forge issue view and pr view cannot return the raw body, so a body edit has to be retyped #190

Closed
opened 2026-09-10 21:56:38 +01:00 by vnprc-agent · 0 comments
Contributor

Let forge issue view and forge pr view return the raw body, so an edit can be built from what is actually there rather than retyped from rendered output.

Primary goals:

  • Body edits stop being destructive — forge issue edit --body-file replaces the whole body, so appending one line today means reconstructing the body from the rendered view, and anything another writer added meanwhile is silently dropped.
  • Round-trip fidelity — the Markdown comes back byte-for-byte: no header block, no comments appended, no re-wrapping or indentation introduced by the renderer.
  • The same seam for PRs — forge pr view has the same gap and takes the same fix.
  • gh's established shape — gh issue view <n> --json body --jq .body already solves this; cli-design.md says copy it rather than invent a local flag.

Current state and specifics

forge issue view <number> prints a rendered summary — Issue #N:, State:, Author:, Labels:, Milestone: — then the body, then every comment. Its only flag is -R/--repo. There is no way to ask for the body alone, so a caller that wants to append a paragraph must strip the header, guess where the body ends and the comments begin, and trust that the renderer left the text untouched.

The REST fallback is not available: the token in ~/.netrc carries almost no API scope, and GET /api/v1/repos/<owner>/<repo>/issues/<n> returns 403 token does not have at least one of required scope(s): [read:issue].

The practical consequence is that an agent asked to add a line to an issue posts a comment instead, because a comment cannot clobber anything. That is the correct call under the current tool, but it files scope decisions in the comment thread instead of the Scope section where the next reader looks — which happened on allod/tools#182.

Scope

In scope: read-side output for issue view and pr view, and whichever field set is worth exposing beyond body. Out of scope: an in-place append or edit verb — once the raw body round-trips, the existing --body-file composes with it.

Let `forge issue view` and `forge pr view` return the raw body, so an edit can be built from what is actually there rather than retyped from rendered output. Primary goals: - **Body edits stop being destructive** — `forge issue edit --body-file` replaces the whole body, so appending one line today means reconstructing the body from the rendered view, and anything another writer added meanwhile is silently dropped. - **Round-trip fidelity** — the Markdown comes back byte-for-byte: no header block, no comments appended, no re-wrapping or indentation introduced by the renderer. - **The same seam for PRs** — `forge pr view` has the same gap and takes the same fix. - **`gh`'s established shape** — `gh issue view <n> --json body --jq .body` already solves this; `cli-design.md` says copy it rather than invent a local flag. ### Current state and specifics `forge issue view <number>` prints a rendered summary — `Issue #N:`, `State:`, `Author:`, `Labels:`, `Milestone:` — then the body, then every comment. Its only flag is `-R/--repo`. There is no way to ask for the body alone, so a caller that wants to append a paragraph must strip the header, guess where the body ends and the comments begin, and trust that the renderer left the text untouched. The REST fallback is not available: the token in `~/.netrc` carries almost no API scope, and `GET /api/v1/repos/<owner>/<repo>/issues/<n>` returns 403 `token does not have at least one of required scope(s): [read:issue]`. The practical consequence is that an agent asked to add a line to an issue posts a comment instead, because a comment cannot clobber anything. That is the correct call under the current tool, but it files scope decisions in the comment thread instead of the Scope section where the next reader looks — which happened on `allod/tools`#182. ### Scope In scope: read-side output for `issue view` and `pr view`, and whichever field set is worth exposing beyond `body`. Out of scope: an in-place append or edit verb — once the raw body round-trips, the existing `--body-file` composes with it.
vnprc closed this issue 2026-09-11 20:13:11 +01:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
allod/tools#190
No description provided.