Summary
NIP-34 issues in Buzz can hold work items but cannot express the relationships between them. That gap blocks using Buzz as the issue tracker for agent work pipelines, where the structure between tickets is the substance.
Filing because #3348 (signed issue routing state) already covers one of the three gaps — this issue is to ask whether the other two are wanted, and in what shape, before anyone builds them.
What works today
Verified against the shipped buzz CLI and desktop/src/features/projects/:
| Operation |
Status |
| Create issue (kind:1621) |
works |
| Read / list issues |
works |
| Comment on issue |
works (ProjectIssuesPanel.tsx:233) |
Labels (t tags) |
works |
| Status open/resolved/closed/draft (1630-1633) |
works |
The three gaps
1. No parent/child relationship between issues.
No way to say "this issue is a child of that one." Agent planning workflows put an index/map issue at the top with child tickets beneath it; without hierarchy that collapses to a flat list.
2. No blocking / dependency edge.
No way to record "issue A is blocked by issue B." This is the load-bearing one: a "frontier" query — which tickets have all their blockers resolved and are therefore claimable — is not expressible. GitHub models this natively via issue dependencies; GitLab via blocking links.
3. No assignee / claim.
Appears to be addressed by #3348. Noting it for completeness, not asking for it twice.
Related: two intermediate board states are label-only
desktop/src/features/projects/projectIssues.mjs maps status:
1633 -> Triage protocol
1631 -> Done protocol
1632 -> Closed protocol
(default) Backlog
"In Progress" <- `t` tag in-progress/active client heuristic
"In Review" <- `t` tag in-review/review client heuristic
The code comments this honestly ("client-side heuristics, not protocol"). But it means those two states do not survive across clients — another NIP-34 reader places those issues in Backlog. If issue lifecycle is meant to model real work-in-progress, these may deserve protocol representation rather than tag convention.
Questions for maintainers
- Is issue hierarchy / dependency in scope for Buzz's NIP-34 usage, or is the position that issues stay flat and structure lives elsewhere?
- If in scope — preference between generic
e-tag relationship tags on kind:1621 vs. a separate relationship event kind? Happy to follow whichever direction you prefer.
- Should "In Progress" / "In Review" get protocol status kinds, or remain deliberately client-local?
Glad to send the PR for any of this once there is a direction. Asking first specifically to avoid building the wrong shape.
Summary
NIP-34 issues in Buzz can hold work items but cannot express the relationships between them. That gap blocks using Buzz as the issue tracker for agent work pipelines, where the structure between tickets is the substance.
Filing because #3348 (signed issue routing state) already covers one of the three gaps — this issue is to ask whether the other two are wanted, and in what shape, before anyone builds them.
What works today
Verified against the shipped
buzzCLI anddesktop/src/features/projects/:ProjectIssuesPanel.tsx:233)ttags)The three gaps
1. No parent/child relationship between issues.
No way to say "this issue is a child of that one." Agent planning workflows put an index/map issue at the top with child tickets beneath it; without hierarchy that collapses to a flat list.
2. No blocking / dependency edge.
No way to record "issue A is blocked by issue B." This is the load-bearing one: a "frontier" query — which tickets have all their blockers resolved and are therefore claimable — is not expressible. GitHub models this natively via issue dependencies; GitLab via blocking links.
3. No assignee / claim.
Appears to be addressed by #3348. Noting it for completeness, not asking for it twice.
Related: two intermediate board states are label-only
desktop/src/features/projects/projectIssues.mjsmaps status:The code comments this honestly ("client-side heuristics, not protocol"). But it means those two states do not survive across clients — another NIP-34 reader places those issues in Backlog. If issue lifecycle is meant to model real work-in-progress, these may deserve protocol representation rather than tag convention.
Questions for maintainers
e-tag relationship tags on kind:1621 vs. a separate relationship event kind? Happy to follow whichever direction you prefer.Glad to send the PR for any of this once there is a direction. Asking first specifically to avoid building the wrong shape.