@mmerterden/multi-agent-pipeline 17.4.0 → 17.5.0

package/pipeline/scripts/gen-mode-dispatch.mjs

@@ -17,9 +17,10 @@
  *
  * v16.0.0 removed the four dev-* modes. Depth is no longer a command name: the
  * Phase 0 Step 7.5 picker asks Full or Short and sets `state.onlyDevelop`. That
- * answer arrives long after the tracker boots at Step -1, so a Short run
- * registers its full set and flips Phases 1 and 2 to `skipped` when it learns.
- * A generated phase set is therefore per-COMMAND, never per-depth.
+ * answer arrives long after the tracker boots at Step -1, so v17.5.0 splits
+ * registration for the two modes that ask it (`full`, `local`): Phase 0 at Step -1,
+ * the rest once depth has named them. Everything else still registers its whole
+ * set up front, and a generated phase set is per-COMMAND, never per-depth.
  *
  * Companion smoke `smoke-mode-dispatch-drift.sh` regenerates the section for
  * each mode file, diffs against the on-disk content, and fails on drift.
@@ -60,10 +61,10 @@ const PHASE_NAMES_NO_TEST = PHASE_NAMES.filter((p) => p !== "5:Test");
  */
 const MODES = {
   autopilot: { phases: PHASE_NAMES_NO_TEST, local: false, autopilot: true },
-  full: { phases: PHASE_NAMES, local: false, autopilot: false },
-  local: { phases: PHASE_NAMES_NO_TEST, local: true, autopilot: false },
+  full: { phases: PHASE_NAMES, local: false, autopilot: false, depth: true },
+  local: { phases: PHASE_NAMES_NO_TEST, local: true, autopilot: false, depth: true },
   "local-autopilot": { phases: PHASE_NAMES_NO_TEST, local: true, autopilot: true },
-  "full-local": { phases: PHASE_NAMES_NO_TEST, local: true, autopilot: false },
+  "full-local": { phases: PHASE_NAMES_NO_TEST, local: true, autopilot: false, depth: true },
   // Analysis produces a document, not code: no Dev, no Test, and Phase 6
   // publishes instead of committing. Same 8-phase contract, four of them
   // reinterpreted.
@@ -81,8 +82,6 @@ if (!spec) {
   process.exit(2);
 }
 
-const phaseLoop = spec.phases.map((p) => `"${p}"`).join(" ");
-
 const ALL_PHASE_IDS = PHASE_NAMES.map((p) => p.split(":")[0]);
 const activeIds = spec.phases.map((p) => p.split(":")[0]);
 const skippedIds = ALL_PHASE_IDS.filter((id) => !activeIds.includes(id));
@@ -104,7 +103,7 @@ const skipNote =
     ? `${modeLabel} mode does NOT TaskCreate phases ${skippedIds.join("/")}  -  those are not part of the ${modeLabel} phase set (\`${spec.phases.join(" ")}\`). Only register tiles for the active set.`
     : `${modeLabel} mode TaskCreates all 8 phases (no phase is skipped).`;
 
-const orderingNote = `**All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied.** For ${modeLabel} that means: ${phaseSequence}. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks. Full ordering contract in \`$HOME/.claude/multi-agent-refs/tracker-contract.md\` section "TaskCreate ordering (strict)".`;
+const orderingNote = `**All TaskCreate calls in a batch fire in strict phase-number order BEFORE any TaskUpdate is applied.** For ${modeLabel} that means: ${spec.depth ? `Phase 0 at Step -1, then the rest in ascending order at Step 7.5 (${phaseSequence} minus whatever the depth answer drops)` : phaseSequence}. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks. Full ordering contract in \`$HOME/.claude/multi-agent-refs/tracker-contract.md\` section "TaskCreate ordering (strict)".`;
 
 const localCaveat = spec.local
   ? `\n> **Local mode:** no worktree is created, work happens on the current branch. Phase 0 Init still calls \`init\`  -  the \`--local\` flag is stored in tracker-state.json, and \`:resume\` restores the correct CWD.\n`
@@ -114,6 +113,32 @@ const banner = spec.autopilot
   ? `\n> **Autopilot mode:** user confirmations are skipped. The tracker is still mandatory  -  autopilot agent calls cannot skip it; skipping breaks \`smoke-tracker-contract.sh\`.\n`
   : "";
 
+// Registration shape. A mode that asks the depth question does not know its phase
+// set at Step -1 (the answer needs taskType, which needs the fetched issue and the
+// branch), so it registers Phase 0 there and the rest at Step 7.5. Drawing eight
+// tiles beside the question that decides whether two of them run is the failure this
+// split exists to remove.
+const fullSet = spec.phases.filter((p) => p !== "0:Init");
+const shortSet = fullSet.filter((p) => Number(p.split(":")[0]) >= 3);
+const loopFor = (list) =>
+  `for p in ${list.map((x) => `"${x}"`).join(" ")}; do\n  bash $HOME/.claude/scripts/phase-tracker.sh add "\${p%%:*}" "\${p#*:}"\ndone`;
+
+const initLoop = spec.depth
+  ? 'bash $HOME/.claude/scripts/phase-tracker.sh add 0 "Init"\nbash $HOME/.claude/scripts/phase-tracker.sh tiles'
+  : `${loopFor(spec.phases)}`;
+
+const deferredBlock = spec.depth
+  ? `
+# Phase 0 Step 7.5, immediately after the depth answer - the first moment this
+# mode knows its phase set. Full:
+${loopFor(fullSet)}
+# Short (Analysis and Planning are not run, so they get no tile at all):
+${loopFor(shortSet)}
+# Then the widget, narrowed to the phases that do not have a tile yet:
+bash $HOME/.claude/scripts/phase-tracker.sh tiles --new
+`
+  : "";
+
 const out = `## Required: Phase Tracker Contract
 
 **The phase tracker is mandatory**  -  the agent cannot skip it. Full spec: [\`$HOME/.claude/multi-agent-refs/tracker-contract.md\`]($HOME/.claude/multi-agent-refs/tracker-contract.md).
@@ -126,11 +151,9 @@ Two channels run in parallel at every phase boundary:
 \`\`\`bash
 # Phase 0, very first shell call (every CLI):
 bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
-for p in ${phaseLoop}; do
-  bash $HOME/.claude/scripts/phase-tracker.sh add "\${p%%:*}" "\${p#*:}"
-done
+${initLoop}
 bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
-
+${deferredBlock}
 # Every phase boundary (every CLI):
 bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|failed|skipped
 
@@ -142,11 +165,11 @@ bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out> [cached]
 
 In Claude Code the agent MUST also drive the native TaskList widget so the user sees a sticky phase tile stack  -  this is the only progress signal Claude Code surfaces. Skipping these calls is the #1 source of "I don't see any phases" complaints.
 
-**TaskCreate ordering (strict)**: All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks (e.g. \`1 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐\`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN  -  register the tile in order, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in \`$HOME/.claude/multi-agent-refs/tracker-contract.md\` section "TaskCreate ordering (strict)".
+**TaskCreate ordering (strict)**: All TaskCreate calls in a registration batch fire in strict phase-number order BEFORE any TaskUpdate in that batch, and a later batch only ever appends phases numbered above everything already registered.${spec.depth ? " This mode registers in two batches (Step -1, then Step 7.5), so `tiles --new` narrows the second one and the Phase 0 tile is never created twice." : ""} The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks (e.g. \`1 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐\`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN  -  register the tile in order, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in \`$HOME/.claude/multi-agent-refs/tracker-contract.md\` section "TaskCreate ordering (strict)".
 
 \`\`\`text
-# Phase 0 startup  -  register one tile per phase (0..N), capture the taskId, persist it:
-for each phase in ${spec.phases.join(", ")}:
+# Register one tile per phase, capture the taskId, persist it:
+for each phase in ${spec.depth ? `0:Init at Step -1, then ${fullSet.join(", ")} (Full) or ${shortSet.join(", ")} (Short) at Step 7.5` : spec.phases.join(", ")}:
   TaskCreate({ subject: "Phase <N>: <Name>", activeForm: "<doing-form>" })
     -> returns taskId
   bash $HOME/.claude/scripts/phase-tracker.sh meta <N> tasklist_id "<taskId>"

package/pipeline/scripts/phase-tracker.sh

@@ -681,8 +681,17 @@ EOF
 # a subject is a task title and travels through surfaces that are not a terminal.
 subjects() {
   need_jq
-  local state want="${1:-}"
+  local state want="${1:-}" new_only=""
+  # `--new` narrows to phases that have no tile yet, which is how a deferred
+  # registration batch (Phase 0 at Step -1, the rest once depth is known) avoids
+  # asking the host to create a tile it already has. A phase whose tasklist_id was
+  # never recorded has, as far as anything can tell, no tile.
+  if [ "$want" = "--new" ]; then new_only=1; want=""; fi
   state=$(load_state)
+  local new_ids=""
+  if [ -n "$new_only" ]; then
+    new_ids=" $(echo "$state" | jq -r '[.phases[]? | select(((.meta.tasklist_id // "") | tostring) == "") | .id] | join(" ")') "
+  fi
   local prices_json='{"prices":{}}'
   if [ -f "$COST_TABLE" ]; then
     prices_json=$(cat "$COST_TABLE" 2>/dev/null) || prices_json='{"prices":{}}'
@@ -704,6 +713,9 @@ subjects() {
   while IFS=$'\x1f' read -r pid pname pstatus p_start p_end pmodel ptok pusd; do
     [ -n "$pid" ] || continue
     [ -z "$want" ] || [ "$want" = "$pid" ] || continue
+    if [ -n "$new_only" ]; then
+      case "$new_ids" in *" $pid "*) ;; *) continue ;; esac
+    fi
     local line="Phase $pid $pname"
     [ -n "$pmodel" ] && line="$line - $pmodel"
     local s_ep e_ep el=""
@@ -755,10 +767,33 @@ subjects() {
 # already does for a different reason.
 tiles_script() {
   need_jq
+  local new_only="${1:-}"
   local state; state=$(load_state)
   local has_subs
   has_subs=$(echo "$state" | jq '[.phases[]?.subs[]?] | length')
 
+  # A list carrying sub-steps has to be rebuilt whole, so the rebuild wins over a
+  # narrowed batch: appending to it would land the new rows after Phase 7.
+  [ "${has_subs:-0}" -gt 0 ] && new_only=""
+
+  if [ -n "$new_only" ]; then
+    local pending_new
+    pending_new=$(subjects --new)
+    if [ -z "$pending_new" ]; then
+      printf 'Every registered phase already has a tile - nothing to create.\n'
+      return 0
+    fi
+    printf 'REQUIRED  -  create one native tile per phase below, in this exact order.
+'
+    printf 'Tiles already created keep their place; every phase here is numbered
+'
+    printf 'above them, so the widget stays in phase order.
+
+'
+    printf '%s\n' "$pending_new" | sed 's/^/  TaskCreate(subject: "/; s/$/")/'
+    return 0
+  fi
+
   if [ "${has_subs:-0}" -gt 0 ]; then
     printf 'The tile list has sub-steps now, and the widget orders by CREATION.
 '
@@ -1346,6 +1381,8 @@ EOF
 
   tiles)
     need_jq
+    tiles_new=""
+    [ "${1:-}" = "--new" ] && tiles_new=1
     tiles_state=$(load_state)
     tiles_count=$(echo "$tiles_state" | jq '[.phases[]?] | length')
     [ "${tiles_count:-0}" -gt 0 ] || {
@@ -1368,7 +1405,7 @@ EOF
         # tools it has. And the fallback is not enough on its own: a user looking
         # at a missing widget needs the one command that brings it back, which is
         # why the opt-in is printed next to it.
-        tiles_script
+        tiles_script "$tiles_new"
         echo
         echo "At every phase boundary re-run \`phase-tracker.sh subjects <id>\` and"
         echo "pass that line as the subject of the TaskUpdate. The subject is the only"

package/pipeline/scripts/phase0-exit-gate.mjs

@@ -20,6 +20,20 @@
  * `agent-state.json` is the only durable evidence they happened - so the gate asserts
  * their output too, not just `taskType`.
  *
+ * A third run got past that, because `baseBranch` and `baseFetchStatus` can be filled
+ * in by a branch that was never chosen. The remote had one PR-targetable branch, the
+ * one-option `AskUserQuestion` was refused by the host (its schema needs two), and the
+ * run announced "only candidate, continuing with it" and carried on. The branch was
+ * right; nothing was asked. `baseBranchSource` is the field that separates those two,
+ * and the dev-context picker never ran at all - no `siblings`, so Phase 4's parity
+ * cross-check had nothing to read and could not tell an empty answer from no answer.
+ *
+ * A fourth showed the same shape one layer down: `git fetch origin` failed on a
+ * restricted network, `git branch -r` printed the remote-tracking cache anyway, and a
+ * weeks-old local list was presented as the remote's answer. Degrading to local refs is
+ * correct; reporting them as remote is not, so `baseBranchEvidence.refProvenance` has to
+ * agree with `baseFetchStatus`.
+ *
  * A phase that reports success without its output is worse than one that fails:
  * every later phase then reasons from a field that is not there. So this is a
  * gate, not a lint  -  the spec already said what to write, and prose alone did
@@ -157,6 +171,120 @@ export function evaluate(state, extraInput = "") {
     );
   }
 
+  // Which rule decided the base branch. `asked` and `input` are the only two an
+  // interactive run can honestly record: `remembered`, `default` and `derived` are the
+  // autopilot resolutions, and an interactive run that reaches for them has skipped its
+  // picker. This is the assertion `baseBranch` alone cannot make - a branch announced in
+  // prose and a branch chosen by the user leave the same value behind. A branch the run
+  // derived from the issue and the user then confirmed is still `asked`; the derivation
+  // lives in `baseBranchEvidence`, which is a record, not a permission.
+  const BRANCH_SOURCES = ["asked", "input", "remembered", "default", "derived"];
+  const branchSource =
+    typeof state.baseBranchSource === "string" ? state.baseBranchSource.trim() : "";
+  if (baseBranch && !BRANCH_SOURCES.includes(branchSource)) {
+    failures.push(
+      `agent-state.json has baseBranchSource="${branchSource || "<unset>"}"; Step 3 must ` +
+        `record one of ${BRANCH_SOURCES.join(" | ")}. Unset means nothing distinguishes a ` +
+        `branch the user chose from one the run picked and announced.`,
+    );
+  }
+  const isAutopilot = state.autopilot === true;
+  const AUTOPILOT_ONLY_SOURCES = ["remembered", "default", "derived"];
+  if (!isAutopilot && AUTOPILOT_ONLY_SOURCES.includes(branchSource)) {
+    failures.push(
+      `baseBranchSource="${branchSource}" on an interactive run. Those three are autopilot ` +
+        `resolutions; an interactive run asks (Step 3 is not skippable) or takes the base ` +
+        `from the task reference. A one-candidate filter is still asked, with a second ` +
+        `option - picker-contract.md, "Two options or it is not a question".`,
+    );
+  }
+
+  // What the base branch was chosen from, and what that list was worth.
+  //
+  // Two separate silent failures live here. The first: `git fetch origin` can fail on a
+  // restricted network while `git branch -r` still prints a full, confident list - the
+  // remote-tracking cache - so a weeks-old local guess gets presented as the remote's
+  // answer. Falling back to local refs is correct; not saying so is not. The second:
+  // `derived` claims the issue named the branch, and a claim with no evidence behind it
+  // is `default` wearing a hat.
+  const evidence =
+    state.baseBranchEvidence && typeof state.baseBranchEvidence === "object"
+      ? state.baseBranchEvidence
+      : null;
+  const DEGRADED_FETCH = ["cached-stale", "local-branch"];
+  if (DEGRADED_FETCH.includes(fetchStatus)) {
+    if (!evidence) {
+      failures.push(
+        `baseFetchStatus="${fetchStatus}" but state.baseBranchEvidence is absent. A run whose ` +
+          `fetch failed listed its branches from local refs; the record of that is what stops a ` +
+          `local-only guess being read afterwards as the remote's answer.`,
+      );
+    } else if (evidence.refProvenance !== "local") {
+      failures.push(
+        `baseFetchStatus="${fetchStatus}" but baseBranchEvidence.refProvenance=` +
+          `"${evidence.refProvenance || "<unset>"}". The fetch failed, so the candidate list came ` +
+          `from local refs and must say so - "remote" here is the silent degradation this field exists to catch.`,
+      );
+    }
+  }
+  if (branchSource === "derived") {
+    const ISSUE_DERIVED = new Set(["issue-version", "linked-release"]);
+    const cands = evidence && Array.isArray(evidence.candidates) ? evidence.candidates : [];
+    const chosen = cands.find((c) => c && c.branch === baseBranch);
+    const hasIssueEvidence =
+      chosen &&
+      Array.isArray(chosen.evidence) &&
+      chosen.evidence.some((e) => e && ISSUE_DERIVED.has(e.kind));
+    if (!hasIssueEvidence) {
+      failures.push(
+        `baseBranchSource="derived" but baseBranchEvidence carries no issue-version or ` +
+          `linked-release evidence for "${baseBranch}". "Derived" names a specific claim - the ` +
+          `issue's version field or a linked release issue pointed at this branch - and without ` +
+          `that record it is the sort-order default under a better name.`,
+      );
+    }
+    if (evidence && evidence.ambiguous === true) {
+      failures.push(
+        `baseBranchSource="derived" with baseBranchEvidence.ambiguous=true. Two or more ` +
+          `candidates tied at the top score; autopilot does not break a tie by picking one.`,
+      );
+    }
+  }
+
+  // Step 5b decides where the branch lives, and `localMode` alone cannot say
+  // whether anyone decided: `false` is both "the user chose a worktree" and
+  // "nothing asked and the default stood". Same shape as baseBranchSource, and
+  // the same reason - an autopilot run resolves it rather than asking, so
+  // `autopilot` is a legal source there and nowhere else.
+  const WORKSPACE_SOURCES = ["asked", "command", "autopilot"];
+  const workspaceSource =
+    typeof state.workspaceSource === "string" ? state.workspaceSource.trim() : "";
+  if (!WORKSPACE_SOURCES.includes(workspaceSource)) {
+    failures.push(
+      `agent-state.json has workspaceSource="${workspaceSource || "<unset>"}"; Step 5b must ` +
+        `record one of ${WORKSPACE_SOURCES.join(" | ")}. Unset means nothing distinguishes a ` +
+        `worktree the user chose from one no question was asked about.`,
+    );
+  }
+  if (!isAutopilot && workspaceSource === "autopilot") {
+    failures.push(
+      `workspaceSource="autopilot" on an interactive run. Autopilot resolves the workspace ` +
+        `to a worktree because an unattended commit in the user's own checkout is what ` +
+        `worktrees prevent; an interactive run asks (Step 5b) or is told by :local / --local.`,
+    );
+  }
+
+  // Step 2b's dev-context picker writes siblings[], empty included. The empty array is
+  // the record that it ran; absent, a multi-repo task silently became a single-repo one
+  // and Phase 4's parity cross-check lost its fourth counterpart source.
+  if (!Array.isArray(state.siblings)) {
+    failures.push(
+      "agent-state.json has no siblings array. Step 2b runs the dev-context picker on " +
+        "every input type and persists the result, `[]` included; an absent field means " +
+        "the picker never ran, so extra repos and read-only counterparts were never offered.",
+    );
+  }
+
   // Worktree isolation is a standing rule: never develop in the primary checkout.
   const worktree = typeof state.worktreePath === "string" ? state.worktreePath.trim() : "";
   const projectRoot = typeof state.projectRoot === "string" ? state.projectRoot.trim() : "";

package/pipeline/scripts/verify-citations.mjs

@@ -67,6 +67,79 @@ export function unsafePath(p) {
   return null;
 }
 
+/**
+ * Extensions a markdown citation may carry.
+ *
+ * A list, not a pattern, and that direction is deliberate: the cost of a
+ * missing extension is one citation going unchecked, while the cost of an open
+ * pattern is the gate failing a correct document over a hostname. Add to it
+ * when a real repository file is missed - never widen it to a wildcard.
+ *
+ * `com`, `net`, `io`, `dev`, `tr` are absent on purpose.
+ */
+export const SOURCE_EXTENSIONS = new Set([
+  "swift",
+  "kt",
+  "kts",
+  "java",
+  "m",
+  "mm",
+  "h",
+  "hpp",
+  "c",
+  "cc",
+  "cpp",
+  "js",
+  "mjs",
+  "cjs",
+  "jsx",
+  "ts",
+  "tsx",
+  "py",
+  "rb",
+  "go",
+  "rs",
+  "php",
+  "sh",
+  "bash",
+  "zsh",
+  "pl",
+  "sql",
+  "json",
+  "yml",
+  "yaml",
+  "toml",
+  "xml",
+  "plist",
+  "xcconfig",
+  "pbxproj",
+  "gradle",
+  "properties",
+  "cfg",
+  "ini",
+  "env",
+  "md",
+  "mdx",
+  "txt",
+  "csv",
+  "tsv",
+  "strings",
+  "stringsdict",
+  "html",
+  "css",
+  "scss",
+  "vue",
+  "svelte",
+  "graphql",
+  "proto",
+  "entitlements",
+  "storyboard",
+  "xib",
+  "lock",
+  "gemspec",
+  "podspec",
+]);
+
 /**
  * Pull `{file, line}` pairs out of whatever was handed over.
  *
@@ -124,6 +197,14 @@ export function extract(raw) {
   // Fenced blocks are skipped for the same class of reason: a code sample that
   // happens to contain `foo.js:12` is an illustration, not a claim about this
   // repository.
+  //
+  // The URL strip below only removes what carries a scheme. A host written
+  // bare - `wiki.example.com:8443/x`, and an analysis document is full of
+  // them - still looks exactly like a path with an extension and a line
+  // number, and this gate would fail the document over `.com`. So the
+  // extension has to be one a repository actually contains. This is the same
+  // defect that was already fixed once here for scheme-carrying URLs; the bare
+  // form survived it.
   let fenced = false;
   raw.split("\n").forEach((line, i) => {
     if (/^\s*```/.test(line)) {
@@ -132,8 +213,9 @@ export function extract(raw) {
     }
     if (fenced) return;
     const cleaned = line.replace(/\b[a-z][a-z0-9+.-]*:\/\/\S+/gi, " ");
-    for (const m of cleaned.matchAll(/([A-Za-z0-9_./-]+\.[A-Za-z][A-Za-z0-9]*):(\d+)/g)) {
-      push(m[1], Number(m[2]), `line ${i + 1}`);
+    for (const m of cleaned.matchAll(/([A-Za-z0-9_./-]+\.([A-Za-z][A-Za-z0-9]*)):(\d+)/g)) {
+      if (!SOURCE_EXTENSIONS.has(m[2].toLowerCase())) continue;
+      push(m[1], Number(m[3]), `line ${i + 1}`);
     }
   });
   return out;

package/pipeline/skills/.skill-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": "1.0.0",
-  "generatedAt": "2026-09-14T11:56:29Z",
+  "generatedAt": "2026-09-15T12:49:28Z",
   "skillCount": 212,
   "entries": [
     {
@@ -237,7 +237,7 @@
     },
     {
       "path": "shared/core/multi-agent/SKILL.md",
-      "sha256": "de56a86c64f1e6f56d1d4e5f0e129f04e44c36d930caa3857dd5c46689e8e501"
+      "sha256": "faac7ceb535d18778efe0ea91c19534c8e076bc709e7b1dbc567f5e71692bbbd"
     },
     {
       "path": "shared/external/accessibility-compliance-accessibility-audit/SKILL.md",

package/pipeline/skills/shared/core/multi-agent/SKILL.md

@@ -316,7 +316,7 @@ All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is
 - `multi-agent-local`, `multi-agent-autopilot`, `multi-agent-local-autopilot`: 0 → 1 → 2 → 3 → 4 → 6 → 7 (the interactive Phase 5 gate needs a worktree checkout and an attended run)
 - `multi-agent-analysis`: 0 → 1 → 2 → 4 → 6 → 7 (no code, so no Dev and no Test)
 
-Depth does not change the SET. A Short run (the Phase 0 Step 7.5 answer) registers its command's full set and flips Phases 1 and 2 to `skipped` when the answer lands at Step 7.5 - the tracker boots at Step -1, long before the question can be asked.
+Depth decides WHICH of the command's set is registered. The tracker boots at Step -1, long before the depth question can be asked, so it registers Phase 0 alone and the remaining tiles are created at Step 7.5 once the answer is known - a Short run never draws an Analysis or Planning tile.
 
 Full contract: `refs/tracker-contract.md` section "TaskCreate ordering (strict)".