no CLI path clears a description: an accidental body is permanent once written #12

• 
  @ogirardot opened this issue · Sep 7, 2026

  Spun out of the review of !1 (issue #7), where it was deliberately left out of
  scope: #7's acceptance criteria require --body ""/blank stdin to be refused
  locally, per issue #94, and !1 implements that.

  The gap

  issue create -b "" is accepted — an empty description is a legitimate state, and
  resolveBody (not requireBody) lets it through. But every edit path refuses a
  blank body:

  $ rickub issue edit 7 -b ""
  rickub: --body must not be blank: refusing to blank the description (omit --body to leave it as it is)
  

  So a description added by mistake — a stray paste, a wrong heredoc — can be
  written but never removed from the terminal. It is the same shape as #94: a state
  the API supports and no non-browser client can reach.

  The client already can: IssuePatch{Body: &""} serialises to "body":"" and
  internal/api/endpoints_patch_test.go pins exactly that on the wire. The
  capability exists and is unreachable from the CLI.

  Why the guard is still right

  The guard is not the bug. #94 was a body destroyed silently by a command the
  user believed had posted it, so "blank means refuse" is the correct default for a
  flag that is normally carrying content. What is missing is an explicit way to say
  "yes, I mean empty" — the same shape as issue label --clear and
  issue milestone --clear, which exist for exactly this reason.

  Suggested shape

  --clear-body on mr edit / issue edit: mutually exclusive with --body,
  sends "body": "", and reports what it did. Refusing a blank --body stays
  untouched — the explicit flag is what distinguishes intent from accident, which a
  bare empty string never can.

  Acceptance criterion

  rickub issue edit <n> --clear-body empties the description and says so;
  rickub mr edit <n> --clear-body likewise; --body and --clear-body together
  is refused locally; a blank --body is still refused with today's message.

Sign in to comment.