20 lines
18 KiB
JSON
20 lines
18 KiB
JSON
{"id":"bd-149","content_hash":"c630e4d2780f0b1a9ca22cb471635970d83516c81e5a82518d28e54998c82f99","title":"Auth tokens expire too quickly","description":"## Summary\n\n[Brief description of the bug]\n\n## Steps to Reproduce\n\n1. Step 1\n2. Step 2\n3. Step 3\n\n## Expected Behavior\n\n[What should happen]\n\n## Actual Behavior\n\n[What actually happens]\n\n## Environment\n\n- OS: [e.g., macOS 15.7.1]\n- Version: [e.g., bd 0.20.1]\n- Additional context: [any relevant details]\n\n## Additional Context\n\n[Screenshots, logs, or other relevant information]\n","design":"## Root Cause Analysis\n\n[Describe the underlying cause once identified]\n\n## Proposed Fix\n\n[Outline the solution approach]\n\n## Impact Assessment\n\n- Affected features: [list]\n- Breaking changes: [yes/no and details]\n- Migration needed: [yes/no and details]\n","acceptance_criteria":"- [ ] Bug no longer reproduces with original steps\n- [ ] Regression tests added\n- [ ] Related edge cases tested\n- [ ] Documentation updated if behavior changed\n","status":"open","priority":1,"issue_type":"bug","created_at":"2025-11-03T19:54:10.671488-08:00","updated_at":"2025-11-03T19:54:10.671488-08:00","labels":["bug"]}
|
|
{"id":"bd-164b","content_hash":"fd9fc7c9e966b68b55c7e60f4b9d4f59581eb79c95c4ae21cf94d2bd8a6fc5f5","title":"Add template support for issue creation","description":"Support creating issues from predefined templates to streamline common workflows like epics, bug reports, or feature proposals.\n\nExample usage:\n bd create --from-template epic \"Phase 3 Features\"\n bd create --from-template bug \"Login failure\"\n bd template list\n bd template create epic\n\nTemplates should include:\n- Pre-filled description structure\n- Suggested priority and type\n- Common labels\n- Design/acceptance criteria sections\n\nImplementation notes:\n- Store templates in .beads/templates/ directory\n- Support YAML or JSON format\n- Ship with built-in templates (epic, bug, feature)\n- Allow custom project-specific templates","status":"closed","priority":1,"issue_type":"feature","created_at":"2025-11-03T18:10:18.985902-08:00","updated_at":"2025-11-03T19:56:41.287303-08:00","closed_at":"2025-11-03T19:56:41.287303-08:00"}
|
|
{"id":"bd-1f64","content_hash":"b509afe2d012683f1031c49007d10ebe9f3707c929fb0d5bc7ca46d6298477a7","title":"Add comprehensive tests for config.yaml issue-prefix migration","description":"The GH #209 config.yaml migration lacks test coverage:\n\nMissing tests:\n- config.SetIssuePrefix() edge cases (empty file, comments, malformed YAML)\n- config.GetIssuePrefix() with various config states\n- MigrateConfigToYAML() automatic migration logic\n- bd init writing to config.yaml instead of DB\n- bd migrate DB→config.yaml migration path\n\nTest scenarios needed:\n1. SetIssuePrefix with empty config.yaml\n2. SetIssuePrefix with existing config.yaml (preserves other settings)\n3. SetIssuePrefix with commented issue-prefix line\n4. SetIssuePrefix atomic write (temp file cleanup)\n5. GetIssuePrefix fallback behavior\n6. MigrateConfigToYAML when config.yaml missing prefix but DB has it\n7. MigrateConfigToYAML when both missing (detect from issues)\n8. MigrateConfigToYAML when config.yaml already has prefix (no-op)\n9. Integration test: fresh bd init writes to config.yaml only\n10. Integration test: upgrade from v0.21 DB migrates to config.yaml\n\nPriority 1 because this is a user-facing migration affecting all users upgrading to v0.22.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-03T22:33:43.08753-08:00","updated_at":"2025-11-03T22:46:16.306565-08:00","closed_at":"2025-11-03T22:46:16.306565-08:00"}
|
|
{"id":"bd-1ls","content_hash":"af79708476d560abaac3cbe9c537bcf43c2100dcb1d676954ea604486f75d199","title":"Override test","description":"## Overview\n\n[Describe the high-level goal and scope of this epic]\n\n## Success Criteria\n\n- [ ] Criteria 1\n- [ ] Criteria 2\n- [ ] Criteria 3\n\n## Background\n\n[Provide context and motivation]\n\n## Scope\n\n**In Scope:**\n- Item 1\n- Item 2\n\n**Out of Scope:**\n- Item 1\n- Item 2\n","design":"## Architecture\n\n[Describe the overall architecture and approach]\n\n## Components\n\n- Component 1: [description]\n- Component 2: [description]\n\n## Dependencies\n\n[List external dependencies or constraints]\n","acceptance_criteria":"- [ ] All child issues are completed\n- [ ] Integration tests pass\n- [ ] Documentation is updated\n- [ ] Code review completed\n","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-11-03T20:15:10.01471-08:00","updated_at":"2025-11-03T23:47:58.44067-08:00","closed_at":"2025-11-03T23:47:58.440673-08:00","labels":["epic"]}
|
|
{"id":"bd-1vv","content_hash":"1db907ddb55edaf7a4c06a566c4e1b8244fcd9ba5d7e2fca4d5c053e424ac515","title":"Add WebSocket support","description":"## Feature Request\n\n[Describe the desired feature]\n\n## Motivation\n\n[Why is this feature needed? What problem does it solve?]\n\n## Use Cases\n\n1. **Use Case 1**: [description]\n2. **Use Case 2**: [description]\n\n## Proposed Solution\n\n[High-level approach to implementing this feature]\n\n## Alternatives Considered\n\n- **Alternative 1**: [description and why not chosen]\n- **Alternative 2**: [description and why not chosen]\n","design":"## Technical Design\n\n[Detailed technical approach]\n\n## API Changes\n\n[New commands, flags, or APIs]\n\n## Data Model Changes\n\n[Database schema changes if any]\n\n## Implementation Notes\n\n- Note 1\n- Note 2\n\n## Testing Strategy\n\n- Unit tests: [scope]\n- Integration tests: [scope]\n- Manual testing: [steps]\n","acceptance_criteria":"- [ ] Feature implements all described use cases\n- [ ] All tests pass\n- [ ] Documentation updated (README, commands)\n- [ ] Examples added if applicable\n- [ ] No performance regressions\n","status":"open","priority":2,"issue_type":"feature","created_at":"2025-11-03T19:56:41.271215-08:00","updated_at":"2025-11-03T19:56:41.271215-08:00","labels":["feature"]}
|
|
{"id":"bd-35c7","content_hash":"28e00b560e08ecbf061e998836f8a1dd11392680b273589341c13e6b267df37c","title":"Add label-based filtering to bd ready command","description":"Allow filtering ready work by labels to help organize work by sprint, week, or category.\n\nExample usage:\n bd ready --label week1-2\n bd ready --label frontend,high-priority\n\nThis helps teams organize work into batches and makes it easier for agents to focus on specific categories of work.\n\nImplementation notes:\n- Add --label flag to ready command\n- Support comma-separated labels (AND logic)\n- Should work with existing ready work logic (unblocked issues)","status":"closed","priority":1,"issue_type":"feature","created_at":"2025-11-03T18:10:18.976536-08:00","updated_at":"2025-11-03T23:47:58.441745-08:00","closed_at":"2025-11-03T23:47:58.441748-08:00"}
|
|
{"id":"bd-4ry","content_hash":"d71a38227ebcb455452f96d07ef100d9c82698aa36c2d4eef5842ca4f1a68fa9","title":"Clarify JSONL size bounds with multi-repo","description":"The contributor-workflow-analysis.md states (line 226): 'Keep beads.jsonl small enough for agents to read (\u003c25k)'\n\nWith multi-repo hydration, it's unclear whether this bound applies to:\n- Each individual JSONL file (likely intention)\n- The total hydrated size across all repos (unclear)\n- Both (most conservative)\n\nClarification needed because:\n- VC monitors .beads/issues.jsonl size to stay under limit\n- With multi-repo, VC needs to know if each additional repo also has 25k limit\n- Agents reading hydrated data need to know total size bounds\n- Performance characteristics depend on total vs per-repo limits\n\nExample scenario:\n- Primary repo: 20k JSONL\n- Planning repo: 15k JSONL\n- Total hydrated: 35k\nIs this acceptable or does it violate the \u003c25k principle?","acceptance_criteria":"- Documentation explicitly states size bound applies per-repo or total\n- Rationale explained (why that bound matters)\n- Guidance for monitoring size with multi-repo\n- If total bound exists, formula provided (e.g., sum of all repos \u003c25k)","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-03T20:24:50.042748-08:00","updated_at":"2025-11-03T20:24:50.042748-08:00"}
|
|
{"id":"bd-5iv","content_hash":"9260ad77a2fcc64520aa97f156bbf9d868d855b7a3b8491256b316f2563ca958","title":"Test Epic","description":"## Overview\n\n[Describe the high-level goal and scope of this epic]\n\n## Success Criteria\n\n- [ ] Criteria 1\n- [ ] Criteria 2\n- [ ] Criteria 3\n\n## Background\n\n[Provide context and motivation]\n\n## Scope\n\n**In Scope:**\n- Item 1\n- Item 2\n\n**Out of Scope:**\n- Item 1\n- Item 2\n","design":"## Architecture\n\n[Describe the overall architecture and approach]\n\n## Components\n\n- Component 1: [description]\n- Component 2: [description]\n\n## Dependencies\n\n[List external dependencies or constraints]\n","acceptance_criteria":"- [ ] All child issues are completed\n- [ ] Integration tests pass\n- [ ] Documentation is updated\n- [ ] Code review completed\n","status":"open","priority":1,"issue_type":"epic","created_at":"2025-11-03T20:15:03.864229-08:00","updated_at":"2025-11-03T20:15:03.864229-08:00","labels":["epic"]}
|
|
{"id":"bd-72w","content_hash":"4f61c75e6e438b0602085d31a889a40694c9c735d9030ea44e504fc948f9d157","title":"Q4 Platform Improvements","description":"## Overview\n\n[Describe the high-level goal and scope of this epic]\n\n## Success Criteria\n\n- [ ] Criteria 1\n- [ ] Criteria 2\n- [ ] Criteria 3\n\n## Background\n\n[Provide context and motivation]\n\n## Scope\n\n**In Scope:**\n- Item 1\n- Item 2\n\n**Out of Scope:**\n- Item 1\n- Item 2\n","design":"## Architecture\n\n[Describe the overall architecture and approach]\n\n## Components\n\n- Component 1: [description]\n- Component 2: [description]\n\n## Dependencies\n\n[List external dependencies or constraints]\n","acceptance_criteria":"- [ ] All child issues are completed\n- [ ] Integration tests pass\n- [ ] Documentation is updated\n- [ ] Code review completed\n","status":"open","priority":1,"issue_type":"epic","created_at":"2025-11-03T19:54:03.794244-08:00","updated_at":"2025-11-03T19:54:03.794244-08:00","labels":["epic"]}
|
|
{"id":"bd-74ee","content_hash":"6d1a4a691f8c06bdf6e770401debb18e5330ad694cf4360ca00726c0ac2fbf44","title":"Frontend task","description":"","status":"open","priority":1,"issue_type":"task","created_at":"2025-11-03T19:11:59.358631-08:00","updated_at":"2025-11-03T19:11:59.358631-08:00","labels":["frontend","week1"]}
|
|
{"id":"bd-78w","content_hash":"ed3e38fda8a1f5f8335b605c7cac5c8e644052bf58d9ee2981e8bd5019ad2bc4","title":"Test Epic 2","description":"## Overview\n\n[Describe the high-level goal and scope of this epic]\n\n## Success Criteria\n\n- [ ] Criteria 1\n- [ ] Criteria 2\n- [ ] Criteria 3\n\n## Background\n\n[Provide context and motivation]\n\n## Scope\n\n**In Scope:**\n- Item 1\n- Item 2\n\n**Out of Scope:**\n- Item 1\n- Item 2\n","design":"## Architecture\n\n[Describe the overall architecture and approach]\n\n## Components\n\n- Component 1: [description]\n- Component 2: [description]\n\n## Dependencies\n\n[List external dependencies or constraints]\n","acceptance_criteria":"- [ ] All child issues are completed\n- [ ] Integration tests pass\n- [ ] Documentation is updated\n- [ ] Code review completed\n","status":"open","priority":1,"issue_type":"epic","created_at":"2025-11-03T20:15:03.878216-08:00","updated_at":"2025-11-03T20:15:03.878216-08:00","labels":["epic"]}
|
|
{"id":"bd-824","content_hash":"c6895598595873d74698771b8687ffbd60999120fed85a5c1d7c2176d7d2976f","title":"Add migration guide for library consumers","description":"The contributor-workflow-analysis.md has excellent migration examples for CLI users (lines 508-549) but lacks examples for library consumers like VC that use beadsLib in Go/TypeScript code.\n\nLibrary consumers need to know:\n- Whether their existing code continues to work unchanged (backward compatibility)\n- How config.toml is automatically read (transparent hydration)\n- When and how to use explicit multi-repo configuration\n- What happens if config.toml doesn't exist (defaults)\n\nExample needed:\n```go\n// Before (v0.17.3)\nstore, err := beadsLib.NewSQLiteStorage(\".beads/vc.db\")\n\n// After (v0.18.0 with multi-repo) - still works!\nstore, err := beadsLib.NewSQLiteStorage(\".beads/vc.db\")\n// Automatically reads .beads/config.toml if present\n\n// Explicit multi-repo (if needed)\ncfg := beadsLib.Config{\n Primary: \".beads/vc.db\",\n Additional: []string{\"~/.beads-planning\"},\n}\nstore, err := beadsLib.NewStorageWithConfig(cfg)\n```","acceptance_criteria":"- Section added to contributor-workflow-analysis.md for library consumers\n- Code examples showing backward compatibility\n- Code examples showing explicit multi-repo configuration\n- Guidance on when library consumers should use multi-repo vs single-repo","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-03T20:24:17.748337-08:00","updated_at":"2025-11-03T20:24:17.748337-08:00"}
|
|
{"id":"bd-9b13","content_hash":"83a72169a32e4c0bd6fa48334900d52ec08c3573b3ed0bd9bd5178ede9720c49","title":"Backend task","description":"","status":"open","priority":1,"issue_type":"task","created_at":"2025-11-03T19:11:59.359262-08:00","updated_at":"2025-11-03T19:11:59.359262-08:00","labels":["backend","week1"]}
|
|
{"id":"bd-cb2f","content_hash":"99b9c1c19d5e9f38308d78f09763426777797f133d4c86edd579419e7ba4043f","title":"Week 1 task","description":"","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-03T19:11:59.358093-08:00","updated_at":"2025-11-03T19:11:59.358093-08:00","labels":["frontend","week2"]}
|
|
{"id":"bd-e044","content_hash":"bd0f9c72de2d340fb09226f12270115762088ea65c36d2b3ca8a17a51f3311c1","title":"Add mermaid output format for bd dep tree","description":"Add visual dependency graph output using Mermaid format for better visualization of issue relationships.\n\nExample usage:\n bd dep tree --format mermaid \u003cissue-id\u003e\n bd dep tree --format mermaid bd-42 \u003e graph.md\n\nThis would output Mermaid syntax that can be rendered in GitHub, documentation sites, or Mermaid live editor.\n\nImplementation notes:\n- Add --format flag to dep tree command\n- Support 'text' (default) and 'mermaid' formats\n- Mermaid graph should show issue IDs, titles, and dependency types\n- Consider using flowchart LR or graph TD syntax","status":"closed","priority":1,"issue_type":"feature","created_at":"2025-11-03T18:10:18.978383-08:00","updated_at":"2025-11-03T20:48:28.950558-08:00","closed_at":"2025-11-03T20:48:28.950558-08:00"}
|
|
{"id":"bd-s02","content_hash":"911d456e4dabae028dd615b643c99058ef12e55ea523cb81cc933783c7b13546","title":"Manual task","description":"","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-03T20:15:10.022202-08:00","updated_at":"2025-11-03T20:15:10.022202-08:00"}
|
|
{"id":"bd-u8j","content_hash":"03131b068616b353b1f6c5d96a39f50680bf296629671060a7a364e76e049485","title":"Clarify exclusive lock protocol compatibility with multi-repo","description":"The contributor-workflow-analysis.md proposes per-repo file locking (Decision #7) using flock on JSONL files. However, VC (a downstream library consumer) uses an exclusive lock protocol (vc-195, requires Beads v0.17.3+) that allows bd daemon and VC executor to coexist.\n\nNeed to clarify:\n- Does the proposed per-repo file locking work with VC's existing exclusive lock protocol?\n- Do library consumers like VC need to adapt their locking logic?\n- Can multiple repos be locked atomically for cross-repo operations?\n\nContext: contributor-workflow-analysis.md lines 662-681","acceptance_criteria":"- Documentation explicitly states compatibility or incompatibility with existing lock protocols\n- If incompatible, migration path is documented for library consumers\n- If compatible, example showing coexistence is provided","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-03T20:24:08.257493-08:00","updated_at":"2025-11-03T20:24:08.257493-08:00"}
|
|
{"id":"bd-wta","content_hash":"59b0c71f52b597b32340bf5675c0a5efa281d08ffcac72bb3ee7b6e6df58b4cf","title":"Add performance benchmarks for multi-repo hydration","description":"The contributor-workflow-analysis.md asserts sub-second queries (line 702) and describes smart caching via file mtime tracking (Decision #4, lines 584-618), but doesn't provide concrete performance benchmarks.\n\nVC's requirement (from VC feedback section):\n- Executor polls GetReadyWork() every 5-10 seconds\n- Queries must be sub-second (ideally \u003c100ms)\n- Smart caching must avoid re-parsing JSONLs on every query\n\nSuggested performance targets to validate:\n- File stat overhead: \u003c1ms per repo\n- Hydration (when needed): \u003c500ms for typical JSONL (\u003c25k)\n- Query (from cache): \u003c10ms\n- Total GetReadyWork(): \u003c100ms (VC's requirement)\n\nAlso test at scale:\n- N=1 repo (baseline)\n- N=3 repos (typical)\n- N=10 repos (edge case)\n\nThese benchmarks are critical for library consumers like VC that run automated polling loops.","acceptance_criteria":"- Performance benchmark suite created for multi-repo hydration\n- Benchmarks cover file stat, hydration, and query times\n- Tests at N=1, N=3, N=10 repo scales\n- Results documented in contributor-workflow-analysis.md\n- Performance targets met or issues filed for optimization","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-03T20:24:39.331528-08:00","updated_at":"2025-11-03T20:24:39.331528-08:00"}
|
|
{"id":"bd-x47","content_hash":"1add411c4d4919dd7179e4e944ebbd9ec3b4672b93f9f6c303ab8fe512e66d09","title":"Add guidance for self-hosting projects","description":"The contributor-workflow-analysis.md is optimized for OSS contributors making PRs to upstream projects. However, it doesn't address projects like VC that use beads for their own development (self-hosting).\n\nSelf-hosting projects differ from OSS contributors:\n- No upstream/downstream distinction (they ARE the project)\n- May run automated executors (not just humans)\n- In bootstrap/early phase (stability matters)\n- Single team/owner (not multiple contributors with permissions)\n\nGuidance needed on:\n- When self-hosting projects should stay single-repo (default, recommended)\n- When they should adopt multi-repo (team planning, multi-phase dev)\n- How automated executors should handle multi-repo (if at all)\n- Special considerations for projects in bootstrap phase\n\nExamples of self-hosting projects: VC (building itself with beads), internal tools, pet projects","acceptance_criteria":"- Section added: 'For Projects Using Beads for Self-Hosting'\n- Clear guidance on when to stay single-repo vs adopt multi-repo\n- Recommendations for automated executor behavior with multi-repo\n- Bootstrap phase considerations documented","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-03T20:24:27.805341-08:00","updated_at":"2025-11-03T20:24:27.805341-08:00"}
|