@amerged/ohmyhost-mcp 0.1.24 → 0.1.25

package/README.md

@@ -1,6 +1,6 @@
 # @amerged/ohmyhost-mcp
 
-Local MCP server of ohmyho.st, version 0.1.24. Sign-in and setting secrets need the CLI too:
+Local MCP server of ohmyho.st, version 0.1.25. Sign-in and setting secrets need the CLI too:
 
 ```sh
 npm install --global @amerged/ohmyhost-cli @amerged/ohmyhost-mcp

package/dist/{chunk-EEFUMPKG.js → chunk-L5A5FEGY.js}

@@ -8,7 +8,7 @@ var __export = (target, all) => {
 // apps/mcp/package.json
 var package_default = {
   name: "@ohmyhost/mcp",
-  version: "0.1.24",
+  version: "0.1.25",
   private: true,
   ohmyhost: {
     deployment: "production",
@@ -30617,7 +30617,7 @@ var GENERATED_SKILL_RESOURCES = Object.freeze([
     title: "ohmyhost-build-portable-app: references/stack-contracts.md",
     description: "Supporting resource for ohmyhost-build-portable-app.",
     mimeType: "text/markdown",
-    text: "# Portable application contracts\n\nUse this reference only when implementing framework or capability code. Product decisions come from `ohmyhost init` and the public CLI, not from provider examples.\n\n## Source and compatibility\n\n- Pin exactly one of `npm`, `pnpm`, `yarn`, or `bun` in `packageManager` and commit exactly one matching frozen lockfile. The direct build commands are `npm run build`, `pnpm run build`, `yarn run build`, or `bun run build`. Bun is pinned to `1.2.22`. Installs are frozen and skip lifecycle scripts (`--ignore-scripts`, or Yarn `--mode=skip-build`); commit generated inputs instead of depending on postinstall.\n- Supported framework config extensions are `.js`, `.mjs`, and `.ts`.\n- Admission windows are Vite `>=5.4.0 <=8.2.2`, TanStack Start `>=1.168.26 <=1.168.49`, Next `15.5.x`, and Next `>=16.0.0 <=16.3.4`. `verified` names an exact tested fixture; another admitted version is `experimental`; an out-of-window or unsupported capability is `unsupported`.\n- `package.json` scripts.build is exactly `next build` or `next build --webpack` for Next.js. Vite and TanStack Start use `vite build`, optionally with one `tsc`, `tsc --noEmit`, `tsc -b` or `tsc --build` stage before or after it joined by `&&`. Arbitrary preparation, `cd`, traversal and lifecycle hooks are outside this build contract. Builds use Node.js 24 and stop after eight minutes; runtime secrets are absent from the build. Commit intentional public build values. Gzipped Worker limits are 10 MiB for Next.js and 5 MiB for other Workers; static output needs `index.html`, at most 10 MiB per file, 25 MiB/1,000 files total and a compressed artifact at most 30 MiB.\n- The platform overlay, not the customer repository, pins OpenNext `1.20.6` and Wrangler `4.125.0`. Do not commit those packages, generated Wrangler files, platform bindings, or `OHMYHOST_BASE_PATH` for hosting.\n\n## The customer chooses application authentication\n\nHosting does not automatically add end-user authentication. The customer or their agent integrates the chosen library/service into the application and owns its user flows, authorization and provider account/configuration. This is separate from WorkOS authenticating the customer to ohmyho.st, `ohmyhost login`, `OHMYHOST_TOKEN`, GitHub consent and protected Dev browser access. Never reuse ohmyho.st's WorkOS tenant, platform keys or agent token for an application's users.\n\nThe supported application-auth interfaces include [Better Auth](https://better-auth.com/docs/installation) and customer-owned [WorkOS AuthKit](https://workos.com/docs/authkit/). Better Auth has retained integration proof; hosted WorkOS Next.js has proof, while other framework/provider combinations need their own hosted evidence. Other OAuth/OIDC integrations must satisfy the actual browser, server, secrets and egress contracts and pass their application tests; a declared origin does not establish complete provider support. Public applications need no auth. Keep other existing customer choices; framework/runtime capability checks apply equally to all dependencies. Use the provider's current first-party SDK/guide for the actual browser or server runtime. Browser integrations use their documented public client identifiers and origin/callback settings; do not request or expose server API/client secrets in a Vite browser bundle. Server integrations use only customer-owned server runtime secrets.\n\nThe current structured platform auth integration accepts `none` or pinned `better-auth`. `none` disables only that managed integration; it does not mean that the application has no login. Do not invent `auth.provider: workos` or another unsupported configuration field. Init reports `application-auth-review` for recognized, unselected auth SDK evidence without enabling managed database/auth/mail. Selecting the optional managed Better Auth integration requires explicit `auth.provider: better-auth`, `database.enabled: true` and `mail.enabled: true`, with Better Auth pinned exactly to `1.7.1`. This managed HTTP bridge always uses private managed mail for verification/reset. Missing mail is `managed_auth_mail_required` at init/planning: enable managed mail and its Paid verified sender, or set `auth.provider: none` and keep application-owned auth/sending. An ordinary Better Auth or mail SDK dependency selects no managed capability. A detected mail SDK is also evidence to review, not consent to enable Paid platform mail. Database migration files are separate evidence and do not identify an auth provider. Source admission does not reject SDKs by vendor name; the actual runtime, egress, migration and artifact contracts still apply. Older installed clients/platforms may report `better-auth-conversion` or `supabase_migration_required`: discover/update the installed release and report its limitation instead of treating it as consent to replace auth or delete users.\n\n`BETTER_AUTH_SECRET` and `BETTER_AUTH_URL` are reserved for the platform-managed integration and cannot be set through the customer secret command. An application that owns its Better Auth setup uses its own secret name, for example `APP_AUTH_SECRET`, and maps that value explicitly to Better Auth's `secret` option. Use an application-owned `APP_URL` for its `baseURL`; it must match the trusted Dev/Prod origin. Do not enable managed auth merely to acquire that name or weaken the reserved-name check. Keep platform-owned credentials and application-owned auth configuration separate.\n\nFor the agent's feedback, state:\n\n- The customer's chosen/existing auth system, whether it runs in the app or externally, and the evidence for runtime/SDK compatibility. Preserve the choice unless the customer authorizes a change.\n- Missing configuration: customer-owned provider tenant/project, exact Dev/Prod login/callback/logout origins, necessary egress destinations and required secret **names**. Use the normal secret CLI/stdin handoff for values. Public client IDs/publishable keys are different from private API keys; follow that provider's documentation.\n- Who stores users/sessions and who sends verification/reset mail. An external provider's mail does not automatically need ohmyho.st mail or Paid access. The explicitly selected managed Better Auth bridge requires database and managed mail, including Paid access and the customer's verified sender domain; missing mail fails early as `managed_auth_mail_required`, and missing sender as `mail_domain_required`. Application-owned Better Auth or external auth mail need no managed capability unless the application deliberately selects it. Report that dependency instead of removing email verification.\n- What was tested: sign-in, callback, authenticated and forbidden access, session handling and sign-out on the real application. For isolated environments, keep auth configuration/sessions/data isolated and register both callback origins; promotion must not copy Dev users or private credentials to Prod.\n- The specific blocker or next action. Keep \u201Ccustomer configuration missing\u201D, \u201Cruntime incompatible\u201D and \u201Cnot yet verified\u201D distinct in the explanation; these are explanatory categories, not new API error codes. Report a suspected platform limitation through feedback, without credentials or user records.\n\nExample feedback: \u201CThis app uses your WorkOS AuthKit account. The ohmyho.st CLI login is separate. Configure this app's Dev/Prod callback URLs and the listed server-secret names. End-user login is not verified until the deployed callback and protected-route tests pass.\u201D\n\n## PostgreSQL and Auth\n\n- Access to ohmyho.st-managed PostgreSQL uses `OHMYHOST_DATABASE`. Neon management, direct migration credentials and managed connection URLs are platform-private. This does not forbid a customer's compatible auth SDK from calling their own external identity provider.\n- Call the database with `createPrivateDatabaseClient` from `@ohmyhost/customer-runtime`; see [database-runtime.md](database-runtime.md) for the working example, what is not available and what it costs. There is no connection string or customer socket; interactive transactions use the bounded `withConnection(callback)` scope. Keep canonical expand-only migrations under the path reported by init.\n- A held scope allows two concurrent transaction/auth connections per physical data area (shared Dev/Prod share them), 100 statements, 30 seconds total and five seconds idle. Close it before storage transfers, email, AI calls or other network waits. An adapter for an existing acquire/close port must release the underlying scope in `finally`; never keep a request-wide transaction open while processing a file.\n- An optional Kysely `0.29.5` dialect is available from `@ohmyhost/customer-runtime/database-kysely`: `createPrivateDatabaseDialect(env.OHMYHOST_DATABASE)` for `new Kysely({ dialect })`. Its `db.transaction().execute(async trx => ...)` uses the actual leased connection with BEGIN/COMMIT or ROLLBACK and close; the same bounds apply. For application-owned Better Auth `1.7.1`, use its own migrated schema, normally `public`: `database: { db: db.withSchema(\"public\"), type: \"postgres\", transaction: true }`. This is separate from the managed auth-lane bridge; `auth.provider: none` provisions no auth tables. The library transaction path is tested; hosted signup/mail still needs application verification. This does not claim Drizzle transaction support.\n- SQL `DATE` and `date[]` elements retain the `YYYY-MM-DD` wire string. They are calendar days, not timezone-bearing JavaScript dates; preserve existing timestamp decoding and normalize only the field that the application's contract requires.\n- When the customer selects the verified Better Auth integration, it owns schema `auth`, UUID IDs, `/api/auth`, secure host-only cookies, database sessions, verification/reset mail, and session revocation. Authorization remains explicit in each use case.\n- Read hosted secrets/bindings from the framework context: for Next.js on this runtime, `getCloudflareContext({ async: true }).env`. Keep an explicit local test adapter where useful, but do not activate a localhost-only test factory in production or trust the request Host header as configuration. Check the session, tenant and application repositories through the same hosted database adapter as health.\n- A newly isolated database can have correct tables but no tenant, administrator or application configuration. Use the application's existing, owner-authorized bootstrap/seed path with its real password hashing and tenant/membership rules. Keep this as a controlled one-off script or existing private administrative workflow; do not add a public bootstrap route or a production test-mode switch. Verify login after bootstrap, without copying Dev users into Prod.\n\n- For interactive work a customer can issue a time-bound direct PostgreSQL login with `ohmyhost database access create` / MCP `database_access_create` (mode `read` or `write`, 5 minutes to 24 hours, at most three active per environment) and open it with `ohmyhost database psql`. The connection URI and `psql` command are returned exactly once: use them immediately, never store or commit a connection string or password, and revoke the credential when finished. Such a login can never change schema and row-level security still applies; application code keeps using `OHMYHOST_DATABASE`.\n\nApplication background: [Better Auth PostgreSQL](https://better-auth.com/docs/adapters/postgresql). Customer code uses the scoped database binding; provider connection examples do not replace it.\n\n## Files, mail, functions, and secrets\n\n- Import the storage client from `@ohmyhost/customer-runtime/storage`. The Storage Gateway owns raw R2 bindings, signed operations, quotas, receipts, and cleanup. Files live in the project's hosting region: `storage.jurisdiction` accepts `us` or `eu` and must equal the region chosen when the project was created (`--region`, default `us`); a mismatch fails the plan with `storage_jurisdiction_conflict`. `ohmyhost init` is offline: it writes `us` unless `--region eu` is supplied and preserves an existing configuration. Use the already-created project's region when preparing a new file.\n- Upgrade the CLI/MCP to the current published version first. Then install the runtime under its import name as the exact npm alias that init reports under `runtime.packages.customerRuntime` for every framework; `companion.packages.customerRuntime` and `worker.packages.customerRuntime` are equivalent fields: `\"@ohmyhost/customer-runtime\": \"npm:@amerged/ohmyhost-runtime@<version>\"` in `package.json`. Refresh and commit the lockfile with the project's package manager. Every `@ohmyhost/customer-runtime/*` import stays unchanged. A bare `@ohmyhost/customer-runtime` version fails the platform build, and an `https://ohmyho.st/releases/\u2026` runtime URL stops resolving once a later release replaces the website downloads, so replace such a URL with the alias. Use the version init reports; older runtime versions carry no compatibility promise.\n- A storage-enabled deployment receives exactly five runtime values and **no** `FILES` bucket binding: the private `OHMYHOST_STORAGE_GATEWAY` Service Binding, the plain values `OHMYHOST_STORAGE_GATEWAY_URL`, `OHMYHOST_PROJECT_ID`, `OHMYHOST_ENVIRONMENT_ID`, and the secret `OHMYHOST_STORAGE_KEY`. Pass `endpoint: env.OHMYHOST_STORAGE_GATEWAY_URL`, `key: env.OHMYHOST_STORAGE_KEY`, `projectId: env.OHMYHOST_PROJECT_ID`, `environmentId: env.OHMYHOST_ENVIRONMENT_ID`, `fetch: (request) => env.OHMYHOST_STORAGE_GATEWAY.fetch(request)` and `capabilityFetch: (request) => fetch(request)`. Invalid options answer non-retryable `gateway_configuration_invalid` naming the option; the clients run only on the server.\n- The gateway hop travels over that Service Binding. `OHMYHOST_STORAGE_GATEWAY_URL` only supplies the origin the client builds its request URLs from; it is not a public endpoint. No public or sandbox hostname transport is supported; never call it with ordinary outbound `fetch`. Outbound `fetch` is for the short-lived signed R2 object URL alone.\n- Files are create-once logical names within an immutable data area: shared Dev/Prod use one namespace, isolated environments use separate namespaces. Each name is at most 512 UTF-8 bytes; slash-separated segments start/end with letters or digits and contain only letters, digits, `.`, `_` and `-`, with no traversal. Idempotency keys are 1\u2013128 letters/digits/`._:-`. Content type is a lowercase `type/subtype` without parameters. Uploads and the physical bucket quota are at most 1 GiB, including open reservations; signed capabilities last five minutes. A deletion never makes a used name reusable inside that identity. A reset creates a fresh namespace, so the same logical name can be used again. `storage_quota_exceeded` needs deleting unneeded objects or a smaller upload; `storage_conflict` needs resolving the original name/key receipt rather than retrying a conflicting payload. `storage_upload_expired` needs a new objectKey and idempotencyKey. `storage_delete_pending` means wait until retryAt, then repeat the original deletion; `data_change_in_progress` means observe that operation; `storage_binding_data_changed` needs redeployment of the named environment. Data assignment changes retain exact existing locators, without moving blobs.\n- Store a file with `upload` (or `reserveUpload` &rarr; PUT to the signed URL &rarr; `completeUpload`) and serve it with `createSignedRead`; `deleteObject` releases quota. If `ohmyhost.yaml` declares storage while no source calls `createPrivateStorageClient`, init blocks `storage_client_missing` instead of reporting a clean deployment that fails at the first upload. After uncertain completion, repeat `upload()` with the same bytes, objectKey and idempotencyKey: a create-only PUT's 412 completes the existing reservation. `storage_upload_rejected` is retryable only for 5xx or 429. For recoverable multi-object work, persist reservation/transfer IDs and cleanup progress before transfers; call `completeUpload(transferId)` to reconcile.\n- `readMany({ objectKeys })` reads 1\u20134,000 distinct logical keys through one streaming gateway call. Iterate every result and consume or cancel each found body before the next item; `not_found` is explicit. Completion requires the final frame and exact EOF. Malformed, oversized or truncated framing fails as `gateway_response_invalid`; an aborted read is not a completed batch. `deleteMany({ objects: [{ objectKey, idempotencyKey }] })` accepts the same key limit and distinct per-object keys. Its ordered outcomes are completed, pending with retryAt, or failed with code/retryable. Control JSON/framing is at most 4 MiB, independent of streamed payload bytes. Keep an application manifest for selection/pagination; there is no bucket-list API. Persist outcomes and replay only pending/retryable items with their original keys.\n- A completed deletion requires verified payload erasure; an accepted request, elapsed upload link or old absence receipt alone does not release quota. Prior conditional uploads cannot restore a completed file. Large or interrupted batches may acknowledge only a subset: retain all keys and retry pending/retryable items. `deleteMany` applies one configured deadline across headers and complete JSON; timeout does not undo durable per-file progress. Binary `readMany` keeps its bounded per-frame timeout and requires complete iteration.\n- When the browser's CSP permits only same-origin connections, upload through an application route instead of exposing a provider URL or weakening CSP. Authorize an opaque, short-lived capability against the real upload reservation, tenant, MIME, byte length and expiry. Keep the platform storage key and signed R2 URLs server-side. Bound bytes while reading; an identical completed PUT retry may return success without writing again, while different bytes must conflict.\n- For inspected private files, use a distinct staging key per capability and an immutable final key. Read the staged ETag conditionally, inspect those bounded bytes, write the final object and verify its metadata before committing the application record. Keep staging through the commit; use a durable, bounded cleanup journal afterward, fenced against active upload/processing work. A comment or an unconsumed outbox event is not a running cleanup path. Original downloads remain authorized, conditional and bounded; a signed GET URL is not a signed HEAD capability.\n- Set upload limits to the smallest limit across ingress, storage, content inspection, downstream APIs and response handling. Reuse one application policy in browser hints, routes and provider adapters; a successful storage upload does not prove the parser or AI service can accept it. Preserve truthful decoder and validation failures.\n- Use authenticated same-origin framework routes for bounded request work. Vite may use the companion source contract returned by init; TanStack Start and Next.js retain their native server routes/functions. A project without a web framework sets `runtime.mode: functions` and writes `src/ohmyhost/worker.ts` as a module Worker: `export default { async fetch(request, env, ctx) {\u2026}, async scheduled(controller, env, ctx) {\u2026} }`. It keeps `build.install` only and receives the same database, files, mail, secret and egress bindings as an edge app.\n- Declare scheduled work only through `functions.crons` in `ohmyhost.yaml`: one to eight unique five-field UTC crons with a five-minute minimum. A field is `*` or one canonical integer; minute is an integer or `*/5` through `*/59`, never bare `*`. Sunday is `0`; ranges, lists, names and shortcuts are refused. Day-of-month and weekday must both match when both are fixed. The handler is the `scheduled(controller, env, ctx)` member of the **default export** of `src/ohmyhost/worker.ts` (functions runtime, Next.js, TanStack Start) or of the Vite companion `src/ohmyhost/companion.ts`. Named exports are never invoked; init blocks `worker_module_default_export_required` and `scheduled_handler_missing` with the file path. The platform runs one attempt per cron and UTC minute with a 120-second deadline, retries a thrown error or platform failure up to three attempts, and honors `controller.noRetry()`. Retries retain the original `scheduledTime`, so make side effects idempotent. Dev and Prod schedules follow their own active deployments and can both write the same shared data; decide which owns a task. Finished runs are retained seven days. Each run is billed as one request plus its CPU credits. Runs are visible through `ohmyhost function runs` / MCP `function_runs_list` (per environment, newest first), not through deployment logs.\n- `src/ohmyhost/worker.ts` is bundled by the platform on its own, outside the framework build: tsconfig `paths` resolve, but Vite-only aliases, framework virtual modules and modules that declare TanStack Start server functions or Next.js route handlers do not. Import plain application modules (repositories, storage and database clients from `@ohmyhost/customer-runtime/database`, `/storage` or `/mail`) and keep framework entry code out of the Worker module.\n- HTTP and scheduled customer Workers have 50 ms CPU and ten subrequests per invocation. Network waiting does not consume CPU, but database, gateway and signed-object calls consume requests; batch and page work accordingly. A runtime limit answers HTTP 429 beginning `Runtime limit exceeded`. A functions module must always export a default `fetch`, including a schedules-only application. `functions.crons` on a static runtime fails `scheduled_functions_runtime_unsupported`.\n- Select a small work batch and per-call timeouts that fit the 120-second scheduled deadline. Persist claims, retry state and cleanup progress before acknowledging work; close database scopes before provider calls. Import narrow runtime modules rather than barrel files that pull Next.js routes into the scheduled bundle. Verify that a due run actually completes through `function_runs_list`.\n- For ohmyho.st-managed transactional mail, use `createTransactionalMailClient` from `@ohmyhost/customer-runtime/mail` with the supplied `OHMYHOST_MAIL_GATEWAY_URL`, `OHMYHOST_MAIL_KEY` and `OHMYHOST_PROJECT_ID`, and `fetch: (request) => env.OHMYHOST_MAIL_GATEWAY.fetch(request)`. Resolve the private Service Binding from the framework request context or Worker `env`; it is not a string in `process.env`. A missing binding is a configuration error, not a reason to retry through public `fetch` or disable placement/egress. Keep the same message and idempotency key for an uncertain retry; do not automatically switch transports. Verification/reset mail owned by an external identity provider stays with that integration. Mail bindings exist only for deployed source with `mail.enabled: true`; a verified project domain alone does not install them, and promotion/rollback of undeclared source removes them. Install application-owned private values through stdin-based CLI commands; source lists secret names, never values.\n\n## Source capability declarations\n\nPreserve an existing `ohmyhost.yaml`. Init detects SQL migrations under `postgres/migrations` or `supabase/migrations`, R2 declarations/bindings and `supabase/storage`; this is evidence to review, not permission to migrate an external service. A database declaration has `enabled: true` and its `migrations` path; files use `storage: { provider: r2, jurisdiction: us|eu, public: false }`. Static Vite/TanStack builds serve assets; Next.js, server TanStack and Vite companions use edge mode; plain Workers use functions mode. A runtime mismatch or `auto` fails planning as `framework_conversion_required`. Enable only actual application capabilities.\n\nServer egress uses `runtime.egress.allow`: at most 13 exact HTTPS origins, without trailing slash, paths, credentials, ports, IP literals or local names. An omitted origin answers 403 `Egress denied`; a redirect answers 502 `Egress upstream unavailable` (304 is retained). Call the final destination and declare its origin. Customer Workers cannot open sockets. Browser origins below are a separate declaration and do not authorize server fetches.\n\nThe runtime does not inject a public app URL or an environment-name variable. Declare application-owned origin secrets separately for Dev and Prod. Only managed Better Auth receives its reserved platform base URL. Secret names must be uppercase letters/digits/underscore, begin with a letter and be at most 128 characters; `OHMYHOST_*` and the fixed platform names are reserved for set.\n\n`runtime.healthcheck` defaults to `/`, is a path without a query, and must answer a cookieless GET with 2xx directly within five seconds. An authenticated redirect fails. Health is a minimal public response without secrets; success does not prove other flows.\n\n## Browser media and microphone\n\nVideo/audio playback and microphone access are blocked by default. Server-rendered HTML can opt in with exactly these lines in `public/_headers` and a redeployment; static asset pages cannot opt in. Anything broader is ignored, and camera and geolocation stay blocked.\nMedia loads only from the application's origin or blob URLs; stream stored media through an\nauthorized application route instead of embedding a signed R2 URL.\n\n```text\n/*\n  Content-Security-Policy: media-src 'self' blob:\n  Permissions-Policy: microphone=(self)\n```\n\n## Browser security (CSP)\n\nNext.js and TanStack Start HTML run under nonce CSP: `script-src 'self' 'nonce-\u2026'` and `style-src 'self' 'nonce-\u2026'`, without unsafe-inline. Each request carries a fresh `x-nonce`; the server wrapper adds it to every rendered script/style tag, including hand-written blocks. Inline `style=\"\"` attributes (also inside SVG) and event handlers stay blocked. Move them to CSS/listeners. Tags created later in the browser need the current nonce (the wrapper supplies a `csp-nonce` meta tag); an unnonced tag is blocked. Vite/static pages get no automatic script/style nonces and permit no inline code. Check the deployed response's Content-Security-Policy and actual browser behavior.\n\nDeclare only the browser capabilities the application uses in the committed configuration:\n\n```yaml\nruntime:\n  mode: edge\n  browser:\n    connect: [https://api.customer.example, wss://events.customer.example]\n    scripts: [https://cdn.customer.example]\n    styles: [https://cdn.customer.example]\n    images: [https://images.customer.example]\n    fonts: [https://fonts.customer.example]\n    frames: [https://embed.customer.example]\n    frameAncestors: [https://portal.customer.example]\n    workers: { self: true, blob: false }\n    cors:\n      origins: [https://portal.customer.example]\n      credentials: false\n```\n\nOmitted groups retain restrictive defaults. Each origin group permits at most sixteen distinct exact HTTPS origins; only `connect` also accepts WSS. No wildcards, paths or script/style inline/eval opt-out exist. Resource groups extend their matching CSP directive; worker flags allow only self/blob. `frameAncestors` controls who may embed the app; `frames` controls what it embeds. Application CORS must echo the actual declared origin and its own allowed methods/headers. Cross-origin requests with cookies also require explicit `credentials: true`; undeclared CORS headers are stripped. Same-origin non-GET requests still require matching Origin when cookies are present. Static pages have no default connect permission; use a declared browser destination or an edge companion for application API work. Verify required browser flows, including OAuth callback/pop-up behavior, on the deployed app: these tested declaration interfaces do not prove arbitrary providers or exported Lovable apps work.\n\nFrames, workers and external resources stay blocked when undeclared; service workers, eval/WASM execution and sockets have no general support promise. Do not change CSP to fake a decoder or authentication success.\nThe gateway replaces application CSP and drops Set-Cookie with a Domain attribute; keep session\ncookies host-only. OAuth form-post callbacks must satisfy the explicit CORS/origin policy;\nverify the provider's chosen callback mode instead of assuming a redirect proves a session.\n\n## Framework notes\n\n- Vite static applications need no server companion. With or without a companion, an unknown file path answers `index.html` with HTTP 200, so client-side routing reloads work; render not-found in the client router. Keep Vite `base` unset or `/`. Add the returned companion source only when the application uses database, Auth, mail, files, request functions, or schedules.\n- The functions runtime is a plain Worker module without a framework: `runtime.mode: functions`, `build.install` only, no `build.command` or `build.output`, HTTP through `fetch` and schedules through `scheduled`. Do not add customer Wrangler configuration.\n- TanStack Start uses its native server routes/functions. Import `tanstackStart` from `@tanstack/react-start/plugin/vite`. Static mode needs `tanstackStart({ prerender: { enabled: true } })` and no Cloudflare plugin; edge mode calls `cloudflare({ viteEnvironment: { name: \"ssr\" } })` before `tanstackStart()`. Unknown paths return 404. Keep an active TanStack Start Vite plugin; do not add a customer Wrangler file or platform base path.\n- Next.js Workers builds use the platform OpenNext 1.20.6 overlay and Webpack, including `proxy.ts` Node middleware. The service supplies `--webpack` to the admitted build script; customers do not need to rename middleware or add platform tools/configuration. Custom loaders must support Webpack; a Turbopack-only configuration is not evidence of a compatible Workers build. Keep route handlers, RSC/SSR, assets and images framework-native. Use a default-exported next.config, without `output: standalone`/`export`, `cacheComponents: true` or non-root `basePath`/`assetPrefix`, and pin exact React and react-dom versions. Unknown paths return 404.\n- A dependency that loads WebAssembly through Node filesystem APIs needs a runtime-compatible entrypoint. Prefer its existing `workerd` conditional export, or a small package adapter that statically imports the same pinned `.wasm` modules for Workers and retains the Node entrypoint for local use. Preserve upstream licenses and validation. The shared pipeline carries validated Workers-compatible JavaScript, MJS and WASM modules for plain functions Workers, Vite edge companions, TanStack Start edge and Next.js. Auxiliary modules are at most 5 MiB each, and the Worker/artifact budgets still apply; do not turn them into arbitrary public assets or replace a failing decoder with an always-successful result.\n- Customer-owned custom domains use the normal Paid-domain flow. Native addons and non-functional Workers Node APIs remain typed blockers; the Node proxy filename alone is not a blocker.\n\n## Completion\n\nVerify each requested capability through the customer's supported interfaces and the protected Dev application. Run promotion/rollback/deletion only within their authorized scope; repeated deletion and absence proofs are for explicitly disposable acceptance projects. A root HTTP `200` alone does not prove application authentication or other required flows.\n"
+    text: "# Portable application contracts\n\nUse this reference only when implementing framework or capability code. Product decisions come from `ohmyhost init` and the public CLI, not from provider examples.\n\n## Source and compatibility\n\n- Pin exactly one of `npm`, `pnpm`, `yarn`, or `bun` in `packageManager` and commit exactly one matching frozen lockfile. The direct build commands are `npm run build`, `pnpm run build`, `yarn run build`, or `bun run build`. Bun is pinned to `1.2.22`. Installs are frozen and skip lifecycle scripts (`--ignore-scripts`, or Yarn `--mode=skip-build`); commit generated inputs instead of depending on postinstall.\n- Supported framework config extensions are `.js`, `.mjs`, and `.ts`.\n- Admission windows are Vite `>=5.4.0 <=8.2.2`, TanStack Start `>=1.168.26 <=1.168.49`, Next `15.5.x`, and Next `>=16.0.0 <=16.3.4`. `verified` names an exact tested fixture; another admitted version is `experimental`; an out-of-window or unsupported capability is `unsupported`.\n- `package.json` scripts.build is exactly `next build` or `next build --webpack` for Next.js. Vite and TanStack Start use `vite build`, optionally with one `tsc`, `tsc --noEmit`, `tsc -b` or `tsc --build` stage before or after it joined by `&&`. Arbitrary preparation, `cd`, traversal and lifecycle hooks are outside this build contract. Builds use Node.js 24 and stop after eight minutes; runtime secrets are absent from the build. Commit intentional public build values. Gzipped Worker limits are 10 MiB for Next.js and 5 MiB for other Workers; static output needs `index.html`, at most 10 MiB per file, 25 MiB/1,000 files total and a compressed artifact at most 30 MiB.\n- The platform overlay, not the customer repository, pins OpenNext `1.20.6` and Wrangler `4.125.0`. Do not commit those packages, generated Wrangler files, platform bindings, or `OHMYHOST_BASE_PATH` for hosting.\n\n## The customer chooses application authentication\n\nHosting does not automatically add end-user authentication. The customer or their agent integrates the chosen library/service into the application and owns its user flows, authorization and provider account/configuration. This is separate from WorkOS authenticating the customer to ohmyho.st, `ohmyhost login`, `OHMYHOST_TOKEN`, GitHub consent and protected Dev browser access. Never reuse ohmyho.st's WorkOS tenant, platform keys or agent token for an application's users.\n\nThe supported application-auth interfaces include [Better Auth](https://better-auth.com/docs/installation) and customer-owned [WorkOS AuthKit](https://workos.com/docs/authkit/). Better Auth has retained integration proof; hosted WorkOS Next.js has proof, while other framework/provider combinations need their own hosted evidence. Other OAuth/OIDC integrations must satisfy the actual browser, server, secrets and egress contracts and pass their application tests; a declared origin does not establish complete provider support. Public applications need no auth. Keep other existing customer choices; framework/runtime capability checks apply equally to all dependencies. Use the provider's current first-party SDK/guide for the actual browser or server runtime. Browser integrations use their documented public client identifiers and origin/callback settings; do not request or expose server API/client secrets in a Vite browser bundle. Server integrations use only customer-owned server runtime secrets.\n\nThe current structured platform auth integration accepts `none` or pinned `better-auth`. `none` disables only that managed integration; it does not mean that the application has no login. Do not invent `auth.provider: workos` or another unsupported configuration field. Init reports `application-auth-review` for recognized, unselected auth SDK evidence without enabling managed database/auth/mail. Selecting the optional managed Better Auth integration requires explicit `auth.provider: better-auth` and `database.enabled: true`, with Better Auth pinned exactly to `1.7.1`. Managed mail is optional for verified-user/session/token flows. The private bridge uses ohmyho.st Mail for verification/reset sends; those calls need `mail.enabled: true`, Paid access and the customer's verified sender. For a custom Resend callback, preserve the application-owned Better Auth handler with `auth.provider: none`; that choice disables only the managed bridge, not application login. CLI 0.1.24 may incorrectly return `managed_auth_mail_required`; use the corrective 0.1.25 release or later and preserve the selected auth and sender. An ordinary Better Auth or mail SDK dependency selects no managed capability. A detected mail SDK is also evidence to review, not consent to enable Paid platform mail. Database migration files are separate evidence and do not identify an auth provider. Source admission does not reject SDKs by vendor name; the actual runtime, egress, migration and artifact contracts still apply. Older installed clients/platforms may report `better-auth-conversion` or `supabase_migration_required`: discover/update the installed release and report its limitation instead of treating it as consent to replace auth or delete users.\n\n`BETTER_AUTH_SECRET` and `BETTER_AUTH_URL` are reserved for the platform-managed integration and cannot be set through the customer secret command. An application that owns its Better Auth setup uses its own secret name, for example `APP_AUTH_SECRET`, and maps that value explicitly to Better Auth's `secret` option. Use an application-owned `APP_URL` for its `baseURL`; it must match the trusted Dev/Prod origin. Do not enable managed auth merely to acquire that name or weaken the reserved-name check. Keep platform-owned credentials and application-owned auth configuration separate.\n\nFor the agent's feedback, state:\n\n- The customer's chosen/existing auth system, whether it runs in the app or externally, and the evidence for runtime/SDK compatibility. Preserve the choice unless the customer authorizes a change.\n- Missing configuration: customer-owned provider tenant/project, exact Dev/Prod login/callback/logout origins, necessary egress destinations and required secret **names**. Use the normal secret CLI/stdin handoff for values. Public client IDs/publishable keys are different from private API keys; follow that provider's documentation.\n- Who stores users/sessions and who sends verification/reset mail. An external provider's mail does not automatically need ohmyho.st mail or Paid access. The managed Better Auth bridge requires its database and has a platform sender for email actions; verified-user/session/token flows need no sender. Keep a custom Resend callback in the application-owned Better Auth handler. Only calls through managed ohmyho.st Mail need its capability, Paid access and verified sender; missing sender for that capability is `mail_domain_required`. Report that dependency instead of removing email verification.\n- What was tested: sign-in, callback, authenticated and forbidden access, session handling and sign-out on the real application. For isolated environments, keep auth configuration/sessions/data isolated and register both callback origins; promotion must not copy Dev users or private credentials to Prod.\n- The specific blocker or next action. Keep \u201Ccustomer configuration missing\u201D, \u201Cruntime incompatible\u201D and \u201Cnot yet verified\u201D distinct in the explanation; these are explanatory categories, not new API error codes. Report a suspected platform limitation through feedback, without credentials or user records.\n\nExample feedback: \u201CThis app uses your WorkOS AuthKit account. The ohmyho.st CLI login is separate. Configure this app's Dev/Prod callback URLs and the listed server-secret names. End-user login is not verified until the deployed callback and protected-route tests pass.\u201D\n\n## PostgreSQL and Auth\n\n- Access to ohmyho.st-managed PostgreSQL uses `OHMYHOST_DATABASE`. Neon management, direct migration credentials and managed connection URLs are platform-private. This does not forbid a customer's compatible auth SDK from calling their own external identity provider.\n- Call the database with `createPrivateDatabaseClient` from `@ohmyhost/customer-runtime`; see [database-runtime.md](database-runtime.md) for the working example, what is not available and what it costs. There is no connection string or customer socket; interactive transactions use the bounded `withConnection(callback)` scope. Keep canonical expand-only migrations under the path reported by init.\n- A held scope allows two concurrent transaction/auth connections per physical data area (shared Dev/Prod share them), 100 statements, 30 seconds total and five seconds idle. Close it before storage transfers, email, AI calls or other network waits. An adapter for an existing acquire/close port must release the underlying scope in `finally`; never keep a request-wide transaction open while processing a file.\n- An optional Kysely `0.29.5` dialect is available from `@ohmyhost/customer-runtime/database-kysely`: `createPrivateDatabaseDialect(env.OHMYHOST_DATABASE)` for `new Kysely({ dialect })`. Its `db.transaction().execute(async trx => ...)` uses the actual leased connection with BEGIN/COMMIT or ROLLBACK and close; the same bounds apply. For application-owned Better Auth `1.7.1`, use its own migrated schema, normally `public`: `database: { db: db.withSchema(\"public\"), type: \"postgres\", transaction: true }`. This is separate from the managed auth-lane bridge; `auth.provider: none` provisions no auth tables. The library transaction path is tested; hosted signup/mail still needs application verification. This does not claim Drizzle transaction support.\n- SQL `DATE` and `date[]` elements retain the `YYYY-MM-DD` wire string. They are calendar days, not timezone-bearing JavaScript dates; preserve existing timestamp decoding and normalize only the field that the application's contract requires.\n- When the customer selects the verified Better Auth integration, it owns schema `auth`, UUID IDs, `/api/auth`, secure host-only cookies, database sessions, verification/reset callbacks, and session revocation. Mail is selected separately; preserve the customer's configured sender. Authorization remains explicit in each use case.\n- Read hosted secrets/bindings from the framework context: for Next.js on this runtime, `getCloudflareContext({ async: true }).env`. Keep an explicit local test adapter where useful, but do not activate a localhost-only test factory in production or trust the request Host header as configuration. Check the session, tenant and application repositories through the same hosted database adapter as health.\n- A newly isolated database can have correct tables but no tenant, administrator or application configuration. Use the application's existing, owner-authorized bootstrap/seed path with its real password hashing and tenant/membership rules. Keep this as a controlled one-off script or existing private administrative workflow; do not add a public bootstrap route or a production test-mode switch. Verify login after bootstrap, without copying Dev users into Prod.\n\n- For interactive work a customer can issue a time-bound direct PostgreSQL login with `ohmyhost database access create` / MCP `database_access_create` (mode `read` or `write`, 5 minutes to 24 hours, at most three active per environment) and open it with `ohmyhost database psql`. The connection URI and `psql` command are returned exactly once: use them immediately, never store or commit a connection string or password, and revoke the credential when finished. Such a login can never change schema and row-level security still applies; application code keeps using `OHMYHOST_DATABASE`.\n\nApplication background: [Better Auth PostgreSQL](https://better-auth.com/docs/adapters/postgresql). Customer code uses the scoped database binding; provider connection examples do not replace it.\n\n## Files, mail, functions, and secrets\n\n- Import the storage client from `@ohmyhost/customer-runtime/storage`. The Storage Gateway owns raw R2 bindings, signed operations, quotas, receipts, and cleanup. Files live in the project's hosting region: `storage.jurisdiction` accepts `us` or `eu` and must equal the region chosen when the project was created (`--region`, default `us`); a mismatch fails the plan with `storage_jurisdiction_conflict`. `ohmyhost init` is offline: it writes `us` unless `--region eu` is supplied and preserves an existing configuration. Use the already-created project's region when preparing a new file.\n- Upgrade the CLI/MCP to the current published version first. Then install the runtime under its import name as the exact npm alias that init reports under `runtime.packages.customerRuntime` for every framework; `companion.packages.customerRuntime` and `worker.packages.customerRuntime` are equivalent fields: `\"@ohmyhost/customer-runtime\": \"npm:@amerged/ohmyhost-runtime@<version>\"` in `package.json`. Refresh and commit the lockfile with the project's package manager. Every `@ohmyhost/customer-runtime/*` import stays unchanged. A bare `@ohmyhost/customer-runtime` version fails the platform build, and an `https://ohmyho.st/releases/\u2026` runtime URL stops resolving once a later release replaces the website downloads, so replace such a URL with the alias. Use the version init reports; older runtime versions carry no compatibility promise.\n- A storage-enabled deployment receives exactly five runtime values and **no** `FILES` bucket binding: the private `OHMYHOST_STORAGE_GATEWAY` Service Binding, the plain values `OHMYHOST_STORAGE_GATEWAY_URL`, `OHMYHOST_PROJECT_ID`, `OHMYHOST_ENVIRONMENT_ID`, and the secret `OHMYHOST_STORAGE_KEY`. Pass `endpoint: env.OHMYHOST_STORAGE_GATEWAY_URL`, `key: env.OHMYHOST_STORAGE_KEY`, `projectId: env.OHMYHOST_PROJECT_ID`, `environmentId: env.OHMYHOST_ENVIRONMENT_ID`, `fetch: (request) => env.OHMYHOST_STORAGE_GATEWAY.fetch(request)` and `capabilityFetch: (request) => fetch(request)`. Invalid options answer non-retryable `gateway_configuration_invalid` naming the option; the clients run only on the server.\n- The gateway hop travels over that Service Binding. `OHMYHOST_STORAGE_GATEWAY_URL` only supplies the origin the client builds its request URLs from; it is not a public endpoint. No public or sandbox hostname transport is supported; never call it with ordinary outbound `fetch`. Outbound `fetch` is for the short-lived signed R2 object URL alone.\n- Files are create-once logical names within an immutable data area: shared Dev/Prod use one namespace, isolated environments use separate namespaces. Each name is at most 512 UTF-8 bytes; slash-separated segments start/end with letters or digits and contain only letters, digits, `.`, `_` and `-`, with no traversal. Idempotency keys are 1\u2013128 letters/digits/`._:-`. Content type is a lowercase `type/subtype` without parameters. Uploads and the physical bucket quota are at most 1 GiB, including open reservations; signed capabilities last five minutes. A deletion never makes a used name reusable inside that identity. A reset creates a fresh namespace, so the same logical name can be used again. `storage_quota_exceeded` needs deleting unneeded objects or a smaller upload; `storage_conflict` needs resolving the original name/key receipt rather than retrying a conflicting payload. `storage_upload_expired` needs a new objectKey and idempotencyKey. `storage_delete_pending` means wait until retryAt, then repeat the original deletion; `data_change_in_progress` means observe that operation; `storage_binding_data_changed` needs redeployment of the named environment. Data assignment changes retain exact existing locators, without moving blobs.\n- Store a file with `upload` (or `reserveUpload` &rarr; PUT to the signed URL &rarr; `completeUpload`) and serve it with `createSignedRead`; `deleteObject` releases quota. If `ohmyhost.yaml` declares storage while no source calls `createPrivateStorageClient`, init blocks `storage_client_missing` instead of reporting a clean deployment that fails at the first upload. After uncertain completion, repeat `upload()` with the same bytes, objectKey and idempotencyKey: a create-only PUT's 412 completes the existing reservation. `storage_upload_rejected` is retryable only for 5xx or 429. For recoverable multi-object work, persist reservation/transfer IDs and cleanup progress before transfers; call `completeUpload(transferId)` to reconcile.\n- `readMany({ objectKeys })` reads 1\u20134,000 distinct logical keys through one streaming gateway call. Iterate every result and consume or cancel each found body before the next item; `not_found` is explicit. Completion requires the final frame and exact EOF. Malformed, oversized or truncated framing fails as `gateway_response_invalid`; an aborted read is not a completed batch. `deleteMany({ objects: [{ objectKey, idempotencyKey }] })` accepts the same key limit and distinct per-object keys. Its ordered outcomes are completed, pending with retryAt, or failed with code/retryable. Control JSON/framing is at most 4 MiB, independent of streamed payload bytes. Keep an application manifest for selection/pagination; there is no bucket-list API. Persist outcomes and replay only pending/retryable items with their original keys.\n- A completed deletion requires verified payload erasure; an accepted request, elapsed upload link or old absence receipt alone does not release quota. Prior conditional uploads cannot restore a completed file. Large or interrupted batches may acknowledge only a subset: retain all keys and retry pending/retryable items. `deleteMany` applies one configured deadline across headers and complete JSON; timeout does not undo durable per-file progress. Binary `readMany` keeps its bounded per-frame timeout and requires complete iteration.\n- When the browser's CSP permits only same-origin connections, upload through an application route instead of exposing a provider URL or weakening CSP. Authorize an opaque, short-lived capability against the real upload reservation, tenant, MIME, byte length and expiry. Keep the platform storage key and signed R2 URLs server-side. Bound bytes while reading; an identical completed PUT retry may return success without writing again, while different bytes must conflict.\n- For inspected private files, use a distinct staging key per capability and an immutable final key. Read the staged ETag conditionally, inspect those bounded bytes, write the final object and verify its metadata before committing the application record. Keep staging through the commit; use a durable, bounded cleanup journal afterward, fenced against active upload/processing work. A comment or an unconsumed outbox event is not a running cleanup path. Original downloads remain authorized, conditional and bounded; a signed GET URL is not a signed HEAD capability.\n- Set upload limits to the smallest limit across ingress, storage, content inspection, downstream APIs and response handling. Reuse one application policy in browser hints, routes and provider adapters; a successful storage upload does not prove the parser or AI service can accept it. Preserve truthful decoder and validation failures.\n- Use authenticated same-origin framework routes for bounded request work. Vite may use the companion source contract returned by init; TanStack Start and Next.js retain their native server routes/functions. A project without a web framework sets `runtime.mode: functions` and writes `src/ohmyhost/worker.ts` as a module Worker: `export default { async fetch(request, env, ctx) {\u2026}, async scheduled(controller, env, ctx) {\u2026} }`. It keeps `build.install` only and receives the same database, files, mail, secret and egress bindings as an edge app.\n- Declare scheduled work only through `functions.crons` in `ohmyhost.yaml`: one to eight unique five-field UTC crons with a five-minute minimum. A field is `*` or one canonical integer; minute is an integer or `*/5` through `*/59`, never bare `*`. Sunday is `0`; ranges, lists, names and shortcuts are refused. Day-of-month and weekday must both match when both are fixed. The handler is the `scheduled(controller, env, ctx)` member of the **default export** of `src/ohmyhost/worker.ts` (functions runtime, Next.js, TanStack Start) or of the Vite companion `src/ohmyhost/companion.ts`. Named exports are never invoked; init blocks `worker_module_default_export_required` and `scheduled_handler_missing` with the file path. The platform runs one attempt per cron and UTC minute with a 120-second deadline, retries a thrown error or platform failure up to three attempts, and honors `controller.noRetry()`. Retries retain the original `scheduledTime`, so make side effects idempotent. Dev and Prod schedules follow their own active deployments and can both write the same shared data; decide which owns a task. Finished runs are retained seven days. Each run is billed as one request plus its CPU credits. Runs are visible through `ohmyhost function runs` / MCP `function_runs_list` (per environment, newest first), not through deployment logs.\n- `src/ohmyhost/worker.ts` is bundled by the platform on its own, outside the framework build: tsconfig `paths` resolve, but Vite-only aliases, framework virtual modules and modules that declare TanStack Start server functions or Next.js route handlers do not. Import plain application modules (repositories, storage and database clients from `@ohmyhost/customer-runtime/database`, `/storage` or `/mail`) and keep framework entry code out of the Worker module.\n- HTTP and scheduled customer Workers have 50 ms CPU and ten subrequests per invocation. Network waiting does not consume CPU, but database, gateway and signed-object calls consume requests; batch and page work accordingly. A runtime limit answers HTTP 429 beginning `Runtime limit exceeded`. A functions module must always export a default `fetch`, including a schedules-only application. `functions.crons` on a static runtime fails `scheduled_functions_runtime_unsupported`.\n- Select a small work batch and per-call timeouts that fit the 120-second scheduled deadline. Persist claims, retry state and cleanup progress before acknowledging work; close database scopes before provider calls. Import narrow runtime modules rather than barrel files that pull Next.js routes into the scheduled bundle. Verify that a due run actually completes through `function_runs_list`.\n- For ohmyho.st-managed transactional mail, use `createTransactionalMailClient` from `@ohmyhost/customer-runtime/mail` with the supplied `OHMYHOST_MAIL_GATEWAY_URL`, `OHMYHOST_MAIL_KEY` and `OHMYHOST_PROJECT_ID`, and `fetch: (request) => env.OHMYHOST_MAIL_GATEWAY.fetch(request)`. Resolve the private Service Binding from the framework request context or Worker `env`; it is not a string in `process.env`. A missing binding is a configuration error, not a reason to retry through public `fetch` or disable placement/egress. Keep the same message and idempotency key for an uncertain retry; do not automatically switch transports. Verification/reset mail owned by an external identity provider stays with that integration. Mail bindings exist only for deployed source with `mail.enabled: true`; a verified project domain alone does not install them, and promotion/rollback of undeclared source removes them. Install application-owned private values through stdin-based CLI commands; source lists secret names, never values.\n\n## Source capability declarations\n\nPreserve an existing `ohmyhost.yaml`. Init detects SQL migrations under `postgres/migrations` or `supabase/migrations`, R2 declarations/bindings and `supabase/storage`; this is evidence to review, not permission to migrate an external service. A database declaration has `enabled: true` and its `migrations` path; files use `storage: { provider: r2, jurisdiction: us|eu, public: false }`. Static Vite/TanStack builds serve assets; Next.js, server TanStack and Vite companions use edge mode; plain Workers use functions mode. A runtime mismatch or `auto` fails planning as `framework_conversion_required`. Enable only actual application capabilities.\n\nServer egress uses `runtime.egress.allow`: at most 13 exact HTTPS origins, without trailing slash, paths, credentials, ports, IP literals or local names. An omitted origin answers 403 `Egress denied`; a redirect answers 502 `Egress upstream unavailable` (304 is retained). Call the final destination and declare its origin. Customer Workers cannot open sockets. Browser origins below are a separate declaration and do not authorize server fetches.\n\nThe runtime does not inject a public app URL or an environment-name variable. Declare application-owned origin secrets separately for Dev and Prod. Only managed Better Auth receives its reserved platform base URL. Secret names must be uppercase letters/digits/underscore, begin with a letter and be at most 128 characters; `OHMYHOST_*` and the fixed platform names are reserved for set.\n\n`runtime.healthcheck` defaults to `/`, is a path without a query, and must answer a cookieless GET with 2xx directly within five seconds. An authenticated redirect fails. Health is a minimal public response without secrets; success does not prove other flows.\n\n## Browser media and microphone\n\nVideo/audio playback and microphone access are blocked by default. Server-rendered HTML can opt in with exactly these lines in `public/_headers` and a redeployment; static asset pages cannot opt in. Anything broader is ignored, and camera and geolocation stay blocked.\nMedia loads only from the application's origin or blob URLs; stream stored media through an\nauthorized application route instead of embedding a signed R2 URL.\n\n```text\n/*\n  Content-Security-Policy: media-src 'self' blob:\n  Permissions-Policy: microphone=(self)\n```\n\n## Browser security (CSP)\n\nNext.js and TanStack Start HTML run under nonce CSP: `script-src 'self' 'nonce-\u2026'` and `style-src 'self' 'nonce-\u2026'`, without unsafe-inline. Each request carries a fresh `x-nonce`; the server wrapper adds it to every rendered script/style tag, including hand-written blocks. Inline `style=\"\"` attributes (also inside SVG) and event handlers stay blocked. Move them to CSS/listeners. Tags created later in the browser need the current nonce (the wrapper supplies a `csp-nonce` meta tag); an unnonced tag is blocked. Vite/static pages get no automatic script/style nonces and permit no inline code. Check the deployed response's Content-Security-Policy and actual browser behavior.\n\nDeclare only the browser capabilities the application uses in the committed configuration:\n\n```yaml\nruntime:\n  mode: edge\n  browser:\n    connect: [https://api.customer.example, wss://events.customer.example]\n    scripts: [https://cdn.customer.example]\n    styles: [https://cdn.customer.example]\n    images: [https://images.customer.example]\n    fonts: [https://fonts.customer.example]\n    frames: [https://embed.customer.example]\n    frameAncestors: [https://portal.customer.example]\n    workers: { self: true, blob: false }\n    cors:\n      origins: [https://portal.customer.example]\n      credentials: false\n```\n\nOmitted groups retain restrictive defaults. Each origin group permits at most sixteen distinct exact HTTPS origins; only `connect` also accepts WSS. No wildcards, paths or script/style inline/eval opt-out exist. Resource groups extend their matching CSP directive; worker flags allow only self/blob. `frameAncestors` controls who may embed the app; `frames` controls what it embeds. Application CORS must echo the actual declared origin and its own allowed methods/headers. Cross-origin requests with cookies also require explicit `credentials: true`; undeclared CORS headers are stripped. Same-origin non-GET requests still require matching Origin when cookies are present. Static pages have no default connect permission; use a declared browser destination or an edge companion for application API work. Verify required browser flows, including OAuth callback/pop-up behavior, on the deployed app: these tested declaration interfaces do not prove arbitrary providers or exported Lovable apps work.\n\nFrames, workers and external resources stay blocked when undeclared; service workers, eval/WASM execution and sockets have no general support promise. Do not change CSP to fake a decoder or authentication success.\nThe gateway replaces application CSP and drops Set-Cookie with a Domain attribute; keep session\ncookies host-only. OAuth form-post callbacks must satisfy the explicit CORS/origin policy;\nverify the provider's chosen callback mode instead of assuming a redirect proves a session.\n\n## Framework notes\n\n- Vite static applications need no server companion. With or without a companion, an unknown file path answers `index.html` with HTTP 200, so client-side routing reloads work; render not-found in the client router. Keep Vite `base` unset or `/`. Add the returned companion source only when the application uses database, Auth, mail, files, request functions, or schedules.\n- The functions runtime is a plain Worker module without a framework: `runtime.mode: functions`, `build.install` only, no `build.command` or `build.output`, HTTP through `fetch` and schedules through `scheduled`. Do not add customer Wrangler configuration.\n- TanStack Start uses its native server routes/functions. Import `tanstackStart` from `@tanstack/react-start/plugin/vite`. Static mode needs `tanstackStart({ prerender: { enabled: true } })` and no Cloudflare plugin; edge mode calls `cloudflare({ viteEnvironment: { name: \"ssr\" } })` before `tanstackStart()`. Unknown paths return 404. Keep an active TanStack Start Vite plugin; do not add a customer Wrangler file or platform base path.\n- Next.js Workers builds use the platform OpenNext 1.20.6 overlay and Webpack, including `proxy.ts` Node middleware. The service supplies `--webpack` to the admitted build script; customers do not need to rename middleware or add platform tools/configuration. Custom loaders must support Webpack; a Turbopack-only configuration is not evidence of a compatible Workers build. Keep route handlers, RSC/SSR, assets and images framework-native. Use a default-exported next.config, without `output: standalone`/`export`, `cacheComponents: true` or non-root `basePath`/`assetPrefix`, and pin exact React and react-dom versions. Unknown paths return 404.\n- A dependency that loads WebAssembly through Node filesystem APIs needs a runtime-compatible entrypoint. Prefer its existing `workerd` conditional export, or a small package adapter that statically imports the same pinned `.wasm` modules for Workers and retains the Node entrypoint for local use. Preserve upstream licenses and validation. The shared pipeline carries validated Workers-compatible JavaScript, MJS and WASM modules for plain functions Workers, Vite edge companions, TanStack Start edge and Next.js. Auxiliary modules are at most 5 MiB each, and the Worker/artifact budgets still apply; do not turn them into arbitrary public assets or replace a failing decoder with an always-successful result.\n- Customer-owned custom domains use the normal Paid-domain flow. Native addons and non-functional Workers Node APIs remain typed blockers; the Node proxy filename alone is not a blocker.\n\n## Completion\n\nVerify each requested capability through the customer's supported interfaces and the protected Dev application. Run promotion/rollback/deletion only within their authorized scope; repeated deletion and absence proofs are for explicitly disposable acceptance projects. A root HTTP `200` alone does not prove application authentication or other required flows.\n"
   },
   {
     skillName: "ohmyhost-deploy-github",
@@ -30653,7 +30653,7 @@ var GENERATED_SKILL_RESOURCES = Object.freeze([
     title: "ohmyhost-get-started",
     description: "Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through browser sign-in, and select an organization before the first GitHub deployment. Also use when one computer holds several accounts, a prompt names the user and organization to work as, the customer needs support, or an automation needs a non-expiring API token. Use the deployment Skill once access is ready.",
     mimeType: "text/markdown",
-    text: '---\nname: ohmyhost-get-started\ndescription: Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through browser sign-in, and select an organization before the first GitHub deployment. Also use when one computer holds several accounts, a prompt names the user and organization to work as, the customer needs support, or an automation needs a non-expiring API token. Use the deployment Skill once access is ready.\n---\n\n# Start with ohmyho.st\n\nConnect this agent to the customer\'s account, then continue with the selected GitHub app.\n\n## How to talk to the customer here\n\n- One action per message, in short plain sentences. Give the link, then what they will see.\n- Write in the language the customer writes in. Translate the message templates below; copy no\n  other sentence from this file into the chat.\n- Keep customer-facing messages focused on the action and why it is needed. Avoid narrating\n  routine internal steps; explain an actual limitation when it prevents the requested work.\n- Wait for required browser input before taking actions that depend on it. Independent repository\n  inspection can continue while the customer signs in; do not start another sign-in for the same\n  account or repeat the instruction without new information. Respect the customer\'s existing authorization and scope.\n- Never ask for a password, an email code or a token value. Never paste a credential into chat,\n  source or a command argument.\n- After they report back, verify with a command instead of trusting the report.\n\n## Step 1 \u2014 determine the state before doing anything\n\nIf the customer\'s prompt names an account ("Use my ohmyho.st account user \u2026 in organization \u2026"),\nread "Several accounts on one computer" first. Use that login\'s `--profile-name` on authenticated\nchecks when needed. Then run these checks:\n\n```sh\nohmyhost --version\nohmyhost whoami --json\nohmyhost profile list --json\n```\n\nAlso list the MCP tools of the `ohmyho` server. A saved configuration alone is not a working connection.\n\nRead the result:\n\n| Observation                                               | State                      | Continue with    |\n| --------------------------------------------------------- | -------------------------- | ---------------- |\n| `ohmyhost` missing, or the MCP server exposes no tools    | not installed              | Step 2           |\n| `--version` is older than the published release           | outdated                   | Step 2           |\n| CLI runs, `whoami` fails with `authentication_required`   | installed, signed out      | Step 3           |\n| `whoami` fails with `credential_store_unavailable`        | no usable credential store | Step 5           |\n| `whoami` returns an identity with an organization         | ready                      | Step 5           |\n| `whoami` returns `next_action` instead of an organization | signed in, no workspace    | Step 4           |\n| `whoami` fails with `profile_selection_required`          | several saved logins       | Several accounts |\n\n`whoami` selects the workspace itself when the customer has exactly one, so an identity that\narrives with an organization needs no workspace step. Without an organization, `next_action`\nmeans the choice would be a guess or no workspace exists yet. With an organization,\n`next_action` can name `github connect`: that workspace has no GitHub connection yet, and Step 6\nhandles it.\n\nIf `OHMYHOST_TOKEN` is set in this process, that token is the credential: the CLI and MCP ignore any\nsaved login. Verify its returned identity, organization and selected platform against the task,\neven if a browser is already signed in. If `whoami` succeeds for that account, go to Step 5 without\nstarting another login. If it fails, ask the customer to update the private credential source,\nnot to paste a replacement value into chat.\nDo not send them to a sign-in link, because `ohmyhost login` refuses to run while the variable is set.\nWith a working token, `profile list` can still answer `credential_store_unavailable` on a host\nwithout a credential store; no repair is needed unless the task names a saved login.\n\nSay nothing about a state that needs nothing from the customer. A ready agent deploys without a\nsingle question. Report a state only in the message that also asks them to act, so they never\nreceive one message about the problem and a second one about the link.\n\n## Several accounts on one computer\n\nEach `ohmyhost login` saves one login: one user in one organization, kept in the operating\nsystem\'s credential store. `ohmyhost profile list --json` (MCP `profile_list`) shows each login\'s\nname, user and organization, never a token. There is no active login for the whole computer: with\none saved login every command uses it; with several, every command names one with\n`--profile-name NAME`, MCP tools take `profile_name`, and `OHMYHOST_PROFILE=NAME` binds a whole\nprocess or MCP server. A command with `--organization` (MCP `organization_id`) uses that\norganization\'s login by itself. A project command can also select it from a checkout link,\nincluding a link for its explicit `--project`; `whoami` and `project list` do not select a login\nfrom checkout links, so name one when several are saved. `ohmyhost init` uses no login and\nrefuses `--profile-name`. Another agent\'s choice never changes which account your command runs as.\n\n- When the prompt names a user and an organization, act only as the saved login with exactly that\n  user and organization, and confirm it with `whoami --profile-name NAME` before any change. These\n  IDs are context, not credentials. Never guess an account and never use another login instead.\n- If no saved login matches, add it and send its link and code as in Step 3:\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`. If the browser is\n  signed in as another account, the login saves nothing and answers `login_account_mismatch`:\n  ask the customer to switch the browser to the named account (or use a private window), then\n  repeat the login.\n- When the prompt names only a user ("it has no organization yet"), use the saved login with that\n  user and no organization, confirmed with `whoami --profile-name NAME`. If none exists, add it\n  with `ohmyhost login --user USER_ID --json`, then continue with Step 4.\n- `profile_selection_required` means several logins could run the command: ask the customer which\n  account to use. `profile_not_found` names the login to add, `profile_context_mismatch` means the\n  request contradicts its binding, organization or user, and `environment_token_context_mismatch`\n  means `OHMYHOST_TOKEN` belongs to another account.\n- A saved login never switches organizations. For another workspace, add its own login with\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`.\n  `ohmyhost logout --profile-name NAME` removes only that login.\n- `secret_set_command` takes `profile_name` like every tool and returns a command that names the\n  same login with `--profile-name` plus its user and organization (`--profile-user`,\n  `--profile-organization`); an MCP server with `OHMYHOST_TOKEN` names its key\'s user and\n  organization with `--token-user` and `--token-organization` instead. Keep those flags when you\n  run the command, so the secret is written as exactly this account. A login of that name that\n  belongs to another user or organization, for example on another computer, answers\n  `profile_context_mismatch`. The key form runs only where `OHMYHOST_TOKEN` holds a key of that\n  user and organization, never with a saved login: it answers `environment_token_required` without\n  a key and `environment_token_context_mismatch` with another account\'s key. None of these\n  refusals reads the value or sends anything.\n- Tokens stay in the operating system\'s credential store; the list of saved logins (names, users\n  and organizations, never a token) is kept in `~/.ohmyhost/profiles/`, so agents that sign in at\n  the same moment never lose each other\'s login. One environment keeps up to 64 saved logins;\n  beyond that `login` answers `profile_limit_reached` and saves nothing: ask the customer which\n  saved login to remove with `ohmyhost logout --profile-name NAME`.\n- One checkout can be linked for several organizations, one link each. With several links, name\n  the login with `--profile-name`; an older link without organization is used only after the API\n  confirms that the chosen login can see its project (`linked_project_organization_mismatch`\n  otherwise).\n- Errors that depend on the account name it in `acting_as`: `resource_not_found` with another\n  account\'s login means the wrong login, `github_connection_required` means that workspace has no\n  GitHub connection yet, and `repository_not_installed` means its GitHub App installation does not\n  cover the repository.\n\n## Step 2 \u2014 install what is missing\n\nRead <https://ohmyho.st/llms.txt> and the [CLI/MCP installation guide](https://docs.ohmyho.st/agents/mcp).\nCompare the installed versions with <https://ohmyho.st/client-release.json>: `ohmyhost --version`\nnames the CLI, and `npm ls --global --depth=0` lists both packages (`ohmyhost-mcp` has no\n`--version` flag; it starts the server). When either is missing or older, install both from the\nsource already in use: the current archive URLs from that guide, or npm\n(`npm install --global @amerged/ohmyhost-cli @amerged/ohmyhost-mcp`). Both provide the same\n`ohmyhost` and `ohmyhost-mcp` commands, so uninstall one pair before switching to the other.\nAn older client lacks commands and rejects newer server responses with `response_contract_invalid`;\nan older MCP server reports the same case as `client_request_failed` although connection and login\nwork. Upgrade both clients and reload MCP before treating either as a platform fault; if both are\ncurrent, report it with `feedback_submit`.\n\nRead [harness setup](references/harness-setup.md) and register the local `ohmyhost-mcp` command with this harness\'s documented settings. Preserve other MCP servers, model choices and permission settings. Use `OHMYHOST_ENVIRONMENT=production` for CLI and MCP unless the customer explicitly selected the development platform.\n\nEvery CLI command and MCP tool is listed in [surfaces](references/surfaces.md); use it to find the exact name of a capability a customer asks for instead of guessing or assuming it is missing.\n\nReload the MCP connection after every install or upgrade, then verify `tools/list` and `resources/list`. A running server keeps the tool list it started with, so a freshly installed version is invisible until it restarts. Repeat Step 1 afterwards.\n\n## Step 3 \u2014 the customer signs in once\n\n```sh\nohmyhost login --json\n```\n\nWhen the prompt named a user and organization, add\n`--organization ORGANIZATION_ID --user USER_ID`, so nothing is saved unless the browser signs in\nas exactly that account. Each login is saved under a name derived from its organization;\n`--profile-name NAME` chooses another (lowercase letters, digits, `-` and `_`, starting with a\nletter or digit, at most 63 characters; another name answers `invalid_command`). If that name\nalready belongs to another saved login (`profile_name_conflict`), choose a different name;\nremove the other login only when the customer asks.\n\nStart it as a background process and read its output while it runs: a sign-in link, a confirmation\ncode such as `ABCD-EFGH` and how many minutes both stay valid appear on stderr at once. The\ncommand waits up to 30 minutes for the customer and saves the login only when it ends by itself;\na harness timeout that stops it earlier saves nothing. The sign-in page shows the same code and\nasks the customer to confirm it. Send one message with the full link, code and validity, then\nwait for the customer while leaving the command running.\n\n> I found no valid ohmyho.st login for this account on this computer. Open this link to connect it:\n>\n> [full link exactly as printed]\n>\n> The page shows the code **[code]**. Continue only if it shows exactly this code.\n> Sign in there, or choose **Sign up** on that same page if you do not have an account yet.\n> Link and code are valid for [minutes] minutes; if the page rejects the code, say so and I will send a new one.\n> Tell me when you are done.\n\nRules for this step:\n\n- Always show the code. Every message that carries a sign-in link also carries its code, the first\n  time and after every repeated login. The customer checks it against the page; a code that\n  appears on the page but never in the chat gives them nothing to check.\n- Write the full link on its own line, exactly as the CLI printed it, so the customer sees the\n  address before opening it. Never hide it behind words like "this link" or "sign-in link" and\n  never shorten it; a bare address the chat makes clickable is fine. The customer types nothing.\n- State how long link and code are valid, taking the number from the CLI\'s own message rather than\n  inventing one.\n- Do not ask whether they have an account. The same page serves both, so naming both costs one\n  sentence and saves a round trip.\n- Sign-up is open. There is no invitation, no waitlist and no access code. Never send the customer\n  somewhere else to request access.\n- Wait for the customer. The command completes on its own once they finish; do not start a second\n  login while the first is still open.\n- A confirmation code lives only a few minutes. While `ohmyhost login --json` still runs, it\n  replaces a lapsed code by itself for up to 30 minutes and prints the new link and code: send\n  them the same way. Run the original login command again, keeping its account flags, only\n  after it ended with `device_authorization_expired`. This is expected, not a failure: do not\n  report an error or suggest the customer did something wrong.\n\nWhen the command returns, verify and continue:\n\n```sh\nohmyhost whoami --json\n```\n\n## Step 4 \u2014 make sure a workspace is selected\n\n`login` and `whoami` select the workspace themselves when the customer has exactly one, and their\nresponse names the selected organization. They report `next_action` with several choices, and then\nthe customer decides; with no workspace at all, create the first one. `organization use` binds a\nlogin that has no organization yet; a login that already has one keeps it (use a separate login\nfor another workspace, see "Several accounts on one computer").\n\nAlways look before creating. A verified first portal signup creates or reuses **My workspace**,\nincluding a direct signup or one with an invalid referral. The customer may also have a workspace\nfrom an earlier session:\n\n```sh\nohmyhost organization list --json\nohmyhost organization use --organization "$ORGANIZATION_ID" --json\n```\n\nCreate a workspace only when that list is empty, with a name the customer gave you:\n\n```sh\nohmyhost organization create --name "$ORGANIZATION_NAME" --source "$SIGNUP_SOURCE" --idempotency-key "$ORGANIZATION_REQUEST_KEY" --json\nohmyhost whoami --json\n```\n\n- `--source` (MCP `signup_source`) is optional attribution. If the task mentioned a campaign,\n  referral (`https://ohmyho.st/?r=ref-\u2026`) or flag (`https://ohmyho.st/?r=flag-\u2026`) link, pass its\n  single accepted `r` value unchanged (lowercase letters, digits, `-` and `_`, starting with a\n  letter or digit, at most 64 characters); otherwise omit it. The portal treats a malformed\n  value as Direct, so missing or invalid attribution never blocks signup and earns no referral\n  bonus. The server decides any once-per-user benefit: an eligible\n  referral or active flag on the first workspace gives 1,000 credits and 30 days of Paid, and a\n  registered campaign can add credits; promise nothing else. Attribution is never an access\n  code or secret and is fixed per user: later workspaces pass the same Signup source shown on\n  the portal\'s Profile page (omit the flag for Direct); another value answers `forbidden`.\n- Reuse the same name, source and idempotency key after an interrupted response instead of creating a second organization.\n- Creating a workspace selects it immediately for a login that had none; `whoami` or `identity_get` confirms the selection before you create a project. A login already in another workspace keeps it, and the response names the `login` that adds one for the new workspace.\n- Over MCP, `organization_create`, `organization_list` and `organization_use` do the same and report the same `selected` workspace.\n- Creating, listing and selecting a workspace need the interactive login. An API token can do none of them, and says so.\n- Never create another workspace on your own when the customer already has one.\n- A session that selected none lists no projects: `projects_list` and `ohmyhost project list` answer `organization_required` instead of an empty page. Select a workspace, then read the list again.\n\n## Step 5 \u2014 keep access for later\n\nThe current CLI login is enough to continue; MCP uses it.\n\n`ohmyhost login` saves each login in the operating system\'s credential store, and MCP reads it\nthere. `credential_store_unavailable` means the CLI cannot use that store. On a desktop, ask the\ncustomer to unlock it, then retry. In a container, CI runner or headless Linux, do not start a\nsign-in that cannot be saved: ask the customer to create a user token at\n<https://app.ohmyho.st/tokens> and load it as `OHMYHOST_TOKEN` from a private env file.\n\nFor automation, use `token_create` with `out_file`, or\n`ohmyhost token create --organization ULID --name NAME --idempotency-key KEY --out .env.local --json`.\nThe client appends `OHMYHOST_TOKEN` once to that private env file, sets mode `600` and returns\nonly metadata; the value is never shown in the client result and cannot be read again. The file\nname must start or end with `.env`, be ignored by Git or lie outside the repository\n(`token_file_not_ignored`), and not already hold `OHMYHOST_TOKEN` (`token_file_has_token`).\nConfigure the process to load it. Preserve existing credentials and never put the value in chat,\nsource or a command argument. If `token_file_changed` names an issued key that could not be saved,\nrevoke that key with `token_revoke` or the returned CLI command before creating a replacement\nwith a new idempotency key; `token_value_unavailable` means use the original file or revoke and\nreplace the key, since replay cannot reveal its value.\n\n`OHMYHOST_TOKEN` overrides the saved logins in any process where it is set. A token alone runs every\ncommand in these Skills except these, which need the interactive login: `login`, `logout` (including\n`logout --revoke`), `organization create|list|use`, and `token create|list|revoke`. Run those in a\nprocess without the variable. Never delete a saved token file. A token belongs to one account and\norganization: a command that names another (`--profile-name`, `--organization`, or a checkout\nlinked for another organization) is refused with `environment_token_context_mismatch` before\nanything is sent.\n\n## Step 6 \u2014 continue with the app\n\nConfirm the selected directory and GitHub repository. Read `github_status` for the selected workspace. If it is not connected, an Owner or Admin uses `github_connect` (CLI below), opens its single `authorization_url`, then repeats the same request/key after the browser completes until the returned status is `connected`.\n\n```sh\nohmyhost github status --organization "$ORGANIZATION_ID" --json\nohmyhost github connect --organization "$ORGANIZATION_ID" --idempotency-key "$GITHUB_CONNECT_KEY" --json\n```\n\nThe one link handles the required installation/user authorization. Do not construct a second installation link, replay OAuth callbacks, or ask for an installation ID or provider token. Use the intended GitHub browser profile. A connected installation covers only its selected repositories; if one is missing, open `connection.settings_url` from status, add the repository and repeat its original source-link request/key.\n\nMCP/REST returns these objects directly. CLI JSON wraps the handoff in `authorization` and status\nin `github`: read `authorization.authorization_url` and `github.connection.settings_url`.\nThe handoff lives 30 minutes (`expires_at`). While `pending`, a `last_failure` of\n`provider_unavailable` or `authorization_code_rejected` means reopen the returned\n`authorization_url` with the same key. `failed` or `expired` is final: `account_admin_required`\nneeds the GitHub account owner or organization admin, `installation_access_required` means the\nApp was not installed for that account, `session_inactive` needs a fresh login by a workspace\nOwner or Admin, and `denied` means the customer declined. Resolve the cause, then connect with a\nnew key for the same workspace; never poll a terminal failure.\n\nUse `projects_list` to reuse a project and `project_context_get` when resuming one. Preserve an existing project\'s region. For a new project, an explicit customer region wins; otherwise use a browser-location hint supplied in the customer\'s onboarding prompt and send that region explicitly. Without either, ask once for US or EU. Never infer customer location from the agent/server IP. The API default remains US; the selected region cannot change later.\n\nContinue with the **ohmyhost-deploy-github** Skill when a deployment is requested. Login, workspace creation, GitHub connection and project linking are distinct results; check each returned state rather than treating a completed browser page as deployment success.\n\nSupport runs through this agent. When the customer needs help, reports a bug or asks for a feature, submit a redacted report with `feedback_submit` (CLI `ohmyhost feedback submit`), give the customer the receipt ID and read replies later with `feedback_status`; the **ohmyhost-troubleshoot-deployment** Skill describes a good report. Point the customer to https://ohmyho.st/contact only when they cannot sign in, a billing issue names `contact_support`, or they ask about privacy or the DPA. The customer page is https://docs.ohmyho.st/support.\n'
+    text: '---\nname: ohmyhost-get-started\ndescription: Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through browser sign-in, and select an organization before the first GitHub deployment. Also use when one computer holds several accounts, a prompt names the user and organization to work as, the customer needs support, or an automation needs a non-expiring API token. Use the deployment Skill once access is ready.\n---\n\n# Start with ohmyho.st\n\nConnect this agent to the customer\'s account, then continue with the selected GitHub app.\n\n## What ohmyho.st is and what you can do with it\n\nohmyho.st hosts a customer\'s GitHub app: Vite/React, TanStack Start, Next.js or a plain Worker\nmodule with HTTP handlers and optional cron schedules. Their coding agent operates it through the local\nMCP server or CLI, both calling the same REST API. Deploy a pushed commit to Dev or Prod,\nverify the app, and promote a tested Dev artifact when appropriate. Dev is protected by default;\nthe deployment Skill handles public Dev, data choices and the shared-database promotion rule.\nYou can also give the app Postgres, private runtime secrets, Cloudflare R2 files, optional\ntransactional mail and a custom domain, export its database as an encrypted SQL ZIP, and read\nusage, credits and project budgets. The customer keeps their own application authentication;\nnothing here replaces it. Sign-up is open and free to start.\n\nThe initial connection normally asks the customer to sign in and authorize GitHub for the\nworkspace. A working saved login or API token can avoid another sign-in, and a connected\nworkspace can reuse its GitHub connection. Optional payments, DNS/account consent or harness\nreloads can require further customer action; use the relevant Skill for the feature they chose.\n\nThe whole path, and the proof that each step is done:\n\n| Step | Result                                                        | Proof                                                                                                                         | Section      |\n| ---- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------ |\n| 1    | You know what is installed and who is signed in               | `ohmyhost --version`, `ohmyhost whoami --json` or MCP `identity_get`, and the MCP tool list                                   | Step 1       |\n| 2    | CLI and MCP are current and registered                        | Installed versions match the published release; the harness\'s MCP `tools/list` exposes the tools after any required reload    | Step 2       |\n| 3    | The intended account is authenticated                         | `ohmyhost whoami --json` or MCP `identity_get` returns the intended user                                                      | Step 3       |\n| 4    | A workspace is selected                                       | The identity returns the intended organization                                                                                | Step 4       |\n| 5    | Access survives this session                                  | The same identity check succeeds from a fresh process with its chosen login or private token source                           | Step 5       |\n| 6    | GitHub is connected and existing projects are known           | MCP `github_status` returns `connected`; `projects_list` identifies a project to reuse                                        | Step 6       |\n| 7    | The repository is linked and the app is deployed and verified | MCP `source_get` confirms the linked repository; the deployment operation succeeds and the selected app URL passes its checks | Deploy Skill |\n\nEach step is a separate result. Confirm it using the Proof column; a completed browser page,\na saved MCP configuration or a started process does not substitute for its returned state.\n\nWhich Skill to read next:\n\n| The customer wants to \u2026                                          | Skill                              |\n| ---------------------------------------------------------------- | ---------------------------------- |\n| prepare or adapt an app so it runs here                          | ohmyhost-build-portable-app        |\n| convert a real Supabase database, Auth, Storage or Functions use | ohmyhost-migrate-supabase-postgres |\n| deploy a commit, verify it, promote Dev to Prod                  | ohmyhost-deploy-github             |\n| understand a queued, stuck or failed deployment, or report a bug | ohmyhost-troubleshoot-deployment   |\n| read or change data, database size or Dev-to-Prod migrations     | ohmyhost-manage-database           |\n| connect a custom domain or mail sender                           | ohmyhost-domains-and-mail          |\n| export the database as an encrypted backup                       | ohmyhost-export-database           |\n| see usage, credits or set a spending limit                       | ohmyhost-usage-and-budgets         |\n\nUsers normally reach this Skill from a prompt such as "connect this agent to ohmyho.st and deploy\nthis project". In that case finish Steps 1 to 6 with as few messages as possible, then continue\nwith the deployment Skill without asking again for anything already decided.\n\n## How to talk to the customer here\n\n- One action per message, in short plain sentences. Give the link, then what they will see.\n- Write in the language the customer writes in. Translate the message templates below; copy no\n  other sentence from this file into the chat.\n- Keep customer-facing messages focused on the action and why it is needed. Avoid narrating\n  routine internal steps; explain an actual limitation when it prevents the requested work.\n- Wait for required browser input before taking actions that depend on it. Independent repository\n  inspection can continue while the customer signs in; do not start another sign-in for the same\n  account or repeat the instruction without new information. Respect the customer\'s existing authorization and scope.\n- Never ask for a password, an email code or a token value. Never paste a credential into chat,\n  source or a command argument.\n- After they report back, verify with a command instead of trusting the report.\n\n## Step 1 \u2014 determine the state before doing anything\n\nIf the customer\'s prompt names an account ("Use my ohmyho.st account user \u2026 in organization \u2026"),\nread "Several accounts on one computer" first. Use that login\'s `--profile-name` on authenticated\nchecks when needed. Then run these checks:\n\n```sh\nohmyhost --version\nohmyhost whoami --json\nohmyhost profile list --json\n```\n\nAlso list the MCP tools of the `ohmyho` server. A saved configuration alone is not a working connection.\n\nRead the result:\n\n| Observation                                               | State                      | Continue with    |\n| --------------------------------------------------------- | -------------------------- | ---------------- |\n| `ohmyhost` missing, or the MCP server exposes no tools    | not installed              | Step 2           |\n| `--version` is older than the published release           | outdated                   | Step 2           |\n| CLI runs, `whoami` fails with `authentication_required`   | installed, signed out      | Step 3           |\n| `whoami` fails with `credential_store_unavailable`        | no usable credential store | Step 5           |\n| `whoami` returns an identity with an organization         | ready                      | Step 5           |\n| `whoami` returns `next_action` instead of an organization | signed in, no workspace    | Step 4           |\n| `whoami` fails with `profile_selection_required`          | several saved logins       | Several accounts |\n\n`whoami` selects the workspace itself when the customer has exactly one, so an identity that\narrives with an organization needs no workspace step. Without an organization, `next_action`\nmeans the choice would be a guess or no workspace exists yet. With an organization,\n`next_action` can name `github connect`: that workspace has no GitHub connection yet, and Step 6\nhandles it.\n\nIf `OHMYHOST_TOKEN` is set in this process, that token is the credential: the CLI and MCP ignore any\nsaved login. Verify its returned identity, organization and selected platform against the task,\neven if a browser is already signed in. If `whoami` succeeds for that account, go to Step 5 without\nstarting another login. If it fails, ask the customer to update the private credential source,\nnot to paste a replacement value into chat.\nDo not send them to a sign-in link, because `ohmyhost login` refuses to run while the variable is set.\nWith a working token, `profile list` can still answer `credential_store_unavailable` on a host\nwithout a credential store; no repair is needed unless the task names a saved login.\n\nSay nothing about a state that needs nothing from the customer. A ready agent deploys without a\nsingle question. Report a state only in the message that also asks them to act, so they never\nreceive one message about the problem and a second one about the link.\n\n## Several accounts on one computer\n\nEach `ohmyhost login` saves one login: one user in one organization, kept in the operating\nsystem\'s credential store. `ohmyhost profile list --json` (MCP `profile_list`) shows each login\'s\nname, user and organization, never a token. There is no active login for the whole computer: with\none saved login every command uses it; with several, every command names one with\n`--profile-name NAME`, MCP tools take `profile_name`, and `OHMYHOST_PROFILE=NAME` binds a whole\nprocess or MCP server. A command with `--organization` (MCP `organization_id`) uses that\norganization\'s login by itself. A project command can also select it from a checkout link,\nincluding a link for its explicit `--project`; `whoami` and `project list` do not select a login\nfrom checkout links, so name one when several are saved. `ohmyhost init` uses no login and\nrefuses `--profile-name`. Another agent\'s choice never changes which account your command runs as.\n\n- When the prompt names a user and an organization, act only as the saved login with exactly that\n  user and organization, and confirm it with `whoami --profile-name NAME` before any change. These\n  IDs are context, not credentials. Never guess an account and never use another login instead.\n- If no saved login matches, add it and send its link and code as in Step 3:\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`. If the browser is\n  signed in as another account, the login saves nothing and answers `login_account_mismatch`:\n  ask the customer to switch the browser to the named account (or use a private window), then\n  repeat the login.\n- When the prompt names only a user ("it has no organization yet"), use the saved login with that\n  user and no organization, confirmed with `whoami --profile-name NAME`. If none exists, add it\n  with `ohmyhost login --user USER_ID --json`, then continue with Step 4.\n- `profile_selection_required` means several logins could run the command: ask the customer which\n  account to use. `profile_not_found` names the login to add, `profile_context_mismatch` means the\n  request contradicts its binding, organization or user, and `environment_token_context_mismatch`\n  means `OHMYHOST_TOKEN` belongs to another account.\n- A saved login never switches organizations. For another workspace, add its own login with\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`.\n  `ohmyhost logout --profile-name NAME` removes only that login.\n- `secret_set_command` takes `profile_name` like every tool and returns a command that names the\n  same login with `--profile-name` plus its user and organization (`--profile-user`,\n  `--profile-organization`); an MCP server with `OHMYHOST_TOKEN` names its key\'s user and\n  organization with `--token-user` and `--token-organization` instead. Keep those flags when you\n  run the command, so the secret is written as exactly this account. A login of that name that\n  belongs to another user or organization, for example on another computer, answers\n  `profile_context_mismatch`. The key form runs only where `OHMYHOST_TOKEN` holds a key of that\n  user and organization, never with a saved login: it answers `environment_token_required` without\n  a key and `environment_token_context_mismatch` with another account\'s key. None of these\n  refusals reads the value or sends anything.\n- Tokens stay in the operating system\'s credential store; the list of saved logins (names, users\n  and organizations, never a token) is kept in `~/.ohmyhost/profiles/`, so agents that sign in at\n  the same moment never lose each other\'s login. One environment keeps up to 64 saved logins;\n  beyond that `login` answers `profile_limit_reached` and saves nothing: ask the customer which\n  saved login to remove with `ohmyhost logout --profile-name NAME`.\n- One checkout can be linked for several organizations, one link each. With several links, name\n  the login with `--profile-name`; an older link without organization is used only after the API\n  confirms that the chosen login can see its project (`linked_project_organization_mismatch`\n  otherwise).\n- Errors that depend on the account name it in `acting_as`: `resource_not_found` with another\n  account\'s login means the wrong login, `github_connection_required` means that workspace has no\n  GitHub connection yet, and `repository_not_installed` means its GitHub App installation does not\n  cover the repository.\n\n## Step 2 \u2014 install what is missing\n\nRead <https://ohmyho.st/llms.txt> and the [CLI/MCP installation guide](https://docs.ohmyho.st/agents/mcp).\nCompare the installed versions with <https://ohmyho.st/client-release.json>: `ohmyhost --version`\nnames the CLI, and `npm ls --global --depth=0` lists both packages (`ohmyhost-mcp` has no\n`--version` flag; it starts the server). When either is missing or older, install both from the\nsource already in use: the current archive URLs from that guide, or npm\n(`npm install --global @amerged/ohmyhost-cli @amerged/ohmyhost-mcp`). Both provide the same\n`ohmyhost` and `ohmyhost-mcp` commands, so uninstall one pair before switching to the other.\nAn older client lacks commands and rejects newer server responses with `response_contract_invalid`;\nan older MCP server reports the same case as `client_request_failed` although connection and login\nwork. Upgrade both clients and reload MCP before treating either as a platform fault; if both are\ncurrent, report it with `feedback_submit`.\n\nRead [harness setup](references/harness-setup.md) and register the local `ohmyhost-mcp` command with this harness\'s documented settings. Preserve other MCP servers, model choices and permission settings. Use `OHMYHOST_ENVIRONMENT=production` for CLI and MCP unless the customer explicitly selected the development platform.\n\nEvery CLI command and MCP tool is listed in [surfaces](references/surfaces.md); use it to find the exact name of a capability a customer asks for instead of guessing or assuming it is missing.\n\nReload the MCP connection after every install or upgrade, then verify `tools/list` and `resources/list`. A running server keeps the tool list it started with, so a freshly installed version is invisible until it restarts. Repeat Step 1 afterwards.\n\n## Step 3 \u2014 the customer signs in once\n\n```sh\nohmyhost login --json\n```\n\nWhen the prompt named a user and organization, add\n`--organization ORGANIZATION_ID --user USER_ID`, so nothing is saved unless the browser signs in\nas exactly that account. Each login is saved under a name derived from its organization;\n`--profile-name NAME` chooses another (lowercase letters, digits, `-` and `_`, starting with a\nletter or digit, at most 63 characters; another name answers `invalid_command`). If that name\nalready belongs to another saved login (`profile_name_conflict`), choose a different name;\nremove the other login only when the customer asks.\n\nStart it as a background process and read its output while it runs: a sign-in link, a confirmation\ncode such as `ABCD-EFGH` and how many minutes both stay valid appear on stderr at once. The\ncommand waits up to 30 minutes for the customer and saves the login only when it ends by itself;\na harness timeout that stops it earlier saves nothing. The sign-in page shows the same code and\nasks the customer to confirm it. Send one message with the full link, code and validity, then\nwait for the customer while leaving the command running.\n\n> I found no valid ohmyho.st login for this account on this computer. Open this link to connect it:\n>\n> [full link exactly as printed]\n>\n> The page shows the code **[code]**. Continue only if it shows exactly this code.\n> Sign in there, or choose **Sign up** on that same page if you do not have an account yet.\n> Link and code are valid for [minutes] minutes; if the page rejects the code, say so and I will send a new one.\n> Tell me when you are done.\n\nRules for this step:\n\n- Always show the code. Every message that carries a sign-in link also carries its code, the first\n  time and after every repeated login. The customer checks it against the page; a code that\n  appears on the page but never in the chat gives them nothing to check.\n- Write the full link on its own line, exactly as the CLI printed it, so the customer sees the\n  address before opening it. Never hide it behind words like "this link" or "sign-in link" and\n  never shorten it; a bare address the chat makes clickable is fine. The customer types nothing.\n- State how long link and code are valid, taking the number from the CLI\'s own message rather than\n  inventing one.\n- Do not ask whether they have an account. The same page serves both, so naming both costs one\n  sentence and saves a round trip.\n- Sign-up is open. There is no invitation, no waitlist and no access code. Never send the customer\n  somewhere else to request access.\n- Wait for the customer. The command completes on its own once they finish; do not start a second\n  login while the first is still open.\n- A confirmation code lives only a few minutes. While `ohmyhost login --json` still runs, it\n  replaces a lapsed code by itself for up to 30 minutes and prints the new link and code: send\n  them the same way. Run the original login command again, keeping its account flags, only\n  after it ended with `device_authorization_expired`. This is expected, not a failure: do not\n  report an error or suggest the customer did something wrong.\n\nWhen the command returns, verify and continue:\n\n```sh\nohmyhost whoami --json\n```\n\n## Step 4 \u2014 make sure a workspace is selected\n\n`login` and `whoami` select the workspace themselves when the customer has exactly one, and their\nresponse names the selected organization. They report `next_action` with several choices, and then\nthe customer decides; with no workspace at all, create the first one. `organization use` binds a\nlogin that has no organization yet; a login that already has one keeps it (use a separate login\nfor another workspace, see "Several accounts on one computer").\n\nAlways look before creating. A verified first portal signup creates or reuses **My workspace**,\nincluding a direct signup or one with an invalid referral. The customer may also have a workspace\nfrom an earlier session:\n\n```sh\nohmyhost organization list --json\nohmyhost organization use --organization "$ORGANIZATION_ID" --json\n```\n\nCreate a workspace only when that list is empty, with a name the customer gave you:\n\n```sh\nohmyhost organization create --name "$ORGANIZATION_NAME" --source "$SIGNUP_SOURCE" --idempotency-key "$ORGANIZATION_REQUEST_KEY" --json\nohmyhost whoami --json\n```\n\n- `--source` (MCP `signup_source`) is optional attribution. If the task mentioned a campaign,\n  referral (`https://ohmyho.st/?r=ref-\u2026`) or flag (`https://ohmyho.st/?r=flag-\u2026`) link, pass its\n  single accepted `r` value unchanged (lowercase letters, digits, `-` and `_`, starting with a\n  letter or digit, at most 64 characters); otherwise omit it. The portal treats a malformed\n  value as Direct, so missing or invalid attribution never blocks signup and earns no referral\n  bonus. The server decides any once-per-user benefit: an eligible\n  referral or active flag on the first workspace gives 1,000 credits and 30 days of Paid, and a\n  registered campaign can add credits; promise nothing else. Attribution is never an access\n  code or secret and is fixed per user: later workspaces pass the same Signup source shown on\n  the portal\'s Profile page (omit the flag for Direct); another value answers `forbidden`.\n- Reuse the same name, source and idempotency key after an interrupted response instead of creating a second organization.\n- Creating a workspace selects it immediately for a login that had none; `whoami` or `identity_get` confirms the selection before you create a project. A login already in another workspace keeps it, and the response names the `login` that adds one for the new workspace.\n- Over MCP, `organization_create`, `organization_list` and `organization_use` do the same and report the same `selected` workspace.\n- Creating, listing and selecting a workspace need the interactive login. An API token can do none of them, and says so.\n- Never create another workspace on your own when the customer already has one.\n- A session that selected none lists no projects: `projects_list` and `ohmyhost project list` answer `organization_required` instead of an empty page. Select a workspace, then read the list again.\n\n## Step 5 \u2014 keep access for later\n\nThe current CLI login is enough to continue; MCP uses it.\n\n`ohmyhost login` saves each login in the operating system\'s credential store, and MCP reads it\nthere. `credential_store_unavailable` means the CLI cannot use that store. On a desktop, ask the\ncustomer to unlock it, then retry. In a container, CI runner or headless Linux, do not start a\nsign-in that cannot be saved: ask the customer to create a user token at\n<https://app.ohmyho.st/tokens> and load it as `OHMYHOST_TOKEN` from a private env file.\n\nFor automation, use `token_create` with `out_file`, or\n`ohmyhost token create --organization ULID --name NAME --idempotency-key KEY --out .env.local --json`.\nThe client appends `OHMYHOST_TOKEN` once to that private env file, sets mode `600` and returns\nonly metadata; the value is never shown in the client result and cannot be read again. The file\nname must start or end with `.env`, be ignored by Git or lie outside the repository\n(`token_file_not_ignored`), and not already hold `OHMYHOST_TOKEN` (`token_file_has_token`).\nConfigure the process to load it. Preserve existing credentials and never put the value in chat,\nsource or a command argument. If `token_file_changed` names an issued key that could not be saved,\nrevoke that key with `token_revoke` or the returned CLI command before creating a replacement\nwith a new idempotency key; `token_value_unavailable` means use the original file or revoke and\nreplace the key, since replay cannot reveal its value.\n\n`OHMYHOST_TOKEN` overrides the saved logins in any process where it is set. A token alone runs every\ncommand in these Skills except these, which need the interactive login: `login`, `logout` (including\n`logout --revoke`), `organization create|list|use`, and `token create|list|revoke`. Run those in a\nprocess without the variable. Never delete a saved token file. A token belongs to one account and\norganization: a command that names another (`--profile-name`, `--organization`, or a checkout\nlinked for another organization) is refused with `environment_token_context_mismatch` before\nanything is sent.\n\n## Step 6 \u2014 continue with the app\n\nConfirm the selected directory and GitHub repository. Read `github_status` for the selected workspace. If it is not connected, an Owner or Admin uses `github_connect` (CLI below), opens its single `authorization_url`, then repeats the same request/key after the browser completes until the returned status is `connected`.\n\n```sh\nohmyhost github status --organization "$ORGANIZATION_ID" --json\nohmyhost github connect --organization "$ORGANIZATION_ID" --idempotency-key "$GITHUB_CONNECT_KEY" --json\n```\n\nThe one link handles the required installation/user authorization. Do not construct a second installation link, replay OAuth callbacks, or ask for an installation ID or provider token. Use the intended GitHub browser profile. A connected installation covers only its selected repositories; if one is missing, open `connection.settings_url` from status, add the repository and repeat its original source-link request/key.\n\nMCP/REST returns these objects directly. CLI JSON wraps the handoff in `authorization` and status\nin `github`: read `authorization.authorization_url` and `github.connection.settings_url`.\nThe handoff lives 30 minutes (`expires_at`). While `pending`, a `last_failure` of\n`provider_unavailable` or `authorization_code_rejected` means reopen the returned\n`authorization_url` with the same key. `failed` or `expired` is final: `account_admin_required`\nneeds the GitHub account owner or organization admin, `installation_access_required` means the\nApp was not installed for that account, `session_inactive` needs a fresh login by a workspace\nOwner or Admin, and `denied` means the customer declined. Resolve the cause, then connect with a\nnew key for the same workspace; never poll a terminal failure.\n\nUse `projects_list` to reuse a project and `project_context_get` when resuming one. Preserve an existing project\'s region. For a new project, an explicit customer region wins; otherwise use a browser-location hint supplied in the customer\'s onboarding prompt and send that region explicitly. Without either, ask once for US or EU. Never infer customer location from the agent/server IP. The API default remains US; the selected region cannot change later.\n\nContinue with the **ohmyhost-deploy-github** Skill when a deployment is requested. Login, workspace creation, GitHub connection and project linking are distinct results; check each returned state rather than treating a completed browser page as deployment success.\n\nSupport runs through this agent. When the customer needs help, reports a bug or asks for a feature, submit a redacted report with `feedback_submit` (CLI `ohmyhost feedback submit`), give the customer the receipt ID and read replies later with `feedback_status`; the **ohmyhost-troubleshoot-deployment** Skill describes a good report. Point the customer to https://ohmyho.st/contact only when they cannot sign in, a billing issue names `contact_support`, or they ask about privacy or the DPA. The customer page is https://docs.ohmyho.st/support.\n'
   },
   {
     skillName: "ohmyhost-get-started",
@@ -30689,7 +30689,7 @@ var GENERATED_SKILL_RESOURCES = Object.freeze([
     title: "ohmyhost-migrate-supabase-postgres",
     description: "Migrate customer-selected Supabase capabilities in a TypeScript application to portable PostgreSQL and the ohmyho.st runtime. Use when real Supabase database, Auth, Storage, Functions or Realtime usage needs conversion; not merely because an SDK is installed.",
     mimeType: "text/markdown",
-    text: "---\nname: ohmyhost-migrate-supabase-postgres\ndescription: Migrate customer-selected Supabase capabilities in a TypeScript application to portable PostgreSQL and the ohmyho.st runtime. Use when real Supabase database, Auth, Storage, Functions or Realtime usage needs conversion; not merely because an SDK is installed.\n---\n\n# Migrate a Supabase application\n\nKeep the application working while converting only the capabilities the customer selected.\n\n## Inspect and choose\n\nRun `ohmyhost init --dry-run --json` in the chosen repository. Inventory actual database queries, RPCs, migrations, RLS assumptions, Auth sessions, Storage calls, Edge Functions and Realtime subscriptions. Distinguish used services from unused dependencies and preserve a valid hosting configuration.\n\nExplain what can remain external, what needs application changes, and any unsupported runtime capability. Do not replace the customer's auth provider or discard data without their decision. A database dump does not migrate every Supabase service.\n\nRead [provider contracts](references/provider-contracts.md) only for the affected capabilities. The [portable baseline helper](scripts/create-portable-baseline.mjs) can prepare a reviewed migration baseline; inspect its documented input/output and the selected migration files before running it. It does not grant database authority or prove that application data has moved.\n\n## Convert the selected capabilities\n\n- Replace selected Supabase-specific database calls with typed SQL or narrow repositories through `createPrivateDatabaseClient` and `OHMYHOST_DATABASE`. Use `transaction()` for predefined statements and bounded `withConnection()` for read-decide-write; see [database runtime](../ohmyhost-build-portable-app/references/database-runtime.md). Preserve transaction boundaries, constraints and tenant filtering.\n- Review SQL functions and RLS-dependent assumptions explicitly. Keep immutable migrations in `YYYYMMDDHHMMSS_name.sql` format and follow [expand-only admission](../ohmyhost-manage-database/SKILL.md). Row changes, DROP, CREATE OR REPLACE, roles/grants and changes to existing constraints are refused. Do not convert RLS/JWT helpers into browser-controlled authority or add a Clerk/RLS integration as an incidental migration.\n- Preserve or integrate the customer-chosen application auth. Configure its callback URLs and private server secrets. Test login, protected access, session refresh/reload and logout; hosting login is separate.\n- Convert selected Storage, Functions and Realtime behavior only when the current runtime contract supports the equivalent application behavior. If it does not, state the gap and agree on the feature decision instead of inserting a fake success or silent fallback.\n- Selected Edge Functions become authenticated framework-native server routes or plain Worker handlers. Declare schedules through `functions.crons`; the platform owns cron delivery/retries, rather than customer Queue/Workflow bindings. Existing external functions may stay when the customer chooses them and their declared interfaces are verified.\n- Optional managed Better Auth uses explicit `auth.provider: better-auth`, database and `mail.enabled: true`: its managed bridge always sends verification/reset mail through the private mail capability and needs Paid/verified sender. Missing mail fails early as `managed_auth_mail_required`. To retain application-owned Better Auth or external sending, use `auth.provider: none`; SDK dependency detection alone selects no managed capability. Preserve external auth-provider mail when the customer chooses it.\n- Keep application runtime secrets separate from repository/build inputs. Use `secret_set_command` and the intended environment ID for private values.\n\n## Verify and deploy\n\nRun relevant application tests and the real framework build, then rerun `init` until the selected conversion requirements are resolved. Use **ohmyhost-build-portable-app** for the resulting runtime and **ohmyhost-deploy-github** for publication.\n\nCheck real login, data reads/writes, constraints and any required files, email or functions on the hosted Dev app. Promote only within the customer's request, preserving Prod records. Rollback or deletion tests belong only to separately requested or explicitly disposable test resources.\n\nFor an unsupported operation or suspected platform bug, use `feedback_submit` with a minimal redacted reproduction and the safe operation/error ID. Keep the unresolved capability visible; do not claim the migration complete until the requested application behavior works.\n"
+    text: "---\nname: ohmyhost-migrate-supabase-postgres\ndescription: Migrate customer-selected Supabase capabilities in a TypeScript application to portable PostgreSQL and the ohmyho.st runtime. Use when real Supabase database, Auth, Storage, Functions or Realtime usage needs conversion; not merely because an SDK is installed.\n---\n\n# Migrate a Supabase application\n\nKeep the application working while converting only the capabilities the customer selected.\n\n## Inspect and choose\n\nRun `ohmyhost init --dry-run --json` in the chosen repository. Inventory actual database queries, RPCs, migrations, RLS assumptions, Auth sessions, Storage calls, Edge Functions and Realtime subscriptions. Distinguish used services from unused dependencies and preserve a valid hosting configuration.\n\nExplain what can remain external, what needs application changes, and any unsupported runtime capability. Do not replace the customer's auth provider or discard data without their decision. A database dump does not migrate every Supabase service.\n\nRead [provider contracts](references/provider-contracts.md) only for the affected capabilities. The [portable baseline helper](scripts/create-portable-baseline.mjs) can prepare a reviewed migration baseline; inspect its documented input/output and the selected migration files before running it. It does not grant database authority or prove that application data has moved.\n\n## Convert the selected capabilities\n\n- Replace selected Supabase-specific database calls with typed SQL or narrow repositories through `createPrivateDatabaseClient` and `OHMYHOST_DATABASE`. Use `transaction()` for predefined statements and bounded `withConnection()` for read-decide-write; see [database runtime](../ohmyhost-build-portable-app/references/database-runtime.md). Preserve transaction boundaries, constraints and tenant filtering.\n- Review SQL functions and RLS-dependent assumptions explicitly. Keep immutable migrations in `YYYYMMDDHHMMSS_name.sql` format and follow [expand-only admission](../ohmyhost-manage-database/SKILL.md). Row changes, DROP, CREATE OR REPLACE, roles/grants and changes to existing constraints are refused. Do not convert RLS/JWT helpers into browser-controlled authority or add a Clerk/RLS integration as an incidental migration.\n- Preserve or integrate the customer-chosen application auth. Configure its callback URLs and private server secrets. Test login, protected access, session refresh/reload and logout; hosting login is separate.\n- Convert selected Storage, Functions and Realtime behavior only when the current runtime contract supports the equivalent application behavior. If it does not, state the gap and agree on the feature decision instead of inserting a fake success or silent fallback.\n- Selected Edge Functions become authenticated framework-native server routes or plain Worker handlers. Declare schedules through `functions.crons`; the platform owns cron delivery/retries, rather than customer Queue/Workflow bindings. Existing external functions may stay when the customer chooses them and their declared interfaces are verified.\n- Optional managed Better Auth uses explicit `auth.provider: better-auth` and its database. Managed mail is optional for verified-user/session/token flows; the bridge's verification/reset sends use its platform sender and need `mail.enabled: true`, Paid access and a verified sender. Keep a custom Resend callback in an application-owned Better Auth handler with `auth.provider: none`; this disables only the managed bridge, not Better Auth or login. SDK dependency detection selects no managed capability. CLI 0.1.24 may incorrectly return `managed_auth_mail_required`; use the corrective 0.1.25 release or later and preserve the selected auth and sender.\n- Keep application runtime secrets separate from repository/build inputs. Use `secret_set_command` and the intended environment ID for private values.\n\n## Verify and deploy\n\nRun relevant application tests and the real framework build, then rerun `init` until the selected conversion requirements are resolved. Use **ohmyhost-build-portable-app** for the resulting runtime and **ohmyhost-deploy-github** for publication.\n\nCheck real login, data reads/writes, constraints and any required files, email or functions on the hosted Dev app. Promote only within the customer's request, preserving Prod records. Rollback or deletion tests belong only to separately requested or explicitly disposable test resources.\n\nFor an unsupported operation or suspected platform bug, use `feedback_submit` with a minimal redacted reproduction and the safe operation/error ID. Keep the unresolved capability visible; do not claim the migration complete until the requested application behavior works.\n"
   },
   {
     skillName: "ohmyhost-migrate-supabase-postgres",
@@ -30698,7 +30698,7 @@ var GENERATED_SKILL_RESOURCES = Object.freeze([
     title: "ohmyhost-migrate-supabase-postgres: references/provider-contracts.md",
     description: "Supporting resource for ohmyhost-migrate-supabase-postgres.",
     mimeType: "text/markdown",
-    text: "# Supabase conversion contracts\n\nUse this reference when a detected Supabase capability needs a replacement. Keep each capability independently testable; a PostgreSQL import does not convert Auth, Functions, Storage, Realtime, or mail.\n\n## Portable target\n\n- The repository pins exactly one `npm`, `pnpm`, `yarn`, or `bun` version and commits exactly one matching frozen lockfile.\n- Vite, TanStack Start, and Next.js remain framework-native. The service-owned build overlay pins OpenNext `1.20.6` and Wrangler `4.125.0`; customer source never commits those dependencies, generated configuration, `OHMYHOST_BASE_PATH`, or provider bindings.\n- Preserve the compatibility result from init: `verified` is exact-fixture-proven, `experimental` is admitted with the same artifact validation, and `unsupported` stops.\n\n## Database and Auth\n\n- Replace selected Supabase database/PostgREST calls and browser SQL with authenticated server use cases backed by `OHMYHOST_DATABASE`. A deliberately retained Supabase browser integration needs its exact origins in `runtime.browser`; server routes use `runtime.egress.allow` instead. Verify the real exported app's auth/data flows before claiming it works. Remove `@supabase/supabase-js` only when no deliberately retained customer-owned Supabase Auth or other approved capability still needs it. Retained external auth must be independently verified; SDK package evidence alone neither selects a managed database nor blocks hosting.\n- The regional database service and Neon management are platform-private. Customer code receives only the scoped `OHMYHOST_DATABASE` binding, never a database URL or migration credentials.\n- Convert RPCs to explicit transactions or reviewed PostgreSQL functions with fixed `search_path`, explicit authorization, idempotency, and concurrency tests.\n- Canonical migrations are expand-only `YYYYMMDDHHMMSS_name.sql` files. A reviewed PostgreSQL schema-only dump may include `public` and app-owned `private`, never Supabase `auth` or `storage`.\n- If the customer selects `auth.provider: better-auth`, the managed bridge owns the new `auth` schema, UUID identities, verification/reset mail, host-only cookies, session revocation and database sessions. It requires both managed database and mail, including Paid access/verified sender; missing mail fails early as `managed_auth_mail_required`. Application-owned Better Auth remains a separate ordinary dependency with `auth.provider: none` and its chosen sender. Never recreate browser-controlled JWT GUCs or Supabase roles.\n\nFirst-party references: [Supabase migration scope](https://supabase.com/docs/guides/platform/migrating-to-supabase/postgres), [PostgreSQL pg_dump](https://www.postgresql.org/docs/current/app-pgdump.html), and [Better Auth PostgreSQL](https://better-auth.com/docs/adapters/postgresql). Hosted database code follows [the private runtime contract](../../ohmyhost-build-portable-app/references/database-runtime.md).\n\n## Functions, files, Realtime, and mail\n\n- Move bounded request-local Edge Functions into authenticated same-origin Vite companion handlers, TanStack Start server routes, or Next.js route handlers. Plain Worker functions use `runtime.mode: functions` and `src/ohmyhost/worker.ts` with a default `fetch` and optional default `scheduled(controller, env, ctx)`. Declare `functions.crons` in `ohmyhost.yaml` and verify runs through `function_runs_list`; the platform owns scheduled delivery/retries, without customer Queue/Workflow bindings.\n- Replace Supabase Storage calls with `@ohmyhost/customer-runtime/storage`. The Storage Gateway owns raw R2, signed access, quotas, receipts, and provider cleanup.\n- Realtime is a typed unsupported blocker until a product contract exists. Do not simulate success or replace it with polling without an explicit product decision.\n- Replace application mail selected for ohmyho.st with `createTransactionalMailClient`; set `mail.enabled: true`, configure/verify the customer's Paid sender and let the platform install its environment-specific mail key. Never call customer secret-set for reserved `OHMYHOST_MAIL_KEY`. Receiving uses a signed application webhook whose returned signing secret is installed under an application-owned name such as `APP_MAIL_WEBHOOK_SECRET`. Preserve verification/reset mail handled by the customer's explicitly retained external auth provider.\n\n## Baseline helper\n\nOnly after the customer chooses Better Auth and its server authorization/boundaries are implemented and reviewed, run:\n\n```text\nscripts/create-portable-baseline.mjs --input <dump> --output-directory <migrations> --migration-prefix <YYYYMMDDHHMMSS_slug> --auth-mode better-auth-uuid --authorization-mode server\n```\n\nThe helper converts only `auth.users` and `auth.uid()`, replaces the service-request helper, reports omitted RLS policies, retains admitted app-private functions, and splits output under platform limits. Nonzero conversion/omission counts require review; they are never automatic approval.\n\n## Completion\n\nDelete only the superseded Supabase database clients/configuration, roles, grants, RLS/JWT helpers, Functions and Storage calls after replacement tests pass. Preserve any explicitly retained external authentication integration; do not treat a database move as an auth migration. Then rerun init and verify the actual service-owned build, managed database and required public behavior. Rollback, repeated deletion and provider absence tests require the customer's separate authorization or disposable acceptance resources; do not delete the migrated application after an ordinary deployment. A root HTTP `200` is not completion.\n"
+    text: "# Supabase conversion contracts\n\nUse this reference when a detected Supabase capability needs a replacement. Keep each capability independently testable; a PostgreSQL import does not convert Auth, Functions, Storage, Realtime, or mail.\n\n## Portable target\n\n- The repository pins exactly one `npm`, `pnpm`, `yarn`, or `bun` version and commits exactly one matching frozen lockfile.\n- Vite, TanStack Start, and Next.js remain framework-native. The service-owned build overlay pins OpenNext `1.20.6` and Wrangler `4.125.0`; customer source never commits those dependencies, generated configuration, `OHMYHOST_BASE_PATH`, or provider bindings.\n- Preserve the compatibility result from init: `verified` is exact-fixture-proven, `experimental` is admitted with the same artifact validation, and `unsupported` stops.\n\n## Database and Auth\n\n- Replace selected Supabase database/PostgREST calls and browser SQL with authenticated server use cases backed by `OHMYHOST_DATABASE`. A deliberately retained Supabase browser integration needs its exact origins in `runtime.browser`; server routes use `runtime.egress.allow` instead. Verify the real exported app's auth/data flows before claiming it works. Remove `@supabase/supabase-js` only when no deliberately retained customer-owned Supabase Auth or other approved capability still needs it. Retained external auth must be independently verified; SDK package evidence alone neither selects a managed database nor blocks hosting.\n- The regional database service and Neon management are platform-private. Customer code receives only the scoped `OHMYHOST_DATABASE` binding, never a database URL or migration credentials.\n- Convert RPCs to explicit transactions or reviewed PostgreSQL functions with fixed `search_path`, explicit authorization, idempotency, and concurrency tests.\n- Canonical migrations are expand-only `YYYYMMDDHHMMSS_name.sql` files. A reviewed PostgreSQL schema-only dump may include `public` and app-owned `private`, never Supabase `auth` or `storage`.\n- If the customer selects `auth.provider: better-auth`, the managed bridge owns the new `auth` schema, UUID identities, verification/reset callbacks, host-only cookies, session revocation and database sessions. It requires its managed database; verified-user/session/token flows need no mail sender. The private bridge's verification/reset sends use the platform sender and require `mail.enabled: true`, Paid access and a verified sender when invoked. Preserve a custom Resend callback in an application-owned Better Auth handler with `auth.provider: none`; this disables only the managed bridge and keeps application login. Never recreate browser-controlled JWT GUCs or Supabase roles.\n\nFirst-party references: [Supabase migration scope](https://supabase.com/docs/guides/platform/migrating-to-supabase/postgres), [PostgreSQL pg_dump](https://www.postgresql.org/docs/current/app-pgdump.html), and [Better Auth PostgreSQL](https://better-auth.com/docs/adapters/postgresql). Hosted database code follows [the private runtime contract](../../ohmyhost-build-portable-app/references/database-runtime.md).\n\n## Functions, files, Realtime, and mail\n\n- Move bounded request-local Edge Functions into authenticated same-origin Vite companion handlers, TanStack Start server routes, or Next.js route handlers. Plain Worker functions use `runtime.mode: functions` and `src/ohmyhost/worker.ts` with a default `fetch` and optional default `scheduled(controller, env, ctx)`. Declare `functions.crons` in `ohmyhost.yaml` and verify runs through `function_runs_list`; the platform owns scheduled delivery/retries, without customer Queue/Workflow bindings.\n- Replace Supabase Storage calls with `@ohmyhost/customer-runtime/storage`. The Storage Gateway owns raw R2, signed access, quotas, receipts, and provider cleanup.\n- Realtime is a typed unsupported blocker until a product contract exists. Do not simulate success or replace it with polling without an explicit product decision.\n- Replace application mail selected for ohmyho.st with `createTransactionalMailClient`; set `mail.enabled: true`, configure/verify the customer's Paid sender and let the platform install its environment-specific mail key. Never call customer secret-set for reserved `OHMYHOST_MAIL_KEY`. Receiving uses a signed application webhook whose returned signing secret is installed under an application-owned name such as `APP_MAIL_WEBHOOK_SECRET`. Preserve verification/reset mail handled by the customer's explicitly retained external auth provider.\n\n## Baseline helper\n\nOnly after the customer chooses Better Auth and its server authorization/boundaries are implemented and reviewed, run:\n\n```text\nscripts/create-portable-baseline.mjs --input <dump> --output-directory <migrations> --migration-prefix <YYYYMMDDHHMMSS_slug> --auth-mode better-auth-uuid --authorization-mode server\n```\n\nThe helper converts only `auth.users` and `auth.uid()`, replaces the service-request helper, reports omitted RLS policies, retains admitted app-private functions, and splits output under platform limits. Nonzero conversion/omission counts require review; they are never automatic approval.\n\n## Completion\n\nDelete only the superseded Supabase database clients/configuration, roles, grants, RLS/JWT helpers, Functions and Storage calls after replacement tests pass. Preserve any explicitly retained external authentication integration; do not treat a database move as an auth migration. Then rerun init and verify the actual service-owned build, managed database and required public behavior. Rollback, repeated deletion and provider absence tests require the customer's separate authorization or disposable acceptance resources; do not delete the migrated application after an ordinary deployment. A root HTTP `200` is not completion.\n"
   },
   {
     skillName: "ohmyhost-migrate-supabase-postgres",

package/dist/index.js

@@ -2,7 +2,7 @@ import { createRequire as __ohmyhostCreateRequire } from "node:module"; const re
 import {
   createOhmyhostMcpServer,
   ohmyhostMcpHandler
-} from "./chunk-EEFUMPKG.js";
+} from "./chunk-L5A5FEGY.js";
 export {
   createOhmyhostMcpServer,
   ohmyhostMcpHandler

package/dist/stdio-main.js

@@ -27,7 +27,7 @@ import {
   serverIdentityOf,
   setNegotiatedProtocolVersion,
   validateEnvelopeMeta
-} from "./chunk-EEFUMPKG.js";
+} from "./chunk-L5A5FEGY.js";
 
 // node_modules/.pnpm/@modelcontextprotocol+server@2.0.0/node_modules/@modelcontextprotocol/server/dist/stdio.mjs
 var StdioServerTransport = class {
@@ -812,7 +812,7 @@ function exact2(v, keys) {
 // apps/product-cli/package.json
 var package_default2 = {
   name: "@ohmyhost/product-cli",
-  version: "0.1.24",
+  version: "0.1.25",
   private: true,
   ohmyhost: {
     deployment: "production",
@@ -1875,9 +1875,6 @@ function hasControlCharacter(value, multiline) {
 }
 
 // packages/contracts/dist/customer-auth-admission.js
-function managedCustomerAuthMailMessage(path) {
-  return `"${path}" selects the managed Better Auth bridge, which sends verification and password-reset email through ohmyhost Mail. Set mail.enabled: true and set up a verified mail sender, or set auth.provider: none and keep the application-owned Better Auth configuration and sender. Commit and push the change, then plan the new commit.`;
-}
 function managedCustomerAuthDatabaseMessage(path) {
   return `"${path}" selects the managed Better Auth bridge, which requires the managed PostgreSQL database. Set database.enabled: true with an admitted migrations path, or set auth.provider: none and keep the application-owned authentication configuration. Commit and push the change, then plan the new commit.`;
 }
@@ -1917,10 +1914,6 @@ var FRAMEWORK_CONVERSION_DETAILS = Object.freeze({
     render: managedCustomerAuthDatabaseMessage,
     pattern: /^"([^"]+)" selects the managed Better Auth bridge, which requires the managed PostgreSQL database\. Set database\.enabled: true with an admitted migrations path, or set auth\.provider: none and keep the application-owned authentication configuration\. Commit and push the change, then plan the new commit\.$/u
   }),
-  managed_auth_mail_required: Object.freeze({
-    render: managedCustomerAuthMailMessage,
-    pattern: /^"([^"]+)" selects the managed Better Auth bridge, which sends verification and password-reset email through ohmyhost Mail\. Set mail\.enabled: true and set up a verified mail sender, or set auth\.provider: none and keep the application-owned Better Auth configuration and sender\. Commit and push the change, then plan the new commit\.$/u
-  }),
   database_binding_private: Object.freeze({
     render: (path) => `"${path}" reads a database connection string (DATABASE_URL, HYPERDRIVE, connectionString or a postgres:// URL); none reaches a customer Worker. Call the database with createPrivateDatabaseClient from "@ohmyhost/customer-runtime/database". ${PUSH_AND_PLAN}`,
     pattern: /^"([^"]+)" reads a database connection string \(DATABASE_URL, HYPERDRIVE, connectionString or a postgres:\/\/ URL\); none reaches a customer Worker\. Call the database with createPrivateDatabaseClient from "@ohmyhost\/customer-runtime\/database"\. Commit and push the change, then plan the new commit\.$/u
@@ -1967,7 +1960,7 @@ function parseFrameworkConversionDiagnostic(value) {
   const record5 = value;
   const path = record5["path"];
   const code = record5["code"];
-  if (Object.keys(record5).length !== 2 || !isFrameworkConversionDiagnosticCode(code) || typeof path !== "string" || path.length > 240 || (code === "managed_auth_mail_required" || code === "managed_auth_database_required" ? path !== "ohmyhost.yaml" : !/^[A-Za-z0-9_@()[\]./-]+\.(?:[cm]?[jt]sx?)$/u.test(path)) || path.split("/").some((segment) => segment === "" || segment === "." || segment === ".."))
+  if (Object.keys(record5).length !== 2 || !isFrameworkConversionDiagnosticCode(code) || typeof path !== "string" || path.length > 240 || (code === "managed_auth_database_required" ? path !== "ohmyhost.yaml" : !/^[A-Za-z0-9_@()[\]./-]+\.(?:[cm]?[jt]sx?)$/u.test(path)) || path.split("/").some((segment) => segment === "" || segment === "." || segment === ".."))
     return null;
   return Object.freeze({ code, path });
 }
@@ -7612,7 +7605,7 @@ function createLocalOhmyhostMcpServer(dependencies) {
     idempotencyKey: input.idempotency_key
   }), mutationAnnotations());
   registerProductTool(server, dependencies, "source_get", "Get linked source status", external_exports.object({ project_id: identifier2 }), (client2, input) => client2.getSource(input.project_id));
-  registerProductTool(server, dependencies, "deployment_plan", "Plan an immutable deployment. Preserve the customer's existing authentication integration, such as Better Auth or WorkOS, and use the same generic Next.js/Vite/TanStack runtime contract. ohmyho.st login is separate. Read the app Skill's auth guidance and report actual plan blockers, required secret names/callback configuration and unverified runtime compatibility. The explicitly selected managed Better Auth bridge requires the managed database and mail, including a verified sender; application-owned auth and sender implementations remain ordinary dependencies. Never assume a working platform login proves application login or silently replace its auth provider. The plan builds into Dev unless environment is prod; prod builds straight into Prod without a Dev deployment (a project with shared data and a database must deploy to Dev and promote instead). The plan stays valid for 24 hours.", external_exports.object({
+  registerProductTool(server, dependencies, "deployment_plan", "Plan an immutable deployment. Preserve the customer's existing authentication integration, such as Better Auth or WorkOS, and use the same generic Next.js/Vite/TanStack runtime contract. ohmyho.st login is separate. Read the app Skill's auth guidance and report actual plan blockers, required secret names/callback configuration and unverified runtime compatibility. The explicitly selected managed Better Auth bridge requires the managed database; managed mail is optional, and its verification or password-reset send actions require a configured platform sender. Application-owned Better Auth handlers can use their own sender, including Resend, with auth.provider set to none. Never assume a working platform login proves application login or silently replace its auth provider. The plan builds into Dev unless environment is prod; prod builds straight into Prod without a Dev deployment (a project with shared data and a database must deploy to Dev and promote instead). The plan stays valid for 24 hours.", external_exports.object({
     project_id: identifier2,
     commit_sha: commitSha,
     environment: external_exports.enum(["dev", "prod"]).optional()

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@amerged/ohmyhost-mcp",
-  "version": "0.1.24",
+  "version": "0.1.25",
   "type": "module",
   "engines": {
     "node": ">=22"
@@ -27,6 +27,7 @@
   "bugs": {
     "url": "https://docs.ohmyho.st/support"
   },
+  "mcpName": "io.github.amerged-org/ohmyhost-mcp",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/amerged-org/ohmyhost-mcp.git"

package/src/apps/mcp/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ohmyhost/mcp",
-  "version": "0.1.24",
+  "version": "0.1.25",
   "private": true,
   "ohmyhost": {
     "deployment": "production",

package/src/apps/mcp/src/local-server.ts

@@ -1363,7 +1363,7 @@ export function createLocalOhmyhostMcpServer(dependencies: LocalOhmyhostMcpDepen
     server,
     dependencies,
     "deployment_plan",
-    "Plan an immutable deployment. Preserve the customer's existing authentication integration, such as Better Auth or WorkOS, and use the same generic Next.js/Vite/TanStack runtime contract. ohmyho.st login is separate. Read the app Skill's auth guidance and report actual plan blockers, required secret names/callback configuration and unverified runtime compatibility. The explicitly selected managed Better Auth bridge requires the managed database and mail, including a verified sender; application-owned auth and sender implementations remain ordinary dependencies. Never assume a working platform login proves application login or silently replace its auth provider. The plan builds into Dev unless environment is prod; prod builds straight into Prod without a Dev deployment (a project with shared data and a database must deploy to Dev and promote instead). The plan stays valid for 24 hours.",
+    "Plan an immutable deployment. Preserve the customer's existing authentication integration, such as Better Auth or WorkOS, and use the same generic Next.js/Vite/TanStack runtime contract. ohmyho.st login is separate. Read the app Skill's auth guidance and report actual plan blockers, required secret names/callback configuration and unverified runtime compatibility. The explicitly selected managed Better Auth bridge requires the managed database; managed mail is optional, and its verification or password-reset send actions require a configured platform sender. Application-owned Better Auth handlers can use their own sender, including Resend, with auth.provider set to none. Never assume a working platform login proves application login or silently replace its auth provider. The plan builds into Dev unless environment is prod; prod builds straight into Prod without a Dev deployment (a project with shared data and a database must deploy to Dev and promote instead). The plan stays valid for 24 hours.",
     z.object({
       project_id: identifier,
       commit_sha: commitSha,

package/src/apps/product-cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ohmyhost/product-cli",
-  "version": "0.1.24",
+  "version": "0.1.25",
   "private": true,
   "ohmyhost": {
     "deployment": "production",

package/src/apps/product-cli/src/repository-init.ts

@@ -102,7 +102,6 @@ export interface RepositoryInitBlocker {
     | "database_driver_unsupported"
     | "build_script_missing"
     | "better_auth_version_unsupported"
-    | "managed_auth_mail_required"
     | "managed_auth_database_required"
     | "framework_ambiguous"
     | "framework_unsupported"
@@ -315,6 +314,9 @@ export async function initializeRepository(
         : "none";
   const migrationCount =
     databaseProvider === "supabase" ? supabaseMigrationCount : postgresMigrationCount;
+  // Inventory remains evidence; an existing configuration selects the managed capabilities.
+  const selectedDatabaseProvider =
+    existingConfiguration === null ? databaseProvider : configuredDatabase ? "postgresql" : "none";
   const betterAuth =
     dependencies.has("better-auth") || existingConfiguration?.auth?.provider === "better-auth";
   const workos = [
@@ -390,7 +392,7 @@ export async function initializeRepository(
   });
   const configurationYaml = existingConfigurationYaml ?? generatedConfigurationYaml;
   const capabilities: RuntimeCapabilities = Object.freeze({
-    database: databaseProvider !== "none",
+    database: selectedDatabaseProvider !== "none",
     auth: targetBetterAuth,
     mail: targetMail,
     storage: targetStorage,
@@ -404,7 +406,7 @@ export async function initializeRepository(
     applicationDirectory,
     applicationFiles,
     existingConfiguration?.database?.migrations,
-    databaseProvider,
+    selectedDatabaseProvider,
   );
   const blockers = [
     ...repositoryAdmissionBlockers,
@@ -415,11 +417,13 @@ export async function initializeRepository(
       applicationDirectory,
       applicationFiles,
     )),
-    ...migrationFilenameBlockers(
-      applicationFiles,
-      existingConfiguration?.database?.migrations,
-      databaseProvider,
-    ),
+    ...(selectedDatabaseProvider === "none"
+      ? []
+      : migrationFilenameBlockers(
+          applicationFiles,
+          existingConfiguration?.database?.migrations,
+          selectedDatabaseProvider,
+        )),
     ...migrationSqlAdmissionBlockers,
     ...(await storageClientBlockers(existingConfiguration, applicationDirectory, applicationFiles)),
     ...(await databaseContractBlockers(
@@ -1244,8 +1248,8 @@ function repositoryBlockers(
     });
   }
   const betterAuthVersion = dependencyVersion(packageJson, "better-auth");
-  const managedMailIssue = managedCustomerAuthAdmissionIssue(existingConfiguration);
-  if (managedMailIssue !== null) blockers.push(managedMailIssue);
+  const managedAuthIssue = managedCustomerAuthAdmissionIssue(existingConfiguration);
+  if (managedAuthIssue !== null) blockers.push(managedAuthIssue);
   if (
     existingConfiguration?.auth?.provider === "better-auth" &&
     betterAuthVersion !== null &&

package/src/packages/agent-skills/src/generated-skill-resources.ts

@@ -44,7 +44,7 @@ export const GENERATED_SKILL_RESOURCES = Object.freeze([
     title: "ohmyhost-build-portable-app: references/stack-contracts.md",
     description: "Supporting resource for ohmyhost-build-portable-app.",
     mimeType: "text/markdown",
-    text: "# Portable application contracts\n\nUse this reference only when implementing framework or capability code. Product decisions come from `ohmyhost init` and the public CLI, not from provider examples.\n\n## Source and compatibility\n\n- Pin exactly one of `npm`, `pnpm`, `yarn`, or `bun` in `packageManager` and commit exactly one matching frozen lockfile. The direct build commands are `npm run build`, `pnpm run build`, `yarn run build`, or `bun run build`. Bun is pinned to `1.2.22`. Installs are frozen and skip lifecycle scripts (`--ignore-scripts`, or Yarn `--mode=skip-build`); commit generated inputs instead of depending on postinstall.\n- Supported framework config extensions are `.js`, `.mjs`, and `.ts`.\n- Admission windows are Vite `>=5.4.0 <=8.2.2`, TanStack Start `>=1.168.26 <=1.168.49`, Next `15.5.x`, and Next `>=16.0.0 <=16.3.4`. `verified` names an exact tested fixture; another admitted version is `experimental`; an out-of-window or unsupported capability is `unsupported`.\n- `package.json` scripts.build is exactly `next build` or `next build --webpack` for Next.js. Vite and TanStack Start use `vite build`, optionally with one `tsc`, `tsc --noEmit`, `tsc -b` or `tsc --build` stage before or after it joined by `&&`. Arbitrary preparation, `cd`, traversal and lifecycle hooks are outside this build contract. Builds use Node.js 24 and stop after eight minutes; runtime secrets are absent from the build. Commit intentional public build values. Gzipped Worker limits are 10 MiB for Next.js and 5 MiB for other Workers; static output needs `index.html`, at most 10 MiB per file, 25 MiB/1,000 files total and a compressed artifact at most 30 MiB.\n- The platform overlay, not the customer repository, pins OpenNext `1.20.6` and Wrangler `4.125.0`. Do not commit those packages, generated Wrangler files, platform bindings, or `OHMYHOST_BASE_PATH` for hosting.\n\n## The customer chooses application authentication\n\nHosting does not automatically add end-user authentication. The customer or their agent integrates the chosen library/service into the application and owns its user flows, authorization and provider account/configuration. This is separate from WorkOS authenticating the customer to ohmyho.st, `ohmyhost login`, `OHMYHOST_TOKEN`, GitHub consent and protected Dev browser access. Never reuse ohmyho.st's WorkOS tenant, platform keys or agent token for an application's users.\n\nThe supported application-auth interfaces include [Better Auth](https://better-auth.com/docs/installation) and customer-owned [WorkOS AuthKit](https://workos.com/docs/authkit/). Better Auth has retained integration proof; hosted WorkOS Next.js has proof, while other framework/provider combinations need their own hosted evidence. Other OAuth/OIDC integrations must satisfy the actual browser, server, secrets and egress contracts and pass their application tests; a declared origin does not establish complete provider support. Public applications need no auth. Keep other existing customer choices; framework/runtime capability checks apply equally to all dependencies. Use the provider's current first-party SDK/guide for the actual browser or server runtime. Browser integrations use their documented public client identifiers and origin/callback settings; do not request or expose server API/client secrets in a Vite browser bundle. Server integrations use only customer-owned server runtime secrets.\n\nThe current structured platform auth integration accepts `none` or pinned `better-auth`. `none` disables only that managed integration; it does not mean that the application has no login. Do not invent `auth.provider: workos` or another unsupported configuration field. Init reports `application-auth-review` for recognized, unselected auth SDK evidence without enabling managed database/auth/mail. Selecting the optional managed Better Auth integration requires explicit `auth.provider: better-auth`, `database.enabled: true` and `mail.enabled: true`, with Better Auth pinned exactly to `1.7.1`. This managed HTTP bridge always uses private managed mail for verification/reset. Missing mail is `managed_auth_mail_required` at init/planning: enable managed mail and its Paid verified sender, or set `auth.provider: none` and keep application-owned auth/sending. An ordinary Better Auth or mail SDK dependency selects no managed capability. A detected mail SDK is also evidence to review, not consent to enable Paid platform mail. Database migration files are separate evidence and do not identify an auth provider. Source admission does not reject SDKs by vendor name; the actual runtime, egress, migration and artifact contracts still apply. Older installed clients/platforms may report `better-auth-conversion` or `supabase_migration_required`: discover/update the installed release and report its limitation instead of treating it as consent to replace auth or delete users.\n\n`BETTER_AUTH_SECRET` and `BETTER_AUTH_URL` are reserved for the platform-managed integration and cannot be set through the customer secret command. An application that owns its Better Auth setup uses its own secret name, for example `APP_AUTH_SECRET`, and maps that value explicitly to Better Auth's `secret` option. Use an application-owned `APP_URL` for its `baseURL`; it must match the trusted Dev/Prod origin. Do not enable managed auth merely to acquire that name or weaken the reserved-name check. Keep platform-owned credentials and application-owned auth configuration separate.\n\nFor the agent's feedback, state:\n\n- The customer's chosen/existing auth system, whether it runs in the app or externally, and the evidence for runtime/SDK compatibility. Preserve the choice unless the customer authorizes a change.\n- Missing configuration: customer-owned provider tenant/project, exact Dev/Prod login/callback/logout origins, necessary egress destinations and required secret **names**. Use the normal secret CLI/stdin handoff for values. Public client IDs/publishable keys are different from private API keys; follow that provider's documentation.\n- Who stores users/sessions and who sends verification/reset mail. An external provider's mail does not automatically need ohmyho.st mail or Paid access. The explicitly selected managed Better Auth bridge requires database and managed mail, including Paid access and the customer's verified sender domain; missing mail fails early as `managed_auth_mail_required`, and missing sender as `mail_domain_required`. Application-owned Better Auth or external auth mail need no managed capability unless the application deliberately selects it. Report that dependency instead of removing email verification.\n- What was tested: sign-in, callback, authenticated and forbidden access, session handling and sign-out on the real application. For isolated environments, keep auth configuration/sessions/data isolated and register both callback origins; promotion must not copy Dev users or private credentials to Prod.\n- The specific blocker or next action. Keep “customer configuration missing”, “runtime incompatible” and “not yet verified” distinct in the explanation; these are explanatory categories, not new API error codes. Report a suspected platform limitation through feedback, without credentials or user records.\n\nExample feedback: “This app uses your WorkOS AuthKit account. The ohmyho.st CLI login is separate. Configure this app's Dev/Prod callback URLs and the listed server-secret names. End-user login is not verified until the deployed callback and protected-route tests pass.”\n\n## PostgreSQL and Auth\n\n- Access to ohmyho.st-managed PostgreSQL uses `OHMYHOST_DATABASE`. Neon management, direct migration credentials and managed connection URLs are platform-private. This does not forbid a customer's compatible auth SDK from calling their own external identity provider.\n- Call the database with `createPrivateDatabaseClient` from `@ohmyhost/customer-runtime`; see [database-runtime.md](database-runtime.md) for the working example, what is not available and what it costs. There is no connection string or customer socket; interactive transactions use the bounded `withConnection(callback)` scope. Keep canonical expand-only migrations under the path reported by init.\n- A held scope allows two concurrent transaction/auth connections per physical data area (shared Dev/Prod share them), 100 statements, 30 seconds total and five seconds idle. Close it before storage transfers, email, AI calls or other network waits. An adapter for an existing acquire/close port must release the underlying scope in `finally`; never keep a request-wide transaction open while processing a file.\n- An optional Kysely `0.29.5` dialect is available from `@ohmyhost/customer-runtime/database-kysely`: `createPrivateDatabaseDialect(env.OHMYHOST_DATABASE)` for `new Kysely({ dialect })`. Its `db.transaction().execute(async trx => ...)` uses the actual leased connection with BEGIN/COMMIT or ROLLBACK and close; the same bounds apply. For application-owned Better Auth `1.7.1`, use its own migrated schema, normally `public`: `database: { db: db.withSchema(\"public\"), type: \"postgres\", transaction: true }`. This is separate from the managed auth-lane bridge; `auth.provider: none` provisions no auth tables. The library transaction path is tested; hosted signup/mail still needs application verification. This does not claim Drizzle transaction support.\n- SQL `DATE` and `date[]` elements retain the `YYYY-MM-DD` wire string. They are calendar days, not timezone-bearing JavaScript dates; preserve existing timestamp decoding and normalize only the field that the application's contract requires.\n- When the customer selects the verified Better Auth integration, it owns schema `auth`, UUID IDs, `/api/auth`, secure host-only cookies, database sessions, verification/reset mail, and session revocation. Authorization remains explicit in each use case.\n- Read hosted secrets/bindings from the framework context: for Next.js on this runtime, `getCloudflareContext({ async: true }).env`. Keep an explicit local test adapter where useful, but do not activate a localhost-only test factory in production or trust the request Host header as configuration. Check the session, tenant and application repositories through the same hosted database adapter as health.\n- A newly isolated database can have correct tables but no tenant, administrator or application configuration. Use the application's existing, owner-authorized bootstrap/seed path with its real password hashing and tenant/membership rules. Keep this as a controlled one-off script or existing private administrative workflow; do not add a public bootstrap route or a production test-mode switch. Verify login after bootstrap, without copying Dev users into Prod.\n\n- For interactive work a customer can issue a time-bound direct PostgreSQL login with `ohmyhost database access create` / MCP `database_access_create` (mode `read` or `write`, 5 minutes to 24 hours, at most three active per environment) and open it with `ohmyhost database psql`. The connection URI and `psql` command are returned exactly once: use them immediately, never store or commit a connection string or password, and revoke the credential when finished. Such a login can never change schema and row-level security still applies; application code keeps using `OHMYHOST_DATABASE`.\n\nApplication background: [Better Auth PostgreSQL](https://better-auth.com/docs/adapters/postgresql). Customer code uses the scoped database binding; provider connection examples do not replace it.\n\n## Files, mail, functions, and secrets\n\n- Import the storage client from `@ohmyhost/customer-runtime/storage`. The Storage Gateway owns raw R2 bindings, signed operations, quotas, receipts, and cleanup. Files live in the project's hosting region: `storage.jurisdiction` accepts `us` or `eu` and must equal the region chosen when the project was created (`--region`, default `us`); a mismatch fails the plan with `storage_jurisdiction_conflict`. `ohmyhost init` is offline: it writes `us` unless `--region eu` is supplied and preserves an existing configuration. Use the already-created project's region when preparing a new file.\n- Upgrade the CLI/MCP to the current published version first. Then install the runtime under its import name as the exact npm alias that init reports under `runtime.packages.customerRuntime` for every framework; `companion.packages.customerRuntime` and `worker.packages.customerRuntime` are equivalent fields: `\"@ohmyhost/customer-runtime\": \"npm:@amerged/ohmyhost-runtime@<version>\"` in `package.json`. Refresh and commit the lockfile with the project's package manager. Every `@ohmyhost/customer-runtime/*` import stays unchanged. A bare `@ohmyhost/customer-runtime` version fails the platform build, and an `https://ohmyho.st/releases/…` runtime URL stops resolving once a later release replaces the website downloads, so replace such a URL with the alias. Use the version init reports; older runtime versions carry no compatibility promise.\n- A storage-enabled deployment receives exactly five runtime values and **no** `FILES` bucket binding: the private `OHMYHOST_STORAGE_GATEWAY` Service Binding, the plain values `OHMYHOST_STORAGE_GATEWAY_URL`, `OHMYHOST_PROJECT_ID`, `OHMYHOST_ENVIRONMENT_ID`, and the secret `OHMYHOST_STORAGE_KEY`. Pass `endpoint: env.OHMYHOST_STORAGE_GATEWAY_URL`, `key: env.OHMYHOST_STORAGE_KEY`, `projectId: env.OHMYHOST_PROJECT_ID`, `environmentId: env.OHMYHOST_ENVIRONMENT_ID`, `fetch: (request) => env.OHMYHOST_STORAGE_GATEWAY.fetch(request)` and `capabilityFetch: (request) => fetch(request)`. Invalid options answer non-retryable `gateway_configuration_invalid` naming the option; the clients run only on the server.\n- The gateway hop travels over that Service Binding. `OHMYHOST_STORAGE_GATEWAY_URL` only supplies the origin the client builds its request URLs from; it is not a public endpoint. No public or sandbox hostname transport is supported; never call it with ordinary outbound `fetch`. Outbound `fetch` is for the short-lived signed R2 object URL alone.\n- Files are create-once logical names within an immutable data area: shared Dev/Prod use one namespace, isolated environments use separate namespaces. Each name is at most 512 UTF-8 bytes; slash-separated segments start/end with letters or digits and contain only letters, digits, `.`, `_` and `-`, with no traversal. Idempotency keys are 1–128 letters/digits/`._:-`. Content type is a lowercase `type/subtype` without parameters. Uploads and the physical bucket quota are at most 1 GiB, including open reservations; signed capabilities last five minutes. A deletion never makes a used name reusable inside that identity. A reset creates a fresh namespace, so the same logical name can be used again. `storage_quota_exceeded` needs deleting unneeded objects or a smaller upload; `storage_conflict` needs resolving the original name/key receipt rather than retrying a conflicting payload. `storage_upload_expired` needs a new objectKey and idempotencyKey. `storage_delete_pending` means wait until retryAt, then repeat the original deletion; `data_change_in_progress` means observe that operation; `storage_binding_data_changed` needs redeployment of the named environment. Data assignment changes retain exact existing locators, without moving blobs.\n- Store a file with `upload` (or `reserveUpload` &rarr; PUT to the signed URL &rarr; `completeUpload`) and serve it with `createSignedRead`; `deleteObject` releases quota. If `ohmyhost.yaml` declares storage while no source calls `createPrivateStorageClient`, init blocks `storage_client_missing` instead of reporting a clean deployment that fails at the first upload. After uncertain completion, repeat `upload()` with the same bytes, objectKey and idempotencyKey: a create-only PUT's 412 completes the existing reservation. `storage_upload_rejected` is retryable only for 5xx or 429. For recoverable multi-object work, persist reservation/transfer IDs and cleanup progress before transfers; call `completeUpload(transferId)` to reconcile.\n- `readMany({ objectKeys })` reads 1–4,000 distinct logical keys through one streaming gateway call. Iterate every result and consume or cancel each found body before the next item; `not_found` is explicit. Completion requires the final frame and exact EOF. Malformed, oversized or truncated framing fails as `gateway_response_invalid`; an aborted read is not a completed batch. `deleteMany({ objects: [{ objectKey, idempotencyKey }] })` accepts the same key limit and distinct per-object keys. Its ordered outcomes are completed, pending with retryAt, or failed with code/retryable. Control JSON/framing is at most 4 MiB, independent of streamed payload bytes. Keep an application manifest for selection/pagination; there is no bucket-list API. Persist outcomes and replay only pending/retryable items with their original keys.\n- A completed deletion requires verified payload erasure; an accepted request, elapsed upload link or old absence receipt alone does not release quota. Prior conditional uploads cannot restore a completed file. Large or interrupted batches may acknowledge only a subset: retain all keys and retry pending/retryable items. `deleteMany` applies one configured deadline across headers and complete JSON; timeout does not undo durable per-file progress. Binary `readMany` keeps its bounded per-frame timeout and requires complete iteration.\n- When the browser's CSP permits only same-origin connections, upload through an application route instead of exposing a provider URL or weakening CSP. Authorize an opaque, short-lived capability against the real upload reservation, tenant, MIME, byte length and expiry. Keep the platform storage key and signed R2 URLs server-side. Bound bytes while reading; an identical completed PUT retry may return success without writing again, while different bytes must conflict.\n- For inspected private files, use a distinct staging key per capability and an immutable final key. Read the staged ETag conditionally, inspect those bounded bytes, write the final object and verify its metadata before committing the application record. Keep staging through the commit; use a durable, bounded cleanup journal afterward, fenced against active upload/processing work. A comment or an unconsumed outbox event is not a running cleanup path. Original downloads remain authorized, conditional and bounded; a signed GET URL is not a signed HEAD capability.\n- Set upload limits to the smallest limit across ingress, storage, content inspection, downstream APIs and response handling. Reuse one application policy in browser hints, routes and provider adapters; a successful storage upload does not prove the parser or AI service can accept it. Preserve truthful decoder and validation failures.\n- Use authenticated same-origin framework routes for bounded request work. Vite may use the companion source contract returned by init; TanStack Start and Next.js retain their native server routes/functions. A project without a web framework sets `runtime.mode: functions` and writes `src/ohmyhost/worker.ts` as a module Worker: `export default { async fetch(request, env, ctx) {…}, async scheduled(controller, env, ctx) {…} }`. It keeps `build.install` only and receives the same database, files, mail, secret and egress bindings as an edge app.\n- Declare scheduled work only through `functions.crons` in `ohmyhost.yaml`: one to eight unique five-field UTC crons with a five-minute minimum. A field is `*` or one canonical integer; minute is an integer or `*/5` through `*/59`, never bare `*`. Sunday is `0`; ranges, lists, names and shortcuts are refused. Day-of-month and weekday must both match when both are fixed. The handler is the `scheduled(controller, env, ctx)` member of the **default export** of `src/ohmyhost/worker.ts` (functions runtime, Next.js, TanStack Start) or of the Vite companion `src/ohmyhost/companion.ts`. Named exports are never invoked; init blocks `worker_module_default_export_required` and `scheduled_handler_missing` with the file path. The platform runs one attempt per cron and UTC minute with a 120-second deadline, retries a thrown error or platform failure up to three attempts, and honors `controller.noRetry()`. Retries retain the original `scheduledTime`, so make side effects idempotent. Dev and Prod schedules follow their own active deployments and can both write the same shared data; decide which owns a task. Finished runs are retained seven days. Each run is billed as one request plus its CPU credits. Runs are visible through `ohmyhost function runs` / MCP `function_runs_list` (per environment, newest first), not through deployment logs.\n- `src/ohmyhost/worker.ts` is bundled by the platform on its own, outside the framework build: tsconfig `paths` resolve, but Vite-only aliases, framework virtual modules and modules that declare TanStack Start server functions or Next.js route handlers do not. Import plain application modules (repositories, storage and database clients from `@ohmyhost/customer-runtime/database`, `/storage` or `/mail`) and keep framework entry code out of the Worker module.\n- HTTP and scheduled customer Workers have 50 ms CPU and ten subrequests per invocation. Network waiting does not consume CPU, but database, gateway and signed-object calls consume requests; batch and page work accordingly. A runtime limit answers HTTP 429 beginning `Runtime limit exceeded`. A functions module must always export a default `fetch`, including a schedules-only application. `functions.crons` on a static runtime fails `scheduled_functions_runtime_unsupported`.\n- Select a small work batch and per-call timeouts that fit the 120-second scheduled deadline. Persist claims, retry state and cleanup progress before acknowledging work; close database scopes before provider calls. Import narrow runtime modules rather than barrel files that pull Next.js routes into the scheduled bundle. Verify that a due run actually completes through `function_runs_list`.\n- For ohmyho.st-managed transactional mail, use `createTransactionalMailClient` from `@ohmyhost/customer-runtime/mail` with the supplied `OHMYHOST_MAIL_GATEWAY_URL`, `OHMYHOST_MAIL_KEY` and `OHMYHOST_PROJECT_ID`, and `fetch: (request) => env.OHMYHOST_MAIL_GATEWAY.fetch(request)`. Resolve the private Service Binding from the framework request context or Worker `env`; it is not a string in `process.env`. A missing binding is a configuration error, not a reason to retry through public `fetch` or disable placement/egress. Keep the same message and idempotency key for an uncertain retry; do not automatically switch transports. Verification/reset mail owned by an external identity provider stays with that integration. Mail bindings exist only for deployed source with `mail.enabled: true`; a verified project domain alone does not install them, and promotion/rollback of undeclared source removes them. Install application-owned private values through stdin-based CLI commands; source lists secret names, never values.\n\n## Source capability declarations\n\nPreserve an existing `ohmyhost.yaml`. Init detects SQL migrations under `postgres/migrations` or `supabase/migrations`, R2 declarations/bindings and `supabase/storage`; this is evidence to review, not permission to migrate an external service. A database declaration has `enabled: true` and its `migrations` path; files use `storage: { provider: r2, jurisdiction: us|eu, public: false }`. Static Vite/TanStack builds serve assets; Next.js, server TanStack and Vite companions use edge mode; plain Workers use functions mode. A runtime mismatch or `auto` fails planning as `framework_conversion_required`. Enable only actual application capabilities.\n\nServer egress uses `runtime.egress.allow`: at most 13 exact HTTPS origins, without trailing slash, paths, credentials, ports, IP literals or local names. An omitted origin answers 403 `Egress denied`; a redirect answers 502 `Egress upstream unavailable` (304 is retained). Call the final destination and declare its origin. Customer Workers cannot open sockets. Browser origins below are a separate declaration and do not authorize server fetches.\n\nThe runtime does not inject a public app URL or an environment-name variable. Declare application-owned origin secrets separately for Dev and Prod. Only managed Better Auth receives its reserved platform base URL. Secret names must be uppercase letters/digits/underscore, begin with a letter and be at most 128 characters; `OHMYHOST_*` and the fixed platform names are reserved for set.\n\n`runtime.healthcheck` defaults to `/`, is a path without a query, and must answer a cookieless GET with 2xx directly within five seconds. An authenticated redirect fails. Health is a minimal public response without secrets; success does not prove other flows.\n\n## Browser media and microphone\n\nVideo/audio playback and microphone access are blocked by default. Server-rendered HTML can opt in with exactly these lines in `public/_headers` and a redeployment; static asset pages cannot opt in. Anything broader is ignored, and camera and geolocation stay blocked.\nMedia loads only from the application's origin or blob URLs; stream stored media through an\nauthorized application route instead of embedding a signed R2 URL.\n\n```text\n/*\n  Content-Security-Policy: media-src 'self' blob:\n  Permissions-Policy: microphone=(self)\n```\n\n## Browser security (CSP)\n\nNext.js and TanStack Start HTML run under nonce CSP: `script-src 'self' 'nonce-…'` and `style-src 'self' 'nonce-…'`, without unsafe-inline. Each request carries a fresh `x-nonce`; the server wrapper adds it to every rendered script/style tag, including hand-written blocks. Inline `style=\"\"` attributes (also inside SVG) and event handlers stay blocked. Move them to CSS/listeners. Tags created later in the browser need the current nonce (the wrapper supplies a `csp-nonce` meta tag); an unnonced tag is blocked. Vite/static pages get no automatic script/style nonces and permit no inline code. Check the deployed response's Content-Security-Policy and actual browser behavior.\n\nDeclare only the browser capabilities the application uses in the committed configuration:\n\n```yaml\nruntime:\n  mode: edge\n  browser:\n    connect: [https://api.customer.example, wss://events.customer.example]\n    scripts: [https://cdn.customer.example]\n    styles: [https://cdn.customer.example]\n    images: [https://images.customer.example]\n    fonts: [https://fonts.customer.example]\n    frames: [https://embed.customer.example]\n    frameAncestors: [https://portal.customer.example]\n    workers: { self: true, blob: false }\n    cors:\n      origins: [https://portal.customer.example]\n      credentials: false\n```\n\nOmitted groups retain restrictive defaults. Each origin group permits at most sixteen distinct exact HTTPS origins; only `connect` also accepts WSS. No wildcards, paths or script/style inline/eval opt-out exist. Resource groups extend their matching CSP directive; worker flags allow only self/blob. `frameAncestors` controls who may embed the app; `frames` controls what it embeds. Application CORS must echo the actual declared origin and its own allowed methods/headers. Cross-origin requests with cookies also require explicit `credentials: true`; undeclared CORS headers are stripped. Same-origin non-GET requests still require matching Origin when cookies are present. Static pages have no default connect permission; use a declared browser destination or an edge companion for application API work. Verify required browser flows, including OAuth callback/pop-up behavior, on the deployed app: these tested declaration interfaces do not prove arbitrary providers or exported Lovable apps work.\n\nFrames, workers and external resources stay blocked when undeclared; service workers, eval/WASM execution and sockets have no general support promise. Do not change CSP to fake a decoder or authentication success.\nThe gateway replaces application CSP and drops Set-Cookie with a Domain attribute; keep session\ncookies host-only. OAuth form-post callbacks must satisfy the explicit CORS/origin policy;\nverify the provider's chosen callback mode instead of assuming a redirect proves a session.\n\n## Framework notes\n\n- Vite static applications need no server companion. With or without a companion, an unknown file path answers `index.html` with HTTP 200, so client-side routing reloads work; render not-found in the client router. Keep Vite `base` unset or `/`. Add the returned companion source only when the application uses database, Auth, mail, files, request functions, or schedules.\n- The functions runtime is a plain Worker module without a framework: `runtime.mode: functions`, `build.install` only, no `build.command` or `build.output`, HTTP through `fetch` and schedules through `scheduled`. Do not add customer Wrangler configuration.\n- TanStack Start uses its native server routes/functions. Import `tanstackStart` from `@tanstack/react-start/plugin/vite`. Static mode needs `tanstackStart({ prerender: { enabled: true } })` and no Cloudflare plugin; edge mode calls `cloudflare({ viteEnvironment: { name: \"ssr\" } })` before `tanstackStart()`. Unknown paths return 404. Keep an active TanStack Start Vite plugin; do not add a customer Wrangler file or platform base path.\n- Next.js Workers builds use the platform OpenNext 1.20.6 overlay and Webpack, including `proxy.ts` Node middleware. The service supplies `--webpack` to the admitted build script; customers do not need to rename middleware or add platform tools/configuration. Custom loaders must support Webpack; a Turbopack-only configuration is not evidence of a compatible Workers build. Keep route handlers, RSC/SSR, assets and images framework-native. Use a default-exported next.config, without `output: standalone`/`export`, `cacheComponents: true` or non-root `basePath`/`assetPrefix`, and pin exact React and react-dom versions. Unknown paths return 404.\n- A dependency that loads WebAssembly through Node filesystem APIs needs a runtime-compatible entrypoint. Prefer its existing `workerd` conditional export, or a small package adapter that statically imports the same pinned `.wasm` modules for Workers and retains the Node entrypoint for local use. Preserve upstream licenses and validation. The shared pipeline carries validated Workers-compatible JavaScript, MJS and WASM modules for plain functions Workers, Vite edge companions, TanStack Start edge and Next.js. Auxiliary modules are at most 5 MiB each, and the Worker/artifact budgets still apply; do not turn them into arbitrary public assets or replace a failing decoder with an always-successful result.\n- Customer-owned custom domains use the normal Paid-domain flow. Native addons and non-functional Workers Node APIs remain typed blockers; the Node proxy filename alone is not a blocker.\n\n## Completion\n\nVerify each requested capability through the customer's supported interfaces and the protected Dev application. Run promotion/rollback/deletion only within their authorized scope; repeated deletion and absence proofs are for explicitly disposable acceptance projects. A root HTTP `200` alone does not prove application authentication or other required flows.\n",
+    text: "# Portable application contracts\n\nUse this reference only when implementing framework or capability code. Product decisions come from `ohmyhost init` and the public CLI, not from provider examples.\n\n## Source and compatibility\n\n- Pin exactly one of `npm`, `pnpm`, `yarn`, or `bun` in `packageManager` and commit exactly one matching frozen lockfile. The direct build commands are `npm run build`, `pnpm run build`, `yarn run build`, or `bun run build`. Bun is pinned to `1.2.22`. Installs are frozen and skip lifecycle scripts (`--ignore-scripts`, or Yarn `--mode=skip-build`); commit generated inputs instead of depending on postinstall.\n- Supported framework config extensions are `.js`, `.mjs`, and `.ts`.\n- Admission windows are Vite `>=5.4.0 <=8.2.2`, TanStack Start `>=1.168.26 <=1.168.49`, Next `15.5.x`, and Next `>=16.0.0 <=16.3.4`. `verified` names an exact tested fixture; another admitted version is `experimental`; an out-of-window or unsupported capability is `unsupported`.\n- `package.json` scripts.build is exactly `next build` or `next build --webpack` for Next.js. Vite and TanStack Start use `vite build`, optionally with one `tsc`, `tsc --noEmit`, `tsc -b` or `tsc --build` stage before or after it joined by `&&`. Arbitrary preparation, `cd`, traversal and lifecycle hooks are outside this build contract. Builds use Node.js 24 and stop after eight minutes; runtime secrets are absent from the build. Commit intentional public build values. Gzipped Worker limits are 10 MiB for Next.js and 5 MiB for other Workers; static output needs `index.html`, at most 10 MiB per file, 25 MiB/1,000 files total and a compressed artifact at most 30 MiB.\n- The platform overlay, not the customer repository, pins OpenNext `1.20.6` and Wrangler `4.125.0`. Do not commit those packages, generated Wrangler files, platform bindings, or `OHMYHOST_BASE_PATH` for hosting.\n\n## The customer chooses application authentication\n\nHosting does not automatically add end-user authentication. The customer or their agent integrates the chosen library/service into the application and owns its user flows, authorization and provider account/configuration. This is separate from WorkOS authenticating the customer to ohmyho.st, `ohmyhost login`, `OHMYHOST_TOKEN`, GitHub consent and protected Dev browser access. Never reuse ohmyho.st's WorkOS tenant, platform keys or agent token for an application's users.\n\nThe supported application-auth interfaces include [Better Auth](https://better-auth.com/docs/installation) and customer-owned [WorkOS AuthKit](https://workos.com/docs/authkit/). Better Auth has retained integration proof; hosted WorkOS Next.js has proof, while other framework/provider combinations need their own hosted evidence. Other OAuth/OIDC integrations must satisfy the actual browser, server, secrets and egress contracts and pass their application tests; a declared origin does not establish complete provider support. Public applications need no auth. Keep other existing customer choices; framework/runtime capability checks apply equally to all dependencies. Use the provider's current first-party SDK/guide for the actual browser or server runtime. Browser integrations use their documented public client identifiers and origin/callback settings; do not request or expose server API/client secrets in a Vite browser bundle. Server integrations use only customer-owned server runtime secrets.\n\nThe current structured platform auth integration accepts `none` or pinned `better-auth`. `none` disables only that managed integration; it does not mean that the application has no login. Do not invent `auth.provider: workos` or another unsupported configuration field. Init reports `application-auth-review` for recognized, unselected auth SDK evidence without enabling managed database/auth/mail. Selecting the optional managed Better Auth integration requires explicit `auth.provider: better-auth` and `database.enabled: true`, with Better Auth pinned exactly to `1.7.1`. Managed mail is optional for verified-user/session/token flows. The private bridge uses ohmyho.st Mail for verification/reset sends; those calls need `mail.enabled: true`, Paid access and the customer's verified sender. For a custom Resend callback, preserve the application-owned Better Auth handler with `auth.provider: none`; that choice disables only the managed bridge, not application login. CLI 0.1.24 may incorrectly return `managed_auth_mail_required`; use the corrective 0.1.25 release or later and preserve the selected auth and sender. An ordinary Better Auth or mail SDK dependency selects no managed capability. A detected mail SDK is also evidence to review, not consent to enable Paid platform mail. Database migration files are separate evidence and do not identify an auth provider. Source admission does not reject SDKs by vendor name; the actual runtime, egress, migration and artifact contracts still apply. Older installed clients/platforms may report `better-auth-conversion` or `supabase_migration_required`: discover/update the installed release and report its limitation instead of treating it as consent to replace auth or delete users.\n\n`BETTER_AUTH_SECRET` and `BETTER_AUTH_URL` are reserved for the platform-managed integration and cannot be set through the customer secret command. An application that owns its Better Auth setup uses its own secret name, for example `APP_AUTH_SECRET`, and maps that value explicitly to Better Auth's `secret` option. Use an application-owned `APP_URL` for its `baseURL`; it must match the trusted Dev/Prod origin. Do not enable managed auth merely to acquire that name or weaken the reserved-name check. Keep platform-owned credentials and application-owned auth configuration separate.\n\nFor the agent's feedback, state:\n\n- The customer's chosen/existing auth system, whether it runs in the app or externally, and the evidence for runtime/SDK compatibility. Preserve the choice unless the customer authorizes a change.\n- Missing configuration: customer-owned provider tenant/project, exact Dev/Prod login/callback/logout origins, necessary egress destinations and required secret **names**. Use the normal secret CLI/stdin handoff for values. Public client IDs/publishable keys are different from private API keys; follow that provider's documentation.\n- Who stores users/sessions and who sends verification/reset mail. An external provider's mail does not automatically need ohmyho.st mail or Paid access. The managed Better Auth bridge requires its database and has a platform sender for email actions; verified-user/session/token flows need no sender. Keep a custom Resend callback in the application-owned Better Auth handler. Only calls through managed ohmyho.st Mail need its capability, Paid access and verified sender; missing sender for that capability is `mail_domain_required`. Report that dependency instead of removing email verification.\n- What was tested: sign-in, callback, authenticated and forbidden access, session handling and sign-out on the real application. For isolated environments, keep auth configuration/sessions/data isolated and register both callback origins; promotion must not copy Dev users or private credentials to Prod.\n- The specific blocker or next action. Keep “customer configuration missing”, “runtime incompatible” and “not yet verified” distinct in the explanation; these are explanatory categories, not new API error codes. Report a suspected platform limitation through feedback, without credentials or user records.\n\nExample feedback: “This app uses your WorkOS AuthKit account. The ohmyho.st CLI login is separate. Configure this app's Dev/Prod callback URLs and the listed server-secret names. End-user login is not verified until the deployed callback and protected-route tests pass.”\n\n## PostgreSQL and Auth\n\n- Access to ohmyho.st-managed PostgreSQL uses `OHMYHOST_DATABASE`. Neon management, direct migration credentials and managed connection URLs are platform-private. This does not forbid a customer's compatible auth SDK from calling their own external identity provider.\n- Call the database with `createPrivateDatabaseClient` from `@ohmyhost/customer-runtime`; see [database-runtime.md](database-runtime.md) for the working example, what is not available and what it costs. There is no connection string or customer socket; interactive transactions use the bounded `withConnection(callback)` scope. Keep canonical expand-only migrations under the path reported by init.\n- A held scope allows two concurrent transaction/auth connections per physical data area (shared Dev/Prod share them), 100 statements, 30 seconds total and five seconds idle. Close it before storage transfers, email, AI calls or other network waits. An adapter for an existing acquire/close port must release the underlying scope in `finally`; never keep a request-wide transaction open while processing a file.\n- An optional Kysely `0.29.5` dialect is available from `@ohmyhost/customer-runtime/database-kysely`: `createPrivateDatabaseDialect(env.OHMYHOST_DATABASE)` for `new Kysely({ dialect })`. Its `db.transaction().execute(async trx => ...)` uses the actual leased connection with BEGIN/COMMIT or ROLLBACK and close; the same bounds apply. For application-owned Better Auth `1.7.1`, use its own migrated schema, normally `public`: `database: { db: db.withSchema(\"public\"), type: \"postgres\", transaction: true }`. This is separate from the managed auth-lane bridge; `auth.provider: none` provisions no auth tables. The library transaction path is tested; hosted signup/mail still needs application verification. This does not claim Drizzle transaction support.\n- SQL `DATE` and `date[]` elements retain the `YYYY-MM-DD` wire string. They are calendar days, not timezone-bearing JavaScript dates; preserve existing timestamp decoding and normalize only the field that the application's contract requires.\n- When the customer selects the verified Better Auth integration, it owns schema `auth`, UUID IDs, `/api/auth`, secure host-only cookies, database sessions, verification/reset callbacks, and session revocation. Mail is selected separately; preserve the customer's configured sender. Authorization remains explicit in each use case.\n- Read hosted secrets/bindings from the framework context: for Next.js on this runtime, `getCloudflareContext({ async: true }).env`. Keep an explicit local test adapter where useful, but do not activate a localhost-only test factory in production or trust the request Host header as configuration. Check the session, tenant and application repositories through the same hosted database adapter as health.\n- A newly isolated database can have correct tables but no tenant, administrator or application configuration. Use the application's existing, owner-authorized bootstrap/seed path with its real password hashing and tenant/membership rules. Keep this as a controlled one-off script or existing private administrative workflow; do not add a public bootstrap route or a production test-mode switch. Verify login after bootstrap, without copying Dev users into Prod.\n\n- For interactive work a customer can issue a time-bound direct PostgreSQL login with `ohmyhost database access create` / MCP `database_access_create` (mode `read` or `write`, 5 minutes to 24 hours, at most three active per environment) and open it with `ohmyhost database psql`. The connection URI and `psql` command are returned exactly once: use them immediately, never store or commit a connection string or password, and revoke the credential when finished. Such a login can never change schema and row-level security still applies; application code keeps using `OHMYHOST_DATABASE`.\n\nApplication background: [Better Auth PostgreSQL](https://better-auth.com/docs/adapters/postgresql). Customer code uses the scoped database binding; provider connection examples do not replace it.\n\n## Files, mail, functions, and secrets\n\n- Import the storage client from `@ohmyhost/customer-runtime/storage`. The Storage Gateway owns raw R2 bindings, signed operations, quotas, receipts, and cleanup. Files live in the project's hosting region: `storage.jurisdiction` accepts `us` or `eu` and must equal the region chosen when the project was created (`--region`, default `us`); a mismatch fails the plan with `storage_jurisdiction_conflict`. `ohmyhost init` is offline: it writes `us` unless `--region eu` is supplied and preserves an existing configuration. Use the already-created project's region when preparing a new file.\n- Upgrade the CLI/MCP to the current published version first. Then install the runtime under its import name as the exact npm alias that init reports under `runtime.packages.customerRuntime` for every framework; `companion.packages.customerRuntime` and `worker.packages.customerRuntime` are equivalent fields: `\"@ohmyhost/customer-runtime\": \"npm:@amerged/ohmyhost-runtime@<version>\"` in `package.json`. Refresh and commit the lockfile with the project's package manager. Every `@ohmyhost/customer-runtime/*` import stays unchanged. A bare `@ohmyhost/customer-runtime` version fails the platform build, and an `https://ohmyho.st/releases/…` runtime URL stops resolving once a later release replaces the website downloads, so replace such a URL with the alias. Use the version init reports; older runtime versions carry no compatibility promise.\n- A storage-enabled deployment receives exactly five runtime values and **no** `FILES` bucket binding: the private `OHMYHOST_STORAGE_GATEWAY` Service Binding, the plain values `OHMYHOST_STORAGE_GATEWAY_URL`, `OHMYHOST_PROJECT_ID`, `OHMYHOST_ENVIRONMENT_ID`, and the secret `OHMYHOST_STORAGE_KEY`. Pass `endpoint: env.OHMYHOST_STORAGE_GATEWAY_URL`, `key: env.OHMYHOST_STORAGE_KEY`, `projectId: env.OHMYHOST_PROJECT_ID`, `environmentId: env.OHMYHOST_ENVIRONMENT_ID`, `fetch: (request) => env.OHMYHOST_STORAGE_GATEWAY.fetch(request)` and `capabilityFetch: (request) => fetch(request)`. Invalid options answer non-retryable `gateway_configuration_invalid` naming the option; the clients run only on the server.\n- The gateway hop travels over that Service Binding. `OHMYHOST_STORAGE_GATEWAY_URL` only supplies the origin the client builds its request URLs from; it is not a public endpoint. No public or sandbox hostname transport is supported; never call it with ordinary outbound `fetch`. Outbound `fetch` is for the short-lived signed R2 object URL alone.\n- Files are create-once logical names within an immutable data area: shared Dev/Prod use one namespace, isolated environments use separate namespaces. Each name is at most 512 UTF-8 bytes; slash-separated segments start/end with letters or digits and contain only letters, digits, `.`, `_` and `-`, with no traversal. Idempotency keys are 1–128 letters/digits/`._:-`. Content type is a lowercase `type/subtype` without parameters. Uploads and the physical bucket quota are at most 1 GiB, including open reservations; signed capabilities last five minutes. A deletion never makes a used name reusable inside that identity. A reset creates a fresh namespace, so the same logical name can be used again. `storage_quota_exceeded` needs deleting unneeded objects or a smaller upload; `storage_conflict` needs resolving the original name/key receipt rather than retrying a conflicting payload. `storage_upload_expired` needs a new objectKey and idempotencyKey. `storage_delete_pending` means wait until retryAt, then repeat the original deletion; `data_change_in_progress` means observe that operation; `storage_binding_data_changed` needs redeployment of the named environment. Data assignment changes retain exact existing locators, without moving blobs.\n- Store a file with `upload` (or `reserveUpload` &rarr; PUT to the signed URL &rarr; `completeUpload`) and serve it with `createSignedRead`; `deleteObject` releases quota. If `ohmyhost.yaml` declares storage while no source calls `createPrivateStorageClient`, init blocks `storage_client_missing` instead of reporting a clean deployment that fails at the first upload. After uncertain completion, repeat `upload()` with the same bytes, objectKey and idempotencyKey: a create-only PUT's 412 completes the existing reservation. `storage_upload_rejected` is retryable only for 5xx or 429. For recoverable multi-object work, persist reservation/transfer IDs and cleanup progress before transfers; call `completeUpload(transferId)` to reconcile.\n- `readMany({ objectKeys })` reads 1–4,000 distinct logical keys through one streaming gateway call. Iterate every result and consume or cancel each found body before the next item; `not_found` is explicit. Completion requires the final frame and exact EOF. Malformed, oversized or truncated framing fails as `gateway_response_invalid`; an aborted read is not a completed batch. `deleteMany({ objects: [{ objectKey, idempotencyKey }] })` accepts the same key limit and distinct per-object keys. Its ordered outcomes are completed, pending with retryAt, or failed with code/retryable. Control JSON/framing is at most 4 MiB, independent of streamed payload bytes. Keep an application manifest for selection/pagination; there is no bucket-list API. Persist outcomes and replay only pending/retryable items with their original keys.\n- A completed deletion requires verified payload erasure; an accepted request, elapsed upload link or old absence receipt alone does not release quota. Prior conditional uploads cannot restore a completed file. Large or interrupted batches may acknowledge only a subset: retain all keys and retry pending/retryable items. `deleteMany` applies one configured deadline across headers and complete JSON; timeout does not undo durable per-file progress. Binary `readMany` keeps its bounded per-frame timeout and requires complete iteration.\n- When the browser's CSP permits only same-origin connections, upload through an application route instead of exposing a provider URL or weakening CSP. Authorize an opaque, short-lived capability against the real upload reservation, tenant, MIME, byte length and expiry. Keep the platform storage key and signed R2 URLs server-side. Bound bytes while reading; an identical completed PUT retry may return success without writing again, while different bytes must conflict.\n- For inspected private files, use a distinct staging key per capability and an immutable final key. Read the staged ETag conditionally, inspect those bounded bytes, write the final object and verify its metadata before committing the application record. Keep staging through the commit; use a durable, bounded cleanup journal afterward, fenced against active upload/processing work. A comment or an unconsumed outbox event is not a running cleanup path. Original downloads remain authorized, conditional and bounded; a signed GET URL is not a signed HEAD capability.\n- Set upload limits to the smallest limit across ingress, storage, content inspection, downstream APIs and response handling. Reuse one application policy in browser hints, routes and provider adapters; a successful storage upload does not prove the parser or AI service can accept it. Preserve truthful decoder and validation failures.\n- Use authenticated same-origin framework routes for bounded request work. Vite may use the companion source contract returned by init; TanStack Start and Next.js retain their native server routes/functions. A project without a web framework sets `runtime.mode: functions` and writes `src/ohmyhost/worker.ts` as a module Worker: `export default { async fetch(request, env, ctx) {…}, async scheduled(controller, env, ctx) {…} }`. It keeps `build.install` only and receives the same database, files, mail, secret and egress bindings as an edge app.\n- Declare scheduled work only through `functions.crons` in `ohmyhost.yaml`: one to eight unique five-field UTC crons with a five-minute minimum. A field is `*` or one canonical integer; minute is an integer or `*/5` through `*/59`, never bare `*`. Sunday is `0`; ranges, lists, names and shortcuts are refused. Day-of-month and weekday must both match when both are fixed. The handler is the `scheduled(controller, env, ctx)` member of the **default export** of `src/ohmyhost/worker.ts` (functions runtime, Next.js, TanStack Start) or of the Vite companion `src/ohmyhost/companion.ts`. Named exports are never invoked; init blocks `worker_module_default_export_required` and `scheduled_handler_missing` with the file path. The platform runs one attempt per cron and UTC minute with a 120-second deadline, retries a thrown error or platform failure up to three attempts, and honors `controller.noRetry()`. Retries retain the original `scheduledTime`, so make side effects idempotent. Dev and Prod schedules follow their own active deployments and can both write the same shared data; decide which owns a task. Finished runs are retained seven days. Each run is billed as one request plus its CPU credits. Runs are visible through `ohmyhost function runs` / MCP `function_runs_list` (per environment, newest first), not through deployment logs.\n- `src/ohmyhost/worker.ts` is bundled by the platform on its own, outside the framework build: tsconfig `paths` resolve, but Vite-only aliases, framework virtual modules and modules that declare TanStack Start server functions or Next.js route handlers do not. Import plain application modules (repositories, storage and database clients from `@ohmyhost/customer-runtime/database`, `/storage` or `/mail`) and keep framework entry code out of the Worker module.\n- HTTP and scheduled customer Workers have 50 ms CPU and ten subrequests per invocation. Network waiting does not consume CPU, but database, gateway and signed-object calls consume requests; batch and page work accordingly. A runtime limit answers HTTP 429 beginning `Runtime limit exceeded`. A functions module must always export a default `fetch`, including a schedules-only application. `functions.crons` on a static runtime fails `scheduled_functions_runtime_unsupported`.\n- Select a small work batch and per-call timeouts that fit the 120-second scheduled deadline. Persist claims, retry state and cleanup progress before acknowledging work; close database scopes before provider calls. Import narrow runtime modules rather than barrel files that pull Next.js routes into the scheduled bundle. Verify that a due run actually completes through `function_runs_list`.\n- For ohmyho.st-managed transactional mail, use `createTransactionalMailClient` from `@ohmyhost/customer-runtime/mail` with the supplied `OHMYHOST_MAIL_GATEWAY_URL`, `OHMYHOST_MAIL_KEY` and `OHMYHOST_PROJECT_ID`, and `fetch: (request) => env.OHMYHOST_MAIL_GATEWAY.fetch(request)`. Resolve the private Service Binding from the framework request context or Worker `env`; it is not a string in `process.env`. A missing binding is a configuration error, not a reason to retry through public `fetch` or disable placement/egress. Keep the same message and idempotency key for an uncertain retry; do not automatically switch transports. Verification/reset mail owned by an external identity provider stays with that integration. Mail bindings exist only for deployed source with `mail.enabled: true`; a verified project domain alone does not install them, and promotion/rollback of undeclared source removes them. Install application-owned private values through stdin-based CLI commands; source lists secret names, never values.\n\n## Source capability declarations\n\nPreserve an existing `ohmyhost.yaml`. Init detects SQL migrations under `postgres/migrations` or `supabase/migrations`, R2 declarations/bindings and `supabase/storage`; this is evidence to review, not permission to migrate an external service. A database declaration has `enabled: true` and its `migrations` path; files use `storage: { provider: r2, jurisdiction: us|eu, public: false }`. Static Vite/TanStack builds serve assets; Next.js, server TanStack and Vite companions use edge mode; plain Workers use functions mode. A runtime mismatch or `auto` fails planning as `framework_conversion_required`. Enable only actual application capabilities.\n\nServer egress uses `runtime.egress.allow`: at most 13 exact HTTPS origins, without trailing slash, paths, credentials, ports, IP literals or local names. An omitted origin answers 403 `Egress denied`; a redirect answers 502 `Egress upstream unavailable` (304 is retained). Call the final destination and declare its origin. Customer Workers cannot open sockets. Browser origins below are a separate declaration and do not authorize server fetches.\n\nThe runtime does not inject a public app URL or an environment-name variable. Declare application-owned origin secrets separately for Dev and Prod. Only managed Better Auth receives its reserved platform base URL. Secret names must be uppercase letters/digits/underscore, begin with a letter and be at most 128 characters; `OHMYHOST_*` and the fixed platform names are reserved for set.\n\n`runtime.healthcheck` defaults to `/`, is a path without a query, and must answer a cookieless GET with 2xx directly within five seconds. An authenticated redirect fails. Health is a minimal public response without secrets; success does not prove other flows.\n\n## Browser media and microphone\n\nVideo/audio playback and microphone access are blocked by default. Server-rendered HTML can opt in with exactly these lines in `public/_headers` and a redeployment; static asset pages cannot opt in. Anything broader is ignored, and camera and geolocation stay blocked.\nMedia loads only from the application's origin or blob URLs; stream stored media through an\nauthorized application route instead of embedding a signed R2 URL.\n\n```text\n/*\n  Content-Security-Policy: media-src 'self' blob:\n  Permissions-Policy: microphone=(self)\n```\n\n## Browser security (CSP)\n\nNext.js and TanStack Start HTML run under nonce CSP: `script-src 'self' 'nonce-…'` and `style-src 'self' 'nonce-…'`, without unsafe-inline. Each request carries a fresh `x-nonce`; the server wrapper adds it to every rendered script/style tag, including hand-written blocks. Inline `style=\"\"` attributes (also inside SVG) and event handlers stay blocked. Move them to CSS/listeners. Tags created later in the browser need the current nonce (the wrapper supplies a `csp-nonce` meta tag); an unnonced tag is blocked. Vite/static pages get no automatic script/style nonces and permit no inline code. Check the deployed response's Content-Security-Policy and actual browser behavior.\n\nDeclare only the browser capabilities the application uses in the committed configuration:\n\n```yaml\nruntime:\n  mode: edge\n  browser:\n    connect: [https://api.customer.example, wss://events.customer.example]\n    scripts: [https://cdn.customer.example]\n    styles: [https://cdn.customer.example]\n    images: [https://images.customer.example]\n    fonts: [https://fonts.customer.example]\n    frames: [https://embed.customer.example]\n    frameAncestors: [https://portal.customer.example]\n    workers: { self: true, blob: false }\n    cors:\n      origins: [https://portal.customer.example]\n      credentials: false\n```\n\nOmitted groups retain restrictive defaults. Each origin group permits at most sixteen distinct exact HTTPS origins; only `connect` also accepts WSS. No wildcards, paths or script/style inline/eval opt-out exist. Resource groups extend their matching CSP directive; worker flags allow only self/blob. `frameAncestors` controls who may embed the app; `frames` controls what it embeds. Application CORS must echo the actual declared origin and its own allowed methods/headers. Cross-origin requests with cookies also require explicit `credentials: true`; undeclared CORS headers are stripped. Same-origin non-GET requests still require matching Origin when cookies are present. Static pages have no default connect permission; use a declared browser destination or an edge companion for application API work. Verify required browser flows, including OAuth callback/pop-up behavior, on the deployed app: these tested declaration interfaces do not prove arbitrary providers or exported Lovable apps work.\n\nFrames, workers and external resources stay blocked when undeclared; service workers, eval/WASM execution and sockets have no general support promise. Do not change CSP to fake a decoder or authentication success.\nThe gateway replaces application CSP and drops Set-Cookie with a Domain attribute; keep session\ncookies host-only. OAuth form-post callbacks must satisfy the explicit CORS/origin policy;\nverify the provider's chosen callback mode instead of assuming a redirect proves a session.\n\n## Framework notes\n\n- Vite static applications need no server companion. With or without a companion, an unknown file path answers `index.html` with HTTP 200, so client-side routing reloads work; render not-found in the client router. Keep Vite `base` unset or `/`. Add the returned companion source only when the application uses database, Auth, mail, files, request functions, or schedules.\n- The functions runtime is a plain Worker module without a framework: `runtime.mode: functions`, `build.install` only, no `build.command` or `build.output`, HTTP through `fetch` and schedules through `scheduled`. Do not add customer Wrangler configuration.\n- TanStack Start uses its native server routes/functions. Import `tanstackStart` from `@tanstack/react-start/plugin/vite`. Static mode needs `tanstackStart({ prerender: { enabled: true } })` and no Cloudflare plugin; edge mode calls `cloudflare({ viteEnvironment: { name: \"ssr\" } })` before `tanstackStart()`. Unknown paths return 404. Keep an active TanStack Start Vite plugin; do not add a customer Wrangler file or platform base path.\n- Next.js Workers builds use the platform OpenNext 1.20.6 overlay and Webpack, including `proxy.ts` Node middleware. The service supplies `--webpack` to the admitted build script; customers do not need to rename middleware or add platform tools/configuration. Custom loaders must support Webpack; a Turbopack-only configuration is not evidence of a compatible Workers build. Keep route handlers, RSC/SSR, assets and images framework-native. Use a default-exported next.config, without `output: standalone`/`export`, `cacheComponents: true` or non-root `basePath`/`assetPrefix`, and pin exact React and react-dom versions. Unknown paths return 404.\n- A dependency that loads WebAssembly through Node filesystem APIs needs a runtime-compatible entrypoint. Prefer its existing `workerd` conditional export, or a small package adapter that statically imports the same pinned `.wasm` modules for Workers and retains the Node entrypoint for local use. Preserve upstream licenses and validation. The shared pipeline carries validated Workers-compatible JavaScript, MJS and WASM modules for plain functions Workers, Vite edge companions, TanStack Start edge and Next.js. Auxiliary modules are at most 5 MiB each, and the Worker/artifact budgets still apply; do not turn them into arbitrary public assets or replace a failing decoder with an always-successful result.\n- Customer-owned custom domains use the normal Paid-domain flow. Native addons and non-functional Workers Node APIs remain typed blockers; the Node proxy filename alone is not a blocker.\n\n## Completion\n\nVerify each requested capability through the customer's supported interfaces and the protected Dev application. Run promotion/rollback/deletion only within their authorized scope; repeated deletion and absence proofs are for explicitly disposable acceptance projects. A root HTTP `200` alone does not prove application authentication or other required flows.\n",
   },
   {
     skillName: "ohmyhost-deploy-github",
@@ -84,7 +84,7 @@ export const GENERATED_SKILL_RESOURCES = Object.freeze([
     description:
       "Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through browser sign-in, and select an organization before the first GitHub deployment. Also use when one computer holds several accounts, a prompt names the user and organization to work as, the customer needs support, or an automation needs a non-expiring API token. Use the deployment Skill once access is ready.",
     mimeType: "text/markdown",
-    text: '---\nname: ohmyhost-get-started\ndescription: Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through browser sign-in, and select an organization before the first GitHub deployment. Also use when one computer holds several accounts, a prompt names the user and organization to work as, the customer needs support, or an automation needs a non-expiring API token. Use the deployment Skill once access is ready.\n---\n\n# Start with ohmyho.st\n\nConnect this agent to the customer\'s account, then continue with the selected GitHub app.\n\n## How to talk to the customer here\n\n- One action per message, in short plain sentences. Give the link, then what they will see.\n- Write in the language the customer writes in. Translate the message templates below; copy no\n  other sentence from this file into the chat.\n- Keep customer-facing messages focused on the action and why it is needed. Avoid narrating\n  routine internal steps; explain an actual limitation when it prevents the requested work.\n- Wait for required browser input before taking actions that depend on it. Independent repository\n  inspection can continue while the customer signs in; do not start another sign-in for the same\n  account or repeat the instruction without new information. Respect the customer\'s existing authorization and scope.\n- Never ask for a password, an email code or a token value. Never paste a credential into chat,\n  source or a command argument.\n- After they report back, verify with a command instead of trusting the report.\n\n## Step 1 — determine the state before doing anything\n\nIf the customer\'s prompt names an account ("Use my ohmyho.st account user … in organization …"),\nread "Several accounts on one computer" first. Use that login\'s `--profile-name` on authenticated\nchecks when needed. Then run these checks:\n\n```sh\nohmyhost --version\nohmyhost whoami --json\nohmyhost profile list --json\n```\n\nAlso list the MCP tools of the `ohmyho` server. A saved configuration alone is not a working connection.\n\nRead the result:\n\n| Observation                                               | State                      | Continue with    |\n| --------------------------------------------------------- | -------------------------- | ---------------- |\n| `ohmyhost` missing, or the MCP server exposes no tools    | not installed              | Step 2           |\n| `--version` is older than the published release           | outdated                   | Step 2           |\n| CLI runs, `whoami` fails with `authentication_required`   | installed, signed out      | Step 3           |\n| `whoami` fails with `credential_store_unavailable`        | no usable credential store | Step 5           |\n| `whoami` returns an identity with an organization         | ready                      | Step 5           |\n| `whoami` returns `next_action` instead of an organization | signed in, no workspace    | Step 4           |\n| `whoami` fails with `profile_selection_required`          | several saved logins       | Several accounts |\n\n`whoami` selects the workspace itself when the customer has exactly one, so an identity that\narrives with an organization needs no workspace step. Without an organization, `next_action`\nmeans the choice would be a guess or no workspace exists yet. With an organization,\n`next_action` can name `github connect`: that workspace has no GitHub connection yet, and Step 6\nhandles it.\n\nIf `OHMYHOST_TOKEN` is set in this process, that token is the credential: the CLI and MCP ignore any\nsaved login. Verify its returned identity, organization and selected platform against the task,\neven if a browser is already signed in. If `whoami` succeeds for that account, go to Step 5 without\nstarting another login. If it fails, ask the customer to update the private credential source,\nnot to paste a replacement value into chat.\nDo not send them to a sign-in link, because `ohmyhost login` refuses to run while the variable is set.\nWith a working token, `profile list` can still answer `credential_store_unavailable` on a host\nwithout a credential store; no repair is needed unless the task names a saved login.\n\nSay nothing about a state that needs nothing from the customer. A ready agent deploys without a\nsingle question. Report a state only in the message that also asks them to act, so they never\nreceive one message about the problem and a second one about the link.\n\n## Several accounts on one computer\n\nEach `ohmyhost login` saves one login: one user in one organization, kept in the operating\nsystem\'s credential store. `ohmyhost profile list --json` (MCP `profile_list`) shows each login\'s\nname, user and organization, never a token. There is no active login for the whole computer: with\none saved login every command uses it; with several, every command names one with\n`--profile-name NAME`, MCP tools take `profile_name`, and `OHMYHOST_PROFILE=NAME` binds a whole\nprocess or MCP server. A command with `--organization` (MCP `organization_id`) uses that\norganization\'s login by itself. A project command can also select it from a checkout link,\nincluding a link for its explicit `--project`; `whoami` and `project list` do not select a login\nfrom checkout links, so name one when several are saved. `ohmyhost init` uses no login and\nrefuses `--profile-name`. Another agent\'s choice never changes which account your command runs as.\n\n- When the prompt names a user and an organization, act only as the saved login with exactly that\n  user and organization, and confirm it with `whoami --profile-name NAME` before any change. These\n  IDs are context, not credentials. Never guess an account and never use another login instead.\n- If no saved login matches, add it and send its link and code as in Step 3:\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`. If the browser is\n  signed in as another account, the login saves nothing and answers `login_account_mismatch`:\n  ask the customer to switch the browser to the named account (or use a private window), then\n  repeat the login.\n- When the prompt names only a user ("it has no organization yet"), use the saved login with that\n  user and no organization, confirmed with `whoami --profile-name NAME`. If none exists, add it\n  with `ohmyhost login --user USER_ID --json`, then continue with Step 4.\n- `profile_selection_required` means several logins could run the command: ask the customer which\n  account to use. `profile_not_found` names the login to add, `profile_context_mismatch` means the\n  request contradicts its binding, organization or user, and `environment_token_context_mismatch`\n  means `OHMYHOST_TOKEN` belongs to another account.\n- A saved login never switches organizations. For another workspace, add its own login with\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`.\n  `ohmyhost logout --profile-name NAME` removes only that login.\n- `secret_set_command` takes `profile_name` like every tool and returns a command that names the\n  same login with `--profile-name` plus its user and organization (`--profile-user`,\n  `--profile-organization`); an MCP server with `OHMYHOST_TOKEN` names its key\'s user and\n  organization with `--token-user` and `--token-organization` instead. Keep those flags when you\n  run the command, so the secret is written as exactly this account. A login of that name that\n  belongs to another user or organization, for example on another computer, answers\n  `profile_context_mismatch`. The key form runs only where `OHMYHOST_TOKEN` holds a key of that\n  user and organization, never with a saved login: it answers `environment_token_required` without\n  a key and `environment_token_context_mismatch` with another account\'s key. None of these\n  refusals reads the value or sends anything.\n- Tokens stay in the operating system\'s credential store; the list of saved logins (names, users\n  and organizations, never a token) is kept in `~/.ohmyhost/profiles/`, so agents that sign in at\n  the same moment never lose each other\'s login. One environment keeps up to 64 saved logins;\n  beyond that `login` answers `profile_limit_reached` and saves nothing: ask the customer which\n  saved login to remove with `ohmyhost logout --profile-name NAME`.\n- One checkout can be linked for several organizations, one link each. With several links, name\n  the login with `--profile-name`; an older link without organization is used only after the API\n  confirms that the chosen login can see its project (`linked_project_organization_mismatch`\n  otherwise).\n- Errors that depend on the account name it in `acting_as`: `resource_not_found` with another\n  account\'s login means the wrong login, `github_connection_required` means that workspace has no\n  GitHub connection yet, and `repository_not_installed` means its GitHub App installation does not\n  cover the repository.\n\n## Step 2 — install what is missing\n\nRead <https://ohmyho.st/llms.txt> and the [CLI/MCP installation guide](https://docs.ohmyho.st/agents/mcp).\nCompare the installed versions with <https://ohmyho.st/client-release.json>: `ohmyhost --version`\nnames the CLI, and `npm ls --global --depth=0` lists both packages (`ohmyhost-mcp` has no\n`--version` flag; it starts the server). When either is missing or older, install both from the\nsource already in use: the current archive URLs from that guide, or npm\n(`npm install --global @amerged/ohmyhost-cli @amerged/ohmyhost-mcp`). Both provide the same\n`ohmyhost` and `ohmyhost-mcp` commands, so uninstall one pair before switching to the other.\nAn older client lacks commands and rejects newer server responses with `response_contract_invalid`;\nan older MCP server reports the same case as `client_request_failed` although connection and login\nwork. Upgrade both clients and reload MCP before treating either as a platform fault; if both are\ncurrent, report it with `feedback_submit`.\n\nRead [harness setup](references/harness-setup.md) and register the local `ohmyhost-mcp` command with this harness\'s documented settings. Preserve other MCP servers, model choices and permission settings. Use `OHMYHOST_ENVIRONMENT=production` for CLI and MCP unless the customer explicitly selected the development platform.\n\nEvery CLI command and MCP tool is listed in [surfaces](references/surfaces.md); use it to find the exact name of a capability a customer asks for instead of guessing or assuming it is missing.\n\nReload the MCP connection after every install or upgrade, then verify `tools/list` and `resources/list`. A running server keeps the tool list it started with, so a freshly installed version is invisible until it restarts. Repeat Step 1 afterwards.\n\n## Step 3 — the customer signs in once\n\n```sh\nohmyhost login --json\n```\n\nWhen the prompt named a user and organization, add\n`--organization ORGANIZATION_ID --user USER_ID`, so nothing is saved unless the browser signs in\nas exactly that account. Each login is saved under a name derived from its organization;\n`--profile-name NAME` chooses another (lowercase letters, digits, `-` and `_`, starting with a\nletter or digit, at most 63 characters; another name answers `invalid_command`). If that name\nalready belongs to another saved login (`profile_name_conflict`), choose a different name;\nremove the other login only when the customer asks.\n\nStart it as a background process and read its output while it runs: a sign-in link, a confirmation\ncode such as `ABCD-EFGH` and how many minutes both stay valid appear on stderr at once. The\ncommand waits up to 30 minutes for the customer and saves the login only when it ends by itself;\na harness timeout that stops it earlier saves nothing. The sign-in page shows the same code and\nasks the customer to confirm it. Send one message with the full link, code and validity, then\nwait for the customer while leaving the command running.\n\n> I found no valid ohmyho.st login for this account on this computer. Open this link to connect it:\n>\n> [full link exactly as printed]\n>\n> The page shows the code **[code]**. Continue only if it shows exactly this code.\n> Sign in there, or choose **Sign up** on that same page if you do not have an account yet.\n> Link and code are valid for [minutes] minutes; if the page rejects the code, say so and I will send a new one.\n> Tell me when you are done.\n\nRules for this step:\n\n- Always show the code. Every message that carries a sign-in link also carries its code, the first\n  time and after every repeated login. The customer checks it against the page; a code that\n  appears on the page but never in the chat gives them nothing to check.\n- Write the full link on its own line, exactly as the CLI printed it, so the customer sees the\n  address before opening it. Never hide it behind words like "this link" or "sign-in link" and\n  never shorten it; a bare address the chat makes clickable is fine. The customer types nothing.\n- State how long link and code are valid, taking the number from the CLI\'s own message rather than\n  inventing one.\n- Do not ask whether they have an account. The same page serves both, so naming both costs one\n  sentence and saves a round trip.\n- Sign-up is open. There is no invitation, no waitlist and no access code. Never send the customer\n  somewhere else to request access.\n- Wait for the customer. The command completes on its own once they finish; do not start a second\n  login while the first is still open.\n- A confirmation code lives only a few minutes. While `ohmyhost login --json` still runs, it\n  replaces a lapsed code by itself for up to 30 minutes and prints the new link and code: send\n  them the same way. Run the original login command again, keeping its account flags, only\n  after it ended with `device_authorization_expired`. This is expected, not a failure: do not\n  report an error or suggest the customer did something wrong.\n\nWhen the command returns, verify and continue:\n\n```sh\nohmyhost whoami --json\n```\n\n## Step 4 — make sure a workspace is selected\n\n`login` and `whoami` select the workspace themselves when the customer has exactly one, and their\nresponse names the selected organization. They report `next_action` with several choices, and then\nthe customer decides; with no workspace at all, create the first one. `organization use` binds a\nlogin that has no organization yet; a login that already has one keeps it (use a separate login\nfor another workspace, see "Several accounts on one computer").\n\nAlways look before creating. A verified first portal signup creates or reuses **My workspace**,\nincluding a direct signup or one with an invalid referral. The customer may also have a workspace\nfrom an earlier session:\n\n```sh\nohmyhost organization list --json\nohmyhost organization use --organization "$ORGANIZATION_ID" --json\n```\n\nCreate a workspace only when that list is empty, with a name the customer gave you:\n\n```sh\nohmyhost organization create --name "$ORGANIZATION_NAME" --source "$SIGNUP_SOURCE" --idempotency-key "$ORGANIZATION_REQUEST_KEY" --json\nohmyhost whoami --json\n```\n\n- `--source` (MCP `signup_source`) is optional attribution. If the task mentioned a campaign,\n  referral (`https://ohmyho.st/?r=ref-…`) or flag (`https://ohmyho.st/?r=flag-…`) link, pass its\n  single accepted `r` value unchanged (lowercase letters, digits, `-` and `_`, starting with a\n  letter or digit, at most 64 characters); otherwise omit it. The portal treats a malformed\n  value as Direct, so missing or invalid attribution never blocks signup and earns no referral\n  bonus. The server decides any once-per-user benefit: an eligible\n  referral or active flag on the first workspace gives 1,000 credits and 30 days of Paid, and a\n  registered campaign can add credits; promise nothing else. Attribution is never an access\n  code or secret and is fixed per user: later workspaces pass the same Signup source shown on\n  the portal\'s Profile page (omit the flag for Direct); another value answers `forbidden`.\n- Reuse the same name, source and idempotency key after an interrupted response instead of creating a second organization.\n- Creating a workspace selects it immediately for a login that had none; `whoami` or `identity_get` confirms the selection before you create a project. A login already in another workspace keeps it, and the response names the `login` that adds one for the new workspace.\n- Over MCP, `organization_create`, `organization_list` and `organization_use` do the same and report the same `selected` workspace.\n- Creating, listing and selecting a workspace need the interactive login. An API token can do none of them, and says so.\n- Never create another workspace on your own when the customer already has one.\n- A session that selected none lists no projects: `projects_list` and `ohmyhost project list` answer `organization_required` instead of an empty page. Select a workspace, then read the list again.\n\n## Step 5 — keep access for later\n\nThe current CLI login is enough to continue; MCP uses it.\n\n`ohmyhost login` saves each login in the operating system\'s credential store, and MCP reads it\nthere. `credential_store_unavailable` means the CLI cannot use that store. On a desktop, ask the\ncustomer to unlock it, then retry. In a container, CI runner or headless Linux, do not start a\nsign-in that cannot be saved: ask the customer to create a user token at\n<https://app.ohmyho.st/tokens> and load it as `OHMYHOST_TOKEN` from a private env file.\n\nFor automation, use `token_create` with `out_file`, or\n`ohmyhost token create --organization ULID --name NAME --idempotency-key KEY --out .env.local --json`.\nThe client appends `OHMYHOST_TOKEN` once to that private env file, sets mode `600` and returns\nonly metadata; the value is never shown in the client result and cannot be read again. The file\nname must start or end with `.env`, be ignored by Git or lie outside the repository\n(`token_file_not_ignored`), and not already hold `OHMYHOST_TOKEN` (`token_file_has_token`).\nConfigure the process to load it. Preserve existing credentials and never put the value in chat,\nsource or a command argument. If `token_file_changed` names an issued key that could not be saved,\nrevoke that key with `token_revoke` or the returned CLI command before creating a replacement\nwith a new idempotency key; `token_value_unavailable` means use the original file or revoke and\nreplace the key, since replay cannot reveal its value.\n\n`OHMYHOST_TOKEN` overrides the saved logins in any process where it is set. A token alone runs every\ncommand in these Skills except these, which need the interactive login: `login`, `logout` (including\n`logout --revoke`), `organization create|list|use`, and `token create|list|revoke`. Run those in a\nprocess without the variable. Never delete a saved token file. A token belongs to one account and\norganization: a command that names another (`--profile-name`, `--organization`, or a checkout\nlinked for another organization) is refused with `environment_token_context_mismatch` before\nanything is sent.\n\n## Step 6 — continue with the app\n\nConfirm the selected directory and GitHub repository. Read `github_status` for the selected workspace. If it is not connected, an Owner or Admin uses `github_connect` (CLI below), opens its single `authorization_url`, then repeats the same request/key after the browser completes until the returned status is `connected`.\n\n```sh\nohmyhost github status --organization "$ORGANIZATION_ID" --json\nohmyhost github connect --organization "$ORGANIZATION_ID" --idempotency-key "$GITHUB_CONNECT_KEY" --json\n```\n\nThe one link handles the required installation/user authorization. Do not construct a second installation link, replay OAuth callbacks, or ask for an installation ID or provider token. Use the intended GitHub browser profile. A connected installation covers only its selected repositories; if one is missing, open `connection.settings_url` from status, add the repository and repeat its original source-link request/key.\n\nMCP/REST returns these objects directly. CLI JSON wraps the handoff in `authorization` and status\nin `github`: read `authorization.authorization_url` and `github.connection.settings_url`.\nThe handoff lives 30 minutes (`expires_at`). While `pending`, a `last_failure` of\n`provider_unavailable` or `authorization_code_rejected` means reopen the returned\n`authorization_url` with the same key. `failed` or `expired` is final: `account_admin_required`\nneeds the GitHub account owner or organization admin, `installation_access_required` means the\nApp was not installed for that account, `session_inactive` needs a fresh login by a workspace\nOwner or Admin, and `denied` means the customer declined. Resolve the cause, then connect with a\nnew key for the same workspace; never poll a terminal failure.\n\nUse `projects_list` to reuse a project and `project_context_get` when resuming one. Preserve an existing project\'s region. For a new project, an explicit customer region wins; otherwise use a browser-location hint supplied in the customer\'s onboarding prompt and send that region explicitly. Without either, ask once for US or EU. Never infer customer location from the agent/server IP. The API default remains US; the selected region cannot change later.\n\nContinue with the **ohmyhost-deploy-github** Skill when a deployment is requested. Login, workspace creation, GitHub connection and project linking are distinct results; check each returned state rather than treating a completed browser page as deployment success.\n\nSupport runs through this agent. When the customer needs help, reports a bug or asks for a feature, submit a redacted report with `feedback_submit` (CLI `ohmyhost feedback submit`), give the customer the receipt ID and read replies later with `feedback_status`; the **ohmyhost-troubleshoot-deployment** Skill describes a good report. Point the customer to https://ohmyho.st/contact only when they cannot sign in, a billing issue names `contact_support`, or they ask about privacy or the DPA. The customer page is https://docs.ohmyho.st/support.\n',
+    text: '---\nname: ohmyhost-get-started\ndescription: Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through browser sign-in, and select an organization before the first GitHub deployment. Also use when one computer holds several accounts, a prompt names the user and organization to work as, the customer needs support, or an automation needs a non-expiring API token. Use the deployment Skill once access is ready.\n---\n\n# Start with ohmyho.st\n\nConnect this agent to the customer\'s account, then continue with the selected GitHub app.\n\n## What ohmyho.st is and what you can do with it\n\nohmyho.st hosts a customer\'s GitHub app: Vite/React, TanStack Start, Next.js or a plain Worker\nmodule with HTTP handlers and optional cron schedules. Their coding agent operates it through the local\nMCP server or CLI, both calling the same REST API. Deploy a pushed commit to Dev or Prod,\nverify the app, and promote a tested Dev artifact when appropriate. Dev is protected by default;\nthe deployment Skill handles public Dev, data choices and the shared-database promotion rule.\nYou can also give the app Postgres, private runtime secrets, Cloudflare R2 files, optional\ntransactional mail and a custom domain, export its database as an encrypted SQL ZIP, and read\nusage, credits and project budgets. The customer keeps their own application authentication;\nnothing here replaces it. Sign-up is open and free to start.\n\nThe initial connection normally asks the customer to sign in and authorize GitHub for the\nworkspace. A working saved login or API token can avoid another sign-in, and a connected\nworkspace can reuse its GitHub connection. Optional payments, DNS/account consent or harness\nreloads can require further customer action; use the relevant Skill for the feature they chose.\n\nThe whole path, and the proof that each step is done:\n\n| Step | Result                                                        | Proof                                                                                                                         | Section      |\n| ---- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------ |\n| 1    | You know what is installed and who is signed in               | `ohmyhost --version`, `ohmyhost whoami --json` or MCP `identity_get`, and the MCP tool list                                   | Step 1       |\n| 2    | CLI and MCP are current and registered                        | Installed versions match the published release; the harness\'s MCP `tools/list` exposes the tools after any required reload    | Step 2       |\n| 3    | The intended account is authenticated                         | `ohmyhost whoami --json` or MCP `identity_get` returns the intended user                                                      | Step 3       |\n| 4    | A workspace is selected                                       | The identity returns the intended organization                                                                                | Step 4       |\n| 5    | Access survives this session                                  | The same identity check succeeds from a fresh process with its chosen login or private token source                           | Step 5       |\n| 6    | GitHub is connected and existing projects are known           | MCP `github_status` returns `connected`; `projects_list` identifies a project to reuse                                        | Step 6       |\n| 7    | The repository is linked and the app is deployed and verified | MCP `source_get` confirms the linked repository; the deployment operation succeeds and the selected app URL passes its checks | Deploy Skill |\n\nEach step is a separate result. Confirm it using the Proof column; a completed browser page,\na saved MCP configuration or a started process does not substitute for its returned state.\n\nWhich Skill to read next:\n\n| The customer wants to …                                          | Skill                              |\n| ---------------------------------------------------------------- | ---------------------------------- |\n| prepare or adapt an app so it runs here                          | ohmyhost-build-portable-app        |\n| convert a real Supabase database, Auth, Storage or Functions use | ohmyhost-migrate-supabase-postgres |\n| deploy a commit, verify it, promote Dev to Prod                  | ohmyhost-deploy-github             |\n| understand a queued, stuck or failed deployment, or report a bug | ohmyhost-troubleshoot-deployment   |\n| read or change data, database size or Dev-to-Prod migrations     | ohmyhost-manage-database           |\n| connect a custom domain or mail sender                           | ohmyhost-domains-and-mail          |\n| export the database as an encrypted backup                       | ohmyhost-export-database           |\n| see usage, credits or set a spending limit                       | ohmyhost-usage-and-budgets         |\n\nUsers normally reach this Skill from a prompt such as "connect this agent to ohmyho.st and deploy\nthis project". In that case finish Steps 1 to 6 with as few messages as possible, then continue\nwith the deployment Skill without asking again for anything already decided.\n\n## How to talk to the customer here\n\n- One action per message, in short plain sentences. Give the link, then what they will see.\n- Write in the language the customer writes in. Translate the message templates below; copy no\n  other sentence from this file into the chat.\n- Keep customer-facing messages focused on the action and why it is needed. Avoid narrating\n  routine internal steps; explain an actual limitation when it prevents the requested work.\n- Wait for required browser input before taking actions that depend on it. Independent repository\n  inspection can continue while the customer signs in; do not start another sign-in for the same\n  account or repeat the instruction without new information. Respect the customer\'s existing authorization and scope.\n- Never ask for a password, an email code or a token value. Never paste a credential into chat,\n  source or a command argument.\n- After they report back, verify with a command instead of trusting the report.\n\n## Step 1 — determine the state before doing anything\n\nIf the customer\'s prompt names an account ("Use my ohmyho.st account user … in organization …"),\nread "Several accounts on one computer" first. Use that login\'s `--profile-name` on authenticated\nchecks when needed. Then run these checks:\n\n```sh\nohmyhost --version\nohmyhost whoami --json\nohmyhost profile list --json\n```\n\nAlso list the MCP tools of the `ohmyho` server. A saved configuration alone is not a working connection.\n\nRead the result:\n\n| Observation                                               | State                      | Continue with    |\n| --------------------------------------------------------- | -------------------------- | ---------------- |\n| `ohmyhost` missing, or the MCP server exposes no tools    | not installed              | Step 2           |\n| `--version` is older than the published release           | outdated                   | Step 2           |\n| CLI runs, `whoami` fails with `authentication_required`   | installed, signed out      | Step 3           |\n| `whoami` fails with `credential_store_unavailable`        | no usable credential store | Step 5           |\n| `whoami` returns an identity with an organization         | ready                      | Step 5           |\n| `whoami` returns `next_action` instead of an organization | signed in, no workspace    | Step 4           |\n| `whoami` fails with `profile_selection_required`          | several saved logins       | Several accounts |\n\n`whoami` selects the workspace itself when the customer has exactly one, so an identity that\narrives with an organization needs no workspace step. Without an organization, `next_action`\nmeans the choice would be a guess or no workspace exists yet. With an organization,\n`next_action` can name `github connect`: that workspace has no GitHub connection yet, and Step 6\nhandles it.\n\nIf `OHMYHOST_TOKEN` is set in this process, that token is the credential: the CLI and MCP ignore any\nsaved login. Verify its returned identity, organization and selected platform against the task,\neven if a browser is already signed in. If `whoami` succeeds for that account, go to Step 5 without\nstarting another login. If it fails, ask the customer to update the private credential source,\nnot to paste a replacement value into chat.\nDo not send them to a sign-in link, because `ohmyhost login` refuses to run while the variable is set.\nWith a working token, `profile list` can still answer `credential_store_unavailable` on a host\nwithout a credential store; no repair is needed unless the task names a saved login.\n\nSay nothing about a state that needs nothing from the customer. A ready agent deploys without a\nsingle question. Report a state only in the message that also asks them to act, so they never\nreceive one message about the problem and a second one about the link.\n\n## Several accounts on one computer\n\nEach `ohmyhost login` saves one login: one user in one organization, kept in the operating\nsystem\'s credential store. `ohmyhost profile list --json` (MCP `profile_list`) shows each login\'s\nname, user and organization, never a token. There is no active login for the whole computer: with\none saved login every command uses it; with several, every command names one with\n`--profile-name NAME`, MCP tools take `profile_name`, and `OHMYHOST_PROFILE=NAME` binds a whole\nprocess or MCP server. A command with `--organization` (MCP `organization_id`) uses that\norganization\'s login by itself. A project command can also select it from a checkout link,\nincluding a link for its explicit `--project`; `whoami` and `project list` do not select a login\nfrom checkout links, so name one when several are saved. `ohmyhost init` uses no login and\nrefuses `--profile-name`. Another agent\'s choice never changes which account your command runs as.\n\n- When the prompt names a user and an organization, act only as the saved login with exactly that\n  user and organization, and confirm it with `whoami --profile-name NAME` before any change. These\n  IDs are context, not credentials. Never guess an account and never use another login instead.\n- If no saved login matches, add it and send its link and code as in Step 3:\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`. If the browser is\n  signed in as another account, the login saves nothing and answers `login_account_mismatch`:\n  ask the customer to switch the browser to the named account (or use a private window), then\n  repeat the login.\n- When the prompt names only a user ("it has no organization yet"), use the saved login with that\n  user and no organization, confirmed with `whoami --profile-name NAME`. If none exists, add it\n  with `ohmyhost login --user USER_ID --json`, then continue with Step 4.\n- `profile_selection_required` means several logins could run the command: ask the customer which\n  account to use. `profile_not_found` names the login to add, `profile_context_mismatch` means the\n  request contradicts its binding, organization or user, and `environment_token_context_mismatch`\n  means `OHMYHOST_TOKEN` belongs to another account.\n- A saved login never switches organizations. For another workspace, add its own login with\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`.\n  `ohmyhost logout --profile-name NAME` removes only that login.\n- `secret_set_command` takes `profile_name` like every tool and returns a command that names the\n  same login with `--profile-name` plus its user and organization (`--profile-user`,\n  `--profile-organization`); an MCP server with `OHMYHOST_TOKEN` names its key\'s user and\n  organization with `--token-user` and `--token-organization` instead. Keep those flags when you\n  run the command, so the secret is written as exactly this account. A login of that name that\n  belongs to another user or organization, for example on another computer, answers\n  `profile_context_mismatch`. The key form runs only where `OHMYHOST_TOKEN` holds a key of that\n  user and organization, never with a saved login: it answers `environment_token_required` without\n  a key and `environment_token_context_mismatch` with another account\'s key. None of these\n  refusals reads the value or sends anything.\n- Tokens stay in the operating system\'s credential store; the list of saved logins (names, users\n  and organizations, never a token) is kept in `~/.ohmyhost/profiles/`, so agents that sign in at\n  the same moment never lose each other\'s login. One environment keeps up to 64 saved logins;\n  beyond that `login` answers `profile_limit_reached` and saves nothing: ask the customer which\n  saved login to remove with `ohmyhost logout --profile-name NAME`.\n- One checkout can be linked for several organizations, one link each. With several links, name\n  the login with `--profile-name`; an older link without organization is used only after the API\n  confirms that the chosen login can see its project (`linked_project_organization_mismatch`\n  otherwise).\n- Errors that depend on the account name it in `acting_as`: `resource_not_found` with another\n  account\'s login means the wrong login, `github_connection_required` means that workspace has no\n  GitHub connection yet, and `repository_not_installed` means its GitHub App installation does not\n  cover the repository.\n\n## Step 2 — install what is missing\n\nRead <https://ohmyho.st/llms.txt> and the [CLI/MCP installation guide](https://docs.ohmyho.st/agents/mcp).\nCompare the installed versions with <https://ohmyho.st/client-release.json>: `ohmyhost --version`\nnames the CLI, and `npm ls --global --depth=0` lists both packages (`ohmyhost-mcp` has no\n`--version` flag; it starts the server). When either is missing or older, install both from the\nsource already in use: the current archive URLs from that guide, or npm\n(`npm install --global @amerged/ohmyhost-cli @amerged/ohmyhost-mcp`). Both provide the same\n`ohmyhost` and `ohmyhost-mcp` commands, so uninstall one pair before switching to the other.\nAn older client lacks commands and rejects newer server responses with `response_contract_invalid`;\nan older MCP server reports the same case as `client_request_failed` although connection and login\nwork. Upgrade both clients and reload MCP before treating either as a platform fault; if both are\ncurrent, report it with `feedback_submit`.\n\nRead [harness setup](references/harness-setup.md) and register the local `ohmyhost-mcp` command with this harness\'s documented settings. Preserve other MCP servers, model choices and permission settings. Use `OHMYHOST_ENVIRONMENT=production` for CLI and MCP unless the customer explicitly selected the development platform.\n\nEvery CLI command and MCP tool is listed in [surfaces](references/surfaces.md); use it to find the exact name of a capability a customer asks for instead of guessing or assuming it is missing.\n\nReload the MCP connection after every install or upgrade, then verify `tools/list` and `resources/list`. A running server keeps the tool list it started with, so a freshly installed version is invisible until it restarts. Repeat Step 1 afterwards.\n\n## Step 3 — the customer signs in once\n\n```sh\nohmyhost login --json\n```\n\nWhen the prompt named a user and organization, add\n`--organization ORGANIZATION_ID --user USER_ID`, so nothing is saved unless the browser signs in\nas exactly that account. Each login is saved under a name derived from its organization;\n`--profile-name NAME` chooses another (lowercase letters, digits, `-` and `_`, starting with a\nletter or digit, at most 63 characters; another name answers `invalid_command`). If that name\nalready belongs to another saved login (`profile_name_conflict`), choose a different name;\nremove the other login only when the customer asks.\n\nStart it as a background process and read its output while it runs: a sign-in link, a confirmation\ncode such as `ABCD-EFGH` and how many minutes both stay valid appear on stderr at once. The\ncommand waits up to 30 minutes for the customer and saves the login only when it ends by itself;\na harness timeout that stops it earlier saves nothing. The sign-in page shows the same code and\nasks the customer to confirm it. Send one message with the full link, code and validity, then\nwait for the customer while leaving the command running.\n\n> I found no valid ohmyho.st login for this account on this computer. Open this link to connect it:\n>\n> [full link exactly as printed]\n>\n> The page shows the code **[code]**. Continue only if it shows exactly this code.\n> Sign in there, or choose **Sign up** on that same page if you do not have an account yet.\n> Link and code are valid for [minutes] minutes; if the page rejects the code, say so and I will send a new one.\n> Tell me when you are done.\n\nRules for this step:\n\n- Always show the code. Every message that carries a sign-in link also carries its code, the first\n  time and after every repeated login. The customer checks it against the page; a code that\n  appears on the page but never in the chat gives them nothing to check.\n- Write the full link on its own line, exactly as the CLI printed it, so the customer sees the\n  address before opening it. Never hide it behind words like "this link" or "sign-in link" and\n  never shorten it; a bare address the chat makes clickable is fine. The customer types nothing.\n- State how long link and code are valid, taking the number from the CLI\'s own message rather than\n  inventing one.\n- Do not ask whether they have an account. The same page serves both, so naming both costs one\n  sentence and saves a round trip.\n- Sign-up is open. There is no invitation, no waitlist and no access code. Never send the customer\n  somewhere else to request access.\n- Wait for the customer. The command completes on its own once they finish; do not start a second\n  login while the first is still open.\n- A confirmation code lives only a few minutes. While `ohmyhost login --json` still runs, it\n  replaces a lapsed code by itself for up to 30 minutes and prints the new link and code: send\n  them the same way. Run the original login command again, keeping its account flags, only\n  after it ended with `device_authorization_expired`. This is expected, not a failure: do not\n  report an error or suggest the customer did something wrong.\n\nWhen the command returns, verify and continue:\n\n```sh\nohmyhost whoami --json\n```\n\n## Step 4 — make sure a workspace is selected\n\n`login` and `whoami` select the workspace themselves when the customer has exactly one, and their\nresponse names the selected organization. They report `next_action` with several choices, and then\nthe customer decides; with no workspace at all, create the first one. `organization use` binds a\nlogin that has no organization yet; a login that already has one keeps it (use a separate login\nfor another workspace, see "Several accounts on one computer").\n\nAlways look before creating. A verified first portal signup creates or reuses **My workspace**,\nincluding a direct signup or one with an invalid referral. The customer may also have a workspace\nfrom an earlier session:\n\n```sh\nohmyhost organization list --json\nohmyhost organization use --organization "$ORGANIZATION_ID" --json\n```\n\nCreate a workspace only when that list is empty, with a name the customer gave you:\n\n```sh\nohmyhost organization create --name "$ORGANIZATION_NAME" --source "$SIGNUP_SOURCE" --idempotency-key "$ORGANIZATION_REQUEST_KEY" --json\nohmyhost whoami --json\n```\n\n- `--source` (MCP `signup_source`) is optional attribution. If the task mentioned a campaign,\n  referral (`https://ohmyho.st/?r=ref-…`) or flag (`https://ohmyho.st/?r=flag-…`) link, pass its\n  single accepted `r` value unchanged (lowercase letters, digits, `-` and `_`, starting with a\n  letter or digit, at most 64 characters); otherwise omit it. The portal treats a malformed\n  value as Direct, so missing or invalid attribution never blocks signup and earns no referral\n  bonus. The server decides any once-per-user benefit: an eligible\n  referral or active flag on the first workspace gives 1,000 credits and 30 days of Paid, and a\n  registered campaign can add credits; promise nothing else. Attribution is never an access\n  code or secret and is fixed per user: later workspaces pass the same Signup source shown on\n  the portal\'s Profile page (omit the flag for Direct); another value answers `forbidden`.\n- Reuse the same name, source and idempotency key after an interrupted response instead of creating a second organization.\n- Creating a workspace selects it immediately for a login that had none; `whoami` or `identity_get` confirms the selection before you create a project. A login already in another workspace keeps it, and the response names the `login` that adds one for the new workspace.\n- Over MCP, `organization_create`, `organization_list` and `organization_use` do the same and report the same `selected` workspace.\n- Creating, listing and selecting a workspace need the interactive login. An API token can do none of them, and says so.\n- Never create another workspace on your own when the customer already has one.\n- A session that selected none lists no projects: `projects_list` and `ohmyhost project list` answer `organization_required` instead of an empty page. Select a workspace, then read the list again.\n\n## Step 5 — keep access for later\n\nThe current CLI login is enough to continue; MCP uses it.\n\n`ohmyhost login` saves each login in the operating system\'s credential store, and MCP reads it\nthere. `credential_store_unavailable` means the CLI cannot use that store. On a desktop, ask the\ncustomer to unlock it, then retry. In a container, CI runner or headless Linux, do not start a\nsign-in that cannot be saved: ask the customer to create a user token at\n<https://app.ohmyho.st/tokens> and load it as `OHMYHOST_TOKEN` from a private env file.\n\nFor automation, use `token_create` with `out_file`, or\n`ohmyhost token create --organization ULID --name NAME --idempotency-key KEY --out .env.local --json`.\nThe client appends `OHMYHOST_TOKEN` once to that private env file, sets mode `600` and returns\nonly metadata; the value is never shown in the client result and cannot be read again. The file\nname must start or end with `.env`, be ignored by Git or lie outside the repository\n(`token_file_not_ignored`), and not already hold `OHMYHOST_TOKEN` (`token_file_has_token`).\nConfigure the process to load it. Preserve existing credentials and never put the value in chat,\nsource or a command argument. If `token_file_changed` names an issued key that could not be saved,\nrevoke that key with `token_revoke` or the returned CLI command before creating a replacement\nwith a new idempotency key; `token_value_unavailable` means use the original file or revoke and\nreplace the key, since replay cannot reveal its value.\n\n`OHMYHOST_TOKEN` overrides the saved logins in any process where it is set. A token alone runs every\ncommand in these Skills except these, which need the interactive login: `login`, `logout` (including\n`logout --revoke`), `organization create|list|use`, and `token create|list|revoke`. Run those in a\nprocess without the variable. Never delete a saved token file. A token belongs to one account and\norganization: a command that names another (`--profile-name`, `--organization`, or a checkout\nlinked for another organization) is refused with `environment_token_context_mismatch` before\nanything is sent.\n\n## Step 6 — continue with the app\n\nConfirm the selected directory and GitHub repository. Read `github_status` for the selected workspace. If it is not connected, an Owner or Admin uses `github_connect` (CLI below), opens its single `authorization_url`, then repeats the same request/key after the browser completes until the returned status is `connected`.\n\n```sh\nohmyhost github status --organization "$ORGANIZATION_ID" --json\nohmyhost github connect --organization "$ORGANIZATION_ID" --idempotency-key "$GITHUB_CONNECT_KEY" --json\n```\n\nThe one link handles the required installation/user authorization. Do not construct a second installation link, replay OAuth callbacks, or ask for an installation ID or provider token. Use the intended GitHub browser profile. A connected installation covers only its selected repositories; if one is missing, open `connection.settings_url` from status, add the repository and repeat its original source-link request/key.\n\nMCP/REST returns these objects directly. CLI JSON wraps the handoff in `authorization` and status\nin `github`: read `authorization.authorization_url` and `github.connection.settings_url`.\nThe handoff lives 30 minutes (`expires_at`). While `pending`, a `last_failure` of\n`provider_unavailable` or `authorization_code_rejected` means reopen the returned\n`authorization_url` with the same key. `failed` or `expired` is final: `account_admin_required`\nneeds the GitHub account owner or organization admin, `installation_access_required` means the\nApp was not installed for that account, `session_inactive` needs a fresh login by a workspace\nOwner or Admin, and `denied` means the customer declined. Resolve the cause, then connect with a\nnew key for the same workspace; never poll a terminal failure.\n\nUse `projects_list` to reuse a project and `project_context_get` when resuming one. Preserve an existing project\'s region. For a new project, an explicit customer region wins; otherwise use a browser-location hint supplied in the customer\'s onboarding prompt and send that region explicitly. Without either, ask once for US or EU. Never infer customer location from the agent/server IP. The API default remains US; the selected region cannot change later.\n\nContinue with the **ohmyhost-deploy-github** Skill when a deployment is requested. Login, workspace creation, GitHub connection and project linking are distinct results; check each returned state rather than treating a completed browser page as deployment success.\n\nSupport runs through this agent. When the customer needs help, reports a bug or asks for a feature, submit a redacted report with `feedback_submit` (CLI `ohmyhost feedback submit`), give the customer the receipt ID and read replies later with `feedback_status`; the **ohmyhost-troubleshoot-deployment** Skill describes a good report. Point the customer to https://ohmyho.st/contact only when they cannot sign in, a billing issue names `contact_support`, or they ask about privacy or the DPA. The customer page is https://docs.ohmyho.st/support.\n',
   },
   {
     skillName: "ohmyhost-get-started",
@@ -122,7 +122,7 @@ export const GENERATED_SKILL_RESOURCES = Object.freeze([
     description:
       "Migrate customer-selected Supabase capabilities in a TypeScript application to portable PostgreSQL and the ohmyho.st runtime. Use when real Supabase database, Auth, Storage, Functions or Realtime usage needs conversion; not merely because an SDK is installed.",
     mimeType: "text/markdown",
-    text: "---\nname: ohmyhost-migrate-supabase-postgres\ndescription: Migrate customer-selected Supabase capabilities in a TypeScript application to portable PostgreSQL and the ohmyho.st runtime. Use when real Supabase database, Auth, Storage, Functions or Realtime usage needs conversion; not merely because an SDK is installed.\n---\n\n# Migrate a Supabase application\n\nKeep the application working while converting only the capabilities the customer selected.\n\n## Inspect and choose\n\nRun `ohmyhost init --dry-run --json` in the chosen repository. Inventory actual database queries, RPCs, migrations, RLS assumptions, Auth sessions, Storage calls, Edge Functions and Realtime subscriptions. Distinguish used services from unused dependencies and preserve a valid hosting configuration.\n\nExplain what can remain external, what needs application changes, and any unsupported runtime capability. Do not replace the customer's auth provider or discard data without their decision. A database dump does not migrate every Supabase service.\n\nRead [provider contracts](references/provider-contracts.md) only for the affected capabilities. The [portable baseline helper](scripts/create-portable-baseline.mjs) can prepare a reviewed migration baseline; inspect its documented input/output and the selected migration files before running it. It does not grant database authority or prove that application data has moved.\n\n## Convert the selected capabilities\n\n- Replace selected Supabase-specific database calls with typed SQL or narrow repositories through `createPrivateDatabaseClient` and `OHMYHOST_DATABASE`. Use `transaction()` for predefined statements and bounded `withConnection()` for read-decide-write; see [database runtime](../ohmyhost-build-portable-app/references/database-runtime.md). Preserve transaction boundaries, constraints and tenant filtering.\n- Review SQL functions and RLS-dependent assumptions explicitly. Keep immutable migrations in `YYYYMMDDHHMMSS_name.sql` format and follow [expand-only admission](../ohmyhost-manage-database/SKILL.md). Row changes, DROP, CREATE OR REPLACE, roles/grants and changes to existing constraints are refused. Do not convert RLS/JWT helpers into browser-controlled authority or add a Clerk/RLS integration as an incidental migration.\n- Preserve or integrate the customer-chosen application auth. Configure its callback URLs and private server secrets. Test login, protected access, session refresh/reload and logout; hosting login is separate.\n- Convert selected Storage, Functions and Realtime behavior only when the current runtime contract supports the equivalent application behavior. If it does not, state the gap and agree on the feature decision instead of inserting a fake success or silent fallback.\n- Selected Edge Functions become authenticated framework-native server routes or plain Worker handlers. Declare schedules through `functions.crons`; the platform owns cron delivery/retries, rather than customer Queue/Workflow bindings. Existing external functions may stay when the customer chooses them and their declared interfaces are verified.\n- Optional managed Better Auth uses explicit `auth.provider: better-auth`, database and `mail.enabled: true`: its managed bridge always sends verification/reset mail through the private mail capability and needs Paid/verified sender. Missing mail fails early as `managed_auth_mail_required`. To retain application-owned Better Auth or external sending, use `auth.provider: none`; SDK dependency detection alone selects no managed capability. Preserve external auth-provider mail when the customer chooses it.\n- Keep application runtime secrets separate from repository/build inputs. Use `secret_set_command` and the intended environment ID for private values.\n\n## Verify and deploy\n\nRun relevant application tests and the real framework build, then rerun `init` until the selected conversion requirements are resolved. Use **ohmyhost-build-portable-app** for the resulting runtime and **ohmyhost-deploy-github** for publication.\n\nCheck real login, data reads/writes, constraints and any required files, email or functions on the hosted Dev app. Promote only within the customer's request, preserving Prod records. Rollback or deletion tests belong only to separately requested or explicitly disposable test resources.\n\nFor an unsupported operation or suspected platform bug, use `feedback_submit` with a minimal redacted reproduction and the safe operation/error ID. Keep the unresolved capability visible; do not claim the migration complete until the requested application behavior works.\n",
+    text: "---\nname: ohmyhost-migrate-supabase-postgres\ndescription: Migrate customer-selected Supabase capabilities in a TypeScript application to portable PostgreSQL and the ohmyho.st runtime. Use when real Supabase database, Auth, Storage, Functions or Realtime usage needs conversion; not merely because an SDK is installed.\n---\n\n# Migrate a Supabase application\n\nKeep the application working while converting only the capabilities the customer selected.\n\n## Inspect and choose\n\nRun `ohmyhost init --dry-run --json` in the chosen repository. Inventory actual database queries, RPCs, migrations, RLS assumptions, Auth sessions, Storage calls, Edge Functions and Realtime subscriptions. Distinguish used services from unused dependencies and preserve a valid hosting configuration.\n\nExplain what can remain external, what needs application changes, and any unsupported runtime capability. Do not replace the customer's auth provider or discard data without their decision. A database dump does not migrate every Supabase service.\n\nRead [provider contracts](references/provider-contracts.md) only for the affected capabilities. The [portable baseline helper](scripts/create-portable-baseline.mjs) can prepare a reviewed migration baseline; inspect its documented input/output and the selected migration files before running it. It does not grant database authority or prove that application data has moved.\n\n## Convert the selected capabilities\n\n- Replace selected Supabase-specific database calls with typed SQL or narrow repositories through `createPrivateDatabaseClient` and `OHMYHOST_DATABASE`. Use `transaction()` for predefined statements and bounded `withConnection()` for read-decide-write; see [database runtime](../ohmyhost-build-portable-app/references/database-runtime.md). Preserve transaction boundaries, constraints and tenant filtering.\n- Review SQL functions and RLS-dependent assumptions explicitly. Keep immutable migrations in `YYYYMMDDHHMMSS_name.sql` format and follow [expand-only admission](../ohmyhost-manage-database/SKILL.md). Row changes, DROP, CREATE OR REPLACE, roles/grants and changes to existing constraints are refused. Do not convert RLS/JWT helpers into browser-controlled authority or add a Clerk/RLS integration as an incidental migration.\n- Preserve or integrate the customer-chosen application auth. Configure its callback URLs and private server secrets. Test login, protected access, session refresh/reload and logout; hosting login is separate.\n- Convert selected Storage, Functions and Realtime behavior only when the current runtime contract supports the equivalent application behavior. If it does not, state the gap and agree on the feature decision instead of inserting a fake success or silent fallback.\n- Selected Edge Functions become authenticated framework-native server routes or plain Worker handlers. Declare schedules through `functions.crons`; the platform owns cron delivery/retries, rather than customer Queue/Workflow bindings. Existing external functions may stay when the customer chooses them and their declared interfaces are verified.\n- Optional managed Better Auth uses explicit `auth.provider: better-auth` and its database. Managed mail is optional for verified-user/session/token flows; the bridge's verification/reset sends use its platform sender and need `mail.enabled: true`, Paid access and a verified sender. Keep a custom Resend callback in an application-owned Better Auth handler with `auth.provider: none`; this disables only the managed bridge, not Better Auth or login. SDK dependency detection selects no managed capability. CLI 0.1.24 may incorrectly return `managed_auth_mail_required`; use the corrective 0.1.25 release or later and preserve the selected auth and sender.\n- Keep application runtime secrets separate from repository/build inputs. Use `secret_set_command` and the intended environment ID for private values.\n\n## Verify and deploy\n\nRun relevant application tests and the real framework build, then rerun `init` until the selected conversion requirements are resolved. Use **ohmyhost-build-portable-app** for the resulting runtime and **ohmyhost-deploy-github** for publication.\n\nCheck real login, data reads/writes, constraints and any required files, email or functions on the hosted Dev app. Promote only within the customer's request, preserving Prod records. Rollback or deletion tests belong only to separately requested or explicitly disposable test resources.\n\nFor an unsupported operation or suspected platform bug, use `feedback_submit` with a minimal redacted reproduction and the safe operation/error ID. Keep the unresolved capability visible; do not claim the migration complete until the requested application behavior works.\n",
   },
   {
     skillName: "ohmyhost-migrate-supabase-postgres",
@@ -131,7 +131,7 @@ export const GENERATED_SKILL_RESOURCES = Object.freeze([
     title: "ohmyhost-migrate-supabase-postgres: references/provider-contracts.md",
     description: "Supporting resource for ohmyhost-migrate-supabase-postgres.",
     mimeType: "text/markdown",
-    text: "# Supabase conversion contracts\n\nUse this reference when a detected Supabase capability needs a replacement. Keep each capability independently testable; a PostgreSQL import does not convert Auth, Functions, Storage, Realtime, or mail.\n\n## Portable target\n\n- The repository pins exactly one `npm`, `pnpm`, `yarn`, or `bun` version and commits exactly one matching frozen lockfile.\n- Vite, TanStack Start, and Next.js remain framework-native. The service-owned build overlay pins OpenNext `1.20.6` and Wrangler `4.125.0`; customer source never commits those dependencies, generated configuration, `OHMYHOST_BASE_PATH`, or provider bindings.\n- Preserve the compatibility result from init: `verified` is exact-fixture-proven, `experimental` is admitted with the same artifact validation, and `unsupported` stops.\n\n## Database and Auth\n\n- Replace selected Supabase database/PostgREST calls and browser SQL with authenticated server use cases backed by `OHMYHOST_DATABASE`. A deliberately retained Supabase browser integration needs its exact origins in `runtime.browser`; server routes use `runtime.egress.allow` instead. Verify the real exported app's auth/data flows before claiming it works. Remove `@supabase/supabase-js` only when no deliberately retained customer-owned Supabase Auth or other approved capability still needs it. Retained external auth must be independently verified; SDK package evidence alone neither selects a managed database nor blocks hosting.\n- The regional database service and Neon management are platform-private. Customer code receives only the scoped `OHMYHOST_DATABASE` binding, never a database URL or migration credentials.\n- Convert RPCs to explicit transactions or reviewed PostgreSQL functions with fixed `search_path`, explicit authorization, idempotency, and concurrency tests.\n- Canonical migrations are expand-only `YYYYMMDDHHMMSS_name.sql` files. A reviewed PostgreSQL schema-only dump may include `public` and app-owned `private`, never Supabase `auth` or `storage`.\n- If the customer selects `auth.provider: better-auth`, the managed bridge owns the new `auth` schema, UUID identities, verification/reset mail, host-only cookies, session revocation and database sessions. It requires both managed database and mail, including Paid access/verified sender; missing mail fails early as `managed_auth_mail_required`. Application-owned Better Auth remains a separate ordinary dependency with `auth.provider: none` and its chosen sender. Never recreate browser-controlled JWT GUCs or Supabase roles.\n\nFirst-party references: [Supabase migration scope](https://supabase.com/docs/guides/platform/migrating-to-supabase/postgres), [PostgreSQL pg_dump](https://www.postgresql.org/docs/current/app-pgdump.html), and [Better Auth PostgreSQL](https://better-auth.com/docs/adapters/postgresql). Hosted database code follows [the private runtime contract](../../ohmyhost-build-portable-app/references/database-runtime.md).\n\n## Functions, files, Realtime, and mail\n\n- Move bounded request-local Edge Functions into authenticated same-origin Vite companion handlers, TanStack Start server routes, or Next.js route handlers. Plain Worker functions use `runtime.mode: functions` and `src/ohmyhost/worker.ts` with a default `fetch` and optional default `scheduled(controller, env, ctx)`. Declare `functions.crons` in `ohmyhost.yaml` and verify runs through `function_runs_list`; the platform owns scheduled delivery/retries, without customer Queue/Workflow bindings.\n- Replace Supabase Storage calls with `@ohmyhost/customer-runtime/storage`. The Storage Gateway owns raw R2, signed access, quotas, receipts, and provider cleanup.\n- Realtime is a typed unsupported blocker until a product contract exists. Do not simulate success or replace it with polling without an explicit product decision.\n- Replace application mail selected for ohmyho.st with `createTransactionalMailClient`; set `mail.enabled: true`, configure/verify the customer's Paid sender and let the platform install its environment-specific mail key. Never call customer secret-set for reserved `OHMYHOST_MAIL_KEY`. Receiving uses a signed application webhook whose returned signing secret is installed under an application-owned name such as `APP_MAIL_WEBHOOK_SECRET`. Preserve verification/reset mail handled by the customer's explicitly retained external auth provider.\n\n## Baseline helper\n\nOnly after the customer chooses Better Auth and its server authorization/boundaries are implemented and reviewed, run:\n\n```text\nscripts/create-portable-baseline.mjs --input <dump> --output-directory <migrations> --migration-prefix <YYYYMMDDHHMMSS_slug> --auth-mode better-auth-uuid --authorization-mode server\n```\n\nThe helper converts only `auth.users` and `auth.uid()`, replaces the service-request helper, reports omitted RLS policies, retains admitted app-private functions, and splits output under platform limits. Nonzero conversion/omission counts require review; they are never automatic approval.\n\n## Completion\n\nDelete only the superseded Supabase database clients/configuration, roles, grants, RLS/JWT helpers, Functions and Storage calls after replacement tests pass. Preserve any explicitly retained external authentication integration; do not treat a database move as an auth migration. Then rerun init and verify the actual service-owned build, managed database and required public behavior. Rollback, repeated deletion and provider absence tests require the customer's separate authorization or disposable acceptance resources; do not delete the migrated application after an ordinary deployment. A root HTTP `200` is not completion.\n",
+    text: "# Supabase conversion contracts\n\nUse this reference when a detected Supabase capability needs a replacement. Keep each capability independently testable; a PostgreSQL import does not convert Auth, Functions, Storage, Realtime, or mail.\n\n## Portable target\n\n- The repository pins exactly one `npm`, `pnpm`, `yarn`, or `bun` version and commits exactly one matching frozen lockfile.\n- Vite, TanStack Start, and Next.js remain framework-native. The service-owned build overlay pins OpenNext `1.20.6` and Wrangler `4.125.0`; customer source never commits those dependencies, generated configuration, `OHMYHOST_BASE_PATH`, or provider bindings.\n- Preserve the compatibility result from init: `verified` is exact-fixture-proven, `experimental` is admitted with the same artifact validation, and `unsupported` stops.\n\n## Database and Auth\n\n- Replace selected Supabase database/PostgREST calls and browser SQL with authenticated server use cases backed by `OHMYHOST_DATABASE`. A deliberately retained Supabase browser integration needs its exact origins in `runtime.browser`; server routes use `runtime.egress.allow` instead. Verify the real exported app's auth/data flows before claiming it works. Remove `@supabase/supabase-js` only when no deliberately retained customer-owned Supabase Auth or other approved capability still needs it. Retained external auth must be independently verified; SDK package evidence alone neither selects a managed database nor blocks hosting.\n- The regional database service and Neon management are platform-private. Customer code receives only the scoped `OHMYHOST_DATABASE` binding, never a database URL or migration credentials.\n- Convert RPCs to explicit transactions or reviewed PostgreSQL functions with fixed `search_path`, explicit authorization, idempotency, and concurrency tests.\n- Canonical migrations are expand-only `YYYYMMDDHHMMSS_name.sql` files. A reviewed PostgreSQL schema-only dump may include `public` and app-owned `private`, never Supabase `auth` or `storage`.\n- If the customer selects `auth.provider: better-auth`, the managed bridge owns the new `auth` schema, UUID identities, verification/reset callbacks, host-only cookies, session revocation and database sessions. It requires its managed database; verified-user/session/token flows need no mail sender. The private bridge's verification/reset sends use the platform sender and require `mail.enabled: true`, Paid access and a verified sender when invoked. Preserve a custom Resend callback in an application-owned Better Auth handler with `auth.provider: none`; this disables only the managed bridge and keeps application login. Never recreate browser-controlled JWT GUCs or Supabase roles.\n\nFirst-party references: [Supabase migration scope](https://supabase.com/docs/guides/platform/migrating-to-supabase/postgres), [PostgreSQL pg_dump](https://www.postgresql.org/docs/current/app-pgdump.html), and [Better Auth PostgreSQL](https://better-auth.com/docs/adapters/postgresql). Hosted database code follows [the private runtime contract](../../ohmyhost-build-portable-app/references/database-runtime.md).\n\n## Functions, files, Realtime, and mail\n\n- Move bounded request-local Edge Functions into authenticated same-origin Vite companion handlers, TanStack Start server routes, or Next.js route handlers. Plain Worker functions use `runtime.mode: functions` and `src/ohmyhost/worker.ts` with a default `fetch` and optional default `scheduled(controller, env, ctx)`. Declare `functions.crons` in `ohmyhost.yaml` and verify runs through `function_runs_list`; the platform owns scheduled delivery/retries, without customer Queue/Workflow bindings.\n- Replace Supabase Storage calls with `@ohmyhost/customer-runtime/storage`. The Storage Gateway owns raw R2, signed access, quotas, receipts, and provider cleanup.\n- Realtime is a typed unsupported blocker until a product contract exists. Do not simulate success or replace it with polling without an explicit product decision.\n- Replace application mail selected for ohmyho.st with `createTransactionalMailClient`; set `mail.enabled: true`, configure/verify the customer's Paid sender and let the platform install its environment-specific mail key. Never call customer secret-set for reserved `OHMYHOST_MAIL_KEY`. Receiving uses a signed application webhook whose returned signing secret is installed under an application-owned name such as `APP_MAIL_WEBHOOK_SECRET`. Preserve verification/reset mail handled by the customer's explicitly retained external auth provider.\n\n## Baseline helper\n\nOnly after the customer chooses Better Auth and its server authorization/boundaries are implemented and reviewed, run:\n\n```text\nscripts/create-portable-baseline.mjs --input <dump> --output-directory <migrations> --migration-prefix <YYYYMMDDHHMMSS_slug> --auth-mode better-auth-uuid --authorization-mode server\n```\n\nThe helper converts only `auth.users` and `auth.uid()`, replaces the service-request helper, reports omitted RLS policies, retains admitted app-private functions, and splits output under platform limits. Nonzero conversion/omission counts require review; they are never automatic approval.\n\n## Completion\n\nDelete only the superseded Supabase database clients/configuration, roles, grants, RLS/JWT helpers, Functions and Storage calls after replacement tests pass. Preserve any explicitly retained external authentication integration; do not treat a database move as an auth migration. Then rerun init and verify the actual service-owned build, managed database and required public behavior. Rollback, repeated deletion and provider absence tests require the customer's separate authorization or disposable acceptance resources; do not delete the migrated application after an ordinary deployment. A root HTTP `200` is not completion.\n",
   },
   {
     skillName: "ohmyhost-migrate-supabase-postgres",

package/src/packages/contracts/src/customer-auth-admission.ts

@@ -4,19 +4,15 @@ export interface ManagedCustomerAuthCapabilities {
   readonly mail?: Readonly<{ enabled: boolean }>;
 }
 
-export function managedCustomerAuthMailMessage(path: string): string {
-  return `"${path}" selects the managed Better Auth bridge, which sends verification and password-reset email through ohmyhost Mail. Set mail.enabled: true and set up a verified mail sender, or set auth.provider: none and keep the application-owned Better Auth configuration and sender. Commit and push the change, then plan the new commit.`;
-}
-
 export function managedCustomerAuthDatabaseMessage(path: string): string {
   return `"${path}" selects the managed Better Auth bridge, which requires the managed PostgreSQL database. Set database.enabled: true with an admitted migrations path, or set auth.provider: none and keep the application-owned authentication configuration. Commit and push the change, then plan the new commit.`;
 }
 
-/** Dependency inventory never selects the managed bridge; only the explicit auth capability does. */
+/** Managed auth needs its real database; Mail remains an independent optional capability. */
 export function managedCustomerAuthAdmissionIssue(
   capabilities: ManagedCustomerAuthCapabilities | null | undefined,
 ): Readonly<{
-  code: "managed_auth_database_required" | "managed_auth_mail_required";
+  code: "managed_auth_database_required";
   message: string;
 }> | null {
   if (capabilities?.auth?.provider !== "better-auth") {
@@ -28,9 +24,5 @@ export function managedCustomerAuthAdmissionIssue(
       message: managedCustomerAuthDatabaseMessage("ohmyhost.yaml"),
     });
   }
-  if (capabilities.mail?.enabled === true) return null;
-  return Object.freeze({
-    code: "managed_auth_mail_required" as const,
-    message: managedCustomerAuthMailMessage("ohmyhost.yaml"),
-  });
+  return null;
 }

package/src/packages/contracts/src/framework-admission.ts

@@ -1,12 +1,6 @@
 import { PINNED_BUN_VERSION } from "./framework-build-script.mjs";
-import {
-  managedCustomerAuthMailMessage,
-  managedCustomerAuthDatabaseMessage,
-} from "./customer-auth-admission.js";
-export {
-  managedCustomerAuthAdmissionIssue,
-  managedCustomerAuthMailMessage,
-} from "./customer-auth-admission.js";
+import { managedCustomerAuthDatabaseMessage } from "./customer-auth-admission.js";
+export { managedCustomerAuthAdmissionIssue } from "./customer-auth-admission.js";
 
 export type PackageManagerName = "bun" | "npm" | "pnpm" | "yarn";
 
@@ -202,7 +196,6 @@ function versionAdmission(
 
 export type FrameworkConversionDiagnosticCode =
   | "managed_auth_database_required"
-  | "managed_auth_mail_required"
   | "database_binding_private"
   | "database_driver_unsupported"
   | "source_syntax_invalid"
@@ -233,11 +226,6 @@ const FRAMEWORK_CONVERSION_DETAILS: Readonly<
     pattern:
       /^"([^"]+)" selects the managed Better Auth bridge, which requires the managed PostgreSQL database\. Set database\.enabled: true with an admitted migrations path, or set auth\.provider: none and keep the application-owned authentication configuration\. Commit and push the change, then plan the new commit\.$/u,
   }),
-  managed_auth_mail_required: Object.freeze({
-    render: managedCustomerAuthMailMessage,
-    pattern:
-      /^"([^"]+)" selects the managed Better Auth bridge, which sends verification and password-reset email through ohmyhost Mail\. Set mail\.enabled: true and set up a verified mail sender, or set auth\.provider: none and keep the application-owned Better Auth configuration and sender\. Commit and push the change, then plan the new commit\.$/u,
-  }),
   database_binding_private: Object.freeze({
     render: (path: string) =>
       `"${path}" reads a database connection string (DATABASE_URL, HYPERDRIVE, connectionString or a postgres:// URL); none reaches a customer Worker. Call the database with createPrivateDatabaseClient from "@ohmyhost/customer-runtime/database". ${PUSH_AND_PLAN}`,
@@ -329,7 +317,7 @@ export function parseFrameworkConversionDiagnostic(
     !isFrameworkConversionDiagnosticCode(code) ||
     typeof path !== "string" ||
     path.length > 240 ||
-    (code === "managed_auth_mail_required" || code === "managed_auth_database_required"
+    (code === "managed_auth_database_required"
       ? path !== "ohmyhost.yaml"
       : !/^[A-Za-z0-9_@()[\]./-]+\.(?:[cm]?[jt]sx?)$/u.test(path)) ||
     path.split("/").some((segment) => segment === "" || segment === "." || segment === "..")

package/src/packages/sdk-ts/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ohmyhost/sdk-ts",
-  "version": "0.1.24",
+  "version": "0.1.25",
   "private": true,
   "type": "module",
   "exports": {

package/src/packages/sdk-ts/src/generated/sdk.gen.ts

@@ -2749,7 +2749,7 @@ export const applyPaidProjectDomain = <ThrowOnError extends boolean = true>(
 /**
  * Plan a deployment
  *
- * Resolves immutable inputs and estimates effects without provider mutation or billable work. The plan targets Dev unless `environment` is `prod`; a Prod plan builds straight into Prod, except that a project with shared data and a database only reaches Prod through promotion. Mail and the currently supported mail-backed Better Auth contract require a confirmed Paid service period; it is checked again before build reservation. An old sender configuration is not Paid authority.
+ * Resolves immutable inputs and estimates effects without provider mutation or billable work. The plan targets Dev unless `environment` is `prod`; a Prod plan builds straight into Prod, except that a project with shared data and a database only reaches Prod through promotion. Managed mail requires a confirmed Paid service period; it is checked again before build reservation. Selecting the managed Better Auth bridge does not require managed mail or Paid access. An old sender configuration is not Paid authority.
  */
 export const planDeployment = <ThrowOnError extends boolean = true>(
   parameters: {