- Nx 22.7 monorepo (pnpm 11.1, TypeScript 5.9, Node 24) - apps/api: NestJS 11 (CJS conforme CODING-RULES.md PGD-DB-004) - apps/web: React 19 + Vite 8 (ESM) - libs/shared/api-interface: Zod contract base - Docker Compose dev: Postgres 18, Valkey 8, MinIO, Mailpit - WDS artifacts: - design-artifacts/A-Product-Brief/ (5 docs canônicos + 16 dialogs) - design-artifacts/B-Trigger-Map/ (hub + 4 personas + feature impact) - Stack canon: STACK.md v2.2 + CODING-RULES.md v2.0 + brand.md - AGENTS.md + README.md como entrada para devs/agentes Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.1 KiB
Product Brief: {{project_name}}
The strategic foundation — why this product exists, who it serves, and what success looks like.
Created: {{date}} Phase: 1 — Product Brief Agent: Saga (Analyst)
What Belongs Here
The Product Brief answers five strategic questions:
- Why does this product exist? (Vision & business goals)
- Who is it for? (Target users and their context)
- What does it need to do? (Core capabilities)
- How will we know it works? (Success metrics)
- What are the constraints? (Platform requirements, tech stack)
Everything downstream — trigger maps, scenarios, page specs, design system — traces back to decisions made here. This is the North Star.
Learn more:
- WDS Course Module 04: Product Brief — Your Strategic Foundation
- WDS Course Module 05: Platform Requirements
For Agents
Workflow: skill:wds-1-project-brief
Agent trigger: PB (Saga)
Templates: ./resources/wds-1-project-brief/templates/
Before writing anything in this folder:
- Load the workflow and follow its steps
- Use Dialog mode for discovery — ask questions, don't assume
- Read existing materials if the user has them (check
wds-project-outline.yaml)
File naming: Number all documents with a two-digit prefix: 01-product-brief.md, 02-content-language.md, etc. Platform Requirements is always last — it summarizes technical decisions that emerge from the strategic documents above. Update the Documents table below as each file is created.
Harm: Producing a brief from assumptions instead of conversation. A brief that doesn't reflect the user's actual goals forces every later phase to build on a wrong foundation.
Help: Asking the right questions, listening deeply, and documenting what the user actually said. A good brief makes every later decision easier.
Documents
This section will be updated as documents are created during Phase 1.
| # | Document | Status |
|---|---|---|
| 01 | Product Brief | Not started |
| 02 | Platform Requirements | Not started |
Created using Whiteport Design Studio (WDS) methodology