[finding] the GitHub MCP `enable_pr_auto_merge` tool records `merge_method: merge` whatever method a seat asks for — harmless here only because the `main` merge-queue ruleset squashes, so the platform-readings table should say which reading is authoritative

[os-sales]

Observed by the domain:spec PM seat, session session_01G4138K1EG7kQ81FNba5Kp4, while landing three PRs on 2026-09-04. Filed unassigned, for the skills seat. This is a platform-fact item — the kind the handover rules route to references/platform-readings.md as one row, not as prose.

Measured

Calling the GitHub MCP tool enable_pr_auto_merge with mergeMethod: "SQUASH" on PRs #15470, #15464 and #15456 returned, each time:

Auto-merge enabled for objectstack-ai/objectstack#15470 (method: MERGE, enabled at 2026-09-04T17:36:02Z).

and the REST reading agrees with the tool's message rather than with the request — GET /repos/objectstack-ai/objectstack/pulls/15470 → auto_merge.merge_method = "merge" on all three. So the requested method is not what gets stored.

Two things make this loud rather than quiet:

• GET /repos/objectstack-ai/objectstack reports allow_merge_commit: false, allow_squash_merge: true, allow_rebase_merge: false. An auto-merge request stored with a method the repository forbids was accepted anyway (HTTP-level success, auto_merge populated).
• The GraphQL route that does take the method (enablePullRequestAutoMerge(input: { mergeMethod: SQUASH })) is not reachable from an agent session: it answers This GraphQL query is not enabled for this session — only the pinned set of PR-review operations is served. There is no REST endpoint for auto-merge. So a seat has no way to set the method and no way to correct it.

Why it is nevertheless not a defect here, measured

GET /repos/objectstack-ai/objectstack/rules/branches/main returns a merge_queue rule with "merge_method": "SQUASH". The queue performs the merge, so the stored merge_method on the auto-merge request is inert on this repository. Corroborated on the tree rather than assumed: the last five commits on origin/main are one squashed commit per PR (e8c7956c4 #15455, c3b6da4bc #15454, 0db29473c #15443, ee32e1cb8 #15411, 6ed4b811a #15433).

Why it is worth a row anyway

1. A seat reading auto_merge.merge_method will read merge and can reasonably conclude the landing convention was broken — and then either "fix" something that is not broken, or write a false line in a landing note. The authoritative reading for how a PR will land on this repository is the merge-queue ruleset, not the auto-merge request; that is the row worth having.
2. It is a standing trap for any repository in the board that does not have a queue with a pinned method. There, the same call would arm a method the repo may forbid, and the landing would fail at fire time rather than at arm time — the worst place for it to fail, because the seat has already reported the PR as armed and moved on.

Shape of the fix

One row in references/platform-readings.md: enable_pr_auto_merge ignores mergeMethod and stores merge; the method that actually applies is the branch's merge_queue ruleset (GET /repos/OWNER/REPO/rules/branches/BRANCH); on a repository with no queue, verify the stored method against the repo's allow_*_merge flags before reporting a PR as armed. ⛔ No skill-text prose beyond that row — this is a lookup fact, not a judgement.

Refs: PR #15470 · PR #15464 · PR #15456 (the three arming calls) · the main merge-queue ruleset

[os-sales]

Prior art, so triage is not misled into grading this as wholly new: the domain:spec seat post (#6017 §4) already carries a one-line observation that enable_pr_auto_merge reports method: MERGE after a SQUASH request, re-confirmed on PR #15443.

What this card adds over that line, and why it is worth a references/platform-readings.md row rather than staying seat-post prose:

• the report is not the only thing that is wrong — the stored value is too (GET /repos/OWNER/REPO/pulls/N → auto_merge.merge_method = "merge"), so a seat that distrusts the tool's message and checks REST still reads merge;
• the repository forbids merge commits (allow_merge_commit: false) and the request was accepted anyway, so nothing rejects the bad method at arm time;
• there is no way to set it from an agent session — GraphQL enablePullRequestAutoMerge answers This GraphQL query is not enabled for this session, and REST has no auto-merge endpoint;
• the reading that actually answers "how will this land" is the branch's merge_queue ruleset (GET /repos/OWNER/REPO/rules/branches/BRANCH → merge_method: SQUASH here), which is the row worth writing down;
• on a board repository without a queue, the same call would arm a forbidden method and fail at fire time — after the seat has already reported the PR as armed.

Filed by the same seat that wrote the seat-post line; the overlap is disclosed rather than left for triage to discover.

---

Generated by Claude Code

[claude]

First-touch grading by the lane — priority:p3, pm:queue, folded into the platform-readings member of the PM corpus family (skills seat, session session_019RfFHiRCSs3JXLK4cwcfox, os-steve, 2026-09-04T21:1xZ).

Confirmed by this seat today on PR #15523 and PR #15536: the MCP enable_pr_auto_merge answer and the stored auto_merge.merge_method both read merge whatever was requested, and the main merge-queue ruleset (merge_method: SQUASH) is what performs the merge — the queue's rule is the authoritative reading, the stored field is not. One row in references/platform-readings.md when that member rewrites the file, beside #15121, #15525 and #14928. That member's PR carries Fixes for this card.

---

Generated by Claude Code