ID-163 {163.1} TECH — canonical-okf-system baseline bundle (Path-2 direct-producer authoring lane)

TECH — canonical-okf-system baseline bundle (Path-2 direct-producer authoring lane)

Status: DRAFT — 17/07/2026. The HOW for the DR-079 class-2 (system baseline) bundle: platform-navigation knowledge for consuming agents (id-71) shipped as a sibling bundle under every client’s OKF_BUNDLE_ROOT.

Spec chain (TECH+PLAN tier — research closed). There is no separate PRODUCT.md: the ratified bundle doctrine (initiatives/core-product/knowledge-base-foundations/okf-platform/bundle-doctrine.md, RATIFIED 16/07/2026, DR-079) is the PRODUCT substrate, and bl-465’s closed research verdicts (folded into the id-163 Task description) are the behaviour contract. This TECH maps proposed changes 1:1 against the doctrine’s “System bundle v1 scope” (S1–S4) and its four “Key assumptions to validate” (KA1–KA4) — the grid in §“Scope → change map” is the Checker’s per-item compliance surface. {163.2} PLAN (a fresh Planner) decomposes this into implementation subtasks.

How to read this: §Context grounds the plan at current head (the proven id-132 producer spine + the {132.35} GLM path). §Scope → change map is the doctrine-item → PC-N grid. §Proposed changes is the HOW, PC-1…PC-9. §Testing and validation names the four doctrine validation slices as concrete gates. §Empirical verification carries the mandated import-and-call result.

De-identification: the system bundle carries no client corpus — all its concepts describe the platform itself. No client name or private path appears in any citation (S3 hard rule).

Context

What is being built

A second OKF bundle class produced by the same id-132 cocoindex producer, differing from the client-business bundle in four axes only: its source (repo/docs, not L-records), its concept-type set (schema/tool/api/navigation/playbook, not the business set), its citation form (git-pinned public-repo blob URLs / resolvable public doc pages, not canonical:// DB-row anchors), and its gate (born-evaluable HC-5 round-trip

CI regen + §9, not the human promotion gate). Everything else — the two-pass agent loop, the bundle writer, index.md/log.md generation, git-sync, the memo-delta regeneration engine, the GLM-5.2/OpenRouter provider path — is reused byte-for-byte. This is a direct-producer (Path 2) lane per the doctrine, not a refinery (Path 1) lane.

Code-intelligence orientation (verbatim — Checker: confirm this ran)

Tools (17/07/2026): gitnexus_query / gitnexus_context (repo canonical), grep over scripts/cocoindex_pipeline/ + lib/okf/ + scripts/mcp-eval/, and the ratified doctrine read in full. Tool catalogue: .gitnexus/CLAUDE.md, .ast-dataflow/CLAUDE.md (cited, not reproduced).

gitnexus_query({query:"OKF bundle producer source", repo:"canonical"}) returned no producer process (empty processes); top definitions were the producer flow-def entry points — Function:scripts/cocoindex_pipeline/producer/flow_def.py:run_producer_flow (364–537), _resolve_bundle_dir (197–219), _resolve_client_id (222–230), and the forced-run server handlers server.py:_producer_run_handler (1151–1241) / _forced_producer_main_fn (1104–1118). This confirms the Path-2 lane is net-new against an existing, deployed producer spine — no RepoDocsSource symbol exists yet.
gitnexus_context({name:"LRecordsSource", repo:"canonical"}) → Class:scripts/cocoindex_pipeline/sources/l_records.py:LRecordsSource (673–1129). It implements a local, runtime_checkable Source protocol mirror (module docstring: “re-implements the reference_agent’s Source protocol shape … NOT vendored”) with abstract-equivalent methods list_concepts() / read_concept(key) and concrete helpers sample_rows(key, n) / find(query), built against an injected asyncpg-shaped pool so it is fully test-doubleable. This is the “Source-ABC spine” RepoDocsSource mirrors (PC-1).
enumerate-bundles.ts (lib/okf/enumerate-bundles.ts:26) enumerateOkfBundles() reads the OKF_BUNDLE_ROOT parent dir, treats every immediate subdirectory as one bundle keyed by its directory name (SAFE_BUNDLE_ID_RE-filtered), returns them sorted, and never throws (unset/absent/empty root → []). The deployment-mount union is therefore already multi-bundle — the system bundle needs only to land as one more sibling subdir (PC-7).
bundle_writer.py (scripts/cocoindex_pipeline/producer/bundle_writer.py:713) already declares BundleClass = Literal["client_business", "system_baseline", "showcase", "internal_dev"]; _resolve_bundle_class() (flow_def.py:234-255) reads OKF_BUNDLE_CLASS; and write_bundle (bundle_writer.py:998) hard-rejects a discovered overlay unless bundle_class == "client_business" — so the {132.36}/DR-054 boundary (“system types NEVER via ontology-overlay.json”) is already enforced in code (PC-6, verified — not net-new).
validator.py (scripts/cocoindex_pipeline/producer/validator.py:229-275) gates concept type against EffectiveOntology.base_only(), whose concept_types = the closed business set ALLOWED_CONCEPT_TYPES (topic/product/company/certification/case_study; mirrors lib/ontology/concept-schema.ts:CONCEPT_TYPE_VALUES). This base set is not bundle-class-aware — the per-class type set is the net-new gate work (PC-4).
The §9 conformance checker (okf:validate plugin, scaccogatto/okf@0.3.4/skills/validate/scripts/okf_validate.py) enforces only §9.1 (parseable frontmatter) + §9.2 (non-empty type, open-valued) as hard errors; broken cross-links and the closed type set are not its job. It is therefore bundle-class-agnostic and reusable as-is — the closed system type set is enforced by the Canonical producer validator.py (PC-4), not by §9 (PC-8).
The mcp-eval matrix lives at scripts/mcp-eval/ (functional-correctness.ts, protocol-compliance.ts, response-quality.ts, headless-complete-set.ts, dual-runtime-connectivity-set.ts, propose-write-set.ts + fixtures.ts/seed-data.ts, importing the actor from lib/mcp/actor.ts via propose-write-set.ts), wired in .github/workflows/ci.yml + eval-nightly.yml. Every current set exercises the MCP tools’ own behaviour; none reads a concept. The HC-5 concept round-trip is a net-new additive set on this harness (PC-8, KA1).

gitnexus orientation: RepoDocsSource / repo-source concept producer — greenfield surface over an existing producer spine.

Current-state facts the plan builds on

The producer is deployed and GLM-proven. {132.35} is DONE (get task 132.35 status → done, 17/07/2026): the producer runs on ca-pipeline-platform-staging, and BI-18 delta-determinism is PROVEN on image sha-35e1a9c1 via the 4-run forced-surface protocol (cold full-corpus draft on GLM-5.2/OpenRouter, pure-unchanged no-op, single-touch one-redraft; zero Anthropic spend). The four GLM-through-OpenRouter wiring hazards are all CLOSED by producer-scoped env slices B–E (PRODUCER_MODEL, PRODUCER_BASE_URL/PRODUCER_AUTH_TOKEN + producer_async_client(), PRODUCER_PROVIDER_ORDER, api_key="" suppression) — see producer-operations.md §“GLM-5.2 routing”. The provider path is not net-new work for id-163 (PC-3).
The source is hard-wired. run_producer_flow instantiates source = LRecordsSource(pool) unconditionally (flow_def.py:433). Source selection is the first wiring point (PC-2).
Change-signal precedent. git_sync.py already shells git via subprocess (_run_git, git_sync.py:264-289; git show HEAD:<rel_path>, git rev-parse HEAD) — the git-blob-SHA change signal (S4) reuses this posture, no new external git library (PC-1, empirical-verification scope).

Governing decisions (cited, not restated)

DR-079 — the four-class doctrine; non-client bundles run GLM-5.2, client bundles stay Anthropic; separate-sibling composition. This bundle is class 2.
DR-081a — the producer emits A19 confidence strong|partial only (no-content/needs-SME are human-reserved); refines DR-079’s A19 posture ({132.41} derive_concept_confidence). Governs PC-9.
DR-055 — deployed-producer bundle hosting: persistent-volume clone + repo-scoped deploy key, push as a separate lane (OKF_BUNDLE_DIR / OKF_BUNDLE_DEPLOY_KEY_PATH). Governs PC-7.
DR-054 — the client-CV-overlay contract: reserved additive ontology-overlay.json, fail-loud. The system bundle NEVER admits an overlay (enforced at bundle_writer.py:998). Governs PC-6.
DR-060 — producer memo delta-determinism; a drafting-config change is a manual, logged version= bump. A PRODUCER_* value change for the system lane inherits this contract.
DR-016 / DR-019 — bundle medium is a git repo; human edits are producer overrides re-applied on regeneration; the OKF conformance posture is a documented superset of upstream v0.1. The interim human sign-off (S2) reuses the DR-016 override mechanism (PC-8).

Scope → change map

The Checker’s 1:1 grid. Every doctrine scope item and key assumption maps to at least one proposed change; every validation slice maps to a §Testing gate.

Doctrine item	Proposed change(s)	Validation gate
S1 grain one-per-tool (~68), per-class type set	PC-1 (RepoDocsSource grain), PC-4 (type set)	KA3 slice; §9 + `validator` gate
S2 GLM-assisted authoring → regenerable	PC-3 (provider reuse), PC-8 (override capture)	first-5-concepts slice
S3 citations = git-blob URLs / public doc pages, never private docs-site	PC-5 (provenance model)	KA2 first-5-concepts slice
S4 change signal = git blob SHA	PC-1 (`RepoConceptKey.git_blob_sha`)	BI-18 no-op re-run
KA1 eval round-trips cheap on mcp-eval	PC-8	one-tool round-trip prototype
KA2 GLM citation-disciplined under seen-anchors	PC-5	first-5-concepts slice
KA3 RepoDocsSource ≤2 extractors	PC-1	two-extractor prototype
KA4 A19 vocabulary fits system concepts	PC-9	strong/partial design slice
bundle-class discriminator (`{132.37}`)	PC-6 (verified enforced)	overlay-rejection test
composition = deployment-mount union	PC-7	multi-bundle render check

Proposed changes

PC-1 — `RepoDocsSource`: the Source-ABC mirror over repo/docs (S1, S4, KA3)

New module scripts/cocoindex_pipeline/sources/repo_docs.py, a structural sibling of LRecordsSource implementing the same local Source protocol (list_concepts() / read_concept(key) / sample_rows / find) so flow_def’s draft loop consumes it unchanged. It is constructed over a repo/docs root path (not a pool) — the persistent-volume checkout the producer already mounts.

Concept identity — new RepoConceptKey (frozen dataclass, the memo key), mirroring ConceptKey but with system-bundle locators: rel_path (bundle path = identity), concept_type (one of the S1 system set — validated in __post_init__ against the class type set, PC-4), source_ref (the backing artefact locator: a file#Lstart-Lend for code-symbol grain, or a doc page path for markdown grain), and git_blob_sha (the S4 change signal — the memo-fingerprint field, the delta lever exactly as ConceptKey.content_version is for L-records). list_concepts() computes git_blob_sha per concept via git rev-parse HEAD:<source_ref path> (subprocess, git_sync.py:264 posture) so a byte-identical backing artefact memo-hits (skip redraft) and a changed one memo-misses — this is how S4 gives BI-18 delta-only regeneration for free.
Extractor-count verdict (KA3): ≤2 extractor FAMILIES — verdict holds, guarded by an escalation trigger. The five pillars split cleanly into two identity models:
- E1 — code-symbol grain (tool ~41, api ~6, schema ~10): identity + backing content resolve from a code symbol — an MCP tool registration in lib/mcp/tools/*, an agent-facing route in app/api/**/route.ts, a table type in supabase/types/database.types.ts. Citation = a git-blob URL pinned to the symbol’s file@SHA#Lrange.
- E2 — markdown-page grain (navigation ~6, playbook ~5): one concept per doc page, page path emitted as the free anchor (the /understand-knowledge precedent the doctrine names as the sanctioned docs-derived production alternative). Citation = the resolvable public doc-page URL.
The three E1 pillars share one identity MODEL (a code symbol → concept) with per-pillar locator resolvers (tool-name from registerXTools, route from file path, table from the generated types) — resolvers are not extractors. Escalation trigger (doctrine key-assumption 3, “Path A balloons”): if any pillar needs a bespoke concept model — a distinct RepoConceptKey shape or read grid, not merely a locator resolver — that is a third family; STOP and escalate to the Orchestrator before authoring beyond the prototype. The KA3 validation slice (§Testing) proves the split on the tool pillar + one doc pillar before the other three are built.

PC-2 — Source selection in `run_producer_flow` (S1)

run_producer_flow (flow_def.py:365) must choose RepoDocsSource vs LRecordsSource instead of the hard-wired LRecordsSource(pool) at line 433. The selector keys on the already-resolved bundle class: when _resolve_bundle_class() is "system_baseline" (or "internal_dev", a future Path-2 class), construct RepoDocsSource(repo_docs_root); otherwise LRecordsSource(pool) as today. repo_docs_root resolves from a new producer-scoped env (OKF_SOURCE_REPO_PATH, read-once-at-import, same posture as the PRODUCER_* slices) pointing at the platform repo/docs checkout. Keep the change additive and class-gated so the client-business path is byte-identical (the isolation discipline the PRODUCER_* slices established). No behaviour change for bundle_class in {None, "client_business"}.

PC-3 — Producer model/endpoint reuse: what is proven, what is new (S2)

Reused unchanged (PROVEN in {132.35}, zero id-163 work): the GLM-5.2 draft path — PRODUCER_MODEL (slug), PRODUCER_BASE_URL/PRODUCER_AUTH_TOKEN + producer_async_client() (endpoint/auth isolation), PRODUCER_PROVIDER_ORDER (OpenRouter Anthropic-skin provider directive), and the slice-E api_key="" suppression. The system bundle sets the same values (OpenRouter endpoint, z-ai provider order, GLM-5.2 slug) the client bundle’s non-client runs use. No new provider path, no agent-loop change. A value change to any of these is DR-060 drafting-config (manual version= bump + log.md note).

Genuinely new for id-163: the source (PC-1), the type set (PC-4), the citation-provenance form (PC-5), and the gate (PC-8). Everything the authoring lane needs on the model side already exists.

PC-4 — Per-bundle-class concept-type set (S1, remit-3)

Make the validator’s base concept-type set bundle-class-scoped. Today EffectiveOntology.base_only() hard-codes the business ALLOWED_CONCEPT_TYPES (validator.py:246-250). Introduce a class→typeset registry (_CLASS_CONCEPT_TYPES: dict[BundleClass, frozenset[str]]):

client_business / showcase → the existing business set (unchanged).
system_baseline → frozenset({"schema", "tool", "api", "navigation", "playbook"}).
internal_dev → deferred (bl-478 parked).

EffectiveOntology gains base_for_class(bundle_class); base_only() stays as the client_business default so every existing call site is unchanged. The DR-054 overlay-union (compose) still widens per dimension but never runs for system_baseline — the overlay is rejected upstream (PC-6), so the effective ontology for a system run is exactly its class base. The RepoConceptKey __post_init__ (PC-1) validates concept_type against the same class set, so a mis-typed system concept fails before drafting. Parity note: the TS lib/ontology/concept-schema.ts:CONCEPT_TYPE_VALUES is business-bundle-scoped; either add a parallel SYSTEM_CONCEPT_TYPE_VALUES constant or document the TS schema as client-business-only. The {163.2} PLAN sizes this; DR-019’s closed-type posture generalises per class (doctrine S1).

PC-5 — Citation provenance: generalise `seen_anchors` to git-blob URLs (S3, KA2)

The BI-17 provenance model (enrich.py _mint / seen_anchors / _validate_citation) mints canonical:// DB-row anchors and rejects any citation not actually read this run. The system bundle’s citations are a different anchor scheme — git-pinned public-repo blob URLs and resolvable public doc pages — but the doctrine keeps the provenance discipline (“every citation is real”; KA2 names “the seen-anchors mechanism” explicitly). Proposed change: generalise the mint/validate pair to the git-blob provenance form, not bypass it.

RepoDocsSource.read_concept mints, for each backing artefact it reads, a git-blob anchor (<public-repo-blob-base>/<sha>/<path>#Lrange for E1, the doc-page URL for E2) into seen_anchors — the exact analogue of L-records’ per-row canonical:// mint. An artefact the run did not read cannot be cited.
_validate_citation accepts a git-blob/doc-page citation iff it is a seen_anchors member (same rule, new scheme), keeping cross-link validation against the list_concepts catalogue unchanged.
Hard rule (S3): the mint base is a PUBLIC host only. The private docs-site is never a mint source (only canonical-okf-internal, bl-478, may cite it). See OQ-1 — the public-repo blob base needs owner ratification before the tool/api/schema pillars can cite code blobs; pillars whose backing artefact is private-only cite a resolvable public doc page instead.

The first-5-concepts slice (§Testing, KA2) proves GLM-5.2 emits only seen_anchors git-blob URLs (zero hallucinated URLs) before the lane scales.

PC-6 — `OKF_BUNDLE_CLASS = "system_baseline"` + overlay rejection (remit-3, {132.36} boundary)

Mostly already enforced — verified, not net-new. The deployed producer sets OKF_BUNDLE_CLASS on the Coolify app; for the system bundle its value is "system_baseline" (bundle_writer.py:713 literal). write_bundle already raises on any discovered ontology-overlay.json unless bundle_class == "client_business" (bundle_writer.py:998), so the {132.36}/DR-054 boundary — system types NEVER admitted via the client overlay feeder — holds for free. id-163 work here is limited to: (a) threading the class value into the two producer-deployment configs (PC-7), and (b) a regression test asserting a system_baseline run with a planted overlay file fails loud (§Testing). No transport or overlay-admission change is proposed.

PC-7 — Repo mint, prove→pin→promote lane, deployment-mount union (composition, remit-4)

New platform-owned repo canonical-okf-system (DR-079 taxonomy row; platform owner). Bundle root carries the reserved CONFORMANCE.md + producer-generated index.md/log.md; no client ontology-overlay.json (PC-6).
Release lane = the existing prove→pin→promote via producer/publish.py — the same commit-local git_sync + separate push lane the client bundle uses (DR-055), but at platform-release cadence. Runtime env on the system producer deployment: OKF_BUNDLE_DIR = persistent-volume clone of canonical-okf-system, OKF_BUNDLE_DEPLOY_KEY_PATH = its RW deploy key, OKF_BUNDLE_CLASS=system_baseline, OKF_SOURCE_REPO_PATH = the platform repo/docs checkout (PC-2). Wiring point: the deployed producer resolves a single OKF_BUNDLE_DIR; running a second bundle class on the same VPS needs either a second bundle-dir+class config (a distinct forced-run invocation) or a per-run bundle-dir/class parameterisation — the {163.2} PLAN sizes which.
Consumption = deployment-mount union, already free. enumerateOkfBundles() unions every OKF_BUNDLE_ROOT subdir (verified above); the system bundle lands as one more sibling. Residual check (not an assumption): confirm the /okf landing + lib/okf/bundle-graph.ts render iterate all enumerated bundleIds and do not assume N=1 (multi-bundle render check, §Testing). Cross-bundle identity = bl-457 base-namespace IRIs (no cross-bundle markdown-link primitive; broken file-links spec-tolerated).

PC-8 — The gate: interim human sign-off → HC-5 concept round-trip on mcp-eval (S2, KA1, remit-5)

The doctrine’s Path-2 gate is born-evaluable HC-5 (agent reads concept → calls the real tool → behaviour matches) + CI regen + §9, with interim human sign-off until the round-trip is wired.

Interim gate = DR-016 override capture. Each concept’s human sign-off / correction is captured as a producer override (keyed by concept-path/section, git_sync.reapply_overrides) re-applied on every regeneration — the exact mechanism client bundles use for approved human edits. This is why “GLM-assisted authoring, then RepoDocsSource makes it regenerable” (S2) does not clobber the sign-off: the corrected body survives redraft as an override. Design slice in {163.2}: whether the whole body or named sections are override-captured.
Target gate = a net-new concept-roundtrip-set on scripts/mcp-eval/ (KA1 cost verdict). The matrix’s harness (fixtures.ts, seed-data.ts, plus the actor at lib/mcp/actor.ts imported by the harness) is reused; the new set, for each tool/api concept, resolves the concept → its cited tool (from the concept’s resource:/citation), invokes the real MCP tool through the existing actor, and asserts the observed behaviour matches the concept’s claim. Cost is additive, not a matrix re-architecture, but two genuinely-new pieces are named: (a) a machine-extractable “expected behaviour” assertion per concept — couples concept authoring to eval-assertability (the concept must carry, or the eval must derive, a structured round-trip claim); (b) a concept→tool-identity resolver. Verdict: bounded and cheap-ish, NOT free — 1 new eval-set file + a resolver + a per-concept assertion convention. Wire in ci.yml (per-release) vs eval-nightly.yml (nightly) is the doctrine’s open question (cost/latency); the KA1 one-tool prototype (§Testing) settles it. §9 conformance is the okf:validate checker (bundle-class-agnostic, reusable as-is).

PC-9 — A19 confidence + routing-hint frontmatter for system concepts (KA4, remit-7)

A19 confidence + the routing-hint frontmatter (purpose/task/audience, FRONTMATTER-WAVE) apply to both bundle classes (bl-477). For system concepts:

Confidence (DR-081a): the producer emits strong|partial only. derive_concept_confidence ({132.41}) generalises to the round-trip signal — a tool/api concept whose HC-5 round-trip asserts is strong; a concept drafted but not fully round-trip-grounded is partial. no-content/needs-SME stay human-reserved. KA4 design slice confirms this mapping before the {132.35} re-proof coupling.
Routing hints: system concepts populate audience = the consuming agent (id-71), purpose = navigate/invoke. The frontmatter builder already emits these fields; the change is populating them for the system type set, not new frontmatter machinery.

Testing and validation

Each doctrine scope item and key assumption maps to a concrete gate. Python: python3 -m pytest scripts/tests/ (worktree CWD — namespace-package hazard, scripts/CLAUDE.md). TS/eval: bun run test (never bun test) + the scripts/mcp-eval/ harness. Behaviour-first tests per test-philosophy.md.

KA3 — two-extractor prototype (S1 grain). Prototype RepoDocsSource over the tool pillar (41) + one doc pillar; assert list_concepts() enumerates the expected grain and the E1/E2 split covers both without a third concept model. A third family needed → escalate (do not proceed to the other pillars). Fixture-driven FakeRepo (mirrors LRecordsSource’s FakePool pattern, test_l_records_source.py).
KA2 / S3 — first-5-concepts citation discipline. Draft 5 system concepts on GLM-5.2/OpenRouter; assert every emitted citation is a seen_anchors git-blob/doc-page URL (zero hallucinated URLs), each resolves on a public host, and none references the private docs-site. This is the KA2 gate and the S3 hard-rule gate in one slice.
S4 — BI-18 delta-only re-run. A pure-unchanged re-run of the system bundle produces zero drafting calls and zero bundle churn (the {132.35} no-op protocol); a single backing-artefact touch (change its git blob SHA) redrafts exactly that one concept.
KA1 — one-tool round-trip prototype (S2 gate). Wire the concept-roundtrip-set end-to-end for one tool concept against the existing mcp-eval harness; assert read-concept → invoke-real-tool → behaviour-match passes, and measure the per-concept wiring cost before scaling to 41. Settles per-release vs nightly (doctrine OQ).
PC-4 — per-class type gate. validator accepts schema/tool/api/navigation/ playbook for system_baseline and rejects a business type (e.g. company) for it, and vice-versa for client_business — the closed set is class-correct in both directions.
PC-6 — overlay rejection. A system_baseline run with a planted ontology-overlay.json fails loud (asserts the bundle_writer.py:998 guard), proving the {132.36} boundary.
PC-7 — multi-bundle render check. With ≥2 sibling bundles under OKF_BUNDLE_ROOT, enumerateOkfBundles() returns both and the /okf render surfaces both (no N=1 assumption).
KA4 — A19 strong/partial design slice. derive_concept_confidence emits strong for a round-trip-passing system concept and partial otherwise; never no-content/needs-SME (DR-081a).
§9 conformance. okf:validate (--strict) passes on the generated system bundle — reused unchanged (bundle-class-agnostic).

Risks and mitigations

Public-repo citation base is unresolved (S3). The canonical working repo may be private (id-68 IP separation); a git-blob URL to a private repo does not resolve publicly, breaking S3. Mitigation: OQ-1 (below) — owner ratifies the public blob base before the E1 pillars author code-blob citations; until then E1 concepts fall back to public doc-page citations (E2 form). This gates the tool/api/schema pillars, not navigation/playbook.
seen_anchors generalisation touches the proven enrich path (PC-5). Changing _validate_citation risks regressing the L-records canonical:// discipline. Mitigation: the git-blob acceptance is an additive branch keyed on anchor scheme; the canonical:// path is untouched and covered by the existing enrich tests (isolation posture identical to the PRODUCER_* slices).
Second producer deployment / bundle-dir contention (PC-7). Running two bundle classes on one VPS with a single OKF_BUNDLE_DIR risks cross-writing. Mitigation: separate bundle-dir+class config (or per-run parameterisation); {163.2} PLAN decides. Memo namespaces are already per-coco.App (kh_pipeline_producer_forced), so drafting state does not bleed.
Concept→eval-assertability coupling (PC-8). If concepts do not carry a machine-extractable behaviour claim, the round-trip set cannot assert. Mit: make the assertion convention part of the concept frontmatter/authoring contract from concept 1 (the one-tool prototype forces the shape early).
concept-schema.ts parity drift (PC-4). A per-class Python type set that the TS side does not mirror can silently diverge. Mit: the schema-parity side-workflow (CLAUDE.md Deployment & CI) + an explicit parity note in PC-4.

Empirical verification

Scope (binding rule): external-library symbols only — not internal Canonical symbols, stdlib, or framework built-ins.

anthropic.AsyncAnthropic.messages.create(..., extra_body={"provider": …}) — the sole external-library API the drafting path depends on. Result: PRESENT / BEHAVIOUR-VERIFIED. Pinned anthropic==0.79.0 (requirements.txt). Import-and-call proven live in {132.35} on 17/07/2026 (image sha-35e1a9c1): the extra_body provider passthrough returned a 200 Anthropic-shaped GLM-5.2 reply through OpenRouter (z-ai/glm-5.2). id-163 reuses this exact call site with no signature change — re-verification is the {132.35} proof, not a new probe.
RepoDocsSource introduces no new external-library symbol. The git-blob-SHA change signal uses subprocess + the git CLI (stdlib + the reused git_sync.py:264 posture — not an external git library such as dulwich/ pygit2, neither of which is in requirements.txt). The bundle writer target is the same cocoindex[postgres]==1.0.7 localfs.declare_file FILE target already in use. No net-new external API to import-and-call.

No ABSENT / SIGNATURE_DRIFT findings — the spec is clear for ratification on the empirical-verification gate.

Open questions (owner ratification) + DR-intents

OQ-1 (blocks PC-5 E1 pillars) — the public citation base. DR-079 mandates “git-pinned public-repo blob URLs / resolvable public doc pages, never the private docs-site” (S3), but the canonical working repo’s public/private status (id-68) determines whether tool/api/schema concepts can cite code blobs at all. Owner must name the public blob base: (i) the canonical repo is public → cite directly; (ii) a public mirror/subset repo → cite the mirror; (iii) E1-pillar concepts backed by private-only code cite a resolvable public doc page instead. DR-intent candidate (hard-to-reverse citation-base ruling) — returned to the Orchestrator to write on main once the owner rules; not written in-branch.
OQ-2 (from the doctrine, PC-8) — round-trip eval cadence. Per-release (ci.yml) vs nightly (eval-nightly.yml) for the concept round-trip set — a cost/latency call the KA1 one-tool prototype informs. Doctrine leaves this open at bl-465 impl.

Follow-ups

internal_dev (bl-478, parked) — a second Path-2 class over the docs-site; the PC-2 source selector and PC-4 class registry are built to extend to it (its type set is deferred here).
TS concept-schema.ts per-class generalisation (PC-4) — if the app-side render needs the system type set, promote the parity note to a subtask.
{163.2} PLAN sizes: repo mint + CI, RepoDocsSource + the two extractors, the per-class validator set, authoring waves by pillar (~68 concepts), the concept-roundtrip eval-set wiring, and the promote-lane integration — sibling-only subtask dependencies.