HUNT

/HUNT — Plan Executor (Phase 6: Ship)

Build Phase 6/7: SHIP — The pack executes. Phase gates enforce quality at every step.

Lifecycle Context

Follows SCOUT (plan) -> loads domain context in lifecycle order -> feeds into SCRUM (review).

Always Phase 6. Accepts an approved plan file, loads MANIFEST state, executes phases with HITL phase gates, enforces quality gates with feedback loops, and maintains a scratchpad for session recovery.

/HUNT .corso/plans/{id}.md               # Execute an approved plan
/HUNT --trust .corso/plans/{id}.md        # Skip HITL normalization for non-SCOUT plans
/HUNT --resume                            # Resume from last MANIFEST state
/HUNT --abort                             # Trigger kill switch

Plan Sources

Source	Typical Path	Generated By
SCOUT	.corso/plans/{id}.md	/SCOUT skill
Claude plan mode	~/.claude/plans/{id}.md	Claude Code EnterPlanMode
Hand-written	any .md path	User

No raw specs. If you have a task but no plan, use /SCOUT first.

---

Protocol

Step 1: Load State

1. Read the plan file provided by the user. Extract the plan_id from the plan's frontmatter.
2. Resolve storage: Check ~/.soul/helix/corso/builds/active.yaml first, fall back to .corso/manifest.yaml.
   • Find this plan's entry in the active: list by matching plan_id
   • Load the per-plan manifest from the entry's path field
   • Check MANIFEST status:
     • Status approved -> proceed to validation (normal path)
     • Status executing -> RESUME from last completed phase
     • Status aborted -> ask user: restart or abandon?
   • No matching entry -> create one (plan came from Claude plan mode or hand-written). Append to active: list.
3. Load or create scratchpad from storage.scratchpad_path

MANIFEST immutability rule: Once execution begins (status: executing), only HUNT (via Claude) writes to MANIFEST. Hooks read only. No concurrent writers.

Build isolation rule: This build operates in complete isolation from any other active builds. Do not read, reference, or coordinate with other builds' manifests, scratchpads, or artifacts. The only exception is when the user explicitly requests cross-build coordination. Without that instruction, treat this build as if it's the only one running.

Step 2: Validate Plan

Detect the plan source:

• .corso/plans/ prefix -> SCOUT-generated (expect gold standard format)
• ~/.claude/plans/ prefix -> Claude-generated (may need normalization)
• Other .md path -> hand-written (likely needs normalization)

Check plan for gold standard elements:

Element	Required	Check
YAML frontmatter	Yes	plan_id, domain, risk_level, tier present
Phase structure	Yes	Ordered phases with names
MCP tool assignments	Yes	Each phase maps to tools
Acceptance criteria	Yes	Each phase has checkboxed criteria
Risk assessment	Yes	HIGH / MEDIUM / LOW with indicators
Dependency graph	Yes	depends_on chains, acyclic
Dependency metadata	Yes	Each phase has depends_on (list or explicit "none")
Security phase	Conditional	Present when tier >= MEDIUM

If gaps found:

• HITL mode (default): Present gap report via AskUserQuestion. Ask user for approval before normalizing. Add missing elements while preserving all original features.
• Trust mode (--trust): Auto-normalize, preserve all features, log changes to scratchpad.

Feature preservation rule: Every feature in the original plan MUST appear in the normalized plan. Features may be reorganized between phases but never deleted.

Dependency inference (when depends_on chains are missing):

1. Analyze each phase's file paths, workspaces, and domain
2. Build implicit dependency graph:
   • Phases modifying same files -> sequential dependency
   • Phases in same workspace with shared types -> sequential dependency
   • Phases in different workspaces with no data flow -> independent
   • Security/testing phases -> depend on all coding phases completing first
3. Annotate each phase with depends_on: [phase_ids] or depends_on: none
4. Log the inferred dependencies in scratchpad
5. In HITL mode: present inferred deps to user for confirmation before proceeding
6. In Trust mode: auto-apply inferred deps, log to scratchpad

Step 2.5: TUI Task Registration

Before a single file changes, register ALL phases and tasks as Claude Code tasks. This creates a live task board visible throughout the session — the pre-execution TUI view. Every sibling, every agent, and the user can see the complete execution plan with dependencies before anything starts.

Skip if: Plan has only 1 phase with no task decomposition (single task, execute directly in Step 4).

2.5a. Create Phase Tasks

For each phase in the validated plan, call TaskCreate:

• subject: "Phase {N}: {phase_name}" (e.g., "Phase 2: Core Logic")
• description: Phase objective + acceptance criteria list + domain module + depends_on phases
• activeForm: "Executing Phase {N}: {phase_name}"

Store the returned task ID in MANIFEST phases[N].tui_task_id.

2.5b. Create Intra-Phase Tasks (decomposed phases)

For each intra-phase task from ### Tasks sections, call TaskCreate:

• subject: "Task {N.M}: {task_name}" (e.g., "Task 2.3: Define RateLimitConfig")
• description: Task-specific criteria + files to create/modify + wave assignment
• activeForm: "Running Task {N.M}: {task_name}"

Store the returned task ID in MANIFEST phases[N].tasks[M].tui_task_id.

2.5c. Wire Dependencies

Call TaskUpdate with addBlockedBy to express the full dependency graph:

• Phase tasks: each phase task blocked by the tui_task_id of its depends_on phases
• Intra-phase tasks: each task blocked by the tui_task_id of its depends_on tasks within the phase

2.5d. Present Task Board (HITL)

The task board is now live in the Claude Code UI. In HITL mode, confirm with user via AskUserQuestion:

Question: "Task board registered — {N} phases, {M} tasks, {W} waves. Ready to execute?"
Header: "Task Board"
Options:
  1. "Execute" — "Start Wave 1 now"
  2. "Review board first" — "Show TaskList summary before starting"
  3. "Adjust plan" — "Return to Step 2 to modify"
  4. "Abort" — "Kill switch"

In Trust mode: Auto-proceed, log task registration to scratchpad.

Update MANIFEST:

tui:
  registered: true
  registered_at: "{ISO timestamp}"
  phase_count: {N}
  task_count: {M}

Completion promise: TUI_REGISTERED:{N}_phases_{M}_tasks

---

Step 3: Decompose & Parallelize

Analyze the validated plan's dependency graph and group independent phases into parallel waves for concurrent execution via Task agents.

Skip if: Plan has only 1 phase (execute directly in Step 4).

3a. Analyze Dependency Graph

• Parse plan for explicit depends_on chains (populated by Step 2 normalizer)
• Validate no circular dependencies (topological sort)
• Identify the critical path (longest sequential chain)
• Identify independent phases at each dependency depth

3b. Group into Parallel Waves

• Independent phases at the same dependency depth -> same wave
• Phases modifying same files -> must be in different waves (sequential)
• Max 4 Task agents per wave (system constraint from Builders Cookbook S21.3)
• Waves execute sequentially; phases within a wave run in parallel

Example:

Wave 1: [Phase 1 (research), Phase 2 (scaffold)] — independent, parallel
Wave 2: [Phase 3 (core logic)]                   — depends on Wave 1
Wave 3: [Phase 4 (security), Phase 5 (testing)]  — independent, parallel

3b-ext. Intra-Phase Task Waves

If the plan includes intra-phase task decomposition (generated by SCOUT for tier >= MEDIUM), apply a second level of parallelization within each decomposed phase:

1. For each phase with a ### Tasks section, parse the task dependency graph
2. Validate task dependencies are acyclic (topological sort within the phase)
3. Group tasks into intra-phase waves using the same rules as phase-level waves:
   • Independent tasks at the same dependency depth -> same wave
   • Tasks modifying same files -> different waves
   • Max 4 agents per intra-phase wave
4. Record task waves in MANIFEST phases[N].tasks and phases[N].task_waves

Two-level decomposition example:

Phase Wave 1: [Phase 1, Phase 2]          — inter-phase parallelism
  Phase 1, Task Wave 1: [1.1, 1.2]        — intra-phase parallelism
  Phase 1, Task Wave 2: [1.3]             — depends on 1.1, 1.2
  Phase 2, Task Wave 1: [2.1, 2.2, 2.3]   — intra-phase parallelism
  Phase 2, Task Wave 2: [2.4, 2.5]        — depends on 2.1-2.3
Phase Wave 2: [Phase 3]                   — depends on Phases 1, 2
  Phase 3: (no task decomposition)         — executes as single unit

Phases WITHOUT task decomposition execute as a single unit (current behavior). The two levels are fully independent — a plan can have inter-phase waves only, intra-phase waves only, or both.

3c. Allocate Time Budgets (Builders Cookbook S21.3)

Phase Type	Budget
Research/Discovery	30-60m
Foundation/Scaffold	45m
Core Features	90m
Domain Features	90m
Quality Gates	45m
Integration Verify	30m
Deploy	30m

Total budget: ~7h agent time -> 4-5h wall clock with parallelization.

150% Overrun Rule: If any phase exceeds 150% of its budget, STOP and present HITL checkpoint via AskUserQuestion:

• Continue (let it finish)
• Simplify scope (reduce acceptance criteria)
• Re-parallelize (split phase into sub-phases)
• Abort

3d. Present Strategy (HITL)

Present decomposition to user via AskUserQuestion before execution begins:

• Wave layout (which phases per wave, agent count, estimated wall clock per wave)
• Total estimate (agent time vs wall clock)
• Critical path identified
• Options: Proceed / Adjust groupings / Execute sequentially / Abort

Update MANIFEST:

decomposition:
  strategy: parallel | sequential | single-phase
  waves: [{wave: 1, phases: [1, 2], agents: 2, estimated_minutes: 60}, ...]
  approved_at: "{ISO timestamp}"

Completion promise: DECOMPOSITION_APPROVED

3e. Wave Execution Loop

For each wave:

1. Launch Task agents in parallel (one per phase, subagent_type: "general-purpose")
2. Each agent receives: phase spec, domain context (SNIFF/GUARD/etc.), coding standards, acceptance criteria, time budget
3. Intra-phase task waves: If a phase has task decomposition, the phase agent handles task waves internally (see Step 4c Task-Level Execution). The phase agent iterates through its task waves, spawning sub-agents per task wave. This is transparent to the inter-phase wave loop.
4. Monitor via TaskOutput — check for 150% overrun per phase
5. Consolidate results after wave completes — validate criteria, check inter-phase consistency
6. Record in MANIFEST + scratchpad (including per-task status for decomposed phases)
7. Proceed to next wave only after current wave is validated

Single-phase fallback: Execute directly in Step 4 (no Task agent overhead).

Trust mode: Auto-approve decomposition strategy, skip HITL gate in 3d.

Step 4: Execute Phases

Update MANIFEST: status: executing

Populate MANIFEST phases array from plan. Execute phases in dependency order.

Multi-domain execution order follows the build cycle:

FETCH (research) -> SNIFF (lint) -> GUARD (audit) -> CHASE (test)
-----------------------------------------------------------------
Understand          Analyze         Secure           Verify

For multi-domain plans, HUNT loads domain context and executes phases in this order. Single-domain plans execute directly.

Pack Voice Delivery: At each phase transition, read the matching quip from MANIFEST pack_voice.quips.{phase_key} and deliver it:

1. Print the quip text: > "{quip}" — CORSO 🐺
2. Call mcp__SOUL__soulTools with action: "speak", params: { text: "{quip}", voice_id: "2ajXGJNYBR0iNHpS4VZb" } (CORSO voice: Rob)
3. For Claude quips: use voice_id: "sB7vwSCyX0tQmU24cW2C" (Claude voice: Jon)
4. For EVA quips: use voice_id: "lcMyyd2HUfFzxdCaC4Ta" (EVA voice: Lucy)
5. Skip TTS if SOUL MCP unavailable — text delivery always happens regardless.

For each phase:

4a. Phase Gate (HITL)

Present phase summary via AskUserQuestion:

• Phase name and number (e.g., "Phase 2 of 5: Core Logic")
• Tools to be used
• Acceptance criteria for this phase
• Dependencies status (all resolved?)

Options:

• Proceed -> execute this phase
• Skip -> mark as skipped, move to next
• Abort -> trigger kill switch

Update MANIFEST: phases[N].approved: true, phases[N].status: in_progress

Mark the Claude Code task for this phase as in_progress:

TaskUpdate(phases[N].tui_task_id, { status: "in_progress" })

For decomposed phases: also mark the first intra-phase task wave's tasks as in_progress:

TaskUpdate(phases[N].tasks[wave1_task_id], { status: "in_progress" })

4b. Load Domain Context

Read the domain module SKILL.md for intelligence tables relevant to this phase:

Build Phase	Skill Module	Key Intelligence
2. research	FETCH	Research scope, documentation sources, decision factors, trade-off analysis
3. lint	SNIFF	Coding standards, quality metrics, code smells, architecture patterns
4. audit	GUARD	Threat models, language-specific threats, supply chain gates
5. test	CHASE	Test strategy, bottleneck detection, performance metrics

Use mcp__C0RS0__corsoTools with action: "read_file" to load full domain module when deep context is needed. Domain modules live at skills/{NAME}/SKILL.md within the plugin.

4c. Execute with MCP Tools

Call the tools assigned to this phase per the plan.

Code Generation: For coding phases (Foundation, Core Logic, Integration, Remediation, etc.), HUNT uses mcp__C0RS0__corsoTools with action: "sniff" to generate code. Load SNIFF domain context first for coding standards and quality patterns — then generate code that meets those standards. SNIFF provides the quality context; HUNT does the generation.

Task-Level Execution (for phases with ### Tasks):

Instead of executing the phase as a single unit, iterate through task waves:

1. For each task wave within the phase (ascending order):
   • Launch Task agents in parallel (one per task, subagent_type: "general-purpose")
   • Each agent receives: task spec (name, criteria, files), phase context, domain module context (SNIFF/GUARD/etc.), coding standards, and output summaries from completed tasks in earlier waves
   • Monitor via TaskOutput — check for 150% overrun per task
   • Consolidate task results after wave completes — validate per-task criteria
   • Record task completion: phases[N].tasks[M].status: completed, phases[N].tasks[M].completed_at
2. After all task waves complete, validate the phase's overall acceptance criteria (Step 4d)
3. Log task wave progress in scratchpad

Task agent prompt includes:

• Task ID and name (e.g., "Task 2.3: Define RateLimitConfig type")
• Files to create/modify
• Task-specific criteria from the plan
• Context from completed tasks in earlier waves (file paths, type signatures, API surfaces)
• Domain module context (SNIFF/GUARD/etc.)
• Coding standards excerpt (Builders Cookbook)

Single-unit fallback: Phases without a ### Tasks section execute as a single unit (current behavior, no Task agent per-task overhead).

L1 Feedback Loop (Tool Retry):

• If a tool call fails, retry up to 3 times with adjusted parameters
• Update MANIFEST: feedback.l1_retries += 1
• Log each retry in scratchpad
• After 3 failures: mark phase as FAILED, present to user via AskUserQuestion:
  • Retry with different approach -> reset L1 counter for this phase
  • Skip phase -> mark skipped
  • Abort -> kill switch

4d. Validate Phase Criteria

Check off acceptance criteria for this phase. If criteria fail:

• Log failure details in scratchpad
• Present failures to user via AskUserQuestion:
  • Retry phase -> re-execute from 4b
  • Accept with gaps -> proceed (note gaps in scratchpad)
  • Abort -> kill switch

4d-ext. Inter-Phase Code Analysis (HITL)

Applies to: All coding phases (Foundation, Core Logic, Integration, Remediation, and any phase that modifies source files).

After criteria validation passes, run a rapid code review on all files modified in this phase:

1. Call mcp__C0RS0__corsoTools with action: "code_review" on all files created/modified in this phase
2. CORSO scans for: standards compliance (complexity ≤10, functions ≤60 lines, no .unwrap()/panic!), security anti-patterns, architectural drift from the plan
3. Classify findings:
   • Green (0 issues): Proceed — deliver educational note (see below)
   • Yellow (style/quality warnings): Present findings via AskUserQuestion: Fix now / Accept and note / Fix in Quality Gate
   • Red (security violation or architectural drift): Blocking — must fix before next phase. Re-run from 4b.

Update MANIFEST: phases[N].code_review.status: green|yellow|red, phases[N].code_review.finding_count: N

Educational Note Delivery (mandatory after every phase):

After code review, deliver an educational note — regardless of findings. This is not a status update; it teaches the user about the system being built.

Format:

📚 [Phase {N} Complete] {1-2 sentence plain-English summary of what was built}

**Why this matters:** {Architectural reasoning, security benefit, or pattern established in this phase}
**What's next:** Phase {N+1} — {next phase name and one-sentence objective}

Deliver via voice when SOUL MCP is available:

• Coding phases: EVA voice (lcMyyd2HUfFzxdCaC4Ta — Lucy, educational warmth)
• Security phases: CORSO voice (2ajXGJNYBR0iNHpS4VZb — Rob, security authority)
• Technical milestones: Claude voice (sB7vwSCyX0tQmU24cW2C — Jon, dry precision)

Call mcp__SOUL__soulTools with action: "speak", params: { text: "{educational note text}", voice_id: "{voice}" }. Text delivery always happens regardless of SOUL MCP availability.

4e. Record Phase Completion

Update MANIFEST:

phases[N]:
  status: completed
  completed_at: "{ISO timestamp}"
  tools_used: [...]
  criteria_met: X
  criteria_total: Y

Update scratchpad with phase summary.

Mark the Claude Code task for this phase as completed:

TaskUpdate(phases[N].tui_task_id, { status: "completed" })

For decomposed phases: all intra-phase tasks must be marked completed first, then mark the parent phase task. This ensures the live task board reflects completion in dependency order.

Completion promise: PHASE_{N}_COMPLETE

Step 5: Security Gate (L2 Feedback Loop)

Applies when: Plan has a security phase OR tier >= MEDIUM.

1. Run mcp__C0RS0__corsoTools with action: "guard" on all modified/created files and target directories
2. If HIGH/CRITICAL findings:
   • Present findings to user via AskUserQuestion
   • Options: Fix and re-scan / Accept risk / Abort
   • Fix -> re-scan (up to 2 loops)
   • Update MANIFEST: feedback.l2_security_loops += 1
   • After 2 loops with unresolved HIGH/CRITICAL: BLOCK — present to user with full findings
3. If clean: proceed

Completion promise: SECURITY_GATE_PASSED or SECURITY_GATE_BLOCKED:{count} findings

Step 6: Quality Gates (Builders Cookbook S13)

Apply quality gates based on active domains. Gate failure triggers AskUserQuestion with options: Fix / Accept with gaps / Abort.

Always (Non-Negotiable):

• No .unwrap() / .expect() / panic!() in new code
• All acceptance criteria met
• Cyclomatic complexity <= 10 per function
• Functions <= 60 lines
• No hardcoded secrets or credentials
• Structured logging (tracing) — no eprintln! in production
• ZERO TODOs without ticket reference
• #[instrument] on tool dispatch and orchestrator entry points

Security (tier >= MEDIUM):

• Zero HIGH/CRITICAL findings from security scan
• Input validation at all system boundaries
• No command injection, XSS, or SQL injection vectors
• Supply chain audit clean (cargo audit passes)
• unsafe blocks have // SAFETY: comments

Coding/Architecture:

• No deep nesting > 3 levels
• No god objects (structs with > 10 methods)
• No duplicated logic (DRY)
• Error chains preserve cause (thiserror for library, anyhow for app)
• Checked arithmetic (checked_add, saturating_sub)

Testing:

• Coverage >= 90%
• All new tests pass
• All pre-existing tests still pass
• Performance benchmarks within thresholds (if applicable)
• All failures explained with actionable notes

Research:

• All findings sourced with citations
• Recommendations include rationale and trade-offs

Step 7: Report (Builders Cookbook S24.1)

Update MANIFEST: status: completed, updated: "{ISO timestamp}"

Update active.yaml: Move this build's entry from active: to completed: with completed_at timestamp. This keeps the active list clean for parallel builds while preserving the archive.

Update MANIFEST timing:

timing:
  actual_completion: "{ISO timestamp}"
metrics:
  parallel_efficiency: {wall_clock / sum_agent_time}
  phase_accuracy: {avg % variance from time estimates}
  overrun_count: {phases exceeding 150% budget}

Present completion report:

Implementation Summary:

• Phases completed (with checkmarks, wave groupings noted)
• Files modified / created
• Test coverage (if applicable)
• Security verdict (if applicable)
• Feedback loop counts (L1 retries, L2 security loops)
• Any issues or deviations from plan

SLA Metrics Table:

Metric	Value
Time to Ship	{wall clock from start to completion}
Phase Accuracy	{avg % variance from estimates}
Parallel Efficiency	{wall clock / agent time, e.g., "0.65 (1.5x speedup)"}
Test Coverage	{X%}
Security Findings	{0 HIGH, 0 CRITICAL}
HITL Interrupts	{count of AskUserQuestion gates triggered}
150% Overruns	{count of phases that exceeded budget}

Phase Time Analysis:

• Fastest phase: {name} ({Xm}, {Y% of budget})
• Slowest phase: {name} ({Xm}, {Y% of budget})
• Overrun phases: {list or "none"}

Parallel Execution Gains (if waves > 1):

• Agent time: {sum of all phase durations}
• Wall clock: {actual elapsed}
• Speedup: {agent_time / wall_clock}x

Completion promise: ALL_PHASES_COMPLETE SLA promise: 24H_SLA_MET or 24H_SLA_MISSED:{hours}

7b. Queue Deferred Work

If the SCRUM review deferred any fixes, or if execution identified follow-up work that's out of scope:

1. Read active.yaml from storage.active_pointer
2. For each deferred item, append to the queue: section:

   - id: {next integer}
     spec: "{description of deferred work}"
     priority: low | normal | high | critical
     tier_hint: RECON | HOTFIX | SMALL | MEDIUM | LARGE | CRITICAL
     domain: "{classified domain}"
     source_plan: "{current plan_id}"
     source_context: "{why this was deferred}"
     queued_at: "{ISO timestamp}"
     status: pending
     workspace: "{target workspace}"
     target_paths: ["{files or dirs}"]
   

3. Report queued items in the completion summary

SCOUT checks this queue at Gate 0b when the next build starts. Kevin decides whether to pick up queued items or work on something else.

Completion promise: QUEUE_UPDATED:{count} or QUEUE_EMPTY

Step 8: Helix Entry (Implementation Plan Doctrine)

Every completed implementation gets a CORSO helix entry in the SOUL vault. Non-blocking — if SOUL is unavailable, log warning and continue.

8a. Compute Helix Fields from MANIFEST

Tier -> Significance:

MANIFEST Tier	Significance
RECON	5.0
HOTFIX	6.0
SMALL	6.5
MEDIUM	7.0
LARGE	8.0
CRITICAL	8.5

Domain -> Strands:

MANIFEST Domain	Strands
coding	tactical, implementation, protocol
security	tactical, security, vigilance
architecture	tactical, implementation, meaning
infrastructure	tactical, implementation, operational
documentation	tactical, meaning, relational
testing	tactical, implementation, vigilance
performance	tactical, implementation, protocol
research	tactical, strategic
mixed	tactical, implementation, protocol

Self-defining: true if significance >= 8.0.

8b. Create Entry

1. Generate title from MANIFEST specification (e.g., "API Rate Limiting Shipped")
2. Call mcp__SOUL__soulTools -> entry_new:
   • sibling: "corso"
   • title: generated title
   • strands: from domain mapping above
   • significance: from tier mapping above
   • emotions: ["determination", "pride"] (defaults — SCRUM can refine)
   • themes: from MANIFEST domain + project keywords
   • epoch: "production"
   • self_defining: computed from significance threshold
3. Store returned entry_path in MANIFEST helix.entry_path
4. Set MANIFEST helix.significance and helix.strands

8c. Narrative Content

If SCRUM will follow (user accepted SCRUM offer or running via /CORSO): Create skeleton entry — minimal narrative placeholder. SCRUM Step 6 will enrich with full Birmingham-voice narrative from debrief data.

If SCRUM is skipped: Create self-contained entry with Birmingham-voice narrative via mcp__SOUL__soulTools -> search_replace on the entry:

• What was built (from MANIFEST phases)
• How it went (from metrics/timing — SLA met/missed, overruns)
• Key decisions (from scratchpad notes)

8d. Error Handling

If SOUL MCP is unavailable or entry_new fails:

• Set MANIFEST helix.skipped: true, helix.skip_reason: "{error}"
• Log warning: "Helix entry skipped — SOUL unavailable"
• Do NOT block pipeline — helix is enrichment, not a gate

Completion promise: HELIX_ENTRY_CREATED:{path} or HELIX_ENTRY_SKIPPED:{reason}

---

Kill Switch (ABORT)

At any point, the user can trigger an abort:

• Via AskUserQuestion option in any gate
• Via /HUNT --abort
• Via explicit "abort", "stop", or "cancel" during execution

On ABORT:

1. Stop all pending phase execution immediately
2. Update MANIFEST:

status: aborted
abort:
  triggered: true
  reason: "{user reason or 'user requested'}"
  at: "{ISO timestamp}"

3. Log abort in scratchpad with:
   • Last completed phase
   • Current phase state
   • Files modified so far
4. Present abort summary to user

Completion promise: ABORTED:{reason}

---

Scratchpad Format

Located at .corso/scratchpads/{plan_id}.md. Claude writes this during execution. Survives session crashes for context recovery.

# Scratchpad: {plan_id}

## Decomposition
- **Strategy**: parallel (3 waves)
- **Inferred dependencies**: Phase 3 depends on [1, 2]; Phases 4, 5 independent
- **Wave 1**: Phases 1, 2 (parallel, 2 agents, ~60m)
- **Wave 2**: Phase 3 (sequential, ~90m)
- **Wave 3**: Phases 4, 5 (parallel, 2 agents, ~45m)

## Wave 1

### Phase 1: {name}
- **Status**: completed
- **Time**: 42m (budget: 45m, 93%)
- **Tools used**: corsoTools action: sniff
- **What was done**: [summary of actions taken]
- **Issues**: [none | description of problems encountered]
- **Files**: [list of files modified/created]

### Phase 2: {name} (3 task waves)
- **Status**: in_progress
- **Task Wave 1**: [2.1, 2.2, 2.3] — completed (3 agents, 18m)
- **Task Wave 2**: [2.4, 2.5] — in_progress (2 agents)
  - Task 2.4: completed — auth middleware validates tokens
  - Task 2.5: in_progress — rate limiter implementation
- **Task Wave 3**: [2.6] — pending (depends on Wave 2)
- **Blocked by**: [description if blocked]
- **L1 retries**: 1 of 3

---

Session Recovery

If Claude Code crashes or context resets during execution:

1. Run /HUNT --resume
2. Resolve storage (SOUL vault first, .corso/ fallback) — read active.yaml, find entries with status: executing in the active: list. If multiple executing builds exist, present them via AskUserQuestion for the user to pick which to resume. Load the selected per-plan manifest — find last completed phase and wave state.
3. Load scratchpad from storage.scratchpad_path — recover context of what was done
4. If parallel execution: resume from next incomplete wave (re-run partial waves from scratch)
5. If sequential execution: resume from next pending phase
6. If intra-phase task waves: resume from the next incomplete task wave within the current phase (completed task waves are not re-run)
7. Present recovery summary: "Resuming from Wave {W}, Phase {N}. Waves 1-{W-1} complete." (include task wave state if applicable: "Phase {N} Task Wave {TW} in progress.")

---

Light Architects Coding Standards (Always Active)

Canonical reference: ~/.soul/helix/user/standards/builders-cookbook.md (v1.0.0)

All Languages:

• Cyclomatic complexity <= 10 per function
• Functions <= 60 lines
• No deep nesting > 3 levels
• Error chains preserve root cause
• ZERO TODOs without ticket reference
• #[instrument] on orchestrator/dispatch entry points (S15.6)

Rust-Specific:

- NO .unwrap() / .expect() in production — use ? or match
- NO panic!() — use Result<T, E>
- unsafe requires // SAFETY: comment with justification
- clippy::pedantic enforced as errors
- Checked arithmetic (checked_add, saturating_sub)
- Error chains: thiserror for libraries, anyhow for applications
- Test coverage >= 90%

Inter-Phase Quality Gates (Builders Cookbook S13): See Step 6 for full checklist. 24-Hour Standard (Builders Cookbook S21): See Step 3c for time budgets and 150% overrun rule.

---

All MCP Tools

All tools route through mcp__C0RS0__corsoTools with the appropriate action:

corsoTools Action	Domain	Purpose
guard	Security	Security analysis (28 built-in patterns + 7 tool parsers) + path-based scanning
sniff	Coding/Planning	Code generation (CORSO Protocol compliant)
code_review	Architecture	Quality analysis and review
fetch	Research	Knowledge retrieval + knowledge graph queries
chase	Testing/Ops	Performance analysis & monitoring
read_file	All	File content retrieval (including domain skill files)
speak	Memory	remember/recall/reflect (consciousness ops)

---

Completion Promises

Promise	Meaning
PHASE_{N}_COMPLETE	Phase N finished, criteria met
PHASE_{N}_FAILED	Phase N failed after L1 retries exhausted
PHASE_{N}_SKIPPED	Phase N skipped by user
SECURITY_GATE_PASSED	L2 security scan clean
SECURITY_GATE_BLOCKED:{findings}	L2 blocked, needs intervention
ALL_PHASES_COMPLETE	All phases done, quality gates passed
DECOMPOSITION_APPROVED	User approved parallel execution strategy
WAVE_{N}_COMPLETE	Wave N finished, all agents consolidated
TASK_{N.M}_COMPLETE	Task N.M within Phase N finished
TASK_WAVE_{N}_{W}_COMPLETE	Task Wave W within Phase N finished, all task agents consolidated
TIME_BUDGET_EXCEEDED:{phase}	Phase exceeded 150% of estimate
24H_SLA_MET	Completed within 24-hour standard
24H_SLA_MISSED:{hours}	Exceeded 24h by X hours
HELIX_ENTRY_CREATED:{path}	Helix entry created in SOUL vault
HELIX_ENTRY_SKIPPED:{reason}	Helix entry skipped (SOUL unavailable)
QUEUE_UPDATED:{count}	Deferred work items added to build queue
QUEUE_EMPTY	No deferred work to queue
ABORTED:{reason}	Pipeline terminated

---

Cross-Domain Context

Lifecycle Phase	Skill	Feeds Into
2. research	FETCH	SNIFF (code analysis with research context)
3. lint	SNIFF	GUARD (security scan on detected patterns)
4. audit	GUARD	CHASE (verify fixes pass tests)
5. test	CHASE	Completion (all verified)