@ductape/mcp 0.2.10 → 0.2.12

package/dist/index.js

@@ -98,7 +98,7 @@ There are THREE categories of operations. Use the right tool for each:
 
        RESOLVING "No linked project" ERRORS:
        Some commands (declarative sync below, db migrate/schema, products environments *) need a
-       linked project — a local .ductape/config.json with a product tag and env slug. The "link"
+       linked project — a local ductape/config.json with a product tag and env slug. The "link"
        command does NOT validate against the server: it just writes that local file. This means you
        can run ductape_cli("link --product <tag> --env <slug>") even before that environment exists on
        the product yet — do not treat "no linked environment exists server-side" as a reason to avoid
@@ -235,6 +235,36 @@ There are THREE categories of operations. Use the right tool for each:
          - For cloud-linked envs, set config.cloud to the connection tag for that env and
            omit raw credentials; the cloud connection must exist for that env too.
 
+       ⚠ PERSIST AGAINST AN ALREADY-REGISTERED COMPONENT TAG CAN SILENTLY NO-OP:
+       import-persist-all / provision-persist-all call the component's create method first and only
+       fall back to update if create throws. Depending on platform version, create against an existing
+       tag can resolve successfully without changing anything instead of throwing — so the response can
+       report success (and, for provision, a real cloud resource gets created) while the Ductape
+       component record is left completely unchanged, still pointing at whatever it pointed at before.
+       Never trust a success response alone when persisting against an existing tag:
+         1. ALWAYS re-fetch the component immediately after — ductape_cli("resources <type> get -t <tag> --json")
+         2. Diff the fields you meant to change (e.g. envs[].config.cloud) against what you intended.
+         3. If unchanged, treat the persist as failed even though it reported success, and say so —
+            do not retry the same call in a loop; report it and ask before continuing.
+
+       ⚠ DUCTAPE NEVER DEPROVISIONS REAL CLOUD RESOURCES — THIS IS INTENTIONAL, NOT A GAP:
+       There is no verb, flag, or code path anywhere in Ductape (CLI, SDK, or backend) that deletes an
+       actual cloud resource (a GCS/S3 bucket, a Pub/Sub/SNS topic, a database instance, etc.). This is a
+       deliberate product decision — auto-deprovisioning real infrastructure risks destroying real data,
+       so that responsibility is left entirely to the human operator via the cloud provider's own console
+       or CLI (gcloud, aws, az, …). Concretely:
+         - ductape_cli("resources <type> delete -t <tag>") only clears Ductape's own catalog record
+           (soft delete). It never touches the underlying cloud resource — that resource still exists and
+           still costs money/still needs manual cleanup after this call succeeds.
+         - provision-persist(-all) and import-persist(-all) create/link real cloud resources but there
+           is no symmetric "deprovision" or "cloud resources delete" operation — attempting
+           ductape_cli("cloud resources delete ...") returns a clear error explaining this by design.
+         - If a provisioning attempt fails partway through, or a component is deleted, any real cloud
+           resources it created are orphaned and will keep existing (and accruing cost) until the operator
+           deletes them manually. Surface this to the user explicitly rather than treating it as something
+           this tooling can clean up — do not propose scripting cloud-provider deletes on the user's behalf
+           unless they explicitly ask for that as a separate, one-off action outside of Ductape.
+
   2. RUNTIME OPERATIONS  (run, dispatch, execute, start, send, produce, query, insert, update, delete…)
        The "input" field shape is product- and operation-specific — it is NOT derivable from Joi validators.
        It is defined by how the product's action/feature/session/quota/etc. was configured in Ductape.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ductape/mcp",
-  "version": "0.2.10",
+  "version": "0.2.12",
   "description": "MCP server that exposes Ductape SDK operations via the backend proxy",
   "type": "module",
   "main": "dist/index.js",
@@ -15,7 +15,7 @@
   ],
   "scripts": {
     "build": "tsc",
-    "test": "npm run build && node scripts/check-cli-command-security.mjs && node scripts/check-frontend-analytics-guidance.mjs && node scripts/check-events-discovery.mjs && node scripts/check-schema-fallback.mjs && node scripts/check-portable-functions.mjs",
+    "test": "npm run build && node scripts/check-cli-command-security.mjs && node scripts/check-frontend-analytics-guidance.mjs && node scripts/check-events-discovery.mjs && node scripts/check-schema-fallback.mjs && node scripts/check-portable-functions.mjs && node scripts/check-project-link-guidance.mjs",
     "start": "node dist/index.js",
     "dev": "tsx src/index.ts"
   },