Commit graph

18 commits

Author SHA1 Message Date
5ddc6c77a5 docs(okf): §8 refined against okr's answer; record the wiki's opposite construction rule
Two findings from the inbox, both re-verified against the other repo's code
rather than its summary.

§8 -- the "contradiction" we flagged was ours to misread. We had SKILL.md:94
(union) against CLAUDE.md:67 (precedence) and asked okr to adjudicate, assuming
SKILL.md because it describes actual procedure. Right, and right for the stated
reason. Verified @52129b5: SKILL.md:35-36 "always search both, project first",
:46-47 "overrides ... ON CONFLICT", :94-95 "Glob both roots". Union is the
search SPACE; precedence is a tie-break that fires only when the same content
sits in both roots -- orthogonal, which is why one file carries both without
contradicting itself. okr fixed CLAUDE.md:67 ("else" implied a lookup stopping
at the first root). §8 stays OPEN at the convention level; only its description
of okr is refined -- retrieval carries union AND precedence as two layers, not
one axis each.

The wiki -- llm-ingestion-okf reported, unprompted, that claude-code-llm-wiki
requires exactly the construction rule §3/§6 forbids. Re-read here @59ef033:
validate.py:74 puts BUNDLE_INDEX_COMPLETE at ERROR, :1097-1104 derives expected
from the directory and demands bidirectional match, bundle.py:498 generates
indexes machine-side. This is not our trap sprung -- it is its mirror image,
chosen: we forbid derivation because a derived index CANNOT DISAGREE with the
directory and so hides what is missing, while they make "cannot disagree" an
enforced invariant with a loud outcome. Our index is a curated selection that
must be able to disagree; theirs must not be. Neither is incoherent.

Consequence (theirs): authored-vs-derived cannot be a library invariant in
either direction; it becomes policy. And the sharpest argument came back at us
-- a field carrying only "per-directory: yes" would have hidden the difference
entirely. That is a better case for splitting scope from construction than the
one we gave them.

Suite 78/78. Inbox emptied: 4 in, 2 replies, 2 closed without reply.
2026-07-25 20:40:06 +02:00
6a72b26985 feat(okf): enforce §3 okf_version shape, bump convention 0.1 -> 0.2
The 2026-07-23 reservation said enforcement waits until "the emitters have
migrated". Measured rather than assumed, and the emitter set turned out to be
TWO, not three:

  okr @0059da7       okf_version: 0.1 + okf_layout: kb-layout-2026-06. Migrated.
  linkedin-studio    scaffold.ts:38 -> okf_version: 0.1. Never carried a layout
                     string; has no okf_layout and needs none.
  ms-ai-architect    NOT an emitter. Zero index.md in the repo; okf_version
                     appears in one planning doc. The status table already said
                     "designed, not built" -- only the word "emitters" implied it.

Swept the whole marketplace plus the sibling consumer repos: every live
okf_version value is 0.1. The flip is a no-op today and locks the invariant.

The gate checks SHAPE (/^\d+(\.\d+)*$/), never membership: the upstream value
set is Google's (spec §12), so a bundle targeting a newer version passes. A
membership check would be the convention claiming a set it says it does not own
-- the over-reach class this round has corrected three times. Presence stays
unenforced (reported, not failed) as a separate §3 MUST.

Convention bumped 0.1 -> 0.2 by this log's own criterion: the set of conforming
bundles changed (the spec explicitly said a layout string "conforms today", and
rollout rule 6 defines conformance as gate output). The §12 per-plugin re-check
is pre-measured as finding zero violations.

Also closes a parity blind spot found while landing this: check-okf-parity
compared the okf_version VALUE, which is identical exactly when two impls
disagree about whether it is acceptable -- a false "agree" on the axis the gate
exists to watch. The signature now carries a boolean shape verdict, with
red-marker-layout as the committed red proof. Its "diverge" expectation encodes
okr's lag (they still pure-echo) and flips to "agree" when they mirror it.

And a correction the round earned: portfolio-optimiser enumerated their own
bundle surface and it is four, not three. The dormant fourth
(reference_domain.py:49 -> package data at :70) has no flag form at all, so our
published claim that the re-measurement surfaced "one" unreported entry was
itself one-of-two. Sharpens the standing rule: a search shaped like one entry
type cannot see another; install-vs-fixture is one instance, not the class.

Suite 73 -> 78. coord: PO replied, okr + llm-ingestion-okf notified (the latter
under the standing promise to flag any okf-check.mjs change).
2026-07-25 20:32:30 +02:00
fdafd8b792 docs(okf): close commons' axis review — all four findings
commons reviewed the STEG 5 text at 3ccb5f6 against their own anchors.
Both questions we asked passed; the findings we did not ask about are
the ones that mattered. All four anchors re-verified here against their
files before acting — including their own mid-review correction, which
was right (the "never by directory enumeration" clause is
method-spec.md:82-83, not :70-73; :68-73 is the escape-not-depth rule).

3(b) — §3's "(directory enumeration)" was ambiguous against a rule that
forbids navigating by directory enumeration. Now "an authored
enumeration of that directory's children — never a filesystem read".
Fixed at BOTH sites: §3 and §6 (commons flagged one; the second was
found here). Their reason for flagging it hard holds: code written
against the wrong reading passes every test you would think to write.

3(a) — "This is exactly okr's okf-check.mjs semantics, generalized" read
as a restatement of upstream while being stricter than it. Upstream
binds index.md to the bundle root alone (method-spec.md:81-85); we bind
every level. That is a legitimate floor of our own under §8, but it must
not borrow upstream's authority. Now stated as a superset, with the
single point of difference named. This was also the catalog's own
longest-open proposed correction, independently confirmed.

Q2 — the precedence hole is now named OPEN in §8. The two shapes were
installed and not-installed; okr is a third, two marked roots at once,
and the marker predicate cannot say which is read. okr's answer is that
there is no single answer: precedence for the org profile
(inject-okr-context.mjs:54-56), union for retrieval
(okr-second-brain-search/SKILL.md:94), because the roots carry different
content. Free while placement is descriptive; the first question a
second implementer asks if marker-based discovery ever goes normative.

Q1 hygiene — "root" carries four specified meanings across this
ecosystem. §1's bare uses are now qualified, with the other three named
and anchored so a reader arriving from method-spec cannot misparse.

Nothing normative changed for consumers: placement stays unmandated, the
§3 floor is unchanged in substance, and no path form is mandated.

Verified: suite 73/73; check-versions 11 OK · 0 WARN · 0 ERROR. The
okf-check FAIL on docs/okf-second-brain is structural and pre-existing
(the spec directory is not itself a bundle) — confirmed identical at
HEAD before this change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CPHvLhn2U3j2XD3Cn8zeYa
2026-07-25 15:37:27 +02:00
9e98f51b9f docs(okf): method correction — the grep proved less than we claimed
p-o-claude re-measured their own source after our (b) finding and sent
back the root cause. It generalizes past them, including to us.

The counting error: their --bundle surface is four sites, not three
(run.py:554 default=None, run_s10.py:46 has a fixture default,
hitl.py:290 append/no default, contracts.py:81 required field).
Verified here against their tree, not their report.

The same blind spot in our own work: 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 it supported. Enumerating declarations instead surfaces one neither
side had reported — portfolio-optimiser's simulation.py:48
_default_bundle_dir() -> shared_root()/examples/bygg-energi-mikro, used
at simulation.py:293. Both PO repos carry a fixture-shaped default, not
just p-o-claude.

The headline is unchanged and survives contact: a fixture default aimed
at golden bytes creates no installation root and is not user-owned
second-brain state. Still one installation against three
non-installations; STEG 5 stays descriptive; §8 untouched. What changed
is the support — "caller-supplied with no default" was too strong, and
the accurate claim is the narrower one the grep actually proved: no
installation root anywhere in either src/.

Citations now pinned to commits rather than lines (PO 9e149c6, POC
bf50d2c) — portfolio-optimiser landed 8+ commits the same day and
already invalidated run.py:653, now run.py:679.

Verified: suite 73/73; check-versions 11 OK · 0 WARN · 0 ERROR.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CPHvLhn2U3j2XD3Cn8zeYa
2026-07-25 15:25:53 +02:00
3aea016074 docs(okf): §1 — okr's two roots are not one ordering
The reference impl read the STEG 5 text and objected to one word: §1 said
okr "runs per-root over a project root … ahead of a home root". Verified
here against their code rather than their report, the objection holds —
that phrasing fused three distinct behaviours into one.

- profile axis is precedence (inject-okr-context.mjs:54-56 short-circuits
  on the project hit)
- retrieval axis is union (okr-second-brain-search/SKILL.md:94 globs both
  roots; they carry different content — project is cwd-bound cycle/work
  data, home is org identity that survives reinstall)
- checking is neither (okf-check.mjs:11 runs each root independently)

So "ahead of" was true of exactly one axis and false as a 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
goes to log.md instead — naming one consumer's internal resolution order
in a scope section is the same class of leak the format exists to keep
out.

Placement remains unmandated (§8); nothing in the contract changed.

Verified: suite 73/73 across the six test files; check-versions 11 OK ·
0 WARN · 0 ERROR (okr released v1.8.0 mid-session and bumped the catalog
ref themselves in 8afd4f0).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CPHvLhn2U3j2XD3Cn8zeYa
2026-07-25 15:17:15 +02:00
3ccb5f6afa docs(okf): STEG 5 — placement is descriptive, not normative
The sample does not support a mandated path form. Of the four consumers
polled, exactly one installs a bundle anywhere (okr: project .claude/okr/
ahead of home ~/.claude/okr/org/); the other three install none — the
bundle dir is a caller-supplied argument per run, with no default, no
discovery, and no $HOME/~ expansion in their sources (verified by grep in
each repo, not taken from their reports).

One installation and three non-installations makes the standing criterion
("three installations before normative text") unmeetable from this
population, so no normative path form was written.

- spec.md §1: correct the in-scope example. A lone `~/.claude/<plugin>/…`
  misstates okr's project-first precedence, i.e. it contradicts the only
  real implementation — a fix that stands on its own regardless of n.
- spec.md §8: placement unmandated; "no installation root" named a
  conforming consumer shape; installing vs. writing marked separate axes
  (a consumer may write into a bundle it never placed).
- log.md: the measured sample with file:line evidence, plus two findings
  the responses did not supply — neither portfolio-optimiser repo reads
  okf_version at all (so neither is evidence for or against marker-based
  discovery), and p-o-claude has a third --bundle entry point that does
  carry a fixture default, contra its own account.

Confirms distilled note 3 ("discovery, not placement") rather than
extending it, and bears on Stage 2 (§10): three of four consumers have
nothing to discover.

Verified: suite 73/73 across the six test files; check-versions 10 OK ·
1 WARN · 0 ERROR (okr 1.8.0 untagged — their release is still in flight).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CPHvLhn2U3j2XD3Cn8zeYa
2026-07-25 12:28:28 +02:00
9ca2c8bdaf docs(okf): STEG 4 — tighten §3 on okf_version/okf_layout (non-enforcing)
§3's okf_version MUST now states the value is the upstream OKF version alone;
a plugin's own layout revision belongs in the optional okf_layout marker (§12).
Marked explicitly 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 inert).

Non-enforcing is the deliberate shape. okr ratified the split and owns the
migration, but their scripts/okf-* are file-fenced frozen through the 1.8.0
consolidation. Enforcing okf_layout presence now would redden the STEG 3 parity
gate on okr with nothing they could do until that ships. Enforcement is a
separate scoped step after their migration lands.

log.md records the round's other settled items, each verified against ground
truth rather than accepted as asserted: the roll-up carrier is a no-op for the
public-mirror class (builder tolerates absence by design); the catalog runs no
index.md generator (read-side only), so commons' inherited item is stale; the
okf_version ruling already existed in §12; and the catalog's okf-check.mjs is
NOT byte-identical to okr's (141 differing lines), so parity here is behavioural
over the §3 floor in default read-mode via check-okf-parity.mjs — never byte
identity.

Verified: suite 73/73, check-okf-parity 8/8 exit 0, check-versions 11 OK/0 WARN/
0 ERROR.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CPHvLhn2U3j2XD3Cn8zeYa
2026-07-25 06:43:38 +02:00
325727523d test(okf): consume nav-golden fixtures + thin STEG 0 corpus gate
Consume commons' nav-golden fixture class byte-exact from
portfolio-optimiser-commons @ b641741 (nav-golden-hierarchy positive +
nav-golden-escape boundary) into test/nav-golden-corpus/ and wire a thin
gate scripts/check-nav-golden.mjs (+ .test.mjs, 10 tests).

Scope (operator decision, thin): the catalog is the convention owner and
holds no consumer (null konsument), and the shared retrieval skill is
deferred (spec.md §10 Stage 3). So the gate does NOT run a read-context
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 expected-read-context.md golden is present and non-empty. Byte-exact
navigator conformance stays a consumer concern (okr STEG 4 / Stage 3 skill).

Fixtures pinned byte-exact (.gitattributes -text); manifest carries source
repo+SHA per the vendoring-provenance rule. Naming: the stale "§5 pts 1-5"
read-context label maps to the settled method-spec §3 Step 1 (commons 9801d35);
no open §5 dependency. commons confirmed b641741 complete + goldens derived
from §3 Step 1 (via coord).

Verified: check-nav-golden 10/10; gate CLI exit 0 (2 fixtures PASS); full
suite 73/73 across the six test files.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NeK9hkxrU9wFPBYGYnSV1V
2026-07-24 20:35:44 +02:00
09521f8f2d test(okf): add running n-way per-file parity gate + adversarial corpus (STEG 3)
Make OKF §3 checker parity a RUNNING per-file red/green signal instead of a
stale one-shot claim. The catalog and okr checkers provably diverge on the same
input (catalog walks everything + no BOM/CRLF norm; okr skips innboks/dot-dirs +
normalizes); this gate turns that divergence into a monitored, tested fact.

- scripts/check-okf-parity.mjs: n-way runner, zero-dep. Normalizes each impl's
  existing checkBundle(root) return to {conceptCount, untyped[], okfVersion} and
  compares per file over default read-mode. Impl registry is availability-guarded
  so a catalog-only checkout degrades gracefully; a documented subprocess seam
  awaits llm-ingestion-okf's Python checker (fase 2) + Node port (fase 4).
- test/okf-parity-corpus/: committed byte-exact adversarial corpus + manifest.
  Red-proof fixtures (expected: diverge) the gate MUST go red on — byte axis
  (BOM+CRLF) and tree axis (innboks, dot-dir) each carry one; canon = both.
  .gitattributes -text pins the BOM/CRLF bytes. Green fixtures pin agreement
  incl. a SHARED gap (both descend into node_modules).
- check-okf-parity.test.mjs: 8/8. Corpus assertions + byte-tracking red-proof +
  runtime-materialized symlink/NFC-NFD meta-tests + graceful-skip seam.

Honest scope: only 2 impls expose a runnable per-file checker today, so the gate
runs 2-way and is architected n-way — no faked third impl, no cross-repo code.
spec §7 + log.md updated (no self-certified parity; fixes stay upstream-first).

Verified: parity 8/8, CLI exit 0; regression 33/33; check-versions 10 OK.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NeK9hkxrU9wFPBYGYnSV1V
2026-07-24 01:23:46 +02:00
3be4321a79 docs(okf): split okf_version/okf_layout in spec §12 (STEG 2)
okf_version had been carrying two unrelated concerns — the upstream OKF
version and a plugin's own layout revision. Split into two markers:
okf_version stays the upstream Google OKF version alone (currently 0.1,
value set owned by Google, single-valued bundle-root marker); a new
optional okf_layout marker holds a plugin's layout-revision snapshot.

Verified against ground truth: okr 056b652 stamps
okf_version: kb-layout-2026-06 (fixtures + bundle roots) — a known
deviation okr itself flagged, and it proposed exactly this okf_layout split.

Lands only the decision + spec text — NOT enforcement (§3 tightening stays
deferred to its own step, so okr's current value isn't flipped to a gate
failure yet; its migration is cheap since the field is pure echo today).
Additive + disambiguating: §3 floor unchanged, okf_layout optional, so the
convention version stays 0.1 — no re-ratification triggered.

- spec.md §12: rewrite defining the split
- log.md: protocol §5 clarified (third non-version marker) + dated change-log entry

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NeK9hkxrU9wFPBYGYnSV1V
2026-07-23 22:29:29 +02:00
548a9abab3 docs(okf): retract false okr verdict-parity claim + fold in 7 distilled notes
The shared checker (scripts/okf-check.mjs) was lifted from okr once (c06e4d7,
2026-06-29) and never updated; okr hardened its checker afterward (skip
innboks/dot-dirs + scoped checkBundle @ 3b45be7, 2026-06-30; BOM/CRLF
normalization @ 482effb, 2026-07-17). The two have diverged and are NOT
verdict-identical. Retract the "byte-identical / verdict parity is verified"
claim everywhere it stood (spec.md section 7, log.md incl. a handed-out
conformance flag, and both script headers), replacing it with a precise, dated
provenance note. Establishing parity is tracked separate work
(check-okf-parity.mjs); fixes go upstream-first (drift is two-way). No code
behavior changed. Also folds the round's 7 distilled architecture notes into
log.md. Tests 33/33.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-23 22:05:13 +02:00
b27905303c docs(catalog): OKF log — record spec-vs-gate coverage gap as a deferred decision
The shared gate enforces only the `type:` MUST, not §3's okf_version / per-level
index.md MUSTs nor §6's index.md-no-frontmatter (inherited faithfully from okr's
reference semantics). So "passes the gate" is a necessary-but-partial §3 signal.
Surfaced by the portfolio-optimiser bundle (index.md with frontmatter) passing.
Deferred to Stage 2 / a spec<->gate reconciliation — not changed now, since
tightening would break the proven verdict-parity with okr's checker.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012GqEHp4uDiivfrAUjw4BdE
2026-06-29 15:30:14 +02:00
12c2fefd74 docs(catalog): OKF log — note external form-consumer portfolio-optimiser (gate-verified)
Relay from the portfolio-optimiser session (per protocol §3): a separate Forgejo
framework (MAF cost-optimiser, NOT a marketplace plugin) independently adopted the
OKF-minimal on-disk form for its per-project runtime knowledge bundles — a different
scope than this convention's user-second-brain. Recorded in the change log so the
on-disk FORM doesn't drift across the ecosystem. NOT a 4th convergence member (no
user-second-brain, no shared ingestion/retrieval).

Independently re-verified in this catalog session before recording: the
shared/examples/bygg-energi-mikro bundle passes the shared gate (exit 0, 5 concepts,
okf_version 0.1, exactly the 2 named resource-warnings); index.md carries frontmatter
(type: index); commit portfolio-optimiser 812db23 exists locally. Claims hold.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012GqEHp4uDiivfrAUjw4BdE
2026-06-29 15:26:44 +02:00
062d6336af docs(catalog): OKF — add landing protocol (siblings record conformance in the shared log)
So a sibling's conformance landing reaches the convergence without the operator
hand-carrying status: when a plugin's bundle conforms, it writes the claim directly
into log.md (its own catalog-go) as 🟡 "claims conformant @ <commit>, awaiting
gate-verification"; a linkedin-studio session runs the shared gate and flips it to
🟢 on exit 0 (independent verification, not self-assertion). Honest limit recorded:
no live push across separate sessions — discovery is pull-at-session-read. Pointer
added to the handoff §5.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012GqEHp4uDiivfrAUjw4BdE
2026-06-29 14:38:02 +02:00
c06e4d7b55 feat(catalog): shared OKF conformance checker + wire as cross-plugin acceptance gate
Lift okr's reference okf-check.mjs into the catalog as the single cross-plugin
acceptance gate for the OKF-compatible second-brain form (spec §3):

- scripts/okf-check.mjs (+ vendored okf-frontmatter.mjs): verdict logic
  byte-identical to okr's reference impl, English output, zero deps, self-contained.
- scripts/okf-check.test.mjs: 5 self-contained tests (temp-dir bundles).
- spec §7 + §14: the shared checker now lives here; only TS/mjs reconciliation
  remains Stage-3, not required for the gate. log.md protocol §6: conformance is
  verified by the gate, not asserted — a plugin moves to 🟢 only after passing it.

Verified: 33/33 catalog tests green (canonical glob form); verdict parity with
okr's checker on okr fixtures (positive + negative missing-type); a scaffolded
linkedin-studio brain/ validates clean (exit 0).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012GqEHp4uDiivfrAUjw4BdE
2026-06-29 10:27:05 +02:00
99d164e31e docs(catalog): OKF log — record Stage 1 ratification by okr + ms-ai-architect
Both siblings ratified spec v0.1 + adapted plans (relayed via operator):
okr @ 75bfc9b, ms-ai-architect @ 72a7e2b. Status table updated, open
coordination items marked resolved-via-ratification, change-log records
Stage 1 ratification complete across all three tracks (interop goal met at
the convention level). Conformance landings remain each their own go.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012GqEHp4uDiivfrAUjw4BdE
2026-06-29 10:01:56 +02:00
0b54b8e1f4 docs(catalog): add OKF second-brain handoff brief for okr + ms-ai-architect
Action brief the operator hands to the two sibling second-brain sessions:
read spec.md + log.md, confirm per-plugin items, update STATE.md, adapt the
plan, and acknowledge back in their own repo (operator relays -> log.md status).
Carries the three verified premise corrections (mdcode != OKF tool; no reusable
OKF ingest; resource not source) and a deterministic acknowledge-back line.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012GqEHp4uDiivfrAUjw4BdE
2026-06-29 09:40:21 +02:00
449225454f docs(catalog): add OKF-compatible second-brain form spec + coordination log
Cross-cutting catalog artifact (owned by no single plugin): the shared
"OKF-compatible second-brain form" convention all three second-brain plugins
(linkedin-studio, okr, ms-ai-architect) conform to, plus a coordination log
that serves as the cross-repo rollout state.

- spec.md: minimal contract (type + per-level index.md + root okf_version),
  recommended fields, extension keys, reference checker (okr okf-check),
  verified premise corrections (mdcode != OKF tool; no reusable OKF ingest),
  staged plan, homes, versioning. linkedin-studio's brain = reference design;
  OKF = thin interop veneer.
- log.md: coordination protocol (single source of truth, no cross-repo writes,
  operator relay), per-plugin conformance status table, open coordination items.

linkedin-studio recorded conformant (brain emits OKF form, cross-tool-verified
against okr's okf-check). okr / ms-ai-architect rollout = separate per-repo go.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012GqEHp4uDiivfrAUjw4BdE
2026-06-29 09:36:04 +02:00