Kjell Tore Guttormsen
6dce4355be
A sixth golden directory, never an edit to the five that exist. Its only difference from the SEGMENTED_V1 golden is the added `okf_version` root key -- measured by diffing the two -- which is exactly what the profile is for and nothing else moved. Modelled on tests/test_segmented_golden.py rather than test_golden.py's `materialize_case`, which is Door A only: it drives materialize_bundle from a manifest and this bundle comes through Door B's inbox. The plan's pointer to an "existing goldens list" in test_golden.py is stale -- that file holds only the Door A parametrize, and `ingest-golden-segmented` is not in it either. Door B goldens carrying their own test file is the established pattern, and this one asserts the five priors are untouched from its own side. CROSS-BUNDLE IDENTITY (PM decision B1) is settled BEFORE this pin, not after. Byte-pinning a bundle carrying `okf_version` is where its concept IDs stop being adjustable: a concept ID is bundle-local and stable, identity across bundles is the tuple (bundle_id, concept_id), and there is no cross-bundle link form in v0.2. Asserted -- every concept carries its bundle id, so the tuple is readable from one document, and no foreign bundle id appears anywhere. Two defects in these tests, both found by running them: - `parse_frontmatter` takes a Path and returns the dict; three call sites had it wrong. - The cross-bundle check used `b-golden-segmented` as the foreign id, which is a PREFIX of this bundle's own id. It failed on every file for the wrong reason and would have read as "a cross-bundle reference was emitted". Now a foreign id that is not a prefix, with a known-positive half asserting the bundle does name its own id -- so the check is looking at content that could have carried one. Negative control: changing one byte of the golden's `okf_version` turns the pin red. `okf_version` and `bundle_id` are fixture DATA read from the case, never constants in the test -- the value belongs to catalog (E1). Suite 931 -> 941. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| ingest-golden-file | ||
| ingest-golden-http | ||
| ingest-golden-okf-v0-2 | ||
| ingest-golden-segmented | ||
| ingest-golden-segmented-okf-v0-2 | ||
| ingest-golden-sql | ||
| README.md | ||
Golden extractions (ingest-spec §11)
One directory per case, ingest-golden-{source type}/, each containing:
| Entry | Meaning |
|---|---|
manifest.json |
The manifest under test. |
fixture/ |
The source content (CSV catalogue, sqlite database, or mock payloads). |
ingested-at.txt |
The fixed timestamp, one line, §5 format. |
expected-bundle/ |
The expected materialized bundle, compared byte for byte. |
ingest-golden-file and ingest-golden-sql are the conformance MUSTs. The
http source type is an OPTIONAL extension point (spec §1); this repository
implements it, and ingest-golden-http exercises it against the mock payloads
in its fixture/ directory — the conformance suite never opens a socket and
runs without credentials (§11). For the sql case, the test sets the
OKF_GOLDEN_SQL_DB environment variable to the fixture database path; for the
http case, the injected mock transport serves fixture/{query path}.
The suite (tests/test_golden.py) re-materializes each case into a fresh
directory and compares the result against expected-bundle/ file by file,
byte for byte — the load-bearing golden-regression seam (§11).