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.

docs/okf-second-brain/log.md

@@ -398,6 +398,41 @@ protocol; 🟢 is reserved for the independent gate-verified step (operator veri
   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):

docs/okf-second-brain/spec.md

@@ -160,10 +160,13 @@ gate to function.
   - **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
+    one answer: okr resolves it **per axis**. **Retrieval** globs **both** roots — union is the
+    *search space*, with project content winning **on conflict only** (`SKILL.md:35,46,95`); the
+    precedence there is a tie-break, not a lookup that stops at the first root. The org **profile**
+    is the one axis that truly short-circuits (project overrides home, `inject-okr-context.mjs:54-56`).
+    So union and precedence are not two axes but two *layers* on one: the roots carry *different
+    content* rather than two versions of the same, which is why the search cannot stop early even
+    though a conflict still needs a winner. 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.**