Spec, research, data model, API contract, implementation plan, and task breakdown for the public event detail page. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
5.6 KiB
5.6 KiB
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.mdis 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