@yemi33/minions 0.1.1884 → 0.1.1886

package/playbooks/plan-to-prd.md

@@ -27,7 +27,7 @@ A user has provided a plan. Analyze it against the codebase and produce a struct
 
 Write the PRD to: `{{team_root}}/prd/{{prd_filename}}`
 
-**CRITICAL: Use the exact filename above.** The engine pre-generates a unique filename to avoid collisions with existing or archived PRDs. Do NOT change or rename it.
+**Use the exact filename above.** The engine pre-generates a unique filename to avoid collisions with existing or archived PRDs; renaming it will detach the PRD from the plan.
 
 This file is NOT checked into the repo. The engine reads it on every tick and dispatches implementation work automatically.
 
@@ -87,7 +87,7 @@ Rules for items:
 - IDs must be `P-<uuid>` format (e.g. `P-a3f9b2c1`) — globally unique, never sequential
 - **`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 must use `{{project_name}}`; contextual mentions of another repo/product must not override it. Cross-repo plans must route each item to the correct project. The engine materializes items into that project's work queue.
+- **`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:
     ```json
     "missing_features": [
@@ -112,7 +112,7 @@ When the engine detects an existing PRD for this plan (`source_plan` match), it
 **When an existing PRD is provided:**
 
 1. **Parse the existing PRD JSON** — extract all `missing_features` items with their `id`, `status`, and metadata
-2. **Preserve item IDs** — match existing items to current plan items by name/description similarity. Each plan item that corresponds to an existing PRD item MUST reuse that item's `P-<id>`. Do NOT generate new IDs for items that already exist.
+2. **Preserve item IDs** — match existing items to current plan items by name/description similarity. Each plan item that corresponds to an existing PRD item should reuse that item's `P-<id>`. Do not generate new IDs for items that already exist — duplicates orphan the prior work.
 3. **Preserve done items** — any existing item with `"status": "done"` carries forward as `"done"` with the same ID, description, and acceptance criteria. Do NOT reset done items to `"missing"`
 4. **Carry forward in-progress items** — items with `"status": "missing"` or other non-done statuses (except `"updated"`) keep their existing ID and reset to `"missing"`. Items with `"status": "updated"` keep their existing ID and remain `"updated"` — do NOT reset to `"missing"`
 5. **New items only** — only generate new `P-<uuid>` IDs for items in the plan that have no match in the existing PRD

package/playbooks/review.md

@@ -59,7 +59,7 @@ Use subagents only for genuinely parallel, independent tasks (e.g., reviewing un
 
 ## Post Review — Submit your verdict
 
-You MUST post a review comment with a clear verdict and write the completion report described in the shared rules. The verdict in the report is the primary machine-readable signal; the verdict line in the PR comment is for humans and backward compatibility.
+You MUST post a review comment with a clear verdict and write the completion report described in the shared rules (schema: `docs/completion-reports.md`). The verdict in the report is the primary machine-readable signal; the verdict line in the PR comment is for humans and backward compatibility.
 
 ### Post your review with verdict
 

package/playbooks/shared-rules.md

@@ -70,9 +70,7 @@ The engine provides a completion report path in the prompt and in `MINIONS_COMPL
 {"status":"success","summary":"what changed and how it was validated","verdict":null,"pr":"PR id/url or N/A","failure_class":"N/A","retryable":false,"needs_rerun":false,"artifacts":[{"type":"note|plan|prd|pr|file","path":"relative/path/or/url","title":"short label"}]}
 ```
 
-Use `status: "failed"` plus an accurate `failure_class`, `retryable`, and `needs_rerun` when the task could not be completed. For PR reviews, set `verdict` to `approved` or `changes-requested`. Include every durable artifact you created or updated in `artifacts` (PRs, notes, plans, PRDs, important files) so the dashboard can display them. Fenced `completion` blocks are still accepted as a fallback, but the JSON report is the primary signal.
-
-**No-op completions:** when you correctly decline to do the work — the change was already shipped on master, the dispatch premise is wrong, the flagged review comment is your own author-notes, etc. — write `status: "success"`, `pr: "N/A"`, AND add `"noop": true`. The engine treats `noop: true` as the canonical signal that no PR was expected, marks the work item done with the rationale surfaced in `_noopReason` for the dashboard, and skips the missing-PR-attachment failure. Without `noop: true`, an empty PR will still be flagged as a silent failure and auto-retried up to `maxRetries` times.
+For the canonical schema — every field, the `failure_class` enum, `noop:true` semantics, `retryable` / `needs_rerun` shape, and the artifacts array — see `docs/completion-reports.md`. The JSON report is the primary signal; fenced `completion` blocks in stdout are accepted only as a fallback.
 
 ## Long-Running Commands
 

package/playbooks/verify.md

@@ -63,4 +63,4 @@ Track each E2E PR in the project's `.minions/pull-requests.json` if it is not al
 
 Your task is complete once dependency branches are merged, build/test verification has run, the permanent guide is written, the inbox copy is written only if verification succeeded, and E2E PR URLs are included in your final response.
 
-Your final message MUST include each E2E PR URL and the testing guide path, for example: `E2E PR created: <url>` and `Testing guide: {{team_root}}/prd/guides/verify-{{plan_slug}}.md`.
+Include each E2E PR URL and the testing guide path in your final message, for example: `E2E PR created: <url>` and `Testing guide: {{team_root}}/prd/guides/verify-{{plan_slug}}.md`.

package/prompts/cc-system.md

@@ -113,12 +113,20 @@ curl -s -X POST http://localhost:{{dashboard_port}}/api/knowledge \
   -d '{"category":"architecture","title":"Doc-chat session lifecycle","content":"..."}'
 ```
 
-Build-and-test a PR:
+Build-and-test a PR (dispatched as a `test` work item — engine routes it to the `build-and-test` playbook):
+```
+curl -s -X POST http://localhost:{{dashboard_port}}/api/work-items \
+  -H 'Content-Type: application/json' \
+  -H 'X-CC-Turn-Id: {{cc_turn_id}}' \
+  -d '{"title":"Build-and-test PR #1234","type":"test","project":"MyApp","description":"Run build + tests against PR #1234.","references":[{"url":"https://github.com/owner/MyApp/pull/1234","label":"PR #1234"}]}'
+```
+
+Trigger a user-defined pipeline (only `id` is read from the body — there is no per-trigger context payload, so the pipeline runs exactly as configured):
 ```
 curl -s -X POST http://localhost:{{dashboard_port}}/api/pipelines/trigger \
   -H 'Content-Type: application/json' \
   -H 'X-CC-Turn-Id: {{cc_turn_id}}' \
-  -d '{"id":"build-and-test","context":{"pr":1234,"project":"MyApp"}}'
+  -d '{"id":"my-pipeline-id"}'
 ```
 
 Link an external PR for tracking: