@cloudgrid-io/mcp 0.16.2 → 0.18.0

package/src/corpus/templates/restaurant-reservations/index.md

@@ -20,7 +20,7 @@ app under `services/web/` following it — the proven `app-with-data` shape with
    `MONGODB_URL` fallback — the grid injects it; never hardcode, never commit.
 3. **Third-party secrets go through the `vault:` block** (Stripe `STRIPE_KEY`,
    email `SENDGRID_API_KEY`, optional `AUTH_PROVIDER_KEY`) → injected env vars;
-   store values with `gridctl_secrets`.
+   store values with `grid_secrets`.
 4. **Declare `needs: { database: true }`** (canonical) — never mix `needs:` and
    `requires:`.
 5. **Cron reminder service is documented but NOT deployable yet** (platform issue
@@ -29,7 +29,7 @@ app under `services/web/` following it — the proven `app-with-data` shape with
 ## Fetch bundle
 
 ```
-gridctl_fetch("template", "restaurant-reservations")   # cloudgrid.yaml + AGENTS.md + README
+grid_fetch("template", "restaurant-reservations")   # cloudgrid.yaml + AGENTS.md + README
 ```
 
 Then read `AGENTS.md` (file tree, `menu`/`reservations`/`tables` collections,

package/src/corpus/templates/saas-marketing/README.md

@@ -3,12 +3,12 @@
 A single self-contained HTML SaaS marketing site (hero, features, pricing tiers, testimonials, FAQ, and a closing call to action). Richer than the landing-page template.
 
 Static inspiration — a single self-contained `index.html` (inline CSS and JS,
-no external CDNs). It deploys instantly via `gridctl_drop` and works on every
+no external CDNs). It deploys instantly via `grid_plug` and works on every
 CloudGrid edition, including hosted.
 
 ## Fill it in
 
-Fetch the template with `gridctl_fetch("template", "saas-marketing")`, then replace the
+Fetch the template with `grid_fetch("template", "saas-marketing")`, then replace the
 placeholders:
 
    - The product name, tagline, and hero eyebrow/headline/subheadline.
@@ -24,7 +24,7 @@ stylesheets, fonts, or large embedded media.
 ## Deploy
 
 - 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 deploys as an inspiration and returns a live share URL right away. Re-deploy
 with the same entity id to update the same URL.

package/src/corpus/templates/saas-marketing/index.md

@@ -5,14 +5,13 @@ State (if any) lives only in memory and is lost on refresh.
 
 ## How it deploys
 
-To publish this page, use **`gridctl_drop`** (or `gridctl_plug` with the inline
-HTML): it deploys as an **inspiration** — instant, and works on the **hosted**
+To publish this page, use **`grid_plug`** with the inline `html`: it deploys as an **inspiration** — instant, and works on the **hosted**
 edition (Claude Web) as well as local. The reference `cloudgrid.yaml` in this
 directory (`type: static`) is ONLY for plugging the page as an OWNED static
-runtime (async, local edition only); the fast path is `gridctl_drop`.
+runtime (async, local edition only); the fast path is `grid_plug`.
 
 The fillable HTML is the real template — fetch it with
-`gridctl_fetch("template", "saas-marketing")` and fill in the user's content.
+`grid_fetch("template", "saas-marketing")` and fill in the user's content.
 
 ## cloudgrid.yaml (reference only)
 

package/src/corpus/templates/status-page/README.md

@@ -3,12 +3,12 @@
 A single self-contained HTML service status page: an overall banner, a component list with up / degraded / down pills, per-component uptime bars, and an incident history log. Status is baked into the page.
 
 Static inspiration — a single self-contained `index.html` (inline CSS and JS,
-no external CDNs). It deploys instantly via `gridctl_drop` and works on every
+no external CDNs). It deploys instantly via `grid_plug` and works on every
 CloudGrid edition, including hosted.
 
 ## Fill it in
 
-Fetch the template with `gridctl_fetch("template", "status-page")`, then replace the
+Fetch the template with `grid_fetch("template", "status-page")`, then replace the
 placeholders:
 
    - The overall status banner text and state class (`ok` / `degraded` / `down`).
@@ -22,7 +22,7 @@ stylesheets, fonts, or large embedded media.
 ## Deploy
 
 - 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 deploys as an inspiration and returns a live share URL right away. Re-deploy
 with the same entity id to update the same URL.

package/src/corpus/templates/status-page/index.md

@@ -5,14 +5,13 @@ State (if any) lives only in memory and is lost on refresh.
 
 ## How it deploys
 
-To publish this page, use **`gridctl_drop`** (or `gridctl_plug` with the inline
-HTML): it deploys as an **inspiration** — instant, and works on the **hosted**
+To publish this page, use **`grid_plug`** with the inline `html`: it deploys as an **inspiration** — instant, and works on the **hosted**
 edition (Claude Web) as well as local. The reference `cloudgrid.yaml` in this
 directory (`type: static`) is ONLY for plugging the page as an OWNED static
-runtime (async, local edition only); the fast path is `gridctl_drop`.
+runtime (async, local edition only); the fast path is `grid_plug`.
 
 The fillable HTML is the real template — fetch it with
-`gridctl_fetch("template", "status-page")` and fill in the user's content.
+`grid_fetch("template", "status-page")` and fill in the user's content.
 
 ## cloudgrid.yaml (reference only)
 

package/src/corpus/templates/subscription-management/AGENTS.md

@@ -18,7 +18,7 @@ The two share the same Stripe + Mongo wiring.
 The proven persistent shape is `app-with-data` (Next.js + Mongo). This blueprint
 extends it with Stripe subscriptions + the Billing Portal. Fetch that template
 for the Mongo lazy-client and App-Router API pattern:
-`gridctl_fetch("template", "app-with-data")`.
+`grid_fetch("template", "app-with-data")`.
 
 ## 1. File tree
 
@@ -89,7 +89,7 @@ client for plan/status — read this (kept current by the webhook).
     STRIPE_KEY: stripe-live-key
     STRIPE_WEBHOOK_SECRET: stripe-webhook-secret
   ```
-  Set the vault items ONCE with `gridctl_secrets` (or `grid secrets set`), then
+  Set the vault items ONCE with `grid_secrets` (or `grid secrets set`), then
   the deployer injects each as the named env var (`process.env.STRIPE_KEY`, etc.)
   at runtime and under `grid dev`. Do NOT commit keys; do NOT set them in
   `services.web.env` (that block is for non-secret config only). Read them lazily
@@ -158,22 +158,22 @@ known user — otherwise anyone could change anyone's plan.
 
 ## 5. Deploy steps
 
-1. `gridctl_login_status` → `gridctl_login` if needed. Respect the grid picker
+1. `grid_login_status` → `grid_login` if needed. Respect the grid picker
    (ask which grid if the user has more than one).
-2. `gridctl_init` an app `<name>` FIRST — it creates the entity, writes
+2. `grid_init` an app `<name>` FIRST — it creates the entity, writes
    `.cloudgrid/link.json`, and a `cloudgrid.yaml` with empty `services: {}`.
    `plug` needs a linked directory.
 3. Write the app under `services/web/` and set `cloudgrid.yaml` to the active
    shape: `name` + `services.web{type: nextjs, path: /}` + `needs:{database:true}`
    + the `vault:` block.
-4. Set the secrets: `gridctl_secrets` for `stripe-live-key`,
+4. Set the secrets: `grid_secrets` for `stripe-live-key`,
    `stripe-webhook-secret` (and `auth-provider-key` if you use an auth SDK) — the
    vault item keys the `vault:` block maps from. Non-secret config (Stripe
-   publishable key, price ids, auth publishable key) → `gridctl_env` /
+   publishable key, price ids, auth publishable key) → `grid_env` /
    `services.web.env`. Do NOT set `DATABASE_MONGODB_URL` yourself — the grid
    injects it.
-5. `gridctl_plug` to deploy. A runtime deploy is **ASYNC** — the first response
-   is `status: building`, not a live URL. Poll `gridctl_status` (or the returned
+5. `grid_plug` to deploy. A runtime deploy is **ASYNC** — the first response
+   is `status: building`, not a live URL. Poll `grid_status` (or the returned
    poll_url) until live; surface a liveness signal while it builds, never a bare
    silent wait.
 6. Once live, add the `/api/webhook` URL as the Stripe webhook endpoint, copy
@@ -187,5 +187,5 @@ A subscription-management app is a built + deployed runtime container, so it
 requires the **local edition** (Claude Desktop / Claude Code) or the CLI. The
 **hosted** edition (Claude Web / hosted MCP) is inline-only and can only publish
 static pages — it CANNOT build this app. On hosted, say so plainly and offer a
-static pricing/plans page (via `gridctl_drop`) instead, then stop the runtime
+static pricing/plans page (via `grid_plug`) instead, then stop the runtime
 path.

package/src/corpus/templates/subscription-management/index.md

@@ -15,8 +15,8 @@ flow, use the `membership-site` blueprint — the two share the same Stripe + Mo
 wiring.
 
 **Fetch the bundle:**
-- `gridctl_fetch("template", "subscription-management")` — this blueprint (`cloudgrid.yaml` + `AGENTS.md`).
-- `gridctl_fetch("template", "app-with-data")` — the proven Next.js + Mongo shape to extend (lazy db client, App-Router API).
+- `grid_fetch("template", "subscription-management")` — this blueprint (`cloudgrid.yaml` + `AGENTS.md`).
+- `grid_fetch("template", "app-with-data")` — the proven Next.js + Mongo shape to extend (lazy db client, App-Router API).
 
 **Key rules:**
 
@@ -30,7 +30,7 @@ wiring.
    `DATABASE_MONGODB_URL` (legacy `MONGODB_URL` fallback). Read it LAZILY inside
    the getter, never at module top level (top-level read fails `next build`).
 4. **Secrets via the `vault:` block** → env vars. `STRIPE_KEY` and
-   `STRIPE_WEBHOOK_SECRET` map to vault items; set them with `gridctl_secrets`,
+   `STRIPE_WEBHOOK_SECRET` map to vault items; set them with `grid_secrets`,
    and the deployer injects them at runtime. Read lazily; do not commit keys or
    put secrets in `services.web.env` (publishable key + price ids go there).
 5. **The webhook is the source of truth.** Change-plan / cancel APIs call Stripe;
@@ -66,8 +66,8 @@ vault:
 
 ## Deploy (async, local edition)
 
-`gridctl_init` first (creates the entity + link.json), write the app under
-`services/web/`, set the vault secrets with `gridctl_secrets`, `gridctl_plug`
-(async — poll `gridctl_status` to a live URL), then register the `/api/webhook`
+`grid_init` first (creates the entity + link.json), write the app under
+`services/web/`, set the vault secrets with `grid_secrets`, `grid_plug`
+(async — poll `grid_status` to a live URL), then register the `/api/webhook`
 URL in Stripe, configure the Billing Portal, and re-plug. Re-plug the same entity
 to update the same URL.

package/src/corpus/templates/waitlist/README.md

@@ -3,12 +3,12 @@
 A single self-contained HTML launch waitlist / coming-soon page: a hero, an email capture form, and a social-proof counter.
 
 Static inspiration — a single self-contained `index.html` (inline CSS and JS,
-no external CDNs). It deploys instantly via `gridctl_drop` and works on every
+no external CDNs). It deploys instantly via `grid_plug` and works on every
 CloudGrid edition, including hosted.
 
 ## Fill it in
 
-Fetch the template with `gridctl_fetch("template", "waitlist")`, then replace the
+Fetch the template with `grid_fetch("template", "waitlist")`, then replace the
 placeholders:
 
    - The product name, coming-soon headline, and subheadline.
@@ -21,7 +21,7 @@ stylesheets, fonts, or large embedded media.
 ## Deploy
 
 - 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 deploys as an inspiration and returns a live share URL right away. Re-deploy
 with the same entity id to update the same URL.

package/src/corpus/templates/waitlist/index.md

@@ -5,14 +5,13 @@ State (if any) lives only in memory and is lost on refresh.
 
 ## How it deploys
 
-To publish this page, use **`gridctl_drop`** (or `gridctl_plug` with the inline
-HTML): it deploys as an **inspiration** — instant, and works on the **hosted**
+To publish this page, use **`grid_plug`** with the inline `html`: it deploys as an **inspiration** — instant, and works on the **hosted**
 edition (Claude Web) as well as local. The reference `cloudgrid.yaml` in this
 directory (`type: static`) is ONLY for plugging the page as an OWNED static
-runtime (async, local edition only); the fast path is `gridctl_drop`.
+runtime (async, local edition only); the fast path is `grid_plug`.
 
 The fillable HTML is the real template — fetch it with
-`gridctl_fetch("template", "waitlist")` and fill in the user's content.
+`grid_fetch("template", "waitlist")` and fill in the user's content.
 
 ## Note on storing signups
 

package/src/corpus/templates/web-app/cloudgrid.yaml

@@ -16,7 +16,7 @@
 # THIS TEMPLATE (web-app): a single self-contained static page. The active fields
 # are exactly name + services.web{type: static, path: /}; there are no needs.
 # This cloudgrid.yaml is the reference for plugging it as an OWNED static
-# runtime; the fast path is to deploy it as an INSPIRATION via gridctl_drop
+# runtime; the fast path is to deploy it as an INSPIRATION via grid_plug
 # (instant, and works on the hosted edition too).
 # ============================================================================
 

package/src/corpus/templates/web-app/index.md

@@ -5,14 +5,13 @@ no `needs:`. State (if any) lives only in memory and is lost on refresh.
 
 ## How it deploys
 
-To publish this page, use **`gridctl_drop`** (or `gridctl_plug` with the inline
-HTML): it deploys as an **inspiration** — instant, and works on the **hosted**
+To publish this page, use **`grid_plug`** with the inline `html`: it deploys as an **inspiration** — instant, and works on the **hosted**
 edition (Claude Web) as well as local. The reference `cloudgrid.yaml` in this
 directory (`type: static`) is ONLY for plugging the page as an OWNED static
-runtime (async, local edition only); the fast path is `gridctl_drop`.
+runtime (async, local edition only); the fast path is `grid_plug`.
 
 The fillable HTML is the real template — fetch it with
-`gridctl_fetch("template", "web-app")` and fill in the user's content.
+`grid_fetch("template", "web-app")` and fill in the user's content.
 
 ## cloudgrid.yaml (reference only)
 

package/src/corpus/troubleshooting/deploy-errors.md

@@ -10,7 +10,7 @@ Match the symptom to the row, apply the fix, and stop. Do not retry permutations
 
 | Symptom | Cause | Fix |
 | --- | --- | --- |
-| `SCOPE_INVALID` on deploy | Known platform issue, not your request | Deploy from a terminal with `gridctl plug <path>` or `cloudgrid plug <path>`. Do not retry flag or path permutations. If no terminal is available, tell the user it is a known issue that needs the CLI. |
+| `SCOPE_INVALID` on deploy | Known platform issue, not your request | Deploy from a terminal with `grid plug <path>` or `cloudgrid plug <path>`. Do not retry flag or path permutations. If no terminal is available, tell the user it is a known issue that needs the CLI. |
 | `429` anonymous cap reached | Anonymous deploy quota is exhausted | Stop. Do not log in to work around it and do not retry today. Tell the user the cap is reached; they can try later or sign in for a higher limit as a deliberate choice. |
 | `409 EDIT_REJECTED` on re-plug | The target entity is archived or expired | Do not silently create a new entity — that mints a new URL and orphans the shared one. Ask the user before creating a fresh entity. |
 | `401` on an anonymous edit | Missing or stale `owner_token` | Re-plug with the `owner_token` from the last deploy of that entity. Each anonymous edit returns a fresh token — store the new one and use it next time. |

package/src/corpus/troubleshooting/persistent-apps.md

@@ -15,7 +15,7 @@ Match the symptom to the row, apply the fix, and stop.
 | `next build` fails / DB connection error at build time | The DB env var is read at module top level; `next build` imports the module for route analysis before the grid injects the var | Read `process.env.DATABASE_MONGODB_URL` (with a legacy `MONGODB_URL` fallback) LAZILY inside the getter (e.g. inside `getDb`), never at module load. Moving the check into the function lets the build pass. |
 | App builds + deploys but every request 500s with `DATABASE_MONGODB_URL not set` | The datastore isn't declared, or you declared the deprecated `requires:` instead of `needs:` | Declare `needs: { database: true }` in `cloudgrid.yaml`. The deployer provisions Mongo and injects `DATABASE_MONGODB_URL` (plus the legacy `MONGODB_URL` alias). Never set `needs:` and `requires:` together (the validator rejects it). |
 | `DATABASE_MONGODB_URL is undefined` (or the db.js guard throws) | The env var isn't present because you're not running under the grid | Run locally with `grid dev`, or deploy with `grid plug` — the grid injects `DATABASE_MONGODB_URL` (+legacy `MONGODB_URL`) at dev-time and runtime. Do NOT set it yourself and never hardcode a connection string. |
-| Deploy seems stuck / no URL returned | Runtime deploys are asynchronous | `plug` returns `status: building`, not a URL. Poll `gridctl_status` (or the poll_url) until the app is live, then return the live URL. Don't treat the build/log link as the deliverable. |
+| Deploy seems stuck / no URL returned | Runtime deploys are asynchronous | `plug` returns `status: building`, not a URL. Poll `grid_status` (or the poll_url) until the app is live, then return the live URL. Don't treat the build/log link as the deliverable. |
 | It won't build on the hosted edition | Hosted MCP is inline-only — it can't run the CLI or folder-plug | Runtime apps need the LOCAL edition (Claude Desktop/Code) or the CLI. On hosted, tell the user persistence isn't available there and offer a static version instead. |
 | Redis not available | `cache` wasn't declared | Add `cache: true` to `needs:` in `cloudgrid.yaml`; the grid then injects `CACHE_REDIS_URL` (plus the legacy `REDIS_URL` alias). Only add it if the app actually needs Redis. |
 

package/src/corpus/usage.md

@@ -16,7 +16,7 @@ Which one you use depends on the client. Pick your client below.
 - **Node 18+** (for `npx`).
 - **No login needed to try it** — anonymous drop works out of the box. For owned
   drops (into your org), run `cloudgrid login` once, or use the `login` skill / the
-  `gridctl_login` MCP tool.
+  `grid_login` MCP tool.
 
 ---
 
@@ -39,13 +39,13 @@ npx skills add cloudgrid-io/skills
 /plugin install cloudgrid
 ```
 - **Find it under `/plugin`**; the skills also show under `/skills` (labeled Plugin).
-- Invoke as **`/cloudgrid:drop`** (plugin namespace + short skill name, like `superpowers:brainstorming`), or describe the task.
+- Invoke as **`/cloudgrid:plug`** (plugin namespace + short skill name, like `superpowers:brainstorming`), or describe the task.
 
 ### Route 3 — the MCP server
 ```
 claude mcp add cloudgrid -- npx -y @cloudgrid-io/mcp
 ```
-- **Find it under `/mcp`.** Exposes tools `gridctl_drop`, `gridctl_login`, …
+- **Find it under `/mcp`.** Exposes tools `grid_plug`, `grid_login`, …
 - Invoke by describing the task; the model calls the tool.
 
 > Where did my install go? `/skills` (skills), `/plugin` (plugin), `/mcp` (MCP).

package/src/corpus/workflows/admin-dashboard.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", "admin-dashboard")`. It is a minimal, real Next.js
+   `grid_fetch("template", "admin-dashboard")`. It is a minimal, real Next.js
    + `mongodb`-driver admin panel under `services/web/`: a lazy client in
    `services/web/lib/db.js`, two App-Router GET/POST/DELETE routes (`users` and
    `orders`), a server-component page that computes a metrics header, 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/ai-app.md

@@ -35,13 +35,13 @@ 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; 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.
 
@@ -75,7 +75,7 @@ ai: true, database: true }`).
    yaml with it, and never set `needs:` and `requires:` together (the validator
    rejects it).
 2. Fetch the template for the chat wiring:
-   `gridctl_fetch("template", "ai-app")`. It is a minimal Next.js App Router chat
+   `grid_fetch("template", "ai-app")`. It is a minimal Next.js App Router chat
    app under `services/web/`: a chat page, an API route
    (`app/api/chat/route.js`, `export const dynamic = "force-dynamic"`) that reads
    the user message, calls the AI gateway, persists the exchange to Mongo, and
@@ -95,7 +95,7 @@ ai: true, database: true }`).
    imported for route analysis before the grid injects the var). Store the user
    message and the assistant reply so the conversation survives refresh. Never
    hardcode a connection string; never commit a secret.
-   - (Optional) fetch `gridctl_fetch("example", "ai-app")` for a richer filled
+   - (Optional) fetch `grid_fetch("example", "ai-app")` for a richer filled
      reference (a themed assistant) to imitate.
 
 ## 5. (Optional) Run locally
@@ -105,17 +105,17 @@ are wired in dev too — and send a test message before deploying. Don't require
 
 ## 6. Config
 
-- Extra API keys / secrets (only if the app needs its own) → `gridctl_secrets`.
-- Non-secret config → `gridctl_env`.
+- Extra API keys / secrets (only if the app needs its own) → `grid_secrets`.
+- Non-secret config → `grid_env`.
 - Do **NOT** set the DB connection var yourself (`DATABASE_MONGODB_URL` / legacy
   `MONGODB_URL`) and do **NOT** set an AI key — the grid injects the DB var and
   the AI SDK auto-detects the in-grid identity.
 
 ## 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 — never a bare silent wait.
 - Only once it is live, return the deployed URL (the app URL, NOT the build/log
   link).

package/src/corpus/workflows/ai-knowledge-base.md

@@ -44,13 +44,13 @@ 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", "ai-knowledge-base")`. The deliverable is the
+`grid_fetch("template", "ai-knowledge-base")`. The deliverable is the
 **`AGENTS.md` structure guide** — read it before writing anything. It defines:
 - the `services/web/` file tree (pages, `api/documents` + `api/ask` routes, `lib/`),
 - the Mongo collections (`documents`, `chunks`) + fields,
@@ -64,7 +64,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:
@@ -112,7 +112,7 @@ Generate the files under `services/web/` per the guide:
   yourself; the grid injects them.
 - Only if you add auth/payments: map the secret in the `vault:` block
   (`AUTH_PROVIDER_KEY` and/or `STRIPE_KEY`) and store the value with
-  `grid secrets set <vault-item-key> …`. Non-secret public config → `gridctl_env`.
+  `grid secrets set <vault-item-key> …`. Non-secret public config → `grid_env`.
 
 ## 7. (Optional) Run locally
 
@@ -121,9 +121,9 @@ Gateway 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/analytics-dashboard.md

@@ -34,13 +34,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:
@@ -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:
-   `gridctl_fetch("template", "analytics-dashboard")`. It is a minimal, real
+   `grid_fetch("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,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/api-dashboard.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", "api-dashboard")`. It is a minimal, real Next.js +
+   `grid_fetch("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,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/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 gridctl_drop.
+capabilities_note: static — no infrastructure. Publishes as an inspiration (instant, works on hosted) via grid_plug.
 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 `gridctl_fetch("template", "api-docs")` to load
+1. **Fetch the template.** Call `grid_fetch("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:
@@ -28,7 +28,7 @@ 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/api-service.md

@@ -36,13 +36,13 @@ the CLI and folder-plug your project.
 ## 2. Auth + grid
 
 Persistent services 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; 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.
 
@@ -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:
-   `gridctl_fetch("template", "api-service")`. It is a minimal Node `http`
+   `grid_fetch("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 `gridctl_fetch("example", "api-service")` for a slightly
+   - (Optional) fetch `grid_fetch("example", "api-service")` for a slightly
      richer filled reference to imitate.
 
 ## 5. (Optional) Run locally
@@ -95,16 +95,16 @@ and hit the endpoints 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` alias) — 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 — never a bare silent wait.
 - Only once it is live, return the deployed URL (the API base URL, NOT the
   build/log link).