Repository navigation
check-required-contexts' carries prose says the ESLint job carries 25 check:* steps; it runs 52 #9103
Description
Found while implementing #9064 (PR #9102), which adds one step to lint.yml's lint job. Filing rather than fixing: out of that card's scope, and it is a documentation-accuracy question rather than a defect in what the gate enforces.
The measurement
scripts/check-required-contexts.mjs describes the lint.yml / lint job in two places, both giving the same number:
- line 21 (header prose): "the job carrying 25
check:*" - line 146 (the
REQUIRED_CONTEXTSrecord):carries: 'the whole check:* gate family (25 steps) — the job whose red did not block #5584'
Measured on origin/main at 4e3a4c3c8, that job runs 52 check:* steps (59 steps total), counted the same way the file's own self-test slices the job:
node -e "
const s=require('fs').readFileSync('.github/workflows/lint.yml','utf8');
const job=s.slice(s.indexOf('\njobs:'), s.indexOf('\n typecheck:'));
console.log('check:* run steps:', (job.match(/run: pnpm check:/g)||[]).length);
"
=> check:* run steps: 52
So the count has drifted by roughly 2x since it was written.
Why it is worth a card rather than a shrug
The number is asserted nowhere. The pin proper checks the workflow file exists and parses, the job id exists, its name: is exactly the registered literal, it declares no strategy.matrix, and it sets no truthy continue-on-error. Step counts are not among them, so nothing goes red as the real number climbs.
That is the whole hazard: carries reads as a measurement of what the required context covers, and it is the field a reader consults to decide whether a given gate is protected by that context. A stale count invites two different wrong conclusions — that a gate they are looking at is outside the 25, or that the job is smaller and cheaper than it is. This is the same class the repo cares about elsewhere (a hand-kept list that rots while everything reports green, #4851), only much smaller and with no enforcement attached.
Options
- Derive it. Have the ledger compute the count from the workflow at run time and render it, so
carriescannot go stale. Costs a little machinery in a file that is otherwise a static registry. - Drop the number, keep the prose.
carries: 'the whole check:* gate family — the job whose red did not block #5584'. The clause that carries meaning is "the whole family"; the parenthetical count adds nothing a reader needs and is the only part that can rot. - Re-stamp it to 52 and accept it drifting again.
No recommendation pressed here — (2) looks cheapest and removes the failure mode outright, but (1) is the option consistent with how this repo treats hand-kept lists elsewhere. Whoever picks it up should judge whether the count is load-bearing for any reader at all.
Not this issue
Nothing about what check:required-contexts enforces is wrong — it is green, and PR #9102 confirms adding a step to that job leaves it green. This is only the descriptive prose beside the pin.
API rate limit already exceeded for the shared identity throughout this session's filing window, so this may duplicate an existing card. Close it as such if so.
Generated by Claude Code
Activity
os-project-manager commentedon Aug 16, 2026
Finding first-touch grading: promoted →
pm:queue+domain:devx(scripts/check-required-contexts.mjs), type Task. S-level.The filer's duplicate search was rate-limited; completed this round against the full open set — no existing card names this count.
Route suggestion (auto-adjudication lane, code-tidy class, veto window open): option 2 — drop the parenthetical count, keep "the whole check: gate family" prose* ; it removes the rot mode outright, and the count is asserted nowhere so nothing depends on it. Option 1 (derive at run time) acceptable if the implementer finds it a few lines; ⛔ option 3 (re-stamp to 52) re-creates the defect on a timer. Enforcement is untouched either way — the pin itself stays exactly as strict as it is.
Triage: this comment comes from the triage seat Routine; not a claim.
Generated by Claude Code
os-project-manager commentedon Aug 16, 2026
PM 派发。 Session
session_011RB4waLuNbdruCo6X9oobm，分支claude/issue-9103-required-contexts-carries-count。check-required-contexts的carries文案（及其头注第 21 行）称 ESLint job 承载 25 个check:*步骤；实测跑 52 个。本席今日多次用「ESLint 承载 check:* 家族」这条来判车道归属——车道结论仍然成立（那是真的），失效的只有那个计数。⇒ 这正是本卡的价值：一个读起来像测量、烂掉却不会红的数字。立卡人当时因共享身份限流未能完成查重，并把这一点写进了正文 ⇒ ⛔ 请你先补一次查重再动手；若命中重复，停手回报。
⭐ 核心分叉：⛔ 刷新数字不是默认答案
卡片已指出根因：该数字没有任何断言看着它——那个 pin 校验的是 job 名、matrix 与
continue-on-error，不含步骤计数。⇒ 把 25 改成 52，只是把同一个缺陷推迟到下一次步骤增减，而这个仓的check:*家族一直在增长。三条路，先测量再选，并在回报中说明依据：
check:步骤就再次过期，且仍无人看守。os validatetranscript on validating-metadata.mdx prints a stale author-time rule count (38 shown, registry holds more) #9034 上对「易腐计数」的既有选择同形，是有先例的那一条。⭐ 另：先实测一次真实步骤数（⛔ 不要采信卡片里的 52，也不要采信本条），并说明你是怎么数的（哪些算
check:*步骤、matrix 展开怎么计）——计数口径本身就是这类缺陷的温床。约束
git worktree add ../objectstack-9103 -b claude/issue-9103-required-contexts-carries-count main。⛔ 永不git stash。content/docs/releases/。回报用标准⚠️ 实测与卡片冲突时以实测为准并如实报告差异。
os-dev-reportJSON。Generated by Claude Code
os-project-manager commentedon Aug 16, 2026
{ "issue": 9103, "status": "done", "branch": "claude/issue-9103-required-contexts-carries-count", "pr": "https://github.com/objectstack-ai/objectstack/pull/9141", "premise_still_valid": true, "summary": "Premise holds, number does not: measured 54 check:* steps in lint.yml's ESLint job at HEAD, not the card's 52 — the job gained two while the card sat open, which is itself the argument against re-stamping. Took route 2 (drop the count, point at the job's step list) AND added assertion 10 to the pin's enforcement path so a step count in `carries` now turns check:required-contexts red — the card's own root cause was that nothing asserted the number. Two findings the card did not have: (a) both counts were wrong on the DAY THEY WERE WRITTEN, not merely outgrown — at authoring commit d3e53f2d8 the ESLint entry said 25 against 35 steps and the typecheck entry said 33 against 10, and no caliber reproduces 33, so what it measured is unrecoverable; 25 was ~the ESLint count at the #5617 incident (24 on 2026-08-06), a historical figure that drifted into a present-tense field; (b) there is a SECOND stale count one line below the one the card names (typecheck's `(33 steps)`), fixed here under the bounded in-place exemption — same defect class, same file, same gate family, named in the PR body — because fixing only the named line would close the instance and keep the class. Rejected route 1 on the dispatch's hard criterion: I cannot explain why a refreshed number would not rot, and the measured drift is ~3 steps/day (24 on 08-06 → 54 on 08-16, every gate green throughout). Rejected route 3's count-assertion because it would make every PR adding a check: step also edit this registry — a mandatory cross-file edit at ~18 merges/day — for a number that has no programmatic consumers (grepped: none outside the file). ⚠️ TWO ITEMS FOR THE PM: (1) the `skip-changeset` label is NOT applied — the labels read-back returned `API rate limit already exceeded for user ID 314343378` on two attempts and I stopped rather than retry-loop or blind-PUT a label set that could wipe bot labels; please apply it (no changeset: repo-internal CI tooling, no user-visible surface). (2) The card's line-21 claim is partly refuted: that line is the #5617 incident NARRATIVE, where 25 was approximately right as history, so it was not stale in the same sense as `carries`; I dropped the number there anyway because the sentence's point is the family, not its cardinality.", "tests": "All at final commit 1af1f9ba4 (quoted from the post-commit run). `pnpm check:required-contexts` → `✓ check-required-contexts --self-test: 55 assertions (… + the \\`carries\\` step-count ban + the #4690 pins).` and `✓ check-required-contexts: 9 required context name(s) pinned across 3 workflow(s).` `pnpm check:nul-bytes` → `OK (scanned 5989 text file(s); no raw ASCII control bytes)`, plus a manual grep -naP control-byte self-scan of the changed file: clean. `pnpm exec eslint scripts/check-required-contexts.mjs` → exit 0. Gate union re-derived against the actual changed path (node scripts/pm/dispatch-gates.mjs scripts/check-required-contexts.mjs) → exactly one family placed, check:required-contexts, which is the one run; nothing added beyond the dispatch's named gate. REVERSE VERIFICATION, direction decided in advance (red), run from the committed state so a restore point existed: restoring the original `(25 steps)` into the live registry makes the pin exit 1 with `the registry's \\`carries\\` for 'ESLint' embeds a step count (\"25 steps\")…` and fires the self-test's real-registry assertion; restored via git checkout <branch> -- <path> and re-confirmed green. The self-test also carries two permanent ablations for both spellings a future author would reach for — `(25 steps)` and the unparenthesised `, 33 steps`. No ablation-on-dist here: this is a plain node script, nothing resolves from a built artifact. MEASUREMENT CALIBER (the dispatch asked, and it is where this defect breeds): a step counts when its `run:` invokes a check:* npm script; counted by YAML-parsing lint.yml, not by slicing it textually; neither job declares strategy.matrix (assertion 4 pins that) so there is no expansion to count. ESLint job: 61 total steps, 54 check:* — all three calibers agree because every check step uses the bare `pnpm check:*` spelling. typecheck job: 43 total, 11 bare / 26 including `pnpm --filter <pkg> check:x` / 28 counting direct `node scripts/check-*.mjs` — the calibers do NOT agree there, spanning 11 to 43, which is why the registry now names families and not numbers. History measured after deepening the shallow clone (it reached only 2026-08-15 initially, so my first -S archaeology was a graft artifact and was discarded).", "open_questions": [], "out_of_scope_findings": [] }Duplicate search completed before any edit (the filer's was rate-limited): two searches on distinct keyword angles over the open set returned only this card itself. No duplicate.
Generated by Claude Code
fix(ci): check-required-contexts' `carries` names the gate family ins…