@cloudgrid-io/mcp 0.16.2 → 0.18.0

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

@@ -36,14 +36,14 @@ the CLI and folder-plug your project.
 ## 2. Auth + grid
 
 Persistent apps are owned entities.
-1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_login`.
+1. Ensure signed in: `grid_login_status`; if not, `grid_login`.
 2. A grid is required. Respect the grid picker: if the user has more than one
    grid, ask which to use (per the existing `resolveGridOrAsk` behavior); do not
    assume a target.
 
 ## 3. Scaffold
 
-`gridctl_init` an app `<name>` (the default `--type` is fine). `init` creates
+`grid_init` 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:
-   `gridctl_fetch("template", "app-with-data")`. It is a minimal, real
+   `grid_fetch("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 `gridctl_fetch("example", "app-with-data")` for a slightly
+   - (Optional) fetch `grid_fetch("example", "app-with-data")` for a slightly
      richer filled reference to imitate.
 
 ## 5. (Optional) Run locally
@@ -95,17 +95,17 @@ and sanity-check before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `gridctl_secrets`.
-- Non-secret config → `gridctl_env`.
+- API keys / secrets → `grid_secrets`.
+- Non-secret config → `grid_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 `gridctl_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"` with a `poll_url` / entity, NOT a live URL yet.
-- Poll `gridctl_status` (or the returned poll_url) until the entity is live.
+- 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
   bare silent wait.
 - Only once it is live, return the deployed URL (the app URL, NOT the build/log

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

@@ -34,7 +34,7 @@ A booking app is a built + deployed container. It requires the **local edition**
 
 ## 2. Auth + grid
 
-1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_login`.
+1. Ensure signed in: `grid_login_status`; if not, `grid_login`.
 2. A grid is required. Respect the grid picker: if the user has more than one
    grid, ask which to use; do not assume a target.
 
@@ -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:
 
-- `gridctl_fetch("template", "appointment-booking")` — the `cloudgrid.yaml` +
+- `grid_fetch("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.**
-- `gridctl_fetch("template", "app-with-data")` — the proven Next.js + Mongo
+- `grid_fetch("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
 
-`gridctl_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_init` 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 → `gridctl_secrets` (set the vault items `auth-provider-key`,
+- Auth + Stripe secrets → `grid_secrets` (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) →
-  `gridctl_env` / `services.web.env`.
+  `grid_env` / `services.web.env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` / legacy
   `MONGODB_URL`) — the grid injects them.
 
@@ -127,9 +127,9 @@ claim reminders are live.
 
 ## 9. Deploy (async)
 
-Deploy the folder with `gridctl_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
-- Poll `gridctl_status` (or the returned poll_url) until the entity is live.
+- 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.
 - If taking deposits, once live register the `/api/webhook` URL as the Stripe
   webhook endpoint, copy the signing secret into the `stripe-webhook-secret`

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

@@ -37,25 +37,25 @@ A persistent approval app is a built + deployed container. It requires the
 
 ## 2. Auth + grid
 
-1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_login`.
+1. Ensure signed in: `grid_login_status`; if not, `grid_login`.
 2. A grid is required. Respect the grid picker: if the user has more than one
    grid, ask which to use; do not assume a target.
 
 ## 3. Read the blueprint
 
 Fetch the blueprint and read it before building:
-`gridctl_fetch("template", "approval-workflow")`. Its **`AGENTS.md`** is the
+`grid_fetch("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:
-`gridctl_fetch("template", "app-with-data")` (lazy `lib/db.js`, App Router
+`grid_fetch("template", "app-with-data")` (lazy `lib/db.js`, App Router
 route, server page).
 
 ## 4. Scaffold
 
-`gridctl_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_init` 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,9 +110,9 @@ before deploying. Don't require it.
 
 ## 8. Deploy (async)
 
-Deploy the folder with `gridctl_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
-- Poll `gridctl_status` (or the returned poll_url) until the entity is live.
+- 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.
 - Only once it is live, return the deployed app URL (NOT the build/log link).
 

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

@@ -37,13 +37,13 @@ A persistent billing dashboard is a built + deployed container. It requires the
 
 ## 2. Auth + grid
 
-1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_login`.
+1. Ensure signed in: `grid_login_status`; if not, `grid_login`.
 2. A grid is required. Respect the grid picker: if the user has more than one grid,
    ask which to use; do not assume a target.
 
 ## 3. Scaffold
 
-`gridctl_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_init` 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. `gridctl_fetch("template", "billing-dashboard")`.
+1. `grid_fetch("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,24 +94,24 @@ This is a blueprint — the structure guide is the deliverable, not copy-paste c
 
 ## 6. Config
 
-- Stripe secrets → the vault: `gridctl_secrets` to set `stripe-live-key` (and a
+- Stripe secrets → the vault: `grid_secrets` 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 → `gridctl_env`.
+  vars. Non-secret config → `grid_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 `gridctl_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
-- Poll `gridctl_status` (or the returned poll_url) until the entity is live.
+- 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.
 - Only once it is live, return the deployed app URL (NOT the build/log link).
 
 ## 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-`gridctl_plug` the SAME entity
+   copy its `whsec_…` secret into the vault, and re-`grid_plug` 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

@@ -33,13 +33,13 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 2. Auth + grid
 
-1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_login`.
+1. Ensure signed in: `grid_login_status`; if not, `grid_login`.
 2. A grid is required. Respect the grid picker: if the user has more than one
    grid, ask which to use; do not assume a target.
 
 ## 3. Scaffold
 
-`gridctl_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_init` 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:
-   `gridctl_fetch("template", "blog-cms")`. It is a minimal, real Next.js +
+   `grid_fetch("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,15 +85,15 @@ before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `gridctl_secrets`. Non-secret config → `gridctl_env`.
+- API keys / secrets → `grid_secrets`. Non-secret config → `grid_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 `gridctl_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
-- Poll `gridctl_status` (or the returned poll_url) until the entity is live.
+- 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.
 - Only once it is live, return the deployed app URL (NOT the build/log link).
 

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

@@ -41,18 +41,18 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 2. Auth + grid
 
-1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_login`.
+1. Ensure signed in: `grid_login_status`; if not, `grid_login`.
 2. A grid is required. Respect the grid picker: if the user has more than one
    grid, ask which to use; do not assume a target.
 
 ## 3. Read the blueprint, then scaffold
 
-1. Fetch the blueprint: `gridctl_fetch("template", "booking-system")`. **Read its
+1. Fetch the blueprint: `grid_fetch("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. `gridctl_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+2. `grid_init` 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 `gridctl_secrets` (e.g.
+- Payment/auth secrets → add the vault items with `grid_secrets` (e.g.
   `stripe-live-key`, `stripe-webhook-secret`, `auth-provider-key`) BEFORE plug so
-  the `vault:` mappings resolve. Non-secret config → `gridctl_env`.
+  the `vault:` mappings resolve. Non-secret config → `grid_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` / legacy
   `MONGODB_URL`) — the grid injects them.
 
@@ -103,9 +103,9 @@ require it.
 
 ## 7. Deploy (async)
 
-Deploy the folder with `gridctl_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
-- Poll `gridctl_status` (or the returned poll_url) until the entity is live.
+- 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.
 - Only once it is live, return the deployed app URL (NOT the build/log link).
 

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

@@ -35,13 +35,13 @@ requires the **local edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 2. Auth + grid
 
-1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_login`.
+1. Ensure signed in: `grid_login_status`; if not, `grid_login`.
 2. A grid is required. Respect the grid picker: if the user has more than one
    grid, ask which to use; do not assume a target.
 
 ## 3. Fetch the blueprint and READ AGENTS.md
 
-`gridctl_fetch("template", "calendar-scheduler")`. The deliverable is the
+`grid_fetch("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
 
-`gridctl_init` an app `<name>` FIRST (creates the entity + `.cloudgrid/link.json`
+`grid_init` 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 → `gridctl_env`.
+  `grid secrets set sendgrid-key SG.…`. Non-secret public config → `grid_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` / legacy
   `MONGODB_URL`) — the grid injects them.
 
@@ -119,9 +119,9 @@ secrets) before deploying. Don't require it.
 
 ## 9. Deploy (async)
 
-Deploy the folder with `gridctl_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
-- Poll `gridctl_status` (or the returned poll_url) until the entity is live.
+- 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.
 - Only once it is live, return the deployed app URL (NOT the build/log link).
 

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 gridctl_drop.
+capabilities_note: static — no infrastructure. Publishes as an inspiration (instant, works on hosted) via grid_plug.
 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 `gridctl_fetch("template", "changelog")` to load
+1. **Fetch the template.** Call `grid_fetch("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:
@@ -25,7 +25,7 @@ this recipe. Do not ask setup questions first; use sensible defaults and build.
      stylesheets, fonts, or large embedded media.
 3. **Deploy.** Deploy the filled HTML:
    - Hosted MCP edition: call the drop tool with the HTML.
-   - Local MCP / CLI edition: write the HTML to a file and run `gridctl plug`.
+   - Local MCP / CLI edition: write the HTML to a file and run `grid plug`.
    It is an inspiration and deploys synchronously, so you get a URL right away.
 4. **Return the live share URL.** For revisions, re-deploy with the entity id
    from the first deploy — it updates the same share URL.

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 gridctl_drop.
+capabilities_note: static — no infrastructure. Publishes as an inspiration (instant, works on hosted) via grid_plug.
 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 `gridctl_fetch("template", "company-website")` to
+1. **Fetch the template.** Call `grid_fetch("template", "company-website")` to
    load the self-contained multi-section HTML company site.
-2. **(Optional) Fetch the example.** Call `gridctl_fetch("example", "company-website")`
+2. **(Optional) Fetch the example.** Call `grid_fetch("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:
@@ -34,7 +34,7 @@ defaults from what the user tells you and build.
      variables (`--accent`, `--bg`, `--fg`) if the user has brand colors.
 4. **Deploy.** Deploy the filled HTML:
    - Hosted MCP edition: call the drop tool with the HTML.
-   - Local MCP / CLI edition: write the HTML to a file and run `gridctl plug`.
+   - Local MCP / CLI edition: write the HTML to a file and run `grid plug`.
    A company website is an inspiration and deploys synchronously, so you get a
    URL right away.
 5. **Return the live share URL.** Give the user the URL that serves the page.

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

@@ -35,13 +35,13 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 2. Auth + grid
 
-1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_login`.
+1. Ensure signed in: `grid_login_status`; if not, `grid_login`.
 2. A grid is required. Respect the grid picker: if the user has more than one
    grid, ask which to use; do not assume a target.
 
 ## 3. Read the blueprint
 
-Fetch the structure guide: `gridctl_fetch("template", "course-platform")`. It
+Fetch the structure guide: `grid_fetch("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
 
-`gridctl_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_init` 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,19 +101,19 @@ rules:
 
 ## 6. Config (secrets + env)
 
-- Secrets → `gridctl_secrets`: `grid secrets set stripe-live-key`,
+- Secrets → `grid_secrets`: `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) → `gridctl_env`.
+- Non-secret config (e.g. the auth **publishable** key) → `grid_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 `gridctl_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
-- Poll `gridctl_status` (or the returned poll_url) until the entity is live.
+- 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.
 - Only once it is live, return the deployed app URL (NOT the build/log link).
 

package/src/corpus/workflows/crm.md

@@ -32,13 +32,13 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 2. Auth + grid
 
-1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_login`.
+1. Ensure signed in: `grid_login_status`; if not, `grid_login`.
 2. A grid is required. Respect the grid picker: if the user has more than one
    grid, ask which to use; do not assume a target.
 
 ## 3. Scaffold
 
-`gridctl_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_init` 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:
-   `gridctl_fetch("template", "crm")`. It is a minimal, real Next.js +
+   `grid_fetch("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 `gridctl_fetch("example", "crm")` for a richer filled
+   - (Optional) fetch `grid_fetch("example", "crm")` for a richer filled
      reference to imitate.
 
 ## 5. (Optional) Run locally
@@ -82,15 +82,15 @@ before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `gridctl_secrets`. Non-secret config → `gridctl_env`.
+- API keys / secrets → `grid_secrets`. Non-secret config → `grid_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 `gridctl_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
-- Poll `gridctl_status` (or the returned poll_url) until the entity is live.
+- 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.
 - Only once it is live, return the deployed app URL (NOT the build/log link).
 

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 gridctl_drop.
+capabilities_note: static — no infrastructure, data is baked into the page. Publishes as an inspiration (instant, works on hosted) via grid_plug.
 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 `gridctl_fetch("template", "dashboard")` to load
+1. **Fetch the template.** Call `grid_fetch("template", "dashboard")` to load
    the self-contained HTML dashboard template.
-2. **(Optional) Fetch the example.** Call `gridctl_fetch("example", "dashboard")`
+2. **(Optional) Fetch the example.** Call `grid_fetch("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.
@@ -27,7 +27,7 @@ this recipe. Do not ask setup questions first; use sensible defaults and build.
      stylesheets, fonts, or large embedded media.
 4. **Deploy.** Deploy the filled HTML:
    - Hosted MCP edition: call the drop tool with the HTML.
-   - Local MCP / CLI edition: write the HTML to a file and run `gridctl plug`.
+   - Local MCP / CLI edition: write the HTML to a file and run `grid plug`.
    A dashboard is an inspiration and deploys synchronously, so you get a URL
    right away.
 5. **Return the live share URL.** Give the user the URL that serves the dashboard.

package/src/corpus/workflows/directory.md

@@ -33,13 +33,13 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 
 ## 2. Auth + grid
 
-1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_login`.
+1. Ensure signed in: `grid_login_status`; if not, `grid_login`.
 2. A grid is required. Respect the grid picker: if the user has more than one
    grid, ask which to use; do not assume a target.
 
 ## 3. Scaffold
 
-`gridctl_init` an app `<name>`. `init` creates the entity + `.cloudgrid/link.json`
+`grid_init` 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:
-   `gridctl_fetch("template", "directory")`. It is a minimal, real Next.js +
+   `grid_fetch("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,15 +82,15 @@ before deploying. Don't require it.
 
 ## 6. Config
 
-- API keys / secrets → `gridctl_secrets`. Non-secret config → `gridctl_env`.
+- API keys / secrets → `grid_secrets`. Non-secret config → `grid_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 `gridctl_plug`. A **runtime deploy is ASYNC**: the first
+Deploy the folder with `grid_plug`. A **runtime deploy is ASYNC**: the first
 response is `status: "building"`, NOT a live URL yet.
-- Poll `gridctl_status` (or the returned poll_url) until the entity is live.
+- 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.
 - Only once it is live, return the deployed app URL (NOT the build/log link).
 

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

@@ -4,7 +4,7 @@ when: documentation site, docs, developer docs, guide, manual, knowledge base, h
 needs: none
 deploy: inspiration
 editions: all
-capabilities_note: static — no infrastructure, content baked into the page. Publishes as an inspiration (instant, works on hosted) via gridctl_drop.
+capabilities_note: static — no infrastructure, content baked into the page. Publishes as an inspiration (instant, works on hosted) via grid_plug.
 summary: Fetch the docs-site template, fill it with the user's documentation, deploy it, and return the live share URL.
 ---
 
@@ -14,7 +14,7 @@ Detect the intent ("build me a docs site / documentation for X") and follow this
 recipe. For a REST API endpoint reference specifically, use `api-docs`. Do not
 ask setup questions first; use sensible defaults and build.
 
-1. **Fetch the template.** Call `gridctl_fetch("template", "docs-site")` to load
+1. **Fetch the template.** Call `grid_fetch("template", "docs-site")` to load
    the self-contained HTML docs layout (sidebar nav, content column, code blocks,
    client-side search box).
 2. **Fill the template.** Replace the placeholders with the user's content:
@@ -27,7 +27,7 @@ ask setup questions first; use sensible defaults and build.
      stylesheets, fonts, or large embedded media.
 3. **Deploy.** Deploy the filled HTML:
    - Hosted MCP edition: call the drop tool with the HTML.
-   - Local MCP / CLI edition: write the HTML to a file and run `gridctl plug`.
+   - Local MCP / CLI edition: write the HTML to a file and run `grid plug`.
    It is an inspiration and deploys synchronously, so you get a URL right away.
 4. **Return the live share URL.** For revisions, re-deploy with the entity id
    from the first deploy — it updates the same share URL.