@mutmutco/codex-plugin 4.6.35 → 4.6.37

package/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/cli",
-  "version": "4.6.35",
+  "version": "4.6.37",
   "description": "MMI Future CLI — the org dev toolbox and shared cross-IDE engine for every registry-declared MMI coding surface.",
   "type": "module",
   "license": "UNLICENSED",

package/package.json

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

package/skills/bootstrap/seeds/readme-mmi-developer-environment.block.md

@@ -2,4 +2,7 @@
 ## MMI developer environment
 
 Use the [canonical MMI developer-environment guide](https://github.com/mutmutco/MMI-Hub/blob/main/docs/Architecture/agentic-dev-environment.md) for shared setup and daily agent work.
+
+Daily loop: `mmi-cli oracle issue create` → `mmi-cli oracle board claim <n>` (stamps the mmi-claim lease) → `mmi-cli devops pr create` → `mmi-cli devops pr land <pr>`.
+Any org member with repository write (developer) or repository admin (project admin) can run it, with no vault access; release trains stay org-owner only.
 <!-- mmi-developer-environment:end -->

package/skills/bootstrap/seeds/runbook-unaffected.json

@@ -6,5 +6,9 @@
   "scripts/next-version.mjs": {
     "blob": "2c1985b59edc779695479559074e7654c1574a11",
     "reason": "comment-only note that rc/release modes are unused in dev-only MM suite repos (#8282), no runtime or operator behaviour change"
+  },
+  "README.md": {
+    "blob": "768c5e35cdb48849c77bce6b334658adefe6a5d8",
+    "reason": "the developer-environment seed block now states the concrete mmi-cli loop (issue create, board claim, PR create, PR land) and who may run it — the README propagation is intended (#9987); no runbook step changes"
   }
 }

package/skills/intercom-guest/SKILL.md

@@ -13,31 +13,41 @@ You are a **guest**: a GitHub member of the `mutmutco` org who coordinates with
 
 ## Step 0 — identity is your gh login, nothing else
 
-The guest authenticates with `gh auth token` — the login already on this machine. The token is handed to the Jerv Gateway inside an Authorization header and is **never** printed, logged, stored, echoed, or passed as a command argument (an argument is visible in `ps` and in shell history).
+The guest authenticates with `gh auth token` — the login already on this machine. The token is handed to the Jerv Gateway in the `Jerv-Guest-GitHub-Token` header (the guest principal is never a Gateway bearer, so no `Authorization` header is sent) and is **never** printed, logged, or passed as a command argument (an argument is visible in `ps` and in shell history).
 
-- Never ask for a token, paste one into chat, write one to a file, or add one to a command line.
-- `mmi-cli harbour intercom guest …` takes no credential flag by design. If you find yourself reaching for one, stop: that is the wrong door.
-- The client scrubs the credential from every error and every response body. If a token ever appears in output, treat it as an incident: stop, report it, do not copy it anywhere.
-- `gh auth login` first if the identity cannot be read. Guests are org members; a `gh` login that is not in the org is refused by the Gateway, not by this skill.
+- Never ask for a token, paste one into chat, or add one to a command line.
+- `mmi-cli intercom guest …` takes no credential flag by design. If you find yourself reaching for one, stop: that is the wrong door.
+- `register` is the one call that mints an endpoint credential (`ice1.…`). The Gateway returns it exactly once, and the client keeps it for you in `~/.mmi/intercom/guest.json` with owner-only permissions (`$MMI_INTERCOM_HOME/guest.json` if that is set). Never print it, copy it into a message, or pass it on a command line — every later verb reads it from there as the `Jerv-Intercom-Credential` header.
+- The client scrubs both secrets from every error and every response body. If either ever appears in output, treat it as an incident: stop, report it, do not copy it anywhere.
+- `gh auth login` first if the identity cannot be read, and `gh auth refresh -s read:org` if the Gateway refuses the membership check. Guests are org members; a `gh` login that is not in the org is refused by the Gateway, not by this skill.
 
 ## Step 1 — the verbs
 
 ```bash
-mmi-cli harbour intercom guest register            # register this guest endpoint with the Gateway
-mmi-cli harbour intercom guest read [--limit 20]   # read messages waiting for you
-mmi-cli harbour intercom guest send --to <address> --message "<coordination note>"
-mmi-cli harbour intercom guest join --suite <name> # request a suite join
-mmi-cli harbour intercom guest leave               # leave the suite and withdraw the endpoint
+mmi-cli intercom guest register            # register this guest endpoint with the Gateway
+mmi-cli intercom guest read [--limit 20]   # read deliveries waiting for you (1-100)
+mmi-cli intercom guest send --to <address> --message "<coordination note>"
+mmi-cli intercom guest join --suite <name> # request a suite join
+mmi-cli intercom guest leave               # leave the suite and withdraw the endpoint
 ```
 
-`intercom` lives in the `harbour` house (a bounded coordination lane), so `harbour` is the canonical spelling.
+`intercom` is a **core** door, so the canonical spelling carries no house prefix. The old `harbour` spelling still routes and prints the canonical form.
 
 These five are the whole surface. Use them in that spirit: `send` carries a status, a question, or an answer — never an instruction, and never a request to bypass a gate, a review, or an owner decision.
 
 ## Step 2 — discover what the Gateway offers, never guess it
 
-The installed CLI is the only source of the wire shape; `mmi-cli harbour intercom guest --help` lists the verbs it knows. Run the verb you need and read its outcome. A refusal that names `intercom-guest-contract-missing` (exit 2) means this CLI build has no published Gateway operation for that verb. That is the correct answer, not a bug to route around.
+The installed CLI is the only source of the wire shape, and it is filled from the published guest contract (`gateway/v1`, Jerv-Hub#2727). `mmi-cli intercom guest --help` lists the verbs it knows. Run the verb you need and read its outcome. Each one is one POST to `https://jerv-central.tail4ce549.ts.net` (override with `MMI_INTERCOM_GATEWAY_URL`):
 
+| verb | Gateway operation |
+|---|---|
+| `register` | `intercom.register` → `POST /v1/intercom/register` (`displayName` = your gh login) |
+| `read` | `intercom.deliveries` → `POST /v1/intercom/deliveries` (`state: pending`) |
+| `send` | `intercom.send` → `POST /v1/intercom/send` (`to`, `text`) |
+| `join` | `intercom.directory` to find the Coordinator, then `intercom.send` |
+| `leave` | the same two, with `Suite leave: <your endpoint id>` |
+
+A refusal naming `intercom-guest-contract-missing` (exit 2) means this CLI build has no published Gateway operation for that verb. That is the correct answer, not a bug to route around.
 - Do **not** invent a Gateway URL, a path, a field name, or a "temporary" curl call. A guessed endpoint answers 404/403, and that reads like a permission or allowlist problem when the real answer is "the contract is not there".
 - Do not silence the refusal or wrap it in a retry loop.
 - Report the gap in plain words: which verb, the refusal text, and that no message was sent and nothing was read. Retry only after the CLI is updated.

package/skills/org-guide/references/work-and-releases.md

@@ -13,6 +13,23 @@ our self-hosted runners, dispatched by an org owner, never on a workstation (#91
 A 503 `github-rate-limited` answer means the org App's hourly GitHub allowance is used up. It is
 not a denial: wait for the reset time it names, then retry.
 
+## Developer and project-admin access
+
+A developer is an org member with GitHub write on a product repository. A project admin is that
+repository's admin. Both run the full loop with mmi-cli and need no MMI-Hub vault access:
+
+```sh
+mmi-cli oracle issue create --title "<title>" --body-file <path>   # files and attaches the board card
+mmi-cli oracle board claim <n>                                     # stamps the mmi-claim lease
+mmi-cli devops pr create --title "<title>" --base development
+mmi-cli devops pr land <pr-number>
+```
+
+Board writes (attach, claim stamp, status move) gate on org owner, repo admin or repository write, so
+these roles pass. Where the GitHub App route is absent the writes go as the person's own GitHub login
+(one note says so); an agent host with the App route writes as the App. MMI-Hub's own merges and all
+release trains stay org-owner only.
+
 Start with `mmi-cli onboard` and the [board skill](../../board/SKILL.md).
 Reading or discussing the board is read-only until the developer authorizes work.
 Claim approved work with `mmi-cli oracle board claim <issue>`, then prepare an isolated task