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/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.**