Manual test cases and UX behavior specifications that are impractical to automate.
- You fixed a UX bug that required human interaction to verify — document it here so it doesn't regress silently.
- You implemented a UX behavior with subtle invariants (z-order, modifier keys, pointer events) that would be fragile or verbose as code tests.
- You discovered an edge case during development that only manifests through real user interaction.
Do not add entries for pure logic, math, or data transformations — those belong in co-located __tests__/ or *.test.ts files.
- Copy
_template.mdand rename:{module}-{area}-{short-description}.md - Assign a unique ID:
TC-{MODULE}-{AREA}-{NNN}(increment NNN within the module+area) - Fill in all frontmatter fields —
statusstarts asuntested - Write the
## Behaviorsection as natural-language prose (design rationale, not just steps) - Write
## Stepswith enough detail for someone unfamiliar to verify
When code implements behavior documented here, add a comment pointing to the file:
// (see test/canvas-input-history-undo-cem.md)- One behavior per file. If a TC covers two independent behaviors, split it.
- Never delete a TC — set
status: deprecatedinstead (preserves history). - When automating: write the code test, add its path to
covered_by, setstatus: deprecatedonce fully covered. - Keep prose stable. Frontmatter fields change freely, but avoid rewriting
## Behaviorunless the actual behavior changed — git blame on that section is the audit trail.