brut 0.0.29 → 0.1.0

data/brutrb.com/configuration.md

@@ -92,7 +92,7 @@ end
 
 ### Type and Name Enforcement
 
-You'll note that `store`, accepts a class parameter.  This is mostly used for documentation, with two exceptions:
+You'll note that `store` accepts a class parameter.  This is mostly used for documentation, with two exceptions:
 
 * If the type is `Pathname` (which is what is used by `store_ensured_path` and `store_required_path`), the configuration parameter name *must* end in `_file` or `_dir`.
 * If the type is `"boolean"` or `:boolean`, the configuration parameter name *must* end in a question mark. In this case, the value itself is coerced into `true` or `false`.
@@ -103,8 +103,7 @@ Brut may add more constraints or conversions over time.
 
 By default, Brut configuration values cannot be overridden and they cannot be `nil`.  When calling `store`, `allow_app_override: true` and `allow_nil: true`, can be passed to change this behavior.
 
-In [Flash and Session](/flash-and-session), we discussed setting your own custom class for managing the flash.
-This is possible due to how Brut defines the configuration parameter `flash_class`:
+In [Flash and Session](/flash-and-session), we discussed that you can set your own class for the flash. This is possible due to how Brut defines the configuration parameter `flash_class`:
 
 ```ruby {6}
 Brut.container.store(
@@ -126,7 +125,7 @@ Calling `override` for parameters where `allow_app_override` is not true results
 `store` on a previously `store`-d parameter results in an error.
 
 The idea is to make it extremely clear what values are being set and overridden, and to avoid setting values that
-don't exist.
+don't exist or aren't relevant.
 
 Some values can be `nil`.  Generally, `nil` is a pain and will cause you great hardship.  On occasion, it's
 needed.  For example, [external IDs](/database-schema#external-ids) only work if the app provides an app-wide

data/brutrb.com/css.md

@@ -42,7 +42,7 @@ First, `package.json` (in your app's root) would include `"foobar-css"`:
 
 Next, `app/src/front_end/css/index.css` would import both `"foobar-css"` and `"pages/HomePage.css"`.
 
-```javascript
+```css
 @import "foobar-css/everything.css";
 @import "pages/HomePage.css";
 ```
@@ -73,7 +73,7 @@ To use `foobar-thin.css`, you'd write this `@import` directive:
 
 ## Using Brut-CSS
 
-By default, Brut includes a lightweight functional CSS library called "brut-css".  It provides a basic design system and single-purpose classes to allow you to quickly prototype or build UIs.  It is similar to TailwindCSS by far far smaller and simpler (and less powered).
+By default, Brut includes a lightweight functional CSS library called [BrutCSS](/brut-css/index.html).  It provides a basic design system and single-purpose classes to allow you to quickly prototype or build UIs.  It is similar to TailwindCSS but far far smaller and simpler (and less powered).
 
 It is included so you have something to start with. You can use it by using its various classes like `bg-green-300` and `m-4`, or you can use its provided custom properties like `var(--green-300)` and `var(--sp-4)`.
 

data/brutrb.com/custom-element-tests.md

@@ -37,8 +37,7 @@ as well, such as `assert`.
 The idea is that you use the browser APIs to examine the DOM and assert the behavior of the custom element
 (as opposed to interacting with the custom element's class).
 
-Suppose that `my-element` transform text inside it based on the `transform` attribute. By default, it's
-`lower`, but can be set to `upper` to lower case or upper case, respectively, the text inside.
+Suppose that `my-element` transform text inside it based on the `transform` attribute. By default, it's `lower` (which will lower-case the text), but can be set to `upper` to upper case the text inside.
 
 This means you'll need three tests, each with a different DOM:
 
@@ -72,7 +71,7 @@ describe("<some-element>", () => {
 })
 ```
 
-when the function you give to `test` is executed, the DOM will have been setup, so you can rely on your
+When the function you give to `test` is executed, the DOM will have been setup, so you can rely on your
 custom elements `connectedCallback` having been called.  Assuming the text transformation for `my-element`
 occurs in `connectedCallback`, here is how you'd test all three cases:
 
@@ -109,7 +108,7 @@ describe("<some-element>", () => {
 })
 ```
 
-You'll notice almost all of this uses the browser APIs you (should :) know and (hopefully :) love.
+You'll notice almost all of this uses the browser APIs you (should) know and (hopefully) love.
 
 You can manipulate the DOM inside a test as well, and it should behave as if you are doing it in a
 browser.  Note that many browser APIs are synchronous, so you don't have to add `await` before every

data/brutrb.com/database-access.md

@@ -156,7 +156,7 @@ end
 ### Do Not Put Business Logic On Your Database Models
 
 There's no reason to, or benefit to doing so.  What you'll find is that any app of even moderate complexity will
-not have a strict mapping from page to business concept to database table.  Rather these things will all differ
+not have a strict mapping from page to business concept to database table.  Rather, these things will all differ
 greatly, and each serves a different purpose.
 
 The job of your data models—and the tables they provide access to—is to store reliable and unambiguous data.

data/brutrb.com/database-schema.md

@@ -1,10 +1,6 @@
 # Database Schema / Migrations
 
-Brut provides access to the database via the [Sequel library](https://sequel.jeremyevans.net/).  Sequel is fully featured and provides a lot of ways of interacting with and managing your database.  Brut includes several plugins and extensions to provide opinionated default behavior or additional features.
-
-One thing to keep in mind is that Brut refers to your database layer as *database models* (notably not the un-qualified "models").  Brut treats this layer as a *model* of your database, not a model of your *domain* (though you are free to conflate the two).
-
-This section details how to manage your database schema.
+Brut provides access to the database via the [Sequel library](https://sequel.jeremyevans.net/).  To manage your database schema, Brut uses Sequel's facility for this, with some of its own enhancements.
 
 > [!NOTE]
 > Brut currently only supports Postgres. Sequel supports many database systems, however Brut's extensions are
@@ -12,22 +8,14 @@ This section details how to manage your database schema.
 
 ## Overview
 
-Brut uses *migrations* to control and manage the schema of your database. Migrations are changes to the
-schema that depend on the changes before them.  In a running production database, you will not be able to
-create the database schema from scratch—you will have to modify the existing schema to produce the schema
-you want.
+Your database schema is managed by a series of changes that build upon one another
+called *migrations*.
 
-For example, if you have a table `widgets` that has a `name` and `description`, to add a `status` field,
-you cannot `drop table widgets` and then `create table widgets(...)` with the fields. You must instead
-`alter table widgets(...)` to add the new column.
+For example, if you have a table `widgets` that has a `name` and `description`, to add a `status` field, you cannot `drop table widgets` and then `create table widgets(...)` with the fields. You must instead `alter table widgets(...)` to add the new column.
 
 Thus, each migration file is a change to the schema produced by all previous migration files. 
 
-Brut's provides this via Sequels. See [both](https://sequel.jeremyevans.net/rdoc/files/doc/schema_modification_rdoc.html) [docs](https://sequel.jeremyevans.net/rdoc/files/doc/migration_rdoc.html) for details on the API.  Any schema modification method Sequel documents is available, however some default behavior has changed.
-
-Schema files are located in `app/src/back_end/data_models/migrations` and are named using a timestamp-based
-scheme.  This means that when you create a new migration, its name will be based on the time and date you
-created it, and any migrations that have not been applied will be applied in timestamp order.
+Brut's provides this via Sequel. See [both](https://sequel.jeremyevans.net/rdoc/files/doc/schema_modification_rdoc.html) [docs](https://sequel.jeremyevans.net/rdoc/files/doc/migration_rdoc.html) for details on the API.  Any schema modification method Sequel documents is available, however some default behavior has changed.
 
 ### Creating Migrations
 
@@ -40,6 +28,10 @@ together to form the filename:
     app/src/back_end/data_models/migrations/20250508132646_user-accounts.rb
 ```
 
+Note that the files are located in `app/src/back_end/data_models/migrations` and
+have a name prefixed with a timestamp.  This timestamp determins an ordering of how
+the files are applied to the database.
+
 The file is created mostly blank:
 
 ```ruby
@@ -49,19 +41,17 @@ Sequel.migration do
 end
 ```
 
-Sequels' migration system is similar to Active Record's/Rails' in design and spirit, but the API is different.
-Please consult the documentation and don't assume Active Record's DSL will work. It will not.
+> [!NOTE]
+> Sequels' migration API is similar in concept to Rails', but differs
+> significantly in specifics. Please consult Sequel's documentation and
+> don't assume Railsism will work the same way.
 
-One thing to note is that Brut encourages the creation of only "up" migrations. That is, migrations that change a
-database. "Down" migrations, which revert a change, are discouraged.  See *Recommended Practices* for a detailed
-explanation.
+Brut encourages only "up" migrations.  Since Brut treats your development database
+as ephemeral, there is little value to managing "down" migrations.
 
-This is also why Sequel's `change` method is not included in the scaffolded code.  `change`, like Active Record's
-method of the same name, automagically creates both "up" and "down" migrations, but *only* if you use the DSL. If
-you use raw SQL, `change` doesn't work.  But that doesn't matter for Brut (again, see *Recommended Practices*).
+This is why Sequel's `change` method is not included in the scaffolded code.  `change`, like Active Record's method of the same name, automagically creates both "up" and "down" migrations, but *only* if you use the DSL. If you use raw SQL, `change` doesn't work. By using only `up`, you won't have to worry about this.
 
-Let's create a user accounts table that has an email field, a `deactivated_at` timestamp, and a `created_at`
-timestamp:
+Let's create an accounts table that has an email field, a `deactivated_at` timestamp, and a `created_at` timestamp:
 
 ```ruby
 Sequel.migration do
@@ -90,10 +80,6 @@ To apply this migration use `bin/db migrate`
 > bin/db migrate
 ```
 
-If you create a new migration, it will use a timestamp that is alphanumerically greater than the one we just made
-and thus that migration will be applied after this one.  Thus, you can rely on previous migrations having been
-applied when authoring new ones.
-
 ### Managing Migrations
 
 Sequel uses a special database table to understand which migrations have been run.  This table will exist in
@@ -126,16 +112,19 @@ provides a more helpful error message when no records are found
 #### External IDs
 
 It's often useful to provide a unique identifier for a record that is not the database primary key.  There are
-many advantages to doing so, but the core value Brut has regarding this is that database primary and foreign keys
-are considered private and internal and for developer use only.  It is trivial to produce externalizable keys, as
-you'll see, so there's no reason to expose primary keys.
+many advantages to doing so, the main being that your primary and foreign keys are
+considered private and for developer use only.  Creating additional externalizable
+unique keys is trivial, so Brut provides a way to do that.
 
 > [!NOTE]
-> Take care to differentiate the terms *primary key* and *key*.  In relational database literature, and thus
-> in Brut, a *key* is any value that uniquely identifies a record. `email` in the `accounts` table above
-> is a key.  The *primary key* is single source of truth for identifying records internally in the database.
-> Thus, it can be used as a *foreign key* to create relationships between tables.  Brut further implements
-> this as a *surrogate* or *synthetic* key, which means the value itself has  no business  or domain meaning.
+> **Primary keys** and **keys** are not the same thing.  **Primary keys** are
+> what is used to identify a record for the purposes of referential integrity.
+> A **key** simply uniquely identifies a row or is a unique constraint on a table.
+> Tables have only one primary key, but potentially many keys. Brut uses
+> *synthetic* (sometimes called *surrogate*) keys as primary keys.  This means
+> they have no business meaning and can be safely used for foreighn keys
+> and other cases without conflating them with domain concepts.
+
 
 In Brut, an external ID is automatically generated by the database when a record is created.  By convention, it
 is prefixed with a short string representing your app and a short string representing the table, followed by a
@@ -190,8 +179,7 @@ This means that you can set values explicitly if you like, *and* you can change
 
 ### Brut Migration Changes and Enhancement
 
-Brut attempts to set default behavior for migrations to encourage a modicum of best practices.  This lists out
-the changes and a brief explanation for the purpose of the change.
+Brut attempts to set default behavior for migrations to encourage a modicum of best practices.  These are:
 
 * **Automatic synthetic primary key named `id` of type `int`.**  You almost always want this. You can change the
 primary key configuration per table if you like, but if you do nothing, you get a primary key that works for 99%

data/brutrb.com/dev-environment.md

@@ -1,6 +1,6 @@
 # Dev Environment
 
-Brut provides sophisticatd tooling to manage your dev environment
+Brut provides sophisticated tooling to manage your dev environment
 
 ## Overview
 
@@ -41,7 +41,7 @@ Your editor and version control system run on your computer.
 These are the commands you will use to manage the *foundational core*, which is the Docker containers and
 their contents.
 
-A few brief terminoloy notes if you aren't familiar with Docker:
+A few brief terminology notes if you aren't familiar with Docker:
 
 * A Docker *container* is akin to a virtual machine. On Linux this isn't strictly true, but conceptually, you can think of this like a virtual computer.
 * A Docker *image* is what you use to start a container.  This is akin to a disk image you might use to
@@ -52,7 +52,7 @@ A few verbs to provide additional help:
 
 * One *builds* a Docker image from a Dockerfile.
 * One *starts* a Docker container from an image.
-* One *stops* a Docker conatiner when it's no longer needed.
+* One *stops* a Docker container when it's no longer needed.
 
 
 | App        | Purpose                                                                |
@@ -68,7 +68,7 @@ The workflow for the foundational core is shown in this diagram.
 
 In words:
 
-1. You build the images based on the latest instrutions via `dx/build`.
+1. You build the images based on the latest instructions via `dx/build`.
 2. You start up the environment with `dx/start`.
 3. You then use `dx/exec` to execute commands from the Workspace (see below).
 4. When you are done working for the day, `dx/stop` shuts everything down.
@@ -90,7 +90,7 @@ you full documentation about what the command and subcommands do.
 |                 | `drop`                | Drop the database if it exists                                                            |
 |                 | `migrate`             | Apply any outstanding migrations to the database                                          |
 |                 | `new_migration`       | Create a new migration file                                                               |
-|                 | `rebuild`             | Drop, re-create, and run migrations, effecitvely rebuilding the entire database           |
+|                 | `rebuild`             | Drop, re-create, and run migrations, effectively rebuilding the entire database           |
 |                 | `seed`                | Load seed data into the database                                                          |
 |                 | `status`              | Check the status of the database and migrations                                           |
 | <code style="white-space: nowrap">bin/dbconsole</code> | None                  | Starts up a `psql` session to your database                                               |
@@ -138,7 +138,7 @@ While you are free to set up mise or rbenv or whatever to run all this on your c
 working is currently not supported nor encouraged.  For now, Brut will focus on the Docker-based approach.
 
 The primary reason is that it's a tightly controlled environment that is almost
-entirely scriptable, but does not require devs to abandon their preffered editor.
+entirely scriptable, but does not require devs to abandon their preferred editor.
 Environment manager-based approaches tend to be more fussy and require documentation
 to ensure they are set up.
 
@@ -174,7 +174,7 @@ exit Brut::CLI.app(
      )
 ```
 
-These files have a lot of duplication, but should be relatively stable.
+These files have some duplication, but should be relatively stable.
 
 This means that Brut-provided CLIs *will*  be updated when you update Brut.  Compare this to the files in
 `dx/` which are entire Bash scripts that will not be updated when Brut is updated.

data/brutrb.com/dir-structure.md

@@ -0,0 +1,120 @@
+# Directory Structure
+
+```
+.
+├── app
+│   ├── config
+│   │   └── i18n
+│   │       └── en
+│   ├── public
+│   │   ├── css
+│   │   ├── js
+│   │   └── static
+│   │       └── images
+│   └── src
+│       ├── back_end
+│       │   ├── data_models
+│       │       ├── db
+│       │       ├── migrations
+│       │       └── seed
+│       ├── cli
+│       └── front_end
+│           ├── components
+│           ├── css
+│           ├── fonts
+│           ├── forms
+│           ├── handlers
+│           ├── images
+│           ├── js
+│           ├── layouts
+│           ├── pages
+│           ├── route_hooks
+│           ├── support
+│           └── svgs
+├── bin
+├── deploy
+├── dx
+└── specs
+    ├── back_end
+    │   ├── data_models
+    │       └── db
+    ├── e2e
+    ├── factories
+    │   └── db
+    └── front_end
+        ├── components
+        ├── handlers
+        ├── js
+        ├── pages
+        └── support
+```
+
+## Top Level
+
+| Directory | Purpose |
+|-----------|---------|
+| `app/`    | Contains all configuration and source code specific to your app |
+| `bin/`    | Contains tasks and other CLIs to do development of your app, such as `bin/test` |
+| `dx/`     | Contains scripts to manage your development environment |
+| `specs/`  | Contains all tests |
+
+## Inside `app`/
+
+| Directory | Purpose |
+|-----------|---------|
+| `bootstrap.rb` | A ruby file that sets up your app and ensures everything is `require`d in the right way. |
+| `config/` | Configuration for your app, such as localizations and translations. Brut tries very hard to make sure there is no YAML in here at all. YAML is not good for you. |
+| `public/` | Root of public assets served by the app. |
+| `src/` | All source code for your app |
+
+Inside `app/src`
+
+| Directory | Purpose |
+|-----------|---------|
+| `app.rb` | The core of your app, mostly configuration, such as routes, hooks, middleware, etc. |
+| `back_end/` | Back end classes for your app including database schema, DB models, seed data, and your domain logic |
+| `cli/` | Any CLIs or tasks for your app |
+| `front_end/` | The front-end for your app, including pages, components, forms, handlers, JavaScript, and assets |
+
+Inside `app/src/back_end`
+
+| Directory | Purpose |
+|-----------|---------|
+| `data_models/app_data_model.rb` | Base class for all DB model classes |
+| `data_models/db` | DB model classes |
+| `data_models/db.rb` | Namespace module for DB model classes |
+| `data_models/migrations` | Database schema migrations |
+| `data_models/seed` | Seed data used for local development |
+
+Inside `app/src/front_end`
+
+|Directory       | Purpose |
+|----------------|---------|
+| `components/`  | Component classes |
+| `css/`         | CSS, managed by esbuild and `bin/build-assets` |
+| `fonts/`       | Custom fonts, managed by esbuild and `bin/build-assets` |
+| `forms/`       | Form classes |
+| `handlers/`    | Handler classes |
+| `images/`      | Images, copied to `app/public` by `bin/build-assets` |
+| `js/`          | JavaScript, managed by esbuild and `bin/build-assets` |
+| `layouts/`     | Layout classes |
+| `middlewares/` | Rack Middleware, if any |
+| `pages/`       | Page classes |
+| `route_hooks/` | Route hooks, if any |
+| `support/`     | General support classes/junk drawer. |
+| `svgs/`        | SVGs you want to render inline |
+
+## Inside `specs/`
+
+`specs/` is intended to mirror `app/src`, but has a few extra directories:
+
+
+|Directory       | Purpose |
+|----------------|---------|
+| `specs/back_end` | tests for all back-end code, organized the same as `app/src/back_end` |
+| `specs/back_end/data_models/db` | tests for all DB classes, if needed |
+| `specs/e2e` | End-to-end tests, organized however you like |
+| `specs/factories` | Root of all factories for FactoryBot. You can create subdirectories here for non-DB classes you may want to be able to create |
+| `specs/factories/db` | Factories to create DB records |
+| `specs/front_end` | tests for all front-end code, organized the same as `app/src/front_end` |
+| `specs/js`| *JavaScript* code to test any autonomous custom elements you have created |

data/brutrb.com/doc-conventions.md

@@ -2,32 +2,35 @@
 
 ## Terminology
 
-Brut attempts to use existing terminology where possible, particularly where that technology applies to the web platform.  For example, there is not a thing called "CSS variables", rather the term is "custom properties". HTML entities are *elements* or *tags* that have *attributes*. As another example, HTML doesn't have *validations*, rather it as *constraints*, which can be *violated*.
+Brut attempts to use existing terminology where possible, particularly where that technology applies to the web platform.  For example, there is not a thing called "CSS variables", rather the term is "custom properties".
 
-When speaking about Ruby, we prefer the term *initializer* over constructor, *parameters* over arguments, and *methods* over messages.  We also prefer *tests* over specs, however test files *are* located in `specs/` and named `*.spec.rb` to be consistent with RSpec's nomenclature.  We prefer *end-to-end* or *e2e* tests instead of browser tests or request specs. 
+Here are some common exampels:
 
-Further, Brut doesn't render HTML, it *generates* it.  The browser renders the HTML for the website's visitor. One exception is Phlex, which uses the term *render* to mean "generate HTML to an internal buffer that will be delivered to the client later".  Thus, you will need to call Phlex's `render` method from time to time, even though it is not rendering HTML but helping to generate it.
 
-Lastly, the documentation tries to talk about the person accessing a website as a "vistor" not a "user". Though the "user" nomenclature is near-ossified in software development, we feel "visitor" is more apt.
+- HTML entities are **elements** or **tags**
+- HTML elements have **attributes**.
+- Forms don't have validations, they have **constraints** which are **violated** by invalid data.
+- Ruby classes don't have constructors, they have **initializers**.
+- Invoking behavior on a Ruby object is **calling a method**, not sending a message.
+- Despite being in `specs/`, the files in there are **tests**, not specifications or
+-specs".
+- Tests that use a browser are **end to end** or **e2e** tests.
+- HTML is not rendered, but **generated**. The browser renders the HTML sent to it by the server, along with the CSS.
+- Your app or site doesn't have users, it has **visitors**.
 
 ## Structure of These Documents
 
 Each page here documents on aspect of Brut, called a *module*, and these pages are organized along four sections:
 
-* **Overview** - provides detailed information on how this part of Brut works, with minimal examples to orient you to
-the terms and design of that module.  Links to reference documentation are provided inline as needed.
-* **Testing** - information about how to write tests for the code in this module.  For example, in [Pages](/pages), we detail how you are intended to test page classes.
-* **Recommended Practices** - this section outlines what we believe is the best way to use the module, along with
-justifications for the recommended approach.  While you are free to ignore this advice, it's often useful to
-understand the intention of the authors.
-* **Technical Notes** - where appropriate, technical details about how or why the module works the way it does
-are provided.  This section should be marked with a date to allow you to understand the recency of the
-information. It may not always be up to date, but this can help further clarify what is happening under the
-covers and why.
+* **Overview** - What the module does, how it works, and a brief example.
+* **Testing** - How to test the code you write in this module.
+* **Recommended Practices** - Opinions from the creators about how best to think about the code in this module.
+* **Technical Notes** - details about the technical implementations that may be
+useful as context.
 
 ## Names of the Library and Associated Modules
 
-This framework is called "Brut" though may be called "BrutRB".  It lives at `brutrb.com`.
+This framework is called "Brut" though may be called "BrutRB" or "brut-rp".  It lives at `brutrb.com`.  Never use "brutRB", "brut_rb", etc.
 
 The JavaScript library is called "BrutJS", but is `brut-js` in code or the filesystem. "Brut-JS" is wrong, as is `brut_js`.
 

data/brutrb.com/dx

@@ -0,0 +1 @@
+../dx

data/brutrb.com/end-to-end-tests.md

@@ -55,7 +55,7 @@ RSpec.describe "logging into the website" do
 end
 ```
 
-`playwright-ruby-client` provides excellent documentation on how it has adapter Playwright's API for use
+`playwright-ruby-client` provides excellent documentation on how it has adapted Playwright's API for use
 in Ruby.
 
 ### Test Setup
@@ -70,9 +70,15 @@ jobs, but rather assert the effects those jobs will have. Redis is flushed betwe
 
 Inside your test, `t` is available to produce translations. You can also access all your page and handler classes, so you can (and should) use `.routing`, e.g. `DashboardPage.routing`, to generate or access routes for your app.
 
-You can set `e2e_timeout` on any test to override the default amount of time Playwright will wait for a
+You can set the `e2e_timeout` metadata on any test to override the default amount of time Playwright will wait for a
 locator to locate an element. The default is 5 seconds.
-`, to generate or access routes for your app.
+
+```ruby
+RSpec.describe "Test for login", e2e_timeout: 10 do
+  # ...
+end
+```
+
 You can also configure behavior with environment variables:
 
 | Variable            | Default | Purpose                                                                                           |
@@ -122,12 +128,9 @@ The main Playwright documentation encourages you to locate elements by "accessib
 indirect ways of finding elements.  In practice, this is error prone and tedious.  Determining the
 accessible name of an element is not always easy.
 
-We recommend you assess your app's accssibility in another way than trying to do it while performing
-end-to-end tests.  Instead, locate elements with CSS selectors—this is what you'd use to debug your app so
-it makes sense as a testing technique.
+We recommend you assess your app's accessibility in another way than trying to do it while performing end-to-end tests.  Instead, locate elements with CSS selectors—this is what you'd use to debug your app so it makes sense as a testing technique.
 
-Insulating your end-to-end tests from markup changes does not produce significant savinsg and can make
-tests more difficult to write.
+Insulating your end-to-end tests from markup changes does not produce significant savings and can make tests more difficult to write.
 
 ### Testing Must Inform your HTML
 
@@ -170,5 +173,4 @@ make sure it's still needed.
 
 _Last Updated June 13, 2025_
 
-The test server is run bin `bin/test-server`, which is why Sidekiq will be running when your app is
-running for an e2e test.
+The test server is run via `bin/test-server`.