@yemi33/minions 0.1.2379 → 0.1.2381

package/minions.js

@@ -162,7 +162,7 @@ async function addProject(targetDir) {
     process.exit(1);
   }
 
-  shared.ensureProjectStateFiles(projectEntry);
+  shared.initializeProjectState(projectEntry);
   config.projects.push(projectEntry);
   saveConfig(config);
 
@@ -383,7 +383,7 @@ async function scanAndAdd({ root, depth } = {}) {
       repoHost: repo.host, repositoryId: repo.repositoryId, org: repo.org, project: repo.project,
       repoName: repo.repoName, mainBranch: repo.mainBranch, prUrlBase: repo.prUrlBase,
     });
-    shared.ensureProjectStateFiles(projectEntry);
+    shared.initializeProjectState(projectEntry);
     config.projects.push(projectEntry);
     console.log(`  + ${name} (${repo.path})`);
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.2379",
+  "version": "0.1.2381",
   "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"

package/playbooks/plan-to-prd.md

@@ -135,7 +135,7 @@ Rules for items:
       { "id": "P-bbb2", "name": "UI client",    "project": "web-dashboard",   ... }
     ]
     ```
-    The engine routes each item to that project's `work-items.json`. The verify task at plan completion picks the project with the most completed items and runs cross-repo verification from there. See the **Cross-repo plans** section below for the full output contract when `{{target_projects}}` is set.
+    The engine routes each item to that project's SQL work-item scope. The verify task at plan completion picks the project with the most completed items and runs cross-repo verification from there. See the **Cross-repo plans** section below for the full output contract when `{{target_projects}}` is set.
 - `depends_on` lists IDs of items that must be done first
 - Keep descriptions actionable — name the files, functions, patterns, or integration points the implementing agent should touch whenever the plan makes them clear
 - Include `acceptance_criteria` so reviewers know when it's done
@@ -149,7 +149,7 @@ This dispatch is rendering against a **cross-repo plan** — the engine extracte
 Apply these rules on top of (and where they conflict, instead of) the single-project guidance above:
 
 1. **Omit the top-level `"project"` field** on the PRD JSON — or set it to `""`. The PRD is not anchored to a single project. The dashboard reads `i.projects[]` per item (P-e8d49105) to render the cross-repo rollup; the top-level `project` only makes sense when the whole plan lives in one repo.
-2. **Every `missing_features` item MUST have an explicit `project`** chosen from `{{target_projects}}`. Do NOT leave `project` unset, do NOT fall back to `{{project_name}}` (it is unset for cross-repo dispatches), and do NOT invent a project not in the list — the engine routes each item to that project's `work-items.json` and an item with an unrecognized project will not materialize. Example:
+2. **Every `missing_features` item MUST have an explicit `project`** chosen from `{{target_projects}}`. Do NOT leave `project` unset, do NOT fall back to `{{project_name}}` (it is unset for cross-repo dispatches), and do NOT invent a project not in the list — the engine routes each item to that project's SQL scope and an item with an unrecognized project will not materialize. Example:
    ```json
    "missing_features": [
      { "id": "P-aaa1", "name": "API endpoint", "project": "<first project from {{target_projects}}>", ... },

package/playbooks/shared-rules.md

@@ -257,7 +257,7 @@ single API call that creates a thread pre-resolved. So on GitHub:
 When asked to check build status, CI results, or review state for a PR:
 
 **Preferred — read cached state (refreshed every `prPollStatusEvery` ticks, default ~12 min when engine is running):**
-Find the PR in `projects/<project-name>/pull-requests.json` by `prNumber`. Key fields:
+Read `GET http://localhost:{{dashboard_port}}/api/pull-requests` and find the project-scoped record by `prNumber`. Key fields:
 - `buildStatus` — `passing` | `failing` | `running` | `none`
 - `buildFailReason` — failing check/pipeline name when `buildStatus` is `failing`; inspect live CI logs yourself for details
 - `reviewStatus` — `approved` | `changes-requested` | `waiting` | `pending`
@@ -324,7 +324,7 @@ Only GitHub/Copilot authentication guidance applies to GitHub repository work.
 When asked to check build status, CI results, or review state for a PR:
 
 **Preferred — read cached state (refreshed every `prPollStatusEvery` ticks, default ~12 min when engine is running):**
-Find the PR in `projects/<project-name>/pull-requests.json` by `prNumber`. Key fields:
+Read `GET http://localhost:{{dashboard_port}}/api/pull-requests` and find the project-scoped record by `prNumber`. Key fields:
 - `buildStatus` — `passing` | `failing` | `running` | `none`
 - `buildFailReason` — failing check/pipeline name when `buildStatus` is `failing`; inspect live CI logs yourself for details
 - `reviewStatus` — `approved` | `changes-requested` | `waiting` | `pending`
@@ -333,7 +333,7 @@ Find the PR in `projects/<project-name>/pull-requests.json` by `prNumber`. Key f
 
 **Live status (when engine isn't running or you need up-to-the-moment results):**
 ```bash
-node engine/ado-status.js <prNumber>              # reads cached pull-requests.json
+node engine/ado-status.js <prNumber>              # reads the cached SQL PR store
 node engine/ado-status.js <prNumber> --live       # fresh ADO API call
 node engine/ado-status.js <prNumber> --live --project MyProject
 ```

package/playbooks/templates/followup-dispatch.md

@@ -137,7 +137,7 @@ auditable record of what you fanned out to:
 ```
 
 The engine logs each entry at `info` and warns if the array references a WI id
-that doesn't exist in any project's `work-items.json` (mismatch between what
+that doesn't exist in any project's SQL scope (mismatch between what
 you claim and what the API actually created — usually a sign that the dispatch
 was reverted or the response was misread).
 

package/playbooks/verify.md

@@ -53,7 +53,7 @@ Use the template at `{{team_root}}/playbooks/templates/verify-guide.md` and clea
 
 For each project with aggregate verification changes, create or update one draft/review PR that combines the plan branches into a single reviewable diff. Reuse an existing `e2e/{{plan_slug}}` branch/PR when present. Include the plan summary, merged PRs, testing guide, and build/test status. Do not auto-complete or merge these PRs.
 
-Track each E2E PR in the project's `.minions/pull-requests.json` if it is not already tracked.
+Include each E2E PR in the structured completion report so the engine enrolls it in the project PR store. If manual enrollment is needed, use `POST /api/pull-requests/link`; never edit runtime state directly.
 
 ## Cross-PR Compatibility Audit
 

package/prompts/cc-system.md

@@ -32,12 +32,12 @@ A literal `</UNTRUSTED-INPUT>` substring is impossible inside a fence — the fe
 
 ## Guardrails
 {{cc_protected_paths}}
-CAN modify: notes, plans, knowledge, work items, pull-requests.json, routing.md, charters, skills, playbooks, project repos.
+CAN modify: notes, plans, knowledge, work items and PR records through dashboard APIs, routing.md, charters, skills, playbooks, project repos.
 
 **Never use the `AskUserQuestion` tool.** This conversation runs headless — the dashboard has no UI to surface the question and no way to feed an answer back, so every invocation hangs the turn. If you need clarification, ask in plain text in your reply; the user can answer in the next message.
 
 ## Filesystem
-Minions state lives in `{{minions_dir}}/`. Key paths: `config.json` (config), `routing.md` (dispatch rules), `projects/{name}/work-items.json` & `pull-requests.json` (per-project), `agents/{id}/` (charters, output), `plans/` & `prd/` (plans), `knowledge/` (KB), `notes/inbox/` (inbox), `engine/dispatch.json` (queue), `playbooks/` (templates). Use tools to read specifics.
+Minions runtime state lives in `{{minions_dir}}/engine/state.db` and is accessed through dashboard APIs. Key file-backed paths: `config.json` (config), `routing.md` (dispatch rules), `agents/{id}/` (charters/output), `plans/` (plan Markdown), `knowledge/` (KB), `notes/inbox/` (inbox), and `playbooks/` (templates). Use `GET /api/routes` to discover state APIs.
 
 ## Your skills
 
@@ -92,7 +92,7 @@ When genuinely in doubt about the size, delegate — agents have isolated worktr
 ### HARD STOP — never edit files yourself in a live/hybrid project
 This overrides everything above, **including the direct-handling override**. For any project whose effective checkout mode is `live` (or `hybrid` for a code-authoring work-item type — `implement`/`fix`/`docs`/`decompose`), you MUST NOT use `Edit`/`Write`/`Bash` (or any tool) to mutate files inside that project's `localPath`, **regardless of task size** — not even a Small 1-line change, and not even when the human explicitly says to do it yourself. The Step-3 "do it yourself" allowance and the Step-1 direct-handling override do **not** apply to writes inside a live/hybrid checkout.
 
-Why: live-mode projects have no worktree isolation — the engine runs agents in-place inside `localPath`, caps dispatch to one mutating operation at a time, and refuses to dispatch on a dirty tree (`live-checkout-dirty`, non-retryable). A stray CC edit leaves the checkout dirty in a way the dispatch bookkeeping does not track, and that dirty state then **blocks every subsequent live-mode dispatch** on the project until a human manually cleans it up. It is NOT covered by the engine's dispatch-time auto-stash/auto-reset recovery — those only run as part of an actual dispatch preflight, never for stray CC edits.
+Why: live-mode projects have no worktree isolation — the engine runs agents in-place inside `localPath` and caps dispatch to one mutating operation at a time. A stray CC edit is outside dispatch ownership: with dirty recovery disabled it causes a `live-checkout-dirty` refusal that blocks live work, while the default auto-stash policy can silently park that edit before the next dispatch, so the requested change is no longer present for the agent to validate or commit. Auto-stash/reset is a dispatch recovery mechanism, not ownership bookkeeping for CC edits.
 
 Instead, when a change is needed in a live/hybrid project, **dispatch a normal work item** (`POST /api/work-items`, `type: "implement"` or `"fix"` as usual) and let the engine own the live-checkout dispatch path (dirty-tree refusal, single-mutating-dispatch cap, auto-stash/auto-reset). Do not try to shortcut it with your own edit.
 
@@ -333,23 +333,23 @@ The `X-CC-Turn-Id` header is the audit trail — the handler stamps it onto the
 Every configured project has an effective **checkout mode** — surfaced in your state snapshot next to the project as `[worktree]`, `[live]`, or `[hybrid (live-validation: <type>)]`. It controls where dispatched agents run:
 
 - **`worktree`** (default) — each dispatch gets its own isolated `git worktree`. Agents run fully in parallel; nothing touches the operator's working tree. Use for normal repos.
-- **`live`** — agents run **in-place** inside the project's `localPath` (no worktree). The engine caps this to **one mutating dispatch at a time** per project and **refuses on a dirty tree**. Use only when worktrees are unworkable (e.g. Android `repo`, submodules, deep Windows paths, emulators that bind the real checkout).
-- **`hybrid`** — `live` **plus** a `liveValidation: { type, autoDispatch }` block. Coding work items (`implement`/`fix`/`docs`/`decompose`) author in **isolated worktrees** (full parallelism), while **only** work items whose type matches `liveValidation.type` (e.g. `build-and-test`) run **in-place on the live checkout**. This is the best of both: parallel code authoring + a real on-disk build/validation that can't run in a worktree. `type` accepts a single string (e.g. `"build-and-test"`) or an array of strings (e.g. `["implement","fix"]`) to route multiple work-item types to the live checkout at once.
+- **`live`** — agents run **in-place** inside the project's `localPath` (no worktree). The engine caps this to **one mutating dispatch at a time** per project. Dirty-tree behavior follows the configured auto-stash/reset policy (auto-stash defaults on); with recovery disabled, the item remains pending until the tree is clean. Use only when worktrees are unworkable.
+- **`hybrid`** — `live` **plus** a `liveValidation: { type, autoDispatch }` block. Work items not listed in `type` use isolated worktrees; listed live-capable canonical work-item types run in-place. The normal validation type is `test`. `build-and-test` is a playbook name, not a work-item type. `type` accepts one string or an array. When `autoDispatch:true`, `test` must be included; the engine creates one PR-targeted `test` WI with the `build-and-test` playbook after each eligible coding WI completes.
 
-**CC never writes into a live/hybrid checkout itself.** Because `live` (and the code-authoring surface of `hybrid`) runs in-place with no worktree isolation, a one-off CC edit inside such a project's `localPath` leaves the tree dirty and blocks every future live-mode dispatch (the engine refuses on a dirty tree, `live-checkout-dirty`, non-retryable — and it does not track or auto-recover stray CC edits). So for any needed change in a `live`/`hybrid` project you **dispatch a work item** and let the engine own the live-checkout path; you never `Edit`/`Write`/`Bash`-mutate files there yourself, regardless of task size or a direct-handling override. Read-only inspection remains fine. This is the same rule stated up top under "HARD STOP — never edit files yourself in a live/hybrid project"; the two sections agree by design.
+**CC never writes into a live/hybrid checkout itself.** A one-off CC edit leaves untracked operator dirt that the next dispatch may unexpectedly stash or may block on when recovery is disabled. For any needed change, **dispatch a work item** and let the engine own the live-checkout path; never `Edit`/`Write`/`Bash`-mutate files there yourself. Read-only inspection remains fine.
 
 **When to recommend hybrid:** the project's build/test/validation genuinely cannot run in an isolated worktree (it needs the real checkout — submodules, a `repo`-managed tree, an emulator/dev-server bound to `localPath`, deep-path tooling), **but** you still want coding agents to work in parallel rather than serialize through the single live checkout. If the *whole* workflow must run on the real tree, use plain `live`. If nothing needs the real tree, stay on `worktree`.
 
 **Configuring it** (via the projects array on `POST /api/settings` — never hand-edit `config.json`):
 ```bash
-# Switch a project to hybrid mode (live checkout + deferred build-and-test validation)
+# Switch a project to hybrid mode (live checkout + deferred test validation)
 curl -s -X POST http://localhost:{{dashboard_port}}/api/settings \
   -H 'Content-Type: application/json' -H 'X-CC-Turn-Id: {{cc_turn_id}}' \
-  -d '{"projects":[{"name":"<project>","checkoutMode":"live","liveValidation":{"type":"build-and-test","autoDispatch":true}}]}'
+  -d '{"projects":[{"name":"<project>","checkoutMode":"live","liveValidation":{"type":"test","autoDispatch":true}}]}'
 # Clear hybrid (back to plain live): pass "liveValidation": null
 # Clear live entirely (back to worktree): pass "checkoutMode": "worktree" (also clear liveValidation)
 ```
-The server validates: `liveValidation` requires `checkoutMode:"live"` (400 otherwise) and a non-empty `type`. With `autoDispatch:true`, the engine auto-creates a `<type>` validation WI on the live checkout after each coding WI completes with a PR. **Always confirm the mode switch with the user before applying it** — it changes how every future dispatch on that project runs.
+The server validates: `liveValidation` requires `checkoutMode:"live"`, canonical live-capable work-item type(s), and a boolean `autoDispatch`; automatic validation additionally requires `test` in `type`. **Always confirm the mode switch with the user before applying it** — it changes how future dispatches run.
 
 ## GitHub auth