bd sync: 2025-11-05 12:56:00
This commit is contained in:
@@ -2,6 +2,7 @@
|
|||||||
{"id":"bd-02a4","content_hash":"fbaca84d9502239656f05a14f62e8e6adec8f8dd492b1e91694fefcd0bdf310c","title":"Modify CreateIssue to support parent resurrection","description":"Update internal/storage/sqlite/sqlite.go:182-196 to call TryResurrectParent before failing on missing parent. Coordinate with EnsureIDs changes for consistent behavior. Handle edge case where parent never existed in JSONL (fail gracefully).","status":"closed","priority":0,"issue_type":"task","created_at":"2025-11-04T12:31:59.701571-08:00","updated_at":"2025-11-04T17:10:48.920499-08:00","closed_at":"2025-11-04T17:10:48.920499-08:00","source_repo":"."}
|
{"id":"bd-02a4","content_hash":"fbaca84d9502239656f05a14f62e8e6adec8f8dd492b1e91694fefcd0bdf310c","title":"Modify CreateIssue to support parent resurrection","description":"Update internal/storage/sqlite/sqlite.go:182-196 to call TryResurrectParent before failing on missing parent. Coordinate with EnsureIDs changes for consistent behavior. Handle edge case where parent never existed in JSONL (fail gracefully).","status":"closed","priority":0,"issue_type":"task","created_at":"2025-11-04T12:31:59.701571-08:00","updated_at":"2025-11-04T17:10:48.920499-08:00","closed_at":"2025-11-04T17:10:48.920499-08:00","source_repo":"."}
|
||||||
{"id":"bd-0458","content_hash":"c4427da2aec84621525f7f286c626f6c94365a7e6ff8e35e9676b184c85e1adb","title":"Consolidate export/import/commit/push into sync.go","description":"Create internal/daemonrunner/sync.go with Syncer type. Add ExportOnce, ImportOnce, CommitAndMaybePush methods. Replace createExportFunc/createAutoImportFunc with thin closures calling Syncer.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-01T11:41:14.874539-07:00","updated_at":"2025-11-02T12:32:00.157369-08:00","closed_at":"2025-11-02T12:32:00.157375-08:00","source_repo":"."}
|
{"id":"bd-0458","content_hash":"c4427da2aec84621525f7f286c626f6c94365a7e6ff8e35e9676b184c85e1adb","title":"Consolidate export/import/commit/push into sync.go","description":"Create internal/daemonrunner/sync.go with Syncer type. Add ExportOnce, ImportOnce, CommitAndMaybePush methods. Replace createExportFunc/createAutoImportFunc with thin closures calling Syncer.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-01T11:41:14.874539-07:00","updated_at":"2025-11-02T12:32:00.157369-08:00","closed_at":"2025-11-02T12:32:00.157375-08:00","source_repo":"."}
|
||||||
{"id":"bd-05a1","content_hash":"b79b0efa41b4eca8d7e5ab9738d5ecaa403c35497877a056a502efe0583ca251","title":"Isolate RPC server startup into rpc_server.go","description":"Create internal/daemonrunner/rpc_server.go with StartRPC function. Move startRPCServer logic here and return typed handle.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-01T11:41:14.876839-07:00","updated_at":"2025-11-02T12:32:00.158054-08:00","closed_at":"2025-11-02T12:32:00.158057-08:00","source_repo":"."}
|
{"id":"bd-05a1","content_hash":"b79b0efa41b4eca8d7e5ab9738d5ecaa403c35497877a056a502efe0583ca251","title":"Isolate RPC server startup into rpc_server.go","description":"Create internal/daemonrunner/rpc_server.go with StartRPC function. Move startRPCServer logic here and return typed handle.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-01T11:41:14.876839-07:00","updated_at":"2025-11-02T12:32:00.158054-08:00","closed_at":"2025-11-02T12:32:00.158057-08:00","source_repo":"."}
|
||||||
|
{"id":"bd-06y7","content_hash":"d8a9c155c8bf968766fc88eccf360ce547d984a1282adb4cc720c502cef0d91f","title":"Show dependency status in bd show output","description":"When bd show displays dependencies and dependents, include their status (open/closed/in_progress/blocked) for quick progress tracking. Improves context rebuilding and planning.","status":"closed","priority":1,"issue_type":"feature","created_at":"2025-11-05T11:22:11.606837-08:00","updated_at":"2025-11-05T11:23:30.431049-08:00","closed_at":"2025-11-05T11:23:30.431049-08:00","source_repo":"."}
|
||||||
{"id":"bd-0702","content_hash":"bed8c3ea786ecdbc1867ba5df8b4968894cc49368eaf1ce3238f560fa742cf97","title":"Consolidate ID generation and validation into ids.go","description":"Extract ID logic into ids.go: ValidateIssueIDPrefix, GenerateIssueID, EnsureIDs. Move GetAdaptiveIDLength here. Unify single and bulk ID generation flows.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-01T11:41:14.877886-07:00","updated_at":"2025-11-02T15:28:11.996618-08:00","closed_at":"2025-11-02T15:28:11.996624-08:00","source_repo":"."}
|
{"id":"bd-0702","content_hash":"bed8c3ea786ecdbc1867ba5df8b4968894cc49368eaf1ce3238f560fa742cf97","title":"Consolidate ID generation and validation into ids.go","description":"Extract ID logic into ids.go: ValidateIssueIDPrefix, GenerateIssueID, EnsureIDs. Move GetAdaptiveIDLength here. Unify single and bulk ID generation flows.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-01T11:41:14.877886-07:00","updated_at":"2025-11-02T15:28:11.996618-08:00","closed_at":"2025-11-02T15:28:11.996624-08:00","source_repo":"."}
|
||||||
{"id":"bd-08fd","content_hash":"1fc998c05fb1ccb8725bc0fe9b930b201c0c291353b9f9d578c44865eef5dde9","title":"Test child issue","description":"","status":"closed","priority":3,"issue_type":"task","created_at":"2025-11-02T11:50:40.640901-08:00","updated_at":"2025-11-02T11:50:47.309652-08:00","closed_at":"2025-11-02T11:50:47.309652-08:00","source_repo":".","dependencies":[{"issue_id":"bd-08fd","depends_on_id":"bd-ce75","type":"blocks","created_at":"2025-11-02T11:50:40.642073-08:00","created_by":"stevey"}]}
|
{"id":"bd-08fd","content_hash":"1fc998c05fb1ccb8725bc0fe9b930b201c0c291353b9f9d578c44865eef5dde9","title":"Test child issue","description":"","status":"closed","priority":3,"issue_type":"task","created_at":"2025-11-02T11:50:40.640901-08:00","updated_at":"2025-11-02T11:50:47.309652-08:00","closed_at":"2025-11-02T11:50:47.309652-08:00","source_repo":".","dependencies":[{"issue_id":"bd-08fd","depends_on_id":"bd-ce75","type":"blocks","created_at":"2025-11-02T11:50:40.642073-08:00","created_by":"stevey"}]}
|
||||||
{"id":"bd-09b5f2f5","content_hash":"02c69c90dc76c4982976362b9cb00ce01bc3fc3d17618feec3a02bab6fa4d196","title":"Daemon fails to auto-import after git pull updates JSONL","description":"After git pull updates .beads/issues.jsonl, daemon doesn't automatically re-import changes, causing stale data to be shown until next sync cycle (up to 5 minutes).\n\nReproduction:\n1. Repo A: Close issues, export, commit, push\n2. Repo B: git pull (successfully updates .beads/issues.jsonl)\n3. bd show \u003cissue\u003e shows OLD status from daemon's SQLite db\n4. JSONL on disk has correct new status\n\nRoot cause: Daemon sync cycle runs on timer (5min). When user manually runs git pull, daemon doesn't detect JSONL was updated externally and continues serving stale data from SQLite.\n\nImpact:\n- High for AI agents using beads in git workflows\n- Breaks fundamental git-as-source-of-truth model\n- Confusing UX: git log shows commit, bd shows old state\n- Data consistency issues between JSONL and daemon\n\nSee WYVERN_SYNC_ISSUE.md for full analysis.","design":"Three possible solutions:\n\nOption 1: Auto-detect and re-import (recommended)\n- Before serving any bd command, check if .beads/issues.jsonl mtime \u003e last import time\n- If newer, auto-import before processing request\n- Fast check, minimal overhead\n\nOption 2: File watcher in daemon\n- Daemon watches .beads/issues.jsonl for mtime changes\n- Auto-imports when file changes\n- More complex, requires file watching infrastructure\n\nOption 3: Explicit sync command\n- User runs `bd sync` after git pull\n- Manual, error-prone, defeats automation\n\nRecommended: Option 1 (auto-detect) + Option 3 (explicit sync) as fallback.","acceptance_criteria":"1. After git pull updates .beads/issues.jsonl, next bd command sees fresh data\n2. No manual import or daemon restart required\n3. Performance impact \u003c 10ms per command (mtime check is fast)\n4. Works in both daemon and non-daemon modes\n5. Test: Two repo clones, update in one, pull in other, verify immediate sync","notes":"**Fixed in v0.21.2!**\n\nThe daemon auto-import is fully implemented:\n- internal/autoimport package handles staleness detection\n- internal/importer package provides shared import logic (used by both CLI and daemon)\n- daemon's checkAndAutoImportIfStale() calls autoimport.AutoImportIfNewer()\n- importFunc uses importer.ImportIssues() with auto-rename enabled\n- All tests passing\n\nThe critical data corruption bug is FIXED:\n✅ After git pull, daemon detects JSONL is newer (mtime check)\n✅ Daemon auto-imports before serving requests\n✅ No stale data served\n✅ No data loss in multi-agent workflows\n\nVerification needed: Run two-repo test to confirm end-to-end behavior.","status":"closed","priority":0,"issue_type":"epic","created_at":"2025-10-25T23:13:12.270766-07:00","updated_at":"2025-11-01T16:52:50.931197-07:00","closed_at":"2025-11-01T16:52:50.931197-07:00","source_repo":"."}
|
{"id":"bd-09b5f2f5","content_hash":"02c69c90dc76c4982976362b9cb00ce01bc3fc3d17618feec3a02bab6fa4d196","title":"Daemon fails to auto-import after git pull updates JSONL","description":"After git pull updates .beads/issues.jsonl, daemon doesn't automatically re-import changes, causing stale data to be shown until next sync cycle (up to 5 minutes).\n\nReproduction:\n1. Repo A: Close issues, export, commit, push\n2. Repo B: git pull (successfully updates .beads/issues.jsonl)\n3. bd show \u003cissue\u003e shows OLD status from daemon's SQLite db\n4. JSONL on disk has correct new status\n\nRoot cause: Daemon sync cycle runs on timer (5min). When user manually runs git pull, daemon doesn't detect JSONL was updated externally and continues serving stale data from SQLite.\n\nImpact:\n- High for AI agents using beads in git workflows\n- Breaks fundamental git-as-source-of-truth model\n- Confusing UX: git log shows commit, bd shows old state\n- Data consistency issues between JSONL and daemon\n\nSee WYVERN_SYNC_ISSUE.md for full analysis.","design":"Three possible solutions:\n\nOption 1: Auto-detect and re-import (recommended)\n- Before serving any bd command, check if .beads/issues.jsonl mtime \u003e last import time\n- If newer, auto-import before processing request\n- Fast check, minimal overhead\n\nOption 2: File watcher in daemon\n- Daemon watches .beads/issues.jsonl for mtime changes\n- Auto-imports when file changes\n- More complex, requires file watching infrastructure\n\nOption 3: Explicit sync command\n- User runs `bd sync` after git pull\n- Manual, error-prone, defeats automation\n\nRecommended: Option 1 (auto-detect) + Option 3 (explicit sync) as fallback.","acceptance_criteria":"1. After git pull updates .beads/issues.jsonl, next bd command sees fresh data\n2. No manual import or daemon restart required\n3. Performance impact \u003c 10ms per command (mtime check is fast)\n4. Works in both daemon and non-daemon modes\n5. Test: Two repo clones, update in one, pull in other, verify immediate sync","notes":"**Fixed in v0.21.2!**\n\nThe daemon auto-import is fully implemented:\n- internal/autoimport package handles staleness detection\n- internal/importer package provides shared import logic (used by both CLI and daemon)\n- daemon's checkAndAutoImportIfStale() calls autoimport.AutoImportIfNewer()\n- importFunc uses importer.ImportIssues() with auto-rename enabled\n- All tests passing\n\nThe critical data corruption bug is FIXED:\n✅ After git pull, daemon detects JSONL is newer (mtime check)\n✅ Daemon auto-imports before serving requests\n✅ No stale data served\n✅ No data loss in multi-agent workflows\n\nVerification needed: Run two-repo test to confirm end-to-end behavior.","status":"closed","priority":0,"issue_type":"epic","created_at":"2025-10-25T23:13:12.270766-07:00","updated_at":"2025-11-01T16:52:50.931197-07:00","closed_at":"2025-11-01T16:52:50.931197-07:00","source_repo":"."}
|
||||||
@@ -204,6 +205,7 @@
|
|||||||
{"id":"bd-gdzd","content_hash":"0882387a9983d9ac3a68027d3ccc84f39856a92a7a46ff5626125bdd088d6f8b","title":"Import fails on same-content-different-ID instead of treating as update","description":"## Problem\n\nThe importer still has rename detection (importer.go:482-500) that triggers when same content hash has different IDs. With hash IDs, this shouldn't happen, but when it does (test data, bugs, legacy data), the import fails:\n\n```\nfailed to handle rename bd-ce75 -\u003e bd-5a90: rename collision handling removed - should not occur with hash IDs\n```\n\n## Current Behavior\n\n1. Importer finds same content hash with different IDs\n2. Calls handleRename() (line 490)\n3. handleRename() errors out (line 294): \"rename collision handling removed\"\n4. Import fails\n\n## Expected Behavior\n\nSame content hash + different IDs should be treated as an **update**, not a rename:\n- Keep existing ID (already in database)\n- Update fields if incoming has newer timestamp\n- Discard incoming ID (it's wrong - hash should have generated same ID)\n\n## Impact\n\n- Import fails on legitimate edge cases (test data, data corruption)\n- Cryptic error message\n- Blocks sync operations\n\n## Fix\n\nIn handleRename() or import loop, instead of erroring:\n```go\n// Same content, different ID - treat as update\nif incoming.UpdatedAt.After(existing.UpdatedAt) {\n existing.Status = incoming.Status\n // ... copy other fields\n s.UpdateIssue(ctx, existing)\n}\nresult.Updated++\n```\n\n## Files\n- internal/importer/importer.go:271-294 (handleRename)\n- internal/importer/importer.go:482-500 (rename detection)\n\n## Repro\nImport JSONL with bd-ce75 and bd-5a90 (both \"Test parent issue\" but different content hashes).","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-05T00:27:51.150233-08:00","updated_at":"2025-11-05T00:54:37.786903-08:00","closed_at":"2025-11-05T00:54:37.786903-08:00","source_repo":"."}
|
{"id":"bd-gdzd","content_hash":"0882387a9983d9ac3a68027d3ccc84f39856a92a7a46ff5626125bdd088d6f8b","title":"Import fails on same-content-different-ID instead of treating as update","description":"## Problem\n\nThe importer still has rename detection (importer.go:482-500) that triggers when same content hash has different IDs. With hash IDs, this shouldn't happen, but when it does (test data, bugs, legacy data), the import fails:\n\n```\nfailed to handle rename bd-ce75 -\u003e bd-5a90: rename collision handling removed - should not occur with hash IDs\n```\n\n## Current Behavior\n\n1. Importer finds same content hash with different IDs\n2. Calls handleRename() (line 490)\n3. handleRename() errors out (line 294): \"rename collision handling removed\"\n4. Import fails\n\n## Expected Behavior\n\nSame content hash + different IDs should be treated as an **update**, not a rename:\n- Keep existing ID (already in database)\n- Update fields if incoming has newer timestamp\n- Discard incoming ID (it's wrong - hash should have generated same ID)\n\n## Impact\n\n- Import fails on legitimate edge cases (test data, data corruption)\n- Cryptic error message\n- Blocks sync operations\n\n## Fix\n\nIn handleRename() or import loop, instead of erroring:\n```go\n// Same content, different ID - treat as update\nif incoming.UpdatedAt.After(existing.UpdatedAt) {\n existing.Status = incoming.Status\n // ... copy other fields\n s.UpdateIssue(ctx, existing)\n}\nresult.Updated++\n```\n\n## Files\n- internal/importer/importer.go:271-294 (handleRename)\n- internal/importer/importer.go:482-500 (rename detection)\n\n## Repro\nImport JSONL with bd-ce75 and bd-5a90 (both \"Test parent issue\" but different content hashes).","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-05T00:27:51.150233-08:00","updated_at":"2025-11-05T00:54:37.786903-08:00","closed_at":"2025-11-05T00:54:37.786903-08:00","source_repo":"."}
|
||||||
{"id":"bd-gm7p","content_hash":"4bc3ca7545527e791e7282ad7596cb39f024e20fda1845c3498ffef1ba0100fd","title":"Use in-memory filesystem for test git operations","description":"Use tmpfs/ramdisk for git operations in tests to reduce I/O overhead.\n\nOptions:\n1. Mount /tmp as tmpfs in CI (GitHub Actions supports this)\n2. Use Go's testing.TB.TempDir() which may already use tmpfs on some systems\n3. Explicitly create ramdisk for tests on macOS\n\nExpected savings: 20-30% reduction in git operation time","status":"closed","priority":3,"issue_type":"task","created_at":"2025-11-04T01:24:19.803224-08:00","updated_at":"2025-11-04T12:27:51.428975-08:00","closed_at":"2025-11-04T12:27:51.428978-08:00","source_repo":".","dependencies":[{"issue_id":"bd-gm7p","depends_on_id":"bd-l5gq","type":"blocks","created_at":"2025-11-04T01:24:19.80414-08:00","created_by":"daemon"}]}
|
{"id":"bd-gm7p","content_hash":"4bc3ca7545527e791e7282ad7596cb39f024e20fda1845c3498ffef1ba0100fd","title":"Use in-memory filesystem for test git operations","description":"Use tmpfs/ramdisk for git operations in tests to reduce I/O overhead.\n\nOptions:\n1. Mount /tmp as tmpfs in CI (GitHub Actions supports this)\n2. Use Go's testing.TB.TempDir() which may already use tmpfs on some systems\n3. Explicitly create ramdisk for tests on macOS\n\nExpected savings: 20-30% reduction in git operation time","status":"closed","priority":3,"issue_type":"task","created_at":"2025-11-04T01:24:19.803224-08:00","updated_at":"2025-11-04T12:27:51.428975-08:00","closed_at":"2025-11-04T12:27:51.428978-08:00","source_repo":".","dependencies":[{"issue_id":"bd-gm7p","depends_on_id":"bd-l5gq","type":"blocks","created_at":"2025-11-04T01:24:19.80414-08:00","created_by":"daemon"}]}
|
||||||
{"id":"bd-gpe7","content_hash":"abafcc321674aa66d99dc353641fe183e510f4b89624adcaf8ffe0cea5ffb1ef","title":"Tests take too long - unacceptable for project size","description":"## Problem\n\nRunning `go test ./internal/importer/... -v` takes an unacceptably long time (minutes). For a project this size, tests should complete in seconds.\n\n## Impact\n\n- Slows down development iteration\n- AI agents waste time waiting for tests\n- Blocks rapid bug fixes and validation\n- Poor developer experience\n\n## Investigation Needed\n\n- Profile which tests are slow\n- Check for unnecessary sleeps, timeouts, or integration tests\n- Look for tests that could be parallelized\n- Consider splitting unit vs integration tests\n\n## Goal\n\nTest suite for a single package should complete in \u003c5 seconds, ideally \u003c2 seconds.","notes":"## Optimizations Applied\n\n1. **Added t.Parallel() to CLI tests** (13 tests) - allows concurrent execution\n2. **Removed unnecessary 200ms sleep** in daemon_autoimport_test.go - Execute() forces auto-import synchronously\n3. **Reduced filesystem settle wait** from 100ms → 50ms on non-Windows platforms\n4. **Optimized debouncer test sleeps** (9 reductions):\n - Before debounce waits: 30ms → 20ms, 20ms → 10ms\n - After debounce waits: 40ms → 35ms, 30ms → 35ms, etc.\n - Thread safety test: 100ms → 70ms\n - Sequential cycles: 50ms → 40ms (3x)\n - Cancel tests: 70-80ms → 60ms\n\n## Results\n\n### cmd/bd package (main improvement target):\n- **Before**: 5+ minutes (timeout)\n- **After**: ~18-20 seconds\n- **Speedup**: ~15-18x faster\n\n### internal/importer package:\n- **After**: \u003c1 second (0.9s)\n\n### Full test suite (with `-short` flag):\n- Most packages complete in \u003c2s\n- Total runtime constrained by sequential integration tests\n\n## Known Issues\n\n- TestConcurrentExternalRefImports hangs due to :memory: connection pool issue (bd-b121)\n- Some sync_branch tests may need sequential execution (git worktree conflicts)","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-05T00:54:47.784504-08:00","updated_at":"2025-11-05T10:55:27.261404-08:00","closed_at":"2025-11-05T01:41:57.544395-08:00","source_repo":"."}
|
{"id":"bd-gpe7","content_hash":"abafcc321674aa66d99dc353641fe183e510f4b89624adcaf8ffe0cea5ffb1ef","title":"Tests take too long - unacceptable for project size","description":"## Problem\n\nRunning `go test ./internal/importer/... -v` takes an unacceptably long time (minutes). For a project this size, tests should complete in seconds.\n\n## Impact\n\n- Slows down development iteration\n- AI agents waste time waiting for tests\n- Blocks rapid bug fixes and validation\n- Poor developer experience\n\n## Investigation Needed\n\n- Profile which tests are slow\n- Check for unnecessary sleeps, timeouts, or integration tests\n- Look for tests that could be parallelized\n- Consider splitting unit vs integration tests\n\n## Goal\n\nTest suite for a single package should complete in \u003c5 seconds, ideally \u003c2 seconds.","notes":"## Optimizations Applied\n\n1. **Added t.Parallel() to CLI tests** (13 tests) - allows concurrent execution\n2. **Removed unnecessary 200ms sleep** in daemon_autoimport_test.go - Execute() forces auto-import synchronously\n3. **Reduced filesystem settle wait** from 100ms → 50ms on non-Windows platforms\n4. **Optimized debouncer test sleeps** (9 reductions):\n - Before debounce waits: 30ms → 20ms, 20ms → 10ms\n - After debounce waits: 40ms → 35ms, 30ms → 35ms, etc.\n - Thread safety test: 100ms → 70ms\n - Sequential cycles: 50ms → 40ms (3x)\n - Cancel tests: 70-80ms → 60ms\n\n## Results\n\n### cmd/bd package (main improvement target):\n- **Before**: 5+ minutes (timeout)\n- **After**: ~18-20 seconds\n- **Speedup**: ~15-18x faster\n\n### internal/importer package:\n- **After**: \u003c1 second (0.9s)\n\n### Full test suite (with `-short` flag):\n- Most packages complete in \u003c2s\n- Total runtime constrained by sequential integration tests\n\n## Known Issues\n\n- TestConcurrentExternalRefImports hangs due to :memory: connection pool issue (bd-b121)\n- Some sync_branch tests may need sequential execution (git worktree conflicts)","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-05T00:54:47.784504-08:00","updated_at":"2025-11-05T10:55:27.261404-08:00","closed_at":"2025-11-05T01:41:57.544395-08:00","source_repo":"."}
|
||||||
|
{"id":"bd-k0j9","content_hash":"52d1e6f87bd7655018bd89dbbbaf8da66bdcba45de6138fd237810365a04606a","title":"Test dependency parent","description":"","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-05T11:23:02.505901-08:00","updated_at":"2025-11-05T11:23:20.91305-08:00","closed_at":"2025-11-05T11:23:20.91305-08:00","source_repo":"."}
|
||||||
{"id":"bd-k58","content_hash":"cc90fb20e7bd178b52133d4d0f8781dce2debb46519674ae6356291d597fc13d","title":"Proposal workflow (propose/withdraw/accept)","description":"Implement commands and state machine for moving issues between personal planning repos and canonical upstream repos, enabling contributors to propose work without polluting PRs.","design":"Commands:\n- bd propose \u003cid\u003e [--target \u003crepo\u003e] - Move issue to target repo\n- bd withdraw \u003cid\u003e - Un-propose (move back)\n- bd accept \u003cid\u003e - Maintainer accepts proposal\n\nVisibility states:\n- local: Personal planning only\n- proposed: Staged for upstream PR\n- canonical: Accepted by upstream (default for existing)\n\nOptional visibility field (backward compatible, defaults to canonical)","acceptance_criteria":"1. bd propose moves issue from planning to primary repo\n2. bd withdraw reverses proposal\n3. bd accept (maintainer) finalizes acceptance\n4. Visibility field tracks state (local/proposed/canonical)\n5. Backward compatible - existing issues default to canonical\n6. State transitions are atomic and git-tracked","status":"closed","priority":1,"issue_type":"epic","created_at":"2025-11-04T11:21:41.113647-08:00","updated_at":"2025-11-05T00:08:38.19821-08:00","closed_at":"2025-11-05T00:08:38.198213-08:00","source_repo":".","dependencies":[{"issue_id":"bd-k58","depends_on_id":"bd-4ms","type":"parent-child","created_at":"2025-11-04T11:22:21.811261-08:00","created_by":"daemon"}]}
|
{"id":"bd-k58","content_hash":"cc90fb20e7bd178b52133d4d0f8781dce2debb46519674ae6356291d597fc13d","title":"Proposal workflow (propose/withdraw/accept)","description":"Implement commands and state machine for moving issues between personal planning repos and canonical upstream repos, enabling contributors to propose work without polluting PRs.","design":"Commands:\n- bd propose \u003cid\u003e [--target \u003crepo\u003e] - Move issue to target repo\n- bd withdraw \u003cid\u003e - Un-propose (move back)\n- bd accept \u003cid\u003e - Maintainer accepts proposal\n\nVisibility states:\n- local: Personal planning only\n- proposed: Staged for upstream PR\n- canonical: Accepted by upstream (default for existing)\n\nOptional visibility field (backward compatible, defaults to canonical)","acceptance_criteria":"1. bd propose moves issue from planning to primary repo\n2. bd withdraw reverses proposal\n3. bd accept (maintainer) finalizes acceptance\n4. Visibility field tracks state (local/proposed/canonical)\n5. Backward compatible - existing issues default to canonical\n6. State transitions are atomic and git-tracked","status":"closed","priority":1,"issue_type":"epic","created_at":"2025-11-04T11:21:41.113647-08:00","updated_at":"2025-11-05T00:08:38.19821-08:00","closed_at":"2025-11-05T00:08:38.198213-08:00","source_repo":".","dependencies":[{"issue_id":"bd-k58","depends_on_id":"bd-4ms","type":"parent-child","created_at":"2025-11-04T11:22:21.811261-08:00","created_by":"daemon"}]}
|
||||||
{"id":"bd-ktng","content_hash":"0a09f3e1549a70817f23aa57444811aaf18683ff9336944ff6e8c277ac5684b4","title":"Optimize CLI test suite - eliminate redundant git init calls","description":"Current: Each of 13 CLI tests calls git init (31s total). Solution: Use single test binary built once in init(), skip git operations where possible, or use mock filesystem.","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-04T11:23:13.660276-08:00","updated_at":"2025-11-04T11:23:13.660276-08:00","source_repo":".","dependencies":[{"issue_id":"bd-ktng","depends_on_id":"bd-l5gq","type":"discovered-from","created_at":"2025-11-04T11:23:13.662102-08:00","created_by":"daemon"}]}
|
{"id":"bd-ktng","content_hash":"0a09f3e1549a70817f23aa57444811aaf18683ff9336944ff6e8c277ac5684b4","title":"Optimize CLI test suite - eliminate redundant git init calls","description":"Current: Each of 13 CLI tests calls git init (31s total). Solution: Use single test binary built once in init(), skip git operations where possible, or use mock filesystem.","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-04T11:23:13.660276-08:00","updated_at":"2025-11-04T11:23:13.660276-08:00","source_repo":".","dependencies":[{"issue_id":"bd-ktng","depends_on_id":"bd-l5gq","type":"discovered-from","created_at":"2025-11-04T11:23:13.662102-08:00","created_by":"daemon"}]}
|
||||||
{"id":"bd-l5gq","content_hash":"9c6f895c8e0066874073474fded02d3b1b10a008c3448f1e650e2ff39b5e8e02","title":"Optimize test suite performance - cut runtime by 50%+","description":"## Problem\nTest suite takes ~20.8 seconds, with 95% of time spent in just 2 tests:\n- TestHashIDs_MultiCloneConverge: 11.08s (53%)\n- TestHashIDs_IdenticalContentDedup: 8.78s (42%)\n\nBoth tests in beads_hash_multiclone_test.go perform extensive Git operations (bare repos, multiple clones, sync rounds).\n\n## Goal\nCut total test time by at least 50% (to ~10 seconds or less).\n\n## Analysis\nTests already have some optimizations:\n- --shared --depth=1 --no-tags for fast cloning\n- Disabled hooks, gc, fsync\n- Support -short flag\n\n## Impact\n- Faster development feedback loop\n- Reduced CI costs and time\n- Better developer experience","status":"closed","priority":2,"issue_type":"epic","created_at":"2025-11-04T01:23:14.410648-08:00","updated_at":"2025-11-04T12:27:51.43013-08:00","closed_at":"2025-11-04T12:27:51.430134-08:00","source_repo":"."}
|
{"id":"bd-l5gq","content_hash":"9c6f895c8e0066874073474fded02d3b1b10a008c3448f1e650e2ff39b5e8e02","title":"Optimize test suite performance - cut runtime by 50%+","description":"## Problem\nTest suite takes ~20.8 seconds, with 95% of time spent in just 2 tests:\n- TestHashIDs_MultiCloneConverge: 11.08s (53%)\n- TestHashIDs_IdenticalContentDedup: 8.78s (42%)\n\nBoth tests in beads_hash_multiclone_test.go perform extensive Git operations (bare repos, multiple clones, sync rounds).\n\n## Goal\nCut total test time by at least 50% (to ~10 seconds or less).\n\n## Analysis\nTests already have some optimizations:\n- --shared --depth=1 --no-tags for fast cloning\n- Disabled hooks, gc, fsync\n- Support -short flag\n\n## Impact\n- Faster development feedback loop\n- Reduced CI costs and time\n- Better developer experience","status":"closed","priority":2,"issue_type":"epic","created_at":"2025-11-04T01:23:14.410648-08:00","updated_at":"2025-11-04T12:27:51.43013-08:00","closed_at":"2025-11-04T12:27:51.430134-08:00","source_repo":"."}
|
||||||
@@ -214,3 +216,4 @@
|
|||||||
{"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-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-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":"27227f7f9b8b03d312d483686711551bcf227c263f935d94d1a8f2c377969d2e","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"}]}
|
{"id":"bd-zkl","content_hash":"27227f7f9b8b03d312d483686711551bcf227c263f935d94d1a8f2c377969d2e","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"}]}
|
||||||
|
{"id":"bd-zwpw","content_hash":"f08173f44c8454bf15b265aa9d3242004e7ee2bc25867b02676746154a9cc6fe","title":"Test dependency child","description":"","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-05T11:23:05.998311-08:00","updated_at":"2025-11-05T11:23:30.389454-08:00","closed_at":"2025-11-05T11:23:30.389454-08:00","source_repo":".","dependencies":[{"issue_id":"bd-zwpw","depends_on_id":"bd-k0j9","type":"blocks","created_at":"2025-11-05T11:23:05.998981-08:00","created_by":"daemon"}]}
|
||||||
|
|||||||
Reference in New Issue
Block a user