Remove the Flow only toggle: the `flow` label alone says what goes first #7771

main is merged into the branch and pushed. The conflicts in docs/MCP.md and src/tui/screens/about.ts are resolved. The 148 tests I ran pass (17 files: idle-reason, mcp-flow-why, flow-first, and a sample of tests that mention About, repo_settings or MCP.md), and bun x tsc --noEmit is clean. I did not run the full suite here, so the forge's check on this push is the first full run.

Conflicts

• docs/MCP.md: I took main's newer releases, report and reports rows. The repo_settings row keeps main's wording without flowOnly, since this pull removes that switch.
• src/tui/screens/about.ts: main added a "Moving" row that explains why builders are held. I kept it and dropped the "Flow only" row this pull removes.

Follow-on edits Code that landed on main after this pull branched still used the retired Flow only switch, so I removed those uses too:

• src/flow/why.ts: the flow_only cause is gone, along with its fact and its import.
• src/crew/idle_reason.ts: it no longer reports "flow only" as a reason the builders are idle.
• docs/MCP.md: the flow row no longer lists flow_only among the causes.
• Tests: in test/idle-reason.test.ts and test/mcp-flow-why.test.ts I deleted the cases that exercised the removed switch and fixed the assertions that named it. The first-cause-wins check now expects no_headroom instead of flow_only. These tests tested the removed feature, not behaviour that should stay.

Nothing else changed.

Continues #7771

main is merged into the branch and pushed. The conflicts in docs/MCP.md and src/tui/screens/about.ts are resolved. The 148 tests I ran pass (17 files: idle-reason, mcp-flow-why, flow-first, and a sample of tests that mention About, repo_settings or MCP.md), and bun x tsc --noEmit is clean. I did not run the full suite here, so the forge's check on this push is the first full run.

Conflicts

• docs/MCP.md: I took main's newer releases, report and reports rows. The repo_settings row keeps main's wording without flowOnly, since this pull removes that switch.
• src/tui/screens/about.ts: main added a "Moving" row that explains why builders are held. I kept it and dropped the "Flow only" row this pull removes.

Follow-on edits Code that landed on main after this pull branched still used the retired Flow only switch, so I removed those uses too:

• src/flow/why.ts: the flow_only cause is gone, along with its fact and its import.
• src/crew/idle_reason.ts: it no longer reports "flow only" as a reason the builders are idle.
• docs/MCP.md: the flow row no longer lists flow_only among the causes.
• Tests: in test/idle-reason.test.ts and test/mcp-flow-why.test.ts I deleted the cases that exercised the removed switch and fixed the assertions that named it. The first-cause-wins check now expects no_headroom instead of flow_only. These tests tested the removed feature, not behaviour that should stay.

Nothing else changed.

The Flow only switch is gone, and the check that parked the last try, "migrations are additive across a roll", now passes. I ran it with the flow, MCP tool, idle-reason and schema tests, and bun x tsc --noEmit is clean. I did not run the full suite; the forge runs it on this push.

• Why the last try failed: the old pull added a migration that dropped the flow_only column and the flow_only_watch table. A roll keeps the previous release serving on the database the new one migrates, so a migration may not drop what that release still reads.
• The fix: I deleted that migration and its pin. The flow_only column and the flow_only_watch table stay in the schema, and no code reads or writes them. Dropping them is a follow-up once no release in play touches them, and I did not file it.
• Test change: test/flow-first.test.ts no longer asserts the column is gone. That assertion was wrong once the column stays. It still checks that the API no longer carries flowOnly.
• Docs: I removed flow_only from the list of causes in README.md and docs/MCP.md, and regenerated the MCP tool table.
• The merge with main: while I worked, a merge of main into this branch was committed and pushed by something other than me, as bb7a68ea. It also dropped the flow_only cause from the new why-it-is-idle and moving rows. I only checked that it left no stale references.

To try it, run files=$(bun scripts/fast.ts) && bun test $files, or just bun test ./test/schema-additive.test.ts.

This pull removes the Flow only toggle, so the flow label alone says what goes first. It is a small, single-purpose removal and is not on the pipeline-first list. The sentinel's review is addressed below. I ran tsc and the tests that cover the change, and all pass; the forge runs the full check on this push.

What changed

• Switch removed: the Flow only setting, its dispatcher holds, alarm lines, settings card, status line and the WAITS_FOR_FLOW_ONLY hold on a requested pull are gone.
• Ordering: readyNow puts ready issues labelled flow first; with none labelled, the order is the old one, and assigned work always starts.
• Flow first button: a writer clicks Flow first on the issue or on a list row (POST …/issues/:number/flow) to put it first or take it back. Any flow issue is put first this way, and the label is created on first use.
• MCP: the labels tool with action: "add" does the same.
• Migration: it stays additive, so the unread repo.flow_only column and the flow_only_watch table remain until the follow-up drops them.

Changes for the review

1. Terminal door: the issue screen now has f ("flow first"), a toggle through the same putFlowFirst action. It makes the label on a repository that has none, and a reader gets no key. The README and docs/design/areas/flow-first.md now list all three doors. The new test/tui-issue-flow-first.test.ts covers it.
2. Explicit refusal: ensureFlowLabel now returns a Result, and putFlowFirst and the MCP labels tool both return its refusal.

- Same-origin check: the /flow route reads its form through readForm(ctx, "rw"), the same as the other issue mutations, and a new test posts with a foreign Origin header. That post is refused and nothing is labelled. - Reader coverage: a reader's web post and a reader's MCP add are refused and create no label (existing tests). - Your 404: the 404 you saw on preview issue 1 was probably that issue not existing there.

1. Follow-up filed: #7803 drops the flow_only column and the flow_only_watch table. The leftover flow_only.cleared line in src/core/event_audience.ts now names it.
2. Tidy: I reverted the import reorder in src/crew/requested.ts and removed the trailing blank line in src/crew/words.ts.
3. Tests:

- Ordering: one new test shows a flow issue outranks a newer raised one, and that a closed flow issue is not ready. Both are in test/flow-first.test.ts. - Assigned work: the same file already covers an assigned, unlabelled issue starting normally. - Deleted suites: I did not port the rest of what the switch-only suites covered, because it was behaviour of the removed switch.

Not done: the schema leftovers are not dropped here (that is #7803).

Try it: open an issue and press Flow first, or f in the terminal issue screen. The map's "Ready now" then lists it first, marked flow.

🤖 Generated with Claude Code

Parked by the crew: the check failed ("reviews, threads and the merge gate > p on a sealed issue shows the private repository and its clone URL, with the same refusals") and the decider saw no point in another try try 1: README.md, docs/MCP.md, docs/STATUS.md, docs/design/areas/flow-first.md (+57 more)

The failing test is fixed and pushed as 7c8e2c3e. I have not yet seen the forge's check run on the new push.

Cause: My earlier commit put an f flow first binding in the terminal issue screen's key bar ahead of p private repo. The bar is cut off at the terminal width, so the sealed-issue hint private repo was pushed off screen. The test waits for that text, so it timed out after 30 seconds.

Fix: In src/tui/screens/issue.ts, I moved the f binding to after p, at the end of the writer's list. Nothing else changed.

Checks run here:

• bun x tsc --noEmit is clean.
• bun scripts/gate.ts printed nothing, so I take it as clean.
• test/tui-workflows.test.ts passes, 8 of 8. test/tui-issue-flow-first.test.ts also passes.
• Reverting the fix made p on a sealed issue… fail again on its own.
• One earlier run of test/tui-workflows.test.ts also failed "a review thread resolves, collapses, and reopens". It passed on the next full run, so it looks like a one-off.

Three other shards (test/tui-issue-goahead.test.ts, test/mcp-profile.test.ts, test/pull-variants.test.ts) were killed on time limits in the check, after fail-fast stopped the run. I did not run them here.

I merged main into the branch, fixed the three merge conflicts, and pushed. I haven't seen the forge's check verdict on the new push. The type check and scripts/gate.ts are clean here, and the 169 tests I ran passed. I didn't run the full suite; the forge's check does that.

The pull still removes the "Flow only" toggle and puts the flow label in its place. The three conflicts were:

• src/core/dependencies.ts: main added a "put first" ordering (first, #7806) that overlaps with the flow label. I kept both. Ready work is sorted by the flow label first, then by "put first", latest first. Anything a person put first therefore still comes ahead of flow-labelled work.
• src/tui/screens/about.ts: I kept main's new team-card code (the empty seat and the fill button). The detach check now uses mayPerson(), the name this branch gave the person check, in place of the old mayFlow().
• src/web/studio/crew.ts: I dropped main's Flow only form from the autonomy card. The "No reviewer" note stays.

The tests I ran were test/dependencies.test.ts, the flow-label/first-ordering/about tests, and every file that references readyNow, firstAt or flowLabelled.

Parked by the crew: the check stayed red through 2 automatic tries

The last red test, "the board and the autonomy settings say so", now passes, and the fix is pushed. test/review-waits.test.ts passes (6 of 6), tsc is clean and design-lint is clean. scripts/gate.ts printed nothing, so I'm assuming it passed. I ran only that one test file, not the rest of the suite.

The merge from main had brought back an old "No reviewer: agent pulls wait for you" note on the "On its own" card in src/web/studio/crew.ts. Since #7774, the crew card on the same settings page already warns "No reviewer: …" when that seat is empty, so the page said it twice. The test expects it once, and it was right.

I deleted the old note in src/web/studio/crew.ts and kept the crew card's warning, so the toggle stays removed. I did not change the test.

I merged main into this branch and pushed it. The only conflict was the labels and land_past_gate rows in docs/MCP.md, and I kept both.

• labels row: it keeps this pull's wording, including action? and "flow goes first among ready work".
• land_past_gate row: it keeps the row main added.

bun x tsc --noEmit and bun scripts/gate.ts both ran clean. scripts/fast.ts could not name tests, because the diff touches 1473 of 1704 files. I ran 9 test files by hand instead: test/mcp.test.ts, test/held-hot-pulls.test.ts, test/held-relieves-map.test.ts, test/gate-bypass.test.ts, and five others matching "label" or "flow-only". All 89 tests pass. I did not run the whole suite; the forge's check does that on the push.

The behaviour of the pull is unchanged: the Flow only toggle stays removed, and flow is still an ordinary label that goes first among ready work.

Parked by the crew: the check stayed red through 2 automatic tries

The flowOnly toggle is removed, and the conflict markers that stopped the last push from booting are gone. I didn't boot the app: my attempt to start it from src/server.ts failed because that path doesn't exist in this clone.

• Conflict markers: the merge had left <<<<<<< markers in src/crew/dispatch.ts. I resolved them by keeping main's twin.ts import and dropping the flow_only.ts import. A search of the branch finds no markers left, and the branch already contains origin/main, so there was nothing more to merge.
• Test and docs: test/conversation-fence.test.ts still used flowOnly, and tsc rejected it. The scripted-injection test now tries repo_settings with visibility: "private". The named() unit tests use allowForks, which exercises the same boolean-switch matching. I reworded the matching comments in src/core/fence.ts and docs/features/conversation-fence.md to match.
• Checks: bun x tsc --noEmit is clean and bun scripts/gate.ts printed no errors. test/conversation-fence.test.ts and test/flow-first.test.ts pass (24 tests). I did not run the full suite: scripts/fast.ts named 1476 of 1708 files, so the forge's check covers it on this push.

I added nothing beyond the removal.

🤖 Generated with Claude Code

The pull's check was failing on conflict markers in src/crew/dispatch.ts. They're gone, and tsc --noEmit and test/conversation-fence.test.ts now pass. bun scripts/gate.ts and the other test files I ran (test/flow-first.test.ts, test/ledger.test.ts) were not re-run after the final fence-test edit. I haven't seen the forge's check on the new head.

• Conflict markers: a bad merge had left <<<<<<</>>>>>>> lines in the imports. The resolved file keeps main's twin.ts import and drops the flowOnlyHolds import, since the Flow only toggle is removed.
• Type error behind the markers: test/conversation-fence.test.ts still read repo.flowOnly, which no longer exists. The test and docs/features/conversation-fence.md now use repo_settings with visibility: "private" as the injected write.
• The allowForks examples: the wording-match cases in that test, plus the comments in src/core/fence.ts, still use allowForks as a made-up example setting. That function only matches text, so I left them.

The branch has changed under me. By the time I went to commit, the working tree was clean. The commits 6e194924 (conflict-marker fix) and 464f77db (fence test and docs) were already on the branch and match what I'd done, so I didn't add a commit or push. The branch matches origin.

I did not run the full suite. bun scripts/fast.ts named 1476 of 1708 test files for this diff, which is too broad to run here. The forge's check runs them.

Try it: bun test test/conversation-fence.test.ts test/flow-first.test.ts.