@yemi33/minions 0.1.2364 → 0.1.2366

package/docs/tutorials/01-install-and-connect.md

@@ -0,0 +1,87 @@
+# Tutorial 1: Install and Connect a Project
+
+You will install Minions, verify the default Copilot runtime, link one Git
+repository, and start the engine and dashboard.
+
+## Prerequisites
+
+- Node.js 22.5 or newer
+- Git
+- GitHub Copilot CLI, Claude Code, or Codex CLI with working authentication
+- A local Git repository with an `origin` remote
+
+Minions defaults to GitHub Copilot CLI. Install it if you have not selected a
+different runtime:
+
+```bash
+npm install -g @github/copilot
+```
+
+## 1. Install and initialize
+
+```bash
+npm install -g @yemi33/minions
+minions init
+```
+
+Initialization creates the operator home at `~/.minions/`, including agent
+charters, playbooks, routing, prompts, and the SQLite state database.
+
+## 2. Verify the host
+
+```bash
+minions doctor
+```
+
+Resolve every `FAIL` before dispatching. Warnings are non-blocking but should be
+read: a permission-flag warning can mean that the selected CLI will stop for an
+interactive prompt during a headless dispatch.
+
+To choose another runtime:
+
+```bash
+minions config set-cli claude
+# or
+minions config set-cli codex
+```
+
+Run `minions doctor` again after switching.
+
+## 3. Link a repository
+
+```bash
+minions add C:\code\sample-project
+```
+
+On macOS or Linux, use the corresponding path such as
+`~/code/sample-project`. Confirm the detected host, repository, main branch,
+and description. The description helps agents route project-agnostic work, so
+describe the repository's responsibility rather than its implementation
+language.
+
+Confirm the result:
+
+```bash
+minions list
+```
+
+## 4. Start Minions
+
+```bash
+minions start --open
+```
+
+`start` is idempotent and starts both the engine and dashboard. If browser
+launch is blocked, run `minions dash`.
+
+## Checkpoint
+
+```bash
+minions status
+```
+
+You should see the engine running, your project listed, and no failed
+dispatches. In the dashboard, verify that the project appears in the project
+picker and that the agent cards are idle.
+
+Next: [ship your first task](02-first-task.md).

package/docs/tutorials/02-first-task.md

@@ -0,0 +1,73 @@
+# Tutorial 2: Ship Your First Task
+
+You will queue a small documentation change, observe routing and live output,
+and inspect the resulting work item and pull request.
+
+## 1. Choose a bounded task
+
+Start with a task that has one clear result and a cheap validation step:
+
+```bash
+minions work "Add a short Development section to README.md that names the existing test command"
+```
+
+For precise project selection, use the dashboard's **Work** page or Command
+Center and select the linked project instead of Auto. A project-scoped task is
+better than auto-routing while learning the lifecycle.
+
+## 2. Wake and inspect the queue
+
+The engine checks for work on its normal tick. You can wake it immediately:
+
+```bash
+minions dispatch
+minions queue
+```
+
+The item normally moves from `pending` to `dispatched`. If it remains pending,
+open its detail view and read `_pendingReason`; common reasons are an unmet
+dependency, no available agent, cooldown, or concurrency limits.
+
+## 3. Follow the agent
+
+In the dashboard:
+
+1. Open **Home** and select the working agent.
+2. Watch **Live Output** for repository exploration, edits, and checks.
+3. Open **Work** and select the item to inspect its branch, output, and
+   artifacts.
+
+The engine chooses an agent from `routing.md`, creates an isolated worktree for
+mutating work, renders the work-type playbook, and invokes the configured
+runtime adapter.
+
+## 4. Inspect the outcome
+
+```bash
+minions status
+minions queue
+```
+
+A successful code-changing task should finish with a branch and pull request.
+If the runtime reports success without the required artifact, the work item can
+still be flagged for lifecycle follow-up.
+
+If the item fails, read its failure class and output before retrying:
+
+```bash
+minions wi show <work-item-id>
+minions wi retry <work-item-id>
+```
+
+Do not retry authentication, invalid configuration, or workspace-permission
+failures without correcting the cause first.
+
+## Checkpoint
+
+You have observed the full path:
+
+```text
+work item -> routing -> worktree -> runtime -> checks -> branch/PR -> completion
+```
+
+Next: [build a feature from a plan](03-plan-driven-feature.md).

package/docs/tutorials/03-plan-driven-feature.md

@@ -0,0 +1,73 @@
+# Tutorial 3: Build a Feature from a Plan
+
+Use a plan when the outcome spans several independently verifiable changes.
+You will create a plan, review its PRD, approve it, and follow dependency-aware
+implementation through verification.
+
+## 1. Draft the request
+
+Open Command Center and enter:
+
+```text
+/plan Add a health endpoint to SampleProject, document it, and add automated
+tests. Keep implementation, tests, and documentation as separate items with
+explicit dependencies.
+```
+
+The plan agent writes Markdown under `plans/`. The plan-to-PRD step then creates
+structured items under `prd/` with acceptance criteria and `depends_on`
+relationships.
+
+You can also provide plan text from the CLI:
+
+```bash
+minions plan "Add a health endpoint, tests, and operator documentation" SampleProject
+```
+
+## 2. Review before approval
+
+Open **Plans** and inspect:
+
+- every item has a concrete deliverable;
+- acceptance criteria can be tested;
+- dependencies use item IDs and are acyclic;
+- each item names the correct project;
+- rejected or out-of-scope ideas are explicit.
+
+Use **Discuss & Revise** for corrections. Approval is the human gate that
+materializes work items, so do not approve a vague PRD and expect routing to
+repair it.
+
+## 3. Approve and observe dependency gating
+
+Approve the plan, then inspect **Work**. Independent items can dispatch in
+parallel. Dependent items stay pending until their prerequisites are done.
+
+At spawn time, Minions resolves completed dependencies to their pull-request
+branches and merges those branches into the dependent item's worktree. This
+lets later items build on code that has not reached the main branch yet.
+
+## 4. Follow verification
+
+When all implementation items finish, Minions creates a `verify` work item.
+Verification builds and tests the combined result and must attach a pull
+request when its contract requires one. A completed plan remains visible until
+you archive it manually.
+
+Archive only after reviewing the verify result:
+
+```bash
+minions plans list
+minions plans archive <plan-or-prd-id>
+```
+
+Archived PRDs remain retained in place; the source plan Markdown moves to
+`plans/archive/`.
+
+## Checkpoint
+
+You should have an approved PRD, materialized work items, dependency-aware
+branches, and a final verification result. See
+[Plan Lifecycle](../plan-lifecycle.md) for status and archive details.
+
+Next: [configure runtimes and project tools](04-runtimes-and-harness.md).

package/docs/tutorials/04-runtimes-and-harness.md

@@ -0,0 +1,77 @@
+# Tutorial 4: Choose Runtimes and Propagate Project Tools
+
+Minions can dispatch with Copilot CLI, Claude Code, or Codex. This tutorial
+switches the fleet runtime, separates Command Center from agent settings, and
+checks which skills, commands, and MCP configurations reach a worktree.
+
+## 1. Inspect the current fleet
+
+```bash
+minions status
+minions doctor --harness
+```
+
+The harness report is read-only. It lists runtime asset directories, skill
+roots, slash-command roots, and MCP configuration paths.
+
+## 2. Select a fleet runtime
+
+```bash
+minions config set-cli copilot --model gpt-5.4
+minions restart
+```
+
+Use a model ID supported by your installed CLI. Omit `--model` to let the CLI
+choose its default. To clear a persisted model while switching:
+
+```bash
+minions restart --cli claude --model ""
+```
+
+Fleet resolution is:
+
+```text
+agent.cli -> engine.defaultCli -> copilot
+agent.model -> engine.defaultModel -> runtime default
+```
+
+Command Center has independent `engine.ccCli` and `engine.ccModel` overrides.
+Changing CC does not silently switch dispatched agents.
+
+## 3. Add a project-local skill
+
+In the linked repository's main checkout, create a committed skill under:
+
+```text
+.claude/skills/<skill-name>/SKILL.md
+```
+
+Describe when the skill applies and provide the exact existing project command
+to run. Commit the skill if every worktree should receive it. Uncommitted
+project-local assets can be propagated from the live checkout when
+`engine.harnessPropagateProjectLocal` is enabled, but committed assets are more
+reproducible.
+
+## 4. Verify propagation
+
+```bash
+minions doctor --harness
+```
+
+Dispatch a small task that clearly matches the skill. The completion report's
+`harnessUsed` section distinguishes assets that were available from those the
+agent reports actually using.
+
+For a known-empty execution environment, enable `hermeticHarness` for an agent
+or the fleet. This removes user asset directories and project harness
+propagation; use it for reproducibility tests, not as an MCP process-launch
+control.
+
+## Checkpoint
+
+The selected runtime passes doctor, your project asset appears in the harness
+survey, and a matching dispatch reports whether it used that asset.
+
+Reference: [Runtime Adapters](../runtime-adapters.md),
+[Harness Propagation](../harness-propagation.md), and
+[Harness Transparency](../harness-transparency.md).

package/docs/tutorials/05-schedules-and-watches.md

@@ -0,0 +1,71 @@
+# Tutorial 5: Automate Recurring Work and Follow-Ups
+
+Schedules create work at a time; watches react to state changes. You will create
+one of each and verify them without waiting for the clock.
+
+## 1. Explore the live schemas
+
+```bash
+minions schedule --help
+minions watch --help
+minions watch target-types
+minions watch action-types
+```
+
+Use the dashboard forms for your first records. They validate against the same
+server-side schemas as the CLI JSON commands.
+
+## 2. Create a schedule
+
+Open **Schedule**, create a disabled schedule named `weekly-doc-check`, select
+your sample project, and use a task such as:
+
+```text
+Review README.md for commands that no longer match the CLI. Correct only
+verified stale claims and report the source lines used.
+```
+
+Use the natural-language parser or cron builder to choose a weekly time. Save
+the schedule disabled, then use **Run now** to test it.
+
+From the CLI:
+
+```bash
+minions schedule list
+minions schedule run-now <schedule-id>
+```
+
+Confirm that a work item appears before enabling the recurring schedule.
+
+## 3. Create a watch
+
+Open **Watches** and create a watch for the test work item:
+
+- target type: `work-item`
+- target: the work-item ID
+- condition: `completed`
+- owner: `human`
+- stop after: `0`
+
+For an absolute condition such as `completed`, `stopAfter: 0` means fire once
+and expire. For change conditions, zero means continue indefinitely.
+
+Choose the default inbox notification first. Follow-up actions can dispatch
+work, call a webhook, trigger a pipeline, run a skill, or invoke CC triage, but
+they should be added only after the condition itself is proven.
+
+## 4. Observe the trigger
+
+```bash
+minions watch list
+minions watch show <watch-id>
+```
+
+Watches are evaluated on their polling cadence, not every engine tick. After
+the work item completes, confirm the watch records a trigger and an inbox note.
+
+## Checkpoint
+
+You have tested time-based creation and condition-based reaction independently.
+See [Watches](../watches.md) for predicates, plugins, templating, guards, and
+action chains.

package/docs/tutorials/06-managed-services.md

@@ -0,0 +1,85 @@
+# Tutorial 6: Keep a Development Service Running
+
+Use managed spawn when later agents need a dev server, emulator, or daemon to
+survive the creating agent's exit. The engine owns the process, checks health,
+and exposes it to later dispatches.
+
+## 1. Prove the service manually
+
+In the worktree that will host the service:
+
+1. Install its existing dependencies.
+2. Run the real start command for at least five seconds.
+3. Probe the intended health endpoint and verify the expected status.
+4. Stop the test process.
+
+Do not derive a managed-spawn spec from package names or guessed monorepo
+filters. A command that exits immediately will not become reliable because the
+engine starts it.
+
+## 2. Dispatch a managed-spawn work item
+
+Create a project-scoped work item through the API so the opt-in metadata is
+explicit. Save a temporary `managed-work-item.json`:
+
+```json
+{
+  "title": "Start the sample development service",
+  "description": "Start the existing development service and leave it available for downstream validation.",
+  "project": "SampleProject",
+  "type": "implement",
+  "meta": {
+    "managed_spawn": true,
+    "managed_spawn_ttl_minutes": 120
+  }
+}
+```
+
+Submit it, then delete the temporary file:
+
+```bash
+minions api POST /api/work-items --body-file managed-work-item.json
+```
+
+The rendered playbook tells the agent where to write
+`agents/<id>/managed-spawn.json` and includes the current executable allowlist
+and schema. The declared `cwd` must be an absolute path that exists when the
+agent exits; the agent should derive it from its current worktree.
+
+## 3. Require a healthcheck
+
+For a web service, use an HTTP healthcheck:
+
+```json
+{
+  "type": "http",
+  "url": "http://localhost:3000/health",
+  "expect_status": 200,
+  "interval_s": 1,
+  "timeout_s": 60
+}
+```
+
+For an emulator or non-HTTP daemon, use a command healthcheck that exits zero
+and matches a stable readiness signal.
+
+## 4. Inspect and use the service
+
+Open **Engine** and find **Managed Processes**, or query:
+
+```bash
+minions api GET /api/managed-processes
+```
+
+Confirm the process is healthy, its log path is populated, and its expiration
+time is correct. Dispatch a second work item in the same project and verify
+that the live managed-process context is included in its prompt.
+
+Use `meta.keep_processes` instead when the agent itself must retain an ad-hoc
+child with no health endpoint. Prefer managed spawn for named services.
+
+## Checkpoint
+
+The service remains healthy after the creating agent exits and is visible to a
+later dispatch. Read [Managed Spawn](../managed-spawn.md) for the full sidecar,
+allowlist, restart, log-stream, and partial-failure contracts.

package/docs/tutorials/07-cross-repo-plan.md

@@ -0,0 +1,56 @@
+# Tutorial 7: Coordinate a Cross-Repository Change
+
+Cross-repository plans keep one product outcome together while materializing
+each item into the project that owns its code.
+
+## 1. Link and name both projects
+
+```bash
+minions add C:\code\sample-api
+minions add C:\code\sample-web
+minions list
+```
+
+Give each project a distinct responsibility in its description. Cross-repo
+routing is much easier to review when `sample-api` and `sample-web` do not both
+say only "application code."
+
+## 2. Request a cross-repo plan
+
+In Command Center:
+
+```text
+/plan Add an API capability in sample-api and consume it from sample-web.
+Create separately testable items, assign every item to one project, and make
+the web integration depend on the API contract item.
+```
+
+The plan must declare both target projects, and every PRD item must have a valid
+`project` value matching a configured project name.
+
+## 3. Review the dependency boundary
+
+Before approval, confirm:
+
+- shared contracts are explicit acceptance criteria;
+- each item edits only one repository;
+- cross-repo `depends_on` records sequencing intent;
+- each repository has its own verification responsibility.
+
+Cross-repo dependencies are advisory for merge coordination. They do not make
+separate repositories share a Git history or automatically merge one repo's
+branch into another.
+
+## 4. Approve and observe fan-out
+
+Approval materializes items into each project's work-item store. Minions creates
+one verify work item per touched project after implementation completes.
+Inspect both project filters in **Work** and **Plans** rather than assuming the
+central plan card shows every repository-specific detail.
+
+## Checkpoint
+
+Both projects have correctly scoped work items and independent verification
+results, while the source plan remains one reviewable artifact.
+
+Reference: [Cross-Repo Plans](../cross-repo-plans.md).

package/docs/tutorials/08-operations-and-recovery.md

@@ -0,0 +1,76 @@
+# Tutorial 8: Operate and Recover Minions
+
+This tutorial builds a repeatable triage order for engine, dispatch, runtime,
+and worktree failures.
+
+## 1. Start with supported summaries
+
+```bash
+minions status
+minions queue
+minions sources
+```
+
+Use the dashboard **Engine** page for dispatch logs, metrics, managed processes,
+and worktree state. Read JSON sidecars only as diagnostics; migrated runtime
+state is canonical in `engine/state.db`.
+
+## 2. Classify before acting
+
+For a pending item, inspect `_pendingReason`. For a failed item, inspect its
+failure class and final output. Correct non-retryable causes such as
+authentication, invalid manifests, bad managed-spawn schemas, or dirty live
+checkouts before retrying.
+
+```bash
+minions wi show <work-item-id>
+minions wi retry <work-item-id>
+```
+
+## 3. Restart safely
+
+`minions start` is idempotent. Use `minions restart` after changing engine
+configuration or playbooks:
+
+```bash
+minions restart
+minions status
+```
+
+Agents are independent child processes. A restart loses in-memory process
+handles, so Minions uses persisted dispatch state, PID data, live-output
+activity, and a restart grace period to recover or classify orphans. Do not
+delete worktrees or dispatch rows to force recovery.
+
+## 4. Use targeted recovery commands
+
+```bash
+minions dispatch    # wake the daemon; does not run a second tick loop
+minions cleanup     # run the supported cleanup path
+minions kill        # kill active agents and reset dispatches to pending
+```
+
+Use `kill` only when agents are genuinely wedged. Quiet output is not enough:
+tracked agents are allowed to be silent during long builds and tests.
+
+## 5. Protect against process-level outages
+
+For unattended installations, inspect and optionally install the external
+watchdog:
+
+```bash
+minions watchdog status
+minions watchdog install --interval=5
+```
+
+The watchdog complements the in-process supervisor by probing and recovering
+the engine through the operating system scheduler.
+
+## Checkpoint
+
+You can distinguish pending, failed, orphaned, and stopped states and can choose
+the least destructive supported action for each.
+
+References: [Engine Restart](../engine-restart.md),
+[Timeouts and Liveness](../timeouts-and-liveness.md), and
+[Worktree Lifecycle](../worktree-lifecycle.md).

package/docs/tutorials/README.md

@@ -0,0 +1,29 @@
+# Minions Tutorial Track
+
+These tutorials build on one another. Complete the first two before jumping to
+an advanced topic. Each tutorial ends with an observable result rather than
+only describing configuration.
+
+| Tutorial | Outcome | Time |
+|---|---|---:|
+| [1. Install and connect a project](01-install-and-connect.md) | A healthy engine, dashboard, and linked repository | 15 min |
+| [2. Ship your first task](02-first-task.md) | One scoped work item dispatched and tracked to completion | 15 min |
+| [3. Build a feature from a plan](03-plan-driven-feature.md) | An approved PRD with dependency-aware implementation and verification | 25 min |
+| [4. Choose runtimes and propagate project tools](04-runtimes-and-harness.md) | A configured fleet with verified skills, commands, and MCP visibility | 20 min |
+| [5. Automate recurring work and follow-ups](05-schedules-and-watches.md) | A schedule and a condition-based watch | 25 min |
+| [6. Keep a development service running](06-managed-services.md) | An engine-owned, health-checked development service | 25 min |
+| [7. Coordinate a cross-repository change](07-cross-repo-plan.md) | One plan fanned out safely across multiple projects | 30 min |
+| [8. Operate and recover Minions](08-operations-and-recovery.md) | A practical status, restart, retry, and diagnostics workflow | 20 min |
+
+## How to use the tutorials
+
+- Use a disposable repository for the first task if you do not want an agent to
+  open a real pull request.
+- Keep the dashboard open while following CLI steps. It is the easiest place to
+  see routing, pending reasons, live output, and artifacts together.
+- Treat JSON files under `engine/` and `projects/` as diagnostic mirrors.
+  `engine/state.db` is the primary store for migrated runtime state.
+- Use the linked reference docs when you need the full schema or lifecycle.
+  Tutorials intentionally focus on a successful path.
+
+For a shorter setup-only path, use [the first-30-minutes guide](../onboarding.md).

package/docs/watches.md

@@ -1,10 +1,10 @@
 # Watches
 
-Persistent monitoring jobs that fire inbox notifications and follow-up actions when a target hits a condition. Watches survive engine restarts and are checked every 3 ticks (~3 minutes by default).
+Persistent monitoring jobs that fire inbox notifications and follow-up actions when a target hits a condition. Watches survive engine restarts and are checked every 18 ticks (~3 minutes at the default 10-second tick).
 
 ## What a Watch Is
 
-A watch is a small JSON record persisted to `engine/watches.json`. It binds:
+A watch is a record persisted in `engine/state.db`; `engine/watches.json` is a passive diagnostic mirror. It binds:
 
 | Field        | Purpose                                                                 |
 |--------------|-------------------------------------------------------------------------|
@@ -20,7 +20,7 @@ A watch is a small JSON record persisted to `engine/watches.json`. It binds:
 | `requires`   | Optional guard: array of predicate objects evaluated against `state` / `entity` / `prevState`; trigger is suppressed when any guard fails (false-or-error). Used to gate a watch on "PR is mergeable AND build passing" etc. |
 | `status`     | `WATCH_STATUS.ACTIVE` \| `PAUSED` \| `TRIGGERED` \| `EXPIRED`            |
 
-`createWatch()` allocates a `watch-<uid>` id, defaults the fields above, and persists atomically via `mutateJsonFileLocked` *(source: `engine/watches.js:184-248`)*.
+`createWatch()` allocates a `watch-<uid>` id, defaults the fields above, and persists through the watch store *(source: `engine/watches.js` and `engine/watches-store.js`)*.
 
 ## Lifecycle (`WATCH_STATUS`)
 
@@ -94,7 +94,7 @@ The eight built-ins are registered at module load *(source: `engine/watches.js`
 
 | `targetType`  | Target value                         | Conditions                                                                 | Notes |
 |---------------|--------------------------------------|----------------------------------------------------------------------------|-------|
-| `pr`          | PR number, canonical id, or display id | `merged`, `build-fail`, `build-pass`, `status-change`, `any`, `new-comments`, `vote-change`, `head-commit-change`, `mergeable-flipped`, `ready-for-merge`, `behind-master`, `draft-flipped` | Reads from `pull-requests.json` for any project; `new-comments` watches `humanFeedback.lastProcessedCommentDate`; `behind-master` requires `engine.watchesIncludeBehindBy: true` so the GH poller populates `pr.behindBy` |
+| `pr`          | PR number, canonical id, or display id | `merged`, `build-fail`, `build-pass`, `status-change`, `any`, `new-comments`, `vote-change`, `head-commit-change`, `mergeable-flipped`, `ready-for-merge`, `behind-master`, `draft-flipped` | Reads project PR state; `new-comments` watches `humanFeedback.lastProcessedCommentDate`; `behind-master` requires `engine.watchesIncludeBehindBy: true` so the GH poller populates `pr.behindBy` |
 | `work-item`   | Work item id                         | `completed`, `failed`, `status-change`, `any`, `stalled`, `retry-limit-reached`, `dependency-met` | `completed` matches `DONE_STATUSES`; `failed` matches `WI_STATUS.FAILED`; `stalled` fires after N unchanged captures (default 12 ≈ 60 min); `retry-limit-reached` fires when `_retryCount >= ENGINE_DEFAULTS.maxRetries` |
 | `meeting`     | Meeting id                           | `concluded`, `status-change`, `any`                                        | `concluded` fires on terminal status (`completed`, `archived`) |
 | `plan`        | PRD JSON filename or plan id         | `approved`, `rejected`, `completed`, `status-change`, `any`, `all-items-done`, `item-failed-n-times` | Looked up by `_source` (PRD file), `_sourcePlan` (.md), or `id`; uses `PLAN_STATUS` |
@@ -145,7 +145,7 @@ Resolution is `path.join(shared.MINIONS_DIR, 'watches.d')` so it works in both d
 }
 ```
 
-`checkWatches` walks every active watch and, inside a single `mutateJsonFileLocked` callback *(source: `engine/watches.js:410-561`)*:
+`checkWatches` walks every active watch and persists updates through the watch store:
 
 1. Skips paused/expired watches and any watch checked within its `interval`.
 2. Captures a baseline `_lastState` on first check (so change conditions have something to diff).
@@ -166,7 +166,7 @@ I/O happens **outside the lock**: notifications via `writeToInbox`, follow-up ac
 | Action type            | What it does                                                                                  |
 |------------------------|-----------------------------------------------------------------------------------------------|
 | `notify`               | Explicit inbox write; lets you customize `owner`/`body` instead of the default trigger string |
-| `dispatch-work-item`   | Append a new WI to the project (or central) `work-items.json` with `createdBy: "watch:<id>"`  |
+| `dispatch-work-item`   | Add a new project or central work item with `createdBy: "watch:<id>"`  |
 | `run-skill`            | Wrapper around `dispatch-work-item` that asks the agent to run a specific `.claude` skill     |
 | `webhook`              | `http`/`https` request to an arbitrary URL (10s safety timeout, JSON or string body)          |
 | `minions-api`          | Loopback call to the in-process dashboard at `http://127.0.0.1:${shared.readDashboardPortFile(MINIONS_DIR)?.port \|\| 7331}` (reads the bound-port beacon file, not the `MINIONS_PORT` env, so it still resolves after an `EADDRINUSE` port scan) — `endpoint` must start with `/api/`; sets `X-Minions-Internal: 1`; returns `{ok, status, summary, response}` for chain-step templating |