feat: enforce deterministic delegated Pi profiles

[BazsaX254]

Intent

Implement FirstMate-owned deterministic delegated Pi profile enforcement for Pi workers, scouts, helper routes, batches, supported secondmates, and recovery across tmux, Herdr, Zellij, Orca, and cmux, while leaving the primary Pi path xhigh. The opt-in operator-owned home profile must pin Pi 0.81.1, an exact model and effective context metadata, explicit medium thinking, and compaction at exactly 60 percent using reserveTokens = contextWindow - floor(0.60 * contextWindow), failing closed before launch on ambiguity, hostile environment/project/extension surfaces, raw launch wrappers, override/model cycling, or unsupported routes. Preserve only required FirstMate extensions, keep existing backend refusals, avoid KING-specific shared policy, and provide provider-free portable tests with overridable Pi/package/compiler discovery, exact local 272000 context and 108800 reserve proof, strict greater-than boundary behavior, resume stability, primary xhigh separation, and full backend coverage. This replacement branch also fixes the sole confirmed PR 877 CI failure by including fm-operational-input.sh in the synthetic current-main backend baseline used by tests/fm-backend.test.sh, without changing runtime behavior. Do not invoke a model or live Pi worker, mutate Herdr lifecycle, global Pi state, production configuration, close PR 877, merge anything, or add an agent co-author.

What Changed

• Add an inherited, opt-in delegated Pi profile that pins Pi 0.81.1, exact model/context metadata, medium thinking, and compaction at the strict 60% boundary across supported worker, scout, batch, helper, secondmate, recovery, and backend routes.
• Fail closed on unsafe launch wrappers, overrides, ambient/project startup surfaces, or untrusted extensions while preserving protected FirstMate supervision extensions; add a separate primary Pi launcher that enforces xhigh thinking.
• Add portable profile and backend coverage for validation, compaction boundaries, resume stability, launch isolation, and primary separation, and include the operational-input dependency in the synthetic backend baseline.

Risk Assessment

✅ Low: The corrective changes address the prior findings, provide a genuine xhigh primary Pi launcher, preserve delegated-profile isolation, and introduce no material source-verifiable risks.

Testing

Provider-free tests demonstrated Pi 0.81.1 enforcement, exact 272000/108800 arithmetic, strict greater-than 60% compaction, resume stability, hostile-input refusal, protected extensions, primary xhigh separation, all five backend handoffs, batches, and secondmate recovery/inheritance. The synthetic-current-main backend regression passed after supplying its absent tasks-axi prerequisite. The optional TypeScript compiler check skipped because tsc was unavailable, but executable runtime guard coverage passed. This is CLI-only behavior, so transcript artifacts—not screenshots—are the appropriate reviewer evidence.

Evidence: Pi profile end-to-end evidence

ok - effective Pi 0.81.1 metadata and controlled settings derive the 272000/108800 profile
ok - unknown models and effective context mismatches are refused before launch
ok - models without effective medium thinking support are refused before launch
ok - raw Pi launch wrappers are rejected without execution
ok - pre-flag startup ignores project settings and migrations through whitespace paths
ok - Pi uses strict greater-than: false at exactly 60 percent and true immediately above
ok - an explicit delegated medium change remains the restored session thinking state
ok - runtime controls cannot leak model, thinking, or compaction changes
skip: tsc not found for delegated Pi profile guard typecheck
ok - hostile project and extension surfaces are neutralized while explicit FirstMate extensions remain supported
warn: no registry at /tmp/fm-pi-compaction-profile.OFUHPe/backend-tmux/home/data/projects.md; defaulting project to no-mistakes off
warn: no registry at /tmp/fm-pi-compaction-profile.OFUHPe/backend-herdr/home/data/projects.md; defaulting project to no-mistakes off
warn: no registry at /tmp/fm-pi-compaction-profile.OFUHPe/backend-zellij/home/data/projects.md; defaulting project to no-mistakes off
warn: no registry at /tmp/fm-pi-compaction-profile.OFUHPe/backend-orca/home/data/projects.md; defaulting project to no-mistakes off
warn: no registry at /tmp/fm-pi-compaction-profile.OFUHPe/backend-cmux/home/data/projects.md; defaulting project to no-mistakes off
ok - the delegated profile traverses every executable backend handoff
ok - delegated medium remains separate from the primary Pi xhigh path
# all fm-pi-compaction-profile tests passed

Evidence: Spawn enforcement evidence

ok - no --model/--effort records defaults and types the claude launch instructions
ok - active crew-dispatch profile requires an explicit harness for ship spawns
ok - active crew-dispatch profile requires an explicit harness for scout spawns
ok - active crew-dispatch profile allows an explicit resolved harness
ok - active crew-dispatch profile allows the legacy positional harness form
ok - active crew-dispatch profile allows the raw launch-command escape hatch
ok - claude receives --model and --effort profile flags
ok - codex receives --model and model_reasoning_effort profile flags
ok - codex omits unsupported max effort instead of passing a bad config value
ok - grok receives --model and --reasoning-effort profile flags
ok - grok omits unsupported max reasoning effort
ok - grok omits unsupported xhigh reasoning effort
ok - opencode receives --model and omits the unsupported effort axis
ok - pi receives --model and --thinking max profile flags
ok - top-level default array resolves through quota selection into the real spawn path
ok - configured delegated Pi profile overrides hostile ambience and pins the controlled command
ok - configured delegated Pi profile refuses model and effort substitution before launch
ok - active delegated Pi profile refuses env, env-command, shell-wrapper, and unknown raw launches
ok - malformed delegated Pi profile paths fail closed before launch
ok - batch dispatch forwards shared --harness, --model, and --effort to every pair
ok - active crew-dispatch profile does not block secondmate launches
ok - active delegated Pi profile must converge before secondmate launch or recovery
ok - Pi secondmates load protected FirstMate-owned supervision extensions
# all fm-spawn-dispatch-profile tests passed

Evidence: Backend CI-recovery evidence

ok - fm_backend_name: FM_BACKEND env > config/backend > default tmux
ok - fm_backend_detect: no markers -> undetected, HERDR_ENV=1 -> herdr, $TMUX -> tmux, CMUX_WORKSPACE_ID -> cmux, nested combinations resolve innermost-first
ok - fm_backend_detect: falls back to __CFBundleIdentifier=com.cmuxterm.app when CMUX_WORKSPACE_ID is absent (signal bundle-id; foreign bundle ids rejected)
ok - fm_backend_detect: the cmux fallback signals are macOS-only (inert on a non-Darwin uname)
ok - fm_backend_detect: an inherited cmux bundle id never outranks $TMUX or HERDR_ENV (tmux/herdr-inside-cmux false positive absorbed)
ok - fm_backend_detect: ancestry fallback matches the lsappinfo-resolved (bundle-id) cmux app pid in the parent chain
ok - fm_backend_detect: ancestry fallback matches a bundle-shaped cmux comm path at any install location when lsappinfo cannot resolve a pid
ok - fm_backend_detect: ancestry fallback stops undetected at launchd (a reparented tmux server never reaches cmux)
ok - fm_backend_name: a fallback-detected cmux prints a NOTICE naming the fallback signal; the primary-marker notice is unchanged
ok - fm_backend_name: auto-detect selects herdr or cmux (loud notice) or tmux (silent, including nested tmux-in-herdr/tmux-in-cmux)
ok - fm_backend_name: an explicit FM_BACKEND or config/backend setting always wins over runtime auto-detection, including an ambient cmux marker
ok - fm_backend_validate: implemented adapters accepted, unknown and blocked codex-app backends refused loudly
ok - zsh: shell-portable backend matching skipped (zsh not found)
ok - bash: fm_backend_source recognizes known backends and rejects unknown ones
ok - fm_backend_validate_spawn: all implemented lifecycle backends are spawn-supported
ok - fm_meta_get / fm_backend_of_meta: read key=value, default backend to tmux
ok - fm_backend_resolve_selector: session:window literal, exact task id first, legacy fm-<id> label fallback, ad hoc bare name via tmux list-windows
ok - fm_backend_of_selector: exact task ids, legacy fm-<id> labels, and matching explicit targets inherit metadata backend
ok - fm-send.sh: explicit tmux targets are verified, while --key/plain/slash send command shape stays old-compatible
ok - fm-peek.sh: capture-pane invocation and output are byte-identical old vs new
ok - fm-spawn.sh: a project reached through a symlinked prefix (e.g. macOS /tmp -> /private/tmp) does not trip the isolation guard's false refusal
ok - fm-teardown.sh: treehouse return + tmux kill-window command log is byte-identical old vs new for a scout task
ok - fm-spawn.sh --backend bogus is refused loudly
ok - fm-spawn.sh --backend codex-app is refused
ok - fm-spawn.sh honors FM_BACKEND and refuses an unimplemented value loudly
ok - fm-spawn.sh: an explicit --backend tmux resolves silently and writes no backend= (missing means tmux)
ok - fm-spawn.sh: explicit --backend tmux wins over an ambient HERDR_ENV=1 auto-detect marker
ok - fm-spawn.sh: auto-detect resolves nested tmux-in-herdr to tmux and stays silent end to end

Evidence: Secondmate inheritance evidence

ok - A1 fm-harness.sh secondmate resolves the fallback chain; crew mode unchanged
ok - C1 fm-harness.sh secondmate-model/secondmate-effort resolve the optional tokens; bare harness stays empty (backward-compat)
ok - B1 propagate_inheritable_config: copy, idempotence, convergence, absence-mirror, exclusion, no-op, skip diagnostics
ok - B2 spawn: secondmate runs the secondmate harness; its home inherits declared config
ok - B3 spawn: an absent secondmate-harness falls back to the crew harness (backward-compat)
ok - B4 spawn: no config at all -> own harness and no propagation side effects
ok - B5 spawn: an explicit per-spawn harness arg overrides config/secondmate-harness
ok - B6 spawn: an unverified resolved secondmate harness is refused (guard intact)
ok - C2 spawn: a bare harness-only secondmate-harness file launches with no model/effort flag (backward-compat)
ok - C3 spawn: config/secondmate-harness's model token threads --model into the launch and meta
ok - C4 spawn: config/secondmate-harness's model+effort tokens thread into the launch and meta
ok - C5 spawn: an explicit --model overrides config/secondmate-harness's model token; the file's effort token still applies
ok - C6 spawn: an explicit --effort overrides config/secondmate-harness's effort token; the file's model token still applies
ok - C7 spawn: an explicit --harness starts with clean model/effort defaults
ok - C8 spawn: an explicit --harness still honors explicit model/effort flags
ok - C9 spawn: the harness fallback chain still resolves with no tokens; crew/scout launches are unaffected by this feature
ok - B7 bootstrap sweep pushes, re-converges, and mirrors absence; never inherits secondmate-harness
ok - B8 bootstrap sweep propagates config even when the home's tracked files are already current
ok - B9 bootstrap sweep defers new inherited config until the home ignores it
ok - B10 bootstrap sweep with no inherited config is a config no-op and still fast-forwards
ok - B11 bootstrap sweep surfaces config propagation failures
ok - B11 bootstrap rereads completed config writes after partial propagation
ok - B12 config-push propagates via shared live discovery, reports items, rereads on change only, and does not fast-forward
ok - B13 config-push reports dirty, non-allowing, and invalid homes without failing warnings-only runs
ok - B14 config-push exits nonzero on real propagation errors
ok - B14 config-push rereads completed config writes after partial propagation
ok - B15 config reread is per-home, exact-byte, ordered, and pointer-only
ok - B16 config reread isolation, ABSENT, generation safety, send failure, and retry
ok - B20 config reread publication failures retain exact generations for retry
ok - B21 config reread instruction-write failures retain exact retry generations
ok - B21 config reread preserves exact bytes when temporary adoption also fails
ok - B21 config reread serializes concurrent propagation and delivery
ok - B22 full config reread retry queues drain before new publication
ok - B23 mixed config reread delivery failures still bound sent history
ok - B26 config reread delivery stops after the oldest failed generation
ok - B17 config reread skips unchanged homes and reads destination post-write bytes
ok - B18 bootstrap config reread path works; spawn flexibility remains defaults-only
ok - B19 bootstrap respawns before inherited-config reread
ok - B25 spawn quarantines stale rereads without blocking relaunch
ok - B24 bootstrap detect-only mode remains filesystem read-only
# all fm-secondmate-harness tests passed

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

🔧 **Rebase** - 1 issue found → auto-fixed ✅

• ⚠️ bin/fm-spawn.sh - merge conflict rebasing onto origin/main

🔧 Fix applied.
✅ Re-checked - no issues remain.

🔧 **Review** - 5 issues found → auto-fixed (2) ✅

• 🚨 bin/fm-spawn.sh:446 - The Pi templates add __PIBRIEFENV__, but no substitution defines or removes it. Every profiled and ordinary Pi launch therefore attempts to execute a command literally named __PIBRIEFENV__ and fails before Pi starts.
• 🚨 bin/fm-pi-profile.sh:95 - This contradicts “Do not ... mutate ... global Pi state [or] production configuration.” The validator executes pi --version; Pi 0.81.1 runs migrations before processing that flag, and this call neither preloads the startup guard nor pins PI_CODING_AGENT_DIR. It can therefore migrate the caller's project or ambient Pi configuration during validation. Read the resolved package metadata instead, or isolate this invocation identically to launch.
• 🚨 bin/fm-spawn.sh:446 - The required fail-closed handling of “hostile ... extension surfaces” is incomplete for Pi secondmates. The template explicitly loads supervision extensions from the secondmate worktree, while the surrounding recovery path deliberately launches dirty or diverged homes unchanged. Modified files at these paths therefore execute as trusted extensions. Verify their bytes against FirstMate-owned sources or load protected copies before launching.
• 🚨 tests/fm-pi-compaction-profile.test.sh:355 - The required “full backend coverage” is not provided: this loop only greps fm-spawn.sh for backend case labels and the common handoff text. It never drives a profiled Pi spawn through Herdr, Zellij, Orca, or cmux, so backend-specific ordering or rendering failures remain untested.
• 🚨 tests/fm-pi-compaction-profile.test.sh:365 - The required portable proof of “primary xhigh separation” is optional and silently skipped unless an externally supplied FM_PI_PRIMARY_LAUNCHER is set; no repository CI configuration supplies it. The default test run therefore does not verify that the primary remains xhigh.

🔧 Fix: Harden delegated Pi validation, extensions, and backend coverage
2 issues (1 error, 1 warning) still open:

• 🚨 tests/fm-pi-compaction-profile.test.sh:454 - The required portable test of “primary xhigh separation” still does not exercise a primary Pi path: it invokes fm-spawn.sh, whose contract is exclusively to spawn direct reports, with no delegated profile and labels that worker “primary.” This proves only that an unprofiled delegated worker accepts xhigh, not that the actual primary launcher remains xhigh.
• ⚠️ bin/fm-spawn.sh:1330 - The extension-integrity fix changes Pi secondmates to load protected extensions from $FM_ROOT, but the operator documentation and launch-placeholder comments still state that they load the secondmate home's mutable copies. Update those contracts so recovery and security guidance describes the implemented ownership boundary.

🔧 Fix: Enforce xhigh in genuine primary Pi launcher
✅ Re-checked - no issues remain.

✅ **Test** - passed

✅ No issues found.

• bash tests/fm-pi-compaction-profile.test.sh
• bash tests/fm-spawn-dispatch-profile.test.sh
• bash tests/fm-backend.test.sh (first run identified missing tasks-axi test prerequisite)
• PATH=/tmp/no-mistakes-evidence/01KY8NX86C6M3E68PBHGWGPXFY/fakebin:$PATH bash tests/fm-backend.test.sh
• bash tests/fm-secondmate-harness.test.sh
• git status --short and git diff --exit-code

✅ **Document** - passed

✅ No issues found.

⚠️ **Lint** - 1 warning

• ⚠️ linter found issues (exit code 127)

🔧 Fix: Suppress false ShellCheck JavaScript expansion warning
1 warning still open:

• ⚠️ linter found issues (exit code 127)

✅ **Push** - passed

✅ No issues found.

[BazsaX254]

Maintainers: this forked PR's CI and Require no-mistakes workflows are awaiting approval (runs 30074245249 and 30074245201). Please approve them when convenient so validation can proceed. Thank you.

[BazsaX254]

@kunchenguid could you please approve the two pending workflow runs for this fork PR? Both CI and the no-mistakes requirement are blocked before execution by GitHub's fork-workflow approval step. The exact runs are 30074245249 and 30074245201. Thanks.