bd daemon sync: 2026-01-07 19:20:08

.beads/issues.jsonl

@@ -553,6 +553,7 @@
 {"id":"bd-9ae788be","title":"Implement clone-scoped ID allocation to prevent N-way collisions","description":"## Problem\nCurrent ID allocation uses per-clone atomic counters (issue_counters table) that sync based on local database state. In N-way collision scenarios:\n- Clone B sees {test-1} locally, allocates test-2\n- Clone D sees {test-1, test-2, test-3} locally, allocates test-4\n- When same content gets assigned test-2 and test-4, convergence fails\n\nRoot cause: Each clone independently allocates IDs without global coordination, leading to overlapping assignments for the same content.\n\n## Solution\nAdd clone UUID to ID allocation to make every ID globally unique:\n\n**Current format:** `test-1`, `test-2`, `test-3`\n**New format:** `test-1-a7b3`, `test-2-a7b3`, `test-3-c4d9`\n\nWhere suffix is first 4 chars of clone UUID.\n\n## Implementation\n\n### 1. Add clone_identity table\n```sql\nCREATE TABLE clone_identity (\n    clone_uuid TEXT PRIMARY KEY,\n    created_at DATETIME DEFAULT CURRENT_TIMESTAMP\n);\n```\n\n### 2. Modify getNextIDForPrefix()\n```go\nfunc (s *SQLiteStorage) getNextIDForPrefix(ctx context.Context, prefix string) (string, error) {\n    cloneUUID := s.getOrCreateCloneUUID(ctx)\n    shortUUID := cloneUUID[:4]\n    \n    nextNum := s.getNextCounterForPrefix(ctx, prefix)\n    return fmt.Sprintf(\"%s-%d-%s\", prefix, nextNum, shortUUID), nil\n}\n```\n\n### 3. Update ID parsing logic\nAll places that parse IDs (utils.ExtractIssueNumber, etc.) need to handle new format.\n\n### 4. Migration strategy\n- Existing IDs remain unchanged (no suffix)\n- New IDs get clone suffix automatically\n- Display layer can hide suffix in UI: `bd-cb64c226.3-a7b3` → `#42`\n\n## Benefits\n- **Zero collision risk**: Same content in different clones gets different IDs\n- **Maintains readability**: Still sequential numbering within clone\n- **No coordination needed**: Works offline, no central authority\n- **Scales to 100+ clones**: 4-char hex = 65,536 unique clones\n\n## Concerns\n- ID format change may break existing integrations\n- Need migration path for existing databases\n- Display logic needs update to hide/show suffixes appropriately\n\n## Success Criteria\n- 10+ clone collision test passes without failures\n- Existing issues continue to work (backward compatibility)\n- Documentation updated with new ID format\n- Migration guide for v1.x → v2.x\n\n## Timeline\nMedium-term (v1.1-v1.2), 2-3 weeks implementation\n\n## References\n- Related to bd-e6d71828 (immediate fix)\n- See beads_nway_test.go for failing N-way tests","status":"closed","priority":2,"issue_type":"feature","created_at":"2025-10-29T10:22:52.260524-07:00","updated_at":"2025-12-14T12:12:46.561129-08:00","closed_at":"2025-11-08T00:36:58.134558-08:00"}
 {"id":"bd-9avq","title":"Fix wisp leak in nodb mode writeIssuesToJSONL","description":"writeIssuesToJSONL in nodb.go calls writeJSONLAtomic without filtering wisps. This means any wisps created during a nodb session would be written to issues.jsonl, leaking ephemeral data into the git-tracked file.\n\nFix: Add the same wisp filter pattern used in sync_export.go, autoflush.go, and export.go:\n\n```go\n// Filter out wisps before writing\nfiltered := make([]*types.Issue, 0, len(issues))\nfor _, issue := range issues {\n    if !issue.Wisp {\n        filtered = append(filtered, issue)\n    }\n}\nissues = filtered\n```\n\nLocation: cmd/bd/nodb.go:writeIssuesToJSONL()","status":"closed","priority":2,"issue_type":"bug","created_at":"2025-12-24T21:15:47.980048-08:00","updated_at":"2025-12-24T21:18:42.607711-08:00","closed_at":"2025-12-24T21:18:42.607711-08:00"}
 {"id":"bd-9b13","title":"Backend task","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-03T19:11:59.359262-08:00","updated_at":"2025-11-05T00:25:06.484312-08:00","closed_at":"2025-11-05T00:25:06.484312-08:00"}
+{"id":"bd-9bci0","title":"Session ended: gt-beads-crew-fang","status":"closed","priority":2,"issue_type":"event","created_at":"2026-01-07T19:20:07.546098-08:00","created_by":"beads/crew/fang","updated_at":"2026-01-07T19:20:07.584512-08:00","closed_at":"2026-01-07T19:20:07.584512-08:00","close_reason":"auto-closed session event"}
 {"id":"bd-9bsx","title":"Recurring dirty state after merge conflicts - bd sync keeps failing","description":"## Problem\n\n`bd sync` consistently fails with merge conflicts in `.beads/beads.jsonl`, creating a loop:\n1. User runs `bd sync`\n2. Git merge conflict occurs\n3. User resolves with `git checkout --theirs` (takes remote)\n4. Daemon auto-exports database state (which has local changes)\n5. JSONL becomes dirty again immediately\n6. Repeat\n\nThis has been happening for **weeks** and is extremely frustrating.\n\n## Root Cause\n\nThe recommended conflict resolution (`git checkout --theirs`) throws away local database state (comments, dependencies, closed issues). The daemon then immediately re-exports, creating a dirty state.\n\n## Current Workaround\n\nManual `bd export -o .beads/beads.jsonl \u0026\u0026 git add \u0026\u0026 git commit \u0026\u0026 git push` after every failed sync.\n\n## Example Session\n\n```bash\n$ bd sync\nCONFLICT (content): Merge conflict in .beads/beads.jsonl\n\n$ git checkout --theirs .beads/beads.jsonl \u0026\u0026 bd import \u0026\u0026 git add \u0026\u0026 git commit \u0026\u0026 git push\n# Pushed successfully\n\n$ git status\nmodified: .beads/beads.jsonl  # DIRTY AGAIN!\n```\n\n## Lost Data in Recent Session\n\n- bd-ry1u closure (lost in merge)\n- Comments on bd-08fd, bd-23a8, bd-6049, bd-87a0 (lost)\n- Dependencies that existed only in local DB\n\n## Potential Solutions\n\n1. **Use beads-merge tool** - Implement proper 3-way JSONL merge (bd-bzfy)\n2. **Smarter conflict resolution** - Detect when `--theirs` will lose data, warn user\n3. **Sync validation** - Check if JSONL == DB after merge, re-export if needed\n4. **Daemon awareness** - Pause auto-export during merge resolution\n5. **Transaction log** - Replay local changes after merge instead of losing them\n\n## Related Issues\n\n- bd-bzfy (beads-merge integration)\n- Possibly related to daemon auto-export behavior","notes":"## Solution Implemented\n\nFixed the recurring dirty state after merge conflicts by adding **sync validation** before re-exporting.\n\n### Root Cause\nLines 217-237 in `sync.go` unconditionally re-exported DB to JSONL after every import, even when they were already in sync. This created an infinite loop:\n1. User runs `bd sync` which pulls and imports remote JSONL\n2. Sync unconditionally re-exports DB (which has local changes)\n3. JSONL becomes dirty immediately\n4. Repeat\n\n### Fix\nAdded `dbNeedsExport()` function in `integrity.go` that checks:\n- If JSONL exists\n- If DB modification time is newer than JSONL\n- If DB and JSONL issue counts match\n\nNow `bd sync` only re-exports if DB actually has changes that differ from JSONL.\n\n### Changes\n- Added `dbNeedsExport()` in `cmd/bd/integrity.go` (lines 228-271)\n- Updated `sync.go` lines 217-251 to check before re-exporting\n- Added comprehensive tests in `cmd/bd/sync_merge_test.go`\n\n### Testing\nAll tests pass including 4 new tests:\n- `TestDBNeedsExport_InSync` - Verifies no export when synced\n- `TestDBNeedsExport_DBNewer` - Detects DB modifications\n- `TestDBNeedsExport_CountMismatch` - Catches divergence\n- `TestDBNeedsExport_NoJSONL` - Handles missing JSONL\n\nThis prevents the weeks-long frustration of merge conflicts causing infinite dirty loops.","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-05T17:52:14.776063-08:00","updated_at":"2025-11-05T17:58:35.611942-08:00","closed_at":"2025-11-05T17:58:35.611942-08:00"}
 {"id":"bd-9btu","title":"Code smell: Duplicated step collection functions in cook.go","description":"attached_args: Fix duplicated step collection functions in cook.go\n\nTwo pairs of nearly identical functions exist in cook.go:\n\n1. collectStepsRecursive() (line 754) vs collectStepsToSubgraph() (line 415)\n   - Both iterate over steps and create issues\n   - Main difference: one writes to DB, one builds in-memory subgraph\n   \n2. collectDependencies() (line 833) vs collectDependenciesToSubgraph() (line 502)\n   - Both collect dependencies from steps\n   - Nearly identical logic\n\nConsider:\n1. Extract common step/dependency processing logic\n2. Use a strategy pattern or callback for the DB vs in-memory difference\n3. Create a single function that returns data, then have callers decide how to persist\n\nLocation: cmd/bd/cook.go:415-567 and cmd/bd/cook.go:754-898","status":"closed","priority":2,"issue_type":"chore","created_at":"2025-12-28T15:31:57.401447-08:00","created_by":"beads/crew/dave","updated_at":"2025-12-28T16:41:07.719801-08:00","closed_at":"2025-12-28T16:41:07.719801-08:00","dependencies":[{"issue_id":"bd-9btu","depends_on_id":"bd-784c","type":"parent-child","created_at":"2025-12-28T15:38:04.168908-08:00","created_by":"daemon"}]}
 {"id":"bd-9cdc","title":"Update docs for import bug fix","description":"Update AGENTS.md, README.md, TROUBLESHOOTING.md with import.orphan_handling config documentation. Document resurrection behavior, tombstones, config modes. Add troubleshooting section for import failures with deleted parents.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-04T12:32:30.770415-08:00","updated_at":"2025-12-21T21:14:08.328627-08:00","closed_at":"2025-12-21T21:14:08.328627-08:00"}