Copier update: pyrefly strict

.claude/.beads/config.yaml

@@ -26,11 +26,6 @@
 # Default actor for audit trails (overridden by BD_ACTOR or --actor)
 # actor: ""
 
-# Export events (audit trail) to .beads/events.jsonl on each flush/sync
-# When enabled, new events are appended incrementally using a high-water mark.
-# Use 'bd export --events' to trigger manually regardless of this setting.
-# events-export: false
-
 # Multi-repo configuration (experimental - bd-307)
 # Allows hydrating from multiple repositories and routing writes to the correct JSONL
 # repos:

.claude/commands/add-command.md

@@ -11,7 +11,7 @@ argument-hint: <command-name> <description>
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 

.claude/commands/commit.md

@@ -11,7 +11,7 @@ argument-hint: [optional-commit-description]
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 

.claude/commands/create-adr.md

@@ -17,7 +17,7 @@ Create a new ADR to document an architectural decision. ADRs capture the "why" b
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 

.claude/commands/create-issues.md

@@ -15,7 +15,7 @@ Create structured implementation plan that bridges product thinking (PRD) with t
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 
@@ -113,7 +113,7 @@ For each task, create a bd issue with:
 
 ```bash
 bd create "Task title" \
-  --type [feature|bug|task|chore] \
+  --type [feature|bug|task|epic|chore|decision] \
   --priority [1-3] \
   --description "Context and what needs to be built" \
   --design "Technical approach, architecture notes" \
@@ -149,8 +149,10 @@ bd create "Task title" \
 
 **Dependencies**: Link related issues
 
+The first argument is the issue that becomes blocked; the second is the blocker it waits on.
+
 ```bash
-bd dep add ISSUE-123 ISSUE-456 --type blocks
+bd dep add <blocked-id> <blocker-id> --type blocks
 ```
 
 ### Validation
@@ -179,20 +181,20 @@ After creating issues, verify:
 
 ### Beads Integration
 
-Use Beads MCP to:
+Use the `bd` CLI to:
 
 - Track work with `bd ready` to find next task
 - Create issues with `bd create "description"`
 - Track dependencies with `bd dep add`
 
-See <https://github.com/steveyegge/beads> for more information.
+See <https://github.com/gastownhall/beads> for more information.
 
 ## Integration with Other Commands
 
 - **Before /create-issues**: Use `/spike` if you need technical exploration first
 - **After /create-issues**: Use `/red` to start TDD on first task
 - **During work**: Use `bd update` to add notes/findings back to issues
-- **When stuck**: Check `bd show ISSUE-ID` to review acceptance criteria
+- **When stuck**: Check `bd show <id>` to review acceptance criteria
 
 <!--
 ============== WARNING ==============================================================================

.claude/commands/gap.md

@@ -11,7 +11,7 @@ argument-hint: [optional additional info]
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 

.claude/commands/green.md

@@ -19,7 +19,7 @@ GREEN PHASE! Apply the below to the user input above.
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 
@@ -39,8 +39,9 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 1. **Red Phase**: Write ONE failing test that describes desired behavior
 
    - The test must fail for the RIGHT reason (not syntax/import errors)
-   - Only one test at a time - this is critical for TDD discipline
-     - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
+   - Only one new behavior at a time - this is critical for TDD discipline. "One test" means one new Given/When, not one assertion: write only enough to fail for the right reason, whether that lands in a new test block or as an assertion added to an existing one.
+     - Before writing a new test block, look for an existing test with the same Arrange and Act. If one exists, add the failing assertion there. A block that repeats another's setup and action is not more disciplined, just more setup to maintain, and it hides that both cover one behavior. Reserve a new block for a different precondition (Given) or a different action (When).
+   - Split test files by category if they exceed ~1000 lines
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
    - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content

.claude/commands/issue.md

@@ -13,7 +13,7 @@ Analyze GitHub issue and create TDD implementation plan.
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 
@@ -81,13 +81,13 @@ Understand the requirement by asking (use AskUserQuestion if needed):
 
 ### Beads Integration
 
-Use Beads MCP to:
+Use the `bd` CLI to:
 
 - Track work with `bd ready` to find next task
 - Create issues with `bd create "description"`
-- Track dependencies with `bd dep add`
+- Track dependencies with `bd dep add <blocked-id> <blocker-id>`
 
-See <https://github.com/steveyegge/beads> for more information.
+See <https://github.com/gastownhall/beads> for more information.
 
 ## TDD Fundamentals
 
@@ -98,8 +98,9 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 1. **Red Phase**: Write ONE failing test that describes desired behavior
 
    - The test must fail for the RIGHT reason (not syntax/import errors)
-   - Only one test at a time - this is critical for TDD discipline
-     - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
+   - Only one new behavior at a time - this is critical for TDD discipline. "One test" means one new Given/When, not one assertion: write only enough to fail for the right reason, whether that lands in a new test block or as an assertion added to an existing one.
+     - Before writing a new test block, look for an existing test with the same Arrange and Act. If one exists, add the failing assertion there. A block that repeats another's setup and action is not more disciplined, just more setup to maintain, and it hides that both cover one behavior. Reserve a new block for a different precondition (Given) or a different action (When).
+   - Split test files by category if they exceed ~1000 lines
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
    - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content

.claude/commands/polish.md

@@ -11,7 +11,7 @@ argument-hint: [branch, PR#, file, or area to polish]
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 

.claude/commands/red.md

@@ -19,7 +19,7 @@ RED PHASE! Apply the below to the user input above.
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 
@@ -39,8 +39,9 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 1. **Red Phase**: Write ONE failing test that describes desired behavior
 
    - The test must fail for the RIGHT reason (not syntax/import errors)
-   - Only one test at a time - this is critical for TDD discipline
-     - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
+   - Only one new behavior at a time - this is critical for TDD discipline. "One test" means one new Given/When, not one assertion: write only enough to fail for the right reason, whether that lands in a new test block or as an assertion added to an existing one.
+     - Before writing a new test block, look for an existing test with the same Arrange and Act. If one exists, add the failing assertion there. A block that repeats another's setup and action is not more disciplined, just more setup to maintain, and it hides that both cover one behavior. Reserve a new block for a different precondition (Given) or a different action (When).
+   - Split test files by category if they exceed ~1000 lines
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
    - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content

.claude/commands/refactor.md

@@ -19,7 +19,7 @@ Apply this document (specifically the Refactor phase) to the user input above.
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 
@@ -39,8 +39,9 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 1. **Red Phase**: Write ONE failing test that describes desired behavior
 
    - The test must fail for the RIGHT reason (not syntax/import errors)
-   - Only one test at a time - this is critical for TDD discipline
-     - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
+   - Only one new behavior at a time - this is critical for TDD discipline. "One test" means one new Given/When, not one assertion: write only enough to fail for the right reason, whether that lands in a new test block or as an assertion added to an existing one.
+     - Before writing a new test block, look for an existing test with the same Arrange and Act. If one exists, add the failing assertion there. A block that repeats another's setup and action is not more disciplined, just more setup to maintain, and it hides that both cover one behavior. Reserve a new block for a different precondition (Given) or a different action (When).
+   - Split test files by category if they exceed ~1000 lines
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
    - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content

.claude/commands/research.md

@@ -11,7 +11,7 @@ argument-hint: <research topic or question>
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 **User arguments:**
 

.claude/commands/simplify.md

@@ -11,7 +11,7 @@ argument-hint: [file, function, or area to simplify]
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 **User arguments:**
 

.claude/commands/spike.md

@@ -19,7 +19,7 @@ SPIKE PHASE! Apply the below to the user input above.
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 
@@ -39,8 +39,9 @@ The foundation of TDD is the Red-Green-Refactor cycle:
 1. **Red Phase**: Write ONE failing test that describes desired behavior
 
    - The test must fail for the RIGHT reason (not syntax/import errors)
-   - Only one test at a time - this is critical for TDD discipline
-     - Exception: For browser-level tests or expensive setup (e.g., Storybook `*.stories.tsx`), group multiple assertions within a single test block to avoid redundant setup - but only when adding assertions to an existing interaction flow. If new user interactions are required, still create a new test. Split files by category if they exceed ~1000 lines.
+   - Only one new behavior at a time - this is critical for TDD discipline. "One test" means one new Given/When, not one assertion: write only enough to fail for the right reason, whether that lands in a new test block or as an assertion added to an existing one.
+     - Before writing a new test block, look for an existing test with the same Arrange and Act. If one exists, add the failing assertion there. A block that repeats another's setup and action is not more disciplined, just more setup to maintain, and it hides that both cover one behavior. Reserve a new block for a different precondition (Given) or a different action (When).
+   - Split test files by category if they exceed ~1000 lines
    - **Adding a single test to a test file is ALWAYS allowed** - no prior test output needed
    - Starting TDD for a new feature is always valid, even if test output shows unrelated work
    - For DOM-based tests, use `data-testid` attributes to select elements rather than CSS classes, tag names, or text content

.claude/commands/summarize.md

@@ -11,7 +11,7 @@ argument-hint: [optional additional info]
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 
@@ -53,7 +53,7 @@ Keep the summary concise and actionable - suitable for pasting into a new conver
 
 ## Beads Integration
 
-If Beads MCP is available, check for task tracking status and ask if the user wants to:
+Check for task tracking status with the `bd` CLI and ask if the user wants to:
 
 1. Review current task status
 2. Update task states based on conversation progress

.claude/commands/tdd-review.md

@@ -11,7 +11,7 @@ argument-hint: [optional test file or directory path]
 - Write natural, descriptive code without meta-commentary about the development process
 - The code should speak for itself - TDD is the process, not the product
 
-Beads is available for task tracking. Use `mcp__beads__*` tools to manage issues (the user interacts via `bd` commands).
+Beads is available for task tracking. Use `bd` CLI commands to manage issues.
 
 ## Plan File Restriction
 
@@ -59,7 +59,7 @@ For each test file, check against these criteria:
 |--------------|-------------------|
 | **The Liar** | `expect(true).toBe(true)`, empty test bodies, tests with no assertions |
 | **Excessive Setup** | >20 lines of arrange code, >5 mocks, deep nested object construction |
-| **The One** | >5 assertions testing unrelated behaviors in a single test |
+| **The One** | Multiple Acts in a unit test, Acts from unrelated scenarios strung together under one name, or assertions that don't trace back to one of the test's Acts - assertion count alone is not the signal, since a single Act can warrant many assertions, and E2E or other multi-step flows legitimately chain several sequential Acts within one scenario |
 | **The Peeping Tom** | Testing private methods, asserting on internal state, tests that break on any refactor |
 | **The Slow Poke** | Real database/network calls, file I/O, hard-coded timeouts |