docs(contributing): §Getting Merged points at AGENTS.md for who lands a PR

[zhuangjianguo]

Fixes #1797

Description

CONTRIBUTING.md §Getting Merged listed "At least one approval required" as the first of four merge conditions. It described nothing in force, and it was the second — and human-facing — answer to the question #1798 had just settled in AGENTS.md.

Ruling: decision batch #99 (issuecomment-5587165996), option C — replace the approval bullet with a pointer to AGENTS.md §How a green PR lands. Keep the CI, no-conflict and squash bullets. No branch-protection change (option D was refused, not deferred). No other file.

Type of Change

• Documentation update

Related Issues

Fixes #1797
Context, not closed by this PR: #1742 (the landing-posture ruling) and its PR #1798 (which landed the AGENTS.md section this now points at); PR #1795 (the zero-review measurement).

Changes Made

• CONTRIBUTING.md §Getting Merged — the approval bullet becomes a pointer to AGENTS.md §How a green PR lands. The other three bullets are byte-identical.
• .changeset/contributing-getting-merged-points-at-agents-md.md — empty frontmatter, the sanctioned "releases nothing" declaration.

The claim being removed, measured twice

The ruling recorded a 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). That gap is now closed. This container can read it, through the rulesets API rather than the legacy branch-protection API:

endpoint	result
GET /repos/objectstack-ai/hotcrm/branches/main/protection	403 Resource not accessible by integration — the legacy API, still unreadable
GET /repos/objectstack-ai/hotcrm/rulesets and /rulesets/12187346	200
GET /repos/objectstack-ai/hotcrm/rules/branches/main	200 — same rule set, as effective rules

Ruleset main (id 12187346, enforcement: active, ~DEFAULT_BRANCH) carries a pull_request rule with:

required_approving_review_count: 0
require_code_owner_review: false
require_last_push_approval: false
required_review_thread_resolution: false
require_extra_approval_for_unattributed_changes: true

So approvals are not required by configuration, not merely absent in practice. The removed sentence contradicted the repo's own settings. This confirms the ruling rather than disturbing it — C stands, and A was never needed.

The behavioural half re-verified: PR #1795 has zero reviews of any kind and merged 5m40s after creation.

Wording: the landed text, not the ruling's paraphrase

The ruling wrote its sentence before AGENTS.md §How a green PR lands existed in main. Per Zone 3, the landed text wins. Two deviations from the ruling's literal sentence, both declared:

1. "green" becomes "a PR whose checks have all finished with none failed". The landed section is explicit that a skipped check (Check Changeset under skip-changeset) and a check that never ran because a path filter excluded it (link-check on a diff carrying no Markdown) are not failures. "Green" would have re-introduced the looseness that section was written to remove.
2. AGENTS.md is a markdown link, not bare code span. The local precedent named in the ruling — §Publishing → docs/RELEASE_STRATEGY.md — writes it as docs/RELEASE_STRATEGY.md, a real link. Following the precedent. The link has no # fragment: AGENTS.md is a governed file under active edit (.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), nothing in this repo checks anchors in root .md files, and a rotted anchor would fail silently.

AGENTS.md is cited and not edited — it is a governed path and belongs to #1686 this round.

A falsified dispatch assumption: this repo does have a merge queue

The dispatch order states "This repo has no merge queue." That is false, on both readings:

• Ruleset 12187346 carries a merge_queue rule — merge_method: SQUASH, grouping_strategy: ALLGREEN, min_entries_to_merge_wait_minutes: 5.
• It is in use. PR docs(guides): drop the Settings path form from the email-templates sketch #1810's timeline, today: 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].

This changes nothing in the file — AGENTS.md §How a green PR lands does not mention a queue either, and writing one in would be scope this card does not have. It is reported for the seat, and it also explains PR #1795's 5m40s: the queue's own 5-minute wait. Branch will be squash-merged stays true — the queue merges with SQUASH.

Testing

• pnpm verify — see the gates table in the terminal report
• Linting passes
• Build succeeds
• New tests added — not applicable, no code changed

Checklist

• I have added a changeset — empty frontmatter, releasing nothing
• I have performed a self-review of my own code
• My changes generate no new warnings
• Any dependent changes have been merged and published — docs(agents): state how a green PR lands, and the governed-surface exception #1798 merged 2026-09-08T15:25:38Z, putting ### How a green PR lands in main

Additional Notes

Landing: CONTRIBUTING.md is not in the governed set (AGENTS.md, CLAUDE.md, .claude/**, .github/instructions/**), so once every check has finished with none failed this goes ready plus auto-merge, per the section it now points at.

🤖 Generated with Claude Code

https://claude.ai/code/session_017FzrA1G4U89KEMf7wfLmqq

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
hotcrm	Ignored		Sep 9, 2026 12:15pm UTC