brut 0.17.0 → 0.18.0

data/brutrb.com/keyword-injection.md

@@ -1,195 +0,0 @@
-# Keyword Injection
-
-Brut is desiged around classes and objects, as compared to modules and DSLs.  Almost everything you do when building your app is to create a class that has an initializer and implements one or more methods.  But, these classes often need information from the request that Brut is managing.
-
-In a basic Rack or Sinatra app, you would access this information via Rack's API, which is essentially a Hash of Whatever. It's error-prone and requires consulting documentation, source code, or runtime information to figure out what's stored where.
-
-Brut can instead inject these values explicitly into the classes of yours it creates.  It does this based on the
-names of keyword arguments declared by your class' intializer.
-
-## Overview
-
-A [Page](/pages) may need the session, flash, HTTP headers, query string parameters, or placeholder values from the URI.  These can all be provided by declaring them as keyword arguments to the page's initializer:
-
-```ruby
-clas WidgetsByIdPage < AppPage
-  def initialize(id:,                # ":id" from /widgets/:id
-                 session:,           # AppSession instance for this request
-                 flash:,             # Flash for this request
-                 http_user_agent:,   # Value of User-Agent header
-                 compact:)           # query string param "compact"
-
-    # ...
-  end
-end
-```
-
-Brut uses this technique in multiple places.  It allows you to design classes whose
-dependencies are clear and explicit, but without having to dig around into hashes or
-manually construct higher-level objects.
-
-
-### Standard Injectible Information
-
-In any request, the following information is available to be injected:
-
-| Value                      | Always Present?                                                                                                                                                                                                    | Description                                                                                     |
-| ---                        | ---    | ----                                                                                            |
-| `session:`                 | ✅ Yes | An instance of your app's `Brut::FrontEnd::Session` subclass for the current visitor's session. |
-| `flash:`                   | ✅ Yes | An instance of your app's `Brut::FrontEnd::Flash` subclass.                                                                                                                                                        |
-| `xhr:`                     | ✅ Yes | true if this was an Ajax request.                                                                                                                                                                                  |
-| `body:`                    | ✅ Yes | the body submitted, if any.                                                                                                                                                                                        |
-| `csrf_token:`              | ✅ Yes | The current CSRF token.                                                                                                                                                                                            |
-| `clock:`                   | ✅ Yes | A `Clock` to be used to access the current time in the visitor's time zone.                                                                                                                                        |
-| `http_*`                   | ❌ No  | any parameter that starts with `http_` is assumed to be for an HTTP header. For example, `http_accept_language` would be given the value for the "Accept-Language" header.  See the section on HTTP headers below. |
-| `rack_request_*:`          | ❌ No  | Any value from the [`Rack::Request`](https://rubydoc.info/gems/rack/3.1.16/Rack/Request) or, more likely, from the [`Helpers`](https://rubydoc.info/gems/rack/3.1.16/Rack/Request/Helpers) module.                 |
-| `env:`                     | ✅ Yes | The Rack env.  This is discouraged, but available if you can't get what you want directly                                                                                                                          |
-| `form:`                    | ❌ No  | The [form](/forms) that was submitted, for [handlers](/handlers) only                                                                                                                                              |
-| Any query string parameter | ❌ No  | For [pages](/pages) only                                                                                                                                                                                           |
-| Any route placeholder      | ✅ Yes | For [pages](/pages) and [handlers](/handlers)                                                                                                                                                                      |
-
-#### Route Hooks
-
-[Route hooks](/hooks) are slightly different.  They have access to only these
-values:
-
-| Name               | Always Present? | Description                                                                                                                      | 
-| ---                | ---             | --- |
-| `request_context:` | ❌ No           | The current `Brut::FrontEnd::RequestContext`, thought it may be `nil` if the hook runs before `Brut::FrontEnd::InlineSvgLocator` |
-| `session:`         | ✅ Yes          | An instance of your app's `Brut::FrontEnd::Session` subclass for the current visitor's session.                                  |
-| `request:`         | ✅ Yes          | The Rack request                                                                                                                 |
-| `response:`        | ✅ Yes          | The Rack response                                                                                                                |
-| `env:`             | ✅ Yes          | The Rack env.                                                                                                                    |
-
-#### HTTP Headers
-
-Since any header can be sent with a request, Brut allows you to access them, including non-standard ones.  Rack (which is based on CGI), provides access to all HTTP headers in the `env` by taking the header name, replacing dashes ("-") with underscores ("\_"), and prepending `http_` to the name, then uppercasing it.  Thus, "User-Agent" becomes `HTTP_USER_AGENT`.
-
-Because Ruby parameters and variables must start with a lower-case letter, Brut uses the lowercased version of the Rack/CGI variable.
-Thus, to receive the "User-Agent", you would declare the keyword parameter `http_user_agent`.
-
-Further, because headers come from the client and may not be under your control, the value that is actually injected depends on a few
-things:
-
-* If your keyword arg is required, i.e. there is no default value:
-  - If the header was not provided, `nil` is injected.
-  - If the header *was* provided, it's value is injected, even if it's the empty string.
-* If your keyword arg is optional, i.e.  it has a default value
-  - If the header was not provided, no value is injected, and your code will receive the default value.
-  - If the header *was* provided, it's value is injected, even if it's the empty string.
-
-### Injecting Custom Data
-
-The true power of keyword injection is that you can store your own data into the
-request context and have it injected into classes when Brut instantiates them.
-
-The place to do this is in a [before hook](/hooks), since that happens before any
-page or handler is created, but *after* the `Brut::FrontEnd::RequestContext` is
-created (which is where all of this information is stored).
-
-For example, here is how you might inject the currently logged-in account based on the session:
-
-```ruby
-class AuthBeforeHook < Brut::FrontEnd::RouteHook
-  def before(request_context:,session:)
-    if session.authenticated_account
-      request_context[:authenticated_account] = session.authenticated_account
-    end
-    continue
-  end
-end
-```
-
-Note that the value is only injected if it exists.  It's important not to inject `nil` for values that don't exist.
-
-With this in place, any page that requires an authenticated account can declare it:
-
-```ruby
-class PreferencesPage < AppPage
-  def initialize(authenticated_account:)
-    # ...
-  end
-end
-```
-
-If the request context has no value for `authenticated_account`, the page cannot be
-instantiated.  Thus, the page's code can always rely on a non-`nil` value for
-`authenticated_account` (provided you don't inject `nil`).
-
-> [!WARNING]
-> Do not inject `nil` into the request context.  Brut currently allows
-> it, but may prevent it in a future update. `nil` is no good for nobody.
-
-### When Values Aren't Available
-
-When a value is not available for injection, and the keyword doesn't provide a default, Brut will raise an error.  This is because
-such a situation represents a design error.
-
-The tables above document which values should always be available. You should never
-provide a default value for these, e.g. `session:` or `env:`. For values that are
-not always available, you should provide a default value unless you are sure there
-will be no routing to the page or handler without the value set.
-
-This is most important for query string parameters.  Since a user can easily
-manipulate these, if your page accepts, say, the parameter `use_detailed_view`, but
-that parameter isn't present, Brut will not be able to instantiate your page unless
-`use_detailed_view:` has a default value in the initializer's keyword arguments.
-
-See [route hooks](/hooks).
-
-## Testing
-
-Brut will not create your classes in a test.  Instead, you must pass in the values you want.  There are various
-helpers in `Brut::SpecSupport` to create blank or empty versions of the special classes.
-
-In particular, A basic `request_context` is setup per test and injected into the Thread local storage. This means
-that if your test should trigger a codepath that *does* cause Brut to use keyword injection, useful values will
-be injected.
-
-For your tests, however, you should pass in directly what you need:
-
-```ruby
-page = WidgetsByIdPage.new(id: widget.id, session: empty_session)
-```
-
-## Recommended Practices
-
-Consider a method like so:
-
-``` ruby
-def create_widget(name:, organization: nil, quantity: 10)
-```
-
-Outside of Brut, the way to interpret this arguments is as follows:
-
-* `name` is required
-* `organization` is optional
-* `quantity` has a default value of 10 if not provided
-
-Any method or intializer that will be keyword-injected should be designed with this in mind.  Thus, the following guidelines will be helpful in managing your app:
-
-* **Do not provide default values when Brut documents the value is always
-available**
-  - If your page needs the session, it will always be there. Don't default `session:` to some other value (especially `nil`!)
-* **Choose arguments based on the needs of the class:**
-  - If a value is optional, default it to either `nil` or a symbol that indicates what happens when the value is omitted
-  - If an optional value has a default, use that (this should be rare for pages, handlers, components, and hooks)
-  - Otherwise, do not provide a default for the keyword
-* **Design for non-`nil` values instead of allowing `nil` and checking for it**
-  - If a page needs, say, the currently logged-in user, set that up as injectible with no default.
-  - If a codepath creates that page without the logged-in user, you will get a very obvious error and
-    can figure out how it happened. Your page's code doesn't need to figure out what to do with `nil`
-* **Do not inject `nil` into the request context.** When your code requires a value for a keyword, you want to rely on that value being non-nil.  Thus, avoid injecting `nil` into the request context. Brut will allow it as a sort-of escape hatch, but you should design your app to avoid it
-* **Be careful injecting global data.**  The request context instance is per request, but you could certainly put global data into it. For example, you may put an initialized API client into the request context as a convieniece. **Be careful** because your app is multi-threaded.  Any object that is not scoped to the request must be thread-safe.
-
-## 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_
-
-Keyword injection is currently implemented in a few places and not available via public API.  It could be useful
-as an API and it will be exposed at some point. For now, it's only available for Brut-managed classes as
-documented here.

data/brutrb.com/layouts.md

@@ -1,156 +0,0 @@
-# Layouts
-
-Brut supports *layouts*, which are a way to centralizing common HTML amongst many
-different pages.  Conceptually, they are the same as a Rails layout.  Technically, they are a Phlex component designed to render a page from a `yield` block.
-
-## Overview
-
-Your app should include `app/src/front_end/layouts/default_layout.rb`. The name
-"default" isn't special, it's just what the `layout` method from
-`Brut::FrontEnd::Page` returns.
-
-A layout is a Phlex component that's expected to have a single call to `yield` in
-its `view_template` method.
-
-### Default Layout and Common Layout Needs
-
-Here is the `DefaultLayout` provided to new Brut apps:
-
-```ruby {33}
-class DefaultLayout < Brut::FrontEnd::Layout
-  include Brut::FrontEnd::Components
-
-  def initialize(page:)
-    @page = page
-  end
-
-  def view_template
-    doctype
-    html(lang: "en") do
-      head do
-        meta(charset: "utf-8")
-        meta(content: "width=device-width,initial-scale=1", name:"viewport")
-        meta(content: "website", property:"og:type")
-        link(rel: "manifest",  href: "/static/manifest.json")
-        link(rel: "preload", as: "style", href: asset_path("/css/styles.css"))
-        link(rel: "stylesheet",           href: asset_path("/css/styles.css"))
-        script(defer: true, src: asset_path("/js/app.js"))
-        title { app_name }
-        PageIdentifier(page)
-        I18nTranslations("cv.cs")
-        I18nTranslations("cv.this_field")
-        Traceparent()
-        render(
-          Brut::FrontEnd::RequestContext.inject(
-            Brut::FrontEnd::Components::LocaleDetection
-          )
-        )
-      end
-      body do
-        brut_tracing url: "/__brut/instrumentation", show_warnings: true
-        main class: page.page_name do
-          yield
-        end
-      end
-    end
-  end
-end
-```
-
-You will likely want to customize what's in your layout, but a few components
-included by default are important for other features of Brut:
-
-| Component | Purpose
-|---|---|
-| `Brut::FrontEnd::Components::PageIdentifier` | Creates a `<meta>` tag with the page's name in it, which is handy for managing your end-to-end tests. |
-| `Brut::FrontEnd::Components::I18nTranslations` | Includes translatsion for common client-side constraint violations.  These are used by `<brut-cv-messages>` and `,brut-cv>`. See [Forms](/forms), [I18n](/i18n), and [JavaScript](/javascript) for more details |
-| `Brut::FrontEnd::Components::Traceparent` | Includes the OpenTelemetry *traceparent* on the page so that client-side telemetry is reported back to the server.  See `<brut-tracing>` and [observability](/instrumentation) |
-| `<brut-tracing>` / `brut_tracing` | Custom element that collects the client-side telemetry and sends it back to the server. See [observability](/instrumentation) |
-
-### Adding Logic/Dynamic Behavior to Layouts
-
-Often, your pages will need to make slight tweaks to the layout that don't apply to all pages. For example, you may wish for a certain page to refresh on a schedule and you want to do that with a [meta refresh](https://en.wikipedia.org/wiki/Meta_refresh), which must appear in the `<head>` of the page.
-
-Unlike Rails, which uses named blocks to render optional or dynamic content, Brut allows you to use methods and normal Ruby-based flow logic.  Since your layouts have access to the page they are laying out, you can use your pages' APIs to do whatever it is you need.
-
-Taking the meta refresh example, suppose your `AppPage` defines a method, `auto_refresh_seconds` that, if non-`nil` means your page should automatically reload itself after that many seconds.  By default, you don't refresh, so it returns `nil`:
-
-```ruby
-class AppPage < Brut::FrontEnd::page
-
-  # ...
-
-  def auto_refresh_seconds = nil
-
-  # ...
-end
-```
-
-Your layout can refrence this API, since it's just a method on a class:
-
-```ruby
-class DefaultLayout < Brut::FrontEnd::Layout
-
-  # ...
-
-  def view_template
-    doctype
-    html(lang: "en") do
-      head do
-        if page.auto_refresh_seconds
-          meta(http_equiv: safe("refresh"), content: page.auto_refresh_seconds)
-        end
-
-        # ...
-  end
-  # ...
-end
-```
-
-Since your pages are a class hierarchy, you can override `auto_refresh_seconds` in any page, and that page will automatically refresh itself:
-
-```ruby
-class DashboardPage < AppPage
-
-  def auto_refresh_seconds = 60 * 60
-
-  # ...
-
-end
-```
-
-### Alternate Layouts
-
-If you used `mkbrut`, you should have access to a `BlankLayout` that is useful for allowing a page to respond to Ajax requests:
-
-```ruby
-class SomePage < AppPage
-  def layout = "blank"
-end
-```
-
-See [creating alternate layouts](/recipes/alternate-layouts) for more information on creating alternate layouts based on your needs.
-
-## Testing
-
-You generally don't test a layout, aside from end-to-end tests.  If your layout
-needs complex logic, you are encouraged to extract that to a
-[component](/components) and test that instead.
-
-## Recommended Practices
-
-Layouts can use components, just keep in mind that any data a component needs must
-be passed to its initializer. Since the layout doesn't have access to the page, this
-implies that components used in your layout must either not require dynamic data or
-be [global components](/components#global-components)
-
-## 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 Sep 9, 2025_
-
-Layouts work due to the implementation of the method `view_template` in `Brut::FrontEnd::Page`. This is why a page class must provide `page_template` instead.
-

data/brutrb.com/lsp.md

@@ -1,23 +0,0 @@
-# Language Server Protocol (LSP) Support
-
-Because Brut development happens inside Docker, but your editor likely runs on your
-computer, getting LSP servers running takes a few more steps.
-
-## Overview
-
-When you created your app with `mkbrut`, the following LSP-related modules are set
-up and/or installed:
-
-* Shopify's Ruby LSP server (installed from `bin/setup`)
-* Microsoft's TypeScript/JavaScript and CSS LSP serfvers (specified in `package.json`, installed when `npm install` runs from `bin/setup`)
-
-In order to use them from your computer a few configurations are needed, some of
-which Brut has done, and some you will need to do.
-
-| Configuration | Description | Brut Handled? |
-|---|---|---|
-| Paths inside Docker Must Match Your Computer | When an LSP server communicates about a file, it does so with a path. That means that paths inside the Docker container must be the same as those on your computer.  Brut achievecs this by using `${CWD}` inside `docker-compose.dx.yml` | ✅ |
-| Third party libraries must *also* be installed in a path that is the same in both places | When jumping to a definition, the LSP server will again use paths, which must match.  Because Node modules are installed local to your app, they already work.  Ruby Gems, however, are configured to be installed in `local-gems` in your app.  Brut should've added this to `.gitignore` and setup everything inside Docker to use it. | ✅ |
-| Your editor must use `dx/exec` to execute LSP commands | Your editor will need to know that the LSP servers are running inside Docker.  If your editor allows configuring the commands used to do this, you must prefix them with `dx/exec`. See [my blog post](https://naildrivin5.com/blog/2025/06/12/neovim-and-lsp-servers-working-with-docker-based-development.html) for details. | ❌ |
-| Other languages or plugins to existing LSP servers | I haven't used these, so no idea how well they work. | ❌ |
-

data/brutrb.com/markdown-examples.md

@@ -1,85 +0,0 @@
-# Markdown Extension Examples
-
-This page demonstrates some of the built-in markdown extensions provided by VitePress.
-
-## Syntax Highlighting
-
-VitePress provides Syntax Highlighting powered by [Shiki](https://github.com/shikijs/shiki), with additional features like line-highlighting:
-
-**Input**
-
-````md
-```js{4}
-export default {
-  data () {
-    return {
-      msg: 'Highlighted!'
-    }
-  }
-}
-```
-````
-
-**Output**
-
-```js{4}
-export default {
-  data () {
-    return {
-      msg: 'Highlighted!'
-    }
-  }
-}
-```
-
-## Custom Containers
-
-**Input**
-
-```md
-::: info
-This is an info box.
-:::
-
-::: tip
-This is a tip.
-:::
-
-::: warning
-This is a warning.
-:::
-
-::: danger
-This is a dangerous warning.
-:::
-
-::: details
-This is a details block.
-:::
-```
-
-**Output**
-
-::: info
-This is an info box.
-:::
-
-::: tip
-This is a tip.
-:::
-
-::: warning
-This is a warning.
-:::
-
-::: danger
-This is a dangerous warning.
-:::
-
-::: details
-This is a details block.
-:::
-
-## More
-
-Check out the documentation for the [full list of markdown extensions](https://vitepress.dev/guide/markdown).

data/brutrb.com/middleware.md

@@ -1,80 +0,0 @@
-# Middleware
-
-Brut supports Rack Middleware.
-
-## Overview 
-
-Similar to [route hooks](/hooks), Brut supports Rack Middleware, which is a lower-level way of modifying a
-request or changing behavior.
-
-Middleware is recommended if what you want to do is not dependent on your application's code or classes
-and is relatively simple.
-
-To use a middleware, create the class in `app/src/front_end/middleware/`. You are encouraged to extend
-`Brut::FrontEnd::Middleware`, however this is an empty class currently. It could grow to have helper
-methods you'll find useful.
-
-The class itself should conform to Rack's specification, which is typically that it will be given the Rack
-"app" in the initializer, and then have a method `call` which will be given the Rack environment.
-
-Here's a middleware that adds a tag to the environment for paths that are "special" to our app, which in
-this case means they start with `/special`:
-
-```ruby
-class TagSpecialPathsMiddleware < Brut::FrontEnd::Middleware
-
-  def initializer(app)
-    @app = app
-  end
-
-  def call(env)
-    if env["PATH_INFO"] =~ /^\/special\//
-      env["app.special_path"] = true
-    end
-    @app.call(env)
-  end
-end
-```
-
-To use this middleware, call `use` with the class name as a string inside `App`:
-
-```ruby
-class App < Brut::Framework::App
-
-  # ...
-
-  use :TagSpecialPathsMiddleware
-
-  # ...
-end
-```
-
-Don't use the actual class as this can create load order issues.
-
-## Testing
-
-Like hooks, Rack middleware can be tested as a normal class.  That said, you are encouraged to test the
-middleware as part of an end-to-end test if possible, since this will ensure it's configured properly in
-the context of your app.
-
-## Recommended Practices
-
-Middleware should be used when its logic can be entirely based on the Rack environment passed-in.  While
-your database models and other classes should be available, excessive use of your domain logic in a
-middleware can create a confusing situation.
-
-## 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_
-
-Route hooks and Middlewares do not share implementations, however they are similar in concept.  These
-concepts may be unified in the future.
-
-`use` and the way Middleware behaves follows Sinatra's implementation as Brut is currently based on
-Sinatra. This may not always be the case, however as things change, we will do our best to ensure the
-semantics remain the same.  Nevertheless, it's advisable to have end to end tests assert the behavior of
-your configured middleware and not just a unit test of the class itself.

data/brutrb.com/overview.md

@@ -1,68 +0,0 @@
-# Conceptual Overview
-
-Brut is a way to build web apps that generate HTML, have JavaScript and CSS, and
-interact with a Database. It's built on Ruby standard libraries and community
-libraries like [Sequel](https://sequel.jeremyevans.net/) and
-[Phlex](https://phlex.fun).
-
-Brut's approach and design are built on three core values:
-
-* **Leverage Standards** - The web platform is great, and Brut wants you to use it.
-* **There's One Best Way To Do It** - Flexibility leads to chaos.
-* **Simple over Easy** - Verbose code that can be quickly understood beats impenetrable compact DSLs every day.
-
-Brut's abstractions tend to mirror concepts found in the domain of web sites. For
-example, a browser serves up a web page at a URL. In Brut, that's called a *page*
-and you'd create a subclass of `Brut::FrontEnd::Page` to implement it.
-
-Brut tries to avoid abstractions that simply translate existing standards into a
-more aestheticly pleasing form. You already need to know CSS, HTML, the Web
-Platform, and SQL, so there's little to gain by requiring you to learn a different
-way to use them.
-
-## Yes, You Can Build a Blog in 15 Minutes
-
-<iframe title="Make a Blog App in 15(ish) minutes With BrutRB - A New Ruby Web Framework" width="560" height="315" src="https://video.hardlimit.com/videos/embed/ae7EMhwjDq9kSH5dqQ9swV" frameborder="0" allowfullscreen="" sandbox="allow-same-origin allow-scripts allow-popups allow-forms"></iframe>
-
-[Check out the source code](https://github.com/thirdtank/blog-demo) if you want to dive right in.
-
-## Basic Elements
-
-Brut organizes its code and behavior around four basic concepts:
-
-* **Client** or *Client Side* is the web browser (or HTTP client). This is where CSS is applied to HTML and where JavaScript is executed. HTTP requests are initiated here.
-* **Server** or *Server Side* is where any code not in the browser runs. In Brut, this includes HTML generation, SQL queries, and everything in between.
-* **Front End** is the code that deals with producing your user interface or HTTP API.  A lot of this code runs on
-the *server side*, however it exists to provide a user interface of some sort.
-* **Back End** is the code that deals with everything else, such as accessing a database, executing business logic, or managing background jobs.
-
-
-![Architectural Overview](/images/OverviewMetro.png)
-
-* **Visitor** is someone visiting your web site or app.
-* **Browser** is, well, a web browser
-* [**Pages**](/pages) generate web pages, which is what happens when a browser's UI navigates to a URL.
-* [**Forms**](/forms) are submitted by the browser to the server. In Brut, a form describes the contents of a `<form>` as well as provides access to the submitted data.
-* [**Handlers**](/handlers) receive non-GET HTTP requests from the browser, notably form submissions.
-* [**Components**](/components) generate HTML fragments and are used to generate the HTML of a page or for re-use across pages.
-* [**JavaScript**](/javascript) and [**Assets**](/assets) (including [CSS](/css)) are bundled on the server and sent to the client.
-* [**Domain Logic**](/business-logic) as where your business and domain logic lives and can be implemented however you like.
-* [**DB Models**](/database-access) are objects that provide access to your database.
-* **Relational Database** is your database, where data is stored.
-
-Brut doesn't prevent the addition of more pieces of infrastructure or code. You can
-add a Redis cache, a Sidekiq job backend, or integrate with third party APIs.
-
-## Brut is Not MVC
-
-Brut is *not* an MVC framework, nor does it use the concept of *resources* as an
-abstraction.  Although HTTP does include this concept, we find it's not as useful
-for managing web apps as it may seem.
-
-We've found that teams often struggle with mapping what everyone else calls pages
-to resources and HTTP verbs.  We also find that the consonance of features, resources, actions, and database tables never materializes.  We're basically not going to debate what the meaning of the `DELETE` verb on the `widgets` resource is actually supposed to mean.
-
-## Brut is Hippocratic Licensed
-
-It's important to me that Brut is used to make the world a better place. Please take
-a note of [its license](https://firstdonoharm.dev/version/3/0/cl-eco-media-my-tal-xuar.txt)