FIN Production Parity — Autonomous Execution Plan

Companion to: Plan (WHAT) + Tracker (STATUS) → this doc (HOW we run it)

0. Aggressive Schedule + Constraints

Wall-clock target: 5 days execution + 2 days buffer (5/16–5/22). Master-merge-ready by Wed 5/20 EOD. See §7 for day-by-day breakdown.

Per Rob 2026-05-16: “This needs to get done asap. So be aggressive about the scheduling.”

The 137 tasks in the tracker are now sequenced for maximum parallelism via 6-terminal × 6-8-subagent fan-out, with the P0 critical path (B-01..B-04) on Terminal A Day 1 morning, all other terminals starting independent foundation work simultaneously.

Constraints (binding)

Per Rob’s directive 2026-05-16:

Constraint	Rule
Subscription only	Use Rob’s Claude Code subscription. NO extra API consumption. NO third-party API calls that bill separately.
No new routines	Do NOT create autonomous routines at claude.ai/code/routines (those fire LLM inference on cron schedules — ongoing cost beyond subscription).
Monitor existing routines	If an existing routine is producing useful output (EIF Continuation, etc.), monitor it but don’t spawn new ones.
GH Actions = unlimited	GitHub Actions are pure CI (no LLM). Use freely for orchestration, merge gates, tracker rollups, blocker watches.
Subagent fan-out OK	Within an active Claude Code session, dispatching subagents via the Agent tool is fine — that’s subscription-billed.
Multi-session OK	Rob can run multiple Claude Code terminals in parallel, each on a different task track — all bill against subscription.
Master merge = human	Auto-merge to integration branch is fine; merge to master stays human.

1. Architecture (5 layers)

                    ┌─────────────────────────────────────────────┐
   Layer 5         │  Monitoring (gh pr list, tracker file, …)   │
   Monitoring      │  Daily standup doc (auto-generated)         │
                    └────────────────────┬────────────────────────┘
                                         │
   Layer 4         ┌────────────────────────────────────────────┐
   Multi-session  │ Rob's terminals: 2-4 Claude Code           │
   orchestration  │ instances in parallel, each on a track     │
                    └────────────────────┬────────────────────────┘
                                         │
   Layer 3         ┌────────────────────────────────────────────┐
   Subagent       │ Within each session, Agent tool fan-out    │
   parallelization│ for independent tasks (4-6 max per session)│
                    └────────────────────┬────────────────────────┘
                                         │
   Layer 2         ┌────────────────────────────────────────────┐
   Branching      │ master ← human merge only                  │
                  │   ↑                                         │
                  │ claude/parity-program-integration ← auto    │
                  │   ↑                                         │
                  │ claude/parity-task-<TASK-ID>-<name> ← work  │
                    └────────────────────┬────────────────────────┘
                                         │
   Layer 1         ┌────────────────────────────────────────────┐
   GH Actions     │ parity-parallel-merge.yml (auto-merge)     │
   (zero LLM)     │ parity-tracker-rollup.yml (cron 4h)        │
                  │ parity-blocker-watch.yml (cron daily)      │
                    └────────────────────────────────────────────┘

2. Layer 1 — GitHub Actions infrastructure

Three new workflows to author. All zero-LLM-cost. Modeled on existing patterns (comms-parallel-merge.yml, proof-card-actions.yml).

2.1 `parity-parallel-merge.yml`

Trigger: PR labeled parity-parallel-merge targeting claude/parity-program-integration Action: Wait for required CI checks → squash-merge → delete scratch branch Zero LLM cost: pure GH Actions

Modeled exactly on .github/workflows/comms-parallel-merge.yml. Replace comms-program label with parity-program, replace target branch.

2.2 `parity-tracker-rollup.yml`

Trigger: cron 0 */4 * * * (every 4h) + manual dispatch Action:

Clone fin-central-intranet vault
Parse tracker tables, count states per part
Update §1 Cumulative Counts table
Generate docs/standups/<YYYY-MM-DD>-standup.md (today/yesterday/blockers/risk/proof gap)
Commit + push if changes Zero LLM cost: pure shell + jq

2.3 `parity-blocker-watch.yml`

Trigger: cron 0 8 * * * (daily 8am ET) + manual dispatch Action:

Parse tracker §18 blockers
For any blocker open >48h, create GH issue tagging Rob with current state
For any blocker resolved, close the issue Zero LLM cost: pure GH CLI

3. Layer 2 — Branching strategy

master  (production; HUMAN merge only)
  │
  └── claude/parity-program-integration  (long-lived feature branch; auto-merged from scratch)
        │
        ├── claude/parity-task-A-01-inventory-gap-report
        ├── claude/parity-task-A-02-render-gap-commodities
        ├── claude/parity-task-B-01-migration-049-apply
        ├── claude/parity-task-B-02-migration-050-apply
        ├── claude/parity-task-B-03-worker-loop-impl
        ├── claude/parity-task-C-01-vendor-universal-renderer
        ├── claude/parity-task-C-02-vendor-overlay-renderer
        └── ... one scratch branch per task ID

Worktree usage (per git worktree add):

Each parallel subagent gets its own worktree at .git/worktrees/parity-<TASK-ID>/
No filesystem collision between concurrent subagents
Cleanup automatic when subagent exits

Naming convention: claude/parity-task-<TASK-ID>-<kebab-case-short-name>

TASK-ID matches tracker (A-01, B-03, etc.)
short-name is 2-4 words, kebab-case

PR labels: parity-program (catch-all) + parity-parallel-merge (auto-merge eligible) + parity-track-<letter> (groups by part)

4. Layer 3 — Subagent fan-out within session

When to fan out: when 2+ tasks in the active session have NO dependencies on each other.

Pattern:

# Within a single Claude Code session message:
<multiple Agent tool calls in parallel>
- Agent { description: "Render vendor universal-layer profile", subagent_type: "general-purpose", isolation: "worktree", prompt: "<self-contained brief>" }
- Agent { description: "Render vendor overlay profile", ... }
- Agent { description: "Render region profile", ... }
- Agent { description: "Render variety profile (extract from script)", ... }

Constraint: 4-6 subagents max per session before token pressure makes the orchestrator session lose effectiveness.

Each subagent prompt MUST contain:

Task ID from tracker (e.g., “C-01”)
Self-contained context (orchestrator session can’t pass conversation context to subagent)
Acceptance criteria from tracker
Required proof artifact type
Branching instruction: “Open scratch branch claude/parity-task-C-01-vendor-universal-renderer; commit there; do NOT push to master”
Tracker update instruction: “When done, update tracker row for C-01 with state=VERIFYING, proof artifact=”

Subagent return contract:

Last message includes a structured summary block:

===PARITY-TASK-RESULT===
task_id: C-01
state: VERIFYING
branch: claude/parity-task-C-01-vendor-universal-renderer
commit_sha: <hash>
proof_type: code_commit + test_output
proof_artifact: .artifacts/test-output/vendor-renderer-2026-05-16.txt
tests_passed: 12/12
next_step: orchestrator to merge PR + update tracker
===END-PARITY-TASK-RESULT===

5. Layer 4 — Multi-session orchestration (Rob runs ≥2 terminals)

Track assignment (each terminal claims a track):

Track	Tasks	Estimated wall-clock	Best for
Track Foundation	A, B (sequential P0), C, E, F	4-5 sessions	Heavy code; one terminal grinds
Track Optimization	G, H (parallel)	2 sessions	Independent of Foundation
Track Specialization-1	I, J (sequential)	3 sessions	After Foundation
Track Specialization-2	K, L, N (parallel within track)	3-4 sessions	Heavy independent work
Track Apex	M, O, P	3-4 sessions	After Specialization

4-terminal config (recommended for max parallel):

Terminal A: Foundation track (Part A → B → C → E → F)
Terminal B: Optimization track (Part G + Part H in parallel within session)
Terminal C: Specialization-1 (Part I → Part J)
Terminal D: Specialization-2 (Part K + Part N in parallel; Part L when blockers cleared)

Coordination via tracker file:

Each session at start: git pull vault, read tracker §1 + §18, claim next ready tasks
Each session at end: update tracker rows, push, open PRs
Conflict resolution: if two sessions both edit tracker, last-write-wins + reconciliation in next session (tracker is append-mostly so conflicts are rare)

Wall-clock estimate:

Single-terminal sequential: ~19 sessions × ~6h = ~114 hours wall-clock + same inference
4-terminal parallel: ~10-12 sessions × ~6h = ~60-72 hours wall-clock + same total inference

The inference budget is the same (no work disappears). The wall-clock is what compresses.

6. Layer 5 — Monitoring (zero LLM)

6.1 Per-session opening ritual

# At every Claude Code session start:
cd /tmp/fin-central-intranet-vault && git pull
# Read tracker §1 (cumulative counts) and §18 (blockers)
# Read tracker §<part> for assigned track
# Pick next task with state=NOT_STARTED and all deps in COMPLETED state

6.2 Per-session closing ritual

# Before session ends:
# 1. Update tracker rows for tasks worked
# 2. Attach proof artifacts (replace 'pending' with actual)
# 3. Update §1 cumulative counts
# 4. git add tracker + commit + push
# 5. If blocker discovered: add to §18

6.3 Continuous monitoring tools (no LLM)

# In-flight PRs:
gh pr list --label parity-program --json number,title,state,headRefName
 
# Auto-merge status:
gh run list --workflow parity-parallel-merge.yml --limit 10
 
# Branch survey:
git branch --remote | grep claude/parity-task | sort
 
# Tracker daily standup:
cat docs/standups/$(date +%Y-%m-%d)-standup.md

6.4 Existing routines to monitor (NOT spawn)

EIF Continuation routine trig_014rpk6efarCSbUrazoLe7VY — already firing on 0 */4 * * *. Per memory: “Phase 2 tenant-local surface (EIF-RM-030..034 → 008/024)“. DO NOT touch; it’s working independently and any progress it makes lands via PR.
Comms continuation routines (4 of them) — appear to be in maintenance mode based on memory note about PR #639. Don’t restart; let them run if they’re still firing.

If any existing routine is generating noise or duplicating parity-program work, disable it via claude.ai/code/routines toggle (Rob’s UI action — no LLM).

7. AGGRESSIVE Execution Sequence (5 days wall-clock target)

Per Rob’s directive 2026-05-16: “This needs to get done asap. So be aggressive about the scheduling.”

Compression rationale: 4 terminals × 6-8 subagents per session × multiple sessions per day = effective task throughput ~10x a single sequential session. 137 tasks at avg 1-1.5h each = ~170-205 task-hours total; with parallel throughput of ~50-80 task-hours per day across 4 terminals, the math says 3-5 days is achievable if dependencies don’t bottleneck.

Target: Master-integration-ready Wed 5/20. Acceptance + cleanup buffer Thu 5/21–Fri 5/22.

Sequencing principle

P0 critical path (B-01, B-02, B-03, B-04) starts Day 1 morning, single terminal grinds it
All other terminals start independent work in parallel from Day 1 morning
Subagent fan-out maximized — 6-8 per session where tasks are independent
No idle time — when a terminal blocks waiting, switch to a different ready task in another part

Day 1 (Sat 5/16) — TODAY

Goal: Critical path B-01..B-04 shipped + all independent foundation work in flight.

Terminal	Tasks	Subagents	Hours
A	B-01, B-02 (migrations 049/050 apply via Neon MCP) → B-03 (worker loop body) → B-04 (routeRenderer dispatch)	0 (orchestrator focus)	5-6
B	A-01..A-04 (stock parity gap script + render + verify + report) → start F-01	4 fan-out for A-02 commodity renders	4-5
C	F-01..F-04 (frontmatter bulk-fix + apply across both repos + mirror to vault)	6 fan-out (1 per doc cluster)	4-5
D	H-01..H-04 (memory indexes + chunk archival + embedding cache + token budget)	4 fan-out per task	4-5
E (extra)	L-01, L-02, L-03 (Teams chat + QC narrative + photo-graph importers — Q-8 confirmed data)	3 fan-out	4-5
F (extra)	O-03 (USDA AMS extension), O-07 (FDA recall ext), O-08 (CDC outbreak), O-10 (NWS regional geocoded)	4 fan-out	4-5

Day 1 task closures target: ~30-40 tasks (B-01..B-04 + A-01..A-04 + F-01..F-04 + H-01..H-04 + L-01..L-03 + 4 connectors). Roughly 25-30% of total program in 1 day.

Day 2 (Sun 5/17)

Goal: Entity renderers + projection backbone in flight; agentic hardening starts.

Terminal	Tasks	Subagents	Hours
A	B-05..B-08 (wikilink resolver + webhook wire + E2E + replay) → C-01..C-05 (5 renderers)	5 fan-out for renderers	6-7
B	E-01..E-08 (projection parity audit — many checks parallel-able)	4 fan-out for audit categories	4-5
C	F-05, F-06 (lint integration + spec amendment) → G-01..G-04 (4 MCP tools)	4 fan-out for tools	4-5
D	H-05, H-06 (auto-handoff + memory rotation) → I-01..I-06 (6 brief shapes inc schema)	6 fan-out	5-6
E (extra)	N-01 (drill-through design) → N-02..N-06 (5 explore-* refactors)	5 fan-out	4-5
F (extra)	J-01..J-03 (tool curation audit + archive + role-catalog updates)	0 (sequential audit)	4-5

Day 2 closures target: ~35-45 tasks. Cumulative ~70-85 tasks (~50-60%).

Day 3 (Mon 5/18)

Goal: Specialization layer + projection index extension.

Terminal	Tasks	Subagents	Hours
A	C-06, C-07 (bulk seeds — vendors + customers if data) → D-01..D-06 (proof + QC + photos)	2 fan-out for bulk + 3 for D	5-6
B	J-04..J-11 (8 new projections — migrations + handlers + replay + RLS)	4 fan-out per round (2 rounds)	6-7
C	I-07..I-10 (5 new brief tools + blueprint + EIF mapper + brief renderer) → K-01..K-04 (4 sales/buyer renderers)	4 fan-out for K	6-7
D	G-05..G-09 (Quartz composer + side-dock + role presets + Playwright eval + gradeboard)	3 fan-out (composer/dock independent)	5-6
E (extra)	N-07..N-11 (side-dock + cross-link + drill projection + UI + Playwright)	3 fan-out	5-6
F (extra)	O remaining unblocked connectors (USDA NASS, NOAA Marine, FDA recall consumer)	3 fan-out	4-5

Day 3 closures target: ~35-40 tasks. Cumulative ~105-125 tasks (~75-90%).

Day 4 (Tue 5/19)

Goal: Apex layer + data fusion engine + remaining specialization.

Terminal	Tasks	Subagents	Hours
A	M-01..M-07 (fusion engine 7 patterns)	6 fan-out (one per pattern, each ~1h)	6-7
B	M-08..M-11 (proof package renderer v2 + daily pulse + PDF + insight subtype)	3 fan-out	5-6
C	K-05..K-08 (tenant config + actor.memory ext + bulk seeds + tests) → blocked-on-data L tasks if Q-8 part 2 cleared	4 fan-out	4-5
D	P-01..P-09 (data discipline — SLO catalog + monitor + dashboard + cache + lineage CI + replay equiv)	5 fan-out	6-7
E (extra)	J-12 (catalog doc) + L-07, L-08 (CLI + manifest doc) + cleanup	0	3-4
F (extra)	Cleanup: any tasks left in NOT_STARTED state, fill in proof gaps	dynamic	4

Day 4 closures target: ~30-35 tasks. Cumulative ~135-160 tasks (~95-100%).

Day 5 (Wed 5/20) — FINAL INTEGRATION

Goal: Apex test + cleanup + master-merge prep.

Terminal	Tasks
A	M-12 sample W19 proof package — APEX TEST. Generate end-to-end. Verify ≥30 sections, ≥100 fact_citations, blind-readable.
B	Replay smoke test full suite (E-08); verify all 15 projections rebuild.
C	All §17 acceptance criteria walk-through; mark DONE per.
D	Tracker §1 cumulative counts updated; all proof artifacts attached; no `pending` left. Final standup.

Day 5 closures target: All 137 tasks COMPLETED. Master merge by Rob.

Buffer (Thu 5/21 + Fri 5/22)

Cleanup of any task that slipped
Apex test re-runs if M-12 needs iteration
Any blocker resolutions that came through (subscriptions, data sources)
Final F-04 vault mirror sweep

Wall-clock summary

Mode	Days	Inference (same total)
Single-terminal sequential (original)	19	~125-155h
4-terminal parallel (prior plan)	10-12	same
6-terminal aggressive (this revision)	5 + 2 buffer	same

6 terminals? Yes — Rob can run more than 4 if his Mac handles it. 6 is the practical max before token pressure becomes crippling. If 4 terminals only, drop to ~7 days wall-clock.

8. Subagent dispatch examples

Example 1: Part C parallel renderer fan-out (within one session)

Orchestrator session (in worktree heuristic-kepler-4f9104):

I'm starting Part C. Tasks C-01, C-02, C-04, C-05 are all independent — can fan out.

Single message with 4 parallel Agent tool calls:

Agent #1:
  description: "Build vendor universal-layer renderer"
  subagent_type: general-purpose
  isolation: worktree
  prompt: "Task C-01 from FIN_PRODUCTION_PARITY_TRACKER_2026-05-16.md. Build
  packages/mcp-server/src/ingestion/renderers/vendor-profile-renderer.ts modeled
  on commodity-profile-renderer.ts. Pull schema from packages/shared/src/schemas/
  contracts/doc.ts. Write 10-15 Vitest contract tests. Branch
  claude/parity-task-C-01-vendor-universal-renderer. Acceptance: tests pass
  schema validation + body composition + determinism + snapshot. Return
  ===PARITY-TASK-RESULT=== block."

Agent #2: ...same shape for C-02 vendor overlay renderer
Agent #3: ...same shape for C-04 region renderer
Agent #5: ...same shape for C-05 variety renderer extract

After all 4 return:
- Read each ===PARITY-TASK-RESULT===
- Open 4 PRs labeled parity-parallel-merge
- Update tracker rows C-01/C-02/C-04/C-05 with state=VERIFYING + commit hashes
- Commit + push tracker

Example 2: Part B (sequential, no fan-out — P0)

Orchestrator session (in worktree):

Part B is sequential P0 — must do in order:
1. B-01 migration 049 apply (5min via neon mcp)
2. B-02 migration 050 apply (5min via neon mcp)
3. B-03 worker loop body (~3h focused work — NO subagent, do inline)
4. B-04 routeRenderer dispatch (1h, inline)
5. B-05 wikilink resolver (1h, can spawn subagent here)
6. B-06 webhook wire (30min, inline)
7. B-07 E2E test (1h, inline)
8. B-08 replay command (30min, inline)

Tracker updates after each step.
Single PR at end labeled parity-parallel-merge.

9. Cost model (subscription only)

Resource	Usage	Cost
Claude Code sessions	Subscription includes ample usage; multi-terminal = same monthly cost	$0 marginal
Subagent dispatches	Counted against subscription session quota	$0 marginal
Worktree storage	Local disk	$0
GH Actions minutes	Free tier: 2,000 min/mo for private repos	Likely $0 (under tier)
GH Actions storage	Free tier: 500MB	$0
Vault repo storage	Already in use	$0
Existing routine inference	Already running (EIF, comms, masn)	Existing budget

No new external services. No new subscriptions. No new APIs.

External subscriptions for Part O (Blue Book, X API, etc.) are SEPARATE Rob-decision (BLK-08); those are Wave 2 GTM cost, not autonomous-execution cost.

10. Risk + mitigation

Risk	Mitigation
Two sessions edit tracker simultaneously → conflict	Pull-rebase pattern; tracker is append-mostly; reconcile in next session
Subagent goes off-rails / wastes inference	Tight prompt + acceptance criteria; orchestrator validates =PARITY-TASK-RESULT= before accepting
GH Actions auto-merge to integration breaks tests	Required CI check on integration branch must pass before any auto-merge fires
Master accidentally pollutes from auto-merge	parity-parallel-merge.yml hard-asserts target = `claude/parity-program-integration`, never master
Existing routines collide with parity work	Monitor PR list; if collision, pause routine via claude.ai/code/routines toggle
Token budget pressure in multi-task sessions	4-6 subagent max per session; if approaching 25% context, write handoff per CLAUDE.md rule
Rob runs out of patience with 4 terminals	Fall back to 2 terminals (Foundation + Optimization tracks); still ~14 days vs 19

11. Success criteria

Tracker §1 cumulative counts: 137/137 tasks reach COMPLETED state
Every COMPLETED task has proof artifact attached (no “pending” entries)
All §18 blockers resolved or explicitly DEFERRED
claude/parity-program-integration branch has all auto-merged commits, ready for human master-merge
Sample W19 proof package (M-12) renders end-to-end with ≥100 fact_citations
No new auto-firing routines created
No usage outside Claude Code subscription

12. Files to create this session (before execution starts)

.github/workflows/parity-parallel-merge.yml (modeled on comms-parallel-merge.yml)
.github/workflows/parity-tracker-rollup.yml (cron 4h, updates tracker §1)
.github/workflows/parity-blocker-watch.yml (cron daily 8am ET, blocker dashboard)
Create the claude/parity-program-integration branch on fin-agentic
PR template for parity tasks at .github/PULL_REQUEST_TEMPLATE/parity-task.md

Once these land, execution can start any session against any track.

13. References

Plan: FIN_PRODUCTION_PARITY_PROGRAM_2026-05-16.md
Tracker: FIN_PRODUCTION_PARITY_TRACKER_2026-05-16.md
Existing parallel-merge workflow patterns:
- .github/workflows/comms-parallel-merge.yml
- .github/workflows/fc-parallel-merge.yml
- .github/workflows/masn-parallel-merge.yml
- .github/workflows/persona-parallel-merge.yml
Existing autonomous routines (DO NOT SPAWN NEW):
- EIF Continuation trig_014rpk6efarCSbUrazoLe7VY (cron 0 */4 * * *)
- Comms-program routines (4) — possibly in maintenance
- MASN routines (5) — possibly in maintenance
Branching pattern reference: feedback_staging_first_iteration_loop.md memory + project_comms_program_continuation_routine.md memory
Subagent dispatch pattern: Agent tool from Claude Code SDK

FIN Central

Explorer

FIN Production Parity Autonomous Execution Plan — Subscription-Only, No Routines

FIN Production Parity — Autonomous Execution Plan

0. Aggressive Schedule + Constraints

Constraints (binding)

1. Architecture (5 layers)

2. Layer 1 — GitHub Actions infrastructure

2.1 `parity-parallel-merge.yml`

2.2 `parity-tracker-rollup.yml`

2.3 `parity-blocker-watch.yml`

3. Layer 2 — Branching strategy

4. Layer 3 — Subagent fan-out within session

5. Layer 4 — Multi-session orchestration (Rob runs ≥2 terminals)

6. Layer 5 — Monitoring (zero LLM)

6.1 Per-session opening ritual

6.2 Per-session closing ritual

6.3 Continuous monitoring tools (no LLM)

6.4 Existing routines to monitor (NOT spawn)

7. AGGRESSIVE Execution Sequence (5 days wall-clock target)

Sequencing principle

Day 1 (Sat 5/16) — TODAY

Day 2 (Sun 5/17)

Day 3 (Mon 5/18)

Day 4 (Tue 5/19)

Day 5 (Wed 5/20) — FINAL INTEGRATION

Buffer (Thu 5/21 + Fri 5/22)

Wall-clock summary

8. Subagent dispatch examples

Example 1: Part C parallel renderer fan-out (within one session)

Example 2: Part B (sequential, no fan-out — P0)

9. Cost model (subscription only)

10. Risk + mitigation

11. Success criteria

12. Files to create this session (before execution starts)

13. References

Graph View

Table of Contents

Backlinks

FIN Central

Explorer

FIN Production Parity Autonomous Execution Plan — Subscription-Only, No Routines

FIN Production Parity — Autonomous Execution Plan

0. Aggressive Schedule + Constraints

Constraints (binding)

1. Architecture (5 layers)

2. Layer 1 — GitHub Actions infrastructure

2.1 parity-parallel-merge.yml

2.2 parity-tracker-rollup.yml

2.3 parity-blocker-watch.yml

3. Layer 2 — Branching strategy

4. Layer 3 — Subagent fan-out within session

5. Layer 4 — Multi-session orchestration (Rob runs ≥2 terminals)

6. Layer 5 — Monitoring (zero LLM)

6.1 Per-session opening ritual

6.2 Per-session closing ritual

6.3 Continuous monitoring tools (no LLM)

6.4 Existing routines to monitor (NOT spawn)

7. AGGRESSIVE Execution Sequence (5 days wall-clock target)

Sequencing principle

Day 1 (Sat 5/16) — TODAY

Day 2 (Sun 5/17)

Day 3 (Mon 5/18)

Day 4 (Tue 5/19)

Day 5 (Wed 5/20) — FINAL INTEGRATION

Buffer (Thu 5/21 + Fri 5/22)

Wall-clock summary

8. Subagent dispatch examples

Example 1: Part C parallel renderer fan-out (within one session)

Example 2: Part B (sequential, no fan-out — P0)

9. Cost model (subscription only)

10. Risk + mitigation

11. Success criteria

12. Files to create this session (before execution starts)

13. References

Graph View

Table of Contents

Backlinks

2.1 `parity-parallel-merge.yml`

2.2 `parity-tracker-rollup.yml`

2.3 `parity-blocker-watch.yml`