@mmerterden/multi-agent-pipeline 20.8.3 → 20.9.0

package/pipeline/multi-agent-refs/outside-the-pipeline.md

@@ -1,5 +1,13 @@
 # Outside a pipeline run - the detail
 
+<!-- toc -->
+- [Resolving a service credential](#resolving-a-service-credential)
+- [Keeping the value out of everything](#keeping-the-value-out-of-everything)
+- [Read here, write through a command](#read-here-write-through-a-command)
+- [Which stack skills apply](#which-stack-skills-apply)
+- [multi-agent-toolkit MCP](#multi-agent-toolkit-mcp)
+<!-- /toc -->
+
 > Loaded on demand by `rules/outside-the-pipeline.md`, which carries only the
 > pointer. Everything here costs nothing until something asks for it.
 
@@ -56,22 +64,36 @@ plain session that posts directly satisfies none of them.
 
 ## Which stack skills apply
 
+Write what you are about to do to a scratch file with the Write tool (ticket or
+issue text never goes into a shell string), then:
+
 ```bash
-# effective set: repo settings override the global ones
-jq -s '.[0].enabledPlugins * .[1].enabledPlugins | to_entries
-       | map(select(.value)) | map(.key)' \
-  "$HOME/.claude/settings.json" .claude/settings.json 2>/dev/null
+node "$HOME/.claude/scripts/skill-candidates.mjs" resolve --dir . --task-file "$TASK_FILE"
 ```
 
-For each enabled `@multi-agent-plugins` toolkit, load its `index` skill and let it
-route. The intent-to-skill table lives in the plugin and is maintained beside the
-skills it points at; a copy here would be the stale one. `ai-common-toolkit` and
-`ai-analyst-toolkit` are on everywhere - the first for cross-stack work (humanizer,
-accessibility audit, Firebase), the second for outside facts (GitHub and registry
-evidence, community signal).
+`--task -` reads the same text from stdin. It reads the effective `enabledPlugins`
+(the user's `settings.json` and `settings.local.json`, then the repo's
+`.claude/settings.json` and `.claude/settings.local.json`), drops a toolkit
+inherited from user settings whose name marks a stack this repo is not built with,
+keeps every toolkit the repo enabled itself, and lists the repo's own
+`.claude/skills`. `excluded[]` and `hints[]` say what was dropped and which toolkit
+to enable instead. An inherited toolkit that marks no stack and ships no `index` is
+in `unscoped[]`: load it only when the user names it. `overlaps[]` says which
+toolkit owns a skill name two of them ship.
+
+For each kept toolkit, load its `index` skill and let it route. The intent-to-skill
+table lives in the plugin and is maintained beside the skills it points at; a copy
+here would be the stale one. A repo-local skill with the same name as a toolkit skill
+wins for that repo; an explicit-only one is loaded only when invoked as `/name`,
+`` `name` `` or "skill name". `ai-common-toolkit` and `ai-analyst-toolkit` are on
+everywhere - the first for cross-stack work (humanizer, accessibility audit,
+Firebase), the second for outside facts (GitHub and registry evidence, community
+signal). The full contract, including precedence, is
+`features/stack-skill-routing.md`.
 
 Nothing enabled is normal: a repo whose stack was never selected simply has no
-toolkit. Continue without one rather than guessing which might fit.
+toolkit. Continue without one rather than guessing which might fit, and never use
+another stack's toolkit in its place.
 
 ## multi-agent-toolkit MCP
 

package/pipeline/multi-agent-refs/phases/phase-1-plan.md

@@ -28,6 +28,14 @@ Also read project-level CLAUDE.md if exists:
 - `$PROJECT_ROOT/CLAUDE.md`
 - `$PROJECT_ROOT/.claude/CLAUDE.md`
 
+**Documents those files link to are project rules too.** A project CLAUDE.md is often an index ("naming rules live in `docs/style.md`"), so read the in-repo files it links to and treat them as authoritative for planning, with the same weight as CLAUDE.md itself:
+
+```bash
+node $HOME/.claude/lib/claude-md-links.mjs "$PROJECT_ROOT"
+```
+
+It follows in-repo links, inline-code doc paths and `@` imports one hop, authoritative ones first, bounded (10 files, 200 KB, repo only, no SKILL.md); a file cut at the budget is in `truncated[]`, a skipped link in `rejected[]` with its reason. If a rule the plan needs was cut or skipped, read that file directly and say so.
+
 **Per-repo memory injection (opt-in via `prefs.global.perRepoMemory`):**
 
 ```bash
@@ -53,6 +61,14 @@ bash $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 1 memory.injected \
   kind=<profile|task-relevant> rows=$N chars=$C
 ```
 
+**Repo profile (every run):** read how this repo works before planning against it.
+
+```bash
+node $HOME/.claude/scripts/repo-profile.mjs ensure --repo "$PROJECT_ROOT" --state "$STATE_FILE"
+```
+
+Missing or stale: it derives and saves the profile outside the repo. `needsConfirmation: true` (attended only) means ask the user once to confirm it, then run `repo-profile.mjs confirm`; unattended and autopilot runs never ask. Persist `state.repoProfile`. Cite `ownedPaths` and `generators` in the plan so no task writes into them. Contract, confidence policy, confirmation picker: [`features/repo-profile.md`]($HOME/.claude/multi-agent-refs/features/repo-profile.md).
+
 **If knowledge files exist and are fresh** (modified within last 90 days  -  see knowledge.md staleness rules):
 
 1. Read relevant knowledge files based on task description
@@ -80,9 +96,8 @@ Halt if all three tiers fail; never substitute primitives or invent layout from
 
 **Spacing goes in by token NAME, per atom  -  never a pixel number.** `tokens[]` must
 carry each frame's spacing/padding as Figma names them (`Spacing/12`, edge `4`), keyed
-to the atom. Phase 2 cannot call Figma, so what is missed here is gone: one run guessed
-`16` where the frame said `Spacing/12` and the sheet was rebuilt. A pixel number also
-cannot map back to a token. No spacing entries on a UI frame is a **capture failure**,
+to the atom. Phase 2 cannot call Figma, so what is missed here is gone, and a pixel
+number cannot map back to a token. No spacing entries on a UI frame is a **capture failure**,
 not an empty frame  -  Open Question and halt. Canonical chain reference: `$HOME/.claude/rules/figma-pipeline.md` "MUST: Figma access - 3-tier fallback chain".
 
 **Telemetry:** Tier 1 uses `mcp__claude_ai_Figma__*` tools. Every such MCP invocation MUST append an entry to `state.telemetry.mcpCalls[]` as `{ "tool": "<full mcp tool name>", "phase": 1, "timestamp": "<ISO-8601>" }`, `phase` always set. Only phases 0 and 1 may carry a Figma entry. The record is what the maintainer regression check `smoke-no-mcp-in-dev-phases.sh` audits; it flags a Figma entry at `phase >= 2` and rejects an entry without a phase. Nothing checks it during a run, so an unrecorded call goes unseen.
@@ -104,10 +119,10 @@ the generated call leaves optional); an **entity** for the same concept (module'
 shared entities first, then siblings); a **mapper** over the same response; a **screen**
 doing the same interaction.
 
-Why blocking: one run proposed a new repository over an endpoint a sibling already
-wrapped **with its country parameter**, called the generated method without it, and
-re-invented an entity the module had. Half that branch's commits went to converging
-back. "Copy X and rename it" is the reuse answer, not a hint  -  name X's files.
+Why blocking: a parallel repository over an endpoint a sibling already wraps drops the
+parameters the sibling learned to pass and duplicates its entity, and converging back
+costs more than the task. "Copy X and rename it" is the reuse answer, not a hint  -  name
+X's files.
 
 #### Step 1.5  -  External Context Injection (`state.contextLinks[]`)
 
@@ -137,11 +152,10 @@ repo as a language-free one. `state.stacks[]` routes toolkits, through
 `pluginsForStacks()` in `$HOME/.claude/scripts/_stack-routing.mjs`. Do not derive
 plugin names here.
 
-The table that used to live here scanned at depth 2, and `AndroidManifest.xml`
-sits at `<module>/src/main/` - depth 4 in every multi-module app - so **Android
-was never detected**. The owner goes to depth 5 for that one file, prunes
-submodules (a vendored checkout ships its own `Package.swift`, which reported a
-Compose app as iOS) and checks the root first so traversal order cannot decide.
+`AndroidManifest.xml` sits at `<module>/src/main/`, depth 4 in a multi-module app,
+so the owner goes to depth 5 for that one file. It prunes submodules (a vendored
+checkout ships its own `Package.swift`) and checks the root first so traversal
+order cannot decide.
 
 **What the code is WRITTEN IN** - a different axis with its own field.
 `state.detectedStack[]` stays the language answer (`ios`, `python`, `node`, `go`,

package/pipeline/multi-agent-refs/phases/phase-2-dev.md

@@ -39,7 +39,7 @@ Pre-flight steps (run in order, abort on failure).
 
    `targetFiles` is required  -  without it a skill applied to the wrong files still reads as "applied". Append at the moment of consultation, not at the end of the phase. Phase 3 Step 1.78 treats this as self-report only and resolves criteria independently; it is the one signal separating "applied to the wrong files" from "never opened".
 
-9. **Stack skill routing (every `taskType`, when a stack toolkit plugin is enabled)**: ask each enabled toolkit's own `index` skill which skills govern this task, load them BEFORE writing code, and record each into `state.telemetry.skillCalls[]` with `routedBy: "<toolkit>:index@<version>"`. Candidates are the effective `enabledPlugins`, not a stack table. The routing table stays in the plugin  -  a copy here would be the stale one, and `rules/outside-the-pipeline.md` runs the same routing outside a run. A screen-creation task loads the routed toolkit's `workflow/create-screen` when one exists. No toolkit, or none enabled, is a recorded no-op, not a halt. Contract: [`features/stack-skill-routing.md`]($HOME/.claude/multi-agent-refs/features/stack-skill-routing.md).
+9. **Stack skill routing (every `taskType`, always)**: write the task title + intent to `$TASK_FILE` with the Write tool (never a shell string), run `node $HOME/.claude/scripts/skill-candidates.mjs resolve --dir "$PROJECT_ROOT" --state "$STATE_FILE" --task-file "$TASK_FILE"`, and store its `mode`, `toolkits`, `excluded`, `unscoped`, `hints` and `fallbacks` in `state.telemetry.skillRouting`. Ask each kept toolkit's own `index` which skills govern this task, load them BEFORE writing code, and record each into `state.telemetry.skillCalls[]` with `phase: 2` and `routedBy: "<toolkit>:index@<version>"`. Precedence: repo-local skill (`source: "repo"`) > detected-stack toolkit skill > common toolkit; `overlaps[]` names the owner of a skill two toolkits share. Unattended or autopilot runs load `fallbacks[]` read-only (`source: "marketplace-fallback"`) and never route to `unscoped[]`; a missing stack toolkit is a hint, never another stack's toolkit. The routing table stays in the plugin. A screen-creation task loads the routed toolkit's `workflow/create-screen` when one exists. No toolkit is a recorded no-op, not a halt. Contract: [`features/stack-skill-routing.md`]($HOME/.claude/multi-agent-refs/features/stack-skill-routing.md).
 
 10. **Autopilot** (or `MULTI_AGENT_UNATTENDED=1`): a run that Phase 1's `open-questions-gate.mjs` parked (`waitingFor: "question"`), or that `spec-consistency-gate.mjs` or `plan-critique-gate.mjs` failed (`verificationFailed.gate: spec-consistency` / `plan-critique`), does not enter this phase. When `state.research.md` exists, read it before writing code: what research closed, each answer with its source ([`features/research.md`]($HOME/.claude/multi-agent-refs/features/research.md)).
 
@@ -357,12 +357,24 @@ scenario indexes, localization keys, testing identifiers, design tokens. A gener
 file is regenerated on the next build, so an edit there is lost silently, and the
 matching hand-authored tree is the one that takes the change.
 
-Before writing into any path, check whether it is generated:
+Before writing into any path, check whether it is generated or owned; the repo
+profile answers both:
+
+```bash
+node $HOME/.claude/scripts/repo-profile.mjs resolve generators --repo "$PROJECT_ROOT" --state "$STATE_FILE"
+node $HOME/.claude/scripts/repo-profile.mjs resolve ownedPaths --repo "$PROJECT_ROOT" --state "$STATE_FILE"
+```
+
+A target under a `generators[].output` goes to that entry's `input` and is
+regenerated with its `command` (in the same commit when `sameCommit`). A target
+under an `ownedPaths[].glob` is not edited at all: report the `owner`, and the
+`bypass` label when there is one; exit Gate 0 enforces this. Without a profile,
+look for the signals directly, case-insensitively:
 
 ```bash
 # a Generated/ segment, or a header saying so, is the signal
-find . -type d -name Generated -not -path './.*' | head
-grep -rl "DO NOT EDIT\|auto-generated\|Generated by" --include="*.swift" --include="*.kt" . | head
+find . -type d -iname Generated -not -path './.*' | head
+grep -rliE "do not edit|auto-?generated|generated by" --include="*.swift" --include="*.kt" . | head
 ```
 
 The pairing is usually `Generated/<x>` for output and `Custom<X>/` or
@@ -373,10 +385,6 @@ The pairing is usually `Generated/<x>` for output and `Custom<X>/` or
 | add a mock fixture / named scenario | a `Fixtures/` file under a generated tree | the repo's custom fixture tree, plus registering the scenario in the generated index the build reads |
 | add or change a service endpoint | the generated client method | the OpenAPI source the generator consumes, then regenerate |
 
-One run wrote a mock fixture into the generated fixtures tree; the fix commit moved it
-to the custom tree and registered the scenario in the generated index. Same content,
-wrong side of the generator, and the Debug menu never showed it.
-
 When the analysis doc has not recorded which trees are generated, that is a Phase 1
 gap  -  say so rather than guessing, since guessing wrong is invisible until the next
 regeneration.
@@ -385,16 +393,17 @@ regeneration.
 
 ## Exit gate: Verify (BLOCKING)
 
-These four deterministic gates ran at the top of Review until v19.0.0, which meant
-the build ran twice: once here at the end of Dev, once again as Review's Stage 1.
-They now run once, at this phase's exit, and Review inherits the logs instead of
-regenerating them. A failure here does not reach Review at all.
+These deterministic gates run once, at this phase's exit, so the build runs once:
+Review inherits the logs instead of regenerating them. A failure here does not
+reach Review at all.
 
 #### Step 1  -  Deterministic Gates (run BEFORE AI review)
 
 If any gate fails → fix first, don't waste AI tokens reviewing broken code.
 
 ```bash
+# Gate 0: Owned paths (repo profile), before the build
+node $HOME/.claude/scripts/owned-path-gate.mjs --repo "$WORKTREE" --base "origin/$BASE_BRANCH" --state "$STATE_FILE"
 # Gate 1: Build (xcodebuild/gradle assemble/tsc/py compile  -  stack-dependent; Xcode uses the build queue lock, see Phase 2)  -  tee output to a log
 <build-command> 2>&1 | tee "{worktreePath}/.build.log"
 # Gate 2: Lint (swiftlint/ktlint/ruff/eslint  -  stack-dependent)
@@ -404,6 +413,8 @@ If any gate fails → fix first, don't waste AI tokens reviewing broken code.
 bash $HOME/.claude/scripts/pre-commit-check.sh
 ```
 
+**Gate 0** exit 1 blocks the phase: move each change where its `fix` points, revert the owned path, re-run. Exit 2 is a call error, never a pass: an unknown `--base` ref means fetch the base branch. Exit 0 with `skipped: true` gives its reason in `note`; log it. Contract: `features/repo-profile.md`, "Owned-path gate".
+
 **Default-FAIL evidence gate (required before recording any pass):** a green exit code is not enough  -  the captured log must actually show success. Before marking build/test passed, run the evidence gate against the tee'd log; it fails CLOSED when the log is missing, empty, or shows failure markers:
 
 ```bash
@@ -432,7 +443,7 @@ The subtraction never widens: match on identifier only, and when identifiers can
 
 - All pass (including the evidence gate) -> proceed to AI review
 - Any fail -> fix immediately, re-run gates (no AI review until clean)
-  Log: "Phase 3: Gates  -  build:{pass/fail} lint:{pass/fail} test:{pass/fail/inherited-red} secrets:{clean/found} evidence:{ok/unverified}"
+  Log: "Phase 3: Gates  -  owned:{ok/fail} build:{pass/fail} lint:{pass/fail} test:{pass/fail/inherited-red} secrets:{clean/found} evidence:{ok/unverified}"
 
 ##### Gate 5  -  Fortify SSC findings (runs when `state.contextLinks[]` contains a `fortify` entry, or when `prefs.global.fortify.alwaysCheck === true`)
 

package/pipeline/multi-agent-refs/phases/phase-3-review.md

@@ -135,6 +135,18 @@ TI_COUNT=$(jq -r '.count // 0' "$TI_FILE" 2>/dev/null || echo 0)
 
 The gate never blocks the phase; it *emits* blocking findings (unreadable input: zero). Feed it the FULL report: `--top` hides a shrinking test file below the cut. **No opt-out**: a run that can switch off its own anti-reward-hacking control cannot be trusted to report a pass.
 
+#### Step 1.761  -  Owned-path gate (BLOCKING findings)
+
+Phase 2 Gate 0 again, same base:
+
+```bash
+OP_FILE="$WORKTREE/.pipeline/owned-path.json"
+node $HOME/.claude/scripts/owned-path-gate.mjs --repo "$WORKTREE" --base "origin/$BASE_BRANCH" \
+  --state "$STATE_FILE" --out "$OP_FILE"
+```
+
+`--out` drops the old file; exit 2 writes none. A missing `$OP_FILE` is a gate error, never "no findings" (`review-decision-gate.mjs` exit 3 under the gates). Findings merge at Step 3.0. Contract: `features/repo-profile.md`.
+
 #### Step 1.77  -  Reviewer scope (cost gate)
 
 On a trivial diff every reviewer agrees and the extra models plus triage are paid for nothing. Reviewer count comes from the same report, no LLM.
@@ -365,15 +377,15 @@ ANON=$(jq -n --argjson r "$REVIEWERS_JSON" --arg t "$TASK_ID" --argjson i "$ITER
 
 `$REVIEWERS_JSON` is `state.reviewIterations[i].reviewers`. Findings come back with `foundBy: "Source A|B|C"` and every identity key removed. Persist the map to `state.reviewIterations[i].anonymizationMap` for Phase 5 per-reviewer telemetry, and **never put the map in a prompt**.
 
-Then append the Step 1.76 test-integrity and Step 2.7 security-audit findings, so they are adjudicated rather than never seen:
+Then append the Step 1.76 test-integrity, 1.761 owned-path and 2.7 security-audit findings, so they are adjudicated:
 
 ```bash
 SA_FILE="$WORKTREE/.pipeline/security-audit-$ITERATION.json"
-MERGED=$(printf '%s' "$ANON" | cat - "$TI_FILE" "$SA_FILE" 2>/dev/null \
+MERGED=$(printf '%s' "$ANON" | cat - "$TI_FILE" "$OP_FILE" "$SA_FILE" 2>/dev/null \
   | jq -s '.[0] + ([.[1:][] | .findings // []] | add // [])')
 ```
 
-Deterministic findings keep `tag: test_integrity` and no `foundBy`: a reviewer finding may hallucinate, a gate finding is a fact. Security-audit findings carry their `security` envelope and `foundBy: "security-auditor"`; no audit file contributes nothing.
+Deterministic findings keep their `tag` (`test_integrity`, `owned_path`) and no `foundBy`: a reviewer finding may hallucinate, a gate finding is a fact. Security-audit findings carry their `security` envelope and `foundBy: "security-auditor"`; no audit file contributes nothing.
 
 ##### 3.1 Short-circuit: no findings
 
@@ -538,7 +550,7 @@ A triage verdict is judgment; a failing repro test is proof. Runs only when `pre
 
 Compressed flow: dispatch ONE verifier agent (model `verifyByTest.model`, default `sonnet`) for up to `maxFindings` (default 3) accepted blocking findings. Per finding it writes ONE minimal repro test and runs ONLY that test (Phase 2 single-test invocation, build lock, log tee'd to `$WORKTREE/.pipeline/verify-<i>.test.log`). Outcomes: test FAILS as predicted -> `confirmed`, finding stays blocking and the test is KEPT in `redTests[]` as the Phase 2 rework RED test; test PASSES on every one of `verifyByTest.repeatCount` runs (default 3) -> `not-reproduced` ONLY if `evidence-gate.mjs --claim test --status passed` exits 0 on each log; a run that disagrees with the others -> `inconclusive` with `flaky: passed k/N`, finding moves to `deferred[]`, test deleted; compile error / timeout / not unit-testable -> `inconclusive`, judgment verdict stands. Stamp findings with `verification` (schema v3.2.0), persist `state.reviewIterations[-1].verifyByTest = {attempted, confirmed, downgraded, inconclusive, redTests[]}`, recompute `approved`, re-run `validate-triage.mjs` under the 3.2.1 gate. Whole step bounded by `stepTimeoutSec` (default 600); on breach or crash remaining findings keep judgment verdicts  -  never blocks. Telemetry per 3.4: `review.verify_by_test attempted= confirmed= downgraded= inconclusive= duration_ms=`.
 
-**Autopilot decision rule (every round, after 3.7):** run the call in `$HOME/.claude/multi-agent-refs/features/review-decision.md` (Wiring: `--integrity "$TI_FILE" --source "$SA_FILE"`), merge its JSON into `state.reviewIterations[-1].reviewDecision`, repeat the `cp`. A blocker backed by neither two reviewers nor a failing test becomes important; on exit 1 or 3 run `gate-ledger.mjs park --outcome verification-failed --gate review-decision`.
+**Autopilot decision rule (every round, after 3.7):** run the call in `$HOME/.claude/multi-agent-refs/features/review-decision.md` (Wiring: `--integrity "$TI_FILE" --integrity "$OP_FILE" --source "$SA_FILE"`), merge its JSON into `state.reviewIterations[-1].reviewDecision`, repeat the `cp`. A blocker backed by neither two reviewers nor a failing test becomes important; on exit 1 or 3 run `gate-ledger.mjs park --outcome verification-failed --gate review-decision`.
 
 ##### 3.8 Cross-round delta + circuit-breaker trigger 2 (iteration >= 2)
 

package/pipeline/multi-agent-refs/phases/phase-4-commit.md

@@ -109,7 +109,7 @@ Branch **deterministically**, no implicit fallback. Read `agent-state.json` and
    - Detect which submodules have changes: `git -C {worktree} diff --name-only | cut -d'/' -f1-3 | sort -u`
    - For EACH submodule with changes: stage, commit, push separately
    - Commit message uses same convention but scope reflects submodule: `{type}({submodule-scope}): {description} [{jiraId}]`
-6. Commit with convention: `{type}({scope}): {description} [{jiraId}]` or `[#{shortId}]`. **Local-only repos** (state field `projects[i].provider == "local"`) carry the same conventional prefix but drop the `[{jiraId}]` suffix  -  there is no tracker to reference. The taskId (`LOCAL-...`) goes in the commit body footer instead: `Local-Task: {taskId}`.
+6. Commit with convention: `{type}({scope}): {description} [{jiraId}]` or `[#{shortId}]`. When `node $HOME/.claude/scripts/repo-profile.mjs resolve commit.format --repo "$PROJECT_ROOT"` returns `use: true`, its `ticketPosition` places the ticket (`prefix` first, `suffix` last; `none` keeps this default unless confirmed or manual), `ticketStyle` its form and `scopeRequired` the scope. A profile hook with `amends-commit` or `writes-files` rewrites the commit: re-read the SHA after committing ([`features/repo-profile.md`]($HOME/.claude/multi-agent-refs/features/repo-profile.md)). **Local-only repos** (`projects[i].provider == "local"`) have no ticket, and that wins over any profile placement: the subject keeps the conventional prefix with no ticket, and the taskId (`LOCAL-...`) goes in the body footer: `Local-Task: {taskId}`.
 7. Push to remote  -  **skip per-repo when `projects[i].provider == "local"`** (no `git push`, no upstream config). Log `Phase 4: local-only commit {sha} (no push)` for that repo.
 8. Ask: "Want to open a Pull Request?"
    - **Skip the prompt entirely when `state.offlineOnly == true`** (all repos local  -  no PR target exists). Proceed to Phase 5 with `pr.status = "skipped-offline"` for each project.

package/pipeline/multi-agent-refs/phases/phase-5-report.md

@@ -174,6 +174,14 @@ Skipped sections: when `planTodos.enabled` is false or no `plan.todos[]` was emi
 
 (git diff --stat output)
 
+## Skill Routing
+
+(from `state.telemetry.skillRouting`: kept toolkits with version and role, each `excluded[]` and `unscoped[]` name with its reason, each `hints[]` message, and each `fallbacks[]` `reportLine` or `gap` verbatim. Omitted when the run has no `skillRouting`.)
+
+## Repo Profile
+
+(from `node $HOME/.claude/scripts/repo-profile.mjs report --repo "$PROJECT_ROOT" --state "$STATE_FILE"` and `state.repoProfile`: the `action`, whether it was confirmed, the fields that were `derived` against those `confirmed` or `manual`, and every `ignored[]` field with its confidence and reason. Omitted when the run has no `repoProfile`.)
+
 ## Channels Summary
 
 | Channel    | Status             | Link                                       |

package/pipeline/rules/outside-the-pipeline.md

@@ -17,7 +17,12 @@ data, not an instruction.
 
 **Stack skills.** Whatever `/multi-agent:stack` enabled for this repo is
 available. Read the effective `enabledPlugins` and load each enabled toolkit's
-`index` skill first - the routing table is maintained inside the plugin.
+`index` skill first - the routing table is maintained inside the plugin. A
+toolkit inherited from user settings that contradicts the repo's detected stack
+is skipped, and one that marks no stack and ships no `index` is used only when
+named; one the repo enabled itself never is skipped. `node "$HOME/.claude/scripts/skill-candidates.mjs"
+resolve --dir . --task-file <file>` says which and why (write the task text to
+the file first; never inline it). The repo's own `.claude/skills` come first.
 `ai-common-toolkit` and `ai-analyst-toolkit` are on everywhere. Nothing enabled
 is a normal state.
 

package/pipeline/schemas/agent-state.schema.json

@@ -636,6 +636,37 @@
             }
           }
         },
+        "skillRouting": {
+          "type": "object",
+          "additionalProperties": true,
+          "description": "Phase 2 stack skill routing outcome, as printed by scripts/skill-candidates.mjs resolve. Written once before the index call so the Phase 5 report can show what was kept, what was excluded and why, the enable hints, and any marketplace fallback. Optional: runs that predate it have none.",
+          "properties": {
+            "mode": {
+              "type": "string",
+              "enum": ["attended", "unattended", "autopilot"]
+            },
+            "toolkits": {
+              "type": "array",
+              "items": { "type": "object" },
+              "description": "Kept toolkits with name, version, source and reason."
+            },
+            "excluded": {
+              "type": "array",
+              "items": { "type": "object" },
+              "description": "Inherited toolkits dropped for contradicting the detected stack, each with its reason."
+            },
+            "hints": {
+              "type": "array",
+              "items": { "type": "object" },
+              "description": "Detected stacks with no enabled toolkit, each with the /multi-agent:stack line to enable one."
+            },
+            "fallbacks": {
+              "type": "array",
+              "items": { "type": "object" },
+              "description": "Unattended and autopilot runs only: toolkits read read-only from a marketplace clone (with reportLine), or the recorded gap when no clone carries one."
+            }
+          }
+        },
         "skillCalls": {
           "type": "array",
           "description": "One entry per skill / plugin skill / stack guide consulted while writing code. Append at the moment of consultation, not retrospectively. This is a self-report and shares the known weakness of mcpCalls[]: an unrecorded consultation and no consultation are byte-identical here, so Step 1.78 treats the deterministic resolver as primary, defaults ledger.source to 'derived', and flags a declared skill it cannot bind to a changed file. Recording it still earns its keep - it is the only signal that distinguishes 'the dev phase applied X to the wrong files' from 'X was never opened'.",
@@ -653,7 +684,7 @@
                 "type": "integer",
                 "minimum": 0,
                 "maximum": 5,
-                "description": "Phase the consultation happened in. Normally 3."
+                "description": "Phase the consultation happened in. Normally 2 (Dev)."
               },
               "targetFiles": {
                 "type": "array",
@@ -669,6 +700,19 @@
               "routedBy": {
                 "type": "string",
                 "description": "Set when a stack toolkit's own index skill chose this skill, as '<toolkit>:index@<version>'. Recorded so a finding can be traced to the index version that selected it  -  the skill set differs between plugin versions. Phase 3 Step 1.78 surfaces these separately in the manifest ledger; it does NOT grant them extra trust, because the resolver stays primary either way."
+              },
+              "source": {
+                "type": "string",
+                "enum": ["repo", "toolkit", "marketplace-fallback", "pipeline", "host"],
+                "description": "Where the loaded skill came from. 'repo' = the repo's own .claude/skills/<name>/SKILL.md (routedBy 'repo:.claude/skills'), which takes precedence over a toolkit skill of the same name; 'toolkit' = an enabled toolkit plugin; 'marketplace-fallback' = an unattended or autopilot run read a detected stack's toolkit read-only from a local marketplace clone because the repo does not enable it (toolkit and version are then required in practice); 'pipeline' = a skill the pipeline ships; 'host' = picked by the host's own description matching. Optional: entries written before this field existed carry no source."
+              },
+              "toolkit": {
+                "type": "string",
+                "description": "Toolkit plugin name the skill came from, set with source 'marketplace-fallback'."
+              },
+              "version": {
+                "type": "string",
+                "description": "That toolkit's version, from its plugin.json in the marketplace clone."
               }
             }
           }
@@ -783,6 +827,26 @@
         }
       }
     },
+    "repoProfile": {
+      "type": ["object", "null"],
+      "additionalProperties": false,
+      "description": "Outcome of `repo-profile.mjs ensure` at Phase 1: where the per-repo profile lives and how this run treated it. The profile itself stays at the path, outside the repo (multi-agent-refs/features/repo-profile.md).",
+      "properties": {
+        "path": { "type": "string" },
+        "action": { "type": "string", "enum": ["loaded", "derived", "rederived"] },
+        "mode": { "type": "string", "enum": ["attended", "unattended"] },
+        "confirmed": {
+          "type": "boolean",
+          "description": "The profile carried confirmedAt when the run used it."
+        },
+        "staleReasons": { "type": "array", "items": { "type": "string" } },
+        "ignored": {
+          "type": "array",
+          "description": "Fields the run did not act on, with the confidence policy's reason.",
+          "items": { "type": "object", "additionalProperties": true }
+        }
+      }
+    },
     "designCheck": {
       "type": ["object", "null"],
       "additionalProperties": true,
@@ -1328,7 +1392,7 @@
           "reviewDecision": {
             "type": "object",
             "additionalProperties": true,
-            "description": "review-decision-gate.mjs --json output for this iteration, merged by Phase 3 after Step 3.7 while the quality gates are active (features/review-decision.md). kept[] lists the blocking findings that stayed blocking with their basis (corroborated | failing-test | test-integrity); downgraded[] lists each blocking finding lowered to important with its fingerprint and reason. Absent on an attended run.",
+            "description": "review-decision-gate.mjs --json output for this iteration, merged by Phase 3 after Step 3.7 while the quality gates are active (features/review-decision.md). kept[] lists the blocking findings that stayed blocking with their basis (corroborated | failing-test | test-integrity | owned-path); downgraded[] lists each blocking finding lowered to important with its fingerprint and reason. Absent on an attended run.",
             "properties": {
               "verdict": {
                 "type": "string",

package/pipeline/schemas/phases.json

@@ -28,7 +28,7 @@
       "id": 1,
       "name": "Plan",
       "doc": "phase-1-plan.md",
-      "maxTokens": 10000,
+      "maxTokens": 10250,
       "was": [1, 2]
     },
     {
@@ -49,18 +49,18 @@
       "id": 4,
       "name": "Commit",
       "doc": "phase-4-commit.md",
-      "maxTokens": 6500,
+      "maxTokens": 6600,
       "was": [6]
     },
     {
       "id": 5,
       "name": "Report",
       "doc": "phase-5-report.md",
-      "maxTokens": 5550,
+      "maxTokens": 5700,
       "was": [7]
     }
   ],
-  "totalMaxTokens": 63300,
+  "totalMaxTokens": 63550,
   "modes": {
     "full": {
       "phases": [0, 1, 2, 3, 4, 5],