@dooer/dooer-test-env 1.15.0 → 1.17.0

package/docs/getting-access.md

@@ -1,27 +1,33 @@
 # Getting access (new developer)
 
-`dooer-test-env` reads the staging cluster to build its compose file, log in to the image registries and
-fetch the BankID cert. That needs two things, in this order:
+`dooer-test-env` builds your local stack from the staging environment: the service list, the registry
+credentials and the BankID material all come from there. That needs two things, in this order:
 
-1. **VPN** — the cluster API is not reachable from the open internet.
-2. **kubectl access** — a client certificate identifying you to the cluster.
+1. **VPN** — nothing this tool talks to is reachable from the open internet.
+2. **An admin session for staging** — `remote-environment login`.
 
-**Both come from an admin**: they create your VPN tunnel and your cluster credential, and send you two
-files — a WireGuard `.conf` and a `kubeconfig`. You install them and check they work. See
-[issuing-access.md](./issuing-access.md) for their side.
+**kubectl is no longer required.** It used to be: every developer held a cluster certificate that could
+read every Secret in the namespace. That is now behind
+[`service-dooer-test-env`](../_specification/service-dooer-test-env.md), which exposes only the operations
+this tool needs, each admin-gated and recorded. If you operate the cluster itself you may still want a
+kubectl credential — see [issuing-access.md](./issuing-access.md) — but you do not need one to use this
+tool.
+
+**The VPN config comes from an admin**: they create your tunnel and send you a WireGuard `.conf`.
 
 ---
 
 ## 0. Prerequisites
 
 ```bash
-brew install wireguard-tools kubernetes-cli
+brew install wireguard-tools
 ```
 
-`openssl` ships with macOS. Check everything is there:
+Plus Docker (Desktop) and Node 18+. `kubernetes-cli` is no longer needed for this tool — install it only
+if you operate the cluster for other reasons.
 
 ```bash
-wg --version && kubectl version --client && openssl version
+wg --version && docker info >/dev/null && node --version
 ```
 
 ---
@@ -90,66 +96,23 @@ amount of kubectl configuration will help.
 
 ---
 
-## 2. kubectl access
-
-**Your admin sends you a ready-made `kubeconfig` file.** You do not generate keys or assemble anything —
-they create the credential and hand it over
-([issuing-access.md § 2](./issuing-access.md#2-kubectl--create-their-credential)).
-
-Like the VPN config, that file contains a **private key**. Same handling: install it, then delete the copy
-they sent you.
-
-### 2a. Install it
-
-**If you have no other clusters** — simplest, just put it in place:
-
-```bash
-mkdir -p ~/.kube
-cp ~/Downloads/<yourname>.kubeconfig ~/.kube/config
-chmod 600 ~/.kube/config
-rm ~/Downloads/<yourname>.kubeconfig
-```
-
-**If you already use kubectl for something else**, merge instead of overwriting:
-
-```bash
-cp ~/.kube/config ~/.kube/config.backup            # always back up first
-KUBECONFIG=~/.kube/config:~/Downloads/<yourname>.kubeconfig \
-  kubectl config view --flatten > /tmp/merged && mv /tmp/merged ~/.kube/config
-chmod 600 ~/.kube/config
-rm ~/Downloads/<yourname>.kubeconfig
-```
+## 2. Log in to staging
 
-Then select the context (the admin will tell you its name, `<firstname>-admin@kubernetes`):
+Everything the tool used to read with kubectl now comes from `service-dooer-test-env`, authorized by your
+own session:
 
 ```bash
-kubectl config get-contexts
-kubectl config use-context <firstname>-admin@kubernetes
+npx @dooer/dooer-test-env@latest remote-environment login --env staging --email you+admin@dooer.com
+npx @dooer/dooer-test-env@latest remote-environment status --env staging
 ```
 
-### 2b. Verify
+It has to be an **admin** account, and therefore **email + password** — BankID cannot reach an admin
+account at all (`loginWithBankIdV2` is pinned to `user_type: 'customer'` server-side, and the partner flow
+resolves your `hi` user). `status` prints which of your accounts you ended up as; read the **user type**
+line.
 
-With the VPN up:
-
-```bash
-kubectl auth whoami
-# Username  <firstname>-admin
-# Groups    [system:authenticated]
-
-kubectl get pods -n dooer-staging | head -3
-kubectl get pods -n dooer-production | head -3
-```
-
-Then the two checks `dooer-test-env` actually depends on:
-
-```bash
-kubectl auth can-i get secrets -n dooer-staging     # yes — registry pull secrets + BankID cert
-kubectl get svc dooer-database -n dooer-staging     # the database service the base-DB build reads
-```
-
-All of those must succeed before `dooer-test-env setup` will work.
-
----
+Don't have an admin account? Ask someone who does to create one —
+[user-management.md](./user-management.md) covers `user create`.
 
 ## 3. You are done
 
@@ -157,7 +120,8 @@ All of those must succeed before `dooer-test-env setup` will work.
 npx @dooer/dooer-test-env@latest setup
 ```
 
-`setup` re-checks all of the above and tells you exactly which piece is missing if something is wrong.
+`setup` re-checks all of the above and tells you exactly which piece is missing if something is wrong. It
+needs Docker running, the VPN up, and the session from section 2.
 
 ---
 
@@ -165,11 +129,12 @@ npx @dooer/dooer-test-env@latest setup
 
 | Symptom | Cause |
 | --- | --- |
-| `dial tcp … i/o timeout` from kubectl | VPN is down — `sudo wg show`, then restart it (1b) |
+| `cannot reach service-dooer-test-env … is the VPN up?` | VPN is down — `sudo wg show`, then restart it (1b) |
 | `nc` to the API server hangs | Tunnel is up but not carrying traffic; restart it |
-| `error: You must be logged in to the server (Unauthorized)` | The certificate in your kubeconfig is expired or unknown to the cluster — ask for a re-issue |
-| `Error from server (Forbidden)` | You *are* authenticated; your user has no permissions bound yet — ask the admin to complete their § 2e (bind permissions) |
+| `not logged in to staging` | Run the login in section 2 |
+| `your staging session expired …` | Sessions are short-lived; log in again |
+| `needs an "admin" session` | You are signed in as your customer or `hi` account — log in with your admin email |
 | `wg-quick: 'roboten' already exists` | The interface is already up — `sudo wg-quick down roboten` first |
 
-Certificates are issued for **one year**. When yours expires, ask your admin for a new kubeconfig and
-repeat section 2 — your permissions stay in place, so they only have to re-issue the credential.
+Nothing here expires on a yearly cycle any more: your session is short-lived and you simply log in again.
+The VPN tunnel is the only thing an admin has to issue, and it is issued once.

package/docs/issuing-access.md

@@ -7,6 +7,15 @@ The other side of [getting-access.md](./getting-access.md). Two independent thin
 | **VPN tunnel** | you | create it and send them the config |
 | **kubectl credential** | you | create the certificate, bind permissions, send a kubeconfig |
 
+> **Using `dooer-test-env` no longer requires §2.** Developers need the VPN (§1) and an admin session —
+> nothing more. Every cluster read the tool used to do is now behind `service-dooer-test-env`, which
+> exposes a fixed set of admin-gated, audited operations instead of an open-ended kubeconfig
+> ([the specification](../_specification/service-dooer-test-env.md) explains the reasoning).
+>
+> Issue a cluster certificate only to people who **operate the cluster** — deploying, editing manifests,
+> restarting pods. That is a much smaller group, and it is the point: a kubeconfig grants arbitrary
+> operations, so the fewer that exist, the smaller the surface.
+
 You need a Robo10 token (§1a), `kubectl` with cluster-admin (`system:masters`), and your own VPN up.
 
 ---

package/docs/user-management.md

@@ -0,0 +1,246 @@
+# Logins and user management
+
+These commands talk to an environment through its **public GraphQL endpoint** — the same one the frontends
+use. No VPN, no kubectl, no cluster credentials: just an ordinary HTTPS call and a session.
+
+| environment | endpoint | `--env` |
+| --- | --- | --- |
+| your local stack | `http://localhost:4000/graphql` | `local` (the default) |
+| staging | `https://api.s-e032.com/graphql` | `staging`, or `dooer-staging` / `s-e032` |
+| live | `https://api.dooer.com/graphql` | `production`, or `live` / `dooer-production` |
+
+---
+
+## 1. The three kinds of user
+
+One person normally has **several user rows** — commonly `you@dooer.com` as a customer and
+`you+hi@dooer.com` as a professional. They are separate accounts with separate passwords, and *which one
+you sign in as* decides what you can see and do. This is the single most important thing on this page: most
+confusing "why can't I…" moments are a session that belongs to the wrong one of your accounts.
+
+| | who uses it | what it can see | how to log in |
+| --- | --- | --- | --- |
+| **customer** | end users | only the organizations attached to that user | email **or** BankID |
+| **partner** (`hi`) | accountants | every organization belonging to their partner | email **or** BankID |
+| **admin** | internal staff | everything, and can create users | email **only** |
+
+**BankID cannot reach an admin account.** The general BankID route (`loginWithBankIdV2`) is pinned to
+`user_type: 'customer'` in service-accounts, and the partner route resolves your `hi` account — so an admin
+session always comes from an email + password login.
+
+### Partners worth knowing
+
+A partner is an accounting firm; its `domain` is how it is addressed on the command line.
+
+| partner | domain | what it actually is |
+| --- | --- | --- |
+| Dooer | `dooer` | **Voitto** — the in-house accounting firm |
+| Dooer Sales | `dooersales` | **Dooer free customers** |
+
+`dooer-test-env partner list` shows the rest for whichever environment you point it at.
+
+---
+
+## 2. Logging in
+
+The session is stored in your macOS keychain, one per environment, and every other command picks it up.
+
+### As a customer user
+
+```bash
+# email + password (you are prompted for the password; it is not echoed)
+dooer-test-env remote-environment login --env staging --email you@dooer.com
+
+# BankID — --customer selects the customer route
+dooer-test-env remote-environment login --env staging --bankid --customer
+```
+
+### As a partner user (accountant)
+
+```bash
+# BankID — this is the default, and is exactly what HQ does
+dooer-test-env remote-environment login --env staging
+
+# email + password, using your professional account's address
+dooer-test-env remote-environment login --env staging --email you+hi@dooer.com
+```
+
+The BankID flow never asks which partner you are signing in to — like HQ, it submits an empty domain and
+lets the server resolve it from your BankID identity.
+
+### As an admin
+
+```bash
+dooer-test-env remote-environment login --env staging --email you+admin@dooer.com
+```
+
+Email only, for the reason in §1.
+
+### What a BankID login looks like
+
+An animated QR is drawn in the terminal and refreshed once a second (the payload is time-based, so a frozen
+QR stops scanning). Open the BankID app, scan, confirm — the command prints who you ended up as:
+
+```
+logged in to staging (s-e032) as Jimmy Bergman <jimmy.bergman+hi@dooer.com>
+  user id     203b9010-abb9-4f7c-9a5e-8bbf6f75ca7b
+  user type   hi
+  session     stored in keychain, valid until 2026-09-11T09:31:17.000Z
+```
+
+Always read the **user type** line. It is the quickest way to catch "I meant to be my other account".
+
+---
+
+## 3. Becoming a partner user from an admin session
+
+Signed in as an admin, you can assume a partner user without their BankID — the same thing back-office's
+**“Become user in X”** button does:
+
+```bash
+dooer-test-env remote-environment become someone+hi@dooer.com --env staging
+dooer-test-env remote-environment become someone+hi@dooer.com --env staging --partner "Dooer Sales"
+```
+
+`--partner` is only needed when they belong to more than one; otherwise it resolves on its own.
+
+Becoming replaces the stored session, so the admin token that authorised it is stashed first:
+
+```bash
+dooer-test-env remote-environment become --revert --env staging
+```
+
+---
+
+## 4. Who am I, and where
+
+```bash
+dooer-test-env remote-environment status --env staging
+dooer-test-env remote-environment status --all      # every environment at once
+dooer-test-env remote-environment list              # endpoints + whether you are logged in
+dooer-test-env remote-environment logout --env staging
+```
+
+---
+
+## 5. Using the token from scripts
+
+`remote-environment token` writes **only** the token to stdout — no colour, no label, no trailing text — so
+it drops straight into a variable or a pipe. Errors go to stderr, and stdout stays empty when they do.
+
+```bash
+dooer-test-env remote-environment token                      # local
+dooer-test-env remote-environment token --env staging
+dooer-test-env remote-environment token --env staging | pbcopy
+```
+
+Calling the API by hand with it:
+
+```bash
+TOKEN=$(dooer-test-env remote-environment token --env staging)
+
+curl -s https://api.s-e032.com/graphql \
+  -H "content-type: application/json" \
+  -H "authorization: Bearer $TOKEN" \
+  -d '{"query":"{ currentUser { id email userType } }"}'
+```
+
+The same works against the local stack on `http://localhost:4000/graphql`. The local environment needs no
+login at all — with no stored session it mints a service token from the shared dev keypair, so
+`token --env local` always returns something usable.
+
+> The token is a bearer credential for whichever account you logged in as. Treat it like a password: it is
+> fine in a shell variable, not in a commit, a ticket or a chat message.
+
+---
+
+## 6. Managing users
+
+```bash
+dooer-test-env user search                       # the most recent users
+dooer-test-env user search anna                  # email, name, personnummer or id
+dooer-test-env user search --role customer       # only customers
+dooer-test-env user get anna@dooer.com           # details + partner memberships
+dooer-test-env user partners anna@dooer.com      # just the memberships, with levels
+```
+
+Users are addressable by **id or email** everywhere.
+
+### Creating a user
+
+```bash
+# password generated and printed once
+dooer-test-env user create --email anna@dooer.com --execute
+
+# a customer, with your own password and a personnummer
+dooer-test-env user create --email kim@example.com \
+  --role customer --password 'hunter2hunter2' --personnummer 19900101-1239 --execute
+
+# a professional placed straight into a partner
+dooer-test-env user create --email anna@dooer.com --partner "Dooer Sales" --level admin --execute
+```
+
+This calls `users.create`, the same mutation back-office's `/users/new` uses, so the service hashes the
+password and applies its own validation. Notes:
+
+- **Needs an admin session** in any remote environment.
+- `--role` defaults to `hi`; the others are `customer` and `admin`.
+- The password is shown **once** and cannot be read back. It works on the ordinary email+password login.
+- First and last name default to something derived from the address; override with `--first-name` /
+  `--last-name`.
+- The personnummer must be a **real** one — the API checks the Luhn digit, so an invented number is
+  rejected. The CLI checks it first and tells you which rule failed.
+- Writes are **dry-run until `--execute`**.
+
+---
+
+## 7. Partner membership
+
+```bash
+dooer-test-env partner list                             # every partner in the environment
+dooer-test-env partner users "Dooer Sales"              # its users and their level
+
+dooer-test-env partner assign anna@dooer.com dooersales --level admin --execute
+dooer-test-env partner unassign anna@dooer.com dooersales --execute
+```
+
+Partners are addressable by **id, name or domain**.
+
+`--level` (`member` or `admin`) is the level *within* the partner — not the same axis as the user's
+`--role` at Dooer. Only **`hi`** users can belong to a partner; the CLI applies the same
+`invalid-user-type` rule the API does, so it will not write a row HQ would trip over.
+
+---
+
+## 8. What each session may do
+
+| operation | required session |
+| --- | --- |
+| `user search`, `user get`, `user partners` | any |
+| `partner assign`, `partner unassign`, `partner users` | partner |
+| `partner list` | admin |
+| `user create` | admin |
+
+When a session lacks the level, the CLI names the one that is required and who you are currently signed in
+as, instead of surfacing a raw `Forbidden`:
+
+```
+creating a user needs an "admin" session. You are signed in to staging as jimmy.bergman+hi@dooer.com (hi).
+
+  Log in as an account that has it:
+    dooer-test-env remote-environment login --env staging --email <your-admin-email>
+```
+
+---
+
+## Troubleshooting
+
+| Symptom | Cause |
+| --- | --- |
+| `not logged in to <env>` | No session for that environment — log in (§2) |
+| `your <env> session expired …` | Sessions are short-lived; log in again |
+| `needs an "admin" session` | Wrong one of your accounts — see §1 and §8 |
+| `only "hi" users can belong to a partner` | You aimed a partner command at a customer/admin account |
+| `"x@y.com" matches N users` | That address exists once per user type; address the user by id instead |
+| `personnummer … has an invalid check digit` | Not a real personnummer — the API validates the Luhn digit |
+| BankID QR never completes on **local** | The local stack lost its BankID certs; `dooer-test-env up` re-injects them |

package/lib/bankid.js

@@ -68,6 +68,15 @@ function keychainDelete(key) {
   return sh('security', ['delete-generic-password', '-a', KEYCHAIN_ACCOUNT, '-s', keychainService(key)]).status === 0
 }
 
+// Pull the BankID material from service-dooer-test-env — no kubectl. Same values, same keys.
+async function pullFromService(envName = 'staging') {
+  const remote = require('./remote')
+  const serviceClient = require('./service-client')
+  const env = remote.resolveEnv(envName)
+  const { values } = await serviceClient.request(env, { path: '/v1/bootstrap/bankid' })
+  return values
+}
+
 // Pull the bankid secrets out of the staging k8s secret via kubectl. k8s stores each value base64-encoded
 // in `.data`; we decode to the raw value the staging container would receive (for the PFX that raw value is
 // itself the base64 PFX string, exactly what @dooer/config's `Buffer.from(pfx,'base64')` expects).
@@ -87,7 +96,24 @@ function pullFromStaging({ namespace = DEFAULT_NAMESPACE, secret = DEFAULT_SECRE
 }
 
 // Pull + store in the keychain. Returns the list of keys stored (never the values).
-function pullAndStore(opts = {}) {
+// Async because the service path is an HTTP call. The single caller (`bankid pull`) already awaits.
+async function pullAndStore(opts = {}) {
+  // Service first — the path with no kubectl. The k8s reader stays as the fallback so a developer
+  // mid-migration, or one whose service is unreachable, is not stuck.
+  try {
+    const fromService = await pullFromService(opts.env || 'staging')
+    if (fromService && Object.keys(fromService).length) {
+      const storedFromService = []
+      for (const [key, value] of Object.entries(fromService)) {
+        keychainSet(key, value)
+        storedFromService.push(key)
+      }
+      return storedFromService
+    }
+  } catch (_) {
+    /* fall through to the kubectl path */
+  }
+
   const values = pullFromStaging(opts)
   const stored = []
   Object.entries(values).forEach(([key, value]) => {
@@ -119,6 +145,7 @@ function loadEnv() {
 }
 
 module.exports = {
+  pullFromService,
   SECRET_KEYS,
   DEFAULT_NAMESPACE,
   DEFAULT_SECRET,

package/lib/command/bankid.js

@@ -16,8 +16,8 @@ module.exports = {
           y2
             .option('namespace', { type: 'string', default: bankid.DEFAULT_NAMESPACE })
             .option('secret', { type: 'string', default: bankid.DEFAULT_SECRET }),
-        handler: (argv) => {
-          const stored = bankid.pullAndStore({ namespace: argv.namespace, secret: argv.secret })
+        handler: async (argv) => {
+          const stored = await bankid.pullAndStore({ namespace: argv.namespace, secret: argv.secret })
           console.log(chalk.green(`bankid: stored ${stored.length} secret(s) in the keychain: ${stored.join(', ')}`))
           console.log(chalk.gray('run `dooer-test-env up` (or restart service-accounts) to apply — production BankID.'))
         },

package/lib/command/customer.js

@@ -1,38 +1,17 @@
 const fs = require('fs')
 const chalk = require('chalk')
-const engine = require('../engine/seed')
 const { purge } = require('../engine/purge')
 const { createAccount, SUBSCRIPTION_TYPES } = require('../account')
 
-// Map yargs values back to the engine's own flag argv, then let the engine's proven parser apply its
-// defaults + validation. Keeps ONE source of truth for option semantics (lib/engine/seed.js).
-function toEngineArgv(argv) {
-  const a = []
-  const flag = (name, val) => {
-    if (val !== undefined && val !== null && val !== false) a.push(`--${name}`, String(val))
-  }
-  flag('source', argv.source)
-  flag('target', argv.target)
-  flag('name', argv.name)
-  flag('owner-user', argv.ownerUser)
-  // `local` is a first-class TARGET/SOURCE, not a k8s namespace — --source-local / --target-local keep the
-  // two ideas separate rather than overloading --*-namespace (Jimmy 2026-09-03). The engine addresses the
-  // local stack through the pseudo-namespace `local` internally.
-  if (argv.sourceNamespace === 'local' || argv.targetNamespace === 'local') {
-    throw new Error('use --source-local / --target-local for the local env, not --*-namespace local')
-  }
-  flag('source-namespace', argv.sourceLocal ? 'local' : argv.sourceNamespace)
-  flag('target-namespace', argv.targetLocal ? 'local' : argv.targetNamespace)
-  flag('email', argv.email)
-  flag('if-target-nonempty', argv.ifTargetNonempty)
-  flag('salt', argv.salt)
-  if (argv.only) a.push('--only', [].concat(argv.only).join(','))
-  if (argv.skipTables) a.push('--skip-tables', [].concat(argv.skipTables).join(','))
-  if (argv.execute) a.push('--execute')
-  if (argv.skipFiles) a.push('--skip-files')
-  if (argv.skipUsers) a.push('--skip-users')
-  if (argv.confirmProduction) a.push('--confirm-production')
-  return a
+// `copy` now runs through service-dooer-test-env (export in the source, import in the target) instead of
+// opening two kubectl-sourced database connections. The COMMAND is unchanged — same name, same flags —
+// because that split is an implementation detail, not something a user should have to think about
+// (Jimmy 2026-09-04). These map the existing --*-namespace / --*-local flags onto environment names.
+const ENV_FOR_NAMESPACE = { 'dooer-staging': 'staging', 'dooer-production': 'production' }
+const envFromFlags = (local, namespace, fallback) => {
+  if (local) return 'local'
+  if (!namespace) return fallback
+  return ENV_FOR_NAMESPACE[namespace] || namespace
 }
 
 // Resolve which orgs to copy: exactly one of --source / --sourcefile. A source FILE is inherently a batch,
@@ -84,6 +63,7 @@ const copyOptions = (y) =>
     .option('skip-files', { type: 'boolean', describe: 'skip the S3 file copy' })
     .option('skip-users', { type: 'boolean', describe: 'skip copying referenced users missing from the target' })
     .option('confirm-production', { type: 'boolean', describe: 'REQUIRED to write to dooer-production' })
+    .option('reason', { type: 'string', describe: 'recorded in the audit trail at both ends' })
     .option('execute', { type: 'boolean', default: false, describe: 'actually write (default: dry-run)' })
 
 module.exports = {
@@ -97,8 +77,18 @@ module.exports = {
         builder: copyOptions,
         handler: async (argv) => {
           const sources = readSources(argv)
+          const sourceEnv = envFromFlags(argv.sourceLocal, argv.sourceNamespace, 'staging')
+          const targetEnv = envFromFlags(argv.targetLocal, argv.targetNamespace, sourceEnv)
+          const { copyOrganization } = require('../copy')
+
           if (sources.length === 1) {
-            await engine.main(engine.parseArgs(toEngineArgv({ ...argv, source: sources[0] })))
+            await copyOrganization({
+              organizationId: sources[0],
+              sourceEnv,
+              targetEnv,
+              reason: argv.reason,
+              dryRun: !argv.execute,
+            })
             return
           }
           // Batch: each org is a full independent copy (the engine scans the source per org). One bad uuid
@@ -108,7 +98,13 @@ module.exports = {
           for (let i = 0; i < sources.length; i++) {
             console.log(chalk.cyan(`\n──── [${i + 1}/${sources.length}] ${sources[i]} ────`))
             try {
-              await engine.main(engine.parseArgs(toEngineArgv({ ...argv, source: sources[i] })))
+              await copyOrganization({
+                organizationId: sources[i],
+                sourceEnv,
+                targetEnv,
+                reason: argv.reason,
+                dryRun: !argv.execute,
+              })
             } catch (e) {
               failed.push({ source: sources[i], error: e.message })
               console.log(chalk.red(`  FAILED: ${e.message}`))

package/lib/command/db.js

@@ -1,4 +1,5 @@
 const os = require('os')
+const fs = require('fs')
 const path = require('path')
 const chalk = require('chalk')
 const dbbuild = require('../engine/dbbuild')
@@ -7,6 +8,27 @@ const { shred } = require('../shred')
 const { auditPii } = require('../shred/audit')
 const { ensureRoles } = require('../db/roles')
 
+// Services whose schema exists but holds no tables beyond the migrations ledger — i.e. they were not in
+// the restored dump. Returns compose service names.
+async function servicesWithEmptySchema(local) {
+  const { Client } = require('pg')
+  const client = new Client({ ...local, ssl: false })
+  await client.connect()
+  try {
+    const { rows } = await client.query(`
+      SELECT n.nspname AS schema, count(t.table_name)::int AS tables
+      FROM information_schema.schemata n
+      LEFT JOIN information_schema.tables t
+        ON t.table_schema = n.schema_name AND t.table_name <> 'migrations'
+      WHERE n.schema_name LIKE 'service\\_%' AND n.schema_name NOT LIKE '%\\_history'
+      GROUP BY n.nspname HAVING count(t.table_name) = 0`)
+    // schema service_foo_bar -> compose service service-foo-bar
+    return rows.map((r) => r.schema.replace(/_/g, '-'))
+  } finally {
+    await client.end().catch(() => {})
+  }
+}
+
 // Base DB: the customer-free, anonymized artifact and local restore points. `db build` runs ONLY as an
 // in-cluster k8s Job (devs never run it); devs `db pull`. See ENVIRONMENT-PLAN.md §5.
 
@@ -96,8 +118,28 @@ module.exports = {
           await dbbuild.pull({
             local,
             download: async () => {
-              const cfg = obc.obcConfig({ namespace: argv.obcNamespace })
               const out = path.join(os.tmpdir(), 'dooer-base-db.pulled.dump')
+              // Service first — no kubectl, no ObjectBucketClaim credentials on this machine, no
+              // rook-ceph ClusterIP lookup. The service streams the artifact from inside the cluster.
+              try {
+                const remote = require('../remote')
+                const serviceClient = require('../service-client')
+                const env = remote.resolveEnv(argv.env || 'staging')
+                const list = await serviceClient.request(env, { path: '/v1/base-db/artifacts' })
+                const newest = (list.artifacts || [])[0]
+                if (!newest) throw new Error('no base-DB artifacts published yet')
+                console.log(`downloading ${newest.id} (${(newest.bytes / 1e6).toFixed(0)} MB) from ${env.label} …`)
+                const bytes = await serviceClient.request(env, {
+                  path: `/v1/base-db/artifacts/${encodeURIComponent(newest.id)}/content`,
+                  raw: true,
+                  timeoutMs: 1800000,
+                })
+                fs.writeFileSync(out, bytes)
+                return out
+              } catch (e) {
+                console.log(chalk.yellow(`service download unavailable (${e.message}); falling back to the OBC`))
+              }
+              const cfg = obc.obcConfig({ namespace: argv.obcNamespace })
               const { file, key } = await obc.download(cfg, out)
               console.log(chalk.gray(`downloaded ${cfg.bucket}/${key}`))
               return file
@@ -108,6 +150,21 @@ module.exports = {
             // Recreate the per-service schema grants + login roles + default search_path that staging has
             // (the dump carries no cluster-global roles). Without them unqualified queries 42P01. See db/roles.js.
             const { total, applied } = await ensureRoles({ local })
+
+            // A restored dump only contains the schemas that existed when it was BUILT. A service
+            // deployed since then (service-dooer-test-env was, today) has its tables wiped by the restore
+            // and never gets them back: `up` migrated into the old database, and nothing re-migrates
+            // afterwards — the symptom is a healthy container failing every query with
+            // `relation "…" does not exist`. Restart exactly those services so their start-up migration
+            // runs against the database that is actually there now.
+            const stale = await servicesWithEmptySchema(local)
+            if (stale.length) {
+              console.log(`re-migrating ${stale.length} service(s) missing from the dump…`)
+              const { migrateServices } = require('../db/migrate-stale')
+              for (const r of migrateServices(stale)) {
+                console.log(`  ${r.ok ? '✓' : '·'} ${r.service}: ${r.detail}`)
+              }
+            }
             console.log(chalk.gray(`db roles: ${applied.length}/${total} service roles provisioned`))
           }
         },