@avi2dg/checks 0.64.0 → 0.65.1

package/CHANGELOG.md

@@ -2,6 +2,22 @@
 
 Every release of `@avi2dg/checks`, newest first, written by the release from its conventional commits.
 
+## 0.65.1
+
+Released 2026-11-03.
+
+### Fixes
+
+- allow weekly advisory scan in any public repository [#42](https://github.com/avi2d/checks/pull/42)
+
+## 0.65.0
+
+Released 2026-11-03.
+
+### Features
+
+- **ci-wiring:** one CI run per pull request, refuse schedules and long jobs [#41](https://github.com/avi2d/checks/pull/41)
+
 ## 0.64.0
 
 Released 2026-11-03.

package/docs/bins.md

@@ -44,7 +44,7 @@ The night-run workflow runs them with `checks-lint --night`, which hands each ra
 These bins run on their own:
 
 - [`checks-test`](gates/checks-test.md) runs the suite as `scripts.test` and refuses a skip without a reason at its test site.
-- [`checks-flake`](gates/checks-flake.md) runs the suite on a schedule and records the seeds a flaky test fails with.
+- [`checks-flake`](gates/checks-flake.md) runs the suite when started by hand and records the seeds a flaky test fails with.
 - [`checks-mutation`](gates/checks-mutation.md) runs Stryker for scoped checks and refuses a full run outside CI.
 - [`checks-mutation-compare`](gates/checks-mutation-compare.md) compares the mutants of two reports and lists each one that regresses.
 - [`checks-mutation-baseline`](gates/checks-mutation-baseline.md) restores the newest mutation baseline from `main`, saves it on a self-hosted runner's disk in place of an artifact, and deletes superseded baselines after a `main` run.

package/docs/design.md

@@ -204,7 +204,8 @@ A daily release pull request would leave each merged change unpublished until a
 Only then does it move `main` to it without a force, so `main` only ever gains a release commit whose checks passed.
 It tags the commit it landed and nothing else.
 A repository that is no package keeps the release pull request, and it opens only when someone runs the workflow.
-No release runs on a schedule, in a package or not, since a schedule cuts releases no one asked for.
+Only a public package that publishes to npm may release on a schedule, at most once a day.
+A schedule elsewhere cuts releases no one asked for.
 `checks-release-pr` writes only to the `release/<branch>` branch it owns, and rebuilds that branch on `main` rather than merging `main` into it, so the changelog it carries is the one the build writes.
 `checks-release-tag` writes only the `v*` tag of a release commit that already landed.
 The `github-release` job's `contents: write` creates or updates the GitHub release from the tag's `CHANGELOG.md` section.
@@ -281,7 +282,7 @@ A group or other write bit fails the run, because another user could have edited
 
 `checks-advisories` compares the advisories at both ends of a range instead of failing on every advisory at the head.
 An advisory published against a package that landed a month earlier would otherwise fail every open pull request, including one that touches only docs.
-The scheduled `--all` run finds those advisories, and `advisory-acks.json` carries the ones a repository accepts for a while.
+The weekly `--all` run finds those advisories, and `advisory-acks.json` carries the ones a repository accepts for a while.
 
 The gate runs OSV-Scanner rather than Trivy, Grype or `bun audit`.
 Trivy 0.74.0 reads a nested `bun.lock` entry such as `mkdirp/minimist` under a name no advisory carries, so it misses every package bun nests.

package/docs/gates/checks-advisories.md

@@ -14,7 +14,7 @@ It ignores aliases, because two live advisories can list each other as aliases.
 An advisory published against a package the base already held shows at both ends, so it fails no range, and `--all` reports it instead.
 Each failure names the package, its version, the advisory id, its severity and its summary.
 A range that leaves `bun.lock` unchanged runs no scan.
-A run `checks-lint` starts defers the scan to the scheduled `--all` run instead, so the desk and the pull request neither fetch the database nor scan.
+A run `checks-lint` starts defers the scan to the weekly `--all` run instead, so the desk and the pull request neither fetch the database nor scan.
 It also holds `advisory-acks.json` to the rules in [The acknowledgement file](#the-acknowledgement-file) on every run.
 
 ## What it reads
@@ -63,7 +63,7 @@ An entry whose `until` falls more than 30 days after that moment fails the run a
 Once that moment passes `until`, the entry fails every run until it is deleted or renewed with a later `until`, whether or not the range touches `bun.lock`.
 Delete it once the package is upgraded.
 When a scan runs, an entry that matches no advisory at the head fails, so the file holds only live entries.
-A deferred run still holds each entry to its day, while an entry that matches nothing waits for the scheduled run.
+A deferred run still holds each entry to its day, while an entry that matches nothing waits for the weekly run.
 A file that does not decode as that list exits 2.
 
 ## Arguments
@@ -99,18 +99,20 @@ advisories: 1 acknowledgement(s) in advisory-acks.json do not hold:
 ## When it runs
 
 `checks-lint` runs it over each pull request's range in a repository that tracks `bun.lock`, as [checks-lint](checks-lint.md) says.
-That run defers the scan to the scheduled run, so it fetches no database and reports the deferral instead of a verdict.
+That run defers the scan to the weekly run, so it fetches no database and reports the deferral instead of a verdict.
 A range that leaves `bun.lock` unchanged runs in under a second, and a direct run over a range that changes `bun.lock` scans for about 10 seconds on a warm cache.
 
 ## Running it on a schedule
 
-A range never fails on an advisory published after its package landed, so a scheduled `--all` run finds those.
-A consuming repository pins advisories between 05:00 and 06:00 UTC at a minute chosen so repositories do not start together:
+A range never fails on an advisory published after its package landed, so a weekly `--all` run finds those.
+Only a public repository runs it on a schedule, as [checks-ci-wiring](checks-ci-wiring.md#schedules) requires.
+Any other repository starts the same workflow by hand with `gh workflow run`, with no `schedule` trigger.
+A package scans on Monday between 05:00 and 06:00 UTC, at a minute chosen so repositories do not start together:
 
 ```yaml
 on:
   schedule:
-    - cron: "15 5 * * *"
+    - cron: "15 5 * * 1"
   workflow_dispatch:
 jobs:
   advisories:

package/docs/gates/checks-ci-wiring.md

@@ -86,7 +86,8 @@ Each refusal names the workflow file and line, the version found and where it wa
 
 ### Release schedule
 
-It refuses a workflow that triggers on `schedule` and releases, in every repository, whether or not it publishes to npm.
+It refuses a workflow that triggers on `schedule` and releases, unless the repository is a public package that publishes to npm.
+That release runs at most once a day.
 A workflow releases when a run step calls `checks-release-pr`, `checks-release-push`, `checks-release-tag` or `checks-release-publish`.
 A call counts directly, through `bunx`, or through `bun` or `bun run` with the bin's path or its source file.
 A call through a `package.json` script counts, as `bun run <script>` where the named script releases.
@@ -94,12 +95,34 @@ A call through a local reusable workflow counts, as a job that uses a file under
 A call through a repository shell script counts, as a path inside the repository whose file releases.
 A workflow also releases when a run step publishes to npm, as [checks-release-preflight](checks-release-preflight.md) reads it, directly or through one of those paths.
 Text that only names a release bin, such as an `echo`, never counts.
-A release runs when someone starts it, as [checks-release-pr](checks-release-pr.md#when-it-runs) says.
-Each refusal names the workflow file and the line of its `schedule` trigger.
+A repository publishes to npm when one of its workflows runs `npm publish` or `checks-release-publish`, the same ways a release call counts, and its `package.json` does not set `private` to `true`.
+A run outside CI cannot read whether the repository is private, so there it refuses only for the `package.json` field or the missing publish step.
+A daily release has one `cron` entry with one minute and one hour.
+Any other release runs when someone starts it, as [checks-release-pr](checks-release-pr.md#when-it-runs) says.
+Each refusal names the workflow file, the line of its `schedule` trigger and what to change.
+
+### Schedules
+
+It refuses every other workflow that triggers on `schedule`, since a test, mutation, flake, browser or night run starts only by hand, with `gh workflow run`.
+The one schedule it keeps is a weekly advisory scan in a public repository.
+A workflow scans advisories when a run step calls `checks-advisories`, the same ways a release call counts, and every other run step is a `bun install`.
+A weekly scan has one `cron` entry with one minute, one hour and one weekday, and `*` for the day of the month and the month.
+It refuses an advisory scan that runs more often, and any scheduled advisory scan in a private repository.
+A run outside CI cannot read whether the repository is private, so it refuses a scan there only for the cron.
+A workflow that releases on a schedule is judged only by the release rule above.
+Each refusal names the workflow file, the line of its `schedule` trigger and what to change.
+
+### Job timeouts
+
+Every job sets `timeout-minutes` to a number of at most 60, so no job runs for hours.
+A job without one would hold its runner for GitHub's 360-minute default when a step hangs.
+It refuses a job that sets no `timeout-minutes`, sets more than 60, or sets an expression it cannot read before the run.
+A job that calls a reusable workflow with `uses` sets no timeout, and the called workflow's jobs are judged in their own file.
+Each refusal names the workflow file, the job and the limit.
 
 ## What it reads
 
-The bin reads `.github/workflows/*.yml`, `*.yaml`, the `scripts` and `checks` runners in `package.json` and the shell scripts those steps and scripts run from the working tree.
+The bin reads `.github/workflows/*.yml`, `*.yaml`, the `scripts`, `private` and `checks` runners in `package.json` and the shell scripts those steps and scripts run from the working tree.
 It reads each file a setup-bun step names for its version.
 It reads the fleet pin from the kit's own `.bun-version`.
 It reads the target branch from `GITHUB_BASE_REF`, then from `refs/remotes/origin/HEAD` and then from the event file `GITHUB_EVENT_PATH` names.
@@ -115,7 +138,7 @@ It takes no arguments.
 | Code | Result |
 | --- | --- |
 | 0 | Every required command has a reachable step. |
-| 1 | A required command is missing or blocked, a job runs on the wrong runner, a workflow names a missing workflow or job, a setup-bun step drifts from the fleet bun version, or a workflow that releases runs on a schedule. |
+| 1 | A required command is missing or blocked, a job runs on the wrong runner, a workflow names a missing workflow or job, a setup-bun step drifts from the fleet bun version, a workflow that releases runs on a schedule outside a public npm package or more than once a day, a workflow other than a weekly public advisory scan runs on a schedule, or a job can run for more than 60 minutes. |
 | 2 | A workflow or `package.json` cannot be decoded, or the kit's own `.bun-version` is missing, unreadable or blank. |
 
 ## Sample output
@@ -142,11 +165,26 @@ ci-wiring: 1 reference(s) name a missing workflow or job:
   .github/workflows/daily-release.yml line 31: names missing workflow commitlint.yml
 ```
 
-A workflow that releases on a schedule produces a report like this:
+A workflow that releases on a schedule in a repository that publishes nothing to npm produces a report like this:
 
 ```
 ci-wiring: 1 workflow(s) release on a schedule:
-  .github/workflows/daily-release.yml line 3: drop the schedule, so a release runs only when someone starts it
+  .github/workflows/daily-release.yml line 3: only a public package that publishes to npm releases on a schedule; drop the schedule, so a release runs only when someone starts it
+```
+
+A scheduled test run and a daily advisory scan produce a report like this:
+
+```
+ci-wiring: 2 workflow(s) run on a schedule:
+  .github/workflows/advisories.yml line 3: the advisory scan runs more than once a week; keep one cron at a minute, an hour and a weekday, such as "15 5 * * 1"
+  .github/workflows/night-run.yml line 4: drop the schedule, so it runs only when someone starts it with gh workflow run
+```
+
+A job that sets no timeout produces a report like this:
+
+```
+ci-wiring: 1 job(s) can run for hours:
+  .github/workflows/ci.yml job checks: the job sets no timeout-minutes, so a hung run holds its runner for GitHub's 360 minute default; set timeout-minutes to a number of at most 60
 ```
 
 ## When it runs

package/docs/gates/checks-flake.md

@@ -4,7 +4,7 @@ audience: consumers
 ---
 # checks-flake
 
-`checks-flake` is the scheduled run that finds flaky tests and records the seeds each one fails with.
+`checks-flake` is the run someone starts by hand that finds flaky tests and records the seeds each one fails with.
 
 ## What it checks
 
@@ -100,21 +100,20 @@ Rerunning a seed with bun test --randomize --seed=<seed> --parallel=4 reproduces
 
 ## When it runs
 
-Only a schedule the repository writes runs it.
+Only a workflow the repository starts by hand runs it.
 
-## Running it on a schedule
+## Running it by hand
 
-A repository runs it on a schedule and keeps the record of a failed run as an artifact.
-A repository schedules it at minute 27 of its tier's 30 minute night window, so repositories do not start together:
+A repository runs it from a workflow someone starts with `gh workflow run`, and keeps the record of a failed run as an artifact.
+The workflow holds no schedule, since [checks-ci-wiring](checks-ci-wiring.md#schedules) refuses one:
 
 ```yaml
 on:
-  schedule:
-    - cron: "27 22 * * *"
   workflow_dispatch:
 jobs:
   flake:
     runs-on: ubuntu-latest
+    timeout-minutes: 60
     steps:
       - uses: actions/checkout@v5
       - uses: oven-sh/setup-bun@v2

package/docs/gates/checks-lint.md

@@ -18,7 +18,7 @@ A test file classifies as TypeScript, so its change runs every applicable gate t
 Gates requiring tracked TypeScript files begin running when the repository tracks TypeScript.
 `checks-lint-coverage` and `checks-graphwalk` also begin running when the repository tracks an `.astro` file.
 `checks-advisories` begins running when the repository tracks `bun.lock`.
-`checks-lint` defers its scan to the scheduled run, so the desk and the pull request fetch no database.
+`checks-lint` defers its scan to the weekly run, so the desk and the pull request fetch no database.
 `checks-frontend-syntax` begins running when the repository tracks `frontend-syntax.json` at its root.
 `checks-copy` begins running when the repository tracks `copy.json` at its root.
 `checks-css-size` begins running when the repository tracks a `*.css` file.

package/docs/gates/checks-mutation-scope.md

@@ -38,7 +38,7 @@ Stryker writes no source without mutants into the report, so a mutated source th
 When a unit test changed, each such source that exists at `HEAD` enters the scope.
 A change under `tests/e2e/` changes no unit test, so it needs no baseline report.
 The scope trusts the coverage edges of the latest full baseline.
-So a helper, fixture or preload changed on `main` since that baseline can hide a lost kill until the scheduled full baseline refreshes.
+So a helper, fixture or preload changed on `main` since that baseline can hide a lost kill until the next full baseline refreshes.
 
 ## What it reads
 

package/docs/gates/checks-mutation.md

@@ -98,6 +98,7 @@ jobs:
       contents: read
       actions: read
     runs-on: [self-hosted, gpu, x64]
+    timeout-minutes: 60
     steps:
       - uses: actions/checkout@v5
         with:

package/docs/gates/checks-night-run.md

@@ -127,15 +127,14 @@ checks-night-run: recorded 42 file score(s) in reports/night-run.json
 
 Only a night workflow the repository writes runs it, after that workflow's full mutation run, its long test tiers and its nightly lint gates.
 
-## Running it at night
+## Running it by hand
 
-A repository runs it from a workflow named `night-run` on a schedule, and starts the same workflow by hand with `gh workflow run night-run`:
+A repository runs it from a workflow named `night-run`, which someone starts with `gh workflow run night-run`.
+The workflow holds no schedule, since [checks-ci-wiring](checks-ci-wiring.md#schedules) refuses one:
 
 ```yaml
 name: night-run
 on:
-  schedule:
-    - cron: "7 22 * * *"
   workflow_dispatch:
 permissions:
   contents: read
@@ -160,6 +159,7 @@ jobs:
           retention-days: 1
   tests:
     runs-on: ubuntu-latest
+    timeout-minutes: 20
     steps:
       - uses: actions/checkout@v5
       - uses: oven-sh/setup-bun@v2
@@ -176,6 +176,7 @@ jobs:
           retention-days: 1
   gates:
     runs-on: ubuntu-latest
+    timeout-minutes: 20
     steps:
       - uses: actions/checkout@v5
         with:
@@ -194,6 +195,7 @@ jobs:
     needs: [mutation, gates, tests]
     if: ${{ !cancelled() && needs.tests.result == 'success' }}
     runs-on: ubuntu-latest
+    timeout-minutes: 15
     permissions:
       contents: read
       actions: read
@@ -228,8 +230,6 @@ jobs:
           retention-days: 90
 ```
 
-The cron starts the run at 22:07 UTC, inside the kit's own night window from 22:00 to 22:30 UTC.
-A repository takes minute 7 of its own tier's 30 minute night window, so repositories do not start together.
 The tests job runs each long tier the repository holds, `live` and `pixel` as [checks-test](checks-test.md#test-tiers) names them, and keeps each JUnit report.
 Each `|| true` lets the job go on to the upload after a failing test, since that test becomes an issue.
 A tier that writes no report fails the report job, because `checks-night-run` cannot read it.
@@ -240,7 +240,7 @@ The download names the artifact by `pattern`, which downloads nothing rather tha
 A full run too long for one job splits into a matrix of shards.
 Each shard uploads its own artifact under the one pattern, and each report gets its own `--mutation`.
 It passes `--gates` only when the gates job succeeded, and the failed gates job still fails the run.
-The concurrency group queues a run started by hand behind the scheduled one, so two runs never file the same finding twice.
+The concurrency group queues a run behind one already going, so two runs never file the same finding twice.
 A dispatch on a branch runs both jobs and lists its findings in the report job's log, and `if-no-files-found: ignore` lets that run upload no record.
 `issues: write` on the report job is the one permission beyond reading the repository and its runs.
 A public repository keeps `runs-on: ubuntu-latest` on every job.

package/docs/gates/checks-release-notes.md

@@ -62,6 +62,7 @@ permissions:
 jobs:
   preflight:
     runs-on: ubuntu-latest
+    timeout-minutes: 10
     permissions:
       contents: read
     steps:
@@ -77,6 +78,7 @@ jobs:
   publish:
     needs: preflight
     runs-on: ubuntu-latest
+    timeout-minutes: 15
     steps:
       - uses: actions/checkout@v5
         with:
@@ -99,6 +101,7 @@ jobs:
   github-release:
     needs: publish
     runs-on: ubuntu-latest
+    timeout-minutes: 10
     permissions:
       contents: write
     steps:
@@ -130,6 +133,7 @@ permissions:
 jobs:
   preflight:
     runs-on: ubuntu-latest
+    timeout-minutes: 10
     permissions:
       contents: read
     steps:
@@ -145,6 +149,7 @@ jobs:
   github-release:
     needs: preflight
     runs-on: ubuntu-latest
+    timeout-minutes: 10
     permissions:
       contents: write
     steps:

package/docs/gates/checks-release-pr.md

@@ -78,8 +78,9 @@ release-pr: https://github.com/acme/widget/pull/12 releases 0.4.0 from 3f2a9c81d
 
 The `release-pr` workflow below runs it on the default branch when someone starts it with `gh workflow run release-pr`.
 The workflow has no schedule, so a release is cut only when someone asks for one.
+A public package that publishes to npm may add one daily `cron` to it instead, such as `"7 3 * * *"`.
 A package published to npm releases each push to `main` through [checks-release-push](checks-release-push.md) instead, with no pull request.
-[checks-ci-wiring](checks-ci-wiring.md#release-schedule) refuses a schedule on any workflow that releases.
+[checks-ci-wiring](checks-ci-wiring.md#release-schedule) refuses a schedule on any other workflow that releases, and one that runs more than once a day.
 
 ## Running it in CI
 

package/docs/gates/checks-release-push.md

@@ -15,7 +15,7 @@ It refuses when `v<version>` of the next version already tags a commit, since a
 It writes the next version into `package.json` and runs `bun run build`, which writes `CHANGELOG.md`.
 It commits both as `chore: release <version>` on top of `HEAD` through the GitHub API, as `checks-release-pr` does.
 It points the branch `release/<branch>` at that commit and dispatches every check workflow its arguments name there.
-It waits up to 45 minutes in all for those workflows to finish on the release commit.
+It waits up to 22 minutes in all for those workflows to finish on the release commit.
 It reads the newest run of each, so a rerun stands in for the run it repeats.
 A failed read of the runs list does not end the wait.
 The wait retries the read at the same interval.
@@ -26,7 +26,8 @@ When all of them pass, it moves `<branch>` to the release commit without a force
 GitHub refuses that update when `<branch>` moved while the checks ran.
 The run then ends cleanly, since the run of the push that moved it releases the new head.
 When the update fails but `<branch>` already holds the release commit, the update landed and the run goes on.
-It then tags the release commit `v<version>`, pushes the tag and dispatches the release workflow on it, and waits up to 45 minutes for that workflow's run on the release commit to finish.
+It then tags the release commit `v<version>`, pushes the tag and dispatches the release workflow on it.
+It waits up to 22 minutes for that workflow's run on the release commit to finish.
 When that run concludes short of success, or does not finish in time, the bin fails, though `<branch>` already holds the release and the tag exists.
 When `HEAD` is itself a release commit, it tags it as [checks-release-tag](checks-release-tag.md) does, and waits for the release workflow it dispatches the same way.
 So a rerun after a failed tag push finishes the release.
@@ -104,7 +105,7 @@ jobs:
   release:
     if: github.ref == 'refs/heads/main'
     runs-on: ubuntu-latest
-    timeout-minutes: 120
+    timeout-minutes: 55
     concurrency:
       group: release-push
       cancel-in-progress: false

package/docs/gates/checks-setup.md

@@ -25,6 +25,8 @@ The workflow always runs `bun run lint`, `bun run typecheck` and `bun run test`.
 A `build` script there also brings a `git diff --exit-code` step.
 Other scripts a `package.json` it finds already holds stay, but the workflow never schedules them.
 The workflow always ends with a `bunx checks-commit-title` step for the pull request title.
+It runs on pull requests alone, so a merge to the default branch does not run the suite a second time.
+A newer push to the same pull request cancels the run in progress.
 A `--private` run pins each job to `${{ vars.CI_RUNS_ON || 'ubuntu-latest' }}`.
 Setting the `CI_RUNS_ON` variable to a self-hosted runner label then lands the jobs there.
 A public run pins each job to `ubuntu-latest`.

package/docs/gates/checks-test.md

@@ -45,13 +45,14 @@ A skipped test or a todo without `skipReason` fails in every environment.
 ## What it reads
 
 `checks-test` reads test source files and the JUnit report written by its own run.
+A pull request run also reads the event file, the git history between the base and the head, the tracked sources, `package.json` and `bunfig.toml`.
 It reads no skip list from `package.json`, only the smoke list.
 It counts a run as `ci` when `CI` is true and as `local` otherwise.
 A local run covers `./tests/unit` plus the smoke list the repository declares.
 The smoke list lives in `package.json` under `checks.smoke` as an array of test file paths.
 A repository with no smoke list runs the unit tier alone outside CI.
 A local run with no unit test and no smoke list runs nothing and passes.
-A `ci` run covers the full default suite.
+A `ci` run covers the full default suite, unless a pull request narrows it, as [Pull request runs](#pull-request-runs) says.
 A smoke entry that names no test file fails the run.
 A smoke entry under `tests/quarantine/`, `tests/live/` or `tests/pixel/` fails the run, since Bun's ignored paths would drop it.
 
@@ -71,6 +72,32 @@ A unit or e2e run keeps Bun's ignored paths, runs only `./tests/unit` or `./test
 
 Files under `tests/quarantine/` are not run or judged, as [checks-test-layout](checks-test-layout.md) says.
 
+## Pull request runs
+
+A `ci` run on a `pull_request` event runs only the test files the pull request reaches.
+It reads the base and head from the event file `GITHUB_EVENT_PATH` names and the changed paths since their merge base from git.
+A test reaches a changed file when it imports it, names its path, runs its `package.json` bin or imports the package by name.
+A test also reaches a file through a test helper or a source that reaches it, at any depth.
+A source reaches only what it imports, so a registry that lists every bin's path does not make each of its importers reach every bin.
+A test that names a fixture's directory reaches each fixture under it.
+A changed test always reaches itself.
+
+A shared file runs the whole suite instead:
+
+- a lockfile, `package.json`, a `*.config.*` or `tsconfig` file, `bunfig.toml`, or a tool pin such as `.bun-version`
+- a file Bun preloads into every test, or a file a preload imports
+- a test helper, which is a file under `tests/` that is neither a test nor a fixture
+- a stylesheet, a font, or a layout under `layouts/` or named `layout.*`
+
+A dependency bump changes `package.json` or the lockfile, so it runs the whole suite in every repository.
+A workflow under `.github/` is not a shared file, since the suite runs under it rather than reading it.
+A pull request that changes no file a test reaches runs no test and passes.
+The run names how many test files it reached, or which shared file made it run the whole suite.
+A change whose paths cannot be read runs the whole suite.
+A run on any other event, such as `workflow_dispatch` for a release, runs the whole suite.
+`--full` and the live and pixel tiers always run whole.
+A narrowed run judges only the skips the files it ran declare.
+
 ## Test tiers
 
 Tests that need a live machine go in `tests/live/`, and tests that need a screen go in `tests/pixel/`.

package/docs/how-to/set-up-a-repository.md

@@ -83,9 +83,13 @@ To run the gates in CI:
    ```yaml
    on:
      pull_request:
+   concurrency:
+     group: ci-${{ github.event.pull_request.number }}
+     cancel-in-progress: true
    jobs:
      checks:
        runs-on: ubuntu-latest
+       timeout-minutes: 30
        steps:
          - uses: actions/checkout@v5
            with:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@avi2dg/checks",
-  "version": "0.64.0",
+  "version": "0.65.1",
   "description": "Deterministic checks shared across a set of TypeScript repositories",
   "author": {
     "name": "avi2d",
@@ -44,6 +44,7 @@
     "src/delivery/release-pr.ts",
     "src/delivery/release-preflight.ts",
     "src/delivery/release-schedule.ts",
+    "src/delivery/schedule-policy.ts",
     "src/delivery/release-publish.ts",
     "src/delivery/release-push.ts",
     "src/delivery/release-tag.ts",
@@ -53,6 +54,7 @@
     "src/testing/block-screens.ts",
     "src/testing/test.ts",
     "src/testing/test-skips.ts",
+    "src/testing/affected-tests.ts",
     "src/core/swc.ts",
     "src/testing/test-report.ts",
     "src/testing/flake.ts",
@@ -76,11 +78,13 @@
     "src/delivery/workflow-references.ts",
     "src/delivery/bun-pin.ts",
     "src/delivery/mutation-job.ts",
+    "src/delivery/job-timeout.ts",
     "src/delivery/runner-policy.ts",
     "src/delivery/secrets.ts",
     "src/delivery/secrets-pack.ts",
     "src/delivery/pr-text.ts",
     "src/delivery/setup.ts",
+    "src/delivery/setup-workflow.ts",
     "src/delivery/gitleaks.ts",
     "src/delivery/gitleaks.toml",
     "src/quality/comment-matchers.ts",

package/src/delivery/ci-wiring.ts

@@ -4,9 +4,11 @@ import { defaultBranch, git } from "../core/git.ts";
 import { runMain } from "../core/main.ts";
 import { ENTRY_POINT, KIT_GATES, type KitGate } from "../core/gates.ts";
 import { findBunPinFaults, formatBunPinReport, readBunPinPolicy } from "./bun-pin.ts";
+import { findLongJobs, formatLongJobReport } from "./job-timeout.ts";
 import { readScheduleFiles, readShellFiles } from "./mutation-job.ts";
 import { findScheduledReleases, formatScheduleReport } from "./release-schedule.ts";
 import { findRunnerFaults, formatRunnerReport, jobRuns, readRunnerConfig } from "./runner-policy.ts";
+import { findScheduledRuns, formatScheduledRunReport } from "./schedule-policy.ts";
 import { invokes, mentions, plainCommand, type Command } from "./shell-command.ts";
 import { findMissingWorkflows, formatMissingReport, isRecord, names, workflowJobs, type Workflow } from "./workflow-references.ts";
 
@@ -65,6 +67,7 @@ const TITLE_LINT = "bunx checks-commit-title";
 const TITLE_CALLS = ["bun src/delivery/commit-title.ts", "./node_modules/.bin/commitlint"];
 const ScriptsManifest = Schema.Struct({
   scripts: Schema.optionalKey(Schema.Record(Schema.String, Schema.String)),
+  private: Schema.optionalKey(Schema.Boolean),
 });
 // Without these a pull_request workflow never sees the commits a pull request pushes.
 const GATING_TYPES = ["opened", "synchronize"];
@@ -271,16 +274,19 @@ export const parseWorkflow = (path: string, text: string): Effect.Effect<Workflo
     catch: (error) => new WiringError({ message: `cannot parse ${path}: ${String(error)}` }),
   });
 
-const readScripts = Effect.fn("readScripts")(function* (root: string) {
+const readManifest = Effect.fn("readManifest")(function* (root: string) {
   const fs = yield* FileSystem.FileSystem;
   const file = (yield* Path.Path).join(root, "package.json");
-  const { scripts = {} } = (yield* fs.exists(file))
+  return (yield* fs.exists(file))
     ? yield* fs.readFileString(file).pipe(
         Effect.flatMap(Schema.decodeUnknownEffect(Schema.fromJsonString(ScriptsManifest))),
         Effect.mapError((cause) => new WiringError({ message: `cannot read ${file}: ${cause.message}` })),
       )
     : ScriptsManifest.make({});
-  return new Map(Object.entries(scripts));
+});
+
+const readScripts = Effect.fn("readScripts")(function* (root: string) {
+  return new Map(Object.entries((yield* readManifest(root)).scripts ?? {}));
 });
 
 export const readDeclaration = Effect.fn("readDeclaration")(function* (root: string) {
@@ -322,17 +328,24 @@ const wiring = Effect.gen(function* () {
   yield* gaps.length > 0 ? Console.error(gapReport) : Console.log(gapReport);
   const missing = findMissingWorkflows(workflows);
   if (missing.length > 0) yield* Console.error(formatMissingReport(missing));
-  const scripts = yield* readScripts(root);
+  const manifest = yield* readManifest(root);
+  const scripts = new Map(Object.entries(manifest.scripts ?? {}));
+  const visibility = yield* readVisibility;
   const runs = workflows.flatMap((workflow) => workflowJobs(workflow).flatMap(([, job]) => jobRuns(workflow, job)));
   const runners = yield* readRunnerConfig(root);
-  const faults = findRunnerFaults({ visibility: yield* readVisibility, scripts, files: yield* readShellFiles(root, scripts, runs), runners }, workflows);
+  const faults = findRunnerFaults({ visibility, scripts, files: yield* readShellFiles(root, scripts, runs), runners }, workflows);
   if (faults.length > 0) yield* Console.error(formatRunnerReport(faults));
   const bunFaults = findBunPinFaults(yield* readBunPinPolicy(root, workflows), workflows);
   if (bunFaults.length > 0) yield* Console.error(formatBunPinReport(bunFaults));
   const scheduleFiles = yield* readScheduleFiles(root, scripts, runs);
-  const scheduled = findScheduledReleases(workflows, { scripts, files: scheduleFiles });
+  const owner = { visibility, publishes: manifest.private !== true };
+  const scheduled = findScheduledReleases(workflows, { scripts, files: scheduleFiles }, owner);
   if (scheduled.length > 0) yield* Console.error(formatScheduleReport(scheduled));
-  return gaps.length === 0 && faults.length === 0 && missing.length === 0 && bunFaults.length === 0 && scheduled.length === 0;
+  const scheduledRuns = findScheduledRuns(workflows, { scripts, files: scheduleFiles }, owner);
+  if (scheduledRuns.length > 0) yield* Console.error(formatScheduledRunReport(scheduledRuns));
+  const longJobs = findLongJobs(workflows);
+  if (longJobs.length > 0) yield* Console.error(formatLongJobReport(longJobs));
+  return [gaps, faults, missing, bunFaults, scheduled, scheduledRuns, longJobs].every((found) => found.length === 0);
 });
 
 if (import.meta.main) runMain("ci-wiring", wiring);

package/src/delivery/job-timeout.ts

@@ -0,0 +1,30 @@
+import { workflowJobs, type Workflow } from "./workflow-references.ts";
+
+export type LongJob = {
+  readonly location: string;
+  readonly fault: string;
+};
+
+const LIMIT = 60;
+const SET = `set timeout-minutes to a number of at most ${LIMIT}`;
+
+function timeoutFault(timeout: unknown): string | undefined {
+  if (timeout === undefined) return "the job sets no timeout-minutes, so a hung run holds its runner for GitHub's 360 minute default; " + SET;
+  if (typeof timeout !== "number") return "its timeout-minutes cannot be shown to stay within an hour before the run; " + SET;
+  return timeout > LIMIT ? `its timeout-minutes of ${timeout} lets the job run for hours; ${SET}` : undefined;
+}
+
+// A job that calls a reusable workflow cannot set timeout-minutes, and the called workflow's own jobs are judged where it lives.
+export function findLongJobs(workflows: readonly Workflow[]): readonly LongJob[] {
+  return workflows.flatMap((workflow) =>
+    workflowJobs(workflow).flatMap(([id, job]) => {
+      if (job["uses"] !== undefined) return [];
+      const fault = timeoutFault(job["timeout-minutes"]);
+      return fault === undefined ? [] : [{ location: `${workflow.path} job ${id}`, fault }];
+    }),
+  );
+}
+
+export function formatLongJobReport(jobs: readonly LongJob[]): string {
+  return [`ci-wiring: ${jobs.length} job(s) can run for hours:`, ...jobs.map(({ location, fault }) => `  ${location}: ${fault}`)].join("\n");
+}

package/src/delivery/release-push.ts

@@ -12,7 +12,7 @@ const LABEL = "release-push";
 const USAGE = "usage: release-push.ts <release-workflow> <workflow>...";
 const UNTAGGED = "tag the release commit with checks-release-tag, whose refusal says what to fix";
 const POLL = Duration.seconds(15);
-const POLLS = 180;
+const POLLS = 88;
 
 const Run = Schema.Struct({ path: Schema.String, status: Schema.String, conclusion: Schema.NullOr(Schema.String), html_url: Schema.String });
 type Run = typeof Run.Type;