A chess HTML5 project needs a legal-position model behind its 64 squares. Use an original pin fixture to test the boundary between a proposed move and a committed move, then test promotion as a choice that happens before commitment.
Put the legal model behind the board
The chess.js v1.4.0 documentation describes a headless rules library: it supplies legal-move and position operations, but no board interface or AI. The reviewed move API throws on an illegal request. Plan an exception path rather than relying on an older null-return convention.
Create native square buttons labeled with file, rank, piece and side, including empty squares. Display the current FEN, side to move, selected source, legal destinations, error and game-status labels separately. The display reads the committed model; dragging or selecting a square cannot become the authority for legality.
Pin the reviewed dependency version for the implementation plan. Verify its license, bundle and actual module resolution later. A package import written in documentation does not establish that a bare module name will resolve in the eventual HTML host. If loading fails, show an unavailable state and the readable fixture rather than functional-looking move controls.
Test a rook that protects its king
Use this original position, with White to move:
k3r3/8/8/8/8/8/4R3/4K3 w - - 0 1
White: king e1, rook e2
Black: king a8, rook e8
The black rook's e-file line runs toward White's king. White's rook on e2 blocks it.
| Proposed White move | Manual expectation | Reason |
|---|---|---|
| e2 → f2 | Reject | The e-file opens against White's king |
| e2 → e3 | Accept | The rook remains between e8 and e1 |
These are manually reasoned fixture expectations, not executed library results. The implementation must verify them against the pinned engine.
For each request, record FEN and turn before the attempt. Submit the proposed source and destination to the model. Only a successful move commits a new display and turn. On an exception, report the rejected request and confirm that model FEN, turn, history and displayed pieces still match the prior state. Do not optimistically move the rook and then reconstruct an old board by hand.
Generate destination highlights from the current model. Clearing the selected source clears its highlights; changing position invalidates every old selection and legal-destination list.
Ask for promotion before committing
Use a separate original fixture:
7k/P7/8/8/8/8/8/7K w - - 0 1
White: king h1, pawn a7
Black: king h8
The proposed a7 → a8 move needs an explicit promotion choice: queen, rook, bishop or knight, represented by q/r/b/n in the request. Keep the move pending until that choice is made. Cancel leaves the pawn, FEN, turn and history unchanged; it is not a completed pawn move followed by an undo.
Before committing, recheck that the pending choice belongs to the current position and session. Reset or a position-mode change retires a stale promotion request. Test each choice and cancel in the actual engine; no promotion fixture has been executed at this manuscript stage.
Label terminal states with their actual policy
Show the engine's check, checkmate, stalemate and draw status as distinct information. Do not implement “king captured” as the win condition. Use the reviewed library's game-over policy for a clearly labeled local casual adapter; its documented repetition behavior is not a claim of complete rated-tournament adjudication.
FEN specifies a position but is not a substitute for the sequence of prior positions when testing repetition history. A fresh fixture load and a played repetition sequence therefore need separate tests. Clocks, claims, arbiter procedures and full tournament compliance remain outside this adapter.
Reset restores the original selected mode and its starting FEN, a fresh move history, blank selection, no pending promotion and cleared errors. It must not retain highlights or callbacks from a different position.
Copyable board-adapter prompt
Create one complete, self-contained US-English HTML companion for “Chess · legal move inspector”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for Pinned rook; Promotion choice; Full starting board; Reset position; a8; b8; c8; d8; e8; f8; g8; h8. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Prepare an original native source plan and optional HTML chess-board adapter specification around reviewed chess.js v1.4.0. The library is headless; supply 64 native square buttons labeled file/rank/piece/side and separate FEN, turn, legal-destination, error and status panels. No AI or copied board artwork/code. Verify license, version, bundle and actual import resolution before implementation; failed loading shows an unavailable state, not working-looking controls.
Pin fixture: k3r3/8/8/8/8/8/4R3/4K3 w - - 0 1. White Ke1/Re2, Black Ka8/Re8. Manual expectations: e2-f2 exposes Ke1 and is rejected; e2-e3 preserves the block and is legal. Mark both unexecuted until checked with the actual engine.
The current move API throws for an illegal request. Snapshot model FEN/turn/history, submit a proposal, and render only a successful commit. Catch rejection and verify all prior model/display state remains consistent. Do not use old null-return assumptions or optimistic display mutation. Legal highlights come from the current model and clear on selection or source-position changes.
Promotion fixture: 7k/P7/8/8/8/8/8/7K w - - 0 1. Request a7-a8 with an explicit q/r/b/n choice before commit. Cancel changes nothing. Validate pending position/session before commit; Reset or mode change retires stale requests. Test all choices against the actual pinned engine.
Label check, checkmate, stalemate and draw separately; no king-capture win. Describe documented game-over/repetition semantics as the library's local casual policy, not full tournament adjudication. FEN alone cannot replace played repetition history. Reset restores the initial mode/FEN, fresh history, blank selection/promotion/errors. Provide pin, rejection integrity, promotion/cancel, source change, special-move and terminal test plans. Mark engine, keyboard, focus, 360 px, article-width and NOS runtime checks not_tested. No saved-game, export or host guarantee.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# Chess HTML5: Reject the Move Before Moving the Display
A rook can move horizontally, so your board lets it travel from e2 to f2. But that rook was blocking a line of attack against its own king. A board that checks only the piece's movement shape can display an illegal position and even change the turn afterward.
A chess HTML5 project needs a legal-position model behind its 64 squares. Use an original pin fixture to test the boundary between a proposed move and a committed move, then test promotion as a choice that happens before commitment.
## Put the legal model behind the board
The [chess.js v1.4.0 documentation](https://jhlywa.github.io/chess.js/) describes a headless rules library: it supplies legal-move and position operations, but no board interface or AI. The reviewed move API throws on an illegal request. Plan an exception path rather than relying on an older null-return convention.
Create native square buttons labeled with file, rank, piece and side, including empty squares. Display the current FEN, side to move, selected source, legal destinations, error and game-status labels separately. The display reads the committed model; dragging or selecting a square cannot become the authority for legality.
Pin the reviewed dependency version for the implementation plan. Verify its license, bundle and actual module resolution later. A package import written in documentation does not establish that a bare module name will resolve in the eventual HTML host. If loading fails, show an unavailable state and the readable fixture rather than functional-looking move controls.
## Test a rook that protects its king
Use this original position, with White to move:
text
k3r3/8/8/8/8/8/4R3/4K3 w - - 0 1
White: king e1, rook e2
Black: king a8, rook e8
The black rook's e-file line runs toward White's king. White's rook on e2 blocks it.
| Proposed White move | Manual expectation | Reason |
|---|---|---|
| e2 → f2 | Reject | The e-file opens against White's king |
| e2 → e3 | Accept | The rook remains between e8 and e1 |
These are manually reasoned fixture expectations, not executed library results. The implementation must verify them against the pinned engine.
For each request, record FEN and turn before the attempt. Submit the proposed source and destination to the model. Only a successful move commits a new display and turn. On an exception, report the rejected request and confirm that model FEN, turn, history and displayed pieces still match the prior state. Do not optimistically move the rook and then reconstruct an old board by hand.
Generate destination highlights from the current model. Clearing the selected source clears its highlights; changing position invalidates every old selection and legal-destination list.
## Ask for promotion before committing
Use a separate original fixture:
text
7k/P7/8/8/8/8/8/7K w - - 0 1
White: king h1, pawn a7
Black: king h8
The proposed a7 → a8 move needs an explicit promotion choice: queen, rook, bishop or knight, represented by q/r/b/n in the request. Keep the move pending until that choice is made. Cancel leaves the pawn, FEN, turn and history unchanged; it is not a completed pawn move followed by an undo.
Before committing, recheck that the pending choice belongs to the current position and session. Reset or a position-mode change retires a stale promotion request. Test each choice and cancel in the actual engine; no promotion fixture has been executed at this manuscript stage.
## Label terminal states with their actual policy
Show the engine's check, checkmate, stalemate and draw status as distinct information. Do not implement “king captured” as the win condition. Use the reviewed library's game-over policy for a clearly labeled local casual adapter; its documented repetition behavior is not a claim of complete rated-tournament adjudication.
FEN specifies a position but is not a substitute for the sequence of prior positions when testing repetition history. A fresh fixture load and a played repetition sequence therefore need separate tests. Clocks, claims, arbiter procedures and full tournament compliance remain outside this adapter.
Reset restores the original selected mode and its starting FEN, a fresh move history, blank selection, no pending promotion and cleared errors. It must not retain highlights or callbacks from a different position.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Optional use for the prepared board
Keep the native source plan and model-state fixtures as the primary developer materials. The HTML companion is available above for comparison with the original records. Verify dependency loading, legal moves, promotion and display consistency in the actual workspace before treating it as tested.