0.5. **Inter-wave worktree base re-check (wave N+1 guard — #1369):**

   After Wave N merges and tracking commits advance orchestrator HEAD, Claude Code's
   `isolation="worktree"` still forks new worktrees from `origin/HEAD` (the "fresh" base),
   not the live HEAD. This means Wave N+1 worktrees would be created from the stale
   pre-Wave-N base, causing the `worktree_branch_check` guard inside each executor to halt
   immediately with a base-mismatch fatal.

   **Run this check at the start of every wave when `USE_WORKTREES != "false"` and
   `RUNTIME = "claude"`**, including Wave 1 (where it mirrors the initialize-step check):

   ```bash
   if [ "$RUNTIME" = "claude" ] && [ "${USE_WORKTREES:-true}" != "false" ]; then
     _WAVE_DEGRADE=$(ferrox_run query worktree.base-check --pick shouldDegrade 2>/dev/null || true)
     if [ "$_WAVE_DEGRADE" = "true" ]; then
       _WAVE_DEGRADE_MSG=$(ferrox_run query worktree.base-check --pick message 2>/dev/null || true)
       [ -n "$_WAVE_DEGRADE_MSG" ] && printf '%s\n' "$_WAVE_DEGRADE_MSG" >&2
       echo "⚠ [#1369] Worktree fork base diverged from orchestrator HEAD (wave merges advanced HEAD past origin/HEAD). Auto-degrading to sequential mode for this wave to avoid base-mismatch halts." >&2
       USE_WORKTREES=false
     fi
   fi
   ```

   If `shouldDegrade` is `true`, override `USE_WORKTREES=false` for **this wave only** —
   all plans in this wave execute sequentially on the main working tree. Later waves re-run
   this check and may re-enable worktree isolation if `origin/HEAD` is updated (e.g. via
   `git fetch` or `worktree.baseRef:"head"` config).

   **To avoid this degrade across all waves:** set `worktree.baseRef:"head"` in
   `.claude/settings.local.json` (or run `ferrox-tools worktree set-baseref`). This tells
   Claude Code to fork from the live HEAD instead of `origin/HEAD`, so each wave's new
   worktrees always start from the correct post-merge base. See #683 for the base-ref
   configuration detail.

## Model-tiering wave guard (MODEL-03/04/05)

Before dispatching a wave, the execute layer **CONSULTS
`ferrox-tools query model.risk-grade`** with the wave's touched paths/categories. When any
path touches a `model.risk_boundaries` entry (auth/crypto/payments/pii/deserialization/
network-file), the verb returns `high-risk` with `forcesFrontier` and `forcesTrident`
true — the wave's build agents are spawned at the **frontier** tier and the
`high-risk-wave-audit` checkpoint runs a bounded cross-lineage **`ferrox-tools query
trident.audit`** pass (a single pass, caller family excluded — see
[gates.md](gates.md) and [model-tiering.md](model-tiering.md)). A boundary hit forces this
REGARDLESS of a low self-declared grade.

Shell/dev operations inside the execute layer route through **`ferrox-tools query
rtk.wrap`** (RTK wraps the Bash/dev op layer — MODEL-05): when `model.rtk.enabled` is true
AND rtk is present the op is wrapped, and it **degrades to a graceful passthrough** (the
original command unchanged) when rtk is absent or the flag is off, so a wave still runs on
a machine without rtk. Savings are reported from rtk's own output via
`ferrox-tools query rtk.report`. See [model-tiering.md](model-tiering.md) for the verbs
and the emitted tokens.