@yemi33/minions 0.1.2414 → 0.1.2416

package/dashboard/js/refresh.js

@@ -185,7 +185,7 @@ const RENDER_VERSIONS = {
   // Bumped to 4 by W-mqrdavob (Agents table: per-agent charter editor column).
   // Bumped to 5 by W-mr0qs0vw (Worker Pool: CC session idle-timeout field).
   // Bumped to 6 for the fleet ACP pool opt-in default and warning copy.
-  settings: 6,
+  settings: 7,
 };
 const _sectionCache = {};
 const _lastValueByKey = {};

package/dashboard/js/settings.js

@@ -713,6 +713,13 @@ async function openSettings() {
   // non-dispatch toggles that historically lived under Auto-fix; placed
   // adjacent to Auto-fix so operators following the legacy mental model find
   // the moved flags quickly.
+  // W-mryz3r7h — a section may opt into a collapsible rail fold by declaring a
+  // `group`. Grouped sections render as an indented child list beneath a fold
+  // header (see RAIL_GROUPS + the railHtml builder below); their PANES stay in
+  // the content area unchanged. Copilot/Claude Tuning + Budget + the former
+  // standalone Advanced pane now live under the "Advanced" fold (collapsed by
+  // default). The former standalone Advanced leaf is nested here too so there is
+  // only ever one thing labeled "Advanced".
   const sections = [
     { id: 'runtime', label: 'Agents Runtime & Models', featured: true, html: paneRuntime },
     { id: 'autofix', label: 'Auto-fix & Review Loop', featured: true, html: paneAutoFix },
@@ -723,15 +730,19 @@ async function openSettings() {
     { id: 'polling', label: 'Polling', html: panePolling },
     { id: 'concurrency', label: 'Concurrency & Timeouts', html: paneConcurrency },
     { id: 'worktree', label: 'Worker Pool & Worktrees', html: paneWorktree },
-    { id: 'copilot', label: 'Copilot Tuning', html: paneCopilot },
-    { id: 'claude', label: 'Claude Tuning', html: paneClaude },
     { id: 'harness', label: 'Runtime Harness', html: paneHarness },
-    { id: 'budget', label: 'Budget', html: paneBudget },
     { id: 'maxturns', label: 'Max Turns', html: paneMaxTurns },
     { id: 'features', label: 'Feature Flags', html: paneFeatures },
-    { id: 'advanced', label: 'Advanced', html: paneAdvanced },
+    { id: 'copilot', label: 'Copilot Tuning', html: paneCopilot, group: 'advanced' },
+    { id: 'claude', label: 'Claude Tuning', html: paneClaude, group: 'advanced' },
+    { id: 'budget', label: 'Budget', html: paneBudget, group: 'advanced' },
+    { id: 'advanced', label: 'Advanced', html: paneAdvanced, group: 'advanced' },
   ];
 
+  // Rail fold registry: group id → display label. Sections opt in via `group`.
+  const RAIL_GROUPS = { advanced: { label: 'Advanced' } };
+  const ADV_FOLD_KEY = 'minions.settings.advancedFoldOpen';
+
   // localStorage-persisted active tab. Falls back to the first section when no
   // saved value or the saved value points at a section we no longer render.
   const SAVED_TAB_KEY = 'minions.settings.activeTab';
@@ -741,12 +752,41 @@ async function openSettings() {
     if (saved && sections.some(s => s.id === saved)) activeTab = saved;
   } catch { /* localStorage may be blocked in some embeds */ }
 
-  const railHtml = sections.map(s =>
-    '<button class="settings-rail-btn' + (s.featured ? ' featured' : '') + (s.id === activeTab ? ' active' : '') + '" data-settings-tab="' + s.id + '" type="button">' +
+  // Compute the Advanced fold's initial expanded state. Default (no saved
+  // value) is COLLAPSED. Persisted choice survives reloads. If the restored
+  // active tab lives inside the fold, force it open so the active rail button
+  // is visible on load.
+  let advancedFoldOpen = false;
+  try { advancedFoldOpen = localStorage.getItem(ADV_FOLD_KEY) === '1'; } catch { /* localStorage may be blocked in some embeds */ }
+  if (sections.some(s => s.id === activeTab && s.group === 'advanced')) advancedFoldOpen = true;
+  const foldStates = { advanced: advancedFoldOpen };
+
+  const railBtnHtml = (s, child) =>
+    '<button class="settings-rail-btn' + (s.featured ? ' featured' : '') + (child ? ' settings-rail-btn--child' : '') + (s.id === activeTab ? ' active' : '') + '" data-settings-tab="' + s.id + '" type="button">' +
       '<span class="rail-label">' + escHtml(s.label) + '</span>' +
       '<span class="match-count" style="display:none">0</span>' +
-    '</button>'
-  ).join('');
+    '</button>';
+
+  // Walk the sections in order. Leaves render directly; the first grouped
+  // section emits the whole fold (header + indented child list), and later
+  // members of the same group are skipped (they were rendered with the header).
+  const renderedGroups = new Set();
+  const railHtml = sections.map(function(s) {
+    if (!s.group) return railBtnHtml(s, false);
+    if (renderedGroups.has(s.group)) return '';
+    renderedGroups.add(s.group);
+    const members = sections.filter(x => x.group === s.group);
+    const open = !!foldStates[s.group];
+    const label = (RAIL_GROUPS[s.group] && RAIL_GROUPS[s.group].label) || s.group;
+    return '<button class="settings-rail-fold' + (open ? ' open' : '') + '" data-settings-fold="' + s.group + '" type="button" aria-expanded="' + (open ? 'true' : 'false') + '">' +
+        '<span class="fold-chevron" aria-hidden="true"></span>' +
+        '<span class="rail-label">' + escHtml(label) + '</span>' +
+        '<span class="match-count" style="display:none">0</span>' +
+      '</button>' +
+      '<div class="settings-rail-group' + (open ? ' open' : '') + '" data-settings-group="' + s.group + '" role="group" aria-label="' + escHtml(label) + '">' +
+        members.map(m => railBtnHtml(m, true)).join('') +
+      '</div>';
+  }).join('');
 
   const panesHtml = sections.map(s =>
     '<div class="settings-pane' + (s.id === activeTab ? ' active' : '') + '" data-settings-pane="' + s.id + '">' +
@@ -806,6 +846,20 @@ async function openSettings() {
     });
   });
 
+  // ── Wire up fold headers (expand/collapse the Advanced group) ───────────
+  // <button> headers are keyboard-operable natively (Enter/Space fire click).
+  // The user's choice is persisted so it survives reloads; the render-time
+  // default is collapsed unless the active tab lives inside the fold.
+  body.querySelectorAll('[data-settings-fold]').forEach(function(btn) {
+    btn.addEventListener('click', function() {
+      const gid = btn.getAttribute('data-settings-fold');
+      const open = _toggleSettingsFold(gid);
+      if (gid === 'advanced') {
+        try { localStorage.setItem(ADV_FOLD_KEY, open ? '1' : '0'); } catch { /* ignore */ }
+      }
+    });
+  });
+
   // ── Cross-tab search box ───────────────────────────────────────────────
   // Filters every [data-search] row across every pane. Empty query restores
   // the active-tab view; non-empty query shows ALL panes with matches and
@@ -1257,6 +1311,32 @@ function _selectSettingsTab(id) {
   body.querySelectorAll('[data-settings-pane]').forEach(function(pane) {
     pane.classList.toggle('active', pane.getAttribute('data-settings-pane') === id);
   });
+  // If the selected tab lives inside a collapsed fold, expand the fold so its
+  // rail button is visible. The pane renders regardless of fold state.
+  const activeBtn = body.querySelector('[data-settings-tab="' + id + '"]');
+  const group = activeBtn && activeBtn.closest('[data-settings-group]');
+  if (group) {
+    group.classList.add('open');
+    const gid = group.getAttribute('data-settings-group');
+    const fold = body.querySelector('[data-settings-fold="' + gid + '"]');
+    if (fold) { fold.classList.add('open'); fold.setAttribute('aria-expanded', 'true'); }
+  }
+}
+
+// Expand/collapse a rail fold. Returns the resulting open state (or undefined
+// if the fold isn't mounted). `forceState` (boolean) sets an explicit state;
+// omitting it toggles. Keeps the header's aria-expanded + chevron in sync.
+function _toggleSettingsFold(groupId, forceState) {
+  const body = document.getElementById('modal-body');
+  if (!body) return undefined;
+  const fold = body.querySelector('[data-settings-fold="' + groupId + '"]');
+  const group = body.querySelector('[data-settings-group="' + groupId + '"]');
+  if (!fold || !group) return undefined;
+  const open = typeof forceState === 'boolean' ? forceState : !group.classList.contains('open');
+  group.classList.toggle('open', open);
+  fold.classList.toggle('open', open);
+  fold.setAttribute('aria-expanded', open ? 'true' : 'false');
+  return open;
 }
 
 function _applySettingsSearch(rawQuery) {
@@ -1281,6 +1361,25 @@ function _applySettingsSearch(rawQuery) {
       const badge = btn.querySelector('.match-count');
       if (badge) badge.style.display = 'none';
     });
+    // Restore each fold's resting state: persisted collapsed default, but kept
+    // open if an active child tab lives inside it (so the visible pane's rail
+    // button isn't hidden). Clears any search-driven fold badge/no-match.
+    body.querySelectorAll('[data-settings-fold]').forEach(function(fold) {
+      const gid = fold.getAttribute('data-settings-fold');
+      const group = body.querySelector('[data-settings-group="' + gid + '"]');
+      if (!group) return;
+      fold.classList.remove('no-match');
+      const foldBadge = fold.querySelector('.match-count');
+      if (foldBadge) foldBadge.style.display = 'none';
+      let open = false;
+      if (gid === 'advanced') {
+        try { open = localStorage.getItem('minions.settings.advancedFoldOpen') === '1'; } catch { /* ignore */ }
+      }
+      if (group.querySelector('[data-settings-tab].active')) open = true;
+      group.classList.toggle('open', open);
+      fold.classList.toggle('open', open);
+      fold.setAttribute('aria-expanded', open ? 'true' : 'false');
+    });
     return;
   }
 
@@ -1311,6 +1410,32 @@ function _applySettingsSearch(rawQuery) {
       }
     }
   });
+
+  // Fold handling during search: expand any fold that has a matching child so
+  // results aren't hidden behind a collapsed header, aggregate the child match
+  // counts onto the fold header badge, and dim folds with zero matches. Runs
+  // AFTER the per-pane loop so child rail badges are already computed.
+  body.querySelectorAll('[data-settings-fold]').forEach(function(fold) {
+    const gid = fold.getAttribute('data-settings-fold');
+    const group = body.querySelector('[data-settings-group="' + gid + '"]');
+    if (!group) return;
+    let total = 0;
+    let anyMatch = false;
+    group.querySelectorAll('[data-settings-tab]').forEach(function(cb) {
+      if (!cb.classList.contains('no-match')) anyMatch = true;
+      const badge = cb.querySelector('.match-count');
+      if (badge && badge.style.display !== 'none') total += Number(badge.textContent) || 0;
+    });
+    group.classList.toggle('open', anyMatch);
+    fold.classList.toggle('open', anyMatch);
+    fold.setAttribute('aria-expanded', anyMatch ? 'true' : 'false');
+    fold.classList.toggle('no-match', !anyMatch);
+    const foldBadge = fold.querySelector('.match-count');
+    if (foldBadge) {
+      foldBadge.textContent = String(total);
+      foldBadge.style.display = total > 0 ? 'inline-block' : 'none';
+    }
+  });
 }
 
 async function saveSettings() {
@@ -1682,7 +1807,7 @@ async function removeProject(name) {
   }
 }
 
-window.MinionsSettings = { openSettings, saveSettings, addProject, removeProject, resetSettingsToDefaults, _selectSettingsTab, _applySettingsSearch };
+window.MinionsSettings = { openSettings, saveSettings, addProject, removeProject, resetSettingsToDefaults, _selectSettingsTab, _applySettingsSearch, _toggleSettingsFold };
 
 // ── Settings embed mode (Slim UX parity — W-mrkpke07000i8ed5) ───────────
 // The Slim UX Settings modal embeds this LITERAL classic Settings surface in

package/dashboard/styles.css

@@ -1308,6 +1308,19 @@
   .settings-rail-btn.active { color: var(--blue); border-left-color: var(--blue); background: var(--surface); font-weight: 600; }
   .settings-rail-btn.no-match { opacity: 0.3; }
   .settings-rail-btn .match-count { font-size: var(--text-xs); color: var(--blue); background: var(--bg); border-radius: var(--radius-xl); padding: 1px 6px; min-width: 18px; text-align: center; }
+  /* W-mryz3r7h — collapsible rail fold ("Advanced"). The fold header is a real
+     <button> (keyboard-operable); child rail buttons live in a container that
+     is hidden unless the fold is .open. Children are indented under the header. */
+  .settings-rail-fold { display: flex; align-items: center; gap: var(--space-2); width: 100%; padding: var(--space-3) var(--space-6); background: transparent; border: none; border-left: 3px solid transparent; color: var(--muted); font-size: var(--text-md); font-weight: 400; font-family: inherit; cursor: pointer; text-align: left; transition: all var(--transition-fast); }
+  .settings-rail-fold:hover { color: var(--text); background: var(--surface); }
+  .settings-rail-fold.no-match { opacity: 0.3; }
+  .settings-rail-fold .rail-label { flex: 1; }
+  .settings-rail-fold .match-count { font-size: var(--text-xs); color: var(--blue); background: var(--bg); border-radius: var(--radius-xl); padding: 1px 6px; min-width: 18px; text-align: center; }
+  .settings-rail-fold .fold-chevron::before { content: '\25B8'; display: inline-block; font-size: var(--text-xs); color: var(--muted); transition: transform var(--transition-fast); }
+  .settings-rail-fold.open .fold-chevron::before { transform: rotate(90deg); }
+  .settings-rail-group { display: none; }
+  .settings-rail-group.open { display: block; }
+  .settings-rail-btn--child { padding-left: var(--space-9); }
   .settings-content { flex: 1; overflow-y: auto; padding: var(--space-7) var(--space-8); min-width: 0; }
   .settings-pane { display: none; }
   .settings-pane.active { display: block; }

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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.2414",
+  "version": "0.1.2416",
   "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`.