@tendrilapp/cli 0.1.49 → 0.1.51

package/dist/SKILL.md

@@ -254,11 +254,20 @@ Batch runs (several components in one session):
    lists unconfirmed partner pairs, this recording references OTHER
    recorded components (a segmented control built from a recorded
    Control, a dialog holding a recorded Button). Order matters:
-   generate the PARTNER bundle first, then show the pairing to the
-   user — a human decides it by running
+   generate the PARTNER bundle first, then put the pairing decision in
+   front of the human — it is human-only on either channel, and you
+   can never make it. CLICK PATH (lead with this): `tendril_compose`
+   puts the pairing in their browser as an Approve card (sign in first
+   via `tendril_login` if needed — one browser Approve each); relay
+   the approve link VERBATIM, name the account the result says to
+   approve as, never urge, then loop `tendril_compose_wait` (same
+   heartbeat contract as publish waits: pending is a heartbeat, one
+   short liveness line, never "stuck"). The card's Deny is NOT NOW —
+   this request only, never a permanent decline. TERMINAL PATH: the
+   human runs
    `npx -y -p @tendrilapp/cli@latest tendril compose --set <host-set-dir>`
-   in their own terminal (confirm or `--decline <pair-key>`; the
-   pair-key is printed above each pair). Never confirm it yourself.
+   themselves (confirm or `--decline <pair-key>`; decline there IS
+   permanent — asked once). Never confirm on either channel yourself.
    Generating the host with pairs undecided is valid — the brief will
    say so — but the host then re-implements the partner's pixels
    locally instead of composing the verified partner bundle, so
@@ -268,6 +277,41 @@ Batch runs (several components in one session):
    in another project root are invisible to pairing until co-located
    or pointed at — the tools name their scanned roots so "not
    scanned" never reads as "no relationship".
+   CONNECTING COMPONENTS THAT ALREADY EXIST (both recorded, both
+   generated): step ONE is putting both recording sets in one scanned
+   root (co-locate, or --library). If a set is not on this machine at
+   all — a fresh checkout, a different laptop, a component a teammate
+   published — do NOT conclude the work needs the original machine:
+   `tendril_pull <component name>` downloads the recording set the
+   published verdict was measured against, into
+   `./recordings/<component>/`. One call per component; the name is
+   exact, and a name that does not resolve comes back with the
+   account's real component names to pick from. It needs a portal
+   session (`tendril_login`) because a recording set belongs to the
+   account that published it — everything after the pull is local and
+   account-less as always. A publication published before recording
+   sets travelled, or published with `--no-recordings`, says so: that
+   is an honest stop, not a retry. If the pairing then shows as
+   NAME-ONLY (the host was recorded over MCP, so Figma's instance→
+   component bindings were never captured), run
+   `tendril_record_bindings` on the HOST set — one or two batched
+   REST calls, congruence-verified, no re-recording; needs the Figma
+   connect — if absent, that is ONE more browser Allow via
+   `tendril_figma_connect`, name it up front so it never reads as a
+   detour — and the pairing becomes id-backed and confirmable. Then
+   the click path above (tendril_compose → Approve →
+   tendril_compose_wait). After the approve: the HOST bundle is
+   REGENERATED with the same --library roots (a verified bundle is
+   frozen — composition never retrofits one; the partner bundle is
+   reused verbatim). That regeneration is a normal generation run:
+   ask the model question there as always, and set the expectation in
+   one line that it takes a few scored attempts. If the regenerated
+   host was ALREADY published, the republish completes in one
+   announced call; if it was NEVER published, a SECOND, different
+   browser card appears — the publish approval — say so before it
+   does. On session resume, a pending connect decision may be waiting:
+   if `pending-compose.json` exists under the user config dir, run
+   `tendril_compose_wait` first.
 
 ## Generating (the agent-harness engine — you are the proposer)
 
@@ -464,6 +508,15 @@ automatically) → `tendril_publish` → surface what it returns:
   moment for a step no click will confirm.
 - Not signed in? Surface `tendril_login` first — the sequence pauses at
   sign-in; it never silently skips publishing.
+- A publish also carries the RECORDING SET the verdict was measured
+  against, so the work can be picked up on any machine the user signs
+  in from (`tendril_pull`). It is private to their account — no share
+  link and no public page reaches it — and it rides the same deletion
+  as everything else. If the publish result says it went without the
+  recording set, relay that line as-is: it names why, and it is never
+  a failed publish. The first time an account carries one, the portal
+  asks for one browser Accept naming the new custody; relay that link
+  the way you relay an approve link, and never urge the decision.
 
 Sub-bar runs do NOT publish — the CLI refuses a declined run, and the
 honest failure report is that run's correct terminal state. The

package/dist/tendril-mcp.js

@@ -138,6 +138,23 @@ var TOOLS = [
     }),
     argv: (i) => ["publish", i["bundleDir"], "--approve-wait", "--wait-window", "55", ...typeof i["portal"] === "string" ? ["--to", i["portal"]] : []]
   },
+  {
+    name: "tendril_pull",
+    description: "Bring a published component's RECORDING SET onto this machine \u2014 the recorded design truth its verdict was measured against. Use it when the recordings are not here: a fresh machine, a clone with no recordings/ directory, or a component someone else on the team published. ONE bounded call, no wait twin. Needs a portal session (tendril_login) because a recording set belongs to the account that published it; everything afterwards \u2014 verify, compose, republish \u2014 is local, offline and account-less as always. The name is EXACT and the portal's refusals list the user's real component names, so a name that does not resolve is a one-step correction rather than a dead end; when one name spans two design systems, pass `figmaFile`. It writes to ./recordings/<component>/ and never overwrites a different set already there. AFTER pulling, call tendril_record_status on each set you pulled, then continue the connect prompt from its step 3.",
+    schema: z.object({
+      component: str("the component name, exactly as the user's library shows it"),
+      figmaFile: optStr("the design system's Figma file key \u2014 only when one name spans several of the user's design systems (the portal's refusal says when)"),
+      dest: optStr("where the set lands (default: ./recordings/<component>)"),
+      portal: optStr("portal origin override for self-hosted portals (defaults to the stored session's portal)")
+    }),
+    argv: (i) => [
+      "pull",
+      i["component"],
+      ...typeof i["figmaFile"] === "string" ? ["--figma-file", i["figmaFile"]] : [],
+      ...typeof i["dest"] === "string" ? ["--dest", i["dest"]] : [],
+      ...typeof i["portal"] === "string" ? ["--to", i["portal"]] : []
+    ]
+  },
   {
     name: "tendril_record_next",
     annotations: { readOnlyHint: true },
@@ -151,6 +168,40 @@ var TOOLS = [
     schema: z.object({ setDir: str("recording set directory") }),
     argv: (i) => ["record", "rest-fetch", "--set", i["setDir"]]
   },
+  {
+    name: "tendril_record_bindings",
+    description: "Fetch Figma's instance\u2192component bindings for an EXISTING MCP-recorded set \u2014 one or two batched REST calls, no re-recording, pixels/geometry/identity untouched. This is how components that are ALREADY recorded and generated become connectable: the bindings make cross-component pairing id-backed, so `tendril compose` can propose it for the human's confirm. Every binding is congruence-verified against the recorded metadata (a design that changed since recording refuses per pose, named). The CLI makes the requests itself with the user's connected Figma credential (tendril_figma_connect); you make NO Figma call. The result names the next step \u2014 including when no partner set is visible in the scanned root (co-locate the sets or pass compose --library). For sets recorded before file identity was captured, pass the design's file key as `file`.",
+    schema: z.object({ setDir: str("recording set directory"), file: optStr("the design's file key (figma.com/design/<KEY>/\u2026) \u2014 only for sets whose manifest lacks figmaFile; an operator assertion, congruence still gates every binding") }),
+    argv: (i) => ["record", "bindings", "--set", i["setDir"], ...typeof i["file"] === "string" ? ["--file", i["file"]] : []]
+  },
+  {
+    name: "tendril_compose",
+    description: "Put ONE composition pairing in front of the user's BROWSER \u2014 phase one of the browser-approved connect (invariant-5 migration; the terminal `--confirm-compositions` path remains for humans at a TTY). Requires a portal session (tendril_login \u2014 one browser Approve). Returns the approve-page link: RELAY IT verbatim, name the account the result says to approve as, and never urge the decision \u2014 the card carries the engine's honest disclosures and the human reads them. Deny on the card is NOT NOW (this request only, never a permanent decline). You cannot decide this yourself on any channel: the portal accepts the decision only from the user's signed-in browser, and the terminal flag only from an interactive TTY. A host with several open pairings needs `pair` (one card = one decision). Then finish with tendril_compose_wait. Both recording sets must be visible in one scanned workspace \u2014 co-locate them or pass `library`.",
+    schema: z.object({
+      setDir: str("the HOST recording set directory (the component that embeds the partner)"),
+      pair: optStr("the pair-key to request when the host has several open pairings"),
+      library: z.array(z.string()).optional().describe("workspace root(s) holding the partner recording set(s) \u2014 required when they live in another project root"),
+      portal: optStr("portal origin override (defaults to the stored session's portal)")
+    }),
+    argv: (i) => [
+      "compose",
+      "--set",
+      i["setDir"],
+      "--approve-start",
+      ...typeof i["pair"] === "string" ? ["--pair", i["pair"]] : [],
+      ...Array.isArray(i["library"]) ? i["library"].flatMap((d) => ["--library", d]) : [],
+      ...typeof i["portal"] === "string" ? ["--to", i["portal"]] : []
+    ]
+  },
+  {
+    name: "tendril_compose_wait",
+    description: 'Phase two of the browser-approved connect. Waits in a BOUNDED window (~1 minute per call) for the user\'s decision on the card tendril_compose returned; on Approve it records the SAME manifest entry the terminal confirm writes \u2014 after re-deriving the pairing from the CURRENT recordings and refusing if anything changed underneath the click (the click is then not wrong; the project moved \u2014 run the connect again). While undecided, each call returns `status: "approval-pending"` \u2014 a heartbeat, not a failure: one short liveness line to the user, then call again; the request stays live ~30 minutes, and a decided card can take moments to land. NOT NOW, a lapse, and success each arrive as their own sentence \u2014 report the one you got. After success: regenerate the HOST bundle with the same library roots (brief \u2192 generate \u2192 score \u2192 verify), then republish \u2014 announce the republish in one line first. Compose waits follow the same heartbeat contract as publish waits: never urge, never call an in-flight wait stuck.',
+    schema: z.object({
+      setDir: str("the same HOST set directory tendril_compose was called with"),
+      portal: optStr("portal origin override (must match tendril_compose's)")
+    }),
+    argv: (i) => ["compose", "--set", i["setDir"], "--approve-wait", "--wait-window", "55", ...typeof i["portal"] === "string" ? ["--to", i["portal"]] : []]
+  },
   {
     name: "tendril_record_fetch",
     description: "Download a Figma asset URL (from get_screenshot's image_url) straight to disk and ingest it as the rep's envelope \u2014 the fallback when only the screenshot piece needs (re-)recording; for a rep's standard three recordings PREFER tendril_record_ingest_rep. Never download the image yourself: the bytes must not pass through your context.",