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>

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

@@ -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.

findings/RISK-F-0005-audit-core-unfiltered-read-path.md

@@ -2,7 +2,7 @@
 id: RISK-F-0005
 type: finding
 title: "audit-core read path applies no tenant filter; the bound is deployment, not code"
-status: open
+status: mitigated
 reported_by: audit-core
 reported_via: flex-auth
 routed_by: risk-nexus
@@ -20,15 +20,16 @@ impact: I3
 likelihood: L2
 fidelity_modifier: false
 production_rescore: true
-disclosure: embargoed
-embargo_condition: "AUDIT-WP-0008-T04 lands a tenant filter in the read path"
+disclosure: public
+publication: pending-handover
+embargo_condition: "met 2026-08-18 — AUDIT-WP-0008-T04 reads done in audit-core's workplan"
 embargo_since: "2026-08-19"
 embargo_review: "2026-11-17"
 escalation: none
-last_checked: "2026-08-20T10:02:42Z"
-next_check: "2026-08-20T11:02:42Z"
-cadence: 1h
-clean_streak: 1
+last_checked: "2026-08-21T06:29:38Z"
+next_check: "2026-08-21T06:29:38Z"
+cadence: instant
+clean_streak: 0
 waiting_on:
   - who: audit-core
     what: "is may_read false on every production credential, or only on the sender"
@@ -85,3 +86,40 @@ No escalation. Known, owned, tracked, moving.
   Open at review: has `AUDIT-WP-0008-T04` moved; is `may_read: false` still
   true of every production credential, not only the sender.
 - **2026-08-20** — clean check: checked against the inbox and the owner's record; nothing moved. Cadence instant → 1h (1 clean in a row); next check 2026-08-20 11:02Z.
+
+## Check — 2026-08-21: the fix landed three days ago and nobody here knew
+
+`RISK-WP-0005-T01`'s first run read `AUDIT-WP-0008-T04` in `audit-core`'s own
+workplan file: **`status: done`**, last changed 2026-08-18.
+
+The task text is the fix this finding asked for — bind the read path to
+permitted tenants, `permits_tenant` governing read as it governs write at the
+same choke point, tenant-scoping `/v1/events`, `/v1/events/<id>`,
+`/v1/dead-letters` and `/v1/secret-findings`, with tests for cross-tenant read
+refusal.
+
+**Three days sat between the fix landing and this register knowing.** Nothing
+was wrong with `audit-core`'s conduct — they did the work and recorded it in
+the authoritative place. The register was carrying a string it never read,
+which is exactly the gap `RISK-WP-0005-T01` exists to close, found on the run
+that closed it.
+
+**`mitigated`, not `fixed`.** The live gap is closed on the owner's record; the
+finding is not, for two reasons:
+
+1. This register has read a workplan status, not a probe. The standard for
+   `fixed` in `docs/method/review.md` is something concrete about the running
+   system, and `audit-core` is the one who can supply it.
+2. `AUDIT-WP-0008-T05` — the adversarial `E2` evidence artifact, an identity
+   bound to tenant A demonstrably unable to read tenant B — reads `wait`. The
+   control exists; the demonstration that it holds does not.
+
+**The embargo lifts.** Its condition was `AUDIT-WP-0008-T04` landing a tenant
+filter, and that is met. The finding describes a read path that no longer
+applies no filter, so publishing it no longer shortens anyone's path.
+`disclosure: public`, handover pending with the others.
+
+The `may_read` question — is it false on every production credential, or only
+on the sender — stays open and matters less now that the bound is in code
+rather than in a flag.
+- **2026-08-21** — not clean: AUDIT-WP-0008-T04 reads done in audit-core's workplan since 2026-08-18; embargo condition met, status mitigated. Cadence 1h → instant; checked again immediately.