@cloudgrid-io/mcp 0.20.4 → 0.20.6

package/src/corpus/workflows/analytics-dashboard.md

@@ -40,7 +40,7 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 3. Scaffold
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. `plug` needs a linked
 directory, so run `init` FIRST. Then (a) write the app under **`services/web/`**,
 and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
@@ -65,7 +65,7 @@ and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
    author new yaml with it, and never set `needs:` and `requires:` together (the
    validator rejects it).
 2. Fetch the template for the Mongo wiring + aggregation shape:
-   `grid_fetch("template", "analytics-dashboard")`. It is a minimal, real
+   `grid_get_template("template", "analytics-dashboard")`. It is a minimal, real
    Next.js + `mongodb`-driver dashboard under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on an `events`
    collection, a server-component page that reads the collection and computes
@@ -85,13 +85,13 @@ before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `grid_secrets`. Non-secret config → `grid_env`.
+- API keys / secrets → `grid_set_secret`. Non-secret config → `grid_set_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` or the
   legacy `MONGODB_URL`) — the grid injects them.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/api-dashboard.md

@@ -39,7 +39,7 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 3. Scaffold
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. `plug` needs a linked
 directory, so run `init` FIRST. Then (a) write the app under **`services/web/`**,
 and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
@@ -64,7 +64,7 @@ and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
    author new yaml with it, and never set `needs:` and `requires:` together (the
    validator rejects it).
 2. Fetch the template for the Mongo wiring + CRUD shape:
-   `grid_fetch("template", "api-dashboard")`. It is a minimal, real Next.js +
+   `grid_get_template("template", "api-dashboard")`. It is a minimal, real Next.js +
    `mongodb`-driver request monitor under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on a `requests`
    collection, a server-component page that reads the log, and a client dashboard
@@ -83,13 +83,13 @@ before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `grid_secrets`. Non-secret config → `grid_env`.
+- API keys / secrets → `grid_set_secret`. Non-secret config → `grid_set_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` or the
   legacy `MONGODB_URL`) — the grid injects them.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/api-docs.md

@@ -4,7 +4,7 @@ when: API documentation, API reference, endpoint docs, REST API docs, method/par
 needs: none
 deploy: inspiration
 editions: all
-capabilities_note: static — no infrastructure. Publishes as an inspiration (instant, works on hosted) via grid_plug.
+capabilities_note: static — no infrastructure. Publishes as an inspiration (instant, works on hosted) via grid_deploy.
 summary: Fetch the api-docs template, fill it with the user's endpoints, deploy it, and return the live share URL.
 ---
 
@@ -15,7 +15,7 @@ this recipe. For prose guides or a general docs site, use `docs-site`; use this
 one when the content is an endpoint reference. Do not ask setup questions first;
 use sensible defaults and build.
 
-1. **Fetch the template.** Call `grid_fetch("template", "api-docs")` to load
+1. **Fetch the template.** Call `grid_get_template("template", "api-docs")` to load
    the self-contained HTML API reference (sidebar endpoint list, method badges,
    params tables, request/response code blocks, client-side filter).
 2. **Fill the template.** Replace the placeholders with the user's content:

package/src/corpus/workflows/api-service.md

@@ -42,7 +42,7 @@ Persistent services are owned entities.
 
 ## 3. Scaffold
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. `plug` needs a linked
 directory, so run `init` FIRST.
 
@@ -72,7 +72,7 @@ fill in `cloudgrid.yaml` to the shape below (`services.api` type `node` + `needs
    runtime. `requires:` is the deprecated v1 alias; don't author new yaml with
    it, and never set `needs:` and `requires:` together (the validator rejects it).
 2. Fetch the template for the server + Mongo shape:
-   `grid_fetch("template", "api-service")`. It is a minimal Node `http`
+   `grid_get_template("template", "api-service")`. It is a minimal Node `http`
    server under `services/api/`: it listens on `process.env.PORT || 8080` and
    serves a small REST resource (`/items` GET list / POST create / DELETE by id)
    backed by Mongo.
@@ -85,7 +85,7 @@ fill in `cloudgrid.yaml` to the shape below (`services.api` type `node` + `needs
      never at module top level, or node startup crashes** before the grid has
      injected the var.
    - Return clear JSON errors (`{ "error": "…" }`) with the right status codes.
-   - (Optional) fetch `grid_fetch("example", "api-service")` for a slightly
+   - (Optional) fetch `grid_get_template("example", "api-service")` for a slightly
      richer filled reference to imitate.
 
 ## 5. (Optional) Run locally
@@ -95,14 +95,14 @@ and hit the endpoints before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `grid_secrets`.
-- Non-secret config → `grid_env`.
+- API keys / secrets → `grid_set_secret`.
+- Non-secret config → `grid_set_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL`, or the
   legacy `MONGODB_URL` alias) — the grid injects them.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"` with a `poll_url` / entity, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/app-with-data.md

@@ -43,7 +43,7 @@ Persistent apps are owned entities.
 
 ## 3. Scaffold
 
-`grid_init` an app `<name>` (the default `--type` is fine). `init` creates
+`grid_create_project` an app `<name>` (the default `--type` is fine). `init` creates
 the entity + `.cloudgrid/link.json` and writes a `cloudgrid.yaml` with an EMPTY
 `services: {}`. `plug` needs a linked directory, so run `init` FIRST.
 
@@ -73,7 +73,7 @@ in `cloudgrid.yaml` to the shape below (`services.web` + `needs: { database: tru
    runtime. `requires:` is the deprecated v1 alias; don't author new yaml with it,
    and never set `needs:` and `requires:` together (the validator rejects it).
 2. Fetch the template for the Mongo wiring + CRUD shape:
-   `grid_fetch("template", "app-with-data")`. It is a minimal, real
+   `grid_get_template("template", "app-with-data")`. It is a minimal, real
    Next.js + `mongodb`-driver to-do app under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on a `todos`
    collection, and a page.
@@ -85,7 +85,7 @@ in `cloudgrid.yaml` to the shape below (`services.web` + `needs: { database: tru
    - **Put the DB connection behind a lazy getter — never read the connection
      string at module top level, or `next build` fails** (the module is imported
      for route analysis before the grid injects the var).
-   - (Optional) fetch `grid_fetch("example", "app-with-data")` for a slightly
+   - (Optional) fetch `grid_get_template("example", "app-with-data")` for a slightly
      richer filled reference to imitate.
 
 ## 5. (Optional) Run locally
@@ -95,15 +95,15 @@ and sanity-check before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `grid_secrets`.
-- Non-secret config → `grid_env`.
+- API keys / secrets → `grid_set_secret`.
+- Non-secret config → `grid_set_env`.
 - Do **NOT** set the DB/cache connection vars yourself (`DATABASE_MONGODB_URL`,
   `CACHE_REDIS_URL`, or their legacy `MONGODB_URL` / `REDIS_URL` aliases) — the
   grid injects them.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"` with a `poll_url` / entity, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — keep the user informed, never a

package/src/corpus/workflows/appointment-booking.md

@@ -43,18 +43,18 @@ A booking app is a built + deployed container. It requires the **local edition**
 Fetch the template and read its structure guide — this is the core of the
 workflow:
 
-- `grid_fetch("template", "appointment-booking")` — the `cloudgrid.yaml` +
+- `grid_get_template("template", "appointment-booking")` — the `cloudgrid.yaml` +
   **`AGENTS.md`**. AGENTS.md has the file tree, the Mongo collections
   (`providers`, `services`, `availability`, `appointments`), the slot-computation
   and anti-double-booking rules, the CloudGrid injection table, and the auth +
   Stripe wiring. **Read it fully before building.**
-- `grid_fetch("template", "app-with-data")` — the proven Next.js + Mongo
+- `grid_get_template("template", "app-with-data")` — the proven Next.js + Mongo
   shape this blueprint extends (lazy db client in `lib/db.js`, App-Router
   GET/POST route). Imitate its wiring.
 
 ## 4. Scaffold
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. `plug` needs a linked
 directory, so run `init` FIRST. Then write the app under **`services/web/`** and
 set `cloudgrid.yaml` to the active shape below.
@@ -101,12 +101,12 @@ never set `needs:` and `requires:` together (the validator rejects it).
 
 ## 6. Config / secrets
 
-- Auth + Stripe secrets → `grid_secrets` (set the vault items `auth-provider-key`,
+- Auth + Stripe secrets → `grid_set_secret` (set the vault items `auth-provider-key`,
   and if taking deposits `stripe-live-key`, `stripe-webhook-secret`, that the
   `vault:` block maps from). The deployer injects each as its env var at runtime
   and under `grid dev`.
 - Non-secret config (auth publishable key `NEXT_PUBLIC_...`, Stripe price ids) →
-  `grid_env` / `services.web.env`.
+  `grid_set_env` / `services.web.env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` / legacy
   `MONGODB_URL`) — the grid injects them.
 
@@ -127,7 +127,7 @@ claim reminders are live.
 
 ## 9. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/approval-workflow.md

@@ -44,18 +44,18 @@ A persistent approval app is a built + deployed container. It requires the
 ## 3. Read the blueprint
 
 Fetch the blueprint and read it before building:
-`grid_fetch("template", "approval-workflow")`. Its **`AGENTS.md`** is the
+`grid_get_template("template", "approval-workflow")`. Its **`AGENTS.md`** is the
 structure guide — the file tree (under `services/web/`), the Mongo collections
 (`users`, `requests`, `steps`, `audit`), the **state machine** (how a request
 advances / is decided across its ordered steps), how CloudGrid injects the DB
 and secrets, how to wire auth roles (and optional payments), and the deploy
 steps. Also fetch the concrete CRUD shape to adapt from:
-`grid_fetch("template", "app-with-data")` (lazy `lib/db.js`, App Router
+`grid_get_template("template", "app-with-data")` (lazy `lib/db.js`, App Router
 route, server page).
 
 ## 4. Scaffold
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. `plug` needs a linked
 directory, so run `init` FIRST. Then (a) write the app under **`services/web/`**
 following `AGENTS.md`, and (b) fill `cloudgrid.yaml` to the shape below.
@@ -110,7 +110,7 @@ before deploying. Don't require it.
 
 ## 8. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/billing-dashboard.md

@@ -43,7 +43,7 @@ A persistent billing dashboard is a built + deployed container. It requires the
 
 ## 3. Scaffold
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. `plug` needs a linked
 directory, so run `init` FIRST.
 
@@ -51,7 +51,7 @@ directory, so run `init` FIRST.
 
 This is a blueprint — the structure guide is the deliverable, not copy-paste code.
 
-1. `grid_fetch("template", "billing-dashboard")`.
+1. `grid_get_template("template", "billing-dashboard")`.
 2. **Read `AGENTS.md`** in the fetched template. It has: the file tree (app under
    `services/web/`), the Mongo collections (`customers`, `invoices`, `charges`,
    `usage_events`) and their fields, how the grid injects Mongo
@@ -94,15 +94,15 @@ This is a blueprint — the structure guide is the deliverable, not copy-paste c
 
 ## 6. Config
 
-- Stripe secrets → the vault: `grid_secrets` to set `stripe-live-key` (and a
+- Stripe secrets → the vault: `grid_set_secret` to set `stripe-live-key` (and a
   `stripe-webhook-secret` if you map one). The `vault:` block turns them into env
-  vars. Non-secret config → `grid_env`.
+  vars. Non-secret config → `grid_set_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` /
   `MONGODB_URL`) — the grid injects them.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.
@@ -111,7 +111,7 @@ response is `status: "building"`, NOT a live URL yet.
 ## 8. Wire the Stripe webhook + return the live URL
 
 1. Register `<live-url>/api/webhook` as a webhook endpoint in the Stripe dashboard,
-   copy its `whsec_…` secret into the vault, and re-`grid_plug` the SAME entity
+   copy its `whsec_…` secret into the vault, and re-`grid_deploy` the SAME entity
    if you changed the `vault:` mapping (same URL).
 2. Give the user the live dashboard URL — that is the deliverable. To iterate,
    re-plug the SAME entity so it updates the same URL.

package/src/corpus/workflows/blog-cms.md

@@ -39,7 +39,7 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 3. Scaffold
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. `plug` needs a linked
 directory, so run `init` FIRST. Then (a) write the app under **`services/web/`**,
 and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
@@ -64,7 +64,7 @@ and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
    author new yaml with it, and never set `needs:` and `requires:` together (the
    validator rejects it).
 2. Fetch the template for the Mongo wiring + CRUD shape:
-   `grid_fetch("template", "blog-cms")`. It is a minimal, real Next.js +
+   `grid_get_template("template", "blog-cms")`. It is a minimal, real Next.js +
    `mongodb`-driver blog under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on a `posts`
    collection, a server-component list page, a single-post page at
@@ -85,13 +85,13 @@ before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `grid_secrets`. Non-secret config → `grid_env`.
+- API keys / secrets → `grid_set_secret`. Non-secret config → `grid_set_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` or the
   legacy `MONGODB_URL`) — the grid injects them.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/booking-system.md

@@ -47,12 +47,12 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 3. Read the blueprint, then scaffold
 
-1. Fetch the blueprint: `grid_fetch("template", "booking-system")`. **Read its
+1. Fetch the blueprint: `grid_get_template("template", "booking-system")`. **Read its
    `AGENTS.md`** — it is the structure guide (file tree under `services/web/`, the
    `services` / `availabilityRules` / `bookings` collections + the double-booking
    guard, how CloudGrid injects the DB and vault secrets, how to wire Stripe +
    auth, and the reminder-cron design).
-2. `grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+2. `grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
    and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. `plug` needs a
    linked directory, so run `init` FIRST.
 
@@ -89,9 +89,9 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 5. Config (secrets)
 
-- Payment/auth secrets → add the vault items with `grid_secrets` (e.g.
+- Payment/auth secrets → add the vault items with `grid_set_secret` (e.g.
   `stripe-live-key`, `stripe-webhook-secret`, `auth-provider-key`) BEFORE plug so
-  the `vault:` mappings resolve. Non-secret config → `grid_env`.
+  the `vault:` mappings resolve. Non-secret config → `grid_set_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` / legacy
   `MONGODB_URL`) — the grid injects them.
 
@@ -103,7 +103,7 @@ require it.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/calendar-scheduler.md

@@ -41,7 +41,7 @@ requires the **local edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 3. Fetch the blueprint and READ AGENTS.md
 
-`grid_fetch("template", "calendar-scheduler")`. The deliverable is the
+`grid_get_template("template", "calendar-scheduler")`. The deliverable is the
 **`AGENTS.md` structure guide** — read it before writing anything. It defines:
 - the `services/web/` file tree (calendar page, event + booking routes, `lib/`),
 - the Mongo collections (`events`, `availability`, optional `bookings`) + fields,
@@ -56,7 +56,7 @@ There is no app code to copy — you generate it from the guide.
 
 ## 4. Scaffold + fill cloudgrid.yaml
 
-`grid_init` an app `<name>` FIRST (creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>` FIRST (creates the entity + `.cloudgrid/link.json`
 and a starter `cloudgrid.yaml` with empty `services:{}`; `plug` needs a linked
 directory). Then put the app under **`services/web/`** and set `cloudgrid.yaml` to
 the blueprint's active fields:
@@ -108,7 +108,7 @@ scheduler hitting an authenticated `POST /api/cron/reminders` route on `web`).
 
 - Map any secrets in the `vault:` block, then **store the values**:
   `grid secrets set auth-provider-key …`, `grid secrets set stripe-live-key sk_live_…`,
-  `grid secrets set sendgrid-key SG.…`. Non-secret public config → `grid_env`.
+  `grid secrets set sendgrid-key SG.…`. Non-secret public config → `grid_set_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` / legacy
   `MONGODB_URL`) — the grid injects them.
 
@@ -119,7 +119,7 @@ secrets) before deploying. Don't require it.
 
 ## 9. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/changelog.md

@@ -4,7 +4,7 @@ when: changelog, release notes, what's new, product updates page, version histor
 needs: none
 deploy: inspiration
 editions: all
-capabilities_note: static — no infrastructure. Publishes as an inspiration (instant, works on hosted) via grid_plug.
+capabilities_note: static — no infrastructure. Publishes as an inspiration (instant, works on hosted) via grid_deploy.
 summary: Fetch the changelog template, fill it with the user's release entries, deploy it, and return the live share URL.
 ---
 
@@ -13,7 +13,7 @@ summary: Fetch the changelog template, fill it with the user's release entries,
 Detect the intent ("build me a changelog / release notes page for X") and follow
 this recipe. Do not ask setup questions first; use sensible defaults and build.
 
-1. **Fetch the template.** Call `grid_fetch("template", "changelog")` to load
+1. **Fetch the template.** Call `grid_get_template("template", "changelog")` to load
    the self-contained HTML changelog (reverse-chronological versioned entries with
    tagged change items).
 2. **Fill the template.** Replace the placeholders with the user's content:

package/src/corpus/workflows/company-website.md

@@ -4,7 +4,7 @@ when: company website, business site, corporate site, about-us site, small-busin
 needs: none
 deploy: inspiration
 editions: all
-capabilities_note: static — no infrastructure. Publishes as an inspiration (instant, works on hosted) via grid_plug.
+capabilities_note: static — no infrastructure. Publishes as an inspiration (instant, works on hosted) via grid_deploy.
 summary: Fetch the company-website template, fill it with the user's content across hero/about/services/team/contact, deploy it, and return the live share URL.
 ---
 
@@ -14,9 +14,9 @@ Detect the intent ("build me a company website / business site / about-us page
 for X") and follow this recipe. Do not ask setup questions first; use sensible
 defaults from what the user tells you and build.
 
-1. **Fetch the template.** Call `grid_fetch("template", "company-website")` to
+1. **Fetch the template.** Call `grid_get_template("template", "company-website")` to
    load the self-contained multi-section HTML company site.
-2. **(Optional) Fetch the example.** Call `grid_fetch("example", "company-website")`
+2. **(Optional) Fetch the example.** Call `grid_get_template("example", "company-website")`
    to see a filled site as a reference for tone and structure.
 3. **Fill the template.** Replace the `{{PLACEHOLDER}}` tokens with the user's
    content, section by section:

package/src/corpus/workflows/course-platform.md

@@ -41,7 +41,7 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 3. Read the blueprint
 
-Fetch the structure guide: `grid_fetch("template", "course-platform")`. It
+Fetch the structure guide: `grid_get_template("template", "course-platform")`. It
 contains AGENTS.md — the CloudGrid-specific spec you must follow:
 
 - the file tree under `services/web/` (catalog page, course detail, gated lesson
@@ -57,7 +57,7 @@ contains AGENTS.md — the CloudGrid-specific spec you must follow:
 
 ## 4. Scaffold + fill cloudgrid.yaml
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. Run `init` FIRST —
 `plug` needs a linked directory. Then set `cloudgrid.yaml` to the shape below and
 write the app under **`services/web/`** (`path: /` is the URL mount, NOT the
@@ -101,17 +101,17 @@ rules:
 
 ## 6. Config (secrets + env)
 
-- Secrets → `grid_secrets`: `grid secrets set stripe-live-key`,
+- Secrets → `grid_set_secret`: `grid secrets set stripe-live-key`,
   `grid secrets set stripe-webhook-secret`, `grid secrets set auth-provider-key`.
   The `vault:` block injects them as `STRIPE_KEY`, `STRIPE_WEBHOOK_SECRET`,
   `AUTH_PROVIDER_KEY`.
-- Non-secret config (e.g. the auth **publishable** key) → `grid_env`.
+- Non-secret config (e.g. the auth **publishable** key) → `grid_set_env`.
 - Do **NOT** set the DB vars yourself (`DATABASE_MONGODB_URL` / legacy
   `MONGODB_URL`) — the grid injects them.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/crm.md

@@ -38,7 +38,7 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 3. Scaffold
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. `plug` needs a linked
 directory, so run `init` FIRST. Then (a) write the app under **`services/web/`**,
 and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
@@ -63,7 +63,7 @@ and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
    author new yaml with it, and never set `needs:` and `requires:` together (the
    validator rejects it).
 2. Fetch the template for the Mongo wiring + CRUD shape:
-   `grid_fetch("template", "crm")`. It is a minimal, real Next.js +
+   `grid_get_template("template", "crm")`. It is a minimal, real Next.js +
    `mongodb`-driver contact manager under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/PATCH/DELETE route on a
    `contacts` collection, a server-component page, and a client table.
@@ -72,7 +72,7 @@ and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
    fallback) — the grid injects it at dev-time and runtime.
    - **Put the DB connection behind a lazy getter — never read the connection
      string at module top level, or `next build` fails.**
-   - (Optional) fetch `grid_fetch("example", "crm")` for a richer filled
+   - (Optional) fetch `grid_get_template("example", "crm")` for a richer filled
      reference to imitate.
 
 ## 5. (Optional) Run locally
@@ -82,13 +82,13 @@ before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `grid_secrets`. Non-secret config → `grid_env`.
+- API keys / secrets → `grid_set_secret`. Non-secret config → `grid_set_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` or the
   legacy `MONGODB_URL`) — the grid injects them.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/dashboard.md

@@ -4,7 +4,7 @@ when: dashboard, metrics, KPIs, stats page, status board, charts, analytics view
 needs: none
 deploy: inspiration
 editions: all
-capabilities_note: static — no infrastructure, data is baked into the page. Publishes as an inspiration (instant, works on hosted) via grid_plug.
+capabilities_note: static — no infrastructure, data is baked into the page. Publishes as an inspiration (instant, works on hosted) via grid_deploy.
 summary: Fetch the dashboard template, fill it with the user's metrics and inline charts, deploy it, and return the live share URL.
 ---
 
@@ -13,9 +13,9 @@ summary: Fetch the dashboard template, fill it with the user's metrics and inlin
 Detect the intent ("build me a dashboard for X metrics / status") and follow
 this recipe. Do not ask setup questions first; use sensible defaults and build.
 
-1. **Fetch the template.** Call `grid_fetch("template", "dashboard")` to load
+1. **Fetch the template.** Call `grid_get_template("template", "dashboard")` to load
    the self-contained HTML dashboard template.
-2. **(Optional) Fetch the example.** Call `grid_fetch("example", "dashboard")`
+2. **(Optional) Fetch the example.** Call `grid_get_template("example", "dashboard")`
    to see a filled dashboard as a reference for structure and layout.
 3. **Fill the template.** Replace the placeholders with the user's content:
    - The dashboard title and (optional) status line.

package/src/corpus/workflows/directory.md

@@ -39,7 +39,7 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 3. Scaffold
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml` with an EMPTY `services: {}`. `plug` needs a linked
 directory, so run `init` FIRST. Then (a) write the app under **`services/web/`**,
 and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
@@ -64,7 +64,7 @@ and (b) fill `cloudgrid.yaml` to the shape below (`services.web` + `needs:
    author new yaml with it, and never set `needs:` and `requires:` together (the
    validator rejects it).
 2. Fetch the template for the Mongo wiring + CRUD shape:
-   `grid_fetch("template", "directory")`. It is a minimal, real Next.js +
+   `grid_get_template("template", "directory")`. It is a minimal, real Next.js +
    `mongodb`-driver directory under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on an
    `entries` collection, a server-component page, and a client list with search +
@@ -82,13 +82,13 @@ before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `grid_secrets`. Non-secret config → `grid_env`.
+- API keys / secrets → `grid_set_secret`. Non-secret config → `grid_set_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` or the
   legacy `MONGODB_URL`) — the grid injects them.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_deploy`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
 - Surface a liveness signal while it builds — never a bare silent wait.

package/src/corpus/workflows/docs-app.md

@@ -4,8 +4,8 @@ when: multi-page documentation SITE, developer docs portal, knowledge base, help
 needs: none
 deploy: static build
 editions: local
-capabilities_note: a built, multi-page static documentation site (Astro Starlight) — sidebar nav, client-side search, and llms.txt / llms-full.txt generated on every build. No infrastructure (no needs:). Because it BUILDS from multiple files, it deploys async and needs the local edition; the hosted MCP cannot build it. Served at the entity root via grid_plug.
-summary: Scaffold an Astro Starlight docs site from the docs-app template, fill in the content, build it, deploy the folder with grid_plug (async → poll to a live URL), then ask the user what visibility they want. llms.txt / llms-full.txt are generated automatically.
+capabilities_note: a built, multi-page static documentation site (Astro Starlight) — sidebar nav, client-side search, and llms.txt / llms-full.txt generated on every build. No infrastructure (no needs:). Because it BUILDS from multiple files, it deploys async and needs the local edition; the hosted MCP cannot build it. Served at the entity root via grid_deploy.
+summary: Scaffold an Astro Starlight docs site from the docs-app template, fill in the content, build it, deploy the folder with grid_deploy (async → poll to a live URL), then ask the user what visibility they want. llms.txt / llms-full.txt are generated automatically.
 ---
 
 # Workflow: docs-app
@@ -45,9 +45,9 @@ and builds your project.
 
 ## 3. Scaffold
 
-`grid_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_create_project` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
 and writes a `cloudgrid.yaml`. Then fetch the template:
-`grid_fetch("template", "docs-app")` — a minimal Astro Starlight project:
+`grid_get_template("template", "docs-app")` — a minimal Astro Starlight project:
 
 ```
 package.json          Astro + Starlight + starlight-llms-txt
@@ -98,7 +98,7 @@ looks for `services/site/` and fails with "Service directory not found". No
 
 ## 6. Build + deploy (async)
 
-Deploy the folder with `grid_plug`. The platform (Cloud Build) runs `npm run
+Deploy the folder with `grid_deploy`. The platform (Cloud Build) runs `npm run
 build` for you and serves the `dist/` output — you do NOT need to build first. A build deploy is **ASYNC**: the first response is
 `status: "building"` with a `poll_url` / entity, NOT a live URL yet.
 - Poll `grid_status` (or the returned poll_url) until the entity is live.
@@ -112,7 +112,7 @@ build` for you and serves the `dist/` output — you do NOT need to build first.
   `<url>/llms-full.txt` (full content), generated automatically.
 - This is a NEW deploy, so ASK the user who should be able to open it (private /
   a space / your grid / anyone with the link / anyone signed in) and set their
-  choice with `grid_visibility`. Do not pick the visibility for them.
+  choice with `grid_set_sharing`. Do not pick the visibility for them.
 
 To iterate, edit the content and re-plug the SAME entity (`target_entity_id`) so
 it updates the same URL.