@sellable/install 0.1.264 → 0.1.265

package/package.json

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

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

@@ -269,11 +269,23 @@ 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
-asking for each substep. The approval packet must name the workspace id, sender
-ids, lane keys, campaign/table ids or create intents, source/import caps,
-generate-message caps, route-proof approval policy, selectedActionIds,
-planRevision, allowed side-effect classes, and stop conditions. After that one
-approval covers the current planRevision, the parent may act on behalf of the
+asking for each substep. The approval request must be rendered from the plan's
+`approvalSummary`, not handwritten from raw lane packets alone. Show:
+
+- `workspaceId`, `planRevision`, and `selectedActionIds`.
+- Sender scopes with display names and ids: Post Engagers senders and shared-lane senders.
+- `campaignsToCreate`: each campaign/lane name, action id, create intent, attached senders, and allowed side effects.
+- `campaignsToUpdate`: each existing campaign/table id, current status/step, attached senders, and exact repairs or setup side effects.
+- `campaignsToVerifyOnly`: existing campaigns that will only be verified/read.
+- `campaignsLeftUntouched`: existing campaigns attached to selected senders but excluded from the current selected lane scope, with the reason.
+- Source/import caps, generate-message caps, route-proof approval policy, allowed side-effect classes, forbidden side effects, blockers, and stop conditions.
+
+If `approvalSummary.approvalQuestion` is present, use it as the short approval
+question and put the detailed buckets underneath. Do not ask a vague yes/no
+question that only says "run evergreen setup" or "approve this plan" without
+naming the campaigns to create, existing campaigns to update/verify, campaigns
+left untouched, and attached senders. After that one approval covers the current
+planRevision and selectedActionIds, the parent may act on behalf of the
 operator and execute the selectedActionIds end to end. Do not ask again for
 substep approvals for source import, create-campaign choices, Message Drafting,
 sequence attach/precheck, or exactly one route-proof approval when those actions
@@ -283,6 +295,7 @@ workspace id, sender ids, source/list id, campaign/table id, new campaign/table
 id, planRevision, actionId, selectedActionIds, allowed side effects, caps,
 status, or blocker set outside the approved packet.
 The short rule: one approval covers the current planRevision and selectedActionIds.
+The approval clarity rule: the operator approves named campaign create/update/verify/untouched buckets and attached senders, not a generic evergreen run.
 The execution rule: act on behalf of the operator; do not ask again for substep approvals while work stays within the lane packet, approved caps, approved side-effect classes, and route-proof approval policy.
 The drift rule: stop and re-plan when ids, caps, blockers, side-effect classes, or any new campaign/table id leave the approved packet.