{"id":16386,"plugin_id":"plugin_asdk_app_6ab4ed5292d48191bc192893c8c83045","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:13:18.861Z","digest":"b25fbfeea6d54c01a2bb1a8fa6617888cd366f1514769dfaefbde206a57821f3","against":null,"payload":{"description":"Use when deploying or managing an app that uses Prisma Composer (`@prisma/composer`): wiring its services and Modules, running it locally, testing composed services, or standing up / tearing down an environment. Triggers on \"prisma composer\", \"@prisma/composer\", \"prisma app\", the `prisma-composer` CLI, `compute()`, `module()`, `contract()`, `service.load()`, `mockService`, `bootstrapService`.","included_files":[],"name":"prisma-composer-core-concepts","skill_md_contents":"---\nname: prisma-composer-core-concepts\nmetadata:\n  library: \"@prisma/composer\"\n  library_version: \"0.21.0\"\n  version: 2026.9.1\ndescription: >-\n  Use when deploying or managing an app that uses Prisma Composer\n  (`@prisma/composer`): wiring its services and Modules, running it locally,\n  testing composed services, or standing up / tearing down an environment.\n  Triggers on \"prisma composer\", \"@prisma/composer\", \"prisma app\", the\n  `prisma-composer` CLI, `compute()`, `module()`, `contract()`,\n  `service.load()`, `mockService`, `bootstrapService`.\n---\n\n# Prisma Composer core concepts\n\nA **Prisma App** is a tree of typed declarations composed in TypeScript and\nhanded to the `prisma-composer` CLI. This file covers structures,\nhierarchies, relationships, and workflows: the concepts you cannot observe\nfrom the code or the CLI's help output. It is not a CLI reference; discover\nany individual command and its flags with `--help`. Commands named here\nbelong to the `prisma-composer` CLI itself; a host CLI that embeds Composer\nmay not carry every verb, so confirm a command exists via `--help` rather\nthan inferring it. The Prisma platform moves fast, so treat this file as the\nstable conceptual core and find current, fuller documentation at\n<https://www.prisma.io/docs>. For working code, read `examples/` in the\nprisma/composer repo.\n\nTwo principles govern everything and are binding\n(`docs/design/01-principles/`):\n\n1. **Your code never reads its environment.** Dependencies, configuration,\n   credentials, and the port all arrive through the service node, typed.\n   `process.env` is never the answer.\n2. **Composer never bundles or transforms your code.** You build with your own\n   bundler; the framework assembles the built output by deterministic steps\n   and hands it to the configured deploy target.\n\n## Declarations are data\n\nEverything you author is a declaration: plain data describing a piece of the\napp, executing nothing when imported. Three node kinds exist:\n\n| Kind | Declared with | Purpose |\n| --- | --- | --- |\n| Service | `compute()` | A running unit of your code; atomic, Composer sees only its ports |\n| Resource | `rawPostgres()`, `bucket()` | A stateful managed dependency |\n| Module | `module()` | A grouping boundary; runs no code of its own, exposes typed ports |\n\nNodes connect through **ports**: `deps` declares what a node requires,\n`expose` declares what it offers. Wiring happens in a Module's builder via\n`provision()`, and the root Module, handed to the CLI, is the App:\n\n```ts\n// module.ts\nimport { module } from '@prisma/composer';\n\nexport default module('store', ({ provision }) => {\n  const catalog = provision(catalogModule);\n  provision(storefrontService, { deps: { catalog: catalog.rpc } });\n});\n```\n\nBecause ports are typed, **the compiler verifies every wire**. A dependency\nwired to the wrong producer, a missing RPC handler, a literal input value of\nthe wrong shape: all of it fails `tsc`, not the deploy. Env-bound input is\nthe exception: those values exist only at deploy, so secret-binding\nmismatches and missing platform variables surface as early deploy-time\nrefusals instead (see Two channels below). Typecheck, then build, then\ndeploy; don't use the cloud to find out whether the wiring is correct.\n\nComposer itself is target-agnostic: `@prisma/composer` carries authoring,\ntesting, and the CLI, coupled to no platform. A deploy target is an extension\nregistered in the deploy config; `@prisma/composer-prisma-cloud` is the\nPrisma Cloud target and the one this skill's deploy sections assume. Its\nroot exports `compute`, `rawPostgres`, `bucket`, `envSecret`, and\n`envParam`; the ORM vocabulary (`postgres`, `dataContract`) lives under the\n`/orm` subpath, alongside the shared `/cron`, `/storage`, `/streams`,\n`/auth`, and `/email` modules. These are the only two Composer packages a\nbasic Prisma Cloud app needs, and nothing installs them for you: a fresh\nproject starts with neither, so add both as dependencies first. An\nextension adds its own `prisma-composer-*` package alongside them. Compose\nan existing Module before implementing a capability yourself; wiring one in\nis a couple of lines.\n\nWithin the entry graph (everything reachable from `module.ts`), write\nrelative imports with explicit `.ts` extensions (`./service.ts`, with\n`allowImportingTsExtensions` in tsconfig): that form resolves everywhere.\nThe `prisma-composer` CLI also maps `./service.js` and extensionless\n`./service` to the `.ts` source, but other hosts may not.\n\n## The service node is the only doorway\n\nYour runtime code receives everything from the service declaration it\nimports:\n\n1. `service.load()`: dependencies (typed RPC clients, database bindings).\n2. `service.input()`: the whole input as one schema-validated object;\n   credentials in it are redacting `SecretString` boxes.\n3. `service.port()`: the reserved port to bind (default 3000).\n\nA service declaration is pure data; the server entry is what your build\nproduces and the platform boots:\n\n```ts\n// service.ts\nexport default compute({\n  name: 'auth',\n  deps: { db: rawPostgres() },\n  build: node({ module: import.meta.url, entry: '../dist/server.mjs' }),\n  expose: { rpc: authContract },\n});\n\n// server.ts\nconst { db } = service.load(); // { url }: you construct your own client\nconst handler = serve(service, {\n  rpc: { verify: async ({ token }) => ({ ok: token.length > 0 }) },\n});\nBun.serve({ port: service.port(), hostname: '0.0.0.0', fetch: handler });\n```\n\nThe consumer declares `deps: { auth: rpc(authContract) }` and gets a typed\nclient back from `load()`.\n\n## Two channels: dependencies and input\n\n| The value is… | Declare | Provide | Read |\n| --- | --- | --- | --- |\n| produced by another node | `deps: { db: rawPostgres() }` | wire at `provision()` | `load()` |\n| anything else (config or credential) | one field of the `input` schema | bind at `provision()`: literal, `envParam()`, or `envSecret()` | `input()` |\n\nThe service declares its whole incoming configuration, plain values and\ncredentials together, as **one [Standard Schema](https://standardschema.dev)**\n(arktype is the house choice). A credential is a field typed as\n`secretString()` from `@prisma/composer/arktype`; conditional legality (\"no\nstripe key unless billing is on\") is an ordinary schema union. The binding at\n`provision()` mirrors the schema's shape; `envSecret('NAME')` names the\nplatform variable and never carries the value.\n\nRules that bite:\n\n1. **Secretness is enforced by validation.** A literal bound where the schema\n   expects `SecretString` fails the deploy; `envSecret` bound to a plain\n   string field fails the same way.\n2. **`envParam` values arrive as raw strings**; bind them to string fields.\n   The stage's platform variable is the store; the deploying shell only seeds\n   a missing name (and the deploy fails early, naming the variable, when both\n   lack it). Changing the platform value needs a redeploy.\n3. **Absence is the schema's call.** An env-bound field whose variable is\n   unset or empty resolves to *key omitted*, which is legal only if the\n   schema allows it (optional field, union arm). The deploy report prints the\n   serialized input document (secrets ride as `{\"$secret\":\"VAR\"}` pointers)\n   and every key that resolved absent.\n4. **The reserved `port` is outside the schema.** Read it through\n   `service.port()`, never `process.env`. The framework also exports `PORT`\n   for Next.js standalone, which binds it itself.\n5. **A Module forwards a secret need without learning the platform name.**\n   Declare `secrets: { signingKey: secret() }` on the Module boundary and\n   pass the forwarded ref as a binding leaf; the parent binds the real\n   source.\n6. `input.apiKey.expose()` is the only way to a secret's value; the box\n   redacts everywhere else (logs, JSON, errors).\n\n## Contracts and RPC\n\nA contract is the typed interface through which services communicate. It\nlives with the service that owns it, typed by any Standard Schema validator,\nand both provider (`serve()`, exhaustive over the contract's methods at\ncompile time) and consumer (`rpc(contract)`) reference the same value. Calls\ntravel as RPC over HTTP. Two behaviours are provisioned for you and must not\nbe reimplemented:\n\n1. **Service keys.** At deploy, Composer mints a distinct unguessable key per\n   consumer→provider binding; `serve()` returns `401` to anything else before\n   the handler runs. Nothing in your code declares it. Consequences: don't\n   build your own service-to-service auth, and don't `curl` a deployed\n   `/rpc/<method>` to check it works. An unwired caller always gets `401`,\n   which looks like a broken deploy and isn't. Debug through a consumer, or\n   locally, where nothing is enforced. Keys are per binding (one leaking\n   can't impersonate another consumer), service-scoped (any valid key\n   reaches every method; split services to gate separately), rotated only by\n   removing the binding or destroying the stack and redeploying, and stored\n   in deploy-owned `COMPOSER_*` variables you never hand-edit.\n2. **Idempotency and retries.** Every generated-client call carries an\n   `Idempotency-Key`; dropped calls retry with backoff, and `serve()` runs\n   one call per key, replaying the completed answer to late retries. Every\n   method is therefore safely retryable and no contract declares anything\n   about it (there is no \"is this idempotent\" flag; don't invent one). A\n   handler may take an optional third argument `(input, deps, ctx)` and read\n   `ctx.idempotencyKey` (`string | undefined`) if it needs exactly-once\n   beyond one instance's memory; most don't. Locally and in tests nothing is\n   provisioned, so `serve()` passes every call through: never supply a key\n   in test inputs.\n\n## Builds are yours\n\nYou build, the framework assembles. For a plain server process, `entry` must\npoint at a single self-contained ESM file: everything inlined except runtime\nbuilt-ins (`bun`, `bun:*`, `node:*`). Deploy copies that one file and never\nships `node_modules`, so anything left un-inlined fails at boot, not at\ndeploy. Rules that bite:\n\n1. **Two services in one package means two separate builds**, one per entry.\n   A single multi-entry build splits shared code into a chunk neither output\n   contains.\n2. **A directory build uses `dir` + `entry`** (`dir` relative to the service\n   module, `entry` a file inside `dir`; `../` is an error). The tree is\n   copied verbatim, so the server must resolve siblings against\n   `import.meta.url`, not the working directory. The tree must contain no\n   symlinks: the packager rejects them, names the link, and assembly fails.\n3. **Next.js**: `next build` with `output: 'standalone'` is the whole build;\n   `nextjs({ module, appDir })` names the app root. Any page or action that\n   calls `load()` needs `export const dynamic = 'force-dynamic'`, because\n   the runtime environment doesn't exist at build time and Next ignores\n   runtime env for prerendered routes.\n4. **Always build before `deploy` or `dev`.** Neither builds for you.\n\nDeploy configuration lives in `prisma-composer.config.ts` (or `.mts`, `.mjs`,\n`.js`; nearest ancestor of the entry wins, `.ts` first within a directory).\nIt registers extensions (`prismaCloud()`, `nodeBuild()`, `nextjsBuild()` when\nthe app has a Next.js service) and the deploy-state backend\n(`prismaState()`). It is read by the CLI's operations (deploy, destroy, and\ndev; a `dev` run without one refuses, naming the missing file) and never\nimported by app code.\n\n## Databases and migrations\n\nTwo kinds of Postgres dependency:\n\n1. **`rawPostgres()`**: the binding is `{ url }` and the app owns its client.\n2. **`postgres(...)`**: a Prisma-ORM-typed database. The binding is\n   `{ url, client }` (ADR-0040): the raw connection URL plus the typed\n   client Composer constructs from your data contract, lazily on first\n   access, so queries go through `binding.client` and are compile-time\n   checked. Both `postgres` and `dataContract` import from\n   `@prisma/composer-prisma-cloud/orm`, not the package root. One\n   `dataContract`-wrapped value (emitted from `contract.prisma` by\n   `prisma contract emit`) is referenced by both the dependency end\n   (`deps: { db: postgres(catalogData) }`) and the resource end, which also\n   names the `prisma.config.ts` path so the deploy's migration step can\n   reload the emitted `contract.json` and find `migrations/`.\n\n**Deploys are replay-only**: they apply the migrations committed under\n`migrations/` and never create schema themselves. Every schema change,\nincluding the first schema of a new database, follows one loop:\n\n1. Edit `contract.prisma`.\n2. `prisma contract emit` regenerates `contract.json` + `contract.d.ts`.\n3. `prisma migration plan --name <slug>` authors the migration (on an empty\n   graph this authors the baseline).\n4. Commit `migrations/` with the change, then deploy. A fresh database\n   replays the whole path from empty.\n\nIf no authored path reaches the target contract, deploy (and `dev` against a\nstale local database) refuses with `MIGRATION_PATH_NOT_FOUND`; its message\nlists the two ways out: author the missing migration, or, when iterating\nagainst a local\ndatabase only, `prisma db update`. The tracked migration resource persists only\ncompact contract identity in deploy state; if the emitted contract artifact\nnamed by `prisma.config.ts` is missing, unreadable, or no longer matches the\ndeclared `dataContract(...)` value, deploy fails before touching the database.\nNever skip step 3 before a deploy. See `examples/store/modules/catalog` for the\ncomplete pattern.\n\n## Deploy model: converge, don't script\n\nDeploy compares the declared topology against recorded deploy state and\napplies only the difference. Re-deploying with nothing changed is a no-op;\nremoving a node removes its deployed resource. The Prisma Cloud target\nrequires exactly two environment variables: `PRISMA_SERVICE_TOKEN` and\n`PRISMA_WORKSPACE_ID`. There is no interactive login.\n\n**Stages.** A stage is an environment name chosen on the command line at\ndeploy time, never written in the topology. The identical graph deploys\neverywhere. On the Prisma Cloud target, a Prisma App is one Project and a\nstage is a Branch of it, with its own running services, its own empty\ndatabase, its own configuration. A stage name must be a valid git ref name;\nan invalid name is a hard error.\n\n**Destroy** always requires an explicit target: a bare destroy is an error,\nand naming a stage and production together is too. Destroying a stage\ndeletes its Branch after removing its resources. Destroying production\nremoves only the resources inside the production Branch, never the Branch\nitself directly; once the Project is empty it is deleted too, and that\ndeletion takes the production Branch with it. A Project still holding\nanother stage's resources is kept. Destroy never creates anything:\ndestroying a\nnever-deployed stage fails rather than standing one up.\n\n**The engine underneath is alchemy.** Convergence is executed by\n[alchemy](https://alchemy.run), a third-party infrastructure-as-code engine\nthat arrives as an ordinary, exactly-pinned npm dependency of\n`@prisma/composer` (2.0.0-beta.74 at this library version). Your code never\nimports or configures it; consult alchemy's own docs for the engine itself.\nWhat matters operationally:\n\nAlchemy is resolved from the nearest `node_modules/.bin`, including hoisted\nancestor directories. Windows resolves `alchemy.exe`, then `alchemy.cmd`,\nthen the extensionless shim; POSIX resolves `alchemy`. No global Alchemy\ninstallation is needed.\n\n1. Deploy and destroy write the pipeline's results to a generated, gitignored\n   stack file at `.prisma-composer/alchemy.run.ts`, then run the alchemy CLI\n   against it as a child process; `dev` does the same at\n   `.prisma-composer/dev/alchemy.run.ts` with local providers. The file\n   carries the computed values as literals but reads credentials via\n   `fromEnv()`, so nothing sensitive lands on disk, and it is regenerated\n   every run: output, not configuration, never edited.\n2. Failures are bisectable through that file. A failing deploy names its\n   path; running `alchemy deploy .prisma-composer/alchemy.run.ts` directly\n   separates \"the framework computed the wrong thing\" from \"the engine or\n   platform rejected the right thing\". An engine failure surfaces as\n   `DEPLOY.ENGINE_FAILED` carrying the exit code and that reproduce command;\n   the child's live output streams to the terminal either way.\n3. Destroy evaluates the same stack program as deploy, and evaluating it\n   packages the assembled bundles, so **an app must be built before it can\n   be torn down**.\n4. alchemy is why the `effect` pin exists: it resolves the `effect`\n   constellation, and a hoisted newer `effect` halts every command (failure\n   mode 1 below).\n\n**The deploy report** ends with the app's own topology: authored names, the\nplatform resource each became, and public URLs. Read ids out of it rather\nthan hunting in the Console. A URL appears only where the address is\ngenuinely public: a service prints one, a database never does, and a\nnode whose product is secret material reports no resource line at all.\n\n**Connection contract refusals.** A connection declares the values it needs\nby name; a producer that omits one fails the deploy, naming the edge, the\nparam, and what the producer did supply:\n\n```text\nConnection input \"auth.db\" declares param \"url\", but its producer \"db\" did not\nsupply it — the producer's outputs carry [host].\n```\n\nThis is a deploy-time refusal, not a broken deploy, and it can appear on an\napp whose code didn't change (the gap used to pass silently as `undefined`\nand crash the consumer at boot). Fix whichever end is wrong; don't mark the\nparam `optional` unless absent really is legal. Only reachable if you\nauthored the connection or an extension on one side.\n\n**Driving deploys from code.** `@prisma/composer/control` exposes typed\n`deploy`, `destroy`, `dev`, and `log` returning structured results. Failures\ncome back as `{ ok: false, failure }` with a dotted `failure.code` from a\nclosed registry (e.g. `ASSEMBLE.BUILD_FAILED`, `DEPLOY.ENGINE_FAILED`,\n`DEPS.EFFECT_VERSION_CONFLICT`); branch on the code, not the message. A\nnon-structured rejection out of an operation is a bug in composer, not an\nexpected failure.\n\n## Local development\n\nThe `dev` command runs the whole app on this machine, wired as it deploys,\nagainst local emulators. No cloud credentials are needed or read. Concepts\nthat surprise:\n\n1. It runs the same pipeline as deploy, so **build first**, exactly like\n   deploy. It watches built output and restarts a service when its build\n   changes.\n2. Ctrl-C stops the app's processes but leaves local databases, buckets, and\n   their data up: the next `dev` is a warm start. Starting clean, wiping\n   this app's local instances and data first, is an explicit opt-in flag.\n3. `dev` does not print service logs; `log` is a separate, read-only command\n   that follows the already-running app's merged logs. It never builds,\n   provisions, starts, or stops anything.\n4. An unset secret doesn't block a local run: it becomes a placeholder plus a\n   warning, and only the code path that spends it fails, at the external\n   service it calls.\n5. Windows isn't supported yet.\n\nLocal Postgres runs on `@prisma/dev`, which `@prisma/composer-prisma-cloud`\ndeclares as its own dependency (`^0.25.2`) and resolves from its own package.\nNothing needs adding to the app, and an app's own `@prisma/dev` (for example the\n`^0.20.0` alchemy pulls in, which crashes on any Postgres message over 64 KiB) is\nignored. If the emulator reports that `@prisma/dev` did not resolve, the install\nis broken: reinstall dependencies rather than adding `@prisma/dev` or `prisma`.\nCloud deployment and local apps without Postgres never load this runtime.\n\n## Testing is an environment seam\n\nA test is just another environment: one where you decide what `load()` and\n`input()` return, never by editing the code under test.\n\n| You want to… | Use | From |\n| --- | --- | --- |\n| Test a page / action / handler in isolation | `mockService` | `@prisma/composer/testing` |\n| Run the real boot + request path against a fake dependency | `bootstrapService` | `@prisma/composer-prisma-cloud/testing` |\n\n`mockService` returns a copy of the service whose `load()` yields your\ndoubles (type-checked against the declared deps) and whose `input()` yields\nthe object passed under the reserved `input` key (required exactly when the\nservice declares an input schema; handed over as-is, not validated). Wiring\nthe module substitution is your runner's job (`vi.mock` in Vitest,\n`mock.module` in bun test).\n\n`bootstrapService` boots the service's real built entry in-process against a\nconfig you choose; drive it over real HTTP. Gotchas:\n\n1. `service.port` must be concrete: the entry self-listens, and no\n   OS-assigned port is reported back.\n2. There is no `close()`; run each integration-test file in its own process\n   (bun test does).\n3. Next.js services take a third argument, a boot thunk, resolved with\n   `standaloneServerPath` from `@prisma/composer/nextjs/control`.\n4. A service with an input schema takes `input` in the config, a binding\n   exactly like `provision()`'s, run through the real serialize/read path.\n\nA dependency's type is its contract, so any value of that shape is a valid\ndouble: a bare object, the real client over an in-memory handler, or a real\nlocal server. Ship a dependency's fake from its own package as a `/fake`\nentry point, outside `src/`, so the fake and the real service share one\ncontract.\n\n## Building blocks and extensions\n\nFirst-party Modules ship inside `@prisma/composer-prisma-cloud` and\nprovision exactly like your own:\n\n| Import | What it provisions | Exposes |\n| --- | --- | --- |\n| `cron` from `/cron` | An always-on scheduler (it holds Compute's keep-awake guard) firing your schedule at your runner service; `input` on `cron()` binds the runner's input schema | nothing |\n| `storage` from `/storage` | An S3-backed blob store (own Postgres + minted credentials) | `store` |\n| `streams` from `/streams` | Durable append-only event streams over a `store` | `streams` |\n| `auth` from `/auth` | Signup, login, sessions, and JWT verification (Better Auth in one service, own database). `auth({ signUp: 'closed' })` makes Better Auth refuse self-service sign-up; operator-created accounts go through `admin.createUser({ email, name, password?, emailVerified? })` from a service wired to `admin` (it throws on a duplicate email and sends no mail) | `api`, `session`, `admin` |\n| `email` from `/email` | Transactional email with a stored outbox (own service and database) | `send`, `outbox` |\n\n`bucket()` (imported alongside `rawPostgres`) is a raw S3-compatible bucket:\nthe dependency end receives `{ url, bucket, accessKeyId, secretAccessKey }`,\nshape-compatible with `/storage`'s `s3()` dependency, so a service wired to\n`s3()` can be rewired to a `bucket` resource unchanged.\n\nAn extension (a package bringing its own Modules, resources, or deploy\ntarget) is published on npm as `prisma-composer-*`. The ecosystem is new:\ntoday the blocks above plus your own Modules are the whole set, so verify a\n`prisma-composer-*` package exists on npm before reaching for it.\n\n## Failure modes quick reference\n\n1. **Every `prisma-composer` command halts at start-up on an `effect`\n   version conflict** (`Dependency conflict: alchemy resolves effect@...`).\n   The app, or one of its dependencies, pins a different `effect` and the\n   package manager hoisted it over Composer's pin. Match the app's own\n   `effect` to `@prisma/composer`'s exact pin, or force it with\n   `\"overrides\": { \"effect\": \"<pin>\" }` in the app's `package.json` (yarn:\n   `resolutions`; pnpm: `pnpm.overrides`), then reinstall. A plain Composer\n   app never hits this: the public packages pin every `effect`-family\n   package alchemy would float.\n2. **A deployed `/rpc/<method>` returns `401` to anything but a wired\n   peer.** Not a broken deploy; see Contracts above.\n3. **Scale-to-zero closes idle database connections.** A persistent client\n   crashes into a 502 restart loop unless the pool is small and\n   reconnect-friendly (`new SQL({ url, max: 1, idleTimeout: 10 })` for Bun)\n   and the process logs `uncaughtException`/`unhandledRejection` instead of\n   dying. Under `dev`, add `prepare: false` as well: the local Postgres\n   is one session shared by every connection and it outlives your\n   processes, so a restarted process collides on prepared-statement\n   names (42P05) and crash-loops.\n4. **Cold starts reset service-to-service connections.** A call into a\n   scaled-to-zero service can get `ECONNRESET`; retry it.\n5. **Bind `0.0.0.0`, not loopback.** The platform routes external HTTP to\n   the VM; a loopback-only listener is unreachable.\n6. **The ingress buffers streaming responses.** An open SSE tail delivers\n   nothing and times out at 60s; don't build on streamed HTTP responses.\n7. **Naming rules fail at load, not typecheck.** Provision ids and declared\n   node names must be ASCII letters and digits only (`[A-Za-z0-9]`): they\n   derive config keys and address segments, so a hyphenated name like\n   `my-db` passes `tsc` and then fails the load. The root module's name is\n   exempt. A provision id shorter than 3 characters is rejected by the\n   platform (name the database `'database'`, not `'db'`), and a service\n   whose name equals its enclosing Module's reads as `auth.auth` unless\n   given an explicit `id`.\n8. **`MIGRATION_PATH_NOT_FOUND`**: see Databases above; author the missing\n   migration, don't skip the plan step.\n9. **Date/time columns hand back `Temporal.*` values on read.** Bun and\n   stock Node ship no global `Temporal`, so a service with `DateTime`\n   contract columns compiles and deploys, then fails on the first timestamp\n   read. Provide the global at the server entry\n   (`import 'temporal-polyfill/global'`) or use string column types.\n10. **The auth module's `/api/auth/*` returns `403 MISSING_OR_NULL_ORIGIN`\n    to a Node script.** It is the browser surface: Better Auth origin-checks\n    any request carrying a cookie, an `Origin`/`Referer`, or a `Sec-Fetch-*`\n    header, and Node's built-in `fetch` sends `Sec-Fetch-Mode` on every\n    request (the same `curl` passes). Send an `Origin` equal to the module's\n    `baseUrl`, or, for provisioning, don't use that surface at all: call\n    `admin.createUser` from a service wired to the `admin` port. A deployed\n    stack's rpc ports are reachable only from inside its graph, so the app\n    exposes its own operator route that makes that call.\n\n## What Composer doesn't do yet\n\nName the gap instead of inventing an API:\n\n1. **No interactive auth in the `prisma-composer` CLI.** Its deploys\n   authenticate only via a static\n   `PRISMA_SERVICE_TOKEN`; there is no `login` flow.\n2. **No in-memory contract bindings.** A dependency can't yet be wired to a\n   co-located handler without HTTP; use `bootstrapService` with a loopback\n   fake.\n3. **RPC over HTTP is the only contract kind.** No gRPC, WebSocket, or\n   streaming contracts.\n\nFor anything else missing, check `examples/`, `docs/design/10-domains/`, and\n`docs/design/90-decisions/` in the prisma/composer repo, then file an issue\nthere rather than guessing.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}