diff --git a/.beads/formulas/mol-polecat-basic.formula.toml b/.beads/formulas/mol-polecat-basic.formula.toml
deleted file mode 100644
index ad08c543..00000000
--- a/.beads/formulas/mol-polecat-basic.formula.toml
+++ /dev/null
@@ -1,89 +0,0 @@
-description = """
-Minimal polecat workflow for trivial fixes.
-
-Use this for P4 backlog items, typo fixes, and simple changes that don't
-require design review or extensive testing. Just get it done.
-
-## When to Use
-- Typo fixes
-- Simple config changes
-- Obvious bug fixes
-- Documentation updates
-- P4 priority items
-
-## When NOT to Use
-- New features (use shiny or chrome)
-- Security-related changes (use chrome)
-- Complex refactoring (use shiny)
-- Anything P1 or P0 (use chrome)
-"""
-formula = "mol-polecat-basic"
-type = "workflow"
-version = 1
-
-[[steps]]
-id = "preflight"
-title = "Quick preflight check"
-description = """
-Fast initialization - just enough to start working.
-
-```bash
-gt prime                    # Load context
-gt mol status               # Check your hook
-bd show {{issue}}           # Understand the task
-```
-
-Verify you understand what needs to be done. If unclear, ask.
-
-**Exit criteria:** You know what to do."""
-
-[[steps]]
-id = "implement"
-title = "Implement {{feature}}"
-needs = ["preflight"]
-description = """
-Just do it. Keep it simple.
-
-1. Make the change
-2. Test it works locally
-3. Commit with clear message:
-
-```bash
-git add <files>
-git commit -m "fix: <description> ({{issue}})"
-```
-
-Don't overthink. Don't gold-plate. Don't scope-creep.
-
-**Exit criteria:** Change implemented and committed."""
-
-[[steps]]
-id = "postflight"
-title = "Submit and signal done"
-needs = ["implement"]
-description = """
-Push and signal completion.
-
-```bash
-# Quick test
-go test ./...               # Must pass
-
-# Push
-git push -u origin $(git branch --show-current)
-
-# Close issue
-bd close {{issue}} --reason "Fixed"
-bd sync
-
-# Signal done
-gt done
-```
-
-**Exit criteria:** Witness takes over from here."""
-
-[vars]
-[vars.issue]
-description = "The issue ID assigned to this polecat"
-required = true
-[vars.feature]
-description = "Brief description of what's being fixed"
diff --git a/.beads/formulas/mol-polecat-chrome.formula.toml b/.beads/formulas/mol-polecat-chrome.formula.toml
deleted file mode 100644
index f8eb747d..00000000
--- a/.beads/formulas/mol-polecat-chrome.formula.toml
+++ /dev/null
@@ -1,453 +0,0 @@
-description = """
-Maximum rigor polecat workflow with deep context and triple review.
-
-Chrome is for critical work where quality is paramount. Every phase is
-decomposed into checkable atoms. Reviews are done three times. Context
-is explicitly loaded before design begins.
-
-## When to Use
-- P0/P1 priority issues
-- Security-sensitive changes
-- Core architecture work
-- Public API changes
-- Anything that could break production
-
-## Phases
-1. **Deep Context** - Read strategic docs before starting
-2. **Design** - Draft, review, finalize
-3. **Implement** - Scaffold, core, edge cases
-4. **Test** - Write, run, review
-5. **Triple Review** - Three passes over the code
-6. **Final** - Docs, cleanup, submit
-"""
-formula = "mol-polecat-chrome"
-type = "workflow"
-version = 1
-
-# =============================================================================
-# PHASE 1: DEEP CONTEXT
-# =============================================================================
-
-[[steps]]
-id = "preflight"
-title = "Load basic context"
-description = """
-Standard initialization.
-
-```bash
-gt prime                    # Load role context
-bd prime                    # Load beads context
-gt mol status               # Check your hook
-bd show {{issue}}           # Full issue details
-gt mail inbox               # Check for additional context
-```
-
-**Exit criteria:** Session initialized, issue understood."""
-
-[[steps]]
-id = "read-strategic-context"
-title = "Read strategic context documents"
-needs = ["preflight"]
-description = """
-CRITICAL: Read the strategic context before designing.
-
-These documents contain the vision, principles, and architectural decisions
-that should guide your implementation. Do not skip this step.
-
-**1. Read CONTEXT.md:**
-```bash
-cat ~/gt/docs/hop/CONTEXT.md
-```
-This contains:
-- Strategic vision
-- Design principles
-- What we're building and why
-
-**2. Read PRIMING.md:**
-```bash
-cat ~/gt/docs/PRIMING.md
-```
-This contains:
-- Role taxonomy
-- Agent responsibilities
-- System architecture
-
-**3. Absorb and consider:**
-- How does {{feature}} fit the strategic vision?
-- What principles apply to this work?
-- Are there architectural constraints to respect?
-
-Take notes if helpful. This context shapes your design.
-
-**Exit criteria:** You understand the strategic context and how it applies."""
-
-# =============================================================================
-# PHASE 2: DESIGN (Draft -> Review -> Finalize)
-# =============================================================================
-
-[[steps]]
-id = "design-draft"
-title = "Draft design for {{feature}}"
-needs = ["read-strategic-context"]
-description = """
-Create an initial design based on strategic context.
-
-Write a design document (can be comments, markdown, or mental model):
-
-1. **Problem Statement**: What exactly are we solving?
-2. **Approach**: How will we solve it?
-3. **Files to Modify**: What code changes?
-4. **Dependencies**: What does this depend on?
-5. **Risks**: What could go wrong?
-6. **Alternatives Considered**: What else could we do?
-
-Be specific. Reference the strategic context where relevant.
-
-**Exit criteria:** Draft design exists."""
-
-[[steps]]
-id = "design-review"
-title = "Review your design"
-needs = ["design-draft"]
-description = """
-Step back and critically review your draft design.
-
-Questions to ask:
-- Does this align with the strategic vision from CONTEXT.md?
-- Is this the simplest solution that works?
-- Have I considered all edge cases?
-- What would break if my assumptions are wrong?
-- Is this consistent with existing patterns in the codebase?
-- Would another engineer understand this approach?
-
-Look for:
-- Over-engineering
-- Missing edge cases
-- Inconsistency with existing code
-- Scope creep beyond {{issue}}
-
-Revise the design based on this review.
-
-**Exit criteria:** Design reviewed and improved."""
-
-[[steps]]
-id = "design-finalize"
-title = "Finalize design"
-needs = ["design-review"]
-description = """
-Lock in the design before implementation.
-
-Final checklist:
-- [ ] Approach is clear and justified
-- [ ] All files to modify are identified
-- [ ] Risks are acknowledged
-- [ ] Success criteria are defined
-- [ ] Design is consistent with strategic context
-
-If you're uncertain about anything, now is the time to ask Witness:
-```bash
-gt mail send <rig>/witness -s "Design review: {{issue}}" -m "..."
-```
-
-Once finalized, commit to this design. Don't redesign mid-implementation.
-
-**Exit criteria:** Design is final, ready to implement."""
-
-# =============================================================================
-# PHASE 3: IMPLEMENT (Scaffold -> Core -> Edge Cases)
-# =============================================================================
-
-[[steps]]
-id = "implement-scaffold"
-title = "Scaffold the structure"
-needs = ["design-finalize"]
-description = """
-Create the skeleton before filling in logic.
-
-1. Create new files if needed
-2. Add function signatures with TODO bodies
-3. Set up imports and dependencies
-4. Add test file stubs
-
-```bash
-git add <files>
-git commit -m "scaffold: structure for {{feature}} ({{issue}})"
-```
-
-This should compile/parse but not work yet.
-
-**Exit criteria:** Structure exists, compiles, ready for core logic."""
-
-[[steps]]
-id = "implement-core"
-title = "Implement core logic"
-needs = ["implement-scaffold"]
-description = """
-Fill in the happy path - the main functionality.
-
-Focus on:
-- Primary use case working correctly
-- Clear, readable code
-- Following existing patterns
-
-Don't worry about edge cases yet. Get the core working first.
-
-```bash
-git add <files>
-git commit -m "feat: core logic for {{feature}} ({{issue}})"
-```
-
-**Exit criteria:** Core functionality works for the happy path."""
-
-[[steps]]
-id = "implement-edge-cases"
-title = "Handle edge cases"
-needs = ["implement-core"]
-description = """
-Now handle the edge cases identified in design.
-
-For each edge case:
-1. Add the handling code
-2. Add a test for it
-3. Verify it works
-
-Common edge cases:
-- Empty/nil inputs
-- Boundary conditions
-- Error conditions
-- Concurrent access (if applicable)
-
-```bash
-git add <files>
-git commit -m "feat: edge case handling for {{feature}} ({{issue}})"
-```
-
-**Exit criteria:** All known edge cases handled."""
-
-# =============================================================================
-# PHASE 4: TEST (Write -> Run -> Review)
-# =============================================================================
-
-[[steps]]
-id = "test-write"
-title = "Write comprehensive tests"
-needs = ["implement-edge-cases"]
-description = """
-Write tests for all new code.
-
-Test categories:
-1. **Unit tests** - Test individual functions
-2. **Integration tests** - Test component interaction
-3. **Regression tests** - Prevent the bug from recurring
-
-Coverage goals:
-- Happy path tested
-- Each edge case tested
-- Error conditions tested
-- Boundary conditions tested
-
-```bash
-git add *_test.go
-git commit -m "test: add tests for {{feature}} ({{issue}})"
-```
-
-**Exit criteria:** Comprehensive test coverage for new code."""
-
-[[steps]]
-id = "test-run"
-title = "Run full test suite"
-needs = ["test-write"]
-description = """
-Run ALL tests, not just your new ones.
-
-```bash
-go test ./...               # Full test suite
-go build ./...              # Build check
-```
-
-**ALL TESTS MUST PASS.**
-
-If tests fail:
-- Your code broke something: FIX IT
-- Pre-existing failure: file bead, but still need green
-
-Do not proceed until all tests pass.
-
-**Exit criteria:** Full test suite passes."""
-
-[[steps]]
-id = "test-review"
-title = "Review test coverage"
-needs = ["test-run"]
-description = """
-Verify tests are actually meaningful.
-
-Check each test:
-- Does it test real behavior, not implementation details?
-- Could a bug slip past this test?
-- Are assertions specific enough?
-
-Look for:
-- Missing negative tests (what should NOT happen)
-- Missing boundary tests
-- Tests that always pass (useless)
-- Tests that test mocks instead of real code
-
-Add any missing tests.
-
-**Exit criteria:** Tests are comprehensive and meaningful."""
-
-# =============================================================================
-# PHASE 5: TRIPLE REVIEW
-# =============================================================================
-
-[[steps]]
-id = "code-review-1"
-title = "Code review pass 1: Correctness"
-needs = ["test-review"]
-description = """
-First review pass: Is the code CORRECT?
-
-```bash
-git diff origin/main...HEAD
-```
-
-Focus on:
-- Logic errors
-- Off-by-one bugs
-- Null pointer risks
-- Race conditions
-- Resource leaks
-- Error handling gaps
-
-For each issue found: FIX IT, don't just note it.
-
-**Exit criteria:** No correctness issues remain."""
-
-[[steps]]
-id = "code-review-2"
-title = "Code review pass 2: Security"
-needs = ["code-review-1"]
-description = """
-Second review pass: Is the code SECURE?
-
-Review for OWASP Top 10:
-- Injection (SQL, command, path)
-- Broken authentication
-- Sensitive data exposure
-- XXE
-- Broken access control
-- Security misconfiguration
-- XSS
-- Insecure deserialization
-- Using components with known vulnerabilities
-- Insufficient logging
-
-Also check:
-- Secrets not hardcoded
-- Input validation
-- Output encoding
-- Proper error messages (don't leak info)
-
-**Exit criteria:** No security issues remain."""
-
-[[steps]]
-id = "code-review-3"
-title = "Code review pass 3: Quality"
-needs = ["code-review-2"]
-description = """
-Third review pass: Is the code QUALITY?
-
-Check:
-- Naming: Are names clear and consistent?
-- Structure: Is code well-organized?
-- Comments: Are complex parts explained?
-- DRY: Is there unnecessary duplication?
-- SOLID: Are principles followed?
-- Patterns: Does it match codebase conventions?
-- Cruft: Any debug code, TODOs, dead code?
-
-The code should be something you're proud of.
-
-**Exit criteria:** Code is clean, maintainable, follows conventions."""
-
-# =============================================================================
-# PHASE 6: FINAL
-# =============================================================================
-
-[[steps]]
-id = "docs-update"
-title = "Update documentation"
-needs = ["code-review-3"]
-description = """
-Update any affected documentation.
-
-Check:
-- README if user-facing changes
-- Code comments for complex logic
-- API docs if interfaces changed
-- CHANGELOG if applicable
-
-```bash
-git add docs/ *.md
-git commit -m "docs: update for {{feature}} ({{issue}})"
-```
-
-**Exit criteria:** Documentation reflects the changes."""
-
-[[steps]]
-id = "final-check"
-title = "Final pre-submit check"
-needs = ["docs-update"]
-description = """
-One last verification before submit.
-
-```bash
-# Clean state
-git status                  # Must be clean
-git stash list              # Must be empty
-
-# Tests still pass
-go test ./...
-
-# Review commit history
-git log --oneline origin/main..HEAD
-
-# Review final diff
-git diff origin/main...HEAD --stat
-```
-
-If anything is wrong, fix it before proceeding.
-
-**Exit criteria:** Everything is perfect."""
-
-[[steps]]
-id = "postflight"
-title = "Submit for merge"
-needs = ["final-check"]
-description = """
-Push and signal completion.
-
-```bash
-# Push branch
-git push -u origin $(git branch --show-current)
-
-# Close issue with summary
-bd close {{issue}} --reason "Implemented with chrome workflow: {{feature}}"
-bd sync
-
-# Signal done
-gt done
-```
-
-Witness will verify, send to merge queue, and terminate your session.
-
-**Exit criteria:** Witness takes over from here."""
-
-[vars]
-[vars.issue]
-description = "The issue ID assigned to this polecat"
-required = true
-[vars.feature]
-description = "The feature being implemented"
-required = true
diff --git a/.beads/formulas/mol-polecat-shiny.formula.toml b/.beads/formulas/mol-polecat-shiny.formula.toml
deleted file mode 100644
index 095b9dee..00000000
--- a/.beads/formulas/mol-polecat-shiny.formula.toml
+++ /dev/null
@@ -1,178 +0,0 @@
-description = """
-Standard quality polecat workflow with design and review phases.
-
-Engineer in a Box - the canonical right way for most work. Design before you
-code. Review before you ship. Test before you submit.
-
-## When to Use
-- P2/P3 features and bugs
-- New functionality
-- Refactoring work
-- Any non-trivial change
-
-## Phases
-1. **Preflight** - Load context, understand assignment
-2. **Design** - Think before you code
-3. **Implement** - Write the code
-4. **Review** - Self-review your changes
-5. **Test** - Run tests, verify coverage
-6. **Postflight** - Submit and signal done
-"""
-formula = "mol-polecat-shiny"
-type = "workflow"
-version = 1
-
-[[steps]]
-id = "preflight"
-title = "Load context and verify assignment"
-description = """
-Initialize your session and understand your assignment.
-
-```bash
-gt prime                    # Load role context
-bd prime                    # Load beads context
-gt mol status               # Check your hook
-bd show {{issue}}           # Full issue details
-gt mail inbox               # Check for additional context
-```
-
-Understand:
-- What exactly needs to be done?
-- What files are likely involved?
-- Are there dependencies or blockers?
-- What does "done" look like?
-
-If blocked or unclear, mail Witness immediately.
-
-**Exit criteria:** You understand the work and can begin."""
-
-[[steps]]
-id = "design"
-title = "Design {{feature}}"
-needs = ["preflight"]
-description = """
-Think carefully about architecture BEFORE writing code.
-
-Consider:
-- How does this fit into the existing system?
-- What are the edge cases?
-- What could go wrong?
-- Is there a simpler approach?
-- What existing patterns should you follow?
-
-Write a brief design note (can be in your head or as a comment):
-- Approach: <how you'll solve it>
-- Files: <what you'll modify>
-- Risks: <what might go wrong>
-
-**Exit criteria:** You have a clear plan before touching code."""
-
-[[steps]]
-id = "implement"
-title = "Implement {{feature}}"
-needs = ["design"]
-description = """
-Write the code following your design.
-
-Working principles:
-- Follow existing codebase conventions
-- Make atomic, focused commits
-- Keep changes scoped to the assigned issue
-- Don't gold-plate or scope-creep
-
-```bash
-# Commit frequently:
-git add <files>
-git commit -m "<type>: <description> ({{issue}})"
-```
-
-If you find unrelated bugs, file a bead - don't fix them in this branch.
-
-**Exit criteria:** Implementation complete, all changes committed."""
-
-[[steps]]
-id = "review"
-title = "Review implementation"
-needs = ["implement"]
-description = """
-Self-review your changes before running tests.
-
-```bash
-git diff origin/main...HEAD     # All changes vs main
-git log --oneline origin/main..HEAD  # All commits
-```
-
-Check for:
-| Category | Look For |
-|----------|----------|
-| Bugs | Off-by-one, null handling, edge cases |
-| Security | Injection, auth bypass, exposed secrets |
-| Style | Naming, formatting, code organization |
-| Completeness | Missing error handling, incomplete paths |
-| Cruft | Debug prints, commented code, TODOs |
-
-Fix issues found - don't just note them.
-
-**Exit criteria:** Changes are clean and ready for testing."""
-
-[[steps]]
-id = "test"
-title = "Test {{feature}}"
-needs = ["review"]
-description = """
-Run tests and verify coverage.
-
-```bash
-go test ./...               # Full test suite
-```
-
-**ALL TESTS MUST PASS.** Do not proceed with failures.
-
-If tests fail:
-- Read the failure carefully
-- If your change caused it: fix it
-- If pre-existing: file a bead, but you still need green tests
-
-New features should have tests. Bug fixes should have regression tests.
-
-```bash
-# Build check
-go build ./...
-```
-
-**Exit criteria:** All tests pass, new code has appropriate coverage."""
-
-[[steps]]
-id = "postflight"
-title = "Submit for merge"
-needs = ["test"]
-description = """
-Clean up and submit.
-
-```bash
-# Verify clean state
-git status                  # Should be clean
-git stash list              # Should be empty
-
-# Push branch
-git push -u origin $(git branch --show-current)
-
-# Close issue
-bd close {{issue}} --reason "Implemented: {{feature}}"
-bd sync
-
-# Signal done
-gt done
-```
-
-Witness will verify, send to merge queue, and terminate your session.
-
-**Exit criteria:** Witness takes over from here."""
-
-[vars]
-[vars.issue]
-description = "The issue ID assigned to this polecat"
-required = true
-[vars.feature]
-description = "The feature being implemented"
-required = true