WP-0001 and WP-0003 are already finished with no open tasks. WP-0002's
remaining tasks (T01, T04, T05) are all gated on external owners
(KeyCape, audit-core, secrets-engine, platform credential custody);
nothing in this repo's own surface moves them forward.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: sonnet
Assistant-Process: 230497@bnt-lap001
Assistant-Session: 418cd0ab-dc61-43d8-8828-9ed571ac5c70
expired stays a terminal exit from valid (state machine unchanged),
but supersede() now also accepts it as a source status when the
caller supplies a validity window, linking a new successor approval
to the expired original instead of requiring a caller to mint an
unlinked replacement from scratch. Without a fresh window, an expired
source still conflicts exactly as before.
The original's status becomes superseded (not left as a bare dead-end
expired) and superseded_by points at the successor, so the link is
documented rather than hidden -- informed-decision's overview already
renders this automatically, no changes needed there.
Prompted by the operator missing infd-20260927-b01's approval window
during today's key-cape login outage (APPROVAL-WP-0003).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: sonnet
Assistant-Process: 169987@bnt-lap001
Assistant-Session: 322ef1ef-9048-4021-8570-b6d6f6347999
A12 r2 reaches every key and value of the declaration, including the
companion's version. The standard: path in INTENT.md was already
unversioned and is unchanged. tests/test_layer_declaration.py fails if a
version key, a versioned standard path, or companion_version returns to
the INTENT.md frontmatter or layer.yaml; schema_version and comments are
not reached. One prose citation ("the v0.5 scope rule") in a rationale
value is allowlisted by exact text and reported to gate-house as open.
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 files before editing: GH-DEC-2026-017
in decisions/decisions.md and amendments A9-A13 in
docs/amendments/v0.8-section-11-declaration-amendments.md, then ops-warden's
reference change set (wiki/playbooks/netkingdom-layer-declaration.md and its
applied instance, ops-warden a70f559). Ruling and playbook agree.
layer.yaml: standard_version removed; marked derived: true / derived_from:
INTENT.md; header rewritten to say it does not govern and that a post-fold
disagreement between the forms is a finding. The Framework comment is
de-versioned for the same reason.
INTENT.md: the frontmatter layer: key is the declaration. It carried no
standard_version key, but its standard: path pinned _v0.7.md; de-versioned as
the reference instance did, since a pinned path reads as a validity condition.
Prose citing v0.7 as the accepted statute is left as is.
NO LAYER VALUE IS CHANGED. INTENT.md says Engine, layer.yaml says engine; the
section 3 vocabulary is closed and compared after an ASCII fold, so they agree.
No conformance checker exists in this repository, and no test reads
standard_version, so nothing else had to change with the field. Test suite:
156 passed. companion_version and schema_version are left untouched; the
ruling does not cover them.
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
informed-decision asked whether its binding.principal and ours name the same
field, since both GH rulings said its slice canonicalizes "two of the five".
They do not: ours is the party on whose behalf the act is performed, taken from
the decision request's subject, while theirs is the approver — which appears
here only as an entry and never in binding. Only target overlaps.
Records the four-role distinction normatively in docs/approval-claim.md and
guards it with a test asserting the act digest is insensitive to the approver
while the approver stays recorded on the entry. Folding approver identity into
the digest would now break view_hash's assumption here rather than silently in
that repository.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QDzGbdDFnVJBxDgdp7RvpH
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2191554@bnt-lap001
Assistant-Session: d69bb7c3-b7b2-41c4-8287-6baef48c0993
key-cape reports the withdrawal came too late: approval-engine-operator
was provisioned in the 2026-09-09 custody window and is wired into a pod.
A live credential that can create and approve approvals, presented by
nobody, is a worse resting state than either extreme.
As requesting owner: disable, do not delete. CCR-2026-0018 stands so it
is restorable under the narrowing constraint once a presenter exists. A
recorded expiry was rejected — it promises to act later on a capability
that is dangerous now, guarding exactly the case where nobody is
watching.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
audit-core's completeness contract landed, and our single per-source beat
is the shape it rules inadequate: it is discharged by whichever class is
busy, so a revocation stream that has gone silent looks identical to a
quiet one — and revocation is the only silence here that matters.
Emit one nothing-to-report assertion per declared class, all four in one
transaction so a partial emission cannot report some classes healthy and
others stalled. Carry type audit-core.heartbeat with class and assertion
on data. Pin that the first beat goes out at startup rather than an
interval later, since a declared-but-never-sent class is their
no_heartbeat_since_registration finding and not a skip.
Declare heartbeat_classes and the reconciliation surface in the source
registration, including the residual neither control covers: a
compromised emitter suppresses the event and its own heartbeat together.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
gate-house (GH-DEC-2026-013) was right that our wording implied a fact
about the person. The tenant comparison is store isolation — does this
caller belong to the store this engine serves — and a registration-
supplied claim satisfies that while satisfying no doctrine about the
approver's own membership. Exact equality cannot see the difference, so
state it, and note that provenance gets recorded on the entry the way v4
records principal_type once the claim carries it.
Answer informed-decision's R3 in the claim contract: view_hash and
binding.digest answer different questions and must not be merged. Three
hashes, three questions. Recommend their binding document carry our
digest rather than re-canonicalize the same five fields, so the act has
one canonicalization and a mismatch is detectable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
railiance-platform asked and declined to guess, which was right — this
registration carries the widest scope set of the pair. Nothing in this
repo obtains an OAuth token; it only verifies them. Scope by scope the
bundle describes no single actor: approve now belongs to
informed-decision's human client, emit is redundant against the server's
own heartbeat, and no requester identity was ever settled for create.
Cancel CCR-2026-0020 as an owner decision rather than leave it in_flight,
keep verifier custody CCR-2026-0018, and record that a future presenter
gets a narrowed registration — approve must not travel with the
operational scopes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
Schema v4 gave the deployment a silent drift surface: the pinned pair is
self-consistent, migrating to 3 and serving 3, while this repository has
moved to 4. That reads as healthy, which makes it worse than an error —
the failure is the assumption that the deployment records approver
principal type.
Document v4 in storage-operations, state in the deploy runbook that the
pin predates it, and add a test that requires the statement whenever the
release record's schema version differs from this repository's. Verified
to fail when the acknowledgement is removed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
An entry stored subject_id, assurance and evidence_ref but nothing about
what kind of principal bound the approval, and subject_id is a naming
convention rather than a verified claim. /entries is not restricted by
principal type — only /consume is — and the approval-engine-operator
client holds approval:approve, so a service can supply approver evidence
today. Whether it may is gate-house doctrine; that it is legible is ours.
Add entries.principal_type, populate it from the verified token, surface
it on the object and the audit evidence path (not the claim, which stays
least-disclosure), and migrate v3 stores leaving legacy rows null rather
than back-filling a claim nobody made.
Also corrects two statements in the requirements issued to
informed-decision: agent tokens are not barred from approval:approve, and
an empty assurance object is accepted rather than refused.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
informed-decision (INFD-WP-0001) has claimed the browser-facing approver
UI this repo disowned. Write down what this engine requires of it, and
name the three places the current contract does not fit: the human client
lacks approval:read for the object it must render, the assurance claim is
the only place MFA survives into the record and must be given a shape,
and view_hash has nowhere to ride into an entry whose body is discarded
by design. Also record that there is no inbox endpoint and never will be.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
key-cape (KEY-WP-0013-T02) asked for two exact strings for the human
approver registration. This engine is a bearer-token resource server: no
redirect endpoint, no authorization-code/PKCE path, and no Ingress or
external origin, so neither string exists here. Record why, name the
missing owner (a browser-facing approver UI outside this repo), and
confirm that the access token — never the ID token — is what this
resource validates.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
