johno/beads
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

bd sync: 2025-12-28 21:43:56

Browse Source
This commit is contained in:
Steve Yegge
2025-12-28 21:43:56 -08:00
parent cb601d661e
commit 68ffda0fc0
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.beads/issues.jsonl
View File

@@ -443,7 +443,7 @@
{"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":"{}"}]}
{"id":"bd-lz49","title":"Add gate fields: await_type, await_id, timeout, waiters","description":"Add gate-specific fields to the Issue type.\n\n## New Fields\n- await_type: string - Type of condition (gh:run, gh:pr, timer, human, mail)\n- await_id: string - Identifier for the condition\n- timeout: duration - Max time to wait before escalation\n- waiters: []string - Mail addresses to notify when gate clears\n\n## Implementation\n- Add fields to Issue struct in internal/types/types.go\n- Update SQLite schema for new columns\n- Add JSONL serialization/deserialization\n- Update import/export logic","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-23T11:44:32.720196-08:00","updated_at":"2025-12-23T12:00:03.837691-08:00","closed_at":"2025-12-23T12:00:03.837691-08:00","close_reason":"Gate fields added to Issue struct, ComputeContentHash, SQLite migration created, all storage queries updated","dependencies":[{"issue_id":"bd-lz49","depends_on_id":"bd-udsi","type":"parent-child","created_at":"2025-12-23T11:44:52.738823-08:00","created_by":"daemon"},{"issue_id":"bd-lz49","depends_on_id":"bd-2v0f","type":"blocks","created_at":"2025-12-23T11:44:56.269351-08:00","created_by":"daemon"}]}
{"id":"bd-m0tl","title":"bd create -f crashes with nil pointer dereference","description":"GitHub issue #674. The markdown import feature crashes at markdown.go:338 because global variables (store, ctx, actor) aren't initialized when createIssuesFromMarkdown is called. The function uses globals set by cobra command framework but is being called before they're ready. Need to either initialize globals at start of function or pass them as parameters.","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-12-21T14:35:14.813012-08:00","updated_at":"2025-12-21T15:41:14.600953-08:00","closed_at":"2025-12-21T15:41:14.600953-08:00","close_reason":"Fixed: added nil check for store in createIssuesFromMarkdown"}
{"id":"bd-m6r3","title":"Refactor: Extract shared getEpicChildren helper for swarm commands","description":"## Context\n`getSwarmStatus` and `analyzeEpicForSwarm` in cmd/bd/swarm.go have nearly identical code for:\n- Getting epic dependents via GetDependents\n- Filtering to parent-child relationships\n- Building childIDSet map\n- Building dependency maps\n\n## Implementation\n1. Extract `getEpicChildren(ctx, store, epicID)` that returns:\n - `[]*types.Issue` - child issues\n - `map[string]bool` - child ID set\n - `map[string][]string` - dependency map (within children)\n - `error`\n\n2. Refactor both `analyzeEpicForSwarm` and `getSwarmStatus` to use it\n\n3. Consider defining a named interface for the store methods:\n ```go\n type SwarmStore interface {\n GetIssue(context.Context, string) (*types.Issue, error)\n GetDependents(context.Context, string) ([]*types.Issue, error)\n GetDependencyRecords(context.Context, string) ([]*types.Dependency, error)\n }\n ```\n\n## Files\n- cmd/bd/swarm.go (lines 150-248, 616-682)\n\n## Acceptance\n- No duplicated code for fetching epic children\n- Both commands produce identical results as before","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T21:30:55.55377-08:00","created_by":"beads/crew/emma","updated_at":"2025-12-28T21:30:55.55377-08:00"}
{"id":"bd-m6r3","title":"Refactor: Extract shared getEpicChildren helper for swarm commands","description":"## Context\n`getSwarmStatus` and `analyzeEpicForSwarm` in cmd/bd/swarm.go have nearly identical code for:\n- Getting epic dependents via GetDependents\n- Filtering to parent-child relationships\n- Building childIDSet map\n- Building dependency maps\n\n## Implementation\n1. Extract `getEpicChildren(ctx, store, epicID)` that returns:\n - `[]*types.Issue` - child issues\n - `map[string]bool` - child ID set\n - `map[string][]string` - dependency map (within children)\n - `error`\n\n2. Refactor both `analyzeEpicForSwarm` and `getSwarmStatus` to use it\n\n3. Consider defining a named interface for the store methods:\n ```go\n type SwarmStore interface {\n GetIssue(context.Context, string) (*types.Issue, error)\n GetDependents(context.Context, string) ([]*types.Issue, error)\n GetDependencyRecords(context.Context, string) ([]*types.Dependency, error)\n }\n ```\n\n## Files\n- cmd/bd/swarm.go (lines 150-248, 616-682)\n\n## Acceptance\n- No duplicated code for fetching epic children\n- Both commands produce identical results as before","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-28T21:30:55.55377-08:00","created_by":"beads/crew/emma","updated_at":"2025-12-28T21:43:50.759453-08:00","closed_at":"2025-12-28T21:43:50.759453-08:00","close_reason":"Extracted getEpicChildren helper, refactored analyzeEpicForSwarm and getSwarmStatus to use it"}
{"id":"bd-m7ib","title":"Add creator field to Issue struct","description":"Add Creator *EntityRef field to Issue. Tracks who created the issue. Optional, omitted if nil in JSONL. This enables CV chain tracking - every piece of work is attributed to its creator.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-22T17:53:31.599447-08:00","updated_at":"2025-12-22T20:03:24.264672-08:00","closed_at":"2025-12-22T20:03:24.264672-08:00","close_reason":"Added Creator *EntityRef field to Issue struct. Included in content hash. Test coverage added.","dependencies":[{"issue_id":"bd-m7ib","depends_on_id":"bd-7pwh","type":"parent-child","created_at":"2025-12-22T17:53:43.39957-08:00","created_by":"daemon"},{"issue_id":"bd-m7ib","depends_on_id":"bd-nmch","type":"blocks","created_at":"2025-12-22T17:53:47.826309-08:00","created_by":"daemon"}]}
{"id":"bd-m8ro","title":"Improve test coverage for internal/rpc (47.5% → 60%)","description":"The RPC package has only 47.5% test coverage. RPC is the communication layer for daemon operations.\n\nCurrent coverage: 47.5%\nTarget coverage: 60%","status":"closed","priority":2,"issue_type":"task","assignee":"beads/delta","created_at":"2025-12-13T20:43:09.515299-08:00","updated_at":"2025-12-23T22:42:11.921388-08:00","closed_at":"2025-12-23T22:42:11.921388-08:00","close_reason":"Improved test coverage from 44.7% to 61.7% by adding comprehensive tests for Count, ResolveID, Delete, Stale, Comment, Metrics, Gate operations, Export, GetMutations, and MutationChan"}
{"id":"bd-m964","title":"Consider FTS5 for text search at scale","description":"SearchIssues uses LIKE patterns for text search which can't use indexes.\n\n**Current query (queries.go:1475-1477):**\n```sql\n(title LIKE ? OR description LIKE ? OR id LIKE ?)\n```\n\n**Problem:** Full table scan on every text search. At 100K+ issues, this becomes slow.\n\n**SQLite FTS5 solution:**\n```sql\nCREATE VIRTUAL TABLE issues_fts USING fts5(\n id, title, description, design, notes,\n content='issues',\n content_rowid='rowid'\n);\n\n-- Triggers to keep FTS in sync\nCREATE TRIGGER issues_ai AFTER INSERT ON issues BEGIN\n INSERT INTO issues_fts(rowid, id, title, description, design, notes)\n VALUES (new.rowid, new.id, new.title, new.description, new.design, new.notes);\nEND;\n-- (similar for UPDATE, DELETE)\n```\n\n**Trade-offs:**\n- Database size increase (~30-50% for text content)\n- Additional write overhead (trigger execution)\n- Better search capabilities (ranking, phrase search)\n\n**Decision needed:** Is full-text search a priority feature? Current LIKE search may be acceptable for most use cases.\n\n**Benchmark first:** Measure SearchIssues at 100K scale before implementing.","status":"open","priority":4,"issue_type":"feature","created_at":"2025-12-22T22:58:56.466121-08:00","updated_at":"2025-12-22T22:58:56.466121-08:00","dependencies":[{"issue_id":"bd-m964","depends_on_id":"bd-h0we","type":"discovered-from","created_at":"2025-12-22T22:58:56.466764-08:00","created_by":"daemon"}]}