@mutmutco/claude-plugin 4.6.36 → 4.6.38
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/.claude-plugin/plugin.json +1 -1
- package/cli/dist/main.cjs +650 -351
- package/cli/package.json +1 -1
- package/package.json +1 -1
- package/skills/intercom-guest/SKILL.md +22 -12
package/cli/package.json
CHANGED
package/package.json
CHANGED
|
@@ -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.
|