feat: add mechanical dispatch guardrails and NAS auto-deploy-sync

.agents/skills/bootstrap-diagnostics/SKILL.md

@@ -2,7 +2,7 @@
 name: bootstrap-diagnostics
 description: >-
   Agent-only handling playbook for session-start bootstrap diagnostics.
-  Use whenever the session-start digest's bootstrap section prints any diagnostic or capability line - MISSING, MISSING_MANUAL, BACKEND_INVALID, NEEDS_GH_AUTH, TANGLE, CREW_HARNESS_OVERRIDE, CREW_DISPATCH, FLEET_SYNC, SECONDMATE_SYNC, SECONDMATE_LIVENESS, TASKS_AXI, NUDGE_SECONDMATES, or FMX - or when a standalone bin/fm-bootstrap.sh run prints one.
+  Use whenever the session-start digest's bootstrap section prints any diagnostic or capability line - MISSING, MISSING_MANUAL, BACKEND_INVALID, NEEDS_GH_AUTH, TANGLE, CREW_HARNESS_OVERRIDE, CREW_DISPATCH, FLEET_SYNC, SECONDMATE_SYNC, SECONDMATE_LIVENESS, TASKS_AXI, NUDGE_SECONDMATES, SERVICE_FAILED, FMX, or UPSTREAM_DRIFT - or when a standalone bin/fm-bootstrap.sh run prints one.
   A silent bootstrap section means all good and needs no skill load.
 user-invocable: false
 metadata:
@@ -47,3 +47,12 @@ The inline rules in `AGENTS.md` section 3 still bind: detect, then consent, then
   A secondmate that was skipped, already current, or whose advance changed no instructions is not listed and must not be disturbed.
 - `FMX: X mode on ...` / `FMX: X mode off ...` - bootstrap confirmed or removed the local X-mode poll artifacts (`docs/configuration.md` "X mode (.env)").
   Only when a running watcher needs the cadence transition applied immediately, restart the home-scoped watcher through the emitted harness supervision protocol; bootstrap deliberately never restarts the watcher itself.
+- `SERVICE_FAILED: <unit> - failed since <timestamp>` - a systemd unit named in the optional local `config/critical-services` file is in the failed state; a pure read-only detection (`systemctl is-failed`, no root), so a read-only session still surfaces it.
+  Report it to the captain in plain language; never restart the unit yourself, since a unit that failed may be unsafe to restart without knowing why.
+  An absent or empty config file, a host without `systemctl`, or no failed unit all print nothing.
+- `UPSTREAM_DRIFT: local main is <ahead> ahead / <behind> behind upstream/main, last reconciled <days>d ago (<date>)` - the always-on FYI variant: firstmate's OWN repo tracking how far it has drifted from its read-only upstream template (`kunchenguid/firstmate`, the `upstream` remote after the remote swap).
+  It prints every session; record it silently like any capability fact and take no action while the wording stays FYI.
+  It only reports - the network fetch that refreshes the ref runs in the locked fleet-sync sweep, and reconciling upstream is never a bootstrap side effect.
+- `UPSTREAM_DRIFT: this repo's upstream sync needs attention - ...` - the escalated variant (local main more than ~30 commits behind `upstream/main`, or the merge-base older than 10 days).
+  Surface it to the captain in plain outcome language and, on their go-ahead, dispatch a deliberately-reviewed firstmate-repo reconciliation ship task - fetch `upstream`, merge it into local `main`, resolve conflicts, and land local-only (`AGENTS.md` section 1) - the same shape that reconciled the divergence before.
+  Never automate the merge; keeping the gap small also keeps the pipeline's opportunistic upstream PR's diff clean (`AGENTS.md` section 1).

.agents/skills/harness-adapters/SKILL.md

@@ -132,6 +132,13 @@ Its broader dark-TRUECOLOR placeholder handling and dark-theme tradeoff are docu
 That styled capture is internal to the boolean detector only.
 `fm-peek` and every other human or LLM-facing capture path stays plain `tmux capture-pane` with no escape codes.
 
+**Auto-compaction fact (verified 2026-07-09, Claude Code 2.1.206; shipped constant raised to 300000 2026-07-11).**
+`bin/fm-spawn.sh` launches every claude crewmate and secondmate with `CLAUDE_CODE_AUTO_COMPACT_WINDOW=300000`, scoped the same way as `CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=false` above, so these separately-launched processes auto-compact around 300k tokens the way the primary already does via its own `.claude/settings.local.json` (which they never inherit).
+The var is read once at process startup and is capped at the model's real context window, so it can only lower the effective trigger, never raise it past the real ceiling: `min(300000, window)` is `300000` once `window` exceeds it, but a no-op (stays at `window`) below that.
+This is not a universal guarantee for every possible future model choice - a differently-configured account/model capped at the plain ~200k window would see no change - but it is true for the window tier crew actually runs on today: `--model sonnet` on this account, the standard crewmate spawn, resolves to the ~1M-context beta, well above 300000.
+Verified live in a tmux pane at the original 200000 value (the mechanism is unchanged, only the shipped constant moved to 300000): `claude --model sonnet` on this account resolves to a ~967k-token auto-compact window with no override (`/context` reported `Auto-compact window: 967k tokens`, i.e. the 1M-context beta, not the 200k a plain Sonnet window would imply); relaunched with `CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000` set, `/context` reported `39.5k/200k tokens (20%)` and `Auto-compact window: 200k tokens` - the window pinned to the override as expected.
+This is why the primary's own two-var form (`CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000` + `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=20`) is not copied here: that pair assumes a 1M window, and would silently cap a smaller-window model/account combination to a far more aggressive trigger.
+
 **Primary-session guard fact (verified 2026-07-04, Claude Code 2.1.201; preserved 2026-07-08, Claude Code 2.1.204).**
 This is separate from the per-task crewmate turn-end hook above (that one just `touch`es a marker file in a task's own `.claude/settings.local.json`).
 The firstmate PRIMARY's own `.claude/settings.json` registers `bin/fm-turnend-guard.sh` as a Stop hook, and exiting with status 2 plus stderr reliably forces the model to continue.

.agents/skills/updatefirstmate/SKILL.md

@@ -18,6 +18,9 @@ It never forces, never creates a merge commit, never stashes, and advances a tar
 A tracked-files fast-forward leaves the gitignored operational dirs (data/, state/, config/, projects/, .no-mistakes/) untouched, so a secondmate's in-flight work is never disrupted.
 This touches only the firstmate repo and its own worktrees, never anything under `projects/`.
 
+Post-swap, this pull follows `origin`, which is the captain's fork, so `/updatefirstmate` converges the whole fleet onto that fork and does nothing on the primary checkout, which is itself the source every fork tracks.
+It deliberately never reaches for the read-only `upstream` template: folding template improvements into local `main` is a separate, reviewed reconciliation ship task, the one the `UPSTREAM_DRIFT:` bootstrap diagnostic surfaces, and it never rides in on a self-update.
+
 ## What it does
 
 1. **Run the updater:**

.agents/skills/verify-trivial/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: verify-trivial
+description: >-
+  Agent-only Light verification tier for a task dispatched at the trivial (haiku/low) model/effort tier.
+  Use when authoring or filling in a Light-tier brief's Task section (a brief scaffolded with `bin/fm-brief.sh --light-verify`), when working a task whose brief points here, or when reviewing such a task's done report before PR-ready.
+  Cites `verify-rigorously` for the AC bar, its 3 verification shapes, its pass/fail matrix, and its "what wasn't verified" footer; layers 3 deltas on top: a cap of 3 acceptance criteria instead of an uncapped set, a 3-attempt cap-out that escalates the task's tier rather than failing it outright, and a mandatory side-effect confidence gate before shipping.
+user-invocable: false
+metadata:
+  internal: true
+---
+
+# verify-trivial
+
+Light verification tier for a task dispatched at the trivial (haiku/low) model/effort tier (see `AGENTS.md` section 7's escalation-trigger paragraph).
+Such a task is scaffolded with `bin/fm-brief.sh --light-verify`; its brief points here instead of the default, uncapped verification workflow.
+
+## Cite, don't copy
+
+Load `verify-rigorously` and apply it in full: named observable pass/fail acceptance criteria, one of its 3 verification shapes per criterion, the criterion x shape pass/fail matrix, and the closing "what wasn't verified" footer.
+This skill does not restate that contract - `verify-rigorously` is its sole owner.
+Everything below is a delta on top of it that applies only to a Light-tier task.
+
+## Delta 1: cap acceptance criteria at 3
+
+Name at most 3 acceptance criteria, not verify-rigorously's uncapped set.
+A trivial-tier task is scoped small enough by definition (`bin/fm-tier-guard.sh`'s envelope: at most 2 changed files, at most 30 changed lines) that 3 observable criteria should describe "done" completely.
+If the task genuinely needs more than 3 to state what done means, that is itself a signal the task has outgrown the trivial tier: report it per Delta 2 instead of naming a 4th criterion.
+
+## Delta 2: a 3-attempt cap-out escalates, it does not fail
+
+verify-rigorously's own 3-attempt cap says: stop and report what's failing, what was tried, and the likely cause.
+On the Light tier, that report is not a terminal failure - it is a request to escalate the task off this tier.
+Append `needs-decision: {criterion} failed verification after 3 attempts, requesting escalation to a heavier tier` (or `blocked:` if the same obstacle recurred, per the brief's own rule for that case) and stop; do not report `failed:` for a cap-out alone.
+Firstmate escalates the task's model/effort in place per `AGENTS.md` section 7's escalation-trigger paragraph, exactly as a `bin/fm-tier-guard.sh` envelope escalation would, and the task continues under the ordinary uncapped `verify-rigorously` workflow from there.
+Never drop the task back to the Light tier afterward - this mirrors section 7's "never silently de-escalate for the rest of that task's life."
+
+## Delta 3: mandatory side-effect confidence gate before shipping
+
+Before reporting `done:` (ship tasks) or writing the report (scout tasks), state explicitly, in one line, whether the change has any side effects outside the files it touches - a shared config default, a migration, a public interface, a cross-task or cross-project coupling - and your confidence in that assessment.
+An unstated "no side effects" is not the same as a stated one: silence here is exactly the gap verify-rigorously's own footer warns against, so this gate is mandatory even when the answer is "none found."
+If confidence is anything less than high, that uncertainty is itself grounds for a Delta 2 escalation rather than shipping on the Light tier.
+
+## Wiring this tier's no-mistakes validation
+
+For a no-mistakes-mode ship task on this tier, firstmate's validation trigger skips the document step (`no-mistakes axi run --skip=document`): the side-effect confidence gate above already covers what that step would otherwise catch at this tier's scale.
+This is firstmate's own action at Validate time (`AGENTS.md` section 7), not something the crewmate invokes itself.

.gitignore

@@ -16,3 +16,4 @@ config/backend
 config/x-mode.env
 config/cmux-socket-password
 config/wedge-alarm
+config/critical-services