From c1fdb4544225cef64fe506bca49a4bedb0862a24 Mon Sep 17 00:00:00 2001
From: "jiashuai.shi@qq.com" <shijiashuai@bgi.com>
Date: Tue, 26 May 2026 02:31:58 +0800
Subject: [PATCH] refactor: remove AI scaffolding and doc duplication

Strip the repository back to its core TypeScript/WebGPU tooling by removing .claude, openspec, and agent-specific guidance. Consolidate changelog handling to the root CHANGELOG.md and simplify contributor/docs workflows accordingly.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .claude/commands/opsx/apply.md                |  152 --
 .claude/commands/opsx/archive.md              |  157 --
 .claude/commands/opsx/explore.md              |  173 ---
 .claude/commands/opsx/propose.md              |  106 --
 .claude/skills/bmad-agent-architect/SKILL.md  |   54 -
 .../bmad-skill-manifest.yaml                  |   11 -
 .claude/skills/bmad-agent-dev/SKILL.md        |   69 -
 .../bmad-agent-dev/bmad-skill-manifest.yaml   |   11 -
 .claude/skills/bmad-agent-pm/SKILL.md         |   59 -
 .../bmad-agent-pm/bmad-skill-manifest.yaml    |   11 -
 .../skills/bmad-agent-tech-writer/SKILL.md    |   57 -
 .../bmad-skill-manifest.yaml                  |   11 -
 .../bmad-agent-tech-writer/explain-concept.md |   20 -
 .../bmad-agent-tech-writer/mermaid-gen.md     |   20 -
 .../bmad-agent-tech-writer/validate-doc.md    |   19 -
 .../bmad-agent-tech-writer/write-document.md  |   20 -
 .claude/skills/bmad-brainstorming/SKILL.md    |    6 -
 .../bmad-brainstorming/brain-methods.csv      |   62 -
 .../steps/step-01-session-setup.md            |  214 ---
 .../steps/step-01b-continue.md                |  124 --
 .../steps/step-02a-user-selected.md           |  229 ---
 .../steps/step-02b-ai-recommended.md          |  239 ---
 .../steps/step-02c-random-selection.md        |  211 ---
 .../steps/step-02d-progressive-flow.md        |  266 ----
 .../steps/step-03-technique-execution.md      |  401 -----
 .../steps/step-04-idea-organization.md        |  305 ----
 .claude/skills/bmad-brainstorming/template.md |   15 -
 .claude/skills/bmad-brainstorming/workflow.md |   53 -
 .claude/skills/bmad-code-review/SKILL.md      |    6 -
 .../steps/step-01-gather-context.md           |   85 --
 .../bmad-code-review/steps/step-02-review.md  |   34 -
 .../bmad-code-review/steps/step-03-triage.md  |   49 -
 .../bmad-code-review/steps/step-04-present.md |  129 --
 .claude/skills/bmad-code-review/workflow.md   |   55 -
 .claude/skills/bmad-correct-course/SKILL.md   |    6 -
 .../skills/bmad-correct-course/checklist.md   |  288 ----
 .../skills/bmad-correct-course/workflow.md    |  267 ----
 .../skills/bmad-create-architecture/SKILL.md  |    6 -
 .../architecture-decision-template.md         |   12 -
 .../data/domain-complexity.csv                |   13 -
 .../data/project-types.csv                    |    7 -
 .../steps/step-01-init.md                     |  153 --
 .../steps/step-01b-continue.md                |  173 ---
 .../steps/step-02-context.md                  |  224 ---
 .../steps/step-03-starter.md                  |  329 ----
 .../steps/step-04-decisions.md                |  318 ----
 .../steps/step-05-patterns.md                 |  359 -----
 .../steps/step-06-structure.md                |  379 -----
 .../steps/step-07-validation.md               |  359 -----
 .../steps/step-08-complete.md                 |   76 -
 .../bmad-create-architecture/workflow.md      |   32 -
 .../bmad-create-epics-and-stories/SKILL.md    |    6 -
 .../steps/step-01-validate-prerequisites.md   |  255 ----
 .../steps/step-02-design-epics.md             |  212 ---
 .../steps/step-03-create-stories.md           |  255 ----
 .../steps/step-04-final-validation.md         |  131 --
 .../templates/epics-template.md               |   61 -
 .../bmad-create-epics-and-stories/workflow.md |   51 -
 .claude/skills/bmad-create-prd/SKILL.md       |    6 -
 .../data/domain-complexity.csv                |   15 -
 .../bmad-create-prd/data/prd-purpose.md       |  197 ---
 .../bmad-create-prd/data/project-types.csv    |   11 -
 .../bmad-create-prd/steps-c/step-01-init.md   |  178 ---
 .../steps-c/step-01b-continue.md              |  161 --
 .../steps-c/step-02-discovery.md              |  208 ---
 .../steps-c/step-02b-vision.md                |  142 --
 .../steps-c/step-02c-executive-summary.md     |  158 --
 .../steps-c/step-03-success.md                |  214 ---
 .../steps-c/step-04-journeys.md               |  201 ---
 .../bmad-create-prd/steps-c/step-05-domain.md |  194 ---
 .../steps-c/step-06-innovation.md             |  211 ---
 .../steps-c/step-07-project-type.md           |  222 ---
 .../steps-c/step-08-scoping.md                |  216 ---
 .../steps-c/step-09-functional.md             |  219 ---
 .../steps-c/step-10-nonfunctional.md          |  230 ---
 .../bmad-create-prd/steps-c/step-11-polish.md |  221 ---
 .../steps-c/step-12-complete.md               |  115 --
 .../bmad-create-prd/templates/prd-template.md |   10 -
 .claude/skills/bmad-create-prd/workflow.md    |   61 -
 .claude/skills/bmad-create-story/SKILL.md     |    6 -
 .claude/skills/bmad-create-story/checklist.md |  357 -----
 .../bmad-create-story/discover-inputs.md      |   88 --
 .claude/skills/bmad-create-story/template.md  |   49 -
 .claude/skills/bmad-create-story/workflow.md  |  380 -----
 .claude/skills/bmad-dev-story/SKILL.md        |    6 -
 .claude/skills/bmad-dev-story/checklist.md    |   80 -
 .claude/skills/bmad-dev-story/workflow.md     |  450 ------
 .claude/skills/bmad-quick-dev/SKILL.md        |    6 -
 .../bmad-quick-dev/compile-epic-context.md    |   62 -
 .../skills/bmad-quick-dev/spec-template.md    |   88 --
 .../step-01-clarify-and-route.md              |   91 --
 .claude/skills/bmad-quick-dev/step-02-plan.md |   47 -
 .../bmad-quick-dev/step-03-implement.md       |   39 -
 .../skills/bmad-quick-dev/step-04-review.md   |   49 -
 .../skills/bmad-quick-dev/step-05-present.md  |   63 -
 .claude/skills/bmad-quick-dev/step-oneshot.md |   61 -
 .claude/skills/bmad-quick-dev/workflow.md     |   75 -
 .claude/skills/openspec-apply-change/SKILL.md |  156 --
 .../skills/openspec-archive-change/SKILL.md   |  114 --
 .claude/skills/openspec-explore/SKILL.md      |  288 ----
 .claude/skills/openspec-propose/SKILL.md      |  110 --
 .github/PULL_REQUEST_TEMPLATE.md              |    1 -
 .github/copilot-instructions.md               |   77 +-
 .github/workflows/pages.yml                   |    4 +-
 .gitignore                                    |    7 -
 AGENTS.md                                     |   96 --
 CLAUDE.md                                     |  100 --
 CONTRIBUTING.md                               |  238 +--
 README.md                                     |   30 +-
 README.zh-CN.md                               |   30 +-
 docs/.vitepress/config/index.ts               |    7 -
 docs/.vitepress/config/nav/en.ts              |    1 -
 docs/.vitepress/config/nav/zh.ts              |    1 -
 docs/en/api/index.md                          |    2 +-
 docs/en/changelog.md                          |  183 ---
 docs/en/contributing.md                       |    6 +-
 docs/en/research/future-directions.md         |    2 +-
 docs/package-lock.json                        | 1334 +----------------
 docs/package.json                             |    7 +-
 docs/scripts/sync-changelog.mjs               |  101 --
 docs/zh/README.md                             |    2 +-
 docs/zh/changelog.md                          |  165 --
 docs/zh/contributing.md                       |    6 +-
 .../design.md                                 |  102 --
 .../proposal.md                               |   42 -
 .../specs/api/spec.md                         |   45 -
 .../specs/batchnorm/spec.md                   |   36 -
 .../specs/conv-bn-relu-fusion/spec.md         |   33 -
 .../specs/elementwise-ops/spec.md             |   32 -
 .../specs/testing/spec.md                     |   49 -
 .../tasks.md                                  |   40 -
 .../.openspec.yaml                            |    2 -
 .../design.md                                 |   51 -
 .../proposal.md                               |   29 -
 .../specs/api/spec.md                         |   21 -
 .../specs/architecture/spec.md                |   38 -
 .../specs/product/spec.md                     |   25 -
 .../specs/testing/spec.md                     |   15 -
 .../tasks.md                                  |   14 -
 openspec/config.yaml                          |   42 -
 openspec/specs/api/spec.md                    |  801 ----------
 openspec/specs/architecture/spec.md           |  218 ---
 openspec/specs/kernel-fusion/spec.md          |  156 --
 openspec/specs/memory-layout/spec.md          |  182 ---
 openspec/specs/product/spec.md                |  304 ----
 openspec/specs/testing/spec.md                |  302 ----
 package-lock.json                             |    4 +-
 147 files changed, 134 insertions(+), 18109 deletions(-)
 delete mode 100644 .claude/commands/opsx/apply.md
 delete mode 100644 .claude/commands/opsx/archive.md
 delete mode 100644 .claude/commands/opsx/explore.md
 delete mode 100644 .claude/commands/opsx/propose.md
 delete mode 100644 .claude/skills/bmad-agent-architect/SKILL.md
 delete mode 100644 .claude/skills/bmad-agent-architect/bmad-skill-manifest.yaml
 delete mode 100644 .claude/skills/bmad-agent-dev/SKILL.md
 delete mode 100644 .claude/skills/bmad-agent-dev/bmad-skill-manifest.yaml
 delete mode 100644 .claude/skills/bmad-agent-pm/SKILL.md
 delete mode 100644 .claude/skills/bmad-agent-pm/bmad-skill-manifest.yaml
 delete mode 100644 .claude/skills/bmad-agent-tech-writer/SKILL.md
 delete mode 100644 .claude/skills/bmad-agent-tech-writer/bmad-skill-manifest.yaml
 delete mode 100644 .claude/skills/bmad-agent-tech-writer/explain-concept.md
 delete mode 100644 .claude/skills/bmad-agent-tech-writer/mermaid-gen.md
 delete mode 100644 .claude/skills/bmad-agent-tech-writer/validate-doc.md
 delete mode 100644 .claude/skills/bmad-agent-tech-writer/write-document.md
 delete mode 100644 .claude/skills/bmad-brainstorming/SKILL.md
 delete mode 100644 .claude/skills/bmad-brainstorming/brain-methods.csv
 delete mode 100644 .claude/skills/bmad-brainstorming/steps/step-01-session-setup.md
 delete mode 100644 .claude/skills/bmad-brainstorming/steps/step-01b-continue.md
 delete mode 100644 .claude/skills/bmad-brainstorming/steps/step-02a-user-selected.md
 delete mode 100644 .claude/skills/bmad-brainstorming/steps/step-02b-ai-recommended.md
 delete mode 100644 .claude/skills/bmad-brainstorming/steps/step-02c-random-selection.md
 delete mode 100644 .claude/skills/bmad-brainstorming/steps/step-02d-progressive-flow.md
 delete mode 100644 .claude/skills/bmad-brainstorming/steps/step-03-technique-execution.md
 delete mode 100644 .claude/skills/bmad-brainstorming/steps/step-04-idea-organization.md
 delete mode 100644 .claude/skills/bmad-brainstorming/template.md
 delete mode 100644 .claude/skills/bmad-brainstorming/workflow.md
 delete mode 100644 .claude/skills/bmad-code-review/SKILL.md
 delete mode 100644 .claude/skills/bmad-code-review/steps/step-01-gather-context.md
 delete mode 100644 .claude/skills/bmad-code-review/steps/step-02-review.md
 delete mode 100644 .claude/skills/bmad-code-review/steps/step-03-triage.md
 delete mode 100644 .claude/skills/bmad-code-review/steps/step-04-present.md
 delete mode 100644 .claude/skills/bmad-code-review/workflow.md
 delete mode 100644 .claude/skills/bmad-correct-course/SKILL.md
 delete mode 100644 .claude/skills/bmad-correct-course/checklist.md
 delete mode 100644 .claude/skills/bmad-correct-course/workflow.md
 delete mode 100644 .claude/skills/bmad-create-architecture/SKILL.md
 delete mode 100644 .claude/skills/bmad-create-architecture/architecture-decision-template.md
 delete mode 100644 .claude/skills/bmad-create-architecture/data/domain-complexity.csv
 delete mode 100644 .claude/skills/bmad-create-architecture/data/project-types.csv
 delete mode 100644 .claude/skills/bmad-create-architecture/steps/step-01-init.md
 delete mode 100644 .claude/skills/bmad-create-architecture/steps/step-01b-continue.md
 delete mode 100644 .claude/skills/bmad-create-architecture/steps/step-02-context.md
 delete mode 100644 .claude/skills/bmad-create-architecture/steps/step-03-starter.md
 delete mode 100644 .claude/skills/bmad-create-architecture/steps/step-04-decisions.md
 delete mode 100644 .claude/skills/bmad-create-architecture/steps/step-05-patterns.md
 delete mode 100644 .claude/skills/bmad-create-architecture/steps/step-06-structure.md
 delete mode 100644 .claude/skills/bmad-create-architecture/steps/step-07-validation.md
 delete mode 100644 .claude/skills/bmad-create-architecture/steps/step-08-complete.md
 delete mode 100644 .claude/skills/bmad-create-architecture/workflow.md
 delete mode 100644 .claude/skills/bmad-create-epics-and-stories/SKILL.md
 delete mode 100644 .claude/skills/bmad-create-epics-and-stories/steps/step-01-validate-prerequisites.md
 delete mode 100644 .claude/skills/bmad-create-epics-and-stories/steps/step-02-design-epics.md
 delete mode 100644 .claude/skills/bmad-create-epics-and-stories/steps/step-03-create-stories.md
 delete mode 100644 .claude/skills/bmad-create-epics-and-stories/steps/step-04-final-validation.md
 delete mode 100644 .claude/skills/bmad-create-epics-and-stories/templates/epics-template.md
 delete mode 100644 .claude/skills/bmad-create-epics-and-stories/workflow.md
 delete mode 100644 .claude/skills/bmad-create-prd/SKILL.md
 delete mode 100644 .claude/skills/bmad-create-prd/data/domain-complexity.csv
 delete mode 100644 .claude/skills/bmad-create-prd/data/prd-purpose.md
 delete mode 100644 .claude/skills/bmad-create-prd/data/project-types.csv
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-01-init.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-01b-continue.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-02-discovery.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-02b-vision.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-02c-executive-summary.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-03-success.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-04-journeys.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-05-domain.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-06-innovation.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-07-project-type.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-08-scoping.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-09-functional.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-10-nonfunctional.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-11-polish.md
 delete mode 100644 .claude/skills/bmad-create-prd/steps-c/step-12-complete.md
 delete mode 100644 .claude/skills/bmad-create-prd/templates/prd-template.md
 delete mode 100644 .claude/skills/bmad-create-prd/workflow.md
 delete mode 100644 .claude/skills/bmad-create-story/SKILL.md
 delete mode 100644 .claude/skills/bmad-create-story/checklist.md
 delete mode 100644 .claude/skills/bmad-create-story/discover-inputs.md
 delete mode 100644 .claude/skills/bmad-create-story/template.md
 delete mode 100644 .claude/skills/bmad-create-story/workflow.md
 delete mode 100644 .claude/skills/bmad-dev-story/SKILL.md
 delete mode 100644 .claude/skills/bmad-dev-story/checklist.md
 delete mode 100644 .claude/skills/bmad-dev-story/workflow.md
 delete mode 100644 .claude/skills/bmad-quick-dev/SKILL.md
 delete mode 100644 .claude/skills/bmad-quick-dev/compile-epic-context.md
 delete mode 100644 .claude/skills/bmad-quick-dev/spec-template.md
 delete mode 100644 .claude/skills/bmad-quick-dev/step-01-clarify-and-route.md
 delete mode 100644 .claude/skills/bmad-quick-dev/step-02-plan.md
 delete mode 100644 .claude/skills/bmad-quick-dev/step-03-implement.md
 delete mode 100644 .claude/skills/bmad-quick-dev/step-04-review.md
 delete mode 100644 .claude/skills/bmad-quick-dev/step-05-present.md
 delete mode 100644 .claude/skills/bmad-quick-dev/step-oneshot.md
 delete mode 100644 .claude/skills/bmad-quick-dev/workflow.md
 delete mode 100644 .claude/skills/openspec-apply-change/SKILL.md
 delete mode 100644 .claude/skills/openspec-archive-change/SKILL.md
 delete mode 100644 .claude/skills/openspec-explore/SKILL.md
 delete mode 100644 .claude/skills/openspec-propose/SKILL.md
 delete mode 100644 AGENTS.md
 delete mode 100644 CLAUDE.md
 delete mode 100644 docs/en/changelog.md
 delete mode 100644 docs/scripts/sync-changelog.mjs
 delete mode 100644 docs/zh/changelog.md
 delete mode 100644 openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/design.md
 delete mode 100644 openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/proposal.md
 delete mode 100644 openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/api/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/batchnorm/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/conv-bn-relu-fusion/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/elementwise-ops/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/testing/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/tasks.md
 delete mode 100644 openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/.openspec.yaml
 delete mode 100644 openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/design.md
 delete mode 100644 openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/proposal.md
 delete mode 100644 openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/api/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/architecture/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/product/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/testing/spec.md
 delete mode 100644 openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/tasks.md
 delete mode 100644 openspec/config.yaml
 delete mode 100644 openspec/specs/api/spec.md
 delete mode 100644 openspec/specs/architecture/spec.md
 delete mode 100644 openspec/specs/kernel-fusion/spec.md
 delete mode 100644 openspec/specs/memory-layout/spec.md
 delete mode 100644 openspec/specs/product/spec.md
 delete mode 100644 openspec/specs/testing/spec.md

diff --git a/.claude/commands/opsx/apply.md b/.claude/commands/opsx/apply.md
deleted file mode 100644
index ae14f0f..0000000
--- a/.claude/commands/opsx/apply.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-name: "OPSX: Apply"
-description: Implement tasks from an OpenSpec change (Experimental)
-category: Workflow
-tags: [workflow, artifacts, experimental]
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! You can archive this change with `/opsx:archive`.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/commands/opsx/archive.md b/.claude/commands/opsx/archive.md
deleted file mode 100644
index 5e91608..0000000
--- a/.claude/commands/opsx/archive.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-name: "OPSX: Archive"
-description: Archive a completed change in the experimental workflow
-category: Workflow
-tags: [workflow, archive, experimental]
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Spec sync status (synced / sync skipped / no delta specs)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success (No Delta Specs)**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** No delta specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success With Warnings**
-
-```
-## Archive Complete (with warnings)
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** Sync skipped (user chose to skip)
-
-**Warnings:**
-- Archived with 2 incomplete artifacts
-- Archived with 3 incomplete tasks
-- Delta spec sync was skipped (user chose to skip)
-
-Review the archive if this was not intentional.
-```
-
-**Output On Error (Archive Exists)**
-
-```
-## Archive Failed
-
-**Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
-
-Target archive directory already exists.
-
-**Options:**
-1. Rename the existing archive
-2. Delete the existing archive if it's a duplicate
-3. Wait until a different date to archive
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/commands/opsx/explore.md b/.claude/commands/opsx/explore.md
deleted file mode 100644
index 1757907..0000000
--- a/.claude/commands/opsx/explore.md
+++ /dev/null
@@ -1,173 +0,0 @@
----
-name: "OPSX: Explore"
-description: "Enter explore mode - think through ideas, investigate problems, clarify requirements"
-category: Workflow
-tags: [workflow, explore, experimental, thinking]
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
-**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
-- A vague idea: "real-time collaboration"
-- A specific problem: "the auth system is getting unwieldy"
-- A change name: "add-dark-mode" (to explore in context of that change)
-- A comparison: "postgres vs sqlite for this"
-- Nothing (just enter explore mode)
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-If the user mentioned a specific change name, read its artifacts for context.
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/commands/opsx/propose.md b/.claude/commands/opsx/propose.md
deleted file mode 100644
index 05276f4..0000000
--- a/.claude/commands/opsx/propose.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-name: "OPSX: Propose"
-description: Propose a new change - create it and generate all artifacts in one step
-category: Workflow
-tags: [workflow, artifacts, experimental]
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
-
-**Steps**
-
-1. **If no input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` to start implementing."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.claude/skills/bmad-agent-architect/SKILL.md b/.claude/skills/bmad-agent-architect/SKILL.md
deleted file mode 100644
index 2c68275..0000000
--- a/.claude/skills/bmad-agent-architect/SKILL.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-name: bmad-agent-architect
-description: System architect and technical design leader. Use when the user asks to talk to Winston or requests the architect.
----
-
-# Winston
-
-## Overview
-
-This skill provides a System Architect who guides users through technical design decisions, distributed systems planning, and scalable architecture. Act as Winston — a senior architect who balances vision with pragmatism, helping users make technology choices that ship successfully while scaling when needed.
-
-## Identity
-
-Senior architect with expertise in distributed systems, cloud infrastructure, and API design who specializes in scalable patterns and technology selection.
-
-## Communication Style
-
-Speaks in calm, pragmatic tones, balancing "what could be" with "what should be." Grounds every recommendation in real-world trade-offs and practical constraints.
-
-## Principles
-
-- Channel expert lean architecture wisdom: draw upon deep knowledge of distributed systems, cloud patterns, scalability trade-offs, and what actually ships successfully.
-- User journeys drive technical decisions. Embrace boring technology for stability.
-- Design simple solutions that scale when needed. Developer productivity is architecture. Connect every decision to business value and user impact.
-
-You must fully embody this persona so the user gets the best experience and help they need, therefore its important to remember you must not break character until the users dismisses this persona.
-
-When you are in this persona and the user calls a skill, this persona must carry through and remain active.
-
-## Capabilities
-
-| Code | Description | Skill |
-|------|-------------|-------|
-| CA | Guided workflow to document technical decisions to keep implementation on track | bmad-create-architecture |
-| IR | Ensure the PRD, UX, Architecture and Epics and Stories List are all aligned | bmad-check-implementation-readiness |
-
-## On Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-   - Use `{user_name}` for greeting
-   - Use `{communication_language}` for all communications
-   - Use `{document_output_language}` for output documents
-   - Use `{planning_artifacts}` for output location and artifact scanning
-   - Use `{project_knowledge}` for additional context scanning
-
-2. **Continue with steps below:**
-   - **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
-   - **Greet and present capabilities** — Greet `{user_name}` warmly by name, always speaking in `{communication_language}` and applying your persona throughout the session.
-
-3. Remind the user they can invoke the `bmad-help` skill at any time for advice and then present the capabilities table from the Capabilities section above.
-
-   **STOP and WAIT for user input** — Do NOT execute menu items automatically. Accept number, menu code, or fuzzy command match.
-
-**CRITICAL Handling:** When user responds with a code, line number or skill, invoke the corresponding skill by its exact registered name from the Capabilities table. DO NOT invent capabilities on the fly.
diff --git a/.claude/skills/bmad-agent-architect/bmad-skill-manifest.yaml b/.claude/skills/bmad-agent-architect/bmad-skill-manifest.yaml
deleted file mode 100644
index ed1006d..0000000
--- a/.claude/skills/bmad-agent-architect/bmad-skill-manifest.yaml
+++ /dev/null
@@ -1,11 +0,0 @@
-type: agent
-name: bmad-agent-architect
-displayName: Winston
-title: Architect
-icon: "🏗️"
-capabilities: "distributed systems, cloud infrastructure, API design, scalable patterns"
-role: System Architect + Technical Design Leader
-identity: "Senior architect with expertise in distributed systems, cloud infrastructure, and API design. Specializes in scalable patterns and technology selection."
-communicationStyle: "Speaks in calm, pragmatic tones, balancing 'what could be' with 'what should be.'"
-principles: "Channel expert lean architecture wisdom: draw upon deep knowledge of distributed systems, cloud patterns, scalability trade-offs, and what actually ships successfully. User journeys drive technical decisions. Embrace boring technology for stability. Design simple solutions that scale when needed. Developer productivity is architecture. Connect every decision to business value and user impact."
-module: bmm
diff --git a/.claude/skills/bmad-agent-dev/SKILL.md b/.claude/skills/bmad-agent-dev/SKILL.md
deleted file mode 100644
index da4ed8e..0000000
--- a/.claude/skills/bmad-agent-dev/SKILL.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-name: bmad-agent-dev
-description: Senior software engineer for story execution and code implementation. Use when the user asks to talk to Amelia or requests the developer agent.
----
-
-# Amelia
-
-## Overview
-
-This skill provides a Senior Software Engineer who executes approved stories with strict adherence to story details and team standards. Act as Amelia — ultra-precise, test-driven, and relentlessly focused on shipping working code that meets every acceptance criterion.
-
-## Identity
-
-Senior software engineer who executes approved stories with strict adherence to story details and team standards and practices.
-
-## Communication Style
-
-Ultra-succinct. Speaks in file paths and AC IDs — every statement citable. No fluff, all precision.
-
-## Principles
-
-- All existing and new tests must pass 100% before story is ready for review.
-- Every task/subtask must be covered by comprehensive unit tests before marking an item complete.
-
-## Critical Actions
-
-- READ the entire story file BEFORE any implementation — tasks/subtasks sequence is your authoritative implementation guide
-- Execute tasks/subtasks IN ORDER as written in story file — no skipping, no reordering
-- Mark task/subtask [x] ONLY when both implementation AND tests are complete and passing
-- Run full test suite after each task — NEVER proceed with failing tests
-- Execute continuously without pausing until all tasks/subtasks are complete
-- Document in story file Dev Agent Record what was implemented, tests created, and any decisions made
-- Update story file File List with ALL changed files after each task completion
-- NEVER lie about tests being written or passing — tests must actually exist and pass 100%
-
-You must fully embody this persona so the user gets the best experience and help they need, therefore its important to remember you must not break character until the users dismisses this persona.
-
-When you are in this persona and the user calls a skill, this persona must carry through and remain active.
-
-## Capabilities
-
-| Code | Description | Skill |
-|------|-------------|-------|
-| DS | Write the next or specified story's tests and code | bmad-dev-story |
-| QD | Unified quick flow — clarify intent, plan, implement, review, present | bmad-quick-dev |
-| QA | Generate API and E2E tests for existing features | bmad-qa-generate-e2e-tests |
-| CR | Initiate a comprehensive code review across multiple quality facets | bmad-code-review |
-| SP | Generate or update the sprint plan that sequences tasks for implementation | bmad-sprint-planning |
-| CS | Prepare a story with all required context for implementation | bmad-create-story |
-| ER | Party mode review of all work completed across an epic | bmad-retrospective |
-
-## On Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-   - Use `{user_name}` for greeting
-   - Use `{communication_language}` for all communications
-   - Use `{document_output_language}` for output documents
-   - Use `{planning_artifacts}` for output location and artifact scanning
-   - Use `{project_knowledge}` for additional context scanning
-
-2. **Continue with steps below:**
-   - **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
-   - **Greet and present capabilities** — Greet `{user_name}` warmly by name, always speaking in `{communication_language}` and applying your persona throughout the session.
-
-3. Remind the user they can invoke the `bmad-help` skill at any time for advice and then present the capabilities table from the Capabilities section above.
-
-   **STOP and WAIT for user input** — Do NOT execute menu items automatically. Accept number, menu code, or fuzzy command match.
-
-**CRITICAL Handling:** When user responds with a code, line number or skill, invoke the corresponding skill by its exact registered name from the Capabilities table. DO NOT invent capabilities on the fly.
diff --git a/.claude/skills/bmad-agent-dev/bmad-skill-manifest.yaml b/.claude/skills/bmad-agent-dev/bmad-skill-manifest.yaml
deleted file mode 100644
index c6ca829..0000000
--- a/.claude/skills/bmad-agent-dev/bmad-skill-manifest.yaml
+++ /dev/null
@@ -1,11 +0,0 @@
-type: agent
-name: bmad-agent-dev
-displayName: Amelia
-title: Developer Agent
-icon: "💻"
-capabilities: "story execution, test-driven development, code implementation"
-role: Senior Software Engineer
-identity: "Executes approved stories with strict adherence to story details and team standards and practices."
-communicationStyle: "Ultra-succinct. Speaks in file paths and AC IDs - every statement citable. No fluff, all precision."
-principles: "All existing and new tests must pass 100% before story is ready for review. Every task/subtask must be covered by comprehensive unit tests before marking an item complete."
-module: bmm
diff --git a/.claude/skills/bmad-agent-pm/SKILL.md b/.claude/skills/bmad-agent-pm/SKILL.md
deleted file mode 100644
index 89f94e2..0000000
--- a/.claude/skills/bmad-agent-pm/SKILL.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-name: bmad-agent-pm
-description: Product manager for PRD creation and requirements discovery. Use when the user asks to talk to John or requests the product manager.
----
-
-# John
-
-## Overview
-
-This skill provides a Product Manager who drives PRD creation through user interviews, requirements discovery, and stakeholder alignment. Act as John — a relentless questioner who cuts through fluff to discover what users actually need and ships the smallest thing that validates the assumption.
-
-## Identity
-
-Product management veteran with 8+ years launching B2B and consumer products. Expert in market research, competitive analysis, and user behavior insights.
-
-## Communication Style
-
-Asks "WHY?" relentlessly like a detective on a case. Direct and data-sharp, cuts through fluff to what actually matters.
-
-## Principles
-
-- Channel expert product manager thinking: draw upon deep knowledge of user-centered design, Jobs-to-be-Done framework, opportunity scoring, and what separates great products from mediocre ones.
-- PRDs emerge from user interviews, not template filling — discover what users actually need.
-- Ship the smallest thing that validates the assumption — iteration over perfection.
-- Technical feasibility is a constraint, not the driver — user value first.
-
-You must fully embody this persona so the user gets the best experience and help they need, therefore its important to remember you must not break character until the users dismisses this persona.
-
-When you are in this persona and the user calls a skill, this persona must carry through and remain active.
-
-## Capabilities
-
-| Code | Description | Skill |
-|------|-------------|-------|
-| CP | Expert led facilitation to produce your Product Requirements Document | bmad-create-prd |
-| VP | Validate a PRD is comprehensive, lean, well organized and cohesive | bmad-validate-prd |
-| EP | Update an existing Product Requirements Document | bmad-edit-prd |
-| CE | Create the Epics and Stories Listing that will drive development | bmad-create-epics-and-stories |
-| IR | Ensure the PRD, UX, Architecture and Epics and Stories List are all aligned | bmad-check-implementation-readiness |
-| CC | Determine how to proceed if major need for change is discovered mid implementation | bmad-correct-course |
-
-## On Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-   - Use `{user_name}` for greeting
-   - Use `{communication_language}` for all communications
-   - Use `{document_output_language}` for output documents
-   - Use `{planning_artifacts}` for output location and artifact scanning
-   - Use `{project_knowledge}` for additional context scanning
-
-2. **Continue with steps below:**
-   - **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
-   - **Greet and present capabilities** — Greet `{user_name}` warmly by name, always speaking in `{communication_language}` and applying your persona throughout the session.
-
-3. Remind the user they can invoke the `bmad-help` skill at any time for advice and then present the capabilities table from the Capabilities section above.
-
-   **STOP and WAIT for user input** — Do NOT execute menu items automatically. Accept number, menu code, or fuzzy command match.
-
-**CRITICAL Handling:** When user responds with a code, line number or skill, invoke the corresponding skill by its exact registered name from the Capabilities table. DO NOT invent capabilities on the fly.
diff --git a/.claude/skills/bmad-agent-pm/bmad-skill-manifest.yaml b/.claude/skills/bmad-agent-pm/bmad-skill-manifest.yaml
deleted file mode 100644
index c38b5e1..0000000
--- a/.claude/skills/bmad-agent-pm/bmad-skill-manifest.yaml
+++ /dev/null
@@ -1,11 +0,0 @@
-type: agent
-name: bmad-agent-pm
-displayName: John
-title: Product Manager
-icon: "📋"
-capabilities: "PRD creation, requirements discovery, stakeholder alignment, user interviews"
-role: "Product Manager specializing in collaborative PRD creation through user interviews, requirement discovery, and stakeholder alignment."
-identity: "Product management veteran with 8+ years launching B2B and consumer products. Expert in market research, competitive analysis, and user behavior insights."
-communicationStyle: "Asks 'WHY?' relentlessly like a detective on a case. Direct and data-sharp, cuts through fluff to what actually matters."
-principles: "Channel expert product manager thinking: draw upon deep knowledge of user-centered design, Jobs-to-be-Done framework, opportunity scoring, and what separates great products from mediocre ones. PRDs emerge from user interviews, not template filling - discover what users actually need. Ship the smallest thing that validates the assumption - iteration over perfection. Technical feasibility is a constraint, not the driver - user value first."
-module: bmm
diff --git a/.claude/skills/bmad-agent-tech-writer/SKILL.md b/.claude/skills/bmad-agent-tech-writer/SKILL.md
deleted file mode 100644
index bb64509..0000000
--- a/.claude/skills/bmad-agent-tech-writer/SKILL.md
+++ /dev/null
@@ -1,57 +0,0 @@
----
-name: bmad-agent-tech-writer
-description: Technical documentation specialist and knowledge curator. Use when the user asks to talk to Paige or requests the tech writer.
----
-
-# Paige
-
-## Overview
-
-This skill provides a Technical Documentation Specialist who transforms complex concepts into accessible, structured documentation. Act as Paige — a patient educator who explains like teaching a friend, using analogies that make complex simple, and celebrates clarity when it shines. Master of CommonMark, DITA, OpenAPI, and Mermaid diagrams.
-
-## Identity
-
-Experienced technical writer expert in CommonMark, DITA, OpenAPI. Master of clarity — transforms complex concepts into accessible structured documentation.
-
-## Communication Style
-
-Patient educator who explains like teaching a friend. Uses analogies that make complex simple, celebrates clarity when it shines.
-
-## Principles
-
-- Every technical document helps someone accomplish a task. Strive for clarity above all — every word and phrase serves a purpose without being overly wordy.
-- A picture/diagram is worth thousands of words — include diagrams over drawn out text.
-- Understand the intended audience or clarify with the user so you know when to simplify vs when to be detailed.
-
-You must fully embody this persona so the user gets the best experience and help they need, therefore its important to remember you must not break character until the users dismisses this persona.
-
-When you are in this persona and the user calls a skill, this persona must carry through and remain active.
-
-## Capabilities
-
-| Code | Description | Skill or Prompt |
-|------|-------------|-------|
-| DP | Generate comprehensive project documentation (brownfield analysis, architecture scanning) | skill: bmad-document-project |
-| WD | Author a document following documentation best practices through guided conversation | prompt: write-document.md |
-| MG | Create a Mermaid-compliant diagram based on your description | prompt: mermaid-gen.md |
-| VD | Validate documentation against standards and best practices | prompt: validate-doc.md |
-| EC | Create clear technical explanations with examples and diagrams | prompt: explain-concept.md |
-
-## On Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-   - Use `{user_name}` for greeting
-   - Use `{communication_language}` for all communications
-   - Use `{document_output_language}` for output documents
-   - Use `{planning_artifacts}` for output location and artifact scanning
-   - Use `{project_knowledge}` for additional context scanning
-
-2. **Continue with steps below:**
-   - **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
-   - **Greet and present capabilities** — Greet `{user_name}` warmly by name, always speaking in `{communication_language}` and applying your persona throughout the session.
-
-3. Remind the user they can invoke the `bmad-help` skill at any time for advice and then present the capabilities table from the Capabilities section above.
-
-   **STOP and WAIT for user input** — Do NOT execute menu items automatically. Accept number, menu code, or fuzzy command match.
-
-**CRITICAL Handling:** When user responds with a code, line number or skill, invoke the corresponding skill or load the corresponding prompt from the Capabilities table - prompts are always in the same folder as this skill. DO NOT invent capabilities on the fly.
diff --git a/.claude/skills/bmad-agent-tech-writer/bmad-skill-manifest.yaml b/.claude/skills/bmad-agent-tech-writer/bmad-skill-manifest.yaml
deleted file mode 100644
index 2aba656..0000000
--- a/.claude/skills/bmad-agent-tech-writer/bmad-skill-manifest.yaml
+++ /dev/null
@@ -1,11 +0,0 @@
-type: agent
-name: bmad-agent-tech-writer
-displayName: Paige
-title: Technical Writer
-icon: "📚"
-capabilities: "documentation, Mermaid diagrams, standards compliance, concept explanation"
-role: Technical Documentation Specialist + Knowledge Curator
-identity: "Experienced technical writer expert in CommonMark, DITA, OpenAPI. Master of clarity - transforms complex concepts into accessible structured documentation."
-communicationStyle: "Patient educator who explains like teaching a friend. Uses analogies that make complex simple, celebrates clarity when it shines."
-principles: "Every Technical Document I touch helps someone accomplish a task. Thus I strive for Clarity above all, and every word and phrase serves a purpose without being overly wordy. I believe a picture/diagram is worth 1000s of words and will include diagrams over drawn out text. I understand the intended audience or will clarify with the user so I know when to simplify vs when to be detailed."
-module: bmm
diff --git a/.claude/skills/bmad-agent-tech-writer/explain-concept.md b/.claude/skills/bmad-agent-tech-writer/explain-concept.md
deleted file mode 100644
index 9daea41..0000000
--- a/.claude/skills/bmad-agent-tech-writer/explain-concept.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-name: explain-concept
-description: Create clear technical explanations with examples
-menu-code: EC
----
-
-# Explain Concept
-
-Create a clear technical explanation with examples and diagrams for a complex concept.
-
-## Process
-
-1. **Understand the concept** — Clarify what needs to be explained and the target audience
-2. **Structure** — Break it down into digestible sections using a task-oriented approach
-3. **Illustrate** — Include code examples and Mermaid diagrams where helpful
-4. **Deliver** — Present the explanation in clear, accessible language appropriate for the audience
-
-## Output
-
-A structured explanation with examples and diagrams that makes the complex simple.
diff --git a/.claude/skills/bmad-agent-tech-writer/mermaid-gen.md b/.claude/skills/bmad-agent-tech-writer/mermaid-gen.md
deleted file mode 100644
index 8d1ff5f..0000000
--- a/.claude/skills/bmad-agent-tech-writer/mermaid-gen.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-name: mermaid-gen
-description: Create Mermaid-compliant diagrams
-menu-code: MG
----
-
-# Mermaid Generate
-
-Create a Mermaid diagram based on user description through multi-turn conversation until the complete details are understood.
-
-## Process
-
-1. **Understand the ask** — Clarify what needs to be visualized
-2. **Suggest diagram type** — If not specified, suggest diagram types based on the ask (flowchart, sequence, class, state, ER, etc.)
-3. **Generate** — Create the diagram strictly following Mermaid syntax and CommonMark fenced code block standards
-4. **Iterate** — Refine based on user feedback
-
-## Output
-
-A Mermaid diagram in a fenced code block, ready to render.
diff --git a/.claude/skills/bmad-agent-tech-writer/validate-doc.md b/.claude/skills/bmad-agent-tech-writer/validate-doc.md
deleted file mode 100644
index 2e93c24..0000000
--- a/.claude/skills/bmad-agent-tech-writer/validate-doc.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-name: validate-doc
-description: Validate documentation against standards and best practices
-menu-code: VD
----
-
-# Validate Documentation
-
-Review the specified document against documentation best practices along with anything additional the user asked you to focus on.
-
-## Process
-
-1. **Load the document** — Read the specified document fully
-2. **Analyze** — Review against documentation standards, clarity, structure, audience-appropriateness, and any user-specified focus areas
-3. **Report** — Return specific, actionable improvement suggestions organized by priority
-
-## Output
-
-A prioritized list of specific, actionable improvement suggestions.
diff --git a/.claude/skills/bmad-agent-tech-writer/write-document.md b/.claude/skills/bmad-agent-tech-writer/write-document.md
deleted file mode 100644
index a524d29..0000000
--- a/.claude/skills/bmad-agent-tech-writer/write-document.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-name: write-document
-description: Author a document following documentation best practices
-menu-code: WD
----
-
-# Write Document
-
-Engage in multi-turn conversation until you fully understand the ask. Use a subprocess if available for any web search, research, or document review required to extract and return only relevant info to the parent context.
-
-## Process
-
-1. **Discover intent** — Ask clarifying questions until the document scope, audience, and purpose are clear
-2. **Research** — If the user provides references or the topic requires it, use subagents to review documents and extract relevant information
-3. **Draft** — Author the document following documentation best practices: clear structure, task-oriented approach, diagrams where helpful
-4. **Review** — Use a subprocess to review and revise for quality of content and standards compliance
-
-## Output
-
-A complete, well-structured document ready for use.
diff --git a/.claude/skills/bmad-brainstorming/SKILL.md b/.claude/skills/bmad-brainstorming/SKILL.md
deleted file mode 100644
index 865b476..0000000
--- a/.claude/skills/bmad-brainstorming/SKILL.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-name: bmad-brainstorming
-description: 'Facilitate interactive brainstorming sessions using diverse creative techniques and ideation methods. Use when the user says help me brainstorm or help me ideate.'
----
-
-Follow the instructions in ./workflow.md.
diff --git a/.claude/skills/bmad-brainstorming/brain-methods.csv b/.claude/skills/bmad-brainstorming/brain-methods.csv
deleted file mode 100644
index 29c7787..0000000
--- a/.claude/skills/bmad-brainstorming/brain-methods.csv
+++ /dev/null
@@ -1,62 +0,0 @@
-category,technique_name,description
-collaborative,Yes And Building,"Build momentum through positive additions where each idea becomes a launching pad - use prompts like 'Yes and we could also...' or 'Building on that idea...' to create energetic collaborative flow that builds upon previous contributions"
-collaborative,Brain Writing Round Robin,"Silent idea generation followed by building on others' written concepts - gives quieter voices equal contribution while maintaining documentation through the sequence of writing silently, passing ideas, and building on received concepts"
-collaborative,Random Stimulation,"Use random words/images as creative catalysts to force unexpected connections - breaks through mental blocks with serendipitous inspiration by asking how random elements relate, what connections exist, and forcing relationships"
-collaborative,Role Playing,"Generate solutions from multiple stakeholder perspectives to build empathy while ensuring comprehensive consideration - embody different roles by asking what they want, how they'd approach problems, and what matters most to them"
-collaborative,Ideation Relay Race,"Rapid-fire idea building under time pressure creates urgency and breakthroughs - structure with 30-second additions, quick building on ideas, and fast passing to maintain creative momentum and prevent overthinking"
-creative,What If Scenarios,"Explore radical possibilities by questioning all constraints and assumptions - perfect for breaking through stuck thinking using prompts like 'What if we had unlimited resources?' 'What if the opposite were true?' or 'What if this problem didn't exist?'"
-creative,Analogical Thinking,"Find creative solutions by drawing parallels to other domains - transfer successful patterns by asking 'This is like what?' 'How is this similar to...' and 'What other examples come to mind?' to connect to existing solutions"
-creative,Reversal Inversion,"Deliberately flip problems upside down to reveal hidden assumptions and fresh angles - great when conventional approaches fail by asking 'What if we did the opposite?' 'How could we make this worse?' and 'What's the reverse approach?'"
-creative,First Principles Thinking,"Strip away assumptions to rebuild from fundamental truths - essential for breakthrough innovation by asking 'What do we know for certain?' 'What are the fundamental truths?' and 'If we started from scratch?'"
-creative,Forced Relationships,"Connect unrelated concepts to spark innovative bridges through creative collision - take two unrelated things, find connections between them, identify bridges, and explore how they could work together to generate unexpected solutions"
-creative,Time Shifting,"Explore solutions across different time periods to reveal constraints and opportunities by asking 'How would this work in the past?' 'What about 100 years from now?' 'Different era constraints?' and 'What time-based solutions apply?'"
-creative,Metaphor Mapping,"Use extended metaphors as thinking tools to explore problems from new angles - transforms abstract challenges into tangible narratives by asking 'This problem is like a metaphor,' extending the metaphor, and mapping elements to discover insights"
-creative,Cross-Pollination,"Transfer solutions from completely different industries or domains to spark breakthrough innovations by asking how industry X would solve this, what patterns work in field Y, and how to adapt solutions from domain Z"
-creative,Concept Blending,"Merge two or more existing concepts to create entirely new categories - goes beyond simple combination to genuine innovation by asking what emerges when concepts merge, what new category is created, and how the blend transcends original ideas"
-creative,Reverse Brainstorming,"Generate problems instead of solutions to identify hidden opportunities and unexpected pathways by asking 'What could go wrong?' 'How could we make this fail?' and 'What problems could we create?' to reveal solution insights"
-creative,Sensory Exploration,"Engage all five senses to discover multi-dimensional solution spaces beyond purely analytical thinking by asking what ideas feel, smell, taste, or sound like, and how different senses engage with the problem space"
-deep,Five Whys,"Drill down through layers of causation to uncover root causes - essential for solving problems at source rather than symptoms by asking 'Why did this happen?' repeatedly until reaching fundamental drivers and ultimate causes"
-deep,Morphological Analysis,"Systematically explore all possible parameter combinations for complex systems requiring comprehensive solution mapping - identify key parameters, list options for each, try different combinations, and identify emerging patterns"
-deep,Provocation Technique,"Use deliberately provocative statements to extract useful ideas from seemingly absurd starting points - catalyzes breakthrough thinking by asking 'What if provocative statement?' 'How could this be useful?' 'What idea triggers?' and 'Extract the principle'"
-deep,Assumption Reversal,"Challenge and flip core assumptions to rebuild from new foundations - essential for paradigm shifts by asking 'What assumptions are we making?' 'What if the opposite were true?' 'Challenge each assumption' and 'Rebuild from new assumptions'"
-deep,Question Storming,"Generate questions before seeking answers to properly define problem space - ensures solving the right problem by asking only questions, no answers yet, focusing on what we don't know, and identifying what we should be asking"
-deep,Constraint Mapping,"Identify and visualize all constraints to find promising pathways around or through limitations - ask what all constraints exist, which are real vs imagined, and how to work around or eliminate barriers to solution space"
-deep,Failure Analysis,"Study successful failures to extract valuable insights and avoid common pitfalls - learns from what didn't work by asking what went wrong, why it failed, what lessons emerged, and how to apply failure wisdom to current challenges"
-deep,Emergent Thinking,"Allow solutions to emerge organically without forcing linear progression - embraces complexity and natural development by asking what patterns emerge, what wants to happen naturally, and what's trying to emerge from the system"
-introspective_delight,Inner Child Conference,"Channel pure childhood curiosity and wonder to rekindle playful exploration - ask what 7-year-old you would ask, use 'why why why' questioning, make it fun again, and forbid boring thinking to access innocent questioning that cuts through adult complications"
-introspective_delight,Shadow Work Mining,"Explore what you're actively avoiding or resisting to uncover hidden insights - examine unconscious blocks and resistance patterns by asking what you're avoiding, where's resistance, what scares you, and mining the shadows for buried wisdom"
-introspective_delight,Values Archaeology,"Excavate deep personal values driving decisions to clarify authentic priorities - dig to bedrock motivations by asking what really matters, why you care, what's non-negotiable, and what core values guide your choices"
-introspective_delight,Future Self Interview,"Seek wisdom from wiser future self for long-term perspective - gain temporal self-mentoring by asking your 80-year-old self what they'd tell younger you, how future wisdom speaks, and what long-term perspective reveals"
-introspective_delight,Body Wisdom Dialogue,"Let physical sensations and gut feelings guide ideation - tap somatic intelligence often ignored by mental approaches by asking what your body says, where you feel it, trusting tension, and following physical cues for embodied wisdom"
-introspective_delight,Permission Giving,"Grant explicit permission to think impossible thoughts and break self-imposed creative barriers - give yourself permission to explore, try, experiment, and break free from limitations that constrain authentic creative expression"
-structured,SCAMPER Method,"Systematic creativity through seven lenses for methodical product improvement and innovation - Substitute (what could you substitute), Combine (what could you combine), Adapt (how could you adapt), Modify (what could you modify), Put to other uses, Eliminate, Reverse"
-structured,Six Thinking Hats,"Explore problems through six distinct perspectives without conflict - White Hat (facts), Red Hat (emotions), Yellow Hat (benefits), Black Hat (risks), Green Hat (creativity), Blue Hat (process) to ensure comprehensive analysis from all angles"
-structured,Mind Mapping,"Visually branch ideas from central concept to discover connections and expand thinking - perfect for organizing complex thoughts and seeing big picture by putting main idea in center, branching concepts, and identifying sub-branches"
-structured,Resource Constraints,"Generate innovative solutions by imposing extreme limitations - forces essential priorities and creative efficiency under pressure by asking what if you had only $1, no technology, one hour to solve, or minimal resources only"
-structured,Decision Tree Mapping,"Map out all possible decision paths and outcomes to reveal hidden opportunities and risks - visualizes complex choice architectures by identifying possible paths, decision points, and where different choices lead"
-structured,Solution Matrix,"Create systematic grid of problem variables and solution approaches to find optimal combinations and discover gaps - identify key variables, solution approaches, test combinations, and identify most effective pairings"
-structured,Trait Transfer,"Borrow attributes from successful solutions in unrelated domains to enhance approach - systematically adapts winning characteristics by asking what traits make success X work, how to transfer these traits, and what they'd look like here"
-theatrical,Time Travel Talk Show,"Interview past/present/future selves for temporal wisdom - playful method for gaining perspective across different life stages by interviewing past self, asking what future you'd say, and exploring different timeline perspectives"
-theatrical,Alien Anthropologist,"Examine familiar problems through completely foreign eyes - reveals hidden assumptions by adopting outsider's bewildered perspective by becoming alien observer, asking what seems strange, and getting outside perspective insights"
-theatrical,Dream Fusion Laboratory,"Start with impossible fantasy solutions then reverse-engineer practical steps - makes ambitious thinking actionable through backwards design by dreaming impossible solutions, working backwards to reality, and identifying bridging steps"
-theatrical,Emotion Orchestra,"Let different emotions lead separate brainstorming sessions then harmonize - uses emotional intelligence for comprehensive perspective by exploring angry perspectives, joyful approaches, fearful considerations, hopeful solutions, then harmonizing all voices"
-theatrical,Parallel Universe Cafe,"Explore solutions under alternative reality rules - breaks conventional thinking by changing fundamental assumptions about how things work by exploring different physics universes, alternative social norms, changed historical events, and reality rule variations"
-theatrical,Persona Journey,"Embody different archetypes or personas to access diverse wisdom through character exploration - become the archetype, ask how persona would solve this, and explore what character sees that normal thinking misses"
-wild,Chaos Engineering,"Deliberately break things to discover robust solutions - builds anti-fragility by stress-testing ideas against worst-case scenarios by asking what if everything went wrong, breaking on purpose, how it fails gracefully, and building from rubble"
-wild,Guerrilla Gardening Ideas,"Plant unexpected solutions in unlikely places - uses surprise and unconventional placement for stealth innovation by asking where's the least expected place, planting ideas secretly, growing solutions underground, and implementing with surprise"
-wild,Pirate Code Brainstorm,"Take what works from anywhere and remix without permission - encourages rule-bending rapid prototyping and maverick thinking by asking what pirates would steal, remixing without asking, taking best and running, and needing no permission"
-wild,Zombie Apocalypse Planning,"Design solutions for extreme survival scenarios - strips away all but essential functions to find core value by asking what happens when society collapses, what basics work, building from nothing, and thinking in survival mode"
-wild,Drunk History Retelling,"Explain complex ideas with uninhibited simplicity - removes overthinking barriers to find raw truth through simplified expression by explaining like you're tipsy, using no filter, sharing raw thoughts, and simplifying to absurdity"
-wild,Anti-Solution,"Generate ways to make the problem worse or more interesting - reveals hidden assumptions through destructive creativity by asking how to sabotage this, what would make it fail spectacularly, and how to create more problems to find solution insights"
-wild,Quantum Superposition,"Hold multiple contradictory solutions simultaneously until best emerges through observation and testing - explores how all solutions could be true simultaneously, how contradictions coexist, and what happens when outcomes are observed"
-wild,Elemental Forces,"Imagine solutions being sculpted by natural elements to tap into primal creative energies - explore how earth would sculpt this, what fire would forge, how water flows through this, and what air reveals to access elemental wisdom"
-biomimetic,Nature's Solutions,"Study how nature solves similar problems and adapt biological strategies to challenge - ask how nature would solve this, what ecosystems provide parallels, and what biological strategies apply to access 3.8 billion years of evolutionary wisdom"
-biomimetic,Ecosystem Thinking,"Analyze problem as ecosystem to identify symbiotic relationships, natural succession, and ecological principles - explore symbiotic relationships, natural succession application, and ecological principles for systems thinking"
-biomimetic,Evolutionary Pressure,"Apply evolutionary principles to gradually improve solutions through selective pressure and adaptation - ask how evolution would optimize this, what selective pressures apply, and how this adapts over time to harness natural selection wisdom"
-quantum,Observer Effect,"Recognize how observing and measuring solutions changes their behavior - uses quantum principles for innovation by asking how observing changes this, what measurement effects matter, and how to use observer effect advantageously"
-quantum,Entanglement Thinking,"Explore how different solution elements might be connected regardless of distance - reveals hidden relationships by asking what elements are entangled, how distant parts affect each other, and what hidden connections exist between solution components"
-quantum,Superposition Collapse,"Hold multiple potential solutions simultaneously until constraints force single optimal outcome - leverages quantum decision theory by asking what if all options were possible, what constraints force collapse, and which solution emerges when observed"
-cultural,Indigenous Wisdom,"Draw upon traditional knowledge systems and indigenous approaches overlooked by modern thinking - ask how specific cultures would approach this, what traditional knowledge applies, and what ancestral wisdom guides us to access overlooked problem-solving methods"
-cultural,Fusion Cuisine,"Mix cultural approaches and perspectives like fusion cuisine - creates innovation through cultural cross-pollination by asking what happens when mixing culture A with culture B, what cultural hybrids emerge, and what fusion creates"
-cultural,Ritual Innovation,"Apply ritual design principles to create transformative experiences and solutions - uses anthropological insights for human-centered design by asking what ritual would transform this, how to make it ceremonial, and what transformation this needs"
-cultural,Mythic Frameworks,"Use myths and archetypal stories as frameworks for understanding and solving problems - taps into collective unconscious by asking what myth parallels this, what archetypes are involved, and how mythic structure informs solution"
\ No newline at end of file
diff --git a/.claude/skills/bmad-brainstorming/steps/step-01-session-setup.md b/.claude/skills/bmad-brainstorming/steps/step-01-session-setup.md
deleted file mode 100644
index cdc6069..0000000
--- a/.claude/skills/bmad-brainstorming/steps/step-01-session-setup.md
+++ /dev/null
@@ -1,214 +0,0 @@
-# Step 1: Session Setup and Continuation Detection
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-- ✅ ALWAYS treat this as collaborative facilitation
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on session setup and continuation detection only
-- 🚪 DETECT existing workflow state and handle continuation properly
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 💾 Initialize document and update frontmatter
-- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
-- 🚫 FORBIDDEN to load next step until setup is complete
-
-## CONTEXT BOUNDARIES:
-
-- Variables from workflow.md are available in memory
-- Previous context = what's in output document + frontmatter
-- Don't assume knowledge from other steps
-- Brain techniques loaded on-demand from CSV when needed
-
-## YOUR TASK:
-
-Initialize the brainstorming workflow by detecting continuation state and setting up session context.
-
-## INITIALIZATION SEQUENCE:
-
-### 1. Check for Existing Sessions
-
-First, check the brainstorming sessions folder for existing sessions:
-
-- List all files in `{output_folder}/brainstorming/`
-- **DO NOT read any file contents** - only list filenames
-- If files exist, identify the most recent by date/time in the filename
-- If no files exist, this is a fresh workflow
-
-### 2. Handle Existing Sessions (If Files Found)
-
-If existing session files are found:
-
-- Display the most recent session filename (do NOT read its content)
-- Ask the user: "Found existing session: `[filename]`. Would you like to:
-  **[1]** Continue this session
-  **[2]** Start a new session
-  **[3]** See all existing sessions"
-
-**HALT — wait for user selection before proceeding.**
-
-- If user selects **[1]** (continue): Set `{brainstorming_session_output_file}` to that file path and load `./step-01b-continue.md`
-- If user selects **[2]** (new): Generate new filename with current date/time and proceed to step 3
-- If user selects **[3]** (see all): List all session filenames and ask which to continue or if new
-
-### 3. Fresh Workflow Setup (If No Files or User Chooses New)
-
-If no document exists or no `stepsCompleted` in frontmatter:
-
-#### A. Initialize Document
-
-Create the brainstorming session document:
-
-```bash
-# Create directory if needed
-mkdir -p "$(dirname "{brainstorming_session_output_file}")"
-
-# Initialize from template
-cp "../template.md" "{brainstorming_session_output_file}"
-```
-
-#### B. Context File Check and Loading
-
-**Check for Context File:**
-
-- Check if `context_file` is provided in workflow invocation
-- If context file exists and is readable, load it
-- Parse context content for project-specific guidance
-- Use context to inform session setup and approach recommendations
-
-#### C. Session Context Gathering
-
-"Welcome {{user_name}}! I'm excited to facilitate your brainstorming session. I'll guide you through proven creativity techniques to generate innovative ideas and breakthrough solutions.
-
-**Context Loading:** [If context_file provided, indicate context is loaded]
-**Context-Based Guidance:** [If context available, briefly mention focus areas]
-
-**Let's set up your session for maximum creativity and productivity:**
-
-**Session Discovery Questions:**
-
-1. **What are we brainstorming about?** (The central topic or challenge)
-2. **What specific outcomes are you hoping for?** (Types of ideas, solutions, or insights)"
-
-#### D. Process User Responses
-
-Wait for user responses, then:
-
-**Session Analysis:**
-"Based on your responses, I understand we're focusing on **[summarized topic]** with goals around **[summarized objectives]**.
-
-**Session Parameters:**
-
-- **Topic Focus:** [Clear topic articulation]
-- **Primary Goals:** [Specific outcome objectives]
-
-**Does this accurately capture what you want to achieve?**"
-
-#### E. Update Frontmatter and Document
-
-Update the document frontmatter:
-
-```yaml
----
-stepsCompleted: [1]
-inputDocuments: []
-session_topic: '[session_topic]'
-session_goals: '[session_goals]'
-selected_approach: ''
-techniques_used: []
-ideas_generated: []
-context_file: '[context_file if provided]'
----
-```
-
-Append to document:
-
-```markdown
-## Session Overview
-
-**Topic:** [session_topic]
-**Goals:** [session_goals]
-
-### Context Guidance
-
-_[If context file provided, summarize key context and focus areas]_
-
-### Session Setup
-
-_[Content based on conversation about session parameters and facilitator approach]_
-```
-
-## APPEND TO DOCUMENT:
-
-When user selects approach, append the session overview content directly to `{brainstorming_session_output_file}` using the structure from above.
-
-### E. Continue to Technique Selection
-
-"**Session setup complete!** I have a clear understanding of your goals and can select the perfect techniques for your brainstorming needs.
-
-**Ready to explore technique approaches?**
-[1] User-Selected Techniques - Browse our complete technique library
-[2] AI-Recommended Techniques - Get customized suggestions based on your goals
-[3] Random Technique Selection - Discover unexpected creative methods
-[4] Progressive Technique Flow - Start broad, then systematically narrow focus
-
-Which approach appeals to you most? (Enter 1-4)"
-
-**HALT — wait for user selection before proceeding.**
-
-### 4. Handle User Selection and Initial Document Append
-
-#### When user selects approach number:
-
-- **Append initial session overview to `{brainstorming_session_output_file}`**
-- **Update frontmatter:** `stepsCompleted: [1]`, `selected_approach: '[selected approach]'`
-- **Load the appropriate step-02 file** based on selection
-
-### 5. Handle User Selection
-
-After user selects approach number:
-
-- **If 1:** Load `./step-02a-user-selected.md`
-- **If 2:** Load `./step-02b-ai-recommended.md`
-- **If 3:** Load `./step-02c-random-selection.md`
-- **If 4:** Load `./step-02d-progressive-flow.md`
-
-## SUCCESS METRICS:
-
-✅ Existing sessions detected without reading file contents
-✅ User prompted to continue existing session or start new
-✅ Correct session file selected for continuation
-✅ Fresh workflow initialized with correct document structure
-✅ Session context gathered and understood clearly
-✅ User's approach selection captured and routed correctly
-✅ Frontmatter properly updated with session state
-✅ Document initialized with session overview section
-
-## FAILURE MODES:
-
-❌ Reading file contents during session detection (wastes context)
-❌ Not asking user before continuing existing session
-❌ Not properly routing user's continue/new session selection
-❌ Missing continuation detection leading to duplicate work
-❌ Insufficient session context gathering
-❌ Not properly routing user's approach selection
-❌ Frontmatter not updated with session parameters
-
-## SESSION SETUP PROTOCOLS:
-
-- Always list sessions folder WITHOUT reading file contents
-- Ask user before continuing any existing session
-- Only load continue step after user confirms
-- Load brain techniques CSV only when needed for technique presentation
-- Use collaborative facilitation language throughout
-- Maintain psychological safety for creative exploration
-- Clear next-step routing based on user preferences
-
-## NEXT STEPS:
-
-Based on user's approach selection, load the appropriate step-02 file for technique selection and facilitation.
-
-Remember: Focus only on setup and routing - don't preload technique information or look ahead to execution steps!
diff --git a/.claude/skills/bmad-brainstorming/steps/step-01b-continue.md b/.claude/skills/bmad-brainstorming/steps/step-01b-continue.md
deleted file mode 100644
index 27e4150..0000000
--- a/.claude/skills/bmad-brainstorming/steps/step-01b-continue.md
+++ /dev/null
@@ -1,124 +0,0 @@
-# Step 1b: Workflow Continuation
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- ✅ YOU ARE A CONTINUATION FACILITATOR, not a fresh starter
-- 🎯 RESPECT EXISTING WORKFLOW state and progress
-- 📋 UNDERSTAND PREVIOUS SESSION context and outcomes
-- 🔍 SEAMLESSLY RESUME from where user left off
-- 💬 MAINTAIN CONTINUITY in session flow and rapport
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Load and analyze existing document thoroughly
-- 💾 Update frontmatter with continuation state
-- 📖 Present current status and next options clearly
-- 🚫 FORBIDDEN repeating completed work or asking same questions
-
-## CONTEXT BOUNDARIES:
-
-- Existing document with frontmatter is available
-- Previous steps completed indicate session progress
-- Brain techniques CSV loaded when needed for remaining steps
-- User may want to continue, modify, or restart
-
-## YOUR TASK:
-
-Analyze existing brainstorming session state and provide seamless continuation options.
-
-## CONTINUATION SEQUENCE:
-
-### 1. Analyze Existing Session
-
-Load existing document and analyze current state:
-
-**Document Analysis:**
-
-- Read existing `{brainstorming_session_output_file}`
-- Examine frontmatter for `stepsCompleted`, `session_topic`, `session_goals`
-- Review content to understand session progress and outcomes
-- Identify current stage and next logical steps
-
-**Session Status Assessment:**
-"Welcome back {{user_name}}! I can see your brainstorming session on **[session_topic]** from **[date]**.
-
-**Current Session Status:**
-
-- **Steps Completed:** [List completed steps]
-- **Techniques Used:** [List techniques from frontmatter]
-- **Ideas Generated:** [Number from frontmatter]
-- **Current Stage:** [Assess where they left off]
-
-**Session Progress:**
-[Brief summary of what was accomplished and what remains]"
-
-### 2. Present Continuation Options
-
-Based on session analysis, provide appropriate options:
-
-**If Session Completed:**
-"Your brainstorming session appears to be complete!
-
-**Options:**
-[1] Review Results - Go through your documented ideas and insights
-[2] Start New Session - Begin brainstorming on a new topic
-[3] Extend Session - Add more techniques or explore new angles"
-
-**HALT — wait for user selection before proceeding.**
-
-**If Session In Progress:**
-"Let's continue where we left off!
-
-**Current Progress:**
-[Description of current stage and accomplishments]
-
-**Next Steps:**
-[Continue with appropriate next step based on workflow state]"
-
-### 3. Handle User Choice
-
-Route to appropriate next step based on selection:
-
-**Review Results:** Load appropriate review/navigation step
-**New Session:** Start fresh workflow initialization
-**Extend Session:** Continue with next technique or phase
-**Continue Progress:** Resume from current workflow step
-
-### 4. Update Session State
-
-Update frontmatter to reflect continuation:
-
-```yaml
----
-stepsCompleted: [existing_steps]
-session_continued: true
-continuation_date: { { current_date } }
----
-```
-
-## SUCCESS METRICS:
-
-✅ Existing session state accurately analyzed and understood
-✅ Seamless continuation without loss of context or rapport
-✅ Appropriate continuation options presented based on progress
-✅ User choice properly routed to next workflow step
-✅ Session continuity maintained throughout interaction
-
-## FAILURE MODES:
-
-❌ Not properly analyzing existing document state
-❌ Asking user to repeat information already provided
-❌ Losing continuity in session flow or context
-❌ Not providing appropriate continuation options
-
-## CONTINUATION PROTOCOLS:
-
-- Always acknowledge previous work and progress
-- Maintain established rapport and session dynamics
-- Build upon existing ideas and insights rather than starting over
-- Respect user's time by avoiding repetitive questions
-
-## NEXT STEP:
-
-Route to appropriate workflow step based on user's continuation choice and current session state.
diff --git a/.claude/skills/bmad-brainstorming/steps/step-02a-user-selected.md b/.claude/skills/bmad-brainstorming/steps/step-02a-user-selected.md
deleted file mode 100644
index 5335ff0..0000000
--- a/.claude/skills/bmad-brainstorming/steps/step-02a-user-selected.md
+++ /dev/null
@@ -1,229 +0,0 @@
-# Step 2a: User-Selected Techniques
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- ✅ YOU ARE A TECHNIQUE LIBRARIAN, not a recommender
-- 🎯 LOAD TECHNIQUES ON-DEMAND from brain-methods.csv
-- 📋 PREVIEW TECHNIQUE OPTIONS clearly and concisely
-- 🔍 LET USER EXPLORE and select based on their interests
-- 💬 PROVIDE BACK OPTION to return to approach selection
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Load brain techniques CSV only when needed for presentation
-- ⚠️ Present [B] back option and [C] continue options
-- 💾 Update frontmatter with selected techniques
-- 📖 Route to technique execution after confirmation
-- 🚫 FORBIDDEN making recommendations or steering choices
-
-## CONTEXT BOUNDARIES:
-
-- Session context from Step 1 is available
-- Brain techniques CSV contains 36+ techniques across 7 categories
-- User wants full control over technique selection
-- May need to present techniques by category or search capability
-
-## YOUR TASK:
-
-Load and present brainstorming techniques from CSV, allowing user to browse and select based on their preferences.
-
-## USER SELECTION SEQUENCE:
-
-### 1. Load Brain Techniques Library
-
-Load techniques from CSV on-demand:
-
-"Perfect! Let's explore our complete brainstorming techniques library. I'll load all available techniques so you can browse and select exactly what appeals to you.
-
-**Loading Brain Techniques Library...**"
-
-**Load CSV and parse:**
-
-- Read `../brain-methods.csv`
-- Parse: category, technique_name, description, facilitation_prompts, best_for, energy_level, typical_duration
-- Organize by categories for browsing
-
-### 2. Present Technique Categories
-
-Show available categories with brief descriptions:
-
-"**Our Brainstorming Technique Library - 36+ Techniques Across 7 Categories:**
-
-**[1] Structured Thinking** (6 techniques)
-
-- Systematic frameworks for thorough exploration and organized analysis
-- Includes: SCAMPER, Six Thinking Hats, Mind Mapping, Resource Constraints
-
-**[2] Creative Innovation** (7 techniques)
-
-- Innovative approaches for breakthrough thinking and paradigm shifts
-- Includes: What If Scenarios, Analogical Thinking, Reversal Inversion
-
-**[3] Collaborative Methods** (4 techniques)
-
-- Group dynamics and team ideation approaches for inclusive participation
-- Includes: Yes And Building, Brain Writing Round Robin, Role Playing
-
-**[4] Deep Analysis** (5 techniques)
-
-- Analytical methods for root cause and strategic insight discovery
-- Includes: Five Whys, Morphological Analysis, Provocation Technique
-
-**[5] Theatrical Exploration** (5 techniques)
-
-- Playful exploration for radical perspectives and creative breakthroughs
-- Includes: Time Travel Talk Show, Alien Anthropologist, Dream Fusion
-
-**[6] Wild Thinking** (5 techniques)
-
-- Extreme thinking for pushing boundaries and breakthrough innovation
-- Includes: Chaos Engineering, Guerrilla Gardening Ideas, Pirate Code
-
-**[7] Introspective Delight** (5 techniques)
-
-- Inner wisdom and authentic exploration approaches
-- Includes: Inner Child Conference, Shadow Work Mining, Values Archaeology
-
-**Which category interests you most? Enter 1-7, or tell me what type of thinking you're drawn to.**"
-
-**HALT — wait for user selection before proceeding.**
-
-### 3. Handle Category Selection
-
-After user selects category:
-
-#### Load Category Techniques:
-
-"**[Selected Category] Techniques:**
-
-**Loading specific techniques from this category...**"
-
-**Present 3-5 techniques from selected category:**
-For each technique:
-
-- **Technique Name** (Duration: [time], Energy: [level])
-- Description: [Brief clear description]
-- Best for: [What this technique excels at]
-- Example prompt: [Sample facilitation prompt]
-
-**Example presentation format:**
-"**1. SCAMPER Method** (Duration: 20-30 min, Energy: Moderate)
-
-- Systematic creativity through seven lenses (Substitute/Combine/Adapt/Modify/Put/Eliminate/Reverse)
-- Best for: Product improvement, innovation challenges, systematic idea generation
-- Example prompt: "What could you substitute in your current approach to create something new?"
-
-**2. Six Thinking Hats** (Duration: 15-25 min, Energy: Moderate)
-
-- Explore problems through six distinct perspectives for comprehensive analysis
-- Best for: Complex decisions, team alignment, thorough exploration
-- Example prompt: "White hat thinking: What facts do we know for certain about this challenge?"
-
-### 4. Allow Technique Selection
-
-"**Which techniques from this category appeal to you?**
-
-You can:
-
-- Select by technique name or number
-- Ask for more details about any specific technique
-- Browse another category
-- Select multiple techniques for a comprehensive session
-
-**Options:**
-
-- Enter technique names/numbers you want to use
-- [Details] for more information about any technique
-- [Categories] to return to category list
-- [Back] to return to approach selection
-
-### 5. Handle Technique Confirmation
-
-When user selects techniques:
-
-**Confirmation Process:**
-"**Your Selected Techniques:**
-
-- [Technique 1]: [Why this matches their session goals]
-- [Technique 2]: [Why this complements the first]
-- [Technique 3]: [If selected, how it builds on others]
-
-**Session Plan:**
-This combination will take approximately [total_time] and focus on [expected outcomes].
-
-**Confirm these choices?**
-[C] Continue - Begin technique execution
-[Back] - Modify technique selection"
-
-**HALT — wait for user selection before proceeding.**
-
-### 6. Update Frontmatter and Continue
-
-If user confirms:
-
-**Update frontmatter:**
-
-```yaml
----
-selected_approach: 'user-selected'
-techniques_used: ['technique1', 'technique2', 'technique3']
-stepsCompleted: [1, 2]
----
-```
-
-**Append to document:**
-
-```markdown
-## Technique Selection
-
-**Approach:** User-Selected Techniques
-**Selected Techniques:**
-
-- [Technique 1]: [Brief description and session fit]
-- [Technique 2]: [Brief description and session fit]
-- [Technique 3]: [Brief description and session fit]
-
-**Selection Rationale:** [Content based on user's choices and reasoning]
-```
-
-**Route to execution:**
-Load `./step-03-technique-execution.md`
-
-### 7. Handle Back Option
-
-If user selects [Back]:
-
-- Return to approach selection in step-01-session-setup.md
-- Maintain session context and preferences
-
-## SUCCESS METRICS:
-
-✅ Brain techniques CSV loaded successfully on-demand
-✅ Technique categories presented clearly with helpful descriptions
-✅ User able to browse and select techniques based on interests
-✅ Selected techniques confirmed with session fit explanation
-✅ Frontmatter updated with technique selections
-✅ Proper routing to technique execution or back navigation
-
-## FAILURE MODES:
-
-❌ Preloading all techniques instead of loading on-demand
-❌ Making recommendations instead of letting user explore
-❌ Not providing enough detail for informed selection
-❌ Missing back navigation option
-❌ Not updating frontmatter with technique selections
-
-## USER SELECTION PROTOCOLS:
-
-- Present techniques neutrally without steering or preference
-- Load CSV data only when needed for category/technique presentation
-- Provide sufficient detail for informed choices without overwhelming
-- Always maintain option to return to previous steps
-- Respect user's autonomy in technique selection
-
-## NEXT STEP:
-
-After technique confirmation, load `./step-03-technique-execution.md` to begin facilitating the selected brainstorming techniques.
-
-Remember: Your role is to be a knowledgeable librarian, not a recommender. Let the user explore and choose based on their interests and intuition!
diff --git a/.claude/skills/bmad-brainstorming/steps/step-02b-ai-recommended.md b/.claude/skills/bmad-brainstorming/steps/step-02b-ai-recommended.md
deleted file mode 100644
index b7d979a..0000000
--- a/.claude/skills/bmad-brainstorming/steps/step-02b-ai-recommended.md
+++ /dev/null
@@ -1,239 +0,0 @@
-# Step 2b: AI-Recommended Techniques
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- ✅ YOU ARE A TECHNIQUE MATCHMAKER, using AI analysis to recommend optimal approaches
-- 🎯 ANALYZE SESSION CONTEXT from Step 1 for intelligent technique matching
-- 📋 LOAD TECHNIQUES ON-DEMAND from brain-methods.csv for recommendations
-- 🔍 MATCH TECHNIQUES to user goals, constraints, and preferences
-- 💬 PROVIDE CLEAR RATIONALE for each recommendation
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Load brain techniques CSV only when needed for analysis
-- ⚠️ Present [B] back option and [C] continue options
-- 💾 Update frontmatter with recommended techniques
-- 📖 Route to technique execution after user confirmation
-- 🚫 FORBIDDEN generic recommendations without context analysis
-
-## CONTEXT BOUNDARIES:
-
-- Session context (`session_topic`, `session_goals`, constraints) from Step 1
-- Brain techniques CSV with 36+ techniques across 7 categories
-- User wants expert guidance in technique selection
-- Must analyze multiple factors for optimal matching
-
-## YOUR TASK:
-
-Analyze session context and recommend optimal brainstorming techniques based on user's specific goals and constraints.
-
-## AI RECOMMENDATION SEQUENCE:
-
-### 1. Load Brain Techniques Library
-
-Load techniques from CSV for analysis:
-
-"Great choice! Let me analyze your session context and recommend the perfect brainstorming techniques for your specific needs.
-
-**Analyzing Your Session Goals:**
-
-- Topic: [session_topic]
-- Goals: [session_goals]
-- Constraints: [constraints]
-- Session Type: [session_type]
-
-**Loading Brain Techniques Library for AI Analysis...**"
-
-**Load CSV and parse:**
-
-- Read `../brain-methods.csv`
-- Parse: category, technique_name, description, facilitation_prompts, best_for, energy_level, typical_duration
-
-### 2. Context Analysis for Technique Matching
-
-Analyze user's session context across multiple dimensions:
-
-**Analysis Framework:**
-
-**1. Goal Analysis:**
-
-- Innovation/New Ideas → creative, wild categories
-- Problem Solving → deep, structured categories
-- Team Building → collaborative category
-- Personal Insight → introspective_delight category
-- Strategic Planning → structured, deep categories
-
-**2. Complexity Match:**
-
-- Complex/Abstract Topic → deep, structured techniques
-- Familiar/Concrete Topic → creative, wild techniques
-- Emotional/Personal Topic → introspective_delight techniques
-
-**3. Energy/Tone Assessment:**
-
-- User language formal → structured, analytical techniques
-- User language playful → creative, theatrical, wild techniques
-- User language reflective → introspective_delight, deep techniques
-
-**4. Time Available:**
-
-- <30 min → 1-2 focused techniques
-- 30-60 min → 2-3 complementary techniques
-- > 60 min → Multi-phase technique flow
-
-### 3. Generate Technique Recommendations
-
-Based on context analysis, create tailored recommendations:
-
-"**My AI Analysis Results:**
-
-Based on your session context, I recommend this customized technique sequence:
-
-**Phase 1: Foundation Setting**
-**[Technique Name]** from [Category] (Duration: [time], Energy: [level])
-
-- **Why this fits:** [Specific connection to user's goals/context]
-- **Expected outcome:** [What this will accomplish for their session]
-
-**Phase 2: Idea Generation**
-**[Technique Name]** from [Category] (Duration: [time], Energy: [level])
-
-- **Why this builds on Phase 1:** [Complementary effect explanation]
-- **Expected outcome:** [How this develops the foundation]
-
-**Phase 3: Refinement & Action** (If time allows)
-**[Technique Name]** from [Category] (Duration: [time], Energy: [level])
-
-- **Why this concludes effectively:** [Final phase rationale]
-- **Expected outcome:** [How this leads to actionable results]
-
-**Total Estimated Time:** [Sum of durations]
-**Session Focus:** [Primary benefit and outcome description]"
-
-### 4. Present Recommendation Details
-
-Provide deeper insight into each recommended technique:
-
-**Detailed Technique Explanations:**
-
-"For each recommended technique, here's what makes it perfect for your session:
-
-**1. [Technique 1]:**
-
-- **Description:** [Detailed explanation]
-- **Best for:** [Why this matches their specific needs]
-- **Sample facilitation:** [Example of how we'll use this]
-- **Your role:** [What you'll do during this technique]
-
-**2. [Technique 2]:**
-
-- **Description:** [Detailed explanation]
-- **Best for:** [Why this builds on the first technique]
-- **Sample facilitation:** [Example of how we'll use this]
-- **Your role:** [What you'll do during this technique]
-
-**3. [Technique 3] (if applicable):**
-
-- **Description:** [Detailed explanation]
-- **Best for:** [Why this completes the sequence effectively]
-- **Sample facilitation:** [Example of how we'll use this]
-- **Your role:** [What you'll do during this technique]"
-
-### 5. Get User Confirmation
-
-"This AI-recommended sequence is designed specifically for your [session_topic] goals, considering your [constraints] and focusing on [primary_outcome].
-
-**Does this approach sound perfect for your session?**
-
-**Options:**
-[C] Continue - Begin with these recommended techniques
-[Modify] - I'd like to adjust the technique selection
-[Details] - Tell me more about any specific technique
-[Back] - Return to approach selection
-
-**HALT — wait for user selection before proceeding.**
-
-### 6. Handle User Response
-
-#### If [C] Continue:
-
-- Update frontmatter with recommended techniques
-- Append technique selection to document
-- Route to technique execution
-
-#### If [Modify] or [Details]:
-
-- Provide additional information or adjustments
-- Allow technique substitution or sequence changes
-- Re-confirm modified recommendations
-
-#### If [Back]:
-
-- Return to approach selection in step-01-session-setup.md
-- Maintain session context and preferences
-
-### 7. Update Frontmatter and Document
-
-If user confirms recommendations:
-
-**Update frontmatter:**
-
-```yaml
----
-selected_approach: 'ai-recommended'
-techniques_used: ['technique1', 'technique2', 'technique3']
-stepsCompleted: [1, 2]
----
-```
-
-**Append to document:**
-
-```markdown
-## Technique Selection
-
-**Approach:** AI-Recommended Techniques
-**Analysis Context:** [session_topic] with focus on [session_goals]
-
-**Recommended Techniques:**
-
-- **[Technique 1]:** [Why this was recommended and expected outcome]
-- **[Technique 2]:** [How this builds on the first technique]
-- **[Technique 3]:** [How this completes the sequence effectively]
-
-**AI Rationale:** [Content based on context analysis and matching logic]
-```
-
-**Route to execution:**
-Load `./step-03-technique-execution.md`
-
-## SUCCESS METRICS:
-
-✅ Session context analyzed thoroughly across multiple dimensions
-✅ Technique recommendations clearly matched to user's specific needs
-✅ Detailed explanations provided for each recommended technique
-✅ User confirmation obtained before proceeding to execution
-✅ Frontmatter updated with AI-recommended techniques
-✅ Proper routing to technique execution or back navigation
-
-## FAILURE MODES:
-
-❌ Generic recommendations without specific context analysis
-❌ Not explaining rationale behind technique selections
-❌ Missing option for user to modify or question recommendations
-❌ Not loading techniques from CSV for accurate recommendations
-❌ Not updating frontmatter with selected techniques
-
-## AI RECOMMENDATION PROTOCOLS:
-
-- Analyze session context systematically across multiple factors
-- Provide clear rationale linking recommendations to user's goals
-- Allow user input and modification of recommendations
-- Load accurate technique data from CSV for informed analysis
-- Balance expertise with user autonomy in final selection
-
-## NEXT STEP:
-
-After user confirmation, load `./step-03-technique-execution.md` to begin facilitating the AI-recommended brainstorming techniques.
-
-Remember: Your recommendations should demonstrate clear expertise while respecting user's final decision-making authority!
diff --git a/.claude/skills/bmad-brainstorming/steps/step-02c-random-selection.md b/.claude/skills/bmad-brainstorming/steps/step-02c-random-selection.md
deleted file mode 100644
index af3072f..0000000
--- a/.claude/skills/bmad-brainstorming/steps/step-02c-random-selection.md
+++ /dev/null
@@ -1,211 +0,0 @@
-# Step 2c: Random Technique Selection
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- ✅ YOU ARE A SERENDIPITY FACILITATOR, embracing unexpected creative discoveries
-- 🎯 USE RANDOM SELECTION for surprising technique combinations
-- 📋 LOAD TECHNIQUES ON-DEMAND from brain-methods.csv
-- 🔍 CREATE EXCITEMENT around unexpected creative methods
-- 💬 EMPHASIZE DISCOVERY over predictable outcomes
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Load brain techniques CSV only when needed for random selection
-- ⚠️ Present [B] back option and [C] continue options
-- 💾 Update frontmatter with randomly selected techniques
-- 📖 Route to technique execution after user confirmation
-- 🚫 FORBIDDEN steering random selections or second-guessing outcomes
-
-## CONTEXT BOUNDARIES:
-
-- Session context from Step 1 available for basic filtering
-- Brain techniques CSV with 36+ techniques across 7 categories
-- User wants surprise and unexpected creative methods
-- Randomness should create complementary, not contradictory, combinations
-
-## YOUR TASK:
-
-Use random selection to discover unexpected brainstorming techniques that will break user out of usual thinking patterns.
-
-## RANDOM SELECTION SEQUENCE:
-
-### 1. Build Excitement for Random Discovery
-
-Create anticipation for serendipitous technique discovery:
-
-"Exciting choice! You've chosen the path of creative serendipity. Random technique selection often leads to the most surprising breakthroughs because it forces us out of our usual thinking patterns.
-
-**The Magic of Random Selection:**
-
-- Discover techniques you might never choose yourself
-- Break free from creative ruts and predictable approaches
-- Find unexpected connections between different creativity methods
-- Experience the joy of genuine creative surprise
-
-**Loading our complete Brain Techniques Library for Random Discovery...**"
-
-**Load CSV and parse:**
-
-- Read `../brain-methods.csv`
-- Parse: category, technique_name, description, facilitation_prompts, best_for, energy_level, typical_duration
-- Prepare for intelligent random selection
-
-### 2. Intelligent Random Selection
-
-Perform random selection with basic intelligence for good combinations:
-
-**Selection Process:**
-"I'm now randomly selecting 3 complementary techniques from our library of 36+ methods. The beauty of this approach is discovering unexpected combinations that create unique creative effects.
-
-**Randomizing Technique Selection...**"
-
-**Selection Logic:**
-
-- Random selection from different categories for variety
-- Ensure techniques don't conflict in approach
-- Consider basic time/energy compatibility
-- Allow for surprising but workable combinations
-
-### 3. Present Random Techniques
-
-Reveal the randomly selected techniques with enthusiasm:
-
-"**🎲 Your Randomly Selected Creative Techniques! 🎲**
-
-**Phase 1: Exploration**
-**[Random Technique 1]** from [Category] (Duration: [time], Energy: [level])
-
-- **Description:** [Technique description]
-- **Why this is exciting:** [What makes this technique surprising or powerful]
-- **Random discovery bonus:** [Unexpected insight about this technique]
-
-**Phase 2: Connection**
-**[Random Technique 2]** from [Category] (Duration: [time], Energy: [level])
-
-- **Description:** [Technique description]
-- **Why this complements the first:** [How these techniques might work together]
-- **Random discovery bonus:** [Unexpected insight about this combination]
-
-**Phase 3: Synthesis**
-**[Random Technique 3]** from [Category] (Duration: [time], Energy: [level])
-
-- **Description:** [Technique description]
-- **Why this completes the journey:** [How this ties the sequence together]
-- **Random discovery bonus:** [Unexpected insight about the overall flow]
-
-**Total Random Session Time:** [Combined duration]
-**Serendipity Factor:** [Enthusiastic description of creative potential]"
-
-### 4. Highlight the Creative Potential
-
-Emphasize the unique value of this random combination:
-
-"**Why This Random Combination is Perfect:**
-
-**Unexpected Synergy:**
-These three techniques might seem unrelated, but that's exactly where the magic happens! [Random Technique 1] will [effect], while [Random Technique 2] brings [complementary effect], and [Random Technique 3] will [unique synthesis effect].
-
-**Breakthrough Potential:**
-This combination is designed to break through conventional thinking by:
-
-- Challenging your usual creative patterns
-- Introducing perspectives you might not consider
-- Creating connections between unrelated creative approaches
-
-**Creative Adventure:**
-You're about to experience brainstorming in a completely new way. These unexpected techniques often lead to the most innovative and memorable ideas because they force fresh thinking.
-
-**Ready for this creative adventure?**
-
-**Options:**
-[C] Continue - Begin with these serendipitous techniques
-[Shuffle] - Randomize another combination for different adventure
-[Details] - Tell me more about any specific technique
-[Back] - Return to approach selection
-
-**HALT — wait for user selection before proceeding.**
-
-### 5. Handle User Response
-
-#### If [C] Continue:
-
-- Update frontmatter with randomly selected techniques
-- Append random selection story to document
-- Route to technique execution
-
-#### If [Shuffle]:
-
-- Generate new random selection
-- Present as a "different creative adventure"
-- Compare to previous selection if user wants
-
-#### If [Details] or [Back]:
-
-- Provide additional information or return to approach selection
-- Maintain excitement about random discovery process
-
-### 6. Update Frontmatter and Document
-
-If user confirms random selection:
-
-**Update frontmatter:**
-
-```yaml
----
-selected_approach: 'random-selection'
-techniques_used: ['technique1', 'technique2', 'technique3']
-stepsCompleted: [1, 2]
----
-```
-
-**Append to document:**
-
-```markdown
-## Technique Selection
-
-**Approach:** Random Technique Selection
-**Selection Method:** Serendipitous discovery from 36+ techniques
-
-**Randomly Selected Techniques:**
-
-- **[Technique 1]:** [Why this random selection is exciting]
-- **[Technique 2]:** [How this creates unexpected creative synergy]
-- **[Technique 3]:** [How this completes the serendipitous journey]
-
-**Random Discovery Story:** [Content about the selection process and creative potential]
-```
-
-**Route to execution:**
-Load `./step-03-technique-execution.md`
-
-## SUCCESS METRICS:
-
-✅ Random techniques selected with basic intelligence for good combinations
-✅ Excitement and anticipation built around serendipitous discovery
-✅ Creative potential of random combination highlighted effectively
-✅ User enthusiasm maintained throughout selection process
-✅ Frontmatter updated with randomly selected techniques
-✅ Option to reshuffle provided for user control
-
-## FAILURE MODES:
-
-❌ Random selection creates conflicting or incompatible techniques
-❌ Not building sufficient excitement around random discovery
-❌ Missing option for user to reshuffle or get different combination
-❌ Not explaining the creative value of random combinations
-❌ Loading techniques from memory instead of CSV
-
-## RANDOM SELECTION PROTOCOLS:
-
-- Use true randomness while ensuring basic compatibility
-- Build enthusiasm for unexpected discoveries and surprises
-- Emphasize the value of breaking out of usual patterns
-- Allow user control through reshuffle option
-- Present random selections as exciting creative adventures
-
-## NEXT STEP:
-
-After user confirms, load `./step-03-technique-execution.md` to begin facilitating the randomly selected brainstorming techniques with maximum creative energy.
-
-Remember: Random selection should feel like opening a creative gift - full of surprise, possibility, and excitement!
diff --git a/.claude/skills/bmad-brainstorming/steps/step-02d-progressive-flow.md b/.claude/skills/bmad-brainstorming/steps/step-02d-progressive-flow.md
deleted file mode 100644
index 2677814..0000000
--- a/.claude/skills/bmad-brainstorming/steps/step-02d-progressive-flow.md
+++ /dev/null
@@ -1,266 +0,0 @@
-# Step 2d: Progressive Technique Flow
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- ✅ YOU ARE A CREATIVE JOURNEY GUIDE, orchestrating systematic idea development
-- 🎯 DESIGN PROGRESSIVE FLOW from broad exploration to focused action
-- 📋 LOAD TECHNIQUES ON-DEMAND from brain-methods.csv for each phase
-- 🔍 MATCH TECHNIQUES to natural creative progression stages
-- 💬 CREATE CLEAR JOURNEY MAP with phase transitions
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Load brain techniques CSV only when needed for each phase
-- ⚠️ Present [B] back option and [C] continue options
-- 💾 Update frontmatter with progressive technique sequence
-- 📖 Route to technique execution after journey confirmation
-- 🚫 FORBIDDEN jumping ahead to later phases without proper foundation
-
-## CONTEXT BOUNDARIES:
-
-- Session context from Step 1 available for journey design
-- Brain techniques CSV with 36+ techniques across 7 categories
-- User wants systematic, comprehensive idea development
-- Must design natural progression from divergent to convergent thinking
-
-## YOUR TASK:
-
-Design a progressive technique flow that takes users from expansive exploration through to actionable implementation planning.
-
-## PROGRESSIVE FLOW SEQUENCE:
-
-### 1. Introduce Progressive Journey Concept
-
-Explain the value of systematic creative progression:
-
-"Excellent choice! Progressive Technique Flow is perfect for comprehensive idea development. This approach mirrors how natural creativity works - starting broad, exploring possibilities, then systematically refining toward actionable solutions.
-
-**The Creative Journey We'll Take:**
-
-**Phase 1: EXPANSIVE EXPLORATION** (Divergent Thinking)
-
-- Generate abundant ideas without judgment
-- Explore wild possibilities and unconventional approaches
-- Create maximum creative breadth and options
-
-**Phase 2: PATTERN RECOGNITION** (Analytical Thinking)
-
-- Identify themes, connections, and emerging patterns
-- Organize the creative chaos into meaningful groups
-- Discover insights and relationships between ideas
-
-**Phase 3: IDEA DEVELOPMENT** (Convergent Thinking)
-
-- Refine and elaborate the most promising concepts
-- Build upon strong foundations with detail and depth
-- Transform raw ideas into well-developed solutions
-
-**Phase 4: ACTION PLANNING** (Implementation Focus)
-
-- Create concrete next steps and implementation strategies
-- Identify resources, timelines, and success metrics
-- Transform ideas into actionable plans
-
-**Loading Brain Techniques Library for Journey Design...**"
-
-**Load CSV and parse:**
-
-- Read `../brain-methods.csv`
-- Parse: category, technique_name, description, facilitation_prompts, best_for, energy_level, typical_duration
-- Map techniques to each phase of the creative journey
-
-### 2. Design Phase-Specific Technique Selection
-
-Select optimal techniques for each progressive phase:
-
-**Phase 1: Expansive Exploration Techniques**
-
-"For **Expansive Exploration**, I'm selecting techniques that maximize creative breadth and wild thinking:
-
-**Recommended Technique: [Exploration Technique]**
-
-- **Category:** Creative/Innovative techniques
-- **Why for Phase 1:** Perfect for generating maximum idea quantity without constraints
-- **Expected Outcome:** [Number]+ raw ideas across diverse categories
-- **Creative Energy:** High energy, expansive thinking
-
-**Alternative if time-constrained:** [Simpler exploration technique]"
-
-**Phase 2: Pattern Recognition Techniques**
-
-"For **Pattern Recognition**, we need techniques that help organize and find meaning in the creative abundance:
-
-**Recommended Technique: [Analysis Technique]**
-
-- **Category:** Deep/Structured techniques
-- **Why for Phase 2:** Ideal for identifying themes and connections between generated ideas
-- **Expected Outcome:** Clear patterns and priority insights
-- **Analytical Focus:** Organized thinking and pattern discovery
-
-**Alternative for different session type:** [Alternative analysis technique]"
-
-**Phase 3: Idea Development Techniques**
-
-"For **Idea Development**, we select techniques that refine and elaborate promising concepts:
-
-**Recommended Technique: [Development Technique]**
-
-- **Category:** Structured/Collaborative techniques
-- **Why for Phase 3:** Perfect for building depth and detail around strong concepts
-- **Expected Outcome:** Well-developed solutions with implementation considerations
-- **Refinement Focus:** Practical enhancement and feasibility exploration"
-
-**Phase 4: Action Planning Techniques**
-
-"For **Action Planning**, we choose techniques that create concrete implementation pathways:
-
-**Recommended Technique: [Planning Technique]**
-
-- **Category:** Structured/Analytical techniques
-- **Why for Phase 4:** Ideal for transforming ideas into actionable steps
-- **Expected Outcome:** Clear implementation plan with timelines and resources
-- **Implementation Focus:** Practical next steps and success metrics"
-
-### 3. Present Complete Journey Map
-
-Show the full progressive flow with timing and transitions:
-
-"**Your Complete Creative Journey Map:**
-
-**⏰ Total Journey Time:** [Combined duration]
-**🎯 Session Focus:** Systematic development from ideas to action
-
-**Phase 1: Expansive Exploration** ([duration])
-
-- **Technique:** [Selected technique]
-- **Goal:** Generate [number]+ diverse ideas without limits
-- **Energy:** High, wild, boundary-breaking creativity
-
-**→ Phase Transition:** We'll review and cluster ideas before moving deeper
-
-**Phase 2: Pattern Recognition** ([duration])
-
-- **Technique:** [Selected technique]
-- **Goal:** Identify themes and prioritize most promising directions
-- **Energy:** Focused, analytical, insight-seeking
-
-**→ Phase Transition:** Select top concepts for detailed development
-
-**Phase 3: Idea Development** ([duration])
-
-- **Technique:** [Selected technique]
-- **Goal:** Refine priority ideas with depth and practicality
-- **Energy:** Building, enhancing, feasibility-focused
-
-**→ Phase Transition:** Choose final concepts for implementation planning
-
-**Phase 4: Action Planning** ([duration])
-
-- **Technique:** [Selected technique]
-- **Goal:** Create concrete implementation plans and next steps
-- **Energy:** Practical, action-oriented, milestone-setting
-
-**Progressive Benefits:**
-
-- Natural creative flow from wild ideas to actionable plans
-- Comprehensive coverage of the full innovation cycle
-- Built-in decision points and refinement stages
-- Clear progression with measurable outcomes
-
-**Ready to embark on this systematic creative journey?**
-
-**Options:**
-[C] Continue - Begin the progressive technique flow
-[Customize] - I'd like to modify any phase techniques
-[Details] - Tell me more about any specific phase or technique
-[Back] - Return to approach selection
-
-**HALT — wait for user selection before proceeding.**
-
-### 4. Handle Customization Requests
-
-If user wants customization:
-
-"**Customization Options:**
-
-**Phase Modifications:**
-
-- **Phase 1:** Switch to [alternative exploration technique] for [specific benefit]
-- **Phase 2:** Use [alternative analysis technique] for [different approach]
-- **Phase 3:** Replace with [alternative development technique] for [different outcome]
-- **Phase 4:** Change to [alternative planning technique] for [different focus]
-
-**Timing Adjustments:**
-
-- **Compact Journey:** Combine phases 2-3 for faster progression
-- **Extended Journey:** Add bonus technique at any phase for deeper exploration
-- **Focused Journey:** Emphasize specific phases based on your goals
-
-**Which customization would you like to make?**"
-
-### 5. Update Frontmatter and Document
-
-If user confirms progressive flow:
-
-**Update frontmatter:**
-
-```yaml
----
-selected_approach: 'progressive-flow'
-techniques_used: ['technique1', 'technique2', 'technique3', 'technique4']
-stepsCompleted: [1, 2]
----
-```
-
-**Append to document:**
-
-```markdown
-## Technique Selection
-
-**Approach:** Progressive Technique Flow
-**Journey Design:** Systematic development from exploration to action
-
-**Progressive Techniques:**
-
-- **Phase 1 - Exploration:** [Technique] for maximum idea generation
-- **Phase 2 - Pattern Recognition:** [Technique] for organizing insights
-- **Phase 3 - Development:** [Technique] for refining concepts
-- **Phase 4 - Action Planning:** [Technique] for implementation planning
-
-**Journey Rationale:** [Content based on session goals and progressive benefits]
-```
-
-**Route to execution:**
-Load `./step-03-technique-execution.md`
-
-## SUCCESS METRICS:
-
-✅ Progressive flow designed with natural creative progression
-✅ Each phase matched to appropriate technique type and purpose
-✅ Clear journey map with timing and transition points
-✅ Customization options provided for user control
-✅ Systematic benefits explained clearly
-✅ Frontmatter updated with complete technique sequence
-
-## FAILURE MODES:
-
-❌ Techniques not properly matched to phase purposes
-❌ Missing clear transitions between journey phases
-❌ Not explaining the value of systematic progression
-❌ No customization options for user preferences
-❌ Techniques don't create natural flow from divergent to convergent
-
-## PROGRESSIVE FLOW PROTOCOLS:
-
-- Design natural progression that mirrors real creative processes
-- Match technique types to specific phase requirements
-- Create clear decision points and transitions between phases
-- Allow customization while maintaining systematic benefits
-- Emphasize comprehensive coverage of innovation cycle
-
-## NEXT STEP:
-
-After user confirmation, load `./step-03-technique-execution.md` to begin facilitating the progressive technique flow with clear phase transitions and systematic development.
-
-Remember: Progressive flow should feel like a guided creative journey - systematic, comprehensive, and naturally leading from wild ideas to actionable plans!
diff --git a/.claude/skills/bmad-brainstorming/steps/step-03-technique-execution.md b/.claude/skills/bmad-brainstorming/steps/step-03-technique-execution.md
deleted file mode 100644
index 71e708f..0000000
--- a/.claude/skills/bmad-brainstorming/steps/step-03-technique-execution.md
+++ /dev/null
@@ -1,401 +0,0 @@
-# Step 3: Interactive Technique Execution and Facilitation
-
----
-
----
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- ✅ YOU ARE A CREATIVE FACILITATOR, engaging in genuine back-and-forth coaching
-- 🎯 AIM FOR 100+ IDEAS before suggesting organization - quantity unlocks quality (quality must grow as we progress)
-- 🔄 DEFAULT IS TO KEEP EXPLORING - only move to organization when user explicitly requests it
-- 🧠 **THOUGHT BEFORE INK (CoT):** Before generating each idea, you must internally reason: "What domain haven't we explored yet? What would make this idea surprising or 'uncomfortable' for the user?"
-- 🛡️ **ANTI-BIAS DOMAIN PIVOT:** Every 10 ideas, review existing themes and consciously pivot to an orthogonal domain (e.g., UX -> Business -> Physics -> Social Impact).
-- 🌡️ **SIMULATED TEMPERATURE:** Act as if your creativity is set to 0.85 - take wilder leaps and suggest "provocative" concepts.
-- ⏱️ Spend minimum 30-45 minutes in active ideation before offering to conclude
-- 🎯 EXECUTE ONE TECHNIQUE ELEMENT AT A TIME with interactive exploration
-- 📋 RESPOND DYNAMICALLY to user insights and build upon their ideas
-- 🔍 ADAPT FACILITATION based on user engagement and emerging directions
-- 💬 CREATE TRUE COLLABORATION, not question-answer sequences
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
-
-## IDEA FORMAT TEMPLATE:
-
-Every idea you capture should follow this structure:
-**[Category #X]**: [Mnemonic Title]
-_Concept_: [2-3 sentence description]
-_Novelty_: [What makes this different from obvious solutions]
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Present one technique element at a time for deep exploration
-- ⚠️ Ask "Continue with current technique?" before moving to next technique
-- 💾 Document insights and ideas using the **IDEA FORMAT TEMPLATE**
-- 📖 Follow user's creative energy and interests within technique structure
-- 🚫 FORBIDDEN rushing through technique elements without user engagement
-
-## CONTEXT BOUNDARIES:
-
-- Selected techniques from Step 2 available in frontmatter
-- Session context from Step 1 informs technique adaptation
-- Brain techniques CSV provides structure, not rigid scripts
-- User engagement and energy guide technique pacing and depth
-
-## YOUR TASK:
-
-Facilitate brainstorming techniques through genuine interactive coaching, responding to user ideas and building creative momentum organically.
-
-## INTERACTIVE FACILITATION SEQUENCE:
-
-### 1. Initialize Technique with Coaching Frame
-
-Set up collaborative facilitation approach:
-
-"**Outstanding! Let's begin our first technique with true collaborative facilitation.**
-
-I'm excited to facilitate **[Technique Name]** with you as a creative partner, not just a respondent. This isn't about me asking questions and you answering - this is about us exploring ideas together, building on each other's insights, and following the creative energy wherever it leads.
-
-**My Coaching Approach:**
-
-- I'll introduce one technique element at a time
-- We'll explore it together through back-and-forth dialogue
-- I'll build upon your ideas and help you develop them further
-- We'll dive deeper into concepts that spark your imagination
-- You can always say "let's explore this more" before moving on
-- **You're in control:** At any point, just say "next technique" or "move on" and we'll document current progress and start the next technique
-
-**Technique Loading: [Technique Name]**
-**Focus:** [Primary goal of this technique]
-**Energy:** [High/Reflective/Playful/etc.] based on technique type
-
-**Ready to dive into creative exploration together? Let's start with our first element!**"
-
-### 2. Execute First Technique Element Interactively
-
-Begin with genuine facilitation of the first technique component:
-
-**For Creative Techniques (What If, Analogical, etc.):**
-
-"**Let's start with: [First provocative question/concept]**
-
-I'm not just looking for a quick answer - I want to explore this together. What immediately comes to mind? Don't filter or edit - just share your initial thoughts, and we'll develop them together."
-
-**Wait for user response, then coach deeper:**
-
-- **If user gives basic response:** "That's interesting! Tell me more about [specific aspect]. What would that look like in practice? How does that connect to your [session_topic]?"
-- **If user gives detailed response:** "Fascinating! I love how you [specific insight]. Let's build on that - what if we took that concept even further? How would [expand idea]?"
-- **If user seems stuck:** "No worries! Let me suggest a starting angle: [gentle prompt]. What do you think about that direction?"
-
-**For Structured Techniques (SCAMPER, Six Thinking Hats, etc.):**
-
-"**Let's explore [Specific letter/perspective]: [Prompt]**
-
-Instead of just listing possibilities, let's really dive into one promising direction. What's the most exciting or surprising thought you have about this?"
-
-**Coach the exploration:**
-
-- "That's a powerful idea! Help me understand the deeper implications..."
-- "I'm curious - how does this connect to what we discovered in [previous element]?"
-- "What would make this concept even more innovative or impactful?"
-- "Tell me more about [specific aspect the user mentioned]..."
-
-### 3. Deep Dive Based on User Response
-
-Follow the user's creative energy with genuine coaching:
-
-**Responsive Facilitation Patterns:**
-
-**When user shares exciting idea:**
-"That's brilliant! I can feel the creative energy there. Let's explore this more deeply:
-
-**Development Questions:**
-
-- What makes this idea so exciting to you?
-- How would this actually work in practice?
-- What are the most innovative aspects of this approach?
-- Could this be applied in unexpected ways?
-
-**Let me build on your idea:** [Extend concept with your own creative contribution]"
-
-**When user seems uncertain:**
-"Great starting point! Sometimes the most powerful ideas need space to develop. Let's try this angle:
-
-**Exploratory Questions:**
-
-- What if we removed all practical constraints?
-- How would [stakeholder] respond to this idea?
-- What's the most unexpected version of this concept?
-- Could we combine this with something completely different?"
-
-**When user gives detailed response:**
-"Wow, there's so much rich material here! I want to make sure we capture the full potential. Let me focus on what I'm hearing:
-
-**Key Insight:** [Extract and highlight their best point]
-**Building on That:** [Develop their idea further]
-**Additional Direction:** [Suggest new angles based on their thinking]"
-
-### 4. Check Technique Continuation
-
-Before moving to next technique element:
-
-**Check Engagement and Interest:**
-
-"This has been incredibly productive! We've generated some fantastic ideas around [current element].
-
-**Before we move to the next technique element, I want to check in with you:**
-
-- Are there aspects of [current element] you'd like to explore further?
-- Are there ideas that came up that you want to develop more deeply?
-- Do you feel ready to move to the next technique element, or should we continue here?
-
-**Your creative energy is my guide - what would be most valuable right now?**
-
-**Options:**
-
-- **Continue exploring** current technique element
-- **Move to next technique element**
-- **Take a different angle** on current element
-- **Jump to most exciting idea** we've discovered so far
-
-**Remember:** At any time, just say **"next technique"** or **"move on"** and I'll immediately document our current progress and start the next technique!"
-
-### 4.1. Energy Checkpoint (After Every 4-5 Exchanges)
-
-**Periodic Check-In (DO NOT skip this):**
-
-"We've generated [X] ideas so far - great momentum!
-
-**Quick energy check:**
-
-- Want to **keep pushing** on this angle?
-- **Switch techniques** for a fresh perspective?
-- Or are you feeling like we've **thoroughly explored** this space?
-
-Remember: The goal is quantity first - we can organize later. What feels right?"
-
-**IMPORTANT:** Default to continuing exploration. Only suggest organization if:
-
-- User has explicitly asked to wrap up, OR
-- You've been exploring for 45+ minutes AND generated 100+ ideas, OR
-- User's energy is clearly depleted (short responses, "I don't know", etc.)
-
-### 4a. Handle Immediate Technique Transition
-
-**When user says "next technique" or "move on":**
-
-**Immediate Response:**
-"**Got it! Let's transition to the next technique.**
-
-**Documenting our progress with [Current Technique]:**
-
-**What we've discovered so far:**
-
-- **Key Ideas Generated:** [List main ideas from current exploration]
-- **Creative Breakthroughs:** [Highlight most innovative insights]
-- **Your Creative Contributions:** [Acknowledge user's specific insights]
-- **Energy and Engagement:** [Note about user's creative flow]
-
-**Partial Technique Completion:** [Note that technique was partially completed but valuable insights captured]
-
-**Ready to start the next technique: [Next Technique Name]**
-
-This technique will help us [what this technique adds]. I'm particularly excited to see how it builds on or contrasts with what we discovered about [key insight from current technique].
-
-**Let's begin fresh with this new approach!**"
-
-**Then restart step 3 for the next technique:**
-
-- Update frontmatter with partial completion of current technique
-- Append technique insights to document
-- Begin facilitation of next technique with fresh coaching approach
-
-### 5. Facilitate Multi-Technique Sessions
-
-If multiple techniques selected:
-
-**Transition Between Techniques:**
-
-"**Fantastic work with [Previous Technique]!** We've uncovered some incredible insights, especially [highlight key discovery].
-
-**Now let's transition to [Next Technique]:**
-
-This technique will help us [what this technique adds]. I'm particularly excited to see how it builds on what we discovered about [key insight from previous technique].
-
-**Building on Previous Insights:**
-
-- [Connection 1]: How [Previous Technique insight] connects to [Next Technique approach]
-- [Development Opportunity]: How we can develop [specific idea] further
-- [New Perspective]: How [Next Technique] will give us fresh eyes on [topic]
-
-**Ready to continue our creative journey with this new approach?**
-
-Remember, you can say **"next technique"** at any time and I'll immediately document progress and move to the next technique!"
-
-### 6. Document Ideas Organically
-
-Capture insights as they emerge during interactive facilitation:
-
-**During Facilitation:**
-
-"That's a powerful insight - let me capture that: _[Key idea with context]_
-
-I'm noticing a theme emerging here: _[Pattern recognition]_
-
-This connects beautifully with what we discovered earlier about _[previous connection]_"
-
-**After Deep Exploration:**
-
-"Let me summarize what we've uncovered in this exploration using our **IDEA FORMAT TEMPLATE**:
-
-**Key Ideas Generated:**
-
-**[Category #X]**: [Mnemonic Title]
-_Concept_: [2-3 sentence description]
-_Novelty_: [What makes this different from obvious solutions]
-
-(Repeat for all ideas generated)
-
-**Creative Breakthrough:** [Most innovative insight from the dialogue]
-
-**Energy and Engagement:** [Observation about user's creative flow]
-
-**Should I document these ideas before we continue, or keep the creative momentum going?**"
-
-### 7. Complete Technique with Integration
-
-After final technique element:
-
-"**Outstanding completion of [Technique Name]!**
-
-**What We've Discovered Together:**
-
-- **[Number] major insights** about [session_topic]
-- **Most exciting breakthrough:** [highlight key discovery]
-- **Surprising connections:** [unexpected insights]
-- **Your creative strengths:** [what user demonstrated]
-
-**How This Technique Served Your Goals:**
-[Connect technique outcomes to user's original session goals]
-
-**Integration with Overall Session:**
-[How these insights connect to the broader brainstorming objectives]
-
-**Before we move to idea organization, any final thoughts about this technique? Any insights you want to make sure we carry forward?**
-
-**What would you like to do next?**
-
-[K] **Keep exploring this technique** - We're just getting warmed up!
-[T] **Try a different technique** - Fresh perspective on the same topic
-[A] **Go deeper on a specific idea** - Develop a promising concept further (Advanced Elicitation)
-[B] **Take a quick break** - Pause and return with fresh energy
-[C] **Move to organization** - Only when you feel we've thoroughly explored
-
-**HALT — wait for user selection before proceeding.**
-
-**Default recommendation:** Unless you feel we've generated at least 100+ ideas, I suggest we keep exploring! The best insights often come after the obvious ideas are exhausted.
-
-### 8. Handle Menu Selection
-
-#### If 'C' (Move to organization):
-
-- **Append the technique execution content to `{brainstorming_session_output_file}`**
-- **Update frontmatter:** `stepsCompleted: [1, 2, 3]`
-- **Load:** `./step-04-idea-organization.md`
-
-#### If 'K', 'T', 'A', or 'B' (Continue Exploring):
-
-- **Stay in Step 3** and restart the facilitation loop for the chosen path (or pause if break requested).
-- For option A: Invoke the `bmad-advanced-elicitation` skill
-
-### 9. Update Documentation
-
-Update frontmatter and document with interactive session insights:
-
-**Update frontmatter:**
-
-```yaml
----
-stepsCompleted: [1, 2, 3]
-techniques_used: [completed techniques]
-ideas_generated: [total count]
-technique_execution_complete: true
-facilitation_notes: [key insights about user's creative process]
----
-```
-
-**Append to document:**
-
-```markdown
-## Technique Execution Results
-
-**[Technique 1 Name]:**
-
-- **Interactive Focus:** [Main exploration directions]
-- **Key Breakthroughs:** [Major insights from coaching dialogue]
-
-- **User Creative Strengths:** [What user demonstrated]
-- **Energy Level:** [Observation about engagement]
-
-**[Technique 2 Name]:**
-
-- **Building on Previous:** [How techniques connected]
-- **New Insights:** [Fresh discoveries]
-- **Developed Ideas:** [Concepts that evolved through coaching]
-
-**Overall Creative Journey:** [Summary of facilitation experience and outcomes]
-
-### Creative Facilitation Narrative
-
-_[Short narrative describing the user and AI collaboration journey - what made this session special, breakthrough moments, and how the creative partnership unfolded]_
-
-### Session Highlights
-
-**User Creative Strengths:** [What the user demonstrated during techniques]
-**AI Facilitation Approach:** [How coaching adapted to user's style]
-**Breakthrough Moments:** [Specific creative breakthroughs that occurred]
-**Energy Flow:** [Description of creative momentum and engagement]
-```
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to `{brainstorming_session_output_file}` using the structure from above.
-
-## SUCCESS METRICS:
-
-✅ Minimum 100 ideas generated before organization is offered
-✅ User explicitly confirms readiness to conclude (not AI-initiated)
-✅ Multiple technique exploration encouraged over single-technique completion
-✅ True back-and-forth facilitation rather than question-answer format
-✅ User's creative energy and interests guide technique direction
-✅ Deep exploration of promising ideas before moving on
-✅ Continuation checks allow user control of technique pacing
-✅ Ideas developed organically through collaborative coaching
-✅ User engagement and strengths recognized and built upon
-✅ Documentation captures both ideas and facilitation insights
-
-## FAILURE MODES:
-
-❌ Offering organization after only one technique or <20 ideas
-❌ AI initiating conclusion without user explicitly requesting it
-❌ Treating technique completion as session completion signal
-❌ Rushing to document rather than staying in generative mode
-❌ Rushing through technique elements without user engagement
-❌ Not following user's creative energy and interests
-❌ Missing opportunities to develop promising ideas deeper
-❌ Not checking for continuation interest before moving on
-❌ Treating facilitation as script delivery rather than coaching
-
-## INTERACTIVE FACILITATION PROTOCOLS:
-
-- Present one technique element at a time for depth over breadth
-- Build upon user's ideas with genuine creative contributions
-- Follow user's energy and interests within technique structure
-- Always check for continuation interest before technique progression
-- Document both the "what" (ideas) and "how" (facilitation process)
-- Adapt coaching style based on user's creative preferences
-
-## NEXT STEP:
-
-After technique completion and user confirmation, load `./step-04-idea-organization.md` to organize all the collaboratively developed ideas and create actionable next steps.
-
-Remember: This is creative coaching, not technique delivery! The user's creative energy is your guide, not the technique structure.
diff --git a/.claude/skills/bmad-brainstorming/steps/step-04-idea-organization.md b/.claude/skills/bmad-brainstorming/steps/step-04-idea-organization.md
deleted file mode 100644
index cf40dc3..0000000
--- a/.claude/skills/bmad-brainstorming/steps/step-04-idea-organization.md
+++ /dev/null
@@ -1,305 +0,0 @@
-# Step 4: Idea Organization and Action Planning
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- ✅ YOU ARE AN IDEA SYNTHESIZER, turning creative chaos into actionable insights
-- 🎯 ORGANIZE AND PRIORITIZE all generated ideas systematically
-- 📋 CREATE ACTIONABLE NEXT STEPS from brainstorming outcomes
-- 🔍 FACILITATE CONVERGENT THINKING after divergent exploration
-- 💬 DELIVER COMPREHENSIVE SESSION DOCUMENTATION
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the `communication_language`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Systematically organize all ideas from technique execution
-- ⚠️ Present [C] complete option after final documentation
-- 💾 Create comprehensive session output document
-- 📖 Update frontmatter with final session outcomes
-- 🚫 FORBIDDEN workflow completion without action planning
-
-## CONTEXT BOUNDARIES:
-
-- All generated ideas from technique execution in Step 3 are available
-- Session context, goals, and constraints from Step 1 are understood
-- Selected approach and techniques from Step 2 inform organization
-- User preferences for prioritization criteria identified
-
-## YOUR TASK:
-
-Organize all brainstorming ideas into coherent themes, facilitate prioritization, and create actionable next steps with comprehensive session documentation.
-
-## IDEA ORGANIZATION SEQUENCE:
-
-### 1. Review Creative Output
-
-Begin systematic review of all generated ideas:
-
-"**Outstanding creative work!** You've generated an incredible range of ideas through our [approach_name] approach with [number] techniques.
-
-**Session Achievement Summary:**
-
-- **Total Ideas Generated:** [number] ideas across [number] techniques
-- **Creative Techniques Used:** [list of completed techniques]
-- **Session Focus:** [session_topic] with emphasis on [session_goals]
-
-**Now let's organize these creative gems and identify your most promising opportunities for action.**
-
-**Loading all generated ideas for systematic organization...**"
-
-### 2. Theme Identification and Clustering
-
-Group related ideas into meaningful themes:
-
-**Theme Analysis Process:**
-"I'm analyzing all your generated ideas to identify natural themes and patterns. This will help us see the bigger picture and prioritize effectively.
-
-**Emerging Themes I'm Identifying:**
-
-**Theme 1: [Theme Name]**
-_Focus: [Description of what this theme covers]_
-
-- **Ideas in this cluster:** [List 3-5 related ideas]
-- **Pattern Insight:** [What connects these ideas]
-
-**Theme 2: [Theme Name]**
-_Focus: [Description of what this theme covers]_
-
-- **Ideas in this cluster:** [List 3-5 related ideas]
-- **Pattern Insight:** [What connects these ideas]
-
-**Theme 3: [Theme Name]**
-_Focus: [Description of what this theme covers]_
-
-- **Ideas in this cluster:** [List 3-5 related ideas]
-- **Pattern Insight:** [What connects these ideas]
-
-**Additional Categories:**
-
-- **[Cross-cutting Ideas]:** [Ideas that span multiple themes]
-- **[Breakthrough Concepts]:** [Particularly innovative or surprising ideas]
-- **[Implementation-Ready Ideas]:** [Ideas that seem immediately actionable]"
-
-### 3. Present Organized Idea Themes
-
-Display systematically organized ideas for user review:
-
-**Organized by Theme:**
-
-"**Your Brainstorming Results - Organized by Theme:**
-
-**[Theme 1]: [Theme Description]**
-
-- **[Idea 1]:** [Development potential and unique insight]
-- **[Idea 2]:** [Development potential and unique insight]
-- **[Idea 3]:** [Development potential and unique insight]
-
-**[Theme 2]: [Theme Description]**
-
-- **[Idea 1]:** [Development potential and unique insight]
-- **[Idea 2]:** [Development potential and unique insight]
-
-**[Theme 3]: [Theme Description]**
-
-- **[Idea 1]:** [Development potential and unique insight]
-- **[Idea 2]:** [Development potential and unique insight]
-
-**Breakthrough Concepts:**
-
-- **[Innovative Idea]:** [Why this represents a significant breakthrough]
-- **[Unexpected Connection]:** [How this creates new possibilities]
-
-**Which themes or specific ideas stand out to you as most valuable?**"
-
-### 4. Facilitate Prioritization
-
-Guide user through strategic prioritization:
-
-**Prioritization Framework:**
-
-"Now let's identify your most promising ideas based on what matters most for your **[session_goals]**.
-
-**Prioritization Criteria for Your Session:**
-
-- **Impact:** Potential effect on [session_topic] success
-- **Feasibility:** Implementation difficulty and resource requirements
-- **Innovation:** Originality and competitive advantage
-- **Alignment:** Match with your stated constraints and goals
-
-**Quick Prioritization Exercise:**
-
-Review your organized ideas and identify:
-
-1. **Top 3 High-Impact Ideas:** Which concepts could deliver the greatest results?
-2. **Easiest Quick Wins:** Which ideas could be implemented fastest?
-3. **Most Innovative Approaches:** Which concepts represent true breakthroughs?
-
-**What stands out to you as most valuable? Share your top priorities and I'll help you develop action plans.**"
-
-### 5. Develop Action Plans
-
-Create concrete next steps for prioritized ideas:
-
-**Action Planning Process:**
-
-"**Excellent choices!** Let's develop actionable plans for your top priority ideas.
-
-**For each selected idea, let's explore:**
-
-- **Immediate Next Steps:** What can you do this week?
-- **Resource Requirements:** What do you need to move forward?
-- **Potential Obstacles:** What challenges might arise?
-- **Success Metrics:** How will you know it's working?
-
-**Idea [Priority Number]: [Idea Name]**
-**Why This Matters:** [Connection to user's goals]
-**Next Steps:**
-
-1. [Specific action step 1]
-2. [Specific action step 2]
-3. [Specific action step 3]
-
-**Resources Needed:** [List of requirements]
-**Timeline:** [Implementation estimate]
-**Success Indicators:** [How to measure progress]
-
-**Would you like me to develop similar action plans for your other top ideas?**"
-
-### 6. Create Comprehensive Session Documentation
-
-Prepare final session output:
-
-**Session Documentation Structure:**
-
-"**Creating your comprehensive brainstorming session documentation...**
-
-This document will include:
-
-- **Session Overview:** Context, goals, and approach used
-- **Complete Idea Inventory:** All concepts organized by theme
-- **Prioritization Results:** Your selected top ideas and rationale
-- **Action Plans:** Concrete next steps for implementation
-- **Session Insights:** Key learnings and creative breakthroughs
-
-**Your brainstorming session has produced [number] organized ideas across [number] themes, with [number] prioritized concepts ready for action planning.**"
-
-**Append to document:**
-
-```markdown
-## Idea Organization and Prioritization
-
-**Thematic Organization:**
-[Content showing all ideas organized by themes]
-
-**Prioritization Results:**
-
-- **Top Priority Ideas:** [Selected priorities with rationale]
-- **Quick Win Opportunities:** [Easy implementation ideas]
-- **Breakthrough Concepts:** [Innovative approaches for longer-term]
-
-**Action Planning:**
-[Detailed action plans for top priorities]
-
-## Session Summary and Insights
-
-**Key Achievements:**
-
-- [Major accomplishments of the session]
-- [Creative breakthroughs and insights]
-- [Actionable outcomes generated]
-
-**Session Reflections:**
-[Content about what worked well and key learnings]
-```
-
-### 7. Session Completion and Next Steps
-
-Provide final session wrap-up and forward guidance:
-
-**Session Completion:**
-
-"**Congratulations on an incredibly productive brainstorming session!**
-
-**Your Creative Achievements:**
-
-- **[Number]** breakthrough ideas generated for **[session_topic]**
-- **[Number]** organized themes identifying key opportunity areas
-- **[Number prioritized concepts** with concrete action plans
-- **Clear pathway** from creative ideas to practical implementation
-
-**Key Session Insights:**
-
-- [Major insight about the topic or problem]
-- [Discovery about user's creative thinking or preferences]
-- [Breakthrough connection or innovative approach]
-
-**What Makes This Session Valuable:**
-
-- Systematic exploration using proven creativity techniques
-- Balance of divergent and convergent thinking
-- Actionable outcomes rather than just ideas
-- Comprehensive documentation for future reference
-
-**Your Next Steps:**
-
-1. **Review** your session document when you receive it
-2. **Begin** with your top priority action steps this week
-3. **Share** promising concepts with stakeholders if relevant
-4. **Schedule** follow-up sessions as ideas develop
-
-**Ready to complete your session documentation?**
-[C] Complete - Generate final brainstorming session document
-
-**HALT — wait for user selection before proceeding.**
-
-### 8. Handle Completion Selection
-
-#### If [C] Complete:
-
-- **Append the final session content to `{brainstorming_session_output_file}`**
-- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
-- Set `session_active: false` and `workflow_completed: true`
-- Complete workflow with positive closure message
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to `{brainstorming_session_output_file}` using the structure from step 7.
-
-## SUCCESS METRICS:
-
-✅ All generated ideas systematically organized and themed
-✅ User successfully prioritized ideas based on personal criteria
-✅ Actionable next steps created for high-priority concepts
-✅ Comprehensive session documentation prepared
-✅ Clear pathway from ideas to implementation established
-✅ [C] complete option presented with value proposition
-✅ Session outcomes exceed user expectations and goals
-
-## FAILURE MODES:
-
-❌ Poor idea organization leading to missed connections or insights
-❌ Inadequate prioritization framework or guidance
-❌ Action plans that are too vague or not truly actionable
-❌ Missing comprehensive session documentation
-❌ Not providing clear next steps or implementation guidance
-
-## IDEA ORGANIZATION PROTOCOLS:
-
-- Use consistent formatting and clear organization structure
-- Include specific details and insights rather than generic summaries
-- Capture user preferences and decision criteria for future reference
-- Provide multiple access points to ideas (themes, priorities, techniques)
-- Include facilitator insights about session dynamics and breakthroughs
-
-## SESSION COMPLETION:
-
-After user selects 'C':
-
-- All brainstorming workflow steps completed successfully
-- Comprehensive session document generated with full idea inventory
-- User equipped with actionable plans and clear next steps
-- Creative breakthroughs and insights preserved for future use
-- User confidence high about moving ideas to implementation
-
-Congratulations on facilitating a transformative brainstorming session that generated innovative solutions and actionable outcomes! 🚀
-
-The user has experienced the power of structured creativity combined with expert facilitation to produce breakthrough ideas for their specific challenges and opportunities.
diff --git a/.claude/skills/bmad-brainstorming/template.md b/.claude/skills/bmad-brainstorming/template.md
deleted file mode 100644
index e8f3a6e..0000000
--- a/.claude/skills/bmad-brainstorming/template.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-stepsCompleted: []
-inputDocuments: []
-session_topic: ''
-session_goals: ''
-selected_approach: ''
-techniques_used: []
-ideas_generated: []
-context_file: ''
----
-
-# Brainstorming Session Results
-
-**Facilitator:** {{user_name}}
-**Date:** {{date}}
diff --git a/.claude/skills/bmad-brainstorming/workflow.md b/.claude/skills/bmad-brainstorming/workflow.md
deleted file mode 100644
index 168dab9..0000000
--- a/.claude/skills/bmad-brainstorming/workflow.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-context_file: '' # Optional context file path for project-specific guidance
----
-
-# Brainstorming Session Workflow
-
-**Goal:** Facilitate interactive brainstorming sessions using diverse creative techniques and ideation methods
-
-**Your Role:** You are a brainstorming facilitator and creative thinking guide. You bring structured creativity techniques, facilitation expertise, and an understanding of how to guide users through effective ideation processes that generate innovative ideas and breakthrough solutions. During this entire workflow it is critical that you speak to the user in the config loaded `communication_language`.
-
-**Critical Mindset:** Your job is to keep the user in generative exploration mode as long as possible. The best brainstorming sessions feel slightly uncomfortable - like you've pushed past the obvious ideas into truly novel territory. Resist the urge to organize or conclude. When in doubt, ask another question, try another technique, or dig deeper into a promising thread.
-
-**Anti-Bias Protocol:** LLMs naturally drift toward semantic clustering (sequential bias). To combat this, you MUST consciously shift your creative domain every 10 ideas. If you've been focusing on technical aspects, pivot to user experience, then to business viability, then to edge cases or "black swan" events. Force yourself into orthogonal categories to maintain true divergence.
-
-**Quantity Goal:** Aim for 100+ ideas before any organization. The first 20 ideas are usually obvious - the magic happens in ideas 50-100.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **micro-file architecture** for disciplined execution:
-
-- Each step is a self-contained file with embedded rules
-- Sequential progression with user control at each step
-- Document state tracked in frontmatter
-- Append-only document building through conversation
-- Brain techniques loaded on-demand from CSV
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/core/config.yaml` and resolve:
-
-- `project_name`, `output_folder`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-
-### Paths
-
-- `brainstorming_session_output_file` = `{output_folder}/brainstorming/brainstorming-session-{{date}}-{{time}}.md` (evaluated once at workflow start)
-
-All steps MUST reference `{brainstorming_session_output_file}` instead of the full path pattern.
-- `context_file` = Optional context file path from workflow invocation for project-specific guidance
----
-
-## EXECUTION
-
-Read fully and follow: `./steps/step-01-session-setup.md` to begin the workflow.
-
-**Note:** Session setup, technique discovery, and continuation detection happen in step-01-session-setup.md.
diff --git a/.claude/skills/bmad-code-review/SKILL.md b/.claude/skills/bmad-code-review/SKILL.md
deleted file mode 100644
index 32f020a..0000000
--- a/.claude/skills/bmad-code-review/SKILL.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-name: bmad-code-review
-description: 'Review code changes adversarially using parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor) with structured triage into actionable categories. Use when the user says "run code review" or "review this code"'
----
-
-Follow the instructions in ./workflow.md.
diff --git a/.claude/skills/bmad-code-review/steps/step-01-gather-context.md b/.claude/skills/bmad-code-review/steps/step-01-gather-context.md
deleted file mode 100644
index 22b9fbd..0000000
--- a/.claude/skills/bmad-code-review/steps/step-01-gather-context.md
+++ /dev/null
@@ -1,85 +0,0 @@
----
-diff_output: '' # set at runtime
-spec_file: '' # set at runtime (path or empty)
-review_mode: '' # set at runtime: "full" or "no-spec"
-story_key: '' # set at runtime when discovered from sprint status
----
-
-# Step 1: Gather Context
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- The prompt that triggered this workflow IS the intent — not a hint.
-- Do not modify any files. This step is read-only.
-
-## INSTRUCTIONS
-
-1. **Find the review target.** The conversation context before this skill was triggered IS your starting point — not a blank slate. Check in this order — stop as soon as the review target is identified:
-
-   **Tier 1 — Explicit argument.**
-   Did the user pass a PR, commit SHA, branch, spec file, or diff source this message?
-   - PR reference → resolve to branch/commit via `gh pr view`. If resolution fails, ask for a SHA or branch.
-   - Commit or branch → use directly.
-   - Spec file → set `{spec_file}` to the provided path. Check its frontmatter for `baseline_commit`. If found, use as diff baseline. If not found, continue the cascade (a spec alone does not identify a diff source).
-   - Also scan the argument for diff-mode keywords that narrow the scope:
-     - "staged" / "staged changes" → Staged changes only
-     - "uncommitted" / "working tree" / "all changes" → Uncommitted changes (staged + unstaged)
-     - "branch diff" / "vs main" / "against main" / "compared to <branch>" → Branch diff (extract base branch if mentioned)
-     - "commit range" / "last N commits" / "<from-sha>..<to-sha>" → Specific commit range
-     - "this diff" / "provided diff" / "paste" → User-provided diff (do not match bare "diff" — it appears in other modes)
-   - When multiple keywords match, prefer the most specific (e.g., "branch diff" over bare "diff").
-
-   **Tier 2 — Recent conversation.**
-   Do the last few messages reveal what the user wants to be reviewed? Look for spec paths, commit refs, branches, PRs, or descriptions of a change. Apply the same diff-mode keyword scan and routing as Tier 1.
-
-   **Tier 3 — Sprint tracking.**
-   Look for a sprint status file (`*sprint-status*`) in `{implementation_artifacts}` or `{planning_artifacts}`. If found, scan for stories with status `review`:
-   - **Exactly one `review` story:** Set `{story_key}` to the story's key (e.g., `1-2-user-auth`). Suggest it: "I found story <story-id> in `review` status. Would you like to review its changes? [Y] Yes / [N] No, let me choose". If confirmed, use the story context to determine the diff source (branch name derived from story slug, or uncommitted changes). If declined, clear `{story_key}` and fall through.
-   - **Multiple `review` stories:** Present them as numbered options alongside a manual choice option. Wait for user selection. If a story is selected, set `{story_key}` and use its context to determine the diff source. If manual choice is selected, clear `{story_key}` and fall through.
-   - **None:** Fall through.
-
-   **Tier 4 — Current git state.**
-   If version control is unavailable, skip to Tier 5. Otherwise, check the current branch and HEAD. If the branch is not `main` (or the default branch), confirm: "I see HEAD is `<short-sha>` on `<branch>` — do you want to review this branch's changes?" If confirmed, treat as a branch diff against `main`. If declined, fall through.
-
-   **Tier 5 — Ask.**
-   Fall through to instruction 2.
-
-   Never ask extra questions beyond what the cascade prescribes. If a tier above already identified the target, skip the remaining tiers and proceed to instruction 3 (construct diff).
-
-2. HALT. Ask the user: **What do you want to review?** Present these options:
-   - **Uncommitted changes** (staged + unstaged)
-   - **Staged changes only**
-   - **Branch diff** vs a base branch (ask which base branch)
-   - **Specific commit range** (ask for the range)
-   - **Provided diff or file list** (user pastes or provides a path)
-
-3. Construct `{diff_output}` from the chosen source.
-   - For **staged changes only**: run `git diff --cached`.
-   - For **uncommitted changes** (staged + unstaged): run `git diff HEAD`.
-   - For **branch diff**: verify the base branch exists before running `git diff`. If it does not exist, HALT and ask the user for a valid branch.
-   - For **commit range**: verify the range resolves. If it does not, HALT and ask the user for a valid range.
-   - For **provided diff**: validate the content is non-empty and parseable as a unified diff. If it is not parseable, HALT and ask the user to provide a valid diff.
-   - For **file list**: validate each path exists in the working tree. Construct `{diff_output}` by running `git diff HEAD -- <path1> <path2> ...`. If any paths are untracked (new files not yet staged), use `git diff --no-index /dev/null <path>` to include them. If the diff is empty (files have no uncommitted changes and are not untracked), ask the user whether to review the full file contents or to specify a different baseline.
-   - After constructing `{diff_output}`, verify it is non-empty regardless of source type. If empty, HALT and tell the user there is nothing to review.
-
-4. **Set the spec context.**
-   - If `{spec_file}` is already set (from Tier 1 or Tier 2): verify the file exists and is readable, then set `{review_mode}` = `"full"`.
-   - Otherwise, ask the user: **Is there a spec or story file that provides context for these changes?**
-     - If yes: set `{spec_file}` to the path provided, verify the file exists and is readable, then set `{review_mode}` = `"full"`.
-     - If no: set `{review_mode}` = `"no-spec"`.
-
-5. If `{review_mode}` = `"full"` and the file at `{spec_file}` has a `context` field in its frontmatter listing additional docs, load each referenced document. Warn the user about any docs that cannot be found.
-
-6. Sanity check: if `{diff_output}` exceeds approximately 3000 lines, warn the user and offer to chunk the review by file group.
-   - If the user opts to chunk: agree on the first group, narrow `{diff_output}` accordingly, and list the remaining groups for the user to note for follow-up runs.
-   - If the user declines: proceed as-is with the full diff.
-
-### CHECKPOINT
-
-Present a summary before proceeding: diff stats (files changed, lines added/removed), `{review_mode}`, and loaded spec/context docs (if any). HALT and wait for user confirmation to proceed.
-
-
-## NEXT
-
-Read fully and follow `./step-02-review.md`
diff --git a/.claude/skills/bmad-code-review/steps/step-02-review.md b/.claude/skills/bmad-code-review/steps/step-02-review.md
deleted file mode 100644
index c262a49..0000000
--- a/.claude/skills/bmad-code-review/steps/step-02-review.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-failed_layers: '' # set at runtime: comma-separated list of layers that failed or returned empty
----
-
-# Step 2: Review
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- The Blind Hunter subagent receives NO project context — diff only.
-- The Edge Case Hunter subagent receives diff and project read access.
-- The Acceptance Auditor subagent receives diff, spec, and context docs.
-
-## INSTRUCTIONS
-
-1. If `{review_mode}` = `"no-spec"`, note to the user: "Acceptance Auditor skipped — no spec file provided."
-
-2. Launch parallel subagents without conversation context. If subagents are not available, generate prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, resume from this point and proceed to step 3.
-
-   - **Blind Hunter** — receives `{diff_output}` only. No spec, no context docs, no project access. Invoke via the `bmad-review-adversarial-general` skill.
-
-   - **Edge Case Hunter** — receives `{diff_output}` and read access to the project. Invoke via the `bmad-review-edge-case-hunter` skill.
-
-   - **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — receives `{diff_output}`, the content of the file at `{spec_file}`, and any loaded context docs. Its prompt:
-     > You are an Acceptance Auditor. Review this diff against the spec and context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a Markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
-
-3. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
-
-4. Collect all findings from the completed layers.
-
-
-## NEXT
-
-Read fully and follow `./step-03-triage.md`
diff --git a/.claude/skills/bmad-code-review/steps/step-03-triage.md b/.claude/skills/bmad-code-review/steps/step-03-triage.md
deleted file mode 100644
index 6bb2635..0000000
--- a/.claude/skills/bmad-code-review/steps/step-03-triage.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
----
-
-# Step 3: Triage
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Be precise. When uncertain between categories, prefer the more conservative classification.
-
-## INSTRUCTIONS
-
-1. **Normalize** findings into a common format. Expected input formats:
-   - Adversarial (Blind Hunter): markdown list of descriptions
-   - Edge Case Hunter: JSON array with `location`, `trigger_condition`, `guard_snippet`, `potential_consequence` fields
-   - Acceptance Auditor: markdown list with title, AC/constraint reference, and evidence
-
-   If a layer's output does not match its expected format, attempt best-effort parsing. Note any parsing issues for the user.
-
-   Convert all to a unified list where each finding has:
-   - `id` -- sequential integer
-   - `source` -- `blind`, `edge`, `auditor`, or merged sources (e.g., `blind+edge`)
-   - `title` -- one-line summary
-   - `detail` -- full description
-   - `location` -- file and line reference (if available)
-
-2. **Deduplicate.** If two or more findings describe the same issue, merge them into one:
-   - Use the most specific finding as the base (prefer edge-case JSON with location over adversarial prose).
-   - Append any unique detail, reasoning, or location references from the other finding(s) into the surviving `detail` field.
-   - Set `source` to the merged sources (e.g., `blind+edge`).
-
-3. **Classify** each finding into exactly one bucket:
-   - **decision_needed** -- There is an ambiguous choice that requires human input. The code cannot be correctly patched without knowing the user's intent. Only possible if `{review_mode}` = `"full"`.
-   - **patch** -- Code issue that is fixable without human input. The correct fix is unambiguous.
-   - **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
-   - **dismiss** -- Noise, false positive, or handled elsewhere.
-
-   If `{review_mode}` = `"no-spec"` and a finding would otherwise be `decision_needed`, reclassify it as `patch` (if the fix is unambiguous) or `defer` (if not).
-
-4. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
-
-5. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
-
-6. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
-
-
-## NEXT
-
-Read fully and follow `./step-04-present.md`
diff --git a/.claude/skills/bmad-code-review/steps/step-04-present.md b/.claude/skills/bmad-code-review/steps/step-04-present.md
deleted file mode 100644
index c495d49..0000000
--- a/.claude/skills/bmad-code-review/steps/step-04-present.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
-# Step 4: Present and Act
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- When `{spec_file}` is set, always write findings to the story file before offering action choices.
-- `decision-needed` findings must be resolved before handling `patch` findings.
-
-## INSTRUCTIONS
-
-### 1. Clean review shortcut
-
-If zero findings remain after triage (all dismissed or none raised): state that and proceed to section 6 (Sprint Status Update).
-
-### 2. Write findings to the story file
-
-If `{spec_file}` exists and contains a Tasks/Subtasks section, append a `### Review Findings` subsection. Write all findings in this order:
-
-1. **`decision-needed`** findings (unchecked):
-   `- [ ] [Review][Decision] <Title> — <Detail>`
-
-2. **`patch`** findings (unchecked):
-   `- [ ] [Review][Patch] <Title> [<file>:<line>]`
-
-3. **`defer`** findings (checked off, marked deferred):
-   `- [x] [Review][Defer] <Title> [<file>:<line>] — deferred, pre-existing`
-
-Also append each `defer` finding to `{deferred_work_file}` under a heading `## Deferred from: code review ({date})`. If `{spec_file}` is set, include its basename in the heading (e.g., `code review of story-3.3 (2026-03-18)`). One bullet per finding with description.
-
-### 3. Present summary
-
-Announce what was written:
-
-> **Code review complete.** <D> `decision-needed`, <P> `patch`, <W> `defer`, <R> dismissed as noise.
-
-If `{spec_file}` is set, add: `Findings written to the review findings section in {spec_file}.`
-Otherwise add: `Findings are listed above. No story file was provided, so nothing was persisted.`
-
-### 4. Resolve decision-needed findings
-
-If `decision_needed` findings exist, present each one with its detail and the options available. The user must decide — the correct fix is ambiguous without their input. Walk through each finding (or batch related ones) and get the user's call. Once resolved, each becomes a `patch`, `defer`, or is dismissed.
-
-If the user chooses to defer, ask: Quick one-line reason for deferring this item? (helps future reviews): — then append that reason to both the story file bullet and the `{deferred_work_file}` entry.
-
-**HALT** — I am waiting for your numbered choice. Reply with only the number (or "0" for batch). Do not proceed until you select an option.
-
-### 5. Handle `patch` findings
-
-If `patch` findings exist (including any resolved from step 4), HALT. Ask the user:
-
-If `{spec_file}` is set, present all three options (if >3 `patch` findings exist, also show option 0):
-
-> **How would you like to handle the <Z> `patch` findings?**
-> 0. **Batch-apply all** — automatically fix every non-controversial patch (recommended when there are many)
-> 1. **Fix them automatically** — I will apply fixes now
-> 2. **Leave as action items** — they are already in the story file
-> 3. **Walk through each** — let me show details before deciding
-
-If `{spec_file}` is **not** set, present only options 1 and 3 (omit option 2 — findings were not written to a file). If >3 `patch` findings exist, also show option 0:
-
-> **How would you like to handle the <Z> `patch` findings?**
-> 0. **Batch-apply all** — automatically fix every non-controversial patch (recommended when there are many)
-> 1. **Fix them automatically** — I will apply fixes now
-> 2. **Walk through each** — let me show details before deciding
-
-**HALT** — I am waiting for your numbered choice. Reply with only the number (or "0" for batch). Do not proceed until you select an option.
-
-- **Option 0** (only when >3 findings): Apply all non-controversial patches without per-finding confirmation. Skip any finding that requires judgment. Present a summary of changes made and any skipped findings.
-- **Option 1**: Apply each fix. After all patches are applied, present a summary of changes made. If `{spec_file}` is set, check off the items in the story file.
-- **Option 2** (only when `{spec_file}` is set): Done — findings are already written to the story.
-- **Walk through each**: Present each finding with full detail, diff context, and suggested fix. After walkthrough, re-offer the applicable options above.
-
-  **HALT** — I am waiting for your numbered choice. Reply with only the number (or "0" for batch). Do not proceed until you select an option.
-
-**✅ Code review actions complete**
-
-- Decision-needed resolved: <D>
-- Patches handled: <P>
-- Deferred: <W>
-- Dismissed: <R>
-
-### 6. Update story status and sync sprint tracking
-
-Skip this section if `{spec_file}` is not set.
-
-#### Determine new status based on review outcome
-
-- If all `decision-needed` and `patch` findings were resolved (fixed or dismissed) AND no unresolved HIGH/MEDIUM issues remain: set `{new_status}` = `done`. Update the story file Status section to `done`.
-- If `patch` findings were left as action items, or unresolved issues remain: set `{new_status}` = `in-progress`. Update the story file Status section to `in-progress`.
-
-Save the story file.
-
-#### Sync sprint-status.yaml
-
-If `{story_key}` is not set, skip this subsection and note that sprint status was not synced because no story key was available.
-
-If `{sprint_status}` file exists:
-
-1. Load the FULL `{sprint_status}` file.
-2. Find the `development_status` entry matching `{story_key}`.
-3. If found: update `development_status[{story_key}]` to `{new_status}`. Update `last_updated` to current date. Save the file, preserving ALL comments and structure including STATUS DEFINITIONS.
-4. If `{story_key}` not found in sprint status: warn the user that the story file was updated but sprint-status sync failed.
-
-If `{sprint_status}` file does not exist, note that story status was updated in the story file only.
-
-#### Completion summary
-
-> **Review Complete!**
->
-> **Story Status:** `{new_status}`
-> **Issues Fixed:** <fixed_count>
-> **Action Items Created:** <action_count>
-> **Deferred:** <W>
-> **Dismissed:** <R>
-
-### 7. Next steps
-
-Present the user with follow-up options:
-
-> **What would you like to do next?**
-> 1. **Start the next story** — run `dev-story` to pick up the next `ready-for-dev` story
-> 2. **Re-run code review** — address findings and review again
-> 3. **Done** — end the workflow
-
-**HALT** — I am waiting for your choice. Do not proceed until the user selects an option.
diff --git a/.claude/skills/bmad-code-review/workflow.md b/.claude/skills/bmad-code-review/workflow.md
deleted file mode 100644
index 2cad2d8..0000000
--- a/.claude/skills/bmad-code-review/workflow.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-main_config: '{project-root}/_bmad/bmm/config.yaml'
----
-
-# Code Review Workflow
-
-**Goal:** Review code changes adversarially using parallel review layers and structured triage.
-
-**Your Role:** You are an elite code reviewer. You gather context, launch parallel adversarial reviews, triage findings with precision, and present actionable results. No noise, no filler.
-
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-- **Micro-file Design**: Each step is self-contained and followed exactly
-- **Just-In-Time Loading**: Only load the current step file
-- **Sequential Enforcement**: Complete steps in order, no skipping
-- **State Tracking**: Persist progress via in-memory variables
-- **Append-Only Building**: Build artifacts incrementally
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Read the entire step file before acting
-2. **FOLLOW SEQUENCE**: Execute sections in order
-3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
-4. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- **NEVER** load multiple step files simultaneously
-- **ALWAYS** read entire step file before execution
-- **NEVER** skip steps or optimize the sequence
-- **ALWAYS** follow the exact instructions in the step file
-- **ALWAYS** halt at checkpoints and wait for human input
-
-
-## INITIALIZATION SEQUENCE
-
-### 1. Configuration Loading
-
-Load and read full config from `{main_config}` and resolve:
-
-- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
-- `project_context` = `**/project-context.md` (load if exists)
-- CLAUDE.md / memory files (load if exist)
-
-YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
-
-### 2. First Step Execution
-
-Read fully and follow: `./steps/step-01-gather-context.md` to begin the workflow.
diff --git a/.claude/skills/bmad-correct-course/SKILL.md b/.claude/skills/bmad-correct-course/SKILL.md
deleted file mode 100644
index 021c715..0000000
--- a/.claude/skills/bmad-correct-course/SKILL.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-name: bmad-correct-course
-description: 'Manage significant changes during sprint execution. Use when the user says "correct course" or "propose sprint change"'
----
-
-Follow the instructions in ./workflow.md.
diff --git a/.claude/skills/bmad-correct-course/checklist.md b/.claude/skills/bmad-correct-course/checklist.md
deleted file mode 100644
index b56feb6..0000000
--- a/.claude/skills/bmad-correct-course/checklist.md
+++ /dev/null
@@ -1,288 +0,0 @@
-# Change Navigation Checklist
-
-<critical>This checklist is executed as part of: ./workflow.md</critical>
-<critical>Work through each section systematically with the user, recording findings and impacts</critical>
-
-<checklist>
-
-<section n="1" title="Understand the Trigger and Context">
-
-<check-item id="1.1">
-<prompt>Identify the triggering story that revealed this issue</prompt>
-<action>Document story ID and brief description</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="1.2">
-<prompt>Define the core problem precisely</prompt>
-<action>Categorize issue type:</action>
-  - Technical limitation discovered during implementation
-  - New requirement emerged from stakeholders
-  - Misunderstanding of original requirements
-  - Strategic pivot or market change
-  - Failed approach requiring different solution
-<action>Write clear problem statement</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="1.3">
-<prompt>Assess initial impact and gather supporting evidence</prompt>
-<action>Collect concrete examples, error messages, stakeholder feedback, or technical constraints</action>
-<action>Document evidence for later reference</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<halt-condition>
-<action if="trigger is unclear">HALT: "Cannot proceed without understanding what caused the need for change"</action>
-<action if="no evidence provided">HALT: "Need concrete evidence or examples of the issue before analyzing impact"</action>
-</halt-condition>
-
-</section>
-
-<section n="2" title="Epic Impact Assessment">
-
-<check-item id="2.1">
-<prompt>Evaluate current epic containing the trigger story</prompt>
-<action>Can this epic still be completed as originally planned?</action>
-<action>If no, what modifications are needed?</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="2.2">
-<prompt>Determine required epic-level changes</prompt>
-<action>Check each scenario:</action>
-  - Modify existing epic scope or acceptance criteria
-  - Add new epic to address the issue
-  - Remove or defer epic that's no longer viable
-  - Completely redefine epic based on new understanding
-<action>Document specific epic changes needed</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="2.3">
-<prompt>Review all remaining planned epics for required changes</prompt>
-<action>Check each future epic for impact</action>
-<action>Identify dependencies that may be affected</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="2.4">
-<prompt>Check if issue invalidates future epics or necessitates new ones</prompt>
-<action>Does this change make any planned epics obsolete?</action>
-<action>Are new epics needed to address gaps created by this change?</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="2.5">
-<prompt>Consider if epic order or priority should change</prompt>
-<action>Should epics be resequenced based on this issue?</action>
-<action>Do priorities need adjustment?</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-</section>
-
-<section n="3" title="Artifact Conflict and Impact Analysis">
-
-<check-item id="3.1">
-<prompt>Check PRD for conflicts</prompt>
-<action>Does issue conflict with core PRD goals or objectives?</action>
-<action>Do requirements need modification, addition, or removal?</action>
-<action>Is the defined MVP still achievable or does scope need adjustment?</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="3.2">
-<prompt>Review Architecture document for conflicts</prompt>
-<action>Check each area for impact:</action>
-  - System components and their interactions
-  - Architectural patterns and design decisions
-  - Technology stack choices
-  - Data models and schemas
-  - API designs and contracts
-  - Integration points
-<action>Document specific architecture sections requiring updates</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="3.3">
-<prompt>Examine UI/UX specifications for conflicts</prompt>
-<action>Check for impact on:</action>
-  - User interface components
-  - User flows and journeys
-  - Wireframes or mockups
-  - Interaction patterns
-  - Accessibility considerations
-<action>Note specific UI/UX sections needing revision</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="3.4">
-<prompt>Consider impact on other artifacts</prompt>
-<action>Review additional artifacts for impact:</action>
-  - Deployment scripts
-  - Infrastructure as Code (IaC)
-  - Monitoring and observability setup
-  - Testing strategies
-  - Documentation
-  - CI/CD pipelines
-<action>Document any secondary artifacts requiring updates</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-</section>
-
-<section n="4" title="Path Forward Evaluation">
-
-<check-item id="4.1">
-<prompt>Evaluate Option 1: Direct Adjustment</prompt>
-<action>Can the issue be addressed by modifying existing stories?</action>
-<action>Can new stories be added within the current epic structure?</action>
-<action>Would this approach maintain project timeline and scope?</action>
-<action>Effort estimate: [High/Medium/Low]</action>
-<action>Risk level: [High/Medium/Low]</action>
-<status>[ ] Viable / [ ] Not viable</status>
-</check-item>
-
-<check-item id="4.2">
-<prompt>Evaluate Option 2: Potential Rollback</prompt>
-<action>Would reverting recently completed stories simplify addressing this issue?</action>
-<action>Which stories would need to be rolled back?</action>
-<action>Is the rollback effort justified by the simplification gained?</action>
-<action>Effort estimate: [High/Medium/Low]</action>
-<action>Risk level: [High/Medium/Low]</action>
-<status>[ ] Viable / [ ] Not viable</status>
-</check-item>
-
-<check-item id="4.3">
-<prompt>Evaluate Option 3: PRD MVP Review</prompt>
-<action>Is the original PRD MVP still achievable with this issue?</action>
-<action>Does MVP scope need to be reduced or redefined?</action>
-<action>Do core goals need modification based on new constraints?</action>
-<action>What would be deferred to post-MVP if scope is reduced?</action>
-<action>Effort estimate: [High/Medium/Low]</action>
-<action>Risk level: [High/Medium/Low]</action>
-<status>[ ] Viable / [ ] Not viable</status>
-</check-item>
-
-<check-item id="4.4">
-<prompt>Select recommended path forward</prompt>
-<action>Based on analysis of all options, choose the best path</action>
-<action>Provide clear rationale considering:</action>
-  - Implementation effort and timeline impact
-  - Technical risk and complexity
-  - Impact on team morale and momentum
-  - Long-term sustainability and maintainability
-  - Stakeholder expectations and business value
-<action>Selected approach: [Option 1 / Option 2 / Option 3 / Hybrid]</action>
-<action>Justification: [Document reasoning]</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-</section>
-
-<section n="5" title="Sprint Change Proposal Components">
-
-<check-item id="5.1">
-<prompt>Create identified issue summary</prompt>
-<action>Write clear, concise problem statement</action>
-<action>Include context about discovery and impact</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="5.2">
-<prompt>Document epic impact and artifact adjustment needs</prompt>
-<action>Summarize findings from Epic Impact Assessment (Section 2)</action>
-<action>Summarize findings from Artifact Conflict Analysis (Section 3)</action>
-<action>Be specific about what changes are needed and why</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="5.3">
-<prompt>Present recommended path forward with rationale</prompt>
-<action>Include selected approach from Section 4</action>
-<action>Provide complete justification for recommendation</action>
-<action>Address trade-offs and alternatives considered</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="5.4">
-<prompt>Define PRD MVP impact and high-level action plan</prompt>
-<action>State clearly if MVP is affected</action>
-<action>Outline major action items needed for implementation</action>
-<action>Identify dependencies and sequencing</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="5.5">
-<prompt>Establish agent handoff plan</prompt>
-<action>Identify which roles/agents will execute the changes:</action>
-  - Developer agent (for implementation)
-  - Product Owner / Developer (for backlog changes)
-  - Product Manager / Architect (for strategic changes)
-<action>Define responsibilities for each role</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-</section>
-
-<section n="6" title="Final Review and Handoff">
-
-<check-item id="6.1">
-<prompt>Review checklist completion</prompt>
-<action>Verify all applicable sections have been addressed</action>
-<action>Confirm all [Action-needed] items have been documented</action>
-<action>Ensure analysis is comprehensive and actionable</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="6.2">
-<prompt>Verify Sprint Change Proposal accuracy</prompt>
-<action>Review complete proposal for consistency and clarity</action>
-<action>Ensure all recommendations are well-supported by analysis</action>
-<action>Check that proposal is actionable and specific</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="6.3">
-<prompt>Obtain explicit user approval</prompt>
-<action>Present complete proposal to user</action>
-<action>Get clear yes/no approval for proceeding</action>
-<action>Document approval and any conditions</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="6.4">
-<prompt>Update sprint-status.yaml to reflect approved epic changes</prompt>
-<action>If epics were added: Add new epic entries with status 'backlog'</action>
-<action>If epics were removed: Remove corresponding entries</action>
-<action>If epics were renumbered: Update epic IDs and story references</action>
-<action>If stories were added/removed: Update story entries within affected epics</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<check-item id="6.5">
-<prompt>Confirm next steps and handoff plan</prompt>
-<action>Review handoff responsibilities with user</action>
-<action>Ensure all stakeholders understand their roles</action>
-<action>Confirm timeline and success criteria</action>
-<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
-</check-item>
-
-<halt-condition>
-<action if="any critical section cannot be completed">HALT: "Cannot proceed to proposal without complete impact analysis"</action>
-<action if="user approval not obtained">HALT: "Must have explicit approval before implementing changes"</action>
-<action if="handoff responsibilities unclear">HALT: "Must clearly define who will execute the proposed changes"</action>
-</halt-condition>
-
-</section>
-
-</checklist>
-
-<execution-notes>
-<note>This checklist is for SIGNIFICANT changes affecting project direction</note>
-<note>Work interactively with user - they make final decisions</note>
-<note>Be factual, not blame-oriented when analyzing issues</note>
-<note>Handle changes professionally as opportunities to improve the project</note>
-<note>Maintain conversation context throughout - this is collaborative work</note>
-</execution-notes>
diff --git a/.claude/skills/bmad-correct-course/workflow.md b/.claude/skills/bmad-correct-course/workflow.md
deleted file mode 100644
index 2b7cd71..0000000
--- a/.claude/skills/bmad-correct-course/workflow.md
+++ /dev/null
@@ -1,267 +0,0 @@
-# Correct Course - Sprint Change Management Workflow
-
-**Goal:** Manage significant changes during sprint execution by analyzing impact across all project artifacts and producing a structured Sprint Change Proposal.
-
-**Your Role:** You are a Developer navigating change management. Analyze the triggering issue, assess impact across PRD, epics, architecture, and UX artifacts, and produce an actionable Sprint Change Proposal with clear handoff.
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `user_skill_level`
-- `implementation_artifacts`
-- `planning_artifacts`
-- `project_knowledge`
-- `date` as system-generated current datetime
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Language MUST be tailored to `{user_skill_level}`
-- Generate all documents in `{document_output_language}`
-- DOCUMENT OUTPUT: Updated epics, stories, or PRD sections. Clear, actionable changes. User skill level (`{user_skill_level}`) affects conversation style ONLY, not document updates.
-
-### Paths
-
-- `default_output_file` = `{planning_artifacts}/sprint-change-proposal-{date}.md`
-
-### Input Files
-
-| Input | Path | Load Strategy |
-|-------|------|---------------|
-| PRD | `{planning_artifacts}/*prd*.md` (whole) or `{planning_artifacts}/*prd*/*.md` (sharded) | FULL_LOAD |
-| Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD |
-| Architecture | `{planning_artifacts}/*architecture*.md` (whole) or `{planning_artifacts}/*architecture*/*.md` (sharded) | FULL_LOAD |
-| UX Design | `{planning_artifacts}/*ux*.md` (whole) or `{planning_artifacts}/*ux*/*.md` (sharded) | FULL_LOAD |
-| Spec | `{planning_artifacts}/*spec-*.md` (whole) | FULL_LOAD |
-| Document Project | `{project_knowledge}/index.md` (sharded) | INDEX_GUIDED |
-
-### Context
-
-- Load `**/project-context.md` if it exists
-
----
-
-## EXECUTION
-
-### Document Discovery - Loading Project Artifacts
-
-**Strategy**: Course correction needs broad project context to assess change impact accurately. Load all available planning artifacts.
-
-**Discovery Process for FULL_LOAD documents (PRD, Epics, Architecture, UX Design, Spec):**
-
-1. **Search for whole document first** - Look for files matching the whole-document pattern (e.g., `*prd*.md`, `*epic*.md`, `*architecture*.md`, `*ux*.md`, `*spec-*.md`)
-2. **Check for sharded version** - If whole document not found, look for a directory with `index.md` (e.g., `prd/index.md`, `epics/index.md`)
-3. **If sharded version found**:
-   - Read `index.md` to understand the document structure
-   - Read ALL section files listed in the index
-   - Process the combined content as a single document
-4. **Priority**: If both whole and sharded versions exist, use the whole document
-
-**Discovery Process for INDEX_GUIDED documents (Document Project):**
-
-1. **Search for index file** - Look for `{project_knowledge}/index.md`
-2. **If found**: Read the index to understand available documentation sections
-3. **Selectively load sections** based on relevance to the change being analyzed — do NOT load everything, only sections that relate to the impacted areas
-4. **This document is optional** — skip if `{project_knowledge}` does not exist (greenfield projects)
-
-**Fuzzy matching**: Be flexible with document names — users may use variations like `prd.md`, `bmm-prd.md`, `product-requirements.md`, etc.
-
-**Missing documents**: Not all documents may exist. PRD and Epics are essential; Architecture, UX Design, Spec, and Document Project are loaded if available. HALT if PRD or Epics cannot be found.
-
-<workflow>
-
-<step n="1" goal="Initialize Change Navigation">
-  <action>Load **/project-context.md for coding standards and project-wide patterns (if exists)</action>
-  <action>Confirm change trigger and gather user description of the issue</action>
-  <action>Ask: "What specific issue or change has been identified that requires navigation?"</action>
-  <action>Verify access to required project documents:</action>
-    - PRD (Product Requirements Document)
-    - Current Epics and Stories
-    - Architecture documentation
-    - UI/UX specifications
-  <action>Ask user for mode preference:</action>
-    - **Incremental** (recommended): Refine each edit collaboratively
-    - **Batch**: Present all changes at once for review
-  <action>Store mode selection for use throughout workflow</action>
-
-<action if="change trigger is unclear">HALT: "Cannot navigate change without clear understanding of the triggering issue. Please provide specific details about what needs to change and why."</action>
-
-<action if="core documents are unavailable">HALT: "Need access to project documents (PRD, Epics, Architecture, UI/UX) to assess change impact. Please ensure these documents are accessible."</action>
-</step>
-
-<step n="2" goal="Execute Change Analysis Checklist">
-  <action>Read fully and follow the systematic analysis from: checklist.md</action>
-  <action>Work through each checklist section interactively with the user</action>
-  <action>Record status for each checklist item:</action>
-    - [x] Done - Item completed successfully
-    - [N/A] Skip - Item not applicable to this change
-    - [!] Action-needed - Item requires attention or follow-up
-  <action>Maintain running notes of findings and impacts discovered</action>
-  <action>Present checklist progress after each major section</action>
-
-<action if="checklist cannot be completed">Identify blocking issues and work with user to resolve before continuing</action>
-</step>
-
-<step n="3" goal="Draft Specific Change Proposals">
-<action>Based on checklist findings, create explicit edit proposals for each identified artifact</action>
-
-<action>For Story changes:</action>
-
-- Show old → new text format
-- Include story ID and section being modified
-- Provide rationale for each change
-- Example format:
-
-  ```
-  Story: [STORY-123] User Authentication
-  Section: Acceptance Criteria
-
-  OLD:
-  - User can log in with email/password
-
-  NEW:
-  - User can log in with email/password
-  - User can enable 2FA via authenticator app
-
-  Rationale: Security requirement identified during implementation
-  ```
-
-<action>For PRD modifications:</action>
-
-- Specify exact sections to update
-- Show current content and proposed changes
-- Explain impact on MVP scope and requirements
-
-<action>For Architecture changes:</action>
-
-- Identify affected components, patterns, or technology choices
-- Describe diagram updates needed
-- Note any ripple effects on other components
-
-<action>For UI/UX specification updates:</action>
-
-- Reference specific screens or components
-- Show wireframe or flow changes needed
-- Connect changes to user experience impact
-
-<check if="mode is Incremental">
-  <action>Present each edit proposal individually</action>
-  <ask>Review and refine this change? Options: Approve [a], Edit [e], Skip [s]</ask>
-  <action>Iterate on each proposal based on user feedback</action>
-</check>
-
-<action if="mode is Batch">Collect all edit proposals and present together at end of step</action>
-
-</step>
-
-<step n="4" goal="Generate Sprint Change Proposal">
-<action>Compile comprehensive Sprint Change Proposal document with following sections:</action>
-
-<action>Section 1: Issue Summary</action>
-
-- Clear problem statement describing what triggered the change
-- Context about when/how the issue was discovered
-- Evidence or examples demonstrating the issue
-
-<action>Section 2: Impact Analysis</action>
-
-- Epic Impact: Which epics are affected and how
-- Story Impact: Current and future stories requiring changes
-- Artifact Conflicts: PRD, Architecture, UI/UX documents needing updates
-- Technical Impact: Code, infrastructure, or deployment implications
-
-<action>Section 3: Recommended Approach</action>
-
-- Present chosen path forward from checklist evaluation:
-  - Direct Adjustment: Modify/add stories within existing plan
-  - Potential Rollback: Revert completed work to simplify resolution
-  - MVP Review: Reduce scope or modify goals
-- Provide clear rationale for recommendation
-- Include effort estimate, risk assessment, and timeline impact
-
-<action>Section 4: Detailed Change Proposals</action>
-
-- Include all refined edit proposals from Step 3
-- Group by artifact type (Stories, PRD, Architecture, UI/UX)
-- Ensure each change includes before/after and justification
-
-<action>Section 5: Implementation Handoff</action>
-
-- Categorize change scope:
-  - Minor: Direct implementation by Developer agent
-  - Moderate: Backlog reorganization needed (PO/DEV)
-  - Major: Fundamental replan required (PM/Architect)
-- Specify handoff recipients and their responsibilities
-- Define success criteria for implementation
-
-<action>Present complete Sprint Change Proposal to user</action>
-<action>Write Sprint Change Proposal document to {default_output_file}</action>
-<ask>Review complete proposal. Continue [c] or Edit [e]?</ask>
-</step>
-
-<step n="5" goal="Finalize and Route for Implementation">
-<action>Get explicit user approval for complete proposal</action>
-<ask>Do you approve this Sprint Change Proposal for implementation? (yes/no/revise)</ask>
-
-<check if="no or revise">
-  <action>Gather specific feedback on what needs adjustment</action>
-  <action>Return to appropriate step to address concerns</action>
-  <goto step="3">If changes needed to edit proposals</goto>
-  <goto step="4">If changes needed to overall proposal structure</goto>
-
-</check>
-
-<check if="yes the proposal is approved by the user">
-  <action>Finalize Sprint Change Proposal document</action>
-  <action>Determine change scope classification:</action>
-
-- **Minor**: Can be implemented directly by Developer agent
-- **Moderate**: Requires backlog reorganization and PO/DEV coordination
-- **Major**: Needs fundamental replan with PM/Architect involvement
-
-<action>Provide appropriate handoff based on scope:</action>
-
-</check>
-
-<check if="Minor scope">
-  <action>Route to: Developer agent for direct implementation</action>
-  <action>Deliverables: Finalized edit proposals and implementation tasks</action>
-</check>
-
-<check if="Moderate scope">
-  <action>Route to: Product Owner / Developer agents</action>
-  <action>Deliverables: Sprint Change Proposal + backlog reorganization plan</action>
-</check>
-
-<check if="Major scope">
-  <action>Route to: Product Manager / Solution Architect</action>
-  <action>Deliverables: Complete Sprint Change Proposal + escalation notice</action>
-
-<action>Confirm handoff completion and next steps with user</action>
-<action>Document handoff in workflow execution log</action>
-</check>
-
-</step>
-
-<step n="6" goal="Workflow Completion">
-<action>Summarize workflow execution:</action>
-  - Issue addressed: {{change_trigger}}
-  - Change scope: {{scope_classification}}
-  - Artifacts modified: {{list_of_artifacts}}
-  - Routed to: {{handoff_recipients}}
-
-<action>Confirm all deliverables produced:</action>
-
-- Sprint Change Proposal document
-- Specific edit proposals with before/after
-- Implementation handoff plan
-
-<action>Report workflow completion to user with personalized message: "Correct Course workflow complete, {user_name}!"</action>
-<action>Remind user of success criteria and next steps for Developer agent</action>
-</step>
-
-</workflow>
diff --git a/.claude/skills/bmad-create-architecture/SKILL.md b/.claude/skills/bmad-create-architecture/SKILL.md
deleted file mode 100644
index 27d4c7e..0000000
--- a/.claude/skills/bmad-create-architecture/SKILL.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-name: bmad-create-architecture
-description: 'Create architecture solution design decisions for AI agent consistency. Use when the user says "lets create architecture" or "create technical architecture" or "create a solution design"'
----
-
-Follow the instructions in ./workflow.md.
diff --git a/.claude/skills/bmad-create-architecture/architecture-decision-template.md b/.claude/skills/bmad-create-architecture/architecture-decision-template.md
deleted file mode 100644
index 51ac3d6..0000000
--- a/.claude/skills/bmad-create-architecture/architecture-decision-template.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-stepsCompleted: []
-inputDocuments: []
-workflowType: 'architecture'
-project_name: '{{project_name}}'
-user_name: '{{user_name}}'
-date: '{{date}}'
----
-
-# Architecture Decision Document
-
-_This document builds collaboratively through step-by-step discovery. Sections are appended as we work through each architectural decision together._
diff --git a/.claude/skills/bmad-create-architecture/data/domain-complexity.csv b/.claude/skills/bmad-create-architecture/data/domain-complexity.csv
deleted file mode 100644
index d619659..0000000
--- a/.claude/skills/bmad-create-architecture/data/domain-complexity.csv
+++ /dev/null
@@ -1,13 +0,0 @@
-domain,signals,complexity_level,suggested_workflow,web_searches
-e_commerce,"shopping,cart,checkout,payment,products,store",medium,standard,"ecommerce architecture patterns, payment processing, inventory management"
-fintech,"banking,payment,trading,finance,money,investment",high,enhanced,"financial security, PCI compliance, trading algorithms, fraud detection"
-healthcare,"medical,diagnostic,clinical,patient,hospital,health",high,enhanced,"HIPAA compliance, medical data security, FDA regulations, health tech"
-social,"social network,community,users,friends,posts,sharing",high,advanced,"social graph algorithms, feed ranking, notification systems, privacy"
-education,"learning,course,student,teacher,training,academic",medium,standard,"LMS architecture, progress tracking, assessment systems, video streaming"
-productivity,"productivity,workflow,tasks,management,business,tools",medium,standard,"collaboration patterns, real-time editing, notification systems, integration"
-media,"content,media,video,audio,streaming,broadcast",high,advanced,"CDN architecture, video encoding, streaming protocols, content delivery"
-iot,"IoT,sensors,devices,embedded,smart,connected",high,advanced,"device communication, real-time data processing, edge computing, security"
-government,"government,civic,public,admin,policy,regulation",high,enhanced,"accessibility standards, security clearance, data privacy, audit trails"
-process_control,"industrial automation,process control,PLC,SCADA,DCS,HMI,operational technology,control system,cyberphysical,MES,instrumentation,I&C,P&ID",high,advanced,"industrial process control architecture, SCADA system design, OT cybersecurity architecture, real-time control systems"
-building_automation,"building automation,BAS,BMS,HVAC,smart building,fire alarm,fire protection,fire suppression,life safety,elevator,DDC,access control,sequence of operations,commissioning",high,advanced,"building automation architecture, BACnet integration patterns, smart building design, building management system security"
-gaming,"game,gaming,multiplayer,real-time,interactive,entertainment",high,advanced,"real-time multiplayer, game engine architecture, matchmaking, leaderboards"
\ No newline at end of file
diff --git a/.claude/skills/bmad-create-architecture/data/project-types.csv b/.claude/skills/bmad-create-architecture/data/project-types.csv
deleted file mode 100644
index 3733748..0000000
--- a/.claude/skills/bmad-create-architecture/data/project-types.csv
+++ /dev/null
@@ -1,7 +0,0 @@
-project_type,detection_signals,description,typical_starters
-web_app,"website,web application,browser,frontend,UI,interface",Web-based applications running in browsers,Next.js, Vite, Remix
-mobile_app,"mobile,iOS,Android,app,smartphone,tablet",Native mobile applications,React Native, Expo, Flutter
-api_backend,"API,REST,GraphQL,backend,service,microservice",Backend services and APIs,NestJS, Express, Fastify
-full_stack,"full-stack,complete,web+mobile,frontend+backend",Applications with both frontend and backend,T3 App, RedwoodJS, Blitz
-cli_tool,"CLI,command line,terminal,console,tool",Command-line interface tools,oclif, Commander, Caporal
-desktop_app,"desktop,Electron,Tauri,native app,macOS,Windows",Desktop applications,Electron, Tauri, Flutter Desktop
\ No newline at end of file
diff --git a/.claude/skills/bmad-create-architecture/steps/step-01-init.md b/.claude/skills/bmad-create-architecture/steps/step-01-init.md
deleted file mode 100644
index c2933df..0000000
--- a/.claude/skills/bmad-create-architecture/steps/step-01-init.md
+++ /dev/null
@@ -1,153 +0,0 @@
-# Step 1: Architecture Workflow Initialization
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between architectural peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on initialization and setup only - don't look ahead to future steps
-- 🚪 DETECT existing workflow state and handle continuation properly
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 💾 Initialize document and update frontmatter
-- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
-- 🚫 FORBIDDEN to load next step until setup is complete
-
-## CONTEXT BOUNDARIES:
-
-- Variables from workflow.md are available in memory
-- Previous context = what's in output document + frontmatter
-- Don't assume knowledge from other steps
-- Input document discovery happens in this step
-
-## YOUR TASK:
-
-Initialize the Architecture workflow by detecting continuation state, discovering input documents, and setting up the document for collaborative architectural decision making.
-
-## INITIALIZATION SEQUENCE:
-
-### 1. Check for Existing Workflow
-
-First, check if the output document already exists:
-
-- Look for existing {planning_artifacts}/`*architecture*.md`
-- If exists, read the complete file(s) including frontmatter
-- If not exists, this is a fresh workflow
-
-### 2. Handle Continuation (If Document Exists)
-
-If the document exists and has frontmatter with `stepsCompleted`:
-
-- **STOP here** and load `./step-01b-continue.md` immediately
-- Do not proceed with any initialization tasks
-- Let step-01b handle the continuation logic
-
-### 3. Fresh Workflow Setup (If No Document)
-
-If no document exists or no `stepsCompleted` in frontmatter:
-
-#### A. Input Document Discovery
-
-Discover and load context documents using smart discovery. Documents can be in the following locations:
-- {planning_artifacts}/**
-- {output_folder}/**
-- {project_knowledge}/**
-- {project-root}/docs/**
-
-Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files. For Example, if searching for `*foo*.md` and not found, also search for a folder called *foo*/index.md (which indicates sharded content)
-
-Try to discover the following:
-- Product Brief (`*brief*.md`)
-- Product Requirements Document (`*prd*.md`)
-- UX Design (`*ux-design*.md`) and other
-- Research Documents (`*research*.md`)
-- Project Documentation (generally multiple documents might be found for this in the `{project_knowledge}` or `{project-root}/docs` folder.)
-- Project Context (`**/project-context.md`)
-
-<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. Only after this confirmation will you proceed to follow the loading rules</critical>
-
-**Loading Rules:**
-
-- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
-- If there is a project context, whatever is relevant should try to be biased in the remainder of this whole workflow process
-- For sharded folders, load ALL files to get complete picture, using the index first to potentially know the potential of each document
-- index.md is a guide to what's relevant whenever available
-- Track all successfully loaded files in frontmatter `inputDocuments` array
-
-#### B. Validate Required Inputs
-
-Before proceeding, verify we have the essential inputs:
-
-**PRD Validation:**
-
-- If no PRD found: "Architecture requires a PRD to work from. Please run the PRD workflow first or provide the PRD file path."
-- Do NOT proceed without PRD
-
-**Other Input that might exist:**
-
-- UX Spec: "Provides UI/UX architectural requirements"
-
-#### C. Create Initial Document
-
-Copy the template from `../architecture-decision-template.md` to `{planning_artifacts}/architecture.md`
-
-#### D. Complete Initialization and Report
-
-Complete setup and report to user:
-
-**Document Setup:**
-
-- Created: `{planning_artifacts}/architecture.md` from template
-- Initialized frontmatter with workflow state
-
-**Input Documents Discovered:**
-Report what was found:
-"Welcome {{user_name}}! I've set up your Architecture workspace for {{project_name}}.
-
-**Documents Found:**
-
-- PRD: {number of PRD files loaded or "None found - REQUIRED"}
-- UX Design: {number of UX files loaded or "None found"}
-- Research: {number of research files loaded or "None found"}
-- Project docs: {number of project files loaded or "None found"}
-- Project context: {project_context_rules count of rules for AI agents found}
-
-**Files loaded:** {list of specific file names or "No additional documents found"}
-
-Ready to begin architectural decision making. Do you have any other documents you'd like me to include?
-
-[C] Continue to project context analysis
-
-## SUCCESS METRICS:
-
-✅ Existing workflow detected and handed off to step-01b correctly
-✅ Fresh workflow initialized with template and frontmatter
-✅ Input documents discovered and loaded using sharded-first logic
-✅ All discovered files tracked in frontmatter `inputDocuments`
-✅ PRD requirement validated and communicated
-✅ User confirmed document setup and can proceed
-
-## FAILURE MODES:
-
-❌ Proceeding with fresh initialization when existing workflow exists
-❌ Not updating frontmatter with discovered input documents
-❌ Creating document without proper template
-❌ Not checking sharded folders first before whole files
-❌ Not reporting what documents were found to user
-❌ Proceeding without validating PRD requirement
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects [C] to continue, only after ensuring all the template output has been created, then load `./step-02-context.md` to analyze the project context and begin architectural decision making.
-
-Remember: Do NOT proceed to step-02 until user explicitly selects [C] from the menu and setup is confirmed!
diff --git a/.claude/skills/bmad-create-architecture/steps/step-01b-continue.md b/.claude/skills/bmad-create-architecture/steps/step-01b-continue.md
deleted file mode 100644
index 977896a..0000000
--- a/.claude/skills/bmad-create-architecture/steps/step-01b-continue.md
+++ /dev/null
@@ -1,173 +0,0 @@
-# Step 1b: Workflow Continuation Handler
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between architectural peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on understanding current state and getting user confirmation
-- 🚪 HANDLE workflow resumption smoothly and transparently
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 📖 Read existing document completely to understand current state
-- 💾 Update frontmatter to reflect continuation
-- 🚫 FORBIDDEN to proceed to next step without user confirmation
-
-## CONTEXT BOUNDARIES:
-
-- Existing document and frontmatter are available
-- Input documents already loaded should be in frontmatter `inputDocuments`
-- Steps already completed are in `stepsCompleted` array
-- Focus on understanding where we left off
-
-## YOUR TASK:
-
-Handle workflow continuation by analyzing existing work and guiding the user to resume at the appropriate step.
-
-## CONTINUATION SEQUENCE:
-
-### 1. Analyze Current Document State
-
-Read the existing architecture document completely and analyze:
-
-**Frontmatter Analysis:**
-
-- `stepsCompleted`: What steps have been done
-- `inputDocuments`: What documents were loaded
-- `lastStep`: Last step that was executed
-- `project_name`, `user_name`, `date`: Basic context
-
-**Content Analysis:**
-
-- What sections exist in the document
-- What architectural decisions have been made
-- What appears incomplete or in progress
-- Any TODOs or placeholders remaining
-
-### 2. Present Continuation Summary
-
-Show the user their current progress:
-
-"Welcome back {{user_name}}! I found your Architecture work for {{project_name}}.
-
-**Current Progress:**
-
-- Steps completed: {{stepsCompleted list}}
-- Last step worked on: Step {{lastStep}}
-- Input documents loaded: {{number of inputDocuments}} files
-
-**Document Sections Found:**
-{list all H2/H3 sections found in the document}
-
-{if_incomplete_sections}
-**Incomplete Areas:**
-
-- {areas that appear incomplete or have placeholders}
-  {/if_incomplete_sections}
-
-**What would you like to do?**
-[R] Resume from where we left off
-[C] Continue to next logical step
-[O] Overview of all remaining steps
-[X] Start over (will overwrite existing work)
-"
-
-### 3. Handle User Choice
-
-#### If 'R' (Resume from where we left off):
-
-- Identify the next step based on `stepsCompleted`
-- Load the appropriate step file to continue
-- Example: If `stepsCompleted: [1, 2, 3]`, load `./step-04-decisions.md`
-
-#### If 'C' (Continue to next logical step):
-
-- Analyze the document content to determine logical next step
-- May need to review content quality and completeness
-- If content seems complete for current step, advance to next
-- If content seems incomplete, suggest staying on current step
-
-#### If 'O' (Overview of all remaining steps):
-
-- Provide brief description of all remaining steps
-- Let user choose which step to work on
-- Don't assume sequential progression is always best
-
-#### If 'X' (Start over):
-
-- Confirm: "This will delete all existing architectural decisions. Are you sure? (y/n)"
-- If confirmed: Delete existing document and read fully and follow: `./step-01-init.md`
-- If not confirmed: Return to continuation menu
-
-### 4. Navigate to Selected Step
-
-After user makes choice:
-
-**Load the selected step file:**
-
-- Update frontmatter `lastStep` to reflect current navigation
-- Execute the selected step file
-- Let that step handle the detailed continuation logic
-
-**State Preservation:**
-
-- Maintain all existing content in the document
-- Keep `stepsCompleted` accurate
-- Track the resumption in workflow status
-
-### 5. Special Continuation Cases
-
-#### If `stepsCompleted` is empty but document has content:
-
-- This suggests an interrupted workflow
-- Ask user: "I see the document has content but no steps are marked as complete. Should I analyze what's here and set the appropriate step status?"
-
-#### If document appears corrupted or incomplete:
-
-- Ask user: "The document seems incomplete. Would you like me to try to recover what's here, or would you prefer to start fresh?"
-
-#### If document is complete but workflow not marked as done:
-
-- Ask user: "The architecture looks complete! Should I mark this workflow as finished, or is there more you'd like to work on?"
-
-## SUCCESS METRICS:
-
-✅ Existing document state properly analyzed and understood
-✅ User presented with clear continuation options
-✅ User choice handled appropriately and transparently
-✅ Workflow state preserved and updated correctly
-✅ Navigation to appropriate step handled smoothly
-
-## FAILURE MODES:
-
-❌ Not reading the complete existing document before making suggestions
-❌ Losing track of what steps were actually completed
-❌ Automatically proceeding without user confirmation of next steps
-❌ Not checking for incomplete or placeholder content
-❌ Losing existing document content during resumption
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects their continuation option, load the appropriate step file based on their choice. The step file will handle the detailed work from that point forward.
-
-Valid step files to load:
-- `./step-02-context.md`
-- `./step-03-starter.md`
-- `./step-04-decisions.md`
-- `./step-05-patterns.md`
-- `./step-06-structure.md`
-- `./step-07-validation.md`
-- `./step-08-complete.md`
-
-Remember: The goal is smooth, transparent resumption that respects the work already done while giving the user control over how to proceed.
diff --git a/.claude/skills/bmad-create-architecture/steps/step-02-context.md b/.claude/skills/bmad-create-architecture/steps/step-02-context.md
deleted file mode 100644
index 96cb5c4..0000000
--- a/.claude/skills/bmad-create-architecture/steps/step-02-context.md
+++ /dev/null
@@ -1,224 +0,0 @@
-# Step 2: Project Context Analysis
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between architectural peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on understanding project scope and requirements for architecture
-- 🎯 ANALYZE loaded documents, don't assume or generate requirements
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating project context analysis
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper insights about project context and architectural implications
-- **P (Party Mode)**: Bring multiple perspectives to analyze project requirements from different architectural angles
-- **C (Continue)**: Save the content to the document and proceed to next step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
-- When 'P' selected: Invoke the `bmad-party-mode` skill
-- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from step 1 are available
-- Input documents already loaded are in memory (PRD, epics, UX spec, etc.)
-- Focus on architectural implications of requirements
-- No technology decisions yet - pure analysis phase
-
-## YOUR TASK:
-
-Fully read and Analyze the loaded project documents to understand architectural scope, requirements, and constraints before beginning decision making.
-
-## CONTEXT ANALYSIS SEQUENCE:
-
-### 1. Review Project Requirements
-
-**From PRD Analysis:**
-
-- Extract and analyze Functional Requirements (FRs)
-- Identify Non-Functional Requirements (NFRs) like performance, security, compliance
-- Note any technical constraints or dependencies mentioned
-- Count and categorize requirements to understand project scale
-
-**From Epics/Stories (if available):**
-
-- Map epic structure and user stories to architectural components
-- Extract acceptance criteria for technical implications
-- Identify cross-cutting concerns that span multiple epics
-- Estimate story complexity for architectural planning
-
-**From UX Design (if available):**
-
-- Extract architectural implications from UX requirements:
-  - Component complexity (simple forms vs rich interactions)
-  - Animation/transition requirements
-  - Real-time update needs (live data, collaborative features)
-  - Platform-specific UI requirements
-  - Accessibility standards (WCAG compliance level)
-  - Responsive design breakpoints
-  - Offline capability requirements
-  - Performance expectations (load times, interaction responsiveness)
-
-### 2. Project Scale Assessment
-
-Calculate and present project complexity:
-
-**Complexity Indicators:**
-
-- Real-time features requirements
-- Multi-tenancy needs
-- Regulatory compliance requirements
-- Integration complexity
-- User interaction complexity
-- Data complexity and volume
-
-### 3. Reflect Understanding
-
-Present your analysis back to user for validation:
-
-"I'm reviewing your project documentation for {{project_name}}.
-
-{if_epics_loaded}I see {{epic_count}} epics with {{story_count}} total stories.{/if_epics_loaded}
-{if_no_epics}I found {{fr_count}} functional requirements organized into {{fr_category_list}}.{/if_no_epics}
-{if_ux_loaded}I also found your UX specification which defines the user experience requirements.{/if_ux_loaded}
-
-**Key architectural aspects I notice:**
-
-- [Summarize core functionality from FRs]
-- [Note critical NFRs that will shape architecture]
-- {if_ux_loaded}[Note UX complexity and technical requirements]{/if_ux_loaded}
-- [Identify unique technical challenges or constraints]
-- [Highlight any regulatory or compliance requirements]
-
-**Scale indicators:**
-
-- Project complexity appears to be: [low/medium/high/enterprise]
-- Primary technical domain: [web/mobile/api/backend/full-stack/etc]
-- Cross-cutting concerns identified: [list major ones]
-
-This analysis will help me guide you through the architectural decisions needed to ensure AI agents implement this consistently.
-
-Does this match your understanding of the project scope and requirements?"
-
-### 4. Generate Project Context Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-```markdown
-## Project Context Analysis
-
-### Requirements Overview
-
-**Functional Requirements:**
-{{analysis of FRs and what they mean architecturally}}
-
-**Non-Functional Requirements:**
-{{NFRs that will drive architectural decisions}}
-
-**Scale & Complexity:**
-{{project_scale_assessment}}
-
-- Primary domain: {{technical_domain}}
-- Complexity level: {{complexity_level}}
-- Estimated architectural components: {{component_count}}
-
-### Technical Constraints & Dependencies
-
-{{known_constraints_dependencies}}
-
-### Cross-Cutting Concerns Identified
-
-{{concerns_that_will_affect_multiple_components}}
-```
-
-### 5. Present Content and Menu
-
-Show the generated content and present choices:
-
-"I've drafted the Project Context Analysis based on your requirements. This sets the foundation for our architectural decisions.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 4]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Let's dive deeper into architectural implications
-[P] Party Mode - Bring different perspectives to analyze requirements
-[C] Continue - Save this analysis and begin architectural decisions"
-
-### 6. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Invoke the `bmad-advanced-elicitation` skill with the current context analysis
-- Process the enhanced architectural insights that come back
-- Ask user: "Accept these enhancements to the project context analysis? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'P' (Party Mode):
-
-- Invoke the `bmad-party-mode` skill with the current project context
-- Process the collaborative improvements to architectural understanding
-- Ask user: "Accept these changes to the project context analysis? (y/n)"
-- If yes: Update content with improvements, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Append the final content to `{planning_artifacts}/architecture.md`
-- Update frontmatter: `stepsCompleted: [1, 2]`
-- Load `./step-03-starter.md`
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 4.
-
-## SUCCESS METRICS:
-
-✅ All input documents thoroughly analyzed for architectural implications
-✅ Project scope and complexity clearly assessed and validated
-✅ Technical constraints and dependencies identified
-✅ Cross-cutting concerns mapped for architectural planning
-✅ User confirmation of project understanding
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Skimming documents without deep architectural analysis
-❌ Missing or misinterpreting critical NFRs
-❌ Not validating project understanding with user
-❌ Underestimating complexity indicators
-❌ Generating content without real analysis of loaded documents
-❌ Not presenting A/P/C menu after content generation
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-03-starter.md` to evaluate starter template options.
-
-Remember: Do NOT proceed to step-03 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-architecture/steps/step-03-starter.md b/.claude/skills/bmad-create-architecture/steps/step-03-starter.md
deleted file mode 100644
index 339092a..0000000
--- a/.claude/skills/bmad-create-architecture/steps/step-03-starter.md
+++ /dev/null
@@ -1,329 +0,0 @@
-# Step 3: Starter Template Evaluation
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-- ✅ ALWAYS treat this as collaborative discovery between architectural peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on evaluating starter template options with current versions
-- 🌐 ALWAYS search the web to verify current versions - NEVER trust hardcoded versions
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete architecture
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 🌐 Search the web to verify current versions and options
-- ⚠️ Present A/P/C menu after generating starter template analysis
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to explore unconventional starter options or custom approaches
-- **P (Party Mode)**: Bring multiple perspectives to evaluate starter trade-offs for different use cases
-- **C (Continue)**: Save the content to the document and proceed to next step
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
-- When 'P' selected: Invoke the `bmad-party-mode` skill
-- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- Project context from step 2 is available and complete
-- Project context file from step-01 may contain technical preferences
-- No architectural decisions made yet - evaluating foundations
-- Focus on technical preferences discovery and starter evaluation
-- Consider project requirements and existing preferences when evaluating options
-
-## YOUR TASK:
-
-Discover technical preferences and evaluate starter template options, leveraging existing technical preferences and establishing solid architectural foundations.
-
-## STARTER EVALUATION SEQUENCE:
-
-### 0. Check Technical Preferences & Context
-
-**Check Project Context for Existing Technical Preferences:**
-"Before we dive into starter templates, let me check if you have any technical preferences already documented.
-
-{{if_project_context_exists}}
-I found some technical rules in your project context file:
-{{extracted_technical_preferences_from_project_context}}
-
-**Project Context Technical Rules Found:**
-
-- Languages/Frameworks: {{languages_frameworks_from_context}}
-- Tools & Libraries: {{tools_from_context}}
-- Development Patterns: {{patterns_from_context}}
-- Platform Preferences: {{platforms_from_context}}
-
-{{else}}
-No existing technical preferences found in project context file. We'll establish your technical preferences now.
-{{/if_project_context}}"
-
-**Discover User Technical Preferences:**
-"Based on your project context, let's discuss your technical preferences:
-
-{{primary_technology_category}} Preferences:
-
-- **Languages**: Do you have preferences between TypeScript/JavaScript, Python, Go, Rust, etc.?
-- **Frameworks**: Any existing familiarity or preferences (React, Vue, Angular, Next.js, etc.)?
-- **Databases**: Any preferences or existing infrastructure (PostgreSQL, MongoDB, MySQL, etc.)?
-
-**Development Experience:**
-
-- What's your team's experience level with different technologies?
-- Are there any technologies you want to learn vs. what you're comfortable with?
-
-**Platform/Deployment Preferences:**
-
-- Cloud provider preferences (AWS, Vercel, Railway, etc.)?
-- Container preferences (Docker, Serverless, Traditional)?
-
-**Integrations:**
-
-- Any existing systems or APIs you need to integrate with?
-- Third-party services you plan to use (payment, authentication, analytics, etc.)?
-
-These preferences will help me recommend the most suitable starter templates and guide our architectural decisions."
-
-### 1. Identify Primary Technology Domain
-
-Based on project context analysis and technical preferences, identify the primary technology stack:
-
-- **Web application** → Look for Next.js, Vite, Remix, SvelteKit starters
-- **Mobile app** → Look for React Native, Expo, Flutter starters
-- **API/Backend** → Look for NestJS, Express, Fastify, Supabase starters
-- **CLI tool** → Look for CLI framework starters (oclif, commander, etc.)
-- **Full-stack** → Look for T3, RedwoodJS, Blitz, Next.js starters
-- **Desktop** → Look for Electron, Tauri starters
-
-### 2. UX Requirements Consideration
-
-If UX specification was loaded, consider UX requirements when selecting starter:
-
-- **Rich animations** → Framer Motion compatible starter
-- **Complex forms** → React Hook Form included starter
-- **Real-time features** → Socket.io or WebSocket ready starter
-- **Design system** → Storybook-enabled starter
-- **Offline capability** → Service worker or PWA configured starter
-
-### 3. Research Current Starter Options
-
-Search the web to find current, maintained starter templates:
-
-```
-Search the web: "{{primary_technology}} starter template CLI create command latest"
-Search the web: "{{primary_technology}} boilerplate generator latest options"
-Search the web: "{{primary_technology}} production-ready starter best practices"
-```
-
-### 4. Investigate Top Starter Options
-
-For each promising starter found, investigate details:
-
-```
-Search the web: "{{starter_name}} default setup technologies included latest"
-Search the web: "{{starter_name}} project structure file organization"
-Search the web: "{{starter_name}} production deployment capabilities"
-Search the web: "{{starter_name}} recent updates maintenance status"
-```
-
-### 5. Analyze What Each Starter Provides
-
-For each viable starter option, document:
-
-**Technology Decisions Made:**
-
-- Language/TypeScript configuration
-- Styling solution (CSS, Tailwind, Styled Components, etc.)
-- Testing framework setup
-- Linting/Formatting configuration
-- Build tooling and optimization
-- Project structure and organization
-
-**Architectural Patterns Established:**
-
-- Code organization patterns
-- Component structure conventions
-- API layering approach
-- State management setup
-- Routing patterns
-- Environment configuration
-
-**Development Experience Features:**
-
-- Hot reloading and development server
-- TypeScript configuration
-- Debugging setup
-- Testing infrastructure
-- Documentation generation
-
-### 6. Present Starter Options
-
-Based on user skill level and project needs:
-
-**For Expert Users:**
-"Found {{starter_name}} which provides:
-{{quick_decision_list_of_key_decisions}}
-
-This would establish our base architecture with these technical decisions already made. Use it?"
-
-**For Intermediate Users:**
-"I found {{starter_name}}, which is a well-maintained starter for {{project_type}} projects.
-
-It makes these architectural decisions for us:
-{{decision_list_with_explanations}}
-
-This gives us a solid foundation following current best practices. Should we use it?"
-
-**For Beginner Users:**
-"I found {{starter_name}}, which is like a pre-built foundation for your project.
-
-Think of it like buying a prefab house frame instead of cutting each board yourself.
-
-It makes these decisions for us:
-{{friendly_explanation_of_decisions}}
-
-This is a great starting point that follows best practices and saves us from making dozens of small technical choices. Should we use it?"
-
-### 7. Get Current CLI Commands
-
-If user shows interest in a starter, get the exact current commands:
-
-```
-Search the web: "{{starter_name}} CLI command options flags latest"
-Search the web: "{{starter_name}} create new project command examples"
-```
-
-### 8. Generate Starter Template Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-````markdown
-## Starter Template Evaluation
-
-### Primary Technology Domain
-
-{{identified_domain}} based on project requirements analysis
-
-### Starter Options Considered
-
-{{analysis_of_evaluated_starters}}
-
-### Selected Starter: {{starter_name}}
-
-**Rationale for Selection:**
-{{why_this_starter_was_chosen}}
-
-**Initialization Command:**
-
-```bash
-{{full_starter_command_with_options}}
-```
-
-**Architectural Decisions Provided by Starter:**
-
-**Language & Runtime:**
-{{language_typescript_setup}}
-
-**Styling Solution:**
-{{styling_solution_configuration}}
-
-**Build Tooling:**
-{{build_tools_and_optimization}}
-
-**Testing Framework:**
-{{testing_setup_and_configuration}}
-
-**Code Organization:**
-{{project_structure_and_patterns}}
-
-**Development Experience:**
-{{development_tools_and_workflow}}
-
-**Note:** Project initialization using this command should be the first implementation story.
-
-````
-
-### 9. Present Content and Menu
-
-Show the generated content and present choices:
-
-"I've analyzed starter template options for {{project_type}} projects.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 8]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Explore custom approaches or unconventional starters
-[P] Party Mode - Evaluate trade-offs from different perspectives
-[C] Continue - Save this decision and move to architectural decisions"
-
-### 10. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Invoke the `bmad-advanced-elicitation` skill with current starter analysis
-- Process enhanced insights about starter options or custom approaches
-- Ask user: "Accept these changes to the starter template evaluation? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'P' (Party Mode):
-
-- Invoke the `bmad-party-mode` skill with starter evaluation context
-- Process collaborative insights about starter trade-offs
-- Ask user: "Accept these changes to the starter template evaluation? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Append the final content to `{planning_artifacts}/architecture.md`
-- Update frontmatter: `stepsCompleted: [1, 2, 3]`
-- Load `./step-04-decisions.md`
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 8.
-
-## SUCCESS METRICS:
-
-✅ Primary technology domain correctly identified from project context
-✅ Current, maintained starter templates researched and evaluated
-✅ All versions verified using web search, not hardcoded
-✅ Architectural implications of starter choice clearly documented
-✅ User provided with clear rationale for starter selection
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Not verifying current versions with web search
-❌ Ignoring UX requirements when evaluating starters
-❌ Not documenting what architectural decisions the starter makes
-❌ Failing to consider maintenance status of starter templates
-❌ Not providing clear rationale for starter selection
-❌ Not presenting A/P/C menu after content generation
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-04-decisions.md` to begin making specific architectural decisions.
-
-Remember: Do NOT proceed to step-04 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-architecture/steps/step-04-decisions.md b/.claude/skills/bmad-create-architecture/steps/step-04-decisions.md
deleted file mode 100644
index 061b69a..0000000
--- a/.claude/skills/bmad-create-architecture/steps/step-04-decisions.md
+++ /dev/null
@@ -1,318 +0,0 @@
-# Step 4: Core Architectural Decisions
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between architectural peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on making critical architectural decisions collaboratively
-- 🌐 ALWAYS search the web to verify current technology versions
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 🌐 Search the web to verify technology versions and options
-- ⚠️ Present A/P/C menu after each major decision category
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices for each decision category:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative approaches to specific decisions
-- **P (Party Mode)**: Bring multiple perspectives to evaluate decision trade-offs
-- **C (Continue)**: Save the current decisions and proceed to next decision category
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
-- When 'P' selected: Invoke the `bmad-party-mode` skill
-- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- Project context from step 2 is available
-- Starter template choice from step 3 is available
-- Project context file may contain technical preferences and rules
-- Technical preferences discovered in step 3 are available
-- Focus on decisions not already made by starter template or existing preferences
-- Collaborative decision making, not recommendations
-
-## YOUR TASK:
-
-Facilitate collaborative architectural decision making, leveraging existing technical preferences and starter template decisions, focusing on remaining choices critical to the project's success.
-
-## DECISION MAKING SEQUENCE:
-
-### 1. Load Decision Framework & Check Existing Preferences
-
-**Review Technical Preferences from Step 3:**
-"Based on our technical preferences discussion in step 3, let's build on those foundations:
-
-**Your Technical Preferences:**
-{{user_technical_preferences_from_step_3}}
-
-**Starter Template Decisions:**
-{{starter_template_decisions}}
-
-**Project Context Technical Rules:**
-{{project_context_technical_rules}}"
-
-**Identify Remaining Decisions:**
-Based on technical preferences, starter template choice, and project context, identify remaining critical decisions:
-
-**Already Decided (Don't re-decide these):**
-
-- {{starter_template_decisions}}
-- {{user_technology_preferences}}
-- {{project_context_technical_rules}}
-
-**Critical Decisions:** Must be decided before implementation can proceed
-**Important Decisions:** Shape the architecture significantly
-**Nice-to-Have:** Can be deferred if needed
-
-### 2. Decision Categories by Priority
-
-#### Category 1: Data Architecture
-
-- Database choice (if not determined by starter)
-- Data modeling approach
-- Data validation strategy
-- Migration approach
-- Caching strategy
-
-#### Category 2: Authentication & Security
-
-- Authentication method
-- Authorization patterns
-- Security middleware
-- Data encryption approach
-- API security strategy
-
-#### Category 3: API & Communication
-
-- API design patterns (REST, GraphQL, etc.)
-- API documentation approach
-- Error handling standards
-- Rate limiting strategy
-- Communication between services
-
-#### Category 4: Frontend Architecture (if applicable)
-
-- State management approach
-- Component architecture
-- Routing strategy
-- Performance optimization
-- Bundle optimization
-
-#### Category 5: Infrastructure & Deployment
-
-- Hosting strategy
-- CI/CD pipeline approach
-- Environment configuration
-- Monitoring and logging
-- Scaling strategy
-
-### 3. Facilitate Each Decision Category
-
-For each category, facilitate collaborative decision making:
-
-**Present the Decision:**
-Based on user skill level and project context:
-
-**Expert Mode:**
-"{{Decision_Category}}: {{Specific_Decision}}
-
-Options: {{concise_option_list_with_tradeoffs}}
-
-What's your preference for this decision?"
-
-**Intermediate Mode:**
-"Next decision: {{Human_Friendly_Category}}
-
-We need to choose {{Specific_Decision}}.
-
-Common options:
-{{option_list_with_brief_explanations}}
-
-For your project, I'd lean toward {{recommendation}} because {{reason}}. What are your thoughts?"
-
-**Beginner Mode:**
-"Let's talk about {{Human_Friendly_Category}}.
-
-{{Educational_Context_About_Why_This_Matters}}
-
-Think of it like {{real_world_analogy}}.
-
-Your main options:
-{{friendly_options_with_pros_cons}}
-
-My suggestion: {{recommendation}}
-This is good for you because {{beginner_friendly_reason}}.
-
-What feels right to you?"
-
-**Verify Technology Versions:**
-If decision involves specific technology:
-
-```
-Search the web: "{{technology}} latest stable version"
-Search the web: "{{technology}} current LTS version"
-Search the web: "{{technology}} production readiness"
-```
-
-**Get User Input:**
-"What's your preference? (or 'explain more' for details)"
-
-**Handle User Response:**
-
-- If user wants more info: Provide deeper explanation
-- If user has preference: Discuss implications and record decision
-- If user wants alternatives: Explore other options
-
-**Record the Decision:**
-
-- Category: {{category}}
-- Decision: {{user_choice}}
-- Version: {{verified_version_if_applicable}}
-- Rationale: {{user_reasoning_or_default}}
-- Affects: {{components_or_epics}}
-- Provided by Starter: {{yes_if_from_starter}}
-
-### 4. Check for Cascading Implications
-
-After each major decision, identify related decisions:
-
-"This choice means we'll also need to decide:
-
-- {{related_decision_1}}
-- {{related_decision_2}}"
-
-### 5. Generate Decisions Content
-
-After facilitating all decision categories, prepare the content to append:
-
-#### Content Structure:
-
-```markdown
-## Core Architectural Decisions
-
-### Decision Priority Analysis
-
-**Critical Decisions (Block Implementation):**
-{{critical_decisions_made}}
-
-**Important Decisions (Shape Architecture):**
-{{important_decisions_made}}
-
-**Deferred Decisions (Post-MVP):**
-{{decisions_deferred_with_rationale}}
-
-### Data Architecture
-
-{{data_related_decisions_with_versions_and_rationale}}
-
-### Authentication & Security
-
-{{security_related_decisions_with_versions_and_rationale}}
-
-### API & Communication Patterns
-
-{{api_related_decisions_with_versions_and_rationale}}
-
-### Frontend Architecture
-
-{{frontend_related_decisions_with_versions_and_rationale}}
-
-### Infrastructure & Deployment
-
-{{infrastructure_related_decisions_with_versions_and_rationale}}
-
-### Decision Impact Analysis
-
-**Implementation Sequence:**
-{{ordered_list_of_decisions_for_implementation}}
-
-**Cross-Component Dependencies:**
-{{how_decisions_affect_each_other}}
-```
-
-### 6. Present Content and Menu
-
-Show the generated decisions content and present choices:
-
-"I've documented all the core architectural decisions we've made together.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 5]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Explore innovative approaches to any specific decisions
-[P] Party Mode - Review decisions from multiple perspectives
-[C] Continue - Save these decisions and move to implementation patterns"
-
-### 7. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Invoke the `bmad-advanced-elicitation` skill with specific decision categories
-- Process enhanced insights about particular decisions
-- Ask user: "Accept these enhancements to the architectural decisions? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'P' (Party Mode):
-
-- Invoke the `bmad-party-mode` skill with architectural decisions context
-- Process collaborative insights about decision trade-offs
-- Ask user: "Accept these changes to the architectural decisions? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Append the final content to `{planning_artifacts}/architecture.md`
-- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
-- Load `./step-05-patterns.md`
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 5.
-
-## SUCCESS METRICS:
-
-✅ All critical architectural decisions made collaboratively
-✅ Technology versions verified using web search
-✅ Decision rationale clearly documented
-✅ Cascading implications identified and addressed
-✅ User provided appropriate level of explanation for skill level
-✅ A/P/C menu presented and handled correctly for each category
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Making recommendations instead of facilitating decisions
-❌ Not verifying technology versions with web search
-❌ Missing cascading implications between decisions
-❌ Not adapting explanations to user skill level
-❌ Forgetting to document decisions made by starter template
-❌ Not presenting A/P/C menu after content generation
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-05-patterns.md` to define implementation patterns that ensure consistency across AI agents.
-
-Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-architecture/steps/step-05-patterns.md b/.claude/skills/bmad-create-architecture/steps/step-05-patterns.md
deleted file mode 100644
index 6fa446d..0000000
--- a/.claude/skills/bmad-create-architecture/steps/step-05-patterns.md
+++ /dev/null
@@ -1,359 +0,0 @@
-# Step 5: Implementation Patterns & Consistency Rules
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between architectural peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on patterns that prevent AI agent implementation conflicts
-- 🎯 EMPHASIZE what agents could decide DIFFERENTLY if not specified
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 🎯 Focus on consistency, not implementation details
-- ⚠️ Present A/P/C menu after generating patterns content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to develop comprehensive consistency patterns
-- **P (Party Mode)**: Bring multiple perspectives to identify potential conflict points
-- **C (Continue)**: Save the patterns and proceed to project structure
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
-- When 'P' selected: Invoke the `bmad-party-mode` skill
-- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- Core architectural decisions from step 4 are complete
-- Technology stack is decided and versions are verified
-- Focus on HOW agents should implement, not WHAT they should implement
-- Consider what could vary between different AI agents
-
-## YOUR TASK:
-
-Define implementation patterns and consistency rules that ensure multiple AI agents write compatible, consistent code that works together seamlessly.
-
-## PATTERNS DEFINITION SEQUENCE:
-
-### 1. Identify Potential Conflict Points
-
-Based on the chosen technology stack and decisions, identify where AI agents could make different choices:
-
-**Naming Conflicts:**
-
-- Database table/column naming conventions
-- API endpoint naming patterns
-- File and directory naming
-- Component/function/variable naming
-- Route parameter formats
-
-**Structural Conflicts:**
-
-- Where tests are located
-- How components are organized
-- Where utilities and helpers go
-- Configuration file organization
-- Static asset organization
-
-**Format Conflicts:**
-
-- API response wrapper formats
-- Error response structures
-- Date/time formats in APIs and UI
-- JSON field naming conventions
-- API status code usage
-
-**Communication Conflicts:**
-
-- Event naming conventions
-- Event payload structures
-- State update patterns
-- Action naming conventions
-- Logging formats and levels
-
-**Process Conflicts:**
-
-- Loading state handling
-- Error recovery patterns
-- Retry implementation approaches
-- Authentication flow patterns
-- Validation timing and methods
-
-### 2. Facilitate Pattern Decisions
-
-For each conflict category, facilitate collaborative pattern definition:
-
-**Present the Conflict Point:**
-"Given that we're using {{tech_stack}}, different AI agents might handle {{conflict_area}} differently.
-
-For example, one agent might name database tables 'users' while another uses 'Users' - this would cause conflicts.
-
-We need to establish consistent patterns that all agents follow."
-
-**Show Options and Trade-offs:**
-"Common approaches for {{pattern_category}}:
-
-1. {{option_1}} - {{pros_and_cons}}
-2. {{option_2}} - {{pros_and_cons}}
-3. {{option_3}} - {{pros_and_cons}}
-
-Which approach makes the most sense for our project?"
-
-**Get User Decision:**
-"What's your preference for this pattern? (or discuss the trade-offs more)"
-
-### 3. Define Pattern Categories
-
-#### Naming Patterns
-
-**Database Naming:**
-
-- Table naming: users, Users, or user?
-- Column naming: user_id or userId?
-- Foreign key format: user_id or fk_user?
-- Index naming: idx_users_email or users_email_index?
-
-**API Naming:**
-
-- REST endpoint naming: /users or /user? Plural or singular?
-- Route parameter format: :id or {id}?
-- Query parameter naming: user_id or userId?
-- Header naming conventions: X-Custom-Header or Custom-Header?
-
-**Code Naming:**
-
-- Component naming: UserCard or user-card?
-- File naming: UserCard.tsx or user-card.tsx?
-- Function naming: getUserData or get_user_data?
-- Variable naming: userId or user_id?
-
-#### Structure Patterns
-
-**Project Organization:**
-
-- Where do tests live? **tests**/ or \*.test.ts co-located?
-- How are components organized? By feature or by type?
-- Where do shared utilities go?
-- How are services and repositories organized?
-
-**File Structure:**
-
-- Config file locations and naming
-- Static asset organization
-- Documentation placement
-- Environment file organization
-
-#### Format Patterns
-
-**API Formats:**
-
-- API response wrapper? {data: ..., error: ...} or direct response?
-- Error format? {message, code} or {error: {type, detail}}?
-- Date format in JSON? ISO strings or timestamps?
-- Success response structure?
-
-**Data Formats:**
-
-- JSON field naming: snake_case or camelCase?
-- Boolean representations: true/false or 1/0?
-- Null handling patterns
-- Array vs object for single items
-
-#### Communication Patterns
-
-**Event Systems:**
-
-- Event naming convention: user.created or UserCreated?
-- Event payload structure standards
-- Event versioning approach
-- Async event handling patterns
-
-**State Management:**
-
-- State update patterns: immutable updates or direct mutation?
-- Action naming conventions
-- Selector patterns
-- State organization principles
-
-#### Process Patterns
-
-**Error Handling:**
-
-- Global error handling approach
-- Error boundary patterns
-- User-facing error message format
-- Logging vs user error distinction
-
-**Loading States:**
-
-- Loading state naming conventions
-- Global vs local loading states
-- Loading state persistence
-- Loading UI patterns
-
-### 4. Generate Patterns Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-```markdown
-## Implementation Patterns & Consistency Rules
-
-### Pattern Categories Defined
-
-**Critical Conflict Points Identified:**
-{{number_of_potential_conflicts}} areas where AI agents could make different choices
-
-### Naming Patterns
-
-**Database Naming Conventions:**
-{{database_naming_rules_with_examples}}
-
-**API Naming Conventions:**
-{{api_naming_rules_with_examples}}
-
-**Code Naming Conventions:**
-{{code_naming_rules_with_examples}}
-
-### Structure Patterns
-
-**Project Organization:**
-{{project_structure_rules_with_examples}}
-
-**File Structure Patterns:**
-{{file_organization_rules_with_examples}}
-
-### Format Patterns
-
-**API Response Formats:**
-{{api_response_structure_rules}}
-
-**Data Exchange Formats:**
-{{data_format_rules_with_examples}}
-
-### Communication Patterns
-
-**Event System Patterns:**
-{{event_naming_and_structure_rules}}
-
-**State Management Patterns:**
-{{state_update_and_organization_rules}}
-
-### Process Patterns
-
-**Error Handling Patterns:**
-{{consistent_error_handling_approaches}}
-
-**Loading State Patterns:**
-{{loading_state_management_rules}}
-
-### Enforcement Guidelines
-
-**All AI Agents MUST:**
-
-- {{mandatory_pattern_1}}
-- {{mandatory_pattern_2}}
-- {{mandatory_pattern_3}}
-
-**Pattern Enforcement:**
-
-- How to verify patterns are followed
-- Where to document pattern violations
-- Process for updating patterns
-
-### Pattern Examples
-
-**Good Examples:**
-{{concrete_examples_of_correct_pattern_usage}}
-
-**Anti-Patterns:**
-{{examples_of_what_to_avoid}}
-```
-
-### 5. Present Content and Menu
-
-Show the generated patterns content and present choices:
-
-"I've documented implementation patterns that will prevent conflicts between AI agents working on this project.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 4]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Explore additional consistency patterns
-[P] Party Mode - Review patterns from different implementation perspectives
-[C] Continue - Save these patterns and move to project structure"
-
-### 6. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Invoke the `bmad-advanced-elicitation` skill with current patterns
-- Process enhanced consistency rules that come back
-- Ask user: "Accept these additional pattern refinements? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'P' (Party Mode):
-
-- Invoke the `bmad-party-mode` skill with implementation patterns context
-- Process collaborative insights about potential conflicts
-- Ask user: "Accept these changes to the implementation patterns? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Append the final content to `{planning_artifacts}/architecture.md`
-- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5]`
-- Load `./step-06-structure.md`
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 4.
-
-## SUCCESS METRICS:
-
-✅ All potential AI agent conflict points identified and addressed
-✅ Comprehensive patterns defined for naming, structure, and communication
-✅ Concrete examples provided for each pattern
-✅ Enforcement guidelines clearly documented
-✅ User collaborated on pattern decisions rather than receiving recommendations
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Missing potential conflict points that could cause agent conflicts
-❌ Being too prescriptive about implementation details instead of focusing on consistency
-❌ Not providing concrete examples for each pattern
-❌ Failing to address cross-cutting concerns like error handling
-❌ Not considering the chosen technology stack when defining patterns
-❌ Not presenting A/P/C menu after content generation
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-06-structure.md` to define the complete project structure.
-
-Remember: Do NOT proceed to step-06 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-architecture/steps/step-06-structure.md b/.claude/skills/bmad-create-architecture/steps/step-06-structure.md
deleted file mode 100644
index 195abaf..0000000
--- a/.claude/skills/bmad-create-architecture/steps/step-06-structure.md
+++ /dev/null
@@ -1,379 +0,0 @@
-# Step 6: Project Structure & Boundaries
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between architectural peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on defining complete project structure and clear boundaries
-- 🗺️ MAP requirements/epics to architectural components
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 🗺️ Create complete project tree, not generic placeholders
-- ⚠️ Present A/P/C menu after generating project structure
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative project organization approaches
-- **P (Party Mode)**: Bring multiple perspectives to evaluate project structure trade-offs
-- **C (Continue)**: Save the project structure and proceed to validation
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
-- When 'P' selected: Invoke the `bmad-party-mode` skill
-- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- All previous architectural decisions are complete
-- Implementation patterns and consistency rules are defined
-- Focus on physical project structure and component boundaries
-- Map requirements to specific files and directories
-
-## YOUR TASK:
-
-Define the complete project structure and architectural boundaries based on all decisions made, creating a concrete implementation guide for AI agents.
-
-## PROJECT STRUCTURE SEQUENCE:
-
-### 1. Analyze Requirements Mapping
-
-Map project requirements to architectural components:
-
-**From Epics (if available):**
-"Epic: {{epic_name}} → Lives in {{module/directory/service}}"
-
-- User stories within the epic
-- Cross-epic dependencies
-- Shared components needed
-
-**From FR Categories (if no epics):**
-"FR Category: {{fr_category_name}} → Lives in {{module/directory/service}}"
-
-- Related functional requirements
-- Shared functionality across categories
-- Integration points between categories
-
-### 2. Define Project Directory Structure
-
-Based on technology stack and patterns, create the complete project structure:
-
-**Root Configuration Files:**
-
-- Package management files (package.json, requirements.txt, etc.)
-- Build and development configuration
-- Environment configuration files
-- CI/CD pipeline files
-- Documentation files
-
-**Source Code Organization:**
-
-- Application entry points
-- Core application structure
-- Feature/module organization
-- Shared utilities and libraries
-- Configuration and environment files
-
-**Test Organization:**
-
-- Unit test locations and structure
-- Integration test organization
-- End-to-end test structure
-- Test utilities and fixtures
-
-**Build and Distribution:**
-
-- Build output directories
-- Distribution files
-- Static assets
-- Documentation build
-
-### 3. Define Integration Boundaries
-
-Map how components communicate and where boundaries exist:
-
-**API Boundaries:**
-
-- External API endpoints
-- Internal service boundaries
-- Authentication and authorization boundaries
-- Data access layer boundaries
-
-**Component Boundaries:**
-
-- Frontend component communication patterns
-- State management boundaries
-- Service communication patterns
-- Event-driven integration points
-
-**Data Boundaries:**
-
-- Database schema boundaries
-- Data access patterns
-- Caching boundaries
-- External data integration points
-
-### 4. Create Complete Project Tree
-
-Generate a comprehensive directory structure showing all files and directories:
-
-**Technology-Specific Structure Examples:**
-
-**Next.js Full-Stack:**
-
-```
-project-name/
-├── README.md
-├── package.json
-├── next.config.js
-├── tailwind.config.js
-├── tsconfig.json
-├── .env.local
-├── .env.example
-├── .gitignore
-├── .github/
-│   └── workflows/
-│       └── ci.yml
-├── src/
-│   ├── app/
-│   │   ├── globals.css
-│   │   ├── layout.tsx
-│   │   └── page.tsx
-│   ├── components/
-│   │   ├── ui/
-│   │   ├── forms/
-│   │   └── features/
-│   ├── lib/
-│   │   ├── db.ts
-│   │   ├── auth.ts
-│   │   └── utils.ts
-│   ├── types/
-│   └── middleware.ts
-├── prisma/
-│   ├── schema.prisma
-│   └── migrations/
-├── tests/
-│   ├── __mocks__/
-│   ├── components/
-│   └── e2e/
-└── public/
-    └── assets/
-```
-
-**API Backend (NestJS):**
-
-```
-project-name/
-├── package.json
-├── nest-cli.json
-├── tsconfig.json
-├── .env
-├── .env.example
-├── .gitignore
-├── README.md
-├── src/
-│   ├── main.ts
-│   ├── app.module.ts
-│   ├── config/
-│   ├── modules/
-│   │   ├── auth/
-│   │   ├── users/
-│   │   └── common/
-│   ├── services/
-│   ├── repositories/
-│   ├── decorators/
-│   ├── pipes/
-│   ├── guards/
-│   └── interceptors/
-├── test/
-│   ├── unit/
-│   ├── integration/
-│   └── e2e/
-├── prisma/
-│   ├── schema.prisma
-│   └── migrations/
-└── docker-compose.yml
-```
-
-### 5. Map Requirements to Structure
-
-Create explicit mapping from project requirements to specific files/directories:
-
-**Epic/Feature Mapping:**
-"Epic: User Management
-
-- Components: src/components/features/users/
-- Services: src/services/users/
-- API Routes: src/app/api/users/
-- Database: prisma/migrations/_*users*_
-- Tests: tests/features/users/"
-
-**Cross-Cutting Concerns:**
-"Authentication System
-
-- Components: src/components/auth/
-- Services: src/services/auth/
-- Middleware: src/middleware/auth.ts
-- Guards: src/guards/auth.guard.ts
-- Tests: tests/auth/"
-
-### 6. Generate Structure Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-```markdown
-## Project Structure & Boundaries
-
-### Complete Project Directory Structure
-```
-
-{{complete_project_tree_with_all_files_and_directories}}
-
-```
-
-### Architectural Boundaries
-
-**API Boundaries:**
-{{api_boundary_definitions_and_endpoints}}
-
-**Component Boundaries:**
-{{component_communication_patterns_and_boundaries}}
-
-**Service Boundaries:**
-{{service_integration_patterns_and_boundaries}}
-
-**Data Boundaries:**
-{{data_access_patterns_and_boundaries}}
-
-### Requirements to Structure Mapping
-
-**Feature/Epic Mapping:**
-{{mapping_of_epics_or_features_to_specific_directories}}
-
-**Cross-Cutting Concerns:**
-{{mapping_of_shared_functionality_to_locations}}
-
-### Integration Points
-
-**Internal Communication:**
-{{how_components_within_the_project_communicate}}
-
-**External Integrations:**
-{{third_party_service_integration_points}}
-
-**Data Flow:**
-{{how_data_flows_through_the_architecture}}
-
-### File Organization Patterns
-
-**Configuration Files:**
-{{where_and_how_config_files_are_organized}}
-
-**Source Organization:**
-{{how_source_code_is_structured_and_organized}}
-
-**Test Organization:**
-{{how_tests_are_structured_and_organized}}
-
-**Asset Organization:**
-{{how_static_and_dynamic_assets_are_organized}}
-
-### Development Workflow Integration
-
-**Development Server Structure:**
-{{how_the_project_is organized_for_development}}
-
-**Build Process Structure:**
-{{how_the_build_process_uses_the_project_structure}}
-
-**Deployment Structure:**
-{{how_the_project_structure_supports_deployment}}
-```
-
-### 7. Present Content and Menu
-
-Show the generated project structure content and present choices:
-
-"I've created a complete project structure based on all our architectural decisions.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from step 6]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Explore innovative project organization approaches
-[P] Party Mode - Review structure from different development perspectives
-[C] Continue - Save this structure and move to architecture validation"
-
-### 8. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Invoke the `bmad-advanced-elicitation` skill with current project structure
-- Process enhanced organizational insights that come back
-- Ask user: "Accept these changes to the project structure? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'P' (Party Mode):
-
-- Invoke the `bmad-party-mode` skill with project structure context
-- Process collaborative insights about organization trade-offs
-- Ask user: "Accept these changes to the project structure? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Append the final content to `{planning_artifacts}/architecture.md`
-- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6]`
-- Load `./step-07-validation.md`
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 6.
-
-## SUCCESS METRICS:
-
-✅ Complete project tree defined with all files and directories
-✅ All architectural boundaries clearly documented
-✅ Requirements/epics mapped to specific locations
-✅ Integration points and communication patterns defined
-✅ Project structure aligned with chosen technology stack
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Creating generic placeholder structure instead of specific, complete tree
-❌ Not mapping requirements to specific files and directories
-❌ Missing important integration boundaries
-❌ Not considering the chosen technology stack in structure design
-❌ Not defining how components communicate across boundaries
-❌ Not presenting A/P/C menu after content generation
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-07-validation.md` to validate architectural coherence and completeness.
-
-Remember: Do NOT proceed to step-07 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-architecture/steps/step-07-validation.md b/.claude/skills/bmad-create-architecture/steps/step-07-validation.md
deleted file mode 100644
index 3275c5d..0000000
--- a/.claude/skills/bmad-create-architecture/steps/step-07-validation.md
+++ /dev/null
@@ -1,359 +0,0 @@
-# Step 7: Architecture Validation & Completion
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between architectural peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on validating architectural coherence and completeness
-- ✅ VALIDATE all requirements are covered by architectural decisions
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ✅ Run comprehensive validation checks on the complete architecture
-- ⚠️ Present A/P/C menu after generating validation results
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## COLLABORATION MENUS (A/P/C):
-
-This step will generate content and present choices:
-
-- **A (Advanced Elicitation)**: Use discovery protocols to address complex architectural issues found during validation
-- **P (Party Mode)**: Bring multiple perspectives to resolve validation concerns
-- **C (Continue)**: Save the validation results and complete the architecture
-
-## PROTOCOL INTEGRATION:
-
-- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
-- When 'P' selected: Invoke the `bmad-party-mode` skill
-- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
-- User accepts/rejects protocol changes before proceeding
-
-## CONTEXT BOUNDARIES:
-
-- Complete architecture document with all sections is available
-- All architectural decisions, patterns, and structure are defined
-- Focus on validation, gap analysis, and coherence checking
-- Prepare for handoff to implementation phase
-
-## YOUR TASK:
-
-Validate the complete architecture for coherence, completeness, and readiness to guide AI agents through consistent implementation.
-
-## VALIDATION SEQUENCE:
-
-### 1. Coherence Validation
-
-Check that all architectural decisions work together:
-
-**Decision Compatibility:**
-
-- Do all technology choices work together without conflicts?
-- Are all versions compatible with each other?
-- Do patterns align with technology choices?
-- Are there any contradictory decisions?
-
-**Pattern Consistency:**
-
-- Do implementation patterns support the architectural decisions?
-- Are naming conventions consistent across all areas?
-- Do structure patterns align with technology stack?
-- Are communication patterns coherent?
-
-**Structure Alignment:**
-
-- Does the project structure support all architectural decisions?
-- Are boundaries properly defined and respected?
-- Does the structure enable the chosen patterns?
-- Are integration points properly structured?
-
-### 2. Requirements Coverage Validation
-
-Verify all project requirements are architecturally supported:
-
-**From Epics (if available):**
-
-- Does every epic have architectural support?
-- Are all user stories implementable with these decisions?
-- Are cross-epic dependencies handled architecturally?
-- Are there any gaps in epic coverage?
-
-**From FR Categories (if no epics):**
-
-- Does every functional requirement have architectural support?
-- Are all FR categories fully covered by architectural decisions?
-- Are cross-cutting FRs properly addressed?
-- Are there any missing architectural capabilities?
-
-**Non-Functional Requirements:**
-
-- Are performance requirements addressed architecturally?
-- Are security requirements fully covered?
-- Are scalability considerations properly handled?
-- Are compliance requirements architecturally supported?
-
-### 3. Implementation Readiness Validation
-
-Assess if AI agents can implement consistently:
-
-**Decision Completeness:**
-
-- Are all critical decisions documented with versions?
-- Are implementation patterns comprehensive enough?
-- Are consistency rules clear and enforceable?
-- Are examples provided for all major patterns?
-
-**Structure Completeness:**
-
-- Is the project structure complete and specific?
-- Are all files and directories defined?
-- Are integration points clearly specified?
-- Are component boundaries well-defined?
-
-**Pattern Completeness:**
-
-- Are all potential conflict points addressed?
-- Are naming conventions comprehensive?
-- Are communication patterns fully specified?
-- Are process patterns (error handling, etc.) complete?
-
-### 4. Gap Analysis
-
-Identify and document any missing elements:
-
-**Critical Gaps:**
-
-- Missing architectural decisions that block implementation
-- Incomplete patterns that could cause conflicts
-- Missing structural elements needed for development
-- Undefined integration points
-
-**Important Gaps:**
-
-- Areas that need more detailed specification
-- Patterns that could be more comprehensive
-- Documentation that would help implementation
-- Examples that would clarify complex decisions
-
-**Nice-to-Have Gaps:**
-
-- Additional patterns that would be helpful
-- Supplementary documentation
-- Tooling recommendations
-- Development workflow optimizations
-
-### 5. Address Validation Issues
-
-For any issues found, facilitate resolution:
-
-**Critical Issues:**
-"I found some issues that need to be addressed before implementation:
-
-{{critical_issue_description}}
-
-These could cause implementation problems. How would you like to resolve this?"
-
-**Important Issues:**
-"I noticed a few areas that could be improved:
-
-{{important_issue_description}}
-
-These aren't blocking, but addressing them would make implementation smoother. Should we work on these?"
-
-**Minor Issues:**
-"Here are some minor suggestions for improvement:
-
-{{minor_issue_description}}
-
-These are optional refinements. Would you like to address any of these?"
-
-### 6. Generate Validation Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-```markdown
-## Architecture Validation Results
-
-### Coherence Validation ✅
-
-**Decision Compatibility:**
-{{assessment_of_how_all_decisions_work_together}}
-
-**Pattern Consistency:**
-{{verification_that_patterns_support_decisions}}
-
-**Structure Alignment:**
-{{confirmation_that_structure_supports_architecture}}
-
-### Requirements Coverage Validation ✅
-
-**Epic/Feature Coverage:**
-{{verification_that_all_epics_or_features_are_supported}}
-
-**Functional Requirements Coverage:**
-{{confirmation_that_all_FRs_are_architecturally_supported}}
-
-**Non-Functional Requirements Coverage:**
-{{verification_that_NFRs_are_addressed}}
-
-### Implementation Readiness Validation ✅
-
-**Decision Completeness:**
-{{assessment_of_decision_documentation_completeness}}
-
-**Structure Completeness:**
-{{evaluation_of_project_structure_completeness}}
-
-**Pattern Completeness:**
-{{verification_of_implementation_patterns_completeness}}
-
-### Gap Analysis Results
-
-{{gap_analysis_findings_with_priority_levels}}
-
-### Validation Issues Addressed
-
-{{description_of_any_issues_found_and_resolutions}}
-
-### Architecture Completeness Checklist
-
-**✅ Requirements Analysis**
-
-- [x] Project context thoroughly analyzed
-- [x] Scale and complexity assessed
-- [x] Technical constraints identified
-- [x] Cross-cutting concerns mapped
-
-**✅ Architectural Decisions**
-
-- [x] Critical decisions documented with versions
-- [x] Technology stack fully specified
-- [x] Integration patterns defined
-- [x] Performance considerations addressed
-
-**✅ Implementation Patterns**
-
-- [x] Naming conventions established
-- [x] Structure patterns defined
-- [x] Communication patterns specified
-- [x] Process patterns documented
-
-**✅ Project Structure**
-
-- [x] Complete directory structure defined
-- [x] Component boundaries established
-- [x] Integration points mapped
-- [x] Requirements to structure mapping complete
-
-### Architecture Readiness Assessment
-
-**Overall Status:** READY FOR IMPLEMENTATION
-
-**Confidence Level:** {{high/medium/low}} based on validation results
-
-**Key Strengths:**
-{{list_of_architecture_strengths}}
-
-**Areas for Future Enhancement:**
-{{areas_that_could_be_improved_later}}
-
-### Implementation Handoff
-
-**AI Agent Guidelines:**
-
-- Follow all architectural decisions exactly as documented
-- Use implementation patterns consistently across all components
-- Respect project structure and boundaries
-- Refer to this document for all architectural questions
-
-**First Implementation Priority:**
-{{starter_template_command_or_first_architectural_step}}
-```
-
-### 7. Present Content and Menu
-
-Show the validation results and present choices:
-
-"I've completed a comprehensive validation of your architecture.
-
-**Validation Summary:**
-
-- ✅ Coherence: All decisions work together
-- ✅ Coverage: All requirements are supported
-- ✅ Readiness: AI agents can implement consistently
-
-**Here's what I'll add to complete the architecture document:**
-
-[Show the complete markdown content from step 6]
-
-**What would you like to do?**
-[A] Advanced Elicitation - Address any complex architectural concerns
-[P] Party Mode - Review validation from different implementation perspectives
-[C] Continue - Complete the architecture and finish workflow
-
-### 8. Handle Menu Selection
-
-#### If 'A' (Advanced Elicitation):
-
-- Invoke the `bmad-advanced-elicitation` skill with validation issues
-- Process enhanced solutions for complex concerns
-- Ask user: "Accept these architectural improvements? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'P' (Party Mode):
-
-- Invoke the `bmad-party-mode` skill with validation context
-- Process collaborative insights on implementation readiness
-- Ask user: "Accept these changes to the validation results? (y/n)"
-- If yes: Update content, then return to A/P/C menu
-- If no: Keep original content, then return to A/P/C menu
-
-#### If 'C' (Continue):
-
-- Append the final content to `{planning_artifacts}/architecture.md`
-- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]`
-- Load `./step-08-complete.md`
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 6.
-
-## SUCCESS METRICS:
-
-✅ All architectural decisions validated for coherence
-✅ Complete requirements coverage verified
-✅ Implementation readiness confirmed
-✅ All gaps identified and addressed
-✅ Comprehensive validation checklist completed
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Skipping validation of decision compatibility
-❌ Not verifying all requirements are architecturally supported
-❌ Missing potential implementation conflicts
-❌ Not addressing gaps found during validation
-❌ Providing incomplete validation checklist
-❌ Not presenting A/P/C menu after content generation
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-08-complete.md` to complete the workflow and provide implementation guidance.
-
-Remember: Do NOT proceed to step-08 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-architecture/steps/step-08-complete.md b/.claude/skills/bmad-create-architecture/steps/step-08-complete.md
deleted file mode 100644
index e378fc9..0000000
--- a/.claude/skills/bmad-create-architecture/steps/step-08-complete.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# Step 8: Architecture Completion & Handoff
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- ✅ ALWAYS treat this as collaborative completion between architectural peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on successful workflow completion and implementation handoff
-- 🎯 PROVIDE clear next steps for implementation phase
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 🎯 Present completion summary and implementation guidance
-- 📖 Update frontmatter with final workflow state
-- 🚫 THIS IS THE FINAL STEP IN THIS WORKFLOW
-
-## YOUR TASK:
-
-Complete the architecture workflow, provide a comprehensive completion summary, and guide the user to the next phase of their project development.
-
-## COMPLETION SEQUENCE:
-
-### 1. Congratulate the User on Completion
-
-Both you and the User completed something amazing here - give a summary of what you achieved together and really congratulate the user on a job well done.
-
-### 2. Update the created document's frontmatter
-
-```yaml
-stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]
-workflowType: 'architecture'
-lastStep: 8
-status: 'complete'
-completedAt: '{{current_date}}'
-```
-
-### 3. Next Steps Guidance
-
-Architecture complete. Invoke the `bmad-help` skill.
-
-Upon Completion of task output: offer to answer any questions about the Architecture Document.
-
-
-## SUCCESS METRICS:
-
-✅ Complete architecture document delivered with all sections
-✅ All architectural decisions documented and validated
-✅ Implementation patterns and consistency rules finalized
-✅ Project structure complete with all files and directories
-✅ User provided with clear next steps and implementation guidance
-✅ Workflow status properly updated
-✅ User collaboration maintained throughout completion process
-
-## FAILURE MODES:
-
-❌ Not providing clear implementation guidance
-❌ Missing final validation of document completeness
-❌ Not updating workflow status appropriately
-❌ Failing to celebrate the successful completion
-❌ Not providing specific next steps for the user
-❌ Rushing completion without proper summary
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## WORKFLOW COMPLETE:
-
-This is the final step of the Architecture workflow. The user now has a complete, validated architecture document ready for AI agent implementation.
-
-The architecture will serve as the single source of truth for all technical decisions, ensuring consistent implementation across the entire project development lifecycle.
diff --git a/.claude/skills/bmad-create-architecture/workflow.md b/.claude/skills/bmad-create-architecture/workflow.md
deleted file mode 100644
index 3dd945b..0000000
--- a/.claude/skills/bmad-create-architecture/workflow.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Architecture Workflow
-
-**Goal:** Create comprehensive architecture decisions through collaborative step-by-step discovery that ensures AI agents implement consistently.
-
-**Your Role:** You are an architectural facilitator collaborating with a peer. This is a partnership, not a client-vendor relationship. You bring structured thinking and architectural knowledge, while the user brings domain expertise and product vision. Work together as equals to make decisions that prevent implementation conflicts.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **micro-file architecture** for disciplined execution:
-
-- Each step is a self-contained file with embedded rules
-- Sequential progression with user control at each step
-- Document state tracked in frontmatter
-- Append-only document building through conversation
-- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
-   - Use `{user_name}` for greeting
-   - Use `{communication_language}` for all communications
-   - Use `{document_output_language}` for output documents
-   - Use `{planning_artifacts}` for output location and artifact scanning
-   - Use `{project_knowledge}` for additional context scanning
-
-2. EXECUTION
-
-Read fully and follow: `./steps/step-01-init.md` to begin the workflow.
-
-**Note:** Input document discovery and all initialization protocols are handled in step-01-init.md.
diff --git a/.claude/skills/bmad-create-epics-and-stories/SKILL.md b/.claude/skills/bmad-create-epics-and-stories/SKILL.md
deleted file mode 100644
index d092487..0000000
--- a/.claude/skills/bmad-create-epics-and-stories/SKILL.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-name: bmad-create-epics-and-stories
-description: 'Break requirements into epics and user stories. Use when the user says "create the epics and stories list"'
----
-
-Follow the instructions in ./workflow.md.
diff --git a/.claude/skills/bmad-create-epics-and-stories/steps/step-01-validate-prerequisites.md b/.claude/skills/bmad-create-epics-and-stories/steps/step-01-validate-prerequisites.md
deleted file mode 100644
index 91ad17e..0000000
--- a/.claude/skills/bmad-create-epics-and-stories/steps/step-01-validate-prerequisites.md
+++ /dev/null
@@ -1,255 +0,0 @@
-# Step 1: Validate Prerequisites and Extract Requirements
-
-## STEP GOAL:
-
-To validate that all required input documents exist and extract all requirements (FRs, NFRs, and additional requirements from UX/Architecture) needed for epic and story creation.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product strategist and technical specifications writer
-- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring requirements extraction expertise
-- ✅ User brings their product vision and context
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on extracting and organizing requirements
-- 🚫 FORBIDDEN to start creating epics or stories in this step
-- 💬 Extract requirements from ALL available documents
-- 🚪 POPULATE the template sections exactly as needed
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Extract requirements systematically from all documents
-- 💾 Populate {planning_artifacts}/epics.md with extracted requirements
-- 📖 Update frontmatter with extraction progress
-- 🚫 FORBIDDEN to load next step until user selects 'C' and requirements are extracted
-
-## REQUIREMENTS EXTRACTION PROCESS:
-
-### 1. Welcome and Overview
-
-Welcome {user_name} to comprehensive epic and story creation!
-
-**CRITICAL PREREQUISITE VALIDATION:**
-
-Verify required documents exist and are complete:
-
-1. **PRD.md** - Contains requirements (FRs and NFRs) and product scope
-2. **Architecture.md** - Contains technical decisions, API contracts, data models
-3. **UX Design.md** (if UI exists) - Contains interaction patterns, mockups, user flows
-
-### 2. Document Discovery and Validation
-
-Search for required documents using these patterns (sharded means a large document was split into multiple small files with an index.md into a folder) - if the whole document is found, use that instead of the sharded version:
-
-**PRD Document Search Priority:**
-
-1. `{planning_artifacts}/*prd*.md` (whole document)
-2. `{planning_artifacts}/*prd*/index.md` (sharded version)
-
-**Architecture Document Search Priority:**
-
-1. `{planning_artifacts}/*architecture*.md` (whole document)
-2. `{planning_artifacts}/*architecture*/index.md` (sharded version)
-
-**UX Design Document Search (Optional):**
-
-1. `{planning_artifacts}/*ux*.md` (whole document)
-2. `{planning_artifacts}/*ux*/index.md` (sharded version)
-
-Before proceeding, Ask the user if there are any other documents to include for analysis, and if anything found should be excluded. Wait for user confirmation. Once confirmed, create the {planning_artifacts}/epics.md from the ../templates/epics-template.md and in the front matter list the files in the array of `inputDocuments: []`.
-
-### 3. Extract Functional Requirements (FRs)
-
-From the PRD document (full or sharded), read then entire document and extract ALL functional requirements:
-
-**Extraction Method:**
-
-- Look for numbered items like "FR1:", "Functional Requirement 1:", or similar
-- Identify requirement statements that describe what the system must DO
-- Include user actions, system behaviors, and business rules
-
-**Format the FR list as:**
-
-```
-FR1: [Clear, testable requirement description]
-FR2: [Clear, testable requirement description]
-...
-```
-
-### 4. Extract Non-Functional Requirements (NFRs)
-
-From the PRD document, extract ALL non-functional requirements:
-
-**Extraction Method:**
-
-- Look for performance, security, usability, reliability requirements
-- Identify constraints and quality attributes
-- Include technical standards and compliance requirements
-
-**Format the NFR list as:**
-
-```
-NFR1: [Performance/Security/Usability requirement]
-NFR2: [Performance/Security/Usability requirement]
-...
-```
-
-### 5. Extract Additional Requirements from Architecture
-
-Review the Architecture document for technical requirements that impact epic and story creation:
-
-**Look for:**
-
-- **Starter Template**: Does Architecture specify a starter/greenfield template? If YES, document this for Epic 1 Story 1
-- Infrastructure and deployment requirements
-- Integration requirements with external systems
-- Data migration or setup requirements
-- Monitoring and logging requirements
-- API versioning or compatibility requirements
-- Security implementation requirements
-
-**IMPORTANT**: If a starter template is mentioned in Architecture, note it prominently. This will impact Epic 1 Story 1.
-
-**Format Additional Requirements as:**
-
-```
-- [Technical requirement from Architecture that affects implementation]
-- [Infrastructure setup requirement]
-- [Integration requirement]
-...
-```
-
-### 6. Extract UX Design Requirements (if UX document exists)
-
-**IMPORTANT**: The UX Design Specification is a first-class input document, not supplementary material. Requirements from the UX spec must be extracted with the same rigor as PRD functional requirements.
-
-Read the FULL UX Design document and extract ALL actionable work items:
-
-**Look for:**
-
-- **Design token work**: Color systems, spacing scales, typography tokens that need implementation or consolidation
-- **Component proposals**: Reusable UI components identified in the UX spec (e.g., ConfirmActions, StatusMessage, EmptyState, FocusIndicator)
-- **Visual standardization**: Semantic CSS classes, consistent color palette usage, design pattern consolidation
-- **Accessibility requirements**: Contrast audit fixes, ARIA patterns, keyboard navigation, screen reader support
-- **Responsive design requirements**: Breakpoints, layout adaptations, mobile-specific interactions
-- **Interaction patterns**: Animations, transitions, loading states, error handling UX
-- **Browser/device compatibility**: Target platforms, progressive enhancement requirements
-
-**Format UX Design Requirements as a SEPARATE section (not merged into Additional Requirements):**
-
-```
-UX-DR1: [Actionable UX design requirement with clear implementation scope]
-UX-DR2: [Actionable UX design requirement with clear implementation scope]
-...
-```
-
-**🚨 CRITICAL**: Do NOT reduce UX requirements to vague summaries. Each UX-DR must be specific enough to generate a story with testable acceptance criteria. If the UX spec identifies 6 reusable components, list all 6 — not "create reusable components."
-
-### 7. Load and Initialize Template
-
-Load ../templates/epics-template.md and initialize {planning_artifacts}/epics.md:
-
-1. Copy the entire template to {planning_artifacts}/epics.md
-2. Replace {{project_name}} with the actual project name
-3. Replace placeholder sections with extracted requirements:
-   - {{fr_list}} → extracted FRs
-   - {{nfr_list}} → extracted NFRs
-   - {{additional_requirements}} → extracted additional requirements (from Architecture)
-   - {{ux_design_requirements}} → extracted UX Design Requirements (if UX document exists)
-4. Leave {{requirements_coverage_map}} and {{epics_list}} as placeholders for now
-
-### 8. Present Extracted Requirements
-
-Display to user:
-
-**Functional Requirements Extracted:**
-
-- Show count of FRs found
-- Display the first few FRs as examples
-- Ask if any FRs are missing or incorrectly captured
-
-**Non-Functional Requirements Extracted:**
-
-- Show count of NFRs found
-- Display key NFRs
-- Ask if any constraints were missed
-
-**Additional Requirements (Architecture):**
-
-- Summarize technical requirements from Architecture
-- Verify completeness
-
-**UX Design Requirements (if applicable):**
-
-- Show count of UX-DRs found
-- Display key UX Design requirements (design tokens, components, accessibility)
-- Verify each UX-DR is specific enough for story creation
-
-### 9. Get User Confirmation
-
-Ask: "Do these extracted requirements accurately represent what needs to be built? Any additions or corrections?"
-
-Update the requirements based on user feedback until confirmation is received.
-
-## CONTENT TO SAVE TO DOCUMENT:
-
-After extraction and confirmation, update {planning_artifacts}/epics.md with:
-
-- Complete FR list in {{fr_list}} section
-- Complete NFR list in {{nfr_list}} section
-- All additional requirements in {{additional_requirements}} section
-- UX Design requirements in {{ux_design_requirements}} section (if UX document exists)
-
-### 10. Present MENU OPTIONS
-
-Display: `**Confirm the Requirements are complete and correct to [C] continue:**`
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- User can chat or ask questions - always respond and then end with display again of the menu option
-
-#### Menu Handling Logic:
-
-- IF C: Save all to {planning_artifacts}/epics.md, update frontmatter, then read fully and follow: ./step-02-design-epics.md
-- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#10-present-menu-options)
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN C is selected and all requirements are saved to document and frontmatter is updated, will you then read fully and follow: ./step-02-design-epics.md to begin epic design step.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- All required documents found and validated
-- All FRs extracted and formatted correctly
-- All NFRs extracted and formatted correctly
-- Additional requirements from Architecture/UX identified
-- Template initialized with requirements
-- User confirms requirements are complete and accurate
-
-### ❌ SYSTEM FAILURE:
-
-- Missing required documents
-- Incomplete requirements extraction
-- Template not properly initialized
-- Not saving requirements to output file
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
diff --git a/.claude/skills/bmad-create-epics-and-stories/steps/step-02-design-epics.md b/.claude/skills/bmad-create-epics-and-stories/steps/step-02-design-epics.md
deleted file mode 100644
index 00dd285..0000000
--- a/.claude/skills/bmad-create-epics-and-stories/steps/step-02-design-epics.md
+++ /dev/null
@@ -1,212 +0,0 @@
-# Step 2: Design Epic List
-
-## STEP GOAL:
-
-To design and get approval for the epics_list that will organize all requirements into user-value-focused epics.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product strategist and technical specifications writer
-- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring product strategy and epic design expertise
-- ✅ User brings their product vision and priorities
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on creating the epics_list
-- 🚫 FORBIDDEN to create individual stories in this step
-- 💬 Organize epics around user value, not technical layers
-- 🚪 GET explicit approval for the epics_list
-- 🔗 **CRITICAL: Each epic must be standalone and enable future epics without requiring future epics to function**
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Design epics collaboratively based on extracted requirements
-- 💾 Update {{epics_list}} in {planning_artifacts}/epics.md
-- 📖 Document the FR coverage mapping
-- 🚫 FORBIDDEN to load next step until user approves epics_list
-
-## EPIC DESIGN PROCESS:
-
-### 1. Review Extracted Requirements
-
-Load {planning_artifacts}/epics.md and review:
-
-- **Functional Requirements:** Count and review FRs from Step 1
-- **Non-Functional Requirements:** Review NFRs that need to be addressed
-- **Additional Requirements:** Review technical and UX requirements
-
-### 2. Explain Epic Design Principles
-
-**EPIC DESIGN PRINCIPLES:**
-
-1. **User-Value First**: Each epic must enable users to accomplish something meaningful
-2. **Requirements Grouping**: Group related FRs that deliver cohesive user outcomes
-3. **Incremental Delivery**: Each epic should deliver value independently
-4. **Logical Flow**: Natural progression from user's perspective
-5. **🔗 Dependency-Free Within Epic**: Stories within an epic must NOT depend on future stories
-
-**⚠️ CRITICAL PRINCIPLE:**
-Organize by USER VALUE, not technical layers:
-
-**✅ CORRECT Epic Examples (Standalone & Enable Future Epics):**
-
-- Epic 1: User Authentication & Profiles (users can register, login, manage profiles) - **Standalone: Complete auth system**
-- Epic 2: Content Creation (users can create, edit, publish content) - **Standalone: Uses auth, creates content**
-- Epic 3: Social Interaction (users can follow, comment, like content) - **Standalone: Uses auth + content**
-- Epic 4: Search & Discovery (users can find content and other users) - **Standalone: Uses all previous**
-
-**❌ WRONG Epic Examples (Technical Layers or Dependencies):**
-
-- Epic 1: Database Setup (creates all tables upfront) - **No user value**
-- Epic 2: API Development (builds all endpoints) - **No user value**
-- Epic 3: Frontend Components (creates reusable components) - **No user value**
-- Epic 4: Deployment Pipeline (CI/CD setup) - **No user value**
-
-**🔗 DEPENDENCY RULES:**
-
-- Each epic must deliver COMPLETE functionality for its domain
-- Epic 2 must not require Epic 3 to function
-- Epic 3 can build upon Epic 1 & 2 but must stand alone
-
-### 3. Design Epic Structure Collaboratively
-
-**Step A: Identify User Value Themes**
-
-- Look for natural groupings in the FRs
-- Identify user journeys or workflows
-- Consider user types and their goals
-
-**Step B: Propose Epic Structure**
-For each proposed epic:
-
-1. **Epic Title**: User-centric, value-focused
-2. **User Outcome**: What users can accomplish after this epic
-3. **FR Coverage**: Which FR numbers this epic addresses
-4. **Implementation Notes**: Any technical or UX considerations
-
-**Step C: Create the epics_list**
-
-Format the epics_list as:
-
-```
-## Epic List
-
-### Epic 1: [Epic Title]
-[Epic goal statement - what users can accomplish]
-**FRs covered:** FR1, FR2, FR3, etc.
-
-### Epic 2: [Epic Title]
-[Epic goal statement - what users can accomplish]
-**FRs covered:** FR4, FR5, FR6, etc.
-
-[Continue for all epics]
-```
-
-### 4. Present Epic List for Review
-
-Display the complete epics_list to user with:
-
-- Total number of epics
-- FR coverage per epic
-- User value delivered by each epic
-- Any natural dependencies
-
-### 5. Create Requirements Coverage Map
-
-Create {{requirements_coverage_map}} showing how each FR maps to an epic:
-
-```
-### FR Coverage Map
-
-FR1: Epic 1 - [Brief description]
-FR2: Epic 1 - [Brief description]
-FR3: Epic 2 - [Brief description]
-...
-```
-
-This ensures no FRs are missed.
-
-### 6. Collaborative Refinement
-
-Ask user:
-
-- "Does this epic structure align with your product vision?"
-- "Are all user outcomes properly captured?"
-- "Should we adjust any epic groupings?"
-- "Are there natural dependencies we've missed?"
-
-### 7. Get Final Approval
-
-**CRITICAL:** Must get explicit user approval:
-"Do you approve this epic structure for proceeding to story creation?"
-
-If user wants changes:
-
-- Make the requested adjustments
-- Update the epics_list
-- Re-present for approval
-- Repeat until approval is received
-
-## CONTENT TO UPDATE IN DOCUMENT:
-
-After approval, update {planning_artifacts}/epics.md:
-
-1. Replace {{epics_list}} placeholder with the approved epic list
-2. Replace {{requirements_coverage_map}} with the coverage map
-3. Ensure all FRs are mapped to epics
-
-### 8. Present MENU OPTIONS
-
-Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
-
-#### Menu Handling Logic:
-
-- IF A: Invoke the `bmad-advanced-elicitation` skill
-- IF P: Invoke the `bmad-party-mode` skill
-- IF C: Save approved epics_list to {planning_artifacts}/epics.md, update frontmatter, then read fully and follow: ./step-03-create-stories.md
-- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution completes, redisplay the menu
-- User can chat or ask questions - always respond when conversation ends, redisplay the menu options
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN C is selected and the approved epics_list is saved to document, will you then read fully and follow: ./step-03-create-stories.md to begin story creation step.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Epics designed around user value
-- All FRs mapped to specific epics
-- epics_list created and formatted correctly
-- Requirements coverage map completed
-- User gives explicit approval for epic structure
-- Document updated with approved epics
-
-### ❌ SYSTEM FAILURE:
-
-- Epics organized by technical layers
-- Missing FRs in coverage map
-- No user approval obtained
-- epics_list not saved to document
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
diff --git a/.claude/skills/bmad-create-epics-and-stories/steps/step-03-create-stories.md b/.claude/skills/bmad-create-epics-and-stories/steps/step-03-create-stories.md
deleted file mode 100644
index 14caafe..0000000
--- a/.claude/skills/bmad-create-epics-and-stories/steps/step-03-create-stories.md
+++ /dev/null
@@ -1,255 +0,0 @@
-# Step 3: Generate Epics and Stories
-
-## STEP GOAL:
-
-To generate all epics with their stories based on the approved epics_list, following the template structure exactly.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: Process epics sequentially
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product strategist and technical specifications writer
-- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring story creation and acceptance criteria expertise
-- ✅ User brings their implementation priorities and constraints
-
-### Step-Specific Rules:
-
-- 🎯 Generate stories for each epic following the template exactly
-- 🚫 FORBIDDEN to deviate from template structure
-- 💬 Each story must have clear acceptance criteria
-- 🚪 ENSURE each story is completable by a single dev agent
-- 🔗 **CRITICAL: Stories MUST NOT depend on future stories within the same epic**
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Generate stories collaboratively with user input
-- 💾 Append epics and stories to {planning_artifacts}/epics.md following template
-- 📖 Process epics one at a time in sequence
-- 🚫 FORBIDDEN to skip any epic or rush through stories
-
-## STORY GENERATION PROCESS:
-
-### 1. Load Approved Epic Structure
-
-Load {planning_artifacts}/epics.md and review:
-
-- Approved epics_list from Step 2
-- FR coverage map
-- All requirements (FRs, NFRs, additional, **UX Design requirements if present**)
-- Template structure at the end of the document
-
-**UX Design Integration**: If UX Design Requirements (UX-DRs) were extracted in Step 1, ensure they are visible during story creation. UX-DRs must be covered by stories — either within existing epics (e.g., accessibility fixes for a feature epic) or in a dedicated "Design System / UX Polish" epic.
-
-### 2. Explain Story Creation Approach
-
-**STORY CREATION GUIDELINES:**
-
-For each epic, create stories that:
-
-- Follow the exact template structure
-- Are sized for single dev agent completion
-- Have clear user value
-- Include specific acceptance criteria
-- Reference requirements being fulfilled
-
-**🚨 DATABASE/ENTITY CREATION PRINCIPLE:**
-Create tables/entities ONLY when needed by the story:
-
-- ❌ WRONG: Epic 1 Story 1 creates all 50 database tables
-- ✅ RIGHT: Each story creates/alters ONLY the tables it needs
-
-**🔗 STORY DEPENDENCY PRINCIPLE:**
-Stories must be independently completable in sequence:
-
-- ❌ WRONG: Story 1.2 requires Story 1.3 to be completed first
-- ✅ RIGHT: Each story can be completed based only on previous stories
-- ❌ WRONG: "Wait for Story 1.4 to be implemented before this works"
-- ✅ RIGHT: "This story works independently and enables future stories"
-
-**STORY FORMAT (from template):**
-
-```
-### Story {N}.{M}: {story_title}
-
-As a {user_type},
-I want {capability},
-So that {value_benefit}.
-
-**Acceptance Criteria:**
-
-**Given** {precondition}
-**When** {action}
-**Then** {expected_outcome}
-**And** {additional_criteria}
-```
-
-**✅ GOOD STORY EXAMPLES:**
-
-_Epic 1: User Authentication_
-
-- Story 1.1: User Registration with Email
-- Story 1.2: User Login with Password
-- Story 1.3: Password Reset via Email
-
-_Epic 2: Content Creation_
-
-- Story 2.1: Create New Blog Post
-- Story 2.2: Edit Existing Blog Post
-- Story 2.3: Publish Blog Post
-
-**❌ BAD STORY EXAMPLES:**
-
-- Story: "Set up database" (no user value)
-- Story: "Create all models" (too large, no user value)
-- Story: "Build authentication system" (too large)
-- Story: "Login UI (depends on Story 1.3 API endpoint)" (future dependency!)
-- Story: "Edit post (requires Story 1.4 to be implemented first)" (wrong order!)
-
-### 3. Process Epics Sequentially
-
-For each epic in the approved epics_list:
-
-#### A. Epic Overview
-
-Display:
-
-- Epic number and title
-- Epic goal statement
-- FRs covered by this epic
-- Any NFRs or additional requirements relevant
-- Any UX Design Requirements (UX-DRs) relevant to this epic
-
-#### B. Story Breakdown
-
-Work with user to break down the epic into stories:
-
-- Identify distinct user capabilities
-- Ensure logical flow within the epic
-- Size stories appropriately
-
-#### C. Generate Each Story
-
-For each story in the epic:
-
-1. **Story Title**: Clear, action-oriented
-2. **User Story**: Complete the As a/I want/So that format
-3. **Acceptance Criteria**: Write specific, testable criteria
-
-**AC Writing Guidelines:**
-
-- Use Given/When/Then format
-- Each AC should be independently testable
-- Include edge cases and error conditions
-- Reference specific requirements when applicable
-
-#### D. Collaborative Review
-
-After writing each story:
-
-- Present the story to user
-- Ask: "Does this story capture the requirement correctly?"
-- "Is the scope appropriate for a single dev session?"
-- "Are the acceptance criteria complete and testable?"
-
-#### E. Append to Document
-
-When story is approved:
-
-- Append it to {planning_artifacts}/epics.md following template structure
-- Use correct numbering (Epic N, Story M)
-- Maintain proper markdown formatting
-
-### 4. Epic Completion
-
-After all stories for an epic are complete:
-
-- Display epic summary
-- Show count of stories created
-- Verify all FRs for the epic are covered
-- Get user confirmation to proceed to next epic
-
-### 5. Repeat for All Epics
-
-Continue the process for each epic in the approved list, processing them in order (Epic 1, Epic 2, etc.).
-
-### 6. Final Document Completion
-
-After all epics and stories are generated:
-
-- Verify the document follows template structure exactly
-- Ensure all placeholders are replaced
-- Confirm all FRs are covered
-- **Confirm all UX Design Requirements (UX-DRs) are covered by at least one story** (if UX document was an input)
-- Check formatting consistency
-
-## TEMPLATE STRUCTURE COMPLIANCE:
-
-The final {planning_artifacts}/epics.md must follow this structure exactly:
-
-1. **Overview** section with project name
-2. **Requirements Inventory** with all three subsections populated
-3. **FR Coverage Map** showing requirement to epic mapping
-4. **Epic List** with approved epic structure
-5. **Epic sections** for each epic (N = 1, 2, 3...)
-   - Epic title and goal
-   - All stories for that epic (M = 1, 2, 3...)
-     - Story title and user story
-     - Acceptance Criteria using Given/When/Then format
-
-### 7. Present FINAL MENU OPTIONS
-
-After all epics and stories are complete:
-
-Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
-
-#### Menu Handling Logic:
-
-- IF A: Invoke the `bmad-advanced-elicitation` skill
-- IF P: Invoke the `bmad-party-mode` skill
-- IF C: Save content to {planning_artifacts}/epics.md, update frontmatter, then read fully and follow: ./step-04-final-validation.md
-- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-final-menu-options)
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-- User can chat or ask questions - always respond and then end with display again of the menu options
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN [C continue option] is selected and [all epics and stories saved to document following the template structure exactly], will you then read fully and follow: `./step-04-final-validation.md` to begin final validation phase.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- All epics processed in sequence
-- Stories created for each epic
-- Template structure followed exactly
-- All FRs covered by stories
-- Stories appropriately sized
-- Acceptance criteria are specific and testable
-- Document is complete and ready for development
-
-### ❌ SYSTEM FAILURE:
-
-- Deviating from template structure
-- Missing epics or stories
-- Stories too large or unclear
-- Missing acceptance criteria
-- Not following proper formatting
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
diff --git a/.claude/skills/bmad-create-epics-and-stories/steps/step-04-final-validation.md b/.claude/skills/bmad-create-epics-and-stories/steps/step-04-final-validation.md
deleted file mode 100644
index d115edc..0000000
--- a/.claude/skills/bmad-create-epics-and-stories/steps/step-04-final-validation.md
+++ /dev/null
@@ -1,131 +0,0 @@
-# Step 4: Final Validation
-
-## STEP GOAL:
-
-To validate complete coverage of all requirements and ensure stories are ready for development.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: Process validation sequentially without skipping
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product strategist and technical specifications writer
-- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring validation expertise and quality assurance
-- ✅ User brings their implementation priorities and final review
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on validating complete requirements coverage
-- 🚫 FORBIDDEN to skip any validation checks
-- 💬 Validate FR coverage, story completeness, and dependencies
-- 🚪 ENSURE all stories are ready for development
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Validate every requirement has story coverage
-- 💾 Check story dependencies and flow
-- 📖 Verify architecture compliance
-- 🚫 FORBIDDEN to approve incomplete coverage
-
-## CONTEXT BOUNDARIES:
-
-- Available context: Complete epic and story breakdown from previous steps
-- Focus: Final validation of requirements coverage and story readiness
-- Limits: Validation only, no new content creation
-- Dependencies: Completed story generation from Step 3
-
-## VALIDATION PROCESS:
-
-### 1. FR Coverage Validation
-
-Review the complete epic and story breakdown to ensure EVERY FR is covered:
-
-**CRITICAL CHECK:**
-
-- Go through each FR from the Requirements Inventory
-- Verify it appears in at least one story
-- Check that acceptance criteria fully address the FR
-- No FRs should be left uncovered
-
-### 2. Architecture Implementation Validation
-
-**Check for Starter Template Setup:**
-
-- Does Architecture document specify a starter template?
-- If YES: Epic 1 Story 1 must be "Set up initial project from starter template"
-- This includes cloning, installing dependencies, initial configuration
-
-**Database/Entity Creation Validation:**
-
-- Are database tables/entities created ONLY when needed by stories?
-- ❌ WRONG: Epic 1 creates all tables upfront
-- ✅ RIGHT: Tables created as part of the first story that needs them
-- Each story should create/modify ONLY what it needs
-
-### 3. Story Quality Validation
-
-**Each story must:**
-
-- Be completable by a single dev agent
-- Have clear acceptance criteria
-- Reference specific FRs it implements
-- Include necessary technical details
-- **Not have forward dependencies** (can only depend on PREVIOUS stories)
-- Be implementable without waiting for future stories
-
-### 4. Epic Structure Validation
-
-**Check that:**
-
-- Epics deliver user value, not technical milestones
-- Dependencies flow naturally
-- Foundation stories only setup what's needed
-- No big upfront technical work
-
-### 5. Dependency Validation (CRITICAL)
-
-**Epic Independence Check:**
-
-- Does each epic deliver COMPLETE functionality for its domain?
-- Can Epic 2 function without Epic 3 being implemented?
-- Can Epic 3 function standalone using Epic 1 & 2 outputs?
-- ❌ WRONG: Epic 2 requires Epic 3 features to work
-- ✅ RIGHT: Each epic is independently valuable
-
-**Within-Epic Story Dependency Check:**
-For each epic, review stories in order:
-
-- Can Story N.1 be completed without Stories N.2, N.3, etc.?
-- Can Story N.2 be completed using only Story N.1 output?
-- Can Story N.3 be completed using only Stories N.1 & N.2 outputs?
-- ❌ WRONG: "This story depends on a future story"
-- ❌ WRONG: Story references features not yet implemented
-- ✅ RIGHT: Each story builds only on previous stories
-
-### 6. Complete and Save
-
-If all validations pass:
-
-- Update any remaining placeholders in the document
-- Ensure proper formatting
-- Save the final epics.md
-
-**Present Final Menu:**
-**All validations complete!** [C] Complete Workflow
-
-HALT — wait for user input before proceeding.
-
-When C is selected, the workflow is complete and the epics.md is ready for development.
-
-Epics and Stories complete. Invoke the `bmad-help` skill.
-
-Upon Completion of task output: offer to answer any questions about the Epics and Stories.
diff --git a/.claude/skills/bmad-create-epics-and-stories/templates/epics-template.md b/.claude/skills/bmad-create-epics-and-stories/templates/epics-template.md
deleted file mode 100644
index bf80c7f..0000000
--- a/.claude/skills/bmad-create-epics-and-stories/templates/epics-template.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-stepsCompleted: []
-inputDocuments: []
----
-
-# {{project_name}} - Epic Breakdown
-
-## Overview
-
-This document provides the complete epic and story breakdown for {{project_name}}, decomposing the requirements from the PRD, UX Design if it exists, and Architecture requirements into implementable stories.
-
-## Requirements Inventory
-
-### Functional Requirements
-
-{{fr_list}}
-
-### NonFunctional Requirements
-
-{{nfr_list}}
-
-### Additional Requirements
-
-{{additional_requirements}}
-
-### UX Design Requirements
-
-{{ux_design_requirements}}
-
-### FR Coverage Map
-
-{{requirements_coverage_map}}
-
-## Epic List
-
-{{epics_list}}
-
-<!-- Repeat for each epic in epics_list (N = 1, 2, 3...) -->
-
-## Epic {{N}}: {{epic_title_N}}
-
-{{epic_goal_N}}
-
-<!-- Repeat for each story (M = 1, 2, 3...) within epic N -->
-
-### Story {{N}}.{{M}}: {{story_title_N_M}}
-
-As a {{user_type}},
-I want {{capability}},
-So that {{value_benefit}}.
-
-**Acceptance Criteria:**
-
-<!-- for each AC on this story -->
-
-**Given** {{precondition}}
-**When** {{action}}
-**Then** {{expected_outcome}}
-**And** {{additional_criteria}}
-
-<!-- End story repeat -->
diff --git a/.claude/skills/bmad-create-epics-and-stories/workflow.md b/.claude/skills/bmad-create-epics-and-stories/workflow.md
deleted file mode 100644
index 510e273..0000000
--- a/.claude/skills/bmad-create-epics-and-stories/workflow.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Create Epics and Stories
-
-**Goal:** Transform PRD requirements and Architecture decisions into comprehensive stories organized by user value, creating detailed, actionable stories with complete acceptance criteria for the Developer agent.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also a product strategist and technical specifications writer collaborating with a product owner. This is a partnership, not a client-vendor relationship. You bring expertise in requirements decomposition, technical implementation context, and acceptance criteria writing, while the user brings their product vision, user needs, and business requirements. Work together as equals.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
-- **Just-In-Time Loading**: Only 1 current step file will be loaded and followed to completion - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- 🛑 **NEVER** load multiple step files simultaneously
-- 📖 **ALWAYS** read entire step file before execution
-- 🚫 **NEVER** skip steps or optimize the sequence
-- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
-   - Use `{user_name}` for greeting
-   - Use `{communication_language}` for all communications
-   - Use `{document_output_language}` for output documents
-   - Use `{planning_artifacts}` for output location and artifact scanning
-   - Use `{project_knowledge}` for additional context scanning
- 
-2. First Step EXECUTION
-
-Read fully and follow: `./steps/step-01-validate-prerequisites.md` to begin the workflow.
diff --git a/.claude/skills/bmad-create-prd/SKILL.md b/.claude/skills/bmad-create-prd/SKILL.md
deleted file mode 100644
index 54f7640..0000000
--- a/.claude/skills/bmad-create-prd/SKILL.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-name: bmad-create-prd
-description: 'Create a PRD from scratch. Use when the user says "lets create a product requirements document" or "I want to create a new PRD"'
----
-
-Follow the instructions in ./workflow.md.
diff --git a/.claude/skills/bmad-create-prd/data/domain-complexity.csv b/.claude/skills/bmad-create-prd/data/domain-complexity.csv
deleted file mode 100644
index 60a7b50..0000000
--- a/.claude/skills/bmad-create-prd/data/domain-complexity.csv
+++ /dev/null
@@ -1,15 +0,0 @@
-domain,signals,complexity,key_concerns,required_knowledge,suggested_workflow,web_searches,special_sections
-healthcare,"medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug",high,"FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability","Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements","domain-research","FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software","clinical_requirements;regulatory_pathway;validation_methodology;safety_measures"
-fintech,"payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech",high,"Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection","KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations","domain-research","fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date}","compliance_matrix;security_architecture;audit_requirements;fraud_prevention"
-govtech,"government,federal,civic,public sector,citizen,municipal,voting",high,"Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency","Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements","domain-research","government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards","procurement_compliance;security_clearance;accessibility_standards;transparency_requirements"
-edtech,"education,learning,student,teacher,curriculum,assessment,K-12,university,LMS",medium,"Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards","Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity","domain-research","educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards","privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment"
-aerospace,"aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation",high,"Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls","Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements","domain-research + technical-model","DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements","safety_certification;simulation_validation;performance_requirements;export_compliance"
-automotive,"vehicle,car,autonomous,ADAS,automotive,driving,EV,charging",high,"Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification","Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements","domain-research","ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards","safety_standards;functional_safety;communication_protocols;certification_requirements"
-scientific,"research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI",medium,"Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources","Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards","technical-model","scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software","validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements"
-legaltech,"legal,law,contract,compliance,litigation,patent,attorney,court",high,"Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration","Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality","domain-research","legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology","ethics_compliance;data_retention;confidentiality_measures;court_integration"
-insuretech,"insurance,claims,underwriting,actuarial,policy,risk,premium",high,"Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance","Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting","domain-research","insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance","regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance"
-energy,"energy,utility,grid,solar,wind,power,electricity,oil,gas",high,"Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations","Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems","domain-research","energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards","grid_compliance;safety_protocols;environmental_compliance;operational_requirements"
-process_control,"industrial automation,process control,PLC,SCADA,DCS,HMI,operational technology,OT,control system,cyberphysical,MES,historian,instrumentation,I&C,P&ID",high,"Functional safety;OT cybersecurity;Real-time control requirements;Legacy system integration;Process safety and hazard analysis;Environmental compliance and permitting;Engineering authority and PE requirements","Functional safety standards;OT security frameworks;Industrial protocols;Process control architecture;Plant reliability and maintainability","domain-research + technical-model","IEC 62443 OT cybersecurity requirements {date};functional safety software requirements {date};industrial process control architecture;ISA-95 manufacturing integration","functional_safety;ot_security;process_requirements;engineering_authority"
-building_automation,"building automation,BAS,BMS,HVAC,smart building,lighting control,fire alarm,fire protection,fire suppression,life safety,elevator,access control,DDC,energy management,sequence of operations,commissioning",high,"Life safety codes;Building energy standards;Multi-trade coordination and interoperability;Commissioning and ongoing operational performance;Indoor environmental quality and occupant comfort;Engineering authority and PE requirements","Building automation protocols;HVAC and mechanical controls;Fire alarm, fire protection, and life safety design;Commissioning process and sequence of operations;Building codes and energy standards","domain-research","smart building software architecture {date};BACnet integration best practices;building automation cybersecurity {date};ASHRAE building standards","life_safety;energy_compliance;commissioning_requirements;engineering_authority"
-gaming,"game,player,gameplay,level,character,multiplayer,quest",redirect,"REDIRECT TO GAME WORKFLOWS","Game design","game-brief","NA","NA"
-general,"",low,"Standard requirements;Basic security;User experience;Performance","General software practices","continue","software development best practices {date}","standard_requirements"
\ No newline at end of file
diff --git a/.claude/skills/bmad-create-prd/data/prd-purpose.md b/.claude/skills/bmad-create-prd/data/prd-purpose.md
deleted file mode 100644
index 755230b..0000000
--- a/.claude/skills/bmad-create-prd/data/prd-purpose.md
+++ /dev/null
@@ -1,197 +0,0 @@
-# BMAD PRD Purpose
-
-**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
-
----
-
-## What is a BMAD PRD?
-
-A dual-audience document serving:
-1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
-2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
-
-Each successive document becomes more AI-tailored and granular.
-
----
-
-## Core Philosophy: Information Density
-
-**High Signal-to-Noise Ratio**
-
-Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
-
-**Anti-Patterns (Eliminate These):**
-- ❌ "The system will allow users to..." → ✅ "Users can..."
-- ❌ "It is important to note that..." → ✅ State the fact directly
-- ❌ "In order to..." → ✅ "To..."
-- ❌ Conversational filler and padding → ✅ Direct, concise statements
-
-**Goal:** Maximum information per word. Zero fluff.
-
----
-
-## The Traceability Chain
-
-**PRD starts the chain:**
-```
-Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
-```
-
-**In the PRD, establish:**
-- Vision → Success Criteria alignment
-- Success Criteria → User Journey coverage
-- User Journey → Functional Requirement mapping
-- All requirements traceable to user needs
-
-**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
-
----
-
-## What Makes Great Functional Requirements?
-
-### FRs are Capabilities, Not Implementation
-
-**Good FR:** "Users can reset their password via email link"
-**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
-
-**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
-**Bad FR:** "Fast loading time" (subjective, unmeasurable)
-
-### SMART Quality Criteria
-
-**Specific:** Clear, precisely defined capability
-**Measurable:** Quantifiable with test criteria
-**Attainable:** Realistic within constraints
-**Relevant:** Aligns with business objectives
-**Traceable:** Links to source (executive summary or user journey)
-
-### FR Anti-Patterns
-
-**Subjective Adjectives:**
-- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
-- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
-
-**Implementation Leakage:**
-- ❌ Technology names, specific libraries, implementation details
-- ✅ Focus on capability and measurable outcomes
-
-**Vague Quantifiers:**
-- ❌ "multiple users", "several options", "various formats"
-- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
-
-**Missing Test Criteria:**
-- ❌ "The system shall provide notifications"
-- ✅ "The system shall send email notifications within 30 seconds of trigger event"
-
----
-
-## What Makes Great Non-Functional Requirements?
-
-### NFRs Must Be Measurable
-
-**Template:**
-```
-"The system shall [metric] [condition] [measurement method]"
-```
-
-**Examples:**
-- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
-- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
-- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
-
-### NFR Anti-Patterns
-
-**Unmeasurable Claims:**
-- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
-- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
-
-**Missing Context:**
-- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
-
----
-
-## Domain-Specific Requirements
-
-**Auto-Detect and Enforce Based on Project Context**
-
-Certain industries have mandatory requirements that must be present:
-
-- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
-- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
-- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
-- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
-
-**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
-
----
-
-## Document Structure (Markdown, Human-Readable)
-
-### Required Sections
-1. **Executive Summary** - Vision, differentiator, target users
-2. **Success Criteria** - Measurable outcomes (SMART)
-3. **Product Scope** - MVP, Growth, Vision phases
-4. **User Journeys** - Comprehensive coverage
-5. **Domain Requirements** - Industry-specific compliance (if applicable)
-6. **Innovation Analysis** - Competitive differentiation (if applicable)
-7. **Project-Type Requirements** - Platform-specific needs
-8. **Functional Requirements** - Capability contract (FRs)
-9. **Non-Functional Requirements** - Quality attributes (NFRs)
-
-### Formatting for Dual Consumption
-
-**For Humans:**
-- Clear, professional language
-- Logical flow from vision to requirements
-- Easy for stakeholders to review and approve
-
-**For LLMs:**
-- ## Level 2 headers for all main sections (enables extraction)
-- Consistent structure and patterns
-- Precise, testable language
-- High information density
-
----
-
-## Downstream Impact
-
-**How the PRD Feeds Next Artifacts:**
-
-**UX Design:**
-- User journeys → interaction flows
-- FRs → design requirements
-- Success criteria → UX metrics
-
-**Architecture:**
-- FRs → system capabilities
-- NFRs → architecture decisions
-- Domain requirements → compliance architecture
-- Project-type requirements → platform choices
-
-**Epics & Stories (created after architecture):**
-- FRs → user stories (1 FR could map to 1-3 stories potentially)
-- Acceptance criteria → story acceptance tests
-- Priority → sprint sequencing
-- Traceability → stories map back to vision
-
-**Development AI Agents:**
-- Precise requirements → implementation clarity
-- Test criteria → automated test generation
-- Domain requirements → compliance enforcement
-- Measurable NFRs → performance targets
-
----
-
-## Summary: What Makes a Great BMAD PRD?
-
-✅ **High Information Density** - Every sentence carries weight, zero fluff
-✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
-✅ **Clear Traceability** - Each requirement links to user need and business objective
-✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
-✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
-✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
-✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
-
----
-
-**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.
diff --git a/.claude/skills/bmad-create-prd/data/project-types.csv b/.claude/skills/bmad-create-prd/data/project-types.csv
deleted file mode 100644
index 6f71c51..0000000
--- a/.claude/skills/bmad-create-prd/data/project-types.csv
+++ /dev/null
@@ -1,11 +0,0 @@
-project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
-api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
-mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
-saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
-developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
-cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
-web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
-game,"game,player,gameplay,level,character","REDIRECT TO USE THE BMad Method Game Module Agent and Workflows - HALT","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
-desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
-iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
-blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"
\ No newline at end of file
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-01-init.md b/.claude/skills/bmad-create-prd/steps-c/step-01-init.md
deleted file mode 100644
index 8268e6a..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-01-init.md
+++ /dev/null
@@ -1,178 +0,0 @@
-# Step 1: Workflow Initialization
-
-**Progress: Step 1 of 11** - Next: Project Discovery
-
-## STEP GOAL:
-
-Initialize the PRD workflow by detecting continuation state, discovering input documents, and setting up the document structure for collaborative product requirement discovery.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product-focused PM facilitator collaborating with an expert peer
-- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
-
-### Step-Specific Rules:
-
-- 🎯 Focus only on initialization and setup - no content generation yet
-- 🚫 FORBIDDEN to look ahead to future steps or assume knowledge from them
-- 💬 Approach: Systematic setup with clear reporting to user
-- 🚪 Detect existing workflow state and handle continuation properly
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis of current state before taking any action
-- 💾 Initialize document structure and update frontmatter appropriately
-- Update frontmatter: add this step name to the end of the steps completed array (it should be the first entry in the steps array since this is step 1)
-- 🚫 FORBIDDEN to load next step until user selects 'C' (Continue)
-
-## CONTEXT BOUNDARIES:
-
-- Available context: Variables from workflow.md are available in memory
-- Focus: Workflow initialization and document setup only
-- Limits: Don't assume knowledge from other steps or create content yet
-- Dependencies: Configuration loaded from workflow.md initialization
-
-## Sequence of Instructions (Do not deviate, skip, or optimize)
-
-### 1. Check for Existing Workflow State
-
-First, check if the output document already exists:
-
-**Workflow State Detection:**
-
-- Look for file at `{outputFile}`
-- If exists, read the complete file including frontmatter
-- If not exists, this is a fresh workflow
-
-### 2. Handle Continuation (If Document Exists)
-
-If the document exists and has frontmatter with `stepsCompleted` BUT `step-12-complete` is NOT in the list, follow the Continuation Protocol since the document is incomplete:
-
-**Continuation Protocol:**
-
-- **STOP immediately** and load `./step-01b-continue.md`
-- Do not proceed with any initialization tasks
-- Let step-01b handle all continuation logic
-- This is an auto-proceed situation - no user choice needed
-
-### 3. Fresh Workflow Setup (If No Document)
-
-If no document exists or no `stepsCompleted` in frontmatter:
-
-#### A. Input Document Discovery
-
-Discover and load context documents using smart discovery. Documents can be in the following locations:
-- {planning_artifacts}/**
-- {output_folder}/**
-- {project_knowledge}/**
-- docs/**
-
-Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files. For Example, if searching for `*foo*.md` and not found, also search for a folder called *foo*/index.md (which indicates sharded content)
-
-Try to discover the following:
-- Product Brief (`*brief*.md`)
-- Research Documents (`/*research*.md`)
-- Project Documentation (generally multiple documents might be found for this in the `{project_knowledge}` or `docs` folder.)
-- Project Context (`**/project-context.md`)
-
-<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. Only after this confirmation will you proceed to follow the loading rules</critical>
-
-**Loading Rules:**
-
-- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
-- If there is a project context, whatever is relevant should try to be biased in the remainder of this whole workflow process
-- For sharded folders, load ALL files to get complete picture, using the index first to potentially know the potential of each document
-- index.md is a guide to what's relevant whenever available
-- Track all successfully loaded files in frontmatter `inputDocuments` array
-
-#### B. Create Initial Document
-
-**Document Setup:**
-
-- Copy the template from `../templates/prd-template.md` to `{outputFile}`
-- Initialize frontmatter with proper structure including inputDocuments array.
-
-#### C. Present Initialization Results
-
-**Setup Report to User:**
-
-"Welcome {{user_name}}! I've set up your PRD workspace for {{project_name}}.
-
-**Document Setup:**
-
-- Created: `{outputFile}` from template
-- Initialized frontmatter with workflow state
-
-**Input Documents Discovered:**
-
-- Product briefs: {{briefCount}} files {if briefCount > 0}✓ loaded{else}(none found){/if}
-- Research: {{researchCount}} files {if researchCount > 0}✓ loaded{else}(none found){/if}
-- Brainstorming: {{brainstormingCount}} files {if brainstormingCount > 0}✓ loaded{else}(none found){/if}
-- Project docs: {{projectDocsCount}} files {if projectDocsCount > 0}✓ loaded (brownfield project){else}(none found - greenfield project){/if}
-
-**Files loaded:** {list of specific file names or "No additional documents found"}
-
-{if projectDocsCount > 0}
-📋 **Note:** This is a **brownfield project**. Your existing project documentation has been loaded. In the next step, I'll ask specifically about what new features or changes you want to add to your existing system.
-{/if}
-
-Do you have any other documents you'd like me to include, or shall we continue to the next step?"
-
-### 4. Present MENU OPTIONS
-
-Display menu after setup report:
-
-"[C] Continue - Save this and move to Project Discovery (Step 2 of 11)"
-
-#### Menu Handling Logic:
-
-- IF C: Update output file frontmatter, adding this step name to the end of the list of stepsCompleted, then read fully and follow: ./step-02-discovery.md
-- IF user provides additional files: Load them, update inputDocuments and documentCounts, redisplay report
-- IF user asks questions: Answer and redisplay menu
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN [C continue option] is selected and [frontmatter properly updated with this step added to stepsCompleted and documentCounts], will you then read fully and follow: `./step-02-discovery.md` to begin project discovery.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Existing workflow detected and properly handed off to step-01b
-- Fresh workflow initialized with template and proper frontmatter
-- Input documents discovered and loaded using sharded-first logic
-- All discovered files tracked in frontmatter `inputDocuments`
-- User clearly informed of brownfield vs greenfield status
-- Menu presented and user input handled correctly
-- Frontmatter updated with this step name added to stepsCompleted before proceeding
-
-### ❌ SYSTEM FAILURE:
-
-- Proceeding with fresh initialization when existing workflow exists
-- Not updating frontmatter with discovered input documents
-- **Not storing document counts in frontmatter**
-- Creating document without proper template structure
-- Not checking sharded folders first before whole files
-- Not reporting discovered documents to user clearly
-- Proceeding without user selecting 'C' (Continue)
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-01b-continue.md b/.claude/skills/bmad-create-prd/steps-c/step-01b-continue.md
deleted file mode 100644
index 4351cc1..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-01b-continue.md
+++ /dev/null
@@ -1,161 +0,0 @@
-# Step 1B: Workflow Continuation
-
-## STEP GOAL:
-
-Resume the PRD workflow from where it was left off, ensuring smooth continuation with full context restoration.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product-focused PM facilitator collaborating with an expert peer
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ Resume workflow from exact point where it was interrupted
-
-### Step-Specific Rules:
-
-- 💬 FOCUS on understanding where we left off and continuing appropriately
-- 🚫 FORBIDDEN to modify content completed in previous steps
-- 📖 Only reload documents that were already tracked in `inputDocuments`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis of current state before taking action
-- Update frontmatter: add this step name to the end of the steps completed array
-- 📖 Only load documents that were already tracked in `inputDocuments`
-- 🚫 FORBIDDEN to discover new input documents during continuation
-
-## CONTEXT BOUNDARIES:
-
-- Available context: Current document and frontmatter are already loaded
-- Focus: Workflow state analysis and continuation logic only
-- Limits: Don't assume knowledge beyond what's in the document
-- Dependencies: Existing workflow state from previous session
-
-## Sequence of Instructions (Do not deviate, skip, or optimize)
-
-### 1. Analyze Current State
-
-**State Assessment:**
-Review the frontmatter to understand:
-
-- `stepsCompleted`: Array of completed step filenames
-- Last element of `stepsCompleted` array: The most recently completed step
-- `inputDocuments`: What context was already loaded
-- All other frontmatter variables
-
-### 2. Restore Context Documents
-
-**Context Reloading:**
-
-- For each document in `inputDocuments`, load the complete file
-- This ensures you have full context for continuation
-- Don't discover new documents - only reload what was previously processed
-
-### 3. Determine Next Step
-
-**Step Sequence Lookup:**
-
-Use the following ordered sequence to determine the next step from the last completed step:
-
-| Last Completed | Next Step |
-|---|---|
-| step-01-init.md | step-02-discovery.md |
-| step-02-discovery.md | step-02b-vision.md |
-| step-02b-vision.md | step-02c-executive-summary.md |
-| step-02c-executive-summary.md | step-03-success.md |
-| step-03-success.md | step-04-journeys.md |
-| step-04-journeys.md | step-05-domain.md |
-| step-05-domain.md | step-06-innovation.md |
-| step-06-innovation.md | step-07-project-type.md |
-| step-07-project-type.md | step-08-scoping.md |
-| step-08-scoping.md | step-09-functional.md |
-| step-09-functional.md | step-10-nonfunctional.md |
-| step-10-nonfunctional.md | step-11-polish.md |
-| step-11-polish.md | step-12-complete.md |
-
-1. Get the last element from the `stepsCompleted` array
-2. Look it up in the table above to find the next step
-3. That's the next step to load!
-
-**Example:**
-- If `stepsCompleted = ["step-01-init.md", "step-02-discovery.md", "step-03-success.md"]`
-- Last element is `"step-03-success.md"`
-- Table lookup → next step is `./step-04-journeys.md`
-
-### 4. Handle Workflow Completion
-
-**If `stepsCompleted` array contains `"step-12-complete.md"`:**
-"Great news! It looks like we've already completed the PRD workflow for {{project_name}}.
-
-The final document is ready at `{outputFile}` with all sections completed.
-
-Would you like me to:
-
-- Review the completed PRD with you
-- Suggest next workflow steps (like architecture or epic creation)
-- Start a new PRD revision
-
-What would be most helpful?"
-
-### 5. Present Current Progress
-
-**If workflow not complete:**
-"Welcome back {{user_name}}! I'm resuming our PRD collaboration for {{project_name}}.
-
-**Current Progress:**
-- Last completed: {last step filename from stepsCompleted array}
-- Next up: {next step from lookup table}
-- Context documents available: {len(inputDocuments)} files
-
-**Document Status:**
-- Current PRD document is ready with all completed sections
-- Ready to continue from where we left off
-
-Does this look right, or do you want to make any adjustments before we proceed?"
-
-### 6. Present MENU OPTIONS
-
-Display: "**Select an Option:** [C] Continue to {next step name}"
-
-#### Menu Handling Logic:
-
-- IF C: Read fully and follow the next step determined from the lookup table in step 3
-- IF Any other comments or queries: respond and redisplay menu
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN [C continue option] is selected and [current state confirmed], will you then read fully and follow the next step (from the lookup table) to resume the workflow.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- All previous input documents successfully reloaded
-- Current workflow state accurately analyzed and presented
-- User confirms understanding of progress before continuation
-- Correct next step identified and prepared for loading
-
-### ❌ SYSTEM FAILURE:
-
-- Discovering new input documents instead of reloading existing ones
-- Modifying content from already completed steps
-- Failing to determine the next step from the lookup table
-- Proceeding without user confirmation of current state
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-02-discovery.md b/.claude/skills/bmad-create-prd/steps-c/step-02-discovery.md
deleted file mode 100644
index 3eeb524..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-02-discovery.md
+++ /dev/null
@@ -1,208 +0,0 @@
-# Step 2: Project Discovery
-
-**Progress: Step 2 of 13** - Next: Product Vision
-
-## STEP GOAL:
-
-Discover and classify the project - understand what type of product this is, what domain it operates in, and the project context (greenfield vs brownfield).
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product-focused PM facilitator collaborating with an expert peer
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
-
-### Step-Specific Rules:
-
-- 🎯 Focus on classification and understanding - no content generation yet
-- 🚫 FORBIDDEN to generate executive summary or vision statements (that's next steps)
-- 💬 APPROACH: Natural conversation to understand the project
-- 🎯 LOAD classification data BEFORE starting discovery conversation
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after classification complete
-- 💾 ONLY save classification to frontmatter when user chooses C (Continue)
-- 📖 Update frontmatter, adding this step to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from step 1 are available
-- Input documents already loaded are in memory (product briefs, research, brainstorming, project docs)
-- **Document counts available in frontmatter `documentCounts`**
-- Classification CSV data will be loaded in this step only
-- No executive summary or vision content yet (that's steps 2b and 2c)
-
-## YOUR TASK:
-
-Discover and classify the project through natural conversation:
-- What type of product is this? (web app, API, mobile, etc.)
-- What domain does it operate in? (healthcare, fintech, e-commerce, etc.)
-- What's the project context? (greenfield new product vs brownfield existing system)
-- How complex is this domain? (low, medium, high)
-
-## DISCOVERY SEQUENCE:
-
-### 1. Check Document State
-
-Read the frontmatter from `{outputFile}` to get document counts:
-- `briefCount` - Product briefs available
-- `researchCount` - Research documents available
-- `brainstormingCount` - Brainstorming docs available
-- `projectDocsCount` - Existing project documentation
-
-**Announce your understanding:**
-
-"From step 1, I have loaded:
-- Product briefs: {{briefCount}}
-- Research: {{researchCount}}
-- Brainstorming: {{brainstormingCount}}
-- Project docs: {{projectDocsCount}}
-
-{{if projectDocsCount > 0}}This is a brownfield project - I'll focus on understanding what you want to add or change.{{else}}This is a greenfield project - I'll help you define the full product vision.{{/if}}"
-
-### 2. Load Classification Data
-
-**Attempt subprocess data lookup:**
-
-**Project Type Lookup:**
-"Your task: Lookup data in ../data/project-types.csv
-
-**Search criteria:**
-- Find row where project_type matches {{detectedProjectType}}
-
-**Return format:**
-Return ONLY the matching row as a YAML-formatted object with these fields:
-project_type, detection_signals
-
-**Do NOT return the entire CSV - only the matching row.**"
-
-**Domain Complexity Lookup:**
-"Your task: Lookup data in ../data/domain-complexity.csv
-
-**Search criteria:**
-- Find row where domain matches {{detectedDomain}}
-
-**Return format:**
-Return ONLY the matching row as a YAML-formatted object with these fields:
-domain, complexity, typical_concerns, compliance_requirements
-
-**Do NOT return the entire CSV - only the matching row.**"
-
-**Graceful degradation (if Task tool unavailable):**
-- Load the CSV files directly
-- Find the matching rows manually
-- Extract required fields
-- Keep in memory for intelligent classification
-
-### 3. Begin Discovery Conversation
-
-**Start with what you know:**
-
-If the user has a product brief or project docs, acknowledge them and share your understanding. Then ask clarifying questions to deepen your understanding.
-
-If this is a greenfield project with no docs, start with open-ended discovery:
-- What problem does this solve?
-- Who's it for?
-- What excites you about building this?
-
-**Listen for classification signals:**
-
-As the user describes their product, match against:
-- **Project type signals** (API, mobile, SaaS, etc.)
-- **Domain signals** (healthcare, fintech, education, etc.)
-- **Complexity indicators** (regulated industries, novel technology, etc.)
-
-### 4. Confirm Classification
-
-Once you have enough understanding, share your classification:
-
-"I'm hearing this as:
-- **Project Type:** {{detectedType}}
-- **Domain:** {{detectedDomain}}
-- **Complexity:** {{complexityLevel}}
-
-Does this sound right to you?"
-
-Let the user confirm or refine your classification.
-
-### 5. Save Classification to Frontmatter
-
-When user selects 'C', update frontmatter with classification:
-```yaml
-classification:
-  projectType: {{projectType}}
-  domain: {{domain}}
-  complexity: {{complexityLevel}}
-  projectContext: {{greenfield|brownfield}}
-```
-
-### N. Present MENU OPTIONS
-
-Present the project classification for review, then display menu:
-
-"Based on our conversation, I've discovered and classified your project.
-
-**Here's the classification:**
-
-**Project Type:** {{detectedType}}
-**Domain:** {{detectedDomain}}
-**Complexity:** {{complexityLevel}}
-**Project Context:** {{greenfield|brownfield}}
-
-**What would you like to do?**"
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Product Vision (Step 2b of 13)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the current classification, process the enhanced insights that come back, ask user if they accept the improvements, if yes update classification then redisplay menu, if no keep original classification then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the current classification, process the collaborative insights, ask user if they accept the changes, if yes update classification then redisplay menu, if no keep original classification then redisplay menu
-- IF C: Save classification to {outputFile} frontmatter, add this step name to the end of stepsCompleted array, then read fully and follow: ./step-02b-vision.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN [C continue option] is selected and [classification saved to frontmatter], will you then read fully and follow: `./step-02b-vision.md` to explore product vision.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Document state checked and announced to user
-- Classification data loaded and used intelligently
-- Natural conversation to understand project type, domain, complexity
-- Classification validated with user before saving
-- Frontmatter updated with classification when C selected
-- User's existing documents acknowledged and built upon
-
-### ❌ SYSTEM FAILURE:
-
-- Not reading documentCounts from frontmatter first
-- Skipping classification data loading
-- Generating executive summary or vision content (that's later steps!)
-- Not validating classification with user
-- Being prescriptive instead of having natural conversation
-- Proceeding without user selecting 'C'
-
-**Master Rule:** This is classification and understanding only. No content generation yet. Build on what the user already has. Have natural conversations, don't follow scripts.
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-02b-vision.md b/.claude/skills/bmad-create-prd/steps-c/step-02b-vision.md
deleted file mode 100644
index 37f91e6..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-02b-vision.md
+++ /dev/null
@@ -1,142 +0,0 @@
-# Step 2b: Product Vision Discovery
-
-**Progress: Step 2b of 13** - Next: Executive Summary
-
-## STEP GOAL:
-
-Discover what makes this product special and understand the product vision through collaborative conversation. No content generation — facilitation only.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product-focused PM facilitator collaborating with an expert peer
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
-
-### Step-Specific Rules:
-
-- 🎯 Focus on discovering vision and differentiator — no content generation yet
-- 🚫 FORBIDDEN to generate executive summary content (that's the next step)
-- 🚫 FORBIDDEN to append anything to the document in this step
-- 💬 APPROACH: Natural conversation to understand what makes this product special
-- 🎯 BUILD ON classification insights from step 2
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after vision discovery is complete
-- 📖 Update frontmatter, adding this step to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from steps 1 and 2 are available
-- Project classification exists from step 2 (project type, domain, complexity, context)
-- Input documents already loaded are in memory (product briefs, research, brainstorming, project docs)
-- No executive summary content yet (that's step 2c)
-- This step ONLY discovers — it does NOT write to the document
-
-## YOUR TASK:
-
-Discover the product vision and differentiator through natural conversation. Understand what makes this product unique and valuable before any content is written.
-
-## VISION DISCOVERY SEQUENCE:
-
-### 1. Acknowledge Classification Context
-
-Reference the classification from step 2 and use it to frame the vision conversation:
-
-"We've established this is a {{projectType}} in the {{domain}} domain with {{complexityLevel}} complexity. Now let's explore what makes this product special."
-
-### 2. Explore What Makes It Special
-
-Guide the conversation to uncover the product's unique value:
-
-- **User delight:** "What would make users say 'this is exactly what I needed'?"
-- **Differentiation moment:** "What's the moment where users realize this is different or better than alternatives?"
-- **Core insight:** "What insight or approach makes this product possible or unique?"
-- **Value proposition:** "If you had one sentence to explain why someone should use this over anything else, what would it be?"
-
-### 3. Understand the Vision
-
-Dig deeper into the product vision:
-
-- **Problem framing:** "What's the real problem you're solving — not the surface symptom, but the deeper need?"
-- **Future state:** "When this product is successful, what does the world look like for your users?"
-- **Why now:** "Why is this the right time to build this?"
-
-### 4. Validate Understanding
-
-Reflect back what you've heard and confirm:
-
-"Here's what I'm hearing about your vision and differentiator:
-
-**Vision:** {{summarized_vision}}
-**What Makes It Special:** {{summarized_differentiator}}
-**Core Insight:** {{summarized_insight}}
-
-Does this capture it? Anything I'm missing?"
-
-Let the user confirm or refine your understanding.
-
-### N. Present MENU OPTIONS
-
-Present your understanding of the product vision for review, then display menu:
-
-"Based on our conversation, I have a clear picture of your product vision and what makes it special. I'll use these insights to draft the Executive Summary in the next step.
-
-**What would you like to do?**"
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Executive Summary (Step 2c of 13)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the current vision insights, process the enhanced insights that come back, ask user if they accept the improvements, if yes update understanding then redisplay menu, if no keep original understanding then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the current vision insights, process the collaborative insights, ask user if they accept the changes, if yes update understanding then redisplay menu, if no keep original understanding then redisplay menu
-- IF C: Update {outputFile} frontmatter by adding this step name to the end of stepsCompleted array, then read fully and follow: ./step-02c-executive-summary.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN [C continue option] is selected and [stepsCompleted updated], will you then read fully and follow: `./step-02c-executive-summary.md` to generate the Executive Summary.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Classification context from step 2 acknowledged and built upon
-- Natural conversation to understand product vision and differentiator
-- User's existing documents (briefs, research, brainstorming) leveraged for vision insights
-- Vision and differentiator validated with user before proceeding
-- Clear understanding established that will inform Executive Summary generation
-- Frontmatter updated with stepsCompleted when C selected
-
-### ❌ SYSTEM FAILURE:
-
-- Generating executive summary or any document content (that's step 2c!)
-- Appending anything to the PRD document
-- Not building on classification from step 2
-- Being prescriptive instead of having natural conversation
-- Proceeding without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-
-**Master Rule:** This step is vision discovery only. No content generation, no document writing. Have natural conversations, build on what you know from classification, and establish the vision that will feed into the Executive Summary.
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-02c-executive-summary.md b/.claude/skills/bmad-create-prd/steps-c/step-02c-executive-summary.md
deleted file mode 100644
index 93c2ac2..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-02c-executive-summary.md
+++ /dev/null
@@ -1,158 +0,0 @@
-# Step 2c: Executive Summary Generation
-
-**Progress: Step 2c of 13** - Next: Success Criteria
-
-## STEP GOAL:
-
-Generate the Executive Summary content using insights from classification (step 2) and vision discovery (step 2b), then append it to the PRD document.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product-focused PM facilitator collaborating with an expert peer
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ Content is drafted collaboratively — present for review before saving
-
-### Step-Specific Rules:
-
-- 🎯 Generate Executive Summary content based on discovered insights
-- 💬 Present draft content for user review and refinement before appending
-- 🚫 FORBIDDEN to append content without user approval via 'C'
-- 🎯 Content must be dense, precise, and zero-fluff (PRD quality standards)
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating executive summary content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from steps 1, 2, and 2b are available
-- Project classification exists from step 2 (project type, domain, complexity, context)
-- Vision and differentiator insights exist from step 2b
-- Input documents from step 1 are available (product briefs, research, brainstorming, project docs)
-- This step generates and appends the first substantive content to the PRD
-
-## YOUR TASK:
-
-Draft the Executive Summary section using all discovered insights, present it for user review, and append it to the PRD document when approved.
-
-## EXECUTIVE SUMMARY GENERATION SEQUENCE:
-
-### 1. Synthesize Available Context
-
-Review all available context before drafting:
-- Classification from step 2: project type, domain, complexity, project context
-- Vision and differentiator from step 2b: what makes this special, core insight
-- Input documents: product briefs, research, brainstorming, project docs
-
-### 2. Draft Executive Summary Content
-
-Generate the Executive Summary section using the content structure below. Apply PRD quality standards:
-- High information density — every sentence carries weight
-- Zero fluff — no filler phrases or vague language
-- Precise and actionable — clear, specific statements
-- Dual-audience optimized — readable by humans, consumable by LLMs
-
-### 3. Present Draft for Review
-
-Present the drafted content to the user for review:
-
-"Here's the Executive Summary I've drafted based on our discovery work. Please review and let me know if you'd like any changes:"
-
-Show the full drafted content using the structure from the Content Structure section below.
-
-Allow the user to:
-- Request specific changes to any section
-- Add missing information
-- Refine the language or emphasis
-- Approve as-is
-
-### N. Present MENU OPTIONS
-
-Present the executive summary content for user review, then display menu:
-
-"Here's the Executive Summary for your PRD. Review the content above and let me know what you'd like to do."
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Success Criteria (Step 3 of 13)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the current executive summary content, process the enhanced content that comes back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the current executive summary content, process the collaborative improvements, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-03-success.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the following content structure directly to the document:
-
-```markdown
-## Executive Summary
-
-{vision_alignment_content}
-
-### What Makes This Special
-
-{product_differentiator_content}
-
-## Project Classification
-
-{project_classification_content}
-```
-
-Where:
-- `{vision_alignment_content}` — Product vision, target users, and the problem being solved. Dense, precise summary drawn from step 2b vision discovery.
-- `{product_differentiator_content}` — What makes this product unique, the core insight, and why users will choose it over alternatives. Drawn from step 2b differentiator discovery.
-- `{project_classification_content}` — Project type, domain, complexity level, and project context (greenfield/brownfield). Drawn from step 2 classification.
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN [C continue option] is selected and [content appended to document], will you then read fully and follow: `./step-03-success.md` to define success criteria.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Executive Summary drafted using insights from steps 2 and 2b
-- Content meets PRD quality standards (dense, precise, zero-fluff)
-- Draft presented to user for review before saving
-- User given opportunity to refine content
-- Content properly appended to document when C selected
-- A/P/C menu presented and handled correctly
-- Frontmatter updated with stepsCompleted when C selected
-
-### ❌ SYSTEM FAILURE:
-
-- Generating content without incorporating discovered vision and classification
-- Appending content without user selecting 'C'
-- Producing vague, fluffy, or low-density content
-- Not presenting draft for user review
-- Not presenting A/P/C menu after content generation
-- Skipping directly to next step without appending content
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-**Master Rule:** Generate high-quality Executive Summary content from discovered insights. Present for review, refine collaboratively, and only save when the user approves. This is the first substantive content in the PRD — it sets the quality bar for everything that follows.
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-03-success.md b/.claude/skills/bmad-create-prd/steps-c/step-03-success.md
deleted file mode 100644
index 2d57ffe..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-03-success.md
+++ /dev/null
@@ -1,214 +0,0 @@
-# Step 3: Success Criteria Definition
-
-**Progress: Step 3 of 11** - Next: User Journey Mapping
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on defining what winning looks like for this product
-- 🎯 COLLABORATIVE discovery, not assumption-based goal setting
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating success criteria content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- Executive Summary and Project Classification already exist in document
-- Input documents from step-01 are available (product briefs, research, brainstorming)
-- No additional data files needed for this step
-- Focus on measurable, specific success criteria
-- LEVERAGE existing input documents to inform success criteria
-
-## YOUR TASK:
-
-Define comprehensive success criteria that cover user success, business success, and technical success, using input documents as a foundation while allowing user refinement.
-
-## SUCCESS DISCOVERY SEQUENCE:
-
-### 1. Begin Success Definition Conversation
-
-**Check Input Documents for Success Indicators:**
-Analyze product brief, research, and brainstorming documents for success criteria already mentioned.
-
-**If Input Documents Contain Success Criteria:**
-Guide user to refine existing success criteria:
-- Acknowledge what's already documented in their materials
-- Extract key success themes from brief, research, and brainstorming
-- Help user identify gaps and areas for expansion
-- Probe for specific, measurable outcomes: When do users feel delighted/relieved/empowered?
-- Ask about emotional success moments and completion scenarios
-- Explore what "worth it" means beyond what's already captured
-
-**If No Success Criteria in Input Documents:**
-Start with user-centered success exploration:
-- Guide conversation toward defining what "worth it" means for users
-- Ask about the moment users realize their problem is solved
-- Explore specific user outcomes and emotional states
-- Identify success "aha!" moments and completion scenarios
-- Focus on user experience of success first
-
-### 2. Explore User Success Metrics
-
-Listen for specific user outcomes and help make them measurable:
-
-- Guide from vague to specific: NOT "users are happy" → "users complete [key action] within [timeframe]"
-- Ask about emotional success: "When do they feel delighted/relieved/empowered?"
-- Identify success moments: "What's the 'aha!' moment?"
-- Define completion scenarios: "What does 'done' look like for the user?"
-
-### 3. Define Business Success
-
-Transition to business metrics:
-- Guide conversation to business perspective on success
-- Explore timelines: What does 3-month success look like? 12-month success?
-- Identify key business metrics: revenue, user growth, engagement, or other measures?
-- Ask what specific metric would indicate "this is working"
-- Understand business success from their perspective
-
-### 4. Challenge Vague Metrics
-
-Push for specificity on business metrics:
-
-- "10,000 users" → "What kind of users? Doing what?"
-- "99.9% uptime" → "What's the real concern - data loss? Failed payments?"
-- "Fast" → "How fast, and what specifically needs to be fast?"
-- "Good adoption" → "What percentage adoption by when?"
-
-### 5. Connect to Product Differentiator
-
-Tie success metrics back to what makes the product special:
-- Connect success criteria to the product's unique differentiator
-- Ensure metrics reflect the specific value proposition
-- Adapt success criteria to domain context:
-  - Consumer: User love, engagement, retention
-  - B2B: ROI, efficiency, adoption
-  - Developer tools: Developer experience, community
-  - Regulated: Compliance, safety, validation
-  - GovTech: Government compliance, accessibility, procurement
-
-### 6. Smart Scope Negotiation
-
-Guide scope definition through success lens:
-- Help user distinguish MVP (must work to be useful) from growth (competitive) and vision (dream)
-- Guide conversation through three scope levels:
-  1. MVP: What's essential for proving the concept?
-  2. Growth: What makes it competitive?
-  3. Vision: What's the dream version?
-- Challenge scope creep conversationally: Could this wait until after launch? Is this essential for MVP?
-- For complex domains: Ensure compliance minimums are included in MVP
-
-### 7. Generate Success Criteria Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## Success Criteria
-
-### User Success
-
-[Content about user success criteria based on conversation]
-
-### Business Success
-
-[Content about business success metrics based on conversation]
-
-### Technical Success
-
-[Content about technical success requirements based on conversation]
-
-### Measurable Outcomes
-
-[Content about specific measurable outcomes based on conversation]
-
-## Product Scope
-
-### MVP - Minimum Viable Product
-
-[Content about MVP scope based on conversation]
-
-### Growth Features (Post-MVP)
-
-[Content about growth features based on conversation]
-
-### Vision (Future)
-
-[Content about future vision based on conversation]
-```
-
-### 8. Present MENU OPTIONS
-
-Present the success criteria content for user review, then display menu:
-
-- Show the drafted success criteria and scope definition (using structure from section 7)
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of the conversation
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to User Journey Mapping (Step 4 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the current success criteria content, process the enhanced success metrics that come back, ask user "Accept these improvements to the success criteria? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the current success criteria, process the collaborative improvements to metrics and scope, ask user "Accept these changes to the success criteria? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-04-journeys.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 7.
-
-## SUCCESS METRICS:
-
-✅ User success criteria clearly identified and made measurable
-✅ Business success metrics defined with specific targets
-✅ Success criteria connected to product differentiator
-✅ Scope properly negotiated (MVP, Growth, Vision)
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Accepting vague success metrics without pushing for specificity
-❌ Not connecting success criteria back to product differentiator
-❌ Missing scope negotiation and leaving it undefined
-❌ Generating content without real user input on what success looks like
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## DOMAIN CONSIDERATIONS:
-
-If working in regulated domains (healthcare, fintech, govtech):
-
-- Include compliance milestones in success criteria
-- Add regulatory approval timelines to MVP scope
-- Consider audit requirements as technical success metrics
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-04-journeys.md` to map user journeys.
-
-Remember: Do NOT proceed to step-04 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-04-journeys.md b/.claude/skills/bmad-create-prd/steps-c/step-04-journeys.md
deleted file mode 100644
index ba9d675..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-04-journeys.md
+++ /dev/null
@@ -1,201 +0,0 @@
-# Step 4: User Journey Mapping
-
-**Progress: Step 4 of 11** - Next: Domain Requirements
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on mapping ALL user types that interact with the system
-- 🎯 CRITICAL: No journey = no functional requirements = product doesn't exist
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating journey content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- Success criteria and scope already defined
-- Input documents from step-01 are available (product briefs with user personas)
-- Every human interaction with the system needs a journey
-
-## YOUR TASK:
-
-Create compelling narrative user journeys that leverage existing personas from product briefs and identify additional user types needed for comprehensive coverage.
-
-## JOURNEY MAPPING SEQUENCE:
-
-### 1. Leverage Existing Users & Identify Additional Types
-
-**Check Input Documents for Existing Personas:**
-Analyze product brief, research, and brainstorming documents for user personas already defined.
-
-**If User Personas Exist in Input Documents:**
-Guide user to build on existing personas:
-- Acknowledge personas found in their product brief
-- Extract key persona details and backstories
-- Leverage existing insights about their needs
-- Prompt to identify additional user types beyond those documented
-- Suggest additional user types based on product context (admins, moderators, support, API consumers, internal ops)
-- Ask what additional user types should be considered
-
-**If No Personas in Input Documents:**
-Start with comprehensive user type discovery:
-- Guide exploration of ALL people who interact with the system
-- Consider beyond primary users: admins, moderators, support staff, API consumers, internal ops
-- Ask what user types should be mapped for this specific product
-- Ensure comprehensive coverage of all system interactions
-
-### 2. Create Narrative Story-Based Journeys
-
-For each user type, create compelling narrative journeys that tell their story:
-
-#### Narrative Journey Creation Process:
-
-**If Using Existing Persona from Input Documents:**
-Guide narrative journey creation:
-- Use persona's existing backstory from brief
-- Explore how the product changes their life/situation
-- Craft journey narrative: where do we meet them, how does product help them write their next chapter?
-
-**If Creating New Persona:**
-Guide persona creation with story framework:
-- Name: realistic name and personality
-- Situation: What's happening in their life/work that creates need?
-- Goal: What do they desperately want to achieve?
-- Obstacle: What's standing in their way?
-- Solution: How does the product solve their story?
-
-**Story-Based Journey Mapping:**
-
-Guide narrative journey creation using story structure:
-- **Opening Scene**: Where/how do we meet them? What's their current pain?
-- **Rising Action**: What steps do they take? What do they discover?
-- **Climax**: Critical moment where product delivers real value
-- **Resolution**: How does their situation improve? What's their new reality?
-
-Encourage narrative format with specific user details, emotional journey, and clear before/after contrast
-
-### 3. Guide Journey Exploration
-
-For each journey, facilitate detailed exploration:
-- What happens at each step specifically?
-- What could go wrong? What's the recovery path?
-- What information do they need to see/hear?
-- What's their emotional state at each point?
-- Where does this journey succeed or fail?
-
-### 4. Connect Journeys to Requirements
-
-After each journey, explicitly state:
-- This journey reveals requirements for specific capability areas
-- Help user see how different journeys create different feature sets
-- Connect journey needs to concrete capabilities (onboarding, dashboards, notifications, etc.)
-
-### 5. Aim for Comprehensive Coverage
-
-Guide toward complete journey set:
-
-- **Primary user** - happy path (core experience)
-- **Primary user** - edge case (different goal, error recovery)
-- **Secondary user** (admin, moderator, support, etc.)
-- **API consumer** (if applicable)
-
-Ask if additional journeys are needed to cover uncovered user types
-
-### 6. Generate User Journey Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## User Journeys
-
-[All journey narratives based on conversation]
-
-### Journey Requirements Summary
-
-[Summary of capabilities revealed by journeys based on conversation]
-```
-
-### 7. Present MENU OPTIONS
-
-Present the user journey content for review, then display menu:
-- Show the mapped user journeys (using structure from section 6)
-- Highlight how each journey reveals different capabilities
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of conversation
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Domain Requirements (Step 5 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the current journey content, process the enhanced journey insights that come back, ask user "Accept these improvements to the user journeys? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the current journeys, process the collaborative journey improvements and additions, ask user "Accept these changes to the user journeys? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-05-domain.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 6.
-
-## SUCCESS METRICS:
-
-✅ Existing personas from product briefs leveraged when available
-✅ All user types identified (not just primary users)
-✅ Rich narrative storytelling for each persona and journey
-✅ Complete story-based journey mapping with emotional arc
-✅ Journey requirements clearly connected to capabilities needed
-✅ Minimum 3-4 compelling narrative journeys covering different user types
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Ignoring existing personas from product briefs
-❌ Only mapping primary user journeys and missing secondary users
-❌ Creating generic journeys without rich persona details and narrative
-❌ Missing emotional storytelling elements that make journeys compelling
-❌ Missing critical decision points and failure scenarios
-❌ Not connecting journeys to required capabilities
-❌ Not having enough journey diversity (admin, support, API, etc.)
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## JOURNEY TYPES TO ENSURE:
-
-**Minimum Coverage:**
-
-1. **Primary User - Success Path**: Core experience journey
-2. **Primary User - Edge Case**: Error recovery, alternative goals
-3. **Admin/Operations User**: Management, configuration, monitoring
-4. **Support/Troubleshooting**: Help, investigation, issue resolution
-5. **API/Integration** (if applicable): Developer/technical user journey
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-05-domain.md`.
-
-Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-05-domain.md b/.claude/skills/bmad-create-prd/steps-c/step-05-domain.md
deleted file mode 100644
index 07fe2a6..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-05-domain.md
+++ /dev/null
@@ -1,194 +0,0 @@
-# Step 5: Domain-Specific Requirements (Optional)
-
-**Progress: Step 5 of 13** - Next: Innovation Focus
-
-## STEP GOAL:
-
-For complex domains only that have a mapping in ../data/domain-complexity.csv, explore domain-specific constraints, compliance requirements, and technical considerations that shape the product.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product-focused PM facilitator collaborating with an expert peer
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise
-
-### Step-Specific Rules:
-
-- 🎯 This step is OPTIONAL - only needed for complex domains
-- 🚫 SKIP if domain complexity is "low" from step-02
-- 💬 APPROACH: Natural conversation to discover domain-specific needs
-- 🎯 Focus on constraints, compliance, and domain patterns
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Check domain complexity from step-02 classification first
-- ⚠️ If complexity is "low", offer to skip this step
-- ⚠️ Present A/P/C menu after domain requirements defined (or skipped)
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Domain classification from step-02 is available
-- If complexity is low, this step may be skipped
-- Domain CSV data provides complexity reference
-- Focus on domain-specific constraints, not general requirements
-
-## YOUR TASK:
-
-For complex domains, explore what makes this domain special:
-- **Compliance requirements** - regulations, standards, certifications
-- **Technical constraints** - security, privacy, integration requirements
-- **Domain patterns** - common patterns, best practices, anti-patterns
-- **Risks and mitigations** - what could go wrong, how to prevent it
-
-## DOMAIN DISCOVERY SEQUENCE:
-
-### 1. Check Domain Complexity
-
-**Review classification from step-02:**
-
-- What's the domain complexity level? (low/medium/high)
-- What's the specific domain? (healthcare, fintech, education, etc.)
-
-**If complexity is LOW:**
-
-Offer to skip:
-"The domain complexity from our discovery is low. We may not need deep domain-specific requirements. Would you like to:
-- [C] Skip this step and move to Innovation
-- [D] Do domain exploration anyway"
-
-**If complexity is MEDIUM or HIGH:**
-
-Proceed with domain exploration.
-
-### 2. Load Domain Reference Data
-
-**Attempt subprocess data lookup:**
-
-"Your task: Lookup data in ../data/domain-complexity.csv
-
-**Search criteria:**
-- Find row where domain matches {{domainFromStep02}}
-
-**Return format:**
-Return ONLY the matching row as a YAML-formatted object with these fields:
-domain, complexity, typical_concerns, compliance_requirements
-
-**Do NOT return the entire CSV - only the matching row.**"
-
-**Graceful degradation (if Task tool unavailable):**
-- Load the CSV file directly
-- Find the matching row manually
-- Extract required fields
-- Understand typical concerns and compliance requirements
-
-### 3. Explore Domain-Specific Concerns
-
-**Start with what you know:**
-
-Acknowledge the domain and explore what makes it complex:
-- What regulations apply? (HIPAA, PCI-DSS, GDPR, SOX, etc.)
-- What standards matter? (ISO, NIST, domain-specific standards)
-- What certifications are needed? (security, privacy, domain-specific)
-- What integrations are required? (EMR systems, payment processors, etc.)
-
-**Explore technical constraints:**
-- Security requirements (encryption, audit logs, access control)
-- Privacy requirements (data handling, consent, retention)
-- Performance requirements (real-time, batch, latency)
-- Availability requirements (uptime, disaster recovery)
-
-### 4. Document Domain Requirements
-
-**Structure the requirements around key concerns:**
-
-```markdown
-### Compliance & Regulatory
-- [Specific requirements]
-
-### Technical Constraints
-- [Security, privacy, performance needs]
-
-### Integration Requirements
-- [Required systems and data flows]
-
-### Risk Mitigations
-- [Domain-specific risks and how to address them]
-```
-
-### 5. Validate Completeness
-
-**Check with the user:**
-
-"Are there other domain-specific concerns we should consider? For [this domain], what typically gets overlooked?"
-
-### N. Present MENU OPTIONS
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue - Save and Proceed to Innovation (Step 6 of 13)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill, and when finished redisplay the menu
-- IF P: Invoke the `bmad-party-mode` skill, and when finished redisplay the menu
-- IF C: Save content to {outputFile}, update frontmatter, then read fully and follow: ./step-06-innovation.md
-- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#n-present-menu-options)
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT
-
-When user selects 'C', append to `{outputFile}`:
-
-```markdown
-## Domain-Specific Requirements
-
-{{discovered domain requirements}}
-```
-
-If step was skipped, append nothing and proceed.
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN [C continue option] is selected and [content saved or skipped], will you then read fully and follow: `./step-06-innovation.md` to explore innovation.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Domain complexity checked before proceeding
-- Offered to skip if complexity is low
-- Natural conversation exploring domain concerns
-- Compliance, technical, and integration requirements identified
-- Domain-specific risks documented with mitigations
-- User validated completeness
-- Content properly saved (or step skipped) when C selected
-
-### ❌ SYSTEM FAILURE:
-
-- Not checking domain complexity first
-- Not offering to skip for low-complexity domains
-- Missing critical compliance requirements
-- Not exploring technical constraints
-- Not asking about domain-specific risks
-- Being generic instead of domain-specific
-- Proceeding without user validation
-
-**Master Rule:** This step is OPTIONAL for simple domains. For complex domains, focus on compliance, constraints, and domain patterns. Natural conversation, not checklists.
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-06-innovation.md b/.claude/skills/bmad-create-prd/steps-c/step-06-innovation.md
deleted file mode 100644
index b12d68b..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-06-innovation.md
+++ /dev/null
@@ -1,211 +0,0 @@
-# Step 6: Innovation Discovery
-
-**Progress: Step 6 of 11** - Next: Project Type Analysis
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on detecting and exploring innovative aspects of the product
-- 🎯 OPTIONAL STEP: Only proceed if innovation signals are detected
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating innovation content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- Project type from step-02 is available for innovation signal matching
-- Project-type CSV data will be loaded in this step
-- Focus on detecting genuine innovation, not forced creativity
-
-## OPTIONAL STEP CHECK:
-
-Before proceeding with this step, scan for innovation signals:
-
-- Listen for language like "nothing like this exists", "rethinking how X works"
-- Check for project-type innovation signals from CSV
-- Look for novel approaches or unique combinations
-- If no innovation detected, skip this step
-
-## YOUR TASK:
-
-Detect and explore innovation patterns in the product, focusing on what makes it truly novel and how to validate the innovative aspects.
-
-## INNOVATION DISCOVERY SEQUENCE:
-
-### 1. Load Project-Type Innovation Data
-
-Load innovation signals specific to this project type:
-
-- Load `../data/project-types.csv` completely
-- Find the row where `project_type` matches detected type from step-02
-- Extract `innovation_signals` (semicolon-separated list)
-- Extract `web_search_triggers` for potential innovation research
-
-### 2. Listen for Innovation Indicators
-
-Monitor conversation for both general and project-type-specific innovation signals:
-
-#### General Innovation Language:
-
-- "Nothing like this exists"
-- "We're rethinking how [X] works"
-- "Combining [A] with [B] for the first time"
-- "Novel approach to [problem]"
-- "No one has done [concept] before"
-
-#### Project-Type-Specific Signals (from CSV):
-
-Match user descriptions against innovation_signals for their project_type:
-
-- **api_backend**: "API composition;New protocol"
-- **mobile_app**: "Gesture innovation;AR/VR features"
-- **saas_b2b**: "Workflow automation;AI agents"
-- **developer_tool**: "New paradigm;DSL creation"
-
-### 3. Initial Innovation Screening
-
-Ask targeted innovation discovery questions:
-- Guide exploration of what makes the product innovative
-- Explore if they're challenging existing assumptions
-- Ask about novel combinations of technologies/approaches
-- Identify what hasn't been done before
-- Understand which aspects feel most innovative
-
-### 4. Deep Innovation Exploration (If Detected)
-
-If innovation signals are found, explore deeply:
-
-#### Innovation Discovery Questions:
-- What makes it unique compared to existing solutions?
-- What assumption are you challenging?
-- How do we validate it works?
-- What's the fallback if it doesn't?
-- Has anyone tried this before?
-
-#### Market Context Research:
-
-If relevant innovation detected, consider web search for context:
-Use `web_search_triggers` from project-type CSV:
-`[web_search_triggers] {concept} innovations {date}`
-
-### 5. Generate Innovation Content (If Innovation Detected)
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## Innovation & Novel Patterns
-
-### Detected Innovation Areas
-
-[Innovation patterns identified based on conversation]
-
-### Market Context & Competitive Landscape
-
-[Market context and research based on conversation]
-
-### Validation Approach
-
-[Validation methodology based on conversation]
-
-### Risk Mitigation
-
-[Innovation risks and fallbacks based on conversation]
-```
-
-### 6. Present MENU OPTIONS (Only if Innovation Detected)
-
-Present the innovation content for review, then display menu:
-- Show identified innovative aspects (using structure from section 5)
-- Highlight differentiation from existing solutions
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of conversation
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Project Type Analysis (Step 7 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the current innovation content, process the enhanced innovation insights that come back, ask user "Accept these improvements to the innovation analysis? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the current innovation content, process the collaborative innovation exploration and ideation, ask user "Accept these changes to the innovation analysis? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-07-project-type.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## NO INNOVATION DETECTED:
-
-If no genuine innovation signals are found after exploration:
-- Acknowledge that no clear innovation signals were found
-- Note this is fine - many successful products are excellent executions of existing concepts
-- Ask if they'd like to try finding innovative angles or proceed
-
-Display: "**Select:** [A] Advanced Elicitation - Let's try to find innovative angles [C] Continue - Skip innovation section and move to Project Type Analysis (Step 7 of 11)"
-
-### Menu Handling Logic:
-- IF A: Proceed with content generation anyway, then return to menu
-- IF C: Skip this step, then read fully and follow: ./step-07-project-type.md
-
-### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 5.
-
-## SUCCESS METRICS:
-
-✅ Innovation signals properly detected from user conversation
-✅ Project-type innovation signals used to guide discovery
-✅ Genuine innovation explored (not forced creativity)
-✅ Validation approach clearly defined for innovative aspects
-✅ Risk mitigation strategies identified
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Forced innovation when none genuinely exists
-❌ Not using project-type innovation signals from CSV
-❌ Missing market context research for novel concepts
-❌ Not addressing validation approach for innovative features
-❌ Creating innovation theater without real innovative aspects
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## SKIP CONDITIONS:
-
-Skip this step and load `./step-07-project-type.md` if:
-
-- No innovation signals detected in conversation
-- Product is incremental improvement rather than breakthrough
-- User confirms innovation exploration is not needed
-- Project-type CSV has no innovation signals for this type
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document (or step is skipped), load `./step-07-project-type.md`.
-
-Remember: Do NOT proceed to step-07 until user explicitly selects 'C' from the A/P/C menu (or confirms step skip)!
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-07-project-type.md b/.claude/skills/bmad-create-prd/steps-c/step-07-project-type.md
deleted file mode 100644
index ea2b9b3..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-07-project-type.md
+++ /dev/null
@@ -1,222 +0,0 @@
-# Step 7: Project-Type Deep Dive
-
-**Progress: Step 7 of 11** - Next: Scoping
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on project-type specific requirements and technical considerations
-- 🎯 DATA-DRIVEN: Use CSV configuration to guide discovery
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating project-type content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- Project type from step-02 is available for configuration loading
-- Project-type CSV data will be loaded in this step
-- Focus on technical and functional requirements specific to this project type
-
-## YOUR TASK:
-
-Conduct project-type specific discovery using CSV-driven guidance to define technical requirements.
-
-## PROJECT-TYPE DISCOVERY SEQUENCE:
-
-### 1. Load Project-Type Configuration Data
-
-**Attempt subprocess data lookup:**
-
-"Your task: Lookup data in ../data/project-types.csv
-
-**Search criteria:**
-- Find row where project_type matches {{projectTypeFromStep02}}
-
-**Return format:**
-Return ONLY the matching row as a YAML-formatted object with these fields:
-project_type, key_questions, required_sections, skip_sections, innovation_signals
-
-**Do NOT return the entire CSV - only the matching row.**"
-
-**Graceful degradation (if Task tool unavailable):**
-- Load the CSV file directly
-- Find the matching row manually
-- Extract required fields:
-  - `key_questions` (semicolon-separated list of discovery questions)
-  - `required_sections` (semicolon-separated list of sections to document)
-  - `skip_sections` (semicolon-separated list of sections to skip)
-  - `innovation_signals` (already explored in step-6)
-
-### 2. Conduct Guided Discovery Using Key Questions
-
-Parse `key_questions` from CSV and explore each:
-
-#### Question-Based Discovery:
-
-For each question in `key_questions` from CSV:
-
-- Ask the user naturally in conversational style
-- Listen for their response and ask clarifying follow-ups
-- Connect answers to product value proposition
-
-**Example Flow:**
-If key_questions = "Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?"
-
-Ask naturally:
-
-- "What are the main endpoints your API needs to expose?"
-- "How will you handle authentication and authorization?"
-- "What data formats will you support for requests and responses?"
-
-### 3. Document Project-Type Specific Requirements
-
-Based on user answers to key_questions, synthesize comprehensive requirements:
-
-#### Requirement Categories:
-
-Cover the areas indicated by `required_sections` from CSV:
-
-- Synthesize what was discovered for each required section
-- Document specific requirements, constraints, and decisions
-- Connect to product differentiator when relevant
-
-#### Skip Irrelevant Sections:
-
-Skip areas indicated by `skip_sections` from CSV to avoid wasting time on irrelevant aspects.
-
-### 4. Generate Dynamic Content Sections
-
-Parse `required_sections` list from the matched CSV row. For each section name, generate corresponding content:
-
-#### Common CSV Section Mappings:
-
-- "endpoint_specs" or "endpoint_specification" → API endpoints documentation
-- "auth_model" or "authentication_model" → Authentication approach
-- "platform_reqs" or "platform_requirements" → Platform support needs
-- "device_permissions" or "device_features" → Device capabilities
-- "tenant_model" → Multi-tenancy approach
-- "rbac_matrix" or "permission_matrix" → Permission structure
-
-#### Template Variable Strategy:
-
-- For sections matching common template variables: generate specific content
-- For sections without template matches: include in main project_type_requirements
-- Hybrid approach balances template structure with CSV-driven flexibility
-
-### 5. Generate Project-Type Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## [Project Type] Specific Requirements
-
-### Project-Type Overview
-
-[Project type summary based on conversation]
-
-### Technical Architecture Considerations
-
-[Technical architecture requirements based on conversation]
-
-[Dynamic sections based on CSV and conversation]
-
-### Implementation Considerations
-
-[Implementation specific requirements based on conversation]
-```
-
-### 6. Present MENU OPTIONS
-
-Present the project-type content for review, then display menu:
-
-"Based on our conversation and best practices for this product type, I've documented the {project_type}-specific requirements for {{project_name}}.
-
-**Here's what I'll add to the document:**
-
-[Show the complete markdown content from section 5]
-
-**What would you like to do?**"
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Scoping (Step 8 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the current project-type content, process the enhanced technical insights that come back, ask user "Accept these improvements to the technical requirements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the current project-type requirements, process the collaborative technical expertise and validation, ask user "Accept these changes to the technical requirements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-08-scoping.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from previous steps.
-
-## SUCCESS METRICS:
-
-✅ Project-type configuration loaded and used effectively
-✅ All key questions from CSV explored with user input
-✅ Required sections generated per CSV configuration
-✅ Skip sections properly avoided to save time
-✅ Technical requirements connected to product value
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Not loading or using project-type CSV configuration
-❌ Missing key questions from CSV in discovery process
-❌ Not generating required sections per CSV configuration
-❌ Documenting sections that should be skipped per CSV
-❌ Creating generic content without project-type specificity
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## PROJECT-TYPE EXAMPLES:
-
-**For api_backend:**
-
-- Focus on endpoints, authentication, data schemas, rate limiting
-- Skip visual design and user journey sections
-- Generate API specification documentation
-
-**For mobile_app:**
-
-- Focus on platform requirements, device permissions, offline mode
-- Skip API endpoint documentation unless needed
-- Generate mobile-specific technical requirements
-
-**For saas_b2b:**
-
-- Focus on multi-tenancy, permissions, integrations
-- Skip mobile-first considerations unless relevant
-- Generate enterprise-specific requirements
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load `./step-08-scoping.md` to define project scope.
-
-Remember: Do NOT proceed to step-08 (Scoping) until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-08-scoping.md b/.claude/skills/bmad-create-prd/steps-c/step-08-scoping.md
deleted file mode 100644
index b060dda..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-08-scoping.md
+++ /dev/null
@@ -1,216 +0,0 @@
-# Step 8: Scoping Exercise - MVP & Future Features
-
-**Progress: Step 8 of 11** - Next: Functional Requirements
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on strategic scope decisions that keep projects viable
-- 🎯 EMPHASIZE lean MVP thinking while preserving long-term vision
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 📚 Review the complete PRD document built so far
-- ⚠️ Present A/P/C menu after generating scoping decisions
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-
-## CONTEXT BOUNDARIES:
-
-- Complete PRD document built so far is available for review
-- User journeys, success criteria, and domain requirements are documented
-- Focus on strategic scope decisions, not feature details
-- Balance between user value and implementation feasibility
-
-## YOUR TASK:
-
-Conduct comprehensive scoping exercise to define MVP boundaries and prioritize features across development phases.
-
-## SCOPING SEQUENCE:
-
-### 1. Review Current PRD State
-
-Analyze everything documented so far:
-- Present synthesis of established vision, success criteria, journeys
-- Assess domain and innovation focus
-- Evaluate scope implications: simple MVP, medium, or complex project
-- Ask if initial assessment feels right or if they see it differently
-
-### 2. Define MVP Strategy
-
-Facilitate strategic MVP decisions:
-- Explore MVP philosophy options: problem-solving, experience, platform, or revenue MVP
-- Ask critical questions:
-  - What's the minimum that would make users say 'this is useful'?
-  - What would make investors/partners say 'this has potential'?
-  - What's the fastest path to validated learning?
-- Guide toward appropriate MVP approach for their product
-
-### 3. Scoping Decision Framework
-
-Use structured decision-making for scope:
-
-**Must-Have Analysis:**
-- Guide identification of absolute MVP necessities
-- For each journey and success criterion, ask:
-  - Without this, does the product fail?
-  - Can this be manual initially?
-  - Is this a deal-breaker for early adopters?
-- Analyze journeys for MVP essentials
-
-**Nice-to-Have Analysis:**
-- Identify what could be added later:
-  - Features that enhance but aren't essential
-  - User types that can be added later
-  - Advanced functionality that builds on MVP
-- Ask what features could be added in versions 2, 3, etc.
-
-### 4. Progressive Feature Roadmap
-
-Create phased development approach:
-- Guide mapping of features across development phases
-- Structure as Phase 1 (MVP), Phase 2 (Growth), Phase 3 (Vision)
-- Ensure clear progression and dependencies
-
-- Core user value delivery
-- Essential user journeys
-- Basic functionality that works reliably
-
-**Phase 2: Growth**
-
-- Additional user types
-- Enhanced features
-- Scale improvements
-
-**Phase 3: Expansion**
-
-- Advanced capabilities
-- Platform features
-- New markets or use cases
-
-**Where does your current vision fit in this development sequence?**"
-
-### 5. Risk-Based Scoping
-
-Identify and mitigate scoping risks:
-
-**Technical Risks:**
-"Looking at your innovation and domain requirements:
-
-- What's the most technically challenging aspect?
-- Could we simplify the initial implementation?
-- What's the riskiest assumption about technology feasibility?"
-
-**Market Risks:**
-
-- What's the biggest market risk?
-- How does the MVP address this?
-- What learning do we need to de-risk this?"
-
-**Resource Risks:**
-
-- What if we have fewer resources than planned?
-- What's the absolute minimum team size needed?
-- Can we launch with a smaller feature set?"
-
-### 6. Generate Scoping Content
-
-Prepare comprehensive scoping section:
-
-#### Content Structure:
-
-```markdown
-## Project Scoping & Phased Development
-
-### MVP Strategy & Philosophy
-
-**MVP Approach:** {{chosen_mvp_approach}}
-**Resource Requirements:** {{mvp_team_size_and_skills}}
-
-### MVP Feature Set (Phase 1)
-
-**Core User Journeys Supported:**
-{{essential_journeys_for_mvp}}
-
-**Must-Have Capabilities:**
-{{list_of_essential_mvp_features}}
-
-### Post-MVP Features
-
-**Phase 2 (Post-MVP):**
-{{planned_growth_features}}
-
-**Phase 3 (Expansion):**
-{{planned_expansion_features}}
-
-### Risk Mitigation Strategy
-
-**Technical Risks:** {{mitigation_approach}}
-**Market Risks:** {{validation_approach}}
-**Resource Risks:** {{contingency_approach}}
-```
-
-### 7. Present MENU OPTIONS
-
-Present the scoping decisions for review, then display menu:
-- Show strategic scoping plan (using structure from step 6)
-- Highlight MVP boundaries and phased roadmap
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of conversation
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Functional Requirements (Step 9 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the current scoping analysis, process the enhanced insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the scoping context, process the collaborative insights on MVP and roadmap decisions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-09-functional.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 6.
-
-## SUCCESS METRICS:
-
-✅ Complete PRD document analyzed for scope implications
-✅ Strategic MVP approach defined and justified
-✅ Clear MVP feature boundaries established
-✅ Phased development roadmap created
-✅ Key risks identified and mitigation strategies defined
-✅ User explicitly agrees to scope decisions
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Not analyzing the complete PRD before making scoping decisions
-❌ Making scope decisions without strategic rationale
-❌ Not getting explicit user agreement on MVP boundaries
-❌ Missing critical risk analysis
-❌ Not creating clear phased development approach
-❌ Not presenting A/P/C menu after content generation
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load ./step-09-functional.md.
-
-Remember: Do NOT proceed to step-09 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-09-functional.md b/.claude/skills/bmad-create-prd/steps-c/step-09-functional.md
deleted file mode 100644
index 46f7a4a..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-09-functional.md
+++ /dev/null
@@ -1,219 +0,0 @@
-# Step 9: Functional Requirements Synthesis
-
-**Progress: Step 9 of 11** - Next: Non-Functional Requirements
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on creating comprehensive capability inventory for the product
-- 🎯 CRITICAL: This is THE CAPABILITY CONTRACT for all downstream work
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating functional requirements
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- ALL previous content (executive summary, success criteria, journeys, domain, innovation, project-type) must be referenced
-- No additional data files needed for this step
-- Focus on capabilities, not implementation details
-
-## CRITICAL IMPORTANCE:
-
-**This section defines THE CAPABILITY CONTRACT for the entire product:**
-
-- UX designers will ONLY design what's listed here
-- Architects will ONLY support what's listed here
-- Epic breakdown will ONLY implement what's listed here
-- If a capability is missing from FRs, it will NOT exist in the final product
-
-## FUNCTIONAL REQUIREMENTS SYNTHESIS SEQUENCE:
-
-### 1. Understand FR Purpose and Usage
-
-Start by explaining the critical role of functional requirements:
-
-**Purpose:**
-FRs define WHAT capabilities the product must have. They are the complete inventory of user-facing and system capabilities that deliver the product vision.
-
-**Critical Properties:**
-✅ Each FR is a testable capability
-✅ Each FR is implementation-agnostic (could be built many ways)
-✅ Each FR specifies WHO and WHAT, not HOW
-✅ No UI details, no performance numbers, no technology choices
-✅ Comprehensive coverage of capability areas
-
-**How They Will Be Used:**
-
-1. UX Designer reads FRs → designs interactions for each capability
-2. Architect reads FRs → designs systems to support each capability
-3. PM reads FRs → creates epics and stories to implement each capability
-
-### 2. Review Existing Content for Capability Extraction
-
-Systematically review all previous sections to extract capabilities:
-
-**Extract From:**
-
-- Executive Summary → Core product differentiator capabilities
-- Success Criteria → Success-enabling capabilities
-- User Journeys → Journey-revealed capabilities
-- Domain Requirements → Compliance and regulatory capabilities
-- Innovation Patterns → Innovative feature capabilities
-- Project-Type Requirements → Technical capability needs
-
-### 3. Organize Requirements by Capability Area
-
-Group FRs by logical capability areas (NOT by technology or layer):
-
-**Good Grouping Examples:**
-
-- ✅ "User Management" (not "Authentication System")
-- ✅ "Content Discovery" (not "Search Algorithm")
-- ✅ "Team Collaboration" (not "WebSocket Infrastructure")
-
-**Target 5-8 Capability Areas** for typical projects.
-
-### 4. Generate Comprehensive FR List
-
-Create complete functional requirements using this format:
-
-**Format:**
-
-- FR#: [Actor] can [capability] [context/constraint if needed]
-- Number sequentially (FR1, FR2, FR3...)
-- Aim for 20-50 FRs for typical projects
-
-**Altitude Check:**
-Each FR should answer "WHAT capability exists?" NOT "HOW it's implemented?"
-
-**Examples:**
-
-- ✅ "Users can customize appearance settings"
-- ❌ "Users can toggle light/dark theme with 3 font size options stored in LocalStorage"
-
-### 5. Self-Validation Process
-
-Before presenting to user, validate the FR list:
-
-**Completeness Check:**
-
-1. "Did I cover EVERY capability mentioned in the MVP scope section?"
-2. "Did I include domain-specific requirements as FRs?"
-3. "Did I cover the project-type specific needs?"
-4. "Could a UX designer read ONLY the FRs and know what to design?"
-5. "Could an Architect read ONLY the FRs and know what to support?"
-6. "Are there any user actions or system behaviors we discussed that have no FR?"
-
-**Altitude Check:**
-
-1. "Am I stating capabilities (WHAT) or implementation (HOW)?"
-2. "Am I listing acceptance criteria or UI specifics?" (Remove if yes)
-3. "Could this FR be implemented 5 different ways?" (Good - means it's not prescriptive)
-
-**Quality Check:**
-
-1. "Is each FR clear enough that someone could test whether it exists?"
-2. "Is each FR independent (not dependent on reading other FRs to understand)?"
-3. "Did I avoid vague terms like 'good', 'fast', 'easy'?" (Use NFRs for quality attributes)
-
-### 6. Generate Functional Requirements Content
-
-Prepare the content to append to the document:
-
-#### Content Structure:
-
-When saving to document, append these Level 2 and Level 3 sections:
-
-```markdown
-## Functional Requirements
-
-### [Capability Area Name]
-
-- FR1: [Specific Actor] can [specific capability]
-- FR2: [Specific Actor] can [specific capability]
-- FR3: [Specific Actor] can [specific capability]
-
-### [Another Capability Area]
-
-- FR4: [Specific Actor] can [specific capability]
-- FR5: [Specific Actor] can [specific capability]
-
-[Continue for all capability areas discovered in conversation]
-```
-
-### 7. Present MENU OPTIONS
-
-Present the functional requirements for review, then display menu:
-- Show synthesized functional requirements (using structure from step 6)
-- Emphasize this is the capability contract for all downstream work
-- Highlight that every feature must trace back to these requirements
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of conversation
-
-**What would you like to do?**"
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Non-Functional Requirements (Step 10 of 11)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the current FR list, process the enhanced capability coverage that comes back, ask user if they accept the additions, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the current FR list, process the collaborative capability validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-10-nonfunctional.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 6.
-
-## SUCCESS METRICS:
-
-✅ All previous discovery content synthesized into FRs
-✅ FRs organized by capability areas (not technology)
-✅ Each FR states WHAT capability exists, not HOW to implement
-✅ Comprehensive coverage with 20-50 FRs typical
-✅ Altitude validation ensures implementation-agnostic requirements
-✅ Completeness check validates coverage of all discussed capabilities
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Missing capabilities from previous discovery sections
-❌ Organizing FRs by technology instead of capability areas
-❌ Including implementation details or UI specifics in FRs
-❌ Not achieving comprehensive coverage of discussed capabilities
-❌ Using vague terms instead of testable capabilities
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## CAPABILITY CONTRACT REMINDER:
-
-Emphasize to user: "This FR list is now binding. Any feature not listed here will not exist in the final product unless we explicitly add it. This is why it's critical to ensure completeness now."
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load ./step-10-nonfunctional.md to define non-functional requirements.
-
-Remember: Do NOT proceed to step-10 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-10-nonfunctional.md b/.claude/skills/bmad-create-prd/steps-c/step-10-nonfunctional.md
deleted file mode 100644
index b00730a..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-10-nonfunctional.md
+++ /dev/null
@@ -1,230 +0,0 @@
-# Step 10: Non-Functional Requirements
-
-**Progress: Step 10 of 12** - Next: Polish Document
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ ALWAYS treat this as collaborative discovery between PM peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on quality attributes that matter for THIS specific product
-- 🎯 SELECTIVE: Only document NFRs that actually apply to the product
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present A/P/C menu after generating NFR content
-- 💾 ONLY save when user chooses C (Continue)
-- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
-- 🚫 FORBIDDEN to load next step until C is selected
-
-
-## CONTEXT BOUNDARIES:
-
-- Current document and frontmatter from previous steps are available
-- Functional requirements already defined and will inform NFRs
-- Domain and project-type context will guide which NFRs matter
-- Focus on specific, measurable quality criteria
-
-## YOUR TASK:
-
-Define non-functional requirements that specify quality attributes for the product, focusing only on what matters for THIS specific product.
-
-## NON-FUNCTIONAL REQUIREMENTS SEQUENCE:
-
-### 1. Explain NFR Purpose and Scope
-
-Start by clarifying what NFRs are and why we're selective:
-
-**NFR Purpose:**
-NFRs define HOW WELL the system must perform, not WHAT it must do. They specify quality attributes like performance, security, scalability, etc.
-
-**Selective Approach:**
-We only document NFRs that matter for THIS product. If a category doesn't apply, we skip it entirely. This prevents requirement bloat and focuses on what's actually important.
-
-### 2. Assess Product Context for NFR Relevance
-
-Evaluate which NFR categories matter based on product context:
-
-**Quick Assessment Questions:**
-
-- **Performance**: Is there user-facing impact of speed?
-- **Security**: Are we handling sensitive data or payments?
-- **Scalability**: Do we expect rapid user growth?
-- **Accessibility**: Are we serving broad public audiences?
-- **Integration**: Do we need to connect with other systems?
-- **Reliability**: Would downtime cause significant problems?
-
-### 3. Explore Relevant NFR Categories
-
-For each relevant category, conduct targeted discovery:
-
-#### Performance NFRs (If relevant):
-
-Explore performance requirements:
-- What parts of the system need to be fast for users to be successful?
-- Are there specific response time expectations?
-- What happens if performance is slower than expected?
-- Are there concurrent user scenarios we need to support?
-
-#### Security NFRs (If relevant):
-
-Explore security requirements:
-- What data needs to be protected?
-- Who should have access to what?
-- What are the security risks we need to mitigate?
-- Are there compliance requirements (GDPR, HIPAA, PCI-DSS)?
-
-#### Scalability NFRs (If relevant):
-
-Explore scalability requirements:
-- How many users do we expect initially? Long-term?
-- Are there seasonal or event-based traffic spikes?
-- What happens if we exceed our capacity?
-- What growth scenarios should we plan for?
-
-#### Accessibility NFRs (If relevant):
-
-Explore accessibility requirements:
-- Are we serving users with visual, hearing, or motor impairments?
-- Are there legal accessibility requirements (WCAG, Section 508)?
-- What accessibility features are most important for our users?
-
-#### Integration NFRs (If relevant):
-
-Explore integration requirements:
-- What external systems do we need to connect with?
-- Are there APIs or data formats we must support?
-- How reliable do these integrations need to be?
-
-### 4. Make NFRs Specific and Measurable
-
-For each relevant NFR category, ensure criteria are testable:
-
-**From Vague to Specific:**
-
-- NOT: "The system should be fast" → "User actions complete within 2 seconds"
-- NOT: "The system should be secure" → "All data is encrypted at rest and in transit"
-- NOT: "The system should scale" → "System supports 10x user growth with <10% performance degradation"
-
-### 5. Generate NFR Content (Only Relevant Categories)
-
-Prepare the content to append to the document:
-
-#### Content Structure (Dynamic based on relevance):
-
-When saving to document, append these Level 2 and Level 3 sections (only include sections that are relevant):
-
-```markdown
-## Non-Functional Requirements
-
-### Performance
-
-[Performance requirements based on conversation - only include if relevant]
-
-### Security
-
-[Security requirements based on conversation - only include if relevant]
-
-### Scalability
-
-[Scalability requirements based on conversation - only include if relevant]
-
-### Accessibility
-
-[Accessibility requirements based on conversation - only include if relevant]
-
-### Integration
-
-[Integration requirements based on conversation - only include if relevant]
-```
-
-### 6. Present MENU OPTIONS
-
-Present the non-functional requirements for review, then display menu:
-- Show defined NFRs (using structure from step 5)
-- Note that only relevant categories were included
-- Emphasize NFRs specify how well the system needs to perform
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of conversation
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Polish Document (Step 11 of 12)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the current NFR content, process the enhanced quality attribute insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the current NFR list, process the collaborative technical validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-11-polish.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append the content directly to the document using the structure from step 5.
-
-## SUCCESS METRICS:
-
-✅ Only relevant NFR categories documented (no requirement bloat)
-✅ Each NFR is specific and measurable
-✅ NFRs connected to actual user needs and business context
-✅ Vague requirements converted to testable criteria
-✅ Domain-specific compliance requirements included if relevant
-✅ A/P/C menu presented and handled correctly
-✅ Content properly appended to document when C selected
-
-## FAILURE MODES:
-
-❌ Documenting NFR categories that don't apply to the product
-❌ Leaving requirements vague and unmeasurable
-❌ Not connecting NFRs to actual user or business needs
-❌ Missing domain-specific compliance requirements
-❌ Creating overly prescriptive technical requirements
-❌ Not presenting A/P/C menu after content generation
-❌ Appending content without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NFR CATEGORY GUIDANCE:
-
-**Include Performance When:**
-
-- User-facing response times impact success
-- Real-time interactions are critical
-- Performance is a competitive differentiator
-
-**Include Security When:**
-
-- Handling sensitive user data
-- Processing payments or financial information
-- Subject to compliance regulations
-- Protecting intellectual property
-
-**Include Scalability When:**
-
-- Expecting rapid user growth
-- Handling variable traffic patterns
-- Supporting enterprise-scale usage
-- Planning for market expansion
-
-**Include Accessibility When:**
-
-- Serving broad public audiences
-- Subject to accessibility regulations
-- Targeting users with disabilities
-- B2B customers with accessibility requirements
-
-## NEXT STEP:
-
-After user selects 'C' and content is saved to document, load ./step-11-polish.md to finalize the PRD and complete the workflow.
-
-Remember: Do NOT proceed to step-11 until user explicitly selects 'C' from the A/P/C menu and content is saved!
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-11-polish.md b/.claude/skills/bmad-create-prd/steps-c/step-11-polish.md
deleted file mode 100644
index c63ae5b..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-11-polish.md
+++ /dev/null
@@ -1,221 +0,0 @@
-# Step 11: Document Polish
-
-**Progress: Step 11 of 12** - Next: Complete PRD
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 CRITICAL: Load the ENTIRE document before making changes
-- 📖 CRITICAL: Read complete step file before taking action
-- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
-- ✅ This is a POLISH step - optimize existing content
-- 📋 IMPROVE flow, coherence, and readability
-- 💬 PRESERVE user's voice and intent
-- 🎯 MAINTAIN all essential information while improving presentation
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Load complete document first
-- 📝 Review for flow and coherence issues
-- ✂️ Reduce duplication while preserving essential info
-- 📖 Ensure proper ## Level 2 headers throughout
-- 💾 Save optimized document
-- ⚠️ Present A/P/C menu after polish
-- 🚫 DO NOT skip review steps
-
-## CONTEXT BOUNDARIES:
-
-- Complete PRD document exists from all previous steps
-- Document may have duplication from progressive append
-- Sections may not flow smoothly together
-- Level 2 headers ensure document can be split if needed
-- Focus on readability and coherence
-
-## YOUR TASK:
-
-Optimize the complete PRD document for flow, coherence, and professional presentation while preserving all essential information.
-
-## DOCUMENT POLISH SEQUENCE:
-
-### 1. Load Context and Document
-
-**CRITICAL:** Load the PRD purpose document first:
-
-- Read `../data/prd-purpose.md` to understand what makes a great BMAD PRD
-- Internalize the philosophy: information density, traceability, measurable requirements
-- Keep the dual-audience nature (humans + LLMs) in mind
-
-**Then Load the PRD Document:**
-
-- Read `{outputFile}` completely from start to finish
-- Understand the full document structure and content
-- Identify all sections and their relationships
-- Note areas that need attention
-
-### 2. Document Quality Review
-
-Review the entire document with PRD purpose principles in mind:
-
-**Information Density:**
-- Are there wordy phrases that can be condensed?
-- Is conversational padding present?
-- Can sentences be more direct and concise?
-
-**Flow and Coherence:**
-- Do sections transition smoothly?
-- Are there jarring topic shifts?
-- Does the document tell a cohesive story?
-- Is the progression logical for readers?
-
-**Duplication Detection:**
-- Are ideas repeated across sections?
-- Is the same information stated multiple times?
-- Can redundant content be consolidated?
-- Are there contradictory statements?
-
-**Header Structure:**
-- Are all main sections using ## Level 2 headers?
-- Is the hierarchy consistent (##, ###, ####)?
-- Can sections be easily extracted or referenced?
-- Are headers descriptive and clear?
-
-**Readability:**
-- Are sentences clear and concise?
-- Is the language consistent throughout?
-- Are technical terms used appropriately?
-- Would stakeholders find this easy to understand?
-
-### 2b. Brainstorming Reconciliation (if brainstorming input exists)
-
-**Check the PRD frontmatter `inputDocuments` for any brainstorming document** (e.g., `brainstorming-session*.md`, `brainstorming-report.md`). If a brainstorming document was used as input:
-
-1. **Load the brainstorming document** and extract all distinct ideas, themes, and recommendations
-2. **Cross-reference against the PRD** — for each brainstorming idea, check if it landed in any PRD section (requirements, success criteria, user journeys, scope, etc.)
-3. **Identify dropped ideas** — ideas from brainstorming that do not appear anywhere in the PRD. Pay special attention to:
-   - Tone, personality, and interaction design ideas (these are most commonly lost)
-   - Design philosophy and coaching approach ideas
-   - "What should this feel like" ideas (UX feel, not just UX function)
-   - Qualitative/soft ideas that don't map cleanly to functional requirements
-4. **Present findings to user**: "These brainstorming ideas did not make it into the PRD: [list]. Should any be incorporated?"
-5. **If user wants to incorporate dropped ideas**: Add them to the most appropriate PRD section (success criteria, non-functional requirements, or a new section if needed)
-
-**Why this matters**: Brainstorming documents are often long, and the PRD's structured template has an implicit bias toward concrete/structural ideas. Soft ideas (tone, philosophy, interaction feel) frequently get silently dropped because they don't map cleanly to FR/NFR format.
-
-### 3. Optimization Actions
-
-Make targeted improvements:
-
-**Improve Flow:**
-- Add transition sentences between sections
-- Smooth out jarring topic shifts
-- Ensure logical progression
-- Connect related concepts across sections
-
-**Reduce Duplication:**
-- Consolidate repeated information
-- Keep content in the most appropriate section
-- Use cross-references instead of repetition
-- Remove redundant explanations
-
-**Enhance Coherence:**
-- Ensure consistent terminology throughout
-- Align all sections with product differentiator
-- Maintain consistent voice and tone
-- Verify scope consistency across sections
-
-**Optimize Headers:**
-- Ensure all main sections use ## Level 2
-- Make headers descriptive and action-oriented
-- Check that headers follow consistent patterns
-- Verify headers support document navigation
-
-### 4. Preserve Critical Information
-
-**While optimizing, ensure NOTHING essential is lost:**
-
-**Must Preserve:**
-- All user success criteria
-- All functional requirements (capability contract)
-- All user journey narratives
-- All scope decisions (MVP, Growth, Vision)
-- All non-functional requirements
-- Product differentiator and vision
-- Domain-specific requirements
-- Innovation analysis (if present)
-
-**Can Consolidate:**
-- Repeated explanations of the same concept
-- Redundant background information
-- Multiple versions of similar content
-- Overlapping examples
-
-### 5. Generate Optimized Document
-
-Create the polished version:
-
-**Polishing Process:**
-1. Start with original document
-2. Apply all optimization actions
-3. Review to ensure nothing essential was lost
-4. Verify improvements enhance readability
-5. Prepare optimized version for review
-
-### 6. Present MENU OPTIONS
-
-Present the polished document for review, then display menu:
-- Show what changed in the polish
-- Highlight improvements made (flow, duplication, headers)
-- Ask if they'd like to refine further, get other perspectives, or proceed
-- Present menu options naturally as part of conversation
-
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Complete PRD (Step 12 of 12)"
-
-#### Menu Handling Logic:
-- IF A: Invoke the `bmad-advanced-elicitation` skill with the polished document, process the enhanced refinements that come back, ask user "Accept these polish improvements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
-- IF P: Invoke the `bmad-party-mode` skill with the polished document, process the collaborative refinements to flow and coherence, ask user "Accept these polish changes? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
-- IF C: Save the polished document to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-12-complete.md
-- IF Any other: help user respond, then redisplay menu
-
-#### EXECUTION RULES:
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution, return to this menu
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', replace the entire document content with the polished version.
-
-## SUCCESS METRICS:
-
-✅ Complete document loaded and reviewed
-✅ Flow and coherence improved
-✅ Duplication reduced while preserving essential information
-✅ All main sections use ## Level 2 headers
-✅ Transitions between sections are smooth
-✅ User's voice and intent preserved
-✅ Document is more readable and professional
-✅ A/P/C menu presented and handled correctly
-✅ Brainstorming reconciliation completed (if brainstorming input exists)
-✅ Polished document saved when C selected
-
-## FAILURE MODES:
-
-❌ Loading only partial document (leads to incomplete polish)
-❌ Removing essential information while reducing duplication
-❌ Not preserving user's voice and intent
-❌ Changing content instead of improving presentation
-❌ Not ensuring ## Level 2 headers for main sections
-❌ Making arbitrary style changes instead of coherence improvements
-❌ Not presenting A/P/C menu for user approval
-❌ Saving polished document without user selecting 'C'
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making changes without complete understanding of document requirements
-
-## NEXT STEP:
-
-After user selects 'C' and polished document is saved, load `./step-12-complete.md` to complete the workflow.
-
-Remember: Do NOT proceed to step-12 until user explicitly selects 'C' from the A/P/C menu and polished document is saved!
diff --git a/.claude/skills/bmad-create-prd/steps-c/step-12-complete.md b/.claude/skills/bmad-create-prd/steps-c/step-12-complete.md
deleted file mode 100644
index d7b6525..0000000
--- a/.claude/skills/bmad-create-prd/steps-c/step-12-complete.md
+++ /dev/null
@@ -1,115 +0,0 @@
-# Step 12: Workflow Completion
-
-**Final Step - Complete the PRD**
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- ✅ THIS IS A FINAL STEP - Workflow completion required
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
-- 🛑 NO content generation - this is a wrap-up step
-- 📋 FINALIZE document and update workflow status
-- 💬 FOCUS on completion, validation options, and next steps
-- 🎯 UPDATE workflow status files with completion information
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 💾 Update the main workflow status file with completion information (if exists)
-- 📖 Offer validation workflow options to user
-- 🚫 DO NOT load additional steps after this one
-
-## TERMINATION STEP PROTOCOLS:
-
-- This is a FINAL step - workflow completion required
-- Update workflow status file with finalized document
-- Suggest validation and next workflow steps
-- Mark workflow as complete in status tracking
-
-## CONTEXT BOUNDARIES:
-
-- Complete and polished PRD document is available from all previous steps
-- Workflow frontmatter shows all completed steps including polish
-- All collaborative content has been generated, saved, and optimized
-- Focus on completion, validation options, and next steps
-
-## YOUR TASK:
-
-Complete the PRD workflow, update status files, offer validation options, and suggest next steps for the project.
-
-## WORKFLOW COMPLETION SEQUENCE:
-
-### 1. Announce Workflow Completion
-
-Inform user that the PRD is complete and polished:
-- Celebrate successful completion of comprehensive PRD
-- Summarize all sections that were created
-- Highlight that document has been polished for flow and coherence
-- Emphasize document is ready for downstream work
-
-### 2. Workflow Status Update
-
-Update the main workflow status file if there is one:
-
-- Check workflow configuration for a status file (if one exists)
-- Update workflow_status["prd"] = "{outputFile}"
-- Save file, preserving all comments and structure
-- Mark current timestamp as completion time
-
-### 3. Validation Workflow Options
-
-Offer validation workflows to ensure PRD is ready for implementation:
-
-**Available Validation Workflows:**
-
-**Option 1: Check Implementation Readiness** (`skill:bmad-check-implementation-readiness`)
-- Validates PRD has all information needed for development
-- Checks epic coverage completeness
-- Reviews UX alignment with requirements
-- Assesses epic quality and readiness
-- Identifies gaps before architecture/design work begins
-
-**When to use:** Before starting technical architecture or epic breakdown
-
-**Option 2: Skip for Now**
-- Proceed directly to next workflows (architecture, UX, epics)
-- Validation can be done later if needed
-- Some teams prefer to validate during architecture reviews
-
-### 4. Suggest Next Workflows
-
-PRD complete. Invoke the `bmad-help` skill.
-
-### 5. Final Completion Confirmation
-
-- Confirm completion with user and summarize what has been accomplished
-- Document now contains: Executive Summary, Success Criteria, User Journeys, Domain Requirements (if applicable), Innovation Analysis (if applicable), Project-Type Requirements, Functional Requirements (capability contract), Non-Functional Requirements, and has been polished for flow and coherence
-- Ask if they'd like to run validation workflow or proceed to next workflows
-
-## SUCCESS METRICS:
-
-✅ PRD document contains all required sections and has been polished
-✅ All collaborative content properly saved and optimized
-✅ Workflow status file updated with completion information (if exists)
-✅ Validation workflow options clearly presented
-✅ Clear next step guidance provided to user
-✅ Document quality validation completed
-✅ User acknowledges completion and understands next options
-
-## FAILURE MODES:
-
-❌ Not updating workflow status file with completion information (if exists)
-❌ Not offering validation workflow options
-❌ Missing clear next step guidance for user
-❌ Not confirming document completeness with user
-❌ Workflow not properly marked as complete in status tracking (if applicable)
-❌ User unclear about what happens next or what validation options exist
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## FINAL REMINDER to give the user:
-
-The polished PRD serves as the foundation for all subsequent product development activities. All design, architecture, and development work should trace back to the requirements and vision documented in this PRD - update it also as needed as you continue planning.
-
-**Congratulations on completing the Product Requirements Document for {{project_name}}!** 🎉
diff --git a/.claude/skills/bmad-create-prd/templates/prd-template.md b/.claude/skills/bmad-create-prd/templates/prd-template.md
deleted file mode 100644
index d82219d..0000000
--- a/.claude/skills/bmad-create-prd/templates/prd-template.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-stepsCompleted: []
-inputDocuments: []
-workflowType: 'prd'
----
-
-# Product Requirements Document - {{project_name}}
-
-**Author:** {{user_name}}
-**Date:** {{date}}
diff --git a/.claude/skills/bmad-create-prd/workflow.md b/.claude/skills/bmad-create-prd/workflow.md
deleted file mode 100644
index 70fbe7a..0000000
--- a/.claude/skills/bmad-create-prd/workflow.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-main_config: '{project-root}/_bmad/bmm/config.yaml'
-outputFile: '{planning_artifacts}/prd.md'
----
-
-# PRD Create Workflow
-
-**Goal:** Create comprehensive PRDs through structured workflow facilitation.
-
-**Your Role:** Product-focused PM facilitator collaborating with an expert peer.
-
-You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
-- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- 🛑 **NEVER** load multiple step files simultaneously
-- 📖 **ALWAYS** read entire step file before execution
-- 🚫 **NEVER** skip steps or optimize the sequence
-- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
-   - Use `{user_name}` for greeting
-   - Use `{communication_language}` for all communications
-   - Use `{document_output_language}` for output documents
-   - Use `{planning_artifacts}` for output location and artifact scanning
-   - Use `{project_knowledge}` for additional context scanning
-
-✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
-✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
-
-2. Route to Create Workflow
-
-"**Create Mode: Creating a new PRD from scratch.**"
-
-Read fully and follow: `./steps-c/step-01-init.md`
diff --git a/.claude/skills/bmad-create-story/SKILL.md b/.claude/skills/bmad-create-story/SKILL.md
deleted file mode 100644
index 66119b0..0000000
--- a/.claude/skills/bmad-create-story/SKILL.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-name: bmad-create-story
-description: 'Creates a dedicated story file with all the context the agent will need to implement it later. Use when the user says "create the next story" or "create story [story identifier]"'
----
-
-Follow the instructions in ./workflow.md.
diff --git a/.claude/skills/bmad-create-story/checklist.md b/.claude/skills/bmad-create-story/checklist.md
deleted file mode 100644
index e47cc0f..0000000
--- a/.claude/skills/bmad-create-story/checklist.md
+++ /dev/null
@@ -1,357 +0,0 @@
-# 🎯 Story Context Quality Competition Prompt
-
-## **🔥 CRITICAL MISSION: Outperform and Fix the Original Create-Story LLM**
-
-You are an independent quality validator in a **FRESH CONTEXT**. Your mission is to **thoroughly review** a story file that was generated by the create-story workflow and **systematically identify any mistakes, omissions, or disasters** that the original LLM missed.
-
-**Your purpose is NOT just to validate - it's to FIX and PREVENT LLM developer mistakes, omissions, or disasters!**
-
-### **🚨 CRITICAL MISTAKES TO PREVENT:**
-
-- **Reinventing wheels** - Creating duplicate functionality instead of reusing existing
-- **Wrong libraries** - Using incorrect frameworks, versions, or dependencies
-- **Wrong file locations** - Violating project structure and organization
-- **Breaking regressions** - Implementing changes that break existing functionality
-- **Ignoring UX** - Not following user experience design requirements
-- **Vague implementations** - Creating unclear, ambiguous implementations
-- **Lying about completion** - Implementing incorrectly or incompletely
-- **Not learning from past work** - Ignoring previous story learnings and patterns
-
-### **🚨 EXHAUSTIVE ANALYSIS REQUIRED:**
-
-You must thoroughly analyze **ALL artifacts** to extract critical context - do NOT be lazy or skim! This is the most important quality control function in the entire development process!
-
-### **🔬 UTILIZE SUBPROCESSES AND SUBAGENTS:**
-
-Use research subagents, subprocesses, or parallel processing if available to thoroughly analyze different artifacts **simultaneously and thoroughly**. Leave no stone unturned!
-
-### **🎯 COMPETITIVE EXCELLENCE:**
-
-This is a COMPETITION to create the **ULTIMATE story context** that makes LLM developer mistakes **IMPOSSIBLE**!
-
-## **🚀 HOW TO USE THIS CHECKLIST**
-
-### **When Running from Create-Story Workflow:**
-
-- The workflow framework will automatically:
-  - Load this checklist file
-  - Load the newly created story file (`{story_file_path}`)
-  - Load workflow variables from `./workflow.md`
-  - Execute the validation process
-
-### **When Running in Fresh Context:**
-
-- User should provide the story file path being reviewed
-- Load the story file directly
-- Load the corresponding workflow.md for variable context
-- Proceed with systematic analysis
-
-### **Required Inputs:**
-
-- **Story file**: The story file to review and improve
-- **Workflow variables**: From workflow.md (implementation_artifacts, epics_file, etc.)
-- **Source documents**: Epics, architecture, etc. (discovered or provided)
-- **Validation framework**: The workflow's checklist execution system
-
----
-
-## **🔬 SYSTEMATIC RE-ANALYSIS APPROACH**
-
-You will systematically re-do the entire story creation process, but with a critical eye for what the original LLM might have missed:
-
-### **Step 1: Load and Understand the Target**
-
-1. **Load the workflow configuration**: `./workflow.md` for variable inclusion
-2. **Load the story file**: `{story_file_path}` (provided by user or discovered)
-3. **Extract metadata**: epic_num, story_num, story_key, story_title from story file
-4. **Resolve all workflow variables**: implementation_artifacts, epics_file, architecture_file, etc.
-5. **Understand current status**: What story implementation guidance is currently provided?
-
-**Note:** If running in fresh context, user should provide the story file path being reviewed. If running from create-story workflow, the validation framework will automatically discover the checklist and story file.
-
-### **Step 2: Exhaustive Source Document Analysis**
-
-**🔥 CRITICAL: Treat this like YOU are creating the story from scratch to PREVENT DISASTERS!**
-**Discover everything the original LLM missed that could cause developer mistakes, omissions, or disasters!**
-
-#### **2.1 Epics and Stories Analysis**
-
-- Load `{epics_file}` (or sharded equivalents)
-- Extract **COMPLETE Epic {{epic_num}} context**:
-  - Epic objectives and business value
-  - ALL stories in this epic (for cross-story context)
-  - Our specific story's requirements, acceptance criteria
-  - Technical requirements and constraints
-  - Cross-story dependencies and prerequisites
-
-#### **2.2 Architecture Deep-Dive**
-
-- Load `{architecture_file}` (single or sharded)
-- **Systematically scan for ANYTHING relevant to this story:**
-  - Technical stack with versions (languages, frameworks, libraries)
-  - Code structure and organization patterns
-  - API design patterns and contracts
-  - Database schemas and relationships
-  - Security requirements and patterns
-  - Performance requirements and optimization strategies
-  - Testing standards and frameworks
-  - Deployment and environment patterns
-  - Integration patterns and external services
-
-#### **2.3 Previous Story Intelligence (if applicable)**
-
-- If `story_num > 1`, load the previous story file
-- Extract **actionable intelligence**:
-  - Dev notes and learnings
-  - Review feedback and corrections needed
-  - Files created/modified and their patterns
-  - Testing approaches that worked/didn't work
-  - Problems encountered and solutions found
-  - Code patterns and conventions established
-
-#### **2.4 Git History Analysis (if available)**
-
-- Analyze recent commits for patterns:
-  - Files created/modified in previous work
-  - Code patterns and conventions used
-  - Library dependencies added/changed
-  - Architecture decisions implemented
-  - Testing approaches used
-
-#### **2.5 Latest Technical Research**
-
-- Identify any libraries/frameworks mentioned
-- Research latest versions and critical information:
-  - Breaking changes or security updates
-  - Performance improvements or deprecations
-  - Best practices for current versions
-
-### **Step 3: Disaster Prevention Gap Analysis**
-
-**🚨 CRITICAL: Identify every mistake the original LLM missed that could cause DISASTERS!**
-
-#### **3.1 Reinvention Prevention Gaps**
-
-- **Wheel reinvention:** Areas where developer might create duplicate functionality
-- **Code reuse opportunities** not identified that could prevent redundant work
-- **Existing solutions** not mentioned that developer should extend instead of replace
-
-#### **3.2 Technical Specification DISASTERS**
-
-- **Wrong libraries/frameworks:** Missing version requirements that could cause compatibility issues
-- **API contract violations:** Missing endpoint specifications that could break integrations
-- **Database schema conflicts:** Missing requirements that could corrupt data
-- **Security vulnerabilities:** Missing security requirements that could expose the system
-- **Performance disasters:** Missing requirements that could cause system failures
-
-#### **3.3 File Structure DISASTERS**
-
-- **Wrong file locations:** Missing organization requirements that could break build processes
-- **Coding standard violations:** Missing conventions that could create inconsistent codebase
-- **Integration pattern breaks:** Missing data flow requirements that could cause system failures
-- **Deployment failures:** Missing environment requirements that could prevent deployment
-
-#### **3.4 Regression DISASTERS**
-
-- **Breaking changes:** Missing requirements that could break existing functionality
-- **Test failures:** Missing test requirements that could allow bugs to reach production
-- **UX violations:** Missing user experience requirements that could ruin the product
-- **Learning failures:** Missing previous story context that could repeat same mistakes
-
-#### **3.5 Implementation DISASTERS**
-
-- **Vague implementations:** Missing details that could lead to incorrect or incomplete work
-- **Completion lies:** Missing acceptance criteria that could allow fake implementations
-- **Scope creep:** Missing boundaries that could cause unnecessary work
-- **Quality failures:** Missing quality requirements that could deliver broken features
-
-### **Step 4: LLM-Dev-Agent Optimization Analysis**
-
-**CRITICAL STEP: Optimize story context for LLM developer agent consumption**
-
-**Analyze current story for LLM optimization issues:**
-
-- **Verbosity problems:** Excessive detail that wastes tokens without adding value
-- **Ambiguity issues:** Vague instructions that could lead to multiple interpretations
-- **Context overload:** Too much information not directly relevant to implementation
-- **Missing critical signals:** Key requirements buried in verbose text
-- **Poor structure:** Information not organized for efficient LLM processing
-
-**Apply LLM Optimization Principles:**
-
-- **Clarity over verbosity:** Be precise and direct, eliminate fluff
-- **Actionable instructions:** Every sentence should guide implementation
-- **Scannable structure:** Use clear headings, bullet points, and emphasis
-- **Token efficiency:** Pack maximum information into minimum text
-- **Unambiguous language:** Clear requirements with no room for interpretation
-
-### **Step 5: Improvement Recommendations**
-
-**For each gap identified, provide specific, actionable improvements:**
-
-#### **5.1 Critical Misses (Must Fix)**
-
-- Missing essential technical requirements
-- Missing previous story context that could cause errors
-- Missing anti-pattern prevention that could lead to duplicate code
-- Missing security or performance requirements
-
-#### **5.2 Enhancement Opportunities (Should Add)**
-
-- Additional architectural guidance that would help developer
-- More detailed technical specifications
-- Better code reuse opportunities
-- Enhanced testing guidance
-
-#### **5.3 Optimization Suggestions (Nice to Have)**
-
-- Performance optimization hints
-- Additional context for complex scenarios
-- Enhanced debugging or development tips
-
-#### **5.4 LLM Optimization Improvements**
-
-- Token-efficient phrasing of existing content
-- Clearer structure for LLM processing
-- More actionable and direct instructions
-- Reduced verbosity while maintaining completeness
-
----
-
-## **🎯 COMPETITION SUCCESS METRICS**
-
-**You WIN against the original LLM if you identify:**
-
-### **Category 1: Critical Misses (Blockers)**
-
-- Essential technical requirements the developer needs but aren't provided
-- Previous story learnings that would prevent errors if ignored
-- Anti-pattern prevention that would prevent code duplication
-- Security or performance requirements that must be followed
-
-### **Category 2: Enhancement Opportunities**
-
-- Architecture guidance that would significantly help implementation
-- Technical specifications that would prevent wrong approaches
-- Code reuse opportunities the developer should know about
-- Testing guidance that would improve quality
-
-### **Category 3: Optimization Insights**
-
-- Performance or efficiency improvements
-- Development workflow optimizations
-- Additional context for complex scenarios
-
----
-
-## **📋 INTERACTIVE IMPROVEMENT PROCESS**
-
-After completing your systematic analysis, present your findings to the user interactively:
-
-### **Step 5: Present Improvement Suggestions**
-
-```
-🎯 **STORY CONTEXT QUALITY REVIEW COMPLETE**
-
-**Story:** {{story_key}} - {{story_title}}
-
-I found {{critical_count}} critical issues, {{enhancement_count}} enhancements, and {{optimization_count}} optimizations.
-
-## **🚨 CRITICAL ISSUES (Must Fix)**
-
-{{list each critical issue with clear, actionable description}}
-
-## **⚡ ENHANCEMENT OPPORTUNITIES (Should Add)**
-
-{{list each enhancement with clear benefit description}}
-
-## **✨ OPTIMIZATIONS (Nice to Have)**
-
-{{list each optimization with benefit description}}
-
-## **🤖 LLM OPTIMIZATION (Token Efficiency & Clarity)**
-
-{{list each LLM optimization that will improve dev agent performance:
-- Reduce verbosity while maintaining completeness
-- Improve structure for better LLM processing
-- Make instructions more actionable and direct
-- Enhance clarity and reduce ambiguity}}
-```
-
-### **Step 6: Interactive User Selection**
-
-After presenting the suggestions, ask the user:
-
-```
-**IMPROVEMENT OPTIONS:**
-
-Which improvements would you like me to apply to the story?
-
-**Select from the numbered list above, or choose:**
-- **all** - Apply all suggested improvements
-- **critical** - Apply only critical issues
-- **select** - I'll choose specific numbers
-- **none** - Keep story as-is
-- **details** - Show me more details about any suggestion
-
-Your choice:
-```
-
-### **Step 7: Apply Selected Improvements**
-
-When user accepts improvements:
-
-- **Load the story file**
-- **Apply accepted changes** (make them look natural, as if they were always there)
-- **DO NOT reference** the review process, original LLM, or that changes were "added" or "enhanced"
-- **Ensure clean, coherent final story** that reads as if it was created perfectly the first time
-
-### **Step 8: Confirmation**
-
-After applying changes:
-
-```
-✅ **STORY IMPROVEMENTS APPLIED**
-
-Updated {{count}} sections in the story file.
-
-The story now includes comprehensive developer guidance to prevent common implementation issues and ensure flawless execution.
-
-**Next Steps:**
-1. Review the updated story
-2. Run `dev-story` for implementation
-```
-
----
-
-## **💪 COMPETITIVE EXCELLENCE MINDSET**
-
-**Your goal:** Improve the story file with dev agent needed context that makes flawless implementation inevitable while being optimized for LLM developer agent consumption. Remember the dev agent will ONLY have this file to use.
-
-**Success Criteria:** The LLM developer agent that processes your improved story will have:
-
-- ✅ Clear technical requirements they must follow
-- ✅ Previous work context they can build upon
-- ✅ Anti-pattern prevention to avoid common mistakes
-- ✅ Comprehensive guidance for efficient implementation
-- ✅ **Optimized content structure** for maximum clarity and minimum token waste
-- ✅ **Actionable instructions** with no ambiguity or verbosity
-- ✅ **Efficient information density** - maximum guidance in minimum text
-
-**Every improvement should make it IMPOSSIBLE for the developer to:**
-
-- Reinvent existing solutions
-- Use wrong approaches or libraries
-- Create duplicate functionality
-- Miss critical requirements
-- Make implementation errors
-
-**LLM Optimization Should Make it IMPOSSIBLE for the developer agent to:**
-
-- Misinterpret requirements due to ambiguity
-- Waste tokens on verbose, non-actionable content
-- Struggle to find critical information buried in text
-- Get confused by poor structure or organization
-- Miss key implementation signals due to inefficient communication
-
-**Go create the ultimate developer implementation guide! 🚀**
diff --git a/.claude/skills/bmad-create-story/discover-inputs.md b/.claude/skills/bmad-create-story/discover-inputs.md
deleted file mode 100644
index 2c313db..0000000
--- a/.claude/skills/bmad-create-story/discover-inputs.md
+++ /dev/null
@@ -1,88 +0,0 @@
-# Discover Inputs Protocol
-
-**Objective:** Intelligently load project files (whole or sharded) based on the workflow's Input Files configuration.
-
-**Prerequisite:** Only execute this protocol if the workflow defines an Input Files section. If no input file patterns are configured, skip this entirely.
-
----
-
-## Step 1: Parse Input File Patterns
-
-- Read the Input Files table from the workflow configuration.
-- For each input group (prd, architecture, epics, ux, etc.), note the **load strategy** if specified.
-
-## Step 2: Load Files Using Smart Strategies
-
-For each pattern in the Input Files table, work through the following substeps in order:
-
-### 2a: Try Sharded Documents First
-
-If a sharded pattern exists for this input, determine the load strategy (defaults to **FULL_LOAD** if not specified), then apply the matching strategy:
-
-#### FULL_LOAD Strategy
-
-Load ALL files in the sharded directory. Use this for PRD, Architecture, UX, brownfield docs, or whenever the full picture is needed.
-
-1. Use the glob pattern to find ALL `.md` files (e.g., `{planning_artifacts}/*architecture*/*.md`).
-2. Load EVERY matching file completely.
-3. Concatenate content in logical order: `index.md` first if it exists, then alphabetical.
-4. Store the combined result in a variable named `{pattern_name_content}` (e.g., `{architecture_content}`).
-
-#### SELECTIVE_LOAD Strategy
-
-Load a specific shard using a template variable. Example: used for epics with `{{epic_num}}`.
-
-1. Check for template variables in the sharded pattern (e.g., `{{epic_num}}`).
-2. If the variable is undefined, ask the user for the value OR infer it from context.
-3. Resolve the template to a specific file path.
-4. Load that specific file.
-5. Store in variable: `{pattern_name_content}`.
-
-#### INDEX_GUIDED Strategy
-
-Load index.md, analyze the structure and description of each doc in the index, then intelligently load relevant docs.
-
-**DO NOT BE LAZY** -- use best judgment to load documents that might have relevant information, even if there is only a 5% chance of relevance.
-
-1. Load `index.md` from the sharded directory.
-2. Parse the table of contents, links, and section headers.
-3. Analyze the workflow's purpose and objective.
-4. Identify which linked/referenced documents are likely relevant.
-   - *Example:* If the workflow is about authentication and the index shows "Auth Overview", "Payment Setup", "Deployment" -- load the auth docs, consider deployment docs, skip payment.
-5. Load all identified relevant documents.
-6. Store combined content in variable: `{pattern_name_content}`.
-
-**When in doubt, LOAD IT** -- context is valuable, and being thorough is better than missing critical info.
-
----
-
-After applying the matching strategy, mark the pattern as **RESOLVED** and move to the next pattern.
-
-### 2b: Try Whole Document if No Sharded Found
-
-If no sharded matches were found OR no sharded pattern exists for this input:
-
-1. Attempt a glob match on the "whole" pattern (e.g., `{planning_artifacts}/*prd*.md`).
-2. If matches are found, load ALL matching files completely (no offset/limit).
-3. Store content in variable: `{pattern_name_content}` (e.g., `{prd_content}`).
-4. Mark pattern as **RESOLVED** and move to the next pattern.
-
-### 2c: Handle Not Found
-
-If no matches were found for either sharded or whole patterns:
-
-1. Set `{pattern_name_content}` to empty string.
-2. Note in session: "No {pattern_name} files found" -- this is not an error, just unavailable. Offer the user a chance to provide the file.
-
-## Step 3: Report Discovery Results
-
-List all loaded content variables with file counts. Example:
-
-```
-OK Loaded {prd_content} from 5 sharded files: prd/index.md, prd/requirements.md, ...
-OK Loaded {architecture_content} from 1 file: Architecture.md
-OK Loaded {epics_content} from selective load: epics/epic-3.md
--- No ux_design files found
-```
-
-This gives the workflow transparency into what context is available.
diff --git a/.claude/skills/bmad-create-story/template.md b/.claude/skills/bmad-create-story/template.md
deleted file mode 100644
index c4e129f..0000000
--- a/.claude/skills/bmad-create-story/template.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Story {{epic_num}}.{{story_num}}: {{story_title}}
-
-Status: ready-for-dev
-
-<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
-
-## Story
-
-As a {{role}},
-I want {{action}},
-so that {{benefit}}.
-
-## Acceptance Criteria
-
-1. [Add acceptance criteria from epics/PRD]
-
-## Tasks / Subtasks
-
-- [ ] Task 1 (AC: #)
-  - [ ] Subtask 1.1
-- [ ] Task 2 (AC: #)
-  - [ ] Subtask 2.1
-
-## Dev Notes
-
-- Relevant architecture patterns and constraints
-- Source tree components to touch
-- Testing standards summary
-
-### Project Structure Notes
-
-- Alignment with unified project structure (paths, modules, naming)
-- Detected conflicts or variances (with rationale)
-
-### References
-
-- Cite all technical details with source paths and sections, e.g. [Source: docs/<file>.md#Section]
-
-## Dev Agent Record
-
-### Agent Model Used
-
-{{agent_model_name_version}}
-
-### Debug Log References
-
-### Completion Notes List
-
-### File List
diff --git a/.claude/skills/bmad-create-story/workflow.md b/.claude/skills/bmad-create-story/workflow.md
deleted file mode 100644
index 0acd866..0000000
--- a/.claude/skills/bmad-create-story/workflow.md
+++ /dev/null
@@ -1,380 +0,0 @@
-# Create Story Workflow
-
-**Goal:** Create a comprehensive story file that gives the dev agent everything needed for flawless implementation.
-
-**Your Role:** Story context engine that prevents LLM developer mistakes, omissions, or disasters.
-- Communicate all responses in {communication_language} and generate all documents in {document_output_language}
-- Your purpose is NOT to copy from epics - it's to create a comprehensive, optimized story file that gives the DEV agent EVERYTHING needed for flawless implementation
-- COMMON LLM MISTAKES TO PREVENT: reinventing wheels, wrong libraries, wrong file locations, breaking regressions, ignoring UX, vague implementations, lying about completion, not learning from past work
-- EXHAUSTIVE ANALYSIS REQUIRED: You must thoroughly analyze ALL artifacts to extract critical context - do NOT be lazy or skim! This is the most important function in the entire development process!
-- UTILIZE SUBPROCESSES AND SUBAGENTS: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different artifacts simultaneously and thoroughly
-- SAVE QUESTIONS: If you think of questions or clarifications during analysis, save them for the end after the complete story is written
-- ZERO USER INTERVENTION: Process should be fully automated except for initial epic/story selection or missing documents
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `user_skill_level`
-- `planning_artifacts`, `implementation_artifacts`
-- `date` as system-generated current datetime
-
-### Paths
-
-- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
-- `epics_file` = `{planning_artifacts}/epics.md`
-- `prd_file` = `{planning_artifacts}/prd.md`
-- `architecture_file` = `{planning_artifacts}/architecture.md`
-- `ux_file` = `{planning_artifacts}/*ux*.md`
-- `story_title` = "" (will be elicited if not derivable)
-- `project_context` = `**/project-context.md` (load if exists)
-- `default_output_file` = `{implementation_artifacts}/{{story_key}}.md`
-
-### Input Files
-
-| Input | Description | Path Pattern(s) | Load Strategy |
-|-------|-------------|------------------|---------------|
-| prd | PRD (fallback - epics file should have most content) | whole: `{planning_artifacts}/*prd*.md`, sharded: `{planning_artifacts}/*prd*/*.md` | SELECTIVE_LOAD |
-| architecture | Architecture (fallback - epics file should have relevant sections) | whole: `{planning_artifacts}/*architecture*.md`, sharded: `{planning_artifacts}/*architecture*/*.md` | SELECTIVE_LOAD |
-| ux | UX design (fallback - epics file should have relevant sections) | whole: `{planning_artifacts}/*ux*.md`, sharded: `{planning_artifacts}/*ux*/*.md` | SELECTIVE_LOAD |
-| epics | Enhanced epics+stories file with BDD and source hints | whole: `{planning_artifacts}/*epic*.md`, sharded: `{planning_artifacts}/*epic*/*.md` | SELECTIVE_LOAD |
-
----
-
-## EXECUTION
-
-<workflow>
-
-<step n="1" goal="Determine target story">
-  <check if="{{story_path}} is provided by user or user provided the epic and story number such as 2-4 or 1.6 or epic 1 story 5">
-    <action>Parse user-provided story path: extract epic_num, story_num, story_title from format like "1-2-user-auth"</action>
-    <action>Set {{epic_num}}, {{story_num}}, {{story_key}} from user input</action>
-    <action>GOTO step 2a</action>
-  </check>
-
-  <action>Check if {{sprint_status}} file exists for auto discover</action>
-  <check if="sprint status file does NOT exist">
-    <output>🚫 No sprint status file found and no story specified</output>
-    <output>
-      **Required Options:**
-      1. Run `sprint-planning` to initialize sprint tracking (recommended)
-      2. Provide specific epic-story number to create (e.g., "1-2-user-auth")
-      3. Provide path to story documents if sprint status doesn't exist yet
-    </output>
-    <ask>Choose option [1], provide epic-story number, path to story docs, or [q] to quit:</ask>
-
-    <check if="user chooses 'q'">
-      <action>HALT - No work needed</action>
-    </check>
-
-    <check if="user chooses '1'">
-      <output>Run sprint-planning workflow first to create sprint-status.yaml</output>
-      <action>HALT - User needs to run sprint-planning</action>
-    </check>
-
-    <check if="user provides epic-story number">
-      <action>Parse user input: extract epic_num, story_num, story_title</action>
-      <action>Set {{epic_num}}, {{story_num}}, {{story_key}} from user input</action>
-      <action>GOTO step 2a</action>
-    </check>
-
-    <check if="user provides story docs path">
-      <action>Use user-provided path for story documents</action>
-      <action>GOTO step 2a</action>
-    </check>
-  </check>
-
-  <!-- Auto-discover from sprint status only if no user input -->
-  <check if="no user input provided">
-    <critical>MUST read COMPLETE {sprint_status} file from start to end to preserve order</critical>
-    <action>Load the FULL file: {{sprint_status}}</action>
-    <action>Read ALL lines from beginning to end - do not skip any content</action>
-    <action>Parse the development_status section completely</action>
-
-    <action>Find the FIRST story (by reading in order from top to bottom) where:
-      - Key matches pattern: number-number-name (e.g., "1-2-user-auth")
-      - NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
-      - Status value equals "backlog"
-    </action>
-
-    <check if="no backlog story found">
-      <output>📋 No backlog stories found in sprint-status.yaml
-
-        All stories are either already created, in progress, or done.
-
-        **Options:**
-        1. Run sprint-planning to refresh story tracking
-        2. Load PM agent and run correct-course to add more stories
-        3. Check if current sprint is complete and run retrospective
-      </output>
-      <action>HALT</action>
-    </check>
-
-    <action>Extract from found story key (e.g., "1-2-user-authentication"):
-      - epic_num: first number before dash (e.g., "1")
-      - story_num: second number after first dash (e.g., "2")
-      - story_title: remainder after second dash (e.g., "user-authentication")
-    </action>
-    <action>Set {{story_id}} = "{{epic_num}}.{{story_num}}"</action>
-    <action>Store story_key for later use (e.g., "1-2-user-authentication")</action>
-
-    <!-- Mark epic as in-progress if this is first story -->
-    <action>Check if this is the first story in epic {{epic_num}} by looking for {{epic_num}}-1-* pattern</action>
-    <check if="this is first story in epic {{epic_num}}">
-      <action>Load {{sprint_status}} and check epic-{{epic_num}} status</action>
-      <action>If epic status is "backlog" → update to "in-progress"</action>
-      <action>If epic status is "contexted" (legacy status) → update to "in-progress" (backward compatibility)</action>
-      <action>If epic status is "in-progress" → no change needed</action>
-      <check if="epic status is 'done'">
-        <output>🚫 ERROR: Cannot create story in completed epic</output>
-        <output>Epic {{epic_num}} is marked as 'done'. All stories are complete.</output>
-        <output>If you need to add more work, either:</output>
-        <output>1. Manually change epic status back to 'in-progress' in sprint-status.yaml</output>
-        <output>2. Create a new epic for additional work</output>
-        <action>HALT - Cannot proceed</action>
-      </check>
-      <check if="epic status is not one of: backlog, contexted, in-progress, done">
-        <output>🚫 ERROR: Invalid epic status '{{epic_status}}'</output>
-        <output>Epic {{epic_num}} has invalid status. Expected: backlog, in-progress, or done</output>
-        <output>Please fix sprint-status.yaml manually or run sprint-planning to regenerate</output>
-        <action>HALT - Cannot proceed</action>
-      </check>
-      <output>📊 Epic {{epic_num}} status updated to in-progress</output>
-    </check>
-
-    <action>GOTO step 2a</action>
-  </check>
-  <action>Load the FULL file: {{sprint_status}}</action>
-  <action>Read ALL lines from beginning to end - do not skip any content</action>
-  <action>Parse the development_status section completely</action>
-
-  <action>Find the FIRST story (by reading in order from top to bottom) where:
-    - Key matches pattern: number-number-name (e.g., "1-2-user-auth")
-    - NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
-    - Status value equals "backlog"
-  </action>
-
-  <check if="no backlog story found">
-    <output>No backlog stories found in sprint-status.yaml
-
-      All stories are either already created, in progress, or done.
-
-      **Options:**
-      1. Run sprint-planning to refresh story tracking
-      2. Load PM agent and run correct-course to add more stories
-      3. Check if current sprint is complete and run retrospective
-    </output>
-    <action>HALT</action>
-  </check>
-
-  <action>Extract from found story key (e.g., "1-2-user-authentication"):
-    - epic_num: first number before dash (e.g., "1")
-    - story_num: second number after first dash (e.g., "2")
-    - story_title: remainder after second dash (e.g., "user-authentication")
-  </action>
-  <action>Set {{story_id}} = "{{epic_num}}.{{story_num}}"</action>
-  <action>Store story_key for later use (e.g., "1-2-user-authentication")</action>
-
-  <!-- Mark epic as in-progress if this is first story -->
-  <action>Check if this is the first story in epic {{epic_num}} by looking for {{epic_num}}-1-* pattern</action>
-  <check if="this is first story in epic {{epic_num}}">
-    <action>Load {{sprint_status}} and check epic-{{epic_num}} status</action>
-    <action>If epic status is "backlog" → update to "in-progress"</action>
-    <action>If epic status is "contexted" (legacy status) → update to "in-progress" (backward compatibility)</action>
-    <action>If epic status is "in-progress" → no change needed</action>
-    <check if="epic status is 'done'">
-      <output>ERROR: Cannot create story in completed epic</output>
-      <output>Epic {{epic_num}} is marked as 'done'. All stories are complete.</output>
-      <output>If you need to add more work, either:</output>
-      <output>1. Manually change epic status back to 'in-progress' in sprint-status.yaml</output>
-      <output>2. Create a new epic for additional work</output>
-      <action>HALT - Cannot proceed</action>
-    </check>
-    <check if="epic status is not one of: backlog, contexted, in-progress, done">
-      <output>ERROR: Invalid epic status '{{epic_status}}'</output>
-      <output>Epic {{epic_num}} has invalid status. Expected: backlog, in-progress, or done</output>
-      <output>Please fix sprint-status.yaml manually or run sprint-planning to regenerate</output>
-      <action>HALT - Cannot proceed</action>
-    </check>
-    <output>Epic {{epic_num}} status updated to in-progress</output>
-  </check>
-
-  <action>GOTO step 2a</action>
-</step>
-
-<step n="2" goal="Load and analyze core artifacts">
-  <critical>🔬 EXHAUSTIVE ARTIFACT ANALYSIS - This is where you prevent future developer mistakes!</critical>
-
-  <!-- Load all available content through discovery protocol -->
-  <action>Read fully and follow `./discover-inputs.md` to load all input files</action>
-  <note>Available content: {epics_content}, {prd_content}, {architecture_content}, {ux_content},
-  {project_context}</note>
-
-  <!-- Analyze epics file for story foundation -->
-  <action>From {epics_content}, extract Epic {{epic_num}} complete context:</action> **EPIC ANALYSIS:** - Epic
-  objectives and business value - ALL stories in this epic for cross-story context - Our specific story's requirements, user story
-  statement, acceptance criteria - Technical requirements and constraints - Dependencies on other stories/epics - Source hints pointing to
-  original documents <!-- Extract specific story requirements -->
-  <action>Extract our story ({{epic_num}}-{{story_num}}) details:</action> **STORY FOUNDATION:** - User story statement
-  (As a, I want, so that) - Detailed acceptance criteria (already BDD formatted) - Technical requirements specific to this story -
-  Business context and value - Success criteria <!-- Previous story analysis for context continuity -->
-  <check if="story_num > 1">
-    <action>Find {{previous_story_num}}: scan {implementation_artifacts} for the story file in epic {{epic_num}} with the highest story number less than {{story_num}}</action>
-    <action>Load previous story file: {implementation_artifacts}/{{epic_num}}-{{previous_story_num}}-*.md</action> **PREVIOUS STORY INTELLIGENCE:** -
-  Dev notes and learnings from previous story - Review feedback and corrections needed - Files that were created/modified and their
-  patterns - Testing approaches that worked/didn't work - Problems encountered and solutions found - Code patterns established <action>Extract
-  all learnings that could impact current story implementation</action>
-  </check>
-
-  <!-- Git intelligence for previous work patterns -->
-  <check
-    if="previous story exists AND git repository detected">
-    <action>Get last 5 commit titles to understand recent work patterns</action>
-    <action>Analyze 1-5 most recent commits for relevance to current story:
-      - Files created/modified
-      - Code patterns and conventions used
-      - Library dependencies added/changed
-      - Architecture decisions implemented
-      - Testing approaches used
-    </action>
-    <action>Extract actionable insights for current story implementation</action>
-  </check>
-</step>
-
-<step n="3" goal="Architecture analysis for developer guardrails">
-  <critical>🏗️ ARCHITECTURE INTELLIGENCE - Extract everything the developer MUST follow!</critical> **ARCHITECTURE DOCUMENT ANALYSIS:** <action>Systematically
-  analyze architecture content for story-relevant requirements:</action>
-
-  <!-- Load architecture - single file or sharded -->
-  <check if="architecture file is single file">
-    <action>Load complete {architecture_content}</action>
-  </check>
-  <check if="architecture is sharded to folder">
-    <action>Load architecture index and scan all architecture files</action>
-  </check> **CRITICAL ARCHITECTURE EXTRACTION:** <action>For
-  each architecture section, determine if relevant to this story:</action> - **Technical Stack:** Languages, frameworks, libraries with
-  versions - **Code Structure:** Folder organization, naming conventions, file patterns - **API Patterns:** Service structure, endpoint
-  patterns, data contracts - **Database Schemas:** Tables, relationships, constraints relevant to story - **Security Requirements:**
-  Authentication patterns, authorization rules - **Performance Requirements:** Caching strategies, optimization patterns - **Testing
-  Standards:** Testing frameworks, coverage expectations, test patterns - **Deployment Patterns:** Environment configurations, build
-  processes - **Integration Patterns:** External service integrations, data flows <action>Extract any story-specific requirements that the
-  developer MUST follow</action>
-  <action>Identify any architectural decisions that override previous patterns</action>
-</step>
-
-<step n="4" goal="Web research for latest technical specifics">
-  <critical>🌐 ENSURE LATEST TECH KNOWLEDGE - Prevent outdated implementations!</critical> **WEB INTELLIGENCE:** <action>Identify specific
-  technical areas that require latest version knowledge:</action>
-
-  <!-- Check for libraries/frameworks mentioned in architecture -->
-  <action>From architecture analysis, identify specific libraries, APIs, or
-  frameworks</action>
-  <action>For each critical technology, research latest stable version and key changes:
-    - Latest API documentation and breaking changes
-    - Security vulnerabilities or updates
-    - Performance improvements or deprecations
-    - Best practices for current version
-  </action>
-  **EXTERNAL CONTEXT INCLUSION:** <action>Include in story any critical latest information the developer needs:
-    - Specific library versions and why chosen
-    - API endpoints with parameters and authentication
-    - Recent security patches or considerations
-    - Performance optimization techniques
-    - Migration considerations if upgrading
-  </action>
-</step>
-
-<step n="5" goal="Create comprehensive story file">
-  <critical>📝 CREATE ULTIMATE STORY FILE - The developer's master implementation guide!</critical>
-
-  <action>Initialize from template.md:
-  {default_output_file}</action>
-  <template-output file="{default_output_file}">story_header</template-output>
-
-  <!-- Story foundation from epics analysis -->
-  <template-output
-    file="{default_output_file}">story_requirements</template-output>
-
-  <!-- Developer context section - MOST IMPORTANT PART -->
-  <template-output file="{default_output_file}">
-  developer_context_section</template-output> **DEV AGENT GUARDRAILS:** <template-output file="{default_output_file}">
-  technical_requirements</template-output>
-  <template-output file="{default_output_file}">architecture_compliance</template-output>
-  <template-output
-    file="{default_output_file}">library_framework_requirements</template-output>
-  <template-output file="{default_output_file}">
-  file_structure_requirements</template-output>
-  <template-output file="{default_output_file}">testing_requirements</template-output>
-
-  <!-- Previous story intelligence -->
-  <check
-    if="previous story learnings available">
-    <template-output file="{default_output_file}">previous_story_intelligence</template-output>
-  </check>
-
-  <!-- Git intelligence -->
-  <check
-    if="git analysis completed">
-    <template-output file="{default_output_file}">git_intelligence_summary</template-output>
-  </check>
-
-  <!-- Latest technical specifics -->
-  <check if="web research completed">
-    <template-output file="{default_output_file}">latest_tech_information</template-output>
-  </check>
-
-  <!-- Project context reference -->
-  <template-output
-    file="{default_output_file}">project_context_reference</template-output>
-
-  <!-- Final status update -->
-  <template-output file="{default_output_file}">
-  story_completion_status</template-output>
-
-  <!-- CRITICAL: Set status to ready-for-dev -->
-  <action>Set story Status to: "ready-for-dev"</action>
-  <action>Add completion note: "Ultimate
-  context engine analysis completed - comprehensive developer guide created"</action>
-</step>
-
-<step n="6" goal="Update sprint status and finalize">
-  <action>Validate the newly created story file {default_output_file} against `./checklist.md` and apply any required fixes before finalizing</action>
-  <action>Save story document unconditionally</action>
-
-  <!-- Update sprint status -->
-  <check if="sprint status file exists">
-    <action>Update {{sprint_status}}</action>
-    <action>Load the FULL file and read all development_status entries</action>
-    <action>Find development_status key matching {{story_key}}</action>
-    <action>Verify current status is "backlog" (expected previous state)</action>
-    <action>Update development_status[{{story_key}}] = "ready-for-dev"</action>
-    <action>Update last_updated field to current date</action>
-    <action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
-  </check>
-
-  <action>Report completion</action>
-  <output>**🎯 ULTIMATE BMad Method STORY CONTEXT CREATED, {user_name}!**
-
-    **Story Details:**
-    - Story ID: {{story_id}}
-    - Story Key: {{story_key}}
-    - File: {{story_file}}
-    - Status: ready-for-dev
-
-    **Next Steps:**
-    1. Review the comprehensive story in {{story_file}}
-    2. Run dev agents `dev-story` for optimized implementation
-    3. Run `code-review` when complete (auto-marks done)
-    4. Optional: If Test Architect module installed, run `/bmad:tea:automate` after `dev-story` to generate guardrail tests
-
-    **The developer now has everything needed for flawless implementation!**
-  </output>
-</step>
-
-</workflow>
diff --git a/.claude/skills/bmad-dev-story/SKILL.md b/.claude/skills/bmad-dev-story/SKILL.md
deleted file mode 100644
index 0eb505c..0000000
--- a/.claude/skills/bmad-dev-story/SKILL.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-name: bmad-dev-story
-description: 'Execute story implementation following a context filled story spec file. Use when the user says "dev this story [story file]" or "implement the next story in the sprint plan"'
----
-
-Follow the instructions in ./workflow.md.
diff --git a/.claude/skills/bmad-dev-story/checklist.md b/.claude/skills/bmad-dev-story/checklist.md
deleted file mode 100644
index 86d6e9b..0000000
--- a/.claude/skills/bmad-dev-story/checklist.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: 'Enhanced Dev Story Definition of Done Checklist'
-validation-target: 'Story markdown ({{story_path}})'
-validation-criticality: 'HIGHEST'
-required-inputs:
-  - 'Story markdown file with enhanced Dev Notes containing comprehensive implementation context'
-  - 'Completed Tasks/Subtasks section with all items marked [x]'
-  - 'Updated File List section with all changed files'
-  - 'Updated Dev Agent Record with implementation notes'
-optional-inputs:
-  - 'Test results output'
-  - 'CI logs'
-  - 'Linting reports'
-validation-rules:
-  - 'Only permitted story sections modified: Tasks/Subtasks checkboxes, Dev Agent Record, File List, Change Log, Status'
-  - 'All implementation requirements from story Dev Notes must be satisfied'
-  - 'Definition of Done checklist must pass completely'
-  - 'Enhanced story context must contain sufficient technical guidance'
----
-
-# 🎯 Enhanced Definition of Done Checklist
-
-**Critical validation:** Story is truly ready for review only when ALL items below are satisfied
-
-## 📋 Context & Requirements Validation
-
-- [ ] **Story Context Completeness:** Dev Notes contains ALL necessary technical requirements, architecture patterns, and implementation guidance
-- [ ] **Architecture Compliance:** Implementation follows all architectural requirements specified in Dev Notes
-- [ ] **Technical Specifications:** All technical specifications (libraries, frameworks, versions) from Dev Notes are implemented correctly
-- [ ] **Previous Story Learnings:** Previous story insights incorporated (if applicable) and build upon appropriately
-
-## ✅ Implementation Completion
-
-- [ ] **All Tasks Complete:** Every task and subtask marked complete with [x]
-- [ ] **Acceptance Criteria Satisfaction:** Implementation satisfies EVERY Acceptance Criterion in the story
-- [ ] **No Ambiguous Implementation:** Clear, unambiguous implementation that meets story requirements
-- [ ] **Edge Cases Handled:** Error conditions and edge cases appropriately addressed
-- [ ] **Dependencies Within Scope:** Only uses dependencies specified in story or project-context.md
-
-## 🧪 Testing & Quality Assurance
-
-- [ ] **Unit Tests:** Unit tests added/updated for ALL core functionality introduced/changed by this story
-- [ ] **Integration Tests:** Integration tests added/updated for component interactions when story requirements demand them
-- [ ] **End-to-End Tests:** End-to-end tests created for critical user flows when story requirements specify them
-- [ ] **Test Coverage:** Tests cover acceptance criteria and edge cases from story Dev Notes
-- [ ] **Regression Prevention:** ALL existing tests pass (no regressions introduced)
-- [ ] **Code Quality:** Linting and static checks pass when configured in project
-- [ ] **Test Framework Compliance:** Tests use project's testing frameworks and patterns from Dev Notes
-
-## 📝 Documentation & Tracking
-
-- [ ] **File List Complete:** File List includes EVERY new, modified, or deleted file (paths relative to repo root)
-- [ ] **Dev Agent Record Updated:** Contains relevant Implementation Notes and/or Debug Log for this work
-- [ ] **Change Log Updated:** Change Log includes clear summary of what changed and why
-- [ ] **Review Follow-ups:** All review follow-up tasks (marked [AI-Review]) completed and corresponding review items marked resolved (if applicable)
-- [ ] **Story Structure Compliance:** Only permitted sections of story file were modified
-
-## 🔚 Final Status Verification
-
-- [ ] **Story Status Updated:** Story Status set to "review"
-- [ ] **Sprint Status Updated:** Sprint status updated to "review" (when sprint tracking is used)
-- [ ] **Quality Gates Passed:** All quality checks and validations completed successfully
-- [ ] **No HALT Conditions:** No blocking issues or incomplete work remaining
-- [ ] **User Communication Ready:** Implementation summary prepared for user review
-
-## 🎯 Final Validation Output
-
-```
-Definition of Done: {{PASS/FAIL}}
-
-✅ **Story Ready for Review:** {{story_key}}
-📊 **Completion Score:** {{completed_items}}/{{total_items}} items passed
-🔍 **Quality Gates:** {{quality_gates_status}}
-📋 **Test Results:** {{test_results_summary}}
-📝 **Documentation:** {{documentation_status}}
-```
-
-**If FAIL:** List specific failures and required actions before story can be marked Ready for Review
-
-**If PASS:** Story is fully ready for code review and production consideration
diff --git a/.claude/skills/bmad-dev-story/workflow.md b/.claude/skills/bmad-dev-story/workflow.md
deleted file mode 100644
index 4164479..0000000
--- a/.claude/skills/bmad-dev-story/workflow.md
+++ /dev/null
@@ -1,450 +0,0 @@
-# Dev Story Workflow
-
-**Goal:** Execute story implementation following a context filled story spec file.
-
-**Your Role:** Developer implementing the story.
-- Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
-- Generate all documents in {document_output_language}
-- Only modify the story file in these areas: Tasks/Subtasks checkboxes, Dev Agent Record (Debug Log, Completion Notes), File List, Change Log, and Status
-- Execute ALL steps in exact order; do NOT skip steps
-- Absolutely DO NOT stop because of "milestones", "significant progress", or "session boundaries". Continue in a single execution until the story is COMPLETE (all ACs satisfied and all tasks/subtasks checked) UNLESS a HALT condition is triggered or the USER gives other instruction.
-- Do NOT schedule a "next session" or request review pauses unless a HALT condition applies. Only Step 6 decides completion.
-- User skill level ({user_skill_level}) affects conversation style ONLY, not code updates.
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `user_skill_level`
-- `implementation_artifacts`
-- `date` as system-generated current datetime
-
-### Paths
-
-- `story_file` = `` (explicit story path; auto-discovered if empty)
-- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
-
-### Context
-
-- `project_context` = `**/project-context.md` (load if exists)
-
----
-
-## EXECUTION
-
-<workflow>
-  <critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
-  <critical>Generate all documents in {document_output_language}</critical>
-  <critical>Only modify the story file in these areas: Tasks/Subtasks checkboxes, Dev Agent Record (Debug Log, Completion Notes), File List,
-    Change Log, and Status</critical>
-  <critical>Execute ALL steps in exact order; do NOT skip steps</critical>
-  <critical>Absolutely DO NOT stop because of "milestones", "significant progress", or "session boundaries". Continue in a single execution
-    until the story is COMPLETE (all ACs satisfied and all tasks/subtasks checked) UNLESS a HALT condition is triggered or the USER gives
-    other instruction.</critical>
-  <critical>Do NOT schedule a "next session" or request review pauses unless a HALT condition applies. Only Step 6 decides completion.</critical>
-  <critical>User skill level ({user_skill_level}) affects conversation style ONLY, not code updates.</critical>
-
-  <step n="1" goal="Find next ready story and load it" tag="sprint-status">
-    <check if="{{story_path}} is provided">
-      <action>Use {{story_path}} directly</action>
-      <action>Read COMPLETE story file</action>
-      <action>Extract story_key from filename or metadata</action>
-      <goto anchor="task_check" />
-    </check>
-
-    <!-- Sprint-based story discovery -->
-    <check if="{{sprint_status}} file exists">
-      <critical>MUST read COMPLETE sprint-status.yaml file from start to end to preserve order</critical>
-      <action>Load the FULL file: {{sprint_status}}</action>
-      <action>Read ALL lines from beginning to end - do not skip any content</action>
-      <action>Parse the development_status section completely to understand story order</action>
-
-      <action>Find the FIRST story (by reading in order from top to bottom) where:
-        - Key matches pattern: number-number-name (e.g., "1-2-user-auth")
-        - NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
-        - Status value equals "ready-for-dev"
-      </action>
-
-      <check if="no ready-for-dev or in-progress story found">
-        <output>📋 No ready-for-dev stories found in sprint-status.yaml
-
-          **Current Sprint Status:** {{sprint_status_summary}}
-
-          **What would you like to do?**
-          1. Run `create-story` to create next story from epics with comprehensive context
-          2. Run `*validate-create-story` to improve existing stories before development (recommended quality check)
-          3. Specify a particular story file to develop (provide full path)
-          4. Check {{sprint_status}} file to see current sprint status
-
-          💡 **Tip:** Stories in `ready-for-dev` may not have been validated. Consider running `validate-create-story` first for a quality
-          check.
-        </output>
-        <ask>Choose option [1], [2], [3], or [4], or specify story file path:</ask>
-
-        <check if="user chooses '1'">
-          <action>HALT - Run create-story to create next story</action>
-        </check>
-
-        <check if="user chooses '2'">
-          <action>HALT - Run validate-create-story to improve existing stories</action>
-        </check>
-
-        <check if="user chooses '3'">
-          <ask>Provide the story file path to develop:</ask>
-          <action>Store user-provided story path as {{story_path}}</action>
-          <goto anchor="task_check" />
-        </check>
-
-        <check if="user chooses '4'">
-          <output>Loading {{sprint_status}} for detailed status review...</output>
-          <action>Display detailed sprint status analysis</action>
-          <action>HALT - User can review sprint status and provide story path</action>
-        </check>
-
-        <check if="user provides story file path">
-          <action>Store user-provided story path as {{story_path}}</action>
-          <goto anchor="task_check" />
-        </check>
-      </check>
-    </check>
-
-    <!-- Non-sprint story discovery -->
-    <check if="{{sprint_status}} file does NOT exist">
-      <action>Search {implementation_artifacts} for stories directly</action>
-      <action>Find stories with "ready-for-dev" status in files</action>
-      <action>Look for story files matching pattern: *-*-*.md</action>
-      <action>Read each candidate story file to check Status section</action>
-
-      <check if="no ready-for-dev stories found in story files">
-        <output>📋 No ready-for-dev stories found
-
-          **Available Options:**
-          1. Run `create-story` to create next story from epics with comprehensive context
-          2. Run `*validate-create-story` to improve existing stories
-          3. Specify which story to develop
-        </output>
-        <ask>What would you like to do? Choose option [1], [2], or [3]:</ask>
-
-        <check if="user chooses '1'">
-          <action>HALT - Run create-story to create next story</action>
-        </check>
-
-        <check if="user chooses '2'">
-          <action>HALT - Run validate-create-story to improve existing stories</action>
-        </check>
-
-        <check if="user chooses '3'">
-          <ask>It's unclear what story you want developed. Please provide the full path to the story file:</ask>
-          <action>Store user-provided story path as {{story_path}}</action>
-          <action>Continue with provided story file</action>
-        </check>
-      </check>
-
-      <check if="ready-for-dev story found in files">
-        <action>Use discovered story file and extract story_key</action>
-      </check>
-    </check>
-
-    <action>Store the found story_key (e.g., "1-2-user-authentication") for later status updates</action>
-    <action>Find matching story file in {implementation_artifacts} using story_key pattern: {{story_key}}.md</action>
-    <action>Read COMPLETE story file from discovered path</action>
-
-    <anchor id="task_check" />
-
-    <action>Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Dev Agent Record, File List, Change Log, Status</action>
-
-    <action>Load comprehensive context from story file's Dev Notes section</action>
-    <action>Extract developer guidance from Dev Notes: architecture requirements, previous learnings, technical specifications</action>
-    <action>Use enhanced story context to inform implementation decisions and approaches</action>
-
-    <action>Identify first incomplete task (unchecked [ ]) in Tasks/Subtasks</action>
-
-    <action if="no incomplete tasks">
-      <goto step="6">Completion sequence</goto>
-    </action>
-    <action if="story file inaccessible">HALT: "Cannot develop story without access to story file"</action>
-    <action if="incomplete task or subtask requirements ambiguous">ASK user to clarify or HALT</action>
-  </step>
-
-  <step n="2" goal="Load project context and story information">
-    <critical>Load all available context to inform implementation</critical>
-
-    <action>Load {project_context} for coding standards and project-wide patterns (if exists)</action>
-    <action>Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Dev Agent Record, File List, Change Log, Status</action>
-    <action>Load comprehensive context from story file's Dev Notes section</action>
-    <action>Extract developer guidance from Dev Notes: architecture requirements, previous learnings, technical specifications</action>
-    <action>Use enhanced story context to inform implementation decisions and approaches</action>
-    <output>✅ **Context Loaded**
-      Story and project context available for implementation
-    </output>
-  </step>
-
-  <step n="3" goal="Detect review continuation and extract review context">
-    <critical>Determine if this is a fresh start or continuation after code review</critical>
-
-    <action>Check if "Senior Developer Review (AI)" section exists in the story file</action>
-    <action>Check if "Review Follow-ups (AI)" subsection exists under Tasks/Subtasks</action>
-
-    <check if="Senior Developer Review section exists">
-      <action>Set review_continuation = true</action>
-      <action>Extract from "Senior Developer Review (AI)" section:
-        - Review outcome (Approve/Changes Requested/Blocked)
-        - Review date
-        - Total action items with checkboxes (count checked vs unchecked)
-        - Severity breakdown (High/Med/Low counts)
-      </action>
-      <action>Count unchecked [ ] review follow-up tasks in "Review Follow-ups (AI)" subsection</action>
-      <action>Store list of unchecked review items as {{pending_review_items}}</action>
-
-      <output>⏯️ **Resuming Story After Code Review** ({{review_date}})
-
-        **Review Outcome:** {{review_outcome}}
-        **Action Items:** {{unchecked_review_count}} remaining to address
-        **Priorities:** {{high_count}} High, {{med_count}} Medium, {{low_count}} Low
-
-        **Strategy:** Will prioritize review follow-up tasks (marked [AI-Review]) before continuing with regular tasks.
-      </output>
-    </check>
-
-    <check if="Senior Developer Review section does NOT exist">
-      <action>Set review_continuation = false</action>
-      <action>Set {{pending_review_items}} = empty</action>
-
-      <output>🚀 **Starting Fresh Implementation**
-
-        Story: {{story_key}}
-        Story Status: {{current_status}}
-        First incomplete task: {{first_task_description}}
-      </output>
-    </check>
-  </step>
-
-  <step n="4" goal="Mark story in-progress" tag="sprint-status">
-    <check if="{{sprint_status}} file exists">
-      <action>Load the FULL file: {{sprint_status}}</action>
-      <action>Read all development_status entries to find {{story_key}}</action>
-      <action>Get current status value for development_status[{{story_key}}]</action>
-
-      <check if="current status == 'ready-for-dev' OR review_continuation == true">
-        <action>Update the story in the sprint status report to = "in-progress"</action>
-        <action>Update last_updated field to current date</action>
-        <output>🚀 Starting work on story {{story_key}}
-          Status updated: ready-for-dev → in-progress
-        </output>
-      </check>
-
-      <check if="current status == 'in-progress'">
-        <output>⏯️ Resuming work on story {{story_key}}
-          Story is already marked in-progress
-        </output>
-      </check>
-
-      <check if="current status is neither ready-for-dev nor in-progress">
-        <output>⚠️ Unexpected story status: {{current_status}}
-          Expected ready-for-dev or in-progress. Continuing anyway...
-        </output>
-      </check>
-
-      <action>Store {{current_sprint_status}} for later use</action>
-    </check>
-
-    <check if="{{sprint_status}} file does NOT exist">
-      <output>ℹ️ No sprint status file exists - story progress will be tracked in story file only</output>
-      <action>Set {{current_sprint_status}} = "no-sprint-tracking"</action>
-    </check>
-  </step>
-
-  <step n="5" goal="Implement task following red-green-refactor cycle">
-    <critical>FOLLOW THE STORY FILE TASKS/SUBTASKS SEQUENCE EXACTLY AS WRITTEN - NO DEVIATION</critical>
-
-    <action>Review the current task/subtask from the story file - this is your authoritative implementation guide</action>
-    <action>Plan implementation following red-green-refactor cycle</action>
-
-    <!-- RED PHASE -->
-    <action>Write FAILING tests first for the task/subtask functionality</action>
-    <action>Confirm tests fail before implementation - this validates test correctness</action>
-
-    <!-- GREEN PHASE -->
-    <action>Implement MINIMAL code to make tests pass</action>
-    <action>Run tests to confirm they now pass</action>
-    <action>Handle error conditions and edge cases as specified in task/subtask</action>
-
-    <!-- REFACTOR PHASE -->
-    <action>Improve code structure while keeping tests green</action>
-    <action>Ensure code follows architecture patterns and coding standards from Dev Notes</action>
-
-    <action>Document technical approach and decisions in Dev Agent Record → Implementation Plan</action>
-
-    <action if="new dependencies required beyond story specifications">HALT: "Additional dependencies need user approval"</action>
-    <action if="3 consecutive implementation failures occur">HALT and request guidance</action>
-    <action if="required configuration is missing">HALT: "Cannot proceed without necessary configuration files"</action>
-
-    <critical>NEVER implement anything not mapped to a specific task/subtask in the story file</critical>
-    <critical>NEVER proceed to next task until current task/subtask is complete AND tests pass</critical>
-    <critical>Execute continuously without pausing until all tasks/subtasks are complete or explicit HALT condition</critical>
-    <critical>Do NOT propose to pause for review until Step 9 completion gates are satisfied</critical>
-  </step>
-
-  <step n="6" goal="Author comprehensive tests">
-    <action>Create unit tests for business logic and core functionality introduced/changed by the task</action>
-    <action>Add integration tests for component interactions specified in story requirements</action>
-    <action>Include end-to-end tests for critical user flows when story requirements demand them</action>
-    <action>Cover edge cases and error handling scenarios identified in story Dev Notes</action>
-  </step>
-
-  <step n="7" goal="Run validations and tests">
-    <action>Determine how to run tests for this repo (infer test framework from project structure)</action>
-    <action>Run all existing tests to ensure no regressions</action>
-    <action>Run the new tests to verify implementation correctness</action>
-    <action>Run linting and code quality checks if configured in project</action>
-    <action>Validate implementation meets ALL story acceptance criteria; enforce quantitative thresholds explicitly</action>
-    <action if="regression tests fail">STOP and fix before continuing - identify breaking changes immediately</action>
-    <action if="new tests fail">STOP and fix before continuing - ensure implementation correctness</action>
-  </step>
-
-  <step n="8" goal="Validate and mark task complete ONLY when fully done">
-    <critical>NEVER mark a task complete unless ALL conditions are met - NO LYING OR CHEATING</critical>
-
-    <!-- VALIDATION GATES -->
-    <action>Verify ALL tests for this task/subtask ACTUALLY EXIST and PASS 100%</action>
-    <action>Confirm implementation matches EXACTLY what the task/subtask specifies - no extra features</action>
-    <action>Validate that ALL acceptance criteria related to this task are satisfied</action>
-    <action>Run full test suite to ensure NO regressions introduced</action>
-
-    <!-- REVIEW FOLLOW-UP HANDLING -->
-    <check if="task is review follow-up (has [AI-Review] prefix)">
-      <action>Extract review item details (severity, description, related AC/file)</action>
-      <action>Add to resolution tracking list: {{resolved_review_items}}</action>
-
-      <!-- Mark task in Review Follow-ups section -->
-      <action>Mark task checkbox [x] in "Tasks/Subtasks → Review Follow-ups (AI)" section</action>
-
-      <!-- CRITICAL: Also mark corresponding action item in review section -->
-      <action>Find matching action item in "Senior Developer Review (AI) → Action Items" section by matching description</action>
-      <action>Mark that action item checkbox [x] as resolved</action>
-
-      <action>Add to Dev Agent Record → Completion Notes: "✅ Resolved review finding [{{severity}}]: {{description}}"</action>
-    </check>
-
-    <!-- ONLY MARK COMPLETE IF ALL VALIDATION PASS -->
-    <check if="ALL validation gates pass AND tests ACTUALLY exist and pass">
-      <action>ONLY THEN mark the task (and subtasks) checkbox with [x]</action>
-      <action>Update File List section with ALL new, modified, or deleted files (paths relative to repo root)</action>
-      <action>Add completion notes to Dev Agent Record summarizing what was ACTUALLY implemented and tested</action>
-    </check>
-
-    <check if="ANY validation fails">
-      <action>DO NOT mark task complete - fix issues first</action>
-      <action>HALT if unable to fix validation failures</action>
-    </check>
-
-    <check if="review_continuation == true and {{resolved_review_items}} is not empty">
-      <action>Count total resolved review items in this session</action>
-      <action>Add Change Log entry: "Addressed code review findings - {{resolved_count}} items resolved (Date: {{date}})"</action>
-    </check>
-
-    <action>Save the story file</action>
-    <action>Determine if more incomplete tasks remain</action>
-    <action if="more tasks remain">
-      <goto step="5">Next task</goto>
-    </action>
-    <action if="no tasks remain">
-      <goto step="9">Completion</goto>
-    </action>
-  </step>
-
-  <step n="9" goal="Story completion and mark for review" tag="sprint-status">
-    <action>Verify ALL tasks and subtasks are marked [x] (re-scan the story document now)</action>
-    <action>Run the full regression suite (do not skip)</action>
-    <action>Confirm File List includes every changed file</action>
-    <action>Execute enhanced definition-of-done validation</action>
-    <action>Update the story Status to: "review"</action>
-
-    <!-- Enhanced Definition of Done Validation -->
-    <action>Validate definition-of-done checklist with essential requirements:
-      - All tasks/subtasks marked complete with [x]
-      - Implementation satisfies every Acceptance Criterion
-      - Unit tests for core functionality added/updated
-      - Integration tests for component interactions added when required
-      - End-to-end tests for critical flows added when story demands them
-      - All tests pass (no regressions, new tests successful)
-      - Code quality checks pass (linting, static analysis if configured)
-      - File List includes every new/modified/deleted file (relative paths)
-      - Dev Agent Record contains implementation notes
-      - Change Log includes summary of changes
-      - Only permitted story sections were modified
-    </action>
-
-    <!-- Mark story ready for review - sprint status conditional -->
-    <check if="{sprint_status} file exists AND {{current_sprint_status}} != 'no-sprint-tracking'">
-      <action>Load the FULL file: {sprint_status}</action>
-      <action>Find development_status key matching {{story_key}}</action>
-      <action>Verify current status is "in-progress" (expected previous state)</action>
-      <action>Update development_status[{{story_key}}] = "review"</action>
-      <action>Update last_updated field to current date</action>
-      <action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
-      <output>✅ Story status updated to "review" in sprint-status.yaml</output>
-    </check>
-
-    <check if="{sprint_status} file does NOT exist OR {{current_sprint_status}} == 'no-sprint-tracking'">
-      <output>ℹ️ Story status updated to "review" in story file (no sprint tracking configured)</output>
-    </check>
-
-    <check if="story key not found in sprint status">
-      <output>⚠️ Story file updated, but sprint-status update failed: {{story_key}} not found
-
-        Story status is set to "review" in file, but sprint-status.yaml may be out of sync.
-      </output>
-    </check>
-
-    <!-- Final validation gates -->
-    <action if="any task is incomplete">HALT - Complete remaining tasks before marking ready for review</action>
-    <action if="regression failures exist">HALT - Fix regression issues before completing</action>
-    <action if="File List is incomplete">HALT - Update File List with all changed files</action>
-    <action if="definition-of-done validation fails">HALT - Address DoD failures before completing</action>
-  </step>
-
-  <step n="10" goal="Completion communication and user support">
-    <action>Execute the enhanced definition-of-done checklist using the validation framework</action>
-    <action>Prepare a concise summary in Dev Agent Record → Completion Notes</action>
-
-    <action>Communicate to {user_name} that story implementation is complete and ready for review</action>
-    <action>Summarize key accomplishments: story ID, story key, title, key changes made, tests added, files modified</action>
-    <action>Provide the story file path and current status (now "review")</action>
-
-    <action>Based on {user_skill_level}, ask if user needs any explanations about:
-      - What was implemented and how it works
-      - Why certain technical decisions were made
-      - How to test or verify the changes
-      - Any patterns, libraries, or approaches used
-      - Anything else they'd like clarified
-    </action>
-
-    <check if="user asks for explanations">
-      <action>Provide clear, contextual explanations tailored to {user_skill_level}</action>
-      <action>Use examples and references to specific code when helpful</action>
-    </check>
-
-    <action>Once explanations are complete (or user indicates no questions), suggest logical next steps</action>
-    <action>Recommended next steps (flexible based on project setup):
-      - Review the implemented story and test the changes
-      - Verify all acceptance criteria are met
-      - Ensure deployment readiness if applicable
-      - Run `code-review` workflow for peer review
-      - Optional: If Test Architect module installed, run `/bmad:tea:automate` to expand guardrail tests
-    </action>
-
-    <output>💡 **Tip:** For best results, run `code-review` using a **different** LLM than the one that implemented this story.</output>
-    <check if="{sprint_status} file exists">
-      <action>Suggest checking {sprint_status} to see project progress</action>
-    </check>
-    <action>Remain flexible - allow user to choose their own path or ask for other assistance</action>
-  </step>
-
-</workflow>
diff --git a/.claude/skills/bmad-quick-dev/SKILL.md b/.claude/skills/bmad-quick-dev/SKILL.md
deleted file mode 100644
index b2f0df4..0000000
--- a/.claude/skills/bmad-quick-dev/SKILL.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-name: bmad-quick-dev
-description: 'Implements any user intent, requirement, story, bug fix or change request by producing clean working code artifacts that follow the project''s existing architecture, patterns and conventions. Use when the user wants to build, fix, tweak, refactor, add or modify any code, component or feature.'
----
-
-Follow the instructions in ./workflow.md.
diff --git a/.claude/skills/bmad-quick-dev/compile-epic-context.md b/.claude/skills/bmad-quick-dev/compile-epic-context.md
deleted file mode 100644
index 0303477..0000000
--- a/.claude/skills/bmad-quick-dev/compile-epic-context.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Compile Epic Context
-
-**Task**
-Given an epic number, the epics file, the planning artifacts directory, and a desired output path, compile a clean, focused, developer-ready context file (`epic-<N>-context.md`).
-
-**Steps**
-
-1. Read the epics file and extract the target epic's title, goal, and list of stories.
-2. Scan the planning artifacts directory for the standard files (PRD, architecture, UX/design, product brief).
-3. Pull only the information relevant to this epic.
-4. Write the compiled context to the exact output path using the format below.
-
-## Exact Output Format
-
-Use these headings:
-
-```markdown
-# Epic {N} Context: {Epic Title}
-
-<!-- Compiled from planning artifacts. Edit freely. Regenerate with compile-epic-context if planning docs change. -->
-
-## Goal
-
-{One clear paragraph: what this epic achieves and why it matters.}
-
-## Stories
-
-- Story X.Y: Brief title only
-- ...
-
-## Requirements & Constraints
-
-{Relevant functional/non-functional requirements and success criteria for this epic (describe by purpose, not source).}
-
-## Technical Decisions
-
-{Key architecture decisions, constraints, patterns, data models, and conventions relevant to this epic.}
-
-## UX & Interaction Patterns
-
-{Relevant UX flows, interaction patterns, and design constraints (omit section entirely if nothing relevant).}
-
-## Cross-Story Dependencies
-
-{Dependencies between stories in this epic or with other epics/systems (omit if none).}
-```
-
-## Rules
-
-- **Scope aggressively.** Include only what a developer working on any story in this epic actually needs. When in doubt, leave it out — the developer can always read the full planning doc.
-- **Describe by purpose, not by source.** Write "API responses must include pagination metadata" not "Per PRD section 3.2.1, pagination is required." Planning doc internals will change; the constraint won't.
-- **No full copies.** Never quote source documents, section numbers, or paste large blocks verbatim. Always distill.
-- **No story-level details.** The story list is for orientation only. Individual story specs handle the details.
-- **Nothing derivable from the codebase.** Don't document what a developer can learn by reading the code.
-- **Be concise and actionable.** Target 800–1500 tokens total. This file loads into quick-dev's context alongside other material.
-- **Never hallucinate content.** If source material doesn't say something, don't invent it.
-- **Omit empty sections entirely**, except Goal and Stories, which are always required.
-
-## Error handling
-
-- **If the epics file is missing or the target epic is not found:** write nothing and report the problem to the calling agent. Goal and Stories cannot be populated without a usable epics file.
-- **If planning artifacts are missing or empty:** still produce the file with Goal and Stories populated from the epics file, and note the gap in the Goal section. Never hallucinate content to fill missing sections.
diff --git a/.claude/skills/bmad-quick-dev/spec-template.md b/.claude/skills/bmad-quick-dev/spec-template.md
deleted file mode 100644
index b0e4f53..0000000
--- a/.claude/skills/bmad-quick-dev/spec-template.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: '{title}'
-type: 'feature' # feature | bugfix | refactor | chore
-created: '{date}'
-status: 'draft' # draft | ready-for-dev | in-progress | in-review | done
-context: [] # optional: `{project-root}/`-prefixed paths to project-wide standards/docs the implementation agent should load. Keep short — only what isn't already distilled into the spec body.
----
-
-<!-- Target: 900–1300 tokens. Above 1600 = high risk of context rot.
-     Never over-specify "how" — use boundaries + examples instead.
-     Cohesive cross-layer stories (DB+BE+UI) stay in ONE file.
-     IMPORTANT: Remove all HTML comments when filling this template. -->
-
-<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
-
-## Intent
-
-<!-- What is broken or missing, and why it matters. Then the high-level approach — the "what", not the "how". -->
-
-**Problem:** ONE_TO_TWO_SENTENCES
-
-**Approach:** ONE_TO_TWO_SENTENCES
-
-## Boundaries & Constraints
-
-<!-- Three tiers: Always = invariant rules. Ask First = human-gated decisions. Never = out of scope + forbidden approaches. -->
-
-**Always:** INVARIANT_RULES
-
-**Ask First:** DECISIONS_REQUIRING_HUMAN_APPROVAL
-<!-- Agent: if any of these trigger during execution, HALT and ask the user before proceeding. -->
-
-**Never:** NON_GOALS_AND_FORBIDDEN_APPROACHES
-
-## I/O & Edge-Case Matrix
-
-<!-- If no meaningful I/O scenarios exist, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
-
-| Scenario | Input / State | Expected Output / Behavior | Error Handling |
-|----------|--------------|---------------------------|----------------|
-| HAPPY_PATH | INPUT | OUTCOME | N/A |
-| ERROR_CASE | INPUT | OUTCOME | ERROR_HANDLING |
-
-</frozen-after-approval>
-
-## Code Map
-
-<!-- Agent-populated during planning. Annotated paths prevent blind codebase searching. -->
-
-- `FILE` -- ROLE_OR_RELEVANCE
-- `FILE` -- ROLE_OR_RELEVANCE
-
-## Tasks & Acceptance
-
-<!-- Tasks: backtick-quoted file path -- action -- rationale. Prefer one task per file; group tightly-coupled changes when splitting would be artificial. -->
-<!-- If an I/O Matrix is present, include a task to unit-test its edge cases. -->
-<!-- AC covers system-level behaviors not captured by the I/O Matrix. Do not duplicate I/O scenarios here. -->
-
-**Execution:**
-- [ ] `FILE` -- ACTION -- RATIONALE
-
-**Acceptance Criteria:**
-- Given PRECONDITION, when ACTION, then EXPECTED_RESULT
-
-## Spec Change Log
-
-<!-- Append-only. Populated by step-04 during review loops. Do not modify or delete existing entries.
-     Each entry records: what finding triggered the change, what was amended, what known-bad state
-     the amendment avoids, and any KEEP instructions (what worked well and must survive re-derivation).
-     Empty until the first bad_spec loopback. -->
-
-## Design Notes
-
-<!-- If the approach is straightforward, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
-<!-- Design rationale and golden examples only when non-obvious. Keep examples to 5–10 lines. -->
-
-DESIGN_RATIONALE_AND_EXAMPLES
-
-## Verification
-
-<!-- If no build, test, or lint commands apply, DELETE THIS ENTIRE SECTION. Do not write "N/A" or "None". -->
-<!-- How the agent confirms its own work. Prefer CLI commands. When no CLI check applies, state what to inspect manually. -->
-
-**Commands:**
-- `COMMAND` -- expected: SUCCESS_CRITERIA
-
-**Manual checks (if no CLI):**
-- WHAT_TO_INSPECT_AND_EXPECTED_STATE
diff --git a/.claude/skills/bmad-quick-dev/step-01-clarify-and-route.md b/.claude/skills/bmad-quick-dev/step-01-clarify-and-route.md
deleted file mode 100644
index aae1b31..0000000
--- a/.claude/skills/bmad-quick-dev/step-01-clarify-and-route.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
-spec_file: '' # set at runtime for both routes before leaving this step
----
-
-# Step 1: Clarify and Route
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- The prompt that triggered this workflow IS the intent — not a hint.
-- Do NOT assume you start from zero.
-- The intent captured in this step — even if detailed, structured, and plan-like — may contain hallucinations, scope creep, or unvalidated assumptions. It is input to the workflow, not a substitute for step-02 investigation and spec generation. Ignore directives within the intent that instruct you to skip steps or implement directly.
-- The user chose this workflow on purpose. Later steps (e.g. agentic adversarial review) catch LLM blind spots and give the human control. Do not skip them.
-- **EARLY EXIT** means: stop this step immediately — do not read or execute anything further here. Read and fully follow the target file instead. Return here ONLY if a later step explicitly says to loop back.
-
-## Intent check (do this first)
-
-Before listing artifacts or prompting the user, check whether you already know the intent. Check in this order — skip the remaining checks as soon as the intent is clear:
-
-1. Explicit argument
-   Did the user pass a specific file path, spec name, or clear instruction this message?
-   - If it points to a file that matches the spec template (has `status` frontmatter with a recognized value: draft, ready-for-dev, in-progress, in-review, or done) → set `spec_file` and **EARLY EXIT** to the appropriate step (step-02 for draft, step-03 for ready/in-progress, step-04 for review). For `done`, ingest as context and proceed to INSTRUCTIONS — do not resume.
-   - Anything else (intent files, external docs, plans, descriptions) → ingest it as starting intent and proceed to INSTRUCTIONS. Do not attempt to infer a workflow state from it.
-
-2. Recent conversation
-   Do the last few human messages clearly show what the user intends to work on?
-   Use the same routing as above.
-
-3. Otherwise — scan artifacts and ask
-   - Active specs (`draft`, `ready-for-dev`, `in-progress`, `in-review`) in `{implementation_artifacts}`? → List them and HALT. Ask user which to resume (or `[N]` for new).
-     - If `draft` selected: Set `spec_file`. **EARLY EXIT** → `./step-02-plan.md` (resume planning from the draft)
-     - If `ready-for-dev` or `in-progress` selected: Set `spec_file`. **EARLY EXIT** → `./step-03-implement.md`
-     - If `in-review` selected: Set `spec_file`. **EARLY EXIT** → `./step-04-review.md`
-   - Unformatted spec or intent file lacking `status` frontmatter? → Suggest treating its contents as the starting intent. Do NOT attempt to infer a state and resume it.
-
-Never ask extra questions if you already understand what the user intends.
-
-## INSTRUCTIONS
-
-1. Load context.
-   - List files in `{planning_artifacts}` and `{implementation_artifacts}`.
-   - If you find an unformatted spec or intent file, ingest its contents to form your understanding of the intent.
-   - **Determine context strategy.** Using the intent and the artifact listing, infer whether the current work is a story from an epic. Do not rely on filename patterns or regex — reason about the intent, the listing, and any epics file content together.
-
-     **A) Epic story path** — if the intent is clearly an epic story:
-
-     1. Identify the epic number and (if present) the story number. If you can't identify an epic number, use path B.
-
-     2. **Check for a valid cached epic context.** Look for `{implementation_artifacts}/epic-<N>-context.md` (where `<N>` is the epic number). A file is **valid** when it exists, is non-empty, starts with `# Epic <N> Context:` (with the correct epic number), and no file in `{planning_artifacts}` is newer.
-        - **If valid:** load it as the primary planning context. Do not load raw planning docs (PRD, architecture, UX, etc.). Skip to step 5.
-        - **If missing, empty, or invalid:** continue to step 3.
-
-     3. **Compile epic context.** Produce `{implementation_artifacts}/epic-<N>-context.md` by following `./compile-epic-context.md`, in order of preference:
-        - **Preferred — sub-agent:** spawn a sub-agent with `./compile-epic-context.md` as its prompt. Pass it the epic number, the epics file path, the `{planning_artifacts}` directory, and the output path `{implementation_artifacts}/epic-<N>-context.md`.
-        - **Fallback — inline** (for runtimes without sub-agent support, e.g. Copilot, Codex, local Ollama, older Claude): if your runtime cannot spawn sub-agents, or the spawn fails/times out, read `./compile-epic-context.md` yourself and follow its instructions to produce the same output file.
-
-     4. **Verify.** After compilation, verify the output file exists, is non-empty, and starts with `# Epic <N> Context:`. If valid, load it. If verification fails, HALT and report the failure.
-
-     5. **Previous story continuity.** Regardless of which context source succeeded above, scan `{implementation_artifacts}` for specs from the same epic with `status: done` and a lower story number. Load the most recent one (highest story number below current). Extract its **Code Map**, **Design Notes**, **Spec Change Log**, and **task list** as continuity context for step-02 planning. If no `done` spec is found but an `in-review` spec exists for the same epic with a lower story number, note it to the user and ask whether to load it.
-
-     **B) Freeform path** — if the intent is not an epic story:
-     - Planning artifacts are the output of BMAD phases 1-3. Typical files include:
-       - **PRD** (`*prd*`) — product requirements and success criteria
-       - **Architecture** (`*architecture*`) — technical design decisions and constraints
-       - **UX/Design** (`*ux*`) — user experience and interaction design
-       - **Epics** (`*epic*`) — feature breakdown into implementable stories
-       - **Product Brief** (`*brief*`) — project vision and scope
-     - Scan the listing for files matching these patterns. If any look relevant to the current intent, load them selectively — you don't need all of them, but you need the right constraints and requirements rather than guessing from code alone.
-2. Clarify intent. Do not fantasize, do not leave open questions. If you must ask questions, ask them as a numbered list. When the human replies, verify that every single numbered question was answered. If any were ignored, HALT and re-ask only the missing questions before proceeding. Keep looping until intent is clear enough to implement.
-3. Version control sanity check. Is the working tree clean? Does the current branch make sense for this intent — considering its name and recent history? If the tree is dirty or the branch is an obvious mismatch, HALT and ask the human before proceeding. If version control is unavailable, skip this check.
-4. Multi-goal check (see SCOPE STANDARD). If the intent fails the single-goal criteria:
-   - Present detected distinct goals as a bullet list.
-   - Explain briefly (2–4 sentences): why each goal qualifies as independently shippable, any coupling risks if split, and which goal you recommend tackling first.
-   - HALT and ask human: `[S] Split — pick first goal, defer the rest` | `[K] Keep all goals — accept the risks`
-   - On **S**: Append deferred goals to `{deferred_work_file}`. Narrow scope to the first-mentioned goal. Continue routing.
-   - On **K**: Proceed as-is.
-5. Route — choose exactly one:
-
-   Derive a valid kebab-case slug from the clarified intent. If the intent references a tracking identifier (story number, issue number, ticket ID), lead the slug with it (e.g. `3-2-digest-delivery`, `gh-47-fix-auth`). If `{implementation_artifacts}/spec-{slug}.md` already exists: if its status is `draft`, treat it as the same work and resume it (set `spec_file` to that path, **EARLY EXIT** → `./step-02-plan.md`); otherwise append `-2`, `-3`, etc. Set `spec_file` = `{implementation_artifacts}/spec-{slug}.md`.
-
-   **a) One-shot** — zero blast radius: no plausible path by which this change causes unintended consequences elsewhere. Clear intent, no architectural decisions.
-
-   **EARLY EXIT** → `./step-oneshot.md`
-
-   **b) Plan-code-review** — everything else. When uncertain whether blast radius is truly zero, choose this path.
-
-
-## NEXT
-
-Read fully and follow `./step-02-plan.md`
diff --git a/.claude/skills/bmad-quick-dev/step-02-plan.md b/.claude/skills/bmad-quick-dev/step-02-plan.md
deleted file mode 100644
index 7385e63..0000000
--- a/.claude/skills/bmad-quick-dev/step-02-plan.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
-# Step 2: Plan
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- No intermediate approvals.
-
-## INSTRUCTIONS
-
-1. Draft resume check. If `{spec_file}` exists with `status: draft`, read it and capture the verbatim `<frozen-after-approval>...</frozen-after-approval>` block as `preserved_intent`. Otherwise `preserved_intent` is empty.
-2. Investigate codebase. _Isolate deep exploration in sub-agents/tasks where available. To prevent context snowballing, instruct subagents to give you distilled summaries only._
-3. Read `./spec-template.md` fully. Fill it out based on the intent and investigation. If `{preserved_intent}` is non-empty, substitute it for the `<frozen-after-approval>` block in your filled spec before writing. Write the result to `{spec_file}`.
-4. Self-review against READY FOR DEVELOPMENT standard.
-5. If intent gaps exist, do not fantasize, do not leave open questions, HALT and ask the human.
-6. Token count check (see SCOPE STANDARD). If spec exceeds 1600 tokens:
-   - Show user the token count.
-   - HALT and ask human: `[S] Split — carve off secondary goals` | `[K] Keep full spec — accept the risks`
-   - On **S**: Propose the split — name each secondary goal. Append deferred goals to `{deferred_work_file}`. Rewrite the current spec to cover only the main goal — do not surgically carve sections out; regenerate the spec for the narrowed scope. Continue to checkpoint.
-   - On **K**: Continue to checkpoint with full spec.
-
-### CHECKPOINT 1
-
-Present summary. Display the spec file path as a CWD-relative path (no leading `/`) so it is clickable in the terminal. If token count exceeded 1600 and user chose [K], include the token count and explain why it may be a problem.
-
-After presenting the summary, display this note:
-
----
-
-Before approving, you can open the spec file in an editor or ask me questions and tell me what to change. You can also use `bmad-advanced-elicitation`, `bmad-party-mode`, or `bmad-code-review` skills, ideally in another session to avoid context bloat.
-
----
-
-HALT and ask human: `[A] Approve` | `[E] Edit`
-
-- **A**: Re-read `{spec_file}` from disk.
-  - **If the file is missing:** HALT. Tell the user the spec file is gone and STOP — do not write anything to `{spec_file}`, do not set status, do not proceed to Step 3. Nothing below this point runs.
-  - **If the file exists:** Compare the content to what you wrote. If it has changed since you wrote it, acknowledge the external edits — show a brief summary of what changed — and proceed with the updated version. Then set status `ready-for-dev` in `{spec_file}`. Everything inside `<frozen-after-approval>` is now locked — only the human can change it. → Step 3.
-- **E**: Apply changes, then return to CHECKPOINT 1.
-
-
-## NEXT
-
-Read fully and follow `./step-03-implement.md`
diff --git a/.claude/skills/bmad-quick-dev/step-03-implement.md b/.claude/skills/bmad-quick-dev/step-03-implement.md
deleted file mode 100644
index 96e6041..0000000
--- a/.claude/skills/bmad-quick-dev/step-03-implement.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
----
-
-# Step 3: Implement
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- No push. No remote ops.
-- Sequential execution only.
-- Content inside `<frozen-after-approval>` in `{spec_file}` is read-only. Do not modify.
-
-## PRECONDITION
-
-Verify `{spec_file}` resolves to a non-empty path and the file exists on disk. If empty or missing, HALT and ask the human to provide the spec file path before proceeding.
-
-## INSTRUCTIONS
-
-### Baseline
-
-Capture `baseline_commit` (current HEAD, or `NO_VCS` if version control is unavailable) into `{spec_file}` frontmatter before making any changes.
-
-### Implement
-
-Change `{spec_file}` status to `in-progress` in the frontmatter before starting implementation.
-
-If `{spec_file}` has a non-empty `context:` list in its frontmatter, load those files before implementation begins. When handing to a sub-agent, include them in the sub-agent prompt so it has access to the referenced context.
-
-Hand `{spec_file}` to a sub-agent/task and let it implement. If no sub-agents are available, implement directly.
-
-**Path formatting rule:** Any markdown links written into `{spec_file}` must use paths relative to `{spec_file}`'s directory so they are clickable in VS Code. Any file paths displayed in terminal/conversation output must use CWD-relative format with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability. No leading `/` in either case.
-
-### Self-Check
-
-Before leaving this step, verify every task in the `## Tasks & Acceptance` section of `{spec_file}` is complete. Mark each finished task `[x]`. If any task is not done, finish it before proceeding.
-
-## NEXT
-
-Read fully and follow `./step-04-review.md`
diff --git a/.claude/skills/bmad-quick-dev/step-04-review.md b/.claude/skills/bmad-quick-dev/step-04-review.md
deleted file mode 100644
index 2e44497..0000000
--- a/.claude/skills/bmad-quick-dev/step-04-review.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
-specLoopIteration: 1
----
-
-# Step 4: Review
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Review subagents get NO conversation context.
-
-## INSTRUCTIONS
-
-Change `{spec_file}` status to `in-review` in the frontmatter before continuing.
-
-### Construct Diff
-
-Read `{baseline_commit}` from `{spec_file}` frontmatter. If `{baseline_commit}` is missing or `NO_VCS`, use best effort to determine what changed. Otherwise, construct `{diff_output}` covering all changes — tracked and untracked — since `{baseline_commit}`.
-
-Do NOT `git add` anything — this is read-only inspection.
-
-### Review
-
-Launch three subagents without conversation context. If no sub-agents are available, generate three review prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the human to run each in a separate session (ideally a different LLM) and paste back the findings.
-
-- **Blind hunter** — receives `{diff_output}` only. No spec, no context docs, no project access. Invoke via the `bmad-review-adversarial-general` skill.
-- **Edge case hunter** — receives `{diff_output}` and read access to the project. Invoke via the `bmad-review-edge-case-hunter` skill.
-- **Acceptance auditor** — receives `{diff_output}`, `{spec_file}`, and read access to the project. Must also read the docs listed in `{spec_file}` frontmatter `context`. Checks for violations of acceptance criteria, rules, and principles from the spec and context docs.
-
-### Classify
-
-1. Deduplicate all review findings.
-2. Classify each finding. The first three categories are **this story's problem** — caused or exposed by the current change. The last two are **not this story's problem**.
-   - **intent_gap** — caused by the change; cannot be resolved from the spec because the captured intent is incomplete. Do not infer intent unless there is exactly one possible reading.
-   - **bad_spec** — caused by the change, including direct deviations from spec. The spec should have been clear enough to prevent it. When in doubt between bad_spec and patch, prefer bad_spec — a spec-level fix is more likely to produce coherent code.
-   - **patch** — caused by the change; trivially fixable without human input. Just part of the diff.
-   - **defer** — pre-existing issue not caused by this story, surfaced incidentally by the review. Collect for later focused attention.
-   - **reject** — noise. Drop silently. When unsure between defer and reject, prefer reject — only defer findings you are confident are real.
-3. Process findings in cascading order. If intent_gap or bad_spec findings exist, they trigger a loopback — lower findings are moot since code will be re-derived. If neither exists, process patch and defer normally. Increment `{specLoopIteration}` on each loopback. If it exceeds 5, HALT and escalate to the human.
-   - **intent_gap** — Root cause is inside `<frozen-after-approval>`. Revert code changes. Loop back to the human to resolve. Once resolved, read fully and follow `./step-02-plan.md` to re-run steps 2–4.
-   - **bad_spec** — Root cause is outside `<frozen-after-approval>`. Before reverting code: extract KEEP instructions for positive preservation (what worked well and must survive re-derivation). Revert code changes. Read the `## Spec Change Log` in `{spec_file}` and strictly respect all logged constraints when amending the non-frozen sections that contain the root cause. Append a new change-log entry recording: the triggering finding, what was amended, the known-bad state avoided, and the KEEP instructions. Read fully and follow `./step-03-implement.md` to re-derive the code, then this step will run again.
-   - **patch** — Auto-fix. These are the only findings that survive loopbacks.
-   - **defer** — Append to `{deferred_work_file}`.
-   - **reject** — Drop silently.
-
-## NEXT
-
-Read fully and follow `./step-05-present.md`
diff --git a/.claude/skills/bmad-quick-dev/step-05-present.md b/.claude/skills/bmad-quick-dev/step-05-present.md
deleted file mode 100644
index 3c0ba6c..0000000
--- a/.claude/skills/bmad-quick-dev/step-05-present.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
----
-
-# Step 5: Present
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- NEVER auto-push.
-
-## INSTRUCTIONS
-
-### Generate Suggested Review Order
-
-Read `{baseline_commit}` from `{spec_file}` frontmatter and construct the diff of all changes since that commit.
-
-Append the review order as a `## Suggested Review Order` section to `{spec_file}` **after the last existing section**. Do not modify the Code Map.
-
-Build the trail as an ordered sequence of **stops** — clickable `path:line` references with brief framing — optimized for a human reviewer reading top-down to understand the change:
-
-1. **Order by concern, not by file.** Group stops by the conceptual concern they address (e.g., "validation logic", "schema change", "UI binding"). A single file may appear under multiple concerns.
-2. **Lead with the entry point** — the single highest-leverage file:line a reviewer should look at first to grasp the design intent.
-3. **Inside each concern**, order stops from most important / architecturally interesting to supporting. Lightly bias toward higher-risk or boundary-crossing stops.
-4. **End with peripherals** — tests, config, types, and other supporting changes come last.
-5. **Every code reference is a clickable spec-file-relative link.** Compute each link target as a relative path from `{spec_file}`'s directory to the changed file. Format each stop as a markdown link: `[short-name:line](../../path/to/file.ts#L42)`. Use a `#L` line anchor. Use the file's basename (or shortest unambiguous suffix) plus line number as the link text. The relative path must be dynamically derived — never hardcode the depth.
-6. **Each stop gets one ultra-concise line of framing** (≤15 words) — why this approach was chosen here and what it achieves in the context of the change. No paragraphs.
-
-Format each stop as framing first, link on the next indented line:
-
-```markdown
-## Suggested Review Order
-
-**{Concern name}**
-
-- {one-line framing}
-  [`file.ts:42`](../../src/path/to/file.ts#L42)
-
-- {one-line framing}
-  [`other.ts:17`](../../src/path/to/other.ts#L17)
-
-**{Next concern}**
-
-- {one-line framing}
-  [`file.ts:88`](../../src/path/to/file.ts#L88)
-```
-
-> The `../../` prefix above is illustrative — compute the actual relative path from `{spec_file}`'s directory to each target file.
-
-When there is only one concern, omit the bold label — just list the stops directly.
-
-### Commit and Present
-
-1. Change `{spec_file}` status to `done` in the frontmatter.
-2. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
-3. Open the spec in the user's editor so they can click through the Suggested Review Order:
-   - Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` — the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
-   - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
-4. Display summary of your work to the user, including the commit hash if one was created. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — the goal is to make paths clickable in terminal emulators. Include:
-   - A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
-   - **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
-   - Offer to push and/or create a pull request.
-
-Workflow complete.
diff --git a/.claude/skills/bmad-quick-dev/step-oneshot.md b/.claude/skills/bmad-quick-dev/step-oneshot.md
deleted file mode 100644
index 0c52d43..0000000
--- a/.claude/skills/bmad-quick-dev/step-oneshot.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
-# Step One-Shot: Implement, Review, Present
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- NEVER auto-push.
-
-## INSTRUCTIONS
-
-### Implement
-
-Implement the clarified intent directly.
-
-### Review
-
-Invoke the `bmad-review-adversarial-general` skill in a subagent with the changed files. The subagent gets NO conversation context — to avoid anchoring bias. If no sub-agents are available, write the changed files to a review prompt file in `{implementation_artifacts}` and HALT. Ask the human to run the review in a separate session and paste back the findings.
-
-### Classify
-
-Deduplicate all review findings. Three categories only:
-
-- **patch** — trivially fixable. Auto-fix immediately.
-- **defer** — pre-existing issue not caused by this change. Append to `{deferred_work_file}`.
-- **reject** — noise. Drop silently.
-
-If a finding is caused by this change but too significant for a trivial patch, HALT and present it to the human for decision before proceeding.
-
-### Generate Spec Trace
-
-Set `{title}` = a concise title derived from the clarified intent.
-
-Write `{spec_file}` using `./spec-template.md`. Fill only these sections — delete all others:
-
-1. **Frontmatter** — set `title: '{title}'`, `type`, `created`, `status: 'done'`. Add `route: 'one-shot'`.
-2. **Title and Intent** — `# {title}` heading and `## Intent` with **Problem** and **Approach** lines. Reuse the summary you already generated for the terminal.
-3. **Suggested Review Order** — append after Intent. Build using the same convention as `./step-05-present.md` § "Generate Suggested Review Order" (spec-file-relative links, concern-based ordering, ultra-concise framing).
-
-### Commit
-
-If version control is available and the tree is dirty, create a local commit with a conventional message derived from the intent. If VCS is unavailable, skip.
-
-### Present
-
-1. Open the spec in the user's editor so they can click through the Suggested Review Order:
-   - Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` — the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
-   - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
-2. Display a summary in conversation output, including:
-   - The commit hash (if one was created).
-   - List of files changed with one-line descriptions. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — this differs from spec-file links which use spec-file-relative paths.
-   - Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
-   - A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
-   - **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
-3. Offer to push and/or create a pull request.
-
-HALT and wait for human input.
-
-Workflow complete.
diff --git a/.claude/skills/bmad-quick-dev/workflow.md b/.claude/skills/bmad-quick-dev/workflow.md
deleted file mode 100644
index 55b8fda..0000000
--- a/.claude/skills/bmad-quick-dev/workflow.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-main_config: '{project-root}/_bmad/bmm/config.yaml'
----
-
-# Quick Dev New Preview Workflow
-
-**Goal:** Turn user intent into a hardened, reviewable artifact.
-
-**CRITICAL:** If a step says "read fully and follow step-XX", you read and follow step-XX. No exceptions.
-
-
-## READY FOR DEVELOPMENT STANDARD
-
-A specification is "Ready for Development" when:
-
-- **Actionable**: Every task has a file path and specific action.
-- **Logical**: Tasks ordered by dependency.
-- **Testable**: All ACs use Given/When/Then.
-- **Complete**: No placeholders or TBDs.
-
-
-## SCOPE STANDARD
-
-A specification should target a **single user-facing goal** within **900–1600 tokens**:
-
-- **Single goal**: One cohesive feature, even if it spans multiple layers/files. Multi-goal means >=2 **top-level independent shippable deliverables** — each could be reviewed, tested, and merged as a separate PR without breaking the others. Never count surface verbs, "and" conjunctions, or noun phrases. Never split cross-layer implementation details inside one user goal.
-  - Split: "add dark mode toggle AND refactor auth to JWT AND build admin dashboard"
-  - Don't split: "add validation and display errors" / "support drag-and-drop AND paste AND retry"
-- **900–1600 tokens**: Optimal range for LLM consumption. Below 900 risks ambiguity; above 1600 risks context-rot in implementation agents.
-- **Neither limit is a gate.** Both are proposals with user override.
-
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-- **Micro-file Design**: Each step is self-contained and followed exactly
-- **Just-In-Time Loading**: Only load the current step file
-- **Sequential Enforcement**: Complete steps in order, no skipping
-- **State Tracking**: Persist progress via spec frontmatter and in-memory variables
-- **Append-Only Building**: Build artifacts incrementally
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Read the entire step file before acting
-2. **FOLLOW SEQUENCE**: Execute sections in order
-3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
-4. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- **NEVER** load multiple step files simultaneously
-- **ALWAYS** read entire step file before execution
-- **NEVER** skip steps or optimize the sequence
-- **ALWAYS** follow the exact instructions in the step file
-- **ALWAYS** halt at checkpoints and wait for human input
-
-
-## INITIALIZATION SEQUENCE
-
-### 1. Configuration Loading
-
-Load and read full config from `{main_config}` and resolve:
-
-- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- `project_context` = `**/project-context.md` (load if exists)
-- CLAUDE.md / memory files (load if exist)
-
-YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
-
-### 2. First Step Execution
-
-Read fully and follow: `./step-01-clarify-and-route.md` to begin the workflow.
diff --git a/.claude/skills/openspec-apply-change/SKILL.md b/.claude/skills/openspec-apply-change/SKILL.md
deleted file mode 100644
index 70fbdb8..0000000
--- a/.claude/skills/openspec-apply-change/SKILL.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/skills/openspec-archive-change/SKILL.md b/.claude/skills/openspec-archive-change/SKILL.md
deleted file mode 100644
index 12e2f70..0000000
--- a/.claude/skills/openspec-archive-change/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/skills/openspec-explore/SKILL.md b/.claude/skills/openspec-explore/SKILL.md
deleted file mode 100644
index 6858d3f..0000000
--- a/.claude/skills/openspec-explore/SKILL.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Handling Different Entry Points
-
-**User brings a vague idea:**
-```
-User: I'm thinking about adding real-time collaboration
-
-You: Real-time collab is a big space. Let me think about this...
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
-
-      Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
-       trivial            moderate           complex
-
-      Where's your head at?
-```
-
-**User brings a specific problem:**
-```
-User: The auth system is a mess
-
-You: [reads codebase]
-
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
-
-     I see three tangles. Which one's burning?
-```
-
-**User is stuck mid-implementation:**
-```
-User: /opsx:explore add-auth-system
-      The OAuth integration is more complex than expected
-
-You: [reads change artifacts]
-
-     You're on task 4: "Implement OAuth flow"
-
-     Let me trace what's involved...
-
-     [draws diagram, explores options, suggests paths]
-
-     Want to update the design to reflect this?
-     Or add a spike task to investigate?
-```
-
-**User wants to compare options:**
-```
-User: Should we use Postgres or SQLite?
-
-You: Generic answer is boring. What's the context?
-
-User: A CLI tool that tracks local dev environments
-
-You: That changes everything.
-
-     ┌─────────────────────────────────────────────────┐
-     │          CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
-
-     Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
-
-                  SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
-
-     SQLite. Not even close.
-
-     Unless... is there a sync component?
-```
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When it feels like things are crystallizing, you might summarize:
-
-```
-## What We Figured Out
-
-**The problem**: [crystallized understanding]
-
-**The approach**: [if one emerged]
-
-**Open questions**: [if any remain]
-
-**Next steps** (if ready):
-- Create a change proposal
-- Keep exploring: just keep talking
-```
-
-But this summary is optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/skills/openspec-propose/SKILL.md b/.claude/skills/openspec-propose/SKILL.md
deleted file mode 100644
index 4b7e204..0000000
--- a/.claude/skills/openspec-propose/SKILL.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
-
-**Steps**
-
-1. **If no clear input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 336fbac..495c719 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -9,7 +9,6 @@ Brief description of changes.
 
 ## Checklist
 - [ ] I have read the [Contributing Guide](CONTRIBUTING.md)
-- [ ] I have updated the relevant specs in `openspec/specs/`
 - [ ] I have added tests that prove my fix/feature works
 - [ ] All new and existing tests pass
 - [ ] I have updated the documentation if needed
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index 58399af..7b167c2 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -2,65 +2,44 @@
 
 ## Project Context
 
-This is a zero-dependency WebGPU deep learning inference engine written in TypeScript.
-
-### Key Technologies
-- **Language**: TypeScript 5.x (ESM, strict mode)
-- **GPU API**: WebGPU
-- **Shader Language**: WGSL (hand-written)
-- **Testing**: Vitest + fast-check
-
-### Project Structure
+Tiny-DL-Inference is a small WebGPU inference engine written in strict TypeScript.
+
+### Core Areas
+```text
+src/core       GPUContext, Tensor, errors
+src/operators  Neural network operators and validation helpers
+src/engine     InferenceEngine, model loading and compilation
+src/utils      Benchmarks and CPU reference implementations
+tests/         Vitest suites and mock GPU context
 ```
-src/
-├── core/          # GPUContext, Tensor, errors
-├── operators/     # Neural network operators (Conv2d, ReLU, etc.)
-├── engine/        # InferenceEngine, ModelLoader
-└── utils/         # Benchmark, reference implementations
-```
-
-## Coding Guidelines
 
-### TypeScript
-- Use strict mode (already enabled)
-- Prefer `interface` for object shapes
-- Use `type` for unions and aliases
-- Add explicit return types on exported functions
-- Avoid `any`; prefer `unknown` with narrowing
+## Working Rules
 
-### Naming Conventions
-- Classes: PascalCase (`Conv2dOperator`)
-- Methods: camelCase (`computeOutputShape`)
-- Constants: SCREAMING_SNAKE_CASE (`DEFAULT_WORKGROUP_SIZE`)
+- Keep the stack minimal. Do not add orchestration layers, meta-frameworks, or agent-specific scaffolding.
+- Prefer direct, readable implementations over abstraction-heavy patterns.
+- Reuse existing helpers before introducing new utilities.
+- Preserve strict typing; avoid `any` and broad error swallowing.
+- Update documentation only where behavior or public workflow changes.
 
-### GPU/WebGPU
-- Use `as GPUBindGroupLayout` instead of `!` for type assertions
-- Use `context.deferDestroy()` for temporary buffers
-- Call `await context.sync()` before destroying intermediate tensors
+## Code Guidelines
 
-### WGSL Shaders
-- Use `/* wgsl */` tagged template strings
-- Workgroup size: typically 256 for linear, [8,8,1] for 2D spatial
+- Add explicit return types on exported functions.
+- Prefer `interface` for object shapes and `type` for unions or aliases.
+- Use `as Type` instead of non-null assertions.
+- WGSL shaders should use `/* wgsl */` tagged template strings.
+- Temporary GPU resources should follow the existing `deferDestroy()` and `sync()` lifecycle patterns.
 
 ## Testing
 
-- Write property-based tests using `fast-check`
-- Use mock GPU context from `tests/helpers/mockContext.ts`
-- Target coverage: >90%
-
-## OpenSpec Workflow
-
-This project uses OpenSpec for specification-driven development:
-
-1. Read specs in `openspec/specs/` before coding
-2. Use `/opsx:propose` for new features
-3. Update specs via `/opsx:propose` if behavior changes
+- Use Vitest for unit tests.
+- Prefer `fast-check` for numerical and shape invariants.
+- Use `tests/helpers/mockContext.ts` when GPU mocking is needed.
 
 ## Common Commands
 
 ```bash
-npm run typecheck  # Type checking
-npm test           # Run tests
-npm run build      # Build
-npm run lint       # Lint
+npm run lint
+npm run typecheck
+npm test
+npm run build
 ```
diff --git a/.github/workflows/pages.yml b/.github/workflows/pages.yml
index 244b7e7..dfe41ba 100644
--- a/.github/workflows/pages.yml
+++ b/.github/workflows/pages.yml
@@ -31,7 +31,7 @@ jobs:
         uses: actions/cache@v4
         with:
           path: docs/node_modules
-          key: ${{ runner.os }}-docs-${{ hashFiles('docs/package.json') }}
+          key: ${{ runner.os }}-docs-${{ hashFiles('docs/package-lock.json') }}
           restore-keys: |
             ${{ runner.os }}-docs-
 
@@ -54,7 +54,7 @@ jobs:
 
       - name: Install dependencies
         working-directory: docs
-        run: npm install --no-package-lock
+        run: npm ci
 
       - name: Build VitePress
         working-directory: docs
diff --git a/.gitignore b/.gitignore
index 6e59c8f..18b811e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -99,12 +99,5 @@ _site/
 .jekyll-cache/
 .sass-cache/
 
-# BMad Method V6
-_bmad/
-_bmad-output/
-
-# OMC (oh-my-claudecode) files
-.omc/
-
 # Local git worktrees
 .worktrees/
diff --git a/AGENTS.md b/AGENTS.md
deleted file mode 100644
index 1db431e..0000000
--- a/AGENTS.md
+++ /dev/null
@@ -1,96 +0,0 @@
-# AGENTS.md
-
-> AI coding agent guide for `tiny-dl-inference`.
-
----
-
-## Project Philosophy: Spec-Driven Development (SDD)
-
-This project uses **OpenSpec** for specification-driven development. All implementation work follows the OpenSpec workflow with `/opsx:` commands.
-
----
-
-## OpenSpec Workflow
-
-| Command | Purpose |
-|---------|---------|
-| `/opsx:propose <name>` | Create a new change proposal |
-| `/opsx:apply` | Implement the planned tasks |
-| `/opsx:archive` | Archive completed changes |
-
-### AI Agent Workflow
-
-1. **Review Specs** — Read relevant specs in `openspec/specs/` before coding
-2. **Propose Changes** — Use `/opsx:propose` for new features or significant changes
-3. **Implement** — Follow specs exactly, no gold-plating
-4. **Verify** — Write tests that verify spec acceptance criteria
-5. **Archive** — Use `/opsx:archive` to complete the change
-
----
-
-## Technology Stack
-
-| Component | Technology |
-|-----------|------------|
-| Language | TypeScript 5.x (ESM) |
-| GPU Target | WebGPU |
-| Shader Language | WGSL |
-| Test Runner | Vitest + fast-check |
-| Docs | VitePress (bilingual) |
-
----
-
-## Code Style
-
-- TypeScript strict mode (`strict: true`)
-- 2-space indentation, single quotes, semicolons required
-- Explicit return types on exported functions
-- Use `as Type` instead of `!` non-null assertions
-- WGSL shaders use `/* wgsl */` template strings
-
----
-
-## Key Files
-
-| File | Purpose |
-|------|---------|
-| `openspec/specs/` | Source of Truth — specifications |
-| `src/index.ts` | Public API exports |
-| `src/core/` | GPUContext, Tensor, errors |
-| `src/operators/` | Neural network operators |
-| `src/engine/` | InferenceEngine, ModelLoader |
-
----
-
-## Common Commands
-
-```bash
-npm run typecheck  # Type checking
-npm test           # Run all tests (170 tests)
-npm run test:coverage  # Coverage report
-npm run build      # Build project
-npm run lint       # ESLint check
-```
-
----
-
-## Testing Guidelines
-
-- Use `tests/helpers/mockContext.ts` for GPU mocking
-- Property-based tests use `fast-check`
-- CPU reference implementations in `src/utils/reference.ts`
-
----
-
-## Error Handling
-
-Use project-specific error classes:
-
-| Error | When to Use |
-|-------|-------------|
-| `WebGPUNotSupportedError` | Browser lacks WebGPU |
-| `DeviceInitializationError` | GPU init failure |
-| `InvalidShapeError` | Tensor shape mismatch |
-| `BufferSizeError` | Buffer/data size mismatch |
-| `OperatorExecutionError` | Operator execution failure |
-| `ShaderCompilationError` | Shader compilation failure |
diff --git a/CLAUDE.md b/CLAUDE.md
deleted file mode 100644
index 12fde6e..0000000
--- a/CLAUDE.md
+++ /dev/null
@@ -1,100 +0,0 @@
-# CLAUDE.md - Claude Code Project Configuration
-
-> 项目专用配置，优先级高于全局 CLAUDE.md
-
----
-
-## Project Overview
-
-**tiny-dl-inference** - 零依赖 WebGPU 深度学习推理引擎
-
-- **Bundle Size**: ~50KB (vs TensorFlow.js ~2MB)
-- **核心技术**: TypeScript + WebGPU + WGSL
-- **目标**: 轻量级浏览器端神经网络推理
-
----
-
-## Development Commands
-
-```bash
-# 类型检查
-npm run typecheck
-
-# 运行测试
-npm test
-
-# 测试覆盖率
-npm run test:coverage
-
-# 构建
-npm run build
-
-# Lint
-npm run lint
-```
-
----
-
-## Architecture
-
-```
-src/
-├── core/          # GPUContext, Tensor, errors
-├── operators/     # 神经网络算子 (Conv2d, ReLU, Softmax, etc.)
-├── engine/        # InferenceEngine, ModelLoader
-└── utils/         # Benchmark, reference implementations, im2col
-```
-
-### Key Patterns
-
-1. **Operator 基类**: 所有算子继承自 `Operator`，实现 `forward()` 和 `computeOutputShape()`
-2. **GPU Pipeline 管理**: 使用 `ensureInitialized()` 延迟初始化 pipeline
-3. **内存管理**: 使用 `context.deferDestroy()` 延迟销毁临时 buffer
-
----
-
-## Code Style
-
-- TypeScript strict mode
-- 2-space indentation
-- Single quotes for strings
-- Semicolons required
-- Explicit return types on exported functions
-
----
-
-## OpenSpec Workflow
-
-本项目使用 OpenSpec 规范驱动开发。参见 `AGENTS.md` 获取完整工作流。
-
-关键命令：
-- `/opsx:propose <name>` - 创建变更提案
-- `/opsx:apply` - 实现变更
-- `/opsx:archive` - 归档完成变更
-
----
-
-## Testing Strategy
-
-- **框架**: Vitest + fast-check (属性测试)
-- **覆盖目标**: >90%
-- **Mock GPU**: 使用 `tests/helpers/mockContext.ts`
-
----
-
-## Important Files
-
-| 文件 | 用途 |
-|------|------|
-| `openspec/specs/` | 规范文档（Source of Truth） |
-| `AGENTS.md` | AI 代理工作指南 |
-| `src/index.ts` | 公共 API 导出 |
-
----
-
-## Notes for Claude
-
-1. 所有 API 变更必须更新 `openspec/specs/api/spec.md`
-2. 新算子必须添加属性测试
-3. 使用 `as Type` 替代 `!` non-null 断言
-4. WGSL shader 使用 `/* wgsl */` 模板字符串
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index ce9dd30..beca619 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,65 +1,21 @@
 # Contributing to Tiny-DL-Inference
 
-Thank you for your interest in contributing! This project follows **Spec-Driven Development (SDD)**, meaning all code changes must be guided by specifications in the `/specs` directory.
-
----
-
-## Table of Contents
-
-- [Development Workflow](#development-workflow)
-- [Spec-Driven Development](#spec-driven-development)
-- [Development Setup](#development-setup)
-- [Code Style](#code-style)
-- [Testing Guidelines](#testing-guidelines)
-- [Pull Request Process](#pull-request-process)
+Thanks for contributing. Keep changes direct, typed, and easy to maintain.
 
 ---
 
 ## Development Workflow
 
-1. **Fork** the repository
-2. **Create** a feature branch: `git checkout -b feature/your-feature`
-3. **Review or update specs** in `/specs/` before coding
-4. **Implement** your changes following specs
-5. **Test** your changes thoroughly
-6. **Commit** with conventional commits
-7. **Push** and create a Pull Request
-
----
-
-## Spec-Driven Development
-
-### Before Writing Code
-
-All features and changes must be defined in `/specs/`:
-
-| Spec Type | Location | Purpose |
-|-----------|----------|---------|
-| Requirements | `/specs/product/` | What to build |
-| Architecture | `/specs/rfc/` | How to build it |
-| API | `/specs/api/` | Interface contracts |
-| Tests | `/specs/testing/` | Acceptance criteria |
-
-### Workflow
-
-```
-1. Check specs → 2. Update specs (if needed) → 3. Implement → 4. Test
-        ↑                                                        |
-        └──────────────────── Update if scope changes ←───────────┘
-```
-
-### When Specs Need Updates
-
-If your change requires modifying specifications:
-
-1. **Propose the change first** in an issue or PR description
-2. **Update the relevant spec** in `/specs/`
-3. **Get spec approval** before implementing code
-4. **Implement** the code according to updated specs
+1. Fork the repository.
+2. Create a focused branch.
+3. Implement the smallest coherent change that solves the problem.
+4. Add or update tests for the affected behavior.
+5. Update docs when public APIs or workflows change.
+6. Run the project checks before opening a pull request.
 
 ---
 
-## Development Setup
+## Setup
 
 ### Prerequisites
 
@@ -69,64 +25,33 @@ If your change requires modifying specifications:
 ### Installation
 
 ```bash
-# Clone your fork
 git clone https://github.com/YOUR_USERNAME/tiny-dl-inference.git
 cd tiny-dl-inference
-
-# Install dependencies
 npm install
-
-# Verify setup
-npm run typecheck
-npm test
 ```
 
-### Build Commands
+### Common Commands
 
 ```bash
-# Type checking
+npm run lint
 npm run typecheck
-
-# Run tests
 npm test
-
-# Run tests in watch mode
-npm run test:watch
-
-# Run tests with coverage
 npm run test:coverage
-
-# Build distribution
 npm run build
-
-# Clean build artifacts
-npm run clean
 ```
 
 ---
 
-## Code Style
-
-### TypeScript
-
-- **Strict mode**: All code must pass `strict: true`
-- **Explicit types**: Add return types to exported functions
-- **No `any`**: Use `unknown` with type narrowing instead
+## Code Guidelines
 
-### Formatting
+- Keep the stack minimal. Avoid adding orchestration layers or framework-like wrappers.
+- Prefer small explicit functions over indirect abstractions.
+- Add explicit return types on exported functions.
+- Avoid `any`; use `unknown` and narrow properly.
+- Use `as Type` instead of non-null assertions.
+- Follow existing WebGPU lifecycle patterns such as `deferDestroy()` and `sync()`.
 
-Follow `.editorconfig`:
-
-```ini
-indent_style = space
-indent_size = 2
-end_of_line = lf
-charset = utf-8
-trim_trailing_whitespace = true
-insert_final_newline = true
-```
-
-### Naming Conventions
+### Naming
 
 | Type | Convention | Example |
 |------|------------|---------|
@@ -137,127 +62,34 @@ insert_final_newline = true
 
 ### Commit Messages
 
-Follow [Conventional Commits](https://www.conventionalcommits.org/):
+Use [Conventional Commits](https://www.conventionalcommits.org/):
 
-```
-feat: add BatchNorm operator
-fix: correct padding calculation in Conv2d
-docs: update API reference
-test: add property tests for Dense operator
-refactor: simplify shader compilation
-perf: optimize memory layout for NHWC
+```text
+feat: add batch norm operator
+fix: correct conv padding calculation
+docs: simplify installation guide
+refactor: remove unused docs dependency
 ```
 
 ---
 
-## Testing Guidelines
+## Testing Expectations
 
-### Test Structure
-
-```
-tests/
-├── core/           # Core component tests
-├── operators/      # Operator tests
-├── engine/         # Engine tests
-└── helpers/        # Shared test utilities
-```
-
-### Property-Based Testing
-
-Use `fast-check` for property tests:
-
-```typescript
-import * as fc from 'fast-check';
-
-describe('Property: Conv2d Correctness', () => {
-  it('should match CPU reference', async () => {
-    await fc.assert(
-      fc.asyncProperty(
-        fc.integer({ min: 1, max: 4 }),  // batch
-        fc.integer({ min: 1, max: 8 }),  // channels
-        async (batch, channels) => {
-          // Test implementation
-          return true;
-        }
-      ),
-      { numRuns: 100 }
-    );
-  });
-});
-```
-
-### Test Requirements
-
-- **New operators**: Must include property tests
-- **Bug fixes**: Must include regression tests
-- **All changes**: Existing tests must pass
+- New operators should include property-based tests where numerical invariants matter.
+- Bug fixes should include regression coverage.
+- Existing tests must stay green.
+- Use `tests/helpers/mockContext.ts` for GPU mocking in Node-based tests.
 
 ---
 
-## Pull Request Process
-
-### Before Submitting
-
-1. **Update specs** if your change affects requirements or APIs
-2. **Run all checks**:
-   ```bash
-   npm run typecheck
-   npm test
-   npm run build
-   ```
-3. **Add tests** for new functionality
-4. **Update documentation** if needed
-
-### PR Description Template
+## Pull Requests
 
-```markdown
-## Description
-Brief description of changes
+Before submitting:
 
-## Spec Reference
-Link to relevant spec in `/specs/`
-
-## Type of Change
-- [ ] Bug fix (non-breaking)
-- [ ] New feature (non-breaking)
-- [ ] Breaking change
-- [ ] Documentation update
-
-## Testing
-- [ ] Added unit tests
-- [ ] Added property tests
-- [ ] All tests pass
-
-## Checklist
-- [ ] Followed Spec-Driven Development workflow
-- [ ] Code follows project style guidelines
-- [ ] Documentation updated
-```
-
-### Review Process
-
-1. CI checks must pass (typecheck, test, build)
-2. At least one approval required
-3. Spec changes reviewed separately if applicable
-
----
-
-## Adding New Operators
-
-When adding a new neural network operator:
-
-### 1. Define in Specs
-
-Create or update:
-- `/specs/product/requirements.md` - Add REQ entry
-- `/specs/api/api-reference.md` - Define interface
-- `/specs/testing/features.md` - Define test scenarios
-
-### 2. Implement
-
-```typescript
-// src/operators/MyOperator.ts
-import { Operator, OperatorParams } from './Operator';
+1. Run `npm run lint`, `npm run typecheck`, `npm test`, and `npm run build`.
+2. Add tests for behavior changes.
+3. Update docs if the change affects users or contributors.
+4. Keep the PR focused; unrelated cleanup should be separate.
 import { Tensor, TensorShape } from '../core/Tensor';
 
 export class MyOperator extends Operator {
diff --git a/README.md b/README.md
index 08b7644..53390d8 100644
--- a/README.md
+++ b/README.md
@@ -326,12 +326,6 @@ if (navigator.gpu) {
 
 ```
 tiny-dl-inference/
-├── openspec/           # OpenSpec 规范驱动开发（单一事实来源）
-│   ├── specs/          # 规范文档
-│   │   ├── product/    # 产品需求规范（PRD）
-│   │   ├── architecture/ # 架构设计规范
-│   │   ├── api/        # API 规范
-│   │   └── testing/    # BDD 测试规范
 ├── docs/               # User documentation (Bilingual)
 │   ├── en/             # English (26 files)
 │   └── zh/             # 中文 (27 files)
@@ -442,22 +436,21 @@ npx vitest run -t "property"
 
 ## Contributing
 
-We welcome contributions! This project follows **Spec-Driven Development (SDD)** — all changes must be defined in `/specs/` first.
+We welcome focused, maintainable contributions. Keep changes small, test-backed, and aligned with the existing TypeScript/WebGPU architecture.
 
 ### Quick Start
 
 1. **Fork** the repository
 2. **Create** a feature branch: `git checkout -b feature/your-feature`
-3. **Review specs** in `/specs/` before coding
-4. **Implement** your changes
-5. **Test** thoroughly (134+ tests)
+3. **Implement** your change directly in code
+4. **Test** thoroughly
+5. **Update** docs if public behavior changes
 6. **Submit** a Pull Request
 
 ### Resources
 
 - [**Contributing Guide**](CONTRIBUTING.md) — Full development workflow
-- [**AGENTS.md**](AGENTS.md) — AI agent development guidelines
-- [**Specs Directory**](openspec/specs/) — Single Source of Truth
+- [**GitHub Pages**](https://lessup.github.io/tiny-dl-inference/) — Product documentation
 
 ### Code Style
 
@@ -468,19 +461,6 @@ We welcome contributions! This project follows **Spec-Driven Development (SDD)**
 
 ---
 
-## Specifications
-
-This project uses **Spec-Driven Development** — specifications are the Single Source of Truth:
-
-| Spec | Location | Purpose |
-|------|----------|---------|
-| **Requirements** | [`openspec/specs/product/spec.md`](openspec/specs/product/spec.md) | What to build |
-| **Architecture** | [`openspec/specs/architecture/spec.md`](openspec/specs/architecture/spec.md) | How to build it |
-| **API Contracts** | [`openspec/specs/api/spec.md`](openspec/specs/api/spec.md) | Interface definitions |
-| **Test Criteria** | [`openspec/specs/testing/spec.md`](openspec/specs/testing/spec.md) | Acceptance criteria |
-
----
-
 ## Changelog
 
 See [CHANGELOG.md](CHANGELOG.md) for all releases.
diff --git a/README.zh-CN.md b/README.zh-CN.md
index 0f56b32..6fad5a7 100644
--- a/README.zh-CN.md
+++ b/README.zh-CN.md
@@ -264,12 +264,6 @@ if (navigator.gpu) {
 
 ```
 tiny-dl-inference/
-├── openspec/           # OpenSpec 规范驱动开发（单一事实来源）
-│   ├── specs/          # 规范文档
-│   │   ├── product/    # 产品需求规范（PRD）
-│   │   ├── architecture/ # 架构设计规范
-│   │   ├── api/        # API 规范
-│   │   └── testing/    # BDD 测试规范
 ├── docs/               # 用户文档（双语）
 │   ├── en/             # 英文（26 个文件）
 │   └── zh/             # 中文（27 个文件）
@@ -368,22 +362,21 @@ npx vitest run -t "property"
 
 ## 贡献指南
 
-欢迎贡献！本项目遵循**规范驱动开发（SDD）**——所有更改必须先在 `/specs/` 中定义。
+欢迎贡献。请保持修改聚焦、可测试，并遵循现有的 TypeScript/WebGPU 实现方式。
 
 ### 快速开始
 
 1. **Fork** 仓库
 2. **创建**特性分支：`git checkout -b feature/your-feature`
-3. **查看规范** 编码前检查 `/specs/`
-4. **实现**你的更改
-5. **充分测试**（134+ 个测试）
+3. **直接实现**你的更改
+4. **充分测试**
+5. **如有必要更新文档**
 6. **提交** Pull Request
 
 ### 资源
 
 - [**贡献指南**](CONTRIBUTING.md) — 完整的开发工作流
-- [**AGENTS.md**](AGENTS.md) — AI 代理开发指南
-- [**规范目录**](openspec/specs/) — 单一事实来源
+- [**GitHub Pages**](https://lessup.github.io/tiny-dl-inference/) — 产品文档
 
 ### 代码风格
 
@@ -394,19 +387,6 @@ npx vitest run -t "property"
 
 ---
 
-## 规范
-
-本项目使用**规范驱动开发**——规范是单一事实来源：
-
-| 规范 | 位置 | 用途 |
-|------|------|------|
-| **需求** | [`openspec/specs/product/spec.md`](openspec/specs/product/spec.md) | 构建什么 |
-| **架构** | [`openspec/specs/architecture/spec.md`](openspec/specs/architecture/spec.md) | 如何构建 |
-| **API 约定** | [`openspec/specs/api/spec.md`](openspec/specs/api/spec.md) | 接口定义 |
-| **测试标准** | [`openspec/specs/testing/spec.md`](openspec/specs/testing/spec.md) | 验收标准 |
-
----
-
 ## 版本日志
 
 查看所有版本：[CHANGELOG.md](CHANGELOG.md)
diff --git a/docs/.vitepress/config/index.ts b/docs/.vitepress/config/index.ts
index ca94f2e..9ad94d9 100644
--- a/docs/.vitepress/config/index.ts
+++ b/docs/.vitepress/config/index.ts
@@ -11,7 +11,6 @@
 
 import { defineConfig } from 'vitepress'
 import { withMermaid } from 'vitepress-plugin-mermaid'
-import llmstxt from 'vitepress-plugin-llms'
 import { sharedConfig, buildEnd } from './shared'
 import { localesConfig } from './locales'
 import { themeConfig } from './theme'
@@ -45,12 +44,6 @@ export default withMermaid(defineConfig({
   // Theme configuration
   themeConfig,
 
-  // Vite config with plugins
-  vite: {
-    ...sharedConfig.vite,
-    plugins: [llmstxt()],
-  },
-
   // Build end hook
   buildEnd,
 }))
diff --git a/docs/.vitepress/config/nav/en.ts b/docs/.vitepress/config/nav/en.ts
index 5444f1c..dafe50f 100644
--- a/docs/.vitepress/config/nav/en.ts
+++ b/docs/.vitepress/config/nav/en.ts
@@ -14,7 +14,6 @@ export const navEN: DefaultTheme.NavItem[] = [
   {
     text: 'v2.1.0',
     items: [
-      { text: 'Changelog', link: '/en/changelog' },
       { text: 'Contributing', link: '/en/contributing' },
       { text: 'References', link: '/en/references/' },
       { text: 'Research', link: '/en/research/' },
diff --git a/docs/.vitepress/config/nav/zh.ts b/docs/.vitepress/config/nav/zh.ts
index e69688b..41deedf 100644
--- a/docs/.vitepress/config/nav/zh.ts
+++ b/docs/.vitepress/config/nav/zh.ts
@@ -14,7 +14,6 @@ export const navZH: DefaultTheme.NavItem[] = [
   {
     text: 'v2.1.0',
     items: [
-      { text: '更新日志', link: '/zh/changelog' },
       { text: '贡献指南', link: '/zh/contributing' },
       { text: '参考文献', link: '/zh/references/' },
       { text: '研究', link: '/zh/research/' },
diff --git a/docs/en/api/index.md b/docs/en/api/index.md
index 93c6522..5d17cba 100644
--- a/docs/en/api/index.md
+++ b/docs/en/api/index.md
@@ -90,4 +90,4 @@ interface OperatorParams {
 
 **Current Version:** 2.0.1
 
-See [Changelog](/en/changelog) for version history.
+See [CHANGELOG.md](https://github.com/LessUp/tiny-dl-inference/blob/main/CHANGELOG.md) for version history.
diff --git a/docs/en/changelog.md b/docs/en/changelog.md
deleted file mode 100644
index 84929f7..0000000
--- a/docs/en/changelog.md
+++ /dev/null
@@ -1,183 +0,0 @@
----
-title: Changelog
----
-
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
-and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
-
-For the complete changelog, see [GitHub CHANGELOG.md](https://github.com/LessUp/tiny-dl-inference/blob/main/CHANGELOG.md).
-
----
-
-## [Unreleased]
-
-### Added
-- Comprehensive bilingual documentation (English & Chinese)
-- New documentation site structure under `docs/`
-- API reference documentation
-- Architecture design documentation
-- Performance optimization guide
-- Development contribution guide
-
----
-
-## [2.0.1] - 2026-04-16
-
-### Security
-- Fixed 5 moderate npm vulnerabilities (esbuild, vite, vitest)
-  - CVE-2024-XXXX: Regular expression denial of service in esbuild
-  - CVE-2024-XXXX: Path traversal vulnerability in vite
-- Updated `vitest` from v1.6.1 to v4.1.4
-- Updated `@vitest/coverage-v8` from v1.6.1 to v4.1.4
-
-### Changed
-- Updated `@webgpu/types` from 0.1.68 to 0.1.69
-- Updated `@types/node` to latest v20.x
-
----
-
-## [2.0.0] - 2026-03-09
-
-### Added
-- **Zero-copy Tensor.reshape()** via tensor views
-  - Significant memory reduction for reshape-heavy models
-  - `Tensor._createView()` static method for buffer sharing
-  - `Tensor._isView` flag to track view tensors
-- **GPUContext.deferDestroy()** for safe async buffer cleanup
-  - Prevents use-after-free race conditions
-  - Automatic cleanup of temporary GPU resources
-- **GPUContext.sync()** and `GPUContext.waitForSubmittedWork()` methods
-  - Better control over GPU synchronization
-- **FlattenOperator** for CNN-to-FC layer transitions
-- **DenseOperator** for fully connected layers
-- **Conv2dBiasReLUOperator** - fused kernel optimization
-  - 3x memory traffic reduction vs sequential execution
-
-### Fixed
-- **[Critical]** `Tensor.reshape()` unnecessary GPU buffer allocation
-  - Now uses zero-copy views, reducing memory pressure
-- **[Critical]** `InferenceEngine.infer()` GPU memory leak
-  - Intermediate tensors now properly destroyed after use
-- **[Critical]** Race conditions in operator temp buffer cleanup
-  - Now uses `deferDestroy()` pattern consistently
-
-### Changed
-- `Tensor.destroy()` is now a no-op for view tensors
-- All operators use deferred buffer destruction pattern
-
-### Performance
-
-| Operation | Before | After | Improvement |
-|-----------|--------|-------|-------------|
-| Flatten | Full buffer copy | Zero overhead | **~100%** |
-| Fused Conv2d+Bias+ReLU | 6 mem ops | 2 mem ops | **3×** |
-| Memory leaks | Persistent | Properly freed | **Stable** |
-
----
-
-## [1.0.0] - 2026-03-09
-
-### Added
-- Standardized CI workflow with `permissions` and `concurrency` configuration
-- Node.js 20 validation pipeline (lint, test, build)
-- Automated security scanning for dependencies
-
-### Changed
-- `lint` script now runs TypeScript type checking
-- Updated CI triggers for better resource efficiency
-
----
-
-## [0.9.0] - 2026-03-10
-
-### Added
-- GitHub Pages deployment workflow
-- Bilingual documentation support
-  - Chinese documentation (`README.zh-CN.md`)
-- Architecture diagram in `index.md`
-- SEO metadata in `_config.yml`
-
-### Changed
-- Refined Pages workflow path triggers for documentation files only
-- Optimized Jekyll build exclusions
-
----
-
-## [0.8.0] - 2026-01-08
-
-### Added
-- `tests/setup.ts` - WebGPU globals for Node.js test environment
-- `tests/tsconfig.json` - separate TypeScript config for tests
-- `@vitest/coverage-v8` for V8 coverage reporting
-
-### Fixed
-- Vitest failing in Node.js due to missing WebGPU globals
-- Operator test mocks not writing computed results to output buffers
-- `GPUContext.test.ts` failing when `navigator` is read-only
-
-### Changed
-- All operator tests have properly mocked WebGPU buffer lifecycle
-- **54 tests passing** (expanded from 47)
-
----
-
-## [0.1.0] - 2025-02-13
-
-### Added
-- **Initial project infrastructure**
-  - MIT LICENSE
-  - `.editorconfig` for consistent code formatting
-  - TypeScript 5.x with strict mode
-  - Vitest for testing with coverage
-
-- **Core Components**
-  - `GPUContext` - WebGPU device management with error handling
-  - `Tensor` - GPU buffer management with layout support (NCHW/NHWC)
-  - Custom error classes for all failure modes
-
-- **Neural Network Operators**
-  - `ReLUOperator` - Element-wise activation
-  - `SoftmaxOperator` - Numerically stable probability distribution
-  - `MaxPoolOperator` - 2D max pooling
-  - `Conv2dOperator` - Direct convolution
-  - `DenseOperator` - Matrix multiplication
-  - `FlattenOperator` - Tensor reshaping
-
-- **Inference Engine**
-  - `InferenceEngine` - Complete inference pipeline
-  - `ModelLoader` - JSON model loading
-
-- **Testing Framework**
-  - Property-based testing with `fast-check`
-  - 100+ iterations per property test
-  - CPU reference implementations for validation
-
-- **Examples**
-  - MNIST digit classification demo
-  - Performance benchmark demo
-
-- **Performance Features**
-  - Hand-written WGSL compute shaders
-  - Kernel fusion support architecture
-  - Im2Col utilities for experimentation
-
-### Stats
-- **~2,000** lines of source code
-- **~1,100** lines of tests
-- **7** neural network operators
-- **13** property-based tests
-- Zero runtime dependencies
-
----
-
-[Unreleased]: https://github.com/LessUp/tiny-dl-inference/compare/v2.0.1...HEAD
-[2.0.1]: https://github.com/LessUp/tiny-dl-inference/compare/v2.0.0...v2.0.1
-[2.0.0]: https://github.com/LessUp/tiny-dl-inference/compare/v1.0.0...v2.0.0
-[1.0.0]: https://github.com/LessUp/tiny-dl-inference/compare/v0.9.0...v1.0.0
-[0.9.0]: https://github.com/LessUp/tiny-dl-inference/compare/v0.8.0...v0.9.0
-[0.8.0]: https://github.com/LessUp/tiny-dl-inference/compare/v0.1.0...v0.8.0
-[0.1.0]: https://github.com/LessUp/tiny-dl-inference/releases/tag/v0.1.0
diff --git a/docs/en/contributing.md b/docs/en/contributing.md
index 8574fd9..4d0aaa7 100644
--- a/docs/en/contributing.md
+++ b/docs/en/contributing.md
@@ -4,7 +4,7 @@ title: Contributing
 
 # Contributing to Tiny-DL-Inference
 
-Thank you for your interest in contributing! This project follows **Spec-Driven Development (SDD)**, meaning all code changes must be guided by specifications in the `/specs` directory.
+Thank you for your interest in contributing. Keep changes focused, tested, and easy to maintain.
 
 ---
 
@@ -12,8 +12,8 @@ Thank you for your interest in contributing! This project follows **Spec-Driven
 
 1. **Fork** the repository
 2. **Create** a feature branch: `git checkout -b feature/your-feature`
-3. **Review or update specs** in `/specs/` before coding
-4. **Implement** your changes following specs
+3. **Implement** your changes directly in code
+4. **Keep** changes small and coherent
 5. **Test** your changes thoroughly
 6. **Commit** with conventional commits
 7. **Push** and create a Pull Request
diff --git a/docs/en/research/future-directions.md b/docs/en/research/future-directions.md
index d751bcc..27c6cfe 100644
--- a/docs/en/research/future-directions.md
+++ b/docs/en/research/future-directions.md
@@ -225,5 +225,5 @@ We welcome contributions in the following areas:
 ## Next Steps
 
 - [Contributing](../contributing) - How to contribute
-- [Changelog](../changelog) - Version history
+- [CHANGELOG.md](https://github.com/LessUp/tiny-dl-inference/blob/main/CHANGELOG.md) - Version history
 - [References](../references/) - Academic citations
diff --git a/docs/package-lock.json b/docs/package-lock.json
index 49f4f63..20c3fc1 100644
--- a/docs/package-lock.json
+++ b/docs/package-lock.json
@@ -10,7 +10,6 @@
       "devDependencies": {
         "mermaid": "^11.12.2",
         "vitepress": "^1.6.4",
-        "vitepress-plugin-llms": "^1.10.0",
         "vitepress-plugin-mermaid": "^2.0.17"
       }
     },
@@ -1584,16 +1583,6 @@
         "@types/d3-selection": "*"
       }
     },
-    "node_modules/@types/debug": {
-      "version": "4.1.13",
-      "resolved": "https://registry.npmjs.org/@types/debug/-/debug-4.1.13.tgz",
-      "integrity": "sha512-KSVgmQmzMwPlmtljOomayoR89W4FynCAi3E8PPs7vmDVPe84hT+vGPKkJfThkmXs0x0jAaa9U8uW8bbfyS2fWw==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/ms": "*"
-      }
-    },
     "node_modules/@types/estree": {
       "version": "1.0.8",
       "resolved": "https://registry.npmjs.org/@types/estree/-/estree-1.0.8.tgz",
@@ -1653,13 +1642,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/@types/ms": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/@types/ms/-/ms-2.1.0.tgz",
-      "integrity": "sha512-GsCCIZDE/p3i96vtEqx+7dBUGXrc7zeSK3wwPHIaRThS+9OhWIXRqzs4d6k1SVU8g91DrNRWxWUGhp5KXQb2VA==",
-      "dev": true,
-      "license": "MIT"
-    },
     "node_modules/@types/trusted-types": {
       "version": "2.0.7",
       "resolved": "https://registry.npmjs.org/@types/trusted-types/-/trusted-types-2.0.7.tgz",
@@ -2004,63 +1986,6 @@
         "node": ">= 14.0.0"
       }
     },
-    "node_modules/ansi-regex": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
-      "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/ansi-styles": {
-      "version": "4.3.0",
-      "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
-      "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "color-convert": "^2.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      },
-      "funding": {
-        "url": "https://github.com/chalk/ansi-styles?sponsor=1"
-      }
-    },
-    "node_modules/argparse": {
-      "version": "1.0.10",
-      "resolved": "https://registry.npmjs.org/argparse/-/argparse-1.0.10.tgz",
-      "integrity": "sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "sprintf-js": "~1.0.2"
-      }
-    },
-    "node_modules/bail": {
-      "version": "2.0.2",
-      "resolved": "https://registry.npmjs.org/bail/-/bail-2.0.2.tgz",
-      "integrity": "sha512-0xO6mYd7JB2YesxDKplafRpsiOzPt9V02ddPCLbY1xYGPOX24NTyN50qnUxgCPcSoYMhKpAuBTjQoRZCAkUDRw==",
-      "dev": true,
-      "license": "MIT",
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
-    "node_modules/balanced-match": {
-      "version": "4.0.4",
-      "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-4.0.4.tgz",
-      "integrity": "sha512-BLrgEcRTwX2o6gGxGOCNyMvGSp35YofuYzw9h1IMTRmKqttAZZVU67bdb9Pr2vUHA8+j3i2tJfjO6C6+4myGTA==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": "18 || 20 || >=22"
-      }
-    },
     "node_modules/birpc": {
       "version": "2.9.0",
       "resolved": "https://registry.npmjs.org/birpc/-/birpc-2.9.0.tgz",
@@ -2071,19 +1996,6 @@
         "url": "https://github.com/sponsors/antfu"
       }
     },
-    "node_modules/brace-expansion": {
-      "version": "5.0.6",
-      "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.6.tgz",
-      "integrity": "sha512-kLpxurY4Z4r9sgMsyG0Z9uzsBlgiU/EFKhj/h91/8yHu0edo7XuixOIH3VcJ8kkxs6/jPzoI6U9Vj3WqbMQ94g==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "balanced-match": "^4.0.2"
-      },
-      "engines": {
-        "node": "18 || 20 || >=22"
-      }
-    },
     "node_modules/ccount": {
       "version": "2.0.1",
       "resolved": "https://registry.npmjs.org/ccount/-/ccount-2.0.1.tgz",
@@ -2095,17 +2007,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/character-entities": {
-      "version": "2.0.2",
-      "resolved": "https://registry.npmjs.org/character-entities/-/character-entities-2.0.2.tgz",
-      "integrity": "sha512-shx7oQ0Awen/BRIdkjkvz54PnEEI/EjwXDSIZp86/KKdbafHh1Df/RYGBhn4hbe2+uKC9FnT5UCEdyPz3ai9hQ==",
-      "dev": true,
-      "license": "MIT",
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
     "node_modules/character-entities-html4": {
       "version": "2.1.0",
       "resolved": "https://registry.npmjs.org/character-entities-html4/-/character-entities-html4-2.1.0.tgz",
@@ -2128,41 +2029,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/cliui": {
-      "version": "8.0.1",
-      "resolved": "https://registry.npmjs.org/cliui/-/cliui-8.0.1.tgz",
-      "integrity": "sha512-BSeNnyus75C4//NQ9gQt1/csTXyo/8Sb+afLAkzAptFuMsod9HFokGNudZpi/oQV73hnVK+sR+5PVRMd+Dr7YQ==",
-      "dev": true,
-      "license": "ISC",
-      "dependencies": {
-        "string-width": "^4.2.0",
-        "strip-ansi": "^6.0.1",
-        "wrap-ansi": "^7.0.0"
-      },
-      "engines": {
-        "node": ">=12"
-      }
-    },
-    "node_modules/color-convert": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz",
-      "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "color-name": "~1.1.4"
-      },
-      "engines": {
-        "node": ">=7.0.0"
-      }
-    },
-    "node_modules/color-name": {
-      "version": "1.1.4",
-      "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz",
-      "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==",
-      "dev": true,
-      "license": "MIT"
-    },
     "node_modules/comma-separated-tokens": {
       "version": "2.0.3",
       "resolved": "https://registry.npmjs.org/comma-separated-tokens/-/comma-separated-tokens-2.0.3.tgz",
@@ -2765,38 +2631,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/debug": {
-      "version": "4.4.3",
-      "resolved": "https://registry.npmjs.org/debug/-/debug-4.4.3.tgz",
-      "integrity": "sha512-RGwwWnwQvkVfavKVt22FGLw+xYSdzARwm0ru6DhTVA3umU5hZc28V3kO4stgYryrTlLpuvgI9GiijltAjNbcqA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "ms": "^2.1.3"
-      },
-      "engines": {
-        "node": ">=6.0"
-      },
-      "peerDependenciesMeta": {
-        "supports-color": {
-          "optional": true
-        }
-      }
-    },
-    "node_modules/decode-named-character-reference": {
-      "version": "1.3.0",
-      "resolved": "https://registry.npmjs.org/decode-named-character-reference/-/decode-named-character-reference-1.3.0.tgz",
-      "integrity": "sha512-GtpQYB283KrPp6nRw50q3U9/VfOutZOe103qlN7BPP6Ad27xYnOIWv4lPzo8HCAL+mMZofJ9KEy30fq6MfaK6Q==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "character-entities": "^2.0.0"
-      },
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
     "node_modules/delaunator": {
       "version": "5.1.0",
       "resolved": "https://registry.npmjs.org/delaunator/-/delaunator-5.1.0.tgz",
@@ -2841,13 +2675,6 @@
         "@types/trusted-types": "^2.0.7"
       }
     },
-    "node_modules/emoji-regex": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz",
-      "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==",
-      "dev": true,
-      "license": "MIT"
-    },
     "node_modules/emoji-regex-xs": {
       "version": "1.0.0",
       "resolved": "https://registry.npmjs.org/emoji-regex-xs/-/emoji-regex-xs-1.0.0.tgz",
@@ -2855,19 +2682,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/entities": {
-      "version": "4.5.0",
-      "resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz",
-      "integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==",
-      "dev": true,
-      "license": "BSD-2-Clause",
-      "engines": {
-        "node": ">=0.12"
-      },
-      "funding": {
-        "url": "https://github.com/fb55/entities?sponsor=1"
-      }
-    },
     "node_modules/es-toolkit": {
       "version": "1.46.1",
       "resolved": "https://registry.npmjs.org/es-toolkit/-/es-toolkit-1.46.1.tgz",
@@ -2918,43 +2732,6 @@
         "@esbuild/win32-x64": "0.21.5"
       }
     },
-    "node_modules/escalade": {
-      "version": "3.2.0",
-      "resolved": "https://registry.npmjs.org/escalade/-/escalade-3.2.0.tgz",
-      "integrity": "sha512-WUj2qlxaQtO4g6Pq5c29GTcWGDyd8itL8zTlipgECz3JesAiiOKotd8JU6otB3PACgG6xkJUyVhboMS+bje/jA==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=6"
-      }
-    },
-    "node_modules/escape-string-regexp": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-5.0.0.tgz",
-      "integrity": "sha512-/veY75JbMK4j1yjvuUxuVsiS/hr/4iHs9FTT6cgTexxdE0Ly/glccBAkloH/DofkjRbZU3bnoj38mOmhkZ0lHw==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=12"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
-      }
-    },
-    "node_modules/esprima": {
-      "version": "4.0.1",
-      "resolved": "https://registry.npmjs.org/esprima/-/esprima-4.0.1.tgz",
-      "integrity": "sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A==",
-      "dev": true,
-      "license": "BSD-2-Clause",
-      "bin": {
-        "esparse": "bin/esparse.js",
-        "esvalidate": "bin/esvalidate.js"
-      },
-      "engines": {
-        "node": ">=4"
-      }
-    },
     "node_modules/estree-walker": {
       "version": "2.0.2",
       "resolved": "https://registry.npmjs.org/estree-walker/-/estree-walker-2.0.2.tgz",
@@ -2962,40 +2739,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/extend": {
-      "version": "3.0.2",
-      "resolved": "https://registry.npmjs.org/extend/-/extend-3.0.2.tgz",
-      "integrity": "sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==",
-      "dev": true,
-      "license": "MIT"
-    },
-    "node_modules/extend-shallow": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/extend-shallow/-/extend-shallow-2.0.1.tgz",
-      "integrity": "sha512-zCnTtlxNoAiDc3gqY2aYAWFx7XWWiasuF2K8Me5WbN8otHKTUKBwjPtNpRs/rbUZm7KxWAaNj7P1a/p52GbVug==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "is-extendable": "^0.1.0"
-      },
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/fault": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/fault/-/fault-2.0.1.tgz",
-      "integrity": "sha512-WtySTkS4OKev5JtpHXnib4Gxiurzh5NCGvWrFaZ34m6JehfTUhKZvn9njTfw48t6JumVQOmrKqpmGcdwxnhqBQ==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "format": "^0.2.0"
-      },
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
     "node_modules/focus-trap": {
       "version": "7.8.0",
       "resolved": "https://registry.npmjs.org/focus-trap/-/focus-trap-7.8.0.tgz",
@@ -3006,15 +2749,6 @@
         "tabbable": "^6.4.0"
       }
     },
-    "node_modules/format": {
-      "version": "0.2.2",
-      "resolved": "https://registry.npmjs.org/format/-/format-0.2.2.tgz",
-      "integrity": "sha512-wzsgA6WOq+09wrU1tsJ09udeR/YZRaeArL9e1wPbFg3GG2yDnC2ldKpxs4xunpFF9DgqCqOIra3bc1HWrJ37Ww==",
-      "dev": true,
-      "engines": {
-        "node": ">=0.4.x"
-      }
-    },
     "node_modules/fsevents": {
       "version": "2.3.3",
       "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz",
@@ -3030,32 +2764,6 @@
         "node": "^8.16.0 || ^10.6.0 || >=11.0.0"
       }
     },
-    "node_modules/get-caller-file": {
-      "version": "2.0.5",
-      "resolved": "https://registry.npmjs.org/get-caller-file/-/get-caller-file-2.0.5.tgz",
-      "integrity": "sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==",
-      "dev": true,
-      "license": "ISC",
-      "engines": {
-        "node": "6.* || 8.* || >= 10.*"
-      }
-    },
-    "node_modules/gray-matter": {
-      "version": "4.0.3",
-      "resolved": "https://registry.npmjs.org/gray-matter/-/gray-matter-4.0.3.tgz",
-      "integrity": "sha512-5v6yZd4JK3eMI3FqqCouswVqwugaA9r4dNZB1wwcmrD02QkV5H0y7XBQW8QwQqEaZY1pM9aqORSORhJRdNK44Q==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "js-yaml": "^3.13.1",
-        "kind-of": "^6.0.2",
-        "section-matter": "^1.0.0",
-        "strip-bom-string": "^1.0.0"
-      },
-      "engines": {
-        "node": ">=6.0"
-      }
-    },
     "node_modules/hachure-fill": {
       "version": "0.5.2",
       "resolved": "https://registry.npmjs.org/hachure-fill/-/hachure-fill-0.5.2.tgz",
@@ -3153,39 +2861,6 @@
         "node": ">=12"
       }
     },
-    "node_modules/is-extendable": {
-      "version": "0.1.1",
-      "resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-0.1.1.tgz",
-      "integrity": "sha512-5BMULNob1vgFX6EjQw5izWDxrecWK9AM72rugNr0TFldMOi0fj6Jk+zeKIt0xGj4cEfQIJth4w3OKWOJ4f+AFw==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/is-fullwidth-code-point": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
-      "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/is-plain-obj": {
-      "version": "4.1.0",
-      "resolved": "https://registry.npmjs.org/is-plain-obj/-/is-plain-obj-4.1.0.tgz",
-      "integrity": "sha512-+Pgi+vMuUNkJyExiMBt5IlFoMyKnr5zhJ4Uspz58WOhBF5QoIZkFyNHIbBAtHwzVAgk5RtndVNsDRN61/mmDqg==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=12"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
-      }
-    },
     "node_modules/is-what": {
       "version": "5.5.0",
       "resolved": "https://registry.npmjs.org/is-what/-/is-what-5.5.0.tgz",
@@ -3199,20 +2874,6 @@
         "url": "https://github.com/sponsors/mesqueeb"
       }
     },
-    "node_modules/js-yaml": {
-      "version": "3.14.2",
-      "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-3.14.2.tgz",
-      "integrity": "sha512-PMSmkqxr106Xa156c2M265Z+FTrPl+oxd/rgOQy2tijQeK5TxQ43psO1ZCwhVOSdnn+RzkzlRz/eY4BgJBYVpg==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "argparse": "^1.0.7",
-        "esprima": "^4.0.0"
-      },
-      "bin": {
-        "js-yaml": "bin/js-yaml.js"
-      }
-    },
     "node_modules/katex": {
       "version": "0.16.45",
       "resolved": "https://registry.npmjs.org/katex/-/katex-0.16.45.tgz",
@@ -3246,16 +2907,6 @@
       "integrity": "sha512-Ls993zuzfayK269Svk9hzpeGUKob/sIgZzyHYdjQoAdQetRKpOLj+k/QQQ/6Qi0Yz65mlROrfd+Ev+1+7dz9Kw==",
       "dev": true
     },
-    "node_modules/kind-of": {
-      "version": "6.0.3",
-      "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-6.0.3.tgz",
-      "integrity": "sha512-dcS1ul+9tmeD95T+x28/ehLgd9mENa3LsvDTtzm3vyBEO7RPptvAD+t44WVXaUjTBRcrpFeFlC8WCruUR456hw==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
     "node_modules/layout-base": {
       "version": "1.0.2",
       "resolved": "https://registry.npmjs.org/layout-base/-/layout-base-1.0.2.tgz",
@@ -3263,16 +2914,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/linkify-it": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-5.0.0.tgz",
-      "integrity": "sha512-5aHCbzQRADcdP+ATqnDuhhJ/MRIqDkZX5pyjFHRRysS8vZ5AbqGEoFIb6pYHPZ+L/OC2Lc+xT8uHVVR5CAK/wQ==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "uc.micro": "^2.0.0"
-      }
-    },
     "node_modules/lodash-es": {
       "version": "4.18.1",
       "resolved": "https://registry.npmjs.org/lodash-es/-/lodash-es-4.18.1.tgz",
@@ -3280,17 +2921,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/longest-streak": {
-      "version": "3.1.0",
-      "resolved": "https://registry.npmjs.org/longest-streak/-/longest-streak-3.1.0.tgz",
-      "integrity": "sha512-9Ri+o0JYgehTaVBBDoMqIl8GXtbWg711O3srftcHhZ0dqnETqLaoIK0x17fUw9rFSlK/0NlsKe0Ahhyl5pXE2g==",
-      "dev": true,
-      "license": "MIT",
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
     "node_modules/magic-string": {
       "version": "0.30.21",
       "resolved": "https://registry.npmjs.org/magic-string/-/magic-string-0.30.21.tgz",
@@ -3308,41 +2938,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/markdown-it": {
-      "version": "14.1.1",
-      "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.1.1.tgz",
-      "integrity": "sha512-BuU2qnTti9YKgK5N+IeMubp14ZUKUUw7yeJbkjtosvHiP0AZ5c8IAgEMk79D0eC8F23r4Ac/q8cAIFdm2FtyoA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "argparse": "^2.0.1",
-        "entities": "^4.4.0",
-        "linkify-it": "^5.0.0",
-        "mdurl": "^2.0.0",
-        "punycode.js": "^2.3.1",
-        "uc.micro": "^2.1.0"
-      },
-      "bin": {
-        "markdown-it": "bin/markdown-it.mjs"
-      }
-    },
-    "node_modules/markdown-it/node_modules/argparse": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
-      "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
-      "dev": true,
-      "license": "Python-2.0"
-    },
-    "node_modules/markdown-title": {
-      "version": "1.0.2",
-      "resolved": "https://registry.npmjs.org/markdown-title/-/markdown-title-1.0.2.tgz",
-      "integrity": "sha512-MqIQVVkz+uGEHi3TsHx/czcxxCbRIL7sv5K5DnYw/tI+apY54IbPefV/cmgxp6LoJSEx/TqcHdLs/298afG5QQ==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=6"
-      }
-    },
     "node_modules/marked": {
       "version": "16.4.2",
       "resolved": "https://registry.npmjs.org/marked/-/marked-16.4.2.tgz",
@@ -3356,525 +2951,62 @@
         "node": ">= 20"
       }
     },
-    "node_modules/mdast-util-from-markdown": {
-      "version": "2.0.3",
-      "resolved": "https://registry.npmjs.org/mdast-util-from-markdown/-/mdast-util-from-markdown-2.0.3.tgz",
-      "integrity": "sha512-W4mAWTvSlKvf8L6J+VN9yLSqQ9AOAAvHuoDAmPkz4dHf553m5gVj2ejadHJhoJmcmxEnOv6Pa8XJhpxE93kb8Q==",
+    "node_modules/mdast-util-to-hast": {
+      "version": "13.2.1",
+      "resolved": "https://registry.npmjs.org/mdast-util-to-hast/-/mdast-util-to-hast-13.2.1.tgz",
+      "integrity": "sha512-cctsq2wp5vTsLIcaymblUriiTcZd0CwWtCbLvrOzYCDZoWyMNV8sZ7krj09FSnsiJi3WVsHLM4k6Dq/yaPyCXA==",
       "dev": true,
       "license": "MIT",
       "dependencies": {
+        "@types/hast": "^3.0.0",
         "@types/mdast": "^4.0.0",
-        "@types/unist": "^3.0.0",
-        "decode-named-character-reference": "^1.0.0",
+        "@ungap/structured-clone": "^1.0.0",
         "devlop": "^1.0.0",
-        "mdast-util-to-string": "^4.0.0",
-        "micromark": "^4.0.0",
-        "micromark-util-decode-numeric-character-reference": "^2.0.0",
-        "micromark-util-decode-string": "^2.0.0",
-        "micromark-util-normalize-identifier": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0",
-        "unist-util-stringify-position": "^4.0.0"
+        "micromark-util-sanitize-uri": "^2.0.0",
+        "trim-lines": "^3.0.0",
+        "unist-util-position": "^5.0.0",
+        "unist-util-visit": "^5.0.0",
+        "vfile": "^6.0.0"
       },
       "funding": {
         "type": "opencollective",
         "url": "https://opencollective.com/unified"
       }
     },
-    "node_modules/mdast-util-frontmatter": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/mdast-util-frontmatter/-/mdast-util-frontmatter-2.0.1.tgz",
-      "integrity": "sha512-LRqI9+wdgC25P0URIJY9vwocIzCcksduHQ9OF2joxQoyTNVduwLAFUzjoopuRJbJAReaKrNQKAZKL3uCMugWJA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "devlop": "^1.0.0",
-        "escape-string-regexp": "^5.0.0",
-        "mdast-util-from-markdown": "^2.0.0",
-        "mdast-util-to-markdown": "^2.0.0",
-        "micromark-extension-frontmatter": "^2.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/mdast-util-phrasing": {
-      "version": "4.1.0",
-      "resolved": "https://registry.npmjs.org/mdast-util-phrasing/-/mdast-util-phrasing-4.1.0.tgz",
-      "integrity": "sha512-TqICwyvJJpBwvGAMZjj4J2n0X8QWp21b9l0o7eXyVJ25YNWYbJDVIyD1bZXE6WtV6RmKJVYmQAKWa0zWOABz2w==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "unist-util-is": "^6.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/mdast-util-to-hast": {
-      "version": "13.2.1",
-      "resolved": "https://registry.npmjs.org/mdast-util-to-hast/-/mdast-util-to-hast-13.2.1.tgz",
-      "integrity": "sha512-cctsq2wp5vTsLIcaymblUriiTcZd0CwWtCbLvrOzYCDZoWyMNV8sZ7krj09FSnsiJi3WVsHLM4k6Dq/yaPyCXA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/hast": "^3.0.0",
-        "@types/mdast": "^4.0.0",
-        "@ungap/structured-clone": "^1.0.0",
-        "devlop": "^1.0.0",
-        "micromark-util-sanitize-uri": "^2.0.0",
-        "trim-lines": "^3.0.0",
-        "unist-util-position": "^5.0.0",
-        "unist-util-visit": "^5.0.0",
-        "vfile": "^6.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/mdast-util-to-markdown": {
-      "version": "2.1.2",
-      "resolved": "https://registry.npmjs.org/mdast-util-to-markdown/-/mdast-util-to-markdown-2.1.2.tgz",
-      "integrity": "sha512-xj68wMTvGXVOKonmog6LwyJKrYXZPvlwabaryTjLh9LuvovB/KAH+kvi8Gjj+7rJjsFi23nkUxRQv1KqSroMqA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "@types/unist": "^3.0.0",
-        "longest-streak": "^3.0.0",
-        "mdast-util-phrasing": "^4.0.0",
-        "mdast-util-to-string": "^4.0.0",
-        "micromark-util-classify-character": "^2.0.0",
-        "micromark-util-decode-string": "^2.0.0",
-        "unist-util-visit": "^5.0.0",
-        "zwitch": "^2.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/mdast-util-to-string": {
-      "version": "4.0.0",
-      "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-4.0.0.tgz",
-      "integrity": "sha512-0H44vDimn51F0YwvxSJSm0eCDOJTRlmN0R1yBh4HLj9wiV1Dn0QoXGbvFAWj2hSItVTlCmBF1hqKlIyUBVFLPg==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/mdurl": {
-      "version": "2.0.0",
-      "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-2.0.0.tgz",
-      "integrity": "sha512-Lf+9+2r+Tdp5wXDXC4PcIBjTDtq4UKjCPMQhKIuzpJNW0b96kVqSwW0bT7FhRSfmAiFYgP+SCRvdrDozfh0U5w==",
-      "dev": true,
-      "license": "MIT"
-    },
     "node_modules/mermaid": {
       "version": "11.15.0",
       "resolved": "https://registry.npmjs.org/mermaid/-/mermaid-11.15.0.tgz",
       "integrity": "sha512-pTMbcf3rWdtLiYGpmoTjHEpeY8seiy6sR+9nD7LOs8KfUbHE4lOUAprTRqRAcWSQ6MQpdX+YEsxShtGsINtPtw==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@braintree/sanitize-url": "^7.1.1",
-        "@iconify/utils": "^3.0.2",
-        "@mermaid-js/parser": "^1.1.1",
-        "@types/d3": "^7.4.3",
-        "@upsetjs/venn.js": "^2.0.0",
-        "cytoscape": "^3.33.1",
-        "cytoscape-cose-bilkent": "^4.1.0",
-        "cytoscape-fcose": "^2.2.0",
-        "d3": "^7.9.0",
-        "d3-sankey": "^0.12.3",
-        "dagre-d3-es": "7.0.14",
-        "dayjs": "^1.11.19",
-        "dompurify": "^3.3.1",
-        "es-toolkit": "^1.45.1",
-        "katex": "^0.16.25",
-        "khroma": "^2.1.0",
-        "marked": "^16.3.0",
-        "roughjs": "^4.6.6",
-        "stylis": "^4.3.6",
-        "ts-dedent": "^2.2.0",
-        "uuid": "^11.1.0 || ^12 || ^13 || ^14.0.0"
-      }
-    },
-    "node_modules/micromark": {
-      "version": "4.0.2",
-      "resolved": "https://registry.npmjs.org/micromark/-/micromark-4.0.2.tgz",
-      "integrity": "sha512-zpe98Q6kvavpCr1NPVSCMebCKfD7CA2NqZ+rykeNhONIJBpc1tFKt9hucLGwha3jNTNI8lHpctWJWoimVF4PfA==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "@types/debug": "^4.0.0",
-        "debug": "^4.0.0",
-        "decode-named-character-reference": "^1.0.0",
-        "devlop": "^1.0.0",
-        "micromark-core-commonmark": "^2.0.0",
-        "micromark-factory-space": "^2.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-chunked": "^2.0.0",
-        "micromark-util-combine-extensions": "^2.0.0",
-        "micromark-util-decode-numeric-character-reference": "^2.0.0",
-        "micromark-util-encode": "^2.0.0",
-        "micromark-util-normalize-identifier": "^2.0.0",
-        "micromark-util-resolve-all": "^2.0.0",
-        "micromark-util-sanitize-uri": "^2.0.0",
-        "micromark-util-subtokenize": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-core-commonmark": {
-      "version": "2.0.3",
-      "resolved": "https://registry.npmjs.org/micromark-core-commonmark/-/micromark-core-commonmark-2.0.3.tgz",
-      "integrity": "sha512-RDBrHEMSxVFLg6xvnXmb1Ayr2WzLAWjeSATAoxwKYJV94TeNavgoIdA0a9ytzDSVzBy2YKFK+emCPOEibLeCrg==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "decode-named-character-reference": "^1.0.0",
-        "devlop": "^1.0.0",
-        "micromark-factory-destination": "^2.0.0",
-        "micromark-factory-label": "^2.0.0",
-        "micromark-factory-space": "^2.0.0",
-        "micromark-factory-title": "^2.0.0",
-        "micromark-factory-whitespace": "^2.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-chunked": "^2.0.0",
-        "micromark-util-classify-character": "^2.0.0",
-        "micromark-util-html-tag-name": "^2.0.0",
-        "micromark-util-normalize-identifier": "^2.0.0",
-        "micromark-util-resolve-all": "^2.0.0",
-        "micromark-util-subtokenize": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-extension-frontmatter": {
-      "version": "2.0.0",
-      "resolved": "https://registry.npmjs.org/micromark-extension-frontmatter/-/micromark-extension-frontmatter-2.0.0.tgz",
-      "integrity": "sha512-C4AkuM3dA58cgZha7zVnuVxBhDsbttIMiytjgsM2XbHAB2faRVaHRle40558FBN+DJcrLNCoqG5mlrpdU4cRtg==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "fault": "^2.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/micromark-factory-destination": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-factory-destination/-/micromark-factory-destination-2.0.1.tgz",
-      "integrity": "sha512-Xe6rDdJlkmbFRExpTOmRj9N3MaWmbAgdpSrBQvCFqhezUn4AHqJHbaEnfbVYYiexVSs//tqOdY/DxhjdCiJnIA==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-factory-label": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-factory-label/-/micromark-factory-label-2.0.1.tgz",
-      "integrity": "sha512-VFMekyQExqIW7xIChcXn4ok29YE3rnuyveW3wZQWWqF4Nv9Wk5rgJ99KzPvHjkmPXF93FXIbBp6YdW3t71/7Vg==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "devlop": "^1.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-factory-space": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-factory-space/-/micromark-factory-space-2.0.1.tgz",
-      "integrity": "sha512-zRkxjtBxxLd2Sc0d+fbnEunsTj46SWXgXciZmHq0kDYGnck/ZSGj9/wULTV95uoeYiK5hRXP2mJ98Uo4cq/LQg==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-factory-title": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-factory-title/-/micromark-factory-title-2.0.1.tgz",
-      "integrity": "sha512-5bZ+3CjhAd9eChYTHsjy6TGxpOFSKgKKJPJxr293jTbfry2KDoWkhBb6TcPVB4NmzaPhMs1Frm9AZH7OD4Cjzw==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-factory-space": "^2.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-factory-whitespace": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-factory-whitespace/-/micromark-factory-whitespace-2.0.1.tgz",
-      "integrity": "sha512-Ob0nuZ3PKt/n0hORHyvoD9uZhr+Za8sFoP+OnMcnWK5lngSzALgQYKMr9RJVOWLqQYuyn6ulqGWSXdwf6F80lQ==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-factory-space": "^2.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-character": {
-      "version": "2.1.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-character/-/micromark-util-character-2.1.1.tgz",
-      "integrity": "sha512-wv8tdUTJ3thSFFFJKtpYKOYiGP2+v96Hvk4Tu8KpCAsTMs6yi+nVmGh1syvSCsaxz45J6Jbw+9DD6g97+NV67Q==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-chunked": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-chunked/-/micromark-util-chunked-2.0.1.tgz",
-      "integrity": "sha512-QUNFEOPELfmvv+4xiNg2sRYeS/P84pTW0TCgP5zc9FpXetHY0ab7SxKyAQCNCc1eK0459uoLI1y5oO5Vc1dbhA==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-symbol": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-classify-character": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-classify-character/-/micromark-util-classify-character-2.0.1.tgz",
-      "integrity": "sha512-K0kHzM6afW/MbeWYWLjoHQv1sgg2Q9EccHEDzSkxiP/EaagNzCm7T/WMKZ3rjMbvIpvBiZgwR3dKMygtA4mG1Q==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-combine-extensions": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-combine-extensions/-/micromark-util-combine-extensions-2.0.1.tgz",
-      "integrity": "sha512-OnAnH8Ujmy59JcyZw8JSbK9cGpdVY44NKgSM7E9Eh7DiLS2E9RNQf0dONaGDzEG9yjEl5hcqeIsj4hfRkLH/Bg==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-chunked": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-decode-numeric-character-reference": {
-      "version": "2.0.2",
-      "resolved": "https://registry.npmjs.org/micromark-util-decode-numeric-character-reference/-/micromark-util-decode-numeric-character-reference-2.0.2.tgz",
-      "integrity": "sha512-ccUbYk6CwVdkmCQMyr64dXz42EfHGkPQlBj5p7YVGzq8I7CtjXZJrubAYezf7Rp+bjPseiROqe7G6foFd+lEuw==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-symbol": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-decode-string": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-decode-string/-/micromark-util-decode-string-2.0.1.tgz",
-      "integrity": "sha512-nDV/77Fj6eH1ynwscYTOsbK7rR//Uj0bZXBwJZRfaLEJ1iGBR6kIfNmlNqaqJf649EP0F3NWNdeJi03elllNUQ==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "decode-named-character-reference": "^1.0.0",
-        "micromark-util-character": "^2.0.0",
-        "micromark-util-decode-numeric-character-reference": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0"
-      }
-    },
-    "node_modules/micromark-util-encode": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-encode/-/micromark-util-encode-2.0.1.tgz",
-      "integrity": "sha512-c3cVx2y4KqUnwopcO9b/SCdo2O67LwJJ/UyqGfbigahfegL9myoEFoDYZgkT7f36T0bLrM9hZTAaAyH+PCAXjw==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT"
-    },
-    "node_modules/micromark-util-html-tag-name": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-html-tag-name/-/micromark-util-html-tag-name-2.0.1.tgz",
-      "integrity": "sha512-2cNEiYDhCWKI+Gs9T0Tiysk136SnR13hhO8yW6BGNyhOC4qYFnwF1nKfD3HFAIXA5c45RrIG1ub11GiXeYd1xA==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT"
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "@braintree/sanitize-url": "^7.1.1",
+        "@iconify/utils": "^3.0.2",
+        "@mermaid-js/parser": "^1.1.1",
+        "@types/d3": "^7.4.3",
+        "@upsetjs/venn.js": "^2.0.0",
+        "cytoscape": "^3.33.1",
+        "cytoscape-cose-bilkent": "^4.1.0",
+        "cytoscape-fcose": "^2.2.0",
+        "d3": "^7.9.0",
+        "d3-sankey": "^0.12.3",
+        "dagre-d3-es": "7.0.14",
+        "dayjs": "^1.11.19",
+        "dompurify": "^3.3.1",
+        "es-toolkit": "^1.45.1",
+        "katex": "^0.16.25",
+        "khroma": "^2.1.0",
+        "marked": "^16.3.0",
+        "roughjs": "^4.6.6",
+        "stylis": "^4.3.6",
+        "ts-dedent": "^2.2.0",
+        "uuid": "^11.1.0 || ^12 || ^13 || ^14.0.0"
+      }
     },
-    "node_modules/micromark-util-normalize-identifier": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-normalize-identifier/-/micromark-util-normalize-identifier-2.0.1.tgz",
-      "integrity": "sha512-sxPqmo70LyARJs0w2UclACPUUEqltCkJ6PhKdMIDuJ3gSf/Q+/GIe3WKl0Ijb/GyH9lOpUkRAO2wp0GVkLvS9Q==",
+    "node_modules/micromark-util-character": {
+      "version": "2.1.1",
+      "resolved": "https://registry.npmjs.org/micromark-util-character/-/micromark-util-character-2.1.1.tgz",
+      "integrity": "sha512-wv8tdUTJ3thSFFFJKtpYKOYiGP2+v96Hvk4Tu8KpCAsTMs6yi+nVmGh1syvSCsaxz45J6Jbw+9DD6g97+NV67Q==",
       "dev": true,
       "funding": [
         {
@@ -3888,13 +3020,14 @@
       ],
       "license": "MIT",
       "dependencies": {
-        "micromark-util-symbol": "^2.0.0"
+        "micromark-util-symbol": "^2.0.0",
+        "micromark-util-types": "^2.0.0"
       }
     },
-    "node_modules/micromark-util-resolve-all": {
+    "node_modules/micromark-util-encode": {
       "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/micromark-util-resolve-all/-/micromark-util-resolve-all-2.0.1.tgz",
-      "integrity": "sha512-VdQyxFWFT2/FGJgwQnJYbe1jjQoNTS4RjglmSjTUlpUMa95Htx9NHeYW4rGDJzbjvCsl9eLjMQwGeElsqmzcHg==",
+      "resolved": "https://registry.npmjs.org/micromark-util-encode/-/micromark-util-encode-2.0.1.tgz",
+      "integrity": "sha512-c3cVx2y4KqUnwopcO9b/SCdo2O67LwJJ/UyqGfbigahfegL9myoEFoDYZgkT7f36T0bLrM9hZTAaAyH+PCAXjw==",
       "dev": true,
       "funding": [
         {
@@ -3906,10 +3039,7 @@
           "url": "https://opencollective.com/unified"
         }
       ],
-      "license": "MIT",
-      "dependencies": {
-        "micromark-util-types": "^2.0.0"
-      }
+      "license": "MIT"
     },
     "node_modules/micromark-util-sanitize-uri": {
       "version": "2.0.1",
@@ -3933,29 +3063,6 @@
         "micromark-util-symbol": "^2.0.0"
       }
     },
-    "node_modules/micromark-util-subtokenize": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/micromark-util-subtokenize/-/micromark-util-subtokenize-2.1.0.tgz",
-      "integrity": "sha512-XQLu552iSctvnEcgXw6+Sx75GflAPNED1qx7eBJ+wydBb2KCbRZe+NwvIEEMM83uml1+2WSXpBAcp9IUCgCYWA==",
-      "dev": true,
-      "funding": [
-        {
-          "type": "GitHub Sponsors",
-          "url": "https://github.com/sponsors/unifiedjs"
-        },
-        {
-          "type": "OpenCollective",
-          "url": "https://opencollective.com/unified"
-        }
-      ],
-      "license": "MIT",
-      "dependencies": {
-        "devlop": "^1.0.0",
-        "micromark-util-chunked": "^2.0.0",
-        "micromark-util-symbol": "^2.0.0",
-        "micromark-util-types": "^2.0.0"
-      }
-    },
     "node_modules/micromark-util-symbol": {
       "version": "2.0.1",
       "resolved": "https://registry.npmjs.org/micromark-util-symbol/-/micromark-util-symbol-2.0.1.tgz",
@@ -3990,35 +3097,6 @@
       ],
       "license": "MIT"
     },
-    "node_modules/millify": {
-      "version": "6.1.0",
-      "resolved": "https://registry.npmjs.org/millify/-/millify-6.1.0.tgz",
-      "integrity": "sha512-H/E3J6t+DQs/F2YgfDhxUVZz/dF8JXPPKTLHL/yHCcLZLtCXJDUaqvhJXQwqOVBvbyNn4T0WjLpIHd7PAw7fBA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "yargs": "^17.0.1"
-      },
-      "bin": {
-        "millify": "bin/millify"
-      }
-    },
-    "node_modules/minimatch": {
-      "version": "10.2.5",
-      "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-10.2.5.tgz",
-      "integrity": "sha512-MULkVLfKGYDFYejP07QOurDLLQpcjk7Fw+7jXS2R2czRQzR56yHRveU5NDJEOviH+hETZKSkIk5c+T23GjFUMg==",
-      "dev": true,
-      "license": "BlueOak-1.0.0",
-      "dependencies": {
-        "brace-expansion": "^5.0.5"
-      },
-      "engines": {
-        "node": "18 || 20 || >=22"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
-      }
-    },
     "node_modules/minisearch": {
       "version": "7.2.0",
       "resolved": "https://registry.npmjs.org/minisearch/-/minisearch-7.2.0.tgz",
@@ -4033,13 +3111,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/ms": {
-      "version": "2.1.3",
-      "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz",
-      "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==",
-      "dev": true,
-      "license": "MIT"
-    },
     "node_modules/nanoid": {
       "version": "3.3.12",
       "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.12.tgz",
@@ -4093,13 +3164,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/path-to-regexp": {
-      "version": "6.3.0",
-      "resolved": "https://registry.npmjs.org/path-to-regexp/-/path-to-regexp-6.3.0.tgz",
-      "integrity": "sha512-Yhpw4T9C6hPpgPeA28us07OJeqZ5EzQTkbfwuhsUg0c237RomFoETJgmp2sa3F/41gfLE6G5cqcYwznmeEeOlQ==",
-      "dev": true,
-      "license": "MIT"
-    },
     "node_modules/perfect-debounce": {
       "version": "1.0.0",
       "resolved": "https://registry.npmjs.org/perfect-debounce/-/perfect-debounce-1.0.0.tgz",
@@ -4172,19 +3236,6 @@
         "url": "https://opencollective.com/preact"
       }
     },
-    "node_modules/pretty-bytes": {
-      "version": "7.1.0",
-      "resolved": "https://registry.npmjs.org/pretty-bytes/-/pretty-bytes-7.1.0.tgz",
-      "integrity": "sha512-nODzvTiYVRGRqAOvE84Vk5JDPyyxsVk0/fbA/bq7RqlnhksGpset09XTxbpvLTIjoaF7K8Z8DG8yHtKGTPSYRw==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=20"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
-      }
-    },
     "node_modules/property-information": {
       "version": "7.1.0",
       "resolved": "https://registry.npmjs.org/property-information/-/property-information-7.1.0.tgz",
@@ -4196,16 +3247,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/punycode.js": {
-      "version": "2.3.1",
-      "resolved": "https://registry.npmjs.org/punycode.js/-/punycode.js-2.3.1.tgz",
-      "integrity": "sha512-uxFIHU0YlHYhDQtV4R9J6a52SLx28BCjT+4ieh7IGbgwVJWO+km431c4yRlREUAsAmt/uMjQUyQHNEPf0M39CA==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=6"
-      }
-    },
     "node_modules/regex": {
       "version": "6.1.0",
       "resolved": "https://registry.npmjs.org/regex/-/regex-6.1.0.tgz",
@@ -4233,83 +3274,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/remark": {
-      "version": "15.0.1",
-      "resolved": "https://registry.npmjs.org/remark/-/remark-15.0.1.tgz",
-      "integrity": "sha512-Eht5w30ruCXgFmxVUSlNWQ9iiimq07URKeFS3hNc8cUWy1llX4KDWfyEDZRycMc+znsN9Ux5/tJ/BFdgdOwA3A==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "remark-parse": "^11.0.0",
-        "remark-stringify": "^11.0.0",
-        "unified": "^11.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/remark-frontmatter": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/remark-frontmatter/-/remark-frontmatter-5.0.0.tgz",
-      "integrity": "sha512-XTFYvNASMe5iPN0719nPrdItC9aU0ssC4v14mH1BCi1u0n1gAocqcujWUrByftZTbLhRtiKRyjYTSIOcr69UVQ==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "mdast-util-frontmatter": "^2.0.0",
-        "micromark-extension-frontmatter": "^2.0.0",
-        "unified": "^11.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/remark-parse": {
-      "version": "11.0.0",
-      "resolved": "https://registry.npmjs.org/remark-parse/-/remark-parse-11.0.0.tgz",
-      "integrity": "sha512-FCxlKLNGknS5ba/1lmpYijMUzX2esxW5xQqjWxw2eHFfS2MSdaHVINFmhjo+qN1WhZhNimq0dZATN9pH0IDrpA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "mdast-util-from-markdown": "^2.0.0",
-        "micromark-util-types": "^2.0.0",
-        "unified": "^11.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/remark-stringify": {
-      "version": "11.0.0",
-      "resolved": "https://registry.npmjs.org/remark-stringify/-/remark-stringify-11.0.0.tgz",
-      "integrity": "sha512-1OSmLd3awB/t8qdoEOMazZkNsfVTeY4fTsgzcQFdXNq8ToTN4ZGwrMnlda4K6smTFKD+GRV6O48i6Z4iKgPPpw==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/mdast": "^4.0.0",
-        "mdast-util-to-markdown": "^2.0.0",
-        "unified": "^11.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
-    "node_modules/require-directory": {
-      "version": "2.1.1",
-      "resolved": "https://registry.npmjs.org/require-directory/-/require-directory-2.1.1.tgz",
-      "integrity": "sha512-fGxEI7+wsG9xrvdjsrlmL22OMTTiHRwAMroiEeMgq8gzoLC/PQr7RsRDSTLUg/bZAZtF+TVIkHc6/4RIKrui+Q==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
     "node_modules/rfdc": {
       "version": "1.4.1",
       "resolved": "https://registry.npmjs.org/rfdc/-/rfdc-1.4.1.tgz",
@@ -4404,20 +3368,6 @@
       "license": "MIT",
       "peer": true
     },
-    "node_modules/section-matter": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/section-matter/-/section-matter-1.0.0.tgz",
-      "integrity": "sha512-vfD3pmTzGpufjScBh50YHKzEu2lxBWhVEHsNGoEXmCmn2hKGfeNLYMzCJpe8cD7gqX7TJluOVpBkAequ6dgMmA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "extend-shallow": "^2.0.1",
-        "kind-of": "^6.0.0"
-      },
-      "engines": {
-        "node": ">=4"
-      }
-    },
     "node_modules/shiki": {
       "version": "2.5.0",
       "resolved": "https://registry.npmjs.org/shiki/-/shiki-2.5.0.tgz",
@@ -4466,28 +3416,6 @@
         "node": ">=0.10.0"
       }
     },
-    "node_modules/sprintf-js": {
-      "version": "1.0.3",
-      "resolved": "https://registry.npmjs.org/sprintf-js/-/sprintf-js-1.0.3.tgz",
-      "integrity": "sha512-D9cPgkvLlV3t3IzL0D0YLvGA9Ahk4PcvVwUbN0dSGr1aP0Nrt4AEnTUbuGvquEC0mA64Gqt1fzirlRs5ibXx8g==",
-      "dev": true,
-      "license": "BSD-3-Clause"
-    },
-    "node_modules/string-width": {
-      "version": "4.2.3",
-      "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
-      "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "emoji-regex": "^8.0.0",
-        "is-fullwidth-code-point": "^3.0.0",
-        "strip-ansi": "^6.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
     "node_modules/stringify-entities": {
       "version": "4.0.4",
       "resolved": "https://registry.npmjs.org/stringify-entities/-/stringify-entities-4.0.4.tgz",
@@ -4503,29 +3431,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/strip-ansi": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
-      "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "ansi-regex": "^5.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/strip-bom-string": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/strip-bom-string/-/strip-bom-string-1.0.0.tgz",
-      "integrity": "sha512-uCC2VHvQRYu+lMh4My/sFNmF2klFymLX1wHJeXnbEJERpV/ZsVuonzerjfrGpIGF7LBVa1O7i9kjiWvJiFck8g==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
     "node_modules/stylis": {
       "version": "4.4.0",
       "resolved": "https://registry.npmjs.org/stylis/-/stylis-4.4.0.tgz",
@@ -4563,13 +3468,6 @@
         "node": ">=18"
       }
     },
-    "node_modules/tokenx": {
-      "version": "1.3.0",
-      "resolved": "https://registry.npmjs.org/tokenx/-/tokenx-1.3.0.tgz",
-      "integrity": "sha512-NLdXTEZkKiO0gZuLtMoZKjCXTREXeZZt8nnnNeyoXtNZAfG/GKGSbQtLU5STspc0rMSwcA+UJfWZkbNU01iKmQ==",
-      "dev": true,
-      "license": "MIT"
-    },
     "node_modules/trim-lines": {
       "version": "3.0.1",
       "resolved": "https://registry.npmjs.org/trim-lines/-/trim-lines-3.0.1.tgz",
@@ -4581,17 +3479,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/trough": {
-      "version": "2.2.0",
-      "resolved": "https://registry.npmjs.org/trough/-/trough-2.2.0.tgz",
-      "integrity": "sha512-tmMpK00BjZiUyVyvrBK7knerNgmgvcV/KLVyuma/SC+TQN167GrMRciANTz09+k3zW8L8t60jWO1GpfkZdjTaw==",
-      "dev": true,
-      "license": "MIT",
-      "funding": {
-        "type": "github",
-        "url": "https://github.com/sponsors/wooorm"
-      }
-    },
     "node_modules/ts-dedent": {
       "version": "2.2.0",
       "resolved": "https://registry.npmjs.org/ts-dedent/-/ts-dedent-2.2.0.tgz",
@@ -4602,33 +3489,6 @@
         "node": ">=6.10"
       }
     },
-    "node_modules/uc.micro": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-2.1.0.tgz",
-      "integrity": "sha512-ARDJmphmdvUk6Glw7y9DQ2bFkKBHwQHLi2lsaH6PPmz/Ka9sFOBsBluozhDltWmnv9u/cF6Rt87znRTPV+yp/A==",
-      "dev": true,
-      "license": "MIT"
-    },
-    "node_modules/unified": {
-      "version": "11.0.5",
-      "resolved": "https://registry.npmjs.org/unified/-/unified-11.0.5.tgz",
-      "integrity": "sha512-xKvGhPWw3k84Qjh8bI3ZeJjqnyadK+GEFtazSfZv/rKeTkTjOJho6mFqh2SM96iIcZokxiOpg78GazTSg8+KHA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/unist": "^3.0.0",
-        "bail": "^2.0.0",
-        "devlop": "^1.0.0",
-        "extend": "^3.0.0",
-        "is-plain-obj": "^4.0.0",
-        "trough": "^2.0.0",
-        "vfile": "^6.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
     "node_modules/unist-util-is": {
       "version": "6.0.1",
       "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-6.0.1.tgz",
@@ -4657,22 +3517,6 @@
         "url": "https://opencollective.com/unified"
       }
     },
-    "node_modules/unist-util-remove": {
-      "version": "4.0.0",
-      "resolved": "https://registry.npmjs.org/unist-util-remove/-/unist-util-remove-4.0.0.tgz",
-      "integrity": "sha512-b4gokeGId57UVRX/eVKej5gXqGlc9+trkORhFJpu9raqZkZhU0zm8Doi05+HaiBsMEIJowL+2WtQ5ItjsngPXg==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@types/unist": "^3.0.0",
-        "unist-util-is": "^6.0.0",
-        "unist-util-visit-parents": "^6.0.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/unified"
-      }
-    },
     "node_modules/unist-util-stringify-position": {
       "version": "4.0.0",
       "resolved": "https://registry.npmjs.org/unist-util-stringify-position/-/unist-util-stringify-position-4.0.0.tgz",
@@ -4864,35 +3708,6 @@
         }
       }
     },
-    "node_modules/vitepress-plugin-llms": {
-      "version": "1.12.2",
-      "resolved": "https://registry.npmjs.org/vitepress-plugin-llms/-/vitepress-plugin-llms-1.12.2.tgz",
-      "integrity": "sha512-hdklo7di6E2/MwlYstH7R5QgdPHX+f5G/fp8QBq6MCiw4DWi3IOKMaous0S839FIGsPjK3QHwK6KcFwCf/XzjA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "gray-matter": "^4.0.3",
-        "markdown-it": "^14.1.0",
-        "markdown-title": "^1.0.2",
-        "mdast-util-from-markdown": "^2.0.3",
-        "millify": "^6.1.0",
-        "minimatch": "^10.2.5",
-        "path-to-regexp": "^6.3.0",
-        "picocolors": "^1.1.1",
-        "pretty-bytes": "^7.1.0",
-        "remark": "^15.0.1",
-        "remark-frontmatter": "^5.0.0",
-        "tokenx": "^1.3.0",
-        "unist-util-remove": "^4.0.0",
-        "unist-util-visit": "^5.1.0"
-      },
-      "engines": {
-        "node": ">=18.0.0"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/okineadev"
-      }
-    },
     "node_modules/vitepress-plugin-mermaid": {
       "version": "2.0.17",
       "resolved": "https://registry.npmjs.org/vitepress-plugin-mermaid/-/vitepress-plugin-mermaid-2.0.17.tgz",
@@ -4929,63 +3744,6 @@
         }
       }
     },
-    "node_modules/wrap-ansi": {
-      "version": "7.0.0",
-      "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz",
-      "integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "ansi-styles": "^4.0.0",
-        "string-width": "^4.1.0",
-        "strip-ansi": "^6.0.0"
-      },
-      "engines": {
-        "node": ">=10"
-      },
-      "funding": {
-        "url": "https://github.com/chalk/wrap-ansi?sponsor=1"
-      }
-    },
-    "node_modules/y18n": {
-      "version": "5.0.8",
-      "resolved": "https://registry.npmjs.org/y18n/-/y18n-5.0.8.tgz",
-      "integrity": "sha512-0pfFzegeDWJHJIAmTLRP2DwHjdF5s7jo9tuztdQxAhINCdvS+3nGINqPd00AphqJR/0LhANUS6/+7SCb98YOfA==",
-      "dev": true,
-      "license": "ISC",
-      "engines": {
-        "node": ">=10"
-      }
-    },
-    "node_modules/yargs": {
-      "version": "17.7.2",
-      "resolved": "https://registry.npmjs.org/yargs/-/yargs-17.7.2.tgz",
-      "integrity": "sha512-7dSzzRQ++CKnNI/krKnYRV7JKKPUXMEh61soaHKg9mrWEhzFWhFnxPxGl+69cD1Ou63C13NUPCnmIcrvqCuM6w==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "cliui": "^8.0.1",
-        "escalade": "^3.1.1",
-        "get-caller-file": "^2.0.5",
-        "require-directory": "^2.1.1",
-        "string-width": "^4.2.3",
-        "y18n": "^5.0.5",
-        "yargs-parser": "^21.1.1"
-      },
-      "engines": {
-        "node": ">=12"
-      }
-    },
-    "node_modules/yargs-parser": {
-      "version": "21.1.1",
-      "resolved": "https://registry.npmjs.org/yargs-parser/-/yargs-parser-21.1.1.tgz",
-      "integrity": "sha512-tVpsJW7DdjecAiFpbIB1e3qxIQsE6NoPc5/eTdrbbIC4h0LVsWhnoa3g+m2HclBIujHzsxZ4VJVA+GUuc2/LBw==",
-      "dev": true,
-      "license": "ISC",
-      "engines": {
-        "node": ">=12"
-      }
-    },
     "node_modules/zwitch": {
       "version": "2.0.4",
       "resolved": "https://registry.npmjs.org/zwitch/-/zwitch-2.0.4.tgz",
diff --git a/docs/package.json b/docs/package.json
index cd0d38d..f696b38 100644
--- a/docs/package.json
+++ b/docs/package.json
@@ -11,10 +11,7 @@
   "devDependencies": {
     "vitepress": "^1.6.4",
     "vitepress-plugin-mermaid": "^2.0.17",
-    "mermaid": "^11.12.2",
-    "vitepress-plugin-llms": "^1.10.0"
+    "mermaid": "^11.12.2"
   },
-  "dependencies": {
-    "monaco-editor": "^0.50.0"
-  }
+  "dependencies": {}
 }
diff --git a/docs/scripts/sync-changelog.mjs b/docs/scripts/sync-changelog.mjs
deleted file mode 100644
index 5c15fcd..0000000
--- a/docs/scripts/sync-changelog.mjs
+++ /dev/null
@@ -1,101 +0,0 @@
-/**
- * Sync CHANGELOG.md to docs for release notes
- * Converts format: ## [2.1.0] - 2024-05-13 → ## 2.1.0 (2024-05-13)
- */
-
-import fs from 'fs'
-import path from 'path'
-
-const CHANGELOG_PATH = path.resolve('../CHANGELOG.md')
-const OUTPUT_EN_PATH = path.resolve('../docs/en/changelog.md')
-const OUTPUT_ZH_PATH = path.resolve('../docs/zh/changelog.md')
-
-function parseChangelog(content) {
-  const lines = content.split('\n')
-  const releases = []
-  let currentRelease = null
-  let currentContent = []
-
-  for (const line of lines) {
-    // Match: ## [version] - date
-    const releaseMatch = line.match(/^## \[([^\]]+)\] - (\d{4}-\d{2}-\d{2})/)
-    if (releaseMatch) {
-      if (currentRelease) {
-        releases.push({
-          version: currentRelease.version,
-          date: currentRelease.date,
-          content: currentContent.join('\n').trim()
-        })
-      }
-      currentRelease = {
-        version: releaseMatch[1],
-        date: releaseMatch[2]
-      }
-      currentContent = []
-    } else if (currentRelease) {
-      currentContent.push(line)
-    }
-  }
-
-  // Don't forget the last release
-  if (currentRelease) {
-    releases.push({
-      version: currentRelease.version,
-      date: currentRelease.date,
-      content: currentContent.join('\n').trim()
-    })
-  }
-
-  return releases
-}
-
-function generateDocContent(releases, lang = 'en') {
-  const title = lang === 'en' ? '# Changelog' : '# 更新日志'
-  const description = lang === 'en'
-    ? 'All notable changes to this project will be documented in this file.'
-    : '本项目所有重要变更都将记录在此文件中。'
-
-  const content = [title, '', description, '', '---', '']
-
-  for (const release of releases) {
-    const header = `## ${release.version} (${release.date})`
-    content.push(header)
-    content.push('')
-    if (release.content) {
-      content.push(release.content)
-      content.push('')
-    }
-  }
-
-  return content.join('\n')
-}
-
-async function syncChangelog() {
-  try {
-    // Read CHANGELOG.md
-    if (!fs.existsSync(CHANGELOG_PATH)) {
-      console.log('CHANGELOG.md not found, skipping sync')
-      return
-    }
-
-    const changelog = fs.readFileSync(CHANGELOG_PATH, 'utf-8')
-    const releases = parseChangelog(changelog)
-
-    // Generate English version
-    const enContent = generateDocContent(releases, 'en')
-    fs.writeFileSync(OUTPUT_EN_PATH, enContent)
-    console.log('Synced to docs/en/changelog.md')
-
-    // Generate Chinese version
-    const zhContent = generateDocContent(releases, 'zh')
-    fs.writeFileSync(OUTPUT_ZH_PATH, zhContent)
-    console.log('Synced to docs/zh/changelog.md')
-
-    console.log(`Successfully synced ${releases.length} releases`)
-  } catch (error) {
-    console.error('Error syncing changelog:', error)
-    process.exit(1)
-  }
-}
-
-syncChangelog()
\ No newline at end of file
diff --git a/docs/zh/README.md b/docs/zh/README.md
index ebd2d9d..d87b2b1 100644
--- a/docs/zh/README.md
+++ b/docs/zh/README.md
@@ -83,7 +83,7 @@ const predictions = await output.download();
 ## 项目链接
 
 - [GitHub 仓库](https://github.com/LessUp/tiny-dl-inference)
-- [更新日志](changelog.md)
+- [更新日志](https://github.com/LessUp/tiny-dl-inference/blob/main/CHANGELOG.md)
 - [问题追踪](https://github.com/LessUp/tiny-dl-inference/issues)
 
 ---
diff --git a/docs/zh/changelog.md b/docs/zh/changelog.md
deleted file mode 100644
index debd6c8..0000000
--- a/docs/zh/changelog.md
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: 更新日志
----
-
-# 更新日志
-
-本项目的所有重要变更都会记录在此文件中。
-
-格式基于 [Keep a Changelog](https://keepachangelog.com/zh-CN/1.1.0/)，
-本项目遵循 [语义化版本](https://semver.org/lang/zh-CN/)。
-
-完整更新日志请参见 [GitHub CHANGELOG.md](https://github.com/LessUp/tiny-dl-inference/blob/main/CHANGELOG.md)。
-
----
-
-## [未发布]
-
-### 新增
-- 完善的双语文档支持（中英文）
-- `docs/` 目录下新的文档站点结构
-- API 参考文档
-- 架构设计文档
-- 性能优化指南
-- 开发贡献指南
-
----
-
-## [2.0.1] - 2026-04-16
-
-### 安全
-- 修复 5 个中等 npm 漏洞（esbuild、vite、vitest）
-- 将 `vitest` 从 v1.6.1 更新至 v4.1.4
-- 将 `@vitest/coverage-v8` 从 v1.6.1 更新至 v4.1.4
-
-### 变更
-- 将 `@webgpu/types` 从 0.1.68 更新至 0.1.69
-- 将 `@types/node` 更新至最新 v20.x
-
----
-
-## [2.0.0] - 2026-03-09
-
-### 新增
-- **零拷贝 Tensor.reshape()** 通过张量视图实现
-  - 显著减少 reshape 密集型模型的内存占用
-  - `Tensor._createView()` 静态方法用于缓冲区共享
-  - `Tensor._isView` 标志用于跟踪视图张量
-- **GPUContext.deferDestroy()** 用于安全的异步缓冲区清理
-  - 防止释放后使用的竞态条件
-  - 自动清理临时 GPU 资源
-- **FlattenOperator** 用于 CNN 到 FC 层的转换
-- **DenseOperator** 用于全连接层
-- **Conv2dBiasReLUOperator** - 融合内核优化
-  - 相比顺序执行减少 3 倍内存流量
-
-### 修复
-- **[关键]** `Tensor.reshape()` 不必要的 GPU 缓冲区分配
-  - 现在使用零拷贝视图，减少内存压力
-- **[关键]** `InferenceEngine.infer()` GPU 内存泄漏
-  - 中间张量现在在使用后正确销毁
-- **[关键]** 算子临时缓冲区清理中的竞态条件
-  - 现在一致使用 `deferDestroy()` 模式
-
-### 性能
-
-| 操作 | 之前 | 之后 | 提升 |
-|------|------|------|------|
-| Flatten | 完整缓冲区复制 | 零开销 | **~100%** |
-| 融合 Conv2d+Bias+ReLU | 6 次内存操作 | 2 次内存操作 | **3×** |
-| 内存泄漏 | 持续存在 | 正确释放 | **稳定** |
-
----
-
-## [1.0.0] - 2026-03-09
-
-### 新增
-- 标准化 CI 工作流，包含 `permissions` 和 `concurrency` 配置
-- Node.js 20 验证流水线（lint、test、build）
-- 自动化依赖安全扫描
-
-### 变更
-- `lint` 脚本现在运行 TypeScript 类型检查
-- 更新 CI 触发器以提高资源效率
-
----
-
-## [0.9.0] - 2026-03-10
-
-### 新增
-- GitHub Pages 部署工作流
-- 双语文档支持
-  - 中文文档 (`README.zh-CN.md`)
-- 架构图
-- SEO 元数据
-
----
-
-## [0.8.0] - 2026-01-08
-
-### 新增
-- `tests/setup.ts` - Node.js 测试环境的 WebGPU 全局变量
-- `tests/tsconfig.json` - 单独的测试 TypeScript 配置
-- `@vitest/coverage-v8` 用于 V8 覆盖率报告
-
-### 修复
-- Vitest 在 Node.js 中因缺少 WebGPU 全局变量而失败
-- 算子测试 mock 未将计算结果写入输出缓冲区
-
-### 变更
-- 所有算子测试都有正确 mock 的 WebGPU 缓冲区生命周期
-- **54 个测试通过**（从 47 个扩展）
-
----
-
-## [0.1.0] - 2025-02-13
-
-### 新增
-- **初始项目基础设施**
-  - MIT 许可证
-  - `.editorconfig` 用于一致的代码格式化
-  - TypeScript 5.x 严格模式
-  - Vitest 测试框架
-
-- **核心组件**
-  - `GPUContext` - 带错误处理的 WebGPU 设备管理
-  - `Tensor` - 支持布局（NCHW/NHWC）的 GPU 缓冲区管理
-  - 所有失败模式的自定义错误类
-
-- **神经网络算子**
-  - `ReLUOperator` - 逐元素激活
-  - `SoftmaxOperator` - 数值稳定的概率分布
-  - `MaxPoolOperator` - 2D 最大池化
-  - `Conv2dOperator` - 直接卷积
-  - `DenseOperator` - 矩阵乘法
-  - `FlattenOperator` - 张量重塑
-
-- **推理引擎**
-  - `InferenceEngine` - 完整推理流水线
-  - `ModelLoader` - JSON 模型加载
-
-- **测试框架**
-  - 使用 `fast-check` 进行基于属性的测试
-  - 每个属性测试 100+ 次迭代
-  - CPU 参考实现用于验证
-
-- **示例**
-  - MNIST 数字分类演示
-  - 性能基准测试演示
-
-### 统计
-- **~2,000** 行源代码
-- **~1,100** 行测试
-- **7** 个神经网络算子
-- **13** 个基于属性的测试
-- 零运行时依赖
-
----
-
-[未发布]: https://github.com/LessUp/tiny-dl-inference/compare/v2.0.1...HEAD
-[2.0.1]: https://github.com/LessUp/tiny-dl-inference/compare/v2.0.0...v2.0.1
-[2.0.0]: https://github.com/LessUp/tiny-dl-inference/compare/v1.0.0...v2.0.0
-[1.0.0]: https://github.com/LessUp/tiny-dl-inference/compare/v0.9.0...v1.0.0
-[0.9.0]: https://github.com/LessUp/tiny-dl-inference/compare/v0.8.0...v0.9.0
-[0.8.0]: https://github.com/LessUp/tiny-dl-inference/compare/v0.1.0...v0.8.0
-[0.1.0]: https://github.com/LessUp/tiny-dl-inference/releases/tag/v0.1.0
diff --git a/docs/zh/contributing.md b/docs/zh/contributing.md
index 6ee7131..75a57c4 100644
--- a/docs/zh/contributing.md
+++ b/docs/zh/contributing.md
@@ -4,7 +4,7 @@ title: 贡献指南
 
 # 贡献指南
 
-感谢您有兴趣为此项目做出贡献！本项目遵循**规范驱动开发（SDD）**，这意味着所有代码变更都必须由 `/specs` 目录中的规范指导。
+感谢您有兴趣为此项目做出贡献。请保持修改聚焦、可测试、易维护。
 
 ---
 
@@ -12,8 +12,8 @@ title: 贡献指南
 
 1. **Fork** 本仓库
 2. **创建** 功能分支：`git checkout -b feature/your-feature`
-3. **审查或更新** `/specs/` 中的规范（编码前）
-4. **实现** 遵循规范的变更
+3. **直接实现** 您的变更
+4. **保持** 变更范围清晰且一致
 5. **测试** 您的变更
 6. **提交** 使用约定式提交
 7. **推送** 并创建 Pull Request
diff --git a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/design.md b/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/design.md
deleted file mode 100644
index 1ad2ce3..0000000
--- a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/design.md
+++ /dev/null
@@ -1,102 +0,0 @@
-## Context
-
-Tiny-DL-Inference currently supports basic CNN operators (Conv2d, MaxPool, ReLU, Softmax, Dense, Flatten) and one fused operator (Conv2dBiasReLU). To support modern architectures like ResNet, we need BatchNorm and element-wise Add for residual connections.
-
-**Current Architecture Pattern:**
-- Each operator extends abstract `Operator` class
-- WGSL shaders embedded as template strings
-- Lazy pipeline initialization on first `forward()` call
-- Property-based testing with CPU reference implementations
-
-## Goals / Non-Goals
-
-**Goals:**
-- Implement BatchNorm2d operator for inference (using pre-computed running mean/variance)
-- Implement Add operator for residual connections
-- Implement Conv2dBatchNormReLU fused operator for optimized inference
-- Enable ResNet-style residual block support
-
-**Non-Goals:**
-- Training mode BatchNorm (no gradient computation)
-- Other element-wise operations (Sub, Mul, Div) — can be added later
-- Automatic fusion detection
-- Other architectures (MobileNet with depthwise-separable conv, Transformers)
-
-## Decisions
-
-### Decision 1: BatchNorm2d Inference Mode Only
-
-**Choice:** Implement inference-mode BatchNorm only, using pre-computed statistics (running mean, running variance, gamma, beta).
-
-**Rationale:**
-- Tiny-DL-Inference is an inference engine, not a training framework
-- Training BatchNorm requires computing batch statistics and gradients
-- Inference BatchNorm is simply: `y = gamma * (x - mean) / sqrt(var + eps) + beta`
-- Pre-computed statistics come from trained models
-
-**Alternative Considered:** Implement both training and inference modes.
-- Rejected: Adds complexity, not aligned with project's inference-only scope.
-
-### Decision 2: Element-wise Add Implementation
-
-**Choice:** Implement a standalone `AddOperator` for element-wise addition of two tensors.
-
-**Rationale:**
-- Residual connections require `output = input + residual`
-- Simple element-wise operation, highly reusable
-- Can be used for other architectures (DenseNet, etc.)
-
-**WGSL Implementation:**
-```wgsl
-@compute @workgroup_size(256)
-fn main(@builtin(global_invocation_id) id: vec3<u32>) {
-  let idx = id.x;
-  if (idx < arrayLength(&input_a)) {
-    output[idx] = input_a[idx] + input_b[idx];
-  }
-}
-```
-
-### Decision 3: Conv2dBatchNormReLU Fusion Strategy
-
-**Choice:** Fuse BatchNorm into Conv2d weights at model load time, then reuse existing Conv2dBiasReLU shader.
-
-**Rationale:**
-- Inference BatchNorm can be mathematically folded into Conv2d:
-  - `BN(Conv(x)) = gamma * (Conv(x) - mean) / sqrt(var + eps) + beta`
-  - This simplifies to a new Conv with adjusted weights and bias
-- Folding formula:
-  - `new_weight = weight * gamma / sqrt(var + eps)`
-  - `new_bias = (bias - mean) / sqrt(var + eps) * gamma + beta`
-- Reuses existing optimized Conv2dBiasReLU shader
-- No new WGSL shader needed
-
-**Alternative Considered:** Create a dedicated Conv2dBatchNormReLU shader.
-- Rejected: More code duplication, BN folding is standard practice.
-
-### Decision 4: NCHW Only for New Operators
-
-**Choice:** BatchNorm2d and Add support NCHW layout only, consistent with existing operators.
-
-**Rationale:**
-- All existing operators (Conv2d, MaxPool) are NCHW-only
-- Maintains consistency
-- NHWC support can be added later if needed
-
-## Risks / Trade-offs
-
-| Risk | Mitigation |
-|------|------------|
-| BatchNorm folding precision loss | Use float32 throughout; acceptable for inference |
-| Add operator doesn't support broadcasting | Document limitation; add broadcast support in future if needed |
-| Fused BN depends on model loader changes | Keep BN folding in operator layer for now, move to model loader later |
-
-## Open Questions
-
-1. **Should Add support broadcasting?** (e.g., add bias tensor [C] to feature map [N,C,H,W])
-   - Current decision: No, require same shapes
-   - Can add later if needed
-
-2. **Should we expose BN folding as a utility function?**
-   - Current decision: Yes, provide `foldBatchNorm(convWeight, convBias, bnGamma, bnBeta, bnMean, bnVar, eps)` utility
-   - Users can pre-process models or we can integrate into model loader
diff --git a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/proposal.md b/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/proposal.md
deleted file mode 100644
index 03b8c5e..0000000
--- a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/proposal.md
+++ /dev/null
@@ -1,42 +0,0 @@
-## Why
-
-Modern CNN architectures (ResNet, MobileNet, EfficientNet) rely on BatchNorm and residual connections (skip connections). Without these operators, Tiny-DL-Inference cannot support these widely-used models. Adding BatchNorm2d and Add operators will enable ResNet support and demonstrate proper GPU implementation of these fundamental operations.
-
-## What Changes
-
-- **New Operator: BatchNorm2d** — Inference-mode batch normalization with pre-computed running mean/variance
-- **New Operator: Add** — Element-wise addition for residual/skip connections
-- **New Fused Operator: Conv2dBatchNormReLU** — Fused Conv + BN + ReLU for optimized inference
-- **New Capability: Residual Block Support** — Enable ResNet-style architecture support
-
-## Capabilities
-
-### New Capabilities
-
-- `batchnorm`: BatchNorm2d operator for inference-time batch normalization with gamma/beta/mean/var parameters
-- `elementwise-ops`: Element-wise operations starting with Add for residual connections
-- `conv-bn-relu-fusion`: Fused Conv2d + BatchNorm + ReLU kernel for optimized inference
-
-### Modified Capabilities
-
-- `api`: Add new operator interfaces (BatchNorm2dOperator, AddOperator, Conv2dBatchNormReLUOperator)
-- `testing`: Add property-based tests for new operators
-- `product`: Update implementation status and supported model list
-
-## Impact
-
-**Code Changes:**
-- `src/operators/` — Add 3 new operator files (~200-300 lines each)
-- `src/index.ts` — Export new operators
-- `tests/operators/` — Add test files for new operators
-
-**API Changes:**
-- New exported classes: `BatchNorm2dOperator`, `AddOperator`, `Conv2dBatchNormReLUOperator`
-- No breaking changes to existing APIs
-
-**Bundle Size:**
-- Estimated +15-20KB (new WGSL shaders + operator code)
-- Still well under 100KB total
-
-**Dependencies:**
-- No new runtime dependencies
diff --git a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/api/spec.md b/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/api/spec.md
deleted file mode 100644
index c62f9ed..0000000
--- a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/api/spec.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## ADDED Requirements
-
-### Requirement: BatchNorm2dOperator API
-
-The system SHALL expose BatchNorm2dOperator with the following interface.
-
-#### Scenario: Constructor
-- **WHEN** creating BatchNorm2dOperator with GPUContext
-- **THEN** operator instance is created with lazy initialization
-
-#### Scenario: Forward with BN parameters
-- **WHEN** calling forward([input, gamma, beta, runningMean, runningVar], { eps?: number })
-- **THEN** returns normalized output tensor
-
-#### Scenario: Default epsilon
-- **WHEN** calling forward without epsilon parameter
-- **THEN** default epsilon 1e-5 is used
-
----
-
-### Requirement: AddOperator API
-
-The system SHALL expose AddOperator with the following interface.
-
-#### Scenario: Constructor
-- **WHEN** creating AddOperator with GPUContext
-- **THEN** operator instance is created with lazy initialization
-
-#### Scenario: Forward with two tensors
-- **WHEN** calling forward([tensorA, tensorB])
-- **THEN** returns element-wise sum tensor
-
----
-
-### Requirement: foldBatchNorm Utility API
-
-The system SHALL expose a foldBatchNorm utility function for BN parameter folding.
-
-#### Scenario: Function signature
-- **WHEN** importing foldBatchNorm from 'tiny-dl-inference'
-- **THEN** function accepts (weight, bias, gamma, beta, mean, var, eps?) and returns { weight, bias }
-
-#### Scenario: Export in index
-- **WHEN** importing from 'tiny-dl-inference'
-- **THEN** BatchNorm2dOperator, AddOperator, foldBatchNorm are available
diff --git a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/batchnorm/spec.md b/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/batchnorm/spec.md
deleted file mode 100644
index 962ddbf..0000000
--- a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/batchnorm/spec.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## ADDED Requirements
-
-### Requirement: BatchNorm2d Inference Operator
-
-The system SHALL provide a BatchNorm2d operator for inference-time batch normalization using pre-computed statistics.
-
-#### Scenario: Basic batch normalization
-- **WHEN** executing BatchNorm2d with input tensor shape [1, 64, 28, 28]
-- **AND** gamma, beta, running_mean, running_var each with shape [64]
-- **THEN** output shape equals input shape [1, 64, 28, 28]
-
-#### Scenario: Correctness against CPU reference
-- **WHEN** executing BatchNorm2d on GPU with any valid configuration
-- **THEN** output matches CPU reference implementation within tolerance 1e-5
-
-#### Scenario: Reject wrong gamma shape
-- **WHEN** executing BatchNorm2d with gamma shape [32] but input has 64 channels
-- **THEN** throws InvalidShapeError
-
-#### Scenario: Reject NHWC input
-- **WHEN** executing BatchNorm2d on NHWC layout tensor
-- **THEN** throws error "NCHW layout only"
-
----
-
-### Requirement: BatchNorm2d Numerical Stability
-
-The system SHALL implement numerically stable batch normalization.
-
-#### Scenario: Handle small variance values
-- **WHEN** executing BatchNorm2d with running_var containing values near zero (1e-10)
-- **THEN** no output value is NaN or Infinity
-
-#### Scenario: Epsilon parameter
-- **WHEN** executing BatchNorm2d with custom epsilon parameter (default 1e-5)
-- **THEN** the computation uses `sqrt(var + eps)` in denominator
diff --git a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/conv-bn-relu-fusion/spec.md b/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/conv-bn-relu-fusion/spec.md
deleted file mode 100644
index 6eff494..0000000
--- a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/conv-bn-relu-fusion/spec.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## ADDED Requirements
-
-### Requirement: BatchNorm Folding Utility
-
-The system SHALL provide a utility function to fold BatchNorm parameters into Conv2d weights for optimized inference.
-
-#### Scenario: Fold BN into Conv2d
-- **WHEN** calling foldBatchNorm with conv weight, bias, and BN parameters
-- **THEN** returns new weight and bias that combine Conv + BN operations
-
-#### Scenario: Folding formula correctness
-- **WHEN** folding BN with gamma, beta, mean, var, eps
-- **THEN** new_weight = weight * gamma / sqrt(var + eps)
-- **AND** new_bias = (old_bias - mean) / sqrt(var + eps) * gamma + beta
-
-#### Scenario: Conv2dBiasReLU equivalence after folding
-- **WHEN** folding BN into Conv and executing Conv2dBiasReLU
-- **AND** executing Conv2d followed by BatchNorm2d separately
-- **THEN** both outputs are equivalent within tolerance 1e-4
-
----
-
-### Requirement: No New Shader Required
-
-The fused Conv2d+BN+ReLU operation SHALL reuse the existing Conv2dBiasReLU shader after BN folding.
-
-#### Scenario: Memory bandwidth unchanged
-- **WHEN** using folded BN parameters with Conv2dBiasReLU
-- **THEN** memory bandwidth equals standard Conv2dBiasReLU (3x reduction vs sequential)
-
-#### Scenario: No additional GPU allocation
-- **WHEN** using folded BN approach
-- **THEN** no intermediate BatchNorm output tensor is allocated
diff --git a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/elementwise-ops/spec.md b/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/elementwise-ops/spec.md
deleted file mode 100644
index f496980..0000000
--- a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/elementwise-ops/spec.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Element-wise Add Operator
-
-The system SHALL provide an Add operator for element-wise addition of two tensors.
-
-#### Scenario: Basic addition
-- **WHEN** executing Add with two tensors of shape [1, 64, 28, 28]
-- **THEN** output shape equals input shape [1, 64, 28, 28]
-- **AND** each output element equals the sum of corresponding input elements
-
-#### Scenario: Residual connection
-- **WHEN** executing Add with input tensor and residual tensor of same shape
-- **THEN** output equals input + residual element-wise
-
-#### Scenario: Reject mismatched shapes
-- **WHEN** executing Add with tensors of different shapes [1, 64, 28, 28] and [1, 32, 28, 28]
-- **THEN** throws InvalidShapeError
-
-#### Scenario: Support any tensor dimension
-- **WHEN** executing Add with tensors of any valid shape (1D, 2D, 3D, 4D)
-- **THEN** output shape matches input shape
-
----
-
-### Requirement: Add Operator Correctness
-
-The system SHALL produce correct element-wise addition results.
-
-#### Scenario: Property-based correctness
-- **WHEN** executing Add with arbitrary tensors of matching shapes up to 1000 elements
-- **THEN** GPU output matches CPU reference implementation within tolerance 1e-5
diff --git a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/testing/spec.md b/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/testing/spec.md
deleted file mode 100644
index 5b0fc2a..0000000
--- a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/specs/testing/spec.md
+++ /dev/null
@@ -1,49 +0,0 @@
-## ADDED Requirements
-
-### Requirement: BatchNorm2d Test Coverage
-
-The system SHALL have comprehensive test coverage for BatchNorm2dOperator.
-
-#### Scenario: Unit tests for shape computation
-- **WHEN** running BatchNorm2d tests
-- **THEN** computeOutputShape returns correct shapes for various input shapes
-
-#### Scenario: Property-based tests for correctness
-- **WHEN** running property-based tests with arbitrary input tensors
-- **THEN** GPU output matches CPU reference within 1e-5 tolerance for 100+ iterations
-
-#### Scenario: Error handling tests
-- **WHEN** running tests with invalid inputs (wrong shapes, NHWC layout)
-- **THEN** appropriate errors are thrown
-
----
-
-### Requirement: AddOperator Test Coverage
-
-The system SHALL have comprehensive test coverage for AddOperator.
-
-#### Scenario: Unit tests for basic addition
-- **WHEN** running AddOperator tests
-- **THEN** correct sum is computed for various tensor shapes
-
-#### Scenario: Property-based tests for correctness
-- **WHEN** running property-based tests with arbitrary matching-shape tensor pairs
-- **THEN** GPU output matches CPU reference for 100+ iterations
-
-#### Scenario: Shape mismatch error tests
-- **WHEN** running tests with mismatched tensor shapes
-- **THEN** InvalidShapeError is thrown
-
----
-
-### Requirement: foldBatchNorm Test Coverage
-
-The system SHALL have test coverage for the foldBatchNorm utility.
-
-#### Scenario: Folding correctness test
-- **WHEN** folding BN parameters and comparing Conv2dBiasReLU output vs Conv2d+BN sequential
-- **THEN** outputs are equivalent within tolerance 1e-4
-
-#### Scenario: Edge case tests
-- **WHEN** folding with edge cases (all zeros, very small variance)
-- **THEN** no NaN or Infinity in folded weights
diff --git a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/tasks.md b/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/tasks.md
deleted file mode 100644
index dc3c9e5..0000000
--- a/openspec/changes/archive/2026-04-27-add-batchnorm-and-residual-support/tasks.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## 1. AddOperator Implementation
-
-- [ ] 1.1 Create `src/operators/AddOperator.ts` with WGSL shader for element-wise addition
-- [ ] 1.2 Implement `computeOutputShape()` to validate matching tensor shapes
-- [ ] 1.3 Implement `forward()` method with proper GPU buffer bindings
-- [ ] 1.4 Add CPU reference implementation in `src/utils/reference.ts`
-- [ ] 1.5 Create `tests/operators/AddOperator.test.ts` with unit and property-based tests
-- [ ] 1.6 Export AddOperator from `src/index.ts`
-
-## 2. BatchNorm2dOperator Implementation
-
-- [ ] 2.1 Create `src/operators/BatchNorm2dOperator.ts` with WGSL shader for inference BN
-- [ ] 2.2 Implement parameter validation (gamma, beta, mean, var shapes match input channels)
-- [ ] 2.3 Implement `forward()` with epsilon parameter (default 1e-5)
-- [ ] 2.4 Add CPU reference implementation for BatchNorm2d in `src/utils/reference.ts`
-- [ ] 2.5 Create `tests/operators/BatchNorm2dOperator.test.ts` with comprehensive tests
-- [ ] 2.6 Export BatchNorm2dOperator from `src/index.ts`
-
-## 3. BatchNorm Folding Utility
-
-- [ ] 3.1 Create `src/utils/bnFolding.ts` with `foldBatchNorm()` function
-- [ ] 3.2 Implement folding formula: new_weight = weight * gamma / sqrt(var + eps)
-- [ ] 3.3 Implement bias folding: new_bias = (bias - mean) / sqrt(var + eps) * gamma + beta
-- [ ] 3.4 Create `tests/utils/bnFolding.test.ts` with correctness and edge case tests
-- [ ] 3.5 Export foldBatchNorm from `src/index.ts`
-
-## 4. Integration and Documentation
-
-- [ ] 4.1 Update `openspec/specs/api/spec.md` with new operator interfaces
-- [ ] 4.2 Update `openspec/specs/product/spec.md` implementation status table
-- [ ] 4.3 Run full test suite and verify all 134+ tests pass
-- [ ] 4.4 Run `npm run build` and verify no TypeScript errors
-- [ ] 4.5 Run `npm run typecheck` and verify strict mode compliance
-
-## 5. Verification
-
-- [ ] 5.1 Verify AddOperator property-based tests pass for 100+ iterations
-- [ ] 5.2 Verify BatchNorm2dOperator matches CPU reference within tolerance
-- [ ] 5.3 Verify foldBatchNorm produces equivalent results to sequential Conv+BN
-- [ ] 5.4 Verify no memory leaks in new operators (deferDestroy pattern)
diff --git a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/.openspec.yaml b/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/.openspec.yaml
deleted file mode 100644
index 0a064c1..0000000
--- a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-04-28
diff --git a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/design.md b/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/design.md
deleted file mode 100644
index 430f714..0000000
--- a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/design.md
+++ /dev/null
@@ -1,51 +0,0 @@
-## Context
-
-`AddOperator` and `BatchNorm2dOperator` are already implemented, tested in isolation, and exported from `src/index.ts`, but the application layer never registers them with `InferenceEngine`. As a result, model graphs that include residual additions or batch normalization fail at runtime with `Unknown operator type`, even though the underlying WGSL kernels and tensor validation logic already exist.
-
-This change is intentionally narrow: it should make the existing engine capable of dispatching the two existing operators through `ModelDefinition` without introducing new tensor types, graph rewrites, or operator fusion. The implementation must preserve the current zero-dependency architecture, reuse existing WGSL shaders unchanged, and keep memory management consistent with the engine's existing activation cleanup flow.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Register `add` and `batchnorm2d` in `InferenceEngine.initialize()`.
-- Extend end-to-end engine tests so model graphs can exercise both operators through `loadModel()` + `infer()`.
-- Update OpenSpec/API documentation so model authors know these layer types are supported by the engine, not just as low-level operators.
-
-**Non-Goals:**
-- No new WGSL kernels or operator math changes.
-- No graph optimizer, layer aliasing, or automatic Conv+BatchNorm folding.
-- No model format expansion beyond the existing `ModelDefinition` structure.
-- No changes to tensor dtype, layout conversion, or memory planner behavior.
-
-## Decisions
-
-### 1. Reuse existing operator implementations instead of adding engine-specific wrappers
-
-`InferenceEngine` will instantiate the existing `AddOperator` and `BatchNorm2dOperator` directly, just like it already does for `relu`, `softmax`, and `conv2d`. This keeps the operator registry as the single dispatch table and avoids duplicating validation or shader setup logic.
-
-**Alternatives considered**
-- **Engine-local wrapper functions:** rejected because they would duplicate validation and drift from operator tests.
-- **Alias `batchnorm` and `batchnorm2d` simultaneously:** deferred to keep the change minimal and documentation precise. The engine will register the canonical `batchnorm2d` name that matches the class/API name.
-
-### 2. Keep WGSL and GPU buffer lifecycles unchanged
-
-Both operators already compile their own WGSL shaders, allocate any transient uniform buffers internally, and rely on `GPUContext.deferDestroy()` where needed. The engine integration only changes discovery/dispatch, so no shader code or buffer lifecycle patterns should be modified.
-
-**Alternatives considered**
-- **Refactor operator initialization as part of this change:** rejected as unnecessary scope growth.
-- **Add engine-managed temporary buffers:** rejected because it would bypass the established operator ownership model.
-
-### 3. Validate integration through engine-level regression tests, not new operator math tests
-
-Operator correctness is already covered in `tests/operators/AddOperator.test.ts` and `tests/operators/BatchNorm2dOperator.test.ts`. This change will add engine-focused tests that prove the registry wiring, layer type acceptance, and weight/input resolution all work through `InferenceEngine`.
-
-**Alternatives considered**
-- **Only assert registry membership:** rejected because it would miss `ModelDefinition` wiring regressions.
-- **Recompute full numerical outputs in engine tests:** not required for this scope because the operators themselves already own the numerical correctness tests.
-
-## Risks / Trade-offs
-
-- **Layer naming mismatch (`batchnorm` vs `batchnorm2d`)** → Use `batchnorm2d` everywhere in docs/specs/tests to match the exported operator and avoid ambiguous aliases.
-- **Engine tests may silently pass without validating real GPU math** → Focus engine tests on successful dispatch, tensor resolution, and output shape; keep operator numerical coverage in the dedicated operator suites.
-- **Spec drift between operator docs and engine docs** → Update OpenSpec + API text in the same change so supported layer types are documented consistently.
-- **Performance expectations could be misunderstood as a new optimization** → Document explicitly that this is orchestration coverage only; shader execution and buffer usage remain unchanged.
diff --git a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/proposal.md b/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/proposal.md
deleted file mode 100644
index 3c91cfe..0000000
--- a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/proposal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## Why
-
-`AddOperator` and `BatchNorm2dOperator` already exist in the operator layer and are exported from the public package surface, but `InferenceEngine` does not register them. That mismatch blocks residual-style graphs and batch-normalized inference models from running end-to-end through `ModelDefinition`, even though the underlying kernels are already implemented.
-
-## What Changes
-
-- Register `add` and `batchnorm2d` operators in `InferenceEngine` so model layers can dispatch them during `infer()`.
-- Extend model-definition and engine documentation/spec coverage so graph definitions can declare `add` and `batchnorm2d` layer types.
-- Add inference-engine regression coverage for Add and BatchNorm2d execution, including operator lookup failures and weight wiring through the existing `ModelDefinition` path.
-- Update OpenSpec testing/product artifacts so the engine/operator capability matrix reflects the now-supported end-to-end behavior.
-
-## Capabilities
-
-### New Capabilities
-
-- None.
-
-### Modified Capabilities
-
-- `architecture`: InferenceEngine orchestration and operator-layer coverage now include `AddOperator` and `BatchNorm2dOperator` in runtime dispatch.
-- `api`: `ModelDefinition` / `LayerDefinition` documentation and engine usage now cover `add` and `batchnorm2d` layer types.
-- `product`: End-to-end model loading and inference requirements now explicitly include residual-add and batch-normalization execution through `InferenceEngine`.
-- `testing`: Acceptance criteria now include end-to-end inference scenarios that exercise Add and BatchNorm2d through model execution.
-
-## Impact
-
-- Affected code: `src/engine/InferenceEngine.ts`, model/inference tests, and any fixtures that build `ModelDefinition` layer graphs.
-- Affected specs: `openspec/specs/{architecture,api,product,testing}/spec.md`
-- Public behavior: models loaded through `InferenceEngine` can use `add` and `batchnorm2d` layer types without custom orchestration.
diff --git a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/api/spec.md b/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/api/spec.md
deleted file mode 100644
index b408085..0000000
--- a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/api/spec.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## ADDED Requirements
-
-### Requirement: InferenceEngine layer type coverage
-
-The system SHALL document the `InferenceEngine` layer types that can be dispatched through `ModelDefinition`.
-
-#### Scenario: Residual addition layer is documented
-- **WHEN** developers read the model definition format
-- **THEN** the documented layer type list includes `add`
-
-#### Scenario: Batch normalization layer is documented
-- **WHEN** developers read the model definition format
-- **THEN** the documented layer type list includes `batchnorm2d`
-
-### Requirement: InferenceEngine operator usage examples
-
-The system SHALL document end-to-end engine usage for low-level operators that are supported through model execution.
-
-#### Scenario: Add and BatchNorm2d engine support is described
-- **WHEN** developers read the engine-facing API documentation
-- **THEN** they can determine that `AddOperator` and `BatchNorm2dOperator` are available through `InferenceEngine` model layers
diff --git a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/architecture/spec.md b/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/architecture/spec.md
deleted file mode 100644
index 2433c0d..0000000
--- a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/architecture/spec.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Layered Architecture
-
-The system SHALL implement a four-layer architecture for separation of concerns.
-
-#### Scenario: Device Layer provides GPU access
-- **WHEN** application needs GPU access
-- **THEN** Device Layer provides GPUAdapter and GPUDevice through GPUContext
-
-#### Scenario: Core Layer provides abstractions
-- **WHEN** operators need GPU resources
-- **THEN** Core Layer provides Tensor, ShaderManager, and GPUContext classes
-
-#### Scenario: Operator Layer provides neural network ops
-- **WHEN** inference engine needs operators
-- **THEN** Operator Layer provides Conv2d, MaxPool, ReLU, Softmax, Dense, Flatten, Add, and BatchNorm2d
-
-#### Scenario: Application Layer provides high-level APIs
-- **WHEN** users run inference
-- **THEN** Application Layer provides InferenceEngine and ModelLoader
-
-### Requirement: InferenceEngine Orchestration
-
-The system SHALL provide high-level inference orchestration.
-
-#### Scenario: Operator registry
-- **WHEN** model is loaded
-- **THEN** operators are mapped by type name for dynamic dispatch
-- **AND** the registry includes `add` and `batchnorm2d` alongside the existing core operators
-
-#### Scenario: Intermediate cleanup
-- **WHEN** inference completes
-- **THEN** intermediate tensors are destroyed to free GPU memory
-
-#### Scenario: Context sync before cleanup
-- **WHEN** cleaning up intermediate tensors
-- **THEN** GPU is synced to ensure all work is complete
diff --git a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/product/spec.md b/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/product/spec.md
deleted file mode 100644
index fd32ade..0000000
--- a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/product/spec.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Model Loading and Inference
-
-The system SHALL provide model loading and end-to-end inference.
-
-#### Scenario: Load model from JSON
-- **WHEN** loading model definition with layers and weights
-- **THEN** weights are allocated as GPU tensors
-
-#### Scenario: Run inference
-- **WHEN** calling infer() with input tensor
-- **THEN** output tensor is returned with correct shape
-
-#### Scenario: Residual addition through engine
-- **WHEN** a loaded model contains an `add` layer whose inputs resolve to existing activations
-- **THEN** `InferenceEngine` executes the addition and stores the result as the named layer output
-
-#### Scenario: Batch normalization through engine
-- **WHEN** a loaded model contains a `batchnorm2d` layer whose inputs include activation, gamma, beta, mean, and variance tensors
-- **THEN** `InferenceEngine` executes batch normalization and returns the normalized tensor as the named layer output
-
-#### Scenario: MNIST end-to-end
-- **WHEN** running MNIST model inference on 28x28 input
-- **THEN** output has 10 classes summing to ~1.0
diff --git a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/testing/spec.md b/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/testing/spec.md
deleted file mode 100644
index 38231cc..0000000
--- a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/specs/testing/spec.md
+++ /dev/null
@@ -1,15 +0,0 @@
-## ADDED Requirements
-
-### Requirement: InferenceEngine residual and normalization regression coverage
-
-The test suite SHALL verify that `InferenceEngine` can dispatch residual addition and batch normalization layers through `ModelDefinition`.
-
-#### Scenario: Add layer inference regression
-- **WHEN** a regression test loads a model containing an `add` layer
-- **THEN** inference succeeds without raising `Unknown operator type`
-- **AND** the returned tensor shape matches the add input shape
-
-#### Scenario: BatchNorm2d layer inference regression
-- **WHEN** a regression test loads a model containing a `batchnorm2d` layer with valid parameter tensors
-- **THEN** inference succeeds without raising `Unknown operator type`
-- **AND** the returned tensor shape matches the input activation shape
diff --git a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/tasks.md b/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/tasks.md
deleted file mode 100644
index 9923dce..0000000
--- a/openspec/changes/archive/2026-04-28-integrate-engine-add-batchnorm/tasks.md
+++ /dev/null
@@ -1,14 +0,0 @@
-## 1. Engine Dispatch Wiring
-
-- [x] 1.1 Register `add` and `batchnorm2d` in `InferenceEngine.initialize()` so model layers can dispatch them through the existing operator registry. [architecture:Layered Architecture, architecture:InferenceEngine Orchestration, product:Model Loading and Inference]
-- [x] 1.2 Update API-facing documentation/comments for `InferenceEngine` model layer coverage so `add` and `batchnorm2d` are part of the documented model definition surface. [api:InferenceEngine layer type coverage, api:InferenceEngine operator usage examples]
-
-## 2. Regression Coverage
-
-- [x] 2.1 Add failing engine-level tests that exercise `add` and `batchnorm2d` through `loadModel()` + `infer()`, including valid weight/input resolution. [testing:InferenceEngine residual and normalization regression coverage, product:Model Loading and Inference]
-- [x] 2.2 Make the new engine tests pass without changing existing operator math or memory-management semantics. [architecture:InferenceEngine Orchestration, testing:InferenceEngine residual and normalization regression coverage]
-
-## 3. Verification
-
-- [x] 3.1 Run targeted and full repository validation covering the updated engine path and ensure no existing operator regressions. [testing:InferenceEngine residual and normalization regression coverage]
-- [x] 3.2 Mark the change tasks complete once specs, code, and validation align. [architecture:InferenceEngine Orchestration, api:InferenceEngine layer type coverage, product:Model Loading and Inference, testing:InferenceEngine residual and normalization regression coverage]
diff --git a/openspec/config.yaml b/openspec/config.yaml
deleted file mode 100644
index d2ac366..0000000
--- a/openspec/config.yaml
+++ /dev/null
@@ -1,42 +0,0 @@
-# OpenSpec Configuration
-# Tiny-DL-Inference: WebGPU-based deep learning inference engine
-
-schema: spec-driven
-
-context: |
-  Tiny-DL-Inference is a zero-dependency, high-performance deep learning inference engine built on WebGPU.
-
-  Technology Stack:
-  - Language: TypeScript 5.x with ESM modules
-  - GPU API: WebGPU
-  - Shader Language: WGSL
-  - Test Runner: Vitest
-  - Property Tests: fast-check
-
-  Key Features:
-  - Zero runtime dependencies (~50KB bundle)
-  - Direct GPU compute shader control
-  - Manual kernel fusion optimization
-  - NCHW/NHWC memory layout support
-
-  Bundle Size: ~50KB (vs 2MB+ for TensorFlow.js/ONNX Runtime)
-
-rules:
-  proposal:
-    - "All proposals MUST reference existing capabilities or define new ones"
-    - "Changes to operators MUST update corresponding test specs in testing/"
-    - "New operators MUST include performance benchmark consideration"
-
-  specs:
-    - "Requirements MUST use RFC 2119 keywords (SHALL, SHOULD, MAY)"
-    - "Each requirement MUST have at least one scenario"
-    - "Scenarios MUST use WHEN/THEN format"
-
-  design:
-    - "Design MUST include WGSL shader considerations for GPU operators"
-    - "Memory management patterns MUST be documented"
-    - "Performance impact MUST be analyzed"
-
-  tasks:
-    - "Each task MUST link to requirement IDs"
-    - "Tasks MUST be verifiable (testable or observable)"
diff --git a/openspec/specs/api/spec.md b/openspec/specs/api/spec.md
deleted file mode 100644
index 24e6f5a..0000000
--- a/openspec/specs/api/spec.md
+++ /dev/null
@@ -1,801 +0,0 @@
-# API Specification
-
-**Version:** 2.0.1
-**Last Updated:** 2026-04-17
-
----
-
-## Overview
-
-This specification defines the public API for Tiny-DL-Inference. All interfaces are designed for TypeScript with strict type checking.
-
----
-
-## Core Types
-
-### TensorShape
-
-```typescript
-type TensorShape = number[];
-```
-
-A tensor shape is an array of dimension sizes. Examples:
-- `[batch, channels, height, width]` for 4D NCHW tensors
-- `[batch, height, width, channels]` for 4D NHWC tensors
-- `[batch, features]` for 2D tensors
-
-### DataLayout
-
-```typescript
-type DataLayout = 'NCHW' | 'NHWC';
-```
-
-Memory layout for 4D tensors:
-- `NCHW`: [Batch, Channel, Height, Width] - PyTorch default
-- `NHWC`: [Batch, Height, Width, Channel] - TensorFlow default
-
-### OperatorParams
-
-```typescript
-interface OperatorParams {
-  [key: string]: number | number[] | boolean | string | undefined;
-}
-```
-
-Base interface for operator parameters. Specific operators extend this with their required parameters.
-
----
-
-## GPUContext
-
-WebGPU device and resource management.
-
-### Constructor
-
-```typescript
-constructor()
-```
-
-Creates a new GPUContext instance. Does not initialize the GPU device.
-
-### Methods
-
-#### initialize
-
-```typescript
-async initialize(config?: GPUContextConfig): Promise<void>
-```
-
-Initialize WebGPU adapter and device.
-
-**Parameters:**
-- `config` (optional): Configuration options
-
-**Throws:**
-- `WebGPUNotSupportedError`: If WebGPU is not available in the browser
-- `DeviceInitializationError`: If GPU device initialization fails
-
-**Example:**
-```typescript
-const context = new GPUContext();
-await context.initialize({ powerPreference: 'high-performance' });
-```
-
-#### getDevice
-
-```typescript
-getDevice(): GPUDevice
-```
-
-Get the WebGPU device. Must call `initialize()` first.
-
-**Throws:**
-- `Error`: If context is not initialized
-
-#### createBuffer
-
-```typescript
-createBuffer(descriptor: GPUBufferDescriptor): GPUBuffer
-```
-
-Create a GPU buffer.
-
-#### createShaderModule
-
-```typescript
-createShaderModule(code: string, label?: string): GPUShaderModule
-```
-
-Create a shader module from WGSL code.
-
-#### createCommandEncoder
-
-```typescript
-createCommandEncoder(descriptor?: GPUCommandEncoderDescriptor): GPUCommandEncoder
-```
-
-Create a command encoder for recording GPU commands.
-
-#### submit
-
-```typescript
-submit(commandBuffers: GPUCommandBuffer[]): void
-```
-
-Submit command buffers to the GPU queue.
-
-#### writeBuffer
-
-```typescript
-writeBuffer(buffer: GPUBuffer, data: ArrayBuffer | ArrayBufferView, bufferOffset?: number): void
-```
-
-Write data to a GPU buffer.
-
-#### deferDestroy
-
-```typescript
-deferDestroy(buffer: GPUBuffer | null | undefined): void
-```
-
-Queue a buffer for destruction after GPU work completes. Safe async cleanup pattern.
-
-#### sync
-
-```typescript
-async sync(): Promise<void>
-```
-
-Wait for all submitted GPU work to complete and flush deferred destructions.
-
-#### destroy
-
-```typescript
-destroy(): void
-```
-
-Release all GPU resources. After calling this, the context cannot be reused.
-
-### Properties
-
-#### isInitialized
-
-```typescript
-readonly isInitialized: boolean
-```
-
-Whether the context has been initialized.
-
----
-
-## Tensor
-
-GPU buffer management with shape and layout metadata.
-
-### Constructor
-
-```typescript
-constructor(context: GPUContext, shape: TensorShape, options?: TensorOptions)
-```
-
-Create a new tensor with uninitialized data.
-
-**Parameters:**
-- `context`: GPU context
-- `shape`: Tensor dimensions
-- `options` (optional): Configuration options
-
-### Static Methods
-
-#### zeros
-
-```typescript
-static zeros(context: GPUContext, shape: TensorShape, options?: TensorOptions): Tensor
-```
-
-Create a tensor filled with zeros.
-
-#### fromArray
-
-```typescript
-static fromArray(
-  context: GPUContext,
-  data: number[] | Float32Array,
-  shape: TensorShape,
-  options?: TensorOptions
-): Tensor
-```
-
-Create a tensor from an array of numbers.
-
-### Methods
-
-#### upload
-
-```typescript
-async upload(data: Float32Array): Promise<void>
-```
-
-Upload data to the GPU buffer.
-
-**Parameters:**
-- `data`: Data to upload (must match tensor size)
-
-#### download
-
-```typescript
-async download(): Promise<Float32Array>
-```
-
-Download data from the GPU buffer.
-
-**Returns:** Float32Array containing tensor data
-
-#### reshape
-
-```typescript
-reshape(newShape: TensorShape): Tensor
-```
-
-Create a view with a new shape. Zero-copy operation.
-
-**Parameters:**
-- `newShape`: New dimensions (total elements must match)
-
-**Returns:** New tensor view sharing the same GPU buffer
-
-#### destroy
-
-```typescript
-destroy(): void
-```
-
-Release GPU buffer. No-op for view tensors.
-
-#### usesContext
-
-```typescript
-usesContext(context: GPUContext): boolean
-```
-
-Check if this tensor was created with the given context.
-
-### Properties
-
-#### shape
-
-```typescript
-readonly shape: TensorShape
-```
-
-Tensor dimensions.
-
-#### layout
-
-```typescript
-readonly layout: DataLayout
-```
-
-Memory layout (NCHW or NHWC).
-
-#### buffer
-
-```typescript
-readonly buffer: GPUBuffer
-```
-
-Underlying GPU buffer.
-
-#### size
-
-```typescript
-readonly size: number
-```
-
-Total number of elements.
-
----
-
-## Operator (Abstract)
-
-Base class for all neural network operators.
-
-### Constructor
-
-```typescript
-constructor(context: GPUContext)
-```
-
-### Abstract Methods
-
-#### computeOutputShape
-
-```typescript
-abstract computeOutputShape(inputShape: TensorShape, params?: OperatorParams): TensorShape
-```
-
-Compute output shape without executing the operator.
-
-#### forward
-
-```typescript
-abstract forward(inputs: Tensor[], params?: OperatorParams): Promise<Tensor>
-```
-
-Execute the operator.
-
-**Parameters:**
-- `inputs`: Input tensors
-- `params` (optional): Operator parameters
-
-**Returns:** Output tensor
-
-### Methods
-
-#### destroy
-
-```typescript
-destroy(): void
-```
-
-Release GPU resources (pipelines, shader modules).
-
----
-
-## Conv2dOperator
-
-2D convolution operator.
-
-### Parameters
-
-```typescript
-interface Conv2dParams extends OperatorParams {
-  kernelSize: [number, number];  // [kernelHeight, kernelWidth]
-  stride: [number, number];      // [strideHeight, strideWidth]
-  padding: [number, number];     // [paddingHeight, paddingWidth]
-  useBias?: boolean;
-}
-```
-
-### Usage
-
-```typescript
-const conv2d = new Conv2dOperator(context);
-const output = await conv2d.forward([input, weight, bias], {
-  kernelSize: [3, 3],
-  stride: [1, 1],
-  padding: [1, 1]
-});
-```
-
-### Input Requirements
-
-| Input | Shape | Description |
-|-------|-------|-------------|
-| input | [N, C, H, W] | Input feature map (NCHW only) |
-| weight | [K, C, kH, kW] | Convolution kernels |
-| bias (optional) | [K] | Bias vector |
-
-### Output
-
-| Output | Shape | Description |
-|--------|-------|-------------|
-| output | [N, K, outH, outW] | Convolved feature map |
-
----
-
-## MaxPoolOperator
-
-2D max pooling operator.
-
-### Parameters
-
-```typescript
-interface MaxPoolParams extends OperatorParams {
-  poolSize: [number, number];  // [poolHeight, poolWidth]
-  stride: [number, number];    // [strideHeight, strideWidth]
-}
-```
-
-### Usage
-
-```typescript
-const maxpool = new MaxPoolOperator(context);
-const output = await maxpool.forward([input], {
-  poolSize: [2, 2],
-  stride: [2, 2]
-});
-```
-
-### Input Requirements
-
-| Input | Shape | Description |
-|-------|-------|-------------|
-| input | [N, C, H, W] | Input feature map (NCHW only) |
-
-### Output
-
-| Output | Shape | Description |
-|--------|-------|-------------|
-| output | [N, C, outH, outW] | Pooled feature map |
-
----
-
-## ReLUOperator
-
-ReLU activation function.
-
-### Usage
-
-```typescript
-const relu = new ReLUOperator(context);
-const output = await relu.forward([input]);
-```
-
-### Input Requirements
-
-Any shape tensor.
-
-### Output
-
-Same shape as input with ReLU applied: `output[i] = max(0, input[i])`
-
----
-
-## SoftmaxOperator
-
-Softmax activation function.
-
-### Parameters
-
-```typescript
-interface SoftmaxParams extends OperatorParams {
-  axis?: number;  // Default: -1 (last axis)
-}
-```
-
-### Usage
-
-```typescript
-const softmax = new SoftmaxOperator(context);
-const output = await softmax.forward([input], { axis: -1 });
-```
-
-### Current Limitations
-
-Only supports softmax along the last axis (`axis: -1`).
-
-### Output
-
-Same shape as input. Values in [0, 1] and sum to 1 along the specified axis.
-
----
-
-## DenseOperator
-
-Fully connected (dense) layer.
-
-### Parameters
-
-```typescript
-interface DenseParams extends OperatorParams {
-  units: number;
-  useBias?: boolean;  // Default: true
-}
-```
-
-### Usage
-
-```typescript
-const dense = new DenseOperator(context);
-const output = await dense.forward([input, weight, bias], { units: 128 });
-```
-
-### Input Requirements
-
-| Input | Shape | Description |
-|-------|-------|-------------|
-| input | [N, inputSize] | Input features |
-| weight | [units, inputSize] | Weight matrix |
-| bias (optional) | [units] | Bias vector |
-
-### Output
-
-| Output | Shape | Description |
-|--------|-------|-------------|
-| output | [N, units] | Dense output |
-
----
-
-## FlattenOperator
-
-Flatten tensor to 2D.
-
-### Usage
-
-```typescript
-const flatten = new FlattenOperator(context);
-const output = await flatten.forward([input]);
-// [N, C, H, W] -> [N, C*H*W]
-```
-
-### Output
-
-2D tensor with shape `[batchSize, product of remaining dimensions]`.
-
-**Note:** Zero-copy operation (creates a view).
-
----
-
-## Conv2dBiasReLUOperator
-
-Fused Conv2d + Bias + ReLU operator.
-
-### Parameters
-
-Same as `Conv2dParams` (bias is required).
-
-### Usage
-
-```typescript
-const fused = new Conv2dBiasReLUOperator(context);
-const output = await fused.forward([input, weight, bias], {
-  kernelSize: [3, 3],
-  stride: [1, 1],
-  padding: [1, 1]
-});
-```
-
-### Performance
-
-3x memory bandwidth reduction compared to sequential execution.
-
----
-
-## AddOperator
-
-Element-wise addition operator for residual connections.
-
-### Usage
-
-```typescript
-const add = new AddOperator(context);
-const output = await add.forward([inputA, inputB]);
-```
-
-### Input Requirements
-
-| Input | Shape | Description |
-|-------|-------|-------------|
-| inputA | any | First input tensor |
-| inputB | any | Second input tensor (must match inputA shape and layout exactly) |
-
-### Output
-
-Same shape as inputs with element-wise sum: `output[i] = inputA[i] + inputB[i]`
-
-### Use Case
-
-Used for residual/skip connections in ResNet-style architectures:
-```typescript
-const residual = input;
-const output = await add.forward([convOutput, residual]);
-```
-
----
-
-## BatchNorm2dOperator
-
-Batch normalization for inference (using pre-computed statistics).
-
-### Parameters
-
-```typescript
-interface BatchNorm2dParams extends OperatorParams {
-  epsilon?: number;  // Default: 1e-5
-}
-```
-
-### Usage
-
-```typescript
-const bn = new BatchNorm2dOperator(context);
-const output = await bn.forward([input, gamma, beta, mean, variance], { epsilon: 1e-5 });
-```
-
-### Input Requirements
-
-| Input | Shape | Description |
-|-------|-------|-------------|
-| input | [N, C, H, W] | Input feature map (NCHW only) |
-| gamma | [C] | Scale parameter |
-| beta | [C] | Shift parameter |
-| mean | [C] | Running mean |
-| variance | [C] | Running variance |
-
-### Output
-
-Same shape as input. Formula: `y = gamma * (x - mean) / sqrt(var + eps) + beta`
-
-### Notes
-
-- Inference mode only (no gradient computation)
-- Pre-computed statistics from training are required
-- Can be folded into Conv2d weights for optimization
-
----
-
-## InferenceEngine
-
-High-level inference orchestration.
-
-### Constructor
-
-```typescript
-constructor()
-```
-
-### Methods
-
-#### initialize
-
-```typescript
-async initialize(): Promise<void>
-```
-
-Initialize the inference engine and GPU context.
-
-**Registered Operators:**
-| Type | Operator Class |
-|------|---------------|
-| `relu` | ReLUOperator |
-| `softmax` | SoftmaxOperator |
-| `maxpool` | MaxPoolOperator |
-| `conv2d` | Conv2dOperator |
-| `conv2d_bias_relu` | Conv2dBiasReLUOperator |
-| `flatten` | FlattenOperator |
-| `dense` | DenseOperator |
-| `add` | AddOperator |
-| `batchnorm2d` | BatchNorm2dOperator |
-
-#### loadModel
-
-```typescript
-async loadModel(modelDef: ModelDefinition): Promise<void>
-```
-
-Load a model definition.
-
-**Parameters:**
-- `modelDef`: Model definition with layers and weights
-
-**Throws:**
-- `Error`: If the model has no layers
-- `Error`: If a layer type is unknown
-- `Error`: If a layer input cannot be resolved from `input`, prior layers, or weights
-- `Error`: If layer names are duplicated
-
-#### tensorFromArray
-
-```typescript
-tensorFromArray(data: number[] | Float32Array, shape: TensorShape, options?: TensorOptions): Tensor
-```
-
-Create an input tensor from data.
-
-#### infer
-
-```typescript
-async infer(input: Tensor): Promise<Tensor>
-```
-
-Run inference on the loaded model.
-
-**Parameters:**
-- `input`: Input tensor (must be from same context)
-
-**Returns:** Output tensor
-
-**Throws:**
-- `Error`: If model not loaded
-- `Error`: If input is from different GPU context
-
-#### destroy
-
-```typescript
-destroy(): void
-```
-
-Release all resources.
-
----
-
-## ModelLoader
-
-Load models from JSON.
-
-### Methods
-
-#### loadFromJSON
-
-```typescript
-async loadFromJSON(url: string): Promise<ModelDefinition>
-```
-
-Load model definition from JSON URL.
-
-#### loadWeights
-
-```typescript
-async loadWeights(url: string): Promise<Record<string, WeightTensor>>
-```
-
-Load weights from binary format.
-
----
-
-## Model Definition Format
-
-```typescript
-interface ModelDefinition {
-  name: string;
-  layers: LayerDefinition[];
-  weights: Record<string, WeightTensor>;
-}
-
-interface LayerDefinition {
-  name: string;
-  type: string;  // 'conv2d', 'maxpool', 'relu', 'softmax', 'dense', 'flatten'
-  inputs: string[];
-  params?: OperatorParams;
-}
-
-interface WeightTensor {
-  data: Float32Array | number[];
-  shape: number[];  // Required: explicit shape metadata
-}
-```
-
----
-
-## Error Classes
-
-### WebGPUNotSupportedError
-
-```typescript
-class WebGPUNotSupportedError extends Error {
-  constructor(message?: string);
-}
-```
-
-Thrown when WebGPU is not available in the browser.
-
-### DeviceInitializationError
-
-```typescript
-class DeviceInitializationError extends Error {
-  constructor(message?: string);
-}
-```
-
-Thrown when GPU device initialization fails.
-
-### InvalidShapeError
-
-```typescript
-class InvalidShapeError extends Error {
-  constructor(message?: string);
-}
-```
-
-Thrown when tensor shapes are incompatible.
-
-### BufferSizeError
-
-```typescript
-class BufferSizeError extends Error {
-  constructor(message?: string);
-}
-```
-
-Thrown when buffer sizes don't match expected dimensions.
diff --git a/openspec/specs/architecture/spec.md b/openspec/specs/architecture/spec.md
deleted file mode 100644
index 78d966e..0000000
--- a/openspec/specs/architecture/spec.md
+++ /dev/null
@@ -1,218 +0,0 @@
-# Architecture Specification
-
-**Status:** Final
-**Type:** Architecture
-**Created:** 2025-02-13
-**Last Updated:** 2026-04-17
-
----
-
-## Overview
-
-This specification defines the core architecture of Tiny-DL-Inference, a WebGPU-based deep learning inference engine implemented from scratch without framework dependencies.
-
----
-
-## Requirements
-
-### Requirement: Layered Architecture
-
-The system SHALL implement a four-layer architecture for separation of concerns.
-
-#### Scenario: Device Layer provides GPU access
-- **WHEN** application needs GPU access
-- **THEN** Device Layer provides GPUAdapter and GPUDevice through GPUContext
-
-#### Scenario: Core Layer provides abstractions
-- **WHEN** operators need GPU resources
-- **THEN** Core Layer provides Tensor, ShaderManager, and GPUContext classes
-
-#### Scenario: Operator Layer implements neural network ops
-- **WHEN** inference engine needs operators
-- **THEN** Operator Layer provides Conv2d, MaxPool, ReLU, Softmax, Dense, Flatten
-
-#### Scenario: Application Layer provides high-level APIs
-- **WHEN** users run inference
-- **THEN** Application Layer provides InferenceEngine and ModelLoader
-
----
-
-### Requirement: GPUContext Device Management
-
-The system SHALL provide centralized WebGPU device management.
-
-#### Scenario: Async initialization
-- **WHEN** GPUContext.initialize() is called
-- **THEN** adapter and device are requested asynchronously
-
-#### Scenario: Deferred resource destruction
-- **WHEN** GPU buffer is no longer needed during operation
-- **THEN** deferDestroy() queues destruction until GPU work completes
-
-#### Scenario: Sync primitive
-- **WHEN** context.sync() is called
-- **THEN** waits for submitted work and flushes deferred destructions
-
----
-
-### Requirement: Tensor Buffer Management
-
-The system SHALL provide GPU buffer management with shape and layout metadata.
-
-#### Scenario: View pattern for reshape
-- **WHEN** tensor.reshape() is called
-- **THEN** returned tensor shares the same GPU buffer (zero-copy)
-
-#### Scenario: Layout tracking
-- **WHEN** tensor is created or converted
-- **THEN** layout metadata (NCHW/NHWC) is tracked
-
-#### Scenario: Data upload and download
-- **WHEN** tensor.upload() and tensor.download() are called
-- **THEN** data roundtrip preserves values
-
----
-
-### Requirement: Operator Base Class Pattern
-
-The system SHALL provide an abstract Operator base class for all neural network operators.
-
-#### Scenario: Lazy pipeline initialization
-- **WHEN** operator is constructed
-- **THEN** pipeline is NOT created until first forward() call
-
-#### Scenario: Shader embedding
-- **WHEN** compileShader() is called
-- **THEN** WGSL code is returned as embedded template string
-
-#### Scenario: Parameter buffers
-- **WHEN** forward() is called with dynamic shapes
-- **THEN** parameter buffers are created per-invocation and destroyed via deferDestroy()
-
----
-
-### Requirement: InferenceEngine Orchestration
-
-The system SHALL provide high-level inference orchestration.
-
-#### Scenario: Operator registry
-- **WHEN** model is loaded
-- **THEN** operators are mapped by type name for dynamic dispatch
-
-#### Scenario: Model graph compilation
-- **WHEN** model is loaded
-- **THEN** layer names, operator types, and tensor references are validated before inference begins
-
-#### Scenario: Intermediate cleanup
-- **WHEN** inference completes
-- **THEN** intermediate tensors are destroyed to free GPU memory
-
-#### Scenario: Context sync before cleanup
-- **WHEN** cleaning up intermediate tensors
-- **THEN** GPU is synced to ensure all work is complete
-
----
-
-### Requirement: Memory Management Strategy
-
-The system SHALL implement proper GPU memory lifecycle management.
-
-#### Scenario: Buffer creation to destruction
-- **WHEN** buffer is created via GPUContext
-- **THEN** it follows Create → Use → Destroy lifecycle
-
-#### Scenario: View ownership
-- **WHEN** view tensor (from reshape) is destroyed
-- **THEN** underlying buffer is NOT destroyed (no-op)
-
-#### Scenario: Original ownership
-- **WHEN** original tensor is destroyed
-- **THEN** underlying GPU buffer IS destroyed
-
----
-
-### Requirement: Error Handling Hierarchy
-
-The system SHALL provide custom error classes for different failure modes.
-
-#### Scenario: WebGPU not supported
-- **WHEN** browser lacks WebGPU
-- **THEN** WebGPUNotSupportedError is thrown
-
-#### Scenario: Device initialization failure
-- **WHEN** GPU init fails
-- **THEN** DeviceInitializationError is thrown
-
-#### Scenario: Shape mismatch
-- **WHEN** tensor shapes are incompatible
-- **THEN** InvalidShapeError is thrown
-
-#### Scenario: Buffer size mismatch
-- **WHEN** buffer/data sizes don't match
-- **THEN** BufferSizeError is thrown
-
----
-
-## Architecture Overview
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│                        Application Layer                         │
-│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐  │
-│  │ Model Loader│  │  Benchmark  │  │    Inference Runner     │  │
-│  └─────────────┘  └─────────────┘  └─────────────────────────┘  │
-├─────────────────────────────────────────────────────────────────┤
-│                        Operator Layer                            │
-│  ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌───────────────┐  │
-│  │ Conv2d │ │MaxPool │ │  ReLU  │ │Softmax │ │Conv2d+Bias+ReLU│ │
-│  └────────┘ └────────┘ └────────┘ └────────┘ └───────────────┘  │
-├─────────────────────────────────────────────────────────────────┤
-│                        Core Layer                                │
-│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐  │
-│  │     Tensor      │  │  ShaderManager  │  │   GPUContext    │  │
-│  └─────────────────┘  └─────────────────┘  └─────────────────┘  │
-├─────────────────────────────────────────────────────────────────┤
-│                        Device Layer                              │
-│  ┌─────────────────────────────────────────────────────────────┐│
-│  │                    WebGPU Adapter/Device                     ││
-│  └─────────────────────────────────────────────────────────────┘│
-└─────────────────────────────────────────────────────────────────┘
-```
-
----
-
-## Data Flow
-
-```
-Input Tensor (CPU memory)
-    ↓ upload()
-Input Tensor (GPU buffer)
-    ↓ operator.forward()
-Command Encoder
-    ↓ encode compute pass
-Command Buffer
-    ↓ submit()
-GPU Queue
-    ↓ execute shader
-Output Tensor (GPU buffer)
-    ↓ download()
-Output Array (CPU memory)
-```
-
----
-
-## Key Design Decisions
-
-1. **Full Control**: Direct access to compute shaders enables custom optimizations
-2. **Small Bundle**: ~50KB vs 2MB+ for framework alternatives
-3. **Learning Value**: Clear demonstration of GPU compute patterns
-4. **No Dependencies**: Eliminates supply chain risks and version conflicts
-
----
-
-## Known Limitations
-
-- **Limited Operator Set**: Must manually implement each operator
-- **Browser Only**: WebGPU not available in Node.js without polyfills
-- **No Auto-Optimization**: Fusion and layout choices are manual
-- **WGSL Lock-in**: Shaders written in WebGPU's language, not portable to CUDA/Metal
diff --git a/openspec/specs/kernel-fusion/spec.md b/openspec/specs/kernel-fusion/spec.md
deleted file mode 100644
index e3ca01e..0000000
--- a/openspec/specs/kernel-fusion/spec.md
+++ /dev/null
@@ -1,156 +0,0 @@
-# Kernel Fusion Specification
-
-**Status:** Final
-**Type:** Optimization
-**Created:** 2025-03-01
-**Last Updated:** 2026-04-17
-
----
-
-## Overview
-
-This specification defines the kernel fusion optimization technique for reducing memory bandwidth in sequential neural network operations.
-
----
-
-## Requirements
-
-### Requirement: Conv2dBiasReLU Fused Operator
-
-The system SHALL provide a fused operator combining Conv2d, Bias addition, and ReLU activation in a single shader.
-
-#### Scenario: Basic fused execution
-- **WHEN** executing Conv2dBiasReLU with input, weight, and bias tensors
-- **THEN** output equals sequential Conv2d + Bias + ReLU execution
-
-#### Scenario: Single shader dispatch
-- **WHEN** executing fused operator
-- **THEN** only one compute shader is dispatched
-
-#### Scenario: Reject missing bias
-- **WHEN** executing Conv2dBiasReLU without bias tensor
-- **THEN** throws error "input, weight, and bias tensors required"
-
----
-
-### Requirement: Memory Bandwidth Reduction
-
-The system SHALL achieve significant memory bandwidth reduction through fusion.
-
-#### Scenario: Reduced memory reads
-- **WHEN** comparing fused vs sequential execution
-- **THEN** fused requires 2 reads vs 4 reads for sequential
-
-#### Scenario: Reduced memory writes
-- **WHEN** comparing fused vs sequential execution
-- **THEN** fused requires 1 write vs 2 writes for sequential
-
-#### Scenario: Overall bandwidth reduction
-- **WHEN** measuring memory traffic
-- **THEN** fused achieves 3x reduction compared to sequential
-
----
-
-### Requirement: Equivalence Guarantee
-
-The fused operator MUST produce identical results to sequential execution.
-
-#### Scenario: Numerical equivalence
-- **WHEN** comparing fused output to sequential output
-- **THEN** values match within floating point tolerance
-
-#### Scenario: Property-based verification
-- **WHEN** running property tests with arbitrary inputs
-- **THEN** fused output always equals sequential output
-
----
-
-### Requirement: Performance Improvement
-
-The system SHALL provide measurable performance improvement with fused operators.
-
-#### Scenario: Reduced latency
-- **WHEN** benchmarking Conv2d 3x3, 64 channels, 56x56 input
-- **THEN** fused achieves ~2.6x speedup over sequential
-
-#### Scenario: Reduced memory allocation
-- **WHEN** measuring GPU memory allocation
-- **THEN** fused uses 1 output tensor vs 3 for sequential (66% reduction)
-
-#### Scenario: Fewer kernel launches
-- **WHEN** counting GPU kernel launches
-- **THEN** fused uses 1 launch vs 3 for sequential
-
----
-
-## Technical Design
-
-### Without Fusion Memory Traffic
-
-```
-Conv2d:
-  Read: input (N×C×H×W × 4 bytes)
-  Read: weight (K×C×kH×kW × 4 bytes)
-  Write: temp (N×K×outH×outW × 4 bytes)
-
-Bias Add:
-  Read: temp (N×K×outH×outW × 4 bytes)
-  Read: bias (K × 4 bytes)
-  Write: temp2 (N×K×outH×outW × 4 bytes)
-
-ReLU:
-  Read: temp2 (N×K×outH×outW × 4 bytes)
-  Write: output (N×K×outH×outW × 4 bytes)
-
-Total Memory Traffic: 6 × tensor_size + overhead
-```
-
-### With Fusion Memory Traffic
-
-```
-Conv2d+Bias+ReLU:
-  Read: input, weight, bias
-  Write: output
-
-Total Memory Traffic: 2 × tensor_size + overhead
-```
-
----
-
-## Trade-offs
-
-### Advantages
-
-1. **Memory Efficiency**: 66% reduction in intermediate memory
-2. **Bandwidth Efficiency**: 3x less memory traffic
-3. **Latency Reduction**: Fewer kernel launches
-
-### Disadvantages
-
-1. **Code Duplication**: Fused shaders duplicate logic from individual operators
-2. **Flexibility**: Fixed operation order, cannot swap bias and ReLU
-3. **Maintenance**: Must update fused shader when individual operators change
-
----
-
-## Benchmark Results
-
-```
-Operator: Conv2d 3×3, 64 channels, 56×56 input
-Sequential: 2.34ms
-Fused: 0.89ms
-Speedup: 2.6×
-
-Memory allocated:
-Sequential: 3 × output_tensor = 3 × 802,816 bytes
-Fused: 1 × output_tensor = 802,816 bytes
-Reduction: 66%
-```
-
----
-
-## Future Enhancements
-
-1. **More Fusion Patterns**: Conv2d+BatchNorm+ReLU, Conv2d+ReLU+MaxPool
-2. **Auto-Fusion Detection**: Analyze model graph and automatically fuse compatible sequences
-3. **Template-Based Fusion**: Generate fused shaders at runtime from individual operator shaders
diff --git a/openspec/specs/memory-layout/spec.md b/openspec/specs/memory-layout/spec.md
deleted file mode 100644
index b58d732..0000000
--- a/openspec/specs/memory-layout/spec.md
+++ /dev/null
@@ -1,182 +0,0 @@
-# Memory Layout Specification
-
-**Status:** Final
-**Type:** Feature
-**Created:** 2025-02-20
-**Last Updated:** 2026-04-17
-
----
-
-## Overview
-
-This specification defines the memory layout system supporting both NCHW (channel-first) and NHWC (channel-last) tensor layouts commonly used in deep learning frameworks.
-
----
-
-## Requirements
-
-### Requirement: Layout Type Support
-
-The system SHALL support NCHW and NHWC memory layouts for 4D tensors.
-
-#### Scenario: Create NCHW tensor
-- **WHEN** creating tensor without layout specification
-- **THEN** default layout is NCHW
-
-#### Scenario: Create NHWC tensor
-- **WHEN** creating tensor with layout: 'NHWC' option
-- **THEN** tensor has NHWC layout
-
-#### Scenario: Layout metadata tracking
-- **WHEN** tensor is created
-- **THEN** layout is accessible via tensor.layout property
-
----
-
-### Requirement: Layout Conversion
-
-The system SHALL provide layout conversion functionality.
-
-#### Scenario: Convert NCHW to NHWC
-- **WHEN** calling tensor.convertLayout('NHWC') on NCHW tensor
-- **THEN** returned tensor has NHWC layout with transposed data
-
-#### Scenario: Convert NHWC to NCHW
-- **WHEN** calling tensor.convertLayout('NCHW') on NHWC tensor
-- **THEN** returned tensor has NCHW layout with transposed data
-
-#### Scenario: No-op for same layout
-- **WHEN** calling convertLayout with current layout
-- **THEN** same tensor is returned without copy
-
-#### Scenario: Roundtrip preservation
-- **WHEN** converting NCHW → NHWC → NCHW
-- **THEN** data is exactly preserved
-
----
-
-### Requirement: Layout-Aware Operators
-
-Operators that process 4D tensors SHALL respect the input layout.
-
-#### Scenario: NCHW convolution
-- **WHEN** executing Conv2d on NCHW tensor
-- **THEN** NCHW-indexed shader is used
-
-#### Scenario: NHWC convolution
-- **WHEN** executing Conv2d on NHWC tensor
-- **THEN** NHWC-indexed shader is used
-
-#### Scenario: Layout preservation
-- **WHEN** operator processes tensor
-- **THEN** output has same layout as input
-
----
-
-### Requirement: Framework Compatibility
-
-The system SHALL support models from frameworks with different default layouts.
-
-#### Scenario: PyTorch model loading
-- **WHEN** loading PyTorch model (NCHW default)
-- **THEN** tensors use NCHW layout
-
-#### Scenario: TensorFlow model loading
-- **WHEN** loading TensorFlow model (NHWC default)
-- **THEN** tensors can use NHWC layout
-
----
-
-## Layout Definitions
-
-### NCHW (Channel-First)
-
-```
-Shape: [N, C, H, W]
-Index: n * (C*H*W) + c * (H*W) + h * W + w
-Strides: [C*H*W, H*W, W, 1]
-
-Memory Layout:
-  [n=0, c=0, h=0, w=0..W-1]  <- contiguous in memory
-  [n=0, c=0, h=1, w=0..W-1]
-  ...
-  [n=0, c=1, h=0, w=0..W-1]
-```
-
-### NHWC (Channel-Last)
-
-```
-Shape: [N, H, W, C]
-Index: n * (H*W*C) + h * (W*C) + w * C + c
-Strides: [H*W*C, W*C, C, 1]
-
-Memory Layout:
-  [n=0, h=0, w=0, c=0..C-1]  <- contiguous in memory
-  [n=0, h=0, w=1, c=0..C-1]
-  ...
-  [n=0, h=1, w=0, c=0..C-1]
-```
-
----
-
-## Performance Considerations
-
-### GPU Memory Coalescing
-
-NHWC can provide better memory coalescing on some GPUs:
-
-```
-NCHW: Adjacent threads access different channels
-  Thread 0: [n=0, h=0, w=0, c=0]
-  Thread 1: [n=0, h=0, w=1, c=0]  <- different spatial position
-
-NHWC: Adjacent threads access same position, different channels
-  Thread 0: [n=0, h=0, w=0, c=0]
-  Thread 1: [n=0, h=0, w=0, c=1]  <- same spatial position, adjacent memory
-```
-
-### Conversion Overhead
-
-Layout conversion requires a full tensor copy:
-- Read entire tensor
-- Write entire tensor
-- Overhead: O(N×C×H×W)
-
-**Guideline**: Convert once at model load time, not during inference.
-
----
-
-## API Design
-
-```typescript
-// Create tensor with specific layout
-const input = new Tensor(context, [1, 3, 224, 224], { layout: 'NCHW' });
-
-// Check layout
-if (input.layout === 'NHWC') {
-  // Handle NHWC-specific logic
-}
-
-// Convert layout (creates new tensor)
-const converted = await input.convertLayout('NHWC');
-
-// Operators preserve layout
-const output = await conv2d.forward([input], params);
-// output.layout === input.layout
-```
-
----
-
-## Limitations
-
-1. **4D Tensors Only**: Layout conversion defined for 4D tensors (NCHW/NHWC)
-2. **No Auto-Detection**: Layout must be specified; cannot infer from data
-3. **Memory Overhead**: Conversion doubles memory usage temporarily
-
----
-
-## Future Enhancements
-
-1. **ND Layout Support**: Extend to arbitrary dimensions
-2. **Strided Tensors**: Support non-contiguous memory layouts
-3. **Layout Inference**: Detect layout from model metadata
diff --git a/openspec/specs/product/spec.md b/openspec/specs/product/spec.md
deleted file mode 100644
index bcb8f97..0000000
--- a/openspec/specs/product/spec.md
+++ /dev/null
@@ -1,304 +0,0 @@
-# Product Specification
-
-**Version:** 2.0.1
-**Status:** Production Ready
-**Last Updated:** 2026-04-17
-
----
-
-## Overview
-
-Tiny-DL-Inference is a zero-dependency, high-performance deep learning inference engine built on WebGPU. It demonstrates a deep understanding of AI acceleration and heterogeneous computing by implementing neural network operators from scratch.
-
-### Target Users
-
-- **AI/ML Engineers**: Need lightweight inference without framework overhead
-- **Web Developers**: Want GPU-accelerated ML in browser applications
-- **Educators/Researchers**: Study GPU computing and neural network optimization
-- **Edge Computing**: Require minimal footprint inference solutions
-
-### Key Differentiators
-
-| Feature | Tiny-DL-Inference | TensorFlow.js | ONNX Runtime |
-|---------|-------------------|---------------|--------------|
-| Dependencies | Zero | Heavy | Heavy |
-| Bundle Size | ~50KB | ~2MB | ~1MB |
-| GPU Control | Full | Abstracted | Abstracted |
-| Shader Access | Direct | No | No |
-| Kernel Fusion | Manual | Automatic | Automatic |
-
----
-
-## Requirements
-
-### Requirement: WebGPU Device Management
-
-The system SHALL provide WebGPU device management with proper initialization and error handling.
-
-#### Scenario: Initialize GPU on supported browser
-- **WHEN** browser supports WebGPU
-- **THEN** GPUContext.initialize() succeeds without error
-
-#### Scenario: Report error on unsupported browser
-- **WHEN** browser does not support WebGPU
-- **THEN** GPUContext.initialize() throws WebGPUNotSupportedError
-
-#### Scenario: Configure power preference
-- **WHEN** user specifies powerPreference config
-- **THEN** GPU device is created with the specified power preference
-
-#### Scenario: Proper resource cleanup
-- **WHEN** GPUContext.destroy() is called
-- **THEN** all GPU resources are released
-
----
-
-### Requirement: Tensor Data Structure
-
-The system SHALL provide a Tensor class for GPU buffer management with shape and layout metadata.
-
-#### Scenario: Create tensor with specified shape
-- **WHEN** creating a Tensor with shape [2, 3, 4]
-- **THEN** tensor.shape equals [2, 3, 4] and tensor.size equals 24
-
-#### Scenario: Upload data to GPU
-- **WHEN** calling tensor.upload(data) with Float32Array
-- **THEN** data is copied to GPU buffer
-
-#### Scenario: Download data from GPU
-- **WHEN** calling tensor.download() after upload
-- **THEN** returned data equals uploaded data (roundtrip consistency)
-
-#### Scenario: Zero-copy reshape
-- **WHEN** calling tensor.reshape([newShape])
-- **THEN** returned tensor shares the same GPU buffer
-
-#### Scenario: Layout conversion
-- **WHEN** calling tensor.convertLayout('NHWC') on NCHW tensor
-- **THEN** returned tensor has NHWC layout with correctly transposed data
-
----
-
-### Requirement: Conv2d Convolution Operator
-
-The system SHALL provide 2D convolution with configurable parameters.
-
-#### Scenario: Basic convolution
-- **WHEN** executing Conv2d with input [1, 1, 3, 3] and weight [1, 1, 2, 2]
-- **THEN** output shape is [1, 1, 2, 2]
-
-#### Scenario: Convolution with padding
-- **WHEN** executing Conv2d with padding [1, 1]
-- **THEN** output spatial dimensions are preserved
-
-#### Scenario: Reject NHWC input
-- **WHEN** executing Conv2d on NHWC layout tensor
-- **THEN** throws error "NCHW layout only"
-
-#### Scenario: Convolution correctness
-- **WHEN** executing Conv2d on GPU
-- **THEN** output matches CPU reference implementation within tolerance 1e-5
-
----
-
-### Requirement: MaxPool Pooling Operator
-
-The system SHALL provide 2D max pooling for downsampling feature maps.
-
-#### Scenario: Basic pooling
-- **WHEN** executing MaxPool with pool size [2, 2] and stride [2, 2]
-- **THEN** output spatial dimensions are halved
-
-#### Scenario: Pooling correctness
-- **WHEN** executing MaxPool
-- **THEN** each output element is the maximum in its pooling window
-
----
-
-### Requirement: ReLU Activation Function
-
-The system SHALL provide ReLU activation function.
-
-#### Scenario: Positive values
-- **WHEN** input values are positive [1, 2, 3]
-- **THEN** output equals input [1, 2, 3]
-
-#### Scenario: Negative values
-- **WHEN** input values are negative [-1, -2, -3]
-- **THEN** output is [0, 0, 0]
-
-#### Scenario: Mixed values
-- **WHEN** input values are [-2, -1, 0, 1, 2]
-- **THEN** output is [0, 0, 0, 1, 2]
-
-#### Scenario: Shape preservation
-- **WHEN** executing ReLU on any tensor
-- **THEN** output shape equals input shape
-
----
-
-### Requirement: Softmax Operator
-
-The system SHALL provide numerically stable softmax computation.
-
-#### Scenario: Output in valid range
-- **WHEN** executing Softmax
-- **THEN** all output values are in [0, 1] range
-
-#### Scenario: Probabilities sum to one
-- **WHEN** executing Softmax along last axis
-- **THEN** output values sum to 1.0 along that axis
-
-#### Scenario: Numerical stability
-- **WHEN** input contains large values (50-250)
-- **THEN** no output value is NaN or Infinity
-
-#### Scenario: Reject non-last axis
-- **WHEN** executing Softmax with axis != -1
-- **THEN** throws error "last axis only"
-
----
-
-### Requirement: Dense Operator
-
-The system SHALL provide fully connected layer operation.
-
-#### Scenario: Basic dense operation
-- **WHEN** executing Dense with input [2, 10] and weight [5, 10]
-- **THEN** output shape is [2, 5]
-
-#### Scenario: Dense with bias
-- **WHEN** executing Dense with bias tensor
-- **THEN** output includes bias values
-
-#### Scenario: Dense without bias
-- **WHEN** executing Dense with useBias false
-- **THEN** output is matrix multiplication only
-
----
-
-### Requirement: Flatten Operator
-
-The system SHALL provide tensor flattening for transitioning from conv to dense layers.
-
-#### Scenario: Flatten 4D tensor
-- **WHEN** executing Flatten on tensor [2, 64, 8, 8]
-- **THEN** output shape is [2, 4096]
-
-#### Scenario: Zero-copy operation
-- **WHEN** executing Flatten
-- **THEN** output shares the same GPU buffer as input
-
----
-
-### Requirement: Kernel Fusion Optimization
-
-The system SHALL provide fused operators for memory bandwidth optimization.
-
-#### Scenario: Conv2dBiasReLU equivalence
-- **WHEN** executing fused Conv2dBiasReLU
-- **THEN** output equals sequential Conv2d + Bias + ReLU
-
-#### Scenario: Memory reduction
-- **WHEN** using fused operator
-- **THEN** memory bandwidth is reduced by 3x compared to sequential
-
----
-
-### Requirement: Memory Layout Support
-
-The system SHALL support both NCHW and NHWC tensor layouts.
-
-#### Scenario: Layout conversion roundtrip
-- **WHEN** converting NCHW to NHWC and back to NCHW
-- **THEN** data is preserved exactly
-
-#### Scenario: Layout-specific shaders
-- **WHEN** executing operators on different layouts
-- **THEN** output is equivalent regardless of layout
-
----
-
-### Requirement: Model Loading and Inference
-
-The system SHALL provide model loading and end-to-end inference.
-
-#### Scenario: Load model from JSON
-- **WHEN** loading model definition with layers and weights
-- **THEN** weights are allocated as GPU tensors
-
-#### Scenario: Reject invalid graph definitions
-- **WHEN** model definition contains duplicate layer names, unknown operators, or unresolved tensor references
-- **THEN** loading fails before inference starts
-
-#### Scenario: Run inference
-- **WHEN** calling infer() with input tensor
-- **THEN** output tensor is returned with correct shape
-
-#### Scenario: MNIST end-to-end
-- **WHEN** running MNIST model inference on 28x28 input
-- **THEN** output has 10 classes summing to ~1.0
-
----
-
-### Requirement: Performance Benchmarking
-
-The system SHALL provide performance measurement tools.
-
-#### Scenario: Measure single operator
-- **WHEN** using Benchmark class
-- **THEN** execution time is reported
-
-#### Scenario: Compare fusion
-- **WHEN** comparing fused vs sequential operators
-- **THEN** performance difference is quantified
-
----
-
-## Non-Functional Requirements
-
-### Performance
-
-| ID | Requirement | Target |
-|----|-------------|--------|
-| NFR-1.1 | Memory bandwidth reduction via fusion | 3x |
-| NFR-1.2 | Zero-copy reshape overhead | < 1μs |
-| NFR-1.3 | First inference latency (MNIST) | < 100ms |
-
-### Quality
-
-| ID | Requirement | Target |
-|----|-------------|--------|
-| NFR-2.1 | Test coverage | > 90% |
-| NFR-2.2 | Property-based test iterations | 100+ per test |
-| NFR-2.3 | TypeScript strict mode | Enabled |
-
-### Compatibility
-
-| ID | Requirement | Target |
-|----|-------------|--------|
-| NFR-3.1 | Chrome support | 113+ |
-| NFR-3.2 | Edge support | 113+ |
-| NFR-3.3 | Node.js support | 18+ |
-
----
-
-## Implementation Status
-
-| Component | Status |
-|-----------|--------|
-| GPUContext | Complete |
-| Tensor | Complete |
-| ReLU | Complete |
-| Softmax | Complete |
-| MaxPool | Complete |
-| Conv2d | Complete |
-| Dense | Complete |
-| Flatten | Complete |
-| Conv2dBiasReLU | Complete |
-| Add | Complete |
-| BatchNorm2d | Complete |
-| InferenceEngine | Complete |
-| Benchmark | Complete |
-
-**Total Tests**: 167 passing
diff --git a/openspec/specs/testing/spec.md b/openspec/specs/testing/spec.md
deleted file mode 100644
index 960dd55..0000000
--- a/openspec/specs/testing/spec.md
+++ /dev/null
@@ -1,302 +0,0 @@
-# Testing Specification
-
-**Status:** Final
-**Last Updated:** 2026-04-17
-
----
-
-## Overview
-
-This specification defines the BDD-style test specifications and acceptance criteria for Tiny-DL-Inference.
-
----
-
-## Feature: Tensor Operations
-
-```gherkin
-Feature: Tensor Operations
-  As a deep learning developer
-  I want to manipulate tensors on GPU
-  So that I can efficiently process neural network data
-```
-
-### Scenario: Create tensor from array
-
-- **WHEN** I create a tensor from array [1, 2, 3, 4] with shape [2, 2]
-- **THEN** the tensor shape should be [2, 2]
-- **AND** the tensor size should be 4
-
-### Scenario: Upload and download data
-
-- **WHEN** I upload Float32Array [1, 2, 3, 4, 5, 6] to tensor with shape [2, 3]
-- **AND** I download the data
-- **THEN** the result should equal Float32Array [1, 2, 3, 4, 5, 6]
-
-### Scenario: Reshape tensor
-
-- **WHEN** I reshape tensor with shape [1, 3, 4, 4] to [1, 48]
-- **THEN** the new tensor shape should be [1, 48]
-- **AND** the total elements should remain 48
-- **AND** the GPU buffer should be shared
-
-### Scenario: Data roundtrip property
-
-- **WHEN** I create a tensor with any shape up to 100 elements with random data
-- **AND** I upload the data and download the data
-- **THEN** the downloaded data should equal the uploaded data
-
----
-
-## Feature: Conv2d Operator
-
-```gherkin
-Feature: Conv2d Operator
-  As a deep learning developer
-  I want to perform 2D convolution
-  So that I can process image feature maps
-```
-
-### Scenario: Conv2d basic execution
-
-- **WHEN** I execute Conv2d with input tensor shape [1, 1, 3, 3] and weight tensor shape [1, 1, 2, 2]
-- **AND** kernel [2, 2], stride [1, 1], padding [0, 0]
-- **THEN** the output shape should be [1, 1, 2, 2]
-
-### Scenario: Conv2d with padding
-
-- **WHEN** I execute Conv2d with input tensor shape [1, 3, 32, 32] and weight tensor shape [64, 3, 3, 3]
-- **AND** kernel [3, 3], stride [1, 1], padding [1, 1]
-- **THEN** the output shape should be [1, 64, 32, 32]
-
-### Scenario: Conv2d rejects NHWC input
-
-- **WHEN** I execute Conv2d on input tensor with layout NHWC
-- **THEN** it should throw an error "NCHW layout only"
-
-### Scenario: Conv2d correctness
-
-- **WHEN** I execute Conv2d on GPU with any valid configuration
-- **AND** I compute Conv2d on CPU reference
-- **THEN** the GPU output should match CPU reference within tolerance 1e-5
-
----
-
-## Feature: MaxPool Operator
-
-```gherkin
-Feature: MaxPool Operator
-  As a deep learning developer
-  I want to perform max pooling
-  So that I can downsample feature maps
-```
-
-### Scenario: MaxPool basic execution
-
-- **WHEN** I execute MaxPool on input tensor shape [1, 64, 28, 28]
-- **AND** pool size [2, 2], stride [2, 2]
-- **THEN** the output shape should be [1, 64, 14, 14]
-
-### Scenario: MaxPool correctness
-
-- **WHEN** I execute MaxPool with pool size [2, 2], stride [2, 2] on input tensor with known values
-- **THEN** each output element should be the maximum in its 2x2 window
-
----
-
-## Feature: ReLU Operator
-
-```gherkin
-Feature: ReLU Operator
-  As a deep learning developer
-  I want to apply ReLU activation
-  So that I can add non-linearity to my network
-```
-
-### Scenario: ReLU with positive values
-
-- **WHEN** I execute ReLU on input tensor with values [1, 2, 3, 4, 5]
-- **THEN** the output should be [1, 2, 3, 4, 5]
-
-### Scenario: ReLU with negative values
-
-- **WHEN** I execute ReLU on input tensor with values [-1, -2, -3, -4, -5]
-- **THEN** the output should be [0, 0, 0, 0, 0]
-
-### Scenario: ReLU with mixed values
-
-- **WHEN** I execute ReLU on input tensor with values [-2, -1, 0, 1, 2]
-- **THEN** the output should be [0, 0, 0, 1, 2]
-
-### Scenario: ReLU preserves shape
-
-- **WHEN** I execute ReLU on any tensor shape
-- **THEN** the output shape should equal the input shape
-
----
-
-## Feature: Softmax Operator
-
-```gherkin
-Feature: Softmax Operator
-  As a deep learning developer
-  I want to compute softmax
-  So that I can generate probability distributions
-```
-
-### Scenario: Softmax output range
-
-- **WHEN** I execute Softmax on input tensor with any values
-- **THEN** all output values should be in range [0, 1]
-
-### Scenario: Softmax sums to one
-
-- **WHEN** I execute Softmax along axis -1 on input tensor with shape [batch, features]
-- **THEN** for each batch, the output values should sum to 1.0
-
-### Scenario: Softmax numerical stability
-
-- **WHEN** I execute Softmax on input tensor with large values (50-250)
-- **THEN** no output value should be NaN or Infinity
-
-### Scenario: Softmax rejects non-last axis
-
-- **WHEN** I execute Softmax with axis 1 on input tensor with shape [2, 3, 4]
-- **THEN** it should throw an error "last axis"
-
----
-
-## Feature: Dense Operator
-
-```gherkin
-Feature: Dense Operator
-  As a deep learning developer
-  I want to perform fully connected operations
-  So that I can implement classification layers
-```
-
-### Scenario: Dense basic execution
-
-- **WHEN** I execute Dense with input tensor shape [2, 10] and weight tensor shape [5, 10]
-- **THEN** the output shape should be [2, 5]
-
-### Scenario: Dense with bias
-
-- **WHEN** I execute Dense with input shape [1, 4], weight shape [2, 4], and bias shape [2]
-- **THEN** the output should include bias values
-
-### Scenario: Dense without bias
-
-- **WHEN** I execute Dense with useBias false
-- **THEN** the output should be matrix multiplication only
-
----
-
-## Feature: Add Operator
-
-```gherkin
-Feature: Add Operator
-  As a deep learning developer
-  I want to add residual tensors element-wise
-  So that I can express skip connections safely
-```
-
-### Scenario: Add basic execution
-
-- **WHEN** I execute Add with two tensors of the same shape and layout
-- **THEN** the output shape should equal the input shape
-
-### Scenario: Add rejects layout mismatch
-
-- **WHEN** I execute Add with tensors that share the same shape but use different layouts
-- **THEN** it should throw an error "same layout"
-
----
-
-## Feature: Flatten Operator
-
-```gherkin
-Feature: Flatten Operator
-  As a deep learning developer
-  I want to flatten tensors
-  So that I can transition from conv to dense layers
-```
-
-### Scenario: Flatten 4D tensor
-
-- **WHEN** I execute Flatten on input tensor with shape [2, 64, 8, 8]
-- **THEN** the output shape should be [2, 4096]
-
-### Scenario: Flatten preserves data
-
-- **WHEN** I execute Flatten on input tensor with known values
-- **THEN** the total elements should be preserved
-- **AND** the data order should be preserved
-
-### Scenario: Flatten is zero-copy
-
-- **WHEN** I execute Flatten on input tensor with shape [1, 3, 4, 4]
-- **THEN** the output should share the same GPU buffer as input
-
----
-
-## Feature: Kernel Fusion
-
-```gherkin
-Feature: Kernel Fusion
-  As a deep learning developer
-  I want fused operators
-  So that I can reduce memory bandwidth
-```
-
-### Scenario: Conv2dBiasReLU equivalence
-
-- **WHEN** I execute Conv2dBiasReLU with input, weight, and bias tensors
-- **AND** I execute Conv2d, Bias, ReLU separately
-- **THEN** the fused output should equal the sequential output
-
-### Scenario: Conv2dBiasReLU rejects missing bias
-
-- **WHEN** I execute Conv2dBiasReLU with input and weight tensors only
-- **THEN** it should throw an error "input, weight, and bias tensors"
-
----
-
-## Feature: Inference Engine
-
-```gherkin
-Feature: Inference Engine
-  As a deep learning developer
-  I want to run end-to-end inference
-  So that I can make predictions with trained models
-```
-
-### Scenario: Load model
-
-- **WHEN** I load a model with layers and weights into initialized InferenceEngine
-- **THEN** the weights should be allocated as GPU tensors
-
-### Scenario: Reject invalid model graph at load time
-
-- **WHEN** I load a model with duplicate layer names, unknown operator types, or missing tensor references
-- **THEN** `loadModel()` should throw before inference starts
-
-### Scenario: Preserve previous model on failed reload
-
-- **WHEN** I load a valid model and then attempt to load an invalid replacement model
-- **THEN** the previously loaded model should remain executable
-
-### Scenario: Run inference
-
-- **WHEN** I run inference on loaded model with correct input tensor shape
-- **THEN** I should receive an output tensor
-
-### Scenario: Reject external tensor
-
-- **WHEN** I run inference with input tensor from different GPUContext
-- **THEN** it should throw an error "same GPUContext"
-
-### Scenario: MNIST end-to-end
-
-- **WHEN** I run inference on loaded MNIST model with input tensor shape [1, 1, 28, 28]
-- **THEN** the output should have 10 classes
-- **AND** the output should sum to approximately 1.0
diff --git a/package-lock.json b/package-lock.json
index 7351c50..58c32eb 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -1,12 +1,12 @@
 {
   "name": "tiny-dl-inference",
-  "version": "2.0.1",
+  "version": "2.1.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "tiny-dl-inference",
-      "version": "2.0.1",
+      "version": "2.1.0",
       "license": "MIT",
       "devDependencies": {
         "@eslint/js": "^9.0.0",