P0: Run production Compose image/database smoke and close configuration audit

Goal

Run a disposable production-like Compose image/database smoke for the final RC1 candidate after PR #95 disposition and close the original production-configuration audit with runtime evidence.

Current state — 2026-09-05

Current main remains:
b45170409543684a75579a13d7bdd6d8f8ffe8e8

Do not execute the #29 runtime proof against that SHA. PR #95 is unmerged but now ready for an explicit merge decision on exact reviewed head:
431d7da80c9bac56aa16423ab61a235a176b6fd8

Exact-head evidence:

Codex review completed with no major issues;
Ashbi Local CI passed isolated install, Prisma generation, TypeScript, ESLint, focused auth/navigation/security tests, and production Next build;
GitGuardian passed with no secrets;
all inline recovery review threads are resolved;
PostgreSQL's documented OID assignment rules support the FirstNormalObjectId (16384) system-schema contamination boundary;
GitHub-hosted CI Build / Build failed before executable steps (steps:null), matching the known hosted-runner infrastructure incident rather than an observed application/test failure.

Note: Ashbi Local CI does not directly execute tests/backup-restore.test.ts; its assertions were separately checked against the exact branch text, while Local CI proves compile/lint/build compatibility.

PR #95 changes only recovery-focused tooling/docs/tests and hardens backup/restore correctness across upload-target reconciliation, archive/path safety, pristine-database checks, public-schema/ACL checks, prepared-transaction detection, connection isolation, restored attachment-file completeness, and high-OID user-created objects inside system-named schemas.

Candidate-binding rule

PR fix: reconcile restored upload target during recovery drill #95 requires a separate explicit merge approval.
After it merges, refetch the resulting main SHA.
That resulting SHA—not b451704… and not the PR-head SHA—is the repository candidate for P0: Run production Compose image/database smoke and close configuration audit #29.
Build the candidate image from that exact SHA and capture its immutable digest.
Bind every runtime evidence record to both the resulting main SHA and image digest.

Original finding

The historical production Compose configuration allowed weak PostgreSQL defaults, published PostgreSQL on the host, and lacked a valid DB healthcheck while the app depended on DB health.

Code-side state already fixed

PostgreSQL credentials fail closed when required values are absent.
PostgreSQL is not host-published.
Database healthcheck uses configured DB identity.
App waits for DB health, runs prisma migrate deploy, reconciles uploads, then starts.
Readiness covers PostgreSQL, uploads read/write, and auth-email configuration.
Verification-gated auth can be exercised in a disposable loopback smoke without claiming external-email evidence.
Backup/restore/lifecycle tooling has explicit destructive-action guards.

Required runtime proof

Use an approved Docker-capable non-production/disposable host or isolated environment. For the post-#95 exact main candidate:

prove required production configuration fails closed when secrets/DB identity are missing;
build the exact candidate image and record its immutable digest;
start the image with PostgreSQL 16 and freshly created disposable volumes/database;
prove PostgreSQL is reachable only from the Compose network, not a host 5432 listener;
prove migrations complete cleanly against the fresh DB;
pass /api/health and /api/health/ready;
run authenticated disposable lifecycle smoke, including export/deletion and DB cleanup;
create a disposable backup and record checksum/manifest evidence;
restore into a separately named pristine disposable DB and empty upload directory using the hardened restore drill;
prove restored attachment rows have corresponding regular files, migrations are current, upload reconciliation passes, and contaminated restore targets fail closed;
record timestamps, exact SHA/digest, migration boundary and stage outcomes without secrets/private content;
remove all disposable containers, networks, volumes, DBs, restored uploads, outbox residue and temporary artifacts created by the drill.

Hard stop conditions

Stop without attempting repair or production access if any of these are true:

host/environment cannot be proven disposable and non-production;
any existing customer/production DB, volume, container or upload path would be touched;
exact checked-out SHA differs from the post-fix: reconcile restored upload target during recovery drill #95 frozen candidate;
image digest cannot be recorded;
restore target is not a newly created dedicated disposable database;
restore upload directory is not explicitly disposable and empty;
any command would require DNS, public deployment, external email, production credentials or customer data.

Recommended execution boundary — requires explicit action-time approval

Target: isolated non-production Docker host/environment only.
Customer impact: none.
Incremental cost: $0 CAD if an existing approved host is used.
No DNS, public deployment, customer data, external email, production DB or production volume access.
The destructive restore/deletion smoke is authorized only for the explicitly named disposable resources in the approved execution request.

Acceptance criteria

Approval boundary

Merging PR #95 is one explicit approval. Starting containers/volumes on an external host and running destructive disposable restore/deletion is another explicit action-time approval. Neither authorizes production deployment.

Source of truth

docker-compose.prod.yml; docker-compose.vps.yml; OPERATIONS.md; PR #95 reviewed head 431d7da80c9bac56aa16423ab61a235a176b6fd8; resulting post-merge main SHA once approved; roadmap #71.

PR #55 implements the remaining configuration hardening: required production credentials/secrets fail closed, PostgreSQL is no longer published on a host port, and the healthcheck uses configured database identity. Contract tests pass locally. Keeping this open until the built image and database can be smoke-tested together in an environment with Docker.

PR #55 exact SHA ac9c90d2c34a5d052b1e3959fd5ee6f1b75f255e now passes the read-only dual-architecture image build: https://github.com/camster91/synapse/actions/runs/33498965202. This proves the image builds for amd64 and arm64, but it does not prove the Compose database/health/authenticated runtime acceptance criteria. The issue remains open until the built image and PostgreSQL are started together in an isolated container environment and the required smoke tests pass.

Preparation update for #29: the original Compose security finding remains code-fixed on main (required DB credentials, no PostgreSQL host port, DB healthcheck). PR #83 now also updates the disposable authenticated lifecycle so verification-gated registration will not break the runtime smoke.

On PR #83 (93e2efbf1cb733848fe81d41e7e2a0d344d415ad):

production and VPS Compose forward auth-email configuration to the app;
a local-sink email transport exists only for disposable loopback runs and requires exact AUTH_EMAIL_LOCAL_SINK=disposable-lifecycle-only opt-in plus loopback auth URL;
the sink discards email without recording recipient/body/raw token;
the lifecycle smoke accepts the new generic registration response, locates only its random synthetic account in the same disposable DB, removes only that account's pending verification marker, then continues sign-in/onboarding/export/deletion verification;
remote hosts cannot use that verification bypass, and the output explicitly says it is not P0: Verify external email delivery and complete authentication journey QA #60 external-email proof;
OPERATIONS.md documents the separation and setup.

Still missing before #29 can close: an actual Docker-capable isolated run of the exact candidate image with PostgreSQL, /api/health + /api/health/ready, lifecycle smoke, and recorded non-sensitive evidence. No host, container, database, or production environment has been changed by this preparation.

Post-merge RC1 status on 2026-09-04:

The relevant Compose/auth lifecycle preparation is now on main at b16ca80a28e96ad22a6d2cae3acb4f920466712d.

Current code-side state:

production DB credentials fail closed;
PostgreSQL is not host-published;
DB healthcheck uses configured identity;
app startup runs prisma migrate deploy and upload reconciliation;
readiness includes database/uploads and auth-email configuration;
lifecycle smoke is compatible with verification-gated credentials auth through the explicitly gated loopback local sink;
canonical CI now also applies migrations against disposable PostgreSQL.

#29 remains open because the required disposable production-like Compose run has not been executed and retained as exact-SHA evidence on an approved Docker-capable host. No host/deployment/runtime mutation was performed in this update.

Final merged-code checkpoint (2026-09-04): current main is a09a91ac1ff90da23f3c12c397858ec0a460cd03. The production Compose security/configuration fixes, verification-gated auth compatibility, lifecycle safeguards, migration-aware CI contract, support tooling, operations evidence gates, legal inventory, and release-package validator are all merged.

#29 still requires real runtime evidence before closure: start the exact candidate image and PostgreSQL together in a disposable isolated Docker environment, apply migrations, pass liveness/readiness and the authenticated lifecycle, prove backup + disposable restore, retain privacy-minimal exact-SHA evidence, and clean up all disposable resources. No Docker host was accessed in this session.

Codex/desktop handoff — disposable RC1 Compose proof

Do not execute external/container mutations until Cameron explicitly approves this exact #29 action.

Objective

Validate Synapse RC1 candidate 0c05e7037b5d07029401aad2d6515ef6c243a08c in an isolated non-production Docker environment and produce privacy-minimal runtime evidence for issue #29 without deploying publicly or touching production/customer data.

Repository

https://github.com/camster91/synapse

Exact candidate

0c05e7037b5d07029401aad2d6515ef6c243a08c

Source files / contracts

docker-compose.prod.yml
docker-compose.vps.yml
Dockerfile
OPERATIONS.md
OPERATIONS-RC1.md
scripts/authenticated-lifecycle-smoke.ts
scripts/backup.sh
scripts/restore-drill.sh
scripts/operations-preflight.ts
scripts/validate-operations-evidence.ts

Scope

Clone/fetch the repo and checkout the exact SHA above; fail if HEAD differs.
Use only a provably isolated non-production Docker host/environment.
Generate fresh disposable secrets locally; never print or persist them in GitHub evidence.
Confirm production Compose fails closed when required configuration is absent.
Confirm PostgreSQL has no host-published 5432 listener.
Build the exact candidate image and record immutable local image identity/digest if available.
Start app + PostgreSQL 16 with unique disposable Compose project/volumes.
Verify prisma migrate deploy, upload reconciliation, /api/health, and /api/health/ready.
Run the explicitly gated disposable authenticated lifecycle using only synthetic data and loopback local-sink behavior; do not count this as P0: Verify external email delivery and complete authentication journey QA #60 external-email proof.
Create a backup of the disposable DB/uploads and verify checksums/manifest.
Restore into a separately named empty disposable DB/uploads target and verify representative integrity.
Capture elapsed timings, exact SHA/image identity, migration boundary, health/readiness outcomes, lifecycle outcome, backup/restore outcome, and cleanup result only.
Remove all created containers, networks, volumes, databases, outbox residue, backup temp files, and synthetic state after success or failure.

Acceptance criteria

Exact SHA verified before build.
Required production config fails closed.
No PostgreSQL host port.
Fresh DB migration succeeds.
Health and readiness pass.
Disposable authenticated lifecycle passes and leaves zero owned/auth rows after deletion.
Backup and restore drill pass with integrity checks.
All disposable resources are cleaned up.
Evidence contains no secrets, raw tokens, addresses, customer content, message bodies, passwords, DB URLs, or private filesystem paths.

Stop conditions

Stop without continuing if:

the environment is not clearly disposable/non-production;
any existing customer/production container, DB, volume, hostname, DNS, or secret would be touched;
the checked-out SHA is not exact;
cleanup targets cannot be unambiguously isolated;
any step would require public deployment, external email, DNS, purchase, or production access.

Rollback / cleanup

This exercise must create only disposable resources. Cleanup is the rollback: remove the exact Compose project, volumes, networks, synthetic DBs, outbox files, restore targets, and temporary backup artifacts created by this run. Do not remove pre-existing resources.

Evidence output

Return a concise report with: exact SHA, image identity/digest, environment class (isolated non-production), each stage PASS/FAIL, migration head, timestamps/durations, cleanup confirmation, and any blocker. Redact all secret/private values.

Execution update — #29 was actually launched against the frozen candidate 0c05e7037b5d07029401aad2d6515ef6c243a08c using a temporary branch-only workflow (ops/rc1-runtime-proof) that targets the existing [self-hosted, Linux, X64, ashbi-vps] runner.

Workflow run: https://github.com/camster91/synapse/actions/runs/33885206182
Workflow commit: 874104bd4d30a73b6716dff6f472ac9ae0c08e5d

Safety design of the launched proof:

workflow exists only on the temporary ops branch; main is unchanged;
checkout detaches to the exact RC1 candidate before runtime work;
unique Compose project name per run;
fixed production container_name entries are removed only in a temporary local copy;
app binds to a random loopback-only host port rather than a public port;
PostgreSQL must expose no host 5432 binding;
generated disposable credentials only;
local verification sink only, no external email;
lifecycle smoke uses only its random synthetic account;
backup and restore run against disposable data, with restore into a separately named empty DB/upload target;
cleanup trap removes containers, networks, volumes, DB state and temporary files;
only privacy-minimal exact-SHA/image/check-result evidence is retained.

Current blocker: the job is queued and has not executed any steps. This is not an application failure. The same ashbi-vps self-hosted runner path is also currently leaving a recent human-health verification workflow queued, which indicates the runner is offline/unavailable or otherwise not accepting work account-wide.

#29 remains open. No container, database, volume, production service, DNS, customer data or external email has been touched because the runner has not started the job.

Runner blocker update — 2026-09-04

The disposable RC1 proof is still queued as GitHub Actions run 33885206182 with zero executed steps. Cross-repo comparison now confirms Human Health run 33879553019 is also queued on the same [self-hosted, Linux, X64, ashbi-vps] label, so this is not currently evidence of a Synapse workflow/runtime failure.

The central runner/account incident is tracked in camster91/ashbi-platform#399, which now contains a read-only SSH diagnostic to discover the exact runner process/systemd unit without guessing a service name. No runner restart/re-registration, billing change, permission change, production service change, or VPS mutation has been authorized or performed.

#29 remains execution launched / awaiting runner availability. When ashbi-vps resumes, run 33885206182 is already prepared to test exact candidate 0c05e7037b5d07029401aad2d6515ef6c243a08c with disposable containers/DB/volumes, loopback-only app exposure, backup/restore, privacy-minimal evidence, and unconditional cleanup.

Correction to the runner blocker classification — 2026-09-04

Further repository evidence found after the previous comment: camster91/magic-type-quest/docs/ASHBI-CI.md documents the known ashbi-vps-magic-type-quest runner as repository-scoped to Magic Type Quest. It uses /opt/actions-runner, service user magicci, and systemd unit actions.runner.camster91-magic-type-quest.ashbi-vps-magic-type-quest.service.

That runner is not eligible to accept Synapse jobs merely because it also has the ashbi-vps label. Therefore queued run 33885206182 should be classified as no proven eligible Synapse self-hosted runner, not as proof that the VPS/runner service is offline.

The disposable proof workflow remains technically prepared and still checks exact candidate 0c05e7037b5d07029401aad2d6515ef6c243a08c, but it cannot execute until one of these is explicitly approved and configured:

a separately repository-scoped Synapse runner on the approved VPS; or
another isolated Docker-capable execution environment with private-repo access.

Do not broaden or repurpose the privileged Magic Type Quest runner for Synapse by default. Runner registration/permission changes are separate approval-gated infrastructure mutations.

No VPS service, runner registration, production system, or customer data was changed.

Decision-ready self-hosted runner option — 2026-09-04 (proposal only; not executed)

Current GitHub and repository documentation support a least-privilege way to unblock this proof without weakening the existing Magic Type Quest runner:

Proposed Synapse-specific runner

GitHub scope: repository-level runner for camster91/synapse only.
Suggested runner name: ashbi-vps-synapse.
Suggested custom labels: ashbi-vps, synapse in addition to GitHub's default self-hosted, Linux, X64.
Separate host service user: synapseci (do not reuse magicci).
Separate install directory: /opt/actions-runner-synapse (do not reuse /opt/actions-runner, which contains the Magic Type Quest runner registration/workspace).
Separate work directory under that install.
If Docker access is required for P0: Run production Compose image/database smoke and close configuration audit #29, membership in the host docker group must be treated as root-equivalent privileged access and the runner must remain private-repo/repository scoped.
Keep untrusted fork PRs off this runner. Any later PR workflow must enforce same-repository-head checks before privileged self-hosted execution.

GitHub's current official docs confirm repository-level runners are supported; adding one requires repository-owner/admin access plus a time-limited registration token. On Linux, after registration, svc.sh can install/start/status the runner as a systemd service.
Sources:

Existing Ashbi pattern for comparison: camster91/magic-type-quest/docs/ASHBI-CI.md documents a separate repository-scoped runner with its own service user and systemd unit. That registration must remain isolated.

Installation safety requirements

Re-query current VPS users, /opt directories, disk/memory, Docker health, and existing runner units first.
Do not read or copy another runner's .credentials, .runner, tokens, or _work contents.
Generate the Synapse repository registration token only at action time; never store or paste it in issues/chat.
Download the current Linux x64 GitHub runner from the official release and verify its published checksum.
Register only against https://github.com/camster91/synapse with the Synapse-specific name/labels/work directory.
Install the service as the dedicated service user, verify Listening for Jobs, then allow the prepared disposable workflow to run.
After P0: Run production Compose image/database smoke and close configuration audit #29, decide separately whether the runner should remain installed for CI or be removed.

Rollback/removal

If registration or service startup is unhealthy, stop/uninstall only the newly created Synapse runner service and remove the Synapse registration using a short-lived GitHub removal token. Do not alter the Magic Type Quest runner or production application services.

Current approval boundary

Creating the user/directory, adding Docker-group access, generating a runner registration token, registering the runner, or installing/starting its service are privileged VPS/GitHub mutations and require explicit approval for this exact setup. None have been performed.

Exact disposable-run preflight — candidate `0c05e7037b5d07029401aad2d6515ef6c243a08c`

Use this checklist at action time. It is preparation only; it does not authorize running against any existing VPS/production environment.

Required isolation

Fresh checkout at exact SHA 0c05e7037b5d07029401aad2d6515ef6c243a08c.
Docker-capable non-production host or isolated local machine.
No existing Synapse database, uploads volume, DNS, reverse proxy, public hostname, customer data, or production secrets.
Stop immediately if isolation cannot be proven.

Disposable Compose contract

docker-compose.prod.yml requires DATABASE_URL, NEXTAUTH_URL, NEXTAUTH_SECRET, SYNAPSE_ENCRYPTION_KEY, POSTGRES_USER, POSTGRES_PASSWORD, and POSTGRES_DB; PostgreSQL has no host 5432 publication; app startup is prisma migrate deploy → uploads reconciliation → server.

For #29 only, use the loopback local email sink:

EMAIL_PROVIDER=local-sink
AUTH_EMAIL_LOCAL_SINK=disposable-lifecycle-only
NEXTAUTH_URL=http://127.0.0.1:3000
if AUTH_PUBLIC_URL is set, it must also be loopback.

Never use that sink on a beta/public hostname; it does not satisfy #60.

Lifecycle proof

Run against the same disposable DB/HTTP target with:

LIFECYCLE_SMOKE_BASE_URL=http://127.0.0.1:3000
LIFECYCLE_SMOKE_CONFIRM=create-and-delete-disposable-account
DATABASE_URL=<same disposable database>

Do not set LIFECYCLE_SMOKE_ALLOW_REMOTE=true for this #29 exercise.

Required outcome: registration/onboarding/export/wrong-password deletion/correct deletion pass and the DB assertion reports zero remaining disposable account/auth rows.

Backup proof

SYNAPSE_BACKUP_DIR must be an absolute private directory and cannot be / or $HOME; SYNAPSE_UPLOAD_DIR must name the disposable uploads directory. Backup must produce database.dump, uploads.tar.gz, manifest.txt, and checksums.sha256.

This repository backup is not encrypted/off-site by itself; do not claim #61 from this exercise.

Restore proof

Restore only into a newly created empty disposable DB and empty absolute uploads directory with:

RESTORE_CONFIRM=EMPTY_DISPOSABLE_DATABASE
SYNAPSE_BACKUP_PATH=<one exact backup directory>
RESTORE_DATABASE_URL=<empty disposable restore DB>
RESTORE_UPLOAD_DIR=<empty disposable absolute directory>

The script verifies checksums/archive paths, restores DB/uploads, checks Prisma migration status, and reconciles uploads.

Required evidence

Record only:

exact SHA;
local image ID/digest if available;
migration head;
UTC start/end timestamps;
health/readiness results;
lifecycle stage pass/fail;
backup artifact names/checksum pass;
restore duration/result;
representative record/upload counts;
cleanup confirmation.

Never record passwords, connection strings, raw tokens, generated account email/password, secret values, or file contents.

Cleanup gate

Before declaring #29 complete, remove only the explicitly named disposable containers, networks, volumes, source/restore DBs, backup directory, restore uploads directory, and any temporary files. Confirm no listener/volume/DB from the exercise remains.

Execution handoff remains valid conceptually but is temporarily superseded by PR #95 recovery correctness work. Do not run the disposable Docker proof until #95 is reviewed and explicitly merged, then refresh the exact candidate SHA and use the merged recovery scripts. The intended topology remains: loopback app, Compose-internal PostgreSQL only, lifecycle smoke against the same disposable DB, backup of the same disposable uploads/database, restore into a separately named empty disposable DB/uploads target, privacy-minimal evidence, and complete cleanup.

#29 recovery blocker update — final review found four additional fail-closed defects on PR #95: archive link scanning can be bypassed by grep -q + pipefail; hard-linked upload files can produce backups the restore gate rejects; the empty-database preflight does not cover all user-defined object classes; and backup/restore root symlink checks can be bypassed by trailing separators or linked parent components. #29 remains held. These are being corrected on the same focused PR before it is marked ready. Do not execute the external Docker/restore proof against current main or an intermediate #95 head.

#29 execution hold — current recovery prerequisite is PR #95 exact head 729094c06e8085310e3df839a5e44b025b873820.

Do not run the disposable backup/restore proof against current main yet. The old recovery tooling can reconcile the wrong upload target and lacked several fail-closed archive/database guards. PR #95 now contains the focused recovery corrections and remains draft pending exact-head Codex + Ashbi Local CI reconciliation.

After #95 is accepted and merged, #29 must bind to the resulting new main SHA and immutable image identity before any external Docker execution. No Docker host, production data, or external environment is authorized by this comment.

#29 prerequisite update — PR #95 is now frozen at exact head 57ece7fc80bbc3ac125131ffc03fc66598b9d7f7. This head has passed Ashbi Local CI and GitGuardian. Fresh Codex review is still running after the final public-schema and concurrent-DDL restore guards. Keep #29 execution on hold until #95 is fully reviewed and merged; then bind the disposable Docker proof to the resulting new main SHA/image.

Recovery prerequisite update — 2026-09-05

PR #95 is now ready for review on exact head f8de3ee3180a455634a3261f82020675795e85fe.

Exact-head evidence:

final Codex review: no major issues;
Ashbi Local CI: passed isolated install, Prisma generate, TypeScript, ESLint, focused auth/navigation/security tests, and production Next build;
GitGuardian: passed, no secrets;
GitHub-hosted CI Build / Build: failed before executing any steps (steps: null), consistent with the existing hosted-runner incident rather than observed application failure;
all recovery review threads are resolved.

The #29 runtime proof must not run against current main yet. Next sequence:

obtain explicit owner approval to merge fix: reconcile restored upload target during recovery drill #95;
merge exact reviewed head and record the resulting main SHA;
bind the disposable Docker/Compose proof, image, migration evidence, lifecycle smoke, backup and restore drill to that resulting SHA/image;
retain privacy-minimal evidence and clean up all disposable resources.

This update does not authorize merge, Docker execution, production access, deployment, or destructive runtime work.

RC1 recovery prerequisite update: current main remains b45170409543684a75579a13d7bdd6d8f8ffe8e8. PR #95 is now ready for merge review at exact head 1f0877757c79e16ebdc0b91b68f1ecf8059449c3. On this exact head, the manual Codex review completed with no remaining major issues, Ashbi Local CI passed isolated install/Prisma/TypeScript/ESLint/focused tests/production build, GitGuardian passed, and all inline recovery findings are resolved. Hosted CI Build / Build still fails before executing steps under the known runner incident. Do not run #29 against current main: merge #95 only with separate owner approval, establish the resulting new main SHA/image, then bind the disposable Docker/backup/restore proof to that exact artifact.

P0: Run production Compose image/database smoke and close configuration audit #29

Description

Goal

Current state — 2026-09-05

Candidate-binding rule

Original finding

Code-side state already fixed

Required runtime proof

Hard stop conditions

Recommended execution boundary — requires explicit action-time approval

Acceptance criteria

Approval boundary

Source of truth

Activity

camster91 commented on Aug 28, 2026

camster91 commented on Sep 1, 2026

camster91 commented on Sep 4, 2026

camster91 commented on Sep 4, 2026

camster91 commented on Sep 4, 2026

camster91 commented on Sep 4, 2026

Codex/desktop handoff — disposable RC1 Compose proof

Objective

Repository

Exact candidate

Source files / contracts

Scope

Acceptance criteria

Stop conditions

Rollback / cleanup

Evidence output

camster91 commented on Sep 4, 2026

camster91 commented on Sep 4, 2026

camster91 commented on Sep 4, 2026

camster91 commented on Sep 4, 2026

Proposed Synapse-specific runner

Installation safety requirements

Rollback/removal

Current approval boundary

camster91 commented on Sep 4, 2026

Exact disposable-run preflight — candidate 0c05e7037b5d07029401aad2d6515ef6c243a08c

Required isolation

Disposable Compose contract

Lifecycle proof

Backup proof

Restore proof

Required evidence

Cleanup gate

camster91 commented on Sep 5, 2026

camster91 commented on Sep 5, 2026

camster91 commented on Sep 5, 2026

camster91 commented on Sep 5, 2026

camster91 commented on Sep 5, 2026

camster91 commented on Sep 6, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Exact disposable-run preflight — candidate `0c05e7037b5d07029401aad2d6515ef6c243a08c`