docs(roadmap): phase 5 — MCP as a way to populate a bundle

Committed by the operator; the design is open and the scope is not. Recorded
in the roadmap with a scoping plan rather than in the v0.2 alignment doc, which
is about OKF v0.2 conformance and is the wrong home.

The plan settles nothing on purpose. It names the fork everything turns on —
whether we are the MCP server (an agent calls our doors, Door B's territory,
ours to design) or an MCP client (a manifest source type, which is normative in
commons' ingest-spec and therefore starts as a request to them, not as code
here). The two share a protocol and nothing else, including their owner.

Constraints written down because each has already refused something: the
one-runtime-dependency rule (an MCP SDK would be the second — stdlib JSON-RPC
or an optional extra), no model calls in the run path (the model may CALL us,
never the reverse), the guard persist gate (MCP is transport, not a bypass),
the network opt-in, and the required ingested_at.

CLAUDE.md

@@ -61,6 +61,14 @@ are the library baseline. First consumer: `portfolio-optimiser-claude`.
    (docx/pdf/eml/html → md). Covers okr, linkedin-studio, ms-ai-architect,
    and the marketplace catalog.
 
+5. **Phase 5 — MCP as a way to populate a bundle.** Committed by the operator
+   2026-07-27; the design is open, the scope is not. Plan:
+   `docs/plan/mcp-bundle-population.md`. The fork that must be settled before
+   any code — whether we are the MCP **server** (an agent calls our doors as
+   tools) or an MCP **client** (a manifest source type that pulls from someone
+   else's server) — decides both the owner and the dependency question, and the
+   two are not variants of one feature.
+
 The two halves share the OKF contract and fixture suite, **not code**.
 
 ### Upstream version policy (standing, non-negotiable)