coulomb/risk-nexus
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
risk-nexus/WORK-RECORDS.md

44 lines
3.4 KiB
Markdown
Raw Normal View History

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
# Work Records — risk-nexus
> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record
> stage 3). Do not edit by hand — edit the source file/block listed for
> each record and re-run fix-consistency to refresh this index. Archived
> workplans are omitted; closed decisions/intakes/engagements stay listed
> so recently-resolved work is still visible. [auto]
| Kind | ID | Status | Lane | Source |
| --- | --- | --- | --- | --- |
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
| workplan | RISK-WP-0001 | finished | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
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
| workplan | RISK-WP-0002 | active | — | workplans/RISK-WP-0002-publication-handover.md |
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
| workplan | RISK-WP-0003 | finished | — | workplans/RISK-WP-0003-regulatory-intake.md |
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
| workplan | RISK-WP-0004 | finished | — | workplans/RISK-WP-0004-run-the-register.md |
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
| workplan | RISK-WP-0005 | active | — | workplans/RISK-WP-0005-close-the-intent-gaps.md |
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
| task | RISK-WP-0001-T01 | done | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
| task | RISK-WP-0001-T02 | done | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
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
| task | RISK-WP-0001-T03 | done | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
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
| task | RISK-WP-0001-T04 | done | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
| task | RISK-WP-0001-T05 | done | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
| task | RISK-WP-0001-T06 | done | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
| task | RISK-WP-0001-T07 | done | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
| task | RISK-WP-0001-T08 | done | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
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
| task | RISK-WP-0002-T01 | progress | — | workplans/RISK-WP-0002-publication-handover.md |
| task | RISK-WP-0002-T02 | done | — | workplans/RISK-WP-0002-publication-handover.md |
| task | RISK-WP-0002-T03 | done | — | workplans/RISK-WP-0002-publication-handover.md |
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
| task | RISK-WP-0003-T01 | done | — | workplans/RISK-WP-0003-regulatory-intake.md |
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
| task | RISK-WP-0003-T02 | done | — | workplans/RISK-WP-0003-regulatory-intake.md |
| task | RISK-WP-0003-T03 | done | — | workplans/RISK-WP-0003-regulatory-intake.md |
| task | RISK-WP-0003-T04 | done | — | workplans/RISK-WP-0003-regulatory-intake.md |
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
| task | RISK-WP-0004-T01 | done | — | workplans/RISK-WP-0004-run-the-register.md |
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
| task | RISK-WP-0004-T02 | done | — | workplans/RISK-WP-0004-run-the-register.md |
| task | RISK-WP-0004-T03 | done | — | workplans/RISK-WP-0004-run-the-register.md |
| task | RISK-WP-0004-T04 | done | — | workplans/RISK-WP-0004-run-the-register.md |
| task | RISK-WP-0004-T05 | done | — | workplans/RISK-WP-0004-run-the-register.md |
| task | RISK-WP-0004-T06 | done | — | workplans/RISK-WP-0004-run-the-register.md |
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
| task | RISK-WP-0005-T01 | todo | — | workplans/RISK-WP-0005-close-the-intent-gaps.md |
| task | RISK-WP-0005-T02 | todo | — | workplans/RISK-WP-0005-close-the-intent-gaps.md |
| task | RISK-WP-0005-T03 | todo | — | workplans/RISK-WP-0005-close-the-intent-gaps.md |
| task | RISK-WP-0005-T04 | todo | — | workplans/RISK-WP-0005-close-the-intent-gaps.md |
| task | RISK-WP-0005-T05 | todo | — | workplans/RISK-WP-0005-close-the-intent-gaps.md |
| task | RISK-WP-0005-T06 | todo | — | workplans/RISK-WP-0005-close-the-intent-gaps.md |
| task | RISK-WP-0005-T07 | todo | — | workplans/RISK-WP-0005-close-the-intent-gaps.md |
Reference in a new issue Copy permalink