Investigate incremental blocked_issues_cache updates at scale

Current blocked_issues_cache strategy does full DELETE + INSERT on every dependency/status change.

**Problem at scale:**
- 10K issues: ~50ms rebuild (acceptable)
- 100K issues: ~500ms rebuild (noticeable)
- 1M issues: multi-second rebuilds (problematic)

**Current implementation (blocked_cache.go:104-154):**
- DELETE FROM blocked_issues_cache
- INSERT with recursive CTE

**Potential optimizations:**
1. **Incremental updates:** Only add/remove affected issue IDs instead of full rebuild
2. **Dirty tracking:** Skip rebuild if cache is already valid
3. **Async rebuild:** Rebuild in background, serve stale cache briefly
4. **Partial invalidation:** Only invalidate affected subtree

**Decision needed:** Is this premature optimization? Current target is <100K issues.

**Benchmark:** Add benchmark for cache rebuild at 100K scale to measure actual impact.

## Benchmark Investigation Results (2026-01-02)

**Cache rebuild timing:**
- 10K issues: 773ms (Go benchmark), ~270ms (raw SQL)
- 20K issues: 1,298ms
- Extrapolated 100K: ~6.5 seconds

Original estimates were 15x too optimistic. Go/CGO/WAL adds ~3x overhead.

**Key insight:** Most dependency changes only affect a localized subgraph. Incremental updates could reduce 773ms to <50ms for typical ops.

**Added:** BenchmarkRebuildBlockedCache_Large/XLarge in sqlite_bench_test.go

## Incremental Update Design Sketch

**When to update cache:**
1. Add blocks dep → add blocked issue + descendants to cache
2. Remove blocks dep → check if still blocked, remove if not + propagate to descendants
3. Close issue → check dependents, remove unblocked + descendants
4. Reopen issue → add dependents + descendants back

**Key insight:** Adding to cache is simple (just insert). Removing is complex (must verify no alternate blocking path).

**Proposed approach:**
- For additions: \`INSERT OR IGNORE\` the affected subgraph (fast, O(affected_nodes))
- For removals: Rebuild only for the affected subgraph, not entire cache
- Keep full rebuild as fallback for complex cases (waits-for, conditional-blocks)

**Estimated improvement:**
- Typical add/remove: O(affected_nodes) vs O(all_issues)
- 10K DB with 1 affected node: ~5ms vs 773ms (150x faster)
- Worst case (unblock entire graph): same as now

**Implementation complexity:** Medium - need to handle transitive parent-child correctly


Add defensive fix in importer to auto-correct status when deleted_at present

Similar to the existing defensive fix for closed_at (lines 260-267 in multirepo.go), add a fix for the reverse case:

If an issue has deleted_at set but status != tombstone, auto-correct status to tombstone during import.

This handles corrupted data gracefully instead of failing import.

Existing pattern in `upsertIssueInTx`:
```go
// Defensive fix for deleted_at invariant: tombstones must have deleted_at
if issue.Status == types.StatusTombstone && issue.DeletedAt == nil {
    maxTime := issue.CreatedAt
    if issue.UpdatedAt.After(maxTime) {
        maxTime = issue.UpdatedAt
    }
    deletedAt := maxTime.Add(time.Second)
    issue.DeletedAt = &deletedAt
}
```

Need to add the reverse:
```go
// Defensive fix: if deleted_at is set, status must be tombstone
if issue.Status != types.StatusTombstone && issue.DeletedAt != nil {
    issue.Status = types.StatusTombstone
}
```


Test dependency child


Run bd doctor at end of bd init to verify setup

Run bd doctor diagnostics at end of bd init (after line 398 in init.go). If issues found, warn user immediately: '⚠ Setup incomplete. Run bd doctor --fix to complete setup.' Catches configuration problems before user encounters them in normal workflow.


Session ended: gt-beads-refinery


Support wisps in nodb mode for lightweight Gas Town rigs

Enable proper wisp support in --no-db mode to allow lightweight Gas Town rigs (including HQ/Mayor) to run without SQLite overhead.

## Motivation
Gas Town HQ and simple rigs could benefit from nodb mode's simplicity. Currently wisps don't work properly in nodb mode.

## Proposed Design

### Phase 1: Session-scoped wisps
- Memory storage already has Wisp field on Issue
- Wisps exist only for the session lifetime
- Acceptable for patrol cycles that complete within a session
- Depends on: bd-9avq (fix the leak)

### Phase 2: Optional wisp persistence
- Add `.beads/wisps.jsonl` for wisp storage (gitignored)
- Load wisps from this file on nodb startup
- Save wisps to this file on nodb exit
- Wisps persist across restarts but don't sync via git

### Phase 3: Verify mol commands
- Test mol squash, burn, bond work with memory storage
- These currently check for SQLite storage type
- May need interface-based approach instead of type assertions

## Files affected
- cmd/bd/nodb.go - wisp filtering and optional persistence
- internal/storage/memory/ - verify wisp field handling
- cmd/bd/mol_*.go - verify memory storage compatibility
- .beads/.gitignore - add wisps.jsonl


Session ended: gt-beads-crew-fang


Digest: mol-deacon-patrol

Cycle 19: Quiet


Digest: mol-deacon-patrol

Patrol 5: Nominal


Digest: mol-deacon-patrol

Patrol 16: healthy


Digest: mol-deacon-patrol

Patrol 61: All agents healthy, 3 convoys active (Hanoi, Boot+Polish, Messaging), 1 polecat (nux) working. No incidents.


Digest: mol-deacon-patrol

Patrol 8: healthy, noted mayor mail


Digest: mol-deacon-patrol

Patrol 16: Clean


Digest: mol-deacon-patrol

Patrol 2: All healthy, no incidents


Digest: mol-deacon-patrol

Patrol 19: all healthy


Digest: mol-deacon-patrol

Patrol 1: Nominal. Cleaned gt-boot orphan, wyvern/refinery at 2/3 health failures


Bootstrap Gas Town

Complete setup of a new Gas Town installation.

Run this after installing gt and bd via Homebrew. This molecule guides you through
creating an HQ, setting up rigs, and configuring your environment.

## Step: locate-hq
Determine where to install the Gas Town HQ.

Ask the user for their preferred location. Common choices:
- ~/gt (recommended - short, easy to type)
- ~/gastown
- ~/workspace/gt

Validate the path:
- Must not already exist (or be empty)
- Parent directory must be writable
- Avoid paths with spaces

Store the chosen path for subsequent steps.

## Step: create-hq
Create the HQ directory structure.

```bash
mkdir -p {{hq_path}}
cd {{hq_path}}
gt install . --name {{hq_name}}
```

If the user wants to track the HQ in git:
```bash
gt git-init --github={{github_repo}} --private
```

The HQ now has:
- mayor/ directory
- .beads/ for town-level tracking
- CLAUDE.md for mayor context

Needs: locate-hq

## Step: setup-rigs
Configure which rigs to add to the HQ.

Default rigs for Gas Town development:
- gastown (git@github.com:steveyegge/gastown.git)
- beads (git@github.com:steveyegge/beads.git)

For each rig, run:
```bash
gt rig add <name> <git-url> --prefix <prefix>
```

This creates the full rig structure:
- refinery/rig/ (canonical main clone)
- mayor/rig/ (mayor's working clone)
- crew/main/ (default human workspace)
- witness/ (polecat monitor)
- polecats/ (worker directory)

Needs: create-hq

## Step: build-gt
Build the gt binary from source.

```bash
cd {{hq_path}}/gastown/mayor/rig
go build -o gt ./cmd/gt
```

Verify the build succeeded:
```bash
./gt version
```

Needs: setup-rigs
Tier: haiku

## Step: install-paths
Install gt to a location in PATH.

Check if ~/bin or ~/.local/bin is in PATH:
```bash
echo $PATH | tr ':' '\n' | grep -E '(~/bin|~/.local/bin|/home/.*/bin)'
```

Copy the binary:
```bash
mkdir -p ~/bin
cp {{hq_path}}/gastown/mayor/rig/gt ~/bin/gt
```

If ~/bin is not in PATH, add to shell config:
```bash
echo 'export PATH="$HOME/bin:$PATH"' >> ~/.zshrc
# or ~/.bashrc for bash users
```

Verify:
```bash
which gt
gt version
```

Needs: build-gt
Tier: haiku

## Step: init-beads
Initialize beads databases in all clones.

For each rig's mayor clone:
```bash
cd {{hq_path}}/<rig>/mayor/rig
bd init --prefix <rig-prefix>
```

For the town-level beads:
```bash
cd {{hq_path}}
bd init --prefix hq
```

Configure sync-branch for multi-clone setups:
```bash
echo "sync-branch: beads-sync" >> .beads/config.yaml
```

Needs: setup-rigs
Tier: haiku

## Step: sync-beads
Sync beads from remotes and fix any issues.

For each initialized beads database:
```bash
bd sync
bd doctor --fix
```

This imports existing issues from JSONL and sets up git hooks.

Needs: init-beads
Tier: haiku

## Step: verify
Verify the installation is complete and working.

Run health checks:
```bash
gt status          # Should show rigs with crew/refinery/mayor
gt doctor          # Check for issues
bd list            # Should show issues from synced beads
```

Test spawning capability (dry run):
```bash
gt spawn --help
```

Print summary:
- HQ location
- Installed rigs
- gt version
- bd version

Needs: sync-beads, install-paths


Digest: mol-deacon-patrol

Patrol 19: All healthy


Digest: mol-deacon-patrol

Patrol 65: All healthy


Digest: mol-deacon-patrol

Patrol cycle 15: all healthy, fixed 1 orphan


POLECAT_STARTED Splitter

Issue: bd-rgyd
Session: gt-beads-Splitter


Digest: mol-deacon-patrol

Patrol 12: Auto


Digest: mol-deacon-patrol

Patrol 6: Quiet


Digest: mol-deacon-patrol

Patrol cycle 2: All healthy, no issues


Digest: mol-deacon-patrol

Patrol 18


Digest: mol-deacon-patrol

Patrol cycle 15: all healthy


Digest: mol-deacon-patrol

Patrol 7: all clear


Digest: mol-deacon-patrol

Patrol 5: Routine


Digest: mol-deacon-patrol

Patrol 9: routine, all healthy


Digest: mol-deacon-patrol

Patrol 15: routine


Digest: mol-deacon-patrol

Patrol 12: routine


🤝 HANDOFF: Christmas Launch Status

## Current State

### System Status (pre-reboot)
- Deacon: Running (PID 25400)
- Witness gastown: Running, monitoring 6 polecats
- Refinery gastown: Running but NOT processing MQ (0 merged)
- Polecats: 6 working (ace, furiosa, morsov, nux, rictus, slit)
- MQ: 12 items ready but not draining - investigate after reboot

### Christmas Launch Progress
- Phase 0: ✅ Complete
- Phase 1: In progress
  - gt-8v8: ✅ Done
  - **gt-9nf**: NEXT - Make gt spawn create fresh worktrees (no reuse)
  - gt-975: Blocked on Beads (bd mol bond)

### Issue to Investigate
MQ has 12 ready items but refinery shows 0 pending/merged. Queue not draining.
Check refinery logs after reboot.

### Key Files
- See gt-ngpz for full Christmas plan
- Dave working on molecule operators in Beads

### After Reboot
1. gt status - verify components came back
2. gt refinery status gastown - check if processing
3. bd show gt-9nf - continue Phase 1 work


Digest: mol-deacon-patrol

Patrol 16: All healthy


Digest: mol-deacon-patrol

Patrol cycle 10: all healthy, mayor now hq-mayor (fixed), beads 8 pending


Digest: mol-deacon-patrol

## Molecule Execution Summary

**Molecule**: mol-deacon-patrol
**Steps**: 9

**Completed**: 9/9

---

### Steps

1. **[closed]** Handle callbacks from agents
   Handle callbacks from agents.

Check the Mayor's inbox for messages from:
- Witnesses reporting polecat status
- Refineries reporting merge results
- Polecats requesting help or escalation
- External ...

2. **[closed]** Burn and respawn or loop
   Burn and let daemon respawn, or exit if context high.

Decision point at end of patrol cycle:

If context is LOW:
- Sleep briefly (avoid tight loop)
- Return to inbox-check step

If context is HIGH:
-...

3. **[closed]** Execute registered plugins
   Execute registered plugins.

Scan ~/gt/plugins/ for plugin directories. Each plugin has a plugin.md with YAML frontmatter defining its gate (when to run) and instructions (what to do).

See docs/deaco...

4. **[closed]** Nudge newly spawned polecats
   Nudge newly spawned polecats that are ready for input.

When polecats are spawned, their Claude session takes 10-20 seconds to initialize. The spawn command returns immediately without waiting. This s...

5. **[closed]** Clean dead sessions
   Clean dead sessions and orphaned state.

Run `gt doctor -v` to check for issues, then `gt doctor --fix` to clean up.

**⚠ CRITICAL: The Deacon NEVER kills crew workers or polecats!**

The orphan-...

6. **[closed]** Evaluate pending async gates
   Evaluate pending async gates.

Gates are async coordination primitives that block until conditions are met.
The Deacon is responsible for monitoring gates and closing them when ready.

**Timer gates**...

7. **[closed]** Check own context limit
   Check own context limit.

The Deacon runs in a Claude session with finite context. Check if approaching the limit:

```bash
gt context --usage
```

If context is high (>80%), prepare for handoff:
- Su...

8. **[closed]** Find abandoned work
   Find abandoned work.

Scan for orphaned state:
- Issues marked in_progress with no active polecat
- Polecats that stopped responding mid-work
- Merge queue entries with no polecat owner
- Wisp session...

9. **[closed]** Check Witness and Refinery health
   Check Witness and Refinery health for each rig.

**ZFC Principle**: You (Claude) make the judgment call about what is "stuck" or "unresponsive" - there are no hardcoded thresholds in Go. Read the sign...


Digest: mol-deacon-patrol

Patrol 10: checkpoint, 22 running, warboy long spawn


Digest: mol-deacon-patrol

Patrol 91: all healthy


Digest: mol-deacon-patrol

Patrol 45: All healthy


Digest: mol-deacon-patrol

Patrol 12: All healthy


POLECAT_STARTED dementus

Issue: gt-qz2l
Session: gt-gastown-dementus


Digest: mol-deacon-patrol

Patrol 1: All witnesses/refineries healthy, 2 convoys active, no orphans


Digest: mol-deacon-patrol

Patrol 11: rig config lost, agents running, handoff


Digest: mol-deacon-patrol

Patrol 2: quiet cycle, all healthy


Digest: mol-deacon-patrol

Patrol 3: all healthy


Digest: mol-deacon-patrol

Patrol cycle 11: quiet


Digest: mol-deacon-patrol

Patrol 10: routine, all healthy


Digest: mol-deacon-patrol

Patrol 18: all healthy


Digest: mol-deacon-patrol

Patrol 16: routine


📋 Work Assignment: Refactor long SQLite test files

Issue: bd-4opy
Title: Refactor long SQLite test files
Priority: P2
Type: task

Description:
The SQLite test files have grown unwieldy. Review and refactor.

## Goals
- Break up large test files into focused modules
- Improve test organization by feature area
- Reduce test duplication
- Make tests easier to maintain and extend

## Areas to Review
- main_test.go (likely the largest)
- Any test files over 500 lines
- Shared test fixtures and helpers
- Test coverage gaps

## Approach
- Group tests by feature (CRUD, sync, queries, transactions)
- Extract common fixtures to test helpers
- Consider table-driven tests where appropriate
- Ensure each test file has clear focus

## Reference
See docs/dev-notes/ for any existing test audit notes

## Workflow
1. Run `gt prime` to load polecat context
2. Work on your task, commit changes regularly
3. Run `bd close <issue-id>` when done
4. Run `bd sync` to push beads changes
5. Push code: `git push origin HEAD`
6. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


POLECAT_STARTED nux

Issue: gt-vmk7
Session: gt-gastown-nux


Digest: mol-deacon-patrol

Patrol cycle 19: Nominal


Session ended: gt-mayor


Digest: mol-deacon-patrol

Patrol complete: All agents healthy, no orphans, no abandoned work


Digest: mol-deacon-patrol

Patrol 15


Digest: mol-deacon-patrol

Patrol 178: All healthy


Test: crew to mayor

Testing crew->mayor mail


TestIntegration fails due to db out of sync

dispatched_by: mayor

The beads integration test (TestIntegration in internal/beads/beads_test.go) fails due to database being out of sync with JSONL. This is an environmental issue - the test requires bd daemon or sync to work. Pre-existing issue found during refinery patrol.


Digest: mol-deacon-patrol

Patrol #16: All healthy.


Digest: mol-deacon-patrol

Patrol 5: 22 running, nominal


📋 Work Assignment: mol-polecat-lease: Semaphore proto for tracking polecat lifecycle

Issue: gt-cp2s
Title: mol-polecat-lease: Semaphore proto for tracking polecat lifecycle
Priority: P1
Type: task

Description:
Define a small proto for tracking a single polecat in the Witness patrol wisp:

```markdown
## Molecule: polecat-lease
Semaphore tracking a single polecat's lifecycle.
Vars: {{polecat}}, {{issue}}

## Step: boot
Spawned. Verify it starts working.
gt peek {{polecat}} - if idle, gt nudge.
Timeout: 60s before escalation.

## Step: working
Actively working. Monitor for stuck.
Wait for SHUTDOWN mail.
Needs: boot

## Step: done
Exit received. Ready for cleanup.
Kill session, prune worktree.
Needs: working
```

Used by Witness: bd mol bond mol-polecat-lease wisp-patrol --var polecat=X

## Workflow
1. Run `gt prime` to load polecat context
2. Work on your task, commit changes regularly
3. Run `bd close <issue-id>` when done
4. Run `bd sync` to push beads changes
5. Push code: `git push origin HEAD`
6. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 12: Healthy


Digest: mol-deacon-patrol

Patrol 9: all healthy


Digest: mol-deacon-patrol

Patrol 11


Digest: mol-deacon-patrol

Cycle 8: Quiet


Digest: mol-deacon-patrol

Patrol #16: routine


Digest: mol-deacon-patrol

C117: All healthy


Digest: mol-deacon-patrol

Patrol cycle 20: All healthy - handoff threshold


Digest: mol-deacon-patrol

Patrol cycle 20: final cycle before handoff, all healthy


Digest: mol-deacon-patrol

Patrol 5: All healthy


Digest: mol-deacon-patrol

Patrol cycle 4: All healthy


Digest: mol-deacon-patrol

Patrol 18: All clear


Digest: mol-deacon-patrol

Patrol cycle 7: Nominal


Digest: mol-deacon-patrol

Patrol 19 complete: all healthy


Digest: mol-deacon-patrol

Patrol 9: All healthy


Digest: mol-deacon-patrol

Patrol cycle 5: All healthy


Digest: mol-deacon-patrol

Patrol cycle 1: Burned 234 stale wisps, all 3 rigs healthy, cleaned 1 orphan session


Digest: mol-deacon-patrol

Patrol 33: All healthy


Digest: mol-deacon-patrol

Patrol 13: All healthy


Digest: mol-deacon-patrol

Patrol cycle 2: All agents healthy, no activity


Digest: mol-deacon-patrol

Patrol #9: routine


Digest: mol-deacon-patrol

Patrol 89: All healthy


Digest: mol-deacon-patrol

Patrol 14: all clear


🤝 HANDOFF: Code review mol bond

## Session Summary

Completed:
- Fixed gt mail inbox identity mismatch (hq-0ol)
- Implemented bd mol bond command (bd-o91r)

Next: Code review mol.go bond implementation
- Review runMolBond polymorphic dispatch
- Check bondProtoProto, bondProtoMol, bondMolMol
- File beads for any issues found

Remaining P2 (bd-o5xe): bd-iq19, bd-iw4z, bd-obep


🤝 HANDOFF: Phase 1 done + sling→hook refactor needed

Completed: Phase 1 Slinging Handoff (gt-qvn7.1). Code reviewed and fixed. NEW: gt-z4bw refactors gt sling into gt hook (durability) + gt handoff <bead> (hook+restart). The sling verb is too casual for session death. See bead for design notes.


Digest: mol-deacon-patrol

Patrol 2: all healthy, quiet town


📋 Work Assignment: Doctor check: Zombie session cleanup

Issue: gt-17r
Title: Doctor check: Zombie session cleanup
Priority: P1
Type: task

Description:
Detect and clean up zombie tmux sessions via gt doctor.

## Problem

Zombie sessions occur when:
- Agent crashes without cleanup
- gt kill fails mid-operation
- System restart leaves orphan sessions
- Session naming collision

## Checks

### ZombieSessionCheck
- List all tmux sessions matching gt-* pattern
- Cross-reference with known polecats
- Flag sessions with no corresponding polecat state
- Flag sessions for removed polecats
- Check session age vs polecat creation time

### Detection Criteria
- Session exists but polecat directory doesn't
- Session name doesn't match any registered polecat
- Polecat state=idle but session running
- Multiple sessions for same polecat

## Output

```
[WARN] Zombie tmux sessions detected:
  - gt-wyvern-OldPolecat (polecat removed)
  - gt-beads-Unknown (no matching polecat)
  - gt-wyvern-Toast (duplicate session)

  Run 'gt doctor --fix' to clean up
```

## Auto-Fix (--fix flag)

- Kill orphan tmux sessions
- Update polecat state to match reality
- Log all cleanup actions

## Safety

- Never kill sessions where polecat state=working
- Prompt before killing if --fix used without --force
- Create audit log of killed sessions

## Workflow
1. Run `gt prime` to load polecat context
2. Work on your task, commit changes regularly
3. Run `bd close <issue-id>` when done
4. Run `bd sync` to push beads changes
5. Push code: `git push origin HEAD`
6. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


POLECAT_STARTED beads/Gater

Issue: bd-likt
Session: gt-beads-Gater


Digest: mol-deacon-patrol

Patrol 18: all healthy


Digest: mol-deacon-patrol

Patrol 76: All healthy. No incidents.


Session ended: gt-gastown-crew-george


Migrate orphaned issues from rig-level beads to clone beads

## Context

The two-level beads architecture fix (hq-5k5) stopped routing to rig-level beads.
But ~/gt/gastown/.beads/ has 95 gt-* issues that may include orphans not in clone beads.

## The Problem

Three beads locations existed:
- Town: ~/gt/.beads/ (hq-*, mail) ✓ KEEP
- Rig: ~/gt/gastown/.beads/ (gitignored, 95 gt-* issues) ✗ ORPHANED
- Clone: ~/gt/gastown/crew/max/.beads/ (422 gt-* issues, syncs via beads-sync) ✓ KEEP

The rig-level was never supposed to have its own issues - it should have been
a symlink or not exist. But work happened there and now we have orphaned data.

## Task

1. **Export rig-level issues**
   ```bash
   cd ~/gt/gastown/.beads
   cp issues.jsonl /tmp/rig-level-issues.jsonl
   ```

2. **Compare with clone beads**
   - Get list of issue IDs from rig-level
   - Get list of issue IDs from clone beads
   - Find orphans (in rig but not in clone)

   ```bash
   # Extract IDs from rig-level
   jq -r '.id' /tmp/rig-level-issues.jsonl | sort > /tmp/rig-ids.txt

   # Extract IDs from clone
   jq -r '.id' ~/gt/gastown/crew/max/.beads/issues.jsonl | sort > /tmp/clone-ids.txt

   # Find orphans
   comm -23 /tmp/rig-ids.txt /tmp/clone-ids.txt > /tmp/orphan-ids.txt
   ```

3. **Review orphans**
   - How many? What types? What status?
   - Are any still relevant (open, in_progress)?
   - Are any just stale copies?

4. **Import relevant orphans to clone beads**
   For each relevant orphan:
   ```bash
   # Extract the issue
   grep '"id":"<orphan-id>"' /tmp/rig-level-issues.jsonl > /tmp/import.jsonl

   # Import to clone beads
   cd ~/gt/gastown/crew/max
   bd import /tmp/import.jsonl
   ```

5. **Document findings**
   Report back:
   - Total orphans found
   - How many imported vs discarded
   - Any issues encountered

## After Completion

Once confirmed that clone beads has all needed data:
- The rig-level beads can be deleted (it's gitignored anyway)
- Update any docs that reference three-level architecture

## Files

- Rig-level: ~/gt/gastown/.beads/issues.jsonl
- Clone: ~/gt/gastown/crew/max/.beads/issues.jsonl

Analyzed. 87 orphans found, 22 are work assignments (stale), 48 are open/in_progress but many superseded. Exported to /tmp/orphan-issues.jsonl. Recommend manual review before import.


Digest: mol-deacon-patrol

Patrol 6: all clear


Digest: mol-deacon-patrol

Patrol cycle 4: Routine


POLECAT_DONE dementus

Exit: COMPLETED
Issue: gt-qz2l
MR: gt-40k6
Branch: polecat/dementus


Digest: mol-deacon-patrol

Patrol 17: routine, all healthy


Digest: mol-deacon-patrol

Patrol 25: healthy


POLECAT_STARTED beads/morsov

Issue: bd-3sz0
Session: gt-beads-morsov


Digest: mol-deacon-patrol

Patrol 16: Healthy


📋 Work Assignment: bd doctor should recommend bd prime migration for existing repos

Issue: bd-0fvq
Title: bd doctor should recommend bd prime migration for existing repos
Priority: P2
Type: feature

Description:
bd doctor should detect old beads integration patterns and recommend migrating to bd prime approach.

## Current behavior
- bd doctor checks if Claude hooks are installed globally
- Doesn't check project-level integration (AGENTS.md, CLAUDE.md)
- Doesn't recommend migration for repos using old patterns

## Desired behavior
bd doctor should detect and suggest:

1. **Old slash command pattern detected**
   - Check for /beads:* references in AGENTS.md, CLAUDE.md
   - Suggest: These slash commands are deprecated, use bd prime hooks instead

2. **No agent documentation**
   - Check if AGENTS.md or CLAUDE.md exists
   - Suggest: Run 'bd onboard' or 'bd setup claude' to document workflow

3. **Old MCP-only pattern**
   - Check for instructions to use MCP tools but no bd prime hooks
   - Suggest: Add bd prime hooks for better token efficiency

4. **Migration path**
   - Show: 'Run bd setup claude to add SessionStart/PreCompact hooks'
   - Show: 'Update AGENTS.md to reference bd prime instead of slash commands'

## Example output

⚠ Warning: Old beads integration detected in CLAUDE.md
  Found: /beads:* slash command references (deprecated)
  Recommend: Migrate to bd prime hooks for better token efficiency
  Fix: Run 'bd setup claude' and update CLAUDE.md

💡 Tip: bd prime + hooks reduces token usage by 80-99% vs slash commands
  MCP mode: ~50 tokens vs ~10.5k for full MCP scan
  CLI mode: ~1-2k tokens with automatic context recovery

## Benefits
- Helps existing repos adopt new best practices
- Clear migration path for users
- Better token efficiency messaging

## Workflow
1. Run `gt prime` to load polecat context
2. Work on your task, commit changes regularly
3. Run `bd close <issue-id>` when done
4. Run `bd sync` to push beads changes
5. Run `gt done` to signal completion (branch stays local)

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 12


Digest: mol-deacon-patrol

Patrol 11: routine


Digest: mol-deacon-patrol

Patrol 1: All healthy, no incidents


Test: crew to refinery

Testing crew->refinery mail


Digest: mol-deacon-patrol

Patrol 17: routine


Digest: mol-deacon-patrol

Patrol cycle 8: All healthy


Digest: mol-deacon-patrol

Patrol 2: Routine, no incidents


Digest: mol-deacon-patrol

Cycle 26: Routine, all healthy, no orphans


Digest: mol-deacon-patrol

Patrol cycle 7: all quiet


Digest: mol-deacon-patrol

Patrol cycle 14: All healthy.


gt mail inbox misses messages due to identity format mismatch

## Bug

When sender uses short address format (e.g., beads/dave), messages are stored with assignee beads-dave.

When recipient checks inbox with full crew path (beads/crew/dave), it looks for beads-crew-dave.

Result: messages never appear in inbox.

## Root Cause

addressToIdentity() converts:
- beads/dave → beads-dave
- beads/crew/dave → beads-crew-dave

These should resolve to the same identity.

## Fix Options

1. **Normalize crew addresses on send**: beads/dave → beads/crew/dave → beads-crew-dave
2. **Simplify crew identities**: beads/crew/dave → beads-dave (strip 'crew/')
3. **Fuzzy inbox lookup**: Try multiple identity formats when querying

Option 2 is cleanest - crew workers should have simple identities like beads-dave.

## Files
- gastown/mayor/rig/internal/mail/types.go:287 (addressToIdentity)
- gastown/mayor/rig/internal/mail/mailbox.go:87 (listBeads)


Digest: mol-deacon-patrol

Patrol 18: routine


Digest: mol-deacon-patrol

Patrol 20: Final cycle, all healthy, handoff


Digest: mol-deacon-patrol

Patrol 16


Digest: mol-deacon-patrol

Patrol 4: Routine


Digest: mol-deacon-patrol

Patrol 18: All healthy


POLECAT_STARTED Pinner

Issue: bd-phtv
Session: gt-beads-Pinner


Digest: mol-deacon-patrol

Patrol 12: Routine


Digest: mol-deacon-patrol

Patrol cycle 12: routine


Digest: mol-deacon-patrol

Patrol cycle 2 complete: all healthy


Digest: mol-deacon-patrol

Patrol 6: Quick cycle.


Digest: mol-deacon-patrol

Cycle 71: All healthy


Digest: mol-deacon-patrol

Patrol 32: All healthy


🤝 HANDOFF: Review: Molecule Algebra design complete, needs edge case analysis

## Context

Major design session with overseer produced the Molecule Algebra spec - a declarative
DSL for work composition. This is a significant architectural addition to Gas Town.

## What Was Created

### Documentation
- `docs/molecule-algebra.md` - Full specification (~700 lines)

### Example Formulas
- `.beads/formulas/shiny.formula.json` - Engineer in a Box
- `.beads/formulas/rule-of-five.formula.json` - Jeffrey's Rule (expansion macro)
- `.beads/formulas/security-audit.formula.json` - AOP aspect
- `.beads/formulas/shiny-enterprise.formula.json` - Composed example

### Implementation Epic
- `gt-8tmz`: Molecule Algebra (14 child tasks)

## Key Concepts Introduced

1. **Formula + Cook** (Breaking Bad × Mad Max naming)
   - Formula = YAML source with composition rules
   - Cook = pre-expand macros/aspects to flat proto
   - "Let's cook" produces pure protos

2. **Four-Tier Model**
   Formula → cook → Proto → pour/wisp → Mol/Wisp

3. **Composition Operators**
   - Advice: before/after/around (Lisp-style)
   - Expansion: macros like Rule of Five
   - Aspects: AOP cross-cutting concerns
   - Control: loop, gate, branch

4. **The Mol/Wisp Decision**
   - Mol = the work itself (persistent, audit trail)
   - Wisp = scaffolding for execution (ephemeral)
   - `--on` flag implies wisp

## Your Task: Design Review

Please review for:

1. **Edge cases in the algebra**
   - What happens with circular dependencies?
   - Expansion within expansion (nested macros)?
   - Aspects that match aspect-inserted steps?

2. **Unexplored areas**
   - Error handling in formulas
   - Formula versioning/migration
   - Debugging cooked protos
   - Formula validation

3. **Dependency consistency in gt-8tmz**
   - Are the task dependencies correct?
   - Missing tasks?
   - Priority ordering sensible?

4. **Cross-reference with existing docs**
   - molecular-chemistry.md
   - molecules.md
   - wisp-architecture.md
   - Any conflicts or redundancies?

## Files to Read
1. docs/molecule-algebra.md (the new spec)
2. bd show gt-8tmz (the implementation epic)
3. .beads/formulas/*.json (examples)

## Don't Implement - Just Review
This is a design review pass. Note concerns, questions, edge cases.
File new beads for anything that needs addressing.


Digest: mol-deacon-patrol

Patrol 4: routine, all healthy


Digest: mol-deacon-patrol

Cycle 16: Quiet


Digest: mol-deacon-patrol

Patrol cycle 7: All quiet, 3 rigs healthy


Digest: mol-deacon-patrol

Patrol 46: All healthy


Digest: mol-deacon-patrol

C79: Healthy.


Digest: mol-deacon-patrol

Patrol 7: All clear


Digest: mol-deacon-patrol

Patrol 86: All healthy. No incidents.


Digest: mol-deacon-patrol

Patrol 3: All healthy


Digest: mol-deacon-patrol

Cycle 12: Clean


Digest: mol-deacon-patrol

Patrol 11: all healthy


Digest: mol-deacon-patrol

Patrol 17: all clear


Digest: mol-deacon-patrol

Patrol 4: All healthy


Digest: mol-deacon-patrol

Patrol 10


Digest: mol-deacon-patrol

Patrol 18: Quiet


Digest: mol-deacon-patrol

Patrol 16: Quick cycle.


Digest: mol-deacon-patrol

Patrol 6: routine, all healthy


Digest: mol-deacon-patrol

Patrol 82: All healthy, routine


Digest: mol-deacon-patrol

Patrol cycle 7: All healthy


Digest: mol-deacon-patrol

C82: Healthy. Session handoff at 10 cycles.


Digest: mol-deacon-patrol

Patrol cycle 17: all healthy


Digest: mol-deacon-patrol

Patrol cycle 2: Inbox clear, 5 convoys open (new: cv-startup), all healthy, 5 gastown polecats running.


Digest: mol-deacon-patrol

Patrol 13: Routine


Digest: mol-deacon-patrol

Patrol cycle 17: routine


Digest: mol-deacon-patrol

Patrol 4: Clean


Digest: mol-deacon-patrol

Patrol 15: Routine


Reconciliation anti-pattern: witness.go reconciles tmux vs bead state

mayor/rig/internal/cmd/witness.go (lines 212-217) reconciles Go-computed state with agent-reported state:
```go
// Reconcile state: tmux session is the source of truth for background mode
if sessionRunning && w.State != witness.StateRunning {
    w.State = witness.StateRunning
} else if !sessionRunning && w.State == witness.StateRunning {
    w.State = witness.StateStopped
}
```

This directly violates: 'If your Go code reconciles inferred state with agent-reported state, stop. Agent state wins, always.'

The witness's self-reported state should be authoritative. If state gets out of sync, let the witness agent detect and report the discrepancy itself.

Fixed: Removed reconciliation logic. Now displays agent-reported state as authoritative per ZFC, with a warning note if tmux session state disagrees.


Digest: mol-deacon-patrol

Patrol 9: Quiet


Digest: mol-deacon-patrol

Patrol cycle 4: routine


Digest: mol-deacon-patrol

Patrol cycle 7: clean


Digest: mol-deacon-patrol

Patrol 19


POLECAT_STARTED morsov

Issue: bd-3sz0
Session: gt-beads-morsov


Digest: mol-deacon-patrol

Patrol 13: routine, no incidents


Digest: mol-deacon-patrol

Patrol 18: Routine


Session ended: gt-gastown-witness


Digest: mol-deacon-patrol

Patrol 1: All healthy - 10 agents running, 2 stopped (zoey/jack). No callbacks, no gates, no orphans.


📋 Work Assignment: Implement gt sling command

Issue: gt-4ev4
Title: Implement gt sling command
Priority: P1
Type: task

Description:
The unified work dispatch command.

```bash
gt sling <thing> <target> [options]
```

Implements spawn + assign + pin in one operation. See sling-design.md.

Acceptance:
- [ ] Parse thing (proto name, issue ID, epic ID)
- [ ] Parse target (agent address)
- [ ] Spawn molecule if proto
- [ ] Assign to target agent
- [ ] Pin to agent's hook (pinned bead)
- [ ] Support --wisp flag for ephemeral
- [ ] Support --molecule flag for issue+workflow
- [ ] Error if hook already occupied (unless --force)

## Workflow
1. Run `gt prime` to load polecat context
2. Run `bd sync --from-main` to get fresh beads
3. Work on your task, commit changes regularly
4. Run `bd close <issue-id>` when done
5. Run `bd sync` to push beads changes
6. Push code: `git push origin HEAD`
7. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 11: routine


Digest: mol-deacon-patrol

Patrol 5: routine


Digest: mol-deacon-patrol

Patrol 3: All agents healthy. No messages.


Digest: mol-deacon-patrol

Patrol 8: All healthy, no inbox


Digest: mol-deacon-patrol

Patrol cycle 17: All quiet


Digest: mol-deacon-patrol

Patrol 4: all healthy


Digest: mol-deacon-patrol

Patrol cycle 3: All agents healthy, cleaned 1 orphan session, routine


Digest: mol-deacon-patrol

Patrol 42: All healthy, 3 convoys active, no issues


Digest: mol-deacon-patrol

Patrol 16: Town idle


Digest: mol-deacon-patrol

Patrol cycle 20: routine


Digest: mol-deacon-patrol

Patrol cycle 13: All healthy


Digest: mol-deacon-patrol

Patrol cycle 18: All healthy


Digest: mol-deacon-patrol

Patrol 20


Digest: mol-deacon-patrol

Patrol 6: nominal


🤝 HANDOFF: Patrol system design - Beacon, Runner, Deacon molecule

## Context

Working on gt-7918: Patrols epic. User wants next session to ultrathink on:
1. Beacon architecture
2. Patrol runner implementation
3. Deacons specific patrol molecule

## Design Thinking So Far

### The Beacon

The beacon is the heartbeat. Three implementation options:

**Option A: Internal Ticker (Recommended)**
- Deacon runs long-lived with goroutine ticker
- Pros: Integrated, no external deps, can coordinate multiple patrols
- Cons: Dies if Deacon crashes
- Implementation: time.NewTicker(30 * time.Second) in Deacon main loop

**Option B: External Cron**
- System cron fires gt deacon tick every N seconds
- Pros: Survives Deacon crashes, Unix-y
- Cons: Requires system setup, less integrated

**Option C: Mail-Based**
- Separate beacon process sends TICK mail to Deacon
- Pros: Reuses mail infrastructure
- Cons: Overhead, another process to manage

Lean toward Option A with Option B as fallback.

### Patrol Runner Algorithm

Key insights:
- Mail interrupts between steps, not during
- State persisted after each step (crash recovery)
- Session reset is just another step type
- Loop delay prevents tight-looping on all-skipped iterations

Pseudocode:
  while true:
    for step in patrol.steps:
      if hasUrgentMail(): handleMail(); continue
      if now - step.lastRun < step.cooldown: skip; continue
      execute(step)
      step.lastRun = now
      if step.type == session-reset: handoff and return
      savePatrolState()
    sleep(loopDelay)

### Deacon Patrol Molecule

mol-deacon-patrol:
  type: patrol
  loop_to: health-check
  loop_delay: 5s

  steps:
    - health-check (30s, critical) - Check sessions responsive
    - witness-ping (1m, active) - Verify Witness alive
    - session-gc (5m, maintenance) - Clean dead sessions
    - orphan-check (10m, maintenance) - Find lost work
    - session-reset (30m, periodic) - Cycle for memory

### State Persistence

Recommendation: Hybrid
- Patrol definition in beads (the molecule)
- Runtime state in local file (fast)
- Periodic sync of state to beads (durability)

### Error Handling

1. Log error with step ID
2. Increment errorCount
3. Circuit breaker if threshold exceeded
4. Escalate critical failures to Mayor
5. Continue to next step

### Open Questions for Next Session

1. How does Deacon bootstrap patrol on fresh start?
2. Multi-rig coordination - one patrol per rig or global?
3. Patrol priority vs spawn requests?
4. Observability - gt patrol status, metrics, alerting

## Files to Look At

- internal/cmd/molecule.go - existing molecule infrastructure
- internal/cmd/spawn.go - MoleculeContext pattern
- internal/cmd/prime.go - outputMoleculeContext

## Next Steps

1. Sketch Deacon patrol molecule in beads format
2. Implement PatrolStep struct with cooldown logic
3. Add patrol runner to Deacon
4. Integrate with auto-handoff (gt-bcwn)
5. Add gt patrol status command

## Related Issues

- gt-7918: Patrols epic
- gt-bcwn: Auto-handoff


Digest: mol-deacon-patrol

Patrol cycle 3: All agents healthy


Digest: mol-deacon-patrol

Patrol 18: healthy


🤝 HANDOFF: Christmas Launch Phase 1 - mol execution

## Christmas Launch Progress

### Completed
- Phase 0: ✅ Complete
  - bd mol bond, spawn, run, distill, catalog, show all working
  - Built fresh bd from beads main, installed to ~/.local/bin/bd
  - NOTE: Required `codesign -s -` after copy to fix macOS signing

- Phase 1 Progress:
  - gt-8v8: ✅ Done (refuse uncommitted work)
  - gt-9nf: ✅ Done + code review fixes merged (fresh polecats)
  - **gt-975: NEXT** - Molecule execution support for polecats

### Next Steps for gt-975
1. Review gt-975 requirements: `bd show gt-975`
2. Check how bd mol run works: `bd mol run --help`
3. Integrate molecule execution into gt spawn --molecule flow
4. Test with mol-christmas-launch or create test molecule

### Key Context
- bd binary is now dev version with full mol support
- Dave still fixing bugs in beads, official release pending
- All 4 gastown clones synced to main

### Reference
- Christmas plan: gt-ngpz
- Phase 1 issues: gt-9nf, gt-975, gt-8v8


Digest: mol-deacon-patrol

Patrol cycle 3 complete: all clear, agents healthy. Patrol count 3.


Digest: mol-deacon-patrol

Patrol cycle 5: Routine, all healthy


🤝 HANDOFF: GH#720 fixed, ready for next

## Session Summary

Fixed GH#720: Parallel execution fails with database migration error (d677554e)

The issue was a race condition in RunMigrations when multiple bd commands open
the database simultaneously. Fixed by:
1. Wrapping RunMigrations in BEGIN EXCLUSIVE transaction
2. Moving PRAGMA foreign_keys=OFF outside the transaction (SQLite requirement)
3. Converting nested transactions in migrations 010, 022, 025 to SAVEPOINTs

## Environment State

- Git: clean, pushed to origin/main
- Tests: all passing
- Commented on GH#720 with fix details

## mol-ready-work Proto

Does NOT exist yet. Previous session filed gt-tnca (in ~/gt/.beads) as the design
epic for this patrol pattern, but the proto itself needs implementation.

## Good Candidates for Next Session

From GH issues:
- GH#714: bd doctor count mismatch (needs investigation)
- GH#704: Absolute paths in global gitignore with --stealth (bug)
- GH#664: bd create --parent fails even when parent exists (bug)

From beads:
- bd-4opy: Refactor long SQLite test files (P2 task)
- bd-bqcc: Consolidate maintenance commands into bd doctor --fix (P2 feature)

## Workflow

Pick an issue from GH or bd ready, implement fix with tests, commit and push.


Digest: mol-deacon-patrol

Patrol cycle 9: All healthy


Digest: mol-deacon-patrol

Patrol #12: routine


Digest: mol-deacon-patrol

Patrol 2: All 6 agents healthy, no issues


Digest: mol-deacon-patrol

Patrol 1: Checked inbox (3 mayor msgs, 1 deacon handoff), nudged 0 polecats, no async gates, all witnesses/refineries healthy, no abandoned work, no orphan sessions, no plugins


Digest: mol-deacon-patrol

Patrol 4: Town idle


Digest: mol-deacon-patrol

Patrol 30: All healthy


Digest: mol-deacon-patrol

Patrol cycle 4: quiet


Digest: mol-deacon-patrol

Patrol cycle 20: quiet, handoff


Digest: mol-deacon-patrol

Patrol cycle 15: Nominal


Digest: mol-deacon-patrol

Patrol: healthy


Digest: mol-deacon-patrol

Patrol 6: quiet


Digest: mol-deacon-patrol

Patrol cycle 15 complete: all clear.


Digest: mol-deacon-patrol

Patrol 21: Closed 2 convoys (identity, boot+polish), all agents healthy (3 witnesses, 3 refineries), 3 gastown polecats working


🤝 HANDOFF: Wisp rename in progress (ephemeral → wisp)

## Context
Renaming "ephemeral" to "wisp" throughout the codebase for the Steam Engine metaphor:
- Claude = Fire
- Claude Code = Steam
- Gas Town = Steam Engine (consuming molecules)
- Wisps = ephemeral vapor it produces

## Completed ✅
1. **types.go**: Ephemeral → Wisp field, IssueFilter.Ephemeral → Wisp
2. **Storage layer**: All sqlite files updated (issues.go, queries.go, dependencies.go, multirepo.go, multirepo_export.go, ready.go, transaction.go)
3. **Commands**: cleanup.go (--wisp flag), autoflush.go, export.go, mol_spawn.go, mol_squash.go, mol_bond.go, mol_run.go, template.go
4. **RPC layer**: protocol.go, server_issues_epics.go
5. **Build passes**: `go build ./...` succeeds

## Remaining Work 📋
1. **Update tests** - mol_test.go, thread_test.go, prime_test.go, delete_test.go have Ephemeral references
2. **Update info.go** - Change release notes from "ephemeral" to "wisp" terminology
3. **Update CHANGELOG.md** - Same terminology update
4. **Run tests** - Verify all pass
5. **Commit and push**
6. **Bump to v0.33.1** - Run from mayor/rig

## Notes
- Database column stays as 'ephemeral' (no migration needed)
- JSON field changed from "ephemeral" to "wisp" (breaking change for anyone using 0.33.0)
- The --persistent flag on mol spawn stays (could become --solid later)

## Commands to continue
```bash
grep -rn "Ephemeral" cmd/bd/*_test.go  # Find test references
go test -short ./...                    # Run tests after updates
```


📋 Work Assignment: Add molecule phase lifecycle diagram to architecture.md

Issue: gt-c6zs
Title: Add molecule phase lifecycle diagram to architecture.md
Priority: P1
Type: task

Description:
Create a clear lifecycle diagram showing molecule phases:

```
                    ┌─────────────┐
                    │   Proto     │
                    │  (crystal)  │
                    └──────┬──────┘
                           │
                      bd mol bond
                           │
              ┌────────────┴────────────┐
              │                         │
              ▼                         ▼
      ┌───────────────┐        ┌───────────────┐
      │     Mol       │        │    Wisp       │
      │   (liquid)    │        │    (gas)      │
      │   durable     │        │  ephemeral    │
      │  main beads   │        │ .beads-eph/   │
      └───────┬───────┘        └───────┬───────┘
              │                        │
         bd mol squash            bd mol squash
              │                        │
              ▼                        ▼
      ┌───────────────┐        ┌───────────────┐
      │    Digest     │        │   (nothing)   │
      │ (distillate)  │        │  evaporates   │
      │  in git hist  │        └───────────────┘
      └───────────────┘
```

Also document:
- When to use Mol vs Wisp
- Mol: code review waves, epic implementation, feature work
- Wisp: orchestration, polecat work sessions, patrol loops

## Workflow
1. Run `gt prime` to load polecat context
2. Run `bd sync --from-main` to get fresh beads
3. Work on your task, commit changes regularly
4. Run `bd close <issue-id>` when done
5. Run `bd sync` to push beads changes
6. Push code: `git push origin HEAD`
7. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 9: All clear


Digest: mol-deacon-patrol

Patrol 14: Quick cycle.


Digest: mol-deacon-patrol

Patrol 75


Digest: mol-deacon-patrol

Patrol cycle 14: All healthy


Digest: mol-deacon-patrol

Patrol 14: All healthy, no inbox


Digest: mol-deacon-patrol

Patrol 14: All healthy


Digest: mol-deacon-patrol

Patrol 1: No messages, cleaned 295 stale wisps, 1 orphan session killed, all agents healthy


Digest: mol-deacon-patrol

Patrol cycle 3: Healthy. All 3 rigs running.


Digest: mol-deacon-patrol

Patrol cycle 1: All healthy, cleaned 1 orphan (gt-boot), gastown 12 pending, beads 8 pending


Digest: mol-deacon-patrol

Patrol 1: inbox clear, all agents healthy, no orphans, clone-divergence noted


Digest: mol-deacon-patrol

Patrol cycle 14


Digest: mol-deacon-patrol

Patrol 7: All healthy


POLECAT_STARTED gastown/toast

Issue: gt-8a0h
Session: gt-gastown-toast


Digest: mol-deacon-patrol

Patrol cycle 7: routine


Digest: mol-deacon-patrol

Patrol #2: quick cycle, all healthy


Digest: mol-deacon-patrol

Patrol cycle 3: clean, all healthy


Digest: mol-deacon-patrol

Patrol cycle 6: All healthy


Digest: mol-deacon-patrol

Patrol 17: All healthy.


Start MQ Processing

12 items are in the merge queue waiting to be processed. Please start the pileup protocol and process them sequentially.


Digest: mol-deacon-patrol

Patrol 10: Quiet


Digest: mol-deacon-patrol

Patrol #10: all healthy except zoey stopped, morsov done


SPAWN: nux starting on gt-3x0z.2

Polecat spawn notification.

Polecat: nux
Issue: gt-3x0z.2
Session: gt-gastown-nux
Spawned by: mayor/

Please monitor this polecat's startup. When Claude is ready (you can see the prompt
in the tmux session), send a nudge to start working:

    tmux send-keys -t gt-gastown-nux "Check your inbox with 'gt mail inbox' and begin working." Enter

The polecat has a work assignment in its inbox.


Digest: mol-deacon-patrol

Patrol 18: quiet


Digest: mol-deacon-patrol

Patrol #13: routine


POLECAT_STARTED furiosa

Issue: bd-au0.6
Session: gt-beads-furiosa


Digest: mol-deacon-patrol

Patrol 10 (midpoint)


Digest: mol-deacon-patrol

Patrol cycle 13: All quiet, 3 rigs healthy


Digest: mol-deacon-patrol

Patrol 12: healthy


Digest: mol-deacon-patrol

Patrol cycle 5: All quiet


POLECAT_STARTED dag

Issue: bd-dtl8
Session: gt-beads-dag


Digest: mol-deacon-patrol

Patrol cycle 5: inbox clear, all 6 agents healthy, fixed 1 orphan


Digest: mol-deacon-patrol

Quiet patrol: all stable


Digest: mol-deacon-patrol

Patrol 2: Routine, all healthy


Digest: mol-deacon-patrol

Patrol cycle 16: All healthy


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.


Digest: mol-deacon-patrol

Patrol 8: Quiet


Digest: mol-deacon-patrol

Patrol cycle 1: All healthy, fixed hook attachments, no lifecycle requests


Digest: mol-deacon-patrol

Patrol cycle 3: All nominal, quick pass


📋 Work Assignment: mol-witness-patrol molecule definition

Issue: gt-83k0
Title: mol-witness-patrol molecule definition
Priority: P1
Type: task

Description:
Create mol-witness-patrol in builtin_molecules.go.

## Steps (10 total)
1. inbox-check - Process witness mail (lifecycle, help requests)
2. load-state - Read handoff bead, get nudge counts
3. survey-workers - gt polecat list, categorize by status
4. inspect-workers - tmux capture-pane for each 'working' polecat
5. decide-actions - Apply nudge matrix, queue actions
6. execute-actions - Nudge, kill, or escalate as decided
7. save-state - Update handoff bead with new states
8. generate-summary - Summarize cycle for digest
9. context-check - Check own context usage
10. burn-or-loop - Squash wisp, then loop or cycle session

## Key Behaviors
- Uses wisp storage (.beads-wisp/)
- Reads/writes witness handoff bead for state persistence
- Progressive nudging (3 levels before escalate)
- Pre-kill verification before killing polecats

## Reference
- See prompts/roles/witness.md for protocol details
- See mol-refinery-patrol for similar structure
- Parent epic: gt-aqd8

## Workflow
1. Run `gt prime` to load polecat context
2. Work on your task, commit changes regularly
3. Run `bd close <issue-id>` when done
4. Run `bd sync` to push beads changes
5. Push code: `git push origin HEAD`
6. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 10: All healthy


Digest: mol-deacon-patrol

Patrol 19: quiet


Test: new slash format

Testing new slash-based addressing


Digest: mol-deacon-patrol

Patrol cycle 5: Routine


Safeguard town root from accidental branch switches

dispatched_by: mayor

The town root (\~/gt) should stay on the main branch (tracking origin/main for workspace state). Today we discovered the town root had been switched to temp-merge (a gastown polecat branch) which caused:

1. mayor/rigs.json to appear missing (it was on main, not temp-merge)
2. gt commands to fail with 'rig not found'
3. Confusion about what happened

Proposed safeguards:
1. Add a pre-checkout hook in town root that warns/prevents switching off main
2. gt doctor check: verify town root is on expected branch
3. gt commands that run in town root should verify branch before operating

The root cause was likely a git command or gt command running in the wrong directory.


LIFECYCLE: mayor requesting cycle

Lifecycle request from mayor.

Action: cycle
Time: 2025-12-21T01:16:25-08:00
Polecat:

Please verify state and execute lifecycle action.


Digest: mol-deacon-patrol

Patrol C44: All healthy


Process merge queue

Two merge requests ready:
- gt-c7z9: Merge gt-3x0z.1 (branch polecat/furiosa)
- gt-3z6x: Merge gt-rana.3 (branch polecat/dementus)

Please process these merges to main.


Digest: mol-deacon-patrol

Patrol 10: 13 polecats working. Swarm active.


Handoff

attached_molecule: hq-uwg3
attached_at: 2025-12-23T12:35:58Z


Digest: mol-deacon-patrol

Patrol 1: All agents healthy. Clone divergence noted (gastown/crew/jack 64 behind). No incidents.


Digest: mol-deacon-patrol

Patrol 16: routine, all healthy


Digest: mol-deacon-patrol

Patrol 2: All healthy, 12 sessions active, 2 convoys


Digest: mol-deacon-patrol

Patrol 5: All healthy, no incidents


Digest: mol-deacon-patrol

Patrol 4: Healthy


POLECAT_STARTED beads/valkyrie

Issue: bd-a15d
Session: gt-beads-valkyrie


Digest: mol-deacon-patrol

Patrol 28: town idle, all healthy


Digest: mol-deacon-patrol

Patrol 28: All healthy


Digest: mol-deacon-patrol

Patrol 91: All healthy


Digest: mol-deacon-patrol

Patrol 5: Routine.


🤝 HANDOFF: gt-975 Molecularizing polecats

## Next Task: gt-975 - Molecule execution for polecats

### Context
- Phase 1 items gt-9nf, gt-8v8: DONE
- gt-975 is the remaining Phase 1 blocker
- bd mol commands all working (bond, spawn, run, distill, catalog, show)
- Dave refactoring mol.go (bd-cnwx), then bd squash (bd-2vh3)

### gt-975 Implementation Steps
1. Polecat startup: check for assigned molecules via bd ready
2. Polecat work loop: follow molecule DAG, close steps as done
3. Witness: monitor molecule progress, detect stalls
4. Mayor: assign molecules, handle escalations

### Start Here
```
bd show gt-975
bd mol catalog  # See available molecule templates
```

### Side Quests (farmed to crew)
- gt-48bs: gt rig reset mail cleanup
- gt-qivm: auto-prime for crew at (hq-koh handoff)
- gt-tca: polecat auto-cleanup after MR (hq-amn handoff)

### Also Done This Session
- Closed gt-pc5d (stale polecat recovery - done via gt orphans)
- Added PostToolUse hook: auto-signs gt after go build in gastown
  ~/.claude/hooks/post-go-build.sh

- Mayor


Digest: mol-deacon-patrol

Patrol 5: No callbacks, all healthy


Digest: mol-deacon-patrol

Routine patrol: all checks clean


Digest: mol-deacon-patrol

Patrol cycle 5: routine, all healthy


Digest: mol-deacon-patrol

Patrol 19: all clear


POLECAT_STARTED beads/kilo

Issue: bd-dhza
Session: gt-beads-kilo


Digest: mol-deacon-patrol

Patrol 9: Routine


Digest: mol-deacon-patrol

Patrol cycle 8: healthy


🤝 HANDOFF: Patrol formulas created, awaiting bd cook

## This Session

1. Fixed 21 backwards dependencies (children depending on parent epics)
2. Filed bd-nim5: Detect/prevent child→parent dependency anti-pattern
3. Completed gt-ingm.1: Created 4 patrol formula YAML files:
   - mol-deacon-patrol.formula.yaml (8 steps)
   - mol-witness-patrol.formula.yaml (9 steps, Christmas Ornament)
   - mol-refinery-patrol.formula.yaml (10 steps)
   - mol-polecat-arm.formula.yaml (5 steps, dynamic bonding)

## Next Step

gt-ingm.2: Cook patrol formulas into proto beads
- Blocked on gt-8tmz.13 (bd cook command)
- Check if Dave finished bd cook: bd cook --help
- If available, run: bd cook .beads/formulas/*.formula.yaml
- Verify protos created: bd mol list

## Formula Location

~/gt/gastown/crew/joe/.beads/formulas/

## Context

The molecular chemistry cleanup (gt-ingm) replaces embedded Go markdown
with proper formula YAML → cook → proto pipeline.

Filed bd-weu8 and bd-wa2l for Dave. Cross-referenced in gt-8tmz.12 and gt-8tmz.13.


Digest: mol-deacon-patrol

Patrol 19: healthy


Digest: mol-deacon-patrol

Patrol complete: 0 inbox messages, all agents healthy, clone divergence noted (gastown/crew/jack 64 behind)


ZFC violation: PID-based process detection in util/process.go

util/process.go (lines 10-24) checks process existence via PID signaling:
```go
func ProcessExists(pid int) bool {
    process, err := os.FindProcess(pid)
    err = process.Signal(syscall.Signal(0))
    return err == nil
}
```

Per ZFC, Go shouldn't infer process state by checking PID existence. Agent liveness should be derived from beads state or explicit agent reporting, not PID probing.

Removed ProcessExists usage from witness/refinery managers; now use tmux session detection per ZFC


Digest: mol-deacon-patrol

Patrol 11: Town quiet


Digest: mol-deacon-patrol

Patrol 8: healthy


🤝 HANDOFF: P0 wisp spawning bug

## Context
Just implemented gt-afn0 (mail queue for patrol roles) but introduced a P0 bug:
Patrol spawning uses main DB instead of wisp storage.

## P0 Bug: gt-jsup
Patrol molecules should be wisps (ephemeral) but currently spawn into main DB.
Root cause: bd mol run can't find templates when using --db .beads-wisp/beads.db
because templates only exist in main DB.

## Fix needed
bd mol run needs cross-database support:
- Read template from main DB
- Write spawned instance to wisp DB

Check the beads repo for bd mol run implementation.

## Files to fix
- gastown: internal/cmd/sling.go lines 680, 883, 1050 (revert IsWisp: false → true)
- beads: wherever bd mol run is implemented

## What's working
- gt sling to patrol roles queues via mail (gt-afn0 ✓)
- --urgent and --replace flags work
- Just need wisp spawning fixed


🤝 HANDOFF: Batch 1 complete, notifications working

## Polecat Lifecycle Tracer Bullet - Batch 1 Complete

### This Session
- Cleaned up old Furiosa (from Dave's session)
- Spawned 2 polecats in parallel:
  - furiosa → gt-r6td (spawn notifications)
  - nux → gt-jzot (done notifications)
- Both completed and merged via Refinery
- Both polecats cleaned up manually (lifecycle gap we're fixing)

### Now Merged
- **gt spawn**: Notifies Witness + Deacon on polecat start
- **gt done**: Notifies Witness with exit outcome (COMPLETED/ESCALATED/DEFERRED)
- gt rebuilt with both features

### Next: Batch 2
The notifications are in place. Now the Witness needs to READ them:

1. **gt-83k0**: mol-witness-patrol (10-step loop with inbox-check)
2. **gt-lnji**: gt polecat git-state (pre-kill verification)

Then Batch 3 to wire it up:
- gt-lx3n: Witness startup bonds mol-witness-patrol
- gt-caih: State persistence

### Key Issues Filed
- gt-jzot: gt done notify Witness (created this session)
- gt-mmbh: Pre-existing test failures (filed by Refinery)

### Context
- Daemon PID: 25400 (running)
- Refinery/Witness sessions active
- No active polecats
- See gt-ngpz for Christmas plan


Digest: mol-deacon-patrol

Patrol 16: Quiet


Digest: mol-deacon-patrol

Patrol 5: all healthy


Digest: mol-deacon-patrol

C81: Healthy.


Digest: mol-deacon-patrol

Patrol cycle 10: all clear


🤝 HANDOFF: Document account management and walk user through it

## Context
Completed code review of account management implementation (gt-3133).

## What Was Done
- Reviewed all account management code
- Found and fixed missing `gt account status` command (commit 3ee23f5)
- All tests pass

## Remaining Tasks

### 1. Fix Doc Discrepancy
File: docs/design/account-management.md line ~106

The doc says:
  gt crew attach --account=ghosttrack max

But the actual command is:
  gt crew at --account=ghosttrack max

Update the doc to use correct command name.

### 2. Walk User Through Account Management

Give the user a walkthrough of how multi-account Claude Code works in Gas Town:

Key points to cover:
- Why: switching between personal/work accounts, quota management
- Where config lives: ~/gt/mayor/accounts.json
- Commands: gt account list/add/default/status
- How to use: --account flag on spawn/crew at, or GT_ACCOUNT env var
- Priority order: GT_ACCOUNT > --account flag > default

Demo commands to show:
  gt account list
  gt account status
  gt account status with GT_ACCOUNT=yegge
  gt spawn --account=yegge (explain, don't run)
  gt crew at --account=yegge max (explain, don't run)

The implementation is complete and working. Just needs docs fix and user education.


Digest: mol-deacon-patrol

Patrol 7: routine, all healthy


Digest: mol-deacon-patrol

Patrol 7: all clear


Digest: mol-deacon-patrol

Patrol 86: all healthy


Digest: mol-deacon-patrol

Patrol cycle 3: All quiet, 3 rigs healthy


Digest: mol-deacon-patrol

Patrol 13: all healthy


Digest: mol-deacon-patrol

Patrol 40: healthy


Digest: mol-deacon-patrol

Patrol 27: routine, all healthy


Digest: mol-deacon-patrol

Patrol cycle 3: Routine, no issues


Digest: mol-deacon-patrol

Patrol 5: All agents healthy. No incidents.


Digest: mol-deacon-patrol

Cycle 9


Digest: mol-deacon-patrol

Patrol 1: inbox empty, 3 witnesses + 3 refineries healthy, mayor attached, no orphans


Digest: mol-deacon-patrol

Patrol cycle 17: All healthy


Digest: mol-deacon-patrol

Patrol 17: All healthy, no inbox


Digest: mol-deacon-patrol

Patrol 20: healthy


Digest: mol-deacon-patrol

Patrol 8: All healthy


Digest: mol-deacon-patrol

Patrol 14


Digest: mol-deacon-patrol

Patrol 84: all agents healthy, queues processing


Digest: mol-deacon-patrol

Patrol cycle 20: all healthy - handoff threshold reached


Digest: mol-deacon-patrol

Patrol 3: Town idle, no activity


Digest: mol-deacon-patrol

Patrol cycle 12: Routine


📋 Work Assignment: Test suite hangs/never finishes

Issue: bd-9usz
Title: Test suite hangs/never finishes
Priority: P2
Type: bug

Description:
Running 'go test ./... -count=1' hangs indefinitely. The full test suite never completes, making it difficult to verify changes. Need to investigate which tests are hanging and fix or add timeouts.

## Workflow
1. Run `gt prime` to load polecat context
2. Work on your task, commit changes regularly
3. Run `bd close <issue-id>` when done
4. Run `bd sync` to push beads changes
5. Push code: `git push origin HEAD`
6. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


POLECAT_STARTED furiosa

Issue: bd-dxtc
Session: gt-beads-furiosa


Digest: mol-deacon-patrol

Patrol 17: nominal


Digest: mol-deacon-patrol

Patrol 5: nominal


ZFC violation: Hardcoded stuck detection thresholds in deacon/stuck.go

deacon/stuck.go (lines 14-18) has hardcoded thresholds for stuck detection:
```go
const (
    DefaultPingTimeout        = 30 * time.Second
    DefaultConsecutiveFailures = 3
    DefaultCooldown           = 5 * time.Minute
)
```

Per ZFC: Let agents decide thresholds. 'Stuck' is a judgment call, not a hardcoded timer. The line between 'agent thinking' and 'agent stuck' isn't always clear externally (ref: Murder Spree Bug cautionary tale).

Also see patrol_check.go:219-229 with hardcoded 1-hour stuck threshold, and constants.go with ClaudeStartTimeout, ShellReadyTimeout.

Fixed: thresholds now configurable via role bead


Digest: mol-deacon-patrol

Patrol 166: All healthy


📋 Work Assignment: Polecat doesn't auto-start after spawn inject - requires manual nudge

Issue: gt-iu23
Title: Polecat doesn't auto-start after spawn inject - requires manual nudge
Priority: P1
Type: bug

Description:
## Problem

After `gt spawn --issue <id> --create`, the polecat session shows Claude Code started with the injected prompt, but Claude doesn't begin processing. The prompt just sits there until manually nudged.

## Evidence

```
$ gt spawn --issue gt-rixa --rig gastown --create
...
✓ Session started. Attach with: gt session at gastown/furiosa
  Polecat nudged to start working
  Witness notified to monitor startup
```

Session shows:
```
> You have a work assignment. Run 'gt mail inbox' to see it, then start
  working on issue gt-rixa.

  ⏵⏵ bypass permissions on (shift+tab to cycle)
```

But Claude doesn't respond. Manual nudge required:
```
$ gt nudge gt-gastown-furiosa "Please start working..."
```

After nudge, polecat immediately starts working correctly.

## Hypothesis

The spawn inject happens before Claude Code is fully initialized. The text arrives in the input buffer, but Claude hasn't started listening yet. By the time Claude starts, the input has already been 'consumed' as initial prompt text but not submitted.

## Resolution Plan

This will be solved by the **polecat molecule workflow** (mol-polecat-work), which provides structured lifecycle management. The molecule approach handles startup, work, and shutdown as discrete steps with proper state tracking.

**Blocked on**: beads/crew/dave completing ephemeral molecules (bd mol bond, ephemeral beads repo).

## Workaround

For now, use `gt nudge` if a polecat doesn't start within ~30 seconds of spawn.

## Workflow
1. Run `gt prime` to load polecat context
2. Run `bd sync --from-main` to get fresh beads
3. Work on your task, commit changes regularly
4. Run `bd close <issue-id>` when done
5. Run `bd sync` to push beads changes
6. Push code: `git push origin HEAD`
7. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol complete: quiet cycle, agents healthy


Digest: mol-deacon-patrol

Patrol C64: inbox empty, convoy hq-cv-w3nm6 pending (10 issues), burned 10 stale wisps, all agents healthy


Digest: mol-deacon-patrol

Patrol C52: all healthy, convoy hq-ao67r pending, no callbacks


Digest: mol-deacon-patrol

Patrol 9: Stable


POLECAT_STARTED cheedo

Issue: gt-f9x.5
Session: gt-gastown-cheedo


POLECAT_STARTED beads/dag

Issue: bd-c7y5
Session: gt-beads-dag


Digest: mol-deacon-patrol

Patrol 7: all healthy


Digest: mol-deacon-patrol

Patrol cycle 16: quiet


POLECAT_DONE nux

Exit: COMPLETED
Issue: bd-dtl8
MR: mr-1766562684-7921c41f
Branch: polecat/nux


POLECAT_STARTED max

Issue: bd-m8ro
Session: gt-beads-max


Digest: mol-deacon-patrol

Patrol 2: All healthy, no issues


POLECAT_STARTED slit

Issue: bd-9usz
Session: gt-beads-slit


Digest: mol-deacon-patrol

Patrol cycle 7: Routine


SPAWN: rictus starting on gt-3x0z.3

Polecat spawn notification.

Polecat: rictus
Issue: gt-3x0z.3
Session: gt-gastown-rictus
Spawned by: gastown/crew/max

Please monitor this polecat's startup. When Claude is ready (you can see the prompt
in the tmux session), send a nudge to start working:

    tmux send-keys -t gt-gastown-rictus "Check your inbox with 'gt mail inbox' and begin working." Enter

The polecat has a work assignment in its inbox.


📋 Work Assignment: Split large cmd/bd files: doctor.go (2948 lines), sync.go (2121 lines)

Issue: bd-05a8
Title: Split large cmd/bd files: doctor.go (2948 lines), sync.go (2121 lines)
Priority: P2
Type: task

Description:
Code health review found several oversized files:

1. doctor.go - 2948 lines, 48 functions mixed together
   - Should split into doctor/checks/*.go for individual diagnostics
   - applyFixes() and previewFixes() are nearly identical

2. sync.go - 2121 lines
   - ZFC (Zero Flush Check) logic embedded inline (lines 213-247)
   - Multiple mode handlers should be extracted

3. init.go - 1732 lines
4. compact.go - 1097 lines
5. show.go - 1069 lines

Recommendation: Extract into focused sub-packages or split into logical files.

## Workflow
1. Run `gt prime` to load polecat context
2. Work on your task, commit changes regularly
3. Run `bd close <issue-id>` when done
4. Run `bd sync` to push beads changes
5. Run `gt done` to signal completion (branch stays local)

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 8: Healthy


Digest: mol-deacon-patrol

Patrol 4


Digest: mol-deacon-patrol

Patrol 5: all clear


Digest: mol-deacon-patrol

Patrol 1: inbox empty, all agents healthy, no orphans, context low


Digest: mol-deacon-patrol

Patrol cycle 17: all clear


POLECAT_STARTED beads/ace

Issue: bd-ymqn
Session: gt-beads-ace


Digest: mol-deacon-patrol

Cycle 69: All healthy


📌 HANDOFF: Christmas Launch Progress

## Completed This Session

### Molecule Unification (bd-ffjt, bd-8b0x, bd-icnf) ✅
- Added bd mol catalog/show/bond/run commands
- Deprecated bd template commands
- Removed molecule.go (simple instantiation)
- bd mol run = bond + assign + pin (durable execution)

### Documentation Cleanup ✅
- Fixed all bd mail → gt mail references in CLAUDE.md files
- Pushed to both beads and gt repos

### Filed
- hq-s5l: Session-close molecule (P3, needs bead squash)

## Next: Christmas Launch

Check bd-p5za (mol-christmas-launch) for the 3-day execution plan.

Key areas:
1. Gas Town stability (witness, refinery, spawn)
2. Beads polish (molecules, pinning, mail)
3. Documentation for launch
4. Demo/video preparation

Run: bd show bd-p5za

Time: 2025-12-21T00:25:01-08:00


Digest: mol-deacon-patrol

Patrol 10: routine


Digest: mol-deacon-patrol

Patrol 17: Quiet


Digest: mol-deacon-patrol

Patrol 2: routine check, all clear


Digest: mol-deacon-patrol

Patrol 11: Routine


Digest: mol-deacon-patrol

Patrol 49: All healthy


POLECAT_STARTED beads/Beader

Issue: bd-tvu3
Session: gt-beads-Beader


POLECAT_STARTED gastown/slit

Issue: gt-g2d
Session: gt-gastown-slit


Digest: mol-deacon-patrol

Patrol 6: routine, no incidents


Digest: mol-deacon-patrol

Patrol 9: Quick cycle.


POLECAT_DONE dag

Exit: COMPLETED
Issue: gt-h6eq.3
MR: gt-23ic
Branch: polecat/dag


bd repair: Fix orphaned deps/labels when database won't open

## Problem

When the database has orphaned foreign key references, the migration invariant check fails, preventing the database from opening. This creates a chicken-and-egg problem where `bd doctor --fix` can't run because it can't open the database.

## Solution

Add `bd repair` command (or `bd doctor --force-repair`) that:
1. Opens SQLite directly, bypassing the normal open path with invariant checks
2. Deletes orphaned dependencies (issue_id or depends_on_id not in issues)
3. Deletes orphaned labels (issue_id not in issues)
4. Runs WAL checkpoint to persist changes
5. Then allows normal bd commands to work

## Implementation

```go
// In cmd/repair.go or extend doctor.go
func repairDatabase(dbPath string) error {
    db, err := sql.Open("sqlite3", dbPath)
    // No migrations, no invariant checks

    // Delete orphans
    db.Exec("DELETE FROM dependencies WHERE NOT EXISTS (SELECT 1 FROM issues WHERE id = issue_id)")
    db.Exec("DELETE FROM dependencies WHERE NOT EXISTS (SELECT 1 FROM issues WHERE id = depends_on_id) AND depends_on_id NOT LIKE 'external:%'")
    db.Exec("DELETE FROM labels WHERE NOT EXISTS (SELECT 1 FROM issues WHERE id = issue_id)")

    db.Exec("PRAGMA wal_checkpoint(TRUNCATE)")
    return nil
}
```

This is the emergency escape hatch when things go wrong.


Digest: mol-deacon-patrol

Patrol cycle 5: All healthy, 5 crew running


Digest: mol-deacon-patrol

Patrol cycle 13: read mayor addendum, all healthy


Digest: mol-deacon-patrol

Patrol 20: routine, all healthy - handoff threshold reached


POLECAT_STARTED beads/slit

Issue: bd-9usz
Session: gt-beads-slit


Digest: mol-deacon-patrol

Patrol cycle 10: All healthy


Digest: mol-deacon-patrol

Patrol 4: Nominal


Session ended: gt-deacon


Digest: mol-deacon-patrol

Patrol 70


Digest: mol-deacon-patrol

Patrol 2: quiet cycle, all agents healthy


Digest: mol-deacon-patrol

Patrol 17: All healthy


SPAWN: dementus starting on gt-ay1r

Polecat spawn notification.

Polecat: dementus
Issue: gt-ay1r
Session: gt-gastown-dementus
Spawned by: gastown/crew/max

The Deacon will trigger this polecat when Claude is ready (WaitForClaudeReady).
The polecat's SessionStart hook runs gt prime, and work assignment is in its inbox.
Monitor for stuck/idle state after a few minutes.


Digest: mol-deacon-patrol

Patrol 18: healthy


Digest: mol-deacon-patrol

Cycle 17: Clean


Digest: mol-deacon-patrol

## Molecule Execution Summary

**Molecule**: mol-deacon-patrol
**Steps**: 9

**Completed**: 9/9

---

### Steps

1. **[closed]** Nudge newly spawned polecats
   Nudge newly spawned polecats that are ready for input.

When polecats are spawned, their Claude session takes 10-20 seconds to initialize. The spawn command returns immediately without waiting. This s...

2. **[closed]** Check Witness and Refinery health
   Check Witness and Refinery health for each rig.

**ZFC Principle**: You (Claude) make the judgment call about what is "stuck" or "unresponsive" - there are no hardcoded thresholds in Go. Read the sign...

3. **[closed]** Clean dead sessions
   Clean dead sessions and orphaned state.

Run `gt doctor -v` to check for issues, then `gt doctor --fix` to clean up.

**⚠ CRITICAL: The Deacon NEVER kills crew workers or polecats!**

The orphan-...

4. **[closed]** Find abandoned work
   Find abandoned work.

Scan for orphaned state:
- Issues marked in_progress with no active polecat
- Polecats that stopped responding mid-work
- Merge queue entries with no polecat owner
- Wisp session...

5. **[closed]** Evaluate pending async gates
   Evaluate pending async gates.

Gates are async coordination primitives that block until conditions are met.
The Deacon is responsible for monitoring gates and closing them when ready.

**Timer gates**...

6. **[closed]** Burn and respawn or loop
   Burn and let daemon respawn, or exit if context high.

Decision point at end of patrol cycle:

If context is LOW:
- Sleep briefly (avoid tight loop)
- Return to inbox-check step

If context is HIGH:
-...

7. **[closed]** Check own context limit
   Check own context limit.

The Deacon runs in a Claude session with finite context. Check if approaching the limit:

```bash
gt context --usage
```

If context is high (>80%), prepare for handoff:
- Su...

8. **[closed]** Handle callbacks from agents
   Handle callbacks from agents.

Check the Mayor's inbox for messages from:
- Witnesses reporting polecat status
- Refineries reporting merge results
- Polecats requesting help or escalation
- External ...

9. **[closed]** Execute registered plugins
   Execute registered plugins.

Scan ~/gt/plugins/ for plugin directories. Each plugin has a plugin.md with YAML frontmatter defining its gate (when to run) and instructions (what to do).

See docs/deaco...


POLECAT_STARTED beads/dag

Issue: bd-dtl8
Session: gt-beads-dag


SPAWN: nux starting on gt-jzot

Polecat spawn notification.

Polecat: nux
Issue: gt-jzot
Session: gt-gastown-nux
Spawned by: gastown/crew/max

The Deacon will trigger this polecat when Claude is ready (WaitForClaudeReady).
The polecat's SessionStart hook runs gt prime, and work assignment is in its inbox.
Monitor for stuck/idle state after a few minutes.


🤝 HANDOFF: Shared Beads + Mail Fixes

## Session Summary

Fixed gt mail system to work with bd v0.32.0 (mail removed from beads).
Investigated shared beads architecture for eliminating git sync overhead.

## Completed

### gt mail migration (DONE)
- mailbox.go: listBeads() uses bd list --type message
- mailbox.go: getBeads() uses bd show
- mailbox.go: markReadBeads() uses bd close
- mailbox.go: listByThreadBeads() uses bd list --label thread:<id>
- router.go: Send() uses bd create --type message with labels
- types.go: Extract from/thread/reply-to from labels
- Added --pinned flag to gt mail send (blocked by bd bug)

Binary installed at ~/gt/gt

### Beads cleanup (DONE)
- Migrated 63 orphan issues from rig-level to clone beads
- Cleaned gm-* prefix mismatch from town beads (now hq-* only)
- Deleted old handoffs, synced

### Investigation: One Beads Per Rig (READY TO IMPLEMENT)
Architecture validated - will eliminate git sync token burn.

Key findings:
- bd already has redirect support (.beads/redirect file)
- Daemon discovery follows redirects (uses resolved dbPath)
- All agents would connect to same daemon socket
- SQLite WAL + daemon serialization handles concurrency
- No race conditions expected

## Blocking Issues

### gt-zr0a [P1]: bd pin command broken
bd pin <id> fails: invalid field for update: pinned
Nudged dave at gt-beads-crew-dave. Blocks --pinned flag.

## Next Steps: Shared Beads Implementation

1. Create shared .beads/ at rig root (e.g., ~/gt/gastown/.beads/)
2. Update gt spawn to create redirect files:
   mkdir -p polecats/nux/.beads
   echo ../../.beads > polecats/nux/.beads/redirect
3. Test that all polecats connect to same daemon
4. Remove git sync from intra-rig workflow
5. Keep JSONL export for backup/cross-rig only

## Key Files Changed This Session
- gastown/mayor/rig/internal/mail/mailbox.go
- gastown/mayor/rig/internal/mail/router.go
- gastown/mayor/rig/internal/mail/types.go
- gastown/mayor/rig/internal/cmd/mail.go

## Redirect Implementation Reference
~/gt/beads/polecats/rictus/internal/beads/beads.go:45 - followRedirect()

-- Mayor


Session ended: hq-mayor


📋 Work Assignment: Phase 2.1: gt spawn --molecule bonds in ephemeral

Issue: gt-3x0z.4
Title: Phase 2.1: gt spawn --molecule bonds in ephemeral
Priority: P1
Type: task

Description:
Make gt spawn molecule-aware with ephemeral bonding.

## New Flag

```bash
gt spawn --issue gt-xxx --molecule mol-polecat-work
```

## Behavior

1. Create polecat with fresh worktree (existing)
2. Bond molecule in ephemeral: `bd mol bond mol-polecat-work --ephemeral`
3. Link molecule root to source issue
4. Include molecule context in work assignment mail
5. Start session

## Work Assignment Mail

```
Subject: Work Assignment: Fix lifecycle bug [MOLECULE]

You are working on gt-rixa as part of molecule mol-polecat-work.

Molecule instance: eph-abc123
Current step: read-assignment (1/8)

Follow the molecule workflow. When complete, generate summary and squash.
```

## Workflow
1. Run `gt prime` to load polecat context
2. Run `bd sync --from-main` to get fresh beads
3. Work on your task, commit changes regularly
4. Run `bd close <issue-id>` when done
5. Run `bd sync` to push beads changes
6. Push code: `git push origin HEAD`
7. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 19: routine, no incidents


Digest: mol-deacon-patrol

Patrol 20: healthy, all 6 agents running, 4 polecats active


Digest: mol-deacon-patrol

Patrol cycle 4: All healthy.


Digest: mol-deacon-patrol

Patrol 14 complete: all healthy


Digest: mol-deacon-patrol

Patrol 14: routine, all healthy


Digest: mol-deacon-patrol

Patrol 8: all clear


Digest: mol-deacon-patrol

Cycle 80: All healthy, handoff


Digest: mol-deacon-patrol

Patrol C33: All healthy


POLECAT_STARTED rictus

Issue: gt-h1n5
Session: gt-gastown-rictus


Digest: mol-deacon-patrol

Patrol cycle 17: All healthy.


Digest: mol-deacon-patrol

Cycle 12: stable


Digest: mol-deacon-patrol

Patrol 56: All healthy


Digest: mol-deacon-patrol

Patrol 5: routine


Digest: mol-deacon-patrol

Patrol 99: all healthy


Digest: mol-deacon-patrol

Patrol cycle 19: All healthy


Digest: mol-deacon-patrol

Patrol 17: quiet


Digest: mol-deacon-patrol

Patrol cycle 14: Routine


Digest: mol-deacon-patrol

Patrol cycle 18: routine


Digest: mol-deacon-patrol

Patrol cycle 19: all clear


Digest: mol-deacon-patrol

Patrol 1: Inbox 0, Mayor 4 msgs (stale polecat reports from witness), all agents healthy (~50min), no orphans


📋 Work Assignment: Update docs with molecule navigation workflow

Issue: gt-um6q
Title: Update docs with molecule navigation workflow
Priority: P1
Type: task

Description:
Update architecture and workflow docs with new molecule navigation.

## Docs to update

### docs/molecules.md
- Add 'Navigating Molecules' section
- Document bd mol current usage
- Document bd close --continue workflow
- Show the propulsion pattern

### docs/propulsion-principle.md
- Add molecule navigation as key enabler
- Show before/after workflow comparison

### docs/polecat-wisp-architecture.md
- Update step execution section
- Show bd close --continue in examples

## New section content

### Molecule Navigation

Finding your place:
  bd mol current              # Where am I?
  bd mol current gt-abc       # Status of specific molecule

Seamless transitions:
  bd close gt-abc.3 --continue   # Close and advance
  bd close gt-abc.3 --no-auto    # Close but don't auto-claim next

The old way (3 commands):
  bd close gt-abc.3
  bd ready --parent=gt-abc
  bd update gt-abc.4 --status=in_progress

The new way (1 command):
  bd close gt-abc.3 --continue

## Blocked by (Beads features)
- bd-sal9: bd mol current
- bd-ieyy: bd close --continue

## Workflow
1. Run `gt prime` to load polecat context
2. Work on your task, commit changes regularly
3. Run `bd close <issue-id>` when done
4. Run `bd sync` to push beads changes
5. Push code: `git push origin HEAD`
6. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 68


Digest: mol-deacon-patrol

Patrol 17: healthy


Digest: mol-deacon-patrol

Patrol 21: No callbacks, no gates, no pending spawns, all witnesses/refineries healthy, no in_progress issues, clone divergence noted (zoey/jack stopped), context threshold reached


Digest: mol-deacon-patrol

P18: clear


Digest: mol-deacon-patrol

Patrol 5: All clear


Digest: mol-deacon-patrol

Patrol 70: All healthy. No incidents.


Digest: mol-deacon-patrol

Patrol 2 complete: all healthy, no orphans


Digest: mol-deacon-patrol

Patrol cycle 10: all quiet


Digest: mol-deacon-patrol

Patrol 11: All systems healthy


Digest: mol-deacon-patrol

Patrol cycle 14: all healthy, fixed 1 orphan


Digest: mol-deacon-patrol

Patrol cycle 10: closed 3 convoys, health ok, cleaned 13 locks


Digest: mol-deacon-patrol

Patrol 33: routine, all healthy


Digest: mol-deacon-patrol

Patrol 6: All healthy, cleaned 1 orphan session


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.


Digest: mol-deacon-patrol

Patrol cycle 3: routine, all healthy, gastown refinery queue 3


Digest: mol-deacon-patrol

Patrol cycle 17: clean


Digest: mol-deacon-patrol

Patrol C66: routine, all healthy


POLECAT_STARTED capable

Issue: bd-t4u1
Session: gt-beads-capable


Digest: mol-deacon-patrol

Patrol cycle 2: All 3 rigs healthy, gastown refinery +1 pending


Digest: mol-deacon-patrol

Patrol #4: 3 polecats active. All healthy.


Digest: mol-deacon-patrol

Patrol 18: Clean


Digest: mol-deacon-patrol

Patrol 13: All healthy.


Digest: mol-deacon-patrol

Patrol 8


Digest: mol-deacon-patrol

Cycle 77: All healthy


Digest: mol-deacon-patrol

Patrol 3: Routine check, 2 convoys in progress, all agents healthy


Digest: mol-deacon-patrol

Patrol cycle 6: all clear, health ok


🤝 HANDOFF: Tech Debt Epic gt-5n2f (4 done, 7 remaining)

## Current State
Completed 4 issues from tech debt epic gt-5n2f. All changes pushed to main.

## Completed This Session
1. **gt-7sqi** (P2): Extracted getRig() helper in internal/cmd/rig_helpers.go
   - Eliminated duplication across 5 get*Manager functions

2. **gt-ai1z** (P2): Implemented cycle detection in molecule dependencies
   - DFS-based algorithm in internal/beads/molecule.go
   - Added 4 tests for various cycle scenarios

3. **gt-nz6t** (P4): Removed unused style helpers
   - Deleted RenderSuccess/Warning/Error/Info functions

4. **gt-zhm5** (P3): Implemented epic child filtering in witness
   - Added isChildOfEpic() in internal/witness/manager.go
   - Checks if issue blocks configured epic

## Remaining Issues (by priority)

### P2
- **gt-480b**: Improve test coverage (cmd 6.8%, mail 3.6%, daemon 12.1%)
  - Larger task, may want to break into smaller chunks

### P3 - Good next candidates
- **gt-xnql**: Define constants for magic strings ("mayor", "main", "beads-sync", "rigs.json")
- **gt-cvfg**: Use cmd.OutOrStdout in refinery (30+ fmt.Print occurrences)
- **gt-2xsh**: Audit silent error handling (_ = err patterns)
- **gt-2n6z**: Inconsistent error wrapping patterns

### P4
- **gt-92of**: Consider splitting large files (800+ lines)
- **gt-pbr3**: Add godoc comments to exported functions

## Recommended Next Steps
1. Pick a P3 issue (gt-xnql or gt-2xsh are focused)
2. Run `bd show <id>` for details
3. Run `bd update <id> --status=in_progress` to claim
4. After completing, run session end checklist

## Commands
- `bd show gt-5n2f` - View full epic
- `bd ready` - See unblocked work
- `git log --oneline -5` - See recent commits


🤝 HANDOFF: Routine cycle after 20 patrols

All systems healthy. Mayor, 2 Witnesses, 2 Refineries, 2 Crews all running.


Test echo banner

Testing echo format


Digest: mol-deacon-patrol

Patrol 20: final patrol before handoff


Digest: mol-deacon-patrol

Patrol 18: All healthy


Digest: mol-deacon-patrol

Patrol 2: inbox clear, all rigs healthy, no issues


Digest: mol-deacon-patrol

Patrol 94: 4 polecats active


Digest: mol-deacon-patrol

Patrol 20: Final, all healthy


Digest: mol-deacon-patrol

Patrol cycle 9: all clear


Digest: mol-deacon-patrol

Patrol cycle 9: routine


Digest: mol-deacon-patrol

Patrol cycle 3: clean, all agents healthy


Digest: mol-deacon-patrol

Patrol 6: routine


Test: self-mail

Testing crew self-mail


🔍 CODE REVIEW: Wisp simplification (bd-bkul)

## Code Review Needed

The wisp simplification work (bd-bkul) was just completed. Please review for correctness and edge cases.

### Files Changed

1. cmd/bd/mol_squash.go - Removed cross-store squash functions
2. cmd/bd/mol_burn.go - Rewrote to work with main store
3. cmd/bd/mol_bond.go - Updated bondProtoMol signature for dual flags
4. cmd/bd/pour.go - Updated bondProtoMol call
5. internal/beads/beads.go - Deprecated wisp storage functions

### Key Review Points

- Verify squashMolecule() handles wisp children correctly
- Verify mol burn rejects non-wisp molecules
- Verify bond --wisp creates Wisp=true in main store
- Verify bond --pour creates Wisp=false
- Verify JSONL export still skips wisps
- Check edge cases in phase inheritance logic

### Test Commands

bd create "Test wisp" -t task --wisp --json
bd wisp list --json
bd mol bond mol-xxx bd-yyy --wisp --dry-run
bd --no-daemon mol burn <wisp-id> --dry-run


Digest: mol-deacon-patrol

Patrol #5: routine, all healthy


Digest: mol-deacon-patrol

Patrol cycle 7: all agents healthy, no orphans


📋 Work Assignment: TIDY UP: Your previous work (patrol runner) was already m...

Issue: gt-qns0
Title: TIDY UP: Your previous work (patrol runner) was already m...
Priority: P2
Type: task

Description:
TIDY UP: Your previous work (patrol runner) was already merged to main. Check your git status is clean, sync beads, and if nothing to do, just run 'gt done'.

## Workflow
1. Run `gt prime` to load polecat context
2. Run `bd sync --from-main` to get fresh beads
3. Work on your task, commit changes regularly
4. Run `bd close <issue-id>` when done
5. Run `bd sync` to push beads changes
6. Push code: `git push origin HEAD`
7. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 10: all healthy


Session ended: gt-gastown-crew-george


Dog: testdog2


Digest: mol-deacon-patrol

Cycle 7: stable


Digest: mol-deacon-patrol

Patrol cycle 16: all healthy, fixed 1 orphan


Digest: mol-deacon-patrol

Patrol cycle 6: Routine


Digest: mol-deacon-patrol

Patrol 20: Final patrol before handoff


Digest: mol-deacon-patrol

Patrol cycle 8: All healthy.


Digest: mol-deacon-patrol

Patrol 20: Nominal


Digest: mol-deacon-patrol

Patrol 10: routine


📋 Work Assignment: mol-witness-patrol

Issue: gt-87jz
Title: mol-witness-patrol
Priority: P1
Type: epic

Description:
Per-rig worker monitor patrol loop using the Christmas Ornament pattern.

The Witness is the Pit Boss for your rig. You watch polecats, nudge them toward
completion, verify clean git state before kills, and escalate stuck workers.

**You do NOT do implementation work.** Your job is oversight, not coding.

## The Christmas Ornament Shape

This molecule uses dynamic bonding to create inspection arms per-polecat:

```
                    ★ mol-witness-patrol (trunk)
                   /|\
            ┌─────┘ │ └─────┐
         PREFLIGHT DISCOVERY CLEANUP
            │       │        │
        ┌───┴───┐ ┌─┴─┐  ┌───┴───┐
        │inbox  │ │sur│  │aggreg │
        │refnry │ │vey│  │save   │
        │load   │ └─┬─┘  │summary│
        └───────┘   │    │contxt │
                    │    │loop   │
          ┌─────────┼─────────┐ └───────┘
          │         │         │
          ●         ●         ●     mol-polecat-arm (dynamic)
         ace       nux      toast
          │         │         │
       ┌──┴──┐   ┌──┴──┐   ┌──┴──┐
       │cap  │   │cap  │   │cap  │
       │ass  │   │ass  │   │ass  │
       │dec  │   │dec  │   │dec  │
       │exec │   │exec │   │exec │
       └──┬──┘   └──┬──┘   └──┬──┘
          │         │         │
          └─────────┴─────────┘
                    │
                 ⬣ base (cleanup)
```

## Phases

### PREFLIGHT (fixed steps)
1. inbox-check - Process lifecycle requests, help messages
2. check-refinery - Ensure MQ is alive and processing
3. load-state - Read persistent state (nudge counts, etc.)

### DISCOVERY (spawns dynamic arms)
4. survey-workers - List polecats, bond mol-polecat-arm per polecat
5. run-plugins - Bond mol-plugin-runner for each witness plugin

### CLEANUP (gate + fixed steps)
6. aggregate - GATE: WaitsFor all arms + plugins to complete
7. save-state - Persist nudge counts, action log
8. generate-summary - Create digest content
9. context-check - Check if context is high
10. burn-or-loop - Squash/burn wisp, then loop or exit

## Dynamic Arms

Each polecat gets mol-polecat-arm bonded as a wisp child:
- capture - Capture tmux output
- assess - Categorize state (working/idle/error/done)
- load-history - Get nudge counts for this polecat
- decide - Apply nudge matrix
- execute - Take action (nudge/kill/escalate/none)

Arms run in PARALLEL. The aggregate step waits for all to complete.

## Activity Feed

This design enables real-time visibility:

```
[14:32:08] + patrol-x7k.arm-ace bonded (5 steps)
[14:32:09] → patrol-x7k.arm-ace.capture in_progress
[14:32:10] ✓ patrol-x7k.arm-ace.capture completed
[14:32:14] ✓ patrol-x7k.arm-ace.decide completed (action: nudge-1)
[14:32:17] ✓ patrol-x7k.arm-ace COMPLETE
```

## Storage

- Wisp storage: .beads-wisp/ (ephemeral, gitignored)
- Persistent state: witness handoff bead (nudge counts, etc.)
- Digests: Squashed summaries in permanent beads

## Dependencies

- bd-xo1o: Dynamic Molecule Bonding epic (in beads rig)
  - bd mol bond with variable substitution
  - WaitsFor directive for fanout gates
  - Activity feed query

Labels: [template, christmas-ornament]

## Workflow
1. Run `gt prime` to load polecat context
2. Work on your task, commit changes regularly
3. Run `bd close <issue-id>` when done
4. Run `bd sync` to push beads changes
5. Run `gt done` to signal completion (branch stays local)

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 13


POLECAT_STARTED beads/echo

Issue: bd-n386
Session: gt-beads-echo


Digest: mol-deacon-patrol

Patrol cycle 3: inbox clear, gates clear, convoys ongoing, health good, 1 orphan session cleaned


POLECAT_STARTED beads/Compactor

Issue: bd-thgk
Session: gt-beads-Compactor


Digest: mol-deacon-patrol

Patrol 9: All clear


Digest: mol-deacon-patrol

Patrol 97: quiet


Digest: mol-deacon-patrol

Patrol C51: inbox empty, witness/refinery healthy, no callbacks, 176 stale wisps noted


Digest: mol-deacon-patrol

Patrol 19: all healthy


📋 Work Assignment: Implement gt mol status command

Issue: gt-uym5
Title: Implement gt mol status command
Priority: P1
Type: task

Description:
Show what's on an agent's hook.

```bash
gt mol status [target]
```

Output:
- What's slung (molecule name, associated issue)
- Current phase and progress
- Whether it's a wisp
- Next action hint

If no target, shows current agent's status.

Acceptance:
- [ ] Read pinned bead attachment
- [ ] Display molecule/issue info
- [ ] Show phase progress
- [ ] Indicate wisp vs durable

## Workflow
1. Run `gt prime` to load polecat context
2. Run `bd sync --from-main` to get fresh beads
3. Work on your task, commit changes regularly
4. Run `bd close <issue-id>` when done
5. Run `bd sync` to push beads changes
6. Push code: `git push origin HEAD`
7. Run `gt done` to signal completion

## Handoff Protocol
Before signaling done, ensure:
- Git status is clean (no uncommitted changes)
- Issue is closed with `bd close`
- Beads are synced with `bd sync`
- Code is pushed to origin

The `gt done` command verifies these and signals the Witness.


Digest: mol-deacon-patrol

Patrol 3: All healthy, no incidents


Digest: mol-deacon-patrol

Patrol 11: All healthy.


POLECAT_DONE nux

Exit: COMPLETED
Issue: gt-ldk8
MR: gt-z9xv
Branch: polecat/nux


Digest: mol-deacon-patrol

Patrol 9: Auto


Digest: mol-deacon-patrol


Digest: mol-deacon-patrol

Patrol cycle 7: all healthy