Tirsvad-Udemy-100-days-of-code/024-snake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request 'Plan: Snake Game (Day 24) baseline' (#1) from plan-baseline into main
TirSystem/github-action: Sync GitHub mirror metadata / sync-metadata (push) Successful in 6s
Details

Browse Source
This commit was merged in pull request #1.
This commit is contained in:
Tirsvad
2026-10-13 08:12:26 +02:00
parent a73e941fb6 e79d974bdb
commit df35c8bacd
20 changed files with 1518 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitmodules
+3
View File
@@ -0,0 +1,3 @@
[submodule "framework"]
path = framework
url = ssh://git@git.tirsystem.com:10022/TirSystem/SQA-QC-Framework.git
docs/artifact-registry.md
+59
View File
@@ -0,0 +1,59 @@
# Artifact Registry
This project's artifact state. Types, short names and `CrossReference
Candidates` come from the framework catalog
(`framework/registry/artifact-catalog.md`); this file only records where
each document lives in *this* project and the next version to use.
Delete rows for types you don't use. Add a row the first time you create a
document of a type. `Primary File` may contain a glob (e.g.
`docs/uc-*/uc.md`); `framework/scripts/find-crossreferences.sh` reads it.
| Short Name | Artifact Type | Primary File | Next Available Version |
| --- | --- | --- | --- |
| BC | Business Case | docs/business-case.md | 002 |
| SA | Stakeholder Analysis | docs/stakeholder-analysis.md | 002 |
| PP | Project Plan | docs/project-plan.md | 002 |
| MIL | Milestone / Gateway | docs/milestones/*.md | 006 |
| DICT | Domain Dictionary | docs/dictionary.md | 002 |
| RC | SQA Review Record | docs/sqa/reviews/rc-*.md | 009 |
## Languages
Set the PO language when the project starts; `project-planning` asks for it
if it is missing. An artifact of a type marked "Written in the PO language"
exists once, in that language, under its normal name (`business-case.md`); the
`artifact` skill ("One file per artifact") has the rule.
| Setting | Value |
| --- | --- |
| PO language | en |
| PO domain | it |
| High-level register | IT Executive English |
| Technical register | IT Professional English |
Every artifact of a type marked "Yes" below states its language and domain in
its `Language` and `Domain` Metadata rows; `new-artifact.sh` fills them from
`PO language` and `PO domain`. `Language` is a BCP 47 code (`da`, `en`).
`Domain` is a value from this list; add a row to introduce a domain, so a
reviewer can see at once which professional vocabulary a document uses.
| Domain | Meaning |
| --- | --- |
| it | Software and IT |
| medical | Healthcare and medical devices |
| construction | Construction and civil engineering |
| Artifact types | Register | Written in the PO language |
| --- | --- | --- |
| BC, KPI, PP, MIL | IT Executive English | Yes |
| SA, BMC, BPMN, UCD, US, UC, SSD, DM, RA, GOV, DICT | IT Professional English | Yes |
| OC, SD, DCD, ERD, ADR, TM, RC, QC, source code | IT Professional English | No |
## Notes
- "Next Available Version" is the zero-padded (3-digit) version to use the
*next* time a new document of that type is created. Increment it only when
a brand-new document is created, not when an existing document's
`## Version History` gets a row.
- `ADR` uses 4 digits (`0001`); `RC` is sequential across all artifact types.
docs/business-case.md
+185
View File
@@ -0,0 +1,185 @@
# Business Case: Snake Game (Day 24)
## Metadata
| Key | Value |
| --- | --- |
| ID | BC-001 |
| CrossReference | [SA-001], [DICT-001] |
| Language | en |
| Domain | it |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-001 (Go) | [e004c34] |
---
## Executive Summary
Snake Game (Day 24) is the day-24 assignment of Udemy's *100 Days of Code: The Complete Python Pro Bootcamp*: the snake game of days 20 and 21 gets a high score that survives between games. Day 24 teaches the local file system and reading and writing files with `open` and the `with` keyword. Applied to the game, the lectures change four things: the scoreboard keeps a `high_score` next to the score, the game no longer ends on a collision but resets the snake and the score and goes on, the high score is read from and written to the file `data.txt`, and so it is still there when the game is started again.
This repository starts from the finished game of the day-21 repository [021-snake-game] (the same way that repository started from [020-snake-game]), changes it as the day-24 lectures describe, and gives it the identity of this repository: name, README, description, topics and a wiki in English, Danish and Bahasa Melayu. The work is planned in five milestones, each delivered by one branch and one pull request. The game has no runtime dependencies.
## Methodological and Standards Foundation
- **Process:** the Software Quality Assurance (SQA) and Quality Criteria (QC) framework mounted at `framework/`: Business Case, Stakeholder Analysis, Project Plan, milestones, tasks synced as issues, then code, each step reviewed before the next. Analysis follows Larman, *Applying UML and Patterns*.
- **Quality model:** ISO/IEC 25010:2023; every QC criterion is tagged with a characteristic of it.
- **Code:** Python Enhancement Proposals (PEP) 8, 257 and 484, reviewed against `QC-PY-001`; comments in Doxygen style; tests with pytest.
- **Domain terms:** the lectures' own terms and names, recorded in the Domain Dictionary [DICT-001]: screen, snake, segment, head, food, score, scoreboard, high score, reset, game over, file, mode (`r`, `w`, `a`), `with`, and the names `Snake`, `Food`, `Scoreboard`, `reset`, `high_score`, `update_scoreboard`, `increase_score`.
## Problem Statement
- The high score of the lectures lives in a variable, so it is zero again each time the game is started; the lecture itself calls this out as a flaw.
- A game that stops at the first collision cannot be played again without starting the program again, so a high score has nothing to compete against.
- Reading and writing a file is easy to get subtly wrong: a file left open, a text that is not a number, a file that does not exist yet. The lecture shows the happy path only.
- A turtle program opens a window, so it is normally not tested, and the file handling needs tests that touch no real window and do not overwrite the player's real high score.
- A repository without a description, topics, README or wiki is hard to find and to judge for the people who browse for ideas.
## Business Opportunity
A finished, reproducible repository shows the path from the day-24 lectures to documented, tested code. Starting from the finished day-21 game saves the rebuild, so the effort goes into what is new: continuous play, the high score and its persistence, and the testing of the file handling. It can be compared with the solutions of other participants and shared.
## Objectives
| # | Objective |
| --- | --- |
| 1 | Keep the behaviour of the day-21 base: a 600 by 600 black window titled "My Snake Game"; a snake of three segments that moves by itself and turns with the arrow keys without reversing; food that is eaten, makes the snake longer and raises the score |
| 2 | Deliver the high score of the lectures: `Scoreboard` has a `high_score` attribute that starts at the stored value, and the scoreboard shows `Score: <score> High Score: <high_score>` |
| 3 | Deliver continuous play: `Scoreboard.game_over` is replaced by `Scoreboard.reset`, which sets `high_score` to the score when the score is higher, sets the score to 0 and writes the scoreboard again; touching the wall or the tail calls `reset` of the scoreboard and of the snake and the game goes on |
| 4 | Deliver `Snake.reset`: every segment is moved off the screen, the segment list is emptied, the snake is created again at the starting positions and `head` is the first new segment |
| 5 | Deliver the persistence of the lectures: the high score is read from `data.txt` with `with open(...)` when the scoreboard is made and written to it, as text, when a new high score is reached; the value is still there after the game is closed and started again |
| 6 | Handle the file robustly where the lecture does not: a missing file is created with 0, and a file that does not hold a whole number is treated as 0 |
| 7 | Keep the assignment's structure and names (`Snake`, `Food`, `Scoreboard`, `create_snake`, `add_segment`, `extend`, `move`, `reset`, `up`, `down`, `left`, `right`, `segments`, `head`, `high_score`, `update_scoreboard`, `increase_score`, `game_is_on`), constants in `constants.py` |
| 8 | Provide a reproducible environment: Python 3.13 or newer, a local `.venv`, a `pyproject.toml`, and zero runtime dependencies |
| 9 | Prove the behaviour with pytest tests that need no display and never touch the player's real `data.txt` |
| 10 | Document the project: Doxygen comments in the source with a `Doxyfile`, and a README with set-up instructions for Windows PowerShell, Linux Debian and macOS |
| 11 | Keep every step traceable: one branch and one pull request per milestone, each pull request closing the issues it completes |
| 12 | Publish the repository with a description and topics, and a wiki in English, Danish and Bahasa Melayu |
## Scope
### In Scope
- Adopting the finished game of [021-snake-game] (source, tests, configuration, continuous integration workflow) as the base of this repository, and recording every difference from it.
- The day-24 lectures about the snake game: the high score attribute, `reset` instead of `game_over`, continuous play, `Snake.reset`, and reading and writing `data.txt`.
- Constants in `constants.py`; source in `src/`, tests in `tests/`, documents in `docs/`.
- `pyproject.toml`, Python `.gitignore`, `Doxyfile`, `README.md` following the Product Owner's template, a continuous integration (CI) workflow.
- Repository description and topics on the git host.
- A wiki in English, Danish and Bahasa Melayu, in the form of the wiki of `TirSystem/github-action`.
### Out of Scope
- The day-24 project that follows the snake game, the personalised letters (mail merge); it is a separate program and gets its own repository if S01 wants it (see the open issues of [PP-001]).
- File paths and directories beyond the single file `data.txt`; the lecture announces them as the next topic.
- Anything the lectures do not cover: sound, a menu, a list of players, levels, configurable speed or window size.
- Keeping this repository and [021-snake-game] in step after today.
- Packaging for or publishing to the Python Package Index (PyPI), and runtime dependencies of any kind.
- Using or testing the tokens in `.env`; the file is for personal use only and is never imported by the project.
## Expected Benefits
### Tangible Benefits
- A finished game (day 24) with a high score that survives between games, running with one command after the README steps.
- A test suite that runs in continuous integration without a display and without touching a real high score file.
- Generated source documentation.
- A repository page with description, topics, README and a three-language wiki.
### Intangible Benefits
- Practice with file handling, the `with` statement and the string-to-integer conversion, which is the aim of the lectures.
- A pattern for the following days of the course.
- Confidence from a step-by-step, reviewed delivery.
## Strategic Alignment
The project supports the participant's goal of finishing the bootcamp with repositories that other people can read, run and learn from, and it exercises the framework's rule that planning, review and code stay in step.
## Success Criteria
| # | Criterion | Target | Measure |
| --- | --- | --- | --- |
| 1 | The day-21 behaviour is kept | Window, snake, steering, food, eating and score behave as in [021-snake-game] | Manual run by S01 against the Go/No-Go list of [MIL-002], plus the matching tests |
| 2 | The scoreboard shows both scores | The text reads `Score: 0 High Score: 0` at the start and updates when the score or the high score changes | Manual run by S01 against the Go/No-Go list of [MIL-003], plus the matching tests |
| 3 | A collision resets and play continues | At the wall or the tail the score becomes 0, the snake is back at the three starting positions, the old segments are off the screen, and the game goes on; the high score is the largest score reached | Manual run by S01 against the Go/No-Go list of [MIL-003], plus the matching tests |
| 4 | The high score persists | After a new high score the file `data.txt` holds it as text; after closing and starting the game it is shown again | Manual run by S01 against the Go/No-Go list of [MIL-004], plus the matching tests |
| 5 | The file handling is robust | A missing file is created holding 0; an empty or non-numeric file reads as 0; the file is always closed (`with`) | Matching tests, review of `src/` |
| 6 | Tests are green and need no display | 100% of tests pass; 0 tests open a window; 0 tests read or write the real `data.txt` | `pytest` exit code 0 locally and in CI |
| 7 | The set-up steps work | A fresh clone reaches a green `pytest` by following the README alone, on Windows PowerShell (by S01) and on Linux (by CI) | One run per operating system, recorded in the pull request |
| 8 | Source documentation builds | `doxygen Doxyfile` ends with 0 warnings | Doxygen output |
| 9 | No runtime dependencies | 0 entries in `[project].dependencies` | `pyproject.toml` |
| 10 | Names follow the assignment | 100% of the names listed in objective 7 exist with that spelling | Review of `src/` against objective 7 |
| 11 | Steps are traceable | 5 of 5 milestones merged by pull request, each description with one `Closes #N` line per completed issue | Pull request list and issue states |
| 12 | The repository page is complete | Non-empty description, at least 5 topics, and the wiki pages `Home`, `Home.da` and `Home.ms` | Git host |
| 13 | The base is adopted without hidden change | Every difference between the adopted files and [021-snake-game] is listed in the pull request that introduces it | Pull request descriptions |
## Risks
| Risk | Impact | Mitigation |
| --- | --- | --- |
| `tkinter` is missing from the Python installation (typical on Debian) | The game cannot start | README lists `python3-tk` for Debian; the tests install a fake `turtle` module and need no `tkinter` |
| Debian 12 ships Python 3.11, below the required 3.13 | Linux set-up fails | README states Debian 13 or newer, or a separately installed Python 3.13 |
| A turtle window cannot be opened in continuous integration | The tests cannot cover the game | Only `main` opens a window; the classes are tested with fakes, as in the base |
| A test overwrites the player's real `data.txt` | The player loses a high score | The path of the file is a parameter with the constant as default; tests pass a temporary path (pytest `tmp_path`) |
| `data.txt` is resolved against the current working directory, so the game started from another folder finds another file | The high score seems to be lost | Decided in [MIL-004] and recorded in an open issue of [PP-001]; the lecture's plain file name is the default |
| The file is missing, empty or damaged | The game crashes at start | Objective 6: read as 0 and create the file; covered by tests |
| Author and reviewer are the same person (S01) | A defect can pass review unnoticed | Review against the QC checklists, record each review as an `RC-*`, and let the pull request be the second look |
| The lectures are available only as the summaries in the request | The game differs from the video | S01 compares the finished game with the video at the [MIL-003] and [MIL-004] Go/No-Go |
| The adopted files drift away from [021-snake-game] | A fix made in one repository is missing in the other | Out of scope by decision; each pull request lists the differences from the base |
| Tokens in `.env` leak into the repository | Credentials exposed | `.env` is in `.gitignore`, is never imported, and is not part of any task |
| The wiki is published with a secret of the organization that may be missing | The wiki stays empty | The pages are files in `wiki/` of the pull request; the marker `wiki/.publish` makes the instance's workflow publish them; a missing secret is reported, not worked around |
## Assumptions
- Python 3.13 or newer with `tkinter` is available on the machines that run the game.
- S01 is the only person who reviews and accepts artifacts.
- The git host is the Tirsvad Gitea instance, and its issues and milestones are used for tracking.
- The day-24 lecture summaries in the request are the specification of day 24; the video is the tie-breaker when a detail is missing.
- The finished `main` of [021-snake-game] is correct as far as its own tests and review records show, and is the base for every file that the milestones adopt; S01 pointed to it in chat on 2026-10-13.
- The look of the snake (light green body, dark green head with a mouth) of [021-snake-game] is kept.
- The wiki of the repository is enabled and has no page yet.
## Constraints
- Python 3.13 or newer, in a virtual environment (`venv`).
- pytest for tests; `constants.py` for constants; `pyproject.toml` for project configuration; a Python `.gitignore`; Doxygen comments in the source and a `Doxyfile`.
- Folder structure `src/`, `tests/`, `docs/`.
- No runtime dependencies unless needed.
- Plan window from 2026-10-14 to 2026-10-25 (proposed, see [PP-001]).
- S01 switched on autonomous mode in chat on 2026-10-13: S01's acceptance of the plan is the request to commit, push, open and merge the pull requests; the assistant's reviews are then not independent (see `AGENTS.md`, Modes).
- The plan gate holds: no file under `src/` or `tests/` before an accepted, reviewed milestone that lists the task.
## Cost–Benefit Assessment
The assessment is qualitative on purpose: this is an unpaid learning project with one participant, so money does not measure either side.
| Costs | Benefits |
| --- | --- |
| About ten days of S01's spare time, most of it review of the planning documents | A finished and shareable repository (objectives 1 to 12) |
| Two repositories that hold similar code and can drift apart | No rebuild of a game that already exists and is tested |
| Doxygen and pytest as development tools (not runtime) | Source documentation and automatic checks |
## Stakeholders
| Stakeholder ID (SA) | Interest in this project |
| --- | --- |
| S01 | Wants a correct, tested and documented solution of the assignment: objectives 1 to 12 |
| S02 | Needs readable, runnable code with the assignment's names and README instructions (objectives 2 to 4, 7, 8 and 10) |
| S03 | Needs a clear repository page and nothing to install (objectives 8, 10 and 12) |
## Recommendation
Proceed — the work is small (adopt a finished and tested base, add the high score, continuous play and the file, document and publish), the cost is about ten days of the Product Owner's spare time, and the result is a reusable, documented repository.
---
[SA-001]: ./stakeholder-analysis.md
[DICT-001]: ./dictionary.md
[PP-001]: ./project-plan.md
[MIL-002]: ./milestones/mil-002-adopt-the-game.md
[MIL-003]: ./milestones/mil-003-continuous-play-and-high-score.md
[MIL-004]: ./milestones/mil-004-high-score-file.md
[020-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/020-snake-game
[021-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/021-snake-game
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/dictionary.md
+70
View File
@@ -0,0 +1,70 @@
# Domain Dictionary: Snake Game (Day 24)
## Metadata
| Key | Value |
| --- | --- |
| ID | DICT-001 |
| CrossReference | [BC-001], [SA-001] |
| Language | en |
| Domain | it |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-003 (Go) | [e004c34] |
---
## Purpose and Scope
Maps each Product Owner (PO) term to its professional information technology (IT) term. PO language: `en` (domain `it`), from the registry's `Languages` section. The PO terms are the words of the lectures of days 20, 21 and 24 as the planning documents use them; the IT terms are the names in the code. The dictionary covers the vocabulary of the game; it exists so that the planning documents use one word for one thing and so that S02 can find the lectures' names in the code. It is adopted from the dictionary of [021-snake-game] and gains the terms high score, reset, continuous play, data file, read, write, mode and `with`, which the day-24 lectures introduce.
## Dictionary
| PO term | Language | IT term | Definition | Used as PO term in | Used as IT term in |
| --- | --- | --- | --- | --- | --- |
| window | en | Tk window | The desktop window that holds the screen and is opened when the game starts. | BC, SA, PP, MIL | PY |
| screen | en | `Screen` | The drawing area that the game sets up (size, colour, title) and on which the snake is shown. | BC, SA, PP, MIL | PY |
| snake | en | `Snake` | The creature the player steers, made of segments. | BC, SA, PP, MIL | PY |
| segment | en | `Turtle` | One square of the snake: light green in the body, dark green with a mouth in the head. | BC, SA, PP, MIL | PY |
| head | en | `head` | The first segment, which leads the snake and is turned by the arrow keys. | BC, SA, PP, MIL | PY |
| tail | en | `segments[1:]` | Every segment behind the head; the snake is reset when the head touches one of them. | BC, SA, PP, MIL | PY |
| body | en | `segments` | All segments of the snake, the head included, in order, the head first. | BC, SA, PP, MIL | PY |
| starting position | en | `STARTING_POSITIONS` | One of the three places at which a segment is drawn when the game starts and after a reset. | BC, MIL | PY |
| move | en | `move` | One pass in which each segment takes the place of the one before it and the head goes forward by the move distance. | BC, SA, PP, MIL | PY |
| direction | en | `heading` | The way the head points: up, down, left or right. | BC, SA, PP, MIL | PY |
| reversal | en | opposite heading | A turn by 180 degrees, so that the head would run into the segment behind it. | BC, SA, PP, MIL | PY |
| arrow key | en | key name `"Up"`, `"Down"`, `"Left"`, `"Right"` | One of the four keys with which the player turns the head. | BC, SA, PP, MIL | PY |
| animation loop | en | `while game_is_on` loop | The loop that refreshes the screen, waits and makes one move, again and again. | BC, PP, MIL | PY |
| food | en | `Food` | The small blue circle that the snake eats; it is shown at a random place. | BC, SA, PP, MIL | PY |
| refresh | en | `refresh` | The food moves to a new random place; it happens when the game starts and every time the food is eaten. | BC, SA, MIL | PY |
| eat | en | `FOOD_COLLISION_DISTANCE` | The head comes closer to the food than this distance, which makes the snake grow and the score rise. | BC, MIL | PY |
| grow | en | `extend` | The snake gets one more segment, at the place where its last segment is. | BC, SA, MIL | PY |
| score | en | `score` | The number of foods the snake has eaten since the last reset. | BC, SA, PP, MIL | PY |
| high score | en | `high_score` | The largest score reached in any game so far; it is kept in the data file between games. | BC, SA, PP, MIL | PY |
| scoreboard | en | `Scoreboard` | The text at the top of the screen that shows the score and the high score. | BC, SA, MIL | PY |
| wall | en | `WALL_LIMIT` | The line on every side of the playing field, 280 pixels from the centre; the head must stay inside it. | BC, SA, PP, MIL | PY |
| touch | en | `TAIL_COLLISION_DISTANCE` | The head comes closer to a segment of the tail than this distance. | BC, MIL | PY |
| reset | en | `reset` | The snake and the score go back to their start, and the high score is kept or raised; it happens when the head passes the wall or touches the tail. | BC, SA, PP, MIL | PY |
| continuous play | en | main flow without `game_over` | The game goes on after a reset and does not stop until the window is closed. | BC, SA, PP, MIL | PY |
| data file | en | `HIGH_SCORE_FILE` (`data.txt`) | The text file that holds the high score between games. | BC, SA, PP, MIL | PY |
| read | en | `open` in mode `r`, then `read` | The game gets the high score from the data file as text and converts it to a whole number. | BC, PP, MIL | PY |
| write | en | `open` in mode `w`, then `write` | The game replaces the content of the data file with the new high score as text. | BC, PP, MIL | PY |
| inheritance | en | subclass of `Turtle` | A class takes over the attributes and methods of another class; `Food` and `Scoreboard` take over those of `Turtle`. | BC, SA, MIL | PY |
## Rules
- The Business Case, Stakeholder Analysis, Project Plan and milestones use the PO term; the source code and its tests use the IT term. The other design artifacts (Domain Model, Operation Contract, Sequence Diagram, Design Class Diagram, ERD) do not exist in this project.
- One IT term per PO term and one PO term per IT term; no synonyms.
- The planning documents use British spelling (colour, centre); identifiers such as `color` follow the `turtle` module and the lectures.
- A code identifier written in backticks in a planning document is an IT term and is allowed there.
- "Game over" is a PO term of day 21 only; from day 24 the game does not end, and the planning documents use "reset" for what happens at the wall and at the tail.
- "Step" is not a PO term of the game. In the planning documents it means a step of the project (a task, a milestone), never a move of the snake.
- "Base" is not a PO term of the game. In the planning documents it means the finished `main` of [021-snake-game] that this project adopts, never a part of the game.
---
[BC-001]: ./business-case.md
[SA-001]: ./stakeholder-analysis.md
[021-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/021-snake-game
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/milestones/mil-001-project-foundation.md
+93
View File
@@ -0,0 +1,93 @@
# MIL-001: Project foundation
## Metadata
| Key | Value |
| --- | --- |
| ID | MIL-001 |
| CrossReference | [BC-001] |
| Language | en |
| Domain | it |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-004 (Go) | [e004c34] |
---
## Purpose
This gate decides whether the repository has the files that carry no game logic yet: configuration, ignore rules, constants, README, source documentation settings, the continuous integration workflow, and the repository description and topics. The work is delivered on the branch `mil-001-project-foundation` and one pull request.
## Deliverable
`pyproject.toml`, the Python `.gitignore`, the package `src/snake_game/` with `__init__.py` and `constants.py`, `tests/test_constants.py`, `README.md` following the Product Owner's template, `Doxyfile`, and `.gitea/workflows/ci.yml`. The repository description and topics on the git host are set. Each adopted file is copied from [021-snake-game] and changed only where the identity of this repository requires it; the pull request lists every difference from the base.
Proposed repository description and topics, for S01 to confirm by accepting the plan:
- Description: "Snake game in Python with turtle graphics, day 24 of Udemy's 100 Days of Code bootcamp: continuous play and a high score kept in a file between games. pytest tests, Doxygen docs, no runtime dependencies."
- Topics: `100-days-of-code`, `doxygen`, `education`, `file-handling`, `game`, `high-score`, `oop`, `pytest`, `python`, `python-bootcamp`, `snake-game`, `turtle-graphics`, `udemy`.
## Go / No-Go Criteria
| # | Criterion (objectively checkable) | Go | No-Go |
| --- | --- | --- | --- |
| 1 | In a fresh clone, `python -m venv .venv`, `python -m pip install --upgrade pip` and `python -m pip install -e ".[dev]"` succeed in Windows PowerShell | All three commands exit 0 | Any command fails |
| 2 | `pytest` runs | Exit code 0, at least one test of `constants.py`, no window opened | Failing test, or no test of `constants.py` |
| 3 | `pyproject.toml` states the Python version and the dependencies | `requires-python = ">=3.13"`, `dependencies = []`, a `dev` extra with pytest, and a repository URL that names this repository | Any of the four is missing or different |
| 4 | The `.gitignore` protects local files | `git check-ignore .venv .env __pycache__ data.txt` lists all four | One of them is not ignored |
| 5 | `constants.py` holds the values of the base, with Doxygen comments | Every value of the `constants.py` of [021-snake-game] is a constant with a Doxygen comment | A value is missing or has no Doxygen comment |
| 6 | `doxygen Doxyfile` builds the source documentation | Ends with 0 warnings and writes HTML for `src/` | Any warning, or no output |
| 7 | The README follows the Product Owner's template | Every section title of the template in the given order (Requirements, Set up with Windows powershell, Linux debian and MacOS, Run, Run the tests, Continuous integration, Build the source documentation, Project layout, License), with commands for the three systems | A heading is missing or out of order, or a section has no commands |
| 8 | The CI workflow exists | `.gitea/workflows/ci.yml` installs `.[dev]` and runs `pytest`, `ruff` and `mypy` on Python 3.13, and nothing under `.github/workflows` exists | No workflow, or it does not run the tests, or a file exists under `.github/workflows` |
| 9 | The repository page is complete | Description is non-empty and there are at least 5 topics on the git host | Description empty or fewer than 5 topics |
| 10 | The adopted files are traceable to the base | The pull request lists every difference between each adopted file and the base, or says that there is none | A difference that the list does not name |
| 11 | The code is reviewed | `RC-*` against `QC-PY-001` has the verdict `Go` | Verdict `No-Go` or `Go-with-conditions` |
| 12 | No secret is in the change | `.env` is not tracked and no token appears in any changed file | A token is found in the diff |
## Dependencies
| Depends on | Reason |
| --- | --- |
| [PP-001] accepted | The plan schedules this gateway; the plan-first gate needs it before any code |
| This milestone accepted with a `Go` review | The plan-first gate allows no file under `src/` or `tests/` before that |
## Traceability
| Business Case objective / KPI / user story | Reference |
| --- | --- |
| Objective 8: reproducible environment, no runtime dependencies | [BC-001], criteria 7 and 9 in Success Criteria |
| Objective 9: tests without a display | [BC-001], criterion 6 in Success Criteria |
| Objective 10: Doxygen and README | [BC-001], criteria 7 and 8 in Success Criteria |
| Objective 12: repository page | [BC-001], criterion 12 in Success Criteria |
| Objective 11: traceable steps; the base is adopted without hidden change | [BC-001], criteria 11 and 13 in Success Criteria |
## Ownership
| Role | Stakeholder ID (SA) |
| --- | --- |
| Owner | S01 |
| Approving reviewer | S01 |
## Target Date
2026-10-15 — first of five gateways, inside the plan of [PP-001] that ends 2026-10-25.
## Tasks
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
| --- | --- | --- | --- | --- |
| 1 | Add pyproject.toml for the Day 24 repository | Adopt `pyproject.toml` from the base for the `snake-game` project: `requires-python = ">=3.13"`, an empty `dependencies` list, a `dev` extra with pytest, ruff and mypy, the `src` layout for the package `snake_game`, the pytest settings, and a description and repository URL that name this repository and day 24. Serves objective 8: a reproducible environment without runtime dependencies. | No | |
| 2 | Add the Python .gitignore for the Day 24 repository | Adopt the Python `.gitignore` from the base: bytecode, `.venv/`, build and packaging output, pytest, ruff, mypy and Doxygen caches. It also ignores `.env`, so the personal tokens can never be committed, and `data.txt`, the player's own high score file. | No | |
| 3 | Adopt constants.py and its test | Copy `src/snake_game/__init__.py`, `src/snake_game/constants.py` and `tests/test_constants.py` from the base. Every value is an `UPPER_SNAKE` constant with a Doxygen comment. The day-24 constants are added in MIL-003 and MIL-004. | No | |
| 4 | Add the README for the Day 24 repository | Adopt `README.md` from the base and rewrite its identity for this repository (name, day 24, clone address). Keep the Product Owner's template. Document creating a local `.venv`, `python -m pip install --upgrade pip` and `python -m pip install -e ".[dev]"`; name `python3-tk` and Debian 13 for Linux. The Run section is finished in MIL-005. Serves S02 and S03. | No | |
| 5 | Add the Doxyfile for the Day 24 repository | Adopt the `Doxyfile` from the base: it reads `src/`, writes to `build/doxygen`, extracts documentation for Python and treats warnings as failures; the project brief names day 24. | No | |
| 6 | Add the continuous integration workflow | Adopt `.gitea/workflows/ci.yml` from the base: check out, set up Python 3.13, upgrade `pip`, install `.[dev]`, run `pytest`, `ruff` and `mypy`. The file stays in `.gitea/workflows`, not `.github/workflows`, so the push mirror to GitHub is not blocked. | No | |
| 7 | Set the repository description and topics | Set the description and at least 5 topics of this repository on the git host with the Gitea application programming interface (API), using `GITEA_TOKEN` from the personal `.env` file; the file is only read by the command, never imported, tested or tracked. Use the proposed text of the Deliverable section. Serves S03 and objective 12. | No | |
---
[BC-001]: ../business-case.md
[PP-001]: ../project-plan.md
[021-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/021-snake-game
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/milestones/mil-002-adopt-the-game.md
+87
View File
@@ -0,0 +1,87 @@
# MIL-002: Adopt the game
## Metadata
| Key | Value |
| --- | --- |
| ID | MIL-002 |
| CrossReference | [BC-001] |
| Language | en |
| Domain | it |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-005 (Go) | [e004c34] |
---
## Purpose
This gate decides whether the finished game of the base ([021-snake-game], `main`) runs in this repository: the snake, the food, the scoreboard, the main flow and all their tests are here, they pass, and the game can be played. It changes no behaviour; the day-24 changes start in [MIL-003]. The work is delivered on the branch `mil-002-adopt-the-game` and one pull request.
## Deliverable
`src/snake_game/snake.py`, `food.py`, `scoreboard.py`, `main.py` and `__main__.py`, and the tests `tests/fakes.py`, `test_snake.py`, `test_food.py`, `test_scoreboard.py` and `test_main.py`. Running `python -m snake_game` plays the game of day 21. The files are copied from the base and changed only where the identity of this repository requires it; the pull request lists every difference from the base.
## Go / No-Go Criteria
| # | Criterion (objectively checkable) | Go | No-Go |
| --- | --- | --- | --- |
| 1 | The adopted files match the base | The pull request lists every difference between each adopted file and the base, or says that there is none | A difference that the list does not name |
| 2 | All tests pass without a display | `pytest` exits 0; no test opens a window; every test of the base is present | A failing test, or a test of the base is missing |
| 3 | Tests, lint, format and types are clean | `pytest`, `python -m ruff check src tests`, `python -m ruff format --check src tests` and `python -m mypy` exit 0, as in continuous integration (CI); no test opens a window | Any of them fails |
| 4 | `doxygen Doxyfile` builds | 0 warnings | Any warning |
| 5 | The game can be played | S01 runs `python -m snake_game` in Windows PowerShell: the window opens, the snake moves and turns, food is shown, the snake eats and grows, the score rises, and the game ends at the wall and at the tail | The game does not start, or one of those things does not happen |
| 6 | Closing the window ends quietly | Closing the window during play, and after game over, ends the program with exit code 0 and no traceback | A traceback |
| 7 | Importing the main flow needs no display | Importing `snake_game.main` loads neither `turtle` nor `tkinter` | Either module is loaded by the import |
| 8 | Constants are in one place | No module other than `constants.py` defines a value of the lectures | A value is a literal in another module |
| 9 | The README matches the adopted game | The Run section and the Project layout of `README.md` describe the files and the command of this milestone | A sentence that is out of date, or a file or command that the README does not name |
| 10 | The code is reviewed | `RC-*` against `QC-PY-001` has the verdict `Go` | Verdict `No-Go` or `Go-with-conditions` |
| 11 | No secret is in the change | `.env` is not tracked and no token appears in any changed file | A token is found in the diff |
## Dependencies
| Depends on | Reason |
| --- | --- |
| [MIL-001] accepted and merged | The package, `constants.py`, the test set-up, the Doxyfile and the CI workflow exist there |
## Traceability
| Business Case objective / KPI / user story | Reference |
| --- | --- |
| Objective 1: the day-21 behaviour is kept | [BC-001], criterion 1 in Success Criteria |
| Objective 7: the assignment's names | [BC-001], criterion 10 in Success Criteria |
| Objective 9: tests without a display | [BC-001], criterion 6 in Success Criteria |
| Objective 11: the base is adopted without hidden change | [BC-001], criteria 11 and 13 in Success Criteria |
## Ownership
| Role | Stakeholder ID (SA) |
| --- | --- |
| Owner | S01 |
| Approving reviewer | S01 |
## Target Date
2026-10-17 — second of five gateways.
## Tasks
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
| --- | --- | --- | --- | --- |
| 1 | Adopt the test fakes | Copy `tests/fakes.py` from the base: the fake segment, the fake screen and the fake `Turtle` base class that record their calls, so that every test runs without a display. The fake `turtle` module is installed before `food` and `scoreboard` are imported. | No | |
| 2 | Adopt the Snake class and its tests | Copy `src/snake_game/snake.py` and `tests/test_snake.py` from the base: `create_snake`, `add_segment`, `extend`, `move`, `hits_wall`, `hits_tail`, `up`, `down`, `left`, `right`, the `segments` list and the `head`. | No | |
| 3 | Adopt the Food class and its tests | Copy `src/snake_game/food.py` and `tests/test_food.py` from the base: `class Food(Turtle)` with `refresh`, whose random place comes from one function that the tests replace. | No | |
| 4 | Adopt the Scoreboard class and its tests | Copy `src/snake_game/scoreboard.py` and `tests/test_scoreboard.py` from the base: `class Scoreboard(Turtle)` with `update_scoreboard`, `increase_score` and `game_over`. `game_over` is replaced in MIL-003. | No | |
| 5 | Adopt the main flow and the entry point | Copy `src/snake_game/main.py`, `src/snake_game/__main__.py` and `tests/test_main.py` from the base: the screen set-up, the key bindings, the animation loop with `game_is_on`, the eating check, the game-over check, the wait for a click and the quiet exit when the window is closed. | No | |
| 6 | Describe the adopted game in the README | Update the Run section and the Project layout of `README.md` so that they match the files and the command of this milestone (`python -m snake_game`, the modules of `src/snake_game/`, the tests). Serves S02 and S03. | No | |
| 7 | Verify the adopted game end to end | Run `pytest`, `ruff check`, `ruff format --check`, `mypy` and `doxygen Doxyfile` in a fresh `.venv`, run `python -m snake_game` until the game is over, close the window during play, and record the results and the list of differences from the base in the pull request. | No | |
---
[BC-001]: ../business-case.md
[PP-001]: ../project-plan.md
[MIL-001]: ./mil-001-project-foundation.md
[MIL-003]: ./mil-003-continuous-play-and-high-score.md
[021-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/021-snake-game
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/milestones/mil-003-continuous-play-and-high-score.md
+88
View File
@@ -0,0 +1,88 @@
# MIL-003: Continuous play and high score
## Metadata
| Key | Value |
| --- | --- |
| ID | MIL-003 |
| CrossReference | [BC-001] |
| Language | en |
| Domain | it |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-006 (Go) | [e004c34] |
---
## Purpose
This gate decides whether the game follows the day-24 lectures on the high score and on continuous play: the scoreboard has a `high_score`, `reset` replaces `game_over`, a collision resets the snake and the score and the game goes on, and the old snake leaves the screen. The high score lives in memory only; the lecture itself shows that it is lost when the game is started again, and [MIL-004] stores it. The work is delivered on the branch `mil-003-continuous-play-and-high-score` and one pull request.
## Deliverable
Changed `src/snake_game/scoreboard.py`, `snake.py`, `main.py` and `constants.py`, with changed and added tests. `Scoreboard.game_over` and its test are removed; `Scoreboard.reset` and `Snake.reset` are added.
## Go / No-Go Criteria
| # | Criterion (objectively checkable) | Go | No-Go |
| --- | --- | --- | --- |
| 1 | The scoreboard shows both scores | The text is `Score: <score> High Score: <high_score>` and starts as `Score: 0 High Score: 0`; the label texts are constants; the old text is cleared before every write | A different text, a literal label outside `constants.py`, or text that is written over the old one |
| 2 | `Scoreboard.reset` follows the lecture | When `score > high_score`, `high_score` becomes the score; then the score is 0 and the scoreboard is written again; a lower or equal score leaves `high_score` unchanged | Any of the three cases behaves differently |
| 3 | `Snake.reset` clears the old snake | Every old segment is sent to a place off the screen (a constant), `segments` is emptied, the snake is created again at the three starting positions and `head` is the first new segment | An old segment stays on the screen, or `head` still refers to an old segment |
| 4 | A collision no longer ends the game | At the wall and at the tail, `scoreboard.reset()` and `snake.reset()` are called and the loop goes on; `game_over`, `GAME_OVER_TEXT` and the wait for a click are gone | The game stops, or a name of the removed game over remains |
| 5 | The snake is playable after a reset | After a reset the snake moves right from the starting positions, a reversal is still ignored, and the food keeps its place | The snake does not move, or turns back onto itself |
| 6 | The day-24 values are constants | The off-screen place and the label texts used by `reset` and the scoreboard are constants with Doxygen comments | A literal in another module |
| 7 | The day-21 tests still hold | Every test of [MIL-002] passes, or is changed on purpose and the change is named in the pull request | A test is deleted without being named |
| 8 | Tests, lint, format and types are clean | `pytest`, `python -m ruff check src tests`, `python -m ruff format --check src tests` and `python -m mypy` exit 0, as in continuous integration (CI); no test opens a window | Any of them fails |
| 9 | `doxygen Doxyfile` builds | 0 warnings | Any warning |
| 10 | The game can be played | S01 plays in Windows PowerShell: hits the wall and the tail twice, sees the score go back to 0, the high score keep the best, and the old snake disappear | Any of those does not happen |
| 11 | The code is reviewed | `RC-*` against `QC-PY-001` has the verdict `Go` | Verdict `No-Go` or `Go-with-conditions` |
| 12 | No secret is in the change | `.env` is not tracked and no token appears in any changed file | A token is found in the diff |
## Dependencies
| Depends on | Reason |
| --- | --- |
| [MIL-002] accepted and merged | The classes and the main flow that this milestone changes exist there |
## Traceability
| Business Case objective / KPI / user story | Reference |
| --- | --- |
| Objective 2: the high score and the scoreboard text | [BC-001], criterion 2 in Success Criteria |
| Objective 3: continuous play and `reset` | [BC-001], criterion 3 in Success Criteria |
| Objective 4: `Snake.reset` | [BC-001], criterion 3 in Success Criteria |
| Objective 7: the assignment's names | [BC-001], criterion 10 in Success Criteria |
## Ownership
| Role | Stakeholder ID (SA) |
| --- | --- |
| Owner | S01 |
| Approving reviewer | S01 |
## Target Date
2026-10-19 — third of five gateways.
## Tasks
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
| --- | --- | --- | --- | --- |
| 1 | Add the high score constants | Add to `constants.py`, with Doxygen comments: the label of the high score text, the place off the screen where an old segment is sent, and any other value the next tasks need. Add the matching test of `test_constants.py`. | No | |
| 2 | Add the high_score attribute and the scoreboard text | `Scoreboard.__init__` sets `self.high_score` to 0 next to `self.score`; `update_scoreboard` clears the old text and writes `Score: <score> High Score: <high_score>`; tests with the fake turtle check the text and the clearing. | No | |
| 3 | Replace game_over with reset in the Scoreboard | Remove `Scoreboard.game_over` and its test. Add `Scoreboard.reset`: when the score is higher than `high_score`, the high score becomes the score; the score becomes 0; `update_scoreboard` is called. Tests: higher, equal and lower score. | No | |
| 4 | Add Snake.reset | Add `Snake.reset`: send every segment of `segments` to the off-screen place, empty the list, call `create_snake` again and set `head` to `segments[0]`. Tests with fake segments check that no old segment remains and that the starting positions are used. | No | |
| 5 | Play on after a collision in the main flow | In `main.py`, a hit of the wall or of the tail calls `scoreboard.reset()` and `snake.reset()` and the loop goes on; the end-of-game check, the game-over text and `exitonclick` are removed; closing the window still ends quietly. Update `tests/test_main.py`. | No | |
| 6 | Update the README for continuous play | Describe in the Run section the two scores on the scoreboard and what a collision does now, and remove the sentences about game over. Serves S02 and S03. | No | |
| 7 | Verify continuous play end to end | Run `pytest`, `ruff check`, `ruff format --check`, `mypy` and `doxygen Doxyfile` in a fresh `.venv`, play with several collisions and close the window, and record the results and the changed tests in the pull request. | No | |
---
[BC-001]: ../business-case.md
[PP-001]: ../project-plan.md
[MIL-002]: ./mil-002-adopt-the-game.md
[MIL-004]: ./mil-004-high-score-file.md
[021-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/021-snake-game
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/milestones/mil-004-high-score-file.md
+86
View File
@@ -0,0 +1,86 @@
# MIL-004: High score file
## Metadata
| Key | Value |
| --- | --- |
| ID | MIL-004 |
| CrossReference | [BC-001] |
| Language | en |
| Domain | it |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-007 (Go) | [e004c34] |
---
## Purpose
This gate decides whether the high score survives between games: it is read from `data.txt` with `with open(...)` when the scoreboard is made, converted from text to an integer, and written back to the file when a new high score is reached. It also decides the behaviour where the lecture is silent: a missing, empty or damaged file. The work is delivered on the branch `mil-004-high-score-file` and one pull request.
## Deliverable
Changed `src/snake_game/scoreboard.py` and `constants.py`, functions that read and write the high score, and tests that use a temporary file. The game, started again after a new high score, shows that high score.
## Go / No-Go Criteria
| # | Criterion (objectively checkable) | Go | No-Go |
| --- | --- | --- | --- |
| 1 | The high score is read at the start | `Scoreboard()` reads the file named by the constant `HIGH_SCORE_FILE` (`data.txt`) with a `with` statement, converts the text with `int` and shows the value as `High Score` | The value is not read, the file is opened without `with`, or the text is not converted |
| 2 | A new high score is written | When `reset` finds a score above the high score, the file holds the new value as text; a lower or equal score does not write the file | The file is not written, is written for a lower score, or holds something other than the number |
| 3 | A missing file is created | Starting without `data.txt` shows `High Score: 0` and leaves a `data.txt` that holds `0` | A traceback, or no file |
| 4 | A damaged file reads as 0 | An empty file, a file with text that is not a whole number and a negative number all give a high score of 0 without a traceback | A traceback, or a negative high score |
| 5 | The path is a parameter | The file name is a constant used as the default of a parameter, and every test passes a temporary path | A test uses the real `data.txt` |
| 6 | The high score survives a restart | S01 reaches a new high score, closes the window, starts `python -m snake_game` again and sees the same high score | The value is lost |
| 7 | `data.txt` is not tracked | `git check-ignore data.txt` lists it and no `data.txt` is in the change | The file is tracked |
| 8 | Tests, lint, format and types are clean | `pytest`, `python -m ruff check src tests`, `python -m ruff format --check src tests` and `python -m mypy` exit 0, as in continuous integration (CI); no test opens a window | Any of them fails |
| 9 | `doxygen Doxyfile` builds | 0 warnings | Any warning |
| 10 | The code is reviewed | `RC-*` against `QC-PY-001` has the verdict `Go` | Verdict `No-Go` or `Go-with-conditions` |
| 11 | No secret is in the change | `.env` is not tracked and no token appears in any changed file | A token is found in the diff |
## Dependencies
| Depends on | Reason |
| --- | --- |
| [MIL-003] accepted and merged | `Scoreboard.reset` and the two scores exist there |
## Traceability
| Business Case objective / KPI / user story | Reference |
| --- | --- |
| Objective 5: the file read and written with `with` | [BC-001], criterion 4 in Success Criteria |
| Objective 6: a missing or damaged file | [BC-001], criterion 5 in Success Criteria |
| Objective 9: tests never touch the real file | [BC-001], criterion 6 in Success Criteria |
## Ownership
| Role | Stakeholder ID (SA) |
| --- | --- |
| Owner | S01 |
| Approving reviewer | S01 |
## Target Date
2026-10-21 — fourth of five gateways.
## Tasks
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
| --- | --- | --- | --- | --- |
| 1 | Add the high score file constant | Add `HIGH_SCORE_FILE: Final[str] = "data.txt"` to `constants.py` with a Doxygen comment, and a test of it. | No | |
| 2 | Read the high score from the file | Add a function that opens the file with `with open(path) as data`, reads it, converts the text with `int` and returns it; `Scoreboard.__init__` takes the path as a parameter with the constant as default and sets `high_score` from it. Tests with a temporary file. | No | |
| 3 | Write the high score to the file | In `Scoreboard.reset`, when a new high score is reached, open the file with `with open(path, mode="w") as data` and write the number as text. Tests check the file content after a higher, equal and lower score. | No | |
| 4 | Handle a missing or damaged file | A missing file is created holding `0`; an empty file, text that is not a whole number or a negative number read as 0 (objective 6 of the Business Case). Tests for each case. | No | |
| 5 | Keep the tests away from the real data.txt | Every test that makes a `Scoreboard` passes a pytest `tmp_path` file; a guard in `tests/conftest.py` fails a test that would open the default path. | No | |
| 6 | Document the high score file in the README | Describe in the Run section where `data.txt` is, that it is created at the first start, how to reset the high score (delete the file) and that it is not tracked by git. Serves S02. | No | |
| 7 | Verify the high score file end to end | Run `pytest`, `ruff check`, `ruff format --check`, `mypy` and `doxygen Doxyfile` in a fresh `.venv`, reach a high score, restart the game, delete and damage `data.txt` and start again, and record the results in the pull request. | No | |
---
[BC-001]: ../business-case.md
[PP-001]: ../project-plan.md
[MIL-003]: ./mil-003-continuous-play-and-high-score.md
[MIL-005]: ./mil-005-wiki-and-finish.md
[021-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/021-snake-game
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/milestones/mil-005-wiki-and-finish.md
+80
View File
@@ -0,0 +1,80 @@
# MIL-005: Wiki and finish
## Metadata
| Key | Value |
| --- | --- |
| ID | MIL-005 |
| CrossReference | [BC-001] |
| Language | en |
| Domain | it |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-008 (Go) | [e004c34] |
---
## Purpose
This gate decides whether the repository is finished: the wiki exists in English, Danish and Bahasa Melayu, the README matches the finished game, the repository page is complete, and the whole game has been checked end to end. The work is delivered on the branch `mil-005-wiki-and-finish` and one pull request.
## Deliverable
The folder `wiki/` with `Home.md`, `Home.da.md`, `Home.ms.md`, `_Sidebar.md` and the marker `.publish`, in the form of the wiki of `TirSystem/github-action` and of [021-snake-game]; the finished `README.md`; a checked description and topics.
## Go / No-Go Criteria
| # | Criterion (objectively checkable) | Go | No-Go |
| --- | --- | --- | --- |
| 1 | The wiki is in three languages | The wiki has the pages `Home` (English), `Home.da` (Danish, Dansk) and `Home.ms` (Bahasa Melayu), each with a short description of the game, its controls, the high score file and how to run it, a language switch at the top, and a `_Sidebar` that lists the three languages | A language is missing, or a page does not link to the other two |
| 2 | The wiki is published | `wiki/.publish` exists and, after the merge, the three pages are on the wiki of the repository | The pages are not on the wiki; a missing secret is reported to S01 |
| 3 | The README is finished | Every section of the template is filled, the commands match the game, and no sentence is out of date | A heading is missing or a sentence is out of date |
| 4 | The repository page is complete | Description non-empty and at least 5 topics on the git host | Description empty or fewer than 5 topics |
| 5 | The whole game works | `pytest`, `ruff`, `mypy` and `doxygen Doxyfile` are clean in a fresh clone, and S01 plays: collision, reset, high score kept after a restart | Any check fails |
| 6 | No runtime dependencies | `[project].dependencies` is empty | An entry is present |
| 7 | The code is reviewed | `RC-*` against `QC-PY-001` has the verdict `Go` | Verdict `No-Go` or `Go-with-conditions` |
| 8 | No secret is in the change | `.env` is not tracked and no token appears in any changed file | A token is found in the diff |
## Dependencies
| Depends on | Reason |
| --- | --- |
| [MIL-004] accepted and merged | The high score file exists there, and the wiki describes it |
## Traceability
| Business Case objective / KPI / user story | Reference |
| --- | --- |
| Objective 10: README | [BC-001], criteria 7 and 8 in Success Criteria |
| Objective 12: repository page and wiki | [BC-001], criterion 12 in Success Criteria |
| Objective 11: traceable steps | [BC-001], criterion 11 in Success Criteria |
## Ownership
| Role | Stakeholder ID (SA) |
| --- | --- |
| Owner | S01 |
| Approving reviewer | S01 |
## Target Date
2026-10-23 — last of five gateways; two buffer days follow.
## Tasks
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
| --- | --- | --- | --- | --- |
| 1 | Write the wiki pages in three languages | In the folder `wiki/`, as the wiki of `TirSystem/github-action` does, write `Home.md` (English), `Home.da.md` (Danish) and `Home.ms.md` (Bahasa Melayu), each with a short description of the game, its controls, the high score file and how to run it, and a language switch (English, Dansk, Bahasa Melayu) at the top; add `_Sidebar.md` that lists the three languages. Serves S03. | No | |
| 2 | Add the wiki publish marker | Add the empty marker `wiki/.publish`, which makes the instance's workflow copy the pages to the wiki of the repository when a pull request is merged to `main`. It needs the secret `TOKEN_FOR_GITEA_WIKI` of the organization; a token is never printed or typed, and a missing secret is reported to S01. | No | |
| 3 | Finish the README | Check every section of `README.md` against the finished game: set-up on the three systems, run, the controls, the two scores, `data.txt`, the tests, CI, Doxygen, layout and license; correct what is out of date. Serves S02 and S03. | No | |
| 4 | Check the repository description and topics again | Read the description and topics from the git host and compare them with the finished game; correct them with the Gitea API when they differ. | No | |
| 5 | Verify the finished game end to end | In a fresh clone follow the README alone: create the `.venv`, upgrade `pip`, install, run `pytest`, `ruff`, `mypy` and `doxygen Doxyfile`, play, restart, and record the results in the pull request. | No | |
---
[BC-001]: ../business-case.md
[PP-001]: ../project-plan.md
[MIL-004]: ./mil-004-high-score-file.md
[021-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/021-snake-game
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/project-plan.md
+126
View File
@@ -0,0 +1,126 @@
# Project Plan: Snake Game (Day 24)
## Metadata
| Key | Value |
| --- | --- |
| ID | PP-001 |
| CrossReference | [BC-001], [SA-001], [DICT-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005] |
| Language | en |
| Domain | it |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version; accepted by S01 (Product Owner) in chat on 2026-10-13 | [e004c34] |
---
## Purpose
This plan schedules the five milestones that deliver the Snake Game (Day 24) repository of [BC-001]. The repository starts from the finished `main` of [021-snake-game], which holds the snake game of days 20 and 21 with tests and documentation. The milestones therefore set up the repository, adopt that base, add continuous play and the high score of the day-24 lectures, store the high score in `data.txt`, and finish the repository with the README check and a wiki in three languages. Each milestone is one gateway document, one branch and one pull request, so that every step is kept track of and reviewed before the next one starts.
## Planning Assumptions
- The phase starts 2026-10-14 and ends by 2026-10-25, which leaves two days of buffer after [MIL-005]. All dates are proposed and need the Product Owner's confirmation (see Open Issues).
- Phase length: two days per milestone, sized for the spare time of S01, who owns every phase ([SA-001]).
- The starting point is the finished `main` of [021-snake-game], which S01 pointed to in chat on 2026-10-13. The base is copied file by file, so each adopted file is a task, and every difference from the base is listed in the pull request.
- One branch per milestone, named after it (`mil-001-project-foundation` and so on), and one pull request that closes the issues of that milestone with one `Closes #N` line each. The planning documents themselves are delivered on the branch `plan-baseline`.
- S01 switched on autonomous mode in chat on 2026-10-13 (see `AGENTS.md`, Modes): S01's acceptance of this plan is the request, and the commit, the push, the pull request and its merge follow without further asking. The reviews are done by the assistant as stand-in for S01 and are not independent; each record says `Mode: autonomous, not independent`.
- The plan gate is enabled for commits in this clone: a commit that changes `src/` or `tests/` needs a `Task: MIL-NNN#N` trailer for an accepted, reviewed milestone.
- The tokens in `.env` are used only by commands that the assistant runs (repository description and topics, sync of issues); the project never imports, tests or tracks the file.
## Gateway Schedule
| Gateway | Document | Window | Decision date | Owner | Stories | Main deliverable | Milestone |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Project foundation | [MIL-001] | 2026-10-14 to 2026-10-15 | 2026-10-15 | S01 | None (see Open Issues) | `pyproject.toml`, `.gitignore`, `constants.py`, README, `Doxyfile`, CI workflow, repository description and topics | |
| Adopt the game | [MIL-002] | 2026-10-16 to 2026-10-17 | 2026-10-17 | S01 | None (see Open Issues) | `Snake`, `Food`, `Scoreboard`, the main flow and `python -m snake_game`, with their tests | |
| Continuous play and high score | [MIL-003] | 2026-10-18 to 2026-10-19 | 2026-10-19 | S01 | None (see Open Issues) | `Scoreboard.high_score` and `reset`, `Snake.reset`, play without game over, with tests | |
| High score file | [MIL-004] | 2026-10-20 to 2026-10-21 | 2026-10-21 | S01 | None (see Open Issues) | High score read from and written to `data.txt` with `with`, robust against a missing or damaged file, with tests | |
| Wiki and finish | [MIL-005] | 2026-10-22 to 2026-10-23 | 2026-10-23 | S01 | None (see Open Issues) | Wiki in English, Danish and Bahasa Melayu; README checked against the finished game; end-to-end verification | |
```plantuml
@startgantt
Project starts 2026-10-14
[MIL-001 Project foundation] starts 2026-10-14 and ends 2026-10-15
[MIL-002 Adopt the game] starts 2026-10-16 and ends 2026-10-17
[MIL-003 Continuous play and high score] starts 2026-10-18 and ends 2026-10-19
[MIL-004 High score file] starts 2026-10-20 and ends 2026-10-21
[MIL-005 Wiki and finish] starts 2026-10-22 and ends 2026-10-23
[MIL-001 Go/No-Go] happens 2026-10-15
[MIL-002 Go/No-Go] happens 2026-10-17
[MIL-003 Go/No-Go] happens 2026-10-19
[MIL-004 Go/No-Go] happens 2026-10-21
[MIL-005 Go/No-Go] happens 2026-10-23
[Buffer] starts 2026-10-24 and ends 2026-10-25
@endgantt
```
## Scope Coverage
| Business Case scope item | Gateway |
| --- | --- |
| Adopting the finished game of the base: configuration, constants, workflow | [MIL-001] |
| Adopting the finished game of the base: `Snake`, `Food`, `Scoreboard`, the main flow and the tests | [MIL-002] |
| Day-24 lecture "High score": `high_score` attribute, `reset` instead of `game_over`, scoreboard text | [MIL-003] |
| Day-24 lecture "Continuous play": no stop on collision; `Snake.reset` moves the old segments off the screen | [MIL-003] |
| Day-24 lectures "Open, read and write files" and "Persist the high score": `data.txt`, `with`, conversion to `int`, write on new high score | [MIL-004] |
| Robust file handling (missing, empty or damaged file) | [MIL-004] |
| Constants in `constants.py`; `src/`, `tests/`, `docs/` layout | [MIL-001], extended in [MIL-003] and [MIL-004] |
| `pyproject.toml`, Python `.gitignore`, `Doxyfile`, README, continuous integration workflow | [MIL-001], README updated in [MIL-002] to [MIL-004] and finished in [MIL-005] |
| Repository description and topics | [MIL-001] (task 7), checked again in [MIL-005] |
| Wiki in English, Danish and Bahasa Melayu | [MIL-005] |
## Dependencies
```
MIL-001 → MIL-002 → MIL-003 → MIL-004 → MIL-005
```
A No-Go on a gateway returns it to S01 for rework and moves every later date by the same number of days; the two buffer days after [MIL-005] absorb a slip before the end date moves.
## Plan Risks
| Risk | Impact | Mitigation |
| --- | --- | --- |
| The planning documents take longer to review than the work left on the game | The first gateway slips | Review [BC-001], [SA-001] and this plan together in one sitting; keep the milestones small |
| Author and reviewer are the same person (S01) | A review can miss a defect | Use the QC checklists and the pull request as the second look; recorded in [BC-001] |
| The git host has no Actions runner | The CI workflow is never executed | Run the same commands locally before each pull request |
| Lecture details are only available as the summaries in the request | The game differs from the video | S01 compares the finished game with the video at the [MIL-003] and [MIL-004] Go/No-Go |
| The sync matches issues by title, so a title used twice overwrites an issue | A task disappears from the board | Every task title is unique across all milestones; check before each `--apply` |
| The base is a copy of another repository | A later fix reaches only one of them | Out of scope by decision (see [BC-001]); each pull request lists the differences from the base |
| The wiki publish workflow needs a secret of the organization | The wiki stays empty | Reported to S01, never worked around; the pages are files in `wiki/` and are not lost |
## Open Issues
- **Dates:** the start date, milestone lengths and the end date 2026-10-25 are proposed and not given by the Product Owner; confirm or replace them.
- **Product Owner (PO) language:** S01 chose English on 2026-10-13; `en` is recorded in `docs/artifact-registry.md`.
- **Stakeholder levels:** the Power and Interest levels of S02 and S03 in [SA-001] are proposals, taken over from [021-snake-game].
- **Starting point:** the finished `main` of [021-snake-game] is the base, as S01 pointed to it in chat on 2026-10-13. Confirm that it is the intended base and not a rebuild from [020-snake-game].
- **Repository address:** the request names `https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code` (underscores), which is not the repository of `origin` (`Tirsvad-Udemy-100-days-of-code/024-snake`). S01 chose `origin` in chat on 2026-10-13; description and topics are set there.
- **Repository description and topics:** the proposed text is in [MIL-001]; S01 confirms it by accepting this plan.
- **"Python greater than 3.13":** read as Python 3.13 or newer (`requires-python = ">=3.13"`), as in [021-snake-game]. Confirm.
- **README template:** the Product Owner's README template is used. It differs from `framework/templates/README-template.md`, so `framework/scripts/check-readme.sh` stays off.
- **Place of `data.txt`:** the lecture opens the plain name `data.txt`, which is resolved against the current working directory, so the game started from another folder uses another file. [MIL-004] keeps the lecture's name as the default and makes the path a parameter; the alternative is a fixed place per user. Confirm. `data.txt` is listed in `.gitignore`, because it is the player's own state.
- **Robust file handling:** the lecture assumes `data.txt` exists and holds a number. The plan adds a fallback to 0 (objective 6 of [BC-001]) and creates a missing file. Confirm, or ask for the lecture's version without it.
- **Mail merge project:** the request lists the personalised-letters project of day 24. It is a separate program and out of scope here (see [BC-001]); it can get its own repository.
- **Display-free tests:** `Scoreboard` inherits from `Turtle`, so its tests install a fake `turtle` module, as in [021-snake-game].
- **No user story or use case:** the tasks are written as build and check steps, so they are plain technical tasks. If the player's goal should be modelled, add a Use Case Diagram, a user story and a use case and reference them from the task rows.
- **Governance and traceability matrix:** `GOV` and `TM` do not exist yet in this project. Decide whether to create them; the plan proceeds without them and records each review as an `RC-*`. The Domain Dictionary [DICT-001] was added on 2026-10-13 so that criterion 5 of `QC-LANG-001` can be checked.
- **Screenshot:** not part of this plan; a screenshot needs S01's display. It can be added to the README and the wiki later.
- **Diagram check:** the Gantt chart above was not rendered because no PlantUML server is configured (`PLANTUML_URL`); render it before the review.
- **Sync:** `sync-project.sh --apply` is run with `GITEA_TOKEN` from the personal `.env` after the plan is accepted, as in [021-snake-game]; the sync matches issues by title.
---
[BC-001]: ./business-case.md
[SA-001]: ./stakeholder-analysis.md
[DICT-001]: ./dictionary.md
[MIL-001]: ./milestones/mil-001-project-foundation.md
[MIL-002]: ./milestones/mil-002-adopt-the-game.md
[MIL-003]: ./milestones/mil-003-continuous-play-and-high-score.md
[MIL-004]: ./milestones/mil-004-high-score-file.md
[MIL-005]: ./milestones/mil-005-wiki-and-finish.md
[020-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/020-snake-game
[021-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/021-snake-game
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/sqa/reviews/rc-001-business-case.md
+69
View File
@@ -0,0 +1,69 @@
# RC-001: Review of BC-001
## Metadata
| Key | Value |
| --- | --- |
| ID | RC-001 |
| CrossReference | [BC-001], [QC-BC-001], [QC-LANG-001], [DICT-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Proposed | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [e004c34] |
---
## Artifact Under Review
- Instance reviewed: [BC-001]
- Checklist used: [QC-BC-001] and, for the language and domain, [QC-LANG-001]
- Scope: full review
- Language and domain: en / it
- Language reviewer: none (the reviewer reads English and knows the IT domain)
- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the assistant also drafted the document)
## Checklist Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | ROI/Cost-Benefit analysis is quantitative, or where qualitative, is explicitly justified | Pass | Cost–Benefit Assessment is qualitative and says why: an unpaid learning project with one participant, so money measures neither side. |
| 2 | Risks are identified with documented impact and mitigation | Pass | Risks table has 11 rows, each with an Impact and a Mitigation. |
| 3 | Success criteria are measurable, stating explicit targets rather than vague aspirations | Pass | Success Criteria has 13 rows with a Target and a Measure; the targets are observable (text strings, file content, exit codes, counts). |
| 4 | Scope explicitly separates In Scope vs Out of Scope | Pass | `### In Scope` and `### Out of Scope` are separate subsections; the out-of-scope list names the mail-merge project, file paths and the PyPI. |
| 5 | Stakeholders are cross-referenced to Stakeholder Analysis IDs rather than re-described inline | Pass | Stakeholders table cites S01, S02 and S03 and states interests only, with objective numbers. |
| 6 | Methodology and quality-standard foundation are stated explicitly (e.g. ISO/IEC 25010, Larman) | Pass | Methodological and Standards Foundation names the framework, Larman, ISO/IEC 25010:2023, PEP 8/257/484, Doxygen and pytest. |
| 7 | Assumptions and constraints are explicit and clearly distinguished from one another | Pass | Assumptions and Constraints are separate lists; the autonomous-mode note and the plan window are in Constraints. |
| 8 | Document supports executive decision-making with a clear, unambiguous recommendation | Pass | Recommendation: "Proceed — ...", one sentence. |
## Language and Domain Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language` is `en` and `Domain` is `it` in Metadata. |
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of BC-001 are English. |
| 4 | The register matches the one the registry gives for the artifact type | Pass | Register is the one the registry gives for the type; code names and commands appear in backticks only where a check needs them. |
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms are those of [DICT-001]: score, high score, reset, continuous play, data file, scoreboard, snake, segment, head, tail, food; `game over` appears only for the base's behaviour and as the removed `game_over` identifier, as the dictionary's rules allow. |
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | `docs/` holds one file per artifact; there is no `<name>.<language>.md`. |
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version of the document: there is no earlier accepted version. |
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The assistant, as stand-in for S01, reads English and knows the IT domain and checked the terms against [DICT-001]; the objectives use the lectures' words. |
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations (SQA, QC, PEP, CI, API, PyPI, FURPS+, RACI, ISO/IEC) are spelled out or defined on first use, or are standard names. |
## Overall Verdict
Go — all Mandatory criteria pass or are not applicable. The rows above were assessed on 2026-10-13 by the assistant that drafted the document, as stand-in for S01 in autonomous mode (chosen by S01 in chat on 2026-10-13). Mode: autonomous, not independent. This review is **not independent**: the drafter and the reviewer are the same assistant, and author and approver (S01) are one person in a single-participant project. S01 accepted the plan in chat on 2026-10-13; the verdict can be challenged in the run summary or on the pull request.
## Action Items
| Action | Owner | Due |
| --- | --- | --- |
| Challenge this `Go` in the run summary or on the pull request if the stand-in decision is not wanted | S01 | 2026-10-15 |
---
[BC-001]: ../../business-case.md
[QC-BC-001]: ../../../framework/qc/artifacts/qc-business-case.md
[QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
[DICT-001]: ../../dictionary.md
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/sqa/reviews/rc-002-stakeholder-analysis.md
+69
View File
@@ -0,0 +1,69 @@
# RC-002: Review of SA-001
## Metadata
| Key | Value |
| --- | --- |
| ID | RC-002 |
| CrossReference | [SA-001], [QC-SA-001], [QC-LANG-001], [DICT-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Proposed | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [e004c34] |
---
## Artifact Under Review
- Instance reviewed: [SA-001]
- Checklist used: [QC-SA-001] and, for the language and domain, [QC-LANG-001]
- Scope: full review
- Language and domain: en / it
- Language reviewer: none (the reviewer reads English and knows the IT domain)
- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the assistant also drafted the document)
## Checklist Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | Power/Interest grid is filled for every stakeholder, with no gaps or unclassified entries | Pass | S01, S02 and S03 each have Power, Interest and Quadrant in the Summary Table; none is unclassified. |
| 2 | Each stakeholder is assigned a unique, stable ID (e.g. S01-S11 style) reusable for RACI assignments in other artifacts | Pass | IDs S01 to S03 are unique and are the IDs the other documents use. |
| 3 | Roles and organizational context are defined with explicit Power and Interest levels, not just narrative description | Pass | Role and organisation are stated and Power and Interest are HIGH or LOW with a rationale for each. |
| 4 | Communication needs (channel, frequency, deliverable type) are mapped to project phases or milestones | Pass | Communication Requirements maps each stakeholder to a channel, frequency, deliverable and milestone (MIL-001, MIL-005). |
| 5 | Conflicting stakeholder interests are identified with documented mitigation or resolution strategies | Pass | Conflicting Interests table has three rows with a mitigation each, including the author-is-reviewer conflict. |
| 6 | Stakeholder concerns are explicitly traced to Business Case objectives | Pass | Business Goal Alignment table traces each concern to a Business Case objective by number. |
| 7 | Primary concerns are expressed in both business language and a recognized quality-attribute mapping (e.g. FURPS+) | Pass | Concerns are in business language and mapped to FURPS+ attributes. |
| 8 | Document is understandable and navigable by non-technical stakeholders reviewing their own entry | Pass | Short, plain tables; each stakeholder can find their entry by ID. |
## Language and Domain Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language` is `en` and `Domain` is `it` in Metadata. |
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of SA-001 are English. |
| 4 | The register matches the one the registry gives for the artifact type | Pass | Register is the one the registry gives for the type; code names and commands appear in backticks only where a check needs them. |
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms are those of [DICT-001]: score, high score, reset, continuous play, data file, scoreboard, snake, segment, head, tail, food; `game over` appears only for the base's behaviour and as the removed `game_over` identifier, as the dictionary's rules allow. |
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | `docs/` holds one file per artifact; there is no `<name>.<language>.md`. |
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version of the document: there is no earlier accepted version. |
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The assistant, as stand-in for S01, reads English and knows the IT domain and checked the terms against [DICT-001]; the concerns use the lectures' words. |
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations (SQA, QC, PEP, CI, API, PyPI, FURPS+, RACI, ISO/IEC) are spelled out or defined on first use, or are standard names. |
## Overall Verdict
Go — all Mandatory criteria pass or are not applicable. The rows above were assessed on 2026-10-13 by the assistant that drafted the document, as stand-in for S01 in autonomous mode (chosen by S01 in chat on 2026-10-13). Mode: autonomous, not independent. This review is **not independent**: the drafter and the reviewer are the same assistant, and author and approver (S01) are one person in a single-participant project. S01 accepted the plan in chat on 2026-10-13; the verdict can be challenged in the run summary or on the pull request.
## Action Items
| Action | Owner | Due |
| --- | --- | --- |
| Challenge this `Go` in the run summary or on the pull request if the stand-in decision is not wanted | S01 | 2026-10-15 |
---
[SA-001]: ../../stakeholder-analysis.md
[QC-SA-001]: ../../../framework/qc/artifacts/qc-stakeholder-analysis.md
[QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
[DICT-001]: ../../dictionary.md
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/sqa/reviews/rc-003-dictionary.md
+68
View File
@@ -0,0 +1,68 @@
# RC-003: Review of DICT-001
## Metadata
| Key | Value |
| --- | --- |
| ID | RC-003 |
| CrossReference | [DICT-001], [QC-DICT-001], [QC-LANG-001], [DICT-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Proposed | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [e004c34] |
---
## Artifact Under Review
- Instance reviewed: [DICT-001]
- Checklist used: [QC-DICT-001] and, for the language and domain, [QC-LANG-001]
- Scope: full review
- Language and domain: en / it
- Language reviewer: none (the reviewer reads English and knows the IT domain)
- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the assistant also drafted the document)
## Checklist Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | Every row has a PO term, its language, an IT term and a definition | Pass | All 28 rows have a PO term, `en`, an IT term and a definition. |
| 2 | Each PO term maps to exactly one IT term and the reverse (no synonyms) | Pass | Each PO term has one IT term and the reverse; the Rules section forbids synonyms. |
| 3 | Every Domain Model concept has a row, and the Domain Model uses its PO term | N-A | No Domain Model exists in this project (Rules section). |
| 4 | The Operation Contracts, Sequence Diagrams, Design Class Diagrams and ERD use the IT term, not the PO term | N-A | No Operation Contract, Sequence Diagram, Design Class Diagram or ERD exists in this project. |
| 5 | Definitions are written in the PO language and are one sentence | Pass | Every definition is one sentence in English. |
| 6 | "Used as PO term in" and "Used as IT term in" name artifact types that exist in the project | Pass | BC, SA, PP and MIL exist; PY is the source code, which the milestones will add. |
| 7 | The dictionary's `Language` and `Domain` rows, and the language of every row, match the PO language and domain in the project registry | Pass | `Language` is `en` and `Domain` is `it`, as the registry states; every row is `en`. |
## Language and Domain Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language` is `en` and `Domain` is `it` in Metadata. |
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of DICT-001 are English. |
| 4 | The register matches the one the registry gives for the artifact type | Pass | Register is the one the registry gives for the type; code names and commands appear in backticks only where a check needs them. |
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | The dictionary is the source of the PO terms; each PO term has one row and no synonym row. |
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | `docs/` holds one file per artifact; there is no `<name>.<language>.md`. |
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version of the document: there is no earlier accepted version. |
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The assistant, as stand-in for S01, reads English and knows the IT domain and checked the terms against [DICT-001]; every term is one row of the dictionary itself. |
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations (SQA, QC, PEP, CI, API, PyPI, FURPS+, RACI, ISO/IEC) are spelled out or defined on first use, or are standard names. |
## Overall Verdict
Go — all Mandatory criteria pass or are not applicable. The rows above were assessed on 2026-10-13 by the assistant that drafted the document, as stand-in for S01 in autonomous mode (chosen by S01 in chat on 2026-10-13). Mode: autonomous, not independent. This review is **not independent**: the drafter and the reviewer are the same assistant, and author and approver (S01) are one person in a single-participant project. S01 accepted the plan in chat on 2026-10-13; the verdict can be challenged in the run summary or on the pull request.
## Action Items
| Action | Owner | Due |
| --- | --- | --- |
| Challenge this `Go` in the run summary or on the pull request if the stand-in decision is not wanted | S01 | 2026-10-15 |
---
[DICT-001]: ../../dictionary.md
[QC-DICT-001]: ../../../framework/qc/artifacts/qc-dictionary.md
[QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
[DICT-001]: ../../dictionary.md
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/sqa/reviews/rc-004-mil-001.md
+67
View File
@@ -0,0 +1,67 @@
# RC-004: Review of MIL-001
## Metadata
| Key | Value |
| --- | --- |
| ID | RC-004 |
| CrossReference | [MIL-001], [QC-MIL-001], [QC-LANG-001], [DICT-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Proposed | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [e004c34] |
---
## Artifact Under Review
- Instance reviewed: [MIL-001]
- Checklist used: [QC-MIL-001] and, for the language and domain, [QC-LANG-001]
- Scope: full review
- Language and domain: en / it
- Language reviewer: none (the reviewer reads English and knows the IT domain)
- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the assistant also drafted the document)
## Checklist Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names the files and results evaluated; 7 tasks are rows in `## Tasks`. |
| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go / No-Go table has 12 criteria, each with an observable Go and No-Go (exit codes, text, file content, warnings). |
| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the milestone that must be accepted and merged first. |
| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability table cites [BC-001] objectives 8, 9, 10, 11 and 12 and the Success Criteria numbers. |
| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership table: Owner S01, Approving reviewer S01 (a stakeholder ID of [SA-001]). |
| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date is inside the plan window of [PP-001] (ends 2026-10-25) and the Business Case constraint. |
## Language and Domain Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language` is `en` and `Domain` is `it` in Metadata. |
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of MIL-001 are English. |
| 4 | The register matches the one the registry gives for the artifact type | Pass | Register is the one the registry gives for the type; code names and commands appear in backticks only where a check needs them. |
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms are those of [DICT-001]: score, high score, reset, continuous play, data file, scoreboard, snake, segment, head, tail, food; `game over` appears only for the base's behaviour and as the removed `game_over` identifier, as the dictionary's rules allow. |
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | `docs/` holds one file per artifact; there is no `<name>.<language>.md`. |
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version of the document: there is no earlier accepted version. |
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The assistant, as stand-in for S01, reads English and knows the IT domain and checked the terms against [DICT-001]; task titles and criteria use dictionary terms. |
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations (SQA, QC, PEP, CI, API, PyPI, FURPS+, RACI, ISO/IEC) are spelled out or defined on first use, or are standard names. |
## Overall Verdict
Go — all Mandatory criteria pass or are not applicable. The rows above were assessed on 2026-10-13 by the assistant that drafted the document, as stand-in for S01 in autonomous mode (chosen by S01 in chat on 2026-10-13). Mode: autonomous, not independent. This review is **not independent**: the drafter and the reviewer are the same assistant, and author and approver (S01) are one person in a single-participant project. S01 accepted the plan in chat on 2026-10-13; the verdict can be challenged in the run summary or on the pull request.
## Action Items
| Action | Owner | Due |
| --- | --- | --- |
| Challenge this `Go` in the run summary or on the pull request if the stand-in decision is not wanted | S01 | 2026-10-15 |
---
[MIL-001]: ../../milestones/mil-001-project-foundation.md
[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
[QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
[DICT-001]: ../../dictionary.md
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/sqa/reviews/rc-005-mil-002.md
+67
View File
@@ -0,0 +1,67 @@
# RC-005: Review of MIL-002
## Metadata
| Key | Value |
| --- | --- |
| ID | RC-005 |
| CrossReference | [MIL-002], [QC-MIL-001], [QC-LANG-001], [DICT-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Proposed | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [e004c34] |
---
## Artifact Under Review
- Instance reviewed: [MIL-002]
- Checklist used: [QC-MIL-001] and, for the language and domain, [QC-LANG-001]
- Scope: full review
- Language and domain: en / it
- Language reviewer: none (the reviewer reads English and knows the IT domain)
- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the assistant also drafted the document)
## Checklist Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names the files and results evaluated; 7 tasks are rows in `## Tasks`. |
| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go / No-Go table has 11 criteria, each with an observable Go and No-Go (exit codes, text, file content, warnings). |
| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the milestone that must be accepted and merged first. |
| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability table cites [BC-001] objectives 1, 7, 9 and 11 and the Success Criteria numbers. |
| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership table: Owner S01, Approving reviewer S01 (a stakeholder ID of [SA-001]). |
| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date is inside the plan window of [PP-001] (ends 2026-10-25) and the Business Case constraint. |
## Language and Domain Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language` is `en` and `Domain` is `it` in Metadata. |
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of MIL-002 are English. |
| 4 | The register matches the one the registry gives for the artifact type | Pass | Register is the one the registry gives for the type; code names and commands appear in backticks only where a check needs them. |
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms are those of [DICT-001]: score, high score, reset, continuous play, data file, scoreboard, snake, segment, head, tail, food; `game over` appears only for the base's behaviour and as the removed `game_over` identifier, as the dictionary's rules allow. |
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | `docs/` holds one file per artifact; there is no `<name>.<language>.md`. |
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version of the document: there is no earlier accepted version. |
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The assistant, as stand-in for S01, reads English and knows the IT domain and checked the terms against [DICT-001]; task titles and criteria use dictionary terms. |
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations (SQA, QC, PEP, CI, API, PyPI, FURPS+, RACI, ISO/IEC) are spelled out or defined on first use, or are standard names. |
## Overall Verdict
Go — all Mandatory criteria pass or are not applicable. The rows above were assessed on 2026-10-13 by the assistant that drafted the document, as stand-in for S01 in autonomous mode (chosen by S01 in chat on 2026-10-13). Mode: autonomous, not independent. This review is **not independent**: the drafter and the reviewer are the same assistant, and author and approver (S01) are one person in a single-participant project. S01 accepted the plan in chat on 2026-10-13; the verdict can be challenged in the run summary or on the pull request.
## Action Items
| Action | Owner | Due |
| --- | --- | --- |
| Challenge this `Go` in the run summary or on the pull request if the stand-in decision is not wanted | S01 | 2026-10-15 |
---
[MIL-002]: ../../milestones/mil-002-adopt-the-game.md
[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
[QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
[DICT-001]: ../../dictionary.md
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/sqa/reviews/rc-006-mil-003.md
+67
View File
@@ -0,0 +1,67 @@
# RC-006: Review of MIL-003
## Metadata
| Key | Value |
| --- | --- |
| ID | RC-006 |
| CrossReference | [MIL-003], [QC-MIL-001], [QC-LANG-001], [DICT-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Proposed | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [e004c34] |
---
## Artifact Under Review
- Instance reviewed: [MIL-003]
- Checklist used: [QC-MIL-001] and, for the language and domain, [QC-LANG-001]
- Scope: full review
- Language and domain: en / it
- Language reviewer: none (the reviewer reads English and knows the IT domain)
- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the assistant also drafted the document)
## Checklist Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names the files and results evaluated; 7 tasks are rows in `## Tasks`. |
| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go / No-Go table has 12 criteria, each with an observable Go and No-Go (exit codes, text, file content, warnings). |
| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the milestone that must be accepted and merged first. |
| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability table cites [BC-001] objectives 2, 3, 4 and 7 and the Success Criteria numbers. |
| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership table: Owner S01, Approving reviewer S01 (a stakeholder ID of [SA-001]). |
| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date is inside the plan window of [PP-001] (ends 2026-10-25) and the Business Case constraint. |
## Language and Domain Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language` is `en` and `Domain` is `it` in Metadata. |
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of MIL-003 are English. |
| 4 | The register matches the one the registry gives for the artifact type | Pass | Register is the one the registry gives for the type; code names and commands appear in backticks only where a check needs them. |
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms are those of [DICT-001]: score, high score, reset, continuous play, data file, scoreboard, snake, segment, head, tail, food; `game over` appears only for the base's behaviour and as the removed `game_over` identifier, as the dictionary's rules allow. |
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | `docs/` holds one file per artifact; there is no `<name>.<language>.md`. |
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version of the document: there is no earlier accepted version. |
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The assistant, as stand-in for S01, reads English and knows the IT domain and checked the terms against [DICT-001]; task titles and criteria use dictionary terms. |
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations (SQA, QC, PEP, CI, API, PyPI, FURPS+, RACI, ISO/IEC) are spelled out or defined on first use, or are standard names. |
## Overall Verdict
Go — all Mandatory criteria pass or are not applicable. The rows above were assessed on 2026-10-13 by the assistant that drafted the document, as stand-in for S01 in autonomous mode (chosen by S01 in chat on 2026-10-13). Mode: autonomous, not independent. This review is **not independent**: the drafter and the reviewer are the same assistant, and author and approver (S01) are one person in a single-participant project. S01 accepted the plan in chat on 2026-10-13; the verdict can be challenged in the run summary or on the pull request.
## Action Items
| Action | Owner | Due |
| --- | --- | --- |
| Challenge this `Go` in the run summary or on the pull request if the stand-in decision is not wanted | S01 | 2026-10-15 |
---
[MIL-003]: ../../milestones/mil-003-continuous-play-and-high-score.md
[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
[QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
[DICT-001]: ../../dictionary.md
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/sqa/reviews/rc-007-mil-004.md
+67
View File
@@ -0,0 +1,67 @@
# RC-007: Review of MIL-004
## Metadata
| Key | Value |
| --- | --- |
| ID | RC-007 |
| CrossReference | [MIL-004], [QC-MIL-001], [QC-LANG-001], [DICT-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Proposed | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [e004c34] |
---
## Artifact Under Review
- Instance reviewed: [MIL-004]
- Checklist used: [QC-MIL-001] and, for the language and domain, [QC-LANG-001]
- Scope: full review
- Language and domain: en / it
- Language reviewer: none (the reviewer reads English and knows the IT domain)
- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the assistant also drafted the document)
## Checklist Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names the files and results evaluated; 7 tasks are rows in `## Tasks`. |
| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go / No-Go table has 11 criteria, each with an observable Go and No-Go (exit codes, text, file content, warnings). |
| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the milestone that must be accepted and merged first. |
| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability table cites [BC-001] objectives 5, 6 and 9 and the Success Criteria numbers. |
| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership table: Owner S01, Approving reviewer S01 (a stakeholder ID of [SA-001]). |
| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date is inside the plan window of [PP-001] (ends 2026-10-25) and the Business Case constraint. |
## Language and Domain Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language` is `en` and `Domain` is `it` in Metadata. |
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of MIL-004 are English. |
| 4 | The register matches the one the registry gives for the artifact type | Pass | Register is the one the registry gives for the type; code names and commands appear in backticks only where a check needs them. |
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms are those of [DICT-001]: score, high score, reset, continuous play, data file, scoreboard, snake, segment, head, tail, food; `game over` appears only for the base's behaviour and as the removed `game_over` identifier, as the dictionary's rules allow. |
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | `docs/` holds one file per artifact; there is no `<name>.<language>.md`. |
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version of the document: there is no earlier accepted version. |
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The assistant, as stand-in for S01, reads English and knows the IT domain and checked the terms against [DICT-001]; task titles and criteria use dictionary terms. |
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations (SQA, QC, PEP, CI, API, PyPI, FURPS+, RACI, ISO/IEC) are spelled out or defined on first use, or are standard names. |
## Overall Verdict
Go — all Mandatory criteria pass or are not applicable. The rows above were assessed on 2026-10-13 by the assistant that drafted the document, as stand-in for S01 in autonomous mode (chosen by S01 in chat on 2026-10-13). Mode: autonomous, not independent. This review is **not independent**: the drafter and the reviewer are the same assistant, and author and approver (S01) are one person in a single-participant project. S01 accepted the plan in chat on 2026-10-13; the verdict can be challenged in the run summary or on the pull request.
## Action Items
| Action | Owner | Due |
| --- | --- | --- |
| Challenge this `Go` in the run summary or on the pull request if the stand-in decision is not wanted | S01 | 2026-10-15 |
---
[MIL-004]: ../../milestones/mil-004-high-score-file.md
[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
[QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
[DICT-001]: ../../dictionary.md
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/sqa/reviews/rc-008-mil-005.md
+67
View File
@@ -0,0 +1,67 @@
# RC-008: Review of MIL-005
## Metadata
| Key | Value |
| --- | --- |
| ID | RC-008 |
| CrossReference | [MIL-005], [QC-MIL-001], [QC-LANG-001], [DICT-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Proposed | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [e004c34] |
---
## Artifact Under Review
- Instance reviewed: [MIL-005]
- Checklist used: [QC-MIL-001] and, for the language and domain, [QC-LANG-001]
- Scope: full review
- Language and domain: en / it
- Language reviewer: none (the reviewer reads English and knows the IT domain)
- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the assistant also drafted the document)
## Checklist Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names the files and results evaluated; 5 tasks are rows in `## Tasks`. |
| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go / No-Go table has 8 criteria, each with an observable Go and No-Go (exit codes, text, file content, warnings). |
| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the milestone that must be accepted and merged first. |
| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability table cites [BC-001] objectives 10, 11 and 12 and the Success Criteria numbers. |
| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership table: Owner S01, Approving reviewer S01 (a stakeholder ID of [SA-001]). |
| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date is inside the plan window of [PP-001] (ends 2026-10-25) and the Business Case constraint. |
## Language and Domain Results
| # | Criterion | Status | Evidence/Notes |
| --- | --- | --- | --- |
| 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language` is `en` and `Domain` is `it` in Metadata. |
| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of MIL-005 are English. |
| 4 | The register matches the one the registry gives for the artifact type | Pass | Register is the one the registry gives for the type; code names and commands appear in backticks only where a check needs them. |
| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms are those of [DICT-001]: score, high score, reset, continuous play, data file, scoreboard, snake, segment, head, tail, food; `game over` appears only for the base's behaviour and as the removed `game_over` identifier, as the dictionary's rules allow. |
| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | `docs/` holds one file per artifact; there is no `<name>.<language>.md`. |
| 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | N-A | First version of the document: there is no earlier accepted version. |
| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The assistant, as stand-in for S01, reads English and knows the IT domain and checked the terms against [DICT-001]; task titles and criteria use dictionary terms. |
| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations (SQA, QC, PEP, CI, API, PyPI, FURPS+, RACI, ISO/IEC) are spelled out or defined on first use, or are standard names. |
## Overall Verdict
Go — all Mandatory criteria pass or are not applicable. The rows above were assessed on 2026-10-13 by the assistant that drafted the document, as stand-in for S01 in autonomous mode (chosen by S01 in chat on 2026-10-13). Mode: autonomous, not independent. This review is **not independent**: the drafter and the reviewer are the same assistant, and author and approver (S01) are one person in a single-participant project. S01 accepted the plan in chat on 2026-10-13; the verdict can be challenged in the run summary or on the pull request.
## Action Items
| Action | Owner | Due |
| --- | --- | --- |
| Challenge this `Go` in the run summary or on the pull request if the stand-in decision is not wanted | S01 | 2026-10-15 |
---
[MIL-005]: ../../milestones/mil-005-wiki-and-finish.md
[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
[QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
[DICT-001]: ../../dictionary.md
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
docs/stakeholder-analysis.md
+99
View File
@@ -0,0 +1,99 @@
# Stakeholder Analysis: Snake Game (Day 24)
## Metadata
| Key | Value |
| --- | --- |
| ID | SA-001 |
| CrossReference | [BC-001], [DICT-001] |
| Language | en |
| Domain | it |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-002 (Go) | [e004c34] |
---
## Purpose
This analysis names the people and groups who have a stake in the Snake Game (Day 24) project, a solution to the day-24 assignment of Udemy's *100 Days of Code: The Complete Python Pro Bootcamp*, and classifies each one on a power/interest grid so the project knows how closely to involve them. The stakeholder IDs (`S01` to `S03`) are the IDs every other artifact uses for owners, reviewers and RACI (Responsible, Accountable, Consulted, Informed) assignments. The terms follow the Domain Dictionary [DICT-001]. The method is the power/interest grid: the quadrant decides how often and with what deliverable a stakeholder is addressed.
The Product Owner stated S01, S02 and S03, the Power and Interest levels of S01, the quadrant of S01, and the deliverables of S02 and S03. The Power and Interest levels of S02 and S03 were not stated; they are proposed here, as in [021-snake-game], and are open for confirmation by the reviewer.
## Stakeholder Summary Table
| ID | Name | Role/Title | Organization | Power Level | Interest Level | Quadrant | Primary Concern (Business Language) |
| --- | --- | --- | --- | --- | --- | --- | --- |
| S01 | Jens Tirsvad Nielsen | Course participant; Product Owner, developer and reviewer | Tirsvad (personal learning project) | HIGH | HIGH | Manage Closely | A correct, tested and documented solution of the assignment that is worth keeping and showing |
| S02 | Udemy coursists | Fellow course participants who share code and compare solutions | Udemy course community (external) | LOW | HIGH | Keep Informed | Readable, runnable code that uses the assignment's function names, with README instructions to run it |
| S03 | GitHub viewers | Visitors who browse the repository for ideas | Public (external) | LOW | LOW | Monitor | A clear repository description, topics and README, and no runtime dependencies to install |
## Power/Interest Classification Rationale
- **Manage Closely (S01):** S01 decides scope, adopts and checks the code, and reviews every artifact, so power and interest are both high. S01 is author and reviewer of the same documents; no independent reviewer exists in this project (see the conflict table).
- **Keep Informed (S02):** S02 cannot change the scope or accept a deliverable, so power is low. They compare solutions with their own, so interest in the code's readability and in the way to run it is high. They need the code and the README, not a say in the plan.
- **Monitor (S03):** S03 arrive by chance, do not take part and cannot influence the project, so power and interest are low. Their first impression is the repository page, which is why description, topics, README and wiki are checked once.
## Primary Concerns and FURPS+ Mapping
FURPS+ stands for Functionality, Usability, Reliability, Performance, Supportability and the added constraints (design, implementation, interface, physical).
| ID | Concern | FURPS+ attribute |
| --- | --- | --- |
| S01 | The game behaves as the day-24 lectures describe: the high score is shown, a collision resets and play continues, and the high score is kept in `data.txt` | Functionality |
| S01 | The day-21 behaviour is kept | Functionality |
| S01 | Behaviour, including the file handling, is proven by tests that run without a display and never touch the real high score | Reliability |
| S01 | Every step is a branch and a pull request, reviewed before the next | Supportability |
| S02 | The code is readable and keeps the assignment's names (`Snake`, `Food`, `Scoreboard`, `reset`, `high_score`, `update_scoreboard`, `increase_score`, `create_snake`, `add_segment`, `extend`, `up`, `down`, `left`, `right`, `segments`, `head`, `game_is_on`) | Usability |
| S02 | The README tells how to create the `.venv`, run the game and run the tests on their operating system | Usability |
| S03 | The repository page says what the project is, with description, topics, README and a wiki in English, Danish and Bahasa Melayu | Usability |
| S03 | Nothing must be installed to run the game apart from Python itself | Implementation (constraint) |
## Communication Requirements
| ID | Channel | Frequency | Deliverable | Phase / Milestone |
| --- | --- | --- | --- | --- |
| S01 | Pull request review in the git host | Once per milestone | Pull request with `Closes #N` lines and the review record | Every milestone ([PP-001]) |
| S02 | README in the repository | Once, updated when the game changes | Set-up, run and test instructions per operating system | [MIL-001], completed in [MIL-005] |
| S03 | Repository description, topics and README | Once, updated when the game changes | Description, topics and README overview | [MIL-001], checked in [MIL-005] |
| S03 | Wiki of the repository | Once | Pages `Home`, `Home.da` and `Home.ms` with a short description, the controls and how to run it | [MIL-005] |
## Conflicting Interests and Mitigations
| Conflict | Stakeholders | Mitigation |
| --- | --- | --- |
| S02 wants plain code in the style of the lecture; S01 wants constants, tests, Doxygen comments and packaging, which add structure | S01, S02 | Keep the lecture's identifiers and flow; put the extra structure in separate places (`constants.py`, an injectable file path) so the main flow stays readable |
| S03 wants nothing to install; S01 needs pytest and Doxygen | S01, S03 | The project has no runtime dependencies; pytest is an optional `dev` extra and Doxygen is an optional documentation tool |
| S01 is author and reviewer, so a review is not independent | S01 | Use the QC checklists as the objective measure, record every review as an `RC-*` (marked `Mode: autonomous, not independent`), and treat the pull request as the second look; recorded as a plan risk in [PP-001] |
## Traceability Analysis
### Business Goal Alignment
| Stakeholder | Concern | Business Case objective |
| --- | --- | --- |
| S01 | Game behaves as the day-24 lectures describe | [BC-001] objectives 2 to 6 |
| S01 | Day-21 behaviour is kept | [BC-001] objective 1 |
| S01 | Tests run without a display and never touch the real file | [BC-001] objective 9 |
| S01 | Every step is a branch and a pull request | [BC-001] objective 11 |
| S02 | Readable code with the assignment's names | [BC-001] objective 7 |
| S02 | README with run and test instructions | [BC-001] objectives 8 and 10 |
| S03 | Description, topics, README and wiki on the repository page | [BC-001] objective 12 |
| S03 | No runtime dependencies | [BC-001] objective 8 |
## Sign-Off
| Stakeholder | Decision | Date |
| --- | --- | --- |
| S01 | Go in RC-002 (not independent; S01 can overrule) | 2026-10-13 |
---
[BC-001]: ./business-case.md
[DICT-001]: ./dictionary.md
[PP-001]: ./project-plan.md
[MIL-001]: ./milestones/mil-001-project-foundation.md
[MIL-005]: ./milestones/mil-005-wiki-and-finish.md
[021-snake-game]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/021-snake-game
[e004c34]: https://git.tirsystem.com/Tirsvad-Udemy-100-days-of-code/024-snake/commit/e004c34565839b38dc1e06c8a05baaa66ce9eb1d
framework
Submodule
+1
Submodule framework added at 6baeadd3c1