bd sync: 2025-12-21 12:18:36

.beads/issues.jsonl

@@ -105,6 +105,7 @@
 {"id":"gt-70b3","title":"detectSender() doesn't recognize crew workers","description":"## Problem\n\n`detectSender()` in mail.go only detects polecats, not crew workers.\n\n## Current Code (line 445)\n\n```go\n// If in a rig's polecats directory, extract address\nif strings.Contains(cwd, \"/polecats/\") {\n    // extract rig/polecat\n}\n\n// Default to mayor\nreturn \"mayor/\"\n```\n\n## Symptom\n\nEmma (crew worker at `/Users/stevey/gt/beads/crew/emma`) runs:\n- `gt mail inbox` → checks `mayor/` inbox (wrong!)\n- Should check `beads/emma` or `beads/crew/emma`\n\n## Fix\n\nAdd crew detection:\n```go\n// If in a rig's crew directory, extract address  \nif strings.Contains(cwd, \"/crew/\") {\n    parts := strings.Split(cwd, \"/crew/\")\n    if len(parts) \u003e= 2 {\n        rigPath := parts[0]\n        crewName := strings.Split(parts[1], \"/\")[0]\n        rigName := filepath.Base(rigPath)\n        return fmt.Sprintf(\"%s/%s\", rigName, crewName)\n    }\n}\n```\n\n## Also Check\n\n- `gt prime` correctly detects role, so there may be another detection function that works\n- Should unify detection logic","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-12-18T21:40:26.520559-08:00","updated_at":"2025-12-18T21:55:54.679969-08:00","closed_at":"2025-12-18T21:55:54.679969-08:00","dependencies":[{"issue_id":"gt-70b3","depends_on_id":"gt-l4gm","type":"blocks","created_at":"2025-12-18T21:50:04.812663-08:00","created_by":"daemon"}]}
 {"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-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-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"}
 {"id":"gt-7lt","title":"gt mail send should tmux-notify recipient","description":"## Problem\n\nWhen mail is sent via gt mail send, the recipient session does not get a tmux notification. In Python Gas Town (PGT), mail delivery triggers a tmux display-message or similar notification so the agent knows mail arrived.\n\n## Expected Behavior\n\nWhen gt mail send \u003caddr\u003e is called:\n1. Mail is delivered to recipient inbox\n2. If recipient has an active tmux session, send notification\n3. Notification should be visible (display-message or bell)\n\n## Current Behavior\n\nMail is delivered but no notification. Agent has to poll inbox to discover new mail.\n\n## Impact\n\n- Agents miss time-sensitive messages\n- Heartbeat pokes from daemon will not wake agents\n- Coordination is slower (polling vs push)\n\n## Implementation Notes\n\nAfter successful mail delivery, check if recipient has active session:\n- gt session list can identify active sessions\n- tmux display-message or send-keys can notify\n- Could inject a visible prompt like \"[MAIL] New message from \u003csender\u003e\"\n\n## Reference\n\nCheck PGT implementation for how it handles this.","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-12-18T12:28:50.142075-08:00","updated_at":"2025-12-18T20:09:53.112902-08:00","closed_at":"2025-12-18T20:09:53.112902-08:00"}