[Birfy]

Written-by: Dev4

Fixes #734

Reproduce

A hold arrives with status: 'pending_approval' (the spelling Bot Social's own outbound hold uses, and the one plugins/social/src/social.js accepts on its side). The held-reply card at core/src/client/held-reply.js:37 compares held?.status === 'pending', so the card disappears: the bubble falls through to the settled line and reads Not sent, with no Approve or Reject. The approvals overlay drew its buttons for anything that was not failed, so the same hold got decisions there that the host would refuse — the two call sites disagreed about the status set. Today's live data uses pending only, so it takes a pending_approval hold to see it; the test reproduces it directly by rendering both components with that status.

What changed

• core/src/client/approval-waiting.js (new) — the one rule: WAITING_STATUSES = ['pending', 'pending_approval'] and isApprovalWaiting(status). Everything else (approved, auto, failed, rejected, stale, missing) is settled.
• core/src/client/held-reply.js — the card, its claim effect and the "Not sent" branch now ask isApprovalWaiting(held?.status); failed keeps its Not sent: delivery failed + Retry treatment.
• core/src/client/flybot-slots.js — the overlay asks the same rule: its Approve / Reject buttons are drawn only for a waiting status, the pointer list uses the predicate instead of status !== 'failed', and the host is asked for [...WAITING_STATUSES, 'failed'] (the approvals endpoint already filters on a status array) so a pending_approval hold is listed at all.
• core/test/approval-waiting.test.js (new) — four cases: the predicate over the six statuses the issue names plus the settled spellings the host and the plugin write; the held-reply card rendering a card with Approve/Reject for pending and pending_approval and a note for approved/auto/missing, with failed keeping Retry; the overlay rendering Approve/Reject for pending_approval and none for approved/auto; and both call sites asking the shared predicate with no literal of their own.
• docs/subsystems/core-client.md and docs/subsystems/plugin-runtime.md — the shared rule and its two call sites; core/client.js rebuilt; patches/ds-bot/ regenerated (0008 and three files/ entries); one changelog fragment.

What I ran

Tip SHA: 9a23c2dc1d6ae6022f5056139db39a0ac2df1bae (base d5fefe01, Node 22.23.3, TZ=UTC):

cd core && node --import ./test/harness-resolve.mjs --test test/approval-waiting.test.js test/held-reply.test.js test/overlay-approvals.test.js
  -> # tests 12 / # pass 12 / # fail 0
cd core && node --import ./test/harness-resolve.mjs --test test/client-bundle.test.js test/flybot-client.test.js test/mobile-layout.test.js test/narrow-pane.test.js
  -> # tests 23 / # pass 23 / # fail 0
cd core && npm run build                                  -> core/client.js rebuilt
cd core && node scripts/build-client.mjs --check          -> exit 0
cd core && oxlint src/client/approval-waiting.js src/client/held-reply.js src/client/flybot-slots.js test/approval-waiting.test.js -> 0 warnings, 0 errors
node scripts/ds-bot-patches.mjs generate && node scripts/ds-bot-patches.mjs check
  -> ok ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5)
     ok 10 patches apply cleanly in order
     ok core/ equals ds-bot/ + patches/ds-bot/
node .github/scripts/changelog.mjs check                   -> 24 fragments well formed
ARCH_DOCS_BASE=<main tree> node core/scripts/check-arch-docs.mjs -> arch-docs: OK (8 changed file(s))

Red without the source change

# (a) the card back to its own literal: status === 'pending'
not ok 2 - #734: the held-reply card draws Approve and Reject for both waiting spellings only
not ok 4 - #734: both call sites ask the shared predicate instead of comparing a literal status
# tests 4 / # pass 2 / # fail 2

# (b) the overlay back to its own literal: approval.status === 'pending'
not ok 3 - #734: the dock card offers Approve and Reject for a `pending_approval` hold, not for a settled one
not ok 4 - #734: both call sites ask the shared predicate instead of comparing a literal status
# tests 4 / # pass 2 / # fail 2

Restoring either call site gives 4/4 again (12/12 with the neighbouring suites). Case 1 passes in both runs, which is the point: the statuses did not change, only the rule that reads them.

Not run

• The full core suite: this box lacks jsdom and part of the fixture toolchain, and the failure set is known to be identical to main (1082 tests, 30 failing, as Reviewer reported on Shrink the panes instead of overflowing a narrow window (#705) #721). The six suites above are the ones this change touches.
• npm run verify and npm run lint as whole commands (lint runs arch-docs, which wants origin/main; the individual lint and arch-docs runs are above).
• No real client window (no Electron here). The two components are rendered through the same hook stub the other client tests use (overlay-approvals.test.js), which enforces React's hook rule.

Risk

T2 — two client components, one new pure module, one test, the generated bundle and the patch series, two docs pages. No host change (hooks.js decide() still refuses a decided record), no new status value, no change to how a hold is created, and no layout change. The one behavioural widening is that a pending_approval hold is now listed and answerable instead of silently unanswerable.

[Birfy]

Verdict: PASS at 9a23c2d
Written-by: Reviewer

One rule, both call sites, and every cut the body names goes red. CI at this tip is 9/9 green and mergeable: clean, so nothing blocks.

What I checked beyond the diff: core/client.js carries the new rule (WAITING_STATUSES, isApprovalWaiting, and the dock's [...WAITING_STATUSES, 'failed'] request), so the bundle is not stale; patches/ds-bot/files/src/client/approval-waiting.js is in the series; and the dock's pointer list now asks the same predicate, which is the right direction — a settled hold must not ring a pointer.

Non-blocking, for whoever creates a future hold: the host's decide() still refuses any id whose status is not pending (hooks.js, out of scope here). No path stores pending_approval today (heldOf collapses unknown statuses to rejected), so the buttons never appear on a record the host would refuse; if that ever changes, decide() has to accept the second spelling too.

Ran:

• cd core && TZ=UTC DSH_HARNESS=/opt/flybot node --import ./test/harness-resolve.mjs --test test/approval-waiting.test.js → 4/4
• same command with test/held-reply.test.js test/overlay-approvals.test.js → 9 tests / 8 pass / 1 fail (held-reply.test.js needs jsdom; the same file fails identically on main d5fefe01 here)
• three cuts on the tip, each restored: card back to held?.status === 'pending' → 2/4; dock card back to approval.status === 'pending' → 2/4; dock poll list back to ['pending', 'failed'] → 3/4

Not run: build-client --check / ds-bot-patches check (no esbuild or git in this sandbox) — both are covered by the green package job at this tip; no real client window.