npm - @sellable/install - Versions diffs - 0.1.320 → 0.1.321 - Mend

@sellable/install 0.1.320 → 0.1.321

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.

Files changed (5) hide show

package/HERMES-SLACK-PROFILE-SCOPING.md +44 -146
package/README.md +20 -103
package/bin/sellable-install.mjs +17 -23
package/package.json +1 -1
package/skill-templates/refill-sends.md +7 -42

package/HERMES-SLACK-PROFILE-SCOPING.md CHANGED Viewed

@@ -1,169 +1,67 @@
 # Hermes Slack Profile Scoping
-Use this when creating or updating customer Hermes profiles that need Slack
-access.
-## Default Rule
-For Sellable-managed customer channels, use one dedicated Slack app/token pair
-per active Hermes customer profile. Run native `hermes -p <profile> gateway run`
-for that profile only. Do not run multiple active Hermes profile gateways
-against the same `SLACK_APP_TOKEN`.
-The customer's Slack app is bound to the exact Slack channel id and the
-customer's profile-local Sellable MCP config. Customer profiles must not store
-or read Sellable Admin MCP credentials, admin Slack app tokens, or sibling
-profile config.
-The shared dispatcher remains a fallback/research path only. Use it only when
-Sellable Admin explicitly owns one shared listener and route registry.
-The 2026-07-06 Hostinger POC proved the native Hermes listener for the
-`sellable-admin` profile with the existing `Sellable Reply Bot` app in
-`#team-chat`: a human mention produced a new Hermes session and a threaded bot
-reply. Treat that as proof that the gateway/listener path works for one owning
-profile, not as approval for multiple active customer profiles sharing one app
+Sellable customer profiles use one dedicated native Slack app/token pair, one
+workspace-locked plain Sellable MCP, and one native Hermes s6 gateway. There is
+no shared dispatcher, route registry, listener fallback, or shared customer app
 token.
-The same day, the `acme` profile reused the same redacted Slack token
-fingerprints for an outbound-only smoke to `#sellable-acme` via:
-```bash
-hermes --profile acme send --to slack:C0BFERDV3N0 --subject '[Hermes acme smoke]' ...
-```
-That succeeded and is useful as an internal smoke test. It does not change the
-inbound listener rule: each active customer profile needs its own native Slack
-app token pair unless Sellable Admin deliberately chooses the dispatcher
-fallback.
-## Which Slack Values Are Enough
-For outbound sends and ordinary Slack Web API calls, the important value is the
-profile-local `SLACK_BOT_TOKEN`.
-For native Hermes live listening through Slack Socket Mode, the profile also
-needs `SLACK_APP_TOKEN`, an app-level `xapp-...` token with `connections:write`.
-`SLACK_APP_ID`, `SLACK_CLIENT_ID`, `SLACK_CLIENT_SECRET`,
-`SLACK_SIGNING_SECRET`, `SLACK_VERIFICATION_TOKEN`, `SLACK_TEAM_ID`, and
-`SLACK_OPERATOR_EMAIL` do not replace `SLACK_APP_TOKEN`.
-## Required Slack App Shape
-Outbound Slack sends can work with fewer permissions. Native Hermes inbound
-listening needs the Slack app itself to be configured for Socket Mode and event
-delivery:
+The production Sellable Reply Bot remains separate HTTP-interactivity product
+infrastructure. Keep Socket Mode off and keep its request URL at
+`https://app.sellable.dev/api/v2/slack/interactions`.
-- Enable Socket Mode.
-- Create an app-level token with `connections:write`.
-- Install the bot with `app_mentions:read`, `channels:history`,
-  `channels:read`, `chat:write`, `groups:history`, `groups:read`,
-  `im:history`, `im:read`, `mpim:history`, `mpim:read`, and `users:read`.
-- Subscribe bot events for `app_mention`, `message.channels`,
-  `message.groups`, `message.im`, and `message.mpim`.
-- Reinstall the app after changing scopes or event subscriptions.
+## Public Boundary
-If the Slack app has `incoming-webhook`, Slack will ask for a webhook channel
-during reinstall. Pick the profile home channel. That webhook selection does
-not replace `SLACK_ALLOWED_CHANNELS`; keep the profile-local allowlist explicit.
-## Profile Bootstrap Command
-Use the Sellable installer profile bootstrap:
+Customer onboarding is owned by the Sellable Admin native-app skill through one
+public command:
 ```bash
-sellable hermes profile bootstrap \
-  --profile acme \
-  --profiles-root /srv/hermes/profiles \
-  --workspace-id ws_acme \
-  --workspace-name Acme \
-  --token-file /run/secrets/sellable-acme-token \
-  --slack-bot-token "$SLACK_BOT_TOKEN" \
-  --slack-app-token "$SLACK_APP_TOKEN" \
-  --slack-home-channel C0ACME12345 \
-  --slack-home-channel-name sellable-acme \
-  --slack-allowed-users U0OPERATOR1 \
-  --slack-require-mention true \
-  --json
+sellable-admin-install hermes customer bootstrap --mode <mode> [approved inputs]
 ```
-If `--slack-home-channel` is supplied and `--slack-allowed-channels` is omitted,
-the installer writes `SLACK_ALLOWED_CHANNELS=<home-channel-id>` automatically.
-That makes the profile fail closed to the customer channel by default.
+The operator uses read-only `plan`, then approved `apply`, and later
+`resume|status|verify|rebuild|rollback` with the persisted `runId`. Do not ask
+the operator to coordinate the public Sellable installer, Slack API/CLI,
+cloud-browser, Gmail, profile, or gateway internals separately.
-Use `--slack-allowed-channels C...,G...` only when a profile is intentionally
-allowed to listen in more than one channel. Pass Slack IDs, not `#channel-name`
-strings or wildcards.
+The approval packet binds exact team/workspace/channel/profile/user identity,
+customer Sellable token-file ref, `gpt-5.6-sol`, redacted evidence root, and the
+exact tested Admin install/MCP and Sellable install/MCP candidates plus all four
+SHA-256 values.
-## Resulting Profile Env
+## Public Sellable Installer Role
-For the dedicated customer Slack app model, the profile-local `.env` should
-contain only scoped Slack keys for that profile:
-```env
-SLACK_BOT_TOKEN=...
-SLACK_APP_TOKEN=...
-SLACK_HOME_CHANNEL=C0ACME12345
-SLACK_HOME_CHANNEL_NAME=sellable-acme
-SLACK_ALLOWED_CHANNELS=C0ACME12345
-SLACK_ALLOWED_USERS=U0OPERATOR1
-SLACK_REQUIRE_MENTION=true
-```
-Keep the file mode at `0600`. Do not copy raw tokens into planning docs, chat,
-or committed artifacts. Record token fingerprints only.
-The profile's Hermes MCP env must also include the profile-local Sellable
-config, customer workspace lock, and fail-closed guard:
+The Admin factory calls the pinned `@sellable/install` candidate internally and
+passes the pinned `@sellable/mcp` candidate through `--mcp-package`. The public
+installer writes profile-local Sellable config and Hermes MCP env with:
 ```yaml
-SELLABLE_CONFIG_PATH: /srv/hermes/profiles/acme/sellable/config.json
-SELLABLE_CONFIGS_DIR: /srv/hermes/profiles/acme/sellable/configs
-SELLABLE_LOCK_WORKSPACE_ID: ws_acme
+SELLABLE_CONFIG_PATH: /opt/data/profiles/<customerSlug>/sellable/config.json
+SELLABLE_CONFIGS_DIR: /opt/data/profiles/<customerSlug>/sellable/configs
+SELLABLE_LOCK_WORKSPACE_ID: <approvedWorkspaceId>
 SELLABLE_REQUIRE_WORKSPACE_LOCK: "1"
 ```
-`SELLABLE_REQUIRE_WORKSPACE_LOCK=1` means an unbound customer profile fails
-closed before making Sellable API calls instead of falling back to shared or
-admin config state. Only the `sellable-admin` profile should provision,
-inspect, or repair other profiles.
-For the shared dispatcher model, do not copy the shared `SLACK_BOT_TOKEN` or
-`SLACK_APP_TOKEN` into customer profile `.env` files. The dispatcher owns those
-tokens and route metadata decides the customer profile.
+It does not create Slack apps, handle Slack tokens, install Admin MCP, or choose
+the profile/workspace/channel from prompt text.
-## Shared Dispatcher Ownership
-The shared Slack dispatcher and its route registry are fallback Sellable Admin
-surfaces. This customer-facing installer must not create shared route bundles or
-write shared listener tokens. Sellable Admin owns Slack app creation and profile
-provisioning, then calls this installer for profile-local Sellable runtime
-bootstrap inside the already-provisioned Hermes profile.
-## Verification
-Run the installer and dispatcher UAT before publishing installer changes:
-```bash
-npm run test:unit -- tests/install-package/agent-preferences.test.ts
-scripts/run-phase92-hermes-profile-bootstrap-uat.sh --mode local-temp
-scripts/run-phase92-hermes-profile-bootstrap-uat.sh --mode linux-shaped
-scripts/run-phase031-hermes-slack-dispatcher-uat.sh --mode local-fixture
-```
+## Customer Isolation
-Expected proof:
+Customer profiles are blank-created. They contain:
-- profile-local Sellable config paths remain authoritative
-- generated profile `.env` has `SLACK_HOME_CHANNEL`
-- generated profile `.env` has `SLACK_ALLOWED_CHANNELS`
-- `acme` allowlist points at the `sellable-acme` fixture channel id
-- redaction scan passes
+- dedicated profile-local Slack runtime secrets in mode-`0600` storage
+- exact channel and allowed-human ID allowlists
+- customer-safe manifest with no slash/App Home/assistant/DM/MPIM surfaces
+- the current `openai-codex` `gpt-5.6-sol` model object
+- Hermes root OAuth fallback from `/opt/data/auth.json`
+- pinned plain Sellable MCP locked to one approved workspace
+- one profile-specific native s6 gateway
-## Current Phase 03 Status
+They never contain customer-local `auth.json`, provider pools, OpenRouter/raw
+OpenAI keys, Sellable Admin MCP/admin skills, browser/Gmail/provisioning
+credentials, TOTP material, or sibling data.
-Phase 03 proved the profile-scoped installer path, outbound Hermes send path,
-and live Slack listener for the `sellable-admin` profile. Phase 03.1 now targets
-dedicated native Slack apps per customer profile, profile-local Sellable MCP
-locks, and fail-closed customer profile behavior so managed customer channels
-can be onboarded through the VPS without local-only browser state, manual SSH
-edits, or untracked processes.
+Direct MCP proof before gateway start must show one intended active/visible
+workspace, `siblingInventoryFetched=false`, and no Admin MCP. Slack acceptance
+then requires real API/CLI, secret-file, s6 process, same-thread reply,
+negative-isolation, restart, rollback, rebuild, and redaction receipts tied to
+the immutable package hashes.

package/README.md CHANGED Viewed

@@ -83,120 +83,37 @@ Auth is stored once at:
 ~/.sellable/config.json
 ```
-## Hermes Profile-Scoped Installs
+## Hermes Customer Profiles
-For a single local Hermes profile, point Sellable auth and memory at the profile
-instead of the global `~/.sellable/config.json`:
+Customer onboarding is owned by the Sellable Admin native customer bootstrap:
 ```bash
-profile="$HOME/.hermes/profiles/acme"
-sellable --host hermes \
-  --sellable-config-path "$profile/sellable/config.json" \
-  --sellable-configs-dir "$profile/sellable/configs"
+sellable-admin-install hermes customer bootstrap --mode <mode> [approved inputs]
 ```
-That writes `SELLABLE_CONFIG_PATH` and `SELLABLE_CONFIGS_DIR` into
-`mcp_servers.sellable.env`, so first-run login, `get_auth_status`, workspace
-switches, and Sellable memory all use the same profile-local files. Hosted MCP
-mode does not receive local filesystem paths.
+That command is the sole operator-facing interface. It calls the exact pinned
+`@sellable/install` tarball internally and passes the exact pinned
+`@sellable/mcp` tarball through `--mcp-package`. Do not ask an operator to run
+the public installer, supply Slack tokens in argv, edit profile files, or manage
+the gateway as separate onboarding steps.
-For zero-shot local or Hostinger/Linux VPS bootstrap, use the profile command:
+The internal profile stage writes profile-local Sellable paths and the exact
+workspace boundary:
-```bash
-sellable hermes profile bootstrap \
-  --profile acme \
-  --profiles-root /srv/hermes/profiles \
-  --workspace-id ws_acme \
-  --workspace-name Acme \
-  --token-file /run/secrets/sellable-acme-token \
-  --json
-```
-It creates:
-```text
-/srv/hermes/profiles/acme/config.yaml
-/srv/hermes/profiles/acme/sellable/config.json
-/srv/hermes/profiles/acme/sellable/configs/
-/srv/hermes/profiles/acme/skills/sellable/
-/srv/hermes/profiles/acme/.env        # only when Slack token inputs are supplied
+```yaml
+SELLABLE_CONFIG_PATH: /opt/data/profiles/<customerSlug>/sellable/config.json
+SELLABLE_CONFIGS_DIR: /opt/data/profiles/<customerSlug>/sellable/configs
+SELLABLE_LOCK_WORKSPACE_ID: <approvedWorkspaceId>
+SELLABLE_REQUIRE_WORKSPACE_LOCK: "1"
 ```
-Bootstrap also writes `SELLABLE_LOCK_WORKSPACE_ID=<workspace-id>` and
-`SELLABLE_REQUIRE_WORKSPACE_LOCK=1` into the profile's Hermes MCP env.
-Customer profiles are therefore locked to their own Sellable workspace:
-Sellable MCP requests are forced to that workspace, workspace switching/creation
-is blocked, workspace listings are filtered, and a missing lock fails closed
-instead of falling back to shared/admin config. Use the `sellable-admin` profile
-for provisioning or cross-profile inspection.
+The locked MCP requests only the approved workspace, blocks workspace switching
+and creation, and reports `siblingInventoryFetched=false`. The customer profile
+must contain no Admin MCP, admin token, customer-local OAuth, or sibling config.
 See [`HERMES-SLACK-PROFILE-SCOPING.md`](./HERMES-SLACK-PROFILE-SCOPING.md) for
-the customer Slack isolation contract and Socket Mode token requirements.
-If no token is supplied, bootstrap still creates a pending
-`sellable/config.json` so the profile path is concrete from the first MCP
-launch. Finish auth with:
-```bash
-sellable auth set <token> --workspace-id <workspace_id> \
-  --sellable-config-path /srv/hermes/profiles/acme/sellable/config.json
-```
-Slack Socket Mode tokens can be written profile-locally:
-```bash
-sellable hermes profile bootstrap \
-  --profile acme \
-  --profiles-root /srv/hermes/profiles \
-  --workspace-id ws_acme \
-  --slack-bot-token "$SLACK_BOT_TOKEN" \
-  --slack-app-token "$SLACK_APP_TOKEN"
-```
-The Slack app must also be configured for inbound Socket Mode delivery. Outbound
-Slack Web API sends can work before this is complete, but Hermes will not hear
-mentions until the app has Socket Mode enabled, an app-level token with
-`connections:write`, bot scopes/events for `app_mention` plus channel/group/IM
-message events, and a fresh workspace reinstall after scope or event changes.
-Scope the profile to its customer channel at install time:
-```bash
-sellable hermes profile bootstrap \
-  --profile acme \
-  --profiles-root /srv/hermes/profiles \
-  --workspace-id ws_acme \
-  --slack-bot-token "$SLACK_BOT_TOKEN" \
-  --slack-app-token "$SLACK_APP_TOKEN" \
-  --slack-home-channel C0ACME12345 \
-  --slack-home-channel-name sellable-acme \
-  --slack-allowed-users U0OPERATOR1 \
-  --slack-require-mention true
-```
-When `--slack-home-channel` is supplied without
-`--slack-allowed-channels`, bootstrap writes
-`SLACK_ALLOWED_CHANNELS=<home-channel-id>` too. That fail-closes a customer
-profile to the intended channel by default. Use
-`--slack-allowed-channels C...,G...` only when a profile is deliberately allowed
-to listen in multiple channels. Pass channel IDs, not `#channel-name`, and use
-separate Slack bot/app tokens per customer profile when you need hard isolation
-between concurrently listening Hermes profiles.
-Customer profiles should use customer-scoped Sellable credentials. A shared
-Sellable admin token can work for internal admin automation, but it is weaker
-isolation and should not be the default for customer profiles. After changing
-Hermes profile config, restart the gateway/session or run `/reload-mcp` and
-`/reload-skills`.
-Validate the active profile with the same path inputs:
-```bash
-SELLABLE_CONFIG_PATH=/srv/hermes/profiles/acme/sellable/config.json \
-SELLABLE_CONFIGS_DIR=/srv/hermes/profiles/acme/sellable/configs \
-sellable --verify-only --host hermes --json \
-  --artifact /srv/hermes/profiles/acme/sellable/verify-runtime.json
-```
+the dedicated native Slack app, root OAuth fallback, immutable package, s6
+gateway, rebuild, and live UAT contract.
 Claude Code, Codex, and Hermes are configured to launch the same packaged MCP server. The
 installer also writes Sellable agent definitions from the packaged `agents/`

package/bin/sellable-install.mjs CHANGED Viewed

@@ -213,26 +213,19 @@ Auth:
   also pass --sellable-config-path or set SELLABLE_CONFIG_PATH so auth and MCP
   runtime use the same profile-local config file.
-Hermes profile bootstrap:
-  sellable hermes profile bootstrap --profile acme --profiles-root /srv/hermes/profiles --workspace-id ws_acme --token-file /run/secrets/sellable-token --json
-  sellable hermes profile bootstrap --profile-root "$HOME/.hermes/profiles/acme" --workspace-id ws_acme --json
-  Bootstrap writes <profileRoot>/config.yaml, <profileRoot>/sellable/config.json,
-  <profileRoot>/sellable/configs, Sellable Hermes skills, and optional
-  <profileRoot>/.env Slack token and channel-scope keys. For customer profiles,
-  pass --slack-home-channel; bootstrap defaults SLACK_ALLOWED_CHANNELS to that
-  exact channel id unless --slack-allowed-channels is supplied. Use
-  customer-scoped Sellable credentials and customer-scoped Slack credentials for
-  customer profiles; shared admin tokens are weaker isolation and should remain
-  internal-only. Bootstrap writes SELLABLE_REQUIRE_WORKSPACE_LOCK=1 whenever a
-  workspace id is supplied, so a customer profile fails closed if the workspace
-  lock is later removed or not yet provisioned.
-Hermes shared Slack dispatcher:
-  Shared listener setup and route-registry validation are internal Sellable
-  Admin responsibilities. This customer-facing installer only bootstraps a
-  profile-local Sellable runtime after Sellable Admin provisions the profile
-  and dispatcher route.
+Hermes customer profile stage:
+  Managed customer onboarding uses only:
+  sellable-admin-install hermes customer bootstrap --mode <mode> [approved inputs]
+  The Admin state machine invokes this package's profile bootstrap internally
+  with exact token-file, workspace-lock, profile-root, and --mcp-package inputs.
+  Operators must not use the low-level profile command to coordinate Slack,
+  profile, or gateway onboarding manually. Customer profiles use root Codex
+  OAuth fallback and contain no local auth.json, provider pool, or Admin MCP.
+Hermes customer Slack runtime:
+  Each customer profile uses its own dedicated native Slack app and gateway.
+  Sellable Admin owns the single resumable customer bootstrap interface.
 `;
 }
@@ -2099,9 +2092,9 @@ Desktop, then start a new thread.
 1. Call \`mcp__sellable__get_auth_status({})\`.
 2. Resolve the target workspace id from the user request, automation config, or install-time workspace mapping. Pass \`workspaceId\` on every scheduled or \`--yolo\` refill tool call. Missing \`workspaceId\` in scheduled or \`--yolo\` mode is a blocker; return \`WORKSPACE_REQUIRED\` instead of running against shared config state. Do not solve automation workspace uncertainty by changing the shared active workspace.
-3. Normalize invocation arguments with \`mcp__sellable__refill_sends({ yolo, executionMode, requireWorkspace, workspaceId, senders, senderIds, senderNames, actionTypes, targetDate, untilDate })\` when the host exposes typed MCP tools. Type shape: \`refill_sends({ yolo?: boolean, executionMode?: "manual" | "scheduled" | "yolo", requireWorkspace?: boolean, workspaceId?: string, senders?: string[], senderIds?: string[], senderNames?: string[], actionTypes?: ("send_invite" | "send_inmail_closed")[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD" })\`.
+3. Normalize invocation arguments with \`mcp__sellable__refill_sends({ yolo, executionMode, requireWorkspace, workspaceId, senders, senderIds, senderNames, targetDate, untilDate })\` when the host exposes typed MCP tools. Type shape: \`refill_sends({ yolo?: boolean, executionMode?: "manual" | "scheduled" | "yolo", requireWorkspace?: boolean, workspaceId?: string, senders?: string[], senderIds?: string[], senderNames?: string[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD" })\`.
 4. Clover scheduled automation example: \`mcp__sellable__refill_sends({ yolo:false, executionMode:"scheduled", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })\`, then \`mcp__sellable__get_refill_target_plan({ intent:"plain", approvalMode:"mark_ready", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })\`.
-5. Call \`mcp__sellable__get_refill_target_plan({ workspaceId, senders, senderIds, senderNames, actionTypes, targetDate, untilDate })\` before any mutation. Render \`target.eligibleSenderLedger\`, \`target.senderRefillPlans[]\`, and \`target.globalActionQueue\` as the structured packet. Preserve the labels \`Need to prepare\`, \`Goal\`, \`Already sent\`, \`Scheduled\`, \`Ready and waiting to be scheduled\`, and \`Still need\`. In \`--yolo\`, \`mcp__sellable__refill_sends\` maintains a run-local \`refreshedPaidInmailSenderIds\` set, refreshes stale/missing paid InMail facts for each selected paid-InMail sender at most once, reruns \`get_refill_target_plan\`, and returns \`autoPaidInmailRefresh\` plus the post-refresh \`targetPlan\` before choosing the next prep/source-copy/bounded-approval/read-only wait or exact-date sweep action. Refill ladder: approve generated rows only through the explicit bounded approval gate, process existing same-campaign unenriched/unprepared rows before source work, then same-source copy, then provider-aligned source-more. New source/provider switches change reply-rate baseline and are manual alternates, not \`--yolo\` side effects. Do not present paid-credit refresh as the next operator action after \`refill_sends\` returns that post-refresh plan. For exact-date proof, \`mcp__sellable__get_scheduler_fill_capacity\` is read-only and tells how many cells the scheduler will try to place for a sender/action/date. When the planner returns a request-scoped exact-date scheduler sweep, execute \`mcp__sellable__run_scheduler_sweep({ workspaceId, action:"run", targetDate, requestKey, targetShapeRevision })\` once, capture its receipt, and fully reread before another action. It may schedule eligible workspace cells through existing gates, but it never sends directly or bypasses limits. If the returned target is already complete, stop with the no-op receipt. Only non-exact or no-sweep waits use the read-only scheduler wait/re-read loop until projected coverage fills, a concrete non-scheduler blocker appears, or Christian explicitly stops/statuses the run.
+5. Call \`mcp__sellable__get_refill_target_plan({ workspaceId, senders, senderIds, senderNames, targetDate, untilDate })\` before any mutation. Render \`target.eligibleSenderLedger\`, \`target.senderRefillPlans[]\`, and \`target.globalActionQueue\` as the structured packet. Preserve the labels \`Need to prepare\`, \`Goal\`, \`Already sent\`, \`Scheduled\`, \`Ready and waiting to be scheduled\`, and \`Still need\`. In \`--yolo\`, \`mcp__sellable__refill_sends\` maintains a run-local \`refreshedPaidInmailSenderIds\` set, refreshes stale/missing paid InMail facts for each selected paid-InMail sender at most once, reruns \`get_refill_target_plan\`, and returns \`autoPaidInmailRefresh\` plus the post-refresh \`targetPlan\` before choosing the next prep/source-copy/bounded-approval/read-only wait action. Refill ladder: approve generated rows only through the explicit bounded approval gate, process existing same-campaign unenriched/unprepared rows before source work, then same-source copy, then provider-aligned source-more. New source/provider switches change reply-rate baseline and are manual alternates, not \`--yolo\` side effects. Do not present paid-credit refresh as the next operator action after \`refill_sends\` returns that post-refresh plan. For exact-date proof, \`mcp__sellable__get_scheduler_fill_capacity\` is read-only and tells how many cells the scheduler will try to place for a sender/action/date. When ready rows cover the target but scheduled rows do not, \`mcp__sellable__run_scheduler_sweep({ workspaceId, action:"run" })\` may request immediate placement within existing gates and returns a receipt, but it never sends or bypasses limits. If the returned target is already complete, stop with the no-op receipt. If ready rows cover the target but scheduled rows do not, keep the run open in the read-only scheduler wait/re-read loop until projected coverage fills, a concrete non-scheduler blocker appears, or Christian explicitly stops/statuses the run.
 6. Load the canonical prompt and deterministic flow asset via
    \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends" })\`,
    then load \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends-workflow" })\`,
@@ -2112,7 +2105,8 @@ Desktop, then start a new thread.
    facts are present, refresh exact selected sender facts once, rerun
    \`get_refill_target_plan\`, and only then enter \`wait_for_scheduler\` if
    freshness is clean.
-7. Follow the canonical prompt exactly. Do not directly send, bypass scheduler gates, or raw-write scheduler fields. Only the exact rendered paused-campaign start and request-scoped scheduler sweep may use their existing product-gated paths; do not launch, archive, or delete unrelated work.
+7. Follow the canonical prompt exactly. Do not launch, start, archive, delete,
+   or write scheduler rows as part of refill sends.
 ## MCP Prompt Fallback

package/package.json CHANGED Viewed

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

package/skill-templates/refill-sends.md CHANGED Viewed

@@ -83,8 +83,6 @@ Accepted invocation flags in the same user request:
 - `senderIds: <id>, <id>` or `senderNames: <name>, <name>`: explicit selector
   alternatives when the host preserves natural-language arguments better than
   shell-style flags.
-- `actionTypes: send_invite, send_inmail_closed`: optional lane selector. Omit
-  `actionTypes` to preserve the target planner's lane inference.
 - `untilDate: YYYY-MM-DD`: explicit date selector alternative when the host
   preserves natural-language arguments better than shell-style flags.
 - `targetDate: YYYY-MM-DD`: exact-date selector alternative when the host
@@ -93,7 +91,7 @@ Accepted invocation flags in the same user request:
 When the host can call typed MCP tools, start with:
 ```text
-refill_sends({ yolo?: boolean, executionMode?: "manual" | "scheduled" | "yolo", requireWorkspace?: boolean, workspaceId?: string, senders?: string[], senderIds?: string[], senderNames?: string[], actionTypes?: ("send_invite" | "send_inmail_closed")[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD" })
+refill_sends({ yolo?: boolean, executionMode?: "manual" | "scheduled" | "yolo", requireWorkspace?: boolean, workspaceId?: string, senders?: string[], senderIds?: string[], senderNames?: string[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD" })
 ```
 That command helper normalizes arguments and returns the execution contract. In
@@ -101,22 +99,14 @@ non-yolo mode it does not mutate. In `--yolo`, it may execute exactly one safe
 bounded primitive from the fresh `target.globalActionQueue[0]`, then reread and
 return the new target plan; currently safe primitives are paid-credit refresh,
 existing-row message preparation, generated-message approval, receipt-proven
-same-source row copy, a request-scoped exact-date product scheduler sweep, and
-read-only wait rereads. Same-source copy/source
+same-source row copy, and read-only wait rereads. Same-source copy/source
 fallback is safe only after receipt-proven exhaustion:
 `hasMoreFrontierRows:false`, zero `approvalCandidates`, no `stuckActiveCells`,
-and no non-terminal `approvedNotDispatched` work. It does not run unbounded
-approval, lower paid-InMail thresholds, switch source families, create
-campaigns, launch, or send directly; it never raw-writes scheduler fields.
-Continue with the workflow below for route selection, state rereads, approval
-gating, source import, preparation, and bounded approval.
-The approval scope is the exact `workspaceId`, `targetDate`, sender ids, action
-types, campaign/table/source ids, `targetShapeRevision`, and `actionKey` in the
-rendered packet. `stateRevision` and sent/scheduled/ready counts are mutable
-progress, not approval-scope drift. Execute only
-`target.globalActionQueue[0]`, then perform a full authoritative reread before
-deciding any next action.
+and no non-terminal `approvedNotDispatched` work. It does not run unbounded approval, lower
+paid-InMail thresholds, switch source families, create campaigns, launch, send,
+or write scheduler rows. Continue with the workflow below for route selection,
+state rereads, approval gating, source import, preparation, and bounded
+approval.
 ## Workspace Contract
@@ -286,27 +276,10 @@ need raw proof, call the read-only `get_scheduler_fill_capacity` query for the
 same sender/action/date; it tells the MCP how many cells the product scheduler
 will try to place and does not import, approve, schedule, refresh credits, or
 mutate.
-Treat `rollingWeeklyInvite.capacityFreedDuringWindow:true` as proof that
-rolling-weekly capacity frees later in the send window and remains schedulable;
-use its timing fields instead of treating the window-start gate as a permanent
-full-day blocker.
 When the refill loop has ready rows and needs scheduler pickup now, use
 `run_scheduler_sweep` with the same explicit `workspaceId`; it can place cells
 within existing scheduler gates and returns the receipt, but it never sends or
 bypasses limits.
-A scheduler sweep is a visible workspace-wide scheduling side effect. The
-request packet limits the expected target changes to its exact date, senders,
-action types, campaigns, tables, and stable sources, but the product scheduler
-may also place unrelated eligible workspace work; disclose that possibility in
-the approval packet and receipt. For an exact-date sweep action, execute it
-once, then reread the full target plan before taking or presenting another
-action.
-The exact-date `run_scheduler_sweep` may schedule eligible workspace cells
-through existing product gates; it never sends directly or raw-writes scheduler
-fields. Only non-exact or no-sweep scheduler waits are read-only.
-On resume, reconcile the current target plan and matching sweep status/receipt
-before retrying. A matching same-key terminal receipt replays; an
-`uncertain_outcome` stops for reconciliation and must not schedule again.
 Scheduler-run receipt interpretation: `cellsConsidered is allocation-attempt
 count`, not total ready supply, while `readyCellsFound` is ready inventory found
 before prefilters. Inspect `campaignScopeSummary` before assuming the selected
@@ -419,14 +392,6 @@ scheduler wait loop. Do not finish the refill goal, mark it complete, or mark it
 blocked only because it is still `awaiting_scheduler_after_ready_buffer`; keep
 waiting unless Christian stops the run or the host cannot continue.
-Future scheduled coverage and already sent actions are distinct; only
-scheduler-owned future scheduled actions count as scheduled coverage. For
-multiple target dates, finish D1 execution and the full D1 reread before
-planning D2. Completion proof is product-native Sellable MCP evidence only:
-target plan, campaign refill state, scheduler capacity, sweep/status, and
-bounded receipts. Never use individual cell ids, Prisma, SQL, direct database
-access, or production-environment scripts as completion proof.
 In `--yolo`, the default fill target is the scheduler-forward 48-hour window
 unless `--target-date`/`targetDate`, `--until`/`untilDate`, or an explicit
 compatibility `horizonSendDays` is provided. If a target date is provided,