carlos / platform Public

Migrated from github.com/carlosframework/platform issue #135, opened 2026-08-10. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".

Still outstanding: Platform binary rolls still need an operator to run per-deployment scripts by hand; ambient convergence covers tenant apps only.

---

The gap

Tenant apps already update ambiently: ship + promote → serial bump → boxes converge in seconds (PR #108). The platform itself is the one thing that doesn't. Today a platform release reaches a deployment only by an operator running per-deployment scripts from a pinfra checkout (roll-console.sh, update-platform-binary.sh, per-box SSM) — the 2026-08-10 versions-fix roll (8f64abd) was exactly this: one manual invocation per deployment, direct AWS access and all. That contradicts how everything else on CARLOS moves, and it doesn't scale past two deployments — customer fleets and the Pi make N deployments × M components of manual rolling.

Shape of the fix (sketch, needs a spec)

Make platform components tenants of their own machinery, and add ONE new primitive — an upstream feed:

1. Platform components as apps of the local ladder — console already is one (canary/console channel + unit-stamped route: adoption cycles it, failed restart rolls back per #117). The root carlos binary and aux daemons want the same shape; the box-side swap machinery already exists (carlos-stage.path / carlos-restart.path, armed by update-platform-binary.sh).
2. An upstream release feed each deployment follows — publishing a platform release writes signed manifests + artifacts to one well-known upstream (public bucket/URL). A small root-side follower per deployment mirrors upstream releases into the LOCAL bucket under the ops account and promotes them onto the local channels; from there the existing serial-bump + adoption + unit-stamp path delivers, bakes, and rolls back exactly as for any app.
3. Signing chain: upstream releases signed with a platform release key; deployments pin that pubkey alongside their own ReleasePub. Deployments already verify signed pointers — this extends the trust root, not the mechanism.
4. Operator control: follow stable by default, pinnable (a deployment that wants to hold a version just doesn't follow), canary-first per deployment (tito already carries a canary/platform-adoption channel from an earlier experiment — currently expired canaries riding ff61d3b-r2).

Why not just cron the pinfra scripts

The scripts are operator-side, need AWS credentials into every deployment's account, and bypass the ladder (no bake, no canary, no rollback contract). The follower model keeps each deployment sovereign: it pulls, verifies, and rides its own ladder — which is also the only shape that works for customer fleets (#73's adoption-over-the-edge direction) and boxes with no operator AWS access at all.

Blast radius

Root-side, fleet-wide, converge-grade — wants a spec in docs/superpowers/specs/ and the failed-restart/rollback contract extended to the root binary before anything ships.

Related: #73 (fleet API surface), spec §6 follow-up (auto-convergence of platform unit files), pinfra update-platform-binary.sh.

🤖 Generated with Claude Code