Add routing integration tests and documentation

- Created routing_integration_test.go with comprehensive routing tests
- Tests cover maintainer/contributor detection, explicit overrides, end-to-end multi-repo
- Added docs/ROUTING.md documenting auto-routing feature
- Closed bd-6u6g, bd-zmi5, bd-nzt4, bd-btsm (routing tests)
- Updated bd-4ms and bd-8hf with progress notes

All routing tests pass. Multi-repo auto-routing is complete.

Amp-Thread-ID: https://ampcode.com/threads/T-2ea8b2ed-ceb7-432e-91f1-1f527b0e7b4d
Co-authored-by: Amp <amp@ampcode.com>
This commit is contained in:
Steve Yegge
2025-11-04 17:48:33 -08:00
parent 6ab6f82c6e
commit cac9ae6647
9 changed files with 554 additions and 9 deletions

View File

@@ -28,7 +28,7 @@
{"id":"bd-1b0a","content_hash":"57d0a0ca69b2c95554ed7afa95c366187f0a9b53beebe2391b7aa49a3436f470","title":"Add transaction helper to replace manual COMMIT/ROLLBACK","description":"Create tx.go with withTx helper that handles transaction lifecycle. Replace manual transaction blocks in create/insert/update paths.","notes":"Refactoring complete:\n- Created withTx() helper in util.go\n- Added ExecInTransaction() as deprecated wrapper for backward compatibility\n- Refactored all manual transaction blocks to use withTx():\n - events.go: AddComment\n - dirty.go: MarkIssuesDirty, ClearDirtyIssuesByID\n - labels.go: executeLabelOperation\n - dependencies.go: AddDependency, RemoveDependency\n - compact.go: ApplyCompaction\n- All tests pass successfully","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-01T11:41:14.823323-07:00","updated_at":"2025-11-02T12:41:45.827688-08:00","closed_at":"2025-11-02T12:41:45.827688-08:00"}
{"id":"bd-1c63eb84","content_hash":"178adb74f06c9a049ec5db6c406253005ee3460e7b732801e60fcee044986004","title":"Investigate jujutsu integration for beads","description":"Research and document how beads could integrate with jujutsu (jj), the next-generation VCS. Key areas to explore:\n- How jj's operation model differs from git (immutable operations, working-copy-as-commit)\n- JSONL sync strategy with jj's conflict resolution model\n- Daemon compatibility with jj's more frequent rewrites\n- Whether auto-import/export needs changes for jj workflows\n- Example configurations and documentation updates needed","status":"open","priority":3,"issue_type":"task","created_at":"2025-10-23T09:23:23.582009-07:00","updated_at":"2025-10-30T17:12:58.177733-07:00"}
{"id":"bd-1c77","content_hash":"e64ed75c5734be1fcd10a824217acb3061aefc510f6a4da1f7c95a42ad8356c8","title":"Implement filesystem shims for WASM","description":"WASM needs JS shims for filesystem access. Child of epic bd-44d0.\n\n## Tasks\n- [ ] Implement file read/write shims\n- [ ] Map WASM syscalls to Node.js fs API\n- [ ] Handle .beads/ directory discovery\n- [ ] Test with real JSONL files\n- [ ] Support both absolute and relative paths\n\n## Technical Notes\n- Use Node.js fs module via syscall/js\n- Consider MEMFS for in-memory option","status":"open","priority":0,"issue_type":"task","created_at":"2025-11-02T18:33:31.280464-08:00","updated_at":"2025-11-02T18:33:31.280464-08:00","dependencies":[{"issue_id":"bd-1c77","depends_on_id":"bd-197b","type":"blocks","created_at":"2025-11-02T18:33:31.281134-08:00","created_by":"daemon"}]}
{"id":"bd-1dtn","content_hash":"84a1719882c2c64247666de08127e1789e00d3ea0277c74705b7e89ba45bd33b","title":"Discovered issues inherit parent source_repo","description":"When creating discovered-from issues, automatically inherit the source_repo field from the parent issue to maintain consistency.","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-04T16:48:49.380623-08:00","updated_at":"2025-11-04T16:48:49.380623-08:00","dependencies":[{"issue_id":"bd-1dtn","depends_on_id":"bd-8hf","type":"parent-child","created_at":"2025-11-04T16:48:49.382151-08:00","created_by":"stevey"}]}
{"id":"bd-1dtn","content_hash":"8c76842a8db081e337b49d7ba957392d3ffe3f70cb2e126aed561e82bbdb54f8","title":"Discovered issues inherit parent source_repo","description":"When creating discovered-from issues, automatically inherit the source_repo field from the parent issue to maintain consistency.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-04T16:48:49.380623-08:00","updated_at":"2025-11-04T17:15:55.957491-08:00","closed_at":"2025-11-04T17:15:55.957491-08:00","dependencies":[{"issue_id":"bd-1dtn","depends_on_id":"bd-8hf","type":"parent-child","created_at":"2025-11-04T16:48:49.382151-08:00","created_by":"stevey"}]}
{"id":"bd-1ece","content_hash":"95ec39ad0bf8c9514bc500b929a5996d026936b0fc037e19a99d2234e5315770","title":"Remove obsolete renumber.go command (hash IDs eliminated need)","description":"","status":"closed","priority":2,"issue_type":"chore","created_at":"2025-10-31T21:27:05.559328-07:00","updated_at":"2025-10-31T21:27:11.426941-07:00","closed_at":"2025-10-31T21:27:11.426941-07:00"}
{"id":"bd-1f28","content_hash":"850a14659d6747dc114b7da94e55c3f9594995cabc31c3c85e3089fbd5f61712","title":"Extract migration functions to migrations.go","description":"Move migrateDirtyIssuesTable, migrateExternalRefColumn, migrateCompositeIndexes, migrateClosedAtConstraint, migrateCompactionColumns, migrateSnapshotsTable, migrateCompactionConfig, migrateCompactedAtCommitColumn, migrateExportHashesTable, migrateContentHashColumn to a separate migrations.go file","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-01T19:28:54.892045-07:00","updated_at":"2025-11-01T20:00:09.038174-07:00","closed_at":"2025-11-01T20:00:09.038178-07:00"}
{"id":"bd-1f4086c5","content_hash":"5dcfbb24a97a6277ca177bf136cf37741dbf54f798ca7e82eca631ea1b0129a1","title":"Event-driven daemon architecture","description":"Replace 5-second polling sync loop with event-driven architecture that reacts instantly to changes. Eliminates stale data issues while reducing CPU ~60%. Key components: FileWatcher (fsnotify), Debouncer (500ms), RPC mutation events, optional git hooks. Target latency: \u003c500ms (vs 5000ms). See event_driven_daemon.md for full design.","notes":"Production-ready after 3 critical fixes (commit 349b892):\n- Skip redundant imports (mtime check prevents self-trigger loops)\n- Add server.Stop() in serverErrChan case (clean shutdown)\n- Fallback ticker (60s) when watcher unavailable (ensures remote sync)\n\nReady to make default after integration test (bd-1f4086c5.1) passes.","status":"closed","priority":1,"issue_type":"epic","created_at":"2025-10-29T23:05:13.969484-07:00","updated_at":"2025-10-31T20:21:25.464736-07:00","closed_at":"2025-10-31T20:21:25.464736-07:00"}
@@ -87,7 +87,7 @@
{"id":"bd-4e21b5ad","content_hash":"8029d0c5b14261648d3d17d8bc26413183962eab2875772cd2585db92c0104a6","title":"Add test case for symmetric collision (both clones create same ID simultaneously)","description":"TestTwoCloneCollision demonstrates the problem, but we need a simpler unit test for the collision resolver itself.\n\nTest should verify:\n- Two issues with same ID, different content\n- Content hash determines winner deterministically \n- Result is same regardless of which clone imports first\n- No title swapping occurs\n\nThis can be a simpler test than the full integration test.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-10-29T17:46:10.046999-07:00","updated_at":"2025-10-31T12:00:43.196705-07:00","closed_at":"2025-10-31T12:00:43.196705-07:00"}
{"id":"bd-4f582ec8","content_hash":"dbf986afd3a1641a2b701645a85cc3576888c6ecd0ecf217b16f4535448facee","title":"Test auto-start in fred","description":"","status":"closed","priority":3,"issue_type":"task","created_at":"2025-10-30T17:46:16.668088-07:00","updated_at":"2025-10-31T12:00:43.185723-07:00","closed_at":"2025-10-31T12:00:43.185723-07:00"}
{"id":"bd-4ff2","content_hash":"9a36dc265788b61d5a45ab75633951f4f653b1130c1a003a66829fd28555488e","title":"Fix CI failures before 0.21.3 release","description":"CI is failing on multiple jobs:\n1. Nix flake: Tests fail due to missing git in build environment\n2. Windows tests: Need to check what's failing\n3. Linux tests: Need to check what's failing\n4. Linter errors: Many unchecked errors need fixing\n\nNeed to fix before tagging v0.21.3 release.","notes":"Fixed linter errors (errcheck, misspell), Nix flake git dependency, and import database discovery bug. Tests still failing - need to investigate further.","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-01T23:52:09.244763-07:00","updated_at":"2025-11-02T12:32:57.748324-08:00","closed_at":"2025-11-02T12:32:57.748329-08:00"}
{"id":"bd-4ms","content_hash":"b3054110411d41ddda918b4971e59a6107ab6d154e9d2e047ef995dfcf0a8203","title":"Multi-repo contributor workflow support","description":"Implement separate repository support for OSS contributors to prevent PR pollution while maintaining git ledger and multi-clone sync. Based on contributor-workflow-analysis.md Solution #4.","design":"See docs/contributor-workflow-analysis.md for complete design rationale.\n\nKey architecture:\n- N ≥ 1 repos (single repo default, multi-repo opt-in)\n- VCS-agnostic (git, jj, hg, sapling)\n- Config-based routing (no schema changes)\n- Smart caching (file mtime tracking, SQLite cache)\n- Global namespace (hash-based IDs)\n- Cross-repo dependencies supported","acceptance_criteria":"1. Zero PR pollution - contributor planning never reaches upstream\n2. Git ledger preserved - all repos VCS-tracked\n3. Backward compatible - existing single-repo workflows unchanged\n4. Sub-second query performance with polling\n5. Library API stable - transparent to downstream consumers like VC","notes":"## Progress Update\n\n**Completed:**\n1. ✅ bd-307 closed - hydration layer complete with tests\n2. ✅ Daemon sync loop now uses multi-repo for import/export\n3. ✅ Added CLI commands: bd repo add/remove/list/sync\n4. ✅ Config stored in database as repos.additional JSON\n\n**Implementation:**\n- Modified importToJSONLWithStore() to call HydrateFromMultiRepo()\n- exportToJSONLWithStore() already used ExportToMultiRepo()\n- Created repo.go with commands for multi-repo management\n- Config helpers: getRepoConfig/setRepoConfig for JSON (de)serialization\n\n**Next:**\n- End-to-end testing of multi-repo workflow\n- Work on bd-8hf (auto-routing) or bd-k58 (propose workflow)","status":"in_progress","priority":1,"issue_type":"epic","created_at":"2025-11-04T11:21:19.515776-08:00","updated_at":"2025-11-04T16:32:26.917818-08:00"}
{"id":"bd-4ms","content_hash":"3700cc2b1293d50aed34a9cafc0d4e496eb4753e5d2d4b69b41e1608d4783a40","title":"Multi-repo contributor workflow support","description":"Implement separate repository support for OSS contributors to prevent PR pollution while maintaining git ledger and multi-clone sync. Based on contributor-workflow-analysis.md Solution #4.","design":"See docs/contributor-workflow-analysis.md for complete design rationale.\n\nKey architecture:\n- N ≥ 1 repos (single repo default, multi-repo opt-in)\n- VCS-agnostic (git, jj, hg, sapling)\n- Config-based routing (no schema changes)\n- Smart caching (file mtime tracking, SQLite cache)\n- Global namespace (hash-based IDs)\n- Cross-repo dependencies supported","acceptance_criteria":"1. Zero PR pollution - contributor planning never reaches upstream\n2. Git ledger preserved - all repos VCS-tracked\n3. Backward compatible - existing single-repo workflows unchanged\n4. Sub-second query performance with polling\n5. Library API stable - transparent to downstream consumers like VC","notes":"## Progress Update\n\n**Completed:**\n1. ✅ bd-307 closed - hydration layer complete with tests\n2. ✅ Daemon sync loop now uses multi-repo for import/export\n3. ✅ Added CLI commands: bd repo add/remove/list/sync\n4. ✅ Config stored in database as repos.additional JSON\n5. ✅ bd-8hf mostly complete - auto-routing implemented and tested\n - Maintainer detection via git config and remote URL\n - Auto-routes bd create based on user role\n - --repo flag overrides\n - Discovered issues inherit parent's source_repo\n - Tests passing (routing_integration_test.go)\n\n**Implementation:**\n- Modified importToJSONLWithStore() to call HydrateFromMultiRepo()\n- exportToJSONLWithStore() uses ExportToMultiRepo()\n- Created repo.go with commands for multi-repo management\n- Created internal/routing package with DetectUserRole() and DetermineTargetRepo()\n- Integrated routing into cmd/bd/create.go\n- End-to-end multi-repo test passing\n\n**Next:**\n- Finish documentation for routing\n- Work on bd-k58 (propose workflow) or close bd-4ms as complete","status":"open","priority":1,"issue_type":"epic","created_at":"2025-11-04T11:21:19.515776-08:00","updated_at":"2025-11-04T17:48:24.303764-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-502e","content_hash":"0f40053f59ff205d858a9ddf0be845df1d52471cc25a812df78cb3d4667efbdd","title":"Add comprehensive tests for sync branch daemon logic","description":"The daemon sync branch functionality (bd-6545) was implemented but needs proper end-to-end testing.\n\nCurrent implementation:\n- daemon_sync_branch.go has syncBranchCommitAndPush() and syncBranchPull()\n- daemon_sync.go has been updated to use these functions when sync.branch is configured\n- All daemon tests pass, but no specific tests for sync branch behavior\n\nTesting needed:\n- Test that daemon commits to sync branch when sync.branch is configured\n- Test that daemon commits to current branch when sync.branch is NOT configured (backward compatibility)\n- Test that daemon pulls from sync branch and syncs JSONL back to main repo\n- Test worktree creation and health checks during daemon operations\n- Test error handling (missing branch, worktree corruption, etc.)\n\nKey challenge: Tests need to run in the context of the git repo (getGitRoot() uses current working directory), so test setup needs to properly change directory or mock the git root detection.\n\nReference existing daemon tests in daemon_test.go and daemon_autoimport_test.go for patterns.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-02T15:59:13.341491-08:00","updated_at":"2025-11-02T16:39:53.278313-08:00","closed_at":"2025-11-02T16:39:53.278313-08:00","dependencies":[{"issue_id":"bd-502e","depends_on_id":"bd-6545","type":"parent-child","created_at":"2025-11-02T15:59:13.342331-08:00","created_by":"daemon"}]}
{"id":"bd-5314bddf","content_hash":"bbaf3bd26766fb78465900c455661a3608ab1d1485cb964d12229badf138753a","title":"bd detect-pollution - Test pollution detector","description":"Detect test issues that leaked into production DB.\n\nPattern matching for:\n- Titles starting with 'test', 'benchmark', 'sample'\n- Sequential numbering (test-1, test-2)\n- Generic descriptions\n- Created in rapid succession\n\nOptional AI scoring for confidence.\n\nFiles: cmd/bd/detect_pollution.go (new)","status":"open","priority":1,"issue_type":"task","created_at":"2025-10-28T14:48:17.466906-07:00","updated_at":"2025-10-30T17:12:58.219307-07:00"}
@@ -123,7 +123,7 @@
{"id":"bd-6c68","content_hash":"e35e484e4f95b135186624795a5eaa5ef8fc13bbcbdde30829a4796c420c4412","title":"bd info shows 'auto_start_disabled' even when daemon is crashed/missing","description":"","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-10-31T21:08:03.385681-07:00","updated_at":"2025-11-01T19:13:43.819004-07:00","closed_at":"2025-11-01T19:13:43.819004-07:00","dependencies":[{"issue_id":"bd-6c68","depends_on_id":"bd-2752a7a2","type":"discovered-from","created_at":"2025-10-31T21:08:03.387045-07:00","created_by":"stevey"}]}
{"id":"bd-6d7efe32","content_hash":"e5c88e7c673bc83ef3b7c24deea92055c4f663327f6831c41f2aa601d0855528","title":"CRDT-based architecture for guaranteed convergence (v2.0)","description":"## Vision\nRedesign beads around Conflict-Free Replicated Data Types (CRDTs) to provide mathematical guarantees for N-way collision resolution at arbitrary scale.\n\n## Current Limitations\n- Content-hash based collision resolution fails at 5+ clones\n- Non-deterministic convergence in multi-round scenarios\n- UNIQUE constraint violations during rename operations\n- No formal proof of convergence properties\n\n## CRDT Benefits\n- Provably convergent (Strong Eventual Consistency)\n- Commutative/Associative/Idempotent operations\n- No coordination required between clones\n- Scales to 100+ concurrent workers\n- Well-understood mathematical foundations\n\n## Proposed Architecture\n\n### 1. UUID-Based IDs\nReplace sequential IDs with UUIDs:\n- Current: bd-1c63eb84, bd-9063acda, bd-4d80b7b1\n- CRDT: bd-a1b2c3d4-e5f6-7890-abcd-ef1234567890\n- Human aliases maintained separately: #42 maps to UUID\n\n### 2. Last-Write-Wins (LWW) Elements\nEach field becomes an LWW register:\n- title: (timestamp, clone_id, value)\n- status: (timestamp, clone_id, value)\n- Deterministic conflict resolution via Lamport timestamp + clone_id tiebreaker\n\n### 3. Operation Log\nTrack all operations as CRDT ops:\n- CREATE(uuid, timestamp, clone_id, fields)\n- UPDATE(uuid, field, timestamp, clone_id, value)\n- DELETE(uuid, timestamp, clone_id) - tombstone, not hard delete\n\n### 4. Sync as Merge\nSyncing becomes merging two CRDT states:\n- No merge conflicts possible\n- Deterministic merge function\n- Guaranteed convergence\n\n## Implementation Phases\n\n### Phase 1: Research \u0026 Design (4 weeks)\n- Study existing CRDT implementations (Automerge, Yjs, Loro)\n- Design schema for CRDT-based issue tracking\n- Prototype LWW-based Issue CRDT\n- Benchmark performance vs current system\n\n### Phase 2: Parallel Implementation (6 weeks)\n- Implement CRDT storage layer alongside SQLite\n- Build conversion tools: SQLite ↔ CRDT\n- Maintain backward compatibility with v1.x format\n- Migration path for existing databases\n\n### Phase 3: Testing \u0026 Validation (4 weeks)\n- Formal verification of convergence properties\n- Stress testing with 100+ clone scenario\n- Performance profiling and optimization\n- Documentation and examples\n\n### Phase 4: Migration \u0026 Rollout (4 weeks)\n- Release v2.0-beta with CRDT backend\n- Gradual migration from v1.x\n- Monitoring and bug fixes\n- Final v2.0 release\n\n## Risks \u0026 Mitigations\n\n**Risk 1: Performance overhead**\n- Mitigation: Benchmark early, optimize hot paths\n- CRDTs can be slower than append-only logs\n- May need compaction strategy\n\n**Risk 2: Storage bloat**\n- Mitigation: Implement operation log compaction\n- Tombstone garbage collection for deleted issues\n- Periodic snapshots to reduce log size\n\n**Risk 3: Breaking changes**\n- Mitigation: Maintain v1.x compatibility layer\n- Gradual migration tools\n- Dual-mode operation during transition\n\n**Risk 4: Complexity**\n- Mitigation: Use battle-tested CRDT libraries\n- Comprehensive documentation\n- Clear migration guide\n\n## Success Criteria\n- 100-clone collision test passes without failures\n- Formal proof of convergence properties\n- Performance within 2x of current system\n- Zero manual conflict resolution required\n- Backward compatible with v1.x databases\n\n## Timeline\n18-20 weeks total (4-5 months)\n\n## References\n- Automerge: https://automerge.org\n- Yjs: https://docs.yjs.dev\n- Loro: https://loro.dev\n- CRDT theory: Shapiro et al, A comprehensive study of CRDTs\n- Related issues: bd-e6d71828, bd-7a2b58fc, bd-81abb639","status":"closed","priority":3,"issue_type":"feature","created_at":"2025-10-29T20:48:00.267237-07:00","updated_at":"2025-10-31T20:06:44.604643-07:00","closed_at":"2025-10-31T20:06:44.604643-07:00"}
{"id":"bd-6fe4622f","content_hash":"d0d8e0634aea5e60373d339b363d7601af5d42d0f90780a54a4978c3e39ca747","title":"Remove unreachable utility functions","description":"Several small utility functions are unreachable:\n\nFiles to clean:\n1. `internal/storage/sqlite/hash.go` - `computeIssueContentHash` (line 17)\n - Check if entire file can be deleted if only contains this function\n\n2. `internal/config/config.go` - `FileUsed` (line 151)\n - Delete unused config helper\n\n3. `cmd/bd/git_sync_test.go` - `verifyIssueOpen` (line 300)\n - Delete dead test helper\n\n4. `internal/compact/haiku.go` - `HaikuClient.SummarizeTier2` (line 81)\n - Tier 2 summarization not implemented\n - Options: implement feature OR delete method\n\nImpact: Removes 50-100 LOC depending on decisions","acceptance_criteria":"- Remove unreachable functions\n- If entire files can be deleted (like hash.go), delete them\n- For SummarizeTier2: decide to implement or delete, document decision\n- All tests pass: `go test ./...`\n- Verify no callers exist for each function","status":"open","priority":2,"issue_type":"task","created_at":"2025-10-28T16:20:02.434573-07:00","updated_at":"2025-10-30T17:12:58.224957-07:00"}
{"id":"bd-6u6g","content_hash":"0c53485581931c19ac3285829e1d0284d83c3e7cedb58fa124737ae2705d6edb","title":"Test routing","description":"","status":"open","priority":1,"issue_type":"task","created_at":"2025-11-04T16:59:53.471001-08:00","updated_at":"2025-11-04T16:59:53.471001-08:00"}
{"id":"bd-6u6g","content_hash":"0c53485581931c19ac3285829e1d0284d83c3e7cedb58fa124737ae2705d6edb","title":"Test routing","description":"","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-04T16:59:53.471001-08:00","updated_at":"2025-11-04T17:46:59.107519-08:00","closed_at":"2025-11-04T17:46:59.107519-08:00"}
{"id":"bd-70419816","content_hash":"5b7eac7e0a00f1253fd8fd3932695b2b4b3a1e0afc632ee0d1a53ffa3ad60a77","title":"Export deduplication breaks when JSONL and export_hashes table diverge","description":"## Problem\n\nThe export deduplication feature (timestamp-only skipping) breaks when the JSONL file and export_hashes table get out of sync, causing exports to skip issues that aren't actually in the file.\n\n## Symptoms\n\n- `bd export` reports \"Skipped 128 issue(s) with timestamp-only changes\"\n- JSONL file only has 38 lines but DB has 149 issues\n- export_hashes table has 149 entries\n- Auto-import doesn't trigger (hash matches despite missing data)\n- Two repos on same commit show different issue counts\n\n## Root Cause\n\nshouldSkipExport() in autoflush.go compares current issue hash with stored export_hashes entry. If they match, it skips export assuming the issue is already in the JSONL.\n\nThis assumption fails when:\n1. Git operations (pull, reset, checkout) change JSONL without clearing export_hashes\n2. Manual JSONL edits or corruption\n3. Import operations that modify DB but don't update export_hashes\n4. Partial exports that update export_hashes but don't complete\n\n## Impact\n\n- **Critical data loss risk**: Issues appear to be tracked but aren't persisted to git\n- Breaks multi-repo sync (root cause of today's debugging session)\n- Auto-import fails to detect staleness (hash matches despite missing data)\n- Silent data corruption (no error messages, just missing issues)\n\n## Reproduction\n\n1. Have DB with 149 issues, all in export_hashes table\n2. Truncate JSONL to 38 lines (simulate git reset or corruption)\n3. Run `bd export` - it skips 128 issues\n4. JSONL still has only 38 lines but export thinks it succeeded\n\n## Current Workaround\n\n```bash\nsqlite3 .beads/beads.db \"DELETE FROM export_hashes\"\nbd export -o .beads/beads.jsonl\n```\n\n## Proposed Solutions\n\n**Option 1: Verify JSONL integrity before skipping**\n- Count lines in JSONL, compare with export_hashes count\n- If mismatch, clear export_hashes and force full export\n- Safe but adds I/O overhead\n\n**Option 2: Hash-based JSONL validation**\n- Store hash of entire JSONL file in metadata\n- Before export, check if JSONL hash matches\n- If mismatch, clear export_hashes\n- More efficient, detects any JSONL corruption\n\n**Option 3: Disable timestamp-only deduplication**\n- Remove the feature entirely\n- Always export all issues\n- Simplest and safest, but creates larger git commits\n\n**Option 4: Clear export_hashes on git operations**\n- Add post-merge hook to clear export_hashes\n- Clear on any import operation\n- Defensive approach but may over-clear\n\n## Recommended Fix\n\nCombination of Options 2 + 4:\n1. Store JSONL file hash in metadata after export\n2. Check hash before export, clear export_hashes if mismatch \n3. Clear export_hashes on import operations\n4. Add `bd validate` check for JSONL/export_hashes sync\n\n## Files Involved\n\n- cmd/bd/autoflush.go (shouldSkipExport)\n- cmd/bd/export.go (export with deduplication)\n- internal/storage/sqlite/metadata.go (export_hashes table)","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-10-29T23:05:13.960352-07:00","updated_at":"2025-10-30T17:12:58.19679-07:00","closed_at":"2025-10-29T22:22:20.406934-07:00"}
{"id":"bd-710a4916","content_hash":"5595ff0955a9ff4e738d4ba4fc87ca9aecd98ffcb694a4932ede8d6d76c5c76c","title":"CRDT-based architecture for guaranteed convergence (v2.0)","description":"## Vision\nRedesign beads around Conflict-Free Replicated Data Types (CRDTs) to provide mathematical guarantees for N-way collision resolution at arbitrary scale.\n\n## Current Limitations\n- Content-hash based collision resolution fails at 5+ clones\n- Non-deterministic convergence in multi-round scenarios\n- UNIQUE constraint violations during rename operations\n- No formal proof of convergence properties\n\n## CRDT Benefits\n- Provably convergent (Strong Eventual Consistency)\n- Commutative/Associative/Idempotent operations\n- No coordination required between clones\n- Scales to 100+ concurrent workers\n- Well-understood mathematical foundations\n\n## Proposed Architecture\n\n### 1. UUID-Based IDs\nReplace sequential IDs with UUIDs:\n- Current: bd-1c63eb84, bd-9063acda, bd-4d80b7b1\n- CRDT: bd-a1b2c3d4-e5f6-7890-abcd-ef1234567890\n- Human aliases maintained separately: #42 maps to UUID\n\n### 2. Last-Write-Wins (LWW) Elements\nEach field becomes an LWW register:\n- title: (timestamp, clone_id, value)\n- status: (timestamp, clone_id, value)\n- Deterministic conflict resolution via Lamport timestamp + clone_id tiebreaker\n\n### 3. Operation Log\nTrack all operations as CRDT ops:\n- CREATE(uuid, timestamp, clone_id, fields)\n- UPDATE(uuid, field, timestamp, clone_id, value)\n- DELETE(uuid, timestamp, clone_id) - tombstone, not hard delete\n\n### 4. Sync as Merge\nSyncing becomes merging two CRDT states:\n- No merge conflicts possible\n- Deterministic merge function\n- Guaranteed convergence\n\n## Implementation Phases\n\n### Phase 1: Research \u0026 Design (4 weeks)\n- Study existing CRDT implementations (Automerge, Yjs, Loro)\n- Design schema for CRDT-based issue tracking\n- Prototype LWW-based Issue CRDT\n- Benchmark performance vs current system\n\n### Phase 2: Parallel Implementation (6 weeks)\n- Implement CRDT storage layer alongside SQLite\n- Build conversion tools: SQLite ↔ CRDT\n- Maintain backward compatibility with v1.x format\n- Migration path for existing databases\n\n### Phase 3: Testing \u0026 Validation (4 weeks)\n- Formal verification of convergence properties\n- Stress testing with 100+ clone scenario\n- Performance profiling and optimization\n- Documentation and examples\n\n### Phase 4: Migration \u0026 Rollout (4 weeks)\n- Release v2.0-beta with CRDT backend\n- Gradual migration from v1.x\n- Monitoring and bug fixes\n- Final v2.0 release\n\n## Risks \u0026 Mitigations\n\n**Risk 1: Performance overhead**\n- Mitigation: Benchmark early, optimize hot paths\n- CRDTs can be slower than append-only logs\n- May need compaction strategy\n\n**Risk 2: Storage bloat**\n- Mitigation: Implement operation log compaction\n- Tombstone garbage collection for deleted issues\n- Periodic snapshots to reduce log size\n\n**Risk 3: Breaking changes**\n- Mitigation: Maintain v1.x compatibility layer\n- Gradual migration tools\n- Dual-mode operation during transition\n\n**Risk 4: Complexity**\n- Mitigation: Use battle-tested CRDT libraries\n- Comprehensive documentation\n- Clear migration guide\n\n## Success Criteria\n- 100-clone collision test passes without failures\n- Formal proof of convergence properties\n- Performance within 2x of current system\n- Zero manual conflict resolution required\n- Backward compatible with v1.x databases\n\n## Timeline\n18-20 weeks total (4-5 months)\n\n## References\n- Automerge: https://automerge.org\n- Yjs: https://docs.yjs.dev\n- Loro: https://loro.dev\n- CRDT theory: Shapiro et al, A comprehensive study of CRDTs\n- Related issues: bd-e6d71828, bd-7a2b58fc,-1","status":"open","priority":3,"issue_type":"feature","created_at":"2025-10-29T10:23:57.978339-07:00","updated_at":"2025-10-30T17:12:58.182513-07:00"}
{"id":"bd-71107098","content_hash":"9feb9a8dc8ae2dc65b11edeff37cf5ce48d8f28e1ced45d64ac0176937610296","title":"Make two-clone workflow actually work (no hacks)","description":"TestTwoCloneCollision proves beads CANNOT handle two independent clones filing issues simultaneously. This is the basic collaborative workflow and it must work cleanly.\n\nTest location: beads_twoclone_test.go\n\nThe test creates two git clones, both file issues with same ID (test-1), --resolve-collisions remaps clone B's to test-2, but after sync:\n- Clone A has test-1=\"Issue from clone A\", test-2=\"Issue from clone B\" \n- Clone B has test-1=\"Issue from clone B\", test-2=\"Issue from clone A\"\n\nThe TITLES are swapped! Both clones have 2 issues but with opposite title assignments.\n\nWe've tried many fixes (per-project daemons, auto-sync, lamport hashing, precommit hooks) but nothing has made the test pass.\n\nGoal: Make the test pass WITHOUT hacks. The two clones should converge to identical state after sync.","acceptance_criteria":"1. TestTwoCloneCollision passes without EXPECTED FAILURE\n2. Both clones converge to identical issue database\n3. No manual conflict resolution required\n4. Git status clean in both clones\n5. bd ready output identical in both clones","notes":"**Major progress achieved!** The two-clone workflow now converges correctly.\n\n**What was fixed:**\n--3d844c58: Implemented content-hash based rename detection\n- bd-64c05d00.1: Fixed test to compare content not timestamps\n- Both clones now converge to identical issue databases\n- test-1 and test-2 have correct titles in both clones\n- No more title swapping!\n\n**Current status (VERIFIED):**\n✅ Acceptance criteria 1: TestTwoCloneCollision passes (confirmed Oct 28)\n✅ Acceptance criteria 2: Both clones converge to identical issue database (content matches)\n✅ Acceptance criteria 3: No manual conflict resolution required (automatic)\n✅ Acceptance criteria 4: Git status clean\n✅ Acceptance criteria 5: bd ready output identical (timestamps are expected difference)\n\n**ALL ACCEPTANCE CRITERIA MET!** This issue is complete and can be closed.","status":"closed","priority":0,"issue_type":"epic","created_at":"2025-10-28T16:34:53.278793-07:00","updated_at":"2025-10-31T19:38:09.206303-07:00","closed_at":"2025-10-28T19:20:04.143242-07:00"}
@@ -156,7 +156,7 @@
{"id":"bd-89e2","content_hash":"c7da1d6c0d28b2fe9a5a1166a7b6712a870b5271fdf21558e4ef639e2675f92f","title":"Daemon race condition: stale export overwrites recent DB changes","description":"**Symptom:**\nMerged bd-fc2d into bd-fb05 in ~/src/beads (commit ce4d756), pushed to remote. The ~/src/fred/beads daemon then exported its stale DB state and committed (8cc1bb4), reverting bd-fc2d back to \"open\" status.\n\n**Timeline:**\n1. 21:45:12 - Merge committed from ~/src/beads (ce4d756): bd-fc2d closed\n2. 21:49:42 - Daemon in ~/src/fred/beads exported stale state (8cc1bb4): bd-fc2d open again\n\n**Root cause:**\nThe fred/beads daemon had a stale database (bd-fc2d still open) and didn't auto-import the newer JSONL before exporting. When it exported, it overwrote the merge with its stale state.\n\n**Expected behavior:**\nDaemon should detect that JSONL is newer than its last export and import before exporting.\n\n**Actual behavior:**\nDaemon exported stale DB state, creating a conflicting commit that reverted upstream changes.\n\n**Impact:**\nMulti-workspace setups with daemons can silently lose changes if one daemon has stale state and exports.","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-01T21:53:07.930819-07:00","updated_at":"2025-11-01T22:01:25.54126-07:00","closed_at":"2025-11-01T22:01:25.54126-07:00"}
{"id":"bd-89f89fc0","content_hash":"235c3bdeb45e3069167f81e7b4e798fc98547478bb16df40556100478c5e505a","title":"Remove unreachable RPC methods","description":"Several RPC server and client methods are unreachable and should be removed:\n\nServer methods (internal/rpc/server.go):\n- `Server.GetLastImportTime` (line 2116)\n- `Server.SetLastImportTime` (line 2123)\n- `Server.findJSONLPath` (line 2255)\n\nClient methods (internal/rpc/client.go):\n- `Client.Import` (line 311) - RPC import not used (daemon uses autoimport)\n\nEvidence:\n```bash\ngo run golang.org/x/tools/cmd/deadcode@latest -test ./...\n```\n\nImpact: Removes ~80 LOC of unused RPC code","acceptance_criteria":"- Remove the 4 unreachable methods (~80 LOC total)\n- Verify no callers: `grep -r \"GetLastImportTime\\|SetLastImportTime\\|findJSONLPath\" .`\n- All tests pass: `go test ./internal/rpc/...`\n- Daemon functionality works: test daemon start/stop/operations","status":"open","priority":2,"issue_type":"task","created_at":"2025-10-28T16:20:02.432202-07:00","updated_at":"2025-10-30T17:12:58.222655-07:00"}
{"id":"bd-8a39","content_hash":"cf11bd12f8906b73236f46998076d6111d69f05e76198e9823a8f10f3e03112b","title":"Fix Windows-specific test failures in CI","description":"Several tests are failing on Windows but passing on Linux:\n\n**Failing tests:**\n- TestFindDatabasePathEnvVar\n- TestHashIDs_MultiCloneConverge\n- TestHashIDs_IdenticalContentDedup\n- TestDatabaseReinitialization (all 5 subtests):\n - fresh_clone_auto_import\n - database_removal_scenario\n - legacy_filename_support\n - precedence_test\n - init_safety_check\n- TestFindBeadsDir_NotFound\n- TestMetricsSnapshot/uptime (in internal/rpc)\n\n**CI Run:** https://github.com/steveyegge/beads/actions/runs/19015638968\n\nThese are likely path separator or filesystem behavior differences between Windows and Linux.","notes":"Fixed all Windows path issues:\n1. TestFindDatabasePathEnvVar - expects canonicalized paths ✅\n2. TestHashIDs tests - use platform-specific bd.exe command ✅ \n3. TestMetricsSnapshot/uptime - enforce minimum 1 second uptime ✅\n4. TestFindBeadsDir_NotFound - allow finding .beads in parent dirs ✅\n5. TestDatabaseReinitialization - fix git path conversion on Windows (git returns /c/Users/... but filepath needs C:\\Users\\...) ✅\n\nCI run in progress to verify all fixes.","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-11-02T09:29:37.274103-08:00","updated_at":"2025-11-02T12:32:00.158713-08:00","closed_at":"2025-11-02T12:32:00.158716-08:00","dependencies":[{"issue_id":"bd-8a39","depends_on_id":"bd-1231","type":"blocks","created_at":"2025-11-02T09:29:37.276579-08:00","created_by":"stevey"}]}
{"id":"bd-8hf","content_hash":"3c0d1ce193f14f07f62d1d768763d5998687ecf33a47e422351a7ee5ecc2db11","title":"Auto-routing and maintainer detection","description":"Implement intelligent routing to automatically send new issues to correct repo based on user's maintainer vs contributor status, with discovered issues inheriting parent's source_repo.","design":"Features:\n- Detect maintainer vs contributor (git config, permissions)\n- Config-based routing rules (no schema changes)\n- Auto-route 'bd add' to primary or planning repo\n- Discovered issues inherit parent's source_repo\n- Explicit override via --repo flag\n\nConfig schema:\n[routing]\nmode = \"auto\" # auto | explicit\ndefault = \"~/.beads-planning\"\n[routing.auto]\nmaintainer = \".\"\ncontributor = \"~/.beads-planning\"","acceptance_criteria":"1. Auto-detect maintainer vs contributor status\n2. Route bd add to correct repo automatically\n3. Discovered issues inherit parent's source_repo\n4. --repo flag overrides auto-routing\n5. Config allows explicit routing rules\n6. Works without breaking single-repo workflows","notes":"## Progress\\n\\n✅ bd-mxtc: Maintainer detection complete\\n- Created internal/routing package\\n- Implemented DetectUserRole() with git config and remote URL checking\\n- All tests passing\\n\\n🔄 bd-ubu2: Auto-routing in progress\\n- Need to integrate routing into bd create command\\n- Need to add config schema support\\n\\n📋 bd-1dtn: Discovered issue inheritance pending","status":"in_progress","priority":1,"issue_type":"epic","created_at":"2025-11-04T11:21:50.961196-08:00","updated_at":"2025-11-04T16:50:22.708318-08:00","dependencies":[{"issue_id":"bd-8hf","depends_on_id":"bd-4ms","type":"parent-child","created_at":"2025-11-04T11:22:24.262815-08:00","created_by":"daemon"}]}
{"id":"bd-8hf","content_hash":"37b4e16057a0f747c2b9670851992a0beabfc96bea04d8d3d759653c9b438dc5","title":"Auto-routing and maintainer detection","description":"Implement intelligent routing to automatically send new issues to correct repo based on user's maintainer vs contributor status, with discovered issues inheriting parent's source_repo.","design":"Features:\n- Detect maintainer vs contributor (git config, permissions)\n- Config-based routing rules (no schema changes)\n- Auto-route 'bd add' to primary or planning repo\n- Discovered issues inherit parent's source_repo\n- Explicit override via --repo flag\n\nConfig schema:\n[routing]\nmode = \"auto\" # auto | explicit\ndefault = \"~/.beads-planning\"\n[routing.auto]\nmaintainer = \".\"\ncontributor = \"~/.beads-planning\"","acceptance_criteria":"1. Auto-detect maintainer vs contributor status\n2. Route bd add to correct repo automatically\n3. Discovered issues inherit parent's source_repo\n4. --repo flag overrides auto-routing\n5. Config allows explicit routing rules\n6. Works without breaking single-repo workflows","notes":"## Progress\n\n✅ bd-mxtc: Maintainer detection complete\n- Created internal/routing package\n- Implemented DetectUserRole() with git config and remote URL checking\n- All tests passing\n\n bd-ubu2: Auto-routing complete\n- Integrated routing into bd create command\n- Auto-routes based on user role (maintainer/contributor)\n- --repo flag overrides auto-routing\n- Tests pass (routing_integration_test.go)\n\n✅ Routing tests complete:\n- bd-6u6g, bd-zmi5, bd-nzt4, bd-btsm all closed\n- End-to-end multi-repo test passing\n\n📋 bd-1dtn: Discovered issue inheritance - ALREADY IMPLEMENTED\n- Code already exists in cmd/bd/create.go to inherit source_repo\n- Test exists in create_test.go: TestCreate_DiscoveredFromInheritsSourceRepo\n\n**Next:** Document routing feature","status":"open","priority":1,"issue_type":"epic","created_at":"2025-11-04T11:21:50.961196-08:00","updated_at":"2025-11-04T17:47:38.932237-08:00","dependencies":[{"issue_id":"bd-8hf","depends_on_id":"bd-4ms","type":"parent-child","created_at":"2025-11-04T11:22:24.262815-08:00","created_by":"daemon"}]}
{"id":"bd-8rd","content_hash":"35b240c77c0960acd2810a0ace985b85cdde4d16a2c4af7192a9526434143fa9","title":"Migration and onboarding for multi-repo","description":"Create migration tools, wizards, and documentation to help users adopt multi-repo workflow, with special focus on OSS contributor onboarding and team adoption scenarios.","design":"Components:\n- Migration guide documentation\n- bd migrate command to move issues between repos\n- bd init --contributor wizard for OSS setup\n- bd init --team wizard for team setup\n- Auto-detect scenarios and prompt users\n- Examples for common workflows (OSS, multi-phase, personas)\n\nScenarios:\n1. OSS contributor (fork workflow)\n2. Team member (branch workflow)\n3. Multi-phase development\n4. Multiple personas (architect/implementer)","acceptance_criteria":"1. Migration guide covers all scenarios\n2. bd migrate moves issues with filtering\n3. Init wizards guide common setups\n4. Examples demonstrate key workflows\n5. Auto-detection prompts users when appropriate\n6. Docs updated with multi-repo patterns\n7. Backward compatibility clearly documented","status":"open","priority":2,"issue_type":"epic","created_at":"2025-11-04T11:22:13.491033-08:00","updated_at":"2025-11-04T11:22:13.491033-08:00","dependencies":[{"issue_id":"bd-8rd","depends_on_id":"bd-4ms","type":"parent-child","created_at":"2025-11-04T11:22:21.858002-08:00","created_by":"daemon"}]}
{"id":"bd-9063acda","content_hash":"0ea4606188e376705c46a14e5d64da1b706aad47a39054a732c21330db601960","title":"Clean up linter errors (914 total issues)","description":"The codebase has 914 linter issues reported by golangci-lint. While many are documented as baseline in LINTING.md, we should clean these up systematically to improve code quality and maintainability.","design":"Break down by linter category, prioritizing high-impact issues:\n1. dupl (7) - Code duplication\n2. goconst (12) - Repeated strings\n3. gocyclo (11) - High complexity functions\n4. revive (78) - Style issues\n5. gosec (102) - Security warnings\n6. errcheck (683) - Unchecked errors (many in tests)","acceptance_criteria":"All linter categories reduced to acceptable levels, with remaining baseline documented in LINTING.md","notes":"Reduced from 56 to 41 issues locally, then to 0 issues.\n\n**Fixed in commits:**\n- c2c7eda: Fixed 15 actual errors (dupl, gosec, revive, staticcheck, unparam)\n- 963181d: Configured exclusions to get to 0 issues locally\n\n**Current status:**\n- ✅ Local: golangci-lint reports 0 issues\n- ❌ CI: Still failing (see [deleted:bd-cb64c226.1])\n\n**Problem:**\nConfig v2 format or golangci-lint-action@v8 compatibility issue causing CI to fail despite local success.\n\n**Next:** Debug [deleted:bd-cb64c226.1] to fix CI/local discrepancy","status":"closed","priority":2,"issue_type":"epic","created_at":"2025-10-24T01:01:12.997982-07:00","updated_at":"2025-11-02T15:58:53.555077-08:00","closed_at":"2025-11-02T15:58:53.555084-08:00"}
{"id":"bd-90a5","content_hash":"e54904609d3be88a50850d032fbbc1729a48d79436ff0ab5204d1cc044b93c47","title":"Extract hash ID generation functions to hash_ids.go","description":"Move generateHashID, getNextChildNumber, GetNextChildID to hash_ids.go","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-01T19:28:54.890883-07:00","updated_at":"2025-11-02T12:32:00.159056-08:00","closed_at":"2025-11-02T12:32:00.159058-08:00"}
@@ -192,7 +192,7 @@
{"id":"bd-bc2c6191","content_hash":"533e56b8628e24229a4beb52f8683355f6ca699e34a73650bf092003d73c2957","title":"Audit Current Cache Usage","description":"Understand exactly what code depends on the storage cache","acceptance_criteria":"- Document showing all cache dependencies\n- Confirmation that removing cache won't break MCP\n- List of tests that need updating\n\nFiles to examine:\n- internal/rpc/server_cache_storage.go (cache implementation)\n- internal/rpc/client.go (how req.Cwd is set)\n- internal/rpc/server_*.go (all getStorageForRequest calls)\n- integrations/beads-mcp/ (MCP multi-repo logic)\n\nTasks:\n- Document all callers of getStorageForRequest()\n- Verify req.Cwd is only set by RPC client for database discovery\n- Confirm MCP server doesn't rely on multi-repo cache behavior\n- Check if any tests assume multi-repo routing\n- Review environment variables: BEADS_DAEMON_MAX_CACHE_SIZE, BEADS_DAEMON_CACHE_TTL, BEADS_DAEMON_MEMORY_THRESHOLD_MB","status":"open","priority":1,"issue_type":"task","created_at":"2025-10-27T23:02:43.506373-07:00","updated_at":"2025-10-31T20:36:49.334214-07:00"}
{"id":"bd-bdaf24d5","content_hash":"64067e38421a77f1b54fca73e6b98923d15aca0933463a1fa6862270c3102566","title":"Final validation test","description":"","status":"closed","priority":2,"issue_type":"task","created_at":"2025-10-27T18:27:28.310533-07:00","updated_at":"2025-10-31T12:00:43.184995-07:00","closed_at":"2025-10-31T12:00:43.184995-07:00"}
{"id":"bd-be7a","content_hash":"d9043a7a49f8e42dc88c3c01aaa178c1560b67c1637c3373b39c387272e8b725","title":"Create npm package structure with package.json","description":"Set up initial npm package structure for @beads/bd:\n\n## Files to create\n- npm/package.json - Package metadata, dependencies, scripts\n- npm/bin/bd - CLI wrapper script that invokes native binary\n- npm/.gitignore - Ignore downloaded binaries\n- npm/README.md - Installation and usage instructions\n\n## package.json structure\n- Name: @beads/bd (scoped package)\n- Main: index.js (exports binary path)\n- Bin: bin/bd (CLI entry point)\n- Scripts: postinstall (download binary)\n- Keywords: issue-tracker, cli, beads, bd\n- License: MIT\n\n## Bin wrapper\nSimple Node.js script that:\n- Spawns native binary with child_process.spawn\n- Passes through all arguments and stdio\n- Exits with binary's exit code","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-02T23:39:47.416779-08:00","updated_at":"2025-11-03T10:31:45.381258-08:00","closed_at":"2025-11-03T10:31:45.381258-08:00","dependencies":[{"issue_id":"bd-be7a","depends_on_id":"bd-febc","type":"parent-child","created_at":"2025-11-02T23:40:32.923859-08:00","created_by":"daemon"}]}
{"id":"bd-btsm","content_hash":"8b4a73c63ae469f6ace709a1170de9782eb341fa9c8aa0da7abf1f9baa20e593","title":"Test explicit repo","description":"","status":"open","priority":1,"issue_type":"task","created_at":"2025-11-04T17:00:02.281431-08:00","updated_at":"2025-11-04T17:00:02.281431-08:00"}
{"id":"bd-btsm","content_hash":"8b4a73c63ae469f6ace709a1170de9782eb341fa9c8aa0da7abf1f9baa20e593","title":"Test explicit repo","description":"","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-04T17:00:02.281431-08:00","updated_at":"2025-11-04T17:47:16.998298-08:00","closed_at":"2025-11-04T17:47:16.998298-08:00"}
{"id":"bd-c01f","content_hash":"14269c39f13784e0ee793fae005b1869fea5c08af1bbdc4a2f841720278180d5","title":"Implement bd stale command to find abandoned/forgotten issues","description":"Add bd stale command to surface issues that haven't been updated recently and may need attention.\n\nUse cases:\n- In-progress issues with no recent activity (may be abandoned)\n- Open issues that have been forgotten\n- Issues that might be outdated or no longer relevant\n\nQuery logic should find non-closed issues where updated_at exceeds a time threshold.\n\nShould support:\n- --days N flag (default 30-90 days)\n- --status filter (e.g., only in_progress)\n- --json output for automation\n\nReferences GitHub issue #184 where user expected this command to exist.","design":"Implementation approach:\n1. Add new command in cmd/bd/stale.go\n2. Query issues with: status != 'closed' AND updated_at \u003c (now - N days)\n3. Support filtering by status (open, in_progress, blocked)\n4. Default threshold: 30 days (configurable via --days)\n5. JSON output for agent consumption\n6. Order by updated_at ASC (oldest first)","status":"closed","priority":2,"issue_type":"epic","created_at":"2025-10-31T22:48:46.85435-07:00","updated_at":"2025-10-31T22:54:33.704492-07:00","closed_at":"2025-10-31T22:54:33.704492-07:00"}
{"id":"bd-c362","content_hash":"3b9c44101d7f31fb6cbf4913873a4e140e74fbe7403907e8532bfaaabf875197","title":"Extract database search logic into helper function","description":"The logic for finding a database in a beads directory is duplicated:\n- FindDatabasePath() BEADS_DIR section (beads.go:141-169)\n- findDatabaseInTree() (beads.go:248-280)\n\nBoth implement the same search order:\n1. Check config.json first (single source of truth)\n2. Fall back to canonical beads.db\n3. Search for *.db files, filtering backups and vc.db\n\nRefactoring suggestion:\nExtract to a helper function like:\n func findDatabaseInBeadsDir(beadsDir string) string\n\nBenefits:\n- Single source of truth for database search logic\n- Easier to maintain and update search order\n- Reduces code duplication\n\nRelated to bd-e16b implementation.","status":"open","priority":3,"issue_type":"chore","created_at":"2025-11-02T18:34:02.831543-08:00","updated_at":"2025-11-02T18:34:02.831543-08:00","dependencies":[{"issue_id":"bd-c362","depends_on_id":"bd-e16b","type":"blocks","created_at":"2025-11-02T18:34:02.832607-08:00","created_by":"daemon"}]}
{"id":"bd-c77d","content_hash":"5d66618a9b287d1af262d989cb26932cb50b0cb0aa8e8e9365c3298a39db5f2d","title":"Test SQLite WASM compatibility","description":"Verify modernc.org/sqlite works in WASM target. Child of epic bd-44d0.\n\n## Tasks\n- [ ] Compile minimal SQLite test to WASM\n- [ ] Test database create/open operations\n- [ ] Test query execution\n- [ ] Test JSONL import/export\n- [ ] Benchmark performance vs native\n\n## Decision Point\nIf modernc.org/sqlite issues, evaluate ncruces/go-sqlite3 alternative.","status":"open","priority":0,"issue_type":"task","created_at":"2025-11-02T18:33:31.247537-08:00","updated_at":"2025-11-02T18:33:31.247537-08:00","dependencies":[{"issue_id":"bd-c77d","depends_on_id":"bd-197b","type":"blocks","created_at":"2025-11-02T18:33:31.248112-08:00","created_by":"daemon"}]}
@@ -284,9 +284,9 @@
{"id":"bd-febc","content_hash":"686e0d5e3d56abe0edbd203d3d138ee3b013f55b6aed1eac05a56e6e3a5cc261","title":"npm package for bd with native binaries","description":"Create an npm package that wraps native bd binaries for easy installation in Claude Code for Web and other Node.js environments.\n\n## Problem\nClaude Code for Web sandboxes are full Linux VMs with npm support, but cannot easily download binaries from GitHub releases due to network restrictions or tooling limitations.\n\n## Solution\nPublish bd as an npm package that:\n- Downloads platform-specific native binaries during postinstall\n- Provides a CLI wrapper that invokes the native binary\n- Works seamlessly in Claude Code for Web SessionStart hooks\n- Maintains full feature parity (uses native SQLite)\n\n## Benefits vs WASM\n- ✅ Full SQLite support (no custom VFS needed)\n- ✅ All features work identically to native bd\n- ✅ Better performance (native vs WASM overhead)\n- ✅ ~4 hours effort vs ~2 days for WASM\n- ✅ Minimal maintenance burden\n\n## Success Criteria\n- npm install @beads/bd works in Claude Code for Web\n- All bd commands function identically to native binary\n- SessionStart hook documented for auto-installation\n- Package published to npm registry","status":"closed","priority":1,"issue_type":"epic","created_at":"2025-11-02T23:39:37.684109-08:00","updated_at":"2025-11-03T10:39:44.932565-08:00","closed_at":"2025-11-03T10:39:44.932565-08:00"}
{"id":"bd-k58","content_hash":"d4b9e8a12c4870015bb8d8bbe5681db2ab75c09ff4b5bf3be98a60aeb32eb303","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":"open","priority":1,"issue_type":"epic","created_at":"2025-11-04T11:21:41.113647-08:00","updated_at":"2025-11-04T11:21:41.113647-08:00","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-mxtc","content_hash":"4f681a5a99c431e080514ae872cb54a80dc760628ed6e3ec8555e121c48715b2","title":"Implement maintainer vs contributor detection","description":"Detect whether user is a maintainer or contributor based on git config and repository permissions. This determines which repo (primary vs planning) should receive new issues.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-04T16:48:38.060925-08:00","updated_at":"2025-11-04T16:50:02.150209-08:00","closed_at":"2025-11-04T16:50:02.150209-08:00","dependencies":[{"issue_id":"bd-mxtc","depends_on_id":"bd-8hf","type":"parent-child","created_at":"2025-11-04T16:48:38.062538-08:00","created_by":"stevey"}]}
{"id":"bd-nzt4","content_hash":"3259db0248fa67e46885e14bf908b3a29ddb644f5bd6e53adfe6f8ecad960a52","title":"Test maintainer routing","description":"","status":"open","priority":1,"issue_type":"task","created_at":"2025-11-04T17:00:01.698681-08:00","updated_at":"2025-11-04T17:00:01.698681-08:00"}
{"id":"bd-nzt4","content_hash":"3259db0248fa67e46885e14bf908b3a29ddb644f5bd6e53adfe6f8ecad960a52","title":"Test maintainer routing","description":"","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-04T17:00:01.698681-08:00","updated_at":"2025-11-04T17:47:11.338097-08:00","closed_at":"2025-11-04T17:47:11.338097-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-ubu2","content_hash":"1bfcd60255e63ff234519bea06c2f47542f75d7cbb0c23aae64b3ae1e09dfda6","title":"Implement auto-routing for bd create based on user role","description":"Route new issues to correct repo automatically based on maintainer/contributor status. Apply config-based routing rules with --repo flag override support.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-04T16:48:43.726578-08:00","updated_at":"2025-11-04T17:00:30.225329-08:00","closed_at":"2025-11-04T17:00:30.225329-08:00","dependencies":[{"issue_id":"bd-ubu2","depends_on_id":"bd-8hf","type":"parent-child","created_at":"2025-11-04T16:48:43.728183-08:00","created_by":"stevey"}]}
{"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"}
{"id":"bd-zmi5","content_hash":"a5274a21b6bc4948ff5b1aac4fe3e7791d7a70e907c8b16f270a28f8b75e84ad","title":"Test contributor routing","description":"","status":"open","priority":1,"issue_type":"task","created_at":"2025-11-04T17:00:01.106133-08:00","updated_at":"2025-11-04T17:00:01.106133-08:00"}
{"id":"bd-zmi5","content_hash":"a5274a21b6bc4948ff5b1aac4fe3e7791d7a70e907c8b16f270a28f8b75e84ad","title":"Test contributor routing","description":"","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-04T17:00:01.106133-08:00","updated_at":"2025-11-04T17:47:05.669252-08:00","closed_at":"2025-11-04T17:47:05.669252-08:00"}