@cloudgrid-io/mcp 0.16.1 → 0.17.0

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_drop.
 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_drop.
 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_drop.
 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_drop.
 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.

package/src/corpus/workflows/erp.md

@@ -39,13 +39,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 + read AGENTS.md
 
-`gridctl_fetch("template", "erp")`. It returns `cloudgrid.yaml`, `AGENTS.md` (the
+`grid_fetch("template", "erp")`. It returns `cloudgrid.yaml`, `AGENTS.md` (the
 structure guide), and the README — **no app code**. Read `AGENTS.md` end to end
 before writing anything: it defines the `services/web/` file tree, the Mongo
 collections + fields per module, how CloudGrid injects the DB and the
@@ -56,7 +56,7 @@ all four at once.
 
 ## 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) build the app under **`services/web/`**
 following `AGENTS.md`, and (b) fill `cloudgrid.yaml` to the shape below.
@@ -97,8 +97,8 @@ following `AGENTS.md`, and (b) fill `cloudgrid.yaml` to the shape below.
 ## 6. Config
 
 - Create the vault items the `vault:` block references (the auth provider's
-  backend key and the Stripe secret key) — `gridctl_secrets` / vault UI. Never
-  commit them. Publishable/front-end auth keys → `gridctl_env`.
+  backend key and the Stripe secret key) — `grid_secrets` / vault UI. Never
+  commit them. Publishable/front-end auth keys → `grid_env`.
 - Register the deployed `/api/finance/webhook` URL as the Stripe webhook endpoint
   once the app is live.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` or the
@@ -111,9 +111,9 @@ vault env vars 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/event-board.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", "event-board")`. It is a minimal, real Next.js +
+   `grid_fetch("template", "event-board")`. It is a minimal, real Next.js +
    `mongodb`-driver event board 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 events sorted by date, and a
@@ -83,15 +83,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/expense-tracker.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", "expense-tracker")`. It is a minimal, real Next.js +
+   `grid_fetch("template", "expense-tracker")`. It is a minimal, real Next.js +
    `mongodb`-driver expense tracker under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on an `expenses`
    collection, a server-component page, and a client form with a table + totals
@@ -83,15 +83,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/feature-request-board.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", "feature-request-board")`. It is a minimal, real
+   `grid_fetch("template", "feature-request-board")`. It is a minimal, real
    Next.js + `mongodb`-driver board under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/PATCH/DELETE route on a
    `requests` collection (PATCH does an atomic `$inc` upvote), a server-component
@@ -86,15 +86,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).