@mutmutco/pi-plugin 4.6.35 → 4.6.37
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -2,4 +2,7 @@
|
|
|
2
2
|
## MMI developer environment
|
|
3
3
|
|
|
4
4
|
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.
|
|
5
|
+
|
|
6
|
+
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>`.
|
|
7
|
+
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.
|
|
5
8
|
<!-- mmi-developer-environment:end -->
|
|
@@ -6,5 +6,9 @@
|
|
|
6
6
|
"scripts/next-version.mjs": {
|
|
7
7
|
"blob": "2c1985b59edc779695479559074e7654c1574a11",
|
|
8
8
|
"reason": "comment-only note that rc/release modes are unused in dev-only MM suite repos (#8282), no runtime or operator behaviour change"
|
|
9
|
+
},
|
|
10
|
+
"README.md": {
|
|
11
|
+
"blob": "768c5e35cdb48849c77bce6b334658adefe6a5d8",
|
|
12
|
+
"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"
|
|
9
13
|
}
|
|
10
14
|
}
|
|
@@ -13,31 +13,41 @@ You are a **guest**: a GitHub member of the `mutmutco` org who coordinates with
|
|
|
13
13
|
|
|
14
14
|
## Step 0 — identity is your gh login, nothing else
|
|
15
15
|
|
|
16
|
-
The guest authenticates with `gh auth token` — the login already on this machine. The token is handed to the Jerv Gateway
|
|
16
|
+
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).
|
|
17
17
|
|
|
18
|
-
- Never ask for a token, paste one into chat,
|
|
19
|
-
- `mmi-cli
|
|
20
|
-
-
|
|
21
|
-
-
|
|
18
|
+
- Never ask for a token, paste one into chat, or add one to a command line.
|
|
19
|
+
- `mmi-cli intercom guest …` takes no credential flag by design. If you find yourself reaching for one, stop: that is the wrong door.
|
|
20
|
+
- `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.
|
|
21
|
+
- 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.
|
|
22
|
+
- `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.
|
|
22
23
|
|
|
23
24
|
## Step 1 — the verbs
|
|
24
25
|
|
|
25
26
|
```bash
|
|
26
|
-
mmi-cli
|
|
27
|
-
mmi-cli
|
|
28
|
-
mmi-cli
|
|
29
|
-
mmi-cli
|
|
30
|
-
mmi-cli
|
|
27
|
+
mmi-cli intercom guest register # register this guest endpoint with the Gateway
|
|
28
|
+
mmi-cli intercom guest read [--limit 20] # read deliveries waiting for you (1-100)
|
|
29
|
+
mmi-cli intercom guest send --to <address> --message "<coordination note>"
|
|
30
|
+
mmi-cli intercom guest join --suite <name> # request a suite join
|
|
31
|
+
mmi-cli intercom guest leave # leave the suite and withdraw the endpoint
|
|
31
32
|
```
|
|
32
33
|
|
|
33
|
-
`intercom`
|
|
34
|
+
`intercom` is a **core** door, so the canonical spelling carries no house prefix. The old `harbour` spelling still routes and prints the canonical form.
|
|
34
35
|
|
|
35
36
|
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.
|
|
36
37
|
|
|
37
38
|
## Step 2 — discover what the Gateway offers, never guess it
|
|
38
39
|
|
|
39
|
-
The installed CLI is the only source of the wire shape
|
|
40
|
+
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`):
|
|
40
41
|
|
|
42
|
+
| verb | Gateway operation |
|
|
43
|
+
|---|---|
|
|
44
|
+
| `register` | `intercom.register` → `POST /v1/intercom/register` (`displayName` = your gh login) |
|
|
45
|
+
| `read` | `intercom.deliveries` → `POST /v1/intercom/deliveries` (`state: pending`) |
|
|
46
|
+
| `send` | `intercom.send` → `POST /v1/intercom/send` (`to`, `text`) |
|
|
47
|
+
| `join` | `intercom.directory` to find the Coordinator, then `intercom.send` |
|
|
48
|
+
| `leave` | the same two, with `Suite leave: <your endpoint id>` |
|
|
49
|
+
|
|
50
|
+
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.
|
|
41
51
|
- 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".
|
|
42
52
|
- Do not silence the refusal or wrap it in a retry loop.
|
|
43
53
|
- 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.
|
|
@@ -13,6 +13,23 @@ our self-hosted runners, dispatched by an org owner, never on a workstation (#91
|
|
|
13
13
|
A 503 `github-rate-limited` answer means the org App's hourly GitHub allowance is used up. It is
|
|
14
14
|
not a denial: wait for the reset time it names, then retry.
|
|
15
15
|
|
|
16
|
+
## Developer and project-admin access
|
|
17
|
+
|
|
18
|
+
A developer is an org member with GitHub write on a product repository. A project admin is that
|
|
19
|
+
repository's admin. Both run the full loop with mmi-cli and need no MMI-Hub vault access:
|
|
20
|
+
|
|
21
|
+
```sh
|
|
22
|
+
mmi-cli oracle issue create --title "<title>" --body-file <path> # files and attaches the board card
|
|
23
|
+
mmi-cli oracle board claim <n> # stamps the mmi-claim lease
|
|
24
|
+
mmi-cli devops pr create --title "<title>" --base development
|
|
25
|
+
mmi-cli devops pr land <pr-number>
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
Board writes (attach, claim stamp, status move) gate on org owner, repo admin or repository write, so
|
|
29
|
+
these roles pass. Where the GitHub App route is absent the writes go as the person's own GitHub login
|
|
30
|
+
(one note says so); an agent host with the App route writes as the App. MMI-Hub's own merges and all
|
|
31
|
+
release trains stay org-owner only.
|
|
32
|
+
|
|
16
33
|
Start with `mmi-cli onboard` and the [board skill](../../board/SKILL.md).
|
|
17
34
|
Reading or discussing the board is read-only until the developer authorizes work.
|
|
18
35
|
Claim approved work with `mmi-cli oracle board claim <issue>`, then prepare an isolated task
|