.gitignore

@@ -0,0 +1,45 @@
+# Secrets and personal files
+.env
+
+# AI prompt log (the repository is public)
+/docs/ai-prompts/
+
+# Python
+__pycache__/
+*.py[cod]
+*.egg-info/
+build/
+dist/
+.eggs/
+
+# Virtual environments
+.venv/
+venv/
+env/
+
+# Tests and coverage
+.pytest_cache/
+.coverage
+.coverage.*
+htmlcov/
+coverage.xml
+
+# Type checker and linter caches
+.mypy_cache/
+.ruff_cache/
+
+# Doxygen output
+/docs/doxygen/
+
+# Browser run artefacts (the lecture screenshots in docs/images are kept)
+/output/
+*.log
+
+# Editors and operating system
+.idea/
+.vscode/
+.DS_Store
+Thumbs.db
+
+# Selenium Chrome profile created by the bot (holds the practice site data)
+/chrome_profile/

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "framework"]
+	path = framework
+	url = ssh://git@git.tirsystem.com:10022/TirSystem/SQA-QC-Framework.git

docs/adr/adr-0001-skip-stories-use-cases.md

@@ -0,0 +1,48 @@
+# ADR-0001 Skip user stories and use cases
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | ADR-0001 |
+| CrossReference | [BC-001], [PP-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+Allowed Status values: `Proposed`, `Accepted`, `Rejected`, `Deprecated`, `Superseded by ADR-NNNN`.
+
+---
+
+## Context
+
+The journey of the `create-project` skill offers user stories, use cases and their design artifacts (domain model, system sequence diagrams, operation contracts, design class diagrams, ERD). The bot has one actor (S01 running the script), one linear flow (log in, book, verify) and no persistent data of its own. Options:
+
+1. Write user stories and use cases for the nine lecture steps.
+2. Skip them and plan the work as technical tasks that cite the Business Case objectives.
+
+## Decision
+
+Option 2. The milestones list technical tasks with the Business Case objective as reference ("Needs its own Use Case/User Story?" is `No`). The lecture steps are the unit of planning.
+
+## Consequences
+
+**Positive:**
+
+- Less documentation than code for a very small program.
+- Each task still traces to an objective (O1 to O8).
+
+**Negative:**
+
+- No use case documents or design diagrams exist; the code reviews cannot trace classes to a Design Class Diagram and record that criterion as not applicable with this ADR as reason.
+
+## Affected Artifacts
+
+- [BC-001] — objectives the tasks trace to
+- [PP-001] — gateways list no stories
+
+---
+
+[BC-001]: ../business-case.md
+[PP-001]: ../project-plan.md

docs/adr/adr-0002-light-clean-architecture.md

@@ -0,0 +1,49 @@
+# ADR-0002 Light Clean Architecture without a presentation layer
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | ADR-0002 |
+| CrossReference | [BC-001], [SA-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+Allowed Status values: `Proposed`, `Accepted`, `Rejected`, `Deprecated`, `Superseded by ADR-NNNN`.
+
+---
+
+## Context
+
+S02 wants simple code with the assignment's function names, while the framework's `clean-architecture` skill wants business rules that do not depend on Selenium. The booking rules (which class is a Tuesday 6pm class, what to do for each button state, how to count and compare) can be tested without a browser. Options:
+
+1. One script file with all steps, as in the lecture.
+2. Layers `domain` (rules and plain data), `application` (use of the rules through a browser port, `retry`), `infrastructure` (Selenium adapter) and a thin command-line entry point.
+3. Full four layers with MVC.
+
+## Decision
+
+Option 2. `domain` and `application` import no Selenium; `infrastructure` holds the Selenium adapter; `cli.py` and `__main__.py` compose them. The assignment's functions `retry`, `login`, `book_class` and `get_my_bookings` are the public names in `application`. There is no MVVM or MVC layer because the program is a command-line bot.
+
+## Consequences
+
+**Positive:**
+
+- The rules and the retry logic are unit tested with fakes, without a browser.
+- Selenium is the only runtime dependency and is confined to one package.
+
+**Negative:**
+
+- More files than the lecture's single script, which S02 has to navigate; the README and wiki explain the map.
+
+## Affected Artifacts
+
+- [BC-001] — objective O7 and success criterion 5
+- [SA-001] — concerns CN-004 and CN-008
+
+---
+
+[BC-001]: ../business-case.md
+[SA-001]: ../stakeholder-analysis.md

docs/adr/adr-0003-docker-headless-browser.md

@@ -0,0 +1,52 @@
+# ADR-0003 Browser runs and screenshots in a Docker container
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | ADR-0003 |
+| CrossReference | [BC-001], [MIL-002], [MIL-003] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+Allowed Status values: `Proposed`, `Accepted`, `Rejected`, `Deprecated`, `Superseded by ADR-NNNN`.
+
+---
+
+## Context
+
+The bot drives a real browser and every lecture step needs a screenshot. The framework forbids testing a GUI on the host desktop because it takes the user's mouse and keyboard (`framework/process/gui-testing.md`). Options:
+
+1. Run Chrome on the host desktop.
+2. Run headless Chromium in a Docker container (Linux).
+3. Run in Windows Sandbox.
+
+## Decision
+
+Option 2. A Dockerfile builds an image with Python, Chromium and its driver; the bot takes a headless option, so the same code runs on the host for users who want it. The practice site keeps its data in the browser profile, so a container run keeps the `chrome_profile` folder in a Docker volume.
+
+## Consequences
+
+**Positive:**
+
+- No interference with the user's desktop; reproducible runs for S02.
+- Screenshots are made the same way each time.
+
+**Negative:**
+
+- Docker is needed for the real-browser runs and screenshots (unit tests need no Docker).
+- The image download is large.
+
+## Affected Artifacts
+
+- [BC-001] — risk of non-reproducible runs
+- [MIL-002] — builds the image
+- [MIL-003] — first container run
+
+---
+
+[BC-001]: ../business-case.md
+[MIL-002]: ../milestones/mil-002-scaffold.md
+[MIL-003]: ../milestones/mil-003-login.md

docs/artifact-registry.md

@@ -0,0 +1,62 @@
+# 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/use-cases/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 | 009 |
+| ADR | Architecture Decision Record | docs/adr/adr-NNNN-*.md | 0004 |
+| RC | SQA Review Record | docs/sqa/reviews/rc-*.md | 016 |
+| TM | Traceability Matrix | docs/sqa/traceability-matrix.md | 002 |
+| DICT | Domain Dictionary | docs/dictionary.md | 002 |
+
+## 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 |
+| Wiki languages | en and the PO language, at least (`framework/process/wiki.md`) |
+
+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, TP, AD, 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

@@ -0,0 +1,155 @@
+# Business Case: Snack and Lift Booking Bot
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | BC-001 |
+| CrossReference | [SA-001] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version: Snack and Lift booking bot (Udemy day 49) | pending |
+
+---
+
+## Executive Summary
+
+Course participant S01 needs a Python bot that books classes at the fictional gym "Snack and Lift" (a practice site on GitHub Pages) without a human. The bot uses Selenium with its own Chrome profile, logs in, books every Tuesday and Thursday 6pm class in the next seven days, joins the waitlist when a class is full, verifies the result on the "My Bookings" page, copes with a site that fails half of its requests, and prints a clear summary. The result is a small, readable, runnable repository that other Udemy course participants (S02) can compare with their own solutions and that GitHub visitors (S03) can browse for ideas, with the assignment's function names, English, Danish and Bahasa Malaysia wiki pages and a screenshot for every lecture step.
+
+## Methodological and Standards Foundation
+
+- Process: the SQA and QC framework mounted at `framework/` (plan-first gate, review records, one pull request per milestone).
+- Quality model: ISO/IEC 25010:2023 characteristics tag every QC criterion.
+- Design: Clean Architecture in a light form (booking rules separated from the Selenium adapter), as described by the `clean-architecture` skill; the program is a command-line bot, so it has no MVVM or MVC presentation layer.
+- Code: Python 3.13 or newer, Doxygen comments, `pytest` for tests, constants in `constants.py`, project configuration in `pyproject.toml`.
+
+## Problem Statement
+
+The Udemy lecture "Create an Automated Booking System" (100 Days of Code, day 49) asks the participant to build a Selenium bot for the Snack and Lift gym site. Solutions shared in the course Q&A are often single untested scripts without instructions, which makes them hard to run, compare and learn from. This participant also wants to keep the work as a documented, reviewed repository.
+
+## Business Opportunity
+
+A documented and tested solution that runs from a README gives participants a reference to compare their selectors, their retry logic and their code with. The wiki explains what each lecture step teaches, in three languages, so Danish and Malay speaking learners can follow too. The skills (waiting for dynamic content, retrying after network failures, verifying a result) apply to many other web automation tasks.
+
+## Objectives
+
+1. O1: Deliver a bot that starts Chrome with its own persistent profile and opens the gym site (lecture step 1).
+2. O2: The bot logs in automatically and confirms the class schedule is shown (step 2).
+3. O3: The bot books a Tuesday 6pm class, then checks the button state first: "Booked", "Waitlisted" or "Join Waitlist" (steps 3 and 4).
+4. O4: The bot counts what it did and prints a summary, then handles every Tuesday and Thursday 6pm class with a detailed list (steps 5 and 6).
+5. O5: The bot verifies the bookings on the "My Bookings" page and reports a match or a mismatch, and works at any date of the site's time travel (steps 7 and 8).
+6. O6: The bot survives a 50% network failure rate with a `retry` wrapper, `login()`, `book_class()` and `get_my_bookings()` (step 9).
+7. O7: Provide the repository hygiene for S02 and S03: README from the framework template, run and test instructions, `.venv` instructions, Doxygen configuration, repository description and topics.
+8. O8: Provide wiki pages in English, Danish and Bahasa Malaysia that explain what each lecture step teaches, each with a screenshot.
+
+## Scope
+
+### In Scope
+
+- Selenium bot for the practice site at the GitHub Pages address of appbrewery/gym, with the assignment's function names (`retry`, `login`, `book_class`, `get_my_bookings`).
+- Lecture steps 1 to 9.
+- Python project: `src/`, `tests/`, `docs/`, `pyproject.toml`, `constants.py`, `.gitignore`, Doxyfile, README.
+- Unit tests with `pytest`; the parsing, decision, counting and retry logic is tested without a browser.
+- One screenshot per lecture step, taken from a headless browser in a Docker container and used in the README and the wiki.
+- Wiki in en, da and ms, published to the git host.
+- Repository description and topics on `git.tirsystem.com`.
+
+### Out of Scope
+
+- Automating anything other than the practice site; real gym sites.
+- Creating the student account automatically (the assignment does it manually once).
+- A graphical user interface or a web API.
+- Distribution as a package on PyPI.
+- Running GUI tests on the host desktop (framework rule: container or sandbox only).
+
+## Expected Benefits
+
+### Tangible Benefits
+
+- A runnable bot that prints a booking summary and a verification result.
+- A test suite that protects the card parsing, booking decision and retry logic.
+- Documentation (README, wiki in three languages) that a newcomer can follow without help.
+
+### Intangible Benefits
+
+- Learning value for S01 and S02: Selenium, explicit waits, XPath ancestors, retry patterns and verification.
+- A worked example of the framework's plan, review and pull request flow on a small project.
+
+## Strategic Alignment
+
+The project is a learning exercise inside the 100 Days of Code bootcamp. It supports S01's goal of finishing the course with reviewed, shareable work and the S02 and S03 goal of finding clear, runnable examples.
+
+## Success Criteria
+
+| # | Criterion | Target | Measure |
+| --- | --- | --- | --- |
+| 1 | Booking rule is correct | Every Tuesday and Thursday 6pm class gets exactly one action, and a day is never decided by list position, in 100% of unit test cases | `pytest` result |
+| 2 | Summary is printed | The summary lists new bookings, new waitlist entries, already booked and the total | Output of the run |
+| 3 | Verification works | "Expected" equals "Found" on the My Bookings page after a run | Output of the run |
+| 4 | The bot survives failures | A container run with the site's 50% failure rate reaches the verification result | Output of the run |
+| 5 | Tests pass | 0 failing tests; at least 80% line coverage of the logic modules | `pytest` with coverage |
+| 6 | A newcomer can run the project | README setup, run and test commands work on a clean clone | Walk-through on a clean clone by S01 |
+| 7 | Documentation is complete | Screenshots for 9 of 9 lecture steps in README and in the 3 wiki languages | Count of images per page |
+| 8 | Repository metadata is set | Description and at least 5 topics present | Repository API response |
+| 9 | No runtime dependency beyond Selenium | `pyproject.toml` lists Selenium as the only runtime dependency | `pyproject.toml` |
+
+## Risks
+
+| Risk | Impact | Mitigation |
+| --- | --- | --- |
+| The practice site changes its element IDs | The bot fails | Keep all selectors in `constants.py`; document the site version used; fail with a clear message |
+| The site keeps its state in the browser profile, so a container run starts from an empty database | The student account is missing in the container | The container run registers the test account through the site's own form with a documented test credential, or reuses a profile volume |
+| Time and booking state differ between runs | Flaky tests and screenshots | Unit tests need no browser; browser runs reset the data through the admin page first |
+| The token for the git host is exposed | Account misuse | Tokens are read from the personal `.env`; never printed, imported, tested or committed |
+| Autonomous mode review is not independent | A defect passes review | Stand-in decisions are marked in each `RC-*` and open to challenge in the final summary by S01 |
+| Translations contain errors | Misleading wiki pages | English is authoritative; da and ms follow it page by page and S01 can correct them |
+
+## Assumptions
+
+- S01 is the Product Owner, the developer and the reviewer; in autonomous mode the AI acts as stand-in reviewer and records it.
+- The people the project is for (S02, S03) cannot be reached for interviews; their needs come from the assignment text and S01.
+- The practice site remains available at its GitHub Pages address during the project, and its admin account is the one named in the assignment.
+- Docker is available for the headless browser runs.
+- The target repository is the one named by `origin` unless S01 states otherwise (see the Project Plan, Open Issues).
+- The idea is validated by the course assignment itself, so no riskiest-assumption test (`RA`) is planned.
+
+## Constraints
+
+- Python 3.13 or newer, a local `.venv`, `pyproject.toml`, `pytest`, constants in `constants.py`.
+- Folder structure `src/`, `tests/`, `docs/`.
+- No runtime dependency unless it is needed.
+- Doxygen comments in source and a Doxyfile.
+- The wiki exists in English, Danish and Bahasa Malaysia.
+- Each pull request is a branch that tracks one step; the framework cannot be edited from this project.
+- The PO language is English, the domain is IT.
+- Credentials come from a personal `.env`, which is not part of the project.
+- The Business Case sets no deadline; the Project Plan assumes 2026-10-28 to 2026-11-06.
+
+## Cost–Benefit Assessment
+
+The assessment is qualitative: this is an unpaid learning project, and no revenue exists to quantify.
+
+| Costs | Benefits |
+| --- | --- |
+| Effort of S01 for reviewing the plan and the final summary | A reusable, tested bot and a three language learning wiki |
+| AI work and compute for planning, code, screenshots and translation | A repository that S02 and S03 can read and run |
+| Maintenance if the practice site changes | Practice of the framework flow on a small scope |
+
+## Stakeholders
+
+| Stakeholder ID (SA) | Interest in this project |
+| --- | --- |
+| S01 | Product Owner, developer and reviewer; wants a finished, reviewed course assignment |
+| S02 | Udemy course participants; want readable, runnable code with the assignment's function names and README instructions |
+| S03 | GitHub viewers; want a clear description, topics and README, and no runtime dependencies |
+
+## Recommendation
+
+Proceed: the scope is small, the risks have mitigations, and the narrowest first release meets all objectives.
+
+---
+
+[SA-001]: ./stakeholder-analysis.md

docs/dictionary.md

@@ -0,0 +1,46 @@
+# Domain Dictionary
+
+## 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-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version: eight gym and course terms | pending |
+
+---
+
+## Purpose and Scope
+
+Maps each Product Owner (PO) term to its professional IT term. PO language: English (`en`), domain `it`. It covers the gym site and course terms used by the Business Case and the milestones.
+
+## Dictionary
+
+| PO term | Language | IT term | Definition | Used as PO term in | Used as IT term in |
+| --- | --- | --- | --- | --- | --- |
+| Booking | en | Reservation record | A place in a class held by the student account, shown on the My Bookings page. | BC, SA, MIL | - |
+| Bot | en | Automation script | A program that books classes without a human. | BC, SA, MIL | - |
+| Class card | en | Schedule entry | One class in the schedule, with its name, time and booking button. | BC, MIL | - |
+| Lecture step | en | Assignment step | One of the nine numbered steps of the Udemy challenge. | BC, SA, MIL | - |
+| Profile | en | Browser profile | The Chrome user data folder where the practice site keeps its data between runs. | BC, MIL | - |
+| Retry | en | Retry wrapper | A function that repeats an action that failed because of a network error. | BC, SA, MIL | - |
+| Time travel | en | Simulated clock | The admin control that moves the practice site's date forward. | BC, MIL | - |
+| Waitlist | en | Waiting queue | The list a student joins when a class is full. | BC, SA, MIL | - |
+
+## Rules
+
+- The Domain Model, use cases and user stories use the PO term; the Operation
+  Contract, Sequence Diagram, Design Class Diagram and ERD use the IT term.
+- One IT term per PO term and one PO term per IT term; no synonyms.
+- Rows are in ascending order of the PO term (case-insensitive, by the
+  alphabet of the PO language), so a term is found without searching.
+
+---
+
+[BC-001]: ./business-case.md
+[SA-001]: ./stakeholder-analysis.md

docs/milestones/mil-001-baseline.md

@@ -0,0 +1,75 @@
+# MIL-001 Baseline and repository set-up
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-001 |
+| CrossReference | [BC-001] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+---
+
+## Purpose
+
+Decide whether the planning baseline is complete and accepted, so that code may be planned and written. The gate checks the documents, the recorded decisions and the repository metadata.
+
+## Deliverable
+
+Accepted Business Case, Stakeholder Analysis, Project Plan and milestones with `Go` review records; ADRs for the decisions; the dictionary; the Traceability Matrix; repository description and topics on the git host.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | Business Case, Stakeholder Analysis, Project Plan and all milestones have an `RC-*` with `Go` and an `Accepted` row (the Project Plan is accepted by S01 through the plan acceptance) | All rows `Accepted` | Any row `Proposed` or `No-Go` |
+| 2 | `bash framework/scripts/check-plan.sh` reports no finding | Exit code 0 | Exit code 1 |
+| 3 | The repository shows a description and at least 5 topics | API response contains both | Either is missing |
+| 4 | ADR-0001 to ADR-0003 are `Accepted` | Three accepted ADRs | A decision is unrecorded |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| none | First gateway |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O7, success criterion 8 | [BC-001] |
+| CN-002, CN-009 | [SA-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S01 |
+| Approving reviewer | S02 (AI as stand-in, autonomous mode, not independent) |
+
+## Target Date
+
+2026-10-28 — inside the planned window 2026-10-28 to 2026-11-06 of [PP-001]; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Review and accept the baseline documents | Review BC-001, SA-001, PP-001 and MIL-001 to MIL-008 against their QC checklists, write the `RC-*` records and set the rows to `Accepted`. In autonomous mode the AI is stand-in reviewer and says so in each record. | No |  |
+| 2 | Record the planning decisions as ADRs | Write ADR-0001 (skip user stories and use cases: one actor, one linear flow), ADR-0002 (light Clean Architecture: booking rules separate from the Selenium adapter, no presentation layer) and ADR-0003 (browser runs and screenshots in a Docker container with headless Chrome, never on the host desktop). | No | ADR-0001, ADR-0002, ADR-0003 |
+| 3 | Create the domain dictionary | Create `docs/dictionary.md` with the PO and IT terms of the gym site and course (class card, booking, waitlist, retry, profile, lecture step), because the language review of the PO-language documents checks their terms against it. | No | DICT-001 |
+| 4 | Create the Traceability Matrix | Create `docs/sqa/traceability-matrix.md` and add a row for each artifact and its review, so coverage of the stakeholder concerns can be read in one place. | No | TM-001 |
+| 5 | Set repository description and topics | Set the description and topics (python, selenium, udemy, 100-days-of-code, automation, gym-booking) on the git host with the API. The token comes from the personal `.env`; it is never printed, imported, tested or committed. Confirm the target repository with S01 first if it differs from `origin`. | No | O7 |
+| 6 | Check repository visibility and the AI prompt log | Ask the host API whether the repository is private. If it is public, put `/docs/ai-prompts/` in `.gitignore`; record each session's prompts in `docs/ai-prompts/session-NNN/prompts.md` as the framework requires. | No |  |
+| 7 | Enable the plan gate commit hook | Run `bash framework/scripts/install-git-hooks.sh --enable-plan-gate` so a commit under `src/` or `tests/` needs a `Task: MIL-NNN#N` trailer. | No |  |
+
+---
+
+[BC-001]: ../business-case.md
+[PP-001]: ../project-plan.md
+[SA-001]: ../stakeholder-analysis.md

docs/milestones/mil-002-scaffold.md

@@ -0,0 +1,74 @@
+# MIL-002 Project scaffold and tooling
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-002 |
+| CrossReference | [BC-001] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+---
+
+## Purpose
+
+Decide whether the Python project skeleton, the tooling and the container image are ready, so that the lecture steps can be built on them.
+
+## Deliverable
+
+`pyproject.toml`, `src/` and `tests/` layout, `constants.py`, `.gitignore`, Doxyfile, README from the framework template with `.venv` instructions, and a Docker image with headless Chrome for browser runs.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | `pip install -e .[dev]` in a fresh `.venv` and `pytest` pass | 0 failures | An install or test failure |
+| 2 | `pyproject.toml` requires Python 3.13 or newer and lists Selenium as the only runtime dependency | Both true | Either false |
+| 3 | `doxygen Doxyfile` runs without warnings on the skeleton | 0 warnings | Any warning |
+| 4 | `bash framework/scripts/check-readme.sh` reports no finding | Exit code 0 | Exit code 1 |
+| 5 | The container image builds and starts headless Chrome | A Selenium smoke run reads a page title | Build or run fails |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| MIL-001 | Needs the accepted baseline |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O7, success criteria 5, 6, 9 | [BC-001] |
+| CN-004, CN-005, CN-008 | [SA-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S01 |
+| Approving reviewer | S02 (AI as stand-in, autonomous mode, not independent) |
+
+## Target Date
+
+2026-10-29 — inside the planned window 2026-10-28 to 2026-11-06 of [PP-001]; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Create pyproject.toml and the package layout | Create `pyproject.toml` (Python 3.13 or newer, Selenium runtime, pytest and pytest-cov in a `dev` extra, a console script) and the `src/snack_and_lift` and `tests/` folders with a first passing test. | No | O7 |
+| 2 | Add constants.py | Create `constants.py` holding the site URL, element IDs and selectors, the Tuesday and Thursday 6pm rule, the retry count and the Chrome profile folder name, so no magic value is in the logic. | No | O7 |
+| 3 | Add .gitignore, Doxyfile and .dockerignore | Add a Python `.gitignore` (including `chrome_profile/`, `.venv/` and `.env`), a `Doxyfile` for the Doxygen comments and a `.dockerignore`. | No | O7 |
+| 4 | Write the README with .venv instructions | Write `README.md` from the framework template: overview, requirements, creating and using a local `.venv`, `python -m pip install --upgrade pip`, run and test commands, and the container run. | No | O7 |
+| 5 | Build the browser container image | Create a `Dockerfile` with headless Chrome and the project, so browser runs and screenshots never use the host desktop (`framework/process/gui-testing.md`). Prove it with a smoke run that reads the site's page title. | No | O7 |
+
+---
+
+[BC-001]: ../business-case.md
+[PP-001]: ../project-plan.md
+[SA-001]: ../stakeholder-analysis.md

docs/milestones/mil-003-login.md

@@ -0,0 +1,72 @@
+# MIL-003 Lecture steps 1 and 2: profile, navigation and automated login
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-003 |
+| CrossReference | [BC-001] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+---
+
+## Purpose
+
+Decide whether the bot can start Chrome with its own persistent profile, open the gym site and log in by itself, which completes lecture steps 1 and 2.
+
+## Deliverable
+
+Browser set-up with the `detach` option and the `chrome_profile` directory, navigation to the site, a `login()` function with explicit waits, unit tests, and screenshots for lecture steps 1 and 2.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | A container run opens the site with a profile directory and, after the test account exists, logs in and finds the class schedule | The schedule element is present | Login fails or times out |
+| 2 | Unit tests for the option building and the credentials handling pass without a browser | 0 failures | A test fails |
+| 3 | `docs/images/step-1.png` and `docs/images/step-2.png` exist | Both files exist and show the site | A file is missing |
+| 4 | The code review against `qc-programming-python.md` is `Go` | `RC-*` is `Go` | `No-Go` |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| MIL-002 | Needs the scaffold and the container image |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O1, O2 | [BC-001] |
+| CN-001, CN-004 | [SA-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S01 |
+| Approving reviewer | S02 (AI as stand-in, autonomous mode, not independent) |
+
+## Target Date
+
+2026-10-30 — inside the planned window 2026-10-28 to 2026-11-06 of [PP-001]; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Start Chrome with a persistent profile | Build the Chrome options with `detach` and `--user-data-dir` pointing at a `chrome_profile` folder in the project, so the site's data survives between runs, and open the site URL. Save the screenshot `step-1.png`. | No | O1 |
+| 2 | Register the test account in the profile | Document and script the one-time registration of the student account in the opened browser (the assignment does it by hand once). The container run registers it with a documented test e-mail and a strong password and keeps it in a profile volume. | No | O1 |
+| 3 | Implement the login | Implement `login()` which clicks the login button, fills e-mail and password, submits and waits with `WebDriverWait` and `presence_of_element_located` for the class schedule. Save the screenshot `step-2.png`. | No | O2 |
+| 4 | Read credentials safely | Take `ACCOUNT_EMAIL` and `ACCOUNT_PASSWORD` from environment variables with documented defaults for the practice site only, never from the personal `.env` and never printed. | No | O2 |
+
+---
+
+[BC-001]: ../business-case.md
+[PP-001]: ../project-plan.md
+[SA-001]: ../stakeholder-analysis.md

docs/milestones/mil-004-book-class.md

@@ -0,0 +1,72 @@
+# MIL-004 Lecture steps 3 and 4: book a class and check its state
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-004 |
+| CrossReference | [BC-001] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+---
+
+## Purpose
+
+Decide whether the bot finds the next Tuesday 6pm class by reading the day and time from the page, and acts on the state of its button, which completes lecture steps 3 and 4.
+
+## Deliverable
+
+Class card parsing (day through the parent group, time from the card), the booking decision for the states "Book Class", "Booked", "Waitlisted" and "Join Waitlist", the console messages, unit tests with a fake driver, and screenshots for lecture steps 3 and 4.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | Unit tests cover the four button states and the day and time parsing | 0 failures; each state has a test | A test fails or a state is untested |
+| 2 | A container run books or recognises the Tuesday 6pm class and prints the matching message | The message names the class and the date | No message or the wrong class |
+| 3 | `docs/images/step-3.png` and `docs/images/step-4.png` exist | Both files exist and show the schedule | A file is missing |
+| 4 | The code review against `qc-programming-python.md` is `Go` | `RC-*` is `Go` | `No-Go` |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| MIL-003 | Needs the login |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O3, success criterion 1 | [BC-001] |
+| CN-001, CN-004 | [SA-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S01 |
+| Approving reviewer | S02 (AI as stand-in, autonomous mode, not independent) |
+
+## Target Date
+
+2026-10-31 — inside the planned window 2026-10-28 to 2026-11-06 of [PP-001]; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Parse class cards | Select the cards with an id-prefix CSS selector and walk to the day group with `ancestor::div`; return plain values (day, time, name, state) so the rules can be tested without a browser. | No | O3 |
+| 2 | Book the next Tuesday 6pm class | Find the first Tuesday 6pm card and click "Book Class" or "Join Waitlist"; print `✓ Booked: Spin Class on Tue, Aug 12`. Save the screenshot `step-3.png`. | No | O3 |
+| 3 | Check the state before clicking | Decide from the button text: "Booked" and "Waitlisted" only report, "Join Waitlist" joins the waitlist, "Book Class" books. Print the three assignment messages. Save the screenshot `step-4.png`. | No | O3 |
+| 4 | Test the decision logic | Write unit tests for parsing and the decision with fake cards, including a day that is not first in the list. | No | O3 |
+
+---
+
+[BC-001]: ../business-case.md
+[PP-001]: ../project-plan.md
+[SA-001]: ../stakeholder-analysis.md

docs/milestones/mil-005-counters-and-both-days.md

@@ -0,0 +1,72 @@
+# MIL-005 Lecture steps 5 and 6: counters and every Tuesday and Thursday class
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-005 |
+| CrossReference | [BC-001] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+---
+
+## Purpose
+
+Decide whether the bot counts what it does, prints the summary and the detailed list, and handles every Tuesday and Thursday 6pm class, which completes lecture steps 5 and 6.
+
+## Deliverable
+
+Counters and a summary, a detailed class list, booking of all Tuesday and Thursday 6pm classes, unit tests, and screenshots for lecture steps 5 and 6.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | Unit tests for the counters, summary text and detailed list pass | 0 failures | A test fails |
+| 2 | A container run processes every Tuesday and Thursday 6pm card in the window once | Total equals the cards found | A card is skipped or repeated |
+| 3 | `docs/images/step-5.png` and `docs/images/step-6.png` exist | Both files exist and show the console summary or schedule | A file is missing |
+| 4 | The code review against `qc-programming-python.md` is `Go` | `RC-*` is `Go` | `No-Go` |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| MIL-004 | Needs the booking decision |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O4, success criteria 1, 2 | [BC-001] |
+| CN-001 | [SA-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S01 |
+| Approving reviewer | S02 (AI as stand-in, autonomous mode, not independent) |
+
+## Target Date
+
+2026-11-01 — inside the planned window 2026-10-28 to 2026-11-06 of [PP-001]; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Add counters and the summary | Count new bookings, waitlists joined and classes already booked or waitlisted; print `--- BOOKING SUMMARY ---` with the total of Tuesday 6pm classes. Save the screenshot `step-5.png`. | No | O4 |
+| 2 | Handle Tuesday and Thursday | Process every Tuesday and Thursday 6pm card, not only the first; keep a list of what happened for each card, with `Tomorrow` and date labels as the site shows them. | No | O4 |
+| 3 | Print the detailed class list | Print `--- DETAILED CLASS LIST ---` with one line per class: `[New Booking]`, `[New Waitlist]`, `[Already Booked]` or `[Already Waitlisted]`. Save the screenshot `step-6.png`. | No | O4 |
+| 4 | Test counting and reporting | Unit tests for the counters, the summary and the detail lines, including the case of no matching class. | No | O4 |
+
+---
+
+[BC-001]: ../business-case.md
+[PP-001]: ../project-plan.md
+[SA-001]: ../stakeholder-analysis.md

docs/milestones/mil-006-verify-and-time-travel.md

@@ -0,0 +1,73 @@
+# MIL-006 Lecture steps 7 and 8: verify bookings and time travel QA
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-006 |
+| CrossReference | [BC-001] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+---
+
+## Purpose
+
+Decide whether the bot verifies its work on the "My Bookings" page and behaves correctly on other dates of the site, which completes lecture steps 7 and 8.
+
+## Deliverable
+
+Navigation to "My Bookings", verification with `NoSuchElementException`, a comparison of expected and found, handling of any start date, unit tests, and screenshots for lecture steps 7 and 8.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | Unit tests for the comparison and the mismatch message pass | 0 failures | A test fails |
+| 2 | A container run prints the verification result and "SUCCESS" when all bookings are found | Expected equals found | A mismatch without cause |
+| 3 | A container run after the admin advances 3 days books new classes in the window | New Tuesday and Thursday classes are processed | The bot assumes the first day is Monday or hardcodes a date |
+| 4 | `docs/images/step-7.png` and `docs/images/step-8.png` exist | Both files exist | A file is missing |
+| 5 | The code review against `qc-programming-python.md` is `Go` | `RC-*` is `Go` | `No-Go` |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| MIL-005 | Needs the counters and the full class list |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O5, success criteria 1, 3 | [BC-001] |
+| CN-001, CN-003 | [SA-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S01 |
+| Approving reviewer | S02 (AI as stand-in, autonomous mode, not independent) |
+
+## Target Date
+
+2026-11-02 — inside the planned window 2026-10-28 to 2026-11-06 of [PP-001]; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Read the My Bookings page | Navigate to "My Bookings", collect the booked and waitlisted entries, and raise `NoSuchElementException` when the page has none where bookings are expected. Save the screenshot `step-7.png`. | No | O5 |
+| 2 | Compare expected with found | Print `--- VERIFYING ON MY BOOKINGS PAGE ---`, the expected and found counts and `SUCCESS` or the `MISMATCH` with the difference, in singular or plural. | No | O5 |
+| 3 | Make the bot date independent | Remove any assumption about the first visible day, a hardcoded date or the list position; test with fake cards for several start weekdays. | No | O5 |
+| 4 | Rehearse time travel in a container run | Reset the data through the admin account, advance 3 days, run the bot and save the screenshot `step-8.png`. The admin credentials are the practice site's published ones. | No | O5 |
+
+---
+
+[BC-001]: ../business-case.md
+[PP-001]: ../project-plan.md
+[SA-001]: ../stakeholder-analysis.md

docs/milestones/mil-007-resilience.md

@@ -0,0 +1,74 @@
+# MIL-007 Lecture step 9: resilience against network failures
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-007 |
+| CrossReference | [BC-001] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+---
+
+## Purpose
+
+Decide whether the bot completes a full run when the site fails half of its requests, which completes lecture step 9.
+
+## Deliverable
+
+A `retry(func, retries=7, description=None)` wrapper, `login()`, `book_class()` and `get_my_bookings()` made resilient with it, unit tests with a failing fake, and the screenshot for lecture step 9.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | Unit tests show that `retry` returns on success, repeats on failure and raises after the last attempt | 0 failures | A test fails |
+| 2 | Booking is only counted when the page confirms it (the button changes state) | Confirmed in tests and in a run | A click is counted without confirmation |
+| 3 | Container runs with 50% simulated failures reach the verification result in 3 of 3 attempts | 3 of 3 | Fewer than 3 |
+| 4 | `docs/images/step-9.png` exists | The file exists | The file is missing |
+| 5 | The code review against `qc-programming-python.md` is `Go` | `RC-*` is `Go` | `No-Go` |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| MIL-006 | Needs login, booking and verification to wrap |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O6, success criteria 4, 5 | [BC-001] |
+| CN-003 | [SA-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S01 |
+| Approving reviewer | S02 (AI as stand-in, autonomous mode, not independent) |
+
+## Target Date
+
+2026-11-04 — inside the planned window 2026-10-28 to 2026-11-06 of [PP-001]; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Write the retry wrapper | Implement `retry(func, retries=7, description=None)` that calls the function, logs each failed attempt with the description and re-raises after the last one. Unit-test it with a fake that fails n times. | No | O6 |
+| 2 | Wrap the login in retry | Move all login steps into `login()` and call it through `retry`, so a failed page load is repeated. | No | O6 |
+| 3 | Make booking confirm its result | Put the booking steps in `book_class()` and treat the click as done only when the button reads "Booked" or "Waitlisted"; call it through `retry`. | No | O6 |
+| 4 | Make the bookings read resilient | Put the My Bookings retrieval in `get_my_bookings()` and call it through `retry`. | No | O6 |
+| 5 | Run the chaos test in a container | Clear the bookings in the admin panel, enable the network simulation at 50%, run the bot three times and keep the output. Save the screenshot `step-9.png`. | No | O6 |
+
+---
+
+[BC-001]: ../business-case.md
+[PP-001]: ../project-plan.md
+[SA-001]: ../stakeholder-analysis.md

docs/milestones/mil-008-documentation.md

@@ -0,0 +1,74 @@
+# MIL-008 Documentation, wiki and release
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-008 |
+| CrossReference | [BC-001] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version | pending |
+
+---
+
+## Purpose
+
+Decide whether the repository is ready for S02 and S03: README, Doxygen output, wiki in three languages with screenshots, and final checks.
+
+## Deliverable
+
+Final README with a screenshot per lecture step, Doxygen configuration that builds, wiki pages in English, Danish and Bahasa Malaysia that explain what each lecture step gained, and the final summary.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | README has the 9 screenshots, setup, run and test instructions | All present; `check-readme.sh` exits 0 | Anything missing |
+| 2 | The wiki has the same page set in `en`, `da` and `ms`, each step page with its screenshot | Three languages, same pages | A page or a language is missing |
+| 3 | `bash framework/scripts/check-languages.sh` and `check-plan.sh` report no finding | Exit code 0 | Exit code 1 |
+| 4 | Tests pass with at least 80% coverage of the logic modules and `doxygen Doxyfile` has no warnings | Both true | Either false |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| MIL-007 | Needs all nine lecture steps and screenshots |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O7, O8, success criteria 6, 7 | [BC-001] |
+| CN-005, CN-006, CN-007 | [SA-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S01 |
+| Approving reviewer | S02 (AI as stand-in, autonomous mode, not independent) |
+
+## Target Date
+
+2026-11-06 — inside the planned window 2026-10-28 to 2026-11-06 of [PP-001]; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Finish the README | Add the nine screenshots, the project layout, the Doxygen instructions and the links to the wiki to `README.md`; run `check-readme.sh`. | No | O7 |
+| 2 | Write the English wiki | Write `docs/wiki/` pages in English: Home, Getting Started, one page per lecture step (what the step gained, with its screenshot), Troubleshooting and the sidebar and footer. | No | O8 |
+| 3 | Translate the wiki to Danish | Write the same page set in Danish as `<Page>-da.md`, following the English text page by page. | No | O8 |
+| 4 | Translate the wiki to Bahasa Malaysia | Write the same page set in Bahasa Malaysia as `<Page>-ms.md`, following the English text page by page. | No | O8 |
+| 5 | Install the wiki publishing workflow | Copy `templates/ci/publish-wiki.yml` and `templates/ci/sync-milestones.yml` to `.gitea/workflows/` so the wiki and milestones reach the git host after the merge. | No | O8 |
+| 6 | Final checks and summary | Run every framework check script, the full test suite and Doxygen, verify the issues are closed, and prepare the final summary for S01. | No |  |
+
+---
+
+[BC-001]: ../business-case.md
+[PP-001]: ../project-plan.md
+[SA-001]: ../stakeholder-analysis.md

docs/project-plan.md

@@ -0,0 +1,111 @@
+# Project Plan: Snack and Lift Booking Bot
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | PP-001 |
+| CrossReference | [BC-001], [SA-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version: eight gateways | pending |
+
+---
+
+## Purpose
+
+This plan schedules eight gateways (`MIL-001` to `MIL-008`) that take the Snack and Lift booking bot from an accepted baseline to a documented, tested and published repository. The Business Case sets no deadline, so the window 2026-10-28 to 2026-11-06 is a planning assumption of this plan. Each gateway ends in a decision and a deliverable and is delivered by one pull request on its own branch.
+
+## Planning Assumptions
+
+- Week 1 starts 2026-10-28; the plan ends by 2026-11-06 (a planning assumption, see Open Issues).
+- Phase length: one to two days per gateway. Gateways 003 to 007 follow the Udemy lecture steps 1 to 9.
+- One branch and one pull request per gateway, each closing the issues of its tasks.
+- The user stories and use case steps of the journey are skipped for this project (ADR-0001), so no gateway lists stories.
+- Autonomous mode: S01 accepts this plan in chat; the AI acts as stand-in reviewer (S02) and records it in each `RC-*`.
+
+## Gateway Schedule
+
+| Gateway | Document | Window | Decision date | Owner | Stories | Main deliverable | Milestone |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| Baseline and repository set-up | [MIL-001] | 2026-10-28 | 2026-10-28 | S01 | none (documents) | Accepted baseline, ADRs, repository description and topics | |
+| Project scaffold and tooling | [MIL-002] | 2026-10-28 to 2026-10-29 | 2026-10-29 | S01 | none (technical tasks) | `pyproject.toml`, layout, `.gitignore`, Doxyfile, README, Docker image | |
+| Lecture steps 1 and 2 | [MIL-003] | 2026-10-29 to 2026-10-30 | 2026-10-30 | S01 | none (technical tasks) | Chrome profile, navigation, `login()`, screenshots 1 and 2 | |
+| Lecture steps 3 and 4 | [MIL-004] | 2026-10-30 to 2026-10-31 | 2026-10-31 | S01 | none (technical tasks) | Card parsing, booking, state checks, screenshots 3 and 4 | |
+| Lecture steps 5 and 6 | [MIL-005] | 2026-10-31 to 2026-11-01 | 2026-11-01 | S01 | none (technical tasks) | Counters, summary, Tuesday and Thursday list, screenshots 5 and 6 | |
+| Lecture steps 7 and 8 | [MIL-006] | 2026-11-01 to 2026-11-02 | 2026-11-02 | S01 | none (technical tasks) | My Bookings verification, time travel, screenshots 7 and 8 | |
+| Lecture step 9 | [MIL-007] | 2026-11-02 to 2026-11-04 | 2026-11-04 | S01 | none (technical tasks) | `retry`, resilient `login`, `book_class`, `get_my_bookings`, screenshot 9 | |
+| Documentation, wiki and release | [MIL-008] | 2026-11-04 to 2026-11-06 | 2026-11-06 | S01 | none (documentation) | README, Doxygen, wiki in en, da and ms, final checks | |
+
+```plantuml
+@startgantt
+Project starts 2026-10-28
+[Baseline] starts 2026-10-28 and ends 2026-10-28
+[Scaffold] starts 2026-10-28 and ends 2026-10-29
+[Steps 1 and 2] starts 2026-10-29 and ends 2026-10-30
+[Steps 3 and 4] starts 2026-10-30 and ends 2026-10-31
+[Steps 5 and 6] starts 2026-10-31 and ends 2026-11-01
+[Steps 7 and 8] starts 2026-11-01 and ends 2026-11-02
+[Step 9] starts 2026-11-02 and ends 2026-11-04
+[Documentation] starts 2026-11-04 and ends 2026-11-06
+[Baseline Go/No-Go] happens 2026-10-28
+[Scaffold Go/No-Go] happens 2026-10-29
+[Steps 1 and 2 Go/No-Go] happens 2026-10-30
+[Steps 3 and 4 Go/No-Go] happens 2026-10-31
+[Steps 5 and 6 Go/No-Go] happens 2026-11-01
+[Steps 7 and 8 Go/No-Go] happens 2026-11-02
+[Step 9 Go/No-Go] happens 2026-11-04
+[Release Go/No-Go] happens 2026-11-06
+@endgantt
+```
+
+## Scope Coverage
+
+| Business Case scope item | Gateway |
+| --- | --- |
+| Selenium bot for the practice site, with the assignment's function names | MIL-003, MIL-004, MIL-006, MIL-007 |
+| Lecture steps 1 to 9 | MIL-003 (1, 2), MIL-004 (3, 4), MIL-005 (5, 6), MIL-006 (7, 8), MIL-007 (9) |
+| Python project files: `src/`, `tests/`, `docs/`, `pyproject.toml`, `constants.py`, `.gitignore`, Doxyfile, README | MIL-002, MIL-008 |
+| Unit tests with `pytest` | MIL-002 to MIL-007 |
+| One screenshot per lecture step in README and wiki | MIL-003 to MIL-007 (capture), MIL-008 (use) |
+| Wiki in en, da and ms | MIL-008 |
+| Repository description and topics | MIL-001 |
+
+## Dependencies
+
+```
+MIL-001 → MIL-002 → MIL-003 → MIL-004 → MIL-005 → MIL-006 → MIL-007 → MIL-008
+```
+
+A No-Go on a gateway stops all later gateways until it is fixed and re-reviewed. The end date then moves by the days spent on the rework; S01 decides a move of the end date.
+
+## Plan Risks
+
+| Risk | Impact | Mitigation |
+| --- | --- | --- |
+| The practice site changes its page structure (Business Case risk: site changes) | Steps 3 to 9 need rework | Selectors only in `constants.py`; the first task of MIL-003 records the page as seen |
+| The container starts with an empty site database (state lives in the browser profile) | Login and booking cannot be shown | MIL-003 registers a documented test account in a profile volume; browser runs reset data through the admin page |
+| Stand-in review misses a defect | Defect reaches `main` | `RC-*` marks the review as not independent; S01 reviews the final summary |
+| Translations take longer than planned | MIL-008 slips | Write English first; da and ms follow page by page; no extra pages |
+
+## Open Issues
+
+- Target repository: the user names `https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code`, but `origin` is `Tirsvad-Udemy-100-days-of-code/049-snack-and-lift`. The plan uses `origin` (description and topics are set there) until S01 states otherwise in chat.
+- The Business Case sets no deadline; the window 2026-10-28 to 2026-11-06 is this plan's own assumption.
+- No QC checklist exists for accepting the Project Plan beyond `QC-PP-001`; S01's acceptance of the plan in chat accepts the row.
+
+---
+
+[BC-001]: ./business-case.md
+[SA-001]: ./stakeholder-analysis.md
+[MIL-001]: ./milestones/mil-001-baseline.md
+[MIL-002]: ./milestones/mil-002-scaffold.md
+[MIL-003]: ./milestones/mil-003-login.md
+[MIL-004]: ./milestones/mil-004-book-class.md
+[MIL-005]: ./milestones/mil-005-counters-and-both-days.md
+[MIL-006]: ./milestones/mil-006-verify-and-time-travel.md
+[MIL-007]: ./milestones/mil-007-resilience.md
+[MIL-008]: ./milestones/mil-008-documentation.md

docs/sqa/reviews/rc-001-business-case.md

@@ -0,0 +1,66 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-001 |
+| CrossReference | [BC-001], [QC-BC-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [BC-001]
+- Checklist used: [QC-BC-001] (`QC-BC-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## 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 states why: unpaid learning project, no revenue. |
+| 2 | Risks are identified with documented impact and mitigation | Pass | Risks table: six risks, each with impact and mitigation. |
+| 3 | Success criteria are measurable, stating explicit targets rather than vague aspirations | Pass | Success Criteria: nine rows with numeric targets and a measure. |
+| 4 | Scope explicitly separates In Scope vs Out of Scope | Pass | Scope has In Scope and Out of Scope subsections. |
+| 5 | Stakeholders are cross-referenced to Stakeholder Analysis IDs rather than re-described inline | Pass | Stakeholders table cites S01, S02 and S03 from SA-001. |
+| 6 | Methodology and quality-standard foundation are stated explicitly (e.g. ISO/IEC 25010, Larman) | Pass | Methodological and Standards Foundation names the framework, ISO/IEC 25010 and Clean Architecture. |
+| 7 | Assumptions and constraints are explicit and clearly distinguished from one another | Pass | Assumptions and Constraints are separate lists. |
+| 8 | Document supports executive decision-making with a clear, unambiguous recommendation | Pass | Recommendation: Proceed, with one rationale 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry 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 (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, class card, lecture step, waitlist, retry, profile (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — BC-001 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[BC-001]: ../../business-case.md
+[QC-BC-001]: ../../../framework/qc/artifacts/qc-business-case.md

docs/sqa/reviews/rc-002-stakeholder-analysis.md

@@ -0,0 +1,67 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-002 |
+| CrossReference | [SA-001], [QC-SA-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [SA-001]
+- Checklist used: [QC-SA-001] (`QC-SA-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Power/Interest grid is filled for every stakeholder, with no gaps or unclassified entries | Pass | Summary table classifies S01, S02 and S03 with power, interest and quadrant. |
+| 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 used by the other documents. |
+| 3 | Roles and organizational context are defined with explicit Power and Interest levels, not just narrative description | Pass | Each row states role, organization, Power Level and Interest Level. |
+| 4 | Communication needs (channel, frequency, deliverable type) are mapped to project phases or milestones | Pass | Communication Requirements table CM-001 to CM-003 maps channels to milestones. |
+| 5 | Conflicting stakeholder interests are identified with documented mitigation or resolution strategies | Pass | Conflicting Interests table has two conflicts, each with a mitigation. |
+| 6 | Stakeholder concerns are explicitly traced to Business Case objectives | Pass | Traceability Analysis maps every concern to Business Case objectives O1 to O8. |
+| 7 | Primary concerns are expressed in both business language and a recognized quality-attribute mapping (e.g. FURPS+) | Pass | Concerns CN-001 to CN-009 are in business language with a FURPS+ attribute. |
+| 8 | Document is understandable and navigable by non-technical stakeholders reviewing their own entry | Pass | Short tables with plain wording; each stakeholder's entry is one row. |
+| 9 | Every concern has a stable ID (`CN-NNN`) in the concern register, with the stakeholder who raised it; IDs are never renumbered or reused | Pass | Concern register has stable IDs CN-001 to CN-009 with the stakeholder who raised each. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry 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 (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, lecture step (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — SA-001 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[SA-001]: ../../stakeholder-analysis.md
+[QC-SA-001]: ../../../framework/qc/artifacts/qc-stakeholder-analysis.md

docs/sqa/reviews/rc-003-project-plan.md

@@ -0,0 +1,73 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-003 |
+| CrossReference | [PP-001], [QC-PP-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [PP-001]
+- Checklist used: [QC-PP-001] (`QC-PP-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | The plan states its start date, end date and the constraint it must fit | Pass | Purpose and Planning Assumptions state the window 2026-10-28 to 2026-11-06 and that the Business Case sets no deadline. |
+| 2 | Every milestone or gateway is listed once with its document, decision date and owner | Pass | Gateway Schedule lists MIL-001 to MIL-008 once each with document link, decision date and owner S01. |
+| 3 | Every decision date lies inside the plan's window and is consistent with the dates in the linked `MIL-*` document | Pass | Decision dates equal the Target Date of each MIL document and lie inside the window. |
+| 4 | Every in-scope item of the Business Case is delivered at a named gateway (scope coverage) | Pass | Scope Coverage maps every In Scope item to a gateway. |
+| 5 | Dependencies between gateways are stated, acyclic and consistent with the schedule order | Pass | Dependencies show the chain MIL-001 to MIL-008; the schedule order agrees. |
+| 6 | The plan states what happens to later gateways and to the end date when a gateway is No-Go | Pass | Dependencies state that a No-Go stops later gateways and that S01 decides a move of the end date. |
+| 7 | Owners, reviewers and escalation roles use Stakeholder Analysis IDs and match the governance RACI | Pass | Owner S01 and reviewer S02 come from SA-001; no governance document exists in this project. |
+| 8 | Planning assumptions are listed with their source, and a changed baseline is recorded with its reason | Pass | Planning Assumptions list their source; no baseline was changed. |
+| 9 | Plan risks are listed with impact and a mitigation, and trace to Business Case risks where they come from there | Pass | Plan Risks has four risks with impact and mitigation, linked to the Business Case risks. |
+| 10 | Open issues are listed, and none contradicts a statement elsewhere in the plan | Pass | Open Issues lists the repository question, the missing deadline and the acceptance note; none contradicts the plan. |
+| 11 | Each gateway's main deliverable is stated and matches the deliverable of its `MIL-*` document | Pass | Main deliverables in the schedule match the Deliverable section of each MIL document. |
+| 12 | Gateways that deliver user stories name them, and those that do not say why | Pass | Planning Assumptions say stories are skipped (ADR-0001); the Stories column says why for each gateway. |
+| 13 | The schedule view (table, Gantt) and the dependency view agree with each other | Pass | The Gantt bars and the table dates are the same; the chain matches the dependency list. |
+| 14 | Each gateway is linked to its issue-tracker milestone, or marked as not yet synced | N-A | No Milestones exist on the git host yet; the Milestone column is blank on purpose until the publish workflow runs. |
+| 15 | The plan is a singleton: one Project Plan per project, changes recorded in Version History | Pass | PP-001 is the only Project Plan; the change is in Version History. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry domain list. |
+| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of PP-001 are English (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, lecture step (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — PP-001 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary. The plan is accepted by S01 through the chat acceptance of the plan.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[PP-001]: ../../project-plan.md
+[QC-PP-001]: ../../../framework/qc/artifacts/qc-project-plan.md

docs/sqa/reviews/rc-004-dictionary.md

@@ -0,0 +1,66 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-004 |
+| CrossReference | [DICT-001], [QC-DICT-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [DICT-001]
+- Checklist used: [QC-DICT-001] (`QC-DICT-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Every row has a PO term, its language, an IT term and a definition | Pass | Every row has a PO term, language, IT term, definition and where it is used. |
+| 2 | Each PO term maps to exactly one IT term and the reverse (no synonyms) | Pass | Eight PO terms map to eight different IT terms; no synonyms. |
+| 3 | Every Domain Model concept has a row, and the Domain Model uses its PO term | N-A | No Domain Model exists (ADR-0001). |
+| 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, DCD or ERD exists (ADR-0001). |
+| 5 | Definitions are written in the PO language and are one sentence | Pass | Each definition is one English sentence. |
+| 6 | "Used as PO term in" and "Used as IT term in" name artifact types that exist in the project | Pass | Used-in columns name BC, SA and MIL, which exist. |
+| 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 | Dictionary Language = en and Domain = it match the registry. |
+| 8 | The dictionary rows are in ascending order of the PO term (case-insensitive, by the alphabet of the PO language) | Pass | Rows run Booking, Bot, Class card, Lecture step, Profile, Retry, Time travel, Waitlist: ascending. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry 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 (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: all eight terms of the dictionary itself (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — DICT-001 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[DICT-001]: ../../dictionary.md
+[QC-DICT-001]: ../../../framework/qc/artifacts/qc-dictionary.md

docs/sqa/reviews/rc-005-adr-0001.md

@@ -0,0 +1,54 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-005 |
+| CrossReference | [ADR-0001], [QC-ADR-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [ADR-0001]
+- Checklist used: [QC-ADR-001] (`QC-ADR-001`)
+- Scope: full review
+- Language and domain: n/a
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | The ID (`ADR-NNNN`, 4-digit) matches the filename number and is unique and sequential | Pass | ID ADR-0001 matches the file name number and is sequential. |
+| 2 | Context states the problem, the forces (cost, risk, constraints) and the options evaluated | Pass | Context states the problem and the options evaluated. |
+| 3 | At least two options were considered, or the absence of alternatives is justified | Pass | Two options; option 2 chosen; negative consequence notes the missing DCD trace. |
+| 4 | Decision is stated in one or two unhedged sentences and matches one of the evaluated options | Pass | Decision is stated in unhedged sentences and equals an evaluated option. |
+| 5 | Consequences list both Positive and Negative outcomes | Pass | Consequences has **Positive:** and **Negative:** lists. |
+| 6 | Quality-attribute impacts (performance, security, portability, etc.) are named where the decision affects them | N-A | No security or performance impact is claimed; flexibility is covered in the consequences. |
+| 7 | Affected Artifacts are listed as links, and each is also in CrossReference | Pass | Affected Artifacts are links and every one is in CrossReference. |
+| 8 | Status changes are recorded as new Version History rows with a Change summary and Commit link; retained rows are never rewritten | Pass | Version History has one row; no retained row is rewritten. |
+| 9 | A superseded or deprecated ADR names its successor, and the successor links back | N-A | The ADR is not superseded. |
+| 10 | Written in business or technical language of the domain, with no unexplained abbreviations | Pass | Plain technical English; abbreviations are the framework's own. |
+| 11 | Status is one of `Proposed`, `Accepted`, `Rejected`, `Deprecated` or `Superseded by ADR-NNNN`, and every Version History row uses only these | Pass | Status is `Proposed` then `Accepted`, which are allowed. |
+
+## Overall Verdict
+
+Go — ADR-0001 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[ADR-0001]: ../../adr/adr-0001-skip-stories-use-cases.md
+[QC-ADR-001]: ../../../framework/qc/artifacts/qc-adr.md

docs/sqa/reviews/rc-006-adr-0002.md

@@ -0,0 +1,54 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-006 |
+| CrossReference | [ADR-0002], [QC-ADR-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [ADR-0002]
+- Checklist used: [QC-ADR-001] (`QC-ADR-001`)
+- Scope: full review
+- Language and domain: n/a
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | The ID (`ADR-NNNN`, 4-digit) matches the filename number and is unique and sequential | Pass | ID ADR-0002 matches the file name number and is sequential. |
+| 2 | Context states the problem, the forces (cost, risk, constraints) and the options evaluated | Pass | Context states the problem and the options evaluated. |
+| 3 | At least two options were considered, or the absence of alternatives is justified | Pass | Three options; option 2 chosen with the public function names. |
+| 4 | Decision is stated in one or two unhedged sentences and matches one of the evaluated options | Pass | Decision is stated in unhedged sentences and equals an evaluated option. |
+| 5 | Consequences list both Positive and Negative outcomes | Pass | Consequences has **Positive:** and **Negative:** lists. |
+| 6 | Quality-attribute impacts (performance, security, portability, etc.) are named where the decision affects them | N-A | No security or performance impact is claimed; flexibility is covered in the consequences. |
+| 7 | Affected Artifacts are listed as links, and each is also in CrossReference | Pass | Affected Artifacts are links and every one is in CrossReference. |
+| 8 | Status changes are recorded as new Version History rows with a Change summary and Commit link; retained rows are never rewritten | Pass | Version History has one row; no retained row is rewritten. |
+| 9 | A superseded or deprecated ADR names its successor, and the successor links back | N-A | The ADR is not superseded. |
+| 10 | Written in business or technical language of the domain, with no unexplained abbreviations | Pass | Plain technical English; abbreviations are the framework's own. |
+| 11 | Status is one of `Proposed`, `Accepted`, `Rejected`, `Deprecated` or `Superseded by ADR-NNNN`, and every Version History row uses only these | Pass | Status is `Proposed` then `Accepted`, which are allowed. |
+
+## Overall Verdict
+
+Go — ADR-0002 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[ADR-0002]: ../../adr/adr-0002-light-clean-architecture.md
+[QC-ADR-001]: ../../../framework/qc/artifacts/qc-adr.md

docs/sqa/reviews/rc-007-adr-0003.md

@@ -0,0 +1,54 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-007 |
+| CrossReference | [ADR-0003], [QC-ADR-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [ADR-0003]
+- Checklist used: [QC-ADR-001] (`QC-ADR-001`)
+- Scope: full review
+- Language and domain: n/a
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | The ID (`ADR-NNNN`, 4-digit) matches the filename number and is unique and sequential | Pass | ID ADR-0003 matches the file name number and is sequential. |
+| 2 | Context states the problem, the forces (cost, risk, constraints) and the options evaluated | Pass | Context states the problem and the options evaluated. |
+| 3 | At least two options were considered, or the absence of alternatives is justified | Pass | Three options; option 2 chosen; profile volume noted. |
+| 4 | Decision is stated in one or two unhedged sentences and matches one of the evaluated options | Pass | Decision is stated in unhedged sentences and equals an evaluated option. |
+| 5 | Consequences list both Positive and Negative outcomes | Pass | Consequences has **Positive:** and **Negative:** lists. |
+| 6 | Quality-attribute impacts (performance, security, portability, etc.) are named where the decision affects them | N-A | No security or performance impact is claimed; flexibility is covered in the consequences. |
+| 7 | Affected Artifacts are listed as links, and each is also in CrossReference | Pass | Affected Artifacts are links and every one is in CrossReference. |
+| 8 | Status changes are recorded as new Version History rows with a Change summary and Commit link; retained rows are never rewritten | Pass | Version History has one row; no retained row is rewritten. |
+| 9 | A superseded or deprecated ADR names its successor, and the successor links back | N-A | The ADR is not superseded. |
+| 10 | Written in business or technical language of the domain, with no unexplained abbreviations | Pass | Plain technical English; abbreviations are the framework's own. |
+| 11 | Status is one of `Proposed`, `Accepted`, `Rejected`, `Deprecated` or `Superseded by ADR-NNNN`, and every Version History row uses only these | Pass | Status is `Proposed` then `Accepted`, which are allowed. |
+
+## Overall Verdict
+
+Go — ADR-0003 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[ADR-0003]: ../../adr/adr-0003-docker-headless-browser.md
+[QC-ADR-001]: ../../../framework/qc/artifacts/qc-adr.md

docs/sqa/reviews/rc-008-mil-001-baseline.md

@@ -0,0 +1,64 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-008 |
+| CrossReference | [MIL-001], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-001]
+- Checklist used: [QC-MIL-001] (`QC-MIL-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete files, runs or documents. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go/No-Go table has objectively checkable criteria with Go and No-Go columns. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the preceding milestone and the reason. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites O7 of BC-001 and the concerns of SA-001. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership names S01 as owner and S02 (AI as stand-in) as approving reviewer. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date lies inside the window 2026-10-28 to 2026-11-06 of PP-001. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry 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 (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, lecture step (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — MIL-001 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary. Tasks: tasks 1 to 7 cover reviews, ADRs, dictionary, matrix, metadata, prompt log and hook.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[MIL-001]: ../../milestones/mil-001-baseline.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md

docs/sqa/reviews/rc-009-mil-002-scaffold.md

@@ -0,0 +1,64 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-009 |
+| CrossReference | [MIL-002], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-002]
+- Checklist used: [QC-MIL-001] (`QC-MIL-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete files, runs or documents. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go/No-Go table has objectively checkable criteria with Go and No-Go columns. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the preceding milestone and the reason. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites O7 of BC-001 and the concerns of SA-001. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership names S01 as owner and S02 (AI as stand-in) as approving reviewer. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date lies inside the window 2026-10-28 to 2026-11-06 of PP-001. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry 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 (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, lecture step (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — MIL-002 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary. Tasks: tasks 1 to 5 cover the package, constants, ignore files, README and image.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[MIL-002]: ../../milestones/mil-002-scaffold.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md

docs/sqa/reviews/rc-010-mil-003-login.md

@@ -0,0 +1,64 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-010 |
+| CrossReference | [MIL-003], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-003]
+- Checklist used: [QC-MIL-001] (`QC-MIL-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete files, runs or documents. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go/No-Go table has objectively checkable criteria with Go and No-Go columns. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the preceding milestone and the reason. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites O1, O2 of BC-001 and the concerns of SA-001. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership names S01 as owner and S02 (AI as stand-in) as approving reviewer. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date lies inside the window 2026-10-28 to 2026-11-06 of PP-001. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry 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 (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, lecture step (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — MIL-003 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary. Tasks: tasks 1 to 4 cover profile, account, login and credentials.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[MIL-003]: ../../milestones/mil-003-login.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md

docs/sqa/reviews/rc-011-mil-004-book-class.md

@@ -0,0 +1,64 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-011 |
+| CrossReference | [MIL-004], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-004]
+- Checklist used: [QC-MIL-001] (`QC-MIL-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete files, runs or documents. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go/No-Go table has objectively checkable criteria with Go and No-Go columns. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the preceding milestone and the reason. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites O3 of BC-001 and the concerns of SA-001. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership names S01 as owner and S02 (AI as stand-in) as approving reviewer. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date lies inside the window 2026-10-28 to 2026-11-06 of PP-001. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry 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 (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, lecture step (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — MIL-004 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary. Tasks: tasks 1 to 4 cover parsing, booking, state check and tests.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[MIL-004]: ../../milestones/mil-004-book-class.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md

docs/sqa/reviews/rc-012-mil-005-counters-and-both-days.md

@@ -0,0 +1,64 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-012 |
+| CrossReference | [MIL-005], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-005]
+- Checklist used: [QC-MIL-001] (`QC-MIL-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete files, runs or documents. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go/No-Go table has objectively checkable criteria with Go and No-Go columns. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the preceding milestone and the reason. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites O4 of BC-001 and the concerns of SA-001. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership names S01 as owner and S02 (AI as stand-in) as approving reviewer. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date lies inside the window 2026-10-28 to 2026-11-06 of PP-001. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry 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 (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, lecture step (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — MIL-005 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary. Tasks: tasks 1 to 4 cover counters, both days, the detailed list and tests.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[MIL-005]: ../../milestones/mil-005-counters-and-both-days.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md

docs/sqa/reviews/rc-013-mil-006-verify-and-time-travel.md

@@ -0,0 +1,64 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-013 |
+| CrossReference | [MIL-006], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-006]
+- Checklist used: [QC-MIL-001] (`QC-MIL-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete files, runs or documents. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go/No-Go table has objectively checkable criteria with Go and No-Go columns. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the preceding milestone and the reason. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites O5 of BC-001 and the concerns of SA-001. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership names S01 as owner and S02 (AI as stand-in) as approving reviewer. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date lies inside the window 2026-10-28 to 2026-11-06 of PP-001. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry domain list. |
+| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of MIL-006 are English (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, lecture step (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — MIL-006 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary. Tasks: tasks 1 to 4 cover My Bookings, comparison, date independence and time travel.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[MIL-006]: ../../milestones/mil-006-verify-and-time-travel.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md

docs/sqa/reviews/rc-014-mil-007-resilience.md

@@ -0,0 +1,64 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-014 |
+| CrossReference | [MIL-007], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-007]
+- Checklist used: [QC-MIL-001] (`QC-MIL-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete files, runs or documents. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go/No-Go table has objectively checkable criteria with Go and No-Go columns. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the preceding milestone and the reason. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites O6 of BC-001 and the concerns of SA-001. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership names S01 as owner and S02 (AI as stand-in) as approving reviewer. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date lies inside the window 2026-10-28 to 2026-11-06 of PP-001. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry domain list. |
+| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of MIL-007 are English (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, lecture step (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — MIL-007 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary. Tasks: tasks 1 to 5 cover retry, login, booking, bookings read and the chaos run.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[MIL-007]: ../../milestones/mil-007-resilience.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md

docs/sqa/reviews/rc-015-mil-008-documentation.md

@@ -0,0 +1,64 @@
+# SQA Review Record
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-015 |
+| CrossReference | [MIL-008], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Review record, full review | pending |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-008]
+- Checklist used: [QC-MIL-001] (`QC-MIL-001`)
+- Scope: full review
+- Language and domain: en / it
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S02`)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete files, runs or documents. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go/No-Go table has objectively checkable criteria with Go and No-Go columns. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table names the preceding milestone and the reason. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites O7, O8 of BC-001 and the concerns of SA-001. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Ownership names S01 as owner and S02 (AI as stand-in) as approving reviewer. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target Date lies inside the window 2026-10-28 to 2026-11-06 of PP-001. |
+
+## 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 | Metadata has `Language` = en and `Domain` = it. |
+| 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is BCP 47; `it` is in the registry domain list. |
+| 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells of MIL-008 are English (stand-in assessment, see the verdict). |
+| 4 | The register matches the one the registry gives for the artifact type | Pass | Register of the type is given in the registry (Languages); the text keeps to it. |
+| 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | Terms follow DICT-001: bot, booking, lecture step (stand-in assessment, see the verdict). |
+| 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Keys, headings, IDs and statuses are English. |
+| 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin exists in `docs/`. |
+| 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; no language change. |
+| 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The stand-in reviewer reads English and checked the IT terms in context (stand-in assessment, see the verdict). |
+| 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out or defined where first used, or are the framework's own IDs. |
+
+## Overall Verdict
+
+Go — MIL-008 meets every Mandatory criterion. No blocking finding. The review is not independent: the AI authored and reviewed it as stand-in for S02, and S01 can challenge it in the end-of-run summary. Criteria 3, 5 and 9 of QC-LANG-001 were assessed by the stand-in only; the framework would hold them `Pending` for an independent language reviewer. S01 is asked to confirm them in the end-of-run summary. Tasks: tasks 1 to 6 cover README, three wiki languages, workflows and final checks.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | S01 | - |
+
+---
+
+[MIL-008]: ../../milestones/mil-008-documentation.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md

docs/sqa/traceability-matrix.md

@@ -0,0 +1,70 @@
+# Traceability Matrix
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | TM-001 |
+| CrossReference | [BC-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version: baseline artifacts | pending |
+
+---
+
+## Purpose
+
+Tracks backward and forward links between artifact instances so that the Business Case's traceability can be read in one place. A row is added or updated whenever an artifact is created or reviewed. Rows for code and tests are added by the milestones that create them.
+
+## Traceability Table
+
+| Artifact Instance | Type | Language | Domain | Upstream (Backward Link) | Downstream (Forward Link) | Last Reviewed (RC-ID) |
+| --- | --- | --- | --- | --- | --- | --- |
+| [BC-001] | Business Case | en | it | - | [SA-001], [PP-001] | RC-001 |
+| [SA-001] | Stakeholder Analysis | en | it | [BC-001] | [PP-001] | RC-002 |
+| [PP-001] | Project Plan | en | it | [BC-001], [SA-001] | [MIL-001] to [MIL-008] | RC-003 |
+| [DICT-001] | Domain Dictionary | en | it | [BC-001], [SA-001] | - | RC-004 |
+| [ADR-0001] | ADR | - | - | [BC-001] | [PP-001] | RC-005 |
+| [ADR-0002] | ADR | - | - | [BC-001], [SA-001] | code from MIL-002 onward | RC-006 |
+| [ADR-0003] | ADR | - | - | [BC-001] | [MIL-002], [MIL-003] | RC-007 |
+| [MIL-001] | Milestone | en | it | [BC-001], [PP-001] | [MIL-002] | RC-008 |
+| [MIL-002] | Milestone | en | it | [BC-001], [PP-001] | [MIL-003] | RC-009 |
+| [MIL-003] | Milestone | en | it | [BC-001], [PP-001] | [MIL-004] | RC-010 |
+| [MIL-004] | Milestone | en | it | [BC-001], [PP-001] | [MIL-005] | RC-011 |
+| [MIL-005] | Milestone | en | it | [BC-001], [PP-001] | [MIL-006] | RC-012 |
+| [MIL-006] | Milestone | en | it | [BC-001], [PP-001] | [MIL-007] | RC-013 |
+| [MIL-007] | Milestone | en | it | [BC-001], [PP-001] | [MIL-008] | RC-014 |
+| [MIL-008] | Milestone | en | it | [BC-001], [PP-001] | - | RC-015 |
+
+## Concern Coverage
+
+| Concern (CN-ID) | Views that answer it | Decisions (ADR) | Quality check | Status |
+| --- | --- | --- | --- | --- |
+| CN-001 | [BC-001], [MIL-003] to [MIL-006] | [ADR-0002] | Unit tests per gateway | Planned |
+| CN-002 | [PP-001], [MIL-001] | [ADR-0001] | Review records RC-001 onward | Covered |
+| CN-003 | [MIL-006], [MIL-007] | [ADR-0002] | Unit tests of `retry`; container chaos run | Planned |
+| CN-004 | [MIL-003] to [MIL-007] | [ADR-0002] | Code review against QC-PY-001 | Planned |
+| CN-005 | [MIL-002], [MIL-008] | - | `check-readme.sh` | Planned |
+| CN-006 | [MIL-008] | - | Page count per language | Planned |
+| CN-007 | [MIL-001] | - | Repository API response | Covered |
+| CN-008 | [MIL-002] | [ADR-0002] | `pyproject.toml` | Planned |
+| CN-009 | [MIL-001] | - | `.gitignore` lists `.env` | Covered |
+
+---
+
+[BC-001]: ../business-case.md
+[SA-001]: ../stakeholder-analysis.md
+[PP-001]: ../project-plan.md
+[DICT-001]: ../dictionary.md
+[ADR-0001]: ../adr/adr-0001-skip-stories-use-cases.md
+[ADR-0002]: ../adr/adr-0002-light-clean-architecture.md
+[ADR-0003]: ../adr/adr-0003-docker-headless-browser.md
+[MIL-001]: ../milestones/mil-001-baseline.md
+[MIL-002]: ../milestones/mil-002-scaffold.md
+[MIL-003]: ../milestones/mil-003-login.md
+[MIL-004]: ../milestones/mil-004-book-class.md
+[MIL-005]: ../milestones/mil-005-counters-and-both-days.md
+[MIL-006]: ../milestones/mil-006-verify-and-time-travel.md
+[MIL-007]: ../milestones/mil-007-resilience.md
+[MIL-008]: ../milestones/mil-008-documentation.md

docs/stakeholder-analysis.md

@@ -0,0 +1,88 @@
+# Stakeholder Analysis
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | SA-001 |
+| CrossReference | [BC-001] |
+| Language | en |
+| Domain | it |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-28 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S02 | Initial version: S01 to S03 | pending |
+
+---
+
+## Purpose
+
+This analysis names the people the Snack and Lift booking bot project affects, how much power and interest each has, what each needs, and who reviews and accepts the work. It follows the power/interest grid (Manage Closely, Keep Satisfied, Keep Informed, Monitor) and maps each concern to a FURPS+ attribute. The business context is in [BC-001].
+
+## 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) | HIGH | HIGH | Manage Closely | Finish the assignment as a reviewed, documented repository |
+| S02 | Udemy course participants | Users who share code and compare solutions | Udemy 100 Days of Code community | LOW | HIGH | Keep Informed | Readable, runnable code with the assignment's function names, and README instructions to run it |
+| S03 | GitHub viewers | Visitors who browse the repository for ideas | Public | LOW | MEDIUM | Keep Informed | A clear repository description, topics and README, and no runtime dependencies beyond what is needed |
+
+## Power/Interest Classification Rationale
+
+- **Manage Closely (S01):** S01 sets scope, accepts the plan and reviews the result. Every decision outside the accepted plan returns to S01.
+- **Keep Informed (S02):** S02 cannot change the project but depends on its clarity. They are informed through the README, the code and the wiki.
+- **Keep Informed (S03):** S03 has even less stake: they browse. The description, topics and README are their whole contact with the project.
+- No stakeholder is in Keep Satisfied or Monitor.
+
+## Primary Concerns and FURPS+ Mapping
+
+| Concern ID | Stakeholder | Concern | FURPS+ attribute |
+| --- | --- | --- | --- |
+| CN-001 | S01 | The bot completes the nine lecture steps: login, booking, waitlist, summary, verification | Functionality |
+| CN-002 | S01 | Work is planned, reviewed and traceable by branch and pull request | Supportability |
+| CN-003 | S01 | The bot survives network failures and any date of the site's time travel | Reliability |
+| CN-004 | S02 | Code is readable and uses the assignment's function names | Usability |
+| CN-005 | S02 | The README explains how to create a `.venv`, run the bot and run the tests | Usability |
+| CN-006 | S02 | The wiki explains what each lecture step teaches, with a screenshot, in English, Danish and Bahasa Malaysia | Usability |
+| CN-007 | S03 | The repository has a clear description, topics and README | Usability |
+| CN-008 | S03 | No runtime dependency beyond Selenium | Implementation |
+| CN-009 | S01 | A token stays outside the repository | Supportability |
+
+## Communication Requirements
+
+| ID | Channel | Frequency | Deliverable | Phase / Milestone |
+| --- | --- | --- | --- | --- |
+| CM-001 | Chat with S01 | Once per plan, and on every stop condition | Plan acceptance, questions, final summary | All milestones |
+| CM-002 | Pull request on the git host | One per milestone | Changes, review records, closed issues | All milestones |
+| CM-003 | README and wiki | On each release | Run instructions, lecture step explanations | Documentation milestone |
+
+## Conflicting Interests and Mitigations
+
+| Conflict | Stakeholders | Mitigation |
+| --- | --- | --- |
+| S01 wants a resilient, well structured bot, while S02 wants code that stays simple and close to the assignment | S01, S02 | Keep the assignment's functions (`retry`, `login`, `book_class`, `get_my_bookings`) as the public API; keep helpers small and documented |
+| S01 wants thorough tests and framework artifacts, while S03 wants no extra runtime dependencies | S01, S03 | Test tools are development-only extras in `pyproject.toml`; Selenium is the only runtime dependency |
+
+## Traceability Analysis
+
+### Business Goal Alignment
+
+| Stakeholder | Concern | Business Case objective |
+| --- | --- | --- |
+| S01 | CN-001 | O1 to O5 in [BC-001] |
+| S01 | CN-003 | O5, O6 in [BC-001] |
+| S01 | CN-002, CN-009 | O7 in [BC-001] |
+| S02 | CN-004, CN-005 | O7 in [BC-001] |
+| S02 | CN-006 | O8 in [BC-001] |
+| S03 | CN-007, CN-008 | O7 in [BC-001] |
+
+## Sign-Off
+
+| Role | Stakeholder | Status |
+| --- | --- | --- |
+| Product Owner | S01 | Accepted the plan in chat on 2026-10-28 |
+| Reviewer | AI as stand-in for S02 | Go in RC-002, autonomous mode, not independent |
+
+---
+
+[BC-001]: ./business-case.md