@mutmutco/pi-plugin 4.5.173 → 4.5.175

package/package.json

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

package/skills/board/SKILL.md

@@ -5,11 +5,9 @@ description: Show the repo workboard and clear it in the fewest PRs.
 
 # /board — your workboard, and the fastest way through it
 
-Two halves. The first shows a dev their board for this repo — what they hold, what is free, what others
-took. The second is the reason this skill exists: plan the whole board into the **fewest pull requests**
-that can safely be opened, then run those lanes in parallel.
-
-Read-only until the dev says go. Rendering a board is not permission to take it.
+Show the dev their board for this repo, then plan the whole board into the **fewest pull requests** that can
+safely be opened and run those lanes in parallel. Read-only until the dev says go; rendering is not
+permission to take anything.
 
 ## Step 1 — read the board
 
@@ -17,138 +15,71 @@ Read-only until the dev says go. Rendering a board is not permission to take it.
 mmi-cli oracle board read --json --out .jerv/tmp/board.json
 ```
 
-Prefer `--out` for a shell-independent UTF-8 receipt. Windows PowerShell 5.1's `>` writes
-UTF-16LE with a BOM (#5802); Bash redirects preserve the CLI's UTF-8 output.
-
-One call. Its JSON carries `viewer`, `repo` and the project title — do not spend extra calls on
-`gh api user` or `gh repo view`. Use `primary` for this repo and `secondary` for other repos on the same
-Project. Partial reads exit nonzero; pass `--allow-partial` only when the dev accepts an incomplete board.
-
-Partition, as the CLI computes it:
-
-- **Yours** — assignee includes the viewer, status in `Todo · In Progress · In Review`.
-- **Free to claim** — status `Todo`, unassigned, and the viewer has push on the repo. Also any item in
-  any status whose claim stamp is stale: its session has done no work on it for 4 hours. A stale stamp
-  holds nothing; `board claim` takes it over without `--force` and names the old stamp.
-- **Taken** — someone else's, any active status.
-
-Every stamped row names its session (`lane surface/session@host`), or `stale:<age>` when the stamp is
-stale. Work means the stamp, an issue comment, a commit on the issue's branch, or an update to an open
-PR that closes it. Any of these in the last 4 hours keeps the hold; a date that cannot be read counts as
-work. A takeover keeps the old branch and PR and names them, so the new session continues them.
+One call; the JSON carries `viewer`, `repo` and the project title. Use `primary` for this repo and
+`secondary` for other repos on the Project. Partial reads exit nonzero; `--allow-partial` only when the dev
+accepts an incomplete board. The CLI partitions rows into **Yours**, **Free to claim** and **Taken**; stale
+stamps (4 hours without work) hold nothing. Partition rules, stamp details and `--out` rationale:
+[reference.md](reference.md).
 
 ## Step 2 — render it
 
 Plain markdown, never a fenced block. Flat `-` lists under bold heads, never `##` headings, never tables.
-Refs are `[RepoName#N](url) · short title` — no `owner/` prefix, no `[type]` brackets, title trimmed to
-its essence. **Taken** renders id · status · owner only, never the title. Skip empty sections silently.
-One screen.
-
-For a rendering example, read [examples.md](examples.md).
+Refs are `[RepoName#N](url) · short title`, no `owner/` prefix, no `[type]` brackets. **Taken** renders
+id · status · owner only, never the title. Skip empty sections. One screen. Example: [examples.md](examples.md).
 
-Status moves happen automatically as work flows — claim, PR open, merge. Never offer a status move.
+Status moves happen automatically as work flows. Never offer a status move.
 
 ## Step 3 — plan the fewest PRs
 
-This is the aggressive half. Do not offer one item at a time and do not default to one PR per issue.
-
-Fetch the material you need to group by:
+Never one item at a time, never one PR per issue. Fetch bodies:
 
 ```bash
 mmi-cli oracle board read --json --bodies --out .jerv/tmp/board-full.json
 ```
 
-`--bodies` fetches body and comments for every scoped issue. In the JSON, read them at
-`row.details.body` and `row.details.comments` — not `row.body` or `row.comments`. `--bundle-details` is
-the cheaper variant that covers only `userOwned` and `claimable` — prefer it when the plan is limited
-to claimable work. `taken` stays metadata-only either way. Do not fetch Done items.
-
-Then build the plan:
-
-1. **Derive each issue's touch-set** — the files and directories it will change, read from the body,
-   its comments and its `surface:*` label. An issue whose touch-set you cannot name is not plannable;
-   leave it out of the batch and say so.
-2. **Join issues whose touch-sets overlap.** Follow the overlap transitively: if A and B share a file and
-   B and C share another, all three are one group. Each resulting group is one worktree and **one PR**.
-3. **Groups are disjoint by construction**, so every group runs in parallel with no worktree contention.
-   That is the whole trick — the number of groups is the number of PRs, and it is the smallest number
-   reachable without two PRs fighting over the same file.
-
-Forced splits — these override the grouping and each takes its own PR:
-
-- **Another repo.** Never bundle across repos. Board advance is per-repo and deliberately refuses to move
-  another repo's issue, so a cross-repo bundle lands the code and leaves those issues stranded open.
-- **Irreversible or gated work** — migrations, secret rotation, release-train changes. Bundling hides them.
-- **An issue that must stay open** (HOLD, prep, partial delivery).
-- **Review size.** A PR no one can review is not cheap. When a group grows past roughly ten issues or
-  spans unrelated subsystems, cut it at its weakest overlap and take two PRs.
+(Bodies and comments are at `row.details.body` and `row.details.comments`. Skip Done.)
 
-Present the plan before touching anything — batch count, issue count, and one line per batch naming its
-shared surface. Then stop and wait.
+1. **Derive each issue's touch-set** from body, comments and `surface:*` label. If you cannot name it, leave
+   the issue out and say so.
+2. **Join overlapping touch-sets**, transitively. Each group is one worktree and **one PR**; groups are
+   disjoint, so all run in parallel.
 
-> Nine claimable, three PRs: **A** #6395–#6397 board routing · **B** #6398–#6401 train doctor heal ·
-> **C** #6402–#6403 CLI flag validation. Say go and I'll run all three in parallel.
+Forced splits, each its own PR: another repo; irreversible or gated work (migrations, secret rotation,
+release-train changes; principle 12); an issue that must stay open; a group past roughly ten issues or
+spanning unrelated subsystems. Reasons: [reference.md](reference.md).
 
-## Step 4 — on the dev's go, claim and run
+Present the plan — batch count, issue count, one line per batch naming its shared surface — then wait for go.
 
-Claim a whole batch in one call — it shares setup cost and returns per-item results:
+## Step 4 — on go, claim and run
 
 ```bash
 mmi-cli oracle board claim <ref> <ref> <ref> --json
 ```
 
-Claiming takes a card that is unassigned or assigned to the viewer, in `Todo`, `In Progress` or
-`In Review`, unless another session still shows work on it in the last 4 hours (then it refuses). It assigns the viewer, moves Status to
-`In Progress`, and stamps a lane-identity comment so other agents can attribute the hold. Any per-item failure exits nonzero — read
-the per-item results rather than assuming the batch took. **Route is `oracle board claim` only**; there is
-no `oracle issue claim` and no flat `board claim` — both refuse. Guessing either burns a call.
+Say the size first: how many issues, how many PRs. Read per-item results; any failure exits nonzero. **Route
+is `oracle board claim` only**; `oracle issue claim` and flat `board claim` refuse.
 
-Then one worktree per batch, all batches concurrently. The host owns worktree mechanics; MMI owns board
-and PR facts. For worktree setup on Windows or concurrent ref renames, read [reference.md](reference.md).
+The claim prints the issue's recorded owner rulings; follow them. Record a new one with `mmi-cli oracle issue decision`.
 
-## Step 5 — land one PR per batch
-
-There is no `--issues` or `--closes` flag. A bundled PR is expressed in the **body**:
+One worktree per batch, all concurrently. Windows setup and ref renames: [reference.md](reference.md).
 
-```
-Closes #6395, #6396, #6397
-```
+## Step 5 — land one PR per batch
 
-`pr create` normalizes multiple closing directives, and after the merge the board advance walks GitHub's
-full `closingIssuesReferences` list and moves **each** issue to Done, verifying every one and naming any
-that did not move. So a bundle is a first-class landing, not a trick.
+No `--issues` or `--closes` flag; put `Closes #6395, #6396, #6397` in the **body**. After merge, board
+advance moves each closed issue to Done.
 
 ```bash
 mmi-cli devops pr create --body-file .jerv/tmp/pr-batch-a.md
 mmi-cli devops pr land <pr> --json
 ```
 
-Materialize the body as a real UTF-8 file and pass its path; do not pipe it to `--body-file -`. Read
-`mmi-cli explain devops pr create --json` before the write — flags change.
-
-When an issue must stay open, write `Part of #N` or `Refs #N`. **Never** write `Does not close #N` —
-GitHub closes it anyway (JC#495).
-
-When the repo runs a guidance-learning gate, read [reference.md](reference.md) before preparing the PR body.
-
-Landing requires a merged receipt before any cleanup: `state` `MERGED`, the head ref and OID matching the
-local task branch, and a clean worktree. Anything else means retain and report, never clean.
-
-## Guardrails
-
-- **No go, no write.** The board render and the plan are free. Claims, branches, PRs are not.
-- **Say the size out loud** before claiming: how many issues, how many PRs.
-- **Same repo only** inside one PR.
-- A batch is justified by a shared code surface, never by convenience. Unrelated changes in one PR make a
-  worse PR, not a cheaper one.
-- Surface any `gh` / `mmi-cli` error verbatim.
+Write the body as a UTF-8 file; run `mmi-cli explain devops pr create --json` first. An issue that stays
+open: `Part of #N` or `Refs #N`, never `Does not close #N`. Guidance-learning gate: read
+[reference.md](reference.md) first. Clean up only after a merged receipt (`state` `MERGED`, matching head
+ref and OID, clean worktree); otherwise retain and report. Show any `gh` / `mmi-cli` error verbatim.
 
 ## Retro — one check before you finish
-Before your final report, answer one question honestly: did **this skill's own instructions** misfire this
-run — ambiguous wording, a misleading message, or an environment failure it should have warned about?
-(Process only — never the user's code or task; e.g. a grouping rule that bundled two issues which turned
-out to conflict, or a board read that misreported what was claimable.) If yes, file **one** lesson and
-move on; a clean run is silent (hard cap: one per run). It lands on the owning 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. File through MMI:
+
+Did this skill's own instructions misfire this run (process only, never the user's code)? If yes, file one:
 `mmi-cli learning skill-lesson --skill board --title "<what misfired>" --body "<what; evidence; proposed amendment>"`
+File one per run; a clean run is silent; if the call fails, note it and continue.

package/skills/board/reference.md

@@ -9,3 +9,69 @@ standalone `learning: none — <reason>` line unless a closing learning issue's
 changed file. The line must stand alone on its own newline — a literal `\n` inside an inline edit fails
 the gate again.
 
+
+## Detail moved from SKILL.md
+
+Prefer `--out` for a shell-independent UTF-8 receipt. Windows PowerShell 5.1's `>` writes
+UTF-16LE with a BOM (#5802); Bash redirects preserve the CLI's UTF-8 output.
+
+One call. Its JSON carries `viewer`, `repo` and the project title — do not spend extra calls on
+`gh api user` or `gh repo view`. Use `primary` for this repo and `secondary` for other repos on the same
+Project. Partial reads exit nonzero; pass `--allow-partial` only when the dev accepts an incomplete board.
+
+Partition, as the CLI computes it:
+
+- **Yours** — assignee includes the viewer, status in `Todo · In Progress · In Review`, or stamped by this
+  seat (same login, host, and surface, including a prior session on this host whose transcript is dead).
+- **Free to claim** — status `Todo`, unassigned, and the viewer has push on the repo. Also any item in
+  any status whose foreign claim stamp is stale: its session has done no work on it for 4 hours. A stale stamp
+  holds nothing; `board claim` takes it over without `--force` and names the old stamp.
+- **Taken** — someone else's, any active status.
+
+Every stamped row names its session (`lane surface/session@host`), or `stale:<age>` when the stamp is
+stale. Work means the stamp, an issue comment, a commit on the issue's branch, or an update to an open
+PR that closes it. Any of these in the last 4 hours keeps the hold; a date that cannot be read counts as
+work. A takeover keeps the old branch and PR and names them, so the new session continues them.
+
+`--bodies` fetches body and comments for every scoped issue. In the JSON, read them at
+`row.details.body` and `row.details.comments` — not `row.body` or `row.comments`. `--bundle-details` is
+the cheaper variant that covers only `userOwned` and `claimable` — prefer it when the plan is limited
+to claimable work. `taken` stays metadata-only either way. Do not fetch Done items.
+
+3. **Groups are disjoint by construction**, so every group runs in parallel with no worktree contention.
+   That is the whole trick — the number of groups is the number of PRs, and it is the smallest number
+   reachable without two PRs fighting over the same file.
+
+Forced splits — these override the grouping and each takes its own PR:
+
+- **Another repo.** Never bundle across repos. Board advance is per-repo and deliberately refuses to move
+  another repo's issue, so a cross-repo bundle lands the code and leaves those issues stranded open.
+- **Irreversible or gated work** — migrations, secret rotation, release-train changes. Bundling hides them.
+- **An issue that must stay open** (HOLD, prep, partial delivery).
+- **Review size.** A PR no one can review is not cheap. When a group grows past roughly ten issues or
+  spans unrelated subsystems, cut it at its weakest overlap and take two PRs.
+
+> Nine claimable, three PRs: **A** #6395–#6397 board routing · **B** #6398–#6401 train doctor heal ·
+> **C** #6402–#6403 CLI flag validation. Say go and I'll run all three in parallel.
+
+Claiming takes a card that is unassigned or assigned to the viewer, in `Todo`, `In Progress` or
+`In Review`, unless another session still shows work on it in the last 4 hours (then it refuses). It assigns the viewer, sets
+`In Progress` and stamps a lane-identity comment.
+
+Then one worktree per batch, all batches concurrently. The host owns worktree mechanics; MMI owns board
+and PR facts.
+
+`pr create` normalizes multiple closing directives, and after the merge the board advance walks GitHub's
+full `closingIssuesReferences` list and moves **each** issue to Done, verifying every one and naming any
+that did not move. So a bundle is a first-class landing, not a trick.
+
+Materialize the body as a real UTF-8 file and pass its path; do not pipe it to `--body-file -`. Read
+`mmi-cli explain devops pr create --json` before the write — flags change.
+
+When an issue must stay open, write `Part of #N` or `Refs #N`. **Never** write `Does not close #N` —
+GitHub closes it anyway (JC#495).
+
+Landing requires a merged receipt before any cleanup: `state` `MERGED`, the head ref and OID matching the
+local task branch, and a clean worktree. Anything else means retain and report, never clean.
+
+Retro: the lesson lands on the owning board (deduped) and is fixed only via a reviewed PR — never edit the skill live; the retro is advisory. A misfire is ambiguous wording, a misleading message, or an environment failure the skill should have warned about (e.g. a grouping rule that bundled two issues which turned out to conflict, or a board read that misreported what was claimable). Hard cap: one lesson per run.

package/skills/bootstrap/SKILL.md

@@ -7,157 +7,71 @@ description: Provision an org repo with board, registry, rules, and plugin setup
 
 # /bootstrap — provision a repo into the org
 
-The one-time onboarding that turns a repo into a first-class org citizen. **Master-admin only, run from
-`MMI-Hub` (the hub).** Every step operates org-level resources (Project, Ruleset, org secrets, member
-access) **through the GitHub App's installation token** — not a human credential — so the gate is who may
-invoke the skill (the master holds the App key), not the caller's GitHub role.
+One-time onboarding, run from `MMI-Hub` by the master (who holds the GitHub App key). It uses the App installation token, no per-repo checkout. The repo must already be named `<CATEGORY>-<PascalName>`.
 
-Bootstrap operates on the target repo entirely through the App — **no per-repo checkout**. The repo must
-already be named on the taxonomy `<CATEGORY>-<PascalName>`.
+Read [reference.md](reference.md) for create vs upgrade, seed refresh, propagation rollback, or new topology values.
 
-Read [reference.md](reference.md) when choosing create vs upgrade, refreshing seeds, rolling back propagation, or using newly released topology values.
+## Step 0 — confirm the four axes before any mutation
 
-## Step 0 — capability shape (confirm the four axes before any mutation)
+Before Step 0a, state a recommended default per axis and confirm all four with Jervaise through the orchestrator; never default silently.
 
-Bootstrap is **destructive to undo**: a wrong shape means converting in place later — deleting protected
-branches, temporarily disabling the org-wide `mmi-train-floor` ruleset (which affects every repo for that
-window), and tearing down train artifacts (#1450). So **before Step 0a touches anything**,
-surface and **confirm all four topology axes with the master** — present the recommended default for each,
-never apply it silently. Use the structured-question UI; one question per axis (or one grouped confirm).
+- **`class`** — `deployable` (full or direct train) · `content` (trunk, `main` only); sets the branch model.
+- **`project-type`** — `web-app`, `cli-tool`, `worker`, `desktop-app`, `desktop-game`, `mobile-app`, `content`…; sets Hub services.
+- **`deploy-model`** — `tenant-container`, `none`, `content`…; sets the deploy path.
+- **`release-track`** — `full` (development·rc·main) · `direct` (development·main) · `trunk` (`main`); sets the branch set.
 
-- **`class`** — `deployable` (ships an app/service; full or direct train) · `content` (docs/content;
-  trunk, `main`-only). *Controls the branch model.* Recommend from what the repo **is**, not a fixed default.
-- **`project-type`** — e.g. `web-app`, `cli-tool`, `worker`, `desktop-app`, `desktop-game`, `mobile-app`, `content`. *Controls which Hub
-  services attach.*
-- **`deploy-model`** — e.g. `tenant-container`, `none`, `content`. *Controls the deploy path.*
-- **`release-track`** — `full` (development·rc·main) · `direct` (development·main, skips rc) · `trunk`
-  (`main` only). *The branch set follows the track, not just the class (#1097).*
+A **deployable** repo also needs gate runtime (`node` default, `python` for a Python app), check command and working directory: `--var GATE_RUNTIME=`, `GATE_CMD=`, `GATE_WORKDIR=`, and `GATE_CACHE_DEP_PATH=` for a non-root Node lockfile.
 
+**Content/trunk**: `main` only, no `rc`, no `gate.yml`, no product required-check ruleset, `projects.json` entry with `branch: main`.
 
-For a **deployable** repo, also capture the **gate runtime** (`node` | `python`), the **check command**, and
-the **working directory** — these feed the product gate (`--var GATE_RUNTIME=`, `--var GATE_CMD=`,
-`--var GATE_WORKDIR=`, and `--var GATE_CACHE_DEP_PATH=` for a non-root Node lockfile; see Step 5 / the
-"Product gate + required checks" note below). Default to `node` at the repo root; recommend `python` when the
-repo's app is Python.
-
-A **content/trunk** choice provisions: `main`-only (no `rc`), **no** `.github/workflows/gate.yml` and **no**
-product required-check ruleset, and a `projects.json` entry with `branch: main` (which marks it a content-class
-repo). A clean content repo then verifies green — `bootstrap verify --class content` no longer reports
-the deployable gate checks as FAIL (#1450).
-
-Record the confirmed axes; Step 0a runs `verify --class <confirmed>`, Step 0b creates the repo on the
-track's default branch, and the apply flags (`--project-type` / `--deploy-model` / `--release-track`) carry
-the confirmed values — no silent defaulting.
+Apply flags carry the confirmed values; Step 0b creates the repo on the track's default branch.
 
 ## Step 0a — no-mutation verifier
 
-Before mutating anything, run the verifier so the current gaps are concrete:
 ```bash
-mmi-cli devops bootstrap verify "$OWNER/$REPO" --class deployable --json
-# or for content repos:
-mmi-cli devops bootstrap verify "$OWNER/$REPO" --class content --json
+mmi-cli devops bootstrap verify "$OWNER/$REPO" --class deployable --json   # or --class content
 ```
 
-Run it again after Step 7. A repo is not ready for real developers until every check is green, or the report
-names an explicitly manual-only item that the master has accepted for that repo. For a deployable repo the
-report ends with the train doctor verdict per lane (`release`; plus `rcand` on a full track) — the same
-`mmi-cli devops train doctor` door `/release` and `/rcand` open (#6070); a `ready: false` there is an
-unfinished repo, **with one expected exception**: a full track's two lanes start from different branches
-(`release` from `rc`, `rcand` from `development`) and one checkout stands on one branch, so the lane you
-are not standing on reports the never-healed `branch-mismatch` blocker (#6432). Verify is read-only and
-does not check the other branch out: a lane whose ONLY finding is that mismatch is printed `NOT EVALUATED
-from this branch` and does not fail the verify (#6677). That is the finished state, not a gap — run
-`mmi-cli devops train doctor --lane <lane> --json` from that lane's own branch for its verdict. Any other
-blocker in that lane, or an unread origin, still makes the report red.
-
-**Two verify FAILs are un-run apply steps or API lag, not code bugs — diagnose them as such, but never as
-acceptable end states (#2928):**
-- `branch protection exists` / `push allowlist configured` — **`bootstrap apply --execute` applies the
-  train-branch push allowlist (Step 2b)**, so these FAIL until the live apply has run. They are security
-  controls and must go green (or be an explicitly master-accepted manual item per the rule above) before
-  the bootstrap is complete. A red branch-protection or push-allowlist check is an **unfinished repo**,
-  never a known-benign FAIL to sign off around.
-- `README has Agent context section — README.md not readable via API` on a README that demonstrably has the
-  section — GitHub's contents API lags for a minute or so right after a merge. **Re-run before believing a
-  content-read failure**; it clears on its own.
-
-For a new repo, board selection/creation, access, gate setup, or manual provisioning, read [reference.md](reference.md) Steps 0b–5 before applying; upgrades can use the apply path below.
+Re-run after Step 7. Ready = all green, or a named manual-only item Jervaise accepted. A deployable report ends with the train doctor verdict per lane (`release`, plus `rcand` on full track); the lane you are not standing on reports `branch-mismatch`; if that is its ONLY finding, verify prints `NOT EVALUATED from this branch` and passes: run `mmi-cli devops train doctor --lane <lane> --json` from that lane's branch. Any other blocker, or an unread origin, is red.
 
-## Step 6 — register Hub META
+Two FAILs are unrun steps or API lag, never acceptable end states:
+- `branch protection exists` / `push allowlist configured` — `bootstrap apply --execute` applies the allowlist (Step 2b). Security controls: green, or an accepted manual item, before the bootstrap is complete.
+- `README has Agent context section — README.md not readable via API` on a README that has it — API lag after a merge; re-run.
 
-Do not seed a product repo control-plane config file. `mmi-cli` carries the Hub API endpoint and resolves board,
-deploy, secret, and project state from the Hub registry at runtime.
+For board selection/creation, access, gate setup or manual provisioning of a new repo, read [reference.md](reference.md) Steps 0b–5; upgrades use the apply path below.
 
-For project-type/deploy-model flag combinations or an MM-Work module, read [reference.md](reference.md) before choosing the apply flags.
+## Step 6 — register Hub META
 
-Run the apply path with the board variables discovered above, or register the same values with
-`mmi-cli oracle org project set` from the Hub or from the target project checkout:
+No product repo control-plane file; `mmi-cli` resolves state from the Hub registry. For flag combinations or an MM-Work module, read [reference.md](reference.md) first. Apply with the board variables discovered earlier (or `mmi-cli oracle org project set`):
 
 ```bash
 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" \
-  --var PROJECT_ID="$PROJECT_ID" \
-  --var STATUS_FIELD_ID="$STATUS_FIELD_ID" \
-  --var STATUS_TODO="$STATUS_TODO" \
-  --var STATUS_IN_PROGRESS="$STATUS_IN_PROGRESS" \
-  --var STATUS_IN_REVIEW="$STATUS_IN_REVIEW" \
-  --var STATUS_DONE="$STATUS_DONE"
+  --var PROJECT_OWNER="$PROJECT_OWNER" --var PROJECT_NUMBER="$PROJECT_NUMBER" \
+  --var PROJECT_ID="$PROJECT_ID" --var STATUS_FIELD_ID="$STATUS_FIELD_ID" \
+  --var STATUS_TODO="$STATUS_TODO" --var STATUS_IN_PROGRESS="$STATUS_IN_PROGRESS" \
+  --var STATUS_IN_REVIEW="$STATUS_IN_REVIEW" --var STATUS_DONE="$STATUS_DONE"
 ```
 
-Tenant-container repos must carry a `docker-compose.yml` and Dockerfile that build from the shipped source
-archive; the train does not ship a prebuilt `dist/`. **Bootstrap seeds both files** for
-`deployModel: tenant-container` from `skills/bootstrap/seeds/` (rendered from
-the bootstrap seed Dockerfile and compose templates). The seeded compose is fileless: its service carries
-`labels: { mmi.runtime-env: "true" }`, no `env_file`, and a loopback-only port; the deploy injects the stage's
-vault values at runtime (`DEPLOY#<stage>.noEnvFile: true`) and the app reads plain env vars — it must **not** self-load SSM and must **not** ship a committed `.env`.
+`tenant-container` repos need a `docker-compose.yml` and Dockerfile building from the shipped source archive (no prebuilt `dist/`); bootstrap seeds both from `skills/bootstrap/seeds/`. The seeded compose is fileless: label `mmi.runtime-env: "true"`, no `env_file`, loopback-only port; deploy injects the stage's vault values (`DEPLOY#<stage>.noEnvFile: true`), so the app reads plain env vars, never self-loads SSM, never ships a `.env`. For an MM-Work module or non-suite web-app with OAuth META, read [reference.md](reference.md) before the first CI/deploy or OAuth provisioning.
 
-For an MM-Work module or non-suite web-app with OAuth META, read [reference.md](reference.md) before the first CI/deploy or OAuth provisioning.
+**Stage port block:** `tenant-container` and `solo-container` need Hub registry `portRange` (`bootstrap verify` fails without it). `bootstrap apply --execute` assigns it; for older META run `mmi-cli stage port-range <Repo>` (idempotent). Use `$STAGE_PORT` in `stage.up`/`healthUrl`.
 
-Local `/stage` is optional product-owned configuration. A repo that wants `/stage` may carry a local
-`stage` block, but that file must not contain board, deploy, or secret registry facts.
+## Step 7 — org-managed .gitignore block
 
-**Stage port block (required for central-container):** run `mmi-cli stage port-range <Repo>` to assign
-(idempotently) the repo's local port block from the central registry. `tenant-container` and
-`solo-container` **must** have Hub registry `portRange` — `mmi-cli devops bootstrap verify` fails without
-it (#5539), and `mmi-cli stage` cannot derive a local preview until the block exists. `bootstrap apply
---execute` assigns the block automatically after DDB register for those models; for older META holes,
-run `stage port-range` explicitly. Use `$STAGE_PORT` in `stage.up` / `healthUrl`; `/stage` then picks a
-free port inside the block so a dev can run several projects/versions locally without collisions.
-
-## Step 7 — seed the org-managed .gitignore block
-
-The org-managed `.gitignore` block is delivered by the `managed-block` bootstrap seed (`skills/bootstrap/seeds/manifest.json`),
-which merges the canonical block into the repo's `.gitignore` in place, preserving the repo's own ignore lines.
-The independent CLI/user-settings resume path may run doctor thereafter. The block carries **only** org-universal ignores —
-never agent guides or a spine. The fanout pipeline that used to push this block via App-token PRs is retired
-(Hub#3010), and the whole-spine fanout was retired earlier (hub-v3 WS4.2 #2219).
+The `managed-block` seed (`skills/bootstrap/seeds/manifest.json`) merges org-universal ignores into `.gitignore` in place, keeping the repo's own lines.
 
 ## Step 8 — report
 
-Repo, default branch, ruleset applied, train branches locked (push allowlist), repository Environments
-provisioned per track (plan-gated protections named in apply output), 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, the final `mmi-cli devops bootstrap verify "$OWNER/$REPO" --class ... --json` result,
-and — for a deployable repo — the train door itself, run from the repo's own checkout on `development`:
+Repo, default branch, ruleset, push allowlist, Environments per track, project (info, Status lanes, Labels field verified), secrets set (names only), access, plugin, docs, registry META, issue templates, org App credentials, `.gitignore` block, the final `bootstrap verify` result, and for a deployable repo the train door from the repo's checkout on `development`:
 
 ```bash
-mmi-cli devops train doctor --lane release --repo "$OWNER/$REPO" --json
+mmi-cli devops train doctor --lane release --repo "$OWNER/$REPO" --json   # full track: also --lane rcand
 ```
 
-`ready: true` is the bootstrap's train-readiness proof; every finding carries `code`, `severity`, `source`,
-`remedy` and a `docs/Guides/train-troubleshooting.md#<code>` anchor. A full-track repo runs
-`--lane rcand` as well. A `bootstrap-gap` finding names the apply row still missing — a blocker for a
-train branch absent on origin, a warning for a stage with no required status check (#6136): read the
-warnings too, `ready: true` alone does not prove the product ruleset is active.
-
-## Retro — one check before you finish
-Before your final report, answer one question honestly: did **this skill's own instructions** misfire
-this run — ambiguous wording, a misleading message, or an environment failure it should have warned
-about? (Process only — never the user's code or task; e.g. an ambiguous seed, registry, or OIDC step, or
-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 owning 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. File through MMI:
+`ready: true` is the train-readiness proof (findings: `docs/Guides/train-troubleshooting.md#<code>`). A `bootstrap-gap` finding names the missing apply row (blocker: train branch absent on origin; warning: stage with no required status check). Read warnings too: `ready: true` alone does not prove the product ruleset is active.
+
+## Retro
+
+If this skill's instructions misfired (process only), file one lesson (one per run; if the call fails, note it and continue):
 `mmi-cli learning skill-lesson --skill bootstrap --title "<what misfired>" --body "<what; evidence; proposed amendment>"`

package/skills/bootstrap/reference.md

@@ -419,3 +419,68 @@ The keys are the one stageless pair `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET`
 stage reads it (#2244/#2528). Never a staged `{dev,rc,main}/GOOGLE_*`, `GOOGLE_OAUTH_CLIENT_*`, or `prod/`
 variant; the runtime reads only the canonical names and declare-first rejects the rest.
 
+
+
+## Detail moved from SKILL.md (verbatim)
+
+For a **deployable** repo, also capture the **gate runtime** (`node` | `python`), the **check command**, and
+the **working directory** — these feed the product gate (`--var GATE_RUNTIME=`, `--var GATE_CMD=`,
+`--var GATE_WORKDIR=`, and `--var GATE_CACHE_DEP_PATH=` for a non-root Node lockfile; see Step 5 / the
+"Product gate + required checks" note below). Default to `node` at the repo root; recommend `python` when the
+repo's app is Python.
+
+A **content/trunk** choice provisions: `main`-only (no `rc`), **no** `.github/workflows/gate.yml` and **no**
+product required-check ruleset, and a `projects.json` entry with `branch: main` (which marks it a content-class
+repo). A clean content repo then verifies green — `bootstrap verify --class content` no longer reports
+the deployable gate checks as FAIL (#1450).
+
+Record the confirmed axes; Step 0a runs `verify --class <confirmed>`, Step 0b creates the repo on the
+track's default branch, and the apply flags (`--project-type` / `--deploy-model` / `--release-track`) carry
+the confirmed values — no silent defaulting.
+
+Run it again after Step 7. A repo is not ready for real developers until every check is green, or the report
+names an explicitly manual-only item that the master has accepted for that repo. For a deployable repo the
+report ends with the train doctor verdict per lane (`release`; plus `rcand` on a full track) — the same
+`mmi-cli devops train doctor` door `/release` and `/rcand` open (#6070); a `ready: false` there is an
+unfinished repo, **with one expected exception**: a full track's two lanes start from different branches
+(`release` from `rc`, `rcand` from `development`) and one checkout stands on one branch, so the lane you
+are not standing on reports the never-healed `branch-mismatch` blocker (#6432). Verify is read-only and
+does not check the other branch out: a lane whose ONLY finding is that mismatch is printed `NOT EVALUATED
+from this branch` and does not fail the verify (#6677). That is the finished state, not a gap — run
+`mmi-cli devops train doctor --lane <lane> --json` from that lane's own branch for its verdict. Any other
+blocker in that lane, or an unread origin, still makes the report red.
+
+Tenant-container repos must carry a `docker-compose.yml` and Dockerfile that build from the shipped source
+archive; the train does not ship a prebuilt `dist/`. **Bootstrap seeds both files** for
+`deployModel: tenant-container` from `skills/bootstrap/seeds/` (rendered from
+the bootstrap seed Dockerfile and compose templates). The seeded compose is fileless: its service carries
+`labels: { mmi.runtime-env: "true" }`, no `env_file`, and a loopback-only port; the deploy injects the stage's
+vault values at runtime (`DEPLOY#<stage>.noEnvFile: true`) and the app reads plain env vars — it must **not** self-load SSM and must **not** ship a committed `.env`.
+
+Local `/stage` is optional product-owned configuration. A repo that wants `/stage` may carry a local
+`stage` block, but that file must not contain board, deploy, or secret registry facts.
+
+**Stage port block (required for central-container):** run `mmi-cli stage port-range <Repo>` to assign
+(idempotently) the repo's local port block from the central registry. `tenant-container` and
+`solo-container` **must** have Hub registry `portRange` — `mmi-cli devops bootstrap verify` fails without
+it (#5539), and `mmi-cli stage` cannot derive a local preview until the block exists. `bootstrap apply
+--execute` assigns the block automatically after DDB register for those models; for older META holes,
+run `stage port-range` explicitly. Use `$STAGE_PORT` in `stage.up` / `healthUrl`; `/stage` then picks a
+free port inside the block so a dev can run several projects/versions locally without collisions.
+
+Repo, default branch, ruleset applied, train branches locked (push allowlist), repository Environments
+provisioned per track (plan-gated protections named in apply output), 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, the final `mmi-cli devops bootstrap verify "$OWNER/$REPO" --class ... --json` result,
+and — for a deployable repo — the train door itself, run from the repo's own checkout on `development`:
+
+```bash
+mmi-cli devops train doctor --lane release --repo "$OWNER/$REPO" --json
+```
+
+`ready: true` is the bootstrap's train-readiness proof; every finding carries `code`, `severity`, `source`,
+`remedy` and a `docs/Guides/train-troubleshooting.md#<code>` anchor. A full-track repo runs
+`--lane rcand` as well. A `bootstrap-gap` finding names the apply row still missing — a blocker for a
+train branch absent on origin, a warning for a stage with no required status check (#6136): read the
+warnings too, `ready: true` alone does not prove the product ruleset is active.