[brentkelly]

Upstream v0.1.0 deleted orchestration v1, which the board was built on. Syncing past v0.0.45 meant porting the board rather than resolving conflicts.

This is the T3O-55 epic's integration branch. It brings in its four child cards, each already reviewed and merged here:

• feat(board): board-owned engine and event log in boards.sqlite (T3O-56) #179 (T3O-56): the board gets its own engine and event log in boards.sqlite
• feat(board): board subscription off the orchestration shell (T3O-57) #180 (T3O-57): the board subscription moves off the orchestration shell
• refactor(board): ThreadGateway, one seam for all board→thread access #181 (T3O-58): ThreadGateway becomes the one seam for all board→thread access
• chore(sync): merge upstream v0.1.0 and run the board on orchestration-v2 #182 (T3O-59): merges upstream v0.1.0 and implements ThreadGatewayV2 on orchestration-v2

Land with a merge commit, never a squash (docs/t3o/seams.md). See the review on this PR: #182 was squash-merged into this branch, so upstream v0.1.0 is not yet in its ancestry.

🤖 Generated with Claude Code

[brentkelly]

High-level summary

This is the T3O-55 epic's integration branch. It brings in its four child PRs: a board-owned engine and event log in boards.sqlite (#179), a board subscription off the orchestration shell (#180), ThreadGateway as the single board→thread seam (#181), and the upstream v0.1.0 merge with ThreadGatewayV2 on orchestration-v2 (#182). The engine and persistence layer looks solid. Event append, projection, receipt and watermark commit in one transaction, the one-time legacy copy is crash-safe and idempotent, board migrations stay on their own ledger, and the subscription's snapshot and resume path has no gap or duplicate. Scopes and MCP registration go through the right seams.

I found 3 critical issues. First, #182 was squash-merged into this branch, so v0.1.0 is not in its ancestry; this needs a graft and a hand --no-ff landing, never the merge button. The other two are in the v2 signal mapping. Every v2 run.created is read as a human turn, so engine wake runs revive stalled and escalated steps. And a Stop pressed before a run has started is read as a recoverable turn end, so the board nudges a card the human just stopped. I also found 4 improvements: a todo stream that dies silently, the untested usage-limit handoff, boards.sqlite pragmas, and a seam inventory that no longer matches the markers. There are 4 nitpicks. I left out the pre-existing ChatView.tsx embedded-chrome re-indent and the full-detail resend in board.subscribeCard, because both already exist on t3o and aren't introduced here.

GitHub can't anchor inline comments on this PR. It changes 16,118 files, because the squashed upstream merge brings in the whole of v0.1.0, and GitHub only resolves paths within the first 3,000 files of a diff. Every finding is below instead, with a permalink to its exact lines at the reviewed commit a2b77461d4. That 3,000-file limit is itself another reason to graft the ancestry (Critical 1): once v0.1.0 is an ancestor, this diff shrinks to the fork's own changes.

---

📍 docs/t3o/seams.md:286

Caution

Critical (1/3): The v0.1.0 sync was squash-merged into this branch, so upstream ancestry is gone

PR #182 landed on board/t3o-55 as a squash: a2b77461d4 has one parent, and git merge-base --is-ancestor v0.1.0 HEAD is false. This branch's tree is right: it matches #182's original head 830139cb20, which does descend from v0.1.0. Its history is not. If #183 lands like this (or through the merge button, which squashes again), the next git merge main resolves its merge base to v0.0.45 and re-conflicts the whole v1→v2 rewrite. This is the third occurrence after #57 and #110, which the runbook just above this row warns about. The fork's main mirror is also still at v0.0.45, so the runbook's git push origin main v0.1.0 step hasn't run either.

Suggested fix: Before landing, graft the ancestry back onto board/t3o-55 with git merge -s ours v0.1.0 (check git diff HEAD~1 HEAD is empty), or merge 830139cb20, whose tree is identical. Fast-forward main to v0.1.0 and push it with the tag. Then land #183 by hand with git merge --no-ff, never the merge button, with auto-merge off on this card, and check git merge-base --is-ancestor v0.1.0 t3o.

---

📍 apps/server/src/board/ThreadGatewayV2.ts:207-216

Caution

Critical (2/3): Every v2 run.created counts as a human turn, so engine-started runs revive stalled and escalated steps

v2 emits run.created for runs the engine starts on its own, as well as for human ones: background-work and notification wakes and delegated-task results (Orchestrator.ts:395-423), restart continuations (RestartContinuation.ts:291, on by default), PR-watch wakes (PullRequestWatchReactor.ts:315) and limit-resume: runs. None of these carry a board-minted command id, so all of them become turn-requested{byBoard:false}. handleTurnStartRequested (supervisorReactor.ts:8271) then calls resumeParkedStep, which un-parks stalled, paused and awaiting-input steps and zeroes the stall count, and noteHumanTurn, which gives the step a free turn ending. The resumeParkedStep doc forbids exactly this (the escalation "would quietly un-escalate itself"). Concretely: sweepBackgroundWait escalates a long background wait to stalled, the work finally reports back, v2's wake run starts, and the card goes back to running with no human involved. v1 only fired this signal on thread.turn.start, so this is a regression from the port, and no test covers a wake run.

Suggested fix: In makeSignalReader, return null for a run.created whose payload has workStartedAt, restartContinuationOfRunId, delegatedTaskId or delegatedCompletion. Treat limit-resume: as its own case: it should un-park the usage-limit step but should not count as a human turn. Add supervisor tests for a wake run hitting a stalled step and a paused step.

---

📍 apps/server/src/board/ThreadGatewayV2.ts:221-236

Caution

Critical (3/3): A human Stop pressed while a run is still starting is read as a normal turn end, and the board nudges the card the human stopped

Orchestrator.markStoppedRun (Orchestrator.ts:8810) returns early when run.rootNodeId or run.providerThreadId is null. A Stop pressed during provider start-up therefore records no run_interrupt_request, so this reader never emits interrupt-requested and the supervisor never pauses the step (T3O-23). The run then ends interrupted or cancelled with startedAt === null. Only failed takes the turn-start-failed branch here, so this becomes a plain turn-ended, and handleTurnCompleted goes to recoverStep and sends a recovery nudge. The window is narrow, but the result is the board overriding an explicit human Stop. I traced the code path; I did not reproduce it.

Suggested fix: Map an interrupted/cancelled run with startedAt === null to interrupt-requested, or have the supervisor treat it as a Stop rather than a recoverable turn end. Add a gateway test for a Stop issued before the run starts.

---

📍 apps/server/src/board/ThreadGatewayV2.ts:716-723

Warning

Improvement (1/4): The live todo stream stops for good, without a log, on its first error

subscribeTodoLog ends with Stream.catchCause(() => Stream.empty). The tail forks it with Stream.runForEach (boardThreadTail.ts:129-137), so one EventSinkV2Error (for example a decode failure on one stored event) ends the stream quietly and the fiber exits. The persisted cursor stops moving, card-threads deltas stop, card todo summaries freeze until restart, and drain callers wait forever. observe already gets this right through followStoredEvents, which resubscribes from its cursor.

Suggested fix: Reuse followStoredEvents (or the same cursor-and-retry pattern) starting from head, and log the cause. Add a test that injects a stream failure and checks the tail recovers.

---

📍 apps/server/src/board/ThreadGatewayV2.ts:556-572

Warning

Improvement (2/4): The board-to-v2 usage-limit handoff has no test where recovery is actually armed

The only thing preventing a double resume (the board's own probe plus v2's UsageLimitRecoveryWorker) is the resumeArmed filter in the supervisor (boardWokenLimitParks, supervisorReactor.ts:3632-3640). The contract test only covers the not-limited → false case. The supervisor fake's armLimitRecovery defaults to false (threadGateway.testkit.ts:403), and usageLimitAutoResume.test.ts never sets resumeArmed. Nothing checks that an armed park is skipped by the board's wake and un-parked exactly once by the limit-resume run, and that is the path that decides whether a limited card resumes twice.

Suggested fix: Add one gateway contract test (limited shell → arm → resumeArmed: true and a thread.metadata.update dispatched) and one supervisor test (an armed park is excluded from clearProviderLimitAndResume and the probes, and resumes exactly once).

---

📍 apps/server/src/board/boardDatabase.ts:149-155

Warning

Improvement (3/4): boards.sqlite misses the sync and WAL-size tuning main gets, so every board commit fsyncs on the main thread and its WAL is never truncated

persistence/Sqlite.ts:82,89 sets synchronous = NORMAL and journal_size_limit before this ATTACH runs. Both pragmas are per-database, so boards ends up with synchronous = FULL and journal_size_limit = -1. The checkpoint worker opens only statev2.sqlite (nodeSqliteClient.ts:531-582), so the board WAL is only checkpointed by the 10,000-frame autocheckpoint backstop (about 40 MB) and never shrinks. Every board commit also fsyncs on the event loop, which is the stall the upstream comment at Sqlite.ts:77-82 exists to avoid.

Suggested fix: After the WAL pragma, also run PRAGMA boards.synchronous = NORMAL and PRAGMA boards.journal_size_limit = <WAL_SIZE_LIMIT_BYTES>, optionally with a periodic PRAGMA boards.wal_checkpoint(PASSIVE). Add a file-backed test asserting the pragmas.

---

📍 docs/t3o/seams.md:799-802

Warning

Improvement (4/4): The seam inventory claims to match rg "T3o:" row for row, but it is missing about half the markers, and the boot order above is stale

There are about 150 T3o: markers across 70 files, but the table has about 75 rows. Files with markers and no rows include AppSidebarLayout.tsx (3), routes/welcome.tsx, Sidebar.tsx, serviceLauncher.ts (3), VcsProcess.ts (3), config.ts, serverSettings.ts, GitManager.ts and index.css (3). ws.ts has 7 markers and 6 rows (the SupervisorReactor resolution at ws.ts:1289 is missing), and ChatView.tsx has 6 markers and 2 rows (the embedded-chrome seam is unlisted). Separately, lines 133-136 say persistence/Layers/Sqlite.ts boots reconcileLegacyBoardLedger() → runMigrations() → runBoardMigrations(). v0.1.0 deleted persistence/Layers/; the seam is now persistence/Sqlite.ts:37-43, starting with initialiseBoardDatabase(). The next sync's operator uses this table to detect dropped seams, so missing rows will hide exactly the drops it exists to catch.

Suggested fix: Regenerate the rows from git grep -n "T3o:" over upstream-owned files, or reword this paragraph so the per-file git grep -c is the authority. Fix the boot-order path and sequence.

---

📍 apps/server/src/board/ThreadGatewayV2.ts:324-339

Note

Nitpick (1/4): Most v2 refusals are logged as failures, with a generic message

v2 rejects most invalid commands with OrchestratorDispatchError, whose cause is usually a plain string. That tag isn't in REFUSAL_TAGS, and describe ignores string causes. So something like "Thread … is not active" becomes a ThreadCommandFailedError warning with a generic message instead of a debug-level refusal that names the reason.

Suggested fix: Have describe fall back to a string cause, and decide explicitly whether OrchestratorDispatchError counts as a refusal.

---

📍 apps/server/src/board/boardSubscription.ts:99-104

Note

Nitpick (2/4): An unarchived card's todo strip doesn't come back until its todos change or the client reconnects

Archived cards' threads are left out of the snapshot, and archiving clears the card's thread entries on the client (boardReducer.ts:371-378). This refetch only fires for card-thread-linked/unlinked, so after board.card-unarchived the card has no thread entries until something else touches them.

Suggested fix: Add board.card-unarchived to this condition.

---

📍 apps/server/src/board/boardDatabase.ts:64-70

Note

Nitpick (3/4): The relocation-conflict recovery message names state.sqlite, but the main database is now statev2.sqlite

Under v2 the main connection is statev2.sqlite (config.ts:158). A user who follows this message drops tables from the v1 file, statev2.sqlite keeps its board tables, and boot keeps refusing.

Suggested fix: Name the real main file, which PRAGMA database_list already gives you a few lines below.

---

📍 apps/server/src/board/ThreadGatewayV2.ts:619-621

Note

Nitpick (4/4): sessionLive is true for any thread that has ever run, and turn-ended.errorMessage is always null

activeProviderThreadId stays set once a thread has run, so worktree retire sends thread.stop to every thread in the worktree. That's harmless, but the field no longer means what its name says. Separately, errorMessage: null (line 235) leaves the supervisor's comments about Grok quota refusals arriving through it (supervisorReactor.ts:8767-8770, 6145-6149) stale, since detection now uses lastErrorClass.

Suggested fix: Base sessionLive on activityRunStatus alone (or rename the field), and update the stale supervisor comments.

[brentkelly]

C1 (v0.1.0 ancestry lost) — fixed in ea429cb (git merge -s ours v0.1.0, first commit after a2b7746). git diff HEAD~1 HEAD is empty and git merge-base --is-ancestor v0.1.0 HEAD prints ok. Per the runbook in docs/t3o/seams.md, landing is still by hand: git merge --no-ff board/t3o-55 into t3o, then git push origin main v0.1.0 (main fast-forwards to v0.1.0; checked). I did not push main or the tag: that's the landing step, not this triage.

[brentkelly]

C2 (engine wake runs read as human turns) — fixed in 72c70d1. A new runOrigin in ThreadGatewayV2.ts classifies each run.created. Engine runs raise no signal: workStartedAt, restartContinuationOfRunId, delegatedTaskId or delegatedCompletion set, or a command:, provider-continuation: or server:pr-watch: command id. A limit-resume: run raises a new limit-resumed signal. The supervisor handles it with resumeParkedStep(…, { usageLimitOnly: true }), which wakes only a stalled/usage-limit park and records no human turn. Tests: ThreadGatewayV2.test.ts › "raises nothing for a run the engine started to carry on its own work" and "reads the engine's limit resume as its own signal". usageLimitAutoResume.test.ts › "the engine's limit resume wakes only the usage-limit park, and buys no free ending". That last one fails on the old behaviour, which woke the awaiting-input step and left the limit park alone.

[brentkelly]

C3 (Stop before run start read as a turn end) — fixed in 72c70d1. When a run ends interrupted/cancelled with startedAt === null, the stop came from a human command, and no run_interrupt_request item was seen for that run, the reader now emits interrupt-requested ahead of turn-ended. That's the same order a running turn produces, so pauseStepForHumanStop parks the step before the end is classified. The board's own interrupts still yield only turn-ended, because the board already tracks them. The reader now returns an array per event. Tests: ThreadGatewayV2.contract.test.ts › "a human's Stop before the run started reads as a Stop, not a bare turn end" runs on the real engine and fails on the old reader, which returned only turn-ended. Also ThreadGatewayV2.test.ts › "does not repeat a Stop the engine already recorded".

[brentkelly]

I1 (todo stream ends silently) — fixed in 211f8b4. subscribeTodoLog now goes through followStoredEvents, which logs and resubscribes from the last entry on a failed read. It gained an optional startAfter so it stays pinned at the head read at subscribe time. Test: ThreadGatewayV2.test.ts › "starts after a given cursor and resubscribes from the last event".

[brentkelly]

I2 (no armed-recovery test) — fixed in 211f8b4 with usageLimitAutoResume.test.ts › "a limit armed with the engine is resumed once, by the engine, never by the board". A thread fails on a named-reset limit and armLimitRecovery marks it resumeArmed. At the reset time the board's probe leaves the park alone and sends nothing. The limit-resumed signal then wakes the step, still with no board send.

[brentkelly]

I3 (boards.sqlite pragmas) — fixed in 211f8b4. attachBoardDatabase now sets PRAGMA boards.synchronous = NORMAL and boards.journal_size_limit to main's 32 MiB after the attach. Test: boardDatabase.test.ts › "gives the board file main's WAL durability and size limit", file-backed. It fails without the change (expected 2 to equal 1).

[brentkelly]

I4 (seam inventory incomplete; stale boot path) — fixed in 3e9e195. The inventory now has one row per seam: 129 rows, up from 75, covering 41 files that were missing, among them ws.ts, ChatView.tsx, serviceLauncher.ts and VcsProcess.ts. The migration paragraph now names persistence/Sqlite.ts and the real initialiseBoardDatabase() → runMigrations() → runBoardMigrations() order. The census reads 150 markers across 70 files; it said 71, which was a miscount. Also fixed the server-updates.md marker, which said launcher protocol 3 when the code is at 4.

[brentkelly]

N1 (dispatch refusals logged as failures) — fixed in ee61cb0. An OrchestratorDispatchError whose cause is a string is now a refusal; that's how the engine states a precondition, e.g. "Run … is not interruptible.". describe() returns string causes. A wrapped real failure is still ThreadCommandFailedError. Tests: ThreadGatewayV2.test.ts › commandError (both cases).

[brentkelly]

N2 (unarchived card's thread entries) — fixed in ee61cb0. board.card-unarchived now joins the card-threads refetch, since archive's card-removed drops the entries client-side (boardReducer.ts). Test: boardSubscription.test.ts › "gives an unarchived card back its thread summaries".

[brentkelly]

N3 (conflict message names state.sqlite) — fixed in ee61cb0. BoardRelocationConflictError now carries mainFile, read from PRAGMA database_list (e.g. statev2.sqlite), and the message uses it.

[brentkelly]

N4 (sessionLive / errorMessage) — fixed in ee61cb0. sessionLive now reads the thread's attached provider sessions (status not stopped/error) or a live run, not activeProviderThreadId, which outlives the session. Test: ThreadGatewayV2.contract.test.ts › "a thread holds a live session only while one is attached and not stopped", which fails on the old logic after detach. For errorMessage, I fixed the code rather than the comments: the reader keeps each run's v2 error turn-item failure text and puts it on that run's failed turn-ended (v2 emits the item before the failed run.updated, Orchestrator.ts ~8295). The usage-limit classifier sees Grok's refusal again, and I updated the supervisor comment. Test: ThreadGatewayV2.test.ts › "carries the provider's failure text onto the failed turn's end".

[brentkelly]

Adjudication: round 1 (fixes at 3e9e195)

All 11 findings: fix-upheld. I checked each fix in the code, ran the named tests and probed the risky claims.

• C1, fix-upheld. v0.1.0 (81493ef) is now an ancestor of HEAD via ea429cb, a two-parent merge with an empty tree diff. Pushing main and the tag stays with the by-hand --no-ff landing in the runbook.
• C2, fix-upheld. runOrigin matches how v2 really mints command ids. Engine runs use command: (restart-continuation, mailbox-accepted, steer-follow-up, start-queued and delegated delivery), provider-continuation: and server:pr-watch:. UsageLimitRecoveryWorker uses limit-resume:. Client commands are bare UUIDs, so human turns still read as human. workStartedAt is set only for wake runs (wakeWorkStartedAt). limit-resumed calls resumeParkedStep(..., {usageLimitOnly:true}), which wakes only a stalled/usage-limit park and records no human turn. Tests cover it in ThreadGatewayV2.test.ts and usageLimitAutoResume.test.ts.
• C3, fix-upheld. When a human interrupts or cancels a run that hasn't started, the reader emits interrupt-requested and then turn-ended, deduplicated against a recorded run_interrupt_request. The contract test dispatches a real run.interrupt through the v2 stack.
• I1, fix-upheld. subscribeTodoLog now uses followStoredEvents(..., head), which retries from its cursor. The startAfter test asserts it resubscribes after 5, then after 6.
• I2, fix-upheld. In the new test the probe leaves the armed park alone. Only limit-resumed wakes it, and the board sends no turn of its own.
• I3, fix-upheld. The pragmas are set on boards after the attach. I confirmed the new boardDatabase.test.ts case fails against the pre-fix boardDatabase.ts and passes now.
• I4, fix-upheld. I compared every file with a T3o: marker against the inventory. Each one that exists in v0.1.0 has a row. The only files missing are fork-owned (board/, migrations/, web board/, commandOrigin.ts, boardThreadState.ts). The boot paragraph now names persistence/Sqlite.ts. server-updates.md "protocol 4" matches SERVICE_LAUNCHER_PROTOCOL = 4.
• N1, fix-upheld. An OrchestratorDispatchError with a string cause is now a refusal and is described in its own words. Unit tests cover both branches.
• N2, fix-upheld. board.card-unarchived now triggers the card-threads refetch, with a test.
• N3, fix-upheld. The message names the main file from PRAGMA database_list. This is a nitpick fix and has no test.
• N4, fix-upheld. sessionLive now reads attached sessions that aren't stopped or errored, not the bound provider thread. The contract test covers attach and detach. A failed run's turn end now carries the text of v2's error turn item.

I ran 5 files, 103 tests: all pass.

[brentkelly]

High-level summary — round 2 (re-review at 3e9e195)

PR #183 lands the T3O-55 epic: it moves the board onto upstream orchestration-v2 (v0.1.0) through board/ThreadGatewayV2.ts, with board-owned persistence in boards.sqlite. This round re-reviewed the round-1 fix commits (ea429cbb44..3e9e19545e) and re-checked the new run classification against every place v2 mints a message.dispatch command id. The fixes are solid. The ancestry graft, pragmas, todo tail retry, seam inventory, session liveness and failure text all hold. The weak spot is the new runOrigin classifier. It decides "human" by elimination over a hand-kept prefix list, and that list is wrong in both directions. A human's steer follow-up (command:steer-follow-up:) is silenced as an engine wake. An agent-authored server wake (server:delegated-task-question:) is read as a human and revives parked steps. That gives 2 improvements and 1 nitpick, with no criticals. Both improvements have one fix: read createdBy from the run's user message rather than guess from id prefixes. Nothing else blocks.

Status of round-1 findings

#	prior finding	status
C1	🔴 v0.1.0 sync squash-merged; upstream ancestry lost	✅ closed. ea429cbb44 grafts it with an empty diff. Pushing main and the tag is left to the by-hand landing
C2	🔴 Every v2 run.created read as a human turn	⚠️ partially addressed. Engine wakes on the listed prefixes are now silent, but the classifier misreads steer follow-ups and delegated-task-question wakes (Improvements 1/2 and 2/2)
C3	🔴 Stop before a run starts read as a turn end	✅ closed. One narrow edge remains (Nitpick 1/1)
I1	🟡 Live todo stream stops silently on first error	✅ closed
I2	🟡 Usage-limit handoff has no armed-recovery test	✅ closed
I3	🟡 boards.sqlite misses synchronous/journal_size_limit	✅ closed
I4	🟡 Seam inventory misses markers; stale boot path	✅ closed
N1	🟢 Dispatch refusals logged as failures	✅ closed
N2	🟢 Unarchived card's thread entries not refetched	✅ closed
N3	🟢 Relocation message names state.sqlite	✅ closed
N4	🟢 sessionLive / errorMessage	✅ closed

Findings

GitHub can't resolve inline paths on this PR because the diff is over its 3,000-file limit, so each finding is listed here with a permalink to its line range.

ThreadGatewayV2.ts:184-191

Warning

Improvement (1/2): A human's steer that becomes a follow-up run is read as an engine wake

The blanket command: prefix here also matches command:steer-follow-up:, and the test at ThreadGatewayV2.test.ts:103 pins that. But EffectWorker.ts:280-300 mints that id when a human's steer lands just as the provider turn completes. It re-dispatches the human's own message (createdBy: message.createdBy, creationSource: message.creationSource) as a new start_immediately run. The run is a human turn. It isn't v2 continuing its own work.

So run.created raises nothing, and noteHumanTurn never records the steer. The board then handles the ending of the run the human steered into, sees no human turn, and sends its resume nudge behind the human's message. That is the T3O-17 two-bubble race the turn-requested path exists to prevent. The human's follow-up turn also gets no free ending. A steer at a turn boundary is the common case: people type while the agent finishes.

Suggested fix: Check for command:steer-follow-up: before the blanket command: prefix and classify it as human, then change the test so it expects a human turn-requested. Better still, classify by the run's user message createdBy (run.userMessageId). That fixes this case and Improvement 2/2.

ThreadGatewayV2.ts:200-215

Warning

Improvement (2/2): Server-minted agent messages fall through to "human" and revive parked steps

Any command id that isn't board-minted, limit-resume: or on the engine-prefix list is classified human. v2 has at least one more run-creating server command: DelegatedTaskQuestionReactor.ts:49-64 dispatches message.dispatch with server:delegated-task-question:<key>, createdBy: "agent", creationSource: "server", queue_after_active, to wake a parent thread whose delegated child asked a question. The run is created queued (Orchestrator.ts:5072-5103), and wakeWorkStartedAt is only stamped when a queued run starts (Orchestrator.ts:1672), so none of the run.* fields catch it either.

Result: a card agent that used delegate_task gets turn-requested{byBoard:false} when its child asks a question. resumeParkedStep then un-parks a step a human paused, an escalated stalled step, or one in awaiting-input. noteHumanTurn gives it a free ending. That is the round-1 C2 failure class through a door the prefix list doesn't cover. The default-to-human rule means every future server-minted run id fails the same way.

Suggested fix: Decide "human" positively instead of by elimination. Read the run's user message (run.userMessageId) and treat only createdBy: "user" as a human. Or, more cheaply, treat any server: id that isn't server:board- as engine, and add server:delegated-task-question: to the wake test table.

ThreadGatewayV2.ts:300-306

Note

Nitpick (1/1): The pre-start Stop check mixes the interrupt's command id with the run's own wake fields

runOrigin(stored.commandId, run) gets the id of the command that stopped the run, but it also reads the run's workStartedAt, restartContinuationOfRunId and delegatedTaskId. A human who presses Stop on an immediate wake run (e.g. a restart continuation) before its provider starts gets "engine". No interrupt-requested is emitted, and the card is nudged after a Stop. The window is narrow.

Suggested fix: Classify the stopping command on its own: !isBoardMintedCommandId(id) && !engineCommandId(id). Don't pass the run's wake fields through runOrigin.

[brentkelly]

Round-2 triage (fixed in 2d1c3ad)

I1 — a human's steer that becomes a follow-up run reads as an engine wake: fixed.
runOrigin no longer decides by command-id prefix. It reads the author of the run's own message: a run is human only when its message is createdBy: "user" from a client, not server, and it carries no wake fields. v2 commits that message right after run.created in the same command (Orchestrator.ts:5171→5219, 5578→5617, 6464→6521), so the signal reader holds each non-board run until its message.updated arrives. command:steer-follow-up: carries the human's createdBy/creationSource over (EffectWorker.ts:302), so it is now a human turn. The board's own steer coming back as a follow-up stays silent, because the board authors as user/server (BOARD_AUTHOR). The test that pinned the wrong behaviour is replaced by "reads a human's steer that became a follow-up run as a human turn", which fails on the old reader.

I2 — server-minted agent messages fall through to human: fixed by the same change. A server:delegated-task-question: run carries an agent message, so it is engine even though it has no wake fields at run.created. That case is added to "raises nothing for a run the engine started to carry on its own work", which fails on the old reader. I chose to classify by author rather than add server: to a prefix list, because the author is the fact we actually need, and the prefix list missed this case once already. "waits for the run's own message, not any message on the thread" pins the pairing.

N1 — the pre-start Stop check mixed the interrupt's command id with the run's wake fields: fixed. The check is now isHumanCommandId(stored.commandId), which reads only the stopping command's id: a bare client UUID is a human, and any command:, provider-continuation:, limit-resume: or server: id is not. A new case in "reads a human's Stop before the run started as a Stop, then the turn's end" (a human cancelling an unstarted workStartedAt wake) fails on the old code.

Checks: ThreadGatewayV2.test.ts 23/23; the whole src/board/ suite, including the engine-driven ThreadGatewayV2.contract.test.ts and usageLimitAutoResume.test.ts, passes 1323/1323 across 90 files. Server typecheck is clean and lint is clean on both files.

[brentkelly]

Adjudication: round 2 (at 2d1c3ad)

I1, steer follow-up read as an engine wake: fix-upheld. runOrigin now classifies a run by its message's author. EffectWorker.ts:302 carries the steer's createdBy/creationSource over to the command:steer-follow-up: dispatch, so a human's steer reads as human. I checked all three run.created sites in Orchestrator.ts (5171, 5578, 6464): each emits message.updated for run.userMessageId later in the same command, so holding the run until its message arrives is sound. The new test fails against the old reader.

I2, server-minted agent messages read as human: fix-upheld. A delegated-task question is sent with createdBy: "agent", so it now reads as engine. Anything not user or not from a client source is treated as engine (creationSource === "server" covers BOARD_AUTHOR and scheduled tasks). The extended test case fails against the old reader.

N1, pre-start Stop mixed the stop's id with the run's wake fields: fix-upheld. The check now uses isHumanCommandId(stored.commandId) on the stopping command alone. The new case (a human cancelling an unstarted workStartedAt wake run) fails against the old code.

Run: ThreadGatewayV2.test.ts and usageLimitAutoResume.test.ts, 60/60 pass. With the pre-fix ThreadGatewayV2.ts swapped in, 4 tests fail.

[brentkelly]

High-level summary — round 3 (re-review at 2d1c3ad)

This PR is the epic merge that moves the board onto upstream orchestration-v2 (v0.1.0). The board now reaches threads only through board/ThreadGatewayV2.ts, and it has its own engine, subscription and boards.sqlite lineage. This round I re-read the round-2 fix. runOrigin now reads who wrote the run's message, and the signal reader holds each non-board run until that message arrives. I checked this against the engine. All three run.created sites in orchestration-v2/Orchestrator.ts (~5171, ~5578, ~6464) emit message.updated for run.userMessageId in the same command. observe runs a single live reader whose state survives followStoredEvents retries, and it starts at the committed head, so a command's events never split across a subscription boundary. The awaitingMessage map is capped by SEEN_LIMIT. Human client messages are user from web/mobile. Agent/MCP, delegated-task, provider-continuation and restart runs are agent, and limit-resume is caught by its prefix first. The pre-start Stop check now reads only the stopping command's id. ThreadGatewayV2.test.ts passes 23/23 locally. There are no new human comments on the PR since round 2.

Nothing blocks. This round has 0 critical, 0 improvement and 1 nitpick finding.

Status of round-2 findings

#	prior finding	status
I1	🟡 A human's steer that becomes a follow-up run is read as an engine wake	✅ closed
I2	🟡 Server-minted agent messages fall through to human and revive parked steps	✅ closed
N1	🟢 Pre-start Stop check mixes the interrupt's command id with the run's wake fields	✅ closed

Findings

The diff spans more than 3,000 files, so GitHub cannot anchor inline comments on it. As in earlier rounds, each finding is listed here with a permalink.

Note

Nitpick (1/1): The async-answer run is read as engine only implicitly, and no test covers it

apps/server/src/board/ThreadGatewayV2.ts#L215-L224

message.creationSource === "server" is there to keep the board's own BOARD_AUTHOR messages silent. It also catches v2's async answer. When a person answers a user-input question after its turn has ended, Orchestrator.ts:7546 dispatches message.dispatch with createdBy: "user", creationSource: "server" under the human's command id. That run therefore reads as engine. This looks correct, because the answer already raises input-resolved{answered:true}, which is what un-parks the step. Without a turn-requested, the run's end is then judged normally rather than given a human-turn free pass. But the comment names only the board's messages, and no test pins this path. A future change that narrows the check to BOARD_AUTHOR would turn every late answer into a "human turn".

Suggested fix: Mention the async-answer: message in the comment and add a case to ThreadGatewayV2.test.ts asserting that it raises no turn-requested.

[brentkelly]

Round 3 triage — N1 (async-answer run read as engine only implicitly): fixed in 9d82ae7.

The creationSource === "server" comment in runOrigin now names both cases: the board's own BOARD_AUTHOR messages, and v2's async-answer: run (Orchestrator.ts, message.dispatch with user/server under the human's command id), which must stay engine because input-resolved already un-parks the step. A case for it (client command id, { createdBy: "user", creationSource: "server" }) is added to ThreadGatewayV2.test.ts "raises nothing for a run the engine started to carry on its own work". No behaviour change, so the test passes before and after; it pins the classification. ThreadGatewayV2.test.ts 23/23 pass.