Week 31
The strategic arc across the week's operational findings · what to fix if you act only once, the multi-day chains, and the policy horizon.
About this weekly1 run
2026-07-27T0110Z-weekly · weekly · Claude Opus 5 · 0 entries published
Weekly strategic run — 2026-W30 — DUPLICATE-WEEK (backup fire, overtaken by the primary mid-flight)
Outcome: duplicate-week — no entries published
This backup weekly fire is a duplicate-week no-op: the primary weekly for 2026-W30 landed on origin/main while this fire was mid-pipeline, so all strategic content this fire composed was withdrawn before publish to honour the one-weekly-per-ISO-week / no-duplicate-coverage invariant. The mandatory artifact of the fire — this run record — is published; zero entries are.
The race, precisely. At this fire's Phase 0 (2026-07-27T01:09Z) the backup-invocation guard and the weekly Phase 0 duplicate-week guard both ran git grep "^week: 2026-W30$" origin/main -- runs/ against origin/main at 537d453 and found no match — no -weekly record covered W30 — so the fire correctly proceeded to execute prompts/weekly-summary.md in full. Unknown to it, the primary weekly 2026-07-26T2309Z-weekly had fired at 2026-07-26T23:09Z; its commits (c59bdbc run + d55b237 publish-status amendment) propagated onto origin/main only after this fire's Phase 0 check. This fire discovered the overtaking run at Phase 6, when the pre-push sync (git fetch origin main) advanced 537d453 → d55b237 and surfaced runs/2026-07-26/2026-07-26T2309Z-weekly.md carrying week: 2026-W30, entries_published: 11, publish_status: ok. Per the anti-crash overtaken-run rule (prompts/cti-run.md guard #10) and the duplicate-week invariant, the correct action once the primary has published the week is to withdraw the overtaken duplicate rather than publish a second W30 weekly.
What this fire did before standing down (preserved under work/2026-07-27T0110Z-weekly/ for forensic review). It ran the full weekly pipeline: Phase 0 preflight (prior-coverage index over 14 days, ATT&CK pin check — up to date v19.1); Phase 1 week-in-review over the 46 W30 operational entries (seven working lists → week-review.json); Phase 2 horizon research (W1 returned 5 items, W2 returned 2 — findings YAMLs preserved); Phase 3 triage (triage.json); Phase 4 composed 9 strategic entries (2 top-stories, vuln-rollup, sector-patterns, multi-day, 2 research, policy, looking-ahead); Phase 5.5 mechanical gate to exit 0; and the full Phase 5.7 verification loop to the 8-iteration cap (Opus/Sonnet rotation; truth-defect counts 9 → 2 → 1 → 3 → CLEAN → refuted(1) → CLEAN → refuted(1); every finding a truth/attribution defect, all remediated, no drops). The eight per-iteration verification reports and findings YAMLs, the W1/W2 findings, the week-review.json working lists and triage.json are all preserved under work/2026-07-27T0110Z-weekly/ for forensic review — they fully document the withdrawn entries' content and the verification history. The 9 composed entry files themselves were withdrawn at Phase 6 and never committed to entries/; the primary weekly's 11 W30 entries are the published record for the week.
Overlap with the primary confirms the withdrawal is correct, not a coverage loss. The primary's 11 W30 strategic entries (entries/2026-07-26/weekly-w30-*) cover the same week-defining signal this fire independently reached: AI as autonomous operator and target; state-nexus self-hosted-webmail espionage; the exploited/KEV vulnerability roll-up; CH/EU public-sector third-party-mediated incidents; trusted-infrastructure C2; the npm/AI-toolchain supply-chain and Joomla-extension status; EU procurement-assurance policy (plus a BaFin/TeamViewer disclosure-precedent item); and a looking-ahead. A reader is fully served by the primary; publishing this fire's near-identical 9 would have duplicated W30 coverage.
The one additive change kept. actor:sandworm gains the alias SANDWORM RELIC (Google GTIG's unified two-word cryptonym, 2026-07-24, surfaced by W1). The primary weekly did not record it; it is registry hygiene, not weekly coverage, so it is committed here where it is correct and non-duplicative. The only sources.json change is factual fetch telemetry — last_successful_fetch bumped to 2026-07-27 for the 15 sources W1/W2 successfully fetched today; no lifecycle transition or new candidate is carried (the primary's source-lifecycle pass stands), and there is no cves_seen.json change. source_health.json is left as the primary left it.
Operator note
Two weekly fires ran for 2026-W30 — the scheduled primary (2026-07-26T23:09Z) and this backup (2026-07-27T01:10Z) — because the backup's Phase 0 check preceded the primary's record reaching origin/main. The primary succeeded and is live; the backup detected it at push time and stood down with zero duplicate entries. No action required. If the double-fire is undesirable, the backup schedule can be shifted later relative to the primary so the primary's record has reliably propagated before the backup's Phase 0 guard runs.