owflow 0.5.0 → 0.7.0

package/dist/skills/docs-manager/references/index-md-template.md

@@ -1,73 +1,73 @@
-# INDEX.md Template
-
-Use this structure when generating or updating `.owflow/docs/INDEX.md`. Scan the actual `.owflow/docs/` directory to populate sections dynamically — do not hardcode file lists.
-
-For technical standards, the description MUST enumerate specific practices/conventions documented in the file, not just a generic category description.
-
-```markdown
-# Documentation Index
-
-**IMPORTANT**: Read this file at the beginning of any development task to understand available documentation and standards.
-
-## Quick Reference
-
-### Project Documentation
-
-Project-level documentation covering vision, goals, architecture, and technology choices.
-
-### Technical Standards
-
-Coding standards, conventions, and best practices organized by domain.
-
----
-
-## Project Documentation
-
-Located in `.owflow/docs/project/`
-
-### Vision (`project/vision.md`)
-
-[Brief description of what this file contains]
-
-### Roadmap (`project/roadmap.md`)
-
-[Brief description of what this file contains]
-
-### Tech Stack (`project/tech-stack.md`)
-
-[Brief description of what this file contains]
-
-### Architecture (`project/architecture.md`)
-
-[Brief description of what this file contains - if exists]
-
----
-
-## Technical Standards
-
-### [Category Name] Standards
-
-Located in `.owflow/docs/standards/[category]/`
-
-#### [Standard Name] (`standards/[category]/[name].md`)
-
-[Practice-specific description — enumerate actual conventions, not generic text]
-
-[... repeat for all categories and standards discovered in the directory ...]
-
----
-
-## How to Use This Documentation
-
-1. **Start Here**: Always read this INDEX.md first to understand what documentation exists
-2. **Project Context**: Read relevant project documentation before starting work
-3. **Standards**: Reference appropriate standards when writing code
-4. **Keep Updated**: Update documentation when making significant changes
-5. **Customize**: Adapt all documentation to your project's specific needs
-
-## Updating Documentation
-
-- Project documentation should be updated when goals, tech stack, or architecture changes
-- Technical standards should be updated when team conventions evolve
-- Always update INDEX.md when adding, removing, or significantly changing documentation
-```
+# INDEX.md Template
+
+Use this structure when generating or updating `.owflow/docs/INDEX.md`. Scan the actual `.owflow/docs/` directory to populate sections dynamically — do not hardcode file lists.
+
+For technical standards, the description MUST enumerate specific practices/conventions documented in the file, not just a generic category description.
+
+```markdown
+# Documentation Index
+
+**IMPORTANT**: Read this file at the beginning of any development task to understand available documentation and standards.
+
+## Quick Reference
+
+### Project Documentation
+
+Project-level documentation covering vision, goals, architecture, and technology choices.
+
+### Technical Standards
+
+Coding standards, conventions, and best practices organized by domain.
+
+---
+
+## Project Documentation
+
+Located in `.owflow/docs/project/`
+
+### Vision (`project/vision.md`)
+
+[Brief description of what this file contains]
+
+### Roadmap (`project/roadmap.md`)
+
+[Brief description of what this file contains]
+
+### Tech Stack (`project/tech-stack.md`)
+
+[Brief description of what this file contains]
+
+### Architecture (`project/architecture.md`)
+
+[Brief description of what this file contains - if exists]
+
+---
+
+## Technical Standards
+
+### [Category Name] Standards
+
+Located in `.owflow/docs/standards/[category]/`
+
+#### [Standard Name] (`standards/[category]/[name].md`)
+
+[Practice-specific description — enumerate actual conventions, not generic text]
+
+[... repeat for all categories and standards discovered in the directory ...]
+
+---
+
+## How to Use This Documentation
+
+1. **Start Here**: Always read this INDEX.md first to understand what documentation exists
+2. **Project Context**: Read relevant project documentation before starting work
+3. **Standards**: Reference appropriate standards when writing code
+4. **Keep Updated**: Update documentation when making significant changes
+5. **Customize**: Adapt all documentation to your project's specific needs
+
+## Updating Documentation
+
+- Project documentation should be updated when goals, tech stack, or architecture changes
+- Technical standards should be updated when team conventions evolve
+- Always update INDEX.md when adding, removing, or significantly changing documentation
+```

package/dist/skills/flow-init/SKILL.md

@@ -1,234 +1,234 @@
----
-name: owflow:flow-init
-description: Initialize AI SDLC framework with intelligent project analysis and documentation generation
-argument-hint: "[--standards-from=PATH]"
-user-invocable: true
----
-
-# Initialize AI SDLC Framework
-
-Initialize `.owflow/docs/` with intelligent project analysis and meaningful documentation generation based on actual codebase inspection.
-
-Gates follow the shared contract in [Gate Contract](../orchestrator-framework/references/gate-contract.md).
-
-**NOTE**: This skill invokes other skills and subagents at specific phases. Use the **Task tool with `docs-operator` subagent** (subagent_type: `docs-operator`) for all docs-manager operations, and **Task tool** for project-analyzer. Use the **Skill tool** only for standards-discover (Phase 8, last phase). The Task tool returns control to this skill after completion; the Skill tool does not.
-
-## Entry Gate
-
-PHASE 1 (Pre-flight Checks) below IS the entry gate of this skill. It validates the `--standards-from=PATH` argument (resolve it; abort with an informative message if the referenced project lacks `.owflow/docs/standards/`) and detects the pre-existing state of `.owflow/` — routing to backup, update, or cancel accordingly. Complete it before any other phase.
-
-## Phase Configuration
-
-| Phase | Subject                            | activeForm                       |
-| ----- | ---------------------------------- | -------------------------------- |
-| 1     | Pre-flight checks                  | Running pre-flight checks        |
-| 2     | Analyze project codebase           | Analyzing project codebase       |
-| 3     | Present findings & gather context  | Gathering project context        |
-| 4     | Select standards to initialize     | Selecting standards              |
-| 5     | Initialize documentation structure | Initializing documentation       |
-| 6     | Generate project documentation     | Generating project documentation |
-| 7     | Validate                           | Validating initialization        |
-| 8     | Discover coding standards          | Discovering coding standards     |
-
-**Task Tracking**: Before Phase 1, use `TaskCreate` for all phases (pending), then set sequential dependencies with `TaskUpdate addBlockedBy`. At each phase: `TaskUpdate` to `in_progress` → execute → `TaskUpdate` to `completed`. If skipped (e.g., user selects "Update existing"), mark skipped phases as `completed` with `metadata: {skipped: true}`.
-
----
-
-## PHASE 1: Pre-flight Checks
-
-**If `--standards-from=PATH` is provided:**
-
-1. Resolve the path (absolute or relative to current working directory)
-2. Check if `PATH/.owflow/docs/standards/` exists. If not, inform the user and stop — the specified project doesn't have owflow standards initialized.
-3. Store the resolved standards source path for use in Phases 4 and 5.
-
-Check if `.owflow/` directory already exists.
-
-**If exists**, use question:
-
-- Options: "Backup and reinitialize", "Update existing documentation", "Cancel"
-- If "Backup": Create `.owflow.backup-$(date +%Y%m%d-%H%M%S)/` using Bash tool
-- If "Update": Skip to PHASE 6 (documentation generation only)
-- If "Cancel": Stop execution
-
----
-
-## PHASE 2: Project Analysis
-
-Invoke `project-analyzer` subagent via the Task tool.
-
-Wait for completion. Store analysis results for use in Phases 3 and 6.
-
----
-
-## PHASE 3: Present Findings & Gather Context
-
-**Step 1**: Present analysis results to the user (project type, primary language/framework, architecture, tech stack, conventions, strengths/opportunities).
-
-**Step 2**: Use question to confirm analysis accuracy. If corrections needed, collect them.
-
-**Step 3**: Gather additional context via question (adapt to project type):
-
-1. Project name (if not obvious)
-2. Project description (1-2 sentences)
-3. Primary goals (adapt question to new/existing/legacy project)
-4. Team context (optional)
-5. Special requirements (optional)
-
-**Step 4**: Ask which project documentation to generate using question (multi-select):
-
-- "Vision" — Project vision, goals, and purpose
-- "Roadmap" — Development roadmap and planned features
-- "Tech Stack" — Technology choices and rationale (ALWAYS selected, required)
-- "Architecture" — System architecture and design patterns (optional)
-
-Smart defaults based on `projectArchitectureType`:
-
-- Standard/Frontend-only/Backend-only: All selected
-- Monorepo/Umbrella: Only "Tech Stack" selected
-
-Store selections for Phase 6.
-
----
-
-## PHASE 4: Select Standards to Initialize
-
-Before presenting options, explain to the user:
-
-- **What standards are**: Coding standards are documented conventions and best practices (naming, error handling, testing patterns, etc.) that guide consistent development across the project.
-- **Starting point**: If `--standards-from` was provided, standards come from the referenced project. Otherwise, the plugin includes generic built-in standards. Either way, they serve as a starting point and can be fully customized or extended later.
-
-**Determine available categories:**
-
-- **If `--standards-from` was provided**: Scan `PATH/.owflow/docs/standards/*/` to discover all available categories from the external project (may include custom categories beyond the baseline global/frontend/backend/testing).
-- **Otherwise**: Use built-in baseline categories (global, frontend, backend, testing).
-
-Calculate smart defaults based on analysis:
-
-- **Global**: Always recommended (if available)
-- **Frontend**: If frontend framework detected or projectArchitectureType includes frontend (if available)
-- **Backend**: If backend framework detected or projectArchitectureType includes backend (if available)
-- **Testing**: Always recommended (if available)
-
-Also scan `.owflow/docs/standards/*/` for any existing custom categories to include.
-
-Show smart defaults summary (noting the source: external project or built-in), then use question:
-
-- "Use smart defaults" → proceed with calculated defaults
-- "Customize selection" → show multi-select with all discovered categories + "Add custom category" option
-
-Custom categories: if user adds a new category, create the directory and include it in the selection.
-
-Store selection for Phase 5.
-
----
-
-## PHASE 5: Initialize Documentation Structure
-
-**Invoke `docs-operator` subagent** via Task tool (subagent_type: `docs-operator`) with prompt:
-
-> "Initialize documentation structure. Standards selection: [array from Phase 4]. [If --standards-from was provided: Standards source path: [resolved path]/.owflow/docs/standards/. Copy standards from this external path instead of built-in defaults.] Only copy selected standard categories. Do NOT copy project templates — only create the project/ directory. Project documentation will be generated in Phase 6 with real content from project analysis. Create placeholder sections in INDEX.md for skipped categories."
-
-Wait for docs-operator to complete, then immediately proceed to Phase 6.
-
----
-
-## PHASE 6: Generate Project Documentation
-
-**IMPORTANT**: Only generate docs selected in Phase 3.
-
-For each selected doc type, read the corresponding reference template:
-
-- Vision selected → Read `references/vision-templates.md`, select template by project type (new/existing/legacy)
-- Roadmap selected → Read `references/roadmap-templates.md`, select template by project type
-- Tech Stack (always) → Read `references/tech-stack-template.md`
-- Architecture selected → Read `references/architecture-template.md`
-
-Fill templates using:
-
-- Analysis report data (tech stack, age, structure)
-- User-provided context from Phase 3 (goals, users, requirements)
-- Auto-detected project characteristics
-
-Write each file to `.owflow/docs/project/`.
-
-**Diagram refinement (content-preserving, do NOT replace prose):**
-
-- If Architecture doc is selected and `.owflow/docs/project/architecture.md` exists:
-  1. Invoke Skill tool: `diagrams-mermaid`
-  2. Pass context from analysis + generated architecture content
-  3. Add Mermaid sections that **refine** the document:
-     - `## Visual Architecture Context` (prefer `C4Context` or `C4Container`)
-     - `## Component Communication Flow` (prefer `sequenceDiagram` or `flowchart`)
-  4. Keep existing architecture narrative intact; diagrams must supplement, not replace sections.
-
-- If Tech Stack doc is selected and `.owflow/docs/project/tech-stack.md` exists:
-  1. Invoke Skill tool: `diagrams-mermaid`
-  2. Add one lightweight visual section (e.g., runtime/build dependency flow) only if context is sufficient
-  3. If context is insufficient, keep text-only output and list missing details (no invented dependencies).
-
----
-
-## PHASE 7: Validate → Exit Gate
-
-**Step 1**: Invoke `docs-operator` subagent via Task tool (subagent_type: `docs-operator`) with prompt:
-
-> "Regenerate INDEX.md to include all newly created project documentation. Then verify AGENTS.md is properly integrated with .owflow/docs/ documentation."
-
-Wait for docs-operator to complete, then immediately continue with Step 2.
-
-**Step 2**: Run validation checks:
-
-- Verify INDEX.md exists
-- Verify tech-stack.md exists (required)
-- Verify selected docs exist
-- Verify selected standards directories exist
-- Verify AGENTS.md integration
-
-**Step 3: Results box** — present the summary as:
-
-```markdown
-## ✅ FLOW INIT COMPLETE — <project name>
-
-**Project type** — [type, language, framework, architecture]
-**Structure** — [tree with check marks for created items]
-**Docs** — [which docs generated, which standards initialized]
-**Standards** — [discovered count, applied]
-**Key findings** — [strengths, opportunities]
-
-**Created** — `.owflow/docs/INDEX.md`
-```
-
-**Step 4: Results-acceptance question** — use `question` — "Are these results correct?" with options:
-
-- **Accept** — initialization is complete; print next steps below.
-- **Adjust** — regenerate the affected artifact (analysis, doc, standards) with the user's corrections, then re-present the results box.
-- **Discuss** — walk through the generated structure and findings in more depth; then re-ask.
-- **Stop here** — end; everything is already written to `.owflow/docs/`.
-
-**Next steps (after Accept)**:
-
-1. Review and customize the generated documentation and standards for your team
-2. Start development with `/owflow:development "<task description>"` (or project work)
-3. Keep documentation current via `/owflow:standards-update "<convention>"`
-
----
-
-## PHASE 8: Discover Coding Standards
-
-Invoke the `standards-discover` skill via Skill tool with `--scope=full` to automatically discover coding standards from the project's config files, source code patterns, documentation, and external sources.
-
-> "Run standards discovery with --scope=full. This is being invoked as part of project initialization."
-
-The standards-discover skill handles its own user interaction (presenting findings by confidence tier, asking for approval). Let it run its full workflow — this is the last phase of init, so context handoff is fine here.
-
-After completion, display a brief summary of how many standards were discovered and applied.
-
----
-
-## Error Handling Principles
-
-- If `.owflow/docs/` creation fails: check permissions, suggest manual creation
-- If project-analyzer fails: offer to proceed with manual input only
-- If docs-manager fails: offer retry (max 2 attempts), then manual instructions
-- Never auto-rollback — always ask user before destructive actions
+---
+name: owflow:flow-init
+description: Initialize AI SDLC framework with intelligent project analysis and documentation generation
+argument-hint: "[--standards-from=PATH]"
+user-invocable: true
+---
+
+# Initialize AI SDLC Framework
+
+Initialize `.owflow/docs/` with intelligent project analysis and meaningful documentation generation based on actual codebase inspection.
+
+Gates follow the shared contract in [Gate Contract](../orchestrator-framework/references/gate-contract.md).
+
+**NOTE**: This skill invokes other skills and subagents at specific phases. Use the **Task tool with `docs-operator` subagent** (subagent_type: `docs-operator`) for all docs-manager operations, and **Task tool** for project-analyzer. Use the **Skill tool** only for standards-discover (Phase 8, last phase). The Task tool returns control to this skill after completion; the Skill tool does not.
+
+## Entry Gate
+
+PHASE 1 (Pre-flight Checks) below IS the entry gate of this skill. It validates the `--standards-from=PATH` argument (resolve it; abort with an informative message if the referenced project lacks `.owflow/docs/standards/`) and detects the pre-existing state of `.owflow/` — routing to backup, update, or cancel accordingly. Complete it before any other phase.
+
+## Phase Configuration
+
+| Phase | Subject                            | activeForm                       |
+| ----- | ---------------------------------- | -------------------------------- |
+| 1     | Pre-flight checks                  | Running pre-flight checks        |
+| 2     | Analyze project codebase           | Analyzing project codebase       |
+| 3     | Present findings & gather context  | Gathering project context        |
+| 4     | Select standards to initialize     | Selecting standards              |
+| 5     | Initialize documentation structure | Initializing documentation       |
+| 6     | Generate project documentation     | Generating project documentation |
+| 7     | Validate                           | Validating initialization        |
+| 8     | Discover coding standards          | Discovering coding standards     |
+
+**Task Tracking**: Before Phase 1, use `TaskCreate` for all phases (pending), then set sequential dependencies with `TaskUpdate addBlockedBy`. At each phase: `TaskUpdate` to `in_progress` → execute → `TaskUpdate` to `completed`. If skipped (e.g., user selects "Update existing"), mark skipped phases as `completed` with `metadata: {skipped: true}`.
+
+---
+
+## PHASE 1: Pre-flight Checks
+
+**If `--standards-from=PATH` is provided:**
+
+1. Resolve the path (absolute or relative to current working directory)
+2. Check if `PATH/.owflow/docs/standards/` exists. If not, inform the user and stop — the specified project doesn't have owflow standards initialized.
+3. Store the resolved standards source path for use in Phases 4 and 5.
+
+Check if `.owflow/` directory already exists.
+
+**If exists**, use question:
+
+- Options: "Backup and reinitialize", "Update existing documentation", "Cancel"
+- If "Backup": Create `.owflow.backup-$(date +%Y%m%d-%H%M%S)/` using Bash tool
+- If "Update": Skip to PHASE 6 (documentation generation only)
+- If "Cancel": Stop execution
+
+---
+
+## PHASE 2: Project Analysis
+
+Invoke `project-analyzer` subagent via the Task tool.
+
+Wait for completion. Store analysis results for use in Phases 3 and 6.
+
+---
+
+## PHASE 3: Present Findings & Gather Context
+
+**Step 1**: Present analysis results to the user (project type, primary language/framework, architecture, tech stack, conventions, strengths/opportunities).
+
+**Step 2**: Use question to confirm analysis accuracy. If corrections needed, collect them.
+
+**Step 3**: Gather additional context via question (adapt to project type):
+
+1. Project name (if not obvious)
+2. Project description (1-2 sentences)
+3. Primary goals (adapt question to new/existing/legacy project)
+4. Team context (optional)
+5. Special requirements (optional)
+
+**Step 4**: Ask which project documentation to generate using question (multi-select):
+
+- "Vision" — Project vision, goals, and purpose
+- "Roadmap" — Development roadmap and planned features
+- "Tech Stack" — Technology choices and rationale (ALWAYS selected, required)
+- "Architecture" — System architecture and design patterns (optional)
+
+Smart defaults based on `projectArchitectureType`:
+
+- Standard/Frontend-only/Backend-only: All selected
+- Monorepo/Umbrella: Only "Tech Stack" selected
+
+Store selections for Phase 6.
+
+---
+
+## PHASE 4: Select Standards to Initialize
+
+Before presenting options, explain to the user:
+
+- **What standards are**: Coding standards are documented conventions and best practices (naming, error handling, testing patterns, etc.) that guide consistent development across the project.
+- **Starting point**: If `--standards-from` was provided, standards come from the referenced project. Otherwise, the plugin includes generic built-in standards. Either way, they serve as a starting point and can be fully customized or extended later.
+
+**Determine available categories:**
+
+- **If `--standards-from` was provided**: Scan `PATH/.owflow/docs/standards/*/` to discover all available categories from the external project (may include custom categories beyond the baseline global/frontend/backend/testing).
+- **Otherwise**: Use built-in baseline categories (global, frontend, backend, testing).
+
+Calculate smart defaults based on analysis:
+
+- **Global**: Always recommended (if available)
+- **Frontend**: If frontend framework detected or projectArchitectureType includes frontend (if available)
+- **Backend**: If backend framework detected or projectArchitectureType includes backend (if available)
+- **Testing**: Always recommended (if available)
+
+Also scan `.owflow/docs/standards/*/` for any existing custom categories to include.
+
+Show smart defaults summary (noting the source: external project or built-in), then use question:
+
+- "Use smart defaults" → proceed with calculated defaults
+- "Customize selection" → show multi-select with all discovered categories + "Add custom category" option
+
+Custom categories: if user adds a new category, create the directory and include it in the selection.
+
+Store selection for Phase 5.
+
+---
+
+## PHASE 5: Initialize Documentation Structure
+
+**Invoke `docs-operator` subagent** via Task tool (subagent_type: `docs-operator`) with prompt:
+
+> "Initialize documentation structure. Standards selection: [array from Phase 4]. [If --standards-from was provided: Standards source path: [resolved path]/.owflow/docs/standards/. Copy standards from this external path instead of built-in defaults.] Only copy selected standard categories. Do NOT copy project templates — only create the project/ directory. Project documentation will be generated in Phase 6 with real content from project analysis. Create placeholder sections in INDEX.md for skipped categories."
+
+Wait for docs-operator to complete, then immediately proceed to Phase 6.
+
+---
+
+## PHASE 6: Generate Project Documentation
+
+**IMPORTANT**: Only generate docs selected in Phase 3.
+
+For each selected doc type, read the corresponding reference template:
+
+- Vision selected → Read `references/vision-templates.md`, select template by project type (new/existing/legacy)
+- Roadmap selected → Read `references/roadmap-templates.md`, select template by project type
+- Tech Stack (always) → Read `references/tech-stack-template.md`
+- Architecture selected → Read `references/architecture-template.md`
+
+Fill templates using:
+
+- Analysis report data (tech stack, age, structure)
+- User-provided context from Phase 3 (goals, users, requirements)
+- Auto-detected project characteristics
+
+Write each file to `.owflow/docs/project/`.
+
+**Diagram refinement (content-preserving, do NOT replace prose):**
+
+- If Architecture doc is selected and `.owflow/docs/project/architecture.md` exists:
+  1. Invoke Skill tool: `diagrams-mermaid` with target file `.owflow/docs/project/architecture.md` (the skill writes the diagrams into the file and themes them github-dark by default)
+  2. Pass context from analysis + generated architecture content
+  3. Add Mermaid sections that **refine** the document:
+     - `## Visual Architecture Context` (architecture view: `flowchart` with subgraphs)
+     - `## Component Communication Flow` (prefer `sequenceDiagram` or `flowchart`)
+  4. Keep existing architecture narrative intact; diagrams must supplement, not replace sections.
+
+- If Tech Stack doc is selected and `.owflow/docs/project/tech-stack.md` exists:
+  1. Invoke Skill tool: `diagrams-mermaid` with target file `.owflow/docs/project/tech-stack.md`
+  2. Add one lightweight visual section (e.g., runtime/build dependency flow) only if context is sufficient
+  3. If context is insufficient, keep text-only output and list missing details (no invented dependencies).
+
+---
+
+## PHASE 7: Validate → Exit Gate
+
+**Step 1**: Invoke `docs-operator` subagent via Task tool (subagent_type: `docs-operator`) with prompt:
+
+> "Regenerate INDEX.md to include all newly created project documentation. Then verify AGENTS.md is properly integrated with .owflow/docs/ documentation."
+
+Wait for docs-operator to complete, then immediately continue with Step 2.
+
+**Step 2**: Run validation checks:
+
+- Verify INDEX.md exists
+- Verify tech-stack.md exists (required)
+- Verify selected docs exist
+- Verify selected standards directories exist
+- Verify AGENTS.md integration
+
+**Step 3: Results box** — present the summary as:
+
+```markdown
+## ✅ FLOW INIT COMPLETE — <project name>
+
+**Project type** — [type, language, framework, architecture]
+**Structure** — [tree with check marks for created items]
+**Docs** — [which docs generated, which standards initialized]
+**Standards** — [discovered count, applied]
+**Key findings** — [strengths, opportunities]
+
+**Created** — `.owflow/docs/INDEX.md`
+```
+
+**Step 4: Results-acceptance question** — use `question` — "Are these results correct?" with options:
+
+- **Accept** — initialization is complete; print next steps below.
+- **Adjust** — regenerate the affected artifact (analysis, doc, standards) with the user's corrections, then re-present the results box.
+- **Discuss** — walk through the generated structure and findings in more depth; then re-ask.
+- **Stop here** — end; everything is already written to `.owflow/docs/`.
+
+**Next steps (after Accept)**:
+
+1. Review and customize the generated documentation and standards for your team
+2. Start development with `/owflow:development "<task description>"` (or project work)
+3. Keep documentation current via `/owflow:standards-update "<convention>"`
+
+---
+
+## PHASE 8: Discover Coding Standards
+
+Invoke the `standards-discover` skill via Skill tool with `--scope=full` to automatically discover coding standards from the project's config files, source code patterns, documentation, and external sources.
+
+> "Run standards discovery with --scope=full. This is being invoked as part of project initialization."
+
+The standards-discover skill handles its own user interaction (presenting findings by confidence tier, asking for approval). Let it run its full workflow — this is the last phase of init, so context handoff is fine here.
+
+After completion, display a brief summary of how many standards were discovered and applied.
+
+---
+
+## Error Handling Principles
+
+- If `.owflow/docs/` creation fails: check permissions, suggest manual creation
+- If project-analyzer fails: offer to proceed with manual input only
+- If docs-manager fails: offer retry (max 2 attempts), then manual instructions
+- Never auto-rollback — always ask user before destructive actions