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:

endpoint status
GET /repos/objectstack-ai/objectstack/branches/main/protection 403 Resource not accessible by integration
GET /repos/objectstack-ai/objectstack/rulesets 200 — one active ruleset, main, id 12119582, updated_at 2026-08-18T03:26:48Z
GET /repos/objectstack-ai/objectstack/rulesets/12119582 200 — 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions