Migrate project artifacts to spec-kit format
- Move cross-cutting docs (personas, design system, implementation phases, Ideen.md) to .specify/memory/ - Move cross-cutting research and plans to .specify/memory/research/ and .specify/memory/plans/ - Extract 5 setup tasks from spec/setup-tasks.md into individual specs/001-005/spec.md files with spec-kit template format - Extract 20 user stories from spec/userstories.md into individual specs/006-026/spec.md files with spec-kit template format - Relocate feature-specific research and plan docs into specs/[feature]/ - Add spec-kit constitution, templates, scripts, and slash commands - Slim down CLAUDE.md to Claude-Code-specific config, delegate principles to .specify/memory/constitution.md - Update ralph.sh with stream-json output and per-iteration logging - Delete old spec/ and docs/agents/ directories - Gitignore Ralph iteration JSONL logs Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
134
.specify/memory/constitution.md
Normal file
134
.specify/memory/constitution.md
Normal file
@@ -0,0 +1,134 @@
|
||||
<!--
|
||||
Sync Impact Report
|
||||
==================
|
||||
Version change: 0.0.0 (template) -> 1.0.0
|
||||
Modified principles: N/A (initial adoption)
|
||||
Added sections:
|
||||
- 6 Core Principles (Privacy, Methodology, API-First, Quality, Dependencies, Accessibility)
|
||||
- Tech Stack & Constraints
|
||||
- Development Workflow
|
||||
- Governance
|
||||
Removed sections: N/A
|
||||
Templates requiring updates:
|
||||
- .specify/templates/plan-template.md: OK (Constitution Check section already generic)
|
||||
- .specify/templates/spec-template.md: OK (no constitution-specific references)
|
||||
- .specify/templates/tasks-template.md: OK (no constitution-specific references)
|
||||
- .specify/templates/checklist-template.md: OK (no constitution-specific references)
|
||||
- .specify/templates/commands/*.md: N/A (no command files exist)
|
||||
Follow-up TODOs: none
|
||||
-->
|
||||
|
||||
# fete Constitution
|
||||
|
||||
## Core Principles
|
||||
|
||||
### I. Privacy by Design
|
||||
|
||||
Privacy is a design constraint, not a feature. It shapes every decision from
|
||||
the start.
|
||||
|
||||
- The system MUST NOT include analytics, telemetry, or tracking of any kind.
|
||||
- The server MUST NOT log PII or IP addresses.
|
||||
- Every feature MUST critically evaluate what data is necessary; only data
|
||||
absolutely required for functionality may be stored.
|
||||
- External dependencies that phone home (CDNs, Google Fonts, tracking-capable
|
||||
libraries) MUST NOT be used.
|
||||
|
||||
### II. Test-Driven Methodology
|
||||
|
||||
Development follows a strict Research -> Spec -> Test -> Implement -> Review
|
||||
sequence. No shortcuts.
|
||||
|
||||
- Tests MUST be written before implementation (TDD). The Red -> Green ->
|
||||
Refactor cycle is strictly enforced.
|
||||
- No implementation code may be written without a specification.
|
||||
- E2E tests are mandatory for every frontend user story.
|
||||
- When a setup task or user story is completed, its acceptance criteria MUST
|
||||
be checked off in the corresponding spec file before committing.
|
||||
|
||||
### III. API-First Development
|
||||
|
||||
The OpenAPI spec (`backend/src/main/resources/openapi/api.yaml`) is the
|
||||
single source of truth for the REST API contract.
|
||||
|
||||
- Endpoints and schemas MUST be defined in the spec first.
|
||||
- Backend interfaces and frontend types MUST be generated from the spec
|
||||
before writing implementation code.
|
||||
- Response schemas MUST include `example:` fields for mock generation and
|
||||
documentation.
|
||||
|
||||
### IV. Simplicity & Quality
|
||||
|
||||
KISS and grugbrain. Engineer it properly, but do not over-engineer.
|
||||
|
||||
- No workarounds. Always fix the root cause, even if it takes longer.
|
||||
- Technical debt MUST be addressed immediately; it MUST NOT accumulate.
|
||||
- Refactoring is permitted freely as long as it does not alter the
|
||||
fundamental architecture.
|
||||
- Every line of code MUST be intentional and traceable to a requirement.
|
||||
No vibe coding.
|
||||
|
||||
### V. Dependency Discipline
|
||||
|
||||
Every dependency is a deliberate, justified decision.
|
||||
|
||||
- A dependency MUST provide substantial value and a significant portion of
|
||||
its features MUST actually be used.
|
||||
- Dependencies MUST be actively maintained and open source (copyleft is
|
||||
acceptable under GPL).
|
||||
- Dependencies that phone home or compromise user privacy MUST NOT be
|
||||
introduced.
|
||||
|
||||
### VI. Accessibility
|
||||
|
||||
Accessibility is a baseline requirement, not an afterthought.
|
||||
|
||||
- All frontend components MUST meet WCAG AA contrast requirements.
|
||||
- Semantic HTML and ARIA attributes MUST be used where appropriate.
|
||||
- The UI MUST be operable via keyboard navigation.
|
||||
|
||||
## Tech Stack & Constraints
|
||||
|
||||
- **Backend:** Java 25 (LTS, SDKMAN), Spring Boot 3.5.x, Maven with wrapper
|
||||
- **Frontend:** Vue 3, TypeScript, Vue Router, Vite, Vitest, ESLint, Prettier
|
||||
- **Testing:** Playwright + MSW for E2E, Vitest for unit tests, JUnit for
|
||||
backend
|
||||
- **Architecture:** Hexagonal (single Maven module, package-level separation),
|
||||
base package `de.fete`
|
||||
- **State management:** Composition API (`ref`/`reactive`) + localStorage;
|
||||
no Pinia
|
||||
- **Database:** No JPA until setup task T-4 is reached
|
||||
- **Design system:** Electric Dusk + Sora (see `.specify/memory/design-system.md`)
|
||||
- **Deployment:** Dockerfile provided; docker-compose example in README
|
||||
|
||||
## Development Workflow
|
||||
|
||||
- Document integrity: when a decision is revised, add an addendum with
|
||||
rationale. Never rewrite or delete the original decision.
|
||||
- The visual design system in `.specify/memory/design-system.md` is authoritative. All
|
||||
frontend implementation MUST follow it.
|
||||
- Research reports go to `docs/agents/research/`, implementation plans to
|
||||
`docs/agents/plan/`.
|
||||
- Conversation and brainstorming in German; code, comments, commits, and
|
||||
documentation in English.
|
||||
- Documentation lives in the README. No wiki, no elaborate docs site.
|
||||
|
||||
## Governance
|
||||
|
||||
This constitution supersedes all ad-hoc practices. It is the authoritative
|
||||
reference for project principles and constraints.
|
||||
|
||||
- **Amendment procedure:** Amendments require documentation of the change,
|
||||
rationale, and an updated version number. The original text MUST be
|
||||
preserved via addendum, not overwritten.
|
||||
- **Versioning:** The constitution follows semantic versioning. MAJOR for
|
||||
principle removals or redefinitions, MINOR for additions or material
|
||||
expansions, PATCH for clarifications and wording fixes.
|
||||
- **Compliance review:** All code changes and architectural decisions MUST
|
||||
be verified against these principles. The plan template's "Constitution
|
||||
Check" gate enforces this before implementation begins.
|
||||
- **Agent governance:** The agent works autonomously on implementation tasks.
|
||||
Architectural decisions, fundamental design questions, tech stack choices,
|
||||
and dependency selections MUST be proposed and approved before proceeding.
|
||||
|
||||
**Version**: 1.0.0 | **Ratified**: 2026-03-06 | **Last Amended**: 2026-03-06
|
||||
Reference in New Issue
Block a user