Sellable Admin Installer

Internal installer for Sellable Admin Claude Code, Codex, and Hermes setup.

Normal employee usage is through the reviewed curl script:

curl -fsSL "https://app.sellable.dev/api/v2/admin/install" -o /tmp/sellable-admin-install.sh
sh /tmp/sellable-admin-install.sh --host all --config-zip ~/Downloads/sellable-config.zip

The installer downloads source code only. Christian sends the private config bundle separately.

For the profile-only named Admin command and its Hostinger/Hermes Desktop operating procedure, see docs/operations/HERMES-ADMIN-AGENT-INSTANTIATION.md.

Sellable Admin Hermes Profile

Bootstrap the privileged sellable-admin profile package-first:

npm exec --yes --package @sellable/admin-install@latest -- \
  sellable-admin-install hermes profile bootstrap \
  --profile sellable-admin \
  --profiles-root /opt/data/profiles \
  --config-zip ~/Downloads/sellable-config.zip \
  --source package \
  --mcp-package @sellable/admin-mcp@latest \
  --json

Use /opt/data/profiles inside the Hermes container. The Hostinger host volume path is /docker/hermes-agent-mc30/data/profiles.

Hermes root auth must contain exactly one approved openai-codex OAuth record. The source profile owns the current gpt-5.6-sol model selection. The generated dashboard entrypoint starts the profile-scoped gateway and isolated dashboard; long-lived profiles should be refreshed through this package command, not by hand-copying files.

Named Admin profile composition always stages and verifies exactly the packaged sellable and sellable-admin MCPs. Lightfield is a workspace-managed Product integration connected in Sellable. Its API key stays encrypted in the Product backend and is never copied into Admin escrow, Hermes configuration, image layers, or profile-owned OAuth state. Admin profiles discover and call reviewed Lightfield actions through Product MCP's integrations_list_tools, integrations_describe_tool, and integrations_call_tool gateway. Customer bootstrap preserves the same workspace-scoped integration boundary.

Hermes Customer Bootstrap

sellable-admin-install hermes customer bootstrap is the production public interface for customer Slack app creation/adoption, workspace/channel identity, the blank isolated profile, workspace-locked plain Sellable MCP, native s6 gateway, verification, rebuild, and rollback.

Start with read-only planning:

sellable-admin-install hermes customer bootstrap \
  --mode plan \
  --customer-slug acme \
  --company "Acme" \
  --team-id T0TEAM12345 \
  --workspace-mode reuse \
  --workspace-id ws_acme \
  --workspace-name "Acme" \
  --channel-mode reuse \
  --channel-id C0ACME12345 \
  --channel-name sellable-acme \
  --allowed-slack-user-ids U0OWNER12345 \
  --sellable-token-file /opt/data/profiles/sellable-admin/secrets/acme.sellable-token \
  --model gpt-5.6-sol \
  --evidence-target /opt/data/profiles/sellable-admin/phase03/acme/evidence \
  --profiles-root /opt/data/profiles \
  --json

The plan returns a deterministic runId, immutable inputHash, exact create/reuse actions, the stage graph, and a reviewable approval packet with no writes. After explicit approval, run the same approved packet with --mode apply --approved. Use resume, status, verify, rebuild, and rollback only with the returned --run-id.

No-Contact Rehearsal V3

sellable-admin-install onboard-client-v3-hermes is a distinct, fail-closed rehearsal command. It delegates only to the customer bootstrap factory while requiring --no-contact, a distinct slug ending in test or a numbered test suffix such as test2, explicit workspace reuse, one internal operator, and a newly created private channel. It rejects a pre-existing channel name before app installation, never invites a workspace or Slack customer member, and never posts an onboarding or test message.

It is not a customer-onboarding command and must not be used to contact a customer. Use the generated onboard-client-v3-hermes skill for the required approval and Printing Press Slack verification procedure.

The operator never coordinates internal Slack API, Browserbase direct-CDP, Gmail, profile-installer, Sellable-installer, or Hermes gateway subcommands. Those are private stages owned by the single bootstrap state machine. The state machine invokes Hermes' native Slack manifest generator itself and derives the customer-safe manifest; customer onboarding never supplies a manifest path or creates a Slack developer project.

Apply and resume also own bounded recovery. When Browserbase returns an explicitly resumable blocker, the same command reloads the durable lifecycle ledger, adopts the exact saved channel/app/session identities, lets the adapter repair authentication from its restricted auth state and persistent context, and retries up to four total attempts. Terminal identity, routing, package, and implementation blockers are never retried. Each attempt writes a secret-free autoRecovery receipt, and a successful blocker/action pair becomes durable recovery memory for the next invocation. Exhaustion returns the typed bootstrap_auto_recovery_exhausted blocker with the original safe cause; it never starts an unbounded loop or duplicates a Slack resource.

The adaptive operator carries production-proven, redacted Slack UI lessons into every attempt. A channel Integrations popup is not trusted as channel-scoped when it exposes workspace-wide Manage, Remove, or Uninstall controls. The operator must stop that unsafe UI path, and the lifecycle reroutes exact stale test-bot membership cleanup through users.info, conversations.kick, and a live membership readback instead of spending another Browserbase retry.

Immutable Release Candidates

Non-fixture apply/resume/rebuild must bind the exact four tested candidates:

• running @sellable/admin-install tarball SHA-256 via --package-sha256
• @sellable/admin-mcp spec and SHA-256 via --mcp-package and --mcp-package-sha256
• @sellable/install spec and SHA-256 via --sellable-install-package and --sellable-install-sha256
• @sellable/mcp spec and SHA-256 via --sellable-mcp-package and --sellable-mcp-sha256

latest is rejected for customer apply/rebuild. The profile factory passes the exact Sellable MCP candidate to the public installer and records all four candidate hashes in the run and rebuild receipts.

Customer Isolation Contract

Customer profiles are blank-created and receive only:

• current openai-codex gpt-5.6-sol model config
• one machine-root openai-codex OAuth chain protected by the root auth lock; they never receive a profile-local Codex provider/pool, OpenRouter, or raw OpenAI API keys
• a dedicated Slack xoxb/minimal xapp pair stored only through restrictive secret files
• exact channel and allowed-human ID allowlists
• customer-safe Slack manifest with no slash commands, App Home/assistant messaging, or DM/MPIM events/scopes
• plain Sellable MCP installed from the pinned candidate with a profile-local Sellable user token, SELLABLE_LOCK_WORKSPACE_ID, and SELLABLE_REQUIRE_WORKSPACE_LOCK=1
• one profile-specific native Hermes gateway supervised by s6

Customer profiles never receive Sellable Admin MCP, admin skills, browser/Gmail credentials, Slack provisioning credentials, sibling profile data, or a shared Slack listener/token pair.

Before Slack-side UAT, the packaged verifier must prove root OAuth fallback, zero local auth entries, exactly one visible/active locked Sellable workspace, no sibling workspace fetch, no Admin MCP, a unique Slack token pair, and one s6 gateway owner. Receipts contain only IDs, paths, modes, hashes, and fingerprints; never raw secrets.

The runtime still presents this as root fallback to named profiles, but the Codex refresh path is root-write-through and profiles never receive profile-local auth.json Codex state. Customer profiles never receive profile-local auth.json credentials.

Shared Codex Runtime Capability

Customer and Admin bootstrap require shared_codex_root_auth_v1 before profile creation. The packaged offline probe races two disposable profiles against an expired dummy Codex token and accepts only one root-locked refresh with both profiles reading the same rotated result. Bootstrap also performs a real safe-mode Codex inference after profile promotion.

Hosting implementations may use a compatible Hermes image, derived image, or hash-pinned runtime overlay. The mechanism is host-specific; the capability probe is not. See docs/operations/HERMES-SHARED-CODEX-AUTH.md in the source repository for the portable hosting and upgrade contract.

Runtime Notes

Hermes command visibility depends on the gateway/root skill scanner. The Admin bootstrap registers the profile skill root in skills.external_dirs and prepends these profile-local paths to the generated entrypoint and MCP env:

• $HOME/.local/bin
• $HOME/.sellable-admin/bin
• $HOME/.slack/bin
• $HOME/.venvs/browser-use/bin

For Hostinger, keep Docker Compose pointed at the generated entrypoint:

entrypoint: ["/opt/data/bin/entrypoint-sellable-admin.sh"]

The production Sellable Reply Bot is separate HTTP-interactivity product infrastructure. Keep Socket Mode off and keep its Interactivity & Shortcuts URL at https://app.sellable.dev/api/v2/slack/interactions.