feat(ci): make this repo's own suite a gating context, and pin what could un-require it [DO NOT MERGE: gate refused]

[NSchatz]

CI-REQUIRED-CHECKS, the org / .github leg.

The item

#39 named a PRE-EXISTING and left it: ruleset ci-required-checks did not require
self-check.yml's scripts job, so this repository's own unit suite ran on every pull request and
could block none of them. A green check that cannot block a merge is documentation.

What this changes

scripts becomes a required context. The precondition was checked rather than assumed, in this
order:

1. self-check.yml has no paths: filter and no job-level if:, so the job is unconditional. The
   standing record read it as path conditional; it is not, and never was. It simply postdated three
   branches that have since gone, which is the corrected cause and the one that makes this reversible
   without a workflow change.
2. The job has completed on main at 41f883e. A context required before its workflow has completed
   on main leaves every pull request pending and unmergeable with nothing saying why.
3. scripts was read off the real pull_request check runs of every open pull request, and off the
   last twelve consecutive pull_request runs of the workflow, all of which carry both jobs.
   Contexts are read off check runs here, never off a workflow's name:: this workflow is titled
   "Self-check" and its contexts are the bare job ids.

test/self-check.test.mjs pins what a ruleset cannot see. Nothing inside a repository can observe
its own ruleset, so two edits un-require a job with no ruleset change and no error anywhere:

• Renaming the job id detaches the ruleset entry silently. The old context is then required and
  emitted by nothing, so every pull request sits pending, which is worse than red because nothing says
  why. The job ids are pinned, so a rename reds in the pull request that made it, beside a comment
  saying to move the ruleset entry too.
• Narrowing what selects the work. A required job gates its steps, not the selection those steps
  operate on. node --test "test/*.test.mjs" exits 0 as happily over one file as over all of them.
  The glob is read out of the workflow and compared against the test files actually on disk, so this
  is a real comparison and not a spelling check.

A paths: filter and a job-level if: are refused too, on a reason that needs no theory about how a
skip resolves: a context that does not run on every pull request cannot gate every pull request.

What a skipped required context does to a merge is deliberately stated nowhere in this change.
This repository has not settled that against a primary source and a live run, deid's ci.yml
records the same question as open against run-actionlint and says not to change that input until it
is settled, and whatever the answer is it governs thirteen repositories at @main. It is raised as
its own item rather than answered in a comment here.

Every assertion was mutation checked. Narrowing the glob, adding paths:, adding a job if:,
dropping the push trigger, unquoting the glob, dropping the checkout, renaming the job, appending
--test-name-pattern, replacing the command with echo, dropping a test file into a subdirectory,
and a ** widening that does not actually cross a separator all red, each on the assertion that names
it. A correct test/**/*.test.mjs widening passes, which is deliberate: the file's own comments
tell a future author to widen the glob when a directory of tests appears, and a guard that reds on its
own documented remedy gets deleted rather than obeyed.

The glob translator follows node's rule rather than a guess, measured on a real run over the same
tree: test/**/*.test.mjs selects 347 tests and test/**.test.mjs selects 346, so ** crosses a
separator only as a whole segment. Reading a bare ** as crossing one fails in the dangerous
direction, reporting a selection wider than the one CI runs.

The case that asserts the invocation owns the shape (node --test, one quoted argument, no
selector smuggled in beside it). Whether the selection is complete is the next case's job. Pinning
the glob's literal value in the first would have conflated the two and reded on a widening as loudly
as on a narrowing.

The ci / prepublish census, recorded rather than fixed

Turning both pre-publish layers on by default made them run in all thirteen callers. It did not
make them block in any. The layers live in their own job, so ci / prepublish is a separate
check-run context, and a caller whose ruleset requires the verify matrix and ci / actionlint does
not thereby require it: a red pre-publish gate shows a red X and the merge button stays green.

Censused 2026-08-07 against real pull_request check runs rather than workflow names. All thirteen
callers emit ci / prepublish, as expected now that both layers default on and no caller passes
either input. cli is the only one whose ruleset requires it. That is one line per caller, in
that caller's own ruleset, and it is not reachable from this repository, so it is written down with
its derivation command instead of being fixed here. It belongs to each caller's own
CI-REQUIRED-CHECKS pass.

The backlog's reading that cli requires "only the two verify matrix contexts plus actionlint" is
stale: cli is in fact the one caller that does require the pre-publish context.

No context count is written anywhere, and nothing asserts a context IS required

Nothing in a repository can observe its own ruleset, so a list or a count goes stale the next time
this workflow grows a job, and prose asserting the current state is the same defect wearing different
clothes. Every addition here states the rule and gives the derivation command instead; the test file
says outright that whether a context is required is not knowable from inside a repository, so nothing
in it asserts that.

The long "how to require a context" procedure previously duplicated in no-emdash.yml is replaced by
a pointer to the one place it is now set out in full. The precondition itself is short and
load-bearing at each site, so it stays stated at each; only the procedure is stated once. That file
keeps the half that is genuinely local to it: which of its two jobs may ever be required.

No workflow logic moved

ci.yml and release.yml, the two called at @main by thirteen repositories, are untouched.
self-check.yml and no-emdash.yml were parsed with a real YAML parser at base and at head and
flattened to leaf paths. Both are identical leaf for leaf: comments only, no job id, step, condition,
run: body, uses: ref, input or output name moved.

Gate

scripts/verify.sh .github has no ladder here (no lockfile) and exits 66, as documented. The real
gate, run by hand:

• node --test "test/*.test.mjs": 346 pass, 0 fail (339 before this change).
• actionlint -shellcheck shellcheck: clean, exit 0.
• node scripts/check-no-emdash.mjs: clean over every tracked file, none exempt.

Deliberately not done here

• no-emdash-messages is not required and must not be, per the standing exemption. Dependabot
  pastes the dependency's upstream release notes into the pull request body, and dependabot.yml
  keeps a standing weekly github-actions schedule, so such a pull request arrives on someone else's
  clock indefinitely.
• The twelve callers that emit ci / prepublish without requiring it. Reported above, not
  changed: each is that repository's own ruleset.
• The resolvedSelection() divergence (vitest list --filesOnly in the gate against vitest run
  in a different CI job) belongs to whichever repository owns that policy, not here.
• cli's release.yml comment, which carries a wrong context count and a claim about Version PRs
  arriving with zero check runs. That claim was true when written and was wrong for about six days,
  not months, which is exactly why it is its own slice with the dated instance kept.
• The open Dependabot pull requests, including the codeql-action init / upload-sarif pair.
  A set that must move together has to land on one sha in one pull request, and that is not this one.

🛑 DO NOT MERGE WITHOUT A HUMAN DECISION

Three gate-refuter passes, the ADR 0016 maximum, and the last one refused. Reported as they
came, including the refusals.

• Pass 1 on 7f14fe7: NOT REFUTED, four minor INTRODUCED findings, no blockers.
• Pass 2 on 5b81279: REFUTED, one INTRODUCED major. The remedy for pass 1 had claimed a
  job-level if: strands a pull request while a step-level one goes green. GitHub documents that a
  skipped job reports success and does not prevent a merge even as a required check, so the contrast
  was false. This repo ships ci.yml with actionlint behind if: inputs.run-actionlint while
  ci / actionlint is a required context in caller rulesets, so a maintainer setting that input
  false was being told to expect a loud strand across thirteen repos.
• Pass 3 on 3bc2dad: REFUTED, INTRODUCED major, called a blocker. The skip-semantics
  theory had been deleted, but a claim that the page and the file now state nothing about it was
  written in its place, and both files still did, further down. A rewrite wearing a deletion's
  clothes.

7a762d9 is the ADR 0016 cut-back and it is UNGRADED, because there is no fourth pass. It is
purely subtractive: every sentence characterising what a skipped required context does to a merge is
deleted, and no sentence replaces it, including the meta-sentence that claimed they were gone. It
also deletes the two pre-existing copies of the same false claim, here and in no-emdash.yml.

The guard, the ruleset act and the census are unaffected by any of that and were never the subject of
a finding. Every finding across all three passes was about prose.

The question that has to be settled by a human, in its own change, and that this pull request
deliberately no longer answers: what does a skipped required context do to a merge? deid's
ci.yml records the same question against run-actionlint and says not to change that input until
it is settled. It is live across thirteen repos through ci.yml's if: ${{ inputs.run-actionlint }}.