Schema: record completeness flag and per-field verified-absent markers

[DutchJaFO]

Add two complementary data quality fields to quote, character, source, and person records.

The problem

Currently null on a nullable field is ambiguous: it means both "not yet investigated" and "we looked and no value exists." Enrichment providers cannot distinguish between the two, so they repeatedly attempt to fill fields that have no answer. The UI also cannot distinguish records that are genuinely finished from records that just haven't been worked on yet.

Two new fields

isComplete: bool (default false)

A human-set flag meaning "I have reviewed this record and I am satisfied with it." Set manually in the management UI — never set automatically by enrichment or import.

• Enrichment providers skip records where isComplete: true
• The quotes list UI gains a filter: "Show incomplete only" (default on during data maintenance sessions)
• Stats endpoint (Stats endpoint: GET /api/v1/stats #48) and statistics page (Statistics: dedicated stats page and extended API #54) report completeness counts per type
• Import always sets isComplete: false regardless of the source payload

noValueKnown: string[] (default [])

A list of field names that have been confirmed as having no findable value. Examples:

"noValueKnown": ["date", "character"]

Meaning: a date for this quote has been researched and genuinely does not exist in any source; and there is no named character (e.g. it is a voiceover or narration).

• Enrichment providers skip any field listed here — do not attempt a lookup
• The UI shows a "No value known" indicator next to each affected field instead of leaving it blank
• Users can set and unset entries via the management UI per field
• A record can be isComplete: false with some noValueKnown entries — still being worked on, but certain fields are confirmed empty
• A record can be isComplete: true with noValueKnown entries — fully reviewed; those fields just have no answer

UI behaviour

In the quote detail/edit page:

• Each nullable field (date, character, author, genres, etc.) has a "Mark as no value known" action alongside its input
• Fields with a noValueKnown entry render a distinct visual state (e.g. a strikethrough placeholder or a "—" badge) rather than an empty input
• A "Mark complete" button sets isComplete: true; the record is visually distinguished in the list

Applies to

All four entity types: quotes, characters, sources, persons. The specific fields that are meaningful to mark as noValueKnown differ by type (e.g. date is relevant on all; character only on quotes).

Notes

• Both fields are stored as columns in SQLite (IsComplete BIT NOT NULL DEFAULT 0, NoValueKnown TEXT NOT NULL DEFAULT '[]' as a JSON array)
• Enrichment scaffold (Enrichment script: fill missing quote fields using TMDB, Open Library, and Wikidata #19) must be updated to check both fields before attempting any lookup
• Stats endpoint (Stats endpoint: GET /api/v1/stats #48): add complete and incomplete counts to byType; add noValueKnown field frequency counts

[DutchJaFO]

Scope reconciliation before implementation

This issue's text predates both #64 (conflict resolution) and #143 (migration ownership/baseline split) — neither existed when it was written. Reconciled before planning:

• IsComplete/NoValueKnown must survive an existing row being rewritten by Import conflict resolution: per-import policy with configurable defaults #64's conflict engine. newest-wins/merge-ours/merge-theirs all update an existing quote row on every reseed/reimport that hits a duplicate Id — Import conflict resolution: per-import policy with configurable defaults #64 didn't exist yet when this issue was written, so it never addressed what happens to these new columns on that path. Decided: both columns are excluded entirely from the UPDATE path; "Import always sets isComplete: false" now applies only to a genuinely new row's first insert. Silently resetting a human's completed review on every reseed would defeat the point of the feature.
• Stats/counts reporting is deferred to Stats endpoint: GET /api/v1/stats #48 (stats endpoint) — still open, not started, so there's nothing to wire completeness counts into yet. This issue ships schema and model changes only, matching how enrichment (Enrichment script: fill missing quote fields using TMDB, Open Library, and Wikidata #19) and the Blazor UI (v3) are already deferred in the original text.
• No public API exposure in this issue — IsComplete/NoValueKnown stay database-only, not added to QuoteResponse or any other response DTO, until a management API/UI actually needs them.
• Migration goes through QuotinatorMigrations.cs (the Fresh-database baseline schema + Data/Engine migration ownership split #143 mechanism: numbered migration, baseline updated in the same commit, schema-drift tests enforced) rather than a generic "schema migration" as originally written.
• NoValueKnown ships on all four tables including Characters (whose only field, Name, is required — no current candidate for "no value known") — kept anyway for consistency and to avoid a later schema change if Characters ever gains a nullable field.

Full detail: docs/milestones/data-import-sources/55-record-completeness-plan.md.

[DutchJaFO]

Released in v1.8.0.

#	Status	Requirement	Method	Verification
1	✅	IsComplete/NoValueKnown columns added to all four tables, baseline matches incremental replay	Unit test	DatabaseInitializerTests.Baseline_And_IncrementalReplay_ProduceIdenticalEngineSchema/...AcceptSameCheckConstraintValues
2	✅	A brand-new row defaults to IsComplete = false, NoValueKnown = []	Unit test	ConflictResolutionTests.Seed_FreshQuote_DefaultsIsCompleteFalseAndNoValueKnownEmpty, QuoteImportServiceTests.ImportAsync_FreshDatabase_DefaultsIsCompleteFalseAndNoValueKnownEmpty
3-4	✅	An existing row's completeness fields survive updates via both seeding and the live import endpoint	Unit test	ConflictResolutionTests.UpdateOnNewestWins_NeverResetsIsCompleteOrNoValueKnown, QuoteImportServiceTests.ImportAsync_ExistingRowMarkedComplete_SurvivesReimportUnchanged
5	✅	NoValueKnown round-trips correctly as a JSON TEXT column	Unit test	DapperSetupTests.JsonHandler_RegisteredByAssemblySetup_RoundTripsListThroughJsonColumn and siblings
6-8	N/A	Stats/enrichment/UI hooks deferred	N/A	Deferred to #48/#19/#11
9-10	✅	T1/T2 — VS and Docker smoke tests, migration applies cleanly	Live	Confirmed 2026-07-05