chore(#361): Candidate-Schema-Spike (Phase 1 von Day-Planner #360) #362

Merged

admin-mrrm merged 1 commit from chore/361-candidate-schema-spike into main

2026-05-20 20:56:00 +02:00

admin-mrrm commented

2026-05-20 20:34:18 +02:00

Owner

Summary

Phase 1 von Epic #360 (Day-Planner). Spike legt das Candidate-Modell als Unit-of-Planning zwischen Sources und Planner fest, damit kein weiteres Direct-Write-Anti-Pattern entsteht.

apps/api/src/modules/candidates/candidates.schema.ts — Drizzle-Tabelle mit Source-Ref, Lifecycle-State-Enum, typed Refs (lists/mail/tracking), Planungs-Constraints, Planner-Result-Feldern, Completion-Policy-Enum
Drizzle-Migration 0017_slim_lady_bullseye.sql (deployable; Tabelle wird noch nicht beschrieben)
UNIQUE(owner_sub, source, source_ref) für Idempotenz pro Source
ADR docs/adr/0001-candidate-model.md mit Begruendungen zu Direct-Write-Vermeidung, Cardinality (1 Source-Item -> n Candidates), Completion-Policy-Modi, Title-Snapshot, Refs-vs-JSONB, Lifecycle-Enum-vs-Flags, Source-Feedback-Pattern
Schema-Sanity-Tests (Insert + Defaults + Unique-Constraint-Verstoss) — 4 Tests, gruen

Out-of-scope (siehe Issue)

Planner-Logik, API-Endpoints, UI, Datenmigration bestehender Listen, weitere Source-Producer

Test plan

pnpm typecheck -> gruen
pnpm lint -> gruen
pnpm test (Unit, 365 Tests) -> gruen
pnpm test:integration (60 Tests inkl. 4 neue) -> gruen
Migration auf dev-neu ausfuehrbar (in Deploy zu pruefen)

Closes #361

## Summary Phase 1 von Epic #360 (Day-Planner). Spike legt das Candidate-Modell als Unit-of-Planning zwischen Sources und Planner fest, damit kein weiteres Direct-Write-Anti-Pattern entsteht. - `apps/api/src/modules/candidates/candidates.schema.ts` — Drizzle-Tabelle mit Source-Ref, Lifecycle-State-Enum, typed Refs (lists/mail/tracking), Planungs-Constraints, Planner-Result-Feldern, Completion-Policy-Enum - Drizzle-Migration `0017_slim_lady_bullseye.sql` (deployable; Tabelle wird noch nicht beschrieben) - UNIQUE(owner_sub, source, source_ref) für Idempotenz pro Source - ADR `docs/adr/0001-candidate-model.md` mit Begruendungen zu Direct-Write-Vermeidung, Cardinality (1 Source-Item -> n Candidates), Completion-Policy-Modi, Title-Snapshot, Refs-vs-JSONB, Lifecycle-Enum-vs-Flags, Source-Feedback-Pattern - Schema-Sanity-Tests (Insert + Defaults + Unique-Constraint-Verstoss) — 4 Tests, gruen ## Out-of-scope (siehe Issue) - Planner-Logik, API-Endpoints, UI, Datenmigration bestehender Listen, weitere Source-Producer ## Test plan - [x] `pnpm typecheck` -> gruen - [x] `pnpm lint` -> gruen - [x] `pnpm test` (Unit, 365 Tests) -> gruen - [x] `pnpm test:integration` (60 Tests inkl. 4 neue) -> gruen - [ ] Migration auf `dev-neu` ausfuehrbar (in Deploy zu pruefen) Closes #361

admin-mrrm added 1 commit

2026-05-20 20:34:18 +02:00

chore(#361 ): Candidate-Schema-Spike (Phase 1 von Day-Planner-Epic #360 )

continuous-integration/drone/push Build is passing

Details

continuous-integration/drone/pr Build is passing

Details

50cad564a3

Führt das Candidate-Modell als Unit-of-Planning zwischen Sources (Mail,
Tracking, Calendar, …) und Output (Todo, Tagesplan) ein, damit Phase 3+
nicht erneut das Direct-Write-Anti-Pattern zementiert.

- candidates-Tabelle mit Source-Ref, Lifecycle-State, typed Refs,
  Planungs-Constraints, Planner-Ergebnis und Completion-Policy
- UNIQUE(owner_sub, source, source_ref) für Idempotenz
- Drizzle-Migration 0017_slim_lady_bullseye.sql (deployable; Tabelle
  wird noch nicht beschrieben, Phase 2 macht das mit Tracking-Refactor)
- ADR 0001 mit Begründungen zu Direct-Write, Cardinality,
  Completion-Policy, Title-Snapshot, Refs vs JSONB, Lifecycle-Enum
  und Source-Feedback-Pattern
- Schema-Sanity-Tests: Insert + Unique-Constraint-Verstoß

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