@sellable/install 0.1.282 → 0.1.284

package/package.json

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

@@ -62,13 +62,15 @@ long-form contract below:
    callable, return `blocked: missing_visible_or_durable_lane_worker_runtime`
    before mutation.
 4. Write one compact prompt file per selected lane using the matching
-   `createCampaignGoals[].goalPrompt`, plus only the receipt path and canonical
-   receipt requirement. Do not paste the full evergreen skill, lane packet,
-   receipt schema, repair history, or verifier checklist into the worker prompt.
-   The worker goal is simple: run `$sellable:create-campaign` normally for that
-   campaign goal, use the evergreen-selected provider/source only as internal
-   sourcing metadata, and write the receipt. The parent does not create campaign
-   shells.
+   `createCampaignGoals[].goalPrompt` as the authoritative campaign task, plus
+   only the lane packet, receipt path, side-effect caps, and canonical receipt
+   requirement. Paste the goal prompt verbatim; do not replace it with a
+   handcrafted `Goal:` paragraph. Do not paste the full evergreen skill, receipt
+   schema, repair history, verifier checklist, or lane-specific copy checklist
+   into the worker prompt. The worker goal is simple: run
+   `$sellable:create-campaign` normally for that campaign goal, use the
+   evergreen-selected provider/source only as internal sourcing metadata, and
+   write the receipt. The parent does not create campaign shells.
 5. Collect fresh durable receipts, verify with the original planRevision and
    selectedActionIds, then run the idempotency plan and show sample messages.
 
@@ -407,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
@@ -442,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
@@ -497,10 +506,17 @@ path/thread id, stop with `blocked: parent_mutated_before_worker_receipt` and
 do not continue setup in the parent.
 Short form: dispatch every selected lane worker before shell creation.
 Short form: do not call `setup_evergreen_campaigns` with `mode:"apply"` from the parent.
-Use a compact worker prompt: include lane packet JSON, original selectedActionIds,
-original planRevision, parent postEngagerSenderIds, parent sharedSenderIds,
-receiptArtifactPath, workspace id, sender ids, side-effect caps, and the
-instruction to load packaged prompts through MCP.
+Use a compact worker prompt: include the exact matching
+`createCampaignGoals[].goalPrompt`, lane packet JSON, original
+selectedActionIds, original planRevision, parent postEngagerSenderIds, parent
+sharedSenderIds, receiptArtifactPath, workspace id, sender ids, side-effect
+caps, and the instruction to load packaged prompts through MCP. The worker
+prompt must explicitly state the authority order:
+`createCampaignGoals[].goalPrompt` first, then loaded `$sellable:create-campaign`
+/ `create-campaign-v2` / `generate-messages` prompts and assets, then evergreen
+lane/receipt proof requirements. Evergreen packet fields and receipt rules are
+operational proof context only; they must not become campaign brief copy,
+message-writing instructions, or generated customer-facing text.
 The worker prompt must include the exact filter status rule:
 `filterDecisionReceipt.status:"applied"` only; never `completed`, `confirmed`,
 `done`, or any other alias.
@@ -541,8 +557,10 @@ 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'
-Use $sellable:create-evergreen-campaigns as the governing skill for this one lane worker.
+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.
 
 Workspace id: <workspaceId>
 Parent planRevision: <planRevision>
@@ -556,7 +574,26 @@ 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):
+<createCampaignGoalPrompt>
+
+Authority order:
+1. The create-campaign goal prompt above is the campaign task.
+2. Loaded `$sellable:create-campaign`, `create-campaign-v2`, and
+   `generate-messages` prompts/assets own the campaign brief and message
+   strategy.
+3. The evergreen lane packet and receipt rules below are operational scope and
+   proof requirements only.
+
+Do not paste evergreen lane keys, provider/source names, receipt terms, setup
+plan terminology, verifier fields, or workflow mechanics into the campaign
+brief or generated customer-facing messages. Do not add evergreen-authored
+message-writing rules to the brief; let the loaded create-campaign and
+generate-messages workflow do its job.
 
 Worker lane packet JSON:
 <lane packet JSON>
@@ -566,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
@@ -579,16 +621,19 @@ 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 lane packet, do not inspect
-the filesystem or rerun inventory; stop with `blocked: worker_dispatch_stalled`.
+If any placeholder cannot be filled from the current plan, matching
+`createCampaignGoals[]` entry, or lane packet, do not inspect the filesystem or
+rerun inventory; stop with `blocked: worker_dispatch_stalled`.
 `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
@@ -833,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`,
@@ -1276,7 +1325,8 @@ Message, and verify current-revision sample messages before final completion.
      Short form: Do not pass the warm template into Shared Signal Discovery or Shared Cold Fallback.
      Short form: Shared lanes must reject generic product-summary samples.
      Short form: Shared lanes must reject three nearly identical samples.
-     Short form: Shared lanes must reject unsupported intent-assumptive hedges; Shared Signal Discovery may use Dotwork-style topic bridges like "saw you might be interested in [topic], so hope this is relevant", "saw you in a few conversations about [topic], so hope this is relevant", or "hope this is relevant if [topic] is part of the plan" when the source evidence supports the topic and the line does not claim engagement or expose source mechanics.
+     Short form: Shared lanes must reject unsupported low-confidence relevance hedges.
+     Short form: Shared lane message quality is owned by the packaged generate-messages prompt and validation; evergreen does not author source-thread bridge phrasing.
      Short form: Shared lanes must reject internal workflow vocabulary.
      Short form: revise or rerun the packaged create-campaign/generate-messages path.
    - **Post Engagers** first-message style: short, casual, references the
@@ -1317,21 +1367,12 @@ Message, and verify current-revision sample messages before final completion.
      product summaries, or repeated structure are bad. If the first generated
      batch violates these rules, rerun, but record that as a repaired UAT path
      rather than the desired zero-shot path.
-     Use the Dotwork gold-standard shape for Shared Signal Discovery samples
-     when the row supports a topic-level weak signal: "saw you might be
-     interested in [topic], so hope this is relevant", "saw you in a few
-     conversations about [topic], so hope this is relevant", or "saw you in a
-     few conversations around [topic], so hope this is relevant". These bridges
-     are allowed only when source evidence supports the topic and the line does
-     not claim a reaction, comment, sender-authored post, or other engagement
-     that is not proven. Do not use "found you in a thread" or other raw
-     source/discovery mechanics.
-     Shared Signal Discovery InMail subjects should follow the Dotwork plus-sign
-     A + B + C pattern: concrete topic + buyer outcome + useful artifact/picture,
-     for example "initiatives + business outcomes + one live picture".
-     Translate source/tool terms into prospect-facing business language; do not
-     put internal workflow
-     vocabulary such as "Codex-style workflow", "MCP", "agent workflows",
+     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
+     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
      message one. Also avoid generic product-process nouns such as "dashboard",
      "workflow", "source", "send-ready copy", "reviewed prospect lists",
@@ -1342,7 +1383,8 @@ Message, and verify current-revision sample messages before final completion.
      Short form: Shared Signal Discovery uses no self-intro such as "I'm building Sellable".
      Short form: Shared Signal Discovery uses no self-intro such as "We're building Sellable".
      Short form: Shared Signal Discovery uses no "I've put together".
-     Short form: topic-level bridges, including "saw you might be interested in [topic], so hope this is relevant", "saw you in a few conversations about/around [topic], so hope this is relevant", and "hope this is relevant if [topic] is part of the plan", are allowed for Shared Signal Discovery when evidence-backed and not engagement-claiming; do not use bare "might be interested" as a generic intent claim.
+     Short form: Shared Signal Discovery may use "saw you around conversations about [topic], so hope this is relevant" when source-supported.
+     Short form: topic-level bridge rules are owned by the packaged generate-messages prompt and validation, not by the evergreen wrapper.
      Short form: no internal workflow vocabulary such as "Codex-style workflow", "MCP", "agent workflows", "Claude Code", or "Claude-style agent workflows".
    - **Shared Cold Fallback** first-message style: cold, direct, and cohesive.
      It must not pretend there was engagement, must not say "saw you pop up",
@@ -1358,14 +1400,15 @@ Message, and verify current-revision sample messages before final completion.
      Sellable/Codex/Claude-Code feature summary
      across prospects. This is a single-message cold path unless the approved
      create-campaign message workflow proves a better delivery format.
-     Do not use source-thread hedges such as "hope this is relevant", "might be
-     interested", or "saw you in a few conversations" in Shared Cold Fallback.
-     Start from a concrete role, company, or buyer-problem observation instead.
-     Do not use a repeated
-     product-definition paragraph such as "Sellable is a GTM system" across
-     samples; every reviewed cold sample should be specific enough to the role,
-     company, or problem that the three sample messages do not share the same
-     body skeleton.
+     Do not open with "hope this is relevant" or a similar low-confidence
+     relevance hedge in Shared Cold Fallback. Do not use a repeated product-definition paragraph such
+     as "Sellable is a GTM system" across samples; every reviewed cold sample
+     should be specific enough to the role, company, or problem that the three
+     sample messages do not share the same body skeleton.
+     Do not use source-thread hedges such as "might be interested", "saw you
+     around conversations about...", or "saw you in a few conversations" in
+     Shared Cold Fallback. Start from a concrete role, company, or buyer-problem
+     observation instead.
      Do not use mechanical Sellable process language such as "campaign idea into
      prospects, filters, messages, and sequence setup", "sequence-prospects",
      "dashboard overhead", "campaign map", "send-ready copy", or "reviewed
@@ -1382,7 +1425,8 @@ Message, and verify current-revision sample messages before final completion.
      Short form: Shared Cold Fallback uses no "I've put together".
      Short form: Shared Cold Fallback uses no opt-out shrug such as "If this isn't relevant, ignore me".
      Short form: Shared Cold Fallback uses no product-stack dump.
-     Short form: no "hope this is relevant", "might be interested", or "saw you in a few conversations" in Shared Cold Fallback; Shared Signal Discovery has the topic-level conversation-bridge exception above.
+     Short form: Shared Cold Fallback uses no low-confidence relevance hedge such as "hope this is relevant".
+     Short form: no "hope this is relevant", "might be interested", "saw you around conversations about", or "saw you in a few conversations" in Shared Cold Fallback; Shared Signal Discovery has the topic-level conversation-bridge exception above.
      Short form: no repeated product-definition paragraph such as "Sellable is a GTM system".
     - Customer-visible evergreen lanes must enable ICP filtering before Message
       Drafting. This applies to Post Engagers, Shared Signal Discovery, and
@@ -1483,13 +1527,18 @@ Message, and verify current-revision sample messages before final completion.
       or a product-stack dump that repeats the same
       Sellable/Codex/Claude-Code feature summary across prospects. For all
       shared lanes, reject generic product-summary samples, repeated
-      near-identical samples, intent-assumptive hedges such as "might be
-      interested", source-context mismatches such as "saw you in a few
-      conversations" in Shared Cold Fallback, internal workflow vocabulary, any
-      sample with non-empty `issues`, and any preserved Post Engagers opener;
-      revise or rerun the packaged create-campaign/generate-messages path before
-      reporting completion. Do not approve or final-report samples
-      with `verdict:"passed"` and non-empty `issues`.
+      near-identical samples, unsupported low-confidence relevance hedges, internal
+      workflow vocabulary, any sample with non-empty `issues`, and any preserved
+      Post Engagers opener; revise or rerun the packaged
+      create-campaign/generate-messages path before reporting completion. Do not
+      approve or final-report samples with `verdict:"passed"` and non-empty
+      `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
+      Fallback samples must still reject source/conversation hedges such as
+      `"hope this is relevant"`, `"might be interested"`, or `"saw you in a few
+      conversations"`.
    - The first review batch exists and at least 3 review rows have generated
      messages from the approved brief. If fewer than 3 usable rows exist, report
      the actual count and why.