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

Merge branch 'main' of github.com:steveyegge/beads

Browse Source 
# Conflicts:
#	.beads/beads.jsonl
This commit is contained in:
Steve Yegge
2025-11-06 19:41:52 -08:00
parent 5c1f441c2a 7afb1439f2
commit 20eafa103a
2 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.beads/beads.jsonl
View File

@@ -267,7 +267,7 @@
{"id":"bd-u8j","content_hash":"91f39bbd4f2394592407c77917682b2c7c3a0b6415a3572eb75a49b0486a17fe","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":"closed","priority":2,"issue_type":"task","created_at":"2025-11-03T20:24:08.257493-08:00","updated_at":"2025-11-05T14:19:11.205328-08:00","closed_at":"2025-11-05T14:15:01.506885-08:00","source_repo":"."}
{"id":"bd-uiae","content_hash":"8627a2c5b57679bf49965553f9ec879045ce9a87023455f1d46fcc683f193f3c","title":"Update documentation for beads-merge integration","description":"Document the integrated merge functionality.\n\n**Updates needed**:\n- AGENTS.md: Replace \"use external beads-merge\" with \"bd merge\"\n- README.md: Add git merge driver section\n- TROUBLESHOOTING.md: Update merge conflict resolution\n- ADVANCED.md: Document 3-way merge algorithm\n- Create CREDITS.md or ATTRIBUTION.md for @neongreen\n\n**Highlight**: Deletion sync fix (bd-hv01)","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-05T18:42:20.488998-08:00","updated_at":"2025-11-06T15:40:27.830475-08:00","closed_at":"2025-11-06T15:40:27.830475-08:00","source_repo":".","dependencies":[{"issue_id":"bd-uiae","depends_on_id":"bd-qqvw","type":"parent-child","created_at":"2025-11-05T18:42:28.752447-08:00","created_by":"daemon"}]}
{"id":"bd-urob","content_hash":"7046a4e101c3ff6030c236c13a7b6bb5d64c54170e8d792768a9f7a8fd5781bf","title":"bd-hv01: Refactor snapshot management into dedicated module","description":"Problem: Snapshot logic is scattered across deletion_tracking.go. Would benefit from abstraction with SnapshotManager type.\n\nBenefits: cleaner separation of concerns, easier to test in isolation, better encapsulation, could add observability/metrics.\n\nSuggested improvements: add magic constants, track merge statistics, better error messages.\n\nFiles: cmd/bd/deletion_tracking.go (refactor into new snapshot_manager.go)","status":"open","priority":3,"issue_type":"chore","created_at":"2025-11-06T18:16:27.943666-08:00","updated_at":"2025-11-06T18:16:27.943666-08:00","source_repo":".","dependencies":[{"issue_id":"bd-urob","depends_on_id":"bd-rbxi","type":"parent-child","created_at":"2025-11-06T18:19:15.192447-08:00","created_by":"daemon"}]}
{"id":"bd-we4p","content_hash":"e60d28255cdb95b96ec50d36d51b97e937e7fb88eb751d11804d95e375fe042b","title":"Cache getMultiRepoJSONLPaths() result during sync to avoid redundant calls","description":"From bd-xo6b code review: getMultiRepoJSONLPaths() is called 3x per sync cycle.\n\n**Current behavior:**\ndaemon_sync.go calls getMultiRepoJSONLPaths() three times per sync:\n- Line 505: Snapshot capture before pull\n- Line 575: Merge/prune after pull\n- Line 613: Base snapshot update after import\n\n**Cost per call:**\n- Config lookup (likely cached, but still overhead)\n- Path construction: O(N) where N = number of repos\n- String allocations: (N + 1) × filepath.Join() calls\n\n**Total per sync:** 3N path constructions + 3 config lookups + 3 slice allocations\n\n**Impact:**\n- For N=3 repos: Negligible (\u003c 1ms)\n- For N=10 repos: Still minimal\n- For N=100+ repos: Wasteful\n\n**Solution:**\nCall once at sync start, reuse result:\n\n```go\nfunc createSyncFunc(...) func() {\n return func() {\n // ... existing setup ...\n \n // Call once at start\n multiRepoPaths := getMultiRepoJSONLPaths()\n \n // Snapshot capture\n if multiRepoPaths != nil {\n for _, path := range multiRepoPaths {\n if err := captureLeftSnapshot(path); err != nil { ... }\n }\n }\n \n // ... later ...\n \n // Merge/prune - reuse same paths\n if multiRepoPaths != nil {\n for _, path := range multiRepoPaths { ... }\n }\n \n // ... later ...\n \n // Base snapshot update - reuse same paths\n if multiRepoPaths != nil {\n for _, path := range multiRepoPaths { ... }\n }\n }\n}\n```\n\n**Files:**\n- cmd/bd/daemon_sync.go:449-636 (createSyncFunc)\n\n**Note:** This is a performance optimization, not a correctness fix. Low priority unless multi-repo usage scales significantly.","status":"open","priority":2,"issue_type":"chore","created_at":"2025-11-06T19:31:32.128674-08:00","updated_at":"2025-11-06T19:31:32.128674-08:00","source_repo":".","dependencies":[{"issue_id":"bd-we4p","depends_on_id":"bd-xo6b","type":"discovered-from","created_at":"2025-11-06T19:32:12.39754-08:00","created_by":"daemon"}]}
{"id":"bd-we4p","content_hash":"0e3248d31a6524c7a665960682cf2b159449fa31f5427771796dce8639059faf","title":"Cache getMultiRepoJSONLPaths() result during sync to avoid redundant calls","description":"From bd-xo6b code review: getMultiRepoJSONLPaths() is called 3x per sync cycle.\n\n**Current behavior:**\ndaemon_sync.go calls getMultiRepoJSONLPaths() three times per sync:\n- Line 505: Snapshot capture before pull\n- Line 575: Merge/prune after pull\n- Line 613: Base snapshot update after import\n\n**Cost per call:**\n- Config lookup (likely cached, but still overhead)\n- Path construction: O(N) where N = number of repos\n- String allocations: (N + 1) × filepath.Join() calls\n\n**Total per sync:** 3N path constructions + 3 config lookups + 3 slice allocations\n\n**Impact:**\n- For N=3 repos: Negligible (\u003c 1ms)\n- For N=10 repos: Still minimal\n- For N=100+ repos: Wasteful\n\n**Solution:**\nCall once at sync start, reuse result:\n\n```go\nfunc createSyncFunc(...) func() {\n return func() {\n // ... existing setup ...\n \n // Call once at start\n multiRepoPaths := getMultiRepoJSONLPaths()\n \n // Snapshot capture\n if multiRepoPaths != nil {\n for _, path := range multiRepoPaths {\n if err := captureLeftSnapshot(path); err != nil { ... }\n }\n }\n \n // ... later ...\n \n // Merge/prune - reuse same paths\n if multiRepoPaths != nil {\n for _, path := range multiRepoPaths { ... }\n }\n \n // ... later ...\n \n // Base snapshot update - reuse same paths\n if multiRepoPaths != nil {\n for _, path := range multiRepoPaths { ... }\n }\n }\n}\n```\n\n**Files:**\n- cmd/bd/daemon_sync.go:449-636 (createSyncFunc)\n\n**Note:** This is a performance optimization, not a correctness fix. Low priority unless multi-repo usage scales significantly.","status":"closed","priority":2,"issue_type":"chore","created_at":"2025-11-06T19:31:32.128674-08:00","updated_at":"2025-11-06T19:41:31.882168-08:00","closed_at":"2025-11-06T19:40:50.871176-08:00","source_repo":".","dependencies":[{"issue_id":"bd-we4p","depends_on_id":"bd-xo6b","type":"discovered-from","created_at":"2025-11-06T19:32:12.39754-08:00","created_by":"daemon"}]}
{"id":"bd-wta","content_hash":"eee40bbe4e00af632ad46e1461a25e4b0e5508bea115422aea0772381eec0d84","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":"closed","priority":2,"issue_type":"task","created_at":"2025-11-03T20:24:39.331528-08:00","updated_at":"2025-11-05T14:19:11.205631-08:00","closed_at":"2025-11-05T14:17:15.079226-08:00","source_repo":"."}
{"id":"bd-x47","content_hash":"e363d887fa6693c1c748d78ea9cdaaa97606889d910f318fbd29584576da57e9","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":"closed","priority":2,"issue_type":"task","created_at":"2025-11-03T20:24:27.805341-08:00","updated_at":"2025-11-05T14:19:11.205917-08:00","closed_at":"2025-11-05T14:16:34.69662-08:00","source_repo":"."}
{"id":"bd-xo6b","content_hash":"edf43a7439dbccd5f280111a1e277b758f5c2d4c57bd01c5086cfdd6118511e7","title":"Review multi-repo deletion tracking implementation","description":"Thoroughly review the multi-repo deletion tracking fix (bd-4oob):\n\nFiles changed:\n- cmd/bd/deletion_tracking.go: Added getMultiRepoJSONLPaths() helper\n- cmd/bd/daemon_sync.go: Updated snapshot capture/update logic for multi-repo\n- cmd/bd/deletion_tracking_test.go: Added 2 new tests (287 lines)\n\nReview focus areas:\n1. Correctness: Does getMultiRepoJSONLPaths() handle all edge cases?\n2. Performance: Calling getMultiRepoJSONLPaths() 3x per sync (snapshot capture, merge, base update) - should we cache?\n3. Error handling: What if some repos fail snapshot operations but others succeed?\n4. Race conditions: Multiple daemons in different repos?\n5. Test coverage: Are TestMultiRepoDeletionTracking and TestMultiRepoSnapshotIsolation sufficient?\n6. Path handling: Absolute vs relative paths, tilde expansion\n\nThis is fresh code - needs careful review before considering deletion tracking production-ready.","notes":"Code review completed. Overall assessment: Core deletion tracking logic is sound, but error handling and path handling issues make this not yet production-ready for multi-repo scenarios.\n\nKey findings:\n\nCRITICAL ISSUES (Priority 1):\n1. Inconsistent error handling in daemon_sync.go - snapshot/merge fail hard but base update warns. Can leave DB in inconsistent state with no rollback. See bd-sjmr.\n2. No path normalization in getMultiRepoJSONLPaths() - tilde expansion, relative paths, duplicates not handled. See bd-iye7.\n\nSHOULD FIX (Priority 2):\n3. Missing test coverage for edge cases - empty paths, duplicates, partial failures. See bd-kdoh.\n4. Performance - getMultiRepoJSONLPaths() called 3x per sync (minor issue). See bd-we4p.\n\nWHAT WORKS WELL:\n- Atomic file operations with PID-based temp files\n- Good snapshot isolation between repos\n- Race condition protection via exclusive locks\n- Solid test coverage for happy path scenarios\n\nVERDICT: Address bd-iye7 and bd-sjmr before considering deletion tracking production-ready for multi-repo mode.\n\nDetailed review notes available in conversation history.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-06T19:23:52.402949-08:00","updated_at":"2025-11-06T19:32:34.160341-08:00","closed_at":"2025-11-06T19:32:34.160341-08:00","source_repo":".","dependencies":[{"issue_id":"bd-xo6b","depends_on_id":"bd-rbxi","type":"parent-child","created_at":"2025-11-06T19:23:52.403723-08:00","created_by":"daemon"}]}

18
cmd/bd/daemon_sync.go
View File

@@ -459,6 +459,9 @@ func createSyncFunc(ctx context.Context, store storage.Storage, autoCommit, auto
return
}
// Cache multi-repo paths to avoid redundant calls (bd-we4p)
multiRepoPaths := getMultiRepoJSONLPaths()
// Check for exclusive lock before processing database
beadsDir := filepath.Dir(jsonlPath)
skip, holder, err := types.ShouldSkipDatabase(beadsDir)
@@ -502,7 +505,6 @@ func createSyncFunc(ctx context.Context, store storage.Storage, autoCommit, auto
// Capture left snapshot (pre-pull state) for 3-way merge
// This is mandatory for deletion tracking integrity
// In multi-repo mode, capture snapshots for all JSONL files
multiRepoPaths := getMultiRepoJSONLPaths()
if multiRepoPaths != nil {
// Multi-repo mode: snapshot each JSONL file
for _, path := range multiRepoPaths {
@@ -572,16 +574,15 @@ func createSyncFunc(ctx context.Context, store storage.Storage, autoCommit, auto
// Perform 3-way merge and prune deletions
// In multi-repo mode, apply deletions for each JSONL file
multiRepoPathsForMerge := getMultiRepoJSONLPaths()
if multiRepoPathsForMerge != nil {
// Multi-repo mode: merge/prune for each JSONL
for _, path := range multiRepoPathsForMerge {
if multiRepoPaths != nil {
// Multi-repo mode: merge/prune for each JSONL
for _, path := range multiRepoPaths {
if err := applyDeletionsFromMerge(syncCtx, store, path); err != nil {
log.log("Error during 3-way merge for %s: %v", path, err)
return
}
}
log.log("Applied deletions from %d repos", len(multiRepoPathsForMerge))
log.log("Applied deletions from %d repos", len(multiRepoPaths))
} else {
// Single-repo mode
if err := applyDeletionsFromMerge(syncCtx, store, jsonlPath); err != nil {
@@ -610,9 +611,8 @@ func createSyncFunc(ctx context.Context, store storage.Storage, autoCommit, auto
// Update base snapshot after successful import
// In multi-repo mode, update snapshots for all JSONL files
multiRepoPathsForSnapshot := getMultiRepoJSONLPaths()
if multiRepoPathsForSnapshot != nil {
for _, path := range multiRepoPathsForSnapshot {
if multiRepoPaths != nil {
for _, path := range multiRepoPaths {
if err := updateBaseSnapshot(path); err != nil {
log.log("Warning: failed to update base snapshot for %s: %v", path, err)
}