More Agents updates

.claude/commands/green.md

@@ -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

@@ -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/red.md

@@ -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

@@ -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/spike.md

@@ -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/tdd-review.md

@@ -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 |
 

.claude/commands/tdd.md

@@ -28,8 +28,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

.config/_typos.toml

@@ -6,8 +6,6 @@ extend-ignore-re = [
 
 [default.extend-words]
 # Words managed by the base template
-# `astroid` is the name of a python library, and it is used in pylint configuration. should not be corrected to asteroid
-astroid = "astroid"
 
 
 # Words specific to this repository

.config/pylintrc.toml

@@ -2,7 +2,7 @@
 disable = "all"
 enable = [
   # These are always needed to ensure that a crash within pylint itself appropriately causes a failure
-  "astroid-error",
+  "astroid-error", # spellchecker:disable-line
   "fatal",
   # Rules relating to errors found parsing this config file
   "config-parse-error",

.config/pyrefly.toml

@@ -18,19 +18,23 @@ search-path = [".."]
 disable-project-excludes-heuristics = true # with this being enabled by default, pyrefly thinks the src is excluded because it's an editable local install
 python-platform = "linux"
 infer-with-first-use = false # more similar to pyright. must define the empty list type when instantiated
-# "strict" enables the maximalist error set plus strict-callable-subtyping and
-# unused-ignore. "preset = all" (every error kind) will be available in v1.1.
-preset = "strict"
+preset = "all"
 spec-compliant-overloads = true # not sure exactly what this does, but seems like a good idea to be more spec compliant
 ignore-errors-in-generated-code = true # not sure yet how effective this is
 
 [errors]
 no-access = "ignore" # (already covered by ruff SLF001)
-# reportMissingTypeStubs=false in pyright
-untyped-import = "ignore"
+untyped-import = "ignore" # equivalent of reportMissingTypeStubs=false in pyright
+unannotated-return = "ignore" # ruff ANN2xx already requires this, but with suppress-none-returning so that None-returning functions don't need the noise. pyrefly has no equivalent option---the error kind is all-or-nothing.
 
 [[sub-config]]
-matches = "**/tests/**"
+matches = "../**/tests/**"
 
 [sub-config.errors]
 implicitly-defined-attribute = "ignore" # doesn't make any sense for test cases. See https://github.com/microsoft/pyright/discussions/4834#discussioncomment-8496931
+# Tests are self-asserting: a value that isn't what the test assumed fails the very next assertion,
+# pointing at the exact line. The unknowns these rules flag also come almost entirely from mocking, where the value
+# genuinely is `Any` and no upstream typing fix is possible --- `spy_return` is set dynamically on the mock,
+# and `call_args[0]` is untyped by construction --- so enforcing here only buys narrowing ceremony at every spy.
+unknown-variable-type = "ignore"
+unknown-argument-type = "ignore"

.config/ruff.toml

@@ -43,6 +43,7 @@ ignore = [
     # rules that conflict with the Ruff formatter https://docs.astral.sh/ruff/formatter/#conflicting-lint-rules
     "W191","E111","E114","E117","D206","Q000","Q001","Q002","Q003","COM812","COM819","ISC001","ISC002","E501",
 
+    "CPY001", # We don't care about having copyright headers in every file # spellchecker:disable-line
     "D100", # Docstrings are not always necessary for public modules
     "D101", # Docstrings are not always necessary for public classes
     "D102", # Docstrings are not always necessary for public methods

.devcontainer/devcontainer.json

@@ -70,5 +70,5 @@
   "initializeCommand": "sh .devcontainer/initialize-command.sh",
   "onCreateCommand": "sh .devcontainer/on-create-command.sh",
   "postStartCommand": "sh .devcontainer/post-start-command.sh"
-  // Devcontainer context hash (do not manually edit this, it's managed by a pre-commit hook): fb8b636d # spellchecker:disable-line
+  // Devcontainer context hash (do not manually edit this, it's managed by a pre-commit hook): fd4e1850 # spellchecker:disable-line
 }

.devcontainer/install-ci-tooling.py

@@ -5,9 +5,9 @@
 import subprocess
 import sys
 
-UV_VERSION = "0.12.1"
-PNPM_VERSION = "11.20.0"
-COPIER_VERSION = "9.17.0"
+UV_VERSION = "0.12.3"
+PNPM_VERSION = "11.21.0"
+COPIER_VERSION = "9.17.1"
 COPIER_TEMPLATE_EXTENSIONS_VERSION = "0.3.3"
 PRE_COMMIT_VERSION = "4.5.1"
 GITHUB_WINDOWS_RUNNER_BIN_PATH = r"C:\Users\runneradmin\.local\bin"

.pre-commit-config.yaml

@@ -42,7 +42,7 @@ repos:
 
   # Reformatting (should generally come before any file format or other checks, because reformatting can change things)
   - repo: https://github.com/crate-ci/typos
-    rev: 96d9af6217dc2855210655af7e1ff19d23d4e593  # frozen: v1
+    rev: 12ffd4a04b4893ab75db66a59aaad2d996c3e982  # frozen: v1
     hooks:
       - id: typos
         args: [--write-changes, --force-exclude, --config, .config/_typos.toml]
@@ -77,19 +77,6 @@ repos:
               .*\.svg|
               .*/vendor_files/.*|
           )$
-      - id: pretty-format-json
-        exclude: |
-          (?x)^(
-              .devcontainer/devcontainer.json|
-              .devcontainer/devcontainer-lock.json|
-              .*devcontainer.json|
-              .*tsconfig.json|
-              .*biome.jsonc|
-              .*/generated/open[-_]api/.*|
-              .*tests/.*/__snapshots__/.*|
-              .*/vendor_files/.*|
-          )$
-        args: [--autofix, --no-sort-keys]
 
   - repo: https://github.com/biomejs/pre-commit
     rev: a450e9c04887b1305951c298db5999cd30155f74  # frozen: v2.1.1
@@ -104,7 +91,7 @@ repos:
           )$
 
   - repo: https://github.com/rbubley/mirrors-prettier
-    rev: 9337a74165b178ae2c766f60bee7252a0f06f3e8  # frozen: v3.9.5
+    rev: 0ee178619d696787ca73d210cc191d720868c631  # frozen: v3.9.6
     hooks:
       - id: prettier
         args: [--config, .config/.prettierrc]
@@ -174,7 +161,7 @@ repos:
       - id: check-case-conflict
 
   - repo: https://github.com/python-jsonschema/check-jsonschema
-    rev: 1a4bb160cab6417b3045e1b37b6b72449243e658  # frozen: 0.37.4
+    rev: c4654a7e007c9619a5eb63c39a456572a0fa1851  # frozen: 0.38.0
     hooks:
       - id: check-github-workflows
 
@@ -219,18 +206,18 @@ repos:
         exclude: docs/.*\.rst$
 
   - repo: https://github.com/hadolint/hadolint
-    rev: 4e697ba704fd23b2409b947a319c19c3ee54d24f  # frozen: v2.14.0
+    rev: 2eece55955ced00200be9729e9728cb7dacca505  # frozen: v2.15.1
     hooks:
       - id: hadolint-docker
         name: Lint Dockerfiles
         # The hadolint pre-commit has a problem where it just always pulls the `latest` image at runtime.
         # Explicitly pinning the image here to the same rev as the hook to patch it until https://github.com/hadolint/hadolint/pull/1177 gets resolved.
-        entry: ghcr.io/hadolint/hadolint:v2.14.0@sha256:27086352fd5e1907ea2b934eb1023f217c5ae087992eb59fde121dce9c9ff21e hadolint
+        entry: ghcr.io/hadolint/hadolint:v2.15.1@sha256:fdf19d026b54834f88c62774fdf2a61ff3b586a42632e5070674d41a796bfdf3 hadolint
         exclude: .*\.jinja$
         description: Runs hadolint to lint Dockerfiles
 
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: 2700fd5671c633760d912769c041bfcde2b9a01b  # frozen: v0.15.22
+    rev: 65dbdb59d2f2d9c3bdc343c566821ad3319ddaa3  # frozen: v0.16.3
     hooks:
       - id: ruff
         name: ruff-src
@@ -261,15 +248,18 @@ repos:
           )$
 
   - repo: https://github.com/pylint-dev/pylint
-    rev: 8a396357098337ba8be714fffdf2d00947a9778c  # frozen: v4.0.6
+    rev: f5a6e3b1de17502747a40d7f92f285ccf9c6c459  # frozen: v4.0.7
     hooks:
       - id: pylint
         name: pylint
+        # exclude any generated code
+        # flagging duplicate code for __all__ lists is a false positive
         # exclude the template files---duplication within them will be discovered during CI of that template instantiation
         exclude: |
           (?x)^(
               .*/generated/graphql/.*|
               .*/generated/open[-_]api/.*|
+              .*__init__\.py|
               template/.*|
           )$
         args: