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

docs: correct the stale step-2 blocker, and ask custody about the npm lane path

Browse source 
SECRETS-WP-0008-T02 still said access-engine Check was unreachable. That is
no longer true and the note read as current, so it is corrected rather than
left to mislead: Check is reachable through the owner-documented access
path and step 2 is proved against decision:0f9c98f14545c42d, a real v2
allow. Two defects that only a real request could expose -- the missing
tenant and the unsatisfiable digest join -- are fixed, so the task's own
acceptance line about failing closed on wrong digest and expired lifetime is
now exercised against a genuine envelope rather than a fixture.

What remains for that task is step 1 alone: approval-engine must serve the
claim endpoint, and APPROVAL-WP-0002-T03 is still wait with no deployed base
URL. One external dependency, not the two previously named.

SECRETS-WP-0006-T06: asked railiance-platform which KV location backs the
whynot-design npm publish lane (hub message 546403e4). The question is
narrowed to the path, since the endpoint agrees and ops-warden's
NPM_AUTH_TOKEN claim resolved here as a category error -- that is the
resolved injection env var, not a KV field name. Catalog left unchanged:
rewriting a proven production lane pointer from an inbox claim is the
unverified custody mutation this task exists to prevent.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715726@bnt-lap001
Assistant-Session: 80a42b32-cba6-4b23-8be0-68819b1a6092
This commit is contained in:
tegwick 2026-09-07 13:44:46 +02:00
parent 1b52771deb
commit 7eeb1c7265
2 changed files with 47 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

10
workplans/SECRETS-WP-0006-catalog-lane-adoption.md
View file

@ -293,6 +293,16 @@ location backs this lane. If the platform path is authoritative, the catalog
mount/path move is a reviewed lane change carrying its own approval, and the
declared field stays `npm_token` unless custody says otherwise.
Asked 2026-09-07 (hub message `546403e4` to `railiance-platform`). The question
is narrowed to the path alone, since the endpoint agrees and the
`NPM_AUTH_TOKEN` claim was resolved here as a category error rather than a
discrepancy. Also asked whether the current `secret/...` location still exists
if the platform path is authoritative — a stale duplicate holding a real token
is worth knowing about independently of this lane. Flagged to them that
ops-warden's `ready: false` is our expected fail-closed posture and must not be
read as corroborating the platform path. Awaiting reply; the catalog is
unchanged.
## Exit criteria

37
workplans/SECRETS-WP-0008-layer-model-lifecycle-conformance.md
View file

@ -111,6 +111,43 @@ local seam. The join is now implemented and tested; the remaining blocker is
genuinely external (approval-engine claim endpoint and access-engine Check, both
unreachable as of 2026-09-06).
Progress 2026-09-07. **Step 2 is no longer blocked and is proved against a real
decision.** The 2026-09-06 note above says "approval-engine claim endpoint and
access-engine Check, both unreachable"; the second half of that is now out of
date and is corrected here rather than left to read as current.
`access-engine` Check is reachable through the owner-documented access path
(loopback `kubectl port-forward` to the named pod plus a bounded `TokenRequest`
token; `docs/pdp-access-path.md`). A real CheckRequest for
`glas-claude-agent-dev-anthropic` returned `decision:0f9c98f14545c42d`, `allow`,
`catalog_lane_policy_matched`, under package `secrets-engine.catalog-lane.lifecycle`
v2 with `binding.tenant: tenant:platform`.
Two defects surfaced only because the request was real, both now fixed:
- Our CheckRequest carried no `tenant`, which v2 treats as a `wrong_tenant`
denial rather than an omission (`80eafaf`).
- `validate_decision_envelope` required byte-equality between the binding and
our unenriched request, which no real decision can satisfy because the
evaluator normalizes and enriches from its registry before hashing. Corrected
to the published consumer rule in `10baad9`.
So the acceptance line "wrong digest, expired lifetime, superseded status, or
missing record fail closed before OpenBao" is now exercised against a genuine
envelope: the unrefreshed live decision is refused on lifetime, and a restated
`resource.attributes.stage`, a foreign `subject.tenant`, or an unexpected
enrichment field are each refused.
**What remains is step 1 only.** approval-engine must serve the claim endpoint;
`APPROVAL-WP-0002-T03` is still `wait` with no deployed base URL, so
`resolve_consume_binding` returns `None` and production stays fail-closed. That
is one external dependency rather than the two this task previously named.
Also recorded, and not a blocker for this task: flex-auth's response channel is
unauthenticated (`FLEX-DEC-2026-010`). Fail-closed protects against a PDP that is
absent, not one that lies. Until `FLEX-WP-0024` ships detached signatures, the
enforced loopback address shape is what stands in for responder authenticity.
Blocked on the durable ActionAuthorization serving path owned with
`SECRETS-WP-0007-T04` / State Hub / `access-engine`.