Skip to content

governed guard: an authorized APPROVED review lifts the >5000-line SIZE limb, as it already lifts Tier H paths #20153

Description

@objectstack-fleet

Ruled: maintainer 「所以阈值写死成 5000 行 , 维护者已经批准了就是可以合并。」 and 「应该立一个 skills 卡片」 · chat with session session_013RWUA7bNq5bRhehLPqXwMg, 2026-09-27

Provenance

  • Who: the maintainer.
  • Where: the maintainer's chat with session session_013RWUA7bNq5bRhehLPqXwMg, 2026-09-27.
  • Why it came up: the maintainer asked why objectstack#20125 did not merge. It was enqueued twice (01:00Z and 03:02Z) and dequeued twice with CI_FAILURE. The cause was Governed Surface Queue Guard exit 8, the SIZE leg: about 11.5k changed lines, over 5,000, although os-zhuang (in GOVERNED_APPROVERS) had approved it. The Tier H path leg was already satisfied by that approval.
  • Verbatim: 「所以阈值写死成 5000 行 , 维护者已经批准了就是可以合并。」, then 「应该立一个 skills 卡片」.

The rule today

scripts/pm/check-governed-queue-guard.mjs, header section "NO APPROVAL LIFTS THIS LIMB":

An authorized APPROVED review lifts a Tier H path because the 2026-08-27 ruling said so of PATHS; nothing has said it of the NUMBER […] Widening it is a one-line maintainer decision — in the sibling, where the predicate lives.

So a PR with more than 5,000 changed lines can only land through the maintainer's bypass-rules merge button, even after an authorized approval. That button skips the merge queue's speculative build on the latest main.

The ruling this card implements

An authorized APPROVED review lifts the SIZE limb exactly as it lifts a Tier H path. "Authorized" means an account in GOVERNED_APPROVERS. After the approval, the owning seat lands the PR through the queue ("席位落地"), under the same predicate as the path leg:

  • latest-decisive review per account;
  • any commit (the 2026-09-04 unpinning);
  • dismissed, superseded and unauthorized approvals never count;
  • an unreadable review list fails closed.

The maintainer's direct merge stays the other landing, unchanged.

Scope

  • scripts/pm/check-governed-merges.mjs: the SIZE predicate, its header section "The SIZE predicate", landsByHumanMerge (or the verdict it reads), and the self-tests that pin "no approval lifts size". The threshold (5,000), the strict > and "generated files included" are unchanged.
  • scripts/pm/check-governed-queue-guard.mjs:
  • Protocol text that states the old rule:
    • AGENTS.md (class (c), "lands only by a human merge");
    • .claude/skills/pm-dispatch/SKILL.md:187;
    • .claude/skills/pm-dispatch/references/landing-operations.md:58;
    • any other place that still says the size limb needs a human merge (grep 5,000 / 5000 / HUMAN_MERGE_LINE_THRESHOLD / size limb across scripts/pm/**, AGENTS.md, .claude/**). Keep the skill line ratchet (check-skill-line-ratchet.mjs) green.

Out of scope

  • ⛔ The FORK limb: unchanged, no approval lifts it.
  • ⛔ The post-merge detection audit still lists oversized landings, as a report. It may note the approval that lifted each one.
  • ⛔ No change to GOVERNED_APPROVERS, to the Tier S rule, or to branch protection / rulesets (the maintainer's).

Acceptance

  • merge_group with one PR over 5,000 changed lines:
    • an authorized APPROVED review, on any commit → exit 0, and the SIZE block prints the lift: approver, commit, and this card;
    • no approval, an unauthorized one, or a dismissed one → exit 8, as today;
    • an unreadable size is still exit 9.
  • The seat-side check-governed-merges.mjs --pr N agrees with the queue leg on the same PR.
  • --self-test of both scripts passes, with new pins for the lift and for each non-lift case above.
  • Once this lands, objectstack#20125 (already approved by os-zhuang) passes the guard through the queue with no new approval.

Landing

This card's own PR touches AGENTS.md and .claude/**, so it is Tier H. It waits for the maintainer's hand or an authorized APPROVED review, per the current rule.


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions