@blotout/qinto-cli 0.1.17 → 0.1.19

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
@@ -281,6 +281,14 @@ Declared `server.schedules` fire on their own while `dev` runs — at the cron's
 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
@@ -295,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.
@@ -527,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 |
 | --- | --- |
@@ -535,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. |
@@ -552,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
 
@@ -574,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: