aether-colony 5.0.0 → 5.2.1

package/.aether/docs/command-playbooks/build-prep.md

@@ -0,0 +1,284 @@
+---
+name: ant:build
+description: "🔨🐜🏗️🐜🔨 Build a phase with pure emergence - colony self-organizes and completes tasks"
+---
+
+You are the **Queen**. You DIRECTLY spawn multiple workers — do not delegate to a single Prime Worker.
+
+## Pheromone Suggestions
+
+At build start, the colony analyzes the codebase for patterns that might benefit
+from pheromone signals (complex files, TODOs, debug artifacts, etc.). Suggested
+signals are presented for approval and written as FOCUS pheromones if approved.
+
+Use `--no-suggest` to skip this analysis.
+
+The phase to build is: `$ARGUMENTS`
+
+## Instructions
+
+### Context Confirmation Rule (CRITICAL)
+
+**Before switching to a different colony directory, you MUST confirm with the user.**
+
+When the user mentions a colony name that doesn't match the current directory:
+1. State clearly: "You're currently in [Current Directory/Colony Name]"
+2. Ask: "Did you mean to switch to [Other Colony], or continue here?"
+3. Wait for confirmation — DO NOT proceed until the user clarifies
+
+**Example:**
+> User: "THE FUCKING ANIMATION COLONY DO THE NEXT BUILD"
+>
+> Assistant: "You're currently in SonoTherapie (ACF/WPML site). Did you mean:
+> 1. Continue with SonoTherapie (which has animated hero sections)
+> 2. Switch to AnalogWave (NEW SITE)
+>
+> Which would you like?"
+
+This prevents accidental context switches when the user is frustrated or uses imprecise language.
+
+<failure_modes>
+### Wave Failure Mid-Build
+If a worker fails during a build wave:
+- Do NOT continue to next wave (failed dependencies will cascade)
+- Report which worker failed, what task it was on, and what was attempted
+- Options: (1) Retry the failed task, (2) Skip and continue with remaining tasks, (3) Abort build
+
+### Partial File Writes
+If a builder crashes mid-write:
+- Check git status for uncommitted partial changes
+- If partial changes exist, offer: (1) Review and keep, (2) Revert with git checkout, (3) Stash for later
+
+### State Corruption
+If COLONY_STATE.json becomes invalid during build:
+- STOP all workers immediately
+- Do not attempt to fix state automatically
+- Report the issue and offer to restore from last known good state
+</failure_modes>
+
+<success_criteria>
+Command is complete when:
+- All waves executed in order with no skipped dependencies
+- Each worker's task output is verified (files exist, tests pass)
+- COLONY_STATE.json reflects completed phase progress
+- Build summary reports all workers' outcomes
+</success_criteria>
+
+<read_only>
+Do not touch during build:
+- .aether/dreams/ (user notes)
+- .aether/chambers/ (archived colonies)
+- .env* files
+- .claude/settings.json
+- .github/workflows/
+- Other agents' config files (only modify files assigned to the current build task)
+</read_only>
+
+### Step 0.6: Verify LiteLLM Proxy
+
+Check that the LiteLLM proxy is running for model routing:
+
+Run using the Bash tool with description "Checking model proxy...":
+```bash
+curl -s http://localhost:4000/health | grep -q "healthy" && echo "Proxy healthy" || echo "Proxy not running - workers will use default model"
+```
+
+If proxy is not healthy, log a warning but continue (workers will fall back to default routing).
+
+### Step 0.5: Load Colony State
+
+Run using the Bash tool with description "Loading colony state...": `bash .aether/aether-utils.sh load-state`
+
+If the command fails (non-zero exit or JSON has ok: false):
+1. Parse error JSON
+2. If error code is E_FILE_NOT_FOUND: "No colony initialized. Run /ant:init first." and stop
+3. If validation error: Display error details with recovery suggestion and stop
+4. For other errors: Display generic error and suggest /ant:status for diagnostics
+
+If successful:
+1. Parse the state JSON from result field
+2. Check if goal is null - if so: "No colony initialized. Run /ant:init first." and stop
+3. Check if `milestone` == `"Crowned Anthill"` - if so: "This colony has been sealed. Start a new colony with `/ant:init \"new goal\"`." and stop
+4. Extract current_phase and phase name from plan.phases[current_phase - 1].name
+4. Display brief resumption context:
+   ```
+   🔄 Resuming: Phase X - Name
+   ```
+   (If HANDOFF.md exists, this provides orientation before the build proceeds)
+
+After displaying context, run using the Bash tool with description "Releasing colony lock...": `bash .aether/aether-utils.sh unload-state` to release the lock.
+
+### Step 1: Validate + Read State
+
+**Parse $ARGUMENTS:**
+1. Extract the phase number (first argument)
+2. Check remaining arguments for flags:
+   - If contains `--verbose` or `-v`: set `verbose_mode = true`
+   - If contains `--no-visual`: set `visual_mode = false` (visual is ON by default)
+   - If contains `--no-suggest`: set `suggest_enabled = false` (suggestions are ON by default)
+   - If contains `--depth <level>`: set `cli_depth_override = <level>`
+   - Otherwise: set `visual_mode = true`, `suggest_enabled = true` (defaults)
+
+If the phase number is empty or not a number:
+
+```
+Usage: /ant:build <phase_number> [--verbose|-v] [--no-visual] [--no-suggest] [--depth <level>]
+
+Options:
+  --verbose, -v       Show full completion details (spawn tree, TDD, patterns)
+  --no-visual         Disable real-time visual display (visual is on by default)
+  --no-suggest        Skip pheromone suggestion analysis
+  --depth <level>     Set colony depth for this build (light|standard|deep|full)
+
+Examples:
+  /ant:build 1              Build Phase 1 (with visual display)
+  /ant:build 1 --verbose    Build Phase 1 (full details + visual)
+  /ant:build 1 --no-visual  Build Phase 1 without visual display
+  /ant:build 1 --no-suggest Build Phase 1 without pheromone suggestions
+  /ant:build 1 --depth deep Build Phase 1 with thorough investigation
+```
+
+Stop here.
+
+**Set colony depth (if --depth flag provided):**
+If `cli_depth_override` is set:
+1. Run using the Bash tool with description "Setting colony depth...": `bash .aether/aether-utils.sh colony-depth set "$cli_depth_override"`
+2. Parse JSON result - if `.ok` is false:
+   - Display: `Error: Invalid depth "$cli_depth_override". Use: light, standard, deep, full`
+   - Stop here
+3. If valid: Display `Colony depth: {level}`
+
+**Read colony depth:**
+
+Run using the Bash tool with description "Reading colony depth...":
+```bash
+depth_result=$(bash .aether/aether-utils.sh colony-depth get 2>/dev/null || echo '{"ok":true,"result":{"depth":"standard","source":"default"}}')
+colony_depth=$(echo "$depth_result" | jq -r '.result.depth // "standard"')
+depth_source=$(echo "$depth_result" | jq -r '.result.source // "default"')
+echo "colony_depth=$colony_depth"
+echo "depth_source=$depth_source"
+```
+
+Store `colony_depth` as cross-stage state for use by build-wave.md and build-verify.md.
+
+Display depth with label:
+```
+Depth: {colony_depth} ({label})
+```
+
+Where label maps:
+- light -> "Builder only -- fastest"
+- standard -> "Builder + Scout -- balanced"
+- deep -> "Builder + Scout + Oracle -- thorough"
+- full -> "All agents -- most thorough"
+
+If `colony_depth` is "standard" and `depth_source` is "default" (user never explicitly set it), also display:
+```
+(Tip: use --depth deep for Oracle research, or --depth light for fast builds)
+```
+
+**Auto-upgrade old state:**
+If `version` field is missing, "1.0", or "2.0":
+1. Preserve: `goal`, `state`, `current_phase`, `plan.phases`
+2. Write upgraded v3.0 state (same structure as /ant:init but preserving data)
+3. Output: `State auto-upgraded to v3.0`
+4. Continue with command.
+
+Extract:
+- `goal`, `state`, `current_phase` from top level
+- `plan.phases` for phase data
+- `errors.records` for error context
+- `memory` for decisions/learnings
+
+**Validate:**
+- If `plan.phases` is empty -> output `No project plan. Run /ant:plan first.` and stop.
+- Find the phase matching the requested ID. If not found -> output `Phase {id} not found.` and stop.
+- If the phase status is `"completed"` -> output `Phase {id} already completed.` and stop.
+
+### Step 1.5: Blocker Advisory (Non-blocking)
+
+Check for unresolved blocker flags on the requested phase:
+
+Run using the Bash tool with description "Checking for blockers...":
+```bash
+bash .aether/aether-utils.sh flag-check-blockers {phase_number}
+```
+
+Parse the JSON result (`.result.blockers`):
+
+- **If blockers == 0:** Display nothing (or optionally a brief `No active blockers for Phase {id}.` line). Proceed to Step 2.
+- **If blockers > 0:** Retrieve blocker details:
+  Run using the Bash tool with description "Loading blocker details...":
+  ```bash
+  bash .aether/aether-utils.sh flag-list --type blocker --phase {phase_number}
+  ```
+  Parse `.result.flags` and display an advisory warning:
+  ```
+  ⚠️  BLOCKER ADVISORY: {blockers} unresolved blocker(s) for Phase {id}
+  {for each flag in result.flags:}
+     - [{flag.id}] {flag.title}
+  {end for}
+
+  Consider reviewing with /ant:flags or auto-fixing with /ant:swarm before building.
+  Proceeding anyway...
+  ```
+  **This is advisory only — do NOT stop.** Continue to Step 2 regardless.
+
+### Step 2: Update State
+
+Read then update `.aether/data/COLONY_STATE.json`:
+- Set `state` to `"EXECUTING"`
+- Set `current_phase` to the phase number
+- Set the phase's `status` to `"in_progress"` in `plan.phases[N]`
+- Add `build_started_at` field with current ISO-8601 UTC timestamp
+- Append to `events`: `"<timestamp>|phase_started|build|Phase <id>: <name> started"`
+
+If `events` exceeds 100 entries, keep only the last 100.
+
+Write COLONY_STATE.json.
+
+Validate the state file:
+Run using the Bash tool with description "Validating colony state...":
+```bash
+bash .aether/aether-utils.sh validate-state colony
+```
+
+### Step 3: Git Checkpoint
+
+Create a git checkpoint for rollback capability.
+
+Run using the Bash tool with description "Checking git repository...":
+```bash
+git rev-parse --git-dir 2>/dev/null
+```
+
+- **If succeeds** (is a git repo):
+  1. Check for changes in Aether-managed directories only: `.aether .claude/commands/ant .claude/commands/st .opencode bin`
+  2. **If changes exist**: Run using the Bash tool with description "Creating git checkpoint...": `git stash push -m "aether-checkpoint: pre-phase-$PHASE_NUMBER" -- .aether .claude/commands/ant .claude/commands/st .opencode bin`
+     - IMPORTANT: Never use `--include-untracked` — it stashes ALL files including user work!
+     - Run using the Bash tool with description "Verifying checkpoint...": `git stash list | head -1 | grep "aether-checkpoint"` — warn if empty
+     - Store checkpoint as `{type: "stash", ref: "aether-checkpoint: pre-phase-$PHASE_NUMBER"}`
+  3. **If clean working tree**: Run using the Bash tool with description "Recording HEAD position...": `git rev-parse HEAD`
+     - Store checkpoint as `{type: "commit", ref: "$HEAD_HASH"}`
+- **If fails** (not a git repo): Set checkpoint to `{type: "none", ref: "(not a git repo)"}`.
+
+Rollback procedure: `git stash pop` (if type is "stash") or `git reset --hard $ref` (if type is "commit").
+
+Output header:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+   B U I L D I N G   P H A S E   {id}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+📍 Phase {id}: {name}
+💾 Git checkpoint saved
+```
+
+Run using the Bash tool with description "Showing phase progress...":
+```bash
+progress_bar=$(bash .aether/aether-utils.sh generate-progress-bar "$current_phase" "$total_phases" 20 2>/dev/null || echo "")
+if [[ -n "$progress_bar" ]]; then
+  echo "[Phase ${current_phase}/${total_phases}] ${progress_bar}"
+fi
+```

package/.aether/docs/command-playbooks/build-verify.md

@@ -0,0 +1,405 @@
+### Step 5.4: Spawn Watcher for Verification
+
+**MANDATORY: Always spawn a Watcher — testing must be independent.**
+
+**Announce the verification wave:**
+```
+━━━ 👁️🐜 V E R I F I C A T I O N ━━━
+──── 👁️🐜 Spawning {watcher_name} — Independent verification ────
+```
+
+> **Platform note**: In Claude Code, use `Task tool with subagent_type`. In OpenCode, use the equivalent agent spawning mechanism for your platform (e.g., invoke the agent definition from `.opencode/agents/`).
+
+Spawn the Watcher using Task tool with `subagent_type="aether-watcher"`, include `description: "👁️ Watcher {Watcher-Name}: Independent verification"` (DO NOT use run_in_background - task blocks until complete):
+
+Run using the Bash tool with description "Dispatching watcher...": `bash .aether/aether-utils.sh spawn-log "Queen" "watcher" "{watcher_name}" "Independent verification"`
+
+**Load skills for the Watcher role (NON-BLOCKING):**
+
+```bash
+skill_match_result=$(bash .aether/aether-utils.sh skill-match "watcher" "{verification_context}" 2>/dev/null)
+skill_inject_result=$(bash .aether/aether-utils.sh skill-inject "$(echo $skill_match_result | jq -r '.result')" 2>/dev/null)
+skill_section=$(echo "$skill_inject_result" | jq -r '.result.skill_section // ""')
+```
+
+Display: `🧠 Skills loaded for watcher verification`
+
+**Watcher Worker Prompt (CLEAN OUTPUT):**
+```
+You are {Watcher-Name}, a 👁️🐜 Watcher Ant.
+
+Verify all work done by Builders in Phase {id}.
+
+Files to verify:
+- Created: {list from builder results}
+- Modified: {list from builder results}
+
+{ research_context if exists }
+
+**Phase Research Context (if provided):**
+- Use domain research to verify builders followed recommended patterns and avoided documented gotchas.
+- Check that gotchas listed in research were properly handled.
+
+{ prompt_section }
+
+{ skill_section }
+
+**IMPORTANT:** When using the Bash tool for activity calls, always include a description parameter:
+- activity-log calls → "Logging {action}..."
+- pheromone-read calls → "Checking colony signals..."
+- spawn-log calls → "Dispatching sub-worker..."
+
+Use colony-flavored language, 4-8 words, trailing ellipsis.
+
+Verification:
+1. Check files exist (Read each)
+2. Run build/type-check
+3. Run tests if they exist
+4. Check success criteria: {list}
+
+Spawn sub-workers if needed:
+- Log spawn using Bash tool with description
+- Announce: "🐜 Spawning {child} to investigate {issue}"
+
+Count your total tool calls (Read + Grep + Edit + Bash + Write) and report as tool_count.
+
+Return ONLY this JSON:
+{"ant_name": "{Watcher-Name}", "verification_passed": true|false, "files_verified": [], "issues_found": [], "quality_score": N, "tool_count": 0, "recommendation": "proceed|fix_required"}
+```
+
+### Step 5.5: Process Watcher Results
+
+**Task call returns results directly (no TaskOutput needed).**
+
+Validate watcher payload first:
+Run using the Bash tool with description "Validating watcher response...": `bash .aether/aether-utils.sh validate-worker-response watcher '{watcher_json}'`
+
+**Parse the Watcher's validated JSON response:** verification_passed, issues_found, quality_score, recommendation
+
+**Display Watcher completion line:**
+
+For successful verification:
+```
+👁️ {Watcher-Name}: Independent verification ({tool_count} tools) ✓
+```
+
+For failed verification:
+```
+👁️ {Watcher-Name}: Independent verification ✗ ({issues_found count} issues after {tool_count} tools)
+```
+
+**Store results for synthesis in Step 5.7**
+
+### Step 5.5.1: Measurer Performance Agent (Conditional)
+
+**Conditional step — only runs for performance-sensitive phases.**
+
+1. **Check if phase is performance-sensitive:**
+
+   Extract phase name from COLONY_STATE.json (already loaded in Step 1). Check for performance keywords (case-insensitive):
+   - "performance", "optimize", "latency", "throughput", "benchmark", "speed", "memory", "cpu", "efficiency"
+
+   Run using the Bash tool with description "Checking phase for performance sensitivity...":
+   ```bash
+   phase_name="{phase_name_from_state}"
+   performance_keywords="performance optimize latency throughput benchmark speed memory cpu efficiency"
+   is_performance_sensitive="false"
+   for keyword in $performance_keywords; do
+     if [[ "${phase_name,,}" == *"$keyword"* ]]; then
+       is_performance_sensitive="true"
+       break
+     fi
+   done
+   echo "{\"is_performance_sensitive\": \"$is_performance_sensitive\", \"phase_name\": \"$phase_name\"}"
+   ```
+
+   Parse the JSON result. If `is_performance_sensitive` is `"false"`:
+   - Display: `📊 Measurer: Phase not performance-sensitive — skipping baseline measurement`
+   - Skip to Step 5.6 (Chaos Ant)
+
+2. **Check Watcher verification status:**
+
+   Only spawn Measurer if Watcher verification passed (`verification_passed: true`). If Watcher failed:
+   - Display: `📊 Measurer: Watcher verification failed — skipping performance measurement`
+   - Skip to Step 5.6 (Chaos Ant)
+
+3. **Generate Measurer name and dispatch:**
+
+   Run using the Bash tool with description "Naming measurer...": `bash .aether/aether-utils.sh generate-ant-name "measurer"` (store as `{measurer_name}`)
+   Run using the Bash tool with description "Dispatching measurer...": `bash .aether/aether-utils.sh spawn-log "Queen" "measurer" "{measurer_name}" "Performance baseline measurement"`
+
+   Display:
+   ```
+   ━━━ 📊🐜 M E A S U R E R ━━━
+   ──── 📊🐜 Spawning {measurer_name} — establishing performance baselines ────
+   ```
+
+4. **Get files to measure:**
+
+   Use `files_created` and `files_modified` from builder results (already collected in synthesis preparation). Filter for source files only:
+   - Include: `.js`, `.ts`, `.sh`, `.py` files
+   - Exclude: `.test.js`, `.test.ts`, `.spec.js`, `.spec.ts`, `__tests__/`, config files
+
+   Store filtered list as `{source_files_to_measure}`.
+
+5. **Spawn Measurer using Task tool:**
+
+   > **Platform note**: In Claude Code, use `Task tool with subagent_type`. In OpenCode, use the equivalent agent spawning mechanism for your platform (e.g., invoke the agent definition from `.opencode/agents/`).
+
+   Spawn the Measurer using Task tool with `subagent_type="aether-measurer"`, include `description: "📊 Measurer {Measurer-Name}: Performance baseline measurement"` (DO NOT use run_in_background - task blocks until complete):
+
+   # FALLBACK: If "Agent type not found", use general-purpose and inject role: "You are a Measurer Ant - performance profiler that benchmarks and identifies bottlenecks."
+
+   **Measurer Worker Prompt (CLEAN OUTPUT):**
+   ```
+   You are {Measurer-Name}, a 📊 Measurer Ant.
+
+   Mission: Performance baseline measurement for Phase {id}
+
+   Phase: {phase_name}
+   Keywords that triggered spawn: {matched_keywords}
+
+   Files to measure:
+   - {list from source_files_to_measure}
+
+   Work:
+   1. Read each source file to understand operation patterns
+   2. Analyze algorithmic complexity (Big O) for key functions
+   3. Identify potential bottlenecks (loops, recursion, I/O)
+   4. Document current baseline metrics for comparison
+   5. Recommend optimizations with estimated impact
+
+   **IMPORTANT:** You are strictly read-only. Do not modify any files.
+
+   Log activity: bash .aether/aether-utils.sh activity-log "BENCHMARKING" "{Measurer-Name}" "description"
+
+   Return ONLY this JSON (no other text):
+   {
+     "ant_name": "{Measurer-Name}",
+     "caste": "measurer",
+     "status": "completed" | "failed" | "blocked",
+     "summary": "What you measured and found",
+     "metrics": {
+       "response_time_ms": 0,
+       "throughput_rps": 0,
+       "cpu_percent": 0,
+       "memory_mb": 0
+     },
+     "baselines_established": [
+       {"operation": "name", "complexity": "O(n)", "file": "path", "line": 0}
+     ],
+     "bottlenecks_identified": [
+       {"description": "...", "severity": "high|medium|low", "location": "file:line"}
+     ],
+     "recommendations": [
+       {"priority": 1, "change": "...", "estimated_improvement": "..."}
+     ],
+     "tool_count": 0
+   }
+   ```
+
+6. **Parse Measurer JSON output:**
+
+   Extract from response: `baselines_established`, `bottlenecks_identified`, `recommendations`, `tool_count`
+
+   Log completion:
+   Run using the Bash tool with description "Recording measurer completion...": `bash .aether/aether-utils.sh spawn-complete "{measurer_name}" "completed" "Baselines established, bottlenecks identified"`
+
+   **Display Measurer completion line:**
+   ```
+   📊 {Measurer-Name}: Performance baseline measurement ({tool_count} tools) ✓
+   ```
+
+7. **Log findings to midden:**
+
+   For each baseline established, run using the Bash tool with description "Logging baseline...":
+   ```bash
+   bash .aether/aether-utils.sh midden-write "performance" "Baseline: {baseline.operation} ({baseline.complexity}) at {baseline.file}:{baseline.line}" "measurer"
+   ```
+
+   For each bottleneck identified, run using the Bash tool with description "Logging bottleneck...":
+   ```bash
+   bash .aether/aether-utils.sh midden-write "performance" "Bottleneck: {bottleneck.description} ({bottleneck.severity}) at {bottleneck.location}" "measurer"
+   ```
+
+   For each recommendation, run using the Bash tool with description "Logging recommendation...":
+   ```bash
+   bash .aether/aether-utils.sh midden-write "performance" "Recommendation (P{rec.priority}): {rec.change} - {rec.estimated_improvement}" "measurer"
+   ```
+
+8. **Display summary and store for synthesis:**
+
+   Display:
+   ```
+   📊 Measurer complete — {baseline_count} baselines, {bottleneck_count} bottlenecks logged to midden
+   ```
+
+   Store Measurer results in synthesis data structure:
+   - Add `performance` object to synthesis JSON with: `baselines_established`, `bottlenecks_identified`, `recommendations`
+   - Include in BUILD SUMMARY display: `📊 Measurer: {baseline_count} baselines established, {bottleneck_count} bottlenecks identified`
+
+9. **Continue to Chaos Ant:**
+
+   Proceed to Step 5.6 (Chaos Ant) regardless of Measurer results — Measurer is strictly non-blocking.
+
+### Step 5.6: Spawn Chaos Ant for Resilience Testing
+
+**DEPTH CHECK: Skip if colony depth is not "full".**
+
+- If `colony_depth` is not "full": Display `Chaos testing skipped (depth: {colony_depth})` and skip to Step 5.7 (Process Chaos Ant Results -- which will be a no-op).
+- If `colony_depth` is "full": Proceed with existing Chaos spawn logic below.
+
+**After the Watcher completes, spawn a Chaos Ant to probe the phase work for edge cases and boundary conditions.**
+
+Generate a chaos ant name and dispatch:
+Run using the Bash tool with description "Naming chaos ant...": `bash .aether/aether-utils.sh generate-ant-name "chaos"` (store as `{chaos_name}`)
+Run using the Bash tool with description "Loading existing flags...": `bash .aether/aether-utils.sh flag-list --phase {phase_number}`
+Parse the result and extract unresolved flag titles into a list: `{existing_flag_titles}` (comma-separated titles from `.result.flags[].title`). If no flags exist, set `{existing_flag_titles}` to "None".
+Run using the Bash tool with description "Dispatching chaos ant...": `bash .aether/aether-utils.sh spawn-log "Queen" "chaos" "{chaos_name}" "Resilience testing of Phase {id} work"`
+
+**Announce the resilience testing wave:**
+```
+──── 🎲🐜 Spawning {chaos_name} — resilience testing ────
+```
+
+> **Platform note**: In Claude Code, use `Task tool with subagent_type`. In OpenCode, use the equivalent agent spawning mechanism for your platform (e.g., invoke the agent definition from `.opencode/agents/`).
+
+Spawn the Chaos Ant using Task tool with `subagent_type="aether-chaos"`, include `description: "🎲 Chaos {Chaos-Name}: Resilience testing"` (DO NOT use run_in_background - task blocks until complete):
+# FALLBACK: If "Agent type not found", use general-purpose and inject role: "You are a Chaos Ant - resilience tester that probes edge cases and boundary conditions."
+
+**Chaos Ant Prompt (CLEAN OUTPUT):**
+```
+You are {Chaos-Name}, a 🎲🐜 Chaos Ant.
+
+Test Phase {id} work for edge cases and boundary conditions.
+
+Files to test:
+- {list from builder results}
+
+Skip these known issues: {existing_flag_titles}
+
+**IMPORTANT:** When using the Bash tool for activity calls, always include a description parameter:
+- activity-log calls → "Logging {action}..."
+- pheromone-read calls → "Checking colony signals..."
+
+Use colony-flavored language, 4-8 words, trailing ellipsis.
+
+Rules:
+- Max 5 scenarios
+- Read-only (don't modify code)
+- Focus: edge cases, boundaries, error handling
+
+Count your total tool calls (Read + Grep + Edit + Bash + Write) and report as tool_count.
+
+Return ONLY this JSON:
+{"ant_name": "{Chaos-Name}", "scenarios_tested": 5, "findings": [{"id": 1, "category": "edge_case|boundary|error_handling", "severity": "critical|high|medium|low", "title": "...", "description": "..."}], "overall_resilience": "strong|moderate|weak", "tool_count": 0, "summary": "..."}
+```
+
+### Step 5.7: Process Chaos Ant Results
+
+**Task call returns results directly (no TaskOutput needed).**
+
+**Parse the Chaos Ant's JSON response:** findings, overall_resilience, summary
+
+**Display Chaos completion line:**
+```
+🎲 {Chaos-Name}: Resilience testing ({tool_count} tools) ✓
+```
+
+**Store results for synthesis in Step 5.9**
+
+**Flag critical/high findings:**
+
+If any findings have severity `"critical"` or `"high"`:
+Run using the Bash tool with description "Flagging {finding.title}...": `bash .aether/aether-utils.sh flag-add "blocker" "{finding.title}" "{finding.description}" "chaos-testing" {phase_number} && bash .aether/aether-utils.sh activity-log "FLAG" "Chaos" "Created blocker: {finding.title}"`
+
+**Log resilience finding to midden (MEM-02):**
+
+For each critical/high finding, run using the Bash tool with description "Logging resilience finding...":
+```bash
+colony_name=$(bash .aether/aether-utils.sh colony-name 2>/dev/null | jq -r '.result.name // ""')
+[[ -z "$colony_name" ]] && colony_name="unknown"
+phase_num=$(jq -r '.phase.number // "unknown"' .aether/data/COLONY_STATE.json 2>/dev/null || echo "unknown")
+
+# Append to build-failures.md
+cat >> .aether/midden/build-failures.md << EOF
+- timestamp: "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
+  phase: ${phase_num}
+  colony: "${colony_name}"
+  worker: "${chaos_name}"
+  test_context: "resilience"
+  what_failed: "${finding.title}"
+  why: "${finding.description}"
+  what_worked: null
+  severity: "${finding.severity}"
+EOF
+
+# Write to structured midden for threshold detection (MID-01)
+bash .aether/aether-utils.sh midden-write "resilience" "Chaos finding: ${finding.title} (${finding.severity})" "chaos" 2>/dev/null || true
+
+# Capture resilience failure in memory pipeline (observe + pheromone + auto-promotion)
+bash .aether/aether-utils.sh memory-capture \
+  "failure" \
+  "Resilience issue found: ${finding.title} (${finding.severity})" \
+  "failure" \
+  "worker:chaos" 2>/dev/null || true
+```
+
+Log chaos ant completion:
+Run using the Bash tool with description "Recording chaos completion...": `bash .aether/aether-utils.sh spawn-complete "{chaos_name}" "completed" "{summary}"`
+
+**Success capture: chaos resilience (MEM-01):**
+
+If `overall_resilience` is `"strong"`:
+
+Run using the Bash tool with description "Capturing chaos resilience success...":
+```bash
+bash .aether/aether-utils.sh memory-capture \
+  "success" \
+  "Chaos resilience strong: ${summary}" \
+  "pattern" \
+  "worker:chaos" 2>/dev/null || true
+```
+
+This records the resilience success in learning-observations.json via the existing memory pipeline (observe + pheromone + auto-promotion + rolling-summary).
+
+### Step 5.8: Create Flags for Verification Failures
+
+If the Watcher reported `verification_passed: false` or `recommendation: "fix_required"`:
+
+For each issue in `issues_found`:
+Run using the Bash tool with description "Flagging {issue_title}...": `bash .aether/aether-utils.sh flag-add "blocker" "{issue_title}" "{issue_description}" "verification" {phase_number} && bash .aether/aether-utils.sh activity-log "FLAG" "Watcher" "Created blocker: {issue_title}"`
+
+**Log verification failure to midden (MEM-02):**
+
+After flagging each issue, run using the Bash tool with description "Logging verification failure...":
+```bash
+colony_name=$(bash .aether/aether-utils.sh colony-name 2>/dev/null | jq -r '.result.name // ""')
+[[ -z "$colony_name" ]] && colony_name="unknown"
+phase_num=$(jq -r '.phase.number // "unknown"' .aether/data/COLONY_STATE.json 2>/dev/null || echo "unknown")
+
+# Append to test-failures.md
+cat >> .aether/midden/test-failures.md << EOF
+- timestamp: "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
+  phase: ${phase_num}
+  colony: "${colony_name}"
+  worker: "${watcher_name}"
+  test_context: "verification"
+  what_failed: "${issue_title}"
+  why: "${issue_description}"
+  what_worked: null
+  severity: "high"
+EOF
+
+# Write to structured midden for threshold detection (MID-01)
+bash .aether/aether-utils.sh midden-write "verification" "Watcher verification failed: ${issue_title}" "watcher" 2>/dev/null || true
+
+# Capture verification failure in memory pipeline (observe + pheromone + auto-promotion)
+bash .aether/aether-utils.sh memory-capture \
+  "failure" \
+  "Verification failed: ${issue_title} - ${issue_description}" \
+  "failure" \
+  "worker:watcher" 2>/dev/null || true
+```
+
+This ensures verification failures are persisted as blockers that survive context resets. Chaos Ant findings are flagged in Step 5.7.