docs: phases 4-5 are demand-driven, not committed work

Operator, 2026-08-02: no MCP, no data lakes, no databases without a
stated need. We run on what we have -- defect fixes, improvements, and
features a consumer actually asked for.

That supersedes the 2026-07-27 line calling phase 5 committed, which
this file still carried. A roadmap that promises work nobody asked for
is a queue that generates its own deadlines, and the sql-is-sqlite-only
"gap" is the clearest case: closing it buys runtime dependency number
two for no asked-for use.

Phase 4 is not demoted the same way -- four named consumers have working
implementations to lift, so the need is real but untriggered. It starts
when one of them asks.

The upstream version policy is stated as the one exception and why: it
is a promise already made, so an upstream release is itself the need.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JxRjDS9U2szUGYDeuZB2M3

CLAUDE.md

@@ -41,7 +41,7 @@ side of the boundary something belongs on: ask the operator.
 pre-mutation collision gate, validated `ingested_at`, typed `IngestError`)
 are the library baseline. First consumer: `portfolio-optimiser-claude`.
 
-### Roadmap (committed phases — all known OKF surfaces get covered)
+### Roadmap (phases 1–3 shipped; what follows is demand-driven)
 
 1. **Phase 1 — Door A (Python).** ingest-spec implementation + the §11
    golden fixtures. Consumers: `portfolio-optimiser-claude` first, then
@@ -61,16 +61,28 @@ 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
+5. **Phase 5 — MCP as a way to populate a bundle. NOT COMMITTED; needs-based
-   2026-07-27; the design is open, the scope is not. Plan:
+   (operator 2026-08-02, superseding the 2026-07-27 commitment.)** No MCP work,
-   `docs/plan/mcp-bundle-population.md`. The fork that must be settled before
+   and no data-lake or database source types, are undertaken without a stated
-   any code — whether we are the MCP **server** (an agent calls our doors as
+   need. `docs/plan/mcp-bundle-population.md` stays as a design record, not a
-   tools) or an MCP **client** (a manifest source type that pulls from someone
+   queue. Its open fork — whether we are the MCP **server** (an agent calls our
-   else's server) — decides both the owner and the dependency question, and the
+   doors as tools) or an MCP **client** (a manifest source type pulling from
-   two are not variants of one feature.
+   someone else's server) — no longer blocks anything, because nothing waits
+   behind it. It is a question to answer *if* a need arrives, not before. This
+   is also why `sql` staying sqlite-only is not a gap: a Postgres driver would
+   be runtime dependency number two, bought for no asked-for use.
 
 The two halves share the OKF contract and fixture suite, **not code**.
 
+**Standing posture (operator 2026-08-02).** Phases 1–3 shipped; the library now
+runs on what it has. Work is defect fixes, improvements, and features that a
+consumer has actually asked for or that measured feedback shows are needed —
+not roadmap completion for its own sake. The upstream version policy below is
+the one exception, and it is not a counterexample: "always latest" is a promise
+already made to consumers, so an upstream release *is* the stated need.
+Phase 4 keeps four named consumers with working implementations to lift, so its
+need is real but untriggered — it starts when one of them asks, not on a date.
+
 ### Upstream version policy (standing, non-negotiable)
 
 **The library always supports the current latest version of Google OKF.** Set by