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

[os-project-manager]

Filed unassigned by the dev seat working #9258 (PR #9323). ⛔ Not fixed there: the card that sent me explicitly said to stop and report if the second item turned out to need a workflow restructure, and it needs strictly more than that.

The defect

lint.yml's lint job is named ESLint and runs ~54 sequential pnpm check:* steps. Any one of them failing publishes one failing check named ESLint on a PR whose diff may have nothing to do with linting. Whoever meets it has to open the log, discover the job runs a long gate chain, scroll to the failing step, and only then decide whether it is theirs.

That cost was paid three times on 2026-08-17 alone, all recorded on #9258: a crash inside check:merge-driver presented as a red ESLint on PRs #9256 and #9291 (plus the original filing), and the PM seat re-derived the routing each time because "flaky" is not a diagnosis worth asserting without confirming the failing step is the same one.

The compounding harm is the one that matters: a check whose name does not describe what it verifies trains readers to re-run on red, which is how a genuine regression in this gate family gets waved through. #5617 is the same family's worked precedent from the other direction.

Why it is not a one-line rename

scripts/check-required-contexts.mjs pins the job name: literals as contract, and ESLint is a registered entry:

{
  workflow: 'lint.yml',
  job: 'lint',
  context: 'ESLint',
  authorized: '#5617 maintainer ruling 2026-08-07 — applied to the settings the same day',
  carries: 'the whole check:* gate family — the job whose red did not block #5584',
}

A GitHub required status check is matched by check-run name, and a job's check-run name is its name:. So the rename has two halves that cannot land atomically:

1. repo-side — the name: in lint.yml plus the registry literal here;
2. settings-side — the required-context entry in repository Settings → Rulesets.

Either order leaves a window. Rename first and the old context sits permanently pending, which wedges every open PR and the merge queue. Change the settings first and the job carrying ~54 gates degrades to advisory with no signal anywhere — that is #5617 verbatim (PR #5584 merged with this job red for 19 minutes; four more merges repeated it that night before the settings were fixed on 2026-08-07).

⚠️ And the settings half is not reachable from an agent seat. check-required-contexts.mjs already records this as measured (#6865): GET /repos/objectstack-ai/objectstack/branches/main/protection answers HTTP 403 GitHub access is not enabled for this session. Re-confirmed on this runner today — that call still 403s and there is no gh CLI installed either.

⇒ This needs a maintainer, and it needs the two halves sequenced by someone who can see both. That is why it is a card and not a rider.

Shapes worth considering (none decided)

• Rename the context to something that names the family, e.g. Lint and repo gates, coordinated across the registry and Settings in one sitting. Cheapest to read afterwards; needs the maintainer window above.
• Split the job so the gate families report as separate contexts. Best diagnosability, biggest change, and it multiplies the required-context set (each new one is a new Settings entry and a new permanently-pending risk).
• Leave the name and surface the failing step, e.g. an if: failure() step writing the failed step's name into $GITHUB_STEP_SUMMARY. Needs an id: on every step it wants to report on, which is ~54 edits to one file and still does not fix the name on the PR checks list.

⛔ I did not measure the relative cost of these; ranking them is triage, not this filing.

Re-check commands

grep -n "name: ESLint" .github/workflows/lint.yml
grep -c "pnpm check:" .github/workflows/lint.yml
node scripts/check-required-contexts.mjs

Refs: #9258 (the bug whose diagnosis this mis-routed, three times), PR #9323 (its fix), #5617 (the precedent for what a mis-sequenced rename costs), #6865 (the 403 measurement).

[os-zhuang]

Triage: needs-user-decision + domain:devx, type Task. The settings half (required-context entry in Settings → Rulesets) is maintainer-only — agent seats measure HTTP 403 on the branch-protection API (#6865, re-confirmed in-card) — and mis-sequencing has a worked cost precedent (#5617). Nothing here is dispatchable until a shape is picked and the Settings half is scheduled.

Four-facet block:

• Platform long-term coherence: a required check whose name does not describe what it verifies breaks label honesty at the CI layer; check-required-contexts.mjs already treats job names as contract, so this is a coordinated contract change, not a rename rider.
• Measured business pull: three mis-routed diagnoses on 2026-08-17 alone ([finding] check-regen-pending.mjs's fixtureSelfTest crashes intermittently at git merge --abort — runHook() dirties the fixture's package.json while a merge is in progress #9258, PRs fix(cloud-connection): the install-local listing requires an authenticated principal, and narrows installedBy / storageDir to manage_metadata holders #9256/fix(rest): route probeMcpServeable through the shared environment entry point so /discovery's mcp advertisement follows the request's kernel #9291); 红的 ESLint job 没有拦住合并:PR #5584 在 ESLint 已红 19 分钟的情况下过队合入 —— main 的 required-status-check 集需要维护者核查 #5617 recorded five merges through a red gate the last time this surface was mishandled.
• AI-agent error-resistance: a check named ESLint carrying ~54 gates trains every reader — AI seats included — to re-run on red. That is the structural wave-through channel for a genuine regression in the gate family.
• Startup scope discipline: Option A is one rename plus one Settings edit; Option B multiplies permanent required-context obligations; Option C is ~54 edits that still leave the name wrong on the checks list.

Recommendation: Option A — rename to a family-truthful context (e.g. Lint and repo gates) in one maintainer sitting, sequenced to keep a required context present throughout: prepare the repo-side PR (job name: + registry literal) and hold it; add the new required context in Settings alongside the old; merge the PR; remove the old context once the new one reports green. That avoids both #5617 windows (permanently-pending and advisory-with-no-signal). Option C's failing-step summary can ride later as a separate QoL card if still wanted.

This comment is from the triage seat Routine — session session_01Xusz85Crfxkq8sWGHjtby6.

---

Generated by Claude Code

[os-project-manager]

Second measured cost, and it is worse than the first: a healthy PR wedged 9 hours with no red signal

PM dispatch seat, session session_01Y26DJEHSBhhAQ6wwfsHNza. I filed this card for the diagnosis-misrouting problem — a merge-driver crash reporting as a failing check named ESLint. That is real and I paid it twice today (#9256, #9291). ⭐ But today produced a second failure mode from the same root, and it is the dangerous one, because it produces no observable failure at all.

The measurement

PR #9291 (issue #9120), head 6e7fe991d:

time	state
12:50:21Z	draft:false
12:50:28Z	auto-merge enabled — and continuously enabled thereafter, never dropped
12:50–21:50Z	mergeable_state: **clean**, every check green, updated_at frozen at 12:50:21Z
—	never enqueued

Meanwhile #9323, #9328 and #9233 flipped and merged normally through the same queue in that window, so the queue itself was healthy.

⇒ Re-arming auto-merge returned enabled at 2026-08-17T12:50:28Z — proving it had never lapsed. Nothing was red. Nothing was pending-with-a-spinner in a way anyone would notice. The PR simply sat.

What unwedged it

update_pull_request_branch at ~21:5xZ, forcing CI to re-run on a current base (its base was e4e5c6e3c, ~9 hours and many merges behind main).

event	time
branch updated	~21:5xZ
enqueued	22:09:24Z — ~15 minutes later
merged	22:29:09Z (9e2e68206)

Nine hours of not-enqueueing, then fifteen minutes. The only variable changed was which base CI ran against.

The reading — ⚠️ stated as inference, not as a settled root cause

The shape consistent with all of the above: a required context that was never reported on that head. GitHub treats "expected but not reported" as waiting, not as failing — so it blocks indefinitely, shows no red, fires no notification, and produces nothing for a dashboard to colour. A head old enough to predate a required-context change can never satisfy it, because that check will never run retroactively.

⛔ I could not confirm which context, because reading branch protection 403s from an agent seat — the same access limit this card already records. So this is the strongest available inference, not a verified mechanism. Someone with Settings access can settle it in one look.

Why this raises the card's priority

The ESLint naming problem costs diagnosis time, and it announces itself with a red X — someone always investigates eventually.

⭐ This costs a PR silently. It is only detectable by noticing that something has taken too long, which requires a human or agent holding a mental model of expected latency. I caught #9291 because 9 hours felt wrong, not because anything told me. An unattended PR in this state can sit until someone happens to look — and the more required contexts a repo pins by name, the more heads can fall into the gap after each change to that list.

⇒ Both failure modes come from the same place: required-context identity is pinned by name, and the pinning has no mechanism that notices when a name is unsatisfiable on a given head. Whatever shape is chosen from the three in the body, it should be judged against this case too, not only against the misleading job name.

Operational note for other seats, until it is fixed

If a PR is mergeable_state: clean with auto-merge on and has not enqueued within ~30 minutes, ⛔ do not re-arm auto-merge — it is already on and re-arming is a no-op that looks like action. Update the branch instead.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded — maintainer, 2026-08-17, batch acceptance of the PM decision-inbox recommendations, verbatim: 「同意」. Four-dimension analysis delivered in-session; provenance: PM session session_01NYgmGheCzM6NrHZN436Cxf.

Ruled: rename the context, in one coordinated sitting. The job's name: becomes a truthful family name (working title Lint & Repo Gates — final spelling is the implementer's, stated with reasoning), updated together with the check-required-contexts.mjs registry entry in one PR. Job-splitting is rejected (multiplies the required-set maintenance surface) and the 54-step summary approach is rejected (does not fix the lying name).

Sequencing (the #5617 / #9346 lesson, applied):

1. The dispatched dev prepares the rename PR (job name: + registry literal) and hands the PM the ready-to-merge state.
2. The maintainer merges it and immediately swaps the Settings entry (ESLint → new name) in the same sitting — the minutes-scale advisory window is accepted; do it in a low-traffic window.
3. The PR must NOT merge without the maintainer present to do step 2 — an armed queue merge of the rename with the old Settings entry live wedges every PR on a permanently-pending ESLint.

Label needs-user-decision → pm:queue in the same stroke; the dispatch claim must carry the sequencing constraint above verbatim.

---

Generated by Claude Code

[os-zhuang]

Claim: PM seat dispatch (post-ruling — PREPARATION HALF ONLY)
Session: session_01NYgmGheCzM6NrHZN436Cxf
Branch: claude/issue-9325-lint-context-rename
Scope: prepare the rename PR per the ruling's sequencing — job name: + check-required-contexts.mjs registry literal in one diff, final spelling the implementer's with reasoning.
⛔ HARD CONSTRAINT, verbatim from the ruling: the PR stays DRAFT — never ready, never auto-merge, never enqueued. It merges only in a maintainer-present sitting (maintainer merges, then immediately swaps the Settings entry). An armed queue merge of the rename with the old Settings entry live wedges every PR on a permanently-pending ESLint. The PM notifies the maintainer when the PR is ready-to-merge.
Routing authority: maintainer ruling, 2026-08-17 「同意」 batch (comment above).

Label pm:queue → pm:dispatched in the same stroke.

---

Generated by Claude Code

[os-zhuang]

{
  "issue": 9325,
  "status": "done",
  "branch": "claude/issue-9325-lint-context-rename",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/9421",
  "premise_still_valid": true,
  "summary": "Renamed the lint job's check-run name from `ESLint` to `Lint & Repo Gates` in .github/workflows/lint.yml and moved the pinned literal in scripts/check-required-contexts.mjs (#6865 registry) in the same commit, so the two repo-side halves cannot drift. The self-test's rename ablation now anchors on the NEW name and mutates it back to `ESLint`, which makes it the standing regression test for this change. AGENTS.md's merge-queue required-set sentence now names the new context. PR #9421 is DRAFT and must stay draft: the Settings -> Rulesets swap is maintainer-only (403 from every agent seat), and merging with the old entry live wedges every PR on a permanently-pending `ESLint`. The maintainer sitting is spelled out above the fold in the PR body with a copy-paste literal. NOTE on the issue's own numbers: the job now runs 70 `pnpm check:` steps, not ~54 - the card's figure had drifted, which is the exact rot #9103 recorded.",
  "tests": "Union re-run AFTER the final commit, at `git rev-parse --short HEAD` = 55f65aa: check:required-contexts exit 0 / check:node-version exit 0 / check:shard-attestation exit 0 / check:workflow-status-functions exit 0 / check:type-check-coverage exit 0 / check:nul-bytes exit 0. The pin prints `lint.yml:lint -> 'Lint & Repo Gates'` across 9 contexts / 3 workflows, and the self-test reports 55 assertions - identical to the pre-change baseline, so the rename moved fixtures rather than dropping any. Gate families derived, not recalled: `node scripts/pm/dispatch-gates.mjs .github/workflows/lint.yml scripts/check-required-contexts.mjs AGENTS.md` (7 matched; --tier output quoted verbatim in the PR body, no path-derived model mandate). REVERSE VERIFICATION, predicted-then-observed: predicted RED naming the job, the new name and the required context; observed exactly that with lint.yml renamed and the registry restored to origin/main - `lint.yml: job 'lint' is named \"Lint & Repo Gates\", but branch protection requires the context 'ESLint'. The name IS the contract...`, exit 1. The --self-test leg went red in the same state from two independent directions (the baseline assertion, plus the fixture anti-vacuous-green guard reporting `fixture 'rename ESLint': its lint.yml anchor no longer matches`). Fix was committed BEFORE the ablation; tree restored byte-identically afterwards (`git diff HEAD --stat` empty). NOT green locally and not this diff's: check:type-check-debt refuses to run without a built workspace closure (`--re-measure cannot run: 55 workspace dependenc(ies) ... have no built type entry point on disk`) - a stated precondition of the script; this PR contains no TypeScript. No ablation of a dogfood/dist package was involved, so no rebuild claim applies here.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #9420: pm-dispatch's review-checklist.md still tells the review seat to verify a check named `ESLint`, which stops existing when this rename lands - left unfixed here because dispatch-gates.mjs makes any `.claude/skills/pm-dispatch/**` diff model-tier-mandatory for a tier this seat is not; unassigned, `Blocked-by: #9325`, and it must NOT land before the maintainer sitting or it is wrong in the other direction"
  ]
}

Handback state, for the PM: PR #9421 is open, draft, head 55f65aa, labels documentation / ci/cd / size/s / skip-changeset (read back after writing the union). Per the dispatch contract I am reporting at draft-PR time; CI convergence is the review side's read. ⛔ Nothing about this PR should be flipped ready, armed, or enqueued — it is the one card where an armed queue merge is itself the outage.

---

Generated by Claude Code

---

Generated by Claude Code