The [2026-10-06 local repair review](https://base.sbarah.com/en/docs/reference/review-2026-10-06/) records defensive source changes and their limits. Local regression results do not change the production acceptance status below.

# Deployment readiness

## Current checkpoint, 2026-10-19

Production acceptance remains unproven. The declared version is 0.5.12, after releases 0.3.0 to 0.5.12 from 2026-10-17 to 2026-10-19 ([changelog](https://base.sbarah.com/en/docs/changelog/)). What changed the readiness picture, each with its own scope:

- **Install with Docker from a bare Ubuntu 26.04 machine:** 14 of 14 checks in a local KVM guest (4 vCPU, 6144 MiB) on 2026-10-17, including a reboot ([vm-docker-install-checks.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/vm-docker-install-checks.json)). Not a real server.
- **TLS proxy with Studio addresses:** 27 of 27 checks on 2026-10-17, self-signed certificate and stub upstream ([tls-termination.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/tls-termination.json)).
- **On the real server through Cloudflare, 2026-10-17:** secret keys ([live-secret-keys-2026-10-17.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/live-secret-keys-2026-10-17.json)) and an agent's deploy through `/mcp` and `/v1` ([live-agent-access-2026-10-17.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/live-agent-access-2026-10-17.json)), on one environment without application data.
- **Developer login limits:** 64 of 64 checks on 2026-10-19 ([developer-schema-checks-2026-10-19.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/developer-schema-checks-2026-10-19.json)).

Still open: a public-server install with Docker, Studio on a real server's public address, restore onto a new server from the off-site copy, an interrupted restore, and a whole installation under real traffic. [Status](https://base.sbarah.com/en/docs/reference/status/) has the details.

## Checkpoint, 2026-10-09

Production acceptance remains unproven. The latest verified published checkpoint is `aad7b5403ad14140e9d9499668e863d7488ce15b`: [CI 37688338269](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37688338269) completed all four jobs successfully, including Docker installation and empty-host acceptance. The [exact CI observation](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/isolated-guest-preparation-2026-10-08/source7/ci-aad7b540.json) preserves the commit and job conclusions. This commit publishes the Source7 repair evidence. Its CI does not execute or accept the experimental guest installer or the full local VM recovery route.

Update 2026-10-17: a real server runs main (sbarbase.sbarah.com, Ubuntu 26.04, 4 cores, 16 GiB), upgraded from 0.2.0 with `lab/upgrade.py start --to`; a restore from a local backup and one served only from Cloudflare R2 passed there on one environment without application data ([checkpoints](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/engineering/checkpoints.md)). Formal production acceptance is not established. The history below keeps its own dates. A local preparation build completed with networking disabled against 1690 published source files and 6557 cache entries. Ten actual Source7 regression tests passed, including a large regular application file and concurrent complete diagnostic streams. Source7 repairs a newly confirmed flaw in the historical Source5 and Source6 candidates: their child file size limit also restricted dpkg and Bun application outputs. The parent now limits each diagnostic stream alone. It also verifies fresh source archives without fixing the historical commit or file count. The [Source7 record](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/isolated-guest-preparation-2026-10-08/source7/summary.json) and [independent review](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/isolated-guest-preparation-2026-10-08/source7/independent-review.md) accept the implemented repair only. The earlier [Source5 record](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/isolated-guest-preparation-2026-10-08/summary.json) is preserved as history.

Guest boot, installation of the complete Supabase runtime and complete restoration to a fresh target have not run locally. Actor integration remains under review and this checkpoint is not a production release.

The deployment target remains portable Linux Docker with original Supabase services. Local VM helper experiments do not become required workstation paths or byte pins in the product. The following 2026-10-07 section preserves its earlier source checkpoint.

## Previous integration checkpoint, 2026-10-07

Production readiness remains unproven. Source integration is still changing, so there is no final merged-source release acceptance. Historical green tests and CI runs apply only to their recorded source and environment. The [integration programme](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/engineering/plans/2026-10-06-integration-programme.md) records the remaining full completion contract.

Current published checkpoint `e08ed3b2684bdf04f0288c7162747a2783177026`: [CI 37600158231](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37600158231) passed all four jobs: general checks, Python compatibility, Docker installation and empty-host acceptance. Python 3.12 passed 2102 tests. [Website 37600311118](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37600311118) passed build and tests. Empty-host acceptance now runs automatically on main pushes as well as explicit manual requests; pull-request behavior is unchanged.

The [current native checkpoint summary](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/ci-e08ed3b-2026-10-07/summary.json) binds the new Docker artifact to 13 reports and 254 passing checks for project creation, Supabase features, backup/restore, upgrades, rollback and restart. This is the new run's fresh-only artifact, not the earlier baafbad archive or historical installation transcription. Its runtime evidence is bound to core code commit `e08ed3b2684bdf04f0288c7162747a2783177026`; a subsequent documentation publication preserves that identity and does not establish runtime acceptance for later code changes.

The [fresh empty-host evidence](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/ci-e08ed3b-2026-10-07/empty-host/summary.json) contains six reports and one run manifest, with 58 unique checklist checks and a separately reported 21-check live Auth bootstrap. The identical rehearsal handoff copy adds no checks. The native log and final script guards establish that the shipped system unit became active and its console answered after the rehearsal. The earlier JSON unit snapshot records the deliberate inactive rehearsal phase; it is not the final restored service state. This is a fresh Ubuntu runner installation checkpoint, not physical reboot, Kali verification, complete lost-source recovery, cold/warm Cron continuity or production acceptance. Static-serving and TLS stub checks retain their separate scope; a public certificate is not proven.

A separate [Fedora 44 systemd descriptor probe](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/systemd-scope-fd-probe-2026-10-07/summary.json) preserved five descriptor identities across same-PID Python exec under bounded systemd scope custody. Its two-file public archive contains the probe and summary. It launched no guest or Docker container and accepts only that Python descriptor behavior, not a Linux guest, reboot or portable production deployment.

Reviewed deltas for database workflow, Storage settlement, administrative transfer, lifecycle and recovery dependencies have entered the integration tree. Component checks at intermediate snapshots do not accept the later tree. The e08ed3b CI checkpoint verifies its current standard checks and installation routes. Installed original-service continuity, complete fresh-target recovery, additional supported hosts, browser/provider checks and pilot operation remain required. All 105 capability acceptance and production rows remain unproven.

The target stays portable Linux with Docker and original Supabase services. The current source admission route requires local rootful Linux Docker Engine 25 or newer, Compose 2.20 or newer, x86_64 and the required runtime capabilities. Desktop, ARM, rootless and an advertised SELinux security option are refused by the current profile; [host admission](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/engineering/HOST-PREFLIGHT.md) records the contract. A local computer supplies an isolated test host without a machine-specific product dependency. A separate Linux VM installation and reboot route on that computer is planned; its construction authority and native acceptance are not established. Windows Docker Desktop support remains a gap, and a Windows-hosted full Linux VM is only a prospective untested route. An external server is not required to continue local work.

Published historical CI: [run 37411721539](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37411721539) succeeded for commit `2c4ec82007a47436ba3e338ac03d1ad5e288df45`. Checks, Python compatibility and Docker installation passed; the empty-host acceptance job was skipped. It does not accept the current integrated source or a fresh host.

The [curated historical integration summary](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/historical-integration-observations-2026-10-07.json) records the exact counts, public source identities and reviewed metadata lineage. It preserves the failed original native result and distinguishes physical resource absence from refused positive owner and guard closure. It is an observation record, not current acceptance.

## Historical evidence before the current integration

The following results retain their original dates, source identities and limits. They do not certify the current tree.

Historical published checkpoint `baafbad`: [CI 37592809221](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37592809221) passed general checks, Python compatibility and Docker installation; [Website 37595879418](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37595879418) passed build and tests. Python 3.12 passed 2086 tests. [Current native evidence](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/ci-current-2026-10-07/summary.json) preserves 13 reports and 254 passing checks for project creation, Supabase features, backup/restore, upgrades, rollback and restart. A historical installation transcription is excluded from the current count. Complete recovery to a fresh server, Cron continuity and production acceptance remain unproven.

Manual [run 37596046599](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37596046599) started on the same commit. Empty-host acceptance failed because the canonical Docker endpoint was forwarded without its matching socket declaration. The focused repair passed 32 tests and independent source review; The subsequent e08ed3b native rerun passed; the original failure remains preserved. [Integration review](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/engineering/reviews/2026-10-07-ci-integration.md) preserves the preceding failures and each result scope.

Historical failed full-standard attempt: the completed focused Namespace regression ran 61 cases successfully. The subsequent full-standard attempt ran 1623 Python tests with 9 failures and 21 errors and exited 1. Its other six stages passed, including 430 Bun tests and all 41 required targeted regressions. The whole attempt remains failed. Ten fixture and runner source repairs were then applied; fresh verification was required at that checkpoint; later CI results are recorded above.

Historical repair checkpoint, 2026-10-06: the reviewed repairs close SQLite connections in `recovery_bundle` after their original transactions and close `HTTPError` responses in `notify`. They also capture and assert complete expected stderr in 27 fixture methods and register tempfile close/unlink ownership before a fallible write. A newer creator fixture associates its tempfile warning with the HTTPError response lifecycle; it does not establish the allocation causes in earlier warning packets.

Historical regression result: **1504 tests passed with zero failures, errors, warnings or skips**, independently reviewed after native exit 0. All 881 public source bindings, both 294-file captures and both 881-entry mode checks matched; all eight helpers were removed with no unresolved resources. This includes 55 regressions for the two newly published private SQL completion components and the 52 focused preparation cases. See the [historical public regression summary](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/private-pump-regression-2026-10-06.json). The [earlier 1449-case result](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/public-regression-2026-10-06.json) retains its original snapshot. [CI at `6c86b10`](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37402639965) passed for the preceding baseline; it excludes the four additions. Component and preparation tests do not establish installed private client compatibility, PostgreSQL startup, Cron/Vault continuity or full restoration.

[CI 37388098529](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37388098529) passed all four jobs for code commit `066f5ec`, including Python 3.12, Docker integration and fresh-host systemd acceptance. [Website 37388119460](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37388119460) passed build and tests only. See the [CI acceptance summary](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/ci-acceptance-2026-10-06.json); its runtime evidence remains bound to that exact code commit.

The normal `legacy-shared` platform has historical Docker integration evidence for installation, the first project, Auth, REST, Storage, Studio, Realtime, Functions, backups and upgrades. Fresh CI and manually dispatched empty-host acceptance passed for code commit `066f5ec`. The user's computer is the selected isolated Linux Docker test server; CI provides an additional fresh-host route. Public DNS and a public TLS certificate are future operator configuration.

The experimental `native-dedicated` path remains incomplete: the PostgreSQL 17.11 candidate has not received accepted startup, effective private-safe configuration, real private request operation, cold/warm Cron and Vault continuity, or physical recovery evidence. Retained isolated candidate volumes must not be adopted, read or deleted. At that checkpoint package 0.2.0 was a development snapshot, and neither production acceptance nor a signed release was established.

[Status](https://base.sbarah.com/en/docs/reference/status/) contains the current evidence links and scope. The matrix below retains its original dates and limits; this edit does not rerun its checks.


## Historical readiness matrix

| Requirement | Status | Evidence or gap |
|---|---|---|
| Installation driver starts the runtime it installs | **fixed and regression-tested** | Running the documented acceptance command on this host exposed a defect the reviews had not: `install()` held the operation lock while spawning `lab/installation_runtime.py up`, which takes the same lock for its own lifetime, so the installer refused its own runtime on every host. The lock is now released after the console-build step and the runtime start is serialised by the runtime itself (`lab/test_install_lock.py`, 5 tests: the lock is free when the runtime starts, a refused start stops the install, a failed step still releases the lock, a second installer is refused) |
| One-command server acceptance with evidence | implemented, refusals tested | `deploy/server-acceptance.sh`: prerequisites, preflight, rehearsal, handoff copy of the evidence; 18 tests in `lab/test_server_acceptance.py` cover a missing prerequisite, a public bootstrap file, unknown arguments, no secret leakage, a failed step stopping the run, `--bun-dir` reaching the prerequisites, the release of the unit before the rehearsal and its restore on any exit, the behaviour of the unit-state probe against a stopped unit, and whether each failure message may promise an evidence file |
| Host preflight (Docker native, Bun, `/usr/bin/python3` 3.12+ with `cryptography`, pinned images, headroom, disk, state) | implemented, proven | `lab/install_server.py check`. What it reports depends on the moment on a shared host: measured here as `Host headroom insufficient: 8187 MiB available, plan needs 8789 MiB (5888 MiB placement + 2560 MiB reserve + 341 MiB measured for the running source stage)`, and at another moment as `0 blocker(s), 2 action(s)` with the same plan. The composition is spelled out in the blocker, including the measured cost of the running source stage, so a combined start refuses before creating containers instead of dying halfway. Also reported: the retained installation (11 source, 8 target containers), the current recovery target's generation pin, and a historical target without one that the runtime does not start. The composition moves with the host: the committed footprint file records 279 MiB of actual usage across the 9 source containers it sampled (`docs/evidence/source-stage-footprint.json`, sampled immediately before that run's combined admission), against 341 MiB at the earlier moment quoted above. With the workstation's own stack running, the same check reports its honest blocker: `Owned containers are already running; stop or supervise them instead of installing` |
| Supervisor unit rendering, verification and install | rendering and verification **passed on this host**; the install needs root on the server | `lab/install_server.py supervise`: the shipped unit is rewritten for the installation's paths, service user and Bun directory, the result is verified with `systemd-analyze verify`, and the exact install commands are recorded (`docs/evidence/supervisor-unit.json`, `passed: true`). It refuses to rewrite a unit whose directives moved, refuses an empty Bun directory, refuses an account or path that is not plainly what it claims to be, refuses to install a unit that does not verify, refuses `--apply` without root, and fails the run if the installed unit never becomes active. `--apply` installs to `/etc/systemd/system/sbarbase.service`, reloads, enables and starts it |
| Supervised path under systemd | **passed on this host**, 10 checks | `docs/evidence/supervised-run.json`, 5:08 PM, 10 of 10: a temporary systemd user unit mirroring the shipped unit's directives (`ExecStartPre` gate, `ExecStart`, PATH) was loaded, accepted the start, started the supervisor and the console, the console and management realm answered, owned containers were started by the unit, the preflight gate ran under systemd, `systemctl stop` returned cleanly, the unit file was removed and no owned container was left running. Not the shipped unit installed at `/etc/systemd/system`; the acceptance run now covers exactly that: it installs the unit as root, starts it, and the rehearsal verifies the installed file itself (`verify_source: installed`, 13 checks, 7:25 PM). This run satisfies the tightened check: the gate row requires the gate's own `Preflight: 0 blocker(s)` line, not any gate output, and the console wait accepts state written after the start under systemd only, not state left by an earlier run |
| Full source and target lifecycle rehearsal | **passed on this host** | `docs/evidence/deployment-rehearsal.json`, 11 of 11 checks, 2026-09-20 17:21: preflight, built page intact, supervisor start, console serving, management identity realm 200, all 8 environment routes 200, 18 live operator bootstrap checks, 14 combined gateway checks, clean shutdown, no owned container left running. The evidence also carries the startup context (`attempts_used: 1`, no refusals) and the unit state it saw (`verify: passed` against the checkout's template, `verify_source: template`, since no unit is installed here). Its systemd row is green because the unit was not required: the supervisor was started directly and `sbarbase.service` was not installed, and the row's own text says that nothing under systemd was exercised. The acceptance variant (`--require-unit`, own evidence file, `docs/evidence/server-acceptance-rehearsal.json`) requires the shipped unit to be installed and now records 13 of 13 with `verify_source: installed` |
| Fresh install from an empty host | **passed in a local VM simulation**, not on a real server | Fedora 44 Cloud VM, 4 vCPU, 6 GiB, clean clone at `0aa0942`: the one-command acceptance with `--install-unit --first-project` passed 12 of 12 ([vm-empty-server-acceptance.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/vm-empty-server-acceptance.json)) and the first project 13 of 13 including supabase-js through the gateway ([vm-empty-server-first-project.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/vm-empty-server-first-project.json)); the service came back by itself after a reboot. Getting there found ten defects the workstation could not show, each fixed with a test: console checked before it was built, IO limits on a partition, CPU and memory requirements from a fixed constant, a failed first launch sent to adoption, body-less POSTs refused over the real listener, an ephemeral console port, a silent pull timeout, a fixed 6 GiB runtime check, and environments the next restart could not admit ([summary](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/vm-empty-server-rehearsal.json)). Repeat with `lab/vm-rehearsal.sh`. A real server adds public networking, a public certificate and a provider's disk and network |
| Combined runtime admission on this host | passed | `docs/evidence/combined-runtime-admission.json` as committed: 5888 MiB of container limits and 5.75 CPUs admitted at 9301 MiB available with the target started in the same run (the file is regenerated by each combined run, so earlier runs of the same measurement recorded 8943 and 8766 MiB). The rehearsals around it recorded 8885 and 8481 MiB available (`docs/evidence/deployment-rehearsal.json`), and the acceptance run's own preflights saw 8900-9453 MiB |
| HTTPS termination | **passed on this host**, 27 checks | `lab/tls_termination_check.py`: `deploy/console-tls-proxy.ts` terminates TLS (self-signed certificate in the check) in front of a stub serving the real built page; the page and its assets arrive byte for byte over HTTPS, a management route is reachable, HSTS and nosniff are set, the protocol is forwarded as https, plain HTTP gets a 308, a host that is neither the public host, loopback nor a Studio address matching `--studio-host` is refused with 421 and never becomes a redirect target, a matching Studio address passes with its own host, hop by hop headers are not forwarded, a declared body over `--max-body` is answered 413 without being read and a chunked body is refused as soon as the stream passes the cap (with a within-limit chunked body reaching the upstream as a positive control), and the proxy refuses a world-readable key, a non-loopback upstream, a missing certificate, a missing public host and a public host that is not a bare host name (`docs/evidence/tls-termination.json`). A public certificate and the operator's own proxy are the server's business |
| Operator bootstrap step, live | **passed on this host**, 18 checks | the rehearsal runs `bun lab/bootstrap-check.ts` against the live management Auth and records `18 live operator bootstrap checks passed`; it covers real Auth operator creation, interrupted bootstrap recovery, password verification, the private journal, idempotent catalog and authenticated organization discovery, and cleans its probe account up. The script writes its own artifact to `.lab/upstream/bootstrap-verification.json`; `docs/evidence/bootstrap-checks.json` is a copy of an earlier, separate run of the same script, kept for the record |
| Console build step, isolated and verified | proven on this host | `lab/console_build_check.py`: build exit 0, page 392 bytes with both referenced assets present and hashed in `docs/evidence/console-build.json`; 8 tests in `lab/test_console_build.py` |
| Console static-serving layer, isolated | proven on this host, 19 checks | `bun lab/console-serve-check.ts`: the built page and both assets are served on an ephemeral loopback port, served asset bytes match the built files, and the security headers, method refusal and loopback host check all hold. The traversal checks send the literal `GET /../src/...` and a percent-encoded variant over a raw socket, because `fetch` normalises a traversal path before it leaves the process; a third check exercises the asset allow-list directly and proves it still admits a real asset (`docs/evidence/console-serve.json`) |
| Pinned images present and matching their digests | proven on this host | `lab/pinned_images_check.py`: all 5 pins resolve to the pinned digest in `docs/evidence/pinned-images.json`; 6 tests in `lab/test_pinned_images.py`. The installer now re-verifies every pin after ensuring presence |
| Studio and postgres-meta pins | distributed pins exist | `lab/studio-image.lock.json` pins Studio and postgres-meta by exact digest. See the [current pin policy](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/engineering/UPSTREAM-UPDATE-POLICY.md). This does not establish a new upstream adoption or native-dedicated acceptance |
| Studio serving per environment | implemented in the legacy shared-engine workflow | [docker-studio-checks.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/docker-studio-checks.json), [Studio guide](https://base.sbarah.com/en/docs/guides/studio/), [integration note](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/engineering/STUDIO-INTEGRATION.md). Native-dedicated Studio operation remains outside this result |
| Retained installation migrated to owned HBA authority | implemented and executed | both retained databases adopted; per role an operation section (7 checks) and a verification section (12 checks) in `docs/evidence/retained-source-adoption.json` and `retained-target-adoption.json`, rules preserved byte for byte |
| Recovery target placement starts and serves | rehearsed live, passed | `docs/evidence/target-placement-rehearsal.json`, 12 checks: lifecycle start, Auth and REST 200, routing resumed, clean stop |
| Fresh-target HBA writer on a disposable container | proven, 16 checks | `docs/evidence/target-hba-creation-checks.json`; the consuming restore path has not been re-run with the owned writer |
| Adversarial review of the target and deployment code | completed, 12 must-fix findings all fixed | `docs/engineering/reviews/target-and-deployment-review.md`; fixes covered below |
| Acceptance run as the installation account | **fixed and regression-tested** | Running the documented `sudo` command exposed a defect no review found: it ran the preflight, the checks and the rehearsal as root, and the installation's ownership model refused the runtime with `HBA ownership inode mismatch`, because the state files belong to the service account and `require_lock` compares their owner with the running uid. The script now runs every installation step as `--service-user` (defaulting to the checkout's owner) and keeps root for the two unit steps only, so the single `sudo` command works as written on a server whose installation belongs to a service account (`lab/test_server_acceptance.py` covers the routing, the default, the `sudo -n` system control and the wrapper's direct path). The same run exposed the other half: the step account's Docker context decides which daemon the steps reach, and `sudo` does not carry the invoking shell's `DOCKER_HOST` into the script, so on this host the preflight refused while root had reached the daemon seconds earlier. `--docker-host` now exports the endpoint for every step, including the unit steps, so a run verifies the daemon the service will use; the deployment runbook says when the flag is needed |
| Third adversarial review, of tonight's fixes | completed, 9 must-fix findings addressed | the review attacked the changes that closed review 2 and the defects found by running the documented command. It found, and this revision fixes: the unit-state probe appended `unknown` exactly when the unit was stopped, so the stop gate could never pass and every `--install-unit` run aborted with a false refusal while leaving the installation stopped; the unit was released only under `--install-unit`, so a plain `--rehearse` could collide with a live supervised installation, and nothing restored it after a failure (now a trap restores it on any exit); the renderer refused `/opt/sbarbase`, the layout the shipped unit already names; the proxy's body cap still buffered a chunked body whole before refusing it (now read and refused at the cap); the supervised gate row read a 60-line journal window that could contain an earlier run's admission (now bounded to the current start); the redaction missed the `--bootstrap-file=PATH` form; a crash in the TLS or console checks could leave the previous run's evidence in place (both now clear it first and the acceptance script says whether a file was written); and the row that reported a green "supervised path exercised through systemd" now says what it actually knows. Its numeric objections to this document (admission 8766 not 8943, footprint 341 not 313, plan 8789 not 8761, 14 not 10 acceptance tests) are corrected above |
| Second adversarial review of the deployment tooling | completed, all 20 must-fix findings addressed, 17 document claims corrected | `docs/engineering/reviews/deployment-tooling-review-2.md`; every falsified claim is corrected in place. Its two lowest-severity items were also closed afterwards: `rehearse()` now returns the context the evidence needs (attempts, unit state, install failure) instead of an unused `None`, and the check totals were re-derived from fresh runs rather than carried from older ones |
| Deployment rehearsal in one command | implemented, records refusal honestly | `lab/deployment_rehearsal.py`; the committed run passed 11 of 11 on 2026-09-20 5:21 PM (`docs/evidence/deployment-rehearsal.json`). A run while the host is short of memory records the refusal and starts nothing, measured repeatedly here: `Combined resource admission refused: host_memory_headroom` at 8736, 8488, 8663 and 8187 MiB available against a plan that moved between 8758 and 8810 MiB as the measured source-stage cost changed, and the green run succeeded once the host reached 8900 MiB. A run that cannot install records `installation steps completed` false with the diagnostic path instead of dying without evidence, and `deploy/server-acceptance.sh` says whether the evidence file was written. The acceptance variant of the same rehearsal, which requires the installed unit, records 13 of 13 |
| Server acceptance run | **passed end to end on this host, 13 of 13, one command** | `sudo deploy/server-acceptance.sh --rehearse --install-unit --service-user <account> --home /home/<account> --bun-dir /home/<account>/.bun/bin --docker-host unix:///var/run/docker.sock` completed at 7:25 PM with exit 0: prerequisites, preflight `0 blocker(s)`, the console static-serving check (19 checks), TLS termination (23 checks), the unit render and its install as root at `/etc/systemd/system/sbarbase.service`, the rehearsal with `--require-unit` (13 checks: install steps, built page intact, supervisor owning the console, console serving, management realm, all recorded environment routes, 18 live bootstrap checks, 14 combined gateway checks, the installed unit enabled and verified, clean shutdown, no owned container left), the unit restart, and the handoff copy (`docs/evidence/server-acceptance-latest.json`, `passed: true`, 13 checks). Earlier runs of the same script recorded 11 of 12 at 5:11 PM and, with the unit installed by hand, 12 of 12 at 6:08 PM. This green run is what found the two defects no review saw, both fixed and regression-tested above. The unit was removed afterwards and the workstation's own stack restored |
| Supervision with a restart policy | **installed, enabled and active on this host**; two preconditions were defects, now fixed | `deploy/sbarbase.service` with `ExecStartPre` preflight, a restart policy and a 150 s stop budget. Installing and starting it for real exposed two blockers no review had found: the unit demanded `ReadWritePaths=$HOME/.secrets`, a directory nothing creates, so systemd failed it with `226/NAMESPACE` before the first command ran (the unit now names the checkout only, and a test refuses any write path outside it); and a system service does not inherit the operator's shell, so on a host whose docker context points at a desktop socket the daemon is unreachable and the preflight now says exactly that, naming the endpoint it tried, instead of reporting the images as absent and the host as a fresh install. With the checkout path fixed and `DOCKER_HOST` pointed at the system socket, the unit installed, enabled and reached `active` here (5:59 PM). The acceptance run re-proved the whole path at 7:25 PM as a service account rather than root: installed, enabled, started, verified with `systemd-analyze verify`, restarted after the rehearsal, and then removed to leave the workstation as it was found |
| Operator bootstrap file, created without leaking the password | implemented and proven | `lab/operator_file.py` writes the 0600 JSON an install reads on stdin: it prompts for the email, the organization and the password twice without echo, or takes the same object on bounded stdin (`--stdin`, 8192 bytes) for automation, and refuses a short password, a malformed email, fields the install would reject, a relative path, a missing parent, a symlink, an existing file without `--force`, and a write that fails part-way. Its own output names the path and the mode, never the password. 9 tests in `lab/test_operator_file.py`, and the runbook creates the file with it before `install --bootstrap-file` |
| Account and layout the installation runs as | named, validated, refuses a missing account | `--service-user`, `--home` and `--bun-dir` are accepted by `lab/install_server.py supervise` and forwarded by `deploy/server-acceptance.sh`; the installer refuses `--apply` for an account that does not exist (the shipped default is `sbarbase`) and records `service_account: present|missing` in its evidence, so an install never produces a unit that cannot start |
| HTTPS and network exposure | termination implemented and checked on this host; the public certificate and the production proxy are the operator's | `deploy/console-tls-proxy.ts` and `lab/tls_termination_check.py` (27 checks, `docs/evidence/tls-termination.json`); runbook in `docs/guides/server-deployment.md`. No port is published by the installation itself |
| Upgrade and rollback | `lab/upgrade.py` with an automatic way back, run with `start --to` in CI and the rehearsal VM. The update channel (signed releases, console install with an acknowledgement for Auth, Storage and Realtime changes, opt-in automatic updates, a drain, a start guard, a health-gated confirmation) has unit tests and its CI cases, which passed on a clean CI machine on 2026-09-25 (`docs/evidence/docker-upgrade-checks.json`, 45 of 45 checks), and ran in the local rehearsal VM on 2026-09-26 as an operator uses it: releases from a local repository signed with a throwaway key, installed through the management API and by automatic mode, a broken one moved back by itself, an attended Auth release after the acknowledgement (`docs/evidence/vm-channel-checks.json`, 114 of 114 checks; the command line cycle `docs/evidence/vm-upgrade-checks.json`, 26 of 26). Nothing of it ran on a real server. No upstream release adopted yet | `docs/guides/upgrades.md`, `docs/engineering/UPDATE-CHANNEL.md`, `docs/engineering/UPSTREAM-UPDATE-POLICY.md` |
| Backup and restore | operator backup/restore and encrypted copy/fetch/restore exercised with disposable local MinIO | [docker-offsite-checks.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/docker-offsite-checks.json), [backup guide](https://base.sbarah.com/en/docs/guides/backup-and-restore/). A real external provider, coherent concurrent object capture and complete fresh-host installation recovery remain unaccepted. The [independent restore](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/engineering/INDEPENDENT-RESTORE.md) fixture is a separate historical experiment |
| Capacity at 10 or 100 projects | not claimed | configured ceilings only, no measured peak demand |
| Realtime and Edge Functions | implemented as optional per-environment services in the legacy workflow | [docker-realtime-checks.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/docker-realtime-checks.json), [docker-functions-checks.json](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/evidence/docker-functions-checks.json); these results do not establish native-dedicated feature acceptance |
| Pooler and operator cron support | not implemented in the legacy workflow | Native-image cron/net bootstrap and probe fragments do not establish an exposed operator feature or accepted native placement |

## Rehearsal order on a selected Linux server

1. `/usr/bin/python3 lab/install_server.py check` on the server. Fix every
   blocker first; a host that fails validation must not be half-installed.
2. `/usr/bin/python3 lab/deployment_rehearsal.py --bootstrap-file <0600 JSON>`
   for a fresh host. It installs, supervises, verifies console and management
   reachability, probes every recorded environment route, shuts the supervisor
   down and asserts no owned container is left running, writing
   `docs/evidence/deployment-rehearsal.json`.
3. `/usr/bin/python3 lab/target_placement_rehearsal.py` when the installation
   has a recovery target, to re-prove that placement on the server.
4. `/usr/bin/python3 lab/combined-supervisor-check.py` for the full source plus
   target rehearsal, which needs the full headroom.
5. Keep the evidence files with the deployment record. A rehearsal that fails
   is evidence too: the refusal is recorded, not hidden.

## Historical legacy rehearsal gaps, documentation checkpoint 2026-10-06

The integrated source now contains durable management grant and rate-limit primitives, administrative transfer/history modules and lifecycle authority and recovery modules. Their presence supersedes the unqualified source-absence wording below. Installed native MFA and rate enforcement, complete credential transfer, interrupted deletion and reclamation, neighbor safety and recovery still need current integrated evidence. The historical bullets retain what their earlier legacy snapshot lacked; they do not describe the present source or grant production acceptance.

- Sustained mixed load, connection saturation and 10/100-project capacity are
  still unmeasured; a short rehearsal proves availability, not capacity.
- Controller death during active provisioning, power loss and multi-host
  coordination remain unproven; the current crash evidence covers bounded
  checkpoints, not arbitrary crashes.
- The storage verification probe and the legacy bootstrap scripts still write
  `pg_hba.conf` directly, as inventoried in `docs/engineering/TARGET-HBA-WRITERS.md`. They
  are check-time or legacy paths, not managed runtime writers.
- The supervised unit needs a daemon socket the service can reach: on a server
  with native Docker that is `/var/run/docker.sock` and the `docker` group; on a
  host whose docker context points at a desktop socket it needs the drop-in noted
  in the runbook. The unit reached `active` here only after that drop-in was
  added.
- Container-generation migration is implemented and crash-tested on disposable
  fixtures, and was run once, attended, on the retained database on 2026-09-25
  with every row intact (`docs/evidence/generation-migration-retained.json`).
  It is not automatic, and it does not cross hosts
  (`docs/engineering/CONTAINER-GENERATION-MIGRATION.md`).
- The bootstrap flow creates the first operator only. Later operators join by
  invitation. There is no MFA, no sign-in rate limit, and no supported repair
  or reset procedure.

## Preserved October verification history

These are preserved statements from earlier source windows, with their original verdicts and links. They do not describe the subsequent historical V11 outcome. Later HTTPError lifecycle evidence does not retroactively establish their allocation causes.

Historical cutoff, 2026-10-05: six independently reviewed source fixes are integrated. Two SQLite paths now close their connections after the original transaction exits; 27 expected-negative fixture methods capture and assert complete stderr in three files; one tempfile fixture owns close and registers unlink before its fallible write. These are source repairs, with fresh full native verification UNRUN. Earlier 875-file source, identity, mode and full results are historical bindings and cannot approve this changed tree.

The separate public55 V3 role has actual MET: 25 component and 30 pump tests passed, original 290 and added 4 actual mode/byte captures matched, and all three known helpers were removed with no unresolved resources. Public BusyBox V8 help metadata also has actual MET: fixed-path Bash 5.3.3 and BusyBox 1.37.0 help returned zero, with its one helper removed. Neither result accepts private request operation, timeout timing/signal behavior, installed binary source provenance, candidate startup, cold/warm Vault or Cron continuity, physical restore or production.

The preserved warning-window V4 negative run reported 1447 ordinary tests OK but six ResourceWarnings, native 1 and observed window 839 for every warning. Three records have exact sqlite3.Connection type; three report tempfile.py line 484 with NoneType source. Observation windows are not allocation causes, and the earlier packet did not establish the three tempfile allocation causes. Fresh complete source/identity/mode/full bindings, final-revision CI and manually dispatched empty-host acceptance remain required; published 0e745394 CI and Website results retain only their earlier revision scope.

Scope corrections updated 2026-10-05. This matrix preserves September workstation and local-VM rehearsal evidence; individual rows retain their original scope and dates. It is not a newly executed acceptance run.

Package 0.2.0 remains a development snapshot, distinct from the historical 0.1.0 release. Published `0e745394` passed [CI 37206229288](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37206229288), including Docker installation; empty-host acceptance was SKIPPED and awaits a fresh manual dispatch. [Website 37206294329](https://github.com/M7MMAD-OMAR/sbarbase/actions/runs/37206294329) passed its separate build-only gate. See [status](https://base.sbarah.com/en/docs/reference/status/) for the current source-bound summary; these results do not transfer to later edits.

The local computer is used as an isolated Linux Docker test server, not an independent public-server pilot. Native preparation sources define a guarded prepare-only handoff; no actual native material-preparation result is accepted here. The earlier V9 initV2 run passed 52 focused cases but its actual 1447-case full run is historical NOT_MET, with one failure and 15 errors. The full admission minimum is 1356, not an exact discovery total.

The historical mode/scratch correction had independently accepted source and source/identity build evidence; its old 875 bindings are no longer current after the six integrated source repairs. Its completed full window is NOT_MET: raw unittest reports 1447 tests OK in 51.862 seconds, all 52 focused cases passed, both 290-file captures and both 875-entry mode jobs matched, and all eight known helpers were removed with no unresolved resources. The full helper nevertheless returned native 1 without its required positive terminal. Its original child cause is not established by that packet; 70 expected-negative fixture stderr lines also violate the parent progress grammar. A later independently accepted negative-only numeric diagnostic reports 1447 raw tests OK in 51.835 seconds, stage 7 with six captured warnings, native 1 and exact cleanup. This identifies that diagnostic invocation's warning-gate refusal, not the earlier invocation's precise cause, and does not accept its full verification. The reviewed 27-method expected-stderr repair is now integrated together with two SQLite close fixes and one tempfile setup-failure repair. Their changed-source native regression remains UNRUN. The later warning-window diagnostic identifies observation window 839 and limited type metadata, not allocation causes; the earlier packet did not establish the three tempfile allocation causes. Fresh exact-source full verification remained required at that historical checkpoint. Native preparation, private pump, startup, Vault continuity, physical restore and production remain unaccepted.

The pinned original configured-effects fragment has scoped acceptance; earlier routine-ACL refusals remain historical losses. The [native placement contract](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/engineering/plans/2026-10-03-native-placement-identity.md) and [ledger](https://github.com/M7MMAD-OMAR/sbarbase/blob/main/docs/engineering/gauntlet-ledger.json) retain those boundaries.