fm-land: name the handoff path on rerun, and stop a spurious stderr diagnostic #20

Merged

john merged 3 commits from fm/fm-land-manifest-handoff-path into main

2026-08-30 05:35:13 +00:00

john commented

2026-08-29 13:47:07 +00:00

Owner

What was wrong

Two small, real faults in bin/fm-land.sh, split out deliberately so a bounded run could finish. Neither risks anything; both were quietly wrong every time the code ran.

1. The landing marker dropped the handoff paths on a push-only rerun. A rerun rewrote the manifest with handoff=already-landed, so the marker no longer named any worker's handoff path — directly contradicting its own "handoff paths + push outcomes" header. The path was known at that point and simply not printed. It now names the real path alongside the already-landed state, in the dry-run line too.

2. A spurious diagnostic reached the operator's stderr on every first landing. In the sentinel pid read, 2>/dev/null was applied after the failing input redirect, so bash's own "no such file" diagnostic still printed. The behaviour was correct — the function returned 1 and the sentinel launched — but the noise appeared on every first landing and looked like a fault. Reproduced standalone on bash 5.3; the redirect is now ordered before the input redirect.

The third change, from review

The review gate caught something worth keeping: the already-landed guard was vacuous — it could not fail, so it was not actually a check. That is fixed here too, rather than left as a passing assertion that proved nothing.

Tests

Both fixes have tests that fail against the pre-fix code, plus coverage of the guard. 63 lines added to tests/fm-land.test.sh against 8 changed lines of bin/fm-land.sh — the ratio is the point: these are behaviours that were silently wrong and had nothing watching them.

Note on how this was built

This ran on the local qwen38-rvn-local model. Worth recording honestly: it needed the exact edits spelled out before it produced anything — its first two attempts spent the whole 98k context window deliberating and changed no files. Once given precise instructions it did the work cleanly and even caught a third occurrence that had not been named. Useful data for how to route local work, not a complaint about the result.

## What was wrong Two small, real faults in `bin/fm-land.sh`, split out deliberately so a bounded run could finish. Neither risks anything; both were quietly wrong every time the code ran. **1. The landing marker dropped the handoff paths on a push-only rerun.** A rerun rewrote the manifest with `handoff=already-landed`, so the marker no longer named any worker's handoff path — directly contradicting its own "handoff paths + push outcomes" header. The path was known at that point and simply not printed. It now names the real path alongside the already-landed state, in the dry-run line too. **2. A spurious diagnostic reached the operator's stderr on every first landing.** In the sentinel pid read, `2>/dev/null` was applied *after* the failing input redirect, so bash's own "no such file" diagnostic still printed. The behaviour was correct — the function returned 1 and the sentinel launched — but the noise appeared on every first landing and looked like a fault. Reproduced standalone on bash 5.3; the redirect is now ordered before the input redirect. ## The third change, from review The review gate caught something worth keeping: the already-landed guard was **vacuous** — it could not fail, so it was not actually a check. That is fixed here too, rather than left as a passing assertion that proved nothing. ## Tests Both fixes have tests that fail against the pre-fix code, plus coverage of the guard. 63 lines added to `tests/fm-land.test.sh` against 8 changed lines of `bin/fm-land.sh` — the ratio is the point: these are behaviours that were silently wrong and had nothing watching them. ## Note on how this was built This ran on the local `qwen38-rvn-local` model. Worth recording honestly: it needed the exact edits spelled out before it produced anything — its first two attempts spent the whole 98k context window deliberating and changed no files. Once given precise instructions it did the work cleanly and even caught a third occurrence that had not been named. Useful data for how to route local work, not a complaint about the result.

john added 3 commits

2026-08-29 13:47:07 +00:00

fm-land: name the already-landed handoff path; quiet the sentinel pid read 883545ef0c

On a push-only rerun the manifest now prints the worker's real handoff
path (handoff=<path> (already-landed)) instead of dropping it, matching the
marker header that promises handoff paths plus push outcomes. And the
sentinel_alive pid read now applies 2>/dev/null before the input redirect so
the first landing's absent pid file no longer leaks a shell 'No such file or
directory' diagnostic to the operator's stderr (the read still fails closed,
so the sentinel still launches).

fm-land: name the already-landed handoff path in the dry-run line too f2a12ae631

Complete the manifest fix on the dry-run already-landed branch (line 600) so
it also names the worker's real handoff path, matching the real-run branch.
The dry-run output now reads handoff=<path> (already-landed) instead of a
bare token, keeping both branches consistent with the marker header.

no-mistakes(review): fix vacuous already-landed guard; document manifest suffix

CI / Test coverage guard (pull_request) Successful in 13s

Details

CI / Behavior portable parallel 2 (pull_request) Successful in 2m57s

Details

CI / Behavior portable parallel 1 (pull_request) Successful in 3m5s

Details

CI / Lint shell scripts (pull_request) Successful in 4m31s

Details

CI / Behavior portable serial 1 (pull_request) Successful in 13m38s

Details

CI / Behavior portable serial 4 (pull_request) Successful in 11m11s