Deacon patrol: Janitorial cleanup patterns

Patterns discovered during town cleanup that could be automated in Deacon's patrol step:

## Stale Issue Detection

1. **Stale in_progress issues** - Issues marked in_progress for >N days without activity
   - Example: 9 issues in_progress, some likely complete
   - Action: Report list, optionally nudge assignee

2. **Duplicate issues** - Same title with different IDs
   - Example: gt-87jz and gt-qp2w both 'mol-witness-patrol'
   - Action: Flag for human review

3. **Orphaned issues** - Referenced in commits but still open
   - bd doctor already detects: 'hq-65jk (commit f9e9034d)'
   - Action: Report, suggest closing

4. **Stale test messages** - Messages with 'test' in title older than N days
   - Example: gt-54kn, gt-1ero, gt-nriy, gt-wrw2, gt-pnu4, gt-g1ud, gt-b5sh
   - Action: Auto-close or flag

## File System Cleanup

5. **Log file accumulation** - daemon.log and rotated .log.gz files
   - Found 8+ log files across rigs
   - Action: Rotate, compress, delete old (>7 days)

6. **Beads directory size** - Town .beads/ is 65MB
   - Action: Monitor growth, alert on threshold

## Database Health

7. **Legacy database fingerprints** - Older DBs without fingerprint
   - bd doctor warns about this
   - Action: Report, suggest migration

## Cross-Reference Integrity

8. **Gastown↔Beads issue sync** - Issues filed in wrong project
   - Example: gt-8tmz.* describes Beads work but no bd-* issues
   - Action: Detect cross-references, verify both sides exist

## Implementation Notes

These could be added to mol-deacon-patrol.formula.yaml as cleanup substeps:
- Daily: Log rotation, stale issue report
- Weekly: Duplicate detection, orphan check
- Monthly: Size monitoring, archive old closed issues


BUG: gt sling updates bead status but doesn't create .hook file

gt sling updates the bead to status=hooked but doesn't actually create the .hook file in the polecat directory.

## Symptom
- gt sling reports success
- Bead shows status=hooked, assignee set
- Polecat's .hook file doesn't exist
- gt hook shows empty

## Root Cause
gt sling updates bead state via bd commands but never writes to polecats/<name>/.hook

## Fix
After updating bead status, write the bead ID to the .hook file:
```go
hookPath := filepath.Join(polecatDir, ".hook")
os.WriteFile(hookPath, []byte(beadID), 0644)
```

## Related
This is blocking gt-zqt4d dispatch to splendid.

Fixed identity format mismatch in buildAgentIdentity - now uses 3-part format (rig/polecats/name) matching session.AgentIdentity.Address()


Merge: slit-mjtj9dc8

branch: polecat/slit-mjtj9dc8
target: main
source_issue: slit-mjtj9dc8
rig: gastown


Missing failsafe: No circuit breaker for stuck agents

When an agent (Deacon, Witness, Refinery) gets stuck, there's no automatic recovery:

1. No timeout on individual steps - an agent can spin forever
2. No watchdog process checking agent health externally
3. No heartbeat/liveness check that triggers restart

Proposed solution:
- Add a watchdog that checks agent last_activity timestamps
- If no activity for >5 minutes, force cycle the agent
- This could be a simple cron job or daemon feature

This is defense-in-depth for the 'who watches the watchers' problem.

(Moved from hq-2wy2i)


Digest: mol-deacon-patrol

Patrol cycle 55: All healthy


Digest: mol-deacon-patrol

Cycle 13: quiet


gt convoy create: Fix notify slot warning

When creating convoy with --notify, get warning:
```
⚠ Warning: couldn't set notify slot: exit status 1
```

But notification target still shows in status. Investigate slot setter.

Fixed: removed invalid slot set for convoy notify


Digest: mol-deacon-patrol

Patrol 7: All healthy


Digest: mol-deacon-patrol

Patrol 15: quiet


Digest: mol-deacon-patrol

Patrol 79: Routine


Digest: mol-deacon-patrol

Patrol 16: quick pass


Witness: Don't nuke polecats with open MRs or hooked work

Witness mass-murdered 11 polecats during cleanup:

Evidence from witness session:
```
gt polecat nuke gastown/slit gastown/capable
Worktrees nuked: 11 (cheedo, dag, dementus, furiosa×2, keeper, nux, rictus, slit, capable, toast)
```

Casualties:
- cheedo had open MR gt-t7g4b (branch not pushed, work lost)
- cheedo had hooked work gt-w0fqg (had to reassign)
- Unknown other work may have been lost

Pre-nuke checklist must verify:
1. No uncommitted/unpushed work
2. No open MRs awaiting merge
3. No work on hook (unless orphan recovery)
4. Issue is actually closed (not just 'done' signaled)

The witness is supposed to be a pit boss, not an executioner.

## Update: Instructions exist but were ignored

Witness CLAUDE.md HAS the pre-kill checklist:
```
Before killing ANY polecat session, verify:
[ ] 3. Check for unpushed commits
[ ] 4. Verify issue closed
[ ] 5. Verify PR submitted
```

Code for verification also exists on main (c28a0d5).

But witness still mass-murdered. Possible causes:
1. Context pressure (witness was at 4% - may have lost instructions)
2. Some aggressive prompt overriding safety checks
3. Agent non-compliance

Need: Enforcement mechanism, not just instructions.

Consolidated into gt-xqh3y - safety checks are part of the nuke-after-completion implementation


Merge: ace-1767106056721

branch: polecat/ace-1767106056721
target: main
source_issue: ace-1767106056721
rig: gastown


gt doctor: Check settings.json hook consistency across town

## Problem

Settings.json files in different locations can become out of sync, causing session_id
passthrough to fail for some roles but not others. This happened when:
- Town root was updated to use session-start.sh
- Rig root still had old 'gt prime' direct call
- Mayor/rig had mixed state

## Locations to Check

1. `~/gt/.claude/settings.json` (town root - Mayor uses this)
2. `~/gt/<rig>/.claude/settings.json` (rig root - polecats/crew use this)
3. `~/gt/<rig>/mayor/rig/.claude/settings.json` (mayor/rig - source of truth)

## Check Logic

For SessionStart and PreCompact hooks, verify all use `session-start.sh`:
- Must contain `bash ~/.claude/hooks/session-start.sh` (or full path)
- Warn if any use bare `gt prime` without session-start.sh wrapper

## Output

```
gt doctor
...
session-hooks: ✓ All settings.json files use session-start.sh
# or
session-hooks: ✗ ~/gt/gastown/.claude/settings.json uses bare 'gt prime' (missing session_id passthrough)
```

## Fix Suggestion

When inconsistency found, suggest:
```
Hint: Update SessionStart/PreCompact hooks to use 'bash ~/.claude/hooks/session-start.sh'
      This enables session_id passthrough for gt seance discovery.
```

## Related

- session-start.sh extracts session_id from Claude Code stdin JSON
- gt prime outputs [GAS TOWN] metadata line for seance
- gt seance discovers sessions from .events.jsonl

Added session-hooks doctor check to verify settings.json files use session-start.sh


gt rig status: Show single-rig status summary

Add 'gt rig status <rig>' command to show focused status for a single rig.

## Use Case
When working on a specific rig, you want to see just that rig's status without the full town overview from 'gt status'.

## Proposed Output
```
$ gt rig status gastown

─── gastown/ ───────────────────────────────────────────

🦉 Witness: running
🏭 Refinery: running (MQ: 2 pending)

👷 Crew (5): 2 active, 3 idle
😺 Polecats (3): 1 working, 2 idle

Open issues: 45
In progress: 3
Ready: 12
```

## Implementation
- Add 'status' subcommand to internal/cmd/rig.go
- Reuse status rendering logic from gt status
- Filter to single rig
- Optionally add --verbose for full agent list

Already implemented - binary was outdated


Digest: mol-deacon-patrol

Patrol complete: gastown witness came online, town healthy


Add await-work and plugin-run steps to mol-refinery-patrol

## Context

The mol-refinery-patrol needs two additional steps:

### 1. await-work (Decision Point)

Not just 'wait for signal' but a crossroads:
- Check for pending signals (mail, nudge, human)
- Check plugin gates (any plugins need to run?)
- Check maintenance schedule (daily/weekly due?)
- Evaluate context and decide next action

Position: Between burn-or-loop and inbox-check (the loop point)

### 2. plugin-run (Like Deacon)

Refinery needs plugin support for:
- **Monitors**: Flag PRs touching sensitive code
- **Gates**: Block merges under certain conditions
- **Schedulers**: Reorder queue based on priority/urgency
- **Maintenance**: Weekly cleanup, audits, stats
- **Audits**: Log merge statistics, track patterns

Position: After queue-scan, before process-branch

## Implementation

Update RefineryPatrolMolecule() in builtin_molecules.go to include:
- await-work step with decision tree
- plugin-run step with gate types

## Related
- gt-7920 (original mol-refinery-patrol)
- docs/deacon-plugins.md (existing plugin model)


Merge: dag-1767074322940

attached_args: Code review this merge request

branch: polecat/dag-1767074322940
target: main
source_issue: dag-1767074322940
rig: gastown


Extract timing constants to constants package

Extract hardcoded timing values to named constants.

## Files to modify
- internal/constants/constants.go (add constants)
- internal/cmd/start.go (use constants)
- internal/tmux/tmux.go (use constants)

## Implementation
Add to constants.go:
```go
const (
    ShutdownNotifyDelay  = 500 * time.Millisecond
    ClaudeStartTimeout   = 15 * time.Second
    ShellReadyTimeout    = 5 * time.Second
    DefaultDebounceMs    = 100
    DefaultDisplayMs     = 5000
)
```

## Acceptance criteria
- [ ] 5 timing constants added to constants.go
- [ ] start.go uses ShutdownNotifyDelay, ClaudeStartTimeout, ShellReadyTimeout
- [ ] tmux.go uses DefaultDebounceMs, DefaultDisplayMs
- [ ] go build ./... passes
- [ ] go test ./... passes


Consolidate duplicate formatAge functions in feed TUI

formatConvoyAge in convoy.go is nearly identical to formatAge in view.go. Consolidate into one shared function.

Consolidated formatConvoyAge into formatAge - both now use 'just now' for < 1 minute


Bug: bd update --parent doesn't persist

The --parent flag on bd update reports success but doesn't persist the parent field.

**Confirmed behavior:**
```bash
bd update gt-9kp3t --parent=gt-d0jqp --no-daemon -v
# Output: ✓ Updated issue: gt-9kp3t

bd show gt-9kp3t --json | jq '.[0].parent'
# Returns: null

grep gt-9kp3t .beads/issues.jsonl | head -1 | jq '.parent'
# Returns: null (field not present)
```

**Root cause hypothesis:**
The update handler processes the --parent flag but either:
1. Doesn't write it to the Issue struct
2. Doesn't include it in the JSONL export
3. The field name doesn't match what export expects

**Files to check:**
- cmd/bd/show.go:638-640 (flag handling)
- cmd/bd/show.go:810-814 (reparenting logic)
- internal/rpc/server_issues_epics.go (RPC handler)
- internal/rpc/protocol.go (UpdateArgs.Parent field)

Related: bd-cj2e (the original feature implementation)


Test swarm epic


Digest: mol-deacon-patrol

Patrol 68: Routine


Instrument gt commands to appear in activity feed

## Architecture: Two-tier event system

```
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│ gt commands │  │ bd mutations│  │ agent output│
└──────┬──────┘  └──────┬──────┘  └──────┬──────┘
       └────────────────┼────────────────┘
                        ▼
              ~/gt/.events.jsonl (raw, audit)
                        │
              ┌─────────────────┐
              │  Feed daemon    │ ← goroutine in gt daemon
              │  - filters      │
              │  - aggregates   │
              │  - AI curates   │
              └────────┬────────┘
                       ▼
              ~/gt/.feed.jsonl (curated, user-facing)
```

## Event format

```json
{
  "ts": "2025-12-28T10:30:15Z",
  "source": "gt",
  "type": "sling",
  "actor": "mayor",
  "payload": {"bead": "gt-xyz", "target": "gastown/Toast"},
  "visibility": "feed"
}
```

Visibility: `audit` | `feed` | `both`

## Implementation phases

1. **Event logging** - gt commands write to ~/gt/.events.jsonl
2. **Feed daemon** - goroutine in gt daemon tails events, writes curated feed
3. **Feed readers** - gt feed, gt dashboard read from .feed.jsonl
4. **AI curation** - future: haiku summarization for complex activity

Part of epic gt-u7dxq

Instrumented gt commands (nudge, unsling, up, down, stop, polecat_spawn) to emit events to ~/gt/.events.jsonl for the activity feed


Digest: mol-deacon-patrol

Patrol 159: All healthy


Digest: mol-deacon-patrol

Patrol 9: All clear


Digest: mol-deacon-patrol

P14: stable


Tmux session scanner for running agents

Scan tmux for running Gas Town agent sessions.

## Deliverables

1. Function: ScanRunningSessions() -> []AgentAddr
   - Parse tmux list-sessions
   - Filter for Gas Town session naming pattern
   - Return addresses of running agents

2. Function: ScanRigSessions(rig) -> []AgentAddr
   - Filter running sessions by rig prefix

3. Alias resolution:
   - #rig/gastown → running sessions in gastown
   - #town → all running Gas Town sessions
   - #witnesses → running witness sessions

## Location
internal/discovery/tmux.go

## Acceptance
- Scanner finds running sessions
- Correctly parses session names to addresses
- Handles no-sessions case gracefully


Merge: keeper-mjtn0wgm

branch: polecat/keeper-mjtn0wgm
target: main
source_issue: keeper-mjtn0wgm
rig: gastown


Digest: mol-deacon-patrol

Patrol 122: All healthy, no callbacks, 3 convoys tracking


Merge: gt-svdsy

branch: polecat/capable-mjtltnm5
target: main
source_issue: gt-svdsy
rig: gastown


Digest: mol-deacon-patrol

Patrol 259 complete: no incidents


Digest: mol-deacon-patrol

Patrol complete: beads witness+refinery came online, both rigs healthy


Merge: dementus-mjw46vz4

branch: polecat/dementus-mjw46vz4
target: main
source_issue: dementus-mjw46vz4
rig: gastown
agent_bead: gt-gastown-polecat-dementus


Digest: mol-deacon-patrol

Patrol complete: all healthy


Merge: capable-mjxen9vb

branch: polecat/capable-mjxen9vb
target: main
source_issue: capable-mjxen9vb
rig: gastown
agent_bead: gt-gastown-polecat-capable


Formula schema: Define formula.toml structure

Define the formula file format in .beads/formulas/:
- formula name and description
- input parameters (pr, branch, files)
- legs array with name, focus, output
- synthesis config
- dependencies between legs

Reference: gt-ubqeg.1 epic description for schema ideas.
Create example formula: code-review.formula.toml

Schema defined in internal/formula/types.go (a395b4e)


Digest: mol-deacon-patrol

Patrol cycle 4: all healthy


Beads daemon cache stale - hook queries return wrong data

Root cause: Beads daemon has stale data. Multiple bd daemons running (4 instances). When gt hook status queries via daemon, it gets old hooked bead. When queried with --no-daemon, correct bead is shown. This is a daemon cache coherence issue, not an ID resolution bug. Workaround: Use bd --no-daemon commands or restart daemons.

Fixed: Hook discovery now reads from database column (hook_bead) instead of parsing stale description field


Merge: gt-svdsy


Session pre-shutdown checks

Session stop should verify clean state before killing, like PGT.

## Pre-Shutdown Checks

### 1. Git Working Tree Clean
```go
func checkGitClean(clonePath string) error {
    // git status --porcelain
    // Fail if any output
}
```

### 2. All Commits Pushed
```go
func checkCommitsPushed(clonePath string) error {
    // git log origin/HEAD..HEAD
    // Fail if any unpushed commits
}
```

### 3. Assigned Issues Handled
```go
func checkIssuesHandled(polecat *Polecat) error {
    // If polecat.Issue != "", check if closed or reassigned
}
```

### 4. Beads Synced
```go
func checkBeadsSynced(clonePath string) error {
    // bd sync --status in clone directory
}
```

## Behavior on Failure
1. First attempt: Nudge worker to fix
2. Retry up to 3 times with delay
3. After retries: Escalate to Witness/Mayor

## Integration
Modify internal/session/manager.go Stop():
```go
func (m *Manager) Stop(polecat string, force bool) error {
    if !force {
        if err := m.runPreShutdownChecks(polecat); err != nil {
            return fmt.Errorf("pre-shutdown checks failed: %w", err)
        }
    }
    // existing stop logic
}
```

## Flags
- --force: Skip checks
- --grace-period N: Time to wait for fixes

## Dependencies
- Ties into gt-69l (hook system) - can be hook-based
- Ties into gt-f8v (Witness pre-kill verification)

## Acceptance Criteria
- [ ] Stop fails if uncommitted changes (without --force)
- [ ] Stop fails if unpushed commits
- [ ] Clear error messages with fix instructions
- [ ] --force bypasses all checks


Digest: mol-deacon-patrol

Patrol 107: All healthy


Digest: mol-deacon-patrol

Patrol 141 complete: All agents healthy, no incidents, no orphans


Digest: mol-deacon-patrol

Patrol 145 complete: All healthy


Migrate startup paths from SessionBeacon to StartupNudge

## Problem
StartupNudge function exists (gt-bgfqy) but no code uses it.
All startup paths still call session.SessionBeacon() + 'gt prime' separately.

SessionBeacon format: [GAS TOWN] address • molID • timestamp
StartupNudge format: [GAS TOWN] recipient <- sender • timestamp • topic

The key difference is SENDER - needed for seance discovery ('who started this session?').

## Files to Update
- internal/cmd/crew_lifecycle.go (lines 354-371, 525-538)
- internal/cmd/start.go (lines 757, 805-810, 946-949)
- internal/cmd/deacon.go (line 307)
- internal/cmd/witness.go (line 350)
- internal/cmd/up.go (lines 288, 335, 559, 660)
- internal/cmd/mayor.go (line 151)
- internal/session/manager.go (lines 205, 215)

## Pattern
Replace:
  beacon := session.SessionBeacon(address, molID)
  t.NudgeSession(sessionID, beacon)
  t.NudgeSession(sessionID, "gt prime")

With:
  cfg := session.StartupNudgeConfig{Recipient: address, Sender: sender, Topic: topic, MolID: molID}
  session.StartupNudge(t, sessionID, cfg)
  // Note: StartupNudge is the session title, still need separate 'gt prime' for priming

## Related
- gt-85whr (parent epic)
- gt-j0546 (did RuntimeConfig refactor, not StartupNudge)

Migrated all 12 startup paths from SessionBeacon to StartupNudge. All startup paths now include sender information for better seance discovery. Files updated: crew_lifecycle.go (3), start.go (2), deacon.go (1), witness.go (1), up.go (4), mayor.go (1), session/manager.go (1). Build passes, all tests pass.


Day 3.5: Test polecat → refinery → merged flow

Integration test:
1. Spawn polecat with work
2. Polecat completes (updates state, closes bead)
3. Witness detects completion
4. Witness sends MERGE_READY
5. Refinery processes and merges
6. MERGED signal received

Parent: gt-hwka3


HOP: Skill vectors on work items

Add skill embeddings to work items for capability-based matching. See ~/ai/stevey-gastown/hop/CONTEXT.md. Post-v0.1 work.


Digest: mol-deacon-patrol

Patrol #17


Add gt seance command for predecessor discovery

## Purpose

**"Where did you put the stuff you left for me?"** - The #1 question in any handoff.

Seance lets you literally talk to your predecessor. Not parse their logs - commune with them.

## The Insight

Claude Code can resume sessions with full context. A seance spawns a Claude subprocess that resumes a predecessor session, letting you ask questions directly:
- "Why did you make this decision?"
- "Where were you stuck?"
- "What did you try that did not work?"

## Architecture

```
gt seance --talk <session-id>
    │
    └─▶ claude --fork-session --resume <id>
        │
        └─▶ Spawns in sandbox namespace (ghost-joe)
            │
            └─▶ Communication via tmux
                "Where is the config you mentioned?"
                → Predecessor has full context, answers
```

**Key flags:**
- `--fork-session` creates new session ID (read-only seance, no grave disturbance)
- `--resume <id>` loads predecessor context

## Discovery

Sessions are discoverable via:
1. **Beacon in transcript** - `[GAS TOWN] role • topic • timestamp` searchable via `/resume`
2. **SessionStart events** - Hook emits to `~/gt/.events.jsonl` (our data, ZFC-compliant)
3. **Claude /resume search** - Native filtering

## Usage

```bash
gt seance                     # List discoverable sessions
gt seance --role crew         # Filter by role
gt seance --rig gastown       # Filter by rig
gt seance --recent 10         # Last N sessions

gt seance --talk <id>         # THE SEANCE - talk to predecessor
gt seance --talk <id> -p "Where is X?"  # One-shot question
```

## ZFC Compliance

- **No parsing Claude internals** - Use Claude CLI to resume
- **Agent discovers** - Claude reads session, interprets, responds
- **Events are ours** - SessionStart hook writes to our event stream

## Beacon Format

```
[GAS TOWN] gastown/crew/joe <- deacon • 2025-12-30T15:42 • assigned:gt-xyz
```

Searchable via `claude --resume "GAS TOWN"` or `claude --resume "gastown/crew/joe"`

Implemented ZFC-compliant seance with --talk flag for literal predecessor conversations


BUG: gt convoy create with count argument doesn't set convoy description

Root cause: 'gt convoy create' usage is 'create <name> [issues...]' but we invoked 'gt convoy create 1 beads' expecting polecat count semantics.

The '1' became the convoy name, 'beads' was treated as an issue ID (failed to track).

Options:
1. Add --count flag for polecat spawning semantics
2. When issues are added later via 'convoy add', update convoy title if current title is just a number
3. If first arg looks like an issue ID (has prefix), auto-generate name from issue title

For now, users must use: 'gt convoy create "Descriptive name" issue-id' not 'gt convoy create <count> <rig>'

Fixed: convoy create now auto-detects issue IDs and generates name from issue title


Digest: mol-deacon-patrol

Patrol 14: All healthy.


QUICK FIX: Make gt crew start use NudgeSession instead of SendKeys

## The Immediate Problem
`gt crew start gus` fails to deliver the GUPP nudge because:
1. Uses `t.SendKeys(sessionID, "gt prime")` which has the Enter-concatenation bug
2. Should use `t.NudgeSession()` which solves this reliably

## Quick Fix
In start.go, change line ~809:
```go
// Before
if err := t.SendKeys(sessionID, "gt prime"); err != nil {

// After
if err := t.NudgeSession(sessionID, "gt prime"); err != nil {
```

Same fix needed in:
- start.go:756 (restart path)
- crew_lifecycle.go:354
- crew_lifecycle.go:525

## Why This Is P0
Cold starts of crew workers are broken. This blocks basic usage.

## Note
This is a stopgap. The full solution is the StartupNudge refactor (gt-bgfqy).

Fixed: Replaced SendKeys with NudgeSession for gt prime in start.go and crew_lifecycle.go


Digest: mol-deacon-patrol

Patrol cycle 5: All 6 agents healthy


Default crew name should be something better than 'main'

When creating a new rig, the default crew worker name is 'main'. This is confusing since:

1. 'main' is also the git branch name
2. It doesn't convey that this is the user's personal workspace
3. Crew names should feel more personal/distinct

Consider alternatives like:
- 'home' - the user's home base
- 'desk' - their personal desk
- 'joe/max/etc' - actual name-based defaults
- Let user pick during rig init


Day 3.4: Refinery processes MERGE_READY mail

Refinery patrol handles merge requests:
1. Check inbox for MERGE_READY messages
2. For each, verify branch exists
3. Run merge checks (tests, lint)
4. If passing, merge to main
5. Send MERGED signal back

Parent: gt-hwka3


Digest: mol-deacon-patrol

Patrol complete: no callbacks, all agents healthy, no orphans, doctor 24/28


Witness cleanup leaves worktree behind

When witness processes POLECAT_DONE:
- Session is killed ✓
- Work is merged ✓
- Worktree is NOT removed ✗

Dementus example: session 'not running', but /Users/stevey/gt/gastown/polecats/dementus still exists.

Expected: gt polecat nuke equivalent - full cleanup including worktree deletion.

Fixed: HandleMerged now calls witness.AutoNukeIfClean to cleanup worktrees after merge


Digest: mol-deacon-patrol

Patrol 11: 3 rigs healthy


Digest: mol-deacon-patrol

Patrol 11: all healthy


Digest: mol-deacon-patrol

Patrol 35: all quiet


Digest: mol-deacon-patrol

Patrol 14


Digest: mol-deacon-patrol

Patrol 133: All healthy


Digest: mol-deacon-patrol

Patrol cycle 11: All healthy


Digest: mol-deacon-patrol

Patrol cycle 20: all healthy, handoff


Digest: mol-deacon-patrol

Patrol 121: All agents healthy, 6 health pings sent, no callbacks, no orphans, 1 idle dog, inbox clean


Digest: mol-deacon-patrol

Cycle 298: All healthy, refinery processing


Merge: gt-fpv2p

branch: polecat/capable-mjw47ef9
target: main
source_issue: gt-fpv2p
rig: gastown
agent_bead: gt-gastown-polecat-capable


Merge: dementus-1767146229184

branch: polecat/dementus-1767146229184
target: main
source_issue: dementus-1767146229184
rig: gastown


Digest: mol-deacon-patrol

Patrol 13: All clear


Merge: nux-1767079896198

branch: polecat/nux-1767079896198
target: main
source_issue: nux-1767079896198
rig: gastown


Digest: mol-deacon-patrol

Cycle 20 - handoff threshold


Digest: mol-deacon-patrol

Patrol 100: All healthy - milestone!


Merge: slit-mjvtz18y

branch: polecat/slit-mjvtz18y
target: main
source_issue: slit-mjvtz18y
rig: gastown
agent_bead: gt-gastown-polecat-slit


Session: gt-gastown-test completed gt-f7jxr


Digest: mol-deacon-patrol

Patrol 13: All healthy


Merge: nux-1767075895486

branch: polecat/nux-1767075895486
target: main
source_issue: nux-1767075895486
rig: gastown


Link MR bead to agent bead for traceability

MR bead and agent bead are separate with no cross-reference.

## Problem
- MR bead tracks: branch, target, source_issue
- Agent bead tracks: state, hook_bead, cleanup_status
- No link between them

When something goes wrong, hard to trace which polecat created which MR.

## Fix
1. MR bead should include agent_bead field
2. Agent bead should include active_mr field
3. On gt done: update both to reference each other
4. On merge: clear both references

## Benefits
- Traceable: given MR, find polecat
- Traceable: given polecat, find MR
- Orphan detection: MR without agent = stale

Implemented bidirectional cross-references between MR beads (agent_bead field) and agent beads (active_mr field). gt done now sets both, refinery clears on merge.


Digest: mol-deacon-patrol

Patrol cycle 20: All healthy, handoff threshold reached


Agent Startup Consolidation: Unified nudge, seance metadata, LLM-agnostic

## Problem

Agent startup nudge logic is scattered across 6+ files with inconsistent behavior:
- start.go, crew_lifecycle.go, crew_at.go, handoff.go, deacon.go, witness.go

Some paths work (handoff), others fail (crew start). The core issues:

1. **tmux send-keys Enter issue**: `send-keys "foo" Enter` concatenates, doesnt send Enter separately
2. **All sessions look identical**: First message is "gt prime" everywhere, `/resume` shows duplicate-looking sessions
3. **No seance metadata**: Cant differentiate predecessors by sender, role, timestamp, topic
4. **Hardcoded to Claude**: `claude --dangerously-skip-permissions` everywhere

## Solution

1. **Unified StartupNudge function** - All paths call one function with rich metadata
2. **Seance-aware nudge format** - First message contains: sender, recipient, timestamp, topic
3. **Runtime configuration** - LLM command/args in config, not hardcoded
4. **gt seance command** - Find and resume predecessor sessions

## Nudge Format

The startup nudge becomes the session title in `/resume`:
```
[GAS TOWN] gastown/crew/gus ← mayor • 2025-12-30T15:42 • cold-start
```

Components:
- Address: gastown/crew/gus (recipient identity)
- Sender: mayor, deacon, witness, self (for handoff)
- Timestamp: When session started
- Topic: mol-id, "cold-start", "handoff", etc.

## Key Insight

The GUPP nudge content doesnt matter for triggering propulsion - agent already read CLAUDE.md and hooks ran. What matters is:
1. The nudge arrives reliably (NudgeSession solves this)
2. The nudge creates a unique, identifiable session title

## Related

- gt-p2o6s: Extend gt nudge to support channel:name syntax
- gt-9guv2: Messaging Channels epic
- Session beacon already exists but is for identity, not session title

All success criteria met: (1) All agent startups use unified StartupNudge (gt-7pp3l), (2) Runtime commands from config (gt-j0546), (3) Sessions identifiable in /resume by role, sender, time, topic, (4) gt seance works for predecessor discovery (gt-7qvd7). Related Phase 1 tasks (gt-bgfqy, gt-dc2fs) also complete.


Merge: slit-mjxaptzz

branch: polecat/slit-mjxaptzz
target: main
source_issue: slit-mjxaptzz
rig: gastown
agent_bead: gt-gastown-polecat-slit


Merge: capable-1767146233256

branch: polecat/capable-1767146233256
target: main
source_issue: capable-1767146233256
rig: gastown


gt hook: Support viewing other agents' hooks

Currently `gt hook` only shows your own hook. Would be useful to query any agent's hook:

```
gt hook show gastown/polecats/nux    # What's nux working on?
gt hook show gastown/witness         # What's the witness hooked to?
```

**Use cases**:
- Mayor checking what polecats are working on
- Witness checking polecat status
- Debugging coordination issues
- Quick status overview

**Compact output** (one line):
```
gastown/polecats/nux: gt-abc123 'Fix the widget bug' [in_progress]
```

Filed by: gastown/polecats/nux (agent UX feedback)

Implemented gt hook show <agent> with compact one-line output format


Digest: mol-deacon-patrol

Patrol cycle 66: All healthy


Digest: mol-deacon-patrol

Patrol 36: rictus removed from rig


Digest: mol-deacon-patrol

Patrol 260 complete: final cycle before handoff


Merge: dementus-1767079823043

branch: polecat/dementus-1767079823043
target: main
source_issue: dementus-1767079823043
rig: gastown


Add compaction recovery protocol to role templates

After context compaction (summarization), agents may be disoriented.

Add guidance to recognize and recover:
- 'If you feel you've lost earlier context or are disoriented, run: gt prime'
- 'This re-injects your role, current work, and pending messages'
- 'It's safe to prime multiple times - it just outputs context'

This is the fallback path when self-check is missed and compaction happens.
Compaction isn't catastrophic if priming is robust.


Digest: mol-deacon-patrol

Patrol #10: All healthy


Review: Witness patrol template changes (gt-h1n5)

Polecat rictus implemented significant witness.md.tmpl changes: banners, wisp-based execution, handoff bead attachment, loop-or-exit, patrol summary. Review for correctness and consistency with deacon pattern.


Digest: mol-deacon-patrol

Patrol 12: Routine


Merge: toast-1767074978542

branch: polecat/toast-1767074978542
target: main
source_issue: toast-1767074978542
rig: gastown

Branch no longer exists on remote - already merged or cleaned up


Digest: mol-deacon-patrol

Patrol 24: All quiet


CLI: plugin commands (list, status)

Add gt plugins <rig> to list plugins and gt plugin status <name> to check plugin state. Simple directory scan of <rig>/plugins/.


Polecats should spawn with auto-accept mode enabled

During swarm bd-784c, polecats (Toast, Nux) were spawned without --dangerously-skip-permissions or equivalent auto-accept mode.

**Problem:**
Every edit, bash command, and tool use required manual confirmation via tmux send-keys. This defeats the purpose of autonomous polecat operation.

**Expected:**
Polecats in a swarm should run with permissions bypassed so they can work autonomously.

**Suggestion:**
- gt sling should pass --dangerously-skip-permissions by default for polecats
- Or polecats should have a .claude/settings.local.json pre-configured for auto-accept

Main fix (--dangerously-skip-permissions for polecat sessions) was already in place since ec29ca07 (Dec 17). Fixed naked mode help text to also show the flag. All spawn paths verified: session.Manager.Start(), swarm spawning, and manual naked mode now all use --dangerously-skip-permissions.


Digest: mol-deacon-patrol

Patrol cycle 42: All agents healthy, no incidents


Digest: mol-deacon-patrol

Patrol cycle 3: All 6 agents healthy, no incidents


Digest: mol-deacon-patrol

P12: stable


Comprehensive help text and examples

Improve help text with examples and cross-references.

## Improvements

### 1. Examples Section
Add to Long description:
```go
var spawnCmd = &cobra.Command{
    Long: `Spawn a polecat with work assignment.

Examples:
  gt spawn gastown/Toast --issue gt-abc
  gt spawn gastown --issue gt-def          # auto-select polecat
  gt spawn gastown/Nux -m "Fix the tests"  # free-form task`,
}
```

### 2. Cross-References
Reference related commands:
```
See also:
  gt polecat list    List available polecats
  gt session attach  Attach to spawned session
```

### 3. Flag Descriptions
More detail on flags:
```go
cmd.Flags().StringVar(&issue, "issue", "",
    "Beads issue ID to assign. The polecat will work on this issue.")
```

### 4. Common Workflows
Add workflow docs to gt --help:
```
Common Workflows:
  Start a swarm:
    gt swarm preflight
    gt swarm create gastown --epic gt-abc --worker Toast --worker Nux --start
    gt refinery start gastown

  Check status:
    gt status
    gt swarm status <id>
```

## Files to Update
All internal/cmd/*.go files

## Acceptance Criteria
- [ ] All commands have Examples
- [ ] Related commands cross-referenced
- [ ] Flags have detailed descriptions
- [ ] Root help shows workflows


Digest: mol-deacon-patrol

Patrol cycle 38: All healthy, no incidents


Update Deacon template to emphasize staying in ~/gt/deacon directory

The Deacon template should instruct the agent to stay in ~/gt/deacon/ as much as possible, and always return there after any excursion. This prevents issues with identity detection (mail, mol status) which depend on cwd.


test-new-swarm-1767338498


Merge: furiosa-mjwnxrkd

branch: polecat/furiosa-mjwnxrkd
target: main
source_issue: furiosa-mjwnxrkd
rig: gastown
agent_bead: gt-gastown-polecat-furiosa


Stranded convoy detection + feeding via dog dispatch

## Problem
Convoys can become **stranded** - they have ready work but no polecats working on it. Work is waiting for a ride.

## Definition: Stranded Convoy
```
convoy is open
  AND has tracked issues where:
    - status = open (not in_progress, not closed)
    - not blocked (dependencies met)
    - no assignee (or assignee session is dead)
```

If all open issues are blocked or have live polecats → convoy is fine (in-flight).
If ready issues exist with nobody working them → convoy is stranded.

## Solution: Deacon patrol + dog dispatch

**Detection (Deacon patrol step):**
Check open convoys for stranded state.

**Dispatch:**
```bash
gt sling mol-convoy-feed deacon/dogs --var convoy=<convoy-id>
```

**mol-convoy-feed formula (single pass):**
1. Load convoy, find ready issues (not blocked, no assignee)
2. Check idle polecat capacity
3. Dispatch min(ready_issues, idle_polecats)
4. Exit

Dog doesn't babysit. Just feeds and leaves. Deacon's patrol loop handles repeated checking - if still stranded next cycle, dispatches dog again.

## Benefit
Stateless, batch-oriented. Convoys become fire-and-forget.

(Moved from hq-1h2to)

Implemented stranded convoy detection with gt convoy stranded command, mol-convoy-feed formula, and deacon patrol step


Digest: mol-deacon-patrol

Patrol cycle 49: All healthy


Plugin/molecule catalog integration design

Two currently independent systems:
1. Disk-based plugins (~~/gt/plugins/) - Deacon patrol extensions
2. Molecule catalog (protos in beads) - bd pour/wisp/bond

Investigate integration points:
- User-contributed molecules bonded to catalog
- Dynamic molecule attachment during execution (e.g., 'attach security sniffer because we noticed condition X')
- How plugins could contribute protos
- How protos could trigger plugins

Not blocking launch. Future design investigation.


Digest: mol-deacon-patrol

Cycle 18


Enhance Mayor CLAUDE.md with GGT milestone tracking

Update ~/ai/CLAUDE.md (Mayor startup context) with:

1. GGT Self-Hosting Milestone section
   - Track progress toward gt replacing town
   - Key blockers: gt-h5n (merge queue), gt-974 (daemon)
   - What "self-hosting" means (GGT working on itself)

2. Recent Architecture Decisions
   - Engineer = role, Refinery = place
   - Merge queue in Beads (not branch discovery)
   - Session restart protocol

3. Transition Plan
   - Current: use town commands (PGT)
   - Target: use gt commands (GGT)
   - Switch criteria: gt-b1g closed

Keep it concise - Mayor context should be quick to scan.


Digest: mol-deacon-patrol

Patrol cycle 3: healthy, 2 acks


Digest: mol-deacon-patrol

Patrol cycle 6: All agents healthy


Digest: mol-deacon-patrol

Patrol cycle 10: All 3 rigs healthy. No incidents.


Define meta-formula YAML schema

Define the YAML schema for meta-formulas that generate multiple formulas.

## Proposed Schema

    type: meta-formula
    name: multi-lang-shiny
    generates:
      for-each:
        var: lang
        values: [go, python, typescript]
      formula:
        name: "shiny-{lang}"
        extends: base-shiny
        vars:
          language: "{lang}"

## Key Decisions

- Use "generates" key to distinguish from regular formulas
- for-each at generation level (not runtime)
- Output is N formula files or in-memory formulas

## Deliverables

1. Add MetaFormula type to types.go
2. Add ForEachGenerate struct
3. Document schema in comments


Implement meta-formula generator in parser

Implement the generator that expands meta-formulas into concrete formulas.

## Implementation

1. Detect type: meta-formula in parser
2. Evaluate for-each values
3. For each value, instantiate the formula template
4. Substitute {var} placeholders with current value
5. Return list of generated Formula structs

## API

    func (p *Parser) ExpandMetaFormula(mf *MetaFormula) ([]*Formula, error)

## Edge Cases

- Empty values list: return empty slice
- Duplicate generated names: error
- Nested meta-formulas: error (not supported initially)


Add multi-lang-shiny example and tests

Create example meta-formula and test suite.

## Example

Create .beads/formulas/multi-lang-shiny.meta.yaml:
- Generates shiny-go, shiny-python, shiny-typescript
- Each extends base-shiny with language-specific vars

## Tests

1. Test basic expansion (3 languages -> 3 formulas)
2. Test variable substitution in names and content
3. Test error on duplicate generated names
4. Test empty values list
5. Integration: cook a generated formula


Design org formula hierarchy pattern

Design how organizational formula hierarchies work.

## Pattern

    company-base.formula.yaml (org-wide policies)
      └── team-frontend.formula.yaml (extends company-base)
           └── project-dashboard.formula.yaml (extends team-frontend)

## Key Questions

1. How are org formulas discovered? (search path? explicit import?)
2. How do aspects merge across levels?
3. Can child override parent aspects?
4. How to handle aspect conflicts?

## Proposed Design

- Formulas use extends: just like today
- Aspect lists merge (child appends to parent)
- Child can exclude parent aspects via "exclude-aspects: [name]"
- Search path: local -> rig -> org (configurable)

## Deliverables

1. Document pattern in docs/formula-inheritance.md
2. Define conflict resolution rules
3. Identify implementation tasks


Implement aspect merging across formula chain

Implement merging of aspects when formulas extend each other.

## Current State

extends: already works for steps and vars.
Aspects need similar merge behavior.

## Implementation

1. In Resolve(), collect aspects from entire extends chain
2. Merge lists: parent aspects first, then child
3. Support exclude-aspects field to remove inherited aspects
4. Dedupe by aspect name (child wins on conflict)

## Files

- internal/formula/parser.go: Resolve()
- internal/formula/types.go: add ExcludeAspects field

## Tests

1. Child inherits parent aspects
2. Child adds additional aspects
3. Child excludes parent aspect
4. Three-level chain merges correctly


Add org formula examples and tests

Create example organizational formula hierarchy and tests.

## Examples

Create in .beads/formulas/:
- acme-base.formula.yaml: Company-wide (security-audit aspect)
- acme-frontend.formula.yaml: extends acme-base, adds accessibility-audit
- acme-backend.formula.yaml: extends acme-base, adds sql-injection-scan

## Tests

1. Three-level inheritance resolves correctly
2. Aspect merge order is correct
3. exclude-aspects removes parent aspect
4. Cooking org formula produces expected steps
5. Error on missing parent formula


Formula error handling and recovery

Specify how cooking errors are reported and recovered:
- What happens when extends chain is broken (missing formula)?
- What happens when aspect pointcut matches nothing?
- What happens when expansion produces invalid structure?
- Graceful degradation vs fail-fast semantics
- Error metadata in cooked protos

Deferred: post-launch polish


Formula versioning and migration strategy

Define how formula versions are managed:
- What does the version field mean? Semver? Integer?
- When a formula changes, what happens to existing protos?
- Do protos track their source formula version?
- Migration path: old proto + new formula = ?
- Backwards compatibility guarantees (if any)

Deferred: post-launch polish


Proto debugging and inspection tools

Proto debugging and inspection tools.

With ephemeral protos (gt-4v1eo), this becomes:
- `bd cook <formula> --dry-run` - preview cooked output without persisting
- `bd cook <formula> --json` - output proto as JSON for inspection
- `bd cook <formula> --graph` - visualize step DAG

No persistent proto beads to inspect - formulas are the source of truth.


Formula validation specification

Complete validation rules for formulas:
- Required vs optional fields
- Valid step ID patterns
- Valid pointcut glob syntax
- Variable reference validation
- Compose rule ordering constraints
- Type-specific validation (workflow vs expansion vs aspect)

Deferred: post-launch polish


Support nested expansion formulas


Polecat prompting: gt mq submit on completion

Update Polecat CLAUDE.md prompting to:

1. On task completion, run: gt mq submit --issue <id>
2. This creates a merge-request bead in the queue
3. Engineer will process it

The Polecat self-reports completion to the merge queue.


Schematic: Domain-Level Formula Composition

A Schematic is a coordinated set of formulas defining an entire workflow domain.

## Concept

Like an orchestra score to instrument parts - says how formulas fit together.

```toml
# shiny-engineering.schematic
[schematic]
name = "The Shiny Way"
description = "Full engineering workflow from issue to production"

[formulas]
planning = "@gastown/shiny"
development = "@gastown/polecat-work"
review = "@gastown/review"
release = "@gastown/release"

[flow]
default = "planning >> development >> review >> release"

[constraints]
all_code_reviewed = true
tests_before_deploy = true
```

## Relationship to Other Concepts

- **Schematic** (workflow dimension) = composition of Formulas
- **Campaign** (work dimension) = composition of Epics
- Schematic compiles to Campaign, like Formula compiles to Molecule

## Use Cases

1. Define "The Shiny Way" for a team/org
2. Encode compliance requirements
3. Standardize workflows across projects
4. Enable workflow reuse and sharing

## Open Questions

1. File format - TOML? YAML? Extend formula syntax?
2. Validation - how to verify schematic consistency?
3. Overrides - can project override org schematic?

## Related

- docs/formula_evolution.md
- gt-8tmz - molecule algebra


Digest: mol-deacon-patrol

Patrol 6: All healthy


Digest: mol-deacon-patrol

Patrol 14: 3 rigs healthy


Digest: mol-deacon-patrol

Patrol 112: All healthy


Digest: mol-deacon-patrol

Patrol 41: final patrol before handoff


Merge: capable-mjtltnm5

branch: polecat/capable-mjtltnm5
target: main
source_issue: capable-mjtltnm5
rig: gastown


Witness Patrol

Per-rig worker monitor patrol loop with progressive nudging.


Digest: mol-deacon-patrol

Patrol cycle 20


Digest: mol-deacon-patrol

Patrol 13: Quiet


Digest: mol-deacon-patrol

Patrol 1: All 6 agents healthy, no incidents, inbox clean


Digest: mol-deacon-patrol

Patrol 4: MQ cleared (0), all healthy


Add tmux hotkey (C-b f) for gt feed window

## Goal

Add a tmux hotkey (e.g., C-b f) that jumps to the activity feed window, creating it if it doesn't exist.

## Behavior

1. If 'feed' window exists in current session → switch to it
2. If 'feed' window doesn't exist → create it with `bd activity --follow`, then switch

## Implementation

Add to gt's tmux session configuration (similar to SetCrewCycleBindings):

```go
// C-b f → jump to feed window
tmux bind-key -T prefix f run-shell "gt feed --window"
```

The `gt feed --window` command already handles:
- Creating the window if missing
- Switching to it if exists
- Running `bd activity --follow` in the window

## Where to add

- `internal/tmux/tmux.go` - add SetFeedBinding() method
- Call it from session configuration (ConfigureGasTownSession or similar)

## Testing

1. In tmux: C-b f should open/switch to feed window
2. Feed window should show streaming activity
3. C-b n/p should still work to cycle back to other windows


Digest: mol-deacon-patrol

Patrol cycle 1: All healthy. 3 rigs, all Witnesses/Refineries responding. No orphans, no cleanup needed, inbox clean.


Digest: mol-deacon-patrol

Patrol 12: All healthy


Add crew lifecycle support to Deacon

Currently crew sessions (like gastown/crew/max, beads/crew/dave) are marked as 'human-managed' and excluded from automated lifecycle.

## Current State
- `getManager(RoleCrew)` returns `"human"` (handoff.go:273)
- `gt handoff` for crew just prints a message, no lifecycle request sent
- Crew cannot request automated refresh from Deacon

## Desired State
Crew members should be able to request lifecycle actions from Deacon:
- `gt handoff --cycle` sends request to Deacon, which kills/restarts the crew session
- Useful when: context full, running molecules that need fresh session, automation

## Implementation
1. Change `getManager(RoleCrew)` to return `"deacon/"` (or new crew manager)
2. Teach Deacon to recognize crew session naming pattern
3. Add crew to Deacon's respawn loop handling
4. Test with `gt nudge` for reliable message delivery

## Use Case
Running a molecule (e.g., version-bump) and discovering mid-workflow that a fresh session is needed. Agent should be able to request refresh automatically rather than requiring human intervention.

## Related
- gt nudge: reliable message delivery to Claude sessions
- bd mol bond: molecule instantiation (coming in beads)


Digest: mol-deacon-patrol

Patrol 4: quick pass


Digest: mol-deacon-patrol

Patrol 72: Routine


Digest: mol-deacon-patrol

Patrol 2: All healthy, 12 polecats, nudged gastown (active work)


Merge: nux-1767073376184

branch: polecat/nux-1767073376184
target: main
source_issue: nux-1767073376184
rig: gastown


Polecat identity confusion leads to direct main commits

When polecats spawn without proper identity (due to gt-si6am and gt-y41ep):
1. They think they're mayor
2. They may commit from wrong directory (mayor/rig instead of polecats/<name>)
3. Work goes directly to main, bypassing merge queue

Observed: slit pushed 'gt polecat recycle' directly to main instead of its branch

Root cause:
- gt-si6am: Wrong CLAUDE.md template (says 'Mayor Rig Context')
- gt-y41ep: Env vars not exported (falls back to mayor detection)

Impact: CRITICAL - merge queue entirely bypassed, no refinery review


Merge: gt-4u49x

branch: polecat/furiosa-mjxn8bl8
target: main
source_issue: gt-4u49x
rig: gastown
agent_bead: gt-gastown-polecat-furiosa


Digest: mol-deacon-patrol

Patrol 154 complete


Refinery Engineer placeholder code references tombstoned gt-3x1.2

The Refinery Engineer module has placeholder code that references gt-3x1.2, which is now tombstoned (gt-3x1 epic was superseded).

## Affected code:

1. **internal/refinery/engineer.go:203-225** - ProcessMR() says "This is a placeholder that will be fully implemented in gt-3x1.2" and returns failure with "ProcessMR not fully implemented (see gt-3x1.2)"

2. **internal/refinery/engineer.go:279-291** - handleFailure() says "This is a placeholder that will be fully implemented in gt-3x1.4"

3. **internal/refinery/engineer.go:307-312** - ProcessMRFromQueue() returns "ProcessMRFromQueue not fully implemented (see gt-3x1.2)"

## Context:
gt-3x1 was about updating Refinery to use Beads merge queue. The approach may have changed. Need to either:
- Implement the actual merge logic (new issue)
- Remove the placeholder code if not needed
- Update references to point to current strategy

## Related:
- gt-3x1 (tombstone) - original epic
- Current MQ implementation may have superseded this

Removed stale gt-3x1.x references. Filed gt-pnv61 for implementing actual merge logic.


Merge: nux-1767082300311

branch: polecat/nux-1767082300311
target: main
source_issue: nux-1767082300311
rig: gastown


Messaging Channels: Unified list/queue/announce/nudge system

Implement the full messaging channel system for Gas Town.

TWO PARALLEL SYSTEMS:
1. Durable (polling): mail - list, queue, announce
2. Real-time (ephemeral): nudge - channels

ARCHITECTURE:
- Config: ~/gt/config/messaging.json (town-level)
- Messages: beads (.beads/issues.jsonl with type=message)

CHANNEL TYPES:
- list:name - Fan-out, each recipient gets copy (DONE)
- queue:name - Claim-based, exactly-once processing (gt-02431)
- announce:name - Bulletin board, read-only (gt-cqvgt)
- nudge channel:name - Real-time fan-out (gt-3txyh)

PRIORITY ORDER:
1. Queues - solves real polecat cleanup race condition
2. Nudge channels - gt broadcast mostly works but channels add precision
3. Announces - nice-to-have bulletin boards


Merge: toast-1767140378007

branch: polecat/toast-1767140378007
target: main
source_issue: toast-1767140378007
rig: gastown


Messaging infrastructure: lists, queues, channels

Multi-recipient and broadcast messaging for Gas Town.

## Phases

**Phase 1 - Foundation**: Config directory (gt-i6jvc)
**Phase 1 - Core**: list:, queue:, @group (requires agent-as-bead for @group)
**Phase 2 - Channels**: announce:, #channel, gt channel publish

## Addressing Syntax

| Prefix | Resolution | Storage | Claim? |
|--------|------------|---------|--------|
| `@group` | Dynamic (bead queries) | Fan-out (N copies) | No |
| `list:name` | Static config | Fan-out (N copies) | No |
| `queue:name` | Static config | Shared (1 copy) | Yes |
| `announce:name` | Static config | Shared (1 copy) | No |
| `#channel` | Dynamic (tmux) | None (ephemeral) | No |

## Alignment with Agent-as-Bead

@group resolution now uses agent bead queries:
- @rig/gastown → bd list --type=agent --rig=gastown
- @witnesses → bd list --type=agent --role_type=witness

This replaces the originally planned filesystem scanner (gt-xo05b, now closed).

## Independent Work

Config-based features (list:, queue:, announce:) can proceed without agent identity.
Only @group requires the agent schema from Pillar 1.


Swarm: E2E Swarm Test Epic

Swarm molecule orchestrating epic gt-1tpts.

Epic: gt-1tpts
Coordinator:

E2E Test: All tasks complete, swarm landed


Merge: valkyrie-mjw71b7u

branch: polecat/valkyrie-mjw71b7u
target: main
source_issue: valkyrie-mjw71b7u
rig: gastown
agent_bead: gt-gastown-polecat-valkyrie


CLI: worker status reporting commands

Worker status reporting CLI for polecats to report progress.

## Commands

### gt worker started
```
gt worker started <issue-id> [-m MESSAGE]
```
Reports work started on issue.

### gt worker progress
```
gt worker progress <issue-id> <0-100> [-m MESSAGE]
```
Reports percentage complete.

### gt worker blocked
```
gt worker blocked <issue-id> <reason> [-m MESSAGE]
```
Reports blocked status with reason.

### gt worker completed
```
gt worker completed <issue-id> [-m MESSAGE]
```
Reports task completion.

### gt worker failed
```
gt worker failed <issue-id> <reason> [-m MESSAGE]
```
Reports task failure.

## Implementation
Each command sends mail to refinery with structured content:
```go
type WorkerStatusReport struct {
    IssueID    string
    Status     string  // started|progress|blocked|completed|failed
    Progress   int     // 0-100 for progress
    Reason     string  // for blocked/failed
    Message    string  // optional detail
    ReportedAt time.Time
}
```

## Message Format
Subject: "[STATUS] <issue-id>: <status>"
Body: JSON-encoded WorkerStatusReport

## Default Recipient
```go
// Determine from context
func getDefaultRecipient() string {
    rig := os.Getenv("GT_RIG")
    if rig != "" {
        return rig + "/refinery"
    }
    return "refinery/"
}
```

## New File
internal/cmd/worker.go

## PGT Reference
gastown-py/src/gastown/cli/worker_cmd.py

## Acceptance Criteria
- [ ] All 5 commands implemented
- [ ] Status sent as mail to refinery
- [ ] Structured JSON body for parsing
- [ ] Works from polecat session context


Digest: mol-deacon-patrol

Patrol 2: all healthy, no incidents


Digest: mol-deacon-patrol

Patrol 4: 3 polecats working, all healthy


Digest: mol-deacon-patrol

Patrol 2: all clear, systems healthy


Day 1.4b: Create Deacon agent bead

Create gt-deacon agent bead for the Deacon (daemon beacon).

The Deacon is a separate Claude Code agent from Mayor:
- Receives the ONLY mechanical daemon heartbeats in the system
- Runs town plugins, cleanup, and monitoring
- Has own top-level directory: ~/gt/deacon/
- No rig preassignment (town-level, like Mayor)
- role_type: deacon

Agent bead structure:
```yaml
id: gt-deacon
type: agent
entity_platform: gastown
entity_org: steveyegge
entity_id: deacon
hook_bead: null  # or current patrol wisp
role_bead: gt-deacon-role
state: idle
role_type: deacon
```

Must be created alongside mayor, witness, refinery agent beads.


Refinery startup: Use Claude agent instead of foreground mode

WIP found in stash: Refactor refinery startup to spawn Claude as the refinery agent rather than using gt refinery start --foreground.

Changes needed:
- Use refineryDir (refinery/rig) as working directory
- Start Claude with --dangerously-skip-permissions
- Wait for shell ready, then Claude ready
- Send gt prime, then refinery startup prompt
- Remove foreground mode complexity

Related: gt-n7z7 (refinery --foreground race condition bug)


Refinery not processing merge-requests - stale MRs accumulating

Discovered 15 stale merge-request issues in beads rig that were never processed by the refinery. These appear to be from polecat branches that completed work but the refinery didn't pick up the merge-requests.

Closed issues:
- bd-r06v, bd-bhg7, bd-754r, bd-fcl1, bd-3zzh
- bd-bijf, bd-5rj1, bd-kptp, bd-rdzk, bd-ibl9
- bd-gfo3, bd-aq3s, bd-x2bd, bd-s1pz, bd-h27p

Need to investigate:
1. Why refinery isn't picking up merge-requests
2. Whether the polecat branches have valid work to merge
3. Add monitoring/alerting for stale MRs

Fixed: gt done and mq submit now write to mrqueue. Added gt mq migrate for stale MR recovery.


Digest: mol-deacon-patrol

Patrol 19: All healthy.


gt mail inbox shows wrong identity when run from deacon directory

When running 'gt mail inbox' from ~/gt/deacon/, it shows 'Inbox: mayor/' instead of 'Inbox: deacon/'. The role detection works (deacon checks in correctly), but mail identity detection is broken.


Digest: mol-deacon-patrol

Patrol 16: 3 rigs healthy


Digest: mol-deacon-patrol

Patrol 148 complete


Merge: gt-a95

branch: polecat/Ace
target: main
source_issue: gt-a95
rig: gastown


Digest: mol-deacon-patrol

Patrol cycle 16: all healthy


Digest: mol-deacon-patrol

Patrol cycle 22 complete. All 3 rigs healthy. No orphans, gates, convoys, or plugins. Quick cycle.


Digest: mol-deacon-patrol

Patrol cycle 12: All 6 agents healthy


Digest: mol-deacon-patrol

Patrol 153 complete


Critical packages lack test coverage

Several packages have no test files:
- internal/lock/ - Core identity locking (212 lines UNTESTED)
- internal/witness/ - Worker monitoring
- internal/mrqueue/ - MR queue management
- internal/claude/ - Claude integration
- internal/style/ - Terminal styling
- internal/constants/ - Constants

Priority for testing:
1. lock/ - prevents duplicate agents, critical for correctness
2. witness/ - agent lifecycle management
3. mrqueue/ - merge request processing

Overall: 37 test files for 160 Go files (23% by file count)


gt sling reports hook occupied but bd hook shows empty

gt sling thinks a hook is occupied when bd hook shows it empty. Example: bd hook --agent beads/crew/dave shows (empty), but gt sling bd-hobo beads/crew/dave says 'hook already occupied by bd-ul59'. They should use the same source of truth (beads database pinned field).

Fixed by using proper bd commands (bd agent state, bd slot set/clear) instead of embedding in description text. Now gastown and beads use the same SQLite columns for hook_bead and agent_state.


Merge: dementus-1767073385126

branch: polecat/dementus-1767073385126
target: main
source_issue: dementus-1767073385126
rig: gastown


gt spawn should verify daemon is running for polecat triggering

gt spawn notifies the Deacon (via mail) that a polecat was started, expecting the Deacon to trigger it once Claude is ready. But if the daemon isn't running, the mail sits unread and the polecat never gets triggered.

## Current Behavior
1. gt spawn starts polecat session
2. gt spawn sends POLECAT_STARTED to deacon/
3. (assumes daemon will trigger polecat)

## Problem
If gt daemon isn't running, step 3 never happens and polecat sits at prompt.

## Solution
In gt spawn, after session start:
1. Check if daemon is running (gt daemon status)
2. If not running, either:
   a. Start daemon: gt daemon start
   b. Or warn user: 'Daemon not running, polecat may not auto-start'

## Alternative
The user can manually trigger with gt nudge, but automated flow should work.


mol-sync-workspace: Fix 'commits ahead' in report for crew on main

Updated mol-sync-workspace generate-report step to use 'Unpushed commits' instead of 'Commits ahead of main' for crew workers on main branch.


Digest: mol-deacon-patrol

Patrol 15: All clear


Merge: gt-lynar

branch: polecat/furiosa-mjxeatgb
target: main
source_issue: gt-lynar
rig: gastown
agent_bead: gt-gastown-polecat-furiosa


Digest: mol-deacon-patrol

Patrol cycle 13: All agents healthy


Merge: organic-mjwjck2f

branch: polecat/organic-mjwjck2f
target: main
source_issue: organic-mjwjck2f
rig: gastown
agent_bead: gt-gastown-polecat-organic


Digest: mol-deacon-patrol

Patrol 14: quiet


Digest: mol-deacon-patrol

Patrol cycle 1: All healthy - witnesses, refineries running. No callbacks, no orphans, no pending spawns.


Digest: mol-deacon-patrol

Patrol 20: All healthy, handoff threshold reached


Merge: testcat-mjtk387i

branch: polecat/testcat-mjtk387i
target: main
source_issue: testcat-mjtk387i
rig: gastown


Digest: mol-deacon-patrol

Patrol 71: Routine


Digest: mol-deacon-patrol

Patrol cycle 36: All healthy, no incidents


File locking for concurrent access

Add file locking for concurrent access safety.

## At-Risk Files
- .gastown/swarms.json (or per-swarm state.json)
- .gastown/refinery.json
- polecats/<name>/state.json
- inbox.jsonl files

## Go File Locking
Use syscall.Flock for advisory locking:
```go
type FileLock struct {
    file *os.File
}

func AcquireLock(path string, timeout time.Duration) (*FileLock, error) {
    f, err := os.OpenFile(path+".lock", os.O_CREATE|os.O_RDWR, 0644)
    if err != nil {
        return nil, err
    }
    // Use syscall.Flock with timeout
}

func (l *FileLock) Release() error
```

## Integration Pattern
```go
func (m *Manager) saveState(ref *Refinery) error {
    lock, err := AcquireLock(m.stateFile(), 5*time.Second)
    if err != nil {
        return fmt.Errorf("could not acquire lock: %w", err)
    }
    defer lock.Release()

    // Read-modify-write cycle
}
```

## New Package
internal/filelock/
├── lock.go     # FileLock, AcquireLock
└── lock_test.go

## Apply To
- internal/refinery/manager.go: loadState/saveState
- internal/cmd/swarm.go: SwarmStore
- internal/mail/mailbox.go: Append, rewrite
- internal/polecat/manager.go: state operations

## Timeout Handling
Default 5 second timeout. Return error if lock not acquired.

## Acceptance Criteria
- [ ] Lock files created (.lock extension)
- [ ] Timeout on lock contention
- [ ] All state files protected
- [ ] Locks released on error paths


Merge: keeper-dogs

branch: polecat/keeper-dogs
target: main
source_issue: keeper-dogs
rig: gastown


Digest: mol-deacon-patrol

Patrol 15: All healthy.


Merge: furiosa-mjxlt6tk

branch: polecat/furiosa-mjxlt6tk
target: main
source_issue: furiosa-mjxlt6tk
rig: gastown
agent_bead: gt-gastown-polecat-furiosa


Merge: gt-svdsy

branch: polecat/capable-mjtltnm5
target: main
source_issue: gt-svdsy
rig: gastown


Digest: mol-deacon-patrol

Patrol 155 complete


Validate rig names to reject hyphens and special characters

GHI #23: Add validation in Manager.AddRig() to reject rig names with hyphens (and other special chars) that break agent ID parsing.

**Problem**: Agent IDs use format `<prefix>-<rig>-<role>[-<name>]` with hyphens as delimiters. Hyphenated rig names like `op-baby` cause parsing failures.

**Fix location**: internal/rig/manager.go:172 (AddRig function)

**Implementation**:
1. Add validation after RigExists check (~line 173)
2. Reject names containing: hyphens, spaces, dots
3. Suggest sanitized alternative in error message

Example:
```go
if strings.Contains(opts.Name, "-") {
    return nil, fmt.Errorf("rig name %q contains hyphens which break agent ID parsing; use %q instead",
        opts.Name, strings.ReplaceAll(opts.Name, "-", ""))
}
```

Ref: https://github.com/steveyegge/gastown/issues/23

Implemented rig name validation in Manager.AddRig()


Digest: mol-deacon-patrol

Patrol complete: checked inbox (empty), scanned health (all witnesses/refineries running), no gates, no convoys, no orphans, 1 dog idle, no plugins


Day 2.7: Bootstrap creates agent beads

Bootstrap commands must create agent beads for ZFC compliance.

## Problem
- `gt install` doesn't create Deacon/Mayor agent beads
- `gt rig add` doesn't create Witness/Refinery agent beads
- `gt doctor` doesn't verify agent beads exist
- Current beads were created manually (not reproducible)

## Impact
Patrol ignition (gt-qpoxz) depends on agent beads existing.
Without bootstrap creating them, fresh installs will fail.

## Required
1. gt install: Create gt-deacon and gt-mayor beads
2. gt rig add: Create gt-witness-<rig> and gt-refinery-<rig> beads
3. gt doctor: Add agent-beads-exist check
4. gt doctor --fix: Create missing agent beads


gt mail inbox: identity auto-detection fails for refinery

When running from ~/gt/gastown/refinery or ~/gt/gastown/refinery/rig, 'gt mail inbox' detects identity as 'mayor/' instead of 'gastown/refinery'.

Workaround: Use --identity flag explicitly:
  gt mail inbox --identity gastown/refinery

This breaks the refinery patrol because it can't see its MERGE_READY messages.

Expected: Running from gastown/refinery should auto-detect identity as gastown/refinery.

Related: The refinery has 9 unread MERGE_READY messages that aren't being processed because of this bug.

Added refinery/witness detection to detectSender()


Digest: mol-deacon-patrol

Patrol 244 complete: no incidents


Digest: mol-deacon-patrol

Patrol 20: all clear - handoff threshold reached


Digest: mol-deacon-patrol

Patrol cycle 19


MessagingConfig: Add missing test cases

Missing test coverage:
1. Version > CurrentMessagingVersion rejection
2. Malformed JSON handling


Digest: mol-deacon-patrol

Patrol 8: All clear


Digest: mol-deacon-patrol

Cycle 296: All healthy, refinery active


Restart daemon to activate Boot integration

The running daemon (PID 70670) predates Boot code. Daemon heartbeat() now calls ensureBootRunning() but the stale process never executes it.

Fix: gt shutdown --force && gt start

This is a one-time operational task, not a code change.

Daemon restarted, Boot now spawning successfully


Digest: mol-deacon-patrol

Patrol 39: all quiet


Merge: capable-1767084028536

branch: polecat/capable-1767084028536
target: main
source_issue: capable-1767084028536
rig: gastown

Conflicts with main - mrqueue package was removed. Notified capable to rebase.


Digest: mol-refinery-patrol

Patrol: Cleaned 2 stale MRs (dag unverifiable, furiosa already merged). Queue empty.


Digest: mol-deacon-patrol

Patrol 12: All healthy, beads/witness now responding


gt sling: nudge witness+refinery when dispatching to polecat

When gt sling dispatches work to a polecat, wake the rig's witness and refinery.

## Boot+Nudge Pattern

```go
// After successful polecat dispatch
func wakeRigAgents(rig string) {
    // Level 2: Start if asleep
    exec.Command("gt", "rig", "boot", rig).Run()

    // Level 1: Clear backoff if running
    t := tmux.NewTmux()
    t.NudgeSession(fmt.Sprintf("gt-%s-witness", rig), "wake")
    t.NudgeSession(fmt.Sprintf("gt-%s-refinery", rig), "wake")
}
```

## Graceful Behavior

- `gt rig boot` is idempotent (no-op if already running)
- Nudge failures are silent (session might not exist yet)
- Agents discover what happened by checking reality

## Reference

See ~/gt/docs/patrol-system-design.md (Two-Level Wake section)


Digest: mol-deacon-patrol

Patrol 13: routine


Merge: rictus-mjuic92c

branch: polecat/rictus-mjuic92c
target: main
source_issue: rictus-mjuic92c
rig: gastown
agent_bead: gt-gastown-polecat-rictus


Digest: mol-deacon-patrol

Patrol #16


Create session name helper functions in internal/session

attached_args: Session name helper functions

Create helper functions for consistent session name construction.

## Files to modify
- internal/session/names.go (NEW)

## Implementation
Create new file with these functions:
```go
package session

import "fmt"

const Prefix = "gt-"

func MayorSessionName() string { return Prefix + "mayor" }
func DeaconSessionName() string { return Prefix + "deacon" }
func WitnessSessionName(rig string) string { return fmt.Sprintf("%s%s-witness", Prefix, rig) }
func RefinerySessionName(rig string) string { return fmt.Sprintf("%s%s-refinery", Prefix, rig) }
func CrewSessionName(rig, name string) string { return fmt.Sprintf("%s%s-crew-%s", Prefix, rig, name) }
func PolecatSessionName(rig, name string) string { return fmt.Sprintf("%s%s-%s", Prefix, rig, name) }
```

## Acceptance criteria
- [ ] New file internal/session/names.go created
- [ ] All 6 helper functions implemented
- [ ] Unit tests in internal/session/names_test.go
- [ ] go build ./... passes
- [ ] go test ./internal/session/... passes


Day 1.4: Create agent beads for core roles

Create agent beads with deterministic IDs:
- gt-mayor (Mayor coordinator)
- gt-witness (per-rig polecat monitor)
- gt-refinery (per-rig merge processor)

Each with role_type, rig, and initial state.

Parent: gt-d0jqp


Digest: mol-deacon-patrol

Patrol 127: All healthy


Digest: mol-deacon-patrol

Patrol cycle 13: All healthy - Witness/Refinery running, 7 polecats monitored


Digest: mol-deacon-patrol

Patrol cycle 2: all healthy, 2 health acks


Merge: rictus-1767073382273

branch: polecat/rictus-1767073382273
target: main
source_issue: rictus-1767073382273
rig: gastown


Digest: mol-deacon-patrol

Patrol 17: All healthy


Digest: mol-deacon-patrol

Cycle 195: Nominal


Digest: mol-deacon-patrol

Cycle 292: All healthy, no incidents


Digest: mol-deacon-patrol

Patrol 99: All healthy


Digest: mol-deacon-patrol

Patrol 202: All agents healthy, 10 polecats working, 3 refineries processing. No incidents.


Digest: mol-deacon-patrol

Patrol 17: 3 rigs healthy


Digest: mol-deacon-patrol

Patrol 83: All healthy, quiet


LESSONS: Idle Polecat Incident 2026-01-02

# Incident Summary

On 2026-01-02, discovered 9 polecats (5 gastown, 4 beads) sitting idle at Claude prompts with completed work, burning money.

## Root Cause Chain

1. **Polecats completed work, submitted MRs** - correct
2. **Refinery merged work, sent MERGED to Witness** - correct
3. **Witness had 50 unread protocol messages** - BUG
4. **Witness not processing mail = no cleanup** - BUG
5. **Polecats waiting for death that never comes** - SYMPTOM

## Why Witness Wasn't Patrolling

Witness is a Claude agent with template instructions. When it finishes one patrol cycle, it stops. The template doesn't emphasize continuous operation.

Claude agents are stateless between turns - they complete a task and wait for next input. Without continuous prompting, they idle.

## Design Flaw

The current model:
```
Polecat → gt done → WAIT for Witness to kill
Witness → process mail → nuke polecat
```

**Problem**: If Witness doesn't patrol, polecats wait forever.

## Fixes Implemented

1. **gt-lynar**: `gt done --exit` - polecats self-terminate after MR submission
2. **gt-x4ad3**: Update polecat template to use --exit
3. **gt-fo9iz**: Nuke safety check - verify work on main, not just 'pushed'

## Lessons

### L1: Agents Should Self-Terminate When Done
Don't rely on external actors to clean up. If an agent finishes work, it should exit immediately. Waiting = burning money.

### L2: Mail Is Not Reliable Signaling
Claude agents may not process mail continuously. Don't design protocols that require prompt mail processing.

### L3: Safety Checks Must Match Reality
After branch merge+delete, local branch looks 'unpushed' even though work is on main. Safety checks should verify actual state (is work on main?) not proxy state (is branch pushed?).

### L4: Idle State Is A Bug
Gas Town's propulsion principle: agents are pistons that fire. Idle agents violate this. If an agent can be idle, the design is wrong.

### L5: Monitor What Matters
We had convoy status, polecat lists, etc. But no alert for 'polecat at prompt doing nothing'. Add monitoring for actual idle time.

## Future Prevention

1. Polecat template: always use `gt done --exit`
2. Witness template: emphasize continuous patrol (or replace with daemon)
3. Add `gt doctor` check: 'polecats at prompt for >N minutes'
4. Consider: Replace Witness with daemon (more reliable than Claude patrol)


Digest: mol-deacon-patrol

Patrol 2: all healthy, no events


gt done: Require pushed branch before MR creation

gt done currently creates MR bead without verifying the branch is pushed.

## Problem
Polecat can run `gt done` with unpushed commits. MR bead references a branch that doesn't exist on remote. Work is lost when polecat is nuked.

## Fix
In done.go runDone():
```go
// Before creating MR bead
status, err := g.CheckUncommittedWork()
if status.UnpushedCommits > 0 {
    return fmt.Errorf("branch has %d unpushed commits; run 'git push' first", status.UnpushedCommits)
}
```

## Already Have
- `computeCleanupStatus()` checks this but only reports, doesn't block
- Just need to make it a hard error

Fixed: Added BranchPushedToRemote check in runDone() before MR creation


Digest: mol-deacon-patrol

Patrol cycle 27: All healthy, no incidents


Digest: mol-deacon-patrol

Patrol cycle 12: All healthy - Witness monitoring 7 polecats, Refinery running, no pending work. Cleaned stale wisp gt-eph-5hp.


Digest: mol-deacon-patrol

Patrol 12: healthy


Add charmbracelet TUI dependencies (bubbletea, bubbles)

Add charmbracelet TUI framework dependencies.

## Dependencies to add
```
go get github.com/charmbracelet/bubbletea
go get github.com/charmbracelet/bubbles
```

## Already have
- github.com/charmbracelet/lipgloss (styling)

## Verify
- go mod tidy
- go build ./...

Quick task, just adding deps.


Digest: mol-deacon-patrol

Patrol 46: All healthy


Digest: mol-deacon-patrol

Patrol #20: All healthy, 3 convoys active


Digest: mol-deacon-patrol

Patrol 7: all clear


Digest: mol-deacon-patrol

Patrol complete: routine, town stable


Create StartupNudge function with seance metadata

## Location
internal/session/startup.go (new file) or internal/agent/startup.go

## Interface
```go
type StartupNudgeConfig struct {
    Recipient   string  // gastown/crew/gus, deacon, gastown/witness
    Sender      string  // mayor, deacon, self (for handoff)
    Topic       string  // mol-id, "cold-start", "handoff", "assigned"
    MolID       string  // Optional: specific molecule being worked
}

func StartupNudge(t *tmux.Tmux, session string, cfg StartupNudgeConfig) error
```

## Nudge Format
```
[GAS TOWN] gastown/crew/gus ← deacon • 2025-12-30T15:42 • assigned:gt-abc12
```

This becomes the session title in Claude Codes `/resume` picker.

## Implementation
1. Build the formatted message from config
2. Call t.NudgeSession(session, message) for reliable delivery
3. Return error if session doesnt exist or nudge fails

## Key Insight
The message content doesnt trigger GUPP - CLAUDE.md and hooks handle that.
The metadata makes sessions identifiable in `/resume`.

Created StartupNudge function in internal/session/startup.go with StartupNudgeConfig struct. Format: [GAS TOWN] recipient <- sender • timestamp • topic[:mol-id]. Tests pass.


Digest: mol-deacon-patrol

Patrol cycle 71: All healthy


stderr suppression hides critical errors

Multiple files set cmd.Stderr = nil:
- prime.go
- up.go
- orphans.go
- daemon.go

This hides git errors and command failures.

Should capture stderr for debugging and log when errors occur,
rather than suppressing entirely.

Fixed stderr suppression: prime.go (3 locations), orphans.go (1 location), patrol_helpers.go (4 locations) now capture stderr for debugging. Daemon launch cases (up.go, daemon.go, daemon_check.go) keep nil for proper detachment but have clarifying comments.


Digest: mol-deacon-patrol

Patrol 8: all clear


Digest: mol-deacon-patrol

Patrol cycle 2: All healthy. No callbacks, orphans, or gates.


Digest: mol-deacon-patrol

Patrol complete: both rigs healthy, handoff threshold reached


Human escalation: notify overseer when self-heal fails

Lightweight escalation extracted from Deacon epic (gt-5af).

**Implementation**: Config in town.json or similar:
```yaml
escalation:
  contact: steve@example.com  # or slack webhook
  triggers:
    - daemon_cant_restart
    - session_missing_5min
```

**Trigger points**:
- Go daemon can't restart a session after N attempts
- Agent detects it's stuck and can't recover
- Witness can't reach polecat

**Mechanism**:
- Simple: `gt mail send --human` already exists
- Enhanced: email/slack via external script

**Weight**: Small config + one code path in daemon
**Value**: High for unattended operation - human gets notified instead of silent failure


Merge: rictus-1767138835254

branch: polecat/rictus-1767138835254
target: main
source_issue: rictus-1767138835254
rig: gastown


Merge: nux-mjxaphp6

branch: polecat/nux-mjxaphp6
target: main
source_issue: nux-mjxaphp6
rig: gastown
agent_bead: gt-gastown-polecat-nux


Witness: must send MERGE_READY to Refinery after POLECAT_DONE

Integration test gt-7psb8 revealed that Witness processes POLECAT_DONE but doesn't send MERGE_READY to Refinery.

Observed:
- Witness receives POLECAT_DONE from furiosa
- Witness verifies branch pushed
- Witness kills polecat session
- Witness notifies Mayor
- NO MERGE_READY sent to Refinery

Expected: After successful pre-kill verification, Witness should send MERGE_READY to gastown/refinery with the MR details.


Digest: mol-deacon-patrol

Patrol 8: all healthy


Digest: mol-deacon-patrol

Patrol cycle 261: Cleaned 510+ stale wisps (57 hq, 450+ gt). All agents healthy (3 witnesses, 3 refineries, 10 polecats active). No incidents.


Digest: mol-deacon-patrol

Cycle 13


Add mutex to swarm.Manager for thread safety

attached_args: Add swarm.Manager mutex for thread safety

Fix potential race condition in swarm manager's map access.

## Files to modify
- internal/swarm/manager.go
- internal/swarm/manager_test.go (add concurrency test)

## Problem
The swarms map[string]*Swarm is accessed without synchronization:
```go
type Manager struct {
    swarms map[string]*Swarm  // No mutex protection
}
```

Multiple goroutines could call Create(), GetSwarm(), etc. simultaneously.

## Implementation
```go
type Manager struct {
    mu     sync.RWMutex
    swarms map[string]*Swarm
}

func (m *Manager) GetSwarm(id string) *Swarm {
    m.mu.RLock()
    defer m.mu.RUnlock()
    return m.swarms[id]
}
```

## Acceptance criteria
- [ ] sync.RWMutex added to Manager struct
- [ ] All map accesses protected by mutex
- [ ] RLock for reads, Lock for writes
- [ ] Concurrency test added
- [ ] go test -race ./internal/swarm/... passes


Witness/Refinery startup: Enforce patrol molecule attachment

Witness and Refinery CLAUDE.md says to:
1. Check for attached molecule on startup
2. If not attached, spawn patrol wisp

But sessions are just reacting to mail without patrol structure.

Current state:
- gt-8ynws (Witness Patrol) exists but not attached
- gt-t5i07 (Refinery Patrol) exists but not attached
- Sessions are running without structured patrol loops

Fix options:
1. Add SessionStart hook to enforce patrol attachment
2. Make 'gt start' attach patrol molecules when spawning witness/refinery
3. Add reminder in CLAUDE.md startup banner that's more emphatic

Fixed autoSpawnPatrol in patrol_helpers.go to use --status=hooked instead of --status=pinned. This ensures patrol wisps are visible to gt mol status and trigger autonomous mode.


Digest: mol-deacon-patrol

Patrol 4: All healthy


Day 2.7c: gt doctor checks agent beads exist

Add gt doctor check: agent-beads-exist

1. For town-level: verify gt-deacon and gt-mayor beads exist
2. For each rig: verify gt-witness-<rig> and gt-refinery-<rig> beads exist
3. Report missing beads as warnings
4. Implement --fix to create missing beads

Files:
- internal/doctor/agent_beads_check.go (new)
- internal/cmd/doctor.go (register check)


Digest: mol-deacon-patrol

Cycle 295: All healthy, gastown refinery 1 pending


Digest: mol-deacon-patrol

Cycle 10


Merge: rictus-1767059698035

branch: polecat/rictus-1767059698035
target: main
source_issue: rictus-1767059698035
rig: gastown

Work already merged to main - branches were never created or already deleted


Overnight Hanoi Demo: Progress monitoring for mega-molecules

Support monitoring million-step molecules for the overnight Hanoi demo.

## Context
Towers of Hanoi with 20 disks = 2^20 - 1 = 1,048,575 steps.
Current display code assumes reasonable step counts.

## Requirements
1. Progress summary command (bd mol progress)
2. Large molecule guards in display code
3. Agent-actionable formula description
4. Convoy integration for completion tracking

## Success Criteria
- Can cook and pour 20-disk Hanoi formula
- Can monitor progress without listing all steps
- Agent can resume mid-molecule with clear instructions
- Know when it is done (convoy or completion signal)

7-disk demo proved molecule system works. Large molecule creation needs optimization before overnight 20-disk run.


Add bd mol progress command for mega-molecule summary

New command that shows progress percentage, current step, rate, ETA without listing all steps.

Output format:
Molecule: gt-hanoi-xyz (Towers of Hanoi - 20 disks)
Progress: 347,892 / 1,048,575 (33.2%)
Current step: gt-hanoi-xyz.move-347893
Rate: ~1,200 steps/hour
ETA: ~9.7 hours remaining

Implementation in beads repo.

Duplicate of beads work: bd-8xnf, bd-vln0


Add display guards for large molecules

bd mol current and convoy displays need guards:
- If steps > 100, show summary instead of list
- Add --range flag for viewing specific step ranges
- Convoy panel shows count + percentage, not child list


Update Hanoi formula with agent-actionable instructions

Update towers-of-hanoi.formula.toml description to include:
- Clear execution protocol for agents
- What each step means
- What to do on resume
- Explicit DO/DO NOT guidance

Updated formula with agent-actionable instructions


Run 1K Hanoi demo (10 disks)

End-to-end test:
1. Cook 20-disk Hanoi formula
2. Pour as wisp on a polecat
3. Let it run overnight
4. Monitor with bd mol progress
5. Verify completion via convoy

7-disk demo succeeded (127 moves, 21 sec). 10-disk blocked by wisp creation timeout - needs performance optimization.


Deacon health checks too frequent - disturbs idle agents

Deacon is sending health checks to mayor every few seconds even when idle. This defeats the purpose of the patrol system - agents should NOT be disturbed when there's nothing going on.

Proposed fix:
1. Reduce health check frequency (e.g., every 60s instead of every 5s)
2. Or: Only health check agents that have active work (hooked molecules)
3. Or: Mayor shouldn't be health-checked at all since it's human-managed

The deacon should be silent/invisible when the town is healthy.

Added idle town protocol - skip health nudges when no active work, sleep 60+ seconds between cycles


Digest: mol-deacon-patrol

Patrol 9: All healthy.


Digest: mol-deacon-patrol

Patrol 246 complete: no incidents


Merge: slit-mjui7j71

branch: polecat/slit-mjui7j71
target: main
source_issue: slit-mjui7j71
rig: gastown


Digest: mol-deacon-patrol

Patrol #9: Health pinged all refineries.


Merge: rictus-mjw1g7ny

branch: polecat/rictus-mjw1g7ny
target: main
source_issue: rictus-mjw1g7ny
rig: gastown
agent_bead: gt-gastown-polecat-rictus


Merge: keeper-dogs

branch: polecat/keeper-dogs
target: main
source_issue: keeper-dogs
rig: gastown


Digest: mol-deacon-patrol

Patrol cycle 9: All healthy, 4 polecats


Merge: toast-mjxm0mmo

branch: polecat/toast-mjxm0mmo
target: main
source_issue: toast-mjxm0mmo
rig: gastown
agent_bead: gt-gastown-polecat-toast


Add NODE_OPTIONS crash logging to claude invocations

## Background

Investigation in bd-6df0 found that NODE_OPTIONS can enable Node.js crash reporting for Claude Code:

```bash
NODE_OPTIONS="--report-on-fatalerror --report-uncaught-exception --report-directory=$HOME/.claude/crash-reports"
```

## Proposal

Modify gt to set NODE_OPTIONS when spawning claude sessions. Key locations in gastown:

- `internal/cmd/up.go` - deacon, witness, crew, polecat spawning
- `internal/cmd/start.go` - refinery, crew spawning
- `internal/cmd/mayor.go` - mayor spawning
- `internal/cmd/handoff.go` - handoff respawning
- `internal/cmd/crew_helpers.go` - execClaude()
- `internal/daemon/lifecycle.go` - daemon-managed spawns

## Implementation

1. Create helper function to build NODE_OPTIONS string
2. Set env var before each claude invocation
3. Ensure ~/.claude/crash-reports/ directory exists
4. Optionally add `gt doctor` check to clean old reports

## Benefits

- Crash diagnostics without user config changes
- All gt-managed sessions automatically covered
- Reports available for debugging unexpected terminations


Test Patrol Parent

[RESURRECTED] This issue was deleted but recreated as a tombstone to preserve hierarchical structure.

Original description:
Test parent for Christmas Ornament pattern


Digest: mol-deacon-patrol

Patrol 58: All healthy


Digest: mol-deacon-patrol

Patrol cycle 63: All healthy


Parameterize 'read org docs' step in polecat workflows

## Problem

The mol-polecat-chrome formula has hardcoded paths to strategic docs:
- ~/gt/docs/hop/CONTEXT.md
- ~/gt/docs/PRIMING.md

This limits reusability across different projects/organizations.

## Solution

Add a `context_docs` variable to the formula that takes a list of document paths:

```toml
[vars.context_docs]
description = "Paths to organizational context documents to read before design"
default = ["~/gt/docs/hop/CONTEXT.md", "~/gt/docs/PRIMING.md"]
```

## Usage at cook/wisp time

```bash
# Use defaults
gt sling gt-abc gastown -q chrome

# Override for different project
gt sling gt-abc gastown -q chrome   --var context_docs="docs/ARCHITECTURE.md,docs/PRINCIPLES.md"
```

## Step template

The step description would interpolate the paths:

```toml
[[steps]]
id = "read-strategic-context"
title = "Read organizational context documents"
description = """
Read the following strategic context documents before designing:

{{#each context_docs}}
- {{this}}
{{/each}}

These contain the vision, principles, and constraints that should guide your work.
"""
```

## Considerations

1. How to handle the array in TOML var syntax?
2. Should this be a reusable step fragment or inline in chrome?
3. Default paths should work for Gas Town but be overridable

## Related
- mol-polecat-chrome.formula.toml (current hardcoded implementation)

Implemented mol-polecat-chrome formula with parameterized context_docs variable. Default paths point to Gas Town docs, can be overridden via --var context_docs="..." at sling time.


Add convoy_test.go tests

convoy.go (525 lines) has no test coverage


Digest: mol-deacon-patrol

Patrol cycle 2: All healthy. 3 rigs responding. No issues.


Consider gt polecats --status=idle for swarm dispatch

The dispatch-swarm-work step in mol-witness-patrol uses a complex jq command to find idle polecats:

```bash
bd list --type=agent --json | jq '[.[] | select(.description | contains("role_type: polecat") and contains("agent_state: idle"))]'
```

Consider adding a dedicated command:
```bash
gt polecats <rig> --status=idle
```

Benefits:
- Simpler for formula authors
- Encapsulates agent bead schema details
- Could add --json output for programmatic use

Low priority - the jq approach works, this is just ergonomics.


Witness patrol formula should document 'dead' agent state

## Problem

The witness patrol formula survey-workers step documents these agent states:

  agent_state: running|idle|stuck|done

But the daemon lifecycle (daemon/lifecycle.go:647) can set agent_state to 'dead'
when an agent goes unresponsive. This state isn't mentioned in the formula.

## Found in commit

f3a6ef6 (feat: Witness reads polecat state from agent beads)

## Suggested fix

Update the formula survey-workers step to include 'dead' in the state table:

| agent_state | Meaning | Action |
|-------------|---------|--------|
| running | Actively working | Check progress (Step 3) |
| idle | No work assigned | Skip (no action needed) |
| stuck | Self-reported stuck | Handle stuck protocol |
| done | Work complete | Verify cleanup triggered |
| dead | Marked dead by daemon | Clean up or respawn |


Digest: mol-deacon-patrol

Patrol 17: routine


Merge: dementus-mjxc9ivl

branch: polecat/dementus-mjxc9ivl
target: main
source_issue: dementus-mjxc9ivl
rig: gastown
agent_bead: gt-gastown-polecat-dementus

Branches merged, cleaning up stale MR beads


Digest: mol-deacon-patrol

Patrol cycle 33: All healthy, no incidents


Merge: rictus-1767084016819

branch: polecat/rictus-1767084016819
target: main
source_issue: rictus-1767084016819
rig: gastown


CLI: all command for batch polecat operations

Batch operations across multiple polecats.

## Commands

### gt all start
```
gt all start [--awake-only] [<specs>...]
```
Start sessions for multiple polecats.
- --awake-only: Only start awake polecats
- specs: Polecat names, rig/polecat patterns

### gt all stop
```
gt all stop [<specs>...] [--force]
```
Stop sessions for multiple polecats.

### gt all status
```
gt all status [<specs>...] [--json]
```
Show status of multiple polecats.

### gt all attach
```
gt all attach [<specs>...]
```
Attach to multiple sessions in tmux panes/windows.

### gt all run
```
gt all run <command> [<specs>...]
```
Run command in multiple polecat sessions.

## Spec Patterns
- `Toast`: Specific polecat (in default/current rig)
- `gastown/Toast`: Specific rig/polecat
- `gastown/*`: All polecats in rig
- `*`: All polecats everywhere

## Implementation
```go
func expandSpecs(specs []string, awakeOnly bool) ([]*polecat.Polecat, error) {
    // Expand patterns to list of polecats
}

func runForAll(polecats []*polecat.Polecat, action func(*polecat.Polecat) error) error {
    // Run action for each, collect errors
}
```

## New File
internal/cmd/all.go

## PGT Reference
gastown-py/src/gastown/cli/all_cmd.py

## Acceptance Criteria
- [ ] Pattern expansion works
- [ ] Parallel execution where safe
- [ ] Aggregate error reporting
- [ ] --awake-only filter works


Campaign: Large-Scale Work Graph Execution

A Campaign is a Molecule-wrapped Epic graph ready for orchestrated execution.

## Concept

Campaign = Molecule + Epics + Dependency Graph + Execution Strategy

Key properties:
1. **Work graph**: Linked epics with dependency edges (possibly from different authors)
2. **Combinators as glue**: >>, |, wrap define bridging/shaping between epics
3. **Molecule shell**: Provides execution state, persistence across sessions
4. **Witness-aware**: Can be parallelized across polecats on independent branches
5. **Single-rig scoped**: One rig executes it (spans sessions/polecats)

## The "Maximum Speed" Model

Witness becomes a scheduler that:
- Watches campaign progress
- Identifies ready nodes (all dependencies satisfied)
- Spawns/assigns polecats to ready nodes
- Respects parallelism constraints
- Handles failures (retry? skip? escalate?)

## Where Campaign Fits in MEOW

Campaign is the convergence point where work-tracking meets workflow-execution:
- An Epic-of-Epics (work dimension)
- A Molecule (workflow dimension)

## Open Questions

1. Campaign creation UX - manual wire vs declare intent?
2. Partial completion - can you commit progress and resume?
3. Distinct entity type or molecule with type="campaign"?
4. Cross-rig campaigns - can graph span multiple rigs?

## Related

- docs/formula_evolution.md - original discussion
- gt-8tmz - molecule algebra (foundation)


Digest: mol-deacon-patrol

Patrol 48: All healthy


Break up long functions in start.go

Several functions in internal/cmd/start.go exceed recommended length:
- runStart: 126 lines (129-255) - handles mayor, deacon, rig agents, crew auto-start
- runStartCrew: 155 lines (638-792) - handles crew target parsing, workspace, session
- cleanupPolecats: 91 lines (543-634) - handles polecat cleanup loop

Suggestion: Extract into focused helpers:
- runStart → startMayorAndDeacon(), startRigAgents(), startConfiguredCrew()
- runStartCrew → parseCrewTarget(), ensureCrewWorkspace(), startOrAttachCrewSession()
- cleanupPolecats → cleanupSinglePolecat()


gt convoy status: Show assignee and actual status for tracked issues

Currently convoy status shows all open issues as ○ with no distinction:

```
○ gt-27bzi: Add gt mail announces command [task]
○ gt-pn2fq: Add isAnnounceAddress() helpers [task]
○ gt-q73h3: Implement sendToAnnounce() [task]
```

But these issues have different statuses and assignees:
- gt-pn2fq: closed (immortan) - should show ✓
- gt-q73h3: hooked (bullet) - should show 🔨 or similar
- gt-27bzi: in_progress (toecutter) - should show ▶

## Proposed display

```
✓ gt-pn2fq: Add isAnnounceAddress() helpers [immortan]
▶ gt-q73h3: Implement sendToAnnounce() [bullet]
▶ gt-27bzi: Add gt mail announces command [toecutter]
```

Show actual status symbols and assignee in brackets.


Digest: mol-deacon-patrol

Patrol cycle 10


Digest: mol-deacon-patrol

Patrol 15: routine


gt done: Fails in worktrees due to missing origin tracking ref

In polecats (git worktrees), after git push -u origin <branch>, the origin/<branch> ref doesn't exist locally. This causes gt done to fail with 'unknown revision' when checking unpushed commits.

**Workaround**: After pushing, manually create the ref:
```bash
git fetch origin <branch>
git update-ref refs/remotes/origin/<branch> FETCH_HEAD
gt done
```

Root cause: Worktrees may not have the same fetch refspecs as the main repo. The tracking is set but the remote ref isn't fetched into refs/remotes/.

Fix: gt done should handle this edge case, perhaps by checking the remote directly or creating the ref after detecting the issue.

Fixed: BranchPushedToRemote now creates missing remote tracking refs from FETCH_HEAD after fetch in worktrees


Wisp squash design: cadences, rules, templates

Design how wisps squash to digests: When to squash (cadences), what to include (summary templates), retention rules. Currently under-designed. Should cover patrol wisps (squash per cycle) and work wisps (squash on completion). Consider allowing formulas to define squash templates.

Designed wisp squash system: cadences (per-cycle for patrols, on-complete for work), summary templates (structured formats, formula-defined), retention rules (30d active, 1yr archive, rollups). See docs/wisp-squash-design.md


Digest: mol-deacon-patrol

Patrol 44: All healthy


Digest: mol-deacon-patrol

Patrol #8: Refineries healthy. Beads 5 pending, gastown 1 pending.


Merge: capable-mq

branch: polecat/capable-mq-events
target: main
source_issue: capable-mq
rig: gastown


Digest: mol-deacon-patrol

Patrol cycle 32: All healthy, no incidents


Merge: gt-k1sl4

branch: polecat/dementus-mjtlqmya
target: main
source_issue: gt-k1sl4
rig: gastown


Extract interfaces for Git and Tmux to enable testing

Git and Tmux packages use concrete types that make testing difficult:

internal/git/git.go:
- Git struct with 40+ methods
- No interface - tests must use real git
- Many packages directly depend on concrete type

internal/tmux/tmux.go:
- Tmux struct with 30+ methods
- No interface - tests must use real tmux
- Contains Claude-specific detection logic mixed in

Suggestion:
1. Extract GitOperations interface with common operations
2. Extract TmuxRunner interface for subprocess operations
3. Allow mock injection for unit tests
4. Move Claude-specific tmux logic to internal/claude/


Digest: mol-deacon-patrol

Patrol 6 complete. All healthy.


Digest: mol-deacon-patrol

Patrol 17: All healthy.


Digest: mol-deacon-patrol

Patrol cycle 16: All agents healthy


Digest: mol-deacon-patrol

Patrol cycle 10: All agents healthy


Digest: mol-deacon-patrol

Patrol cycle 14: All healthy


Digest: mol-deacon-patrol

Cycle 197: Nominal


Witness: Escalate dormant polecats with unpushed work (don't auto-nuke)

Witness escalation for dormant polecats should distinguish between safe-to-nuke and needs-recovery.

## Problem
Witness detected 4 dormant polecats with unpushed commits (hq-ww5ev) but by the time Mayor processed the mail, the polecats were nuked during cleanup, losing work.

## Fix
1. Witness dormancy check should read cleanup_status from agent bead
2. If has_unpushed or has_uncommitted: mark as NEEDS_RECOVERY, escalate
3. If clean: safe to nuke
4. NEVER auto-nuke polecats with unpushed work

## Escalation Format
Subject: RECOVERY_NEEDED <polecat>
Body includes: unpushed commit SHAs, branch name, issue ID

Implemented recovery escalation for dormant polecats with unpushed work


Digest: mol-deacon-patrol

Patrol 1: All 3 rigs healthy, 12 polecats active, no zombies, no orphans, inbox clear


Digest: mol-deacon-patrol

Patrol 42: All healthy, 6 agents pinged, no incidents


Merge: rictus-mjuic92c

branch: polecat/rictus-mjuic92c
target: main
source_issue: rictus-mjuic92c
rig: gastown


Digest: mol-deacon-patrol

Patrol 2: All healthy. 3 rigs, 6 agents. No incidents.


Modified mol-deacon-patrol.formula.toml to make health check nudges conditional - only sent when concerning signals detected (agent not running, status check fails, queue stuck). Previously nudges were sent every 1-2 minute patrol cycle.


Merge: dementus-mjw062kt

branch: polecat/dementus-mjw062kt
target: main
source_issue: dementus-mjw062kt
rig: gastown
agent_bead: gt-gastown-polecat-dementus


Merge: organic-1767106082951

branch: polecat/organic-1767106082951
target: main
source_issue: organic-1767106082951
rig: gastown


Digest: mol-deacon-patrol

Patrol 155: All healthy


Merge: capable-mjxb80jf

branch: polecat/capable-mjxb80jf
target: main
source_issue: capable-mjxb80jf
rig: gastown
agent_bead: gt-gastown-polecat-capable


Implement announce:name address type for bulletin-board messaging

Add support for announce:name addresses for read-only bulletin boards.

SEMANTICS:
- Messages to announce:name create ONE copy in shared location
- All eligible readers can read (no claiming, no removal)
- Messages retained up to retain_count, oldest pruned
- No inbox pollution - readers check the announce channel explicitly

USE CASE:
Low urgency broadcast that does not need ack, e.g. clean up your branches.

IMPLEMENTATION:
1. Add isAnnounceAddress() / parseAnnounceName() helpers
2. Add sendToAnnounce() - creates message in announce location
3. Add gt mail announces - list available announce channels
4. Add gt mail read-announce <channel> - read messages from channel
5. Add retention pruning on new message

CONFIG (already in messaging.json schema):
announces.alerts.readers = [@town]
announces.alerts.retain_count = 100


Crew worker fang in gastown - human-managed persistent workspace.

role_type: crew
rig: gastown
agent_state: idle
hook_bead: null
role_bead: gt-crew-gastown-fang-role
cleanup_status: null

Migrated to canonical naming: gt-gastown-crew-<name>


Crew worker grip in gastown - human-managed persistent workspace.

role_type: crew
rig: gastown
agent_state: idle
hook_bead: null
role_bead: gt-crew-gastown-grip-role
cleanup_status: null


Crew worker jack in gastown - human-managed persistent workspace.

role_type: crew
rig: gastown
agent_state: running
hook_bead: null
role_bead: gt-crew-gastown-jack-role


gt-crew-gastown-joe

gt-crew-gastown-joe

role_type:
rig: null
agent_state: running
hook_bead: null
role_bead: null
cleanup_status: null


gt-crew-gastown-max

gt-crew-gastown-max

role_type: crew
rig: gastown
agent_state: running
hook_bead: null
role_bead: gt-crew-gastown-max-role
cleanup_status: null


Crew worker wolf in gastown - human-managed persistent workspace.

role_type: crew
rig: gastown
agent_state: idle
hook_bead: null
role_bead: gt-crew-gastown-wolf-role
cleanup_status: null


Crew Role Definition

You are a Crew Worker - a human-managed persistent workspace within a rig.

Unlike polecats which are witness-managed and transient, crew workers are:
- Persistent: Not auto-garbage-collected
- User-managed: Overseer controls lifecycle
- Long-lived identities: Keep your name across sessions
- Gas Town integrated: Mail, handoff mechanics work

session_pattern: gt-{rig}-crew-{name}
work_dir_pattern: {town}/{rig}/crew/{name}
needs_pre_sync: true
start_command: exec claude --dangerously-skip-permissions

default_molecule: null
capabilities:
  - autonomous_work
  - beads_access
  - git_operations
  - mail_communication

## Core Responsibilities

1. Execute assigned work autonomously
2. Track progress via beads (bd commands)
3. Communicate via mail when blocked or complete
4. Maintain clean git state
5. Hand off context when cycling sessions

## Propulsion Principle

If you find something on your hook, YOU RUN IT.

Hook has work then Run it. Hook empty then Check mail. Nothing then Wait for overseer.

## Session End Protocol

- git status, git add, bd sync, git commit, git push
- gt handoff - hand off to fresh session

## Key Commands

- gt mol status - Check your hook
- bd ready - Find next step
- bd close <id> - Mark work complete
- gt mail inbox - Check messages
- gt handoff - Cycle to fresh session


Digest: mol-deacon-patrol

Patrol 1: all agents healthy, no callbacks, clone divergence detected (zoey 52 behind)


Errant redirect file in .beads/ causes chain warnings

A redirect file appeared in gastown/mayor/rig/.beads/ alongside the actual beads.db, causing 'redirect chains not allowed' warnings. The redirect pointed to ../../mayor/rig/.beads which is circular. Had to manually delete the redirect file.

Fixed: Added circular redirect detection to ResolveBeadsDir (auto-removes errant redirects) and added safety checks to ensureBeadsRedirect to prevent creating redirects in canonical beads location


Digest: mol-deacon-patrol

Patrol 6: routine


Digest: mol-deacon-patrol

Patrol 1: 3 rigs healthy, no incidents


Digest: mol-deacon-patrol

Patrol cycle 54: All healthy


Merge: gt-84ery

branch: polecat/dementus-mjtlqmya
target: main
source_issue: gt-84ery
rig: gastown


Digest: mol-deacon-patrol

Patrol cycle 56: All healthy