Full-stack web application development — frontend, backend, APIs, databases, auth, UI/UX. Use when building webapps, websites, SPAs, REST or GraphQL APIs, or anything with a browser-facing interface.
Use when the goal involves any of:
Do NOT use for:
data_science)Web projects are multi-file and layered. A "simple login app" is not one file — it is models, migrations, middleware, routes, views, components, an API client, and error handling.
When the user asks for a webapp:
compute with mode:"deep" and skill:"webdeveloper" — the architect needs room to decompose into many coherent files. A shallow compute producing one giant file is the wrong shape for web work.setup commands and the scheduler grafts them automatically. Trust the compute pipeline.Decompose webapps the way a real engineering team would: deep, layered, with clear ownership boundaries. Not three files. A real webapp is 10–25 files.
The blueprint is the SOLE source of truth. Every file path, every directory, every config — defined in the blueprint. Coders write exactly what the blueprint says. Nothing else decides the project structure.
No scaffolders. Do NOT use npx create-next-app, npm create vite, create-react-app, or any scaffolding tool. They produce unpredictable directory structures that conflict with the blueprint. Instead, create all files explicitly through tasks — package.json, tsconfig.json, config files, entry points — everything. The blueprint owns the structure.
Default frontend: Vue 3 + Vite. Unless the user asks for React, Next.js, Svelte, etc., always use Vue 3 with <script setup>, Vite, and Tailwind CSS. Vue is lightweight, fast, and the coders handle it reliably. No Server Component confusion, no 'use client' directives.
Setup commands are for mkdir -p and npm install only:
"setup": [
"mkdir -p project/frontend/src/views project/frontend/src/components project/frontend/src/stores project/frontend/src/api project/frontend/src/router project/frontend/public",
"mkdir -p project/backend/src/routes project/backend/src/middleware project/backend/src/models project/backend/db",
"cd project/frontend && npm init -y && npm install vue vue-router pinia axios",
"cd project/frontend && npm install -D vite @vitejs/plugin-vue tailwindcss postcss autoprefixer",
"cd project/backend && npm init -y && npm install express better-sqlite3 bcrypt jsonwebtoken cors dotenv"
]
Separate frontend and backend cleanly. Typical layout for a full-stack app:
project/
frontend/
src/
views/ — page-level components (Home.vue, Login.vue, Dashboard.vue)
components/ — reusable UI pieces (HeroSection.vue, ThemeToggle.vue)
stores/ — Pinia stores (auth.js, user.js)
api/ — HTTP client, endpoint wrappers (auth.js, client.js)
router/ — route definitions (index.js)
App.vue — root component
main.js — entry point
style.css — global styles + Tailwind directives
index.html — Vite entry HTML
package.json
vite.config.js
tailwind.config.js
postcss.config.js
backend/
src/
routes/ — one file per resource
middleware/ — auth, logging, error, CORS
models/ — data access, one per entity
server.js — entry point
db/
seed.js — database init + seed
package.json
Design the interfaces before decomposing. Use the interfaces field to lock the REST API contract so frontend and backend coders produce compatible code:
"interfaces": {
"POST /api/auth/register": {"request": {"email": "string", "password": "string", "name": "string"}, "response": {"token": "string", "user": {"id": "number", "email": "string", "name": "string"}}},
"POST /api/auth/login": {"request": {"email": "string", "password": "string"}, "response": {"token": "string", "user": {"id": "number", "email": "string"}}},
"GET /api/users/me": {"headers": {"Authorization": "Bearer <token>"}, "response": {"id": "number", "email": "string", "name": "string"}}
}
Design the database schema up front. Use the schema field. Default to SQLite unless the user asked for something specific:
"schema": {
"type": "sqlite",
"tables": {
"users": "id integer primary key autoincrement, email text unique not null, password_hash text not null, name text not null, created_at text default (datetime('now'))"
}
}
One file per task. Each task owns exactly one file. Large webapps become many tasks. Don't group server.js + auth.js + routes.js into one task — split them.
Config files are tasks too. package.json, vite.config.js, tailwind.config.js, postcss.config.js, index.html — each is a task that writes the complete file. The setup command does npm init -y to create a skeleton, then a coder task overwrites package.json with the correct scripts and config. The package.json MUST include scripts: {"dev": "vite", "build": "vite build", "preview": "vite preview"}.
Execute and service fields. For the final task that starts the dev servers, use service:
{"service": {"command": "node project/backend/src/server.js", "name": "backend"}}
{"service": {"command": "npm run dev --prefix project/frontend", "name": "frontend"}}
service field. Without both, validators that hit either server will fail.npx create-next-app, npm create vite, create-react-app, django-admin startproject, or any scaffolding tool. Create every file through blueprint tasks. The blueprint is the sole authority on project structure.execute field to apply them (e.g. "execute": "node project/backend/db/seed.js").service field."cd project/frontend && npm install && npm run build". Never just npm run build alone.--yes, -y flags.check field MUST be a shell command (curl, node -e, test). NEVER prose like "Manual test". Use ACTUAL ports from your services. Example:"validation": [
{"name": "backend health", "check": "curl -sf http://localhost:4000/health", "expect": "returns 200"},
{"name": "frontend loads", "check": "curl -sf http://localhost:3000/", "expect": "returns 200 with HTML"},
{"name": "auth register", "check": "curl -sf -X POST http://localhost:4000/auth/register -H 'Content-Type: application/json' -d '{\"email\":\"[email protected]\",\"password\":\"pass123\",\"name\":\"Test\"}'", "expect": "returns token"}
]
2-5 checks total. Every check must be a command that exits 0 on success.
10. If the workspace already has files, scan them first. Check existing package.json, directory structure, and config before planning. Write the blueprint around what exists — extend, don't overwrite.
When diagnosing web app failures, follow this procedure — don't guess, read the evidence:
Service not responding (curl connection refused):
Build fails (vite build, npm run build):
npm install fails:
package.json issues:
Every file you write is production code. No stubs, no TODOs, no skeleton functions. Match the depth the file's purpose calls for.
UI components (Vue / React / Svelte):
<button>, <form>, <label>, <nav>, <main> — not <div> for everything.aria-label on icon-only buttons, aria-invalid on bad inputs, keyboard focus visible, alt text on images, semantic landmarks.Forms specifically:
Backend routes:
{"error": "message", "code": "ERR_CODE"} — not plain text, not HTML.Database models:
API clients (frontend):
State management:
CSS and styling:
File shape:
console.log left behind, no dead branches.Never ship:
TODO or FIXME or HACK comments.throw new Error("not implemented").console.log debug output in production paths.