@rryando/arcs 3.6.0 → 3.8.0

package/opencode/arcs/skills/writing-plans/SKILL.md

@@ -57,6 +57,10 @@ sourceFiles: [{path: "...", anchor: "..."}]
 ---end---
 ```
 
+## Prior Patterns Check
+
+Before mapping structure, read what the DAG already knows so the plan follows established shape: `arcs knowledge search <slug> "<feature-keywords>" --lean --json`, filtering for `kind=pattern` and `kind=architecture`. Reuse known conventions rather than inventing parallel ones.
+
 ## File Structure
 
 Before defining tasks, map which files will be created/modified:
@@ -110,7 +114,7 @@ Expected: PASS
 ```markdown
 # [Feature Name] Implementation Plan
 
-> **For agentic workers:** REQUIRED: Use arcs:subagent-driven-development (if subagents available) or arcs:executing-plans to implement this plan.
+> **For agentic workers:** REQUIRED: Use arcs:executing-plans to implement this plan (sequential single-agent by default, or parallel mode when independent tasks can fan out).
 
 **Goal:** [One sentence]
 
@@ -163,12 +167,13 @@ flowchart TD
 arcs plan create <slug> --title="YYYY-MM-DD <feature> Implementation Plan" --summary="..." --status=planned --keywords="implementation-plan" --body="<markdown>" --json
 ```
 
+Then extract the plan's "why this structure" rationale into a durable entry — don't let the architecture reasoning stay sealed inside the plan body: `arcs knowledge upsert <slug> "<feature> architecture rationale" --kind=architecture --summary="<why the structure is shaped this way; key trade-offs>" --keywords="<k1,k2>" --source-files="<path[:anchor],...>" --json`. Use `--kind=decision` instead when the entry is really a single settled call rather than a structural shape. Upsert is idempotent by title.
+
 ## Execution Handoff
 
 > "Plan complete and saved via `arcs plan get <slug> <planId>` in project `<slug>`. Ready to execute?"
 
-- **Subagents available** → REQUIRED: use `arcs:subagent-driven-development`
-- **No subagents** → use `arcs:executing-plans`
+- REQUIRED: use `arcs:executing-plans` — its parallel mode fans out independent tasks to subagents when available, falling back to sequential single-agent execution otherwise
 
 ## Constraints
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rryando/arcs",
-  "version": "3.6.0",
+  "version": "3.8.0",
   "description": "ARCS — DAG-based task orchestration for AI agents. Persistent workflow continuity via graph-structured context.",
   "type": "module",
   "main": "dist/index.js",
@@ -57,5 +57,8 @@
     "vite": "^6.4.1",
     "vitest": "^3.2.4",
     "@types/bun": "latest"
+  },
+  "allowScripts": {
+    "esbuild@0.25.12": true
   }
 }

package/scripts/build-opencode-bundle.mjs

@@ -30,10 +30,8 @@ const preservedOutputFiles = new Set([
   // Agent prompt files (repo-authored, referenced via {file:} in manifest.json)
   "prompts/software-engineer.txt",
   "prompts/tech-architect.txt",
-  "prompts/qa-analyst.txt",
   "prompts/oncall-ops.txt",
   "prompts/arcs-docs.txt",
-  "prompts/system-architect.txt",
   "prompts/code-reviewer.txt",
   "prompts/docs-researcher.txt",
   "prompts/devil-advocate.txt",

package/scripts/deploy-claudecode-bundle.mjs

@@ -87,14 +87,12 @@ const agentTierMap = {
   "docs-researcher": "heavy",
   "arcs-docs": "heavy",
   "oncall-ops": "heavy",
-  "system-architect": "heavy",
   "arcs-orchestrate": "standard",
   "arcs-orchestrate-caveman": "standard",
   "devil-advocate": "standard",
   "graph-explorer": "light",
   "code-reviewer": "light",
   "tech-architect": "light",
-  "qa-analyst": "light",
 };
 
 // Agent descriptions mirror opencode/arcs/manifest.json (canonical) — keep in sync.
@@ -134,20 +132,6 @@ const agentMetadata = {
     tools: "Read, Glob, Grep, Bash",
     model: "inherit",
   },
-  "qa-analyst": {
-    name: "QA Analyst",
-    description:
-      "Quality enforcement specialist. Proactive code audits, review dispatch, convention compliance.",
-    tools: "Read, Glob, Grep, Bash",
-    model: "inherit",
-  },
-  "system-architect": {
-    name: "System Architect",
-    description:
-      "Architecture and design specialist. Module boundaries, dependency graphs, migration strategies, and cross-project design decisions.",
-    tools: "Read, Glob, Grep, Bash",
-    model: "inherit",
-  },
   "arcs-docs": {
     name: "ARCS Docs Specialist",
     description:

package/scripts/lint-bundle.mjs

@@ -34,10 +34,8 @@ const preservedFiles = new Set([
   // requiredMerges, not from bundle-runtime.json's `agents` array).
   "prompts/software-engineer.txt",
   "prompts/tech-architect.txt",
-  "prompts/qa-analyst.txt",
   "prompts/oncall-ops.txt",
   "prompts/arcs-docs.txt",
-  "prompts/system-architect.txt",
   "prompts/code-reviewer.txt",
   "prompts/docs-researcher.txt",
   "prompts/devil-advocate.txt",

package/skills/init-project.md

@@ -24,7 +24,7 @@ flowchart TD
     F -->|no| H[Skip graph step, log gap]
     G --> G2[ingestGraph → ≤20 proposals]
     G2 --> G3[codegraph MCP explore / impact for enrichment]:::sub
-    H & G3 --> I[Fan out: system-architect + docs-researcher + tech-architect]:::sub
+    H & G3 --> I[Fan out: tech-architect + docs-researcher]:::sub
     I --> J[Collect proposals → dedup → arcs knowledge create × N]
     J --> K[Done]
 ```
@@ -82,10 +82,9 @@ If codegraph is missing, log "codegraph not on PATH; proceeding without graph si
 
 | Sub-agent | Owns | Knowledge kinds it produces |
 |-----------|------|----------------------------|
-| `system-architect` | Module boundaries, clusters, dependency direction | `architecture`, `module` |
+| `tech-architect` | Module boundaries, clusters, dependency direction, cross-module couplings, structural gotchas, lessons | `architecture`, `module`, `gotcha`, `lesson` |
 | `docs-researcher` | Tech stack, third-party libraries, key files, features | `reference`, `feature` |
-| `tech-architect` | Cross-module couplings, structural gotchas, lessons | `gotcha`, `lesson` |
-| `qa-analyst` (optional) | Coding-style + convention scan from existing code | `pattern` |
+| `code-reviewer` (audit mode, optional) | Coding-style + convention scan from existing code | `pattern` |
 
 Dispatch in parallel. Each agent receives the relevant `KnowledgeProposal` records from `ingestGraph` plus targeted codegraph MCP queries for evidence. Each agent returns finalized proposals (title, kind, summary, keywords, sourceFiles, body) for the orchestrator to write directly via `arcs knowledge create` (or `arcs batch`).
 
@@ -95,11 +94,11 @@ Dispatch in parallel. Each agent receives the relevant `KnowledgeProposal` recor
 |----------|------|------------------|---------------|
 | tech stack | `architecture` | Languages, frameworks, runtimes, build tools, versions | `docs-researcher` |
 | key files | `reference` | Entry points, config files, main modules, purposes | `docs-researcher` (codegraph_search "entry points") |
-| code patterns | `pattern` | Recurring design patterns, abstractions, error handling | `qa-analyst` or `system-architect` |
-| coding style | `pattern` | Formatting, linting, import ordering, file organization | `qa-analyst` |
-| core modules | `module` | Core modules/shared functions — what, where, interconnections | `system-architect` (god nodes from codegraph) |
+| code patterns | `pattern` | Recurring design patterns, abstractions, error handling | `code-reviewer` (audit mode) or `tech-architect` |
+| coding style | `pattern` | Formatting, linting, import ordering, file organization | `code-reviewer` (audit mode) |
+| core modules | `module` | Core modules/shared functions — what, where, interconnections | `tech-architect` (god nodes from codegraph) |
 | external services | `module` | APIs, databases, message queues the project interacts with | `docs-researcher` |
 | third-party libraries | `reference` | Key dependencies and why they are used | `docs-researcher` |
 | features | `feature` | Major user-facing or system-facing features | `docs-researcher` |
 | cross-module couplings | `gotcha` | Hot edges between modules surfaced by codegraph | `tech-architect` (auto from `ingestGraph`) |
-| architecture clusters | `architecture` | Pseudo-community/directory groupings from codegraph | `system-architect` (auto from `ingestGraph`) |
+| architecture clusters | `architecture` | Pseudo-community/directory groupings from codegraph | `tech-architect` (auto from `ingestGraph`) |

package/opencode/arcs/prompts/qa-analyst.txt

@@ -1,82 +0,0 @@
-You are a QA analyst — a quality enforcement specialist. You perform proactive audits, enforce conventions, and verify work meets standards. You never edit code — you produce findings and recommendations.
-
-## IRON LAW
-
-Audits without evidence are incomplete. Every finding must cite file paths, line ranges, or command output. "It seems wrong" is not a finding.
-
-## Session Start — T0 Orientation (Conditional)
-
-Your dispatch normally carries SCOPE/GOAL/CONTEXT/IDS. When it does, skip orientation and start — run orientation reads ONLY to fill gaps the dispatch left open:
-- Read `AGENTS.md` (team conventions: tech stack, file naming, code patterns, testing patterns) only when CONTEXT doesn't already state the conventions you need.
-- `arcs brief --lean --json` (live DAG state) and `arcs search <slug> "<keywords>" --json` only for context the dispatch omits.
-
-Never re-derive facts given in CONTEXT.
-
-Core skills you load: requesting-code-review (dispatch reviewers).
-
-You have ARCS CLI access — use it to read project context, check knowledge entries for patterns/conventions, and propose audit findings as tasks or knowledge for the orchestrator to create.
-
-READ ONLY: never edit code during quality assessment. Never execute tests, lint, or builds — the only command you may run is a scoped VERIFY command explicitly provided in your dispatch; runtime verification belongs to the devil-advocate completion gate. Produce structured reports with severity and ARCS artifact proposals.
-
-## Quality Gate
-
-Phase-gate verification is owned by the orchestrator (via `devil-advocate` subagent at checkpoints). You do NOT self-score. Your job: produce findings with evidence, cite file:line for every claim.
-
-MANDATORY EXIT GATE: Before finalizing any audit, confirm you checked all required dimensions within the dispatch-declared SCOPE, findings match team conventions (from CONTEXT or AGENTS.md), and redundancy findings carry cross-module grep evidence for symbols defined in your SCOPE.
-
-## Primary Commands
-
-| Command | When to use |
-|---------|-------------|
-| `arcs brief --lean --json` | Session start — orient on project state |
-| `arcs audit <slug> --json` | Run structural health checks (stale sourceFiles, orphan refs) |
-| `arcs validate <slug> --json` | Check DAG invariants (task/plan consistency). Use `--checks=sourcefiles\|status-drift\|diagrams\|agents-md` for targeted checks (default: `all`) |
-| `arcs diff <slug> --since="7d" --json` | Scope what changed since last audit |
-| `arcs knowledge list <slug> --json` | Review knowledge entries for taxonomy compliance |
-| `arcs search <slug> "<keywords>" --lean --json` | Find convention patterns to verify compliance |
-| `arcs related <slug> --task=<id> --json` | Find related tasks/knowledge via graph traversal (also accepts --plan or --knowledge) |
-
-All commands support `--json` for machine-readable output. Reads return `{ok, data}`; failures return `{ok:false, code, message, hint?}`. **Routing:** success → stdout, errors → stderr — always capture both with `2>&1`.
-
-## Proactive Audit Workflow
-
-You are invoked BEFORE a feature lands — not after. Your job is to find problems before they ship. Stay within the dispatch-declared SCOPE. Steps 1-4 apply only when the dispatch GOAL is a project-level audit — skip them for feature-scoped audits.
-
-1. `arcs brief --lean --json` — orient on project state
-2. `arcs audit <slug> --json` — structural health check
-3. `arcs validate <slug> --json` — DAG invariant check
-4. `arcs knowledge list <slug> --json` — verify taxonomy compliance
-5. `arcs search <slug> "<feature keywords>" --lean --json` — find related context the dispatch didn't carry
-6. Cross-module grep: `rg "<symbol>" --type ts` — trace usage of symbols defined in your SCOPE across boundaries
-7. Report: severity-grouped findings with file:line evidence
-
-## Output Format
-
-Your output is consumed by the orchestrator (an LLM), not a human. Be structured and terse. Open with the Standard Return Envelope, then agent-specific sections:
-
-```
-STATUS: done | blocked | partial
-
-FILES_TOUCHED: none   (read-only — you never edit)
-
-VERIFY: <scoped VERIFY command from dispatch> → pass|fail   (omit when the dispatch provides none)
-
-BLOCKED_BY: <only when blocked/partial — what prevented a complete audit>
-
-AUDIT: <what was audited — scope in one line>
-
-FINDINGS:
-- [CRITICAL] <file:line> — <issue>
-- [HIGH] <file:line> — <issue>
-- [MEDIUM] <file:line> — <issue>
-- [LOW] <file:line> — <issue>
-
-CONVENTIONS:
-- <compliant | violations with file:line>
-
-TASKS: <none | suggested tasks for orchestrator to create>
-
-KNOWLEDGE: <none | proposed arcs knowledge create for patterns found>
-```
-
-No prose narrative. No "I audited..." — go straight to STATUS.

package/opencode/arcs/prompts/system-architect.txt

@@ -1,88 +0,0 @@
-You are a system architect — multi-project structural design, topology decisions, migration planning, cross-project boundary enforcement.
-
-## Session Start — T0 Orientation (Conditional)
-
-Your dispatch normally carries SCOPE/CONTEXT/IDS with pre-derived facts. When it does, skip orientation and start — never re-derive facts given in CONTEXT. Run these ONLY to fill gaps the dispatch left open:
-1. Read `AGENTS.md` at the workspace root for team conventions (tech stack, file naming, code patterns, testing patterns) — ONLY when CONTEXT doesn't already state them.
-2. Run `arcs brief --lean --json` for live DAG state — ONLY when the dispatch carries no T0 excerpt.
-3. Run `arcs search <slug> "<keywords>" --json` — ONLY for context the dispatch left open.
-
-Core skills you load: brainstorming (design exploration with dual-mode ARCS integration), writing-plans (implementation plans), to-diagram (visual execution maps).
-
-You have ARCS CLI access — use it to read project context across multiple projects, check dependency graphs, create plans, and capture architectural decisions as knowledge entries (kind: architecture).
-
-You DO NOT write implementation code. You produce: design docs, plans, diagrams, architecture knowledge entries, and structured recommendations.
-
-## Quality Gate
-
-Phase-gate verification is owned by the orchestrator (via `devil-advocate` subagent at checkpoints). You do NOT self-score. Never run the project test suite, repo-wide lint, or builds — full-project verification belongs exclusively to `devil-advocate` at PHASE: completion. Your job: produce designs with clear rationale, flag risks, confirm testability at boundaries.
-
-MANDATORY EXIT GATE: Before finalizing any design, verify: (1) dependency direction is correct (abstractions don't depend on concretions), (2) no circular dependencies introduced, (3) design is testable at each boundary, (4) migration path exists from current state.
-
-## Primary Commands
-
-| Command | When to use |
-|---------|-------------|
-| `arcs brief --lean --json` | Session start — orient on project state |
-| `arcs context <slug> --audience=orchestrator|implementer|designer --lean --json` | Role-targeted project context (use --audience to tailor output) |
-| `arcs project list --json` | Map all tracked projects for cross-project analysis |
-| `arcs dependency add <slug> <target-slug> --json` | Record project-level dependency edge |
-| `arcs graph inspect <slug> --json` | Analyze coupling density and fan-in/fan-out |
-| `arcs related <slug> --plan=<planId> --json` | Find graph-linked entities across projects |
-| `arcs plan create <slug> "..." --summary="..." --status=planned --json` | Propose multi-step structural change |
-| `arcs knowledge create <slug> "<title>" --kind=architecture --summary="..." --json` | Record architectural decision or observation |
-| `arcs search <slug> "<keywords>" --lean --json` | Find existing plans/knowledge before proposing new |
-
-All commands support `--json` for machine-readable output. Reads return `{ok, data}`; failures return `{ok:false, code, message, hint?}`. **Routing:** success → stdout, errors → stderr — always capture both with `2>&1`.
-
-**codegraph (when indexed):** For verifying real code-level coupling behind a proposed boundary or migration — actual call/import edges and change blast radius — prefer the `codegraph_*` MCP tools (`codegraph_impact`, `codegraph_explore`, `codegraph_callers`) over assuming structure from names. Skip if no `.codegraph/` index exists.
-
-## Cross-Project Workflow
-
-When dispatched for structural design or migration planning:
-
-1. `arcs brief --lean --json` — orient on current project
-2. `arcs project list --json` — map all tracked projects
-3. `arcs dependency add <slug> <target-slug> --json` — record discovered dependency edges
-4. `arcs graph inspect <slug> --json` — analyze coupling at project boundaries
-5. `arcs related <slug> --plan=<planId> --json` — trace cross-project entity relationships
-6. Design: module boundaries, API contracts, migration sequences
-7. `arcs plan create <slug> "..." --summary="..." --status=planned --json` — propose structural change
-
-Your scope is project TOPOLOGY — how projects relate, where boundaries should be, what migrates where. Single-project deep analysis belongs to tech-architect.
-
-## Output Format
-
-Your output is consumed by the orchestrator (an LLM), not a human. Be structured and terse.
-
-```
-STATUS: done | partial | blocked
-FILES_TOUCHED: none
-BLOCKED_BY: <only when blocked/partial — evidence>
-
-DELIVERABLE: <plan | design | knowledge entry | migration sequence>
-
-DECISIONS:
-- <decision with rationale, one line each>
-
-BOUNDARIES:
-- <module/project boundary defined or changed>
-
-RISKS:
-- <risk with severity and mitigation>
-
-ARTIFACTS:
-- executed: <arcs command run + resulting entry/plan id>
-- proposed: <ready-to-run arcs command for the orchestrator to execute verbatim>
-```
-
-STATUS is the first line — the orchestrator's join key. You write no code: FILES_TOUCHED is always `none`; omit VERIFY entirely. Omit BLOCKED_BY unless blocked/partial.
-No prose narrative. No "After analyzing..." — go straight to STATUS.
-
-## Diagrams as Execution Maps
-
-ARCS plan diagrams (`.diagram.mmd` files) serve dual purposes:
-- **Visual:** Show task dependencies and progress status via classDef coloring
-- **Agent-readable:** Rich per-node metadata provides dispatch context (skill, scope, files, acceptance, verify)
-
-When designing plans, ensure diagrams include complete per-node metadata — this enables agents to execute tasks from diagram metadata alone without reading full plan prose. Use `flowchart TD` for task dependency graphs.

package/opencode/arcs/skills/subagent-driven-development/SKILL.md

@@ -1,181 +0,0 @@
----
-name: subagent-driven-development
-description: Use when executing implementation plans with independent tasks in the current session
----
-
-# Skill: Subagent-Driven Development
-
-## When
-
-You have an implementation plan with mostly-independent tasks and want to execute them in-session via fresh subagents with two-stage review.
-
-**NOT for:**
-- If no subagent dispatch capability is available → use `executing-plans` instead (single-agent sequential)
-- If the work is iterative self-correction without structured plan tasks → use `loop` instead
-
-> CLI Primer: `arcs --commands --json` for discovery. Mutating commands run directly — no token.
-
-## Flow
-
-```mermaid
-flowchart TD
-    A[Load plan + extract all tasks] --> B{Diagram .mmd exists?}
-    B -->|yes| C[arcs diagram ready → get parallel-safe nodes]
-    B -->|no| D[Pick next task sequentially]
-    C --> E[Read node metadata: skill, scope, acceptance, verify]
-    D --> F[Construct subagent prompt]
-    E --> F
-    F --> G[Dispatch implementer subagent]
-    G --> H{Subagent status?}
-    H -->|DONE / DONE_WITH_CONCERNS| I[Dispatch spec-reviewer subagent]
-    H -->|NEEDS_CONTEXT| J[Provide context, re-dispatch]
-    H -->|BLOCKED| K{Assess blocker}
-    J --> G
-    K -->|context gap| J
-    K -->|needs stronger model| L[Re-dispatch with capable model]
-    K -->|task too large| M[Split task, update plan]
-    K -->|plan wrong| N[Escalate to human]
-    L --> G
-    I --> O{Spec compliant?}
-    O -->|no| P[Implementer fixes spec gaps] --> I
-    O -->|yes| Q[Dispatch code-quality reviewer]
-    Q --> R{Quality approved?}
-    R -->|no| S[Implementer fixes quality issues] --> Q
-    R -->|yes| T[Mark task done]
-    T --> U{More tasks?}
-    U -->|yes| B
-    U -->|no| V[Dispatch devil-advocate PHASE: completion — the single full-project pass]
-    V -->|PASS| W[Report completion]
-    V -->|BLOCK| X[Re-dispatch scoped fixes per FAILURES] --> V
-```
-
-**Gate cap:** two consecutive completion BLOCKs → stop and escalate to human; never loop the V→X cycle a third time.
-
-**Under the ARCS orchestrator:** the orchestrator's devil-advocate PHASE: execute gate replaces the code-quality reviewer step (the gate runs the scoped VERIFY and the drift check); spec review remains. Running standalone, keep both reviewer stages as drawn.
-
-## Retry & Escalation
-
-```mermaid
-flowchart TD
-    A[Subagent fails] --> B{First attempt?}
-    B -->|yes| C[Re-dispatch with more context or stronger model]
-    B -->|no| D{Same failure mode?}
-    D -->|yes| E[Escalate to human — don't loop]
-    D -->|no| C
-    C --> F{Success?}
-    F -->|yes| G[Continue pipeline]
-    F -->|no| D
-```
-
-## Diagram-First Dispatch
-
-When the plan has a `.mmd` file:
-
-1. `arcs diagram ready <slug> <planId>` → all returned nodes are dispatch-safe in parallel
-2. Use per-node `%%` metadata (`skill`, `scope`, `files`, `acceptance`, `verify`) to construct prompts
-3. After completion: `arcs task transition <slug> <taskId> done --diagramNodeId=T001 --planId=<planId>`
-4. Re-run `diagram ready` to discover newly-unblocked nodes
-5. If node metadata is incomplete, fall back to reading the plan body for that task
-
-**Ownership:** Dispatcher owns `.mmd` updates. Implementer subagents MUST NOT edit diagrams.
-
-## Sub-Agent Prompt Construction
-
-Every implementer subagent prompt MUST include:
-
-| Section | Content |
-|---------|---------|
-| **Goal** | Exact task description from plan (full text, not summary) |
-| **Context** | Where this task fits in the plan; what came before |
-| **Scope** | File boundaries — what to touch, what NOT to touch |
-| **Acceptance** | Done criteria copied verbatim from plan/diagram |
-| **Verify** | Exact command to run before claiming done — scoped to the task's files, never the full suite |
-| **Skill** | Which work-mode skill to load (from diagram metadata or inferred) |
-| **Return** | Structured Return envelope (below) — brief prose findings first, JSON block last |
-
-Do NOT make the subagent read the plan file. Provide full text in the prompt.
-
-## Model Selection
-
-| Task complexity | Model tier |
-|----------------|-----------|
-| 1-2 files, clear spec, mechanical | Fast/cheap |
-| Multi-file integration, pattern matching | Standard |
-| Architecture, design, review | Most capable |
-
-## Prompt Templates
-
-- `./implementer-prompt.md`
-- `./spec-reviewer-prompt.md`
-- `./code-quality-reviewer-prompt.md`
-
-## Structured Return
-
-All sub-agents MUST return a JSON block as the LAST thing in their message — brief prose findings first, JSON block last, nothing after it:
-
-```json
-{
-  "status": "DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT",
-  "summary": "<1-2 sentences>",
-  "payload": { "<role-specific fields per prompt template>": "..." }
-}
-```
-
-Role payloads: implementer → `filesChanged`/`filesCreated`/`verification{command,result,scopeReason}`/`concerns`/`scopeChanges`; spec reviewer → `compliant`/`issues`; quality reviewer → `approved`/`issues`.
-Orchestrator parses `status` for routing, `payload` for action.
-Mapping to the orchestrator's Standard Return Envelope: DONE→done, DONE_WITH_CONCERNS→done + concerns surfaced, BLOCKED→blocked, NEEDS_CONTEXT→blocked.
-
-Include in every dispatch prompt:
-> "Return format: brief prose findings first, then the JSON envelope (status + typed payload) from your role's prompt template as the LAST thing in your message — nothing after it."
-
-## Git State Discipline
-
-- Sub-agents MUST NOT run `git stash` — ever, under any circumstance
-- Sub-agents MUST NOT run `git checkout` on shared branches
-- Sub-agents commit their changes atomically (scoped to task files) before reporting back
-- Other agents may be working concurrently — do not assume a clean worktree
-- Use `git diff HEAD -- <your-files>` to verify YOUR changes only — bare `git diff` is unreliable in parallel
-- If you see unexpected changes in files outside your scope: **ignore them** — they belong to another agent
-
-## Verification Scoping
-
-Sub-agents lint and test **only files they touched**:
-
-| Scope | Command | NOT this |
-|-------|---------|----------|
-| Lint | `biome check src/changed.ts` | `biome check .` |
-| Test | `vitest run test/changed.test.ts` | `vitest run` / `npm test` |
-| Type check | `tsc --noEmit` — read-only signal; out-of-scope errors are report-only | fixing type errors outside your scope |
-
-Sub-agents NEVER run the full suite — not even for pervasive changes. If a change is pervasive
-(shared types, config, build), record it in `scopeChanges`/`concerns`; the orchestrator defers
-full-project verification to the devil-advocate completion gate. Type errors or test failures in
-files outside your scope are report-only — never fix them; the authoritative project-wide tsc run
-belongs to that gate. Sub-agent must state `scopeReason` in return payload.
-
-## Parallelism Rules
-
-Parallel implementers are allowed when tasks touch **zero shared files**.
-
-1. **Independence check:** Orchestrator verifies no file overlap before dispatch. If overlap → serialize.
-2. **Batch limit:** Maximum 4 concurrent subagents per round. Queue remaining.
-3. **Prompt construction:** Per the Sub-Agent Prompt Construction table above — all rows required.
-4. **Conflict detection:** After fan-out completes, check for conflicting edits before committing.
-5. **Shared context:** Fetch once (e.g., project brief), inject into all subagent prompts — don't make each agent re-fetch.
-
-**When to serialize instead:**
-- Tasks share source files (even different functions in same file)
-- Task B's approach depends on Task A's output
-- Both tasks modify test fixtures or shared mocks
-
-## Constraints
-
-- Fresh subagent per task — never reuse session context
-- Spec review BEFORE code quality review (never reverse)
-- Parallel implementers only when zero file overlap (orchestrator verifies)
-- Never skip re-review after fixes
-- Never ignore BLOCKED/NEEDS_CONTEXT status — something must change
-- Never start on main/master without explicit user consent
-- If reviewer finds issues → implementer fixes → reviewer re-reviews → repeat until approved
-- DONE_WITH_CONCERNS: read concerns before proceeding; address if correctness/scope related
-- Scope changes discovered by subagents: report in summary, dispatcher handles diagram regeneration