rigjs 4.0.18 → 4.1.0

package/RIG_CICD_SKILL.md

@@ -0,0 +1,288 @@
+---
+name: rig-cicd
+description: >-
+  Agent skill for `rig build` / `rig deploy` / `rig publish` — rig's static-site CI/CD targeting Aliyun OSS + CDN. One OSS bucket serves many sites: each site is uploaded into its own subdirectory; CDN URI-rewrite rules (set by `rig publish`) map incoming `https://<domain>/...` to the right `oss://<bucket>/<deployDir>/...` path. Supports SPA hash, SPA history (BrowserRouter), MPA (one HTML per route), and any pre-built directory of HTML files. Trigger when the user wants to build/deploy/publish a web app via rig, debug a CDN rewrite, add a new endpoint or domain, switch web_type, or asks "rig 怎么部署" / "回源路径怎么改" / "一个 OSS 桶发多个站怎么配". Do NOT use for backend deploys, container registries, non-Aliyun providers (Huawei stub exists but isn't wired through), or package management (see rig-package).
+user-invocable: true
+disable-model-invocation: false
+metadata:
+  openclaw:
+    requires:
+      bins: [rig, git, yarn, node]
+    os: [darwin, linux]
+---
+
+# rig-cicd — agent operator's playbook
+
+## What this skill covers
+
+rig ships three CI/CD commands that share the `cicd` block of `package.rig.json5`:
+
+- `rig build [-s <schema>] [-p <params>] <dirPath>` — runs the per-endpoint build script with rig-injected variables (`publicPath`, `OUTPUT_DIR`, defines), then rewrites string tokens (`__RIG_PUBLIC_PATH__`, `__RIG_ENTRY_PATH__`, …) inside the built output. Output lands at `<source.root_path>/<deployDir>/`.
+- `rig deploy [-s <schema>] [-p <params>] <dirPath>` — uploads `<source.root_path>/<deployDir>/` to the configured OSS bucket. Sets `Cache-Control: no-cache` on `index.html`, `max-age=31536000` on `.js` / `.css` / `.ico`.
+- `rig publish [-s <schema>] [-p <params>] <dirPath>` — sets / updates Aliyun CDN **URI-rewrite** rules on each domain (this is what makes one bucket serve many sites), then refreshes the CDN cache.
+
+Typical pipeline: `rig build "<dir>" && rig deploy "<dir>" && rig publish "<dir>"`. Build and deploy can run independently; **publish is the only step that touches CDN config** — re-run it whenever you change `web_type`, `endpoints`, `target`, or rename a `deployDir`.
+
+The `<dirPath>` arg is a `/`-joined path matched against `tree_schema`. Use `%` as a wildcard and `%<group>` to reference a `groups[].name` (see `tree_schema` field below).
+
+## Topology — one OSS bucket, many sites
+
+A single OSS bucket holds every site:
+
+```
+oss://<bucket>/
+  app-a/
+    index.html
+    assets/...
+  app-b/
+    index.html
+    assets/...
+  marketing/
+    en/
+      index.html
+    zh/
+      index.html
+```
+
+For each public domain you serve, CDN holds a stack of **URI rewrite** rules that map the user-visible path to a real OSS object. Example for `app-a.example.com` running SPA history mode:
+
+| Match (incoming URI) | Rewrite to (origin path) | Purpose |
+|---|---|---|
+| `^/([^?]*\.[a-zA-Z0-9]+)($|\?)` | `/app-a/$1` | Any path ending in a file extension → that file under `app-a/` |
+| `^/([\w-/]*\w+)(?![^?]*\.\w+)` | `/app-a/index.html` | Any extensionless path → SPA entry under `app-a/` |
+| `^(/)($|\?|#|/\?|/$)` | `/app-a/index.html` | The web-entry path itself → SPA entry under `app-a/` |
+
+`rig publish` generates these rules deterministically from `cicd.web_type` + each endpoint's `deployDir`, calls Aliyun CDN's `SetCdnDomainConfig` with `enhance_break` (stop processing further rules once matched), waits for the rule status to flip to `success`, then calls `RefreshObjectCaches` on the touched URLs. Failure modes: 10-min config-apply timeout, 10-min refresh timeout. The `setRewriteUri` / `refreshCache` retry loops poll every 3 s up to 100 ticks.
+
+## `cicd` block — field reference
+
+Lives inside `package.rig.json5` alongside `dependencies`. Comments are JSON5-legal.
+
+```json5
+{
+  // ... dependencies block (see rig-package skill) ...
+
+  cicd: {
+    // tree_schema — REQUIRED. Slash-joined path schema describing the SHAPE of <dirPath> args.
+    //   Each segment is a "DirLevel". Examples:
+    //     'env/app'                          → two static segments: env, app.
+    //     'env/{vendor}'                     → second level is dynamic (param name 'vendor').
+    //     'env/%region/app'                  → second level uses a named group (see `groups`).
+    //   Aliases: `path_schema` (kept for back-compat).
+    tree_schema: 'env/app',
+
+    // web_type — OPTIONAL, default 'hash'. Drives the CDN rewrite rules `rig publish` generates.
+    //   'hash'    — SPA with hash routing (e.g. Vue Router hash mode, /#/foo).
+    //               Files are NOT prefixed with deployDir (the build embeds publicPath itself);
+    //               the only rule the publish step needs is "home → /<deployDir>/index.html".
+    //               Lets ONE domain serve MULTIPLE hash-mode SPAs at different entry paths
+    //               (/, /app1, /app2) because the runtime never asks the server for routes.
+    //   'history' — SPA with history routing (BrowserRouter / Vue Router history mode).
+    //               ALL extensionless paths → /<deployDir>/index.html (server falls through to SPA).
+    //               File-extension paths → /<deployDir>/<path>.
+    //   'mpa'     — Multi-Page App: one HTML per route. ALSO the right choice for "a pre-built
+    //               directory of HTML files" (e.g. a docs site, a hand-written static site,
+    //               a Next.js `next export` output).
+    //               Extensionless path /foo → /<deployDir>/foo.html.
+    //               File-extension path → /<deployDir>/<path>.
+    web_type: 'history',
+
+    // source — REQUIRED. Where rig reads the built artefacts from on the local filesystem.
+    source: {
+      // root_path — REQUIRED. Directory (relative to project root) that contains per-endpoint
+      //   subdirs after `rig build`. `rig deploy` walks <root_path>/<deployDir>/ and uploads
+      //   every file with the relative path used as the OSS object key.
+      root_path: 'dist',
+    },
+
+    // target — REQUIRED. One DeployTarget object OR an array (only the first is used today).
+    target: {
+      // id — REQUIRED. Free-form label, used in logs.
+      id: 'prod',
+
+      // type — REQUIRED. Cloud provider. Currently only 'alicloud' is wired through publish + deploy.
+      //   (A HuaweiDeploy.ts stub exists but is not connected to the publish path.)
+      type: 'alicloud',
+
+      // bucket / region / access_key / access_secret — REQUIRED. Aliyun OSS credentials.
+      //   The same credentials are reused for CDN API calls during `rig publish`.
+      //   NEVER inline real keys here — read from env (.env at project root) or the keychain and
+      //   inject via `-p key=value` or `${VAR}` substitution in the file.
+      bucket: 'my-site-bucket',
+      region: 'oss-cn-hangzhou',
+      access_key: '${ALIYUN_ACCESS_KEY}',
+      access_secret: '${ALIYUN_ACCESS_SECRET}',
+
+      // root_path / bucket_root_path — REQUIRED. OSS key prefix all uploads share. Use '/'
+      //   unless your bucket is shared with non-rig content.
+      root_path: '/',
+      bucket_root_path: '/',
+
+      // web_entry_path — OPTIONAL, default '/'. Fallback entry path when an endpoint omits its own.
+      //   Used only in hash mode (history/mpa always treat '/' as entry).
+      web_entry_path: '/',
+
+      // uri_rewrite — OPTIONAL. Manual override for the CDN rewrite step. When set (with
+      //   `original` or `original_regexp`), `rig publish` skips the auto-generated entry rule
+      //   for that endpoint and uses this one instead.
+      //   - original / original_regexp — the incoming URI to match. Pass a regex via
+      //     original_regexp; plain prefixes via original. Example: '/admin'.
+      //   - final — reserved, not consumed by publish today.
+      //   Use this only when you need a non-standard entry path (e.g. `/portal` instead of `/`)
+      //   on top of one of the three web_type modes.
+      uri_rewrite: undefined,
+    },
+
+    // endpoints — REQUIRED. Map keyed by the dir path that, when joined with `tree_schema`,
+    //   identifies one site to build/deploy/publish. Each value tells rig how to build it and
+    //   where to put it.
+    endpoints: {
+      // The key 'prod/app-a' fits a tree_schema of 'env/app' (two static segments).
+      'prod/app-a': {
+        // build — REQUIRED unless vue_env is set. Shell command rig runs to produce the bundle.
+        //   rig substitutes the following tokens in the string BEFORE exec:
+        //     $public_path / __PUBLIC_PATH__ / __RIG_PUBLIC_PATH__ → the deploy dir as URL path
+        //     __RIG_OUTPUT_DIR__                                  → <source.root_path>/<deployDir>
+        //   Use `__RIG_OUTPUT_DIR__` for `--outDir` / `--dest` flags so build output lands in
+        //   the right place. Output dir is also exported as the env var `OUTPUT_DIR` for the
+        //   child process (`PUBLIC_PATH` is exported too).
+        build: 'yarn vite build --base=__RIG_PUBLIC_PATH__ --outDir __RIG_OUTPUT_DIR__',
+
+        // vue_env — OPTIONAL. If set (e.g. 'prod'), rig generates a .env.rig file with
+        //   PUBLIC_PATH + OUTPUT_DIR + every key in `extra_env`, then defaults `build` to
+        //   `npx vue-cli-service build --mode rig --dest <OUTPUT_DIR>`. Use this with
+        //   vue-cli projects to skip writing a custom build string.
+        vue_env: undefined,
+
+        // extra_env — OPTIONAL. Extra env vars that should land in the per-build .env file when
+        //   vue_env is set. Also reachable from the build script via process.env.
+        extra_env: undefined,
+
+        // target — OPTIONAL. Free-form label that points back to a DeployTarget. Reserved for
+        //   future multi-target routing; today rig deploys/publishes to `cicd.target[0]`.
+        target: 'prod',
+
+        // domain / domains — REQUIRED. Public domain(s) the CDN rules will be set on.
+        //   `domains` is the canonical field (array, multi-domain). `domain` is the legacy
+        //   single-value field kept for back-compat. Use `domains`.
+        domains: ['app-a.example.com'],
+
+        // defines — OPTIONAL. String-replace map applied to every built .js / .ts / .html file
+        //   AFTER the build runs. Both keys and values are treated as plain strings. rig
+        //   pre-populates these for you:
+        //     __PUBLIC_PATH__       → the deploy dir as URL path
+        //     __DEPLOY_DIR__        → the deploy dir as URL path
+        //     __RIG_PUBLIC_PATH__   → same
+        //     __RIG_DEPLOY_DIR__    → same
+        //     __RIG_ENTRY_PATH__    → the endpoint's web_entry_path
+        //   The values you supply are themselves replaced for: $public_path, __PUBLIC_PATH__,
+        //   __RIG_PUBLIC_PATH__, __DOMAIN__, __RIG_DOMAIN__ before they are substituted into
+        //   files. Useful for bundling absolute API URLs that depend on the deploy domain.
+        defines: {
+          __API_BASE__: 'https://api.__RIG_DOMAIN__',
+        },
+
+        // web_entry_path — OPTIONAL. Where the SPA mounts in hash mode. Default '/'. Lets you
+        //   put two hash-mode SPAs on one domain at /, /portal, etc. Ignored when
+        //   web_type='history' or 'mpa' (those always use '/').
+        web_entry_path: '/',
+
+        // uri_rewrite — OPTIONAL per-endpoint override (same shape as target.uri_rewrite above).
+        //   When set, suppresses the auto-generated entry rule for this endpoint only.
+        uri_rewrite: undefined,
+      },
+
+      'prod/app-b': {
+        build: 'yarn build --base=__RIG_PUBLIC_PATH__ --outDir __RIG_OUTPUT_DIR__',
+        domains: ['app-b.example.com'],
+      },
+    },
+
+    // groups — OPTIONAL. Named bundles of values for one dynamic level of tree_schema.
+    //   Lets `rig build env/%region/app` expand across many regions. Each group:
+    //   - name      Used in <dirPath> as `%<name>`. MUST start with `%`.
+    //   - level     The DirLevel name (segment of tree_schema, without `{}`).
+    //   - includes  Allowed values for that level. Endpoints whose actual dir value is not in
+    //               `includes` are skipped during build/deploy/publish.
+    groups: [
+      { name: '%apac', level: 'region', includes: ['cn', 'jp', 'sg'] },
+    ],
+  },
+}
+```
+
+### `<dirPath>` matching rules (read before debugging "no endpoints matched")
+
+`tree_schema` declares the shape; `<dirPath>` selects which endpoints to act on:
+
+- `prod/app-a` — exact match. Only the `prod/app-a` endpoint runs.
+- `prod/%` — wildcard at level 2. All endpoints whose first segment is `prod` AND whose level 2 is **dynamic** (declared as `{...}` in `tree_schema`) match.
+- `%/app-a` — wildcard at level 1. Only endpoints whose second segment equals `app-a`.
+- `prod/%apac/app` — group wildcard. Iterates `groups['%apac'].includes` and picks endpoints whose level-2 value is in `['cn','jp','sg']`. (Requires `tree_schema` to have THREE segments.)
+- Extra trailing segments past `tree_schema.length` are appended to each matching endpoint's `deployDir`. E.g. with `tree_schema: 'env/app'` and `<dirPath>: 'prod/app-a/v2'`, the endpoint `prod/app-a` gets deployed to `<bucket>/prod/app-a/v2/`. This lets you push the same code under a versioned subpath without editing `endpoints`.
+
+`-p key=value` and `-s key=value` further substitute `${key}` (in the JSON5 file) and `{key}` (inside `<dirPath>`) at run time. Use them for branch/PR/env scoping in CI.
+
+## Intent → command map
+
+| User intent | Action |
+|---|---|
+| "build everything for prod" | `rig build "prod"` (matches every endpoint whose first segment is `prod` if level 2 is dynamic, or just one if it's static). Verify the dist tree exists at `<source.root_path>/<deployDir>/` before deploying. |
+| "build + deploy + publish one site" | `rig build "<dirPath>"` → `rig deploy "<dirPath>"` → `rig publish "<dirPath>"`. Publish is the slow one (CDN-config apply 30 s – minutes; cache refresh another minute). |
+| "I changed web_type / endpoints / deployDir" | Re-run `rig publish "<dirPath>"` on every affected endpoint. Build + deploy alone do NOT update CDN rules. |
+| "the site is showing the WRONG site" | Two suspects: (1) CDN rewrite rule is wrong — check Aliyun console → CDN domain → 配置 → 高级配置 → URI 改写; expect a rule per row matching the table in the topology section. (2) The OSS object isn't where you think — `aliyun oss ls oss://<bucket>/<deployDir>/`. Confirm `index.html` exists. |
+| "404 on a deep route in history mode" | CDN rewrite rules missing the `^/([\w-/]*\w+)(?![^?]*\.\w+)` → `/<deployDir>/index.html` rule. Re-run `rig publish` to regenerate. |
+| "404 on a deep route in MPA mode" | Means the matching `.html` file does not exist in OSS. The MPA rewrite is `/foo` → `/<deployDir>/foo.html` — your build must emit `foo.html`. If it emits `foo/index.html`, switch web_type or change the rewrite via `target.uri_rewrite`. |
+| "rebuild publicPath was wrong, hash mode" | rig injects `__RIG_PUBLIC_PATH__` / `__PUBLIC_PATH__` and the `PUBLIC_PATH` env var. Use one of them in the bundler config (`vite --base`, Vue CLI `publicPath`, webpack `output.publicPath`). hash mode does NOT prefix OSS path with deployDir at the CDN layer — the bundle has to know its own deploy dir at build time. |
+| "want a new domain on an existing site" | Add to the endpoint's `domains` array. Re-run `rig publish` (no rebuild needed). |
+| "want one OSS bucket for two completely different sites" | That's the default model. Two endpoints with different `deployDir`s and different `domains`. `rig publish` writes per-domain rewrite stacks; the bucket is shared. |
+| "deploy a pre-built static dir (docs site, hand-written HTML)" | Set `web_type: 'mpa'`. Point `endpoints.<dir>.build` at whatever produces the dir (or a no-op like `cp -r src/site dist/<deployDir>` if there's nothing to build). The MPA rewrite handles both `/about` → `/about.html` and `/img.png` → `/img.png`. |
+| "credentials in package.rig.json5 — is that OK?" | NO. Use `${VAR}` interpolation or `-p key=value` and store the real values in env / keychain. Anything committed is shared with everyone who clones. |
+
+## How it works under the hood
+
+`rig build` (lib/build/index.ts):
+1. Load `cicd` block; create `CICD` (parses `tree_schema` into `DirLevel[]`, builds an `Endpoint[]`).
+2. Create `CICDCmd` from the `<dirPath>` arg — filters endpoints by `matchCmd()`, appends extra trailing path segments to each surviving endpoint's `deployDir` / `publicPath`.
+3. For each surviving endpoint:
+   - Replace `$public_path`, `__PUBLIC_PATH__`, `__RIG_PUBLIC_PATH__`, `__DOMAIN__`, `__RIG_DOMAIN__` in `defines`.
+   - If `vue_env`, write `.env.rig` (via `lib/env`), default the `build` string if missing.
+   - Replace `$public_path`, `__RIG_OUTPUT_DIR__` in `build`. shelljs.exec.
+   - Walk the output dir; replace every `defines` key in every `.js` / `.ts` / `.html` file.
+
+`rig deploy` (lib/deploy/index.ts):
+1. Same `CICD` / `CICDCmd` setup.
+2. For each endpoint: walk `<root_path>/<deployDir>/` recursively, upload every file via `ali-oss`'s `putStream` with the relative path as OSS key. `index.html` → `Cache-Control: no-cache`; `.js`/`.css`/`.ico` → `max-age=31536000`. Everything else uses bucket default.
+
+`rig publish` (lib/publish/index.ts):
+1. Same `CICD` / `CICDCmd` setup.
+2. Group rewrite rules by **domain** (a domain can host multiple endpoints — uncommon but supported).
+3. For each domain, build the rewrite stack from `web_type`:
+   - `hash`: only the file-extension passthrough `/<file>` → `/<file>` (no deployDir prefix — bundle is built with publicPath baked in) plus the entry rule (`/` or `web_entry_path` → `/<deployDir>/index.html`).
+   - `history`: file-extension paths → `/<deployDir>/<path>`; everything else → `/<deployDir>/index.html`.
+   - `mpa`: file-extension paths → `/<deployDir>/<path>`; extensionless paths → `/<deployDir>/<path>.html`; entry rule for `/`.
+   - If endpoint or target supplies `uri_rewrite`, only the file-extension rule + the custom entry are emitted (no auto extensionless rule). Useful for irregular sites mounted at non-root paths.
+4. Call `cdn.setRewriteUri(domain, originals, deployDirs, ['enhance_break'])`. Poll `describeCdnDomainConfigs` every 3 s; succeed when all configs reach `Status: success`; fail on any `Status: failed` or after 100 ticks.
+5. Call `cdn.refreshCache(urls.join('\n'))` on every touched entry URL. Poll `describeRefreshTaskById` the same way.
+
+### Order matters when re-running publish
+
+`SetCdnDomainConfig` appends rules — it does NOT replace the existing stack. If you change `deployDir` for an endpoint and re-publish, **both the old and new rules are now active**, and Aliyun evaluates the **first match wins** (the `enhance_break` action stops the chain). The old rule may shadow the new one. Cleanup steps:
+
+1. Aliyun console → CDN → domain → 配置 → 高级配置 → URI 改写 → delete obsolete rules manually, OR
+2. Use Aliyun's `BatchDeleteCdnDomainConfig` API if you script it (rig has no built-in cleanup today — surface this as a known gap when migrating endpoints).
+
+## What rig CI/CD does NOT do
+
+- **No non-Aliyun providers.** `HuaweiDeploy.ts` exists but is not wired into publish; CloudFront / Fastly / Cloudflare are out of scope.
+- **No backend deploy.** Container images, lambdas, server bundles — find another tool.
+- **No environment promotion ladder.** rig has no notion of "promote from staging → prod". Use distinct `tree_schema` segments (`env`) and run publish per env.
+- **No rule cleanup.** Renaming a `deployDir` leaves orphan CDN rules pointing at the old path. Delete by hand.
+- **No publish-time secret scanning.** Don't commit credentials into `package.rig.json5`; the deploy pipeline will happily ship them.
+
+## Reporting & cleanup checklist (after non-trivial changes)
+
+- After `rig build`: confirm `<source.root_path>/<deployDir>/index.html` exists for every targeted endpoint.
+- After `rig deploy`: spot-check OSS with `aliyun oss ls oss://<bucket>/<deployDir>/`.
+- After `rig publish`: open `https://<domain><web_entry_path>` and a deep route; both should respond 200 with the expected content. Cache may take another 30 s to settle even after the refresh task reports `Complete`.
+- When migrating `web_type`, list every endpoint that was on the old type and re-publish each one — the rewrite stack is per-domain, not per-endpoint.

package/RIG_CREW_SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: rig-crew
 description: >-
-  Agent-facing Leader-first multi-agent workflow over an Obsidian vault using
-  `rig crew`. Use when the current coding agent should initialize a crew vault,
-  refresh a human-readable dashboard, inspect inbox/status, register project
+  Agent-facing Orchestrator-first multi-agent workflow over an Obsidian vault using
+  `rig orchestrate` (alias: `rig crew`). Use when the current coding agent should initialize a crew vault,
+  refresh a human-readable dashboard, inspect pending-questions/status, register project
   owners, or coordinate PRD-driven project work through Vault files.
   For frontend testing, default to PRD-scoped Playwright E2E only: do not add
   or run frontend unit/integration tests unless the user or project explicitly
@@ -19,46 +19,46 @@ metadata:
 
 # rig-crew
 
-Use this skill when the current coding agent is inside or coordinating an Obsidian Vault that uses `rig crew`: a file-backed, Leader-first agent workflow using Obsidian Markdown as the source of truth.
+Use this skill when the current coding agent is inside or coordinating an Obsidian Vault that uses `rig orchestrate` (alias: `rig crew`): a file-backed, Orchestrator-first agent workflow using Obsidian Markdown as the source of truth.
 
-`rig crew` is primarily for coding agents, not a human-operated daily CLI. The human talks to the active Claude/Codex session; that coding agent should use `rig crew` commands and Vault files to communicate with Crew Lead, coordinate other roles, and stay aware of all agent/todo status.
+`rig orchestrate` is primarily for coding agents, not a human-operated daily CLI. The human talks to the active Claude/Codex session; that coding agent should use `rig orchestrate` commands and Vault files to communicate with the Orchestrator, coordinate other roles, and stay aware of all agent/todo status.
 
 ## Agent Quickstart
 
 ```bash
-rig crew init --vault "/path/to/ObsidianVault" --as personal
-rig crew "推进当前目标"
-rig crew role add security-reviewer --from ./security-reviewer.md --agent security-reviewer --executor codex
-rig crew research "比较 Playwright agents 的最佳实践"
-rig crew inbox
-rig crew board
-rig crew status
+rig orchestrate init --vault "/path/to/ObsidianVault" --as personal
+rig orchestrate "推进当前目标"
+rig orchestrate role add security-reviewer --from ./security-reviewer.md --agent security-reviewer --executor codex
+rig orchestrate research "比较 Playwright agents 的最佳实践"
+rig orchestrate pending-questions
+rig orchestrate board
+rig orchestrate status
 ```
 
 Project Owner management:
 
 ```bash
-rig crew project add rig --path /path/to/projects/rig --executor claude --test-command "yarn build"
-rig crew project add dsh-service --path /path/to/projects/dsh-service --executor codex --test-command "yarn test"
-rig crew project add demo-web --path /path/to/ObsidianVault/tmp/demo-web --executor codex
-rig crew project sync
-rig crew project list
-rig crew project status rig
+rig orchestrate project add rig --path /path/to/projects/rig --executor claude --test-command "yarn build"
+rig orchestrate project add dsh-service --path /path/to/projects/dsh-service --executor codex --test-command "yarn test"
+rig orchestrate project add demo-web --path /path/to/ObsidianVault/tmp/demo-web --executor codex
+rig orchestrate project sync
+rig orchestrate project list
+rig orchestrate project status rig
 ```
 
-Use `rig crew project sync` after directories are added to or removed from the Vault `projects/` folder. It refreshes the active Project Owner registry and project-scoped agent task folders under `<crew-root>/Projects/`.
+Use `rig orchestrate project sync` after directories are added to or removed from the Vault `projects/` folder. It refreshes the active Project Owner registry and project-scoped agent task folders under `<crew-root>/Projects/`.
 
 ## State Model
 
-`rig crew` is file-backed. Do not assume a long-running multi-agent runtime exists.
+`rig orchestrate` is file-backed. Do not assume a long-running multi-agent runtime exists.
 
-- Default crew root: `rig-agents/`
-- Vault source of truth: `rig-agents/**` by default, or the configured `crew.root`.
+- Default crew root: `rig-crew/`
+- Vault source of truth: `rig-crew/**` by default, or the configured `crew.root`.
 - Vault-local scratch projects: `tmp/<project>/**`
-- Human dashboard: `<crew-root>/Team-Dashboard.md`
-- User decisions: `<crew-root>/Inbox.md`
+- Human dashboard: `<crew-root>/Dashboard.md`
+- User decisions: `<crew-root>/Pending-Questions.md`
 - Shared context: `<crew-root>/Shared/**`
-- Role registry for Lead: `<crew-root>/Shared/Roles.md`
+- Role registry for the Orchestrator: `<crew-root>/Shared/Roles.md`
 - Project owner memory: `<crew-root>/Projects/<project>/**`
 - Project-scoped agent tasks: `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md`
 - Large active task batches: `<crew-root>/Projects/<project>/Tasklists/active/*.md` and `<crew-root>/Projects/<project>/Agents/<role>/Tasklists/active/*.md`
@@ -71,9 +71,9 @@ Use `rig crew project sync` after directories are added to or removed from the V
 
 All multi-agent collaboration materials should live inside the Vault. Temporary demo or test projects should be created under `Vault/tmp/<project>` and registered with their own Project Owner.
 
-`rig crew` coordinates multiple roles on one device through one Vault. Do not assume a separate multi-agent runtime inside each project repository; project directories are execution workspaces, while tasks, reports, inbox, dashboard, and research indexes return to the Vault.
+`rig orchestrate` coordinates multiple roles on one device through one Vault. Do not assume a separate multi-agent runtime inside each project repository; project directories are execution workspaces, while tasks, reports, inbox, dashboard, and research indexes return to the Vault.
 
-`rig crew init` is additive and non-destructive. It may create missing folders/files and update managed blocks, but it must not overwrite existing agent work files such as project `Tasks.md`, `Role.md`, `Index.md`, reports, specs, decisions, or user-authored notes.
+`rig orchestrate init` is additive and non-destructive. It may create missing folders/files and update managed blocks, but it must not overwrite existing agent work files such as project `Tasks.md`, `Role.md`, `Index.md`, reports, specs, decisions, or user-authored notes.
 
 Built-in role directories are reusable role cards, not project task queues. Concrete PM/Coder/Tester/etc work should be assigned under a specific project:
 
@@ -92,16 +92,16 @@ Keep each `Tasks.md` small. Use it as a current queue or index, not an unlimited
 
 Move completed or stale batches to `Tasklists/archive/YYYY-MM.md`. The active dashboard scans `Tasks.md` and `Tasklists/active/**/*.md`; it does not scan archive files by default.
 
-## Lead Orchestration
+## Orchestrator
 
-Lead is the default orchestration protocol, not a mandatory Claude/Codex subagent.
+The Orchestrator is the default orchestration protocol, not a mandatory Claude/Codex subagent.
 
-As the coding agent, use `rig crew "<request>"` when the user asks for planning, multi-agent coordination, PRD, research, testing strategy, owner routing, role routing, reports, or broad project changes. Do not ask the human to run the command when you can run it yourself.
+As the coding agent, use `rig orchestrate "<request>"` when the user asks for planning, multi-agent coordination, PRD, research, testing strategy, owner routing, role routing, reports, or broad project changes. Do not ask the human to run the command when you can run it yourself.
 
 After handoff, read:
 
-- `<crew-root>/Team-Dashboard.md`
-- `<crew-root>/Inbox.md`
+- `<crew-root>/Dashboard.md`
+- `<crew-root>/Pending-Questions.md`
 - `<crew-root>/Shared/Roles.md`
 - relevant `<crew-root>/Projects/<project>/Tasks.md`
 - relevant `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md`
@@ -112,15 +112,15 @@ If the CLI is unavailable, use the file protocol:
 1. Append the request to `<crew-root>/Current-Goal.md`.
 2. When a project is known, create or update small/current work in `<crew-root>/Projects/<project>/Tasks.md` or `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md`; split larger batches into `Tasklists/active/<feature-or-iteration>.md`.
 3. Route worker tasks with inline fields such as `[role:: tester]`, `[owner:: maintainer:rig]`, `[project:: rig]`, `[executor:: codex]`, `[status:: pending]`.
-4. Put user-facing questions or approvals in `<crew-root>/Inbox.md`.
+4. Put user-facing questions or approvals in `<crew-root>/Pending-Questions.md`.
 
-Lead communicates with workers through Markdown tasks, delegation packets, and result notes. Do not rely on private subagent chat state as the coordination source of truth. Subagents are optional executors for specific roles when the selected executor supports them; Vault files remain canonical.
+The Orchestrator communicates with workers through Markdown tasks, delegation packets, and result notes. Do not rely on private subagent chat state as the coordination source of truth. Subagents are optional executors for specific roles when the selected executor supports them; Vault files remain canonical.
 
 Maintain status awareness before and after work: scan dashboard, inbox, project owner tasks, project-scoped agent tasks, active tasklists, blockers, and todo status. The coding session should be able to answer what each role/project is doing without asking the human to inspect the Vault manually.
 
 ## Mixed Executors
 
-`rig crew` can mix Claude Code, Codex, and future executors because state lives in files, not in one long-running agent process.
+`rig orchestrate` can mix Claude Code, Codex, and future executors because state lives in files, not in one long-running agent process.
 
 Executor selection order:
 
@@ -133,11 +133,11 @@ Executor selection order:
 Use project-level executors when teams prefer different coding agents per repo:
 
 ```bash
-rig crew project add rig --path /path/to/projects/rig --executor claude
-rig crew project add dsh-service --path /path/to/projects/dsh-service --executor codex
+rig orchestrate project add rig --path /path/to/projects/rig --executor claude
+rig orchestrate project add dsh-service --path /path/to/projects/dsh-service --executor codex
 ```
 
-The executor only affects code-running / project-local work. Vault Markdown updates should still be written by the `rig crew` host so Claude and Codex share the same source of truth.
+The executor only affects code-running / project-local work. Vault Markdown updates should still be written by the `rig orchestrate` host so Claude and Codex share the same source of truth.
 
 ## Custom Roles
 
@@ -158,10 +158,10 @@ Directory layout:
 Commands:
 
 ```bash
-rig crew role add security-reviewer --from ./security-reviewer.md --agent security-reviewer --executor codex
-rig crew role add security-reviewer --from ./security-reviewer.md --agent security-reviewer --executor codex --crew personal
-rig crew role list
-rig crew role show security-reviewer
+rig orchestrate role add security-reviewer --from ./security-reviewer.md --agent security-reviewer --executor codex
+rig orchestrate role add security-reviewer --from ./security-reviewer.md --agent security-reviewer --executor codex --crew personal
+rig orchestrate role list
+rig orchestrate role show security-reviewer
 ```
 
 When a role is materialized in a Vault, use:
@@ -174,7 +174,7 @@ When a role is materialized in a Vault, use:
 
 Built-in roles use `<crew-root>/<Role>/Role.md`. These role files are short editable descriptions. Do not use them as normal task queues.
 
-`<crew-root>/Shared/Roles.md` is generated so Lead can load available roles. If the user asks Lead to use a specific role, match that role by `name` first, then route the task into `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md` with `[role:: <name>]`. If the role defines `agent`, use that agent/subagent for role execution when the executor supports it.
+`<crew-root>/Shared/Roles.md` is generated so the Orchestrator can load available roles. If the user asks the Orchestrator to use a specific role, match that role by `name` first, then route the task into `<crew-root>/Projects/<project>/Agents/<role>/Tasks.md` with `[role:: <name>]`. If the role defines `agent`, use that agent/subagent for role execution when the executor supports it.
 
 ## Researcher
 
@@ -201,13 +201,13 @@ Recommended `~/.rig/RIG.md` section:
 | project:<name> | <crew-root>/Projects/<name>/Research | Project-specific research notes |
 ```
 
-If the destination is unclear, create or ask Lead to create an Inbox question instead of guessing. When a report is written outside `<crew-root>/Researcher/Reports`, keep an index entry in `<crew-root>/Researcher/Index.md`.
+If the destination is unclear, create or ask the Orchestrator to create a Pending-Questions entry instead of guessing. When a report is written outside `<crew-root>/Researcher/Reports`, keep an index entry in `<crew-root>/Researcher/Index.md`.
 
 ## Rules Files
 
 Read rules in this order:
 
-1. Vault agent rules: `CLAUDE.md` and `AGENTS.md` at the Vault root. `rig crew init` maintains a managed `rig-crew` block in both files.
+1. Vault agent rules: `CLAUDE.md` and `AGENTS.md` at the Vault root. `rig orchestrate init` maintains a managed `rig-crew` block in both files.
 2. Project rules: `projects/<project>/RIG.md` (also accept `rig.md` for compatibility).
 3. Project testing guide: `docs/testing.md`, `test/README.md`, or `tests/README.md`.
 4. User rules: `~/.rig/RIG.md`.
@@ -225,7 +225,7 @@ For frontend/UI behavior:
 - Use PRD-scoped Playwright E2E as the default and preferred test type.
 - Do not add frontend unit tests by default.
 - Do not add frontend integration tests by default.
-- Do not run old frontend unit/integration suites as part of normal `rig crew` verification.
+- Do not run old frontend unit/integration suites as part of normal `rig orchestrate` verification.
 - Do not run the full historical E2E suite unless risk requires it.
 
 Default frontend verification is:
@@ -235,7 +235,7 @@ PM PRD / Acceptance Criteria
 -> Tester creates current Test Scope
 -> Playwright planner/generator creates or updates focused E2E
 -> Tester runs only current PRD E2E + minimal smoke
--> Lead reports what was run and what was intentionally skipped
+-> The Orchestrator reports what was run and what was intentionally skipped
 ```
 
 Run full regression only when:
@@ -243,7 +243,7 @@ Run full regression only when:
 - Project Owner asks for it.
 - The change touches auth, routing, shared layout, build config, data migration, checkout/payment, or release flow.
 - Focused PRD E2E cannot cover the risk.
-- Lead marks the task `risk: high`.
+- The Orchestrator marks the task `risk: high`.
 
 Tester reports must include:
 
@@ -291,7 +291,7 @@ yarn playwright test --project=chromium-production --grep @prod-readonly --trace
 - Do not run a separate multi-agent state machine inside a project repo; coordinate through one local Vault.
 - Do not store custom role prompts in project repos; use `~/.rig/crew/roles/<role>/`.
 - Do not overwrite unrelated Vault `CLAUDE.md` / `AGENTS.md` content; update only the managed `rig-crew` block.
-- Do not overwrite existing agent work files on repeated `rig crew init`; only create missing files or update explicit managed blocks.
+- Do not overwrite existing agent work files on repeated `rig orchestrate init`; only create missing files or update explicit managed blocks.
 - Researcher reports default to Vault paths configured in `~/.rig/RIG.md`.
 - For frontend testing, prefer one high-value PRD E2E over many low-signal unit/integration tests.
-- If a required account alias is missing, run or recommend `rig crew doctor`; do not guess credentials.
+- If a required account alias is missing, run or recommend `rig orchestrate doctor`; do not guess credentials.