@mutmutco/kilo-plugin 3.106.0 → 3.107.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/kilo-plugin",
-  "version": "3.106.0",
+  "version": "3.107.1",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {
     "name": "MMI Future",

package/scripts/secret-redact.mjs

@@ -1,4 +1,4 @@
-// Scrooge v2 pillar 2 — Claude PostToolUse secret redaction (#1589). No throttling, no compaction; fail-soft always.
+// Claude PostToolUse secret redaction (#1589). No throttling, no compaction; fail-soft always.
 // Patterns are self-contained here (conservative, prefix-anchored secret shapes).
 
 import { appendHookActivity } from './hook-trace.mjs';
@@ -498,7 +498,7 @@ export async function runHookGate({ input: buffered } = {}) {
     // be tested against UPDATABLE_TOOLS, and it collapsed Codex `shell` and `local_shell` into "PowerShell".
     // #4012 fixed this call's `tool` FIELD and #4015 the stderr arms; the `action` TEXT below was converted
     // by neither, so one row read `{"tool":"shell","action":"secret detected in PowerShell output …"}` and
-    // disagreed with itself — in the log doctor, the Stop summary and scrooge.md's detection counts read.
+    // disagreed with itself — in the log doctor, the Stop summary and Archive/scrooge.md's detection counts read.
     const alarmTool = tracedTool(input) || decision?.toolName || 'tool';
     const action = !decision
       ? 'clean'

package/skills/bootstrap/SKILL.md

@@ -16,7 +16,7 @@ already be named on the taxonomy `<CATEGORY>-<PascalName>`.
 ## Seed sources + create-vs-upgrade
 
 The org-standard scaffolding is a **machine-readable manifest** — `skills/bootstrap/seeds/manifest.json`
-(loaded by the CLI; `mmi-cli bootstrap apply <repo> [--execute]` consumes it). Every seed carries an **ownership**:
+(loaded by the CLI; `mmi-cli devops bootstrap apply <repo> [--execute]` consumes it). Every seed carries an **ownership**:
 
 - **`org`** — org-delivered, **overwritten on upgrade** (the org owns it): the issue templates, the gate
   workflow, and the org-managed `.gitignore` block. `source: self` = copied verbatim from MMI-Hub's own
@@ -44,7 +44,7 @@ branch (#4241). Running `apply --execute` against every registry repo by hand to
 exactly the copy-per-repo pattern this rule exists to end — see Hub#4234.
 
 **Rollback is per-repo, never a second fleet overwrite (#4240).** When a propagated `org`-owned seed
-breaks a repo, the recovery is `mmi-cli bootstrap rollback <repo> --target <t> [--execute]` — it resolves
+breaks a repo, the recovery is `mmi-cli devops bootstrap rollback <repo> --target <t> [--execute]` — it resolves
 the ONE merge commit that repo's `bootstrap propagate` (#4238) run actually landed (live from the repo's
 `seed-propagate-<slug>` merged-PR history, or replayed from a persisted propagate `--json` report via
 `--record`) and opens an ordinary revert PR of it, through that repo's own gate, on a `seed-rollback-<slug>`
@@ -117,9 +117,9 @@ the confirmed values — no silent defaulting.
 
 Before mutating anything, run the verifier so the current gaps are concrete:
 ```bash
-mmi-cli bootstrap verify "$OWNER/$REPO" --class deployable --json
+mmi-cli devops bootstrap verify "$OWNER/$REPO" --class deployable --json
 # or for content repos:
-mmi-cli bootstrap verify "$OWNER/$REPO" --class content --json
+mmi-cli devops bootstrap verify "$OWNER/$REPO" --class content --json
 ```
 
 Run it again after Step 7. A repo is not ready for real developers until every check is green, or the report
@@ -166,7 +166,7 @@ On an empty repo that PUT creates `$FIRST` **and leaves it the default branch**,
 The two `gh` writes above are authorized by the authenticated master-admin login and are the one-time
 bootstrap exception while no App-backed `mmi-cli` command owns a repository that does not yet exist. They
 are not a general write lane: after the namespace and first ref exist, use the App-backed
-`mmi-cli bootstrap apply --execute` path for managed seeds, labels, rulesets, and registry state.
+`mmi-cli devops bootstrap apply --execute` path for managed seeds, labels, rulesets, and registry state.
 
 For a **content** repo the API form is not merely tidier, it is the only thing that works: `main` is that
 track's first and only branch, so the initial commit IS a push to `main` and the #1660 guard fences it — and
@@ -292,13 +292,13 @@ gh project list --owner "$PROJECT_OWNER" --format json   # existing boards to ch
   Then **interview the master** for the seed short description + README (what it tracks, member repos, links
   to the repos' `README.md`/`architecture.md`); set them via the `updateProjectV2` mutation
   (`shortDescription`, `readme`). If cloning, verify the built-in workflows survived (next note).
-- **Built-in workflows:** `mmi-cli bootstrap verify` checks these Project workflows are enabled:
+- **Built-in workflows:** `mmi-cli devops bootstrap verify` checks these Project workflows are enabled:
   `Auto-add sub-issues to project`, `Auto-archive items`, `Item added to project`, and `Item closed`. The
   Todo/In Progress/In Review moves are **central** (the Hub webhook); the built-in `Item closed` sets `Done`
   on merge. GitHub's public GraphQL schema exposes delete/read surfaces for Project workflows but no
   create/update/enable mutation; if any required workflow is missing or disabled, repair it in the project's
   **Workflows** settings before calling the repo ready for developers.
-- **Board shape (#4093):** `mmi-cli bootstrap verify` also checks the view triple (`List`/`Board`/`Roadmap`
+- **Board shape (#4093):** `mmi-cli devops bootstrap verify` also checks the view triple (`List`/`Board`/`Roadmap`
   by name **and** layout), the Board view's grouping, and its card fields against the standard the template
   board (project 4) carries. Grouping (columns=`Status`, swimlanes=`Repository`) has **no** GraphQL create/
   update mutation (`ProjectV2ViewConfigurationInput` carries only `visibleFieldIds`) — a drifted swimlane or
@@ -308,10 +308,10 @@ gh project list --owner "$PROJECT_OWNER" --format json   # existing boards to ch
   drifted one can be fixed live instead of only reported.
 
 Record the chosen `projectNumber`/`projectId` plus Status/Priority field ids in the Hub registry META
-(`PROJECT#<slug>`) by re-running `mmi-cli bootstrap apply --execute` **after** `gh project link`. Apply reads
+(`PROJECT#<slug>`) by re-running `mmi-cli devops bootstrap apply --execute` **after** `gh project link`. Apply reads
 the repo's linked board and derives all of them itself (#3543) — pass `--var PROJECT_ID=<node id>` only to
 override, which is also what you need when the repo is linked to more than one board and apply therefore
-refuses to guess. **Verify the row afterwards** (`mmi-cli org project get <owner/repo>`): a registered repo
+refuses to guess. **Verify the row afterwards** (`mmi-cli oracle org project get <owner/repo>`): a registered repo
 whose META carries no `projectId`/`statusFieldId` looks finished everywhere else while the Hub webhook has
 nothing to move issues with, and `registry project board META exists` is the single check that says so. Going forward the thin Lambda adds each new issue to that project on `issues.opened` and sets
 `Status: Todo`.
@@ -331,7 +331,7 @@ The default `tenant-container` substrate is a **Hetzner box** (`hetzner-ssh`): t
 `.env` from the registry + vault and runs the container via docker-compose, deployed over the Hub's bounded
 SSH lane. Do **not** create an AWS OIDC deploy role or a repo deploy Action for it. **Ask the master for the
 box assignment** — the `sshHost` (and the loopback port) per stage — then write the `DEPLOY#<stage>` rows with
-`mmi-cli org project set-deploy <owner/repo> --stage <dev|rc|main> --ssh-host <host> [--port <p>]` (defaults:
+`mmi-cli oracle org project set-deploy <owner/repo> --stage <dev|rc|main> --ssh-host <host> [--port <p>]` (defaults:
 `substrate: hetzner-ssh`, deploy path `/opt/mmi/<slug>/<stage>`, service = slug, ssh-user `root`). Without those
 rows the tenant cannot deploy (`tenant-deploy.yml` errors on missing `DEPLOY#` coords), so do not skip this.
 Keep every runtime config value in the vault; never paste secret values into logs.
@@ -381,7 +381,7 @@ collaborator list + the per-branch allowlist are the record — no separate rost
   both enforce the step, so do not remove it. After apply,
   master-admin must **activate** that JSON as a repository ruleset (GitHub → Settings → Rules → Rulesets →
   Import/create from the committed reference) so the `gate` context is required on train branches. Once the
-  gate is green on `development`, `mmi-cli ci reconcile --apply --repo $OWNER/$REPO` should flip enforcement
+  gate is green on `development`, `mmi-cli devops ci reconcile --apply --repo $OWNER/$REPO` should flip enforcement
   to **Active**; if it does not, use the Step 5 PUT fallback and confirm with `bootstrap verify` before
   reporting bootstrap complete. MMI-Hub keeps its own three-job gate (`cli`/`infra`/`docs`) — never apply the
   product ruleset there.
@@ -411,7 +411,7 @@ collaborator list + the per-branch allowlist are the record — no separate rost
   Cloning from the template board (project 4, Step 3) already produces this; `bootstrap verify` asserts it
   (`Board view card fields match the org standard`) on every subsequent run, so drift shows up there rather
   than only at bootstrap time. Fix via Board view → **Fields**, or `updateProjectV2View(configuration:
-  {visibleFieldIds:[...]})`. Strip any legacy `priority:*` / taxonomy labels with `mmi-cli board doctor --fix`.
+  {visibleFieldIds:[...]})`. Strip any legacy `priority:*` / taxonomy labels with `mmi-cli oracle board doctor --fix`.
 - **Org App credentials** — nothing to register per repo (#494). Board moves are central (the Hub webhook
   moves Todo/In Progress/In Review for every repo) and the org App token is minted inside the Hub's own
   central workflows, so `MMI_APP_ID` / `MMI_APP_PRIVATE_KEY` live only on the Hub — a product repo seeds no
@@ -436,12 +436,12 @@ collaborator list + the per-branch allowlist are the record — no separate rost
   what this bootstrap already knows: **Stack / Run locally / Verify** from the Step-4c gate + install commands
   and the repo's actual code; **Gotchas** and the architecture **Overview / Build & deploy** from the confirmed
   Step-0 axes (class, project-type, deploy-model). Do **not** write the release track, board number, or deploy
-  coords as a value — the templates point at `mmi-cli org project get` (registry SSOT, never copied, so it cannot drift).
+  coords as a value — the templates point at `mmi-cli oracle org project get` (registry SSOT, never copied, so it cannot drift).
   Do not write `AGENTS.md` / `CLAUDE.md` — these are developer-owned, gitignored agent guides, never a bootstrapped repo file (the `mmi-no-agent-files-org` ruleset blocks committing them).
 - **`docs/index.md` is an optional generated routing index (#3545 / Hub#4133).** Agent entrypoints prefer
-  `mmi-cli repo-index search` + compute-at-read CLI over living prose under `docs/`. Apply may still create
+  `mmi-cli oracle repo-index search` + compute-at-read CLI over living prose under `docs/`. Apply may still create
   `docs/index.md` once for link routing; it never rewrites it. Once the repo has docs of its own,
-  `mmi-cli docs index --write` owns the routing artifact and `--check` gates drift — it is not product
+  `mmi-cli oracle docs index --write` owns the routing artifact and `--check` gates drift — it is not product
   current-state SSOT. Decision records under `docs/decisions/` remain append-only *why*.
 - **Push the mandated fill past the active ruleset (#1807).** Deployable repos activate
   `mmi-product-required-checks` during apply (its `bypass_actors` is empty by design), so the `gate` check is
@@ -451,8 +451,8 @@ collaborator list + the per-branch allowlist are the record — no separate rost
   `mmi-product-required-checks`, set **Enforcement** to **Disabled**, push/merge the filled `README.md` +
   `architecture.md`, then set **Enforcement** back to **Active**. Programmatic equivalent: PUT the ruleset
   with `enforcement: disabled` (a PATCH is rejected, #917/#922), push the fill, then PUT it back to
-  `active` (or re-run `mmi-cli ci reconcile --apply --repo $OWNER/$REPO` once the gate is green, which
-  should activate idempotently). Before reporting bootstrap complete, run `mmi-cli bootstrap verify` and
+  `active` (or re-run `mmi-cli devops ci reconcile --apply --repo $OWNER/$REPO` once the gate is green, which
+  should activate idempotently). Before reporting bootstrap complete, run `mmi-cli devops bootstrap verify` and
   confirm `product required-check ruleset enforcement active` is OK — a parked ruleset is not done. Never
   leave enforcement disabled.
 - `.claude/settings.local.json` is local-only and gitignored; bootstrap seeds no committed `.claude/settings.json`.
@@ -477,10 +477,10 @@ web tenants, `--project-type desktop-game --deploy-model none --clear-web-profil
 app stores, and
 `--class content --project-type content --deploy-model content --clear-web-profile` for a content/KB repo.
 Run the apply path with the board variables discovered above, or register the same values with
-`mmi-cli org project set` from the Hub or from the target project checkout:
+`mmi-cli oracle org project set` from the Hub or from the target project checkout:
 
 ```bash
-mmi-cli bootstrap apply "$OWNER/$REPO" --class deployable \
+mmi-cli devops bootstrap apply "$OWNER/$REPO" --class deployable \
   --project-type web-app --deploy-model tenant-container --execute \
   --var PROJECT_OWNER="$PROJECT_OWNER" \
   --var PROJECT_NUMBER="$PROJECT_NUMBER" \
@@ -502,14 +502,14 @@ and the app reads plain env vars — it must **not** self-load SSM and must **no
 For a `web-app` that declares `oauth` META, print the canonical OAuth surface and provision the client once:
 
 ```bash
-mmi-cli org oauth plan --repo "$OWNER/$REPO"        # the exact JS origins + redirect URIs + canonical SSM keys
+mmi-cli vault org oauth plan --repo "$OWNER/$REPO"        # the exact JS origins + redirect URIs + canonical SSM keys
 ```
 
 Register those JS origins + `/api/auth/callback` redirect URIs on the Console client (master, per
 `docs/Guides/oauth-provision.md`), then store the creds in the canonical keys in one step:
 
 ```bash
-mmi-cli org oauth set-creds --repo "$OWNER/$REPO" < client.json   # the Console "Download JSON" file
+mmi-cli vault org oauth set-creds --repo "$OWNER/$REPO" < client.json   # the Console "Download JSON" file
 ```
 
 The keys are the one stageless pair `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET` at the slug root — every
@@ -536,7 +536,7 @@ never agent guides or a spine. The fanout pipeline that used to push this block
 Repo, default branch, ruleset applied, train branches locked (push allowlist), project attached/created
 (+ info seeded, Status lanes and Labels field verified), secrets set (names only), developer access, plugin
 installed, docs seeded, registry META written, issue templates committed, org App credentials registered,
-org-managed `.gitignore` block seeded, and the final `mmi-cli bootstrap verify "$OWNER/$REPO" --class ... --json` result.
+org-managed `.gitignore` block seeded, and the final `mmi-cli devops bootstrap verify "$OWNER/$REPO" --class ... --json` result.
 
 ## Retro — one check before you finish
 Before your final report, answer one question honestly: did **this skill's own instructions** misfire
@@ -545,4 +545,4 @@ about? (Process only — never the user's code or task; e.g. an ambiguous seed,
 a guard that fired on a healthy repo.) If yes, file **one** lesson and move on; a clean run is silent
 (hard cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR — never
 edit the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill bootstrap --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill bootstrap --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/bootstrap/seeds/README.template.md

@@ -18,13 +18,13 @@ access runbook → [repo-access](https://github.com/mutmutco/MMI-Hub/blob/develo
 
 Read this section at the start of agent work in this repo.
 
-- **Structure search:** `mmi-cli repo-index search <path|symbol|meaning>` — Hub cloud pointer hits
+- **Structure search:** `mmi-cli oracle repo-index search <path|symbol|meaning>` — Hub cloud pointer hits
   (Hub#4133). Prefer this over inventing wiki pages or trusting stale inventories under `docs/`.
 - **Durable WHY:** `docs/decisions/` — one file per decision, prose only for what was chosen and
   rejected; never a description of current state. Do not maintain living current-state under `docs/`.
-- **Current state:** code + compute-at-read CLI (`mmi-cli org project get`, `board`, `status`,
+- **Current state:** code + compute-at-read CLI (`mmi-cli oracle org project get`, `board`, `status`,
   `org schedules`, …) — registry facts, resolved live. Optional generated `docs/index.md` is a
-  **routing** index only (`mmi-cli docs index --check`), not product truth.
+  **routing** index only (`mmi-cli oracle docs index --check`), not product truth.
 - **GitHub wikis are retired org-wide** — this repo does not publish to a `.wiki.git`; do not create one.
 - **Stack:** (languages, frameworks, major services)
 - **Run locally:** (install, dev server, `/stage` if non-obvious)

package/skills/bootstrap/seeds/architecture.template.md

@@ -21,7 +21,7 @@
 
 ## Build & deploy
 
-- **Class + release track + stages:** `mmi-cli org project get` (registry SSOT — full = development/rc/main,
+- **Class + release track + stages:** `mmi-cli oracle org project get` (registry SSOT — full = development/rc/main,
   direct = development/main, trunk = main; never copied here, so it cannot go stale).
 - **Deploys run centrally** via the Hub (`tenant-deploy.yml`); this repo carries no deploy files, unless
   noted otherwise below.

package/skills/bootstrap/seeds/gate.template.yml

@@ -65,7 +65,7 @@ jobs:
       # node/npm (or python) is missing, or whose setup step raced, fails `{{GATE_INSTALL_CMD}}` with a
       # bare `command not found` (exit 127) that reads like a broken diff and abandons a correct PR in an
       # autonomous merge loop. This names the RUNNER instead — a distinguishable infra failure that
-      # `mmi-cli pr checks-wait` classifies as rerunnable (title `CI runner toolchain`), mirroring the
+      # `mmi-cli devops pr checks-wait` classifies as rerunnable (title `CI runner toolchain`), mirroring the
       # disk (#3366) and browser (#808) preflights. No test ran; the diff is not implicated.
       - name: Toolchain preflight
         if: ${{ '{{GATE_RUNTIME}}' == 'node' }}

package/skills/bootstrap/seeds/google-login.template.md

@@ -6,10 +6,10 @@ prod. Adding Google login here is **self-serve**: you do not need master-admin h
 ## Reach the creds (from SSM — never in git, never printed)
 ```bash
 # Confirm they resolve for your repo (names only, no value):
-mmi-cli secrets list
+mmi-cli vault secrets list
 # Consume them keyless in a command — injected into its env, never printed (raw `secrets get` was removed, #2844):
-mmi-cli secrets use GOOGLE_CLIENT_ID -- <cmd>
-mmi-cli secrets use GOOGLE_CLIENT_SECRET -- <cmd>
+mmi-cli vault secrets use GOOGLE_CLIENT_ID -- <cmd>
+mmi-cli vault secrets use GOOGLE_CLIENT_SECRET -- <cmd>
 ```
 The canonical keys are the stageless `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET` pair at the project vault
 root. The project-admin can manage them for their own repo; runtime and CI read them keylessly. Never bake a secret into an
@@ -28,6 +28,6 @@ URIs are registered for both `mutatismutandis.co` and `mutmut.co`, so the deploy
 ## Reference implementation + full guide
 Inspect this repo's expected URIs and confirm the client is port-agnostic:
 ```bash
-mmi-cli org oauth plan      # the canonical JS origins + redirect URIs + SSM cred params
-mmi-cli org oauth verify    # probes an arbitrary :9123 loopback — no redirect_uri_mismatch = good
+mmi-cli vault org oauth plan      # the canonical JS origins + redirect URIs + SSM cred params
+mmi-cli vault org oauth verify    # probes an arbitrary :9123 loopback — no redirect_uri_mismatch = good
 ```

package/skills/bootstrap/seeds/manifest.json

@@ -1,5 +1,5 @@
 {
-  "_comment": "Bootstrap seed manifest (#201) — the machine-readable contract of what /bootstrap and `mmi-cli bootstrap --apply` (#202) stamp into a target repo. Consumed by the CLI (loadBootstrapSeeds). ownership: 'org' = org-delivered, OVERWRITTEN on upgrade (the org owns it); 'repo' = created ONCE on a fresh bootstrap, never clobbered on upgrade (the repo owns its content). source: 'self' = copy MMI-Hub's own current file verbatim; 'seed:<file>' = render the named template in this dir with {{PLACEHOLDERS}}; 'managed-block' = merge the org-managed .gitignore block in place (preserves the repo's own ignore lines) — this is how the org-managed .gitignore block reaches every repo now that the fanout pipeline is retired (Hub#3010); the doctor SessionStart heal keeps it current thereafter. NOTE: this manifest seeds org-managed PRODUCT assets only — it never seeds AGENTS.md / CLAUDE.md / .claude/settings.json (personal agent guides) or a legacy repo-local control-plane marker. classes: which repo classes receive this seed.",
+  "_comment": "Bootstrap seed manifest (#201) — the machine-readable contract of what /bootstrap and `mmi-cli devops bootstrap --apply` (#202) stamp into a target repo. Consumed by the CLI (loadBootstrapSeeds). ownership: 'org' = org-delivered, OVERWRITTEN on upgrade (the org owns it); 'repo' = created ONCE on a fresh bootstrap, never clobbered on upgrade (the repo owns its content). source: 'self' = copy MMI-Hub's own current file verbatim; 'seed:<file>' = render the named template in this dir with {{PLACEHOLDERS}}; 'managed-block' = merge the org-managed .gitignore block in place (preserves the repo's own ignore lines) — this is how the org-managed .gitignore block reaches every repo now that the fanout pipeline is retired (Hub#3010); the doctor SessionStart heal keeps it current thereafter. NOTE: this manifest seeds org-managed PRODUCT assets only — it never seeds AGENTS.md / CLAUDE.md / .claude/settings.json (personal agent guides) or a legacy repo-local control-plane marker. classes: which repo classes receive this seed.",
   "placeholders": ["OWNER", "REPO", "REPO_SLUG", "REPO_NAME", "CLASS", "GATE_CMD", "GATE_PUSH_BRANCHES_YAML", "GATE_FULL_RUN_BRANCH", "GATE_RULESET_BRANCH_REFS_JSON", "PROJECT_OWNER", "PROJECT_NUMBER", "PROJECT_ID", "STATUS_FIELD_ID", "STATUS_TODO", "STATUS_IN_PROGRESS", "STATUS_IN_REVIEW", "STATUS_DONE", "STACK", "REGION"],
   "seeds": [
     { "target": ".github/ISSUE_TEMPLATE/bug.yml", "source": "self", "ownership": "org", "classes": ["deployable", "content"] },

package/skills/browser-automation/SKILL.md

@@ -90,4 +90,4 @@ about? (Process only — never the user's code or task.) If yes, file **one** le
 silent (hard cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR —
 never edit the skill live; the retro is advisory, so if the call fails, note it and continue:
 
-`mmi-cli skill-lesson --skill browser-automation --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill browser-automation --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/epic/SKILL.md

@@ -23,7 +23,7 @@ Read the parent end-to-end before slicing — body **and every comment**, treati
 superseding:
 
 ```bash
-mmi-cli board show <owner/repo#N>       # status, body, and every comment for the umbrella
+mmi-cli oracle board show <owner/repo#N>       # status, body, and every comment for the umbrella
 ```
 
 Slice by deliverable, not by phase: each child must be independently claimable and land in its own PR.
@@ -59,7 +59,7 @@ aggregate error, so you fix all of them once. Get the user's go on the drafted s
 ## Step 2 — create the children
 
 ```bash
-mmi-cli issue create --type task --batch tmp/epic-children.json --surface cli
+mmi-cli oracle issue create --type task --batch tmp/epic-children.json --surface cli
 ```
 
 `--type` is required by the create command but each row's own `type` governs; pass any valid type as the
@@ -74,14 +74,14 @@ wait for writes to quiesce, inspect the children, then retry the missing rows wi
 ## Step 3 — confirm the tree
 
 ```bash
-mmi-cli issue children <owner/repo#N>        # each child: number/title/state/repo/boardStatus/linkedPrs
+mmi-cli oracle issue children <owner/repo#N>        # each child: number/title/state/repo/boardStatus/linkedPrs
 ```
 
 Verify every intended child is linked and on the board as Todo. To link a child that already existed (not
 part of the batch), use the inverse-friendly single link:
 
 ```bash
-mmi-cli issue link-child <parent> <child>
+mmi-cli oracle issue link-child <parent> <child>
 ```
 
 Each child is now a parallel item — fan them out one worktree + PR each. **When the last child merges,
@@ -101,4 +101,4 @@ about? (Process only — never the user's code or task; e.g. a batch schema that
 link that attached to the wrong parent.) If yes, file **one** lesson and move on; a clean run is silent
 (hard cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR — never
 edit the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill epic --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill epic --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/hotfix/SKILL.md

@@ -39,7 +39,7 @@ Production changes require the authorized human's explicit approval in the curre
 and CLI health before starting:
 
 ```bash
-mmi-cli org access role <owner/repo> --json
+mmi-cli oracle org access role <owner/repo> --json
 mmi-cli doctor --no-repo-writes
 ```
 
@@ -55,7 +55,7 @@ exactly ` M` as real work to commit or stash, and for ` M` discard only when
 Use the orchestrator with an explicit source every time:
 
 ```bash
-mmi-cli hotfix start --from <development-pr-or-sha>[,<development-pr-or-sha>...] --json
+mmi-cli devops hotfix start --from <development-pr-or-sha>[,<development-pr-or-sha>...] --json
 ```
 
 **One hotfix cycle carries as many merged fixes as you name.** `--from` takes a comma-separated list in
@@ -91,8 +91,8 @@ active agent doctrine. Review the actual main-base diff and the original issue a
 Wait for required CI through Hub:
 
 ```bash
-mmi-cli pr checks-wait <hotfix-pr-number>
-mmi-cli pr merge <number> --squash
+mmi-cli devops pr checks-wait <hotfix-pr-number>
+mmi-cli devops pr merge <number> --squash
 ```
 
 The main-base PR is the production gate. Do not bypass checks or protected-branch authority. After the
@@ -103,11 +103,11 @@ issue. The development PR should already have closed the work item; do not add r
 
 ## 3. Run the gated release
 
-Derive the tag from `mmi-cli hotfix status`, then release with the same declared source:
+Derive the tag from `mmi-cli devops hotfix status`, then release with the same declared source:
 
 ```bash
-mmi-cli hotfix status
-mmi-cli hotfix release <vX.Y.Z> --carries <development-pr-or-sha>[,<development-pr-or-sha>...]
+mmi-cli devops hotfix status
+mmi-cli devops hotfix release <vX.Y.Z> --carries <development-pr-or-sha>[,<development-pr-or-sha>...]
 ```
 
 Name **every** fix the cycle carries. Each is proven an ancestor of the tagged SHA before tagging; a
@@ -146,8 +146,8 @@ Hub docs catalog-lockstep refuses PRs into `development` that advance
 truth. When Publish-Truth / a version bump must advance the marketplace, do **not** land
 `release-distribution prepare` as a development PR — use this hotfix door:
 
-1. `mmi-cli hotfix start --from <merged-dev-pr-or-sha>` (prepare + distribution bump on `hotfix/vX.Y.Z` from `main`)
-2. merge the hotfix PR → `mmi-cli hotfix release vX.Y.Z` (publish)
+1. `mmi-cli devops hotfix start --from <merged-dev-pr-or-sha>` (prepare + distribution bump on `hotfix/vX.Y.Z` from `main`)
+2. merge the hotfix PR → `mmi-cli devops hotfix release vX.Y.Z` (publish)
 3. land the automatic `hotfix-fold/<tag>` development fold PR (or follow its printed remedy)
 
 A development prepare PR that only exists to move marketplace ahead of main will keep failing
@@ -158,5 +158,5 @@ catalog-lockstep; that is not a false red — switch to the hotfix path above.
 If this skill's instructions themselves misfired, file one deduplicated lesson and continue:
 
 ```bash
-mmi-cli skill-lesson --skill hotfix --title "<what misfired>" --body "<what; evidence; proposed amendment>"
+mmi-cli learning skill-lesson --skill hotfix --title "<what misfired>" --body "<what; evidence; proposed amendment>"
 ```

package/skills/mmi/SKILL.md

@@ -37,7 +37,7 @@ it on every move). Closed/finished items auto-archive after they go quiet; archi
    cached/session-start health line explicitly says a heal is needed.
 
 ```bash
-mmi-cli board read --json    # Step 1 — first useful render on the happy path
+mmi-cli oracle board read --json    # Step 1 — first useful render on the happy path
 mmi-cli doctor --no-repo-writes   # only after a hard setup signal — foreground, one at a time
 ```
 
@@ -112,7 +112,7 @@ What the env half heals:
     ```
     The `project` scope is what lets `/mmi` read + move the board, granted here once. When they're back,
     re-run `mmi-cli doctor` to confirm green.
-  - **Hub registry / board META** — `mmi-cli org project get <owner/repo>` or `mmi-cli board read` reports
+  - **Hub registry / board META** — `mmi-cli oracle org project get <owner/repo>` or `mmi-cli oracle board read` reports
     missing project/board coords → a master-admin registers or backfills the repo's `PROJECT#<slug>` META.
     There's no reliable project to read until that is fixed, so stop here.
 
@@ -127,7 +127,7 @@ tenant request surfaces. After the board read (Step 1), you already have `viewer
 authority on this or another repo, run:
 
 ```bash
-mmi-cli org access role <owner/repo> --json   # { role, train } — Hub-verified from registry projectAdmins
+mmi-cli oracle org access role <owner/repo> --json   # { role, train } — Hub-verified from registry projectAdmins
 ```
 
 When `role` is `project-admin` and `train` is true on **that** repo, the dev holds D14 authority there —
@@ -150,14 +150,14 @@ cards** (title + compact intent, PRIOR-not-instruction framing — silent when a
 complete partition — secondary repos, taken items, bundle details — run the full command below.
 
 ```bash
-mmi-cli board read --json
+mmi-cli oracle board read --json
 ```
 
 This is the **only foreground call** on the happy path for **work items** (not identity — Step 0 already
 resolved login). Its JSON carries `viewer`, `repo`, and the project title — do **not** run separate
 `gh api user` / `gh repo view` calls; they just delay the board. If `repo` is missing from the JSON,
 keep the board header generic. The CLI resolves the project from the Hub registry; to inspect it
-directly, `mmi-cli org project get --json`.
+directly, `mmi-cli oracle org project get --json`.
 
 Use the returned `primary` group for current-repo items and `secondary` for other repos on the same Project.
 Within each group, render `userOwned`, `claimable`, and `taken`.
@@ -242,18 +242,18 @@ potentially **superseding** the body. Only then greet into the work or propose a
 
 ```bash
 # One shot — status, assignees, type, body, and every comment for one board item:
-mmi-cli board show <owner/repo#N>          # add --json for machine-readable output
+mmi-cli oracle board show <owner/repo#N>          # add --json for machine-readable output
 ```
-For an item **not on the board**, `mmi-cli issue view <N> --comments` is the board-independent one-shot:
+For an item **not on the board**, `mmi-cli oracle issue view <N> --comments` is the board-independent one-shot:
 it returns the body **and** every comment as JSON in a single call (add `--context` for `linkedPrs` and, on
 an epic, a `children` summary). Prefer it over raw `gh issue view --comments`, which in a non-TTY shell (every
 agent/CI context) prints only the comments, hides the body, and prints nothing at all on a zero-comment issue.
 ```bash
-mmi-cli issue view <N> --repo <owner/repo> --comments   # body + every comment, one call
+mmi-cli oracle issue view <N> --repo <owner/repo> --comments   # body + every comment, one call
 ```
 
 > **Never reach for standalone `jq`** — it isn't installed on Windows dev machines, so each attempt burns a
-> failed call (#230). `mmi-cli board read|show` is already human-readable (drop `--json`); to parse JSON use
+> failed call (#230). `mmi-cli oracle board read|show` is already human-readable (drop `--json`); to parse JSON use
 > `mmi-cli … --json` piped to `node`, or `gh`'s **built-in** `--jq`.
 
 (Triggers only when a dev commits to an existing item — no-op for the *report a bug / request a feature /
@@ -266,7 +266,7 @@ something else* paths.)
   is offered. Every later transition (In Review on PR open, Done on merge) flows automatically from the
   work, not from here.
   ```bash
-  mmi-cli board claim <owner/repo#N> --json
+  mmi-cli oracle board claim <owner/repo#N> --json
   ```
   The command validates `Todo` + unassigned, assigns the viewer, and moves the Project v2 `Status` to
   `In Progress`. A partial claim exits nonzero unless the dev explicitly accepted `--allow-partial`.
@@ -279,14 +279,14 @@ something else* paths.)
   2. **Fill that type's template.** Read its fields from `.github/ISSUE_TEMPLATE/<type>.yml` and gather
      answers from the dev for each — draft where you can, ask where you can't (the template form is
      interactive and won't drive in a non-TTY agent shell, so collect the fields, then create directly).
-  3. **Submit via `mmi-cli issue create`** — the canonical create path. Before filing, read the live
+  3. **Submit via `mmi-cli oracle issue create`** — the canonical create path. Before filing, read the live
      `issue create` entry from `mmi-cli commands --json`; flags change, and a missing documented flag means
      the installed CLI is stale until a fresh local build proves otherwise. It maps `--type` to the label,
      `--priority` sets the board Priority **field** (never a `priority:*` label — #416), and `--surface`
      supplies the repository's required single surface label. It always prints `{number,url}` JSON. Never
      use `gh issue create`; it bypasses these board contracts:
      ```bash
-     mmi-cli issue create --type <bug|feature|task> --title "<title>" --body "<filled template>" \
+     mmi-cli oracle issue create --type <bug|feature|task> --title "<title>" --body "<filled template>" \
        --priority <high|medium|low> --surface <surface>
      ```
      For long markdown, materialize a temporary UTF-8 body file, pass its real path with
@@ -299,7 +299,7 @@ something else* paths.)
      The command starts bounded related-issue discovery off-path. It auto-comments only high-confidence,
      idempotent links. To inspect candidates manually before writing anything else:
      ```bash
-     mmi-cli issue discover-related --repo <owner/repo> --number <number> --title "<title>" --body "<body>" --json
+     mmi-cli oracle issue discover-related --repo <owner/repo> --number <number> --title "<title>" --body "<body>" --json
      ```
   It lands on the board as Todo automatically — confirm the link from the JSON. (Templates differ per
   repo; read the actual `.yml` set rather than assuming bug/feature/task.)
@@ -339,7 +339,7 @@ Bundling detail boundary: start from the metadata board. Only if there are multi
 `userOwned`/`claimable` candidates, fetch bodies/comments with:
 
 ```bash
-mmi-cli board read --json --bundle-details
+mmi-cli oracle board read --json --bundle-details
 ```
 
 That detail path may fetch bodies/comments only for `userOwned` and `claimable` issues. `taken` stays
@@ -364,7 +364,8 @@ destroying the worktree after each issue:
   `--body-file <path>`, and remove it after the write succeeds. Do not pipe the body to `--body-file -`;
   host prose guards require the materialized-file path.
 - **Batch:** one worktree, claim each item (the Step 5 claim loop), make the coupled edits, open **one** PR
-  (`Closes #…, #…`).
+  (`Closes #…, #…`). When an issue must stay open (HOLD/prep), never write `Does not close #N` — GitHub
+  still closes it; use `Part of #N` / `Refs #N` / `leaves #N open` only (JC#495).
 - **Session/sequential:** multiple related same-repo items handled one after another in the same session
   reuse the active worktree until the session or execution group ends; do not churn one worktree per
   issue unless a branch/PR boundary, true parallelism, or explicit user ask requires it.
@@ -375,7 +376,7 @@ destroying the worktree after each issue:
 - **Stage/worktree:** a local `/stage` is tied to the worktree that started it. Stop/destroy and recreate
   it before moving to another worktree, or warn first when intent is unclear.
 - **Split:** keep the original as the umbrella; file each child as a **native sub-issue** of it with
-  `mmi-cli issue create --parent <umbrella-ref> …` (or `mmi-cli issue link-child <umbrella> <child>` for a
+  `mmi-cli oracle issue create --parent <umbrella-ref> …` (or `mmi-cli oracle issue link-child <umbrella> <child>` for a
   child that already exists). The parent then renders a sub-issue checklist with each child's state and the
   child renders its parent — no title prefix or body task-list to maintain. Refs are `#NN`, `owner/repo#NN`,
   or a URL, and it works cross-repo (a Hub umbrella can track product-repo children). Get the dev's go before
@@ -400,4 +401,4 @@ about? (Process only — never the user's code or task; e.g. a board read that m
 claimable, or a claim that moved the wrong item.) If yes, file **one** lesson and move on; a clean run is
 silent (hard cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR —
 never edit the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill mmi --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill mmi --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/mmi-doctor/SKILL.md

@@ -14,7 +14,7 @@ mmi-cli doctor
 By default this **heals and cleans** (MMI-Hub#3975): CLI/plugin/marketplace env repairs, managed
 `.gitignore`, merged-branch / dead-worktree reap (including deferred IDE-locked removals), light board
 mechanical fixes, docs-index working-tree heal, and related full-lane checks. Secrets stay **out** of
-default doctor — use `mmi-cli secrets diff` when you need a catalog gap check.
+default doctor — use `mmi-cli vault secrets diff` when you need a catalog gap check.
 
 ## Flags
 
@@ -32,8 +32,8 @@ Do **not** chain these as a `/mmi-doctor` substitute:
 
 ```bash
 mmi-cli doctor --self
-mmi-cli board doctor
-mmi-cli secrets diff
+mmi-cli oracle board doctor
+mmi-cli vault secrets diff
 mmi-cli worktree gc
 ```
 
@@ -52,4 +52,4 @@ about? (Process only — never the user's code or task; e.g. a doctor run that p
 branch.) If yes, file **one** lesson and move on; a clean run is silent (hard cap: one per run). It
 lands on the Hub board (deduped) and is fixed only via a reviewed PR — never edit the skill live; the
 retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill doctor --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill doctor --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/onboard/SKILL.md

@@ -35,7 +35,7 @@ front of you.
 A `✗` on any line comes with a `Next command:` — run **that** first. Common ones:
 
 - Hub API URL not configured → `mmi-cli doctor` (fix wiring).
-- Repo not registered → a master-admin runs `/bootstrap` (or `mmi-cli org project set <owner/repo>`).
+- Repo not registered → a master-admin runs `/bootstrap` (or `mmi-cli oracle org project set <owner/repo>`).
 - GitHub auth missing → the dev runs `gh auth login --hostname github.com --git-protocol https --web --scopes "project"`.
 
 ## Step 1 — the picture
@@ -44,13 +44,13 @@ Once the gates are green:
 
 ```bash
 mmi-cli status        # branch, worktrees, your PRs, your claimed items, stage
-mmi-cli next          # the first claimable item + its claim command
+mmi-cli oracle next          # the first claimable item + its claim command
 ```
 
 ## Step 2 — hand over the first move
 
 Close with one grounding line: gates green (or the one gate to fix), and the single first command —
-usually `mmi-cli board claim <n>` for the recommended item, or the readiness fix if a gate is red. Don't
+usually `mmi-cli oracle board claim <n>` for the recommended item, or the readiness fix if a gate is red. Don't
 claim on the user's behalf; let them take the first item when ready.
 
 ## Step 2b — structure door (compute-at-read)
@@ -58,9 +58,9 @@ claim on the user's behalf; let them take the first item when ready.
 Before treating `docs/**` as current-state, teach the Hub door (Hub#4133 / #4148):
 
 ```bash
-mmi-cli repo-index search <path-or-symbol-or-meaning>   # Hub cloud pointers (default)
-mmi-cli repo-index search "where …" --semantic          # Titan meaning over embeddings
-mmi-cli repo-index status --cloud                        # is the estate index live?
+mmi-cli oracle repo-index search <path-or-symbol-or-meaning>   # Hub cloud pointers (default)
+mmi-cli oracle repo-index search "where …" --semantic          # Titan meaning over embeddings
+mmi-cli oracle repo-index status --cloud                        # is the estate index live?
 ```
 
 Host indexes (Cursor / Kilo) stay local helpers; **Hub `repo-index` is the org SSOT structure door**.
@@ -81,4 +81,4 @@ board read actually failed, or a next command that pointed at the wrong fix.) If
 and move on; a clean run is silent (hard cap: one per run). It lands on the Hub board (deduped) and is
 fixed only via a reviewed PR — never edit the skill live; the retro is advisory, so if the call fails,
 note it and continue:
-`mmi-cli skill-lesson --skill onboard --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill onboard --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/rcand/SKILL.md

@@ -12,7 +12,7 @@ run `/release` from `development` instead. The board needs no touch
 here — items reach `Done` when their PR merges to `development` (native close → Done); `rc` is a deploy
 stage, not a lane.
 
-Authority is **structural + server-checked**: step 0 asks the Hub (`mmi-cli org access role`), and step 4
+Authority is **structural + server-checked**: step 0 asks the Hub (`mmi-cli oracle org access role`), and step 4
 pushes to the protected `rc` branch, whose per-repo allowlist carries the same people (master + that repo's
 project-admins). No `.env` role marker. Gate ordering: the tag lands the rc SHA
 for checks, and every deploy side-effect waits until the protected `rc` push accepts that checked SHA.
@@ -20,14 +20,14 @@ for checks, and every deploy side-effect waits until the protected `rc` push acc
 ## Step 0 — train-authority probe (server-side, D14)
 
 ```bash
-mmi-cli org access role {owner}/{repo} --json   # Hub-verified: { role, train }
+mmi-cli oracle org access role {owner}/{repo} --json   # Hub-verified: { role, train }
 ```
 `train: false` — or ANY error (fail closed) → stop: a product repo's train belongs to that repo's
 **project-admin** (repo write + registry `projectAdmins`) or the master. When `project-admin` + `train`,
 proceed — do not redirect to the master (`AGENTS.md` § Authority). Errors → fix `gh auth` first,
 never proceed unverified.
 
-**CLI freshness (#2562):** check the running CLI is current BEFORE step 1 — `mmi-cli rcand --apply` refuses
+**CLI freshness (#2562):** check the running CLI is current BEFORE step 1 — `mmi-cli devops rcand --apply` refuses
 a stale CLI at its own step 0 (pre-mutation), but the manual steps below mutate local state earlier, so a
 stale CLI discovered late reads as a mid-train abort. When another train just published a new CLI (e.g. a
 Hub release), run `mmi-cli doctor --no-repo-writes` first. A stale-CLI refusal itself changes
@@ -65,12 +65,12 @@ Dirty → stop. Count `0` → stop ("nothing to promote"). `>0` → capture the
 Resolve the project META first; its `deployModel` decides the deploy path. `tenant-container` repos use the
 central tenant deployer and therefore need DEPLOY# coords. Serverless, `registry-publish`, and
 `solo-container` repos deploy from their own workflow, so do **not** dispatch `tenant-deploy.yml` for them.
-Direct-track repos (`releaseTrack: direct`, e.g. MMI-Hub) have no rc candidate path; `mmi-cli rcand --apply`
+Direct-track repos (`releaseTrack: direct`, e.g. MMI-Hub) have no rc candidate path; `mmi-cli devops rcand --apply`
 refuses after this preflight.
 Verify META + required SSM secret names before touching `rc`:
 ```bash
-mmi-cli org project get {owner}/{repo}
-mmi-cli secrets preflight --stage rc --repo {owner}/{repo}
+mmi-cli oracle org project get {owner}/{repo}
+mmi-cli vault secrets preflight --stage rc --repo {owner}/{repo}
 ```
 Missing META or secret names → stop and repair the registry/secrets first.
 
@@ -126,7 +126,7 @@ gh api repos/{owner}/{repo}/commits/$SHA/check-runs \
   --jq '[.check_runs[]|{name:.name,conclusion:.conclusion}]'
 git push origin rc
 ```
-(`mmi-cli rcand --apply` performs this discovery + bounded wait itself.)
+(`mmi-cli devops rcand --apply` performs this discovery + bounded wait itself.)
 Rejected (protected / not a bypass actor) → stop, nothing deployed, no board writes; leave the local tag
 for an authorized re-push, never force. Non-fast-forward → re-pull, re-run from step 1.
 
@@ -145,7 +145,7 @@ gh run watch "$(gh run list --workflow tenant-deploy.yml --limit 1 --json databa
 For serverless repos, do **not** dispatch `tenant-deploy.yml`: their own push-triggered workflow owns the
 rc deploy.
 
-`mmi-cli rcand --apply --json` returns the relevant run `runId` + `runUrl` (alongside `deployStatus`), so
+`mmi-cli devops rcand --apply --json` returns the relevant run `runId` + `runUrl` (alongside `deployStatus`), so
 you never hand-correlate Actions. For tenant-container repos, that is the dispatched `tenant-deploy.yml`
 run. For Hub serverless, that is the auto-fired `deploy.yml` run from the protected `rc` push. Add
 `--watch` to block on the run and have `deployStatus` resolve to `success`/`failure`; `promoted: true`
@@ -156,7 +156,7 @@ The deploy runs while you report. When the background watch returns, surface the
 correct next action is a **deploy retry of the existing rc ref** after the Hub runtime is repaired — never
 a re-tag/re-merge:
 ```bash
-mmi-cli runtime tenant redeploy {owner}/{repo} rc --watch   # re-dispatch tenant-deploy.yml for the promoted rc
+mmi-cli devops runtime tenant redeploy {owner}/{repo} rc --watch   # re-dispatch tenant-deploy.yml for the promoted rc
 ```
 **Branch the recovery by failure class — a bare redeploy is NOT always the whole recovery.** For **exit 78**
 (`compose is fileless but DEPLOY#<stage>.noEnvFile is not true`) a plain redeploy fails identically: the
@@ -164,10 +164,10 @@ box's baked `/opt/mmi-control/<slug>.sh` still carries the stale `noEnvFile`, so
 the fileless compose expects passthrough. Fix the registry AND re-render the box control script first, then
 redeploy (`set-deploy` alone is not enough — the reconcile is the discoverable-but-non-obvious middle step):
 ```bash
-mmi-cli org project set-deploy {owner}/{repo} --stage rc --no-env-file true   # register the DEPLOY#rc fileless flag
-mmi-cli runtime tenant reconcile {owner}/{repo} rc --watch                    # Hub-authorized; project-admin needs no MMI-Hub Actions access
-mmi-cli runtime tenant redeploy {owner}/{repo} rc --watch                     # NOW the redeploy reads the corrected control script
-mmi-cli runtime tenant control {owner}/{repo} rc verify-broker --watch        # value-free broker proof for runtime consumers
+mmi-cli oracle org project set-deploy {owner}/{repo} --stage rc --no-env-file true   # register the DEPLOY#rc fileless flag
+mmi-cli devops runtime tenant reconcile {owner}/{repo} rc --watch                    # Hub-authorized; project-admin needs no MMI-Hub Actions access
+mmi-cli devops runtime tenant redeploy {owner}/{repo} rc --watch                     # NOW the redeploy reads the corrected control script
+mmi-cli devops runtime tenant control {owner}/{repo} rc verify-broker --watch        # value-free broker proof for runtime consumers
 ```
 The reconcile must finish green before redeploy starts; `--watch` enforces that ordering. A failed rc
 dispatch stays fail-loud — rc is ephemeral and re-runnable, so the redeploy (after the reconcile step above
@@ -195,4 +195,4 @@ about? (Process only — never the user's code or task; e.g. a misleading author
 ambiguous tag or push-order step.) If yes, file **one** lesson and move on; a clean run is silent (hard
 cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR — never edit
 the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill rcand --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill rcand --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/release/SKILL.md

@@ -20,7 +20,7 @@ master-only. This is the **only** sanctioned prod path; a prod release still nee
 explicit per-turn go — an agent never self-initiates it. The board needs no
 touch — items reached `Done` when their PRs merged to `development`; `rc`/`main` are deploy stages, not lanes.
 
-Authority is structural + server-checked: step 0 asks the Hub (`mmi-cli org access role`), and step 3 pushes
+Authority is structural + server-checked: step 0 asks the Hub (`mmi-cli oracle org access role`), and step 3 pushes
 to the protected `main` branch, whose per-repo allowlist carries the same people (master + that repo's
 project-admins; Hub: master + App only). Gate ordering: the tag lands the release SHA for checks, and
 nothing deploys before the protected `main` push accepts that checked SHA.
@@ -43,7 +43,7 @@ nothing deploys before the protected `main` push accepts that checked SHA.
 
 Confirm the human holding train authority for THIS repo authorized a prod release this turn. Probe:
 ```bash
-mmi-cli org access role {owner}/{repo} --json   # Hub-verified: { role, train }
+mmi-cli oracle org access role {owner}/{repo} --json   # Hub-verified: { role, train }
 ```
 `train: false` — or any error (fail closed) → stop: a product repo's train belongs to that repo's
 project-admin or the master; the Hub train is master-only. **Two exceptions to fail-closed here, and both
@@ -129,6 +129,17 @@ direction is a gate. Read the rows.
 Treating doctor's exit code as the gate halts a healthy train on cosmetic drift — or, worse, teaches an
 operator to ignore doctor's exit code entirely.
 
+**A local `npm ci` failure during the fold on a lockfile CI already accepted is an npm-major mismatch, not a
+bad lockfile (#4578).** Before touching the lockfile, compare toolchains:
+```bash
+npm -v
+gh api repos/{owner}/{repo}/actions/runs --jq '.workflow_runs[0].id'   # or read the gate log's
+# `node -v && npm -v` toolchain-preflight line (#3446) for the npm major CI ran with
+```
+A different npm MAJOR (e.g. local 12 vs. CI's 11) resolves the same lockfile differently and throws `Missing:
+<pkg> from lock file` on a lockfile that is not actually broken. Align the local npm major
+(`npm install -g npm@<CI major>`) and re-run `npm ci` before rewriting or regenerating the lockfile.
+
 **Then check the version yourself — do not rely on doctor having printed a row (#3674).** "Read the rows"
 resolves to "proceed" when the row is *absent*, and doctor's version row is conditional. On 2026-07-27 this
 step reported healthy with no version line while the installed CLI was 3.70.0 against a released 3.71.0;
@@ -149,8 +160,8 @@ central tenant deployer and therefore need DEPLOY# coords. `hub-serverless` (MMI
 workflow, so do **not** dispatch `tenant-deploy.yml` for them.
 Verify META + required SSM secret names before touching `main`:
 ```bash
-mmi-cli org project get {owner}/{repo}
-mmi-cli secrets preflight --stage main --repo {owner}/{repo}
+mmi-cli oracle org project get {owner}/{repo}
+mmi-cli vault secrets preflight --stage main --repo {owner}/{repo}
 ```
 An enumerated missing META row or missing secret name → stop and repair the registry/secrets first. An
 HTTP 5xx, timeout, DNS, socket, or other transport failure is **unverified**, not evidence that a name is
@@ -182,7 +193,7 @@ files further via #2767/#2771; `/release` correctly stopped on 4 conflicted file
 which side carries the correct current content, then land a true-merge alignment PR (never hand-resolve on
 `main`) before rerunning release.
 
-It runs **automatically inside `mmi-cli release --apply`** (Step 1+ below) — built into the CLI so it
+It runs **automatically inside `mmi-cli devops release --apply`** (Step 1+ below) — built into the CLI so it
 works in every product repo with no repo-local script. You do not invoke it separately.
 
 Per main-only commit it accepts: the `(cherry picked from commit <sha>)` trailer with that dev SHA an
@@ -190,7 +201,7 @@ ancestor of `origin/rc` (immune to conflict-resolved ports); a matching `git pat
 (trailer-less picks); or a distribution-manifest-only bump (exempt — rc carries its own). Anything else
 **fails the release closed** → **stop**: the right fix is a re-cut `/rcand` from `development`. Only when
 the authorized human has manually verified the content is in the candidate, rerun with
-`mmi-cli release --apply --ack <sha>[,<sha>…]` — the ack is recorded in the verdict. Never ack to save time.
+`mmi-cli devops release --apply --ack <sha>[,<sha>…]` — the ack is recorded in the verdict. Never ack to save time.
 
 ## Step 0d — no docs-keeping on the release train (Hub#4164)
 
@@ -198,8 +209,8 @@ Scheduled docs-janitor / wiki-keeper / living-docs freshness passes are **retire
 The release train does **not** open docs-only PRs, wait on README/architecture auto-merges, or
 treat prose refresh as a gate.
 
-Current state is compute-at-read + the estate repo-index (`mmi-cli repo-index search`,
-`mmi-cli org project`, board/schedules verbs). Durable WHY stays in `docs/decisions/`.
+Current state is compute-at-read + the estate repo-index (`mmi-cli oracle repo-index search`,
+`mmi-cli oracle org project`, board/schedules verbs). Durable WHY stays in `docs/decisions/`.
 If shipping code made a hand-written surface wrong, fix it on `development` as an ordinary PR
 **outside** the train — never as a release Step.
 
@@ -223,11 +234,11 @@ Conflict → abort + stop (the train is misaligned — investigate; don't hand-r
 direct-track repo, a conflict here right after a hotfix is expected friction, not a fluke — see Step 0c for
 why (a hotfix freezes a snapshot that `development` can keep rewriting).
 Alignment PRs are the exception to the org's squash default: land them with a true merge —
-`mmi-cli pr merge <n> --auto --merge` (not squash; a squash discards the merge parentage, so the
+`mmi-cli devops pr merge <n> --auto --merge` (not squash; a squash discards the merge parentage, so the
 misalignment guard re-flags the same divergence on the next run). `--auto` clears the checks the PR
 triggers, which block an immediate merge right after a release.
 
-**Exception — version-manifest and `.gitignore` paths.** `mmi-cli release --apply` tolerates
+**Exception — version-manifest and `.gitignore` paths.** `mmi-cli devops release --apply` tolerates
 conflicts confined to the version-fold paths (Step 1b) and `.gitignore` (#1037 — a
 repo bootstrapped before the managed-gitignore era still carries the legacy file on `main`; the candidate
 carries the Hub-managed copy with project-local entries preserved). The org spine is no longer delivered per
@@ -236,7 +247,7 @@ committed CLI bundle on `main` only, so the next merge re-conflicts there even w
 and the fold rewrites those exact paths right after the merge. For all tolerated paths the CLI takes the
 incoming side deterministically and continues. Any other conflicted path → abort + stop as above.
 
-## Step 1b — version fold (automatic, inside `mmi-cli release --apply`)
+## Step 1b — version fold (automatic, inside `mmi-cli devops release --apply`)
 
 Every release folds the version bump into the release itself (#976): after the merge onto local `main` and
 before the tag, the CLI bumps the version manifests to the release version and commits — **unconditionally,
@@ -269,7 +280,7 @@ git tag "$TAG"
 
 ## Step 3 — push tag, wait for the REQUIRED checks, then push main (the gate)
 
-`mmi-cli release --apply`'s exit code is **not** the release verdict: exit `2` can mean the release
+`mmi-cli devops release --apply`'s exit code is **not** the release verdict: exit `2` can mean the release
 shipped successfully while protected-branch alignment remains pending, and exit `1` can mean a
 post-release follow-up failed after promotion. Read the live release verdict and verify these four
 facts instead: the `main..development` count, the tag on `origin`, `gh release view`, and the runs on
@@ -296,7 +307,7 @@ gh api repos/{owner}/{repo}/commits/$SHA/check-runs \
   --jq '[.check_runs[]|{name:.name,conclusion:.conclusion}]'
 git push origin main
 ```
-(`mmi-cli release --apply` performs this discovery + bounded wait itself.) A required context can only ever
+(`mmi-cli devops release --apply` performs this discovery + bounded wait itself.) A required context can only ever
 resolve on a tag SHA if its workflow runs on `push: tags` (or is otherwise SHA-addressable) — a PR/issue-event
 job (e.g. a stale hand-added `add-to-project` / `mark-merged-pr-done` board-automation check) structurally
 never produces a check-run there. The train recognizes that fixed pair by name and, after a short grace
@@ -313,7 +324,7 @@ never go forward (a failed check will not pass on that SHA). This is the **oppos
 state (checks passing/pending, only the branch push / Release / deploy left, where the recovery is to finish
 forward and you must NOT delete the tag). Here: fix the cause on `development` via a CI-gated PR, then **delete
 the stray tag** — `git push origin --delete vX.Y.0` **and** `git tag -d vX.Y.0` (delete the local tag too; a
-surviving local tag makes `next-version cycle` silently mint the *next* version) — and re-run `mmi-cli release
+surviving local tag makes `next-version cycle` silently mint the *next* version) — and re-run `mmi-cli devops release
 --apply` (the fold re-tags the same version on the fixed HEAD). **Tag deletion is deletion-class → it needs the
 authorized human's explicit per-turn go.** Exception: if a publish/deploy DID run off the stray tag, do **not**
 delete — mint the next version with `MMI_RELEASE_VERSION` instead. The CLI already classifies this
@@ -340,7 +351,7 @@ For other direct-track repos, the train dispatches nothing centrally: a `registr
 event fires its own `publish.yml` (npm / plugin marketplace); a `solo-container` repo deploys via its own
 workflow. Publish the GitHub Release, then watch/report that repo's own release-triggered run.
 
-`mmi-cli release --apply --json` returns the relevant run id/url data with `deployStatus`; `--watch` blocks
+`mmi-cli devops release --apply --json` returns the relevant run id/url data with `deployStatus`; `--watch` blocks
 on the run(s) and resolves `deployStatus` to `success`/`failure`. For tenant-container repos, that is the
 dispatched `tenant-deploy.yml` run. For Hub serverless, that is the auto-fired release `deploy.yml` and
 `publish.yml` workflow pair — watched on `mutmutco/MMI-Hub`. For `registry-publish`, that is the target
@@ -369,7 +380,7 @@ deploy even when the train reported success — flag it loudly and fix it before
 
 **Hub releases announce to Slack (#883).** Hub scope is **only** `mutmutco/MMI-Hub`: the commits/PRs on
 `origin/main..origin/development`, this repo's `deploy.yml` + `publish.yml`, and Hub tooling (`mmi-cli`,
-skills, plugin, registry, central workflows). Do **not** read another repo's board (`mmi-cli board` / `/mmi`
+skills, plugin, registry, central workflows). Do **not** read another repo's board (`mmi-cli oracle board` / `/mmi`
 on a product), watch or dispatch `ds-propagate.yml`, run `design-system` / `doctor` design-system heals for
 consumers, or treat a product's deploy state as part of this release — those belong to that product's own
 `/release` or `/rcand`, never a Hub train.
@@ -384,7 +395,7 @@ Source from **Hub PR titles only** (`origin/main..origin/development` on `mutmut
 each line in neutral Hub-subsystem terms (CLI, skills, plugin, workflows, registry, deploy hub) — **never**
 a product or brand name (FoFu, Katip, etc.) anywhere in the summary file, Slack post, chat, or release
 report. Product names are allowed only when releasing **that product's repo**. Then pass the file through:
-`mmi-cli release --apply --announce-summary-file "$f"`. After the GitHub Release publishes, the CLI posts
+`mmi-cli devops release --apply --announce-summary-file "$f"`. After the GitHub Release publishes, the CLI posts
 the summary to the org alerts channel as the MMI-Future Slack app (token + channel from SSM at run time).
 For a new MMI-Hub `--apply`, the CLI refuses before promotion when the file is missing, unreadable, or does
 not contain 3–6 non-empty lines; generated-note fallback is not an agent release path. `--resume` never
@@ -396,8 +407,8 @@ never rolls back an otherwise completed release.
 info, branch alignment) while prod deploys. The verdict is collected in Step 6 — verification is not
 skipped, only un-blocked. Deploy failure → report plainly, then **retry the existing promoted ref by deploy
 model** once the runtime is repaired — never a re-tag or republish (`main` is already at the release, which is
-correct). Read the model from the registry (`mmi-cli org project get {owner}/{repo}` → `deployModel`):
-- **tenant-container** — the central tenant deployer owns the redeploy: `mmi-cli runtime tenant redeploy
+correct). Read the model from the registry (`mmi-cli oracle org project get {owner}/{repo}` → `deployModel`):
+- **tenant-container** — the central tenant deployer owns the redeploy: `mmi-cli devops runtime tenant redeploy
   {owner}/{repo} main --watch`.
 - **repository-owned serverless / registry-publish** (e.g. Jerv-PowerTools' `Deploy Jerv Memory`) — there is
   no `runtime tenant redeploy` for these; re-run the repo's OWN declared `workflow_dispatch` deploy workflow at
@@ -408,29 +419,29 @@ Name the sanctioned dispatch mechanism you used in the train report.
 ## Step 4b — re-sync project info (no in-repo docs pass)
 
 In-repo README/architecture freshness is **not** a train step (Step 0d retired, Hub#4164).
-`mmi-cli release --apply` re-syncs the GitHub **Project** short description + thin README from the
+`mmi-cli devops release --apply` re-syncs the GitHub **Project** short description + thin README from the
 released commit and the registry member list through the command ladder. For a manual repair or preview use:
 ```bash
-mmi-cli org project sync-info --apply   # omit --apply for the read-only plan
+mmi-cli oracle org project sync-info --apply   # omit --apply for the read-only plan
 ```
 
 ## Step 5 — roll development forward
 
-- Keep branches aligned: `mmi-cli release --apply` back-merges the released `main` (incl. the version
+- Keep branches aligned: `mmi-cli devops release --apply` back-merges the released `main` (incl. the version
   fold) into `development` and reports it as `devRollForward`. When `development` has no required checks it
   pushes directly (`status: pushed`). When `development` *requires* checks (e.g. MMI-Hub needs
   `cli`/`infra`/`docs`), the fresh merge commit carries no passing checks, so a direct push is structurally
   rejected — the train instead **opens an alignment PR** `main → development` (`status: pr-pending`) and the
   release report prints the exact land command. The release itself has already shipped; **land the alignment
-  PR with a true merge** — `mmi-cli pr merge <number> --auto --merge` (never squash — a squash drops the merge
+  PR with a true merge** — `mmi-cli devops pr merge <number> --auto --merge` (never squash — a squash drops the merge
   parentage and the misalignment guard re-flags the divergence). `--auto` is what makes it land right after a
   release: the alignment PR's own `cli`/`infra`/`docs` checks are still running, so a plain immediate merge is
   policy-blocked — `--auto` merges once they pass. Never force.
-- Full-track repos: `mmi-cli release --apply` already aligned `rc` to the released `main` (#1036 — the
+- Full-track repos: `mmi-cli devops release --apply` already aligned `rc` to the released `main` (#1036 — the
   push runs inside the authority-gated train; the result reports it as `rcAlignment`). No manual `rc`
   push — if the result reports a failed alignment, investigate and rerun via the train, never bare-push.
 - **Local branches never left stale (#2582).** A release advances `main`/`development`/`rc` on **origin**;
-  `mmi-cli release --apply` also fast-forwards the LOCAL train branches to match, so the checkout you
+  `mmi-cli devops release --apply` also fast-forwards the LOCAL train branches to match, so the checkout you
   released from does not lag what you just pushed. The train restores + fast-forwards the start branch
   (`checkout`, #2340) and fast-forwards the others (`localSync`) — non-destructively: only a true
   fast-forward moves a branch; a diverged local branch is reported and left untouched (never a force).
@@ -506,7 +517,7 @@ Hub's registry-declared npm surfaces are public today, so `release-distribution.
 **tenant-publish.yml E409 belt-and-braces (#2428).** The central `tenant-publish.yml` lane (the
 `publishRequired` companion publish only — never dispatched for `registry-publish`, see above) already
 treats a lost `npm publish` race as idempotent inside the run (a re-check `npm view` after a failed publish;
-see the workflow file). `mmi-cli release --apply --watch` mirrors that at the CLI layer: a watched
+see the workflow file). `mmi-cli devops release --apply --watch` mirrors that at the CLI layer: a watched
 `tenant-publish.yml` run that concludes `failure` is re-checked against that SAME run's own log (bounded
 retries, visibility-agnostic — never a bare `npm view`) for the idempotent-success marker before the CLI
 reports the publish as failed. A run whose log never shows the version landed stays a loud failure.
@@ -534,4 +545,4 @@ about? (Process only — never the user's code or task; e.g. a misleading author
 ambiguous version-fold or back-merge step.) If yes, file **one** lesson and move on; a clean run is silent
 (hard cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR — never
 edit the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill release --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill release --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/resume/SKILL.md

@@ -41,12 +41,12 @@ workspace identity the next step must use (for example `mutmutco/MMC-ZuberShade`
 ## Step 2 — the next move
 
 ```bash
-mmi-cli next --repo <repo reported by status>
+mmi-cli oracle next --repo <repo reported by status>
 ```
 
 Pass the repository from `status` explicitly; never reconstruct it by changing case or punctuation.
 `next` recommends the single most actionable claimable board item (unblocked, priority-ranked) and prints
-the exact `mmi-cli board claim <n>` to take it. Offer it; do not claim on the user's behalf without a go.
+the exact `mmi-cli oracle board claim <n>` to take it. Offer it; do not claim on the user's behalf without a go.
 For the full board partition (yours / claimable / taken) run `/mmi`.
 
 ## Step 3 — render, then stop
@@ -61,12 +61,12 @@ janitor prose. Catalog: `docs/Architecture/compute-at-read.md` (in MMI-Hub).
 
 | Ask | Verb |
 | --- | --- |
-| Schedules / harbour lanes | `mmi-cli org schedules` / `--json` |
-| Boxes / IPs | `mmi-cli runtime box list` |
-| Registry / projects | `mmi-cli org project list\|get` |
-| Board | `mmi-cli board read` / `mmi-cli next` |
-| Docs index freshness | `mmi-cli docs index --check` |
-| Path / symbol / meaning pointers | `mmi-cli repo-index search <q>` (Hub cloud; `--semantic` optional) |
+| Schedules / harbour lanes | `mmi-cli harbour org schedules` / `--json` |
+| Boxes / IPs | `mmi-cli devops runtime box list` |
+| Registry / projects | `mmi-cli oracle org project list\|get` |
+| Board | `mmi-cli oracle board read` / `mmi-cli oracle next` |
+| Docs index freshness | `mmi-cli oracle docs index --check` |
+| Path / symbol / meaning pointers | `mmi-cli oracle repo-index search <q>` (Hub cloud; `--semantic` optional) |
 
 ## Notes
 
@@ -81,4 +81,4 @@ about? (Process only — never the user's code or task; e.g. a self-check that r
 snapshot that named the wrong branch.) If yes, file **one** lesson and move on; a clean run is silent
 (hard cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR — never
 edit the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill resume --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill resume --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/secrets/SKILL.md

@@ -5,7 +5,7 @@ description: Manage the full own-project vault and granted org-infra secret name
 
 # /secrets — two-tier project secrets
 
-**Authority:** a project-admin self-serves their own product repo's full vault tree (`mmi-cli org access
+**Authority:** a project-admin self-serves their own product repo's full vault tree (`mmi-cli oracle org access
 role` → `project-admin` + `train`): stageless, `dev`, `rc`, and `main`. Do not redirect them to master for
 an own-project coordinate. Only org-infra grants and cross-project administration stay master-only.
 
@@ -22,11 +22,11 @@ SecureString + KMS, and **a value is never echoed to chat or logs**):
   project-admin).
 
 **Grant scope (#3652).** A grant is `rw` by default — it opens both keyless `use` and `set`/`rm` on that
-key. `mmi-cli secrets grant <repo> <login> <key> --read` grants **consume-only** reach: keyless `use`
+key. `mmi-cli vault secrets grant <repo> <login> <key> --read` grants **consume-only** reach: keyless `use`
 works, rotate and remove still refuse. Only a `--read` grant may name a **wildcard** key — `*` for the
 whole namespace, `<provider>/*` for one provider group — so "may read every crown jewel" is one grant
 instead of forty. A wildcard never confers write; asking for one as `rw` is refused, not narrowed.
-`mmi-cli org access capabilities` prints `grant (read)` or `grant (rw)` next to each name.
+`mmi-cli oracle org access capabilities` prints `grant (read)` or `grant (rw)` next to each name.
 
 A bare `<KEY>` is the **stageless canonical** at the slug root — one value every stage shares (#2244)
 and the path deploys resolve (#2523). A staged `dev/<KEY>` is a **per-stage override** and WINS for that
@@ -36,15 +36,15 @@ own-project `main/SECRET_KEY_BASE` or `rc/DB_URL` remains project-admin self-ser
 
 **Declare-first (#2528):** the registry catalog is the SSOT; SSM is a projection of it. A `set` to a
 coordinate not declared in the catalog is **rejected** — the error names the attempted path and the fix.
-Declare the key first via `mmi-cli org project set <owner/repo> --secrets-file <catalog.json>` (`stages: []`
+Declare the key first via `mmi-cli oracle org project set <owner/repo> --secrets-file <catalog.json>` (`stages: []`
 = the shared stageless canonical, `stages: ["dev"]` = a per-stage override), then retry. See what is
-declared with `mmi-cli secrets catalog` or `secrets list`; ask for a key you lack via `mmi-cli secrets
+declared with `mmi-cli vault secrets catalog` or `secrets list`; ask for a key you lack via `mmi-cli vault secrets
 request <KEY>`. There is no master bypass. `rm` of an undeclared path stays allowed, so cleanup keeps
 working. Google OAuth is one stageless pair per repo: bare `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET`
 at the slug root (the staged `{dev,rc,main}/GOOGLE_*` shape is retired; `org oauth set-creds` writes the
 bare keys).
 
-All ops run through `mmi-cli secrets …`, which calls the org backend with the caller's `gh` token; the
+All ops run through `mmi-cli vault secrets …`, which calls the org backend with the caller's `gh` token; the
 backend re-verifies **project-admin-of-this-repo** and the **vault namespace** server-side and does the scoped
 SSM op. This skill never touches AWS.
 
@@ -54,11 +54,11 @@ Read the current repo + slug; the tier of a key follows from its name (above). `
 exists and which ones **you** can manage (a `*`), never values.
 
 ```bash
-mmi-cli secrets list                 # names + tier + a * on the ones you can write. NEVER values.
+mmi-cli vault secrets list                 # names + tier + a * on the ones you can write. NEVER values.
 ```
 
 `secrets: no registry META` or `Hub API unreachable` → the repo is not registered with the Hub, GitHub auth
-is missing, or the Hub API is unavailable. Run `mmi-cli org project get <owner/repo>` to distinguish those cases;
+is missing, or the Hub API is unavailable. Run `mmi-cli oracle org project get <owner/repo>` to distinguish those cases;
 a master-admin backfills the registry before secrets can be resolved.
 
 ## Step 1 — the verb
@@ -68,17 +68,17 @@ Default to the **current repo**; pass `--repo owner/Name` to target another (you
 ```bash
 # CONSUME a secret keyless — injected into the command's env, NEVER printed (raw `secrets get` was
 # removed, the floor wins, #2844):
-mmi-cli secrets use SCRAPER_API_KEY -- <cmd>
+mmi-cli vault secrets use SCRAPER_API_KEY -- <cmd>
 
 # Write / rotate — the VALUE is read from stdin, NEVER an argument (so it can't leak into shell history
 # or process args). Pipe it in:
-printf %s "$THE_VALUE" | mmi-cli secrets set SCRAPER_API_KEY
+printf %s "$THE_VALUE" | mmi-cli vault secrets set SCRAPER_API_KEY
 
 # Validate a known provider key without printing its value:
-mmi-cli secrets verify RECALL_API_KEY
+mmi-cli vault secrets verify RECALL_API_KEY
 
 # Remove:
-mmi-cli secrets rm SCRAPER_API_KEY
+mmi-cli vault secrets rm SCRAPER_API_KEY
 ```
 
 **Never** pass a value as an argument (`secrets set KEY thevalue` is wrong — there is no value arg). The
@@ -89,7 +89,7 @@ confirmation prints the **name and tier only**, never the value.
 Before rotating, enumerate every copy of the key so no tier stays stale:
 
 ```bash
-mmi-cli secrets list --repo owner/Repo
+mmi-cli vault secrets list --repo owner/Repo
 ```
 
 Check the bare canonical plus any `dev/`, `rc/`, `main/` overrides the list shows. Rotate the provider-side
@@ -107,9 +107,9 @@ it). These verbs are **master-only** — the backend 403s anyone else.
 
 ```bash
 # MASTER: let @oguz-mut consume one _org provider key from their MM-Chat project
-mmi-cli secrets grant mutmutco/MM-Chat oguz-mut google/SOME_SHARED_KEY
+mmi-cli vault secrets grant mutmutco/MM-Chat oguz-mut google/SOME_SHARED_KEY
 # MASTER: withdraw it
-mmi-cli secrets revoke mutmutco/MM-Chat oguz-mut google/SOME_SHARED_KEY
+mmi-cli vault secrets revoke mutmutco/MM-Chat oguz-mut google/SOME_SHARED_KEY
 ```
 
 The master can also operate the org-infra key directly while guiding (master ⊇ project-admin). Org-infra
@@ -130,8 +130,8 @@ when they point at the same sandbox project; prod should stay distinct when the
 
 Sanctioned copy within the own-project vault (org-infra/cross-project sources remain master-gated):
 ```bash
-mmi-cli secrets copy --from rc --to dev --keys RECALL_API_KEY,GEMINI_API_KEY
-mmi-cli secrets copy --from rc --to dev --keys RECALL_API_KEY --dry-run   # plan only
+mmi-cli vault secrets copy --from rc --to dev --keys RECALL_API_KEY,GEMINI_API_KEY
+mmi-cli vault secrets copy --from rc --to dev --keys RECALL_API_KEY --dry-run   # plan only
 ```
 Prefer this over manual copy piping — audit-logged, blocklist enforced.
 
@@ -154,4 +154,4 @@ about? (Process only — never the user's code or task; e.g. a canonical-name or
 that risked echoing a value.) If yes, file **one** lesson and move on; a clean run is silent (hard cap:
 one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR — never edit the
 skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill secrets --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill secrets --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/stage/SKILL.md

@@ -148,4 +148,4 @@ about? (Process only — never the user's code or task; e.g. a teardown that lef
 Playwright output path aimed at the repo root.) If yes, file **one** lesson and move on; a clean run is
 silent (hard cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR —
 never edit the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill stage --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill stage --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/worktree/SKILL.md

@@ -42,8 +42,8 @@ open — never move it by hand.
 
 ```bash
 git push origin <branch>:<branch>              # explicit feature refspec — see below
-mmi-cli pr create --title "<title>" --body-file .jerv/PR_BODY.md --base development
-mmi-cli pr checks-wait <PR-number>              # wait for required CI to go green
+mmi-cli devops pr create --title "<title>" --body-file .jerv/PR_BODY.md --base development
+mmi-cli devops pr checks-wait <PR-number>              # wait for required CI to go green
 ```
 
 Write the PR body under `.jerv/` (#4405), never at the worktree root. `.jerv/` is the agent-artifact
@@ -57,9 +57,13 @@ share the push with staging or commit verbs in one compound command: the deny ap
 command, so a refused `git add … && git commit … && git push …` chain discards the add and commit
 with it. Stage, commit, and push as separate commands.
 
+If the branch adds, removes, or renames any `docs/` file, `pr create` refuses with a stale
+`docs/index.md` (#4092) — run `mmi-cli oracle docs index --write`, commit `docs/index.md`, and push again
+before retrying.
+
 ## Step 4 — land + clean up
 
-Under standing go (green CI, CI-gated PR) land to `development`. **Invoke `mmi-cli pr land` from the
+Under standing go (green CI, CI-gated PR) land to `development`. **Invoke `mmi-cli devops pr land` from the
 primary checkout** (or any cwd that is not the PR worktree) (#4549). Landing while cwd is still inside
 the worktree that cleanup removes can merge successfully and still exit 1 with
 `cleanupError: … Unable to read current working directory` — post-merge `gh`/`git` follow-ups then have
@@ -67,7 +71,7 @@ no readable cwd even when removal itself chdir'd away (#4140).
 
 ```bash
 cd <primary-checkout>   # e.g. the main MMI-Hub clone — not the slice worktree
-mmi-cli pr land <PR-number>
+mmi-cli devops pr land <PR-number>
 ```
 
 `pr land` waits for checks, squash-merges, and does the full cleanup at the branch boundary: removes the
@@ -101,6 +105,13 @@ that references that SHA in the message — do not pull the main commit into the
 This does not weaken the `#3167` merge floor on `/hotfix` and `/release` (never squash a tagged commit;
 alignment / roll-forward stays a true merge).
 
+**Stay-open phrasing (JC#495 / #3718):** GitHub's closing-keyword parser is negation-blind. `Does not
+close #N` still contains `close #N` and **closes the issue** on merge/squash (measured: Jerv-JervCode
+PR #493 closed #487). When an issue must stay open, never put `close`/`closes`/`fix`/`resolve` + `#N`
+in the PR body, commit message, or merge message — use `Part of #N`, `Refs #N`, or `leaves #N open` only.
+`mmi-cli devops pr create` rewrites common negated phrases; `pr land` / `pr merge` still refuse any remaining
+negation-blind close. `--force` only when those targets should actually close.
+
 If a PR already inherited closed-issue `Closes` keywords from that anti-pattern and `pr land` / `pr merge`
 refuses, land with `--force` only when those inherited targets are already closed — prefer preventing the
 pollution above over relying on `--force`.
@@ -110,8 +121,8 @@ pollution above over relying on `--force`.
 Record durable decisions on the issue or PR, then check the board again:
 
 ```bash
-mmi-cli wave status        # remaining worktrees, open PRs, local stages at a glance
-mmi-cli next               # the next actionable item
+mmi-cli oracle wave status        # remaining worktrees, open PRs, local stages at a glance
+mmi-cli oracle next               # the next actionable item
 ```
 
 ## Notes
@@ -133,4 +144,4 @@ about? (Process only — never the user's code or task; e.g. a create that branc
 land that left a worktree behind.) If yes, file **one** lesson and move on; a clean run is silent (hard
 cap: one per run). It lands on the Hub board (deduped) and is fixed only via a reviewed PR — never edit
 the skill live; the retro is advisory, so if the call fails, note it and continue:
-`mmi-cli skill-lesson --skill worktree --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+`mmi-cli learning skill-lesson --skill worktree --title "<what misfired>" --body "<what; evidence; proposed amendment>"`