@sellable/install 0.1.218 → 0.1.220

package/README.md

@@ -35,8 +35,9 @@ Campaign creation, foundation memory, content capture/ideation, and post
 drafting run inside Claude Code or Codex, where the Sellable MCP tools and
 approval flows are available.
 
-Install is auth-free by default. If you do not pass a token, the agent handles
-Sellable sign-in on the first campaign run with a magic-link handoff.
+Install is auth-free by default. The normal path is first-run login: launch a
+Sellable workflow in Claude Code or Codex and the agent handles Sellable
+sign-in with a browser magic-link handoff.
 
 The installer uses package stdio MCP by default:
 
@@ -64,14 +65,15 @@ verification in one path:
 curl -fsSL "https://app.sellable.dev/api/v2/cli/install" | sh
 ```
 
-For CI/scripted installs, get a Sellable API token from:
+For scripted fallback after browser login, paste the command shown by Sellable:
 
-```text
-https://app.sellable.dev/settings
+```bash
+sellable auth set <token> --workspace-id <workspace_id>
 ```
 
-Then pass it with `--token` / `SELLABLE_TOKEN` plus `--workspace-id` /
-`SELLABLE_WORKSPACE_ID`.
+For CI/env-only installs, operators can still pass `--token` / `SELLABLE_TOKEN`
+plus `--workspace-id` / `SELLABLE_WORKSPACE_ID`. Do not use env vars as the
+primary human setup path.
 
 Auth is stored once at:
 

package/bin/sellable-install.mjs

@@ -605,13 +605,26 @@ async function loadAuthIfPresent(opts) {
   return opts;
 }
 
+function redactTokensForLog(value) {
+  if (Array.isArray(value)) {
+    return value.map((item) => redactTokensForLog(item));
+  }
+  if (value && typeof value === "object") {
+    return Object.fromEntries(
+      Object.entries(value).map(([key, item]) => [
+        key,
+        key.toLowerCase().includes("token") && typeof item === "string"
+          ? redact(item)
+          : redactTokensForLog(item),
+      ])
+    );
+  }
+  return value;
+}
+
 function writeJson(path, data, opts) {
   if (VERBOSE) {
-    const redacted = JSON.stringify(
-      { ...data, token: redact(data.token) },
-      null,
-      2
-    );
+    const redacted = JSON.stringify(redactTokensForLog(data), null, 2);
     logVerbose(`${C.grey}Writing ${path}: ${redacted}${C.reset}`);
   }
   if (opts.dryRun) return;
@@ -628,6 +641,56 @@ function readExisting(path) {
   }
 }
 
+function mergeAuthConfig(raw, auth) {
+  const existing =
+    raw && typeof raw === "object" && !Array.isArray(raw) ? raw : {};
+  const authFields = {
+    token: auth.token,
+    activeWorkspaceId: auth.activeWorkspaceId,
+    apiUrl: auth.apiUrl,
+  };
+
+  if (existing.activeEnv && existing.environments) {
+    const activeEnv = existing.activeEnv;
+    const envConfig = existing.environments[activeEnv];
+    if (
+      !envConfig ||
+      typeof envConfig !== "object" ||
+      Array.isArray(envConfig)
+    ) {
+      throw new Error(
+        `Unknown active environment '${activeEnv}' in ${authPath()}`
+      );
+    }
+    return {
+      ...existing,
+      environments: {
+        ...existing.environments,
+        [activeEnv]: {
+          ...envConfig,
+          ...authFields,
+        },
+      },
+    };
+  }
+
+  return {
+    ...existing,
+    ...authFields,
+  };
+}
+
+function writeAuthSetConfig({ token, workspaceId, apiUrl, dryRun }) {
+  const configPath = authPath();
+  const raw = readExisting(configPath) || {};
+  const config = mergeAuthConfig(raw, {
+    token,
+    activeWorkspaceId: workspaceId || null,
+    apiUrl,
+  });
+  writeJson(configPath, config, { dryRun });
+}
+
 function sellableHostEnvPath() {
   return join(homedir(), ".local", "sellable", "app-sellable-dev", ".env");
 }
@@ -925,8 +988,11 @@ const CREATE_CAMPAIGN_ALLOWED_TOOLS = [
   "mcp__sellable__save_rubrics",
   "mcp__sellable__get_campaign_table_schema",
   "mcp__sellable__select_campaign_cells",
+  "mcp__sellable__record_campaign_review_batch",
   "mcp__sellable__queue_campaign_cells",
   "mcp__sellable__wait_for_campaign_processing",
+  "mcp__sellable__refill_campaign_sends",
+  "mcp__sellable__resolve_campaign_fill_route",
   "mcp__sellable__fill_campaign_horizon",
   "mcp__sellable__start_campaign_message_preparation",
   "mcp__sellable__get_campaign_message_preparation_status",
@@ -3909,18 +3975,31 @@ async function main() {
       }
       const token = rawArgs[2];
       const authSetFlags = rawArgs.slice(3);
-      const dryRun = authSetFlags.includes("--dry-run");
-      const unknownAuthSetFlag = authSetFlags.find(
-        (arg) => arg !== "--dry-run"
-      );
-      if (unknownAuthSetFlag) {
-        console.error(`Unknown auth set option: ${unknownAuthSetFlag}`);
+      let dryRun = false;
+      let workspaceId = "";
+      for (let i = 0; i < authSetFlags.length; i += 1) {
+        const flag = authSetFlags[i];
+        if (flag === "--dry-run") {
+          dryRun = true;
+          continue;
+        }
+        if (flag === "--workspace-id") {
+          const value = authSetFlags[i + 1];
+          if (!value || value.startsWith("--")) {
+            console.error("Missing value for --workspace-id");
+            process.exit(2);
+          }
+          workspaceId = value;
+          i += 1;
+          continue;
+        }
+        console.error(`Unknown auth set option: ${flag}`);
         process.exit(2);
       }
       if (!token) {
         console.error(
-          "Usage: sellable auth set <token>\n" +
-            "Get the token from the Sellable browser confirm page (after clicking the magic link)."
+          "Usage: sellable auth set <token> [--workspace-id <id>]\n" +
+            "Use this only when the Sellable browser login page shows a manual fallback command."
         );
         process.exit(2);
       }
@@ -3932,23 +4011,22 @@ async function main() {
         );
         process.exit(2);
       }
-      // Bypass writeAuth() — its workspaceId guard early-returns on missing
-      // workspaceId, but on the auth-set path we don't have one yet (next MCP
-      // call hydrates it). Write the same shape directly.
+      // Bypass writeAuth() because auth-set is a first-run browser fallback:
+      // the workspace id is optional for legacy fallback pages, and existing
+      // config metadata must be preserved.
       // Skip installSelfShim() — by definition the user has the shim already
       // (they invoked `sellable auth set` from it).
       const apiUrl = process.env.SELLABLE_API_URL || DEFAULT_API_URL;
-      writeJson(
-        authPath(),
-        { token, activeWorkspaceId: null, apiUrl },
-        { dryRun }
-      );
+      writeAuthSetConfig({ token, workspaceId, apiUrl, dryRun });
       if (dryRun) {
         console.log(`Dry run: token would be saved to ${authPath()}`);
       } else {
         console.log(`✓ Token saved to ${authPath()}`);
       }
       console.log(`  apiUrl: ${apiUrl}`);
+      if (workspaceId) {
+        console.log(`  activeWorkspaceId: ${workspaceId}`);
+      }
       console.log(`  Continue in your agent:`);
       console.log(`    Claude Code: /sellable:create-campaign`);
       console.log(`    Claude Code: /sellable:foundation`);

package/lib/runtime-verify.mjs

@@ -28,6 +28,8 @@ export const REQUIRED_SELLABLE_MCP_TOOLS = [
   "get_campaign_messages_preview",
   "attach_sequence",
   "attach_recommended_sequence",
+  "refill_campaign_sends",
+  "resolve_campaign_fill_route",
   "start_campaign_message_preparation",
   "get_campaign_message_preparation_status",
   "cancel_campaign_message_preparation",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.218",
+  "version": "0.1.220",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-campaign.md

@@ -44,8 +44,11 @@ allowed-tools:
   - mcp__sellable__save_rubrics
   - mcp__sellable__get_campaign_table_schema
   - mcp__sellable__select_campaign_cells
+  - mcp__sellable__record_campaign_review_batch
   - mcp__sellable__queue_campaign_cells
   - mcp__sellable__wait_for_campaign_processing
+  - mcp__sellable__refill_campaign_sends
+  - mcp__sellable__resolve_campaign_fill_route
   - mcp__sellable__fill_campaign_horizon
   - mcp__sellable__start_campaign_message_preparation
   - mcp__sellable__get_campaign_message_preparation_status
@@ -105,37 +108,54 @@ most one direct `enrich_with_prospeo` sample when row evidence is too thin.
 After filter approval, the browser should move to Filter Leads with
 `currentStep: "apply-icp-rubric"` and show template waiting/approval copy until
 the template is approved.
+If the bounded filter run later returns `0/N` passes, do not immediately find
+new leads. Load `references/sample-validation-loop.md`, run the zero-pass
+rule-relaxability audit, then choose exactly one recovery: revise saved
+rubrics, record a fresh same-source review batch, or change lead source. Change
+source only when safe relaxation and same-source sampling would still fail or
+would pass bad-fit rows.
 The default path stays the existing first campaign-table execution slice:
 review the normal `reviewBatchLimit:15`, approve reviewed draft rows, then move
-to Settings/sequence/final greenlight. Only call
-`fill_campaign_horizon` for explicit source-cleanup horizon-fill requests, such
-as "fill sends from Signal Discovery but not John Cutler posts." Run
-`fill_campaign_horizon({ action:"audit", ... })` first, then apply with the
-returned `stateRevision`. It imports/prepares at most 300 eligible non-excluded
-source rows in the first pass, caps prep batches at 100, skips existing rows
-from excluded post/author sources, and does not launch the campaign. If the
-user only asks for generic extra sends with no source cleanup, use
-`start_campaign_message_preparation` when the user explicitly asks for more
-prepared messages, a send count, or language like "fill up/load sends for these
-senders." Treat those requests as capacity-fill preparation: calculate the
-bounded target from sender capacity when needed, then let the preparation job
-queue pending `Enrich Prospect` cells, wait for ICP/rubric and Generate Message
-cells to cascade, and mark ready or approve only the target cohort. Do not
-count `checkedRows` as enriched rows; it is only the table cursor. Use
+to Settings/sequence/final greenlight. For any plain post-mint fill request
+such as "fill campaigns", "fill up", "refill sends", "max out sends", or
+"load sends", first call `refill_campaign_sends({ mode:"plan", intent:"plain" })`.
+If the user did not include `--yolo`, report the plan and stop. If the user did
+include `--yolo`, call plan first, inspect blockers, then call
+`refill_campaign_sends({ mode:"apply", yolo:true, planRevision, actionIds })`
+using only the selected immutable action IDs from the fresh plan. Plain fill is
+not an alias for `fill_campaign_horizon` or campaign creation. Keep
+`resolve_campaign_fill_route`, `fill_campaign_horizon`, and
+`start_campaign_message_preparation` as fallback/lower-level diagnostics only
+when `refill_campaign_sends` is unavailable or when the refill command itself
+returns an evergreen subplan. `fill_campaign_horizon` is evergreen-only and
+must not be used for regular campaign refill. When more leads are needed, the
+plan must recommend same-campaign source-ladder replenishment; do not create
+warm-post-engager side campaigns, on-demand campaigns, or unrelated campaigns.
+If fallback `resolve_campaign_fill_route` returns `route:"ask_create"`, ask
+whether to create a normal campaign or evergreen campaigns; campaign creation is
+never the default response to plain fill.
+Treat active fills as capacity-fill preparation: calculate the bounded target
+from sender capacity when needed, then let the preparation job queue pending
+`Enrich Prospect` cells, wait for ICP/rubric and Generate Message cells to
+cascade, and mark ready or approve only the target cohort. Do not count
+`checkedRows` as enriched rows; it is only the table cursor. Use
 `progress.enrichedRows`, `progress.needsEnrichRows`, `activeCellCount`,
-`preparedMessages`, `approvedRows`, target, estimated row budget remaining, and
-`stopReason` to explain progress. If the user says "prepare/generate X
-messages", set `targetPreparedMessages:X`, omit `maxRowsToCheck`, and keep
+`preparedMessages`, `approvedRows`, active preparation jobs, sender-health
+blockers, target, estimated row budget remaining, and `stopReason` to explain
+progress. If the user says "prepare/generate X messages", set
+`targetPreparedMessages:X`, omit `maxRowsToCheck`, and keep
 `approvalMode:"mark_ready"`. The backend calibrates on at least 100 actually
 enriched rows, estimates the row budget from observed rubric/pass yield, caps
 `maxRowsToCheck` at 300, then continues in batches capped at 100 newly checked
 rows. It will not pull another row batch while the current checked batch still
 has queueable or active cells. If the user says "approve X messages", use
 `approvalMode:"approve"` but still do not launch. If the user says "schedule X
-sends" or asks to fill sender sends, use `approvalMode:"approve"` to approve
-exactly the bounded X-message cohort during preparation, then continue through
-sender, sequence, and final launch greenlight; the launch path must verify that
-bounded cohort and must not broad approve-all.
+sends" or asks to fill sender sends, use `approvalMode:"approve"` only when
+the user explicitly asked for approval, approve exactly the bounded X-message
+cohort during preparation, then re-read scheduled counts; if scheduler-owned
+cells are not present, report prepared/approved/ready awaiting scheduler
+instead of success. Final launch remains a separate explicit user greenlight
+and must verify that bounded cohort and must not broad approve-all.
 When approving reviewed draft rows in the campaign table, resolve the actual
 visible `Approved` cells with `select_campaign_cells({ columnRole: "approved",
 rowSelector: { type: "rowIds", rowIds } })` and `update_cell` those returned
@@ -893,7 +913,11 @@ updates.
 
 1. Call `mcp__sellable__get_auth_status({})`.
 2. If auth is not OK with `error.type === "config"` or `error.type === "auth"`,
-   the user has not signed in yet. Run the FTUX magic-link handoff:
+   the user has not signed in yet. Run first-run login through the FTUX
+   magic-link handoff. If a browser page or tool guidance gives the user a
+   manual fallback, it must be
+   `sellable auth set <token> --workspace-id <workspace_id>`. Do not instruct
+   the user to hand-edit JSON auth config.
 
    a. Say to the user verbatim:
 
@@ -1081,7 +1105,11 @@ updates.
    rubrics and Message Drafting runs.
    After rubrics save, keep Filter Rules visible for approval; after approval,
    move to Filter Leads with `currentStep: "apply-icp-rubric"` and wait there
-   while Message Drafting finishes or the template is approved.
+   while Message Drafting finishes or the template is approved. After template
+   approval and bounded scoring, a `0/N` pass result must run the
+   sample-validation zero-pass rule-relaxability audit before any lead-source
+   revision; the three allowed recoveries are rubric revision, fresh
+   same-source sample, or source revision.
    If filters are skipped, launch Message Drafting before moving to
    Messages/message review; updating `currentStep` to `messages` is not proof
    that the background worker started. Queue the bounded campaign-table