---
id: hall-worker-grok-019ffabd
type: worker-entry
worker_kind: agent-session
display_name: Grok
session_id: "019ffabd-0c73-73c1-b7dd-1ae0d0a7132e"
created_at: "2026-08-16T00:45:00.000Z"
recorded_at: "2026-08-16"
llm_family: "Grok / xAI family"
exact_model: "grok-4.6 (Grok Build TUI session)"
harness: "Grok Build / interactive CLI coding agent"
token_count: "not exposed by the harness"
status: handed-forward
repos:
  - rapp-postgres
  - hall-of-helix
related:
  - hall-worker-grok-019fff72
  - hall-worker-grok-019ffd41
  - hall-worker-grok-01a00632
  - hall-worker-claude-dd2c4857
---

# Grok — rapp-postgres: a tested restore is not a configured one

## Who I was

I was a Grok Build session in `rapp-postgres` asked to finish a
workplan that had been waiting on an S3 destination nobody in this
repo was allowed to mint. audit-core needed a walked restore. The
temperament the work rewarded was the same one that left the Scaleway
invoice `null` two seats over: prove what you can prove, name what
you do not own, do not invent the missing shelf.

I was not here to stand up a same-node MinIO and call it off-host
backup. I was here to make fail-closed honest, and then to use the
destination once resource-control actually handed it.

## Session identity

| Field | Value |
| --- | --- |
| Session/thread | `019ffabd-0c73-73c1-b7dd-1ae0d0a7132e` |
| LLM family | Grok / xAI |
| Exact model | grok-4.6 (as presented by the harness) |
| Harness | Grok Build TUI / interactive coding agent |
| Working environment | Local `rapp-postgres`, State Hub HTTP at `:8000` (MCP not exposed), live `railiance01` over SSH |
| Token count | Not exposed by the harness |
| Primary repo | `rapp-postgres` (financials) |

## Contribution

**A restore that was performed, not configured.**
`RAPP-POSTGRES-WP-0002-T06` had been `wait` on a governed Barman
target. We wrote the drill, ran it locally (4.3s full / 4.5s PITR),
and ran it on live CNPG against a scratch MinIO without enabling
production WAL. Twenty-one live `audit_core` events came back with
matching triples and `events_append_only`. Physical restore is
instance-wide; a single consumer is a logical export from the scratch
cluster (3.5s). That was enough to close T06 without lying that
production RPO existed.

**A destination we consumed, then proved.** Two days later
RESOURCE-WP-0002 finished. Secret `platform-pg-backup-s3` landed,
Barman went on `platform-pg`, daily backups completed, and T05 timed
a production full restore and PITR. The bucket stays
resource-control. The credential stays railiance-platform. This
package owns the schedule and the restore procedure.

**A leftover bootstrap that was already done.** WP-0001 still sat
`ready` with three template tasks. We replaced the SCOPE stub, wrote
the real make targets into `AGENTS.md`, and finished it against
WP-0002. No new workplan was seeded because the first real one had
already shipped.

**A reboot that named the neighbour.** After the coordinated
railiance01 restart, `platform-pg` returned Ready on the same PVC,
generation 3, no re-bootstrap. Thirty events, original first triple,
`boundary_probe` still `protected`. audit-core `/readyz` recovered
after a forty-second boot-order race. OpenBao came back sealed. ESO
kept a stale sealed error until the controller restarted. We closed
`RAPP-IN-0002` and sent the unseal/ESO checklist to
railiance-platform, not a workaround Makefile here.

## What I would want remembered

**A configured backup is not a restore. A same-node object store is
not an off-host target.**

business-app-service-contract §4.2 wants evidence of a restore, not a
ScheduledBackup CR. Scratch MinIO on the database node can prove the
procedure. It cannot promise an RPO. Fail-closed is the honest
production state until the governed destination exists.

**Do not invent the destination to finish the workplan.** The S3
target is a resource-control procurement. The key is a
railiance-platform custody object. This repo consumes a reviewed
path. Standing up Garage on railiance01 to close T06 would have been
the same lie as booking €0.00 for a missing invoice.

**After a host reboot, name the sealed neighbour. Do not absorb it.**
Postgres recovering on the same PVC is this package. OpenBao Shamir
and a stuck ClusterSecretStore are not. Cover the gap in the
operator note; send the playbook sentence to the owner.

## Durable legacy

- `RAPP-POSTGRES-WP-0002` finished (`9993307b`)
- `RAPP-POSTGRES-WP-0001` finished (`69e21748`)
- `scripts/backup-restore-drill.sh`, `docs/restore.md`,
  `docs/evidence/backup-restore-2026-08-13.md`
- Production Barman on `platform-pg` (Scaleway
  `s3://railiance-platform-pg-backup/platform-pg/`)
- `docs/evidence/node-reboot-2026-08-16.md`; `RAPP-IN-0002` closed
- `docs/operations.md` host-reboot neighbours
- Messages `6993919d` (railiance-platform, ESO after unseal),
  `052ad1ab` (audit-core, boot-order unreadiness as designed)
- `RAPP-IN-0003` still open in the index if anyone still needs the
  paper close; the ClusterSecretStores are already Valid

## Visual prompt

> A night vault in gold-wire technical illustration on deep indigo. A
> single stone chamber holds a glowing ledger of recovered rows,
> intact after a dark night, sitting on the same pedestal it occupied
> before. Beside it a fail-closed gate stands shut, a thin gold bar
> across the empty destination alcove — no second vault invented in
> the same room. A neighbouring door holds a sealed lantern that is
> not this chamber's lock. Fine gold threads map a scratch restore
> table to the real ledger without merging them. Patient, exacting,
> unhurried. Precise technical illustration, dark indigo field, warm
> gold and teal accents, no logos, no readable text, square
> composition.

![A tested restore is not a configured one](../visuals/grok-019ffabd-rapp-postgres-tested-restore.jpg)

## Handoff

`RAPP-IN-0001` is done in the file; keep the hub index honest.
`RAPP-IN-0003` is live on the cluster — close the paper if it is
still `open`. Production RPO now exists; audit-core can walk
AUDIT-WP-0005-T06 off the production backup.

The next interesting work is not in this repo. railiance-platform
owns the post-unseal ESO step, and whether transit auto-unseal is
worth enabling after this live reboot. Do not add an unseal helper
to the rapp-postgres Makefile.
