bd sync: 2025-11-24 17:00:58
This commit is contained in:
@@ -615,6 +615,7 @@
|
||||
{"id":"bd-u3t","content_hash":"0666b1c7fb8f72d592027b74221e620e5f6aeb71a2ab4c3bcc15df190dc6a037","title":"Phase 2: Implement sandbox auto-detection for GH #353","description":"Implement automatic sandbox detection to improve UX for users in sandboxed environments (e.g., Codex).\n\n**Tasks:**\n1. Implement sandbox detection heuristic using syscall.Kill permission checks\n2. Auto-enable --sandbox mode when sandbox is detected\n3. Display informative message when sandbox is detected\n\n**Implementation:**\n- Add isSandboxed() function in cmd/bd/main.go\n- Auto-set sandboxMode = true in PersistentPreRun when detected\n- Show: 'ℹ️ Sandbox detected, using direct mode'\n\n**References:**\n- docs/GH353_INVESTIGATION.md (Solution 3, lines 120-160)\n- Depends on: Phase 1 (bd-???)\n\n**Acceptance Criteria:**\n- Codex users don't need to manually specify --sandbox\n- No false positives in normal environments\n- Clear messaging when auto-detection triggers","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-21T18:51:57.254358-05:00","updated_at":"2025-11-21T19:28:24.467713-05:00","closed_at":"2025-11-21T19:28:24.467713-05:00","source_repo":"."}
|
||||
{"id":"bd-u4f5","content_hash":"89c6ae8745a842541c9a2025222c2c2e67e17b4fc33e0e56e58a37f0c5935939","title":"bd import silently succeeds when database matches working tree but not git HEAD","description":"**Critical**: bd import reports '0 created, 0 updated' when database matches working tree JSONL, even when working tree is ahead of git HEAD. This gives false confidence that everything is synced with the source of truth.\n\n## Reproduction\n\n1. Start with database synced to working tree .beads/issues.jsonl (376 issues)\n2. Git HEAD has older version of .beads/issues.jsonl (354 issues)\n3. Run: bd import .beads/issues.jsonl\n4. Output: 'Import complete: 0 created, 0 updated'\n\n## Problem\n\nUser expects 'bd import' after 'git pull' to sync database with committed state, but:\n- Command silently succeeds because DB already matches working tree\n- No warning that working tree has uncommitted changes\n- User falsely believes everything is synced with git\n- Violates 'JSONL in git is source of truth' principle\n\n## Expected Behavior\n\nWhen .beads/issues.jsonl differs from git HEAD, bd import should:\n1. Detect uncommitted changes: git diff --quiet HEAD .beads/issues.jsonl\n2. Warn user: 'Warning: .beads/issues.jsonl has uncommitted changes (376 lines vs 354 in HEAD)'\n3. Clarify status: 'Import complete: 0 created, 0 updated (already synced with working tree)'\n4. Recommend: 'Run git diff .beads/issues.jsonl to review uncommitted work'\n\n## Impact\n\n- Users can't trust 'bd import' status messages\n- Silent data loss risk if user assumes synced and runs git checkout\n- Breaks mental model of 'JSONL in git = source of truth'\n- Critical for VC's landing-the-plane workflow","acceptance_criteria":"1. bd import detects when working tree differs from git HEAD\n2. Warning emitted if JSONL has uncommitted changes \n3. Status message clarifies 'synced with working tree' vs 'synced with git'\n4. Optional flag to suppress warning (e.g., --working-tree mode)\n5. Documentation updated to explain import behavior with uncommitted changes\n6. Test case: import with dirty working tree shows warning","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-07T23:51:28.536822-08:00","updated_at":"2025-11-07T23:58:34.482313-08:00","closed_at":"2025-11-07T23:58:34.482313-08:00","source_repo":".","labels":["data-integrity"]}
|
||||
{"id":"bd-u8j","content_hash":"91f39bbd4f2394592407c77917682b2c7c3a0b6415a3572eb75a49b0486a17fe","title":"Clarify exclusive lock protocol compatibility with multi-repo","description":"The contributor-workflow-analysis.md proposes per-repo file locking (Decision #7) using flock on JSONL files. However, VC (a downstream library consumer) uses an exclusive lock protocol (vc-195, requires Beads v0.17.3+) that allows bd daemon and VC executor to coexist.\n\nNeed to clarify:\n- Does the proposed per-repo file locking work with VC's existing exclusive lock protocol?\n- Do library consumers like VC need to adapt their locking logic?\n- Can multiple repos be locked atomically for cross-repo operations?\n\nContext: contributor-workflow-analysis.md lines 662-681","acceptance_criteria":"- Documentation explicitly states compatibility or incompatibility with existing lock protocols\n- If incompatible, migration path is documented for library consumers\n- If compatible, example showing coexistence is provided","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-03T20:24:08.257493-08:00","updated_at":"2025-11-05T14:15:01.506885-08:00","closed_at":"2025-11-05T14:15:01.506885-08:00","source_repo":"."}
|
||||
{"id":"bd-ufny","content_hash":"e91676db7930ad2f04145ce7bb6d438d2ade056750d78974c55577a4cc0409b7","title":"First-class git worktree support","description":"## Motivation\n\nBeads should be a first-class citizen in git worktree environments like gastown/town, where multiple worktrees share the same repository but work on different branches simultaneously.\n\nCurrent state: Worktrees trigger a warning suggesting --no-daemon, but this is a bandaid, not a solution. MCP integration requires daemon mode, so worktree users are second-class citizens.\n\n## The Core Problem\n\nGit worktrees create a fundamental mismatch:\n- Multiple checkouts share one .beads/ directory (tracked in git)\n- One SQLite database (gitignored local cache)\n- One daemon per .beads/ path\n- Daemon doesn't know which worktree is calling it\n- Sync commits can go to the wrong branch\n\n## Use Cases\n\n1. **Gastown/Town Pattern**: One project, multiple named worktrees (polecats), all sharing issues\n2. **Solo Developer**: Main + feature branch worktrees, issues visible across all\n3. **Team**: Multiple developers using worktrees, syncing via git\n\n## Key Insight\n\nIssues are PROJECT-level, not BRANCH-level. An issue created in BlackRoad worktree is still relevant to RedTanker. The JSONL is shared via git. The database is just a local cache.\n\n## Proposed Solution: Per-Worktree Daemon with Shared Database\n\n### 1. Auto-Detect Worktree Environment\n```go\nfunc DetectWorktreeMode() WorktreeMode {\n gitDir := exec(\"git rev-parse --git-dir\")\n commonDir := exec(\"git rev-parse --git-common-dir\")\n if gitDir != commonDir {\n return WorktreeModeDetected\n }\n return WorktreeModeNormal\n}\n```\n\n### 2. Worktree Identity in Daemon\n- Socket path includes worktree name: `.beads/bd-{worktree-name}.sock`\n- Each worktree gets its own daemon process\n- All daemons share SQLite with proper WAL-mode locking\n- Each daemon knows its worktree's current branch\n\n### 3. Auto-Initialize on First Access\nWhen bd runs in worktree without local database:\n1. Detect worktree mode\n2. Find shared .beads/issues.jsonl\n3. Create/update local SQLite cache\n4. Auto-detect prefix from existing JSONL issues\n5. Start worktree-aware daemon\n6. No \"bd init\" ceremony needed\n\n### 4. Worktree-Aware Sync\nOptions (configurable):\n- **Per-branch**: Each daemon commits to its worktree's current branch\n- **Unified**: All daemons commit to a shared \"beads-sync\" branch\n\n### 5. Graceful Degradation\nIf worktree complexity detected and daemon can't handle it:\n- Warn once (not every command)\n- Auto-fallback to no-daemon mode\n- Fully functional, just no auto-sync\n\n## Implementation Phases\n\n### Phase 1: Better Detection \u0026 Auto-Fallback\n- Improved worktree detection\n- Single clear warning with actionable advice\n- Auto-set BEADS_NO_DAEMON in worktrees by default\n- Add --worktree-mode flag to override\n\n### Phase 2: Auto-Init\n- When JSONL exists but no DB, auto-initialize\n- Infer prefix from existing issues (already works in bd init)\n- Eliminate \"bd init\" requirement for fresh worktree clones\n\n### Phase 3: Per-Worktree Daemons\n- Socket/lock naming with worktree identity\n- Daemon startup detects and records worktree context\n- Proper WAL-mode locking for concurrent DB access\n- RPC includes worktree context\n\n### Phase 4: Worktree-Aware Sync\n- Config option: sync-mode: per-branch | unified\n- Branch-aware commit routing\n- Handle merge conflicts gracefully\n- Test with gastown multi-polecat setup\n\n## Files to Modify\n\n- `cmd/bd/main.go`: Database discovery, worktree detection\n- `cmd/bd/daemon.go`: Socket path generation with worktree ID\n- `cmd/bd/daemon_sync_branch.go`: Branch routing per worktree\n- `cmd/bd/worktree.go`: Enhanced detection, auto-fallback logic\n- `cmd/bd/init.go`: Auto-init when JSONL exists\n- `internal/daemon/discovery.go`: Find daemons per worktree\n- `internal/beads/discover.go`: Worktree-aware DB discovery\n\n## Success Criteria\n\n1. Running `bd list` in a fresh gastown worktree \"just works\" (no bd init needed)\n2. Multiple worktrees can run daemons simultaneously without conflict\n3. MCP integration works in worktree environments\n4. Sync commits go to correct branch (or configured sync branch)\n5. No scary warnings for supported worktree configurations\n\n## References\n\n- gastown issue: gt-t8q (Support git worktree environments natively)\n- Current worktree warning: cmd/bd/worktree.go warnWorktreeDaemon()\n- Existing WorktreeManager: internal/git/worktree.go","status":"open","priority":1,"issue_type":"feature","created_at":"2025-11-24T16:27:31.381177-08:00","updated_at":"2025-11-24T16:27:31.381177-08:00","source_repo":"."}
|
||||
{"id":"bd-uiae","content_hash":"5c184901daaa674a0f1224a29ab789019b53da6d5b5b4d6ac943e7d5d4846b3e","title":"Update documentation for beads-merge integration","description":"Document the integrated merge functionality.\n\n**Updates needed**:\n- AGENTS.md: Replace \"use external beads-merge\" with \"bd merge\"\n- README.md: Add git merge driver section\n- TROUBLESHOOTING.md: Update merge conflict resolution\n- ADVANCED.md: Document 3-way merge algorithm\n- Create CREDITS.md or ATTRIBUTION.md for @neongreen\n\n**Highlight**: Deletion sync fix (bd-hv01)","status":"closed","priority":2,"issue_type":"task","created_at":"2025-11-05T18:42:20.488998-08:00","updated_at":"2025-11-06T18:19:16.234758-08:00","closed_at":"2025-11-06T15:40:27.830475-08:00","source_repo":".","dependencies":[{"issue_id":"bd-uiae","depends_on_id":"bd-qqvw","type":"parent-child","created_at":"2025-11-05T18:42:28.752447-08:00","created_by":"daemon"}]}
|
||||
{"id":"bd-urob","content_hash":"fc0e79260f5f6860fa8884859c4b33b18f9cc2dad361c1c1abb9bdeb412479b5","title":"bd-hv01: Refactor snapshot management into dedicated module","description":"Problem: Snapshot logic is scattered across deletion_tracking.go. Would benefit from abstraction with SnapshotManager type.\n\nBenefits: cleaner separation of concerns, easier to test in isolation, better encapsulation, could add observability/metrics.\n\nSuggested improvements: add magic constants, track merge statistics, better error messages.\n\nFiles: cmd/bd/deletion_tracking.go (refactor into new snapshot_manager.go)","status":"closed","priority":3,"issue_type":"chore","created_at":"2025-11-06T18:16:27.943666-08:00","updated_at":"2025-11-08T02:24:24.686744-08:00","closed_at":"2025-11-08T02:19:14.152412-08:00","source_repo":".","dependencies":[{"issue_id":"bd-urob","depends_on_id":"bd-rbxi","type":"parent-child","created_at":"2025-11-06T18:19:15.192447-08:00","created_by":"daemon"}]}
|
||||
{"id":"bd-ut5","content_hash":"d9b4ee9c7748c28dc2cd436911b1bee39e68e82df99b718ebe57a246f72a6bcb","title":"Test label update feature","description":"","status":"open","priority":3,"issue_type":"task","created_at":"2025-11-21T22:07:25.488849-05:00","updated_at":"2025-11-21T22:07:25.488849-05:00","source_repo":".","labels":["test-direct"]}
|
||||
|
||||
Reference in New Issue
Block a user