coulomb/approval-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Reconcile the release record; guard the image pin with tests

Browse source 
The publication at b51d174 pinned the manifest and appended a note, but left
three documents asserting the opposite. docs/image-scan-2026-09-06.md said "It
has not been pushed" in its Outcome block at the top while recording the
successful push at the bottom; its "Release status" section still said no
release digest existed and the manifest carried REPLACE_WITH_RELEASE_DIGEST;
and deploy/README.md still instructed an operator to replace a placeholder that
is now a real digest -- an instruction to undo the pin.

This is the derived-artifact staleness this repo argued for a rule about in
v0.8 §12 and then produced in its own release evidence, in the file another
repository would read to confirm what shipped. Superseded sections are now
marked in place with what replaced them rather than deleted, since they record
why the base changed and why the release was held. The scan doc carries a
status marker naming which parts state current state, including that a clean
scan is point-in-time and ages as advisories are published.

The workplan gains the publication entry it never got, and a re-check of T03's
full acceptance: a published image reads like a finished task, but the digest
was one of five requirements. Nothing is deployed -- the namespace is empty and
no secrets exist -- and production serve refuses to start without authenticated
audit delivery, so a rollout today would fail closed and prove nothing. T03
stays wait on T01's registrations and the audit credential.

Also corrects an earlier caution in the workplan that the digest was "a local
image id, not a release digest". That was wrong: with the containerd/OCI store
the build id is the manifest digest, and the registry resolves it.

tests/test_deploy_manifest.py holds the pin mechanically instead of by review:
both image references exist, are digest-pinned rather than tagged, are
identical, and no placeholder remains. The identity check matters because the
init container migrates the database the server then serves -- two different
digests there is a split-brain migration. Verified the guard fails on the drift
it targets, not only that it passes today. 116 tests pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PM5HnEAhokxdfcPqBNpT7D

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715850@bnt-lap001
Assistant-Session: eb557e93-7cb1-45d0-9e57-7d15b3edc60e
This commit is contained in:
tegwick 2026-09-07 09:04:34 +02:00
parent 3ab497e0a7
commit 119359c33d
4 changed files with 159 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

26
workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md
View file

@ -262,6 +262,32 @@ the tag, never the local image id
Rollout, restart and restore evidence remain gated on the KeyCape registrations
and audit sender credential.
2026-09-06 published (`glas-harness`, standing production authorization). The
push above succeeded outside this repo's session. Registry tag `0.1.0` resolves
to OCI index digest
`sha256:73333f5ceb55e48192e3095cb2e2a741cdc6ff0be2f18128301072b4a6b6eb9d`, with
linux/amd64 manifest `sha256:2064d5378e01801ecf9966ccec9c93aadd16d6b404ef4890983d89fa738c164c`.
Both `image:` references in `deploy/approval-engine.yaml` pin the index digest
at `b51d174`.
The index digest equals the local image id recorded above, which is a property
of the containerd/OCI image store rather than evidence of anything — the
publication evidence is the successful push and the remote index lookup, and
this repo verified the digest resolves against the registry independently. An
earlier caution in this workplan that the value was "a local image id, not a
release digest" was wrong on that point; the digest is correct and the pin is
sound.
2026-09-07 acceptance re-checked against the whole list, because a published
image reads like a finished task. T03's acceptance requires an immutable digest
**and** KeyCape registrations, an audit sender credential, a successful rollout,
and restart/restore evidence. Only the first is now met. `kubectl -n
approval-engine get all` returns nothing and no secrets exist, so nothing is
deployed; production `serve` refuses to start without authenticated audit
delivery, so a rollout attempted today would fail closed by design and would
prove nothing. **T03 stays `wait`** — on T01's registrations and the audit
credential, not on anything this repo owns.
## Wire outbox delivery and reconciliation
```task