@cloudgrid-io/mcp 0.11.2 → 0.13.0

package/src/corpus/workflows/status-page.md

@@ -0,0 +1,35 @@
+---
+name: status-page
+when: status page, service status, uptime page, incident history, is-it-down page, system status board. Display-only — status is baked into the page, no live monitoring.
+needs: none
+deploy: inspiration
+editions: all
+capabilities_note: static — no infrastructure, status baked into the page. Publishes as an inspiration (instant, works on hosted) via gridctl_drop.
+summary: Fetch the status-page template, fill it with the user's components and incidents, deploy it, and return the live share URL.
+---
+
+# Workflow: status-page
+
+Detect the intent ("build me a status page / uptime page for X") and follow this
+recipe. This is a display-only static page — the status is baked into the markup,
+there is no live polling. Do not ask setup questions first; use sensible defaults
+and build.
+
+1. **Fetch the template.** Call `gridctl_fetch("template", "status-page")` to load
+   the self-contained HTML status page (overall banner, component list with
+   up/degraded/down pills, per-component uptime bars, incident history).
+2. **Fill the template.** Replace the placeholders with the user's content:
+   - The overall banner text and its state class (`ok` / `degraded` / `down`).
+   - One row per component: name, a status pill, and the 90-day uptime bar. Mark
+     any non-ok bar segments with class `degraded` or `down`.
+   - The incident history entries: date, title, state, and a short note.
+   - Keep it a single self-contained HTML file. Do not add external scripts,
+     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`.
+   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.
+
+Keep the whole flow tight: fetch, fill, deploy, share.

package/src/corpus/workflows/task-manager.md

@@ -0,0 +1,101 @@
+---
+name: task-manager
+when: task manager, to-do app (richer than the app-with-data starter), task list with due dates/priorities, complete-toggle + filter — a persistent task app that sticks across refresh. Needs a database → runtime → local edition.
+needs: database
+deploy: runtime
+editions: local
+capabilities_note: persistent — needs a database (Mongo). Runtime app, async build, local edition only. Declare the canonical `needs: { database: true }`; the deployer injects DATABASE_MONGODB_URL (+legacy MONGODB_URL).
+summary: Build a persistent Next.js + Mongo task manager on the grid — a `tasks` collection (title, done, due, priority) with a complete-toggle, active/done filter, add/delete. Richer than the bare app-with-data to-do. Edition-gate first, scaffold, put the app under services/web/, wire process.env.DATABASE_MONGODB_URL (legacy MONGODB_URL fallback) lazily, declare needs:{database:true} (not requires:), deploy async, poll to a live URL.
+---
+
+# Workflow: task-manager
+
+The user wants a task manager richer than the bare `app-with-data` to-do starter
+— tasks with due dates and priorities, a complete-toggle, and an active/done
+filter, all of which **stick** across refresh and are shared across sessions.
+That is a **runtime app** backed by the grid's shared Mongo, not a static page.
+It is the same proven shape as `app-with-data`, with a `tasks` domain (title,
+done, due, priority of low/medium/high). (For the bare-minimum in-memory to-do,
+use `app-with-data` instead.)
+
+Follow this recipe. Be honest that a runtime deploy is async (not instant like a
+static drop) and that it needs the local edition.
+
+## 1. Edition check FIRST (hard gate)
+
+A persistent app is a built + deployed container. It requires the **local
+edition** (Claude Desktop / Claude Code) or the CLI.
+
+- **Hosted edition (Claude Web / hosted MCP):** you CANNOT build a runtime app —
+  hosted is inline-only and can only publish static pages. Tell the user
+  plainly, offer a **static version** instead, and STOP the runtime path here.
+- **Local edition:** continue.
+
+## 2. Auth + grid
+
+1. Ensure signed in: `gridctl_login_status`; if not, `gridctl_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`
+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:
+{ database: true }`).
+
+## 4. Add the datastore + wire Mongo
+
+1. Set `cloudgrid.yaml`. **App code MUST live under `services/<name>/`** —
+   `path:` is the URL mount, NOT the filesystem path.
+   ```yaml
+   name: my-tasks
+   services:
+     web:
+       type: nextjs
+       path: /
+   needs:
+     database: true
+   ```
+   **Declare the datastore with `needs: { database: true }`** — the canonical
+   shape. The deployer provisions Mongo and injects `DATABASE_MONGODB_URL` (plus
+   the legacy `MONGODB_URL` alias). `requires:` is the deprecated v1 alias; don't
+   author new yaml with it, and never set `needs:` and `requires:` together (the
+   validator rejects it).
+2. Fetch the template for the Mongo wiring + CRUD shape:
+   `gridctl_fetch("template", "task-manager")`. It is a minimal, real Next.js +
+   `mongodb`-driver task manager under `services/web/`: a lazy client in
+   `services/web/lib/db.js`, an App-Router GET/POST/PATCH/DELETE route on a
+   `tasks` collection (PATCH toggles done), a server-component page, and a client
+   list with an active/done filter.
+3. Adapt it (rename the collection, change fields, adjust the UI). **Read the DB
+   from `process.env.DATABASE_MONGODB_URL`** (legacy `process.env.MONGODB_URL`
+   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.**
+
+## 5. (Optional) Run locally
+
+Mention that the user can `grid dev` to run locally against the injected Mongo
+before deploying. Don't require it.
+
+## 6. Config
+
+- API keys / secrets → `gridctl_secrets`. Non-secret config → `gridctl_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
+response is `status: "building"`, NOT a live URL yet.
+- Poll `gridctl_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. Return the live URL + iterate
+
+Give the user the live app URL — that is the deliverable. To iterate, re-plug the
+SAME entity so it updates the same URL. Keep it honest: async build, local-edition
+only, credentials injected by the grid.

package/src/corpus/workflows/waitlist.md

@@ -0,0 +1,42 @@
+---
+name: waitlist
+when: waitlist, coming soon, early access, join the list, launch page, sign-up teaser with an email capture form. NOTE the form is static — to actually STORE signups you need a runtime app (needs: database), coming in the crud-app archetype.
+needs: none
+deploy: inspiration
+editions: all
+capabilities_note: static — no infrastructure. The email form posts to a configurable mailto/external endpoint; it does NOT store signups. Publishes as an inspiration (instant, works on hosted) via gridctl_drop.
+summary: Fetch the waitlist template, fill it with the user's launch copy, wire the form to a mailto or external endpoint, deploy it, and return the live share URL.
+---
+
+# Workflow: waitlist
+
+Detect the intent ("build me a waitlist / coming-soon / early-access page") and
+follow this recipe. Do not ask setup questions first; use sensible defaults and
+build.
+
+**Important — the form is static.** This template captures an email and posts it
+to a configurable action: a `mailto:` (the default, which opens the visitor's
+mail client) or an external form endpoint you set on the `<form action>`. It does
+NOT store signups anywhere on CloudGrid. To actually **store** waitlist signups
+(persist, count, export them), you need a runtime app with a database
+(`needs: { database: true }`) — that is a CRUD app, coming in the crud-app
+archetype (Wave 1b). Do not claim this static page persists data.
+
+1. **Fetch the template.** Call `gridctl_fetch("template", "waitlist")` to load
+   the self-contained HTML waitlist page (hero, email form, social-proof counter).
+2. **Fill the template.** Replace the placeholders with the user's content:
+   - The product name, coming-soon headline, and subheadline.
+   - The signup counter and any social-proof line.
+   - The form action: set `<form action>` to a `mailto:` address or an external
+     form endpoint. Default is `mailto:`.
+   - Keep it a single self-contained HTML file. Do not add external scripts,
+     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`.
+   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. If the user needs
+   signups stored, tell them that needs the runtime crud-app archetype (Wave 1b).
+
+Keep the whole flow tight: fetch, fill, deploy, share.