Block a user
As a reader I want undated and imprecisely-dated letters to be honestly labelled in browse views so I always understand a document's date position
Sara Holt — Senior QA Engineer
Observations
- The test plan is unusually well-layered for an issue this size, and it respects the pyramid: Mockito unit for
resolveSort, **Testcontainers…
As the archive owner I want the normalizer's canonical exports to carry every field the importer needs (file, date-range end, person ids in the tree) so the loaders have a complete, joinable contract
Nora Steiner ("NullX") — Application Security Engineer
This is an offline Python ETL tool with no network, no auth surface, and no user-supplied input at runtime — the spreadsheet is trusted…
As the archive owner I want the importer rebuilt as modular loaders over the normalizer's canonical exports, so dates/people/tags import correctly and re-runs are idempotent
Nora "NullX" Steiner — Application Security Engineer
Observations
- The "port the guards before deleting the old method" instruction is exactly right and is the single most important…
As the archive owner I want one Flyway migration and domain model carrying all import/precision/attribution/identity fields so downstream phases compile against a single, collision-free schema
Sara Holt — Senior QA Engineer
This is a migration-and-mapping issue, so the test strategy lives almost entirely at the integration layer against real Postgres. The acceptance criteria are…
As a reader I want a clean persons directory so I'm not overwhelmed by unconfirmed import entries
Developer — Felix Brandt (@felixbrandt)
Observations
- The null-avatar crash is real and exactly as described.
+page.svelte:132is `{person.firstName ? person.firstName[0] :…
As the archive owner I want the normalizer's canonical exports to carry every field the importer needs (file, date-range end, person ids in the tree) so the loaders have a complete, joinable contract
Sara Holt — Senior QA Engineer
I verified the acceptance criteria against the actual parser. One AC scenario fails on its own example today, and the other two need negative cases added.
###…
As a reader I want undated and imprecisely-dated letters to be honestly labelled in browse views so I always understand a document's date position
Nora Steiner ("NullX") — Application Security Engineer
Observations
- The
/api/documents/searchendpoint is a read-only GET and correctly carries no@RequirePermissionwrite…
As a reader I want imprecise and unknown dates rendered honestly (e.g. "Juni 1916", "ca. 1916", "Datum unbekannt") so a document never shows a precision the data doesn't have
Nora "NullX" Steiner — Application Security Engineer
Observations
- The one genuine attack surface here is
meta_date_raw— untrusted verbatim spreadsheet text rendered into the…
As the archive owner I want the importer rebuilt as modular loaders over the normalizer's canonical exports, so dates/people/tags import correctly and re-runs are idempotent
Felix Brandt — Senior Fullstack Developer
Observations
- The TDD plan is the right shape:
CanonicalSheetReaderfirst (no DB), then four loaders with the owning service mocked under…
As the archive owner I want one Flyway migration and domain model carrying all import/precision/attribution/identity fields so downstream phases compile against a single, collision-free schema
Nora Steiner ("NullX") — Application Security Engineer
Schema-and-entity issue with no new endpoints, so the attack surface is small. My focus is on the integrity constraints (these are…
As a reader I want undated and imprecisely-dated letters to be honestly labelled in browse views so I always understand a document's date position
Felix Brandt — Senior Fullstack Developer
Observations
- The TDD ordering is already correct in the spec:
resolveSortparameterized over{ASC, DESC}assertingNullHandling.NULLS_LAST…
As a reader I want imprecise and unknown dates rendered honestly (e.g. "Juni 1916", "ca. 1916", "Datum unbekannt") so a document never shows a precision the data doesn't have
Felix Brandt — Senior Fullstack Developer
Observations
- The formatter is a pure, branch-heavy function — ideal TDD target.
documentDate.spec.tswith one failing test per precision…
As the archive owner I want the normalizer's canonical exports to carry every field the importer needs (file, date-range end, person ids in the tree) so the loaders have a complete, joinable contract
Felix Brandt — Senior Fullstack Developer
I traced all four files and ran the AC's own date example. There's a blocker hiding in the Gap 2 acceptance criterion. TDD red-first on every…
As a reader I want a clean persons directory so I'm not overwhelmed by unconfirmed import entries
Architect — Markus Keller (@mkeller)
Observations
- The corrected pagination design is sound. I verified
document/DocumentSearchResult.javais exactly the hand-written record this issue…
As the archive owner I want one Flyway migration and domain model carrying all import/precision/attribution/identity fields so downstream phases compile against a single, collision-free schema
Felix Brandt — Senior Fullstack Developer
Clean, well-scoped schema-only issue. The TDD path here is mostly integration-level (migration + entity mapping), and I want to flag a couple of…
As the archive owner I want the importer rebuilt as modular loaders over the normalizer's canonical exports, so dates/people/tags import correctly and re-runs are idempotent
Markus Keller — Senior Application Architect
Observations
- The dependency DAG is real and correctly named: documents need persons + tags; tree needs persons. I verified `RelationshipServi…
As a reader I want undated and imprecisely-dated letters to be honestly labelled in browse views so I always understand a document's date position
Markus Keller — Senior Application Architect
Observations
- The spec correctly identifies that this is a read-path correctness fix with no schema impact — "Adds NO migration." I…
As a reader I want imprecise and unknown dates rendered honestly (e.g. "Juni 1916", "ca. 1916", "Datum unbekannt") so a document never shows a precision the data doesn't have
Markus Keller — Senior Application Architect
Observations
- Scope is correct: this is a presentation-only consumer of #671's schema and #669's data. No migration, no enum, no DB concern…
As the archive owner I want the normalizer's canonical exports to carry every field the importer needs (file, date-range end, person ids in the tree) so the loaders have a complete, joinable contract
Markus Keller — Senior Application Architect
I read documents.py, dates.py, writers.py, persons.py, and persons_tree.py to ground this. The three gaps are real and the fix direction…
As the archive owner I want one Flyway migration and domain model carrying all import/precision/attribution/identity fields so downstream phases compile against a single, collision-free schema
Markus Keller — Senior Application Architect
This is exactly the right move. Consolidating three competing V69s into one owned migration is textbook "get the schema right before application…