Phase 2 — Architect

How we're going to build what was agreed on in Design.

🎯 Goal

Turn the what (Design) into a viable technical plan: architecture, folder structure, data models, API contracts, dependencies, and — crucially — explicit trade-offs.

📋 What goes into BLUEPRINT.md

1. Architectural overview

Diagram (ASCII or Mermaid) showing the components and how they connect.

2. Chosen stack (with rationale)

Which language, framework, database, infra. WHY this one and not others?

**Backend:** Node.js 20 + NestJS 11
- ✓ Team already knows it
- ✓ Strong typing
- ✓ Decorators make validation and auth easier

Considered but rejected:
- Go: excellent performance, but the whole team would need to learn it
- Plain Express: would lack structure, team would lose productivity

3. Directory structure

Exact layout of folders/files that will be created or modified.

4. Data models

Schemas, entities, migrations. In the concrete format of the chosen stack.

5. API contracts / interfaces

Endpoints, payloads, return values. In OpenAPI, GraphQL schema, or markdown tables.

6. Architectural decisions (ADR-style)

Each important decision with: context, options considered, decision, consequences.

7. Preliminary task list

Breakdown of the work into items. Refined later with /generate-tasks.

8. Risks and mitigations

What could go wrong? How are we going to respond?

🤖 How the AI generates the Blueprint

The AI takes the DESIGN.md and proposes a complete architecture. It should:

• ✅ List at least 2-3 alternatives for important decisions
• ✅ Make trade-offs explicit (don't paint a choice as "obvious")
• ✅ Consider constraints from the Design (mandatory stack, deadline, etc.)
• ✅ Leverage loaded skills (e.g., the Laravel API skill teaches the stack's patterns)
• ✅ Flag the assumptions it's making

What the AI should NOT do:

• ❌ Implement real code (that's Execute)
• ❌ Suggest libraries that don't exist (verify first!)
• ❌ Present 1 option as "the best" without an explicit trade-off

🚀 How to trigger it (Cursor)

/generate-blueprint DARE/DESIGN.md

Or, if you want the AI to refine something specific:

/generate-blueprint DARE/DESIGN.md

Special focus on deciding between PostgreSQL and MongoDB for storage.

Output: DARE/BLUEPRINT.md in the canonical format.

✅ Criteria for "Blueprint ready for Review"

Before moving on to the Review phase, the AI should ensure:

• Covers all success criteria from DESIGN.md
• Non-goals from DESIGN.md respected (don't design things outside the scope)
• Explicit trade-offs in at least 3 important decisions
• Concrete folder structure (not "a folder for controllers")
• Assumptions listed separately
• Risks enumerated with preliminary mitigation

🚫 Common anti-patterns

"Blueprint without alternatives"

If every decision shows up as "we'll use X" without mentioning the Y and Z that were considered, the Blueprint is shallow. Ask the AI to expand the trade-offs.

"Hyped stack without rationale"

"We'll use Bun + Hono + Drizzle because it's modern." Why does your team / project benefit from this vs. the alternatives? Without rationale, it's cargo culting.

"Generic tutorial structure"

controllers/, services/, repositories/ without thinking about whether it makes sense for the problem. For a 5-endpoint app, this is over-engineering.

"Empty risks"

A list of "performance might be a problem" with no mitigation. A risk listed without a response plan = theater.

🔄 Iteration

If while generating the Blueprint you notice that the DESIGN.md has a gap (missing information, contradiction, poorly defined scope), go back to Design and redo it. Don't try to compensate in the Blueprint.

📂 Templates

• templates/BLUEPRINT-template.md (each implementation has a copy)

🔗 Next

Phase 3: Review →