@blotout/qinto-cli 0.1.16 → 0.1.18

package/README.md

@@ -147,7 +147,7 @@ or go straight to the Developer area:
 
 | Environment | Developer area |
 | --- | --- |
-| `production` | `https://portal.qinto.io/developer` |
+| `production` | `https://platform.blotout.io/developer` |
 | `sandbox` | `https://portal.qinto.tech/developer` |
 
 **Opening that page is the whole step.** The first visit creates a personal organization named after your email address and makes
@@ -263,13 +263,32 @@ goes caller → the site worker's broker → callee, each app in its own worker.
 apps are mounted; a `private` one is refused with `403 forbidden` until you approve it under **App-to-app approvals** on the
 callee's page, exactly as a site manager does on a deployed site.
 
+**An app you call but do not have is mocked for you.** When a mounted app's `rpc.calls` names a slug nothing mounts, `dev`
+scaffolds `mocks/<slug>.ts` inside the calling app — one exported function per function it exposes — and mounts it under that
+slug. `ctx.apps.call('resend', 'send', args)` then takes the real path: caller → broker → the mock's own worker, with no `if` in
+your code and nothing to change when the real app arrives beside you.
+
+If you are logged in, the mock is typed: `dev` fetches the app's published rpc contract, writes it next to the stub as
+`mocks/<slug>.rpc.json`, generates `mocks/<slug>.types.ts` from it, and the platform validates every call and result against it —
+so a mock that lies about its shape fails locally the way the real app would. Commit all three files; the sidecar keeps the mock
+typed offline and for anyone else who checks the app out. Without a contract (not logged in, or the app is unpublished) the stub
+takes and returns `unknown` and the terminal says why.
+
 An app folder added or removed while `dev` is running is not picked up — it says so and asks for a restart. A save inside a
-mounted app rebuilds that app alone.
+mounted app rebuilds that app and every mock alongside it.
 
 Declared `server.schedules` fire on their own while `dev` runs — at the cron's minute, in UTC, with `scheduledTime` set to that
 instant, exactly as the deployed sweep dispatches them. Each schedule on the app's console page also has a **Run now** button,
 so you never wait for the window.
 
+Declared `server.hooks.onLifecycle` hooks fire on the same transitions the platform announces: `installed` when you install the
+app or add an install — and on the first boot of a dev root, which seeds the app installed — `enabled` and `disabled` when
+you switch the app or an install, `configurationChanged` when install or app variables change, from the console or the panel,
+and `uninstalled` when you remove an install or uninstall the app. Each goes out once the worker holds the new state, in
+per-install sequence order. `versionChanged` never fires locally, because a dev build has one version. Like a deployed hook,
+a failing one rolls nothing back: the change stays saved and the console, or the terminal at boot, names the hook that failed.
+To run `installed` again on an existing dev root, uninstall and install the app.
+
 Three surfaces, one per side of the product:
 
 - **The console** is the platform's side. A team and the site `dev.localhost` are seeded for you; every mounted app is listed
@@ -284,7 +303,7 @@ Three surfaces, one per side of the product:
   `track`, `identify`, `consent`, `alias`, `getSession` — then shows which app bundles `q.js` carried and which installs
   activated. Its **Visitor** panel shows the browser's anon id, the one to paste into the ID graph page, and the person id
   once `identify` links one. Its **Events** panel has a button for each of the eleven standard events in
-  [the standard events reference](https://docs.qinto.io): selecting one loads its documented payload into an editable box,
+  [the standard events reference](https://docs.blotout.io): selecting one loads its documented payload into an editable box,
   and **Track it** sends whatever is in it, so you can fire the real shape or your own. Every event reaches your hooks;
   only one carrying a numeric `value` and a non-empty `orderId` — `Purchase`, among the standard ones — is also recorded as a
   conversion in the identity graph.
@@ -516,7 +535,7 @@ can cancel it — an organization owner unwedges an abandoned draft with `--forc
 
 `qinto.app.jsonc` is the app: it is JSONC (comments and trailing commas allowed), it is validated before every publish, and its
 digest is what the version is finalized against. Every field and option is documented in
-[the manifest reference](https://docs.qinto.io); the summary:
+[the manifest reference](https://docs.blotout.io); the summary:
 
 | Field | What it declares |
 | --- | --- |
@@ -524,7 +543,7 @@ digest is what the version is finalized against. Every field and option is docum
 | `slug`, `name`, `description` | Identity. `slug` is immutable and must match the registered app. |
 | `flows` | `transform`, `destination`, or both. |
 | `consent` | The single consent category a visitor must have granted before events reach the app. |
-| `legal` | `termsUrl` and `privacyUrl` — HTTPS, and your own documents, never a `qinto.io` URL. |
+| `legal` | `termsUrl` and `privacyUrl` — HTTPS, and your own documents, never a Qinto platform URL. |
 | `server` | `entry` plus the event and advisory lifecycle hooks the entry exports. |
 | `browser` | `entry` for the bundle inside the site's `q.js`, optional capture names, and action types whose browser handlers return a same-event server result. |
 | `capabilities` | The platform `api` calls and the event `data` the app is allowed to read. |
@@ -532,7 +551,7 @@ digest is what the version is finalized against. Every field and option is docum
 | `variables` | Up to 32 per-install settings a team fills in — `plain` or `secret`, `text`/`password`/`toggle`. |
 | `appVariables` | Up to 16 settings you fill in once for the whole app with `qinto app var set` / `qinto app secret set`. |
 | `endpoints` | Up to 16 HTTP routes served at `https://<site>/app/<slug><path>`. |
-| `rpc` | Functions this app `exposes` to other apps, and the ones it `calls` on them. |
+| `rpc` | Functions this app `exposes` to other apps, and the ones it `calls` on them. Each exposed one is built with `defineRpc`, and publish uploads its argument and result schemas as the version's contract. |
 | `events` | The push topics this app broadcasts to every app on the site. |
 | `ui` | `dir` holding the built panel, and the `build` command that produces it. |
 | `install` | `multiple: true` to let a site install the app more than once, plus a `labelHint`. |
@@ -541,7 +560,7 @@ Limits worth knowing before a publish: the server bundle is capped at 10 MB, the
 one site together), the UI panel at 200 files and 25 MB, and an app at 15 installs per site. A variable value is capped at 256
 serialized bytes, and one variable's values across every install of that app on a site must fit in 5 KB. Every other cap — the
 manifest, the publish, the install, and the runtime envelope — is listed in
-[Qinto app limits](https://docs.qinto.io).
+[Qinto app limits](https://docs.blotout.io).
 
 ## Built for humans and agents alike
 
@@ -563,7 +582,7 @@ Qinto runs in two environments, and every command talks to exactly one of them:
 
 | Environment | API origin | Platform |
 | --- | --- | --- |
-| `production` | `https://api.qinto.io` | `https://portal.qinto.io` |
+| `production` | `https://qinto-api.blotout.io` | `https://platform.blotout.io` |
 | `sandbox` | `https://api.qinto.tech` | `https://portal.qinto.tech` |
 
 `qinto env` picks one and remembers it, so nothing after it needs a flag: