pstack watch-pr: BLOCKED merge state with green CI reports ready — intentional, or gate it? #731

Question

assessGitHubMerge treats mergeStateStatus: "BLOCKED" with a non-failing rollup as allowed, so a PR that GitHub blocks for a non-CI reason (e.g. missing required review) is classified ready.

• Version: pstack 0.15.28 (harness/pstack/claude-code)
• Files: skills/poteto-mode/scripts/watch-pr/policy.ts (assessGitHubMerge, ~L8–27), types.ts (GitHubMergeAllowed ~L96–121)

if (args.mergeStateStatus === "BLOCKED") {
  if (headRollupState === "ERROR" || headRollupState === "FAILURE") return { kind: "refused", ... };
  return { kind: "allowed", basis: "rollup", ... };   // SUCCESS/EXPECTED/null land here
}

Reproduction (using the repo's own fakes)

fakeReader({
  facts: { mergeStateStatus: "BLOCKED" },
  fastPath: { kind: "checks", checks: [passingCheck()] },
  commitRollups: [{ oid: "head", state: "SUCCESS" }],
})
// ci.kind === "ci-clean"
// ci.github === { kind: "allowed", basis: "rollup", mergeStateStatus: "BLOCKED", headRollupState: "SUCCESS" }
// classifyPr(...) === { kind: "ready" }

gateReason blocks CHANGES_REQUESTED only, so REVIEW_REQUIRED is echoed into the proof but does not prevent ready.

Why I am asking rather than sending a patch

The types and the readiness truth table in policy.test.ts encode BLOCKED + PENDING -> allowed, and ignoring GitHub's merge state in favour of our own rollup looks deliberate. But BLOCKED + SUCCESS is unspecified and inherits allowed from the same Exclude<RollupState, "ERROR" | "FAILURE">, and that row is the one where required review hides.

So: is trusting the rollup over GitHub's merge state intentional?

• If yes, then there is a missing truth-table row worth pinning explicitly, and callers need to know that ready can mean "CI clean, non-CI merge gate possibly unmet".
• If no, two fixes suggest themselves:

A. Keep the distrust rule, block readiness: when mergeStateStatus === "BLOCKED" and the head rollup is settled (SUCCESS / EXPECTED / null), return a gate blocker — e.g. add "merge-state-blocked" to MergeGateReason and have gateReason report it when ci.kind === "ci-clean" and ci.github.mergeStateStatus === "BLOCKED". ci-clean stays truthful; only readiness changes.

B. Gate required review: block REVIEW_REQUIRED in gateReason exactly like CHANGES_REQUESTED. Smallest change, but it changes behaviour for every PR that merely awaits an approval.

Either way the truth table should gain the missing ["BLOCKED", "SUCCESS", ...] row.