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

docs/okf-second-brain/spec.md

@@ -17,9 +17,13 @@ organizational context the plugin retrieves from during chat and commands. This
 retrieval skill (if ever justified — §10) has one contract to build against.
 
 - **In scope:** the user's own context/data — the per-user second brain. **Where** that brain sits on
-  disk is *not* part of this contract (§8): the reference impl (okr) runs per-root over a **project**
-  root (`.claude/okr/`, cwd-relative) and a home root (`~/.claude/okr/org/`), and other
-  consumers install no root at all. A single `~/.claude/<plugin>/…` example would misstate both.
+  disk is *not* part of this contract (§8): the reference impl (okr) runs per **installation root**
+  over a project installation root (`.claude/okr/`, cwd-relative) and a home installation root
+  (`~/.claude/okr/org/`), and other consumers install none at all. A single `~/.claude/<plugin>/…`
+  example would misstate both. _("Root" is overloaded across this ecosystem — installation root
+  (here, §8), **bundle root** (an interior link-resolution origin, `method-spec.md:68-69`), **source
+  root** (ingest extraction, `ingest-spec.md:106-108`), and the §3 **root marker**. Every bare use in
+  this document means installation root.)_
 - **Explicitly out of scope:** each plugin's **domain reference files** (skill `references/*`). Those
   stay native Claude Code skill-references (Anthropic-recommended progressive disclosure). The decisive
   test, which all three plugins reached independently: not "is it an LLM-wiki" (both are) but
@@ -44,8 +48,8 @@ file path minus `.md`.
 
 - **MUST** — every concept file (every `.md` except `index.md`) carries a `type:` frontmatter key
   (free string, e.g. `Profile`, `Operations`, `JournalEntry`).
-- **MUST** — every directory level has an `index.md` (directory enumeration, **no frontmatter**,
-  carries progressive-disclosure prose).
+- **MUST** — every directory level has an `index.md` (an **authored** enumeration of that directory's
+  children — **never a filesystem read**; **no frontmatter**, carries progressive-disclosure prose).
 - **MUST** — the bundle-root `index.md` carries an `okf_version` marker (the upstream OKF version the
   bundle targets, currently `0.1`). The value is the **upstream version alone**; a plugin's own layout
   revision belongs in the optional `okf_layout` marker (§12), never here. **Not yet enforced** — no
@@ -54,7 +58,12 @@ file path minus `.md`.
 - **MUST (consumers)** — preserve unknown frontmatter keys, tolerate unknown `type` values, tolerate
   broken cross-links.
 
-This is exactly okr's `okf-check.mjs` semantics, generalized (§7).
+This is a **superset** of upstream OKF, not a restatement of it. The difference is deliberate and
+sits in one place: upstream binds the `index.md` requirement to the **bundle root alone** — a nested
+directory without its own `index.md` is not an error there (`method-spec.md:81-85`) — whereas the
+MUST above binds **every** level. §8 permits a plugin to go further than the floor; this is the
+catalog exercising that, and a reader must not take it as upstream's requirement restated. okr's
+`okf-check.mjs` (§7) is the reference implementation of *these* semantics.
 
 ## 4. Recommended fields (warnings, not errors)
 
@@ -76,8 +85,8 @@ levelled down to bare OKF.**
 
 ## 6. Reserved files & cross-links
 
-- `index.md` — directory enumeration, **no frontmatter**, progressive-disclosure prose. The
-  bundle-root one carries `okf_version`.
+- `index.md` — an **authored** enumeration of the directory's children (**never a filesystem read** —
+  §3), **no frontmatter**, progressive-disclosure prose. The bundle-root one carries `okf_version`.
 - `log.md` — change log (optional per bundle; reserved name).
 - Cross-links — plain markdown (bundle-relative `/...` or relative); relation type conveyed by prose.
   Consumers MUST tolerate broken links.
@@ -142,6 +151,16 @@ gate to function.
   the writer is the installer. This is why discovery keys on the §3 root marker rather than on a path
   (`log.md`, distilled note 3): a marker-based reader serves both shapes; a mandated path form serves
   neither.
+  - **OPEN — which root wins when there is more than one.** The two shapes above are *installed* and
+    *not installed*; okr is a third, **two marked installation roots at once**, and the marker
+    predicate answers "is this a bundle?" without answering "which of these do I read?". Nor is there
+    one answer: okr resolves it **per axis** — precedence for the org **profile** (project overrides
+    home, `inject-okr-context.mjs:54-56`) but **union** for **retrieval** (both roots globbed,
+    `okr-second-brain-search/SKILL.md:94`), because the roots carry *different content* rather than
+    two versions of the same. This costs nothing while placement stays descriptive. It becomes the
+    first question a second implementer asks the moment marker-based discovery is proposed as
+    normative (§10, Stage 3), so it is named here rather than left implied by the two-shape framing.
+    **Unresolved; do not plan against an assumed answer.**
 
 ## 9. Verified premise corrections (dead-ends — do not plan against these)