@tendrilapp/cli 0.1.54 → 0.1.56

package/dist/SKILL.md

@@ -20,48 +20,25 @@ Non-negotiables (the CLI enforces these; do not fight them):
 - Sub-bar results are honest, not failures to hide: exit 5 ships the
   bundle with real scores. Report them as they are.
 
-Permissions, FIRST THING in every pipeline run (the trigger is a FILE
-CHECK, not prompt-watching — you cannot observe permission prompts, so
-never condition on them; a measured session full of prompts had a
-prompt-conditioned offer never fire): check whether ANY Claude
-settings file the host merges — the project's
-`.claude/settings.local.json` or `.claude/settings.json`, or the
-user's `~/.claude/settings.json` — contains tendril MCP entries
-(plugin installs use `mcp__plugin_tendril_tendril__*`; direct
-`claude mcp add` installs use `mcp__<server-name>__*`) AND shell-
-surface entries (`Bash(ls:*)`-style prefixes plus `Write`/`Edit`)
-AND Figma entries under the prefix THIS session's Figma tools
-actually carry — take a Figma tool you can see (e.g. get_metadata)
-and check its full `mcp__…` name against the allowlist; entries
-under a different server's prefix are dead and DO NOT count (a
-measured session held six such entries while every Figma call
-prompted).
-THE MCP LIST ALONE IS NOT "PERMISSIONS ARE FINE": a run is mostly
-shell — mkdir, evidence reads, log writes, the printed npx commands —
-and a measured session whose every MCP call was covered still put
-~300 shell decisions to the user because this check certified only
-the MCP half. If either half is missing, BEFORE the first recording
-call, tell the user one approval can replace every pipeline prompt
-and offer `tendril_permissions` with `write: true` — it merges the
-per-tool allowlist PLUS the run's shell surface and project-scoped
-Write/Edit (with deny guards so that grant can never touch
-`./.claude/**` or `./.git/**`) into the project's
-settings.local.json (idempotent, touches nothing else). PREFIXES:
-pass `figmaPrefix` (and `tendrilPrefix` for non-plugin installs)
-spelled exactly as THIS session names those tools — the part before
-`__get_metadata` — whenever they differ from the plugin defaults; a
-measured figma-remote session got six entries that could never
-match because the write assumed the plugin shape. These are
-CONVENIENCE grants, not a security boundary — the command's output
-names what they trade (read verbs read any file without prompting;
-host Bash patterns are best-effort prefix matches; the CLI
-subcommand grants carry the CLI's own write surface). RELAY that
-note to the user with the offer, never soften it, and say BOTH that
-a reload is required AND that the current session keeps prompting
-until then — the savings land next session; that is expected, not a
-failure. Offer ONCE per session; never run it unoffered (it edits
-the user's settings), and if declined, proceed without mentioning
-it again.
+Permissions: do nothing up front. Hosts now default to auto/allow
+modes where pipeline calls never prompt, and an unprompted consent
+dialog is itself the alarm it claims to prevent. Act ONLY on
+observable evidence of the ask-mode case — you cannot see the host's
+permission prompts (measured: a session full of prompts had a
+prompt-conditioned offer never fire), but you CAN see a denied or
+long-pending tool call, and the user can tell you they are being
+prompted for everything. When that evidence exists, name the
+one-command fix ONCE and let them decide: `tendril_permissions` with
+`write: true` merges the pipeline's per-tool allowlist plus the run's
+shell surface and project-scoped Write/Edit (deny guards keep the
+grant out of `./.claude/**` and `./.git/**`) into the project's
+settings.local.json — idempotent, touches nothing else. Pass
+`figmaPrefix`/`tendrilPrefix` exactly as THIS session names those
+tools when they differ from the plugin defaults. These are
+CONVENIENCE grants, not a security boundary — relay the command's own
+trade-off note unsoftened, and say that a reload is required and the
+current session keeps prompting until then. Never run it unasked; if
+declined, proceed and drop the subject.
 
 Long generator/score waits: silence is not a health signal, and POLL
 cadence is not RELAY cadence (run 13: rounds landed 6–11 minutes apart,
@@ -233,9 +210,11 @@ Batch runs (several components in one session):
    cost of not delegating is invisible until paid (12 hand-recorded
    reps ≈ 45k main-context tokens that cheap recorders absorb at ~11k
    each in their own context). So ask ONCE, IMMEDIATELY after `plan`
-   returns, before recording anything: "This is N poses — recording
-   can run in parallel on cheap background agents, or serially here
-   (slower and costlier). Run it in parallel?" A yes makes every
+   returns, before recording anything. You do not have to remember
+   the wording: whenever poses remain, the plan output carries
+   `recordingDelegation` — its `question` is the ask, verbatim, and
+   `recommendedRecorders` is the fan-out for that queue. Put it to
+   the user with the other plan-time questions. A yes makes every
    later spawn user-requested, generators included. If this session
    cannot spawn subagents at all, or the `tendril-recorder` agent is
    not in your registry, record serially yourself with the same
@@ -494,9 +473,13 @@ machine token can fake.
 The terminal sequence on green: `verify` → the inspect sheet (written
 automatically) → `tendril_publish` → surface what it returns:
 
-- `status: "approval-pending"` (a component's FIRST publish): relay the
-  `approveUrl` VERBATIM and name the `approveAsAccount` it carries —
-  state the account explicitly even when it looks obvious, because the
+- `status: "approval-pending"` (a component's FIRST publish): surface
+  the ask THE MOMENT it appears, as its own short message with the
+  `approveUrl` VERBATIM on its own line — the link is the user's single
+  next action, and it opens a card that explains exactly what approving
+  publishes (the same card also waits on their portal home page, so
+  either door works). Name the `approveAsAccount` it carries — state
+  the account explicitly even when it looks obvious, because the
   approving browser can be signed in to a different account than this
   session runs under, and a mismatch strands the user on an empty
   approve page. Do not urge them to approve: approving includes

package/dist/tendril-mcp.js

@@ -25,7 +25,7 @@ var optStr = (d) => z.string().optional().describe(d);
 var TOOLS = [
   {
     name: "tendril_record_plan",
-    description: "ENTRY POINT for implementing/building a React component from a Figma design or figma.com URL \u2014 start the Tendril pipeline here (after loading the tendril skill, if installed). Plans a recording session: computes the rep queue (anchor + one-factor + conflict crosses) from the verbatim get_metadata response (pass its blocks via metadataParts \u2014 no file to write) and persists the set manifest. Resumes if the set already exists. The output may carry USER QUESTIONS \u2014 defaultsToConfirm (which pose is the component's default) or a multiple-component-sets error (which set to record): render them to a present user and apply the answers via `defaults` / `componentSet`; non-interactive runs follow each question's stated fallback. It may also carry `interactionStatesToConfirm` \u2014 the recording holds no hover/focus/pressed state, so nothing shows how the component behaves when someone uses it: say its `statement` and `designFix` in that SAME one message (the fix is a Figma variant, not code). It is a disclosure, not a gate \u2014 no answer is required and recording proceeds regardless. The output also carries `feasibilityCheck`: the call arithmetic for this queue plus the free `whoami` check that turns it into a verdict \u2014 complete that handshake BEFORE the first recording call, and surface the verdict to the user when the set does not fit their daily allowance.",
+    description: "ENTRY POINT for implementing/building a React component from a Figma design or figma.com URL \u2014 start the Tendril pipeline here (after loading the tendril skill, if installed). Plans a recording session: computes the rep queue (anchor + one-factor + conflict crosses) from the verbatim get_metadata response (pass its blocks via metadataParts \u2014 no file to write) and persists the set manifest. Resumes if the set already exists. The output may carry USER QUESTIONS \u2014 defaultsToConfirm (which pose is the component's default) or a multiple-component-sets error (which set to record): render them to a present user and apply the answers via `defaults` / `componentSet`; non-interactive runs follow each question's stated fallback. It may also carry `interactionStatesToConfirm` \u2014 the recording holds no hover/focus/pressed state, so nothing shows how the component behaves when someone uses it: say its `statement` and `designFix` in that SAME one message (the fix is a Figma variant, not code). It is a disclosure, not a gate \u2014 no answer is required and recording proceeds regardless. When poses remain it also carries `recordingDelegation` \u2014 a QUESTION, asked once, before the first recording call: parallel cheap recorders or serially in your own context. Put it to a present user with the other plan-time questions and honour the answer; if this session cannot spawn subagents, do not ask \u2014 record serially and say so in one line. The output also carries `feasibilityCheck`: the call arithmetic for this queue plus the free `whoami` check that turns it into a verdict \u2014 complete that handshake BEFORE the first recording call, and surface the verdict to the user when the set does not fit their daily allowance.",
     schema: z.object({
       setDir: str("recording set directory to create/resume"),
       component: str("component/system name"),