@dypai-ai/mcp 1.5.3 → 1.5.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dypai-ai/mcp",
-  "version": "1.5.3",
+  "version": "1.5.4",
   "description": "DYPAI MCP Server — AI agent toolkit for building and deploying full-stack apps",
   "type": "module",
   "main": "src/index.js",

package/src/index.js

@@ -485,10 +485,18 @@ First reflex, always:
 
 1. **Acknowledge briefly** what they want to build (one short line, their language).
 2. **\`search_project_templates(query: "<keywords from their request>")\`** — keywords in their language. Templates cover common app types (gym, clinic, waitlist, saas dashboard, etc.).
-3. **If a template matches** → confirm with the user in one line, then \`create_project(name: "<their name>", template_slug: "<slug>")\`. Don't ask 15 questions about scope — the template IS the starting MVP, you can iterate from there.
-4. **If no template matches** → \`create_project(name: "<their name>", template_slug: "blank")\` and then build from scratch.
+3. **Decide: template or blank?** Default is **blank**. A template is only the right pick when the match is OBVIOUS and STRONG:
+   - ✅ User says *"app para mi gimnasio"* + there's \`gym-manager\` (exact domain + feature overlap) → template.
+   - ❌ User says *"algo para gestionar reservas"* + there's \`gym-manager\` (soft match, many interpretations) → **blank**. Don't assume they want the gym's specific schema (classes, memberships, check-ins) — they didn't ask for it.
+   - ❌ User is a dev with a concrete spec (*"crea un proyecto con estas 3 tablas y estos endpoints"*) → **blank**, always. Respect their design.
+   - ❌ No template returned at all → **blank**.
+4. **Call it** → \`create_project(name: "<their name>", template_slug: "<matched_slug>" | "blank")\`.
+   If you went with a template, acknowledge in ONE line what's included so the user can push back: *"Lo arranco con la plantilla X, que trae socios, clases y pagos. ¿Te vale o prefieres algo más simple?"*
+   If you went blank, just say: *"Arranco un proyecto en blanco y lo construimos a medida."*
 5. **After \`create_project\`** → ask for an absolute workspace path, then \`dypai_pull\` + \`manage_frontend(sync)\` (see next section).
 
+**The template system exists to save time when the fit is obvious, not to force-match every request.** When in doubt → blank is always correct. Iterating up from blank is cheaper than deleting 80% of a mismatched template.
+
 ## The one legit follow-up question
 
 After deciding to build on DYPAI, you may ask ONE question (not five) to size scope if the request is genuinely vague:
@@ -531,6 +539,8 @@ Before the first \`execute_sql\`, before the first file edit, before ANYTHING:
 1. **Look at the workspace.** Is there a \`dypai/\` folder? A \`src/\`? A \`package.json\`? If you're using a Read/ls tool, check now.
 2. **Missing backend (\`dypai/\` absent)?** You have no endpoint YAMLs, no \`schema.sql\`, no node catalog. Cannot write queries, cannot push, cannot reason about the schema.
 3. **Missing frontend (\`src/\` or \`package.json\` absent)?** You have no React/Vite/Next code. Cannot change the UI, cannot run \`npm install\`, cannot test locally.
+
+**Having \`src/\` on disk does NOT mean the backend is on disk.** \`dypai/\` is a SEPARATE folder. Check for \`dypai/schema.sql\` specifically — if it's missing, the backend isn't materialized, even if the frontend clearly is. This is the #1 trap in hosts that default to file-first workflows (Claude Code especially): they see \`src/\` + \`package.json\` and assume the project is complete. Always verify \`dypai/schema.sql\` exists before touching data, queries, or endpoints.
 4. **If either is missing → sync FIRST:**
    - Ask the user for an absolute workspace path if you don't have one (e.g. \`/Users/me/code/my-app\`).
    - Run \`dypai_pull(project_id, out_dir: <abs>/dypai)\` — materializes backend (endpoints, SQL, prompts, schema.sql, node-catalog.json).