@sellable/install 0.1.283 → 0.1.285

package/package.json

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

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

@@ -409,30 +409,37 @@ 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 --skip-git-repo-check -m <worker-model> -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. `--skip-git-repo-check` belongs after `exec` because current customer and VPS Codex CLI builds expose it
+`codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
+The approval, sandbox, and reasoning-effort config flags must come before the
+`exec` subcommand for Codex CLI builds that expose `-a`/`-s`/`-c` only at top
+level. `--skip-git-repo-check` belongs after `exec` because current customer and VPS Codex CLI builds expose it
 as an `exec` subcommand flag, not a top-level flag. 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.
 When launching durable Codex CLI workers from an automation parent, pass an
-explicit supported worker model instead of relying on the Codex CLI default
-model. Use the parent runtime model when known, for example:
-`codex -a never -s danger-full-access exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
+explicit supported worker model and explicit `xhigh` reasoning effort instead
+of relying on the Codex CLI defaults. Use the parent runtime model when known,
+for example:
+`codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
 In Codex CLI, the parent runtime model is visible in the run header as
 `model: <model-name>`. Copy that exact model string into child worker launches
 first. If the parent header says `model: gpt-5.5`, launch workers with
-`-m gpt-5.5`; do not invent or probe nearby aliases such as `gpt-5.3-codex`,
-`gpt-5.2`, `gpt-5-codex`, `codex-latest`, or `codex-mini-latest` before trying
-the exact parent model. A one-line probe must count as supported only when it
-exits 0 and returns the requested output; a session header followed by a
-`not supported` error is rejected, not accepted.
-Do not rely on the Codex CLI default model; some customer and VPS installs
-default to unavailable model aliases. If the parent cannot identify a supported
-worker model and a test `codex exec -m <worker-model>` launch is rejected, stop
-with `blocked: worker_model_unavailable` before mutation.
+`-m gpt-5.5` plus `-c model_reasoning_effort=xhigh`; do not invent or probe
+nearby aliases such as `gpt-5.3-codex`, `gpt-5.2`, `gpt-5-codex`,
+`codex-latest`, or `codex-mini-latest` before trying the exact parent model. A
+one-line probe must include the same `-c model_reasoning_effort=xhigh` override
+and count as supported only when it exits 0 and returns the requested output; a
+session header followed by a `not supported` error is rejected, not accepted.
+Do not rely on the Codex CLI default model or default reasoning effort; some
+customer and VPS installs default to unavailable model aliases or to `high`
+reasoning. `-m gpt-5.5` alone is not enough. If a child worker reports GPT 5.5
+with `high` reasoning, treat that as a launcher bug, relaunch with the explicit
+`xhigh` config before mutation, and do not ask the user to continue through the
+model-quality warning. If the parent cannot identify a supported worker model
+and launch it with `xhigh` reasoning, stop with
+`blocked: worker_model_unavailable` before mutation.
 When wrapping multiple local Codex CLI workers in a shell launcher, run the
 wrapper with `/bin/bash -lc` or another explicitly chosen portable shell. Do not
 rely on zsh-specific behavior. Do not use `status` as a shell variable because
@@ -444,7 +451,7 @@ Do not embed `<<'WORKER_PROMPT'` heredocs inside a single quoted or double
 quoted `/bin/bash -lc '...'` command string; nested quoting is brittle and can
 truncate the first worker before mutation. For multi-worker launchers, write one
 plain prompt file per lane under the current run directory, then start each
-worker with `codex -a never -s danger-full-access exec --skip-git-repo-check -m "$WORKER_MODEL" -C "$REPO" -o
+worker with `codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m "$WORKER_MODEL" -C "$REPO" -o
 "$worker_final_file" - < "$worker_prompt_file"`. Keep launcher shell variables
 double-quoted and keep the prompt heredoc only in a standalone script/prompt-file
 write step, not inside an already quoted shell argument. If the first launcher
@@ -550,7 +557,7 @@ launchers, write the same prompt body to `<worker-prompt-file>` and launch the
 worker with stdin redirected from that file:
 
 ```
-codex -a never -s danger-full-access exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
+codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
 Use $sellable:create-campaign as the governing campaign workflow for this one lane worker.
 Use the evergreen plan/packet below only for lane scope, source metadata,
 postconditions, side-effect caps, and durable receipt proof.
@@ -567,7 +574,8 @@ Write the durable receipt to this exact path: <receiptArtifactPath>
 
 If your runtime exposes a goal tool, create or maintain this exact goal:
 complete action <actionId> only when <receiptArtifactPath> exists as valid JSON
-for this lane or when a blocked receipt has been written at that same path.
+for this lane, or only for the accepted Post Engagers no-source blockers listed
+below when a blocked receipt has been written at that same path.
 
 Create-campaign goal prompt (authoritative; paste verbatim from the matching
 createCampaignGoals[].goalPrompt):
@@ -595,6 +603,11 @@ Use mcp__sellable only. Do not use admin tools, direct DB, Prisma, SQL, web sear
 Do not launch, start, schedule, send, or use paid InMail.
 For filter proof, durable receipt status must be `filterDecisionReceipt.status:"applied"` only; never `completed`, `confirmed`, `done`, or aliases.
 For generated messages, `update_cell` is allowed only for the semantic Approved checkbox. Never use `update_cell` for generated message text/body/sample copy. Bad copy requires `revise_message_template_and_rerun` or brief/template revision plus Generate Message rerun. Any generated-message cell override is `blocked: generated_message_cell_override`.
+If `bootstrap_create_campaign.modelQuality.status === "warn"` because the child
+worker reports GPT 5.5 with `high` reasoning, that is a parent launcher
+configuration bug, not an operator approval path inside the worker. Stop before
+mutation, tell the parent to relaunch this lane with
+`-c model_reasoning_effort=xhigh`, and do not mark the worker goal complete.
 Complete only this lane. Do not end with narration only. Before your final
 response, run a local file-existence and JSON self-check for
 <receiptArtifactPath>. If the lane succeeded, write the canonical success
@@ -608,12 +621,14 @@ receipt, not a worker crash: use one of
 `post_engagers_no_sender_owned_posts`, or
 `post_engagers_source_author_mismatch`, include the source/readback evidence,
 and stop without scraping third-party authors or generating misleading warm
-copy. The terminal condition is filesystem proof that <receiptArtifactPath>
-exists.
+copy. Any other blocked receipt is not a goal-complete success condition; it is
+a failed lane return that the parent must report or repair. The terminal success
+condition is filesystem proof that <receiptArtifactPath> exists with a success
+receipt, or an accepted Post Engagers no-source blocked/no-op receipt.
 WORKER_PROMPT
 
 # Multi-worker launcher equivalent:
-codex -a never -s danger-full-access exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - < <worker-prompt-file>
+codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - < <worker-prompt-file>
 ```
 
 If any placeholder cannot be filled from the current plan, matching
@@ -863,7 +878,11 @@ by someone else. Use the explicit blocker codes
 `acceptedLaneBlockers`, so the parent can report the truthful no-op instead of
 retrying invalid source repair. This exception does not apply to shared lanes,
 bad generated copy, stale plans, target mismatch, missing receipt files, launch
-or schedule side effects, or arbitrary worker failures.
+or schedule side effects, model-quality/preflight blockers, worker model
+availability blockers, or arbitrary worker failures. A blocked receipt outside
+the accepted Post Engagers source codes must not be treated as completion, must
+not be used to mark the worker goal complete, and must not let the parent report
+the evergreen command as complete.
 
 All step proof objects must live under `createCampaignStepReceipt`. Do not put
 `createCampaignWorkflowReceipt`, `campaignBriefReceipt`,
@@ -1339,9 +1358,11 @@ Message, and verify current-revision sample messages before final completion.
      senders, the copy must be safe for every attached sender to send. Do not
      use founder-only first person such as "I'm building", "my company", "my
      team", or "I have a framework" unless every attached sender can credibly
-     say it. Prefer sender-agnostic company/team language such as "we're
-     helping CX teams..." or "at cxconnect.ai, we help..." and one clear
-     problem question.
+     say it. Prefer sender-agnostic company/team language grounded in the
+     current workspace's verified company, offer, buyer, and proof, plus one
+     clear problem question. Do not reuse unrelated fixture/example customer
+     names, domains, verticals, product categories, use cases, or proof points
+     unless the current workspace/company research independently supports them.
      Before Message Drafting runs, the campaign brief must already include
      these shared-lane hard avoids and source-use rules. Do not rely on a
      failed first generation batch to discover that self-intros, generic
@@ -1351,7 +1372,10 @@ Message, and verify current-revision sample messages before final completion.
      Shared Signal Discovery samples may use a supported topic bridge such as
      "saw you around conversations about [high-level topic], so hope this is
      relevant" when the topic is grounded in source evidence and not
-     activity-log phrasing. Translate source/tool terms into prospect-facing
+     activity-log phrasing. Signal Discovery is only a lead-source provider;
+     do not infer a product category, buyer pain, offer, asset, CTA, or
+     provider-themed message direction from the lane/provider name.
+     Translate source/tool terms into prospect-facing
      business language; do not put internal workflow vocabulary such as
      "Codex-style workflow", "MCP", "agent workflows",
      "Claude Code", or "Claude-style agent workflows" in customer-facing
@@ -1516,7 +1540,10 @@ Message, and verify current-revision sample messages before final completion.
       `issues`.
       Shared Signal Discovery samples may use `"saw you around conversations
       about [high-level topic], so hope this is relevant"` when the topic is
-      supported by source evidence and not activity-log phrasing. Shared Cold
+      supported by source evidence and not activity-log phrasing. Signal
+      Discovery is only a lead-source provider; reject provider-themed campaign
+      copy unless that language is independently supported by the current
+      workspace/company research. Shared Cold
       Fallback samples must still reject source/conversation hedges such as
       `"hope this is relevant"`, `"might be interested"`, or `"saw you in a few
       conversations"`.