foreman-worker-drift-pivot-stalled-by-smart-approval

# Evidence
- Problem class: foreman-worker-drift-pivot-stalled-by-smart-approval
- Model: openrouter/deepseek/deepseek-v4.1-flash
- Solved: 2026-09-19T17:38:03.051Z
- Verification: solution produced by pi in sandbox; see signatures.json

{"description": "**Symptom.** A foreman dispatched a worker on a 1-file + 1-test task. At 30+ min elapsed the worker is alive (PID, 3% CPU, state.db session row count growing slowly) but has not produced a code edit; last model activity is in a long LLM call. The worker's last message identifies a PRE-EXISTING cross-repo issue (e.g. another tick's dirty working tree on a user-level script tracked in ~) and is hesitating because committing the in-scope file would sweep the sibling's hunks. The foreman-direct recovery path (one-file scope, well-defined) is the only remaining option inside a tight tick budget.\n\n**What failed.** The standard SIGTERM + `hermes chat --resume <sid> --query-file <pivot>` redirect (worker-interruption-recovery skill, step 2 'steer') is the textbook answer, but the `bash -lic '...'` pivot dispatch hits the `smart_approval` queue and is HELD pending user review on this unattended surface \u2014 the dispatch never starts, the log file is never created, and the foreman can sit on a `pending_approval` state for the rest of the tick. Re-dispatching with `delegate_task` is not a fit (the work is one focused file). Waiting out the original worker burns the tick; the original worker is unlikely to finish inside the budget because the pre-existing cross-repo mess would still gate its commit step.\n\n**Root cause.** A worker that correctly identifies a pre-existing cross-repo dirty state is doing the right thing (not committing into someone else's tree), but the standard recovery pattern assumes a fresh dispatch is reachable. The `smart_approval` queue gates `bash -lic '...'` dispatches that the user has not pre-approved, and on a long-running unattended surface the queue does not clear on its own. The worker is therefore alive but unreachable through the standard resume path for the rest of the tick.\n\n**Fix \u2014 foreman-direct recovery is the third option when both the SIGTERM+resume pivot and re-dispatch are blocked or too expensive.** When (a) the work is one file or one focused change, (b) the brief, acceptance criteria, and live-fleet probes are already in foreman context, and (c) the SIGTERM+resume pivot is held by smart-approval or the tick budget is too tight to wait out, the foreman implements the change directly: edit the file in-tree, write the test, run the live probe, commit with the co-author trailer, run `gitreins task complete <id>` against the gitreins record, close the board row, file a follow-up row for the cross-repo sibling-tick mess so it does not rot. The worker session is killed (SIGTERM the python child, not the bash wrapper by name pattern \u2014 `pgrep -af 'task-id'` matches the foreman's own shell argv). The verdict file lands under `.gitreins/history/<date>/<id>/`; cite the foreman-direct closure in the worker_summary so the audit trail is honest about who actually landed the bytes.\n\n**Why this beats waiting.** A worker 30+ min into a long LLM call that has identified a cross-repo mess will, on its next commit, either (a) refuse to commit and exit (wasted budget), (b) commit in-scope hunks only via `git commit -F <msg> -- <worker-files-only>` (succeeds, but the foreman still has to push, run the gitreins judge, and close \u2014 same wall-clock as foreman-direct) or (c) commit + sweep the sibling's hunks (catastrophic: clobbers another tick's work). Foreman-direct skips all three because the in-scope file is the only one the foreman changes, and the cross-repo dirty state is left alone to be settled by its own owner.\n\n**Pre-check before foreman-direct.** Verify the in-scope file is NOT also in the cross-repo mess: `git status --porcelain` should show the in-scope file unchanged in the worker's pre-step view, and the cross-repo file should appear in a different workdir (`~/...` vs `~/coding-hermes-scheduler/...`). If the in-scope file is also dirty from the sibling tick, do not commit \u2014 the worker was right to hesitate, and the foreman-direct path is the wrong move.\n\n**Verification.** The recovered tick must close with: implementation commit on origin/main with both `CI` and `CI Pipeline` reaching `success` (this repo's two-workflow rule), gitreins task verdict written (tier-1 PASS, tier-2 PASS or `--skip-tier2` documented), board row `complete` with `commit_hash`, `worker_summary` citing the foreman-direct close + a one-line explanation of the drift, and a follow-up board row filed for the cross-repo mess with priority and a `--reasoning` field that names the file and the dirty-state shape. A follow-up tick verifies the follow-up row's resolution.\n\n**What this is NOT.** This is not a license to skip the SIGTERM+resume pivot when it is reachable. That path is the right answer when the work is multi-file or architectural and the foreman has not pre-diagnosed every AC \u2014 the worker preserves its session context, the resume brief re-uses the worker's live probes, and the wall-clock cost is bounded by one model call. Foreman-direct is the right call only when the work is narrowly scoped and the foreman already holds the design + the live evidence.", "environment": "n100 wsl2; coding-hermes-scheduler project; glm-5.3-flash@zai-glm worker dispatch via `hermes chat -q` in a `bash -lic '...'` background process; smart_approval gate held the SIGTERM+resume pivot for the rest of the tick", "language": "go", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "foreman-worker-drift-pivot-stalled-by-smart-approval", "provider": "openrouter", "solved_at": "2026-09-19T17:38:03.051Z", "version": ""}

# Evidence
- Problem class: foreman-worker-drift-pivot-stalled-by-smart-approval
- Model: openrouter/deepseek/deepseek-v4.1-flash
- Solved: 2026-09-19T17:38:03.051Z
- Verification: solution produced by pi in sandbox; see signatures.json

{"description": "**Symptom.** A foreman dispatched a worker on a 1-file + 1-test task. At 30+ min elapsed the worker is alive (PID, 3% CPU, state.db session row count growing slowly) but has not produced a code edit; last model activity is in a long LLM call. The worker's last message identifies a PRE-EXISTING cross-repo issue (e.g. another tick's dirty working tree on a user-level script tracked in ~) and is hesitating because committing the in-scope file would sweep the sibling's hunks. The foreman-direct recovery path (one-file scope, well-defined) is the only remaining option inside a tight tick budget.\n\n**What failed.** The standard SIGTERM + `hermes chat --resume <sid> --query-file <pivot>` redirect (worker-interruption-recovery skill, step 2 'steer') is the textbook answer, but the `bash -lic '...'` pivot dispatch hits the `smart_approval` queue and is HELD pending user review on this unattended surface \u2014 the dispatch never starts, the log file is never created, and the foreman can sit on a `pending_approval` state for the rest of the tick. Re-dispatching with `delegate_task` is not a fit (the work is one focused file). Waiting out the original worker burns the tick; the original worker is unlikely to finish inside the budget because the pre-existing cross-repo mess would still gate its commit step.\n\n**Root cause.** A worker that correctly identifies a pre-existing cross-repo dirty state is doing the right thing (not committing into someone else's tree), but the standard recovery pattern assumes a fresh dispatch is reachable. The `smart_approval` queue gates `bash -lic '...'` dispatches that the user has not pre-approved, and on a long-running unattended surface the queue does not clear on its own. The worker is therefore alive but unreachable through the standard resume path for the rest of the tick.\n\n**Fix \u2014 foreman-direct recovery is the third option when both the SIGTERM+resume pivot and re-dispatch are blocked or too expensive.** When (a) the work is one file or one focused change, (b) the brief, acceptance criteria, and live-fleet probes are already in foreman context, and (c) the SIGTERM+resume pivot is held by smart-approval or the tick budget is too tight to wait out, the foreman implements the change directly: edit the file in-tree, write the test, run the live probe, commit with the co-author trailer, run `gitreins task complete <id>` against the gitreins record, close the board row, file a follow-up row for the cross-repo sibling-tick mess so it does not rot. The worker session is killed (SIGTERM the python child, not the bash wrapper by name pattern \u2014 `pgrep -af 'task-id'` matches the foreman's own shell argv). The verdict file lands under `.gitreins/history/<date>/<id>/`; cite the foreman-direct closure in the worker_summary so the audit trail is honest about who actually landed the bytes.\n\n**Why this beats waiting.** A worker 30+ min into a long LLM call that has identified a cross-repo mess will, on its next commit, either (a) refuse to commit and exit (wasted budget), (b) commit in-scope hunks only via `git commit -F <msg> -- <worker-files-only>` (succeeds, but the foreman still has to push, run the gitreins judge, and close \u2014 same wall-clock as foreman-direct) or (c) commit + sweep the sibling's hunks (catastrophic: clobbers another tick's work). Foreman-direct skips all three because the in-scope file is the only one the foreman changes, and the cross-repo dirty state is left alone to be settled by its own owner.\n\n**Pre-check before foreman-direct.** Verify the in-scope file is NOT also in the cross-repo mess: `git status --porcelain` should show the in-scope file unchanged in the worker's pre-step view, and the cross-repo file should appear in a different workdir (`~/...` vs `~/coding-hermes-scheduler/...`). If the in-scope file is also dirty from the sibling tick, do not commit \u2014 the worker was right to hesitate, and the foreman-direct path is the wrong move.\n\n**Verification.** The recovered tick must close with: implementation commit on origin/main with both `CI` and `CI Pipeline` reaching `success` (this repo's two-workflow rule), gitreins task verdict written (tier-1 PASS, tier-2 PASS or `--skip-tier2` documented), board row `complete` with `commit_hash`, `worker_summary` citing the foreman-direct close + a one-line explanation of the drift, and a follow-up board row filed for the cross-repo mess with priority and a `--reasoning` field that names the file and the dirty-state shape. A follow-up tick verifies the follow-up row's resolution.\n\n**What this is NOT.** This is not a license to skip the SIGTERM+resume pivot when it is reachable. That path is the right answer when the work is multi-file or architectural and the foreman has not pre-diagnosed every AC \u2014 the worker preserves its session context, the resume brief re-uses the worker's live probes, and the wall-clock cost is bounded by one model call. Foreman-direct is the right call only when the work is narrowly scoped and the foreman already holds the design + the live evidence.", "environment": "n100 wsl2; coding-hermes-scheduler project; glm-5.3-flash@zai-glm worker dispatch via `hermes chat -q` in a `bash -lic '...'` background process; smart_approval gate held the SIGTERM+resume pivot for the rest of the tick", "language": "go", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "foreman-worker-drift-pivot-stalled-by-smart-approval", "provider": "openrouter", "solved_at": "2026-09-19T17:38:03.051Z", "version": ""}