v0.5.0a1 shipped the one actor value the spec owner had already excluded. Caught before any pilot was notified, so it costs a tag, not a migration. Commons decided <fast id> = process:okf-ingest on 2026-07-31, on this repo's own proposal, superseding option (d) (process:llm-ingestion-okf) chosen here on 07-27. The exclusion is ingest-spec.md:7-8, frozen on the spec being framework-neutral: normalising OUR repo name into the normative id would force every other conformant implementation to write it into its own output. Verified against three independent sources before touching anything — commons' coord message 20260731T154140Z, their plan :215-216/:244, and their STATE :37. Why this had to land before the pilot notifications rather than after: actor is both the stamp written and the value owned back (OwnershipPolicy), and recognition is one-way. A pilot that had run Test A against the excluded id would hold bundles this library stops recognising the moment the id is corrected — collision_unstamped on their OWN files. That is the A-E5 failure mode, and we would have inflicted it. Worse, it would not have shown up as a failure: the plan's A-E3 expectation (:854) named the same excluded value as the code, so Test A would have PASSED and confirmed the error. Expectation and implementation agreeing is not evidence when both predate the decision. Nothing in the wild carried the old value: OKF_V0_2 did not exist at v0.4.0, so the profile has never been released. v0.5.0a1 is abandoned, not moved — a tag already on a public remote does not get force-pushed, and the history should say plainly that a1 was wrong. A-E3 now records both corrections with dates. The V1 paragraph at :1169 is superseded in place rather than rewritten: its reasoning still holds, only its outcome moved. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVTup4v7tW9QiVyBENk2LV |
||
|---|---|---|
| .. | ||
| ingest-golden-file | ||
| ingest-golden-http | ||
| ingest-golden-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).