Update to ohmyho.st

{
  "description": "Develop, version, preview and publish an application with ohmyho.st from a local checkout or a connected native chat. Reuse the saved project and source, select managed source or GitHub only when needed, and switch an existing project only on request. Use troubleshooting for a stuck deployment.",
  "included_files": [],
  "name": "ohmyhost-deploy",
  "skill_md_contents": "---\nname: ohmyhost-deploy\ndescription: Develop, version, preview and publish an application with ohmyho.st from a local checkout or a connected native chat. Reuse the saved project and source, select managed source or GitHub only when needed, and switch an existing project only on request. Use troubleshooting for a stuck deployment.\n---\n\n# Develop and deploy an app\n\nRead available MCP tool schemas or installed CLI help. Complete access with\n**ohmyhost-get-started**, preserving the user's selected account, organization and project.\nKeep explanations in the user's language; users need app versions, a preview and a working\naddress, not the storage provider's implementation details.\n\n## Select the source once\n\nThe saved project binding and `source_get` determine how to continue an existing application.\nReuse them before interpreting local Git remotes. Never silently replace a source because the\nagent changed, a checkout was cloned, or a GitHub remote is missing on this computer.\nFor generation-aware inspection, initialization, commits or a source switch, request\n`source_get` with `include_binding: true`. Its default preserves the existing GitHub view;\nthe opt-in returns the exact source connection and generation. Managed source already includes\nthose guards in either view. `ohmyhost source status` opts in for the local source workflow.\n\n| Situation                                                           | Continue with                                                |\n| ------------------------------------------------------------------- | ------------------------------------------------------------ |\n| Existing managed binding                                            | Managed source on that project                               |\n| Existing GitHub binding                                             | **ohmyhost-deploy-github**                                   |\n| Explicit request to use GitHub                                      | **ohmyhost-deploy-github**, including GitHub setup if needed |\n| Explicit request to store/deploy directly with ohmyho.st            | Managed source                                               |\n| New application developed entirely in native chat                   | Managed source                                               |\n| Unbound local checkout with a selected GitHub remote                | **ohmyhost-deploy-github**                                   |\n| Unbound local checkout without GitHub and no explicit source choice | Ask once: \"Keep versions with ohmyho.st, or set up GitHub?\"  |\n\nA local `.git` directory may belong to a non-GitHub host or have no remote. A copied GitHub\nremote alone does not override the saved project binding. If the existing source conflicts\nwith an explicit new choice, use the source-switch flow after its concrete effects are reviewed.\nThe direct managed route requires neither GitHub signup nor a copied platform/device token.\n\n## Local managed checkout\n\nRun the installed source/deploy help and inspect the repository with `ohmyhost init --dry-run\n--json`. Resolve real framework/configuration blockers through **ohmyhost-build-portable-app**;\npreserve the app's authentication, migrations, selected application root and region. A supported\napp needs its actual `ohmyhost.yaml` and lockfile, not a generated pretend-success result.\n\nUse `ohmyhost source inspect --directory PATH --json` for read-only evidence, then\n`ohmyhost source publish` to bind or continue the selected project. Inspect its installed help\nbefore choosing `--mode initialize`, `commit` or the explicitly requested `switch`, and supply\nthe saved `--expected-source-generation` and source connection when that mode requires them,\nwith a concise `--message` and one saved `--idempotency-key`. For an existing managed checkout,\nomit `--expected-commit` to use its own `last_confirmed_commit_sha` as the optimistic base.\nSupply an explicit newer SHA only after reading and merging the other chat's changes into these\nlocal files; never attach a newly fetched remote head to an unchanged stale checkout. It stages the filtered\napplication manifest, uploads the changed blobs and commits\nthe completed tree. Preserve executable bits. Exclude credentials, `.env` files, local caches,\ndependency directories and build outputs. Do not require `git push` to GitHub for this route.\nSave the returned project/source binding; the accepted server commit identifies the version\nto plan and deploy. An upload is not itself a successful build or publication.\n\nIf publication is pending, poll its saved `operation_get` and then run\n`ohmyhost source publish complete --project ULID --directory PATH --operation ULID --json`\nunder the same login. This confirms the persisted version and finishes the local binding.\nResume a pending upload from `source inspect`'s `pending_publications`; preserve its operation\nand key. Completing an already authorized publication needs no second routing question.\n\n| Local task                               | Installed command                                                                                                 |\n| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |\n| Read the persisted source                | `ohmyhost source status --project ULID --json`                                                                    |\n| List or read a version's files           | `ohmyhost source files` / `ohmyhost source file --path PATH`, with `--project ULID` and optional `--commit SHA`   |\n| Inspect history or a diff                | `ohmyhost source versions` / `ohmyhost source diff --from SHA --to SHA`, scoped to the same project               |\n| Observe a saved upload                   | `ohmyhost source upload --project ULID --operation ULID --json`                                                   |\n| Finish an accepted local publication     | `ohmyhost source publish complete --project ULID --directory PATH --operation ULID --json`                        |\n| Initialize an explicitly chosen template | `ohmyhost source initialize`, with the project, template, current source generation and saved key                 |\n| Restore files as a new version           | `ohmyhost source restore`, with the current source generation/head, `--restore-commit SHA`, message and saved key |\n\nUse the returned exact schemas and [the generated surface reference](../ohmyhost-get-started/references/surfaces.md)\nfor flags. Restoring files is separate from publication and does not import local Git history.\nLocal MCP exposes the corresponding `source_inspect`, `source_publish`, `source_publish_complete`, `source_upload`,\n`source_initialize`, `source_files`, `source_file`, `source_versions`, `source_diff`,\n`source_changes` and `source_restore` tools. `source_inspect` and `source_publish` operate on\nthis computer's checkout; never use their local paths as native-chat source files. Local\n`source_publish` can use the cached optimistic base when `expected_commit_sha` is omitted;\n`source_publish_complete` finishes pending work using the same project, directory and profile.\nLocal MCP `source_file` reads default to `format: \"text\"`: valid UTF-8 returns `content_text`\nwith `encoding: \"utf8\"`; a file that cannot be decoded returns base64. Choose `format: \"base64\"`\nfor exact binary contents. The REST/SDK wire format remains base64.\n\n## Managed application in native chat\n\nThis workflow needs the authenticated remote tools; it has no local filesystem or shell\ndependency. Use `connection_grants` and the approved `connection_request`/`connection_status`\nflow from the get-started Skill before project actions.\n\n1. Reuse the chosen project via `project_list`/`project_get` and read `project_context_get`. For a new\n   app, use `project_create` with its approved organization, name, region, data mode and Dev\n   access mode, `source_provider: \"managed\"` and the intended `template`. Choose `vite-react`\n   for a basic web app, or `empty` for a specifically chosen supported stack. Preserve an\n   existing project's region and data; do not infer region from an\n   agent's IP. Shared Dev/Prod data requires Dev followed by promotion; isolated data permits\n   independent environments and incurs separate database usage.\n2. Follow the accepted project operation, then read `source_get` with `include_binding: true` until its managed source is\n   `ready` and has a persisted commit. Creation queues source initialization after the project\n   is provisioned; a completed project operation can still have `source.status: \"pending\"`.\n   Keep polling that source rather than starting a duplicate initialization. A `failed` source\n   needs its recorded failure diagnosed. When `initialization_operation_id` is returned, follow\n   that actual child operation with `operation_get`; otherwise use the returned\n   `initialization_error_code`. An `authorization_changed` failure needs the approved connection\n   and project grant restored through **ohmyhost-get-started** before retrying the source action.\n   For an existing project with no source and no pending\n   initialization, `source_initialize` can create the explicitly chosen template under the\n   current generation and a saved key. Observe that accepted operation and reread `source_get`\n   before writing files. A GitHub source is not permission to initialize over it.\n3. Read the manifest with `source_files`, then pass `path` for each relevant file at the current\n   commit. `format: \"text\"` is the default; it returns `content_text` with `encoding: \"utf8\"`\n   when valid UTF-8, otherwise `content_base64` with `encoding: \"base64\"`. Choose the explicit\n   base64 format for binary contents. Apply purposeful\n   batches with `source_changes`: exact `expected_source_generation`, `expected_commit_sha`,\n   a concise commit `message`, and each changed path's plain UTF-8 `content_text` and executable\n   flag. Supply exactly one content field per change: use `content_base64` for binary contents\n   or `content_base64: null` to delete the file. Do not supply both text and base64. Preserve\n   the returned executable flags when editing existing files. Reuse the idempotency key after an uncertain\n   response. If another chat advanced the source, read the current version and reconcile the\n   changes; never force-overwrite the other chat's work. Follow each accepted source operation\n   to success, then read `source_get` for its persisted commit before planning a build.\n   Source generation changes when a binding is initialized or switched, not on every commit;\n   concurrent edits are guarded by the expected commit. Copy both guards from current state.\n   A change batch accepts at most 2 MiB of decoded content. For a complete atomic tree or\n   related edits larger than that batch, use the remote upload flow below rather than\n   splitting one intended version into several unrelated commits.\n4. Use `source_versions` and `source_diff` to inspect saved work. `source_restore` creates a\n   new version from the selected earlier commit under the same revision guards; it does not\n   delete history or roll back database migrations. Observe its accepted operation before\n   reading the resulting current commit.\n5. Set required application credentials using `secret_input_request` for the chosen environment.\n   Give the private portal URL to the user and observe `connection_status`. `secrets_list` shows\n   metadata only. Never put a password, model API key or runtime secret into a tool argument,\n   source file, commit, project note or chat message.\n6. Call `deployment_plan` for the exact accepted commit and `environment: \"dev\"`; review its\n   real costs/effects within the user's existing authorization, then `deployment_create` with\n   the plan and one saved key. Follow the same `operation_get` until its terminal state; use\n   `deployment_get` and `deployment_logs` for diagnosis. A running operation is not a reason\n   to start another build.\n7. Read `project_status` for the Dev URL and access mode. Public Dev opens directly. For\n   protected Dev, give the user the private reusable `share_url` from\n   `project_dev_share_link_get`. To inspect it as the agent, use `project_dev_access_create`\n   and open its one-time `redeem_url`; do not issue another ticket while the first is unused.\n   Then verify the clean preview URL. Keep these entry links out of notes, source and logs.\n   Verify the app's meaningful\n   interaction, expected content and any requested data flow before calling it ready. If the\n   chat cannot inspect the preview, say exactly what remains unverified and keep the same project.\n8. Publish only when requested and allowed by the project's explicit publishing grant. Use\n   `promotion_plan` then `deployment_promote` for the verified Dev deployment, including the\n   exact ETag, confirmation and idempotency guards. Alternatively plan an exact commit into\n   isolated Prod when that is the requested supported route. Prod needs its own secret inputs;\n   they are not copied from Dev. Poll the accepted operation and verify the public result.\n\nReturn the project's working address, exact commit and verification result, plus any required\nuser action. Do not claim a plugin installation, finished OAuth page, saved commit or accepted\ndeployment proves that the app is live.\n\n## Save a complete tree in native chat\n\nRemote uploads use application file bytes, never a directory on this computer. Read the\ncomplete intended files from the client's actual available file or repository context.\nIf that context or payload transfer is unavailable, state the concrete capability gap;\ndo not invent missing files or hashes. For a new app that starts from an uploaded tree,\nchoose an explicitly intended `empty` managed template, observe its initialization, then\ncommit the replacement tree. Use `initialize` only for a genuinely unbound project with\nno pending initialization.\n\n1. Read `source_get` with `include_binding: true`. Call `source_upload_prepare` once with\n   `project_id`, `mode`, the original `expected_source_generation`,\n   `expected_source_connection_id`, `expected_commit_sha`, a concise `message` and one\n   saved `idempotency_key`. Initialize uses null connection/head and generation 0;\n   commit uses the current managed connection/generation and reconciled parent SHA;\n   switch uses the original GitHub connection/generation and a null parent. Retain the\n   accepted `operation.id` as the upload's operation ID.\n2. Call `source_blob_put` for each complete file with the same `project_id` and\n   `operation_id`, its repository-relative `path`, `executable` flag, a saved per-file\n   key and exactly one of `content_text` or `content_base64`. The server validates the\n   actual bytes and computes SHA-256 and byte length. Keep its confirmed\n   `{path, sha256, byte_length, executable}` receipt unchanged. Never supply or invent a\n   hash or length. This is not a chunk-upload protocol for oversized individual files.\n3. Finalize the complete intended `files` manifest, including unchanged files that should\n   remain, from receipts of **this upload operation**. Every staged file must occur exactly;\n   do not omit an already staged extra or replace a staged path's bytes/mode. An omitted\n   previously saved path is absent from the replacement tree. Use `source_upload_commit`\n   for initialize/commit with the upload's `operation_id`, original generation and one\n   finalize key. Use `source_switch` only for switch mode, as described below.\n4. Observe the same `operation_get` and `source_upload`. Require operation `succeeded`\n   and receipt `state: \"committed\"` before treating the receipt's own `commit_sha` as saved.\n   A sealed receipt can already name an unpushed candidate; it is not deployable proof.\n   Current main can later advance, so keep this operation's own committed SHA for its build.\n\n`source_upload` reports state, original generation/parent, expiry and commit; it is not a\nfile inventory. Recover a lost blob receipt by repeating identical `source_blob_put`\narguments and key. After an uncertain prepare/finalize, retain the original operation,\nmanifest and keys and observe it before another attempt. Staged paths are immutable.\nAn expired timestamp alone does not prove a completed upload failed. Diagnose a reported\nfailure or conflict, read and merge current state, then deliberately start new work.\n\nThe complete tree is at most 8 MiB decoded and 2,000 files; each complete file is at most\n2 MiB. Use safe archive-compatible ASCII paths. Credentials, private `.env` contents,\ndependency directories, caches and build output are not application source. These server\nbounds do not establish the chosen native client's transfer capacity; report a real client\nlimit rather than claiming an unverified large upload. Saving the version starts no build\nor publication; use the separate preview/deployment workflow for the confirmed exact SHA.\n\n## Switch source on the existing project\n\nOnly switch on the user's explicit request. Read the current project and `source_get` with\n`include_binding: true` for the source connection and generation first; explain which\nsource will be replaced. Upload the complete intended\nreplacement tree using the supported switch operation with those original guards. Finalize it\nbefore updating the checkout binding. A conflict requires a fresh source read and review.\n\nIn native chat, use `source_upload_prepare` with `mode: \"switch\"`, the existing GitHub\n`expected_source_connection_id` and generation, and `expected_commit_sha: null`. Stage all\nintended files through `source_blob_put`, retain their receipts, then call `source_switch`\nwith `project_id`, the original `upload_operation_id`, original source connection/generation,\nthe complete `files` manifest and a saved key. Do not use `source_upload_commit` for switch.\nThe old binding stays active until successful completion. Observe that same operation and\nupload receipt, then reread the full source binding; its generation increases once. The\nproject's GitHub auto-deploy is disabled by switching; the GitHub repository is not deleted.\nGitHub history is not imported. The local equivalent remains `source publish --mode switch`.\n\nKeep the same project ID, environment URLs, domain, runtime secrets and database/data-mode\nidentity. Do not create another project, delete the GitHub repository, alter its remotes or\ncopy customer data as a shortcut. A failed or uncertain switch is reconciled under its original\noperation/idempotency key. Read `source_get` after completion before planning the new commit.\n\nRollback, deletion, data-mode changes and domain/mail changes retain their own reviewed plans\nand scopes. Use the existing deployment, database and domains Skills as appropriate; switching\nsource alone authorizes none of them.\n"
}