Problem
A run_mode=restore of a past week (intended only to refresh content/data and the taxonomy on publish) also regenerates that week's weekly article and republishes it. The sync-publish-to-main.yml job then wipes and re-syncs content/weekly/ from publish to main, so the regenerated article overwrites the original published post.
Because the weekly analysis is LLM-generated and non-deterministic, the regenerated article differs from the original. Observed in the 2026-W31 restore:
- The W31 article "Agent Work Moved Into the Operating Room" (topic "AI Agents in Healthcare") was replaced by "Agent Workbenches Met the Trust Gap" (2 topics).
topics: frontmatter on W21–W30 was stripped in the same sync.
This broke test_weekly_topic_backfill, test_rendered_weekly_links, and test_topic_hubs, and changed live content. Remediated reactively in #638 by restoring the original weekly articles.
Root cause
crawl-and-publish.yml in restore mode regenerates the full weekly transaction (article + observatory data) from stored raw evidence.sync-publish-to-main.yml treats publish as canonical and wipes+resyncs content/weekly/, content/monthly/, content/yearly/ to main.
So restoring a week to refresh data has the side effect of republishing a different article.
Proposed options
- A — Data-only restore mode: add a restore variant (or flag) that regenerates only observatory surfaces (
content/data, data/taxonomy, content/repo, datasets, tools) and skips weekly article generation/promotion.
- B — Preserve existing published article: in restore mode, if a promoted weekly article already exists for the week, keep it (do not overwrite with a new regeneration).
- C — Guard the sync: make
sync-publish-to-main.yml skip content/weekly/<week> when the only change is a same-week article rewrite from a restore.
Option A or B is preferred — a restore meant to refresh data should never rewrite an already-published weekly post.
Acceptance
References
Problem
A
run_mode=restoreof a past week (intended only to refreshcontent/dataand the taxonomy onpublish) also regenerates that week's weekly article and republishes it. Thesync-publish-to-main.ymljob then wipes and re-syncscontent/weekly/frompublishtomain, so the regenerated article overwrites the original published post.Because the weekly analysis is LLM-generated and non-deterministic, the regenerated article differs from the original. Observed in the 2026-W31 restore:
topics:frontmatter on W21–W30 was stripped in the same sync.This broke
test_weekly_topic_backfill,test_rendered_weekly_links, andtest_topic_hubs, and changed live content. Remediated reactively in #638 by restoring the original weekly articles.Root cause
crawl-and-publish.ymlin restore mode regenerates the full weekly transaction (article + observatory data) from stored raw evidence.sync-publish-to-main.ymltreatspublishas canonical and wipes+resyncscontent/weekly/,content/monthly/,content/yearly/tomain.So restoring a week to refresh data has the side effect of republishing a different article.
Proposed options
content/data,data/taxonomy,content/repo, datasets, tools) and skips weekly article generation/promotion.sync-publish-to-main.ymlskipcontent/weekly/<week>when the only change is a same-week article rewrite from a restore.Option A or B is preferred — a restore meant to refresh data should never rewrite an already-published weekly post.
Acceptance
content/datadoes not change any already-publishedcontent/weekly/*article.References
.github/workflows/sync-publish-to-main.yml.github/workflows/crawl-and-publish.yml(run_mode=restore)