Summary
`scripts/dependency-audit.mjs` runs a live `npm audit` inside the required `Frontend` job (`.github/workflows/ci.yml`), which also runs lint/test/build. Because the advisory database it queries updates on its own schedule, any open PR can go red with zero code changes whenever a new CVE publishes — this happened three times in a few hours today (dompurify/js-yaml/brace-expansion/undici via #256/#257, then nanoid via GHSA-2v37-7h3g-55p8 blocking #259, opened after #257 was already fixed).
Decision
Owner-selected approach (of three options presented): keep the PR-blocking gate exactly as strict as it is today — do not weaken it — and add a scheduled workflow that proactively re-runs the same audit against `dev` independent of any open PR. This keeps `dev` caught up so a PR rarely gets blindsided, and when a new advisory does land mid-review, there's a same-day heads-up rather than a surprise CI failure discovered only when someone happens to push.
Proposed Behavior
New `.github/workflows/dependency-audit-schedule.yml`:
- Runs daily on a cron schedule, plus `workflow_dispatch` for manual runs.
- Checks out `dev`, installs frontend deps, runs `node scripts/dependency-audit.mjs`.
- On a blocking finding: creates (or comments on, if one is already open) a labelled issue with the audit output and the fix procedure, assigned to the owner.
- On a clean result: closes the alert issue if one is currently open (self-healing once the advisory is fixed).
Acceptance Criteria
- New scheduled workflow exists, does not affect `ci.yml`'s existing per-PR gate at all.
- A manual `workflow_dispatch` run completes successfully against the current (clean) `dev` state.
- Issue-filing logic reviewed for idempotency (does not spam a new issue every day for the same still-unresolved advisory).
Priority
P2 — quality-of-life / CI reliability, not blocking product work.
Summary
`scripts/dependency-audit.mjs` runs a live `npm audit` inside the required `Frontend` job (`.github/workflows/ci.yml`), which also runs lint/test/build. Because the advisory database it queries updates on its own schedule, any open PR can go red with zero code changes whenever a new CVE publishes — this happened three times in a few hours today (dompurify/js-yaml/brace-expansion/undici via #256/#257, then nanoid via GHSA-2v37-7h3g-55p8 blocking #259, opened after #257 was already fixed).
Decision
Owner-selected approach (of three options presented): keep the PR-blocking gate exactly as strict as it is today — do not weaken it — and add a scheduled workflow that proactively re-runs the same audit against `dev` independent of any open PR. This keeps `dev` caught up so a PR rarely gets blindsided, and when a new advisory does land mid-review, there's a same-day heads-up rather than a surprise CI failure discovered only when someone happens to push.
Proposed Behavior
New `.github/workflows/dependency-audit-schedule.yml`:
Acceptance Criteria
Priority
P2 — quality-of-life / CI reliability, not blocking product work.