@yemi33/minions 0.1.873 → 0.1.875

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,11 @@
1
1
  # Changelog
2
2
 
3
+ ## 0.1.875 (2026-04-11)
4
+
5
+ ### Fixes
6
+ - reset central work-items.json on agent kill (closes #890) (#891)
7
+ - include started_at in done/error agent status so duration renders
8
+
3
9
  ## 0.1.873 (2026-04-11)
4
10
 
5
11
  ### Features
package/dashboard.js CHANGED
@@ -1622,7 +1622,7 @@ const server = http.createServer(async (req, res) => {
1622
1622
  }, { defaultValue: { pending: [], active: [], completed: [] } });
1623
1623
 
1624
1624
  // 4. Reset work items from dispatched → pending so they can be retried
1625
- const allWiPaths = [];
1625
+ const allWiPaths = [path.join(MINIONS_DIR, 'work-items.json')];
1626
1626
  for (const proj of PROJECTS) allWiPaths.push(shared.projectWorkItemsPath(proj));
1627
1627
  let resetCount = 0;
1628
1628
  for (const wiPath of allWiPaths) {
package/engine/queries.js CHANGED
@@ -257,6 +257,7 @@ function getAgentStatus(agentId) {
257
257
  task: latest.task || '',
258
258
  dispatch_id: latest.id,
259
259
  type: latest.type || '',
260
+ started_at: latest.started_at || null,
260
261
  completed_at: latest.completed_at,
261
262
  resultSummary: latest.resultSummary || latest.reason || '',
262
263
  };
package/engine.js CHANGED
@@ -2592,15 +2592,29 @@ function discoverCentralWorkItems(config) {
2592
2592
  vars.plan_summary = (item.title || item.planFile).substring(0, 80);
2593
2593
  vars.plan_file = item.planFile || '';
2594
2594
  vars.project_name_lower = (firstProject?.name || 'project').toLowerCase();
2595
- // Generate unique PRD filenamecheck prd/ and prd/archive/ for collisions
2596
- const prdBase = vars.project_name_lower + '-' + dateStamp();
2597
- let prdFilename = prdBase + '.json';
2598
- const prdExisting = new Set([
2599
- ...safeReadDir(PRD_DIR).filter(f => f.endsWith('.json')),
2600
- ...safeReadDir(path.join(PRD_DIR, 'archive')).filter(f => f.endsWith('.json')),
2601
- ]);
2602
- let prdCounter = 2;
2603
- while (prdExisting.has(prdFilename)) { prdFilename = prdBase + '-' + prdCounter + '.json'; prdCounter++; }
2595
+ // Check if a PRD already exists for this plan reuse its filename to avoid duplicates (#884)
2596
+ let prdFilename = null;
2597
+ const prdFiles = safeReadDir(PRD_DIR).filter(f => f.endsWith('.json'));
2598
+ for (const pf of prdFiles) {
2599
+ const prd = safeJson(path.join(PRD_DIR, pf));
2600
+ if (prd?.source_plan === item.planFile) {
2601
+ prdFilename = pf;
2602
+ try { vars.existing_prd_json = fs.readFileSync(path.join(PRD_DIR, pf), 'utf8'); } catch (_) { /* ignore */ }
2603
+ log('info', `plan-to-prd: reusing existing PRD "${pf}" for plan "${item.planFile}" (#884)`);
2604
+ break;
2605
+ }
2606
+ }
2607
+ if (!prdFilename) {
2608
+ // Generate unique PRD filename — check prd/ and prd/archive/ for collisions
2609
+ const prdBase = vars.project_name_lower + '-' + dateStamp();
2610
+ prdFilename = prdBase + '.json';
2611
+ const prdExisting = new Set([
2612
+ ...prdFiles,
2613
+ ...safeReadDir(path.join(PRD_DIR, 'archive')).filter(f => f.endsWith('.json')),
2614
+ ]);
2615
+ let prdCounter = 2;
2616
+ while (prdExisting.has(prdFilename)) { prdFilename = prdBase + '-' + prdCounter + '.json'; prdCounter++; }
2617
+ }
2604
2618
  vars.prd_filename = prdFilename;
2605
2619
  mutations.set(item.id, Object.assign(mutations.get(item.id) || {}, { _prdFilename: prdFilename }));
2606
2620
  vars.branch_strategy_hint = item.branchStrategy
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@yemi33/minions",
3
- "version": "0.1.873",
3
+ "version": "0.1.875",
4
4
  "description": "Multi-agent AI dev team that runs from ~/.minions/ — five autonomous agents share a single engine, dashboard, and knowledge base",
5
5
  "bin": {
6
6
  "minions": "bin/minions.js"
@@ -14,12 +14,13 @@ A user has provided a plan. Analyze it against the codebase and produce a struct
14
14
  ## Instructions
15
15
 
16
16
  1. **Read the plan carefully** — understand the goals, scope, and requirements
17
- 2. **Explore the codebase** at `{{project_path}}`understand the existing structure to write accurate descriptions and acceptance criteria. Do NOT use observations about existing PRs or partial work to set item statuses — all items are always `"missing"` regardless of codebase state
18
- 3. **Break the plan into discrete, implementable items**each should be a single PR's worth of work
19
- 4. **Estimate complexity** `small` (< 1 file), `medium` (2-5 files), `large` (6+ files or cross-cutting)
20
- 5. **Order by dependency** — items that others depend on come first
21
- 6. **Use unique item IDs** — generate a short uuid for each item (e.g. `P-a3f9b2c1`). Do not use sequential `P001`/`P002` — IDs must be globally unique across all PRDs to avoid collisions
22
- 7. **Identify open questions** — flag anything ambiguous in the plan that needs user input
17
+ 2. **Check for an existing PRD**if the engine provides `existing_prd_json` below, a PRD already exists for this plan. See "Reusing an Existing PRD" section for how to preserve item IDs and done statuses. If no existing PRD is provided, this is a fresh run — all items start as `"missing"`.
18
+ 3. **Explore the codebase** at `{{project_path}}` understand the existing structure to write accurate descriptions and acceptance criteria. Do NOT use observations about existing PRs or partial work to set item statuses status is determined only by existing PRD items (step 2), not codebase state
19
+ 4. **Break the plan into discrete, implementable items** each should be a single PR's worth of work
20
+ 5. **Estimate complexity** — `small` (< 1 file), `medium` (2-5 files), `large` (6+ files or cross-cutting)
21
+ 6. **Order by dependency** — items that others depend on come first
22
+ 7. **Use unique item IDs** — generate a short uuid for each item (e.g. `P-a3f9b2c1`). Do not use sequential `P001`/`P002` — IDs must be globally unique across all PRDs to avoid collisions. **If reusing an existing PRD, keep all existing IDs — only generate new UUIDs for genuinely new items.**
23
+ 8. **Identify open questions** — flag anything ambiguous in the plan that needs user input
23
24
 
24
25
  ## Output
25
26
 
@@ -83,7 +84,7 @@ When using `parallel`:
83
84
 
84
85
  Rules for items:
85
86
  - IDs must be `P-<uuid>` format (e.g. `P-a3f9b2c1`) — globally unique, never sequential
86
- - **`status` is always `"missing"`** — do not set `done`, `complete`, `implemented`, or any other value, even if you observe active PRs or completed work in the codebase. Status is exclusively engine-managed after the PRD is written. Pre-setting any other status causes items to be silently skipped by the engine and breaks dependency resolution for all downstream items.
87
+ - **`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.
87
88
  - **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.
88
89
  - **`project` field is REQUIRED** — set it to the project name where the code changes go (e.g., `"OfficeAgent"`, `"office-bohemia"`). Cross-repo plans must route each item to the correct project. The engine materializes items into that project's work queue.
89
90
  - `depends_on` lists IDs of items that must be done first
@@ -91,19 +92,33 @@ Rules for items:
91
92
  - Include `acceptance_criteria` so reviewers know when it's done
92
93
  - Aim for 5-25 items depending on plan scope. If more than 25, group related work
93
94
 
94
- ## Updating an Existing PRD
95
+ ## Reusing an Existing PRD
95
96
 
96
- If the task description contains `mode: diff-aware-update`, you are updating an existing PRD, not creating one from scratch. The plan was revised and you need to produce an updated PRD that reflects the changes while preserving existing work.
97
+ 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).
97
98
 
98
- **Rules for diff-aware updates:**
99
- - **Read the existing PRD file first** — it's at `{{team_root}}/prd/{{prd_filename}}`
100
- - **Preserve item IDs** — do NOT generate new IDs for items that already exist. The engine maps work items by ID.
101
- - **Done + unchanged** → keep `"status": "done"` and the same ID (no work dispatched)
102
- - **Done + modified** (plan added requirements/scope) → set `"status": "updated"` with same ID (engine re-opens the work item and dispatches to existing branch)
103
- - **New items** in the updated plan → generate new `P-<uuid>` IDs, set `"status": "missing"`
104
- - **Removed items** (in old PRD but not in updated plan) drop from the PRD entirely (engine cancels pending work items)
105
- - **Pending/failed items** reset to `"missing"` with updated description
106
- - Preserve `branch_strategy`, `feature_branch`, `project`, and other plan-level fields from the existing PRD unless the plan explicitly changes them
99
+ <existing-prd>
100
+ {{existing_prd_json}}
101
+ </existing-prd>
102
+
103
+ **When an existing PRD is provided:**
104
+
105
+ 1. **Parse the existing PRD JSON** extract all `missing_features` items with their `id`, `status`, and metadata
106
+ 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.
107
+ 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"`
108
+ 4. **Carry forward in-progress items** — items with `"status": "missing"` or other non-done statuses keep their existing ID and reset to `"missing"`
109
+ 5. **New items only** — only generate new `P-<uuid>` IDs for items in the plan that have no match in the existing PRD
110
+ 6. **Removed items** — if an existing PRD item has no match in the current plan, drop it from the output
111
+ 7. **Preserve plan-level fields** — keep `branch_strategy`, `feature_branch`, and `project` from the existing PRD unless the plan explicitly changes them
112
+
113
+ This ensures re-running plan-to-prd on the same plan produces a clean update (new items added, completed items preserved, IDs stable) rather than a full reset with orphaned duplicates.
114
+
115
+ ## Updating an Existing PRD (Diff-Aware)
116
+
117
+ If the task description contains `mode: diff-aware-update`, you are updating an existing PRD because the plan was revised. Follow the same reuse rules above, plus these additional diff-aware rules:
118
+
119
+ **Additional diff-aware rules** (on top of the reuse rules above):
120
+ - **Done + modified** (plan added requirements/changed scope) → set `"status": "updated"` with same ID (engine re-opens the work item and dispatches to existing branch)
121
+ - **Pending/failed items** → reset to `"missing"` with updated description if the plan changed their scope
107
122
 
108
123
  ## Important
109
124