@sellable/install 0.1.283 → 0.1.284

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.283",
+  "version": "0.1.284",
   "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`,