Ruby on Rails rules file

---description: "Project rules for Ruby, Ruby on Rails, PostgreSQL, RSpec, Bundler. Generated by RulePaste."alwaysApply: true--- # Project rules Stack: Ruby, Ruby on Rails, PostgreSQL, RSpec, Bundler. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Install gems with `bundle install`. Commit `Gemfile.lock` for this application.- Start the app with `bin/dev` if that script exists, otherwise `bin/rails server`.- Tests: `bundle exec rspec` on the file you changed.- Run RuboCop on changed files if the project has it. ## Ruby - Match the Ruby version in `.ruby-version` or the Gemfile.- Run RuboCop if the repo has it. `snake_case` methods, `CamelCase` classes, two-space indent.- Add gems to the Gemfile with a bounded version, then install with Bundler. Commit `Gemfile.lock` for applications. ## Ruby on Rails - If the UI is Hotwire, do not add React or a second API for a server-rendered screen.- Every write uses strong parameters. Never pass raw `params` into `create` or `update`.- Keep validations and associations on the model. Add a service object only if the repo already has that pattern and the action is more than one model write.- Migrations are reversible and append-only. Eager-load associations a list will touch with `includes`.- Use the test suite the repo has, `bin/rails test` or RSpec. Do not introduce the other one. Keep secrets in credentials or the environment. ## PostgreSQL - Every query is parameterized. Never concatenate request data into SQL.- Use the pool the repo already has. Do not open a new client per call on a hot path.- Migrations are append-only SQL. Timestamps are `timestamptz`. New ids match the id type already in the schema.- Name the columns you select. Add an index only for a filter, join, or ordering this change actually runs. ## RSpec - Specs live under `spec/` and mirror the app structure. Use `describe`, `context`, and `it`.- An example name reads as a sentence. Use the factories the repo already has. Do not stub the object under test.- Run `bundle exec rspec` on the file you changed. ## Bundler - Install with `bundle install`. Add gems in the Gemfile, then update the lockfile.- Run project executables with `bin/` or `bundle exec`, not a global gem. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

# Project rules Stack: Ruby, Ruby on Rails, PostgreSQL, RSpec, Bundler. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Install gems with `bundle install`. Commit `Gemfile.lock` for this application.- Start the app with `bin/dev` if that script exists, otherwise `bin/rails server`.- Tests: `bundle exec rspec` on the file you changed.- Run RuboCop on changed files if the project has it. ## Ruby - Match the Ruby version in `.ruby-version` or the Gemfile.- Run RuboCop if the repo has it. `snake_case` methods, `CamelCase` classes, two-space indent.- Add gems to the Gemfile with a bounded version, then install with Bundler. Commit `Gemfile.lock` for applications. ## Ruby on Rails - If the UI is Hotwire, do not add React or a second API for a server-rendered screen.- Every write uses strong parameters. Never pass raw `params` into `create` or `update`.- Keep validations and associations on the model. Add a service object only if the repo already has that pattern and the action is more than one model write.- Migrations are reversible and append-only. Eager-load associations a list will touch with `includes`.- Use the test suite the repo has, `bin/rails test` or RSpec. Do not introduce the other one. Keep secrets in credentials or the environment. ## PostgreSQL - Every query is parameterized. Never concatenate request data into SQL.- Use the pool the repo already has. Do not open a new client per call on a hot path.- Migrations are append-only SQL. Timestamps are `timestamptz`. New ids match the id type already in the schema.- Name the columns you select. Add an index only for a filter, join, or ordering this change actually runs. ## RSpec - Specs live under `spec/` and mirror the app structure. Use `describe`, `context`, and `it`.- An example name reads as a sentence. Use the factories the repo already has. Do not stub the object under test.- Run `bundle exec rspec` on the file you changed. ## Bundler - Install with `bundle install`. Add gems in the Gemfile, then update the lockfile.- Run project executables with `bin/` or `bundle exec`, not a global gem. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

# Project rules Stack: Ruby, Ruby on Rails, PostgreSQL, RSpec, Bundler. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Install gems with `bundle install`. Commit `Gemfile.lock` for this application.- Start the app with `bin/dev` if that script exists, otherwise `bin/rails server`.- Tests: `bundle exec rspec` on the file you changed.- Run RuboCop on changed files if the project has it. ## Ruby - Match the Ruby version in `.ruby-version` or the Gemfile.- Run RuboCop if the repo has it. `snake_case` methods, `CamelCase` classes, two-space indent.- Add gems to the Gemfile with a bounded version, then install with Bundler. Commit `Gemfile.lock` for applications. ## Ruby on Rails - If the UI is Hotwire, do not add React or a second API for a server-rendered screen.- Every write uses strong parameters. Never pass raw `params` into `create` or `update`.- Keep validations and associations on the model. Add a service object only if the repo already has that pattern and the action is more than one model write.- Migrations are reversible and append-only. Eager-load associations a list will touch with `includes`.- Use the test suite the repo has, `bin/rails test` or RSpec. Do not introduce the other one. Keep secrets in credentials or the environment. ## PostgreSQL - Every query is parameterized. Never concatenate request data into SQL.- Use the pool the repo already has. Do not open a new client per call on a hot path.- Migrations are append-only SQL. Timestamps are `timestamptz`. New ids match the id type already in the schema.- Name the columns you select. Add an index only for a filter, join, or ordering this change actually runs. ## RSpec - Specs live under `spec/` and mirror the app structure. Use `describe`, `context`, and `it`.- An example name reads as a sentence. Use the factories the repo already has. Do not stub the object under test.- Run `bundle exec rspec` on the file you changed. ## Bundler - Install with `bundle install`. Add gems in the Gemfile, then update the lockfile.- Run project executables with `bin/` or `bundle exec`, not a global gem. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

---trigger: always_ondescription: "Project rules for Ruby, Ruby on Rails, PostgreSQL, RSpec, Bundler. Generated by RulePaste."--- # Project rules Stack: Ruby, Ruby on Rails, PostgreSQL, RSpec, Bundler. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Install gems with `bundle install`. Commit `Gemfile.lock` for this application.- Start the app with `bin/dev` if that script exists, otherwise `bin/rails server`.- Tests: `bundle exec rspec` on the file you changed.- Run RuboCop on changed files if the project has it. ## Ruby - Match the Ruby version in `.ruby-version` or the Gemfile.- Run RuboCop if the repo has it. `snake_case` methods, `CamelCase` classes, two-space indent.- Add gems to the Gemfile with a bounded version, then install with Bundler. Commit `Gemfile.lock` for applications. ## Ruby on Rails - If the UI is Hotwire, do not add React or a second API for a server-rendered screen.- Every write uses strong parameters. Never pass raw `params` into `create` or `update`.- Keep validations and associations on the model. Add a service object only if the repo already has that pattern and the action is more than one model write.- Migrations are reversible and append-only. Eager-load associations a list will touch with `includes`.- Use the test suite the repo has, `bin/rails test` or RSpec. Do not introduce the other one. Keep secrets in credentials or the environment. ## PostgreSQL - Every query is parameterized. Never concatenate request data into SQL.- Use the pool the repo already has. Do not open a new client per call on a hot path.- Migrations are append-only SQL. Timestamps are `timestamptz`. New ids match the id type already in the schema.- Name the columns you select. Add an index only for a filter, join, or ordering this change actually runs. ## RSpec - Specs live under `spec/` and mirror the app structure. Use `describe`, `context`, and `it`.- An example name reads as a sentence. Use the factories the repo already has. Do not stub the object under test.- Run `bundle exec rspec` on the file you changed. ## Bundler - Install with `bundle install`. Add gems in the Gemfile, then update the lockfile.- Run project executables with `bin/` or `bundle exec`, not a global gem. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

# Project rules Stack: Ruby, Ruby on Rails, PostgreSQL, RSpec, Bundler. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Install gems with `bundle install`. Commit `Gemfile.lock` for this application.- Start the app with `bin/dev` if that script exists, otherwise `bin/rails server`.- Tests: `bundle exec rspec` on the file you changed.- Run RuboCop on changed files if the project has it. ## Ruby - Match the Ruby version in `.ruby-version` or the Gemfile.- Run RuboCop if the repo has it. `snake_case` methods, `CamelCase` classes, two-space indent.- Add gems to the Gemfile with a bounded version, then install with Bundler. Commit `Gemfile.lock` for applications. ## Ruby on Rails - If the UI is Hotwire, do not add React or a second API for a server-rendered screen.- Every write uses strong parameters. Never pass raw `params` into `create` or `update`.- Keep validations and associations on the model. Add a service object only if the repo already has that pattern and the action is more than one model write.- Migrations are reversible and append-only. Eager-load associations a list will touch with `includes`.- Use the test suite the repo has, `bin/rails test` or RSpec. Do not introduce the other one. Keep secrets in credentials or the environment. ## PostgreSQL - Every query is parameterized. Never concatenate request data into SQL.- Use the pool the repo already has. Do not open a new client per call on a hot path.- Migrations are append-only SQL. Timestamps are `timestamptz`. New ids match the id type already in the schema.- Name the columns you select. Add an index only for a filter, join, or ordering this change actually runs. ## RSpec - Specs live under `spec/` and mirror the app structure. Use `describe`, `context`, and `it`.- An example name reads as a sentence. Use the factories the repo already has. Do not stub the object under test.- Run `bundle exec rspec` on the file you changed. ## Bundler - Install with `bundle install`. Add gems in the Gemfile, then update the lockfile.- Run project executables with `bin/` or `bundle exec`, not a global gem. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

# Project rules Stack: Ruby, Ruby on Rails, PostgreSQL, RSpec, Bundler. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Install gems with `bundle install`. Commit `Gemfile.lock` for this application.- Start the app with `bin/dev` if that script exists, otherwise `bin/rails server`.- Tests: `bundle exec rspec` on the file you changed.- Run RuboCop on changed files if the project has it. ## Ruby - Match the Ruby version in `.ruby-version` or the Gemfile.- Run RuboCop if the repo has it. `snake_case` methods, `CamelCase` classes, two-space indent.- Add gems to the Gemfile with a bounded version, then install with Bundler. Commit `Gemfile.lock` for applications. ## Ruby on Rails - If the UI is Hotwire, do not add React or a second API for a server-rendered screen.- Every write uses strong parameters. Never pass raw `params` into `create` or `update`.- Keep validations and associations on the model. Add a service object only if the repo already has that pattern and the action is more than one model write.- Migrations are reversible and append-only. Eager-load associations a list will touch with `includes`.- Use the test suite the repo has, `bin/rails test` or RSpec. Do not introduce the other one. Keep secrets in credentials or the environment. ## PostgreSQL - Every query is parameterized. Never concatenate request data into SQL.- Use the pool the repo already has. Do not open a new client per call on a hot path.- Migrations are append-only SQL. Timestamps are `timestamptz`. New ids match the id type already in the schema.- Name the columns you select. Add an index only for a filter, join, or ordering this change actually runs. ## RSpec - Specs live under `spec/` and mirror the app structure. Use `describe`, `context`, and `it`.- An example name reads as a sentence. Use the factories the repo already has. Do not stub the object under test.- Run `bundle exec rspec` on the file you changed. ## Bundler - Install with `bundle install`. Add gems in the Gemfile, then update the lockfile.- Run project executables with `bin/` or `bundle exec`, not a global gem. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. 

# Project rules Stack: Ruby, Ruby on Rails, PostgreSQL, RSpec, Bundler. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - Install gems with `bundle install`. Commit `Gemfile.lock` for this application.- Start the app with `bin/dev` if that script exists, otherwise `bin/rails server`.- Tests: `bundle exec rspec` on the file you changed.- Run RuboCop on changed files if the project has it. ## Ruby - Match the Ruby version in `.ruby-version` or the Gemfile.- Run RuboCop if the repo has it. `snake_case` methods, `CamelCase` classes, two-space indent.- Add gems to the Gemfile with a bounded version, then install with Bundler. Commit `Gemfile.lock` for applications. ## Ruby on Rails - If the UI is Hotwire, do not add React or a second API for a server-rendered screen.- Every write uses strong parameters. Never pass raw `params` into `create` or `update`.- Keep validations and associations on the model. Add a service object only if the repo already has that pattern and the action is more than one model write.- Migrations are reversible and append-only. Eager-load associations a list will touch with `includes`.- Use the test suite the repo has, `bin/rails test` or RSpec. Do not introduce the other one. Keep secrets in credentials or the environment. ## PostgreSQL - Every query is parameterized. Never concatenate request data into SQL.- Use the pool the repo already has. Do not open a new client per call on a hot path.- Migrations are append-only SQL. Timestamps are `timestamptz`. New ids match the id type already in the schema.- Name the columns you select. Add an index only for a filter, join, or ordering this change actually runs. ## RSpec - Specs live under `spec/` and mirror the app structure. Use `describe`, `context`, and `it`.- An example name reads as a sentence. Use the factories the repo already has. Do not stub the object under test.- Run `bundle exec rspec` on the file you changed. ## Bundler - Install with `bundle install`. Add gems in the Gemfile, then update the lockfile.- Run project executables with `bin/` or `bundle exec`, not a global gem. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets.