test(docs): byte-gate the requirement backlink on a real fixture — task 7, series complete

Plan: docs/superpowers/plans/2026-08-21-requirements-doc-surface.md. Adds
fixtures/conformance/requirement-levels-and-nesting/expected/Order.md, which
test/golden/docs-file-conformance.test.ts now byte-matches against docsFile() output.

THE PLAN POINTED AT A REJECTED CORPUS AND IS CORRECTED, NOT FOLLOWED. Task 7 originally said
"a codegen-conformance case". fixtures/codegen-conformance/ is FORMALLY REJECTED — FR-007
rejected 2026-05-26, re-confirmed 2026-05-31, its README kept solely so nobody re-proposes
it, on the reasoning that codegen is a substrate whose observable consequences are already
gated by the behaviour corpora. Following my own plan would have revived something the repo
deliberately killed. The real mechanism is the docs golden harness, which byte-matches ANY
fixtures/conformance/<name>/expected/<Entity>.md and skips fixtures without one — so the
golden lands on an existing fixture and no new corpus appears.

WHY THIS FIXTURE. requirement-levels-and-nesting already pairs an Order entity with a nested
ledger, so one golden covers four things at once that a purpose-built fixture would have had
to assemble: a nested dotted path (Storefront.OrderService.OrderRecord), an L4 claim, an
ARCHITECTURAL claim rendering with no level at all (the unlevelled policy form), and —
silently but importantly — the entity-grain rule, since the L5 TranscribableReference claims
Order.reference, a FIELD, and correctly does NOT appear on the entity page.

THE GOLDEN WAS REVIEWED, NOT ACCEPTED. Generating a golden from current behaviour encodes
whatever the code does, which is how a golden goes quiet the moment it is regenerated to
match a bad fix. I read the emitted file and checked each line said what the model actually
declares before installing it. It then failed on first run against the harness — my generator
used an in-memory source so Source read `<inline>` where the harness loads real files and
reads `meta.shop.json`. Corrected to the harness's truth; the entire Required-by section
matched byte-for-byte on that first run, which is the part that mattered.

PROVEN ABLE TO FAIL: forcing claimedBy to undefined turns this golden red and restoring it
turns it green. Third gate in this series verified by sabotage rather than by its silence,
after the one vacuous assertion found earlier.

Cross-port safety: this corpus is shared by all five ports, and expected.json coexisting with
an expected/ directory is an established pattern here (docs-file-basic carries both), so the
addition is TS-additive and invisible to the other runners.

Verified: codegen-ts 1300 pass / 0 fail (the golden harness goes 4 -> 5 cases).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: dmealing

docs/superpowers/plans/2026-08-21-requirements-doc-surface.md

@@ -129,10 +129,18 @@ Task 1 rows by `@implementedBy`.
 **Tests first:** `--requirements` alone emits only this surface; no flag emits all three; a
 project with no ledger sees byte-identical output to before this plan.
 
-## Task 7 — the conformance fixture
-
-A `codegen-conformance` case whose model carries a nested `requirement.*` tree, gating both
-artifacts byte-for-byte — the mechanism that keeps the markdown and the TOON in agreement.
+## Task 7 — the byte-level golden
+
+**CORRECTION — this task originally said "a `codegen-conformance` case". That corpus is
+formally REJECTED** (`fixtures/codegen-conformance/README.md`: FR-007 rejected 2026-05-26,
+re-confirmed 2026-05-31, the README kept only so nobody re-proposes it). Adding a case there
+would have revived something the repo deliberately killed, on the reasoning that codegen is a
+substrate whose observable consequences are gated by the behaviour corpora.
+
+The real mechanism is `test/golden/docs-file-conformance.test.ts`: **any**
+`fixtures/conformance/<name>/expected/<Entity>.md` is byte-matched against `docsFile()` output,
+and fixtures without one are skipped. So the golden goes on an existing requirement fixture
+rather than into a new corpus.
 
 **The fixture must carry, or the gate is blind:**
 - **nesting** (Tasks 1 + 3 both fail silently on a flat corpus)

fixtures/conformance/requirement-levels-and-nesting/expected/Order.md

@@ -0,0 +1,22 @@
+<!-- @generated by @metaobjectsdev/codegen-ts — DO NOT EDIT. -->
+
+# Order
+
+**Type:** `object.entity`
+**Source:** `meta.shop.json`
+
+## Identity
+
+- **Primary key:** `id`
+
+## Fields
+
+| Field | Type | Required | Column | Rules |
+|---|---|---|---|---|
+| <a id="field-id"></a>🔑 `id` | `uuid` | yes |  |  |
+| <a id="field-reference"></a>`reference` | `string` | yes |  |  |
+
+## Required by
+
+- `requirement.functional Storefront.OrderService.OrderRecord` · **L4** · status: `live` — An order records what was bought and for how much
+- `requirement.architectural UuidPrimaryKeys` · status: `live` — Every entity has a uuid primary key