fete/.specify/memory/constitution.md

<!--
  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.
- Feature specs, research, and plans live in `specs/NNN-feature-name/`
  (spec-kit format). Cross-cutting research goes to
  `.specify/memory/research/`, cross-cutting plans to
  `.specify/memory/plans/`.
- 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