Written back by statehub fix-consistency after NK-WP-0035-T05 was added.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ek3zTdfMa35bPVDjVUyhxx
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 868701@bnt-lap001
Assistant-Session: b2e101b6-f501-40dc-9ee5-438cac36e21a
gate-house circulated v0.8 with two questions for this repository as owner of
the NetKingdom emission-cadence security profile: whether §17's ownership
paragraph reads in our own voice, and whether §11's new conformance item
follows the profile or diverges from it.
§17 is confirmed as written. It assigns the generic EmissionCadenceDeclaration
contract to info-tech-canon and to net-kingdom the MUST/SHOULD split, the
rare-class rate-monitoring prohibition, and the heartbeat-plus-reconciliation
obligation — which is emission-cadence-security-profile_v0.1.md §3, conjunction
included. No change.
§11 diverged in both directions and is corrected. Requiring a detection surface
of "heartbeat or reconciliation" of every load-bearing source withholds from a
volume class the expected-rate form the profile permits, and accepts for a rare
class either control alone where the profile — and the checker in
tools/emission-cadence-profile — require both. A rare class covered by a
heartbeat alone has no reconciliation to catch divergence, and one covered by
reconciliation alone produces no claim that can go missing, which is the whole
reason §9.6 rejects rate monitoring there. The item also contradicted its own
following paragraph, which admits rate monitoring except where the class is
rare.
The check now defers the form to the governing profile rather than restating a
split that is §17's to assign, carries the volume/rare distinction explicitly,
and states that classification is the source's published inventory and never the
checker's to infer from a name, payload, or observed rate — otherwise omission
detection is circular.
Change log item 6 and §14 record the review. The standard stays proposed;
publication and the acceptance flip wait on the close of the circulation round.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ek3zTdfMa35bPVDjVUyhxx
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 868701@bnt-lap001
Assistant-Session: b2e101b6-f501-40dc-9ee5-438cac36e21a
verify-t06.sh reported success against a resolver that had been
unsaveable since creation and a reconciliation script that could never
complete a run. It asserted that objects existed rather than that the
property held.
A check that reports green while the system is broken is worse than no
check, because it is believed.
T01 rewrites it to prove a user resolves and MFA validates, and must be
demonstrated failing with the tuning fields cleared — not argued. T02
audits the sibling scripts for the same shape, output a table rather
than a rewrite. T03 labels 32 attended scripts with exercise status,
where "unknown" is permitted and more useful than a guess. T04 extracts
the one privacyIDEA request helper whose absence let a fixed defect be
reintroduced verbatim in the same directory.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3377672@bnt-lap001
Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166
The live-file pass missed these: archived ad-hocs carry a YYMMDD- filename
prefix, so the ADHOC-* glob did not match them. They still derive from the
forge, so they are live records rather than dead files.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
`ADHOC-YYYY-MM-DD` is unique per date but not per repository, so any two repos
opening an ad-hoc on the same day collide. The 2026-08-26 fleet projection
reset refused 9 records for exactly this reason.
Canon (work-record-types_v0.1, CUST-WP-0066) settled the form as
`{PREFIX}-WP-ADHOC-YYYY-MM-DD`, filename unchanged, and grandfathered existing
ids on the condition they are never *silently* re-derived. This is the explicit
migration that clause allows for.
The hub id is derived from the record id, so a changed id is a different
record: stale state_hub_*_id fields are dropped and fix-consistency re-derives.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
platform-root login is restored and the resolver holds the current bind
credential, so T04's outstanding reconciliation is done. No green receipt
yet — the run of record is a FAIL at resolver-lookup, and T05 stays open.
Records four things the session established:
- the predecessor is dead, observed twice by hand, but not by receipt;
- the value is unrecoverable, because no KeePassXC database has ever
existed despite platform-root-custody.md naming a safe entry, and the
only copy lived in a Firefox entry overwritten during the session.
T04 replaced the credential with no step to update operator custody —
the root cause of the whole session;
- the reconciliation script had never completed a run (4a38511);
- verify-t06.sh reported success at bootstrap against a resolver that
was misconfigured and a reconciliation path that could not execute.
That blind spot is open and is the finding worth acting on.
Also corrects the record: the stale bind credential was real but did not
cause the lookup failure. The HTTP 400 was our own request builder.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3377672@bnt-lap001
Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166
A missing newline fused the closing delimiter onto the last frontmatter value
(`- KONT-WP-0016---`), or fused a value onto the following key. Either way the
frontmatter never terminates and the whole body is swallowed.
Because workplan files are selected by `type: workplan`, such a file is not
invalid but invisible: it appears in no projection, raises no error, and is
reported as neither a workplan nor a problem. A forge-derived reset would
therefore read its correct hub record as no longer deriving and propose retiring
live work.
Only the missing newline is inserted; no value is altered.
Refs STATE-WP-0083-T08
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.
Records central already holds were deliberately left untouched.
Refs CUST-WP-0068-T06
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Answers zone-engine ZONE-WP-0001-T01.
Decision 5.6 — enforcement stance is a sibling standard, not an axis. The six
ladders are monotone and the whole current/target/guard machinery depends on it;
enforcement stance is not (ADR-0006 is the finding that the top rung is wrong for
the SSH lane). And this framework is descriptive: an accurately declared exempt
would be conformant and exempt. Membership is declared, stance belongs to the
control owner. Zone membership rides tenancy.yaml under a reserved zones: key so
the estate keeps one declaration surface; the schema permits it, unconstrained.
Decisions 8.4.1/8.4.2 — 'substrate location is not evidence' stated once instead
of three repo-local slogans, and the reef/P/V gap recorded as this document's
defect rather than zone-engine's scope. NK-WP-0027 takes it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
T02 done. Deployed user-engine digest c501aeb2 reads the projected flex-auth
token per decision (verified in the running container); flex-auth-user-engine
138aa347 serves with caller-auth enforce. Probes: valid 200
decision:d9aef25f08e17b84, missing token 401, wrong-system 403.
Closes manifest drift: runtime.yaml pinned e3b5f65b, the digest T01 warned
against, while the cluster ran c501aeb2. Re-applying it would have rolled the
portal back to an image that cannot authenticate to a PDP now in enforce.
kubectl diff is now empty.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
