# OKF second-brain convergence — coordination log > Cross-repo coordination for the OKF-compatible second-brain form (`spec.md`). This is the **one > shared place** all three plugin sessions read to know where the others are. OKF reserves `log.md` > for change logs; this extends it with rollout status + the coordination protocol. > > **No writing crosses repo boundaries** — each plugin session writes only its own repo (+ the catalog > with its own go). Status here is updated via operator relay. ## Coordination protocol The operator runs one Claude session per plugin repo and relays between them. To keep three independent sessions converged **without** cross-repo writes (mirrors the maskinrommet feedback-register pattern): 1. **Single source of truth = `spec.md`.** The convention is defined once, here. No plugin redefines it locally; a plugin's local OKF doc *references* this file. (Mirrors the global rule: don't invent local mechanisms; extend the shared one.) 2. **This log is the cross-repo state.** Convention version, decisions, per-plugin conformance status, open coordination items. All three sessions read it. 3. **No writing crosses repo boundaries.** Each session writes only its own repo. The catalog is shared but needs a per-session go. A plugin records its own conformance in its own STATE/changelog; the operator relays it here. 4. **Operator = relay + truth-source.** Convention changes are proposed by any session, written here (with go), and the operator carries "convention changed → re-check conformance" to the other sessions. 5. **Two version markers** (spec §12): `okf_version` (upstream Google OKF) and this convention's own version. Either bump → log it below → each plugin re-checks. (A third spec-§12 marker, the optional `okf_layout`, is a plugin-own layout snapshot — not a version; it triggers no cross-plugin re-check.) 6. **Conformance is verified, not asserted.** A plugin's status only moves to 🟢 after its bundle passes the shared acceptance gate `catalog/scripts/okf-check.mjs` (spec §7) — `node catalog/scripts/okf-check.mjs ` → exit 0. On a relayed conformance landing, run the gate against that plugin's bundle and record the result here. Evidence-based flips only (operator verification-plikt). ## Per-plugin conformance status Legend: 🔵 not started · 🟡 building / partial · 🟢 conformant (+ commit-ref). **Ratification** (spec accepted + plan adapted) is recorded in the Status cell with the plugin's own commit-ref — distinct from conformance (code landed), which `linkedin-studio` alone holds so far. | Plugin | Against minimal contract (spec §3) | Notes | Status | |---|---|---|---| | **linkedin-studio** | `type` + per-level `index.md` + root `okf_version` on `brain/`; `ingest/` excluded (round-trip-critical tributary) | Reference design. Emits frontmatter, adds no parser. Brain suite 134/134; passes the **shared gate** `catalog/scripts/okf-check.mjs` (scaffolded `brain/` → "OK: valid OKF bundle", exit 0). | 🟢 conformant @ linkedin-studio `da0a16a` (2026-06-26) | | **okr** | `type` required + recommended-as-warnings + `okf_version` echo | Has the reference **writer + checker** (`okf-check.mjs`, `okf-index.mjs`, `lib/frontmatter.mjs`) + skill `okr-second-brain-search` v1.6.1. | 🟡 built · **spec ratified @ okr `75bfc9b` (2026-06-29)**; conformance-alignment landing = own go | | **ms-ai-architect** | designed, not built | Targets the fuller OKF package + a retrieval skill. Builds against this spec. | 🔵 designed · **spec ratified @ ms-ai-architect `72a7e2b` (2026-06-29)**; build = own go | ## Landing protocol — how a sibling records conformance When your plugin's bundle actually conforms (the work of step 4, done in your own session): 1. **Record it in your own repo** (STATE/changelog) — as the handoff already instructs. 2. **Update THIS file** (your own catalog-go): set your row in the status table above to 🟡 → **"claims conformant @ ``, bundle ``, awaiting gate-verification"**. 3. A **linkedin-studio session** then runs the shared gate against your bundle — `node catalog/scripts/okf-check.mjs ` — and, on exit 0, flips your row to 🟢 with the proof. This puts the landing signal in the **one shared doc**, so the operator need not hand-carry status, and any session sees the truth on its next read. **Honest limit:** there is no live push-notification across separate sessions — a landing is discovered when a session next *reads* this log (a linkedin-studio session is told to check it at start; see its STATE). Self-flipping straight to 🟢 is **not** the protocol; 🟢 is reserved for the independent gate-verified step (operator verification-plikt). ## Open coordination items (what each session must confirm) > **✅ Resolved 2026-06-29 — both siblings ratified.** okr (`75bfc9b`) and ms-ai-architect (`72a7e2b`) > ratified `spec.md` and adapted their plans. The items below are **accepted via ratification**; they > are kept as the record of what was asked. Any new field-gap, change-proposal, or conformance landing > arrives as a **fresh item / status bump**, not here. **→ okr session:** - Confirm `okf-check.mjs` semantics are stable enough to stand as the reference contract (spec §3, §7), and that this spec faithfully generalizes them (only-`type`-required; recommended → warnings; `okf_version` echo). - Canonical recommended-field name is **`resource`** (OKF), not `source` — confirm okr uses `resource`. - Flag any field okr needs that the minimal contract + recommended set doesn't cover. **→ ms-ai-architect session:** - Confirm the minimal contract + extension-key model (spec §3, §5) supports the planned **"full OKF package"** KB structure — going fuller is fine; the minimal contract is the **floor, not the ceiling**. - **Field-name drift:** the architect brief writes `source`/`timestamp` (line 45); canonical is OKF's **`resource`**. Align on `resource`. - **mdcode is not an OKF tool** (spec §9.1) — drop it from the adoption plan. The `reference_agent` enrichment is GCP/Gemini-bound (spec §9.2) — adopt the *prompt patterns*, not as drop-in code. **→ both:** - Ratify `spec.md` as the shared contract, or propose changes here. - Retrieval-skill naming/home: okr shipped `okr-second-brain-search`; architect plans `second-brain-search`. If a shared skill ever happens (Stage 3), converge naming + home (standalone plugin, spec §11) — **not now** (Stage 2 measurement must justify it first). ## Deferred decisions - **Spec §3/§6 vs. the gate's actual coverage.** The shared gate `okf-check.mjs` (faithfully lifted from okr's reference) fails **only** on a concept file missing `type:`. It does **not** fail on a missing root `okf_version` (echoed as `MISSING`, not an error), missing per-level `index.md` (§3 MUST), or an `index.md` that carries frontmatter (§6 says it should not). So **"passes the gate" = "every concept file has `type:`"** — a necessary but **partial** §3 signal, not full §3/§6 conformance. Surfaced when portfolio-optimiser's bundle (index.md with frontmatter) passed. **To resolve in Stage 2 / a spec↔gate reconciliation:** either tighten the gate to enforce more of §3/§6 (diverges this copy further from okr — drift is two-way; fixes go upstream-first) or relax the spec's MUSTs to match what the gate actually enforces. **Not changed now** — there is no established okr parity to protect (see the 2026-07-23 correction below); the fix belongs upstream, then re-vendored. _(linkedin-studio session, 2026-06-29; parity framing corrected 2026-07-23.)_ ## Change log - **2026-06-29** — Convention **v0.1** authored (`spec.md`) + this log. Seeded from the three per-plugin design notes + linkedin-studio's verified premise corrections (mdcode ≠ OKF tool; no reusable OKF ingest code; classify/convert is build-yourself). linkedin-studio recorded **🟢** (brain emits OKF-compatible form, validated by the shared gate `okf-check`). okr / ms-ai-architect rollout = separate per-repo go. _(Authored by the linkedin-studio session; operator relay to siblings pending.)_ - **2026-06-29** — **Stage 1 ratification complete across all three tracks.** okr ratified spec v0.1 + adapted plan @ okr `75bfc9b`; ms-ai-architect ratified spec v0.1 + adapted plan @ ms-ai-architect `72a7e2b` (both relayed via operator). The shared contract is now accepted by all three — the interop goal of Stage 1 is met at the convention level. Conformance *landings* (okr form-alignment, ms-ai-architect build) remain each their own go. _(linkedin-studio session, operator relay.)_ - **2026-06-29** — **Shared acceptance gate landed** (`catalog/scripts/okf-check.mjs` + `okf-frontmatter.mjs` + `okf-check.test.mjs`). Lifted from okr's reference impl at `c06e4d7`; English output, zero deps, self-contained. Verified: 33/33 catalog tests green; the gate's own §3 verdicts held on okr fixtures (positive + negative) at lift-time; a scaffolded linkedin-studio `brain/` validates clean (exit 0). Wired as the conformance gate (protocol §6 + spec §7): a plugin only moves to 🟢 after passing it. The only Stage-3 remainder is reconciling the TS/mjs impls — not required for the gate. _(linkedin-studio session.)_ - **2026-06-29** — **Ekstern form-konsument notert: portfolio-optimiser.** Et separat Forgejo-rammeverk (MAF kostnads-optimiser, IKKE en marketplace-plugin) adopterte OKF- minimal-formen uavhengig for sine per-prosjekt runtime-kunnskapsbundles — en ANNEN scope enn denne konvensjonens bruker-second-brain (§1). Bundelen passerer den delte gaten (`node catalog/scripts/okf-check.mjs ` → okf_version 0.1, "OK: valid OKF bundle", exit 0) etter å ha lagt til rot-`okf_version`-markøren; commit portfolio-optimiser `812db23`. Registrert så on-disk-FORMEN ikke driver fra hverandre i økosystemet (global regel: konformer til den delte formen, ikke re-derive). IKKE et 4. konvergens-medlem — ingen bruker-second-brain, ingen delt ingestion (spec §8–9: build-yourself), ingen delt retrieval. Eneste framtidige overlapp: bygger portfolio-optimiser verdict-promotering (sitt «steg 8»), er den gjenbrukbare skrive-primitiven okr's `okf-index.mjs` + frontmatter-skriver. Kjente avvik på bundelen: 2 `resource`-warnings (utelatelse tillatt, §4); `index.md` beholder frontmatter (avviker fra §6 reservert-index, beholdt fordi dens `okf.py`-leser klassifiserer index på type). _(Relayet fra portfolio-optimiser-sesjonen; bruk i en catalog-sesjon per protokoll §3.)_ **Gate re-verifisert i denne catalog-sesjonen (uavhengig):** `shared/examples/bygg-energi-mikro` → exit 0, 5 konsepter, 0 uten type, okf_version 0.1, nøyaktig de 2 `resource`-warnings nevnt (`kilder-realiseringsgap.md`, `metode-ipmvp-a.md`); `index.md` bærer frontmatter (`type: index`); commit `812db23` finnes lokalt. Påstandene stemmer. - **2026-07-23** — **Parity claim retracted (drift correction).** Earlier entries and `spec.md` §7 stated the catalog gate is "byte-identical" to / "in verdict parity with" okr's checker. That is **false against okr's current checker.** The copy was lifted once (`c06e4d7`, 2026-06-29) and never updated; okr began hardening the next day (`3b45be7`, 2026-06-30: skip `innboks/`+dot-dirs, scoped `checkBundle(root, { strictIngest, files })`) and added BOM/CRLF normalization weeks later (`482effb`, 2026-07-17; `lib/frontmatter.mjs:23`) — none of which the catalog copy has. The two can already diverge on the same input. The lift-time parity run was green but narrow (okr's own fixtures, bundle-verdict) and is now stale. Establishing parity is tracked separate work: a CI-run gate over a spec-derived adversarial corpus (`check-okf-parity.mjs`). Fixes go **upstream-first** — drift is two-way; re-copying okr is the cause, not the cure. _(catalog session.)_ - **2026-07-23** — **`okf_version` / `okf_layout` split (spec §12).** `okf_version` had been carrying two unrelated concerns — the upstream OKF version *and* a plugin's own layout revision. okr flagged this as a blocker and left the call to the convention owner: its bundle roots + fixtures stamp `okf_version: kb-layout-2026-06` (a layout snapshot, not `0.1`) — a known deviation okr already documented, and it proposed exactly this two-field split (verified against okr `056b652`). **Decision (owner, catalog):** `okf_version` stays the upstream Google OKF version alone (value set owned by Google, single-valued — the bundle-root marker relies on that, §6); a new **optional** `okf_layout` marker line holds a plugin's own layout-revision snapshot. **This step lands only the decision + spec text** (§12) — *not* enforcement. §3 tightening that would flip okr's current value from "echoes an odd value" to "fails the gate" stays deferred to its own step; the field's re-check semantics are pure echo today, so okr's migration (move the value to `okf_layout`) is cheap when it happens, and it should happen before that tightening. Additive + disambiguating: the §3 floor is unchanged and `okf_layout` is optional, so **the convention version stays `0.1`** — no re-ratification triggered. _(catalog session.)_ - **2026-07-23** — **STEG 3: the running parity gate landed** (`scripts/check-okf-parity.mjs` + `test/okf-parity-corpus/` + `check-okf-parity.test.mjs`). Parity is now a *running* per-file red/green signal over a committed spec-adversarial corpus, not a stale one-shot claim (retracted above). **Verified scope blocker (ground-truth this session, 2 independent agents + grep):** the round named ≥3 impls, but **only two expose a runnable per-file checker** — catalog + okr. llm-ingestion-okf's Python lib is a *producer* (no `check_bundle`, no CLI; checker is fase-2, its own repo); linkedin-studio's TS §3 logic lives only in private test helpers (not a participant). **Decision (operator delegated on quality grounds):** build the gate **n-way-capable, wire the 2 real impls now**, with a documented availability- guarded seam for the Python checker (fase 2) and its Node port (fase 4) — no faked third impl, no cross-repo code. Decisions the earlier record left open, now fixed: **(a) per-file contract** = each impl's existing `checkBundle(root)` return normalized to `{ conceptCount, untyped[], okfVersion }`, compared per file (concept-set + type verdict), over **default read-mode** (strictIngest off, not files-scoped); **(b) adapter convention** = JS impls imported directly (both export `checkBundle`), zero subprocess/zero dep; cross-repo/other-language impls get a subprocess `--json` adapter when they exist; **(c) corpus form** = committed byte-exact fixtures (`.gitattributes -text` pins BOM/CRLF), the inspectable "borne proof"; **(d) red-proof** = `expected: "diverge"` fixtures the gate MUST go red on (byte + tree axes each carry one; canon = BOM+CRLF concept + `innboks/` raw file, catalog FAIL vs okr OK). Axis decisions: IN = byte (BOM/CRLF), tree (innboks, dot-dir, node_modules[shared gap, both descend], duplicate-name, hierarchical); **WITHDRAWN** = verbatim/trailing-newline (trinn E §1); **OUT of STEG 3** = path-forms (rerouted to §1.2/STEG 5). The git/FS-hostile axes (live symlink, NFC/NFD filename) are covered as **runtime-materialized meta-tests** (temp dir), not committed fixtures. The gate does **not** claim the two checkers are identical (they provably are not) — it makes their divergence a monitored fact. Verified: parity 8/8, `node check-okf-parity.mjs` → exit 0 ("parity holds"); regression 33/33; `check-versions` 10 OK. Fixes stay **upstream-first** (patching BOM-norm into the catalog copy would just re-diverge in the other direction). _(catalog session.)_ - **2026-07-24** — **STEG 0: nav-golden fixture class consumed + thin corpus gate landed** (`test/nav-golden-corpus/` + `scripts/check-nav-golden.mjs` + `check-nav-golden.test.mjs`). commons authored a `nav-golden` fixture class — each fixture is an OKF bundle paired with a committed byte-exact `expected-read-context.md` golden (the fasit a conformant read-context navigator, commons `method-spec.md §3 Step 1` + §11 Navigation boundary, must produce). **Consumed byte-exact from portfolio-optimiser-commons `b641741`** (`nav-golden-hierarchy` positive + `nav-golden-escape` boundary; `diff -r` identical; `.gitattributes -text` pins bytes; manifest carries source repo+SHA per vendoring rule #7). **Scope decision (operator, thin):** the catalog is the convention owner and holds no consumer (null konsument), and the shared retrieval skill is deferred (spec §10 Stage 3, "do not build before Stage 2 says so") — so the gate does **not** run a navigator and does **not** assert the goldens byte-exact. It asserts only what the catalog owns: each fixture `bundle/` is a conformant OKF bundle under the existing §3 `checkBundle` (every concept typed + root `okf_version`), and the committed golden is present + non-empty. Byte-exact navigator conformance stays a consumer concern (okr STEG 4 / the deferred Stage 3 skill). **Naming correction (relayed to + confirmed by commons via coord):** the earlier record's "§5 pts 1-5" read-context label was stale — the settled normative location is `method-spec §3 Step 1`'s five read-context bullets (commons `9801d35`); there is no open §5 dependency (current spec §5 = extension keys). commons confirmed both prerequisites: Q1 `b641741` is the complete nav-golden set (future cases additive, non-moving); Q2 the goldens derive from settled §3 Step 1. Verified: `check-nav-golden` 10/10; gate CLI → exit 0 (2 fixtures PASS — hierarchy 5 concepts / escape 1, `okf_version` 0.1, goldens present); full suite **73/73** across the six test files. _(catalog session.)_ - **2026-07-25** — **STEG 4: §3 tightened (non-enforcing) on the `okf_version` / `okf_layout` split.** §3's `okf_version` MUST now states the value is the **upstream version alone**, with a plugin's own layout revision belonging in the optional `okf_layout` marker (§12) — and marks itself **not yet enforced**: no checker validates the value's shape, so an emitter still carrying a layout string conforms today. **No convention version bump** — §12 ties a bump to a change in the §3 *floor*, and the set of conforming bundles is unchanged (a clarification, deliberately non-enforcing). **Why non-enforcing (okr's answer, received via coord):** okr ratified the split and owns the migration, but `scripts/okf-*` is file-fenced **frozen** through their 1.8.0 consolidation (Wave 4/6); the migration runs as scoped work right after release. It is an **ETA, not an open blocker** — their field is pure echo text with no validation semantics, so they do not fail the gate meanwhile. Making §3 *enforce* `okf_layout` presence now would redden the STEG 3 parity gate on okr with nothing they could do until 1.8.0 ships. Enforcement is therefore a separate scoped step, after their migration. **Also settled this round (all verified against ground truth, not accepted as asserted):** (a) **D2 roll-up carrier is a no-op for the public-mirror class** — `build-rollup-register.mjs` defaults `carrierMode` to `absent` and only `committed` reaches output B, so okr, ms-ai-architect and claude-code-llm-wiki are excluded **by design**, never reported as missing/malformed; no code change. (b) **The catalog runs no `index.md` generator** — read-side only (`okf-check.mjs:45`, `check-nav-golden.mjs:48`); commons' inherited "catalog regenerates index.md" item (ingest-spec §6) is **stale** and needs no §6 ruling. (c) **`okf_version` ruling already existed** — spec §12 (lines 174–186) settled it; llm-ingestion-okf was pointed at the written text rather than issued a new one. (d) **Correction issued to llm-ingestion-okf:** their premise that the catalog's `okf-check.mjs` is "vendored byte-identical from okr" — and thus their Phase 4 conformance oracle — is **false** (141 diff lines; okr's copy adds `strictIngest`, `files` scoping, `innboks`/dot-dir exclusion and `lib/` deps). Parity here is **behavioural on the §3 floor in default read-mode**, gated by `check-okf-parity.mjs`, never byte identity; their impl's real entry point is that gate's n-way `IMPLS` registry behind `available()`, not a catalog `ref` (they are not a marketplace plugin, and `check-versions.mjs`/`release-plugin.mjs` operate only over `marketplace.json` entries). Verified: full suite **73/73** across the six test files; `check-versions` 11 OK · 0 WARN · 0 ERROR. _(catalog session.)_ - **2026-07-25** — **STEG 5 (installation root) settled as _descriptive_, not normative: the sample does not support a mandated path form.** The ecosystem was asked where each consumer installs its bundle. Every answer was given **against code, not docs**, and each was re-verified here before being acted on: - **okr** — the only real installation. Two roots: project `.claude/okr/` **ahead of** home `~/.claude/okr/org/`, each checked per-root (okr `scripts/okf-check.mjs:11`, `lib/innboks-write.mjs:44`). - **portfolio-optimiser-commons** — declined, correctly. Spec owner with no runnable pipeline; its only bundle-shaped bytes are conformance fixtures, so answering would have codified a **test artifact as an installation site**. - **portfolio-optimiser** — **no root.** `--bundle-dir` defaults to `None` (`run.py:653`); absent it, the feature is simply off. Verified here: **0 hits** for `expanduser|Path.home|.claude/` across `src/`. - **portfolio-optimiser-claude** — **no root.** `--bundle` defaults to `None` (`run.py:554`); `bundle_dir` is a required non-empty config field (`contracts.py:81`). Verified here: **0 hits** for the same patterns across `src/`. **One installation, three non-installations** — so the standing acceptance criterion ("three installations before normative text") is not merely unmet, it is **unmeetable from this population**. Landed in `spec.md` as exactly two things: the §1 in-scope example corrected (it showed a lone `~/.claude//…` form that misstates okr's project-first precedence), and a new §8 bullet naming placement unmandated, **"no installation root" a conforming consumer shape**, and *installing* vs. *writing* separate axes (a consumer may write into a bundle it never placed). **No normative path form was written.** Two things the responses did not supply, both found here: **(a)** neither portfolio-optimiser repo reads `okf_version` at all (**0 hits** in `src/` for both), so neither is evidence for *or against* marker-based discovery — though p-o-claude's fixture *carries* the marker, so a marker-based reader would still recognise it. **(b)** p-o-claude's own account ("two entry points, both with no default") is inexact: `run_s10.py:46` is a **third** `--bundle` entry point _(superseded — the full set is **four**; see the method correction below)_ and it *does* carry a default — `parents[2]/shared/examples/bygg-energi-mikro`, a repo-relative fixture. That leaves their headline standing (no `~`/`$HOME`/`.claude` anywhere in `src/`) but it is the same fixture-as-location class commons declined to answer from; returned to them. This **confirms distilled note 3 ("discovery, not placement") rather than extending it** — the measured population is dominated by that chain's first link, an explicit caller-supplied param. It also bears on **Stage 2 (§10)**: the evidence points *away* from a Stage-3 discovery convention, since three of four consumers have nothing to discover. _(catalog session.)_ - **2026-07-25** — **§1 corrected again: okr's two roots are not one ordering.** The reference impl read the STEG 5 text and objected to a single word — §1 said okr "runs per-root over a project root … *ahead of* a home root". Verified here against their code, not their report, and the objection holds: that phrasing **fused three distinct behaviours into one**. - **Profile axis — precedence.** `hooks/scripts/inject-okr-context.mjs:54-56` resolves `existsSync(projectConfigPath) ? projectConfigPath : (existsSync(homeConfigPath) ? … : null)`. Genuine most-specific-wins; the project hit ends the lookup. - **Retrieval axis — union.** `skills/okr-second-brain-search/SKILL.md:94` says "**Glob both roots**" and does *not* short-circuit on the project root. The roots carry **different content**, not two versions of the same: project = cycle/work data (cwd-bound), home = org identity (survives reinstall). Their own source comment states it (`inject-okr-context.mjs:51-53`: "only the org PROFILE resolves to home"). - **Checking — neither.** `scripts/okf-check.mjs:11` ("Kjoeres PER ROT") runs each root *independently*: no precedence, no union. So "ahead of" was true of exactly one of the three axes and false as a general statement about the only implementation §1 describes. Fixed by **deletion, not elaboration** — §1's job is that placement is not in this contract, and that claim never needed an ordering. The axis detail lives here rather than in the spec: naming one consumer's internal resolution order in a scope section is the same class of leak the format is meant to keep out. **Placement remains unmandated (§8); nothing in the contract changed.** _(catalog session, on okr's correction.)_ - **2026-07-25** — **Method correction: a root-signature grep licenses "no installation root", not "no default" — and we drew the wider conclusion too.** p-o-claude re-measured against their own source after our (b) finding and reported the root cause, which turned out to generalize past them. Citations pinned to commits, not lines — both consumer repos move faster than this doc (portfolio-optimiser landed 8+ commits the same day, which already invalidated one line number below). - **The counting error.** p-o-claude's `--bundle` surface is **four** sites, not the three implied above (@`bf50d2c`): `run.py:554` (`default=None`), `run_s10.py:46` (**has** a default — `_DEFAULT_BUNDLE`, `run_s10.py:40`), `hitl.py:290` (`action="append"`, no default), and `contracts.py:81` (required config field). Verified here against their tree; correction accepted as theirs. - **The same blind spot in our own measurement.** We greped both PO repos for the installation-root signature (`expanduser|Path.home|.claude/`), got **0 hits**, and reported "no default". The grep was sound; the inference was wider than the grep supported. Re-measuring portfolio-optimiser by enumerating the declarations instead surfaces one **neither side had reported**: `simulation.py:48` `_default_bundle_dir()` → `shared_root()/examples/bygg-energi-mikro`, used at `simulation.py:293` (@`9e149c6`). So *both* PO repos carry a demo/fixture-shaped default, not just p-o-claude. - **Also stale:** the `run.py:653` citation above is now `run.py:679` (@`9e149c6`). The fact (`--bundle-dir`, `default=None`) stands; the line does not. **The headline is unchanged, and this is why it survives contact:** a fixture default resolved from `__file__` or a re-pointable shared root aims at golden bytes, creates no installation root, and is not user-owned second-brain state. The sample stays **one installation against three non-installations**, STEG 5 stays descriptive, §8 is untouched. What changed is the *support*: "the bundle dir is caller-supplied with no default" is too strong as written, and the accurate claim is the narrower one the grep actually proved — **no installation root anywhere in either `src/`**. Standing rule for the next round: ask for the enumeration, not the null result — a search shaped like an install path cannot see a fixture path. _(catalog session, on p-o-claude's correction.)_ - **2026-07-25** — **The enumeration above was itself incomplete: two entries were unreported, not one.** portfolio-optimiser answered our published finding by enumerating their own surface, and the count is **four** (verified here against their tree @`9e149c6`, every site re-read): `run.py:679` (`--bundle-dir`, `default=None`), `run.py:249` (library param `run_project(bundle_dir=)`, default `None`), `simulation.py:48` `_default_bundle_dir()` (the fixture default we found), and **`reference_domain.py:49` `Project.bundle_dir`** — a per-project path in the packaged reference portfolio, threaded to `run_project` at `run.py:644` and resolved against **package data** (`reference_domain.py:70`, `files("portfolio_optimiser").joinpath(f"data/{rel}")`). The shipped `reference_projects.json` sets only `docs_dir`, so it is **dormant**: a capability with no value today, and the day it gets one it points into Python package data. - **What this corrects here:** the entry above says our re-measurement "surfaces **one** neither side had reported". It surfaced one **of two**. The claim implied a completeness the enumeration did not have — the same shape of over-reach as the null-result inference it was correcting. - **Why the dormant one is the interesting miss:** it has no flag form at all. It is a key in packaged JSON, so no search shaped like a CLI entry point — ours or theirs — could ever have seen it. That sharpens the standing rule: *a search shaped like one entry type cannot see another*, of which "an install-shaped search cannot see a fixture path" is one instance, not the general case. - **Classification unchanged, and re-verified against their anchors:** `shared_root.py:15` `ENV_VAR = "PORTFOLIO_SHARED_ROOT"`, `:17` `_DEFAULT = Path(__file__).resolve().parents[2]/"shared"` — default *and* override both point at a checked-out spec subtree, never a home directory. The env var exists so `shared/` can be extracted to its own repo without code change; re-pointing it re-points to another spec tree. `expanduser|Path.home|\.claude/` over `src/` still gives **0 hits** @`9e149c6`. **One installation against three non-installations stands.** Their own sharper wording, adopted: not "caller-supplied with no default" but **no *installation* default** — a fixture default in the simulation entry, a dormant package-data path in the reference portfolio. _(catalog session, on portfolio-optimiser's unprompted enumeration.)_ - **2026-07-25** — **STEG 4 completed: §3 `okf_version` is now ENFORCED on shape; convention version 0.1 → 0.2.** The reservation added on 2026-07-23 ("enforcement waits until the emitters have migrated") had its condition measured, not assumed. **The emitter set is two, not three:** - **okr** @`0059da7` (v1.8.1) — migrated. `okf-index.mjs` emits `okf_version: 0.1` + `okf_layout: kb-layout-2026-06`, with a verbatim migration path for legacy roots. - **linkedin-studio** — `scripts/brain/src/scaffold.ts:38` emits `okf_version: 0.1`. It never carried a layout string, and has no `okf_layout` (0 hits) because it needs none. - **ms-ai-architect is not an emitter at all** — **zero `index.md` in the repo**; `okf_version` occurs in exactly one planning document. This log's own status table already said so (🔵 "designed, not built"), but the reservation's phrase "the emitters" had been read as including it. Nothing to migrate, so it cannot gate enforcement. Swept wider than the two named: every `okf_version` value across the marketplace **and** the sibling consumer repos is `0.1`. The only `kb-layout-2026-06` occurrences are okr's own migration-test inputs and prose in these docs. **No live emitter anywhere carries a layout string**, so the flip is a no-op against today's ecosystem and locks the invariant going forward. **What the gate does and deliberately does not do.** `okf-check.mjs` rejects a value that is not version-shaped (`/^\d+(\.\d+)*$/`). It asserts **nothing about which upstream versions exist** — that value set is Google's (§12), so a bundle targeting a newer upstream version passes. This matters: a checker that validated *membership* would be the convention claiming ownership of a set §12 says it does not own — the same over-reach class this round corrected three times. **Presence stays unenforced** (absent → reported, not failed); that is a separate §3 MUST and a separate step. **Convention version bumped 0.1 → 0.2**, by this log's own stated criterion. The 2026-07-23 entry declined a bump because "the set of conforming bundles is unchanged (a clarification, deliberately non-enforcing)". Here the set **does** change: the spec explicitly declared that an emitter carrying a layout string "conforms today", and rollout rule 6 defines conformance as gate output ("verified, not asserted"). Per §12 the bump triggers a per-plugin re-check — which the sweep above has already pre-measured as finding **zero** violations. Side benefit: the convention version is no longer numerically confusable with upstream OKF v0.1. **The parity gate was blind to this axis, and that is now fixed.** `check-okf-parity.mjs` compared the normalized tuple `{conceptCount, untyped, okfVersion}` — the `okf_version` **value**. But when two checkers disagree about whether a value is *acceptable*, the value is identical, so the axis read **agree**. A false green on exactly the drift the gate exists to catch. The signature now carries a boolean shape **verdict** (`okfVersionAccepted`), normalized as a verdict rather than a message so two enforcing impls agree even if they word rejection differently. New corpus fixture **`red-marker-layout`** (`expected: "diverge"`) is the red proof, and the CLI now prints `(accepted)`/`(REJECTED)` because on this axis both impls print the same `okf=` value. **Known, deliberate divergence:** catalog now enforces; okr still pure-echoes (their `CHANGELOG.md` for 1.8.1: "verdiene valideres fortsatt ikke, siden spec §3 ennå ikke er håndhevende på form" — a statement that was true when written and is now stale). The `diverge` expectation **encodes okr's lag, not a design split**, and flips to `agree` when they mirror it. okr notified; the standing promise to notify llm-ingestion-okf on any `okf-check.mjs` change was honoured in the same round. Suite **73 → 78** across the six test files. _(catalog session.)_ - **2026-07-25** — **The §8 "contradiction" was ours to misread, and okr's own doc was the thing that was wrong.** We had flagged `SKILL.md:94` ("Glob both roots" = union) against `CLAUDE.md:67` ("project preferred, else home" = precedence) and asked okr to adjudicate, assuming SKILL.md because it describes actual procedure. That guess was right, and right for the stated reason. Verified here against their files @`52129b5`, not against their summary: `SKILL.md:35-36` "always search both, project first", `:46-47` "Project content overrides home content **on conflict** (most-specific-wins)", `:94-95` "Glob both roots". **Union is the search space; precedence is a tie-break that only fires when the same content exists in both roots.** The two statements were orthogonal all along — which is exactly why one file could carry both without contradicting itself. okr corrected `CLAUDE.md:67` (the word "else" made it false by implying a lookup that stops at the first root). **§8's status is unchanged — still OPEN at the convention level** — but its *description* of okr was refined: retrieval carries union **and** precedence as two layers, not one axis each. One hole, read from three sides independently (commons from the ordering axis, okr from their own doc, us from the §8 text). _(catalog session, on okr's answer.)_ - **2026-07-25** — **A second consumer requires the exact construction rule §3/§6 forbids, and does so deliberately.** llm-ingestion-okf reported it unprompted while deciding whether to make our "authored enumeration, never a filesystem read" rule a library invariant. Re-read here out of the wiki's own code @`59ef033`, not relayed: `validate.py:74` puts `BUNDLE_INDEX_COMPLETE` at **ERROR**, and `:1097-1104` builds `expected` by enumerating the directory's files, then requires the index links to match **bidirectionally**; `bundle.py:498` `_index_entries` is machine generation ("Everything sorted, so regeneration is byte-identical"). - **This is not the trap we warned about — it is its mirror image, chosen.** Our rule exists because a derived index *cannot disagree* with the directory, so it cannot reveal that something is missing or misfiled: a silent failure mode. The wiki makes "the index cannot disagree with the directory" an **enforced invariant with a loud outcome**. Our rule serves a convention whose index is a curated selection with progressive-disclosure prose, i.e. one that *must* be able to disagree; theirs serves one where it must not. Neither is incoherent inside its own spec. - **Consequence accepted, and it is theirs, not ours:** authored-vs-derived cannot be a library invariant in **either** direction. It becomes policy alongside the match rule; nothing in the library enumerates a directory unless the profile in force says the index is derived. - **The sharpest argument came back at us:** a policy field carrying only "per-directory: yes" would have hidden this difference entirely — two consumers, identical surface requirement, opposite construction rule underneath. That is a better argument for splitting *scope* from *construction* than the one we gave them. _(catalog session, on llm-ingestion-okf's measurement.)_ ## Distilled architecture notes (OKF round, 2026-07) Durable conclusions from the cross-repo round (full working context retained by the catalog session): 1. **One form, two depths.** A flat bundle is a degenerate depth-1 of the spec §3 tree, not a separate form. 2. **A shared fixture-suite is blocked** on three things: a sibling's golden-test invariant, a commons-owned ingest spec, and this convention's own unimplemented per-level rule. 3. **Discovery, not placement.** The bundle marker is the root `index.md` + `okf_version`; resolution is explicit param → plugin config → environment → search root. The marker itself is inert. 4. **A closed `type` vocabulary is a writer requirement, not a form requirement** — it constrains the `type` value, not the field-set. 5. **The parity check was actually run and was green** — but at lift-time, against okr's own fixtures, at bundle-verdict granularity. "Spec-derived" is the load-bearing word, not "spec-owned": the corpus is derived from the spec, not certified by any one implementation. 6. **No artifact may self-certify parity.** Parity is a gate's output over a corpus, never a claim in a file's header or comment. 7. **Vendoring requires** a provenance pointer (source repo + SHA), a CI gate, and upstream-first fixes.