You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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
403Resource 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
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.
Not a mechanical edit, which is why this is a card:
Token dependence. The 200 above was measured from one seat. Whether the token available to a CI job can read the ruleset is a separate measurement — GITHUB_TOKEN in a workflow is not this seat's token, and a gate that goes red because it cannot read the ruleset would be worse than one that never tried. The obvious shape is: read it when reachable, and treat unreachable as "not verified" stated in the output, never as a pass (check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690).
The header, the lint.yml step comment, and the prescription all have to move together, or the next reader inherits the retired premise from whichever copy they open.
Filed unassigned by the
domain:devxos-dev seat while landing #9595 / PR forcross-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):and again in the failure prescription (line 855):
lint.yml's step comment repeats it: "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:
GET /repos/objectstack-ai/objectstack/branches/main/protectionResource not accessible by integrationGET /repos/objectstack-ai/objectstack/rulesetsmain, id12119582,updated_at 2026-08-18T03:26:48ZGET /repos/objectstack-ai/objectstack/rulesets/12119582rules[], includingrequired_status_checksThe
required_status_checksrule from that second call, verbatim in list order:strict_required_status_checks_policy: false. The same ruleset also carriesdeletion,non_fast_forward,merge_queue(SQUASH,grouping_strategy: ALLGREEN,check_response_timeout_minutes: 60) andpull_request(0 required approvals) rules. Only one ruleset exists, and it is repository-sourced, so no organization ruleset is being missed.Why it matters
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 againstREQUIRED_CONTEXTS, and fail on a registry row whose context is absent from the live set.needs-user-decisioncard 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 whetherBuild Docs/Console Pin Gatewere 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.)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 TheESLintrequired context carries ~54check:*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:
GITHUB_TOKENin a workflow is not this seat's token, and a gate that goes red because it cannot read the ruleset would be worse than one that never tried. The obvious shape is: read it when reachable, and treat unreachable as "not verified" stated in the output, never as a pass (check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690).lint.ymlstep comment, and the prescription all have to move together, or the next reader inherits the retired premise from whichever copy they open.Ref: #5617 · #6865 · #9325 · #9495 · #9533 · PR #9523
Generated by Claude Code