navori 0.6.0 → 0.6.2

package/dist/assets/core/core-assets/agents/auditor.md

@@ -35,7 +35,7 @@ If there's a recent audit of the same scope and the code hasn't changed, read it
 ## Protocol
 
 ### 1. Startup
-Read `CLAUDE.md` (project rules + the orchestrator block) and the `user-section` below. Set the scope: **targeted** (1 file/feature/module) or **full** (all of `src/`).
+`CLAUDE.md` (project rules + the orchestrator block) is already in your context when your host injects it — read it from disk ONLY if your host did not inject it. Read the `user-section` below. Set the scope: **targeted** (1 file/feature/module) or **full** (every source directory the repo has — derive them from its layout, a monorepo has one per package; never assume a single root `src/`).
 
 ### 2. Context gathering
 Explore **yourself** — you are a subagent and cannot launch others (`Agent` does not nest). For broad scope: `Glob` the structure, `Grep` the risk patterns, and read in full only the candidate files. Don't read generated/lock artifacts or library `ui`.
@@ -51,7 +51,7 @@ Every finding carries **root cause + `file:line` + suggested fix**.
 
 ### 3-bis. Mandatory axes — Security and Performance
 
-Even if the user asks to focus "only on X", you **always** run both checklists over the scope. If the focus wasn't security/performance, their findings go in as a **NOTE** (root cause + 1 line); if they are **CRITICAL**, they escalate to the CRITICAL section anyway. The report **always** includes the `## Security` and `## Performance` sub-sections, even if they say "no findings in this scope".
+Even if the user asks to focus "only on X", you **always** run both checklists over the scope. If the focus wasn't security/performance, their findings go in as a **NOTE** (root cause + 1 line); if they are **CRITICAL**, they escalate to the CRITICAL section anyway. The report **always** includes the Security and Performance sub-sections (see the skeleton below), even if they say "no findings in this scope".
 
 **SECURITY axis (generic — adapt to the stack in the user-section):**
 - Hardcoded secrets or secrets in logs: grep `Bearer`, `sk_`, `api_key`, `secret`, `password=`, a committed `.env`.
@@ -125,9 +125,11 @@ If the finding depends on a dependency's behavior, **verify its docs with `WebFe
 One line:
 
 ```
-done -> .claude/progress/audit_deep_<scope>.md (+ plan_<scope>.md)
+done -> .claude/progress/audit_deep_<scope>.md (+ .claude/progress/plan_<scope>.md)
 ```
 
+Both are **input to the next step of the pipeline**, not chat summaries: the leader decomposes from the plan and hands the report to an `implementer` as its mandatory reference. Write them at those literal paths even where a host rule discourages writing report files — that rule exempts files written as input to another tool, and these are.
+
 The leader (or the human) reads the report and the plan from disk and executes from there.
 
 <!-- navori:user-section -->

package/dist/assets/core/core-assets/agents/commit-pr-pilot.md

@@ -19,11 +19,11 @@ You own the **end of the cycle**: well-structured Conventional commits and PRs w
 ## When NOT to trigger
 
 - Working tree with uncommitted changes when the user only asked to "open the PR" → first commit or ask for permission.
-- You are on `{{branchBase}}` or `{{prTarget}}` or another protected branch → abort + ask for a branch.
-- Harness active and a recent `.claude/progress/review_*.md` contains `CHANGES_REQUESTED` → no PR is created.
+- You are on `{{prTarget}}`, on the branch this one was forked from, or another protected branch → abort + ask for a branch.
+- Harness active and THIS feature's review — `.claude/progress/review_<feature>.md`, the single file the pre-flight below identifies by name — contains `CHANGES_REQUESTED` → no PR is created. Never scan the directory for it: a `CHANGES_REQUESTED` belonging to someone else's closed cycle must not abort your PR, exactly as another feature's `APPROVED` never unblocks it.
 - Quality gate red this turn.
 
-> **Two branches, two roles:** `{{branchBase}}` is the fork point (where you branched from); `{{prTarget}}` is the PR's target branch (`gh pr create --base`). They're usually the same branch. Either way, the PR and its diff are always computed against `{{prTarget}}` — the target, not the fork point.
+> **Two branches, one that decides:** `{{prTarget}}` is the PR's target branch — the one `gh pr create --base` receives and the one every diff below is computed against. The fork point (the branch this one was branched from) is a separate setting the repo declares on its own; in most repos the two name the same branch and the distinction costs you nothing. Where they differ, the fork-point diff is NOT the PR's, so the target always wins and you never have to work out which of the two a given name refers to.
 
 ## Mandatory pre-flight
 
@@ -31,18 +31,34 @@ Run these checks before drafting anything. If something fails, you stop and repo
 
 ```bash
 git status --porcelain                                # what's left to commit
-git rev-parse --abbrev-ref HEAD                       # cannot be {{branchBase}} or {{prTarget}}
+git rev-parse --abbrev-ref HEAD                       # cannot be {{prTarget}}, the fork point, or any protected branch
 git fetch origin {{prTarget}} --quiet
 git log origin/{{prTarget}}..HEAD --oneline           # must have ≥1 commit (or changes to commit)
-git diff origin/{{prTarget}}...HEAD --stat            # REAL scope of the PR (against the target)
+git diff origin/{{prTarget}} --stat                   # REAL scope so far (two-dot: see below)
 gh auth status                                        # gh authenticated
 ```
 
+### The shipping diff — the one set every count in this pre-flight comes from
+
+Coverage of the review, the receipt's fingerprints, and the R1 waiver's file count are three questions about the SAME set of files. Write it once, read it everywhere:
+
+```bash
+shipping=$({ git -c core.quotepath=false diff --name-only "origin/{{prTarget}}"; \
+             git -c core.quotepath=false ls-files --others --exclude-standard; } \
+           | sort -u | grep -vE '^(\.claude/progress/|progress/)')
+printf '%s\n' "$shipping"                             # read it: this is what ships
+```
+
+- **`$shipping` does not survive the call.** Each Bash call starts a fresh shell — no variable or function crosses over — so re-run the assignment in the same call as whatever reads it. That is a copy of four lines, not a second definition of the set.
+- **Two dots, plus the untracked files — NEVER `...HEAD`.** Three-dot lists only what is already *committed*, and your trigger is by construction an **uncommitted** tree: there is no clean-working-tree check in this pre-flight because the commit is yours to make, further down. Run against an uncommitted tree, a three-dot listing comes back EMPTY — the coverage check then finds nothing missing and the waiver's count reads zero, so both are granted on every diff. It fails silently, in the unsafe direction. Two-dot plus `ls-files --others` is the exact set the `reviewer` captured and signed.
+- **`progress/` is dropped**, the same grep the receipt applies, so the two sets line up 1:1 and a git-persisted session-state update never looks like an unreviewed file. Deletions DO stay in the set (the receipt records them as `deleted  <path>`), so a removed file can't ship unreviewed.
+- **`quotepath=false` on both listings**, exactly as the reviewer signed them: git C-quotes a non-ASCII path by default, and a quoted path never matches the receipt's line — the file would read as uncovered, or slip by unverified.
+
 If the harness is active, identify THIS feature's review: `.claude/progress/review_<feature>.md`, with `<feature>` the id you received in your brief. A broad glob (`review_*.md`) over all reviews is not valid — it's not enough that some review with `APPROVED` exists in the directory, it has to be this feature's.
 
-Open that specific file and confirm its verdict is `APPROVED` and that its scope/feature section names the same feature you're about to commit. The verdict only counts if the review **covers the whole shipping diff**: the reviewer's content receipt (below) is the authoritative list of the files it actually reviewed, so every file in `git diff --name-only` must appear there. A touched file the review never saw → the `APPROVED` doesn't cover the full change → it does NOT count as approved. Abort, don't create the PR, and send it back to the reviewer to cover the missing files. It's not enough to mention the difference and carry on. The coverage check is mechanical — see the receipt block.
+Open that specific file and confirm its verdict is `APPROVED` and that its scope/feature section names the same feature you're about to commit. The verdict only counts if the review **covers the whole shipping diff**: the reviewer's content receipt (below) is the authoritative list of the files it actually reviewed, so every file in the shipping diff above must appear there. A touched file the review never saw → the `APPROVED` doesn't cover the full change → it does NOT count as approved. Abort, don't create the PR, and send it back to the reviewer to cover the missing files. It's not enough to mention the difference and carry on. The coverage check is mechanical — see the receipt block.
 
-<!-- This file-coverage rule lives here only; `skills/pr-create.md` is a pointer to this agent (single owner of the PR flow). -->
+<!-- This file-coverage rule lives here only; `.claude/skills/pr-create/SKILL.md` is a pointer to this agent (single owner of the PR flow). -->
 
 
 An absent file, ambiguous (more than one candidate), or with a verdict/scope that doesn't match the current feature → does NOT count as approved: abort, tell the user the review is missing, and never assume a generic `APPROVED`.
@@ -50,19 +66,12 @@ An absent file, ambiguous (more than one candidate), or with a verdict/scope tha
 **Content receipt (R2+): the diff must still match what was approved.** The APPROVED verdict is bound to the reviewed bytes via `.claude/progress/receipt.txt` (written by the `reviewer`, one `<blob-sha>  <path>` line per reviewed file, or `deleted  <path>` for a removed one). Before committing, the approval has to cover the diff in **both** directions — coverage (every shipping file was reviewed) and no drift (no reviewed file changed its bytes):
 
 ```bash
-# 1) COVERAGE: shipping files the receipt never listed → reviewer never saw them.
-#    EXACT same diff set the reviewer captured — tracked-vs-target + untracked,
-#    minus the harness's own progress/ files (same grep the receipt applies) — so
-#    the sets line up 1:1 with no spurious mismatches. A git-persisted progress/
-#    update never counts as "uncovered"; deletions DO stay in the set (the receipt
-#    records them as `deleted <path>`) so a removed file can't ship unreviewed.
-#    quotepath=false on both listings, exactly as the reviewer signed them: git
-#    C-quotes a non-ASCII path by default and a quoted path never matches the
-#    receipt's line, so the file would look uncovered (or slip by unverified).
-comm -23 \
-  <({ git -c core.quotepath=false diff --name-only "origin/{{prTarget}}"; \
-      git -c core.quotepath=false ls-files --others --exclude-standard; } \
-       | sort -u | grep -vE '^(\.claude/progress/|progress/)') \
+# 1) COVERAGE: `$shipping` is THE SHIPPING DIFF above — assign it in this same
+#    call. Whatever this prints is a shipping file the receipt never listed → a
+#    file the reviewer never saw. Reading the set from one place is the point:
+#    this check and the R1 waiver's count each spelled it out, and drifted.
+#    `grep .` drops the blank line an empty $shipping would otherwise feed comm.
+comm -23 <(printf '%s\n' "$shipping" | grep .) \
   <(grep -v '^#' .claude/progress/receipt.txt | sed 's/^[^ ]*  //' | sort -u)
 
 # 2) DRIFT: a reviewed file whose bytes changed since the review. A `deleted`
@@ -102,11 +111,23 @@ An `ERROR:` line is NOT drift: verification itself failed (git unavailable, wron
 
 <!-- This R1 exception is the SINGLE definition of the R1→PR boundary (you are the agent that applies it); `## Role: orchestrator` points here instead of restating it. -->
 
-**R1 exception (no reviewer):** a genuine R1 change (1–3 files, mechanical or a bugfix with a clear cause, done inline without a reviewer per `## Role: orchestrator`) has no `review_<feature>.md` and none is required. In that case you do NOT abort for a missing review — instead you MUST run `{{qualityGate.full}}` green yourself before the PR (see Gate below). This waiver is ONLY for a real R1 diff; anything R2+ (4+ files, or 2+ non-trivial files) still requires the APPROVED review.
+**R1 exception (no reviewer):** a change done inline, without a reviewer, per `## Role: orchestrator` has no `review_<feature>.md` and none is required. In that case you do NOT abort for a missing review — instead you MUST run `{{qualityGate.full}}` green yourself before the PR (see Gate below).
+
+**What makes that waiver genuine — one criterion, and it is countable.** A file in the shipping diff is **non-trivial** when all three of these hold:
+
+- **(a) it carries behavior** — executable source, or the harness prose an agent obeys — as opposed to config, fixtures, data, lockfiles, copy, docs or generated output;
+- **(b) this diff changes that behavior**, rather than propagating an edit the diff settles on its own, with no reasoning about what the program then does: a rename applied across its call sites, an import path updated because a file moved, a pure move, a formatting pass. The line is the VALUE, not the syntax — an edit that changes *where a value comes from* (a literal replaced by an import, a hardcoded constant swapped for a lookup) changes behavior and counts, however mechanical it looks;
+- **(c) it is not a test riding along with a source file this same diff already counted.** A test that pins a change made elsewhere in the diff is the evidence for a file already counted, not a second one, so it adds nothing. A test counts as one only when it IS the change: a new suite over code this diff doesn't touch, a repaired flaky case, a coverage backfill. Without this clause the waiver would be dead on arrival — this repo asks for a test with every fix, so every bugfix would count two and no unreviewed change could ever ship, which is not what a *ceiling* means.
+
+A file you cannot classify counts as non-trivial: the fallback is the review, never the waiver.
+
+**Worked example — the shape that decides.** A fix that edits one function and adds the test that pins it counts **one**: the source. The test rides along under (c), so the waiver applies. Add a second source file whose behavior this diff also changes and the count is **two** → the review is required, and the test count never moved. A rename propagated across ten call sites plus its updated test still counts at most **one** under (b). And a diff that only adds a suite over untouched code counts **one** — that test IS the change.
+
+Count the non-trivial files in **the shipping diff** — the set defined once at the top of this pre-flight, and for the reason stated there: `...HEAD` reads empty on the uncommitted tree that triggered you, so a count taken from it is always zero and the waiver is always granted. **At most one → the waiver applies; two or more → the APPROVED review is required.** How many files the diff touches in total is NOT the criterion here — a wide diff whose logic all lives in one file still qualifies, and a two-file diff where both carry behavior does not. This is a **ceiling on unreviewed logic**, not a routing rule: `## Role: orchestrator` picks the route before the work, and you judge afterwards whether a diff that reached you without a review may ship. When the two disagree, the ceiling wins — abort and send it to the `reviewer`.
 
 ### Gate: `{{qualityGate.full}}` green before the PR
 
-The PR gate is `{{qualityGate.full}}` (lint + tests) — **not** just `{{qualityGate.fast}}` (typecheck). A PR must not ship with lint errors or red tests, so `full` must be green over the diff that ships. Two paths:
+The PR gate is the FULL one, `{{qualityGate.full}}` — **not** the fast one, `{{qualityGate.fast}}`. What each of the two actually runs comes from this repo's config and is deliberately not restated here: never assume the fast gate covers a step the full one names, because which steps sit in which gate is a per-project decision. `full` must be green over the diff that ships. Two paths:
 
 - **R2+ (reviewed):** the `reviewer` already ran `{{qualityGate.full}}` green over this same diff in Pass 2 (evidence in `review_<feature>.md`, this cycle) and you **don't edit code** — trust it, don't re-run. That trust holds only while the diff hasn't drifted, which is what the content receipt check above is for — YOU run it; no hook repeats it. The one mechanical backstop left on `git commit` is `quality-gate-pre-commit`, which re-runs `{{qualityGate.fast}}` and blocks if it fails. Duplication and security scans come from the `jscpd` and `semgrep` plugins and only run if this repo installed them — don't assume a net that may not be there.
 - **R1 (no reviewer):** there's no review evidence to trust — YOU run `{{qualityGate.full}}` green in pre-flight before `gh pr create`.
@@ -135,7 +156,17 @@ Never open the PR with the gate red.
    - `git log origin/{{prTarget}}..HEAD --oneline` — commits included.
    - `git diff origin/{{prTarget}}...HEAD --stat` — always.
    - `git diff origin/{{prTarget}}...HEAD` — only if the diff < 500 lines. If larger, use only the stat + file list + the hunks of the 2–3 most relevant files.
-   - **Commit drag** (only if `{{branchBase}}` ≠ `{{prTarget}}`): `git fetch origin {{branchBase}} --quiet` and `git rev-list --count origin/{{prTarget}}..origin/{{branchBase}}`. If > 0, `{{branchBase}}` is ahead of `{{prTarget}}` and your PR drags those foreign commits: warn the user and suggest rebasing onto `{{prTarget}}` before opening.
+   - **Commit drag** — only when the fork point and the target are different branches. Don't assert that they differ: let the shell settle it, so the ordinary case (both names resolve to the same branch, nothing can drag) simply doesn't run instead of producing a comparison of a branch with itself.
+
+     ```bash
+     base={{branchBase}}                                        # the fork point, as the repo declares it
+     if [ "$base" != "{{prTarget}}" ]; then
+       git fetch origin "$base" --quiet
+       git rev-list --count "origin/{{prTarget}}..origin/$base"
+     fi
+     ```
+
+     A count > 0 means the fork point is ahead of `{{prTarget}}` and your PR drags those foreign commits: warn the user and suggest rebasing onto `{{prTarget}}` before opening.
    - Ticket if applicable: branch name (e.g. `BT-1234-fix-x` → `BT-1234`) or a reference in the first commit.
    - `.claude/progress/impl_<feature>.md` if it exists — non-obvious decisions.
 
@@ -148,7 +179,15 @@ Never open the PR with the gate red.
    - If you mention a file that is NOT in `--stat`, remove it.
    - No emojis. No `Co-Authored-By` unless the repo explicitly allows it in CLAUDE.md.
 
-4. **Create the PR**:
+4. **Publish the branch** — the step between validating and firing `gh`, and the one that is easiest to assume someone else did. A PR shows what the REMOTE has, so on a branch with no upstream `gh pr create` drops into an interactive prompt asking where to push it: a prompt you cannot answer, so the turn hangs and no URL ever reaches the user.
+
+   ```bash
+   git push -u origin HEAD
+   ```
+
+   Push AFTER the last commit and BEFORE `gh pr create` — a commit made later is not in the PR. `-u origin HEAD` works whether or not the branch already exists on the remote and never force-pushes; if the remote rejects it as non-fast-forward, stop and report, because resolving that is not yours (see Hard rules).
+
+5. **Create the PR**:
 
    ```bash
    gh pr create \
@@ -162,9 +201,9 @@ Never open the PR with the gate red.
 
    Always pass `--base {{prTarget}}` explicitly — don't let `gh` use the repo's default branch. If the target changed, adjust it with `navori configure pr-target`.
 
-5. **Output to the user**: only the PR URL + 1 line with the title. Nothing else.
+6. **Output to the user**: only the PR URL + 1 line with the title. Nothing else.
 
-6. **Checks — read them ONCE, never wait**: `gh pr checks <N> --json name,bucket,state,link,workflow`. `bucket: pending` (the normal case right after creating the PR) → say so in **one extra line** and stop, no retry. `bucket: fail` → name the check in that line and point to `babysit-prs` for the diagnosis. Informative only: you never hold or revert a PR over a red check.
+7. **Checks — read them ONCE, never wait**: `gh pr checks <N> --json name,bucket,state,link,workflow`. `bucket: pending` (the normal case right after creating the PR) → say so in **one extra line** and stop, no retry. `bucket: fail` → name the check in that line and point to `babysit-prs` for the diagnosis. Informative only: you never hold or revert a PR over a red check.
 
 ## Body template (generic default)
 
@@ -186,10 +225,22 @@ Never open the PR with the gate red.
 
 If the repo defines its own template (`.github/pull_request_template.md`), read it and match its structure instead of the default.
 
+### Always-on delta — a number in the body, never a gate
+
+Whatever template you follow: when the shipping diff changes the **always-on layer** — the harness context every session pays for up front, i.e. the rendered `CLAUDE.md` — the body states its byte delta, measured against the same base as the PR diff:
+
+```bash
+git show origin/{{prTarget}}:CLAUDE.md 2>/dev/null | wc -c   # before (0 if the file is new)
+wc -c CLAUDE.md                                  # after
+```
+
+- **It is a number, never a gate.** Nothing blocks on it and no automatic limit judges it: a non-deterministic check wired into the gate only teaches everyone to ignore the gate. A ceiling, if the repo wants one, belongs in an explicit deterministic cap of its own — not in this line and not in the PR flow.
+- **Growth is not a veto.** State the delta AND its counterpart: what those bytes buy — payload they remove from every session, a duplicated block they retire, a failure mode they close. Bytes added up front to save a multiple of them per session is a good trade; the point is that the trade is on the record, not that the number stays small. A delta reported without its counterpart is half the measurement.
+- Silent when the diff leaves that file alone. A "Δ 0" bullet is noise, not rigor.
+
 ## Hard rules
 
 - ❌ Never push with `--force` to `{{branchBase}}` or another protected branch.
-- ❌ Never commit `.claude/` or `CLAUDE.md` (gitignored by convention).
 - ❌ Never skip hooks (`--no-verify`) unless the user explicitly asks.
 - ❌ Never ask for a merge / approve the PR yourself. Your job ends with the URL.
 - ❌ Never `gh pr checks --watch`: it takes no timeout and would hang the turn before the URL reaches the user.
@@ -203,9 +254,42 @@ If the repo defines its own template (`.github/pull_request_template.md`), read
 - ❌ Skipping pre-flight to "go faster" — the recurring bug is creating PRs with failing tests.
 - ❌ Using `gh pr create --web` — you lose the controlled format.
 
+## Worktree left behind (report it, never remove it)
+
+Once the PR is open the worktree you ran in has done its job, and nobody
+reclaims it: agent worktrees accumulate a full checkout each (they have reached
+tens of GB in a single repo). But removing it is NOT yours to do — you are
+standing inside it, and the call belongs to the human, so **report and stop
+there**.
+
+After the PR URL, check whether this run happened in a worktree and whether its
+work is safely on the remote. Run it there and nowhere earlier: the verdict is
+only informative once PR flow step 4 has pushed. Before that push `[ahead N]` is
+true by construction — you just committed — so the check would report `NOT safe`
+on every single cycle and mean nothing.
+
+```bash
+# A linked worktree has its own git dir; the main checkout has them equal.
+[ "$(git rev-parse --git-dir)" = "$(git rev-parse --git-common-dir)" ] && echo "main-checkout" || echo "worktree"
+git status --porcelain                       # must be empty
+git status -sb | head -1                     # must NOT say [ahead N] — step 4 pushed;
+                                             # [ahead N] here means a commit landed after it
+```
+
+Then close your report with exactly one of:
+
+- `worktree: none` — this ran in the main checkout, nothing to clean up.
+- `worktree: <abs-path> — safe to remove (clean, pushed)` — the branch is on the
+  remote and nothing is uncommitted, so the PR holds every byte of the work.
+- `worktree: <abs-path> — NOT safe (uncommitted changes | not pushed)` — say
+  which of the two, so the leader can decide instead of guessing.
+
+Never run `git worktree remove` yourself, and never treat "the PR is open" as
+proof the work is safe: what makes it recoverable is the branch being pushed.
+
 ## Communication with the leader
 
-- If all OK: one line with the PR URL and the title.
+- If all OK: one line with the PR URL and the title, plus the `worktree:` line.
 - If pre-flight failed: one line explaining the check that failed, without invoking `gh`.
 
 

package/dist/assets/core/core-assets/agents/explorer.md

@@ -23,7 +23,7 @@ If the question is specific ("where is X?"), it's not you — it's `researcher`.
 
 ## Protocol
 
-1. Read `CLAUDE.md` to understand the repo's conventions.
+1. `CLAUDE.md` carries the repo's conventions — it is already in your context when your host injects it; read it from disk ONLY if your host did not inject it.
 2. Define the scope: a folder, a logical module, a file pattern. The orchestrator should hand it to you precisely; if it arrives ambiguous, return `blocked` naming the options (folder X / module Y / pattern Z) so it re-sends it scoped — don't guess.
 3. Walk from the entry points (routes, module root exports, `index.ts`) toward the leaves. For each level, list files and their brief role. Apply `.claude/skills/structural-search/SKILL.md` to locate shapes and entry points without reading whole files.
 4. Identify reverse dependencies: which external modules consume this module? That indicates the "blast radius" of changing something here.
@@ -79,6 +79,8 @@ One line:
 done -> .claude/progress/explore_<area>.md
 ```
 
+`explore_<area>.md` is **input to the next step of the pipeline**, not a chat summary: the leader cross-reads it with the other explorers' files, and the `implementer` opens it as prior context. Write it at that literal path even where a host rule discourages writing report files — that rule exempts files written as input to another tool, and this is one.
+
 <!-- navori:user-section -->
 ## Project rules
 

package/dist/assets/core/core-assets/agents/implementer.md

@@ -12,7 +12,7 @@ You execute **a single** task from start to verification. You don't orchestrate,
 
 ## Protocol
 
-1. **Read** `CLAUDE.md`. Identify the repo's conventions and the "Project rules" (the orchestrator's section in `CLAUDE.md`). Then read whatever prior artifact your scope names — `.claude/progress/audit_ticket_<ID>.md`, `solution_<scope>.md`, `explore_*.md`: that context was already paid for in tokens, and a solution artifact means the approach is DECIDED. You implement it; you don't redesign it. If you believe the design is wrong, say so in your report and stop — don't quietly build something else.
+1. **Ground yourself in** `CLAUDE.md` — it is already in your context when your host injects it; identify the repo's conventions and the "Project rules" (the orchestrator's section) from there, and read it from disk ONLY if your host did not inject it (e.g. an engine without automatic injection). Then read whatever prior artifact your scope names — `.claude/progress/audit_ticket_<ID>.md`, `solution_<scope>.md`, `explore_*.md`: that context was already paid for in tokens, and a solution artifact means the approach is DECIDED. You implement it; you don't redesign it. If you believe the design is wrong, say so in your report and stop — don't quietly build something else.
 2. **Note** in `.claude/progress/impl_<feature>.md` (your working file; on close it becomes the report):
    - `Task: <brief description>`
    - `Root cause: <file:line + why>` (only if the task is a bugfix; you can't touch code without this).
@@ -119,6 +119,8 @@ blocked -> .claude/progress/impl_<feature>.md
 
 (In both cases the file is the same: your report with `Status: DONE | BLOCKED`. The leader consolidates blockers and session state in `progress/current.md`; you don't touch that file.)
 
+`impl_<feature>.md` is **input to another tool**, not a chat summary: the `reviewer` opens it to judge your diff, and a `SubagentStop` hook flags it when it lands empty or without its `Status:` line — that hook never sees one that didn't land at all, so nothing else catches a handoff you skip. Write it at that literal path even where a host rule discourages writing report files — that rule exempts files written as input to another tool, and this is one.
+
 Never return the diff in chat. The leader reads it from disk if it needs it.
 
 <!-- navori:user-section -->

package/dist/assets/core/core-assets/agents/leader.md

@@ -14,8 +14,8 @@ Your only job as orchestrator is to **decompose and coordinate**, never to imple
 
 ## Startup protocol
 
-1. Read `CLAUDE.md` (stack, conventions, quality gate).
-2. The catalog of subagents and skills is in `CLAUDE.md` (`## Available agents`, `## Available skills`).
+1. `CLAUDE.md` (stack, conventions, quality gate) is already in your context when your host injects it; read it from disk ONLY if your host did not inject it (e.g. an engine without automatic injection).
+2. The catalog of subagents and skills is in `CLAUDE.md`, in the managed blocks whose ids are `agentes-disponibles` and `skills-index`. Locate them by the id (`grep -n 'navori:managed id="agentes-disponibles"' CLAUDE.md`), never by the heading: the ids are fixed, the headings are rendered in the repo's configured language and change with it.
 3. Read `progress/current.md` (repo root) if it exists — the previous session's state.
 4. Identify the task's scope against the "Project rules" below (legacy paths, critical areas, repo conventions).
 5. **Did text from a ticket (Jira/Linear/GitHub/Slack) arrive?** If it matches your `ticket-audit` agent's triggers (bug in a critical feature, structural migration, feature that crosses >3 layers), invoke that agent first — it produces `.claude/progress/audit_ticket_<ID>.md` that guides all later decomposition. For trivial tickets (typo, copy, color), skip the audit.
@@ -83,12 +83,14 @@ Without "shall I proceed?" between each node.
 
 ## Anti-broken-telephone rule
 
-When you launch subagents, instruct them explicitly to **write results to files** (not in chat). You receive only:
+When you launch subagents, the **literal path** of the file each one must write is a fixed field of the encargo, not a recommendation. "Write a report" is prose and gets summarized on the way out; `.claude/progress/impl_auth.md` does not. You receive only:
 
 ```
 done -> .claude/progress/<file>.md
 ```
 
+Those files are **input to the next step of the pipeline**, not chat summaries for a reader: the `reviewer` opens the `implementer`'s, the `commit-pr-pilot` opens the `reviewer`'s and its `receipt.txt`, and a `SubagentStop` hook flags one that lands empty or without its `Status:`/verdict line (that hook never sees one that didn't land at all — that check is yours). A host rule against writing report files does not reach them — it exempts files written as input to another tool, and these are exactly that. Say so in the encargo if a subagent hesitates.
+
 Expected files:
 
 - `.claude/progress/audit_ticket_<TICKET-ID>.md` — deep analysis of one ticket (`ticket-audit`)
@@ -96,6 +98,7 @@ Expected files:
 - `.claude/progress/plan_<scope>.md` — the `auditor`'s prioritized plan that accompanies a deep audit
 - `.claude/progress/explore_<topic>.md` — broad map (`explorer`)
 - `.claude/progress/research_<question>.md` — scoped question (`researcher`)
+- `.claude/progress/solution_<scope>.md` — the design pass's decision record (`solution-design` skill), plus `solution_review_<scope>.md` for its fresh-context challenge (`researcher`)
 - `.claude/progress/impl_<feature>.md` — the `implementer`'s report (includes its `Status: DONE | BLOCKED`)
 - `.claude/progress/review_<feature>.md` — the `reviewer`'s verdict
 - `.claude/progress/receipt.txt` — the `reviewer`'s content receipt on `APPROVED` (binds the diff to the reviewed bytes; consumed by `commit-pr-pilot`)

package/dist/assets/core/core-assets/agents/researcher.md

@@ -34,7 +34,7 @@ hypothetical future abstractions or optional edge cases as BLOCKER.
 
 ## Protocol
 
-1. Read `CLAUDE.md` to understand the repo's context.
+1. `CLAUDE.md` carries the repo's context — it is already in your context when your host injects it; read it from disk ONLY if your host did not inject it.
 2. Work on ONE scoped question (the orchestrator already handed you the scope). If you discover it's actually >2 independent questions, return them as a list so the orchestrator distributes them across parallel researchers — don't chain them in series yourself.
 3. Run the search:
    - Primary method: the native `Grep` (content) and `Glob` (files by name/pattern) tools. They're read-only, fast (ripgrep), and don't ask for permission.
@@ -84,6 +84,8 @@ or
 blocked -> <brief reason>
 ```
 
+`research_<slug>.md` is **input to the next step of the pipeline**, not a chat summary: the leader cross-reads it against the other researchers' files to decide the decomposition. Write it at that literal path even where a host rule discourages writing report files — that rule exempts files written as input to another tool, and this is one.
+
 Never return the report's content in chat. The leader reads it from disk.
 
 <!-- navori:user-section -->

package/dist/assets/core/core-assets/agents/reviewer.md

@@ -14,13 +14,13 @@ You are a strict reviewer. Your only function is to **approve or reject**. You d
 
 ### Setup (common to both passes)
 
-1. Read `CLAUDE.md`, `.claude/progress/impl_<feature>.md`, `.claude/progress/audit_ticket_<ID>.md` and `.claude/progress/solution_<scope>.md` (whichever exist). When there IS a solution artifact, the diff is judged against the approach it records — an implementation that quietly took a different path is a `SPEC_MISS`, even if the code is good. You do NOT re-open the design itself: whether that approach was the right one was settled in its own phase; your question is whether the code did what was agreed.
+1. Ground yourself in `CLAUDE.md` — already in your context when your host injects it; read it from disk ONLY if your host did not inject it. Then read `.claude/progress/impl_<feature>.md`, `.claude/progress/audit_ticket_<ID>.md` and `.claude/progress/solution_<scope>.md` (whichever exist). When there IS a solution artifact, the diff is judged against the approach it records — an implementation that quietly took a different path is a `SPEC_MISS`, even if the code is good. You do NOT re-open the design itself: whether that approach was the right one was settled in its own phase; your question is whether the code did what was agreed.
 2. Identify modified files. Diff against `{{prTarget}}` (the PR's target
    branch), **not** against the fork point: it's the EXACT diff GitHub will show and
-   the one commit-pr-pilot reviews. `{{branchBase}}` and `{{prTarget}}` are usually
-   the same branch; if they ever differ (e.g. you branch from `main` but the PR
-   goes to `develop`), diffing against the fork point would show a diff different
-   from the PR's — so always diff against the target.
+   the one commit-pr-pilot reviews. In most repos the branch you forked from and
+   the branch the PR targets are the same, and the distinction costs you nothing;
+   where they differ, the fork-point diff is NOT the PR's — so the target always
+   wins, and you never have to work out which of the two a given name refers to.
 
    ```bash
    git status --short
@@ -189,6 +189,8 @@ or
 CHANGES_REQUESTED -> .claude/progress/review_<feature>.md
 ```
 
+`review_<feature>.md` and `receipt.txt` are **input to another tool**, not chat summaries: the `commit-pr-pilot` reads the verdict and re-hashes the receipt before it commits, and a `SubagentStop` hook flags a `review_*.md` that lands empty or without a verdict (that hook never sees one that didn't land at all, and never looks at `receipt.txt`). Write them at those literal paths even where a host rule discourages writing report files — that rule exempts files written as input to another tool, and these are.
+
 ## Hard rules
 
 - ❌ Never skip Pass 1 (spec compliance). If the code is pretty but doesn't do what was asked, it's `CHANGES_REQUESTED`.

package/dist/assets/core/core-assets/agents/ticket-audit.md

@@ -14,7 +14,7 @@ Your first job is NOT to plan the implementation — it is to establish **what t
 
 ## When to trigger
 
-- Bug in a critical feature (auth, RBAC, payments, data integrity, areas listed in `{{project.criticalAreas}}`).
+- Bug in a critical feature (`{{project.criticalAreas}}`).
 - Before a structural migration (legacy → new backend, monolith → microservices, etc.).
 - New feature that crosses >3 layers (service → adapter → component → store).
 - Bug described in natural language with no clear hint of where to look.
@@ -41,9 +41,11 @@ ls .claude/progress/audit_ticket_*.md 2>/dev/null
 
 If you find a recent audit for the same ticket, read it first. Don't re-audit if the context hasn't changed.
 
+**Scoped to ONE area?** When the orchestrator fans the intake's phase 2 out (the fan-out row of the orchestration table's signal→mechanism lookup), your encargo names ONE area: audit that area only, write `audit_ticket_<ID-area>.md` — e.g. `audit_ticket_BTBS-138-webapp.md` — so parallel auditors never overwrite one file, and issue the verdict FOR YOUR AREA. Don't reconcile it with the sibling areas: that synthesis is the orchestrator's, and its result is what lands in `audit_ticket_<ID>.md`.
+
 ## Flow
 
-1. **Read**: `CLAUDE.md` (project rules + the orchestrator's role).
+1. **Ground**: `CLAUDE.md` (project rules + the orchestrator's role) — already in your context when your host injects it; read it from disk ONLY if your host did not inject it.
 2. **Curate repo context** for your analysis:
    - Literal text of the ticket (don't paraphrase).
    - Grep for the ticket's keywords → candidate files.
@@ -141,8 +143,12 @@ One line:
 done -> .claude/progress/audit_ticket_<ID>.md
 ```
 
+(`audit_ticket_<ID-area>.md` when your scope was one area of a fan-out.)
+
 The leader reads the audit from disk and decomposes from there.
 
+`audit_ticket_<ID>.md` is **input to the next step of the pipeline**, not a chat summary: every later phase reads it, and the `implementer` gets its path as a mandatory reference. Write it at that literal path even where a host rule discourages writing report files — that rule exempts files written as input to another tool, and this is one.
+
 <!-- navori:user-section -->
 ## Project rules
 

package/dist/assets/core/core-assets/hooks/_partials/extract-cmd.sh

@@ -3,19 +3,31 @@
 # of truth for the sibling gate scripts; DO NOT copy this body back into a hook
 # by hand (that is the drift #225/#261 removed).
 #
-# PreToolUse(Bash) passes the tool input on stdin. Extract .tool_input.command
+# PreToolUse(Bash) passes the tool input on stdin. Read one field out of it
 # WITHOUT hard-depending on jq (NOT preinstalled on macOS): try jq, then node
-# (Claude Code's own runtime), then a best-effort sed unwrap. No command
-# extracted → empty $cmd, and each caller decides what that means (the gate
-# scripts scan defensively; guard-destructive waves the command through).
+# (Claude Code's own runtime), then a best-effort sed unwrap on the leaf key.
+# Nothing extracted → empty output, and each caller decides what that means (the
+# gate scripts scan defensively; guard-destructive waves the command through).
+#
+# $1 is a dotted path written HERE, never user input — the payload is the data.
+# Generic on purpose: `.cwd` feeds the worktree resolver of #454 through the
+# SAME hardened cascade instead of a second copy of it.
+#
+# $2 overrides the sed fallback's capture. `.*` (greedy, to the last quote on the
+# line) is right for `command`, whose value can itself contain escaped quotes and
+# which Claude Code sends LAST. Every other field takes the default `[^"]*` run,
+# so a value with more JSON after it is not swallowed whole.
 payload=$(cat)
-extract_cmd() {
+payload_field() {
   if command -v jq >/dev/null 2>&1; then
-    printf '%s' "$payload" | jq -r '.tool_input.command // empty' 2>/dev/null && return 0
+    printf '%s' "$payload" | jq -r ".$1 // empty" 2>/dev/null && return 0
   fi
   if command -v node >/dev/null 2>&1; then
-    printf '%s' "$payload" | node -e 'let s="";process.stdin.on("data",c=>s+=c).on("end",()=>{try{process.stdout.write(String(JSON.parse(s)?.tool_input?.command??""))}catch{}})' 2>/dev/null && return 0
+    printf '%s' "$payload" | node -e 'let s="";const p=process.argv[1].split(".");process.stdin.on("data",c=>s+=c).on("end",()=>{try{let v=JSON.parse(s);for(const k of p)v=v?.[k];process.stdout.write(String(v??""))}catch{}})' "$1" 2>/dev/null && return 0
   fi
-  printf '%s' "$payload" | sed -n 's/.*"command"[[:space:]]*:[[:space:]]*"\(.*\)".*/\1/p'
+  printf '%s' "$payload" | sed -n "s/.*\"${1##*.}\"[[:space:]]*:[[:space:]]*\"\(${2:-[^\"]*}\)\".*/\1/p"
+}
+extract_cmd() {
+  payload_field tool_input.command '.*'
 }
 cmd=$(extract_cmd)

package/dist/assets/core/core-assets/hooks/_partials/gate-trigger.sh

@@ -15,15 +15,20 @@
 # does NOT trigger it. Known limitation: it cannot see through `sh -c`, `eval`,
 # or obfuscation — a seatbelt, not a sandbox.
 is_scan_trigger() {
-  local input="$1" segment
+  # Pre-expanded newline: zsh does NOT expand $'\n' in the REPLACEMENT of
+  # ${var//pat/repl} (it inserts the literal characters), so an inline $'\n'
+  # left compound commands unsplit there and the gate silently skipped
+  # `cd x && git commit` (#391). A plain variable expands identically in
+  # bash and zsh. ($'\n' in PATTERN position expands fine in both.)
+  local input="$1" segment nl=$'\n'
   # FIX B: join `\<newline>` continuations into a space FIRST, so a command
   # split across lines with a trailing backslash stays ONE logical segment
   # (otherwise the subcommand/flag lands in a segment not starting with git).
   input="${input//\\$'\n'/ }"
-  input="${input//&&/$'\n'}"
-  input="${input//||/$'\n'}"
-  input="${input//;/$'\n'}"
-  input="${input//|/$'\n'}"
+  input="${input//&&/$nl}"
+  input="${input//||/$nl}"
+  input="${input//;/$nl}"
+  input="${input//|/$nl}"
   # `<<<` feeds the already-expanded value as data — no re-evaluation — so a
   # command that contains backticks/$() is inspected, never executed.
   while IFS= read -r segment; do