olympus-ai 4.4.5 → 4.4.7

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "olympus-ai",
-  "version": "4.4.5",
+  "version": "4.4.7",
   "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.4.5";
+export declare const VERSION = "4.4.7";
 /** 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.5';
+export const VERSION = '4.4.7';
 /**
  * Read a content file from the resources/ directory.
  *

package/package.json

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

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

@@ -31,6 +31,12 @@ B) Review a previous stage ([Show available stages])
    - **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
+   - **Construction In-Progress Artifacts**: Before creating any new construction artifacts, scan for existing ones:
+     - Check `construction/plans/` for code generation plans
+     - Check `construction/u-*-{unit-name}/` for legacy per-unit artifacts
+     - Check for partially-generated code files referenced in any existing plan
+     - Present an inventory of found artifacts to the user: "Found N existing construction artifacts: [list]. These will be loaded as the starting point."
+     - Do NOT create new artifacts that duplicate existing ones — always check first
    - **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

package/resources/rules/construction/code-generation.md

@@ -51,6 +51,19 @@ When managing code generation, the orchestrator MUST leverage Olympus capabiliti
 
 # PART 1: PLANNING
 
+## Step 0: Check for Existing Artifacts (Idempotency Gate)
+- [ ] Scan `aidlc-docs/{workflow-id}/construction/` for any existing code generation plan for this unit
+  - Check canonical path: `construction/plans/{unit-name}-code-generation-plan.md`
+  - Check legacy paths: `construction/u-*-{unit-name}/code-generation-plan*`, `construction/{unit-name}/code-generation-plan*`
+- [ ] If a plan exists:
+  - Read it and present a summary to the user
+  - Ask: "An existing code generation plan was found at `{path}`. Would you like to (A) reuse it as-is, (B) update it, or (C) replace it with a new plan?"
+  - If at a non-canonical path, migrate it to the canonical location: `construction/plans/{unit-name}-code-generation-plan.md`
+  - If reusing (A): skip to Step 7 (approval) with the existing plan
+  - If updating (B): load it as the starting point for Steps 1-6
+  - If replacing (C): proceed to Step 1 as normal
+- [ ] If no plan exists: proceed to Step 1
+
 ## Step 1: Analyze Unit Context
 - [ ] Read unit design artifacts from Unit Design Generation
 - [ ] Read unit story map to understand assigned stories
@@ -92,7 +105,7 @@ When managing code generation, the orchestrator MUST leverage Olympus capabiliti
   - Service boundaries and responsibilities
 
 ## Step 4: Create Unit Plan Document
-- [ ] Save complete plan as `aidlc-docs/construction/plans/{unit-name}-code-generation-plan.md`
+- [ ] Save complete plan as `aidlc-docs/{workflow-id}/construction/plans/{unit-name}-code-generation-plan.md` (CANONICAL PATH — do not use any other location)
 - [ ] Include step numbering (Step 1, Step 2, etc.)
 - [ ] Include unit context and dependencies
 - [ ] Include story traceability
@@ -239,6 +252,12 @@ When managing code generation, the orchestrator MUST leverage Olympus capabiliti
 - **STORY TRACEABILITY**: Mark unit stories [x] when functionality is implemented
 - **RESPECT DEPENDENCIES**: Only implement when unit dependencies are satisfied
 
+### Canonical Path Rules
+- **Code generation plans MUST be saved at**: `aidlc-docs/{workflow-id}/construction/plans/{unit-name}-code-generation-plan.md`
+- Do NOT create code generation plans at any other path (e.g., `construction/u-nnn-{name}/`, `construction/{name}/`)
+- If a plan is found at a non-canonical path during Step 0, migrate it to the canonical location before proceeding
+- Per-unit directories (`construction/u-nnn-{name}/`) are reserved for construction output artifacts (code summaries, documentation), NOT plans
+
 ### Automation Friendly Code Rules
 When generating UI code (web, mobile, desktop), ensure elements are automation-friendly:
 - Add `data-testid` attributes to interactive elements (buttons, inputs, links, forms)

package/resources/skills/brief/SKILL.md

@@ -23,6 +23,16 @@ Determine which mode to run based on the input:
 
 If the input already contains substantial context (e.g., the user pasted a feature description, a ticket, or a problem statement), extract what you can from it and confirm rather than re-asking. The goal is a conversation, not a questionnaire.
 
+### Thin-Context Handling
+
+When the input is vague or minimal (e.g., "we need password reset" with no further detail), don't generate a brief full of assumptions. Instead:
+
+1. **Generate the brief anyway** — a brief with "Unknown" sections is better than no brief. Fill in what you can reasonably infer from the request itself.
+2. **Mark unknowns explicitly** — for each unknown section, include the specific questions you would have asked. This turns the brief into a structured interview guide for the next conversation. Example: "Unknown — Who is requesting this? What is the business impact? Is there a deadline?"
+3. **Invest in Notes for Elaboration** — when context is thin, this section becomes the most valuable part of the brief. List the open questions, risks, and decisions the elaboration team needs to resolve.
+
+The goal is that even a thin-context brief is useful — it captures what is known, makes the unknowns visible, and gives the team a structured starting point for discussion.
+
 ---
 
 ## Single Mode
@@ -57,7 +67,7 @@ Have a natural conversation to understand the user's intent. You're trying to fi
 
 ### Generating the Brief
 
-Once you have enough context, generate the brief. Don't wait for perfect information — a brief with a few "TBD" sections is better than no brief.
+Once you have enough context, generate the brief. Don't wait for perfect information — a brief with a few "Unknown" sections is better than no brief.
 
 Create the directory if needed, then write the brief:
 
@@ -69,7 +79,7 @@ Create the directory if needed, then write the brief:
 # Intent Brief: [Name]
 
 **Date:** [ISO date]
-**Author:** [who created it — ask if not obvious]
+**Author:** [who created it — ask if not obvious, default to "Unknown" if not provided]
 **Status:** Draft
 
 ## Problem
@@ -143,6 +153,8 @@ Help the user sequence the items. Ask about:
 
 If the user already has a priority order, confirm it rather than re-deriving it.
 
+**Partial priority ordering:** When some items have an explicit priority (e.g., "Mario requested the first 3") but others don't, preserve the explicit ordering for those items and sequence the remaining items using dependency analysis and risk assessment. Explain your reasoning for the inferred positions — the user should understand why item 4 comes before item 5.
+
 ### Step 4: Generate All Briefs
 
 Write each brief to `.olympus/briefs/{kebab-case-name}.md` using the same template as single mode. Include the priority position in each brief's metadata.
@@ -176,7 +188,19 @@ Write the priority-sequenced index:
 [How this collection should be used — e.g., "Feed into March 30th Mob Elaboration session" or "Input for /plan runs on the EZFacility codebase"]
 ```
 
-After generating all briefs and the index, summarize what was created and offer next steps.
+### Step 6: Identify Cross-Brief Dependencies
+
+After generating all briefs, review the full set and identify items that share components, data models, or user flows. Document these in the index under a dedicated section:
+
+```markdown
+## Cross-Brief Dependencies
+
+- **[Brief A] ↔ [Brief B]** — Share [component/data model/user flow]. Elaborate together or sequence A before B.
+```
+
+This prevents the team from elaborating overlapping items in isolation, which leads to conflicting designs and rework during construction.
+
+After generating all briefs, the index, and cross-brief dependencies, summarize what was created and offer next steps.
 
 ---
 
@@ -193,7 +217,7 @@ This integration point will be formalized in a future update to the `/plan` skil
 ## Principles
 
 - **Capture intent, not design.** Briefs describe problems and outcomes. Solutions, architecture, and implementation details belong to `/plan` and Mob Elaboration.
-- **Good enough beats perfect.** A brief with a "TBD" section is better than no brief. The elaboration team will fill gaps — that's their job.
+- **Good enough beats perfect.** A brief with an "Unknown" section is better than no brief. The elaboration team will fill gaps — that's their job.
 - **Respect the user's time.** In batch mode especially, don't ask questions you can infer the answers to. Template similar items. Be efficient.
 - **Standalone value.** A brief should be useful even if `/plan` is never run — it's a communication artifact that helps teams align on what needs to be built and why.
 - **No codebase analysis.** Briefs are business-context documents. Technical discovery, reverse engineering, and architecture decisions happen in `/plan`. Don't read source code or suggest implementations.