open/llm-ingestion-okf
1
0
Fork 0
Code Issues Releases 1 Activity

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

Browse source 
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
This commit is contained in:
Kjell Tore Guttormsen 2026-08-02 21:48:34 +02:00
commit 12301531d3
1 changed files with 20 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

28
CLAUDE.md
View file

@ -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
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.
5. **Phase 5 — MCP as a way to populate a bundle. NOT COMMITTED; needs-based
(operator 2026-08-02, superseding the 2026-07-27 commitment.)** No MCP work,
and no data-lake or database source types, are undertaken without a stated
need. `docs/plan/mcp-bundle-population.md` stays as a design record, not a
queue. Its open fork — whether we are the MCP **server** (an agent calls our
doors as tools) or an MCP **client** (a manifest source type pulling from
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