@sellable/install 0.1.319 → 0.1.321

package/HERMES-SLACK-PROFILE-SCOPING.md

@@ -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

@@ -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

@@ -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.
 `;
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.319",
+  "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

@@ -276,10 +276,6 @@ 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