Expose canonical Canon document-registration write surface

[chitcommit]

Problem

The Canon implementation already defines register_document / deprecated alias canon_register_document in chittyos/chittyentity/workers/chittyagent-canon/src/tools.ts, and the generated ChittyMCP inventory references the Canon registration tool. However, the currently connected Canon/ChittyMCP surface available to clients does not expose a usable Canon document-registration write action.

This blocks a governed flow such as:

draft/provisional Canon spec -> register_document -> canonical URI/registration receipt -> downstream projection sync

The immediate example is chittycanon://docs/tech/spec/chittyentity-projection-taxonomy: the normative spec can exist in GitHub, but live Canon registration cannot be completed through the active tool surface.

Required boundary

Do not add an ad hoc bypass or duplicate registry. Reconcile the existing Canon implementation through the canonical MCP/gateway projection with normal auth, ownership, approval, and audit controls.

Acceptance criteria

• Active Canon MCP projection exposes document registration using the existing Canon capability/contract.
• Canon read tools and write tools resolve through the same canonical service identity rather than a parallel endpoint.
• Write path enforces the applicable ChittyAuth/approval boundary and records provenance/audit metadata.
• A client can register a provisional spec and receive its canonical URI plus registration record/receipt.
• /health and /api/v1/status (or canonical MCP status equivalent) identify the live Canon projection used for the write.
• Generated MCP/tool inventory and actual exposed tool surface agree; drift is detectable.
• No new schema/database/service boundary is introduced unless existing canonical storage is proven insufficient.

Evidence

• Implementation: chittyos/chittyentity/workers/chittyagent-canon/src/tools.ts defines register_document.
• Generated inventory: chittyos/chittymcp/docs/generated/mcp-tool-inventory.json contains the Canon registration projection.
• Current client/tool exposure does not provide a callable Canon registration write surface.

Related

• chittyfoundation/chittycanon#49 — provisional ChittyEntity projection taxonomy.
• Follow the Capability Governor rule: one canonical capability, many controlled projections, no unmanaged clones.

[chitcommit]

Root-cause narrowing — 2026-08-23

Read-only verification shows the Canon write implementation is not missing server-side:

• Live Cloudflare chittymcp has SVC_CANON -> chittyagent-canon bound.
• Live deployed chittymcp bundle contains the canon SERVICE_MAP entry and per-service forwarding pipeline.
• Live deployed chittyagent-canon bundle contains registerCanonTools, register_document, deprecated alias canon_register_document, and registerDocument.
• chittymcp has no live MCP_REGISTRY binding, so current checked-in routing should use the static SERVICE_MAP (which includes Canon).
• The connected ChatGPT/portal tool catalog visible to this session exposes no Canon tools (codemode.tools() search for canon returns []), while the older generated inventory records Canon with five tools including document registration.

Revised failure class

Client/catalog projection drift, not missing Canon implementation and not a missing ChittyMCP service binding.

Do not patch around this by adding a second registration endpoint or bypassing Canon. The next repair should reconcile the ChatGPT/portal-connected MCP catalog with the live mcp.chitty.cc/canon/mcp surface, then verify tools/list includes register_document and that the connector projection refreshes it.

Additional deployment drift observed

Live chittymcp settings differ from GitHub source (compatibility_date 2026-04-27 live vs 2026-08-07 source; live tail consumers empty while source declares chittytrack). That is a separate deployment-reconciliation item and should not be conflated with the Canon tool-catalog defect.

No runtime mutation or redeploy was performed.