diff --git a/.beads/issues.jsonl b/.beads/issues.jsonl
index c07bc732..54f20117 100644
--- a/.beads/issues.jsonl
+++ b/.beads/issues.jsonl
@@ -44,6 +44,7 @@
 {"id":"bd-0qeg","title":"Fix bd doctor hash ID detection for short all-numeric hashes","description":"bd doctor incorrectly flags hash-based IDs as sequential when they are short (3-4 chars) and all-numeric (e.g., pf-158).\n\nRoot cause: isHashID() in cmd/bd/migrate_hash_ids.go:328-358 uses faulty heuristic:\n- For IDs \u003c 5 chars, only returns true if contains letters\n- But base36 hash IDs can be 3+ chars and all-numeric (MinLength: 3)\n- Example: pf-158 is valid hash ID but flagged as sequential\n\nFix: Check multiple IDs (10-20 samples) instead of single-ID pattern matching:\n- Sample IDs across database \n- Check majority pattern (sequential vs hash format)\n- Sequential: 1-4 digits (bd-1, bd-2...)\n- Hash: 3-8 chars base36 (pf-158, pf-3s9...)\n\nImpact: False positive warnings in bd doctor output","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-11-16T13:45:20.733761-08:00","updated_at":"2025-11-16T14:27:48.143485-08:00","closed_at":"2025-11-16T14:27:48.143485-08:00"}
 {"id":"bd-0qx5","title":"Implement Jira issue timestamp comparison for sync","description":"In cmd/bd/jira.go:633, there's a TODO for a full implementation that would fetch the Jira issue and compare timestamps to detect conflicts during sync.\n\nFile: cmd/bd/jira.go:633","status":"closed","priority":4,"issue_type":"feature","created_at":"2025-12-28T16:32:52.601594-08:00","created_by":"stevey","updated_at":"2025-12-30T18:12:30.977631-08:00","closed_at":"2025-12-30T16:00:07.968921-08:00","close_reason":"Implemented Jira timestamp comparison for sync. Added fetchJiraIssueTimestamp() to fetch timestamps from Jira REST API, updated detectJiraConflicts() to compare actual timestamps, and improved conflict resolution functions to display timestamp details."}
 {"id":"bd-0sgd","title":"Design escalation inbox for stuck workflows","description":"## Summary\n\nExtend the existing `gt escalate` system with tiered routing, structured decision patterns, and integration with gates and patrol lifecycles.\n\n## Background\n\nFrom gate design discussion and workflow analysis. Gas Town needs:\n1. Structured way for workers to request decisions (not just free-form escalation)\n2. Tiered routing (Deacon -\u003e Mayor -\u003e Overseer) instead of direct-to-human\n3. Integration with gates (timeout -\u003e escalate)\n4. Formalized patterns for all worker exit scenarios\n\n## Current State (what exists)\n\nThe escalation system is already partially built:\n\n- `gt escalate` command: CRITICAL/HIGH/MEDIUM severity\n- Creates bead tagged `escalation`\n- Sends mail to `overseer`\n- Mayor checks pending escalations on `gt prime`\n- Exit type `ESCALATED` for polecats\n- Event logging: `escalation_sent`\n\nSee: `gastown/docs/escalation.md`\n\n## What's Missing\n\n| Gap | Current | Proposed |\n|-----|---------|----------|\n| Tiered routing | Direct to overseer | Deacon -\u003e Mayor -\u003e Overseer |\n| Decision pattern | Free-form topic | Structured options in issue |\n| Categories | Just \"escalation\" tag | decision, help, blocked, failed, emergency |\n| Gate integration | None | Gate timeout -\u003e escalate |\n| Patrol integration | Ad-hoc | Formalized paths |\n\n## Design\n\n### Escalation Categories\n\n| Category | Description | Default Destination |\n|----------|-------------|---------------------|\n| `decision` | Multiple valid paths, need choice | Deacon -\u003e Mayor |\n| `help` | Need guidance/expertise | Deacon -\u003e Mayor |\n| `blocked` | Waiting on unresolvable dependency | Mayor |\n| `failed` | Unexpected error, can't proceed | Deacon |\n| `emergency` | Security/data integrity | Overseer (direct) |\n| `gate_timeout` | Gate didn't resolve in time | Deacon |\n| `lifecycle` | Worker stuck/needs recycle | Witness |\n\n### Extended Command\n\n```bash\n# Current (unchanged)\ngt escalate \"Something went wrong\"\ngt escalate -s CRITICAL \"Data corruption\"\n\n# New: Category-based\ngt escalate --type decision \"Which auth approach?\"\ngt escalate --type help \"Need architecture guidance\"\ngt escalate --type blocked \"Waiting on bd-xyz\"\ngt escalate --type failed \"Tests failing unexpectedly\"\ngt escalate --type emergency \"Security vulnerability found\"\n\n# New: Tiered routing\ngt escalate --to deacon \"Infra issue\"\ngt escalate --to mayor \"Cross-rig coordination needed\"\ngt escalate --to overseer \"Human judgment required\"\n\n# New: Structured decision\ngt escalate --type decision \\\n  --question \"Which authentication approach?\" \\\n  --options \"JWT tokens,Session cookies,OAuth2\" \\\n  --context \"Admin panel needs login\" \\\n  --issue bd-xyz\n```\n\n### Decision Pattern in Issues\n\nWhen `--type decision` is used, the issue is updated with structured format:\n\n```markdown\n## Decision Needed\n\n**Question:** Which authentication approach?\n\n| Option | Description |\n|--------|-------------|\n| A | JWT tokens |\n| B | Session cookies |\n| C | OAuth2 |\n\n**Context:** Admin panel needs login\n\n**Escalated by:** beads/polecats/obsidian\n**Escalated at:** 2026-01-01T15:00:00Z\n\n**To resolve:**\n1. Comment with chosen option (e.g., \"Decision: A\")\n2. Reassign to work queue or original worker\n```\n\nThis makes the issue the async communication channel for decisions.\n\n### Tiered Escalation Flow\n\n```\nWorker encounters issue\n    |\n    v\ngt escalate --type \u003ccategory\u003e --to \u003ctier\u003e\n    |\n    v\n[Deacon receives]\n    |\n    +-- Can resolve? --\u003e Updates issue, re-slings work\n    |\n    +-- Cannot resolve? --\u003e gt escalate --to mayor --forward\n                                |\n                                v\n                           [Mayor receives]\n                                |\n                                +-- Can resolve? --\u003e Updates issue, re-slings\n                                |\n                                +-- Cannot resolve? --\u003e gt escalate --to overseer\n                                                            |\n                                                            v\n                                                       [Overseer resolves]\n```\n\nEach tier can resolve OR forward. The escalation bead tracks the chain via comments/notes.\n\n### Integration Points\n\n#### Gate Timeouts (bd-7zka.2)\n\n```go\n// In Witness patrol (timer gates)\nif gate.Expired() {\n    exec.Command(\"gt\", \"escalate\",\n        \"--type\", \"gate_timeout\",\n        \"--severity\", \"HIGH\",\n        \"--issue\", gate.BlockedIssueID,\n        fmt.Sprintf(\"Gate %s timed out after %s\", gate.ID, gate.Timeout)).Run()\n}\n```\n\n#### Witness Patrol\n\nWitness already detects stuck polecats. Formalize as escalation:\n\n```go\n// Instead of ad-hoc mail\nexec.Command(\"gt\", \"escalate\",\n    \"--type\", \"lifecycle\",\n    \"--to\", \"mayor\",\n    \"--issue\", polecat.CurrentIssue,\n    fmt.Sprintf(\"Polecat %s stuck: no progress for %d minutes\", polecat.ID, minutes)).Run()\n```\n\n#### Refinery\n\nOn merge failures that can't be auto-resolved:\n\n```go\nexec.Command(\"gt\", \"escalate\",\n    \"--type\", \"failed\",\n    \"--issue\", mr.IssueID,\n    \"Merge failed: \"+reason).Run()\n```\n\n### Polecat Exit with Escalation\n\n```bash\n# Worker reaches decision point\n\n# 1. Update issue with decision structure\nbd update $ISSUE --notes \"$(cat \u003c\u003cEOF\n## Decision Needed\n\n**Question:** Which approach for caching?\n\n| Option | Description |\n|--------|-------------|\n| A | Redis (external dependency) |\n| B | In-memory (simpler, no persistence) |\n| C | SQLite (local persistence) |\n\n**Context:** API response times are slow, need caching layer.\nEOF\n)\"\n\n# 2. Escalate\ngt escalate --type decision --issue $ISSUE \"Caching approach needs decision\"\n\n# 3. Exit cleanly\ngt done --exit ESCALATED\n```\n\n### New Issue Statuses\n\nConsider adding to beads:\n\n| Status | Meaning |\n|--------|---------|\n| `decision_needed` | Waiting for decision from escalation |\n| `escalated` | General escalation pending |\n\nOr keep using `blocked` with escalation tag - simpler.\n\n## Implementation Plan\n\n### Phase 1: Extend gt escalate\n- Add `--type` flag for categories\n- Add `--to` flag for routing (deacon, mayor, overseer)\n- Add `--forward` flag for tier forwarding\n- Keep backward compatibility\n\n### Phase 2: Decision Pattern\n- Add `--question`, `--options`, `--context` flags\n- Auto-update issue with decision structure\n- Parse decision from issue comments on resolution\n\n### Phase 3: Gate Integration\n- Add `gate_timeout` escalation type\n- Witness: check timer gates, escalate on timeout\n- Refinery: check GH gates, escalate on timeout/failure\n\n### Phase 4: Patrol Integration\n- Formalize Witness stuck-polecat as escalation\n- Formalize Refinery merge-failure as escalation\n- Unified escalation handling in Mayor\n\n## Acceptance Criteria\n\n- [ ] `gt escalate --type decision` creates structured issue update\n- [ ] `gt escalate --to deacon|mayor|overseer` routes correctly\n- [ ] Gate timeouts trigger escalation (after bd-7zka.2)\n- [ ] Witness uses escalation for stuck polecats\n- [ ] Refinery uses escalation for merge failures\n- [ ] Escalation chain tracked in bead (who forwarded to whom)\n- [ ] `bd list --tag=escalation --type=decision` filters work\n\n## References\n\n- bd-7zka.2: Gate evaluation (uses escalation for timeouts)\n- gastown/docs/escalation.md: Current escalation protocol\n- gastown/crew/max/internal/cmd/escalate.go: Current implementation","notes":"## Design Complete\n\nThe extended escalation design has been documented in gastown/docs/escalation.md.\n\n**Key design decisions:**\n1. Categories map to default routing tiers\n2. Decision pattern uses issue notes as async communication channel\n3. Gate integration via --type gate_timeout\n4. Lifecycle escalations formalized for Witness/Refinery\n\n**Implementation phases defined:**\n- Phase 1: Extend gt escalate command\n- Phase 2: Add decision pattern flags\n- Phase 3: Gate integration\n- Phase 4: Patrol integration\n\nThe acceptance criteria in this issue describe implementation, not design. Those will be verified when the implementation issues are completed.","status":"closed","priority":2,"issue_type":"feature","assignee":"beads/polecats/quartz","created_at":"2026-01-01T15:03:37.684701-08:00","created_by":"beads/crew/fang","updated_at":"2026-01-01T16:14:14.115179-08:00","closed_at":"2026-01-01T16:14:14.115179-08:00","close_reason":"Design documented in gastown/docs/escalation.md. Implementation issues to follow."}
+{"id":"bd-0t8ak","title":"Session ended: gt-beads-crew-wolf","status":"closed","priority":2,"issue_type":"event","created_at":"2026-01-08T14:37:26.15333-08:00","created_by":"beads/crew/wolf","updated_at":"2026-01-08T14:37:26.187302-08:00","closed_at":"2026-01-08T14:37:26.187302-08:00","close_reason":"auto-closed session event"}
 {"id":"bd-0v4","title":"Short tests taking 13+ minutes (performance regression)","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-27T00:54:03.350344-08:00","updated_at":"2025-11-27T13:23:19.376658-08:00","closed_at":"2025-11-27T01:36:06.684059-08:00"}
 {"id":"bd-0vfe","title":"Blocked issue","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-07T19:07:17.105974-08:00","updated_at":"2025-11-07T22:07:17.342098-08:00","closed_at":"2025-11-07T21:55:09.425545-08:00"}
 {"id":"bd-0vg","title":"Pinned issues: persistent context markers","description":"Add ability to pin issues so they remain visible and are excluded from work-finding commands. Pinned issues serve as persistent context markers (handoffs, architectural notes, recovery instructions) that should not be claimed as work items.\n\nUse Cases:\n1. Handoff messages - Pin session handoffs so new agents always see them\n2. Architecture decisions - Pin ADRs or design notes for reference  \n3. Recovery context - Pin amnesia-cure notes that help agents orient\n\nCore commands: bd pin, bd unpin, bd list --pinned/--no-pinned","status":"closed","priority":1,"issue_type":"epic","created_at":"2025-12-18T23:33:10.911092-08:00","updated_at":"2025-12-21T11:30:28.989696-08:00","closed_at":"2025-12-21T11:30:28.989696-08:00"}