The console is an app — retiring the pinfra roll

Date: 2026-08-23 · Status: approved (Paul, in-session); reworked after a Fable review · Slice: 1 of 4

Problem

Every tenant deploys with one command and no infrastructure access. The platform deploys itself with a bash script, an AWS profile, an SSM session and a checkout of a second repository.

tenant:   carlos deploy -app blog
platform: roll-console.sh <platform-checkout> both     # pinfra + AWS + SSM

That inversion is the thing CLAUDE.md's own rule complains about ("every carlos command is designed for a user with no access to the underlying infra"), and it costs more than convenience: a special door is where our own deficiencies hide. Everything that makes rolling the console feel dangerous — a version header that lies, a restart nobody trusts, a rollback verified by hand — is a deficiency tenants have too. They just complain less. While the platform team has its own door, nothing forces us to feel it.

This slice makes the console an ordinary app, deployed by the ordinary verb.

Three of the five fixes below (honest build verification §3, the dirty-tree guard §7, and the restart-recovery fix §4b) are tenant fixes that this work merely forces us to make.

Not in this slice

carlos system is deferred, not rejected (Paul, 2026-08-23). It earns its place for what genuinely cannot be an app: the root carlos binary, the edge router, the activator, the provisioning reconciler. Those have no route, no channel to be adopted from and no upstream — they are the substrate that does the adopting and routing. update-platform-binary.sh is 85 lines of exactly that work, none of which has an app-shaped equivalent. That is slice 3.

The dividing line, stated once so later work can apply it: carlos system is for what is not an app. Anything adoptable through a route is an app.

The test the design must pass

roll-console.sh and verify-console.sh encode failure modes this project has already paid for. A replacement that drops any of them is a regression wearing better clothes.

| # | Failure mode | Covered by | |---|---|---| | 1 | amd64 artifact shipped to Graviton boxes | §5 ELF refusal (-target default only helps the careful caller) | | 2 | Adoption swaps the symlink; the old process keeps serving | §4a — the right route stamped | | 3 | SSM shells missing set -a; source host.env | No SSM at all | | 4 | "Verified" reported from a stale binary | §3 build probe | | 5 | A dirty tree stamping a version naming no real commit | §7 | | 6 | sysusers before tmpfiles | Not reached — root-binary concern, slice 3 | | 7 | The console artifact is cmd/console, not the root binary (8-minute outage, 2026-08-08) | §5 embedded-build refusal |

1. What is actually in the way

Verified against the live estate on 2026-08-23. See the appendix for the raw readings.

The console is already structurally an app. Releases at apps/bab/console/, properly account-qualified under ops, on channel canary/console, adopted by the same pass as every tenant, served through routes, one route already naming console.service.

*But it is not an app record.* ops on flagship holds two app rows: deploy-probe and platform-site. There is no console row, because ship-app.sh ships direct-to-bucket and direct mode deliberately skips the claim. Without a row the console API cannot see the app at all.

Claiming the name is refused today by claimApp (internal/console/server.go:2426) because the prefix has objects — issue #79.

The other three pinfra apps need no claim. Contrary to CLAUDE.md's framing of four equivalent apps, kass, keymail and platform-site are already claimed rows with live channels. They are on ship-app.sh out of habit.

2. Claiming an app whose objects already exist (#79)

claimApp's bucket guard is right for a stranger and wrong for the account that owns the prefix. apps/<sqid>/<app>/ is namespaced by account, so objects under apps/bab/ can only be ops's. An owner of bab claiming a name under bab's own prefix is adopting their own objects.

// today — always refuses
if len(keys) > 0 { return claimTaken, "" }

// after — unless the claimer owns the account the prefix belongs to
if len(keys) > 0 && !ownerClaim { return claimTaken, "" }

ownerClaim is passed by the caller. Five constraints, each of which a naive implementation gets wrong:

• Owner, not member. Adopting existing release history is an ownership act.
• ownerClaim is FALSE for every service principal. A service has no role at all, and an account-scoped PrincipalService with App == "" legitimately reaches claimApp (apicli.go:346–350 blocks only app-scoped ones). Without an explicit pin, the exemption silently hands every CI credential the power to adopt release history — exactly the widening the svcrole work exists to prevent.
• handleNewApp (the browser door) must be changed deliberately, not incidentally. It currently discards the role (addr, raw, acct, _, ok := s.account(…), server.go:2524) and its doc comment says "Any member may claim." The exemption changes that door's stated policy; the comment changes with it.
• The legacy prefix still blocks, always. For ops, claimApp also checks release.LegacyAppPrefix(name) — apps/<app>/, unqualified. Those objects predate account scoping and are owed an accounts migrate -from legacy. The exemption applies only to the account-qualified prefix.
• HasOwners(name) still blocks. A CLI-granted app in ops stays claim-proof.

Refusals stay byte-identical for non-members. The new branch runs after the owner gate, so only someone who has already proved ownership can reach it.

What this does and does not unblock. Verified: the owners table holds grants for derp, meep and platform-site only. So the exemption unblocks console, carloku, carlosframework, keymail (the bab prefix), hello and apt-carlosframework; derp and meep stay claim-proof by design. An earlier draft claimed otherwise and was wrong.

One nuance to absorb: a trashed app passes HasAppIn (which filters deleted_at = 0) and is caught later by CreateAppIn's ON CONFLICT DO NOTHING (store.go:1120–1128) → claimTaken. No hole, but after the exemption a trashed-name claim burns a bucket listing before hitting that refusal. Acceptable; noted so it is not mistaken for a bug.

Test: an owner claims a name whose account-qualified prefix has objects and succeeds, release history immediately visible through channels; a non-owner member gets claimTaken; a service principal gets claimTaken whatever its scope; a non-member gets the byte-identical 404; a name whose legacy prefix has objects is refused even for an owner; a name with an owners row is refused even for an owner.

3. Honest verification: the console reports its own build

Both cheap answers lie. X-Carlos-Version is stamped by the edge (edge.go:1336–1341) from the route row, so adoption sets it while the old process keeps serving. systemctl is-active reports "active" for a process started from the previous version just as happily — on 2026-08-09 tito said "active" while /proc said 9668d30, seconds after adopt and restart both reported success.

A carlos deploy -app console waiting on X-Carlos-Version would be less trustworthy than the bash it retires. So the console reports its own build, from the process, compiled in:

GET /healthz  →  ok <build>          # today: "ok"

At least as strong as the /proc check and arguably stronger: /proc proves which path is executing, this proves which code is, from internal/version.Build set by ldflags in the same build. Nothing but the running process can answer it.

/healthz is served by the console's own mux (server.go:794), not the edge. Existing consumers (internal/vet, the edge health probe) check status only, so appending the build is additive-safe. The build id is not a secret — X-Carlos-Version already exposes it on every response.

3a. Where the probe is declared, and who parses it

carlos deploy's watch gains a second exit criterion: when the app declares a build probe, poll it instead of the header.

{"build_probe": {"path": "/healthz"}}

The path is the only thing that varies. The contract is fixed: a 2xx whose body contains the build id as a whitespace-delimited token. Not a regex, not a JSON pointer, not a header name — each is a knob whose wrong setting produces a watch that passes while proving nothing. Token-matching rather than substring is load-bearing: a substring match lets build abc123 satisfy a watch waiting for abc1234, and short git shas make that a real collision.

Storage, and the consumer list — CLAUDE.md's rule is that when a storage shape changes, the consumer list is everything that PARSES the shape:

The probe is app-level, not per-instance. The health probe it resembles lives in provision.Record (internal/provision/provision.go:33, wire key "probe", at apps/<sqid>/<app>/instances/<host>.json) and that is the wrong home for this: handleAPIInstanceUpdate is a read-modify-write of the record, so an older console rewriting a newer record would silently drop the field. The build probe describes the app, not one instance of it, and every instance would carry an identical copy.

It therefore lives on the app row, served to the CLI on the existing per-app API the deploy path already calls, and is not a bucket object at all. Parsers: the app row's own query (which names columns explicitly — verified, no SELECT *), the API handler that serves it, and carlos deploy's watch. Three, all in-repo, none of them a wire shape a box parses. That is the point of choosing the row over the record.

3b. Two ways the watch can still lie, and what closes them

The ldflags trap. carlos deploy ships a binary the operator built. -version defaults to gitShortHead() (deploy.go:52) but version.Build comes from ldflags the operator must remember (default "dev", internal/version/version.go:6). Build without the flag and the roll succeeds while the probe reports ok dev forever — deploy reports failure on a healthy deploy, the exact inverse of the lie §3 exists to kill. Closed twice: §5's ship-time refusal when the embedded build ≠ -version, and a watch timeout that names what the probe actually said (a body of dev is then self-diagnosing).

The edge cache. watchVersion cache-busts every poll because the edge caches proxied 2xx responses up to five minutes (deploy.go:1013–1022, edge.go:933). The console's /healthz sends no Cache-Control so it is safe today, but §3 is a tenant feature and a tenant's probe path may not be. The probe leg inherits the buster, and reads the body through the default transport so gzip is transparently decoded.

Test: the watch reports live only once the probe body carries the shipped build as a whole token; abc123 does not satisfy a watch for abc1234; a probe stuck on the previous build times out with a diagnosis naming both the expected build and the body received; an app with no probe keeps today's header behaviour byte for byte; the probe leg sends a cache-buster.

4. Restart, rollback, and the recovery hole

makeRestartRoute arm 1 (internal/host/agent.go:2041–2050) try-restarts a route that names its unit and returns the failure, so adoptHost poisons the build, repoints the symlink back and skips SetVersions (adopt.go:779–818). That much is built, and it is what makes a lying header impossible in that case.

It is a much narrower guarantee than it looks, and an earlier draft of this spec overclaimed it. Two holes, both verified.

4a. The guarantee only covers systemd-visible start failure

systemctl try-restart on a Type=simple unit succeeds the moment the process is exec'd. A console that starts and then panics on its first request, exits after a half-applied migration, or listens and 500s, exits 0. Then SetVersions stamps the new build fleet-wide, the §3 probe correctly times out — and nothing rolls back. The symlink stays on the broken build, the next pass early-returns on cur == ver (adopt.go:637), and the repair door is the thing that is down.

Requirement: console.service gains a readiness gate so that "started but not serving" becomes a failed start. Type=notify with the console signalling readiness after migrations have applied and the listener is up is the precise form; an ExecStartPost readiness poll is the cheap form.

This is a pinfra change plus a cmd/console change, and it is a cross-repo dependency this spec owns. It cannot be assumed: console.service is defined in pinfra, not in internal/host/units/, and its current Type= is not recorded anywhere in this repo. Step 0 reads it.

The residual after this — a console that starts, serves, passes readiness and is behaviourally wrong — has no automatic recovery and is break-glass (§9). Say so out loud rather than implying the rollback covers it.

4b. Rollback repoints the symlink but leaves the console DOWN — and the next pass then lies

This is the more serious of the two and it is not in the review that prompted this rework; it was found verifying that review.

On restart failure adoptHost repoints the symlink to cur and returns (adopt.go:781–815). It does not start the unit again. For a try-restart that failed to bring the service back, systemd leaves it failed — so the box is left with a correct symlink and no console.

It gets worse on the next pass. try-restart is by definition a no-op on a unit that is not running (the property makeRestartRoute's comment relies on so that a deliberately-stopped console stays stopped). So:

pass 1:  PointLive(new) → try-restart → FAILS → poison, PointLive(old), no stamp
         unit: failed.  console: DOWN.  header: honest (old).
pass 2:  PointLive(new) → try-restart on a NOT-RUNNING unit → no-op, exit 0
         → SetVersions(new)
         unit: still failed.  console: STILL DOWN.  header: claims the new build.

The second pass converts an honest failure into the exact lie the whole mechanism exists to prevent, over a console that is not running at all.

Requirement: when arm 1's try-restart fails and the symlink has been rolled back, adoption must start the named unit on the restored version — a systemctl start, not a try-restart, because the whole point is that the unit is down. If that start also fails, the version stays poisoned and unstamped and the failure is printed; the box is then genuinely broken and break-glass is correct.

This is a tenant fix. Any bespoke unit-backed route has this hole today. It is the strongest argument in the whole slice for making the platform eat its own food: the hole has presumably been there since #110 and nobody found it, because the pinfra script's explicit post-pass systemctl restart has been papering over it on the only unit-stamped route in the fleet.

Test: a failed named-unit restart leaves the unit RUNNING on the previous version, the symlink on the previous version, and the row unstamped; a second pass over the same still-broken build does not stamp; a failed rollback start is reported and still does not stamp.

4c. One process, several hostnames — the stamped route is not a free choice

The console is one console.service behind several hostnames. Adoption is per host (reg.List(), ORDER BY host, registry.go:604), and each adoptHost repoints live/<that host> (PointLive(optDir, rt.Host, …)) and then fires the restart callback.

So the restart fires inside one host's adoption, while the other hosts' symlinks have not moved yet. Which means:

> The route that must carry the Unit stamp is the host whose symlink the > unit's ExecStart resolves — not the canonical hostname, not the first > alphabetically.

Flagship today gets this wrong, and the pinfra script has been hiding it:

ExecStart = /opt/carlos/live/platform.carlosframework.com serve
stamped   = console.carloku.com          ← sorts BEFORE platform.…

The pass restarts at console.carloku.com (2nd of 4 by host order), when live/platform.carlosframework.com still points at the old build; that symlink moves last, under an already-running process. Every roll to date has worked only because roll-console.sh runs an explicit systemctl restart console after the whole pass. Remove that line — which is precisely what "the console is an ordinary app" means — and the console keeps serving the old build while all its routes advertise the new one.

Requirement: step 0 verifies, per box, that the Unit-stamped route is the host named in ExecStart, and restamps if not. Exactly one route is stamped: one is sufficient to cycle the process, and stamping several would try-restart the same unit several times in one pass.

The unstamped rows' X-Carlos-Version then becomes cosmetic, which §3 makes harmless. One honesty note: on restart failure the poison map only stops later hosts in the pass from stamping (adopt.go:648), so whether the cosmetic headers stay honest depends on alphabetical order relative to the stamped host — protection by accident, not by design. The real fix is the follow-up below.

Follow-up to file, explicitly out of scope: teach the pass to collect named-unit restarts and run them once, after every host's symlink has moved. That makes the stamp/ExecStart coupling and the alphabetical accident both irrelevant, and it is the general fix for any bespoke service behind several hostnames.

5. Ship-time refusals for a control-plane app

Two refusals, both at the ship door, both scoped to apps carrying the §6 flag.

Architecture. Read the artifact's ELF header and refuse a machine type that does not match the declared -target. -target linux-arm64 being carlos deploy's default only protects the careful caller; this closes the path a hand-run carlos ship, a CI job or a future script takes into the same channel.

Embedded build. Refuse a binary whose embedded internal/version.Build does not equal the -version being shipped. This closes §3b's ldflags trap at the door instead of at a timeout, and it incidentally closes failure mode #7: the root carlos binary and cmd/console stamp the same version.Build, so this does not catch a wrong-artifact ship on its own — but combined with the probe (only cmd/console serves /healthz) the pair does.

Scoped to control-plane apps deliberately: a tenant may legitimately ship an artifact we would guess wrong about, and refusing their ship on our inference is not our call. For the app that is the control plane, on boxes we own and know are arm64, it is.

Test: an amd64 ELF with -target linux-arm64 is refused naming both the declared target and what was found; a binary whose embedded build ≠ -version is refused naming both; a matching artifact ships; a non-control-plane app is unaffected; a non-ELF artifact (a static tarball) is unaffected.

6. The control-plane flag gates DESTRUCTION, not promotion — and narrows a service principal's authority

ALTER TABLE apps ADD COLUMN control_plane INTEGER NOT NULL DEFAULT 0;

An earlier draft had this flag demand fresh auth to promote, "exactly as stable already does, at every rung." That was wrong, and wrong in a way that defeated the spec's own purpose. stable's API gate is a bare 403 with a console_url and no API-side step-up (apicli.go:632–638), and carlos deploy log.Fatalfs on a failed promote after the ship has already landed (deploy.go:206–208). Extending it to every rung would mean carlos deploy -app console ships the artifact and then dies, every time — the exact command this spec exists to create.

Invert it. Deploying the console should be easy; destroying it should be hard. That is also where the real danger is: handlePurgeApp (ownership.go:293) can delete apps/bab/console/** — the release history the fleet is currently running — behind an owner check, a typed name and fresh auth, none of which knows this app is the control plane.

An app carrying the flag:

• refuses trash, purge, rename and transfer outright. Not "with fresh auth" — refused, with a message saying the flag must be cleared first. The console's release history is not something to delete behind a confirmation dialog.
• refuses promotion by a service principal. A person with ops membership can roll the console; a CI credential cannot. This closes the hole §10 step ordering would otherwise leave open, without a step-up flow.
• refuses an instance-record DELETE outright (added mid-rollout, 2026-08-28). This is the eighth door and the shortest fuse of the set. carlos deploy resolves hosts through apps/<sqid>/<app>/instances/<host>.json, so making the console deployable means giving it a record — and a record is an authority transfer: once it exists and the route is Provisioned, the provisioning reconciler's removal phase retires the route the moment the record goes. DELETE /api/cli/apps/{account}/{app}/instances/{host} is svcrole.Allow(svcrole.Instance), so one call from a person or a CI credential holding that role took the control plane off the air. Same class as trash and purge; same refusal. The console must not become instance-backed until this guard is in place.
• refuses an instance CREATE or PATCH by a service principal. A person must be able to write the console's record — that is the runbook step the whole §10 sequence turns on — but a CI credential must not acquire the reconciler's authority over the console's route, and PATCH is a repoint: the reconciler converges a route's Channel and Environment from this record on every pass. Same person/service split as promote, for the same reason.
• refuses a domain DETACH outright, and a domain ATTACH by a service principal. DELETE /api/cli/apps/{account}/{app}/domains/{host}'s first-route branch calls the same provision.DeleteRecord the instance delete does, and POST .../domains's first-route branch writes a declared record — both registered svcrole.Allow(svcrole.Publish, svcrole.Instance), so a service credential reaches either. Guarding the instance family and leaving these open would be a guard with a published way round it. Detach's browser twin (detachDomain) carries the same outright refusal; attach's needs none, because a browser session's principal is always a person. Neither guard is conditional on the record-touching branch: a conditional would have to re-derive "does this claim mint the app's route" ahead of the code that derives it, and the two would drift.
• gets §5's two ship-time refusals.

The closure principle — read this before adding a tenth door. The set above is not a list to extend by taste; it is the provision.Record lifecycle, closed. A record is what grants the provisioning reconciler authority over a route, so every door that CREATES, MUTATES or REMOVES one for a flagged app carries a guard: create (POST .../instances, POST .../domains) and mutate (PATCH .../instances/{host}) refuse a service principal, because a person performing them is a legitimate operator act; remove (DELETE .../instances/{host}, DELETE .../domains/{host}) refuses outright, because removal is destruction and belongs with trash and purge. A future door that touches that lifecycle needs the same guard by the same argument, and one that does not, does not.

Two lifecycle sites carry no control_plane call and are still covered, which is worth writing down so the next audit does not read them as gaps. POST .../instances/{host}/channel (channelmove.go) MUTATES a record, and is registered with the zero svcrole.Set{} — no service principal reaches it at all, admin included, which enforces the service half more strictly than a refusal would; a person repointing the control plane's channel is the same legitimate operator act as promoting it. And rollbackAttach (domainattach.go) deletes a record, but it is not a door: it is the compensating delete inside the attach path, reachable only once that path's own guard has passed, and it removes only the record the same call just tried to write — guarding it would strand half-written attaches instead of protecting anything.

Promotion by a person is gated by ops membership, which is already the operator boundary, and by nothing else. That is what keeps carlos deploy -app console working as an ordinary command.

How the flag is set. Not by a box-local sqlite write — that contradicts the no-box-commands corollary. It is set at claim time: carlos apps create gains -control-plane, owner-only, and the console's app settings page can clear it (clearing is the dangerous direction, so clearing requires fresh auth; setting does not).

Test: trash/purge/rename/transfer on a flagged app are refused naming the flag; the instance-record DELETE is refused for a person AND for a service, and the record survives; a domain detach is refused for a person and a service at the API door and for the owner at the browser door, and the claim survives; a service principal's promote, retention change, instance create, instance patch and domain attach are each refused — the attach in BOTH request shapes, alias and first-route, since the guard is not conditional on the branch — and each for both service roles the domains routes admit; a person's promote at any rung succeeds with ordinary membership, and a person can still CREATE and PATCH the flagged app's instance record and ATTACH a domain to it — asserted on the stored record and the stored claim, not on a status code, because that half is the runbook step the flag must not break; on every service-refused and outright-refused door, clearing the flag lets the IDENTICAL call through, which is what proves the flag is the only variable; clearing the flag requires fresh auth; setting it requires owner; an unflagged app is unaffected in every case; and every refusal sits behind the existing 404, so a non-member probing any of these doors gets the byte-identical not-found and never learns the flag's existence.

7. The version stamp and the dirty tree

roll-console.sh refuses a dirty tree because the version stamp is the git short sha, and a stamp naming a commit the binary does not match is how a false "verified" happens. carlos deploy already defaults -version to gitShortHead() and inherits the convention — but not the guard.

carlos deploy refuses to ship when -version was derived from git and the tree is dirty. An explicit -version is the operator saying they mean it, and is not second-guessed.

A general fix: any tenant using the default stamp today can ship a binary whose sha names a commit it was not built from.

Test: dirty tree + derived version refuses before anything ships; dirty tree + explicit -version ships; clean tree ships.

8. The migration has an ordering trap

store.go's migrate() runs its ALTER TABLE apps block (lines 198–219) before migrateAppsKey() (line 231), whose rebuild copies an enumerated column list into apps_new (271–288) — and the code already carries a comment about this hazard at line 280.

Add control_plane to that ALTER block and any database that has not yet been through the rebuild — a self-hoster jumping versions — has the column silently dropped, after which every SELECT control_plane errors.

Requirement: either add the ALTER after migrateAppsKey(), or add the column to apps_new and its copy list. The plan picks one and tests the jumping-a-version path explicitly.

Otherwise the column is safe: every apps query names its columns (verified — no SELECT *), so no row parser breaks.

9. The pinfra scripts stay

roll-console.sh and verify-console.sh stay, reclassified in their header comments as break-glass: the path that works when the console is down. That is the honest answer to the bootstrap question — the console mediates its own replacement on the happy path, §4 covers a build that fails readiness, and §4a's residual (starts, serves, behaves wrong) has no automatic recovery at all. A console that is already down cannot be the door to its own repair.

ship-app.sh and promote-app.sh lose their console/kass/keymail/ platform-site callers but are not deleted; promote-app.sh still serves direct-bucket promotes for apps outside any console's knowledge.

10. Order of work

Reordered after review: the flag must exist before the claim, and the code must reach the boxes before the first self-deploy.

0. Survey both boxes (read-only, no changes). Per box: console.service's ExecStart path and its Type=; which route carries the Unit stamp; every console route and channel (tito is entirely unsurveyed — it has console.platform.tito.io and the still-serving carlos.tito.io); HasOwners("console"); any legacy apps/console/ prefix; the bucket production flag on console. Flagship's readings are in the appendix; tito's are not, and step 7 deploys there first.

1. §2 owner exemption, with the service-principal pin and the handleNewApp policy change.
2. §8 migration + §6 flag, its destructive-verb refusals, its service-principal promote refusal, and -control-plane on apps create.
3. §3 /healthz carries the build; the app-level build probe; the watch's second exit criterion with cache-busting and a naming timeout.
4. §4b restart-recovery: start the unit on the restored version after a rolled back adoption. Tenant fix; lands independently of everything else here.
5. §5 ship-time refusals. §7 dirty-tree guard.
6. cmd/console readiness signalling (§4a) — the code half of the Type=notify change.
7. Delivery roll. One last roll-console.sh on both boxes carrying steps 1–6, plus a CLI release carrying the new watch. Without this, step 9 runs against a console that predates its own probe and fails.
8. pinfra: console.service gains the readiness gate (§4a). Applied to both boxes.
9. Stamp correctly (§4c): on each box, move the Unit stamp to the host named in ExecStart, exactly one route. Verify with a no-op adopt.
10. Claim ops/console with the flag set, in one step, on both deployments. Not two: a row without the flag is a window in which any ops member or Publish service principal can roll the production console.
11. First carlos deploy -app console on tito, verified against the build probe. Tito first: smaller blast radius, and its console going down does not take carloku with it.
12. The same on flagship.
13. Prove carlos deploy on kass, keymail, platform-site — each with step 9's precondition first. kass and keymail are addr-backed bespoke services whose Unit stamps are unsurveyed; an unstamped keymail proof run is the #110 shape again (symlink swapped, nothing restarted, header lies) and would "prove" a deploy that did not happen.
14. Update CLAUDE.md's "Deploy reality", which currently sends the reader to the pinfra scripts for all four apps. Reclassify the scripts as break-glass.
15. File the two follow-ups: the restart-dedupe pass (§4c), and how a fresh deployment gets its ops/console row (§11).

11. Open questions

• How does a fresh deployment or a self-hoster get the ops/console row? Nothing creates it — not provisioning, not materializeQuietly, not BackfillOpsMemberships. Steps 10 backfills our two boxes by hand. The general answer belongs to slice 3 or to #135, and is filed at step 15, but it should be named as an unsolved product gap rather than left implicit.
• What alarms on a console that is down? §4a's residual and §4b's rollback both print into the root pass's journal — box-only. The CLI's timeout tells the operator who ran the deploy and nobody else. Out of scope to build here; named so it is not mistaken for covered.
• carlos deploy -app console run against the console being deployed is expected to work — the watch tolerates the restart — but its diagnostics leg reads the platform log stream through the console API, so it will error precisely when it is most wanted. Confirm at step 11 and degrade the diagnostics gracefully rather than failing the deploy.

Appendix — flagship readings, 2026-08-23

apps rows in ops (bab):        deploy-probe, platform-site      (no console)
bucket prefixes under apps/bab/: apt-carlosframework, carloku, carlosframework,
                               console, deploy-probe, derp, hello, keymail,
                               meep, platform-site
owners table (grants):         derp, meep, platform-site        (no console)
legacy apps/console/:          absent

console routes:
  platform.carlosframework.com | console | canary/console | (no unit)
  console.bab.oncarlos.com     | console | (alias)        | (no unit)
  dashboard.carloku.com        | console | canary/console | (no unit)
  console.carloku.com          | console | canary/console | console.service

console.service ExecStart:     /opt/carlos/live/platform.carlosframework.com serve
console.service Type:          not read — step 0
CONSOLE_ORIGIN:                https://console.carloku.com
CONSOLE_DB:                    /data/console/console.db

The ExecStart host and the stamped route disagree. That is §4c.