Skip to content

ID-71 Surface-Design Record

This record anchors the ID-71 surface-design decisions to their ratified outcomes. The first section formalises the Wave 0 carried PI-items ({71.6}); later waves append their own keep/refine/retire verdicts as they land.


Recorded 15/06/2026. Satisfies B-INV-42 (M42, PI-15 retire) and prepares B-INV-41 (M41, PI-13/14 fold). No KH code path was re-enabled or modified by this slice — it is a record + verification slice only. Verification was run read-only against the id71-id104 worktree (HEAD 8e9694770).

Decision (ratified 14/06/2026, OQ-4 Option A): PI-15 — per-tenant point-of-use derived-artefact generation (taxonomy-sync) — is RETIRED. It has been BROKEN since the {68.23} prompt relocation (the classification-prompt.md source was relocated private and now resolves via the KH_PRIVATE_DOCS_DIR bridge — confirmed in scripts/generate-classification-prompt-taxonomy.ts:6-8). It is retired in favour of the kb://taxonomy MCP resource serving grounded taxonomy access. No PI-15 code path is re-enabled by this slice.

No-live-consumer confirmation (B-INV-42 condition — expected: none, CONFIRMED none): No live runtime consumer depends on the broken per-tenant point-of-use derived-artefact path. Grep evidence (worktree id71-id104):

  • generate-taxonomy-snapshot / generateTaxonomySnapshot referenced in lib/, app/, components/, hooks/ (runtime surfaces): 0 hits. The per-tenant snapshot generators (scripts/generate-taxonomy-snapshot.ts, scripts/generate-entity-aliases-snapshot.ts) are dev/CI/deploy-time scripts only — they are NOT invoked from any runtime code path.
  • per-tenant/point-of-use taxonomy artefact references in lib/, app/, components/, hooks/: 0 hits.
  • The Python pipeline notes (scripts/cocoindex_pipeline/canonicalisation.py:130,277,297, extraction.py) document the per-tenant snapshot as gitignored, generated at point-of-use, ABSENT on fresh checkout/CI, and degrading gracefully to baseline-only — i.e. there is by design no committed artefact and no hard runtime dependency.

Disambiguation (NOT PI-15 — LIVE, left untouched): The taxonomy-sync admin-dispatch flow is a separate, LIVE, central mechanism and is not the retired per-tenant point-of-use surface. It comprises app/api/admin/taxonomy-sync/route.tslib/taxonomy/sync-trigger.ts (enqueueTaxonomySync) / lib/integrations/github-dispatch.ts (dispatchTaxonomySync) → .github/workflows/taxonomy-sync.yml (runs bun run sync:taxonomy, commits regenerated prompt/snapshot/plugin to main). It regenerates the canonical taxonomy artefacts centrally and is wired to nine taxonomy/layer API routes plus a taxonomy_sync_state table. This central flow is one of the things that supersedes the per-tenant approach; it is explicitly out of PI-15 scope and was not modified.

kb://taxonomy — named replacement (absorbs bl-52)

Section titled “kb://taxonomy — named replacement (absorbs bl-52)”

The grounded-taxonomy replacement is the kb://taxonomy MCP resource, registered in lib/mcp/resources.ts:457-459 (resource name 'taxonomy', URI literal 'kb://taxonomy'; description “The full taxonomy of domains and subtopics used to classify content”, lib/mcp/resources.ts:461-462). It reads taxonomy_domains and taxonomy_subtopics live from the DB under the caller’s RLS scope (lib/mcp/resources.ts:468-481). This absorbs bl-52 and serves the outcome (grounded taxonomy access) that the broken per-tenant artefact previously targeted.

PI-13/14 — branding / connector-ref inventory (STAGED for {71.13}; NOT renamed here)

Section titled “PI-13/14 — branding / connector-ref inventory (STAGED for {71.13}; NOT renamed here)”

Per B-INV-41 / M41, this is an inventory only — the actual rename is the bid→forms rename lockstep ({71.12}–{71.14}), landing in {71.13} (plugin lane 3+4). Nothing below was renamed by {71.6}.

No live client connectors today (clean-break premise — CONFIRMED). The plugin is tool-agnostic: CONNECTORS.md declares the ~~knowledge base placeholder and a single connector row (Knowledge Hub) with “Other options: —” (no third-party client connectors). There is no .mcp.json in the plugin tree (.claude/plugins/knowledge-hub/1.0.0/); the KH MCP server is the only pre-configured server. Therefore the PI-13/14 rename is a clean break with no live client-connector migration.

PI-13 stale plugin-branding surface that {71.13} folds in (under .claude/plugins/knowledge-hub/1.0.0/):

  • Plugin command files to rename: commands/bid-pipeline-review.mdform-pipeline-review.md; commands/bid-status.mdform-status.md.
  • Plugin skill to rename: skills/bid-writing/ (SKILL.md, QUICKREF.md) → completing-forms/ (WS-9 named generalisation).
  • Pervasive bid/Bid//kb:bid-status//kb:bid-pipeline-review branding inside command bodies that survive into other (kept) commands — e.g. commands/briefing.md (list_active_bids, “Active bid status”, /kb:bid-status), commands/search.md, commands/draft-response.md, plus the tool-name references in CONNECTORS.md (list_active_bids, get_bid_detail, get_bid_question → forms vocabulary) and the bid_preferences block in settings.template.json:34.
  • Generated artefact: lib/mcp/plugin-bundle.ts is a committed base64 plugin ZIP and is sandbox READ-DENIED in this environment (“Permission to use Bash … has been denied” on read; it is in the read deny-list). Its decoded bid string literals are therefore not directly inspectable here, but it is a generated artefact — bun run build:plugin regenerates it from the plugin source files above, so the source inventory is the authoritative rename surface; {71.13} regenerates the bundle (do NOT hand-edit it).

PI-14 connector-ref surface that {71.13} reviews: CONNECTORS.md (placeholder model + the 54-tool reference table, several rows of which carry bid-named tools that rename in {71.12}). No third-party connector definitions exist to migrate.

Verdict: PI-13/14 staged, not actioned. The drift-guard forces these into lockstep with {71.12}/{71.14} in the single atomic rename PR ({71.13}).


Wave 1 — Surface-design verdict ({71.11})

Section titled “Wave 1 — Surface-design verdict ({71.11})”

Recorded 15/06/2026. Satisfies B-INV-22/23/24 (verdicts anchor to outcomes, kept-concept ≠ frozen tool, retire-without-orphan), B-INV-25/26 (single human-facing server + Option-B deferral trigger), B-INV-28 (ontology-grounding affordance), B-INV-34 (layer placement), and the B-INV-43 / M-DEFER-O8 deferred-with-anchor entry. This is the outcome-anchored record for the full Wave-1 consolidation landed across {71.7}–{71.11}; the code for {71.11} shipped as commit 959bd585c on the id71-id104 track (branch worktree-agent-afff2e5cddfb3d713).

The outcome map used throughout (from PRODUCT.md §C/§D): O1 find/answer (W1.3 = ontology-grounded answering), O4 reorientation/briefing, O5 signal→action / intelligence-consumption, O6 exposure (five layers), O8 guides / knowledge-product authoring (W8.1 = guide tools, W8.4 = argument-quality). Per B-INV-22, every verdict below anchors to an O/W number; per B-INV-24, every retire names the surviving entry so no ranked outcome is orphaned.

VerdictOutcome / workflowSurviving entryRetired / folded entriesSubtask
REFINE (consolidate)O1 find/answerfind (type / scope / granularity / similar_to params)search_knowledge_base, search_qa_library, search_content_chunks, find_similar_items{71.7}
KEEP-CONCEPT (promote)O1 W1.3 ontology-grounded answeringget_entity_relationships + kb://entities (reframed as grounding affordances of the answering surface, discoverable alongside find)none retired — affordance promotion only (B-INV-28){71.11}
REFINE (consolidate)O6 exposurewhere_are_we_exposed (five-layer presentation, B-INV-4)get_freshness_report, get_expiring_content, get_coverage_gaps, audit_content, get_quality_summary, get_quality_briefing, get_quality_actions, get_certification_status{71.8}
KEEPO6 resolution loopsuggest_content_creation (kept as the resolution affordance on the exposure outcome, B-INV-4)none{71.8}
REFINE (one-queue + facet)governance/review queue (O6-adjacent triage)whats_in_my_queue (one queue, facet: content_quality / governance / all — B-INV-30)get_governance_queue, get_review_queue, get_assignments_for_user, get_dashboard_summary{71.9}
REFINE (one-or-many)content retrieval (accept step of O1 two-step)get (id single | ids batch, B-INV-32/33)get_content_item, get_content_items{71.10}
REFINE (one-or-many)ownership assignment (O6 curation)assign (assignment single | assignments batch)assign_content_owner, bulk_assign_owner{71.10}
REFINE (scope param)duplicate detection (O6 curation)find_duplicates (scope: item | all)find_duplicate_candidates, find_all_duplicates{71.10}
KEEP (procurement umbrella)O2 completing-forms reads (procurement, first form type)list_active_procurement, get_procurement_detail, get_change_report (kept as-is at launch; bid→forms rename is the {71.12}–{71.14} lockstep, not a retire)none retired — naming break deferred to the rename wave (B-INV-31)

No retire verdict above orphans a ranked outcome: each names its surviving consolidated entry (B-INV-24). “Keep-concept” for O1 W1.3 ships as a reframed/cross-referenced pair, not a frozen tool, consistent with B-INV-23.

Layer placement (B-INV-34) — tools / skills / apps / commands / prompts

Section titled “Layer placement (B-INV-34) — tools / skills / apps / commands / prompts”
  • Tools = ability. The consolidated entries above are the only place tool ability lives.
  • Prompts = thin orchestrators. {71.11} rewrote the prompt instruction text in lib/mcp/resources.ts so prompts orchestrate over the consolidated entries and name no retired tool: coverage_analysiswhere_are_we_exposed + suggest_content_creation; draft_responsefind + get; review_itemget; sector_briefingfind + find(type: "q_a_pair") + whats_in_my_queue(facet: "governance"). No prompt re-implements tool ability.
  • MCP Apps = visual density + WS-8 resolution surface. The four apps stay the visual-density layer. {71.11} updated mcp-apps/reorient-me drill-downs to call the consolidated entries (where_are_we_exposed, get) and regenerated the committed lib/mcp/app-bundles.ts. No app duplicates a tool without density/resolution value.
  • Plugin /kb:* commands = thin orchestrators (DEFERRED to {71.13}). The plugin command bodies still name retired reads (search_knowledge_base, search_qa_library, get_governance_queue, get_freshness_report, get_quality_summary, get_dashboard_summary in search.md / draft-response.md / sector-briefing.md / coverage.md / change-report.md). Editing them requires regenerating the committed lib/mcp/plugin-bundle.ts (the bundle lockstep) — and these same files are the bid→forms rename surface staged for {71.13} (Wave 0 record above). To avoid a source/bundle drift and a collision with the rename wave on identical files, the {71.11} Executor deferred the /kb:* command thin-orchestrator alignment to {71.13}, which owns both the bundle regeneration and the bid→forms rename of these commands. (plugin-bundle.ts is also sandbox read/write-denied in the worktree-Executor environment, so regeneration is not possible from {71.11}.)
  • Plugin skills = expertise layer. Unchanged by {71.11}.

Single human-facing server + fleet-additive (B-INV-25)

Section titled “Single human-facing server + fleet-additive (B-INV-25)”

The human-facing surface is a single outcome-grouped MCP server (Option A): all tools are registered on one server via registerTools (lib/mcp/tools/index.ts), exposed at /api/mcp/mcp. No second connector ships at launch. Option C’s headless-agent fleet is layered on this same server additively — it consumes the same consolidated entries; it does not introduce a parallel surface. Pass condition (B-INV-25): one human-facing server; fleet additive on it; no second connector at launch — HELD.

Option B (a consumption/admin audience split into two connectors) is deferred. The revisit trigger is recorded: Option B is reopened only when the admin and consumption auth/role surfaces diverge enough to warrant a second connector — i.e. when the role/permission model for admin/curation actions diverges materially from the consumption (read/answer) model such that a single server’s annotation + role-gating discipline can no longer cleanly serve both audiences. Until that divergence is observed, the single-server shape (B-INV-25) stands.

B-INV-43 / M-DEFER-O8 — deferred-with-anchor (O8 W8.4 argument-quality checking)

Section titled “B-INV-43 / M-DEFER-O8 — deferred-with-anchor (O8 W8.4 argument-quality checking)”

O8 W8.4 — argument-quality checking (an O8-side quality check over a drafted guide/argument) is recorded DEFERRED-WITH-ANCHOR — not a launch deliverable. WS-3 ratified argument-quality checking as wanted tooling; the strawman ranks O8 (guides / knowledge-product authoring) at rank 8, below the O1/O4/O6 launch set and the O5/O9 differentiators. The existing O8 W8.1 guide tools (list_guides / get_guide / create_guide / update_guide, plugin skill guide-builder) are kept; W8.4 has no current surface and ships NO launch slice.

  • Anchor: B-INV-43 (PRODUCT.md §G) / M-DEFER-O8 (TECH.md §M — deferred anchor, no launch M-change).
  • Graduation pointer: graduates as an O8 affordance in a later group (own-Task or a guide-tooling Task), not pulled into the ID-71 launch set without a ratified scope change.
  • Born-evaluable requirement: when W8.4 lands it is built born-evaluable against an ID-104 eval (B-INV-13/40).

Pass condition (B-INV-43): W8.4 carried as a numbered deferred-with-anchor outcome with an own-Task/later-group pointer and the born-evaluable requirement noted — HELD. It is neither silently dropped nor pulled into the launch set.