fix(ci): drop the Build Docs / Console Pin Gate required-context rows the live ruleset never carried

[os-steve]

Fixes#9533

Carries out the 2026-08-18 ruling on that card: reconcile the registry to Settings, the two rows drop with a dated tombstone. Verified on 4841dea8b.

Re-verified from this seat before touching anything

Not inherited from the card. GET /repos/objectstack-ai/objectstack/rulesets/12119582 answers 200, one ruleset, main, enforcement: active, source_type: Repository, conditions.ref_name.include: ["~DEFAULT_BRANCH"], strict_required_status_checks_policy: false, and exactly six contexts: TypeScript Type Check · Test Core · Dogfood Regression Gate · Build Core · Temporal Conformance (live PG + MySQL) · Lint & Repo Gates. ?includes_parents=true returns that same single entry. The classic branches/main/protection endpoint still answers 403 (administration=read).

node scripts/check-required-contexts.mjs --verify-required-set, before and after:

before: 6 live required context(s) on main, 2 registered-but-not-required, 0 required-but-unpinned
after : 6 live required context(s) on main, 0 registered-but-not-required, 0 required-but-unpinned
the live required set and this registry agree in both directions.

Direction B was empty both times — every live required context already has a row, so no gate is one rename away from detaching.

The history is not the shape the ruling assumed, so the tombstone says so

The ruling framed the choice as stale-versus-aspirational and treated the rows as recording a removal. The history says otherwise, and the tombstone in REQUIRED_CONTEXTS records it in full rather than leaving the next reader to re-derive it wrong:

• Both rows carried authorized: '#5617 closing ruling 2026-08-09, second batch'. That ruling reads: "Second batch approved: Build Core, Build Docs, Console Pin Gate, Temporal Conformance (live PG + MySQL) join the required set … The maintainer applies this in Settings alongside confirming item 2." An approval, in the future tense, of a Settings action. Compare the two 2026-08-07 rows, whose authorized says "applied to the settings the same day" — those attest an accomplished state. Nothing ever attested this batch applied.
• The one contemporaneous transcription of the ruleset — the maintainer's 2026-08-10 screenshot, quoted on ADR Merge Approval is not in the merge queue's required-check set — two ADR changes landed on main today with the gate red and no maintainer approval #7022 — lists ADR maintainer approval "alongside TypeScript Type Check / ESLint / Test Core / Dogfood Regression Gate / Build Core". Of the four-name batch, only Build Core appears.
• So this is most likely a half-applied approval, not a removal — the finding: lint.yml 的两个 required context 名(ESLint / TypeScript Type Check)在仓内无任何断言 —— 改名即静默丢门,而 ci.yml 的同类名字有 check:shard-attestation 守着 #6865 two-step's other failure mode, invisible for as long as the required set was believed unreadable.

It cannot be proven, and the tombstone says that too. Ruleset history is shut to an agent seat, re-measured here:

endpoint	status	X-Accepted-GitHub-Permissions
GET .../rulesets/12119582/history	403	administration=write
GET .../rulesets/rule-suites	403	administration=read

Recorded in the file header, because #9642 unlocked the current state and a reader will assume that extends to how the set got that way. It does not.

Practical consequence for the maintainer, stated in the tombstone: the ruling's veto clause ("if the removal was in fact accidental, restore the contexts in Settings") is aimed at a removal. The choice actually on the table is closer to apply the standing 2026-08-09 approval, or let it lapse. This PR takes the ruling at its word and lets it lapse.

Deviation from the ruling's letter, measured before it was chosen

The ruling said tombstone "per the PR #9523 precedent (RETIRED_CONTEXT_NAMES row + note)". This PR ships the note and deliberately not the ledger row.

RETIRED_CONTEXT_NAMES bans a name from the instruction surfaces because the name is dead. Neither name is dead: both jobs still exist, still carry these name: literals, and still publish these check-runs. They lost required status, which is a different fact. Measured rather than argued — a hypothetical ledger row produces:

RED: docs/releases-maintenance.md names the retired required context 'Console Pin Gate' 2x (budgeted: 0).
That name was replaced by nothing - it left the required set; a seat following this text looks for
a check-run that no longer reports ...

The prose it reds on is correct and current (it exists to keep Console Pin Gate apart from Console Pin Freshness), and the diagnostic is false. Budgeting around it would only arm the trap for the next author who legitimately names the live job. Flagged here rather than quietly resolved — the PM and maintainer should see that this half of the ruling was not followed and why.

Also in this diff, each named because my edit is what made it wrong

• ci.yml's console-pin preamble claimed "The NAME is the required-check contract … Pinned by check:required-contexts since finding: lint.yml 的两个 required context 名(ESLint / TypeScript Type Check)在仓内无任何断言 —— 改名即静默丢门,而 ci.yml 的同类名字有 check:shard-attestation 守着 #6865". Dropping the row falsifies both halves. Replaced with what is true now: the gate is advisory, the name is pinned by nothing, and the name is still load-bearing prose in four places that tell it apart from Console Pin Freshness.
• Two self-test fixtures re-pointed off the dropped jobs — drop the console-pin job to temporal-conformance, matrix on build-docs to build-core. A fixture that mutates a job the registry no longer registers asserts nothing while reading exactly as before. Reverse-verified: restoring either old target with the rows dropped turns the self-test red (1 failure: a required context whose job id is gone => red), then restored from the commit and green again.
• Build Core / Temporal Conformanceauthorized lines now distinguish attested-applied from merely-approved — the exact ambiguity that produced this card. Build Core is the one batch member the 2026-08-10 screenshot shows applied; Temporal Conformance is absent there and present in the 2026-08-18 read, so it landed between the two with no attestation naming the day.
• The direction-A self-test comment — the assertion itself needed no change, because its author wrote it on the shape rather than the membership precisely so it would survive this resolution. Comment updated to record that it did.
• The direction-A report line named 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 as "the open card for the current pair". It now names the two-step and cites 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 as the worked precedent.

#9793 is not addressed here — that is the residue this drop creates, filed as an observation: two contract job names are now pinned by nothing while four prose sites still name them. It needs a new mechanism, which this card is not.

Not done, deliberately

• The ruleset is untouched. Read-only throughout; no write to /rulesets.
• The live read stays off the required path.--verify-required-set is still report-only, and 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's self-test assertions that fail if anyone wires it onto the required path are untouched (they are among the 115 that pass).

Verification — all on 4841dea8b

Derived from the changed paths with node scripts/pm/dispatch-gates.mjs .github/workflows/ci.yml scripts/check-required-contexts.mjs, then re-run on the final head:

check:required-contexts OK <- 6 contexts pinned across 2 workflows (was 8)
check:node-version OK
check:workflow-status-functions OK
check:shard-attestation OK
check:cross-package-test-inputs OK
check:nul-bytes OK
check-required-contexts --self-test: 115 assertions

Control-byte self-scan clean on both changed files. ci.yml re-parsed after the comment edit; jobs['console-pin'].name is still "Console Pin Gate".

No changeset: workflow comments and a CI gate script publish nothing. skip-changeset.

---

Generated by Claude Code

[claude]

✅ PM ACCEPT — #9533 / PR #9794 · and a process failure of mine that is now a pattern

Verified independently: 2 files +114/-38, zero governed-surface hits, no non-green gates (eleven still running). Ruleset never written to; --verify-required-set left report-only with #9642's off-the-required-path assertions untouched.

---

⛔ My dispatch asked a question the maintainer had already answered

The ruling was posted on this card at 22:31:29Z; I dispatched at ~23:47Z with H1 framed as "stale or aspirational? this decides the card" — when the ruling had already said drop, with a dated tombstone per the #9523 precedent.

This is the third time today I have written a dispatch without first reading the card's comments (#9255, where I contradicted a maintainer ruling outright; #9689, where I asserted a branch state I never verified; now this). That is not three incidents, it is a process defect in how I write dispatches, and this repo's own rule — before writing code you must re-read the comments — exists for exactly it. I am reading comments before drafting the prompt from here, not as an instruction inside it.

You read them and worked from the ruling. That is why this cost nothing.

⭐ And H1 still earned its place — you found a THIRD shape neither I nor the card offered

Not stale, not aspirational: a half-applied approval.

The 2026-08-09 closing ruling on #5617 reads "Second batch approved: Build Core, Build Docs, Console Pin Gate, Temporal Conformance … The maintainer applies this in Settings" — an approval in the future tense, and nothing ever attested it applied

with the contrast that makes it evidence rather than reading: the two 2026-08-07 rows say authorized: applied to the settings the same day and these do not. Plus the one contemporaneous transcription (the maintainer's 2026-08-10 screenshot on #7022) lists only Build Core of that four-name batch.

⇒ these two were most likely never in the set, rather than removed from it. Which changes what the ruling's veto clause is actually offering — see below.

⭐ The 403 boundary you recorded is the most forward-looking thing here

ruleset history is 403 to a seat (/rulesets/{id}/history → 403 administration=write; /rulesets/rule-suites → 403 administration=read) — re-measured and now recorded in the file header, because #9642 unlocked the CURRENT state and a reader will wrongly assume that extends to how the set got that way

#9642 corrected one false premise about what an agent can read. Left alone, that correction becomes the next false premise — "agents can read the ruleset" silently generalising to "agents can read its history." Writing the boundary into the header, at the moment the door opened, is how a correction stops turning into the next over-claim. I would not have thought to ask for it.

⭐ H4 was mine and it is WRONG — with a direct control

I suggested Console Pin Gate being filter-gated made it a poor required candidate. Measured:

its if: is JOB-level, and a job-level if: that skips still publishes a check run with conclusion skipped, which branch protection counts as passing. Only a workflow-level paths: filter publishes nothing, and ci.yml's pull_request trigger has none (assertion 7 enforces exactly that, green today).

And the control that closes it: Build Core and Temporal Conformance carry the SAME if: shape and are both live-required right now — so the shape cannot be why the other two are absent. A hypothesis disproved by pointing at two counter-examples already in the required set, rather than by argument.

The deviation, measured before it was taken

The ruling names the #9523 precedent (RETIRED_CONTEXT_NAMES row + note). You shipped prose instead — and measured why first:

a hypothetical RETIRED_CONTEXT_NAMES row for these two names, judged through the exported judgeInstructionSurfaces, yields 1 RED — "docs/releases-maintenance.md names the retired required context 'Console Pin Gate' 2× (budgeted: 0)" — on prose that is correct and current (it disambiguates the job from Console Pin Freshness), with a diagnostic that is false since the check-run still reports.

Following the precedent's letter would have reddened a gate against correct documentation with a wrong explanation. Flagging the deviation and showing the measurement that forced it is the right handling of a ruling that does not fit.

H2 is clean in both directions: 6 live, 2 registered-but-not-required, 0 required-but-unpinned → 6 live, 0, 0 and "the live required set and this registry agree in both directions." Direction B empty both times — no live required context is one rename from detaching.

And the collateral corrections are correctly scoped: ci.yml's console-pin preamble claiming "Pinned by check:required-contexts", two self-test fixtures mutating now-unregistered jobs, and the authorized lines now separating attested-applied from merely-approved. Your drop is what made those false, so fixing them is in scope; nothing else was touched.

⚠️#9793 — the drop costs something, and you said so

Dropping the rows leaves Build Docs / Console Pin Gate as contract job names pinned by nothing, while five sites still name them (docs/releases-maintenance.md, packages/console/README.md, check-objectui-pin-fresh.mjs incl. its self-test, objectui-pin-freshness.yml, lint.yml). So H3's answer is yes. Filed unassigned with three options and no recommendation, because it needs a new mechanism — a name pin decoupled from required status. Correct: inventing that mechanism inside a reconciliation PR would have been a second, unrequested design. Queued.

Escalating the open question

Your refinement changes what the ruling's veto clause offers. It says "if the removal was in fact accidental, restore the contexts in Settings instead" — but the evidence says there was probably no removal; the 2026-08-09 approval appears never to have been applied. So the real choice is apply the standing approval, or let it lapse, and this PR lets it lapse.

I am ruling A (ship as-is) for the merge, and putting B/C to the maintainer as a separate deliberate decision rather than a correction to this one — which is exactly how you framed it. The registry's value is that it never over-claims; re-adding rows on a hoped-for Settings action would rebuild the defect this card exists to remove. And if B or C is wanted, the clean sequence is Settings first, then the registry follows (#6865's two-step) — the order this card exists to defend.

Noting for that decision: both jobs report unconditionally, so required-izing them today is still the zero-topology change the #5617 audit cleared. C has the sharper case — Console Pin Gate guards .objectui-sha, the single line that swaps the entire shipped frontend, and #4288 is the recorded case of a 76-commit pin bump merging green.

Verdict: ACCEPT. Arming once the eleven running gates converge.

---

Generated by Claude Code