Problem
Ordinary OMP worker conversations are launched under the task's temporary runtime directory. If that temporary directory is removed by reboot cleanup or another cleanup path, an unfinished worker can lose the exact conversation needed to resume even while its isolated source copy and validation records remain. A second failure mode is a generic resume hint that omits the custom session directory, which reports a session missing even when the exact session file still exists elsewhere.
Observed behavior
The maintained Firstmate incident ledger records ordinary OMP sessions under a task temporary root and a later unfinished task with no usable recorded session directory. It also records a custom-session launch whose displayed omp --resume command searched the wrong namespace; invoking the exact session directory resumed the existing conversation.
Expected invariant
Until guarded cleanup after landing, every unfinished ordinary OMP worker has an exact durable session location and pointer. Recovery instructions resolve that pointer directly, never a default or guessed session namespace. Missing, malformed, or ambiguous session state is reported as a bounded refusal and is not silently recreated or discarded.
Evidence and causal boundary
- Current
main creates ordinary OMP sessions at bin/fm-spawn.sh:3204-3217, beneath /tmp/fm-<task>/omp-sessions, while the same temporary root is the cleanup unit.
- The launch template passes that directory and any resume file at
bin/fm-spawn.sh:3677-3700; ordinary workers do not use the durable project-home pointer path used by the persistent secondmate path.
- The incident ledger records the volatile placement and unknown deletion event at
data/firstmate-state-breakages.md:20-28 and the wrong-namespace resume hint at :50-58.
- The consolidated diagnosis separates the proven structural defect from the unknown remover at
data/firstmate-broken-state-diagnosis.md:15-27,41-58.
The proven causal boundary is Firstmate's ordinary OMP session placement and resume-pointer contract. The exact process or host policy that removed the originally missing directory remains unknown; reboot proximity is not proof of deletion cause.
Impact
A worker's source and validation custody can survive while its conversation becomes unrecoverable or appears missing. Operators may start an unnecessary replacement, lose context, or misclassify an operational persistence failure as lost work.
Relationship to existing work
This is not stale supervision advisory delivery (open issue #74), evidence-receipt validation (closed issue #57), inbox steering (merged PRs #68 and #71), remote lifecycle reporting (merged PR #70), or away-mode composer admission (open PR #72). PR #69 is superseded evidence and must not be revived. The current clean-commit worker relaunch repair provides a safe replacement path from an exact clean commit, but it does not make an unfinished ordinary OMP conversation durable, so it does not cover this issue.
Acceptance criteria
- Ordinary OMP sessions are stored in a durable, task-scoped private location that is not part of the temporary runtime cleanup root.
- Firstmate atomically records and validates one exact session pointer before the worker is considered ready; the pointer must name a direct session file within the approved directory.
- Firstmate's recovery or rendered resume instruction includes the exact session directory and file, and refuses missing, malformed, foreign, or ambiguous pointers without guessing.
- Failed recovery preserves the durable session and pointer; guarded cleanup retires them only after the existing landed-work and endpoint-closure proof.
- Existing persistent secondmate session safeguards remain unchanged.
Deterministic regression scenario
Launch a disposable ordinary OMP worker with a known custom session directory and exact session file. Remove only the task temporary runtime root, as a reboot/cleanup simulation. Assert the session file and pointer remain, the recovery command names that exact directory/file, and a relaunch resumes that session. Repeat with a missing pointer and with two retained session files; both cases must refuse without deleting or selecting either file.
Problem
Ordinary OMP worker conversations are launched under the task's temporary runtime directory. If that temporary directory is removed by reboot cleanup or another cleanup path, an unfinished worker can lose the exact conversation needed to resume even while its isolated source copy and validation records remain. A second failure mode is a generic resume hint that omits the custom session directory, which reports a session missing even when the exact session file still exists elsewhere.
Observed behavior
The maintained Firstmate incident ledger records ordinary OMP sessions under a task temporary root and a later unfinished task with no usable recorded session directory. It also records a custom-session launch whose displayed
omp --resumecommand searched the wrong namespace; invoking the exact session directory resumed the existing conversation.Expected invariant
Until guarded cleanup after landing, every unfinished ordinary OMP worker has an exact durable session location and pointer. Recovery instructions resolve that pointer directly, never a default or guessed session namespace. Missing, malformed, or ambiguous session state is reported as a bounded refusal and is not silently recreated or discarded.
Evidence and causal boundary
maincreates ordinary OMP sessions atbin/fm-spawn.sh:3204-3217, beneath/tmp/fm-<task>/omp-sessions, while the same temporary root is the cleanup unit.bin/fm-spawn.sh:3677-3700; ordinary workers do not use the durable project-home pointer path used by the persistent secondmate path.data/firstmate-state-breakages.md:20-28and the wrong-namespace resume hint at:50-58.data/firstmate-broken-state-diagnosis.md:15-27,41-58.The proven causal boundary is Firstmate's ordinary OMP session placement and resume-pointer contract. The exact process or host policy that removed the originally missing directory remains unknown; reboot proximity is not proof of deletion cause.
Impact
A worker's source and validation custody can survive while its conversation becomes unrecoverable or appears missing. Operators may start an unnecessary replacement, lose context, or misclassify an operational persistence failure as lost work.
Relationship to existing work
This is not stale supervision advisory delivery (open issue #74), evidence-receipt validation (closed issue #57), inbox steering (merged PRs #68 and #71), remote lifecycle reporting (merged PR #70), or away-mode composer admission (open PR #72). PR #69 is superseded evidence and must not be revived. The current clean-commit worker relaunch repair provides a safe replacement path from an exact clean commit, but it does not make an unfinished ordinary OMP conversation durable, so it does not cover this issue.
Acceptance criteria
Deterministic regression scenario
Launch a disposable ordinary OMP worker with a known custom session directory and exact session file. Remove only the task temporary runtime root, as a reboot/cleanup simulation. Assert the session file and pointer remain, the recovery command names that exact directory/file, and a relaunch resumes that session. Repeat with a missing pointer and with two retained session files; both cases must refuse without deleting or selecting either file.