Contributing-patterns

← Developer-manual

8. Contributing-patterns

Hvordan vi arbejder med kode-ændringer på TesseraCMS. Disse konventioner er ikke håndhævet maskinelt — de er social.

pm-workflow

Vi tracker alt non-trivielt arbejde via slash-commands der mutere changes.md (én root-fil med alle tasks):

  1. /pm-plan — bruger beskriver hvad de vil have lavet → assistant foreslår implementation-plan → enighed nås → task logges som specified
  2. /pm-approve <id> — bruger godkender planen → task moves til approved
  3. /pm-implement — assistant implementerer alle approved tasks → moves til implemented
  4. /pm-tested <id> — bruger har testet → moves til tested (terminal state)

Andre commands:

  • /pm-tasks — list alle (med status) eller vis en specifik
  • /pm-cleanup — auto-detect overlap, stale tasks, status-mismatch, foreslå merges/rejects

Hvorfor: planning fanger forkerte antagelser FØR vi skriver kode. Approve er en gate så bruger har ejerskab. Tested er sandt termini — ingen reopen.

Commit-style

Vi følger Conventional Commits:

<type>(<scope>): <subject>

<body>

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Types vi bruger:

  • feat — ny funktionalitet
  • fix — bugfix
  • refactor — restruktur uden ny funktion
  • docs — kun docs-ændringer
  • chore — build/tooling/seed-data

Scopes (eksempler): admin, auth, backups, engine, social, docs. Hold dem korte og meaningful.

Subject: max 70 tegn, lowercase efter type+scope, ingen punktum, imperativ-form ("add" ikke "added").

Branch-naming

Vi arbejder typisk direkte på master (lille team, høj cadence). Når vi gør feature-branches:

  • feat/<task-id>-<short-description> — fx feat/TASK-119-docs-sitetype
  • fix/<task-id>-<short> — fx fix/TASK-141-auth-guard-race

Ok at gå mest direct på master når changes er små + tested. Brug branch + PR når der er reason for review eller du vil bevare incremental state.

Code-style

  • Engelsk for new code — type-navne, field-navne, file-navne, code-comments. Display-strings bruger LocalizedString { en, da? }
  • No hardcoded UI-strings — alle bruger-vendte strings gennem useTranslate() / makeServerTranslate() med keys i src/i18n/locales/<locale>.ts
  • Default no comments — kun WHY-comments hvor det ikke er obvious. Aldrig WHAT-comments (koden selv er WHAT)
  • No useless abstractions — ikke design for hypotetiske requirements. Tre similar lines is fine.
  • No error-handling for impossible cases — trust internal code. Valider kun ved system-boundaries (user input, external APIs)

Memory-system

Claude-sessioner husker konventioner via ~/.claude/projects/.../memory/. Når du etablerer en ny norm der senere sessioner skal kende (fx "vi committer aldrig uden eksplicit godkendelse"), bør den committes til memory via Claude. Ellers glemmes den.

Eksempler på persisteret memory:

  • "Ask before push" — aldrig git push/git commit uden brugerens per-turn confirmation
  • "Temp files in sharefolder" — alt usikkert/temp i sharefolder/
  • "i18n everywhere" — DoD: alle UI-strings via translate-keys
  • "Create redirects to list" — efter Create-flow i admin → redirect til oversigt, ikke edit-page

Definition of Done

En task er IKKE done før ALLE disse:

  • No hardcoded UI-strings — verificeret med grep -nE '">[A-ZÆØÅ][a-zæøå]' new-file.tsx
  • TypeScript clean — npx tsc --noEmit exit 0
  • Tested locally når feasible (dev-server compiler + key-flow virker)
  • Tenant-aware — ingen hardcoded tenant-slugs; alt storage scoped på PartitionKey
  • Engine vs sitetype boundary respected — engine importer aldrig fra sitetypes
  • Memory updated hvis en ny project-convention emerges som future sessions bør know

Code-review (når vi gør PR-baseret)

Når en PR åbnes, reviewer kigger på:

  1. Does it match the plan? — tjek changes.md task; afvigelser skal nævnes i PR-beskrivelsen
  2. Lag-grænse respecteret? — engine vs sitetype
  3. i18n compliance? — search efter hardcoded strings
  4. Typecheck clean? — CI failer hvis ikke
  5. Sensitive data? — ingen secrets, ingen prod-mail-recipients (vi har en regel: aldrig produktion-mail-sends under dev)

Godkendelse → merge til master → CI deployer.

Documentation

  • CLAUDE.md — top-level project-instructions; opdateres når nye konventioner ratificeres
  • docs/architecture.md — deep-dive på system-design; opdateres ved større ændringer
  • docs/aca-setup-runbook.md — operational runbook for Azure-setup
  • changes.md — per-task log; opdateres af pm-skills
  • src/sitetypes/<x>/README.md — placeholder for nu; tilføj hvis sitetype får sin egen story

Ingen formel doc-style — markdown er fint. Hold concise; long docs bliver ikke læst.

← Testing og deployment