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

RISK-WP-0005-T01: read the fix records, and two findings moved

Browse source 
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>
This commit is contained in:
tegwick 2026-08-21 08:29:38 +02:00
parent 0ff87c22d8
commit ba3b3f686d
7 changed files with 217 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

54
findings/RISK-F-0002-ops-warden-sign-ungated.md
View file

@ -29,8 +29,8 @@ embargo_review: "2026-11-17"
escalation: withdrawn
escalation_trigger: 6
escalation_status: withdrawn-hazard-window-closed
last_checked: "2026-08-20T10:02:41Z"
next_check: "2026-08-20T10:02:41Z"
last_checked: "2026-08-21T06:29:10Z"
next_check: "2026-08-21T06:29:10Z"
cadence: instant
clean_streak: 0
waiting_on:
@ -274,3 +274,53 @@ reason than the one this finding was filed for. That is the second time in two
days that this finding's blocker turned out to be a claim about the world at a
date.
- **2026-08-20** — not clean: RISK-V-0001 found the flex-auth-ops-warden policy admits no ingress; the live question is now availability, not attestation. Cadence instant → instant; checked again immediately.
## Check — 2026-08-21: both tracked records were already closed when this was filed
`RISK-WP-0005-T01` made this register read the fix records it had been writing
down without reading. The first run answered a question nobody had asked:
| Tracked | State | Last changed |
| --- | --- | --- |
| `WARDEN-WP-0007` | **archived** | 2026-07-08 |
| `FLEX-WP-0007` | **finished** | 2026-06-29 |
This finding was filed on **2026-08-18** and states that the gate is "blocked
on `FLEX-WP-0007`". That workplan had read `finished` for seven weeks by then.
`flex-auth` restated the same blocker to this register on 2026-08-19 —
"`policy.enabled` remains off (`FLEX-WP-0007`)" — while their own authoritative
record said it was done.
**The register is not concluding that the blocker is gone.** Three readings
fit and only the owners can say which: the deployment finished and was later
reverted or never applied; "finished" means something narrower than the
sentence implies; or the blocker is genuinely stale and two repos have been
repeating it.
What can be said without either owner's help is that **the stated blocker has
not matched the stated record since June**, and nothing would have caught that
before this register started reading fix state.
### This is the third time on the same finding
`RISK-F-0002` argued, when it was filed, that a blocker is a claim about the
world at a date, and that its own had been invalidated in a day with nothing
re-checking it. Since then:
1. `RISK-F-0001` was fixed hours after this register graded the ordering hazard;
2. `RISK-V-0001` found a NetworkPolicy that may make enabling the gate fail
closed for an entirely different reason;
3. and now both tracked records turn out to have been closed before the finding
was written.
The finding was right about the estate and right about itself. Severity is
unchanged at `medium` — none of this changes what the gate does today — but
what is *blocking* it has been wrong in the record for two months.
### The ask, sharpened
Previously: probe whether the flex-auth pin admits ingress. Now, additionally:
**what actually blocks `policy.enabled` today?** If the answer is "nothing
except the ingress question", that is a much shorter path than the one both
repos have been describing.
- **2026-08-21** — not clean: Fix tracking read for the first time: WARDEN-WP-0007 archived 2026-07-08, FLEX-WP-0007 finished 2026-06-29 — both closed before the finding was filed. Cadence instant → instant; checked again immediately.