process-watch-report

name	process-watch-report
description	Compare state/watch/* (what the daily watcher discovered) against state/ingest/* (what each downstream skill last ingested) and invoke every skill whose mapped sources have changed since its last successful run. Use when the user says "process today's watch report", "sync data based on the watcher", "refresh everything that changed", "run the right skills for what changed", or otherwise asks to act on what the daily watcher found. Robust to multi-day gaps between orchestrator runs — never misses an intermediate-day change.
allowed-tools	["Read","Bash","Skill"]

Process watch report (orchestrator skill)

The daily watcher in scripts/watch/ writes per-source state to state/watch/<source>.json (with a lastChanged ISO timestamp) and also produces a human-readable daily report under data-reports/. This orchestrator decides what to ingest by comparing watcher state against per-skill ingest markers under state/ingest/<skill>.json (with a lastSuccessfulIngest timestamp).

Why state-driven, not report-driven? The watcher's ## Changed section in any one report is relative to the previous watcher run, not the last successful ingest. If a source changed on Monday but the orchestrator wasn't run until Wednesday, Wednesday's report only lists Wednesday's changes — Monday's would be silently missed. State files are the durable truth: state/watch/<source>.json.lastChanged is "when did this source last actually move?" and state/ingest/<skill>.json.lastSuccessfulIngest is "when did we last ingest that move?". The comparison is invariant under any number of skipped days.

The human-readable reports under data-reports/ are still useful for narration in the final summary — but they're no longer the decision input.

Inputs

• state/watch/<source>.json for each watcher source — the truth about what's changed when. Always exists once the watcher has run at least once.
• state/ingest/<skill>.json for each tier-2 skill that has run successfully under this orchestrator. May be missing on first run after the state-driven migration — see "Bootstrap" below.
• data-reports/<YYYY-MM-DD>.md reports — read for narration in the final summary, not for decision-making.

Source → skill mapping

The "Changed" section of the report contains a bulleted list. Each bullet's label maps to a downstream skill:

Source label in the report (label prefix is enough)	Skill to invoke
Parliament roll-call votes	update-rollcall
Parliament MPs (active roster)	parliament-scrape (Step 5 — also re-runs the local-elections MP-link decorator via npx tsx scripts/parsers_local/decorate_local_mp_links.ts so any newly-seated MPs' photos surface on the local-election mayor / council rows they ran on; Step 6 — also re-runs npx tsx scripts/preferences/rebuild_resolved.ts so the precomputed /candidate/* resolution shards re-match against the refreshed index, then bucket:sync since those shards are gitignored)
BG Wikipedia polls	update-polls
BG Wikipedia governments list	manual edit required — see "Governments: manual edit first" below
Сметна палата declarations registry	update-connections
Сметна палата declarations — executive (officials)	update-officials (also re-runs update-funds political-economy join step — npx tsx scripts/funds/political_links.ts — since the officials → company links are an input)
Сметна палата declarations — municipal (mayors & councillors)	update-officials (Step 1b — municipal ingest; same political-economy follow-up applies)
data.egov.bg Commerce Registry	tr-daily-refresh (npm run tr:daily-refresh)
EC Financial Transparency System	db:load:ngo-funding:pg (npm run db:load:ngo-funding:pg — new FTS year: download {YEAR}_FTS_dataset_en.xlsx into raw_data/ngo_funding/fts/, then load into the ngo_funding table; DB-only, no JSON)
data.egov.bg АОП (procurement)	update-procurement (also re-runs the funds political-economy join — npx tsx scripts/funds/political_links.ts — since АОП award totals overlay the EU-funds political flags). Procurement is served from Postgres (Cloud SQL), NOT GCS — the whole data/procurement/ tree (except roads.json + derived/mp_party.json) is excluded from bucket:sync and no longer gzip-shipped, so the run's ordinary bucket:sync (done anyway for funds/prices/etc.) already handles procurement's two GCS stragglers; there is no bucket:sync:all step for procurement. Publish procurement via Postgres: the skill's Step 2b runs npm run db:refresh for LOCAL PG (contracts + tenders, rebuilt from the fresh gitignored shards — no commit/sync); for prod, emit the Cloud SQL loaders in Next-steps (Procedure step 8): npm run db:load:pg:cloud && npm run db:load:tenders:pg:cloud && npm run db:load:awarder-seats:pg:cloud. (Both tables are wired into db:refresh; a migrated table left out of the refresh path silently goes stale — the tenders-stale bug, fixed 2026-07-02.) Textbook market: the CPV-22112 concentration overlay (/awarder/000695114) is built from this same corpus — after the re-ingest, re-run gen_textbook_market.ts + bucket:sync:paths -- education (see the egov_procurement row).
АОП debarred-suppliers register	update-procurement (Step 5 — debarred-list refresh; debarred flags on flagged EU-funds beneficiaries refresh via the same political_links step)
КЗК procurement-appeals register (жалби по ЗОП)	update-kzk-appeals — an automated orchestrator step; invoke it with the Skill tool like any other queued skill. It drives a headed Playwright browser (a desktop window pops up for ~2 min) and needs Bulgarian egress (reg.cpc.bg 403s non-BG), so it is still never a CI/--all step — but on a developer machine in BG the orchestrator runs it unattended. ⚠ Pin the local DB — --apply writes Postgres via scripts/db/lib/pg.ts, and any DATABASE_URL left exported by an earlier db:*:cloud command is password-less by design and resolves its password from .pgpass (the CLOUD password), so it fails 28P01 against local PG. The skill's Step 0 covers this. ⚠ Assert 2,098 outcomes survive every --apply (select count(*) from kzk_appeals where outcome is not null) — the merits-outcome crawler (scripts/procurement/kzk_decisions.ts) does not exist in the repo, so those rows are irreplaceable; never wipe kzk_appeals.json or TRUNCATE the table. Stamp state/ingest/kzk_appeals.json on success. Surfaces on /tenders/:unp, the /procurement "Recent appeals (КЗК)" tile, and the procurementAppeals AI tool. Publishing is NOT bucket:sync and NOT db:dump — procurement/ is excluded from the sync, and db:dump only pg_dumps outward to GCS. See the skill's Step 4.
МОН регистър на институциите (schools/kindergartens)	Re-crawl the ЕИК→EKATTE crosswalk that geo-resolves school/kindergarten procurement buyers: npx tsx scripts/procurement/mon_ri_crawl.ts → data/procurement/derived/mon_ri_eik_crosswalk.json, then npx tsx scripts/procurement/awarder_geo_map.ts && npm run procurement:ingest. Headed Playwright (ri.mon.bg is Cloudflare-walled — a desktop window opens ~1 min; reachable from any egress, no BG requirement); never a CI/--all step. Fires rarely — EIK↔EKATTE is stable, so only flips when schools open/close. NOT a full update-procurement re-ingest — just the crawl + geo rebuild. Stamp state/ingest/mon_ri_register.json. See [[reference_mon_ri_register]] + scripts/procurement/mon_ri_crawl.ts.
ИСУН EU funds (beneficiaries)	update-funds
ИСУН EU funds (projects)	update-funds (Step 2 — contract-level ingest; runs npm run funds:ingest-projects after the beneficiaries ingest, then npx tsx scripts/funds/build_geo_pins.ts to rebuild the slim per-município files under data/funds/projects/by-muni-geo/ — top-200 contracts by money, geocoded + non-geocoded — that back the My-Area "Проекти от еврофондовете" tile: a scrollable project list plus an on-demand Leaflet map of the geocoded subset.)
data.egov.bg бюджет (budget execution)	update-budget (a December snapshot that closes a fiscal year also re-bases the tax-policy simulator — run npx tsx scripts/budget/run_policy_baseline.ts after the ingest; see "Policy-baseline refresh" below)
Per-ministry execution reports (програмен бюджет)	update-budget