bd sync: 2025-12-29 17:12:43
This commit is contained in:
Steve Yegge
@@ -1 +1 @@
|
||||
56832
|
||||
36155
|
||||
|
||||
@@ -268,10 +268,10 @@
|
||||
{"id":"gt-eph-7gy","title":"mol-deacon-patrol","description":"Mayor's daemon patrol loop.\n\nThe Deacon is the Mayor's background process that runs continuously, handling callbacks, monitoring rig health, and performing cleanup. Each patrol cycle runs these steps in sequence, then loops or exits.","status":"closed","priority":2,"issue_type":"epic","created_at":"2025-12-28T02:01:03.365622-08:00","updated_at":"2025-12-28T05:39:40.760566-08:00","closed_at":"2025-12-28T05:39:40.760566-08:00"}
|
||||
{"id":"gt-eph-89x","title":"mol-deacon-patrol","description":"Mayor's daemon patrol loop.\n\nThe Deacon is the Mayor's background process that runs continuously, handling callbacks, monitoring rig health, and performing cleanup. Each patrol cycle runs these steps in sequence, then loops or exits.\n\n## Second-Order Monitoring\n\nWitnesses send WITNESS_PING messages to verify the Deacon is alive. This\nprevents the \"who watches the watchers\" problem - if the Deacon dies,\nWitnesses detect it and escalate to the Mayor.\n\nThe Deacon's agent bead last_activity timestamp is updated during each patrol\ncycle. Witnesses check this timestamp to verify health.","status":"closed","priority":2,"issue_type":"epic","created_at":"2025-12-28T13:08:55.447783-08:00","updated_at":"2025-12-28T13:10:26.371776-08:00","closed_at":"2025-12-28T13:10:26.371776-08:00"}
|
||||
{"id":"gt-eph-8fu","title":"Nudge newly spawned polecats","description":"Nudge newly spawned polecats that are ready for input.\n\nWhen polecats are spawned, their Claude session takes 10-20 seconds to initialize. The spawn command returns immediately without waiting. This step finds spawned polecats that are now ready and sends them a trigger to start working.\n\n**ZFC-Compliant Observation** (AI observes AI):\n\n```bash\n# View pending spawns with captured terminal output\ngt deacon pending\n```\n\nFor each pending session, analyze the captured output:\n- Look for Claude's prompt indicator \"\u003e \" at the start of a line\n- If prompt is visible, Claude is ready for input\n- Make the judgment call yourself - you're the AI observer\n\nFor each ready polecat:\n```bash\n# 1. Trigger the polecat\ngt nudge \u003csession\u003e \"Begin.\"\n\n# 2. Clear from pending list\ngt deacon pending \u003csession\u003e\n```\n\nThis triggers the UserPromptSubmit hook, which injects mail so the polecat sees its assignment.\n\n**Bootstrap mode** (daemon-only, no AI available):\nThe daemon uses `gt deacon trigger-pending` with regex detection. This ZFC violation is acceptable during cold startup when no AI agent is running yet.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T09:55:41.718169-08:00","updated_at":"2025-12-28T09:55:41.71817-08:00","dependencies":[{"issue_id":"gt-eph-8fu","depends_on_id":"gt-eph-hfj","type":"parent-child","created_at":"2025-12-28T09:55:41.727407-08:00","created_by":"deacon"},{"issue_id":"gt-eph-8fu","depends_on_id":"gt-eph-5c8","type":"blocks","created_at":"2025-12-28T09:55:41.782453-08:00","created_by":"deacon"}]}
|
||||
{"id":"gt-eph-acp","title":"mol-deacon-patrol","description":"Mayor's daemon patrol loop.\n\nThe Deacon is the Mayor's background process that runs continuously, handling callbacks, monitoring rig health, and performing cleanup. Each patrol cycle runs these steps in sequence, then loops or exits.\n\n## Second-Order Monitoring\n\nWitnesses send WITNESS_PING messages to verify the Deacon is alive. This\nprevents the \"who watches the watchers\" problem - if the Deacon dies,\nWitnesses detect it and escalate to the Mayor.\n\nThe Deacon's agent bead last_activity timestamp is updated during each patrol\ncycle. Witnesses check this timestamp to verify health.","status":"hooked","priority":2,"issue_type":"epic","created_at":"2025-12-28T15:57:11.334141-08:00","updated_at":"2025-12-28T15:57:18.365848-08:00"}
|
||||
{"id":"gt-eph-bf1","title":"Check own context limit","description":"Check own context limit.\n\nThe Deacon runs in a Claude session with finite context. Check if approaching the limit:\n\n```bash\ngt context --usage\n```\n\nIf context is high (\u003e80%), prepare for handoff:\n- Summarize current state\n- Note any pending work\n- Write handoff to molecule state\n\nThis enables the Deacon to burn and respawn cleanly.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T09:55:41.719859-08:00","updated_at":"2025-12-28T09:55:41.719859-08:00","dependencies":[{"issue_id":"gt-eph-bf1","depends_on_id":"gt-eph-hfj","type":"parent-child","created_at":"2025-12-28T09:55:41.768581-08:00","created_by":"deacon"},{"issue_id":"gt-eph-bf1","depends_on_id":"gt-eph-lm1","type":"blocks","created_at":"2025-12-28T09:55:41.833279-08:00","created_by":"deacon"}]}
|
||||
{"id":"gt-eph-cfu","title":"Check own context limit","description":"Check own context limit.\n\nThe Deacon runs in a Claude session with finite context. Check if approaching the limit:\n\n```bash\ngt context --usage\n```\n\nIf context is high (\u003e80%), prepare for handoff:\n- Summarize current state\n- Note any pending work\n- Write handoff to molecule state\n\nThis enables the Deacon to burn and respawn cleanly.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-28T09:53:46.12348-08:00","updated_at":"2025-12-28T09:54:29.071412-08:00","closed_at":"2025-12-28T09:54:29.071412-08:00"}
|
||||
{"id":"gt-eph-ckj","title":"mol-deacon-patrol","description":"Mayor's daemon patrol loop.\n\nThe Deacon is the Mayor's background process that runs continuously, handling callbacks, monitoring rig health, and performing cleanup. Each patrol cycle runs these steps in sequence, then loops or exits.\n\n## Second-Order Monitoring\n\nWitnesses send WITNESS_PING messages to verify the Deacon is alive. This\nprevents the \"who watches the watchers\" problem - if the Deacon dies,\nWitnesses detect it and escalate to the Mayor.\n\nThe Deacon's agent bead last_activity timestamp is updated during each patrol\ncycle. Witnesses check this timestamp to verify health.","status":"open","priority":2,"issue_type":"epic","created_at":"2025-12-28T11:22:36.024308-08:00","updated_at":"2025-12-28T11:22:36.024308-08:00"}
|
||||
{"id":"gt-eph-dhv","title":"mol-deacon-patrol","description":"Mayor's daemon patrol loop.\n\nThe Deacon is the Mayor's background process that runs continuously, handling callbacks, monitoring rig health, and performing cleanup. Each patrol cycle runs these steps in sequence, then loops or exits.\n\n## Second-Order Monitoring\n\nWitnesses send WITNESS_PING messages to verify the Deacon is alive. This\nprevents the \"who watches the watchers\" problem - if the Deacon dies,\nWitnesses detect it and escalate to the Mayor.\n\nThe Deacon's agent bead last_activity timestamp is updated during each patrol\ncycle. Witnesses check this timestamp to verify health.","status":"hooked","priority":2,"issue_type":"epic","created_at":"2025-12-28T15:52:49.698851-08:00","updated_at":"2025-12-28T15:52:57.067866-08:00"}
|
||||
{"id":"gt-eph-ei9","title":"Evaluate pending async gates","description":"Evaluate pending async gates.\n\nGates are async coordination primitives that block until conditions are met.\nThe Deacon is responsible for monitoring gates and closing them when ready.\n\n**Timer gates** (await_type: timer):\nCheck if elapsed time since creation exceeds the timeout duration.\n\n```bash\n# List all open gates\nbd gate list --json\n\n# For each timer gate, check if elapsed:\n# - CreatedAt + Timeout \u003c Now → gate is ready to close\n# - Close with: bd gate close \u003cid\u003e --reason \"Timer elapsed\"\n```\n\n**GitHub gates** (await_type: gh:run, gh:pr) - handled in separate step.\n\n**Human/Mail gates** - require external input, skip here.\n\nAfter closing a gate, the Waiters field contains mail addresses to notify.\nSend a brief notification to each waiter that the gate has cleared.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T09:55:41.718473-08:00","updated_at":"2025-12-28T09:55:41.718473-08:00","dependencies":[{"issue_id":"gt-eph-ei9","depends_on_id":"gt-eph-hfj","type":"parent-child","created_at":"2025-12-28T09:55:41.734258-08:00","created_by":"deacon"},{"issue_id":"gt-eph-ei9","depends_on_id":"gt-eph-5c8","type":"blocks","created_at":"2025-12-28T09:55:41.789441-08:00","created_by":"deacon"}]}
|
||||
{"id":"gt-eph-gf1","title":"Execute registered plugins","description":"Execute registered plugins.\n\nScan ~/gt/plugins/ for plugin directories. Each plugin has a plugin.md with YAML frontmatter defining its gate (when to run) and instructions (what to do).\n\nSee docs/deacon-plugins.md for full documentation.\n\nGate types:\n- cooldown: Time since last run (e.g., 24h)\n- cron: Schedule-based (e.g., \"0 9 * * *\")\n- condition: Metric threshold (e.g., wisp count \u003e 50)\n- event: Trigger-based (e.g., startup, heartbeat)\n\nFor each plugin:\n1. Read plugin.md frontmatter to check gate\n2. Compare against state.json (last run, etc.)\n3. If gate is open, execute the plugin\n\nPlugins marked parallel: true can run concurrently using Task tool subagents. Sequential plugins run one at a time in directory order.\n\nSkip this step if ~/gt/plugins/ does not exist or is empty.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T09:55:41.719043-08:00","updated_at":"2025-12-28T09:55:41.719043-08:00","dependencies":[{"issue_id":"gt-eph-gf1","depends_on_id":"gt-eph-hfj","type":"parent-child","created_at":"2025-12-28T09:55:41.747929-08:00","created_by":"deacon"},{"issue_id":"gt-eph-gf1","depends_on_id":"gt-eph-tc2","type":"blocks","created_at":"2025-12-28T09:55:41.810967-08:00","created_by":"deacon"}]}
|
||||
{"id":"gt-eph-hfj","title":"mol-deacon-patrol","description":"Mayor's daemon patrol loop.\n\nThe Deacon is the Mayor's background process that runs continuously, handling callbacks, monitoring rig health, and performing cleanup. Each patrol cycle runs these steps in sequence, then loops or exits.","status":"open","priority":2,"issue_type":"epic","created_at":"2025-12-28T09:55:41.717288-08:00","updated_at":"2025-12-28T09:55:41.717288-08:00"}
|
||||
@@ -424,10 +424,10 @@
|
||||
{"id":"gt-kt9qq","title":"Deacon Patrol","description":"Mayor's daemon patrol loop for handling callbacks, health checks, and cleanup.","status":"open","priority":2,"issue_type":"molecule","created_at":"2025-12-29T14:37:53.146706-08:00","created_by":"gastown/crew/max","updated_at":"2025-12-29T14:37:53.146706-08:00"}
|
||||
{"id":"gt-l3gfn","title":"Digest: mol-deacon-patrol","description":"Patrol 18: Quiet","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-25T07:29:32.029593-08:00","updated_at":"2025-12-25T07:29:32.029593-08:00","closed_at":"2025-12-25T07:29:32.029556-08:00"}
|
||||
{"id":"gt-l3o0k","title":"Update gastown to use 'ephemeral' instead of 'wisp' terminology","description":"After beads renames 'wisp' to 'ephemeral' (bd-o18s), update gastown code:\n\n- patrol_helpers.go: bd wisp create → bd ephemeral create (or new API)\n- doctor/wisp_check.go: rename to ephemeral_check.go\n- All references to Wisp field → Ephemeral\n\nDepends on: bd-o18s","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-26T20:16:44.91769-08:00","updated_at":"2025-12-26T20:16:44.91769-08:00","dependencies":[{"issue_id":"gt-l3o0k","depends_on_id":"external:beads:ephemeral-rename","type":"blocks","created_at":"2025-12-26T20:17:00.859719-08:00","created_by":"daemon"},{"issue_id":"gt-l3o0k","depends_on_id":"external:beads:bd-o18s","type":"blocks","created_at":"2025-12-26T20:17:51.026548-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-l6ro3","title":"Patrol Exponential Backoff System","description":"Cost-saving await-signal model for patrol agents.\n\n## The Problem\n\nPatrol agents (witness, refinery) poll continuously even when idle, burning API credits.\n\n## The Solution: Await-Signal\n\nAgents don't poll constantly. They **wait for a signal**, then **discover reality**.\n\n```\nPATROL LOOP:\n await-signal (just wake me)\n ↓ awake\n check-reality (mail, beads, hook, git)\n ↓\n work found? → DO WORK → loop\n ↓ no\n increase backoff → loop\n```\n\n**Key principle (ZFC-aligned):** Signal carries no semantic meaning - just 'wake up'.\nAgent discovers what to do by examining reality.\n\n## Two-Level Wake\n\n| Level | State | Command |\n|-------|-------|---------|\n| 1 | Running (backoff) | `gt nudge` clears backoff |\n| 2 | Asleep | `gt rig boot` starts session |\n\n**Boot+nudge pattern:**\n```bash\ngt rig boot \u003crig\u003e # Wake if asleep (idempotent)\ngt nudge \u003crig\u003e/witness 'wake' # Clear backoff if running\n```\n\n## Backoff Curve\n\nBase: 30s → 60s → 120s → 240s → ... → 10min cap\n\nResets on: nudge received, work found, deacon ping.\n\n## Reference\n\nSee ~/gt/docs/patrol-system-design.md (Await-Signal Model section)","status":"open","priority":2,"issue_type":"epic","created_at":"2025-12-28T22:31:05.32225-08:00","created_by":"mayor","updated_at":"2025-12-28T23:05:37.717126-08:00"}
|
||||
{"id":"gt-l6ro3.1","title":"Daemon activity detection and rig nudging","description":"Daemon monitors activity feed and nudges patrol agents when commands detected.\n\n## Implementation\n\n1. Daemon watches activity feed (or logs) for gt/bd command execution\n2. Track per-rig last-activity timestamps\n3. On activity in rig: nudge witness + refinery for that rig\n4. Nudge clears their backoff → immediate poll\n\n## Activity Sources\n\n- gt commands (sling, mail, polecat, etc.)\n- bd commands (create, update, close, sync, etc.)\n- Maybe: file writes in rig directories\n\n## Graceful Behavior\n\n- If agent session not running: no-op (not an error)\n- Activity detection is best-effort\n- Backoff still works without this (just slower wake)","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T22:31:24.266187-08:00","created_by":"mayor","updated_at":"2025-12-28T22:31:24.266187-08:00","dependencies":[{"issue_id":"gt-l6ro3.1","depends_on_id":"gt-l6ro3","type":"parent-child","created_at":"2025-12-28T22:31:24.266638-08:00","created_by":"daemon"},{"issue_id":"gt-l6ro3.1","depends_on_id":"gt-arjlu","type":"blocks","created_at":"2025-12-28T22:31:51.176239-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-l6ro3.2","title":"Deacon health pings clear agent backoff","description":"Deacon's periodic health checks also clear patrol agent backoff.\n\n## Current Flow (mol-deacon-patrol)\n\nDeacon already pings witnesses/refineries for health checks. These pings should:\n1. Verify agent is alive\n2. Clear their backoff as side effect\n\n## Implementation\n\nIn mol-deacon-patrol health-scan step:\n- gt nudge \u003crig\u003e/witness 'HEALTH_CHECK from deacon'\n- gt nudge \u003crig\u003e/refinery 'HEALTH_CHECK from deacon'\n\nReceiving agent:\n- Responds to prove liveness\n- Resets backoff to base interval\n\n## Ping Interval\n\nDeacon patrols every ~1-2 minutes. This ensures:\n- Maximum backoff is bounded by deacon ping interval\n- Even if daemon misses activity, deacon catches up","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T22:31:35.003984-08:00","created_by":"mayor","updated_at":"2025-12-28T22:31:35.003984-08:00","dependencies":[{"issue_id":"gt-l6ro3.2","depends_on_id":"gt-l6ro3","type":"parent-child","created_at":"2025-12-28T22:31:35.004499-08:00","created_by":"daemon"},{"issue_id":"gt-l6ro3.2","depends_on_id":"gt-arjlu","type":"blocks","created_at":"2025-12-28T22:31:51.206694-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-l6ro3.3","title":"Molecule await-signal step type","description":"Add await-signal as a molecule step type for patrol agents.\n\n## Step Definition\n\n```toml\n[[steps]]\nid = \"await-signal\"\ntype = \"wait\"\nbackoff = { base = \"30s\", multiplier = 2, max = \"10m\" }\ndescription = \"Wait for signal, then check reality\"\n```\n\n## Behavior\n\n1. Sleep for current backoff interval\n2. Wake immediately on nudge (or timeout expires)\n3. Proceed to next step (check-reality)\n4. If no work found, loop back with increased backoff\n5. If work found, reset backoff to base\n\n## Implementation Options\n\nA. Formula-level: Define in TOML, agent interprets\nB. Code-level: Agent implements wait loop with backoff\n\nOption A is cleaner but needs formula parser support.\nOption B works now but less declarative.\n\n## Used By\n\n- mol-witness-patrol (first step)\n- mol-refinery-patrol (first step)","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T23:06:11.638803-08:00","created_by":"mayor","updated_at":"2025-12-28T23:06:11.638803-08:00","dependencies":[{"issue_id":"gt-l6ro3.3","depends_on_id":"gt-l6ro3","type":"parent-child","created_at":"2025-12-28T23:06:11.63931-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-l6ro3","title":"Patrol Exponential Backoff System","description":"Cost-saving await-signal model for patrol agents.\n\n## The Problem\n\nPatrol agents (witness, refinery) poll continuously even when idle, burning API credits.\n\n## The Solution: Await-Signal\n\nAgents don't poll constantly. They **wait for a signal**, then **discover reality**.\n\n```\nPATROL LOOP:\n await-signal (just wake me)\n ↓ awake\n check-reality (mail, beads, hook, git)\n ↓\n work found? → DO WORK → loop\n ↓ no\n increase backoff → loop\n```\n\n**Key principle (ZFC-aligned):** Signal carries no semantic meaning - just 'wake up'.\nAgent discovers what to do by examining reality.\n\n## Two-Level Wake\n\n| Level | State | Command |\n|-------|-------|---------|\n| 1 | Running (backoff) | `gt nudge` clears backoff |\n| 2 | Asleep | `gt rig boot` starts session |\n\n**Boot+nudge pattern:**\n```bash\ngt rig boot \u003crig\u003e # Wake if asleep (idempotent)\ngt nudge \u003crig\u003e/witness 'wake' # Clear backoff if running\n```\n\n## Backoff Curve\n\nBase: 30s → 60s → 120s → 240s → ... → 10min cap\n\nResets on: nudge received, work found, deacon ping.\n\n## Reference\n\nSee ~/gt/docs/patrol-system-design.md (Await-Signal Model section)","status":"open","priority":2,"issue_type":"epic","created_at":"2025-12-28T22:31:05.32225-08:00","created_by":"mayor","updated_at":"2025-12-28T23:05:37.717126-08:00","dependencies":[{"issue_id":"gt-l6ro3","depends_on_id":"gt-vdprb","type":"blocks","created_at":"2025-12-29T17:03:39.527-08:00","created_by":"mayor"}]}
|
||||
{"id":"gt-l6ro3.1","title":"Daemon activity detection and rig nudging","description":"Daemon monitors activity feed and nudges patrol agents when commands detected.\n\n## Implementation\n\n1. Daemon watches activity feed (or logs) for gt/bd command execution\n2. Track per-rig last-activity timestamps\n3. On activity in rig: nudge witness + refinery for that rig\n4. Nudge clears their backoff → immediate poll\n\n## Activity Sources\n\n- gt commands (sling, mail, polecat, etc.)\n- bd commands (create, update, close, sync, etc.)\n- Maybe: file writes in rig directories\n\n## Graceful Behavior\n\n- If agent session not running: no-op (not an error)\n- Activity detection is best-effort\n- Backoff still works without this (just slower wake)","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-28T22:31:24.266187-08:00","created_by":"mayor","updated_at":"2025-12-29T17:08:36.965815-08:00","closed_at":"2025-12-29T17:08:36.965815-08:00","close_reason":"Obsoleted by feed-based wake model (gt-vdprb). Agents subscribe directly to feed; daemon does not mediate activity detection.","dependencies":[{"issue_id":"gt-l6ro3.1","depends_on_id":"gt-l6ro3","type":"parent-child","created_at":"2025-12-28T22:31:24.266638-08:00","created_by":"daemon"},{"issue_id":"gt-l6ro3.1","depends_on_id":"gt-arjlu","type":"blocks","created_at":"2025-12-28T22:31:51.176239-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-l6ro3.2","title":"Deacon health pings clear agent backoff","description":"Deacon's periodic health checks also clear patrol agent backoff.\n\n## Current Flow (mol-deacon-patrol)\n\nDeacon already pings witnesses/refineries for health checks. These pings should:\n1. Verify agent is alive\n2. Clear their backoff as side effect\n\n## Implementation\n\nIn mol-deacon-patrol health-scan step:\n- gt nudge \u003crig\u003e/witness 'HEALTH_CHECK from deacon'\n- gt nudge \u003crig\u003e/refinery 'HEALTH_CHECK from deacon'\n\nReceiving agent:\n- Responds to prove liveness\n- Resets backoff to base interval\n\n## Ping Interval\n\nDeacon patrols every ~1-2 minutes. This ensures:\n- Maximum backoff is bounded by deacon ping interval\n- Even if daemon misses activity, deacon catches up","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T22:31:35.003984-08:00","created_by":"mayor","updated_at":"2025-12-28T22:31:35.003984-08:00","dependencies":[{"issue_id":"gt-l6ro3.2","depends_on_id":"gt-l6ro3","type":"parent-child","created_at":"2025-12-28T22:31:35.004499-08:00","created_by":"daemon"},{"issue_id":"gt-l6ro3.2","depends_on_id":"gt-arjlu","type":"blocks","created_at":"2025-12-28T22:31:51.206694-08:00","created_by":"daemon"},{"issue_id":"gt-l6ro3.2","depends_on_id":"gt-vdprb.1","type":"blocks","created_at":"2025-12-29T17:09:33.31837-08:00","created_by":"mayor"}]}
|
||||
{"id":"gt-l6ro3.3","title":"Molecule await-signal step type","description":"Add await-signal as a molecule step type for patrol agents.\n\n## Step Definition\n\n```toml\n[[steps]]\nid = \"await-signal\"\ntype = \"wait\"\nbackoff = { base = \"30s\", multiplier = 2, max = \"10m\" }\ndescription = \"Wait for signal, then check reality\"\n```\n\n## Behavior\n\n1. Sleep for current backoff interval\n2. Wake immediately on nudge (or timeout expires)\n3. Proceed to next step (check-reality)\n4. If no work found, loop back with increased backoff\n5. If work found, reset backoff to base\n\n## Implementation Options\n\nA. Formula-level: Define in TOML, agent interprets\nB. Code-level: Agent implements wait loop with backoff\n\nOption A is cleaner but needs formula parser support.\nOption B works now but less declarative.\n\n## Used By\n\n- mol-witness-patrol (first step)\n- mol-refinery-patrol (first step)","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-28T23:06:11.638803-08:00","created_by":"mayor","updated_at":"2025-12-29T17:08:22.492383-08:00","dependencies":[{"issue_id":"gt-l6ro3.3","depends_on_id":"gt-l6ro3","type":"parent-child","created_at":"2025-12-28T23:06:11.63931-08:00","created_by":"daemon"},{"issue_id":"gt-l6ro3.3","depends_on_id":"gt-vdprb","type":"parent-child","created_at":"2025-12-29T17:08:22.500906-08:00","created_by":"mayor"}]}
|
||||
{"id":"gt-l6ro3.4","title":"Deacon stuck-session detection and force-kill protocol","description":"Deacon detects and kills genuinely stuck/hung Claude Code sessions.\n\n## The Problem\n\nClaude Code sessions can get stuck:\n- Infinite loop / hung tool call\n- Crashed but tmux session still exists\n- Unresponsive to nudges\n\n`gt rig boot` is idempotent (won't kill) - it only starts if not running.\nSomeone needs to detect stuck sessions and force-kill them.\n\n## Detection Protocol\n\nDuring Deacon health rounds:\n\n1. **Ping test**: `gt nudge \u003cagent\u003e 'HEALTH_CHECK'`\n2. **Wait for response**: Agent should update agent bead `last_activity`\n3. **Timeout**: If no activity update within N seconds, mark suspicious\n4. **Consecutive failures**: After M consecutive failures, declare stuck\n\n## Force-Kill Protocol\n\nWhen stuck detected:\n\n```bash\n# 1. Log the intervention\ngt mail send \u003cagent\u003e -s 'FORCE_KILL: unresponsive' -m 'Deacon detected...'\n\n# 2. Kill the tmux session\ntmux kill-session -t \u003csession-name\u003e\n\n# 3. Update agent bead state\nbd update \u003cagent-bead\u003e --status=killed --reason='Deacon force-kill: unresponsive'\n\n# 4. Notify mayor (optional, for visibility)\ngt mail send mayor/ -s 'Agent killed: \u003cagent\u003e' -m 'Reason: unresponsive...'\n```\n\n## Recovery\n\nAfter force-kill, the agent is 'asleep'. Normal wake mechanisms apply:\n- `gt rig boot` restarts it\n- Or stays asleep until next activity trigger\n\n## Parameters (configurable)\n\n- ping_timeout: 30s (how long to wait for response)\n- consecutive_failures: 3 (how many before force-kill)\n- cooldown: 5m (minimum time between force-kills of same agent)\n\n## NOT Deacon's Job\n\n- Graceful shutdown (agent does this itself)\n- Context-based recycling (agent self-handoffs)\n- Normal backoff/sleep transitions\n\nDeacon only force-kills when agent is genuinely unresponsive.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-28T23:09:21.694807-08:00","created_by":"mayor","updated_at":"2025-12-28T23:09:21.694807-08:00","dependencies":[{"issue_id":"gt-l6ro3.4","depends_on_id":"gt-l6ro3","type":"parent-child","created_at":"2025-12-28T23:09:21.695345-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-l8fp7","title":"Digest: mol-deacon-patrol","description":"Patrol 1: inbox clear, gates clear, no pending spawns, witnesses/refineries healthy, no orphans","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-28T15:49:38.09038-08:00","updated_at":"2025-12-28T15:49:38.09038-08:00","closed_at":"2025-12-28T15:49:38.090344-08:00"}
|
||||
{"id":"gt-l90dq","title":"gt crew at fails to detect existing crew session","description":"## Summary\n`gt crew at` started a new Claude session instead of attaching to an existing one for the same crew worker.\n\n## Reproduction\n1. Have a crew worker (joe) running in gastown/crew/joe (PID 27526 on tty s030)\n2. Run `gt crew at` from the same directory (gastown/crew/joe)\n3. Expected: Attach to existing session on s030\n4. Actual: Started a brand new Claude session (PID 67618 on s026)\n\n## Evidence\n```\n# Old joe still running:\nPID 27526 on s030: /Users/stevey/gt/gastown/crew/joe (started 10:22AM)\n\n# New joe spawned by 'gt crew at':\nPID 67618 on s026: /Users/stevey/gt/gastown/crew/joe (started 10:39AM)\n```\n\n## Impact\n- Duplicate crew workers cause confusion\n- User expected to attach to existing session, not spawn a second one\n- The original session was still functional (just stuck in feed display)\n\n## Likely cause\n`gt crew at` probably doesn't check for running Claude processes in the crew directory before spawning a new one. It should:\n1. Check for existing tmux sessions for this crew worker\n2. Check for running `claude` processes with cwd matching the crew directory\n3. If found, attach to existing session instead of spawning new one","status":"open","priority":2,"issue_type":"bug","created_at":"2025-12-28T10:52:28.917151-08:00","created_by":"gastown/crew/joe","updated_at":"2025-12-28T10:52:42.111835-08:00"}
|
||||
@@ -569,7 +569,7 @@
|
||||
{"id":"gt-s0nba","title":"Digest: mol-deacon-patrol","description":"Patrol cycle 6: All healthy","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-28T11:21:26.271445-08:00","updated_at":"2025-12-28T11:21:26.271445-08:00","closed_at":"2025-12-28T11:21:26.271411-08:00"}
|
||||
{"id":"gt-s148","title":"Clean up stale children on deacon handoff bead","description":"The deacon handoff bead hq-8r8 has 7 stale children (hq-8r8.1 through hq-8r8.7) from a previous patrol that got incorrectly parented. These should be cleaned up.\n\nThe handoff bead should only contain the attached_molecule reference, not instantiated steps.","status":"open","priority":3,"issue_type":"task","created_at":"2025-12-23T13:16:52.273025-08:00","updated_at":"2025-12-23T13:16:52.273025-08:00"}
|
||||
{"id":"gt-s18k","title":"Witness patrol: stale MR queue detection needs state tracking","description":"The mol-witness-patrol check-refinery step says 'if queue is non-empty for \u003e30 min, send nudge' but doesn't explain how to track when the queue first became non-empty.\n\n## Problem\nThe Witness needs to persist:\n- When MR queue first became non-empty\n- Previous queue state for comparison\n\nWithout this, the Witness can't detect stale queues.\n\n## Solution\nAdd to witness handoff bead:\n- mr_queue_nonempty_since: timestamp\n- Update in save-state step\n- Check in check-refinery step","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-23T01:02:38.497753-08:00","updated_at":"2025-12-23T01:02:38.497753-08:00","dependencies":[{"issue_id":"gt-s18k","depends_on_id":"gt-bjft","type":"blocks","created_at":"2025-12-23T01:03:12.026206-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-s57tk","title":"Phase 2: Observable Infrastructure","description":"Glass cockpit - see what's happening across the system.\n\nPhase 1 got the engine running. Phase 2 makes it observable.\n\n**Pillars:**\n- Pillar 4: Swarm-in-Beads (gt-kc7yj - already exists)\n- Pillar 5: MQ Observability\n- Pillar 6: Witness Observability \n- Pillar 7: Unified Dashboard\n\n**Success criteria:**\n1. gt status shows per-rig queue depth and agent health\n2. gt feed shows MQ and swarm lifecycle events\n3. gt dashboard provides live system visibility\n4. No .runtime/*.json files for observable state\n5. Swarms fully tracked in beads\n\nReference: ~/gt/docs/liftoff-plan.md","status":"open","priority":1,"issue_type":"epic","created_at":"2025-12-28T21:40:01.375659-08:00","created_by":"gastown/crew/jack","updated_at":"2025-12-28T21:40:01.375659-08:00","dependencies":[{"issue_id":"gt-s57tk","depends_on_id":"gt-lfi2d","type":"blocks","created_at":"2025-12-28T21:41:21.132603-08:00","created_by":"daemon"},{"issue_id":"gt-s57tk","depends_on_id":"gt-qd7ri","type":"blocks","created_at":"2025-12-28T21:41:21.163101-08:00","created_by":"daemon"},{"issue_id":"gt-s57tk","depends_on_id":"gt-kc7yj","type":"blocks","created_at":"2025-12-28T21:41:21.193543-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-s57tk","title":"Glass Cockpit: See WTF is happening","description":"Glass cockpit - see what's happening across the system.\n\nPhase 1 got the engine running. Phase 2 makes it observable.\n\n**Pillars:**\n- Pillar 4: Swarm-in-Beads (gt-kc7yj - already exists)\n- Pillar 5: MQ Observability\n- Pillar 6: Witness Observability \n- Pillar 7: Unified Dashboard\n\n**Success criteria:**\n1. gt status shows per-rig queue depth and agent health\n2. gt feed shows MQ and swarm lifecycle events\n3. gt dashboard provides live system visibility\n4. No .runtime/*.json files for observable state\n5. Swarms fully tracked in beads\n\nReference: ~/gt/docs/liftoff-plan.md","status":"open","priority":1,"issue_type":"epic","created_at":"2025-12-28T21:40:01.375659-08:00","created_by":"gastown/crew/jack","updated_at":"2025-12-29T17:02:48.010526-08:00","dependencies":[{"issue_id":"gt-s57tk","depends_on_id":"gt-lfi2d","type":"blocks","created_at":"2025-12-28T21:41:21.132603-08:00","created_by":"daemon"},{"issue_id":"gt-s57tk","depends_on_id":"gt-qd7ri","type":"blocks","created_at":"2025-12-28T21:41:21.163101-08:00","created_by":"daemon"},{"issue_id":"gt-s57tk","depends_on_id":"gt-kc7yj","type":"blocks","created_at":"2025-12-28T21:41:21.193543-08:00","created_by":"daemon"}]}
|
||||
{"id":"gt-s6dw","title":"Batch wisp squashing in Deacon maintenance","description":"Add wisp squashing to Deacon's maintenance duties:\n- Patrol plugin to find orphaned/completed wisps across all rigs\n- Squash completed patrol wisps to digests\n- Burn abandoned wisps that have no audit value\n- Part of the hygiene/cleanup system\n\nAlso: Witness polecat shutdown should spawn its own short wisp for the cleanup protocol.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-22T21:52:49.403649-08:00","updated_at":"2025-12-22T21:52:49.403649-08:00"}
|
||||
{"id":"gt-s6r44","title":"gt status: Show agent hook_bead (current work) in status output","description":"attached_args: Implement the hook_bead display in gt status. The agent bead lifecycle is complete - just need to read hook_bead and display it.\n\n## Current State\n\ngt status shows agents with their agent_state from beads:\n```\n crew/max ✓ running [running]\n```\n\n## Enhancement\n\nShow what each agent is working on (hook_bead field from agent beads):\n```\n crew/max ✓ running [running] → gt-abc (Fix auth bug)\n crew/joe ✓ running [running] → gt-xyz (Add tests)\n refinery ✓ running → refinery Handoff\n```\n\nThis gives the overseer a quick view of:\n1. Who is running\n2. What each agent is working on\n3. Progress at a glance\n\n## Implementation\n\nIn status.go, when displaying agents:\n1. Look up agent bead by ID (e.g., gt-crew-gastown-max)\n2. Parse hook_bead from description\n3. If hook_bead set, fetch its title for display\n4. Show as: agent_state → hook_bead (title truncated)\n\n## Related\n\nThe agent bead lifecycle is now complete:\n- prime.go creates agent beads\n- sling.go sets hook_bead\n- done.go clears hook_bead and sets final state","status":"closed","priority":2,"issue_type":"feature","created_at":"2025-12-28T10:13:46.434234-08:00","created_by":"gastown/crew/max","updated_at":"2025-12-28T10:17:37.231773-08:00","closed_at":"2025-12-28T10:17:37.231773-08:00"}
|
||||
{"id":"gt-s7j9c","title":"Digest: mol-deacon-patrol","description":"Patrol 13: all clear","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-28T08:18:22.67202-08:00","updated_at":"2025-12-28T08:18:22.67202-08:00","closed_at":"2025-12-28T08:18:22.671981-08:00"}
|
||||
@@ -632,6 +632,12 @@
|
||||
{"id":"gt-v3bjf","title":"Digest: mol-deacon-patrol","description":"Patrol 14: Quiet","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-25T07:28:25.96187-08:00","updated_at":"2025-12-25T07:28:25.96187-08:00","closed_at":"2025-12-25T07:28:25.961842-08:00"}
|
||||
{"id":"gt-v650","title":"Add handoff self-initiation protocol to role templates","description":"Agents need clear protocol for self-initiated handoff:\n\n1. Recognize: 'I should cycle now'\n2. Prepare: Summarize current state, what's next\n3. Send: gt mail send \u003cself\u003e -s '🤝 HANDOFF: ...' -m '...'\n4. Exit: End session cleanly\n\nThis replaces external 'you should cycle now' nudging.\nThe agent owns its lifecycle.\n\nInclude examples for each role type.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-23T01:46:30.987381-08:00","updated_at":"2025-12-23T14:27:07.35534-08:00"}
|
||||
{"id":"gt-v8ycl","title":"Digest: mol-deacon-patrol","description":"Patrol 8: All healthy.","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-28T03:06:20.557185-08:00","updated_at":"2025-12-28T03:06:20.557185-08:00","closed_at":"2025-12-28T03:06:20.557145-08:00"}
|
||||
{"id":"gt-vdprb","title":"Feed-Based Wake Model for Patrol Agents","description":"## The Paradigm Shift\n\n\u003e **Backoff is not about polling less. It is about waiting for signals with a timeout.**\n\nThis epic captures the shift from time-driven to event-driven patrol wake.\n\n## Key Insight (Recovered from 2025-12-29 session crash)\n\nThe Beads activity feed (bd activity --follow) is the universal data plane for\nwake signals. Every meaningful action creates a beads mutation; agents subscribe to\nthe feed and wake within ~500ms. The timeout is just a safety net.\n\n**OLD**: Time-driven. Wake because time passed. Poll less when idle.\n**NEW**: Event-driven. Wake because signal arrived. Timeout is safety net.\n\n## Architecture\n\nANY MUTATION:\n bd create/update/close -\u003e issues.jsonl mutation\n -\u003e bd activity --follow sees it (~500ms)\n -\u003e All subscribed agents wake immediately\n\nPATROL AGENT:\n Runs bd activity --follow as background source\n Any output line = wake signal\n Timeout expiry = safety net (not primary wake)\n\n## Wake Sources (Priority Order)\n\n| Source | Latency | Purpose |\n|--------|---------|---------|\n| Feed | ~500ms | Primary - any beads mutation |\n| Nudge | Instant | Explicit wake (startup hooks) |\n| Timeout | Backoff | Safety net for missed signals |\n| Daemon | 5-60min | GUPP backstop, session recovery |\n\n## Key Design Decisions\n\n1. No wake_on conditions - signals carry no semantic meaning. Just wake up.\n Agent discovers reality by checking mail, beads, hook, git state.\n\n2. Read-only commands do not wake - gt status, bd show create no mutations.\n\n3. Daemon is recovery-focused - catches edge cases (GUPP violations, dead sessions).\n\n4. Keepalive file deprecated - the feed replaces the keepalive mechanism.\n\n## Reference\n\n- ~/gt/docs/patrol-system-design.md (Sleeping Agents section)\n- ~/gt/docs/PRIMING.md (Feed Is the Signal insight)\n\n## Related\n\n- gt-l6ro3: Patrol Exponential Backoff System (backoff timing, complements this)","status":"open","priority":1,"issue_type":"epic","created_at":"2025-12-29T17:02:14.195425-08:00","created_by":"mayor","updated_at":"2025-12-29T17:02:31.416494-08:00"}
|
||||
{"id":"gt-vdprb.1","title":"Patrol agents subscribe to bd activity --follow","description":"Each patrol agent (Deacon, Witness, Refinery) should run bd activity --follow as a background process. Any output line is a wake signal. This is the primary wake mechanism.\n\nImplementation:\n1. Add feed subscription to await-signal step logic\n2. Agent starts bd activity --follow on entering await-signal\n3. Any line of output breaks the wait immediately\n4. Timeout still applies as safety net\n\nSee patrol-system-design.md for full specification.","status":"open","priority":1,"issue_type":"task","created_at":"2025-12-29T17:02:47.872208-08:00","created_by":"mayor","updated_at":"2025-12-29T17:09:57.295218-08:00","dependencies":[{"issue_id":"gt-vdprb.1","depends_on_id":"gt-vdprb","type":"parent-child","created_at":"2025-12-29T17:02:47.872866-08:00","created_by":"mayor"},{"issue_id":"gt-vdprb.1","depends_on_id":"gt-l6ro3.3","type":"blocks","created_at":"2025-12-29T17:08:56.137406-08:00","created_by":"mayor"}]}
|
||||
{"id":"gt-vdprb.2","title":"Remove keepalive file infrastructure","description":"The keepalive mechanism (~/gt/daemon/activity.json) is deprecated in favor of feed-based wake.\n\nTODO:\n1. Remove keepalive.TouchTownActivity() calls from gt commands\n2. Remove keepalive.ReadTownActivity() from daemon\n3. Delete internal/keepalive package\n4. Update daemon to use longer base heartbeat (recovery-focused)\n\nWhitelist consideration: Some read-only commands might need to wake (TBD - none identified yet)","status":"open","priority":3,"issue_type":"task","created_at":"2025-12-29T17:03:10.887382-08:00","created_by":"mayor","updated_at":"2025-12-29T17:03:10.887382-08:00","dependencies":[{"issue_id":"gt-vdprb.2","depends_on_id":"gt-vdprb","type":"parent-child","created_at":"2025-12-29T17:03:10.888084-08:00","created_by":"mayor"},{"issue_id":"gt-vdprb.2","depends_on_id":"gt-vdprb.4","type":"blocks","created_at":"2025-12-29T17:09:11.896659-08:00","created_by":"mayor"}]}
|
||||
{"id":"gt-vdprb.3","title":"Startup hooks nudge Deacon","description":"When a new Claude session starts (via startup hook), it should nudge Deacon so Deacon knows a new agent has appeared. This is one of Deacons extra wake sources for GUPP backstop.\n\nImplementation: Add gt nudge deacon session-started to the startup hook chain.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-29T17:03:17.160315-08:00","created_by":"mayor","updated_at":"2025-12-29T17:10:07.577468-08:00","dependencies":[{"issue_id":"gt-vdprb.3","depends_on_id":"gt-vdprb","type":"parent-child","created_at":"2025-12-29T17:03:17.160964-08:00","created_by":"mayor"},{"issue_id":"gt-vdprb.3","depends_on_id":"gt-vdprb.1","type":"blocks","created_at":"2025-12-29T17:09:40.073828-08:00","created_by":"mayor"}]}
|
||||
{"id":"gt-vdprb.4","title":"Daemon heartbeat becomes recovery-focused","description":"Update daemon heartbeat to be recovery-focused, not wake-focused.\n\nCurrent: Daemon pokes agents every 5-60min as primary wake.\nNew: Daemon only checks for:\n- Dead sessions that need restart\n- Agents with work-on-hook not progressing (GUPP violation)\n- Orphaned work\n\nFeed handles normal wake; daemon is the safety net for edge cases.","status":"open","priority":2,"issue_type":"task","created_at":"2025-12-29T17:03:23.47806-08:00","created_by":"mayor","updated_at":"2025-12-29T17:10:02.442966-08:00","dependencies":[{"issue_id":"gt-vdprb.4","depends_on_id":"gt-vdprb","type":"parent-child","created_at":"2025-12-29T17:03:23.478825-08:00","created_by":"mayor"},{"issue_id":"gt-vdprb.4","depends_on_id":"gt-vdprb.1","type":"blocks","created_at":"2025-12-29T17:09:05.198482-08:00","created_by":"mayor"}]}
|
||||
{"id":"gt-vdprb.5","title":"Documentation: Feed-based wake model","description":"Document the feed-based wake model in patrol-system-design.md and PRIMING.md.\n\nDONE (2025-12-29):\n- Updated patrol-system-design.md with full feed-based wake specification\n- Added Feed Is the Signal and Discover Dont Be Told insights to PRIMING.md\n- Committed as 39e46148","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-29T17:03:56.043996-08:00","created_by":"mayor","updated_at":"2025-12-29T17:04:01.193795-08:00","closed_at":"2025-12-29T17:04:01.193795-08:00","close_reason":"Completed 2025-12-29, commit 39e46148","dependencies":[{"issue_id":"gt-vdprb.5","depends_on_id":"gt-vdprb","type":"parent-child","created_at":"2025-12-29T17:03:56.044684-08:00","created_by":"mayor"}]}
|
||||
{"id":"gt-vg4n","title":"Use Beads issue status as spawn source of truth","description":"Currently witness tracks spawned issues in .gastown/witness.json to prevent re-spawning:\n\n{\"spawned_issues\": [\"gt-abc1\", \"gt-def2\", ...]}\n\nThis is redundant with Beads issue status (in_progress). The witness could query:\n bd list --status=in_progress\n\nThe local list serves as a performance cache to avoid querying beads every cycle. Consider:\n1. Use Beads as source of truth\n2. Keep local cache with TTL\n3. Sync cache on witness start\n\nThis simplifies state management and ensures consistency.","status":"open","priority":4,"issue_type":"task","created_at":"2025-12-21T22:07:31.756863-08:00","updated_at":"2025-12-21T22:07:31.756863-08:00"}
|
||||
{"id":"gt-vjcbo","title":"Digest: mol-deacon-patrol","description":"Patrol 20: final cycle","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-28T06:13:45.223964-08:00","updated_at":"2025-12-28T06:13:45.223964-08:00","closed_at":"2025-12-28T06:13:45.223931-08:00"}
|
||||
{"id":"gt-vkmpf","title":"Digest: mol-deacon-patrol","description":"Patrol 12: routine","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-26T18:43:21.209794-08:00","updated_at":"2025-12-26T18:43:21.209794-08:00","closed_at":"2025-12-26T18:43:21.209749-08:00"}
|
||||
@@ -671,6 +677,7 @@
|
||||
{"id":"gt-xveby","title":"Digest: mol-deacon-patrol","description":"Cycle 9: quiet","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-28T13:17:31.34652-08:00","updated_at":"2025-12-28T13:17:31.34652-08:00","closed_at":"2025-12-28T13:17:31.346483-08:00"}
|
||||
{"id":"gt-xvner","title":"Digest: mol-deacon-patrol","description":"Patrol 7: All clear","status":"closed","priority":2,"issue_type":"task","created_at":"2025-12-25T00:01:49.871554-08:00","updated_at":"2025-12-25T00:01:49.871554-08:00","closed_at":"2025-12-25T00:01:49.871519-08:00"}
|
||||
{"id":"gt-xw7b","title":"Add --fart as easter egg alias for bd mol bond","description":"Add a hidden alias for the bond command:\n\n```bash\nbd mol fart mol-polecat-work --wisp\n# equivalent to:\nbd mol bond mol-polecat-work --wisp\n```\n\n## Context\nThe fart joke: instantiating a proto can produce either:\n- A Mol (solid/substantial output)\n- A Wisp (gas/ephemeral output)\n\n## Implementation\n- Add 'fart' as an alias in the mol subcommand\n- No documentation needed (easter egg)\n- Maybe a fun message: 'Bonding molecule...' or similar\n\nLow priority, just for fun.","status":"closed","priority":4,"issue_type":"task","created_at":"2025-12-21T16:33:18.822868-08:00","updated_at":"2025-12-28T22:33:35.382773-08:00","closed_at":"2025-12-28T22:33:35.382773-08:00"}
|
||||
{"id":"gt-xwige","title":"Remove keepalive file infrastructure","description":"The keepalive mechanism (~/gt/daemon/activity.json) is deprecated in favor of feed-based wake.\n\n**Current state:**\n- keepalive.TouchTownActivity() writes to activity.json on every gt/bd command\n- Daemon reads activity.json to calculate exponential backoff\n\n**New model (feed-based wake):**\n- Patrol agents subscribe to `bd activity --follow`\n- Any beads mutation wakes agents within ~500ms\n- Daemon heartbeat is recovery-focused, not wake-focused\n- Read-only commands don't need to wake the town\n\n**TODO:**\n1. Remove keepalive.TouchTownActivity() calls from gt commands\n2. Remove keepalive.ReadTownActivity() from daemon\n3. Delete internal/keepalive package\n4. Update daemon to use longer base heartbeat (recovery-focused)\n\n**Whitelist consideration:**\nSome read-only commands might need to wake (TBD):\n- gt mail inbox (checking for work?)\n- None identified yet\n\nSee docs/patrol-system-design.md for full feed-based wake design.","status":"open","priority":3,"issue_type":"task","created_at":"2025-12-29T16:35:53.250019-08:00","created_by":"mayor","updated_at":"2025-12-29T16:35:53.250019-08:00"}
|
||||
{"id":"gt-y14l7","title":"Activity stream infrastructure check","description":"Verify activity stream infrastructure exists and is sufficient for MQ/witness events.\n\nCheck:\n- Does gt feed already have event infrastructure?\n- Can we emit custom events from Go code?\n- What format do events need?\n\nIf infrastructure exists, close this. If not, implement minimal event emission.","status":"hooked","priority":2,"issue_type":"task","created_at":"2025-12-28T21:40:18.862686-08:00","created_by":"gastown/crew/jack","updated_at":"2025-12-28T22:26:11.560503-08:00"}
|
||||
{"id":"gt-y3jb9","title":"Protocol: Type System for Formulas","description":"Protocols define interfaces that formulas implement - a type system for workflows.\n\n## Concept\n\n```toml\n# reviewable.protocol\n[protocol]\nname = \"Reviewable\"\n\n[requires]\nsteps = [\"review\"] # Must have a step tagged \"review\"\noutputs = [\"review_decision\"] # Must produce this\n\n[guarantees]\n\"review completes before any deploy step\"\n```\n\nFormulas declare: `implements = [\"Reviewable\", \"Deployable\"]`\n\nSystem verifies compliance statically.\n\n## Use Cases\n\n1. Ensure all deploy formulas have review steps\n2. Define compliance requirements as protocols\n3. Enable formula discovery: \"Give me all Deployable formulas\"\n4. Validate formula composition compatibility\n\n## Properties\n\n- Static verification (before execution)\n- Composable (protocol can extend protocol)\n- Documentation value (self-describing contracts)\n\n## Open Questions\n\n1. Protocol syntax - embedded in formula or separate files?\n2. Verification timing - cook time? load time?\n3. Protocol versioning - how do protocols evolve?\n4. Inheritance - can protocols extend other protocols?\n\n## Related\n\n- docs/formula_evolution.md - \"Formula Schemas\" section\n- gt-8tmz - molecule algebra\n","status":"closed","priority":4,"issue_type":"epic","created_at":"2025-12-26T01:00:53.856997-08:00","updated_at":"2025-12-28T22:33:22.289063-08:00","closed_at":"2025-12-28T22:33:22.289063-08:00"}
|
||||
{"id":"gt-y41ep","title":"Polecat spawn: Environment vars not exported to shell","description":"Polecat sessions set tmux environment but don't export to shell before Claude\n\nIn session/manager.go Start():\n _ = m.tmux.SetEnvironment(sessionID, \"GT_RIG\", m.rig.Name)\n _ = m.tmux.SetEnvironment(sessionID, \"GT_POLECAT\", polecat)\n ...\n command = \"claude --dangerously-skip-permissions\"\n\nCompare to crew_lifecycle.go which exports inline:\n claudeCmd := fmt.Sprintf(\"export GT_ROLE=crew GT_RIG=%s GT_CREW=%s \u0026\u0026 claude ...\")\n\nResult: Claude can't detect polecat identity, falls back to 'mayor', shows wrong hook.\n\nFix: Export GT_ROLE=polecat GT_RIG=X GT_POLECAT=Y inline before running Claude.","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-12-28T14:16:18.410705-08:00","created_by":"mayor","updated_at":"2025-12-28T15:34:03.01152-08:00","closed_at":"2025-12-28T15:34:03.01152-08:00"}
|
||||
|
||||
Reference in New Issue
Block a user