olympus-ai 4.0.2 → 4.0.4

package/resources/rules/common/session-continuity.md

@@ -1,47 +1,47 @@
-# Session Continuity Templates
-
-## Welcome Back Prompt Template
-When a user returns to continue work on an existing AI-DLC project, present this prompt:
-
-```markdown
-**Welcome back! I can see you have an existing AI-DLC project in progress.**
-
-Based on your aidlc-state.md, here's your current status:
-- **Project**: [project-name]
-- **Current Phase**: [INCEPTION/CONSTRUCTION/OPERATIONS]
-- **Current Stage**: [Stage Name]
-- **Last Completed**: [Last completed step]
-- **Next Step**: [Next step to work on]
-
-**What would you like to work on today?**
-
-A) Continue where you left off ([Next step description])
-B) Review a previous stage ([Show available stages])
-
-[Answer]: 
-```
-
-## MANDATORY: Session Continuity Instructions
-1. **Always read aidlc-state.md first** when detecting existing project
-2. **Parse current status** from the workflow file to populate the prompt
-3. **MANDATORY: Load Previous Stage Artifacts** - Before resuming any stage, automatically read all relevant artifacts from previous stages:
-   - **Reverse Engineering**: Read architecture.md, code-structure.md, api-documentation.md
-   - **Requirements Analysis**: Read requirements.md, requirement-verification-questions.md
-   - **User Stories**: Read stories.md, personas.md, story-generation-plan.md
-   - **Application Design**: Read application-design artifacts (components.md, component-methods.md, services.md)
-   - **Design (Units)**: Read unit-of-work.md, unit-of-work-dependency.md, unit-of-work-story-map.md
-   - **Per-Unit Design**: Read functional-design.md, nfr-requirements.md, nfr-design.md, infrastructure-design.md
-   - **Code Stages**: Read all code files, plans, AND all previous artifacts
-4. **Smart Context Loading by Stage**:
-   - **Early Stages (Workspace Detection, Reverse Engineering)**: Load workspace analysis
-   - **Requirements/Stories**: Load reverse engineering + requirements artifacts
-   - **Design Stages**: Load requirements + stories + architecture + design artifacts
-   - **Code Stages**: Load ALL artifacts + existing code files
-5. **Adapt options** based on architectural choice and current phase
-6. **Show specific next steps** rather than generic descriptions
-7. **Log the continuity prompt** in audit.md with timestamp
-8. **Context Summary**: After loading artifacts, provide brief summary of what was loaded for user awareness
-9. **Asking questions**: ALWAYS ask clarification or user feedback questions by placing them in .md files. DO NOT place the multiple-choice questions in-line in the chat session.
-
-## Error Handling
-If artifacts are missing or corrupted during session resumption, see [error-handling.md](error-handling.md) for guidance on recovery procedures.
+# Session Continuity Templates
+
+## Welcome Back Prompt Template
+When a user returns to continue work on an existing AI-DLC project, present this prompt:
+
+```markdown
+**Welcome back! I can see you have an existing AI-DLC project in progress.**
+
+Based on your aidlc-state.md, here's your current status:
+- **Project**: [project-name]
+- **Current Phase**: [INCEPTION/CONSTRUCTION/OPERATIONS]
+- **Current Stage**: [Stage Name]
+- **Last Completed**: [Last completed step]
+- **Next Step**: [Next step to work on]
+
+**What would you like to work on today?**
+
+A) Continue where you left off ([Next step description])
+B) Review a previous stage ([Show available stages])
+
+[Answer]: 
+```
+
+## MANDATORY: Session Continuity Instructions
+1. **Always read aidlc-state.md first** when detecting existing project
+2. **Parse current status** from the workflow file to populate the prompt
+3. **MANDATORY: Load Previous Stage Artifacts** - Before resuming any stage, automatically read all relevant artifacts from previous stages:
+   - **Reverse Engineering**: Read architecture.md, code-structure.md, api-documentation.md
+   - **Requirements Analysis**: Read requirements.md, requirements-analysis-questions.md
+   - **User Stories**: Read stories.md, personas.md, story-generation-plan.md
+   - **Application Design**: Read application-design artifacts (components.md, component-methods.md, services.md)
+   - **Design (Units)**: Read unit-of-work.md, unit-of-work-dependency.md, unit-of-work-story-map.md
+   - **Per-Unit Design**: Read functional-design.md, nfr-requirements.md, nfr-design.md, infrastructure-design.md
+   - **Code Stages**: Read all code files, plans, AND all previous artifacts
+4. **Smart Context Loading by Stage**:
+   - **Early Stages (Workspace Detection, Reverse Engineering)**: Load workspace analysis
+   - **Requirements/Stories**: Load reverse engineering + requirements artifacts
+   - **Design Stages**: Load requirements + stories + architecture + design artifacts
+   - **Code Stages**: Load ALL artifacts + existing code files
+5. **Adapt options** based on architectural choice and current phase
+6. **Show specific next steps** rather than generic descriptions
+7. **Log the continuity prompt** in audit.md with timestamp
+8. **Context Summary**: After loading artifacts, provide brief summary of what was loaded for user awareness
+9. **Asking questions**: ALWAYS ask clarification or user feedback questions by placing them in .md files. DO NOT place the multiple-choice questions in-line in the chat session.
+
+## Error Handling
+If artifacts are missing or corrupted during session resumption, see [error-handling.md](error-handling.md) for guidance on recovery procedures.

package/resources/rules/inception/requirements-analysis.md

@@ -1,215 +1,247 @@
-# Requirements Analysis (Adaptive)
-
-**Assume the role** of a product owner
-
-**Adaptive Phase**: Always executes. Detail level adapts to problem complexity.
-
-**See [depth-levels.md](../common/depth-levels.md) for adaptive depth explanation**
-
-## Prerequisites
-- Workspace Detection must be complete
-- Reverse Engineering must be complete (if brownfield)
-
-## Agent Delegation Strategy
-
-**Orchestrator-driven stage** with optional agent support. Requirements Analysis is primarily Q&A-driven work that the orchestrator manages directly (intent analysis, question generation, answer collection, requirements document creation).
-
-**Optional delegation**:
-- **`metis`** (Opus, read-only): May be invoked for blind spot analysis during the question-answering phase. If used, findings are presented to the user for review in Step 6b. This is optional and at the orchestrator's discretion based on project complexity.
-
-**Execution mode**: The orchestrator runs all steps directly. If `metis` is invoked, it runs in the foreground as a supplementary analysis — not a replacement for the orchestrator's own work.
-
-**If an agent task fails**: Follow the Agent Task Failure Recovery procedure in `error-handling.md` — retry the delegation, never silently do the work yourself.
-
-## Execution Steps
-
-### Step 1: Load Reverse Engineering Context (if available)
-
-**IF brownfield project**:
-- Load `aidlc-docs/inception/reverse-engineering/architecture.md`
-- Load `aidlc-docs/inception/reverse-engineering/component-inventory.md`
-- Load `aidlc-docs/inception/reverse-engineering/technology-stack.md`
-- Use these to understand existing system when analyzing request
-
-### Step 2: Analyze User Request (Intent Analysis)
-
-#### 2.1 Request Clarity
-- **Clear**: Specific, well-defined, actionable
-- **Vague**: General, ambiguous, needs clarification
-- **Incomplete**: Missing key information
-
-#### 2.2 Request Type
-- **New Feature**: Adding new functionality
-- **Bug Fix**: Fixing existing issue
-- **Refactoring**: Improving code structure
-- **Upgrade**: Updating dependencies or frameworks
-- **Migration**: Moving to different technology
-- **Enhancement**: Improving existing feature
-- **New Project**: Starting from scratch
-
-#### 2.3 Initial Scope Estimate
-- **Single File**: Changes to one file
-- **Single Component**: Changes to one component/package
-- **Multiple Components**: Changes across multiple components
-- **System-wide**: Changes affecting entire system
-- **Cross-system**: Changes affecting multiple systems
-
-#### 2.4 Initial Complexity Estimate
-- **Trivial**: Simple, straightforward change
-- **Simple**: Clear implementation path
-- **Moderate**: Some complexity, multiple considerations
-- **Complex**: Significant complexity, many considerations
-
-### Step 3: Determine Requirements Depth
-
-**Based on request analysis, determine depth:**
-
-**Minimal Depth** - Use when:
-- Request is clear and simple
-- No detailed requirements needed
-- Just document the basic understanding
-
-**Standard Depth** - Use when:
-- Request needs clarification
-- Functional and non-functional requirements needed
-- Normal complexity
-
-**Comprehensive Depth** - Use when:
-- Complex project with multiple stakeholders
-- High risk or critical system
-- Detailed requirements with traceability needed
-
-### Step 4: Assess Current Requirements
-
-Analyze whatever the user has provided:
-   - Intent statements or descriptions (already logged in audit.md)
-   - Existing requirements documents (search workspace if mentioned)
-   - Pasted content or file references
-   - Convert any non-markdown documents to markdown format 
-
-### Step 5: Thorough Completeness Analysis
-
-**CRITICAL**: Use comprehensive analysis to evaluate requirements completeness. Default to asking questions when there is ANY ambiguity or missing detail.
-
-**MANDATORY**: Evaluate ALL of these areas and ask questions for ANY that are unclear:
-- **Functional Requirements**: Core features, user interactions, system behaviors
-- **Non-Functional Requirements**: Performance, security, scalability, usability
-- **User Scenarios**: Use cases, user journeys, edge cases, error scenarios
-- **Business Context**: Goals, constraints, success criteria, stakeholder needs
-- **Technical Context**: Integration points, data requirements, system boundaries
-- **Quality Attributes**: Reliability, maintainability, testability, accessibility
-
-**When in doubt, ask questions** - incomplete requirements lead to poor implementations.
-
-### Step 6: Generate Clarifying Questions (PROACTIVE APPROACH)
-   - **ALWAYS** create `aidlc-docs/inception/requirements/requirement-verification-questions.md` unless requirements are exceptionally clear and complete
-   - Ask questions about ANY missing, unclear, or ambiguous areas
-   - Focus on functional requirements, non-functional requirements, user scenarios, and business context
-   - Request user to fill in all [Answer]: tags directly in the questions document
-   - If presenting multiple-choice options for answers:
-     - Label the options as A, B, C, D etc.
-     - Ensure options are mutually exclusive and don't overlap
-     - ALWAYS include option for custom response: "X) Other (please describe after [Answer]: tag below)"
-   - Wait for user answers in the document
-   - **MANDATORY**: Analyze ALL answers for ambiguities and create follow-up questions if needed
-   - **MANDATORY**: Keep asking questions until ALL ambiguities are resolved OR user explicitly asks to proceed
-
-### ⛔ GATE: Await User Answers
-DO NOT proceed to Step 7 until all questions in requirement-verification-questions.md are answered and validated.
-Present the question file to the user and STOP.
-
-### Step 6b: Review Supplementary Analysis (if applicable)
-
-**IF a Metis blind spot analysis (or any supplementary agent analysis) was run during the question-answering phase:**
-
-1. Present a summary of the agent's findings to the user — clearly separated from the user's own answers
-2. Format as a numbered list of findings, each with a brief explanation of why it was flagged
-3. Ask the user to review and indicate which findings to incorporate:
-
-```markdown
-> **🔎 Metis Blind Spot Analysis Findings**
->
-> The following potential gaps or risks were identified during requirements analysis:
->
-> 1. [Finding description]
-> 2. [Finding description]
-> ...
->
-> **Please review these findings.** You may:
-> - ✅ **Approve All** — Incorporate all findings into requirements
-> - ✏️ **Select Specific** — Indicate which findings to include (e.g., "include 1, 3, skip 2")
-> - ❌ **Skip All** — Proceed without incorporating supplementary findings
-```
-
-4. **MANDATORY**: Do NOT proceed to Step 7 until the user has reviewed and responded
-5. **MANDATORY**: Only incorporate findings the user explicitly approved
-6. Log the user's response in `audit.md` with complete raw input
-
-**IF no supplementary analysis was run**: Skip directly to Step 7.
-
-### Step 7: Generate Requirements Document
-   - **PREREQUISITE**: Step 6 gate must be passed — all answers received and analyzed. If Step 6b applied, supplementary findings must also be reviewed.
-   - Create `aidlc-docs/inception/requirements/requirements.md`
-   - Include intent analysis summary at the top:
-     - User request
-     - Request type
-     - Scope estimate
-     - Complexity estimate
-   - Include both functional and non-functional requirements
-   - Incorporate user's answers to clarifying questions
-   - Provide brief summary of key requirements
-
-### Step 8: MANDATORY: Update State Tracking
-
-**MANDATORY**: Update BOTH state files in the SAME interaction:
-1. Update `aidlc-docs/{workflow-id}/aidlc-state.md`:
-
-```markdown
-## Stage Progress
-### 🔵 INCEPTION PHASE
-- [x] Workspace Detection
-- [x] Reverse Engineering (if applicable)
-- [x] Requirements Analysis
-```
-
-### Step 9: Log and Proceed
-   - Log approval prompt with timestamp in `aidlc-docs/audit.md`
-   - Present completion message in this structure:
-     1. **Completion Announcement** (mandatory): Always start with this:
-
-```markdown
-# 🔍 Requirements Analysis Complete
-```
-
-     2. **AI Summary** (optional): Provide structured bullet-point summary of requirements
-        - Format: "Requirements analysis has identified [project type/complexity]:"
-        - List key functional requirements (bullet points)
-        - List key non-functional requirements (bullet points)
-        - Mention architectural considerations or technical decisions if relevant
-        - DO NOT include workflow instructions ("please review", "let me know", "proceed to next phase", "before we proceed")
-        - Keep factual and content-focused
-     3. **Formatted Workflow Message** (mandatory): Always end with this exact format:
-
-```markdown
-> **📋 <u>**REVIEW REQUIRED:**</u>**  
-> Please examine the requirements document at: `aidlc-docs/inception/requirements/requirements.md`
-
-
-
-> **🚀 <u>**WHAT'S NEXT?**</u>**
->
-> **You may:**
->
-> 🔧 **Request Changes** -  Ask for modifications to the requirements if required based on your review 
-> [IF User Stories will be skipped, add this option:]
-> 📝 **Add User Stories** - Choose to Include **User Stories** stage (currently skipped based on project simplicity)  
-> ✅ **Approve & Continue** - Approve requirements and proceed to **[User Stories/Workflow Planning]**
-
----
-```
-
-**Note**: Include the "Add User Stories" option only when User Stories stage will be skipped. Replace [User Stories/Workflow Planning] with the actual next stage name.
-
-   - Wait for explicit user approval before proceeding
-   - Record approval response with timestamp
-   - Update Requirements Analysis stage complete in aidlc-state.md
+# Requirements Analysis (Adaptive)
+
+**Assume the role** of a product owner
+
+**Adaptive Phase**: Always executes. Detail level adapts to problem complexity.
+
+**See [depth-levels.md](../common/depth-levels.md) for adaptive depth explanation**
+
+## Prerequisites
+- Workspace Detection must be complete
+- Reverse Engineering must be complete (if brownfield)
+
+## Agent Delegation Strategy
+
+**Orchestrator-driven stage** with optional agent support. Requirements Analysis is primarily Q&A-driven work that the orchestrator manages directly (intent analysis, question generation, answer collection, requirements document creation).
+
+**Optional delegation**:
+- **`metis`** (Opus, read-only): May be invoked for blind spot analysis during the question-answering phase. If used, findings are presented to the user for review in Step 6b. This is optional and at the orchestrator's discretion based on project complexity.
+
+**Execution mode**: The orchestrator runs all steps directly. If `metis` is invoked, it runs in the foreground as a supplementary analysis — not a replacement for the orchestrator's own work.
+
+**If an agent task fails**: Follow the Agent Task Failure Recovery procedure in `error-handling.md` — retry the delegation, never silently do the work yourself.
+
+## Execution Steps
+
+### Step 1: Load Reverse Engineering Context (if available)
+
+**IF brownfield project**:
+- Load `aidlc-docs/{workflow-id}/inception/reverse-engineering/architecture.md`
+- Load `aidlc-docs/{workflow-id}/inception/reverse-engineering/component-inventory.md`
+- Load `aidlc-docs/{workflow-id}/inception/reverse-engineering/technology-stack.md`
+- Use these to understand existing system when analyzing request
+
+### Step 2: Analyze User Request (Intent Analysis)
+
+#### 2.1 Request Clarity
+- **Clear**: Specific, well-defined, actionable
+- **Vague**: General, ambiguous, needs clarification
+- **Incomplete**: Missing key information
+
+#### 2.2 Request Type
+- **New Feature**: Adding new functionality
+- **Bug Fix**: Fixing existing issue
+- **Refactoring**: Improving code structure
+- **Upgrade**: Updating dependencies or frameworks
+- **Migration**: Moving to different technology
+- **Enhancement**: Improving existing feature
+- **New Project**: Starting from scratch
+
+#### 2.3 Initial Scope Estimate
+- **Single File**: Changes to one file
+- **Single Component**: Changes to one component/package
+- **Multiple Components**: Changes across multiple components
+- **System-wide**: Changes affecting entire system
+- **Cross-system**: Changes affecting multiple systems
+
+#### 2.4 Initial Complexity Estimate
+- **Trivial**: Simple, straightforward change
+- **Simple**: Clear implementation path
+- **Moderate**: Some complexity, multiple considerations
+- **Complex**: Significant complexity, many considerations
+
+### Step 3: Determine Requirements Depth
+
+**Based on request analysis, determine depth:**
+
+**Minimal Depth** - Use when:
+- Request is clear and simple
+- No detailed requirements needed
+- Just document the basic understanding
+
+**Standard Depth** - Use when:
+- Request needs clarification
+- Functional and non-functional requirements needed
+- Normal complexity
+
+**Comprehensive Depth** - Use when:
+- Complex project with multiple stakeholders
+- High risk or critical system
+- Detailed requirements with traceability needed
+
+### Step 4: Assess Current Requirements
+
+Analyze whatever the user has provided:
+   - Intent statements or descriptions (already logged in audit.md)
+   - Existing requirements documents (search workspace if mentioned)
+   - Pasted content or file references
+   - Convert any non-markdown documents to markdown format 
+
+### Step 5: Thorough Completeness Analysis
+
+**CRITICAL**: Use comprehensive analysis to evaluate requirements completeness. Default to asking questions when there is ANY ambiguity or missing detail.
+
+**MANDATORY**: Evaluate ALL of these areas and ask questions for ANY that are unclear:
+- **Functional Requirements**: Core features, user interactions, system behaviors
+- **Non-Functional Requirements**: Performance, security, scalability, usability
+- **User Scenarios**: Use cases, user journeys, edge cases, error scenarios
+- **Business Context**: Goals, constraints, success criteria, stakeholder needs
+- **Technical Context**: Integration points, data requirements, system boundaries
+- **Quality Attributes**: Reliability, maintainability, testability, accessibility
+
+**When in doubt, ask questions** - incomplete requirements lead to poor implementations.
+
+### Step 6: Generate Clarifying Questions (PROACTIVE APPROACH)
+   - **ALWAYS** create `aidlc-docs/{workflow-id}/inception/requirements/requirements-analysis-questions.md` unless requirements are exceptionally clear and complete
+   - Ask questions about ANY missing, unclear, or ambiguous areas
+   - Focus on functional requirements, non-functional requirements, user scenarios, and business context
+   - Request user to fill in all [Answer]: tags directly in the questions document
+   - If presenting multiple-choice options for answers:
+     - Label the options as A, B, C, D etc.
+     - Ensure options are mutually exclusive and don't overlap
+     - ALWAYS include option for custom response: "X) Other (please describe after [Answer]: tag below)"
+   - Wait for user answers in the document
+   - **MANDATORY**: Analyze ALL answers for ambiguities and create follow-up questions if needed
+   - **MANDATORY**: Keep asking questions until ALL ambiguities are resolved OR user explicitly asks to proceed
+
+### ⛔ GATE: Await User Answers
+DO NOT proceed to Step 7 until all questions in requirements-analysis-questions.md are answered and validated.
+Present the question file to the user and STOP.
+
+### Step 6b: Review Supplementary Analysis (if applicable)
+
+**IF a Metis blind spot analysis (or any supplementary agent analysis) was run during the question-answering phase:**
+
+1. **Write findings to a file** — Create `aidlc-docs/{workflow-id}/inception/requirements/metis-blind-spot-analysis.md` with this structure:
+
+```markdown
+# Metis Blind Spot Analysis
+
+Date: {ISO-8601}
+Feature: {feature name}
+
+## How to Review
+
+For each finding below, Metis has provided a **Recommendation** with a suggested course of action.
+Review each finding and:
+- **Check the box** `[x]` next to findings you want incorporated into requirements
+- **Add comments** in the "Your Comments" field if you want to modify or clarify a finding
+- Leave unchecked findings as `[ ]` to skip them
+
+When done, let me know and I will incorporate your approved findings into the requirements.
+
+---
+
+## Findings
+
+### 1. [Finding title]
+[Description of the gap/risk and why it was flagged]
+
+**Recommendation**: [Metis's suggested course of action — e.g., incorporate as requirement, defer to later phase, investigate further, add as constraint, etc.]
+
+- [ ] Include this finding
+- **Your Comments**:
+
+---
+
+### 2. [Finding title]
+...
+
+{repeat for all findings}
+```
+
+2. **Present the file to the user** for review:
+
+```markdown
+> **🔎 Metis Blind Spot Analysis**
+>
+> Metis identified potential gaps and risks during requirements analysis.
+> Findings with recommendations have been written to:
+> `aidlc-docs/{workflow-id}/inception/requirements/metis-blind-spot-analysis.md`
+>
+> Please review the file — each finding includes Metis's recommended course of action to help you decide.
+> Check the boxes for findings you want included and add any comments, then let me know to continue.
+```
+
+3. **MANDATORY**: Do NOT proceed to Step 7 until the user has reviewed the file and responded
+4. **MANDATORY**: Only incorporate findings the user explicitly checked/approved in the file
+5. Log the user's response in `audit.md` with complete raw input
+
+**IF no supplementary analysis was run**: Skip directly to Step 7.
+
+### Step 7: Generate Requirements Document
+   - **PREREQUISITE**: Step 6 gate must be passed — all answers received and analyzed. If Step 6b applied, supplementary findings must also be reviewed.
+   - Create `aidlc-docs/{workflow-id}/inception/requirements/requirements.md`
+   - Include intent analysis summary at the top:
+     - User request
+     - Request type
+     - Scope estimate
+     - Complexity estimate
+   - Include both functional and non-functional requirements
+   - Incorporate user's answers to clarifying questions
+   - Provide brief summary of key requirements
+
+### Step 8: MANDATORY: Update State Tracking
+
+**MANDATORY**: Update BOTH state files in the SAME interaction:
+1. Update `aidlc-docs/{workflow-id}/aidlc-state.md`:
+
+```markdown
+## Stage Progress
+### 🔵 INCEPTION PHASE
+- [x] Workspace Detection
+- [x] Reverse Engineering (if applicable)
+- [x] Requirements Analysis
+```
+
+### Step 9: Log and Proceed
+   - Log approval prompt with timestamp in `aidlc-docs/audit.md`
+   - Present completion message in this structure:
+     1. **Completion Announcement** (mandatory): Always start with this:
+
+```markdown
+# 🔍 Requirements Analysis Complete
+```
+
+     2. **AI Summary** (optional): Provide structured bullet-point summary of requirements
+        - Format: "Requirements analysis has identified [project type/complexity]:"
+        - List key functional requirements (bullet points)
+        - List key non-functional requirements (bullet points)
+        - Mention architectural considerations or technical decisions if relevant
+        - DO NOT include workflow instructions ("please review", "let me know", "proceed to next phase", "before we proceed")
+        - Keep factual and content-focused
+     3. **Formatted Workflow Message** (mandatory): Always end with this exact format:
+
+```markdown
+> **📋 <u>**REVIEW REQUIRED:**</u>**  
+> Please examine the requirements document at: `aidlc-docs/{workflow-id}/inception/requirements/requirements.md`
+
+
+
+> **🚀 <u>**WHAT'S NEXT?**</u>**
+>
+> **You may:**
+>
+> 🔧 **Request Changes** -  Ask for modifications to the requirements if required based on your review 
+> [IF User Stories will be skipped, add this option:]
+> 📝 **Add User Stories** - Choose to Include **User Stories** stage (currently skipped based on project simplicity)  
+> ✅ **Approve & Continue** - Approve requirements and proceed to **[User Stories/Workflow Planning]**
+
+---
+```
+
+**Note**: Include the "Add User Stories" option only when User Stories stage will be skipped. Replace [User Stories/Workflow Planning] with the actual next stage name.
+
+   - Wait for explicit user approval before proceeding
+   - Record approval response with timestamp
+   - Update Requirements Analysis stage complete in aidlc-state.md