2026-08-17T0110Z-weekly

Verification & coverage notes

Outcome: stand-down. This fire published no entries because the primary weekly for 2026-W33 had already published the week. The primary run 2026-08-16T2315Z-weekly started at 23:15 on 16 August and published 15 strategic entries with 4 updates. This run's output was withdrawn before commit; the run record is the only artefact it publishes, which is the correct outcome for a duplicate-week stand-down rather than a failure. The twelve withdrawn drafts are listed with their sections and their disposition against the primary's coverage in work/2026-08-17T0110Z-weekly/withdrawn-entries.md, so the comparison below is auditable rather than assertion.

Why the stand-down came late, and what that cost. The preflight guard was correct when it ran, but not for the reason first written here — the corrected account follows, because the original one blamed a mechanism the artefacts contradict.

At 01:10 origin/main stood at b77d651, which does not contain the primary's record, and a sweep of every remote claude/** branch found nothing. Both surfaces were genuinely clean, and the reason is simply that the primary was still running: its own verification loop was mid-flight at that moment, its iterations continuing until 01:44:10, and its first commit cf7e13d is timestamped 01:46:29 with the publish-status amendment 9edfd66 at 01:48:19. Nothing of the primary had been pushed at 01:10, so there was no feature branch to find and none had been deleted. Propagation from that first commit to main was a matter of minutes, and the pre-verifier guard caught it — the second of the two mandated guard points doing exactly its job. The promotion therefore landed during this run's composition phase, not its research phase, which ended at 01:31:15.

The cost was about 45 minutes of research and composition: two research sub-agents, ten primary sources deep-read, and twelve composed strategic entries discarded. No verifier iterations were spent on withdrawn content.

This is the fourth consecutive weekly cycle in which the backup fire has done substantial work before discovering the primary had the week — 2026-W30, W31, W32 and now W33 all ended in a duplicate-week stand-down. The two earliest had guard defects the prompt has since fixed. The last two did not: W32 ran under the same prompt version as this fire, its guard came back clean on both legs exactly as this one did, and no guard change landed between them.

The one thing that holds across both weeks is the push time, and it is what the schedule has to clear. In each of the last two cycles the primary's first commit landed at almost exactly the same moment — 01:46:56Z for the W32 primary, 01:46:29Z for the W33 primary — while the backup starts at 01:10. The backup therefore begins roughly thirty-six minutes before the primary's work becomes visible on any remote surface, every time, and no guard placed before that point can see anything.

What the primary was doing during that interval differs between the two weeks, and the earlier stand-down's diagnosis should not be generalised. The W32 primary had finished its verification loop at 01:05:25Z, two iterations in, before that week's backup began — so for W32 the gap really was between a finished run and a visible push. The W33 primary was still verifying: its seven iterations ran to 01:44:10Z, and it committed two minutes later. Same outcome, different mechanism.

What is common, and is worth recording because it misled the reading of both, is that the primary's completed field is far earlier than the end of its work: completed: 00:06:31Z against a 01:46:56Z commit for W32, and completed: 00:07:59Z against a 01:46:29Z commit for W33 — about an hour and forty minutes adrift on both occasions. The field appears to be stamped when the state phase finishes and not revised afterwards. Anything that reads it, including the next fire's state digest, gets a completion time substantially earlier than the run's real end. That is a data-quality problem rather than the cause of this stand-down: the duplicate-week guard never consults that field, so correcting it would not by itself have prevented anything. The single change that would prevent a fifth occurrence is the schedule — moving the backup clear of the primary's actual push time rather than the completion its record advertises.

Residual research: three items preserved to the coverage backlog. A stand-down's verified-but-unpublished research is the thing most likely to be lost, because the next intel run's window is roughly a day and the next weekly's is the following ISO week. Comparing this run's twelve composed entries against the primary's fifteen, most were covered — in several cases better, and the primary additionally carried material this run did not find at all, including the Cyber Resilience Act standards approval, two Q2 ransomware reports, and a Russia/Ukraine defence-supply-chain assessment. Three findings were not carried by the primary and are now queued in state/coverage_backlog.md:

• CRPx0, an emerging ransomware-as-a-service operation marketing white-label campaigns on a 100% profit-sharing model behind a subscription fee, alongside a separate hacking-as-a-service arm, with a June-to-July victim jump its own analyst declines to attribute to either genuine growth or affiliate-recruitment scam behaviour. Absent from the entry store and from the entity registry entirely — the only fully unpublished item of the three.
• The OT edge authentication pattern. Both component vulnerabilities are published and appear in the primary's roll-up, but nothing carries the cross-cutting finding: on the OT edge the recurring defect is an absent authentication decision rather than a memory-safety bug, which means network placement rather than firmware version is the primary control, and the campaign causing actual operational impact in that sector carries no identifier at all.
• Browser and operating-system trust-bridge failures as a named class. The three component disclosures are published; what no entry carries is the class itself — that a component mediating between a lower-privilege caller and a higher-privilege local action fails by not re-verifying the caller at the point privilege changes hands. The native-messaging inventory step this run had claimed as new is not new: the Jewelbug entry of 2026-08-16 already tells readers to inventory native-messaging host registrations across the managed browser estate and gives three discriminators for spotting an illegitimate one. The residual value is therefore the generalisation across component types, not that action, and the backlog row was corrected to say so — it is the weakest of the three rows on that basis.

Each row records honestly whether it is a genuinely unpublished item or a framing over already-published components, so a future fire can publish or strike it cheaply.

State changes retained despite the stand-down. The entity-registry additions this run had staged were reverted, because the entries that justified them were withdrawn and orphan records help nobody; the backlog rows name the keys to register when the items are published. Source-list bookkeeping was kept where it records something that actually happened and is not already on main: eight sources were fetched successfully and had their fetch dates advanced, five of which additionally carried a non-zero quiet-period counter that this reset; no failure counter moved on any of them, and one new candidate was added. The source file was reconciled against origin/main rather than against this run's stale base, which removed one redundant edit — fortinet-fortiguard-blog was listed as promotion-due in this run's state digest and the promotion was applied, but the primary weekly had already promoted it, so this run's duplicate edit and second promotion note were dropped instead of being layered on top.

Findings verified but not published, recorded here for the audit trail. Five candidate quotes returned by the horizon research fail a literal-substring check against the page each cites, and the four that reached a draft entry were corrected against the page text before composition: one had dropped the backticks around a command name; one had been re-capitalised after losing its opening clause; one had dropped an article and a noun; and one differed only by lower-casing its opening word. The fifth spliced two non-adjacent passages into a single quotation with an inserted ellipsis — each half verbatim on its own, the join not — and was replaced in drafting by the shorter contiguous passage rather than corrected in place. A more substantive correction: the research reported the Dutch NIS2 transposition as carrying a 24-hour initial notification duty, and reading the government announcement directly established that the 24-hour clock belongs to the companion critical-entities law, while the NIS2 transposition requires reporting within statutory deadlines whose thresholds are set per sector in ministerial regulations. Administrative-fine figures that appeared in the research summary were not on the cited page and were dropped. None of this reached a published entry, but it is the kind of defect the deep-read step exists to catch and is worth recording.

Scheduler gap inside the covered week. There is no intel run for 2026-08-14 — no runs/2026-08-14/ directory and no entry carrying that discovery date. The 2026-08-15 fire's window absorbed the gap and no resulting coverage hole was identified while building the week's working lists, but the missed fire is an operational fact for the operator.

Coverage gaps. cisa-directives is unrecovered and recorded in fetch_failures: the host returns HTTP 403 to the routine transport and the reader proxy returned HTTP 402 across all seven pooled credentials. enisa and ncsc-uk were not fetched this run. Three ad-hoc corroboration attempts outside the curated source list returned 403 or a Cloudflare challenge.

Reader-credit pool exhausted. The jina reader returned HTTP 402 across the whole key pool, consistent with the state digest's record of a 402 on the previous fire. Every deep read this run therefore used direct transports, which succeeded on all ten primaries attempted. This is a standing operator item: the pool needs topping up before a fire meets a host only the reader can reach.

ATT&CK pin. attack_data.py --check reports the local pin at v19.2, up to date against the upstream release. No update was required this week.