create-substrat 0.6.3 → 0.7.0

package/index.js

@@ -35,10 +35,10 @@ const TEMPLATE = join(HERE, 'template');
 // The runtime packages release together off one version line (the changesets `fixed`
 // group), so one constant is right for all of them. Engines do NOT share a line —
 // each versions on its own, so one pin per engine, deliberately.
-const SUBSTRAT = '^0.76.0';
-const ENGINE_WORKORDER = '^0.6.3';
-const ENGINE_INVOICING = '^0.7.3';
-const BOUNDARY_LINT = '^0.0.7';
+const SUBSTRAT = '^0.83.0';
+const ENGINE_WORKORDER = '^0.7.3';
+const ENGINE_INVOICING = '^0.8.3';
+const BOUNDARY_LINT = '^0.0.8';
 
 const DOCS = 'https://substrat.net';
 
@@ -93,8 +93,27 @@ function packageJson(name) {
             { binding: 'SCOPE', class: 'ScopeDO' },
             // The scope-local sweep singleton — the deployment's own timer (#461).
             { binding: 'SWEEPER', class: 'SweeperDO' },
+            // Per-instance config delivered by the platform (/internal/configure) —
+            // one DO per tenant, rows per scope. Without it the app cannot receive
+            // the settings the dashboard offers its users.
+            { binding: 'CONFIG', class: 'ConfigDO' },
           ],
         },
+        // The declared per-instance settings — MIRRORED from src/manifest.ts
+        // (`SHOP_ENV`), because `substrat push` reads JSON, not TS. The dashboard
+        // renders its Settings form from this; keep the two in sync.
+        envSpec: [
+          {
+            key: 'SHOP_NAME',
+            label: 'Workshop name',
+            description: 'The workshop name shown to customers. Set per install.',
+            placeholder: 'Söder Cykel & Service',
+            default: 'Substrat Bike Shop',
+            required: false,
+            secret: false,
+            group: 'General',
+          },
+        ],
         devServers: DEV_SERVERS,
       },
       scripts: {
@@ -150,9 +169,11 @@ const TSCONFIG = `${JSON.stringify(
       types: ['node'],
     },
     include: ['src', 'test'],
-    // The worker compiles against workers-types under its own config
-    // (tsconfig.worker.json) — the node config must not see it.
-    exclude: ['src/worker.ts'],
+    // The worker and its Cloudflare-only stores compile against workers-types
+    // under their own config (tsconfig.worker.json) — the node config must not
+    // see them. `src/routes.ts` is deliberately NOT excluded: the shared route
+    // table must typecheck under both, which is what keeps it host-agnostic.
+    exclude: ['src/worker.ts', 'src/config-do.ts'],
   },
   null,
   2,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-substrat",
-  "version": "0.6.3",
+  "version": "0.7.0",
   "description": "Scaffold a Substrat vertical — `npm create substrat <dir>`.",
   "license": "Apache-2.0",
   "repository": {

package/template/.substrat/playbook.md

@@ -277,6 +277,20 @@ Field names mirror the SQL columns, snake_case included — a prettier naming he
 description of the same rows. Not every table is an entity: an entity is something the
 platform can point at (attachments hang off one, grants narrow to one, events are about one).
 
+`primaryKey` defaults to `['id']` — declare it where the identity is something else. The side
+table you add for extra data on an engine's entity is keyed by *that engine's id*
+(`primaryKey: ['workorder_id']`); its identity IS the work order's, and an `id` of its own
+would permit two side rows for one work order. A value-keyed table is keyed by its values
+(`primaryKey: ['customer_id', 'year', 'month']`). It is separate from `key`, which is an
+additional uniqueness rule — a table legitimately has both. An entity with neither an `id`
+field nor a `primaryKey` is refused rather than emitted without one.
+
+A **composite** key means the entity cannot be pointed at: attachments, grants, link edges
+and event subjects all need one id, so naming such an entity in `parents`,
+`attachmentTargets`, `relations`, `emits.entity` or a narrowed `permission.entity` is a
+compile error. It is still a full model member with migrations and a row type. A
+single-column key that is not called `id` stays fully pointable.
+
 Behaviour stays prose in `DESIGN.md`. Inventing a way to declare a state *transition* means
 the boundary slipped.
 

package/template/AGENTS.md

@@ -44,11 +44,21 @@ src/migrations.ts      the SqlMigration[]                         ← module cod
 src/module.ts          imports both; operations + registration    ← module code
 src/provision.ts       MODULES, ROLES, grant shapes — node-free    ← module code
 src/seed.ts            host, tenants, demo cast, seed world        ← harness
-src/server.ts          thin wrapper, one route per operation       ← harness
-src/worker.ts          the deployable Cloudflare worker            ← harness
+src/routes.ts          the HTTP route table — BOTH hosts mount it   ← harness
+src/server.ts          the dev entrypoint (node + persona picker)   ← harness
+src/worker.ts          the deployable Cloudflare worker             ← harness
+src/config-do.ts       per-instance config store (Cloudflare only)  ← harness
 test/scenario.test.ts  the scenario — including the denials
 ```
 
+**A new route goes in `src/routes.ts`, never in an entrypoint.** Both `server.ts`
+and `worker.ts` mount that one table, so a route added there is live on both — and
+a route added to only one is a surface that works in dev and 404s in production
+(or the reverse), which nothing catches until you deploy: the scenario tests call
+operations directly and never boot either host. What an entrypoint may still own
+is only what is genuinely its own — building a host, resolving a caller, and its
+own auth-shaped route (`/api/cast` in dev, `/api/me` in the worker).
+
 `provision.ts` is deliberately node-free: both hosts register from it (the dev
 server's SQLite host and the worker's `ScopeDO`), and `substrat push` reads the
 permission registry from it (package.json `substrat.permissions`). Roles or
@@ -56,10 +66,23 @@ modules defined anywhere else will run locally and silently not deploy.
 `worker.ts` **mounts** the platform's `/internal/*` management contract via
 `mountPlatformSurface` from `@substrat-run/vertical-host` (one call — the routes
 and the `{ error }` envelope are authored there, not here, so they can't drift or
-ship half-done). What `worker.ts` still owns is your app routes and **the auth
-seam** — the dev `x-principal` header is the only caller resolution until you wire
-real auth there; deploying with `ALLOW_DEV_HEADER` set is a cross-tenant hole with
-a UI.
+ship half-done). What `worker.ts` still owns is **the auth seam** — the dev
+`x-principal` header is the only caller resolution until you wire real auth there;
+deploying with `ALLOW_DEV_HEADER` set is a cross-tenant hole with a UI.
+
+Among the hooks it passes, **`onConfigure` is the one you must not drop.** It is
+how per-instance settings reach the running app: the dashboard's Settings → Env
+and Identity tabs POST to `/internal/configure`, and a vertical that supplies no
+hook answers **501** to that call for its whole life — the setting is saved, the
+dashboard reports `delivered: false`, and the app never sees it. That includes the
+`substrat:auth` issuer choice, i.e. the difference between a working login and
+401-on-everything. The starter stores deliveries in `config-do.ts` and reads them
+back through `resolveScopedEnvSpec` (`instanceConfig`). Read settings that way and
+never off `env` directly: an `envSpec` default rides as a worker binding shared by
+every install of one serving script, so `env.FOO` is the same string for every
+tenant no matter what any of them saved. Declare a setting in **both**
+`src/manifest.ts` (`SHOP_ENV`) and package.json `substrat.envSpec` — `substrat
+push` reads the JSON, not the TypeScript.
 
 ## The rules (non-negotiable)
 

package/template/src/config-do.ts

@@ -0,0 +1,86 @@
+import { DurableObject } from 'cloudflare:workers';
+
+/**
+ * The key the platform delivers a scope's identity-provider choice under.
+ *
+ * It lives HERE rather than in `worker.ts` for a runtime reason worth knowing: workerd
+ * requires every named export of the entry module to be a handler or a Durable Object
+ * class, so exporting a plain constant from `worker.ts` makes the whole worker fail to
+ * boot — with a `tsc`-clean tree and a green test suite. Config vocabulary belongs with
+ * the config store anyway.
+ */
+export const AUTH_CONFIG_KEY = 'substrat:auth';
+
+/**
+ * The vertical's own per-instance CONFIG store — the durable half of
+ * `/internal/configure`.
+ *
+ * The platform delivers per-install settings (the dashboard's Settings → Env and
+ * Identity tabs) by POSTing them to `/internal/configure` on this worker. A vertical
+ * that supplies no `onConfigure` hook answers 501 to that call for its whole life:
+ * the dashboard records the setting, reports `delivered: false`, and the running app
+ * never sees it. This DO is what makes the hook answerable.
+ *
+ * It is a HARNESS store, not module code — the config a scope runs on is not domain
+ * data, and it must survive a scope-DO storage wipe (a restore, a rebind), so it
+ * deliberately lives outside the scope's own DO. One DO per TENANT, rows keyed by
+ * scope; the table matches `scope_config` in `@substrat-run/vertical-auth`'s
+ * `IdentityDO` exactly, so a project that later adopts vertical-auth for real logins
+ * swaps the binding and keeps its rows.
+ *
+ * Sandbox-clean (D-18): this is one of the deployment's OWN Durable Object classes,
+ * declared in package.json `substrat.runtimeNeeds.stores`. No control-plane binding,
+ * no service binding — the platform refuses those.
+ */
+export class ConfigDO extends DurableObject<Record<string, never>> {
+  private ready = false;
+
+  /** Lazily create the table — cheaper than a blockConcurrencyWhile on every wake. */
+  private init(): void {
+    if (this.ready) return;
+    this.ctx.storage.sql.exec(
+      `CREATE TABLE IF NOT EXISTS scope_config (
+         scope_id TEXT NOT NULL, key TEXT NOT NULL, value TEXT NOT NULL,
+         PRIMARY KEY (scope_id, key))`,
+    );
+    this.ready = true;
+  }
+
+  /**
+   * Upsert config delivered for one scope. Key-by-key rather than a replace, so a
+   * partial delivery composes with what is already there; idempotent, so the
+   * platform's reconciliation sweep can re-run it safely.
+   */
+  async setScopeConfig(scopeId: string, entries: Array<{ key: string; value: string }>): Promise<void> {
+    this.init();
+    for (const { key, value } of entries) {
+      this.ctx.storage.sql.exec(
+        'INSERT OR REPLACE INTO scope_config (scope_id, key, value) VALUES (?, ?, ?)',
+        scopeId, key, value,
+      );
+    }
+  }
+
+  /**
+   * The config delivered to one scope, as a plain map — exactly the `delivered`
+   * argument of `resolveScopedEnvSpec(spec, env, delivered)`. Reading it back is what
+   * keeps the hook from being write-only: an env-spec key set per install must be
+   * overlaid here, because env-spec defaults ride as worker bindings SHARED by every
+   * install of one serving script, so reading `env` alone always yields the shared
+   * default no matter what the tenant saved.
+   */
+  async getScopeConfig(scopeId: string): Promise<Record<string, string>> {
+    this.init();
+    const config: Record<string, string> = {};
+    for (const row of this.ctx.storage.sql.exec('SELECT key, value FROM scope_config WHERE scope_id = ?', scopeId)) {
+      config[row.key as string] = row.value as string;
+    }
+    return config;
+  }
+}
+
+/** The typed stub surface — what `worker.ts` calls across the DO boundary. */
+export interface ConfigDo {
+  setScopeConfig(scopeId: string, entries: Array<{ key: string; value: string }>): Promise<void>;
+  getScopeConfig(scopeId: string): Promise<Record<string, string>>;
+}

package/template/src/manifest.ts

@@ -1,4 +1,4 @@
-import { moduleManifest, permissionKey } from '@substrat-run/contracts';
+import { moduleManifest, permissionKey, type EnvVarSpec } from '@substrat-run/contracts';
 
 // ============================================================================
 // The vertical's MANIFEST — the reviewable contract the kernel reads at
@@ -19,6 +19,32 @@ export const SHOP_PERM = {
   bikeManage: permissionKey.parse('bike:manage'),
 };
 
+/**
+ * The vertical's DECLARED per-instance settings — the allow-list of config keys this
+ * app consumes, and what the dashboard renders a form from. A key not declared here is
+ * a key the app cannot read, however it is delivered.
+ *
+ * Read them with `resolveScopedEnvSpec(SHOP_ENV, env, delivered)` (never `env.FOO`
+ * directly): precedence is delivered > env > default, and only that overlay sees a
+ * value one tenant saved for one install — a spec `default` rides as a worker binding
+ * shared by every install of the serving script.
+ *
+ * MIRRORED in package.json `substrat.envSpec` (what `substrat push` carries — it reads
+ * JSON, not TS); keep the two in sync.
+ */
+export const SHOP_ENV: EnvVarSpec[] = [
+  {
+    key: 'SHOP_NAME',
+    label: 'Workshop name',
+    description: 'The workshop name shown to customers. Set per install.',
+    placeholder: 'Söder Cykel & Service',
+    default: 'Substrat Bike Shop',
+    required: false,
+    secret: false,
+    group: 'General',
+  },
+];
+
 export const bikeShopManifest = moduleManifest.parse({
   id: 'bikeshop',
   version: '0.0.1',
@@ -44,5 +70,6 @@ export const bikeShopManifest = moduleManifest.parse({
     { entityType: 'bike', parentType: 'customer' },
     { entityType: 'workorder', parentType: 'bike' },
   ],
+  envSpec: SHOP_ENV,
   entitlementKey: 'bikeshop',
 });

package/template/src/routes.ts

@@ -0,0 +1,140 @@
+import type { Context, Hono } from 'hono';
+import { classifyError } from '@substrat-run/vertical-host';
+import type { ScopeStub } from '@substrat-run/kernel';
+
+/**
+ * The bike shop's HTTP API — ONE route table, adapter- and auth-agnostic.
+ *
+ * Both entrypoints mount this: `server.ts` (node, pure-SQLite adapter, `x-principal`
+ * dev auth) and `worker.ts` (Cloudflare, Durable-Object adapter, the auth seam). Each
+ * supplies a `resolveStub` that authenticates the caller its own way and returns a
+ * capability `ScopeStub`; every route here is a thin wrapper over ONE operation, with
+ * no business logic — the rules live in an operation or an engine.
+ *
+ * Sharing the table is the point. A route added to only one entrypoint is a surface
+ * that exists in dev and 404s in production (or the reverse), and nothing catches it
+ * until deploy: the scenario tests call operations directly and never boot either host.
+ * Add a route HERE and it is live on both.
+ *
+ * What each entrypoint still owns is only what is genuinely its own: how it builds a
+ * host, how it resolves a caller, and its own auth-shaped routes (`/api/cast` in dev,
+ * `/api/me` in the worker) — those answer "who am I on THIS host" and cannot be shared.
+ */
+export type ResolveStub = (c: Context) => Promise<ScopeStub>;
+
+// eslint-disable-next-line @typescript-eslint/no-explicit-any
+export function mountApi(app: Hono<any, any, any>, resolveStub: ResolveStub): void {
+  const S = resolveStub;
+  const body = (c: Context) => c.req.json<Record<string, unknown>>();
+
+  /**
+   * One error vocabulary, shared with the platform surface: `classifyError`
+   * (@substrat-run/vertical-host) is the same function `mountPlatformSurface` uses, so a
+   * permission denial is 403, a missing thing 404, a broken invariant 409, a runtime
+   * fault 502 — identically on both hosts. "No opinion" becomes the caller's 400.
+   *
+   * In `worker.ts` this handler is REPLACED: Hono keeps only the last-registered
+   * `onError`, and `mountPlatformSurface` installs its own. That is harmless precisely
+   * because both are built on `classifyError` — same input, same answer. Registering it
+   * here is what gives `server.ts`, which mounts no platform surface, the same behaviour.
+   */
+  app.onError((err, c) => {
+    const seen = classifyError(err);
+    if (seen) return c.json({ error: seen.message }, seen.status);
+    return c.json({ error: err instanceof Error ? err.message : String(err) }, 400);
+  });
+
+  // -- generic invoke ---------------------------------------------------------
+  // The kernel checks a permission inside EVERY operation, so a generic route is
+  // exactly as safe as one route per operation. It is the escape hatch that keeps a
+  // new operation reachable before it has a named route — on BOTH hosts, deliberately.
+  app.post('/api/invoke', async (c) => {
+    const { op, input } = await c.req.json<{ op: string; input?: unknown }>();
+    return c.json((await (await S(c)).invoke(op, input)) ?? null);
+  });
+
+  // -- customers, bikes, price list (the vertical's own tables) ---------------
+  app.get('/api/customers', async (c) => c.json(await (await S(c)).invoke('shop/list-customers')));
+  app.post('/api/customers', async (c) =>
+    c.json(await (await S(c)).invoke('shop/create-customer', await c.req.json())),
+  );
+  app.post('/api/customers/:id/bikes', async (c) =>
+    c.json(
+      await (await S(c)).invoke('shop/register-bike', {
+        customerId: c.req.param('id'),
+        ...(await body(c)),
+      }),
+    ),
+  );
+  app.get('/api/prices', async (c) => c.json(await (await S(c)).invoke('shop/price-list')));
+  app.post('/api/prices', async (c) =>
+    c.json(await (await S(c)).invoke('shop/upsert-price', await c.req.json())),
+  );
+
+  // -- repairs ---------------------------------------------------------------
+  // create/complete/close are the VERTICAL's operations (they wrap the engine and own
+  // the pricing moment); assign/start/report/get/list are the ENGINE's own, invoked
+  // directly. Which is which is the composition boundary, visible right here.
+  app.get('/api/repairs', async (c) =>
+    c.json(await (await S(c)).invoke('workorder/list', { status: c.req.query('status') })),
+  );
+  app.post('/api/repairs', async (c) =>
+    c.json(await (await S(c)).invoke('shop/create-repair', await c.req.json())),
+  );
+  app.get('/api/repairs/:id', async (c) =>
+    c.json(await (await S(c)).invoke('workorder/get', { orderId: c.req.param('id') })),
+  );
+  app.get('/api/repairs/:id/timeline', async (c) =>
+    c.json(
+      await (await S(c)).invoke('shop/timeline', {
+        entityType: 'workorder',
+        entityId: c.req.param('id'),
+      }),
+    ),
+  );
+  app.post('/api/repairs/:id/assign', async (c) =>
+    c.json(
+      await (await S(c)).invoke('workorder/assign', {
+        orderId: c.req.param('id'),
+        ...(await body(c)),
+      }),
+    ),
+  );
+  app.post('/api/repairs/:id/start', async (c) =>
+    c.json(await (await S(c)).invoke('workorder/start', { orderId: c.req.param('id') })),
+  );
+  app.post('/api/repairs/:id/time', async (c) =>
+    c.json(
+      await (await S(c)).invoke('workorder/report-time', {
+        orderId: c.req.param('id'),
+        ...(await body(c)),
+      }),
+    ),
+  );
+  app.post('/api/repairs/:id/material', async (c) =>
+    c.json(
+      await (await S(c)).invoke('workorder/report-material', {
+        orderId: c.req.param('id'),
+        ...(await body(c)),
+      }),
+    ),
+  );
+  app.post('/api/repairs/:id/complete', async (c) =>
+    c.json(await (await S(c)).invoke('shop/complete-repair', { orderId: c.req.param('id') })),
+  );
+  app.post('/api/repairs/:id/close', async (c) =>
+    c.json(await (await S(c)).invoke('shop/close-repair', { orderId: c.req.param('id') })),
+  );
+
+  // -- the customer portal (the per-entity proof walk) ------------------------
+  app.get('/api/portal/repairs', async (c) => c.json(await (await S(c)).invoke('shop/portal-repairs')));
+
+  // -- invoicing (the sibling engine, fed by event) ---------------------------
+  app.get('/api/invoicing', async (c) => c.json(await (await S(c)).invoke('invoicing/list')));
+  app.get('/api/invoicing/:id', async (c) =>
+    c.json(await (await S(c)).invoke('invoicing/get', { underlagId: c.req.param('id') })),
+  );
+  app.post('/api/invoicing/:id/export', async (c) =>
+    c.json(await (await S(c)).invoke('invoicing/export', { underlagId: c.req.param('id') })),
+  );
+}

package/template/src/server.ts

@@ -7,12 +7,14 @@ import type { Context } from 'hono';
 import { PermissionDenied, type ScopeStub } from '@substrat-run/kernel';
 import type { PrincipalId } from '@substrat-run/contracts';
 import { buildBikeShopHost, seedBikeShop, type BikeShopWorld } from './seed.js';
+import { mountApi } from './routes.js';
 
 // ============================================================================
-// A deliberately THIN dev API. Each route authenticates (a dev principal picker
-// via the `x-principal` header — a real deployment swaps in a session), gets the
-// scope, and invokes ONE operation. There is no business logic here: every rule
-// lives in an operation or an engine.
+// The DEV entrypoint. It owns exactly three things — a SQLite host on disk, the
+// `x-principal` persona picker, and the port — and then mounts `routes.ts`, the
+// same route table `worker.ts` mounts. There is no business logic here and no
+// route here either: a route added to this file would exist in dev and 404 in
+// production, which is the one failure this split exists to prevent.
 // ============================================================================
 
 const dataDir = join(dirname(fileURLToPath(import.meta.url)), '..', '.data');
@@ -44,100 +46,13 @@ function stub(c: Context): Promise<ScopeStub> {
 
 const app = new Hono();
 
-app.onError((err, c) => {
-  const message = err instanceof Error ? err.message : String(err);
-  if (err instanceof PermissionDenied) return c.json({ error: message }, 403);
-  if (/invalid transition|immutable|already/.test(message)) return c.json({ error: message }, 409);
-  if (/not found|unknown scope|unknown operation/.test(message)) return c.json({ error: message }, 404);
-  return c.json({ error: message }, 400);
-});
-
+// The persona picker — genuinely dev-only, so it stays out of the shared table.
+// Its ABSENCE in the worker is how a client can tell it is talking to a real
+// deployment; the worker answers `/api/me` instead.
 app.get('/api/cast', (c) => c.json(CAST));
 
-// Customers, bikes, price list (the vertical's own tables).
-app.get('/api/customers', async (c) => c.json(await (await stub(c)).invoke('shop/list-customers')));
-app.post('/api/customers', async (c) =>
-  c.json(await (await stub(c)).invoke('shop/create-customer', await c.req.json())),
-);
-app.post('/api/customers/:id/bikes', async (c) =>
-  c.json(
-    await (await stub(c)).invoke('shop/register-bike', {
-      customerId: c.req.param('id'),
-      ...(await c.req.json<Record<string, unknown>>()),
-    }),
-  ),
-);
-app.get('/api/prices', async (c) => c.json(await (await stub(c)).invoke('shop/price-list')));
-app.post('/api/prices', async (c) =>
-  c.json(await (await stub(c)).invoke('shop/upsert-price', await c.req.json())),
-);
-
-// Repairs — the vertical's create/complete/close wrap the engine; assign/start/
-// report/get/list are the engine's own operations, invoked directly.
-app.get('/api/repairs', async (c) =>
-  c.json(await (await stub(c)).invoke('workorder/list', { status: c.req.query('status') })),
-);
-app.post('/api/repairs', async (c) =>
-  c.json(await (await stub(c)).invoke('shop/create-repair', await c.req.json())),
-);
-app.get('/api/repairs/:id', async (c) =>
-  c.json(await (await stub(c)).invoke('workorder/get', { orderId: c.req.param('id') })),
-);
-app.get('/api/repairs/:id/timeline', async (c) =>
-  c.json(
-    await (await stub(c)).invoke('shop/timeline', {
-      entityType: 'workorder',
-      entityId: c.req.param('id'),
-    }),
-  ),
-);
-app.post('/api/repairs/:id/assign', async (c) =>
-  c.json(
-    await (await stub(c)).invoke('workorder/assign', {
-      orderId: c.req.param('id'),
-      ...(await c.req.json<Record<string, unknown>>()),
-    }),
-  ),
-);
-app.post('/api/repairs/:id/start', async (c) =>
-  c.json(await (await stub(c)).invoke('workorder/start', { orderId: c.req.param('id') })),
-);
-app.post('/api/repairs/:id/time', async (c) =>
-  c.json(
-    await (await stub(c)).invoke('workorder/report-time', {
-      orderId: c.req.param('id'),
-      ...(await c.req.json<Record<string, unknown>>()),
-    }),
-  ),
-);
-app.post('/api/repairs/:id/material', async (c) =>
-  c.json(
-    await (await stub(c)).invoke('workorder/report-material', {
-      orderId: c.req.param('id'),
-      ...(await c.req.json<Record<string, unknown>>()),
-    }),
-  ),
-);
-app.post('/api/repairs/:id/complete', async (c) =>
-  c.json(await (await stub(c)).invoke('shop/complete-repair', { orderId: c.req.param('id') })),
-);
-app.post('/api/repairs/:id/close', async (c) =>
-  c.json(await (await stub(c)).invoke('shop/close-repair', { orderId: c.req.param('id') })),
-);
-
-// The customer portal — the per-entity proof walk.
-app.get('/api/portal/repairs', async (c) =>
-  c.json(await (await stub(c)).invoke('shop/portal-repairs')),
-);
-
-// Invoicing (the sibling engine, fed by event).
-app.get('/api/invoicing', async (c) => c.json(await (await stub(c)).invoke('invoicing/list')));
-app.get('/api/invoicing/:id', async (c) =>
-  c.json(await (await stub(c)).invoke('invoicing/get', { underlagId: c.req.param('id') })),
-);
-app.post('/api/invoicing/:id/export', async (c) =>
-  c.json(await (await stub(c)).invoke('invoicing/export', { underlagId: c.req.param('id') })),
-);
+// Everything else — including `/api/invoke` and the shared error envelope.
+mountApi(app, stub);
 
 const PORT = Number(process.env.PORT ?? 8873);
 serve({ fetch: app.fetch, port: PORT });