Implement lifecycle workspace publication and audit delivery

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a10780-6d41-7952-9718-dfbc1f41236f
This commit is contained in:
tegwick 2026-10-04 20:17:24 +02:00
parent ee472acc87
commit 5fec7de4cb
21 changed files with 1022 additions and 78 deletions

View file

@ -0,0 +1,70 @@
# Lifecycle workspace and delivery
2026-10-04; INFD-WP-0007-T02 through T06, source implementation.
## Human workspace
With `lifecycle_policy` configured, the signed-in home links to `/decisions`.
The workspace uses the same headless service as the API. Existing KeyCape
sessions establish identity; existing origin and CSRF checks protect forms.
Users can search, prepare a draft, record source metadata and evaluations,
comment, publish to explicit members/groups, refine, compare consecutive
revisions and download authorized packet entries. Source content is not fetched.
Packet uploads currently use the API. All forms receive fresh policy checks;
rendering a button grants no authority.
Publication records an audience for one revision. Access Engine determines access
using authenticated identity and retained record facts. Publication creates no
approval and no human disposition. New revisions require their own publication.
The workspace explicitly states that human acceptance is unavailable for these
drafts. Connecting a lifecycle revision to the existing protected presentation
and Approval Engine path remains T03/T05 work.
## Runtime and deployment inputs
The optional runtime `lifecycle_policy` object requires exactly `origin`,
`package`, `version`, `package_digest`, `caller_token_file`. Its package must
differ from the review package. No default policy or identity fallback exists.
The optional boolean `lifecycle_delivery` defaults to false. Configure both
for an admitted workspace with evidence delivery.
The deployment renderer accepts the same separate policy pins plus `pod_name`,
requires explicit `lifecycle_delivery: true` with that package, and generates
exact egress and an owner-review ingress proposal. It references the existing
mounted workload policy credential path; this does not authorize that workload
for a new package. Existing admission inputs render without lifecycle changes.
The API still requires its own admitted bearer verifier and listener composition.
## Independent evidence
On an enabled audit tick, up to 100 pending mutations are staged as immutable
`informed-decision.lifecycle` commitments in the existing outbox. The event UUID
is the delivery identity. Commitment metadata includes memo id, revision,
operation, a content digest and an existence assertion. The digest covers the
retained event and historical memo. Advisory text stays in source custody;
commitment delivery does not provide independent content reconstructability.
Pending obligations clear only after the outbox retains a receiver reference.
Lost replies retry with the same identity. The existing worker supplies bounded
delivery, reconciliation and a 24-hour lifecycle heartbeat. Undelivered evidence
keeps runtime readiness false. The current sink/reconciliation identity is
platform-scoped; other tenants fail closed at staging. Multi-tenant receiver
admission is not claimed. Kubernetes traffic readiness behavior is unchanged.
Tests use the actual local Audit Core receiver contract, including deduplication
and reconciliation. The agent-to-human collaboration scenario creates two
records, publishes/comments/refines and drains five events with unchanged runtime
configuration bytes. Its identity and PDP transport are synthetic. It proves
source behavior, not deployed workload authority or all seven acceptance cases.
## Remaining delivery work
T02/T04 require owner-admitted lifecycle policy actions/context, workload identity
and API ingress. The policy must cover all actions in LifecycleServiceContract,
including collection search and per-record checks. Existing compact-sitting pins
do not supply these grants. WP-0005 retains private intake composition work.
T03/T05 require the durable review handoff and human-only acceptance integration.
T06 requires full acceptance evidence, sender/cadence admission, immutable image,
database backup/migration and rollback verification. T07 requires the separately
approved concrete live rollout. No production pins or resources changed here.