axn 0.1.0.pre.alpha.1

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: ef826e80d884d02a1ed34f2bea7adec8d588c10b9205530491dfdd3f7f0b49b6
+  data.tar.gz: 11ea30c7aa7648962a5c0f90e8e6de872e6a28aaedb5603982d762013260e5ed
+SHA512:
+  metadata.gz: 6ab30a1f36da77f01eb19e1de1fcdeebac6662246bc30b652917b6e86af69e345a1075370de4a9cd2f197e93db77264fe1e369a48c4d994c1246f57a347335e8
+  data.tar.gz: d9e72527cb17dac4eb2f85d2b607919996d50d59797122049f42a3c92a44c44a60ca83660ceaf446588013b355a053162698a94aed75424f16e357de56ba7c70

data/.rspec

@@ -0,0 +1,3 @@
+--format documentation
+--color
+--require spec_helper

data/.rubocop.yml

@@ -0,0 +1,54 @@
+AllCops:
+  TargetRubyVersion: 3.1
+  SuggestExtensions: false
+  NewCops: enable
+
+Style/StringLiterals:
+  Enabled: true
+  EnforcedStyle: double_quotes
+
+Style/StringLiteralsInInterpolation:
+  Enabled: true
+  EnforcedStyle: double_quotes
+
+Style/Documentation:
+  Enabled: false
+
+Style/TrailingCommaInArguments:
+  EnforcedStyleForMultiline: comma
+
+Style/TrailingCommaInArrayLiteral:
+  EnforcedStyleForMultiline: comma
+
+Style/TrailingCommaInHashLiteral:
+  EnforcedStyleForMultiline: comma
+
+Style/DoubleNegation:
+  Enabled: false
+
+Metrics/BlockLength:
+  Enabled: false
+
+Metrics/MethodLength:
+  Max: 60
+
+Metrics/PerceivedComplexity:
+  Max: 15
+
+Metrics/AbcSize:
+  Max: 51
+
+Metrics/CyclomaticComplexity:
+  Max: 12
+
+Lint/EmptyBlock:
+  Enabled: false
+
+Naming/MethodParameterName:
+  AllowedNames: e
+
+Metrics/ParameterLists:
+  Max: 6
+
+Layout/LineLength:
+  Max: 160

data/CHANGELOG.md

@@ -0,0 +1,5 @@
+# Changelog
+
+## UNRELEASED
+
+* N/A

data/CONTRIBUTING.md

@@ -0,0 +1,37 @@
+# Contributing to Axn
+
+Axn is open source and contributions from the community are encouraged!
+No contribution is too small.
+
+Please consider:
+
+* adding a feature
+* squashing a bug
+* writing documentation
+* reporting an issue
+* fixing a typo
+
+## How do I contribute?
+
+For the best chance of having your changes merged, please:
+
+1. [Fork](https://github.com/teamshares/axn/fork) the project.
+2. [Write](http://en.wikipedia.org/wiki/Test-driven_development) a failing test.
+3. [Commit](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) changes that fix the tests.
+4. [Submit](https://github.com/teamshares/axn/pulls) a pull request with *at least* one animated GIF.
+5. Be patient.
+
+## Bug Reports
+
+If you are experiencing unexpected behavior and, after having read [our documentation](https://teamshares.github.io/axn/guide/), are convinced this behavior is a bug, please:
+
+1. [Search](https://github.com/teamshares/axn/issues) existing issues.
+2. Collect enough information to reproduce the issue:
+  * Axn version
+  * Ruby version
+  * Rails version (if applicable)
+  * Specific setup conditions
+  * Description of expected behavior
+  * Description of actual behavior
+3. [Submit](https://github.com/teamshares/axn/issues/new) an issue.
+4. Be patient.

data/LICENSE.txt

@@ -0,0 +1,22 @@
+Copyright (c) 2025 Teamshares
+
+MIT License
+
+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,30 @@
+# Axn ("Action")
+
+Just spinning this up -- not yet released (i.e. doc updates in flight).
+
+## Installation & Usage
+
+See our [User Guide](https://teamshares.github.io/axn/guide/) for details.
+
+## [!!] Inheritance Support
+
+Out of the box Axn only supports a direct style (every action must `include Action`).
+
+If you want to support inheritance, you'll need to add this line to your `Gemfile` (we're layered over Interactor, and their released version doesn't yet support inheritance):
+
+    gem "interactor", github: "kaspermeyer/interactor", branch: "fix-hook-inheritance"
+
+
+## Development
+
+After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
+
+## Contributions
+
+Axn is open source and contributions from the community are encouraged! No contribution is too small.
+
+See our [contribution guidelines](CONTRIBUTING.md) for more information.
+
+## Thank You
+
+A very special thank you to [Collective Idea](https://collectiveidea.com/)'s fantastic [Interactor](https://github.com/collectiveidea/interactor?tab=readme-ov-file#interactor) library, which [we](https://www.teamshares.com/) used successfully for a number of years and which still forms the basis of this library today.

data/Rakefile

@@ -0,0 +1,12 @@
+# frozen_string_literal: true
+
+require "bundler/gem_tasks"
+require "rspec/core/rake_task"
+
+RSpec::Core::RakeTask.new(:spec)
+
+require "rubocop/rake_task"
+
+RuboCop::RakeTask.new
+
+task default: %i[spec rubocop]

data/axn.gemspec

@@ -0,0 +1,45 @@
+# frozen_string_literal: true
+
+require_relative "lib/axn/version"
+
+Gem::Specification.new do |spec|
+  spec.name = "axn"
+  spec.version = Axn::VERSION
+  spec.authors = ["Kali Donovan"]
+  spec.email = ["kali@teamshares.com"]
+
+  spec.summary = "A terse convention for business logic"
+  spec.description = "Pattern for writing callable service objects with contract validation and error swallowing"
+  spec.homepage = "https://github.com/teamshares/axn"
+  spec.license = "MIT"
+
+  # NOTE: uses endless methods from 3, literal value omission from 3.1
+  spec.required_ruby_version = ">= 3.1.0"
+
+  # spec.metadata["allowed_push_host"] = "TODO: Set to your gem server 'https://example.com'"
+  # spec.metadata["rubygems_mfa_required"] = "true"
+
+  spec.metadata["homepage_uri"] = spec.homepage
+  spec.metadata["source_code_uri"] = spec.homepage
+  spec.metadata["changelog_uri"] = "https://github.com/teamshares/axn/blob/main/CHANGELOG.md"
+
+  # Specify which files should be added to the gem when it is released.
+  # The `git ls-files -z` loads the files in the RubyGem that have been added into git.
+  spec.files = Dir.chdir(__dir__) do
+    `git ls-files -z`.split("\x0").reject do |f|
+      (File.expand_path(f) == __FILE__) ||
+        f.start_with?(*%w[bin/ test/ spec/ features/ .git .github appveyor Gemfile])
+    end
+  end
+  spec.bindir = "exe"
+  spec.executables = spec.files.grep(%r{\Aexe/}) { |f| File.basename(f) }
+  spec.require_paths = ["lib"]
+
+  # Core dependencies
+  spec.add_dependency "activemodel", "> 7.0"    # For contract validation
+  spec.add_dependency "activesupport", "> 7.0"  # For compact_blank and friends
+
+  # NOTE: for inheritance support, need to specify a fork in consuming applications' Gemfile (see Gemfile here for syntax)
+  spec.add_dependency "interactor", "3.1.2" # We're building on this scaffolding for organizing business logic
+  spec.metadata["rubygems_mfa_required"] = "true"
+end

data/docs/.vitepress/config.mjs

@@ -0,0 +1,55 @@
+import { defineConfig } from 'vitepress'
+
+// https://vitepress.dev/reference/site-config
+export default defineConfig({
+  title: "Axn",
+  description: "A terse convention for business logic",
+  base: "/axn/",
+  themeConfig: {
+    // https://vitepress.dev/reference/default-theme-config
+    nav: [
+      { text: 'Home', link: '/' },
+      { text: 'User Guide', link: '/guide' }
+    ],
+
+    sidebar: [
+      {
+        text: 'Introduction',
+        items: [
+          { text: 'About', link: '/about/' },
+          { text: 'Summary Overview', link: '/guide/' },
+        ]
+      },
+      {
+        text: 'Getting Started',
+        items: [
+          { text: 'Setup', link: '/usage/setup' },
+          { text: 'Writing Actions', link: '/usage/writing' },
+          { text: 'Using Actions', link: '/usage/using' },
+          { text: 'Testing Actions', link: '/usage/testing' },
+          { text: 'Conventions', link: '/usage/conventions' },
+        ]
+      },
+      {
+        text: 'Reference',
+        items: [
+          { text: 'Configuration', link: '/reference/configuration' },
+          { text: 'Class Interface', link: '/reference/class' },
+          { text: 'Instance Interface', link: '/reference/instance' },
+          { text: 'Result Interface', link: '/reference/action-result' },
+        ]
+      },
+      {
+        text: 'Advanced Usage',
+        items: [
+          { text: 'ROUGH NOTES', link: '/advanced/rough' },
+          { text: 'Validating User Input', link: '/advanced/validating-user-input' },
+        ]
+      },
+    ],
+
+    socialLinks: [
+      { icon: 'github', link: 'https://github.com/teamshares/axn' }
+    ]
+  }
+})

data/docs/about/index.md

@@ -0,0 +1,46 @@
+## History
+
+The need to consistently organize your business logic somewhere within the MVC Rails stack is a perennial topic of discussion, with many approaches in the community. Over the course of a few years, [we at Teamshares](https://github.com/teamshares) had three teams building three separate apps, each of which chose a different approach.
+
+After observing the challenges that emerged from each approach, we extracted a list of explicit design goals and then set out to build a library that would implement them.
+
+## Design Goals
+
+::: tip Overall Focus
+A simple, declarative core API. Concise enough to pick up quickly, but sufficiently powerful to manage real-world complexity.
+:::
+
+**Core needs:**
+
+  - Consistent, DRY pattern to reach for when building services (`FooService.call`)
+  - Ability to declaratively specify pre- and post- conditions
+  - Consistent return interface (including exception swallowing)
+    - Clear distinction between user-facing and internal errors
+  - Minimal boilerplate
+  - Easy backgrounding (no need for a separate Worker class just to wrap a service call)
+
+**Additional benefits devs get for free:**
+
+  - Integrated metrics
+  - Integrated debug logging
+  - Automatic error reporting
+
+## Orchestration
+
+We found that many of our existing solutions were _also_ pretty solid for individual services, but started to break down when complex use-cases required nesting service calls within each other (hard to tell at a glance how exceptions bubble up, what the end-user ends up seeing in various failure modes, which parts get unwound by DB transactions, etc.).
+
+The core library provides many benefits for individual action calls, but also aims to establish a few clear usage patterns to make it easy to reason about nested services.
+
+### "Blessed" patterns:
+* Single action
+* Linear flow
+  * A list of actions to execute in series
+  * Each layer `expects` and `exposes` its own accessor set, but internally all the values are passed down the chain (i.e. actor C can accept something A exposed that B didn’t touch and knows nothing about).
+  * The top-level action must `expose` it’s own layer (effectively documenting public vs private exposures, which drastically eases refactoring)
+* Ad hoc (called arbitrarily from within other actions)
+  * `hoist_errors` (usage: `hoist_errors { Nested::Action.call }`) ensures any failure from a nested service is bubbled up to the top level (by default, as if the failure had happened there directly).
+  * Allows configurable handling at call site (e.g. setting `prefix`, so identical failures from different nested calls are distinguishable)
+
+::: danger ALPHA
+* TODO: add links to sections showing usage guides/examples for the more complex flows
+:::

data/docs/advanced/rough.md

@@ -0,0 +1,12 @@
+::: danger ALPHA
+* TODO: convert rough notes into actual documentation
+:::
+
+## Rough Notes
+
+* General note: the inbound/outbound contexts are views into an underlying shared object (passed down through organize calls) -- modifications of one will affect the other (e.g. preprocessing inbound args implicitly transforms them on the underlying context, which is echoed if you also expose it on outbound).
+
+* Configuring logging (will default to Rails.logger if available, else fall back to basic Logger (but can explicitly set via e.g. `Action.config.logger = Logger.new($stdout`))
+
+    * Note `context_for_logging` is available (filtered to accessible attrs, filtering out sensitive values). Automatically passed into `on_exception` hook.
+

data/docs/advanced/validating-user-input.md

@@ -0,0 +1,11 @@
+# Validating _user_ input
+
+::: danger ALPHA
+This has not yet been fully fleshed out.  For now, the general idea is that user-facing validation is a _separate layer_ from the declarative expectations about what inputs your Action takes (e.g. `expects :params` and pass to a form object, rather than accepting field-level params directly).
+:::
+
+
+The `expects`/`exposes` validations are for confirming that you're fulfilling your contract with yourself to call your service correctly.  Any failures are _not_ user facing (and in fact, at some point may optionally raise in development)
+
+If you want to run validations on user-provided data (i.e. individual form elements), there's a Form Object pattern for that.
+

data/docs/guide/index.md

@@ -0,0 +1,157 @@
+---
+outline: deep
+---
+
+# Introduction
+
+This library provides a set of conventions for writing business logic in Rails (or other Ruby) applications with:
+
+  * Clear calling semantics: `Foo.call`
+  * A declarative interface
+  * A [consistent return interface](./#return-interface)
+    * Exception swallowing + clear distinction between internal and user-facing errors
+
+### Minimal example
+
+Your logic goes in a <abbr title="Plain Old Ruby Object">PORO</abbr>. The only requirements are to `include Action` and a `call` method, meaning the basic skeleton looks something like this:
+
+```ruby
+class Foo
+  include Action
+
+  def call
+    log "Doesn't do much, but this technically works..."
+  end
+end
+```
+
+## Inputs and Outflows
+
+### Overview
+
+Most actions require inputs, and many return values to the caller; no need for any `def initialize` boilerplate, just add:
+
+  * `expects :foo` to declare inputs the class expects to receive.
+
+    You pass the `expect`ed keyword arguments to `call`, then reference their values as local `attr_reader`s.
+
+  * `exposes :bar` to declare any outputs the class will expose.
+
+    Within your action, use `expose :bar, <value>` to set a value that will be available on the return interface.
+
+::: info
+By design you _cannot access anything you do not explicitly `expose` from outside the action itself_.  Making the external interface explicit helps maintainability by ensuring you can refactor internals without breaking existing callsites.
+:::
+
+### Details
+Both `expects` and `exposes` support a variety of options:
+
+| Option | Example (same for `exposes`) | Meaning |
+| -- | -- | -- |
+| `sensitive` | `expects :password, sensitive: true` | Filters the fields value when logging, reporting errors, or calling `inspect`
+| `default` | `expects :foo, default: 123` | If `foo` isn't provided, it'll default to this value
+| `allow_blank` | `expects :foo, allow_blank: true` | Don't fail if the value is blank
+| `type` | `expects :foo, type: String` | Custom type validation -- fail unless `foo.is_a?(String)`
+| anything else | `expects :foo, inclusion: { in: [:apple, :peach] }` | Any other arguments will be processed [as ActiveModel validations](https://guides.rubyonrails.org/active_record_validations.html) (i.e. as if passed to `validate :foo, <...>` on an ActiveRecord model)
+
+::: warning
+The declarative interface (`expects` and `exposes`) constitutes a contract you are making _with yourself_ (and your fellow developers). **This is _not_ for validating user input** -- [there's a Form Object pattern for that](/advanced/validating-user-input).
+:::
+
+If any expectations fail, the action will fail early and set `error` to a generic error message (because a failed validation means _you_ called _your own_ service wrong; there's nothing the end user can do about that).
+
+
+### Putting it together
+
+```ruby
+class Actions::Slack::Post
+  include Action
+  VALID_CHANNELS = [ ... ]
+
+  expects :channel, default: VALID_CHANNELS.first, inclusion: { in: VALID_CHANNELS } # [!code focus:4]
+  expects :message, type: String
+
+  exposes :thread_id, type: String
+
+  def call
+    response = client.chat_postMessage(channel:, text: message)
+    the_thread_id = response["ts"]
+
+    expose :thread_id, the_thread_id # [!code focus]
+  end
+
+  private
+
+  def client = Slack::Web::Client.new
+end
+```
+
+## Return interface {#return-interface}
+
+### Overview
+
+The return value of an Action call is always an `Action::Result`, which provides a consistent interface:
+
+| Method | Description |
+| -- | -- |
+| `ok?` | `true` if the call succeeded, `false` if not.
+| `error` | Will _always_ be set to a safe-to-show-users string if not `ok?`
+| any `expose`d values | guaranteed to be set if `ok?` (since they have outgoing presence validations by default; any missing would have failed the action)
+
+### Details
+
+::: danger ALPHA
+* TODO: link to a reference page for the full interface.
+:::
+
+### Putting it together
+
+This interface yields a common usage pattern:
+
+
+```ruby
+class MessagesController < ApplicationController
+  def create
+    result = Actions::Slack::Post.call( # [!code focus]
+      channel: "#engineering",
+      message: params[:message],
+    )
+
+    if result.ok?  # [!code focus:2]
+      @thread_id = result.thread_id # Because `thread_id` was explicitly exposed
+      flash.now[:success] = "Sent the Slack message"
+    else
+      flash[:alert] = result.error # [!code focus]
+      redirect_to action: :new
+    end
+  end
+end
+```
+
+Note this simple pattern handles multiple levels of "failure" ([details below](#error-handling)):
+* Showing specific user-facing flash messages for any arbitrary logic you want in your action (from `fail!`)
+* Showing generic error message if anything went wrong internally (e.g. the Slack client raised an exception -- it's been logged for the team to investigate, but the user doesn't need to care _what_ went wrong)
+* Showing generic error message if any of your declared interface expectations fail (e.g. if the exposed `thread_id`, which we pulled from Slack's API response, somehow _isn't_ a String)
+
+
+## Error handling {#error-handling}
+
+::: tip BIG IDEA
+By design, `result.error` is always safe to show to the user.
+
+:star_struck: The calling code usually only cares about `ok?` and `error` -- no complex error handling needed.
+:::
+
+
+We make a clear distinction between user-facing and internal errors.
+
+### User-facing errors (`fail!`)
+
+For _known_ failure modes, you can call `fail!("Some user-facing explanation")` at any time to abort execution and set `result.error` to your custom message.
+
+### Internal errors (uncaught `raise`)
+
+Any exceptions will be swallowed and the action failed (i.e. _not_ `ok?`). `result.error` will be set to a generic error message ("Something went wrong" by default, but highly configurable).
+<!-- TODO: link to messaging configs -->
+
+The swallowed exception will be available on `result.exception` for your introspection, but it'll also be passed to your `on_exception` handler so, [with a bit of configuration](/usage/setup), you can trust that any exceptions have been logged to your error tracking service automatically (one more thing the dev doesn't need to think about).

data/docs/index.md

@@ -0,0 +1,26 @@
+---
+# https://vitepress.dev/reference/default-theme-home-page
+layout: home
+
+hero:
+  name: "Axn"
+  text: "A terse convention for business logic"
+  tagline: "**ALPHA release -- everything subject to change**"
+  actions:
+    - theme: brand
+      text: User Guide
+      link: /guide
+    # - theme: alt
+    #   text: API Examples
+    #   link: /api-examples
+
+features:
+  - title: Declarative interface
+    details: Lorem ipsum dolor sit amet, consectetur adipiscing elit
+  - title: Exception swallowing
+    details: Lorem ipsum dolor sit amet, consectetur adipiscing elit
+  - title: Default Observability
+    details: Lorem ipsum dolor sit amet, consectetur adipiscing elit
+---
+
+

data/docs/reference/action-result.md

@@ -0,0 +1,12 @@
+::: danger ALPHA
+* TODO: convert this rough outline into actual documentation
+:::
+
+
+`Action::Result`
+
+  * ok?
+  * error
+  * exception
+  * success
+  * message

data/docs/reference/class.md

@@ -0,0 +1,18 @@
+::: danger ALPHA
+* TODO: convert this rough outline into actual documentation
+:::
+
+## Class-level interface
+
+* `expects`
+* `exposes`
+* `messages`
+
+### `expects` and `exposes`
+* setting `sensitive: true` on any param will filter that value out when inspecting or passing to on_exception
+* Note we have two custom validations: boolean: true and the implicit type: foo.  (maybe with array of types?)
+    Note a third allows custom validations: `expects :foo, validate: ->(value) { "must be pretty big" unless value > 10 }` (error raised if any string returned OR if it raises an exception)
+
+### #call and #rollback
+
+### hooks

data/docs/reference/configuration.md

@@ -0,0 +1,90 @@
+# Configuration
+
+Somewhere at boot (e.g. `config/initializers/actions.rb` in Rails), you can call `Action.configure` to adjust a few global settings.
+
+
+```ruby
+  Action.configure do |c|
+    c.global_debug_logging = false
+
+    c.on_exception = ...
+
+    c.top_level_around_hook = ...
+
+    c.additional_includes = []
+  end
+```
+
+## `global_debug_logging`
+
+By default, every `action.call` will emit _debug_ log lines when it is called (including the action class and any arguments it was provided) and after it completes (including the execution time and the outcome).
+
+You can bump the log level from `debug` to `info` for specific actions by including their class name (comma separated, if multiple) in a `SA_DEBUG_TARGETS` ENV variable.
+
+You can also turn this on _globally_ by setting `global_debug_logging = true`.
+
+```ruby
+  Action.configure do |c|
+    c.global_debug_logging = true
+  end
+```
+
+## `on_exception`
+
+By default any swallowed errors are noted in the logs, but it's _highly recommended_ to wire up an `on_exception` handler so those get reported to your error tracking service.
+
+For example, if you're using Honeybadger this could look something like:
+
+
+```ruby
+  Action.configure do |c|
+    c.on_exception = proc do |e, action:, context:|
+      message = "[#{action.class.name}] Failing due to #{e.class.name}: #{e.message}"
+
+      Rails.logger.warn(message)
+      Honeybadger.notify(message, context:)
+    end
+  end
+```
+
+A couple notes:
+
+  * `context` will contain the arguments passed to the `action`, _but_ any marked as sensitive (e.g. `expects :foo, sensitive: true`) will be filtered out in the logs.
+  * If your handler raises, the failure will _also_ be swallowed and logged
+
+
+## `top_level_around_hook`
+
+If you're using an APM provider, observability can be greatly enhanced by adding automatic _tracing_ of Action calls and/or emitting count metrics after each call completes.
+
+For example, to wire up Datadog:
+
+```ruby
+  Action.configure do |c|
+    c.top_level_around_hook = proc do |resource, &action|
+      Datadog::Tracing.trace("Action", resource:) do
+        (outcome, _exception) = action.call
+
+        TS::Metrics.increment("action.#{resource.underscore}", tags: { outcome:, resource: })
+      end
+    end
+  end
+```
+
+A couple notes:
+
+  * `Datadog::Tracing` is provided by [the datadog gem](https://rubygems.org/gems/datadog)
+  * `TS::Metrics` is a custom implementation to set a Datadog count metric, but the relevant part to note is that outcome (`success`, `failure`, `exception`) of the action is reported so you can easily track e.g. success rates per action.
+
+
+## `additional_includes`
+
+This is much less critical than the preceding options, but on the off chance you want to add additional customization to _all_ your actions you can set additional modules to be included alongside `include Action`.
+
+For example:
+
+```ruby
+  Action.configure do |c|
+    c.additional_includes = [SomeFancyCustomModule]
+  end
+```