Testing New Features

Clone the repository and open its folder:

git clone https://github.com/avivz/aicode-lab05-chess.git
cd aicode-lab05-chess

Ask your agent to create a virtual environment named .venv and install requirements-dev.txt in it. Activate it in each terminal you use for the game or tests:

source .venv/bin/activate

Start the server:

python3 server.py

Open http://127.0.0.1:8000. Have your agent run the tests in another terminal:

python -m pytest

One of you (replace YOU and PARTNER with your GitHub user names):

gh repo create aicode-lab05-chess --private
git remote add team https://github.com/YOU/aicode-lab05-chess.git
git push -u team main
gh api -X PUT repos/YOU/aicode-lab05-chess/collaborators/PARTNER

The other accepts the invitation at https://github.com/YOU/aicode-lab05-chess/invitations, then:

git remote add team https://github.com/YOU/aicode-lab05-chess.git
git fetch team

From then on, git push -u team <branch> shares a branch and git fetch team gets your partner’s.

1. Implement these two features separately, on branches from the same starter commit: one partner adds save and load, with controls to save a game to a file and resume it later; the other adds undo, with a control that lets the player reverse the last move. Agree on shared game information. Each branch must include its own tests for the feature it adds. Have your agent write and run those tests before merging, then review the changes and results.
2. Merge both features into main and try them together. Run your tests and play the game. Have your agents add checks for combined behavior that your separate tests do not cover.
3. Integrate the supplied branches into main, one at a time: first feature/captured-pieces, which displays captured pieces, then feature/promotion, which lets the player choose a new piece when a pawn reaches the far rank. After each merge, run the existing tests and try the combined game before asking your agent to repair anything. Investigate anything unexpected, have your agent add a test that reproduces it, and fix it together. Alternate who operates the agent. After each merge, ask yourself: do the tests cover the features working together? Check the results before fixing failures. Read the relevant assertions and changes. Keep the tests and rerun them as you continue. If everything works immediately, show which check establishes that.

Save/load and undo requirements

• Save/load: add controls to save to a file and load in a fresh instance. Preserve the board, turn, move notation, opponent mode, and history needed to undo earlier moves.
• Undo: add a control that reverses a move, restores any captured piece, and updates the turn and notation. Repeated undo reaches the start; undo there does nothing. Against the computer, it follows your agreed behavior.

Supplied features: behavior and branch names

Merge feature/captured-pieces, then feature/promotion (possibly under origin/ in a clone).

• Captured pieces: the display lists pieces actually captured in the current game.
• Promotion: a pawn reaching the last row on the opposite side becomes a queen, rook, bishop, or knight, chosen by its player.

To try promotion, start a new two-player game and follow the moves below. Each square has a letter for its column and a number for its row, shown along the board’s edges: a2 means column a, row 2. Click the piece, then its destination square.

Take turns moving the same white and black pawns:

The white pawn has reached the opposite end of the board. Choose which piece it becomes when the game asks—for example, a queen. This is promotion.

Have your agent run ruff check, ruff format --check, and mypy --strict, then run the tests and produce a test coverage report. Read the commands, results, and useful findings before making changes.

The coverage report shows which parts of the code ran during the tests. Does it cover everything? Discuss the gaps with your agent, including behavior the tests might not check even when the code runs.

For a repaired failure, run the tools at its first failing revision in a scratch worktree. Does a finding explain its cause?

Add redo together: a control that restores the move the player just undid. Decide the expected outcomes before implementing redo with your undo mechanism:

• Undo → redo restores a capture or promotion, including the chosen piece and display.
• Undo → save → load → redo works: preserve the redo continuation in the save file.
• Undo → play a different move discards the old redo continuation.
• Against the computer, agree on which moves redo restores and whether its reply may change.
• A new game clears both undo and redo history.

Try adding an automatic tie when only the two kings remain, since neither can checkmate the other. This condition is not yet detected; stalemate is already handled. Other ideas: a new piece pawns can promote to, a randomly arranged starting row of pieces, or a limit of three undos per player. You can invent another rule.

Identify affected features and what must be saved or restored. Have your agents add checks for your expected outcomes and test both rules after merging.