Time & Risk Comparison — Fast Containment (A) vs Direct Decomposition (B)

Side by side

Dimension	A — Fast Containment	B — Direct Decomposition
Identities to design/provision	1 broad (union)	4 least-privilege (+1 deferred)
Operator hours	~6h	~8h
Elapsed	~24–48h	~48–72h
Container restarts	2 (agent-data, nuxt)	2 (agent-data, nuxt)
Nuxt-image gate (NUXT-IMG-H1)	Required	Required (same)
Time-to-admin-rotation	Gated by NUXT-IMG-H1	Gated by NUXT-IMG-H1 (equal)
Lockout vector (25-fail) during migration	remains for password consumers until repointed	eliminated (password→token conversion)
End-state privilege	broad non-admin token (needs later decomposition)	least-privilege, final
New long-lived secrets in docker/.env	1 broad token	4 scoped tokens
Second pass required	YES (decomposition, with deadline)	NO
Residual risk	MEDIUM (scope creep if decomposition slips)	LOW

The decisive observation

Both options require repointing Nuxt, and repointing Nuxt requires a container recreate, and that recreate is not safe today because the Nuxt image is a mutable :latest whose registry is unreachable from the VPS (Artifact Registry API disabled for project 812872501910; the running image 72715a... exists only in the local docker cache). Therefore:

Neither option can rotate the admin credential until NUXT-IMG-H1 completes.

Fast Containment's entire premise — "contain sooner by accepting a broad bridge identity" — does not pay off here, because the bottleneck is the Nuxt image, not identity-design time. A cannot rotate earlier than B. Meanwhile A leaves a broad token behind that must be cleaned up later.

Where Fast Containment WOULD win (it does not apply here)

If the exposed admin credential were under active abuse and we needed to cut machine dependence in hours regardless of Nuxt (e.g., by tolerating a brief Nuxt outage or a risky pull), the broad bridge would be justified. Current evidence shows no active abuse and Nuxt is load-bearing (public site + 103 live workflow hits), so a forced/risky Nuxt recreate is NOT warranted.

Recommendation

Choose Option B (Direct Decomposition), sequenced blast-radius-first:

1. Repoint the 4 file/password consumers now (no restart, no gate) — removes most of the admin-credential blast radius and the lockout vector immediately.
2. Repoint agent-data now (recreate is safe once its image is docker save-backed up).
3. Run NUXT-IMG-H1 on the critical path (it is the only thing standing between here and rotation).
4. Repoint Nuxt, verify, then rotate (C2B1-X) and prove restore (C2B1-V).

Rationale: B reaches the same rotation milestone at the same time as A (shared Nuxt gate), for ~2 extra operator-hours, and delivers the least-privilege end-state with no throwaway token and no lockout exposure. The extra 2h is cheap insurance against permanent scope creep.

Residual risk during the migration window (either option)

The exposed admin credential (git history + historical PG dumps + Drive artifacts per C1/C2A) stays live until C2B1-X. Nightly encrypted backups are healthy (BACKUP_RECOVERABILITY=PASS, NEWEST_PROVEN_RESTORABLE_OFFSITE=2026-07-20T18:37:01Z), and future dumps are encrypted, but historical plaintext exposure persists. Prioritize NUXT-IMG-H1 to shorten this window; it is the gating item.