@sellable/install 0.1.23 → 0.1.25
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/bin/sellable-install.mjs +11 -3
- package/package.json +1 -1
package/bin/sellable-install.mjs
CHANGED
|
@@ -15,7 +15,7 @@ import { createInterface } from "node:readline/promises";
|
|
|
15
15
|
const DEFAULT_API_URL = "https://app.sellable.dev";
|
|
16
16
|
const DEFAULT_SERVER_PACKAGE =
|
|
17
17
|
process.env.SELLABLE_MCP_PACKAGE || "@sellable/mcp";
|
|
18
|
-
const CODEX_PLUGIN_VERSION = "0.1.
|
|
18
|
+
const CODEX_PLUGIN_VERSION = "0.1.25";
|
|
19
19
|
const CODEX_PLUGIN_COMPAT_VERSIONS = [
|
|
20
20
|
"0.1.8",
|
|
21
21
|
"0.1.9",
|
|
@@ -32,6 +32,8 @@ const CODEX_PLUGIN_COMPAT_VERSIONS = [
|
|
|
32
32
|
"0.1.20",
|
|
33
33
|
"0.1.21",
|
|
34
34
|
"0.1.22",
|
|
35
|
+
"0.1.23",
|
|
36
|
+
"0.1.24",
|
|
35
37
|
];
|
|
36
38
|
const INSTALL_PACKAGE_SPEC = `@sellable/install@${CODEX_PLUGIN_VERSION}`;
|
|
37
39
|
|
|
@@ -866,10 +868,16 @@ The user should be able to compare "here is the template" against "here is what
|
|
|
866
868
|
one real prospect would receive" before approving, and understand exactly how
|
|
867
869
|
the tokens should and should not be filled.
|
|
868
870
|
|
|
871
|
+
Every token needs a fallback. If the row does not have clean data for a token,
|
|
872
|
+
the approval view should say whether to use a safe segment-level phrase, omit
|
|
873
|
+
the sentence, or revise the message. It should include the exact fallback
|
|
874
|
+
example, like \`omit the noticed... line\` or \`use "operators"\`. Missing data
|
|
875
|
+
should never produce robotic or creepy copy.
|
|
876
|
+
|
|
869
877
|
Approved token guidance is part of the campaign, not just the review. When a
|
|
870
878
|
campaign is minted, the approved brief should carry forward the token fill
|
|
871
|
-
rules and examples: good fills, good omits, bad fills, and why
|
|
872
|
-
blocked.
|
|
879
|
+
rules and examples: good fills, good omits, bad fills, fallback rules, and why
|
|
880
|
+
the bad fills are blocked.
|
|
873
881
|
|
|
874
882
|
For lead-source decisions, confidence comes from concrete counts. Do not say
|
|
875
883
|
"strong sample", "73% match", or "meaningful concentration" without showing the
|