Document versioning and release strategy

Create comprehensive versioning strategy for beads ecosystem.

Components to document:
1. bd CLI (Go binary) - main version number
2. Plugin (Claude Code) - tracks CLI version
3. MCP server (Python) - bundled with plugin
4. Release workflow - how to sync all three

Decisions to make:
- Should plugin.json auto-update from bd CLI version?
- Should we have a VERSION file at repo root?
- How to handle breaking changes across components?
- What's the update notification strategy?

References:
- plugin.json engines field now requires bd >=0.9.0
- /bd-version command added for checking compatibility
- PLUGIN.md now documents update workflow


Improve error handling in dependency removal during remapping

In updateDependencyReferences(), RemoveDependency errors are caught and ignored with continue (line 392). Comment says 'if dependency doesn't exist' but this catches ALL errors including real failures. Should check error type with errors.Is(err, ErrDependencyNotFound) and only ignore not-found errors, returning other errors properly.

Federation allows:
- Multiple gateways sync with each other
- Each gateway has authoritative set of issues
- Peer-to-peer sync protocol
- Conflict resolution across gateways

Architecture:
- Gateway-to-gateway API
- Peer discovery
- Sync protocol between gateways
- Distributed conflict resolution

Complex feature - only if team usage emerges.

- Gateway federation protocol designed
- Peer discovery mechanism
- Gateway-to-gateway sync
- Distributed conflict resolution
- Tests for federation
- Documentation in FEDERATION.md

---


Consider batching API for bulk issue creation (recovered from bd-222)

Current CreateIssue acquires a dedicated connection for each call. For bulk imports or agent workflows creating many issues, a batched API could improve performance:

CreateIssues(ctx, issues []*Issue, actor string) error

This would:
- Acquire one connection
- Use one IMMEDIATE transaction
- Insert all issues atomically
- Reduce connection overhead

Not urgent - current approach is correct and fast enough for typical use.

**Recovered from:** bd-390 (lost in auto-import bug, see LOST_ISSUES_RECOVERY.md)

Investigation complete. Successfully recovered 3 valuable issues (bd-651, bd-233) from 22 total lost. Historical context preserved in bd-89 notes. Auto-import collision detection (bd-656) now prevents future data loss.


parallel_test_1

Add new section: "Multi-Device Sync"

Content:
- Brief overview of git-based sync
- Link to SYNC.md for details
- Link to GATEWAY.md for gateway mode
- Quick start examples
- Configuration options

Keep brief - detailed docs in separate files.

- README.md updated with sync section
- Links to SYNC.md and GATEWAY.md
- Quick start examples
- Configuration overview
- Maintains existing structure
- All links working

---


verification_

Sections:
1. Introduction
2. Quick Start
3. Manual Git Workflow
4. bd sync Command
5. bd daemon Background Sync
6. Git Hooks
7. Conflict Resolution
8. Best Practices
9. Troubleshooting
10. FAQ

Include examples, code snippets, and diagrams.

- SYNC.md created with all sections
- Quick start guide for new users
- Detailed workflow examples
- Conflict resolution guide
- Best practices section
- Troubleshooting with solutions
- FAQ with common questions
- Code examples working
- Links from README.md

---


Concurrent bd commands collide on shared .tmp filename

When multiple bd commands run concurrently (e.g., different agents), they all write to .beads/issues.jsonl.tmp causing race conditions. One command's rename succeeds, consuming the .tmp file, then other commands fail with 'no such file or directory'. Solution: use unique temp filenames with PID or random suffix (e.g., issues.jsonl.tmp.12345).

Label management fully implemented with comprehensive test coverage (10 test cases). Provides foundation for better data organization and filtering.


parallel_test_9

Analysis complete. Recommendation: Hybrid approach with DB CHECK constraint + smart UpdateIssue + import enforcement + reopen command.

Key insights:
- DB constraint provides defense-in-depth perfect for agent swarms
- Statistics calculation currently uses 'closed_at IS NOT NULL' which is BROKEN by inconsistent data
- UpdateIssue and Import don't manage the invariant
- EventReopened exists but is unused

See ULTRATHINK_BD224.md for full analysis.


Critical: Auto-import silently overwrites local changes without collision detection

## Problem

Auto-import is silently overwriting local changes when pulling from Git, without using collision detection or warning the user.

## Evidence

Issue bd-89 timeline:
1. 08:07:31 - Manual update: set status=in_progress
2. 08:13:08 - Manual close: set status=closed, closed_at set
3. 08:33:25 - **Auto-import silently overwrote to status=open** (discarded local change)
4. 08:57:59 - Auto-import overwrote again
5. 08:58:30 - Auto-import overwrote again

Query shows 10+ issues with multiple auto-import overwrites, including bd-621, bd-199, bd-358-206.

## Root Cause Hypothesis

When two clones both modify issue N:
- Clone A: modifies bd-89, exports to JSONL, commits
- Clone B: also modifies bd-89 differently, pulls from A
- Auto-import uses UpdateIssue which **unconditionally overwrites**
- Clone B's local changes are silently lost
- No collision detection warning
- References and work context corrupted

## Impact

- **Data loss**: Local changes silently discarded
- **Corruption**: Issue state doesn't reflect actual work done
- **Lost references**: Comments/deps referencing lost state are now wrong
- **Trust**: Can't trust the database reflects reality
- **Agent swarms**: Catastrophic for parallel workers

## Expected Behavior

Auto-import should:
1. Detect collisions (same ID, different content)
2. Warn user or fail import
3. Offer resolution options (--resolve-collisions)
4. Never silently overwrite without user confirmation

## Current Behavior

Auto-import silently overwrites using UpdateIssue, no collision detection.

## Reproduction

1. Clone A: bd update bd-1 --status in_progress
2. Clone A: git add .beads/issues.jsonl && git commit && git push
3. Clone B: bd update bd-1 --status closed
4. Clone B: git pull (triggers auto-import)
5. Result: bd-1 status silently reverted to in_progress, closed state lost

## Files Involved

- cmd/bd/main.go: auto-import trigger logic
- cmd/bd/import.go: import without collision detection
- internal/storage/sqlite/sqlite.go: UpdateIssue unconditionally overwrites


Reach 1.0 release milestone

Stabilize API, finalize documentation, comprehensive testing


Add integration tests for auto-import collision detection

The auto-import collision detection fix (bd-656) needs comprehensive integration tests.

## Test Scenarios Needed

### 1. Basic Collision Detection
```go
TestAutoImportWithCollisions
- Setup: Create issue in DB with status=closed
- Simulate: Git pull with JSONL containing same issue with status=open
- Verify: Local changes preserved, warning printed, issue still closed
```

### 2. Multiple Collisions
```go
TestAutoImportWithMultipleCollisions
- Setup: 5 issues with local modifications
- Simulate: JSONL with 3 colliding, 2 matching
- Verify: 3 skipped, 2 updated, appropriate warnings
```

### 3. No Collisions (Happy Path)
```go
TestAutoImportWithoutCollisions
- Setup: Clean database
- Simulate: JSONL with new issues + exact matches
- Verify: All imported successfully, no warnings
```

### 4. All Collisions
```go
TestAutoImportAllCollisions
- Setup: Every issue has local modifications
- Simulate: JSONL with conflicting versions
- Verify: All skipped, warning lists all issues
```

### 5. Collision Detection Failure
```go
TestAutoImportCollisionDetectionError
- Setup: Mock DetectCollisions() to return error
- Verify: Import skipped entirely (safe failure mode)
```

### 6. Hash-Based Skip
```go
TestAutoImportHashUnchanged
- Setup: JSONL hash matches last_import_hash
- Verify: No collision detection runs, fast path
```

### 7. Fallback for Non-SQLite
```go
TestAutoImportWithoutCollisionDetection
- Setup: Mock non-SQLite storage backend
- Verify: Falls back to old behavior, no collision detection
```

## Test Infrastructure Needed

1. **Helper functions:**
   - createTestDBWithIssues()
   - writeJSONLFile()
   - captureStderrWarnings()
   - simulateGitPull()

2. **Fixtures:**
   - sample-collisions.jsonl
   - sample-exact-matches.jsonl
   - sample-mixed.jsonl

3. **Assertions:**
   - assertIssueState(id, expectedStatus)
   - assertWarningContains(text)
   - assertCollisionCount(n)

## Acceptance Criteria
- All 7 test scenarios implemented
- Tests pass consistently
- Code coverage >80% for autoImportIfNewer()
- Tests run in <5 seconds total
- Clear test names and documentation


Low priority chore

Benchmarks for:
1. JSONL import/export performance
2. Collision detection performance
3. Three-way merge performance
4. Gateway API latency
5. WebSocket throughput
6. Concurrent client handling
7. Large database operations (10k+ issues)

Use Go benchmarking and profiling tools.

Track performance over time in CI.

- Benchmark suite implemented
- All key operations benchmarked
- CPU and memory profiling
- Large database benchmarks
- Concurrent operation benchmarks
- CI integration for regression detection
- Performance baseline documented
- Documentation in PERFORMANCE.md

---


Sync versions to 0.9.2 across all components

Version mismatch discovered: bd CLI is 0.9.2 but other components still at 0.9.0 or 1.0.0.

Current state:
- bd CLI (cmd/bd/version.go): 0.9.2 ✓
- Plugin (.claude-plugin/plugin.json): 0.9.0 ✗
- MCP Server (integrations/beads-mcp): 1.0.0 ✗
- README.md: 0.9.0 ✗

Files to update:
1. .claude-plugin/plugin.json
2. integrations/beads-mcp/pyproject.toml
3. README.md (all mentions)
4. PLUGIN.md (if any mentions)
5. CHANGELOG.md (add 0.9.1 and 0.9.2 entries)

Root cause: Version bumps only updated version.go, not other components.
Solution needed: Script or process to sync versions across all files.


Build collision resolution tooling for distributed branch workflows

When branches diverge and both create issues, auto-incrementing IDs collide on merge. Build excellent tooling to detect collisions during import, auto-renumber issues with fewer dependencies, update all references in descriptions and dependency links, and provide clear user feedback. Goal: keep beautiful brevity of numeric IDs (bd-374) while handling distributed creation gracefully.


Code review follow-up: Post-PR #8 merge improvements

Follow-up tasks from the ultrathink code review of PR #8 merge (bd-62).

**Context:** PR #8 successfully merged atomic counter + dirty tracking. Core functionality is solid but several improvements identified.

**Critical (P0-P1):**
- bd-64: Fix SyncAllCounters performance bottleneck (P0)
- bd-65: Add migration for issue_counters table (P1)
- bd-66: Make import counter sync failure fatal (P1)

**Nice to have (P2-P3):**
- bd-67: Update test comments (P2)
- bd-68: Add performance benchmarks (P2)
- bd-69: Add metrics/logging (P3)
- bd-70: Add EXPLAIN QUERY PLAN tests (P3)

**Overall assessment:** 4/5 stars - Excellent implementation with one critical performance issue. After bd-64 is fixed, this becomes 5/5.

**Review document:** Available if needed

Command should:
1. Export pending changes to JSONL
2. Commit changes to git
3. Pull from remote (with conflict resolution)
4. Push local commits to remote

Wraps the entire sync workflow in one command for better UX.

- bd sync command implemented
- Exports dirty changes to JSONL automatically
- Commits to git with descriptive message
- Pulls and handles merge conflicts
- Auto-imports updated JSONL
- Pushes to remote
- Error handling for git failures
- Tests cover success and failure scenarios
- Documentation in README.md

---

All tasks completed: bd-64 (performance), bd-65 (migration), bd-66 (version sync), bd-67 (version script), bd-69 (CI coverage), bd-70 (test coverage). Code review follow-up complete.


When branches diverge and both create issues, auto-incrementing IDs collide on merge. Build excellent tooling to detect collisions during import, auto-renumber issues with fewer dependencies, update all references in descriptions and dependency links, and provide clear user feedback. Goal: keep beautiful brevity of numeric IDs (bd-641) while handling distributed creation gracefully.


Fix metadata error handling in auto-import

GetMetadata() failure causes auto-import to stop forever. Should treat missing/corrupt metadata as first import (lastHash='') instead of skipping.


Ensure last_import_hash update is error-checked

If hash update fails after successful import, auto-import will retry same import forever. Must error-check SetMetadata() and warn user.


Fix N+1 query pattern in auto-import

Line 347 calls GetIssue() for every imported issue. With 1000+ issues this is slow. Batch fetch all existing issues upfront.


Implement bd renumber command to compact issue ID space

After closing many duplicates, we have high issue numbers (bd-666) but only 114 open issues. Add command to renumber all issues sequentially to fill gaps.

Behavior:
- Renumber all issues starting from 1 (or next available after last closed)
- Update all references: dependencies, parent-child, discovered-from links
- Update text references in descriptions, notes, acceptance criteria
- Preserve chronological order by created_at
- Show mapping report (old ID -> new ID)
- Require confirmation or --force flag
- Export clean JSONL after renumber

Benefits:
- Cleaner ID space after collision remapping creates gaps
- More human-friendly issue numbers
- Easier to track project scope

Risks:
- Breaking external references (GitHub issues, docs, commits)
- Complexity of updating all references
- Git history confusion

Consider: Maybe only renumber open issues, leave closed ones untouched?


Create version bump script

Create scripts/bump-version.sh to automate version syncing across all components.

The script should:
1. Take a version number as argument (e.g., ./scripts/bump-version.sh 0.9.3)
2. Update all version files:
   - cmd/bd/version.go (Version constant)
   - .claude-plugin/plugin.json (version field)
   - .claude-plugin/marketplace.json (plugins[].version)
   - integrations/beads-mcp/pyproject.toml (version field)
   - README.md (Alpha version mention)
   - PLUGIN.md (version requirements)
3. Validate semantic versioning format
4. Show diff preview before applying
5. Optionally create git commit with standard message

This prevents the version mismatch issue that occurred when only version.go was updated.

Related: bd-66 (version sync issue)


Add system-wide/multi-repo support for beads

GitHub issue #4 requests ability to use beads across multiple projects and for system-wide task tracking.

Current limitation: beads is per-repository isolated. Each project has its own .beads/ directory and issues cannot reference issues in other projects.

Potential approaches:
1. Global beads instance in ~/.beads/global.db for cross-project work
2. Project references - allow issues to link across repos
3. Multi-project workspace support - one beads instance managing multiple repos
4. Integration with existing MCP server to provide remote multi-project access

Use cases:
- System administrators tracking work across multiple machines/repos
- Developers working on a dozen+ projects simultaneously
- Cross-cutting concerns that span multiple repositories
- Global todo list with project-specific subtasks

Related:
- GitHub issue #4: https://github.com/steveyegge/beads/issues/4
- Comparison to membank MCP which already supports multi-project via centralized server
- MCP server at integrations/beads-mcp/ could be extended for this

See also: Testing framework for plugins (also from GH #4)


Add coverage threshold to CI pipeline

Current CI runs tests with coverage but doesn't enforce minimum threshold. Add step to fail if coverage drops below target.

Current coverage: 60%
Recommended thresholds:
- Warn: 55%
- Fail: 50%

This prevents coverage regression while allowing gradual improvement toward 80% target for 1.0.

Implementation:
1. Add coverage check step after test run
2. Use 'go tool cover -func=coverage.out' to get total
3. Parse percentage and compare to threshold
4. Optionally: Use codecov's built-in threshold features

Related to test coverage improvement work (upcoming issue).


Add performance benchmarks document

Document actual performance metrics with hyperfine tests


Increase test coverage for auto-flush and auto-import features

Critical features have 0% test coverage despite being core workflow functionality.

**Uncovered areas (0% coverage):**

Auto-flush/Auto-import (dirty tracking):
- MarkIssueDirty / MarkIssuesDirty
- GetDirtyIssues / GetDirtyIssueCount
- ClearDirtyIssues / ClearDirtyIssuesByID
- Auto-flush debouncing logic
- Auto-import hash comparison

Database/file discovery:
- FindDatabasePath (finds .beads/*.db in directory tree)
- FindJSONLPath (finds issues.jsonl)
- findDatabaseInTree helper

Label operations:
- AddLabel / RemoveLabel
- GetLabels / GetIssuesByLabel

Events/Comments:
- AddComment
- GetEvents
- GetStatistics

Metadata storage:
- SetMetadata / GetMetadata (used for import hash tracking)

CLI output formatting:
- outputJSON
- printCollisionReport / printRemappingReport
- createIssuesFromMarkdown

**Priority areas:**
1. Auto-flush/import (highest risk - core workflow)
2. Database discovery (second - affects all operations)
3. Labels/events (lower priority - less commonly used)

**Test approach:**
- Add unit tests for dirty tracking in sqlite package
- Add integration tests for auto-flush timing and debouncing
- Add tests for import hash detection and idempotency
- Add tests for database discovery edge cases (permissions, nested dirs)

**Target:** Get overall coverage from 60% → 75%, focus on cmd/bd (currently 24.1%)

**Note:** These features work well in practice (dogfooding proves it) but edge cases (disk full, permissions, concurrent access, race conditions) are untested.

Test coverage significantly improved! Added comprehensive test suites:

**Tests Added:**
1. ✅ Dirty tracking (dirty_test.go): 8 tests
   - MarkIssueDirty, MarkIssuesDirty, GetDirtyIssues, ClearDirtyIssues
   - GetDirtyIssueCount, ClearDirtyIssuesByID
   - Ordering and timestamp update tests
   - Coverage: 75-100% for all functions

2. ✅ Metadata storage (sqlite_test.go): 4 tests
   - SetMetadata, GetMetadata with various scenarios
   - Coverage: 100%

3. ✅ Label operations (labels_test.go): 9 tests
   - AddLabel, RemoveLabel, GetLabels, GetIssuesByLabel
   - Duplicate handling, empty cases, dirty marking
   - Coverage: 71-82%

4. ✅ Events & Comments (events_test.go): 7 tests
   - AddComment, GetEvents with limits
   - Timestamp updates, dirty marking
   - Multiple event types in history
   - Coverage: 73-92%

5. ✅ Database/JSONL discovery (beads_test.go): 8 tests
   - FindDatabasePath with env var, tree search, home default
   - FindJSONLPath with existing files, defaults, multiple files
   - Coverage: 89-100%

**Coverage Results:**
- Overall: 70.3% (up from ~60%)
- beads package: 90.6%
- sqlite package: 74.7% (up from 60.8%)
- types package: 100%

**Impact:**
All priority 1 features now have solid test coverage. Auto-flush/import, metadata storage, labels, and events are thoroughly tested with edge cases covered.

Files created:
- internal/storage/sqlite/dirty_test.go (8 tests)
- internal/storage/sqlite/labels_test.go (9 tests)
- internal/storage/sqlite/events_test.go (7 tests)
- beads_test.go (8 tests)

Files modified:
- internal/storage/sqlite/sqlite_test.go (added 4 metadata tests)

**Next Steps (if desired):**
- CLI output formatting tests (outputJSON, printCollisionReport, etc.)
- Integration tests for auto-flush debouncing timing
- More edge cases for concurrent access


Status update: All P0-P1 critical tasks completed! bd-64 (performance), bd-65 (migration), bd-66 (fatal error), bd-67 (comments) are all done. Atomic counter implementation is now production-ready. Remaining tasks are P2-P3 enhancements.


Test performance - issue 1


Performance test 1


Performance test 2


Performance test 3


Performance test 4


Performance test 5


Performance test 6


Performance test 7


Reach 1.0 release milestone


Performance test 8


Performance test 9


Performance test 10


Add external_ref field for tracking GitHub issues

Add optional external_ref field to issues table to track external references like 'gh-9', 'jira-ABC', etc. Includes schema migration, CLI flags (--external-ref for create/update), and tests. This enables linking bd issues to GitHub issues for better workflow integration.


Auto-import fails in git workflows due to mtime issues

The auto-import mechanism (autoImportIfNewer) relies on file modification time comparison between JSONL and DB. This breaks in git workflows because git does not preserve original file modification times - pulled files get fresh mtimes based on checkout time.

Root causes:
1. Git checkout sets mtime to 'now', not original commit time
2. Auto-import compares JSONL mtime vs DB mtime (line 181 in main.go)
3. If DB was recently modified (agents working), mtime check fails
4. Auto-import silently returns without feedback
5. Agents continue with stale database state

This caused issues in VC project where 3 parallel agents:
- Pulled updated .beads/issues.jsonl from git
- Auto-import didn't trigger (JSONL appeared older than DB)
- Agents couldn't find their assigned issues
- Agents exported from wrong database, corrupting JSONL

Recommended approach: Checksum-based sync (option 3 from original design)

## Solution: Hash-based content comparison

Replace mtime comparison with JSONL content hash comparison:

1. **Compute JSONL hash on startup**:
   - SHA256 hash of .beads/issues.jsonl contents
   - Fast enough for typical repos (<1MB = ~20ms)
   - Only computed once per command invocation

2. **Store last import hash in DB**:
   - Add metadata table if not exists: CREATE TABLE IF NOT EXISTS metadata (key TEXT PRIMARY KEY, value TEXT)
   - Store hash after successful import: INSERT OR REPLACE INTO metadata (key, value) VALUES ('last_import_hash', '<hash>')
   - Query on startup: SELECT value FROM metadata WHERE key = 'last_import_hash'

3. **Compare hashes instead of mtimes**:
   - If JSONL hash != stored hash: auto-import (content changed)
   - If JSONL hash == stored hash: skip import (no changes)
   - If no stored hash: fall back to mtime comparison (backward compat)

4. **Update autoImportIfNewer() in cmd/bd/main.go**:
   - Lines 155-279 currently use mtime comparison (line 181)
   - Replace with hash comparison
   - Keep mtime as fallback for old DBs without metadata table

## Implementation Details

### New storage interface method:
```go
// In internal/storage/storage.go
type Storage interface {
    // ... existing methods ...
    GetMetadata(ctx context.Context, key string) (string, error)
    SetMetadata(ctx context.Context, key, value string) error
}
```

### Migration:
```go
// In internal/storage/sqlite/sqlite.go init
CREATE TABLE IF NOT EXISTS metadata (
    key TEXT PRIMARY KEY,
    value TEXT NOT NULL
);
```

### Updated autoImportIfNewer():
```go
func autoImportIfNewer() {
    jsonlPath := findJSONLPath()

    // Check if JSONL exists
    jsonlData, err := os.ReadFile(jsonlPath)
    if err != nil {
        return // No JSONL, skip
    }

    // Compute current hash
    hasher := sha256.New()
    hasher.Write(jsonlData)
    currentHash := hex.EncodeToString(hasher.Sum(nil))

    // Get last import hash from DB
    ctx := context.Background()
    lastHash, err := store.GetMetadata(ctx, "last_import_hash")
    if err != nil {
        // No metadata support (old DB) - fall back to mtime comparison
        autoImportIfNewerByMtime()
        return
    }

    // Compare hashes
    if currentHash == lastHash {
        return // No changes, skip import
    }

    // Content changed - import
    if err := importJSONLSilent(jsonlPath, jsonlData); err != nil {
        return // Import failed, skip
    }

    // Store new hash
    _ = store.SetMetadata(ctx, "last_import_hash", currentHash)
}
```

## Benefits

- **Git-proof**: Works regardless of file timestamps
- **Universal**: Works with git, Dropbox, rsync, manual edits
- **Backward compatible**: Falls back to mtime for old DBs
- **Efficient**: SHA256 is fast (~20ms for 1MB)
- **Accurate**: Only imports when content actually changed
- **No user action**: Fully automatic, invisible

## Performance Optimization

For very large repos (>10MB JSONL):
- Only hash if mtime changed (combine both checks)
- Use incremental hashing if metadata table tracks line count
- Consider sampling hash (first 1MB + last 1MB)

But start simple - full hash is fast enough for 99% of use cases.

## Rollout Plan

1. Add metadata table + Get/SetMetadata methods (backward compatible)
2. Update autoImportIfNewer() with hash logic + mtime fallback
3. Test with old and new DBs
4. Ship in next minor version (v0.10.0)
5. Document in CHANGELOG as "more reliable auto-import"
6. Git hooks remain optional but unnecessary for most users

- Auto-import works correctly after git pull
- Agents in parallel workflows see consistent database state
- Clear feedback when import is needed
- Performance acceptable for large databases
- Works in both git and non-git workflows
- Documentation updated with multi-agent best practices


GH-1: Fix bd dep tree graph display issues

Tree display has several issues: 1) Epic items may not expand all sub-items, 2) Subitems repeat multiple times at same level, 3) Items with multiple blockers appear multiple times. The tree visualization doesn't properly handle graph structures with multiple dependencies.


GH-2: Evaluate optional Turso backend for collaboration

RFC proposal for optional Turso/libSQL backend to enable: database branching, near-real-time sync between agents/humans, native vector search, browser-ready persistence (WASM/OPFS), and concurrent writes. Would be opt-in, keeping current JSONL+SQLite as default. Requires storage driver interface.


GH-3: Debug zsh killed error on bd init

User reports 'zsh: killed bd init' when running bd init or just bd command. Likely a crash or signal. Need to reproduce and investigate cause.


GH-4: Consider system-wide/multi-repo beads usage

User wants to use beads across multiple repositories and for sysadmin tasks. Currently beads is project-scoped (.beads/ directory). Explore options for system-wide issue tracking that spans multiple repos. Related question: how does beads compare to membank MCP?


GH-6: Fix race condition in parallel issue creation

Creating multiple issues rapidly in parallel causes 'UNIQUE constraint failed: issues.id' error. The ID generation has a race condition. Reproducible with: for i in {26..35}; do ./bd create parallel_ 2>&1 & done

**Historical context (recovered from lost issue bd-221):**

First attempt at fixing this race condition had a critical flaw: used 'ROLLBACK; BEGIN IMMEDIATE' which executed as two separate statements. After ROLLBACK, the Go tx object was invalid but continued to be used, causing undefined behavior.

Root cause of failed fix: database/sql connection pooling. Without acquiring a dedicated connection, subsequent queries could use different connections from the pool, breaking the transaction.

Correct fix (the one that was merged): Use conn := s.db.Conn(ctx) to acquire a dedicated connection, then execute BEGIN IMMEDIATE, all operations, and COMMIT on that single connection.

This bug was caught during code review and fixed before merging.

See LOST_ISSUES_RECOVERY.md for details on bd-221.


When branches diverge and both create issues, auto-incrementing IDs collide on merge. Build excellent tooling to detect collisions during import, auto-renumber issues with fewer dependencies, update all references in descriptions and dependency links, and provide clear user feedback. Goal: keep beautiful brevity of numeric IDs (bd-551) while handling distributed creation gracefully.


GH-7: Package available in AUR (beads-git)

Community member created AUR package for Arch Linux: https://aur.archlinux.org/packages/beads-git. This is informational - no action needed, but good to track for release process and documentation.


GH-9: Support markdown files in bd create

Request to support markdown files as input to bd create, which would parse the markdown and split it into multiple issues. Use case: developers keep feature drafts in markdown files in version control, then want to convert them into issues. Example: bd create -f feature-draft.md


GH-11: Add Docker support for hosted/shared instance

Request for Docker container hosting to use beads across multiple dev machines. Would need to consider: centralized database (PostgreSQL?), authentication, concurrent access, API server, etc. This is a significant architectural change from the current local-first model.


GH-18: Add --deps flag to bd create for one-command issue creation

Request to add dependency specification to bd create command instead of requiring separate 'bd dep add' command. Proposed syntax: bd create 'Fix bug' --deps discovered-from=bd-20. This would be especially useful for aider integration and reducing command verbosity.


parallel_test_1


parallel_test_4


parallel_test_7


parallel_test_6


parallel_test_5


parallel_test_2


Test issue with explicit ID


Root issue for dep tree test


Dependency A


Dependency B


Shared dependency C


Epic test


Task A under epic


Task B under epic


Sub-task under A


Sub-task under B


Another explicit ID