Skip to main content
Operate against the actual release and retained request identities. This page summarizes repository evidence reviewed October 20, 2026; it is not a fresh probe of your deployment.

​
Current recorded state

Source records can lag a later deployment. Verify the actual controller revision, immutable image digest, schema ledger, enabled stores, and capability response before enabling a new client feature. Do not substitute a package version for deployment evidence.

​
Health and capabilities

Use the supplied API origin without /api/v1 for these controller routes. Liveness, database readiness, feature configuration, and successful authenticated runtime work are separate observations. Capabilities can report configured and available workspace/CSI state; a degraded snapshot path may retain portable-checkpoint fallback.

​
Shared coordination and upgrades

In production, preserve PostgreSQL, Redis coordination/replay state, artifact/checkpoint storage, encryption keys, secrets, runtime specs, and configuration together. Migration-ledger compatibility and source provenance matter before switching replicas or restoring backups. Do not replay an old bootstrap/import operation against the recorded Redis PVC. Candidate shared tunnels need migration 069, TUNNEL_STORE_BACKEND=db, compatible DB-backed idempotency, and an explicit old-memory-tunnel drain/reconciliation. DB mode fails closed on unavailable storage; it must not silently serve a stale local record. In-flight network connections do not migrate between replicas. Use the repository’s migration/backup/restore procedures against an isolated target first. A PVC or snapshot substrate test is distinct from end-to-end application recovery. Restored execution receipts and external side effects must be reconciled before retrying work.

​
Audit and incident inspection

The candidate records metadata-only direct execution, file, download, and REPL activity. Events bind actor and execution identity while omitting arguments, environment, contents, and output. Organization-scoped summaries use database history where configured and expose DB versus replica-memory provenance.
Use the actual CLI help for export filters/output options. Export holds a fixed time cutoff, checks page continuity, and creates a private new file without overwriting evidence. A partial, repeated, changing, or oversized history is an error rather than a complete report. When command outcome is unknown, retain IDs, request key, response/request ID, and bounded logs. Inspect original receipts, process status, workspace, and external system state. Accepted cancellation/stop alone does not establish process termination or release billing.

​
Release and promotion

The committed application baseline is 67bc2370, tagged v2.12.0-rc.2. Its newer published image review confirms source provenance/publication, supported live client/server skew, eight transport checks, and server-side cutover dry runs. The scan reports zero fixable HIGH/CRITICAL, zero CRITICAL, and 43 unfixed HIGH package findings across eight CVEs. These observations do not record a production deployment. The reviewed working tree also contains uncommitted RC3 work removing those OS packages from the Node runtime. Its readiness guide reports identical bytes from both Node build entry points, zero HIGH/CRITICAL local scan findings without exceptions, and 14 bootstrap checks. The bootstrap fixture disables Kubernetes and its isolation preflight; it does not establish hosted runtime provisioning or containment. Preserve its separate source/image identity and future publication evidence rather than attributing those results to RC2. The newer RC2 CI attempt was blocked before job steps by account payment/spending configuration. Fresh hosted CI, independent review, applicable image review, compatible migrations, and hosted acceptance remain gates. This documentation update does not promote or deploy the candidate. Source: docs/RELAUNCH_READINESS.md, EXECUTION_READINESS.md, and dated docs/releases/records/, including v2.12.0-rc.2-image-review.json, and the working-tree RC3 readiness update. Continue with production configuration or task recovery.
Last modified on October 20, 2026