From 4f95331801b97102070e5138b108b5b2c08d8a5e Mon Sep 17 00:00:00 2001 From: Kjell Tore Guttormsen Date: Mon, 20 Jul 2026 21:38:55 +0200 Subject: [PATCH] =?UTF-8?q?docs(linkedin-studio):=20OKF=20trinn=20E=20?= =?UTF-8?q?=E2=80=94=20Q3=20besvart=20+=20korriger=20uverifisert=20vokabul?= =?UTF-8?q?ar-tilslutning?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) Claude-Session: https://claude.ai/code/session_019uzhvLjCm39mNQXVFwG7w2 --- docs/okf-ingestion/plan.md | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/docs/okf-ingestion/plan.md b/docs/okf-ingestion/plan.md index 60279a4..83d461e 100644 --- a/docs/okf-ingestion/plan.md +++ b/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