test(okf): capture block-form fixture and collection baseline before any decoder

Co-Authored-By: Claude <claude-opus-5>

tests/golden/block-form-provenance/bundle/attested.md

@@ -0,0 +1,19 @@
+---
+type: concept
+okf_version: 0.2
+title: "Attested computation"
+generated: { by: process:fixture-author, at: 2026-09-02T00:00:00Z }
+verified:
+  - { by: process:fixture-check, at: 2026-09-02T08:00:00Z }
+sources:
+  - resource: https://example.invalid/fixture-cost-baseline
+    id: fixture-cost-baseline
+---
+
+One verification event, written as a single-entry block sequence — the SPEC-canonical
+long form of `verified: { by: ..., at: ... }`. The actor is a `process:` one, so the
+trust tier a consumer derives from it is machine-confirmed, never human-reviewed.
+
+`sources` is written in block form too, so a reader that only understands the flow
+shorthand loses the provenance of this concept entirely rather than reporting that it
+could not read it.

tests/golden/block-form-provenance/bundle/index.md

@@ -0,0 +1,13 @@
+---
+type: index
+okf_version: 0.2
+title: "Block-form provenance — the shape a line parser cannot read"
+---
+
+A repo-owned fixture bundle whose concepts carry OKF provenance in **block** form:
+`verified` as a YAML sequence of mappings (SPEC §5.2) rather than the single-line flow
+shorthand. Navigation must stay tolerant of it — the bytes rendered here are the "before"
+referent that later decoder work compares against.
+
+- [Attested computation](attested.md)
+- [Multi-verified concept](multi-verified.md)

tests/golden/block-form-provenance/bundle/multi-verified.md

@@ -0,0 +1,14 @@
+---
+type: concept
+okf_version: 0.2
+title: "Multi-verified concept"
+generated: { by: process:fixture-author, at: 2026-09-02T00:00:00Z }
+verified:
+  - { by: human:fixture-reviewer, at: 2026-09-02T09:00:00Z }
+  - { by: process:fixture-nightly, at: 2026-09-02T10:00:00Z }
+---
+
+Two independent verification events: a human sign-off FIRST, a nightly process SECOND.
+The order is the whole point of this file. A reader that keeps the last entry it sees
+reports machine-confirmed for a concept a human actually signed off, so the tier flips
+downward without anything failing — the defect has no error channel of its own.

tests/golden/block-form-provenance/expected-read-context.md

@@ -0,0 +1,24 @@
+A repo-owned fixture bundle whose concepts carry OKF provenance in **block** form:
+`verified` as a YAML sequence of mappings (SPEC §5.2) rather than the single-line flow
+shorthand. Navigation must stay tolerant of it — the bytes rendered here are the "before"
+referent that later decoder work compares against.
+
+- [Attested computation](attested.md)
+- [Multi-verified concept](multi-verified.md)
+
+## concept: Attested computation
+
+One verification event, written as a single-entry block sequence — the SPEC-canonical
+long form of `verified: { by: ..., at: ... }`. The actor is a `process:` one, so the
+trust tier a consumer derives from it is machine-confirmed, never human-reviewed.
+
+`sources` is written in block form too, so a reader that only understands the flow
+shorthand loses the provenance of this concept entirely rather than reporting that it
+could not read it.
+
+## concept: Multi-verified concept
+
+Two independent verification events: a human sign-off FIRST, a nightly process SECOND.
+The order is the whole point of this file. A reader that keeps the last entry it sees
+reports machine-confirmed for a concept a human actually signed off, so the tier flips
+downward without anything failing — the defect has no error channel of its own.