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

docs/okf-second-brain/spec.md

@@ -16,7 +16,10 @@ organizational context the plugin retrieves from during chat and commands. This
 **one shared on-disk form** so a single reader can traverse all three, and so a future shared
 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 (e.g. `~/.claude/<plugin>/...`).
+- **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) *ahead of* a home root (`~/.claude/okr/org/`), and other
+  consumers install no root at all. A single `~/.claude/<plugin>/…` example would misstate both.
 - **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
@@ -129,6 +132,16 @@ gate to function.
   different points (ms-ai-architect targets the fuller package; linkedin-studio emits the minimal form
   + extension keys; okr has writer + checker). **The minimal contract (§3) is the floor all meet;**
   going further is per-plugin and never required by this spec.
+- **Placement — where a bundle lives on disk.** Unmandated, and *measured* rather than assumed
+  (`log.md`, 2026-07-25): of the four consumers polled, exactly **one** installs a bundle anywhere
+  (okr's two roots — §1), and **three install none** — the bundle directory is a
+  caller-supplied argument per run, with no default, no discovery, and no `$HOME`/`~` expansion
+  anywhere in their sources. **"No installation root" is a conforming consumer shape,** not a gap: a
+  consumer may be handed a bundle it never placed. Note also that *installing* and *writing* are
+  separate axes — a consumer can write into a bundle it did not place — so no rule here may assume
+  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.
 
 ## 9. Verified premise corrections (dead-ends — do not plan against these)