patchcord 0.6.30 → 0.6.31

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "patchcord",
   "description": "Cross-machine agent messaging. Messages from other agents land in the inbox and wake the agent to reply.",
-  "version": "0.6.30",
+  "version": "0.6.31",
   "author": {
     "name": "ppravdin"
   },

package/bin/patchcord.mjs

@@ -196,11 +196,24 @@ team (run from the project root):
   patchcord team blueprint push --namespace <ns> --file <blueprint.json> [--json]
                                              create/update a team blueprint (first push
                                              to a new namespace claims it — first-provision)
+                                             PROMOTES BY DEFAULT — the pushed document
+                                             goes live immediately
+  patchcord team blueprint push ... --no-promote      (alias --dry-run)
+                                             validate + store WITHOUT going live. Use this
+                                             when any deployer may not yet understand a
+                                             value in the document.
   patchcord team deployment request --namespace <ns> [--revision <uid>] [--json]
                                              enqueue an apply of a saved revision
                                              (exit 3 = one is already in flight)
   patchcord team deployment pending [--json] jobs waiting for this host to claim
-  patchcord team deployment claim --job <uid> [--installation <name>] [--json]
+  patchcord team deployment claim --job <uid> [--installation <name>]
+        [--installation-uuid <uuid>] [--json]
+                                             --installation is the host LABEL
+                                             (becomes claimed_by).
+                                             --installation-uuid is the identity
+                                             selector; must match the enrolment
+                                             body or identity-key membership is
+                                             never recorded. Optional.
                                              take ownership (exit 3 = lost the race)
   patchcord team deployment complete --job <uid> --status <healthy|degraded|cancelled>
                                              [--result <json> | --result-file <path>] [--json]
@@ -1701,13 +1714,27 @@ you design the team, provision its agents, launch them, and manage them.
         const file = flagVal("file");
         const idem = flagVal("idempotency-key");
         const wantJson = process.argv.includes("--json");
-        if (!ns || !file) { console.error("Usage: patchcord team blueprint push --namespace <ns> --file <blueprint.json> [--idempotency-key k] [--json]"); process.exit(1); }
+        // --no-promote / --dry-run: store the revision and run strict server
+        // validation WITHOUT moving the live pointer.
+        //
+        // This exists because push promotes by default, so a hand-written
+        // document goes live the instant it validates. That is fine when the
+        // document is one every consumer understands, and it is how a Team gets
+        // bricked when it is not: the server can accept a value that deployers
+        // do not yet handle, and promoting it makes the Team undeployable AND
+        // unrestorable from one command. The rule the team arrived at is
+        // "consumers accept before producers emit", and until now the only way
+        // to honour it here was to remember to. This is the safe path existing
+        // rather than being agreed.
+        const noPromote = process.argv.includes("--no-promote") || process.argv.includes("--dry-run");
+        if (!ns || !file) { console.error("Usage: patchcord team blueprint push --namespace <ns> --file <blueprint.json> [--no-promote|--dry-run] [--idempotency-key k] [--json]"); process.exit(1); }
         let doc;
         try { doc = JSON.parse(readFileSync(file, "utf-8")); }
         catch (e) { console.error(`cannot read blueprint file: ${e.message}`); process.exit(1); }
         // First POST for an unowned namespace IS first-provision (server claims
         // the namespace atomically when PATCHCORD_BLUEPRINT_ATOMIC_CREATE is on).
         const payload = { canonical_json: doc };
+        if (noPromote) payload.promote = false;
         if (idem) payload.idempotency_key = idem;
         const { status, json, body } = await accountCall("POST", `/api/team/${encodeURIComponent(ns)}/blueprint/revisions`, payload);
         if (status !== "201" && status !== "200") {
@@ -1715,7 +1742,7 @@ you design the team, provision its agents, launch them, and manage them.
           process.exit(1);
         }
         if (wantJson) {
-          process.stdout.write(JSON.stringify({ ...json, created: status === "201" }) + "\n");
+          process.stdout.write(JSON.stringify({ ...json, created: status === "201", promoted: json.promoted !== false && !noPromote }) + "\n");
           process.exit(0);
         }
         console.log(`${status === "201" ? "created" : "unchanged (dedup)"} revision_uid: ${json.revision_uid}`);
@@ -1785,10 +1812,35 @@ you design the team, provision its agents, launch them, and manage them.
       if (dsub === "claim") {
         const job = flagVal("job");
         const installation = flagVal("installation");
-        if (!job) { console.error("Usage: patchcord team deployment claim --job <uid> [--installation <name>] [--json]"); process.exit(1); }
+        // SEPARATE FIELD, deliberately not a new meaning for --installation.
+        //
+        // --installation becomes claimed_by, which is the human-readable "which
+        // host took this job" an operator reads in the deploy list. Putting a
+        // UUID there would spend a label field on an identifier and leave
+        // nothing legible in its place.
+        //
+        // They are also different things by construction: --installation is
+        // <hostname>-<suffix>, live (macOS renames itself on a Bonjour
+        // collision) and MUX_HOST_ID-overridable — the exact selector we
+        // disqualified for the identity flow. --installation-uuid is minted
+        // beside the identity key itself so the key and its selector share one
+        // lifetime. It is what the server keys team membership on, so it must
+        // match the enrolment body's installation_uuid EXACTLY or membership is
+        // written against a string nothing else uses and the team-scoped read
+        // returns an empty set forever.
+        //
+        // Omitting it is legal and stays legal: an installation that has not
+        // upgraded keeps claiming exactly as before and simply records no
+        // identity-key membership. The server has accepted this field since
+        // bb553b2, so consumers accept before producers emit.
+        const installationUuid = flagVal("installation-uuid");
+        if (!job) { console.error("Usage: patchcord team deployment claim --job <uid> [--installation <name>] [--installation-uuid <uuid>] [--json]"); process.exit(1); }
+        const claimBody = {};
+        if (installation) claimBody.installation = installation;
+        if (installationUuid) claimBody.installation_uuid = installationUuid;
         const { status, json, body } = await accountCall(
           "POST", `/api/deployments/${encodeURIComponent(job)}/claim`,
-          installation ? { installation } : {},
+          claimBody,
         );
         // Losing a claim race is normal in a multi-host account, not a failure:
         // exit 3 so a poller can skip to the next job without parsing stderr.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "patchcord",
-  "version": "0.6.30",
+  "version": "0.6.31",
   "description": "Cross-machine agent messaging for Claude Code and Codex",
   "scripts": {
     "version": "node scripts/sync-plugin-version.mjs && git add .claude-plugin/plugin.json"