ci: basic tier named as the merge requirement + event bots consolidated into repo-sweeper (every 15m)

.github/ci-policy.md

@@ -19,6 +19,28 @@ Highest class wins when a change spans classes.
 | 3 — elevated | lockfiles, `go.mod`/`go.sum` roots, `flake.nix`/`flake.lock`, build definitions, `.github/workflows/**`, shared/core libraries | class 2 + compile check of affected packages |
 | 4 — nix expressions | `**.nix` | class 1 + parse/eval of the changed files only (never full flake check on a PR) |
 
+## Merge requirement
+
+**Merge requirement: the basic-validation (PR) tier only. The full
+suite runs on main and is NOT a merge gate.**
+
+The basic tier's checks are named so the tier is recognizable in the
+check list — they carry the `basic` prefix:
+
+- `basic typecheck` (workflow `check`) — typecheck + changed-file lint
+- `basic affected packages` (workflow `test`) — affected-package detection
+- `basic unit (<os>)` (workflow `test`) — unit tests of affected packages
+- `e2e (<os>)` (workflow `test`) — the aggregator only on PRs: it
+  reports green when the e2e suite is tier-skipped, so the name stays
+  stable for branch rules; the suite itself is main-tier
+
+Workflow names (`test`, `check`, `nix-eval`) are deliberately NOT
+renamed: the Phase 3 watcher (`main-broken.yml`) references them by
+name in its `workflow_run` trigger. Job display names carry the tier
+label instead. If branch rules ever require checks by name, require
+the `basic`-prefixed names above — the full main-tier jobs (`build`,
+`e2e` suites) must never become merge requirements.
+
 ## How the classes map to this repo's workflows
 
 - `check` (typecheck + changed-file lint) — the PR tier's core; runs on
@@ -58,11 +80,19 @@ concurrency:
 
 Publish/release workflows extend the `run_id` keying to tag pushes and
 manual dispatches, so a release is never cancelled mid-publish.
-Issue/PR bot workflows (`duplicate-issues`, `triage`, `review`,
-`opencode`, `pr-management`, `pr-standards`) keep per-issue/per-PR
-groups with `queue: max` and `cancel-in-progress: false` so bursts
-queue per item instead of replacing each other. Scheduled singleton
-and deploy workflows keep `cancel-in-progress: false` deliberately.
+Issue/PR management is NOT event-triggered: `repo-sweeper.yml` runs
+every 15 minutes (`*/15 * * * *`, single live run, cancel-in-progress)
+and performs all management duties in one pass — contributor labels,
+issue compliance + duplicate checks, compliance rechecks, triage, the
+72-hour compliance closes, and the daily stale-issue / low-reaction-PR
+closers (gated to their original 02:00 / 22:00 UTC windows). It
+replaced `pr-management`, `duplicate-issues`, `triage`, `close-issues`,
+`close-prs` and `compliance-close`. Event-based only where a human
+waits synchronously: `opencode` (`/oc`, `/opencode` mentions) and
+`review` (`/review` command). `pr-standards` stays a
+`pull_request_target` validation workflow (PR standards / template
+compliance). Scheduled singleton and deploy workflows keep
+`cancel-in-progress: false` deliberately.
 Never pair `queue: max` with a `cancel-in-progress` expression that
 can evaluate true for `issues`/`pull_request_target` events — GitHub
 rejects that combination and the workflow never runs.

.github/workflows/check.yml

@@ -22,7 +22,7 @@ permissions:
 jobs:
   check:
     timeout-minutes: 15
-    name: typecheck
+    name: basic typecheck
     # RUNNER-SWITCH: Blacksmith (commented out 2026-10-18): runs-on: blacksmith-4vcpu-ubuntu-2404
     runs-on: ubuntu-24.04
     steps: