feat: add pr view and checks (task 0009) #9

alexion · 2026-07-12T20:23:00-04:00

alexion commented

2026-07-12 20:23:00 -04:00

Task: .claude/tasks/0009-pr-view-and-checks.md

Summary

Adds pr view <n> and pr checks <n>.

pr view uses the three-call fetch pattern (ADR 0006): the PR and its reviews are fetched in parallel, then the head commit's combined status once the head SHA is known — so checks, comment_count, and review_count are always in the default output. --comments, --reviews, and --full behave as on issue view: 800-char comment truncation with cleanBody, --full suppressing all truncation, and --reviews exposing Gitea's official/stale fields plus each review's inline comments.
pr checks renders the checks summary line above a { name, conclusion } list, or a scalar no-CI message when no statuses exist.

Notable decisions / deviations

The state→conclusion mapping and summary live in a new src/checks.ts (summarizeChecks pure core + fetchChecks shell); unknown/future commit-status states fall through to pending rather than being reported as a pass/fail they aren't.
New generic renderScalar(noun, value, help) in src/render.ts emits the no-CI checks: line unquoted (TOON reads a string scalar to end of line), matching the summary line's treatment.
commentRows was extracted from issue.ts into src/comment.ts and is now shared by issue view --comments and pr view --comments.
merged renders as no when open, or the merge time (relative) once merged, matching gh-axi.

Review

Risk

Overall: Medium

Blast radius — Low: additive pr view/pr checks subcommands plus small shared helpers (commentRows, renderScalar, fetchReviews refactor); no existing behavior altered beyond a clean extraction.
Reversibility — Low: new files and dispatch branches; trivial to drop with no migrations or persisted state.
Test coverage — Low: three new test files (checks unit + pr-checks + pr-view fixture-server integration) cover states, truncation, no-checks, and 404 paths.
Sensitive domain — Low: read-only CI/review reporting; no auth, permissions, mutations, or concurrency beyond bounded parallel fetches.
Size & complexity — Medium: ~1100 diff lines, but mostly tests and declarative rendering; control flow is straightforward.
Runtime criticality — Low: local dev-facing CLI tooling, not a production hot path.

Standards (unaddressed)

Duplicated Code (judgement call) — buildReviewRows inline comment mapping vs the freshly-extracted commentRows. Kept separate deliberately: review inline comments are a different entity (PullReviewComment, with path and no displayed timestamp) than issue/PR comments ({ author, created, body }); forcing reuse would mean parameterizing the middle field, obscuring more than it saves.
Minor judgement calls (Primitive Obsession on checksSummary: string, Data Clumps on the { host, full, now } option trio) were judged acceptable — the string is the only field the detail row needs, and the option-object trio mirrors the existing issue.ts idiom.

Spec (unaddressed)

pr checks no-CI label wrinkle — the summary string is labeled summary: when checks exist but checks: in the empty case. Intentional: it matches the spec's literal empty-state form (checks: "0 passed, 0 failed — …", spec line 292) and gh-axi's shape.
The one coverage gap the Spec review raised (no pr view test driving a >500-char body through the truncation hint) was addressed — a truncation test was added.

Task: `.claude/tasks/0009-pr-view-and-checks.md` ## Summary Adds `pr view <n>` and `pr checks <n>`. - **`pr view`** uses the three-call fetch pattern (ADR 0006): the PR and its reviews are fetched in parallel, then the head commit's combined status once the head SHA is known — so `checks`, `comment_count`, and `review_count` are always in the default output. `--comments`, `--reviews`, and `--full` behave as on `issue view`: 800-char comment truncation with `cleanBody`, `--full` suppressing all truncation, and `--reviews` exposing Gitea's `official`/`stale` fields plus each review's inline comments. - **`pr checks`** renders the checks summary line above a `{ name, conclusion }` list, or a scalar no-CI message when no statuses exist. ### Notable decisions / deviations - The state→conclusion mapping and summary live in a new `src/checks.ts` (`summarizeChecks` pure core + `fetchChecks` shell); unknown/future commit-status states fall through to `pending` rather than being reported as a pass/fail they aren't. - New generic `renderScalar(noun, value, help)` in `src/render.ts` emits the no-CI `checks:` line unquoted (TOON reads a string scalar to end of line), matching the summary line's treatment. - `commentRows` was extracted from `issue.ts` into `src/comment.ts` and is now shared by `issue view --comments` and `pr view --comments`. - `merged` renders as `no` when open, or the merge time (relative) once merged, matching gh-axi. ## Review ### Risk **Overall: Medium** - Blast radius — Low: additive `pr view`/`pr checks` subcommands plus small shared helpers (`commentRows`, `renderScalar`, `fetchReviews` refactor); no existing behavior altered beyond a clean extraction. - Reversibility — Low: new files and dispatch branches; trivial to drop with no migrations or persisted state. - Test coverage — Low: three new test files (checks unit + pr-checks + pr-view fixture-server integration) cover states, truncation, no-checks, and 404 paths. - Sensitive domain — Low: read-only CI/review reporting; no auth, permissions, mutations, or concurrency beyond bounded parallel fetches. - Size & complexity — Medium: ~1100 diff lines, but mostly tests and declarative rendering; control flow is straightforward. - Runtime criticality — Low: local dev-facing CLI tooling, not a production hot path. ### Standards (unaddressed) - **Duplicated Code (judgement call) — `buildReviewRows` inline comment mapping vs the freshly-extracted `commentRows`.** Kept separate deliberately: review inline comments are a different entity (`PullReviewComment`, with `path` and no displayed timestamp) than issue/PR comments (`{ author, created, body }`); forcing reuse would mean parameterizing the middle field, obscuring more than it saves. - Minor judgement calls (Primitive Obsession on `checksSummary: string`, Data Clumps on the `{ host, full, now }` option trio) were judged acceptable — the string is the only field the detail row needs, and the option-object trio mirrors the existing `issue.ts` idiom. ### Spec (unaddressed) - **`pr checks` no-CI label wrinkle** — the summary string is labeled `summary:` when checks exist but `checks:` in the empty case. Intentional: it matches the spec's literal empty-state form (`checks: "0 passed, 0 failed — …"`, spec line 292) and gh-axi's shape. - The one coverage gap the Spec review raised (no `pr view` test driving a >500-char body through the truncation hint) was addressed — a truncation test was added.

alexion added 1 commit 2026-07-12 20:23:01 -04:00

feat: add pr view and checks (task 0009)

CI / test (pull_request) Successful in 36s

Details

CI / test (push) Successful in 37s

Details

16d2f29f19

Add `pr view <n>` and `pr checks <n>`, built on the truncation machinery
and review fetches from earlier slices.

`pr view` uses the three-call fetch pattern (PR + reviews in parallel, then
the head commit's combined status) so `checks`, `comment_count`, and
`review_count` are in the default output; `--comments`, `--reviews`, and
`--full` behave as on `issue view`, with `--reviews` exposing Gitea's
`official`/`stale` fields plus per-review inline comments.

`pr checks <n>` renders the checks summary line and the `{ name, conclusion }`
rows, or the scalar no-CI message when no statuses exist.

The state→conclusion mapping and summary live in a new `src/checks.ts`;
`commentRows` is extracted into `src/comment.ts` and shared with `issue view`.

alexion merged commit 16d2f29f19 into main

2026-07-13 16:54:51 -04:00

alexion deleted branch task-0009-pr-view-and-checks

2026-07-13 16:54:51 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: alexion/gitea-axi#9