42 lines
1.4 KiB
Markdown
42 lines
1.4 KiB
Markdown
# Delivery report (illustrative example)
|
|
|
|
This is an illustrative example, not a report from a real client project.
|
|
It shows the shape of the evidence attached to every pull request.
|
|
|
|
Change: availability parsing (a date and weekly hours)
|
|
Rules: reject 2026-02-30, accept 2028-02-29, accept 0 to 168 hours per week, reject 169
|
|
|
|
## Gates
|
|
|
|
```
|
|
[pass] spec 9 cases written before code
|
|
[pass] red 9 failing for the right reason
|
|
[pass] green 9/9 pass
|
|
[pass] mutation 14 mutants, 14 caught, 0 survived
|
|
[pass] coverage changed lines 100% (23/23)
|
|
[pass] typecheck clean
|
|
[pass] lint clean
|
|
verdict: pass
|
|
```
|
|
|
|
## Commands
|
|
|
|
Every gate is a command you can run yourself:
|
|
|
|
```
|
|
pnpm test # spec, red, green
|
|
pnpm test:mutation # mutation check on the changed files
|
|
pnpm test:coverage # coverage on changed lines
|
|
pnpm typecheck
|
|
pnpm lint
|
|
```
|
|
|
|
## How to read it
|
|
|
|
- spec: behavior written as concrete cases before any implementation exists.
|
|
- red: the new cases fail because the behavior is missing, not because of an import or compile error.
|
|
- green: all cases pass with the simplest clean solution.
|
|
- mutation: the code is changed on purpose (for example `<=` becomes `<`); the tests must fail. A surviving mutant means a weak assertion or dead code.
|
|
- coverage: shows which changed lines ran. It is a gap finder, not a goal.
|
|
- verdict is pass only if every gate passes.
|