docs(linkedin-studio): OKF trinn E — Q3 besvart + korriger uverifisert vokabular-tilslutning

To selvkorreksjoner verifisert mot kode:
- type-vokabularet er tre verdier, ikke fem (JournalEntry/TributarySummary
  finnes kun i designnotat, aldri i kode)
- tilslutningen til lukket vokabular ble gitt uten aa sjekke innholdet;
  okf-check --strict-ingest exit 1 paa vaart konforme bundle, og safe
  default kollapser alle tre typene til Dokument

Nytt empirisk argument mot obligatorisk noekkel-prefiks: referanse-checkerens
egen konstant heter RECOMMENDED, ikke REQUIRED (exit 0 med advarsler).

Q3 (fase 4-omfang) besvart av llm-ingestion-okf: lag 1-primitivene, ikke
materialize_bundle-paritet. Status forblir planned.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019uzhvLjCm39mNQXVFwG7w2

docs/okf-ingestion/plan.md

@@ -72,6 +72,23 @@ library's materializer is stricter than the spec it implements. Our Stage-1 OKF
 (`docs/okf-convergence-brief.md`) depends on rich fields riding along as extension keys; door A has no
 mechanism for that.
 
+> **Addition, 2026-07-20 (trinn E).** Two runs of `okr/scripts/okf-check.mjs` against a fresh
+> `brain init` scaffold sharpen this into a concrete argument, and correct one of our own claims:
+>
+> - The reference checker's own constant is named `RECOMMENDED`, not `REQUIRED` (`okf-check.mjs:21`).
+>   A bundle missing `resource`/`timestamp` gets **warnings and exit 0**. The de-facto conformance
+>   tool already treats every §5 key beyond `type` as advisory — so a mandatory ordered prefix would
+>   turn a green bundle red without a byte changing. Argument fed to commons' D1.
+> - **Correction:** trinn C claimed our `type` vocabulary is five values. It is three —
+>   `Profile` (`scripts/brain/src/profile.ts:48`), `Operations` (`scaffold.ts:56`),
+>   `PendingDiff` (`cli.ts:252`). `JournalEntry`/`TributarySummary` exist only as examples in
+>   `docs/okf-convergence-brief.md:101`, never in code.
+> - **Correction:** we assented to a closed `type` vocabulary without checking its contents.
+>   `okf-check.mjs --strict-ingest` **exits 1** on our conformant bundle — `okr/lib/okf-vocab.mjs:11-21`
+>   is nine okr-domain values, and the safe default (`Dokument`) collapses all three of our types into
+>   one, erasing the distinction `okf-conform.test.ts` rests on. Our assent now carries a condition:
+>   an absent vocabulary must mean *do not snap*, and the vocabulary is per-bundle, never spec-global.
+
 **(2) Rewrite-on-run ownership vs incremental accretion.** Door A owns files via `generated: true` +
 `ingest_manifest`, then **deletes every stamped file and rewrites the set** each run. Our stores accrete:
 dedupe by content id, topic-union on re-capture, last-wins score, collision-suffix on body divergence,
@@ -240,8 +257,14 @@ the other's approval. The guard plan's own interop blocker (Python↔Node) is tr
    scan nor an external bundle import.
 2. Is R2 (extension keys) a spec change via commons, or a materializer relaxation within the current spec?
    OKF v0.1 already mandates preserving unknown keys, which suggests the latter.
-3. For phase 4: is the Node half expected to reach parity with door A only, or with whatever doors exist
-   when it starts? Our adoption depends on R1, which is not door A.
+3. ~~For phase 4: is the Node half expected to reach parity with door A only, or with whatever doors exist
+   when it starts?~~ **Answered 2026-07-20 (trinn E, felles §6): phase 4 delivers the layer-1 primitives,
+   not `materialize_bundle` parity** — no Node repo in the set runs door A (verified here: the only Python
+   in this repo is `hooks/scripts/compile-hooks.py`, a build-time script never on a data path). Our register
+   status therefore stays **`planned`**, not `blocked on phase 4 scope`. One follow-up outstanding: layer 1
+   grew after the question was asked (`read_concept`, `navigate_bundle`, `routeLevel`), so we asked whether
+   phase 4 tracks the set as it stands or as it evolves — the reader is decision-relevant for us, since our
+   dependency is `serialize ∘ parse = identity`, not the writer alone.
 
 ## 9. References