DevOps task briefs: October 2026 R01–R05

Parent: 89803f50-5eb3-4fd1-a7eb-559daa7c9265 v2. Repository for every task: h8v6/heyaira. Implementation contract: remediation plan. The RESULT receipt pins this document's delivery branch and commit.

Registration status: all five pending. The assigned execution credential cannot call task_create; no task IDs have been invented. The coordinator must create one HeyAira task per row below, link the parent and the corresponding plan section at the receipt's result commit, and return their IDs in HeyAira. Git owns the detailed work orders; task descriptions should contain the goal, scope and acceptance references, not copies of repository files.

Common contract: tags security, devops, p2; separate branch/commit per task; backend/CI specialists implement code before DevOps operates it. Security reviews permission changes independently; DevOps executes only in its own owner-approved window. No secret values in code, examples, logs or receipts. Record actual tests separately from simulated provider/time tests and live attestation. Include base/result SHAs, approved production revision, rollback reference and residual risks in each RESULT. Recommended work-session limit: 4 hours per task stage (implementation or operation); at the limit write a handoff rather than broadening scope. Coordinator schedules further stages under the same finding when needed; time limits do not waive acceptance.

R01 task — narrow API secret mounts and isolate admin output

Summary: Give the API only its own read-only files and move token/recovery output to an operator-only one-shot container.

Executor / dependencies: DevOps with backend maintainer; independent of the other windows, admin DB role follows R02. Owner agrees secret placement and the recovery procedure before production execution.

In scope: R01 Compose/overlay mounts, deployment preflight, admin service, CLI/runbook examples and regression tests. Out: rotation of secret values, database role cutover, OpenBao TLS or other R06–R11 work.

Acceptance: Merged service mount inventory contains no API directory or writable secret mount; synthetic tests deny writes and access to unrelated files; all enabled API consumers work; admin output is mode 0600, exclusive, absent from API mounts and not logged. Owner-approved production checks and the R01 rollback procedure are recorded without file contents.

R02 task — separate migration, API, worker and backup DB roles

Summary: Remove startup migration authority from runtime logins and enforce the plan's worker queue/function boundary in PostgreSQL.

Executor / dependencies: Backend/DB maintainer implements, DevOps performs the cutover after R03 recovery acceptance. Owner agrees roles, rotation, startup change and window. Security reviews gateways and effective grants.

In scope: R02 explicit migrator, read-only schema validation in every existing entry point, role provisioning, bounded SQL gateways, service credential mapping, deployment guards, restore point and role tests. Out: redesigning tenant permissions, granting superuser to unblock tests, recreating PostgreSQL, or silently restoring broad runtime credentials.

Acceptance: Full PostgreSQL 16 role-session suite proves all positive consumer paths and denies DDL/role escalation/cross-queue access; backup dump/restore and post-restore lineage work; runtime services have no owner membership; migration credential never reaches them. Existing-volume and fresh-bootstrap tests pass. Live grants, compatibility rollback and revocation of the former shared runtime credential have value-free evidence.

R03 task — protect recovery copies and remove retention-key fallback

Summary: Separate retention authority, preserve provider lock compatibility, and maintain a verified immutable copy outside the production writer's scope.

Executor / dependencies: Backup maintainer and DevOps; R04 completes the direct restore/report integration. Owner agrees provider changes, costs, cadence, custody, retention/deletion horizon and key rotation.

In scope: R03 fail-closed retention configuration, primary locks, independent recovery bucket, daily encrypted copy, independent watchdog read-only monitor and isolated restore/retention tests. Out: enabling retention apply without its separate go, deleting retained backups, copying private age identity to server, or claiming R2 supports write-without-delete credentials.

Acceptance: Missing/partial retention key refuses even in dry-run; writer and retention credentials cannot access the recovery bucket; locked object and manifest deny overwrite/delete; a verified pair restores after simulated loss of the primary copy; unchanged-data days still produce protected copies; offline Mac is detected by the external monitor without reboot actions. Document real provider tests versus simulated expiry, zero legacy-mark preflight, retained APPLY=false state unless separately approved, and key cutover/rollback receipts. Direct restore uses read-only credentials.

R04 task — remove arbitrary restore SSH shell and bound reporting

Summary: Download backups directly with read-only R2 access and replace runtime-user SSH/sudo with a forced PASS/FAIL-only reporting identity.

Executor / dependencies: DevOps and restore/backup maintainer after R03 read credentials and recovery bucket exist. Owner agrees SSH/sudo changes, status bucket, credentials and report trust.

In scope: R04 Mac script/LaunchAgent, server-owned helper, dedicated SSH identity, separate status bucket/reader and removal of old restore-specific sudo/key access. Out: changing operator identities en masse, granting Docker access, moving private age custody, or accepting arbitrary report bodies/commands.

Acceptance: Isolated recovery restore passes; shell, PTY, forwarding, sudo/Docker, SFTP and argument-injection tests fail; only exact PASS/FAIL reports work; report credential cannot access data buckets; stale/failing reports remain visible; old arbitrary-shell route is removed with independent operator access preserved. Include approved sshd policy and rollback proof.

R05 task — isolate CI jobs on disposable hosted runners

Summary: Move the shared persistent test job to fresh hosted VMs and close alternate routes by which PR code could still select persistent runners.

Executor / dependencies: CI maintainer and DevOps; independent window. Owner agrees hosted-minute budget, GitHub workflow permissions/admission, runner group changes and retirement of the old runners.

In scope: R05 workflow runner/checkout/cache settings, reviewed immutable action pins, repository fork admission, runner retirement, network/credential attestation and concurrent/subsequent job isolation tests. Out: production deploys, production secrets in CI, bypassing required checks, or running PR head code under pull_request_target.

Acceptance: Both existing CI jobs pass with unchanged required-check names; two concurrent jobs cannot observe/control one another's workspace/containers; a later run starts clean; checkout persists no Git credential; untrusted PRs cannot schedule persistent runners, receive write tokens or production secrets. Private production management routes/tunnels are absent. Record the public HTTPS limitation explicitly; if the owner requires total production egress denial, install an external enforceable policy before accepting that window. Old runners are retired only after job completion and rollback is documented.