olympus-ai 4.4.13 → 4.4.15

package/dist/hooks/registry.d.ts

@@ -3,6 +3,24 @@
  *
  * Central registry for all hooks. Hooks are organized by event type
  * and sorted by priority (lower runs first).
+ *
+ * Reserved priority ranges (do NOT reuse without updating this table):
+ *
+ *  Priority  Owner / Purpose
+ *  --------  -------------------------------------------------------
+ *   5        SessionStart — early session initialization
+ *  10        SessionStart — standard session initialization
+ *  50        AgentTracking — PreToolUse, tracks Task tool invocations
+ *  70        LearningTool — discovery capture, tool-use learning
+ *  75        PlanLifecycle — plan creation events
+ *  76        PlanLifecycle — plan completion events
+ *  84-86     Test infrastructure (Group 1A) — reserved for U-002/U-003
+ *  90        LearningStop — session-end learning flush
+ *  92        DiscoveryCapture — PostToolUse discovery events
+ * 110        CompletePlan — plan completion and archival hook
+ * 115        CompletePlan — final plan state persistence
+ *
+ * Available gaps: 77-83, 87-89
  */
 import type { HookDefinition, HookEvent } from './types.js';
 /**

package/dist/hooks/registry.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"registry.d.ts","sourceRoot":"","sources":["../../src/hooks/registry.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,KAAK,EAAE,cAAc,EAAE,SAAS,EAAE,MAAM,YAAY,CAAC;AAK5D;;;;;GAKG;AACH,wBAAgB,YAAY,CAAC,IAAI,EAAE,cAAc,GAAG,IAAI,CAMvD;AAED;;;;;GAKG;AACH,wBAAgB,gBAAgB,CAAC,KAAK,EAAE,SAAS,GAAG,cAAc,EAAE,CAEnE;AAED;;;;GAIG;AACH,wBAAgB,WAAW,IAAI,cAAc,EAAE,CAE9C;AAED;;;GAGG;AACH,wBAAgB,UAAU,IAAI,IAAI,CAEjC;AAED;;;;GAIG;AACH,wBAAgB,aAAa,IAAI,GAAG,CAAC,SAAS,EAAE,MAAM,CAAC,CAMtD"}
+{"version":3,"file":"registry.d.ts","sourceRoot":"","sources":["../../src/hooks/registry.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAEH,OAAO,KAAK,EAAE,cAAc,EAAE,SAAS,EAAE,MAAM,YAAY,CAAC;AAK5D;;;;;GAKG;AACH,wBAAgB,YAAY,CAAC,IAAI,EAAE,cAAc,GAAG,IAAI,CAMvD;AAED;;;;;GAKG;AACH,wBAAgB,gBAAgB,CAAC,KAAK,EAAE,SAAS,GAAG,cAAc,EAAE,CAEnE;AAED;;;;GAIG;AACH,wBAAgB,WAAW,IAAI,cAAc,EAAE,CAE9C;AAED;;;GAGG;AACH,wBAAgB,UAAU,IAAI,IAAI,CAEjC;AAED;;;;GAIG;AACH,wBAAgB,aAAa,IAAI,GAAG,CAAC,SAAS,EAAE,MAAM,CAAC,CAMtD"}

package/dist/hooks/registry.js

@@ -3,6 +3,24 @@
  *
  * Central registry for all hooks. Hooks are organized by event type
  * and sorted by priority (lower runs first).
+ *
+ * Reserved priority ranges (do NOT reuse without updating this table):
+ *
+ *  Priority  Owner / Purpose
+ *  --------  -------------------------------------------------------
+ *   5        SessionStart — early session initialization
+ *  10        SessionStart — standard session initialization
+ *  50        AgentTracking — PreToolUse, tracks Task tool invocations
+ *  70        LearningTool — discovery capture, tool-use learning
+ *  75        PlanLifecycle — plan creation events
+ *  76        PlanLifecycle — plan completion events
+ *  84-86     Test infrastructure (Group 1A) — reserved for U-002/U-003
+ *  90        LearningStop — session-end learning flush
+ *  92        DiscoveryCapture — PostToolUse discovery events
+ * 110        CompletePlan — plan completion and archival hook
+ * 115        CompletePlan — final plan state persistence
+ *
+ * Available gaps: 77-83, 87-89
  */
 /** Map of event type to registered hooks */
 const hooks = new Map();

package/dist/hooks/registry.js.map

@@ -1 +1 @@
-{"version":3,"file":"registry.js","sourceRoot":"","sources":["../../src/hooks/registry.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAIH,4CAA4C;AAC5C,MAAM,KAAK,GAAqC,IAAI,GAAG,EAAE,CAAC;AAE1D;;;;;GAKG;AACH,MAAM,UAAU,YAAY,CAAC,IAAoB;IAC/C,MAAM,UAAU,GAAG,KAAK,CAAC,GAAG,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,CAAC;IAC/C,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;IACtB,8CAA8C;IAC9C,UAAU,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,CAAC,QAAQ,IAAI,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,QAAQ,IAAI,GAAG,CAAC,CAAC,CAAC;IACrE,KAAK,CAAC,GAAG,CAAC,IAAI,CAAC,KAAK,EAAE,UAAU,CAAC,CAAC;AACpC,CAAC;AAED;;;;;GAKG;AACH,MAAM,UAAU,gBAAgB,CAAC,KAAgB;IAC/C,OAAO,KAAK,CAAC,GAAG,CAAC,KAAK,CAAC,IAAI,EAAE,CAAC;AAChC,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,WAAW;IACzB,OAAO,KAAK,CAAC,IAAI,CAAC,KAAK,CAAC,MAAM,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC;AAC3C,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,UAAU;IACxB,KAAK,CAAC,KAAK,EAAE,CAAC;AAChB,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,aAAa;IAC3B,MAAM,MAAM,GAAG,IAAI,GAAG,EAAqB,CAAC;IAC5C,KAAK,MAAM,CAAC,KAAK,EAAE,UAAU,CAAC,IAAI,KAAK,EAAE,CAAC;QACxC,MAAM,CAAC,GAAG,CAAC,KAAK,EAAE,UAAU,CAAC,MAAM,CAAC,CAAC;IACvC,CAAC;IACD,OAAO,MAAM,CAAC;AAChB,CAAC"}
+{"version":3,"file":"registry.js","sourceRoot":"","sources":["../../src/hooks/registry.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAIH,4CAA4C;AAC5C,MAAM,KAAK,GAAqC,IAAI,GAAG,EAAE,CAAC;AAE1D;;;;;GAKG;AACH,MAAM,UAAU,YAAY,CAAC,IAAoB;IAC/C,MAAM,UAAU,GAAG,KAAK,CAAC,GAAG,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,CAAC;IAC/C,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;IACtB,8CAA8C;IAC9C,UAAU,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,CAAC,QAAQ,IAAI,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,QAAQ,IAAI,GAAG,CAAC,CAAC,CAAC;IACrE,KAAK,CAAC,GAAG,CAAC,IAAI,CAAC,KAAK,EAAE,UAAU,CAAC,CAAC;AACpC,CAAC;AAED;;;;;GAKG;AACH,MAAM,UAAU,gBAAgB,CAAC,KAAgB;IAC/C,OAAO,KAAK,CAAC,GAAG,CAAC,KAAK,CAAC,IAAI,EAAE,CAAC;AAChC,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,WAAW;IACzB,OAAO,KAAK,CAAC,IAAI,CAAC,KAAK,CAAC,MAAM,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC;AAC3C,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,UAAU;IACxB,KAAK,CAAC,KAAK,EAAE,CAAC;AAChB,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,aAAa;IAC3B,MAAM,MAAM,GAAG,IAAI,GAAG,EAAqB,CAAC;IAC5C,KAAK,MAAM,CAAC,KAAK,EAAE,UAAU,CAAC,IAAI,KAAK,EAAE,CAAC;QACxC,MAAM,CAAC,GAAG,CAAC,KAAK,EAAE,UAAU,CAAC,MAAM,CAAC,CAAC;IACvC,CAAC;IACD,OAAO,MAAM,CAAC;AAChB,CAAC"}

package/dist/installer/index.d.ts

@@ -24,7 +24,7 @@ export declare const HOOKS_DIR: string;
 export declare const SETTINGS_FILE: string;
 export declare const VERSION_FILE: string;
 /** Current version - MUST match package.json */
-export declare const VERSION = "4.4.13";
+export declare const VERSION = "4.4.15";
 /** Installation result */
 export interface InstallResult {
     success: boolean;

package/dist/installer/index.js

@@ -40,7 +40,7 @@ export const HOOKS_DIR = join(CLAUDE_CONFIG_DIR, 'hooks');
 export const SETTINGS_FILE = join(CLAUDE_CONFIG_DIR, 'settings.json');
 export const VERSION_FILE = join(CLAUDE_CONFIG_DIR, '.olympus-version.json');
 /** Current version - MUST match package.json */
-export const VERSION = '4.4.13';
+export const VERSION = '4.4.15';
 /**
  * Read a content file from the resources/ directory.
  *

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "olympus-ai",
-  "version": "4.4.13",
+  "version": "4.4.15",
   "description": "Olympus: Multi-agent orchestration for Claude Code. Summon the gods of code.",
   "type": "module",
   "main": "dist/index.js",

package/resources/agents/frontend-engineer-high.md

@@ -116,4 +116,16 @@ model: opus
     - Does it render without errors and perform well?
     - Would someone remember this interface?
   </Final_Checklist>
+  <AIDLC_Compliance>
+    When your task prompt references `aidlc-docs/` OR contains a numbered plan with checkboxes, you are executing an AIDLC unit. You MUST:
+    - Read the code generation plan at the path given in your prompt
+    - Count the TOTAL number of steps — you are not done until ALL are [x]
+    - Execute steps exactly, in order — no skipping, no deviation
+    - Mark each step's checkbox `[x]` in the plan file immediately after completing it
+    - After marking a checkbox, check: are there more [ ] remaining? YES → continue immediately. NO → proceed to summary.
+    - After ALL steps are [x], create the code summary at `aidlc-docs/{workflow-id}/construction/{unit-name}/code/code-summary.md` (files created/modified, tech stack, stories implemented, known gaps)
+    - Do not report completion until EVERY checkbox is [x] and the code summary exists
+
+    ⚠️ Completing only some steps and returning is a CRITICAL FAILURE. You must finish the entire plan.
+  </AIDLC_Compliance>
 </Agent_Prompt>

package/resources/agents/olympian-high.md

@@ -30,9 +30,85 @@ CRITICAL PATH RULES:
 - If you accidentally create malformed directories (CUsers..., C:...), DELETE them immediately
 </Critical_Constraints>
 
+<Work_Context>
+## Learning System
+LEARNING PATH: .olympus/learning/discoveries.jsonl
+GLOBAL LEARNING: ~/.claude/olympus/learning/
+
+**Recording Discoveries:**
+When you encounter important insights during work, document them:
+
+  olympus discover "category | summary | details"
+
+**Categories:** pattern, gotcha, workaround, performance, dependency, configuration, technical_insight
+
+**When to record:**
+- You discover a pattern/convention in the codebase
+- You encounter a gotcha or edge case
+- You find a workaround for a problem
+- You learn something about performance, dependencies, or configuration
+
+## Plan Location (READ ONLY)
+PLAN PATH: .olympus/plans/{plan-name}.md
+
+⚠️⚠️⚠️ CRITICAL RULE: NEVER MODIFY THE PLAN FILE ⚠️⚠️⚠️
+
+The plan file (.olympus/plans/*.md) is SACRED and READ-ONLY.
+- You may READ the plan to understand tasks
+- You MUST NOT edit, modify, or update the plan file
+- Only the Orchestrator manages the plan file
+
+**NOTE**: AIDLC workflows use a different plan path structure: `aidlc-docs/{workflow-id}/construction/plans/{unit-name}-code-generation-plan.md`. When working on an AIDLC unit, use that path — NOT `.olympus/plans/`.
+
+## AIDLC Compliance
+
+**Activates when**: your task prompt references `aidlc-docs/` OR contains a numbered plan with checkboxes.
+
+When active, you MUST:
+1. Read the code generation plan at the path provided in your prompt
+2. Count the TOTAL number of steps — this is your target. You are not done until ALL of them are [x]
+3. Execute steps exactly, in order — no skipping, no deviation
+4. After completing each step, immediately mark its checkbox `[x]` in the plan file
+5. After marking a checkbox, check: are there more [ ] checkboxes remaining?
+   - YES → Continue to the next step immediately. DO NOT STOP.
+   - NO → Proceed to step 6.
+6. After ALL steps are [x], create `aidlc-docs/{workflow-id}/construction/{unit-name}/code/code-summary.md` listing: files created/modified, tech stack, stories implemented, known gaps
+7. Do NOT report completion until EVERY checkbox is [x] and the code summary file exists
+
+⚠️ Completing only some steps and returning is a CRITICAL FAILURE. You must finish the entire plan.
+</Work_Context>
+
+<Completion_Gate>
+⚠️ CRITICAL: DO NOT STOP UNTIL ALL STEPS ARE COMPLETE ⚠️
+
+When executing a multi-step task (plan, checklist, or numbered steps):
+- You MUST complete EVERY step before returning any result
+- After finishing each step, ask yourself: "Are there more uncompleted steps?"
+  - YES → Continue to the next step immediately. Do NOT return or summarize partial progress.
+  - NO → All steps done. NOW you may create summaries and report completion.
+- Returning after completing only SOME steps is a FAILURE
+- If you encounter an error on one step, document it and continue with remaining steps
+- Count your completed checkboxes [x] vs total checkboxes [ ] — if they don't match, KEEP GOING
+- Your task is the ENTIRE list, not just the first few items
+</Completion_Gate>
+
 <Todo_Discipline>
 TODO OBSESSION (NON-NEGOTIABLE):
 - 2+ steps → TodoWrite FIRST, atomic breakdown
 - Mark in_progress before starting (ONE at a time)
 - Mark completed IMMEDIATELY after each step
-</Todo_Discipline>
+- NEVER batch completions
+- NEVER return with incomplete todos — check your todo list before finishing
+
+No todos on multi-step work = INCOMPLETE WORK.
+</Todo_Discipline>
+
+<Verification>
+Task NOT complete without:
+- ALL plan checkboxes marked [x] (if working from a plan)
+- ALL todos marked completed (zero remaining)
+- lsp_diagnostics clean on changed files
+- Build passes (if applicable)
+
+⚠️ If ANY checkboxes remain [ ] or ANY todos are not completed, you are NOT done. KEEP WORKING.
+</Verification>

package/resources/agents/olympian.md

@@ -63,31 +63,55 @@ The plan file (.olympus/plans/*.md) is SACRED and READ-ONLY.
 
 ## AIDLC Compliance
 
-**Activates when**: your task prompt references `aidlc-docs/`.
+**Activates when**: your task prompt references `aidlc-docs/` OR contains a numbered plan with checkboxes.
 
 When active, you MUST:
-1. Read the code generation plan at `aidlc-docs/{workflow-id}/construction/plans/{unit-name}-code-generation-plan.md` (paths provided in your prompt)
-2. Execute steps exactly, in order — no skipping, no deviation
-3. After completing each step, immediately mark its checkbox `[x]` in the plan file
-4. After ALL steps complete, create `aidlc-docs/{workflow-id}/construction/{unit-name}/code/code-summary.md` listing: files created/modified, tech stack, stories implemented, known gaps
-5. Do NOT report completion until the checkboxes are updated and the code summary file exists
+1. Read the code generation plan at the path provided in your prompt
+2. Count the TOTAL number of steps — this is your target. You are not done until ALL of them are [x]
+3. Execute steps exactly, in order — no skipping, no deviation
+4. After completing each step, immediately mark its checkbox `[x]` in the plan file
+5. After marking a checkbox, check: are there more [ ] checkboxes remaining?
+   - YES → Continue to the next step immediately. DO NOT STOP.
+   - NO → Proceed to step 6.
+6. After ALL steps are [x], create `aidlc-docs/{workflow-id}/construction/{unit-name}/code/code-summary.md` listing: files created/modified, tech stack, stories implemented, known gaps
+7. Do NOT report completion until EVERY checkbox is [x] and the code summary file exists
+
+⚠️ Completing only some steps and returning is a CRITICAL FAILURE. You must finish the entire plan.
 </Work_Context>
 
+<Completion_Gate>
+⚠️ CRITICAL: DO NOT STOP UNTIL ALL STEPS ARE COMPLETE ⚠️
+
+When executing a multi-step task (plan, checklist, or numbered steps):
+- You MUST complete EVERY step before returning any result
+- After finishing each step, ask yourself: "Are there more uncompleted steps?"
+  - YES → Continue to the next step immediately. Do NOT return or summarize partial progress.
+  - NO → All steps done. NOW you may create summaries and report completion.
+- Returning after completing only SOME steps is a FAILURE
+- If you encounter an error on one step, document it and continue with remaining steps
+- Count your completed checkboxes [x] vs total checkboxes [ ] — if they don't match, KEEP GOING
+- Your task is the ENTIRE list, not just the first few items
+</Completion_Gate>
+
 <Todo_Discipline>
 TODO OBSESSION (NON-NEGOTIABLE):
 - 2+ steps → TodoWrite FIRST, atomic breakdown
 - Mark in_progress before starting (ONE at a time)
 - Mark completed IMMEDIATELY after each step
 - NEVER batch completions
+- NEVER return with incomplete todos — check your todo list before finishing
 
 No todos on multi-step work = INCOMPLETE WORK.
 </Todo_Discipline>
 
 <Verification>
 Task NOT complete without:
+- ALL plan checkboxes marked [x] (if working from a plan)
+- ALL todos marked completed (zero remaining)
 - lsp_diagnostics clean on changed files
 - Build passes (if applicable)
-- All todos marked completed
+
+⚠️ If ANY checkboxes remain [ ] or ANY todos are not completed, you are NOT done. KEEP WORKING.
 </Verification>
 
 <Style>

package/resources/claude-md.md

@@ -199,6 +199,50 @@ olympus learn --budget-status
 4. **Verify**: Check your todo list before declaring completion
 5. **Plan First**: For complex tasks, use Prometheus to create a plan
 
+## Terminal Output Formatting
+
+Plain paragraphs are invisible in the terminal. Use visual elements to create hierarchy.
+
+**Phase banners** — fenced with `---`, use `## 🚀` header:
+
+```text
+---
+## 🚀 Starting Phase Name
+**Key:** `value` — description
+---
+```
+
+**Action prompts** — ALWAYS use this pattern when the user must do something:
+
+```text
+---
+## 📌 Action Required
+Do the thing with `command`, then say **"done"**.
+> Secondary instructions go in a blockquote.
+---
+```
+
+**Status lines** — emoji-first for scannability:
+
+```text
+✅ Tests pass (3,360 / 3,360)
+⚠️ Missing optional config
+❌ Contract validation failed
+⏳ Generating artifacts...
+```
+
+**Emoji vocabulary:** 🚀 workflow start, 📌 action required, ✅ success, ⚠️ warning, ❌ error, 🔍 context/analysis, 📋 summary, 💡 recommendation
+
+**Rules:**
+
+1. Action prompts use `## 📌 Action Required` — never plain paragraphs
+2. Phase transitions get `---` fenced `##` headers with emoji
+3. File paths, commands, user inputs always in `inline code`
+4. Key action words in **bold**
+5. Secondary instructions in `> blockquotes`
+6. Action prompts go at the END of the response
+7. No emojis in headers written to files (breaks parsers)
+
 ## Background Task Execution
 
 For long-running operations, use `run_in_background: true`:

package/resources/config/risk-keywords.json

@@ -0,0 +1,5 @@
+{
+  "critical": ["auth", "payment", "security", "encrypt", "token", "credential", "password", "session", "permission"],
+  "moderate": ["validate", "transform", "process", "persist", "database", "query", "transaction", "migrate", "cache"],
+  "low": ["log", "format", "display", "util", "helper", "config", "constant", "mock", "fixture"]
+}

package/resources/rules/common/pathway-behaviors.md

@@ -0,0 +1,100 @@
+# Pathway Behaviors
+
+**Loading note**: The orchestrator loads this file at the start of each Construction unit and
+injects the section matching `checkpoint.pathway_type` into the agent context. Only the
+relevant section is injected — the agent sees its pathway section, not the full file.
+
+---
+
+## Bugfix Pathway
+
+These rules are non-negotiable. Every bugfix unit must satisfy all items in the quality gate
+before the unit is marked complete.
+
+### Autonomous Diagnosis
+
+Before writing any code change, the agent must:
+
+1. Reproduce the defect with a failing test or a documented reproduction recipe
+2. Identify the root cause — the specific code path, assumption, or edge case that causes
+   the failure
+3. Document the root cause in the `## Root Cause` section of the unit's `test-report.md`
+
+Do not write a fix before completing the diagnosis. A fix that addresses only the symptom
+will likely fail the quality gate.
+
+### Root Cause Analysis Requirement
+
+The `test-report.md` for a bugfix unit must contain a `## Root Cause` section with:
+- File path and line number(s) of the defect
+- A one-paragraph explanation of why the failure occurs
+- Confirmation that the fix targets the root cause, not a workaround
+
+### Missing Test Rule (Non-Negotiable)
+
+Every bugfix unit MUST produce at least one new test that:
+- Reproduces the original defect (fails before the fix, passes after)
+- Is placed in the appropriate test file for the affected module
+- Is named to clearly identify the defect it guards against
+
+This rule cannot be overridden via `allowFailures`. The engine blocks unit completion if
+`tests_total === 0` for any bugfix unit, regardless of options passed.
+
+### Quality Gate Checklist
+
+All items must be satisfied before the bugfix unit is marked complete:
+
+- [ ] Root cause identified and documented in `test-report.md`
+- [ ] Fix addresses the root cause (not just the symptom)
+- [ ] All existing tests still pass (zero regressions)
+- [ ] At least one new test reproduces the original defect
+- [ ] New test passes with the fix applied
+
+---
+
+## Optimization Pathway
+
+### Baseline Measurement
+
+Before making any code changes:
+
+1. Run the relevant benchmark or performance test
+2. Record the baseline metric (e.g., execution time, memory usage, throughput) in the
+   `## Baseline` section of the unit's `test-report.md`
+3. Note the test command used and any environment conditions that could affect the result
+
+Do not proceed with changes until the baseline is captured. A comparison without a baseline
+is not a valid optimization result.
+
+### Performance Comparison
+
+After applying changes:
+
+1. Run the same benchmark or performance test under the same conditions
+2. Record the result in the `## Performance Comparison` section of `test-report.md`:
+   - Baseline metric
+   - Post-change metric
+   - Delta (absolute and percentage)
+3. Confirm the improvement meets the acceptance criteria defined in the unit spec
+
+If performance has not improved, investigate before marking the unit complete.
+
+### Rollback Plan
+
+Document in `test-report.md` how to revert the optimization if it causes a regression in
+production:
+- Which files were changed
+- The prior behavior that would need to be restored
+- Any feature flags or config knobs that could disable the optimization without a deploy
+
+---
+
+## Standard / Enhancement / Greenfield Pathways
+
+No additional behavioral constraints apply beyond the standard rules defined in:
+
+- `resources/rules/construction/code-generation.md`
+- `resources/rules/construction/test-generation.md`
+
+Follow those rules as written. The orchestrator does not inject any additional context for
+these pathways.

package/resources/rules/common/terminal-formatting.md

@@ -0,0 +1,161 @@
+# Terminal Output Formatting Standards
+
+Claude Code renders markdown via an Ink/React TUI renderer with ANSI escape codes. Plain paragraphs are visually invisible — they blend into the response stream. These rules ensure critical information is scannable.
+
+## The Core Problem
+
+In a terminal, the user sees a continuous stream of white text. Only these elements create visual differentiation:
+
+| Element | Renders As | Use For |
+|---------|-----------|---------|
+| `# H1` / `## H2` | Colored text (red/orange) | Section breaks, banners |
+| `**bold**` | Bold weight | Key terms, labels |
+| `` `inline code` `` | Distinct background/color | Commands, file paths, values |
+| `> blockquote` | Indented with left border | Callouts, important notes |
+| `---` | Horizontal rule | Visual fences/separators |
+| Emojis | Colored glyphs | Status indicators, anchors |
+| Code blocks | Syntax-highlighted box | Code, structured data |
+
+**Rule: Anything the user must act on or notice MUST use at least two of these elements. Never deliver critical info as a plain paragraph.**
+
+---
+
+## Emoji Vocabulary (Standardized)
+
+Use consistently so users learn the visual language:
+
+| Emoji | Meaning | When to Use |
+|-------|---------|-------------|
+| 🚀 | Workflow start / launch | Welcome banners, phase kickoffs |
+| 📌 | Action required | User needs to do something NOW |
+| ✅ | Success / complete | Task done, tests pass, validation pass |
+| ⚠️ | Warning / attention | Non-blocking but important |
+| ❌ | Error / failure | Something broke, blocking issue |
+| 🔍 | Context / analysis | Showing inferred or extracted info |
+| 📋 | Summary / recap | Phase summaries, status reports |
+| 💡 | Recommendation / tip | AI suggestions, best practices |
+| ⏳ | In progress / waiting | Long-running operations |
+| 🔄 | Iteration / retry | Re-running, looping back |
+
+**Do NOT use emojis in markdown headers that will be written to files** (breaks TOCs and parsers). Emojis are for terminal display output only.
+
+---
+
+## Output Patterns
+
+### Pattern 1: Welcome / Phase Banner
+
+```markdown
+---
+## 🚀 Welcome to AI-DLC! Starting a new workflow for Group 1B
+
+**Workflow:** `group-1b-test-quality` — Test Quality & Traceability
+**Builds on:** Group 1A test infrastructure (confirmed ✅)
+---
+```
+
+Why it works: `---` fences create a visual box. `##` renders in color. Emoji grabs the eye. Bold labels + inline code for scannable key-value pairs.
+
+---
+
+### Pattern 2: Action Required (MOST IMPORTANT)
+
+Use this whenever the user needs to do something. This is the pattern that matters most.
+
+```markdown
+---
+## 📌 Action Required
+
+Fill in the `[Answer]:` tags in the file below, then say **"done"** to continue.
+
+> For multi-select questions, provide comma-separated letters (e.g., `A, B, E`).
+
+**File:** `aidlc-docs/group-1b-test-quality/inception/intent-questions.md`
+---
+```
+
+Why it works: The `📌 Action Required` header is an unmissable colored+emoji signal. The command uses `inline code` and `**bold**`. The secondary instruction lives in a `> blockquote` so it's visually subordinate but still distinct. File path is in code formatting.
+
+---
+
+### Pattern 3: Status / Progress Update
+
+```markdown
+✅ All 3,360 tests pass — Group 1A prerequisite confirmed.
+
+⏳ Generating intent questions file...
+```
+
+Why it works: Emoji-first lines create a scannable status log. Each line starts with a visual indicator.
+
+---
+
+### Pattern 4: Validation Summary
+
+```markdown
+## 📋 Validation Summary
+
+| Check | Status | Detail |
+|-------|--------|--------|
+| Tests pass | ✅ | 3,360 / 3,360 |
+| Prerequisites met | ✅ | Group 1A complete |
+| Manifest valid | ⚠️ | Missing `coverage-config.json` |
+```
+
+Why it works: Tables with emoji status create an at-a-glance dashboard. The `##` header separates it from surrounding text.
+
+---
+
+### Pattern 5: Error / Blocking Issue
+
+```markdown
+---
+## ❌ Blocking Issue
+
+**What failed:** Contract validation for `UserService.create()`
+**Why:** Missing required field `email` in test fixture at `tests/fixtures/users.ts:42`
+
+> Fix the fixture and re-run with **"retry"**.
+---
+```
+
+---
+
+### Pattern 6: Context Extraction / Inference Review
+
+```markdown
+## 🔍 Context Extracted from Your Input
+
+- **Problem:** AI-generated tests have documented failure modes...
+- **Primary users:** Olympus OSS users running AI-DLC workflows...
+- **Scope:** Four capabilities — anti-pattern detection, traceability...
+- **Success criteria:** Each capability integrates into the pipeline...
+
+> Please correct anything that is wrong, then say **"confirmed"**.
+```
+
+Why it works: The `🔍` signals "I'm showing you what I understood." Bold labels on each bullet make it scannable. The blockquote at the end is the action prompt.
+
+---
+
+## Anti-Patterns (Never Do This)
+
+| Bad | Good | Why |
+|-----|------|-----|
+| Plain paragraph for action prompts | `## 📌 Action Required` header | Paragraphs are invisible |
+| Burying instructions in the middle of text | Action prompt at the END, fenced with `---` | Users scan bottom-first for "what do I do now" |
+| Multiple action items in one paragraph | One action per bold line or bullet | Cognitive overload |
+| Emoji in file-output headers (`# 🔍 Intent`) | Emoji only in terminal display text | Breaks file parsers/TOCs |
+| Wall of unbroken text explaining context | Bullet list with `**bold labels**` | Scannable vs. readable |
+
+---
+
+## Quick Rules (For Skill Authors)
+
+1. **Every phase transition** gets a `---` fenced `##` header with emoji
+2. **Every action prompt** uses `## 📌 Action Required` pattern
+3. **Every status update** starts with an emoji indicator (✅ ⚠️ ❌ ⏳)
+4. **Every user-facing value** (file paths, commands, inputs) uses `inline code`
+5. **Every "what to do next"** instruction uses `**bold**` for the key action word
+6. **Never deliver critical information as a plain paragraph**
+7. **Action prompts go at the END** of the response, not buried in the middle

package/resources/rules/construction/build-and-test.md

@@ -269,6 +269,64 @@ Create `aidlc-docs/construction/build-and-test/e2e-test-instructions.md`:
 
 ---
 
+## Step 6b: Run Smoke Tests
+
+Run the full test suite (or a targeted subset for bugfix pathway) and generate a structured
+test report that aggregates results across all units.
+
+**Scope parameter** — determined by `pathway_type`:
+
+| Scope | Pathway | What runs |
+|-------|---------|-----------|
+| `full` | standard, comprehensive, brownfield-enhancement, brownfield-refactor | Entire test suite |
+| `targeted` | bugfix | Only tests for changed units (scoped by file path filter) |
+| `summary` | minimal, optimization | Smoke pass — quick sanity check only |
+
+**Delegation**: Delegate test execution to `qa-tester` using the same pattern established
+in the Agent Delegation Strategy section. The orchestrator generates the scope instruction
+first, then delegates; after the agent reports, the orchestrator runs the test command
+independently to verify (see Orchestrator Verification Requirements above).
+
+**Output artifact**: `aidlc-docs/{workflow-id}/construction/build-and-test/test-report.md`
+
+Aggregate per-unit test reports from `aidlc-docs/{workflow-id}/construction/{unit}/testing/test-report.md`
+into the build-level report using this schema:
+
+```markdown
+# Test Report — Build and Test
+
+## Summary
+
+| Metric | Value |
+|--------|-------|
+| total_tests | [X] |
+| passed | [X] |
+| failed | [X] |
+| skipped | [X] |
+
+## Per-Unit Breakdown
+
+| Unit | Total | Passed | Failed | Skipped | Status |
+|------|-------|--------|--------|---------|--------|
+| [unit-id] | [X] | [X] | [X] | [X] | Pass/Fail |
+
+## Failure Details
+
+[For each failing test: unit, test name, file path, error message]
+
+## Remediation Guidance
+
+[Populated only when failures exist — links to the failing unit's test-report.md]
+\`\`\`
+
+**Critical failure gate**: If `tests_failed > 0` and `allowFailures` is not set:
+- Block workflow progression
+- Surface the failing unit's `test-report.md` path in the Remediation Guidance section
+- Do NOT proceed to Step 7 until all failures are resolved or `allowFailures` is explicitly
+  confirmed by the user
+
+---
+
 ## Step 7: Generate Test Summary
 
 Create `aidlc-docs/construction/build-and-test/build-and-test-summary.md`: