Update to Tiniest Cloud

{
  "description": "Build and deploy apps to Tiniest Cloud, which gives every app sign-in, per-user storage, realtime, push notifications, scheduled jobs and an LLM with no keys and no backend. Use when building or changing an app hosted on Tiniest Cloud, or when you see tiny.db, tiny.ai, or tiny.rules.json.",
  "included_files": [],
  "name": "tiny",
  "skill_md_contents": "---\nname: tiny\ndescription: >-\n  Build and deploy apps to Tiniest Cloud, which gives every app sign-in, per-user storage,\n  realtime, push notifications, scheduled jobs and an LLM with no keys and no backend. Use when\n  building or changing an app hosted on Tiniest Cloud, or when you see tiny.db, tiny.ai, or\n  tiny.rules.json.\n---\n\n# Building for Tiniest Cloud\n\nTiniest Cloud hosts static frontends. Each one gets sign-in, per-user storage, realtime rooms,\npush notifications, scheduled jobs and a language model, with no keys anywhere and no backend\nto write.\n\n## Call `tiny_guide` first\n\n**Before writing or changing any app that will be deployed here, call the `tiny_guide` tool.**\nIt returns the current SDK reference, the limits and the patterns that matter, then names the\nguide's other sections; call it again with `section` for each one the build uses (`fetch` to\ncall another service's API, `jobs` for scheduled work, `functions` for server code). This file\ndeliberately does not repeat any of it. The platform gains features,\nand a copy pasted into a plugin listing would keep teaching an old API long after the real one\nmoved on, producing apps that deploy cleanly and then fail in the browser.\n\nSo: `tiny_guide`, then build, then `deploy`.\n\n**Before designing, call `tiny_guide` with a `topic`** — `design`, `app`, `website`,\n`dashboard`, `presentation` or `form` — for how that kind of thing should look: a direction for\nthe product and its industry, palette, type, motion, light and dark, and a checklist. When the\nperson has design standards of their own (a design system, components, a brand guide, an app to\nmatch), those come first and the playbook only fills what they leave open.\n\n## What never changes\n\nThese four hold regardless of which version of the SDK is current, and they are the ones an\nagent gets wrong when it treats this like ordinary static hosting:\n\n- **Build a static frontend.** Plain HTML, CSS and JavaScript, or a framework's build output\n  (a React or Astro project's `dist/`), with `index.html` at the top level of what you deploy. With a shell, a new one starts from\n  `npm create tiniest-cloud@latest <folder>` (add `-- --template site` for a website).\n- **Do not write a login flow.** Sign-in belongs to the platform. The SDK tells you who the\n  visitor is; there are no passwords, sessions or tokens for the app to handle.\n- **Do not use `localStorage` for anything that matters.** It is per-browser and per-device,\n  so the same person loses their data on their phone. Storage in the SDK follows the account.\n- **Do not add a server of your own or call your own API.** There is no origin to call. Logic\n  users must not be able to change runs as a backend function: a file in the deployed\n  `_functions/` folder (`public/_functions/` in the starters), called from the page with\n  `tiny.call`. Anything that needs a secret goes through a connection the app's owner declares,\n  so the key never reaches the page or the function's code.\n\n## Deploying\n\nThe server cannot read your disk. Read the files yourself and pass their contents to `deploy`.\nEvery deploy is a new immutable version, and earlier versions stay restorable with `rollback`.\n\nIf a deploy reports that an app uses `localStorage` or calls its own backend, `modernize_app`\nconverts it to the platform's own storage and sign-in.\n"
}