No way to edit a published issue body (kind:1621): CLI and Desktop can both create and change status, but never revise content
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
## What's missing
A NIP-34 issue (kind:1621) is a regular, non-replaceable event. Once published there is no way to change its `content` or its `subject`/`t` tags — not from the CLI (`buzz issues` is `create`/`get`/`list`/`status`) and not from Desktop (`desktop/src/features/projects/issueMutations.ts` exposes `publishProjectIssue` only; there is no update/edit mutation).
Status is separately mutable via kinds 1630–1633, so lifecycle is fine. The body is not.
## Why it matters
Any planning workflow where an issue is a **living document** is impossible on Buzz Projects. Concretely, the wayfinder planning skill keeps a "map" issue that is rewritten every session as decisions land and scope shrinks. On GitHub that's `gh issue edit`. On Buzz the only options are to close-and-recreate (losing the id every other event references) or to keep the map outside Projects entirely.
More mundane cases hit this too: fixing a typo, correcting a spec, adding acceptance criteria after triage, expanding a one-line issue into a real description.
## Possible directions
1. **NIP-34 revision events**, mirroring what PRs already do. `buzz pr update` (kind 1619, `KIND_GIT_PR_UPDATE`) exists and `projectPullRequests.mjs` folds updates onto the root PR. An `issues update` with the same shape would be consistent with the codebase's existing pattern, and would preserve edit history.
2. **Addressable issues** (kind 30000-range with a `d` tag) so edits are plain replaceable-event upserts, like `buzz notes set`. Cleaner, but diverges from NIP-34 and breaks `e`-tag references.
(1) looks like the smaller, more consistent change — the client-side fold logic already exists for pull requests.
## Workaround in the meantime
`buzz notes` (NIP-23, kind 30023) is an editable upsert keyed by `(author, slug)`, so a living planning document can live there and link to the issues. That works but it's outside Projects, so it doesn't show up in the project view.
Verified against `block/buzz` @ ab3af828 and a live relay.
Contributor guide
Assessment
This issue has not been assessed yet.