tegwick
be1a388a84
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
80 lines
3.9 KiB
Markdown
80 lines
3.9 KiB
Markdown
# Storage operations
|
|
|
|
Production uses one SQLite writer on persistent `ReadWriteOnce` storage.
|
|
Production serve disables automatic migration and refuses schema drift or an
|
|
in-memory database.
|
|
|
|
```bash
|
|
approval-engine migrate --db /data/approvals.sqlite
|
|
approval-engine verify --db /data/approvals.sqlite
|
|
approval-engine backup --db /data/approvals.sqlite --output /backup/approval.sqlite
|
|
```
|
|
|
|
Migration is repeatable and sets an explicit `PRAGMA user_version`. Backup uses
|
|
SQLite's online backup API, verifies `PRAGMA integrity_check`, writes mode 0600,
|
|
and refuses to overwrite a target.
|
|
|
|
Restore is a stopped-single-writer operation:
|
|
|
|
1. Stop the StatefulSet and confirm no approval-engine or migration process has
|
|
the PVC open.
|
|
2. Preserve the failed database and its `-wal`/`-shm` companions for analysis.
|
|
3. Copy the verified backup to a new database path with owner 10001 and mode
|
|
0600. Do not merge a backup with old WAL files.
|
|
4. Run `verify`, then `migrate` if the release schema is newer, then `verify`
|
|
again.
|
|
5. Start exactly one replica and prove approval/entry/outbox counts, readiness,
|
|
claim retrieval, and idempotent audit drain before reopening callers.
|
|
|
|
Approval mutation and outbox insertion share `BEGIN IMMEDIATE` and one commit;
|
|
a failed outbox insert rolls the mutation back. Delivery occurs afterward and
|
|
does not roll back a committed mutation.
|
|
|
|
## Schema v3 — declared PDP-path intent
|
|
|
|
`GH-DEC-2026-008` added `approvals.pdp_path` (INTEGER NOT NULL DEFAULT 0).
|
|
Migration is the usual additive `ALTER TABLE`; run `approval-engine migrate`
|
|
before a production start, which refuses an unmigrated store.
|
|
|
|
Legacy rows default to `0`. Intent is **not** back-filled from a recorded
|
|
`pdp_digest`: an approval issued before the ruling was never declared for the
|
|
PDP path, and inferring the declaration from an incidental digest would
|
|
manufacture a statement nobody made. Such approvals stay usable by consumers in
|
|
this engine's own vocabulary and are simply not usable on the PDP path — which
|
|
is the ruling's intended cost, not a migration defect.
|
|
|
|
## Schema v4 — recorded approver principal type
|
|
|
|
`entries.principal_type` (TEXT, nullable) records what kind of principal bound
|
|
an approval, taken only from the verified token. Migration is the usual additive
|
|
`ALTER TABLE`; run `approval-engine migrate` before a production start, which
|
|
refuses an unmigrated store.
|
|
|
|
Legacy entries stay `NULL` and are **not** back-filled — the same reasoning as
|
|
`pdp_path` in v3. An entry written before this column existed carries no
|
|
verified statement about the principal that made it, and reading `user:`-shaped
|
|
`subject_id` values as `human` would manufacture approver evidence nobody
|
|
presented. A `NULL` here means *unclassified*, never *human*.
|
|
|
|
Downgrade is not supported: an older server refuses the store on the version
|
|
check rather than reading the column, which is the intended direction. Restore
|
|
from a v4 backup onto a v3 release requires re-pinning forward, not editing
|
|
`user_version`.
|
|
|
|
|
|
## Schema v5 — explicit human-control declaration
|
|
|
|
GH-DEC-2026-016 adds `approvals.human_control`, constrained to 0 or 1, with default
|
|
0. Existing objects remain undeclared regardless of recorded approver types;
|
|
there is no retrospective declaration or change to their five-field binding
|
|
digest. A successor inherits the declaration. Linking an existing successor with
|
|
a different declaration conflicts and rolls back the parent transition.
|
|
|
|
New human-control entries require verified type human at the engine boundary.
|
|
The declaration is retained on object/claim and audit events. Claim and consume
|
|
also refuse inconsistent persisted human evidence. Tests cover a persistent v4
|
|
upgrade and preservation, signed API refusal, quorum and outbox rollback. Take
|
|
and verify the existing backup before migration. The old v3 image must not serve
|
|
a v5 database; rollback requires the matching pre-migration backup and the
|
|
existing single-writer recovery procedure. No live database is migrated by the
|
|
source test run.
|