Exploration: full field test of the PR UI (blocked merges, all merge strategies, commits land in repo) #600

New issue

Closed

opened 2026-09-15 21:21:44 +00:00 by crueber · 1 comment

crueber commented

2026-09-15 21:21:44 +00:00

Owner

What's requested

A full field test of the pull request UI, exercised end-to-end on real PRs: PRs that are blocked from merging (protection/failed checks/unresolved threads), every merge strategy the UI offers (merge commit, squash, rebase, fast-forward, etc.), and confirmation that merged commits actually land in the target repo — verified independently by cloning the repo and inspecting the resulting history, not just by trusting the UI.

Method

Test against the live dev instance with real throwaway PRs; keep probes small and use an obvious throwaway repository with named branches and PRs.

Acceptance criteria

Exercise the PR UI on multiple blocked merge cases; document which blockers appear and how the UI presents them
Exercise every merge strategy exposed in the UI on real PRs; document each outcome and any failures; ensure the repository is updated appropriate each time.
After each successful merge, verify the commits landed in the target branch by cloning the repo and inspecting history (git log), not only via the UI, but also using clone.
File findings as separate defect issues (one per discrete problem) with evidence

## What's requested A full field test of the pull request UI, exercised end-to-end on real PRs: PRs that are blocked from merging (protection/failed checks/unresolved threads), every merge strategy the UI offers (merge commit, squash, rebase, fast-forward, etc.), and confirmation that merged commits actually land in the target repo — verified independently by cloning the repo and inspecting the resulting history, not just by trusting the UI. ## Method Test against the live dev instance with real throwaway PRs; keep probes small and use an obvious throwaway repository with named branches and PRs. ## Acceptance criteria - [ ] Exercise the PR UI on multiple blocked merge cases; document which blockers appear and how the UI presents them - [ ] Exercise every merge strategy exposed in the UI on real PRs; document each outcome and any failures; ensure the repository is updated appropriate each time. - [ ] After each successful merge, verify the commits landed in the target branch by cloning the repo and inspecting history (`git log`), not only via the UI, but also using clone. - [ ] File findings as separate defect issues (one per discrete problem) with evidence

crueber added the

pull requests

label

2026-09-15 21:21:49 +00:00

crueber added this to the v1 milestone

2026-09-15 21:21:49 +00:00

crueber added the

bug

issues

labels

2026-09-15 21:22:08 +00:00

crueber referenced this issue

2026-09-15 23:05:26 +00:00

Draft PRs are unreachable: Draft is never set, so the draft merge-blocker and Draft phrase are dead #613

crueber commented

2026-09-15 23:05:34 +00:00

Author

Owner

Field test complete on a local scratch stack (:18099, throwaway repo field/demo — live instances untouched per standing rules). Three discrete findings filed with evidence: #611 (CLI ignores --data-dir for the store), #612 (UI over-blocks CHANGES_REQUESTED with no rule while server merges), #613 (draft PRs unreachable). What verified clean: dirty-conflict refusal (conflicts named, mergeable.state=dirty), required-reviews refusal once policy present (need 1 approvals, have 0; self-approval correctly not counted per #586b — note: unsatisfiable on auth-none single identity), failing-checks refusal (rejected by rule, UI wires policy to blockers), merge/squash/rebase all land correctly (clone-verified: 2-parent tip / single-parent combined / linear replay; clone history identical to API list). Fast-forward is not offered — by §5 exact-set design, not filed.