@vpxa/aikit 0.1.74 → 0.1.75

package/scaffold/{compiled → dist/compiled}/flows-data.mjs

@@ -1,7 +1,4 @@
-// Auto-generated by scaffold/compile.mjs — DO NOT EDIT
-export const FLOWS = {
-  "_epilogue": [
-    { file: "steps/docs-sync/README.md", content: `# Epilogue: Documentation Sync
+const e={_epilogue:[{file:`steps/docs-sync/README.md`,content:`# Epilogue: Documentation Sync
 
 > **This is a mandatory epilogue step.** It runs automatically after every flow completes to keep project documentation synchronized with code changes.
 
@@ -120,260 +117,185 @@ If the flow's changes don't warrant doc updates (e.g., pure bug fix with no reve
 - [ ] \`docs/\` bootstrapped with tool outputs if it didn't exist
 - [ ] Relevant docs created or updated (or skipped with reason)
 - [ ] \`docs/README.md\` index is current
-- [ ] No placeholder/empty docs created — all content tool-generated or hand-written with purpose` },
-  ],
-  "aikit-advanced": [
-    { file: "README.md", content: `# aikit:advanced — Full Development Flow
-
-Full development flow for **new features, API design, and architecture changes**.
-
-## Steps
-
-| # | Step | Skill | Produces | Requires | Agents |
-|---|------|-------|----------|----------|--------|
-| 1 | **Design Gate** | \`steps/design/README.md\` | \`design-decisions.md\` | — | Researcher-Alpha/Beta/Gamma/Delta |
-| 2 | **Specification** | \`steps/spec/README.md\` | \`spec.md\` | \`design-decisions.md\` | Researcher-Alpha |
-| 3 | **Planning** | \`steps/plan/README.md\` | \`plan.md\` | \`spec.md\` | Planner, Explorer |
-| 4 | **Task Breakdown** | \`steps/task/README.md\` | \`tasks.md\` | \`plan.md\` | Planner, Architect-Reviewer-Alpha |
-| 5 | **Execution** | \`steps/execute/README.md\` | \`progress.md\` | \`tasks.md\` | Orchestrator, Implementer, Frontend, Refactor |
-| 6 | **Verification** | \`steps/verify/README.md\` | \`verify-report.md\` | \`progress.md\` | Code-Reviewer-Alpha/Beta, Architect-Reviewer-Alpha/Beta, Security |
-
-## How It Works
-
-Each step has a **README.md** file that contains the detailed instructions for the agent(s) executing that step. The Orchestrator reads the README.md via \`flow_read_instruction\` and delegates work accordingly.
-
-### Step 1: Design Gate
-- Full brainstorming session for new features and architectural changes
-- FORGE classification (\`forge_classify\`) + grounding (\`forge_ground\`) for complex tasks
-- Parallel 4-researcher decision protocol for non-trivial technical decisions
-- ADR generation for critical-tier tasks
-- **Mandatory user stop** before proceeding — design decisions must be approved
-- Read \`steps/design/README.md\` for the full protocol
-
-### Step 2: Specification
-- Elicit requirements from the user, clarify scope
-- Define acceptance criteria and constraints
-- Build on design decisions from the previous step
-
-### Step 3: Planning
-- Deep codebase analysis using \`search\`, \`scope_map\`, \`trace\`, \`analyze_*\`
-- Design architecture based on spec and design decisions
-- Create comprehensive implementation plan with file-level changes
-
-### Step 4: Task Breakdown
-- Break the plan into ordered, atomic implementation tasks
-- Define dependencies between tasks
-- Identify parallel batches for multi-agent execution
-- Architecture review of the task structure
-
-### Step 5: Execution
-- Orchestrator dispatches agents in parallel batches per the task breakdown
-- Each agent gets a scoped task (1-3 files) with clear acceptance criteria
-- TDD: write tests first, then implement
-- Per-batch review cycle: Code Review (dual) → Arch Review → Security → Evidence Gate
-
-### Step 6: Verification
-- Dual code review (Code-Reviewer-Alpha + Beta)
-- Architecture review (Architect-Reviewer-Alpha + Beta)
-- Security review
-- Run \`check({})\` + \`test_run({})\` + \`blast_radius({})\`
-- \`evidence_map({ action: "gate" })\` for final quality gate
-
-## Using Skills Inside Steps
-
-When the Orchestrator activates a step:
-
-1. **Read the instruction first** — \`flow_read_instruction\` returns the README.md for the current step
-2. **Follow step instructions** — the README.md is the primary guide for what to do
-3. **Delegate to listed agents** — each step lists which agents are appropriate
-4. **Produce the required artifact** — the step's \`produces\` field specifies what file to create in the artifacts directory
-5. **Check dependencies** — the step's \`requires\` field lists artifacts from previous steps that must exist
-6. **Report status** — agents report \`DONE\` | \`DONE_WITH_CONCERNS\` | \`NEEDS_CONTEXT\` | \`BLOCKED\` to the Orchestrator
-
-## Artifacts
-
-All artifacts are stored in the run directory under \`.flows/{topic}/\`. The template variable \`{{artifacts_path}}\` resolves to the actual path at runtime.
-` },
-    { file: "steps/design/README.md", content: `# Design Gate — Advanced Flow
-
-Full design gate for new features, API design, and architecture changes. Runs brainstorming, decision protocol, and FORGE classification before specification begins.
-
-## When This Step Runs
-
-This is the **first step** of the \`aikit:advanced\` flow. It runs before specification.
-
-## Instructions
-
-### 1. Task Classification
-
-Classify the task:
-
-| Category | Indicators | Action |
-|----------|-----------|--------|
-| **Bug fix** | Error, regression, "fix" — wrong flow, should use \`aikit:basic\` | → Note mismatch, still run Quick Design |
-| **New feature** | New behavior, new API, new component | → Run **Full Design** below |
-| **Architecture change** | Restructure, migration, new pattern, cross-cutting | → Run **Full Design** with architecture focus |
-
-### 2. FORGE Classification
-
-Run \`forge_classify({ task: "<task description>", files: [<relevant files>] })\` to determine the complexity tier.
-
-| Tier | Meaning | Design Depth |
-|------|---------|-------------|
-| **Floor** | Low risk, well-understood | Quick brainstorm, 1-2 decisions |
-| **Standard** | Moderate complexity | Full brainstorm, parallel research, decision protocol |
-| **Critical** | High risk, contract/security implications | Deep brainstorm, 4-researcher parallel review, ADR required |
-
-### 3. Brainstorming Session
-
-Load the \`brainstorming\` skill and conduct a structured brainstorming session:
-
-1. **Intent Discovery** — What is the user trying to achieve? What problem does this solve?
-2. **Constraint Mapping** — Technical constraints, time constraints, compatibility requirements
-3. **Approach Exploration** — Generate 2-4 possible approaches
-4. **Trade-off Analysis** — Compare approaches on: complexity, maintainability, performance, risk
-
-For **Critical** tier tasks, also explore:
-- Security implications
-- Backward compatibility
-- Migration path
-- Rollback strategy
-
-### 4. Decision Protocol (Standard & Critical tiers)
-
-When technical decisions need resolution:
-
-1. **Identify decisions** — List each decision point with 2+ viable options
-2. **Parallel research** — Delegate to Researcher agents (2 for Standard, 4 for Critical):
-   - Researcher-Alpha: Deep analysis of primary approach
-   - Researcher-Beta: Trade-offs and edge cases of alternatives
-   - Researcher-Gamma: Cross-domain patterns and precedents
-   - Researcher-Delta: Feasibility and performance implications
-3. **Synthesize** — Combine researcher findings into a recommendation per decision
-4. **ADR** (Critical tier) — Load \`adr-skill\` and create an Architecture Decision Record
-
-### 5. FORGE Ground (Standard & Critical tiers)
-
-Run \`forge_ground({ task, root_path: "." })\` to:
-- Scope the affected files and modules
-- Identify unknowns and risks
-- Load existing constraints and conventions
-
-**Auto-upgrade check**: If \`forge_ground\` reveals contract-type unknowns or security concerns not caught by initial \`forge_classify\`, recommend tier upgrade.
-
-### 6. Write \`{{artifacts_path}}/design-decisions.md\` to disk
-
-**You MUST create this file on disk** using \`create_file\` or equivalent — do not just present content in chat.
-
-\`\`\`markdown
-## Design Decisions
-
-### FORGE Assessment
-- **Tier**: {Floor | Standard | Critical}
-- **Rationale**: {why this tier}
-- **Auto-upgrade**: {yes/no — if yes, explain}
-
-### Task Summary
-- **Goal**: {what we're building}
-- **Problem**: {what problem this solves}
-- **Users affected**: {who is impacted}
-
-### Approach
-- **Chosen approach**: {description}
-- **Alternatives considered**: {list with reasons for rejection}
-
-### Key Decisions
-| # | Decision | Choice | Rationale |
-|---|----------|--------|-----------|
-| 1 | {decision} | {choice} | {why} |
-
-### Constraints
-- {constraint 1}
-- {constraint 2}
-
-### Risks
-| Risk | Likelihood | Impact | Mitigation |
-|------|-----------|--------|------------|
-| {risk} | {L/M/H} | {L/M/H} | {mitigation} |
-
-### Open Questions
-- {question 1}
-- {question 2}
-\`\`\`
-
-### 7. Present to User
-
-Use \`present({ format: "html" })\` (or \`format: "browser"\` in CLI mode) to show:
-- Design decisions summary
-- FORGE tier and rationale
-- Key trade-offs
-- Open questions requiring user input
-
-**🛑 MANDATORY STOP** — Wait for user approval of design decisions before proceeding.
-
-### 8. Report to Orchestrator
-
-After user approves:
-- \`DONE\` — design decisions approved, ready for specification
-- \`DONE_WITH_CONCERNS\` — approved with caveats (list them)
-- \`NEEDS_CONTEXT\` — user raised questions that need more research
-
-**Do NOT call \`flow_step\`** — let the Orchestrator advance the flow.
-
-## Outputs
-
-Write \`{{artifacts_path}}/design-decisions.md\` to disk. **You MUST create this file** using \`create_file\` or equivalent — do not just present content in chat. This file is a prerequisite for the next step.
-
-## Produces
-
-- \`{{artifacts_path}}/design-decisions.md\` — FORGE tier, approach, key decisions, constraints, risks
-
-## Agents
-
-- \`Researcher-Alpha\` — Deep analysis of primary approach
-- \`Researcher-Beta\` — Trade-offs and edge cases
-- \`Researcher-Gamma\` — Cross-domain patterns
-- \`Researcher-Delta\` — Feasibility and performance
-
-## Foundation Integration
-
-Load these skills BEFORE executing this step:
-
-| Skill | Purpose | When |
-|-------|---------|------|
-| \`aikit\` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
-| \`present\` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
-| \`multi-agents-development\` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
-| \`brainstorming\` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
-| \`c4-architecture\` | C4 model diagrams showing system structure changes | When visualizing proposed architecture |
-| \`adr-skill\` | Architecture Decision Records for non-trivial decisions | Critical tier — document architecture decisions |
-
-### Presentation Rules
-- Use \`present\` for **any output** that benefits from rich rendering — not limited to dashboards
-- Assessments, reports, comparisons, reviews, status boards → \`present({ format: "html" })\`
-- Tables, charts, progress tracking, code review findings → always present
-- Artifact content and summaries → present with structured layout
-- Only use plain text for brief confirmations and simple questions
-
-## Completion Criteria
-
-- [ ] \`{{artifacts_path}}/design-decisions.md\` written to disk (NOT just presented in chat)
-- [ ] FORGE tier determined and documented
-- [ ] Brainstorming session completed (for Standard+ tier)
-- [ ] Key design decisions documented with rationale
-- [ ] User approval received (🛑 MANDATORY STOP)
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using \`remember()\`:
-
-- **Design decisions**: Chosen approach and alternatives considered with trade-offs
-- **Architecture patterns**: New patterns introduced or existing patterns that must be followed
-- **Constraints discovered**: Technical limitations, compatibility requirements, or performance boundaries
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
-` },
-    { file: "steps/execute/README.md", content: `---
+- [ ] No placeholder/empty docs created — all content tool-generated or hand-written with purpose`}],"aikit-advanced":[{file:`README.md`,content:"# aikit:advanced — Full Development Flow\n\nFull development flow for **new features, API design, and architecture changes**.\n\n## Steps\n\n| # | Step | Skill | Produces | Requires | Agents |\n|---|------|-------|----------|----------|--------|\n| 1 | **Design Gate** | `steps/design/README.md` | `design-decisions.md` | — | Researcher-Alpha/Beta/Gamma/Delta |\n| 2 | **Specification** | `steps/spec/README.md` | `spec.md` | `design-decisions.md` | Researcher-Alpha |\n| 3 | **Planning** | `steps/plan/README.md` | `plan.md` | `spec.md` | Planner, Explorer |\n| 4 | **Task Breakdown** | `steps/task/README.md` | `tasks.md` | `plan.md` | Planner, Architect-Reviewer-Alpha |\n| 5 | **Execution** | `steps/execute/README.md` | `progress.md` | `tasks.md` | Orchestrator, Implementer, Frontend, Refactor |\n| 6 | **Verification** | `steps/verify/README.md` | `verify-report.md` | `progress.md` | Code-Reviewer-Alpha/Beta, Architect-Reviewer-Alpha/Beta, Security |\n\n## How It Works\n\nEach step has a **README.md** file that contains the detailed instructions for the agent(s) executing that step. The Orchestrator reads the README.md via `flow_read_instruction` and delegates work accordingly.\n\n### Step 1: Design Gate\n- Full brainstorming session for new features and architectural changes\n- FORGE classification (`forge_classify`) + grounding (`forge_ground`) for complex tasks\n- Parallel 4-researcher decision protocol for non-trivial technical decisions\n- ADR generation for critical-tier tasks\n- **Mandatory user stop** before proceeding — design decisions must be approved\n- Read `steps/design/README.md` for the full protocol\n\n### Step 2: Specification\n- Elicit requirements from the user, clarify scope\n- Define acceptance criteria and constraints\n- Build on design decisions from the previous step\n\n### Step 3: Planning\n- Deep codebase analysis using `search`, `scope_map`, `trace`, `analyze_*`\n- Design architecture based on spec and design decisions\n- Create comprehensive implementation plan with file-level changes\n\n### Step 4: Task Breakdown\n- Break the plan into ordered, atomic implementation tasks\n- Define dependencies between tasks\n- Identify parallel batches for multi-agent execution\n- Architecture review of the task structure\n\n### Step 5: Execution\n- Orchestrator dispatches agents in parallel batches per the task breakdown\n- Each agent gets a scoped task (1-3 files) with clear acceptance criteria\n- TDD: write tests first, then implement\n- Per-batch review cycle: Code Review (dual) → Arch Review → Security → Evidence Gate\n\n### Step 6: Verification\n- Dual code review (Code-Reviewer-Alpha + Beta)\n- Architecture review (Architect-Reviewer-Alpha + Beta)\n- Security review\n- Run `check({})` + `test_run({})` + `blast_radius({})`\n- `evidence_map({ action: \"gate\" })` for final quality gate\n\n## Using Skills Inside Steps\n\nWhen the Orchestrator activates a step:\n\n1. **Read the instruction first** — `flow_read_instruction` returns the README.md for the current step\n2. **Follow step instructions** — the README.md is the primary guide for what to do\n3. **Delegate to listed agents** — each step lists which agents are appropriate\n4. **Produce the required artifact** — the step's `produces` field specifies what file to create in the artifacts directory\n5. **Check dependencies** — the step's `requires` field lists artifacts from previous steps that must exist\n6. **Report status** — agents report `DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED` to the Orchestrator\n\n## Artifacts\n\nAll artifacts are stored in the run directory under `.flows/{topic}/`. The template variable `{{artifacts_path}}` resolves to the actual path at runtime.\n"},{file:`steps/design/README.md`,content:`# Design Gate — Advanced Flow
+
+Full design gate for new features, API design, and architecture changes. Runs brainstorming, decision protocol, and FORGE classification before specification begins.
+
+## When This Step Runs
+
+This is the **first step** of the \`aikit:advanced\` flow. It runs before specification.
+
+## Instructions
+
+### 1. Task Classification
+
+Classify the task:
+
+| Category | Indicators | Action |
+|----------|-----------|--------|
+| **Bug fix** | Error, regression, "fix" — wrong flow, should use \`aikit:basic\` | → Note mismatch, still run Quick Design |
+| **New feature** | New behavior, new API, new component | → Run **Full Design** below |
+| **Architecture change** | Restructure, migration, new pattern, cross-cutting | → Run **Full Design** with architecture focus |
+
+### 2. FORGE Classification
+
+Run \`forge_classify({ task: "<task description>", files: [<relevant files>] })\` to determine the complexity tier.
+
+| Tier | Meaning | Design Depth |
+|------|---------|-------------|
+| **Floor** | Low risk, well-understood | Quick brainstorm, 1-2 decisions |
+| **Standard** | Moderate complexity | Full brainstorm, parallel research, decision protocol |
+| **Critical** | High risk, contract/security implications | Deep brainstorm, 4-researcher parallel review, ADR required |
+
+### 3. Brainstorming Session
+
+Load the \`brainstorming\` skill and conduct a structured brainstorming session:
+
+1. **Intent Discovery** — What is the user trying to achieve? What problem does this solve?
+2. **Constraint Mapping** — Technical constraints, time constraints, compatibility requirements
+3. **Approach Exploration** — Generate 2-4 possible approaches
+4. **Trade-off Analysis** — Compare approaches on: complexity, maintainability, performance, risk
+
+For **Critical** tier tasks, also explore:
+- Security implications
+- Backward compatibility
+- Migration path
+- Rollback strategy
+
+### 4. Decision Protocol (Standard & Critical tiers)
+
+When technical decisions need resolution:
+
+1. **Identify decisions** — List each decision point with 2+ viable options
+2. **Parallel research** — Delegate to Researcher agents (2 for Standard, 4 for Critical):
+   - Researcher-Alpha: Deep analysis of primary approach
+   - Researcher-Beta: Trade-offs and edge cases of alternatives
+   - Researcher-Gamma: Cross-domain patterns and precedents
+   - Researcher-Delta: Feasibility and performance implications
+3. **Synthesize** — Combine researcher findings into a recommendation per decision
+4. **ADR** (Critical tier) — Load \`adr-skill\` and create an Architecture Decision Record
+
+### 5. FORGE Ground (Standard & Critical tiers)
+
+Run \`forge_ground({ task, root_path: "." })\` to:
+- Scope the affected files and modules
+- Identify unknowns and risks
+- Load existing constraints and conventions
+
+**Auto-upgrade check**: If \`forge_ground\` reveals contract-type unknowns or security concerns not caught by initial \`forge_classify\`, recommend tier upgrade.
+
+### 6. Write \`{{artifacts_path}}/design-decisions.md\` to disk
+
+**You MUST create this file on disk** using \`create_file\` or equivalent — do not just present content in chat.
+
+\`\`\`markdown
+## Design Decisions
+
+### FORGE Assessment
+- **Tier**: {Floor | Standard | Critical}
+- **Rationale**: {why this tier}
+- **Auto-upgrade**: {yes/no — if yes, explain}
+
+### Task Summary
+- **Goal**: {what we're building}
+- **Problem**: {what problem this solves}
+- **Users affected**: {who is impacted}
+
+### Approach
+- **Chosen approach**: {description}
+- **Alternatives considered**: {list with reasons for rejection}
+
+### Key Decisions
+| # | Decision | Choice | Rationale |
+|---|----------|--------|-----------|
+| 1 | {decision} | {choice} | {why} |
+
+### Constraints
+- {constraint 1}
+- {constraint 2}
+
+### Risks
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|------------|
+| {risk} | {L/M/H} | {L/M/H} | {mitigation} |
+
+### Open Questions
+- {question 1}
+- {question 2}
+\`\`\`
+
+### 7. Present to User
+
+Use \`present({ format: "html" })\` (or \`format: "browser"\` in CLI mode) to show:
+- Design decisions summary
+- FORGE tier and rationale
+- Key trade-offs
+- Open questions requiring user input
+
+**🛑 MANDATORY STOP** — Wait for user approval of design decisions before proceeding.
+
+### 8. Report to Orchestrator
+
+After user approves:
+- \`DONE\` — design decisions approved, ready for specification
+- \`DONE_WITH_CONCERNS\` — approved with caveats (list them)
+- \`NEEDS_CONTEXT\` — user raised questions that need more research
+
+**Do NOT call \`flow_step\`** — let the Orchestrator advance the flow.
+
+## Outputs
+
+Write \`{{artifacts_path}}/design-decisions.md\` to disk. **You MUST create this file** using \`create_file\` or equivalent — do not just present content in chat. This file is a prerequisite for the next step.
+
+## Produces
+
+- \`{{artifacts_path}}/design-decisions.md\` — FORGE tier, approach, key decisions, constraints, risks
+
+## Agents
+
+- \`Researcher-Alpha\` — Deep analysis of primary approach
+- \`Researcher-Beta\` — Trade-offs and edge cases
+- \`Researcher-Gamma\` — Cross-domain patterns
+- \`Researcher-Delta\` — Feasibility and performance
+
+## Foundation Integration
+
+Load these skills BEFORE executing this step:
+
+| Skill | Purpose | When |
+|-------|---------|------|
+| \`aikit\` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
+| \`present\` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
+| \`multi-agents-development\` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
+| \`brainstorming\` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
+| \`c4-architecture\` | C4 model diagrams showing system structure changes | When visualizing proposed architecture |
+| \`adr-skill\` | Architecture Decision Records for non-trivial decisions | Critical tier — document architecture decisions |
+
+### Presentation Rules
+- Use \`present\` for **any output** that benefits from rich rendering — not limited to dashboards
+- Assessments, reports, comparisons, reviews, status boards → \`present({ format: "html" })\`
+- Tables, charts, progress tracking, code review findings → always present
+- Artifact content and summaries → present with structured layout
+- Only use plain text for brief confirmations and simple questions
+
+## Completion Criteria
+
+- [ ] \`{{artifacts_path}}/design-decisions.md\` written to disk (NOT just presented in chat)
+- [ ] FORGE tier determined and documented
+- [ ] Brainstorming session completed (for Standard+ tier)
+- [ ] Key design decisions documented with rationale
+- [ ] User approval received (🛑 MANDATORY STOP)
+
+## Knowledge Capture
+
+Before completing this step, persist important findings using \`remember()\`:
+
+- **Design decisions**: Chosen approach and alternatives considered with trade-offs
+- **Architecture patterns**: New patterns introduced or existing patterns that must be followed
+- **Constraints discovered**: Technical limitations, compatibility requirements, or performance boundaries
+
+**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
+`},{file:`steps/execute/README.md`,content:`---
 name: execute
 description: Implement all tasks from the task breakdown, dispatching agents in parallel where possible.
 ---
@@ -518,8 +440,7 @@ Before completing this step, persist important findings using \`remember()\`:
 - **Gotchas encountered**: Edge cases, workarounds, or non-obvious behaviors discovered during execution
 
 **Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
-` },
-    { file: "steps/plan/README.md", content: `---
+`},{file:`steps/plan/README.md`,content:`---
 name: plan
 description: Analyze the codebase, design the architecture, and create a detailed implementation plan.
 ---
@@ -641,8 +562,7 @@ Before completing this step, persist important findings using \`remember()\`:
 - **Resource decisions**: File ownership, module boundaries, and integration points
 
 **Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
-` },
-    { file: "steps/spec/README.md", content: `---
+`},{file:`steps/spec/README.md`,content:`---
 name: spec
 description: Elicit requirements, clarify scope, and define acceptance criteria through structured dialogue.
 ---
@@ -763,8 +683,7 @@ Before completing this step, persist important findings using \`remember()\`:
 - **Acceptance criteria**: Key testable conditions that define "done"
 
 **Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
-` },
-    { file: "steps/task/README.md", content: `---
+`},{file:`steps/task/README.md`,content:`---
 name: task
 description: Break the implementation plan into ordered, atomic tasks with dependencies and agent assignments.
 ---
@@ -883,8 +802,7 @@ Before completing this step, persist important findings using \`remember()\`:
 - **Coordination points**: Where tasks interact and handoff requirements
 
 **Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
-` },
-    { file: "steps/verify/README.md", content: `---
+`},{file:`steps/verify/README.md`,content:`---
 name: verify
 description: Dual code review, architecture review, security review, and comprehensive test validation.
 ---
@@ -1029,62 +947,7 @@ Before completing this step, persist important findings using \`remember()\`:
 - **Session checkpoint**: Summarize what was accomplished, decisions made, and any remaining work
 
 **Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
-` },
-  ],
-  "aikit-basic": [
-    { file: "README.md", content: `# aikit:basic — Quick Development Flow
-
-Quick development flow for **bug fixes, small features, and refactoring**.
-
-## Steps
-
-| # | Step | Skill | Produces | Requires | Agents |
-|---|------|-------|----------|----------|--------|
-| 1 | **Design Gate** | \`steps/design/README.md\` | \`design-decisions.md\` | — | Researcher-Alpha/Beta/Gamma/Delta |
-| 2 | **Assessment** | \`steps/assess/README.md\` | \`assessment.md\` | \`design-decisions.md\` | Explorer, Researcher-Alpha |
-| 3 | **Implementation** | \`steps/implement/README.md\` | \`progress.md\` | \`assessment.md\` | Implementer, Frontend |
-| 4 | **Verification** | \`steps/verify/README.md\` | \`verify-report.md\` | \`progress.md\` | Code-Reviewer-Alpha, Security |
-
-## How It Works
-
-Each step has a **README.md** file that contains the detailed instructions for the agent(s) executing that step. The Orchestrator reads the README.md via \`flow_read_instruction\` and delegates work accordingly.
-
-### Step 1: Design Gate
-- **Auto-skips** for bug fixes and refactors (produces a minimal \`design-decisions.md\` noting it was skipped)
-- For small features: runs quick brainstorming, FORGE classification, and optional decision protocol
-- Read \`steps/design/README.md\` for the full decision tree
-
-### Step 2: Assessment
-- Explore the codebase to understand scope and impact
-- Use \`search\`, \`scope_map\`, \`file_summary\`, \`compact\` to gather context
-- Identify the approach and produce \`assessment.md\`
-
-### Step 3: Implementation
-- Write code following the assessment plan
-- The Orchestrator dispatches Implementer/Frontend agents with specific file scopes
-- Follow TDD practices where applicable
-
-### Step 4: Verification
-- Code review, test execution, security check
-- Run \`check({})\` + \`test_run({})\` + \`blast_radius({})\`
-- Produce \`verify-report.md\` with findings
-
-## Using Skills Inside Steps
-
-When the Orchestrator activates a step:
-
-1. **Read the instruction first** — \`flow_read_instruction\` returns the README.md for the current step
-2. **Follow step instructions** — the README.md is the primary guide for what to do
-3. **Delegate to listed agents** — each step lists which agents are appropriate
-4. **Produce the required artifact** — the step's \`produces\` field specifies what file to create in the artifacts directory
-5. **Check dependencies** — the step's \`requires\` field lists artifacts from previous steps that must exist
-6. **Report status** — agents report \`DONE\` | \`DONE_WITH_CONCERNS\` | \`NEEDS_CONTEXT\` | \`BLOCKED\` to the Orchestrator
-
-## Artifacts
-
-All artifacts are stored in the run directory under \`.flows/{topic}/\`. The template variable \`{{artifacts_path}}\` resolves to the actual path at runtime.
-` },
-    { file: "steps/assess/README.md", content: `---
+`}],"aikit-basic":[{file:`README.md`,content:"# aikit:basic — Quick Development Flow\n\nQuick development flow for **bug fixes, small features, and refactoring**.\n\n## Steps\n\n| # | Step | Skill | Produces | Requires | Agents |\n|---|------|-------|----------|----------|--------|\n| 1 | **Design Gate** | `steps/design/README.md` | `design-decisions.md` | — | Researcher-Alpha/Beta/Gamma/Delta |\n| 2 | **Assessment** | `steps/assess/README.md` | `assessment.md` | `design-decisions.md` | Explorer, Researcher-Alpha |\n| 3 | **Implementation** | `steps/implement/README.md` | `progress.md` | `assessment.md` | Implementer, Frontend |\n| 4 | **Verification** | `steps/verify/README.md` | `verify-report.md` | `progress.md` | Code-Reviewer-Alpha, Security |\n\n## How It Works\n\nEach step has a **README.md** file that contains the detailed instructions for the agent(s) executing that step. The Orchestrator reads the README.md via `flow_read_instruction` and delegates work accordingly.\n\n### Step 1: Design Gate\n- **Auto-skips** for bug fixes and refactors (produces a minimal `design-decisions.md` noting it was skipped)\n- For small features: runs quick brainstorming, FORGE classification, and optional decision protocol\n- Read `steps/design/README.md` for the full decision tree\n\n### Step 2: Assessment\n- Explore the codebase to understand scope and impact\n- Use `search`, `scope_map`, `file_summary`, `compact` to gather context\n- Identify the approach and produce `assessment.md`\n\n### Step 3: Implementation\n- Write code following the assessment plan\n- The Orchestrator dispatches Implementer/Frontend agents with specific file scopes\n- Follow TDD practices where applicable\n\n### Step 4: Verification\n- Code review, test execution, security check\n- Run `check({})` + `test_run({})` + `blast_radius({})`\n- Produce `verify-report.md` with findings\n\n## Using Skills Inside Steps\n\nWhen the Orchestrator activates a step:\n\n1. **Read the instruction first** — `flow_read_instruction` returns the README.md for the current step\n2. **Follow step instructions** — the README.md is the primary guide for what to do\n3. **Delegate to listed agents** — each step lists which agents are appropriate\n4. **Produce the required artifact** — the step's `produces` field specifies what file to create in the artifacts directory\n5. **Check dependencies** — the step's `requires` field lists artifacts from previous steps that must exist\n6. **Report status** — agents report `DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED` to the Orchestrator\n\n## Artifacts\n\nAll artifacts are stored in the run directory under `.flows/{topic}/`. The template variable `{{artifacts_path}}` resolves to the actual path at runtime.\n"},{file:`steps/assess/README.md`,content:`---
 name: assess
 description: Understand scope, analyze the codebase, and identify the implementation approach.
 ---
@@ -1193,125 +1056,123 @@ Before completing this step, persist important findings using \`remember()\`:
 - **Scope decisions**: What's in scope, what's explicitly excluded, and why
 
 **Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
-` },
-    { file: "steps/design/README.md", content: `# Design Gate — Basic Flow
-
-Lightweight design gate for bug fixes, small features, and refactoring. Evaluates the task type and determines whether design work is needed before proceeding.
-
-## When This Step Runs
-
-This is the **first step** of the \`aikit:basic\` flow. It runs before assessment.
-
-## Instructions
-
-### 1. Task Classification
-
-Classify the task into one of these categories:
-
-| Category | Indicators | Action |
-|----------|-----------|--------|
-| **Bug fix** | Error reports, stack traces, regression, "fix", "broken" | → **Auto-skip** to next step |
-| **Refactor** | Code cleanup, rename, restructure, no behavior change | → **Auto-skip** to next step |
-| **Small feature** | New behavior, new endpoint, new component, UI change | → Run **Quick Design** below |
-
-**If the task is a bug fix or refactor**, write \`{{artifacts_path}}/design-decisions.md\` to disk:
-\`\`\`markdown
-## Design Decisions
-- **Task type**: Bug fix / Refactor
-- **Design gate**: Auto-skipped — no design work needed
-- **Proceed to**: Assessment
-\`\`\`
-**You MUST create this file on disk** at the exact \`{{artifacts_path}}/design-decisions.md\` path — do not just present the content in chat.
-Then report \`DONE\` to the Orchestrator so the flow advances.
-
-### 2. Quick Design (Small Features Only)
-
-For small features that need minimal design:
-
-1. **FORGE Classify** — Run \`forge_classify({ task: "<task description>", files: [<relevant files>] })\` to determine complexity tier
-2. **Brainstorming** (if tier ≥ Standard) — Load the \`brainstorming\` skill and run a focused brainstorming session:
-   - What is the user trying to achieve?
-   - What are the constraints?
-   - What is the simplest approach?
-3. **Decision Protocol** (if technical decisions exist) — Delegate to 2-4 Researcher agents in parallel:
-   - Each researcher evaluates a different approach
-   - Synthesize findings into a recommendation
-4. **Write \`{{artifacts_path}}/design-decisions.md\`** to disk:
-
-\`\`\`markdown
-## Design Decisions
-
-### FORGE Assessment
-- **Tier**: {Floor | Standard | Critical}
-- **Rationale**: {why this tier}
-
-### Task Summary
-- **Goal**: {what we're building}
-- **Approach**: {chosen approach}
-- **Key decisions**: {list}
-
-### Constraints
-- {constraint 1}
-- {constraint 2}
-\`\`\`
-
-### 3. Report to Orchestrator
-
-When complete, report status:
-- \`DONE\` — design decisions captured, ready for assessment
-- \`DONE_WITH_CONCERNS\` — design captured but open questions remain (list them)
-
-**Do NOT call \`flow_step\`** — let the Orchestrator advance the flow.
-
-## Outputs
-
-Write \`{{artifacts_path}}/design-decisions.md\` to disk. **You MUST create this file** using \`create_file\` or equivalent — do not just present content in chat. This file is a prerequisite for the next step.
-
-## Produces
-
-- \`{{artifacts_path}}/design-decisions.md\` — Task classification, FORGE tier, key design decisions
-
-## Agents
-
-- \`Researcher-Alpha\`, \`Researcher-Beta\`, \`Researcher-Gamma\`, \`Researcher-Delta\` — for parallel research during decision protocol
-
-## Foundation Integration
-
-Load these skills BEFORE executing this step:
-
-| Skill | Purpose | When |
-|-------|---------|------|
-| \`aikit\` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
-| \`present\` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
-| \`multi-agents-development\` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
-| \`brainstorming\` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
-| \`c4-architecture\` | C4 model architecture diagrams — system context, container, component, deployment views | When visualizing system structure during design |
-| \`adr-skill\` | Architecture Decision Records — create, review, maintain ADRs | When making non-trivial design or technology decisions |
-
-### Presentation Rules
-- Use \`present\` for **any output** that benefits from rich rendering — not limited to dashboards
-- Assessments, reports, comparisons, reviews, status boards → \`present({ format: "html" })\`
-- Tables, charts, progress tracking, code review findings → always present
-- Artifact content and summaries → present with structured layout
-- Only use plain text for brief confirmations and simple questions
-
-## Completion Criteria
-
-- [ ] \`{{artifacts_path}}/design-decisions.md\` written to disk (NOT just presented in chat)
-- [ ] FORGE tier determined (for small features)
-- [ ] Key design decisions documented
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using \`remember()\`:
-
-- **Design decisions**: Chosen approach and alternatives considered with trade-offs
-- **Architecture patterns**: New patterns introduced or existing patterns that must be followed
-- **Constraints discovered**: Technical limitations, compatibility requirements, or performance boundaries
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
-` },
-    { file: "steps/implement/README.md", content: `---
+`},{file:`steps/design/README.md`,content:`# Design Gate — Basic Flow
+
+Lightweight design gate for bug fixes, small features, and refactoring. Evaluates the task type and determines whether design work is needed before proceeding.
+
+## When This Step Runs
+
+This is the **first step** of the \`aikit:basic\` flow. It runs before assessment.
+
+## Instructions
+
+### 1. Task Classification
+
+Classify the task into one of these categories:
+
+| Category | Indicators | Action |
+|----------|-----------|--------|
+| **Bug fix** | Error reports, stack traces, regression, "fix", "broken" | → **Auto-skip** to next step |
+| **Refactor** | Code cleanup, rename, restructure, no behavior change | → **Auto-skip** to next step |
+| **Small feature** | New behavior, new endpoint, new component, UI change | → Run **Quick Design** below |
+
+**If the task is a bug fix or refactor**, write \`{{artifacts_path}}/design-decisions.md\` to disk:
+\`\`\`markdown
+## Design Decisions
+- **Task type**: Bug fix / Refactor
+- **Design gate**: Auto-skipped — no design work needed
+- **Proceed to**: Assessment
+\`\`\`
+**You MUST create this file on disk** at the exact \`{{artifacts_path}}/design-decisions.md\` path — do not just present the content in chat.
+Then report \`DONE\` to the Orchestrator so the flow advances.
+
+### 2. Quick Design (Small Features Only)
+
+For small features that need minimal design:
+
+1. **FORGE Classify** — Run \`forge_classify({ task: "<task description>", files: [<relevant files>] })\` to determine complexity tier
+2. **Brainstorming** (if tier ≥ Standard) — Load the \`brainstorming\` skill and run a focused brainstorming session:
+   - What is the user trying to achieve?
+   - What are the constraints?
+   - What is the simplest approach?
+3. **Decision Protocol** (if technical decisions exist) — Delegate to 2-4 Researcher agents in parallel:
+   - Each researcher evaluates a different approach
+   - Synthesize findings into a recommendation
+4. **Write \`{{artifacts_path}}/design-decisions.md\`** to disk:
+
+\`\`\`markdown
+## Design Decisions
+
+### FORGE Assessment
+- **Tier**: {Floor | Standard | Critical}
+- **Rationale**: {why this tier}
+
+### Task Summary
+- **Goal**: {what we're building}
+- **Approach**: {chosen approach}
+- **Key decisions**: {list}
+
+### Constraints
+- {constraint 1}
+- {constraint 2}
+\`\`\`
+
+### 3. Report to Orchestrator
+
+When complete, report status:
+- \`DONE\` — design decisions captured, ready for assessment
+- \`DONE_WITH_CONCERNS\` — design captured but open questions remain (list them)
+
+**Do NOT call \`flow_step\`** — let the Orchestrator advance the flow.
+
+## Outputs
+
+Write \`{{artifacts_path}}/design-decisions.md\` to disk. **You MUST create this file** using \`create_file\` or equivalent — do not just present content in chat. This file is a prerequisite for the next step.
+
+## Produces
+
+- \`{{artifacts_path}}/design-decisions.md\` — Task classification, FORGE tier, key design decisions
+
+## Agents
+
+- \`Researcher-Alpha\`, \`Researcher-Beta\`, \`Researcher-Gamma\`, \`Researcher-Delta\` — for parallel research during decision protocol
+
+## Foundation Integration
+
+Load these skills BEFORE executing this step:
+
+| Skill | Purpose | When |
+|-------|---------|------|
+| \`aikit\` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
+| \`present\` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
+| \`multi-agents-development\` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
+| \`brainstorming\` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
+| \`c4-architecture\` | C4 model architecture diagrams — system context, container, component, deployment views | When visualizing system structure during design |
+| \`adr-skill\` | Architecture Decision Records — create, review, maintain ADRs | When making non-trivial design or technology decisions |
+
+### Presentation Rules
+- Use \`present\` for **any output** that benefits from rich rendering — not limited to dashboards
+- Assessments, reports, comparisons, reviews, status boards → \`present({ format: "html" })\`
+- Tables, charts, progress tracking, code review findings → always present
+- Artifact content and summaries → present with structured layout
+- Only use plain text for brief confirmations and simple questions
+
+## Completion Criteria
+
+- [ ] \`{{artifacts_path}}/design-decisions.md\` written to disk (NOT just presented in chat)
+- [ ] FORGE tier determined (for small features)
+- [ ] Key design decisions documented
+
+## Knowledge Capture
+
+Before completing this step, persist important findings using \`remember()\`:
+
+- **Design decisions**: Chosen approach and alternatives considered with trade-offs
+- **Architecture patterns**: New patterns introduced or existing patterns that must be followed
+- **Constraints discovered**: Technical limitations, compatibility requirements, or performance boundaries
+
+**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
+`},{file:`steps/implement/README.md`,content:`---
 name: implement
 description: Write code following the assessment plan, using TDD practices where applicable.
 ---
@@ -1442,8 +1303,7 @@ Before completing this step, persist important findings using \`remember()\`:
 - **Gotchas encountered**: Edge cases, workarounds, or non-obvious behaviors discovered during implementation
 
 **Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
-` },
-    { file: "steps/verify/README.md", content: `---
+`},{file:`steps/verify/README.md`,content:`---
 name: verify
 description: Review code changes, run tests, validate correctness and quality.
 ---
@@ -1566,6 +1426,4 @@ Before completing this step, persist important findings using \`remember()\`:
 - **Session checkpoint**: Summarize what was accomplished, decisions made, and any remaining work
 
 **Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call \`remember()\` now.
-` },
-  ],
-};
+`}]};export{e as FLOWS};