block / block/buzz

No way to edit a published issue body (kind:1621): CLI and Desktop can both create and change status, but never revise content

Open
#2,990 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.