Make obot-merge --check report mergeability, not just policy

[obotclaw[bot]]

Found while building /session-reviews (2026-07-29): obot-merge 52 -R jwildfire/obot.agent --check answered CHECK PASSED - policy permits merging PR #52 for a PR whose state is CONFLICTING/DIRTY. That is correct by design — --check is a policy gate — but it reads like "this will merge", which is exactly the wrong impression to give right after Jeremy approves something.

Idea: have --check also print mergeable / mergeStateStatus and say plainly when the PR cannot merge as it stands, so an approved merge does not fail at the last step. The reviewing agent currently has to fetch that separately (scripts/reviews-queue does, and buckets conflicts as "back to the agent").

Timing: obot.agent#61 is refactoring the merge-policy resolver right now — this either folds in there or lands straight after.

— captured in session, 2026-07-29 06:36 EDT

[obotclaw[bot]]

Triage: classified as an update to existing work — this folds into #140's Design (per-repo write policy) alongside obot.agent#65; the natural landing zone is the merge-policy resolver refactor in obot.agent#61. The --check output will report mergeable/mergeStateStatus plainly so a policy pass never reads as "this will merge". Thread stays open until the design lands.

---

This comment was drafted by Claude Code using Fable 5 and reviewed by @jwildfire

[obotclaw[bot]]

Design posted, this idea folded in: 140_design.html §6 — awaiting @jwildfire's review, nothing implemented yet.

• --check reports policy and mergeability as two separate verdicts with separate verbs, plus a table translating each mergeStateStatus (CLEAN, UNSTABLE, BEHIND, DIRTY, BLOCKED, DRAFT, HAS_HOOKS) into a plain sentence and who has to act — the same fields and vocabulary scripts/reviews-queue already uses.
• Measured while designing it: mergeable/mergeStateStatus return UNKNOWN on the first query and settle a couple of seconds later (obot.agent#52 → CONFLICTING/DIRTY on the second attempt). So the value obot-merge prints in its header line today is usually meaningless — a bounded poll (3 attempts, ~2 s apart) is what makes the field usable at all.
• A related defect surfaced on the real merge path: the attested lane posts the "🔒 explicitly approved by @jwildfire" audit comment before attempting the merge, so a conflicting PR gets an audit trail for a merge that never happened. The mergeability check moves ahead of the side effects.
• Two decisions for @jwildfire in §8: D6 — keep exit 0 on a policy pass with mergeability as a separate line (proposed) vs a new exit 3 for "policy OK, GitHub will not merge"; D7 — report failing/pending checks now and leave the refusal to obot.agent#37's CI gate, or fold Requirement: QT Safety Explorer Phase 2 — QTcI, multi-interval, drill-down, hysteresis & guided ICH-E14 workflow #37 in.
• Landing zone: one PR in obot.agent alongside the carve-out enforcement (#65). This thread closes when it merges.

---

This comment was drafted by Claude Code using Opus 5 and reviewed by @jwildfire

[obotclaw[bot]]

Re-triage 2026-08-14 (👯🤖 blockers-tails). Classification unchanged — update to existing work. No new agent action available: this thread is now blocked on @jwildfire, not on the design.

• 140_design.html §6 has carried the answer since 2026-08-01, and §10 names the rollout explicitly: one PR in obot.agent closing #65 and this thread. Nothing can merge until D1-D8 are answered — 13 days open as of tonight.
• Tonight independently corroborated §6's finding that the attested lane posts its audit comment before attempting the merge. Working the other way round, that side effect turned out to be the only reliable lane marker available after the fact: obot.agent#83's body claimed the attested lane, and the absence of a 🔒 audit comment is what proved it actually merged on the standard lane. Detail in #65.
• That is a second live instance of the carve-out hole after Requirement: reaction feedback and trigger reliability for the Ideas triage pipeline #61's, which strengthens the case for the same single PR — so this idea and Next/Back in safety-viz example pages #65 still belong together, exactly as §10 has it.

Thread stays open, as the 2026-08-01 comment said it would, until that PR merges.

---

This comment was drafted by Claude Code using Opus 5 and reviewed by @jwildfire