feat: add --fields to pr, issue, and run detail views

[Freudator86]

What this adds

--fields LIST|all on pr view, issue view, and run view.

pr list, issue list, and run list already narrow their output this way. The detail views did not, so an agent reading one value paid for the whole field set and then had to pipe the result through a JSON tool to extract it. That is the case principle 2 exists for, and the three list commands already establish the pattern this follows.

Design notes

• --fields all is the identity narrowing. The catalogs are built from the existing identity field lists in emission order, so --fields all reproduces an unnarrowed view byte for byte. A test pins that rather than trusting the ordering by eye.
• An absent --fields narrows nothing. A detail view's field set is not fixed -- edit_history_count is present only on hosts that serve content history -- so there is no static default list that could stand for "whatever this view returned". This is why the detail helper is separate from chooseFields rather than a third caller of it.
• A requested field the host did not supply is omitted, not emitted as null. Asking for edit_history_count against a host without content history returns the view without it, which is exactly what the unnarrowed view says about that field. Emitting an explicit null would claim the host answered.
• Scope is the primary object. On issue view the comment thread is untouched, and on run view the job list is untouched. Both are stated in --help.
• Invalid and duplicated values reuse the existing Invalid or duplicate --fields value error and its Valid fields: help, so the three list commands and the three detail views fail identically.

Contract

Additive: a new optional flag on three commands, no default output changed, no field renamed or repurposed. Minor-release shaped under docs/contract.md.

Verification

• npm run check passes: lint, typecheck, 242 tests (237 before, 5 added), smoke.
• npm run gen:skill regenerated; the byte comparison in check passes.

Live lanes: neither was run. I have no credential for a Forgejo host that these lanes may mutate, and the lanes mutate the repository they point at. Per CONTRIBUTING I am saying so rather than guessing.

What I did verify against a real host: the built CLI reading a live Forgejo 15.0.6+gitea-1.22.0 instance unauthenticated over a loopback forward, against a public repository:

$ forgejo-axi pr view 1 --repo axitest/axi-demo --fields state,merged,head_sha
pull_request:
  state: closed
  merged: true
  head_sha: d86904b3a505a149b77aad53789a4c0edca93800

--fields all against that same live pull request was byte-identical to the unnarrowed --json output. That exercises the real response shape but not the mutating lanes, so it is weaker evidence than lane 15 and I would not want it read as equivalent.

Summary by CodeRabbit

• New Features

  • Added --fields LIST|all to pull request, issue, and run detail views.
  • Supports selecting fields in the requested order while omitting unavailable fields.
  • all returns the complete primary object.
  • Issue comments and run job details remain unaffected by field selection.

• Documentation

  • Updated command help and usage documentation with field-selection behavior and validation details.

[Freudator86]

Separate from this change, and flagging it because it concerns your project rather than mine:

I found forgejo-axi absent from the AXI catalog and proposed a community entry for it — kunchenguid/axi#150. You are named as the author there.

I opened it because the tool is published, built on axi-sdk-js, and ships a generated skill, so the absence looked like nobody had added the line rather than a decision. But it is your project and not mine to list, so if you would rather submit it yourself, or would rather it not be listed at all, say so and I will close it.

That pull request does not assert an admission verdict. It records the source review at v1.2.0 including the principles that do not hold there — 7 (no setup hooks), and the --version half of 10 — and leaves the verdict to their reviewer. The two pull requests here that close those are referenced as proposals, not as merges.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b692d9a-7984-4435-a114-3ab986d5f8ae

📥 Commits

Reviewing files that changed from the base of the PR and between 3b28d09 and 1a54680.

📒 Files selected for processing (7)

• docs/contract.md
• skills/forgejo-axi/SKILL.md
• src/cli.ts
• src/help.ts
• test/cli.test.ts
• test/issue.test.ts
• test/run.test.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 6 remain after this review.

---

📝 Walkthrough

Walkthrough

The CLI adds --fields LIST|all to pull request, issue, and run detail views. It validates and projects requested fields while preserving unrelated comments, jobs, logs, and metadata. Documentation and tests define and verify the new behavior.

Changes

Detail field selection

Layer / File(s)	Summary
Field-selection contracts and command documentation docs/contract.md, skills/forgejo-axi/SKILL.md, src/help.ts	Documents --fields LIST|all, field ordering, unavailable-field omission, default behavior, and filtering scope.
Detail-field validation and response filtering src/cli.ts	Adds field catalogs, validates selections, projects pull request, issue, and run objects, and preserves unrelated response data.
Field-selection behavior tests test/cli.test.ts, test/issue.test.ts, test/run.test.ts	Tests selective fields, all fields, unavailable fields, invalid and duplicate fields, and unchanged comments or jobs.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to 1a546

This additive change narrows fields for existing detail views without changing default output or remote operations; no actionable merge-blocking risk remains after normal checks and review.

Sequence Diagram(s)

sequenceDiagram
  participant ViewCommand as Detail view command
  participant FieldProjection as Detail-field projection
  participant Response as Host response
  ViewCommand->>Response: Fetch detail response
  ViewCommand->>FieldProjection: Validate requested fields
  FieldProjection-->>ViewCommand: Return filtered primary object
  ViewCommand-->>Response: Preserve comments, jobs, logs, and metadata

Loading

Suggested reviewers: escidmore

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the addition of the --fields option to pull request, issue, and run detail views.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[escidmore]

@Freudator86 Thank you for the contributions! There's actually a pending upstream PR kunchenguid/axi#123 but the added voice probably doesn't hurt. I made a couple of tweaks to the PRs you submitted, and am going to merge them.