docs(plan): record commons↔implementation-repo coordination boundary

The Claude SDK implementation (claude-code-llm-wiki) runs the same adoption task
in parallel; it owns guard wiring in its repo-local modules (ingest.py/verdicts.py/
okf.py), while shared/ and the ingest-spec gate contract are commons-owned. Record
the reciprocal boundary in the adoption plan so the division of labor survives
between sessions.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/plan/2026-07-16-llm-ingestion-guard-adoption.md

@@ -128,6 +128,19 @@ future ingest-spec section, added when Trigger A/B nears — so MAF and the Clau
 implementation wire the identical guard. The executable wiring lives in each implementation
 repo; the *rule* lives in commons, mirroring how method-spec/ingest-spec already work.
 
+**Coordination with consuming implementation repos (recorded 2026-07-16).** The Claude
+Agents SDK implementation (`claude-code-llm-wiki`) is running this same adoption task in
+parallel and has drawn the reciprocal boundary: its `shared/` is a **pull-only subtree of
+commons**, so guard wiring that touches `shared/` or the **ingest-spec** is owned by *this*
+commons session, not there — its plan covers only its **repo-local modules** (`ingest.py`,
+`verdicts.py`, `okf.py`). Division of labor, both directions:
+
+- **Commons (here)** authors the normative untrusted-source *gate contract* (a future
+  ingest-spec section) and MUST NOT edit implementation-repo modules.
+- **Each implementation repo** wires the guard in its own runtime modules and pulls the spec
+  via subtree; it MUST NOT edit the shared ingest-spec in place (edits land in commons first,
+  then `git subtree pull`, per README).
+
 ## 5. Honest limitations to carry into any future wiring (brief §8)
 
 - **Semantic / factual poisoning is invisible** to the deterministic core — highest impact