bd sync: 2025-12-21 17:20:07
This commit is contained in:
Steve Yegge
@@ -251,7 +251,7 @@
|
||||
{"id":"bd-lfak","title":"bd preflight: PR readiness checks for contributors","description":"## Vision\n\nEncode project-specific institutional knowledge into executable checks. CONTRIBUTING.md is documentation that's read once and forgotten; `bd preflight` is documentation that runs at exactly the right moment.\n\n## Problem Statement\n\nContributors face a \"last mile\" problem - they do the work but stumble on project-specific gotchas at PR time:\n- Nix vendorHash gets stale when go.sum changes\n- Beads artifacts leak into PRs (see bd-umbf for namespace solution)\n- Version mismatches between version.go and default.nix\n- Tests/lint not run locally before pushing\n- Other project-specific checks that only surface when CI fails\n\nThese are too obscure to remember, exist in docs nobody reads end-to-end, and waste CI round-trips.\n\n## Why beads?\n\nBeads already has a foothold in the contributor workflow. It knows:\n- Git state (staged files, branch, dirty status)\n- Project structure\n- The specific issue being worked on\n- Project-specific configuration\n\n## Proposed Interface\n\n### Tier 1: Checklist Mode (v1)\n\n $ bd preflight\n PR Readiness Checklist:\n\n [ ] Tests pass: go test -short ./...\n [ ] Lint passes: golangci-lint run ./...\n [ ] No beads pollution: check .beads/issues.jsonl diff\n [ ] Nix hash current: go.sum unchanged or vendorHash updated\n [ ] Version sync: version.go matches default.nix\n\n Run 'bd preflight --check' to validate automatically.\n\n### Tier 2: Check Mode (v2)\n\n $ bd preflight --check\n ✓ Tests pass\n ✓ Lint passes\n ⚠ Beads pollution: 3 issues in diff - are these project issues or personal?\n ✗ Nix hash stale: go.sum changed, vendorHash needs update\n Fix: sha256-KRR6dXzsSw8OmEHGBEVDBOoIgfoZ2p0541T9ayjGHlI=\n ✓ Version sync\n\n 1 error, 1 warning. Run 'bd preflight --fix' to auto-fix where possible.\n\n### Tier 3: Fix Mode (v3)\n\n $ bd preflight --fix\n ✓ Updated vendorHash in default.nix\n ⚠ Cannot auto-fix beads pollution - manual review needed\n\n## Checks to Implement\n\n| Check | Description | Auto-fixable |\n|-------|-------------|--------------|\n| tests | Run go test -short ./... | No |\n| lint | Run golangci-lint | Partial (gofmt) |\n| beads-pollution | Detect personal issues in diff | No (see bd-umbf) |\n| nix-hash | Detect stale vendorHash | Yes (if nix available) |\n| version-sync | version.go matches default.nix | Yes |\n| no-debug | No TODO/FIXME/console.log | Warn only |\n| clean-stage | No unintended files staged | Warn only |\n\n## Future: Configuration\n\nMake checks configurable per-project via .beads/preflight.yaml:\n\n preflight:\n checks:\n - name: tests\n run: go test -short ./...\n required: true\n - name: no-secrets\n pattern: \"**/*.env\"\n staged: deny\n - name: custom-check\n run: ./scripts/validate.sh\n\nThis lets any project using beads define their own preflight checks.\n\n## Implementation Phases\n\n### Phase 1: Static Checklist\n- Implement bd preflight with hardcoded checklist for beads\n- No execution, just prints what to check\n- Update CONTRIBUTING.md to reference it\n\n### Phase 2: Automated Checks\n- Implement bd preflight --check\n- Run tests, lint, detect stale hashes\n- Clear pass/fail/warn output\n\n### Phase 3: Auto-fix\n- Implement bd preflight --fix\n- Fix vendorHash, version sync\n- Integrate with bd-umbf solution for pollution\n\n### Phase 4: Configuration\n- .beads/preflight.yaml support\n- Make it useful for other projects using beads\n- Plugin/hook system for custom checks\n\n## Dependencies\n\n- bd-umbf: Namespace isolation for beads pollution (blocking for full solution)\n\n## Success Metrics\n\n- Fewer CI failures on first PR push\n- Reduced \"fix nix hash\" commits\n- Contributors report preflight caught issues before CI","status":"open","priority":2,"issue_type":"epic","created_at":"2025-12-13T18:01:39.587078-08:00","updated_at":"2025-12-13T18:01:39.587078-08:00","dependencies":[{"issue_id":"bd-lfak","depends_on_id":"bd-umbf","type":"blocks","created_at":"2025-12-13T18:01:46.059901-08:00","created_by":"daemon","metadata":"{}"}]}
|
||||
{"id":"bd-llfl","title":"Improve test coverage for cmd/bd CLI (26.2% → 50%)","description":"The main CLI package (cmd/bd) has only 26.2% test coverage. CLI commands should have at least 50% coverage to ensure reliability.\n\nKey areas with low/no coverage:\n- daemon_autostart.go (multiple 0% functions)\n- compact.go (several 0% functions)\n- Various command handlers\n\nCurrent coverage: 26.2%\nTarget coverage: 50%","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-13T20:43:03.123341-08:00","updated_at":"2025-12-13T21:01:18.901944-08:00"}
|
||||
{"id":"bd-lo4","title":"Test pinned issue","status":"tombstone","priority":2,"issue_type":"task","created_at":"2025-12-18T21:44:49.031385-08:00","updated_at":"2025-12-18T21:47:25.055109-08:00","deleted_at":"2025-12-18T21:47:25.055109-08:00","deleted_by":"daemon","delete_reason":"delete","original_type":"task"}
|
||||
{"id":"bd-lq2o","title":"Rebuild local binary","description":"Build and verify: go build -o bd ./cmd/bd \u0026\u0026 ./bd version","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-21T16:10:13.759506-08:00","updated_at":"2025-12-21T16:10:13.759506-08:00","dependencies":[{"issue_id":"bd-lq2o","depends_on_id":"bd-bs5j","type":"parent-child","created_at":"2025-12-21T16:10:13.762851-08:00","created_by":"stevey"},{"issue_id":"bd-lq2o","depends_on_id":"bd-oy6c","type":"blocks","created_at":"2025-12-21T16:10:13.763375-08:00","created_by":"stevey"}],"wisp":true}
|
||||
{"id":"bd-lq2o","title":"Rebuild local binary","description":"Build and verify: go build -o bd ./cmd/bd \u0026\u0026 ./bd version","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-21T16:10:13.759506-08:00","updated_at":"2025-12-21T17:19:21.253342-08:00","closed_at":"2025-12-21T17:19:21.253342-08:00","close_reason":"Binary builds and runs correctly","dependencies":[{"issue_id":"bd-lq2o","depends_on_id":"bd-bs5j","type":"parent-child","created_at":"2025-12-21T16:10:13.762851-08:00","created_by":"stevey"},{"issue_id":"bd-lq2o","depends_on_id":"bd-oy6c","type":"blocks","created_at":"2025-12-21T16:10:13.763375-08:00","created_by":"stevey"}],"wisp":true}
|
||||
{"id":"bd-lsv4","title":"GH#444: Fix inconsistent status naming in_progress vs in-progress","description":"Documentation uses in-progress (hyphen) but code expects in_progress (underscore). Update all docs to use canonical in_progress. See GitHub issue #444.","status":"tombstone","priority":2,"issue_type":"bug","created_at":"2025-12-16T01:03:14.349425-08:00","updated_at":"2025-12-17T16:11:17.070763-08:00","deleted_at":"2025-12-17T16:11:17.070763-08:00","deleted_by":"batch delete","delete_reason":"batch delete","original_type":"bug"}
|
||||
{"id":"bd-lw0x","title":"Fix bd sync race condition with daemon causing dirty working directory","description":"After bd sync completes with sync.branch mode, subsequent bd commands or daemon file watcher would see a hash mismatch and trigger auto-import, which then schedules re-export, dirtying the working directory.\n\n**Root cause:**\n1. bd sync exports JSONL with NEW content (hash H1)\n2. bd sync updates jsonl_content_hash = H1 in DB\n3. bd sync restores JSONL from HEAD (OLD content, hash H0)\n4. Now: file hash = H0, DB hash = H1 (MISMATCH)\n5. Daemon or next CLI command sees mismatch, imports from OLD JSONL\n6. Import triggers re-export → file is dirty\n\n**Fix:**\nAfter restoreBeadsDirFromBranch(), update jsonl_content_hash to match the restored file's hash. This ensures daemon and CLI see file hash = DB hash → no spurious import/export cycle.\n\nRelated: bd-c83r (multiple daemon prevention)","status":"closed","priority":2,"issue_type":"bug","created_at":"2025-12-13T06:42:17.130839-08:00","updated_at":"2025-12-13T06:43:33.329042-08:00","closed_at":"2025-12-13T06:43:33.329042-08:00"}
|
||||
{"id":"bd-lxzx","title":"Add close_reason to JSONL export format documentation","description":"PR #551 now persists close_reason to the database, but there's a question about whether this field should be exported to JSONL format.\n\n## Current State\n- close_reason is stored in issues.close_reason column\n- close_reason is also stored in events table (audit trail)\n- The JSONL export format may or may not include close_reason\n\n## Questions\n1. Should close_reason be exported to JSONL format?\n2. If yes, where should it go (root level or nested in events)?\n3. Should there be any special handling to avoid duplication?\n4. How should close_reason be handled during JSONL import?\n\n## Why This Matters\n- JSONL is the git-friendly sync format\n- Other beads instances import from JSONL\n- close_reason is meaningful data that should be preserved across clones\n\n## Suggested Action\n- Check if close_reason is currently exported in JSONL\n- If not, add it to the export schema\n- Document the field in JSONL format spec\n- Add tests for round-trip (export -\u003e import -\u003e verify close_reason)","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-14T14:25:17.414916-08:00","updated_at":"2025-12-14T14:25:17.414916-08:00","dependencies":[{"issue_id":"bd-lxzx","depends_on_id":"bd-z86n","type":"discovered-from","created_at":"2025-12-14T14:25:17.416131-08:00","created_by":"stevey","metadata":"{}"}]}
|
||||
@@ -265,14 +265,14 @@
|
||||
{"id":"bd-n386","title":"Improve test coverage for internal/daemon (27.3% → 60%)","description":"The daemon package has only 27.3% test coverage. The daemon is critical for background operations and reliability.\n\nKey areas needing tests:\n- Daemon autostart logic\n- Socket handling\n- PID file management\n- Health checks\n\nCurrent coverage: 27.3%\nTarget coverage: 60%","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-13T20:43:00.895238-08:00","updated_at":"2025-12-13T21:01:17.274438-08:00"}
|
||||
{"id":"bd-n3v","title":"Error committing to sync branch: failed to create worktree","description":"\u003e bd sync --no-daemon\n→ Exporting pending changes to JSONL...\n→ Committing changes to sync branch 'beads-sync'...\nError committing to sync branch: failed to create worktree: failed to create worktree parent directory: mkdir /var/home/matt/dev/beads/fix-ci/.git: not a directory","notes":"**Problem Diagnosed**: The `bd sync` command was failing with \"mkdir /var/home/matt/dev/beads/fix-ci/.git: not a directory\" because it was being executed from the wrong directory.\n\n**Root Cause**: The command was run from `/var/home/matt/dev/beads` (where the `fix-ci` worktree exists) instead of the main repository directory `/var/home/matt/dev/beads/main`. Since `fix-ci` is a git worktree with a `.git` file (not directory), the worktree creation logic failed when trying to create `\u003ccurrent_dir\u003e/.git/beads-worktrees/\u003cbranch\u003e`.\n\n**Solution Verified**: Execute `bd sync` from the main repository directory:\n```bash\ncd main \u0026\u0026 bd sync --dry-run\n```\n","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-05T15:25:24.514998248-07:00","updated_at":"2025-12-05T15:42:32.910166956-07:00"}
|
||||
{"id":"bd-n4td","title":"Add warning when staleness check errors","description":"## Problem\n\nWhen ensureDatabaseFresh() calls CheckStaleness() and it errors (corrupted metadata, permission issues, etc.), we silently proceed with potentially stale data.\n\n**Location:** cmd/bd/staleness.go:27-32\n\n**Scenarios:**\n- Corrupted metadata table\n- Database locked by another process \n- Permission issues reading JSONL file\n- Invalid last_import_time format in DB\n\n## Current Code\n\n```go\nisStale, err := autoimport.CheckStaleness(ctx, store, dbPath)\nif err \\!= nil {\n // If we can't determine staleness, allow operation to proceed\n // (better to show potentially stale data than block user)\n return nil\n}\n```\n\n## Fix\n\n```go\nisStale, err := autoimport.CheckStaleness(ctx, store, dbPath)\nif err \\!= nil {\n fmt.Fprintf(os.Stderr, \"Warning: Could not verify database freshness: %v\\n\", err)\n fmt.Fprintf(os.Stderr, \"Proceeding anyway. Data may be stale.\\n\\n\")\n return nil\n}\n```\n\n## Impact\nMedium - users should know when staleness check fails\n\n## Effort\nEasy - 5 minutes","status":"closed","priority":2,"issue_type":"bug","created_at":"2025-11-20T20:16:34.889997-05:00","updated_at":"2025-12-17T23:13:40.531031-08:00","closed_at":"2025-12-17T19:11:12.950618-08:00","dependencies":[{"issue_id":"bd-n4td","depends_on_id":"bd-2q6d","type":"blocks","created_at":"2025-11-20T20:18:20.154723-05:00","created_by":"stevey","metadata":"{}"}]}
|
||||
{"id":"bd-n777","title":"Timer beads for scheduled agent callbacks","description":"## Problem\n\nAgents frequently need to wait for external events (CI completion, PR reviews, artifact builds) but have no good mechanism:\n- `sleep N` blocks and is unreliable (often times out at 8+ minutes)\n- Polling wastes context and is easy to forget\n- No way to survive session restarts\n\n## Proposal: Timer Beads\n\nA new bead type or field that represents a scheduled callback:\n\n### Creating timers\n```bash\nbd timer create --in 30s --callback \"Check CI run 12345\" --issue bd-xyz\nbd timer create --at \"2025-12-20T08:00:00\" --callback \"Morning standup\"\nbd timer create --in 5m --on-expire \"tmux send-keys -t dave 'bd show bd-xyz'\"\n```\n\n### Timer storage\n- Store in beads (survives restarts)\n- Fields: `expires_at`, `callback_description`, `on_expire_command`, `linked_issue`\n- Status: pending, fired, cancelled\n\n### Deacon integration\nThe Deacon daemon monitors timer beads:\n1. Wakes on next timer expiry\n2. Executes `on_expire` command (e.g., tmux send-keys to interrupt agent)\n3. Marks timer as fired\n4. Optionally updates linked issue\n\n### Use cases\n- CI monitoring: \"ping me when build completes\"\n- PR reviews: \"check back in 1 hour\"\n- Scheduled tasks: \"remind me at EOD to sync\"\n- Blocking waits: agent registers callback instead of sleeping\n\n## Acceptance criteria\n- [ ] Timer bead type or field design\n- [ ] `bd timer create/list/cancel` commands\n- [ ] Deacon timer monitoring loop\n- [ ] tmux integration for agent interrupts\n- [ ] Survives daemon restarts","status":"open","priority":2,"issue_type":"feature","created_at":"2025-12-19T23:05:33.051861-08:00","updated_at":"2025-12-19T23:05:33.051861-08:00"}
|
||||
{"id":"bd-n777","title":"Timer beads for scheduled agent callbacks","description":"## Problem\n\nAgents frequently need to wait for external events (CI completion, PR reviews, artifact builds) but have no good mechanism:\n- `sleep N` blocks and is unreliable (often times out at 8+ minutes)\n- Polling wastes context and is easy to forget\n- No way to survive session restarts\n\n## Proposal: Timer Beads\n\nA new bead type or field that represents a scheduled callback:\n\n### Creating timers\n```bash\nbd timer create --in 30s --callback \"Check CI run 12345\" --issue bd-xyz\nbd timer create --at \"2025-12-20T08:00:00\" --callback \"Morning standup\"\nbd timer create --in 5m --on-expire \"tmux send-keys -t dave 'bd show bd-xyz'\"\n```\n\n### Timer storage\n- Store in beads (survives restarts)\n- Fields: `expires_at`, `callback_description`, `on_expire_command`, `linked_issue`\n- Status: pending, fired, cancelled\n\n### Deacon integration\nThe Deacon daemon monitors timer beads:\n1. Wakes on next timer expiry\n2. Executes `on_expire` command (e.g., tmux send-keys to interrupt agent)\n3. Marks timer as fired\n4. Optionally updates linked issue\n\n### Use cases\n- CI monitoring: \"ping me when build completes\"\n- PR reviews: \"check back in 1 hour\"\n- Scheduled tasks: \"remind me at EOD to sync\"\n- Blocking waits: agent registers callback instead of sleeping\n\n## Acceptance criteria\n- [ ] Timer bead type or field design\n- [ ] `bd timer create/list/cancel` commands\n- [ ] Deacon timer monitoring loop\n- [ ] tmux integration for agent interrupts\n- [ ] Survives daemon restarts","status":"closed","priority":2,"issue_type":"feature","created_at":"2025-12-19T23:05:33.051861-08:00","updated_at":"2025-12-21T17:19:48.087482-08:00","closed_at":"2025-12-21T17:19:48.087482-08:00","close_reason":"Will not implement - Gas Town uses a different approach for timed events"}
|
||||
{"id":"bd-ncwo","title":"Ghost resurrection: remote status:closed wins during git merge","description":"During bd sync, the 3-way git merge sometimes keeps remote's status:closed instead of local's status:tombstone. This causes ghost issues to resurrect even when tombstones exist.\n\nRoot cause: Git 3-way merge doesn't understand tombstone semantics. If base had closed, local changed to tombstone, and remote has closed, git might keep remote's version.\n\nThe early tombstone check in importer.go only prevents CREATION when tombstones exist in DB. But if applyDeletionsFromMerge hard-deletes the tombstones before import runs (because they're not in the merged result), the check doesn't help.\n\nPotential fixes:\n1. Make tombstones 'win' in the beads merge driver (internal/merge/merge.go)\n2. Don't hard-delete tombstones in applyDeletionsFromMerge if they're in the DB\n3. Export tombstones to a separate file that's not subject to merge\n\nGhost issues: bd-cb64c226.*, bd-cbed9619.*","status":"tombstone","priority":1,"issue_type":"bug","created_at":"2025-12-16T22:01:03.56423-08:00","updated_at":"2025-12-17T16:11:17.070763-08:00","deleted_at":"2025-12-17T16:11:17.070763-08:00","deleted_by":"batch delete","delete_reason":"batch delete","original_type":"bug"}
|
||||
{"id":"bd-ndye","title":"mergeDependencies uses union instead of 3-way merge","description":"## Critical Bug\n\nThe `mergeDependencies` function in internal/merge/merge.go performs a UNION of left and right dependencies instead of a proper 3-way merge. This causes removed dependencies to be resurrected.\n\n### Root Cause\n\n```go\n// Current code (lines 795-816):\nfunc mergeDependencies(left, right []Dependency) []Dependency {\n // Just unions left + right\n // NEVER REMOVES anything\n // Doesn't even look at base!\n}\n```\n\nAnd `mergeIssue` (line 579) doesn't pass `base`:\n```go\nresult.Dependencies = mergeDependencies(left.Dependencies, right.Dependencies)\n```\n\n### Impact\n\nIf:\n- Base has dependency D\n- Left removes D (intentional)\n- Right still has D (stale)\n\nCurrent: D is in result (resurrection!)\nCorrect: Left removed it, D should NOT be in result\n\nThis breaks Gas Town's workflow and data integrity. Closed means closed.\n\n### Fix\n\nChange `mergeDependencies` to take `base` and do proper 3-way merge:\n- If dep was in base and removed by left → exclude (left wins)\n- If dep was in base and removed by right → exclude (right wins)\n- If dep wasn't in base and added by either → include\n- If dep was in base and both still have it → include\n\nKey principle: **REMOVALS ARE AUTHORITATIVE**\n\n### Files to Change\n\n1. internal/merge/merge.go:\n - `mergeDependencies(left, right)` → `mergeDependencies(base, left, right)`\n - `mergeIssue` line 579: pass `base.Dependencies`\n\n### Related\n\nThis also explains why `ProtectLocalExportIDs` in importer is defined but never used - the protection was never actually implemented.","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-12-18T23:15:54.475872-08:00","updated_at":"2025-12-18T23:21:10.709571-08:00","closed_at":"2025-12-18T23:21:10.709571-08:00"}
|
||||
{"id":"bd-nl2","title":"No logging/debugging for tombstone resurrection events","description":"Per the design document bd-zvg Open Question 1: Should resurrection log a warning? Recommendation was Yes. Currently, when an expired tombstone loses to a live issue (resurrection), there is no logging or debugging output. This makes it hard to understand why an issue reappeared. Recommendation: Add optional debug logging when resurrection occurs, e.g., Issue bd-abc resurrected (tombstone expired). Files: internal/merge/merge.go:359-366, 371-378, 400-405, 410-415","status":"open","priority":4,"issue_type":"feature","created_at":"2025-12-05T16:36:52.27525-08:00","updated_at":"2025-12-05T16:36:52.27525-08:00"}
|
||||
{"id":"bd-nuh1","title":"GH#403: bd doctor --fix circular error message","description":"bd doctor --fix suggests running bd doctor --fix for deletions manifest issue. Fix to provide actual resolution. See GitHub issue #403.","status":"tombstone","priority":2,"issue_type":"bug","created_at":"2025-12-16T01:03:16.290018-08:00","updated_at":"2025-12-17T16:11:17.070763-08:00","deleted_at":"2025-12-17T16:11:17.070763-08:00","deleted_by":"batch delete","delete_reason":"batch delete","original_type":"bug"}
|
||||
{"id":"bd-o4qy","title":"Improve CheckStaleness error handling","description":"## Problem\n\nCheckStaleness returns 'false' (not stale) for multiple error conditions instead of returning errors. This masks problems.\n\n**Location:** internal/autoimport/autoimport.go:253-285\n\n## Edge Cases That Return False\n\n1. **Invalid last_import_time format** (line 259-262)\n2. **No JSONL file found** (line 267-277) \n3. **JSONL stat fails** (line 279-282)\n\n## Fix\n\nReturn errors for abnormal conditions:\n\n```go\nlastImportTime, err := time.Parse(time.RFC3339, lastImportStr)\nif err != nil {\n return false, fmt.Errorf(\"corrupted last_import_time: %w\", err)\n}\n\nif jsonlPath == \"\" {\n return false, fmt.Errorf(\"no JSONL file found\")\n}\n\nstat, err := os.Stat(jsonlPath)\nif err != nil {\n return false, fmt.Errorf(\"cannot stat JSONL: %w\", err)\n}\n```\n\n## Impact\nMedium - edge cases are rare but should be handled\n\n## Effort \n30 minutes - requires updating callers in RPC server","status":"closed","priority":2,"issue_type":"bug","created_at":"2025-11-20T20:17:27.606219-05:00","updated_at":"2025-12-17T23:13:40.536905-08:00","closed_at":"2025-12-17T19:11:12.965289-08:00","dependencies":[{"issue_id":"bd-o4qy","depends_on_id":"bd-2q6d","type":"blocks","created_at":"2025-11-20T20:18:26.81065-05:00","created_by":"stevey","metadata":"{}"}]}
|
||||
{"id":"bd-o55a","title":"GH#509: bd doesn't find .beads when running from nested worktrees","description":"When worktrees are nested under main repo (.worktrees/feature/), bd stops at worktree git root instead of continuing to find .beads in parent. See GitHub issue #509 for detailed fix suggestion.","status":"tombstone","priority":2,"issue_type":"bug","created_at":"2025-12-16T01:03:20.281591-08:00","updated_at":"2025-12-17T16:11:17.070763-08:00","deleted_at":"2025-12-17T16:11:17.070763-08:00","deleted_by":"batch delete","delete_reason":"batch delete","original_type":"bug"}
|
||||
{"id":"bd-o5xe","title":"Molecule bonding: composable workflow templates","description":"Vision: Molecules should be composable like LEGO bricks or Mad Max war rig sections. Bonding lets you attach molecules together to create compound workflows.\n\nTHREE BONDING CONTEXTS:\n1. Template-time: bd mol bond A B → Create reusable compound proto\n2. Spawn-time: bd mol spawn A --attach B → Attach modules when instantiating \n3. Runtime: bd mol attach epic B → Add to running workflow\n\nBOND TYPES:\n- Sequential: B after A completes (feature → deploy)\n- Parallel: B runs alongside A (feature + docs)\n- Conditional: B only if A fails (feature → hotfix)\n\nBOND POINTS (Attachment Sites):\n- Default: B depends on A root epic completion\n- Explicit: --after issue-id for specific attachment\n- Future: Named bond points in proto definitions\n\nVARIABLE FLOW:\n- Shared namespace between bonded molecules\n- Warn on variable name conflicts\n- Future: explicit mapping with --map\n\nDATA MODEL: Issues track bonded_from to preserve compound lineage.\n\nSUCCESS CRITERIA:\n- Can bond two protos into a compound proto\n- Can spawn with --attach for on-the-fly composition\n- Can attach molecules to running workflows\n- Compound structure visible in bd mol show\n- Variables flow correctly between bonded molecules","design":"SIMPLIFIED API (per design review):\n\nCORE COMMANDS:\n- bd mol spawn \u003cproto\u003e - Instantiate proto → molecule\n- bd mol bond \u003cA\u003e \u003cB\u003e - Polymorphic bonding (any combination)\n- bd mol distill \u003cmol\u003e - Extract molecule → proto\n- bd mol show/catalog - Inspect\n\nBOND IS POLYMORPHIC:\n| bond A B | Result |\n|---------------|-------------------------------------|\n| proto + proto | compound proto |\n| proto + mol | spawn proto, attach to mol |\n| mol + proto | spawn proto, attach to mol |\n| mol + mol | join into compound molecule |\n\nBOND TYPES: sequential (default), parallel, conditional\n\nTERMINOLOGY:\n- Proto: Uninstantiated template (easter egg: 'protomolecule')\n- Molecule: Spawned instance of a proto\n- Compound: Result of bonding (proto or molecule)\n- Distill: Extract proto from ad-hoc epic","status":"open","priority":1,"issue_type":"epic","created_at":"2025-12-21T00:58:35.479009-08:00","updated_at":"2025-12-21T01:10:24.298798-08:00"}
|
||||
{"id":"bd-o5xe","title":"Molecule bonding: composable workflow templates","description":"Vision: Molecules should be composable like LEGO bricks or Mad Max war rig sections. Bonding lets you attach molecules together to create compound workflows.\n\nTHREE BONDING CONTEXTS:\n1. Template-time: bd mol bond A B → Create reusable compound proto\n2. Spawn-time: bd mol spawn A --attach B → Attach modules when instantiating \n3. Runtime: bd mol attach epic B → Add to running workflow\n\nBOND TYPES:\n- Sequential: B after A completes (feature → deploy)\n- Parallel: B runs alongside A (feature + docs)\n- Conditional: B only if A fails (feature → hotfix)\n\nBOND POINTS (Attachment Sites):\n- Default: B depends on A root epic completion\n- Explicit: --after issue-id for specific attachment\n- Future: Named bond points in proto definitions\n\nVARIABLE FLOW:\n- Shared namespace between bonded molecules\n- Warn on variable name conflicts\n- Future: explicit mapping with --map\n\nDATA MODEL: Issues track bonded_from to preserve compound lineage.\n\nSUCCESS CRITERIA:\n- Can bond two protos into a compound proto\n- Can spawn with --attach for on-the-fly composition\n- Can attach molecules to running workflows\n- Compound structure visible in bd mol show\n- Variables flow correctly between bonded molecules","design":"SIMPLIFIED API (per design review):\n\nCORE COMMANDS:\n- bd mol spawn \u003cproto\u003e - Instantiate proto → molecule\n- bd mol bond \u003cA\u003e \u003cB\u003e - Polymorphic bonding (any combination)\n- bd mol distill \u003cmol\u003e - Extract molecule → proto\n- bd mol show/catalog - Inspect\n\nBOND IS POLYMORPHIC:\n| bond A B | Result |\n|---------------|-------------------------------------|\n| proto + proto | compound proto |\n| proto + mol | spawn proto, attach to mol |\n| mol + proto | spawn proto, attach to mol |\n| mol + mol | join into compound molecule |\n\nBOND TYPES: sequential (default), parallel, conditional\n\nTERMINOLOGY:\n- Proto: Uninstantiated template (easter egg: 'protomolecule')\n- Molecule: Spawned instance of a proto\n- Compound: Result of bonding (proto or molecule)\n- Distill: Extract proto from ad-hoc epic","status":"closed","priority":1,"issue_type":"epic","created_at":"2025-12-21T00:58:35.479009-08:00","updated_at":"2025-12-21T17:19:45.871164-08:00","closed_at":"2025-12-21T17:19:45.871164-08:00","close_reason":"All core bonding features implemented (6/7 children closed, 1 deferred for future polish)"}
|
||||
{"id":"bd-o7ik","title":"Priority: refactor mol.go then bd squash","description":"Two tasks:\n\n1. bd-cnwx - Refactor mol.go (1200+ lines, split by subcommand)\n2. bd-2vh3 - Ephemeral cleanup (bd cleanup --ephemeral)\n\nRefactor first - smaller, unblocks easier review of future mol work.\n\n- Mayor","status":"closed","priority":2,"issue_type":"message","assignee":"beads-dave","created_at":"2025-12-21T11:31:38.287244-08:00","updated_at":"2025-12-21T12:59:32.937472-08:00","closed_at":"2025-12-21T12:59:32.937472-08:00","close_reason":"mol.go refactor (bd-cnwx) done. Epic bd-2vh3 now has 5 tiered implementation tasks with dependencies."}
|
||||
{"id":"bd-o91r","title":"Polymorphic bond command: bd mol bond A B","description":"Implement proto-to-proto bonding to create compound protos.\n\nCOMMAND: bd mol bond proto-feature proto-testing [--as proto-feature-tested] [--type sequential]\n\nBEHAVIOR:\n- Load both proto subgraphs\n- Create new compound proto with combined structure\n- B's root becomes child of A's root (sequential) or sibling (parallel)\n- Wire dependencies: B depends on A's leaf nodes (sequential) or runs parallel\n- Store bonded_from metadata for lineage tracking\n\nFLAGS:\n- --as NAME: Custom ID for compound proto (default: generates hash)\n- --type: sequential (default) or parallel\n- --dry-run: Preview compound structure\n\nOUTPUT:\n- New compound proto in catalog\n- Shows combined variable requirements","notes":"UPDATE: bond is now polymorphic - handles proto+proto, proto+mol, and mol+mol based on operand types. Separate 'attach' command eliminated.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-21T00:58:55.604705-08:00","updated_at":"2025-12-21T10:10:25.385995-08:00","closed_at":"2025-12-21T10:10:25.385995-08:00","close_reason":"Implemented in commit f0df4070","dependencies":[{"issue_id":"bd-o91r","depends_on_id":"bd-o5xe","type":"parent-child","created_at":"2025-12-21T00:59:51.30026-08:00","created_by":"daemon"},{"issue_id":"bd-o91r","depends_on_id":"bd-mh4w","type":"blocks","created_at":"2025-12-21T00:59:51.569391-08:00","created_by":"daemon"},{"issue_id":"bd-o91r","depends_on_id":"bd-rnnr","type":"blocks","created_at":"2025-12-21T00:59:51.652397-08:00","created_by":"daemon"}]}
|
||||
{"id":"bd-o9o","title":"Exclude pinned issues from bd ready","description":"Update bd ready to exclude pinned issues. Pinned issues are context markers, not work items, and should never appear in the ready-to-work list.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-18T23:33:41.979073-08:00","updated_at":"2025-12-21T11:29:41.190567-08:00","closed_at":"2025-12-21T11:29:41.190567-08:00","close_reason":"Already implemented in SQLite (line 18). Added memory storage exclusion for completeness.","dependencies":[{"issue_id":"bd-o9o","depends_on_id":"bd-0vg","type":"blocks","created_at":"2025-12-18T23:33:56.392931-08:00","created_by":"daemon"},{"issue_id":"bd-o9o","depends_on_id":"bd-7h5","type":"blocks","created_at":"2025-12-18T23:34:07.612655-08:00","created_by":"daemon"}]}
|
||||
|
||||
Reference in New Issue
Block a user