@yemi33/minions 0.1.2363 → 0.1.2365

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 |

package/engine/lifecycle.js

@@ -6874,6 +6874,15 @@ function collapseAllDuplicatePrRecords(config) {
 // a coding WI (not one of the validation types itself). Skips if the coding WI
 // has no PR.
 //
+// W-mrdq22j700056c6c — gated to real code-authoring completions only. Only
+// item.type in {implement, implement:large, fix} ever spawns a follow-up
+// validation WI. Every other work-item type (review, test, verify, setup,
+// explore, ask, docs, decompose, ...) is excluded even when it resolves a PR
+// ref and autoDispatch is on, because those completions don't author a code
+// diff worth re-validating — e.g. a `review` dispatch that merely comments on
+// someone else's PR previously spawned a spurious "Validate: Review opg PR
+// #792 ..." follow-up. See the ELIGIBLE_TYPES check below.
+//
 // Files exactly ONE validation WI per coding-WI completion (W-mrhybval0001).
 // `liveValidation.type` still governs CHECKOUT ROUTING — the set of work-item
 // types that run in-place on the live checkout (see resolveCheckoutMode's
@@ -6893,6 +6902,10 @@ function collapseAllDuplicatePrRecords(config) {
 // own type is excluded so a validation-type WI can't recursively validate
 // itself (anti-loop).
 //
+// Only these item.type values ever trigger this hook (see ELIGIBLE_TYPES
+// below) — real code-authoring completions, not review/test/verify/setup/
+// explore/ask/docs/decompose completions.
+//
 // Deduplicates per codingWiId: any non-terminal WI with
 // meta.liveValidationFor === codingWiId blocks a second dispatch, so only one
 // validation task is ever in flight per coding completion.
@@ -6907,6 +6920,14 @@ function collapseAllDuplicatePrRecords(config) {
 // Validate: ..."), repeating indefinitely. Any WI that was itself created
 // as a liveValidation follow-up (tagged via meta.liveValidationFor at
 // creation, below) must never re-trigger this hook, regardless of its type.
+//
+// W-mrdq22j700056c6c — only real code-authoring work-item types ever spawn a
+// live-validation follow-up. Every other completed type (review, test,
+// verify, setup, explore, ask, docs, decompose, ...) is excluded even when it
+// resolves a PR ref, because those completions don't author a code diff
+// worth re-validating.
+const ELIGIBLE_LIVE_VALIDATION_TYPES = new Set([WORK_TYPE.IMPLEMENT, WORK_TYPE.IMPLEMENT_LARGE, WORK_TYPE.FIX]);
+
 function autoDispatchLiveValidationWi(meta, config) {
   const item = meta?.item;
   if (!item?.id || !item?.type) return;
@@ -6916,6 +6937,12 @@ function autoDispatchLiveValidationWi(meta, config) {
   // "Validate: Validate: ..." cascade (W-mr9u39az000db5c2 / issue #708).
   if (item.meta && item.meta.liveValidationFor) return;
 
+  // W-mrdq22j700056c6c — only implement/implement:large/fix completions ever
+  // author a real code diff worth validating. Review, test, verify, setup,
+  // explore, ask, docs, decompose, etc. completions must never spawn a
+  // "Validate: ..." follow-up, even when they resolve a PR reference.
+  if (!ELIGIBLE_LIVE_VALIDATION_TYPES.has(item.type)) return;
+
   // Issue #716 — QA Session infrastructure WIs (SETUP/DRAFT/EXECUTE, tagged
   // via meta.sessionId and always dispatched with skipPr:true) never own a
   // real code diff, so there is nothing for a live-validation WI to validate.

package/engine/playbook.js

@@ -1060,12 +1060,12 @@ function renderPlaybook(type, vars) {
 // ─── Playbook Section Validator ──────────────────────────────────────────────
 
 // Required structural section patterns — warn (do not throw) when absent.
-// Only '## Your Task' is checked: it's the one section every playbook template
-// actually implements. '## Tools' / '## Constraints' were removed (#775) —
-// no template in playbooks/ defines those headers, so the checks always
-// failed and produced 100%-failure-rate warn-level noise in engine/log.json.
+// Playbooks use a few established names for the task-bearing section; accept
+// all of them rather than generating warn-level noise for valid templates.
+// '## Tools' / '## Constraints' were removed (#775) because no template
+// consistently implements those headers.
 const _REQUIRED_PROMPT_SECTIONS = [
-  { pattern: /^## Your Task\b/m,   label: '## Your Task' },
+  { pattern: /^## (?:Your Task|Task Description|Mission)\b/m, label: 'task section' },
 ];
 
 /**

package/engine/process-utils.js

@@ -566,9 +566,9 @@ function findProcessCwdHolders(worktreePath, opts = {}) {
   return _parseCwdHolderLines(raw, resolved);
 }
 
-// Cross-check a single PID's command line for a Minions agent invocation
-// (`claude` or `copilot`, including the `node spawn-agent.js --runtime <name>`
-// wrapper and `gh copilot` fallback). Used by orphan/recycled-PID safety:
+// Cross-check a single PID's command line for a Minions agent invocation,
+// including the shared spawn wrapper and every bundled runtime CLI. Used by
+// orphan/recycled-PID safety:
 //   - engine/cleanup.js: gate before killing a PID found in engine/tmp/pid-*.pid
 //   - engine/timeout.js: gate before parking a dispatch as still-alive when
 //     the OS PID is alive but may belong to an unrelated recycled-PID process
@@ -578,9 +578,20 @@ function findProcessCwdHolders(worktreePath, opts = {}) {
 // macOS / when /proc isn't available: fallback `ps -p <pid> -o command=`.
 //
 // Returns false when the PID is invalid, the process doesn't exist, the
-// command line can't be read, or the cmdline contains neither `claude` nor
-// `copilot`. False is the safe default for both call sites: cleanup falls
+// command line can't be read, or the cmdline contains no recognized agent
+// marker. False is the safe default for both call sites: cleanup falls
 // through to "skip kill" and timeout falls through to "treat PID as dead".
+const AGENT_COMMAND_PATTERNS = [
+  /(?:^|[\s"'\\/])(?:claude|copilot|codex)(?:\.exe|\.cmd|\.bat|\.js)?(?=$|[\s"])/i,
+  /[\\/]claude-code[\\/]cli\.js(?=$|[\s"])/i,
+  /[\\/]@github[\\/](?:copilot|copilot-cli)[\\/](?:(?:dist|bin)[\\/])?index\.js(?=$|[\s"])/i,
+];
+
+function _commandLineMatchesAgent(cmdline) {
+  const value = String(cmdline || '');
+  return AGENT_COMMAND_PATTERNS.some(pattern => pattern.test(value));
+}
+
 function isProcessCommandLineMatchingAgent(pid) {
   const n = Number(pid);
   if (!Number.isInteger(n) || n <= 0) return false;
@@ -605,8 +616,7 @@ function isProcessCommandLineMatchingAgent(pid) {
     }
   } catch { return false; }
   if (!cmdline) return false;
-  const lower = cmdline.toLowerCase();
-  return lower.includes('claude') || lower.includes('copilot');
+  return _commandLineMatchesAgent(cmdline);
 }
 
 function _buildChildMap(processes) {
@@ -693,6 +703,7 @@ module.exports = {
   _parseCwdHolderLines,
   findProcessCwdHolders,
   isProcessCommandLineMatchingAgent,
+  _commandLineMatchesAgent, // exported for testing
   _buildChildMap,
   listProcessDescendants,
   listProcessReachable,

package/engine/queries.js

@@ -3283,10 +3283,6 @@ function getStatusFastStateMtimePaths(config) {
  *     Claude CLI mutations (mcp add/remove, settings edits), not on every
  *     prompt, so whole-file tracking is acceptable.
  *
- * Files intentionally NOT tracked here:
- *   - version, autoMode, installId — change only on human/CLI edits, which
- *     already pop the slow-state via reloadConfig + the 60 s TTL.
- *
  * Per-project `.git/logs/HEAD` + `.git/FETCH_HEAD` ARE tracked here in
  * addition to the fast-state tracker. The project payload (`projects:`
  * with ahead/behind counts) lives in the slow-state slice, and
@@ -3327,6 +3323,14 @@ function getStatusSlowStateMtimePaths(config) {
   // in the payload anymore.
   const files = [];
 
+  // Config-derived status fields (projects, autoMode, version settings) can be
+  // changed by the CLI or another process without calling dashboard-local
+  // invalidateStatusCache(). The unified cache has no TTL fallback, so these
+  // source files must participate in the mtime registry.
+  files.push(CONFIG_PATH);
+  files.push(path.join(MINIONS_DIR, '.install-id'));
+  files.push(path.join(MINIONS_DIR, 'package.json'));
+
   // Skill discovery roots (surfaced by _buildStatusSlowState → getSkills).
   // Mirrors collectSkillFiles' source enumeration so adding a new runtime
   // adapter automatically extends the tracker. ENOENT is tolerated by

package/engine/shared.js

@@ -6327,16 +6327,18 @@ function resolveAgentTempBaseDir(project, engine, minionsDir) {
 
 // Seed the agent COPILOT_HOME's mcp-config (copy of `~/.copilot/mcp-config.json`
 // MINUS `engine.copilotAgentDisabledMcpServers`) and return the home path. This
-// is the single source of truth for "what MCP servers may a minions-spawned
-// copilot load." It is applied to EVERY copilot spawn path — agent dispatches
-// (engine), internal `llm.callLLM` calls (engine), and CC / doc-chat / the CC
-// worker pool (dashboard) — by setting `process.env.COPILOT_HOME` at the boot of
-// both processes, so every copilot CHILD inherits the filtered config. copilot
-// SPAWNS every server in its config and authenticates it (`--disable-mcp-server`
-// only hides tools), so any auth-requiring server pops a Microsoft window per
-// spawn — filtering the config is the only effective control. Idempotent: writes
-// only when the content changes (safe under concurrent callers). The operator's
-// real `~/.copilot` (interactive copilot) is never touched. Fail-open.
+// is the source of truth for "what MCP servers may an agent-dispatch copilot
+// load." It is applied to the engine-process copilot spawn paths ONLY — agent
+// dispatches (`_applyAgentCopilotHome`) and the engine process's own internal
+// `llm.callLLM` calls — by setting `process.env.COPILOT_HOME` at engine boot
+// and re-stamping it per dispatch, so those copilot CHILDREN inherit the
+// filtered config. copilot SPAWNS every server in its config and
+// authenticates it (`--disable-mcp-server` only hides tools), so any
+// auth-requiring server pops a Microsoft window per spawn — filtering the
+// config is the only effective control. Idempotent: writes only when the
+// content changes (safe under concurrent callers). The operator's real
+// `~/.copilot` (interactive copilot, and now also Command Center / doc-chat /
+// the CC worker pool, per W-mre75l6x00024f49) is never touched. Fail-open.
 function ensureAgentCopilotHome(minionsDir, engine) {
   const home = resolveAgentCopilotHome(minionsDir);
   try {
@@ -7882,7 +7884,17 @@ function upsertPullRequestRecord(prPath, entry, { project = null, itemId = null,
     ...(Array.isArray(itemIds) ? itemIds : [itemId]),
   ]);
   const prNumber = getPrNumber(entry.prNumber ?? entry.id ?? entry.url);
-  const canonicalId = getCanonicalPrId(project, entry.prNumber ?? entry.id ?? entry.url ?? prNumber, entry.url || '');
+  // Issue #802: when the caller already resolved a scope-qualified canonical
+  // id (e.g. `ado:office/office/office#5370216`, as enrollPrFromCanonicalId
+  // does before calling here), it must win over recomputing from a bare
+  // entry.prNumber + project. Recomputing silently downgrades to a legacy
+  // `PR-<n>` stub whenever project is null/unresolvable (getCanonicalPrId
+  // can't derive a scope), discarding the good id even though it was passed
+  // in. Prefer entry.id whenever it already parses as canonical.
+  const hasCanonicalEntryId = typeof entry.id === 'string' && parseCanonicalPrId(entry.id) != null;
+  const canonicalId = hasCanonicalEntryId
+    ? getCanonicalPrId(project, entry.id, entry.url || '')
+    : getCanonicalPrId(project, entry.prNumber ?? entry.id ?? entry.url ?? prNumber, entry.url || '');
   if (!canonicalId) throw new Error('PR id required');
   const normalizedEntry = {
     ...entry,

package/engine/worktree-gc.js

@@ -769,9 +769,9 @@ function pruneOrphanWorktrees(opts) {
   const globalLiveDirNames = new Set();
   for (const d of [...(dispatchSnap.active || []), ...(dispatchSnap.pending || [])]) {
     if (!d || !d.id || !d.meta || !d.meta.branch) continue;
-    const dispatchProject = (d.meta.project && typeof d.meta.project === 'string')
+    const dispatchProject = typeof d.meta.project === 'string'
       ? d.meta.project
-      : 'default';
+      : (d.meta.project?.name || 'default');
     try {
       globalLiveDirNames.add(_buildWorktreeDirName({
         dispatchId: d.id,

package/engine.js

@@ -10141,7 +10141,9 @@ async function discoverWork(config) {
             const activeMissionIds = new Set();
             const activeScheduleIds = new Set();
             for (const existing of items) {
-              if (existing.status === WI_STATUS.DONE || existing.status === WI_STATUS.FAILED) continue;
+              if (DONE_STATUSES.has(existing.status) ||
+                  existing.status === WI_STATUS.FAILED ||
+                  existing.status === WI_STATUS.CANCELLED) continue;
               if (existing._missionId) activeMissionIds.add(existing._missionId);
               if (existing._scheduleId) activeScheduleIds.add(existing._scheduleId);
             }
@@ -11809,8 +11811,11 @@ if (require.main === module) {
   // `llm.callLLM` calls (consolidation, classification, meetings, …) — inherits
   // this process's COPILOT_HOME, so point it at the seeded, MCP-filtered home.
   // Without this, those `direct:true` copilot calls load the operator's full
-  // `~/.copilot` stack and pop a Microsoft auth window per call. The dashboard
-  // sets the same at its own boot for CC / doc-chat / the CC worker pool.
+  // `~/.copilot` stack and pop a Microsoft auth window per call. This isolation
+  // is engine-process-only: the dashboard process deliberately does NOT set
+  // COPILOT_HOME at its own boot, so Command Center / doc-chat / the CC worker
+  // pool inherit the operator's real `~/.copilot` home instead (reverted in
+  // W-mre75l6x00024f49; see dashboard.js boot for rationale).
   // See shared.ensureAgentCopilotHome. Fail-open.
   try { process.env.COPILOT_HOME = shared.ensureAgentCopilotHome(MINIONS_DIR, getConfig()?.engine); } catch {}
   const { handleCommand } = require('./engine/cli');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.2363",
+  "version": "0.1.2365",
   "description": "Multi-agent AI dev team that runs from ~/.minions/ — five autonomous agents share a single engine, dashboard, and knowledge base",
   "bin": {
     "minions": "bin/minions.js"