@sellable/install 0.1.289 → 0.1.291

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@sellable/install",
3
- "version": "0.1.289",
3
+ "version": "0.1.291",
4
4
  "type": "module",
5
5
  "description": "One-command installer for Sellable MCP in Claude Code and Codex",
6
6
  "bin": {
@@ -135,19 +135,23 @@ campaigns are start-eligible refill candidates; read refill state before decidin
135
135
  whether to prep, approve, start, or skip. Do not treat them as archived inventory.
136
136
 
137
137
  For interactive Codex or Claude Code sessions, that approval must use the
138
- host-native structured question gate, not plain chat:
138
+ host-native structured question gate, but the full approval packet must render
139
+ in normal chat first:
139
140
 
140
141
  - Codex: use `request_user_input`.
141
142
  - Claude Code: use `AskUserQuestion`.
142
143
 
143
- The approval question must present the final refill step with exactly two
144
- choices: `Accept` and `Decline`. The question body must include the operator
145
- output packet: workspace, sender scope, a campaign-by-campaign table with
146
- campaign name, sender names, action, target count/cap, source/list, and
147
- blocker/skip reason, then exact ids, expected side effects, forbidden actions,
148
- and the stop condition. Treat `Accept` as permission for only the rendered
149
- target, caps, mode, and side effects. Treat `Decline` as a hard stop with no
150
- mutation.
144
+ Render the operator output packet in normal chat immediately before opening the
145
+ structured question. Use Markdown so the packet is readable: workspace, sender
146
+ scope, a campaign-by-campaign table with campaign name, sender names, action,
147
+ target count/cap, source/list, and blocker/skip reason, then exact ids, expected
148
+ side effects, forbidden actions, and the stop condition. Then open the
149
+ structured approval question with exactly two choices: `Accept` and `Decline`.
150
+ Keep that question compact, for example "Approve the refill packet rendered
151
+ above?" Do not paste the full packet into the structured question panel. Treat
152
+ `Accept` as permission for only the exact packet rendered immediately above,
153
+ including target, caps, mode, and side effects. Treat `Decline` as a hard stop
154
+ with no mutation.
151
155
 
152
156
  If Christian includes `--yolo` in the same refill request, treat that flag as
153
157
  auto-accept for the rendered bounded refill packet after the required fresh state