From 1004874f206f4f1ac107837d96177814338ce3d0 Mon Sep 17 00:00:00 2001 From: Seongho Bae Date: Sun, 6 Sep 2026 22:30:48 +0900 Subject: [PATCH] docs(claude): replace the required-context count with the measured list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CLAUDE.md said `.github` uses "classic branch protection with 14 named required contexts". The live endpoint returns 12. gh api repos/ContextualWisdomLab/.github/branches/main/protection \ --jq '.required_status_checks.contexts | length' 12 Measured 2026-09-06: CodeQL compatibility analysis (actions), CodeQL compatibility analysis (python), Detect CodeQL languages, coverage-evidence, dependency-review, noema-review, opencode-review, osv-scan, required-workflow-bootstrap, scan-pr-queue, scorecard, trivy-fs. Not "14 became 12". `git log -S "named required contexts" -- CLAUDE.md` returns exactly one commit, 7d093881 (#1766), and the sentence has never been revised since. Branch-protection edits leave no trace in git and the REST API exposes no history, so whether the count was wrong when written or two contexts were later removed is not recoverable. The text says so instead of guessing, so a later reader does not infer a removal that has no evidence. Records the list rather than a bare number: a count cannot be checked against anything, while a list can be diffed against the endpoint and shows *which* context drifted. The bare number went stale unnoticed for three days. The count also cannot be corroborated from inside the repository. CHANGELOG line 52 already says "0/12 required contexts", but that figure came from 7f4c5e3e (#1937) — the same author's own census — so it is the same measurement read twice, not an independent source. The protection endpoint is the only authority here, which is exactly why the text tells the reader to re-read it. Evidence: - uvx ruff check --select F821 scripts/ci tests: All checks passed - full suite: 2956 passed, 0 failed - coverage: TOTAL 100%; interrogate: PASSED (minimum 100.0%) - no test pins this prose: `git grep '14 named\|named required contexts'` over tests/ and scripts/ returns nothing Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 30db1fc23b..6ab603fffd 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -160,10 +160,19 @@ repeatable compile command. in each target repository's context and discards its `paths`, `paths-ignore`, `branches`, and `types` there (confirmed live: `bandscope` has no local `codeql-pr.yml`/`strix.yml`/ `security-scan.yml`, yet ruleset-injected runs of all three exist). `.github` is excluded from - that ruleset and instead uses classic branch protection with 14 named required contexts, where a - path-filtered workflow leaves its context Pending forever. Never add a trigger-level filter to a - required workflow; skip at job level via a `changed-scope` gate job instead, and always keep one - job with no output-dependent `if:` so the run concludes `success` rather than `skipped`. See + that ruleset and instead uses classic branch protection with a fixed list of named required + contexts, where a path-filtered workflow leaves its context Pending forever. Measured from + `branches/main/protection` on 2026-09-06, that list is these 12: `CodeQL compatibility analysis + (actions)`, `CodeQL compatibility analysis (python)`, `Detect CodeQL languages`, + `coverage-evidence`, `dependency-review`, `noema-review`, `opencode-review`, `osv-scan`, + `required-workflow-bootstrap`, `scan-pr-queue`, `scorecard`, `trivy-fs`. Re-read the endpoint + rather than trusting this list: branch-protection edits leave no trace in git, so a stale list + here cannot be detected by reading the repository. This sentence previously said "14 named + required contexts" and had never been revised since `7d093881` (#1766) introduced it; that is a + correction of an unverifiable count, **not** evidence that two contexts were removed. Never add a + trigger-level filter to a required workflow; skip at job level via a `changed-scope` gate job + instead, and always keep one job with no output-dependent `if:` so the run concludes `success` + rather than `skipped`. See `docs/doctoring/required-workflow-path-filter-boundary.md`. - **Narrowing a PR does not carry its delta automatically.** When a large PR is split into successors, diff the union of the successors against the original before treating the supersession