[standing] Estate CodeQL cron drift detection + 6-week budget review

[hyperpolymath]

Background

Spun out of #288 — the one-off CodeQL weekly→monthly fan-out is finite work and will close. But the standing concerns are:

1. New repos scaffolded with weekly cron drift back to the same state [campaign] Estate CodeQL weekly→monthly sweep (cut 3, standards#233 Option B — ~206 repos) #288 cleaned up.
2. The Cut-3 savings claim (~46k Actions-min/yr) needs a 6-week budget review to confirm it landed.
3. Future cron-policy changes (e.g. cut 4+) need a single durable place to land.

This issue is the durable home for that work. It does not close — it carries the recurring sweep on a monthly cadence.

What this tracker owns

A. Monthly drift sweep (recurring)

On the 15th of each month, re-audit estate for CodeQL cron drift back to '0 6 * * 1':

gh api --paginate "search/code?q=org:hyperpolymath+filename:codeql.yml+cron&per_page=100" \
  --jq '.items[] | .repository.full_name + "\t" + .path' \
  | while IFS=$'\t' read -r repo path; do
      gh api "repos/${repo}/contents/${path}" --jq '.content' 2>/dev/null \
        | base64 -d 2>/dev/null \
        | grep -qE "^[[:space:]]*-[[:space:]]*cron:[[:space:]]*['\"]0 6 \* \* 1['\"]" \
        && echo "$repo $path"
    done

For each drift hit: file the standard cut-3-shape PR ('0 6 * * 1' → '0 6 1 * *') using the body shape from #288.

B. 6-week budget review (one-off — first checkpoint ~2026-07-15)

Counterfact: Cut-3 acceptance criterion calls for "6-week budget review confirms ~46k min/yr savings landed."

• 2026-05-30: ci(codeql): canonical cron weekly→monthly (cut 3, standards#233 Option B) #286 canonical merged, sweep starts.
• 2026-07-15: 6-week mark — pull gh api repos/.../actions/billing/usage-equivalent or the org Actions billing CSV; compute scheduled-CodeQL min delta vs the pre-cut baseline; comment results here.

C. Future cron-policy changes (cut 4+)

If a future budget decision changes the canonical CodeQL cron again (e.g. to quarterly, or different time), the decision ticket files here as a sub-comment and the fan-out happens via a new dated [campaign] issue child of this tracker.

Triggering shape

Two possible shapes for the drift sweep:

• Manual cadence: monthly checklist on the 15th, ~5min to run the audit + decide whether any new PRs are needed.
• Automated: a .github/workflows/codeql-cron-drift.yml in hyperpolymath/standards runs the audit on a monthly cron, files an issue with the drift list. Owner-decision required before automating (cost: a few Actions-min/month vs the value of catching drift).

Prefer the manual cadence first — automate after we have at least one confirmed drift hit, otherwise we're paying for a job that does nothing.

Cross-references

• Parent campaign: [campaign] Estate CodeQL weekly→monthly sweep (cut 3, standards#233 Option B — ~206 repos) #288 (one-off fan-out, closes when complete)
• Long-tail follow-up: [campaign] Long-tail non-canonical CodeQL cron sweep (~86 files / 30 repos) #324
• Decision: GH Actions budget: cut 3 — CodeQL scheduled-run policy (pick a shape) #233 (Option B, 2026-05-30)
• Canonical change: ci(codeql): canonical cron weekly→monthly (cut 3, standards#233 Option B) #286
• Memory: session_2026_05_28_gh_actions_budget_cuts_1_2_3.md, project_estate_codeql_cron_recurring_drift.md (TBD)

Acceptance

This tracker is intentionally never-closing. Acceptance per cycle:

• Per month: drift audit run, results commented (0 drift hits is a valid result).
• Per 6-month rolling window: at least one comment with a budget-review delta.

[hyperpolymath]

Concrete monthly drift-detection script

For the recurring portion, a single-shot audit query:

#!/usr/bin/env bash
# /tmp/codeql-cron-drift-audit.sh — run on the 15th of each month
set -euo pipefail

OUT=/tmp/codeql-cron-drift-$(date -u +%Y-%m-%d).tsv
: > "$OUT"

gh api --paginate "search/code?q=org:hyperpolymath+filename:codeql.yml+cron&per_page=100" \
  --jq '.items[] | .repository.full_name + "\t" + .path' \
  | while IFS=$'\t' read -r repo path; do
      content=$(gh api "repos/${repo}/contents/${path}" --jq '.content' 2>/dev/null | base64 -d 2>/dev/null || true)
      if printf '%s' "$content" | grep -qE "^[[:space:]]*-[[:space:]]*cron:[[:space:]]*['\"]0 6 \* \* 1['\"]" ; then
        printf '%s\t%s\n' "$repo" "$path" >> "$OUT"
      fi
    done

n=$(wc -l < "$OUT" || echo 0)
echo "Drift hits: $n (full list in $OUT)"
if [ "$n" -gt 0 ]; then
  echo "To fix: feed $OUT into /tmp/codeql-audit/sweep.sh, e.g."
  echo "  awk -F'\\t' '{print \$1}' $OUT | sort -u | xargs -n1 /tmp/codeql-audit/sweep.sh"
fi

Output: zero rows = nothing to do.

When to act

• 0 rows: comment here with n=0 on YYYY-MM-DD, no PR work.
• 1-5 rows: file PRs directly via sweep.sh per-repo (idempotent).
• >5 rows: re-evaluate — the scaffold/template may have drifted; fix the source.

6-week budget checkpoint (~2026-07-15)

When the time comes, post Actions billing delta vs the 2026-05-30 (pre-cut) baseline. Comparable metric: scheduled codeql min/month. Expected delta: ~46k/yr ÷ 12 ≈ ~3.8k min/month reduction.