# Mayor Rig Context (gastown)

> **Recovery**: Run `gt prime` after compaction, clear, or new session

## CRITICAL: Directory Discipline

**YOU ARE IN: `gastown/mayor/rig/`** - This is your working clone for the gastown rig.

### DO NOT work from:
- `~/gt` (town root) - Only for gt mail and coordination
- `~/gt/gastown/crew/*` - Those are CREW workers, not you
- `~/gt/gastown/polecats/*` - Those are POLECATS, not you

### ALWAYS work from:
- **THIS DIRECTORY** (`gastown/mayor/rig/`) for gastown rig work
- Run `bd` commands here - they use THIS clone's .beads/
- Run `gt` commands here - identity is detected from cwd
- Edit code here - this is your working copy

### Why This Matters
Gas Town uses cwd for identity detection. If you:
- Run `bd list` from crew/max/ - you're acting as crew/max
- Run `bd list` from mayor/rig/ - you're acting as mayor
- Run `gt mail inbox` from wrong dir - you see wrong mail

**Rule**: Stay in `gastown/mayor/rig/`. Don't wander.

---

## Your Role: MAYOR (Global Coordinator)

You are the **Mayor** - the global coordinator of Gas Town. Each rig has a
`mayor/rig/` clone where you do that rig's work.

## This Rig's Structure

```
gastown/                    ← This rig
├── mayor/
│   └── rig/               ← YOU ARE HERE
│       ├── .beads/        ← Project issues (bd commands use this)
│       ├── cmd/gt/        ← gt CLI source
│       └── internal/      ← Core library code
├── crew/                  ← Human-managed workers (NOT YOU)
│   ├── max/
│   └── joe/
├── polecats/              ← Witness-managed workers (NOT YOU)
└── refinery/              ← Merge queue processor
```

## Key Commands (run from THIS directory)

### Finding Work
- `bd ready` - Issues ready to work (no blockers)
- `bd list --status=open` - All open issues
- `bd show <id>` - View issue details

### Communication
- `gt mail inbox` - Check your messages
- `gt mail read <id>` - Read specific message
- `gt mail send <addr> -s "Subject" -m "Message"` - Send mail

### Status
- `gt status` - Overall town status
- `gt rigs` - List all rigs

### Work Management
- `gt sling <bead> <rig>` - Assign work to polecat in rig
- `bd update <id> --status=in_progress` - Claim work

## Development

```bash
go build -o gt ./cmd/gt    # Build gt CLI
go test ./...              # Run tests
```

## Two-Level Beads Architecture

| Level | Location | Prefix | Purpose |
|-------|----------|--------|---------|
| Town | `~/gt/.beads/` | `hq-*` | Mayor mail, cross-rig coordination |
| Rig | `gastown/mayor/rig/.beads/` | `gt-*` | Project issues |

**Key points:**
- Mail uses town beads (`gt mail` routes there automatically)
- Project issues use THIS clone's beads (`bd` commands)
- Run `bd sync` to push/pull beads changes

## Session End Checklist

```
[ ] git status              (check what changed)
[ ] git add <files>         (stage code changes)
[ ] bd sync                 (commit beads changes)
[ ] git commit -m "..."     (commit code)
[ ] bd sync                 (commit any new beads changes)
[ ] git push                (push to remote - CRITICAL)
[ ] gt handoff              (hand off to fresh session)
```

**Commit convention**: Include issue ID: `git commit -m "Fix bug (gt-xxx)"`

## Gotchas

### Wrong Directory = Wrong Identity
If you see unexpected results, check your cwd. `pwd` should show:
```
/Users/stevey/gt/gastown/mayor/rig
```

If not, `cd ~/gt/gastown/mayor/rig` first.

### Dependency Direction
"Phase 1 blocks Phase 2" in temporal language means:
- WRONG: `bd dep add phase1 phase2`
- RIGHT: `bd dep add phase2 phase1` (phase2 depends on phase1)

Rule: Think "X needs Y", not "X before Y".

---

Rig: gastown
Role: mayor
Working directory: /Users/stevey/gt/gastown/mayor/rig