@yemi33/minions 0.1.2162 → 0.1.2163
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/preflight.md +43 -0
- package/package.json +1 -1
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
# Preflight & Doctor
|
|
2
|
+
|
|
3
|
+
`minions doctor` (and the lighter `minions preflight` that runs on every CLI
|
|
4
|
+
invocation) inspects the local environment for the conditions Minions needs
|
|
5
|
+
to dispatch agents reliably. Every row is one of: `OK`, `WARN`, `FAIL`.
|
|
6
|
+
|
|
7
|
+
This page documents the rows that are not self-explanatory from their message.
|
|
8
|
+
|
|
9
|
+
## "Permission bypass: \<runtime\>"
|
|
10
|
+
|
|
11
|
+
Minions dispatches agents in **headless** mode — no human is sitting at the
|
|
12
|
+
terminal to answer "Allow this tool to run X?" permission prompts. Every
|
|
13
|
+
agent runtime adapter therefore declares a `permissionBypassFlags` list (the
|
|
14
|
+
flag set that tells the underlying CLI to skip every interactive permission
|
|
15
|
+
prompt). At doctor time we shell out to `<runtime> --help` and confirm those
|
|
16
|
+
flags still appear in the help text.
|
|
17
|
+
|
|
18
|
+
The check emits **WARN** (not FAIL) so an outdated or unusual CLI install
|
|
19
|
+
doesn't block existing dispatches — Minions still passes the flags, the
|
|
20
|
+
agent just risks hanging on a prompt if the CLI doesn't honor them.
|
|
21
|
+
|
|
22
|
+
WARN cases and remedies:
|
|
23
|
+
|
|
24
|
+
| Case | Meaning | Fix |
|
|
25
|
+
|------|---------|-----|
|
|
26
|
+
| `adapter did not declare permissionBypassFlags` | The runtime adapter is missing its declared bypass-flag list. Internal bug — open an issue. | Code change in `engine/runtimes/<name>.js`. |
|
|
27
|
+
| `could not invoke <runtime> --help` | The runtime binary was found but `--help` failed (exit non-zero, timeout, or no output). | Re-install the CLI; verify `<runtime> --help` works in a fresh shell. |
|
|
28
|
+
| `--help does not list expected flag(s): <flags>` | The installed CLI version is older than the flags Minions expects, **or** the resolved binary is a different CLI with the same name. | Update the CLI: `npm i -g @anthropic-ai/claude-code` for Claude, `winget upgrade Microsoft.CopilotCLI` (Windows) or `npm i -g @github/copilot` for the Copilot CLI. |
|
|
29
|
+
|
|
30
|
+
### The `gh copilot` vs Copilot-CLI gotcha
|
|
31
|
+
|
|
32
|
+
On Linux CI agents, `which copilot` often resolves to `/usr/bin/gh` — the
|
|
33
|
+
GitHub CLI's **`gh copilot`** extension, not the standalone **Copilot CLI**
|
|
34
|
+
(`@github/copilot`). They share the binary name but have completely
|
|
35
|
+
different flag sets. The `gh copilot` extension does NOT accept
|
|
36
|
+
`--autopilot`, `--allow-all`, or `--no-ask-user`, so the WARN row will fire
|
|
37
|
+
even though the binary "works".
|
|
38
|
+
|
|
39
|
+
The warn is legitimate — dispatched agents using that binary would hang on
|
|
40
|
+
permission prompts. Install the standalone Copilot CLI (`npm i -g
|
|
41
|
+
@github/copilot`) ahead of `gh` in `$PATH`, or configure
|
|
42
|
+
`agents.<id>.cli` to point at the absolute path of the real Copilot CLI
|
|
43
|
+
binary.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@yemi33/minions",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.2163",
|
|
4
4
|
"description": "Multi-agent AI dev team that runs from ~/.minions/ — five autonomous agents share a single engine, dashboard, and knowledge base",
|
|
5
5
|
"bin": {
|
|
6
6
|
"minions": "bin/minions.js"
|