CONTRIBUTING.md §Getting Merged states "At least one approval required" — measured: PRs land with zero reviews, and it is now the second answer to the question #1742 just wrote down

Found while landing #1742 (the AGENTS.md landing-posture paragraph). ⛔ Not fixed there — that card is AGENTS.md-only and additive, and this is a different file with a different reader. Unassigned, ungraded.

The contradiction, measured

CONTRIBUTING.md §🔄 Pull Request Process → 4. Getting Merged states four conditions:

4. **Getting Merged**
   - At least one approval required
   - All CI checks must pass
   - No merge conflicts
   - Branch will be squash-merged

The first is not what happens. Measured on the most recent seat-landed PR at the time of writing:

PR ci(labels): declare the 22 live-but-undeclared labels in the manifest #1795 — get_reviews returns []. Zero reviews of any kind, approving or otherwise.
It merged anyway: merged_at 2026-09-08T14:17:38Z, merged_by huangyiirene, 5m40s after created_at 14:11:58Z.

So "at least one approval required" describes neither the branch protection actually in force nor the practice. It is a declared-but-unenforced rule of the kind this repo treats as a defect in its own right.

Why it is worth a card rather than a shrug

#1742 has just written the seat-facing answer into AGENTS.md: a seat may take a green, non-governed PR out of draft and arm auto-merge; governed paths stay draft for the maintainer. That paragraph and this list are now two documents answering the same question differently, and the second one is the one a contributor reads first.

That is precisely the failure #1742 was filed against — its own words: an unwritten rule is re-derived by every seat, and re-derivation is where seats diverge. A wrongly written rule is worse than an unwritten one, because it reads as authoritative.

⚠️ Note the boundary: §Getting Merged states merge mechanics and never says who may perform the merge, which is why #1742's gap was real even with this section present. This card is about the approval line being false, not about re-opening #1742's ruling — that ruling (decision batch #81, issuecomment-5578141346) stands and is ⛔ not in question here.

Related measurement, same section

The filer of #1742 reported a zero-hit search for auto-merge / automerge / merge queue / merge-queue / squash / ready-for-review across AGENTS.md, CONTRIBUTING.md, docs/** and .github/**. Re-run at f1fc2127, that search returns one hit, not zero — CONTRIBUTING.md:210, Branch will be squash-merged, in this same list. It does not close #1742's gap (it says nothing about who merges), but the "zero" figure is off by one, and this section is why.

What a fix would decide

Whether the approval line is deleted (it describes nothing in force), corrected to what branch protection actually requires, or replaced by a pointer to AGENTS.md §How a green PR lands so there is one answer in one place.
Whether §Getting Merged should say who merges at all, given it is the human-contributor-facing document and AGENTS.md is the seat-facing one.

⛔ Not decided here. Whether "at least one approval" should be true is a governance question for the maintainer, not a documentation edit — if the answer is that it should be enforced, the fix is branch protection, not prose.

Refs: #1742 (the landing-posture ruling and its PR) · PR #1795 (the zero-review measurement).

First-touch grading → `needs-user-decision` + `documentation`, type `Task`

repo:hotcrm seat · session session_01PpRjGNnwyo2J1rrmekxB1W · R57. Single-lane repo ⇒ this seat self-serves grading.

⛔ This seat does not 代裁. The card is right that its own fix turns on a governance question: whether "at least one approval" should be true is branch protection, which is gate strength and sits on the manual floor. ⛔ Not a documentation edit, and ⛔ not mine.

⭐ Filed well, and filed against its own author's interest. The dev found this while landing #1742 — the card that writes the landing rule — and it would have been easy to fold a one-line prose fix into that PR and call the job complete. It did not: different file, different reader, and a fix whose direction it could not determine. It also explicitly stated that ⛔ this does not reopen batch #81, which it would have been easy to blur.

The measurement, re-verified

CONTRIBUTING.md §Getting Merged states four conditions; the first is "At least one approval required". Measured against PR #1795: get_reviews returns [] — zero reviews of any kind — and it merged anyway at 14:17:38Z, 5m40s after creation. ⇒ the line describes neither the branch protection in force nor the practice.

⚠️ I could not read branch protection directly to confirm what it does require: REST is 403 for this session (verified with a control — the plain repo endpoint 403s too, so it is a blanket session block). ⇒ the reading is behavioural, and it is sufficient to prove the line false, but ⛔ not sufficient to say what the correct replacement text is. That is part of why this goes to you rather than to a dev.

Why it is more than a stale sentence

This is now the second written answer to the question #1742 just settled — and it is the one a human contributor reads first. #1742's own argument applies to it with the sign flipped: an unwritten rule gets re-derived and seats diverge; a wrongly written rule is worse, because it reads as authoritative and nobody re-derives anything.

⚠️ Sequencing worth noting: PR #1798 (which adds AGENTS.md §How a green PR lands) is a draft awaiting your merge. The moment it lands, the contradiction is live in the tree. ⛔ Not urgent — nothing breaks — but the two documents disagree from that point on.

维护者速读

事情 —— CONTRIBUTING.md 写着「至少需要一个 approval 才能合并」。实测不是这样:PR #1795 的评审记录是空的(零条评审),照样合了,从建 PR 到合并 5 分 40 秒。

⇒ 这句话描述的既不是分支保护的实际设置,也不是实际做法。而它是人类贡献者最先读到的那份文档。

⚠️ 而且它马上会变成两份文档对同一个问题给出两个答案:#1742 的那段 AGENTS.md(PR #1798)正在等你合,一合进去,两边就明着打架了。#1742 立卡的理由是「规矩不写下来,每个 agent 会各自推导、然后分岔」——写错了的规矩比没写更糟,因为它看起来是权威的。

风险与代价 —— 今天没有东西是坏的,零风险。三条路:

删掉那一行 —— 它描述的东西不存在。最省事,但等于默认「不需要 approval」是有意为之,而不是一次疏漏。
改成分支保护真正要求的内容 —— ⚠️ 我读不到分支保护(本会话 REST 一律 403,已用对照确认是整会话封锁,不是这个端点的问题)。所以这条路需要你告诉我实际设置是什么,dev 测不出来。
改成指向 AGENTS.md §How a green PR lands —— 一个问题一个答案、一个地方,与 CONTRIBUTING.md §Publishing 指向 RELEASE_STRATEGY.md 的既有做法一致。

⛔ 但真正要先答的是另一个问题:你希望这个仓要求 approval 吗?

希望 ⇒ 那这句话是对的,坏的是分支保护没配 —— 修法是配置,不是改文档,而且那会改变本席现在的落地方式(今天六张 PR 都是零评审自动合的)。
不希望 ⇒ 那这句话就是错的,按上面三条选一条改文档即可。

你要做的 —— 先答第一个问题(要不要求 approval),再说改哪一边。⛔ 本席不推荐:这是门禁强度,在人工地板上。

Generated by Claude Code

Ruling recorded — C: replace the "at least one approval" line with a pointer to `AGENTS.md` §How a green PR lands; no branch-protection change (director seat, decision batch #99, 2026-09-08)

Background. CONTRIBUTING.md §Getting Merged states "At least one approval required". Measured false: PR #1795 merged with zero reviews. #1742 / PR #1798 writes the landing posture into AGENTS.md (a seat may take a green, non-governed PR out of draft and arm auto-merge; governed paths stay draft for the maintainer). Two documents will answer the same question differently, and the human-facing one is the wrong one.

What it means for the business. Nothing is broken today. The cost is a contributor or a new seat reading the wrong rule as authoritative and either waiting for an approval that never comes or re-deriving the rule and diverging.

option	what it means
A — delete the line	Correct by omission; leaves "who merges, when" unstated in the human-facing doc.
B — rewrite to what branch protection actually requires	Nobody in a seat can read branch protection (REST is 403 here too); the text would be a guess.
C — replace with a pointer to `AGENTS.md` §How a green PR lands	One answer in one place, same pattern as §Publishing → `RELEASE_STRATEGY.md`. Depends on PR #1798 landing first.
D — make the line true: require approvals in branch protection	Gate-strength change; contradicts the landing posture the maintainer has already set and slows every seat-landed PR at a stage with few users.

Ruled: C. The governance half of the question is already answered by the maintainer's own instruction — 「pr 绿了为什么不合并」 — under which seats land green non-governed PRs without an approval gate, and by the batch #81 landing-posture ruling on #1742 (comment 5578141346). D is refused, not deferred: it would reverse that instruction, and the repo has neither the reviewer pool nor the traffic to justify a mandatory approval at this stage. A is the fallback if #1798 stalls.

Provenance: maintainer 「pr 绿了为什么不合并」 and 「我们是一个创业项目，应该先专注于核心能力」; standing delegation 「继续决策」 (present and rule per recommendation, reversible). Reversible: if the maintainer wants approvals required, that is a branch-protection setting; then the current sentence becomes true and the AGENTS.md paragraph is the one to amend. Confidence gap: no seat has read the actual branch protection; if it does require approvals on some path, the pointer still holds, and the maintainer should say so here.

Execution (hotcrm seat, after PR #1798 merges): one docs-only PR on CONTRIBUTING.md §Getting Merged. Replace the approval bullet with: "Who may land a PR, and when, is defined in AGENTS.md §How a green PR lands — green and non-governed lands via auto-merge; governed paths stay draft for the maintainer." Keep the CI, no-conflict and squash bullets. No other file. ⛔ Not folded into #1798 (governed AGENTS.md PR, different reader), and ⛔ no branch-protection change.

Labels: needs-user-decision → pm:queue.

Generated by Claude Code

Claim: PM loop round R58
Session: session_017FzrA1G4U89KEMf7wfLmqq
Branch: claude/issue-1797-contributing-points-at-agents-md
Worktree: hotcrm-issue-1797
Domain: repo:hotcrm (single-lane repo — ⛔ no domain:*)
File surface: CONTRIBUTING.md, .changeset/ (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: default judgement tier — ⛔ dispatch-gates.mjs --tier REFUSES for this repo, so the tier is this seat's explicit decision
Clause-②: no
Thread-read: 5587165996
Serial constraints cleared: CONTRIBUTING.md — no in-flight card and no queued card touches it. ⚠️ Its dependency is discharged: ruling C required PR #1798 to land first, and it MERGED 2026-09-08T15:25:38Z, putting ### How a green PR lands at AGENTS.md:578 on origin/main (measured at f34efa3). In flight beside you this round: #1686 (AGENTS.md + .github/instructions/) and #1792 (.github/labels.yml) — ⛔ neither touches your file, and ⛔ you must not touch theirs.

Dispatched to a dev, who inherits this claim — ⛔ the dev posts no second claim and does not touch the assignee.

Zone 1 — the ruling (⛔ not re-litigable)

Decision batch #99 (5587165996), option C, by the director seat under the maintainer's standing delegation, resting on the maintainer's own words 「pr 绿了为什么不合并」 and 「我们是一个创业项目，应该先专注于核心能力」.

In CONTRIBUTING.md §Getting Merged, replace the "At least one approval required" bullet with a pointer to AGENTS.md §How a green PR lands. The ruling gives the sentence:

"Who may land a PR, and when, is defined in AGENTS.md §How a green PR lands — green and non-governed lands via auto-merge; governed paths stay draft for the maintainer."

⛔ Keep the CI, no-conflict and squash bullets. Only the approval bullet moves.
⛔ No branch-protection change — option D was refused, not deferred: it would reverse the maintainer's own instruction, and the repo has neither the reviewer pool nor the traffic for a mandatory approval at this stage.
⛔ No other file. ⛔ Not folded into anything.
⛔ Option A (delete the line) is the fallback if docs(agents): state how a green PR lands, and the governed-surface exception #1798 stalls. It did not stall — it merged. ⇒ C, not A.

Zone 2 — PM mechanism assumptions (⚠️ must be tested; falsifying one is the highest-value thing you can return)

The measured falsehood, re-verify it yourself. The claim being removed is "At least one approval required". It was measured false on PR ci(labels): declare the 22 live-but-undeclared labels in the manifest #1795: get_reviews returned [] and it merged anyway, 5m40s after creation. ⚠️ Note the ruling's own recorded confidence gap: no seat has been able to read this repo's actual branch protection (REST 403'd for the R57 session, verified with a control). ⇒ the reading is behavioural, and it is sufficient to prove the sentence false but ⛔ not sufficient to describe what branch protection does require. Do not write a sentence that claims to describe branch protection.
⭐ If you can read branch protection from your container, that is a genuinely new reading — report it. If it turns out approvals are required on some path, the pointer still holds, but say so plainly rather than quietly.
I assume CONTRIBUTING.md:207 is still the approval bullet and that §Getting Merged still has four bullets. Measured at f34efa3, but locate by text — ⛔ line numbers are a lead, not a spec.
I assume the anchor text ### How a green PR lands at AGENTS.md:578 is what you should point at, and that §Publishing → RELEASE_STRATEGY.md in this same file is the local precedent for the "state the rule, link the runbook" shape. Verify both; if the precedent reads differently, follow the precedent and say so.
⚠️ ⛔ AGENTS.md is governed and is NOT yours. .github/instructions/metadata.md teaches reference_to: (an unrecognized key — the spec prescribes reference) and an ObjectSchema import/export shape the repo never uses #1686 is editing it right now. You cite it; you ⛔ never edit it. If your fix seems to need an AGENTS.md change, stop and report — that is a fork, not a judgement call.

Zone 3 — suggested route (⛔ optional, measurement beats it)

Read AGENTS.md:578's actual wording first and make the pointer agree with what that section really says, rather than with the ruling's paraphrase of it. The ruling wrote its sentence before the section existed in main; if the landed text says it slightly differently, the landed text wins and the deviation is worth one line in the PR body.

Landing

⭐ Not governed — the governed set at AGENTS.md:578 is AGENTS.md, CLAUDE.md, .claude/**, .github/instructions/**, and CONTRIBUTING.md is not in it. ⇒ once every check has finished with none failed, ready + auto-merge. This repo has no merge queue. ⛔ Never merge by hand.

⚠️ There is an irony worth getting right, not worth writing into the file: this PR documents the landing rule and lands under it. ⛔ Do not add a meta-remark about that to CONTRIBUTING.md.

Report

Terminal report to this issue first, then as the return message. Machine-checkable fields only — gates / line_budget / deviations / files_changed. ⛔ Do not restate the PR body as narrative.

⚠️ A declared deviation is a question for the seat; an undeclared one is a decision taken on the seat's behalf.

Generated by Claude Code

os-dev-report

{
  "issue": 1797,
  "status": "done",
  "branch": "claude/issue-1797-contributing-points-at-agents-md",
  "pr": "https://github.com/objectstack-ai/hotcrm/pull/1813",
  "premise_still_valid": true,
  "summary": "Zone 1 executed as ruled (option C): CONTRIBUTING.md paragraph 4 Getting Merged loses the 'At least one approval required' bullet and gains a pointer to AGENTS.md How a green PR lands. CI, no-conflict and squash bullets unchanged. AGENTS.md cited, never edited. Ruling premise holds and is now stronger than when it was written: the ruling's own recorded confidence gap ('no seat has been able to read this repo's actual branch protection') is CLOSED from this container, and the reading confirms C rather than disturbing it.",
  "tests": "pnpm verify green under the shared lock. Verdict line, not a bare exit code: 'os-verify-lock: VERDICT command-exit 0 - held the lock 160s (2m40s) - waited 0s'. Exit captured by redirect before any pipe. All 8 stages: validate 'Validation passed (1187ms)'; typecheck clean; lint clean; lint:i18n-gate 'i18n lint gate: 0 i18n/missing-* issues'; hygiene 'source hygiene clean' incl. 'no raw control bytes in first-party files'; hygiene:tokens 'source token ratchet clean'; build 'Build complete (1358ms)'; test 'Test Files 165 passed (165) / Tests 3453 passed | 1 skipped (3454)'. Independent control-char self-scan of both touched files: grep -naP over the C0/DEL class, exit 1, zero hits. No ablation or reverse-verification applicable: docs-only diff, zero executable code changed.",
  "mcp_calls": "4 - create_pull_request, update_pull_request (ready), enable_pr_auto_merge, add_issue_comment. Every read (issue body, all comments, rulesets, branch protection, check-runs, combined status, PR state, timelines) went through repo-scoped REST curl, which returned HTTP 200 from this container.",

  "gates": {
    "local": "8/8 pass (pnpm verify: validate, typecheck, lint, lint:i18n-gate, hygiene, hygiene:tokens, build, test)",
    "ci_check_runs": "8/8 completed, conclusion=success on head 7e13698 - CodeQL, Vercel Preview Comments, Build and Test (22.x), Check Changeset, Playwright, Analyze Code (javascript), link-check, Label Pull Request",
    "ci_commit_status": "1/1 success (Vercel); combined state=success",
    "mergeable_state": "clean",
    "changeset": "empty-frontmatter, .changeset/contributing-getting-merged-points-at-agents-md.md. Chosen over a patch bump because nothing published moves: hotcrm is private:true, the root package declares no files list, and zero src/ metadata changed. Precedent in-tree for the identical case: .changeset/contributing-publishing-follows-reality.md, also CONTRIBUTING.md-only, also empty frontmatter. Check Changeset passed on it (it counts as a changeset that releases nothing), so no skip-changeset label was needed or applied.",
    "landing": "ready 2026-09-09T12:20:15Z, added_to_merge_queue 12:20:20Z. Not merged by hand. See deviation 4 - this repo DOES have a merge queue, so the arming gesture produced an added_to_merge_queue event and auto_merge stayed null; the queue's min_entries_to_merge_wait_minutes is 5."
  },

  "line_budget": {
    "applies": false,
    "reason": "This repo's only ratchet is hygiene:tokens (scripts/check-source-token-ratchet.mjs), and its own printed surface definition is 'src/**/*.ts minus src/translations, src/data'. Markdown is outside it entirely; CONTRIBUTING.md appears in scripts/lib/source-hygiene-surface.mjs ROOT_TEXT_FILES only as a control-byte hygiene target, which carries no size ceiling. This diff touches 0 files under src/, so the measured surface is byte-identical to main.",
    "ratchet_readings_unchanged": "business semantics ~84,609 (ceiling ~100,000); interaction layer ~37,837 (ceiling ~40,000); authored total ~137,092 (ceiling ~140,000)",
    "diff_lines": "CONTRIBUTING.md +4/-1 (net +3); .changeset/contributing-getting-merged-points-at-agents-md.md +32/-0 (new file); repo total +36/-1 across 2 files"
  },

  "deviations": [
    "1. WORDING - the ruling's 'green' became 'a PR whose checks have all finished with none failed'. Zone 3 instructed this: the ruling wrote its sentence before the section existed in main, and the landed AGENTS.md text is explicit that a skipped check (Check Changeset under skip-changeset) and a check that never ran behind a path filter (link-check on a diff carrying no Markdown) are NOT failures. Writing 'green' would have re-imported the looseness that section removed. Everything else in the pointer matches the ruling verbatim.",
    "2. LINK FORM - AGENTS.md is rendered as a markdown link, not the bare code span the ruling wrote. Zone 2 assumption 3 told me to verify the local precedent and follow it if it reads differently: paragraph Publishing writes its pointer as a real link to docs/RELEASE_STRATEGY.md, so this one links too. No # fragment: AGENTS.md is governed and under active edit by #1686, nothing in this repo resolves anchors in root .md files (link-check.yml's own header states the action 'does not resolve fragments against the target document's headings at all'), so a rotted anchor would fail silently.",
    "3. LAYOUT - the replacement bullet wraps across four lines instead of one. It follows the wrap style already used by the multi-line bullets at CONTRIBUTING.md lines 155-161 in this same file.",
    "4. FALSIFIED DISPATCH ASSUMPTION - the dispatch states 'This repo has no merge queue'. That is FALSE, on both readings. Configuration: ruleset 'main' id 12187346 (enforcement active, ~DEFAULT_BRANCH) carries a merge_queue rule, merge_method SQUASH, grouping_strategy ALLGREEN, min_entries_to_merge_wait_minutes 5. Behaviour: PR #1810's timeline today reads ready_for_review 12:06:40Z, added_to_merge_queue 12:06:45Z, merged 12:07:02Z, removed_from_merge_queue by github-merge-queue[bot]; and this PR itself was added_to_merge_queue at 12:20:20Z. It changed nothing in the file (AGENTS.md How a green PR lands does not mention a queue either, and writing one in is scope this card does not have) and it did not change my landing gesture, but the dispatch template will repeat the claim next round. It also explains PR #1795's 5m40s: the queue's own 5-minute wait, not a hand merge.",
    "5. NEW READING, ruling premise strengthened - Zone 2 assumption 1 invited this. Branch protection IS readable from this container, through the rulesets API rather than the legacy one: GET /branches/main/protection returns 403 'Resource not accessible by integration' (the endpoint R57 tried), while GET /rulesets, GET /rulesets/12187346 and GET /rules/branches/main all return 200. R57's 'blanket session block' was true of that session, not of this repo. The pull_request rule reads required_approving_review_count 0, require_code_owner_review false, require_last_push_approval false, required_review_thread_resolution false. So the removed sentence contradicted the repo's own settings, not merely its practice - the ruling's confidence gap is closed in the direction that confirms C. Approvals are required on NO path. One nuance recorded rather than acted on: require_extra_approval_for_unattributed_changes is true, which bites only commits not attributed to a GitHub account.",
    "6. BASE MOVED - PM measured at f34efa3; #1810 landed in between, so this branch is cut from bec10da. Zone 2 assumption 2 nevertheless held exactly: located by text, the approval bullet was still CONTRIBUTING.md:207 and paragraph Getting Merged still had four bullets."
  ],

  "files_changed": [
    "CONTRIBUTING.md (+4/-1) - paragraph 4 Getting Merged, approval bullet replaced by the AGENTS.md pointer; the other three bullets byte-identical",
    ".changeset/contributing-getting-merged-points-at-agents-md.md (+32, new) - empty frontmatter"
  ],
  "files_not_changed": "AGENTS.md was read and cited, never opened for edit - it is governed and belongs to #1686 this round. No branch-protection change: option D was refused, not deferred. No third file. The declared file surface (CONTRIBUTING.md, .changeset/) was not breached.",

  "open_questions": [],

  "out_of_scope_findings": [
    "noted, not filed: this repo has an active merge queue (deviation 4) while AGENTS.md How a green PR lands describes arming auto-merge as a seat's only landing route without naming the queue. Successor named: the PM dispatch template, which carries the false 'no merge queue' line into the next round, and the #1686 dev who currently owns AGENTS.md. Not filed by me - AGENTS.md is governed and under active edit, and the gesture itself is unaffected, so this is a reading for the seat rather than a defect I can name a failing probe for.",
    "noted, not filed: ruleset 12187346 carries NO required_status_checks rule, so 'All CI checks must pass' is likewise not enforced by branch protection. It is kept because the ruling said to keep it and because it is true as practice, not as configuration - but anyone who later applies this card's reasoning to that bullet needs this reading first. Successor named: whoever next edits paragraph Getting Merged.",
    "noted, not filed: the R57 grading comment records 'REST is 403 for this session (verified with a control - the plain repo endpoint 403s too, so it is a blanket session block)'. From this container the plain repo endpoint returns 200 and only the legacy branch-protection endpoint 403s. The 403 is per-session, not per-repo, and the rulesets API is the route that works. Successor named: any future seat that reads that comment and concludes branch protection is unreadable here."
  ]
}

Generated by Claude Code

✅ ACCEPT (post-hoc) — PR #1813 MERGED `7ddc88b` · ⚠️ and it landed before this seat's review, which is the seat's own fault

repo:hotcrm seat · session session_017FzrA1G4U89KEMf7wfLmqq · R58, 2026-09-09T12:2xZ.

⚠️ The process error, stated first because it is mine

This card landed without a recorded ACCEPT preceding it. The dispatch order I wrote told the dev: "when every check has finished with none failed, mark ready and arm auto-merge (SQUASH)" — so the dev did exactly that, correctly, under the instruction it was given. ⛔ Not a dev deviation; it followed the order.

The order was wrong. The seat is the recorded reviewer, and the review has to precede the landing. Compare the same round:

card	what the dispatch said	what happened
#1730	same self-land wording	dev left the flip to the seat anyway (its contract forbids polling CI) ⇒ seat reviewed first ✅
#1792	same self-land wording	dev held at draft on an open question ⇒ seat reviewed first ✅
#1797	same self-land wording	dev's checks converged inside its run ⇒ it self-landed, and the seat never got the gate ⚠️
#1812	⛔ "leave the flip to the seat"	reserved correctly

⇒ the safe outcome on the first two was luck of timing, not design. ⭐ Correction carried into this round already: #1812's dispatch reserves the flip explicitly, and every dispatch from here does the same — the dev reports; the seat flips. The self-land wording only belongs on a card where the seat has consciously delegated the landing.

⛔ I am not reverting anything over this. The content is right (verified below), and a revert would cost more than the process gap did. The record exists so the next seat inherits the corrected template rather than the one that produced this.

The review, done properly against `origin/main` — ⛔ not against the report

I had independently verified this diff before it merged (2 files, the ruled edit), and re-verified on the merged ref:

item	reading
merged	`7ddc88b` on `origin/main`, read after a fetch ⛔ not off a PR field
files	2: `CONTRIBUTING.md` (+4/−1) and the changeset — inside the declared surface ✅
the ruled edit	§Getting Merged's approval bullet is replaced by the pointer to `AGENTS.md` §How a green PR lands ✅
⛔ the other three bullets	CI, no-conflicts and squash all intact — verified in the section text on `main` ✅
stale claim	`approval required` now returns 0 in `CONTRIBUTING.md`; control `squash-merged` still returns 1, so the zero is real ✅
⛔ branch protection	untouched, as ruled — option D was refused, not deferred ✅
`AGENTS.md`	not touched — correct; it was governed, in flight on #1686, and this card only cites it ✅

⭐⭐ The dev closed the ruling's own recorded confidence gap

Batch #99 stated its limit explicitly: "no seat has read the actual branch protection … if it does require approvals on some path, the pointer still holds, and the maintainer should say so here." The dev read it: the active main ruleset (id 12187346) carries a pull_request rule whose required_approving_review_count is 0.

⇒ the finding is stronger than the card claimed. The line did not merely contradict practice (PR #1795 merging with get_reviews = []); it contradicted the repo's own configuration. The ruling's C is now the correct answer on both readings, and its confidence gap is closed rather than merely noted.

⭐ It also took the Zone 3 suggestion in the right direction — following the wording that actually landed in AGENTS.md rather than the ruling's earlier paraphrase: "a PR whose checks have all finished with none failed" instead of "green", because that section is explicit that a skipped check (Check Changeset under skip-changeset) and one that never ran (link-check on a Markdown-free diff) are not failures. Transcribing "green" would have written a stricter rule than the one AGENTS.md states.

Third REST correction of the round

This makes three independent falsifications of the seat post's REST claims in one round: labels are enumerable (#1792), and now branch protection / rulesets are readable (#1797). Combined with #1792's finding that only /search/issues is 403, seat-post §5.8's "blanket session block" and §5.9's "structurally blind" are both wrong as written and get rewritten in the R58 refresh. ⛔ Probe per container; ⛔ never inherit either result — including this one.

pm:dispatched stripped; type set to Task (the grading assigned it, but the field was never written — a half-state, healed here).

Generated by Claude Code

Navigation Menu

Repository navigation

`CONTRIBUTING.md` §Getting Merged states "At least one approval required" — measured: PRs land with zero reviews, and it is now the second answer to the question #1742 just wrote down #1797

The contradiction, measured

Why it is worth a card rather than a shrug

Related measurement, same section

What a fix would decide

First-touch grading → `needs-user-decision` + `documentation`, type `Task`

The measurement, re-verified

Why it is more than a stale sentence

维护者速读

Ruling recorded — C: replace the "at least one approval" line with a pointer to `AGENTS.md` §How a green PR lands; no branch-protection change (director seat, decision batch #99, 2026-09-08)

Zone 1 — the ruling (⛔ not re-litigable)

Zone 2 — PM mechanism assumptions (⚠️ must be tested; falsifying one is the highest-value thing you can return)

Zone 3 — suggested route (⛔ optional, measurement beats it)

Landing

Report

✅ ACCEPT (post-hoc) — PR #1813 MERGED `7ddc88b` · ⚠️ and it landed before this seat's review, which is the seat's own fault

⚠️ The process error, stated first because it is mine

The review, done properly against `origin/main` — ⛔ not against the report

⭐⭐ The dev closed the ruling's own recorded confidence gap

Third REST correction of the round

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

CONTRIBUTING.md §Getting Merged states "At least one approval required" — measured: PRs land with zero reviews, and it is now the second answer to the question #1742 just wrote down #1797

Description

The contradiction, measured

Why it is worth a card rather than a shrug

Related measurement, same section

What a fix would decide

Activity

huangyiirene commented on Sep 8, 2026

First-touch grading → needs-user-decision + documentation, type Task

The measurement, re-verified

Why it is more than a stale sentence

维护者速读

os-zhuang commented on Sep 8, 2026

Ruling recorded — C: replace the "at least one approval" line with a pointer to AGENTS.md §How a green PR lands; no branch-protection change (director seat, decision batch #99, 2026-09-08)

zhuangjianguo commented on Sep 9, 2026

Zone 1 — the ruling (⛔ not re-litigable)

Zone 2 — PM mechanism assumptions (⚠️ must be tested; falsifying one is the highest-value thing you can return)

Zone 3 — suggested route (⛔ optional, measurement beats it)

Landing

Report

zhuangjianguo commented on Sep 9, 2026

zhuangjianguo commented on Sep 9, 2026

✅ ACCEPT (post-hoc) — PR #1813 MERGED 7ddc88b · ⚠️ and it landed before this seat's review, which is the seat's own fault

⚠️ The process error, stated first because it is mine

The review, done properly against origin/main — ⛔ not against the report

⭐⭐ The dev closed the ruling's own recorded confidence gap

Third REST correction of the round

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`CONTRIBUTING.md` §Getting Merged states "At least one approval required" — measured: PRs land with zero reviews, and it is now the second answer to the question #1742 just wrote down #1797

First-touch grading → `needs-user-decision` + `documentation`, type `Task`

Ruling recorded — C: replace the "at least one approval" line with a pointer to `AGENTS.md` §How a green PR lands; no branch-protection change (director seat, decision batch #99, 2026-09-08)

✅ ACCEPT (post-hoc) — PR #1813 MERGED `7ddc88b` · ⚠️ and it landed before this seat's review, which is the seat's own fault

The review, done properly against `origin/main` — ⛔ not against the report