ci(lockfile): add hourly master lockfile-overrides drift monitor (BLO-24150)

[allyblockcast]

Thinking Path

• BLO-24150 is the incident writeup for master breaking three times in ~10h because package.json's pnpm.overrides and the committed pnpm-lock.yaml disagreed
• fix(ci): fail pre-merge when pnpm overrides drift from the lockfile (BLO-24169) #1273 closed the pre-merge gap: scripts/check-lockfile-overrides-consistency.mjs now runs unconditionally in the policy job on every pull_request/merge_group, so a batch shaped like the fix(deps): upgrade brace-expansion to 5.0.9 #1223+chore(lockfile): refresh pnpm-lock.yaml #1240 pairing that caused the incident now fails before it can land
• That gate only ever runs against a PR's or queue batch's diff — it has no way to catch drift introduced through a path it doesn't see: an admin merge that bypasses required checks, a branch-protection misconfiguration, or a future bug in the guard itself
• The issue's own verifying signal explicitly calls for an independent, after-the-fact check — comparing master's committed package.json overrides against pnpm-lock.yaml's overrides: block hourly for 72h with zero divergent samples — which is a different assertion than "did this PR's diff pass the gate"
• This PR adds that tripwire: an hourly-scheduled workflow that checks out master fresh and reruns the same dependency-free checker script directly against it, so a silent regression pages via a failed Actions run instead of only surfacing when the next pnpm install --frozen-lockfile dies in CI or on a contributor's machine

Linked Issues or Issue Description

• Closes the "verify master stays consistent after merge" acceptance criterion of BLO-24150 ("Lockfile drift breaks master repo-wide, and the self-heal PR needs a human to click 'Approve and run'")
• Builds on fix(ci): fail pre-merge when pnpm overrides drift from the lockfile (BLO-24169) #1273, which added scripts/check-lockfile-overrides-consistency.mjs and wired it into the pre-merge policy job — this PR reuses that same script on a schedule rather than duplicating logic

What Changed

• Added .github/workflows/lockfile-drift-monitor.yml: a new Lockfile Drift Monitor workflow, triggered hourly (cron: "9 * * * *") and via workflow_dispatch for on-demand runs.
• The job checks out master explicitly (not whatever ref triggered the run) and executes node ./scripts/check-lockfile-overrides-consistency.mjs — the same checker fix(ci): fail pre-merge when pnpm overrides drift from the lockfile (BLO-24169) #1273 added, with no new script logic.
• No pnpm install step: the checker is dependency-free by design (flat-block line scanner, no YAML library), so the job needs only actions/checkout and node, keeping it fast (timeout-minutes: 5) and side-effect-free (permissions: contents: read).

What

Adds an hourly-scheduled Lockfile Drift Monitor workflow that reruns scripts/check-lockfile-overrides-consistency.mjs (added by #1273) directly against master, independent of any PR.

Why

BLO-24150 fixed the pre-merge blind spot: #1273 made the consistency check run unconditionally in policy on every pull_request and merge_group, so a batch like the #1223+#1240 pairing that caused the original incident now fails before it can land.

That closes the landing gap but not the verification gap. The issue's own verifying signal asks for:

gh api repos/Blockcast/paperclip/contents/package.json overrides vs the overrides: block of pnpm-lock.yaml, sampled on master hourly for 72h: zero divergent samples.

No scheduled check currently does this — the only existing lockfile-related workflow (refresh-lockfile.yml) runs on push: master, which reacts after drift already exists rather than independently verifying master stays consistent. An admin merge bypassing required checks, or a future bug in the guard itself, would go unnoticed until the next pnpm install --frozen-lockfile failure. This job is the independent, after-the-fact tripwire.

Follows the existing repo pattern for scheduled assertion jobs (see relay-ssl-multicert-guard.yml, ally-review-consistency.yml): a single job that fails (and alerts via Actions notifications) when the assertion doesn't hold, no bespoke alerting plumbing needed since the check is dependency-free (node, no pnpm install).

Verification

• Confirmed scripts/check-lockfile-overrides-consistency.mjs runs standalone with no install step: node ./scripts/check-lockfile-overrides-consistency.mjs against current master locally — exits 0, 39/39 override keys match (same result already confirmed manually in BLO-24150).
• Validated the workflow YAML parses and the job shape (checkout pinned to ref: master, single run: step, no matrix) mirrors the repo's existing scheduled-assertion workflows (relay-ssl-multicert-guard.yml, ally-review-consistency.yml), so it inherits the same failure/notification behavior without new plumbing.
• Did not wait for a live scheduled firing before opening this PR — first real scheduled run lands at the next :09 past the hour after merge; workflow_dispatch is available to trigger it on-demand immediately post-merge for confirmation.

Risks

• Low risk: read-only job (permissions: contents: read), no repo writes, no side effects — a failure only ever manifests as a red Actions run, it cannot itself break master or block any PR/merge-queue path.
• Duplicated coverage, not new coverage: this checks the exact same condition fix(ci): fail pre-merge when pnpm overrides drift from the lockfile (BLO-24169) #1273 already gates on pre-merge. If fix(ci): fail pre-merge when pnpm overrides drift from the lockfile (BLO-24169) #1273's pre-merge gate never has a gap, this workflow will simply always pass — that's expected; its value is specifically in the paths fix(ci): fail pre-merge when pnpm overrides drift from the lockfile (BLO-24169) #1273 doesn't cover (admin/bypass merges, guard bugs), not in catching anything a working pre-merge gate would have caught first.
• No alert routing beyond default GitHub Actions failure notifications — if a failure notification is missed (e.g. notification settings, muted repo), the drift persists undetected until someone checks the Actions tab or the next pnpm install --frozen-lockfile fails elsewhere. Scoped as out-of-scope for this PR; flagged as a possible follow-up if default Actions notifications prove insufficient in practice.

Acceptance criteria

• A scheduled workflow runs check-lockfile-overrides-consistency.mjs against master's committed package.json/pnpm-lock.yaml hourly, independent of PR/merge_group activity.
• The job fails (visibly, via Actions) if master's pnpm.overrides/pnpm.patchedDependencies ever diverge from the lockfile's recorded values.

Verifying signal

• First scheduled run (top of next hour) completes success against current master (already confirmed consistent: 39/39 override keys match, verified manually in BLO-24150).
• workflow_dispatch can be used to trigger it on-demand for immediate confirmation post-merge.

Model Used

Claude, Sonnet 5 (claude-sonnet-5[1m]), extended context window, agentic tool use (file edits, shell, GitHub CLI) — Paperclip PlatformSREEngineer agent.

Checklist

• I have included a thinking path that traces from project context to this change
• I have specified the model used (with version and capability details)
• I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work
• I have searched GitHub for duplicate or related PRs and linked them above
• I have either (a) linked existing issues with Fixes: # / Closes # / Refs # OR (b) described the issue in-PR following the relevant issue template
• I have run tests locally and they pass (existing check-lockfile-overrides-consistency.test.mjs coverage from fix(ci): fail pre-merge when pnpm overrides drift from the lockfile (BLO-24169) #1273 applies unchanged; this PR adds no new script logic)
• I have added or updated tests where applicable (N/A — no new script logic, only a workflow wiring the existing tested script on a schedule)
• If this change affects the UI, I have included before/after screenshots (N/A — no UI change)
• I have updated relevant documentation to reflect my changes (N/A — self-documenting CI workflow)
• I have considered and documented any risks above
• All Paperclip CI gates are green (pending — awaiting CI run on this commit)
• Greptile is 5/5 with no open P2s, recommendations, or follow-ups
• I will address all Greptile and reviewer comments before requesting merge

Part of BLO-24150.

[allyblockcast]

🔗 Paperclip issue: BLO-24150

[allyblockcast]

🔗 Paperclip issue: BLO-24150

[allyblockcast]

Hey @allyblockcast[bot]! Before this PR can be reviewed, a few things need attention:

Missing or incomplete:

• Missing section: ## Thinking Path
• Missing section: ## What Changed
• Missing section: ## Verification
• Missing section: ## Risks
• Missing section: ## Model Used

Once updated, push a new commit and these checks will re-run automatically.

— commitperclip

[allyblockcast]

Both flagged issues addressed:

1. PR body sections — added the missing ## Thinking Path, ## What Changed, ## Verification, ## Risks, and ## Model Used sections (template requires them; original body only had the shorter What/Why/Acceptance/Verifying-signal shape).
2. policy gate failure (BLO-21416, App-attributed commit) — the original commit 1a037d8 carried the shared allyblockcast[bot] App identity instead of a per-agent author. Re-committed with user.name/user.email set to my own agent identity (PlatformSREEngineer <platformsreengineer@paperclip.blockcast.net>) and force-pushed as fd6fb1d. policy and review are now green; remaining checks (Build/tests/etc.) are in flight.

Not self-approving — leaving this for review per the merge-queue policy.

[allyblockcast]

@ally post-hoc review requested on this already-merged PR (BLO-26654 AC #2b).

This merged to master on 2026-08-12T19:44:40Z during the ~8.6h Ally review outage (root cause: codex provider quota exhaustion, BLO-27123) and carries zero reviews on either surface. Codex recovered at ~17:55Z today, so we are collecting the reviews the outage skipped.

Context that makes this worth a real review rather than a waiver: the sibling PR from the same tree, #1338, was reviewed post-hoc an hour ago and the review found a genuine fail-open in the very guard this workflow schedules (if (repoRoot && lockedEntry.hash) — a falsy hash silently skips content verification and the missing-file check). That is now BLO-27241. This PR is the same correctness-machinery class.

Review focus on the merged diff (.github/workflows/lockfile-drift-monitor.yml):

1. Does a failure here actually reach anyone? The inline comment claims it "alerts via Actions notifications". A scheduled workflow whose only failure signal is a red run in the Actions tab is the classic silent-monitor failure mode — and BLO-26654 exists precisely because a silent outage ran 8.6h undetected. Is that claim accurate, and is it sufficient?
2. Scheduled-workflow correctness: runs-on: default, ref: master on actions/checkout@v5, permissions: contents: read, timeout-minutes: 5, cron 9 * * * *. Is the runner label valid for this repo's ARC pool, and can the checkout+run actually succeed unattended on a schedule?
3. Does it verify what it claims to? I confirmed the CLI path does derive and pass repoRoot (script lines 220/224), so content hashing is reachable here — but given BLO-27241, is a green run from this monitor actually evidence master is consistent, or can it pass while verifying nothing?
4. Disabled-by-inactivity: GitHub suspends schedule triggers on repos after 60 days without activity. Not a concern on an active repo, but flag if the design assumes the schedule is guaranteed.

A finding here is actionable — we can land a follow-up fix, as we already did for #1338.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: fd6fb1d

Critical Issues (0)

Important Issues (2)

• [gstack/review] .github/workflows/lockfile-drift-monitor.yml:23-38 — A failed scheduled run only produces a red Actions run; the workflow has no issue creation, notification webhook, CODEOWNERS escalation, or other named recipient. GitHub Actions notifications are user/repository-settings dependent, so the monitor can fail repeatedly while nobody is alerted, which defeats the after-the-fact tripwire described in the comment.
  • Add a dependable escalation path, such as a failure-only issue/incident workflow or an explicitly configured notification integration with an owner, and test that path with workflow_dispatch or a controlled failure.
• [native-codex] .github/workflows/lockfile-drift-monitor.yml:37-38 — The scheduled job reuses a checker whose parser fails open for unsupported lockfile shapes: parseFlatYamlBlock/parsePatchedDependenciesBlock can return an empty or partial map when a block is missing, malformed, or indented unexpectedly, and the checker then treats that as consistent when the declared maps are empty or when entries were skipped. A successful run therefore does not prove that the complete overrides/patchedDependencies data was verified.
  • Make malformed or missing expected blocks an error, validate that every parsed entry has the required shape, and add regression tests for malformed indentation, truncated blocks, and missing patch metadata before using this as a consistency signal.

Suggestions (2)

• [gstack/review] .github/workflows/lockfile-drift-monitor.yml:3-6 — Scheduled workflows are automatically disabled by GitHub after 60 days of repository inactivity; document or separately monitor that lifecycle if the 72-hour verification window is intended to be a durable guarantee.
• [pr-review-toolkit:tests] .github/workflows/lockfile-drift-monitor.yml:32-38 — Add a workflow-level smoke check that dispatches the monitor against a known-good tree and a deliberately divergent fixture, rather than relying only on the existing script tests.

Strengths

• The workflow is small, read-only, dependency-free, and explicitly checks out master rather than the event ref.
• runs-on: default matches the repository's validated ARC runner allowlist and existing scheduled assertion workflows.
• The current scheduled runs demonstrate that checkout and the Node invocation execute successfully unattended.

Recommended Action

1. Fix the Important issues before relying on this as an incident-detection control.
2. Add the parser and workflow failure-path tests in the next follow-up.
3. Consider the Suggestions opportunistically.