@titan-design/brain 0.6.1 → 0.7.0

package/dist/{command-resolution-MO7LSFOT.js → command-resolution-EJ6LTC2Z.js}

@@ -92,7 +92,7 @@ async function resolveUnknownCommand(input, db, embedder, fusionWeights) {
   }
   if (db && embedder) {
     try {
-      const { search } = await import("./search-AKSAQJOR.js");
+      const { search } = await import("./search-NPTRJV4W.js");
       const results = await search(
         db,
         embedder,

package/dist/{search-AKSAQJOR.js → search-NPTRJV4W.js}

@@ -3,8 +3,8 @@ import {
   computeFacets,
   search,
   searchMemories
-} from "./chunk-KSJZ7CMP.js";
-import "./chunk-AJKFX2TM.js";
+} from "./chunk-4GDSQB2E.js";
+import "./chunk-LLAHWRO4.js";
 import "./chunk-PO3GJPIC.js";
 export {
   checkAndPromote,

package/dist/templates/brainstorm-design.md

@@ -0,0 +1,30 @@
+# Brainstorm: Present Design
+
+Assisted-mode phase. Present the design section by section, getting approval after each.
+
+---
+
+## Context
+
+- Topic: `{{TASK_DESCRIPTION}}`
+- Project: `{{PROJECT_PREFIX}}`
+- Chosen approach: (from propose phase)
+
+## Instructions
+
+Present the design incrementally. Cover these sections, scaled to complexity:
+
+1. **Architecture** — Components, layers, data flow
+2. **API / Interface** — Public contracts, types, signatures
+3. **Data model** — State shape, storage, migrations
+4. **Error handling** — Failure modes, recovery, user feedback
+5. **Testing strategy** — What to test, how, coverage targets
+
+After each section, ask: "Does this look right so far?"
+
+If the user has concerns, revise before moving on. If something needs clarification, the workflow can loop back to interview.
+
+## Completion
+
+This phase is complete when all sections are approved.
+Advance to write-doc.

package/dist/templates/brainstorm-explore.md

@@ -0,0 +1,30 @@
+# Brainstorm: Explore Context
+
+Explore-type agent gathering project context before a brainstorming session.
+
+---
+
+## Setup
+
+- Topic: `{{TASK_DESCRIPTION}}`
+- Project: `{{PROJECT_PREFIX}}`
+- Location: `{{REPO_PATH}}`
+
+## Instructions
+
+Survey the codebase to understand:
+
+1. **Current state** — What exists today? Recent commits, active branches, open PRs.
+2. **Related code** — Files, modules, and patterns relevant to "{{TASK_DESCRIPTION}}".
+3. **Constraints** — Existing architecture decisions, dependencies, or conventions that apply.
+4. **Prior art** — Has something similar been attempted? Check docs, plans, design notes.
+
+## Output
+
+Write a structured context brief covering:
+- Key files and their roles
+- Architectural patterns in use
+- Potential constraints or risks
+- Open questions for the interview phase
+
+Keep it under 200 lines. Facts only — no design recommendations yet.

package/dist/templates/brainstorm-interview.md

@@ -0,0 +1,26 @@
+# Brainstorm: Interview
+
+Assisted-mode phase. The orchestrator asks the user clarifying questions one at a time.
+
+---
+
+## Context
+
+- Topic: `{{TASK_DESCRIPTION}}`
+- Project: `{{PROJECT_PREFIX}}`
+
+## Interview Guidelines
+
+Ask questions **one at a time**. Prefer multiple choice when possible.
+
+Focus areas:
+1. **Purpose** — What problem does this solve? Who benefits?
+2. **Scope** — What's in v1 vs future? What explicitly isn't included?
+3. **Constraints** — Performance, compatibility, timeline, dependencies?
+4. **Success criteria** — How do we know it's done? What does "working" look like?
+5. **Prior context** — Has the user researched this? Are there examples to follow?
+
+## Completion
+
+This phase is complete when the orchestrator has enough context to propose 2-3 approaches.
+Mark the task done and advance the workflow.

package/dist/templates/brainstorm-propose.md

@@ -0,0 +1,28 @@
+# Brainstorm: Propose Approaches
+
+Assisted-mode phase. Present 2-3 approaches with trade-offs and a recommendation.
+
+---
+
+## Context
+
+- Topic: `{{TASK_DESCRIPTION}}`
+- Project: `{{PROJECT_PREFIX}}`
+
+## Instructions
+
+Based on the interview findings, propose 2-3 approaches:
+
+For each approach:
+1. **Name** — Short label
+2. **Summary** — 2-3 sentences
+3. **Pros** — What it does well
+4. **Cons** — What it does poorly or risks
+5. **Effort** — Relative complexity (low/medium/high)
+
+Lead with your **recommended** approach and explain why.
+
+## Completion
+
+This phase is complete when the user selects an approach.
+Record the chosen approach and advance the workflow.

package/dist/templates/brainstorm-write-doc.md

@@ -0,0 +1,30 @@
+# Brainstorm: Write Design Doc
+
+Agent-mode phase. Write the validated design to a markdown file and commit.
+
+---
+
+## Context
+
+- Topic: `{{TASK_DESCRIPTION}}`
+- Project: `{{PROJECT_PREFIX}}`
+- Location: `{{REPO_PATH}}`
+
+## Instructions
+
+Write the approved design to `docs/plans/{{PLAN_ID}}-design.md` in the target repo.
+
+Structure:
+- Title and one-line goal
+- Architecture overview
+- Component breakdown
+- Data model
+- Error handling
+- Testing strategy
+- Open questions (if any remain)
+
+Commit with message: "Add design doc: {{TASK_DESCRIPTION}}"
+
+## Output
+
+The design document path, ready for the writing-plans phase.

package/dist/templates/implementation-compact.md

@@ -0,0 +1,46 @@
+# Implementation Task: {{TASK_ID}}
+
+## Setup
+
+- Location: `{{REPO_PATH}}`
+- Branch: `{{BRANCH_NAME}}` (base: `{{BASE_BRANCH}}`)
+- Build: `{{BUILD_CMD}}` | Test: `{{TEST_CMD}}` | Typecheck: `{{TYPECHECK_CMD}}` | Lint: `{{LINT_CMD}}`
+- Worktree: `{{WORKTREE_PATH}}` (omit if not isolated)
+- Brain PM task: `{{BRAIN_TASK_ID}}` / claim token: `{{CLAIM_TOKEN}}`
+
+## Ownership Scope
+
+Only modify files matching: `{{OWNERSHIP_PATTERNS}}`
+
+## Context
+
+{{CONTEXT_FILES}}
+
+{{PREREQUISITES}}
+
+## What to Implement
+
+{{IMPLEMENTATION_INSTRUCTIONS}}
+
+Constraints: {{DESIGN_CONSTRAINTS}}
+
+## Tests
+
+{{TEST_INSTRUCTIONS}}
+
+## Verify and Complete
+
+Run in order — all must pass:
+
+1. `{{TYPECHECK_CMD}}` — no type errors
+2. `{{TEST_CMD}}` — all tests pass
+3. `{{LINT_CMD}}` — no lint errors
+4. `npx prettier --check .` — no formatting issues (fix with `npx prettier --write .` if needed)
+5. `{{BUILD_CMD}}` — builds successfully
+6. {{MANUAL_VERIFICATION_STEPS}}
+
+If verification fails, fix and retry twice before exiting with diagnostics.
+
+When all pass, commit referencing `{{TASK_ID}}` (imperative mood, <72 chars) and push to `origin/{{BRANCH_NAME}}`. Report: summary of changes, files modified, test count delta, issues encountered.
+
+Stay within ownership scope, run all verification steps, no dead code, no skipping on failure.

package/dist/templates/implementation.md

@@ -0,0 +1,92 @@
+# Implementation Task: {{TASK_ID}}
+
+## Repo Setup
+
+- Location: `{{REPO_PATH}}`
+- Branch: `{{BRANCH_NAME}}` (base: `{{BASE_BRANCH}}`)
+- Build: `{{BUILD_CMD}}`
+- Test: `{{TEST_CMD}}`
+- Typecheck: `{{TYPECHECK_CMD}}`
+- Lint: `{{LINT_CMD}}`
+- Worktree: `{{WORKTREE_PATH}}` (omit if not isolated)
+- Brain PM task: `{{BRAIN_TASK_ID}}` / claim token: `{{CLAIM_TOKEN}}`
+
+## Ownership Scope
+
+You may only modify files matching these patterns:
+
+```
+{{OWNERSHIP_PATTERNS}}
+```
+
+Do NOT modify files outside this scope.
+
+## Context
+
+### Read first
+
+{{CONTEXT_FILES}}
+
+### Prerequisites
+
+{{PREREQUISITES}}
+
+### What NOT to change
+
+{{DO_NOT_CHANGE}}
+
+## What to Implement
+
+{{IMPLEMENTATION_INSTRUCTIONS}}
+
+## Design Constraints
+
+{{DESIGN_CONSTRAINTS}}
+
+## Tests
+
+{{TEST_INSTRUCTIONS}}
+
+## Verification
+
+After all changes, run each of these in order. All must pass.
+
+1. **Typecheck**: `{{TYPECHECK_CMD}}` — no type errors
+2. **Tests**: `{{TEST_CMD}}` — all tests pass
+3. **Lint**: `{{LINT_CMD}}` — no lint errors
+4. **Format**: `npx prettier --check .` — no formatting issues (fix with `npx prettier --write .`)
+5. **Build**: `{{BUILD_CMD}}` — builds successfully
+5. **Manual checks**:
+
+{{MANUAL_VERIFICATION_STEPS}}
+
+## Completion
+
+When all verification passes:
+
+1. Commit with a descriptive message referencing `{{TASK_ID}}` (imperative mood, <72 chars subject)
+2. Push to `origin/{{BRANCH_NAME}}`
+3. Report back with:
+   - Summary of what changed and why
+   - Files modified (list)
+   - Test count (before/after if tests were added)
+   - Any issues encountered or things the orchestrator should know
+
+## Retry Policy
+
+If tests, typecheck, lint, or build fail after your changes, investigate the root cause and fix it. Try at least **twice** before giving up. If after 2 fix attempts you still cannot resolve the issue, exit with a clear explanation of:
+
+1. What is failing (exact error output)
+2. What you tried to fix it
+3. Your best theory on the root cause
+
+## Anti-Patterns
+
+- Do NOT modify files outside the ownership scope listed above
+- Do NOT skip any verification step
+- Do NOT commit generated files unless explicitly told to
+- Do NOT create new files unless necessary — prefer editing existing files
+- Do NOT leave TODO comments without a tracking issue
+- Do NOT leave dead code or commented-out code
+- Do NOT suppress lint/type errors — fix the underlying issue
+- Do NOT exit on first test failure — follow the retry policy above

package/dist/templates/ops.md

@@ -0,0 +1,18 @@
+# Ops Task: {{TASK_ID}}
+
+## Setup
+- Location: {{REPO_PATH}}
+- Branch: {{BRANCH_NAME}} (or "N/A" for cleanup)
+
+## What to Do
+{{INSTRUCTIONS}}
+
+## Verify
+{{VERIFICATION_STEPS}}
+
+## Report
+- What was done
+- Current state
+- Anything needing follow-up
+
+If anything fails, try to fix it twice. If stuck, report what failed and why.

package/dist/templates/planning-critic.md

@@ -0,0 +1,123 @@
+# Planning Critic: {{TASK_ID}}
+
+## Context
+
+- Plan: {{PLAN_ID}}
+- Project: {{PROJECT_PREFIX}}
+- Location: `{{REPO_PATH}}`
+
+## Input
+
+Read these artifacts. You did NOT write them — you are reviewing them with fresh eyes.
+
+1. `.plans/{{PLAN_ID}}/spec.md` — problem specification
+2. `.plans/{{PLAN_ID}}/design.md` — technical approach
+3. `.plans/{{PLAN_ID}}/acceptance-criteria.md` — testable conditions
+4. Project CLAUDE.md at `{{REPO_PATH}}/CLAUDE.md` — project conventions
+
+Do NOT read the research brief or interview answers. Your review must be independent of the designer's reasoning process.
+
+## Your Role
+
+You are an adversarial critic. Your job is to find problems, not confirm correctness. If you find no issues, explain why that's suspicious and look harder. Early agreement is a warning sign — it usually means you haven't examined closely enough.
+
+You are NOT here to be helpful or supportive. You are here to catch mistakes, gaps, and bad decisions before they become expensive rework during implementation.
+
+## Review Process
+
+### Phase 1: Multi-Persona Review
+
+Review the design from three independent perspectives. For each, write your findings before moving to the next perspective.
+
+**Perspective 1: Correctness Reviewer**
+- Does the design satisfy EVERY acceptance criterion? Map each criterion to the design element that fulfills it.
+- Are there requirements in spec.md with no corresponding design element?
+- Are there acceptance criteria that the proposed code structure cannot satisfy?
+- Are there implicit assumptions that should be explicit?
+
+**Perspective 2: Error Handling Reviewer**
+- What happens when each external dependency fails? (network, filesystem, database, BLE)
+- What happens with invalid input at every boundary?
+- Are there race conditions in concurrent operations?
+- What happens during partial failure (some operations succeed, some fail)?
+- Are error messages actionable for debugging?
+
+**Perspective 3: API Design Reviewer**
+- Are names clear and consistent? Do they follow project conventions?
+- Is the interface minimal? Could anything be removed without losing functionality?
+- Will this be easy to change later? Where are the coupling points?
+- Does the data flow make sense? Are there unnecessary intermediaries?
+- Are types precise enough to prevent misuse?
+
+### Phase 2: Chain of Verification
+
+Generate 5-10 specific questions about the design. Then answer each question independently — do NOT refer to the design's own justifications when answering. Compare your answers to the design. Flag contradictions.
+
+Example questions:
+- "Given requirement R3, what is the minimum API surface needed?"
+- "If component A fails, what should component B do?"
+- "What happens if this function is called with an empty array?"
+
+### Phase 3: Cross-Cutting Checks
+
+- **Scaffolding completeness:** Can wave 1 (scaffolding) be built and tested independently? Does wave 2+ have everything it needs from wave 1?
+- **File ownership conflicts:** Do any two implementation tasks need to modify the same file? If so, flag as a decomposition risk.
+- **Test coverage:** Does every acceptance criterion have a clear test strategy? Are edge cases covered?
+- **Convention compliance:** Does the design follow the project's coding standards (from CLAUDE.md)?
+
+## Findings Format
+
+For EVERY finding, assign one of:
+- `[FIX]` — Must be addressed before implementation. Explain what's wrong and suggest a fix.
+- `[ACCEPTED]` — Reviewed and found correct. Brief explanation of why.
+
+There is no "suggestion" or "nice to have" category. Every aspect is either a problem or it isn't.
+
+## Output
+
+Write your findings to `.plans/{{PLAN_ID}}/critic-report.md` with this structure:
+
+```
+# Critic Report: {{TASK_ID}}
+
+## Summary
+[2-3 sentence overall assessment. Be direct — is this design ready or not?]
+
+## Verdict: <READY or NEEDS REVISION>
+
+## Findings
+
+### Correctness
+- [FIX] <finding> — <suggested fix>
+- [ACCEPTED] <aspect reviewed> — <why it's correct>
+
+### Error Handling
+- [FIX] <finding> — <suggested fix>
+- [ACCEPTED] <aspect reviewed> — <why it's adequate>
+
+### API Design
+- [FIX] <finding> — <suggested fix>
+- [ACCEPTED] <aspect reviewed> — <why it's clean>
+
+### Chain of Verification
+| Question | Independent Answer | Design Says | Match? |
+|----------|-------------------|-------------|--------|
+| Q1 | ... | ... | Yes/No |
+
+### Cross-Cutting
+- [FIX] / [ACCEPTED] <finding>
+
+## Open Questions
+[Questions the critic cannot resolve — these may trigger a human walkthrough]
+
+## FIX Summary
+Total: <N> FIX items
+1. <file/section> — <brief description>
+2. ...
+```
+
+## Important
+
+- Be thorough but focused. Target ~15-20% of the expected implementation token budget.
+- If the design is genuinely solid, say so — but explain WHY you believe that despite your adversarial mandate.
+- Open questions in your report may trigger a human walkthrough — flag anything you're uncertain about.

package/dist/templates/planning-decompose.md

@@ -0,0 +1,221 @@
+# Planning Decompose: {{TASK_ID}}
+
+Decompose an approved design into PM tasks and briefing files. Each task becomes an independently executable unit dispatched via `implementation-compact.md`.
+
+---
+
+## Context
+
+- Plan: `{{PLAN_ID}}`
+- Project: `{{PROJECT_PREFIX}}`
+- Location: `{{REPO_PATH}}`
+- Build: `{{BUILD_CMD}}` | Test: `{{TEST_CMD}}` | Typecheck: `{{TYPECHECK_CMD}}` | Lint: `{{LINT_CMD}}`
+- Brain PM task: {{BRAIN_TASK_ID}}
+
+## Input
+
+Read these approved design artifacts before proceeding:
+
+1. `.plans/{{PLAN_ID}}/design.md` -- technical approach, file list, scaffolding boundaries, PR boundary recommendation
+2. `.plans/{{PLAN_ID}}/acceptance-criteria.md` -- testable conditions mapped to tests
+3. `.plans/{{PLAN_ID}}/critic-report.md` -- critic findings and their resolutions
+
+Also read for conventions:
+- `{{REPO_PATH}}/CLAUDE.md` -- project conventions and commands
+- Any existing code referenced in `design.md` -- understand current patterns before splitting work
+
+## Decomposition Rules
+
+Apply all five rules. If any rule is violated, restructure until it holds.
+
+1. **One logical unit per task** -- a task produces one coherent change: a component, a store, a utility, a hook, or a test suite. Not "half a component."
+2. **Exclusive file ownership** -- no two tasks modify the same file. If a file needs changes from multiple tasks, assign it to one task and make others depend on it.
+3. **Independently verifiable** -- each task's success criteria can be checked without other incomplete tasks. Tests may import from scaffolding (wave 1) but not from peer tasks in the same wave.
+4. **50-line briefing limit** -- if a briefing exceeds 50 lines of meaningful content (excluding code blocks), the task is too large. Split it.
+5. **TDD step structure** -- every task follows: write test, verify fail, implement, verify pass, commit.
+
+## Wave Structure
+
+Group tasks into waves based on `design.md` scaffolding boundaries:
+
+### Wave 1: Scaffolding
+
+Types, interfaces, shared utilities, store structure, configuration. These are the foundations other tasks depend on.
+
+- **Gate:** `{{TYPECHECK_CMD}}` passes. Any scaffolding tests pass.
+- **Dependency:** None -- wave 1 tasks run in parallel.
+
+### Wave 2+: Implementation
+
+Features built on top of scaffolding. Tasks within a wave run in parallel.
+
+- **Gate:** `{{TEST_CMD}}` passes. `{{LINT_CMD}}` clean. `{{TYPECHECK_CMD}}` passes.
+- **Dependency:** All wave 1 tasks must be complete before wave 2 starts. Within a wave, tasks are independent.
+
+### Final Wave: Integration
+
+Cross-cutting tests, cleanup, integration validation. Only if the design calls for it.
+
+- **Gate:** Full verification pipeline -- `{{TYPECHECK_CMD}}`, `{{TEST_CMD}}`, `{{LINT_CMD}}`, `npx prettier --check .`, `{{BUILD_CMD}}`.
+- **Dependency:** All prior waves complete.
+
+## Creating PM Tasks
+
+For each task, create a brain PM entry:
+
+```bash
+brain pm task add "<task name>" \
+  --workstream <appropriate workstream> \
+  --project {{PROJECT_PREFIX}} \
+  --category implementation \
+  --priority medium \
+  --description "Briefing: .plans/{{PLAN_ID}}/briefings/task-NN.md"
+```
+
+Set dependencies to enforce wave ordering:
+
+```bash
+brain pm task update <TASK-ID> --depends-on <DEPENDENCY-ID>
+```
+
+- Wave 1 tasks: no dependencies.
+- Wave 2+ tasks: depend on all wave 1 tasks.
+- Final wave tasks: depend on all prior wave tasks.
+
+Record each PM task ID -- you will need them for the output summary.
+
+## Creating Briefing Files
+
+For each task, create `.plans/{{PLAN_ID}}/briefings/task-NN.md` using this format:
+
+```markdown
+# Task NN: <Component Name>
+
+## Architectural Context
+
+[2-3 sentences: where this fits, what it depends on, why it exists. Reference specific files.]
+
+## File Ownership
+
+**May modify:**
+- `exact/path/to/file.ts`
+- `exact/path/to/file.test.ts`
+
+**Must not touch:**
+- `exact/path/to/adjacent.ts`
+
+**Read for context (do not modify):**
+- `exact/path/to/dependency.ts` -- [why relevant]
+
+## Steps
+
+### Step 1: Unstash spec tests (if applicable)
+Run: `git stash list` to find `spec-tests-{{PLAN_ID}}`
+Run: `git stash pop stash@{N}` (where N is the stash index)
+Move relevant test files to this task's test location if needed.
+
+### Step 2: Write the failing test
+[Exact test code or clear description of what to test]
+
+### Step 3: Run test to verify it fails
+Run: `{{TEST_CMD}} -- <test file path>`
+Expected: FAIL
+
+### Step 4: Write minimal implementation
+[Implementation guidance -- not full code, but unambiguous direction]
+
+### Step 5: Run test to verify it passes
+Run: `{{TEST_CMD}} -- <test file path>`
+Expected: PASS
+
+### Step 6: Commit
+git add <files>
+git commit -m "<imperative mood commit message>"
+
+[Repeat step groups 2-6 for additional changes within this task]
+
+## Success Criteria
+
+- [ ] Tests pass: `{{TEST_CMD}} -- <path>`
+- [ ] No lint warnings: `{{LINT_CMD}}`
+- [ ] Types check: `{{TYPECHECK_CMD}}`
+- [ ] [Feature-specific criterion from acceptance-criteria.md]
+
+## Anti-patterns
+
+- Do NOT modify files outside the ownership list
+- Do NOT modify CLAUDE.md
+- Do NOT add features beyond the steps
+- [Task-specific anti-pattern if applicable]
+```
+
+### Briefing Authoring Guidelines
+
+- **Architectural Context**: Orient the agent in 2-3 sentences. Reference concrete file paths.
+- **File Ownership**: Explicit allowlist. If a task touches 5+ files, split it.
+- **Steps**: Complete enough to be unambiguous. Include exact test expectations.
+- **Success Criteria**: Every criterion maps to a command the agent can run.
+- **Anti-patterns**: Always include the three universal ones (file ownership, CLAUDE.md, scope creep) plus task-specific ones.
+- **Parallel awareness**: If a task's tests depend on code from another wave-2 task, note that the dependency will exist at the wave gate, not during task execution.
+
+## Spec Test Distribution
+
+The spec tests from the previous phase are stashed as `spec-tests-{{PLAN_ID}}`. Distribute them:
+
+- List the stashed test files and map each to the task that will use it.
+- Wave 1 (scaffolding) tasks typically have no spec tests -- scaffolding is validated by typecheck.
+- Wave 2+ tasks unstash and use spec tests as their TDD targets.
+- If a spec test covers multiple tasks, assign it to the task with the most relevant ownership. Other tasks reference it as read-only context.
+- Include the unstash step only in the FIRST task of each wave (to avoid double-popping).
+
+## PR Boundary
+
+Read the PR boundary recommendation from `design.md`:
+
+- **Single PR:** All tasks commit to the same feature branch. Simpler, but larger review.
+- **Per-wave PR:** Each wave gets its own branch stacked on the previous. Smaller reviews, but more branch management.
+
+Document the chosen strategy in your output. The orchestrator needs this to manage branches during dispatch.
+
+## Output
+
+When decomposition is complete, report:
+
+```
+## Decomposition Summary
+
+### Tasks Created
+| # | PM Task ID | Name | Wave | Depends On | Briefing |
+|---|-----------|------|------|-----------|---------|
+| 1 | PROJ-XX.YY | Scaffold types | 1 | -- | task-01.md |
+| 2 | PROJ-XX.YY | Implement feature A | 2 | Task 1 | task-02.md |
+| ... | ... | ... | ... | ... | ... |
+
+### Wave Gates
+- Wave 1 gate: {{TYPECHECK_CMD}} passes
+- Wave 2 gate: {{TEST_CMD}} + {{LINT_CMD}} + {{TYPECHECK_CMD}} pass
+- [Final wave gate if applicable]
+
+### PR Strategy
+[Single PR / Per-wave -- from design.md recommendation, with rationale]
+
+### File Ownership Map
+| File | Owned By |
+|------|----------|
+| src/types.ts | Task 1 |
+| src/feature-a.ts | Task 2 |
+| ... | ... |
+
+### Spec Test Distribution
+| Test File | Assigned To | Unstash In |
+|-----------|------------|-----------|
+| __tests__/feature-a.test.ts | Task 2 | Task 2 (first in wave 2) |
+| ... | ... | ... |
+```
+
+Verify before reporting:
+- Every file from `design.md` appears exactly once in the ownership map
+- Every acceptance criterion maps to at least one task
+- No circular dependencies between tasks
+- Wave ordering respects scaffolding-first
+- All briefing files are under 50 lines of meaningful content