mc/metacircular
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Mark Phase B complete in PLATFORM_EVOLUTION.md

Browse Source 
Agent now registers/removes routes with mc-proxy automatically
during deploy/stop. Phases A and B are both complete.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Kyle Isom
2026-03-27 01:37:56 -07:00
parent b17472122b
commit 21e2aadeb5
1 changed files with 33 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
PLATFORM_EVOLUTION.md
View File

@@ -5,7 +5,7 @@ from its current manually-wired state to fully declarative deployment.
It is a living design document — not a spec, not a commitment, but a It is a living design document — not a spec, not a commitment, but a
record of where we are, where we want to be, and what's between. record of where we are, where we want to be, and what's between.
Last updated: 2026-03-27 (Phase A complete) Last updated: 2026-03-27 (Phases A + B complete)
--- ---
@@ -202,18 +202,18 @@ Agent allocates host ports automatically at deploy time:
- Registry: `component_routes` table with `host_port` tracking - Registry: `component_routes` table with `host_port` tracking
- Runtime: `Env` field on `ContainerSpec`, `-e` flag generation - Runtime: `Env` field on `ContainerSpec`, `-e` flag generation
#### 3. MCP Agent: mc-proxy Route Registration #### 3. MCP Agent: mc-proxy Route Registration — DONE
**Gap**: mc-proxy routes are static TOML. The gRPC admin API exists but Agent connects to mc-proxy via Unix socket and automatically manages
MCP doesn't use it. routes during deploy and stop:
- Deploy: after container starts, calls `AddRoute` with hostname,
**Work**: backend (`127.0.0.1:<host_port>`), mode (l4/l7), and TLS cert paths
- Agent calls mc-proxy gRPC API to register/remove routes on - Stop: calls `RemoveRoute` before stopping containers
deploy/stop. - Config: `[mcproxy] socket` and `cert_dir` in agent config
- Route registration includes: hostname, backend address (node address - Nil-safe: if socket not configured, silently skipped (backward compatible)
+ assigned port), mode (l4/l7), TLS cert paths. - L7 routes: mc-proxy terminates TLS using certs at `<cert_dir>/<service>.pem`
- L4 routes: TLS passthrough, backend handles its own TLS
**Depends on**: port assignment (#2), mc-proxy route persistence (#5). - Hostnames default to `<service>.svc.mcp.metacircular.net`
#### 4. MCP Agent: TLS Cert Provisioning #### 4. MCP Agent: TLS Cert Provisioning
@@ -271,19 +271,18 @@ needs the account created).
#### 8. MCNS: Record Management API #### 8. MCNS: Record Management API
**Gap**: MCNS is a CoreDNS precursor serving static zone files. There **Gap**: MCNS v1.0.0 has REST + gRPC APIs and SQLite storage, but
is no API for dynamic record management. records are currently seeded from migrations (static). The API supports
CRUD operations but MCP does not yet call it for dynamic registration.
**Work**: **Work**:
- MCNS needs an API (REST + gRPC per platform convention) for - MCP agent calls MCNS API to create/update/delete records on
creating/updating/deleting DNS records. deploy/stop.
- Records are stored in SQLite (replacing or supplementing zone files). - MCIAS auth scoping to allow MCP agent to manage
- MCIAS auth, scoped to allow MCP agent to manage
`*.svc.mcp.metacircular.net` records. `*.svc.mcp.metacircular.net` records.
**Depends on**: this is the largest gap. MCNS is currently a CoreDNS **Depends on**: MCNS API exists. Remaining work is MCP integration
wrapper, not a full service. This may be the right time to build the and auth scoping.
real MCNS.
#### 9. Application $PORT Convention — DONE #### 9. Application $PORT Convention — DONE
@@ -309,9 +308,8 @@ Phase A — Independent groundwork: ✓ COMPLETE
#5 mc-proxy route persistence ✓ DONE #5 mc-proxy route persistence ✓ DONE
#9 $PORT convention in applications ✓ DONE #9 $PORT convention in applications ✓ DONE
Phase B — MCP route registration: ← IN PROGRESS Phase B — MCP route registration: ✓ COMPLETE
#3 Agent registers routes with mc-proxy #3 Agent registers routes with mc-proxy ✓ DONE
(depends on #2 + #5 — both done)
Phase C — Automated TLS: Phase C — Automated TLS:
#7 Metacrypt cert issuance policy #7 Metacrypt cert issuance policy
@@ -324,25 +322,21 @@ Phase D — DNS:
(depends on #8) (depends on #8)
``` ```
**Phase A is complete.** Services can be deployed with agent-assigned **Phases A and B are complete.** Services can be deployed with
ports and `$PORT` env vars. mc-proxy routes must still be registered agent-assigned ports, `$PORT` env vars, and automatic mc-proxy route
manually via `mcproxyctl` or the gRPC API. registration. No more manual port picking, mcproxyctl, or TOML editing.
**Phase B is next.** The agent will call mc-proxy's gRPC API to The remaining manual steps are TLS cert provisioning (Phase C) and
register/remove routes automatically during deploy/stop. This DNS registration (Phase D).
eliminates the last manual networking step — no more `mcproxyctl`
or TOML editing.
After Phase C, cert provisioning is automatic. After Phase D,
`mcp deploy` is fully declarative.
### Immediate Next Steps ### Immediate Next Steps
1. **Phase B: MCP agent route registration (#3)** — agent connects to 1. **Phase C: Automated TLS** — Metacrypt cert issuance policy for MCP
mc-proxy via Unix socket, registers routes on deploy, removes on agent, then agent provisions certs automatically during deploy.
stop. TLS certs are pre-provisioned (Phase C automates this later). 2. **Phase D: DNS** — MCNS record management API integration, then
2. **mcdoc implementation** — fully designed, no platform evolution agent registers DNS records during deploy.
dependency. Deployable with a manually assigned port today. 3. **mcdoc implementation** — fully designed, no platform evolution
dependency. Deployable now with the new route system.
--- ---