@cloudgrid-io/mcp 0.12.0 → 0.14.0

package/src/corpus/templates/appointment-booking/cloudgrid.yaml

@@ -0,0 +1,250 @@
+# ============================================================================
+# cloudgrid.yaml — Complete Example
+# ============================================================================
+#
+# This file shows EVERY field the platform supports, with comments explaining
+# each one. It is a reference — no real project would use all of these at once.
+#
+# STANDARD: every CloudGrid template ships its cloudgrid.yaml in THIS full form.
+# Uncomment ONLY the fields the archetype needs (always: name + services; plus
+# needs: for runtime apps). Leave everything else commented. Comments are
+# ignored by the parser, so the file deploys to exactly the active fields.
+#
+# Only two fields are required: name and services. Everything else is optional.
+# Full docs: docs/cloudgrid-yaml-reference.md
+# ============================================================================
+
+
+# ─── IDENTITY ───────────────────────────────────────────────────────────────
+
+# Entity slug (REQUIRED). 2-42 chars, lowercase alphanumeric + hyphens.
+# Must start and end with a letter or digit.
+# Becomes part of your public URL: <name>-<4hex>.<org>.cloudgrid.io
+name: appointment-booking
+
+# One-line summary. Max 280 chars. If omitted, Grid Brain auto-generates one.
+# description: Order processing API for the e-commerce platform
+
+# Single emoji or short text shown as the entity icon. Max 64 chars.
+# icon: "📦"
+
+# Entity type: 'app' (default) or 'agent'. An agent is an app with an agent: block.
+# kind: app
+
+
+# ─── NETWORKING ─────────────────────────────────────────────────────────────
+
+# Whether this entity serves public HTTP traffic.
+# true = public URL + Ingress (default). false = internal only.
+# expose: true
+
+# Additional domain names this entity serves on (the platform URL is always active).
+# custom_domains:
+#   - orders.example.com
+#   - shop.example.com
+
+
+# ─── HEALTH PROBE (entity-level override) ──────────────────────────────────
+
+# Override the default health check for the entire entity.
+# probe:
+#   path: /healthz               # HTTP path to probe (default: /).
+#   expected: "<500"             # '<500' (default), '200', '2xx'.
+
+
+# ─── DEPLOY NOTIFICATIONS ──────────────────────────────────────────────────
+
+# Slack notification to the org's default channel on deploy failure.
+# true = notify (default), false = silent.
+# notify: true
+
+
+# ─── SCALING ────────────────────────────────────────────────────────────────
+
+# Replica scaling intent.
+#   'auto'  — platform decides from the grid tier (default).
+#   'alert' — single-replica, emit a SPOF warning at plug time.
+#   1-10    — explicit replica count, clamped to the grid max.
+# scale: auto
+
+
+# ─── INFRASTRUCTURE NEEDS ──────────────────────────────────────────────────
+#
+# Declare infrastructure; the platform provisions it and injects connection
+# details as env vars. Nine needs: database, cache, kv, queue, pubsub, vector,
+# object_storage, disk, ai. Simplest form is `true`.
+#
+# needs:
+#   # database — MongoDB. Injects DATABASE_MONGODB_URL (+ legacy MONGODB_URL).
+#   #   true | pool | dedicated | { tier: external, secret: MY_DB }
+#   database: true
+#   # cache — Redis, LRU eviction (derived data). Injects CACHE_REDIS_URL (+ REDIS_URL).
+#   #   true | redis | { engine: external, secret: MY_REDIS_URL }
+#   cache: true
+#   # kv — Redis, no eviction (durable: flags, idempotency). Injects KV_REDIS_URL.
+#   kv: true
+#   # queue — Redis job-queue substrate (BullMQ). Injects QUEUE_REDIS_URL.
+#   queue: true
+#   # pubsub — Redis broadcast pub/sub. Injects PUBSUB_REDIS_URL.
+#   pubsub: true
+#   # vector — pgvector on Postgres. Injects VECTOR_PGVECTOR_URL (+ PGVECTOR_URL).
+#   #   true | pgvector | { engine: pgvector, dim: 1536 }
+#   vector: pgvector
+#   # object_storage — GCS bucket. Injects OBJECT_STORAGE_GCS_BUCKET, _GCS_REGION.
+#   #   true | { size: 10Gi }
+#   object_storage: true
+#   # disk — persistent FS mount (PVC). Injects DISK_PATH. Pins to 1 replica.
+#   #   true | { size: 1Gi, mount: /var/data }  (forbidden: /proc /sys /dev)
+#   disk: true
+#   # ai — AI Gateway via @cloudgrid-io/ai. Injects AI_GATEWAY_URL. true | false.
+#   ai: true
+
+
+# ─── INTER-ENTITY COMMUNICATION ────────────────────────────────────────────
+
+# Entities this app calls (outbound). Service-account token injected per pair.
+# calls:
+#   - org:atomic/billing-api
+
+# Inbound caller policy — who can call YOUR entity.
+# callers:
+#   policy: auto                 # 'auto' | 'manual' (default).
+#   scope: org                   # 'org' (default) | 'space' | 'explicit'.
+#   fallback: deny               # 'deny' (default) | 'warn'.
+#   # allowed_apps:              # required only when scope: explicit
+#   #   - org:atomic/frontend
+
+
+# ─── VAULT ──────────────────────────────────────────────────────────────────
+
+# Map org vault items to env vars. Keys UPPER_SNAKE_CASE; values = vault item keys.
+# Auth (so providers/clients own bookings) and optional deposit payments need
+# secrets injected as env vars — this is the CloudGrid-correct way. Set each
+# vault item once (grid secrets set), then the deployer injects it as the named
+# env var at runtime and under `grid dev`. Read them LAZILY, never top-level.
+vault:
+  AUTH_PROVIDER_KEY: auth-provider-key         # auth SDK server key (e.g. Clerk secret / Auth0 client secret)
+  STRIPE_KEY: stripe-live-key                  # Stripe secret key — optional booking deposits / prepayment
+  STRIPE_WEBHOOK_SECRET: stripe-webhook-secret # verifies Stripe webhook signatures (deposit confirmation)
+
+
+# ─── CONNECTORS AND HOOKS ──────────────────────────────────────────────────
+
+# connectors:
+#   - id: team-slack
+#     target: org                # 'system' | 'org'.
+#     channel: "#deploys"
+# hooks:
+#   - on: deploy.failed          # release.published | deploy.failed | feedback.received | entity.created
+#     via: team-slack
+#     template: "Deploy failed for {entity_name}: {error}"
+#     channel: "#alerts"
+# triggers:
+#   - from: team-slack
+#     event: message
+#     channel: "#support"
+#     route: /webhooks/slack
+
+
+# ─── LOCAL DEVELOPMENT ──────────────────────────────────────────────────────
+
+# Config for `grid dev`. Redact fields in dev data snapshots.
+# dev:
+#   snapshot:
+#     mask:
+#       - users.email
+#       - users.phone
+
+
+# ─── AGENT METADATA ────────────────────────────────────────────────────────
+
+# An agent is an app with kind: agent (above) and an agent: block.
+# agent:
+#   purpose: Sync customer data from external CRM every night
+#   schedule: "0 2 * * *"
+#   trigger: webhook
+
+
+# ─── PRIVATE RESOURCE AUTO-DEPENDENCIES ────────────────────────────────────
+
+# When true (default), private resources are auto-injected as depends_on.
+# auto_depends_on_private_requires: true
+
+
+# ─── SERVICES (REQUIRED) ───────────────────────────────────────────────────
+#
+# At least one service is required. Key = service name (slug rules).
+# Types: node, nextjs, python, static, cron.
+#
+services:
+  web:
+    # type (REQUIRED): node | nextjs | python | static | cron
+    type: nextjs
+    # HTTP route: '/' | '/api' | false (internal) | omitted (=false + warning).
+    # Only one service per entity can claim '/'.
+    path: /
+    # Container port (default 8080; read process.env.PORT). Not for cron.
+    # port: 3000
+    # nextjs only: base_image: distroless (default) | alpine
+    # base_image: distroless
+    # node only: lang: javascript (default) | typescript
+    # lang: typescript
+    # Custom source location (default services/<name>/). '.' = project root.
+    # source:
+    #   path: src/worker
+    # Health probe: false/omitted (TCP) | true (/health) | "/path" | {path,expected}
+    # health:
+    #   path: /api/health
+    #   expected: "200"
+    # Static runtime env vars (strings). Reserved: PORT, APP_NAME, SERVICE_NAME,
+    # NODE_ENV, MONGODB_URL, REDIS_URL, AI_GATEWAY_URL, N8N_WEBHOOK_URL, CLOUDGRID_*.
+    # env:
+    #   LOG_LEVEL: info
+    # Sibling services/private resources that must be Ready first (no cron, no cycles).
+    # depends_on:
+    #   - worker
+    # Per-service needs override (merges with app-level needs).
+    # needs:
+    #   queue: true
+    # Static-only build step:
+    # build:
+    #   command: npm run build
+    #   output: dist
+    #   env:
+    #     VITE_API_URL: https://api.example.com
+    # node_version: "22"          # static build step: '18'|'20'|'22'|'24' (quoted)
+    # Cron-only: schedule (REQUIRED), timezone (UTC|EST|PST), run (job | https URL)
+    # schedule: "0 9 * * 1"
+    # timezone: UTC
+    # run: job
+    # Verbose per-service persistence (prefer needs.disk):
+    # persist:
+    #   - name: scratch
+    #     path: /tmp/scratch
+    #     size: 500Mi
+
+  # ── INTENDED cron service — appointment reminders (NOT YET DEPLOYABLE) ──
+  # This design wants a scheduled job to send reminders for upcoming
+  # appointments (e.g. "24h before"). The shape below is the intended cron
+  # service. Cron deploy is a PENDING platform issue (#1543) — leave this
+  # COMMENTED until cron ships; uncommenting it today will not deploy. See
+  # AGENTS.md § "Reminders (cron — PENDING #1543)" for the intended behaviour.
+  # reminders:
+  #   type: cron
+  #   schedule: "*/15 * * * *"     # every 15 min: find appts entering the reminder window
+  #   timezone: UTC
+  #   run: job                     # runs services/reminders/ as a one-shot job per tick
+  #   # Inherits app-level needs (database) + vault (for the notification provider key).
+
+
+needs:
+  database: true
+
+
+# ============================================================================
+# NOTES
+# - NOT here: org:/entity_id: (→ .cloudgrid/link.json), secrets (→ grid secrets set),
+#   Dockerfile (platform generates from services.*.type).
+# - Deploy: grid plug   |   Local with grid resources: grid dev
+# - Full reference: docs/cloudgrid-yaml-reference.md  |  CLI: docs/cli-reference.md
+# ============================================================================

package/src/corpus/templates/appointment-booking/index.md

@@ -0,0 +1,72 @@
+# Template: appointment-booking (BLUEPRINT — Next.js + auth + Mongo, optional Stripe)
+
+An appointment / clinic / salon booking app. **Blueprint, not finished code**:
+it ships the `cloudgrid.yaml` and a structure guide (`AGENTS.md`) so an agent can
+build it correctly on CloudGrid — a Next.js app where a business defines
+providers and bookable services, publishes availability, and clients book an open
+slot, with auth so a provider owns their calendar, optional Stripe deposits, and
+grid-shared Mongo. Read `AGENTS.md`, build the app under `services/web/`, adapt
+the providers/services/slot rules, then deploy (async — poll to a live URL).
+Local edition only.
+
+**Fetch the bundle:**
+- `gridctl_fetch("template", "appointment-booking")` — this blueprint (`cloudgrid.yaml` + `AGENTS.md`).
+- `gridctl_fetch("template", "app-with-data")` — the proven Next.js + Mongo shape to extend (lazy db client, App-Router API).
+
+**Key rules:**
+
+1. **Blueprint — read `AGENTS.md` first.** It has the file tree, the Mongo
+   collections (`providers`, `services`, `availability`, `appointments`), the
+   slot-computation + anti-double-booking rules, the CloudGrid injection table,
+   and the auth + Stripe wiring. Build following it; do not invent structure.
+2. **App code MUST live under `services/web/`.** `path: /` is the URL mount, NOT
+   the filesystem path. Root files fail with `Service directory not found`.
+3. **Mongo via `needs:{database:true}`** → the grid injects
+   `DATABASE_MONGODB_URL` (legacy `MONGODB_URL` fallback). Read it LAZILY inside
+   the getter, never at module top level (top-level read fails `next build`).
+4. **Secrets via the `vault:` block** → env vars. `AUTH_PROVIDER_KEY` (and, for
+   deposits, `STRIPE_KEY` / `STRIPE_WEBHOOK_SECRET`) map to vault items; set them
+   with `gridctl_secrets`, and the deployer injects them at runtime. Read lazily;
+   do not commit keys or put secrets in `services.web.env`.
+5. **No double-booking.** `appointments` is the source of truth for "taken";
+   compute open slots as availability minus booked, re-check at write time, and
+   guard the insert with a partial unique index on `{ providerId, startAt }`.
+6. **Never set `needs:` and `requires:` together** — `requires:` is the
+   deprecated v1 alias.
+7. **Reminders (cron) are designed but PENDING platform issue #1543** — keep the
+   `reminders` cron service COMMENTED in `cloudgrid.yaml`; it is not yet
+   deployable. See AGENTS.md § 7.
+
+## cloudgrid.yaml (active fields)
+
+```yaml
+# On disk this file is the full-annotated reference (templates/_cloudgrid.yaml.reference) with EVERY
+# field present as a comment; only the fields below are uncommented, so it
+# deploys to exactly these active fields.
+name: appointment-booking
+services:
+  web:
+    type: nextjs
+    path: /
+needs:
+  database: true
+vault:
+  AUTH_PROVIDER_KEY: auth-provider-key
+  STRIPE_KEY: stripe-live-key
+  STRIPE_WEBHOOK_SECRET: stripe-webhook-secret
+```
+
+> **Capability:** `needs: { database: true }` → the deployer provisions Mongo and
+> injects `DATABASE_MONGODB_URL` (+ legacy `MONGODB_URL`). The `vault:` block maps
+> auth/Stripe secrets to env vars — the CloudGrid-correct way to inject
+> credentials. `requires:` is the deprecated v1 alias; don't mix it with `needs:`.
+> A `reminders` cron service is designed (commented) but cron deploy is PENDING
+> #1543. See the capability-map for the full injection table.
+
+## Deploy (async, local edition)
+
+`gridctl_init` first (creates the entity + link.json), write the app under
+`services/web/`, set the vault secrets with `gridctl_secrets`, `gridctl_plug`
+(async — poll `gridctl_status` to a live URL). If taking deposits, register the
+`/api/webhook` URL in Stripe and re-plug. Re-plug the same entity to update the
+same URL.

package/src/corpus/templates/approval-workflow/AGENTS.md

@@ -0,0 +1,170 @@
+# AGENTS.md — approval-workflow (blueprint)
+
+A multi-step approval system: a requester submits a **request**, it advances
+through an ordered chain of **approval steps**, each step is decided (approve /
+reject / delegate) by an assigned approver **role**, and every action is
+recorded. This is a **blueprint** — a structure guide, not app code. Read it,
+then build the Next.js + Mongo app on the grid following the shape below.
+
+The proven base shape is `app-with-data` (Next.js + Mongo, App Router, lazy DB
+getter). This blueprint extends it with a state machine, roles, and
+notifications. Fetch that template for the concrete Mongo/CRUD wiring:
+`gridctl_fetch("template", "app-with-data")`, then adapt it to the collections
+here.
+
+## 1. File tree
+
+Service code MUST live under `services/web/` — `path: /` in `cloudgrid.yaml` is
+the URL mount, NOT the filesystem path. Files at the root fail with
+`Error: Service directory not found: …/services/web`.
+
+```
+cloudgrid.yaml                               # name + services.web (nextjs) + needs:{database:true} (+ vault: for auth)
+services/web/package.json                    # next, react, react-dom, mongodb (+ auth provider SDK, + stripe if used)
+services/web/middleware.js                   # auth provider middleware — gates /dashboard + /api behind sign-in
+services/web/lib/db.js                        # lazy Mongo client from DATABASE_MONGODB_URL (legacy MONGODB_URL fallback)
+services/web/lib/workflow.js                  # state machine: advance/decide a request across its ordered steps
+services/web/lib/auth.js                       # read current user + role from the auth provider session
+services/web/lib/notify.js                     # send step-assigned / decided notifications (email/Slack connector)
+services/web/app/layout.js                     # root layout + auth provider wrapper
+services/web/app/page.js                       # server component: my requests + requests awaiting my approval
+services/web/app/request-form.js               # client: create a request, choose the approval chain
+services/web/app/requests/[id]/page.js         # server: one request, its steps, timeline, decide buttons
+services/web/app/requests/[id]/decide.js       # client: approve / reject / delegate the current step
+services/web/app/api/requests/route.js         # GET (list mine/pending) / POST (create request + seed steps)
+services/web/app/api/requests/[id]/route.js    # GET one request (with steps + audit)
+services/web/app/api/requests/[id]/decide/route.js  # POST a decision → advances the state machine
+services/web/app/api/webhooks/auth/route.js    # auth provider webhook: upsert users into the `users` collection
+```
+
+If an approval gates a payment, add
+`services/web/app/api/checkout/route.js` (create a Stripe Checkout session) and
+`services/web/app/api/webhooks/stripe/route.js` (mark the request paid on
+`checkout.session.completed`).
+
+## 2. Mongo collections
+
+The grid provisions one Mongo database (see wiring below). Model these
+collections in it:
+
+**`users`** — one per person, mirrored from the auth provider.
+- `_id` (ObjectId), `authId` (provider user id, unique), `email`, `name`,
+  `role` (enum: `requester` | `approver` | `admin`), `createdAt`.
+
+**`requests`** — one per approval request (the aggregate root).
+- `_id`, `title`, `description`, `amount` (optional, if it gates a payment),
+  `requesterId` (→ users), `status` (enum: `pending` | `approved` | `rejected`
+  | `cancelled`), `currentStep` (int, 0-based index into `steps`), `createdAt`,
+  `updatedAt`.
+
+**`steps`** — the ordered approval chain for a request (or embed as a `steps: []`
+array on the request document — either works; a separate collection scales better
+for querying "awaiting my approval").
+- `_id`, `requestId` (→ requests), `order` (int, 0-based), `approverRole`
+  (which role decides this step) or `approverId` (a specific user),
+  `status` (enum: `waiting` | `active` | `approved` | `rejected` | `skipped`),
+  `decidedBy` (→ users, nullable), `decidedAt` (nullable), `comment`.
+
+**`audit`** — append-only event log (never mutate/delete rows).
+- `_id`, `requestId`, `actorId` (→ users), `action` (enum: `created` |
+  `approved` | `rejected` | `delegated` | `cancelled`), `at`, `detail`.
+
+Suggested indexes: `requests.requesterId`, `requests.status`,
+`steps.requestId + order`, `steps.approverRole + status`, `audit.requestId + at`.
+
+## 3. The state machine (`lib/workflow.js`)
+
+The core of this blueprint. Keep the transitions in one module so both the API
+routes and the UI agree on what is legal.
+
+- **Create**: seed the `steps` for the request from the chosen chain; set
+  `steps[0].status = active`, the rest `waiting`; `request.status = pending`,
+  `request.currentStep = 0`; append `audit(created)`.
+- **Approve current step**: only the assigned role/user may decide; mark the
+  active step `approved`; if a next step exists, set it `active` and bump
+  `currentStep`; else set `request.status = approved`. Append `audit(approved)`.
+- **Reject current step**: mark it `rejected`, set `request.status = rejected`,
+  mark remaining `waiting` steps `skipped`. Append `audit(rejected)`.
+- **Delegate**: reassign the active step's `approverId` to another user, append
+  `audit(delegated)` — the step stays `active`.
+- Guard every transition against the current `status`/`currentStep` server-side;
+  never trust the client to say which step is active.
+- Fire `lib/notify.js` on step activation (notify the new approver) and on final
+  decision (notify the requester).
+
+## 4. How CloudGrid injects everything
+
+- **Mongo (the datastore):** you declare `needs: { database: true }` in
+  `cloudgrid.yaml`. You do NOT provision a DB or set a connection string. The
+  deployer provisions shared Mongo and injects the connection string as the
+  **`DATABASE_MONGODB_URL`** env var (plus the legacy **`MONGODB_URL`** alias) at
+  dev-time (`grid dev`) and at runtime (after `grid plug`). Read it in
+  `lib/db.js` via `process.env.DATABASE_MONGODB_URL || process.env.MONGODB_URL`
+  **lazily, inside the getter — never at module top level**, or `next build`
+  fails when it imports the module for route analysis before the var exists.
+- **Secrets (auth / payments) via the `vault:` block:** the CloudGrid-correct way
+  to inject secrets is the `vault:` block in `cloudgrid.yaml`, which maps a vault
+  item to an env var. This blueprint's yaml has a commented `vault:` block —
+  uncomment it and store the real value with `grid secrets set`, then the
+  deployer injects it as an env var:
+  ```yaml
+  vault:
+    AUTH_PROVIDER_KEY: auth-provider-secret-key   # → process.env.AUTH_PROVIDER_KEY
+    # STRIPE_KEY: stripe-live-key                  # → process.env.STRIPE_KEY (if a step gates a payment)
+    # SENDGRID_API_KEY: sendgrid-key               # → process.env.SENDGRID_API_KEY (email notifications)
+  ```
+  Do NOT hardcode keys and do NOT set `DATABASE_MONGODB_URL`/`MONGODB_URL`
+  yourself — the grid injects the DB vars.
+- **AI (optional):** if you add AI (e.g. auto-summarize a request), declare
+  `needs: { ai: true }`; the grid injects **`AI_GATEWAY_URL`** and you call it
+  through `@cloudgrid-io/ai`.
+- **Non-secret config** → `grid env`. **Secrets** → `grid secrets set` (mapped by
+  `vault:`).
+
+## 5. Wiring auth (roles) and payments
+
+**Auth + roles (required — approvals need to know who you are):**
+1. Add an auth provider SDK to `package.json` (e.g. `@clerk/nextjs` or the Auth0
+   Next.js SDK).
+2. Put the provider's publishable key in `services/web/app/layout.js` (client
+   wrapper) and the secret key in `process.env.AUTH_PROVIDER_KEY` (from the
+   `vault:` block — never inline it).
+3. `services/web/middleware.js` gates `/dashboard`, `/requests/*`, and `/api/*`
+   behind sign-in.
+4. `lib/auth.js` reads the current user + `role` from the session; the state
+   machine uses `role` to decide who may approve a given step.
+5. `app/api/webhooks/auth/route.js` receives the provider's user-created/updated
+   webhook and upserts the person into the `users` collection with a default
+   `role: requester`.
+
+**Payments (optional — only if an approved request triggers a charge):**
+1. Add `stripe` to `package.json`; put the key in `STRIPE_KEY` via `vault:`.
+2. `app/api/checkout/route.js` creates a Checkout session after the request
+   reaches `approved`.
+3. `app/api/webhooks/stripe/route.js` verifies the signature and, on
+   `checkout.session.completed`, records payment on the `requests` document.
+
+## 6. Deploy steps
+
+1. `gridctl_init` an app `<name>` — creates the entity, `.cloudgrid/link.json`,
+   and a `cloudgrid.yaml` with an empty `services: {}`. Run `init` FIRST because
+   `plug` needs a linked directory.
+2. Fill `cloudgrid.yaml` to this blueprint's shape (copy this template's file):
+   `services.web { type: nextjs, path: / }` + `needs: { database: true }` +
+   (uncomment) the `vault:` block for `AUTH_PROVIDER_KEY`.
+3. Write the app under `services/web/` following the file tree above.
+4. `grid secrets set` the auth provider key (and Stripe/SendGrid keys if used);
+   they are injected via the `vault:` mapping.
+5. (Optional) `grid dev` to run locally against injected Mongo before deploying.
+6. `grid plug` to deploy. A runtime deploy is **async** — the first response is
+   `status: building`, not a live URL. Poll `grid status` (surface a liveness
+   signal, never a bare silent wait) until it is live, then return the live app
+   URL. Re-plug the SAME entity to update the same URL.
+
+## 7. Edition note
+
+This is a built + deployed container (a **runtime** app), so it requires the
+**local edition** (Claude Code / Claude Desktop) or the CLI. The **hosted**
+edition (Claude Web / hosted MCP) is inline-only and can publish only static
+pages — it CANNOT build this runtime app. On hosted, tell the user plainly and
+offer a static mock instead; do not attempt the runtime path there.

package/src/corpus/templates/approval-workflow/README.md

@@ -0,0 +1,12 @@
+# approval-workflow template (blueprint)
+
+A multi-step approval system: a requester submits a request, it advances through
+an ordered chain of approval steps decided by assigned roles (approve / reject /
+delegate), every action is recorded in an append-only audit log, and approvers
+are notified as each step activates. It is a persistent Next.js + Mongo runtime
+app (declares `needs: { database: true }`, extends the proven `app-with-data`
+shape) with auth-provider roles wired through a `vault:` secret. This is a
+**blueprint: structure + cloudgrid.yaml — adapt and build.** Read `AGENTS.md`
+for the full file tree, Mongo collections, the state machine, CloudGrid wiring
+(DB injection, `vault:` secrets, deploy), then build the app following it. There
+is no shipped app code here.