olympus-ai 4.5.1 → 4.5.2

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "olympus-ai",
-  "version": "4.5.1",
+  "version": "4.5.2",
   "description": "Olympus: Multi-agent orchestration for Claude Code. Summon the gods of code.",
   "author": {
     "name": "mikev10",

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.5.1";
+export declare const VERSION = "4.5.2";
 /** 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.5.1';
+export const VERSION = '4.5.2';
 /**
  * Read a content file from the resources/ directory.
  *

package/package.json

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

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

@@ -182,16 +182,74 @@ When done, let me know and I will incorporate your approved findings into the re
 ### 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
+   - Begin with YAML frontmatter mirroring intent.md classification:
+
+```yaml
+---
+workflow: "{workflow-id}"
+pathway: "{greenfield|brownfield-enhancement|brownfield-refactor|bugfix|migration}"
+scope: "{single-file|single-component|multi-component|system-wide|cross-system}"
+complexity: "{trivial|simple|moderate|complex}"
+depth: "{minimal|standard|comprehensive}"
+status: draft
+created: "{ISO-8601}"
+---
+```
+
+   - Include intent analysis summary after frontmatter:
+     - User request (verbatim or paraphrased)
+     - Request type classification
      - Scope estimate
      - Complexity estimate
-   - Include both functional and non-functional requirements
-   - Include scenario coverage when relevant (use cases, edge cases, error scenarios)
-   - Incorporate user's answers to clarifying questions
-   - Provide brief summary of key requirements
    - **Do NOT include a User Stories section** — user stories with personas and acceptance criteria are generated in the dedicated User Stories stage
+   - Incorporate user's answers to clarifying questions
+   - If the requirements introduce 3+ domain-specific terms that aren't self-explanatory, append a `## Glossary` section defining them
+
+#### Depth-Specific Content Guidance
+
+The depth determined in Step 3 controls which sections to include and how much detail each receives:
+
+**Minimal** (clear, simple requests):
+- Intent analysis summary
+- Functional requirements (concise list)
+- Brief key requirements summary
+- Coverage verification (expect most areas N/A with justification)
+
+**Standard** (normal complexity):
+- All Minimal sections, plus:
+- Non-functional requirements
+- Scenario coverage (key use cases and error scenarios)
+- Coverage verification (expect most areas Covered)
+
+**Comprehensive** (complex, high-risk):
+- All Standard sections, plus:
+- Detailed scenario coverage with edge cases and error scenarios
+- Dedicated Business Context section
+- Dedicated Technical Context section
+- Coverage verification (ALL areas must be Covered or have justified Partial status)
+
+#### 7b. Coverage Verification (MANDATORY)
+
+Include a **Coverage Verification** section at the end of `requirements.md`. This maps directly to the six coverage areas evaluated in Step 5. Every area must be accounted for:
+
+```markdown
+## Coverage Verification
+
+| Area | Status | Section | Notes |
+|------|--------|---------|-------|
+| Functional Requirements | {Covered/Partial/N-A} | {§ section ref} | {justification if Partial or N-A} |
+| Non-Functional Requirements | {Covered/Partial/N-A} | {§ section ref} | {justification if Partial or N-A} |
+| Scenario Coverage | {Covered/Partial/N-A} | {§ section ref} | {justification if Partial or N-A} |
+| Business Context | {Covered/Partial/N-A} | {§ section ref} | {justification if Partial or N-A} |
+| Technical Context | {Covered/Partial/N-A} | {§ section ref} | {justification if Partial or N-A} |
+| Quality Attributes | {Covered/Partial/N-A} | {§ section ref} | {justification if Partial or N-A} |
+```
+
+**Rules**:
+- **Covered**: The area has a dedicated section with substantive content
+- **Partial**: The area is addressed but incomplete — the Notes column MUST explain what is missing and why
+- **N-A**: The area does not apply to this workflow — the Notes column MUST justify the exclusion
+- If any area is Partial, consider whether follow-up questions are needed before finalizing
 
 ### Step 8: MANDATORY: Update State Tracking
 

package/resources/rules/inception/units-generation.md

@@ -74,6 +74,7 @@ Unit boundaries define the scope of all subsequent design and code generation wo
 - [ ] Generate `aidlc-docs/inception/application-design/unit-of-work.md` with unit definitions and responsibilities
 - [ ] Generate `aidlc-docs/inception/application-design/unit-of-work-dependency.md` with dependency matrix
 - [ ] Generate `aidlc-docs/inception/application-design/unit-of-work-story-map.md` mapping stories to units
+- [ ] **Conditional** (complexity >= moderate AND units >= 3): Generate per-unit briefs in `aidlc-docs/inception/application-design/units/{unit-slug}/unit-brief.md`
 - [ ] **Greenfield only**: Document code organization strategy in `unit-of-work.md` (see code-generation.md for structure patterns)
 - [ ] Validate unit boundaries and dependencies
 - [ ] Ensure all stories are assigned to units
@@ -163,9 +164,63 @@ If the analysis in step 7 reveals ANY ambiguous answers, you MUST:
 - [ ] Save all generated artifacts
 - **Do NOT proceed without completing state updates**
 
+## Step 14b: Generate Unit Briefs (CONDITIONAL)
+
+**Condition**: Generate unit briefs when complexity is `moderate` or `complex` AND the decomposition produced 3 or more units. If the condition is not met, skip to Step 15.
+
+For each unit defined in `unit-of-work.md`, create a per-unit brief file:
+
+**Path**: `aidlc-docs/{workflowId}/inception/application-design/units/{unit-slug}/unit-brief.md`
+
+Where `{unit-slug}` follows the existing convention (e.g., `UNIT-001-foundation`).
+
+```markdown
+---
+unit: "U-NNN"
+intent: "{workflow-id}"
+complexity: "{S|M|L|XL}"
+status: draft
+created: "{ISO-8601}"
+---
+
+# Unit Brief: U-NNN — {Name}
+
+## Purpose and Scope
+{What this unit handles. Explicit boundary — what is IN vs OUT of this unit relative to other units.}
+
+## Requirements Mapping
+| Requirement | Description | Coverage |
+|-------------|-------------|----------|
+| FR-1 | {description} | Covered / Partial |
+
+## Key Domain Entities
+| Entity | Description | Owned by this unit? |
+|--------|-------------|---------------------|
+| {Entity} | {description} | Yes / Shared with U-NNN |
+
+## Technical Context
+{Tech stack, integration points, data storage, and APIs relevant to this unit.
+Reference existing system components if brownfield.}
+
+## Dependencies
+- **Depends on**: {list units this unit requires to be built first, or "None"}
+- **Depended on by**: {list units that require this unit, or "None"}
+
+## Success Criteria
+- [ ] {Verifiable outcome specific to this unit}
+- [ ] {Verifiable outcome specific to this unit}
+```
+
+**Rules**:
+- Unit briefs supplement, not replace, `unit-of-work.md` — the overview document remains the single index of all units
+- Requirements Mapping must trace back to FRs in `requirements.md`
+- Dependencies must be consistent with `unit-of-work-dependency.md`
+- Keep briefs concise — detailed functional design happens in the Construction phase
+
 ## Step 15: Continue or Complete
 - [ ] If more steps remain, return to Step 12
 - [ ] If all steps complete, verify units are ready for design stages
+- [ ] If unit briefs were generated (Step 14b), verify consistency across all briefs
 - [ ] Mark Units Generation stage as complete
 
 ## Step 16: Present Completion Message

package/resources/rules/inception/user-stories.md

@@ -163,9 +163,46 @@ For medium priority cases, execute user stories if ANY of these apply:
   - [ ] Generate stories.md with user stories following INVEST criteria
   - [ ] Generate personas.md with user archetypes and characteristics
   - [ ] Ensure stories are Independent, Negotiable, Valuable, Estimable, Small, Testable
-  - [ ] Include acceptance criteria for each story
+  - [ ] Include acceptance criteria for each story (Gherkin Given/When/Then format)
+  - [ ] Include edge cases for non-trivial stories
   - [ ] Map personas to relevant user stories
 
+### Story Naming Convention (MANDATORY)
+
+All stories MUST use `S-NNN` IDs (zero-padded to three digits, sequential within the workflow). This is consistent with `U-NNN` for units and `BOLT-NNN` for bolts.
+
+### Story Template (MANDATORY)
+
+Each story in `stories.md` MUST follow this structure:
+
+```markdown
+### S-NNN: {Story Title}
+
+**Persona**: {persona name from personas.md}
+**Priority**: {must | should | could}
+
+> As a **{persona}**, I want **{capability}**, so that **{benefit}**.
+
+#### Acceptance Criteria
+- **Given** {precondition}, **when** {action}, **then** {expected result}
+- **Given** {precondition}, **when** {action}, **then** {expected result}
+
+#### Edge Cases
+| Scenario | Expected Behavior |
+|----------|-------------------|
+| {edge case} | {what should happen} |
+
+#### Dependencies
+- Requires: {S-NNN or "None"}
+- Enables: {S-NNN or "None"}
+```
+
+**Rules**:
+- Every story MUST have at least one Given/When/Then acceptance criterion
+- Edge Cases table is MANDATORY for stories with priority `must`, optional for `should`/`could`
+- Dependencies track inter-story ordering — use "None" when the story is independent
+- Priority uses MoSCoW: `must` (required), `should` (important), `could` (nice-to-have)
+
 ## Step 5: Present Story Options
 - Include different approaches for story breakdown in the plan document:
   - **User Journey-Based**: Stories follow user workflows and interactions

package/resources/skills/plan/SKILL.md

@@ -121,6 +121,9 @@ Before generating questions, analyze the `/plan` input and extract what is alrea
 - Infer the problem being solved
 - Identify any mentioned personas or user types
 - Note any explicit constraints or success criteria
+- Infer business context (why now? what motivates this work?)
+- Infer technical context (current system state, relevant technologies, integrations)
+- Estimate priority (must/should/could) and complexity (trivial/simple/moderate/complex)
 - Determine what is genuinely unclear or missing
 
 ### 3b. Generate intent-questions.md
@@ -137,7 +140,10 @@ Based on your description, I've inferred the following. Please correct anything
 - **Problem**: {inferred problem statement}
 - **Primary users**: {inferred personas}
 - **Scope**: {inferred scope}
+- **Business context**: {inferred motivation, else "unclear"}
+- **Technical context**: {inferred current state, else "unclear"}
 - **Success criteria**: {inferred if present, else "unclear"}
+- **Priority**: {inferred must/should/could, else "unclear"}
 
 ---
 
@@ -164,9 +170,9 @@ Z) Other: please specify
 ```
 
 **Question count based on trust level:**
-- Trust 0: 5+ questions (Problem, Personas, Success Metrics, Constraints, Priorities)
-- Trust 1: 3-4 questions (Problem, Personas, Success Metrics, and one more if needed)
-- Trust 2: 2-3 questions (Problem + Success Metrics, omit if clearly answered in input)
+- Trust 0: 6+ questions (Problem, Personas, Business Context, Technical Context, Success Criteria, Constraints, Priority)
+- Trust 1: 4-5 questions (Problem, Personas, Success Criteria, Business Context, and one more if needed)
+- Trust 2: 2-3 questions (Problem + Success Criteria + Business Context, omit if clearly answered in input)
 - Trust 3: 1-2 questions, or 0 if the feature description is comprehensive
 
 **Question format rules:**
@@ -230,6 +236,10 @@ title: "{title}"
 status: draft
 created: "{ISO-8601}"
 author: "prometheus"
+pathway: "{greenfield|brownfield-enhancement|brownfield-refactor|bugfix|migration}"
+scope: "{single-file|single-component|multi-component|system-wide|cross-system}"
+complexity: "{trivial|simple|moderate|complex}"
+priority: "{must|should|could}"
 ---
 
 # INTENT: {Title}
@@ -237,20 +247,30 @@ author: "prometheus"
 ## Problem Statement
 {What problem does this solve? Who is affected? Why does it matter now?}
 
+## Business Context
+{Why is this work happening now? What business driver, compliance requirement,
+user feedback, or strategic goal motivates it? What happens if we don't do this?}
+
 ## User Personas
-- **{Persona 1}**: {Description — role, goals, pain points}
+- **{Persona 1}**: {Role, goals, pain points — 1-2 sentences}
+
+## Technical Context
+{Current system state relevant to this intent. Key technologies, integrations,
+and architectural constraints that shape the solution space. NOT the design —
+just what exists today that matters.}
 
-## Success Metrics
-- {Measurable outcome 1}
+## Success Criteria
+- [ ] {Measurable, verifiable outcome 1}
+- [ ] {Measurable, verifiable outcome 2}
 
 ## Business Constraints
-- {Constraint 1}
+- {Constraint 1 — e.g., timeline, budget, compliance, backwards compatibility}
 
 ## Out of Scope
-- {Explicit exclusion 1}
+- {Explicit exclusion 1 — prevents scope creep during construction}
 ```
 
-Fill all sections from interview answers. Include multiple personas, metrics, constraints, and exclusions as appropriate.
+Fill all sections from interview answers. Include multiple personas, metrics, constraints, and exclusions as appropriate. The frontmatter `pathway`, `scope`, and `complexity` values must align with the classifications determined during the interview. User stories do NOT belong in intent.md — capture personas here; full stories are generated in the User Stories stage.
 
 ### 4b. Initialize checkpoint with inception_stages