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
- 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.
- 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 @ ab3af82 and a live relay.
What's missing
A NIP-34 issue (kind:1621) is a regular, non-replaceable event. Once published there is no way to change its
contentor itssubject/ttags — not from the CLI (buzz issuesiscreate/get/list/status) and not from Desktop (desktop/src/features/projects/issueMutations.tsexposespublishProjectIssueonly; 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
buzz pr update(kind 1619,KIND_GIT_PR_UPDATE) exists andprojectPullRequests.mjsfolds updates onto the root PR. Anissues updatewith the same shape would be consistent with the codebase's existing pattern, and would preserve edit history.dtag) so edits are plain replaceable-event upserts, likebuzz notes set. Cleaner, but diverges from NIP-34 and breakse-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@ ab3af82 and a live relay.