From 20e2a13dc489b950f5e7cbf8f69bfd7322dc148a Mon Sep 17 00:00:00 2001 From: Steve Yegge Date: Tue, 23 Dec 2025 00:17:49 -0800 Subject: [PATCH] feat: Add mol-ready-work protomolecule MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds autonomous backlog processing patrol molecule for crew workers. The molecule scans PRs, GitHub issues, and beads; selects work using an ROI heuristic; executes items; and loops until context is low. Key features: - Vapor phase (wisp) - ephemeral patrol cycles - Scans 4 backlogs: PRs > untriaged > beads > triaged - ROI-based selection with context awareness - Per-type execution handlers (PR review, triage, implementation) - Clean handoff protocol with digest squashing Issue: gt-tnca.1 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 --- .beads/issues.jsonl | 12 +- internal/beads/builtin_molecules.go | 188 +++++++++++++++++++++++ internal/beads/builtin_molecules_test.go | 4 +- 3 files changed, 196 insertions(+), 8 deletions(-) diff --git a/.beads/issues.jsonl b/.beads/issues.jsonl index 439ae920..71a75edf 100644 --- a/.beads/issues.jsonl +++ b/.beads/issues.jsonl @@ -124,7 +124,7 @@ {"id":"gt-5v29","title":"Add 'wit' alias for witness command","description":"ref works as alias for refinery, but wit doesn't work for witness. Add Aliases: []string{\"wit\"} to witnessCmd.","status":"open","priority":3,"issue_type":"task","created_at":"2025-12-20T23:11:53.453692-08:00","updated_at":"2025-12-20T23:11:53.453692-08:00"} {"id":"gt-5wb7","title":"Update vision.md with proto/mol/wisp terminology","description":"Update the Steam Engine Metaphor section to use consistent phase terminology:\n\nCurrent (vision.md):\n- Proto molecules = fuel (templates)\n- Wisps = steam (transient execution traces) \n- Digests = distillate (permanent records)\n\nNew terminology:\n- **Proto** = crystal/solid - frozen template\n- **Mol** = liquid - reified durable instance (tracked in git)\n- **Wisp** = gas - ephemeral instance (evaporates after squash)\n- **Digest** = distillate - compressed summary after squash\n\nKey clarification needed:\n- Proto → bond → creates either Mol (durable) or Wisp (ephemeral)\n- The choice of Mol vs Wisp depends on --wisp flag\n- Default is Mol (durable, recorded in main beads)\n- Wisp lives in .beads-ephemeral/, squashes away","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-21T16:32:45.68234-08:00","updated_at":"2025-12-21T17:20:42.826322-08:00","dependencies":[{"issue_id":"gt-5wb7","depends_on_id":"gt-62hm","type":"blocks","created_at":"2025-12-21T16:33:17.307488-08:00","created_by":"daemon"}]} {"id":"gt-5wtw","title":"Shutdown request handler","description":"Handle polecat shutdown requests:\n\nWhen polecat runs 'gt handoff --shutdown':\n1. Polecat sends mail to \u003crig\u003e/witness requesting shutdown\n2. Witness receives mail\n3. Witness verifies:\n - Git working tree is clean\n - Work is submitted (MR exists or in queue)\n - No uncommitted beads changes\n4. If clean:\n - gt session stop \u003crig\u003e/\u003cpolecat\u003e\n - git worktree remove polecats/\u003cname\u003e\n - git branch -d polecat/\u003cname\u003e\n5. If not clean:\n - Send nudge back to polecat\n - Track retry count\n\nDepends on fixing gt-dsfi (handoff deadlock).","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-20T03:14:22.968711-08:00","updated_at":"2025-12-20T09:28:15.512143-08:00","closed_at":"2025-12-20T09:28:15.512143-08:00","dependencies":[{"issue_id":"gt-5wtw","depends_on_id":"gt-53w6","type":"parent-child","created_at":"2025-12-20T03:14:37.300578-08:00","created_by":"daemon"},{"issue_id":"gt-5wtw","depends_on_id":"gt-mxyj","type":"blocks","created_at":"2025-12-20T03:14:38.893061-08:00","created_by":"daemon"}]} -{"id":"gt-5xph","title":"Document session cycling protocol in all templates","description":"Add explicit lifecycle request protocol to all agent templates.\n\n## Problem\nTemplates mention 'request session refresh' but don't show HOW.\nAgents don't know the protocol for requesting a cycle.\n\n## Protocol to document\n1. Write handoff mail to self (for continuity)\n2. Set requesting_cycle=true in state.json\n3. Send LIFECYCLE mail to deacon/:\n Subject: 'LIFECYCLE: \u003crole\u003e requesting cycle'\n Body: Reason for cycle request\n\n## Templates to update\n- prompts/roles/polecat.md\n- prompts/roles/crew.md \n- prompts/roles/witness.md\n- prompts/roles/refinery.md\n\n## Also add\n- Example state.json location for each role\n- When to request cycle (context full, work complete, etc.)\n- What happens after (daemon kills, respawns, new session primes)","status":"in_progress","priority":1,"issue_type":"task","assignee":"gastown/slit","created_at":"2025-12-22T16:43:54.10282-08:00","updated_at":"2025-12-23T00:09:06.898993-08:00"} +{"id":"gt-5xph","title":"Document session cycling protocol in all templates","description":"Add explicit lifecycle request protocol to all agent templates.\n\n## Problem\nTemplates mention 'request session refresh' but don't show HOW.\nAgents don't know the protocol for requesting a cycle.\n\n## Protocol to document\n1. Write handoff mail to self (for continuity)\n2. Set requesting_cycle=true in state.json\n3. Send LIFECYCLE mail to deacon/:\n Subject: 'LIFECYCLE: \u003crole\u003e requesting cycle'\n Body: Reason for cycle request\n\n## Templates to update\n- prompts/roles/polecat.md\n- prompts/roles/crew.md \n- prompts/roles/witness.md\n- prompts/roles/refinery.md\n\n## Also add\n- Example state.json location for each role\n- When to request cycle (context full, work complete, etc.)\n- What happens after (daemon kills, respawns, new session primes)","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-22T16:43:54.10282-08:00","updated_at":"2025-12-22T16:43:54.10282-08:00"} {"id":"gt-5y5p","title":"Preflight molecule: verify baseline health before work","description":"Before assigning work, verify baseline (main branch) is healthy.\n\n**From VC**: Self-healing state machine (HEALTHY → SELF_HEALING → ESCALATED). ~200 lines.\n\n**Gas Town implementation**: Preflight molecule or refinery feature:\n```yaml\npreflight:\n gates: [test, lint, build]\n on_failure: create-fix-issue\n```\n\nRun at session start. If baseline broken, file a P0 fix issue and work on that first.\n\n**Value**: Self-healing baseline. Agents don't start from broken state.\n\n**VC lesson**: Prevents cascading failures. Agent shouldn't start work on broken code.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-20T20:30:13.807641-08:00","updated_at":"2025-12-20T20:30:13.807641-08:00","dependencies":[{"issue_id":"gt-5y5p","depends_on_id":"gt-zhpa","type":"parent-child","created_at":"2025-12-20T20:30:27.469804-08:00","created_by":"daemon"}]} {"id":"gt-61o","title":"Review and audit all GGT beads","description":"Thorough review of all filed beads in gastown GGT repo. Check for: consistency, completeness, correct dependencies, accurate descriptions, proper prioritization. Ensure beads are self-contained and dont rely on external docs.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-15T20:24:07.152386-08:00","updated_at":"2025-12-15T21:23:58.255447-08:00","closed_at":"2025-12-15T21:23:58.255447-08:00"} {"id":"gt-62hm","title":"Molecule Phase Terminology Documentation","description":"Document the three-phase molecule lifecycle with consistent terminology:\n\n## The Phases (States of Matter)\n\n| Phase | State | Nature |\n|-------|-------|--------|\n| **Proto** | Solid/Crystal | Frozen template, static definition in catalog |\n| **Mol** | Liquid | Reified instance, malleable, tracked in git (durable) |\n| **Wisp** | Gas | Evaporates after squash, ephemeral orchestration |\n\n## Documentation Gaps Identified\n\n### High Priority\n1. Update vision.md Steam Engine metaphor to use proto/mol/wisp terminology\n2. Add lifecycle diagram: Proto → bond → Mol or Wisp → squash → Digest\n3. Document Go types for phases (ProtoMolecule, etc.)\n4. Document .beads-ephemeral/ structure and purpose\n\n### Medium Priority\n5. Update CLAUDE.md files (polecat, witness, refinery) with molecule workflow\n6. Document bd mol bond/squash/burn CLI API with examples\n7. Add polecat guide: Executing molecules and generating summaries\n\n### Low Priority\n8. Add terminology glossary to architecture.md\n9. Create troubleshooting playbook for stuck molecules\n10. Add reference diagrams for state transitions\n\n## Current State\n- architecture.md has good molecule basics but uses inconsistent terminology\n- vision.md has Steam Engine metaphor (proto=fuel, wisp=steam, digest=distillate)\n- molecules.md has detailed reference but needs phase clarity\n- builtin_molecules.go has 8 molecules but no phase documentation in code","status":"open","priority":1,"issue_type":"epic","created_at":"2025-12-21T16:32:27.537487-08:00","updated_at":"2025-12-21T16:32:27.537487-08:00"} @@ -153,7 +153,7 @@ {"id":"gt-7920","title":"Create mol-refinery-patrol with test failure gates","description":"## Problem\n\nThe Refinery role lacks:\n1. A formal patrol molecule (Deacon has mol-deacon-patrol)\n2. Engineer identity/philosophy guidance\n3. Structural enforcement of failure handling (not just documentation)\n\nWhen tests fail during merge processing, the current guidance doesn't prevent 'disavowal' - noting a problem exists and proceeding without tracking it.\n\n## The Structural Solution\n\nCreate `mol-refinery-patrol` with **verification gates** that make disavowal structurally impossible:\n\n```markdown\n## Molecule: mol-refinery-patrol\n\n## Step: inbox-check\nCheck mail for MR submissions, escalations, messages.\nProcess any urgent items first.\n\n## Step: queue-scan\nFetch remote, identify polecat branches waiting.\nIf queue empty, skip to context-check.\nTrack branch list for this cycle.\nNeeds: inbox-check\n\n## Step: process-branch\nPick next branch. Rebase on current main.\nIf rebase conflicts: notify polecat, skip to next branch.\nNeeds: queue-scan\n\n## Step: run-tests\nRun go test ./...\nTrack results (pass/fail count).\nNeeds: process-branch\n\n## Step: handle-failures\n**GATE**: If tests passed, this step auto-completes.\nIf tests failed:\n- Diagnose: branch regression or pre-existing?\n- Branch regression → abort, notify polecat\n- Pre-existing → EITHER fix OR \\`bd create --type=bug\\`\n**VERIFY**: Fix committed OR bead filed before proceeding.\nNeeds: run-tests\n\n## Step: merge-push\nMerge to main (ff-only preferred).\nPush immediately.\nDelete polecat branch.\nNeeds: handle-failures\n\n## Step: loop-check\nMore branches? Return to process-branch.\nOtherwise continue to summary.\nNeeds: merge-push\n\n## Step: generate-summary\nSummarize cycle: branches processed, tests results, issues filed.\nNeeds: loop-check\n\n## Step: context-check\nCheck context usage.\nIf high: write handoff, prepare for burn/respawn.\nNeeds: generate-summary\n\n## Step: burn-or-loop\nIf context LOW and queue non-empty: loop (return to queue-scan)\nIf context HIGH or queue empty: burn and exit\nNeeds: context-check\n```\n\n## Implementation Tasks\n\n### 1. Add RefineryPatrolMolecule() to builtin_molecules.go\n- Copy pattern from DeaconPatrolMolecule\n- Include all steps with proper `Needs:` dependencies\n- Emphasize handle-failures gate in description\n\n### 2. Update Refinery CLAUDE.md\nAdd sections:\n- **The Engineer Mindset** (identity/philosophy)\n- **The Scotty Test** (Would Scotty walk past this?)\n- **Patrol Molecule** reference (mol-refinery-patrol)\n- **Test Failure Protocol** (explicit decision tree)\n\n### 3. Create prompts/roles/refinery.md\n- Follow pattern of deacon.md\n- Include patrol execution loop diagram\n- Reference the molecule\n\n### 4. Consider mol-witness-patrol\n- Witness has detailed heartbeat protocol but no formal molecule\n- Similar pattern could apply\n\n## Why This Matters\n\nGUPP: 'If you have work on your hook, you have to run it.'\nThe patrol molecule puts failure handling ON THE HOOK as a mandatory step.\nYou can't skip handle-failures to get to merge-push.\nThe structure enforces good behavior.\n\n## Related\n- gt-7919: Fix failing beads tests (discovered during this session)\n- mol-deacon-patrol (existing pattern to follow)\n- docs/molecular-chemistry.md (chemistry concepts)\n- docs/wisp-architecture.md (wisp vs mol decision)","status":"closed","priority":1,"issue_type":"feature","created_at":"2025-12-22T13:01:48.588945-08:00","updated_at":"2025-12-22T13:20:37.565029-08:00","closed_at":"2025-12-22T13:13:36.329669-08:00"} {"id":"gt-7921","title":"Add await-work and plugin-run steps to mol-refinery-patrol","description":"## Context\n\nThe mol-refinery-patrol needs two additional steps:\n\n### 1. await-work (Decision Point)\n\nNot just 'wait for signal' but a crossroads:\n- Check for pending signals (mail, nudge, human)\n- Check plugin gates (any plugins need to run?)\n- Check maintenance schedule (daily/weekly due?)\n- Evaluate context and decide next action\n\nPosition: Between burn-or-loop and inbox-check (the loop point)\n\n### 2. plugin-run (Like Deacon)\n\nRefinery needs plugin support for:\n- **Monitors**: Flag PRs touching sensitive code\n- **Gates**: Block merges under certain conditions\n- **Schedulers**: Reorder queue based on priority/urgency\n- **Maintenance**: Weekly cleanup, audits, stats\n- **Audits**: Log merge statistics, track patterns\n\nPosition: After queue-scan, before process-branch\n\n## Implementation\n\nUpdate RefineryPatrolMolecule() in builtin_molecules.go to include:\n- await-work step with decision tree\n- plugin-run step with gate types\n\n## Related\n- gt-7920 (original mol-refinery-patrol)\n- docs/deacon-plugins.md (existing plugin model)","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-22T13:24:11.267237-08:00","updated_at":"2025-12-22T13:24:11.267237-08:00"} {"id":"gt-7922","title":"Dynamic wisp modification: insert, reorder, bond mid-execution","description":"## Vision\n\nWisps should be living documents that adapt mid-execution, not static scripts.\n\n## Operations Needed\n\n### bd mol insert\nInsert a step into a running wisp:\n```bash\nbd mol insert \u003cwisp-id\u003e --after \u003cstep\u003e --step 'security-gate: Review auth changes'\n```\n\n### bd mol reorder \nChange step order in a running wisp:\n```bash\nbd mol reorder \u003cwisp-id\u003e --move process-branch --before current\n```\n\n### bd mol bond (to wisp)\nAttach an entire molecule to a running wisp:\n```bash\nbd mol bond mol-weekly-maintenance \u003cwisp-id\u003e --after await-work\n```\n\n### bd mol skip\nSkip a step (with reason):\n```bash\nbd mol skip \u003cwisp-id\u003e \u003cstep\u003e --reason 'Queue empty, skipping summary'\n```\n\n## Use Cases\n\n1. **Hotfix priority**: Reorder queue to process urgent MR first\n2. **Security gate**: Insert review step when PR touches sensitive files\n3. **Scheduled maintenance**: Bond maintenance mol on schedule\n4. **Context adaptation**: Skip steps when they don't apply\n\n## Why This Matters\n\nEngine room problems emerge dynamically. The wisp's flexibility lets agents model situations as they evolve, not execute rigid scripts.\n\nGUPP still applies: whatever's on your hook, you run. But the hook contents can adapt.\n\n## Implementation\n\nThis requires Beads changes to support wisp mutation:\n- Track step ordering in wisp storage\n- Support step insertion/deletion/reordering\n- Handle bond-to-wisp (spawn steps into existing wisp)\n- Preserve audit trail of modifications","status":"open","priority":2,"issue_type":"feature","created_at":"2025-12-22T13:24:26.533247-08:00","updated_at":"2025-12-22T13:24:26.533247-08:00"} -{"id":"gt-7923","title":"gt rig add / gt doctor: patrol awareness and wiring","description":"## Problem\n\nWhen a rig is installed or audited, we need to ensure all built-in patrols and role hooks are properly wired up.\n\n## gt rig add Changes\n\nWhen adding a rig, automatically:\n\n1. **Create patrol molecules** for each role:\n - mol-deacon-patrol (town-level)\n - mol-witness-patrol (per-rig)\n - mol-refinery-patrol (per-rig)\n\n2. **Set up hooks** that trigger patrols:\n - Deacon: daemon timer / heartbeat\n - Witness: daemon timer / polecat lifecycle events\n - Refinery: MR submission events / daemon timer\n\n3. **Configure daemon** to manage these patrols:\n - Register patrol molecules in daemon config\n - Set up respawn behavior for each role\n\n4. **Create plugin directories**:\n - ~/gt/plugins/ (town-level)\n - \u003crig\u003e/plugins/ (rig-level, if needed)\n\n## gt doctor Changes\n\nAdd patrol health checks:\n\n### patrol-molecules-exist\n- Verify mol-deacon-patrol, mol-witness-patrol, mol-refinery-patrol exist\n- Check they parse correctly (valid steps, dependencies)\n\n### patrol-hooks-wired\n- Verify hooks trigger patrol execution\n- Check daemon is configured to manage patrols\n\n### patrol-not-stuck\n- Detect wisps that have been in-progress too long\n- Flag orphaned patrol molecules (no active session)\n\n### patrol-plugins-accessible\n- Verify plugin directories exist and are readable\n- Check plugin frontmatter parses correctly\n\n### patrol-roles-have-prompts\n- Verify prompts/roles/*.md exist for each role\n- Check they reference the correct patrol molecule\n\n## Auto-fix\n\ngt doctor --fix can:\n- Create missing patrol molecules\n- Wire up missing hooks\n- Create plugin directories\n- NOT restart stuck patrols (needs human decision)\n\n## Related\n- gt-7920 (mol-refinery-patrol)\n- gt-7921 (await-work and plugin-run)\n- docs/wisp-architecture.md","status":"in_progress","priority":1,"issue_type":"feature","assignee":"gastown/rictus","created_at":"2025-12-22T13:24:43.158379-08:00","updated_at":"2025-12-23T00:10:58.83252-08:00"} +{"id":"gt-7923","title":"gt rig add / gt doctor: patrol awareness and wiring","description":"## Problem\n\nWhen a rig is installed or audited, we need to ensure all built-in patrols and role hooks are properly wired up.\n\n## gt rig add Changes\n\nWhen adding a rig, automatically:\n\n1. **Create patrol molecules** for each role:\n - mol-deacon-patrol (town-level)\n - mol-witness-patrol (per-rig)\n - mol-refinery-patrol (per-rig)\n\n2. **Set up hooks** that trigger patrols:\n - Deacon: daemon timer / heartbeat\n - Witness: daemon timer / polecat lifecycle events\n - Refinery: MR submission events / daemon timer\n\n3. **Configure daemon** to manage these patrols:\n - Register patrol molecules in daemon config\n - Set up respawn behavior for each role\n\n4. **Create plugin directories**:\n - ~/gt/plugins/ (town-level)\n - \u003crig\u003e/plugins/ (rig-level, if needed)\n\n## gt doctor Changes\n\nAdd patrol health checks:\n\n### patrol-molecules-exist\n- Verify mol-deacon-patrol, mol-witness-patrol, mol-refinery-patrol exist\n- Check they parse correctly (valid steps, dependencies)\n\n### patrol-hooks-wired\n- Verify hooks trigger patrol execution\n- Check daemon is configured to manage patrols\n\n### patrol-not-stuck\n- Detect wisps that have been in-progress too long\n- Flag orphaned patrol molecules (no active session)\n\n### patrol-plugins-accessible\n- Verify plugin directories exist and are readable\n- Check plugin frontmatter parses correctly\n\n### patrol-roles-have-prompts\n- Verify prompts/roles/*.md exist for each role\n- Check they reference the correct patrol molecule\n\n## Auto-fix\n\ngt doctor --fix can:\n- Create missing patrol molecules\n- Wire up missing hooks\n- Create plugin directories\n- NOT restart stuck patrols (needs human decision)\n\n## Related\n- gt-7920 (mol-refinery-patrol)\n- gt-7921 (await-work and plugin-run)\n- docs/wisp-architecture.md","status":"open","priority":1,"issue_type":"feature","created_at":"2025-12-22T13:24:43.158379-08:00","updated_at":"2025-12-22T13:24:43.158379-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:31:43.230007-08:00","closed_at":"2025-12-22T12:31:43.230007-08:00","close_reason":"Documentation complete. Created docs/propulsion-principle.md covering the One Rule, sling lifecycle, agent startup protocol, and examples/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} @@ -269,7 +269,7 @@ {"id":"gt-ca4v.7","title":"More branches to process?","description":"More branches to process?\n\nIf yes: Return to process-branch with next branch.\nIf no: Continue to generate-summary.\n\nTrack: branches processed, branches skipped (with reasons).\n\ninstantiated_from: mol-refinery-patrol\nstep: loop-check","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-22T17:13:47.746798-08:00","updated_at":"2025-12-22T17:13:47.746798-08:00","dependencies":[{"issue_id":"gt-ca4v.7","depends_on_id":"gt-ca4v","type":"parent-child","created_at":"2025-12-22T17:13:47.747125-08:00","created_by":"daemon"},{"issue_id":"gt-ca4v.7","depends_on_id":"gt-ca4v.6","type":"blocks","created_at":"2025-12-22T17:13:48.464174-08:00","created_by":"daemon"}]} {"id":"gt-ca4v.8","title":"Summarize this patrol cycle.","description":"Summarize this patrol cycle.\n\nInclude:\n- Branches processed (count, names)\n- Test results (pass/fail)\n- Issues filed (if any)\n- Branches skipped (with reasons)\n- Any escalations sent\n\nThis becomes the digest when the patrol is squashed.\n\ninstantiated_from: mol-refinery-patrol\nstep: generate-summary","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-22T17:13:47.827331-08:00","updated_at":"2025-12-22T17:13:47.827331-08:00","dependencies":[{"issue_id":"gt-ca4v.8","depends_on_id":"gt-ca4v","type":"parent-child","created_at":"2025-12-22T17:13:47.827682-08:00","created_by":"daemon"},{"issue_id":"gt-ca4v.8","depends_on_id":"gt-ca4v.7","type":"blocks","created_at":"2025-12-22T17:13:48.545582-08:00","created_by":"daemon"}]} {"id":"gt-ca4v.9","title":"Check own context usage.","description":"Check own context usage.\n\nIf context is HIGH (\u003e80%):\n- Write handoff summary\n- Prepare for burn/respawn\n\nIf context is LOW:\n- Can continue processing\n\ninstantiated_from: mol-refinery-patrol\nstep: context-check","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-22T17:13:47.909098-08:00","updated_at":"2025-12-22T17:13:47.909098-08:00","dependencies":[{"issue_id":"gt-ca4v.9","depends_on_id":"gt-ca4v","type":"parent-child","created_at":"2025-12-22T17:13:47.909418-08:00","created_by":"daemon"},{"issue_id":"gt-ca4v.9","depends_on_id":"gt-ca4v.8","type":"blocks","created_at":"2025-12-22T17:13:48.621628-08:00","created_by":"daemon"}]} -{"id":"gt-caih","title":"Witness handoff bead state persistence","description":"Implement state persistence for Witness across wisp cycles.\n\n## Problem\nWisps burn between cycles, but Witness needs to remember:\n- Which workers have been nudged\n- How many times (nudge_count)\n- When was last nudge\n- Last observed activity\n\n## Solution\nWitness handoff bead with worker_states field:\n\n```json\n{\n \"id\": \"gt-witness-state\",\n \"type\": \"handoff\",\n \"assignee\": \"\u003crig\u003e/witness\",\n \"pinned\": true,\n \"worker_states\": {\n \"furiosa\": {\n \"issue\": \"gt-123\",\n \"nudge_count\": 2,\n \"last_nudge\": \"2024-12-22T10:00:00Z\"\n }\n },\n \"last_patrol\": \"2024-12-22T10:05:00Z\"\n}\n```\n\n## Implementation\n1. On patrol start: bd show \u003cwitness-handoff-id\u003e to load state\n2. During patrol: update in-memory state\n3. On save-state step: bd update to persist\n4. State survives wisp burn/squash\n\n## Depends on\n- gt-83k0 (mol-witness-patrol definition)","status":"in_progress","priority":1,"issue_type":"task","assignee":"gastown/furiosa","created_at":"2025-12-22T16:42:57.427131-08:00","updated_at":"2025-12-23T00:06:13.00402-08:00","dependencies":[{"issue_id":"gt-caih","depends_on_id":"gt-83k0","type":"blocks","created_at":"2025-12-22T16:43:59.609821-08:00","created_by":"daemon"}]} +{"id":"gt-caih","title":"Witness handoff bead state persistence","description":"Implement state persistence for Witness across wisp cycles.\n\n## Problem\nWisps burn between cycles, but Witness needs to remember:\n- Which workers have been nudged\n- How many times (nudge_count)\n- When was last nudge\n- Last observed activity\n\n## Solution\nWitness handoff bead with worker_states field:\n\n```json\n{\n \"id\": \"gt-witness-state\",\n \"type\": \"handoff\",\n \"assignee\": \"\u003crig\u003e/witness\",\n \"pinned\": true,\n \"worker_states\": {\n \"furiosa\": {\n \"issue\": \"gt-123\",\n \"nudge_count\": 2,\n \"last_nudge\": \"2024-12-22T10:00:00Z\"\n }\n },\n \"last_patrol\": \"2024-12-22T10:05:00Z\"\n}\n```\n\n## Implementation\n1. On patrol start: bd show \u003cwitness-handoff-id\u003e to load state\n2. During patrol: update in-memory state\n3. On save-state step: bd update to persist\n4. State survives wisp burn/squash\n\n## Depends on\n- gt-83k0 (mol-witness-patrol definition)","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-22T16:42:57.427131-08:00","updated_at":"2025-12-22T16:42:57.427131-08:00","dependencies":[{"issue_id":"gt-caih","depends_on_id":"gt-83k0","type":"blocks","created_at":"2025-12-22T16:43:59.609821-08:00","created_by":"daemon"}]} {"id":"gt-caz","title":"Timed Beads: Scheduled recurring work","description":"## Summary\n\nTimed beads wake up periodically and get injected into the ready queue by the daemon.\n\n## Schema Extension\n\n```yaml\nid: gt-weekly-sync\ntype: task # or sentinel\nschedule: \"0 9 * * 1\" # cron: Monday 9am\n# OR\ninterval: 24h # every 24 hours\ntier: haiku # cheap model for routine checks\nnext_run: 2025-12-20T09:00:00Z\n```\n\n## Daemon Integration\n\nDaemon heartbeat loop:\n1. Check timed beads where `next_run \u003c= now`\n2. For each due bead:\n - Inject into ready queue (set status to open if needed)\n - Update `next_run` based on schedule/interval\n3. Witnesses pick up work via `bd ready`\n\n## Use Cases\n\n- Weekly team sync reminders\n- Daily health checks\n- Periodic cleanup tasks\n- Scheduled reports\n\n## Interaction with Pinned Beads\n\nA pinned bead can be timed - it wakes up periodically but never closes.\nThis is how you model \"background services\" in Gas Town.","status":"open","priority":2,"issue_type":"epic","created_at":"2025-12-18T18:07:39.665294-08:00","updated_at":"2025-12-18T18:07:39.665294-08:00"} {"id":"gt-cik","title":"Overseer Crew: User-managed persistent workspaces","description":"## Overview\n\nCrew workers are the overseer's (human's) personal workspaces within a rig. Unlike polecats which are witness-managed and ephemeral, crew workers are:\n\n- **Persistent**: Not auto-garbage-collected\n- **User-managed**: Overseer controls lifecycle\n- **Long-lived identities**: dave, emma, fred - recognizable names\n- **Gas Town integrated**: Mail, handoff mechanics work\n- **Tmux optional**: Can work in terminal directly\n\n## Directory Structure\n\n```\n\u003crig\u003e/\n polecats/ # Managed workers (witness controls)\n refinery/ # Merge queue processor\n witness/ # Pit boss\n crew/ # Overseer's personal workspaces\n dave/ # Full clone, persistent\n emma/ # Full clone, persistent\n fred/ # Full clone, persistent\n```\n\n## Key Differences from Polecats\n\n- Location: crew/ instead of polecats/\n- Lifecycle: User-managed, not witness-managed\n- Auto-cleanup: Never (polecats auto-cleanup on swarm land)\n- Issue assignment: Optional (polecats require it)\n- Tmux: Optional (polecats require it)\n- Mail \u0026 Handoff: Yes for both\n- Identity: Persistent (polecats are ephemeral)\n\n## CLI Commands\n\n- gt crew add \u003cname\u003e [--rig \u003crig\u003e] - Create crew workspace\n- gt crew list [--rig \u003crig\u003e] - List crew workspaces\n- gt crew at \u003crig\u003e/\u003cname\u003e - Attach to workspace (start session)\n- gt crew attach \u003cname\u003e - Attach (infer rig from cwd)\n- gt crew refresh \u003cname\u003e - Handoff + restart (context cycling)\n- gt crew remove \u003cname\u003e [--force] - Remove workspace\n- gt crew status [\u003cname\u003e] - Show workspace status\n\n## Design Notes\n\n- Crew workers use full git clones (not worktrees)\n- Optional beads integration via BEADS_DIR\n- Mail-to-self handoff works for context cycling\n- No witness monitoring or nudging\n- No automatic issue assignment required\n\n## Background\n\nUsers often maintain separate repo clones for serial agent work. This is tedious to set up manually. Crew workspaces bring these into Gas Town's infrastructure while keeping user control.","status":"closed","priority":1,"issue_type":"epic","created_at":"2025-12-16T16:47:37.529887-08:00","updated_at":"2025-12-16T20:59:46.13518-08:00","closed_at":"2025-12-16T20:59:46.13518-08:00"} {"id":"gt-cik.1","title":"Crew directory structure and config","description":"Add crew/ directory support to rig structure. Include:\n- crew/ as peer to polecats/, refinery/, witness/\n- Crew worker subdirectories with full git clones\n- Optional BEADS_DIR configuration for beads integration\n- Crew state tracking (separate from polecat state)","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-16T16:48:00.285499-08:00","updated_at":"2025-12-16T20:47:23.003869-08:00","closed_at":"2025-12-16T20:31:23.558027-08:00","dependencies":[{"issue_id":"gt-cik.1","depends_on_id":"gt-cik","type":"parent-child","created_at":"2025-12-16T16:48:00.28789-08:00","created_by":"daemon"}]} @@ -414,7 +414,7 @@ {"id":"gt-iua8","title":"Merge: gt-frs","description":"branch: polecat/Slit\ntarget: main\nsource_issue: gt-frs\nrig: gastown","status":"closed","priority":2,"issue_type":"merge-request","created_at":"2025-12-19T16:30:05.529099-08:00","updated_at":"2025-12-19T18:26:14.104887-08:00","closed_at":"2025-12-19T17:48:44.654109-08:00"} {"id":"gt-j4nu","title":"Merge: gt-g44u.3","description":"branch: polecat/Ace\ntarget: main\nsource_issue: gt-g44u.3\nrig: gastown","status":"closed","priority":0,"issue_type":"merge-request","created_at":"2025-12-19T16:14:52.767156-08:00","updated_at":"2025-12-19T17:35:36.663796-08:00","closed_at":"2025-12-19T17:35:36.663796-08:00"} {"id":"gt-j5tk","title":"Work assignment messages should auto-close on completion","description":"When a polecat completes work on an issue, the work assignment message (msg-type:task) stays open. Found 7 stale work assignments in gastown after swarm completed.\n\nProposal: When bd close is called on an issue, auto-close any work assignment messages that reference that issue in their body.\n\nAlternative: Work assignment messages could use a different lifecycle - perhaps they should be acked (closed) when the polecat starts working, not when they finish.","status":"open","priority":2,"issue_type":"feature","created_at":"2025-12-20T03:12:28.403974-08:00","updated_at":"2025-12-20T03:12:28.403974-08:00"} -{"id":"gt-j6s8","title":"Refinery startup: bond mol-refinery-patrol on start","description":"Wire up Refinery to automatically bond its patrol molecule on startup.\n\n## Current state\n- mol-refinery-patrol exists in builtin_molecules.go\n- prompts/roles/refinery.md describes the protocol\n- Refinery doesn't auto-bond on startup\n\n## Desired behavior\nOn Refinery session start:\n1. gt prime detects RoleRefinery\n2. Check for existing in-progress patrol: bd list --status=in_progress --assignee=refinery\n3. If found: resume from current step\n4. If not found: bd mol bond mol-refinery-patrol --wisp\n5. Output patrol context to agent\n\n## Implementation options\nA) Add to gt prime (outputRefineryPatrolContext)\nB) Add startup hook in refinery CLAUDE.md\nC) Both (prime detects, template reinforces)\n\n## Testing\n- Start refinery session\n- Verify patrol bonds automatically\n- Kill mid-patrol, restart, verify resumes\n\n## Depends on\n- gt-3x0z.10 (existing issue for Refinery patrol)","status":"closed","priority":1,"issue_type":"task","assignee":"gastown/dementus","created_at":"2025-12-22T16:43:34.739741-08:00","updated_at":"2025-12-23T00:10:46.503806-08:00","closed_at":"2025-12-23T00:10:46.503806-08:00","close_reason":"Implemented outputRefineryPatrolContext in gt prime. Auto-spawns mol-refinery-patrol wisp on Refinery startup when no active patrol exists."} +{"id":"gt-j6s8","title":"Refinery startup: bond mol-refinery-patrol on start","description":"Wire up Refinery to automatically bond its patrol molecule on startup.\n\n## Current state\n- mol-refinery-patrol exists in builtin_molecules.go\n- prompts/roles/refinery.md describes the protocol\n- Refinery doesn't auto-bond on startup\n\n## Desired behavior\nOn Refinery session start:\n1. gt prime detects RoleRefinery\n2. Check for existing in-progress patrol: bd list --status=in_progress --assignee=refinery\n3. If found: resume from current step\n4. If not found: bd mol bond mol-refinery-patrol --wisp\n5. Output patrol context to agent\n\n## Implementation options\nA) Add to gt prime (outputRefineryPatrolContext)\nB) Add startup hook in refinery CLAUDE.md\nC) Both (prime detects, template reinforces)\n\n## Testing\n- Start refinery session\n- Verify patrol bonds automatically\n- Kill mid-patrol, restart, verify resumes\n\n## Depends on\n- gt-3x0z.10 (existing issue for Refinery patrol)","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-22T16:43:34.739741-08:00","updated_at":"2025-12-22T16:43:34.739741-08:00"} {"id":"gt-j87","title":"Design: Work flow simulation and validation","description":"Validate GGT designs through simulation before implementation.\n\n## Validation Approaches\n\n### 1. Dry-Run Simulation (Recommended First)\nMayor walks through scenarios mentally/on paper:\n- \"If polecat Toast signals done with dirty git state, what happens?\"\n- \"If Witness context fills mid-verification, what state is lost?\"\n- \"If two polecats try to close same issue, what happens?\"\n\nCreate beads for any gaps discovered.\n\n### 2. Real Work in gastown-py\nUse Python Gas Town to stress-test assumptions:\n- Run actual batch work on test repos\n- Observe edge cases in practice\n- Document issues found\n\n### 3. Edge Case Analysis\nSystematic review of failure modes:\n- Agent crashes mid-operation\n- Network failures during sync\n- Concurrent access to shared state\n- Context limits hit at bad times\n\n## Key Scenarios to Validate\n\n- [ ] Witness session cycling (state preservation)\n- [ ] Polecat decommission with dirty state\n- [ ] Merge conflicts in queue\n- [ ] Beads sync conflicts between workers\n- [ ] Escalation path (stuck worker -\u003e Mayor)\n- [ ] Cross-rig communication\n- [ ] Federation mail routing (future)\n\n## Success Criteria\n\n- No data loss scenarios identified\n- Clear recovery paths for all failure modes\n- Edge cases either handled or documented as limitations\n- Design improves as model cognition improves\n\n## Output\n\nFor each scenario validated:\n1. Document in relevant bead if issue found\n2. Create new beads for missing functionality\n3. Update architecture.md if design changes","status":"open","priority":1,"issue_type":"epic","created_at":"2025-12-15T20:24:11.251841-08:00","updated_at":"2025-12-16T17:25:49.858717-08:00"} {"id":"gt-jgdx","title":"Digest: mol-deacon-patrol","description":"Test patrol cycle - first run, no actual work done","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-22T02:07:03.388821-08:00","updated_at":"2025-12-22T02:07:03.388821-08:00","closed_at":"2025-12-22T02:07:03.388793-08:00","close_reason":"Squashed from 5 wisps"} {"id":"gt-jpt","title":"Town-level beads: Real DB for coordination mail","description":"Implement Option A from mail redesign: Town gets real beads DB for coordination.\n\n## Background\n\nMail is now Beads. But currently:\n- Town .beads/redirect points to rig beads\n- mayor/mail/ has legacy JSONL files\n- Cross-rig coordination has no clear home\n\n## Design\n\nTown beads = coordination, cross-rig mail, mayor inbox, handoffs\nRig beads = project issues, work items\n\nMatches HOP hierarchy: platform \u003e project \u003e worker\n\n## Structure\n\n~/gt/\n .beads/ # REAL beads DB (prefix: gm-)\n mayor/\n town.json\n state.json # NO mail/ directory\n gastown/\n .beads/ # Rig beads (prefix: ga-)\n\n## Tasks\n\n1. Delete ~/gt/.beads/redirect\n2. Run bd init --prefix gm at ~/gt/ (town beads)\n3. Delete ~/gt/mayor/mail/ directory\n4. Update gt mail to use beads not JSONL\n5. Add mail fields (thread_id, reply_to, msg_type)\n6. Update gt prime for two-tier model\n7. Update docs/architecture.md\n\n## Addressing\n\n- mayor/ -\u003e town beads\n- rig/agent -\u003e rig beads\n- Cross-rig -\u003e town beads","status":"closed","priority":1,"issue_type":"epic","created_at":"2025-12-17T19:09:55.855955-08:00","updated_at":"2025-12-19T01:57:17.032558-08:00","closed_at":"2025-12-19T01:57:17.032558-08:00"} @@ -460,7 +460,7 @@ {"id":"gt-l6r9","title":"Test molecule","description":"Test","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-19T14:29:43.985973-08:00","updated_at":"2025-12-19T14:30:00.084138-08:00","closed_at":"2025-12-19T14:30:00.084138-08:00"} {"id":"gt-l7cd","title":"Work on gt-role-template: Refine witness/CLAUDE.md role t...","description":"Work on gt-role-template: Refine witness/CLAUDE.md role template. See issue for details. Run 'bd show gt-role-template' to see the full issue.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-20T03:47:29.414394-08:00","updated_at":"2025-12-20T03:54:13.699528-08:00","closed_at":"2025-12-20T03:54:13.699528-08:00"} {"id":"gt-l9g","title":"Beads epic templates for batch work patterns","description":"Optional: Define templates for common batch work patterns.\n\n## Concept\n\nA template encodes a workflow pattern that can be instantiated as beads:\n\n```yaml\n# templates/batch-basic.yaml\nname: basic-batch\ndescription: Simple batch work pattern\nphases:\n - name: startup\n issues:\n - title: \"Verify workers ready\"\n - name: working\n # Actual work issues added separately\n - name: cleanup\n issues:\n - title: \"Merge all branches\"\n - title: \"Clean up workers\"\n - title: \"Report to Mayor\"\n```\n\n## Usage\n\n```bash\ngt spawn --template basic-batch --epic gt-u1j --workers 3\n```\n\nCreates beads epic with template phases + actual work from gt-u1j children.\n\n## Decision Point\n\nTemplates are OPTIONAL. The core design (beads as state, multi-wave orchestration) works without templates. Templates are sugar for common patterns.\n\nConsider deferring to P3 or dropping entirely if beads epics with dependencies suffice.\n\n## Note\n\nNo \"swarm IDs\" involved - templates just pre-populate epic/issue structure.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-16T01:51:24.399235-08:00","updated_at":"2025-12-16T17:26:08.868396-08:00"} -{"id":"gt-ldk8","title":"Witness should verify polecat submitted before stopping session","description":"## Problem\n\nWitness stopped dementus's session before it could call `gt done`, losing the MR submission. I had to manually push and submit the branch.\n\n## Root Cause\n\nWitness cleanup is triggered by nudge/manual check rather than by receiving POLECAT_DONE message. When Witness cleans up based on issue status (closed), it doesn't wait for the polecat to complete its shutdown sequence.\n\n## Expected Behavior\n\nWitness should only stop a polecat session after:\n1. Receiving POLECAT_DONE message from that polecat, OR\n2. Timeout waiting for POLECAT_DONE after issue is closed\n\n## Current Behavior\n\nWitness stops sessions immediately when asked to check for completions, even if polecat hasn't called `gt done` yet.\n\n## Fix\n\nIn mol-witness-patrol inbox-check step:\n- Only clean up polecats that have sent POLECAT_DONE\n- For polecats with closed issues but no DONE message, nudge them to complete\n- Add timeout before force-killing","status":"in_progress","priority":1,"issue_type":"bug","assignee":"gastown/nux","created_at":"2025-12-22T23:54:12.969528-08:00","updated_at":"2025-12-23T00:10:56.589919-08:00"} +{"id":"gt-ldk8","title":"Witness should verify polecat submitted before stopping session","description":"## Problem\n\nWitness stopped dementus's session before it could call `gt done`, losing the MR submission. I had to manually push and submit the branch.\n\n## Root Cause\n\nWitness cleanup is triggered by nudge/manual check rather than by receiving POLECAT_DONE message. When Witness cleans up based on issue status (closed), it doesn't wait for the polecat to complete its shutdown sequence.\n\n## Expected Behavior\n\nWitness should only stop a polecat session after:\n1. Receiving POLECAT_DONE message from that polecat, OR\n2. Timeout waiting for POLECAT_DONE after issue is closed\n\n## Current Behavior\n\nWitness stops sessions immediately when asked to check for completions, even if polecat hasn't called `gt done` yet.\n\n## Fix\n\nIn mol-witness-patrol inbox-check step:\n- Only clean up polecats that have sent POLECAT_DONE\n- For polecats with closed issues but no DONE message, nudge them to complete\n- Add timeout before force-killing","status":"open","priority":1,"issue_type":"bug","created_at":"2025-12-22T23:54:12.969528-08:00","updated_at":"2025-12-22T23:54:12.969528-08:00"} {"id":"gt-ldm4","title":"verify-tests","description":"Run existing tests. Add new tests for new functionality.\nEnsure adequate coverage.\n\ngo test ./...\n\nFix any test failures before proceeding.\n\nDepends: implement","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-21T21:48:26.322056-08:00","updated_at":"2025-12-21T21:48:26.322056-08:00","dependencies":[{"issue_id":"gt-ldm4","depends_on_id":"gt-i4lo","type":"parent-child","created_at":"2025-12-21T21:48:26.326258-08:00","created_by":"stevey"},{"issue_id":"gt-ldm4","depends_on_id":"gt-vhby","type":"blocks","created_at":"2025-12-21T21:48:26.326815-08:00","created_by":"stevey"}],"wisp":true} {"id":"gt-le1a","title":"Merge: gt-3x1","description":"branch: polecat/Slit\ntarget: main\nsource_issue: gt-3x1\nrig: gastown","status":"closed","priority":1,"issue_type":"merge-request","created_at":"2025-12-19T14:53:47.674479-08:00","updated_at":"2025-12-19T18:30:24.050697-08:00","closed_at":"2025-12-19T18:30:24.0507-08:00"} {"id":"gt-leeb","title":"load-context","description":"Run gt prime and bd prime. Verify issue assignment.\nCheck inbox for any relevant messages.\n\nRead the assigned issue (gt-qwyu) and understand the requirements.\nIdentify any blockers or missing information.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-21T21:58:52.59974-08:00","updated_at":"2025-12-21T21:59:10.94207-08:00","closed_at":"2025-12-21T21:59:10.94207-08:00","close_reason":"test cleanup","dependencies":[{"issue_id":"gt-leeb","depends_on_id":"gt-q6hl","type":"parent-child","created_at":"2025-12-21T21:58:52.600633-08:00","created_by":"stevey"}],"wisp":true} @@ -643,7 +643,7 @@ {"id":"gt-upom","title":"Witness patrol: cleanup idle orphan polecats","description":"Add patrol step to find and cleanup polecats that are idle with no assigned issue. These orphans occur when polecats crash before sending DONE or Witness misses the message. Patrol should verify git is clean before removing worktree. Part of gt-rana.","status":"open","priority":2,"issue_type":"feature","created_at":"2025-12-21T23:09:41.756753-08:00","updated_at":"2025-12-21T23:09:41.756753-08:00"} {"id":"gt-us8","title":"Daemon: configurable heartbeat interval","description":"Heartbeat interval is hardcoded to 60s. Should be configurable via:\n- town.json config\n- Command line flag\n- Environment variable\n\nDefault 60s is reasonable but some deployments may want faster/slower.","status":"open","priority":3,"issue_type":"task","created_at":"2025-12-18T13:38:14.282216-08:00","updated_at":"2025-12-18T13:38:14.282216-08:00","dependencies":[{"issue_id":"gt-us8","depends_on_id":"gt-99m","type":"blocks","created_at":"2025-12-18T13:38:26.704111-08:00","created_by":"daemon"}]} {"id":"gt-usy0","title":"Merge: gt-3x0z.3","description":"branch: polecat/rictus\ntarget: main\nsource_issue: gt-3x0z.3\nrig: gastown","status":"closed","priority":2,"issue_type":"merge-request","created_at":"2025-12-21T16:03:43.535266-08:00","updated_at":"2025-12-21T17:20:27.505696-08:00","closed_at":"2025-12-21T17:20:27.505696-08:00","close_reason":"ORPHANED: Branch never pushed, worktree deleted"} -{"id":"gt-utwc","title":"Self-mail should suppress tmux notification","description":"When sending mail to yourself (e.g., mayor sending to mayor/), the tmux notification shouldn't fire.\n\n**Rationale:**\n- Self-mail is intended for future-you (next session handoff)\n- Present-you just sent it, so you already know about it\n- The notification is redundant/confusing in this case\n\n**Fix:**\nSuppress tmux notification when sender == recipient address.","status":"closed","priority":3,"issue_type":"bug","created_at":"2025-12-22T17:55:39.573705-08:00","updated_at":"2025-12-22T23:58:02.827026-08:00","closed_at":"2025-12-22T23:58:02.827026-08:00","close_reason":"Skip tmux notification when sender == recipient"} +{"id":"gt-utwc","title":"Self-mail should suppress tmux notification","description":"When sending mail to yourself (e.g., mayor sending to mayor/), the tmux notification shouldn't fire.\n\n**Rationale:**\n- Self-mail is intended for future-you (next session handoff)\n- Present-you just sent it, so you already know about it\n- The notification is redundant/confusing in this case\n\n**Fix:**\nSuppress tmux notification when sender == recipient address.","status":"open","priority":3,"issue_type":"bug","created_at":"2025-12-22T17:55:39.573705-08:00","updated_at":"2025-12-22T17:55:39.573705-08:00"} {"id":"gt-uym5","title":"Implement gt mol status command","description":"Show what's on an agent's hook.\n\n```bash\ngt mol status [target]\n```\n\nOutput:\n- What's slung (molecule name, associated issue)\n- Current phase and progress\n- Whether it's a wisp\n- Next action hint\n\nIf no target, shows current agent's status.\n\nAcceptance:\n- [ ] Read pinned bead attachment\n- [ ] Display molecule/issue info\n- [ ] Show phase progress\n- [ ] Indicate wisp vs durable","status":"closed","priority":1,"issue_type":"task","assignee":"gastown/nux","created_at":"2025-12-22T03:17:34.679963-08:00","updated_at":"2025-12-22T12:34:19.942265-08:00","closed_at":"2025-12-22T12:34:19.942265-08:00","close_reason":"Implemented gt mol status command with mol alias, auto-detection, progress display, wisp detection, and next action hints"} {"id":"gt-v5hv","title":"Work on ga-y6b: Implement Refinery as Claude agent. Conve...","description":"Work on ga-y6b: Implement Refinery as Claude agent. Convert from shell to Claude agent that processes MRs in merge queue, runs tests, merges to integration branch. When done, submit MR (not PR) to integration branch for Refinery.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-19T22:58:17.576892-08:00","updated_at":"2025-12-19T23:23:22.778407-08:00","closed_at":"2025-12-19T23:23:22.778407-08:00"} {"id":"gt-v5k","title":"Design: Failure modes and recovery","description":"Document failure modes and recovery strategies for Gas Town operations.\n\n## Critical Failure Modes\n\n### 1. Agent Crash Mid-Operation\n\n**Scenario**: Polecat crashes while committing, Witness crashes while verifying\n\n**Detection**:\n- Session suddenly gone (tmux check fails)\n- State shows 'working' but no session\n- Heartbeat stops (for Witness)\n\n**Recovery**:\n- Doctor detects via ZombieSessionCheck\n- Capture any recoverable state\n- Reset agent state to 'idle'\n- For Witness: auto-restart via supervisor or manual gt witness start\n\n### 2. Git State Corruption\n\n**Scenario**: Merge conflict, failed rebase, detached HEAD\n\n**Detection**:\n- Git commands fail\n- Dirty state that won't commit\n- Branch diverged from origin\n\n**Recovery**:\n- gt doctor reports git health issues\n- Manual intervention recommended\n- Severe cases: remove clone, re-clone\n\n### 3. Beads Sync Conflict\n\n**Scenario**: Two polecats modify same issue\n\n**Detection**:\n- bd sync fails with conflict\n- Beads tombstone mechanism handles most cases\n\n**Recovery**:\n- Beads has last-write-wins semantics\n- bd sync --force in extreme cases\n- Issues may need manual dedup\n\n### 4. Tmux Failure\n\n**Scenario**: Tmux server crashes, socket issues\n\n**Detection**:\n- All sessions inaccessible\n- \"no server running\" errors\n\n**Recovery**:\n- Kill any orphan processes\n- tmux kill-server \u0026\u0026 tmux start-server\n- All agent states reset to idle\n- Re-spawn active work\n\n### 5. Claude API Issues\n\n**Scenario**: Rate limits, outages, context limits\n\n**Detection**:\n- Sessions hang or produce errors\n- Repeated failure patterns\n\n**Recovery**:\n- Exponential backoff (handled by Claude Code)\n- For context limits: session cycling (mail-to-self)\n- For outages: wait and retry\n\n### 6. Disk Full\n\n**Scenario**: Clones, logs, or beads fill disk\n\n**Detection**:\n- Write operations fail\n- git/bd commands error\n\n**Recovery**:\n- Clean up logs: rm ~/.gastown/logs/*\n- Remove old polecat clones\n- gt doctor --fix can clean some cruft\n\n### 7. Network Failure\n\n**Scenario**: Can't reach GitHub, API servers\n\n**Detection**:\n- git fetch/push fails\n- Claude sessions hang\n\n**Recovery**:\n- Work continues locally\n- Queue pushes for later\n- Sync when connectivity restored\n\n## Recovery Principles\n\n1. **Fail safe**: Prefer stopping over corrupting\n2. **State is recoverable**: Git and beads have recovery mechanisms\n3. **Doctor heals**: gt doctor --fix handles common issues\n4. **Emergency stop**: gt stop --all as last resort\n5. **Human escalation**: Some failures need Overseer intervention\n\n## Implementation\n\n- Document each failure mode in architecture.md\n- Ensure doctor checks cover detection\n- Add recovery hints to error messages\n- Log all failures for debugging","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-15T23:19:07.198289-08:00","updated_at":"2025-12-15T23:19:28.171942-08:00"} diff --git a/internal/beads/builtin_molecules.go b/internal/beads/builtin_molecules.go index b031af38..d19957a0 100644 --- a/internal/beads/builtin_molecules.go +++ b/internal/beads/builtin_molecules.go @@ -23,6 +23,7 @@ func BuiltinMolecules() []BuiltinMolecule { WitnessPatrolMolecule(), CrewSessionMolecule(), PolecatSessionMolecule(), + ReadyWorkMolecule(), } } @@ -1367,6 +1368,193 @@ Needs: execute`, } } +// ReadyWorkMolecule returns the ready-work molecule definition. +// This is an autonomous backlog processing patrol for crew workers. +// It's a vapor-phase molecule (wisp) that scans backlogs, selects work, +// and processes items until context is low. +func ReadyWorkMolecule() BuiltinMolecule { + return BuiltinMolecule{ + ID: "mol-ready-work", + Title: "Ready Work", + Description: `Autonomous backlog processing patrol for crew workers. + +**Phase**: vapor (wisp) - ephemeral patrol cycles +**Squash**: after each work item or context threshold + +This molecule enables crew workers to autonomously process backlog items +using an ROI heuristic. It scans multiple backlogs, selects the highest-value +achievable item, executes it, and loops until context is low. + +## Variables + +| Variable | Default | Description | +|----------|---------|-------------| +| backlog_priority | (see scan order) | Override backlog scan order | +| context_threshold | 20 | Percentage at which to handoff | +| max_items | unlimited | Maximum items to process per session | + +## Step: orient +Load context and check for interrupts. + +` + "```" + `bash +gt prime # Load Gas Town context +bd sync --from-main # Fresh beads state +` + "```" + ` + +Check for: +- Mail with overseer instructions: ` + "`gt mail inbox`" + ` +- Predecessor handoff: Look for 🤝 HANDOFF messages +- Current context state + +If overseer mail directs specific work, attach that instead of autonomous scan. +If handoff exists, resume from handoff state. + +## Step: scan-backlogs +Survey all backlogs in priority order. + +Scan order (highest to lowest priority): +1. ` + "`gh pr list --state open`" + ` - PRs need review/merge +2. ` + "`gh issue list --state open --label untriaged`" + ` - Untriaged issues +3. ` + "`bd ready`" + ` - Beads issues ready to work +4. ` + "`gh issue list --state open --label triaged`" + ` - Triaged GitHub issues + +For each backlog, capture: +- Total count of items +- Top 3-5 candidates with brief descriptions +- Estimated size category (small/medium/large) + +` + "```" + `bash +# Example scan +echo "=== PRs ===" && gh pr list --state open --limit 10 +echo "=== Untriaged ===" && gh issue list --state open --label untriaged --limit 10 +echo "=== Beads Ready ===" && bd ready +echo "=== Triaged ===" && gh issue list --state open --label triaged --limit 10 +` + "```" + ` + +If all backlogs empty: exit patrol (nothing to do). +Needs: orient + +## Step: select-work +Apply ROI heuristic to select best work item. + +**ROI Formula**: Impact / Effort, constrained by remaining context + +Evaluation criteria: +1. **Estimate size** - Tokens needed (small=1k, medium=5k, large=20k+) +2. **Check context capacity** - Can this item fit in remaining context? +3. **Weight by impact**: + - PRs: High (blocking others) → weight 3x + - Untriaged: Medium (needs triage) → weight 2x + - Beads ready: Medium (concrete work) → weight 2x + - Triaged GH: Lower (already processed) → weight 1x +4. **Adjust by priority** - P0/P1 issues get 2x multiplier + +Selection algorithm: +1. Filter to items that fit in remaining context +2. Score each: (impact_weight × priority_multiplier) / estimated_effort +3. Select highest scoring item +4. If tie: prefer PRs > untriaged > beads > triaged + +If no achievable items (all too large): goto handoff step. +Record selection rationale for audit. +Needs: scan-backlogs + +## Step: execute-work +Work the selected item based on its type. + +**For PRs (gh pr)**: +- Review the changes +- If good: approve and merge +- If issues: request changes with specific feedback +- Close or comment as appropriate + +**For untriaged issues (gh issue, no label)**: +- Read and understand the issue +- Add appropriate labels (bug, feature, enhancement, etc.) +- Set priority if determinable +- Convert to beads if actionable: ` + "`bd create --title=\"...\" --type=...`" + ` +- Close if duplicate/invalid/wontfix + +**For beads ready (bd)**: +- Claim: ` + "`bd update --status=in_progress`" + ` +- Implement the fix/feature +- Test changes +- Commit and push +- Close: ` + "`bd close `" + ` + +**For triaged GitHub issues**: +- Implement the fix/feature +- Create PR or push directly +- Link to issue: ` + "`Fixes #`" + ` +- Close issue when merged + +Commit regularly. Push changes. Update issue state. +Needs: select-work + +## Step: check-context +Assess context state after completing work item. + +` + "```" + `bash +# Estimate context usage (if tool available) +gt context --usage +` + "```" + ` + +Decision matrix: +| Context Used | Action | +|--------------|--------| +| < 60% | Loop to scan-backlogs (continue working) | +| 60-80% | One more small item, then handoff | +| > 80% | Goto handoff immediately | + +Also check: +- Items processed this session vs max_items limit +- Time elapsed (soft limit for long sessions) +- Any new high-priority mail that should interrupt + +If continuing: return to scan-backlogs step. +Needs: execute-work + +## Step: handoff +Prepare for session transition. + +1. **Summarize work completed**: + - Items processed (count and types) + - PRs reviewed/merged + - Issues triaged + - Beads closed + - Any issues filed + +2. **Note in-progress items**: + - If interrupted mid-work, record state + - File continuation issue if needed + +3. **Send handoff mail**: +` + "```" + `bash +gt mail send -s "🤝 HANDOFF: Ready-work patrol" -m " +## Completed This Session +- + +## Backlog State +- PRs remaining: +- Untriaged: +- Beads ready: +- Triaged: + +## Notes + +" +` + "```" + ` + +4. **Squash wisp to digest**: +` + "```" + `bash +bd mol squash --summary="Processed N items: X PRs, Y issues, Z beads" +` + "```" + ` + +5. **Exit for fresh session** - Successor picks up from handoff. +Needs: check-context`, + } +} + // SeedBuiltinMolecules creates all built-in molecules in the beads database. // It skips molecules that already exist (by title match). // Returns the number of molecules created. diff --git a/internal/beads/builtin_molecules_test.go b/internal/beads/builtin_molecules_test.go index 6c484c46..e609a334 100644 --- a/internal/beads/builtin_molecules_test.go +++ b/internal/beads/builtin_molecules_test.go @@ -5,8 +5,8 @@ import "testing" func TestBuiltinMolecules(t *testing.T) { molecules := BuiltinMolecules() - if len(molecules) != 12 { - t.Errorf("expected 12 built-in molecules, got %d", len(molecules)) + if len(molecules) != 13 { + t.Errorf("expected 13 built-in molecules, got %d", len(molecules)) } // Verify each molecule can be parsed and validated