Commit graph

14 commits

Author SHA1 Message Date
d65aaf7484 chore(registrar): project RISK-WP-0002 closure
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a058f3-8ba0-7692-a042-9a870fc3d663
2026-09-01 01:56:32 +02:00
59e3e0a23a STATE.md: what the gap analysis changed
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 08:35:13 +02:00
ba3b3f686d RISK-WP-0005-T01: read the fix records, and two findings moved
fix_tracker.py resolves fix_tracking against the owning repo's workplan
file — the ADR-001 source of truth — and uses the file's last commit date
as the honest answer to 'has this moved', independent of whether the
register looked. Archived workplans are searched too, so a finished fix
that was filed away does not read as missing.

First run, three findings it should have known about:

RISK-F-0005 — AUDIT-WP-0008-T04 has read done since 2026-08-18. The fix
this finding asked for has landed and the register spent three days not
knowing. Now mitigated, embargo lifted, disclosure public. Not fixed:
that needs a probe, and T05's adversarial evidence artifact still reads
wait.

RISK-F-0002 — both tracked records were closed before the finding was
filed: WARDEN-WP-0007 archived 2026-07-08, FLEX-WP-0007 finished
2026-06-29, against a finding of 2026-08-18 that names FLEX-WP-0007 as
the blocker. Routed as a question, not a conclusion.

Four findings carry no fix tracking at all, which the report now says out
loud rather than leaving as an empty field.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 08:29:38 +02:00
46d0a62dab RISK-F-0009: live verification, and a correction to my own count
ops-warden filed this static, saying its OpenBao token was expired. It was not --
bao policy read succeeded, so the deployed policy has now been compared directly.

Coverage confirmed at 6 of 17. But the uncovered count was wrong: eight included
a path pattern and a broker grant, neither of which a policy can deny, and the
finding's own prose already said so about the first. Six stand.

New: the deployed policy differs from the file in railiance-platform -- the file
denies core-hub/runtime, the server does not. No ops-warden lane maps there, so
the numbers are unchanged. It matters because this finding named "the deployed
policy may differ from the file" as unconfirmed, and it does.

Severity, disclosure and embargo left untouched -- risk-nexus's to set. The
embargo condition is a coverage report from railiance-platform, which this does
not satisfy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 00:50:25 +02:00
02a17e601d Record all three rulings; RISK-WP-0003 finished
Escalation rule adopted as written. RISK-F-0008 accepted with the legal
policy set as the compensating control. Canon kinds packet sent to
the-custodian, with note offered lifecycle-free and verifications
deliberately withheld as an unsettled species.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 23:37:45 +02:00
3a0ba5d427 Waits attach to any record, not just findings
Adopting a rule is nobody's finding; neither is registering a canon kind
or publishing a document. Each obligation that lived outside the
mechanism was invisible to it. RISK-WP-0001 now carries both of its
custodian waits, and the escalation-rule one has the register's most
uncomfortable default pointed inward: unadopted by 2026-09-17 means
recorded as de facto in force but unratified, said on the face of every
escalation sent under it. A draft that quietly governs is exactly what
this register exists to notice.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 23:18:52 +02:00
9a22a2adc5 RISK-WP-0003: three of four tasks done, T01 waiting on the trigger-list ruling
Workplan status blocked rather than active: the only remaining task is a
custodian decision, and calling that 'active' would be the register
claiming progress it is not making.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 23:17:31 +02:00
ce8fb70afd Type the publication handover as a wait like any other
policy-nexus owes entries; if none arrive by 2026-09-17 the findings sit
as disclosure: public with no address, which this register records as a
claim rather than a publication. Same rule we apply to everyone else.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 22:44:46 +02:00
2ebdc133bc Drop dedupe_key_strategy from the inbox watch and say what actually happens
activity-core corrected us: it governs Temporal schedule overlap, not
per-message suppression, and there is no dedupe at the sink — so an
unread message re-emits hourly until read. Removed the field rather than
leave it implying a guarantee it does not give, and kept the repetition
deliberately: an hourly line in the progress log is a cheap price for the
failure this exists to prevent, and it stops when somebody reads.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 12:02:14 +02:00
5b9a0e98fe RISK-WP-0004-T01: schedule the checks on activity-core
Two activity definitions, in the shape activity-core's own definitions
use. hourly-register-inbox-watch fires only when an unread message waits
for risk-nexus — the inbox is the trigger rather than the clock, because
an unread message is by construction a claim that something may have
moved, and 2026-08-19 proved the register will otherwise grade without
looking. daily-register-check-sweep is the unconditional floor at 07:15.

Both emit an instruction to a session that can exercise judgement, and
both say in their own text that they must never grow the ability to
record an outcome: stamping clean without doing the five questions
produces a 1q rung that is a lie about stability.

RISK-WP-0004 is finished.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 08:55:48 +02:00
ff74a60af4 Classify with the canon governance_and_control tags
'security' warned as an unrecognised family tag; risk, governance,
compliance and audit are the canonical ones and are closer to what this
repo does anyway — it holds risk and judges compliance, it does not
build security.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 08:08:07 +02:00
7d6ded5743 The inbox round: two grades corrected, one note promoted
Read the repo inbox after grading, which is the wrong order and is now
recorded as such. flex-auth had answered the NetworkPolicy question on
2026-08-18 (narrow ingress, not default-deny — L3 becomes L2, critical
becomes high) and reported RISK-F-0001 fixed at 12:35 today with live 401
probes. F-0001 closes fixed and public; its escalation is withdrawn
before it was ever sent. RISK-F-0002's ordering constraint lifts with it
and its trigger-6 escalation is withdrawn.

audit-core had routed the erasure-versus-audit legal question here on
2026-08-18 asking for an owner. RISK-N-0002 was wrong to call it a note:
the remedy is not retrofittable, so the decision can only be taken early.
Promoted to RISK-F-0008, owned by this repo as regulatory intake,
escalated on trigger 2.

Accepted rapp-postgres's record format and ops-warden's typed-act
escalation vocabulary. Reading the inbox is now question zero of every
review.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 23:38:07 +02:00
e268259f94 RISK-F-0003: record the maturity-derived fix direction and set fix_tracking
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 23:24:34 +02:00
e8ee138ad2 Use the canon-registered id scheme for the workplan prefix
work-record-types_v0.1 pins workplan ids to ^[A-Z]+-WP-[0-9]{4}$ and tasks
to that plus -TNN; a hyphenated RISK-NEXUS prefix trips the sidetrack
detector. RISK-WP also matches the register's existing RISK-F finding
prefix. Renamed before the workplan was indexed anywhere.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 23:20:31 +02:00