Complete live empty custody consumer acceptance
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1029d-2c93-7500-a0e0-e3e089668b29
This commit is contained in:
tegwick 2026-10-03 20:39:15 +02:00
parent f85c9681a7
commit 608cbff477
4 changed files with 157 additions and 7 deletions

View file

@ -0,0 +1,67 @@
{
"date": "2026-10-03",
"workplan": "USER-WP-0037-T02",
"source_commit": "0d0751d",
"image_digest": "sha256:030fe90232e20bb02b372e3d16b8ff659a5407d54f6405eb85754262b9ad7dc6",
"canon_commit": "db319335b27b61b855382ee5af5d690f06eeb010",
"approved_document_sha256": "33a2ae086385028db1b654aa5646b7a98bcde1c5878c804e19315dadc3f87248",
"initialization": {
"actual_grant": false,
"baseline_initially_absent": true,
"baseline_receipt_matched": true,
"empty_no_grant_document": true,
"empty_record_returns_no_grant": true,
"failure_preserves_baseline": true,
"fresh_authenticated_owner_read": true,
"initialized_from_authenticated_receipt": true,
"injected_read_failure_returns_no_grant": true,
"ok": true,
"other_tenant_returns_no_grant": true,
"owner_read_clock_aware": true,
"reconnect_preserves_baseline": true,
"record_id_matched": true,
"record_revision": 1,
"runtime_enabled": true,
"same_revision_mutation_preserves_baseline": true,
"wrong_audience_login_denied": true
},
"after_controlled_pod_restart": {
"actual_grant": false,
"baseline_initially_absent": false,
"baseline_receipt_matched": true,
"baseline_survives_actual_pod_restart": true,
"capability_probe_read_at": "2026-10-03T18:30:58.194568+00:00",
"capability_probe_read_digest_matched": true,
"custody_write_denied": true,
"custody_write_denied_http_status": 403,
"empty_no_grant_document": true,
"empty_record_returns_no_grant": true,
"existing_baseline_receipt_matched": true,
"failure_preserves_baseline": true,
"fixture_service_serializes_live_empty_root_grant_null": true,
"fresh_authenticated_owner_read": true,
"hub_private_route_acceptance_claimed": false,
"injected_read_failure_returns_no_grant": true,
"metadata_list_denied": true,
"metadata_list_denied_http_status": 403,
"ok": true,
"other_tenant_returns_no_grant": true,
"owner_read_clock_aware": true,
"read_request_id": "91cd7235-9cfe-06c3-57a6-64a013d1cfcb",
"reader_login_request_id": "29a2fac4-8108-7ca5-d0a6-682c4a31f48d",
"reconnect_preserves_baseline": true,
"record_id_matched": true,
"record_revision": 1,
"runtime_enabled": true,
"same_revision_mutation_preserves_baseline": true,
"sibling_read_denied": true,
"sibling_read_denied_http_status": 403,
"wrong_audience_login_denied": true
},
"limitations": [
"No actual root grant exists: approved entries[] record.",
"Read failure and same-revision mutation are injected consumer checks, not production OpenBao outage or mutation.",
"Service serialization uses in-memory synthetic accounts/authorization harness against live authenticated empty custody source; no private Hub caller admission claimed.",
"Producer recovery/restore/audit completeness remains with railiance-platform; request IDs are correlation references, not inspected audit-log receipts."
]
}

View file

@ -0,0 +1,64 @@
# Live empty custody consumer acceptance
USER-WP-0037-T02 is complete for the approved empty/no-grant delivery. The
authenticated reader and persisted baseline work in the deployed consumer,
including an actual pod restart. This creates no root grant and does not close
USER-WP-0037-T03's independent private Hub caller admission.
Machine receipt: [consumer acceptance](2026-10-03-root-custody-consumer-live.json).
Source `0d0751d`; image
`sha256:030fe90232e20bb02b372e3d16b8ff659a5407d54f6405eb85754262b9ad7dc6`;
embedded NetKingdom canon `db319335b27b61b855382ee5af5d690f06eeb010`.
## Accepted source and initialization
Founder reported no known ceremony record. The reviewed initial entries[] document
contains no certified grants; record id nk-custody:platform-root, revision1, KV1.
Owner admission/publication receipts
platform-root-admission-20261003T181954Z-333977 and
platform-root-publish-20261003T181954Z-333977 both returned ok=true.
Document digest:
`33a2ae086385028db1b654aa5646b7a98bcde1c5878c804e19315dadc3f87248`.
The consumer's previously absent baseline was initialized once through the actual
dedicated projected OpenBao audience JWT, admitted Kubernetes role and bounded
read. The read matched the owner digest and exact configured source/record.
After the packaging owner's controlled pod restart the same database baseline
existed, matched the digest and was not reinitialized or reset. A separate
connection also verified persisted contents.
## Live boundaries
The fresh exact-path read matched the approved empty document. The adapter returns
no grant for platform and other tenants. A real login with the existing flex-auth
audience JWT was denied. With the real root-custody reader token, LIST on metadata,
GET of a sibling path and POST to the custody path each returned403. The POST used
an empty body with no required data, so even an unexpected write allowance could
not publish a valid KV document. No custody document was written by these probes.
The internal in-memory fixture service/serialization harness used the actual live
authenticated custody adapter and emitted optional AccountAuthority.root_grant
as null. Fixture authorization is not an admitted real Hub principal; this result
does not claim private HTTP route acceptance or real-user account verification.
Consumer-injected source failure and same-revision mutation produced no grant
and preserved the trusted baseline. These are consumer failure checks, not an
actual OpenBao outage or a changed producer document. Positive grants, revocation,
supersession and rollback were tested with synthetic offline canon fixtures; no
real grant exists to exercise those transitions live.
## Audit correlation and remaining ownership
Allowed read request_id: `91cd7235-9cfe-06c3-57a6-64a013d1cfcb`.
Reader login request_id: `29a2fac4-8108-7ca5-d0a6-682c4a31f48d`.
Read correlation time: `2026-10-03T18:30:58.194568+00:00`.
These references enable owner audit lookup; no raw token, document, rejected
response or private profile was printed. Audit-log retrieval was not performed.
Actual producer restore/recovery/read-audit receipts remain railiance-platform's
RPF-WP-0049/NK-WP-0045-T05 responsibility and do not reopen this consumer gate.
The owner observed one transient original database connection refusal at startup
on rollout and restart; Kubernetes retry recovered Ready1/1 and health/readiness
200. This occurred in the original runtime database connection before custody
assembly. It is recorded as a startup-reliability follow-up, not repaired or
expanded into unrelated work here.