brut 0.0.20 → 0.0.22

data/brutrb.com/dev-environment.md

@@ -0,0 +1,179 @@
+# Dev Environment
+
+Brut provides sophisticatd tooling to manage your dev environment
+
+## Overview
+
+A development environments or *dev environment* is made up of two parts:
+
+* *Foundational Core* - the operating system and tools needed to run the app and *its* tools. This
+includes language runtimes, system libraries (like ImageMagick), and system tools like web browsers.
+* *Workspace* - the tools and code bundled with the app that you use day-to-day to work on the app itself.
+This would include scripts to run the app in development, run tests, perform scaffolding, or manage the
+database.
+
+On many teams, the Foundational Core is different per developer, since some run Linux, some run MacOs.
+Some might use mise to manage their version of Ruby while others use rbenv.  Some will set up Postgres via
+homebrew, while others might use Popstgres.app.
+
+Brut takes a different approach.  Everyone shares the same Foundational Core, and this is defined by a
+`Dockerfile`, a `docker-compose.yml` file, and some lightweight Bash scripts.
+
+This means that everyone uses the same version of everything, and they are all managed the same way.
+
+Brut also provides sophisticated tooling for the Workspace.  Like Rails, Brut provides a command-line
+based flow that can be scripted into any editor.  Unlike Rails, Brut's Workspace is comprised of separate
+command-line apps and not Rake tasks.
+
+### Conceptual Overview
+
+Your dev environment consists of a Docker container that has languages, an operating system, and other
+system components installed in it.  It will have access to the files on your computer so that it can run
+your app. The app will be exposed so that a browser on your computer can access it.  Postgres will be run
+as a separate Docker container available to the dev Docker container.
+
+Your editor and version control system run on your computer.
+
+![Conceptual Overview](/images/dev-env-overview.png)
+
+### Foundational Core Command Line Apps
+
+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 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
+create a new computer or virtual machine.
+* A Dockerfile (often named `Dockerfile`) is a set of instructions to create an image.
+
+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.
+
+
+| App        | Purpose                                                                |
+|------------|------------------------------------------------------------------------|
+| `dx/build` | Builds a Docker *image* from a `Dockerfile.dx`                         |
+| `dx/start` | Starts all Docker containers, including those for databases and caches |
+| `dx/stop`  | Stops all Docker containers                                            |
+| `dx/exec`  | Execute a command inside a running Docker container                    |
+
+The workflow for the foundational core is shown in this diagram.
+
+![Foundational Core Workflow](/images/dev-env-protocol.png)
+
+In words:
+
+1. You build the images based on the latest instrutions 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.
+
+### Workspace Command Line Apps
+
+The workspace is where you'll run your day-to-day commands, such as running tests, starting the dev
+server, managing the database schema, etc.
+
+Several of the commands accept or require subcommands.  Each CLI app responds to `--help` and will show
+you full documentation about what the command and subcommands do.
+
+| App             | Subcommand            | Descriptions                                                                              |
+|-----------------|-----------------------|-------------------------------------------------------------------------------------------|
+| <code style="white-space: nowrap">bin/ci</code>        | None                  | Runs all tests and security checks                                                        |
+| <code style="white-space: nowrap">bin/console</code>   | None                  | Starts up a local IRB session with your app loaded                                        |
+| <code style="white-space: nowrap">bin/db</code>        |                       | Tools for managing the database                                                           |           |
+|                 | `create`              | Create the database if it does not exist                                                  |
+|                 | `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           |
+|                 | `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                                               |
+| <code style="white-space: nowrap">bin/dev</code>       | None                  | Starts the app in dev mode, rebuilding assets and reload as needed                        |
+| <code style="white-space: nowrap">bin/setup</code>     | None                  | Install and setup all third party libraries and other configuration needed to use the app |
+| <code style="white-space: nowrap">bin/scaffold</code>  |                       | Generate Brut classes or files like database migrations or page classes                   |
+|                 | `action`              | Create a handler for an action                                                            |
+|                 | `component`           | Create a new component and associated test                                                |
+|                 | `custom_element_test` | Create a test for a custom element in your app                                            |
+|                 | `form`                | Create a form and handler                                                                 |
+|                 | `page`                | Create a new page and associated test                                                     |
+|                 | `test`                | Create the shell of a unit test based on an existing source file                          |
+|                 | `test:e2e`            | Create the shell of an end-to-end test                                                    |
+| <code style="white-space: nowrap">bin/test</code>      |                       | Run tests |
+|                 | `audit`               | Audits all of the app's classes to see if test files exist                                |
+|                 | `e2e`                 | Run e2e tests                                                                             |
+|                 | `js`                  | Run JavaScript unit tests                                                                 |
+|                 | `run`                 | Run non-e2e tests (default)                                                               |
+
+
+The workflow for your Workspace is shown in this diagram
+
+![Workspace Workflow](/images/workspace-protocol.png)
+
+In words:
+
+1. You'll run `bin/setup` to get everything set up for working.
+2. You'll start your dev server with `bin/dev`.
+3. You'll write code, using tools like `bin/db` and `bin/scaffold` to assist.
+4. Using `bin/test`, you can test any code you've written a test for.
+5. When you are at a stopping point, use `bin/ci` to test the entire app.
+
+### Extending and Enhancing
+
+TBD
+
+## Testing
+
+There aren't tests for this code, because you are using all day every day.  Brut's test suite will ensure
+that the versions of these command line apps provided when you set up your app are working.
+
+## Recommended Practices
+
+While you are free to set up mise or rbenv or whatever to run all this on your computer, this way of
+working is currently not supported nor encouraged.  For now, Brut will focus on the Docker-based approach.
+
+You are encouraged to understand how it works, especially because the Docker skills you learn in doing so
+will help with production deployment and operations.
+
+Beyond this, we recommend that you keep a few things in mind with respect to automation:
+
+* The *Foundational Core* is bootstrapped in a degenerate environment without reliable tools beyond Bash.
+This is why it's almost entirely written in Bash, since it's available everywhere and relatively stable.
+* The *Workspace* **can and should** rely on the languages and third party modules that are part of your
+app. Just keep in mind that `bin/setup` can only rely on programming language runtimes and not any
+particular Ruby gem having been installed.
+
+## Technical Notes
+
+> [!IMPORTANT]
+> Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut's
+> internals, the source code is always more correct.
+
+_Last Updated June 12, 2025_
+
+Everything in `bin/` is intended to be a short shim that calls into classes managed either by Brut or by
+your app. For example, here is `bin/db`:
+
+```ruby
+#!/usr/bin/env ruby
+
+require "bundler"
+Bundler.require
+require "pathname"
+require "brut/cli/apps/db"
+
+exit Brut::CLI.app(
+       Brut::CLI::Apps::DB,
+       project_root: Pathname($0).dirname / ".."
+     )
+```
+
+These files have a lot of 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/doc-conventions.md

@@ -0,0 +1,39 @@
+# Documentation Conventions
+
+## 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*.
+
+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. 
+
+Further, Brut doesn't render HTML, it *generates* it.  The browser renders the HTML for the website's visitor.
+
+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.
+
+## 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.
+
+## Names of the Library and Associated Modules
+
+This framework is called "Brut" though may be called "BrutRB".  It lives at `brutrb.com`.
+
+The JavaScript library is called "BrutJS", but is `brut-js` in code or the filesystem. "Brut-JS" is wrong, as is `brut_js`.
+
+The CSS library is called "BrutCSS", but is `brut-css` in code or the filesystem. "Brut-CSS" is wrong, as is "brut-css".
+
+
+## On Using VitePress
+
+This site is built using [VitePress](https://vitepress.dev), which is a client-side heavy framework.  It kinda goes against the ethos of Brut, but it is allowing me to write documentation that looks decent and is mostly navigable.  I would like to use a more accessible, customized system for documenting Brut, but for now, it's more important to get the documentation out.  A better documentation experience is planned.

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

@@ -0,0 +1,174 @@
+# End to End Tests
+
+Is there a greater pain the world than an end-to-end test? Is there a more punishing API than trying to
+convince a browser to browse and use a website?  Is there an answer for why the way we interact with
+browsers when writing code is 100% different than the we do when writing a test?
+
+Brut cannot answer these things, but it does provide a way to write end-to-end tests with a browser, with
+a somewhat slightly reduced amount of pain.
+
+## Overview
+
+Brut uses [Playwright](https://playwright.dev/) and the
+[playwright-ruby-client](https://playwright-ruby-client.vercel.app/) to allow you to write end-to-end
+tests that use a web browser.  Brut sets up headless Chromium to do this.
+
+You can run End-to-End (e2e) tests with `bin/test e2e`.  You must use this to run individual tests as
+well, since this will ensure proper set up for the tests, which is more than is needed for a normal unit
+test.
+
+### Using Playwright
+
+At a high level, e2e tests look like normal RSpec tests:
+
+```ruby
+require "spec_helper"
+
+RSpec.describe "logging into the website" do
+
+  # ...
+
+end
+```
+
+The contents of your `it` blocks will use `playwright-ruby-client` to interact with the browser and make
+assertions.  The value `page` is available to use this API.
+
+```ruby
+require "spec_helper"
+
+RSpec.describe "logging into the website" do
+  it "shows an error when login is invalid" do
+    page.goto("/")
+
+    email     = page.locator("form input[type='email']")
+    password  = page.locator("form input[type='password']")
+    button    = page.locator("form button")
+
+    email.fill("pat@example.com")
+    password.fill("12345678")
+    button.click
+
+    flash = page.locator("[role='alert']")
+    expect(flash).to have_text("No email/password in our system")
+  end
+end
+```
+
+`playwright-ruby-client` provides excellent documentation on how it has adapter Playwright's API for use
+in Ruby.
+
+### Test Setup
+
+Brut will run your app via `Brut::SpecSupport::E2ETestServer`.  It will run it before the first e2e test, leave it running during the remainder of the test suite, then stop it. This means that database changes your test makes will persist across tests.
+
+If you are using Sidekiq, Sidekiq will be set up like normal. Jobs queued will go to Redis, and those jobs
+will be processed by Sidekiq, just like in production.  Thus, you should not assert things about specific
+jobs, but rather assert the effects those jobs will have. Redis is flushed between each test.
+
+### Test Helpers and Configuration
+
+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
+locator to locate an element. The default is 5 seconds.
+`, to generate or access routes for your app.
+You can also configure behavior with environment variables:
+
+| Variable            | Default | Purpose                                                                                           |
+|---------------------|---------|---------------------------------------------------------------------------------------------------|
+| `E2E_TIMEOUT_MS`    | 5000    | Number of milliseconds Playwright will wait for a locator to appear                               |
+| `E2E_SLOW_MO`       | 0       | Number of milliseconds Playwright will pause between operations. Useful to detect race conditions |
+| `E2E_RECORD_VIDEOS` | unset   | If set, videos of each test run are saved in `tmp/e2e-videos`                                     |
+
+
+### Quirks of Playwright
+
+The Playwright JavaScript API is heavily asycnhronous, requiring liberal use of `await`. The
+`playwright-ruby-client` wrapper abstracts that so you can write more straightfoward code.
+
+The main thing to be aware of is that locators that fail only fail when you attempt to assert something.
+
+For example
+
+```ruby
+button = page.locator("form button") # suppose this button doesn't exist
+
+button.click # This is where you'll see a failure
+```
+
+This hidden asynchronous behavior also means that certain calls will wait a period of time for the element
+you are locating to appear.  This is why the example test above works without having to explicitly wait
+for a page refresh.  After `button.click`, presumably the back-end is contacted and the page is
+re-rendered with an error.  As long as that happens within a second or so, the code will wait for an
+element matching `[role='alert']` to show up.
+
+## Recommended Practices
+
+E2e tests are slow. They can also be flaky if you aren't careful in how you write them and how you
+author your HTML.
+
+### Test Major Flows, Not Exhaustive Branches
+
+E2e tests give the most value when they assert that a sequence of actions the visitor takes result in what
+you expect—a "major flow".  Testing some error cases can be useful, but you should not use e2e tests to
+assert every single possible thing that could happen on a page.
+
+In fact, your app might be better off leaving some behaviors better untested instead of tested by an e2e test.  Use your judgement and be aware of the carrying cost of each e2e test.
+
+### Use CSS Selectors
+
+The main Playwright documentation encourages you to locate elements by "accessible names" and other
+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.
+
+Insulating your end-to-end tests from markup changes does not produce significant savinsg and can make
+tests more difficult to write.
+
+### Testing Must Inform your HTML
+
+To allow CSS selectors to survive minor changes to a page, your HTML should be authored with testing in
+mind.  In the example above, we locate the flash by looking for `[role='alert']`, since this is the most
+semantically correct way to mark up a flash message that contains an error.
+
+ARIA roles that should be applied for accessibility purposes can be leveraged as locators, as can custom
+elements.  Remember that any custom element is valid, even if it has no associated JavaScript.  Custom
+elements are an excellent way to "tag" markup for use in tests or progressively-enhanced behavior.
+
+CSS classes, on the other hand, are not a good candidate for identifying markup in a test. CSS classes
+exist to afford visual styling of elements and are the most likely to change as the app evolves.  A better
+fallback if there is no other way to locate an element is to use `data-testid`.  It makes itself painfully
+clear why it's there.  Use this sparingly, but it's there if you need it.
+
+### Asserting the Lack of Content Basically Doesn't Work
+
+To assert that some content or an element **is not** on the page requires locating it and waiting the
+timeout for that locate to fail. This sucks. Don't do it.
+
+If you need to assert that something did not happen, you may want to design your page or app such that
+markup appears that indicates whatever it is didn't happen.  This is not ideal, but a web page is a living
+thing that never stops changing, so your test can't just assume it's all synchronous.
+
+### Try to Use the Defaults for Timeouts
+
+Your app should not take 5 seconds to do anythning, especially not inside a test.  You may need to bump up
+the timeout to figure out what's going wrong, or set `E2E_SLOW_MO` to watch a video test, but once you've
+sorted out the issue, restore these to their defaults.
+
+If you *must* set `e2e_timeout` as metadata on test, **explain why** and try removing it every so often to
+make sure it's still needed.
+
+## Technical Notes
+
+> [!IMPORTANT]
+> Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut's
+> internals, the source code is always more correct.
+
+_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.

data/brutrb.com/flash-and-session.md

@@ -0,0 +1,224 @@
+# Flash and Session
+
+Brut sessions are stored in cookies, encrypted to prevent tampering.  The *flash*, which is a way to temporarily
+store small bits of information between page loads, is encoded in the session.
+
+## Overview
+
+Unlike Rails, the session and flash are presented to you as objects, not Hashes.  By declaring the `session:`
+parameter on an initializer, you'll be given the current session for the request as an `AppSession`, which
+inherits from `Brut::FrontEnd::Session`.  Similarly, declaring `flash:`, you'll get a `Brut::FrontEnd::Flash`.
+
+The idea is to use Ruby's type system to describe what data is in the session and flash.
+
+### Session
+
+Brut's session is somewhat richer than you might get from other frameworks.  In particular, the session can
+provide you:
+
+* The current `Brut::I18n::HTTPAcceptLanguage`, which is the visitor's locale. See [I18n](/i18n) for how this
+works and how to use this value.
+* The timezone as provided by the browser.
+* An explicitly-set timezone that may or may not be what the browser provided.  See [Space-Time Continuum](/space-time-continuum) for more details.
+
+The session also handles serializing the flash to and from the browser's cookies and can store any arbitrary data
+you like via `[]`.  You are encouraged to add methods to your app's `AppSession` to make it explicit what you are
+storing.
+
+Let's  see the [route hook](/hooks) from  the [pages](/pages) section again.
+
+> [!CAUTION]
+> This hook is not production-ready. It lacks certain error-handling situations and
+> makes an assumption about how the session is managed. It's for demonstration only.
+> The [route hooks](/hooks) section has a more
+> appropriate example.
+
+```ruby
+class RequireAuthBeforeHook < Brut::FrontEnd::RouteHook
+  def before(request_context:,session:)
+    if session.current_user_id
+      user = DB::User.find(id: session.current_user_id)
+      if user
+        request_context[:current_user] = user
+      end
+    end
+  end
+end
+```
+
+When this hook executes, `session` will be an `AppSession`, serialized from the browser's cookies.  Here's what
+that class might look like:
+
+```ruby
+# app/src/front_end/support/app_session.rb
+class AppSession < Brut::FrontEnd::Session
+  def login!(current_user:)
+    self[:current_user_id] = current_user.id
+  end
+
+  def logout!
+    self[:current_user_id] = nil
+  end
+
+  def logged_in?
+    !!self.current_user_id
+  end
+
+  def current_user_id = self[:current_user_id]
+end
+```
+
+The session is a rich object and not just a thin wrapper over a Hash.  You could even have the session perform
+the lookup in the database:
+
+```ruby {11,14-16}
+# app/src/front_end/support/app_session.rb
+class AppSession < Brut::FrontEnd::Session
+  def login!(current_user:)
+    self[:current_user_id] = current_user.id
+  end
+  def logout!
+    self[:current_user_id] = nil
+  end
+
+  def logged_in?
+    !!self.current_user
+  end
+
+  def current_user
+    DB::User.find(id: self[:current_user_id])
+  end
+end
+```
+
+Now, the hook could call `current_user`:
+
+```ruby {3-5}
+class RequireAuthBeforeHook < Brut::FrontEnd::RouteHook
+  def before(request_context:,session:)
+    if session.logged_in?
+      request_context[:current_user] = session.current_user
+    end
+  end
+end
+```
+
+Let's see `LoginHandler` from the [handlers](/handlers) section, to see how to save the current user.  Given what
+we've learned, the declaration of the `session:` parameter to the initializer means the relevant instance of
+`AppSession` will be passed in.
+
+```ruby {20}
+# app/src/front_end/handlers/login_handler.rb
+class LoginHandler < AppHandler
+  def initialize(form:, session:)
+    @form    = form
+    @session = session
+  end
+
+  def handle
+    if !@form.constraint_violations?
+      authorized_user = AuthorizedUser.login(
+        email: form.email,
+        password: form.password
+      )
+      if authorized_user.nil?
+        @form.server_side_constraint_violation(
+          input_name: :email,
+          key: :login_not_found
+        )
+      else
+        session.login!(current_user: authorized_user.user)
+      end
+    end
+    if @form.constraint_violations?
+      LoginPage.new(form: @form)
+    else
+      redirect_to(DashboardPage.routing)
+    end
+  end
+end
+```
+
+Brut will handle saving the updated values in the response so when, in this case, the `DashboardPage` is
+rendered, it can see which user is logged in.
+
+### Flash
+
+By default, your app will use Brut's flash class, `Brut::FrontEnd::Flash`.  This is because you typically don't
+need to enhance the flash.  Brut's flash has an "alert" and "notice", and you can use them however you see fit. You can also set arbitrary messages in the flash via `[]`.
+
+The contents of the flash only survive one request, so anything you set will be available in that session's next
+request, but not after that.
+
+Note that the flash's alert and notice are intended to be I18n keys.  You don't have to use them this way, but it
+is encouraged.  If you pass an array into `alert=` or `notice=`, the elements will be joined to form an I18n key.
+
+You can create your own subclass if you need a richer flash class than the one Brut provides.
+
+First, create your class. It can be anywhere, but we recommend `app/src/front_end/support/app_flash.rb`:
+
+```ruby
+# app/src/front_end/support/app_flash.rb
+class AppFlash < Brut::FrontEnd::Flash
+  # For example
+  def debug=(debug)
+    self[:debug] = debug
+  end
+  def debug  = self[:debug]
+  def debug? = !!self.debug
+end
+```
+
+Then, in your `App`, located in `app/src/app.rb`, use `Brut.container.override` to change the class used for the
+flash:
+
+```ruby
+class App < Brut::Framework::App
+  # ...
+  def initialize
+    Brut.container.override(
+      "flash_class",
+      AppFlash
+    )
+  end
+
+  # ...
+end
+```
+
+Brut's configuration system is discussed in more detail in [Configuration](/configuration).
+
+## Testing
+
+Testing your session or flash classes may not be super valuable, however they are normal Ruby objects so you can
+test them in a conventional way.  Both classes treat their internals as a Hash, so you can implement and assert
+via the `[]` and `[]=` methods.
+
+## Recommended Practices
+
+While you can use both the flash and the session has a hash of whatever, your are encouraged to avoid this in
+your production code.  Create well-defined attributes or methods to manipulate these objects using the language
+of your domain.
+
+
+## Technical Notes
+
+> [!IMPORTANT]
+> Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut's
+> internals, the source code is always more correct.
+
+_Last Updated May 7, 2025_
+
+The session is based on [`Rack::Session`](https://github.com/rack/rack-session), which is configured explicitly
+in your app's `config.ru`. (TBD: WHY?)
+
+The session object itself is created on demand for any route hook that needs it.
+Since `Brut::FrontEnd::RouteHooks::SetupRequestContext` requires the session, the
+`Brut::FrontEnd::RequestContext` is created here and given the session (and flash) that is used for subsequent
+hooks and HTML generation.
+
+The flash is created largely on-demand and is a special hash serialized into the session.  The hash contains the
+current age of the flash and then all the messages.  This format could use improvement and may change.
+`Brut::FrontEnd::RouteHooks::AgeFlash` is a route hook that handles increasing the age of the flash, however the
+flash itself controls when to "age out" messages.  None of this is currently configurable.
+