Status: reframed — work in flight in a separate Claude Code session
This issue's original premise (add routes to a Cloudflare Worker called mukoko-edge) was based on a pre-4.1.x topology that no longer applies. There is no mukoko-edge Worker. The platform layer is the Nyuchi Console monorepo at platform.nyuchi.com — see #58 for the canonical stack documentation.
What this issue actually represents now
The design-registry surface that needs to be exposed to consumers (Design Portal, @nyuchi/mzizi-cli, external adopters) lives in the canonical DB nyuchi_design_db (Supabase grjsboqkaywpwatvrzmy) and is accessed via the new function set built in #120:
| Function |
Role |
read_documents(collection, name, owner, dna_role, limit) |
one generic reader; RLS-enforced |
read_documents_jsonld(...) |
open interchange via schema.org / JSON-LD with stable @id URIs |
read_versions(collection, name, limit) |
version history beside each doc |
put_document(...) |
one versioned writer; doc + version in one atomic txn |
query_events(stream, since, limit) |
one event reader across all 5 streams |
emit_observability / emit_chaos / emit_healing / emit_issue |
typed, RLS-gated emitters |
log_release(...) |
one release logger |
record_doctrine_change(...) |
doctrine-edit version enforcer |
get_system_counts() |
live counts; no hardcoded numbers |
schema_org_type(collection) |
collection → schema.org @type |
Anything that previously routed through a /v1/design/* Worker now resolves directly to these RPCs (or to thin Nyuchi Console handlers that wrap them) — there is no separate gateway Worker to wire.
How the Console consumes the canonical DB
Nyuchi Console (platform.nyuchi.com — monorepo)
├── SvelteKit on Vercel Console UI
├── FastAPI servers Platform APIs (consume read_documents / put_document via Supabase service-role)
└── Cloudflare Workers Baked-in edge components
Supabase access pattern:
@supabase/supabase-js + service-role key as platform secrets.
Same pattern as existing Nyuchi Workers; no Hyperdrive (see FRD-35).
What's NOT part of this issue anymore
Related current work
Action
No execution work tracked here. Reframed as source-of-truth documentation describing how the Nyuchi Console consumes the Mzizi design registry via the canonical DB function set.
Status: reframed — work in flight in a separate Claude Code session
This issue's original premise (add routes to a Cloudflare Worker called
mukoko-edge) was based on a pre-4.1.x topology that no longer applies. There is nomukoko-edgeWorker. The platform layer is the Nyuchi Console monorepo atplatform.nyuchi.com— see #58 for the canonical stack documentation.What this issue actually represents now
The design-registry surface that needs to be exposed to consumers (Design Portal,
@nyuchi/mzizi-cli, external adopters) lives in the canonical DBnyuchi_design_db(Supabasegrjsboqkaywpwatvrzmy) and is accessed via the new function set built in #120:read_documents(collection, name, owner, dna_role, limit)read_documents_jsonld(...)@idURIsread_versions(collection, name, limit)put_document(...)query_events(stream, since, limit)emit_observability/emit_chaos/emit_healing/emit_issuelog_release(...)record_doctrine_change(...)get_system_counts()schema_org_type(collection)@typeAnything that previously routed through a
/v1/design/*Worker now resolves directly to these RPCs (or to thin Nyuchi Console handlers that wrap them) — there is no separate gateway Worker to wire.How the Console consumes the canonical DB
What's NOT part of this issue anymore
wrangler secret put DESIGN_SUPABASE_URLfor a standalone Worker — there is no standalone Worker/v1/design/*routes in mukoko-edge — mukoko-edge doesn't exist/v1/mcp/designroute plumbing — MCP rebuild is its own work in Rebuild Nyuchi Design MCP against the new function set (post-consolidation) #121Related current work
Action
No execution work tracked here. Reframed as source-of-truth documentation describing how the Nyuchi Console consumes the Mzizi design registry via the canonical DB function set.