@workser/cli 0.6.20 → 0.6.21

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.
 `
   },
   {
@@ -4776,6 +4854,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\`.
 `
   },
   {
@@ -12189,7 +12274,7 @@ function colour(d) {
 
 // src/index.ts
 var pkg = {
-  version: true ? "0.6.20" : "0.0.0-dev"
+  version: true ? "0.6.21" : "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.21",
   "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,7 @@ 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` |
 | 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/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`.