@cloudgrid-io/mcp 0.16.2 → 0.18.0

package/src/corpus/workflows/marketplace.md

@@ -34,13 +34,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", "marketplace")`. The deliverable is the **`AGENTS.md`
+`grid_fetch("template", "marketplace")`. The deliverable is the **`AGENTS.md`
 structure guide** — read it before writing anything. It defines:
 - the `services/web/` file tree (pages, API routes, `lib/`),
 - the Mongo collections (`vendors`, `listings`, `orders`) + fields,
@@ -54,7 +54,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:
@@ -97,7 +97,7 @@ Generate the files under `services/web/` per the guide:
 - Map secrets in the `vault:` block (done above), then **store the values**:
   `grid secrets set stripe-live-key sk_live_…`,
   `grid secrets set stripe-webhook-secret whsec_…`,
-  `grid secrets set auth-provider-key …`. Non-secret public config → `gridctl_env`.
+  `grid secrets set auth-provider-key …`. Non-secret public config → `grid_env`.
 - Do **NOT** set the DB connection vars yourself (`DATABASE_MONGODB_URL` / legacy
   `MONGODB_URL`) — the grid injects them.
 
@@ -108,9 +108,9 @@ secrets 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/membership-site.md

@@ -34,7 +34,7 @@ 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.
 
@@ -43,17 +43,17 @@ edition** (Claude Desktop / Claude Code) or the CLI.
 Fetch the template and read its structure guide — this is the core of the
 workflow:
 
-- `gridctl_fetch("template", "membership-site")` — the `cloudgrid.yaml` +
+- `grid_fetch("template", "membership-site")` — the `cloudgrid.yaml` +
   **`AGENTS.md`**. AGENTS.md has the file tree, the Mongo collections
   (`users`, `memberships`), 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.
@@ -98,11 +98,11 @@ never set `needs:` and `requires:` together (the validator rejects it).
 
 ## 6. Config / secrets
 
-- Stripe + auth secrets → `gridctl_secrets` (set the vault items `stripe-live-key`,
+- Stripe + auth secrets → `grid_secrets` (set the vault items `stripe-live-key`,
   `stripe-webhook-secret`, `auth-provider-key` 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 id) →
-  `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.
 
@@ -113,9 +113,9 @@ and vault secrets 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.
 - Once live, register the `/api/webhook` URL as the Stripe webhook endpoint,
   copy the signing secret into the `stripe-webhook-secret` vault item, and

package/src/corpus/workflows/monitoring-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", "monitoring-dashboard")`. It is a minimal, real
+   `grid_fetch("template", "monitoring-dashboard")`. It is a minimal, real
    Next.js + `mongodb`-driver health board under `services/web/`: a lazy client
    in `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on a `checks`
    collection, a server-component page that derives the status grid, and a client
@@ -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/online-store.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.
 
@@ -48,7 +48,7 @@ directory, so run `init` FIRST.
 
 This is a blueprint — the structure guide is the deliverable, not copy-paste code.
 
-1. `gridctl_fetch("template", "online-store")`.
+1. `grid_fetch("template", "online-store")`.
 2. **Read `AGENTS.md`** in the fetched template. It has: the file tree (app under
    `services/web/`), the Mongo collections (`products`, `orders`) and their
    fields, how the grid injects Mongo (`DATABASE_MONGODB_URL`) and the Stripe key
@@ -88,24 +88,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
+   dashboard, 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 store URL — that is the deliverable. To iterate, re-plug
    the SAME entity so it updates the same URL.

package/src/corpus/workflows/portfolio.md

@@ -4,7 +4,7 @@ when: portfolio, personal site, freelancer site, my work, showcase, resume site,
 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 portfolio template, fill it with the user's projects and bio, deploy it, and return the live share URL.
 ---
 
@@ -15,7 +15,7 @@ follow this recipe. Reach for this over `landing-page` when the request is about
 showcasing projects with an about, skills, and contact. Do not ask setup
 questions first; use sensible defaults and build.
 
-1. **Fetch the template.** Call `gridctl_fetch("template", "portfolio")` to load
+1. **Fetch the template.** Call `grid_fetch("template", "portfolio")` to load
    the self-contained HTML portfolio (hero, about, skills, projects grid,
    contact).
 2. **Fill the template.** Replace the placeholders with the user's content:
@@ -27,7 +27,7 @@ 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/presentation.md

@@ -4,7 +4,7 @@ when: slides, deck, pitch, presentation, slideshow.
 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 deck template, fill it with the user's content, deploy it, and return the live share URL.
 ---
 
@@ -13,9 +13,9 @@ summary: Fetch the deck template, fill it with the user's content, deploy it, an
 Detect the intent ("build me a presentation / deck / slides about X") and follow
 this recipe. Do not ask setup questions first; use sensible defaults and build.
 
-1. **Fetch the template.** Call `gridctl_fetch("template", "deck")` to load the
+1. **Fetch the template.** Call `grid_fetch("template", "deck")` to load the
    self-contained HTML deck template.
-2. **(Optional) Fetch the example.** Call `gridctl_fetch("example", "deck")` to
+2. **(Optional) Fetch the example.** Call `grid_fetch("example", "deck")` to
    see a filled deck as a reference for tone and structure.
 3. **Fill the template.** Replace the placeholders with the user's content:
    - The deck title and subtitle.
@@ -24,7 +24,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`.
    An HTML deck 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 deck.

package/src/corpus/workflows/product-catalog.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. 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:
@@ -66,7 +66,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", "product-catalog")`. It is a minimal, real
+   `grid_fetch("template", "product-catalog")`. It is a minimal, real
    Next.js + `mongodb`-driver catalog under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on a `products`
    collection, a server-component page, and a client grid with a category filter
@@ -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).
 

package/src/corpus/workflows/product-launch.md

@@ -4,7 +4,7 @@ when: product launch page, launch announcement, new product page, we just launch
 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 product-launch template, fill it with the user's product/launch content, deploy it, and return the live share URL.
 ---
 
@@ -14,10 +14,10 @@ Detect the intent ("build a launch page / announcement for our new product X")
 and follow this recipe. Do not ask setup questions first; use sensible defaults
 and build.
 
-1. **Fetch the template.** Call `gridctl_fetch("template", "product-launch")` to
+1. **Fetch the template.** Call `grid_fetch("template", "product-launch")` to
    load the self-contained HTML launch-page template (hero + product image,
    countdown, features, launch offer, social proof).
-2. **(Optional) Fetch the example.** Call `gridctl_fetch("example", "product-launch")`
+2. **(Optional) Fetch the example.** Call `grid_fetch("example", "product-launch")`
    to see a filled launch page as a reference for tone and structure.
 3. **Fill the template.** Replace the placeholders with the user's content:
    - Product name, hero headline, subhead, launch badge, and CTA label/target.
@@ -33,7 +33,7 @@ and build.
      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 launch page 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/project-management.md

@@ -36,13 +36,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:
@@ -67,7 +67,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", "project-management")`. It is a minimal, real
+   `grid_fetch("template", "project-management")`. It is a minimal, real
    Next.js + `mongodb`-driver app under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on a `projects`
    collection, a GET/POST/PATCH/DELETE route on a `tasks` collection, a
@@ -87,15 +87,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/property-listings.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", "property-listings")`. It is a minimal, real
+   `grid_fetch("template", "property-listings")`. It is a minimal, real
    Next.js + `mongodb`-driver listings site under `services/web/`: a lazy client
    in `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on a
    `properties` collection (GET supports `?location=` and `?maxPrice=` filters), a
@@ -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/quiz-platform.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", "quiz-platform")`. It is a minimal, real Next.js +
+   `grid_fetch("template", "quiz-platform")`. It is a minimal, real Next.js +
    `mongodb`-driver quiz platform under `services/web/`: a lazy client in
    `services/web/lib/db.js`, an App-Router GET/POST/DELETE route on a
    `questions` collection, a server-component page that reads the collection, and
@@ -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).
 

package/src/corpus/workflows/report.md

@@ -4,7 +4,7 @@ when: report, one-pager, summary, brief, whitepaper, case study, formatted docum
 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 report template, fill it with the user's content, deploy it, and return the live share URL.
 ---
 
@@ -13,9 +13,9 @@ summary: Fetch the report template, fill it with the user's content, deploy it,
 Detect the intent ("build me a report / one-pager / brief about X") and follow
 this recipe. Do not ask setup questions first; use sensible defaults and build.
 
-1. **Fetch the template.** Call `gridctl_fetch("template", "report")` to load
+1. **Fetch the template.** Call `grid_fetch("template", "report")` to load
    the self-contained, print-friendly HTML report template.
-2. **(Optional) Fetch the example.** Call `gridctl_fetch("example", "report")`
+2. **(Optional) Fetch the example.** Call `grid_fetch("example", "report")`
    to see a filled report as a reference for tone and structure.
 3. **Fill the template.** Replace the placeholders with the user's content:
    - The report title, subtitle, and date 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 report 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 report.

package/src/corpus/workflows/restaurant-reservations.md

@@ -37,13 +37,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. Fetch the blueprint and READ AGENTS.md
 
-`gridctl_fetch("template", "restaurant-reservations")`. This is a **blueprint**,
+`grid_fetch("template", "restaurant-reservations")`. This is a **blueprint**,
 so the deliverable is `cloudgrid.yaml` + `AGENTS.md`, not app code.
 
 **Read `AGENTS.md` before building.** It defines:
@@ -56,7 +56,7 @@ so the deliverable is `cloudgrid.yaml` + `AGENTS.md`, not app code.
 
 ## 4. Scaffold + fill
 
-1. `gridctl_init` an app `<name>` — creates the entity + `.cloudgrid/link.json`
+1. `grid_init` an app `<name>` — creates the entity + `.cloudgrid/link.json`
    and a `cloudgrid.yaml` with an EMPTY `services: {}`. Run `init` FIRST (plug
    needs a linked directory).
 2. Write the app under **`services/web/`** (`path:` is the URL mount, NOT the
@@ -85,9 +85,9 @@ so the deliverable is `cloudgrid.yaml` + `AGENTS.md`, not app code.
 
 ## 5. Config / secrets
 
-- Secret values (Stripe, SendGrid, auth) → `gridctl_secrets` (the `vault:` block
+- Secret values (Stripe, SendGrid, auth) → `grid_secrets` (the `vault:` block
   maps them to env vars). Non-secret config (publishable keys, flags) →
-  `gridctl_env`.
+  `grid_env`.
 - Do **NOT** set the DB vars yourself (`DATABASE_MONGODB_URL` / `MONGODB_URL`) —
   the grid injects them.
 
@@ -98,9 +98,9 @@ against dev Mongo. Seed the `menu` collection, test a booking. Don't require it.
 
 ## 7. Deploy (async)
 
-Deploy `services/web/` with `gridctl_plug`. A **runtime deploy is ASYNC**: the
+Deploy `services/web/` with `grid_plug`. A **runtime deploy is ASYNC**: the
 first response is `status: building`, NOT a live URL.
-- Poll `gridctl_status` (or the returned poll URL) until live.
+- Poll `grid_status` (or the returned poll URL) until live.
 - Surface a liveness signal while it builds — never a bare silent wait.
 - Only once live, return the deployed app URL (NOT the build/log link).
 - If Stripe deposits are on, register the live `/api/webhooks/stripe` URL in the

package/src/corpus/workflows/revenue-dashboard.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", "revenue-dashboard")`. It is a minimal, real
+   `grid_fetch("template", "revenue-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 a `sales`
    collection, a server-component page that computes the total + per-product
@@ -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/saas-marketing.md

@@ -4,7 +4,7 @@ when: SaaS marketing site, product marketing page, features and pricing page, mu
 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 saas-marketing template, fill it with the user's product content, deploy it, and return the live share URL.
 ---
 
@@ -16,7 +16,7 @@ it when the request calls for pricing tiers, testimonials, and an FAQ, not just
 hero. For a plain single-section landing page, use `landing-page`. Do not ask
 setup questions first; use sensible defaults and build.
 
-1. **Fetch the template.** Call `gridctl_fetch("template", "saas-marketing")` to
+1. **Fetch the template.** Call `grid_fetch("template", "saas-marketing")` to
    load the self-contained HTML marketing site.
 2. **Fill the template.** Replace the placeholders with the user's content:
    - The product name, tagline, and hero eyebrow/headline/subheadline.
@@ -29,7 +29,7 @@ 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.