This original JavaScript Sudoku source plan separates immutable givens, editable entries, conflicts and complete solutions. It uses a deliberately simple teaching fixture. Use the local HTML/JavaScript example to inspect the fixture, then verify input behavior in the intended host.
Start with a board whose completion you can explain
For this original 9-by-9 fixture, the first eight rows are givens and the ninth row is blank:
123456789
456789123
789123456
234567891
567891234
891234567
345678912
678912345
_________
There are 72 immutable givens and nine editable cells. This is a teaching fixture for input and constraint checks, not an expert puzzle or generated difficulty level. Keep the native board definition and developer key separate from the blank learner copy.
The expected ninth row is 912345678. Each column's eight givens omit exactly one digit, so each final-row value is forced. The resulting board also satisfies the row and 3-by-3 box constraints. This establishes uniqueness for this fixture without claiming a puzzle generator exists.
Indiana State's Sudoku PDF describes the cell, row, column and box constraints. We use those constraints, not its exact-cover algorithm, source code or illustrations. Sudoku Constraints
Keep givens and entries separate in the source model
The later implementation should maintain an immutable original-givens record and a separate editable-entry state. A cell identified as given must never be changed by typing, paste, clearing or reset. Completion checking should also confirm that every given still matches its original value.
Label cells by row and column using one-based notation such as r9c1. Give editable cells accessible row/column instructions and a visible given/editable distinction that does not depend only on color.
Accept a blank or a single digit 1–9 as the full committed entry. Zero is not a blank or an allowed Sudoku digit. Reject malformed and multi-digit values without silently truncating them. Validate committed input—including paste and composition/IME paths—rather than relying only on a global keydown handler. Check those input routes in the intended host rather than inferring their behavior from the input rules.
Explain a conflict with its unit
At the blank baseline, try r9c1 = 1. Column 1 already contains r1c1 = 1, so the entry conflicts. Show the conflicting column evidence rather than merely displaying “wrong.” Clearing the attempted value removes that conflict and leaves the board incomplete.
In a separate baseline attempt, r9c2 = 1 fits this fixture, but eight final-row cells remain blank. Report a valid partial state, not a win. Reevaluate every affected row, column and box after edits, and clear stale completion or conflict feedback.
The user needs to distinguish invalid input from an allowed digit that violates a board rule. Neither case may alter the immutable givens.
Require a complete valid board
Report completion only when all of these hold:
- All 81 cells contain valid digits 1–9.
- Every row, column and 3-by-3 box contains each digit exactly once.
- Every given is unchanged.
Do not equate “no duplicates among entered cells” with completion. Do not accept a filled board solely because it matches an arbitrary stored key without validating the constraints and givens.
For the original fixture, completing the last row with 912345678 satisfies the guard. A fully blank-board variant has many solutions; finding one solved board would not establish uniqueness. If generation is added later, count solutions up to two to distinguish none, unique and multiple before describing a published puzzle as unique. This example does not include a generator or solution-counting implementation.
Define clear and reset precisely
Clear removes an editable entry and updates the board status. Reset clears all nine editable cells, preserves all 72 givens and returns completion to incomplete. It does not replace the original puzzle or imply saved progress after reload.
Use a native fixture/test matrix for given protection, invalid input, conflicting entry, valid partial entry, full valid completion and reset. Actual keyboard/touch/IME/paste, narrow-screen and host behavior must be tested after authorized implementation. No score, storage, network collection or learner mastery claim is included.
Copy this prompt for the Sudoku source plan
Prepare an original US-English JavaScript Sudoku source plan, native board/key and test matrix only. No HTML/JS implementation or executed game. Nine rows:123456789/456789123/789123456/234567891/567891234/891234567/345678912/678912345/blank nine cells. First 8 rows, 72 givens immutable; last row, 9 editable cells. Teaching fixture not expert/generator. Expected last row 912345678, unique because each column omits one forced digit; completed rows/columns/boxes valid.
Separate original givens from entry state, label row/column. Blank or one committed digit 1–9 only, no zero/noninteger/malformed/multidigit/truncation. Given cells cannot mutate via input/paste/clear/reset. Validate committed input/IME/paste, not global keydown alone. r9c1=1 conflicts column 1, r1c1=1; clear restores incomplete. Separate baseline r9c2=1 fits but remains incomplete. Feedback recomputed after edits.
Win requires 81 filled valid digits, every row/column/3×3box unique 1–9 and givens unchanged; partial no-duplicates not win, no key-only validation. Clear editable only, reset all 9 editable cells preserving 72 givens. Fully blank board has many solutions; one solver result not uniqueness. Future generation needs solution count up to 2 none/unique/multiple, not implemented. Native developer key separate not secrecy guarantee. Actual input/keyboard/touch/360px/host tests pending. No copied PDF code/puzzle/art, scores/storage/network/assessment or difficulty guarantee.
Review the rule evidence beside the cell
The local HTML board places the given/entry distinction, conflict evidence and completion state together. NOS supports saving and rendering prepared HTML; verify input behavior in the intended host. Retain the native board and test record.
Explore NOS to present the prepared constraint review. A player should be able to tell why an entry conflicts, why a partial board is incomplete and what establishes a valid finish.