PYR0D-338: Rebuild firstmate on the latest upstream, with our Forgejo, guard and workflow slices #37
Loading…
Reference in a new issue
No description provided.
Delete branch "fm/fm-rebuild-upstream-land"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Story: PYR0D-338 - Rebuild the firstmate fork on the maintainer's latest upstream
What was wrong
Our fork had drifted about 400 commits behind kunchenguid/firstmate while carrying its own changes: Forgejo delivery, loss guards, workflow rules and OMP. The earlier merge-everything attempt kept tangling upstream's rewrites with our patches. On 09/28 the captain chose D139 B: rebuild on the latest upstream and port only what we still need.
What changed
The branch takes upstream as the base and ports seven slices on top, one commit each, each with its tests, following the keep-list plan (D143 to D145):
.github/workflows/ci.ymlstays byte-identical.forge=forgejoadded to the delivery-forge axis, so workers on Forgejo projects report "pipeline passed, pushed" and firstmate opens the PR.bin/fm-land.sh, the quota-reset sentinel, and last-run telemetry for registered checks.config/startup-memory-budgeton the curated memory files and marks exact cut points.plane-first-recordskill), the imported skills, and the security playbook.Test hygiene commits keep the Herdr, Orca and spawn-mechanics suites off the new delivery guard. The no-mistakes review fixes cover check-sidecar cleanup on unregister, the read-once budget wording, and reverting formatter churn on upstream-owned files, so that upstream diffs stay minimal. The document step adds the Forgejo forge token and the check sidecar to the docs.
It lands as one history-preserving merge: no force push, and upstream's history is kept.
Decisions
What stays open
jq"argument list too long" failure at this home's size, if upstream has not already fixed it.Validation: the no-mistakes pipeline passed (review, test, document, lint) at
a9e08c56. Forge CI runs on this PR.* fix(hooks): keep tracked Claude entries inert under grok 1.0.0 hooks Grok loads Claude-compatible settings, so the tracked `.claude/settings.json` hook entries also fire under Grok. They were meant to be inert there, guarded by `[ -z "${GROK_AGENT:-}" ] || exit 0`. That guard silently stopped working. Verified from the live process environment of a wedged grok 1.0.0 Stop hook on 2026-08-07: a grok 1.0.0 HOOK process carries GROK_HOOK_EVENT, GROK_HOOK_NAME, GROK_SESSION_ID, and GROK_WORKSPACE_ROOT, but no GROK_AGENT. The observed hook process was labelled `GROK_HOOK_NAME=project/settings:stop[0].hooks[1]`, which is the Claude-only auto-arm entry. Consequence: Grok ran `bin/fm-claude-stop-autoarm.sh` synchronously. Grok has no `asyncRewake`, so it waited on the foregrounded watcher for that entry's declared 28800-second timeout and the Grok turn never ended - the operator saw an infinite "Responding". Widen the guard to `[ -z "${GROK_AGENT:-}${GROK_HOOK_EVENT:-}" ] || exit 0` on the five entries that have a `.grok/hooks/` counterpart: both Stop entries, the SessionStart entry, and the two PreToolUse Bash entries. Two deliberate limits: - The guard is NOT widened to GROK_SESSION_ID. Grok injects it into every child process, so it can survive into a Claude session that Grok launched and would silently disable Claude's own watcher continuity. GROK_HOOK_EVENT is per-hook-invocation and does not leak that way. - `bin/fm-subagent-pretool-check.sh` stays unguarded on purpose. It is the one tracked entry with no `.grok/hooks/` counterpart, so guarding it would remove the guard from Grok entirely rather than deduplicate it. The new test asserts it stays unguarded so the exception cannot be closed silently, and docs/subagent-guard.md is honest that the coverage it leaves is partial. `bin/fm-harness.sh` corrects a comment that presented GROK_AGENT as reliably present; it is a fast path only, and the ancestry walk is what actually guarantees grok identification. tests/fm-turnend-guard.test.sh adds test_tracked_claude_entries_inert_under_grok, which runs every tracked entry under a real grok 1.0.0 hook environment, a legacy GROK_AGENT environment, and a native Claude environment. * no-mistakes(document): docs: sync grok hook-marker guard facts to owners * no-mistakes(review): docs: state grok guard criterion by event coverage* fix(bin): strip every bracket tag, not just [key=...], from a status verb status_line_verb only stripped a leading "[key=...]" token before the colon, so a remote secondmate reply's leading "[corr=...]" correlation tag stayed glued onto the returned verb word ("needs-decision [corr=...]" instead of "needs-decision"). The open-decisions fold's verb match then silently failed to recognize the line at all, so fm-send --resolve-key refused to close a decision that was plainly open on the status line. Generalize the parser to strip every "[name=value]" tag before the colon, in any order and count, so local and remote replies fold identically. * no-mistakes(review): Invalidate stale decision cursors after parser fix * no-mistakes(document): Clarify status metadata verb parsing* feat(calm): add a max presentation level that hides mid-turn working notes Calm's home-local preference becomes a three-state level instead of a boolean: "off" is stock Pi, "on" is today's Calm, and "max" is Calm plus hiding the assistant text of messages the model did not end its response with. `/calm max` selects it from any state, a plain `/calm` steps max back to ordinary Calm and otherwise keeps the existing on/off cycle, and any other argument keeps that cycle too. `config/calm` now persists "max" as its own literal value, so a session start, resume, fork, or reload restores the stored level rather than treating it as unrecognized and dropping to off. The hide rule keys on Pi's intrinsic per-message stopReason: "toolUse", or "length" with tool calls present. Streaming ("pending") text is never filtered, because suppressing it would also stop a genuine reply from streaming. The existing assistant layout adapter filters the blocks out of the same shallow presentation copy it already uses for collapsed thinking, so the message, model context, session storage, /export, and delivery are untouched and a hidden mid-turn row collapses to zero height. The new "assistant-working-note" class keeps that choice in the visibility policy owner, where ordinary Calm keeps it visible. * no-mistakes(document): Clarify Calm max persistence and taxonomy* feat(calm): make hiding mid-turn working notes the ordinary Calm state Calm collapses back to the two-state on/off toggle it was before the max presentation level, with max's hide rule promoted into ordinary Calm. Calm on now hides mid-turn assistant working notes in addition to what it already hid, and the /calm command parses no argument again. The hide rule itself is unchanged: assistant text is removed from the shallow presentation copy when the message's own stopReason is "toolUse", or "length" with tool calls present. Streaming ("pending") text is never filtered, so a genuine reply still streams. The message, model context, session storage, /export, and delivery remain untouched. config/calm persists only "on" and "off" again, but the reader still maps a persisted "max" to on so a home upgraded from the removed level keeps Calm on instead of dropping to off. The mid-turn hide is now default behavior rather than an opt-in level, so docs/calm.md documents it for users, docs/configuration.md records the two written values plus the legacy max mapping, and the feasibility taxonomy drops its level-scoped wording. * no-mistakes(document): Document ordinary Calm working-note hiding* feat(checks): report tool updates that are available or installed but inert Firstmate had no way to notice that tooling this home depends on needs an update, and no way at all to notice the worse case: an update that installed correctly and then did nothing. That second case is why this exists. A tool that self-installs into ~/.local/bin while a version manager keeps its own older copy earlier on PATH looks completely up to date to anything that asks only "is a newer version published". On 2026-08-20 a Herdr update landed at 0.8.2 while an older 0.8.0 copy stayed earlier on PATH, so every Herdr command failed on a protocol mismatch and firstmate could not read its own fleet. bin/fm-tool-update-check.sh reports the two conditions separately: <tool> update available a newer version exists at the update source. <tool> update not in effect a newer copy is installed on this host, but PATH still resolves an older one. PATH skew is measured, never inferred. Every executable copy of a watched command on PATH is asked for its own version and those answers are compared, so one lookup cannot hide the skew, and a directory name is never read as a version because a version manager's "latest" directory can hold an older build. A copy that will not report a version is a check failure, not a pass. The watched tools live in local, gitignored config/watched-tools.json, so adding a tool is a config edit rather than a code change, and the file is never propagated to another home. Update sources cover both shapes: a local clone's commit distance from its remote branch, and a command's own version and update announcement, including a tool like no-mistakes that prints its version on one command and announces a new release on another. The check prints one line when something needs attention and prints nothing otherwise, so it rides the existing watcher state-check contract with its trust binding instead of introducing a schedule of its own, and state/.tool-updates keeps the same pending update from being reported on every poll. The check only reports. It never installs, updates, reorders PATH, touches a version manager, or fetches into a watched repository; every git probe is read-only. Tests cover the skew case as a regression, and it was verified by mutation: removing the skew report, or stopping after the first PATH hit as a single lookup would, each make that test fail. * no-mistakes(review): fix tool update check probe reporting, budget, and shim write * no-mistakes(review): keep sweeps alive on broken patterns and oversized budgets * no-mistakes(review): roll back failed arm, widen budget clamp, bound repo probe * no-mistakes(review): guard git probes at the budget, record uncut findings * no-mistakes(document): fix stale watched-tool report-record wording in docs and header * no-mistakes: apply CI fixes * no-mistakes: apply CI fixes * no-mistakes: apply CI fixes * no-mistakes: apply CI fixes * no-mistakes: apply CI fixes The behavior shard's watch-triage suite failed on the new worktree-write wedge tests. Those five tests are the only ones in the file that do not use its standard waits. They give a fixed 3 second liveness budget to the one poll that now spawns the bounded worktree walk, and 4 seconds to an escalating watcher where every other test in the file gives 10. On a loaded runner that poll outlives the fixed budget, so the round is reaped before the deferral it asserts on is recorded, and the test reports a lost deferral instead of the deferral under test. Wait for a completed poll cycle through the file's own wait_poll_cycle, which is what its header documents this hazard for, and use the file's standard 100 tick exit budget. Verified against a load that reproduces the failure: 11 of 12 runs failed before, 8 of 8 pass after. Verified by mutation too, so the waits still prove the behavior: removing the write deferral, and keeping a finished deferral chain across an idle-timer repair, each still fail their test.* feat(bin): merge GitLab merge requests through the guarded PR merge path bin/fm-pr-lib.sh already parses a GitLab merge request URL for the watcher, but bin/fm-pr-merge.sh refused every non-github provider, so a merge request had to be merged by hand and got none of the recording, guards, or audit trail a pull request gets. The merge path now dispatches on the parsed provider. A GitHub URL keeps its exact previous behavior. A GitLab URL is addressed through glab by the project URL rebuilt from the parsed host and path, so a merge request on any instance resolves and no host is hardcoded, and no merge-method flag is added because the project's own merge method is what should apply. A GitLab merge happens only after one live read of the merge request confirms it is open, detailed_merge_status is mergeable, has_conflicts is false, blocking_discussions_resolved is true, and the head pipeline succeeded at the exact current head. Every failing condition is reported, not just the first. The verified head is bound to the merge with glab's --sha, so a push landing between the read and the merge fails the merge instead of landing commits nothing verified. Recorded metadata is never the authority for any of this: a rebase moves the head and leaves a recorded value stale, so a recorded head that disagrees with the live one is reported rather than trusted, and the recorded value is read before the recording step because that step drops a GitLab head it cannot resolve. * no-mistakes(review): reject bundled -R clusters and make tool-absence cases host-independent * no-mistakes(test): state authorised GitHub narrowing of bundled -R guard This branch NARROWS GitHub behaviour. The narrowing was authorised deliberately rather than slipping in by accident, and it applies to both providers, GitHub and GitLab alike, because a script that guards one provider and not the other is a trap for the next reader. What bin/fm-pr-merge.sh now refuses is extra merge arguments containing a bundled short-option cluster that includes R, for example "-dR other/repo". The forge CLIs expand such a cluster one character at a time, so it carries "--repo other/repo", and that later value wins over the repository the URL named. Before this change, "fm-pr-merge.sh <task> <github-url> -- -dR other/repo" reached "gh-axi pr merge 12 --repo example/repo --squash -dR other/repo" and exited 0 with pr= recorded and the merge poll armed. It now exits 1 with "extra merge arguments must not override the repository", records nothing, and invokes no forge merge command. Every other GitHub invocation is byte-identical to the base commit. Closing that hole honours the existing rule rather than departing from it. The file header already forbids --repo and -R because the repository must come only from the URL, so a bundled cluster carrying a repository override was never legitimate behaviour to preserve: it was that guard being evaded. Redirecting a merge to a repository the URL does not name is exactly what the guard exists to prevent. The refusal is already pinned on both paths by the existing case test_bundled_repo_override_args_refuse_before_recording in tests/fm-pr-merge.test.sh. On GitHub ("-dR wrong/repo") and on GitLab ("-yR https://other.example/g/p") it asserts exit 1, the refusal wording, no pr= in the task meta, no armed merge poll, and no forge merge command invoked, with a control case proving a cluster that carries no repository override still reaches the forge. No duplicate assertion was added. Both assertions were confirmed to have teeth by narrowing the guard back to a bare -R and watching each path fail. This commit carries no file change: the guard and its coverage landed in 614853d, and this message exists so the pull request description states the narrowing. * no-mistakes(document): fix README pointer for GitLab watch and merge doc * no-mistakes: apply CI fixes* fix(procevent): retry a transient Lavish poll interruption quietly A live Lavish listener can be cut short by the server with exactly error: Lavish Editor poll response was interrupted code: SERVER_ERROR while the session's marks remain available. Firstmate registered raw `lavish-axi poll` output, so the generic process-event runner captured that transient response as a result and woke the whole fleet over what is really an internal retry. The Lavish adapter now registers its own listener command, which reruns the published blocking poll up to 12 times at 5 second intervals for that one exact two-line response. The match is deliberately narrow: real feedback, ended and missing sessions, any other SERVER_ERROR, and the same interruption still standing once the bound is spent all pass straight through and are captured and announced as before. The retry is a Lavish fact, so the generic runner stays adapter-agnostic. `FM_LAVISH_POLL_RETRY_DELAY` is a bounded 0 to 60 second override for the interval only, refused rather than rounded when malformed, so a test can exercise the real bound without waiting it out. * no-mistakes(review): Harden Lavish retry matching, validation, and cleanup * no-mistakes(review): Bound Lavish retry staging and stabilize regression * no-mistakes(document): docs: explain Lavish retry adoption * no-mistakes(lint): Restore Lavish trap ShellCheck suppressionThe unguarded Herdr declaration quoted `{TASK}` in its own prose while the scaffold instructs firstmate to replace every `{TASK}` placeholder. The documented global replace therefore spliced the whole task body into the middle of the safety gate's sentence, silently destroying the one contract that exists precisely because the scaffold cannot inspect the task text. Reword the gate to refer to the task text filled in above, leaving the placeholder only at its genuine fill site. Rewording rather than renaming the token keeps the unfilled-charter guards in fm-home-seed.sh and fm-remote-home-seed.sh working unchanged. Add a regression test that performs the documented global fill on ship and scout scaffolds and asserts the body lands once and the gate survives.The writer lock's stale-lock branch read the lock's mtime with `stat -f %m ... || stat -c %Y ...`. On GNU coreutils `-f` is filesystem stat, so it consumed the format string as a path, complained on stderr, printed a partial filesystem dump (" File: ...") on stdout, and still exited 0. The GNU form in the fallback therefore never ran, and the following arithmetic evaluated the word `File`, aborting the writer under `set -u` with "File: unbound variable". fm-teardown.sh died there after returning the worktree, leaving state/<id>.meta, .status, .busy-gen, .busy-state, .busy-state.lock/ and .turn-ended behind. The surviving metadata kept the watcher monitoring an endpoint whose agent was gone, so a finished task produced stale wakes forever, and every re-run died identically because the abandoned lock was never broken. Detect the platform once and pick the right stat form, the pattern bin/fm-watch.sh already documents, and treat any non-numeric result as "just created" so a future portability surprise degrades to a lock-timeout refusal rather than killing teardown mid-way.* fix(tests): make the changed-file map select per script and stabilize a budget flake The changed-file map's bin/ fallback resolved a direct test reference to that test's whole FAMILY. bin/fm-push-transition-lib.sh is named by exactly one real-Herdr E2E, so a one-line change to it selected all 12 real-herdr-gated scripts, including a 341s presentation E2E with no dependency on it. Resolve direct test references per script, and keep resolving consumer bin/ scripts through the curated map so recorded family-level coupling survives. Also fix a load-sensitive flake: the tool-update budget deadline is whole-second granular, so a test budget of 1 left headroom anywhere in (0, 1] seconds and the first budget check could already read as exhausted. * feat(bin): make suite wall clock a result and let a family's concurrency be proven --max-wall-ms fails a run whose wall clock exceeds the caller's budget, after reporting the per-script results. A suite that stays green while outgrowing its caller's invocation budget is the regression that got an agent killed mid-run and retried invisibly, so duration has to be a result rather than a log note. --pool on the isolation-proof harness runs the same concurrent proof over a whole family, so 'is this family safe to parallelize?' is answered by a command instead of a guess. Measured watcher-wake-lock and refused it: 3 of 18 scripts fail under concurrency on wall-clock assertions about reaching the next poll. * perf(bin): schedule the changed suite concurrently, longest first The watcher-wake-lock family is proven concurrent-safe (two clean runs, 18 candidates, 0 failures at 4 workers; docs/fm-test-isolation-proof.md), so --changed now schedules its proven-concurrent scripts with bounded parallelism and runs any unproven remainder serially afterwards, never beside them. Concurrent runs are ordered longest-hint-first. Workers are handed scripts in order, so alphabetical order started the 193s fm-watch-triage last and stranded it running alone: 395s wall against a 205s balanced four-worker sum. An explicit --jobs keeps its strict refusal, so every CI lane is unchanged. * fix(bin): bound a hung test instead of letting it hang the suite tests/fm-calm-pi-extension.test.sh was observed running 17+ minutes against a 464ms recorded hint, and the suite had no per-script bound to stop it. An unbounded suite is precisely what silently outruns a caller's invocation budget, and --max-wall-ms is evaluated after the run so it cannot end one that never finishes. --per-script-timeout-secs terminates a script that outruns it and records exit 124, so the run still completes, accounts for the script, and fails. The auto-concurrent --changed path applies 900s, far above the slowest real script (the 341s Herdr presentation E2E), so it only ever converts a hang. * no-mistakes(review): Enforce safe concurrency and descendant timeouts * no-mistakes(review): Validate empty runs and isolation proof pools * no-mistakes(review): Measure selection time in wall budget * no-mistakes(review): Reap interrupted workers and bound finalization * no-mistakes(review): Contain shutdown descendants and watchdog finalization * no-mistakes(review): Honor remaining budget and close launch races * no-mistakes(review): Restore timeout helper and simplify runner cleanup * no-mistakes(review): Record isolation pool admission metadata * no-mistakes(review): Bound Chrome reap and scope proof admission * no-mistakes(review): Align proof scheduling and preserve budget summaries * no-mistakes(review): Remove unreliable finalization watchdog * no-mistakes(review): Freeze budget duration and enforce admission caps * no-mistakes(document): Refresh test runner concurrency documentation * no-mistakes(lint): Fix ShellCheck findings in test runner scripts * no-mistakes(ci): Fixed Greptile’s concurrency-consent finding. `--changed` now remains serial by default; `--changed --jobs auto` explicitly opts into bounded concurrency and the automatic hang timeout. Updated documentation and added behavioral coverage proving serial default behavior, explicit concurrent scheduling, and refusal of `--jobs auto` outside `--changed`. Verified with `bash tests/fm-test-run.test.sh`, `bin/fm-lint.sh`, and `git diff --check` * no-mistakes(review): Restore automatic changed-suite concurrency and timeout * no-mistakes(review): Correct changed-suite contributor guidance * no-mistakes(review): Reject gate-skipped isolation proofs * no-mistakes(review): Correct automatic concurrency evidence * no-mistakes(review): Isolate nested runner process groups * no-mistakes(review): Remove unreliable signal cleanup machinery * no-mistakes(test): Narrow changed-suite selection to executable contract owners * no-mistakes(document): Document isolation proof skip and artifact semantics * no-mistakes(ci): Fixed Greptile’s concurrency-consent finding. `--changed` now remains serial by default; bounded concurrency requires explicit `--jobs auto`. Updated behavioral coverage, contributor guidance, and isolation-proof commands accordingly. Verified with `tests/fm-test-run.test.sh`, `bin/fm-doc-audience-check.sh`, `bin/fm-lint.sh`, Bash syntax checks, and `git diff --check`; all passed * no-mistakes(review): Restore plain changed-suite automatic concurrency * no-mistakes(review): Record resolved changed-suite worker count * fix(bin): keep a runner change selecting its whole curated family A pipeline fix round narrowed the curated changed-file map so bin/fm-test-run.sh and bin/fm-test-isolation-proof.sh selected only their own two contract tests, and the documentation surfaces only the audience test. That cut this branch's own changed selection from 33 scripts to 5. The runner executes every pure-contract-unit script, so its contract test passing proves its logic is right, not that the suite it drives still runs. Narrowing it also makes any wall-clock claim about the changed suite trivially true by not running the work. Only the unmapped bin/* grep fallback resolves per script; curated mappings keep their recorded family coupling. * perf(bin): admit the pure-contract-unit family to bounded concurrency A runner-file change selects pure-contract-unit, so that family decides the changed suite's wall clock. With only watcher-wake-lock admitted, 14 of its 33 selected scripts fell to the serial tail and the selection measured 327.3s against a 300s budget: the concurrent group was 19 scripts totalling 273.4s while the tail alone was 215.7s. bin/fm-test-isolation-proof.sh --pool pure-contract-unit --jobs 4 passes twice, 32 candidates, 0 failures, so the family is admitted on recorded evidence. Full 33-script plain --changed: 327.3s -> 181.8s / 178.5s / 172.7s, 0 failures, inside a 300000ms budget. Also states the per-script guard's derivation. * no-mistakes(review): Align contract-unit concurrency cap with recorded proof * no-mistakes(document): Record final changed-suite performance evidence * fix(bin): keep an empty changed selection clean on stock macOS Bash Under set -u, bash 3.2 treats "${arr[@]}" on an EMPTY array as an unbound-variable error, while bash 4.4+ makes it a harmless no-op. The concurrency work removed the early exit for an empty selection, so execution fell through to the unguarded existence loop: on stock /bin/bash 3.2.57 a contributor who changes only documentation and runs --changed got bin/fm-test-run.sh: line 1713: SCRIPTS[@]: unbound variable with exit 1 and no summary, instead of a clean total=0 pass. Restore the early exit, and guard every remaining array expansion reachable with an empty selection. The reported duration is real elapsed invocation time rather than a hardcoded zero, so a selection phase that outran --max-wall-ms still fails. Verified on this host with /bin/bash 3.2.57: exit 1 with the unbound-variable error before, exit 0 with FM_TEST_SUMMARY total=0 after. * no-mistakes(document): Document shell-bound changed-suite performance --------- Co-authored-by: Kun Chen <kun-1@kunchenguid.com>* Fix public-followup register crashing on empty lock arrays under bash 3.2. bash 3.2 with set -u treats "${arr[@]}" on an empty array as unbound, so the first register in a fresh home aborted before taking the registry lock. The empty-lock regression also runs under the existing stock macOS Bash CI lane so pre-fix code would fail there. * no-mistakes(document): Document stock Bash registration coverage * no-mistakes(ci): Pinned the stock macOS Bash CI lane to tasks-axi@0.2.5, eliminating dependency drift. Verified workflow YAML parsing, git diff checks, and the focused regression under /bin/bash 3.2.57 with tasks-axi 0.2.5 * no-mistakes(ci): Fixed the flaky portable CI test: it treated exited zombie processes as live because `kill -0` succeeds for zombies. The watcher and descendant assertions now check process state and regard zombies as exited. Verified `tests/fm-pr-check-security.test.sh`, ShellCheck, `git diff --check`, and the focused Bash public-followup regression* fix(bin): resolve process-event state roots before validating them The process-event module validated the caller's spelling of a home's state root instead of the directory it operates on: it required the supplied path to equal its own lexical normalization, which rejects any path reached through a symlinked ancestor. On macOS both /tmp and $TMPDIR are symlinks, so an operator home under either could never claim a source. Reconcile still reported the runner started, while the detached runner died writing "cannot claim source" to the discarded stderr, and the source silently never fired. Resolve the state root to its physical directory once, then apply the existing private-directory validation to that resolved directory and derive every path, recorded claim identity, and later confinement check from it. This keeps the confinement contract for the directory actually operated on rather than only for callers that already spelled it physically, and removes the window where an ancestor symlink could be repointed between check and use. Homes already spelled physically behave identically. This was the single cause of both deterministic macOS failures in tests/fm-procevent.test.sh ("reconcile never claimed the registered source") and tests/fm-procevent-when.test.sh ("the winning concurrent arm did not produce an outcome"). The new case pins the behavior with an explicit symlinked-ancestor home, so it fails without the fix on any platform rather than only where the temp root happens to be a symlink. * fix(bin): pin the external capture staging boundary to its physical path The extension capture path pinned its registry staging boundary by comparing `pwd -P` against the caller-spelled registry directory, so a home reached through a symlinked ancestor still refused to start an extension-backed source after the state root itself resolved correctly. That left such a home half working: built-in sources ran while external ones failed. The staging preparer now prints the physical registry directory it validated, matching the inbox and reservation preparers beside it, and the start path pins on that returned path. The new end-to-end case drives the shipped file-signal package from a symlinked home spelling. * no-mistakes(review): Propagate canonical process-event state roots * no-mistakes(review): Propagate canonical state to process-event adapters * no-mistakes(document): Document physical process-event state roots* fix(bin): never close a captain call during cleanup A scout that held its own work item for the captain, which is what captain-hold-lifecycle prefers ("hold the work item the question gates"), was closed by bin/fm-teardown.sh's automatic backlog transition. The completion gate passed, cleanup ran, and the captain's question moved to Done with no recorded answer: the one thing the policy says must never happen. `tasks-axi done` closes a held row silently, and nothing in teardown asked whether the row was the captain's own call. bin/fm-captain-hold.sh gains the read-only `open` predicate: exit 0 when the task is still an open captain call, 1 when it is not, 2 when that cannot be established. It reads the row through the transition library's backend-aware probe, so it addresses the same backlog teardown does; the script's other commands now address the configured data directory the same way instead of FM_HOME, which also fixes captain holds in a home with a relocated data directory. Teardown asks `open` before any destructive step and refuses on 2. On 0 only the close changes: after cleanup and still under the task's own lock, the row gets one "Deliverable of the finished work" line at the end of its body and returns to Queued through `tasks-axi reopen`, keeping its hold, so it lands in Captain's Call instead of reading as work under way. --force does not lift this: it authorizes discarding unlanded work, never the captain's question. The deliverable goes into the body because `tasks-axi update --report` rewrites the title of a row that is not Done. The crash window reuses the pending-close record teardown already stages: a `mode=retain` line makes the existing replay record the deliverable and reopen instead of closing, with the same validator, stale-generation check, cleanup-incomplete marking, and non-blocking bootstrap lock as an ordinary close. A retained row the captain answered first simply retires the record. No parallel record type, recovery command, or second bootstrap loop is introduced. Regressions run the real executables: the captain-held scout survives cleanup queued, held, with its deliverable and on the board, only `answer` closes it, --force keeps it open, and an ordinary scout still closes with its report; an interrupted cleanup leaves the row untouched and the next session start retains it; a relocated backlog keeps the retention in its one configured file; and a ship row whose hold cannot be read refuses cleanup before anything destructive. Claude-Session: https://claude.ai/code/session_01FqdTiHCwTqrAQrz8K2y4Np * no-mistakes(review): Serialize captain holds and fix backend-aware listing * no-mistakes(document): Update captain-call retention documentation * no-mistakes(document): Fix relocated captain-hold backlog diagnostics* fix(bin): disable Claude's feedback-draft flow for fleet-launched agents Scope --settings '{"feedbackDrafts":"off"}' to every Firstmate-launched Claude crewmate and secondmate, so /bug and /feedback never queue or submit a bug report on the captain's behalf. feedbackDrafts is the documented settings key (Claude Code changelog 2.1.247); the per-launch CLI flag never touches the captain's global settings.json. Claude-Session: https://claude.ai/code/session_01XYAXXzr4oZx9NjZb1veeE3 * no-mistakes(review): Prevent managed settings from re-enabling Claude feedback drafts * no-mistakes(document): Fix Claude feedback documentation formatting * fix(bin): layer both feedback-draft controls for defense in depth The prior --settings-only fix can be overridden by a managed Claude settings policy (feedbackDrafts precedence). Keep CLAUDE_CODE_SEND_FEEDBACK=0 alongside --settings '{"feedbackDrafts":"off"}': either control alone disables the SendFeedback tool, so a managed override of one still leaves the other in force. Claude-Session: https://claude.ai/code/session_01XYAXXzr4oZx9NjZb1veeE3 * no-mistakes(document): Document Claude feedback-draft suppression ownership* fix(bin): close legacy records on the Beads backend honestly Two pre-Beads reads blocked honest closure of leftover records: 1. fm-captain-hold.sh complete/verify resolved attested legacy hold ids only against the live backend and the pre-collapse derived identity, so a home whose holds fm-hold-migration rehomed under fm- ids failed with an empty-name absence message (the resolve failure was swallowed by the command substitution feeding verify_hold_durable). Resolution now falls back, on the Beads backend only, to the legacy id under the configured beads prefix and to the row whose notes carry the exact marker line 'migrated from data/backlog.md id <legacy id>'; every refusal names the id it could not resolve, and the markdown path is unchanged. 2. fm-teardown.sh refused any record without spawn_gen forever. A record that predates the field can now be torn down with an explicit --legacy-record flag once the recovery-grade endpoint classifier confirms the recorded endpoint dead or agent-less; the accepted incarnation is stamped into the record right before its close marker binds to it and named in the teardown line. Refusals leave the record byte-identical, the unlanded-work refusal is not relaxed, and a corrupt (multi-valued) spawn_gen is never accepted. The companion repair this branch carries (follow-up commit) is the backend-gated --file and markdown-file requirement in the mutate path and lifecycle gates: fm_backlog_mutate passed --file and required the markdown backlog file regardless of the resolved backend, and the transition gate plus row probe required that file before any backend work, so a home on a non-markdown backend could neither gate, probe, nor close its rows. Behavior tests: self-contained beads fixtures over a scratch bd graph (self-skipping on markdown-only tasks-axi installs), legacy meta fixtures for every teardown gate, and the relocated markdown backlog coverage stays green. * no-mistakes(review): fix(review): report migrated-hold scan refusals and guard legacy spawn_gen stamp against newline-less records * fix(backlog): address the configured backend for lifecycle writes Completes the fm-backlog-transition-lib repair the first commit's message claims: on this base fm_backlog_mutate passed --file and required the markdown backlog file regardless of the resolved backend, and fm_backlog_transition_applies plus fm_backlog_row_probe required that file before any backend work, so a home on a non-markdown backend could neither gate, probe, nor close its backlog rows. All three now gate the markdown file on the resolved tasks-axi backend: markdown keeps exactly its explicit <data>/backlog.md behavior, non-markdown homes address the backend their own configuration selects with no markdown file requirement. fm_backlog_row_show and fm_backlog_row_list already gated correctly and are unchanged. docs/configuration.md owns the contract line. Also extends the same backend gate to fm-captain-hold.sh's own mutation wrapper - hold/add/update/answer/done append the markdown --file only when the resolved backend is markdown, so a captain call on a Beads home reaches the Beads store end to end - and applies the review round's two direct remedies there: the [beads] graph path resolves against the backlog root when relative (never the process CWD), and a failed bd graph read reports bd's own trimmed stderr reason in the refusal. Coverage: tests/fm-backlog-atomicity.test.sh gains a stub-driven Beads completion case proving the transition gate applies, the row probe reads, and done runs without any markdown file or --file override; the relocated markdown backlog test stays green. * no-mistakes(review): Document root-tasks.toml-only beads settings for migrated-hold resolution * test(gotmp): stub fm_tasks_axi_backend so the fixture matches the backend-aware transition lib The legacy-records change made fm-backlog-transition-lib.sh resolve the configured backend via fm_tasks_axi_backend before the markdown-only skip. The gotmp fixture's fm-tasks-axi-lib stub lacked that function, so the markdown check fell through and teardown hit the incompatible-backend error with unbound FM_TASKS_AXI_MIN under set -u. Stub the backend as markdown and define the floor, restoring the intended no-backlog skip. * fix(teardown): roll the legacy stamp back when the close marker fails A legacy-record teardown stamps its accepted incarnation into the record right before the close marker binds to it; when that marker write then fails, the stamp survived, so a retried teardown sailed past the dead-or-agent-less endpoint gate the stamp now proved unnecessary. The failed marker write now truncates the record back to its exact pre-stamp bytes (verified by size), restoring the byte-identical-refusal invariant; when the rollback itself fails the operator is told to re-run with --legacy-record after reconciling the endpoint. Also completes the recorded review decision's coverage wording: the beads stub test now drives the answer close end to end (update and done through the gated wrapper), asserting no markdown file override reaches either verb. * fix(review): harden the legacy stamp rollback and resolve derived migrated ids The legacy-record stamp rollback now uses perl (already in the teardown curated PATH; truncate is not, and is absent on stock macOS), routes every failure branch inside the stamp block through the same size-verified rollback so the byte-identical-refusal invariant holds on those paths too, and gains behavior coverage: an unrecordable close (an invalid pr= link) fails the teardown, leaves the record byte-identical, keeps the backlog row in flight, and a flag-less retry still refuses. Migrated-hold resolution now probes the derived pre-collapse identity (<origin>-decision-<entry>) alongside the raw entry - fm-hold-migration recorded the DERIVED id in every migrated row's marker note - in both the prefix and the migration-note forms, with the ambiguity refusal naming every identity tried, plus behavior coverage for a bare decision key resolved through its derived identity's marker. Also aligns fm-backlog-transition-lib.sh's header ADDRESSING/SCOPE paragraphs with the backend-gated contract, drops an unreachable FORCE validity guard the parser rewrite left behind, and switches the new stub fixture to the portable sed -i.bak idiom. * no-mistakes(review): Name the configured backend in teardown's backlog reminder * no-mistakes(review): Scan migration markers before the prefix guess * no-mistakes(review): Document marker-first resolution and cover the prefix branch * no-mistakes(document): Record prefix-attestation audit and marker-line forms * no-mistakes(ci): Fixed the Greptile P1 on bin/fm-teardown.sh: a failed rollback of the synthetic legacy stamp let a retry bypass the dead-or-agent-less endpoint gate. Root cause: teardown minted `spawn_gen=legacy-<ts>-<pid>` into the task record before the close marker bound to it. When the close-marker write failed AND the rollback also failed, the record retained that token. On the next invocation `fm_backlog_meta_spawn_gen` succeeded, so `TEARDOWN_LEGACY_PENDING` stayed 0 and the endpoint gate was skipped entirely — even with `--legacy-record`. The script's own error text told the operator to "re-run teardown with --legacy-record", advice the code could not honor. Fix (bin/fm-teardown.sh): - A `legacy-*` spawn_gen is now recognized as a stamp this teardown path minted, never one a spawn published (fm-spawn.sh publishes `s<epoch>.<pid>.<random>`). Such a record still reads as the legacy record it is: it re-enters the endpoint gate, and a flag-less retry refuses naming `--legacy-record`. - Acceptance reuses the retained token instead of minting a second one; the append block is skipped when the record already carries it, so no duplicate spawn_gen is written. - The rollback attempt and its "could not be rolled back" message are guarded to runs that actually appended a stamp, so a run that appended nothing never claims a rollback it did not perform. - Usage header documents the retained-stamp rule. Test (tests/fm-teardown.test.sh): added `test_retained_legacy_stamp_still_faces_the_endpoint_gate`, an end-to-end reproduction — a `perl` stub that fails only the rollback's `truncate` (delegating every other perl call to the real interpreter) leaves the stamp behind, then the retry must still hit the gate, must not stamp a second incarnation, must not close the backlog row, and the flag-less retry must refuse. Verification: the new test fails against the pre-fix script on exactly the reported defect ("the retry skipped the dead-or-agent-less endpoint gate") and passes after. Full tests/fm-teardown.test.sh 80 ok / 0 failures / rc=0; tests/fm-backlog-atomicity.test.sh 80 ok / 0 failures / rc=0; bin/fm-lint.sh (pinned ShellCheck 0.11.0 + actionlint 1.7.12) clean* fix(spawn): keep the worktree poll from adopting the repository primary After `treehouse get` is sent, the worktree-discovery poll reads the pane's foreground-process cwd. While treehouse is still fetching and checking a slot out, the foreground process is treehouse itself and it reports the repository's PRIMARY checkout as its cwd for several seconds. The poll accepted any path that merely differed from the spawning project, so from a linked spawning home - whose project is itself a worktree of that repository - it adopted the primary, and the isolation guard then refused a launch whose slot treehouse went on to create normally. Screen every candidate with the isolation guard's own conditions, extracted as spawn_worktree_isolated, so a read the guard would reject stays a transient the poll keeps waiting through. The two-consecutive-reads rule and the guard as final backstop are unchanged; a pane that never reaches an isolated worktree still fails at the existing 60s deadline, now naming the last path it reported. The already-settled timing assertion counted whole-spawn wall time against a 5s budget and failed on unmodified HEAD on slower machines; it now counts pane reads, which is what "one confirming read, not an extra cycle" actually means. * fix(spawn): say which path the worktree wait rejected, and why Screening every discovery-poll candidate means a host that never reaches an isolated worktree spends the whole 60s window before refusing. That wait is deliberate - separating a transient from a terminal misconfiguration needs machinery this path does not want - so the refusal explains itself instead: the isolation check records why a candidate failed, and the deadline names the last path seen together with that reason. Message and diagnostics only; the poll's control flow is unchanged. Two suites asserted the guard's wording on paths the poll now rejects rather than adopts, so their refusal arrives from the deadline instead: realign fm-tangle-guard's non-git and subdirectory-of-primary cases (each now also asserting the stated reason, and the second the metadata absence it was missing) and the herdr projection e2e's forced non-worktree cwd. * no-mistakes(review): stub poll sleep in tangle-guard spawn isolation test * no-mistakes(document): document spawn poll isolation screen in fm-spawn header * test(spawn): make the non-git isolation case non-git anywhere The refusal-reason assertion for a path outside any repository assumed TMPDIR is not inside a git repository. Where it is, git walks up from the temporary directory, finds that repository, and the spawn reports the subdirectory cause instead - so the case passed or failed on a property of the host rather than on the behaviour under test. Build the path under a directory the test then names in GIT_CEILING_DIRECTORIES, which git documents as not chdir-ing up into a listed directory while looking for a repository. Git never excludes the directory being searched, so the ceiling is the parent of the path handed to the spawn. The assertions pin which cause fired rather than the sentence that explains it, leaving the operator wording free to improve. * no-mistakes(document): point spawn poll comment at the isolation screen's comparison * no-mistakes(ci): Fixed the "Behavior portable serial 2" failure in tests/fm-tangle-guard.test.sh ("non-worktree spawn did not say why the path was rejected (missing: 'not inside a git worktree')"). Root cause, in this PR's code: bin/fm-spawn.sh's spawn_worktree_isolated resolved the git toplevel with `wt_top_real=$(cd "$SPAWN_WT_TOP" ...)`. For a path in no repository, `git rev-parse --show-toplevel` yields empty, and `cd ""` is a SUCCESSFUL no-op on bash before 5.3 (CI's ubuntu-latest ships bash 5.2). The empty toplevel therefore resolved to fm-spawn's own cwd — the CI checkout — so the poll reported "it is a subdirectory of worktree root '/home/runner/work/firstmate/firstmate'" instead of the correct "it is not inside a git worktree". Dev machines with bash 5.3 fail `cd ""`, which is why the suite passed locally and only failed on CI; it is a genuine shell-portability defect in the reason vocabulary this change added, not a test-environment artifact. Fix (smallest root-cause change, 1 line + comment, bin/fm-spawn.sh:2168-2173): guard the empty value so it never reaches `cd` — if [ -n "$SPAWN_WT_TOP" ] && ! wt_top_real=$(cd "$SPAWN_WT_TOP" 2>/dev/null && pwd -P); then No change to the poll's timing or deadline behavior (respecting the recorded refusal-latency and spawn-wt-reason-vocabulary decisions), no new tests, no other files touched. Verification: - Reproduced the exact CI failure locally by putting bash 3.2 (same `cd ""` semantics as CI's 5.2) first on PATH: fails before the fix with the identical message shape, passes after. - tests/fm-tangle-guard.test.sh passes under both bash 3.2 and bash 5.3. - tests/fm-spawn-worktree-settle.test.sh and tests/fm-spawn-pool-base-freshen.test.sh pass; shellcheck -x bin/fm-spawn.sh clean. - bin/fm-test-run.sh --changed: 46 suites completed, every FM_TEST_END exit=0, 1076 passing assertions, 0 "not ok" (including fm-tangle-guard, fm-control-relaunch, fm-lint). The run ended on my own 900s wall-clock cap (rc=124), not on any test failure* Let the supervision branch resolve extension-registered providers The isolated branch ModelRuntime cannot see providers an extension registered into main's runtime at run time, so a pin on pi-devin-auth's devin/swe-1-7 (or an unpinned branch following a main session on devin) failed with "unavailable to the isolated branch runtime". Capture main's ModelRegistry alongside mainModel and copy each extension-registered provider config into the branch runtime at model-resolution time. The config carries the provider's own streamSimple and oauth wiring by reference, so the custom gRPC transport reaches the branch unchanged instead of being reimplemented. The /supervision-model picker uses the same copy so those models are offered. Update configuration.md and pi-supervision-branch.md, which previously stated extension-registered providers were not offered. * no-mistakes(document): docs: own devin provider carve-out in branch architecture doc * no-mistakes(ci): Fixed the Greptile P1 finding: the /supervision-model picker copied extension-registered providers into the branch ModelRuntime but checked hasConfiguredAuth without refreshing them, so providers with provisional post-registration auth were omitted from the picker while the pin-resolution path (which did refresh) accepted them. Root-cause fix in .pi/extensions/fm-branch-supervision.ts: moved the `refresh({ providers, allowNetwork: false })` call into `copyExtensionProviders` (now async, refreshing every provider it copied) and removed the duplicate per-provider refresh from `resolveBranchModel`. Both the picker and the resolution path now share one copy-and-refresh step, so hasConfiguredAuth is real in both. Regression coverage in tests/fm-pi-branch-extension.test.sh: the stubbed ModelRuntime now mirrors the real runtime by leaving a registered provider's auth pending until `refresh()` runs for it. With that stub, the existing extension-registered-provider case fails against the pre-fix extension (picker offers only anthropic/main-model) and passes with the fix. Verification: tests/fm-pi-branch-extension.test.sh passes (42 ok, no failures); tests/fm-branch-supervision.test.sh passes; tests/fm-pi-primary-types.test.sh skips locally because tsc is not installed (the refresh signature reused is the one the existing code already called). Intent constraints preserved: isolation flags untouched, carve-out still scoped to provider registration, graceful fallthrough when no providers are registered * ci: retrigger flaky Herdr/serial-1 lanes * no-mistakes(document): docs already cover branch extension-provider copyThe captain's attribution policy (no Co-Authored-By trailer, no Claude-Session link, no generated-with line) lives in Claude Code's `user` settings scope. A spawned worker's settings sources are not guaranteed to load that scope, so a launched worker could write attribution trailers into its commits and PR bodies regardless of the captain's own configuration. launch_template()'s claude case now carries the same policy ("attribution": {"commit": "", "pr": "", "sessionUrl": false}) directly in its inline --settings JSON, so every claude launch keeps attribution off independent of which settings scopes end up loaded. Tests assert the policy on the rendered launch command for both a crewmate and a secondmate spawn. Co-authored-by: NewAiCoder <170579485+NewAiCoder@users.noreply.github.com>* test(lib): set fixture mtimes through one portable epoch helper On macOS the visible symptom was ONE red case in the turn-end guard suite. The actual damage was TWO cases that had quietly stopped testing their subject. The red one was the harmless half - people read one red case as one broken thing, and here that intuition is wrong. `touch -d @<epoch>` is a GNU extension; BSD touch rejects it outright and leaves the file at its current mtime. So on macOS the three away-mode beacon cases never aged their beacon at all. The 400s case exists to pin that 400s is stale under the flat 300s default but fresh under the poll-derived grace (660s at FM_POLL=600). Deleting the grace it guards (FM_POLL=60, so max(300,120)=300) and re-running proves what it was worth on this platform: pre-fix input (beacon left at now): ok - passes with the feature DELETED post-fix input (beacon 400s old): not ok - expected exit 0, got 2 It was green while measuring nothing, and could not have caught a regression in the grace it names. Only the 700s case broke loudly. `touch -t [[CC]YY]MMDDhhmm[.SS]` is POSIX and both platforms accept it, so the only host-specific step left is formatting the epoch into that stamp, which date(1) spells two incompatible ways. fm_touch_epoch in tests/lib.sh owns that probe once and fails loudly rather than leaving an unset timestamp behind - the failure mode that caused this. Verified on BSD touch/date here and on GNU coreutils 9.7 in a container. Three real sites, and one consistency change - not four fixes. The stale destination lock in tests/fm-remote-backlog-handoff.test.sh was never a defect: its `uname = Darwin` branch made the `touch -d` line unreachable on macOS, and BSD touch accepts that space-separated form anyway. `touch -t` takes the date directly on both platforms, so the branch goes rather than standing as a second copy of the same platform assumption. Known limit: the third case (away mode off) is only HALF recovered here. It now receives the input its name claims, but it is still insensitive after this fix - its verdict is identical with a 0s and a 400s beacon, because the fixture records a daemon lock and no watcher lock, and with away mode off the daemon lock proves nothing. Not fixed here; tracked separately, with the requirement that any fix be shown to FAIL when the protection is removed. FULL SUITE ON macOS: 189 scripts, four red, none of them this change. The turn-end guard and remote-handoff suites are clean. Attribution was established by running the four failures at the base commit and at this head on an idle machine, because base-idle against head-under-load moves two variables at once: script head/loaded base/idle head/idle verdict fm-calm-pi-extension red red red pre-existing fm-backlog-atomicity red red red pre-existing fm-procevent red red red pre-existing fm-startup-network red green green cause unestablished, load-sensitive under a full run Reported, not fixed. fm-calm-pi-extension deserves its own note: it FAILS because Chrome is absent instead of declaring the capability it needs and standing aside, so its verdict is about the machine rather than its subject - the same family as the defect above, with the red at least announcing itself. Neighbouring class, reported not changed: `file_mode()` - a verbatim `uname = Darwin ? stat -f %Lp : stat -c %a` - is copy-pasted across at least five test scripts plus a `reread_mode` variant, and epoch-mtime reads are open-coded as `date -r … || stat -c %Y` in three more; same one-owner shape as the defect above. `git init` without `-b main` depends on the host's init.defaultBranch in several scripts (branch-name case, tracked elsewhere). timeout, sha256sum and sed -i uses are all correctly guarded where checked. Observed while building the check rather than the fix: the first watcher I wrote to wait for the suite matched its own command line, so it was waiting on its own existence and could never fire. Same shape as the cases above - machinery answering confidently about something other than its subject, by including itself in the evidence it was meant to judge. The file sentinel it was replaced with cannot be produced by the observer that reads it. * fix(review): Pin fixture timestamps to UTC across DST transitions * fix(document): Clarify shared fixture suite coverage* fix(pi): preserve native Codex effort and guarded supervision * test(pi): identify native compatibility guard versions * no-mistakes(review): share native-main follow rule between build and picker * no-mistakes(document): document native progress marker and ultra effort owners * no-mistakes(ci): Failing check "Behavior portable serial 1" was caused by this PR. The shard ran the default-on live guard tests/fm-pi-branch-responsiveness-live-e2e.test.sh, whose idle arm loads .pi/extensions/fm-branch-supervision.ts into a scratch project with a fixed list of copied libs. This PR added `import { registerFirstmateTool } from "./lib/fm-native-contract.ts"` to that extension and updated every other loading fixture's copy list, but missed this guard. Pi 0.85.1 therefore refused to load the extension ("Cannot find module './lib/fm-native-contract.ts'"), never drew its TUI, the test failed with "Pi 0.85.1 never drew its TUI in the idle arm", and the job hit its 20-minute cap. Fix (one line): added fm-native-contract to the lib copy loop in tests/fm-pi-branch-responsiveness-live-e2e.test.sh. Swept all other suites referencing fm-branch-supervision.ts / fm-primary-pi-watch.ts; the remaining ones without the new lib only hash, path-reference, or string-match the files and do not load them into Pi, so no further fixture changes are needed. Verification: reproduced the mechanism against the installed Pi 0.85.1 by building the lab copy with the old lib list (load error as above) and the fixed list (loads cleanly). tmux is not installed on this machine, so the live guard itself gate-skips locally ("skip: live: tmux absent") and could not be run end to end here; CI (which has tmux and Pi) will exercise it. shellcheck is clean on the edited file --------- Co-authored-by: Talon Stark <talonstark@gmail.com>* fix(remote): let the Aqua launch agent own the fm-remote Herdr session A herdr server keeps the macOS audit session of whatever started it, and only the Aqua login session (gui/<uid>) can read the login keychain without a prompt. Herdr's SSH remote attach starts the fm-remote server as its own child when it finds none, wins the socket at boot because sshd accepts connections before the login session exists, and every claude pane under that server then gets `security` exit 36, falls back to a stale plaintext credentials file, and reports "Login expired". launchd's own job lost the socket on every KeepAlive retry and the doctor still reported the session ready because it only asked whether any server answered. - Add bin/fm-remote-herdr-guard.sh, the launch agent's exec target: start the server in the foreground when nothing owns the socket, exit 0 when an Aqua-born server does, and otherwise stop the foreign server, wait for the socket, and exec the server at once. - Add bin/fm-remote-herdr-owner-lib.sh, the single owner of socket-owner discovery (lsof; pgrep cannot see herdr's argv on macOS) and the birth markers (SSH_*, XPC_SERVICE_NAME, FM_REMOTE_JOB_ACTIVE, sshd or remote-client-bridge ancestry matched on argv[0] and whole arguments). - Render the agent as the login shell exec'ing the guard with KeepAlive={SuccessfulExit=false} and ThrottleInterval=10, check the loaded job's successful-exit semaphore, and report a session served outside the Aqua login session as fixable so --fix retakes it through launchd; the reload waits for an Aqua-born owner rather than any running server. - Correct the doctor and docs: the launch shell provides environment parity, the launchd domain provides keychain access. - Pin the guard's decision table and the doctor's verdicts against real marker-carrying processes, and record the dated audit-session evidence. * no-mistakes(review): Verify Aqua ownership through launchd domains * no-mistakes(document): Document macOS lsof ownership requirement* ci: rebalance the portable parallel lanes on measured runner durations Both portable parallel lanes are capped at 10 minutes. Lane 1 was cancelled at that cap on every request raised on 2026-09-10 while lane 2 finished in about 3.5 minutes, so no request could go green. CONTRACT CLASS: RESTORE. The workflow already promises two duration-balanced lanes and the shard documentation already claims a measured wall; this re-establishes both against what the lanes now cost, and changes no lane count, no cap, and no scope of what runs. The counter-argument, so nobody has to take that on trust: two pieces here are genuinely new rather than restored, and either could be argued to make this a NEW-behavior change. `--list-scheduled` now ranks a parallel lane on measured durations where it previously handed every parallel script the serial default weight and returned an alphabetical order; and `--check-coverage` gains three reported fields. I classify the change RESTORE because both exist only to make the already-promised property checkable, but they are named here rather than folded into the restoration. === PART 1: THE TOTAL, AND HOW IT WAS OBTAINED === This section stands on its own. It establishes what the parallel set costs. It derives no packing; Part 2 does that, from this number. THE TOTAL: 828568 ms, about 13 min 49 s of serial work across the 24 scripts. Lane 1 held 624299 ms of it and lane 2 held 204269 ms, a 3.06:1 split. HOW IT WAS OBTAINED. The difficulty was that lane 1 had never finished, so its duration did not exist as a recorded figure anywhere and no timing artifact was expected for it. It turned out to be recoverable from the real lane without estimating, by two routes, across six CI runs on 2026-09-10 (34459949083, 34460760299, 34462530836, 34462758357, 34466966385, 34470382458): - Run 34462758357's lane-1 job finished its suite 18 s BEFORE the wall and uploaded a complete fm-test-timing-portable-parallel-1 artifact carrying all 11 scripts, FM_TEST_SUMMARY total=11 failed=0 duration_ms=598225. The upload step is if: always(), so the cancellation did not suppress it. This is one full, untruncated lane-1 measurement. - The five other lane-1 jobs were cancelled mid-suite, but each logs every script that had already finished as an FM_TEST_END duration_ms= marker. Those per-script records are complete measurements of completed scripts; only the script in flight at cancellation is lost, and it differs by run. Lane 2 completed in all six runs, so its scripts come from the six uploaded fm-test-timing-portable-parallel-2 artifacts. Every one of the 24 scripts therefore carries at least one untruncated measurement: 20 of them measured in all six runs, two in three or four runs, and two (fm-brief, fm-transition-lib, the tail of lane 1) in the single complete run. Each hint is the SLOWEST value that script reached, so the total is an upper envelope rather than an average. NO FIGURE IN IT IS DERIVED FROM A TRUNCATED LANE, and no lower bound was ever extrapolated into a total. THE ENVIRONMENT, AND WHETHER IT TRANSFERS. Every hint is a serial run of the real portable parallel lane on a GitHub ubuntu-latest runner, produced by the lane's own CI job. It transfers because it is not a proxy for the lane; it is the lane. Nothing in the total came from this machine or from any harness of mine. That mattered, and here is what it would have cost. A same-day macOS cross-check of the same scripts ran 1.7x to 5.0x slower with the ratio varying per script (fm-test-run 157420 ms against 92944 ms, fm-x-mode 67217 ms against 31870 ms, fm-composer-ghost 10521 ms against 2120 ms). Local timings therefore do not scale the lane, they REORDER it, so a packing derived from them would have balanced the wrong thing while looking clean. WHAT IT REPLACES, which is the root cause. The lanes were packed from the 2026-08-20 concurrent isolation proof: 24 candidates across four LOCAL workers. That record answers whether the candidates are isolation-safe, not how long a SERIAL CI lane runs, so it was structurally incapable of representing lane wall clock even when it was fresh. It was also never refreshed while the set grew about 3.2x. Both the wrong instrument and the staleness are fixed here: the hints now come from the lane itself and carry their run ids and date. === PART 2: THE SPLIT DERIVED FROM THAT TOTAL === Longest-processing-time assignment over those hints gives 414269 ms and 414299 ms, 30 ms apart, against 624299/204269 before. tests/fm-pi-primary-types.test.sh stays in lane 1 because that is the job which installs the Pi package, so ci.yml needs no step changes. === PART 3: DOES THE MARGIN SURVIVE MACHINE VARIANCE === Stated explicitly, because 6.90 min against a 10 min cap is 69% of cap before any variance is applied, and the cap covers the whole job rather than the suite. worst lane, script time 414299 ms 6.90 min job overhead, measured on the real lane ~18 s (see below) expected healthy job ~432300 ms 7.21 min x1.29 on the script time, plus overhead ~552400 ms 9.21 min cap 600000 ms 10.00 min room left after the multiplication ~47.6 s 7.9% of cap The 1.29x is the runner variance measured today on the SIBLING SERIAL lane, as supplied; it is not this lane's own figure. This lane family does have its own, and it is tighter: the six full lane-2 sums today span 192939 ms to 203451 ms, a spread of 1.054x. At that figure the worst lane lands near 7.58 min with about 2.4 min of room. I have used the LARGER, borrowed 1.29x for the verdict rather than the tighter one this lane actually shows, and note that the hints are already per-script maxima, so 1.29x on top is conservative twice over. THE MARGIN SURVIVES THE MULTIPLICATION, so this proceeds rather than stopping. The 18 s overhead is measured, not assumed: in run 34462758357 the lane-1 job ran 10 min 16 s against a 598.2 s suite, and lane 2 ran 3 min 21 s against a 192.9 s suite, a ~10 s difference that matches lane 1's extra Pi package install. The cap is unchanged, the lane count is unchanged, and nothing in the serial lane, its shard count, its guard or its hint table is touched. === PART 4: THE RECORDED FACT === The workflow comment no longer restates the shard wall as a literal, which is how "~1 min of serial sum" survived a 10x change without announcing it. It now points at bin/fm-test-run.sh --check-coverage, which prints parallel_max_ms, parallel_imbalance_ms and parallel_unhinted derived from the hint table, so the current number is computed on demand. The shard documentation carries the dated run ids, which route it was taken by, and the local cross-check that shows why local numbers are not admissible as hints. Two regressions pin what rotted: lane membership must be stored longest-measured-first, and the lanes must be fully hinted and packed within 5% of each other. Both were run against the old composition and both fail on it (420030 ms imbalance against a 624299 ms worst lane). The ordering assertion they replace named a specific script by hand and had itself gone stale. === PART 5: NAMED AND LEFT, OUTSIDE THIS REBALANCE === tests/fm-captain-hold-lifecycle.test.sh alone is 296481 ms, 36% of the whole set, so it is the floor of any two-lane split: no repacking can put a lane below it. After this rebalance the cap is about 1.45x the healthy lane where the sibling serial lane keeps roughly 2x. Nothing refuses a stale parallel hint the way PORTABLE_SERIAL_MAX_UNHINTED_PERCENT bounds the serial lane. parallel_unhinted is reported, not enforced, which is what let this drift for three weeks unnoticed. * fix(review): Restrict parallel scheduling hints to portable parallel lanes * fix(document): Clarify parallel lane scheduling and timing evidence* test: reproduce buried status declarations in shared readers * fix: share status event reads and preserve open blockers * fix: retain terminal scout and ship status declarations * no-mistakes(review): Fix status chronology, legacy completions, and reader performance * no-mistakes(review): Share terminal decision reconciliation across fleet snapshots * no-mistakes(review): Unify terminal supersession across cached folds and consumers * no-mistakes(review): Filter per-key status history while preserving terminal chronology * no-mistakes(test): Preserve parent lock ownership in Bash 3.2 subshells * no-mistakes(review): Anchor legacy status tokens so prose cannot hide pauses * no-mistakes(document): Document latest-event status read and kind-scoped fold cursor * no-mistakes(lint): Quote literal done in test for-lists for SC1010 * ci: expect 19 snapshot/fleet-view tests This branch adds a fleet-snapshot regression, so the stock macOS Bash lane's hardcoded guard of 18 'ok - ' lines fails on the new count. Bump the guard and its message to 19. * no-mistakes(review): Restore multiline child outcome reporting * no-mistakes(review): Select ledger terminal events through bounded shared reader * no-mistakes(review): Report newest open decision instead of preferring blocked * no-mistakes(review): Require colon before ship/scout terminal supersession in fold * no-mistakes(review): Gate socket-down override on latest event; drop lock matrix * no-mistakes(review): Fold only colon-bearing or keyed lines as decision transitions * no-mistakes(review): Pre-select candidate lines before per-key closing-verb fold * no-mistakes(test): Update fleet-view expectations to newest-open-decision rule * no-mistakes(document): Align status-read docs with fold-resolved crew state * no-mistakes(document): Correct status-reader contracts in classify-lib and crew-state headers * no-mistakes(ci): Greptile P1 (bin/fm-crew-state.sh:729, "Stale socket blocker survives") was a real defect introduced by commit b7c2183 on this branch, and is fixed. Root cause: the daemon-socket-down override took its verb check from `last_status_line "$LOG"` but its evidence and emitted detail from `$LOG_LINE` (status_current_line = the fold's newest still-open decision). Those are different lines whenever a later recognized `blocked:` event is one the decision fold declines. Reproduced by sourcing bin/fm-classify-lib.sh on `blocked: no-mistakes daemon socket is missing` followed by `blocked [key=pending-reply-t3]: still waiting on the answer` (reserved-namespace key whose note does not speak that vocabulary, so _fm_decision_key_transition_allowed rejects it): open set still holds the socket blocker, last_status_line returns the newer line, its verb is blocked, so the gate passed and the stale daemon-down evidence overrode a healthy attributed run. Fix (bin/fm-crew-state.sh): capture LOG_LATEST=$(last_status_line "$LOG") once and read verb, socket-down evidence, and the emitted note all off that same line, so the override fires only while the socket-down declaration is itself the log's latest recognized event — preserving the narrow override the prior round's user instruction asked for. Comment updated to state that contract. No new machinery; the two-line conflation was removed rather than papered over. Regression: extended tests/fm-crew-state.test.sh:test_socket_refusal_override_expires_when_the_crew_moves_on with the reproduced sequence, asserting the run-step reading (state: working, source: run-step) and absence of the override detail. It fails before the fix ("not ok - a later unfolded blocked event also hands the reading back to the run (missing: 'state: working')") and passes after. Verified locally: tests/fm-crew-state.test.sh, tests/fm-fleet-snapshot-view.test.sh, tests/fm-classify-decision-key.test.sh, tests/fm-watch-triage.test.sh, tests/fm-captain-hold-lifecycle.test.sh all pass; bin/fm-lint.sh (shellcheck 0.11.0 + actionlint) exits 0. Changes left uncommitted in the worktree * test: fold terminal-cleanup snapshot coverage into the completed-scout case Keep the ship/scout/secondmate supersession assertions without adding a nineteenth top-level fleet-view test, so CI can stay at the upstream suite count. * no-mistakes(document): Clarify socket-down override expiry in architecture doc * ci: retrigger flaky contribution checkUnder set -u, stock macOS bash 3.2.57 treats "${arr[@]}" on an empty indexed array as an unbound variable and aborts the shell. In signal_turnend_panes_churned() the missing_keys loop was reachable with an empty array whenever every churned key already held a fresh .churn-since-* marker (a second churning turn-end inside an open deferral window), so each watcher cycle died about half a minute in and supervision restarted endlessly. The created_keys rollback loops had the same latent crash on their error paths. Audit of bin/ for the same pattern found one more confirmed-reachable case: remote_handoff's noncanonical-body scan iterates to_move, which is empty when a retried remote handoff finds every key already staged in the outbox. All other "${arr[@]}" sites are either count-guarded, guaranteed non-empty by construction, or unreachable while empty. Guard the three reachable expansions with the repo's existing "${arr[@]+...}" idiom. New regression test drives a real watcher through the all-marked churn path; the macos-stock-bash CI lane runs it under real /bin/bash 3.2 via FM_TEST_ONLY.* fix(bin): stop misreading a no-run branch as an unreadable runs table Defect: when `no-mistakes axi status`'s overview is truncated (a task's own branch has zero rows among the shown ones), fm_nm_select_run's Python fallback derived the repo identity for its direct SQLite query from a `repo: <path>` line it expected in the overview text. The real CLI never emits that line, truncated or not (see the genuine capture at tests/captures/no-mistakes-v1.70.1/overview.toon, which has only `count:`/`runs[...]:`), so the lookup always failed and reported "unreadable runs table" for a task that simply has no run on its branch. On a fleet with many concurrent runs, every idle-branch task hits the truncated-overview path routinely, so this fired every few minutes and drowned genuine unreadable/blocked verdicts in noise. Fix: derive the repo identity from the task worktree path instead, which is exactly the value `no-mistakes` records as a repo's `working_path` (confirmed against the existing capped-overview test fixtures, which already register repos by worktree path). A worktree path that is not absolute cannot be matched and still reads as unreadable rather than being guessed at. Also raise the reader's SQLite busy timeout from 1s to 30s so ordinary lock contention on a busy fleet cannot masquerade as an unreadable database. Safety: every other verdict byte-for-byte unchanged - the repo lookup still requires exactly one matching row (a genuinely corrupt or mismatched repos table still reports unreadable, per the existing `repo` failure-mode test), the branch query and row validation are untouched, and a zero-row result for the branch still flows through the same recursive re-parse that already turns an empty `runs[0]{...}` table into `absent`. Added a regression test (test_capped_overview_without_repo_line_and_no_runs_reports_absent) that reproduces the real overview shape - capped, zero rows for the task's branch, no `repo: ` line - and asserts the crew state falls through to the pane/busy verdict instead of reporting unknown or "unreadable". Full fm-crew-state.test.sh suite passes unchanged otherwise. * fix: recovered same-branch inventory awk misreads empty result as unreadable fm_nm_select_run's deep SQLite reader rebuilds a `count:`/`runs[...]:` overview and re-runs it through the same awk selection pass. When that rebuilt inventory has zero rows for the branch, the row-matching loop never executes, so its counters (`seen`) stay at awk's uninitialized empty string while `expected` and `shown` are plain strings parsed from the header text. Comparing an uninitialized value against a non-numeric string uses string comparison, so "" != "0" is true, and the END block takes the "unreadable runs table" branch instead of falling through to the correct "absent" verdict for a branch with genuinely zero runs. Coerce the affected END comparisons with `+0` so they are always numeric, matching seen/expected/shown/total regardless of whether awk classified them as strings or numeric strings. A truncated or genuinely malformed inventory still differs numerically and still reports unreadable. * no-mistakes(review): bound capped-overview inventory reader and canonicalize worktree lookup * no-mistakes(review): match recorded repo path first, tolerate duplicate spellings * no-mistakes(review): revert repo lookup to exact working_path match * no-mistakes(document): note state-db inventory read under crew-state nm timeout* fix(bin): let one TERM always stop the watcher on bash 5.2 Bash 5.2 runs a pending trap from the parser entry of the next command substitution it expands, where the trap body is parsed as the inside of that substitution and fails ("trap: line 2: unexpected EOF while looking for matching `)'") or is dropped silently, consuming the signal. The watcher's `trap 'exit 1' HUP INT TERM` could therefore ignore a TERM and keep polling while its stopper waited: the triage suite's reap waited forever (CI jobs cancelled at 30 minutes), and the arm's signal path and the away-mode daemon's shutdown wait for the watcher the same way. Bash 5.3 fixed the parser; 5.2 is the stock bash on Ubuntu 24.04. HUP and TERM now keep bash's native fatal-signal handling, which runs the EXIT trap (watcher_cleanup) and exits on bash 3.2, 5.2, and 5.3. INT keeps its trap because bash ignores a direct SIGINT while a child runs. The check-spawn deferral window no longer contains a command substitution. The triage suite's reap is now bounded and fails the case within 10s with process evidence instead of hanging the job, and a new regression test proves TERM stops a watcher blocked inside a poll's pane capture and still releases its lock and records an acknowledgeable stop. * no-mistakes(document): Clarify watcher stop-signal documentation* fix(test): repair tmux liveness and calm follow-up loaded_off regressions Both self-tests fail on untouched main on a host whose coreutils are a multicall binary and whose Chrome has no pre-warmed profile, and each failure masks the other's file. tests/fm-tmux-agent-liveness.test.sh - the stand-in harness processes were symlinks to the host's `sleep`. A single-purpose `sleep` runs happily under another name, but a multicall coreutils binary (uutils or busybox) resolves its applet from argv[0]: `claude-link -> sleep` invoked under the harness name runs the wrong applet and exits immediately, so no foreground process exists and every positive case reads not-alive ("last verdict for liveness:agent was missing (expected alive); title=sh comms=[sh ]"). Build a dedicated spinner as the stand-in target, exactly the way the version-string case already builds its executable, and require the fallback target to demonstrably survive the rename before using it. Every assertion is untouched; the stand-in identity signal is unchanged (the kernel still records the symlink name as the executable identity). tests/fm-calm-pi-extension.test.sh - render_export_dom pinned a brand-new `--user-data-dir` per attempt. On Google Chrome for Testing 151.0.7922.34 that pristine profile makes Chrome's first-run initialization never complete: the browser and its renderers start, but --dump-dom never returns, so all three bounded attempts end exit=0 timed_out=yes bytes=0 and the DOM assertions never run ("could not render calm-mode HTML export DOM"). Chrome's own profile creation under a fresh HOME renders the same document in about a second, so the helper now gives Chrome a private per-attempt HOME instead of the explicit profile flag. Each attempt still gets an isolated profile, and every DOM assertion is unchanged. Root-cause evidence: a pristine --user-data-dir with `--headless=new --dump-dom` had not returned after 150s, while the same command with an empty HOME and no --user-data-dir returned the full DOM in ~1s, and reusing an already-populated profile also returned it in ~1s. The render failure masked the rest of the file: with it repaired, the Pi follow-up loaded_off case passes unmodified against an installed @earendil-works/pi-coding-agent package. These two failures block downstream validation of every lane on hosts with multicall coreutils or a fresh Chrome profile. Verification: - timeout 300 bash tests/fm-tmux-agent-liveness.test.sh -> exit 0, 16 assertions ok - timeout 700 bash tests/fm-calm-pi-extension.test.sh -> exit 0, 13 assertions ok, including the Pi operational follow-up loaded_off case - bash -n and shellcheck clean on both touched files - rest of tests/: bin/fm-test-run.sh --all bounded by timeout 900 completed 17 files with 0 failures (fm-afk-contract.test.sh through fm-backend-herdr-launcher-workspace-e2e.test.sh), then the bound cut off the 18th (fm-backend-herdr-presentation-e2e.test.sh, a real-herdr-gated lab test) with no failure recorded * fix(test): give wake-queue observation checkpoints the alerting ceiling tests/fm-wake-queue.test.sh's secondmate stall case runs bounded foreground watcher checkpoints whose job is to record an observation, with the alerting checkpoint that follows asserting the stall. A checkpoint's exit publishes a downtime marker, and the next checkpoint consumes it only by reaching the end of the watcher's poll loop, where the recovery surfacing runs after the stall tick; the observation itself is recorded by that same stall tick. On a loaded host a 1s ceiling sits under the cost of that iteration (which includes a pane capture in the active-turn gate), so the observation was never recorded, the downtime marker stayed pending, and the alerting checkpoint surfaced `check: rearm-resurface` instead of the stall it asserts: not ok - a foreign queue with no progress did not alert: check: rearm-resurface not ok - a frozen reprovisioned queue generation was hidden: check: rearm-resurface Give the observation checkpoints that feed a later alert the same 4s ceiling the file already documents for alerting checkpoints. The ceiling is only a bound - a checkpoint still returns on its first actionable wake - so no assertion is weakened, and the quiet windows get longer, not shorter. * no-mistakes(document): docs: correct export-DOM Chrome render root cause * no-mistakes(review): Isolate Chrome profile on macOS, dedupe tmux CC_BIN lookup * chore: re-trigger fork workflow approval for triage --------- Co-authored-by: Captain <blackxwhite88@users.noreply.github.com> Co-authored-by: kunchenguid <kunchenguid@users.noreply.github.com>* fix(bin): terminate a remote job worker that lost ownership when it receives TERM A serving worker whose lock directory is gone can no longer quarantine shutdown, and resuming service publishes a false ready heartbeat. Exit after stopping only that worker's own command tree, without removing a replacement owner's lock. * no-mistakes(review): Check worker lock ownership before publishing shutdown quarantine * no-mistakes(document): Correct worker shutdown comment on replacement-owned lock * fix(bin): keep an ousted remote job worker off the replacement quarantine Shutdown can lose the lock after the first ownership check and before it writes or clears quarantine. Bind both operations to the directory object this process still owns so a replacement's quarantine stays untouched. * no-mistakes(review): Make ousted-worker shutdown test reliably reach quarantine clear * no-mistakes(document): Reattach worker_shutdown doc comment to its function * no-mistakes(ci): Fixed the failing check (Behavior portable serial 7) with a test-only change to the stall test in tests/fm-remote-job.test.sh. Product code is unchanged; no other test changed. Cause: after the decoy dies, both workers run the same check-exists, read, delete sequence on the job records. On the CI runner the replacement deleted a record between the ousted worker's check and its read. The ousted worker exited 125, and because the file runs under set -e the unguarded `wait` ended the test with 125. The exit trap then killed the replacement, which produced the "Killed" line. Reproduction: a temporary 0.3 s delay between the check and the read, applied to the ousted worker only, made the committed test fail exactly as in CI (exit 125 and the "Killed" line). The new test passed with the same delay. The delay is reverted, along with a similar debug hook that the timed-out attempt had left in bin/fm-remote-job-worker.sh. Test changes: - The replacement is frozen (and confirmed stopped) before the decoy is killed and resumed only after the ousted worker exits, so only one worker touches the job records at a time. - The ousted worker is stopped only once its quarantine exists and its lane is reaped, which places it inside its stop loop. - Every fixed poll loop is now a wait on a named condition with a 30 s deadline and an explicit failure message. Exit detection also handles zombies. - The exit trap kills and waits for the decoy and both workers on every path. - A non-zero exit from the ousted worker now fails with its exit code and stderr instead of silently ending the file. The test still proves that the resumed ousted worker exits 0 and leaves the replacement's lock, quarantine contents and quarantine inode unchanged. Verification: the full test file passed four times on its own and three times under nice -n 10 with four busy-loop CPU hogs; bin/fm-lint.sh passes. Changes are not committed * no-mistakes(ci): I fixed the failing check (Behavior portable serial 7) by changing only the stall test in tests/fm-remote-job.test.sh. Product code is unchanged. **What failed:** "an ousted worker in shutdown leaves the replacement quarantine untouched" failed on CI with the ousted worker exiting 125 ("could not stop the active command tree"). **Why:** during shutdown, the worker retries the still-running decoy command group a fixed 100 times, 0.01 s apart, then gives up and exits 125. The test tried to freeze the worker partway through those retries by sending SIGSTOP from outside. On a slow runner the retries ran out before the stop arrived, so the worker had already given up. The invariant is that the test must hold the ousted worker inside that retry loop until the replacement owns the lock. That was the only place the test depended on timing. The other waits already watch for a named state change with a 30 s deadline. **Fix:** - The ousted worker now starts with a small `sleep` wrapper at the front of its PATH, and the SIGSTOP race is gone. - The wrapper only holds a `sleep` called directly by that worker's own process (it checks its parent pid against a hold file) while its quarantine file exists. - The only such `sleep` is the first retry in the shutdown stop loop, so the worker waits there as long as needed. - The wrapper writes a marker when it starts holding. The test waits for that marker, then hands the lock to the replacement, freezes the replacement, and kills the decoy. - The test releases the worker by deleting the hold file. Deleting the whole temp directory also releases it, so a failed run cannot leave the wrapper looping. - A process leak: the test overwrites the job's command-group record with the decoy, so no worker ever stopped the job's real command. `fm-hold-job.sh` and its `sleep 30` stayed running for up to 30 s after the test. The test now records that group before overwriting it and kills it at the end of the test and in the exit cleanup. - The test still asserts the same things: the ousted worker exits 0, and the replacement's lock, quarantine contents and quarantine inode are unchanged. **Verification:** - The full file passed twice on its own, twice under `nice -n 10` with six busy-loop CPU hogs, and twice more after the leak fix. - `pgrep` found no leftover processes afterwards. - With the worker from just before the fix commit (cf45cb6^), the test still fails with "the ousted worker wrote or cleared the replacement quarantine during shutdown", so it still proves the fix. - `bin/fm-lint.sh` passes. - I did not reproduce the CI failure locally. The cause comes from the fixed retry limit and the CI error message. The changes are not committed * no-mistakes(ci): I changed only the stall test ("an ousted worker in shutdown leaves the replacement quarantine untouched") in tests/fm-remote-job.test.sh. Product code is unchanged, and so is every other test. **Invariant:** the pid written to the job's group record must be a process-group leader whose group dies when that one process is killed. Otherwise the worker's bounded stop loop never sees the group die, gives up, and exits 125 ("could not stop the active command tree") before it reaches the lost-ownership exit. The decoy is the only place in this test that depends on this. **Fix:** - The decoy used to be `set -m; sleep 30 &`. It now starts as `perl -MPOSIX=setsid -e 'setsid() >= 0 or exit 1; exec @ARGV' sleep 30 &`, which gets its own session and group without shell job control. tests/fm-procevent.test.sh already uses the same idiom. - The test now waits, with the file's usual 30 s deadline and a named failure, until `ps -o pgid=` of the decoy equals its pid before writing it into the group record. This way the worker can never read the record before `setsid` has run. - The existing steps are unchanged: the test kills the decoy, reaps it with `wait` before releasing the hold file, and the exit trap still kills and reaps the decoy and both workers. - The assertions are unchanged: the ousted worker exits 0, and the replacement's lock pid, quarantine text and quarantine inode stay the same. **Cleanup:** I reverted a debug `printf` hook that the timed-out previous attempt had left in bin/fm-remote-job-worker.sh, and deleted its untracked `.tmp-repro/` directory. Neither was committed. **Verification:** - The full tests/fm-remote-job.test.sh passed twice normally and once under `setsid -w` with stdin from /dev/null (no controlling terminal). - `bin/fm-lint.sh` passes. - No leftover `sleep 30` processes afterwards. **Not reproduced:** I could not reproduce the CI failure locally. On this host `set -m` made the decoy its own group leader even without a controlling terminal, so the cause on the runner is not confirmed. The change removes the test's reliance on shell job control, as the user asked. Changes are not committed * no-mistakes(ci): I changed only the stall test ("an ousted worker in shutdown leaves the replacement quarantine untouched") in tests/fm-remote-job.test.sh. Product code is unchanged, and so is every other test. **Invariant:** the group record the ousted worker checks in its stop loop must stay the job's own command group, and the test must stop that group before it releases the hold. Otherwise the bounded retry keeps seeing a live group, gives up, and exits 125 ("could not stop the active command tree") before it reaches the lost-ownership exit. The test overwrote this record in one place (the decoy) and stopped the group in one place (killing the decoy); both are changed. **Fix:** - I removed the setsid decoy and the overwrite of `.claim/group`. The record keeps the job's real command group, which the test still saves as `STALL_JOB_GROUP`. - The two-line `group_start` stays. It is still needed: without it the worker kills the real group on its first pass, before the replacement takes over, so the hold would never matter. - The `sleep` wrapper that holds the worker at its first stop-loop retry is unchanged. - After the replacement owns the lock, its quarantine is planted and it is frozen, the test runs `kill -KILL -- -$STALL_JOB_GROUP`. It then waits, with the file's usual 30 s deadline and a named failure, until `kill -0` on the group fails. Only then does it remove the hold file. The worker therefore always sees its own command already stopped and never races its retry budget. - The exit trap still kills the saved command group if the test fails. It can't `wait` on that group because the group is not a child of the test shell. The decoy variable and its cleanup entry are gone. - The assertions are unchanged: the ousted worker exits 0, and the replacement's lock pid, quarantine text and quarantine inode stay the same. **Verification:** - The full tests/fm-remote-job.test.sh passed twice normally. - It passed once under `setsid -w` with stdin from /dev/null (no controlling terminal). - It passed once under `nice -n 10` with six busy-loop CPU hogs. - With the worker from before the fix (cf45cb6^), the test still fails with "the ousted worker wrote or cleared the replacement quarantine during shutdown", so it still proves the fix. - No `fm-hold-job` or `sleep 30` processes were left afterwards. - `bin/fm-lint.sh` passes. **Not reproduced:** I couldn't reproduce the CI failure locally; the decoy version also passed on this host. So I can't confirm why the decoy group stayed alive on the runner. The new wait turns any leftover live group into a clear named failure instead of an exit 125. The changes are not committed * fix(bin): keep a dead command group dead on bash 5.2 A bare return inside the liveness check drops the failing kill status when the check runs in a conditional, so shutdown keeps treating a stopped group as alive and exits 125. * no-mistakes(review): Use bash 3.2 fd syntax and fix trap return comments* fix(bin): strip AI co-author trailers from fleet-launched commits Cursor and other non-Claude runtimes append the trailer after the typed message. A per-task commit-msg hook removes it and leaves human co-authors and the author identity untouched. * no-mistakes(review): Export pane hooksPath override and drop generated-with stripping * no-mistakes(ci): This PR caused all three CI failures, and the fix is test-only: 4 test files change, no product code. **Cause.** `fm-spawn.sh` now installs the AI-trailer strip hooks for every spawn, secondmates included. The installer refuses a worktree that is not a git repository, and the PR deliberately keeps that fail-closed rule because real secondmate homes are firstmate clones. Four test fixtures still gave secondmates a plain directory as their home, so each spawn failed with "not a git worktree ... could not install the AI-trailer strip hooks": - serial 5: `tests/fm-backlog-atomicity.test.sh` ("secondmate spawn failed"). - serial 8: `tests/fm-secondmate-harness.test.sh` ("split: no meta written"). - Herdr: `tests/fm-backend-herdr-launcher-workspace-e2e.test.sh` and `tests/fm-backend-herdr-workspace-per-home-e2e.test.sh`. **Rule that must hold.** Every home a test spawns as a secondmate must be a git worktree. I checked the other places in the changed area: the only secondmate spawns in these tests are the ones listed. The earlier rounds already fixed the other fixtures (`fm-secondmate-liveness`, `fm-secondmate-safety`) the same way. **Fix.** - Each of those four secondmate homes now gets the same `.gitignore` plus `git init -q -b main` that the liveness and safety tests already use. - The two Herdr tests clean up with their own plain `rm -rf "$TMP_ROOT"`, not the shared `tests/lib.sh` helper. Because the installer leaves each `state/<id>.git-hooks` directory read-only, that cleanup printed "Permission denied" and left the directories behind. Both cleanups now restore the owner's write bit on every directory before removing (`find ... -exec chmod u+rwx`), which is what `fm_test_remove_tree` in `tests/lib.sh` does. **Verification.** - `tests/fm-secondmate-harness.test.sh` passes. - `tests/fm-backlog-atomicity.test.sh` passes (99 ok, exit 0). - shellcheck is clean on all four files. - I could not run the two real-Herdr tests locally: the Herdr lab on this host refuses to start because it needs exactly one running default session, and I did not change the host's Herdr state to get around that. Instead I checked their two changed steps directly: the installer succeeds on a home set up the new way, and the new cleanup removes the read-only hooks directory completely. Those two tests will only be proven on CI* fix(bin): refuse a merge when a required check never reported fm-pr-merge.sh built its GitHub refusals only from checks present in statusCheckRollup, so a required check that never ran was simply absent and the merge proceeded on the subset that reported, contradicting its own "every required check green" claim. The GitHub verify now reads the base branch's required contexts from the forge itself - the classic branch protection summary on GET repos/{o}/{r}/branches/{b} and the active ruleset rules on GET repos/{o}/{r}/rules/branches/{b} - and refuses when a required context has no entry in the same rollup, at the same head, that the merge is bound to. Absence reads as unknown, never green. The required-set read joins the existing refusal list, so a draft, a red check, and an unreported required check are all reported together. Could not read vs nothing required: both endpoints need only repository read access. The admin-only GET .../branches/{b}/protection endpoint is deliberately not used: it answers a non-admin token with the same 404 an unprotected branch gets (observed live on kunchenguid/firstmate main with this token), which would read a missing permission as "nothing required". Any failed or malformed read of either source (auth, missing fine-grained permission, rate limit, network, 404, unexpected shape) refuses the merge with a line naming the unreadable source. The one exception is GitHub's plan-gated 403 on the rules endpoint ("Upgrade to GitHub Pro or make this repository public"), which already means "this repository has no branch rules" for the merge-queue reader; that check moves into one shared helper and the classic summary still decides for such a repository. Attended waiver: --allow-missing <check-name> is the twin of --allow-red and follows the same design and recording path: once, separate name argument, waives only that exact unreported required check, still requires every other required check reported and every check green, never waives an unreadable required set, refused while the away-posture record exists, and refused on GitLab. Merge-state BLOCKED policy is unchanged. How this differs from the withdrawn #5353 (read from its diff): - #5353 read the admin-only branches/{b}/protection endpoint and treated its 404 as "no required checks", so for any non-admin token the required set silently read as empty; this change reads the read-access branch summary and treats every failure as unreadable. - #5353 ignored rulesets; this change also reads required_status_checks rules from the effective branch rules. - #5353 made separate per-head REST reads of statuses and check-runs capped at per_page=100 with no pagination; this change checks presence in the same statusCheckRollup view the red-check gate already reads at the verified head. - #5353 stopped at the first unreadable read; this change reports it as one refusal among all the others. - #5353 also claimed #5345 (lock stealing) and changed 39 files, most unrelated; this change is #5344 only. Live proof, read-only (a gh wrapper refused every merge and mutating call): - cli/cli#14474 (trunk requires 3 classic build contexts, none ran): refused, naming build (macos-latest), build (ubuntu-latest), build (windows-latest); with --allow-missing "build (macos-latest)" it still refused, naming the other two. - cli/cli#13665 (ran build (ubuntu-24.04-firewall) instead): refused, naming build (ubuntu-latest). - hashicorp/terraform#39262 (ruleset-required checks absent): refused, naming Code Consistency Checks, End-to-end Tests, Race Tests, Unit Tests. - cli/cli#14485 (all required reported and green): verified; the wrapper blocked the merge call and the pull request read back open. Fixes #5344 * fix(review): Preserve required-check producers and aggregate independent read failures * fix(document): Clarify required-check verification and waiver documentation * fix(bin): match an app-bound required commit status by name The producer-identity check resolved an app-bound required context only against check runs, so a required context that the required app reports as a commit status could never match and always read as "has not reported". A commit status carries no app id to compare, so an app-bound requirement that arrives as a status now matches by name, as before producer binding; check runs keep requiring the configured producer app. Live, read-only: hashicorp/terraform#39262 requires license/cla from integration 865473, reported green as a commit status by the CLA app. The previous head refused it as unreported; this head no longer does, while still naming the four required check runs that never ran there. Refs #5344 * fix(document): Clarify accepted commit-status producer verification limitation --------- Co-authored-by: firstmate-oss <firstmate-oss@kunchenguid.local>* fix(bin): stop reporting an already-installed version as an available update An update announcement named its version first ("current -> new"), so reading the first dotted number as the announced version compared the current version against itself and always looked newer. Read the last dotted number instead, and only report an available update when that announced version is newer than the newest installed copy found; when that version is already installed, report only PATH skew. Fixes #5151 * no-mistakes(document): docs: gate announce update-available report on newer-than-installedAdversarial-review fixes for PR 37. S2: fm_pr_forgejo_read_pull now requires .draft to exist and be boolean - a missing, null, or wrong-type draft refuses the read instead of passing the gate as non-draft. A Forgejo merge the forge queued or could not confirm no longer exits zero: it exits nonzero with an explicit pending message while the merge poll stays armed, so no caller can read the exit as a landed outcome. tests/fm-pr-merge.test.sh gains Forgejo merge-gate coverage through the same run_pr_merge fixture with a curl mock: the green path pins head_commit_id in the JSON body and carries the token by descriptor, and the refusals cover draft, unmergeable, moved head, red status, status-less head, malformed draft shapes, queued and unreadable read-backs, and --allow-red refusal. The suite's fixture also gains a tasks-axi stub so its verdicts no longer depend on the host's installed tasks-axi version, which fixes the long-red github-zero-exit-queue-required case (host 0.2.5 vs required 0.2.6+). S4: the delivery-target guard compares the effective push destination instead of the fetch URL: every distinct push URL of the origin is resolved (remote.origin.pushurl when set) and any mismatch or multiple destinations refuses the spawn. tests/fm-spawn-nm-target.test.sh gains a pushurl-mismatch case. S7: docs/operator-pc-compromise.md no longer treats absent log evidence as a clean host ("no evidence found in available logs"; untrusted or incomplete logs mean unknown, corroborate before calling a host clean) and a clean tofu plan now reads as no current drift, not proof of non-use, with provider audit history as the attribution source. Deliberately not changed: the same-head combined-status race in the Forgejo merge gate (firstmate files it as a follow-up for forge branch protection), and AGENTS.md's quota-ceiling landing section, which stays per the captain's keep-list S5.Superseded by #38 (same branch content plus the Lint 2 fix).
Pull request closed