- 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.6 KiB
Step 4: Testing
Display: Orientation → Walkthrough → Detail Pass → [Testing]
Follow Global Step Rules in SKILL.md
- This is experiential, not analytical. The detail pass asked "did you think about X?" — this says "you could see X with your own eyes."
- Do not prescribe. The human decides whether observing the behavior is worth their time. Frame suggestions as options, not obligations.
- Do not duplicate CI, test suites, or automated checks. Assume those exist and work. This is about manual observation — the kind of confidence-building no automated test provides.
- If the change has no user-visible behavior, say so explicitly. Do not invent observations.
IDENTIFY OBSERVABLE BEHAVIOR
Scan the diff and spec for changes that produce behavior a human could directly observe. Categories to look for:
- UI changes — new screens, modified layouts, changed interactions, error states
- CLI/terminal output — new commands, changed output, new flags or options
- API responses — new endpoints, changed payloads, different status codes
- State changes — database records, file system artifacts, config effects
- Error paths — bad input, missing dependencies, edge conditions
For each observable behavior, determine:
- What to do — the specific action (command to run, button to click, request to send)
- What to expect — the observable result that confirms the change works
- Why bother — one phrase connecting this observation to the change's intent (omit if obvious from context)
Target 2–5 suggestions for a typical change. If more than 5 qualify, prioritize by how much confidence the observation provides relative to effort. A change with zero observable behavior is fine — do not pad with trivial observations.
PRESENT
Output as a single message:
Orientation → Walkthrough → Detail Pass → [Testing]
Then the testing suggestions using this format:
### How to See It Working
**{Brief description}**
Do: {specific action}
Expect: {observable result}
**{Brief description}**
Do: {specific action}
Expect: {observable result}
Include code blocks for commands or requests where helpful.
If the change has no observable behavior, replace the suggestions with:
### How to See It Working
This change is internal — no user-visible behavior to observe. The diff and tests tell the full story.
Closing
End the message with:
---
You've seen the change and how to verify it. When you're ready to make a call, just say so.
NEXT
When the human signals they're ready to make a decision about this {change_type}, read fully and follow ./step-05-wrapup.md