@mmerterden/multi-agent-pipeline 19.1.4 → 20.1.0

package/pipeline/schemas/migrations/prefs-2.7.0-to-2.8.0.mjs

@@ -0,0 +1,33 @@
+/**
+ * prefs-2.7.0-to-2.8.0.mjs  -  preferences migration
+ *
+ * v20.0.0 folds `/multi-agent:resume-local` into `/multi-agent:resume`. One
+ * command now asks which unfinished work to pick up: a run that stopped
+ * mid-phase, or a branch carrying work no run ever produced. The preference
+ * that decides whether triage-accepted findings are auto-fixed applies to the
+ * second path, so it moves with it: `global.resumeLocal` -> `global.resume`.
+ *
+ * The value is carried, never reset. Someone who turned auto-fix on for the
+ * tail meant it for exactly the work this path still handles.
+ *
+ * @param {object} data  -  parsed multi-agent-preferences.json
+ * @returns {object}     -  migrated data with schemaVersion "2.8.0"
+ */
+export default function migrate(data) {
+  const out = JSON.parse(JSON.stringify(data));
+
+  out.schemaVersion = "2.8.0";
+
+  if (!out.global || typeof out.global !== "object") return out;
+
+  const legacy = out.global.resumeLocal;
+  if (!out.global.resume || typeof out.global.resume !== "object") {
+    out.global.resume = {};
+  }
+  if (typeof out.global.resume.autoFix !== "boolean") {
+    out.global.resume.autoFix = typeof legacy?.autoFix === "boolean" ? legacy.autoFix : false;
+  }
+  delete out.global.resumeLocal;
+
+  return out;
+}

package/pipeline/schemas/phases.json

@@ -6,7 +6,6 @@
   "phaseSchema": 2,
   "phaseSchemaNote": "The phase vocabulary generation. metrics.jsonl is append-only and v19.0.0 renumbered the phases, so every line written from v19.0.0 on carries this number and a line without the field is generation 1. Aggregators pick their name table from it; without it phase 3 means Dev in old rows and Review in new ones and no reader can tell them apart.",
   "legacyPhaseNames": {
-    "note": "Generation 1 phase names, kept so an aggregator can label a historical metrics.jsonl row correctly instead of printing the current name for a number that meant something else. Read-only history: nothing emits these any more. The generation 1 -> 2 number map is not repeated here, it is the `was` array on each phase above.",
     "0": "Init",
     "1": "Analysis",
     "2": "Planning",
@@ -14,7 +13,8 @@
     "4": "Review",
     "5": "Test",
     "6": "Commit",
-    "7": "Report"
+    "7": "Report",
+    "note": "Generation 1 phase names, kept so an aggregator can label a historical metrics.jsonl row correctly instead of printing the current name for a number that meant something else. Read-only history: nothing emits these any more. The generation 1 -> 2 number map is not repeated here, it is the `was` array on each phase above."
   },
   "phases": [
     {
@@ -64,42 +64,20 @@
   "modes": {
     "full": {
       "phases": [0, 1, 2, 3, 4, 5],
-      "local": false,
-      "autopilot": false,
-      "depth": true
+      "autopilot": false
     },
     "autopilot": {
       "phases": [0, 1, 2, 3, 4, 5],
-      "local": false,
-      "autopilot": true
-    },
-    "local": {
-      "phases": [0, 1, 2, 3, 4, 5],
-      "local": true,
-      "autopilot": false,
-      "depth": true
-    },
-    "local-autopilot": {
-      "phases": [0, 1, 2, 3, 4, 5],
-      "local": true,
       "autopilot": true
     },
-    "full-local": {
-      "phases": [0, 1, 2, 3, 4, 5],
-      "local": true,
-      "autopilot": false,
-      "depth": true
-    },
     "analysis": {
       "phases": [0, 1, 3, 4, 5],
-      "local": false,
       "autopilot": false
     }
   },
   "thresholds": {
     "waitingFromPhase": 4,
     "mcpAllowedThroughPhase": 1,
-    "shortRunFromPhase": 2,
-    "note": "Phase numbers other code compares against, named here so a renumbering moves them with the contract. waitingFromPhase: runs-index.mjs groups a run as 'waiting on you' from Commit on. mcpAllowedThroughPhase: Figma MCP is reachable only through Plan; smoke-no-mcp-in-dev-phases.sh fails any recorded call at a higher phase. Its literal threshold is unchanged from the eight-phase contract on purpose - Analysis was 1 and is now inside Plan, also 1, so the permitted set {0,1} is identical. shortRunFromPhase: the depth picker's Short set starts here."
+    "note": "Phase numbers other code compares against, named here so a renumbering moves them with the contract. waitingFromPhase: runs-index.mjs groups a run as 'waiting on you' from Commit on. mcpAllowedThroughPhase: Figma MCP is reachable only through Plan; smoke-no-mcp-in-dev-phases.sh fails any recorded call at a higher phase. Its literal threshold is unchanged from the eight-phase contract on purpose - Analysis was 1 and is now inside Plan, also 1, so the permitted set {0,1} is identical."
   }
 }

package/pipeline/schemas/prefs.schema.json

@@ -14,8 +14,8 @@
   "properties": {
     "schemaVersion": {
       "type": "string",
-      "enum": ["2.0.0", "2.1.0", "2.2.0", "2.3.0", "2.4.0", "2.5.0", "2.6.0", "2.7.0"],
-      "description": "v2.0.0: pre-v3.7. v2.1.0: v3.7+ adds identities[].servicePatMap, platformIdentityRouting, recentGroups, recentBranches, serviceStatus, settings, expanded keychainMapping. v2.2.0: v6.0.0 formalizes v5.7 / v5.8 additions (reportChannels, reportContent with technicalAnalysis, wikiScope, autopilotReportTimeoutSeconds) that had been running as 2.1.0 sub-migrations without a proper version bump. v2.5.0: v14.0.0 adds global.skillConformance (Phase 4 criteria resolution) and declares global.ship.autoFix, which the tail command's spec had referenced as global.finish.autoFix without ever declaring it. v2.6.0: v15.0.0 renames global.ship to global.resumeLocal (/multi-agent:ship -> :resume-local). v2.7.0: v19.0.0 drops the analysis Lite mode (global.analysisPhase.mode keeps a single value 'full') and adds global.modelRouting, which ships disabled."
+      "enum": ["2.0.0", "2.1.0", "2.2.0", "2.3.0", "2.4.0", "2.5.0", "2.6.0", "2.7.0", "2.8.0"],
+      "description": "v2.0.0: pre-v3.7. v2.1.0: v3.7+ adds identities[].servicePatMap, platformIdentityRouting, recentGroups, recentBranches, serviceStatus, settings, expanded keychainMapping. v2.2.0: v6.0.0 formalizes v5.7 / v5.8 additions (reportChannels, reportContent with technicalAnalysis, wikiScope, autopilotReportTimeoutSeconds) that had been running as 2.1.0 sub-migrations without a proper version bump. v2.5.0: v14.0.0 adds global.skillConformance (Phase 4 criteria resolution) and declares global.ship.autoFix, which the tail command's spec had referenced as global.finish.autoFix without ever declaring it. v2.6.0: v15.0.0 renames global.ship to global.resumeLocal (/multi-agent:ship -> :resume-local). v2.7.0: v19.0.0 drops the analysis Lite mode (global.analysisPhase.mode keeps a single value 'full') and adds global.modelRouting, which ships disabled. v2.8.0: v20.0.0 folds :resume-local into :resume and renames global.resumeLocal to global.resume."
     },
     "global": {
       "type": "object",
@@ -1923,15 +1923,15 @@
             }
           }
         },
-        "resumeLocal": {
+        "resume": {
           "type": "object",
           "additionalProperties": false,
-          "description": "/multi-agent:resume-local (formerly :ship, :finish) - the tail that runs review + build/test + PR + report over work already on the branch.",
+          "description": "/multi-agent:resume - picking up unfinished work, either a run that stopped mid-phase or a branch carrying work no run produced. These keys apply to the second path, which runs review + build/test + PR + report over the branch diff.",
           "properties": {
             "autoFix": {
               "type": "boolean",
               "default": false,
-              "description": "When true, resume-local auto-fixes triage-accepted blocking/important findings and re-reviews instead of asking. Equivalent to passing `autopilot` on every run. Default false: resume-local operates on work the user wrote by hand, so silently rewriting it is the surprising option."
+              "description": "When true, the tail path auto-fixes triage-accepted blocking/important findings and re-reviews instead of asking. Equivalent to passing `autopilot` on every run. Default false: this path operates on work the user wrote by hand, so silently rewriting it is the surprising option."
             }
           }
         },
@@ -2140,10 +2140,6 @@
               "format": "date-time",
               "description": "Timestamp of last task start against this project."
             },
-            "componentDevWorkflow": {
-              "type": "boolean",
-              "description": "Project follows the component (Configuration / View / Modifiers) development workflow, so Phase 2 dispatches the component skills instead of the standard TDD flow."
-            },
             "figmaConfigPath": {
               "type": "string",
               "description": "Path to per-project figma-config.json (for Figma pipeline projects)."

package/pipeline/schemas/reviewer-output.schema.json

@@ -1,9 +1,9 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
   "$id": "https://github.com/mmerterden/multi-agent-pipeline/pipeline/schemas/reviewer-output.schema.json",
-  "version": "1.3.0",
+  "version": "1.4.0",
   "title": "Multi-Agent Pipeline  -  Phase 3 reviewer output",
-  "description": "Contract for a single code-reviewer subagent's JSON output in Phase 4 Step 2. Every host dispatches 3 parallel reviewers; the middle slot is CLI-aware: Claude Code (Fable, Opus, Sonnet); Copilot CLI (Opus, GPT-5.4, Sonnet); Codex CLI dispatches 3 (gpt-5.6 at xhigh, gpt-5.4, gpt-5.6 at medium). Every reviewer must return an object matching this shape before Opus triage merges them. v1.1.0 adds the rule-ID conformance checklist: when the orchestrator supplies a ${CRITERIA} block (Phase 3 Step 1.78), the reviewer must return one conformance row per selected rule ID. Findings alone cannot answer 'was this applied completely' - a reviewer that opened nothing returns the same empty findings array as one that checked everything. v1.2.0 adds the optional per-finding fingerprint (Phase 3 Step 2.1): the stable id a finding keeps across review rounds.",
+  "description": "Contract for a single code-reviewer subagent's JSON output in Phase 4 Step 2. Every host dispatches 3 parallel reviewers; the middle slot is CLI-aware: Claude Code (Fable, Opus, Sonnet); Copilot CLI (Opus, GPT-5.4, Sonnet); Codex CLI dispatches 3 (gpt-5.6 at xhigh, gpt-5.4, gpt-5.6 at medium). Every reviewer must return an object matching this shape before Opus triage merges them. v1.1.0 adds the rule-ID conformance checklist: when the orchestrator supplies a ${CRITERIA} block (Phase 3 Step 1.78), the reviewer must return one conformance row per selected rule ID. Findings alone cannot answer 'was this applied completely' - a reviewer that opened nothing returns the same empty findings array as one that checked everything. v1.2.0 adds the optional per-finding fingerprint (Phase 3 Step 2.1): the stable id a finding keeps across review rounds. v1.4.0 adds the optional per-finding `security` envelope (OWASP + CWE + CVSS + evidence + remediation): the security-auditor emits reviewer-output objects whose findings carry it, so a blocking security finding merges at Step 3.0 and blocks Phase 4 like any reviewer blocker. General reviewers omit it. Its shape mirrors security-finding.schema.json, kept in step by smoke-security-schema-parity.sh.",
   "type": "object",
   "additionalProperties": false,
   "required": ["findings", "approved"],
@@ -128,6 +128,103 @@
           "type": "string",
           "pattern": "^F:[0-9a-f]{8}$",
           "description": "Stable cross-round identity of the finding, computed by finding-fingerprint.mjs from (file, ruleId or normalized issue text). Never includes the line. On iteration >= 2 a reviewer that recognises an entry from <previous-round-findings> echoes its fingerprint; otherwise leave it unset and the script fills it in."
+        },
+        "security": {
+          "type": "object",
+          "additionalProperties": false,
+          "required": ["owaspCategory", "cwe", "cvss", "evidence", "confidence", "remediation"],
+          "description": "OPTIONAL security envelope. Present when the finding comes from the security-auditor (Phase 3 Step 3.0 merge) or /multi-agent:security-review; absent on a general code-reviewer finding. Its shape is the security block of security-finding.schema.json, kept in step by smoke-security-schema-parity.sh (self-contained, no cross-file $ref). validate-reviewer.mjs ignores it; triage carries it through unchanged so Phase 5 can report CVSS + CWE + remediation.",
+          "properties": {
+            "owaspCategory": {
+              "type": "string",
+              "pattern": "^(A(0[1-9]|10):2021|M[1-9]:2024|M10:2024)( .+)?$",
+              "description": "OWASP Top 10 2021 id (web/API) or OWASP Mobile Top 10 2024 id, optionally followed by a human title."
+            },
+            "cwe": {
+              "type": "string",
+              "pattern": "^CWE-[0-9]{1,5}$",
+              "description": "The specific CWE weakness id. One per finding."
+            },
+            "cve": {
+              "type": "string",
+              "pattern": "^CVE-[0-9]{4}-[0-9]{4,}$",
+              "description": "A published CVE, for a known-vulnerable dependency finding."
+            },
+            "cvss": {
+              "type": "object",
+              "additionalProperties": false,
+              "required": ["vector", "baseScore", "band"],
+              "description": "CVSS 3.1 base metrics; baseScore and band are computed from the vector by security_cvss_score.",
+              "properties": {
+                "vector": {
+                  "type": "string",
+                  "pattern": "^CVSS:3[.]1/AV:[NALP]/AC:[LH]/PR:[NLH]/UI:[NR]/S:[UC]/C:[NLH]/I:[NLH]/A:[NLH]$",
+                  "description": "Full CVSS 3.1 base vector."
+                },
+                "baseScore": {
+                  "type": "number",
+                  "minimum": 0,
+                  "maximum": 10,
+                  "description": "0.0 .. 10.0 base score."
+                },
+                "band": {
+                  "type": "string",
+                  "enum": ["none", "low", "medium", "high", "critical"],
+                  "description": "Qualitative band; maps to the finding severity (critical/high -> blocking, medium -> important, low/none -> suggestion)."
+                }
+              }
+            },
+            "evidence": {
+              "type": "string",
+              "minLength": 8,
+              "description": "What in the code proves the finding, cited by file:line."
+            },
+            "counterevidence": {
+              "type": "string",
+              "description": "What would disprove it, or the condition under which it is a false positive."
+            },
+            "confidence": {
+              "type": "string",
+              "enum": ["high", "medium", "low"],
+              "description": "How sure the auditor is the finding is real."
+            },
+            "confidenceRationale": {
+              "type": "string",
+              "description": "Why the confidence is what it is."
+            },
+            "severityChangeConditions": {
+              "type": "string",
+              "description": "The fact that, if learned, would move the severity."
+            },
+            "remediation": {
+              "type": "string",
+              "minLength": 8,
+              "description": "Remediation steps in prose."
+            },
+            "remediationDiff": {
+              "type": "object",
+              "additionalProperties": false,
+              "required": ["before", "after"],
+              "description": "The fix as a before/after pair.",
+              "properties": {
+                "before": { "type": "string" },
+                "after": { "type": "string" }
+              }
+            },
+            "endpoint": {
+              "type": "string",
+              "description": "The HTTP route or RPC method for a service-layer finding."
+            },
+            "method": {
+              "type": "string",
+              "enum": ["GET", "POST", "PUT", "PATCH", "DELETE", "HEAD", "OPTIONS"],
+              "description": "HTTP method for an endpoint finding."
+            },
+            "fixVerification": {
+              "type": "string",
+              "description": "How to confirm the fix worked - the test to add or check to run."
+            }
+          }
         }
       }
     }

package/pipeline/schemas/security-finding.schema.json

@@ -0,0 +1,144 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://github.com/mmerterden/multi-agent-pipeline/pipeline/schemas/security-finding.schema.json",
+  "version": "1.0.0",
+  "title": "Multi-Agent Pipeline  -  security finding",
+  "description": "Contract for one finding produced by the security-auditor subagent (Phase 3) and the /multi-agent:security-review command. A security finding IS a reviewer-output.schema.json finding - same core fields (severity, file, line, issue, fix) - carrying one extra `security` block. That is exactly why it works: the auditor emits reviewer-output objects whose findings have the block, they merge into the Phase 3 reviewer set at Step 3.0, and a blocking one blocks Phase 4 like any reviewer blocker. reviewer-output.schema.json declares the same `security` property as OPTIONAL on its finding; here it is REQUIRED, which is the whole difference between a general finding and a security finding. The severity enum is the reviewer's (blocking|important|suggestion), never a private Critical/High/Medium scale: severity is derived from security.cvss.band by the rule on the `severity` property, and a severity that contradicts the band is the one inconsistency this contract forbids. The two schemas are kept in step by smoke-security-schema-parity.sh, not by a cross-file $ref, matching the self-contained style of the other pipeline schemas.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["severity", "file", "line", "issue", "fix", "security"],
+  "properties": {
+    "severity": {
+      "type": "string",
+      "enum": ["blocking", "important", "suggestion"],
+      "description": "The reviewer severity, derived from security.cvss.band so this finding filters through triage like any other: critical or high band -> blocking; medium -> important; low or none -> suggestion. It is not a free choice - a severity that disagrees with the band is the one inconsistency this schema exists to forbid."
+    },
+    "file": {
+      "type": "string",
+      "minLength": 1,
+      "description": "Path relative to repo root. The auditor must not invent a file that is not in the tree."
+    },
+    "line": {
+      "type": "integer",
+      "minimum": 0,
+      "description": "Line number. 0 = whole-file, configuration-level, or dependency-manifest finding."
+    },
+    "issue": {
+      "type": "string",
+      "minLength": 4,
+      "description": "What is wrong, in one sentence. The vulnerability, not the fix."
+    },
+    "fix": {
+      "type": "string",
+      "minLength": 4,
+      "description": "Concrete remediation in one line, for the reviewer-shaped view. The full before/after diff lives in security.remediationDiff."
+    },
+    "ruleId": {
+      "type": "string",
+      "minLength": 1,
+      "description": "Stable id of a cited rule (e.g. SEC-03) when the finding comes from a standards registry supplied to the auditor. The author can look the rule up and argue with it rather than with the auditor."
+    },
+    "criteriaSource": {
+      "type": "string",
+      "minLength": 1,
+      "description": "Which source the rule came from: a registry name, a compliance catalog (apple-archive-compliance / google-play-compliance), a reference path, or 'threat-model' when the finding is derived from the run-scoped threat model rather than a fixed rule."
+    },
+    "security": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["owaspCategory", "cwe", "cvss", "evidence", "confidence", "remediation"],
+      "description": "The security envelope. Present on every security finding; optional on a general reviewer finding.",
+      "properties": {
+        "owaspCategory": {
+          "type": "string",
+          "pattern": "^(A(0[1-9]|10):2021|M[1-9]:2024|M10:2024)( .+)?$",
+          "description": "The OWASP category: web/API uses OWASP Top 10 2021 ids (A01:2021 .. A10:2021), mobile uses OWASP Mobile Top 10 2024 ids (M1:2024 .. M10:2024). An optional human title may follow the id, e.g. 'A01:2021 Broken Access Control'."
+        },
+        "cwe": {
+          "type": "string",
+          "pattern": "^CWE-[0-9]{1,5}$",
+          "description": "The specific weakness, as a validated CWE id (CWE-89, CWE-798, ...). One weakness per finding; if a line has two, it is two findings."
+        },
+        "cve": {
+          "type": "string",
+          "pattern": "^CVE-[0-9]{4}-[0-9]{4,}$",
+          "description": "A published CVE, when the finding is a known-vulnerable dependency rather than first-party code. Set by the dependency-audit path, not by static code review."
+        },
+        "cvss": {
+          "type": "object",
+          "additionalProperties": false,
+          "required": ["vector", "baseScore", "band"],
+          "description": "CVSS 3.1 base metrics. The auditor writes the vector; security_cvss_score (toolkit) computes baseScore and band from it, so the two cannot drift from the vector by hand.",
+          "properties": {
+            "vector": {
+              "type": "string",
+              "pattern": "^CVSS:3[.]1/AV:[NALP]/AC:[LH]/PR:[NLH]/UI:[NR]/S:[UC]/C:[NLH]/I:[NLH]/A:[NLH]$",
+              "description": "A full CVSS 3.1 base vector string. All eight base metrics are required; temporal and environmental metrics are out of scope for a static review."
+            },
+            "baseScore": {
+              "type": "number",
+              "minimum": 0,
+              "maximum": 10,
+              "description": "The CVSS 3.1 base score computed from the vector by security_cvss_score. 0.0 .. 10.0, one decimal."
+            },
+            "band": {
+              "type": "string",
+              "enum": ["none", "low", "medium", "high", "critical"],
+              "description": "The qualitative band of baseScore: none 0.0, low 0.1-3.9, medium 4.0-6.9, high 7.0-8.9, critical 9.0-10.0. This is what maps to `severity`."
+            }
+          }
+        },
+        "evidence": {
+          "type": "string",
+          "minLength": 8,
+          "description": "What in the code proves the finding, quoted or cited by file:line. A static finding with no evidence is a guess; this is what a reader checks before agreeing."
+        },
+        "counterevidence": {
+          "type": "string",
+          "description": "What in the code would DISPROVE the finding, or the condition under which it is a false positive - a guard elsewhere, a framework default, an unreachable path. Stating it keeps confidence honest; leaving it blank asserts there is none."
+        },
+        "confidence": {
+          "type": "string",
+          "enum": ["high", "medium", "low"],
+          "description": "How sure the auditor is that this is real. Low confidence does not mean do-not-report; it means report with the counterevidence and let triage weigh it."
+        },
+        "confidenceRationale": {
+          "type": "string",
+          "description": "One line on why the confidence is what it is - what was and was not verifiable from the code alone."
+        },
+        "severityChangeConditions": {
+          "type": "string",
+          "description": "The fact that, if learned, would move the severity: 'critical if this endpoint is unauthenticated in production; medium if it is admin-only'. Names the assumption the score rests on."
+        },
+        "remediation": {
+          "type": "string",
+          "minLength": 8,
+          "description": "The remediation steps in prose - what to change and why it closes the weakness. Actionable, not 'sanitize input'."
+        },
+        "remediationDiff": {
+          "type": "object",
+          "additionalProperties": false,
+          "required": ["before", "after"],
+          "description": "The fix as a before/after pair the author can read as a diff. Optional - some findings are configuration or process changes with no single code hunk - but preferred for first-party code.",
+          "properties": {
+            "before": { "type": "string", "description": "The vulnerable code as it stands." },
+            "after": { "type": "string", "description": "The same region after the fix." }
+          }
+        },
+        "endpoint": {
+          "type": "string",
+          "description": "The HTTP route or RPC method the finding sits on, when it is a service-layer issue. Empty for non-network findings."
+        },
+        "method": {
+          "type": "string",
+          "enum": ["GET", "POST", "PUT", "PATCH", "DELETE", "HEAD", "OPTIONS"],
+          "description": "The HTTP method for an endpoint finding."
+        },
+        "fixVerification": {
+          "type": "string",
+          "description": "How to confirm the fix worked - the test to add or the check to run. Static review cannot fire an exploit, so this is the empirical step a human or a later dynamic pass takes."
+        }
+      }
+    }
+  }
+}

package/pipeline/scripts/_stack-routing.mjs

@@ -28,6 +28,7 @@ export const COMMON_SKILLS = [
   "skill-creator",
   "backlog",
   "localization-reuse-map",
+  "security-review",
 ];
 
 // The analyst plugin is the second always-enabled toolkit. It carries outside

package/pipeline/scripts/cost-table.json

@@ -16,7 +16,7 @@
       "cacheReadPerMtok": 0.5,
       "modelId": "claude-opus-5",
       "provider": "anthropic",
-      "note": "Second tier - dev phase on a Short run, Reviewer 1 and triage on Copilot CLI, and the opus rung of the fable -> opus -> sonnet fallback ladder. Same rate as the Opus 4.8 it replaces, so the ledger needed no reprice on the generation move. Claude Opus 5 draws on a rate-limit pool SEPARATE from the combined Opus 4.x pool - moving traffic here neither frees headroom on the old bucket nor inherits it."
+      "note": "Second tier - Reviewer 1 and triage on Copilot CLI, and the opus rung of the fable -> opus -> sonnet fallback ladder. Same rate as the Opus 4.8 it replaces, so the ledger needed no reprice on the generation move. Claude Opus 5 draws on a rate-limit pool SEPARATE from the combined Opus 4.x pool - moving traffic here neither frees headroom on the old bucket nor inherits it."
     },
     "sonnet": {
       "inPerMtok": 3.0,

package/pipeline/scripts/gc-abandoned.sh

@@ -11,9 +11,9 @@
 # Three things keep this from being a foot-gun, and each is a rule rather than a
 # heuristic:
 #
-#   1. A run WAITING FOR YOU is never reaped. An open PR, Phase 4 or 7, or
-#      `status: awaiting_input` means the work landed and the pipeline is
-#      holding for an answer by design. That is finished work, not residue.
+#   1. A run WAITING FOR YOU is never reaped. An open PR, the Commit or Report
+#      phase, or `status: awaiting_input` means the work landed and the pipeline
+#      is holding for an answer by design. That is finished work, not residue.
 #   2. A path that is not strictly inside `<repo>/.worktrees/` is never removed.
 #      This is not theoretical: four state files on that machine record
 #      `worktreePath` as the REPO ROOT, so a sweep that trusted the field would
@@ -96,6 +96,13 @@ case "$DAYS$PHASE0_DAYS" in *[!0-9]*) echo "gc-abandoned: --days and --phase0-da
 command -v jq >/dev/null 2>&1 || { echo "gc-abandoned: jq is required"; exit 0; }
 [ -d "$LOGS" ] || { echo "gc-abandoned: nothing to do (no state at $LOGS)"; exit 0; }
 
+# The phase from which a stopped run is "waiting on you", not residue, is the
+# contract's threshold - Commit onward - not a literal pinned to one numbering.
+# runs-index.mjs groups the same way from the same field.
+SELF_DIR=$(cd "$(dirname "$0")" && pwd)
+WAITING_FROM=$(jq -r '.thresholds.waitingFromPhase' "$SELF_DIR/../schemas/phases.json" 2>/dev/null || echo 4)
+case "$WAITING_FROM" in *[!0-9]*|"") WAITING_FROM=4 ;; esac
+
 # GNU form FIRST. `stat -f` is a valid GNU flag (--file-system) that succeeds and
 # prints a mount point, so BSD-first silently returns a number that is not a
 # timestamp. ADR-0012 lists this among the constructs that look cross-platform
@@ -142,7 +149,7 @@ while IFS= read -r state; do
   wt=$(jq -r '.worktreePath // ""' "$state" 2>/dev/null || true)
 
   # Rule 1: waiting for you is not residue.
-  if [ "$status" = "awaiting_input" ] || [ -n "$pr" ] || [ "$phase" = "6" ] || [ "$phase" = "7" ]; then
+  if [ "$status" = "awaiting_input" ] || [ -n "$pr" ] || { [ "$phase" != "?" ] && [ "$phase" -ge "$WAITING_FROM" ] 2>/dev/null; }; then
     skipped_waiting=$((skipped_waiting + 1))
     continue
   fi
@@ -271,10 +278,10 @@ if [ "$STATE_ONLY" -eq 0 ] && [ -d "$REPOS" ]; then
       ph=$(printf '%s' "$row" | cut -f5)
 
       # Rule 1 again: landed work is not residue, whichever pass finds it. Order
-      # matters here - the phase-4/5 test is a proxy for "still waiting", and a
-      # run whose status already says it FINISHED is not waiting for anyone. A
-      # complete run sitting at phase 7 was read as waiting and never reaped,
-      # which is how three finished worktrees held 5.1 GB indefinitely.
+      # matters here - the waiting-phase test is a proxy for "still waiting", and
+      # a run whose status already says it FINISHED is not waiting for anyone. A
+      # complete run sitting at the report phase was read as waiting and never
+      # reaped, which is how three finished worktrees held 5.1 GB indefinitely.
       case "$st" in
         complete | completed | failed) ;;
         awaiting_input)
@@ -282,7 +289,7 @@ if [ "$STATE_ONLY" -eq 0 ] && [ -d "$REPOS" ]; then
         in_progress | paused)
           continue ;; # pass 1 owns these; do not report them twice
         *)
-          if [ -n "$pr" ] || [ "$ph" = "6" ] || [ "$ph" = "7" ]; then
+          if [ -n "$pr" ] || { [ "$ph" != "?" ] && [ "$ph" -ge "$WAITING_FROM" ] 2>/dev/null; }; then
             skipped_waiting=$((skipped_waiting + 1)); continue
           fi ;;
       esac

package/pipeline/scripts/gc-refs.sh

@@ -4,7 +4,7 @@
 # `offload-ref.sh` parks build logs, diffs and test output under
 # <root>/.multi-agent/refs/<node_id>.md so a phase prompt can carry a pointer
 # instead of the whole log. In worktree modes that directory dies with the
-# worktree. In the --local modes there is no worktree: the refs land in the
+# worktree. With a local workspace there is no worktree: the refs land in the
 # real checkout and nothing ever removes them. They are gitignored, so they are
 # invisible to `git status` and grow without bound.
 #

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

@@ -16,12 +16,9 @@ import { readFileSync } from "node:fs";
  *   node pipeline/scripts/gen-mode-dispatch.mjs --mode=autopilot    # 0..5
  *   node pipeline/scripts/gen-mode-dispatch.mjs --mode=analysis     # 0/1/3/4/5 (no Dev)
  *
- * 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 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.
+ * There is one pipeline. A mode's phase set is a property of the COMMAND and is
+ * known before the tracker boots, so every mode registers its whole set at
+ * Step -1 and no registration is deferred.
  *
  * Companion smoke `smoke-mode-dispatch-drift.sh` regenerates the section for
  * each mode file, diffs against the on-disk content, and fails on drift.
@@ -63,9 +60,7 @@ const MODES = Object.fromEntries(
     name,
     {
       phases: modePhases(name),
-      local: m.local,
       autopilot: m.autopilot,
-      ...(m.depth ? { depth: true } : {}),
     },
   ]),
 );
@@ -86,9 +81,6 @@ const phaseSequence = activeIds.map((id) => `Phase ${id}`).join(" → ");
 const MODE_LABELS = {
   autopilot: "`autopilot`",
   full: "full-pipeline",
-  local: "`--local`",
-  "local-autopilot": "`--local autopilot`",
-  "full-local": "full-pipeline + `--local`",
 };
 const modeLabel = MODE_LABELS[MODE] ?? `\`${MODE}\``;
 
@@ -98,46 +90,24 @@ 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 ${PHASES.length} phases (no phase is skipped).`;
 
-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`
-  : "";
+const orderingNote = `**All TaskCreate calls in a batch 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 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]) >= 2);
+// Registration shape. Every mode knows its whole phase set at Step -1, so every
+// tile is created there and nothing is appended later.
 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 initLoop = loopFor(spec.phases);
+const deferredBlock = "";
 
 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).
-${banner}${localCaveat}
+${banner}
 Two channels run in parallel at every phase boundary:
 
 1. **State channel** (every CLI, identical): \`phase-tracker.sh\` writes to \`tracker-state.json\`. Drives \`:resume\`, \`:log\`, \`:status\`.
@@ -160,11 +130,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 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)".
+**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. 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
 # 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(", ")}:
+for each phase in ${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>"