bd sync: 2025-12-22 12:19:36
This commit is contained in:
@@ -83,7 +83,7 @@
|
||||
{"id":"gt-480b","title":"Improve test coverage in low-coverage packages","description":"Several packages have low test coverage:\n- internal/cmd: 6.8%\n- internal/mail: 3.6%\n- internal/daemon: 12.1%\n- internal/doctor: 14.5%\n- internal/refinery: 20.6%\n- internal/session: 27.8%\n- internal/git: 28.8%\n\nPriority should be given to mail, cmd, and daemon packages which handle critical functionality.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-21T21:34:47.807929-08:00","updated_at":"2025-12-21T22:19:59.416507-08:00","closed_at":"2025-12-21T22:19:59.416507-08:00","close_reason":"Deferred to post-launch. Test coverage improvement is ongoing work, not blocking for launch. Current tests cover critical paths; additional coverage can be added incrementally."}
|
||||
{"id":"gt-48bs","title":"gt rig reset: clear stale mail on reset/land","description":"## Problem\n\nWhen resetting or landing a rig/town, stale mail messages can confuse agents on startup. Old handoff messages, daemon notifications, and inter-agent mail should be cleaned up as part of reset.\n\n## Current State\n\n- `gt rig reset` exists but doesn't clear mail\n- Stale messages accumulate (e.g., daemon SHUTDOWN messages)\n- Agents may read outdated context on startup\n\n## Proposed Behavior\n\n`gt rig reset` and `gt town reset` should:\n1. Close all open messages (`--type=message`) in the relevant beads\n2. Optionally preserve pinned handoff beads (clear content, keep bead)\n3. Log what was cleaned up\n\n```bash\ngt rig reset gastown # Clears gastown mail\ngt rig reset gastown --mail # Only clear mail, keep other state\ngt town reset # Clears all town-level mail\ngt town reset --all # Clears mail in all rigs too\n```\n\n## Implementation\n\n1. Query `bd list --type=message --status=open`\n2. Close each with reason 'Cleared during reset'\n3. For pinned handoffs: `bd update \u003cid\u003e --description=''` instead of close","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-19T11:42:17.769674-08:00","updated_at":"2025-12-21T11:27:49.532203-08:00","closed_at":"2025-12-21T11:27:49.532203-08:00","close_reason":"Added --mail flag to gt rig reset"}
|
||||
{"id":"gt-4eim","title":"gt nudge should accept flexible session identifiers","description":"Currently `gt nudge` requires the exact tmux session name (e.g., `gt-gastown-furiosa`).\n\nIt should also accept:\n- `gastown/furiosa` (rig/polecat format)\n- `furiosa` (polecat name, infer rig from cwd or require if ambiguous)\n\nThe session list command shows `gastown/furiosa` format, but nudge rejects it:\n```\ngt session list → shows 'gastown/furiosa'\ngt nudge gastown/furiosa 'msg' → 'session not found'\ngt nudge gt-gastown-furiosa 'msg' → works\n```\n\nShould normalize all these formats to the tmux session name internally.","status":"in_progress","priority":2,"issue_type":"bug","assignee":"gastown/angharad","created_at":"2025-12-21T15:36:45.013475-08:00","updated_at":"2025-12-21T15:37:59.042119-08:00"}
|
||||
{"id":"gt-4ev4","title":"Implement gt sling command","description":"The unified work dispatch command.\n\n```bash\ngt sling \u003cthing\u003e \u003ctarget\u003e [options]\n```\n\nImplements spawn + assign + pin in one operation. See sling-design.md.\n\nAcceptance:\n- [ ] Parse thing (proto name, issue ID, epic ID)\n- [ ] Parse target (agent address) \n- [ ] Spawn molecule if proto\n- [ ] Assign to target agent\n- [ ] Pin to agent's hook (pinned bead)\n- [ ] Support --wisp flag for ephemeral\n- [ ] Support --molecule flag for issue+workflow\n- [ ] Error if hook already occupied (unless --force)","status":"in_progress","priority":1,"issue_type":"task","assignee":"gastown/furiosa","created_at":"2025-12-22T03:17:27.273013-08:00","updated_at":"2025-12-22T12:12:32.617698-08:00"}
|
||||
{"id":"gt-4ev4","title":"Implement gt sling command","description":"The unified work dispatch command.\n\n```bash\ngt sling \u003cthing\u003e \u003ctarget\u003e [options]\n```\n\nImplements spawn + assign + pin in one operation. See sling-design.md.\n\nAcceptance:\n- [ ] Parse thing (proto name, issue ID, epic ID)\n- [ ] Parse target (agent address) \n- [ ] Spawn molecule if proto\n- [ ] Assign to target agent\n- [ ] Pin to agent's hook (pinned bead)\n- [ ] Support --wisp flag for ephemeral\n- [ ] Support --molecule flag for issue+workflow\n- [ ] Error if hook already occupied (unless --force)","status":"in_progress","priority":1,"issue_type":"task","assignee":"gastown/furiosa","created_at":"2025-12-22T03:17:27.273013-08:00","updated_at":"2025-12-22T12:19:35.961386-08:00"}
|
||||
{"id":"gt-4my","title":"Doctor check: Worker health and stuck detection","description":"Detect and report stuck workers via gt doctor.\n\n## Checks\n\n### WorkerHealthCheck\n- List all active workers (polecats with state=working)\n- Check last activity timestamp for each\n- Flag as potentially stuck if no progress for configurable threshold (default: 30 min)\n- Check if Witness is running for the rig\n- Verify Witness last heartbeat time\n\n### Stuck Detection Criteria\n- Polecat state=working but session not running\n- Polecat state=working but output unchanged for threshold\n- Witness not responding to health checks\n- Multiple polecats in same rig all stuck\n\n## Output\n\n```\n[WARN] Workers in rig 'wyvern' may be stuck:\n - Toast: working for 45m, no recent output\n - Capable: working for 52m, session not found\n - Witness: last heartbeat 20m ago\n \n Suggestions:\n - gt witness status wyvern\n - gt capture wyvern/Toast 50\n - gt stop --rig wyvern (kill all)\n```\n\n## Auto-Fix\n\nCannot auto-fix stuck workers (risk of data loss), but can:\n- Restart Witness daemon if crashed\n- Send warning mail to Mayor","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-15T23:17:59.265062-08:00","updated_at":"2025-12-16T17:24:34.882466-08:00","dependencies":[{"issue_id":"gt-4my","depends_on_id":"gt-f9x.4","type":"blocks","created_at":"2025-12-15T23:19:05.565606-08:00","created_by":"daemon"},{"issue_id":"gt-4my","depends_on_id":"gt-7ik","type":"blocks","created_at":"2025-12-17T15:44:42.068149-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-4nn","title":"Molecules: Composable Workflow Beads","description":"## Summary\n\nMolecules are crystallized workflow patterns stored as Beads issues.\nWhen instantiated, the molecule creates child beads forming a DAG.\n\n## Key Insight: Molecules ARE Beads\n\nPer HOP Decision 001: Beads IS the ledger. Molecules don't get a separate YAML format - they're issues with `type: molecule` containing prose-based step definitions.\n\nAgents don't need rigid schemas. They parse natural language natively. A molecule is just instructions with enough structure for tooling.\n\n## Example: Engineer in a Box\n\n```markdown\nid: mol-xyz\ntype: molecule\ntitle: Engineer in a Box\n\nThis workflow takes a task from design to merge.\n\n## Step: design\nThink carefully about architecture. Consider existing patterns, \ntrade-offs, testability.\n\n## Step: implement\nWrite clean code. Follow codebase conventions.\nNeeds: design\n\n## Step: review \nReview for bugs, edge cases, style issues.\nNeeds: implement\n\n## Step: test\nWrite and run tests. Cover happy path and edge cases.\nNeeds: implement\n\n## Step: submit\nSubmit for merge via refinery.\nNeeds: review, test\n```\n\n## Instantiation\n\n```bash\n# Attach molecule when spawning\ngt spawn --issue gt-abc --molecule mol-xyz\n\n# Creates child beads atomically:\ngt-abc.design ← ready first\ngt-abc.implement ← blocked by design \ngt-abc.review ← blocked by implement\ngt-abc.test ← blocked by implement\ngt-abc.submit ← blocked by review, test\n```\n\nEach step issue gets an `instantiated-from` edge to the molecule (with step metadata).\n\n## Why This Matters\n\n1. **Unified data plane**: Everything in Beads, no parallel YAML channel\n2. **AI-native**: Prose instructions, not rigid schemas\n3. **Error isolation**: Each step is a checkpoint - failure doesn't lose progress\n4. **Scales with AI**: As agents get smarter, they handle more complex molecules\n\n## Implementation Primitives\n\n- `ParseMoleculeSteps()`: Extract steps from prose (convention-based)\n- `InstantiateMolecule()`: Atomic transaction creating all steps + edges \n- `instantiated-from` edge type: Track provenance\n- Parameterization: `{{variable}}` substitution from context map","status":"closed","priority":0,"issue_type":"epic","created_at":"2025-12-18T18:06:24.573068-08:00","updated_at":"2025-12-19T14:44:59.705427-08:00","closed_at":"2025-12-19T14:44:59.705427-08:00"}
|
||||
{"id":"gt-4nn.1","title":"Molecule schema: YAML format for workflow definitions","description":"Define the YAML schema for molecule definitions:\n\n```yaml\nmolecule: \u003cname\u003e\nversion: 1\ndescription: \"Human description\"\nsteps:\n - id: \u003cstep-id\u003e\n title: \"Step title\"\n prompt: \"Instructions for agent\"\n depends: [\u003cother-step-ids\u003e] # optional\n tier: haiku|sonnet|opus # optional, default from config\n timeout: 30m # optional\n```\n\nStore molecules in:\n- `\u003crig\u003e/molecules/\u003cname\u003e.yaml` for rig-specific\n- `\u003ctown\u003e/molecules/\u003cname\u003e.yaml` for town-wide\n\nBuilt-in molecules to ship:\n- engineer-in-box: design→code→review→test→submit\n- quick-fix: implement→test→submit\n- research: investigate→document","status":"closed","priority":0,"issue_type":"task","created_at":"2025-12-18T18:06:49.441267-08:00","updated_at":"2025-12-18T20:14:32.629327-08:00","closed_at":"2025-12-18T20:14:32.629327-08:00","dependencies":[{"issue_id":"gt-4nn.1","depends_on_id":"gt-4nn","type":"parent-child","created_at":"2025-12-18T18:06:49.442723-08:00","created_by":"daemon"}]}
|
||||
@@ -139,7 +139,7 @@
|
||||
{"id":"gt-71i","title":"Update architecture.md: Engineer role and Beads merge queue","description":"Update docs/architecture.md with recent design decisions:\n\n1. Agent table: Change \"Refinery\" role to \"Engineer\"\n - Refinery = place/module/directory\n - Engineer = role (agent that works in the Refinery)\n\n2. Merge Queue section: Document Beads-native model\n - MRs are beads issues with --type=merge-request\n - gt mq commands (submit, list, next, process, reorder)\n - Ordering via depends-on links\n\n3. CLI section: Add gt mq commands\n\n4. Key Design Decisions: Add decisions for:\n - #15: Merge Queue in Beads\n - #16: Engineer role (distinct from Refinery place)\n - #17: Session restart protocol for Engineer","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-16T23:12:03.616159-08:00","updated_at":"2025-12-16T23:12:03.616159-08:00","dependencies":[{"issue_id":"gt-71i","depends_on_id":"gt-h5n","type":"blocks","created_at":"2025-12-16T23:12:14.92163-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-72so","title":"gt mq list: doesn't show submitted MRs","description":"After submitting MRs with gt mq submit, gt mq list gastown shows empty queue.\n\n## Reproduction\n1. gt mq submit --issue gt-h5n.5 --branch polecat/Scabrous\n2. gt mq list gastown → (empty)\n3. bd list --type=merge-request → shows the MR\n\n## Expected\ngt mq list should show submitted MRs\n\n## MR example\ngt-ts4u has rig: gastown in description, type=merge-request, status=open","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-12-19T14:54:26.731813-08:00","updated_at":"2025-12-19T17:22:52.552662-08:00","closed_at":"2025-12-19T16:19:53.82455-08:00"}
|
||||
{"id":"gt-7918","title":"Patrols: Cyclic molecules for autonomous maintenance","description":"## Vision\n\nPatrols are **cyclic molecules** - workflow loops that give Gas Town its autonomous nervous system. While regular molecules are DAGs that terminate, patrols loop forever, performing maintenance tasks at varying cadences.\n\nThis is the \"steam engine\" of Gas Town: converting episodic Claude sessions into continuous autonomous operation.\n\n## Core Concepts\n\n### 1. Cyclic Molecules\n\nRegular molecule: A -\u003e B -\u003e C -\u003e done\nPatrol molecule: A -\u003e B -\u003e C --+\n ^ |\n +-------------+\n\nPatrols have a loop_to field specifying where to restart.\n\n### 2. Cooldown-Aware Steps (Atoms)\n\nSteps encode their own cadence. When patrol reaches a step:\n1. Check: now - last_run \u003e cooldown?\n2. If yes: execute, update last_run\n3. If no: skip (immediately close)\n\nThe patrol runner is simple - steps self-skip. Complexity distributed into atoms.\n\n### 3. The Beacon\n\nThe heartbeat that fires patrol triggers:\n- Internal ticker in Deacon (goroutine)\n- Or external cron firing gt deacon tick\n- Or mail-based triggers\n\nWithout beacon, nothing proactive happens.\n\n### 4. Session Reset as Patrol Step\n\nConnects to auto-handoff (gt-bcwn). Session reset is a patrol step, not a separate mechanism.\n\n### 5. Multi-Role Patrols\n\nEach supervisor has its own patrol:\n\n**Deacon patrol:** health-check (30s), session-gc (5m), beacon-tick (10s)\n**Witness patrol:** orphan-scan (10m), stuck-check (2m), molecule-progress (1m)\n**Refinery patrol:** queue-check (30s), pr-status (1m), merge-ready (30s)\n\n### 6. Cadence Tiers\n\n- Critical (10-30s): Health checks\n- Active (1-5m): Progress, nudges\n- Maintenance (10-30m): Orphans, GC\n- Periodic (1h+): Reports\n\n### 7. Best-Effort Scheduling\n\nNot real-time - more like cron. No hard deadlines. Catch-up, dont pile-up.\nPriority preemption (mail interrupts patrol). Graceful degradation under load.\n\n## Open Questions\n\n1. State persistence: Beads (self-describing) or file (faster)?\n2. Interruption: How does urgent mail preempt patrol?\n3. Error recovery: Backoff? Escalate? Circuit breaker?\n4. Coordination: Can patrols send mail to trigger other patrols?\n\n## Related\n\n- gt-bcwn: Auto-handoff (session reset is a patrol step)\n- Molecule system (patrols extend molecules with loops)\n- Deacon lifecycle management\n\n## Metaphor\n\nClaude was fire. Claude Code was steam. Gas Town is the steam engine. Beads is the train tracks.\n\nThe steam engine converts episodic combustion into continuous rotary motion.\nGas Town converts episodic Claude sessions into continuous autonomous work.","status":"open","priority":1,"issue_type":"epic","created_at":"2025-12-21T12:18:22.99128-08:00","updated_at":"2025-12-21T12:18:22.99128-08:00","dependencies":[{"issue_id":"gt-7918","depends_on_id":"gt-bcwn","type":"blocks","created_at":"2025-12-21T12:18:30.86651-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-7hor","title":"Document the Propulsion Principle","description":"Write canonical documentation for the Universal Gas Town Propulsion Principle.\n\nLocation: gastown/mayor/rig/docs/propulsion-principle.md\n\nContent:\n- The One Rule (hook has work → work happens)\n- Why it works (stateless agents, molecule-driven)\n- The sling lifecycle diagram\n- Agent startup protocol\n- Examples and anti-patterns\n\nThis is foundational theory-of-operation documentation.","status":"in_progress","priority":2,"issue_type":"task","assignee":"gastown/slit","created_at":"2025-12-22T03:17:47.790012-08:00","updated_at":"2025-12-22T12:13:16.886084-08:00"}
|
||||
{"id":"gt-7hor","title":"Document the Propulsion Principle","description":"Write canonical documentation for the Universal Gas Town Propulsion Principle.\n\nLocation: gastown/mayor/rig/docs/propulsion-principle.md\n\nContent:\n- The One Rule (hook has work → work happens)\n- Why it works (stateless agents, molecule-driven)\n- The sling lifecycle diagram\n- Agent startup protocol\n- Examples and anti-patterns\n\nThis is foundational theory-of-operation documentation.","status":"closed","priority":2,"issue_type":"task","assignee":"gastown/slit","created_at":"2025-12-22T03:17:47.790012-08:00","updated_at":"2025-12-22T12:18:20.377092-08:00","closed_at":"2025-12-22T12:18:20.377092-08:00","close_reason":"Wrote propulsion-principle.md documenting the One Rule, molecule-driven execution, sling lifecycle, startup protocol, and anti-patterns"}
|
||||
{"id":"gt-7hz3","title":"Merge: gt-92l","description":"branch: polecat/Ace\ntarget: main\nsource_issue: gt-92l\nrig: gastown","status":"closed","priority":2,"issue_type":"merge-request","created_at":"2025-12-19T16:31:37.716367-08:00","updated_at":"2025-12-19T18:26:14.102101-08:00","closed_at":"2025-12-19T17:48:09.627376-08:00"}
|
||||
{"id":"gt-7iek","title":"context-check","description":"Assess own context usage. If high, prepare for handoff.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-21T17:51:45.43771-08:00","updated_at":"2025-12-21T17:51:45.43771-08:00","dependencies":[{"issue_id":"gt-7iek","depends_on_id":"gt-hbnz","type":"parent-child","created_at":"2025-12-21T17:51:45.442974-08:00","created_by":"stevey"}],"wisp":true}
|
||||
{"id":"gt-7ik","title":"Ephemeral polecats: spawn fresh, delete on completion","description":"## Design Decision\n\nSwitch from pooled/idle polecats to ephemeral model:\n- Spawn creates fresh worktree from main\n- Polecat requests shutdown when done (bottom-up)\n- Witness verifies handoff, kills session, deletes worktree\n- No 'idle' state - polecats exist only while working\n\n## Rationale\n\n1. **Git worktrees are fast** - pooling optimization is obsolete\n2. **Pooling creates maintenance burden:**\n - Git stashes accumulate\n - Untracked artifacts pile up\n - Branches drift from main\n - Beads DB gets stale\n3. **PGT sync problems** came from persistent branches\n4. **Support infrastructure exists** - Witness, Refinery, Mayor handle continuity\n5. **Simpler mental model** - polecat exists = work in progress\n\n## Lifecycle\n\n```\nSpawn:\n gt spawn --issue \u003cid\u003e\n → Creates fresh worktree: git worktree add polecats/\u003cname\u003e -b polecat/\u003cname\u003e\n → Initializes beads in worktree\n → Starts session, assigns work\n\nWorking:\n Polecat does task\n → Pushes to polecat/\u003cname\u003e branch\n → Submits to merge queue when ready\n\nCompletion (POLECAT-INITIATED):\n Polecat runs: gt handoff\n → Verifies git state clean\n → Sends mail to Witness: \"Ready for shutdown\"\n → Marks itself done, waits for termination\n\nCleanup (WITNESS-OWNED):\n Witness receives shutdown request\n → Verifies PR merged or in queue\n → Verifies no uncommitted changes\n → Kills session: gt session stop \u003crig\u003e/\u003cpolecat\u003e\n → Deletes worktree: git worktree remove polecats/\u003cname\u003e\n → Deletes branch: git branch -d polecat/\u003cname\u003e\n → Optionally: Notifies Mayor of completion\n```\n\n## Key Insight: Bottom-Up Shutdown\n\n**Old model (wrong)**: Top-down batch shutdown - \"cancel the swarm\"\n**New model (right)**: Bottom-up individual shutdown - polecat requests, Witness executes\n\nThis enables streaming:\n- Workers come and go continuously\n- No \"swarm end\" to trigger cleanup\n- Each worker manages its own lifecycle\n- Witness is the lifecycle authority\n\n## Implementation\n\n1. Add `gt handoff` command for polecats to request shutdown\n2. Modify gt spawn to always create fresh worktree\n3. Run bd init in new worktree (beads needs initialization)\n4. Add shutdown request handler to Witness\n5. Witness verifies handoff, then cleans up:\n - Kill session\n - Remove worktree\n - Delete branch\n6. Remove 'idle' state from polecat state machine\n7. Simplify gt polecat list (only shows active)\n\n## Impact on Other Tasks\n\n- gt-17r (Zombie cleanup): Becomes trivial - orphan worktrees\n- gt-4my (Worker health): Simpler - no idle/stuck ambiguity\n- gt-f9x.5/f9x.6 (Doctor): Fewer states to validate\n- gt-eu9 (Witness handoff): Witness receives polecat shutdown requests","status":"closed","priority":1,"issue_type":"feature","created_at":"2025-12-17T15:44:31.139964-08:00","updated_at":"2025-12-19T01:57:17.033547-08:00","closed_at":"2025-12-19T01:57:17.033547-08:00"}
|
||||
|
||||
Reference in New Issue
Block a user