@workser/cli 0.6.20 → 0.6.22

package/dist/index.js

@@ -4035,6 +4035,84 @@ built next.
 Run it alongside \`workser verify\` before declaring an API task finished. An API
 somebody can call and an API somebody can integrate with are different products,
 and the spec is the difference.
+`
+  },
+  {
+    topic: "apps",
+    title: "The project's other apps \u2014 what they are, and wiring one to another",
+    summary: "List every app in the project with its type, deploy state and URL; read a sibling's settings without exposing them; point a client at the right service.",
+    commands: ["project", "env"],
+    source: "skills/workser/reference/apps.md",
+    body: `# The project's other apps
+
+A project holds several apps \u2014 a web app, one or more services, maybe a phone
+or desktop app \u2014 and each has its own variables. Every command here takes
+\`--app <webAppId>\`; without it you are operating on the app whose folder you
+are in.
+
+Start from the inventory rather than guessing:
+
+\`\`\`bash
+workser project apps          # every app: id, type, status, URL, local folder
+workser project app <id>      # one app: preview + production URLs, local path
+\`\`\`
+
+That answers the questions you actually need before wiring anything: which
+services exist, whether each is **deployed or only local**, and what its
+address is per environment.
+
+### Reading another app's config without exposing it
+
+\`\`\`bash
+workser env list --app <id> --env production   # KEYS only \u2014 values are masked
+workser env get  <key> --app <id>              # the value. Sensitive.
+\`\`\`
+
+\`list\` is the one to reach for. It answers "does that service already have a
+\`STRIPE_SECRET_KEY\`?" without printing it, which is almost always the question.
+Use \`get\` only when you genuinely need the value in hand, and never echo it into
+a file the user will read, a commit, or a log.
+
+### Copying a value from one app to another
+
+\`\`\`bash
+workser env set KEY="$(workser env get KEY --app <from> --quiet)" --app <to>
+\`\`\`
+
+Two rules that are not optional:
+
+- **Match the environment.** A production key set into preview, or the reverse,
+  produces an app that works in one place and fails in the other with no
+  message. Pass \`--env\` on both sides.
+- **Never copy a secret into a phone or desktop app.** Those bundles install on
+  someone's device and anything inside can be read by whoever installs it. A
+  client gets public values only (\`EXPO_PUBLIC_*\`, \`NEXT_PUBLIC_*\`); anything
+  privileged stays in a service and the client reaches it over HTTP.
+
+### Pulling config into a local file
+
+\`\`\`bash
+workser env pull --app <id> --env preview --out .env.local
+\`\`\`
+
+Writes that app's cloud variables locally so \`npm run dev\` behaves like the
+deployed app. Keep the file out of git.
+
+### Pointing a client at a service
+
+There is no magic wiring. Read the service's URL from \`project app <id>\`, then
+set it on the client under the key that client reads:
+
+| Client | Key |
+| --- | --- |
+| Phone app (Expo) | \`EXPO_PUBLIC_API_URL\` |
+| Desktop app | \`NEXT_PUBLIC_API_URL\` |
+| Web app | \`NEXT_PUBLIC_API_URL\` |
+
+Workser sets this for you **only** when the project has exactly one service \u2014
+then it is not a guess. With two or more, the choice is yours to make and to
+say out loud, because nothing else can know which service that client belongs
+to.
 `
   },
   {
@@ -4491,8 +4569,35 @@ turn.
 
 Types: \`input\` (default, free text), \`choice\` (with \`--option\`), \`approval\`
 (permission), \`confirmation\` (check an assumption), \`information\` (FYI, no answer
-needed). It times out (default 10 min) rather than hanging forever; if it does, carry
-on and state clearly what you assumed.
+needed), \`create_app\` (below). It times out (default 10 min) rather than hanging
+forever; if it does, carry on and state clearly what you assumed.
+
+## Asking for an app that does not exist yet
+
+The project needs a kind of app it does not have \u2014 a backend for the phone app, a
+desktop build of the website. **You cannot create one yourself**, by design: apps
+are real infrastructure on the owner's account. Ask, and their click creates it.
+The answer gives you the new app's id.
+
+\`\`\`
+workser ask "The phone app needs an API to hold its data. Add one?" \\
+  --type create_app --app-type api --app-name "Lattice Drive API"
+\`\`\`
+
+\`--app-type\` is required and must be one of:
+
+| | |
+|---|---|
+| \`web\` | Next.js site on Workser hosting |
+| \`mobile\` | Expo / React Native phone app |
+| \`desktop\` | Next.js + Electron, installs on a Mac or PC |
+| \`api\` | backend service \u2014 \`api-hono\` (TypeScript) or \`api-python\` (FastAPI) |
+
+**Name the kind you actually mean.** Asking for \`web\` because you are unsure is
+how a desktop app gets created as a website: the card shows the owner the kind
+you named, they approve THAT, and the wrong app is provisioned under your own
+sentence asking for the right one. An unknown kind is refused with the list
+above rather than guessed at \u2014 read it and ask again.
 
 **Never ask for a secret value this way** \u2014 the answer is stored and displayed. Ask
 *where* a key should go, then have the user set it (\`workser env set\` writes it
@@ -4569,6 +4674,105 @@ workser artifact add --url https://acme.workser.app --kind app -t "Storefront"
 \`\`\`
 
 See \`reference/deliverables.md\`.
+`
+  },
+  {
+    topic: "desktop",
+    title: "Desktop apps \u2014 one codebase, a window, and an installer",
+    summary: "How a Workser desktop app is built, what breaks only after it is installed, and how to produce and publish a signed installer.",
+    commands: ["project", "env", "deploy"],
+    source: "skills/workser/reference/desktop.md",
+    body: `# Desktop apps
+
+A Workser desktop app is **one Next.js codebase with two ways to run**: a normal
+web build for development and preview, and an Electron shell that loads the
+static export from disk and gets packaged into an installer.
+
+There is no deploy. A desktop app has no Vercel project and no URL \u2014 its
+preview is the app running locally, and its deliverable is a file someone
+double-clicks.
+
+## The rule that breaks everything, and only after install
+
+**The app must stay statically exportable.** A packaged Electron app loads from
+\`file://\` and has **no Node server**. So none of this exists once it is
+installed:
+
+- server components that fetch at request time
+- server actions (\`"use server"\`)
+- route handlers under \`app/api/*\`
+- \`next/image\` optimisation
+
+Every one of them works in \`npm run dev\` **and** in the local preview, and fails
+only on the owner's machine. That is the one direction of error nobody catches,
+so \`next.config.mjs\` keeps \`output: "export"\` to make the build fail loudly
+instead. Do not remove it to "fix" an import.
+
+Need a server? Use the project's api app \u2014 \`workser project apps\` to find it,
+then read its URL and set \`NEXT_PUBLIC_API_URL\`. See \`workser help apps\`.
+
+## Secrets: this is a public client
+
+Anyone who installs the app can read every string inside it. So:
+
+- \`NEXT_PUBLIC_*\` only, and nothing behind that prefix is private
+- never a database URL, an API key, or a \`wsgw_\` gateway key
+- anything privileged lives in the api app and is reached over HTTP
+
+The manifest deliberately does not declare \`AI_GATEWAY_API_KEY\` for this type,
+which is what stops Workser seeding one. Do not add it.
+
+## The two processes
+
+| File | Runs where | May do |
+| --- | --- | --- |
+| \`electron/main.js\` | Node, on the machine | files, tray, windows, updates |
+| \`app/**\` | the renderer, sandboxed | ordinary web code, no Node |
+| \`electron/preload.js\` | the bridge | expose **named functions** only |
+
+\`contextIsolation: true\` and \`nodeIntegration: false\` are not defaults to tidy
+up \u2014 turning either off hands full filesystem and process access to page code.
+Add a capability by exporting one named function from preload, never by handing
+the renderer \`ipcRenderer\`.
+
+## Building and shipping
+
+\`\`\`bash
+npm run dev            # browser only, fastest loop
+npm run dev:desktop    # the same app inside a real Electron window
+npm run build          # static export -> out/
+npm run dist:desktop   # the installer -> release/
+\`\`\`
+
+In the app, **Publish \u2192 Your installer** does the same thing with a target
+picker, progress, and a download link at the end.
+
+## Signing \u2014 the owner's certificate, never Workser's
+
+An unsigned build runs perfectly on the machine that made it and tells every
+other machine the app is damaged (macOS) or trips SmartScreen (Windows). That
+is the failure an owner cannot diagnose, so say it before they send the file.
+
+\`electron-builder\` reads these from the environment; set them with
+\`workser env set --app <id>\`:
+
+| Platform | Keys |
+| --- | --- |
+| macOS | \`CSC_LINK\`, \`CSC_KEY_PASSWORD\` |
+| macOS notarize | \`APPLE_ID\`, \`APPLE_APP_SPECIFIC_PASSWORD\`, \`APPLE_TEAM_ID\` |
+| Windows | \`WIN_CSC_LINK\`, \`WIN_CSC_KEY_PASSWORD\` |
+
+A Mac app can only be built on a Mac \u2014 \`codesign\` and \`hdiutil\` are Apple's and
+have no substitute.
+
+## Auto-update
+
+Publishing uploads the installer **and** the update metadata
+(\`latest-mac.yml\` / \`latest.yml\`) beside it. \`electron-updater\` reads only that
+metadata, so an installer published alone gives you a download that works once
+and an app that can never update itself \u2014 and nobody notices until release two.
+Keep \`publish.url\` in \`electron-builder.yml\` pointed at the prefix the publish
+step reports back.
 `
   },
   {
@@ -4776,6 +4980,13 @@ same rule.
 - **Cloud and local are different environments.** \`env set\` configures the
   cloud; the files in the app folder configure this computer. Don't hand-edit
   one to change the other.
+
+## Another app's variables
+
+Every command here takes \`--app <webAppId>\`; without it you are operating on
+the app whose folder you are in. Reading a sibling service's config, copying a
+value across, and pointing a client at a service are all covered in
+\`workser help apps\`.
 `
   },
   {
@@ -5071,6 +5282,35 @@ connect to it** \u2014 useful as a snapshot, useless as somewhere to run tests.
   is this database costing me while nothing is happening".
 - **Most apps never need the storage or functions half.** If the user just wants
   to store uploads, the default bucket in \`reference/storage.md\` is the answer.
+
+## Sign-in for the app you are building
+
+**WEB APPS ONLY.** Everything in this section is about the \`web\` app type. Neon's
+managed auth is consumed through a Next.js server route (\`/api/auth/*\`), so it
+does not reach a mobile app, and it does not reach a desktop app either \u2014 that
+type is a static export and cannot serve a route at all. For those two, auth
+belongs in the project's API service, self-hosted, where Google needs the owner's
+own credentials like anywhere else. Do not tell a phone-app owner that Google
+sign-in is free.
+
+**On a web app with Neon-managed auth, Google sign-in is already on.** Neon runs
+it on its own shared OAuth credentials \u2014 there is no client ID to create, no
+secret to set, no redirect URI to register. If the owner asks for "login with
+Google", build the button; do not send them to the Google Cloud Console.
+
+Check which mode the app is on before answering: \`workser env get AUTH_MODE\`.
+\`neon_managed\` means the above. Anything else (or absent) is self-hosted, where
+Google needs the owner's own \`GOOGLE_CLIENT_ID\`/\`GOOGLE_CLIENT_SECRET\` and a
+redirect URI per domain.
+
+Two caveats worth saying out loud rather than letting the owner find later:
+
+- **The consent screen says Neon, not their brand**, and the quota is shared.
+  Correct for a prototype, wrong once real users sign in. Moving to their own
+  Google client is done in the desktop app under **Cloud -> Auth -> Sign-in
+  providers**, which also shows the exact redirect URI to register.
+- **GitHub and Vercel have no shared credentials.** Those stay off until the
+  owner installs their own client in that same place.
 `
   },
   {
@@ -9048,6 +9288,16 @@ var TYPES = [
    */
   "create_app"
 ];
+var APP_TYPES = [
+  "web",
+  "mobile",
+  "desktop",
+  // `api` is the shorthand; the two concrete spellings pick the runtime and
+  // are accepted at this boundary for an agent that knows which one it wants.
+  "api",
+  "api-hono",
+  "api-python"
+];
 function registerAsk(program3) {
   program3.command("ask <message>").description("Ask the user a question and wait for their answer").option(
     "-t, --type <type>",
@@ -9060,7 +9310,7 @@ function registerAsk(program3) {
     []
   ).option(
     "--app-type <type>",
-    "create_app only: web | mobile | api | worker | cron | python"
+    `create_app only: ${APP_TYPES.join(" | ")}`
   ).option(
     "--app-name <name>",
     "create_app only: what the app should be called"
@@ -9092,7 +9342,13 @@ function registerAsk(program3) {
       }
       if (type === "create_app" && !opts.appType) {
         throw new WorkserError(
-          "Say which kind of app: `--app-type mobile`.",
+          `Say which kind of app: \`--app-type desktop\`. One of: ${APP_TYPES.join(", ")}.`,
+          { code: "bad_request" }
+        );
+      }
+      if (type === "create_app" && opts.appType && !APP_TYPES.includes(opts.appType)) {
+        throw new WorkserError(
+          `Unknown --app-type "${opts.appType}". Use one of: ${APP_TYPES.join(", ")}.`,
           { code: "bad_request" }
         );
       }
@@ -12189,7 +12445,7 @@ function colour(d) {
 
 // src/index.ts
 var pkg = {
-  version: true ? "0.6.20" : "0.0.0-dev"
+  version: true ? "0.6.22" : "0.0.0-dev"
 };
 var program2 = new Command();
 program2.name("workser").description(

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@workser/cli",
-  "version": "0.6.20",
+  "version": "0.6.22",
   "description": "Workser CLI — give your local AI agent native DevOps & infrastructure on Workser. The agent runs `workser …` to provision, deploy, and manage real apps.",
   "license": "MIT",
   "type": "module",

package/skills/workser/SKILL.md

@@ -21,6 +21,8 @@ screen long. Find your row, run that **one** command — every line costs you.
 | See what was decided or written down for this project | `decision …`, `requirement …`, `doc …` | `workser help sdlc-entities` |
 | Follow the project's brand — colours, fonts, logo | `design …` | `workser help brand` |
 | Provision or query Postgres; list end users | `db …`, `auth …` | `workser help database` |
+| See the project's other apps, and wire one to another | `project …`, `env … --app` | `workser help apps` |
+| Build a desktop app, sign it, ship an installer | `deploy`, `env …` | `workser help desktop` |
 | Deploy, set env vars, read logs, check a domain | `deploy`, `env …`, `logs`, `versions`, `domain`, `open` | `workser help deploy` |
 | Save work before a risky change, undo it, sync this folder | `checkpoint`, `restore`, `sync` | `workser help version-control` |
 | Put files in the project's bucket | `storage …` | `workser help storage` |

package/skills/workser/reference/apps.md

@@ -0,0 +1,77 @@
+---
+topic: apps
+title: The project's other apps — what they are, and wiring one to another
+summary: List every app in the project with its type, deploy state and URL; read a sibling's settings without exposing them; point a client at the right service.
+commands: [project, env]
+---
+
+# The project's other apps
+
+A project holds several apps — a web app, one or more services, maybe a phone
+or desktop app — and each has its own variables. Every command here takes
+`--app <webAppId>`; without it you are operating on the app whose folder you
+are in.
+
+Start from the inventory rather than guessing:
+
+```bash
+workser project apps          # every app: id, type, status, URL, local folder
+workser project app <id>      # one app: preview + production URLs, local path
+```
+
+That answers the questions you actually need before wiring anything: which
+services exist, whether each is **deployed or only local**, and what its
+address is per environment.
+
+### Reading another app's config without exposing it
+
+```bash
+workser env list --app <id> --env production   # KEYS only — values are masked
+workser env get  <key> --app <id>              # the value. Sensitive.
+```
+
+`list` is the one to reach for. It answers "does that service already have a
+`STRIPE_SECRET_KEY`?" without printing it, which is almost always the question.
+Use `get` only when you genuinely need the value in hand, and never echo it into
+a file the user will read, a commit, or a log.
+
+### Copying a value from one app to another
+
+```bash
+workser env set KEY="$(workser env get KEY --app <from> --quiet)" --app <to>
+```
+
+Two rules that are not optional:
+
+- **Match the environment.** A production key set into preview, or the reverse,
+  produces an app that works in one place and fails in the other with no
+  message. Pass `--env` on both sides.
+- **Never copy a secret into a phone or desktop app.** Those bundles install on
+  someone's device and anything inside can be read by whoever installs it. A
+  client gets public values only (`EXPO_PUBLIC_*`, `NEXT_PUBLIC_*`); anything
+  privileged stays in a service and the client reaches it over HTTP.
+
+### Pulling config into a local file
+
+```bash
+workser env pull --app <id> --env preview --out .env.local
+```
+
+Writes that app's cloud variables locally so `npm run dev` behaves like the
+deployed app. Keep the file out of git.
+
+### Pointing a client at a service
+
+There is no magic wiring. Read the service's URL from `project app <id>`, then
+set it on the client under the key that client reads:
+
+| Client | Key |
+| --- | --- |
+| Phone app (Expo) | `EXPO_PUBLIC_API_URL` |
+| Desktop app | `NEXT_PUBLIC_API_URL` |
+| Web app | `NEXT_PUBLIC_API_URL` |
+
+Workser sets this for you **only** when the project has exactly one service —
+then it is not a guess. With two or more, the choice is yours to make and to
+say out loud, because nothing else can know which service that client belongs
+to.

package/skills/workser/reference/deliverables.md

@@ -95,8 +95,35 @@ turn.
 
 Types: `input` (default, free text), `choice` (with `--option`), `approval`
 (permission), `confirmation` (check an assumption), `information` (FYI, no answer
-needed). It times out (default 10 min) rather than hanging forever; if it does, carry
-on and state clearly what you assumed.
+needed), `create_app` (below). It times out (default 10 min) rather than hanging
+forever; if it does, carry on and state clearly what you assumed.
+
+## Asking for an app that does not exist yet
+
+The project needs a kind of app it does not have — a backend for the phone app, a
+desktop build of the website. **You cannot create one yourself**, by design: apps
+are real infrastructure on the owner's account. Ask, and their click creates it.
+The answer gives you the new app's id.
+
+```
+workser ask "The phone app needs an API to hold its data. Add one?" \
+  --type create_app --app-type api --app-name "Lattice Drive API"
+```
+
+`--app-type` is required and must be one of:
+
+| | |
+|---|---|
+| `web` | Next.js site on Workser hosting |
+| `mobile` | Expo / React Native phone app |
+| `desktop` | Next.js + Electron, installs on a Mac or PC |
+| `api` | backend service — `api-hono` (TypeScript) or `api-python` (FastAPI) |
+
+**Name the kind you actually mean.** Asking for `web` because you are unsure is
+how a desktop app gets created as a website: the card shows the owner the kind
+you named, they approve THAT, and the wrong app is provisioned under your own
+sentence asking for the right one. An unknown kind is refused with the list
+above rather than guessed at — read it and ask again.
 
 **Never ask for a secret value this way** — the answer is stored and displayed. Ask
 *where* a key should go, then have the user set it (`workser env set` writes it

package/skills/workser/reference/desktop.md

@@ -0,0 +1,98 @@
+---
+topic: desktop
+title: Desktop apps — one codebase, a window, and an installer
+summary: How a Workser desktop app is built, what breaks only after it is installed, and how to produce and publish a signed installer.
+commands: [project, env, deploy]
+---
+
+# Desktop apps
+
+A Workser desktop app is **one Next.js codebase with two ways to run**: a normal
+web build for development and preview, and an Electron shell that loads the
+static export from disk and gets packaged into an installer.
+
+There is no deploy. A desktop app has no Vercel project and no URL — its
+preview is the app running locally, and its deliverable is a file someone
+double-clicks.
+
+## The rule that breaks everything, and only after install
+
+**The app must stay statically exportable.** A packaged Electron app loads from
+`file://` and has **no Node server**. So none of this exists once it is
+installed:
+
+- server components that fetch at request time
+- server actions (`"use server"`)
+- route handlers under `app/api/*`
+- `next/image` optimisation
+
+Every one of them works in `npm run dev` **and** in the local preview, and fails
+only on the owner's machine. That is the one direction of error nobody catches,
+so `next.config.mjs` keeps `output: "export"` to make the build fail loudly
+instead. Do not remove it to "fix" an import.
+
+Need a server? Use the project's api app — `workser project apps` to find it,
+then read its URL and set `NEXT_PUBLIC_API_URL`. See `workser help apps`.
+
+## Secrets: this is a public client
+
+Anyone who installs the app can read every string inside it. So:
+
+- `NEXT_PUBLIC_*` only, and nothing behind that prefix is private
+- never a database URL, an API key, or a `wsgw_` gateway key
+- anything privileged lives in the api app and is reached over HTTP
+
+The manifest deliberately does not declare `AI_GATEWAY_API_KEY` for this type,
+which is what stops Workser seeding one. Do not add it.
+
+## The two processes
+
+| File | Runs where | May do |
+| --- | --- | --- |
+| `electron/main.js` | Node, on the machine | files, tray, windows, updates |
+| `app/**` | the renderer, sandboxed | ordinary web code, no Node |
+| `electron/preload.js` | the bridge | expose **named functions** only |
+
+`contextIsolation: true` and `nodeIntegration: false` are not defaults to tidy
+up — turning either off hands full filesystem and process access to page code.
+Add a capability by exporting one named function from preload, never by handing
+the renderer `ipcRenderer`.
+
+## Building and shipping
+
+```bash
+npm run dev            # browser only, fastest loop
+npm run dev:desktop    # the same app inside a real Electron window
+npm run build          # static export -> out/
+npm run dist:desktop   # the installer -> release/
+```
+
+In the app, **Publish → Your installer** does the same thing with a target
+picker, progress, and a download link at the end.
+
+## Signing — the owner's certificate, never Workser's
+
+An unsigned build runs perfectly on the machine that made it and tells every
+other machine the app is damaged (macOS) or trips SmartScreen (Windows). That
+is the failure an owner cannot diagnose, so say it before they send the file.
+
+`electron-builder` reads these from the environment; set them with
+`workser env set --app <id>`:
+
+| Platform | Keys |
+| --- | --- |
+| macOS | `CSC_LINK`, `CSC_KEY_PASSWORD` |
+| macOS notarize | `APPLE_ID`, `APPLE_APP_SPECIFIC_PASSWORD`, `APPLE_TEAM_ID` |
+| Windows | `WIN_CSC_LINK`, `WIN_CSC_KEY_PASSWORD` |
+
+A Mac app can only be built on a Mac — `codesign` and `hdiutil` are Apple's and
+have no substitute.
+
+## Auto-update
+
+Publishing uploads the installer **and** the update metadata
+(`latest-mac.yml` / `latest.yml`) beside it. `electron-updater` reads only that
+metadata, so an installer published alone gives you a download that works once
+and an app that can never update itself — and nobody notices until release two.
+Keep `publish.url` in `electron-builder.yml` pointed at the prefix the publish
+step reports back.

package/skills/workser/reference/env.md

@@ -113,3 +113,10 @@ same rule.
 - **Cloud and local are different environments.** `env set` configures the
   cloud; the files in the app folder configure this computer. Don't hand-edit
   one to change the other.
+
+## Another app's variables
+
+Every command here takes `--app <webAppId>`; without it you are operating on
+the app whose folder you are in. Reading a sibling service's config, copying a
+value across, and pointing a client at a service are all covered in
+`workser help apps`.

package/skills/workser/reference/neon-backend.md

@@ -74,3 +74,32 @@ connect to it** — useful as a snapshot, useless as somewhere to run tests.
   is this database costing me while nothing is happening".
 - **Most apps never need the storage or functions half.** If the user just wants
   to store uploads, the default bucket in `reference/storage.md` is the answer.
+
+## Sign-in for the app you are building
+
+**WEB APPS ONLY.** Everything in this section is about the `web` app type. Neon's
+managed auth is consumed through a Next.js server route (`/api/auth/*`), so it
+does not reach a mobile app, and it does not reach a desktop app either — that
+type is a static export and cannot serve a route at all. For those two, auth
+belongs in the project's API service, self-hosted, where Google needs the owner's
+own credentials like anywhere else. Do not tell a phone-app owner that Google
+sign-in is free.
+
+**On a web app with Neon-managed auth, Google sign-in is already on.** Neon runs
+it on its own shared OAuth credentials — there is no client ID to create, no
+secret to set, no redirect URI to register. If the owner asks for "login with
+Google", build the button; do not send them to the Google Cloud Console.
+
+Check which mode the app is on before answering: `workser env get AUTH_MODE`.
+`neon_managed` means the above. Anything else (or absent) is self-hosted, where
+Google needs the owner's own `GOOGLE_CLIENT_ID`/`GOOGLE_CLIENT_SECRET` and a
+redirect URI per domain.
+
+Two caveats worth saying out loud rather than letting the owner find later:
+
+- **The consent screen says Neon, not their brand**, and the quota is shared.
+  Correct for a prototype, wrong once real users sign in. Moving to their own
+  Google client is done in the desktop app under **Cloud -> Auth -> Sign-in
+  providers**, which also shows the exact redirect URI to register.
+- **GitHub and Vercel have no shared credentials.** Those stay off until the
+  owner installs their own client in that same place.