weft 0.1.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: fada6be56bfe906aa7c6f8d30f2e759b750517440027eada9b98b3afcff9e4d9
+  data.tar.gz: bd66b0c5d17e658de87ebc058ca393a5d94632b1cb5251c5f43fb9a757d35656
+SHA512:
+  metadata.gz: 376016a9b727cf23334ca98410778b3c90f4aa2d38a1cffe84ac91b4b32e82d2afb148a84bc370309962406c536e2dc458c3f0310ea2020cfb40b75a2ba5e657
+  data.tar.gz: f9c26e0e7514cb92356ed4a78b515f2f367dcb92126c259318d14378469e2d26ffe9af1ee64440f671a18239cfdb10312942c12bec862518a2dbe63446c30b39

data/CHANGELOG.md

@@ -0,0 +1,37 @@
+# Changelog
+
+## v0.1.0 (2026-07-12)
+
+First usable release. Weft is component-oriented hypermedia for Ruby: components declare their structure, their data, and their interactive behaviors, and the framework derives the routing, request handling, and client-side wiring automatically.
+
+### New Features:
+
+- **Components and pages** – Subclass `Weft::Component` and `Weft::Page`, declare `attribute`s, and build HTML in Ruby via Arbre:
+  - Components render standalone fragments or compose into pages through generated builder methods (`builder_method :name`)
+  - Declared attributes resolve from request parameters with defaults and type coercion, and reach your code as `attrs.whatever`
+  - Pages carry the document shell: title, stylesheets, scripts, inline CSS, all inheritable down the page hierarchy
+- **The verb DSL** – One-line declarations for dynamic behavior:
+  - `performs :name` – user-initiated actions: run your callable, re-render the component
+  - `transfers :name, to: Other` – actions that render a different component in the caller's place
+  - `dismisses :name` – actions that remove the component from the DOM
+  - `refreshes every:` / `refreshes on:` – client re-fetches on a timer (whole or fractional seconds, down to a 1ms floor) or when a page event fires
+  - `pushes every:` – the server streams re-renders over SSE, with an immediate first frame for new subscribers
+  - `triggers "event"` – announce action responses to the rest of the page
+  - `includes Other` – companion components ride along out-of-band in action responses
+  - `recovers from:, with:` – declarative error behavior per class
+- **Auto-routing** – Components route at `/_components/<name>` and pages at name-derived paths, with the conventional class-name suffix stripped (`OrdersPanelComponent`, `OrdersPanel`, and `DashboardPage`, `Dashboard` all route without ceremony):
+  - Explicit overrides via `self.page_path` and `self.component_path =`; global knobs for the component prefix and stream suffix
+  - Routability inferred from declared state, with `abstract!` / `routable!` as escape hatches
+  - SSE stream endpoints generated automatically for every pushing component
+- **Route collision detection** – Two routable classes resolving to the same effective path raise `Weft::InvalidDefinition` naming both, lazily on the first request. Code reloaders that redefine a class prune the stale registration automatically; `Weft.registry.clear` gives reload integrations and tests a full reset
+- **Element kwargs** – `action:`, `loads:`, `trigger:`, `navigate:`, and `push_url:` work on any element at any nesting depth, with `target:` and `swap:` refinements on `loads:` and the shorthands. Raw htmx attributes pass through untouched, side by side with what the kwargs expand to
+- **Interaction shorthands** – `tooltip:`, `modal:`, `lazy:`, `load_more:`, `infinite_scroll:`, `live_search:`, `tabs:`, `inline_expand:`, and `retry:` — named presets over the `loads:` machinery with the trigger and swap details baked in. Register your own vocabulary with `Weft.register_shorthand`
+- **Error handling** – A semantic error family under `Weft::Error` (`InvalidConfiguration`, `InvalidDefinition`, `InvalidUsage`, and the `HTTPError` classes such as `Weft::NotFound` and `Weft::Unprocessable`):
+  - The `recovers` chain renders declared fallbacks with semantic status codes (a validation failure is a `422` whose body is the component wearing its error state)
+  - Recovery targets receive schema-gated context — `:exception`, `:request_path`, `:status_code`, `:component_id`, `:retry_url` — only where declared
+  - Brand the defaults app-wide via the `error_component` / `error_page` / `not_found_page` / `not_found_component` knobs, or per class with explicit `recovers` declarations
+  - The gem-default error components offer one-click retry via the `retry:` shorthand
+- **Configuration** – `Weft.configure` covers development reloading (`auto_reload`, `reload_paths`), logging (`Weft.logger`, stdout by default; `log_level`, `router_logging`), static asset bundles (`static_assets` with named bundles, path-containment checks, and `assets:` resolution on `register_stylesheet` / `register_script`), htmx delivery (`include_htmx`, `include_sse_ext`), and routing (`component_path`, `stream_suffix`)
+- **Security posture** – The htmx core and SSE-extension scripts Weft includes are subresource-integrity pinned; `register_script` forwards `integrity:` / `crossorigin:` (and any other attributes) to the tag for your own CDN scripts
+- **Documentation** – A complete set under `docs/`: a build-your-first-app tutorial; references for the DSL, routing, error handling, configuration, and the Arbre HTML layer; an application-patterns guide (service objects, databases, background jobs, authentication, CSRF, testing); and a twenty-one-page examples catalog with captured wire traffic that deliberately covers the ground of htmx's own examples
+- **Demo app** – A complete Sinatra + Weft application under `demo/`, exercising the feature surface end to end

data/LICENSE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Andy Rusterholz
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

data/README.md

@@ -0,0 +1,150 @@
+# Weft
+
+**Component-oriented hypermedia for Ruby.**
+
+Weft lets you write your application in terms of its interface: components declare their structure, their data, and their interactive behaviors, and the framework derives the routing, request handling, and client-side wiring automatically.
+
+```ruby
+class DeliveryStatus < Weft::Component
+  attribute :delivery_id
+
+  refreshes every: 5.seconds
+
+  performs :cancel do |attrs|
+    delivery = Delivery.find(attrs.delivery_id)
+    CancelDelivery.call(delivery)
+  end
+
+  def build(attributes = {})
+    super
+    delivery = Delivery.find(attrs.delivery_id)
+    div(class: "delivery-status") do
+      progress value: delivery.progress, max: 100
+      button "Cancel", action: :cancel if delivery.cancelable?
+      span "Arriving #{delivery.eta}"
+    end
+  end
+end
+```
+
+That's a complete, interactive UI component. It polls for updates every 5 seconds. The cancel button invokes a service and re-renders the result. There's no routes file, no controller, no custom JavaScript — just Ruby describing what the UI is and what it does. The UI is the source of truth; the plumbing is implied.
+
+Weft is built on [Arbre](https://github.com/activeadmin/arbre) for HTML generation and [htmx](https://htmx.org) for hypermedia interactions. It runs standalone as a lightweight Sinatra-backed server, or mounts as middleware inside any existing Rack app. No build step, no npm, no hydration — just Ruby, HTML, and HTTP.
+
+### The verbs
+
+Components declare their dynamic behaviors with verbs:
+
+| Verb | What it does |
+|------|-------------|
+| `refreshes every: 5.seconds` | Client re-fetches on a timer |
+| `refreshes on: "event"` | Client re-fetches when a page event fires |
+| `pushes every: 5.seconds` | Server streams re-renders over SSE |
+| `performs :name` | User-initiated action: runs your callable, re-renders |
+| `transfers :name, to: Other` | Action that renders a different component in this one's place |
+| `dismisses :name` | Action that removes the component from the DOM |
+| `triggers "event"` | Announces this component's actions to the rest of the page |
+| `includes Other` | Companion components ride along in action responses, out-of-band |
+| `recovers from: Err, with: Fallback` | Declares what renders when something raises |
+
+Elements get their own vocabulary — `action:`, `loads:`, `trigger:` kwargs and interaction shorthands like `tooltip:`, `modal:`, `lazy:`, `infinite_scroll:` — all covered in [the DSL reference](docs/dsl.md).
+
+## Documentation
+
+- **[Build your first Weft app](docs/tutorial.md)** — the tutorial: empty directory to a working app with pages, components, a validated form action, and live updates.
+- **[Examples](docs/examples/README.md)** — twenty-one worked patterns with captured wire traffic. Coming from htmx? This catalog deliberately covers the ground of htmx's own examples.
+- **[The Weft DSL](docs/dsl.md)** — every verb, element kwarg, and interaction shorthand.
+- **[Application patterns](docs/app-patterns.md)** — the app around the components: service objects, databases, background jobs, authentication, CSRF, assets, and testing.
+- **[Arbre: the HTML layer](docs/arbre.md)** — the HTML builder inside every `build` method, in depth.
+- **[Routing](docs/routing.md)** — how classes become URLs, what's routable, and collision detection.
+- **[Error handling](docs/error-handling.md)** — the error classes, recovery chains, and branding your error pages.
+- **[Configuration](docs/configuration.md)** — every setting.
+
+## Roadmap & Availability
+
+| Version | Features | Status |
+|---------|---------|--------|
+| v0.1.0 | First usable release: the verb DSL, auto-routing with collision detection, interaction shorthands, SSE, error recovery, full documentation set | **Current** |
+| v0.2 | Attribute hydration (resolver reification), child-component ergonomics, SSE error recovery, Zeitwerk integration | Next |
+
+## Installation
+
+Weft requires Ruby 3.2 or newer. Add it to your Gemfile:
+
+```ruby
+gem "weft"
+```
+
+Then run:
+
+```bash
+bundle install
+```
+
+## Usage
+
+Weft mounts into your Rack app in one of two shapes, depending on whether Weft is the entire application or just a part of one.
+
+### Standalone — Weft is the app
+
+For a fully Weft-powered application, run `Weft::Router` as the Rack app itself:
+
+```ruby
+# config.ru
+require_relative "config/environment"   # loads your components and pages
+
+run Weft::Router
+```
+
+Components and pages auto-route based on their class declarations: components serve HTML fragments under `/_components/<name>`, pages serve full documents at their `page_path` (or a name-derived default). If two routable classes would resolve to the same path, Weft raises on the first request, naming both. [Routing](docs/routing.md) has the full story, and [the tutorial](docs/tutorial.md) walks through a working `config/environment.rb`.
+
+### As middleware — alongside an existing app
+
+For adding Weft to an existing Rack app (Sinatra, Rails, anything Rack), mount it as middleware. Unmatched paths fall through to your downstream app:
+
+```ruby
+# config.ru
+require_relative "config/environment"
+require_relative "app"   # your existing application
+
+use Weft::Router
+run MyApp
+```
+
+### Configuration
+
+`Weft.configure` exposes gem-level settings — the two you'll want on day one are the development reloader flags:
+
+```ruby
+Weft.configure do |c|
+  c.auto_reload = (ENV.fetch("RACK_ENV", "production") == "development")
+  c.reload_paths = [File.expand_path("app/**/*.rb", __dir__)]
+end
+```
+
+Everything else — static asset bundles, error presentation, routing overrides, logging — is in [the configuration reference](docs/configuration.md).
+
+### Customizing error and not-found pages
+
+Assign your own fallback classes once, and every recovery path uses them:
+
+```ruby
+Weft.configure do |c|
+  c.error_component = MyApp::ErrorComponent
+  c.not_found_page = MyApp::NotFoundPage
+end
+```
+
+Per-class `recovers` declarations override the app-wide fallbacks where you need finer grain. [Error handling](docs/error-handling.md) covers the error classes, the recovery chain, and the attributes your fallback pages can receive.
+
+## Contributing
+
+Bug reports and pull requests are welcome on GitHub at https://github.com/rusterholz/weft. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [code of conduct](CODE_OF_CONDUCT.md).
+
+## License
+
+The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
+
+## Code of Conduct
+
+Everyone interacting in the Weft project's codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](CODE_OF_CONDUCT.md).

data/docs/app-patterns.md

@@ -0,0 +1,268 @@
+# Application patterns
+
+The [tutorial](tutorial.md) gets an app running, and the reference docs cover each mechanism on its own. This page is about the application *around* the components — where things live as a Weft app grows, and how the rest of your stack plugs in.
+
+The theme throughout: Weft is deliberately small. It owns pages, components, and the wiring between user actions and renders. Everything else — your data, your background jobs, your authentication, your assets — is ordinary Ruby on ordinary Rack, and each has a well-defined seam.
+
+## Laying out a growing app
+
+The tutorial's layout extends naturally:
+
+```
+my-app/
+├── config.ru
+├── config/
+│   └── environment.rb
+├── app/
+│   ├── components/
+│   ├── data/          # stores, models, Current — your data layer
+│   ├── pages/
+│   └── services/      # business operations
+└── spec/
+```
+
+`config/environment.rb` grows one entry in its load list:
+
+```ruby
+%w[data services components pages].each do |dir|
+  Dir[File.join(APP_ROOT, "app", dir, "*.rb")].sort.each { |file| require file }
+end
+```
+
+The ordering carries the same rule the tutorial explains: files that *define* things load before files that *reference* them in class bodies (`includes AttendeeList`, `transfers to: Confirmation`). Data and services never reference components, components reference each other and the data layer, pages compose components — so data → services → components → pages loads cleanly. When alphabetical luck within a directory stops being enough, that's the sign your app has outgrown the glob and wants a real autoloader like Zeitwerk.
+
+## Where business logic goes
+
+Components own what the user **sees and does** — the markup, the affordances, and the immediate response to an action. They should not own your business rules.
+
+The dividing line runs through the action callable. A callable is a translation layer: attributes in, one operation invoked, a hash out for the re-render. The moment the middle step grows past a few lines — multiple records, a transaction, an email, a job — it belongs in a plain Ruby service object:
+
+```ruby
+# app/services/comment_poster.rb
+class CommentPoster
+  def self.call(author:, body:)
+    author = author.to_s.strip
+    body = body.to_s.strip
+    return :blank if author.empty? || body.empty?
+
+    GUEST_COMMENTS << { author: author, body: body }
+    :posted
+  end
+end
+```
+
+```ruby
+# in the component
+performs :post do |attrs|
+  CommentPoster.call(author: attrs.author, body: attrs.body)
+  { author: nil, body: nil }
+end
+```
+
+The service knows nothing about components or HTML; the component knows nothing about how a post actually happens. Two details worth noticing:
+
+- **End the callable with the hash you mean.** A callable's return value merges into the attributes for the re-render *if it's a hash* — anything else is discarded (see [the callable contract](dsl.md#the-callable-contract)). Delegating to a service and then returning your own hash, as above, keeps the wire state deliberate even when the service's return value changes.
+- **The service returns plain Ruby values** (`:posted`, `:blank`, a record, a result object — whatever fits). When the component needs to branch on the outcome, branch in the callable and translate to attributes; the service still shouldn't know what a DOM id is.
+
+## Databases
+
+Weft has no data layer and no ORM opinion. `build` methods and callables are plain Ruby, so `Event.find(...)`, `DB[:events].where(...)`, and a hand-rolled store are all the same to Weft — the examples' data-constant stubs stand in for whichever you choose. ActiveRecord in standalone mode, Sequel, ROM, or a bare adapter are all equally at home; establish the connection in `config/environment.rb` before the app files load, and your components can use it from the first render.
+
+One operational honesty about the in-memory stores the tutorial and examples use: module-level state is **per-process**. That's exactly right for learning and development, and exactly wrong under a multi-process server — each Puma worker gets its own copy, and they drift immediately. The moment state needs to be shared or survive a restart, it belongs in a real database (or Redis, or any store that lives outside the app process).
+
+## Background jobs
+
+Weft doesn't run jobs, but it has a natural shape for showing their progress: **a job writes to the store; a component watches the store**.
+
+The pattern in three steps:
+
+1. **The action dispatches and returns.** A user action that starts long work shouldn't wait for it — the callable enqueues the job (Sidekiq, SolidQueue, GoodJob, a `Thread` in development — Weft doesn't care) and returns immediately with whatever attributes render the "started" state.
+2. **The job writes progress to the shared store** as it works: a status column, a percentage, a result row. The job knows nothing about components.
+3. **The component re-renders on a cadence** — [`refreshes every:`](dsl.md#refreshes--the-client-re-fetches) polls, [`pushes every:`](dsl.md#pushes--the-server-sends-updates) streams over SSE — and each render just reads the store. Completion isn't an event to handle; it's data the next render picks up.
+
+The [Progress Bar](examples/progress-bar.md) example is this exact lifecycle, verified end to end — a Start action kicking off a background worker, a polling component advancing as the store changes, a finished state with a Restart affordance. [Live Ticker](examples/live-ticker.md) is the SSE variant. Both pages show precisely what travels on the wire.
+
+## Authentication and sessions
+
+Weft is deliberately session-agnostic: no cookie handling, no `current_user`, no login machinery. Identity is your app's concern, handled with standard Rack pieces in front of the Router. What Weft *does* define is the seam, and it's narrower than you might expect:
+
+> Components and callables receive exactly their **resolved attributes** — values from request parameters, filtered through each component's declared schema. Session state and request headers are not part of that channel.
+
+So per-request identity needs its own channel. The pattern that fits — the same one Rails blesses as `Current` — is a [`CurrentAttributes`](https://api.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html) object set by middleware. Weft already depends on ActiveSupport, so it's available without adding anything:
+
+```ruby
+# app/data/current.rb
+require "active_support"
+require "active_support/current_attributes"
+
+class Current < ActiveSupport::CurrentAttributes
+  attribute :user, :csrf_token
+end
+```
+
+(The bare `require "active_support"` line matters: requiring only `current_attributes` fails on recent ActiveSupport versions, which expect the framework's base to be loaded first.)
+
+A small middleware reads the session once per request, exposes it through `Current`, and — importantly — always resets afterwards, so state never leaks between requests on a reused thread:
+
+```ruby
+class CurrentScope
+  def initialize(app)
+    @app = app
+  end
+
+  def call(env)
+    session = env["rack.session"]
+    Current.user = session["user"]
+    Current.csrf_token = Rack::Protection::AuthenticityToken.token(session)
+    @app.call(env)
+  ensure
+    Current.reset
+  end
+end
+```
+
+Session *writes* — logging in and out — live outside Weft components, in any Rack endpoint you own. A tiny Sinatra app is plenty, mounted beside the Router:
+
+```ruby
+class AuthApp < Sinatra::Base
+  post "/login" do
+    session["user"] = params["name"]
+    redirect "/", 303
+  end
+
+  post "/logout" do
+    session.delete("user")
+    redirect "/", 303
+  end
+end
+```
+
+`config.ru` assembles the stack — session first, then protection, then `CurrentScope`, then the apps:
+
+```ruby
+require_relative "config/environment"
+require "rack/session"
+require "rack/protection"
+require "sinatra/base"
+
+use Rack::Session::Cookie, secret: ENV.fetch("SESSION_SECRET")  # 64+ characters
+use Rack::Protection::AuthenticityToken
+use CurrentScope
+
+map "/auth" do
+  run AuthApp
+end
+
+run Weft::Router
+```
+
+From there, any component can read identity like any other Ruby value:
+
+```ruby
+class WhoAmI < Weft::Component
+  builder_method :who_am_i
+
+  def build(attributes = {})
+    super
+    if Current.user
+      para "Signed in as #{Current.user}."
+      form(action: "/auth/logout", method: "post") do
+        input type: "hidden", name: "authenticity_token", value: Current.csrf_token
+        input type: "submit", value: "Sign out"
+      end
+    else
+      para "You're browsing anonymously."
+      form(action: "/auth/login", method: "post") do
+        input type: "hidden", name: "authenticity_token", value: Current.csrf_token
+        label "Name ", for: "name"
+        input type: "text", name: "name", id: "name"
+        input type: "submit", value: "Sign in"
+      end
+    end
+  end
+end
+```
+
+Note the form lines: `action:` with a **string** renders as a plain HTML `action` attribute — an ordinary full-page form post to your auth endpoint, no htmx involved. It's only `action:` with a **symbol** that wires up a Weft component action. The two coexist naturally: identity changes full pages; component actions swap fragments.
+
+(This example stores the user's name in the session directly to stay small; a real app stores an id and has `CurrentScope` — or a lazy reader on `Current` — hydrate the user record.)
+
+Authorization follows the same grain: middleware can gate whole path prefixes before Weft ever sees the request, and components can branch on `Current.user` to decide which affordances to render. For anything destructive, check authority *in the action's service call* too — component actions are plain HTTP endpoints, and markup you didn't render is not a guarantee nobody sends the request.
+
+## CSRF protection
+
+The stack above already includes it. `Rack::Protection::AuthenticityToken` (part of rack-protection, which ships with Sinatra) rejects any non-GET request that doesn't carry a valid token — **including every Weft action form**, since those are ordinary POSTs. Two pieces make it work:
+
+1. `CurrentScope` computes the session's token via `Rack::Protection::AuthenticityToken.token(session)` and exposes it as `Current.csrf_token`.
+2. Every form gains one hidden input:
+
+```ruby
+input type: "hidden", name: "authenticity_token", value: Current.csrf_token
+```
+
+That covers both transports at once: the htmx path (a form's fields are its payload) and the no-JS fallback submit carry the same field. A missing or stale token is a `403` before the request reaches any component; with the token, actions behave exactly as before. Weft has no form helper to inject this automatically today, so the hidden input is per-form — a base component class of your own is a fine place to fold it into a one-liner.
+
+## Assets
+
+The seam is [`static_assets`](configuration.md#static_assets): register a directory as a named bundle, and `register_stylesheet` / `register_script` resolve bare-relative paths against it. Whatever produces the files — esbuild, Vite, Tailwind's CLI, Sprockets, or a `cp` in your Makefile — Weft only needs to know the output directory:
+
+```ruby
+Weft.configure do |c|
+  c.static_assets root: "/assets", from: File.join(APP_ROOT, "public/assets")
+end
+```
+
+Point your bundler's output at that directory and the integration is done. The [configuration reference](configuration.md#static_assets) covers multiple bundles, environment-specific roots, and the resolution rules.
+
+## Testing the whole app
+
+[Component unit testing](arbre.md#testing-components) needs no server: `Component.render(**attrs)` returns the HTML string. For request-level coverage — routes, actions, status codes, wire payloads — use Rack::Test against the Router:
+
+```ruby
+# spec/spec_helper.rb
+ENV["RACK_ENV"] ||= "test"
+
+require "rack/test"
+require_relative "../config/environment"
+
+RSpec.configure do |config|
+  config.before(:each) do
+    GUEST_COMMENTS.replace([{ author: "Rosa", body: "Lovely event — count me in for next year." }])
+  end
+end
+```
+
+```ruby
+# spec/router_spec.rb
+RSpec.describe "the app through Weft::Router" do
+  include Rack::Test::Methods
+
+  def app = Weft::Router
+
+  it "serves a component fragment" do
+    get "/_components/comment_section"
+    expect(last_response.status).to eq(200)
+    expect(last_response.body).to include("Rosa")
+  end
+
+  it "runs an action" do
+    post "/_components/comment_section/post", author: "Test", body: "From a spec."
+    expect(last_response.status).to eq(200)
+    expect(last_response.body).to include("Test")
+  end
+end
+```
+
+Two lines in that helper do quiet, load-bearing work:
+
+- **`ENV["RACK_ENV"] ||= "test"`.** Without it, specs run in Sinatra's development mode, whose DNS-rebinding host protection rejects Rack::Test's default host — every request comes back `403 Host not permitted` before reaching your app. The test environment permits it.
+- **The `before(:each)` reset.** Weft doesn't own your data layer, so state between examples is your responsibility — replace the in-memory store's contents, truncate tables, or run each example in a transaction, per your data layer's usual practice.
+
+These specs hit `Weft::Router` directly, bypassing whatever middleware `config.ru` stacks in front — which is usually what you want when the subject is component behavior. (It's also why the action POST above needs no CSRF token: the protection middleware isn't in the loop.)
+
+## Where to go from here
+
+- [The examples catalog](examples/README.md) — worked patterns with captured wire traffic, including the [Progress Bar](examples/progress-bar.md) job lifecycle.
+- [The Weft DSL](dsl.md) — the callable contract, every verb, every kwarg.
+- [Routing](routing.md#mounting-the-router) — standalone vs. middleware mounting in detail.
+- [Configuration](configuration.md) — static assets, reloading, error presentation.