axn 0.1.0.pre.alpha.2.8 → 0.1.0.pre.alpha.3

data/docs/reference/axn-result.md

@@ -0,0 +1,107 @@
+# `Axn::Result`
+
+Every `call` invocation on an Axn will return an `Axn::Result` instance, which provides a consistent interface:
+
+| Method | Description |
+| -- | -- |
+| `ok?` | `true` if the call succeeded, `false` if not.
+| `error` | User-facing error message (string), if not `ok?` (else nil)
+| `success` | User-facing success message (string), if `ok?` (else nil)
+| `message` | User-facing message (string), always defined (`ok? ? success : error`)
+| `exception` | If not `ok?` because an exception was swallowed, will be set to the swallowed exception (note: rarely used outside development; prefer to let the library automatically handle exception handling for you)
+| `outcome` | The execution outcome as a string inquirer (`success?`, `failure?`, `exception?`)
+| `elapsed_time` | Execution time in milliseconds (Float)
+| `finalized?` | `true` if the result has completed execution (either successfully or with an exception), `false` if still in progress
+| 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)
+
+NOTE: `success` and `error` (and so implicitly `message`) can be configured per-action via [the `success` and `error` declarations](/reference/class#success-and-error).
+
+### Clarification of exposed values
+
+In addition to the core interface, your Action's Result class will have methods defined to read the values of any attributes that were explicitly exposed.  For example, given this action and result:
+
+
+```ruby
+class Foo
+  include Axn
+
+  exposes :bar, :baz # [!code focus]
+
+  def call
+    expose bar: 1, baz: 2
+  end
+end
+
+result = Foo.call # [!code focus]
+```
+
+`result` will have both `bar` and `baz` reader methods (which will return 1 and 2, respectively).
+
+## Pattern Matching Support
+
+`Axn::Result` supports Ruby 3's pattern matching feature, allowing you to destructure results in a more expressive way:
+
+```ruby
+case SomeAction.call
+in ok: true, success: String => message, user:, order:
+  process_success(user, order, message)
+in ok: false, error: String => message
+  handle_error(message)
+end
+```
+
+### Available Pattern Matching Keys
+
+When pattern matching, the following keys are available:
+
+- `ok` - Boolean success state (`true` for success, `false` for failure)
+- `success` - Success message string (only present when `ok` is `true`)
+- `error` - Error message string (only present when `ok` is `false`)
+- `message` - Always present message string (success or error)
+- `outcome` - Symbol indicating the execution outcome (`:success`, `:failure`, or `:exception`)
+- `finalized` - Boolean indicating if execution completed
+- Any exposed values from the action
+
+### Pattern Matching Examples
+
+**Basic Success/Failure Matching:**
+```ruby
+case result
+in ok: true, user: User => user
+  puts "User created: #{user.name}"
+in ok: false, error: String => message
+  puts "Error: #{message}"
+end
+```
+
+**Outcome-Based Matching:**
+```ruby
+case result
+in ok: true, outcome: :success, data: { id: Integer => id }
+  puts "Success with ID: #{id}"
+in ok: false, outcome: :failure, error: String => message
+  puts "Business logic failure: #{message}"
+in ok: false, outcome: :exception, error: String => message
+  puts "System error: #{message}"
+end
+```
+
+**Complex Nested Data Matching:**
+```ruby
+case result
+in ok: true, order: { id: Integer => order_id, items: [{ name: String => item_name }] }
+  puts "Order #{order_id} created with #{item_name}"
+in ok: false, error: String => message, field: String => field
+  puts "Validation failed on #{field}: #{message}"
+end
+```
+
+**Type Guards and Variable Binding:**
+```ruby
+case result
+in ok: true, success: String => message, user: { email: String => email }
+  send_notification(email, message)
+in ok: false, error: String => message, code: String => code
+  log_error(code: code, message: message)
+end
+```

data/docs/reference/class.md

@@ -13,9 +13,10 @@ Both `expects` and `exposes` support the same core options:
 | Option | Example (same for `exposes`) | Meaning |
 | -- | -- | -- |
 | `sensitive` | `expects :password, sensitive: true` | Filters the field's value when logging, reporting errors, or calling `inspect`
-| `default` | `expects :foo, default: 123` | If `foo` isn't explicitly set, it'll default to this value
-| `allow_nil` | `expects :foo, allow_nil: true` | Don't fail if the value is `nil`
-| `allow_blank` | `expects :foo, allow_blank: true` | Don't fail if the value is blank
+| `default` | `expects :foo, default: 123` | If `foo` is missing or explicitly `nil`, it'll default to this value (not applied for blank values)
+| `optional` | `expects :foo, optional: true` | **Recommended**: Don't fail if the value is missing, nil, or blank. Equivalent to `allow_blank: true`
+| `allow_nil` | `expects :foo, allow_nil: true` | Don't fail if the value is `nil` (but will fail for blank strings)
+| `allow_blank` | `expects :foo, allow_blank: true` | Don't fail if the value is blank (nil, empty string, whitespace, etc.)
 | `type` | `expects :foo, type: String` | Custom type validation -- fail unless `name.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 `validates :foo, <...>` on an ActiveRecord model)
 
@@ -26,33 +27,52 @@ Both `expects` and `exposes` support the same core options:
 While we _support_ complex interface validations, in practice you usually just want a `type`, if anything.  Remember this is your validation about how the action is called, _not_ pretty user-facing errors (there's [a different pattern for that](/recipes/validating-user-input)).
 :::
 
-In addition to the [standard ActiveModel validations](https://guides.rubyonrails.org/active_record_validations.html), we also support three additional custom validators:
+In addition to the [standard ActiveModel validations](https://guides.rubyonrails.org/active_record_validations.html), we also support four additional custom validators:
 * `type: Foo` - fails unless the provided value `.is_a?(Foo)`
   * Edge case: use `type: :boolean` to handle a boolean field (since ruby doesn't have a Boolean class to pass in directly)
   * Edge case: use `type: :uuid` to handle a confirming given string is a UUID (with or without `-` chars)
+  * Edge case: use `type: :params` to accept either a Hash or ActionController::Parameters (Rails-compatible)
 * `validate: [callable]` - Support custom validations (fails if any string is returned OR if it raises an exception)
   * Example:
     ```ruby
     expects :foo, validate: ->(value) { "must be pretty big" unless value > 10 }
     ```
-* `model: true` (or `model: TheModelClass`) - allows auto-hydrating a record when only given its ID
+* `model: true` (or `model: TheModelClass` or `model: { klass: TheModelClass, finder: :find }`) - allows auto-hydrating a record when only given its ID
   * Example:
     ```ruby
-    expects :user_id, model: true
+    expects :user, model: true
+    # or
+    expects :user, model: User
+    # or with custom finder
+    expects :user, model: { klass: User, finder: :find }
     ```
     This line will add expectations that:
-      * `user_id` is provided
-      * `User.find(user_id)` returns a record
+      * `user_id` is provided (automatically derived from field name)
+      * `User.find(user_id)` (or custom finder) returns a record
 
-    And, when used on `expects`, will create two reader methods for you:
-      * `user_id` (normal), _and_
-      * `user` (for the auto-found record)
+    And, when used on `expects`, will create a reader method for you:
+      * `user` (the auto-found record)
 
     ::: info NOTES
-    * The field name must end in `_id`
-    * This was designed for ActiveRecord models, but will work on any class that returns an instance from `find_by(id: <the provided ID>)`
+    * The system automatically looks for `#{field}_id` (e.g., `:user` → `:user_id`)
+    * The `klass` option defaults to the field name classified (e.g., `:user` → `User`)
+    * The `finder` option defaults to `:find` but can be any method that takes an ID directly
+    * This works with any class that has a finder method (e.g., `User.find`, `ApiService.find_by_id`, etc.)
+    * For external APIs, you can pass a `Method` object as the finder
     :::
 
+#### How `optional`, `allow_blank` and `allow_nil` work with validators
+
+When you specify `optional: true`, `allow_blank: true`, or `allow_nil: true` on a field, these options are automatically passed through to **all validators** applied to that field. This means:
+
+- **ActiveModel validations** (like `inclusion`, `length`, etc.) will respect these options
+- **Custom validators** (`type`, `validate`, `model`) will also respect these options
+- **Type validator edge case**: Note passing `allow_blank` is nonsensical for type: :params and type: :boolean
+
+**Recommended approach**: Use `optional: true` instead of `allow_blank: true` for better clarity. The `optional` parameter is equivalent to `allow_blank: true` and makes the intent clearer.
+
+If neither `optional`, `allow_blank` nor `allow_nil` is specified, a default presence validation is automatically added (unless the type is `:boolean` or `:params`, which have their own validation logic as described above).
+
 ### Details specific to `.exposes`
 
 Remember that you'll need [a corresponding `expose` call](/reference/instance#expose) for every variable you declare via `exposes`.
@@ -62,13 +82,14 @@ Remember that you'll need [a corresponding `expose` call](/reference/instance#ex
 
 #### Nested/Subfield expectations
 
-`expects` is for defining the inbound interface. Usually it's enough to declare the top-level fields you receive, but sometimes you want to make expectations about the shape of that data, and/or to define easy accessor methods for deeply nested fields. `expects` supports the `on` option for this (all the normal attributes can be applied as well, _except default, preprocess, and sensitive_):
+`expects` is for defining the inbound interface. Usually it's enough to declare the top-level fields you receive, but sometimes you want to make expectations about the shape of that data, and/or to define easy accessor methods for deeply nested fields. `expects` supports the `on` option for this (all the normal attributes can be applied as well):
 
 ```ruby
 class Foo
   expects :event
   expects :data, type: Hash, on: :event  # [!code focus:2]
   expects :some, :random, :fields, on: :data
+  expects :optional_field, on: :data, default: "default value"  # [!code focus]
 
   def call
     puts "THe event.data.random field's value is: #{random}"
@@ -76,8 +97,12 @@ class Foo
 end
 ```
 
+::: tip Subfield Defaults
+Defaults work the same way for subfields as they do for top-level fields - they are applied when the subfield is missing or explicitly `nil`, but not for blank values.
+:::
+
 #### `preprocess`
-`expects` also supports a `preprocess` option that, if set to a callable, will be executed _before_ applying any validations.  This can be useful for type coercion, e.g.:
+`expects` also supports a `preprocess` option that, if set to a callable, will be executed _before_ applying any defaults or validations.  This can be useful for type coercion, e.g.:
 
 ```ruby
 expects :date, type: Date, preprocess: ->(d) { d.is_a?(Date) ? d : Date.parse(d) }
@@ -130,7 +155,7 @@ end
 **Correct order:**
 ```ruby
 class MyAction
-  include Action
+  include Axn
 
   # Define static fallback first
   success "Default success message"
@@ -145,7 +170,7 @@ end
 **Incorrect order (conditional messages will be shadowed):**
 ```ruby
 class MyAction
-  include Action
+  include Axn
 
   # These conditional messages will never be reached!
   success "Special success", if: :special_condition?
@@ -163,7 +188,7 @@ end
 While `.error` and `.success` set the default messages, you can register conditional messages using an optional `if:` or `unless:` matcher. The matcher can be:
 
 - an exception class (e.g., `ArgumentError`)
-- a class name string (e.g., `"Action::InboundValidationError"`)
+- a class name string (e.g., `"Axn::InboundValidationError"`)
 - a symbol referencing a local instance method predicate (arity 0 or 1, or keyword `exception:`), e.g. `:bad_input?`
 - a callable (arity 0 or 1, or keyword `exception:`)
 
@@ -228,7 +253,7 @@ When using `from:`, the error handler receives the exception from the child acti
 
 ```ruby
 class InnerAction
-  include Action
+  include Axn
 
   error "Something went wrong in the inner action"
 
@@ -238,7 +263,7 @@ class InnerAction
 end
 
 class OuterAction
-  include Action
+  include Axn
 
   # Customize error messages from InnerAction
   error from: InnerAction do |e|
@@ -267,7 +292,7 @@ You can also combine the `from:` parameter with the `prefix:` keyword to create
 
 ```ruby
 class OuterAction
-  include Action
+  include Axn
 
   # Add prefix to error messages from InnerAction
   error from: InnerAction, prefix: "API Error: " do |e|
@@ -293,7 +318,7 @@ Messages are evaluated in **last-defined-first** order, meaning the most recentl
 
 ```ruby
 class ParentAction
-  include Action
+  include Axn
 
   success "Parent success message"
   error "Parent error message"
@@ -309,7 +334,7 @@ Within a single class, later definitions override earlier ones:
 
 ```ruby
 class MyAction
-  include Action
+  include Axn
 
   success "First success message"           # Ignored
   success "Second success message"          # Ignored
@@ -327,6 +352,79 @@ The system evaluates handlers in the order they were defined until it finds one
 **Key point**: Static messages (without conditions) are evaluated **first** in the order they were defined. This means you should define your static fallback messages at the top of your class, before any conditional messages, to ensure proper fallback behavior.
 :::
 
+## `.async`
+
+Configures the async execution behavior for the action. This determines how the action will be executed when `call_async` is called.
+
+```ruby
+class MyAction
+  include Axn
+
+  # Configure Sidekiq
+  async :sidekiq do
+    sidekiq_options queue: "high_priority", retry: 5, priority: 10
+  end
+
+  # Or use keyword arguments (shorthand)
+  async :sidekiq, queue: "high_priority", retry: 5
+
+  # Configure ActiveJob
+  async :active_job do
+    queue_as "data_processing"
+    self.priority = 10
+    self.wait = 5.minutes
+  end
+
+  # Disable async execution
+  async false
+
+  expects :input
+
+  def call
+    # Action logic here
+  end
+end
+```
+
+### Available Adapters
+
+**`:sidekiq`** - Integrates with Sidekiq background job processing
+- Supports all Sidekiq configuration options via `sidekiq_options`
+- Supports keyword argument shorthand for common options (`queue`, `retry`, `priority`)
+
+**`:active_job`** - Integrates with Rails' ActiveJob framework
+- Supports all ActiveJob configuration options
+- Works with any ActiveJob backend (Sidekiq, Delayed Job, etc.)
+
+**`false`** - Disables async execution
+- `call_async` will raise a `NotImplementedError`
+
+### Inheritance
+
+Async configuration is inherited from parent classes. Child classes can override the parent's configuration:
+
+```ruby
+class ParentAction
+  include Axn
+
+  async :sidekiq do
+    sidekiq_options queue: "parent_queue"
+  end
+end
+
+class ChildAction < ParentAction
+  # Inherits parent's Sidekiq configuration
+  # Can override with its own configuration
+  async :active_job do
+    queue_as "child_queue"
+  end
+end
+```
+
+### Default Configuration
+
+If no async configuration is specified, the action will use the default configuration set via `Axn.config.set_default_async`. If no default is set, async execution is disabled.
+
 ## Callbacks
 
 In addition to the [global exception handler](/reference/configuration#on-exception), a number of custom callback are available for you as well, if you want to take specific actions when a given Axn succeeds or fails.
@@ -371,7 +469,7 @@ Much like the [globally-configured on_exception hook](/reference/configuration#o
 
 ```ruby
 class Foo
-  include Action
+  include Axn
 
   on_exception do |exception| # [!code focus:3]
     # e.g. trigger a slack error
@@ -383,7 +481,7 @@ Note that by default the `on_exception` block will be applied to _any_ `Standard
 
 ```ruby
 class Foo
-  include Action
+  include Axn
 
   on_exception(if: NoMethodError) do |exception| # [!code focus]
     # e.g. trigger a slack error

data/docs/reference/configuration.md

@@ -1,9 +1,9 @@
 # Configuration
 
-Somewhere at boot (e.g. `config/initializers/actions.rb` in Rails), you can call `Action.configure` to adjust a few global settings.
+Somewhere at boot (e.g. `config/initializers/actions.rb` in Rails), you can call `Axn.configure` to adjust a few global settings.
 
 ```ruby
-Action.configure do |c|
+Axn.configure do |c|
   c.log_level = :info
   c.logger = ...
   c.on_exception = proc do |e, action:, context:|
@@ -22,7 +22,7 @@ By default any swallowed errors are noted in the logs, but it's _highly recommen
 For example, if you're using Honeybadger this could look something like:
 
 ```ruby
-  Action.configure do |c|
+  Axn.configure do |c|
     c.on_exception = proc do |e, action:, context:|
       message = "[#{action.class.name}] Failing due to #{e.class.name}: #{e.message}"
 
@@ -56,7 +56,7 @@ A couple notes:
 
 ## `wrap_with_trace` and `emit_metrics`
 
-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.
+If you're using an APM provider, observability can be greatly enhanced by adding automatic _tracing_ of Axn calls and/or emitting count metrics after each call completes.
 
 The framework provides two distinct hooks for observability:
 
@@ -66,7 +66,7 @@ The framework provides two distinct hooks for observability:
 For example, to wire up Datadog:
 
 ```ruby
-  Action.configure do |c|
+  Axn.configure do |c|
     c.wrap_with_trace = proc do |resource, &action|
       Datadog::Tracing.trace("Action", resource:) do
         action.call
@@ -91,6 +91,20 @@ A couple notes:
 
 Defaults to `Rails.logger`, if present, otherwise falls back to `Logger.new($stdout)`.  But can be set to a custom logger as necessary.
 
+### Background Job Logging
+
+When using background jobs, you may want different loggers for web requests vs. background job execution. Here's a recommended pattern:
+
+```ruby
+Axn.configure do |c|
+  # Use Sidekiq's logger when running in Sidekiq workers, otherwise use Rails logger
+  c.logger = (defined?(Sidekiq) && Sidekiq.server?) ? Sidekiq.logger : Rails.logger
+end
+```
+
+This ensures that:
+- Web requests log to `Rails.logger` (typically `log/production.log`)
+- Background jobs log to `Sidekiq.logger` (typically STDOUT or a separate log file)
 
 
 ## `additional_includes`
@@ -100,7 +114,7 @@ This is much less critical than the preceding options, but on the off chance you
 For example:
 
 ```ruby
-  Action.configure do |c|
+  Axn.configure do |c|
     c.additional_includes = [SomeFancyCustomModule]
   end
 ```
@@ -115,6 +129,105 @@ Sets the log level used when you call `log "Some message"` in your Action.  Note
 
 Automatically detects the environment from `RACK_ENV` or `RAILS_ENV`, defaulting to `"development"`. This is used internally for conditional behavior (e.g., more verbose logging in non-production environments).
 
+## `set_default_async`
+
+Configures the default async adapter and settings for all actions that don't explicitly specify their own async configuration.
+
+```ruby
+Axn.configure do |c|
+  # Set default async adapter with configuration
+  c.set_default_async(:sidekiq, queue: "default", retry: 3) do
+    sidekiq_options priority: 5
+  end
+
+  # Set default async adapter with just configuration
+  c.set_default_async(:active_job) do
+    queue_as "default"
+    self.priority = 5
+  end
+
+  # Disable async by default
+  c.set_default_async(false)
+end
+```
+
+### Async Configuration
+
+Axn supports asynchronous execution through background job processing libraries. You can configure async behavior globally or per-action.
+
+**Available adapters:**
+- `:sidekiq` - Sidekiq background job processing
+- `:active_job` - Rails ActiveJob framework
+- `false` - Disable async execution
+
+**Basic usage:**
+```ruby
+# Configure per-action
+async :sidekiq, queue: "high_priority"
+
+# Configure globally
+Axn.configure do |c|
+  c.set_default_async(:sidekiq, queue: "default")
+end
+```
+
+For detailed information about async execution, including delayed execution, adapter configuration options, and best practices, see the [Async Execution documentation](/reference/async).
+
+#### Disabled
+
+Disables async execution entirely. The action will raise a `NotImplementedError` when `call_async` is called.
+
+```ruby
+# In your action class
+async false
+```
+
+### Default Configuration
+
+By default, async execution is disabled (`false`). You can set a default configuration that will be applied to all actions that don't explicitly configure their own async behavior:
+
+```ruby
+Axn.configure do |c|
+  # Set a default async configuration
+  c.set_default_async(:sidekiq, queue: "default") do
+    sidekiq_options retry: 3
+  end
+end
+
+# Now all actions will use Sidekiq by default
+class MyAction
+  include Axn
+  # No async configuration needed - uses default
+end
+```
+
+## Rails-specific Configuration
+
+When using Axn in a Rails application, additional configuration options are available under `Axn.config.rails`:
+
+### `app_actions_autoload_namespace`
+
+Controls the namespace for actions in `app/actions`. Defaults to `nil` (no namespace).
+
+```ruby
+Axn.configure do |c|
+  # No namespace (default behavior)
+  c.rails.app_actions_autoload_namespace = nil
+
+  # Use Actions namespace
+  c.rails.app_actions_autoload_namespace = :Actions
+
+  # Use any other namespace
+  c.rails.app_actions_autoload_namespace = :MyApp
+end
+```
+
+When `nil` (default), actions in `app/actions/user_management/create_user.rb` will be available as `UserManagement::CreateUser`.
+
+When set to `:Actions`, the same action will be available as `Actions::UserManagement::CreateUser`.
+
+When set to any other symbol (e.g., `:MyApp`), the action will be available as `MyApp::UserManagement::CreateUser`.
+
 ## Automatic Logging
 
 By default, every `action.call` will emit log lines when it is called and after it completes:
@@ -124,11 +237,11 @@ By default, every `action.call` will emit log lines when it is called and after
     [YourCustomAction] Execution completed (with outcome: success) in 0.957 milliseconds
   ```
 
-Automatic logging will log at `Action.config.log_level` by default, but can be overridden or disabled using the declarative `auto_log` method:
+Automatic logging will log at `Axn.config.log_level` by default, but can be overridden or disabled using the declarative `auto_log` method:
 
 ```ruby
 # Set default for all actions (affects both explicit logging and automatic logging)
-Action.configure do |c|
+Axn.configure do |c|
   c.log_level = :debug
 end
 
@@ -143,18 +256,77 @@ end
 
 # Use default level (no auto_log call needed)
 class DefaultAction
-  # Uses Action.config.log_level
+  # Uses Axn.config.log_level
 end
 ```
 
 The `auto_log` method supports inheritance, so subclasses will inherit the setting from their parent class unless explicitly overridden.
 
+## Profiling
+
+Axn supports performance profiling using [Vernier](https://github.com/Shopify/vernier), a Ruby sampling profiler. Profiling is enabled per-action by calling the `profile` method.
+
+### Usage
+
+Enable profiling on specific actions using the `profile` method:
+
+```ruby
+class MyAction
+  include Axn
+
+  # Profile conditionally (only one profile call per action)
+  profile if: -> { debug_mode }
+
+  expects :name, :debug_mode
+
+  def call
+    "Hello, #{name}!"
+  end
+end
+```
+
+### Configuration Options
+
+The `profile` method accepts several options:
+
+```ruby
+class MyAction
+  include Axn
+
+  # Profile with custom options
+  profile(
+    if: -> { debug_mode },
+    sample_rate: 0.1,  # Sampling rate (0.0 to 1.0, default: 0.1)
+    output_dir: "tmp/profiles"  # Output directory (default: Rails.root/tmp/profiles or tmp/profiles)
+  )
+
+  def call
+    # Action logic
+  end
+end
+```
+
+**Important**:
+- You can only call `profile` **once per action** - subsequent calls will override the previous one
+- This prevents accidental profiling of all actions and ensures you only profile what you intend to analyze
+
+### Viewing Profiles
+
+Profiles are saved as JSON files that can be viewed in the [Firefox Profiler](https://profiler.firefox.com/):
+
+1. Run your action with profiling enabled
+2. Find the generated profile file in your `profiling_output_dir`
+3. Upload the JSON file to [profiler.firefox.com](https://profiler.firefox.com/)
+4. Analyze the performance data
+
+For more detailed information, see the [Profiling guide](/advanced/profiling).
+
 ## Complete Configuration Example
 
 Here's a complete example showing all available configuration options:
 
 ```ruby
-Action.configure do |c|
+Axn.configure do |c|
   # Logging
   c.log_level = :info
   c.logger = Rails.logger
@@ -178,7 +350,16 @@ Action.configure do |c|
     Datadog::Metrics.histogram("action.duration", result.elapsed_time, tags: { resource: })
   end
 
+
+  # Async configuration
+  c.set_default_async(:sidekiq, queue: "default") do
+    sidekiq_options retry: 3, priority: 5
+  end
+
   # Global includes
   c.additional_includes = [MyCustomModule]
+
+  # Rails-specific configuration
+  c.rails.app_actions_autoload_namespace = :Actions
 end
 ```