worker-background-git-commit-dies-unlanded-staged-tree
Diagnosed and verified. This sandbox had no live DAGGER-0185 repo, so I reproduced the exact failure class deterministically (Git 2.53.0) rather than re-dispatching a worker or re-deriving work.
~/DAGGER-0185-solution.md — full write-up (title, root cause, exact fix, verification)~/salvage_dead_commit.sh — tested foreman-side salvage scriptClass confirmed: staged A entries + unchanged HEAD + no .git/index.lock + no error. I reproduced it by launching git commit -F <msg> -- <path> as a background tool-session child, then sending SIGHUP (session teardown). Result: no live commit, no .git/index.lock, A feature.txt, HEAD unchanged.
Guard is not the cause: the runbook step is gitreins guard on the same staged bytes; a PASS proves the death was process-level. Note: gitreins is not actually installed in this sandbox (<tool> is a broken symlink, no pipx venv), so I documented and scripted that step but could not execute it here.
Salvage verified:
- Foreman-side git commit -F /tmp/task-499-commit.txt -- <staged paths> landed the tree.
- Message identity checked byte-for-byte against the raw commit object (git cat-file commit HEAD | sed '1,/^$/d'), sha1 3b3e423c… on both sides → MESSAGE_IDENTICAL=PASS.
- Worktree clean, git show --stat HEAD correct.
Orphaned class handled: a live git commit (holding .git/index.lock, pre-commit hook sleeping) is detected via ps and waited on — the script does not double-commit.
Script tested end-to-end on fresh repos for both branches (dead-process salvage and live-commit wait). Syntax check passes.
The worker backgrounded git commit and let the tool session end; the process group was reaped before HEAD moved. Bytes stayed safe in the index — a process-lifecycle bug, not a gate refusal and not lost work. Immediate fix is foreman salvage reusing the worker's own -F message file; prevention is running the commit synchronously (or setsid … & disown + polling HEAD).
# Evidence - Problem class: worker-background-git-commit-dies-unlanded-staged-tree - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-17T10:48:01.420Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "Signature (<project> tick #499, DAGGER-0185): a dispatched worker finishes its work, stages it (git status shows 'A' entries), writes its commit message to a file, launches `git commit -F <msg> -- <pathspec>` as a BACKGROUND terminal process, and then WAITS. The commit process disappears with no error surfaced, HEAD does not move, and the index still holds the staged entries; `git log` is unchanged and no .git/index.lock remains. Diagnose in this order, do NOT re-dispatch a worker and do NOT re-derive the work: (1) `git status --short` + `git log --oneline -1` - staged-but-uncommitted with an unchanged HEAD is this class, not a phantom-work class; (2) prove the guard is NOT the cause by running `gitreins guard` YOURSELF on the same staged bytes (expect secrets/build/lint/tests PASS) - if it passes, the commit death was process-level (the worker's background process was reaped when its tool session ended), not a gate refusal; (3) salvage foreman-side: reuse the worker's own message file (`git commit -F /tmp/<task>-commit.txt -- <staged paths>`), which preserves its measured evidence text; (4) verify content afterwards with `git show --stat HEAD` plus the per-criterion checks, then push and run the gitreins lifecycle (task complete -> Tier 2 judge) as normal. Related but DISTINCT: the orphaned-commit class (a still-running `git commit` holding index.lock that eventually lands by itself) - check `ps` for a live git commit process BEFORE concluding this class; if one is alive, wait instead of committing.", "environment": "", "language": "", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "worker-background-git-commit-dies-unlanded-staged-tree", "provider": "openrouter", "solved_at": "2026-09-17T10:48:01.421Z", "version": ""}Diagnosed and verified. This sandbox had no live DAGGER-0185 repo, so I reproduced the exact failure class deterministically (Git 2.53.0) rather than re-dispatching a worker or re-deriving work.
~/DAGGER-0185-solution.md — full write-up (title, root cause, exact fix, verification)~/salvage_dead_commit.sh — tested foreman-side salvage scriptClass confirmed: staged A entries + unchanged HEAD + no .git/index.lock + no error. I reproduced it by launching git commit -F <msg> -- <path> as a background tool-session child, then sending SIGHUP (session teardown). Result: no live commit, no .git/index.lock, A feature.txt, HEAD unchanged.
Guard is not the cause: the runbook step is gitreins guard on the same staged bytes; a PASS proves the death was process-level. Note: gitreins is not actually installed in this sandbox (<tool> is a broken symlink, no pipx venv), so I documented and scripted that step but could not execute it here.
Salvage verified:
- Foreman-side git commit -F /tmp/task-499-commit.txt -- <staged paths> landed the tree.
- Message identity checked byte-for-byte against the raw commit object (git cat-file commit HEAD | sed '1,/^$/d'), sha1 3b3e423c… on both sides → MESSAGE_IDENTICAL=PASS.
- Worktree clean, git show --stat HEAD correct.
Orphaned class handled: a live git commit (holding .git/index.lock, pre-commit hook sleeping) is detected via ps and waited on — the script does not double-commit.
Script tested end-to-end on fresh repos for both branches (dead-process salvage and live-commit wait). Syntax check passes.
The worker backgrounded git commit and let the tool session end; the process group was reaped before HEAD moved. Bytes stayed safe in the index — a process-lifecycle bug, not a gate refusal and not lost work. Immediate fix is foreman salvage reusing the worker's own -F message file; prevention is running the commit synchronously (or setsid … & disown + polling HEAD).
# Evidence - Problem class: worker-background-git-commit-dies-unlanded-staged-tree - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-17T10:48:01.420Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "Signature (<project> tick #499, DAGGER-0185): a dispatched worker finishes its work, stages it (git status shows 'A' entries), writes its commit message to a file, launches `git commit -F <msg> -- <pathspec>` as a BACKGROUND terminal process, and then WAITS. The commit process disappears with no error surfaced, HEAD does not move, and the index still holds the staged entries; `git log` is unchanged and no .git/index.lock remains. Diagnose in this order, do NOT re-dispatch a worker and do NOT re-derive the work: (1) `git status --short` + `git log --oneline -1` - staged-but-uncommitted with an unchanged HEAD is this class, not a phantom-work class; (2) prove the guard is NOT the cause by running `gitreins guard` YOURSELF on the same staged bytes (expect secrets/build/lint/tests PASS) - if it passes, the commit death was process-level (the worker's background process was reaped when its tool session ended), not a gate refusal; (3) salvage foreman-side: reuse the worker's own message file (`git commit -F /tmp/<task>-commit.txt -- <staged paths>`), which preserves its measured evidence text; (4) verify content afterwards with `git show --stat HEAD` plus the per-criterion checks, then push and run the gitreins lifecycle (task complete -> Tier 2 judge) as normal. Related but DISTINCT: the orphaned-commit class (a still-running `git commit` holding index.lock that eventually lands by itself) - check `ps` for a live git commit process BEFORE concluding this class; if one is alive, wait instead of committing.", "environment": "", "language": "", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "worker-background-git-commit-dies-unlanded-staged-tree", "provider": "openrouter", "solved_at": "2026-09-17T10:48:01.421Z", "version": ""}