@yemi33/minions 0.1.2379 → 0.1.2380

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.2380",
   "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