Skip to content

check-required-contexts.mjs reasons from "no agent seat can read the ruleset" — measured false: the rulesets API answers 200, and the required SET is readable #9642

Description

@os-steve

Filed unassigned by the domain:devx os-dev seat while landing #9595 / PR for cross-repo-issue-closer.yml. Recording, not claiming — the seat needed the live required-set to re-derive that card's red/green judgement and found the premise wrong on the way. Dedup-searched (workflow name, "ruleset", "required set", "403"): #9533 and #6991 are the neighbours, and neither states this.

The premise, quoted

scripts/check-required-contexts.mjs, header (line 79):

Settings → Rulesets, and no agent seat can read it: GET /repos/objectstack-ai/objectstack/branches/main/protection answers HTTP 403

and again in the failure prescription (line 855):

(Settings → Rulesets is maintainer-only; the API answers 403 to every agent seat), so a legitimate rename …

lint.yml's step comment repeats it: "⚠️ It cannot verify the required SET itself — Settings → Rulesets is unreadable from every agent seat (403)".

The measurement (2026-08-18, this container, ordinary agent seat)

The endpoint named in the header does answer 403. It is also not the ruleset endpoint — it is the classic branch-protection endpoint, which this repository does not use. The rulesets endpoints answer 200:

endpointstatus
GET /repos/objectstack-ai/objectstack/branches/main/protection403Resource not accessible by integration
GET /repos/objectstack-ai/objectstack/rulesets200 — one active ruleset, main, id 12119582, updated_at 2026-08-18T03:26:48Z
GET /repos/objectstack-ai/objectstack/rulesets/12119582200 — full rules[], including required_status_checks

The required_status_checks rule from that second call, verbatim in list order:

TypeScript Type Check
Test Core
Dogfood Regression Gate
Build Core
Temporal Conformance (live PG + MySQL)
Lint & Repo Gates

strict_required_status_checks_policy: false. The same ruleset also carries deletion, non_fast_forward, merge_queue (SQUASH, grouping_strategy: ALLGREEN, check_response_timeout_minutes: 60) and pull_request (0 required approvals) rules. Only one ruleset exists, and it is repository-sourced, so no organization ruleset is being missed.

Why it matters

  1. The gate's stated blind spot is not actually blind. The script says at length that it can assert only the repo-side half — the job name: literals — because the required SET is unreadable. It is readable. The half of 红的 ESLint job 没有拦住合并:PR #5584 在 ESLint 已红 19 分钟的情况下过队合入 —— main 的 required-status-check 集需要维护者核查 #5617 that has no signal today (a context silently dropped from Settings leaves the whole family advisory) is mechanically checkable: read the ruleset, diff it against REQUIRED_CONTEXTS, and fail on a registry row whose context is absent from the live set.
  2. It closes an open needs-user-decision card without a maintainer look.finding: required-context registry pins Build Docs and Console Pin Gate, absent from the maintainer's 2026-08-18 six-item required-set reading #9533 asks whether Build Docs / Console Pin Gate were removed from the ruleset after 2026-08-09 or whether the maintainer's six-item reading was partial, and states — from this same premise — that "only the maintainer can tell them apart". The live ruleset above is the answer: the six-item reading is complete, and those two contexts are genuinely absent. (Comment with the same measurement posted on finding: required-context registry pins Build Docs and Console Pin Gate, absent from the maintainer's 2026-08-18 six-item required-set reading #9533.)
  3. A stale premise in a gate header is load-bearing prose. It is quoted in lint.yml, in finding: required-context registry pins Build Docs and Console Pin Gate, absent from the maintainer's 2026-08-18 six-item required-set reading #9533, and in the The ESLint required context carries ~54 check:* gates, so every one of their failures mis-routes its own diagnosis — and the rename needs a Settings change no agent seat can make #9325 rename procedure, all of which reason from "unreadable" to "maintainer-present sitting".

What a fix would have to be careful about

Not a mechanical edit, which is why this is a card:

Ref: #5617 · #6865 · #9325 · #9495 · #9533 · PR #9523


Generated by Claude Code

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions