scope

Pre-launch verifications captured here as decisions are locked.

npm package name

Decision: snappy-os (unscoped).

Probed 2026-04-17 via npm view snappy-os:

npm error code E404
npm error 404 Not Found - GET https://registry.npmjs.org/snappy-os - Not found

Exit code 1, 404 — the name is unregistered and available. No fallback needed.

If a future namespace conflict emerges (e.g. another publisher races the name), fall back to @snappy-ai/os under the existing @snappy-ai org.

Out of scope for v1

These surfaces are intentionally NOT addressed by snappy-os v1. Each is documented here so future work has an explicit boundary to push against.

ChatGPT MCP apps and RemoteClaude

ChatGPT-hosted MCP apps and RemoteClaude do not get symlink fan-out, slash-command generation, or hook wiring in v1. The integration surface differs enough from local CLI runtimes that retro-fitting them under the same symlink-runtimes.sh would dilute the per-runtime contracts. v2 revisits after v1 has steady-state telemetry.

MCP config read or write

snappy-os never reads or writes MCP configuration files. Joes who run MCP do so in parallel; the two systems do not interfere. Reasoning: MCP is a separate substrate with its own conventions, and treating it as a peer runtime would import its conflicts into snappy-os. The consequence is that an MCP-only workflow does not benefit from snappy-os sync, but it also is not broken by it.

Email and Slack alert delivery

v1 has no email or Slack channel for alerts. Robert reads _status on the Worker frontend when checking in. The alerts/ log captures detail locally, and /_status aggregates across tenants. Adding push-style delivery in v1 would require a credentials-management surface that is out of scope; v2 may add a webhook receiver after the secrets-rotation flow has been exercised.

Auto-upgrade on pull

pull never auto-upgrades the bootstrap. Schema-version mismatch surfaces as a refusal with an upgrade prompt. Auto-upgrade-on-pull would change runtime configuration (hooks, symlinks) without the user's knowledge, which violates the "no surprise behavior change" principle. Manual npx snappy-os@latest remains the only upgrade path in v1.

Per-tenant tier self-serve

Tier upgrades (subscriber, client) are manual in v1 — Robert updates tenants/<id>.json after confirmed acceptance. There is no Stripe hook, no self-serve portal, no automated grant on payment. v2 may add this once the tier model has been validated against real client work.

Tail-only ndjson delta uploads

Phase 12 documents <file>.last-pushed-offset sidecars as a v2 feature. v1 gzips and re-uploads append-only ndjson in full. Acceptable until any single file exceeds ~1 MB compressed; v2 implements tail-only when that threshold is approached.

Cross-tenant raw eval visibility

The PID aggregate is anonymized by tenant hash. No tenant ever sees another tenant's raw evals.ndjson. Quorum-driven promotion is the only cross-tenant surface. v1 deliberately does not expose per-tenant score histories or tenant-to-tenant comparison views.