cmdx 1.7.5 → 1.9.0

data/docs/logging.md

@@ -1,16 +1,10 @@
 # Logging
 
-CMDx provides comprehensive automatic logging for task execution with structured data, customizable formatters, and intelligent severity mapping. All task results are logged after completion with rich metadata for debugging and monitoring.
-
-## Table of Contents
-
-- [Formatters](#formatters)
-- [Structure](#structure)
-- [Usage](#usage)
+CMDx automatically logs every task execution with structured data, making debugging and monitoring effortless. Choose from multiple formatters to match your logging infrastructure.
 
 ## Formatters
 
-CMDx supports multiple log formatters to integrate with various logging systems:
+Choose the format that works best for your logging system:
 
 | Formatter | Use Case | Output Style |
 |-----------|----------|--------------|
@@ -40,12 +34,13 @@ E, [2022-07-17T18:43:15.000000 #3784] ERROR -- BillingWorkflow:
 index=3 chain_id="018c2b95-b764-7615-a924-cc5b910ed1e5" type="Task" class="BillingWorkflow"  state="interrupted" status="failed" caused_failure={index: 2, class: "CalculateTax", status: "failed"} threw_failure={index: 1, class: "ValidateCustomer", status: "failed"}
 ```
 
-> [!TIP]
-> Logging can be used as low-level eventing system, ingesting all tasks performed within a small action or long running request. This ie where correlation is especially handy.
+!!! tip
+
+    Use logging as a low-level event stream to track all tasks in a request. Combine with correlation for powerful distributed tracing.
 
 ## Structure
 
-All log entries include comprehensive execution metadata. Field availability depends on execution context and outcome.
+Every log entry includes rich metadata. Available fields depend on execution context and outcome.
 
 ### Core Fields
 
@@ -86,7 +81,7 @@ All log entries include comprehensive execution metadata. Field availability dep
 
 ## Usage
 
-Tasks have access to the frameworks logger.
+Access the framework logger directly within tasks:
 
 ```ruby
 class ProcessSubscription < CMDx::Task
@@ -97,8 +92,3 @@ class ProcessSubscription < CMDx::Task
   end
 end
 ```
-
----
-
-- **Prev:** [Middlewares](middlewares.md)
-- **Next:** [Internationalization (i18n)](internationalization.md)

data/docs/middlewares.md

@@ -1,27 +1,16 @@
 # Middlewares
 
-Middleware provides Rack-style wrappers around task execution for cross-cutting concerns like authentication, logging, caching, and error handling.
+Wrap task execution with middleware for cross-cutting concerns like authentication, caching, timeouts, and monitoring. Think Rack middleware, but for your business logic.
 
-Check out the [Getting Started](https://github.com/drexed/cmdx/blob/main/docs/getting_started.md#middlewares) docs for global configuration.
+See [Global Configuration](getting_started.md#middlewares) for framework-wide setup.
 
-## Table of Contents
+## Execution Order
 
-- [Order](#order)
-- [Declarations](#declarations)
-  - [Proc or Lambda](#proc-or-lambda)
-  - [Class or Module](#class-or-module)
-- [Removals](#removals)
-- [Built-in](#built-in)
-  - [Timeout](#timeout)
-  - [Correlate](#correlate)
-  - [Runtime](#runtime)
+Middleware wraps task execution in layers, like an onion:
 
-## Order
+!!! note
 
-Middleware executes in a nested fashion, creating an onion-like execution pattern:
-
-> [!NOTE]
-> Middleware executes in the order they are registered, with the first registered middleware being the outermost wrapper.
+    First registered = outermost wrapper. They execute in registration order.
 
 ```ruby
 class ProcessCampaign < CMDx::Task
@@ -97,10 +86,11 @@ end
 
 ## Removals
 
-Class and Module based declarations can be removed at a global and task level.
+Remove class or module-based middleware globally or per-task:
+
+!!! warning
 
-> [!WARNING]
-> Only one removal operation is allowed per `deregister` call. Multiple removals require separate calls.
+    Each `deregister` call removes one middleware. Use multiple calls for batch removals.
 
 ```ruby
 class ProcessCampaign < CMDx::Task
@@ -113,7 +103,7 @@ end
 
 ### Timeout
 
-Ensures task execution doesn't exceed a specified time limit:
+Prevent tasks from running too long:
 
 ```ruby
 class ProcessReport < CMDx::Task
@@ -149,7 +139,7 @@ result.metadata #=> { limit: 3 }
 
 ### Correlate
 
-Tags tasks with a global correlation ID for distributed tracing:
+Add correlation IDs for distributed tracing and request tracking:
 
 ```ruby
 class ProcessExport < CMDx::Task
@@ -179,8 +169,7 @@ result.metadata #=> { correlation_id: "550e8400-e29b-41d4-a716-446655440000" }
 
 ### Runtime
 
-The runtime middleware tags tasks with how long it took to execute the task.
-The calculation uses a monotonic clock and the time is returned in milliseconds.
+Track task execution time in milliseconds using a monotonic clock:
 
 ```ruby
 class PerformanceMonitoringCheck
@@ -200,8 +189,3 @@ end
 result = ProcessExport.execute
 result.metadata #=> { runtime: 1247 } (ms)
 ```
-
----
-
-- **Prev:** [Callbacks](callbacks.md)
-- **Next:** [Logging](logging.md)

data/docs/outcomes/result.md

@@ -1,27 +1,14 @@
 # Outcomes - Result
 
-The result object is the comprehensive return value of task execution, providing complete information about the execution outcome, state, timing, and any data produced during the task lifecycle. Results serve as the primary interface for inspecting task execution outcomes and chaining task operations.
-
-## Table of Contents
-
-- [Result Attributes](#result-attributes)
-- [Lifecycle Information](#lifecycle-information)
-- [Outcome Analysis](#outcome-analysis)
-- [Chain Analysis](#chain-analysis)
-- [Index and Position](#index-and-position)
-- [Block Yield](#block-yield)
-- [Handlers](#handlers)
-- [Pattern Matching](#pattern-matching)
-  - [Array Pattern](#array-pattern)
-  - [Hash Pattern](#hash-pattern)
-  - [Pattern Guards](#pattern-guards)
+Results are your window into task execution. They expose everything: outcome, state, timing, context, and metadata.
 
 ## Result Attributes
 
-Every result provides access to essential execution information:
+Access essential execution information:
 
-> [!IMPORTANT]
-> Result objects are immutable after task execution completes and reflect the final state.
+!!! warning "Important"
+
+    Results are immutable after execution completes.
 
 ```ruby
 result = BuildApplication.execute(version: "1.2.3")
@@ -43,7 +30,7 @@ result.metadata #=> { error_code: "BUILD_TOOL.NOT_FOUND" }
 
 ## Lifecycle Information
 
-Results provide comprehensive methods for checking execution state and status:
+Check execution state and status with predicate methods:
 
 ```ruby
 result = BuildApplication.execute(version: "1.2.3")
@@ -65,7 +52,7 @@ result.bad?         #=> false (skipped or failed)
 
 ## Outcome Analysis
 
-Results provide unified outcome determination depending on the fault causal chain:
+Get a unified outcome string combining state and status:
 
 ```ruby
 result = BuildApplication.execute(version: "1.2.3")
@@ -75,7 +62,7 @@ result.outcome #=> "success" (state and status)
 
 ## Chain Analysis
 
-Use these methods to trace the root cause of faults or trace the cause points.
+Trace fault origins and propagation:
 
 ```ruby
 result = DeploymentWorkflow.execute(app_name: "webapp")
@@ -116,7 +103,7 @@ result.chain.results[result.index] == result #=> true
 
 ## Block Yield
 
-Implement conditional logic using a block expression that yields a result for complete encapsulation.
+Execute code with direct result access:
 
 ```ruby
 BuildApplication.execute(version: "1.2.3") do |result|
@@ -132,34 +119,35 @@ end
 
 ## Handlers
 
-Use result handlers for clean, functional-style conditional logic. Handlers return the result object, enabling method chaining and fluent interfaces.
+Handle outcomes with functional-style methods. Handlers return the result for chaining:
 
 ```ruby
 result = BuildApplication.execute(version: "1.2.3")
 
 # Status-based handlers
 result
-  .on_success { |result| notify_deployment_ready(result) }
-  .on_failed { |result| handle_build_failure(result) }
-  .on_skipped { |result| log_skip_reason(result) }
+  .handle_success { |result| notify_deployment_ready(result) }
+  .handle_failed { |result| handle_build_failure(result) }
+  .handle_skipped { |result| log_skip_reason(result) }
 
 # State-based handlers
 result
-  .on_complete { |result| update_build_status(result) }
-  .on_interrupted { |result| cleanup_partial_artifacts(result) }
+  .handle_complete { |result| update_build_status(result) }
+  .handle_interrupted { |result| cleanup_partial_artifacts(result) }
 
 # Outcome-based handlers
 result
-  .on_good { |result| increment_success_counter(result) }
-  .on_bad { |result| alert_operations_team(result) }
+  .handle_good { |result| increment_success_counter(result) }
+  .handle_bad { |result| alert_operations_team(result) }
 ```
 
 ## Pattern Matching
 
-Results support Ruby's pattern matching through array and hash deconstruction:
+Use Ruby 3.0+ pattern matching for elegant outcome handling:
+
+!!! warning "Important"
 
-> [!IMPORTANT]
-> Pattern matching requires Ruby 3.0+
+    Pattern matching works with both array and hash deconstruction.
 
 ### Array Pattern
 
@@ -203,8 +191,3 @@ in { runtime: time } if time > performance_threshold
   investigate_build_performance(result)
 end
 ```
-
----
-
-- **Prev:** [Interruptions - Exceptions](../interruptions/exceptions.md)
-- **Next:** [Outcomes - States](states.md)

data/docs/outcomes/states.md

@@ -1,16 +1,6 @@
 # Outcomes - States
 
-States represent the execution lifecycle condition of task execution, tracking
-the progress of tasks through their complete execution journey. States provide
-insight into where a task is in its lifecycle and enable lifecycle-based
-decision making and monitoring.
-
-## Table of Contents
-
-- [Definitions](#definitions)
-- [Transitions](#transitions)
-- [Predicates](#predicates)
-- [Handlers](#handlers)
+States track where a task is in its execution lifecycle—from creation through completion or interruption.
 
 ## Definitions
 
@@ -34,8 +24,9 @@ State-Status combinations:
 
 ## Transitions
 
-> [!CAUTION]
-> States are automatically managed during task execution and should **never** be modified manually. State transitions are handled internally by the CMDx framework.
+!!! danger "Caution"
+
+    States are managed automatically—never modify them manually.
 
 ```ruby
 # Valid state transition flow
@@ -62,19 +53,14 @@ result.executed?    #=> true (complete OR interrupted)
 
 ## Handlers
 
-Use state-based handlers for lifecycle event handling. The `on_executed` handler is particularly useful for cleanup operations that should run regardless of success, skipped, or failure.
+Handle lifecycle events with state-based handlers. Use `handle_executed` for cleanup that runs regardless of outcome:
 
 ```ruby
 result = ProcessVideoUpload.execute
 
 # Individual state handlers
 result
-  .on_complete { |result| send_upload_notification(result) }
-  .on_interrupted { |result| cleanup_temp_files(result) }
-  .on_executed { |result| log_upload_metrics(result) }
+  .handle_complete { |result| send_upload_notification(result) }
+  .handle_interrupted { |result| cleanup_temp_files(result) }
+  .handle_executed { |result| log_upload_metrics(result) }
 ```
-
----
-
-- **Prev:** [Outcomes - Result](result.md)
-- **Next:** [Outcomes - Statuses](statuses.md)

data/docs/outcomes/statuses.md

@@ -1,13 +1,6 @@
 # Outcomes - Statuses
 
-Statuses represent the business outcome of task execution logic, indicating how the task's business logic concluded. Statuses differ from execution states by focusing on the business outcome rather than the technical execution lifecycle. Understanding statuses is crucial for implementing proper business logic branching and error handling.
-
-## Table of Contents
-
-- [Definitions](#definitions)
-- [Transitions](#transitions)
-- [Predicates](#predicates)
-- [Handlers](#handlers)
+Statuses represent the business outcome—did the task succeed, skip, or fail? This differs from state, which tracks the execution lifecycle.
 
 ## Definitions
 
@@ -19,8 +12,9 @@ Statuses represent the business outcome of task execution logic, indicating how
 
 ## Transitions
 
-> [!IMPORTANT]
-> Status transitions are unidirectional and final. Once a task is marked as skipped or failed, it cannot return to success status. Design your business logic accordingly.
+!!! warning "Important"
+
+    Status transitions are final and unidirectional. Once skipped or failed, tasks can't return to success.
 
 ```ruby
 # Valid status transitions
@@ -53,24 +47,19 @@ result.bad?     #=> true if skipped OR failed (not success)
 
 ## Handlers
 
-Use status-based handlers for business logic branching. The `on_good` and `on_bad` handlers are particularly useful for handling success/skip vs failed outcomes respectively.
+Branch business logic with status-based handlers. Use `handle_good` and `handle_bad` for success/skip vs failed outcomes:
 
 ```ruby
 result = ProcessNotification.execute
 
 # Individual status handlers
 result
-  .on_success { |result| mark_notification_sent(result) }
-  .on_skipped { |result| log_notification_skipped(result) }
-  .on_failed { |result| queue_retry_notification(result) }
+  .handle_success { |result| mark_notification_sent(result) }
+  .handle_skipped { |result| log_notification_skipped(result) }
+  .handle_failed { |result| queue_retry_notification(result) }
 
 # Outcome-based handlers
 result
-  .on_good { |result| update_message_stats(result) }
-  .on_bad { |result| track_delivery_failure(result) }
+  .handle_good { |result| update_message_stats(result) }
+  .handle_bad { |result| track_delivery_failure(result) }
 ```
-
----
-
-- **Prev:** [Outcomes - States](states.md)
-- **Next:** [Attributes - Definitions](../attributes/definitions.md)

data/docs/stylesheets/extra.css

@@ -0,0 +1,42 @@
+:root  > * {
+  /* Primary color shades */
+  --md-primary-fg-color:        #fe1817;
+  --md-primary-fg-color--light: #fe1817;
+  --md-primary-fg-color--dark:  #fe1817;
+
+  /* Accent color shades */
+  --md-accent-fg-color:                hsla(#{hex2hsl(#fe1817)}, 1);
+  --md-accent-fg-color--transparent:   hsla(#{hex2hsl(#fe1817)}, 0.1);
+}
+
+/* Atom One Light Pro syntax highlighting */
+[data-md-color-scheme="default"] {
+  --md-code-hl-color:            #2c3036;
+  --md-code-hl-keyword-color:    #a626a4;
+  --md-code-hl-string-color:     #50a14f;
+  --md-code-hl-name-color:       #e4564a;
+  --md-code-hl-function-color:   #4078f2;
+  --md-code-hl-number-color:     #ca7601;
+  --md-code-hl-constant-color:   #c18401;
+  --md-code-hl-comment-color:    #9ca0a4;
+  --md-code-hl-operator-color:   #0184bc;
+  --md-code-hl-punctuation-color:#383a42;
+  --md-code-hl-variable-color:   #e4564a;
+  --md-code-hl-generic-color:    #e4564a;
+}
+
+/* Atom One Dark Pro syntax highlighting */
+[data-md-color-scheme="slate"] {
+  --md-code-hl-color:            #e5e5e6;
+  --md-code-hl-keyword-color:    #c678dd;
+  --md-code-hl-string-color:     #98c379;
+  --md-code-hl-name-color:       #e06c75;
+  --md-code-hl-function-color:   #61afef;
+  --md-code-hl-number-color:     #d19a66;
+  --md-code-hl-constant-color:   #d19a66;
+  --md-code-hl-comment-color:    #7f848e;
+  --md-code-hl-operator-color:   #56b6c2;
+  --md-code-hl-punctuation-color:#abb2bf;
+  --md-code-hl-variable-color:   #e06c75;
+  --md-code-hl-generic-color:    #e06c75;
+}

data/docs/tips_and_tricks.md

@@ -1,16 +1,6 @@
 # Tips and Tricks
 
-This guide covers advanced patterns and optimization techniques for getting the most out of CMDx in production applications.
-
-## Table of Contents
-
-- [Project Organization](#project-organization)
-  - [Directory Structure](#directory-structure)
-  - [Naming Conventions](#naming-conventions)
-  - [Story Telling](#story-telling)
-  - [Style Guide](#style-guide)
-- [Attribute Options](#attribute-options)
-- [ActiveRecord Query Tagging](#activerecord-query-tagging)
+Best practices, patterns, and techniques to build maintainable CMDx applications.
 
 ## Project Organization
 
@@ -54,7 +44,7 @@ class TokenGeneration < CMDx::Task; end    # ❌ Avoid
 
 ### Story Telling
 
-Consider using descriptive methods to express the task’s flow, rather than concentrating all logic inside the `work` method.
+Break down complex logic into descriptive methods that read like a narrative:
 
 ```ruby
 class ProcessOrder < CMDx::Task
@@ -86,7 +76,7 @@ end
 
 ### Style Guide
 
-Follow a style pattern for consistent task design:
+Follow this order for consistent, readable tasks:
 
 ```ruby
 class ExportReport < CMDx::Task
@@ -129,7 +119,7 @@ end
 
 ## Attribute Options
 
-Use Rails `with_options` to reduce duplication and improve readability:
+Use `with_options` to reduce duplication:
 
 ```ruby
 class ConfigureCompany < CMDx::Task
@@ -155,36 +145,7 @@ class ConfigureCompany < CMDx::Task
 end
 ```
 
-## ActiveRecord Query Tagging
-
-Automatically tag SQL queries for better debugging:
-
-```ruby
-# config/application.rb
-config.active_record.query_log_tags_enabled = true
-config.active_record.query_log_tags << :cmdx_task_class
-config.active_record.query_log_tags << :cmdx_chain_id
-
-# app/tasks/application_task.rb
-class ApplicationTask < CMDx::Task
-  before_execution :set_execution_context
-
-  private
-
-  def set_execution_context
-    # NOTE: This could easily be made into a middleware
-    ActiveSupport::ExecutionContext.set(
-      cmdx_task_class: self.class.name,
-      cmdx_chain_id: chain.id
-    )
-  end
-end
-
-# SQL queries will now include comments like:
-# /*cmdx_task_class:ExportReportTask,cmdx_chain_id:018c2b95-b764-7615*/ SELECT * FROM reports WHERE id = 1
-```
-
----
+## Advanced Examples
 
-- **Prev:** [Workflows](workflows.md)
-- **Next:** [Getting Started](getting_started.md)
+- [Active Record Query Tagging](https://github.com/drexed/cmdx/blob/main/examples/active_record_query_tagging.md)
+- [Paper Trail Whatdunnit](https://github.com/drexed/cmdx/blob/main/examples/paper_trail_whatdunnit.md)

data/docs/workflows.md

@@ -1,26 +1,14 @@
 # Workflows
 
-Workflow orchestrates sequential execution of multiple tasks in a linear pipeline. Workflows provide a declarative DSL for composing complex business logic from individual task components, with support for conditional execution, context propagation, and configurable halt behavior.
-
-## Table of Contents
-
-- [Declarations](#declarations)
-  - [Task](#task)
-  - [Group](#group)
-  - [Conditionals](#conditionals)
-- [Halt Behavior](#halt-behavior)
-  - [Task Configuration](#task-configuration)
-  - [Group Configuration](#group-configuration)
-- [Nested Workflows](#nested-workflows)
-- [Parallel Execution](#parallel-execution)
-- [Task Generator](#task-generator)
+Compose multiple tasks into powerful, sequential pipelines. Workflows provide a declarative way to build complex business processes with conditional execution, shared context, and flexible error handling.
 
 ## Declarations
 
-Tasks execute sequentially in declaration order (FIFO). The workflow context propagates to each task, allowing access to data from previous executions.
+Tasks run in declaration order (FIFO), sharing a common context across the pipeline.
 
-> [!IMPORTANT]
-> Do **NOT** define a `work` method in workflow tasks. The included module automatically provides the execution logic.
+!!! warning
+
+    Don't define a `work` method in workflows—the module handles execution automatically.
 
 ### Task
 
@@ -35,15 +23,17 @@ class OnboardingWorkflow < CMDx::Task
 end
 ```
 
-> [!TIP]
-> Execute tasks in parallel via the [cmdx-parallel](https://github.com/drexed/cmdx-parallel) gem.
+!!! tip
+
+    Execute tasks in parallel via the [cmdx-parallel](https://github.com/drexed/cmdx-parallel) gem.
 
 ### Group
 
-Group related tasks for better organization and shared configuration:
+Group related tasks to share configuration:
 
-> [!IMPORTANT]
-> Settings and conditionals for a group apply to all tasks within that group.
+!!! warning "Important"
+
+    Settings and conditionals apply to all tasks in the group.
 
 ```ruby
 class ContentModerationWorkflow < CMDx::Task
@@ -78,10 +68,10 @@ class OnboardingWorkflow < CMDx::Task
   task SendWelcomeEmail, if: :email_configured?, unless: :email_disabled?
 
   # Proc
-  task SendWelcomeEmail, if: ->(workflow) { Rails.env.production? && workflow.class.name.include?("Premium") }
+  task SendWelcomeEmail, if: -> { Rails.env.production? && self.class.name.include?("Premium") }
 
   # Lambda
-  task SendWelcomeEmail, if: proc { |workflow| workflow.context.features_enabled? }
+  task SendWelcomeEmail, if: proc { context.features_enabled? }
 
   # Class or Module
   task SendWelcomeEmail, unless: ContentAccessCheck
@@ -95,7 +85,7 @@ class OnboardingWorkflow < CMDx::Task
   private
 
   def email_configured?
-    context.user.email_address.present?
+    context.user.email_address == true
   end
 
   def email_disabled?
@@ -106,9 +96,7 @@ end
 
 ## Halt Behavior
 
-By default skipped tasks are considered no-op executions and does not stop workflow execution.
-This is configurable via global and task level breakpoint settings. Task and group configurations
-can be used together within a workflow.
+By default, skipped tasks don't stop the workflow—they're treated as no-ops. Configure breakpoints globally or per-task to customize this behavior.
 
 ```ruby
 class AnalyticsWorkflow < CMDx::Task
@@ -164,7 +152,7 @@ end
 
 ## Nested Workflows
 
-Workflows can task other workflows for hierarchical composition:
+Build hierarchical workflows by composing workflows within workflows:
 
 ```ruby
 class EmailPreparationWorkflow < CMDx::Task
@@ -191,10 +179,11 @@ end
 
 ## Parallel Execution
 
-Parallel task execution leverages the [Parallel](https://github.com/grosser/parallel) gem, which automatically detects the number of available processors to maximize concurrent task execution.
+Run tasks concurrently using the [Parallel](https://github.com/grosser/parallel) gem. It automatically uses all available processors for maximum throughput.
+
+!!! warning
 
-> [!IMPORTANT]
-> Context cannot be modified during parallel execution. Ensure that all required data is preloaded into the context before parallelization begins.
+    Context is read-only during parallel execution. Load all required data beforehand.
 
 ```ruby
 class SendWelcomeNotifications < CMDx::Task
@@ -232,10 +221,6 @@ class SendNotifications < CMDx::Task
 end
 ```
 
-> [!TIP]
-> Use **present tense verbs + pluralized noun** for workflow task names, eg: `SendNotifications`, `DownloadFiles`, `ValidateDocuments`
-
----
+!!! tip
 
-- **Prev:** [Deprecation](deprecation.md)
-- **Next:** [Tips and Tricks](tips_and_tricks.md)
+    Use **present tense verbs + pluralized noun** for workflow task names, eg: `SendNotifications`, `DownloadFiles`, `ValidateDocuments`

data/examples/active_record_query_tagging.md

@@ -0,0 +1,46 @@
+# Active Record Query Tagging
+
+Add a comment to every query indicating some context to help you track down where that query came from, eg:
+
+```sh
+/*cmdx_task_class:ExportReportTask,cmdx_chain_id:018c2b95-b764-7615*/ SELECT * FROM reports WHERE id = 1
+```
+
+### Setup
+
+```ruby
+# config/application.rb
+config.active_record.query_log_tags_enabled = true
+config.active_record.query_log_tags += [
+  :cmdx_correlation_id,
+  :cmdx_chain_id,
+  :cmdx_task_class,
+  :cmdx_task_id
+]
+
+# lib/cmdx_query_tagging_middleware.rb
+class CmdxQueryTaggingMiddleware
+  def self.call(task, **options, &)
+    ActiveSupport::ExecutionContext.set(
+      cmdx_correlation_id: task.result.metadata[:correlation_id],
+      cmdx_chain_id: task.chain.id,
+      cmdx_task_class: task.class.name,
+      cmdx_task_id: task.id,
+      &
+    )
+  end
+end
+```
+
+### Usage
+
+```ruby
+class MyTask < CMDx::Task
+  register :middleware, CmdxQueryTaggingMiddleware
+
+  def work
+    # Do work...
+  end
+
+end
+```