Files

nitrix 6aeb4b8bca 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>

2026-03-06 20:19:41 +01:00

5.5 KiB

Raw Blame History

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

5.5 KiB Raw Blame History