fete/.specify/memory/constitution.md

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