diff --git a/.beads/beads.jsonl b/.beads/beads.jsonl
index c70f6a61..0e24a2fe 100644
--- a/.beads/beads.jsonl
+++ b/.beads/beads.jsonl
@@ -1,3 +1,4 @@
+{"id":"bd-0vc","title":"Git history fallback could cause data loss on first import after fresh clone","description":"## Problem\n\nConsider this scenario:\n1. User creates issue locally, exports to JSONL, commits \u0026 pushes\n2. Another user does fresh clone\n3. That user runs `bd import` \n4. Issue is in their DB but not in their JSONL (normal for fresh import)\n5. Git history check finds the ID in history\n6. Issue gets DELETED from their DB\\!\n\nThe bug: git history will show the ID was added (in the push), but the current logic interprets \"found in history\" as \"was deleted\".\n\n## Root Cause\n\nThe git history check can't distinguish between:\n- ID appeared because it was ADDED then REMOVED (deletion)\n- ID appeared because it was ADDED and still exists (current)\n\n## Location\n`internal/importer/importer.go:891-915`\n\n## Impact\n- **Data loss** on fresh clones\n- Silently deletes valid issues\n- Self-healing backfill makes it worse (records false deletion)\n\n## Fix\n\nNeed to verify the ID was actually REMOVED, not just that it appeared:\n\nOption 1: Check if ID exists in HEAD version of JSONL\n```bash\ngit show HEAD:.beads/beads.jsonl | grep '\"id\":\"bd-xxx\"'\n```\nIf found in HEAD, it's NOT deleted - skip.\n\nOption 2: Count occurrences in -S output\nIf ID appears odd number of times, it's currently present.\nIf even number (add+remove), it was deleted.","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-11-25T12:53:08.95406-08:00","updated_at":"2025-11-25T12:54:14.843732-08:00","closed_at":"2025-11-25T12:54:14.843732-08:00"}
 {"id":"bd-13gm","title":"Add explicit cache validation tests for blocked_issues_cache","description":"Add explicit cache validation tests for blocked_issues_cache to verify it correctly identifies blocked issues under various scenarios.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-23T20:06:55.736412-08:00","updated_at":"2025-11-25T00:28:43.983358-08:00","closed_at":"2025-11-23T23:22:04.177645-08:00"}
 {"id":"bd-19er","title":"Create backup and restore procedures","description":"Disaster recovery procedures for Agent Mail data.\n\nAcceptance Criteria:\n- Automated daily snapshots (GCP persistent disk)\n- SQLite backup script\n- Git repository backup\n- Restore procedure documentation\n- Test restore from backup\n\nFile: deployment/agent-mail/backup.sh","status":"closed","priority":3,"issue_type":"task","created_at":"2025-11-07T22:43:43.417403-08:00","updated_at":"2025-11-24T00:01:27.553156-08:00","closed_at":"2025-11-23T23:39:00.061047-08:00","dependencies":[{"issue_id":"bd-19er","depends_on_id":"bd-z3s3","type":"blocks","created_at":"2025-11-07T23:04:28.122501-08:00","created_by":"daemon"}]}
 {"id":"bd-1a6j","title":"Test issue 2","description":"","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-07T19:07:12.24632-08:00","updated_at":"2025-11-24T00:01:27.553619-08:00","closed_at":"2025-11-23T23:35:04.068982-08:00"}
@@ -5,6 +6,7 @@
 {"id":"bd-1qwo","title":"Audit and enforce consistent error handling patterns across codebase","description":"**Background:** Error handling patterns are now documented in docs/ERROR_HANDLING.md (bd-9lwr). We have three established patterns:\n- Pattern A: Exit immediately (os.Exit) for fatal errors\n- Pattern B: Warn and continue for optional operations\n- Pattern C: Silent ignore for cleanup/best-effort\n\n**Goal:** Systematically review all error handling in cmd/bd to ensure each instance uses the appropriate pattern according to the guidelines.\n\n**Scope:** \n- Review all files in cmd/bd/*.go\n- Focus on files with high usage: create.go, init.go, sync.go, daemon_sync.go, export.go, import.go\n- Identify outliers where similar operations use different patterns\n- Refactor to use consistent patterns\n\n**Acceptance Criteria:**\n- Similar operations (e.g., all metadata updates) use the same pattern\n- Critical operations always use Pattern A\n- Auxiliary operations use Pattern B or C appropriately\n- No mixed patterns for identical operation types\n\n**References:**\n- docs/ERROR_HANDLING.md - Guidelines and decision tree\n- bd-9lwr - Documentation task\n- bd-bwk2 - Related storage layer error handling work","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-23T21:53:25.687087-08:00","updated_at":"2025-11-24T01:08:18.294375-08:00","closed_at":"2025-11-24T00:28:58.356196-08:00"}
 {"id":"bd-1rh","title":"cmd/bd test suite is absurdly slow - 279 tests taking 8+ minutes","description":"# Problem\n\nThe cmd/bd test suite is painfully slow:\n- **279 tests** in cmd/bd alone\n- Full suite takes **8+ minutes** to run\n- Even with the 16 slowest integration tests now tagged with `integration` build tag, the remaining tests still take forever\n\nThis makes the development loop unusable. We can't wait 8+ minutes every time we want to run tests.\n\n# Root Cause Analysis\n\n## 1. Sheer Volume\n279 tests is too many for a single package. Even at 0.1s per test, that's 28 seconds minimum just for cmd/bd.\n\n## 2. Each Test Creates Full Database + Temp Directories\nEvery test does heavy setup:\n- Creates temp directory (`t.TempDir()` or `os.MkdirTemp`)\n- Initializes SQLite database\n- Sets up git repo in many cases\n- Creates full storage layer\n\nExample from the tests:\n```go\nfunc setupCLITestDB(t *testing.T) string {\n    tmpDir := createTempDirWithCleanup(t)\n    runBDInProcess(t, tmpDir, \"init\", \"--prefix\", \"test\", \"--quiet\")\n    return tmpDir\n}\n```\n\nThis happens 279 times!\n\n## 3. Tests Are Not Properly Categorized\nWe have three types of tests mixed together:\n- **Unit tests** - should be fast, test single functions\n- **Integration tests** - test full workflows, need DB/git\n- **End-to-end tests** - test entire CLI commands\n\nThey're all lumped together in cmd/bd, all running every time.\n\n# What We've Already Fixed\n\nAdded `integration` build tags to 16 obviously-slow test files:\n- import_profile_test.go (performance benchmarking tests)\n- export_mtime_test.go (tests with time.Sleep calls)\n- cli_fast_test.go (full CLI integration tests)\n- delete_test.go, import_uncommitted_test.go, sync_local_only_test.go (git integration)\n- And 10 more in internal/ packages\n\nThese are now excluded from the default `go test ./...` run.\n\n# Proposed Solutions\n\n## Option 1: Shared Test Fixtures (Quick Win)\nCreate a shared test database that multiple tests can use:\n```go\nvar testDB *sqlite.SQLiteStorage\nvar testDBOnce sync.Once\n\nfunc getSharedTestDB(t *testing.T) storage.Storage {\n    testDBOnce.Do(func() {\n        // Create one DB for all tests\n    })\n    return testDB\n}\n```\n\n**Pros**: Easy to implement, immediate speedup\n**Cons**: Tests become less isolated, harder to debug failures\n\n## Option 2: Table-Driven Tests (Medium Win)\nCollapse similar tests into table-driven tests:\n```go\nfunc TestCreate(t *testing.T) {\n    tests := []struct{\n        name string\n        args []string\n        want string\n    }{\n        {\"basic issue\", []string{\"create\", \"Test\"}, \"created\"},\n        {\"with description\", []string{\"create\", \"Test\", \"-d\", \"desc\"}, \"created\"},\n        // ... 50 more cases\n    }\n    \n    db := setupOnce(t) // Setup once, not 50 times\n    for _, tt := range tests {\n        t.Run(tt.name, func(t *testing.T) {\n            // test using shared db\n        })\n    }\n}\n```\n\n**Pros**: Dramatically reduces setup overhead, tests run in parallel\n**Cons**: Requires refactoring, tests share more state\n\n## Option 3: Split cmd/bd Tests Into Packages (Big Win)\nMove tests into focused packages:\n- `cmd/bd/internal/clitests` - CLI integration tests (mark with integration tag)\n- `cmd/bd/internal/unittests` - Fast unit tests\n- Keep only essential tests in cmd/bd\n\n**Pros**: Clean separation, easy to run just fast tests\n**Cons**: Requires significant refactoring\n\n## Option 4: Parallel Execution (Quick Win)\nAdd `t.Parallel()` to independent tests:\n```go\nfunc TestSomething(t *testing.T) {\n    t.Parallel() // Run this test concurrently with others\n    // ...\n}\n```\n\n**Pros**: Easy to add, can cut time in half on multi-core machines\n**Cons**: Doesn't reduce actual test work, just parallelizes it\n\n## Option 5: In-Memory Databases (Medium Win)\nUse `:memory:` SQLite databases instead of file-based:\n```go\nstore, err := sqlite.New(ctx, \":memory:\")\n```\n\n**Pros**: Faster than disk I/O, easier cleanup\n**Cons**: Some tests need actual file-based DBs (export/import tests)\n\n# Recommended Approach\n\n**Short-term (this week)**:\n1. Add `t.Parallel()` to all independent tests in cmd/bd\n2. Use `:memory:` databases where possible\n3. Create table-driven tests for similar test cases\n\n**Medium-term (next sprint)**:\n4. Split cmd/bd tests into focused packages\n5. Mark more integration tests appropriately\n\n**Long-term (backlog)**:\n6. Consider shared test fixtures with proper isolation\n\n# Current Status\n\nWe've tagged 16 files with `integration` build tag, but the remaining 279 tests in cmd/bd still take 8+ minutes. This issue tracks fixing the cmd/bd test performance specifically.\n\n# Target\n\nGet `go test ./...` (without `-short` or `-tags=integration`) down to **under 30 seconds**.\n\n\n# THE REAL ROOT CAUSE (Updated Analysis)\n\nAfter examining the actual test code, the problem is clear:\n\n## Every Test Creates Its Own Database From Scratch\n\nLook at `create_test.go`:\n```go\nfunc TestCreate_BasicIssue(t *testing.T) {\n    tmpDir := t.TempDir()                          // ← Creates temp dir\n    testDB := filepath.Join(tmpDir, \".beads\", \"beads.db\")\n    s := newTestStore(t, testDB)                   // ← Opens NEW SQLite connection\n                                                    // ← Runs migrations\n                                                    // ← Sets config\n    // ... actual test (3 lines)\n}\n\nfunc TestCreate_WithDescription(t *testing.T) {\n    tmpDir := t.TempDir()                          // ← Creates ANOTHER temp dir\n    testDB := filepath.Join(tmpDir, \".beads\", \"beads.db\")\n    s := newTestStore(t, testDB)                   // ← Opens ANOTHER SQLite connection\n    // ... actual test (3 lines)\n}\n```\n\n**This happens 279 times!**\n\n## These Tests Don't Need Isolation!\n\nMost tests are just checking:\n- \"Can I create an issue with a title?\"\n- \"Can I create an issue with a description?\"\n- \"Can I add labels?\"\n\nThey don't conflict with each other. They could all share ONE database!\n\n## The Fix: Test Suites with Shared Setup\n\nInstead of:\n```go\nfunc TestCreate_BasicIssue(t *testing.T) {\n    s := newTestStore(t, t.TempDir()+\"/db\")  // ← Expensive!\n    // test\n}\n\nfunc TestCreate_WithDesc(t *testing.T) {\n    s := newTestStore(t, t.TempDir()+\"/db\")  // ← Expensive!\n    // test\n}\n```\n\nDo this:\n```go\nfunc TestCreate(t *testing.T) {\n    // ONE setup for all subtests\n    s := newTestStore(t, t.TempDir()+\"/db\")\n    \n    t.Run(\"basic_issue\", func(t *testing.T) {\n        t.Parallel()  // Can run concurrently - tests don't conflict\n        // test using shared `s`\n    })\n    \n    t.Run(\"with_description\", func(t *testing.T) {\n        t.Parallel()\n        // test using shared `s`\n    })\n    \n    // ... 50 more subtests, all using same DB\n}\n```\n\n**Result**: 50 tests → 1 database setup instead of 50!\n\n## Why This Works\n\nSQLite is fine with concurrent reads and isolated transactions. These tests:\n- ✅ Create different issues (no ID conflicts)\n- ✅ Just read back what they created\n- ✅ Don't depend on database state from other tests\n\nThey SHOULD share a database!\n\n## Real Numbers\n\nCurrent:\n- 279 tests × (create dir + init SQLite + migrations) = **8 minutes**\n\nAfter fix:\n- 10 test suites × (create dir + init SQLite + migrations) = **30 seconds**\n- 279 subtests running in parallel using those 10 DBs = **5 seconds**\n\n**Total: ~35 seconds instead of 8 minutes!**\n\n## Implementation Plan\n\n1. **Group related tests** into suites (Create, List, Update, Delete, etc.)\n2. **One setup per suite** instead of per test\n3. **Use t.Run() for subtests** with t.Parallel()\n4. **Keep tests that actually need isolation** separate (export/import tests, git operations)\n\nThis is way better than shuffling tests into folders!","notes":"## Progress Update (2025-11-21)\n\n✅ **Completed**:\n- Audited all 280 tests, created TEST_SUITE_AUDIT.md ([deleted:bd-c49])\n- Refactored create_test.go to shared DB pattern ([deleted:bd-y6d])\n- Proven the pattern works: 11 tests now run in 0.04s with 1 DB instead of 11\n\n❌ **Current Reality**:\n- Overall test suite: Still 8+ minutes (no meaningful change)\n- Only 1 of 76 test files refactored\n- Saved ~10 DB initializations out of 280\n\n## Acceptance Criteria (REALISTIC)\n\nThis task is NOT complete until:\n- [ ] All P1 files refactored (create ✅, dep, stale, comments, list, ready)\n- [ ] Test suite runs in \u003c 2 minutes\n- [ ] Measured and verified actual speedup\n\n## Next Steps\n\n1. Refactor remaining 5 P1 files: dep_test.go, stale_test.go, comments_test.go, list_test.go, ready_test.go\n2. Measure actual time improvement after each file\n3. Continue with P2 files if needed to hit \u003c2min target","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-11-21T11:37:47.886207-05:00","updated_at":"2025-11-24T00:01:27.554109-08:00","closed_at":"2025-11-23T23:38:54.185364-08:00"}
 {"id":"bd-1w6i","title":"Document blocked_issues_cache architecture and behavior","description":"Add comprehensive documentation about the blocked_issues_cache optimization to help future maintainers understand the design.\n\n## What to document\n\n1. **Architecture overview**\n   - Why cache exists (performance: 752ms -\u003e 29ms)\n   - When cache is used (GetReadyWork queries)\n   - How cache is maintained (invalidation triggers)\n\n2. **Cache invalidation rules**\n   - Invalidated on: dependency add/remove (blocks/parent-child only)\n   - Invalidated on: any status change\n   - Invalidated on: issue close\n   - NOT invalidated on: related/discovered-from dependencies\n\n3. **Transaction safety**\n   - All invalidations happen within transactions\n   - Cache can use tx or direct db connection\n   - Rebuild is atomic (DELETE + INSERT in same tx)\n\n4. **Performance characteristics**\n   - Full rebuild on every invalidation\n   - Rebuild is fast (\u003c50ms on 10K database)\n   - Write complexity traded for read speed\n   - Dependency changes are rare vs reads\n\n5. **Edge cases**\n   - Parent-child transitive blocking\n   - Closed issues don't block\n   - Foreign key CASCADE handles deletions\n\n## Where to document\n\nAdd to these locations:\n\n1. **blocked_cache.go** - Add detailed package comment:\n```go\n// Package blocked_cache implements the blocked_issues_cache optimization.\n// \n// Performance: GetReadyWork originally used recursive CTE (752ms on 10K db).\n// With cache: Simple NOT EXISTS query (29ms on 10K db).\n//\n// Cache Maintenance:\n// - Rebuild triggered on dependency changes (blocks/parent-child only)\n// - Rebuild triggered on status changes  \n// - Full rebuild (DELETE + INSERT) is fast enough for all cases\n// ...\n```\n\n2. **ARCHITECTURE.md** or **PERFORMANCE.md** (new file) - High-level overview\n\n3. **ready.go** - Update comment at line 84-85 with more detail\n\n## Related\n\n- [deleted:[deleted:[deleted:[deleted:[deleted:[deleted:bd-5qim]]]]]]: GetReadyWork optimization (implemented)\n- bd-13gm: Cache validation tests\n- [deleted:[deleted:[deleted:[deleted:bd-obdc]]]]: Cache rebuild command","status":"closed","priority":3,"issue_type":"task","created_at":"2025-11-23T20:07:23.467296-08:00","updated_at":"2025-11-25T09:10:06.179923-08:00","closed_at":"2025-11-24T01:40:45.872263-08:00"}
+{"id":"bd-296","title":"Compact deletions pruning runs even on --dry-run","description":"## Problem\n\n`pruneDeletionsManifest()` is called unconditionally at the end of compact operations, even when `--dry-run` is specified. This means a dry-run can still modify the deletions.jsonl file.\n\n## Location\n- `cmd/bd/compact.go:302` (runCompactSingle)  \n- `cmd/bd/compact.go:429` (runCompactAll)\n- `cmd/bd/compact.go:887` (runCompactApply)\n\n## Impact\n- Dry-run is not truly dry - it modifies files\n- User loses old deletion records unexpectedly\n- Violates principle of least surprise\n\n## Fix\nCheck `compactDryRun` before calling `pruneDeletionsManifest()`:\n\n```go\nif !compactDryRun {\n    pruneDeletionsManifest()\n}\n```","status":"closed","priority":2,"issue_type":"bug","created_at":"2025-11-25T12:51:37.723827-08:00","updated_at":"2025-11-25T12:52:54.318721-08:00","closed_at":"2025-11-25T12:52:54.318721-08:00"}
 {"id":"bd-2bl","title":"Add DeletionRecord type and deletions.jsonl file handling","description":"Parent: bd-imj\n\n## Task\nCreate the core data structures and file I/O for the deletions manifest.\n\n## Implementation\n\n### DeletionRecord struct\n```go\ntype DeletionRecord struct {\n    ID        string    `json:\"id\"`\n    Timestamp time.Time `json:\"ts\"`\n    Actor     string    `json:\"by\"`\n    Reason    string    `json:\"reason,omitempty\"`\n}\n```\n\n### File operations\n- `LoadDeletions(path string) (map[string]DeletionRecord, error)` - load into map for O(1) lookup\n- `AppendDeletion(path string, record DeletionRecord) error` - append single record\n- `WriteDeletions(path string, records []DeletionRecord) error` - atomic rewrite for compaction\n\n### Corrupt file recovery\n`LoadDeletions` should:\n- Skip invalid JSON lines with a warning log\n- Return successfully loaded entries\n- Not fail on partial corruption\n- Optionally return count of skipped lines for diagnostics\n\n```go\nfunc LoadDeletions(path string) (map[string]DeletionRecord, int, error) {\n    // returns: records, skippedCount, error\n}\n```\n\n### Location\n- New file: `internal/deletions/deletions.go`\n- Path: `.beads/deletions.jsonl`\n\n## Acceptance Criteria\n- [ ] DeletionRecord type with JSON tags\n- [ ] Load/append/write functions with proper error handling\n- [ ] Atomic write (temp file + rename) for compaction safety\n- [ ] Corrupt lines skipped with warning (not fatal)\n- [ ] Unit tests for round-trip serialization\n- [ ] Unit tests for corrupt line handling","status":"closed","priority":0,"issue_type":"task","created_at":"2025-11-25T09:56:24.634947-08:00","updated_at":"2025-11-25T10:59:00.126123-08:00","closed_at":"2025-11-25T10:59:00.126123-08:00"}
 {"id":"bd-379","title":"Implement `bd setup cursor` for Cursor IDE integration","description":"Create a `bd setup cursor` command that integrates Beads workflow into Cursor IDE via .cursorrules file. Unlike Claude Code (which has hooks), Cursor uses a static rules file to provide context to its AI.","status":"closed","priority":3,"issue_type":"feature","created_at":"2025-11-11T23:32:22.170083-08:00","updated_at":"2025-11-25T09:10:06.181261-08:00","closed_at":"2025-11-24T01:39:26.852836-08:00"}
 {"id":"bd-3852","title":"Add orphan detection migration","description":"Create migration to detect orphaned children in existing databases. Query: SELECT id FROM issues WHERE id LIKE '%.%' AND substr(id, 1, instr(id || '.', '.') - 1) NOT IN (SELECT id FROM issues). Log results, let user decide action (delete orphans or convert to top-level).","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-04T12:32:30.727044-08:00","updated_at":"2025-11-24T01:08:18.295118-08:00","closed_at":"2025-11-24T00:31:16.479343-08:00"}
@@ -32,7 +34,9 @@
 {"id":"bd-b0c8","title":"Research hooks/skills approach for enforcing issue descriptions","description":"## Solution: Hooks/Skills (mentioned in discussion)\n\nResearch the hooks/skills system mentioned by riordanpawley in discussion #366:\nhttps://www.reddit.com/r/ClaudeAI/s/wrn2tjkMHX\n\n## Investigation Tasks\n\n1. Review the Reddit post to understand the approach\n2. Determine if beads hooks can enforce validation\n3. Check if Claude Code skills/hooks can intercept MCP calls\n4. Assess feasibility and user burden\n\n## Notes\n\nFrom discussion #366:\n\u003e I'm using a skills/hooks system to get Claude to do that kind of thing right similar to https://www.reddit.com/r/ClaudeAI/s/wrn2tjkMHX\n\nThis might be a client-side solution rather than server-side.\n\n## Deliverable\n\nDocument findings in issue notes, with recommendation on whether to pursue this approach.","status":"closed","priority":3,"issue_type":"task","created_at":"2025-11-23T14:01:01.57079-08:00","updated_at":"2025-11-24T01:25:22.237007-08:00","closed_at":"2025-11-24T01:15:03.961995-08:00"}
 {"id":"bd-b2c","title":"Clarify metadata handling in init.go (config vs tracking)","description":"Review init.go:207-228 to ensure configuration metadata (issue_prefix, sync.branch) uses Pattern A consistently, while tracking metadata (bd_version, repo_id, etc.) uses Pattern B. Add comments explaining the distinction.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-24T00:28:53.199481-08:00","updated_at":"2025-11-24T00:33:24.654007-08:00","closed_at":"2025-11-24T00:33:24.654007-08:00","dependencies":[{"issue_id":"bd-b2c","depends_on_id":"bd-1qwo","type":"blocks","created_at":"2025-11-24T00:28:53.200299-08:00","created_by":"daemon"}]}
 {"id":"bd-b55e2ac2","title":"Fix autoimport tests for content-hash collision scoring","description":"## Overview\nThree autoimport tests are failing after bd-cbed9619.4 because they expect behavior based on the old reference-counting collision resolution, but the system now uses deterministic content-hash scoring.\n\n## Failing Tests\n1. `TestAutoImportMultipleCollisionsRemapped` - expects local versions preserved\n2. `TestAutoImportAllCollisionsRemapped` - expects local versions preserved  \n3. `TestAutoImportCollisionRemapMultipleFields` - expects specific collision resolution behavior\n\n## Root Cause\nThese tests were written when ScoreCollisions used reference counting to determine which version to keep. Now it uses content-hash comparison (introduced in commit 2e87329), which produces different but deterministic results.\n\n## Example\nOld behavior: Issue with more references would be kept\nNew behavior: Issue with lexicographically lower content hash is kept\n\n## Solution\nUpdate each test to:\n1. Verify the new content-hash based behavior is correct\n2. Check that the remapped issue (not necessarily local/remote) has the expected content\n3. Ensure dependencies are preserved on the correct remapped issue\n\n## Acceptance Criteria\n- All three autoimport tests pass\n- Tests verify content-hash determinism (same collision always resolves the same way)\n- Tests check dependency preservation on remapped issues\n- Test documentation explains content-hash scoring expectations\n\n## Files to Modify\n- `cmd/bd/autoimport_collision_test.go`\n\n## Testing\nRun: `go test ./cmd/bd -run \"TestAutoImport.*Collision\" -v`","status":"closed","priority":2,"issue_type":"task","created_at":"2025-10-28T19:17:28.358028-07:00","updated_at":"2025-11-24T00:01:27.558153-08:00","closed_at":"2025-11-23T23:20:43.995595-08:00"}
+{"id":"bd-bgs","title":"Git history fallback doesn't escape regex special chars in IDs","description":"## Problem\n\nIn `batchCheckGitHistory`, IDs are directly interpolated into a regex pattern:\n\n```go\npatterns = append(patterns, fmt.Sprintf(\\`\"id\":\"%s\"\\`, id))\nsearchPattern := strings.Join(patterns, \"|\")\ncmd := exec.Command(\"git\", \"log\", \"--all\", \"-G\", searchPattern, ...)\n```\n\nIf an ID contains regex special characters (e.g., `bd-foo.bar` or `bd-test+1`), the pattern will be malformed or match unintended strings.\n\n## Location\n`internal/importer/importer.go:923-926`\n\n## Impact\n- False positives: IDs with `.` could match any character\n- Regex errors: IDs with `[` or `(` could cause git to fail\n- Security: potential for regex injection (low risk since IDs are validated)\n\n## Fix\nEscape regex special characters:\n\n```go\nimport \"regexp\"\n\nescapedID := regexp.QuoteMeta(id)\npatterns = append(patterns, fmt.Sprintf(\\`\"id\":\"%s\"\\`, escapedID))\n```","status":"open","priority":2,"issue_type":"bug","created_at":"2025-11-25T12:50:30.132232-08:00","updated_at":"2025-11-25T12:50:30.132232-08:00"}
 {"id":"bd-bh1","title":"Rewrite ARCHITECTURE.md with proper data model overview","description":"Issue #376 feedback: Current ARCHITECTURE.md is misleading - it's about FlushManager and Blocked Cache internals, not overall architecture.\n\nNeeded:\n1. Rename current ARCHITECTURE.md to INTERNALS.md or FLUSH_ARCHITECTURE.md\n2. Write new ARCHITECTURE.md covering:\n   - Git ↔ JSONL ↔ SQLite data model (the 'magic')\n   - Write path: CLI → SQLite → JSONL export → git commit\n   - Read path: git pull → JSONL import → SQLite → CLI\n   - Hash-based collision prevention\n   - Daemon architecture overview\n3. Add TROUBLESHOOTING.md or section with recovery procedures:\n   - Merge conflicts in JSONL\n   - Locked database\n   - Worktree sync issues\n   - Multiple databases created\n\nReference: CLAUDE.md already has decent 'Three-Layer Design' and 'Distributed Database Pattern' sections to build from.\n\nGitHub issue: #376","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-25T11:30:52.57061-08:00","updated_at":"2025-11-25T11:35:07.125512-08:00","closed_at":"2025-11-25T11:35:07.125512-08:00"}
+{"id":"bd-bhd","title":"Git history fallback assumes .beads is direct child of repo root","description":"## Problem\n\n`checkGitHistoryForDeletions` assumes the repo structure:\n\n```go\nrepoRoot := filepath.Dir(beadsDir)  // Assumes .beads is in repo root\njsonlPath := filepath.Join(\".beads\", \"beads.jsonl\")\n```\n\nBut `.beads` could be in a subdirectory (monorepo, nested project), and the actual JSONL filename could be different (configured via `metadata.json`).\n\n## Location\n`internal/importer/importer.go:865-869`\n\n## Impact\n- Git search will fail silently for repos with non-standard structure\n- Monorepo users won't get deletion propagation\n\n## Fix\n1. Use `git rev-parse --show-toplevel` to find actual repo root\n2. Compute relative path from repo root to JSONL\n3. Or use `git -C \u003cdir\u003e` to run from beadsDir directly","status":"open","priority":2,"issue_type":"bug","created_at":"2025-11-25T12:51:03.46856-08:00","updated_at":"2025-11-25T12:51:03.46856-08:00"}
 {"id":"bd-bt6y","title":"Improve compact/daemon/merge documentation and UX","description":"Multiple documentation and UX issues encountered:\n1. \"bd compact --analyze\" fails with misleading \"requires SQLite storage\" error when daemon is running. Needs --no-daemon or better error.\n2. \"bd merge\" help text is outdated (refers to 3-way merge instead of issue merging).\n3. Daemon mode purpose isn't clear to local-only users.\n4. Compact/cleanup commands are hard to discover.\n\nProposed fixes:\n- Fix compact+daemon interaction or error message.\n- Update \"bd merge\" help text.\n- Add \"when to use daemon\" section to docs.\n- Add maintenance section to quickstart.\n","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-20T18:55:43.637047-05:00","updated_at":"2025-11-20T18:55:43.637047-05:00"}
 {"id":"bd-bwk2","title":"Centralize error handling patterns in storage layer","description":"80+ instances of inconsistent error handling across sqlite.go with mix of %w, %v, and no wrapping.\n\nLocation: internal/storage/sqlite/sqlite.go (throughout)\n\nProblem:\n- Some use fmt.Errorf(\"op failed: %w\", err) - correct wrapping\n- Some use fmt.Errorf(\"op failed: %v\", err) - loses error chain\n- Some return err directly - no context\n- Hard to debug production issues\n- Can't distinguish error types\n\nSolution: Create internal/storage/sqlite/errors.go:\n- Define sentinel errors (ErrNotFound, ErrInvalidID, etc.)\n- Create wrapDBError(op string, err error) helper\n- Convert sql.ErrNoRows to ErrNotFound\n- Always wrap with operation context\n\nImpact: Lost error context; inconsistent messages; hard to debug\n\nEffort: 5-7 hours","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-16T14:51:54.974909-08:00","updated_at":"2025-11-24T01:08:18.298536-08:00","closed_at":"2025-11-24T00:57:47.359519-08:00","dependencies":[{"issue_id":"bd-bwk2","depends_on_id":"bd-vfe","type":"blocks","created_at":"2025-11-24T00:53:28.831021-08:00","created_by":"daemon"},{"issue_id":"bd-bwk2","depends_on_id":"bd-z8z","type":"blocks","created_at":"2025-11-24T00:53:28.897593-08:00","created_by":"daemon"},{"issue_id":"bd-bwk2","depends_on_id":"bd-w8h","type":"blocks","created_at":"2025-11-24T00:53:28.957487-08:00","created_by":"daemon"},{"issue_id":"bd-bwk2","depends_on_id":"bd-r71","type":"blocks","created_at":"2025-11-24T00:53:29.023262-08:00","created_by":"daemon"}]}
 {"id":"bd-c362","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 [deleted:bd-e16b] implementation.","status":"open","priority":3,"issue_type":"chore","created_at":"2025-11-02T18:34:02.831543-08:00","updated_at":"2025-11-23T22:38:46.782725-08:00"}
@@ -41,6 +45,7 @@
 {"id":"bd-e1085716","title":"bd validate - Comprehensive health check","description":"Run all validation checks in one command.\n\nChecks:\n- Duplicates\n- Orphaned dependencies\n- Test pollution\n- Git conflicts\n\nSupports --fix-all for auto-repair.\n\nDepends on bd-cbed9619.1, bd-0dcea000, bd-31aab707, bd-9826b69a.\n\nFiles: cmd/bd/validate.go (new)","status":"closed","priority":1,"issue_type":"task","created_at":"2025-10-29T23:05:13.980679-07:00","updated_at":"2025-11-24T00:01:27.558631-08:00","closed_at":"2025-11-23T23:20:39.694984-08:00"}
 {"id":"bd-e166","title":"Improve timestamp comparison readability in import","description":"The timestamp comparison logic uses double-negative which can be confusing:\n\nCurrent code:\nif !incoming.UpdatedAt.After(existing.UpdatedAt) {\n    // skip update\n}\n\nMore readable:\nif incoming.UpdatedAt.After(existing.UpdatedAt) {\n    // perform update\n} else {\n    // skip (local is newer)\n}\n\nThis is a minor refactor for code clarity.\n\nRelated: bd-1022\nFiles: internal/importer/importer.go:411, 488","status":"open","priority":4,"issue_type":"chore","created_at":"2025-11-02T15:32:12.27108-08:00","updated_at":"2025-11-02T15:32:12.27108-08:00"}
 {"id":"bd-e92","title":"Add test coverage for internal/autoimport package","description":"","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-20T21:21:22.338577-05:00","updated_at":"2025-11-20T21:21:22.338577-05: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-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":"open","priority":2,"issue_type":"bug","created_at":"2025-11-25T12:48:24.388639-08:00","updated_at":"2025-11-25T12:48:24.388639-08:00"}
 {"id":"bd-g9eu","title":"Investigate TestRoutingIntegration failure","description":"TestRoutingIntegration/maintainer_with_SSH_remote failed during pre-commit check with \"expected role maintainer, got contributor\".\nThis occurred while running `go test -short ./...` on darwin/arm64.\nThe failure appears unrelated to storage/sqlite changes.\nNeed to investigate if this is a flaky test or environmental issue.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-20T15:55:19.337094-08:00","updated_at":"2025-11-24T00:01:27.559057-08:00","closed_at":"2025-11-23T23:38:55.477369-08:00"}
 {"id":"bd-ge7","title":"Improve Beads test coverage from 46% to 80%","description":"","status":"open","priority":1,"issue_type":"epic","created_at":"2025-11-20T21:21:03.700271-05:00","updated_at":"2025-11-20T21:21:03.700271-05:00"}
 {"id":"bd-gfu","title":"Add --start flag to bd daemon, show help with no args","description":"Currently `bd daemon` with no args immediately starts the daemon. This is inconsistent with other daemon management commands like `--stop`, `--status`, etc.\n\n## Proposed Changes\n\n1. Add `--start` flag to explicitly start daemon\n2. With no args or flags, print help text showing available options\n3. Maintain backward compatibility where feasible\n\n## Current Consumers\n\n- **Auto-start logic** (`daemon_autostart.go:106, 270`): Calls `bd daemon` programmatically - needs update\n- **MCP docs** (SETUP_DAEMON.md:111): Already incorrectly shows `bd daemon start` - will be fixed by this change\n- **Python daemon client**: Suggests `bd daemon` in error messages - needs doc update\n\n## Implementation Notes\n\n- Default behavior (no args/flags) should show help\n- `--start` should start daemon (current no-args behavior)\n- Auto-start code needs to pass `--start` flag explicitly\n- Update all documentation to use `bd daemon --start`\n- Ensure backward compat doesn't break existing workflows","status":"closed","priority":2,"issue_type":"feature","created_at":"2025-11-23T23:54:49.906553-08:00","updated_at":"2025-11-24T00:03:15.231345-08:00","closed_at":"2025-11-24T00:03:15.231345-08:00"}
@@ -54,6 +59,7 @@
 {"id":"bd-ktng","title":"Optimize CLI test suite - eliminate redundant git init calls","description":"Current: Each of 13 CLI tests calls git init (31s total). Solution: Use single test binary built once in init(), skip git operations where possible, or use mock filesystem.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-04T11:23:13.660276-08:00","updated_at":"2025-11-23T23:01:49.003046-08:00","closed_at":"2025-11-23T22:55:32.103839-08:00","comments":[{"id":1,"issue_id":"bd-ktng","author":"stevey","text":"Completed first phase: refactored sync_test.go to use helper functions.\n\nChanges:\n- Added 3 helper functions: setupGitRepo(), setupGitRepoWithBranch(), setupMinimalGitRepo()\n- Refactored 19 test functions in sync_test.go\n- Eliminated ~300 lines of duplicate git initialization boilerplate\n- All tests pass\n\nThe helpers consolidate the repeated pattern of:\n1. Creating temp directory\n2. Initializing git repo\n3. Configuring git user\n4. Creating initial commit\n5. Handling cleanup\n\nNext steps:\n- Apply similar optimization to other test files (daemon_test.go, hooks_test.go, etc.)\n- Measure actual performance improvement","created_at":"2025-11-25T17:10:06Z"}]}
 {"id":"bd-kzo","title":"End-to-end test: deletion propagation across clones","description":"Parent: bd-imj\n\n## Task\nCreate integration test verifying deletions propagate correctly between clones.\n\n## Test Scenario\n1. Create two \"clones\" (separate .beads directories)\n2. Clone A: create issue bd-xxx\n3. Sync both clones (both have bd-xxx)\n4. Clone A: delete bd-xxx\n5. Sync Clone A (deletions.jsonl updated)\n6. Sync Clone B (should pull deletions.jsonl)\n7. Clone B: import should purge bd-xxx from DB\n\n## Edge Cases to Test\n- Simultaneous deletion in both clones (should be idempotent)\n- Deletion of non-existent issue (no-op, still recorded)\n- Corrupt deletions.jsonl line (skipped with warning)\n- Empty/missing deletions.jsonl (graceful handling)\n\n## Acceptance Criteria\n- [ ] Test creates isolated clone environments\n- [ ] Verifies deletion propagates via manifest\n- [ ] Verifies duplicate deletions are handled\n- [ ] Verifies corrupt line recovery\n- [ ] Can run in CI (no real git remotes needed)","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-25T10:50:57.436227-08:00","updated_at":"2025-11-25T12:03:08.790655-08:00","closed_at":"2025-11-25T12:03:08.790655-08:00"}
 {"id":"bd-l0r","title":"CRITICAL: bd sync pushes stale DB state instead of trusting JSONL truth on pull","description":"When a clone has stale DB (688 issues) and pulls fresh JSONL (62 issues), bd sync detects 1009.7% divergence but proceeds to re-export the stale DB and push it, overwriting the correct JSONL state. \n\nRepro:\n1. Clone has 688 issues in DB (628 closed)\n2. git pull brings JSONL with 62 issues (cleanup applied)\n3. bd sync warns about divergence but exports DB→JSONL\n4. Pushes 688 issues back to remote, undoing cleanup\n\nExpected: JSONL is source of truth after pull. DB should be wiped and reimported.\nActual: DB overwrites JSONL, pushing stale state upstream.\n\nImpact: Breaks multi-clone coordination. Cleanup work gets undone.","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-23T22:29:37.668882-08:00","updated_at":"2025-11-25T09:10:06.18172-08:00","closed_at":"2025-11-24T01:45:33.004694-08:00"}
+{"id":"bd-l7u","title":"Duplicate DefaultRetentionDays constants","description":"## Problem\n\nThere are now two constants for the same value:\n\n1. `deletions.DefaultRetentionDays = 7` in `internal/deletions/deletions.go:184`\n2. `configfile.DefaultDeletionsRetentionDays = 7` in `internal/configfile/configfile.go:102`\n\n## Impact\n- DRY violation\n- Risk of values getting out of sync\n- Confusing which one to use\n\n## Fix\nRemove the constant from `deletions` package and have it import from `configfile`, or create a shared constants package.","status":"open","priority":3,"issue_type":"task","created_at":"2025-11-25T12:49:38.356211-08:00","updated_at":"2025-11-25T12:49:38.356211-08:00"}
 {"id":"bd-l954","title":"Performance Testing Framework","description":"Add comprehensive performance testing for beads focusing on optimization guidance and validating 10K+ database scale. Uses standard Go tooling, follows existing patterns, minimal complexity.\n\nComponents:\n- Benchmark suite for critical operations at 10K-20K scale\n- Fixture generator for realistic test data (epic hierarchies, cross-links)\n- User diagnostics via bd doctor --perf\n- Always-on profiling integration\n\nGoals:\n- Identify bottlenecks for optimization work\n- Validate performance at 10K+ issue scale\n- Enable users to collect diagnostics for bug reports\n- Support both SQLite and JSONL import paths","status":"open","priority":2,"issue_type":"epic","created_at":"2025-11-13T22:22:11.203467-08:00","updated_at":"2025-11-13T22:22:11.203467-08:00"}
 {"id":"bd-m0w","title":"Add test coverage for internal/validation package","description":"","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-20T21:21:24.129559-05:00","updated_at":"2025-11-20T21:21:24.129559-05:00","dependencies":[{"issue_id":"bd-m0w","depends_on_id":"bd-ge7","type":"blocks","created_at":"2025-11-20T21:21:31.350477-05:00","created_by":"daemon"}]}
 {"id":"bd-m7ge","title":"Add .beads/README.md during 'bd init' for project documentation and promotion","description":"When 'bd init' is run, automatically generate a .beads/README.md file that:\n\n1. Briefly explains what Beads is (AI-native issue tracking that lives in your repo)\n2. Links to the main repository: https://github.com/steveyegge/beads\n3. Provides a quick reference of essential commands:\n   - bd create: Create new issues\n   - bd list: View all issues\n   - bd update: Modify issue status/details\n   - bd show: View issue details\n   - bd sync: Sync with git remote\n4. Highlights key benefits for AI coding agents and developers\n5. Encourages developers to try it out\n\nThe README should be enthusiastic and compelling to get open source contributors excited about using Beads for their AI-assisted development workflows.","status":"open","priority":2,"issue_type":"feature","created_at":"2025-11-16T22:32:50.478681-08:00","updated_at":"2025-11-16T22:32:58.492868-08:00"}
@@ -73,11 +79,14 @@
 {"id":"bd-t4u1","title":"False positive detection by Kaspersky Antivirus (Trojan)","description":"Kaspersky Antivirus falsely detects beads (bd.exe v0.23.1) as a Trojan (PDM:Trojan.Win32.Generic) and removes it.\nEvent: Malicious object detected\nComponent: System Watcher\nObject name: bd.exe\n","notes":"## Completed Actions\n\n1. **Root cause analysis**: Documented that this is a known false positive with Go binaries\n2. **Created comprehensive user documentation**: docs/ANTIVIRUS.md with:\n   - Explanation of why Go binaries trigger false positives\n   - Instructions for adding exclusions (Kaspersky, Windows Defender, etc.)\n   - File integrity verification steps\n   - False positive reporting procedures\n   - FAQ section\n3. **Updated TROUBLESHOOTING.md**: Added quick reference section with link to detailed guide\n\n## Next Steps (Follow-up Issues)\n\nThe following actions require external processes or future releases:\n\n1. **Submit false positive to Kaspersky**: Need to access bd.exe v0.23.1 Windows binary and submit to https://opentip.kaspersky.com/\n2. **Code signing for Windows**: Requires purchasing certificate and configuring GoReleaser (medium-term)\n3. **Apply for Kaspersky whitelist**: Long-term relationship building with vendor\n\n## Current Status\n\nUsers affected by this issue now have:\n- Clear documentation explaining the false positive\n- Step-by-step instructions to work around it\n- Ways to verify file integrity\n- Process to report to their antivirus vendor\n\nBuild configuration already includes recommended optimizations (-s -w flags).","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-20T18:56:12.498187-05:00","updated_at":"2025-11-24T01:17:35.4543-08:00","closed_at":"2025-11-24T01:03:39.166915-08:00"}
 {"id":"bd-tne","title":"Add Claude setup tip with dynamic priority","description":"Add a predefined tip that suggests running `bd setup claude` when Claude Code is detected but not configured. This tip should have higher priority (shown more frequently) until the setup is complete.","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-11T23:29:29.871324-08:00","updated_at":"2025-11-11T23:50:29.756454-08:00","dependencies":[{"issue_id":"bd-tne","depends_on_id":"bd-d4i","type":"blocks","created_at":"2025-11-11T23:29:29.872081-08:00","created_by":"daemon"}]}
 {"id":"bd-tru","title":"Update documentation for bd prime and Claude integration","description":"Update AGENTS.md, README.md, and QUICKSTART.md to document the new `bd prime` command, `bd setup claude` command, and tip system.","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-11T23:30:22.77349-08:00","updated_at":"2025-11-11T23:45:23.242658-08:00"}
+{"id":"bd-tys","title":"Git history fallback has incorrect logic for detecting deletions","description":"## Problem\n\nThe `wasInGitHistory` function in `internal/importer/importer.go:891` returns true if the ID is found **anywhere** in git history. But finding an ID in history doesn't necessarily mean it was deleted - it could mean:\n\n1. The issue was added (appears in a commit adding it)\n2. The issue was modified (appears in commits updating it)\n3. The issue was deleted (appears in a commit removing it)\n\nThe current logic incorrectly treats all three cases as 'deleted'.\n\n## Correct Logic\n\n`git log -S` with `--oneline` shows commits where the string was added OR removed. To detect deletion specifically:\n\n1. ID appears in git history (was once in JSONL)\n2. ID is NOT currently in JSONL\n\nThe second condition is already checked by the caller (`purgeDeletedIssues`), so technically the logic is correct in context. But the function name and doc comment are misleading.\n\n## Fix Options\n\n1. **Rename function** to `wasEverInJSONL` and update doc comment to clarify\n2. **Add explicit check** for current JSONL state in the function itself\n\nOption 1 is simpler and correct since caller already filters.","status":"open","priority":3,"issue_type":"bug","created_at":"2025-11-25T12:46:16.073661-08:00","updated_at":"2025-11-25T12:47:34.047651-08:00"}
 {"id":"bd-v0y","title":"Critical: bd sync overwrites git-pulled JSONL instead of importing it","description":"## Problem\n\nWhen a user runs `git pull` (which updates .beads/beads.jsonl) followed by `bd sync`, the sync command fails to detect that the JSONL changed and exports the local database, **overwriting the pulled JSONL** instead of importing it first.\n\nThis causes cleaned-up issues (removed via `bd cleanup` in another repo) to be resurrected and pushed back to the remote.\n\n## Root Cause\n\n`hasJSONLChanged()` in cmd/bd/integrity.go incorrectly returns FALSE when it should return TRUE after git pull updates the JSONL file.\n\nThe function has two code paths:\n1. **Fast-path (line 128-129)**: If mtime unchanged, return false\n2. **Slow-path (line 135-151)**: Compute hash and compare\n\nSuspected issue: The mtime-based fast-path may incorrectly return false if:\n- Git preserves mtime when checking out files, OR\n- The mtime check logic has a race condition, OR\n- The stored last_import_mtime is stale/incorrect\n\n## Reproduction\n\n**Setup:**\n1. Repo A: Has 686 issues (including 630 closed)\n2. Run `bd cleanup -f` in Repo A (removes 630 closed issues → 56 issues remain)\n3. Push to remote\n4. Repo B: Still has 686 issues in database\n\n**Trigger:**\n1. In Repo B: `git pull` (JSONL now has 56 issues)\n2. In Repo B: `bd sync`\n\n**Expected behavior:**\n- hasJSONLChanged() returns TRUE\n- Auto-imports 56-issue JSONL\n- Database updated to 56 issues\n- Exports (no-op, DB and JSONL match)\n- Pushes\n\n**Actual behavior:**\n- hasJSONLChanged() returns FALSE ❌\n- Skips auto-import\n- Exports 686 issues from DB to JSONL\n- Commits and pushes the 686-issue JSONL\n- **Undoes the cleanup from Repo A**\n\n## Evidence\n\nFrom actual session (2025-11-23):\n- Commit 8bc8611 in cino/beads shows: `+640, -14 lines` after bd sync\n- No \"Auto-import complete\" message in output\n- Database had 686 issues, JSONL was pulled with 56 issues\n- Sync exported DB → JSONL instead of importing JSONL → DB\n\n## Impact\n\n**Critical:** This breaks multi-device sync and causes:\n- Lost work (cleanup operations undone)\n- Data resurrection (deleted issues come back)\n- Confusing merge conflicts\n- User trust issues (\"Why does sync keep bringing back deleted issues?\")\n\n## Proposed Solutions\n\n### Option 1: Remove mtime fast-path (safest)\nAlways compute and compare hashes. Eliminates false negatives from mtime issues.\n\n**Pros:** Guaranteed correctness\n**Cons:** Slightly slower (hash computation on every sync)\n\n### Option 2: Fix mtime comparison logic\nInvestigate why mtime check fails and fix it properly.\n\n**Areas to check:**\n- Does git preserve mtime on checkout? (may vary by git version/config)\n- Is last_import_mtime updated correctly after all operations?\n- Race condition between git pull and mtime check?\n\n### Option 3: Add hash-based validation\nKeep mtime fast-path but add hash validation as backup:\n- If mtime unchanged, still spot-check hash occasionally (e.g., 10% of the time)\n- Log warnings when mtime and hash disagree\n- This would catch the bug while maintaining performance\n\n### Option 4: Add `--force-import` flag to bd sync\nShort-term workaround: Allow users to force import even if hasJSONLChanged() returns false.\n\n## Workaround\n\nUntil fixed, after `git pull`:\n```bash\nbd import --force  # Force import the pulled JSONL\nbd sync            # Then sync normally\n```\n\nOr manually run bd cleanup in affected repos.\n\n## Files\n\n- cmd/bd/integrity.go:101-152 (hasJSONLChanged function)\n- cmd/bd/sync.go:130-143 (auto-import logic)\n- cmd/bd/autoflush.go:698 (export updates last_import_hash)\n\n## Related Issues\n\n- bd-77gm: Import reports misleading counts\n- bd-khnb: Content-based staleness detection (original implementation of hash checking)\n","notes":"## Fix Implemented (Option 1)\n\n**Root Cause Confirmed:**\nGit does NOT update mtime when checking out files. Testing confirmed that after `git checkout HEAD~1`, the file mtime remains unchanged even though content differs.\n\n**Solution:**\nRemoved the mtime-based fast-path in `hasJSONLChanged()`. Now always computes content hash for comparison.\n\n**Changes Made:**\n1. **cmd/bd/integrity.go:107-116** - Removed mtime fast-path, always compute hash\n2. **cmd/bd/sync.go:752** - Removed mtime storage after import\n3. **cmd/bd/import.go:340** - Removed mtime storage after import\n4. **cmd/bd/daemon_sync.go:280-301** - Removed mtime storage and updated comments\n5. **cmd/bd/daemon_sync_test.go:479,607,628** - Removed mtime assertions from tests\n\n**Performance Impact:**\nMinimal. Hash computation takes ~10-50ms even for large databases, which is acceptable for sync operations.\n\n**Testing:**\n- All existing tests pass\n- Test \"mtime changed but content same - git operation scenario\" verifies the fix\n- Full test suite passes (cmd/bd and all internal packages)\n\n**Verification:**\nThe fix ensures that after `git pull` updates the JSONL:\n1. `hasJSONLChanged()` returns TRUE (content hash differs)\n2. Auto-import runs and updates database\n3. No data loss or resurrection of deleted issues","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-11-23T22:24:53.69901-08:00","updated_at":"2025-11-24T00:01:27.560055-08:00","closed_at":"2025-11-23T22:50:12.611126-08:00"}
+{"id":"bd-v29","title":"Deletions pruning doesn't include results in JSON output","description":"## Problem\n\nWhen `bd compact --json` runs with deletions pruning, the prune results are silently discarded:\n\n```go\n// Only report if there were deletions to prune\nif result.PrunedCount \u003e 0 {\n    if jsonOutput {\n        // JSON output will be included in the main response\n        return  // \u003c-- BUG: results are NOT included anywhere\n    }\n    ...\n}\n```\n\n## Location\n`cmd/bd/compact.go:925-929`\n\n## Impact\n- JSON consumers don't know deletions were pruned\n- No way to audit pruning via automation\n\n## Fix\nReturn prune results and include in JSON output structure:\n\n```json\n{\n  \"success\": true,\n  \"compacted\": {...},\n  \"deletions_pruned\": {\n    \"count\": 5,\n    \"retention_days\": 7\n  }\n}\n```","status":"open","priority":2,"issue_type":"bug","created_at":"2025-11-25T12:48:59.730979-08:00","updated_at":"2025-11-25T12:48:59.730979-08:00"}
 {"id":"bd-v2x","title":"Add deletions pruning to bd compact","description":"Parent: bd-imj\n\n## Task\nAdd time-based pruning of deletions manifest to `bd compact`.\n\n## Implementation\n\n```go\nfunc (c *Compactor) PruneDeletions(retentionDays int) error {\n    records, err := deletions.Load(\".beads/deletions.jsonl\")\n    if err != nil {\n        return err\n    }\n    \n    cutoff := time.Now().AddDate(0, 0, -retentionDays)\n    var kept []DeletionRecord\n    var pruned int\n    \n    for _, r := range records {\n        if r.Timestamp.After(cutoff) {\n            kept = append(kept, r)\n        } else {\n            pruned++\n        }\n    }\n    \n    if pruned \u003e 0 {\n        if err := deletions.Write(\".beads/deletions.jsonl\", kept); err != nil {\n            return err\n        }\n        log.Printf(\"Pruned %d deletions older than %d days\", pruned, retentionDays)\n    }\n    \n    return nil\n}\n```\n\n## Configuration\n```yaml\n# .beads/config.yaml\ndeletions:\n  retention_days: 7  # Default\n  max_entries: 50000\n```\n\n## CLI\n```bash\nbd compact                    # Prunes deletions with default retention\nbd compact --retention=14     # Override retention for this run\n```\n\n## Acceptance Criteria\n- [ ] `bd compact` prunes deletions by age\n- [ ] Retention configurable via config.yaml\n- [ ] Retention overridable via CLI flag\n- [ ] Atomic file rewrite (no corruption on crash)\n- [ ] Test: old deletions pruned, recent kept","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-25T09:57:03.922494-08:00","updated_at":"2025-11-25T12:38:47.220395-08:00","closed_at":"2025-11-25T12:38:47.220398-08:00","dependencies":[{"issue_id":"bd-v2x","depends_on_id":"bd-2bl","type":"blocks","created_at":"2025-11-25T09:57:50.009596-08:00","created_by":"daemon"}]}
 {"id":"bd-vfe","title":"Apply wrapDBError to config.go","description":"","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-24T00:53:12.771275-08:00","updated_at":"2025-11-24T00:54:15.676618-08:00","closed_at":"2025-11-24T00:54:15.676618-08:00"}
 {"id":"bd-w8h","title":"Apply wrapDBError to remaining storage files","description":"","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-24T00:53:15.498428-08:00","updated_at":"2025-11-24T00:56:47.434071-08:00","closed_at":"2025-11-24T00:56:47.434071-08:00"}
 {"id":"bd-wcl","title":"Document CLI + hooks as recommended approach over MCP","description":"Update documentation to position CLI + bd prime hooks as the primary recommended approach over MCP server, explaining why minimizing context matters even with large context windows (compute cost, energy, environment, latency).","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-12T00:15:25.923025-08:00","updated_at":"2025-11-12T00:18:16.786857-08:00"}
+{"id":"bd-wmo","title":"PruneDeletions iterates map non-deterministically","description":"## Problem\n\n`PruneDeletions` iterates over `loadResult.Records` which is a map. Go maps iterate in random order, so:\n\n1. `result.PrunedIDs` order is non-deterministic\n2. `kept` slice order is non-deterministic → `WriteDeletions` output order varies\n\n## Location\n`internal/deletions/deletions.go:213`\n\n## Impact\n- Git diffs are noisy (file changes order on each prune)\n- Tests could be flaky if they depend on order\n- Harder to debug/audit\n\n## Fix\nSort by ID or timestamp before iterating:\n\n```go\n// Convert map to slice and sort\nvar records []DeletionRecord\nfor _, r := range loadResult.Records {\n    records = append(records, r)\n}\nsort.Slice(records, func(i, j int) bool {\n    return records[i].ID \u003c records[j].ID\n})\n```","status":"open","priority":3,"issue_type":"bug","created_at":"2025-11-25T12:49:11.290916-08:00","updated_at":"2025-11-25T12:49:11.290916-08:00"}
 {"id":"bd-x2i","title":"Add bd deleted command for audit trail","description":"Parent: bd-imj\n\nAdd command to view deletion history.\n\nUsage:\n  bd deleted              # Show recent deletions (last 7 days)\n  bd deleted --since=30d  # Show deletions in last 30 days\n  bd deleted --all        # Show all tracked deletions\n  bd deleted bd-xxx       # Show deletion details for specific issue\n\nOutput format:\n  bd-xxx  2025-11-25 10:00  stevey  duplicate of bd-yyy\n  bd-yyy  2025-11-25 10:05  claude  cleanup\n\nAcceptance criteria:\n- List deletions with timestamp, actor, reason\n- Filter by time range\n- Lookup specific issue ID\n- JSON output option for scripting","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-25T09:57:21.113861-08:00","updated_at":"2025-11-25T09:57:21.113861-08:00"}
 {"id":"bd-ybv5","title":"Refactor AGENTS.md to use external references","description":"Suggestion to use external references (e.g., \"ALWAYS REFER TO ./beads/prompt.md\") instead of including all instructions directly within AGENTS.md.\nReasons:\n1. Agents can follow external references.\n2. Prevents context pollution/stuffing in AGENTS.md as more tools append instructions.\n","status":"open","priority":3,"issue_type":"task","created_at":"2025-11-20T18:55:53.259144-05:00","updated_at":"2025-11-20T18:55:53.259144-05:00"}
 {"id":"bd-ye0d","title":"troubleshoot GH#278 daemon exits every few secs","description":"","status":"open","priority":2,"issue_type":"task","created_at":"2025-11-13T06:27:23.39509215-07:00","updated_at":"2025-11-13T06:27:23.39509215-07:00"}