Memo version 3 uses three new approval IDs. The consumed 2026-09-16 IDs stay consumed.
Assistant: grok
Assistant-Session: 01a0e2a1-8058-7553-9999-b7d106c17047
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
A configured exec owner may receive fields from other consenting kv lanes.
Each lane is gated, consumed and read through its own AppRole; any refusal
starts no child. Companions are part of the owner digest.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 226514@bnt-lap001
Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 272244@bnt-lap001
Assistant-Session: c8962fa7-b290-47df-865f-403ddb6c77e9
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 272244@bnt-lap001
Assistant-Session: c8962fa7-b290-47df-865f-403ddb6c77e9
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 272244@bnt-lap001
Assistant-Session: c8962fa7-b290-47df-865f-403ddb6c77e9
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 272244@bnt-lap001
Assistant-Session: c8962fa7-b290-47df-865f-403ddb6c77e9
railiance-platform e82bb289 recorded against SECRETS-WP-0006-T05 (explicit wait
on T04 serving; CCR-2026-0003 is provenance only). 29cccf8a recorded against
SECRETS-WP-0008-T06, including the open tenant:coulomb vs tenant:platform
question for the service JWT, left for an owner session. railiance-clock's
review request opened as SECRETS-IN-0003. The intelligence-radar messages are
superseded by SECRETS-WP-0010-T03 (done 2026-09-16) and answered by pointer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
Verified against gate-house's committed ruling (decisions/decisions.md,
GH-DEC-2026-017) and amendments A9-A13, then ops-warden's reference change set
(a70f559, wiki/playbooks/netkingdom-layer-declaration.md). They agree.
layer.yaml: standard_version removed; derived: true and derived_from:
INTENT.md added; declared_by kept. INTENT.md frontmatter never carried
standard_version, but its standard: value was a version-pinned path; it is
de-versioned as the reference instance did. No layer value is re-spelled:
INTENT.md still says Engine and layer.yaml still says engine.
The checker changes in the same commit because it listed standard_version as
a required key: removing the field alone would have made a conforming
declaration exit 2 MALFORMED. It now reads INTENT.md as the governing form,
requires the derived marking, rejects a returning standard_version in either
form, checks both layer values against the closed four-token vocabulary
(Taxonomy included) after an ASCII fold, and reports a post-fold disagreement
between the forms as a finding rather than resolving it by precedence.
Tests assert the fold, not per-file spelling, and cover fold agreement, a
real disagreement, the closed vocabulary and a returning version. Full suite
430 passed.
role:, pep-stance.yaml and schema_version are untouched (not ruled). Still
open: where the removed version lives in a derived conformance record; asked
of gate-house by ops-warden (4220413a), followed rather than chosen here.
Closes the SECRETS-WP-0008 note that waited on the reference form.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
ops-warden and railiance-platform asked, independently, which OpenBao location
`secrets-engine exec --catalog whynot-design-npm-publish` reads. Answered from
this repository's own code and catalog with no OpenBao read and no value.
It reads `secret/coulomb/whynot-design/npm/publish` — the legacy, ungoverned
duplicate. `_fetch_value` concatenates the catalog's `mount` and `path` with no
override or fallback, so the proven pilot published from the duplicate and the
lowercase `npm_token` field is the field there. ops-warden's front door names
this repository as exec_owner, so it currently routes callers at a path no CCR
covers.
Recorded in SECRETS-WP-0006 with what a move to the governed lane requires, and
flagged that the duplicate must not be destroyed until the lane moves. Whether
the two locations hold the same value is a value comparison and is not answered
here.
Also records GH-DEC-2026-017 against SECRETS-WP-0008: INTENT.md governs, the
sidecar is derived, the vocabulary is case-insensitive so nothing is re-spelled,
and standard_version comes out of layer.yaml once ops-warden updates the
reference form this repository copied.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
Set flavor on open workplans from origin/prose/status. Copy existing
depends_on aliases only. Do not promote residuals.
Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
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
The live proof in 03c0569 showed validate_decision_envelope rejecting every
real allow. The evaluator normalizes before hashing -- the request tenant is
copied onto subject and resource, and a registry hit copies type, tenant and
selected attributes onto the refs -- so binding.request_digest covers
material we never sent. Byte-equality against our unenriched request was
unsatisfiable, not merely mismatched.
THE RULE WAS ALREADY PUBLISHED. flex-auth's canonical-request-digest.md
section "Normalization" states the enrichment and tells consumers what to do
instead: compare structured binding fields to the proposed action, treat
request_digest as the evaluator's statement of what it hashed, and recompute
independently over the tuple the binding carries. I raised this with them as
an unpublished gap and asked them to pick between three shapes; it was in
their contract already and the answer was the first of the three. Nothing
was blocked on them, and this follows the published rule rather than one I
inferred.
- _require_binding_corresponds: everything we proposed must survive
unchanged -- tenant, action, context, subject.id/type,
resource.id/type/system, and every attribute we sent.
- Enrichment may add only type, tenant, attributes. Any other added field is
refused, and an enriched tenant must be the request tenant, so a
cross-tenant binding cannot arrive wearing our request's clothes.
- request_digest is still verified, now against binding_tuple(binding) for
self-consistency rather than against material we never sent.
- The envelope's top-level subject/resource get the same rule; they are
enriched too.
Proved against the artifact: the real decision:0f9c98f14545c42d now
validates, and the unrefreshed envelope is refused on lifetime -- reaching
the lifetime check at all is the evidence the binding checks pass on a real
decision. Negatives cover a restated resource.attributes.stage, a foreign
subject.tenant, and an unexpected enrichment field.
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
Probing the handed-over Service DNS name from the workstation found that
every *.svc.cluster.local name resolves here to one unrelated public
address via the ad.binect.de search suffix -- including names of services
that do not exist, which proves it is suffix expansion and not a record.
Pointing SECRETS_ENGINE_PDP_URL at the Service name would send the
CheckRequest body (subject, tenant, lane ids, stage, field names, purpose)
and the static Bearer token to that host. Decision envelopes are
structurally validated but not signed, so a responder knowing the package
and version can return a well-formed allow; the fail-closed posture
assumes the PDP is the PDP.
Not mitigated here: choosing the transport control is the owners' call,
not this consumer's. Recommended to FLEX-WP-0021-T05 that the handover be
a trailing-dot FQDN or explicit address, with the response channel's
authentication stated. Our pin stays unset, so the hazard is theoretical.
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
The vocabulary mapping this path was waiting on is not coming: gate-house
rejected it in GH-DEC-2026-008, because a translation can be confidently
wrong and fails open by accepting a claim approved for a different action.
The stronger option arrived instead, and both halves are enforced here.
flex-auth published binding.approval_binding_digest (FLEX-DEC-2026-007) to
fix the circularity this repo reported: a pdp_digest recorded at issue time
can never equal the request_digest of the request that carries the claim in
its hashed context, so with GH-DEC-2026-008 requiring that equality, destroy
would have failed closed forever on a check no correct record could pass.
- authorization.approval_binding_digest implements the published exclusion
rule, including Go's context,omitempty behaviour when stripping empties
the context; digest_material drops an empty context for the same reason.
- validate_decision_envelope recomputes the field rather than trusting it,
refuses a claim-bearing request whose decision records none, and compares
the claim's digest from step 1 against it -- never against request_digest,
which still covers the claim so it stays a sound replay identity.
- validate_approval_claim requires binding.pdp_path true before using
pdp_digest at all. Path intent is never inferred from a digest that
happens to be present; pre-schema-v3 approvals carry pdp_path false
regardless of any digest they hold.
Replay fixtures re-vendored from dd3ce4c. The destroy pins moved a second
and final time; approval_binding_digest did not, which is the point. The
fixture now demonstrates the property instead of asserting it: we rederive
fa07becf... from its own request through our canonical implementation,
proving we hash the same material flex-auth does rather than pinning a
constant we cannot reproduce.
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
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M65ovP3eiiPHubibvWs9mD
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 393550@bnt-lap001
Assistant-Session: 4bb359f9-1f12-4410-9e76-079cf23c82e4
