@yemi33/minions 0.1.2415 → 0.1.2417

package/docs/README.md

@@ -44,6 +44,7 @@ Architecture, design proposals, and lifecycle references for people working on t
 - [deprecated-process.md](deprecated-process.md) — Schema for `docs/deprecated.json` and the weekly `cleanup-deprecated` audit walk that retires entries past their removal signal.
 - [design-inbox-entries-schema.md](design-inbox-entries-schema.md) — Implemented SQL schema and store contract for the future operator/agent inbox queue, including current indexes, mutators, event emission, and integration status.
 - [design-state-storage.md](design-state-storage.md) — Design proposal evaluating five database options for replacing Minions' file-based JSON state; recommends `node:sqlite` (accepted; implementation tracked in CHANGELOG.md Phases 0–10).
+- [dev-composite-workflow.md](dev-composite-workflow.md) — The recurring "rebuild the composite branch from all my open PRs and relaunch the dev dashboard" workflow, and the `rebuild-composite` skill + `scripts/rebuild-composite.ps1` that automate it.
 - [harness-mode.md](harness-mode.md) — Tri-Agent Harness Mode (`harness_mode: "tri_agent"` on scheduled tasks): Planner → Generator → Evaluator loop that iterates a shared on-disk artifact until a rubric passes or the iteration cap fires.
 - [harness-propagation.md](harness-propagation.md) — The native runtime
   contract for repository instructions, skills, commands, and MCPs.

package/docs/command-center.md

@@ -77,6 +77,12 @@ Because that bypass can spend tens of seconds starting a one-off process before
 
 **No new `engine.*` flag.** The limits above are module-level constants in `dashboard.js` (`CC_IMAGE_MAX_COUNT`, `CC_IMAGE_MAX_DECODED_BYTES`, `CC_IMAGE_MIME_ALLOWLIST`), not config keys; `engine/shared.js` `ENGINE_DEFAULTS` was not touched. Per CLAUDE.md Best Practice #9 (Settings parity), no Settings toggle is added because no new `engine.*` flag was introduced. Runtime selection that determines whether images are accepted is the existing `engine.ccCli` / `ccModel` override, which already has a Settings control.
 
+## Operator-checkout write authority (interactive turns)
+
+Interactive Command Center turns MAY use `Edit`/`Write`/`Bash` to change files and run mutating git commands (e.g. a clean `git pull --ff-only origin main`, a requested `git checkout -- <file>`, a one-off file edit) inside a configured project's `localPath` — but **only** to carry out a change the human explicitly asked to make in that checkout, acting as the operator's hands. The authoritative rule text lives in `prompts/cc-system.md` → "Operator checkouts — write only on an explicit user request" and is regression-tested in `test/unit.test.js` ("cc-system prompt permits explicit-request CC edits to operator checkouts with guardrails").
+
+Guardrails preserved: no unsolicited writes (question/inspection-only asks stay read-only), requested scope only (never revert/stash/reset/overwrite the operator's unrelated uncommitted changes, no destructive commands like `git reset --hard` / `git clean -fd` unless explicitly named), and dispatch is still preferred for Medium/Large feature work that should land as a reviewed PR. This authority is **CC-only**: it does not change agent dispatch, which always runs in engine-owned isolated worktrees (`worktree` mode) or the guarded live-checkout path (`live`/`hybrid` mode). Worktree ownership, wipe guards, and live-checkout safety are unchanged.
+
 ## Create-PR flow — checkout-mode-aware (PR #387)
 
 The "Create PR" chip offered by CC after a local edit follows the **same checkout pattern** as a normal dispatch for the project (`shared.resolveCheckoutMode`).

package/docs/live-checkout-mode.md

@@ -229,7 +229,9 @@ The core invariant holds end-to-end through restore: **the engine only ever swit
 
 ## Create-PR chip safety (CC-initiated, separate from the dispatch path)
 
-Command Center never creates edits inside a configured project's `localPath`. The **"Create PR"** chip is only for pre-existing operator changes. In worktree mode, `prepareCreatePrWorktree` creates a fresh branch from `origin/<mainBranch>` (falling back to local main when no remote exists), applies only the uncommitted diff/untracked files, and leaves the source checkout unchanged. Topic commits from the operator's current branch cannot leak into the PR. Live-mode Create-PR remains a deliberate in-place flow and retains the base-branch protections below.
+The **"Create PR"** chip is only for pre-existing operator changes and never fabricates edits itself. In worktree mode, `prepareCreatePrWorktree` creates a fresh branch from `origin/<mainBranch>` (falling back to local main when no remote exists), applies only the uncommitted diff/untracked files, and leaves the source checkout unchanged. Topic commits from the operator's current branch cannot leak into the PR. Live-mode Create-PR remains a deliberate in-place flow and retains the base-branch protections below.
+
+(Note: interactive Command Center turns may make direct, explicitly-requested edits to `localPath` — including a requested clean `git pull --ff-only origin main` — as the operator's hands; see `prompts/cc-system.md` → "Operator checkouts — write only on an explicit user request". That interactive authority is separate from this Create-PR chip flow and does not change the dispatch-path or agent-worktree ownership contracts on this page.)
 
 **The bug it fixes (W-mr3jbpru).** The old live-mode chip message keyed its branch instruction off `git rev-parse --abbrev-ref HEAD` (the *current* branch) and only told the agent to branch off cleanly **if** that current branch already happened to be the project's main branch. If the checkout was on any other branch, the message told the agent to commit the new changes **directly onto that branch** — silently carrying all of that branch's unrelated commits into the new PR. There was no engine-side verification that the current branch was clean or at parity with main; it was trusted blindly. A user hit exactly this: a Create-PR chip PR ended up built on top of a leftover topic branch and carried unrelated diffs.
 

package/docs/worktree-lifecycle.md

@@ -15,8 +15,10 @@ Lifecycle keeps the cross-cutting invariants; the detail lives here.
 
 For `checkoutMode: "worktree"`, `project.localPath` is an operator-owned source
 checkout, not an execution directory. Project-bound read-only and mutating
-dispatches both run in engine-owned worktrees; Command Center delegates writes;
-Create-PR staging copies existing operator changes without resetting or deleting
+dispatches both run in engine-owned worktrees; interactive Command Center turns
+may write to `localPath` only on an explicit user request (never as a dispatch or
+background action — see `prompts/cc-system.md`); Create-PR staging copies existing
+operator changes without resetting or deleting
 the source; restart restore requires explicit live dispatch provenance plus
 current live configuration. Branchless project dispatches receive detached
 worktrees, and path containment resolves symlinks/junctions before accepting a

package/engine/runtimes/codex.js

@@ -551,6 +551,28 @@ function _extractText(obj) {
   return '';
 }
 
+// True turn-terminal detection (W-ms0mc2qf000ibd51). Codex streams both
+// per-item events (`item.started` / `item.completed`) and turn-level terminals
+// (`turn.completed` / `turn.failed` / `result` / `task_complete`). An assistant
+// PROGRESS message arrives mid-turn as
+//   { type: 'item.completed', item: { type: 'agent_message', text: '…' } }
+// which must stream as non-terminal progress. Only genuine turn/task/result
+// completion may fire the early-resolve terminal signal (ctx.setText →
+// onTerminalResult). The old `/complete|completed|final|result/` match treated
+// `item.completed` as terminal and finalized the CC turn before subsequent tool
+// calls (incident 2026-07-25 reason=done/tools=0/actions=0 after a progress
+// message, then a function_call several seconds later).
+function _isTurnTerminalType(type) {
+  const t = String(type || '');
+  if (!t) return false;
+  // item-scoped events (item.completed / item.started / item.updated …) are
+  // per-item progress, never a turn terminal.
+  if (/^item[._]/i.test(t)) return false;
+  return /(?:turn|task|response|session)[._]?(?:complete|completed|final|done)\b/i.test(t)
+    || /(?:^|[^a-z])result(?:[^a-z]|$)/i.test(t)
+    || /task_complete/i.test(t);
+}
+
 function _extractDelta(obj) {
   const type = _eventType(obj);
   if (!/delta|chunk/i.test(type)) return '';
@@ -886,7 +908,12 @@ function createStreamConsumer(ctx) {
     if (eventText) {
       terminalText = eventText;
       deltaText = '';
-      if (/complete|completed|final|result/i.test(type)) ctx.setText(eventText);
+      // Only genuine turn/task/result terminals fire the early-resolve terminal
+      // signal. item.completed agent_message events are streamed as non-terminal
+      // progress so subsequent tool calls in the same turn are not cut off
+      // (W-ms0mc2qf000ibd51). parseOutput() still owns final-answer extraction
+      // from the complete stdout at finalize() time.
+      if (_isTurnTerminalType(type)) ctx.setText(eventText);
       else ctx.pushText(eventText);
     }
   }
@@ -971,5 +998,6 @@ module.exports = {
   _readCatalogIds,
   _extractInvalidModelName,
   _extractToolUse,
+  _isTurnTerminalType,
   CAPS_SCHEMA_VERSION,
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.2415",
+  "version": "0.1.2417",
   "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/prompts/cc-system.md

@@ -89,17 +89,19 @@ If you start a small task and discover it's actually Medium (3+ files, more tool
 
 When genuinely in doubt about the size, delegate — agents have isolated worktrees, full tool access, durable work-item tracking, and no turn limits.
 
-### HARD STOP — never edit a configured project's operator checkout
-This overrides everything above, **including the direct-handling override**. For every configured project, you MUST NOT use `Edit`/`Write`/`Bash` (or any tool) to mutate files inside that project's `localPath`, **regardless of checkout mode or task size** — not even a Small 1-line change, and not even when the human explicitly says to do it yourself.
+### Operator checkouts — write only on an explicit user request
+A configured project's `localPath` is the **human operator's own working tree**. You MAY use `Edit`/`Write`/`Bash` to change files and run mutating git commands inside `localPath` — but only as the operator's hands, carrying out a change **they explicitly asked you to make in that checkout**. This includes ordinary requested git operations (e.g. a clean `git pull --ff-only origin main`, `git checkout -- <file>` on a file they named) and requested file edits.
 
-Why: in `worktree` mode, `localPath` is operator-owned and every project-bound dispatch (including read-only work) gets an isolated worktree. In `live`/`hybrid` mode, only the engine-owned dispatch path may deliberately operate there. A direct CC edit bypasses both ownership models.
+Guardrails (these still bind, regardless of checkout mode or task size):
+- **Explicit request only — never unsolicited.** If the human only asked a question, asked you to inspect, or asked you to dispatch, stay read-only. Do not edit or run mutating commands in `localPath` on your own initiative. This is the one place the direct-handling override does **not** apply: absent an explicit ask to change that checkout, treat it as read-only.
+- **Requested scope only — never their unrelated work.** Change exactly what was asked. Never revert, stash, reset, discard, or overwrite the operator's unrelated uncommitted changes, and never run destructive commands (`git reset --hard`, `git clean -fd`, `git checkout .`, branch/force-push/delete operations) unless the human explicitly named that exact destructive action.
+- **Prefer dispatch for real feature work.** For Medium/Large coding work — new features, multi-file refactors, anything that should land as a reviewed PR — still **dispatch a work item** (`POST /api/work-items`, `type: "implement"` or `"fix"`) so the engine runs it in an isolated worktree with the normal review/build loop. Direct `localPath` writes are for the small, explicit "do this here, now" asks: a quick fix, a requested `git pull`, a one-off edit.
+- **CC-only authority — dispatch isolation is unchanged.** This permission covers interactive Command Center turns only. It does **not** loosen how the engine dispatches agents: dispatched agents still run in engine-owned isolated worktrees (`worktree` mode) or the guarded live-checkout path (`live`/`hybrid` mode), and worktree ownership, wipe guards, and live-checkout safety are untouched. Do not hand-edit `localPath` to work around a dirty-tree or busy-dispatch gate — dispatch instead.
 
-Instead, **dispatch a normal work item** (`POST /api/work-items`, `type: "implement"` or `"fix"` as usual). The engine will choose an isolated worktree or the guarded live path from project configuration. Do not shortcut that path.
-
-Read-only inspection is still fine: viewing files and `git status`/`git log`/`git diff` are allowed. Do not run builds/tests in `localPath` when they may generate files; dispatch them instead.
+Read-only inspection never needs a request: viewing files and `git status`/`git log`/`git diff` are always fine.
 
 ### Create a PR from pre-existing operator changes
-Use this only when the human asks to open a PR from changes that already exist in a configured worktree-mode project's operator checkout. CC must not create those changes itself.
+Use this when the human asks to open a PR from changes that **already exist** in a configured worktree-mode project's operator checkout — so the PR is built from a clean copy and the operator's original tree is left untouched.
 
 First call:
 ```
@@ -355,7 +357,7 @@ Every configured project has an effective **checkout mode** — surfaced in your
 - **`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 any configured project's `localPath`.** Dispatch a work item and let the engine own either the isolated-worktree or guarded-live path. Read-only inspection remains fine.
+**CC may write into a configured project's `localPath` only on an explicit user request** (see "Operator checkouts — write only on an explicit user request"). Dispatched agents never do — the engine owns their isolated-worktree or guarded-live path. 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`.