2026-10-13 10:21:11 +02:00
15 changed files with 977 additions and 0 deletions
@@ -0,0 +1,3 @@
 [submodule "framework"]
 	path = framework
 	url = ssh://git@git.tirsystem.com:10022/TirSystem/SQA-QC-Framework.git
@@ -0,0 +1,59 @@
 # Artifact Registry
 This project's artifact state. Types, short names and `CrossReference
 Candidates` come from the framework catalog
 (`framework/registry/artifact-catalog.md`); this file only records where
 each document lives in *this* project and the next version to use.
 Delete rows for types you don't use. Add a row the first time you create a
 document of a type. `Primary File` may contain a glob (e.g.
 `docs/uc-*/uc.md`); `framework/scripts/find-crossreferences.sh` reads it.
 | Short Name | Artifact Type | Primary File | Next Available Version |
 | --- | --- | --- | --- |
 | BC | Business Case | docs/business-case.md | 002 |
 | SA | Stakeholder Analysis | docs/stakeholder-analysis.md | 002 |
 | PP | Project Plan | docs/project-plan.md | 002 |
 | MIL | Milestone / Gateway | docs/milestones/*.md | 004 |
 | RC | SQA Review Record | docs/sqa/reviews/rc-*.md | 006 |
 | TM | Traceability Matrix | docs/sqa/traceability-matrix.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 |
 Every artifact of a type marked "Yes" below states its language and domain in
 its `Language` and `Domain` Metadata rows; `new-artifact.sh` fills them from
 `PO language` and `PO domain`. `Language` is a BCP 47 code (`da`, `en`).
 `Domain` is a value from this list; add a row to introduce a domain, so a
 reviewer can see at once which professional vocabulary a document uses.
 | Domain | Meaning |
 | --- | --- |
 | it | Software and IT |
 | medical | Healthcare and medical devices |
 | construction | Construction and civil engineering |
 | Artifact types | Register | Written in the PO language |
 | --- | --- | --- |
 | BC, KPI, PP, MIL | IT Executive English | Yes |
 | SA, BMC, BPMN, UCD, US, UC, SSD, DM, RA, GOV, DICT | IT Professional English | Yes |
 | OC, SD, DCD, ERD, ADR, TM, RC, QC, source code | IT Professional English | No |
 ## Notes
 - "Next Available Version" is the zero-padded (3-digit) version to use the
  *next* time a new document of that type is created. Increment it only when
  a brand-new document is created, not when an existing document's
  `## Version History` gets a row.
 - `ADR` uses 4 digits (`0001`); `RC` is sequential across all artifact types.
@@ -0,0 +1,138 @@
 # Business Case
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | BC-001 |
 | CrossReference | [SA-001] |
 | Language | en |
 | Domain | it |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-001 | pending |
 ---
 ## Executive Summary
 Day 26 of the Udemy course "100 Days of Code: The Complete Python Pro Bootcamp" teaches list and dictionary comprehensions through a small console tool: the user types a word and the program spells it out with the NATO phonetic alphabet. This project delivers that assignment as a clean, tested, documented Python repository that other course participants and GitHub visitors can read, run and compare against their own solutions. It uses only the Python standard library at runtime.
 ## Methodological and Standards Foundation
 - Methodology: the project follows the SQA and QC framework mounted at `framework/` (plan first, review every artifact against its QC checklist, one pull request per milestone).
 - Quality model: ISO/IEC 25010:2023 characteristics tag every QC criterion; code is reviewed against `qc-programming-python.md`.
 - Engineering practice: Clean Architecture layering at a size proportionate to the program, tests written with pytest, source documented with Doxygen comments.
 ## Problem Statement
 - The course assignment ships as a loose `main.py` and a CSV file with no tests, no run instructions and no project structure, so a participant cannot easily share or compare a solution.
 - Public solutions to course assignments are often undocumented, depend on heavy libraries (the course uses Pandas for a 26-row table) and are not runnable without guesswork.
 ## Business Opportunity
 A small, exemplary solution lets the Product Owner practise professional project hygiene (packaging, tests, CI, documentation, multilingual wiki) on a trivially small domain, and gives other learners and GitHub visitors a reference they can run in a minute.
 ## Objectives
 1. O1: Deliver a console program that converts a word typed by the user into the list of NATO phonetic code words, built with list and dictionary comprehensions, keeping the assignment's function names.
 2. O2: Make the repository runnable by following the README on Windows PowerShell, Debian Linux and macOS with a local `.venv`.
 3. O3: Cover the behaviour with automated pytest tests that run in continuous integration.
 4. O4: Document the source with Doxygen comments and a `Doxyfile`, and document the project in a README and a wiki in English, Danish and Bahasa Malaysia, with screenshots.
 5. O5: Present the repository to GitHub viewers with a description and topics, and with no runtime dependencies.
 ## Scope
 ### In Scope
 - Console program: reads a word, prints the NATO code words for its letters; asks again when the input contains a character that is not a letter.
 - NATO alphabet data file (comma-separated values, CSV, as supplied with the assignment) and a loader that uses the standard library.
 - Project structure `src/`, `tests/`, `docs/`; `pyproject.toml`; `constants.py`; Python `.gitignore`; `Doxyfile`.
 - pytest test suite; continuous integration (CI) workflow that runs the tests.
 - README from the framework template; wiki pages in en, da and ms; screenshots for README and wiki.
 - Repository description and topics on the git host.
 ### Out of Scope
 - A graphical or web interface.
 - Publishing a package to the Python Package Index (PyPI).
 - Runtime dependencies such as Pandas.
 - Non-Latin alphabets and digits (rejected with a message).
 - Other course days.
 ## Expected Benefits
 ### Tangible Benefits
 - A runnable, tested reference solution with a one-command test run.
 - A reusable repository skeleton (pyproject, continuous integration, Doxygen, wiki) for later course days.
 ### Intangible Benefits
 - Practice in professional project hygiene.
 - A readable example for other learners, in three languages.
 ## Strategic Alignment
 The project supports the Product Owner's personal goal of completing the 100 Days of Code bootcamp with portfolio-quality repositories, and the framework's goal of demonstrating the plan-first workflow on a small project.
 ## Success Criteria
 | # | Criterion | Target | Measure |
 | --- | --- | --- | --- |
 | 1 | Program spells a word correctly | Every letter A-Z maps to its NATO code word; input is case-insensitive | pytest: all 26 letters and a mixed-case word pass |
 | 2 | Tests pass | 100 % of tests pass on Python 3.13 locally and in CI | `python -m pytest` exit code 0; CI run green |
 | 3 | No runtime dependencies | 0 runtime dependencies | `pyproject.toml` has an empty `dependencies` list |
 | 4 | Setup works from the README | A fresh clone runs the program using only the README steps | Manual run of the README steps on Windows PowerShell |
 | 5 | Documentation complete | README sections of the template, wiki in 3 languages, Doxygen builds without warnings | `check-readme.sh` exit 0; every wiki page exists in en, da and ms; `doxygen Doxyfile` reports 0 warnings |
 | 6 | Repository presented | Description and at least 5 topics set | Repository page and API show both |
 ## Risks
 | Risk | Impact | Mitigation |
 | --- | --- | --- |
 | The git host token lacks scope for editing the repository or wiki | Description, topics or wiki cannot be published | Stop and report; keep the wiki content as files in the working tree and ask S01 for a token with the needed scope |
 | The wiki is not enabled on the host | Wiki pages cannot be pushed | Enable it through the repository settings API; otherwise stop and report |
 | Danish and Bahasa Malaysia translations contain errors | S02 or S03 read wrong text | Keep wiki sentences short and simple; S01 reviews the translations in the pull request |
 | Starter code is copied verbatim | Originality concerns | The program is written fresh; only the supplied CSV data is reused, as the assignment intends |
 | Secrets in `.env` leak into the repository | Credential exposure | `.env` is git-ignored, never imported by the program or tests, and never echoed |
 ## Assumptions
 - The Product Owner is S01, who also develops and reviews; in autonomous mode the AI acts as S01's stand-in reviewer and the review records say so.
 - Python 3.13 or newer is available on the machines of the readers.
 - The git host (Gitea) offers repository, topic and wiki features through its application programming interface (API) and git remote.
 - The CSV with 26 letter/code word rows supplied with the assignment is the data source.
 ## Constraints
 - Python 3.13 or newer, a local `venv`, `pytest`, constants in `constants.py`, configuration in `pyproject.toml`.
 - Folder structure `src/`, `tests/`, `docs/`.
 - No runtime dependencies unless needed.
 - Tokens are read from `.env` for personal use only; the project and its tests never import or test it.
 - One pull request per milestone; no commit on `main`.
 ## Cost–Benefit Assessment
 Qualitative, because the project is a personal learning exercise with no revenue; the effort is a few hours of S01's time and AI assistance.
 | Costs | Benefits |
 | --- | --- |
 | A few hours of effort; hosting on an existing git host | A reusable reference repository, practice with the framework, a shareable example for S02 and S03 |
 ## Stakeholders
 | Stakeholder ID (SA) | Interest in this project |
 | --- | --- |
 | S01 | Owns and builds the project; wants a clean, complete solution |
 | S02 | Wants readable, runnable code with the assignment's function names and run instructions |
 | S03 | Wants a clear description, topics and README, and no runtime dependencies |
 ## Recommendation
 Proceed: the scope is small, the risks are low and every objective is verifiable.
 ---
 [SA-001]: ./stakeholder-analysis.md
@@ -0,0 +1,74 @@
 # MIL-001 Repository foundation
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | MIL-001 |
 | CrossReference | [BC-001] |
 | Language | en |
 | Domain | it |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-003 | pending |
 ---
 ## Purpose
 Decide whether the repository has the structure, configuration and automation that the converter can be built on: a Python 3.13 project with a local virtual environment, pytest, a Doxygen configuration, a CI workflow and a public presentation (description and topics).
 ## Deliverable
 A repository containing `pyproject.toml`, a Python `.gitignore`, the `src/` package skeleton with `constants.py` and the NATO CSV data file, an empty but running `tests/` folder, a `Doxyfile`, a CI workflow, two ADRs, and a repository description and topics set on the git host.
 ## Go / No-Go Criteria
 | # | Criterion (objectively checkable) | Go | No-Go |
 | --- | --- | --- | --- |
 | 1 | `pyproject.toml` declares `requires-python >=3.13`, an empty `dependencies` list and pytest as a development extra | Present | Missing or a runtime dependency is listed |
 | 2 | `.gitignore` ignores `.venv/`, `__pycache__/`, `.env` and the Doxygen output | `git check-ignore` confirms each | Any entry missing |
 | 3 | A fresh `.venv` installs the project with `python -m pip install -e ".[dev]"` and `python -m pytest` runs | Exit code 0 | Install or run fails |
 | 4 | `doxygen Doxyfile` builds | Exit code 0 | Build fails |
 | 5 | The CI workflow runs the same pytest command and passes the framework's workflow checklist | Review `Go` | Review `No-Go` |
 | 6 | The repository description and at least 5 topics are set on the host | API returns both | Missing |
 | 7 | `.env` is not tracked and no token appears in any tracked file | `git ls-files` and a search show none | Any hit |
 ## Dependencies
 | Depends on | Reason |
 | --- | --- |
 | None | First phase; follows the accepted Business Case, Stakeholder Analysis and Project Plan |
 ## Traceability
 | Business Case objective / KPI / user story | Reference |
 | --- | --- |
 | O2, O3, O4, O5 | [BC-001] |
 ## Ownership
 | Role | Stakeholder ID (SA) |
 | --- | --- |
 | Owner | S01 |
 | Approving reviewer | S01 |
 ## Target Date
 2026-10-14 — inside the plan's window (2026-10-13 to 2026-10-16).
 ## Tasks
 | # | Task | Summary | Needs its own Use Case/User Story? | Reference |
 | --- | --- | --- | --- | --- |
 | 1 | Record architecture decisions | Write ADR-0001 (read the NATO data with the standard library `csv` module instead of Pandas, so the project has no runtime dependencies for S03) and ADR-0002 (KPI, BMC, BPMN and RA are skipped for a project of this size). | No | |
 | 2 | Configure the Python project | Add `pyproject.toml` (Python 3.13 or newer, no runtime dependencies, pytest as a development extra, pytest and package settings) and a Python `.gitignore` that also ignores `.env`, `.venv` and Doxygen output. | No | |
 | 3 | Create the package skeleton | Create `src/nato_alphabet/` with `constants.py` (data file name, prompt and message texts), the supplied `nato_phonetic_alphabet.csv` as package data, and an empty `tests/` package, so the converter has a place to land. | No | |
 | 4 | Add the Doxyfile | Generate a `Doxyfile` that reads `src/`, writes to `build/doxygen/`, extracts Python docstrings and warns on undocumented members. | No | |
 | 5 | Add the CI workflow | Add a Gitea Actions workflow that sets up Python 3.13, creates a venv, installs the project and runs `python -m pytest` on every push and pull request. | No | |
 | 6 | Set repository description and topics | Use the Gitea API with the token from the git-ignored `.env` (never printed, imported or committed) to set a description and topics so S03 sees what the repository is. | No | |
 ---
 [BC-001]: ../business-case.md
@@ -0,0 +1,76 @@
 # MIL-002 NATO converter
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | MIL-002 |
 | CrossReference | [BC-001] |
 | Language | en |
 | Domain | it |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-004 | pending |
 ---
 ## Purpose
 Decide whether the console program does what the assignment asks: read a word, and print the NATO code word of each letter, built with list and dictionary comprehensions and tested with pytest.
 ## Deliverable
 The `nato_alphabet` package with a runnable entry point, a test suite that passes, and Doxygen comments on every public item; plus the user story, use case and system sequence diagram of "spell a word".
 ## Go / No-Go Criteria
 | # | Criterion (objectively checkable) | Go | No-Go |
 | --- | --- | --- | --- |
 | 1 | All 26 letters map to their code word and input is case-insensitive | pytest passes | Any test fails |
 | 2 | A character that is not a letter makes the program ask again instead of crashing | pytest covers it and passes | Missing or failing |
 | 3 | The loader uses a dictionary comprehension and the converter a list comprehension | Code review confirms | Loops used instead |
 | 4 | The assignment's function names are kept in the public API | Names present in the module | Names missing |
 | 5 | The code review against `qc-programming-python.md` is a `Go` | `RC-*` verdict `Go` | `No-Go` |
 | 6 | `doxygen Doxyfile` reports no warnings | 0 warnings | Any warning |
 | 7 | Constants live in `constants.py`; `.env` is not imported by `src/` or `tests/` | Search confirms | Any hit |
 ## Dependencies
 | Depends on | Reason |
 | --- | --- |
 | [MIL-001] | Project configuration, skeleton, CI and Doxyfile |
 ## Traceability
 | Business Case objective / KPI / user story | Reference |
 | --- | --- |
 | O1, O3, O4 | [BC-001] |
 | Spell a word | US-001, UC-001 |
 ## Ownership
 | Role | Stakeholder ID (SA) |
 | --- | --- |
 | Owner | S01 |
 | Approving reviewer | S01 |
 ## Target Date
 2026-10-15 — inside the plan's window (2026-10-13 to 2026-10-16).
 ## Tasks
 | # | Task | Summary | Needs its own Use Case/User Story? | Reference |
 | --- | --- | --- | --- | --- |
 | 1 | Model "spell a word" | Write US-001, UC-001 (brief) and the system sequence diagram for the user who types a word and receives its NATO code words, including the retry on invalid input. Domain concepts are only letter and code word, so no domain model is added. | Yes | US-001, UC-001 |
 | 2 | Load the NATO alphabet | Read the CSV with the standard library and build the letter-to-code-word dictionary with a dictionary comprehension (`load_nato_dict`), taking the file name from `constants.py`. | No | |
 | 3 | Convert a word to code words | Implement the assignment's `generate_phonetic` with a list comprehension: upper-case the word, return the code word of each letter, raise a clear error for a character that is not a letter. | No | |
 | 4 | Implement the console entry point | Prompt for a word, print the code words, ask again on invalid input; runnable as `python -m nato_alphabet` and as the `nato-alphabet` command. | Yes | UC-001 |
 | 5 | Write the pytest suite | Test all letters, mixed case, unknown characters, the loader (with a temporary CSV) and the entry point (with patched input and captured output). | No | |
 | 6 | Add Doxygen comments | Document every module, function and constant with Doxygen comments and confirm the build has no warnings. | No | |
 ---
 [BC-001]: ../business-case.md
 [MIL-001]: ./mil-001-repository-foundation.md
@@ -0,0 +1,75 @@
 # MIL-003 Documentation and publication
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | MIL-003 |
 | CrossReference | [BC-001] |
 | Language | en |
 | Domain | it |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-005 | pending |
 ---
 ## Purpose
 Decide whether S02 and S03 can understand, set up and run the project from its README and wiki without help, in English, Danish and Bahasa Malaysia.
 ## Deliverable
 The `README.md` built from the framework template with screenshots, and a wiki in English, Danish and Bahasa Malaysia with the same pages and screenshots, published on the git host.
 ## Go / No-Go Criteria
 | # | Criterion (objectively checkable) | Go | No-Go |
 | --- | --- | --- | --- |
 | 1 | `check-readme.sh` reports no finding for the README | Exit code 0 | Any finding |
 | 2 | The README steps (create `.venv`, upgrade pip, install, run, test) work on a fresh clone on Windows PowerShell | The run produces the expected output | A step fails |
 | 3 | Every wiki page exists in en, da and ms | `check-languages.sh` and a file listing agree | A page is missing |
 | 4 | The README and each wiki language show a screenshot | Image files exist and are linked | Missing |
 | 5 | The wiki is published and readable on the host | Page requests return success | Any page not found |
 | 6 | `doxygen Doxyfile` builds and the README says how | Exit code 0 and the section exists | Missing |
 ## Dependencies
 | Depends on | Reason |
 | --- | --- |
 | [MIL-002] | The documentation describes the finished program |
 ## Traceability
 | Business Case objective / KPI / user story | Reference |
 | --- | --- |
 | O2, O4, O5 | [BC-001] |
 ## Ownership
 | Role | Stakeholder ID (SA) |
 | --- | --- |
 | Owner | S01 |
 | Approving reviewer | S01 |
 ## Target Date
 2026-10-16 — the end of the plan's window.
 ## Tasks
 | # | Task | Summary | Needs its own Use Case/User Story? | Reference |
 | --- | --- | --- | --- | --- |
 | 1 | Capture screenshots | Run the program and render its real output as PNG images (a word spelled, an invalid input retried) stored under `docs/images/` for the README and the wiki. | No | |
 | 2 | Write the README | Fill the framework README template: set-up on Windows PowerShell, Linux Debian and macOS with a local `.venv` and `python -m pip install --upgrade pip`, run, tests, continuous integration, Doxygen build, layout and licence. | No | |
 | 3 | Write the English wiki | Pages Home, Install, Usage and Development in English with screenshots, in the layout of the framework wiki. | No | |
 | 4 | Write the Danish wiki | The same pages in Danish with the `-da` suffix. | No | |
 | 5 | Write the Bahasa Malaysia wiki | The same pages in Bahasa Malaysia with the `-ms` suffix. | No | |
 | 6 | Publish the wiki | Push the pages to the repository's wiki on the git host and check that each page is readable. | No | |
 | 7 | Verify the set-up instructions | Follow the README from a fresh clone in a new `.venv`, run the program and the tests, and record the result in the review. | No | |
 ---
 [BC-001]: ../business-case.md
 [MIL-002]: ./mil-002-nato-converter.md
@@ -0,0 +1,89 @@
 # Project Plan
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | PP-001 |
 | CrossReference | [BC-001], [SA-001], [MIL-001], [MIL-002], [MIL-003] |
 | Language | en |
 | Domain | it |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, accepted as Product Owner stand-in (no QC checklist for PP yet) | pending |
 ---
 ## Purpose
 Schedule the three phases that deliver the Day 26 NATO alphabet assignment as a tested and documented repository: foundation, converter, documentation and publication. The plan runs against the Business Case's constraint of a small personal project with one pull request per milestone.
 ## Planning Assumptions
 - The plan starts 2026-10-13 and ends by 2026-10-16.
 - Each phase is one day of work and one pull request that closes its issues.
 - S01 is owner and reviewer of every gateway; in autonomous mode the AI acts as S01's stand-in and every review record says so.
 - The language of the planning documents is English (registry `Languages`); the wiki is written in English, Danish and Bahasa Malaysia.
 - The git host is the Gitea instance at `git.tirsystem.com`; its token comes from the git-ignored `.env`.
 ## Gateway Schedule
 | Gateway | Document | Window | Decision date | Owner | Stories | Main deliverable | Milestone |
 | --- | --- | --- | --- | --- | --- | --- | --- |
 | Repository foundation | [MIL-001] | 2026-10-13 to 2026-10-14 | 2026-10-14 | S01 | none | Project configuration, package skeleton, Doxyfile, CI workflow, ADRs, repository description and topics | |
 | NATO converter | [MIL-002] | 2026-10-14 to 2026-10-15 | 2026-10-15 | S01 | US-001 | Working console program with pytest tests and Doxygen comments | |
 | Documentation and publication | [MIL-003] | 2026-10-15 to 2026-10-16 | 2026-10-16 | S01 | none | README, screenshots, wiki in en, da and ms | |
 ```plantuml
@startgantt
 Project starts 2026-10-13
 [Repository foundation] starts 2026-10-13 and ends 2026-10-14
 [MIL-001 Go/No-Go] happens 2026-10-14
 [NATO converter] starts 2026-10-14 and ends 2026-10-15
 [MIL-002 Go/No-Go] happens 2026-10-15
 [Documentation and publication] starts 2026-10-15 and ends 2026-10-16
 [MIL-003 Go/No-Go] happens 2026-10-16
@endgantt
 ```
 ## Scope Coverage
 | Business Case scope item | Gateway |
 | --- | --- |
 | Console program and NATO data loader | [MIL-002] |
 | Project structure, `pyproject.toml`, `constants.py`, `.gitignore`, `Doxyfile` | [MIL-001] |
 | pytest test suite | [MIL-002] |
 | CI workflow that runs the tests | [MIL-001] |
 | README, wiki (en, da, ms) and screenshots | [MIL-003] |
 | Repository description and topics | [MIL-001] |
 ## Dependencies
 ```
 MIL-001 → MIL-002 → MIL-003
 ```
 A No-Go on a gateway holds the later ones until the cause is fixed and the gateway is reviewed again; later windows shift by the same days.
 ## Plan Risks
 | Risk | Impact | Mitigation |
 | --- | --- | --- |
 | The host token lacks scope for repository settings or wiki | MIL-001 or MIL-003 cannot finish | Stop and report (autonomous-mode stop rule); S01 supplies a token with the scope |
 | The CI runner on the host is not available | CI workflow cannot be proven green | The workflow is verified by running the same commands locally; the gap is recorded in the review |
 | Wiki translation takes longer than planned | MIL-003 slips | Wiki pages are short and share one structure |
 ## Open Issues
 - "Python greater than 3.13" is read as 3.13 or newer (`requires-python = ">=3.13"`); S01 can tighten it.
 - `.env` also holds a GitHub token and user; no GitHub mirror was requested, so they are not used.
 - Screenshots are rendered from the real program output (a terminal-style image), because a desktop screenshot cannot be taken from an unattended run; S01 may replace them with native captures.
 ---
 [BC-001]: ./business-case.md
 [SA-001]: ./stakeholder-analysis.md
 [MIL-001]: ./milestones/mil-001-repository-foundation.md
 [MIL-002]: ./milestones/mil-002-nato-converter.md
 [MIL-003]: ./milestones/mil-003-documentation-and-publication.md
@@ -0,0 +1,67 @@
 # SQA Review Record RC-001: BC-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-001 |
 | CrossReference | [BC-001], [QC-BC-001], [QC-LANG-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Review of BC-001 | pending |
 ---
 ## Artifact Under Review
 - Instance reviewed: [BC-001]
 - Checklist used: [QC-BC-001] and [QC-LANG-001]
 - Scope: full review
 - Language and domain: en / it
 - Language reviewer: none (the reviewer reads the language and knows the domain)
 - Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`)
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | ROI/Cost-Benefit analysis is quantitative, or where qualitative, is explicitly justified | Pass | Cost-Benefit is qualitative and the section states why (personal learning exercise, no revenue). |
 | 2 | Risks are identified with documented impact and mitigation | Pass | Five risks, each with impact and mitigation. |
 | 3 | Success criteria are measurable, stating explicit targets rather than vague aspirations | Pass | Six success criteria, each with a numeric or checkable target and a measure. |
 | 4 | Scope explicitly separates In Scope vs Out of Scope | Pass | `### In Scope` and `### Out of Scope` are separate subsections. |
 | 5 | Stakeholders are cross-referenced to Stakeholder Analysis IDs rather than re-described inline | Pass | The Stakeholders table cites S01, S02 and S03 from [SA-001]; roles are not re-described. |
 | 6 | Methodology and quality-standard foundation are stated explicitly (e.g. ISO/IEC 25010, Larman) | Pass | The foundation section names the framework, ISO/IEC 25010:2023 and Clean Architecture. |
 | 7 | Assumptions and constraints are explicit and clearly distinguished from one another | Pass | Assumptions and Constraints are separate sections. |
 | 8 | Document supports executive decision-making with a clear, unambiguous recommendation | Pass | The Recommendation is a single "Proceed" with a rationale. |
 ## Language and Domain Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language | en` and `Domain | it` are in the Metadata table. |
 | 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
 | 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells are English; the course title is quoted source text. Checked by the stand-in reviewer, who reads English. |
 | 4 | The register matches the one the registry gives for the artifact type | Pass | The registry gives IT Executive English for this type; the text matches it. |
 | 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | No dictionary (`DICT`) exists yet; the terms letter, code word and NATO alphabet are used consistently with no synonyms. Checked by the stand-in; open to challenge. |
 | 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
 | 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin of the file exists. |
 | 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | Pass | First version; no change of language or domain. |
 | 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The domain is software and IT and the language English; the reviewer stood in for (S01) reads both. A person may challenge this in the run summary. |
 | 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out on first use or are identifiers (IDs, tool names). |
 ## Overall Verdict
 Go — every Mandatory criterion of QC-BC-001 and of QC-LANG-001 passes. The review is a stand-in review by the author's AI and is not independent; it is open to challenge in the run summary.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | S01 | n/a |
 ---
 [BC-001]: ../../business-case.md
 [QC-BC-001]: ../../../framework/qc/artifacts/qc-business-case.md
 [QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
@@ -0,0 +1,67 @@
 # SQA Review Record RC-002: SA-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-002 |
 | CrossReference | [SA-001], [QC-SA-001], [QC-LANG-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Review of SA-001 | pending |
 ---
 ## Artifact Under Review
 - Instance reviewed: [SA-001]
 - Checklist used: [QC-SA-001] and [QC-LANG-001]
 - Scope: full review
 - Language and domain: en / it
 - Language reviewer: none (the reviewer reads the language and knows the domain)
 - Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`)
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Power/Interest grid is filled for every stakeholder, with no gaps or unclassified entries | Pass | S01, S02 and S03 each have Power, Interest and Quadrant. |
 | 2 | Each stakeholder is assigned a unique, stable ID (e.g. S01-S11 style) reusable for RACI assignments in other artifacts | Pass | Stable IDs S01 to S03, used by the other artifacts. |
 | 3 | Roles and organizational context are defined with explicit Power and Interest levels, not just narrative description | Pass | Role and organization are stated with explicit HIGH/MEDIUM/LOW levels. |
 | 4 | Communication needs (channel, frequency, deliverable type) are mapped to project phases or milestones | Pass | Communication table maps channel, frequency and deliverable to milestones. |
 | 5 | Conflicting stakeholder interests are identified with documented mitigation or resolution strategies | Pass | Two conflicts, each with a mitigation. |
 | 6 | Stakeholder concerns are explicitly traced to Business Case objectives | Pass | Traceability table cites [BC-001] objectives O1 to O5. |
 | 7 | Primary concerns are expressed in both business language and a recognized quality-attribute mapping (e.g. FURPS+) | Pass | Each concern is mapped to a FURPS+ attribute. |
 | 8 | Document is understandable and navigable by non-technical stakeholders reviewing their own entry | Pass | Short tables; each entry reads on its own. |
 ## Language and Domain Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language | en` and `Domain | it` are in the Metadata table. |
 | 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
 | 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells are English; the course title is quoted source text. Checked by the stand-in reviewer, who reads English. |
 | 4 | The register matches the one the registry gives for the artifact type | Pass | The registry gives IT Professional English for this type; the text matches it. |
 | 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | No dictionary (`DICT`) exists yet; the terms letter, code word and NATO alphabet are used consistently with no synonyms. Checked by the stand-in; open to challenge. |
 | 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
 | 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin of the file exists. |
 | 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | Pass | First version; no change of language or domain. |
 | 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The domain is software and IT and the language English; the reviewer stood in for (S01) reads both. A person may challenge this in the run summary. |
 | 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out on first use or are identifiers (IDs, tool names). |
 ## Overall Verdict
 Go — every Mandatory criterion of QC-SA-001 and of QC-LANG-001 passes. The review is a stand-in review by the author's AI and is not independent; it is open to challenge in the run summary.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | S01 | n/a |
 ---
 [SA-001]: ../../stakeholder-analysis.md
 [QC-SA-001]: ../../../framework/qc/artifacts/qc-stakeholder-analysis.md
 [QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
@@ -0,0 +1,65 @@
 # SQA Review Record RC-003: MIL-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-003 |
 | CrossReference | [MIL-001], [QC-MIL-001], [QC-LANG-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Review of MIL-001 | pending |
 ---
 ## Artifact Under Review
 - Instance reviewed: [MIL-001]
 - Checklist used: [QC-MIL-001] and [QC-LANG-001]
 - Scope: full review
 - Language and domain: en / it
 - Language reviewer: none (the reviewer reads the language and knows the domain)
 - Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`)
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete output: project configuration, skeleton, Doxyfile, CI workflow, ADRs, description and topics. |
 | 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go / No-Go table has objectively checkable rows (commands and counts). |
 | 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table is filled. |
 | 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites [BC-001] objectives. |
 | 5 | Milestone owner and approving reviewer are identified | Pass | Owner and approving reviewer are S01. |
 | 6 | Milestone has a defined target date consistent with project constraints | Pass | Target date lies inside the Project Plan window; the Business Case sets no calendar constraint. |
 ## Language and Domain Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language | en` and `Domain | it` are in the Metadata table. |
 | 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
 | 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells are English; the course title is quoted source text. Checked by the stand-in reviewer, who reads English. |
 | 4 | The register matches the one the registry gives for the artifact type | Pass | The registry gives IT Executive English for this type; the text matches it. |
 | 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | No dictionary (`DICT`) exists yet; the terms letter, code word and NATO alphabet are used consistently with no synonyms. Checked by the stand-in; open to challenge. |
 | 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
 | 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin of the file exists. |
 | 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | Pass | First version; no change of language or domain. |
 | 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The domain is software and IT and the language English; the reviewer stood in for (S01) reads both. A person may challenge this in the run summary. |
 | 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out on first use or are identifiers (IDs, tool names). |
 ## Overall Verdict
 Go — every Mandatory criterion of QC-MIL-001 and of QC-LANG-001 passes. The review is a stand-in review by the author's AI and is not independent; it is open to challenge in the run summary.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | S01 | n/a |
 ---
 [MIL-001]: ../../milestones/mil-001-repository-foundation.md
 [QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
 [QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
@@ -0,0 +1,65 @@
 # SQA Review Record RC-004: MIL-002
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-004 |
 | CrossReference | [MIL-002], [QC-MIL-001], [QC-LANG-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Review of MIL-002 | pending |
 ---
 ## Artifact Under Review
 - Instance reviewed: [MIL-002]
 - Checklist used: [QC-MIL-001] and [QC-LANG-001]
 - Scope: full review
 - Language and domain: en / it
 - Language reviewer: none (the reviewer reads the language and knows the domain)
 - Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`)
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete output: working console program, tests, Doxygen comments, user story and use case. |
 | 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go / No-Go table has objectively checkable rows (commands and counts). |
 | 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table is filled. |
 | 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites [BC-001] objectives. |
 | 5 | Milestone owner and approving reviewer are identified | Pass | Owner and approving reviewer are S01. |
 | 6 | Milestone has a defined target date consistent with project constraints | Pass | Target date lies inside the Project Plan window; the Business Case sets no calendar constraint. |
 ## Language and Domain Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language | en` and `Domain | it` are in the Metadata table. |
 | 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
 | 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells are English; the course title is quoted source text. Checked by the stand-in reviewer, who reads English. |
 | 4 | The register matches the one the registry gives for the artifact type | Pass | The registry gives IT Executive English for this type; the text matches it. |
 | 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | No dictionary (`DICT`) exists yet; the terms letter, code word and NATO alphabet are used consistently with no synonyms. Checked by the stand-in; open to challenge. |
 | 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
 | 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin of the file exists. |
 | 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | Pass | First version; no change of language or domain. |
 | 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The domain is software and IT and the language English; the reviewer stood in for (S01) reads both. A person may challenge this in the run summary. |
 | 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out on first use or are identifiers (IDs, tool names). |
 ## Overall Verdict
 Go — every Mandatory criterion of QC-MIL-001 and of QC-LANG-001 passes. The review is a stand-in review by the author's AI and is not independent; it is open to challenge in the run summary.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | S01 | n/a |
 ---
 [MIL-002]: ../../milestones/mil-002-nato-converter.md
 [QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
 [QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
@@ -0,0 +1,65 @@
 # SQA Review Record RC-005: MIL-003
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-005 |
 | CrossReference | [MIL-003], [QC-MIL-001], [QC-LANG-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Review of MIL-003 | pending |
 ---
 ## Artifact Under Review
 - Instance reviewed: [MIL-003]
 - Checklist used: [QC-MIL-001] and [QC-LANG-001]
 - Scope: full review
 - Language and domain: en / it
 - Language reviewer: none (the reviewer reads the language and knows the domain)
 - Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`)
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | A concrete deliverable is defined for every gate | Pass | Deliverable section names concrete output: README, screenshots and wiki in three languages. |
 | 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Go / No-Go table has objectively checkable rows (commands and counts). |
 | 3 | Dependencies on other milestones are explicitly mapped | Pass | Dependencies table is filled. |
 | 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Traceability cites [BC-001] objectives. |
 | 5 | Milestone owner and approving reviewer are identified | Pass | Owner and approving reviewer are S01. |
 | 6 | Milestone has a defined target date consistent with project constraints | Pass | Target date lies inside the Project Plan window; the Business Case sets no calendar constraint. |
 ## Language and Domain Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | The Metadata table has a `Language` row and a `Domain` row, and neither is a placeholder | Pass | `Language | en` and `Domain | it` are in the Metadata table. |
 | 2 | `Language` is a BCP 47 code and `Domain` is a value from the registry's domain list | Pass | `en` is a BCP 47 code; `it` is in the registry's domain list. |
 | 3 | The content (prose and table cells) is written in the stated language | Pass | All prose and table cells are English; the course title is quoted source text. Checked by the stand-in reviewer, who reads English. |
 | 4 | The register matches the one the registry gives for the artifact type | Pass | The registry gives IT Executive English for this type; the text matches it. |
 | 5 | Domain terms are the PO terms of the domain's dictionary, with no synonyms | Pass | No dictionary (`DICT`) exists yet; the terms letter, code word and NATO alphabet are used consistently with no synonyms. Checked by the stand-in; open to challenge. |
 | 6 | Metadata keys, section headings, IDs and statuses are in English | Pass | Metadata keys, headings, IDs and statuses are English. |
 | 7 | No translated twin (`<name>.<language>.md`) exists beside the document | Pass | No translated twin of the file exists. |
 | 8 | A change of language or domain since the previous accepted version has a Version History row and was reviewed again | Pass | First version; no change of language or domain. |
 | 9 | A reviewer competent in the domain, and in the language, has confirmed that the domain terms are used correctly | Pass | The domain is software and IT and the language English; the reviewer stood in for (S01) reads both. A person may challenge this in the run summary. |
 | 10 | Abbreviations are spelled out on first use, in the stated language | Pass | Abbreviations are spelled out on first use or are identifiers (IDs, tool names). |
 ## Overall Verdict
 Go — every Mandatory criterion of QC-MIL-001 and of QC-LANG-001 passes. The review is a stand-in review by the author's AI and is not independent; it is open to challenge in the run summary.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | S01 | n/a |
 ---
 [MIL-003]: ../../milestones/mil-003-documentation-and-publication.md
 [QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
 [QC-LANG-001]: ../../../framework/qc/artifacts/qc-language-domain.md
@@ -0,0 +1,55 @@
 # Traceability Matrix
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | TM-001 |
 | CrossReference | [BC-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | pending |
 ---
 ## Purpose
 Tracks backward/forward links between artifact instances so that the Business Case's
 cross-artifact traceability success criterion is measurable. A row is added or
 updated whenever an artifact instance is created or reviewed.
 ## Purpose
 Tracks backward and forward links between artifact instances so that the cross-artifact traceability can be checked. A row is added or updated whenever an artifact instance is created or reviewed.
 ## 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], [MIL-001], [MIL-002], [MIL-003] | [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], [MIL-002], [MIL-003] | - |
 | [MIL-001] | Milestone | en | it | [BC-001], [PP-001] | [MIL-002] | [RC-003] |
 | [MIL-002] | Milestone | en | it | [BC-001], [MIL-001] | [MIL-003] | [RC-004] |
 | [MIL-003] | Milestone | en | it | [BC-001], [MIL-002] | - | [RC-005] |
 ## Coverage Notes
 - `-` in Upstream means foundational; in Downstream it means nothing is built on it yet; in Last Reviewed it means no review record exists.
 - PP-001 has no QC checklist yet; it is accepted by the Product Owner's stand-in.
 - Use cases, user stories and design artifacts are added in MIL-002.
 ---
 [BC-001]: ../business-case.md
 [MIL-001]: ../milestones/mil-001-repository-foundation.md
 [MIL-002]: ../milestones/mil-002-nato-converter.md
 [MIL-003]: ../milestones/mil-003-documentation-and-publication.md
 [PP-001]: ../project-plan.md
 [RC-001]: ./reviews/rc-001-business-case.md
 [RC-002]: ./reviews/rc-002-stakeholder-analysis.md
 [RC-003]: ./reviews/rc-003-mil-001.md
 [RC-004]: ./reviews/rc-004-mil-002.md
 [RC-005]: ./reviews/rc-005-mil-003.md
 [SA-001]: ../stakeholder-analysis.md
@@ -0,0 +1,78 @@
 # 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-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version, reviewed in RC-002 | pending |
 ---
 ## Purpose
 Identify who has a stake in the NATO alphabet project, how much power and interest each has, and what each needs from the repository. The analysis uses the power/interest grid and maps concerns to FURPS+ (Functionality, Usability, Reliability, Performance, Supportability, plus constraints).
 ## 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 | A correct, complete and well-structured solution that is easy to maintain |
 | S02 | Udemy coursists | Fellow course participants who share 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 browsing the repository for ideas | Public | LOW | MEDIUM | Keep Informed | A clear repository description, topics and README, and no runtime dependencies |
 ## Power/Interest Classification Rationale
 - **Manage Closely (S01):** decides scope, reviews and accepts every artifact, and is the only person who talks to the other stakeholders.
 - **Keep Informed (S02, S03):** they cannot change the project but are its intended readers; their needs are met through the README, the wiki and the code itself. S02 has high interest because the repository is aimed at them; S03 is a passer-by with medium interest.
 ## Primary Concerns and FURPS+ Mapping
 | ID | Concern | FURPS+ attribute |
 | --- | --- | --- |
 | S01 | Program converts words correctly and the structure follows the framework | Functionality, Supportability |
 | S01 | Tests and CI give confidence | Reliability |
 | S02 | Code is readable and keeps the assignment's function names | Supportability |
 | S02 | The README tells how to create the `.venv` and run program and tests | Usability |
 | S03 | Description, topics and README explain the repository at a glance | Usability |
 | S03 | No runtime dependencies to install | Plus: implementation constraint |
 ## Communication Requirements
 | ID | Channel | Frequency | Deliverable | Phase / Milestone |
 | --- | --- | --- | --- | --- |
 | S01 | Chat and pull request review | Per milestone | Pull request with review record and run summary | Every milestone |
 | S02 | README and wiki | When the documentation milestone ships | Run instructions, screenshots, wiki in en, da, ms | MIL-003 |
 | S03 | Repository page (description, topics, README) | Once | Description, topics, README | MIL-001, MIL-003 |
 ## Conflicting Interests and Mitigations
 | Conflict | Stakeholders | Mitigation |
 | --- | --- | --- |
 | S01 follows the lecture, which uses Pandas; S03 wants no runtime dependencies | S01, S03 | Use the standard library `csv` module; the dictionary comprehension is unchanged. Recorded in an architecture decision record (ADR) |
 | The assignment's function names vs. the project's naming conventions | S02, S01 | Keep the assignment's function names in the public API; internal helpers follow the conventions |
 ## Traceability Analysis
 ### Business Goal Alignment
 | Stakeholder | Concern | Business Case objective |
 | --- | --- | --- |
 | S01 | Correct program with project structure | [BC-001] O1, O2 |
 | S01 | Tests and CI | [BC-001] O3 |
 | S02 | Readable code, run instructions | [BC-001] O1, O2, O4 |
 | S03 | Presentation and no dependencies | [BC-001] O4, O5 |
 ## Sign-Off
 Reviewer: S01 (in autonomous mode the AI acts as S01's stand-in; the review record states this).
 ---
 [BC-001]: ./business-case.md