bd sync: 2025-12-22 23:46:48

This commit is contained in:
Steve Yegge
2025-12-22 23:46:48 -08:00
parent a739904e79
commit 739e2b4d76

View File

@@ -389,6 +389,7 @@
{"id":"gt-i4i2","title":"Update deacon.md.tmpl with correct molecule commands","description":"The deacon prompt references commands that don't exist:\n- gt mol bond → should be bd mol run or gt mol arm\n- gt mol status → needs gt mol command tree first\n\nUpdate after gt mol command tree is implemented.\n\nDepends on: gt mol command tree issue","status":"closed","priority":1,"issue_type":"task","created_at":"2025-12-22T13:12:26.401739-08:00","updated_at":"2025-12-22T13:19:50.641767-08:00","closed_at":"2025-12-22T13:19:50.641767-08:00","close_reason":"Updated deacon.md with correct commands: gt mol status, bd mol spawn, gt mol squash","dependencies":[{"issue_id":"gt-i4i2","depends_on_id":"gt-x74c","type":"blocks","created_at":"2025-12-22T13:12:35.69774-08:00","created_by":"daemon"}]}
{"id":"gt-i4kq","title":"Update templates for Propulsion Principle","description":"Overhaul agent prompts to embody the Universal Gas Town Propulsion Principle:\n\n\u003e If you find something on your hook, YOU RUN IT.\n\nTemplates to update:\n- [ ] deacon.md.tmpl - Check hook first, no decision logic\n- [ ] polecat.md.tmpl - Propulsion startup, follow molecule\n- [ ] witness.md.tmpl - Sling wisps when spawning agents\n- [ ] refinery.md.tmpl - Accept slung epics\n\nKey changes:\n1. Remove 'should I run this?' decision points\n2. Add 'check your hook' as step 1 of startup\n3. Make molecule-following the default mode\n4. Simplify - agents don't think, they execute","status":"closed","priority":1,"issue_type":"task","assignee":"gastown/slit","created_at":"2025-12-22T03:17:46.464968-08:00","updated_at":"2025-12-22T23:44:05.155061-08:00","closed_at":"2025-12-22T23:44:05.155061-08:00","close_reason":"All four templates updated with Propulsion Principle","dependencies":[{"issue_id":"gt-i4kq","depends_on_id":"gt-4ev4","type":"blocks","created_at":"2025-12-22T12:10:42.245621-08:00","created_by":"daemon"},{"issue_id":"gt-i4kq","depends_on_id":"gt-uym5","type":"blocks","created_at":"2025-12-22T12:10:42.320803-08:00","created_by":"daemon"}]}
{"id":"gt-i4lo","title":"mol-polecat-work","description":"Full polecat lifecycle from assignment to decommission.\n\nThis proto enables nondeterministic idempotence for polecat work.\nA polecat that crashes after any step can restart, read its molecule state,\nand continue from the last completed step. No work is lost.\n\nVariables:\n- gt-test123 - The source issue ID being worked on","status":"in_progress","priority":2,"issue_type":"epic","assignee":"stevey","created_at":"2025-12-21T21:48:26.320963-08:00","updated_at":"2025-12-21T21:48:26.332718-08:00","wisp":true}
{"id":"gt-i6b9","title":"Merge: gt-cp2s","description":"branch: polecat/rictus\ntarget: main\nsource_issue: gt-cp2s\nrig: gastown","status":"open","priority":1,"issue_type":"merge-request","created_at":"2025-12-22T23:45:29.171329-08:00","updated_at":"2025-12-22T23:45:29.171329-08:00"}
{"id":"gt-ic0j","title":"🤝 HANDOFF: Timing fixes applied","description":"Fixed mayor attach timing bug. Completed: timing fix, gt-tulx, Emma beads-6v2. Remaining P1: gt-17zr, gt-kcee, gt-szsq. Run gt prime on startup.","status":"closed","priority":2,"issue_type":"message","created_at":"2025-12-18T22:19:57.731032-08:00","updated_at":"2025-12-18T23:28:33.950423-08:00","closed_at":"2025-12-18T23:28:33.950423-08:00"}
{"id":"gt-id36","title":"Deacon Kernel: event processing molecule architecture","description":"\nExtend the Deacon from \"health orchestrator\" to \"event processing kernel\" that runs a \nmolecule (rounds) each wake cycle, like an OS kernel scheduler.\n\n## Core Insight\n\nThe Deacon already has:\n- Wake cycle (daemon poke, timer, lifecycle request)\n- Mail as event queue\n- Health scanning\n- Lifecycle processing\n\nBut it is REACTIVE. This epic makes it PROACTIVE with a structured molecule:\n\n```\nDeacon Wake\n├── Step 0: Session Check (should I cycle myself?)\n├── Step 1: Health Scan (Mayor, Witnesses, Crew, Refineries)\n├── Step 2: Lifecycle Processing (cycle/restart/shutdown requests)\n├── Step 3: Plugin Execution (scheduled, event-triggered, human-requested)\n├── Step 4: Event Callbacks (timers, subscriptions)\n└── Step 5: Heartbeat + Wait\n```\n\n## Key Design Decisions\n\n1. **Session cycling first** - Token costs are quadratic with session length.\n Deacon should aggressively cycle to fresh sessions. First step of every\n wake is \"do I need a new session?\" based on context budget.\n\n2. **Pinned bead with marching orders** - A pinned bead (like gt prime for\n agents) defines the Deacon's rounds molecule. This is the Deacon's\n \"kernel\" - its operating loop.\n\n3. **Keepalive file for daemon quieting** - Instead of daemon tmux-poking\n the Deacon (which interrupts work), Deacon writes a keepalive file.\n Daemon reads it and backs off. Worst case: Deacon forgets, gets one\n extra heartbeat it squelches.\n\n4. **Molecule-based rounds** - The wake cycle becomes a molecule with steps.\n Each step can have plugins (inline attention). Steps can be added/modified\n by updating the pinned bead.\n\n## Architecture\n\n```\nGo Daemon (minimal, dumb)\n├── Reads {townRoot}/deacon/keepalive.json\n├── If fresh: do nothing\n├── If stale: poke Deacon (fallback)\n└── Process lifecycle requests (still daemon's job)\n\nDeacon (Claude agent, smart)\n├── Wakes: poke, timer, mail event\n├── Writes keepalive (quiets daemon for duration of rounds)\n├── Runs rounds molecule:\n│ ├── session-check: cycle if context budget low\n│ ├── health-scan: check agents, remediate\n│ ├── lifecycle: process requests\n│ ├── plugins: run scheduled/triggered plugins\n│ ├── events: process timer/event callbacks\n│ └── complete: update heartbeat, wait\n└── Reads marching orders from pinned bead\n```\n\n## Relation to Existing Work\n\n- Extends gt-5af (Deacon infrastructure) - CLOSED\n- Relates to gt-axz (Plugin architecture) - P3\n- Fits into phase3-deacon of gt-ngpz (Christmas Plan)\n- Enables gt-976 (Crew lifecycle) as part of health-scan step\n","status":"open","priority":1,"issue_type":"epic","created_at":"2025-12-20T21:46:08.076178-08:00","updated_at":"2025-12-20T21:46:08.076178-08:00","dependencies":[{"issue_id":"gt-id36","depends_on_id":"gt-976","type":"blocks","created_at":"2025-12-20T21:48:05.215593-08:00","created_by":"daemon"}]}
{"id":"gt-id36.1","title":"Deacon session cycling: first step of rounds","description":"\nFirst step of every Deacon wake cycle: check if a fresh session is needed.\n\n## Why First\n\nToken costs are quadratic with session length. A Deacon running for hours\naccumulates massive context. Better to cycle early and often.\n\n## Implementation\n\nAt wake, before doing anything else:\n\n1. Check context budget estimate (conversation turns, tool calls, etc.)\n2. If budget is low (e.g., \u003e50% consumed), request cycle:\n - Write handoff mail to self with current state\n - Request lifecycle: cycle via daemon\n - Daemon kills session, starts fresh\n - New session reads handoff mail, continues\n\n## Decision Criteria\n\n- Conversation turns \u003e N (configurable, default 50?)\n- Explicit \"context feels heavy\" signal from Claude\n- Time since last cycle \u003e M hours (configurable, default 4?)\n- Forced cycle on certain events (e.g., major config change)\n\n## State to Preserve in Handoff\n\n- Current health status\n- Pending lifecycle requests (in flight)\n- Plugin state (last run times, outcomes)\n- Any active timers\n\n## Relation to Daemon\n\nThe Deacon requests its own cycle via the same lifecycle mechanism:\n```\ngt mail send deacon/ -s \"LIFECYCLE: deacon/ requesting cycle\" -m \"...\"\n```\n\nDaemon sees this, kills gt-deacon session, respawn loop restarts it.\n","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-20T21:46:44.700695-08:00","updated_at":"2025-12-20T21:46:44.700695-08:00","dependencies":[{"issue_id":"gt-id36.1","depends_on_id":"gt-id36","type":"parent-child","created_at":"2025-12-20T21:46:44.703642-08:00","created_by":"daemon"}]}
@@ -592,6 +593,11 @@
{"id":"gt-th7","title":"Add agent abstraction layer to support non-Claude agents","description":"Currently Gas Town hardcodes 'claude --dangerously-skip-permissions' throughout the codebase for spawning agents. We should add an abstraction layer to support other AI agents (e.g., Gemini CLI, OpenAI agents, local models).\n\nLocations that spawn Claude:\n- internal/cmd/mayor.go:131\n- internal/cmd/deacon.go:150 \n- internal/cmd/witness.go:280\n- internal/cmd/crew.go (multiple locations)\n- internal/cmd/up.go:190, 229\n- internal/session/manager.go:146\n- internal/refinery/manager.go:207\n\nSuggested approach:\n1. Create an agent package with an interface\n2. Add configuration for agent type in town/rig config\n3. Replace hardcoded claude commands with agent.Spawn() calls\n4. Support agents: claude, gemini, openai, local (ollama, etc.)","status":"open","priority":3,"issue_type":"feature","created_at":"2025-12-20T15:11:15.931048-08:00","updated_at":"2025-12-20T15:26:54.236995-08:00"}
{"id":"gt-tl54","title":"MR: gt-test (main)","description":"branch: main\ntarget: main\nsource_issue: gt-test","status":"closed","priority":3,"issue_type":"merge-request","created_at":"2025-12-18T20:16:41.125975-08:00","updated_at":"2025-12-18T20:21:54.162843-08:00","closed_at":"2025-12-18T20:21:54.162843-08:00"}
{"id":"gt-tmm","title":"Polecat beads not synced with rig beads","description":"When gt spawn assigns an issue to a polecat, the polecat cannot find the issue because:\n\n1. Rig beads at /gt/gastown/.beads contains gt-th7\n2. Polecat beads at /gt/gastown/polecats/dementus/.beads does NOT have gt-th7\n3. bd sync in polecat dir pulls from beads-sync branch which doesn't have the new issue\n4. Rig bd sync uses 'main' branch, causing a branch mismatch\n\nThe polecat gets a work assignment for an issue it literally cannot see.\n\n## Root Cause\n\n- Rig beads and polecat beads are separate git-tracked copies\n- No mechanism to propagate newly created issues from rig to polecats before assignment\n- Sync branch configuration mismatch between rig and polecats\n\n## Fix Options\n\n1. gt spawn should sync rig beads before assigning work\n2. gt spawn should sync polecat beads after assignment\n3. Use shared beads (symlink or same DB) instead of copies\n4. Push new issues immediately on create","notes":"Note: This sync mismatch is resolved by gt-9nf (fresh polecats). Rather than fixing sync between stale clones, we'll always create fresh worktrees. This issue documents the root cause for posterity.","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-12-20T15:17:10.158624-08:00","updated_at":"2025-12-21T10:12:57.282455-08:00","closed_at":"2025-12-21T10:12:57.282455-08:00","close_reason":"Fixed by gt-9nf: fresh polecats now use shared rig beads via redirect"}
{"id":"gt-tnca","title":"Design mol-ready-work patrol for crew workers","description":"## Summary\n\nDesign and implement a protomolecule (mol-ready-work) that enables crew workers to autonomously work through backlogs when the overseer is away. This replaces the normal \"await instructions\" patrol step with productive backlog processing.\n\n## Context\n\nCrew workers like dave/joe are persistent, user-managed agents. Currently their patrol loop has an \"await instructions\" step that idles. We want an alternative: sling mol-ready-work at them and they crank through backlogs until:\n- The overseer interrupts with new instructions\n- Context fills up (request handoff)\n- Backlogs are empty\n\n## Backlogs (Priority Order)\n\n1. **Open PRs** - Review/merge pending pull requests\n2. **Untriaged GH issues** - New issues needing triage\n3. **Open beads work** - bd ready items (unblocked issues)\n4. **Triaged GH issues** - Bugs/features to implement\n\n## Key Features\n\n### ROI-Based Selection\nInstead of strict priority, agent applies ROI heuristic:\n- Size estimate (fits in remaining context?)\n- Achievability (has all needed info?)\n- Impact (priority + type weight)\n- Pick highest-value achievable item\n\n### Context Management\n- Check token usage after each work item\n- Request handoff before running out\n- Leave clear handoff notes (mail to self)\n- Next session picks up the patrol\n\n### Patrol Loop Structure\n```\norient → scan-backlogs → select-work → execute-work → check-context → (loop or handoff)\n```\n\n## Design Questions\n\n1. How does gt sling work? Does it exist?\n2. How does this interact with the normal crew patrol?\n3. Should the molecule go in Gas Town catalog or per-rig?\n4. How does bonding work for discovered work during execution?\n5. Should this be a wisp (ephemeral) or mol (persistent)?\n\n## Acceptance Criteria\n\n- [ ] mol-ready-work protomolecule defined in catalog\n- [ ] gt sling command implemented (or existing mechanism documented)\n- [ ] Context-checking step works with agent token awareness\n- [ ] Handoff mechanism integrates with gt mail\n- [ ] Documentation for crew workers on using the patrol","status":"open","priority":2,"issue_type":"epic","created_at":"2025-12-22T23:45:40.63509-08:00","updated_at":"2025-12-22T23:45:40.63509-08:00"}
{"id":"gt-tnca.1","title":"Draft mol-ready-work protomolecule definition","description":"Draft the actual protomolecule definition in markdown format.\n\n## Molecule Structure\n\n```markdown\n## Molecule: ready-work\nAutonomous backlog processing patrol for crew workers.\n\nPhase: vapor (wisp) - ephemeral patrol cycles\nSquash: after each work item or context threshold\n\n## Step: orient\nLoad context and check for interrupts:\n- Read mail for overseer instructions\n- Check for predecessor handoff\n- Load current context state\n\n## Step: scan-backlogs\nSurvey all backlogs in priority order:\n1. gh pr list --state open\n2. gh issue list --state open --label untriaged (or no label)\n3. bd ready\n4. gh issue list --state open --label triaged\n\nCapture counts and candidates.\n\nNeeds: orient\n\n## Step: select-work\nApply ROI heuristic to select best work item:\n- Estimate size (tokens needed)\n- Check remaining context capacity\n- Weight by impact (priority, type)\n- Select highest ROI achievable item\n- If empty: exit patrol\n\nNeeds: scan-backlogs\n\n## Step: execute-work\nWork the selected item:\n- For PRs: review, request changes, or merge\n- For untriaged: triage and label\n- For beads: implement and close\n- For triaged GH: implement fix\n\nCommit, push, close/update as appropriate.\n\nNeeds: select-work\n\n## Step: check-context\nAssess context state:\n- Estimate remaining capacity\n- If \u003c 20%: goto handoff\n- If ok: loop to scan-backlogs\n\nNeeds: execute-work\n\n## Step: handoff\nPrepare for session transition:\n- Summarize work completed this cycle\n- Note any in-progress items\n- Send handoff mail to self\n- Squash wisp to digest\n- Exit for fresh session\n\nNeeds: check-context\n```\n\n## Variables\n\n- `backlog_priority`: Override backlog scan order\n- `context_threshold`: Percentage at which to handoff (default: 20)\n- `max_items`: Maximum items to process per session\n\n## Notes\n\n- This is a vapor-phase molecule (wisp)\n- Each work item should squash to a digest\n- The patrol itself squashes at handoff","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-22T23:46:00.012418-08:00","updated_at":"2025-12-22T23:46:00.012418-08:00","dependencies":[{"issue_id":"gt-tnca.1","depends_on_id":"gt-tnca","type":"parent-child","created_at":"2025-12-22T23:46:00.012887-08:00","created_by":"daemon"}]}
{"id":"gt-tnca.2","title":"Implement context-checking for agent sessions","description":"Implement the context-checking step that allows agents to assess their remaining context capacity.\n\n## Challenge\n\nAgents don't have direct access to token counts. Need heuristics:\n\n### Approach 1: Message count heuristic\n- Count messages in conversation\n- Estimate tokens per message\n- Compare to model's context window\n\n### Approach 2: External tool\n- Claude Code could expose a /context command\n- Returns estimated usage percentage\n- Agent queries before each work item\n\n### Approach 3: Conservative fixed limits\n- After N work items, always handoff\n- Simple but may waste context or handoff too early\n\n### Approach 4: Hook-based injection\n- SessionStart hook injects context estimate\n- Updated periodically via tool call\n\n## Recommendation\n\nStart with Approach 3 (fixed limits) as MVP:\n- Default: 3-5 work items per session\n- Agent can override via variable\n- Upgrade to smarter heuristics later\n\n## Integration\n\n- Add check-context step to mol-ready-work\n- Implement handoff trigger logic\n- Test with various context states","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-22T23:46:28.414584-08:00","updated_at":"2025-12-22T23:46:28.414584-08:00","dependencies":[{"issue_id":"gt-tnca.2","depends_on_id":"gt-tnca","type":"parent-child","created_at":"2025-12-22T23:46:28.414964-08:00","created_by":"daemon"}]}
{"id":"gt-tnca.3","title":"Implement/document gt sling mechanism","description":"Investigate and implement the gt sling command for attaching molecules to crew workers. Check if gt sling exists, design the flow (mail-based vs direct pin vs wisp spawn), implement in gastown CLI, integrate with bd mol/wisp/pin commands.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-22T23:46:38.592538-08:00","updated_at":"2025-12-22T23:46:38.592538-08:00","dependencies":[{"issue_id":"gt-tnca.3","depends_on_id":"gt-tnca","type":"parent-child","created_at":"2025-12-22T23:46:38.592961-08:00","created_by":"daemon"}]}
{"id":"gt-tnca.4","title":"Document crew worker patrol integration","description":"Document how mol-ready-work integrates with crew worker workflow. Cover: starting the patrol, patrol vs normal operation, backlog configuration, handoff mechanics, discovered work handling. Update CLAUDE.md with patrol section.","status":"open","priority":3,"issue_type":"task","created_at":"2025-12-22T23:46:38.867975-08:00","updated_at":"2025-12-22T23:46:38.867975-08:00","dependencies":[{"issue_id":"gt-tnca.4","depends_on_id":"gt-tnca","type":"parent-child","created_at":"2025-12-22T23:46:38.868332-08:00","created_by":"daemon"}]}
{"id":"gt-tnw","title":"MCP beads tools fail from polecat directories","description":"The beads MCP plugin (plugin:beads:beads) fails to find issues when invoked from polecat directories.\n\n## Observed\n- Polecat in /gt/gastown/polecats/dementus\n- MCP tool: plugin:beads:beads - show (issue_id: 'gt-th7')\n- Error: 'bd command failed: Error: no issue found matching gt-th7'\n\n## Expected\nMCP tools should work the same as running bd directly.\n\n## Note\nThis may be related to gt-tmm (beads sync issue) rather than an MCP-specific bug. The MCP tool uses bd under the hood, and bd can't find the issue because the polecat's beads database is stale.","status":"open","priority":2,"issue_type":"bug","created_at":"2025-12-20T15:17:33.135931-08:00","updated_at":"2025-12-20T15:17:33.135931-08:00"}
{"id":"gt-ts4u","title":"Merge: gt-h5n.5","description":"branch: polecat/Scabrous\ntarget: main\nsource_issue: gt-h5n.5\nrig: gastown","status":"closed","priority":1,"issue_type":"merge-request","created_at":"2025-12-19T14:53:43.268861-08:00","updated_at":"2025-12-20T23:17:25.78812-08:00","closed_at":"2025-12-20T23:17:25.78812-08:00","close_reason":"Branches nuked, MRs obsolete"}
{"id":"gt-tubn","title":"Track operational stats as entity/audit beads","description":"Witness and refinery track operational stats in JSON files:\n- total_merged, today_merged, total_failed (refinery)\n- total_checks, total_nudges, total_escalations (witness)\n\nFor HOP entity CV tracking, these could become:\n- type=audit beads (daily roll-ups of operational metrics)\n- Entity chain entries showing validator activity\n\nThis provides observability and contributes to entity reputation tracking (e.g., refinery X has merged 500 PRs with 2% failure rate).\n\nNot critical for launch but aligns with HOP Platform of Platforms vision.","status":"open","priority":4,"issue_type":"feature","created_at":"2025-12-21T22:07:30.404073-08:00","updated_at":"2025-12-21T22:07:30.404073-08:00"}