johno/beads
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

bd sync: 2025-11-05 00:55:40

Browse Source
This commit is contained in:
Steve Yegge
2025-11-05 00:55:40 -08:00
parent e0c1872dd8
commit 6da54f49fa
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.beads/beads.jsonl
View File

@@ -208,4 +208,4 @@
{"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","source_repo":"."}
{"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","source_repo":"."}
{"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","source_repo":"."}
{"id":"bd-zkl","content_hash":"cb299b73577814802df3a99dc6c100be59b62cad83511abf65015ca3b66a2f33","title":"Add tests for daemon vs non-daemon parity in list filters","description":"After bd-o43 RPC integration, we need tests to verify daemon mode behaves identically to direct mode for all new filter flags.\n\nTest coverage needed:\n- Pattern matching: --title-contains, --desc-contains, --notes-contains\n- Date ranges: all 6 date filter flags (created/updated/closed after/before)\n- Empty/null checks: --empty-description, --no-assignee, --no-labels\n- Priority ranges: --priority-min, --priority-max\n- Status normalization: --status all vs no status flag\n- Date parsing: YYYY-MM-DD, RFC3339, and error cases\n- Backward compat: deprecated --label flag still works\n\nOracle review findings (bd-o43):\n- Date parsing should support multiple formats\n- Status 'all' should be treated as unset\n- NoLabels field was missing from RPC protocol\n- Error messages should be clear and actionable\n\nTest approach:\n- Create RPC integration tests in internal/rpc/server_issues_epics_test.go\n- Compare daemon client.List() vs direct store.SearchIssues() for same filters\n- Verify error messages match between modes\n- Test with real daemon instance, not just unit tests","status":"open","priority":1,"issue_type":"task","created_at":"2025-11-05T00:43:53.369457-08:00","updated_at":"2025-11-05T00:43:53.369457-08:00","source_repo":".","dependencies":[{"issue_id":"bd-zkl","depends_on_id":"bd-o43","type":"discovered-from","created_at":"2025-11-05T00:43:53.371274-08:00","created_by":"daemon"}]}
{"id":"bd-zkl","content_hash":"cb299b73577814802df3a99dc6c100be59b62cad83511abf65015ca3b66a2f33","title":"Add tests for daemon vs non-daemon parity in list filters","description":"After bd-o43 RPC integration, we need tests to verify daemon mode behaves identically to direct mode for all new filter flags.\n\nTest coverage needed:\n- Pattern matching: --title-contains, --desc-contains, --notes-contains\n- Date ranges: all 6 date filter flags (created/updated/closed after/before)\n- Empty/null checks: --empty-description, --no-assignee, --no-labels\n- Priority ranges: --priority-min, --priority-max\n- Status normalization: --status all vs no status flag\n- Date parsing: YYYY-MM-DD, RFC3339, and error cases\n- Backward compat: deprecated --label flag still works\n\nOracle review findings (bd-o43):\n- Date parsing should support multiple formats\n- Status 'all' should be treated as unset\n- NoLabels field was missing from RPC protocol\n- Error messages should be clear and actionable\n\nTest approach:\n- Create RPC integration tests in internal/rpc/server_issues_epics_test.go\n- Compare daemon client.List() vs direct store.SearchIssues() for same filters\n- Verify error messages match between modes\n- Test with real daemon instance, not just unit tests","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-05T00:43:53.369457-08:00","updated_at":"2025-11-05T00:55:31.318526-08:00","closed_at":"2025-11-05T00:55:31.318526-08:00","source_repo":".","dependencies":[{"issue_id":"bd-zkl","depends_on_id":"bd-o43","type":"discovered-from","created_at":"2025-11-05T00:43:53.371274-08:00","created_by":"daemon"}]}