WIP: Staged all changes

.specify/memory/constitution.md

@@ -1,15 +1,14 @@
 <!--
 SYNC IMPACT REPORT
-Version: 1.0.0 (Initial Ratification)
+Version: 1.1.0 (Svelte Support)
 Changes:
-- Established Core Principles based on Semantic Code Generation Protocol.
-- Defined Causal Validity, Immutability, Format Compliance, DbC, and Belief State Logging.
-- Added Section: File Structure Standards.
-- Added Section: Generation Workflow.
+- Added Svelte Component semantic markup standards.
+- Updated File Structure Standards to include `.svelte` files.
+- Refined File Structure Standards to distinguish between Python Modules and Svelte Components.
 Templates Status:
-- .specify/templates/plan-template.md: ✅ Aligned (Constitution Check section refers to constitution).
-- .specify/templates/spec-template.md: ✅ Aligned (Requirements section allows for functional constraints).
-- .specify/templates/tasks-template.md: ✅ Aligned (Supports contract/test-first workflow).
+- .specify/templates/plan-template.md: ⚠ Pending (Needs update to include Component headers in checks).
+- .specify/templates/spec-template.md: ✅ Aligned.
+- .specify/templates/tasks-template.md: ⚠ Pending (Needs update to include Component definition tasks).
 -->
 # Semantic Code Generation Constitution
 
@@ -31,6 +30,8 @@ Contracts are the Source of Truth. Functions and Classes must define their purpo
 Logs must define the agent's internal state for debugging and coherence checks. We use a strict format: `logger.level(f"[{ANCHOR_ID}][{STATE}] {MESSAGE} context={...}")` to track transitions between `Entry`, `Validation`, `Action`, and `Coherence` states.
 
 ## File Structure Standards
+
+### Python Modules
 Every `.py` file must start with a Module definition header (`[DEF:module_name:Module]`) containing:
 - `@SEMANTICS`: Keywords for vector search.
 - `@PURPOSE`: Primary responsibility of the module.
@@ -39,6 +40,16 @@ Every `.py` file must start with a Module definition header (`[DEF:module_name:M
 - `@INVARIANT` & `@CONSTRAINT`: Immutable rules.
 - `@PUBLIC_API`: Exported symbols.
 
+### Svelte Components
+Every `.svelte` file must start with a Component definition header (`[DEF:ComponentName:Component]`) wrapped in an HTML comment `<!-- ... -->` containing:
+- `@SEMANTICS`: Keywords for vector search.
+- `@PURPOSE`: Primary responsibility of the component.
+- `@LAYER`: Architecture layer (UI/State/Layout).
+- `@RELATION`: Child components, Stores used, API calls.
+- `@PROPS`: Input properties.
+- `@EVENTS`: Emitted events.
+- `@INVARIANT`: Immutable UI/State rules.
+
 ## Generation Workflow
 The development process follows a strict sequence:
 1. **Analyze Request**: Identify target module and graph position.
@@ -54,4 +65,4 @@ This Constitution establishes the "Semantic Code Generation Protocol" as the sup
 - **Review**: Code reviews must verify that implementation matches the preceding contracts and that no "naked code" exists outside of semantic anchors.
 - **Compliance**: Failure to adhere to the `[DEF]` / `[/DEF]` structure constitutes a build failure.
 
-**Version**: 1.0.0 | **Ratified**: 2025-12-19 | **Last Amended**: 2025-12-19
+**Version**: 1.1.0 | **Ratified**: 2025-12-19 | **Last Amended**: 2025-12-19

.specify/templates/agent-file-template.md

@@ -0,0 +1,28 @@
+# [PROJECT NAME] Development Guidelines
+
+Auto-generated from all feature plans. Last updated: [DATE]
+
+## Active Technologies
+
+[EXTRACTED FROM ALL PLAN.MD FILES]
+
+## Project Structure
+
+```text
+[ACTUAL STRUCTURE FROM PLANS]
+```
+
+## Commands
+
+[ONLY COMMANDS FOR ACTIVE TECHNOLOGIES]
+
+## Code Style
+
+[LANGUAGE-SPECIFIC, ONLY FOR LANGUAGES IN USE]
+
+## Recent Changes
+
+[LAST 3 FEATURES AND WHAT THEY ADDED]
+
+<!-- MANUAL ADDITIONS START -->
+<!-- MANUAL ADDITIONS END -->

.specify/templates/checklist-template.md

@@ -0,0 +1,40 @@
+# [CHECKLIST TYPE] Checklist: [FEATURE NAME]
+
+**Purpose**: [Brief description of what this checklist covers]
+**Created**: [DATE]
+**Feature**: [Link to spec.md or relevant documentation]
+
+**Note**: This checklist is generated by the `/speckit.checklist` command based on feature context and requirements.
+
+<!-- 
+  ============================================================================
+  IMPORTANT: The checklist items below are SAMPLE ITEMS for illustration only.
+  
+  The /speckit.checklist command MUST replace these with actual items based on:
+  - User's specific checklist request
+  - Feature requirements from spec.md
+  - Technical context from plan.md
+  - Implementation details from tasks.md
+  
+  DO NOT keep these sample items in the generated checklist file.
+  ============================================================================
+-->
+
+## [Category 1]
+
+- [ ] CHK001 First checklist item with clear action
+- [ ] CHK002 Second checklist item
+- [ ] CHK003 Third checklist item
+
+## [Category 2]
+
+- [ ] CHK004 Another category item
+- [ ] CHK005 Item with specific criteria
+- [ ] CHK006 Final item in this category
+
+## Notes
+
+- Check items off as completed: `[x]`
+- Add comments or findings inline
+- Link to relevant resources or documentation
+- Items are numbered sequentially for easy reference

.specify/templates/plan-template.md

@@ -31,8 +31,8 @@
 
 *GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
 
-- [ ] **Causal Validity**: Do all planned modules have defined Contracts (inputs/outputs/invariants) before implementation logic?
-- [ ] **Immutability**: Are architectural layers and constraints defined in Module Headers?
+- [ ] **Causal Validity**: Do all planned modules/components have defined Contracts (inputs/outputs/props/events) before implementation logic?
+- [ ] **Immutability**: Are architectural layers and constraints defined in Module/Component Headers?
 - [ ] **Format Compliance**: Does the plan ensure all code will be wrapped in `[DEF]` anchors?
 - [ ] **Belief State**: Is logging planned to follow the `Entry` -> `Validation` -> `Action` -> `Coherence` state transition model?
 

.specify/templates/tasks-template.md

@@ -93,7 +93,9 @@ Examples of foundational tasks (adjust based on your project):
 - [ ] T014 [P] [US1] Define [Service] Module Header & Contracts in src/services/[service].py
 - [ ] T015 [US1] Implement [Service] logic satisfying contracts (depends on T012)
 - [ ] T016 [US1] Define [endpoint] Contracts & Logic in src/[location]/[file].py
-- [ ] T017 [US1] Verify `[DEF]` syntax and Belief State logging compliance
+- [ ] T017 [US1] Define [Component] Header (Props/Events) in frontend/src/components/[Component].svelte
+- [ ] T018 [US1] Implement [Component] logic satisfying contracts
+- [ ] T019 [US1] Verify `[DEF]` syntax and Belief State logging compliance
 
 **Checkpoint**: At this point, User Story 1 should be fully functional and testable independently
 
@@ -107,15 +109,16 @@ Examples of foundational tasks (adjust based on your project):
 
 ### Tests for User Story 2 (OPTIONAL - only if tests requested) ⚠️
 
-- [ ] T018 [P] [US2] Contract test for [endpoint] in tests/contract/test_[name].py
-- [ ] T019 [P] [US2] Integration test for [user journey] in tests/integration/test_[name].py
+- [ ] T020 [P] [US2] Contract test for [endpoint] in tests/contract/test_[name].py
+- [ ] T021 [P] [US2] Integration test for [user journey] in tests/integration/test_[name].py
 
 ### Implementation for User Story 2
 
-- [ ] T020 [P] [US2] Define [Entity] Module Header & Contracts in src/models/[entity].py
-- [ ] T021 [P] [US2] Implement [Entity] logic satisfying contracts
-- [ ] T022 [US2] Define [Service] Module Header & Contracts in src/services/[service].py
-- [ ] T023 [US2] Implement [Service] logic satisfying contracts
+- [ ] T022 [P] [US2] Define [Entity] Module Header & Contracts in src/models/[entity].py
+- [ ] T023 [P] [US2] Implement [Entity] logic satisfying contracts
+- [ ] T024 [US2] Define [Service] Module Header & Contracts in src/services/[service].py
+- [ ] T025 [US2] Implement [Service] logic satisfying contracts
+- [ ] T026 [US2] Define [Component] Header & Logic in frontend/src/components/[Component].svelte
 
 **Checkpoint**: At this point, User Stories 1 AND 2 should both work independently
 
@@ -129,14 +132,15 @@ Examples of foundational tasks (adjust based on your project):
 
 ### Tests for User Story 3 (OPTIONAL - only if tests requested) ⚠️
 
-- [ ] T024 [P] [US3] Contract test for [endpoint] in tests/contract/test_[name].py
-- [ ] T025 [P] [US3] Integration test for [user journey] in tests/integration/test_[name].py
+- [ ] T027 [P] [US3] Contract test for [endpoint] in tests/contract/test_[name].py
+- [ ] T028 [P] [US3] Integration test for [user journey] in tests/integration/test_[name].py
 
 ### Implementation for User Story 3
 
-- [ ] T026 [P] [US3] Define [Entity] Module Header & Contracts in src/models/[entity].py
-- [ ] T027 [US3] Define [Service] Module Header & Contracts in src/services/[service].py
-- [ ] T028 [US3] Implement logic for [Entity] and [Service] satisfying contracts
+- [ ] T029 [P] [US3] Define [Entity] Module Header & Contracts in src/models/[entity].py
+- [ ] T030 [US3] Define [Service] Module Header & Contracts in src/services/[service].py
+- [ ] T031 [US3] Implement logic for [Entity] and [Service] satisfying contracts
+- [ ] T032 [US3] Define [Component] Header & Logic in frontend/src/components/[Component].svelte
 
 **Checkpoint**: All user stories should now be independently functional
 
@@ -179,9 +183,10 @@ Examples of foundational tasks (adjust based on your project):
 ### Within Each User Story
 
 - Tests (if included) MUST be written and FAIL before implementation
-- Module Headers & Contracts BEFORE Implementation (Causal Validity)
+- Module/Component Headers & Contracts BEFORE Implementation (Causal Validity)
 - Models before services
 - Services before endpoints
+- Components before Pages
 - Story complete before moving to next priority
 
 ### Parallel Opportunities