asgard 0.3.2 → 0.4.0

data/docs/dependencies.md

@@ -236,9 +236,9 @@ Because `*.loki` files are loaded alphabetically when `import "*.loki"` is used,
 
 ---
 
-## Dynamic Dependencies (Proc Form)
+## Dynamic Dependencies (Proc / Block Form)
 
-`depends_on` normally takes a fixed list, recorded the moment the `def` right after it is encountered — which is why load order matters, as above. Pass a `Proc` or lambda instead, and that list is computed *later*, after every `.loki` file has finished loading, rather than at the point `depends_on` itself is evaluated:
+`depends_on` normally takes a fixed list, recorded the moment the `def` right after it is encountered — which is why load order matters, as above. Pass a `Proc` or lambda instead — or, equivalently, a block — and that list is computed *later*, after every `.loki` file has finished loading, rather than at the point `depends_on` itself is evaluated:
 
 ```ruby
 depends_on -> { [all_commands.keys.grep(/_check\z/).sort.map(&:to_sym)] }
@@ -246,22 +246,33 @@ desc "Run every *_check quality gate task in parallel"
 def quality
   # ...
 end
+
+depends_on { [all_commands.keys.grep(/_check\z/).sort.map(&:to_sym)] }
+desc "Same thing, written as a block"
+def quality2
+  # ...
+end
 ```
 
-This solves exactly the "load order matters" problem from the previous section: a plain array can only name tasks that already exist in `.loki` files loaded *before* this one. A Proc is resolved once every file has loaded, so it can safely reference a task defined in a file that hasn't been imported yet at the point `depends_on` is written — including one that only exists conditionally, e.g. a Rails-specific task file imported with `import "quality_rails.loki" if defined?(Rails)`.
+This solves exactly the "load order matters" problem from the previous section: a plain array can only name tasks that already exist in `.loki` files loaded *before* this one. A Proc/block is resolved once every file has loaded, so it can safely reference a task defined in a file that hasn't been imported yet at the point `depends_on` is written — including one that only exists conditionally, e.g. a Rails-specific task file imported with `import "quality_rails.loki" if defined?(Rails)`. `depends_on` accepts task arguments *or* a block, never both — combining them raises `Asgard::Error`.
+
+**Shape:** the Proc/block must return exactly what the plain-array form would receive as its splat arguments — an array of stages, each a `Symbol`/`String` (sequential) or an `Array` of `Symbol`/`String` (parallel group), nested no deeper than that. The example above returns `[[:a_check, :b_check, :c_check]]`: one stage, containing every matching task, all running in parallel — the same shape as `depends_on [:a_check, :b_check, :c_check]`. This shape is validated once the result comes back — a bad return value (wrong type, a stage that isn't a Symbol/String/Array, a leaf inside a parallel group that isn't a Symbol/String, or nesting more than one level deep) raises `Asgard::Error` naming the task and the offending value, instead of failing later with an opaque `NoMethodError`:
 
-**Shape:** the Proc must return exactly what the plain-array form would receive as its splat arguments — an array of stages, each a `Symbol` (sequential) or `Array` (parallel group). The example above returns `[[:a_check, :b_check, :c_check]]`: one stage, containing every matching task, all running in parallel — the same shape as `depends_on [:a_check, :b_check, :c_check]`.
+```bash
+asgard quality
+# asgard: depends_on proc/block for 'quality' returned invalid stage 123 (Integer); expected a Symbol, String, or Array of them
+```
 
-**When it runs:** once, when `validate_deps!` runs (right after the `.loki` chain finishes loading, before any task dispatches). The resolved result replaces the Proc in the dependency table, so cycle detection, undefined-task checks, and arity checks all run against the *resolved* list — a Proc that references an undefined task, or that itself introduces a cycle, is caught at startup exactly like a plain array would be:
+**When it runs:** once, when `validate_deps!` runs (right after the `.loki` chain finishes loading, before any task dispatches). The resolved result replaces the Proc/block in the dependency table, so cycle detection, undefined-task checks, and arity checks all run against the *resolved* list — a Proc/block that references an undefined task, or that itself introduces a cycle, is caught at startup exactly like a plain array would be:
 
 ```bash
 asgard quality
 # asgard: undefined task(s) in depends_on: ghost_check
 ```
 
-**`self` inside the Proc:** since the Proc is written directly in a `class Tasks` body, it lexically captures that class as `self` — so it can call `all_commands`, `_deps`, or any other class-level method bare, without a `self.class.` prefix, even though it's actually invoked later from inside `validate_deps!`.
+**`self` inside the Proc/block:** since it's written directly in a `class Tasks` body, it lexically captures that class as `self` — so it can call `all_commands`, `_deps`, or any other class-level method bare, without a `self.class.` prefix, even though it's actually invoked later from inside `validate_deps!`.
 
-**If the Proc raises**, the error is caught and re-raised as `Asgard::Error` naming the task it was declared for:
+**If the Proc/block raises**, the error is caught and re-raised as `Asgard::Error` naming the task it was declared for:
 
 ```
 asgard: depends_on proc for 'quality' raised RuntimeError: boom

data/docs/index.md

@@ -18,6 +18,7 @@
 <li><strong>Dotenv Support</strong> — load <code>.env</code> files into the environment with <code>dotenv</code></li>
 <li><strong>Auto-Discovery</strong> — <code>.loki</code> root marker searched from CWD upward through parent directories</li>
 <li><strong>Multi-File Tasks</strong> — split tasks across <code>*.loki</code> files loaded via <code>import</code></li>
+<li><strong>Scheduled Tasks</strong> — run any task periodically under launchd (macOS) or systemd timers (Linux) with <code>schedule</code> and <code>asgard schedule install</code></li>
 <li><strong>Built-in Flags</strong> — <code>--version</code>, <code>--debug</code>, <code>--verbose</code>, and <code>--doctor</code> available on every task</li>
 </ul>
 </td>

data/docs/schedule.md

@@ -0,0 +1,101 @@
+# Scheduled Tasks
+
+Asgard can run any task on a schedule. You declare schedules in the project's own `.loki`, and `asgard schedule install` hands them to the platform's own scheduler: **launchd** on macOS, **systemd user timers** on Linux. Both schedulers run a calendar job that was missed while the machine slept as soon as it wakes.
+
+Scheduling is built into the gem, so there is nothing to import or require.
+
+---
+
+## Declaring Schedules
+
+Call `schedule` at class level inside `Tasks`:
+
+```ruby
+# .loki
+class Tasks
+  desc "daily_summary", "Summarize the day's work"
+  def daily_summary = sh "bin/summary"
+
+  schedule :daily_summary, at: "17:30", on: :weekdays
+  schedule :weekly_report, at: "16:00", on: :friday
+  schedule :sync,          every: 3600                 # seconds
+  schedule :backup,        at: %w[02:00 14:00]         # on: defaults to :daily
+
+  # The task's own options go in options:, split the way a shell would
+  # (quotes respected).
+  schedule :report, options: "--format md -v",  at: "08:00", on: :weekdays
+  schedule :report, options: "--period week",   at: "16:00", on: :friday
+  schedule :notify, options: "--msg 'backup done'", every: 86_400, as: "notify_daily"
+end
+```
+
+A declaration needs exactly one of `at:` or `every:`.
+
+| Keyword | Meaning |
+|---------|---------|
+| `at:` | `"HH:MM"` (24-hour), or an Array of times |
+| `on:` | `:daily` (default), `:weekdays`, `:weekends`, a day (`:friday`), or an Array of days |
+| `every:` | Interval in seconds, or anything that responds to `in_seconds` (an ActiveSupport `Duration`) |
+| `options:` | The task's own arguments, as a String (split shell-style) or an Array of words |
+| `env:` | `{ "KEY" => "value" }`: literal environment variables added to the job |
+| `as:` | The entry's name (letters, digits, `_ . -`) |
+
+### Entry Names
+
+Every entry has a name, and the subcommands below take it as `NAME`. The name defaults to the task name. When the entry has `options:`, the default is a slug of the task plus its options (`:report, options: "--format md -v"` becomes `report-format-md-v`), so one task can be scheduled several times with different flags. `as:` overrides the default. Declaring two *different* entries with the same name raises an error.
+
+### Durations
+
+Asgard doesn't depend on ActiveSupport. If you want `every: 3.minutes`, require it yourself at the top of your `.loki`:
+
+```ruby
+require "active_support/core_ext/integer/time"
+
+class Tasks
+  schedule :sync, every: 15.minutes
+end
+```
+
+---
+
+## Managing Schedules
+
+`schedule` is also a command with subcommands. They work the same way on both platforms:
+
+```bash
+asgard schedule preview        # print the job files install would write
+asgard schedule install        # load declared entries; drop entries no longer declared
+asgard schedule list           # installed entries, schedule, state, last exit status
+asgard schedule stop NAME      # stop one entry (stays stopped across reboots and installs)
+asgard schedule start NAME     # start a stopped entry, or install just this one
+asgard schedule trigger NAME   # run an installed entry now, under the scheduler
+asgard schedule log NAME [-f]  # print the entry's log (-f keeps following it)
+asgard schedule remove         # unload and delete all of this project's entries
+```
+
+Re-run `asgard schedule install` after changing declarations or your `PATH`.
+
+---
+
+## How Jobs Run
+
+Each entry runs `asgard <task> [options]` from the directory that holds `.loki`, so installing from any subdirectory gives the same result. The job gets the `PATH` that was current when you ran `install`, plus any `env:` variables.
+
+If the project has a `.envrc`, the job runs under `direnv exec`, so API keys and other secrets load from `.envrc` at run time and are never copied into the job files. If `direnv` isn't on your `PATH`, `install` warns that `.envrc` will not be loaded.
+
+Entries are scoped to the project (the name of the directory holding `.loki`), so `list`, `install` and `remove` only touch this project's jobs.
+
+| | macOS (launchd) | Linux (systemd) |
+|---|---|---|
+| Job files | `~/Library/LaunchAgents/com.madbomber.asgard.<project>.<name>.plist` | `~/.config/systemd/user/asgard.<project>.<name>.{service,timer}` |
+| Logs | `~/Library/Logs/asgard/` | `~/.local/state/asgard/` (honors `XDG_STATE_HOME`) |
+| Stop | `launchctl disable` | `systemctl --user disable --now` |
+| Caveats | runs only while you're logged in | runs only while you're logged in unless `loginctl enable-linger`; needs systemd 240+ |
+
+Other platforms aren't supported. The `schedule` subcommands there exit with an error.
+
+---
+
+## Name Collisions
+
+The built-in command is registered as `_schedule` and mapped to `schedule`, following Asgard's `_` convention for gem-owned tasks. If your `.loki` defines its own `schedule` task, `asgard schedule` still dispatches to the built-in command.

data/docs/shell.md

@@ -2,7 +2,7 @@
 
 Asgard provides two methods for running shell commands and scripts from within task bodies: `sh` for shell commands and heredocs, and `shebang` for polyglot scripts. Both are provided by `Asgard::Shell` and mixed into every `Tasks` instance.
 
-Both methods exit with the command's status code on failure — they do not raise Ruby exceptions.
+Both methods exit with the command's status code on failure — they do not raise Ruby exceptions. `sh` also accepts `exec: true` to replace the asgard process outright instead of forking — see [Handing Off with `exec`](#handing-off-with-exec).
 
 ---
 
@@ -80,6 +80,35 @@ class Tasks
 end
 ```
 
+### Handing Off with `exec`
+
+Pass `exec: true` to hand the command the asgard process itself instead of forking a child. Under the hood this calls `Kernel.exec` rather than `system`, which replaces the running ruby process image with the command — asgard doesn't stick around waiting on it.
+
+Use this for a task's final, long-running command — a dev server, a REPL, anything meant to take over the terminal — so there's no idle ruby process sitting in memory alongside it, and Ctrl-C is handled directly by the command instead of unwinding back through asgard:
+
+```ruby
+class Tasks
+  desc "Documentation server startup"
+  depends_on :doc_builder
+  def doc_server = sh "mkdocs serve", exec: true
+end
+```
+
+Since the process is replaced, nothing after the `sh` call ever runs, and `depends_on` chains upstream of it must already have finished (they have — dependencies run before the task body).
+
+```ruby
+class Tasks
+  desc "Start a REPL — never returns to asgard"
+  def console
+    sh "bundle exec pry", exec: true
+    puts "unreachable"
+  end
+end
+```
+
+!!! note
+    `exec: true` only makes sense for a command meant to run for the lifetime of the process. Don't use it for a step with more work queued after it in the same task.
+
 ---
 
 ## `shebang` — Polyglot Scripts

data/docs/tasks.md

@@ -206,6 +206,46 @@ Without `default_task`, running `asgard` with no arguments displays the help mes
 
 ---
 
+## Abbreviated Command Matching
+
+Every task is a Thor command, and Thor resolves any unambiguous prefix of a command name to that command automatically — no Asgard code involved, and nothing to declare. Given:
+
+```ruby
+class Tasks
+  desc "Check code style with RuboCop"
+  def rubocop_check = sh "bundle exec rubocop"
+
+  desc "Run the test suite"
+  def test_check = sh "bundle exec rake test"
+
+  desc "Run the test suite with verbose output"
+  def test_verbose = sh "bundle exec rake test -v"
+
+  desc "Deploy to production"
+  def deploy = sh "cap production deploy"
+
+  desc "Deploy to staging"
+  def deploy_staging = sh "cap staging deploy"
+end
+```
+
+```bash
+asgard r             # same as: asgard rubocop_check — the only task starting with "r"
+asgard test_c        # same as: asgard test_check     — enough of the name to be unique
+asgard test          # Ambiguous command test matches [test_check, test_verbose]
+asgard deploy        # runs deploy, not deploy_staging — see below
+```
+
+Thor matches on a plain prefix (`command_name.start_with?(typed_string)`), so the shortest string that is still unique for your task set works. Two details worth knowing:
+
+- **An exact full name always wins**, even if it's also a prefix of another task. `asgard deploy` runs `deploy` itself, never the ambiguous-prefix error, because `deploy` is a defined command — not merely a prefix of `deploy_staging`.
+- **An ambiguous prefix produces a clean error listing every candidate** (`Ambiguous command X matches [...]`) rather than guessing or running the alphabetically-first match. Type enough of the name to disambiguate.
+
+!!! tip
+    Because matching depends on every task name currently defined, a short prefix that's unique today can become ambiguous tomorrow when a new task with the same stem is added — e.g. adding `rubocop_fix` alongside `rubocop_check` turns `asgard r` from a clean match into `Ambiguous command r matches [rubocop_check, rubocop_fix]`. Use [`map`](#command-aliases) below for a short name you want to guarantee stays stable regardless of what other tasks get added later.
+
+---
+
 ## Command Aliases
 
 `map` creates short aliases for existing tasks:

data/examples/depends_on_block/bad/.loki

@@ -0,0 +1,51 @@
+# examples/depends_on_block/bad/.loki
+# BAD example: depends_on block returning a mis-shaped result.
+#
+# Compare with ../good/.loki, which does this correctly:
+#
+#   depends_on { [all_commands.keys.grep(/_check\z/).sort.map(&:to_sym)] }
+#     ^                                                                ^
+#     one wrapping [ ] — this is "one stage, containing every matching
+#     task, all running in parallel."
+#
+# It's an easy typo to add a SECOND wrapping array, thinking the outer
+# array is "the list of stages" and the inner one is "this stage's tasks"
+# as two separate concerns:
+#
+#   depends_on { [[all_commands.keys.grep(/_check\z/).sort.map(&:to_sym)]] }
+#                ^                                                        ^
+#                that's one stage too many — the middle array ends up
+#                *inside* a stage as a dependency, not as the stage itself.
+#
+# depends_on's block/Proc result is validated the moment it resolves
+# (during validate_deps!, before any task runs): every stage must be a
+# Symbol/String (sequential) or an Array of Symbol/String (parallel group)
+# — nesting one level deeper than that is rejected with Asgard::Error
+# instead of failing later with a confusing NoMethodError.
+#
+# Run with (from this directory):
+#   asgard quality
+#
+# Expected output (validate_deps! aborts before quality — or any other
+# task — ever runs):
+#   asgard: depends_on proc/block for 'quality' returned invalid dependency
+#   [:a_check, :b_check, :c_check] (Array) in a parallel group; expected a
+#   Symbol or String
+
+class Tasks
+  desc "Run the first check"
+  def a_check = puts "running a_check ..."
+
+  desc "Run the second check"
+  def b_check = puts "running b_check ..."
+
+  desc "Run the third check"
+  def c_check = puts "running c_check ..."
+
+  # BUG: double-wrapped — [[ ... ]] instead of [ ... ]. See comment above.
+  depends_on { [[all_commands.keys.grep(/_check\z/).sort.map(&:to_sym)]] }
+  desc "Run every *_check task in parallel, then report"
+  def quality
+    puts "quality: all *_check tasks passed"
+  end
+end

data/examples/depends_on_block/good/.loki

@@ -0,0 +1,83 @@
+# examples/depends_on_block/good/.loki
+# GOOD example: depends_on with a block instead of a Proc/lambda.
+#
+# A block behaves exactly like `-> { ... }` — it defers resolution to
+# validate_deps! (once, after every .loki file has loaded) instead of
+# resolving the moment depends_on is evaluated. This is the real pattern
+# from this gem's own quality.loki: gather every task whose name ends in
+# `_check`, without having to know their names or load order upfront.
+#
+# The block's return value is validated once it resolves: it must be an
+# Array of stages, each a Symbol/String (sequential) or an Array of
+# Symbol/String (parallel group) — see ../bad/.loki for what happens when
+# that shape is wrong.
+#
+# `{ ... }` braces are used below for the short, single-line blocks (quality,
+# full_cycle) — standard Ruby style reserves `do ... end` for a block that
+# spans multiple statements, shown in smoke further down.
+#
+# Run with (from this directory):
+#   asgard quality
+#
+# Expected output:
+#   running a_check ...
+#   running b_check ...
+#   running c_check ...
+#   quality: all *_check tasks passed
+
+class Tasks
+  desc "Run the first check"
+  def a_check = puts "running a_check ..."
+
+  desc "Run the second check"
+  def b_check = puts "running b_check ..."
+
+  desc "Run the third check"
+  def c_check = puts "running c_check ..."
+
+  # self inside the block is the Tasks class (it's written directly in the
+  # class body), so all_commands can be called bare, with no self.class.
+  # prefix — even though the block itself isn't invoked until later.
+  depends_on { [all_commands.keys.grep(/_check\z/).sort.map(&:to_sym)] }
+  desc "Run every *_check task in parallel, then report"
+  def quality
+    puts "quality: all *_check tasks passed"
+  end
+
+  # A block can also return a mix of sequential Symbols and parallel Arrays,
+  # exactly like the plain splat form: depends_on :setup, [:a_check, :b_check], :teardown
+  desc "Prepare fixtures before the checks run"
+  def setup = puts "setup: fixtures ready"
+
+  desc "Clean up fixtures after the checks run"
+  def teardown = puts "teardown: fixtures removed"
+
+  depends_on { [:setup, %i[a_check b_check], :teardown] }
+  desc "setup, then a_check+b_check in parallel, then teardown"
+  def full_cycle
+    puts "full_cycle: done"
+  end
+
+  # A block spanning multiple statements — local variables, some computation
+  # — reads more naturally as do...end than as one long `{ ... }` line.
+  # Whatever it does along the way, the last expression is still what gets
+  # returned and validated: here, [:setup, Array, :teardown], the same shape
+  # as full_cycle above.
+  #
+  # Gotcha: this block runs during validate_deps!, which happens *before*
+  # Thor parses this invocation's CLI options (see the Entry Point Flow in
+  # CLAUDE.md) — so checking `--verbose`/`--debug` in here would always see
+  # the pre-flag default, never what was actually passed on this run. Keep
+  # depends_on blocks limited to shaping the dependency graph itself.
+  depends_on do
+    all_checks  = all_commands.keys.grep(/_check\z/).sort.map(&:to_sym)
+    slow_checks = %i[c_check]
+    fast_checks = all_checks - slow_checks
+
+    [:setup, fast_checks, :teardown]
+  end
+  desc "setup, then every *_check except the slow ones, then teardown"
+  def smoke
+    puts "smoke: done"
+  end
+end

data/examples/kitchen_sink.loki

@@ -181,6 +181,19 @@ class Tasks
     end
   end
 
+  # ── Asgard: sh — run shell commands, single-line and multi-line heredoc ────
+  desc "Show environment info (single-line sh)"
+  def env_info = sh "echo Running #{@@app_name} on $(uname -s)"
+
+  desc "Bootstrap the local environment (multi-line sh / heredoc)"
+  def bootstrap
+    sh <<~SHELL
+      echo "App:  #{@@app_name}"
+      echo "Ruby: $(ruby -v)"
+      echo "Date: $(date)"
+    SHELL
+  end
+
   # ── Thor: no_commands — public helper excluded from CLI and --help ──────────
   no_commands do
     def current_sha

data/lib/asgard/base/dependency_graph.rb

@@ -17,13 +17,21 @@ module Asgard
       #   depends_on [:build, :lint]                 # build and lint in parallel
       #   depends_on :setup, [:build, :lint], :test  # setup, then build+lint, then test
       #
-      # A sole Proc/lambda defers resolution to validate_deps! (after every
-      # .loki file has loaded), instead of now. It must return the same shape
-      # the splat form above would: an array of stages, each a Symbol
-      # (sequential) or Array (parallel group).
+      # A sole Proc/lambda, or a block in place of the splat args, defers
+      # resolution to validate_deps! (after every .loki file has loaded),
+      # instead of now. It must return the same shape the splat form above
+      # would: an array of stages, each a Symbol (sequential) or Array
+      # (parallel group).
       #
       #   depends_on -> { [all_commands.keys.grep(/_check\z/).map(&:to_sym)] }
-      def depends_on(*tasks)
+      #   depends_on { [all_commands.keys.grep(/_check\z/).map(&:to_sym)] }
+      def depends_on(*tasks, &block)
+        if block
+          raise Asgard::Error, "depends_on accepts either task arguments or a block, not both" if tasks.any?
+
+          tasks = [block]
+        end
+
         @_pending_deps = tasks
       end
 
@@ -65,7 +73,9 @@ module Asgard
         _deps.each do |task, stages_or_proc|
           next unless stages_or_proc.respond_to?(:call)
 
-          _deps[task] = _stages_from(Array(_call_dep_proc(task, stages_or_proc)))
+          result = Array(_call_dep_proc(task, stages_or_proc))
+          _validate_dep_shape!(task, result)
+          _deps[task] = _stages_from(result)
         end
       end
 
@@ -75,6 +85,32 @@ module Asgard
         raise Asgard::Error, "depends_on proc for '#{task}' raised #{e.class}: #{e.message}"
       end
 
+      # A resolved proc/lambda/block result must be an Array of stages, each
+      # either a Symbol/String (sequential) or an Array of Symbol/String
+      # (parallel group) — no deeper nesting, no other leaf types.
+      def _validate_dep_shape!(task, result)
+        result.each { |stage| _validate_dep_stage!(task, stage) }
+      end
+
+      def _validate_dep_stage!(task, stage)
+        case stage
+        when Symbol, String then nil
+        when Array           then stage.each { |leaf| _validate_dep_leaf!(task, leaf) }
+        else
+          raise Asgard::Error,
+                "depends_on proc/block for '#{task}' returned invalid stage #{stage.inspect} " \
+                "(#{stage.class}); expected a Symbol, String, or Array of them"
+        end
+      end
+
+      def _validate_dep_leaf!(task, leaf)
+        return if leaf.is_a?(Symbol) || leaf.is_a?(String)
+
+        raise Asgard::Error,
+              "depends_on proc/block for '#{task}' returned invalid dependency #{leaf.inspect} " \
+              "(#{leaf.class}) in a parallel group; expected a Symbol or String"
+      end
+
       def _check_orphaned_deps!
         pending = Array(@_pending_deps)
         return unless pending.any?
@@ -107,7 +143,7 @@ module Asgard
       # the order itself isn't otherwise used (execution order comes from the
       # stage groups each task's own depends_on declared).
       def _build_and_sort_graph(all_task_names)
-        full_graph = all_task_names.to_h { |task| [task, _deps.fetch(task, []).flatten] }
+        full_graph = all_task_names.to_h { |task| [task, _deps.fetch(task) { [] }.flatten] }
         Graph.new(full_graph).tsort
       end
 

data/lib/asgard/base/task_dsl.rb

@@ -48,11 +48,10 @@ module Asgard
         here   = caller_locations(1, 1).first if active
 
         if active && @_default_task_location
-          # rubocop:disable Style/StderrPuts -- warn bypasses $stderr in Ruby 4.0, breaking capture_io in tests
+          # rubocop:disable-next Style/StderrPuts -- warn bypasses $stderr in Ruby 4.0, breaking capture_io in tests
           $stderr.puts "asgard: default_task :#{meth} at #{here.path}:#{here.lineno} " \
                        "overrides default_task :#{@_default_task_name} set at " \
                        "#{@_default_task_location.path}:#{@_default_task_location.lineno}"
-          # rubocop:enable Style/StderrPuts
         end
         if active
           @_default_task_location = here

data/lib/asgard/errors.rb

@@ -0,0 +1,7 @@
+# frozen_string_literal: true
+
+# Required first: Asgard::Schedule::Error subclasses Asgard::Error.
+module Asgard
+  class Error < StandardError; end
+  class CircularDependencyError < Error; end
+end