Correctness

Free sample

Undocumented decisions, off-by-one, null/empty, conversions, logic inversion, state.

review/correctness.md · 1.9 KB

review/correctness.md

# Pass — Correctness

Run this on every change.

```
You did not write this code. Review it for correctness only — not style,
not performance, not architecture.

For each finding, give a CONCRETE failing scenario: specific input, specific
state, specific wrong output. If you cannot produce one, mark it as a style
opinion and put it at the end.

Look for:

1. UNDOCUMENTED DECISIONS
   Every place the code resolved something the requirement did not specify:
   a default chosen, an error type picked, an empty case handled, an
   ordering assumed. State what was chosen and what else it could have been.
   Look hardest here — these are the bugs that pass tests.

2. OFF-BY-ONE
   Loop bounds, slice ranges, pagination offsets, retry counts, "last N",
   inclusive vs exclusive ranges, index vs count.

3. NULL / EMPTY / MISSING
   For every value that could be absent: is it checked? Is absent handled
   differently from empty? Is empty handled differently from zero?

4. TYPE AND CONVERSION
   Integer division where a float was meant. Truncation. Signed/unsigned.
   Precision loss. Implicit string coercion. Timezone lost in a conversion.

5. LOGIC INVERSION
   Negated conditions, De Morgan mistakes, an early return that skips
   something it should not, a guard clause with the wrong comparison.

6. STATE
   Is anything mutated that the caller did not expect to be? Is a shared
   structure modified while iterated? Does a retry re-run a side effect?

7. THE STATED REQUIREMENT
   If a requirement was given: walk each point and name the code that
   implements it. List any with none.

Do not fix anything. Report findings only.
```

## What this pass misses

It reads the diff, so it cannot see a caller elsewhere in the codebase that
violates a new assumption. For that, run the pass and then ask separately:

```
Find every caller of the changed functions. For each, does the change alter
its behaviour? Quote file and line.
```

That was one of 20 files

The rest of Review & Repair is written the same way. $29 once, yours permanently, 14-day refund.

# Pass — Correctness Run this on every change. ``` You did not write this code. Review it for correctness only — not style, not performance, not architecture. For each finding, give a CONCRETE failing scenario: specific input, specific state, specific wrong output. If you cannot produce one, mark it as a style opinion and put it at the end. Look for: 1. UNDOCUMENTED DECISIONS Every place the code resolved something the requirement did not specify: a default chosen, an error type picked, an empty case handled, an ordering assumed. State what was chosen and what else it could have been. Look hardest here — these are the bugs that pass tests. 2. OFF-BY-ONE Loop bounds, slice ranges, pagination offsets, retry counts, "last N", inclusive vs exclusive ranges, index vs count. 3. NULL / EMPTY / MISSING For every value that could be absent: is it checked? Is absent handled differently from empty? Is empty handled differently from zero? 4. TYPE AND CONVERSION Integer division where a float was meant. Truncation. Signed/unsigned. Precision loss. Implicit string coercion. Timezone lost in a conversion. 5. LOGIC INVERSION Negated conditions, De Morgan mistakes, an early return that skips something it should not, a guard clause with the wrong comparison. 6. STATE Is anything mutated that the caller did not expect to be? Is a shared structure modified while iterated? Does a retry re-run a side effect? 7. THE STATED REQUIREMENT If a requirement was given: walk each point and name the code that implements it. List any with none. Do not fix anything. Report findings only. ``` ## What this pass misses It reads the diff, so it cannot see a caller elsewhere in the codebase that violates a new assumption. For that, run the pass and then ask separately: ``` Find every caller of the changed functions. For each, does the change alter its behaviour? Quote file and line. ```