@yemi33/minions 0.1.2176 → 0.1.2178

package/package.json

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

@@ -121,19 +121,42 @@ Rules for items:
 - **`status` is `"missing"` for new items** — do not set `done`, `complete`, `implemented`, or any other value based on codebase observations. The only exception is when reusing an existing PRD (see below) — items already `"done"` in the existing PRD carry forward as `"done"`. Pre-setting any other status on new items causes them to be silently skipped by the engine.
 - **Do NOT include a "verify" or "test" or "integration test" item** — the engine automatically creates a verify task when all PRD items are done. Adding one manually creates a duplicate that blocks plan completion.
 - **`project` field is required** — set it to the project name where the code changes go (e.g., `"OfficeAgent"`, `"office-bohemia"`). If the plan declares a single project, every item should use `{{project_name}}`; contextual mentions of another repo/product should not override it. Cross-repo plans should route each item to the correct project. The engine materializes items into that project's work queue.
-  - **Cross-repo plans:** when the plan body does NOT declare `**Project:**` (or declares it empty), `{{project_name}}` is unset. In that case, set each item's `project` to the actual repo where its code changes belong, and omit the top-level `"project"` field (or set it to `""`). Example:
+  - **Cross-repo plans:** the canonical signal that this is a cross-repo plan-to-prd dispatch is `{{target_projects}}` being non-empty — the engine extracts it from the plan markdown's `**Projects:** …` header (or `<!-- minions:targetProjects=… -->` marker) and injects the comma-separated list. When set, `{{project_name}}` is unset (no single owning repo). Set each item's `project` to the actual repo from `{{target_projects}}` where its code changes belong, and omit the top-level `"project"` field (or set it to `""`). Example:
     ```json
     "missing_features": [
       { "id": "P-aaa1", "name": "API endpoint", "project": "backend-service", ... },
       { "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.
+    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.
 - `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
 - Aim for 5-25 items depending on plan scope. If more than 25, group related work
 
+{{#target_projects}}
+## Cross-repo plans
+
+This dispatch is rendering against a **cross-repo plan** — the engine extracted the list `{{target_projects}}` from the plan's `**Projects:**` header (P-c1f87a92) and injected it here. There is no single owning project for the PRD as a whole; every item ships into one of the listed repos.
+
+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:
+   ```json
+   "missing_features": [
+     { "id": "P-aaa1", "name": "API endpoint", "project": "<first project from {{target_projects}}>", ... },
+     { "id": "P-bbb2", "name": "UI client",    "project": "<second project from {{target_projects}}>", ... }
+   ]
+   ```
+3. **Default `branch_strategy` to `"parallel"`** for cross-repo plans. Reason: a `shared-branch` plan presumes a single git history that all items push to, which is impossible across separate repos — at best it means "shared *branch name*, independent branches per repo", which is a coordination convention, not a literal shared history, and only makes sense when the human plan author explicitly asked for that coordination (e.g. to keep matching `user/<login>/PL-<slug>` branches across repos for a single launch). If the plan explicitly justifies `shared-branch` for cross-repo coordination, you may use it; otherwise prefer `parallel` so each item gets its own per-repo branch and PR.
+4. **`feature_branch` follows the strategy:**
+   - `parallel`: omit `feature_branch` entirely (the engine derives per-item branches as `user/<loginname>/<wi-id>-<slug>` in each project).
+   - `shared-branch` (only with explicit justification): use the canonical `user/<loginname>/PL-<short-kebab-slug>` form. The engine will pre-create a matching branch in every project listed in `{{target_projects}}` (P-1c0f5e84) so each item can push to the same branch name in its own repo.
+
+The verify task at plan completion picks the project with the most completed items and runs cross-repo verification from there; items with no PRs (e.g. docs-only changes that landed via direct commit) are still counted via their `done` status.
+
+{{/target_projects}}
 ## Reusing an Existing PRD
 
 When the engine detects an existing PRD for this plan (`source_plan` match), it passes the content below. If this section is empty or absent, skip to normal generation (all items `"missing"` with new UUIDs).

package/playbooks/plan.md

@@ -61,8 +61,10 @@ Use this format:
 ```markdown
 # Plan: {{plan_title}}
 
-**Project:** {{project_name}}
-**Author:** {{agent_name}}
+{{#target_projects}}**Projects:** {{target_projects}}
+<!-- minions:targetProjects={{target_projects}} -->
+{{/target_projects}}{{^target_projects}}**Project:** {{project_name}}
+{{/target_projects}}**Author:** {{agent_name}}
 **Date:** {{date}}
 
 ## Goal