bd sync: 2025-11-29 20:21:54

.beads/issues.jsonl

@@ -37,6 +37,7 @@
 {"id":"bd-e92","title":"Add test coverage for internal/autoimport package","description":"","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-20T21:21:22.338577-05:00","updated_at":"2025-11-28T22:17:12.608565-08:00","closed_at":"2025-11-28T21:52:34.222127-08:00","dependencies":[{"issue_id":"bd-e92","depends_on_id":"bd-ge7","type":"blocks","created_at":"2025-11-20T21:21:31.128625-05:00","created_by":"daemon"}]}
 {"id":"bd-emg","title":"bd init should refuse when JSONL already has issues (safety guard)","description":"When running `bd init` in a directory with an existing JSONL containing issues, bd should refuse and suggest the correct action instead of proceeding.\n\n## The Problem\n\nCurrent behavior when database is missing but JSONL exists:\n```\n$ bd create \"test\"\nError: no beads database found\nHint: run 'bd init' to create a database...\n```\n\nThis leads users (and AI agents) to reflexively run `bd init`, which can cause:\n- Prefix mismatch if wrong prefix specified\n- Data corruption if JSONL is damaged\n- Confusion about what actually happened\n\n## Proposed Behavior\n\n```\n$ bd init --prefix bd\n\n⚠ Found existing .beads/issues.jsonl with 76 issues.\n\nThis appears to be a fresh clone, not a new project.\n\nTo hydrate the database from existing JSONL:\n  bd doctor --fix\n\nTo force re-initialization (may cause data loss):\n  bd init --prefix bd --force\n\nAborting.\n```\n\n## Trigger Conditions\n\n- `.beads/issues.jsonl` or `.beads/beads.jsonl` exists\n- File contains \u003e 0 valid issue lines\n- No `--force` flag provided\n\n## Edge Cases\n\n- Empty JSONL (0 issues) → allow init (new project)\n- Corrupted JSONL → warn but allow with confirmation\n- Existing `.db` file → definitely refuse (weird state)\n\n## Related\n\n- bd-dmb: Fresh clone should suggest hydration (better error messages)\n- bd-4ew: bd doctor should detect fresh clone\n\nThis issue is about the safety guard on `bd init` itself, not the error messages from other commands.","status":"closed","priority":2,"issue_type":"bug","created_at":"2025-11-28T18:21:41.149304-08:00","updated_at":"2025-11-28T22:17:18.849507-08:00","closed_at":"2025-11-28T22:17:18.849507-08:00"}
 {"id":"bd-f0n","title":"Git history fallback missing timeout - could hang on large repos","description":"## Problem\n\nThe git commands in `checkGitHistoryForDeletions` have no timeout. On large repos with extensive history, `git log --all -S` or `git log --all -G` can take a very long time (minutes).\n\n## Location\n`internal/importer/importer.go:899` and `:930`\n\n## Impact\n- Import could hang indefinitely\n- User has no feedback that git search is running\n- No way to cancel except killing the process\n\n## Fix\nAdd context with timeout to git commands:\n\n```go\nctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)\ndefer cancel()\ncmd := exec.CommandContext(ctx, \"git\", ...)\n```\n\nAlso consider adding a `--since` flag to bound the git history search.","status":"closed","priority":2,"issue_type":"bug","created_at":"2025-11-25T12:48:24.388639-08:00","updated_at":"2025-11-25T15:04:53.669714-08:00","closed_at":"2025-11-25T15:04:53.669714-08:00"}
+{"id":"bd-f2f","title":"CRITICAL: bd sync exports before pull, allowing stale DB to corrupt JSONL statuses","description":"## Root Cause\n\nThe fix in bd-53c (reverse ZFC check) only checks COUNTS, not content. The real corruption happens when:\n\n1. Polecat A has stale DB with old status values (e.g., status=closed for issues that are now open on remote)\n2. Polecat A runs bd sync:\n   - **Export FIRST**: DB (status=closed) → JSONL (overwrites correct status=open)\n   - Commit: Stale JSONL committed\n   - Pull: 3-way merge with remote\n   - Merge uses 'closed wins' rule → status stays closed\n3. Polecat A pushes → Remote now corrupted with status=closed\n\n## Why bd-53c didn't fix it\n\nThe reverse ZFC check compares COUNTS:\n```go\nif jsonlCount \u003e dbCount  // Only catches count mismatch\n```\n\nBut in the corruption scenario:\n- JSONL count = 5, DB count = 5 (same count!)\n- Only the STATUS field differs\n\n## The Real Fix\n\n**PULL BEFORE EXPORT**. The sync order must be:\n1. Pull from remote (get latest state)\n2. Import merged JSONL to DB\n3. THEN export DB changes (if any)\n\nCurrent order is: Export → Commit → Pull → Import → Push\n\nThis is a fundamental architecture change to the sync flow.\n\n## Workaround\n\nUse --no-auto-flush and manually control the sync order, or disable daemon auto-export.\n\n## Evidence\n\nFrom user investigation:\n- At 595b7943 (13:20:30): 5 open issues\n- At 10239812 (13:28:39): 0 open issues\n- All 5 issues had their status changed from open to closed\n- Count stayed at 5 (not a deletion issue)","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-29T17:33:26.744766-08:00","updated_at":"2025-11-29T19:24:31.010075-08:00","closed_at":"2025-11-29T19:24:31.010075-08:00","close_reason":"Fixed: Added Case 3 (bd-f2f) hash-based staleness detection in sync.go. When JSONL content hash differs from stored hash, we now import first before exporting. This catches the corruption scenario where counts match but status/content differs. The fix builds on the existing hasJSONLChanged() infrastructure. Added test TestHashBasedStalenessDetection_bd_f2f."}
 {"id":"bd-ge7","title":"Improve Beads test coverage from 46% to 80%","description":"","status":"closed","priority":1,"issue_type":"epic","created_at":"2025-11-20T21:21:03.700271-05:00","updated_at":"2025-11-28T22:17:12.608871-08:00","closed_at":"2025-11-28T21:56:04.085939-08:00"}
 {"id":"bd-ghb","title":"Add --yes flag to bd doctor --fix for non-interactive mode","description":"## Feature Request\n\nAdd a `--yes` or `-y` flag to `bd doctor --fix` that automatically confirms all prompts, enabling non-interactive usage in scripts and CI/CD pipelines.\n\n## Current Behavior\n`bd doctor --fix` prompts for confirmation before applying fixes, which blocks automated workflows.\n\n## Desired Behavior\n`bd doctor --fix --yes` should apply all fixes without prompting.\n\n## Use Cases\n- CI/CD pipelines that need to auto-fix issues\n- Scripts that automate repository setup\n- Pre-commit hooks that want to silently fix issues","status":"closed","priority":3,"issue_type":"feature","created_at":"2025-11-26T23:22:45.486584-08:00","updated_at":"2025-11-28T22:17:12.609134-08:00","closed_at":"2025-11-28T21:55:06.895066-08:00"}
 {"id":"bd-gqo","title":"Implement health checks in daemon event loop","description":"Add health checks to checkDaemonHealth() function in daemon_event_loop.go:170:\n- Database integrity check\n- Disk space check\n- Memory usage check\n\nCurrently it's just a no-op placeholder.","status":"open","priority":3,"issue_type":"feature","created_at":"2025-11-21T18:55:07.534304-05:00","updated_at":"2025-11-21T18:55:07.534304-05:00"}