@tendrilapp/cli 0.1.52 → 0.1.54

package/dist/SKILL.md

@@ -206,7 +206,7 @@ Batch runs (several components in one session):
    metadata and context response text passed VERBATIM — responses
    often arrive as MULTIPLE output blocks (block counts vary BY
    TRANSPORT: the desktop server has been measured at 2-4 blocks per
-   response, the remote server at 1-2 — never treat any count as a
+   response, the remote server at 1-5 — never treat any count as a
    sanity check), so `metadataParts`/`contextParts` (every block in
    order, never hand-joined) is the normal path; `metadata`/`context`
    only for a genuinely single-block response — plus the screenshot
@@ -253,7 +253,13 @@ Batch runs (several components in one session):
 5. COMPOSITION: read the status output's `composition` block. If it
    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:
+   Control, a dialog holding a recorded Button). A pair the human
+   ALREADY confirmed can legitimately re-open as a GROWTH ask
+   (`growsConfirmed: true`): new evidence derived MORE instances of
+   the same pairing — say so as an addition, never as a contradiction
+   of the settled decision; confirming adds the new instances, the
+   standing confirmation is untouched, and growth asks cannot be
+   declined (leave them unconfirmed and they simply stay local). Order matters:
    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`
@@ -388,6 +394,13 @@ Batch runs (several components in one session):
    genuinely headless runs; it cannot tell "nobody is there" from "the
    harness said nobody is there", so it must at least say what it did,
    loudly and first.)
+   PRESENCE PROOF OVERRIDES THE NON-INTERACTIVE BRANCH: a browser
+   approval decided mid-run — a compose card approved, a publish
+   card clicked — is a human at the keyboard, whatever the harness
+   said. From the moment one lands, ask the consent gates that
+   remain instead of auto-resolving them (measured, 2026-08-30: a
+   run auto-resolved the model pick for its THIRD generation while
+   the user was demonstrably present, having just clicked Approve).
    Weak models produce honest sub-bar reports, never false passes.
 6. Tell the user roughly what a run costs them: organism-scale
    components have measured 0.3–0.7M tokens of their plan.
@@ -527,6 +540,14 @@ live at <URL>" (or "done — waiting for your Approve at <link>, as
 <account>"), before scores, caveats and file lists. The user should
 never have to ask where their component is.
 
+And invite the ONE check only the user can run: right after the
+done-line, ask them to open the live page and say whether the demo
+renders. You cannot execute the published page — a browser can, and
+a served-page defect is invisible to every check this pipeline runs
+(measured, 2026-08-30: two publishes reported "done — live" while
+both live demos showed an error banner nobody had seen). One line,
+no urging: "open it and tell me if anything looks off."
+
 A green verify may also print COMPOSE lines: other recorded components
 that embed the one just verified. Relay them after the done-line as
 DISCLOSURES (zero questions — the confirm decision is human-only, in

package/dist/tendril-mcp.js

@@ -125,9 +125,18 @@ var TOOLS = [
     description: "Publish a VERIFIED bundle to the user's portal \u2014 phase one of the browser-approved publish. Re-publishing an already-published component completes in one call. A component's FIRST publish is a human-only decision the portal enforces: this call requests the approval and returns the approve-page link \u2014 RELAY IT to the user verbatim, along with which account the result says to be signed in as (they click Approve in the browser; approving includes accepting the design system's publishing terms, which is their decision to make, never yours to urge). Then call tendril_publish_wait to finish. You cannot approve this yourself: the portal only accepts the decision from their signed-in browser, never from this machine's token. Requires a green verify (the CLI refuses a declined run) and a portal session (tendril_login).",
     schema: z.object({
       bundleDir: str("bundle directory (verified \u2014 carries component.json and verify-evidence)"),
-      portal: optStr("portal origin override for self-hosted portals (defaults to the stored session's portal)")
+      portal: optStr("portal origin override for self-hosted portals (defaults to the stored session's portal)"),
+      designSystemName: optStr(
+        "first publish only: a PROPOSED display name for the design system, prefilled on the approve card where the human names or picks it \u2014 pass the design's human name when you know it (the Figma file's title, the design system the user named); without a proposal the card prefills the raw Figma file key, and a plain Approve makes that key the permanent name"
+      )
     }),
-    argv: (i) => ["publish", i["bundleDir"], "--approve-start", ...typeof i["portal"] === "string" ? ["--to", i["portal"]] : []]
+    argv: (i) => [
+      "publish",
+      i["bundleDir"],
+      "--approve-start",
+      ...typeof i["designSystemName"] === "string" ? ["--design-system-name", i["designSystemName"]] : [],
+      ...typeof i["portal"] === "string" ? ["--to", i["portal"]] : []
+    ]
   },
   {
     name: "tendril_publish_wait",
@@ -161,12 +170,14 @@ var TOOLS = [
     description: "Fetch the user's living DESIGN-SYSTEM.md \u2014 the portal-assembled file describing one design system: its components with their ruler verdicts, each component's prescribed API and poses, the captured variable vocabulary, the icon inventory, and a changelog. Call it with no arguments first to LIST the design systems and their ids, then again with `ds` to fetch one (pass `out` to write the file where a design agent will read it). The file is a PROJECTION the portal re-assembles fresh on every fetch \u2014 never edit it, re-fetch it. Needs a portal session (tendril_login); it is owner-only because the vocabulary and icons are the customer's design IP.",
     schema: z.object({
       ds: optStr("the design system id \u2014 omit to list them"),
+      component: optStr("with ds: one component's id (from the file's inventory links) \u2014 fetches just that component's markdown page, the right scope when building with a single component"),
       out: optStr("write the markdown to this file instead of returning it inline"),
       portal: optStr("portal origin override for self-hosted portals (defaults to the stored session's portal)")
     }),
     argv: (i) => [
       "design-system",
       ...typeof i["ds"] === "string" ? ["--ds", i["ds"]] : [],
+      ...typeof i["component"] === "string" ? ["--component", i["component"]] : [],
       ...typeof i["out"] === "string" ? ["--out", i["out"]] : [],
       ...typeof i["portal"] === "string" ? ["--to", i["portal"]] : []
     ]