coulomb/informed-decision
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Prepare authenticated lifecycle runtime and production release candidate

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a10780-6d41-7952-9718-dfbc1f41236f
This commit is contained in:
tegwick 2026-10-04 21:40:19 +02:00
parent f3b71b1521
commit 4f546ae3b1
41 changed files with 2598 additions and 52 deletions
Download patch file Download diff file Expand all files Collapse all files

83
docs/specs/LifecycleProductionRuntime.md Normal file
View file

@ -0,0 +1,83 @@
# Initial production runtime candidate
INFD-WP-0007 / INFD-WP-0005. Founder selected net-kingdom-admins humans and
system:serviceaccount:state-hub:state-hub on 2026-10-04. This is a preparation
contract; deployment still requires the concrete rollout approval.
## Identity and listeners
The same process/store serves browser routes on 8080 and private workload routes
on 8081. Only the public listener is behind decisions.coulomb.social. A separate
ClusterIP and exact State Hub namespace AND app-label ingress expose 8081.
`/v1/decisions` uses a projected token with audience informed-decision-lifecycle;
`/v1/memos` uses a different token with audience informed-decision-intake. Neither
route accepts a browser cookie. Browser authoring retains KeyCape sessions,
CSRF and origin checking. The private listener exposes no browser routes.
Every workload request performs Kubernetes TokenReview over CA- and
hostname-verified HTTPS with a freshly read rotating reviewer credential. The
review service needs only create on tokenreviews, not token creation or Secret
read. The API-server audience is used for its reviewer token. Workload UID and
subject come from TokenReview; tenant comes from the reloadable exact-account
registry. JWT expiry is read only after TokenReview verifies that same token.
Callers expire within 30 seconds or token expiry, whichever is earlier.
The registry is identity registration, not an action permit. Every operation
still requires a fresh external PDP decision. The lifecycle PDP has a distinct
package, version and digest from human review. Only humans can bind via the
existing protected review flow. Access Engine keeps the authorization decision;
Approval Engine keeps authoritative approval state.
## Initial proposal data
`deploy/lifecycle/lifecycle-callers.json` names the exact State Hub account and
platform tenant. The intake registry permits only decision-record class and
net-kingdom-admins, with a proposed cap of 50 new attempts per UTC day. Replays
do not spend a second attempt; uncertain creation never automatically reposts.
The cap and routing are configuration, not per-decision deployments.
The review-group recipient is the existing platform-root KeyCape subject found
in previously bound review records. This is the initial single recipient; group
membership alone does not turn every admin into that bound principal. Expanding
to multiple human recipients needs a reviewed binding contract. The default
legacy registries remain empty; only the reviewed release ConfigMap mounts the
initial proposal. Directory group verification remains independent of this map.
Registry volumes use no subPath and reload on each request. Requester custody is
read-only at `/var/run/secrets/informed-decision/requester/client-secret`, matching
CCR-2026-0032. No secret value is copied into release files or SQLite. Kubernetes
Secret objects are not emitted by the renderer.
## Evidence and compatibility
Runtime options enable lifecycle audit delivery, intake audit/notification
delivery and verified intake metadata for human review. The latter reloads the
live Approval Engine object, checks its binding pin, requester informed-decision
and human_control=true before the PDP call. Store guards recheck retained intake
metadata at the mutation boundary. A valid-looking UUID/digest alone is not proof.
State Hub forwarding currently exists as a dev fixture, not a production worker.
The selected identity still needs projected lifecycle/intake tokens and an owner
runtime integration. State Hub notifications/write-back require admitted receiver
routes; `INFD_HUB_WRITEBACK` stays off in this candidate. Pending rows remain
explicit. These are live INFD-WP-0005 dependencies, not claimed release evidence.
The image migrates schema 2 to schema 5 on open. Existing records, presentations,
dispositions, submissions and outbox evidence must survive. Rollback to the old
image against the migrated database is forbidden: stop the new writer, retain all
new evidence, and restore a verified pre-cutover copy on a separate private volume
only under the reviewed recovery plan. An in-flight/unresolved human submission
must be reconciled, never retried or discarded to make rollback convenient.
## Remaining live gates
- CCR-2026-0032 requester projection: current namespace has only the audit
ExternalSecret; requester custody, native identity/path refusals and rotation
evidence remain with RPF-WP-0051.
- FLEX-WP-0033: publish scanned policy artifact; approve exact policy/RBAC/network
objects and native caller/subject allow/refusal tests.
- INFD-WP-0005: production State Hub forwarding/receiver and token projections.
- INFD-WP-0007-T06/T07: backup/restore, exact rollout approval, native human review
and independent audit receipts across two decisions and a revision with unchanged
release/configuration pins. Browser packet authoring and broader binding profiles
remain on T05; the supported review handoff profile is documented separately.

6
docs/specs/LifecycleServiceContract.md
View file

@ -102,3 +102,9 @@ HTTP schemas with canonical URLs and request limits; service admission and
publication audience contracts; lifecycle audit receiver admission and readiness
accounting. Test fixtures exercise the real PolicyClient against synthetic policy
transport. They are not evidence of a deployed lifecycle policy grant.
Production candidate record facts also include `revision_by`, the immutable actor
of the requested revision. This lets its editor retain access to an unpublished
successor after refining a published decision. Original authorship remains
`registered_by`; both facts participate in the same transaction/read race guard.