olympus-ai 4.0.1 → 4.0.3

package/resources/rules/core-workflow.md

@@ -24,482 +24,107 @@ The AI model intelligently assesses what stages are needed based on:
 - Load `~/.claude/olympus/rules/common/question-format-guide.md` for question formatting rules
 - Load `~/.claude/olympus/rules/common/terminology.md` for phase/stage naming conventions
 - Load `~/.claude/olympus/rules/common/error-handling.md` for error recovery procedures
-- Reference these throughout the workflow execution
 
 ## MANDATORY: Content Validation
 
-**CRITICAL**: Before creating ANY file, you MUST validate content according to `~/.claude/olympus/rules/common/content-validation.md` rules:
-- Validate Mermaid diagram syntax
-- Validate ASCII art diagrams (see `~/.claude/olympus/rules/common/ascii-diagram-standards.md`)
-- Escape special characters properly
-- Provide text alternatives for complex visual content
-- Test content parsing compatibility
+Before creating ANY file, validate content per `~/.claude/olympus/rules/common/content-validation.md`:
+Mermaid syntax, ASCII diagrams, special character escaping, text alternatives.
 
 ## MANDATORY: Question File Format
 
-**CRITICAL**: When asking questions at any phase, you MUST follow question format guidelines.
-
-**See `~/.claude/olympus/rules/common/question-format-guide.md` for complete question formatting rules including**:
-- Multiple choice format (A, B, C, D, E options)
-- [Answer]: tag usage
-- Answer validation and ambiguity resolution
+Follow `~/.claude/olympus/rules/common/question-format-guide.md` for multiple choice format, [Answer]: tags, and validation.
 
 ## MANDATORY: Custom Welcome Message
 
-**CRITICAL**: When starting ANY software development request, you MUST display the welcome message.
-
-**How to Display Welcome Message**:
-1. Load the welcome message from `~/.claude/olympus/rules/common/welcome-message.md`
-2. Display the complete message to the user
-3. This should only be done ONCE at the start of a new workflow
-4. Do NOT load this file in subsequent interactions to save context space
-
-# Adaptive Software Development Workflow
+At workflow start, load and display `~/.claude/olympus/rules/common/welcome-message.md` once.
 
 ---
 
-# INCEPTION PHASE
-
-**Purpose**: Planning, requirements gathering, and architectural decisions
+# INCEPTION PHASE — Determine WHAT to build and WHY
 
-**Focus**: Determine WHAT to build and WHY
-
-**Stages in INCEPTION PHASE**:
-- Workspace Detection (ALWAYS)
-- Reverse Engineering (CONDITIONAL - Brownfield only)
-- Requirements Analysis (ALWAYS - Adaptive depth)
-- User Stories (CONDITIONAL)
-- Workflow Planning (ALWAYS)
-- Application Design (CONDITIONAL)
-- Units Generation (CONDITIONAL)
-
----
+Each stage: load its rule file BEFORE executing, log all interactions in audit.md, wait for explicit user approval before proceeding (do not auto-advance).
 
-## Workspace Detection (ALWAYS EXECUTE)
-
-1. **MANDATORY**: Log initial user request in audit.md with complete raw input
-2. Load all steps from `~/.claude/olympus/rules/inception/workspace-detection.md`
-3. Execute workspace detection:
-   - Check for existing aidlc-state.md (resume if found)
-   - Scan workspace for existing code
-   - Determine if brownfield or greenfield
-   - Check for existing reverse engineering artifacts
-4. Determine next phase: Reverse Engineering (if brownfield and no artifacts) OR Requirements Analysis
-5. **MANDATORY**: Log findings in audit.md
-6. Present completion message to user (see workspace-detection.md for message formats)
-7. Automatically proceed to next phase
-
-## Reverse Engineering (CONDITIONAL - Brownfield Only)
-
-**Execute IF**:
-- Existing codebase detected
-- No previous reverse engineering artifacts found
-
-**Skip IF**:
-- Greenfield project
-- Previous reverse engineering artifacts exist
-
-**Execution**:
-1. **MANDATORY**: Log start of reverse engineering in audit.md
-2. Load all steps from `~/.claude/olympus/rules/inception/reverse-engineering.md`
-3. Execute reverse engineering — delegate to `explore-medium` for codebase analysis:
-   - Analyze all packages and components
-   - Generate a business overview of the whole system covering the business transactions
-   - Generate architecture documentation
-   - Generate code structure documentation
-   - Generate API documentation
-   - Generate component inventory
-   - Generate Interaction Diagrams depicting how business transactions are implemented across components
-   - Generate technology stack documentation
-   - Generate dependencies documentation
-
-4. **Wait for Explicit Approval**: Present detailed completion message (see reverse-engineering.md for message format) - DO NOT PROCEED until user confirms
-5. **MANDATORY**: Log user's response in audit.md with complete raw input
-
-## Requirements Analysis (ALWAYS EXECUTE - Adaptive Depth)
-
-**Always executes** but depth varies based on request clarity and complexity:
-- **Minimal**: Simple, clear request - just document intent analysis
-- **Standard**: Normal complexity - gather functional and non-functional requirements
-- **Comprehensive**: Complex, high-risk - detailed requirements with traceability
-
-**Execution**:
-1. **MANDATORY**: Log any user input during this phase in audit.md
-2. Load all steps from `~/.claude/olympus/rules/inception/requirements-analysis.md`
-3. Execute requirements analysis:
-   - Load reverse engineering artifacts (if brownfield)
-   - Analyze user request (intent analysis)
-   - Determine requirements depth needed
-   - Assess current requirements
-   - Ask clarifying questions (if needed)
-   - Generate requirements document
-4. Execute at appropriate depth (minimal/standard/comprehensive)
-5. **Wait for Explicit Approval**: Follow approval format from requirements-analysis.md detailed steps - DO NOT PROCEED until user confirms
-6. **MANDATORY**: Log user's response in audit.md with complete raw input
-
-## User Stories (CONDITIONAL)
-
-**INTELLIGENT ASSESSMENT**: Use multi-factor analysis to determine if user stories add value:
-
-**ALWAYS Execute IF** (High Priority Indicators):
-- New user-facing features or functionality
-- Changes affecting user workflows or interactions
-- Multiple user types or personas involved
-- Complex business requirements with acceptance criteria needs
-- Cross-functional team collaboration required
-- Customer-facing API or service changes
-- New product capabilities or enhancements
-
-**LIKELY Execute IF** (Medium Priority - Assess Complexity):
-- Modifications to existing user-facing features
-- Backend changes that indirectly affect user experience
-- Integration work that impacts user workflows
-- Performance improvements with user-visible benefits
-- Security enhancements affecting user interactions
-- Data model changes affecting user data or reports
-
-**COMPLEXITY-BASED ASSESSMENT**: For medium priority cases, execute user stories if:
-- Request involves multiple components or services
-- Changes span multiple user touchpoints
-- Business logic is complex or has multiple scenarios
-- Requirements have ambiguity that stories could clarify
-- Implementation affects multiple user journeys
-- Change has significant business impact or risk
-
-**SKIP ONLY IF** (Low Priority - Simple Cases):
-- Pure internal refactoring with zero user impact
-- Simple bug fixes with clear, isolated scope
-- Infrastructure changes with no user-facing effects
-- Technical debt cleanup with no functional changes
-- Developer tooling or build process improvements
-- Documentation-only updates
-
-**ASSESSMENT CRITERIA**: When in doubt, favor inclusion of user stories for:
-- Requests with business stakeholder involvement
-- Changes requiring user acceptance testing
-- Features with multiple implementation approaches
-- Work that benefits from shared team understanding
-- Projects where requirements clarity is valuable
-
-**ASSESSMENT PROCESS**:
-1. Analyze request complexity and scope
-2. Identify user impact (direct or indirect)
-3. Evaluate business context and stakeholder needs
-4. Consider team collaboration benefits
-5. Default to inclusion for borderline cases
-
-**Note**: If Requirements Analysis executed, Stories can reference and build upon those requirements.
-
-**User Stories has two parts within one stage**:
-1. **Part 1 - Planning**: Create story plan with questions, collect answers, analyze for ambiguities, get approval
-2. **Part 2 - Generation**: Execute approved plan to generate stories and personas
-
-**Execution**:
-1. **MANDATORY**: Log any user input during this phase in audit.md
-2. Load all steps from `~/.claude/olympus/rules/inception/user-stories.md`
-3. **MANDATORY**: Perform intelligent assessment (Step 1 in user-stories.md) to validate user stories are needed
-4. Load reverse engineering artifacts (if brownfield)
-5. If Requirements exist, reference them when creating stories
-6. Execute at appropriate depth (minimal/standard/comprehensive)
-7. **PART 1 - Planning**: Create story plan with questions, wait for user answers, analyze for ambiguities, get approval
-8. **PART 2 - Generation**: Execute approved plan to generate stories and personas
-9. **Wait for Explicit Approval**: Follow approval format from user-stories.md detailed steps - DO NOT PROCEED until user confirms
-10. **MANDATORY**: Log user's response in audit.md with complete raw input
-
-## Workflow Planning (ALWAYS EXECUTE)
-
-1. **MANDATORY**: Log any user input during this phase in audit.md
-2. Load all steps from `~/.claude/olympus/rules/inception/workflow-planning.md`
-3. **MANDATORY**: Load content validation rules from `~/.claude/olympus/rules/common/content-validation.md`
-4. Load all prior context:
-   - Reverse engineering artifacts (if brownfield)
-   - Intent analysis
-   - Requirements (if executed)
-   - User stories (if executed)
-5. Execute workflow planning:
-   - Determine which phases to execute
-   - Determine depth level for each phase
-   - Create multi-package change sequence (if brownfield)
-   - Generate workflow visualization (VALIDATE Mermaid syntax before writing)
-6. **MANDATORY**: Validate all content before file creation per content-validation.md rules
-7. **Wait for Explicit Approval**: Present recommendations using language from workflow-planning.md Step 9, emphasizing user control to override recommendations - DO NOT PROCEED until user confirms
-8. **MANDATORY**: Log user's response in audit.md with complete raw input
-
-## Application Design (CONDITIONAL)
-
-**Execute IF**:
-- New components or services needed
-- Component methods and business rules need definition
-- Service layer design required
-- Component dependencies need clarification
-
-**Skip IF**:
-- Changes within existing component boundaries
-- No new components or methods
-- Pure implementation changes
-
-**Execution**:
-1. **MANDATORY**: Log any user input during this phase in audit.md
-2. Load all steps from `~/.claude/olympus/rules/inception/application-design.md`
-3. Load reverse engineering artifacts (if brownfield)
-4. Execute at appropriate depth (minimal/standard/comprehensive) — delegate to `oracle` for architecture decisions
-5. **Wait for Explicit Approval**: Present detailed completion message (see application-design.md for message format) - DO NOT PROCEED until user confirms
-6. **MANDATORY**: Log user's response in audit.md with complete raw input
-
-## Units Generation (CONDITIONAL)
-
-**Execute IF**:
-- System needs decomposition into multiple units of work
-- Multiple services or modules required
-- Complex system requiring structured breakdown
-
-**Skip IF**:
-- Single simple unit
-- No decomposition needed
-- Straightforward single-component implementation
-
-**Execution**:
-1. **MANDATORY**: Log any user input during this phase in audit.md
-2. Load all steps from `~/.claude/olympus/rules/inception/units-generation.md`
-3. Load reverse engineering artifacts (if brownfield)
-4. Execute at appropriate depth (minimal/standard/comprehensive)
-5. **Wait for Explicit Approval**: Present detailed completion message (see units-generation.md for message format) - DO NOT PROCEED until user confirms
-6. **MANDATORY**: Log user's response in audit.md with complete raw input
+| Stage | Condition | Rule File |
+|-------|-----------|-----------|
+| Workspace Detection | ALWAYS | `~/.claude/olympus/rules/inception/workspace-detection.md` |
+| Reverse Engineering | Brownfield only (no prior artifacts) | `~/.claude/olympus/rules/inception/reverse-engineering.md` |
+| Requirements Analysis | ALWAYS (adaptive depth) | `~/.claude/olympus/rules/inception/requirements-analysis.md` |
+| User Stories | Conditional (new user-facing features, multiple personas, complex requirements) | `~/.claude/olympus/rules/inception/user-stories.md` |
+| Workflow Planning | ALWAYS | `~/.claude/olympus/rules/inception/workflow-planning.md` |
+| Application Design | Conditional (new components/services needed) | `~/.claude/olympus/rules/inception/application-design.md` |
+| Units Generation | Conditional (multiple units of work needed) | `~/.claude/olympus/rules/inception/units-generation.md` |
 
 ---
 
-# CONSTRUCTION PHASE
-
-**Purpose**: Detailed design, NFR implementation, and code generation
-
-**Focus**: Determine HOW to build it
-
-**Stages in CONSTRUCTION PHASE**:
-- Per-Unit Loop (executes for each unit):
-  - Functional Design (CONDITIONAL, per-unit)
-  - NFR Requirements (CONDITIONAL, per-unit)
-  - NFR Design (CONDITIONAL, per-unit)
-  - Infrastructure Design (CONDITIONAL, per-unit)
-  - Code Generation (ALWAYS, per-unit)
-- Build and Test (ALWAYS - after all units complete)
-
-**Note**: Each unit is completed fully (design + code) before moving to the next unit.
-
----
+# CONSTRUCTION PHASE — Determine HOW to build it
 
-## Per-Unit Loop (Executes for Each Unit)
-
-**For each unit of work, execute the following stages in sequence:**
-
-Units are identified by name (e.g., `{unit-name}`) — not by numbered codes.
-Each unit produces its own directory under `aidlc-docs/{workflow-id}/construction/{unit-name}/`.
-
-### Functional Design (CONDITIONAL, per-unit)
-
-**Execute IF**:
-- New data models or schemas
-- Complex business logic
-- Business rules need detailed design
-
-**Skip IF**:
-- Simple logic changes
-- No new business logic
-
-**Execution**:
-1. **MANDATORY**: Log any user input during this stage in audit.md
-2. Load all steps from `~/.claude/olympus/rules/construction/functional-design.md`
-3. Execute functional design for this unit — delegate to `oracle-medium` for design decisions
-4. **MANDATORY**: Present standardized 2-option completion message as defined in functional-design.md - DO NOT use emergent 3-option behavior
-5. **Wait for Explicit Approval**: User must choose between "Request Changes" or "Continue to Next Stage" - DO NOT PROCEED until user confirms
-6. **MANDATORY**: Log user's response in audit.md with complete raw input
-
-### NFR Requirements (CONDITIONAL, per-unit)
-
-**Execute IF**:
-- Performance requirements exist
-- Security considerations needed
-- Scalability concerns present
-- Tech stack selection required
-
-**Skip IF**:
-- No NFR requirements
-- Tech stack already determined
-
-**Execution**:
-1. **MANDATORY**: Log any user input during this stage in audit.md
-2. Load all steps from `~/.claude/olympus/rules/construction/nfr-requirements.md`
-3. Execute NFR assessment for this unit
-4. **MANDATORY**: Present standardized 2-option completion message as defined in nfr-requirements.md - DO NOT use emergent behavior
-5. **Wait for Explicit Approval**: User must choose between "Request Changes" or "Continue to Next Stage" - DO NOT PROCEED until user confirms
-6. **MANDATORY**: Log user's response in audit.md with complete raw input
-
-### NFR Design (CONDITIONAL, per-unit)
-
-**Execute IF**:
-- NFR Requirements was executed
-- NFR patterns need to be incorporated
-
-**Skip IF**:
-- No NFR requirements
-- NFR Requirements Assessment was skipped
-
-**Execution**:
-1. **MANDATORY**: Log any user input during this stage in audit.md
-2. Load all steps from `~/.claude/olympus/rules/construction/nfr-design.md`
-3. Execute NFR design for this unit
-4. **MANDATORY**: Present standardized 2-option completion message as defined in nfr-design.md - DO NOT use emergent behavior
-5. **Wait for Explicit Approval**: User must choose between "Request Changes" or "Continue to Next Stage" - DO NOT PROCEED until user confirms
-6. **MANDATORY**: Log user's response in audit.md with complete raw input
-
-### Infrastructure Design (CONDITIONAL, per-unit)
-
-**Execute IF**:
-- Infrastructure services need mapping
-- Deployment architecture required
-- Cloud resources need specification
-
-**Skip IF**:
-- No infrastructure changes
-- Infrastructure already defined
-
-**Execution**:
-1. **MANDATORY**: Log any user input during this stage in audit.md
-2. Load all steps from `~/.claude/olympus/rules/construction/infrastructure-design.md`
-3. Execute infrastructure design for this unit
-4. **MANDATORY**: Present standardized 2-option completion message as defined in infrastructure-design.md - DO NOT use emergent behavior
-5. **Wait for Explicit Approval**: User must choose between "Request Changes" or "Continue to Next Stage" - DO NOT PROCEED until user confirms
-6. **MANDATORY**: Log user's response in audit.md with complete raw input
-
-### Code Generation (ALWAYS EXECUTE, per-unit)
-
-**Always executes for each unit**
-
-**Code Generation is two-part within one stage**:
-1. **Part 1 - Planning**: Create a detailed code generation plan with explicit steps and checkboxes; present to user for approval
-2. **Part 2 - Generation**: Execute the approved plan to generate code, tests, and artifacts — delegate to `olympian` or `olympian-high` (for complex units)
-
-**Execution**:
-1. **MANDATORY**: Log any user input during this stage in audit.md
-2. Load all steps from `~/.claude/olympus/rules/construction/code-generation.md`
-3. **PART 1 - Planning**: Create code generation plan with checkboxes, get user approval
-4. **PART 2 - Generation**: Execute approved plan; delegate implementation to `olympian`
-5. **MANDATORY**: Present standardized 2-option completion message as defined in code-generation.md - DO NOT use emergent behavior
-6. **Wait for Explicit Approval**: User must choose between "Request Changes" or "Continue to Next Stage" - DO NOT PROCEED until user confirms
-7. **MANDATORY**: Log user's response in audit.md with complete raw input
+Each unit is completed fully (design + code) before moving to the next unit. Construction stages use standardized 2-option completion messages (Request Changes / Continue) — NO emergent 3-option behavior.
 
----
+**Per-Unit Loop** (for each unit of work):
 
-## Build and Test (ALWAYS EXECUTE)
+| Stage | Condition | Rule File |
+|-------|-----------|-----------|
+| Functional Design | Conditional (new data models, complex business logic) | `~/.claude/olympus/rules/construction/functional-design.md` |
+| NFR Requirements | Conditional (performance, security, scalability, tech stack) | `~/.claude/olympus/rules/construction/nfr-requirements.md` |
+| NFR Design | Conditional (NFR Requirements was executed) | `~/.claude/olympus/rules/construction/nfr-design.md` |
+| Infrastructure Design | Conditional (infra services, deployment arch) | `~/.claude/olympus/rules/construction/infrastructure-design.md` |
+| Code Generation | ALWAYS (two-part: plan then generate) | `~/.claude/olympus/rules/construction/code-generation.md` |
 
-1. **MANDATORY**: Log any user input during this phase in audit.md
-2. Load all steps from `~/.claude/olympus/rules/construction/build-and-test.md`
-3. Generate comprehensive build and test instructions — delegate to `qa-tester` for test execution:
-   - Build instructions for all units
-   - Unit test execution instructions
-   - Integration test instructions (test interactions between units)
-   - Performance test instructions (if applicable)
-   - Additional test instructions as needed (contract tests, security tests, e2e tests)
-4. Create instruction files in build-and-test/ subdirectory: build-instructions.md, unit-test-instructions.md, integration-test-instructions.md, performance-test-instructions.md, build-and-test-summary.md
-5. **Wait for Explicit Approval**: Ask: "**Build and test instructions complete. Ready to proceed to Operations stage?**" - DO NOT PROCEED until user confirms
-6. **MANDATORY**: Log user's response in audit.md with complete raw input
+**Build and Test** (ALWAYS, after all units): Load `~/.claude/olympus/rules/construction/build-and-test.md`
 
 ---
 
-# OPERATIONS PHASE
-
-**Purpose**: Placeholder for future deployment and monitoring workflows
-
-**Focus**: How to DEPLOY and RUN it (future expansion)
-
-**Stages in OPERATIONS PHASE**:
-- Operations (PLACEHOLDER)
+# OPERATIONS PHASE — Placeholder for future deployment/monitoring workflows
 
 ---
 
-## Operations (PLACEHOLDER)
-
-**Status**: This stage is currently a placeholder for future expansion.
-
-The Operations stage will eventually include:
-- Deployment planning and execution
-- Monitoring and observability setup
-- Incident response procedures
-- Maintenance and support workflows
-- Production readiness checklists
-
-**Current State**: All build and test activities are handled in the CONSTRUCTION phase.
-
 ## Key Principles
 
 - **Adaptive Execution**: Only execute stages that add value
-- **Transparent Planning**: Always show execution plan before starting
 - **User Control**: User can request stage inclusion/exclusion
 - **Progress Tracking**: Update aidlc-state.md with executed and skipped stages
 - **Complete Audit Trail**: Log ALL user inputs and AI responses in audit.md with timestamps
-  - **CRITICAL**: Capture user's COMPLETE RAW INPUT exactly as provided
-  - **CRITICAL**: Never summarize or paraphrase user input in audit log
-  - **CRITICAL**: Log every interaction, not just approvals
-- **Quality Focus**: Complex changes get full treatment, simple changes stay efficient
-- **Content Validation**: Always validate content before file creation per content-validation.md rules
-- **NO EMERGENT BEHAVIOR**: Construction phases MUST use standardized 2-option completion messages as defined in their respective rule files. DO NOT create 3-option menus or other emergent navigation patterns.
+  - Capture user's COMPLETE RAW INPUT exactly as provided (never summarize)
+  - Log every interaction, not just approvals
+- **Content Validation**: Validate before file creation per content-validation.md rules
+- **NO EMERGENT BEHAVIOR**: Construction phases use standardized 2-option completion messages only
 
 ## MANDATORY: Plan-Level Checkbox Enforcement
 
-### MANDATORY RULES FOR PLAN EXECUTION
-1. **NEVER complete any work without updating plan checkboxes**
-2. **IMMEDIATELY after completing ANY step described in a plan file, mark that step [x]**
-3. **This must happen in the SAME interaction where the work is completed**
-4. **NO EXCEPTIONS**: Every plan step completion MUST be tracked with checkbox updates
-
-### Two-Level Checkbox Tracking System
-- **Plan-Level**: Track detailed execution progress within each stage
-- **Stage-Level**: Track overall workflow progress in aidlc-state.md
-- **Update immediately**: All progress updates in SAME interaction where work is completed
+1. NEVER complete any work without updating plan checkboxes
+2. IMMEDIATELY mark steps `[x]` in the SAME interaction where work is completed
+3. Two-Level tracking: Plan-Level (detailed steps) + Stage-Level (aidlc-state.md)
 
 ## Prompts Logging Requirements
-- **MANDATORY**: Log EVERY user input (prompts, questions, responses) with timestamp in audit.md
-- **MANDATORY**: Capture user's COMPLETE RAW INPUT exactly as provided (never summarize)
-- **MANDATORY**: Log every approval prompt with timestamp before asking the user
-- **MANDATORY**: Record every user response with timestamp after receiving it
-- **CRITICAL**: ALWAYS append changes to EDIT audit.md file, NEVER use tools and commands that completely overwrite its contents
-- Use ISO 8601 format for timestamps (YYYY-MM-DDTHH:MM:SSZ)
-- Include stage context for each entry
+
+- Log EVERY user input with ISO 8601 timestamp in audit.md
+- Capture COMPLETE RAW INPUT exactly as provided (never summarize)
+- ALWAYS append/edit audit.md — NEVER overwrite
 
 ### Audit Log Format:
 ```markdown
-## [Stage Name or Interaction Type]
+## [Stage Name]
 **Timestamp**: [ISO timestamp]
-**User Input**: "[Complete raw user input - never summarized]"
-**AI Response**: "[AI's response or action taken]"
-**Context**: [Stage, action, or decision made]
+**User Input**: "[Complete raw user input]"
+**AI Response**: "[Action taken]"
+**Context**: [Stage/decision]
 
 ---
 ```
 
-### Correct Tool Usage for audit.md
-
-CORRECT:
-1. Read the audit.md file
-2. Append/Edit the file to make changes
-
-WRONG:
-1. Read the audit.md file
-2. Completely overwrite the audit.md with the contents of what you read, plus the new changes you want to add to it
-
 ## Directory Structure
 
 ```text
 <WORKSPACE-ROOT>/                   # APPLICATION CODE HERE
-├── [project-specific structure]    # Varies by project (see code-generation.md)
-│
+├── [project-specific structure]
 ├── aidlc-docs/                     # DOCUMENTATION ONLY
-│   ├── inception/                  # INCEPTION PHASE
+│   ├── inception/
 │   │   ├── plans/
 │   │   ├── reverse-engineering/    # Brownfield only
 │   │   ├── requirements/
 │   │   ├── user-stories/
 │   │   └── application-design/
-│   ├── construction/               # CONSTRUCTION PHASE
+│   ├── construction/
 │   │   ├── plans/
 │   │   ├── {unit-name}/
 │   │   │   ├── functional-design/
@@ -508,59 +133,36 @@ WRONG:
 │   │   │   ├── infrastructure-design/
 │   │   │   └── code/               # Markdown summaries only
 │   │   └── build-and-test/
-│   ├── operations/                 # OPERATIONS PHASE (placeholder)
+│   ├── operations/                 # Placeholder
 │   ├── aidlc-state.md
 │   └── audit.md
 ```
 
-**CRITICAL RULE**:
-- Application code: Workspace root (NEVER in aidlc-docs/)
-- Documentation: aidlc-docs/ only
-- Project structure: See code-generation.md for patterns by project type
+Application code: workspace root (NEVER in aidlc-docs/). Documentation: aidlc-docs/ only.
 
 ## Olympus Agent Delegation
 
-When executing AI-DLC workflow stages, Olympus delegates to specialized agents:
-
-| Stage | Agent | Recommended Skills | Purpose |
-|-------|-------|--------------------|---------|
-| Discovery/Reverse Engineering | `explore-medium` | — | Codebase analysis |
-| Reverse Engineering (visual) | `multimodal-looker` (optional) | — | Architecture diagram extraction |
-| Intent/Requirements | `prometheus` | — | Strategic planning with interview |
-| Requirements Analysis | `metis` (optional) | — | Blind spot analysis |
-| User Stories | `oracle-medium` | — | Story and persona generation |
-| Application Design | `oracle` | — | Architecture decisions |
-| Application Design (review) | `momus` (optional) | — | Design quality gate |
-| Units Generation | `olympian` | — | Decomposition execution |
-| Units Generation (review) | `momus` (optional) | — | Decomposition quality gate |
-| Functional Design | `oracle-medium` | — | Design decisions |
-| NFR Requirements | `oracle-medium` | — | NFR assessment |
-| NFR Requirements (validation) | `librarian` (optional) | — | Technology doc verification |
-| NFR Design | `oracle-medium` | — | Design pattern incorporation |
-| Infrastructure Design | `oracle-medium` | — | Infrastructure mapping |
-| Code Generation (backend) | `olympian` or `olympian-high` | `ascent`, `ultrawork` | Backend/general implementation |
-| Code Generation (frontend) | `frontend-engineer` or `frontend-engineer-high` | `ascent`, `ultrawork` | UI/component implementation |
-| Build & Test | `qa-tester` | `ascent` | Testing and verification |
-| Review | `momus` | — | Critical evaluation |
-
-Use the Task tool to delegate. Run independent stages in parallel when profitable.
-
-## Recommended Skill Stacking for AI-DLC
-
-The `/plan` command starts the AI-DLC workflow. For maximum effectiveness during the construction phase, users should stack additional Olympus skills:
-
-| Combination | Effect | Best For |
-|-------------|--------|----------|
-| `/plan` alone | Structured workflow with agent delegation | Standard features, single-unit work |
-| `/plan` + `/ascent` | Adds persistence — orchestrator cannot stop until all units complete | Multi-unit construction loops |
-| `/plan` + `/ultrawork` | Adds parallel execution and verification guarantees | Large implementations, independent units |
-| `/plan` + `/ascent` + `/ultrawork` | Full Olympus power: parallel, persistent, verified | Complex multi-unit features |
-
-**How skills enhance the orchestrator during AI-DLC**:
-- **`/ascent`** — Ensures the orchestrator persists through all construction units without stopping early. Enforces todo tracking and continuation.
-- **`/ultrawork`** — Enables parallel Task calls for independent units, adds mandatory independent verification after every agent delegation, and enforces zero-tolerance for incomplete work.
-- Skills modify the **orchestrator's behavior** (how it manages the workflow), not the sub-agents. Sub-agents are always delegated to via the Task tool with their own specific prompts.
+| Stage | Agent | Purpose |
+|-------|-------|---------|
+| Discovery/Reverse Engineering | `explore-medium` | Codebase analysis |
+| Intent/Requirements | `prometheus` | Strategic planning with interview |
+| User Stories | `oracle-medium` | Story and persona generation |
+| Application Design | `oracle` | Architecture decisions |
+| Functional/NFR/Infrastructure Design | `oracle-medium` | Design decisions |
+| Code Generation (backend) | `olympian` or `olympian-high` | Implementation |
+| Code Generation (frontend) | `frontend-engineer` or `frontend-engineer-high` | UI implementation |
+| Build & Test | `qa-tester` | Testing and verification |
+| Review | `momus` | Critical evaluation |
+
+## Skill Stacking for AI-DLC
+
+| Combination | Effect |
+|-------------|--------|
+| `/plan` alone | Structured workflow with agent delegation |
+| `/plan` + `/ascent` | Adds persistence — cannot stop until all units complete |
+| `/plan` + `/ultrawork` | Adds parallel execution and verification guarantees |
+| `/plan` + `/ascent` + `/ultrawork` | Full power: parallel, persistent, verified |
 
 ## Extensions
 
-Custom project-specific rule extensions can be placed in `.aidlc-rule-details/extensions/` at the workspace root. Files in that directory are loaded in addition to the standard rules above and take precedence for any rules they redefine.
+Custom extensions in `.aidlc-rule-details/extensions/` at workspace root take precedence over standard rules.