feat: scaffold SvelteKit project with Tailwind, TypeScript, ESLint, Prettier

Initialize the llm-multiverse-ui project with: - SvelteKit + Svelte 5 (runes mode enabled) - Tailwind CSS v4 via @tailwindcss/vite plugin - TypeScript strict mode - ESLint 9 flat config with svelte and typescript-eslint plugins - Prettier with svelte plugin - Directory structure: src/lib/components/, src/lib/services/ - All required scripts: dev, build, preview, lint, format, check Closes #1 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-12 11:03:46 +01:00
parent 3cb3480f78
commit 978325565d
40 changed files with 4376 additions and 256 deletions
--- a/.claude/agents/_shared-context.md
+++ b/.claude/agents/_shared-context.md
@@ -20,11 +20,11 @@ When in subagent mode, your final output MUST be a single JSON object:

 ```json
 {
-  "status": "success | partial | failed",
-  "summary": "3 sentence max description of what happened",
-  "artifacts": ["list of file paths created or modified"],
-  "phase_data": { },
-  "failure_reason": null
+	"status": "success | partial | failed",
+	"summary": "3 sentence max description of what happened",
+	"artifacts": ["list of file paths created or modified"],
+	"phase_data": {},
+	"failure_reason": null
 }
 ```

@@ -35,6 +35,7 @@ When in subagent mode, your final output MUST be a single JSON object:
 ## Architecture Reference

 All agents MUST respect the project's architecture constraints. Read `CLAUDE.md` if it exists for project-specific rules. Key principles:
+
 - Follow the established frontend framework patterns and conventions
 - Use the project's chosen state management approach consistently
 - Follow component composition patterns already established in the codebase
--- a/.claude/agents/code-review.md
+++ b/.claude/agents/code-review.md
@@ -29,6 +29,7 @@ git diff main --name-only
 ```

 Read every changed file in full. Also read the diff for context on what changed:
+
 ```bash
 git diff main
 ```
@@ -38,12 +39,14 @@ git diff main
 Evaluate each changed file against these dimensions:

 **Correctness:**
+
 - Does the code do what the issue and plan require?
 - Are edge cases handled?
 - Are error conditions properly managed?
 - Do loading and empty states work correctly?

 **Security:**
+
 - No XSS vulnerabilities (dangerouslySetInnerHTML, unsanitized user input)
 - No credentials or API keys in client-side code
 - No sensitive data stored insecurely (localStorage, etc.)
@@ -51,6 +54,7 @@ Evaluate each changed file against these dimensions:
 - No open redirects

 **Architecture:**
+
 - Component boundaries respected
 - State management follows project patterns
 - API communication uses established patterns
@@ -58,6 +62,7 @@ Evaluate each changed file against these dimensions:
 - Proper separation of concerns (logic vs presentation)

 **Code Quality:**
+
 - Idiomatic TypeScript/framework patterns
 - Consistent error handling
 - Meaningful variable and function names
@@ -66,18 +71,21 @@ Evaluate each changed file against these dimensions:
 - No `any` types without justification

 **Testing:**
+
 - Sufficient test coverage
 - Meaningful test cases (not just happy path)
 - Component tests for UI behavior
 - Proper mocking of external dependencies

 **Accessibility:**
+
 - Semantic HTML elements used
 - ARIA attributes where needed
 - Keyboard navigation support
 - Color contrast considerations

 **Performance:**
+
 - No unnecessary re-renders
 - Proper memoization where beneficial
 - Lazy loading for heavy components/routes
@@ -87,12 +95,12 @@ Evaluate each changed file against these dimensions:

 Each finding MUST be categorized:

-| Severity | Description | Blocks Merge? |
-|---|---|---|
-| **Critical** | Security vulnerability, data loss risk, major architectural violation | Yes |
-| **Major** | Bug, missing error handling, test gap, significant design issue | Yes |
-| **Minor** | Style issue, naming improvement, small optimization, documentation gap | No |
-| **Suggestion** | Optional improvement, alternative approach worth considering | No |
+| Severity       | Description                                                            | Blocks Merge? |
+| -------------- | ---------------------------------------------------------------------- | ------------- |
+| **Critical**   | Security vulnerability, data loss risk, major architectural violation  | Yes           |
+| **Major**      | Bug, missing error handling, test gap, significant design issue        | Yes           |
+| **Minor**      | Style issue, naming improvement, small optimization, documentation gap | No            |
+| **Suggestion** | Optional improvement, alternative approach worth considering           | No            |

 ### 5. Produce Review Report

@@ -130,6 +138,7 @@ Request Changes: one or more critical/major findings
 ### 6. Handle Minor Findings (standalone mode only)

 If the verdict is **APPROVE** but there are minor findings:
+
 1. Create a single Gitea issue titled: "Tech debt: minor findings from issue #<NUMBER> review"
 2. List all minor findings in the issue body as checklist items
 3. Apply labels: `type:refactor`, `priority:low`, `cat:tech-debt`
@@ -138,6 +147,7 @@ If the verdict is **APPROVE** but there are minor findings:
 ### 7. Post Review to PR (standalone mode only)

 If a pull request exists for the feature branch:
+
 - Add a review comment via `mcp__gitea__pull_request_review_write`
 - If APPROVE: approve the PR
 - If REQUEST_CHANGES: request changes with the critical/major findings listed
@@ -146,25 +156,23 @@ If a pull request exists for the feature branch:

 ```json
 {
-  "status": "success | failed",
-  "summary": "Code review of issue #N: APPROVE/REQUEST_CHANGES",
-  "artifacts": [],
-  "phase_data": {
-    "verdict": "APPROVE",
-    "findings": {
-      "critical": 0,
-      "major": 0,
-      "minor": 2,
-      "suggestion": 1
-    },
-    "critical_details": [],
-    "major_details": [],
-    "minor_details": [
-      {"file": "src/components/Dashboard.tsx", "line": 42, "description": "..."}
-    ],
-    "pr_number": null
-  },
-  "failure_reason": null
+	"status": "success | failed",
+	"summary": "Code review of issue #N: APPROVE/REQUEST_CHANGES",
+	"artifacts": [],
+	"phase_data": {
+		"verdict": "APPROVE",
+		"findings": {
+			"critical": 0,
+			"major": 0,
+			"minor": 2,
+			"suggestion": 1
+		},
+		"critical_details": [],
+		"major_details": [],
+		"minor_details": [{ "file": "src/components/Dashboard.tsx", "line": 42, "description": "..." }],
+		"pr_number": null
+	},
+	"failure_reason": null
 }
 ```

--- a/.claude/agents/implement-story.md
+++ b/.claude/agents/implement-story.md
@@ -23,6 +23,7 @@ An implementation plan MUST exist at `implementation-plans/issue-<NUMBER>.md` wi
 ### 1. Read the Plan and Context

 Read these files:
+
 - `implementation-plans/issue-<NUMBER>.md` -- the implementation plan
 - `CLAUDE.md` -- coding standards (if it exists)
 - `package.json` -- project dependencies and scripts
@@ -61,6 +62,7 @@ Follow the plan's implementation steps in order:
 ### 5. Code Quality Standards

 **General:**
+
 - TypeScript strict mode -- no `any` types without justification
 - Use the project's established patterns for component structure
 - Follow the project's naming conventions (check existing code)
@@ -68,17 +70,20 @@ Follow the plan's implementation steps in order:
 - Accessible markup (semantic HTML, ARIA attributes where needed)

 **Components:**
+
 - Keep components focused -- single responsibility
 - Extract reusable logic into custom hooks
 - Use proper prop typing with TypeScript interfaces
 - Handle loading, error, and empty states

 **State Management:**
+
 - Follow the project's chosen state management approach
 - Keep state as local as possible
 - Avoid prop drilling -- use context or state management when appropriate

 **Styling:**
+
 - Follow the project's established styling approach
 - Ensure responsive design
 - Support dark/light themes if the project uses them
@@ -86,6 +91,7 @@ Follow the plan's implementation steps in order:
 ### 6. Log Deviations

 If you deviate from the plan (different approach, additional files, skipped steps), document each deviation in the plan's **Deviation Log** section with:
+
 - What changed
 - Why it changed

@@ -115,6 +121,7 @@ Adapt commands based on what's available in `package.json`. Fix any failures bef
 ### 8. Commit

 Stage all changed files and commit with a descriptive message:
+
 ```
 feat: <short description of what was implemented> (issue #<NUMBER>)
 ```
@@ -124,6 +131,7 @@ Use conventional commit prefixes: `feat:`, `fix:`, `chore:`, `refactor:`, `test:
 ### 9. Output

 **standalone mode:** Display:
+
 - Files created and modified (with counts)
 - Tests added (count and coverage percentage)
 - Deviations from plan (if any)
@@ -136,23 +144,23 @@ Use conventional commit prefixes: `feat:`, `fix:`, `chore:`, `refactor:`, `test:

 ```json
 {
-  "status": "success | failed",
-  "summary": "Implemented issue #N on branch feature/issue-N-desc",
-  "artifacts": ["list of files created/modified"],
-  "phase_data": {
-    "issue_number": 28,
-    "branch_name": "feature/issue-28-dashboard-page",
-    "files_created": ["src/pages/Dashboard.tsx"],
-    "files_modified": ["src/App.tsx"],
-    "quality_gates": {
-      "build": "pass",
-      "lint": "pass",
-      "typecheck": "pass",
-      "tests": "pass"
-    },
-    "deviations": []
-  },
-  "failure_reason": null
+	"status": "success | failed",
+	"summary": "Implemented issue #N on branch feature/issue-N-desc",
+	"artifacts": ["list of files created/modified"],
+	"phase_data": {
+		"issue_number": 28,
+		"branch_name": "feature/issue-28-dashboard-page",
+		"files_created": ["src/pages/Dashboard.tsx"],
+		"files_modified": ["src/App.tsx"],
+		"quality_gates": {
+			"build": "pass",
+			"lint": "pass",
+			"typecheck": "pass",
+			"tests": "pass"
+		},
+		"deviations": []
+	},
+	"failure_reason": null
 }
 ```

--- a/.claude/agents/plan-story.md
+++ b/.claude/agents/plan-story.md
@@ -23,6 +23,7 @@ Use `mcp__gitea__issue_read` to get the full issue (title, body, labels, milesto
 ### 2. Read Project Context

 Read these files to understand the project:
+
 - `CLAUDE.md` -- coding standards and workflow (if it exists)
 - `package.json` -- project dependencies and scripts
 - `implementation-plans/_index.md` -- existing plans index (if it exists)
@@ -30,6 +31,7 @@ Read these files to understand the project:
 ### 3. Determine Technology Stack

 From the project files, determine:
+
 - **Framework:** React, Vue, Svelte, etc. (check package.json)
 - **Language:** TypeScript or JavaScript
 - **Build tool:** Vite, Next.js, Webpack, etc.
@@ -40,6 +42,7 @@ From the project files, determine:
 ### 4. Find Related Plans

 From the index (if it exists), identify plans that share:
+
 - The same feature area or component
 - Overlapping affected files
 - Dependency relationships (blocked-by / blocks)
@@ -49,6 +52,7 @@ Read those related plan files to understand prior decisions and patterns.
 ### 5. Explore the Codebase

 Based on the issue's scope, explore relevant code:
+
 - Use Glob to find files in affected directories
 - Use Grep to find existing patterns, interfaces, types, and components
 - Use Read to examine specific files mentioned in the issue or related plans
@@ -60,6 +64,7 @@ Based on the issue's scope, explore relevant code:
 Create the plan. The plan MUST include:

 **Metadata:**
+
 - Issue link, number, title
 - Milestone and labels
 - Status: `PLANNED`
@@ -68,9 +73,11 @@ Create the plan. The plan MUST include:
 - Blocked-by references

 **Acceptance Criteria:**
+
 - Copy directly from the issue body

 **Architecture Analysis:**
+
 - Which components/pages are affected
 - Which API endpoints are involved
 - Which state/stores are affected
@@ -78,6 +85,7 @@ Create the plan. The plan MUST include:
 - Existing patterns to follow (with file references)

 **Implementation Steps (phase by phase):**
+
 1. **Types & Configuration** -- TypeScript types/interfaces, config constants, API types
 2. **Core Logic** -- Business logic, hooks, utilities, state management
 3. **Components** -- UI components, layouts, pages
@@ -85,9 +93,11 @@ Create the plan. The plan MUST include:
 5. **Tests** -- Unit tests, component tests, E2E tests

 **Files to Create/Modify:**
+
 - Explicit file paths with a one-line purpose for each

 **Risks and Edge Cases:**
+
 - Potential issues and mitigation strategies

 **Important:** Include type definitions, component signatures, and hook interfaces in the plan, but do NOT write actual implementation code.
@@ -99,6 +109,7 @@ Write the plan to `implementation-plans/issue-<NUMBER>.md`.
 ### 8. Update the Index

 Create or update `implementation-plans/_index.md`:
+
 - Add the new plan to the master table
 - Add cross-references in the appropriate feature area section

@@ -111,16 +122,16 @@ Create or update `implementation-plans/_index.md`:

 ```json
 {
-  "status": "success | failed",
-  "summary": "Created implementation plan for issue #N",
-  "artifacts": ["implementation-plans/issue-N.md", "implementation-plans/_index.md"],
-  "phase_data": {
-    "issue_number": 28,
-    "plan_path": "implementation-plans/issue-28.md",
-    "language": "typescript",
-    "framework": "react"
-  },
-  "failure_reason": null
+	"status": "success | failed",
+	"summary": "Created implementation plan for issue #N",
+	"artifacts": ["implementation-plans/issue-N.md", "implementation-plans/_index.md"],
+	"phase_data": {
+		"issue_number": 28,
+		"plan_path": "implementation-plans/issue-28.md",
+		"language": "typescript",
+		"framework": "react"
+	},
+	"failure_reason": null
 }
 ```

--- a/.claude/agents/refactor-review.md
+++ b/.claude/agents/refactor-review.md
@@ -12,6 +12,7 @@ Mode is specified in Dynamic Context below. Default: standalone.
 ## Trigger

 This agent is invoked:
+
 - Periodically (every ~5 completed stories) by the auto-dev pipeline
 - Manually by the user via `/project:refactor-review`

@@ -26,6 +27,7 @@ This agent is invoked:
 ### 2. Survey the Codebase

 Explore all source directories:
+
 - Use Glob to find all source files (`src/**/*.ts`, `src/**/*.tsx`, `src/**/*.css`, `src/**/*.vue`, `src/**/*.svelte`, etc.)
 - Use Grep to find patterns of concern (see checklist below)
 - Read key files to understand current state
@@ -35,17 +37,20 @@ Explore all source directories:
 Evaluate the project against these dimensions:

 **Code Duplication:**
+
 - Shared logic duplicated across components instead of extracted to hooks/utilities
 - Similar UI patterns that should be abstracted into shared components
 - Repeated API call patterns that should use a shared data fetching layer

 **Modularity:**
+
 - Components longer than ~100 lines that should be split
 - Components with too many responsibilities (God components)
 - Tight coupling between feature modules
 - Missing abstractions (e.g., a custom hook for behavior used in multiple places)

 **Consistency:**
+
 - Inconsistent error handling patterns across components
 - Inconsistent state management approaches
 - Inconsistent API call patterns
@@ -53,23 +58,27 @@ Evaluate the project against these dimensions:
 - Inconsistent styling approaches

 **Architecture Drift:**
+
 - Components bypassing the established API layer
 - State management inconsistencies
 - Routing pattern violations
 - Feature boundaries not respected

 **Dependency Health:**
+
 - Unused dependencies in package.json
 - Outdated dependencies with known vulnerabilities
 - Lock file hygiene

 **Test Quality:**
+
 - Tests that only test happy paths
 - Missing component tests for interactive features
 - Missing E2E tests for critical user flows
 - Test code duplication (shared fixtures/helpers needed)

 **Accessibility:**
+
 - Missing ARIA attributes on interactive elements
 - Missing keyboard navigation
 - Color contrast issues
@@ -79,11 +88,11 @@ Evaluate the project against these dimensions:

 Categorize each finding:

-| Priority | Description |
-|---|---|
-| **High** | Architecture drift, security concern, significant duplication causing bugs, accessibility blockers |
-| **Medium** | Modularity issues, inconsistencies, test quality gaps |
-| **Low** | Style issues, minor duplication, documentation gaps |
+| Priority   | Description                                                                                        |
+| ---------- | -------------------------------------------------------------------------------------------------- |
+| **High**   | Architecture drift, security concern, significant duplication causing bugs, accessibility blockers |
+| **Medium** | Modularity issues, inconsistencies, test quality gaps                                              |
+| **Low**    | Style issues, minor duplication, documentation gaps                                                |

 ### 5. Create Refactoring Issues

@@ -140,15 +149,15 @@ Check existing open issues with `type:refactor` and `priority:low` labels. If an

 ```json
 {
-  "status": "success",
-  "summary": "Refactoring review complete",
-  "artifacts": [],
-  "phase_data": {
-    "project_health": "GOOD",
-    "issues_created": [{"number": 42, "title": "Refactor: ...", "priority": "medium"}],
-    "issues_closed": [{"number": 30, "title": "Tech debt: ...", "reason": "resolved"}]
-  },
-  "failure_reason": null
+	"status": "success",
+	"summary": "Refactoring review complete",
+	"artifacts": [],
+	"phase_data": {
+		"project_health": "GOOD",
+		"issues_created": [{ "number": 42, "title": "Refactor: ...", "priority": "medium" }],
+		"issues_closed": [{ "number": 30, "title": "Tech debt: ...", "reason": "resolved" }]
+	},
+	"failure_reason": null
 }
 ```

--- a/.claude/agents/release.md
+++ b/.claude/agents/release.md
@@ -58,6 +58,7 @@ git checkout -b release/<milestone-slug> main
 ### 4. Create Release PR

 Push the release branch and create a Gitea PR:
+
 - **Title:** `Release: <milestone-name>`
 - **Head:** `release/<milestone-slug>`
 - **Base:** `main`
@@ -82,6 +83,7 @@ If **manually requested (standalone mode):** Proceed to merge.
 ### 6. Create Gitea Release

 Use `mcp__gitea__create_release`:
+
 - **tag_name:** `<milestone-slug>`
 - **target:** `main`
 - **title:** `<milestone-name>`
@@ -94,6 +96,7 @@ Use `mcp__gitea__milestone_write` to set the milestone state to `closed`.
 ### 8. Output

 **standalone mode:** Display:
+
 - Milestone name and version
 - PR number and merge status
 - Tag created
@@ -107,17 +110,17 @@ Use `mcp__gitea__milestone_write` to set the milestone state to `closed`.

 ```json
 {
-  "status": "success | failed",
-  "summary": "Release PR created for milestone <name>",
-  "artifacts": [],
-  "phase_data": {
-    "milestone": "MVP",
-    "pr_number": 42,
-    "merged": false,
-    "tag": null,
-    "issues_included": [28, 29, 30]
-  },
-  "failure_reason": null
+	"status": "success | failed",
+	"summary": "Release PR created for milestone <name>",
+	"artifacts": [],
+	"phase_data": {
+		"milestone": "MVP",
+		"pr_number": 42,
+		"merged": false,
+		"tag": null,
+		"issues_included": [28, 29, 30]
+	},
+	"failure_reason": null
 }
 ```

--- a/.claude/agents/select-story.md
+++ b/.claude/agents/select-story.md
@@ -18,6 +18,7 @@ Use `mcp__gitea__list_issues` to fetch all open issues. Paginate with `perPage:
 ### 2. Filter Out Ineligible Issues

 Remove any issue that has:
+
 - Label `workflow:manual`
 - Label `workflow:blocked`

@@ -34,10 +35,12 @@ For each candidate issue, read its body and look for a "Blocked by" section. If
 Sort remaining issues using this priority order:

 **Milestone priority (earliest milestone first):**
+
 - Sort by milestone due date (earliest first)
 - Issues with no milestone come last

 **Within the same milestone, sort by priority label:**
+
 1. `priority:critical`
 2. `priority:high`
 3. `priority:medium`
@@ -47,6 +50,7 @@ Sort remaining issues using this priority order:
 ### 6. Present or Return Result

 **standalone mode:** Display the highest-priority issue with:
+
 - Issue number and title
 - Milestone name
 - All labels
@@ -61,6 +65,7 @@ Then ask: "Shall I proceed to plan this story, or would you like to pick a diffe
 ## Auto-Merge Eligibility

 All issues are auto-merge eligible by default EXCEPT:
+
 - Issues with label `workflow:manual-review`

 If the issue has `workflow:manual-review`, set `auto_merge_eligible: false`. Otherwise set it to `true`.
@@ -69,17 +74,17 @@ If the issue has `workflow:manual-review`, set `auto_merge_eligible: false`. Oth

 ```json
 {
-  "status": "success | failed",
-  "summary": "Selected issue #N: <title>",
-  "artifacts": [],
-  "phase_data": {
-    "issue_number": 28,
-    "issue_title": "Story title",
-    "milestone": "MVP",
-    "labels": ["type:feature", "priority:high"],
-    "auto_merge_eligible": true
-  },
-  "failure_reason": null
+	"status": "success | failed",
+	"summary": "Selected issue #N: <title>",
+	"artifacts": [],
+	"phase_data": {
+		"issue_number": 28,
+		"issue_title": "Story title",
+		"milestone": "MVP",
+		"labels": ["type:feature", "priority:high"],
+		"auto_merge_eligible": true
+	},
+	"failure_reason": null
 }
 ```

--- a/.claude/agents/verify-story.md
+++ b/.claude/agents/verify-story.md
@@ -30,26 +30,31 @@ Check `package.json` and the plan to know which quality gates to run.
 Run each gate and record pass/fail. Detect available commands from `package.json`:

 Gate 1 -- Build:
+
 ```bash
 npm run build
 ```

 Gate 2 -- Lint:
+
 ```bash
 npm run lint
 ```

 Gate 3 -- Type Check:
+
 ```bash
 npm run typecheck  # or npx tsc --noEmit
 ```

 Gate 4 -- Tests:
+
 ```bash
 npm run test
 ```

 Gate 5 -- Format (if available):
+
 ```bash
 npm run format:check  # or npx prettier --check .
 ```
@@ -61,18 +66,21 @@ Adapt commands based on what's available in `package.json`.
 Review all files changed in this branch (use `git diff main --name-only` to get the list). For each changed file, verify:

 **General:**
+
 - No hardcoded credentials, API keys, or secrets
 - No `TODO` or `FIXME` left unresolved (unless documented in plan)
 - Consistent error handling patterns
 - No `console.log` left in production code (use proper logging if available)

 **TypeScript:**
+
 - No `any` types without justification
 - Proper type narrowing and null checks
 - No type assertions (`as`) without justification
 - Interfaces/types exported where needed

 **Components:**
+
 - Proper prop typing
 - Loading, error, and empty states handled
 - Accessible markup (semantic HTML, ARIA)
@@ -80,12 +88,14 @@ Review all files changed in this branch (use `git diff main --name-only` to get
 - Responsive design considered

 **State & Data:**
+
 - State management follows project patterns
 - API calls use the project's data fetching approach
 - Error states properly handled and displayed
 - No data fetching in render path without proper caching/memoization

 **Security:**
+
 - No XSS vulnerabilities (dangerouslySetInnerHTML, etc.)
 - User input properly sanitized
 - API tokens/secrets not in client-side code
@@ -94,6 +104,7 @@ Review all files changed in this branch (use `git diff main --name-only` to get
 ### 5. Acceptance Criteria Verification

 For each acceptance criterion from the issue:
+
 - Check the code to verify the criterion is met
 - Note which file(s) satisfy each criterion
 - Mark each criterion as PASS or FAIL with explanation
@@ -101,6 +112,7 @@ For each acceptance criterion from the issue:
 ### 6. Determine Result

 **PASS** if ALL of the following are true:
+
 - All quality gates pass
 - No architecture violations found (major/critical)
 - All acceptance criteria are met
@@ -163,24 +175,24 @@ For each acceptance criterion from the issue:

 ```json
 {
-  "status": "success | failed",
-  "summary": "Verification of issue #N: PASS/FAIL",
-  "artifacts": [],
-  "phase_data": {
-    "verdict": "PASS",
-    "quality_gates": {
-      "build": "pass",
-      "lint": "pass",
-      "typecheck": "pass",
-      "tests": "pass",
-      "format": "pass"
-    },
-    "acceptance_criteria": [
-      {"criterion": "Description", "result": "PASS", "evidence": "Component.tsx:42"}
-    ],
-    "architecture_violations": []
-  },
-  "failure_reason": null
+	"status": "success | failed",
+	"summary": "Verification of issue #N: PASS/FAIL",
+	"artifacts": [],
+	"phase_data": {
+		"verdict": "PASS",
+		"quality_gates": {
+			"build": "pass",
+			"lint": "pass",
+			"typecheck": "pass",
+			"tests": "pass",
+			"format": "pass"
+		},
+		"acceptance_criteria": [
+			{ "criterion": "Description", "result": "PASS", "evidence": "Component.tsx:42" }
+		],
+		"architecture_violations": []
+	},
+	"failure_reason": null
 }
 ```

--- a/.claude/commands/auto-dev.md
+++ b/.claude/commands/auto-dev.md
@@ -10,6 +10,7 @@ You are the **Auto Dev Orchestrator**. You run the full development pipeline in
 ## Auto-Merge Eligibility

 An issue is **auto-merge eligible** (no user approval needed) if ALL of these are true:
+
 - The issue does NOT have a `workflow:manual-review` label
 - All quality gates pass
 - Code review by the review agent returns APPROVE (no critical/major findings)
@@ -35,6 +36,7 @@ Run the story selection logic (same as `/project:select-story`):
 7. Present the top candidate to the user with issue number, title, milestone, labels, and summary

 **PAUSE HERE** — Wait for user confirmation before proceeding. The user may:
+
 - Confirm the selection
 - Pick a different issue number
 - Say "stop" to end the loop
@@ -87,6 +89,7 @@ Run the code review logic autonomously (same as `/project:code-review`):
 Based on verification AND code review results:

 **On PASS (verification passes AND code review APPROVE):**
+
 1. Update plan status to `COMPLETED`
 2. Push the feature branch to origin
 3. Create a Gitea pull request targeting `main`
@@ -103,11 +106,13 @@ Based on verification AND code review results:
 8. Loop back to Phase 1

 **On FAIL (attempt 1):**
+
 1. Update plan status to `RETRY`
 2. Append retry instructions to the plan (what failed and how to fix it)
 3. Loop back to Phase 3 (re-implement with retry instructions)

 **On FAIL (attempt 2):**
+
 1. Update plan status to `BLOCKED`
 2. Add `workflow:manual` label to the Gitea issue
 3. Inform the user: "Story #NNN blocked after 2 attempts. Marked for manual review."
@@ -116,6 +121,7 @@ Based on verification AND code review results:
 ### Phase 7 — MILESTONE CHECK

 After each completed story, check if all issues in the story's milestone are now closed. If so:
+
 1. Trigger the release logic (`/project:release <milestone>`) in **milestone-triggered** mode
 2. The release PR is created but NOT merged — it awaits user approval
 3. Inform the user: "All issues in <milestone> completed. Release PR created for your approval."
@@ -124,6 +130,7 @@ After each completed story, check if all issues in the story's milestone are now
 ### Phase 8 — PERIODIC REFACTORING CHECK

 After every 5 completed stories (tracked by the `completed` counter):
+
 1. Run the refactoring review logic (`/project:refactor-review`)
 2. Create refactoring issues as needed
 3. Close resolved tech debt issues
@@ -133,11 +140,13 @@ After every 5 completed stories (tracked by the `completed` counter):
 ## Stop Conditions

 Stop the loop when any of these occur:
+
 - The user says "stop"
 - No eligible issues remain (all are completed, blocked, or have unmet dependencies)
 - 3 consecutive stories are BLOCKED

 When stopping, display a summary of work completed:
+
 - Stories completed (with PR links)
 - Stories auto-merged vs awaiting review
 - Stories blocked (with failure reasons)
@@ -149,6 +158,7 @@ When stopping, display a summary of work completed:
 ## Tracking

 Maintain a running tally during the session:
+
 - `completed`: list of issue numbers with PR links
 - `auto_merged`: list of issue numbers that were auto-merged
 - `awaiting_review`: list of issue numbers with PRs awaiting manual review
--- a/.claude/commands/code-review.md
+++ b/.claude/commands/code-review.md
@@ -26,6 +26,7 @@ git diff main --name-only
 ```

 Read every changed file in full. Also read the diff for context on what changed:
+
 ```bash
 git diff main
 ```
@@ -35,23 +36,27 @@ git diff main
 Evaluate each changed file against these dimensions:

 **Correctness:**
+
 - Does the code do what the issue and plan require?
 - Are edge cases handled?
 - Are error conditions properly managed?

 **Security:**
+
 - No XSS vulnerabilities
 - No credentials or API keys in client-side code
 - No sensitive data stored insecurely
 - Proper input sanitization

 **Architecture:**
+
 - Component boundaries respected
 - State management follows project patterns
 - API communication uses established patterns
 - Proper separation of concerns

 **Code Quality:**
+
 - Idiomatic TypeScript/framework patterns
 - Consistent error handling
 - Meaningful variable and function names
@@ -59,17 +64,20 @@ Evaluate each changed file against these dimensions:
 - No `any` types without justification

 **Testing:**
+
 - Sufficient test coverage
 - Meaningful test cases (not just happy path)
 - Component tests for UI behavior
 - Proper mocking of external dependencies

 **Accessibility:**
+
 - Semantic HTML elements used
 - ARIA attributes where needed
 - Keyboard navigation support

 **Performance:**
+
 - No unnecessary re-renders
 - Proper memoization where beneficial
 - No memory leaks
@@ -78,12 +86,12 @@ Evaluate each changed file against these dimensions:

 Each finding MUST be categorized:

-| Severity | Description | Blocks Merge? |
-|---|---|---|
-| **Critical** | Security vulnerability, data loss risk, major architectural violation | Yes |
-| **Major** | Bug, missing error handling, test gap, significant design issue | Yes |
-| **Minor** | Style issue, naming improvement, small optimization, documentation gap | No |
-| **Suggestion** | Optional improvement, alternative approach worth considering | No |
+| Severity       | Description                                                            | Blocks Merge? |
+| -------------- | ---------------------------------------------------------------------- | ------------- |
+| **Critical**   | Security vulnerability, data loss risk, major architectural violation  | Yes           |
+| **Major**      | Bug, missing error handling, test gap, significant design issue        | Yes           |
+| **Minor**      | Style issue, naming improvement, small optimization, documentation gap | No            |
+| **Suggestion** | Optional improvement, alternative approach worth considering           | No            |

 ### 5. Produce Review Report

@@ -117,6 +125,7 @@ Request Changes: one or more critical/major findings
 ### 6. Handle Minor Findings

 If the verdict is **APPROVE** but there are minor findings:
+
 1. Create a single Gitea issue titled: "Tech debt: minor findings from issue #$ARGUMENTS review"
 2. List all minor findings in the issue body as checklist items
 3. Apply labels: `type:refactor`, `priority:low`, `cat:tech-debt`
@@ -125,6 +134,7 @@ If the verdict is **APPROVE** but there are minor findings:
 ### 7. Post Review to PR

 If a pull request exists for the feature branch:
+
 - Add a review comment via `mcp__gitea__pull_request_review_write`
 - If APPROVE: approve the PR
 - If REQUEST_CHANGES: request changes with the critical/major findings listed
--- a/.claude/commands/implement-story.md
+++ b/.claude/commands/implement-story.md
@@ -20,6 +20,7 @@ An implementation plan MUST exist at `implementation-plans/issue-$ARGUMENTS.md`
 ### 1. Read the Plan and Context

 Read these files:
+
 - `implementation-plans/issue-$ARGUMENTS.md` — the implementation plan
 - `CLAUDE.md` — coding standards (if it exists)
 - `package.json` — project dependencies and scripts
@@ -64,6 +65,7 @@ Follow the plan's implementation steps in order:
 ### 6. Log Deviations

 If you deviate from the plan (different approach, additional files, skipped steps), document each deviation in the plan's **Deviation Log** section with:
+
 - What changed
 - Why it changed

@@ -81,6 +83,7 @@ Adapt commands based on what's available in `package.json`. Fix any failures bef
 ### 8. Commit

 Stage all changed files and commit with a descriptive message:
+
 ```
 feat: <short description of what was implemented> (issue #$ARGUMENTS)
 ```
@@ -90,6 +93,7 @@ Use conventional commit prefixes: `feat:`, `fix:`, `chore:`, `refactor:`, `test:
 ### 9. Output Summary

 Display:
+
 - Files created and modified (with counts)
 - Tests added (count)
 - Deviations from plan (if any)
--- a/.claude/commands/plan-story.md
+++ b/.claude/commands/plan-story.md
@@ -20,6 +20,7 @@ Use `mcp__gitea__issue_read` to get the full issue (title, body, labels, milesto
 ### 2. Read Project Context

 Read these files to understand the project:
+
 - `CLAUDE.md` — coding standards and workflow (if it exists)
 - `package.json` — project dependencies and scripts
 - `implementation-plans/_index.md` — existing plans index (if it exists)
@@ -27,6 +28,7 @@ Read these files to understand the project:
 ### 3. Determine Technology Stack

 From the project files, determine:
+
 - **Framework:** React, Vue, Svelte, etc. (check package.json)
 - **Language:** TypeScript or JavaScript
 - **Build tool:** Vite, Next.js, Webpack, etc.
@@ -37,6 +39,7 @@ From the project files, determine:
 ### 4. Find Related Plans

 From the index (if it exists), identify plans that share:
+
 - The same feature area or component
 - Overlapping affected files
 - Dependency relationships (blocked-by / blocks)
@@ -46,6 +49,7 @@ Read those related plan files to understand prior decisions and patterns.
 ### 5. Explore the Codebase

 Based on the issue's scope, explore relevant code:
+
 - Use Glob to find files in affected directories
 - Use Grep to find existing patterns, interfaces, types, and components
 - Use Read to examine specific files mentioned in the issue or related plans
@@ -56,6 +60,7 @@ Based on the issue's scope, explore relevant code:
 The plan MUST include:

 **Metadata:**
+
 - Issue link, number, title
 - Milestone and labels
 - Status: `PLANNED`
@@ -64,9 +69,11 @@ The plan MUST include:
 - Blocked-by references

 **Acceptance Criteria:**
+
 - Copy directly from the issue body

 **Architecture Analysis:**
+
 - Which components/pages are affected
 - Which API endpoints are involved
 - Which state/stores are affected
@@ -74,6 +81,7 @@ The plan MUST include:
 - Existing patterns to follow (with file references)

 **Implementation Steps (phase by phase):**
+
 1. **Types & Configuration** — TypeScript types/interfaces, config constants, API types
 2. **Core Logic** — Business logic, hooks, utilities, state management
 3. **Components** — UI components, layouts, pages
@@ -81,9 +89,11 @@ The plan MUST include:
 5. **Tests** — Unit tests, component tests, E2E tests

 **Files to Create/Modify:**
+
 - Explicit file paths with a one-line purpose for each

 **Risks and Edge Cases:**
+
 - Potential issues and mitigation strategies

 **Important:** Include type definitions, component signatures, and hook interfaces in the plan, but do NOT write actual implementation code.
@@ -95,6 +105,7 @@ Write the plan to `implementation-plans/issue-$ARGUMENTS.md`.
 ### 8. Update the Index

 Create or update `implementation-plans/_index.md`:
+
 - Add the new plan to the master table
 - Add cross-references in the appropriate feature area section

--- a/.claude/commands/refactor-review.md
+++ b/.claude/commands/refactor-review.md
@@ -10,6 +10,7 @@ You are the **Refactoring Reviewer** agent. Your job is to review the entire pro
 ## Trigger

 This command is triggered:
+
 - Periodically (every ~5 completed stories) by the auto-dev pipeline
 - Manually by the user via `/project:refactor-review`

@@ -24,6 +25,7 @@ This command is triggered:
 ### 2. Survey the Codebase

 Explore all source directories:
+
 - Use Glob to find all source files (`src/**/*.ts`, `src/**/*.tsx`, `src/**/*.css`, `src/**/*.vue`, `src/**/*.svelte`, etc.)
 - Use Grep to find patterns of concern (see checklist below)
 - Read key files to understand current state
@@ -33,17 +35,20 @@ Explore all source directories:
 Evaluate the project against these dimensions:

 **Code Duplication:**
+
 - Shared logic duplicated across components instead of extracted to hooks/utilities
 - Similar UI patterns that should be abstracted into shared components
 - Repeated API call patterns that should use a shared data fetching layer

 **Modularity:**
+
 - Components longer than ~100 lines that should be split
 - Components with too many responsibilities
 - Tight coupling between feature modules
 - Missing abstractions

 **Consistency:**
+
 - Inconsistent error handling patterns
 - Inconsistent state management approaches
 - Inconsistent API call patterns
@@ -51,21 +56,25 @@ Evaluate the project against these dimensions:
 - Inconsistent styling approaches

 **Architecture Drift:**
+
 - Components bypassing the established API layer
 - State management inconsistencies
 - Routing pattern violations

 **Dependency Health:**
+
 - Unused dependencies in package.json
 - Outdated dependencies with known vulnerabilities
 - Lock file hygiene

 **Test Quality:**
+
 - Tests that only test happy paths
 - Missing component tests for interactive features
 - Test code duplication

 **Accessibility:**
+
 - Missing ARIA attributes on interactive elements
 - Missing keyboard navigation
 - Missing alt text on images
@@ -74,11 +83,11 @@ Evaluate the project against these dimensions:

 Categorize each finding:

-| Priority | Description |
-|---|---|
-| **High** | Architecture drift, security concern, significant duplication, accessibility blockers |
-| **Medium** | Modularity issues, inconsistencies, test quality gaps |
-| **Low** | Style issues, minor duplication, documentation gaps |
+| Priority   | Description                                                                           |
+| ---------- | ------------------------------------------------------------------------------------- |
+| **High**   | Architecture drift, security concern, significant duplication, accessibility blockers |
+| **Medium** | Modularity issues, inconsistencies, test quality gaps                                 |
+| **Low**    | Style issues, minor duplication, documentation gaps                                   |

 ### 5. Create Refactoring Issues

--- a/.claude/commands/release.md
+++ b/.claude/commands/release.md
@@ -55,6 +55,7 @@ git checkout -b release/<milestone-slug> main
 ### 4. Create Release PR

 Push the release branch and create a Gitea PR:
+
 - **Title:** `Release: <milestone-name>`
 - **Head:** `release/<milestone-slug>`
 - **Base:** `main`
@@ -79,6 +80,7 @@ If **manually requested:** Proceed to merge.
 ### 6. Create Gitea Release

 Use `mcp__gitea__create_release`:
+
 - **tag_name:** `<milestone-slug>`
 - **target:** `main`
 - **title:** `<milestone-name>`
@@ -91,6 +93,7 @@ Use `mcp__gitea__milestone_write` to set the milestone state to `closed`.
 ### 8. Output Summary

 Display:
+
 - Milestone name and version
 - PR number and merge status
 - Tag created
--- a/.claude/commands/select-story.md
+++ b/.claude/commands/select-story.md
@@ -16,6 +16,7 @@ Use `mcp__gitea__list_issues` to fetch all open issues. Paginate with `perPage:
 ### 2. Filter Out Ineligible Issues

 Remove any issue that has:
+
 - Label `workflow:manual`
 - Label `workflow:blocked`

@@ -32,10 +33,12 @@ For each candidate issue, read its body and look for a "Blocked by" section. If
 Sort remaining issues using this priority order:

 **Milestone priority (earliest milestone first):**
+
 - Sort by milestone due date (earliest first)
 - Issues with no milestone come last

 **Within the same milestone, sort by priority label:**
+
 1. `priority:critical`
 2. `priority:high`
 3. `priority:medium`
@@ -45,6 +48,7 @@ Sort remaining issues using this priority order:
 ### 6. Present the Top Candidate

 Display the highest-priority issue with:
+
 - Issue number and title
 - Milestone name
 - All labels
--- a/.claude/commands/verify-story.md
+++ b/.claude/commands/verify-story.md
@@ -27,26 +27,31 @@ Check `package.json` and the plan to know which quality gates to run.
 Run each gate and record pass/fail:

 Gate 1 — Build:
+
 ```bash
 npm run build
 ```

 Gate 2 — Lint:
+
 ```bash
 npm run lint
 ```

 Gate 3 — Type Check:
+
 ```bash
 npm run typecheck  # or npx tsc --noEmit
 ```

 Gate 4 — Tests:
+
 ```bash
 npm run test
 ```

 Gate 5 — Format (if available):
+
 ```bash
 npm run format:check  # or npx prettier --check .
 ```
@@ -58,23 +63,27 @@ Adapt commands based on what's available in `package.json`.
 Review all files changed in this branch (use `git diff main --name-only` to get the list). For each changed file, verify:

 **General:**
+
 - [ ] No hardcoded credentials, API keys, or secrets
 - [ ] No `TODO` or `FIXME` left unresolved (unless documented in plan)
 - [ ] Consistent error handling patterns
 - [ ] No `console.log` left in production code

 **TypeScript:**
+
 - [ ] No `any` types without justification
 - [ ] Proper type narrowing and null checks
 - [ ] Interfaces/types exported where needed

 **Components:**
+
 - [ ] Proper prop typing
 - [ ] Loading, error, and empty states handled
 - [ ] Accessible markup (semantic HTML, ARIA)
 - [ ] Responsive design considered

 **Security:**
+
 - [ ] No XSS vulnerabilities
 - [ ] User input properly sanitized
 - [ ] API tokens/secrets not in client-side code
@@ -82,6 +91,7 @@ Review all files changed in this branch (use `git diff main --name-only` to get
 ### 5. Acceptance Criteria Verification

 For each acceptance criterion from the issue:
+
 - Check the code to verify the criterion is met
 - Note which file(s) satisfy each criterion
 - Mark each criterion as PASS or FAIL with explanation
@@ -89,6 +99,7 @@ For each acceptance criterion from the issue:
 ### 6. Determine Result

 **PASS** if ALL of the following are true:
+
 - All quality gates pass
 - No architecture violations found (major/critical)
 - All acceptance criteria are met