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>

.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",
+	"status": "success | partial | failed",
-  "summary": "3 sentence max description of what happened",
+	"summary": "3 sentence max description of what happened",
-  "artifacts": ["list of file paths created or modified"],
+	"artifacts": ["list of file paths created or modified"],
-  "phase_data": { },
+	"phase_data": {},
-  "failure_reason": null
+	"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

.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? |
+| Severity       | Description                                                            | Blocks Merge? |
-|---|---|---|
+| -------------- | ---------------------------------------------------------------------- | ------------- |
-| **Critical** | Security vulnerability, data loss risk, major architectural violation | Yes |
+| **Critical**   | Security vulnerability, data loss risk, major architectural violation  | Yes           |
-| **Major** | Bug, missing error handling, test gap, significant design issue | Yes |
+| **Major**      | Bug, missing error handling, test gap, significant design issue        | Yes           |
-| **Minor** | Style issue, naming improvement, small optimization, documentation gap | No |
+| **Minor**      | Style issue, naming improvement, small optimization, documentation gap | No            |
-| **Suggestion** | Optional improvement, alternative approach worth considering | 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",
+	"status": "success | failed",
-  "summary": "Code review of issue #N: APPROVE/REQUEST_CHANGES",
+	"summary": "Code review of issue #N: APPROVE/REQUEST_CHANGES",
-  "artifacts": [],
+	"artifacts": [],
-  "phase_data": {
+	"phase_data": {
-    "verdict": "APPROVE",
+		"verdict": "APPROVE",
-    "findings": {
+		"findings": {
-      "critical": 0,
+			"critical": 0,
-      "major": 0,
+			"major": 0,
-      "minor": 2,
+			"minor": 2,
-      "suggestion": 1
+			"suggestion": 1
-    },
+		},
-    "critical_details": [],
+		"critical_details": [],
-    "major_details": [],
+		"major_details": [],
-    "minor_details": [
+		"minor_details": [{ "file": "src/components/Dashboard.tsx", "line": 42, "description": "..." }],
-      {"file": "src/components/Dashboard.tsx", "line": 42, "description": "..."}
+		"pr_number": null
-    ],
+	},
-    "pr_number": null
+	"failure_reason": null
-  },
-  "failure_reason": null
 }
 ```
 

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

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

.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 |
+| Priority   | Description                                                                                        |
-|---|---|
+| ---------- | -------------------------------------------------------------------------------------------------- |
-| **High** | Architecture drift, security concern, significant duplication causing bugs, accessibility blockers |
+| **High**   | Architecture drift, security concern, significant duplication causing bugs, accessibility blockers |
-| **Medium** | Modularity issues, inconsistencies, test quality gaps |
+| **Medium** | Modularity issues, inconsistencies, test quality gaps                                              |
-| **Low** | Style issues, minor duplication, documentation 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",
+	"status": "success",
-  "summary": "Refactoring review complete",
+	"summary": "Refactoring review complete",
-  "artifacts": [],
+	"artifacts": [],
-  "phase_data": {
+	"phase_data": {
-    "project_health": "GOOD",
+		"project_health": "GOOD",
-    "issues_created": [{"number": 42, "title": "Refactor: ...", "priority": "medium"}],
+		"issues_created": [{ "number": 42, "title": "Refactor: ...", "priority": "medium" }],
-    "issues_closed": [{"number": 30, "title": "Tech debt: ...", "reason": "resolved"}]
+		"issues_closed": [{ "number": 30, "title": "Tech debt: ...", "reason": "resolved" }]
-  },
+	},
-  "failure_reason": null
+	"failure_reason": null
 }
 ```
 

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

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

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

.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

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

.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)

.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
 

.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 |
+| Priority   | Description                                                                           |
-|---|---|
+| ---------- | ------------------------------------------------------------------------------------- |
-| **High** | Architecture drift, security concern, significant duplication, accessibility blockers |
+| **High**   | Architecture drift, security concern, significant duplication, accessibility blockers |
-| **Medium** | Modularity issues, inconsistencies, test quality gaps |
+| **Medium** | Modularity issues, inconsistencies, test quality gaps                                 |
-| **Low** | Style issues, minor duplication, documentation gaps |
+| **Low**    | Style issues, minor duplication, documentation gaps                                   |
 
 ### 5. Create Refactoring Issues
 

.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

.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

.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

.gitignore

@@ -1,138 +1,23 @@
-# ---> Node
+node_modules
-# Logs
-logs
-*.log
-npm-debug.log*
-yarn-debug.log*
-yarn-error.log*
-lerna-debug.log*
-.pnpm-debug.log*
 
-# Diagnostic reports (https://nodejs.org/api/report.html)
+# Output
-report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
+.output
+.vercel
+.netlify
+.wrangler
+/.svelte-kit
+/build
 
-# Runtime data
+# OS
-pids
+.DS_Store
-*.pid
+Thumbs.db
-*.seed
-*.pid.lock
 
-# Directory for instrumented libs generated by jscoverage/JSCover
+# Env
-lib-cov
-
-# Coverage directory used by tools like istanbul
-coverage
-*.lcov
-
-# nyc test coverage
-.nyc_output
-
-# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
-.grunt
-
-# Bower dependency directory (https://bower.io/)
-bower_components
-
-# node-waf configuration
-.lock-wscript
-
-# Compiled binary addons (https://nodejs.org/api/addons.html)
-build/Release
-
-# Dependency directories
-node_modules/
-jspm_packages/
-
-# Snowpack dependency directory (https://snowpack.dev/)
-web_modules/
-
-# TypeScript cache
-*.tsbuildinfo
-
-# Optional npm cache directory
-.npm
-
-# Optional eslint cache
-.eslintcache
-
-# Optional stylelint cache
-.stylelintcache
-
-# Microbundle cache
-.rpt2_cache/
-.rts2_cache_cjs/
-.rts2_cache_es/
-.rts2_cache_umd/
-
-# Optional REPL history
-.node_repl_history
-
-# Output of 'npm pack'
-*.tgz
-
-# Yarn Integrity file
-.yarn-integrity
-
-# dotenv environment variable files
 .env
-.env.development.local
+.env.*
-.env.test.local
+!.env.example
-.env.production.local
+!.env.test
-.env.local
-
-# parcel-bundler cache (https://parceljs.org/)
-.cache
-.parcel-cache
-
-# Next.js build output
-.next
-out
-
-# Nuxt.js build / generate output
-.nuxt
-dist
-
-# Gatsby files
-.cache/
-# Comment in the public line in if your project uses Gatsby and not Next.js
-# https://nextjs.org/blog/next-9-1#public-directory-support
-# public
-
-# vuepress build output
-.vuepress/dist
-
-# vuepress v2.x temp and cache directory
-.temp
-.cache
-
-# vitepress build output
-**/.vitepress/dist
-
-# vitepress cache directory
-**/.vitepress/cache
-
-# Docusaurus cache and generated files
-.docusaurus
-
-# Serverless directories
-.serverless/
-
-# FuseBox cache
-.fusebox/
-
-# DynamoDB Local files
-.dynamodb/
-
-# TernJS port file
-.tern-port
-
-# Stores VSCode versions used for testing VSCode extensions
-.vscode-test
-
-# yarn v2
-.yarn/cache
-.yarn/unplugged
-.yarn/build-state.yml
-.yarn/install-state.gz
-.pnp.*
 
+# Vite
+vite.config.js.timestamp-*
+vite.config.ts.timestamp-*

.npmrc

@@ -0,0 +1 @@
+engine-strict=true

.prettierignore

@@ -0,0 +1,11 @@
+# Package
+node_modules
+package-lock.json
+
+# Build output
+build
+.svelte-kit
+dist
+
+# Generated
+src/lib/proto

.prettierrc

@@ -0,0 +1,15 @@
+{
+	"useTabs": true,
+	"singleQuote": true,
+	"trailingComma": "none",
+	"printWidth": 100,
+	"plugins": ["prettier-plugin-svelte"],
+	"overrides": [
+		{
+			"files": "*.svelte",
+			"options": {
+				"parser": "svelte"
+			}
+		}
+	]
+}

.vscode/extensions.json

@@ -0,0 +1,3 @@
+{
+	"recommendations": ["svelte.svelte-vscode"]
+}

README.md

@@ -1,3 +1,3 @@
 # llm-multiverse-ui
 
-Web frontend for the llm-multiverse orchestration system
+Web frontend for the llm-multiverse orchestration system

eslint.config.js

@@ -0,0 +1,23 @@
+import js from '@eslint/js';
+import svelte from 'eslint-plugin-svelte';
+import prettier from 'eslint-config-prettier';
+import ts from 'typescript-eslint';
+
+export default ts.config(
+	js.configs.recommended,
+	...ts.configs.recommended,
+	...svelte.configs.recommended,
+	prettier,
+	...svelte.configs.prettier,
+	{
+		files: ['**/*.svelte', '**/*.svelte.ts', '**/*.svelte.js'],
+		languageOptions: {
+			parserOptions: {
+				parser: ts.parser
+			}
+		}
+	},
+	{
+		ignores: ['build/', '.svelte-kit/', 'dist/']
+	}
+);

implementation-plans/_index.md

@@ -0,0 +1,5 @@
+# Implementation Plans Index
+
+| Issue | Title                                                  | Status       | Plan                         |
+| ----- | ------------------------------------------------------ | ------------ | ---------------------------- |
+| #1    | Project scaffolding: SvelteKit + Tailwind + TypeScript | IMPLEMENTING | [issue-001.md](issue-001.md) |

implementation-plans/issue-001.md

@@ -0,0 +1,66 @@
+# Issue #1: Project scaffolding: SvelteKit + Tailwind + TypeScript
+
+**Status:** IMPLEMENTING
+**Issue:** https://git.shahondin1624.de/llm-multiverse/llm-multiverse-ui/issues/1
+**Branch:** `feature/issue-1-project-scaffolding`
+
+## Summary
+
+Initialize the SvelteKit project with Svelte 5 (runes mode), Tailwind CSS, TypeScript strict mode, proper directory structure, and ESLint + Prettier configuration.
+
+## Acceptance Criteria
+
+- [ ] SvelteKit project initialized with Svelte 5 (runes mode)
+- [ ] Tailwind CSS configured and working
+- [ ] TypeScript strict mode enabled
+- [ ] Directory structure: `src/lib/`, `src/routes/`, `src/lib/components/`
+- [ ] ESLint + Prettier configured
+- [ ] `dev`, `build`, `preview`, `lint`, `format` scripts in package.json
+
+## Implementation Phases
+
+### Phase 1: SvelteKit + TypeScript Initialization
+
+Use the SvelteKit scaffolding tool (`npx sv create`) to create the project in the current directory with:
+
+- SvelteKit with Svelte 5
+- TypeScript strict mode
+- Vite as the build tool
+
+Since we're in an existing git repo with just a README, we'll scaffold into a temp directory and move files over.
+
+### Phase 2: Tailwind CSS Integration
+
+Add Tailwind CSS v4 using the SvelteKit integration:
+
+- Install `@tailwindcss/vite` and `tailwindcss`
+- Configure the Vite plugin
+- Add Tailwind CSS import to app.css
+
+### Phase 3: Directory Structure
+
+Create the required directory structure:
+
+- `src/lib/` (SvelteKit default)
+- `src/lib/components/` — reusable UI components
+- `src/lib/services/` — API/service layer (for future issues)
+- `src/routes/` (SvelteKit default)
+
+### Phase 4: ESLint + Prettier
+
+Configure ESLint and Prettier using the SvelteKit recommended setup:
+
+- `eslint` + `@eslint/js` + `eslint-plugin-svelte` + `typescript-eslint`
+- `prettier` + `prettier-plugin-svelte`
+- Add `lint` and `format` scripts to package.json
+
+### Phase 5: Verify
+
+- Run `dev` server to confirm it starts
+- Run `build` to confirm production build works
+- Run `lint` and `format` to confirm tooling works
+- Verify TypeScript strict mode is active
+
+## Deviations
+
+(none yet)

package.json

@@ -0,0 +1,34 @@
+{
+	"name": "llm-multiverse-ui",
+	"private": true,
+	"version": "0.0.1",
+	"type": "module",
+	"scripts": {
+		"dev": "vite dev",
+		"build": "vite build",
+		"preview": "vite preview",
+		"prepare": "svelte-kit sync || echo ''",
+		"check": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json",
+		"check:watch": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json --watch",
+		"lint": "eslint .",
+		"format": "prettier --write ."
+	},
+	"devDependencies": {
+		"@eslint/js": "^9.0.0",
+		"@sveltejs/adapter-auto": "^7.0.0",
+		"@sveltejs/kit": "^2.50.2",
+		"@sveltejs/vite-plugin-svelte": "^6.2.4",
+		"@tailwindcss/vite": "^4.0.0",
+		"eslint": "^9.0.0",
+		"eslint-config-prettier": "^10.0.0",
+		"eslint-plugin-svelte": "^3.0.0",
+		"prettier": "^3.0.0",
+		"prettier-plugin-svelte": "^3.0.0",
+		"svelte": "^5.51.0",
+		"svelte-check": "^4.4.2",
+		"tailwindcss": "^4.0.0",
+		"typescript": "^5.9.3",
+		"typescript-eslint": "^8.0.0",
+		"vite": "^7.3.1"
+	}
+}

src/app.css

@@ -0,0 +1 @@
+@import 'tailwindcss';

src/app.d.ts

@@ -0,0 +1,13 @@
+// See https://svelte.dev/docs/kit/types#app.d.ts
+// for information about these interfaces
+declare global {
+	namespace App {
+		// interface Error {}
+		// interface Locals {}
+		// interface PageData {}
+		// interface PageState {}
+		// interface Platform {}
+	}
+}
+
+export {};

src/app.html

@@ -0,0 +1,11 @@
+<!doctype html>
+<html lang="en">
+	<head>
+		<meta charset="utf-8" />
+		<meta name="viewport" content="width=device-width, initial-scale=1" />
+		%sveltekit.head%
+	</head>
+	<body data-sveltekit-preload-data="hover">
+		<div style="display: contents">%sveltekit.body%</div>
+	</body>
+</html>

src/lib/assets/favicon.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="107" height="128" viewBox="0 0 107 128"><title>svelte-logo</title><path d="M94.157 22.819c-10.4-14.885-30.94-19.297-45.792-9.835L22.282 29.608A29.92 29.92 0 0 0 8.764 49.65a31.5 31.5 0 0 0 3.108 20.231 30 30 0 0 0-4.477 11.183 31.9 31.9 0 0 0 5.448 24.116c10.402 14.887 30.942 19.297 45.791 9.835l26.083-16.624A29.92 29.92 0 0 0 98.235 78.35a31.53 31.53 0 0 0-3.105-20.232 30 30 0 0 0 4.474-11.182 31.88 31.88 0 0 0-5.447-24.116" style="fill:#ff3e00"/><path d="M45.817 106.582a20.72 20.72 0 0 1-22.237-8.243 19.17 19.17 0 0 1-3.277-14.503 18 18 0 0 1 .624-2.435l.49-1.498 1.337.981a33.6 33.6 0 0 0 10.203 5.098l.97.294-.09.968a5.85 5.85 0 0 0 1.052 3.878 6.24 6.24 0 0 0 6.695 2.485 5.8 5.8 0 0 0 1.603-.704L69.27 76.28a5.43 5.43 0 0 0 2.45-3.631 5.8 5.8 0 0 0-.987-4.371 6.24 6.24 0 0 0-6.698-2.487 5.7 5.7 0 0 0-1.6.704l-9.953 6.345a19 19 0 0 1-5.296 2.326 20.72 20.72 0 0 1-22.237-8.243 19.17 19.17 0 0 1-3.277-14.502 17.99 17.99 0 0 1 8.13-12.052l26.081-16.623a19 19 0 0 1 5.3-2.329 20.72 20.72 0 0 1 22.237 8.243 19.17 19.17 0 0 1 3.277 14.503 18 18 0 0 1-.624 2.435l-.49 1.498-1.337-.98a33.6 33.6 0 0 0-10.203-5.1l-.97-.294.09-.968a5.86 5.86 0 0 0-1.052-3.878 6.24 6.24 0 0 0-6.696-2.485 5.8 5.8 0 0 0-1.602.704L37.73 51.72a5.42 5.42 0 0 0-2.449 3.63 5.79 5.79 0 0 0 .986 4.372 6.24 6.24 0 0 0 6.698 2.486 5.8 5.8 0 0 0 1.602-.704l9.952-6.342a19 19 0 0 1 5.295-2.328 20.72 20.72 0 0 1 22.237 8.242 19.17 19.17 0 0 1 3.277 14.503 18 18 0 0 1-8.13 12.053l-26.081 16.622a19 19 0 0 1-5.3 2.328" style="fill:#fff"/></svg>

src/lib/index.ts

@@ -0,0 +1 @@
+// place files you want to import through the `$lib` alias in this folder.

src/routes/+layout.svelte

@@ -0,0 +1,12 @@
+<script lang="ts">
+	import favicon from '$lib/assets/favicon.svg';
+	import '../app.css';
+
+	let { children } = $props();
+</script>
+
+<svelte:head>
+	<link rel="icon" href={favicon} />
+</svelte:head>
+
+{@render children()}

src/routes/+page.svelte

@@ -0,0 +1,2 @@
+<h1 class="text-3xl font-bold text-center mt-8">LLM Multiverse UI</h1>
+<p class="text-center text-gray-600 mt-2">Orchestration interface</p>

static/robots.txt

@@ -0,0 +1,3 @@
+# allow crawling everything by default
+User-agent: *
+Disallow:

svelte.config.js

@@ -0,0 +1,16 @@
+import adapter from '@sveltejs/adapter-auto';
+
+/** @type {import('@sveltejs/kit').Config} */
+const config = {
+	kit: {
+		// adapter-auto only supports some environments, see https://svelte.dev/docs/kit/adapter-auto for a list.
+		// If your environment is not supported, or you settled on a specific environment, switch out the adapter.
+		// See https://svelte.dev/docs/kit/adapters for more information about adapters.
+		adapter: adapter()
+	},
+	vitePlugin: {
+		dynamicCompileOptions: ({ filename }) => ({ runes: !filename.includes('node_modules') })
+	}
+};
+
+export default config;

tsconfig.json

@@ -0,0 +1,20 @@
+{
+	"extends": "./.svelte-kit/tsconfig.json",
+	"compilerOptions": {
+		"rewriteRelativeImportExtensions": true,
+		"allowJs": true,
+		"checkJs": true,
+		"esModuleInterop": true,
+		"forceConsistentCasingInFileNames": true,
+		"resolveJsonModule": true,
+		"skipLibCheck": true,
+		"sourceMap": true,
+		"strict": true,
+		"moduleResolution": "bundler"
+	}
+	// Path aliases are handled by https://svelte.dev/docs/kit/configuration#alias
+	// except $lib which is handled by https://svelte.dev/docs/kit/configuration#files
+	//
+	// To make changes to top-level options such as include and exclude, we recommend extending
+	// the generated config; see https://svelte.dev/docs/kit/configuration#typescript
+}

vite.config.ts

@@ -0,0 +1,7 @@
+import { sveltekit } from '@sveltejs/kit/vite';
+import tailwindcss from '@tailwindcss/vite';
+import { defineConfig } from 'vite';
+
+export default defineConfig({
+	plugins: [tailwindcss(), sveltekit()]
+});