The previous fix only added the "dog" case to AgentEnv but dogs still couldn't
find their mail because:
1. BuildAgentStartupCommand doesn't pass AgentName, so BD_ACTOR was empty
2. detectSenderFromRole had no "dog" case, falling back to "overseer"
Fixes:
- Add BuildDogStartupCommand that properly passes dog name to AgentEnv
- Update dog dispatch to use BuildDogStartupCommand
- Add "dog" case to detectSenderFromRole that reads BD_ACTOR
The env vars are now exported in the startup command (via exec env) so the
agent inherits them when it starts, rather than relying on tmux setenv which
only affects new shells.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Dogs are just directories with state files - they don't have sessions
to receive and execute mail. This means `gt dog dispatch --plugin X`
would assign work and send mail, but nothing would ever execute.
This fix spawns a tmux session for the dog after dispatch, with an
initial prompt that tells Claude to check mail and execute the plugin
instructions. This makes dog dispatch actually work as intended.
The session is named `gt-<town>-deacon-<dogname>` following the pattern
from showDogStatus. If session creation fails, we log a warning but
don't fail the dispatch (mail was sent, work was assigned, human can
manually start the session).
Related: mayor guidance to have deacon execute dog work directly.
This is a stepping stone - dogs now execute their own work via sessions.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Polish help text across all agent commands to clarify roles:
- crew: persistent workspaces vs ephemeral polecats
- deacon: town-level watchdog receiving heartbeats
- dog: cross-rig infrastructure workers (cats vs dogs)
- mayor: Chief of Staff for cross-rig coordination
- nudge: universal synchronous messaging API
- polecat: ephemeral one-task workers, self-cleaning
- refinery: merge queue serializer per rig
- witness: per-rig polecat health monitor
Add comprehensive gt nudge documentation to crew template explaining
when to use nudge vs mail, common patterns, and target shortcuts.
Add orphan-process-cleanup step to deacon patrol formula to clean up
claude subagent processes that fail to exit (TTY = "?").
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Fixes from code review:
- Remove duplicate generateDogNameForDispatch, reuse generateDogName
- Fix race condition: assign work BEFORE sending mail
- Add rollback if mail send fails (clear work assignment)
- Fix misleading help text (was "hooks mail", actually sends mail)
- Add --json flag for scripted output
- Add --dry-run flag to preview without executing
The order change (assign work first, then send mail) ensures that if
AssignWork fails, no mail has been sent. If mail fails after work is
assigned, we rollback by clearing the work assignment.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Implements gt-n08ix.2: formalized plugin dispatch to dogs.
The new `gt dog dispatch --plugin <name>` command:
- Finds plugin definition using the existing plugin scanner
- Creates a mail work unit with plugin instructions
- Assigns work to an idle dog (or creates one with --create)
- Returns immediately (non-blocking)
Usage:
gt dog dispatch --plugin rebuild-gt
gt dog dispatch --plugin rebuild-gt --rig gastown
gt dog dispatch --plugin rebuild-gt --dog alpha
gt dog dispatch --plugin rebuild-gt --create
This enables the Deacon to dispatch plugins to dogs during patrol
cycles without blocking on execution.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Session names `gt-mayor` and `gt-deacon` were hardcoded, causing tmux
session name collisions when running multiple towns simultaneously.
Changed to `gt-{town}-mayor` and `gt-{town}-deacon` format (e.g.,
`gt-ai-mayor`) to allow concurrent multi-town operation.
Key changes:
- session.MayorSessionName() and DeaconSessionName() now take townName param
- Added workspace.GetTownName() helper to load town name from config
- Updated all callers in cmd/, daemon/, doctor/, mail/, rig/, templates/
- Updated tests with new session name format
- Bead IDs remain unchanged (already scoped by .beads/ directory)
Fixes#60🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
When adding a dog, creates an agent bead with role_type:dog label.
When removing a dog, deletes the corresponding agent bead.
This enables @dogs group resolution in the mail router by allowing
queries like `bd list --type=agent --label=role_type:dog`.
Changes:
- Add DogBeadID(), DogRoleBeadID() helper functions
- Add CreateDogAgentBead() for creating dog agent beads with labels
- Add FindDogAgentBead() and DeleteDogAgentBead() for cleanup
- Add Labels field to Issue struct for label parsing
- Update ParseAgentBeadID() to handle dog bead IDs (gt-dog-<name>)
- Update IsAgentSessionBead() to include "dog" as valid role
(gt-qha0g)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Implements dog management commands:
- gt dog add <name>: Create dog in kennel with multi-rig worktrees
- gt dog remove <name>: Retire dog, cleanup worktrees
- gt dog list: Show the pack with status
- gt dog call [name]: Wake idle dog(s)
- gt dog status [name]: Show detailed dog state
Dogs are reusable workers managed by the Deacon for infrastructure tasks.
Each dog gets worktrees into all configured rigs (gastown, beads, etc.).
Includes internal/dog package with Manager and state handling (from gt-0x5og.2).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
