@tendrilapp/cli 0.1.24 → 0.1.26

package/dist/SKILL.md

@@ -69,13 +69,29 @@ fidelity gap" was a missing font weight one check away; a stop rule is
 for avoiding thrash, never for converting an unverified hypothesis into
 a final answer.
 
+Concurrency, whether that is several components in one session or one
+large set:
+- Every agent in flight spends ONE shared Figma budget, and Figma
+  meters per minute as well as per day, so parallelism sets the burst
+  rate. Scale recorders to the total pose count: up to ~30 poses,
+  four; ~30–100 poses, two; beyond ~100 poses, record serially and
+  pace it — a large set has no slack to burn on a per-minute limit.
+  A measured 8-wide batch hit its rate limit (per-piece resume
+  recovered, but the stall is avoidable).
+- COUNT EVERY AGENT THAT CALLS FIGMA, not every agent you launched:
+  a recorder NEVER spawns its own recorders. It records the queue it
+  was handed and stops. A measured 4-wide run peaked at double the
+  intended rate because two recorders spawned children that kept
+  calling after their parents reported done — the parent's "done" is
+  not proof its calls have stopped. To split a large queue further,
+  hand out the extra slices yourself so the whole count stays in one
+  place.
+
 Batch runs (several components in one session):
-- Cap concurrent recorders at FOUR. All recorders share one Figma
-  desktop MCP server; a measured 8-wide batch hit its rate limit
-  (per-piece resume recovered, but the stall is avoidable).
 - Batch the questions: plan ALL sets first, then put every
-  defaults-to-confirm and the one model question to the user together
-  — never one dialog per component.
+  defaults-to-confirm, every missing-interaction-state disclosure and
+  the one model question to the user together — never one dialog per
+  component, and never mid-generation.
 - Create candidate directories with a bare `mkdir -p <dir>` — no
   `&&`-compounds. Compound variants each need their own permission
   approval; the bare form is one grant for the whole batch.
@@ -110,8 +126,38 @@ Batch runs (several components in one session):
      which X should it show?" — the heuristic's pick is Recommended;
      a different answer re-plans via `defaults` (free until the first
      envelope is ingested, frozen after).
-   Recording cost is stated in figmaCallEstimate, never asked about —
-   proceed with what the user provided.
+   - `interactionStatesToConfirm`: the component set has no hover,
+     focus or pressed variant, so nothing recorded shows how it looks
+     while someone is using it — and what is never recorded is never
+     checked. Say its `statement` and `designFix` as written. This one
+     is a DISCLOSURE, not a question: no answer is needed, nothing is
+     blocked, and the fix (if the user wants one) is a new variant in
+     Figma, not a change in the code. Say only what
+     `recordedVariants` contains — never guess from the component's
+     name what kind of control it is.
+   FEASIBILITY, before the first recording call: the plan output
+   states the call arithmetic for this queue (poses × calls per pose).
+   Turn it into a verdict with one free check — IF your Figma server
+   exposes a `whoami` tool, call it: it names the seat and plan and is
+   exempt from Figma's tool-call limits. Then divide the queue's call
+   count by the daily allowance that seat carries. Never quote an
+   allowance from memory; use the one whoami reports. Not every
+   transport has it — the remote Figma MCP server does, the local Dev
+   Mode server does not — so if yours does not, say the allowance is
+   UNKNOWN and show the plan's own hint as the unverified figure it is
+   marked as, rather than presenting a guess as a checked number. If the set fits inside one
+   day, record and say nothing about cost — a set that comfortably
+   fits is not worth the user's attention. If it does NOT fit, stop
+   and tell the user in plain numbers before recording anything:
+   "336 poses × 3 = 1,008 Figma calls. Your Full seat on Professional
+   allows 200/day, so this set needs about 5 days." Then let them
+   choose: (a) pace it across days — a rate limit loses no recorded
+   work, the set persists after every pose and re-running the same
+   command resumes; (b) record fewer poses — theirs to decide alone,
+   because it buys calls with coverage and there is no tool for it:
+   they re-plan with `--sample` in their own terminal; (c) a seat or
+   plan with a larger daily allowance. Never sample on their behalf,
+   and never start a set you have computed cannot finish.
    Later, `tendril_engine_brief` may carry `fontProvisioning` (the
    design uses a family the local kit lacks). First run
    `tendril fonts resolve --set <recording-dir>` yourself — it fetches
@@ -146,7 +192,9 @@ Batch runs (several components in one session):
    from it. SPEED: after `plan` the whole queue is known and reps are
    independent — fan out across parallel subagents in any order (use
    the cheap `tendril-recorder` agent; recording is transcription,
-   not reasoning). HOST-POLICY GATE (measured, run 6): many hosts
+   not reasoning), with HOW MANY set by the concurrency rule above:
+   it scales down as poses go up, and no recorder spawns recorders.
+   HOST-POLICY GATE (measured, run 6): many hosts
    forbid spawning subagents unless the user requested it, and the
    cost of not delegating is invisible until paid (12 hand-recorded
    reps ≈ 45k main-context tokens that cheap recorders absorb at ~11k

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. Recording cost is stated in figmaCallEstimate, never asked about \u2014 proceed with what the user provided.",
+    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.",
     schema: z.object({
       setDir: str("recording set directory to create/resume"),
       component: str("component/system name"),