bd sync: 2025-11-23 21:08:58
This commit is contained in:
@@ -633,7 +633,7 @@
|
||||
{"id":"bd-u4f5","content_hash":"ef770c563aa1907472ac2599b030242ba362bcde85a694737f969391fd4affb3","title":"bd import silently succeeds when database matches working tree but not git HEAD","description":"**Critical**: bd import reports '0 created, 0 updated' when database matches working tree JSONL, even when working tree is ahead of git HEAD. This gives false confidence that everything is synced with the source of truth.\n\n## Reproduction\n\n1. Start with database synced to working tree .beads/issues.jsonl (376 issues)\n2. Git HEAD has older version of .beads/issues.jsonl (354 issues)\n3. Run: bd import .beads/issues.jsonl\n4. Output: 'Import complete: 0 created, 0 updated'\n\n## Problem\n\nUser expects 'bd import' after 'git pull' to sync database with committed state, but:\n- Command silently succeeds because DB already matches working tree\n- No warning that working tree has uncommitted changes\n- User falsely believes everything is synced with git\n- Violates 'JSONL in git is source of truth' principle\n\n## Expected Behavior\n\nWhen .beads/issues.jsonl differs from git HEAD, bd import should:\n1. Detect uncommitted changes: git diff --quiet HEAD .beads/issues.jsonl\n2. Warn user: 'Warning: .beads/issues.jsonl has uncommitted changes (376 lines vs 354 in HEAD)'\n3. Clarify status: 'Import complete: 0 created, 0 updated (already synced with working tree)'\n4. Recommend: 'Run git diff .beads/issues.jsonl to review uncommitted work'\n\n## Impact\n\n- Users can't trust 'bd import' status messages\n- Silent data loss risk if user assumes synced and runs git checkout\n- Breaks mental model of 'JSONL in git = source of truth'\n- Critical for VC's landing-the-plane workflow","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-07T23:51:28.536822-08:00","updated_at":"2025-11-07T23:58:34.482313-08:00","closed_at":"2025-11-07T23:58:34.482313-08:00","source_repo":".","labels":["data-integrity"]}
|
||||
{"id":"bd-u4sb","content_hash":"12afcfe4009b34cecb06fcded5903d4b1ce4e06a57e121669068bfbb24446a3e","title":"bd doctor should validate metadata.json version tracking","description":"bd doctor should check that metadata.json has the LastBdVersion field and that it's valid.\n\nChecks to add:\n- metadata.json exists and is valid JSON\n- LastBdVersion field is present\n- LastBdVersion is a valid semver-like string (or empty on first run)\n- Optionally warn if LastBdVersion is very old (\u003e 10 versions behind)\n\nThis helps ensure version tracking (bd-loka) is working correctly.\n\nRelated: bd-loka","status":"closed","priority":2,"issue_type":"feature","created_at":"2025-11-23T17:19:08.140971-08:00","updated_at":"2025-11-23T17:27:54.857447-08:00","closed_at":"2025-11-23T17:27:54.857447-08:00","source_repo":"."}
|
||||
{"id":"bd-u8j","content_hash":"776ccc476b2cdfeca6758f8b6bf553059f04189d2ebe9fe1e8128d7165839968","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","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-03T20:24:08.257493-08:00","updated_at":"2025-11-05T14:15:01.506885-08:00","closed_at":"2025-11-05T14:15:01.506885-08:00","source_repo":"."}
|
||||
{"id":"bd-ue7e","content_hash":"364998a8040200d5fb0ca99f75518112b4f13d0b0fdbcbf6328a4fd7dc7cb607","title":"Add mutex protection for dirtyIssues map in autoflush.go","description":"**Location:** cmd/bd/autoflush.go (global state)\n\n**Issue:** Global dirtyIssues map is modified without synchronization across goroutines. Daemon event loop and flush manager both access this shared state with no documented mutex protection.\n\n**Impact:** Potential race conditions leading to:\n- Lost dirty tracking\n- Concurrent map access panics\n- Data corruption on flush\n\n**Evidence:** 277 occurrences of Lock/Unlock patterns found in cmd/bd but no evidence of protection for dirty tracking.\n\n**Fix:** Implement mutex-protected map or use sync.Map for concurrent access to dirtyIssues.","status":"open","priority":1,"issue_type":"bug","created_at":"2025-11-23T19:46:43.936939-08:00","updated_at":"2025-11-23T19:46:43.936939-08:00","source_repo":"."}
|
||||
{"id":"bd-ue7e","content_hash":"9043d82902856402aa5cd260602e5db2dc9d98d0cf57ae7e17406829a88c7811","title":"Add mutex protection for dirtyIssues map in autoflush.go","description":"**Location:** cmd/bd/autoflush.go (global state)\n\n**Issue:** Global dirtyIssues map is modified without synchronization across goroutines. Daemon event loop and flush manager both access this shared state with no documented mutex protection.\n\n**Impact:** Potential race conditions leading to:\n- Lost dirty tracking\n- Concurrent map access panics\n- Data corruption on flush\n\n**Evidence:** 277 occurrences of Lock/Unlock patterns found in cmd/bd but no evidence of protection for dirty tracking.\n\n**Fix:** Implement mutex-protected map or use sync.Map for concurrent access to dirtyIssues.","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-11-23T19:46:43.936939-08:00","updated_at":"2025-11-23T21:07:29.683881-08:00","closed_at":"2025-11-23T21:07:29.683881-08:00","source_repo":"."}
|
||||
{"id":"bd-uiae","content_hash":"5c184901daaa674a0f1224a29ab789019b53da6d5b5b4d6ac943e7d5d4846b3e","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-06T18:19:16.234758-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":"fc0e79260f5f6860fa8884859c4b33b18f9cc2dad361c1c1abb9bdeb412479b5","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":"closed","priority":3,"issue_type":"chore","created_at":"2025-11-06T18:16:27.943666-08:00","updated_at":"2025-11-08T02:24:24.686744-08:00","closed_at":"2025-11-08T02:19:14.152412-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-ut5","content_hash":"d9b4ee9c7748c28dc2cd436911b1bee39e68e82df99b718ebe57a246f72a6bcb","title":"Test label update feature","description":"","status":"open","priority":3,"issue_type":"task","created_at":"2025-11-21T22:07:25.488849-05:00","updated_at":"2025-11-21T22:07:25.488849-05:00","source_repo":".","labels":["test-direct"]}
|
||||
|
||||
Reference in New Issue
Block a user