off-by-nonelisted

# Spec-Faithful Implementation with Independent Verification ## Overview Self-written tests inherit the same misreading as your implementation, so they pass while the code is wrong. This skill forces test cases to be derived from the spec's literal wording BEFORE implementing, with mandatory boundary-value coverage. **Core principle: a test derived from your implementation verifies nothing. Derive every test from the spec's exact words.** ## Workflow 1. **Requirements ledger.** Number every clause of the spec, including sub-clauses hidden inside sentences ("then re-apply rule 6" is its own entry). One checklist item per clause. 2. **Derive tests from the spec text — before writing any implementation code.** - For every clause, write at least one case using only the spec's wording, not your planned code. - **Boundary rule (mandatory):** every numeric limit or boundary word — "at", "at or before", "exceeds", "up to", "at least", "within" — gets three cases: exactly N-1, exactly N, exactly N+1. Compute the expected outputs by hand from the spec sentence, character by character if needed. - **Boundary words bind to what they modify.** "At or before max_len" about a *position* (a delimiter, a marker, a match) requires a test where that thing sits exactly AT position max_len — a test where only the total *length* is at the limit does not cover it. For each boundary phrase, name the noun it modifies (length? index? count? position?) and put the test exactly there.