An open issue the crew found done on main is held as done_on_main, not stalled, and never handed back to the planner #2508

Continues #2508

An open issue whose newest crew note is "Done on main already, waiting for you to close it" is now held as done_on_main. The planner no longer gets it back. I ran test/crew-held.test.ts and the flow, tui, brief and parks suites; all pass. I did not run the type check: tsc could not find the bun types in this sandbox.

• The hold: src/crew/held.ts has a new done_on_main hold, asked right after planner and before stalled. It uses alreadyDone(), is not in REPLANNABLE, and the tick line says done_on_main=N. Because stalled and run_cap are the only holds stuckOf lists for the planner, the brief never names these issues.
• A later park note: the issue stops being done_on_main. If the crew has since run on it again, it is stalled and replannable again. A park note alone doesn't do that. A park written by a person who directs the crew counts as a word after the last run, so the issue becomes startable.
• A person's comment after the done note: it does not make the issue startable. alreadyDone() only looks at the crew's notes, so the issue stays done_on_main.
• src/crew/parks.ts is unchanged. Its parkedTwice query already leaves out an issue whose done note is newer than its last park, which is the same rule alreadyDone() uses. I didn't add a second filter.
• The asks are unchanged, so people still see these issues as "waiting for you to close it".
• Tests: a new case in test/crew-held.test.ts covers the three behaviours, and none of the existing heldWords assertions needed changing. I did not run the whole bun test, so the forge's check will be the first full run.

I did not check the issue's #2344–#2347, #2392 and #451 against the live board; the tests use synthetic issues.

An open issue the crew found done on main is now held as done_on_main instead of stalled, so the planner no longer gets it back every tick. The work is already pushed; nothing changed in this session. The branch matches origin, and the issue has no new comments I could find. The comments route returned no route, so I couldn't read its thread. I ran test/crew-held.test.ts and the flow, tui, brief and parks suites, and all pass. I did not run the type check or the full bun test; the forge's check will be the first full run.

• The hold: src/crew/held.ts has a new done_on_main hold, asked right after planner and before stalled. It uses alreadyDone() and is not in REPLANNABLE. The tick line says done_on_main=N.
• The planner's brief: stuckOf only lists stalled and run_cap issues, so a done-on-main issue never reaches it. I left src/crew/parks.ts alone, because the parked-twice query already leaves out an issue whose done note is newer than its last park. The asks are untouched, so people still see these issues as "waiting for you to close it".
• A later park note: it takes the issue out of done_on_main. If a run has happened since, the issue is stalled and replannable again. A park note alone is not enough. A park written by a person who directs the crew counts as a word after the last run, so the issue becomes startable.
• A person's comment after the done note: it leaves the issue held as done_on_main, not startable.
• Tests: one new case in test/crew-held.test.ts covers all three behaviours. No existing heldWords assertion needed changing.

I did not check the real issues named in the report (#2344–#2347, #2392, #451) against the live board; the tests use synthetic issues.

An open issue the crew found done on main is now held as done_on_main instead of stalled, so the planner no longer gets it back every tick. I changed nothing this session. The work was already pushed in ed9259a4, and the branch matches origin with a clean tree. I ran test/crew-held.test.ts and the flow, tui, brief and parks suites, and all pass. I did not run the type check or the full bun test: tsc can't find the bun types in this sandbox, so the forge's check will be the first full run.

• The hold: src/crew/held.ts has a new done_on_main hold, asked right after planner and before stalled. It uses alreadyDone() and is not in REPLANNABLE. The tick line says done_on_main=N.
• The planner's brief: it lists only stalled and run_cap issues, so a done-on-main issue never reaches it. I left src/crew/parks.ts alone, because the parked-twice query already leaves out an issue whose done note is newer than its last park. The asks are untouched, so people still see these issues as "waiting for you to close it".
• A later park note: it takes the issue out of done_on_main. If a run has happened since, the issue is stalled and replannable again. A park note alone is not enough. A park written by a person who directs the crew counts as a word after the last run, so the issue becomes startable.
• A person's comment after the done note: the issue stays held as done_on_main, not startable.
• Tests: one new case in test/crew-held.test.ts covers all three behaviours. No existing heldWords assertion needed changing.

I did not check the real issues named in the report (#2344–#2347, #2392, #451) against the live board; the tests use synthetic issues.

An open issue the crew found done on main is now held as done_on_main instead of stalled, so the planner no longer gets it back every tick. I changed nothing this session. The work is already pushed in ed9259a4, the branch matches origin, and the tree is clean. The issue is still open and I found nothing new on it. I ran test/crew-held.test.ts and the flow, tui, brief and parks suites, and all pass. I did not run the type check or the full bun test: tsc can't find the bun types in this sandbox, so the forge's check will be the first full run.

• The hold: src/crew/held.ts has a new done_on_main hold, asked right after planner and before stalled. It uses alreadyDone() and is not in REPLANNABLE. The tick line says done_on_main=N.
• The planner's brief: it lists only stalled and run_cap issues, so a done-on-main issue never reaches it. I left src/crew/parks.ts alone, because the parked-twice query already leaves out an issue whose done note is newer than its last park. The asks are untouched, so people still see these issues as "waiting for you to close it".
• A later park note: it takes the issue out of done_on_main. If a run has happened since, the issue is stalled and replannable again. A park note alone is not enough. A park written by a person who directs the crew counts as a word after the last run, so the issue becomes startable.
• A person's comment after the done note: the issue stays held as done_on_main, not startable.
• Tests: one new case in test/crew-held.test.ts covers all three behaviours. No existing heldWords assertion needed changing.

I did not check the real issues named in the report (#2344–#2347, #2392, #451) against the live board; the tests use synthetic issues.

An open issue the crew found done on main is now held as done_on_main instead of stalled, so the planner no longer gets it back every tick. I changed nothing this session. The work is already pushed in ed9259a4, and the branch matches origin with a clean tree.

I ran test/crew-held.test.ts and the flow, tui, brief and parks suites, and all pass. I did not run the type check or the full bun test: tsc can't find the bun types in this sandbox, so the forge's check will be the first full run.

• The hold: src/crew/held.ts has a new done_on_main hold, asked right after planner and before stalled. It uses alreadyDone() and is not in REPLANNABLE. The tick line says done_on_main=N.
• The planner's brief: it lists only stalled and run_cap issues, so a done-on-main issue never reaches it. I left src/crew/parks.ts alone, because the parked-twice query already leaves out an issue whose done note is newer than its last park. The asks are untouched, so people still see these issues as "waiting for you to close it".
• A later park note: it takes the issue out of done_on_main. If a run has happened since, the issue is stalled and replannable again. A park note alone is not enough. A park written by a person who directs the crew counts as a word after the last run, so the issue becomes startable.
• A person's comment after the done note: the issue stays held as done_on_main, not startable.
• Tests: one new case in test/crew-held.test.ts covers all three behaviours. No existing heldWords assertion needed changing.

I did not check the real issues named in the report (#2344–#2347, #2392, #451) against the live board; the tests use synthetic issues.

An open issue the crew found done on main is now held as done_on_main instead of stalled, so the planner no longer gets it back every tick. I changed nothing this session. The work is already pushed in ed9259a4, and the branch matches origin with a clean tree.

I ran test/crew-held.test.ts and the flow, tui, brief and parks suites, and all pass. I did not run the type check or the full bun test: tsc can't find the bun types in this sandbox, so the forge's check will be the first full run.

• The hold: src/crew/held.ts has a new done_on_main hold, asked right after planner and before stalled. It uses alreadyDone() and is not in REPLANNABLE. The tick line says done_on_main=N.
• The planner's brief: it lists only stalled and run_cap issues, so a done-on-main issue never reaches it. I left src/crew/parks.ts alone, because the parked-twice query already leaves out an issue whose done note is newer than its last park. The asks are untouched, so people still see these issues as "waiting for you to close it".
• A later park note: it takes the issue out of done_on_main. If a run has happened since, the issue is stalled and replannable again. A park note alone is not enough. A park written by a person who directs the crew counts as a word after the last run, so the issue becomes startable.
• A person's comment after the done note: the issue stays held as done_on_main, not startable.
• Tests: one new case in test/crew-held.test.ts covers all three behaviours. No existing heldWords assertion needed changing.

I did not check the real issues named in the report (#2344–#2347, #2392, #451) against the live board; the tests use synthetic issues.

I merged main into the branch and pushed it (71e759b1). test/crew-held.test.ts passes with 6 tests; I did not run the other suites or the type check after the merge.

main had already gained its own done_on_main hold in src/crew/held.ts, which conflicted with mine, so I kept main's version of that file and dropped mine. What this pull still adds is one test in test/crew-held.test.ts. It checks that a person's comment after the done note leaves the issue held as done_on_main and not startable, which main's test doesn't cover. It also confirms an issue the crew parks after the done note and then runs on again is replannable. In the conflicted test file I kept main's test and put mine after it.

I loosened my assertion from done_on_main=2 to done_on_main=. The merged test file already holds more than one such issue, and the exact count was not what I was testing.