@sellable/install 0.1.20 → 0.1.22
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 +14 -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.22";
|
|
19
19
|
const CODEX_PLUGIN_COMPAT_VERSIONS = [
|
|
20
20
|
"0.1.8",
|
|
21
21
|
"0.1.9",
|
|
@@ -29,6 +29,8 @@ const CODEX_PLUGIN_COMPAT_VERSIONS = [
|
|
|
29
29
|
"0.1.17",
|
|
30
30
|
"0.1.18",
|
|
31
31
|
"0.1.19",
|
|
32
|
+
"0.1.20",
|
|
33
|
+
"0.1.21",
|
|
32
34
|
];
|
|
33
35
|
const INSTALL_PACKAGE_SPEC = `@sellable/install@${CODEX_PLUGIN_VERSION}`;
|
|
34
36
|
|
|
@@ -856,8 +858,17 @@ or plain paths to the files behind the decision. The artifact links are a backup
|
|
|
856
858
|
for inspection, not a replacement for showing the content in chat.
|
|
857
859
|
|
|
858
860
|
This applies especially to message approvals. Never ask someone to approve a
|
|
859
|
-
message they cannot see. Show the subject,
|
|
860
|
-
|
|
861
|
+
message they cannot see. Show the subject, tokenized template, a filled sample
|
|
862
|
+
prospect version, good fill example, good omit example, bad fill example, why
|
|
863
|
+
the bad fill is wrong, token notes, your take, and suggested adjustment first.
|
|
864
|
+
The user should be able to compare "here is the template" against "here is what
|
|
865
|
+
one real prospect would receive" before approving, and understand exactly how
|
|
866
|
+
the tokens should and should not be filled.
|
|
867
|
+
|
|
868
|
+
Approved token guidance is part of the campaign, not just the review. When a
|
|
869
|
+
campaign is minted, the approved brief should carry forward the token fill
|
|
870
|
+
rules and examples: good fills, good omits, bad fills, and why the bad fills are
|
|
871
|
+
blocked.
|
|
861
872
|
|
|
862
873
|
For lead-source decisions, confidence comes from concrete counts. Do not say
|
|
863
874
|
"strong sample", "73% match", or "meaningful concentration" without showing the
|