2026-08-10T0110Z-weekly

Verification & coverage notes

Outcome: duplicate-week stand-down. The primary weekly published 2026-W32 while this backup fire was mid-pipeline, and this run withdrew all fourteen of its composed strategic entries before commit.

Why the Phase 0 guard did not catch it. At preflight (01:10Z) the v3.31 two-part duplicate-week guard came back clean on both legs: no -weekly run record carrying week: 2026-W32 existed on origin/main, and git ls-remote --heads origin 'claude/*' returned no feature branches at all, so there was nothing for the branch sweep to inspect. The primary, 2026-08-09T2315Z-weekly, had in fact started at 23:15:39Z and completed at 00:06:31Z — before this fire began — but at 01:10Z its work was on neither main nor a visible remote branch. By the pre-verifier re-check at 02:05Z its record and sixteen strategic entries were on main. The guard behaved exactly as designed and still could not see it; what the branch sweep cannot cover is the interval between a primary completing locally and its push becoming visible. That is the third consecutive weekly cycle disrupted by this race, and it is now the only remaining gap in the guard rather than one of two.

The pre-verifier re-check is what saved the wasted time, and it is worth stating plainly what it saved. The stand-down was reached at 02:05:12Z, roughly 55 minutes in, immediately after check_run.py --pre-verify exited 0 and before the first verifier spawn. (Git puts the primary's commits on origin/main at 01:46:56Z and 01:48:49Z — after this run's 01:10Z preflight and before its 02:05Z re-check, which is what the two guard points bracket.) The completed timestamp in this record is the true end of the run and therefore postdates that decision; an earlier main.ended_at stamp taken at the end of the state phase was superseded rather than kept. The 2026-07-27 fire that motivated this check ran eight verifier iterations before discovering the same condition at Phase 6. This run spent nothing on verification and nothing on the publishing chain for withdrawn content.

What was withdrawn. Fourteen horizon: strategic entries had been composed and had passed the mechanical gate (38 pass · 0 fail): two top-stories, three multi-day, one vuln roll-up, one sector-patterns, one incidents-recap, two research, two long-running, one policy and one outlook. All fourteen files were deleted before commit. The registry addition they justified (actor:unc5537) was reverted, and the two state/cves_seen.json records this run added for them (CVE-2026-64638, CVE-2017-16740) were removed, so the dedup index does not record as covered anything that was never published. Source bookkeeping, the pwn-ai candidate addition and the state/source_health.json snapshot were kept: those reflect fetches that genuinely happened.

Residual coverage — six items the primary did not carry, now queued rather than narrated. This is the v3.31 rule that exists because the 2026-08-03 stand-down listed nine such items in prose and none was ever published. Each was checked against the primary's sixteen entries and its run record by keyword before being queued; each row carries its own verification state, and two of them are restorations of rows this run had prematurely struck:

• XSS2Shell / CVE-2026-64638 — a WordPress Core pre-authentication XSS-to-RCE chain patched same-day in 7.0.3. The primary weekly contains no WordPress coverage at all (zero hits for "WordPress", "XSS2Shell" or "64638" across its entries and record).
• wp2root — the wp2shell-to-kernel-root chain, restored to the backlog after being struck earlier in this run.
• FreeBSD CTL HA — three unauthenticated kernel-RCE primitives the project declined to fix; restored likewise. The primary's critical-infrastructure entry covers Zbtlink and CPDLC but not FreeBSD.
• CVE-2026-33824 root cause — 0patch's pre-authentication double free in ikeext.dll on UDP 500/4500, which closes an evidence gap on a CVE this store already records as exploited by a tracked campaign.
• Connor Moucka / UNC5537 guilty plea — law-enforcement closure on the 2024 cloud-tenant mass-extortion campaign, with the registry key drafted here and withdrawn with the stand-down.
• Forescout's water-sector controller census — 4,407 internet-facing Rockwell PLCs, 22 of them inside the attacked cities and 19 of those on firmware susceptible to a 2017 flaw, plus CISA's on-the-record refusal to attribute. The primary's water entry uses the FBI's naming of the controller family instead and carries none of these figures.

One further in-window item was assessed and deliberately not queued: Trail of Bits' AWS Nitro Enclaves / KMS trust-boundary research (2026-08-05). It is substantive primary research, but it is an architecture-audit checklist with no in-window urgency and no horizon shift, so it fails the inclusion gate on its merits rather than for want of space. Recording the decision here so a later fire does not have to re-derive it.

The backlog now carries 20 open rows: 16 already stood in the file before this fire (8 surfaced by the 2026-08-03 stand-down, 8 by the 2026-08-09 quality audit), of which this run touched only the two it had prematurely struck and then restored; the other 14 it left exactly as found. Four rows are new this run. Operator item, and the more serious one: not one of those 16 pre-existing rows has been struck by any intel fire between 2026-08-04 and 2026-08-09. The queue introduced in v3.31 to stop verified work being lost is itself not being worked, so the mechanism has moved the problem rather than solved it. On the file's own ~30-day rule the oldest rows begin expiring in early September.

Verification: two iterations, two models, early exit on a NEEDS_FIXES verdict with two residual findings, both remediated. Iteration 1 (Opus) read the record cold and returned five truth findings, one missed-angle and one advisory — every one of them a real defect in the record rather than in withdrawn content, which is what a stand-down's verification is for, since the record is the only thing that publishes. Iteration 2 (Sonnet, per the rotation) independently re-derived all seven remediations from ground truth and confirmed each landed without regression, then found two further defects on a cold pass: the iteration-1 ledger itemised eight findings against a verdict summing to seven, because the main agent had split one of the verifier's findings and assigned its own F-codes; and W2's sources_attempted carried two ids that do not exist in the source registry. Both were fixed, along with one advisory clarity nit in a backlog row. The run publishes on the low-residual early exit rather than a confirmed CLEAN: the final verdict is NEEDS_FIXES with a residual count of 2, which is iteration 2's truth+editorial total, and both of those findings were remediated after it reported. What is NOT established is an independent verifier read of the final state — a third iteration would have cost another ten minutes against a record whose remaining defects were an arithmetic mismatch and two bad identifiers, neither of which changes what the operator is told.

Research telemetry is retained in full because the work was real. W1 and W2 both returned inside their caps with 14 and 3 items; their findings files, the URL-liveness ledger, the Phase 4 deep-read bodies and the quote-verification results are committed under work/2026-08-10T0110Z-weekly/ as the forensic surface. Of note for future fires: 24 candidate quotes were literal-substring-checked against locally saved primaries before composition and all 24 passed, and one planned ATT&CK mapping (T1562.001) was caught as revoked in the pinned v19.2 dataset and corrected to T1685 before it could reach an entry.

Two reported fetch failures were not failures. W1 logged sygnia as a WebFetch 403 without escalating, and prodaft as a stale listing. The mechanical gate flagged that neither had been tried through the bridge, and a Phase 5 check found both retrieve cleanly via tools/fetch_source.py url (173 KB and 271 KB). Neither belongs in fetch_failures[], which is reserved for genuinely unrecovered failures, so both records were removed rather than left overstating the source list's ill health. For prodaft the residual question is publication cadence or the listing path W1 chose (/reports rather than /resources), not a broken transport.

Source health. python3 tools/source_health.py probed 179/179 sources in 110 s: 100 ok, 77 bridge-ok, 1 jina-ok, 1 client-error, and zero sources flagged for action — no needs-bridge or needs-demote, so there is no standing repair order from this run. The newly added pwn-ai candidate probed HTTP 200 on its first sweep.

Coverage gaps: sygnia, prodaft (transport healthy, no in-window content pulled); paradigm-shift-research (publisher serving a placeholder page, third consecutive run); ibm-xforce, socket-dev-blog (JS-rendered shells, structured recipes not attempted); technadu, sans-newsbites (not attempted — W1 allocated time to higher-yield primaries); bsi-de, edpb, us-treasury-ofac, ncsc-ch-focus, cert-eu (reachable, nothing published in-window). FINMA, EUR-Lex and the European Commission have no records in sources/sources.json and are therefore absent from W2's sources_attempted list, which carries registry ids only; they were swept by targeted search plus a direct fetch of the specific publication page, and none carried an in-window cyber-relevant item. W2 did verify the amended AI Act Article 113 timetable verbatim from EUR-Lex while there.

Watchlist: products checked=0, hits=0; suppliers checked=0, hits=0 — the organization profile configures no product and no supplier watchlist, so both sweeps are no-ops.

ATT&CK pin. python3 tools/attack_data.py --check: up to date — local v19.2 equals upstream latest v19.2. No update required this week.

Operator items. (1) The duplicate-week guard's remaining blind spot is the window between a primary completing and its push becoming visible on origin; a completed-primary signal that does not depend on git visibility is the only thing that would close it. (2) state/coverage_backlog.md is not being worked down by the intel runs that own it — this is now the second consecutive week in which a stand-down has added rows nobody has consumed. (3) paradigm-shift-research has produced no usable content for three consecutive runs and its publisher serves a placeholder page; its candidate status should be re-evaluated. (4) prodaft has now gone four consecutive rotation periods without yielding in-window content while returning HTTP 200 from a transport this run proved healthy (its consecutive_quiet_periods reached 4; its failure counter remains 0). That points at publication cadence rather than reachability.