Issue 1 of #780: gh pr list --json whitelist is unintuitive.
merged / closedAt / mergedAt / mergeCommit are basic per-PR
fields already returned by GitHub list API and already
projected by prSummary(); they were previously rejected by
the prListJsonFields validator. Add them to PR_LIST_JSON_FIELDS
so callers no longer have to fall back to a pr view per-PR.
mergeable / mergeStateStatus / statusCheckRollup remain
closeout fields that still require a per-PR pr view.
Issue 2 of #780: gh issue close --comment only accepts short
inline text; long Markdown closeout bodies had to escape
backticks, newlines and \\ in shell, then bash heredoc.
Add --comment-file <file|-> to issue close/reopen, which
mirrors the existing --body-file plumbing through
readIssueLifecycleCommentBody. --comment and --comment-file
are mutually exclusive; both remain mutually exclusive with
--body and --body-file.
Verified live:
- gh pr list --repo pikasTech/HWLAB --state closed --json
number,merged,mergedAt,closedAt,mergeCommit returns real data
(number=781 merged=true mergedAt=2026-06-03T14:22:32Z
closedAt=2026-06-03T14:22:32Z
mergeCommit={oid:3ac4cf8d2e4dfadb251cad53bf35d08b86d73840})
- gh pr list --json mergeable,statusCheckRollup still rejected
with 'unsupported closeout field(s)' pointing to pr view
- gh issue close 780 --comment-file /tmp/test-close-comment.md
--dry-run reports comment.planned=true bodyChars=155
bodySource.kind=body-file
- gh issue close 780 --comment 'x' --comment-file /tmp/x.md
--dry-run fails with --comment and --comment-file are
mutually exclusive
Capture the regression class behind #748 (orphan el.<removed-field>.addEventListener after a button is removed from index.html): Bun.build is transpile-only so web:check does not catch it, and the runtime crash only surfaces on init.
Adds the minimal closeout checks (grep dist + curl 19666 + control-plane status) and a one-liner orphan listener scan that authors can run while the PR is open.
Refs: pikasTech/HWLAB#748
Documents that gh issue comment create/delete, close, reopen, update,
edit, and board-row all now accept the owner/repo#number positional
shorthand that gh issue read/view and gh pr * already accept, completing
the shorthand parity across the gh subcommand.
The companion code change (scripts/src/gh.ts) was committed in the
previous commit; this doc update adds the long-term reference for the
new behavior and links it to the HWLAB #621 CLI acceptance friction
that motivated it.
The HWLAB v0.2 #744 fix was originally committed directly to v0.2 instead
of going through the canonical feature branch + PR flow. This documents:
- the canonical v0.2 worktree + PR sequence (trans G14:/root/hwlab-v02
worktree add, fix/issue<N>-* branch, UniDesk CLI gh pr create/merge,
fixed repo git pull --ff-only)
- a bounded recovery procedure when a direct commit has already landed
on v0.2 (single-commit case, --force-with-lease, autostash preservation,
cherry-pick onto the existing worktree branch, re-merge through PR)
- the v0.2 CLI verification gap: no layout-browser smoke exists for
19666/19667 (dev-cloud-workbench-layout-smoke.mjs is hard-coded to
16666/16667), so closeout must combine web:check + web:build,
control-plane status --lane v02, and direct curl/grep probes against
19666/19667
Closes CLI friction observed during the #744 v0.2 fix process.
gh issue comment create/delete, close, reopen, update, edit, and board-row
all now accept the owner/repo#number positional shorthand that gh issue
read/view and gh pr * already accept. This removes the friction of having
to split shorthand into a separate --repo flag and a bare number, and
keeps error messages consistent with the existing shorthand validation.
Discovered during HWLAB #621 CLI acceptance: posting the acceptance
results to the issue required gh issue comment create pikasTech/HWLAB#621,
which previously failed with 'issue comment create must be a positive
integer' and forced a separate --repo flag.