@sellable/install 0.1.228 → 0.1.230

package/bin/sellable-install.mjs

@@ -37,7 +37,7 @@ function getInstallVersion() {
   }
 }
 
-const CODEX_PLUGIN_VERSION = "0.1.45";
+const CODEX_PLUGIN_VERSION = "0.1.47";
 const CODEX_PLUGIN_COMPAT_VERSIONS = [
   "0.1.8",
   "0.1.9",

package/package.json

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

package/skill-templates/create-evergreen-campaigns.md

@@ -24,10 +24,19 @@ run without user input, or similar, run in **automation mode**:
 - Reconcile structure and record any template/config polish as `created`,
   `reused`, `repaired`, `flagged`, or `blocked`.
 - Choose the automation depth from the invoking prompt:
+  - Sparse `--yolo` create/repair invocations default to customer-visible completion:
+    when the user says run/create/repair/setup `$sellable:create-evergreen-campaigns`,
+    create evergreen campaigns, or similar without saying heartbeat/structure-only,
+    set `depth:"customer_visible"`. Customers usually expect usable campaigns,
+    not empty shells.
   - **Structure-only reconcile** is for heartbeat prompts that only say to
-    ensure slots exist. It may create/reuse shells and apply metadata repairs,
-    but it does not create rows, generate messages, approve rows, or attach new
-    send work.
+    ensure slots exist. Only choose `depth:"structure_only"` for
+    heartbeat/ensure-slots-only automation where the prompt explicitly says it
+    does not need source rows, generated messages, approvals, or sequence. It may
+    create/reuse shells and apply metadata repairs, but it does not create rows,
+    generate messages, approve rows, or attach new send work.
+    Short form: only choose `depth:"structure_only"` for
+    heartbeat/ensure-slots-only runs.
   - **Customer-visible completion** is required when the prompt says full
     campaign, customer-ready, send-review-ready, went through
     `$sellable:create-campaign`, fill out, approve one, only needs enrich and
@@ -138,6 +147,16 @@ for that shared-only sender. Example: if Justin already has a Post Engagers
 campaign and Jell/Hulan should only participate in the two shared campaigns,
 call `setup_evergreen_campaigns` with `postEngagerSenderIds:["<justin id>"]`
 and `sharedSenderIds:["<justin id>","<jell or hulan id>"]`.
+If the operator says to keep a protected existing Post Engagers campaign unchanged
+and create/repair only the shared lanes, pass `postEngagerSenderIds:[]` and the
+full shared sender set in `sharedSenderIds`. Do not include the protected active
+Post Engagers lane as a reuse packet in that shared-only execution scope: an
+ACTIVE protected lane can correctly produce a backend `launched_campaign`
+blocker and would make the whole yolo plan non-autoExecutable even though the
+operator asked to leave it untouched. Inventory and waterfall proof may mention
+the protected lane, but selectedActionIds and lane workers must cover only the
+shared lane packets.
+Short form: Do not include the protected active Post Engagers lane as a reuse packet when the operator requested only shared lane execution.
 
 When senders are ambiguous, ask which sender ids belong in the Post Engagers
 sender scope and which belong in the shared lane sender scope before planning.
@@ -155,6 +174,12 @@ plan execution, paid InMail spend, or ambiguous target choice. Stop on wrong
 workspace, cleanup/archive/delete need, stale plan, disconnected sender,
 duplicate candidate, unsafe side effect, missing source proof, or missing
 message proof.
+In exec/automation mode, do not call `request_user_input`. If a plan under
+`--yolo` returns `autoExecutable:false` and the run cannot receive interactive
+bounded delegated approval, stop with
+`blocked: bounded_approval_unavailable_in_exec_mode` before any mutation and
+state whether the operator should rerun with a safe autoExecutable plan, narrower
+sender scopes, explicit bindings, or an interactive session.
 
 When safe-yolo is blocked only because the plan needs normal setup work, ask
 for a **bounded delegated approval** over the rendered current plan instead of
@@ -219,6 +244,15 @@ written by the current worker, stop with `blocked: stale_receipt_artifact`
 before parent verify or completion. A streaming worker or branch worker is
 acceptable only when it writes a fresh durable per-lane receipt artifact as it
 works.
+When visible Codex app thread tools are unavailable but local Codex CLI is
+available, the accepted durable streaming-worker command shape is:
+`codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> -`.
+The approval and sandbox flags must come before the `exec` subcommand for Codex
+CLI builds that expose `-a`/`-s` only at top level. Do not use
+`codex exec --ask-for-approval never ...` or `codex exec -a never ...`; those
+forms fail on current customer CLI installs. Pipe the lane packet prompt on
+stdin, require the worker to write `workerDispatch.receiptArtifactHint`, and
+pass exactly one lane packet per worker.
 `multi_agent_v1.spawn_agent`, raw `spawn_agent`, or any opaque Task/subagent
 runtime that cannot expose a visible thread id or durable receipt artifact is
 not accepted as command-level UAT proof and must not be used for mutating