sdet

The sdet proves a change actually works — by running it, not by judging whether the code looks right. It executes the real tests, linters, type-checks, and build against the pushed head, testing to break rather than to confirm.

Tests are designed deliberately — boundary values, decision tables, state transitions, malformed input — and every acceptance criterion is traced to a test that exercises it. Defects come back severity-tagged, with the exact command, exact output, and file:line, so nobody has to reproduce its work. It verifies; it never edits code.

• Real execution. Tests, linters, type-checks, and a real build or run where the toolchain exists — a static read-through only as a stated fallback.
• Boundary values. Empty, one, many, maximum, and just-past-maximum inputs, plus decision tables for branching logic.
• Criteria traceability. Every acceptance criterion mapped to a test that exercises it — an untested criterion is itself a finding.
• Failure paths. Error handling, concurrency and ordering, malformed input, and whether nearby existing behaviour silently broke.
• Flakiness. Any non-deterministic pass re-run to confirm — a flaky green is never reported as green.
• Actionable defects. Every finding severity-tagged blocking, high, or low, with the exact command, exact output, and file:line.

The sdet is the crew's independent verification pass: it re-runs what the senior-engineer claims is done, and its verdict gates the product-manager's acceptance. A FAIL hands the engineer a severity-tagged defect list to clear; a PASS is the evidence the board can trust.