Link synced milestones in the project plan

Add the Gitea milestone links (ids 43 to 45) to the Gateway Schedule after the issue sync: MIL-001 -> #3 to #8, MIL-002 -> #9 to #14, MIL-003 -> #15 to #20. Refs: #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Resolve pending commit links in planning documents
2026-10-05 13:49:30 +08:00 · 2026-10-05 13:41:48 +08:00 · 2026-10-05 13:41:36 +08:00
32 changed files with 1701 additions and 74 deletions
@@ -18,6 +18,13 @@ document of a type. `Primary File` may contain a glob (e.g.
 | US | User Story | docs/user-stories.md | 002 |
 | UC | Use Case | docs/uc-*/uc.md | 002 |
 | SSD | System Sequence Diagram | docs/uc-*/ssd.md | 002 |
 | OC | Operation Contract | docs/uc-*/oc.md | 002 |
 | SD | Sequence Diagram | docs/uc-*/sd.md | 002 |
 | DM | Domain Model | docs/domain-model.md | 003 |
 | DICT | Domain Dictionary (PO and IT terms) | docs/dictionary.md | 002 |
 | UCD | Use Case Diagram | docs/use-case-diagram.md | 002 |
 | RC | SQA Review Record | docs/sqa/reviews/rc-*.md | 016 |
 | TM | Traceability Matrix | docs/sqa/traceability-matrix.md | 002 |
 ## Languages
@@ -4,12 +4,13 @@
 | Key | Value |
 | --- | --- |
 | ID | BC-001 |
-| CrossReference | [SA-001] |
+| CrossReference | [SA-001], [UCD-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
+| 2026-10-05 | Deprecated | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Optional GitHub; choosing GitHub applies the AGPL license to the Gitea repository<br>Cited UCD-001<br>Justified the qualitative cost-benefit; stakeholder roles replaced by interests; success criteria 2 and 3 reworded for optional GitHub<br>Added objective 7 (documentation) and its success criterion | [02875ae] |
 ---
@@ -33,12 +34,13 @@ One repeatable, reviewed procedure gives every new project the same secure basel
 ## Objectives
-1. Create an empty GitHub repository under a chosen user or organization.
+1. Optionally create an empty GitHub repository under a chosen user or organization.
-2. Create a matching empty Gitea repository under a chosen user or organization.
+2. Create a Gitea repository under a chosen user or organization, empty, or with the AGPL license when GitHub is chosen.
-3. Configure the Gitea repository as a push mirror to GitHub (direction Gitea to GitHub).
+3. When GitHub was chosen, configure the Gitea repository as a push mirror to GitHub (direction Gitea to GitHub).
-4. Create the local project directory with `origin` (Gitea) and `github` remotes that contain no credentials.
+4. Create the local project directory with an `origin` (Gitea) remote and, when GitHub was chosen, a `github` remote, neither containing credentials.
 5. Add the SQA-QC-Framework as the `framework` submodule, install its skills and git hooks, and copy its templates, optionally enabling the plan gate.
 6. Never print or persist a token, and never overwrite existing files or directories without consent.
 7. Document installation, configuration, usage, security decisions and error handling in clear English for GitHub readers.
 ## Scope
@@ -46,7 +48,7 @@ One repeatable, reviewed procedure gives every new project the same secure basel
 - `create-project.sh`, `config.env.example`, `.env.example`, `.gitignore` and `README.md`.
 - Safe parsing and validation of `config.env` and `.env` (never `source`d).
- Prompts for name, description, visibility and owner on both hosts.
+- Prompts for name, description, visibility and owner on each chosen host, and whether to use GitHub (which also applies the AGPL license).
 - Checks for required tools (`git`, `curl`, optional `jq`) before any change.
 - A check that the project name is not already taken on GitHub.
 - Partial-failure reporting with a documented way to continue.
@@ -81,11 +83,12 @@ Supports developing on self-hosted Gitea while publishing to GitHub, and adoptin
 | # | Criterion | Target | Measure |
 | --- | --- | --- | --- |
 | 1 | Credential exposure | 0 occurrences of a token in output, saved remote URLs, config files or leftover temp files | Test run with log review; `git config --get-regexp remote` inspected |
-| 2 | Repository ownership | Both repositories are created under the owner chosen at the prompt, never silently under `GITHUB_USER` | Test run with a user owner and with an organization owner |
+| 2 | Repository ownership | Each repository created is under the owner chosen at the prompt for that host, never silently under `GITHUB_USER` | Test run with a user owner and with an organization owner |
-| 3 | Mirror direction | Gitea is the source, GitHub the target; a push to `origin` appears on GitHub | Push a test commit and compare |
+| 3 | Mirror direction | When GitHub is chosen, Gitea is the source and GitHub the target; a push to `origin` appears on GitHub | Push a test commit and compare |
 | 4 | Partial failure | When one host fails, the output lists what was created and the command to continue | Forced failure test (invalid token for one host) |
 | 5 | No overwrite | An existing directory or file is never replaced without a yes | Run twice in the same location |
 | 6 | Lint | `shellcheck` reports no errors on `create-project.sh` | `shellcheck create-project.sh` |
 | 7 | Documentation | `README.md` covers installation, configuration, usage, security decisions, error handling and stakeholders | Review by S02 against MIL-003 Go/No-Go criterion 6 |
 ## Risks
@@ -117,12 +120,14 @@ Supports developing on self-hosted Gitea while publishing to GitHub, and adoptin
 | --- | --- |
 | Three planned phases of maintainer time; ongoing maintenance when the GitHub or Gitea API changes | Repeatable secure setup for every future project; fewer setup mistakes; reusable by GitHub readers |
 The assessment is qualitative on purpose: this is internal tooling with no revenue, and there is no measurement of how long the manual setup takes today to compare against. The cost is maintainer time.
 ## Stakeholders
 | Stakeholder ID (SA) | Interest in this project |
 | --- | --- |
-| S01 | Product Owner and maintainer; sets scope and accepts the result |
+| S01 | Sets the scope and accepts the result |
-| S02 | DevOps, cybersecurity and maintainer; reviews credential handling and git host integration |
+| S02 | Reviews credential handling and the git host integration |
 | S03 | Reads and may reuse the published project on GitHub |
 ## Recommendation
@@ -132,4 +137,6 @@ Proceed — the procedure is small, well bounded and removes a repeated, securit
 ---
 [SA-001]: ./stakeholder-analysis.md
 [UCD-001]: ./use-case-diagram.md
 [424f14f]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/424f14f4f5577bb47fea41c8f3a655dca953e6d8
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,59 @@
 # Domain Dictionary (PO and IT terms)
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | DICT-001 |
 | CrossReference | [BC-001], [SA-001], [DM-001], [DM-002] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Initial version, terms of UC-001 | [02875ae] |
 ---
 ## Purpose and Scope
 Maps each Product Owner (PO) term to its professional IT term. PO language: English (`en`), from the registry's `Languages` section. It covers the concepts of [DM-001] and [DM-002].
 ## Dictionary
 | PO term | Language | IT term | Definition | Used as PO term in | Used as IT term in |
 | --- | --- | --- | --- | --- | --- |
 | Maintainer | en | Maintainer | The person who creates a new project. | DM, UC, US | OC, SD |
 | Project | en | ProjectRequest | The new software project being set up, with its name, description and visibility. | DM, UC, US | OC, SD |
 | Configuration | en | Configuration | The service addresses and access tokens set up before starting. | DM, UC | OC, SD |
 | Git Host | en | GitHost | A service that holds repositories: Gitea or GitHub. | DM, UC | OC, SD |
 | Access Token | en | Credential | A secret that lets the Maintainer act on a Git Host; never part of an address. | DM, UC | OC, SD |
 | Owner | en | Owner | The user or organization on a Git Host that owns repositories. | DM, UC | OC, SD |
 | Repository | en | Repository | A place on a Git Host that holds a project's history. | DM, UC | OC, SD |
 | Gitea Repository | en | GiteaRepository | The repository on Gitea; the source of truth. | DM, UC | OC, SD |
 | GitHub Repository | en | GitHubRepository | The repository on GitHub; it receives its content from the mirror. | DM, UC | OC, SD |
 | License | en | LicenseFile | The legal terms file (AGPL-3.0) added to the Gitea repository when GitHub is chosen. | DM, UC | OC, SD |
 | Mirror | en | PushMirror | The push mirror that copies a Gitea repository to a GitHub repository. | DM, UC | OC, SD |
 | Local Project | en | LocalProject | The project directory on the Maintainer's machine. | DM, UC | OC, SD |
 | Remote | en | Remote | A named link from a local project to a repository. | DM, UC | OC, SD |
 | Framework | en | Submodule | The SQA-QC-Framework added to a local project; the IT term names how it is attached. | DM, UC | OC, SD |
 | Framework Setup | en | HookSetup | The skills and git hooks installed from the framework, with the plan gate on or off. | DM, UC | OC, SD |
 | Template | en | Template | A framework file copied into a project. | DM, UC | OC, SD |
 | Summary | en | Summary | The report of what was created, skipped or failed and how to continue. | DM, UC | OC, SD |
 ## 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.
 - `Run`, `ToolCheck`, `PreflightResult` and `PromptSet` appear in [OC-001] but
  have no PO term: they are system concepts, not domain concepts, and are not
  in the Domain Model.
 - A new concept in a Domain Model gets a row here in the same change.
 ---
 [BC-001]: ./business-case.md
 [SA-001]: ./stakeholder-analysis.md
 [DM-001]: ./uc-001/dm.md
 [DM-002]: ./domain-model.md
 [OC-001]: ./uc-001/oc.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,172 @@
 # Domain Model
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | DM-002 |
 | CrossReference | [UC-001], [SSD-001], [DICT-001], [DM-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Initial version, created from [DM-001] (UC-001) | [02875ae] |
 ---
 ## Purpose and Scope
 The consolidated model of the project. Use-case models are scoped views; when one changes, this model is checked and updated in the same change. It currently covers [UC-001] "Create a new project" ([DM-001]), which it was created from. Concept names are the PO terms recorded in [DICT-001].
 ## Diagram
 Concepts, attributes and associations only — no operations.
 ```plantuml
@startuml
 class Maintainer {
  name
 }
 class Project {
  name
  description
  visibility
 }
 class Configuration
 class "Git Host" as GitHost {
  name
  web address
  API address
 }
 class "Access Token" as AccessToken {
  kind
 }
 class Owner {
  name
  kind
 }
 class Repository {
  name
  description
  visibility
  address
 }
 class "Gitea Repository" as GiteaRepository
 class "GitHub Repository" as GitHubRepository
 class License {
  name
 }
 class Mirror {
  interval
  sync on commit
 }
 class "Local Project" as LocalProject {
  directory
 }
 class Remote {
  name
  address
 }
 class Framework {
  name
  address
 }
 class "Framework Setup" as FrameworkSetup {
  plan gate enabled
 }
 class Template {
  name
 }
 class Summary {
  created items
  skipped items
  next steps
 }
 Repository <|-- GiteaRepository
 Repository <|-- GitHubRepository
 Maintainer "1" --> "0..*" Project : creates
 Configuration "1" --> "1..2" GitHost : defines
 Configuration "1" --> "1..2" AccessToken : holds
 AccessToken "1" --> "1" GitHost : gives access to
 GitHost "1" --> "0..*" Owner : has
 Owner "1" --> "0..*" Repository : owns
 Project "1" --> "1" GiteaRepository : is stored in
 Project "1" --> "0..1" GitHubRepository : is also stored in
 GiteaRepository "1" --> "0..1" License : has
 Mirror "1" --> "1" GiteaRepository : copies from
 Mirror "1" --> "1" GitHubRepository : copies to
 Mirror "0..*" --> "1" AccessToken : is authorised by
 LocalProject "1" --> "1" Project : is the working copy of
 LocalProject "1" --> "1..2" Remote : has
 Remote "0..*" --> "1" Repository : points to
 LocalProject "1" --> "1" Framework : includes
 LocalProject "1" --> "1" FrameworkSetup : has
 FrameworkSetup "0..*" --> "1" Framework : is installed from
 Framework "1" --> "1..*" Template : provides
 LocalProject "1" --> "0..*" Template : contains a copy of
 Summary "1" --> "1" Project : reports on
@enduml
 ```
 ## Concept Table
 | Concept | Definition | Attributes | Source (use case / glossary) |
 | --- | --- | --- | --- |
 | Maintainer | The person who creates a new project (S01 or S02) | name | [UC-001] primary actor |
 | Project | The new software project being set up | name, description, visibility | [UC-001] "new project", step 3 |
 | Configuration | The service addresses and access tokens the Maintainer has set up before starting | none | [UC-001] precondition, step 2 "configuration and credentials" |
 | Git Host | A service that holds repositories: Gitea or GitHub | name, web address, API address | [UC-001] steps 5 to 7 "GitHub", "Gitea" |
 | Access Token | A secret that lets the Maintainer act on a Git Host; it is never part of an address | kind | [UC-001] precondition "Gitea token", "GitHub PAT" |
 | Owner | The user or organization on a Git Host that owns repositories | name, kind (user or organization) | [UC-001] step 3 "owner" |
 | Repository | A place on a Git Host that holds a project's history | name, description, visibility, address | [UC-001] steps 5 and 6 "repository" |
 | Gitea Repository | The Repository on Gitea; the source of truth | none beyond Repository | [UC-001] step 6 |
 | GitHub Repository | The Repository on GitHub; receives its content from the Mirror | none beyond Repository | [UC-001] step 5 |
 | License | The legal terms file added to a Gitea Repository (AGPL-3.0) when GitHub is chosen | name | [UC-001] step 6 "AGPL license" |
 | Mirror | The push mirror that copies a Gitea Repository to a GitHub Repository | interval, sync on commit | [UC-001] step 7 "push mirror" |
 | Local Project | The project directory on the Maintainer's machine | directory | [UC-001] step 8 "local project" |
 | Remote | A named link from a Local Project to a Repository (`origin`, `github`) | name, address | [UC-001] step 8 "remote" |
 | Framework | The SQA-QC-Framework added to a Local Project | name, address | [UC-001] step 9 "framework submodule" |
 | Framework Setup | The skills and git hooks installed from the Framework, with the plan gate on or off | plan gate enabled | [UC-001] step 9 "skills and hooks", "plan gate" |
 | Template | A file the Framework provides to copy into a project (`AGENTS.md`, artifact registry) | name | [UC-001] step 9 "templates" |
 | Summary | The report of what was created, skipped or failed and how to continue | created items, skipped items, next steps | [UC-001] step 10 "summary" |
 ## Association Table
 | From | Association (reading direction) | To | Multiplicity |
 | --- | --- | --- | --- |
 | Maintainer | creates | Project | 1 to 0..* |
 | Configuration | defines | Git Host | 1 to 1..2 (GitHub is optional) |
 | Configuration | holds | Access Token | 1 to 1..2 |
 | Access Token | gives access to | Git Host | 1 to 1 |
 | Git Host | has | Owner | 1 to 0..* |
 | Owner | owns | Repository | 1 to 0..* |
 | Project | is stored in | Gitea Repository | 1 to 1 |
 | Project | is also stored in | GitHub Repository | 1 to 0..1 |
 | Gitea Repository | has | License | 1 to 0..1 (1 when GitHub is chosen) |
 | Mirror | copies from | Gitea Repository | 1 to 1 |
 | Mirror | copies to | GitHub Repository | 1 to 1 |
 | Mirror | is authorised by | Access Token | 0..* to 1 |
 | Local Project | is the working copy of | Project | 1 to 1 |
 | Local Project | has | Remote | 1 to 1..2 |
 | Remote | points to | Repository | 0..* to 1 |
 | Local Project | includes | Framework | 1 to 1 |
 | Local Project | has | Framework Setup | 1 to 1 |
 | Framework Setup | is installed from | Framework | 0..* to 1 |
 | Framework | provides | Template | 1 to 1..* |
 | Local Project | contains a copy of | Template | 1 to 0..* |
 | Summary | reports on | Project | 1 to 1 |
 ## Generalizations
 | General | Specializations | Is-a justification |
 | --- | --- | --- |
 | Repository | Gitea Repository, GitHub Repository | Each is a Repository with the same name, visibility and owner rules; they differ in role (source of truth against mirror target) |
 ---
 [UC-001]: ./uc-001/uc.md
 [SSD-001]: ./uc-001/ssd.md
 [DICT-001]: ./dictionary.md
 [DM-001]: ./uc-001/dm.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -9,7 +9,8 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
+| 2026-10-05 | Deprecated | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Optional GitHub; choosing GitHub applies the AGPL license to the Gitea repository<br>Cited US-001.01<br>Target date accepted | [02875ae] |
 ---
@@ -30,6 +31,7 @@ Decide whether the secure base of `create-project.sh` is sound enough to build t
 | 3 | No token appears in stdout, stderr or a log in any test, including failure paths | None found | Any found |
 | 4 | Missing `git` or `curl` stops the script before any change | Stops with a clear message | Continues |
 | 5 | `.env` is ignored by git; both example files contain placeholders only | Verified | Real value present |
 | 6 | All acceptance criteria of US-001.01 in [US-001] are met | Verified | Any unmet |
 ## Dependencies
@@ -41,6 +43,7 @@ Decide whether the secure base of `create-project.sh` is sound enough to build t
 | Business Case objective / KPI / user story | Reference |
 | --- | --- |
 | User story US-001.01 | [US-001] |
 | Objective 6 (no credential exposure, no overwrite) | [BC-001] |
 | Success criteria 1 and 6 | [BC-001] |
@@ -53,7 +56,7 @@ Decide whether the secure base of `create-project.sh` is sound enough to build t
 ## Target Date
-2026-10-16 — proposed; the Business Case sets no deadline.
+2026-10-16 — the Business Case sets no deadline, so it does not constrain this date; accepted together with PP-001.
 ## Tasks
@@ -63,7 +66,7 @@ Decide whether the secure base of `create-project.sh` is sound enough to build t
 | 2 | Script skeleton with strict mode and safe helpers | `set -Eeuo pipefail`, an ERR/EXIT trap, `mktemp` with `umask 077` and cleanup on exit, small single-purpose functions, logging helpers that redact known secret values, and no `rm -rf`. Follow the framework `coding-conventions` Shell rules. | No | |
 | 3 | Safe parser for config.env and .env | Read `KEY=VALUE` lines without `source` or `eval`; accept only whitelisted keys, strip optional quotes, reject control characters, and validate that service URLs are well-formed `https` and that credentials are non-empty. Warn when `.env` is readable by other users. | No | |
 | 4 | Tool check and HTTP helper | Check `git` and `curl` (and optional `jq`, with a fallback parser for the few JSON fields needed) before any change. Wrap `curl` so tokens go through a private curl config file or stdin rather than the command line (visible in process lists), with `--fail-with-body` handling, timeouts, and error messages that carry the HTTP status but never the credential. | No | |
-| 5 | Interactive prompts and input validation | Prompt for repository name, description, visibility and the owner or organization separately for GitHub and Gitea, with defaults taken from configuration. Validate names against both hosts' allowed characters. `GITHUB_USER` is only the authenticating account and is never assumed to be the owner. | Yes | [UC-001] |
+| 5 | Interactive prompts and input validation | Prompt for repository name, description, visibility, whether to also create a GitHub repository (which also applies the AGPL license to the Gitea repository), and the owner or organization separately for Gitea and (if chosen) GitHub, with defaults taken from configuration. Validate names against both hosts' allowed characters. `GITHUB_USER` is only the authenticating account and is never assumed to be the owner. | Yes | [UC-001] |
 | 6 | .gitignore and test harness | Add `.env` and temporary files to `.gitignore`. Add a test harness with stubbed `curl` and `git` that covers parser rejection cases and the no-token-in-output check, run alongside `shellcheck`. | No | |
 ---
@@ -72,3 +75,4 @@ Decide whether the secure base of `create-project.sh` is sound enough to build t
 [US-001]: ../user-stories.md
 [UC-001]: ../uc-001/uc.md
 [424f14f]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/424f14f4f5577bb47fea41c8f3a655dca953e6d8
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -9,28 +9,30 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
+| 2026-10-05 | Deprecated | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Optional GitHub; choosing GitHub applies the AGPL license to the Gitea repository<br>Cited US-001.02<br>Purpose and criterion 1 reworded for optional GitHub<br>Target date accepted | [02875ae] |
 ---
 ## Purpose
-Decide whether the script creates both remote repositories under the correct owners and configures the Gitea to GitHub push mirror reliably, including when something fails halfway.
+Decide whether the script creates the Gitea repository and, if GitHub is chosen, the GitHub repository under the correct owners, and configures the Gitea to GitHub push mirror reliably, including when something fails halfway.
 ## Deliverable
-`create-project.sh` creating an empty GitHub repository and an empty Gitea repository, configuring the push mirror, verifying it, and printing a summary of what exists, with documented token permissions.
+`create-project.sh` creating a Gitea repository (with the AGPL license when GitHub is chosen, otherwise empty) and, if chosen, an empty GitHub repository, configuring the push mirror, verifying it, and printing a summary of what exists, with documented token permissions.
 ## Go / No-Go Criteria
 | # | Criterion (objectively checkable) | Go | No-Go |
 | --- | --- | --- | --- |
-| 1 | Repositories are created under the owner chosen at the prompt, for a user owner and for an organization owner, on both hosts | Both verified | Any under the wrong owner |
+| 1 | Repositories are created under the owner chosen at the prompt, for a user owner and for an organization owner, on each host used | Both verified | Any under the wrong owner |
-| 2 | Both repositories are empty (no README, licence or `.gitignore` generated by the host) | Verified | Any commit present |
+| 2 | The GitHub repository is created empty. The Gitea repository holds only the AGPL license file when GitHub is chosen, otherwise it is empty. Neither has a generated README or `.gitignore` | Verified | Any other commit present |
-| 3 | A commit pushed to Gitea appears on GitHub; nothing flows the other way | Verified | Wrong direction or no sync |
+| 3 | When GitHub is chosen, a commit pushed to Gitea (including the license file) appears on GitHub; nothing flows the other way. When GitHub is not chosen, no GitHub call is made | Verified | Wrong direction, no sync, or a GitHub call without the choice |
 | 4 | Mirror credentials are never part of a remote URL, log or output | None found | Any found |
 | 5 | With an invalid token on one host, the script stops before creating anything or reports exactly what was created and how to continue | Verified | Silent or misleading |
 | 6 | Required token scopes and the `sync_on_commit` limitation are documented | Present in README draft | Missing |
 | 7 | All acceptance criteria of US-001.02 in [US-001] are met | Verified | Any unmet |
 ## Dependencies
@@ -42,6 +44,7 @@ Decide whether the script creates both remote repositories under the correct own
 | Business Case objective / KPI / user story | Reference |
 | --- | --- |
 | User story US-001.02 | [US-001] |
 | Objectives 1, 2 and 3 | [BC-001] |
 | Success criteria 2, 3 and 4 | [BC-001] |
@@ -54,16 +57,16 @@ Decide whether the script creates both remote repositories under the correct own
 ## Target Date
-2026-10-30 — proposed.
+2026-10-30 — the Business Case sets no deadline, so it does not constrain this date; accepted together with PP-001.
 ## Tasks
 | # | Task | Summary | Needs its own Use Case/User Story? | Reference |
 | --- | --- | --- | --- | --- |
-| 1 | Preflight checks before any creation | With read-only calls, verify both tokens (`GET /user` on each host), that the owner exists and the token may create repositories there, and that the name is free on both hosts, so one host is not created and the other refused. Also test SSH to `git.tirsystem.com` on port 10022 (needed for the submodule); its result decides whether `origin` later uses SSH (test passed) or HTTPS (default). | Yes | [UC-001] |
+| 1 | Preflight checks before any creation | With read-only calls, verify the tokens needed for the chosen hosts (`GET /user`; GitHub only when chosen), that the owner exists and the token may create repositories there, and that the name is free on both hosts, so one host is not created and the other refused. Also test SSH to `git.tirsystem.com` on port 10022 (needed for the submodule); its result decides whether `origin` later uses SSH (test passed) or HTTPS (default). | Yes | [UC-001] |
-| 2 | Create the empty GitHub repository | `POST /user/repos` when the owner is the authenticated user, otherwise `POST /orgs/{org}/repos`, with `auto_init` false. Use the visibility from the prompt. Report the HTTP status and a hint on failure, without exposing the token. | Yes | [UC-001] |
+| 2 | Create the empty GitHub repository (optional) | Only when the Maintainer chose GitHub. `POST /user/repos` when the owner is the authenticated user, otherwise `POST /orgs/{org}/repos`, with `auto_init` false. Use the visibility from the prompt. Report the HTTP status and a hint on failure, without exposing the token. | Yes | [UC-001] |
-| 3 | Create the empty Gitea repository | `POST /user/repos` or `POST /orgs/{org}/repos` on the Gitea API base, with `auto_init` false and no template, readme, licence or gitignore. Derive the clone URL from `GITEA_URL` and the selected owner. | Yes | [UC-001] |
+| 3 | Create the Gitea repository, with AGPL license when GitHub is chosen | `POST /user/repos` or `POST /orgs/{org}/repos` on the Gitea API base, with no template, readme or gitignore. When GitHub is chosen, send `license` `AGPL-3.0` (listed by `GET /licenses`; check it exists first) with `auto_init` true so the license file is committed and the repository is not empty; otherwise `auto_init` false and the repository stays empty. Derive the clone URL from `GITEA_URL` and the selected owner. | Yes | [UC-001] |
-| 4 | Configure the Gitea to GitHub push mirror | Call `POST /repos/{owner}/{repo}/push_mirrors` with `remote_address` (the GitHub HTTPS URL built from `GITHUB_WEB_URL` and the GitHub owner, without credentials), `remote_username` (`GITHUB_USER`), `remote_password` (`GITHUB_PAT`), an interval and `sync_on_commit`. Gitea has a known issue where `sync_on_commit` can be ignored on API creation, so read the result back, trigger `push_mirrors-sync`, and report the effective setting. The PAT needs push access to the target repository (classic `repo` scope, or a fine-grained token with Contents write). Stop with a clear error if it is missing. Confirm the mirror feature is enabled on the Gitea server. | Yes | [UC-001] |
+| 4 | Configure the Gitea to GitHub push mirror (when GitHub is chosen) | Skip this step when GitHub was not chosen. Otherwise call `POST /repos/{owner}/{repo}/push_mirrors` with `remote_address` (the GitHub HTTPS URL built from `GITHUB_WEB_URL` and the GitHub owner, without credentials), `remote_username` (`GITHUB_USER`), `remote_password` (`GITHUB_PAT`), an interval and `sync_on_commit`. Gitea has a known issue where `sync_on_commit` can be ignored on API creation, so read the result back, trigger `push_mirrors-sync`, and report the effective setting. The PAT needs push access to the target repository (classic `repo` scope, or a fine-grained token with Contents write). Stop with a clear error if it is missing. Confirm the mirror feature is enabled on the Gitea server. | Yes | [UC-001] |
 | 5 | Partial-failure reporting and resume | Track each step (GitHub repo, Gitea repo, mirror) in a state summary. When a step fails, print what succeeded, what did not, and the exact way to continue. When rerun and the repository already exists and is empty, offer to reuse it instead of failing. Never delete anything automatically. | No | |
 | 6 | Document token permissions and API limitations | Draft the README sections on required GitHub PAT permissions (create in user or org, push), Gitea token scopes (repository write, organization write for org repos), the fact that Gitea stores the mirror password server-side, and the `sync_on_commit` limitation. | No | |
@@ -74,3 +77,4 @@ Decide whether the script creates both remote repositories under the correct own
 [UC-001]: ../uc-001/uc.md
 [MIL-001]: ./mil-001-foundation.md
 [424f14f]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/424f14f4f5577bb47fea41c8f3a655dca953e6d8
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -9,7 +9,8 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
+| 2026-10-05 | Deprecated | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Optional GitHub; choosing GitHub applies the AGPL license to the Gitea repository<br>Cited US-001.03<br>Traces to objective 7<br>Criterion 2 names the framework URL<br>Target date accepted | [02875ae] |
 ---
@@ -25,13 +26,14 @@ Complete `create-project.sh` (local directory, credential-free remotes, framewor
 | # | Criterion (objectively checkable) | Go | No-Go |
 | --- | --- | --- | --- |
-| 1 | `git remote -v` shows `origin` (Gitea) and `github` with no credentials in either URL | Verified | Any credential |
+| 1 | `git remote -v` shows `origin` (Gitea) and, when GitHub was chosen, `github`, with no credentials in any URL; with GitHub chosen the local history contains the license commit | Verified | Any credential, or a missing license commit |
-| 2 | `framework` is a submodule at the configured URL and the install scripts have run once, in the documented order | Verified | Missing or repeated |
+| 2 | `framework` is a submodule of `ssh://git@git.tirsystem.com:10022/TirSystem/SQA-QC-Framework.git` and the install scripts have run once, in the documented order | Verified | Missing or repeated |
 | 3 | An existing directory, `AGENTS.md` or `docs/artifact-registry.md` is never overwritten without a yes | Verified by a second run | Overwritten |
 | 4 | With the plan gate enabled, a commit touching `src/` or `tests/` without a `Task: MIL-NNN#N` trailer is refused | Verified | Accepted |
 | 5 | An existing `core.hooksPath` is reported and not replaced without consent | Verified | Replaced silently |
 | 6 | README covers installation, configuration, usage examples, security decisions, error handling and stakeholders, in clear English | Reviewed by S02 | Section missing |
 | 7 | End-to-end run on disposable repositories passes and the final review records no open security finding | Recorded in an `RC-*` | Open finding |
 | 8 | All acceptance criteria of US-001.03 in [US-001] are met | Verified | Any unmet |
 ## Dependencies
@@ -43,8 +45,9 @@ Complete `create-project.sh` (local directory, credential-free remotes, framewor
 | Business Case objective / KPI / user story | Reference |
 | --- | --- |
-| Objectives 4, 5 and 6 | [BC-001] |
+| User story US-001.03 | [US-001] |
-| Success criteria 1, 5 and 6 | [BC-001] |
+| Objectives 4, 5, 6 and 7 | [BC-001] |
 | Success criteria 1, 5, 6 and 7 | [BC-001] |
 ## Ownership
@@ -55,13 +58,13 @@ Complete `create-project.sh` (local directory, credential-free remotes, framewor
 ## Target Date
-2026-11-13 — proposed.
+2026-11-13 — the Business Case sets no deadline, so it does not constrain this date; accepted together with PP-001.
 ## Tasks
 | # | Task | Summary | Needs its own Use Case/User Story? | Reference |
 | --- | --- | --- | --- | --- |
-| 1 | Create the local project directory and credential-free remotes | After consent, create the directory (refuse to reuse an existing one without a yes), run `git init` on `main`, and add `origin` (Gitea) and `github` using URLs derived from the configured base URLs and the selected owners, with no token in any URL. `origin` uses HTTPS derived from `GITEA_URL`, unless the SSH test from the preflight passed, in which case it uses SSH on port 10022. Do not make a commit. | Yes | [UC-001] |
+| 1 | Create the local project directory and credential-free remotes | After consent, create the directory (refuse to reuse an existing one without a yes), run `git init` on `main`, and add `origin` (Gitea) and, only if GitHub was chosen, `github` using URLs derived from the configured base URLs and the selected owners, with no token in any URL. `origin` uses HTTPS derived from `GITEA_URL`, unless the SSH test from the preflight passed, in which case it uses SSH on port 10022. When the Gitea repository is not empty (GitHub chosen, AGPL license), fetch it and check out its default branch so the local history starts from the license commit. Do not make a commit. | Yes | [UC-001] |
 | 2 | Add the framework submodule | From the project directory run `git submodule add ssh://git@git.tirsystem.com:10022/TirSystem/SQA-QC-Framework.git framework`. Check beforehand that SSH on port 10022 works and stop with an actionable message if not. Document that this SSH access must be configured. | Yes | [UC-001] |
 | 3 | Install skills and git hooks, with optional plan gate | Run `framework/scripts/install-skills.sh` and `install-git-hooks.sh`. The hook installer only sets `core.hooksPath` to `framework/githooks` and is safe to rerun, but it would replace a different existing value, so read the current value first and ask. Offer `--enable-plan-gate` as an optional choice, which requires a `Task: MIL-NNN#N` trailer on commits changing `src/` or `tests/`. | Yes | [UC-001] |
 | 4 | Copy the framework templates without overwriting | Copy `AGENTS-template.md` to `AGENTS.md` and `artifact-registry-template.md` to `docs/artifact-registry.md` after `mkdir -p docs`, asking before replacing an existing file. | Yes | [UC-001] |
@@ -75,3 +78,4 @@ Complete `create-project.sh` (local directory, credential-free remotes, framewor
 [UC-001]: ../uc-001/uc.md
 [MIL-002]: ./mil-002-repositories-and-mirror.md
 [424f14f]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/424f14f4f5577bb47fea41c8f3a655dca953e6d8
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -9,7 +9,8 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
+| 2026-10-05 | Deprecated | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Stories per phase: US-001.01 to US-001.03<br>Dates accepted | [02875ae] |
 ---
@@ -28,9 +29,9 @@ Schedule the three phases that deliver RepoFoundry (`create-project.sh` and its
 | Gateway | Document | Window | Decision date | Owner | Stories | Main deliverable | Milestone |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| Foundation | [MIL-001] | 2026-10-05 to 2026-10-16 | 2026-10-16 | S01 | US-001.01 | Safe skeleton, config parsing, prompts, tests | |
+| Foundation | [MIL-001] | 2026-10-05 to 2026-10-16 | 2026-10-16 | S01 | US-001.01 | Safe skeleton, config parsing, prompts, tests | [Milestone 43] |
-| Repositories and Mirror | [MIL-002] | 2026-10-19 to 2026-10-30 | 2026-10-30 | S02 | US-001.01 | GitHub and Gitea repositories and the push mirror | |
+| Repositories and Mirror | [MIL-002] | 2026-10-19 to 2026-10-30 | 2026-10-30 | S02 | US-001.02 | GitHub and Gitea repositories and the push mirror | [Milestone 44] |
-| Scaffold and Release | [MIL-003] | 2026-11-02 to 2026-11-13 | 2026-11-13 | S01 | US-001.01 | Local project, framework, README, final review | |
+| Scaffold and Release | [MIL-003] | 2026-11-02 to 2026-11-13 | 2026-11-13 | S01 | US-001.03 | Local project, framework, README, final review | [Milestone 45] |
 ```plantuml
@startgantt
@@ -72,11 +73,11 @@ A No-Go moves every later date by the time needed to rework the failed criteria.
 ## Open Issues
- Confirm the proposed dates (S01).
+- Decided: the proposed dates are accepted with this plan (S01 asked for its acceptance on 2026-10-05); a change needs a new Version History row.
 - Decided: `origin` uses HTTPS derived from `GITEA_URL`, unless the SSH test passed, in which case it uses SSH on port 10022.
 - Decided: use case [UC-001] "Create a new project" is created, with [SSD-001]; tasks that implement its steps reference it.
 - Decided: S01 and S02 are both held by one person for now.
- Open: this plan says the script does not make the first commit; confirm.
+- Open: this plan says the script does not make the first commit; confirm before MIL-003 starts.
 ---
@@ -89,3 +90,7 @@ A No-Go moves every later date by the time needed to rework the failed criteria.
 [UC-001]: ./uc-001/uc.md
 [SSD-001]: ./uc-001/ssd.md
 [424f14f]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/424f14f4f5577bb47fea41c8f3a655dca953e6d8
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
 [Milestone 43]: https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry/milestone/43
 [Milestone 44]: https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry/milestone/44
 [Milestone 45]: https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry/milestone/45
@@ -0,0 +1,49 @@
 # SQA Review Record: US-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-001 |
 | CrossReference | [US-001], [QC-US-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version; re-reviewed after UCD-001 and the split into three stories | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [US-001]
 - Checklist used: [QC-US-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Follows INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) | Pass | INVEST check recorded; the only exception (Independent, on US-001.02 and US-001.03) is stated and follows the milestone order. |
 | 2 | Written in "As a / I want / So that" form | Pass | All three statements follow As a / I want / So that. |
 | 3 | Clear, testable acceptance criteria are included | Pass | Three Given/When/Then criteria per story. |
 | 4 | Traceable to a use case or epic | Pass | Each story traces to UC-001 steps and one milestone. |
 | 5 | Story is sized to fit within a single iteration | Pass | Re-checked: the epic was split into three stories, one per milestone, each fitting one two-week phase. |
 | 6 | Story statement avoids technical implementation detail | Pass | Domain terms only (repository, mirror, framework); no tools or commands. |
 | 7 | Role named in the story matches an actor defined in the Use Case Diagram | Pass | The role Maintainer matches the actor in UCD-001 (re-checked after UCD-001 was created). |
 ## Overall Verdict
 Go — All mandatory criteria pass and the optional criterion 5 now passes after the split. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework's independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | Create a Use Case Diagram (UCD-001) and re-check criterion 7 | S01 | Done 2026-10-05 |
 | Split US-001.01 into per-phase stories | S01 | Done 2026-10-05 |
 ---
 [US-001]: ../../user-stories.md
 [QC-US-001]: ../../../framework/qc/qc-user-story.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,53 @@
 # SQA Review Record: UC-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-002 |
 | CrossReference | [UC-001], [QC-UC-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version; criterion 10 re-checked after UCD-001 | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [UC-001]
 - Checklist used: [QC-UC-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Consists of a single, concise paragraph summarizing only the primary success scenario | N-A | Format is Fully Dressed. |
 | 2 | Written as an informal multi-paragraph narrative; may mention some alternate flows without formal structure | N-A | Format is Fully Dressed. |
 | 3 | All standard sections are present: actors, preconditions, postconditions, main success scenario, alternative/exception flows | Pass | Scope, level, primary actor, stakeholders, preconditions, postconditions, main scenario and extensions are present. |
 | 4 | Preconditions and postconditions are explicitly defined | Pass | Preconditions and postconditions are defined. |
 | 5 | Primary actor is explicitly stated | Pass | Primary actor: Maintainer. |
 | 6 | Stakeholders and their interests are stated | Pass | S01, S02 and S03 with their interests. |
 | 7 | Main success scenario is written as clear, numbered steps | Pass | Ten numbered steps; optional steps 5 and 7 are marked. |
 | 8 | Alternative/exception flows correctly reference `<<include>>`/`<<extend>>` use cases where relevant, per UML 2.5.1 | N-A | No include or extend relationships are used. |
 | 9 | Explicit business rules are captured per step where applicable, rather than embedded loosely in narrative text | Pass | Business rules table per step. |
 | 10 | Naming of actors and use case title is consistent with the corresponding Use Case Diagram and User Stories | Pass | Title and actor match US-001 and UCD-001 (re-checked after UCD-001 was created). |
 | 11 | Scope/level (e.g. summary, user-goal, subfunction) is explicitly stated | Pass | Scope RepoFoundry, level user-goal. |
 | 12 | Use case is written from the actor's goal perspective, free of UI or implementation detail | Pass | Written from the Maintainer's goal. A reference to a hooks setting option was reworded during this review; HTTPS or SSH, the submodule and the AGPL license remain because they are the Maintainer's stated requirements. |
 ## Overall Verdict
 Go — All mandatory criteria pass after UCD-001 was created. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework's independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | Create the Use Case Diagram (see RC-001) and re-check criterion 10 | S01 | Done 2026-10-05 |
 ---
 [UC-001]: ../../uc-001/uc.md
 [QC-UC-001]: ../../../framework/qc/qc-use-case.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,48 @@
 # SQA Review Record: SSD-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-003 |
 | CrossReference | [SSD-001], [QC-SSD-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [SSD-001]
 - Checklist used: [QC-SSD-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Input/output messages match the corresponding Use Case's main success scenario step-for-step | Pass | Two operations cover the actor-system exchange of steps 1 to 3; steps 4 to 10 are internal to the system and the SSD says so. |
 | 2 | Actor and System are treated strictly as black boxes (system shown as `:System`) | Pass | Only the Maintainer and `:System` appear. |
 | 3 | Object creation/destruction of the System instance handled explicitly where relevant | Pass | Lifecycle Notes describe one run of the system. |
 | 4 | Return values are shown for operations that produce one, using dashed return arrows | Pass | Dashed returns for the prompt set, the checks and the summary. |
 | 5 | Alternate/exceptional flows are represented separately (or explicitly out of scope noted) | Pass | Failure flows are stated as out of scope. |
 | 6 | Message names are verb phrases consistent with the use case's system responsibilities | Pass | startProjectCreation and provideProjectDetails. |
 | 7 | Diagram references the specific Use Case (name and ID) it depicts | Pass | Names UC-001 and the main success scenario. |
 ## Overall Verdict
 Go — All mandatory criteria pass. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework's independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [SSD-001]: ../../uc-001/ssd.md
 [QC-SSD-001]: ../../../framework/qc/qc-ssd.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,48 @@
 # SQA Review Record: DM-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-004 |
 | CrossReference | [DM-001], [QC-DM-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [DM-001]
 - Checklist used: [QC-DM-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Uses ubiquitous/business language throughout; no technical or implementation jargon (e.g. no "table", "class", "pointer") | Pass | Business terms; `API address` is the only technical word and is the data the Maintainer configures. |
 | 2 | Multiplicities on associations are correct and complete (e.g. `1..*`, `0..1`) | Pass | All 21 associations have both multiplicities, including the optional GitHub paths. |
 | 3 | No operation/method signatures shown — attributes and associations only | Pass | Attributes and associations only. |
 | 4 | Associations are named with an unambiguous reading direction | Pass | Each association has a reading direction. |
 | 5 | Generalization/specialization used correctly, reflecting true "is-a" relationships, not misused for code reuse | Pass | Only Repository specializes into Gitea Repository and GitHub Repository, justified as is-a. |
 | 6 | Every concept traces to a noun phrase found in the use cases or glossary | Pass | The concept table traces every concept to a UC-001 step or precondition. |
 | 7 | Attributes are simple domain data (no foreign-key-like references or object pointers modeled as attributes) | Pass | Attributes are simple data; links are associations. |
 ## Overall Verdict
 Go — All mandatory criteria pass. Project DM checked: see RC-005. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework's independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [DM-001]: ../../uc-001/dm.md
 [QC-DM-001]: ../../../framework/qc/qc-domain-model.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,48 @@
 # SQA Review Record: DM-002
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-005 |
 | CrossReference | [DM-002], [QC-DM-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [DM-002]
 - Checklist used: [QC-DM-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Uses ubiquitous/business language throughout; no technical or implementation jargon (e.g. no "table", "class", "pointer") | Pass | Same wording as DM-001. |
 | 2 | Multiplicities on associations are correct and complete (e.g. `1..*`, `0..1`) | Pass | Same associations as DM-001, all with multiplicities. |
 | 3 | No operation/method signatures shown — attributes and associations only | Pass | No operations. |
 | 4 | Associations are named with an unambiguous reading direction | Pass | Reading directions present. |
 | 5 | Generalization/specialization used correctly, reflecting true "is-a" relationships, not misused for code reuse | Pass | Same single generalization. |
 | 6 | Every concept traces to a noun phrase found in the use cases or glossary | Pass | Sources cite UC-001; no concept without a source. |
 | 7 | Attributes are simple domain data (no foreign-key-like references or object pointers modeled as attributes) | Pass | Same attributes as DM-001. |
 ## Overall Verdict
 Go — Consolidated model created from DM-001; with one use case there is nothing to reconcile and no conflict. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework's independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [DM-002]: ../../domain-model.md
 [QC-DM-001]: ../../../framework/qc/qc-domain-model.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,48 @@
 # SQA Review Record: OC-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-006 |
 | CrossReference | [OC-001], [QC-OC-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [OC-001]
 - Checklist used: [QC-OC-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Method signature is complete: operation name, parameter types, and return type | Pass | Both signatures give name, parameter types and return type. |
 | 2 | Preconditions explicitly list required state before execution | Pass | Preconditions stated; the first operation has none, stated explicitly. |
 | 3 | Postconditions explicitly describe resulting state using Larman's "instance created/associated/attribute modified" style | Pass | Postconditions P1 to P4 and P1 to P13 describe instances created, associated or set. |
 | 4 | Exceptions and error conditions are documented, including the triggering precondition failure | Pass | Exceptions list the failing precondition and the outcome. |
 | 5 | Operation is explicitly traceable to a single SSD message | Pass | One contract per SSD message. |
 | 6 | Contract avoids specifying implementation/algorithmic details (declarative, not procedural) | Pass | Declarative state changes; no algorithm. |
 | 7 | Cross-references the Domain Model classes/associations affected by pre/postconditions | Pass | Uses the IT terms of DICT-001 for the concepts of DM-001. |
 ## Overall Verdict
 Go — All mandatory criteria pass. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework's independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [OC-001]: ../../uc-001/oc.md
 [QC-OC-001]: ../../../framework/qc/qc-operation-contract.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,49 @@
 # SQA Review Record: SD-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-007 |
 | CrossReference | [SD-001], [QC-SD-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [SD-001]
 - Checklist used: [QC-SD-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Message passing strictly follows UML sync/async/return arrow syntax | Pass | Solid arrows for calls and dashed arrows for returns. |
 | 2 | GRASP/GoF patterns applied and explicitly annotated where used (e.g. Controller, Observer, Mediator, Factory) | Pass | Controller, Pure Fabrication, Creator, Facade and Protection from variations are annotated. |
 | 3 | Lifelines show activation bars matching actual processing time/call nesting | Pass | Activations follow the call nesting. |
 | 4 | Object creation and destruction shown with correct UML notation (`create`/`destroy` messages, X on lifeline) | Pass | Creation and destruction are shown for every transient object. Fixed during this review: creation and destruction of the two host clients were missing. |
 | 5 | Diagram realizes the postconditions of a specific Operation Contract | Pass | The coverage tables map every postcondition P1 to P4 and P1 to P13 to a message. |
 | 6 | Responsibility assignment favors low coupling/high cohesion (no god-object receiving all messages) | Pass | The controller only sequences; work sits in the helpers. |
 | 7 | Loop, alt, and opt combined fragments used correctly for conditional/repeated behavior | Pass | `alt` for the license choice, `opt` for the optional GitHub steps. |
 | 8 | Each exception of the realized Operation Contract is shown as an `alt` or `opt` fragment, or its absence is justified | Pass | Failure paths are not drawn and the Responsibility Check says why. |
 ## Overall Verdict
 Go — All mandatory criteria pass after the fix noted at criterion 4. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework's independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [SD-001]: ../../uc-001/sd.md
 [QC-SD-001]: ../../../framework/qc/qc-sequence-diagram.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,48 @@
 # SQA Review Record: DICT-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-008 |
 | CrossReference | [DICT-001], [QC-DICT-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [DICT-001]
 - Checklist used: [QC-DICT-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Every row has a PO term, its language, an IT term and a definition | Pass | All 17 rows are complete. |
 | 2 | Each PO term maps to exactly one IT term and the reverse (no synonyms) | Pass | 17 PO terms map to 17 distinct IT terms. |
 | 3 | Every Domain Model concept has a row, and the Domain Model uses its PO term | Pass | All 17 concepts of DM-001 and DM-002 have a row and the models use the PO terms. |
 | 4 | The Operation Contracts, Sequence Diagrams, Design Class Diagrams and ERD use the IT term, not the PO term | Pass | OC-001 and SD-001 use the IT terms. |
 | 5 | Definitions are written in the PO language and are one sentence | Pass | One sentence each, in English. |
 | 6 | "Used as PO term in" and "Used as IT term in" name artifact types that exist in the project | Pass | Fixed during this review: DCD was removed from the IT-term column because no DCD exists. |
 | 7 | Translated artifacts (`<artifact>.<language>.md`) use the PO terms of the dictionary | N-A | The PO language is English; no translations. |
 ## Overall Verdict
 Go — All mandatory criteria pass. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework's independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [DICT-001]: ../../dictionary.md
 [QC-DICT-001]: ../../../framework/qc/qc-dictionary.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,49 @@
 # SQA Review Record: UCD-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-009 |
 | CrossReference | [UCD-001], [QC-UCD-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [UCD-001]
 - Checklist used: [QC-UCD-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Actors are defined with correct UML stereotypes (e.g. `<<System>>`, `<<Actor>>`) | Pass | Actor `<<Actor>>`, system boundary `<<System>>`. |
 | 2 | System boundary is clearly drawn and labeled | Pass | The boundary is drawn and labelled RepoFoundry. |
 | 3 | Include/extend relationships are used correctly per UML 2.5.1, not as generic "uses" arrows | N-A | No include or extend is used; the Relationships section says why. |
 | 4 | Every actor participates in at least one use case (no orphan actors) | Pass | The only actor, Maintainer, takes part in Create a new project. |
 | 5 | Diagram is traceable to a documented stakeholder need | Pass | The Maintainer is S01 and S02 in SA-001. |
 | 6 | Use case names are verb phrases describing actor goals, not internal system operations | Pass | Create a new project is a verb phrase and a goal. |
 | 7 | Diagram is free of implementation detail (e.g. UI widgets, database tables) | Pass | No tools, screens or tables. |
 | 8 | Actor and use case naming is consistent with corresponding Use Case and User Story documents | Pass | Names match US-001 and UC-001. |
 ## Overall Verdict
 Go — All mandatory criteria pass. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [UCD-001]: ../../use-case-diagram.md
 [QC-UCD-001]: ../../../framework/qc/qc-use-case-diagram.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,49 @@
 # SQA Review Record: BC-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-010 |
 | CrossReference | [BC-001], [QC-BC-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version; re-checked after objective 7 was added | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [BC-001]
 - Checklist used: [QC-BC-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | ROI/Cost-Benefit analysis is quantitative, or where qualitative, is explicitly justified | Pass | Qualitative, and now explicitly justified (internal tooling, no revenue, no baseline). Fixed during this review. |
 | 2 | Risks are identified with documented impact and mitigation | Pass | Six risks, each with impact and mitigation. |
 | 3 | Success criteria are measurable, stating explicit targets rather than vague aspirations | Pass | Seven criteria with targets and measures; criteria 2 and 3 were reworded during this review for the optional GitHub path. |
 | 4 | Scope explicitly separates In Scope vs Out of Scope | Pass | In Scope and Out of Scope are separate subsections. Objective 7 (documentation) was added during the SA-001 review; it is covered by the README scope item and success criterion 7. |
 | 5 | Stakeholders are cross-referenced to Stakeholder Analysis IDs rather than re-described inline | Pass | The Stakeholders table cites S01, S02 and S03 with their interest only. Roles that had been re-described inline were removed during this review. |
 | 6 | Methodology and quality-standard foundation are stated explicitly (e.g. ISO/IEC 25010, Larman) | Pass | The framework, ISO/IEC 25010:2023 and the shell coding conventions are stated. |
 | 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. |
 ## Overall Verdict
 Go — All mandatory criteria pass after the three fixes noted. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [BC-001]: ../../business-case.md
 [QC-BC-001]: ../../../framework/qc/qc-business-case.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,47 @@
 # SQA Review Record: MIL-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-011 |
 | CrossReference | [MIL-001], [QC-MIL-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [MIL-001]
 - Checklist used: [QC-MIL-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | A concrete deliverable is defined for every gate | Pass | The script skeleton with safe parsing, prompts, example files and a test harness. |
 | 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Six criteria, each with an objective Go and No-Go (including all acceptance criteria of US-001.01). |
 | 3 | Dependencies on other milestones are explicitly mapped | Pass | None; it is the first phase. |
 | 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Maps to Business Case objective 6, success criteria 1 and 6, and US-001.01. |
 | 5 | Milestone owner and approving reviewer are identified | Pass | Owner S01, approving reviewer S02. |
 | 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-10-16, matches PP-001. The Business Case sets no duration, so nothing conflicts; the date is accepted together with the plan. |
 ## Overall Verdict
 Go — All mandatory criteria pass. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [MIL-001]: ../../milestones/mil-001-foundation.md
 [QC-MIL-001]: ../../../framework/qc/qc-milestones-gateways.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,49 @@
 # SQA Review Record: PP-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-012 |
 | CrossReference | [PP-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [PP-001]
 - Checklist used: none: no QC checklist exists for PP; the checks below come from the PP reference (Required sections, Validating)
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | Required sections are present in order | Pass | All eight required sections are present, in order. |
 | 2 | Gateway Schedule agrees with each MIL-* (window, decision date, owner) | Pass | Three rows, one per MIL-*; windows, decision dates and owners match each milestone. |
 | 3 | Timeline diagram shows each phase and Go/No-Go decision | Pass | The Gantt has one bar and one Go/No-Go marker per phase. |
 | 4 | Plan fits the Business Case constraint | Pass | The Business Case sets no duration constraint, so there is no conflict; the plan states its dates are accepted by S01. |
 | 5 | Scope Coverage maps each Business Case scope item to a gateway | Pass | Every in-scope item of BC-001 maps to a gateway. |
 | 6 | Dependencies and the effect of a No-Go are stated | Pass | The chain MIL-001, MIL-002, MIL-003 and the effect of a No-Go are stated. |
 | 7 | Owners use stakeholder IDs | Pass | Owners are S01 and S02. |
 | 8 | Stories column matches the stories each gateway delivers | Pass | US-001.01, .02 and .03 match the milestones that deliver them. |
 | 9 | Open Issues is accurate | Pass | Open Issues lists one open item (first commit), assigned to MIL-003. |
 ## Overall Verdict
 Go — All checks pass. PP has no QC checklist, so the checks come from the PP reference (required sections and Validating). Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [PP-001]: ../../project-plan.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,49 @@
 # SQA Review Record: SA-001
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-013 |
 | CrossReference | [SA-001], [QC-SA-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [SA-001]
 - Checklist used: [QC-SA-001]
 - Review date: 2026-10-05
 ## 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 all have Power, Interest and a 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, unique and used by the other artifacts. |
 | 3 | Roles and organizational context are defined with explicit Power and Interest levels, not just narrative description | Pass | Roles and levels are explicit. The organization is recorded as Not stated: the Product Owner gave no organization and none was invented. |
 | 4 | Communication needs (channel, frequency, deliverable type) are mapped to project phases or milestones | Pass | Channel, frequency and deliverable for each stakeholder, tied to MIL-001 to MIL-003. |
 | 5 | Conflicting stakeholder interests are identified with documented mitigation or resolution strategies | Pass | One conflict (convenience against consent prompts) with a mitigation. The mitigation was corrected during this review to point at the UC-001 business rules instead of an undefined option. |
 | 6 | Stakeholder concerns are explicitly traced to Business Case objectives | Pass | Every stakeholder traces to a Business Case objective. S03 had no objective; fixed during this review by adding objective 7 (documentation) to BC-001. |
 | 7 | Primary concerns are expressed in both business language and a recognized quality-attribute mapping (e.g. FURPS+) | Pass | Each concern has a business statement and a FURPS+ attribute. |
 | 8 | Document is understandable and navigable by non-technical stakeholders reviewing their own entry | Pass | Short tables in plain language. |
 ## Overall Verdict
 Go — All mandatory criteria pass after the two fixes noted. Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [SA-001]: ../../stakeholder-analysis.md
 [QC-SA-001]: ../../../framework/qc/qc-stakeholder-analysis.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,47 @@
 # SQA Review Record: MIL-002
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-014 |
 | CrossReference | [MIL-002], [QC-MIL-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [MIL-002]
 - Checklist used: [QC-MIL-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | A concrete deliverable is defined for every gate | Pass | The script creating the repositories and mirror, with a printed summary and documented token permissions. |
 | 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Seven criteria, each with an objective Go and No-Go (including all acceptance criteria of US-001.02). Criterion 1 was reworded during this review for the optional GitHub path. |
 | 3 | Dependencies on other milestones are explicitly mapped | Pass | Depends on MIL-001, with the reason. |
 | 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Maps to Business Case objectives 1 to 3, success criteria 2 to 4, and US-001.02. |
 | 5 | Milestone owner and approving reviewer are identified | Pass | Owner S02, approving reviewer S01. |
 | 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-10-30, matches PP-001; the Business Case sets no duration, so nothing conflicts. |
 ## Overall Verdict
 Go — All mandatory criteria pass after the wording fixes noted (Purpose and criterion 1). Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [MIL-002]: ../../milestones/mil-002-repositories-and-mirror.md
 [QC-MIL-001]: ../../../framework/qc/qc-milestones-gateways.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,47 @@
 # SQA Review Record: MIL-003
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | RC-015 |
 | CrossReference | [MIL-003], [QC-MIL-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Artifact Under Review
 - Instance reviewed: [MIL-003]
 - Checklist used: [QC-MIL-001]
 - Review date: 2026-10-05
 ## Checklist Results
 | # | Criterion | Status | Evidence/Notes |
 | --- | --- | --- | --- |
 | 1 | A concrete deliverable is defined for every gate | Pass | The complete script, the README and a written final review with the external prerequisites. |
 | 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Eight criteria, each with an objective Go and No-Go (including all acceptance criteria of US-001.03). Criterion 2 now names the framework URL; it said only the configured URL, which no configuration key defines. Fixed during this review. |
 | 3 | Dependencies on other milestones are explicitly mapped | Pass | Depends on MIL-002, with the reason. |
 | 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Maps to Business Case objectives 4 to 7, success criteria 1, 5, 6 and 7, and US-001.03. |
 | 5 | Milestone owner and approving reviewer are identified | Pass | Owner S01, approving reviewer S02. |
 | 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-11-13, matches PP-001; the Business Case sets no duration, so nothing conflicts. |
 ## Overall Verdict
 Go — All mandatory criteria pass after the fix noted (criterion 2). Author and reviewer are the same person for now (S01 and S02 are both held by the Maintainer), so the framework independence rule is not met; re-review when a second person takes S02.
 ## Action Items
 | Action | Owner | Due |
 | --- | --- | --- |
 | None | - | - |
 ---
 [MIL-003]: ../../milestones/mil-003-scaffold-and-release.md
 [QC-MIL-001]: ../../../framework/qc/qc-milestones-gateways.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,79 @@
 # Traceability Matrix
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | TM-001 |
 | CrossReference | [BC-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version, UC-001 artifacts and baseline | [02875ae] |
 ---
 ## 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.
 ## Traceability Table
 | Artifact Instance | Type | Upstream (Backward Link) | Downstream (Forward Link) | Last Reviewed (RC-ID) |
 | --- | --- | --- | --- | --- |
 | [BC-001] | BC | - | [SA-001], [PP-001], [MIL-001], [MIL-002], [MIL-003], [US-001], [UCD-001] | [RC-010] |
 | [SA-001] | SA | [BC-001] | [UCD-001], [UC-001], [DICT-001] | [RC-013] |
 | [PP-001] | PP | [BC-001], [SA-001] | [MIL-001], [MIL-002], [MIL-003] | [RC-012] |
 | [MIL-001] | MIL | [BC-001], [PP-001] | [US-001] | [RC-011] |
 | [MIL-002] | MIL | [BC-001], [PP-001] | [US-001] | [RC-014] |
 | [MIL-003] | MIL | [BC-001], [PP-001] | [US-001] | [RC-015] |
 | [UCD-001] | UCD | [BC-001], [SA-001] | [US-001], [UC-001] | [RC-009] |
 | [US-001] | US | [BC-001], [UCD-001], [MIL-001], [MIL-002], [MIL-003] | [UC-001] | [RC-001] |
 | [UC-001] | UC | [UCD-001], [US-001], [SA-001] | [SSD-001], [DM-001] | [RC-002] |
 | [SSD-001] | SSD | [UC-001] | [OC-001] | [RC-003] |
 | [DM-001] | DM | [UC-001], [SSD-001] | [DM-002], [DICT-001], [OC-001] | [RC-004] |
 | [DM-002] | DM | [DM-001] | [DICT-001] | [RC-005] |
 | [DICT-001] | DICT | [BC-001], [SA-001], [DM-001], [DM-002] | [OC-001], [SD-001] | [RC-008] |
 | [OC-001] | OC | [SSD-001], [DM-001] | [SD-001] | [RC-006] |
 | [SD-001] | SD | [OC-001] | - | [RC-007] |
 ## Coverage Notes
 - Reviewed so far: every artifact in the project (see the Last Reviewed column).
 - No Design Class Diagram, ERD, KPI, BMC or BPMN exists yet. `-` in Downstream means nothing is built on the artifact yet.
 ---
 [BC-001]: ../business-case.md
 [SA-001]: ../stakeholder-analysis.md
 [PP-001]: ../project-plan.md
 [MIL-001]: ../milestones/mil-001-foundation.md
 [MIL-002]: ../milestones/mil-002-repositories-and-mirror.md
 [MIL-003]: ../milestones/mil-003-scaffold-and-release.md
 [UCD-001]: ../use-case-diagram.md
 [US-001]: ../user-stories.md
 [UC-001]: ../uc-001/uc.md
 [SSD-001]: ../uc-001/ssd.md
 [DM-001]: ../uc-001/dm.md
 [DM-002]: ../domain-model.md
 [DICT-001]: ../dictionary.md
 [OC-001]: ../uc-001/oc.md
 [SD-001]: ../uc-001/sd.md
 [RC-001]: ./reviews/rc-001-user-story.md
 [RC-002]: ./reviews/rc-002-uc-001.md
 [RC-003]: ./reviews/rc-003-ssd-001.md
 [RC-004]: ./reviews/rc-004-dm-001.md
 [RC-005]: ./reviews/rc-005-dm-002.md
 [RC-006]: ./reviews/rc-006-oc-001.md
 [RC-007]: ./reviews/rc-007-sd-001.md
 [RC-008]: ./reviews/rc-008-dictionary.md
 [RC-009]: ./reviews/rc-009-ucd-001.md
 [RC-010]: ./reviews/rc-010-bc-001.md
 [RC-011]: ./reviews/rc-011-mil-001.md
 [RC-012]: ./reviews/rc-012-pp-001.md
 [RC-013]: ./reviews/rc-013-sa-001.md
 [RC-014]: ./reviews/rc-014-mil-002.md
 [RC-015]: ./reviews/rc-015-mil-003.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -9,7 +9,8 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
+| 2026-10-05 | Deprecated | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Mitigation points to the UC-001 business rules<br>S03 traced to BC objective 7<br>Sign-off recorded | [02875ae] |
 ---
@@ -51,7 +52,7 @@ Identify who is affected by RepoFoundry and what each needs from it, so owners a
 | Conflict | Stakeholders | Mitigation |
 | --- | --- | --- |
-| Convenience of one-step setup against strict consent prompts for every overwrite | S01, S02 | Prompt only where something would be changed; offer `--yes` only for non-destructive steps (to be decided in MIL-001) |
+| Convenience of one-step setup against strict consent prompts for every overwrite | S01, S02 | Prompt only where something would be replaced, as set out in the business rules of [UC-001]; steps that only create new items run without asking |
 ## Traceability Analysis
@@ -61,13 +62,16 @@ Identify who is affected by RepoFoundry and what each needs from it, so owners a
 | --- | --- | --- |
 | S01 | One-command setup | [BC-001] objectives 1–5 |
 | S02 | Credential safety, no overwrite | [BC-001] objective 6 |
-| S03 | Reusable documentation | [BC-001] objective 6 and the README deliverable |
+| S03 | Reusable documentation | [BC-001] objective 7 |
 ## Sign-Off
-Pending review by S02.
+Reviewed in [RC-013] on 2026-10-05: Go.
 ---
 [BC-001]: ./business-case.md
 [UC-001]: ./uc-001/uc.md
 [RC-013]: ./sqa/reviews/rc-013-sa-001.md
 [424f14f]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/424f14f4f5577bb47fea41c8f3a655dca953e6d8
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,172 @@
 # Domain Model (UC-001)
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | DM-001 |
 | CrossReference | [UC-001], [SSD-001], [DICT-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Purpose and Scope
 Covers [UC-001] "Create a new project". The concepts come from the nouns of that use case. Concept names are the PO terms recorded in [DICT-001]; the project-level model that consolidates all use cases is [DM-002].
 ## Diagram
 Concepts, attributes and associations only — no operations.
 ```plantuml
@startuml
 class Maintainer {
  name
 }
 class Project {
  name
  description
  visibility
 }
 class Configuration
 class "Git Host" as GitHost {
  name
  web address
  API address
 }
 class "Access Token" as AccessToken {
  kind
 }
 class Owner {
  name
  kind
 }
 class Repository {
  name
  description
  visibility
  address
 }
 class "Gitea Repository" as GiteaRepository
 class "GitHub Repository" as GitHubRepository
 class License {
  name
 }
 class Mirror {
  interval
  sync on commit
 }
 class "Local Project" as LocalProject {
  directory
 }
 class Remote {
  name
  address
 }
 class Framework {
  name
  address
 }
 class "Framework Setup" as FrameworkSetup {
  plan gate enabled
 }
 class Template {
  name
 }
 class Summary {
  created items
  skipped items
  next steps
 }
 Repository <|-- GiteaRepository
 Repository <|-- GitHubRepository
 Maintainer "1" --> "0..*" Project : creates
 Configuration "1" --> "1..2" GitHost : defines
 Configuration "1" --> "1..2" AccessToken : holds
 AccessToken "1" --> "1" GitHost : gives access to
 GitHost "1" --> "0..*" Owner : has
 Owner "1" --> "0..*" Repository : owns
 Project "1" --> "1" GiteaRepository : is stored in
 Project "1" --> "0..1" GitHubRepository : is also stored in
 GiteaRepository "1" --> "0..1" License : has
 Mirror "1" --> "1" GiteaRepository : copies from
 Mirror "1" --> "1" GitHubRepository : copies to
 Mirror "0..*" --> "1" AccessToken : is authorised by
 LocalProject "1" --> "1" Project : is the working copy of
 LocalProject "1" --> "1..2" Remote : has
 Remote "0..*" --> "1" Repository : points to
 LocalProject "1" --> "1" Framework : includes
 LocalProject "1" --> "1" FrameworkSetup : has
 FrameworkSetup "0..*" --> "1" Framework : is installed from
 Framework "1" --> "1..*" Template : provides
 LocalProject "1" --> "0..*" Template : contains a copy of
 Summary "1" --> "1" Project : reports on
@enduml
 ```
 ## Concept Table
 | Concept | Definition | Attributes | Source (use case / glossary) |
 | --- | --- | --- | --- |
 | Maintainer | The person who creates a new project (S01 or S02) | name | [UC-001] primary actor |
 | Project | The new software project being set up | name, description, visibility | [UC-001] "new project", step 3 |
 | Configuration | The service addresses and access tokens the Maintainer has set up before starting | none | [UC-001] precondition, step 2 "configuration and credentials" |
 | Git Host | A service that holds repositories: Gitea or GitHub | name, web address, API address | [UC-001] steps 5 to 7 "GitHub", "Gitea" |
 | Access Token | A secret that lets the Maintainer act on a Git Host; it is never part of an address | kind | [UC-001] precondition "Gitea token", "GitHub PAT" |
 | Owner | The user or organization on a Git Host that owns repositories | name, kind (user or organization) | [UC-001] step 3 "owner" |
 | Repository | A place on a Git Host that holds a project's history | name, description, visibility, address | [UC-001] steps 5 and 6 "repository" |
 | Gitea Repository | The Repository on Gitea; the source of truth | none beyond Repository | [UC-001] step 6 |
 | GitHub Repository | The Repository on GitHub; receives its content from the Mirror | none beyond Repository | [UC-001] step 5 |
 | License | The legal terms file added to a Gitea Repository (AGPL-3.0) when GitHub is chosen | name | [UC-001] step 6 "AGPL license" |
 | Mirror | The push mirror that copies a Gitea Repository to a GitHub Repository | interval, sync on commit | [UC-001] step 7 "push mirror" |
 | Local Project | The project directory on the Maintainer's machine | directory | [UC-001] step 8 "local project" |
 | Remote | A named link from a Local Project to a Repository (`origin`, `github`) | name, address | [UC-001] step 8 "remote" |
 | Framework | The SQA-QC-Framework added to a Local Project | name, address | [UC-001] step 9 "framework submodule" |
 | Framework Setup | The skills and git hooks installed from the Framework, with the plan gate on or off | plan gate enabled | [UC-001] step 9 "skills and hooks", "plan gate" |
 | Template | A file the Framework provides to copy into a project (`AGENTS.md`, artifact registry) | name | [UC-001] step 9 "templates" |
 | Summary | The report of what was created, skipped or failed and how to continue | created items, skipped items, next steps | [UC-001] step 10 "summary" |
 ## Association Table
 | From | Association (reading direction) | To | Multiplicity |
 | --- | --- | --- | --- |
 | Maintainer | creates | Project | 1 to 0..* |
 | Configuration | defines | Git Host | 1 to 1..2 (GitHub is optional) |
 | Configuration | holds | Access Token | 1 to 1..2 |
 | Access Token | gives access to | Git Host | 1 to 1 |
 | Git Host | has | Owner | 1 to 0..* |
 | Owner | owns | Repository | 1 to 0..* |
 | Project | is stored in | Gitea Repository | 1 to 1 |
 | Project | is also stored in | GitHub Repository | 1 to 0..1 |
 | Gitea Repository | has | License | 1 to 0..1 (1 when GitHub is chosen) |
 | Mirror | copies from | Gitea Repository | 1 to 1 |
 | Mirror | copies to | GitHub Repository | 1 to 1 |
 | Mirror | is authorised by | Access Token | 0..* to 1 |
 | Local Project | is the working copy of | Project | 1 to 1 |
 | Local Project | has | Remote | 1 to 1..2 |
 | Remote | points to | Repository | 0..* to 1 |
 | Local Project | includes | Framework | 1 to 1 |
 | Local Project | has | Framework Setup | 1 to 1 |
 | Framework Setup | is installed from | Framework | 0..* to 1 |
 | Framework | provides | Template | 1 to 1..* |
 | Local Project | contains a copy of | Template | 1 to 0..* |
 | Summary | reports on | Project | 1 to 1 |
 ## Generalizations
 | General | Specializations | Is-a justification |
 | --- | --- | --- |
 | Repository | Gitea Repository, GitHub Repository | Each is a Repository with the same name, visibility and owner rules; they differ in role (source of truth against mirror target) |
 ---
 [UC-001]: ./uc.md
 [SSD-001]: ./ssd.md
 [DICT-001]: ../dictionary.md
 [DM-002]: ../domain-model.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,91 @@
 # Operation Contract
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | OC-001 |
 | CrossReference | [SSD-001], [DM-001], [SD-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 Concepts below use the IT terms of [DICT-001] for the PO concepts of [DM-001]. `Run`, `ToolCheck`, `PreflightResult` and `PromptSet` are system concepts with no PO term and are not in the Domain Model.
 ## Contract: startProjectCreation
 | Item | Value |
 | --- | --- |
 | Operation | `startProjectCreation(): PromptSet` |
 | Traces to | `startProjectCreation` in [SSD-001] |
 | Concepts | Run, Configuration, ToolCheck |
 **Preconditions**
 - None; this is the first operation of a Run.
 **Postconditions**
 - P1. A `Run` instance was created.
 - P2. A `Configuration` instance was created from `config.env` and `.env`, with every value validated and the credentials held only in memory.
 - P3. A `ToolCheck` instance was created and associated with the `Run`, recording that `git` and `curl` are present and whether `jq` is present.
 - P4. The `Run` was associated with a `PromptSet` that is returned.
 **Exceptions**
 | Condition (failing precondition) | Outcome |
 | --- | --- |
 | `config.env` or `.env` is missing, or a value is missing or malformed | The `Run` ends with an error naming the key, never its value; nothing was changed |
 | `git` or `curl` is missing | The `Run` ends with an error naming the tool; nothing was changed |
 ## Contract: provideProjectDetails
 | Item | Value |
 | --- | --- |
 | Operation | `provideProjectDetails(name: String, description: String, visibility: Visibility, giteaOwner: Owner, githubOwner: Owner [0..1], directory: Path, enablePlanGate: Boolean): Summary` |
 | Traces to | `provideProjectDetails` in [SSD-001] |
 | Concepts | ProjectRequest, PreflightResult, GiteaRepository, GitHubRepository, LicenseFile, PushMirror, LocalProject, Remote, Submodule, HookSetup, Summary |
 **Preconditions**
 - A `Run` exists and its `Configuration` is valid (from `startProjectCreation`).
 - `githubOwner` is present exactly when the Maintainer chose GitHub.
 **Postconditions**
 - P1. A `ProjectRequest` instance was created with the given attributes and associated with the `Run`.
 - P2. A `PreflightResult` instance was created and associated with the `ProjectRequest`, recording that each token needed for the chosen hosts works, that each owner accepts new repositories, that the name is free on the chosen hosts, that `AGPL-3.0` is offered by Gitea when GitHub was chosen, and the outcome of the SSH test to Gitea on port 10022.
 - P3. A `GiteaRepository` instance was created under `giteaOwner` with the given name, description and visibility, and associated with the `ProjectRequest`.
 - P4. If `githubOwner` is present, a `LicenseFile` instance for `AGPL-3.0` was created and associated with the `GiteaRepository`, so that repository is not empty. Otherwise the `GiteaRepository` has no `LicenseFile` and is empty.
 - P5. If `githubOwner` is present, an empty `GitHubRepository` instance was created under `githubOwner` and associated with the `ProjectRequest`.
 - P6. If `githubOwner` is present, a `PushMirror` instance was created, associated with the `GiteaRepository` as source and the `GitHubRepository` as target, with its effective sync setting recorded, and a first sync was requested.
 - P7. A `LocalProject` instance was created at `directory`, associated with the `ProjectRequest`. If the `GiteaRepository` is not empty, the `LocalProject` holds its history, including the `LicenseFile` commit.
 - P8. A `Remote` named `origin` was associated with the `LocalProject`, pointing at the `GiteaRepository` over SSH if the SSH test passed, otherwise over HTTPS, with no credential in its URL.
 - P9. If `githubOwner` is present, a `Remote` named `github` was associated with the `LocalProject`, pointing at the `GitHubRepository`, with no credential in its URL.
 - P10. A `Submodule` named `framework` was associated with the `LocalProject`.
 - P11. A `HookSetup` instance was associated with the `LocalProject`, recording that skills and git hooks were installed once and, if `enablePlanGate`, that the plan gate was enabled.
 - P12. `AGENTS.md` and `docs/artifact-registry.md` exist in the `LocalProject`, each either newly copied from the framework templates or left as it was because the Maintainer declined to replace it.
 - P13. A `Summary` instance was created listing every created item, every skipped item and the next step for anything that failed, and is returned. It contains no credential.
 **Exceptions**
 | Condition (failing precondition) | Outcome |
 | --- | --- |
 | A token is invalid, an owner refuses new repositories, or the name is taken on a chosen host (P2) | The `Run` ends before P3; nothing was created; the error names the failed check |
 | GitHub was chosen and Gitea does not offer `AGPL-3.0` (P2) | The `Run` ends before P3; nothing was created |
 | `GiteaRepository` creation fails after a `GitHubRepository` was created (P5, P3 ordering) | The `Summary` lists the `GitHubRepository` as created, the `GiteaRepository` as failed and how to continue |
 | `PushMirror` creation fails (P6) | The `Summary` lists both repositories as created, the mirror as failed and how to continue; the local steps are not run |
 | `directory` exists, or a target file exists, and the Maintainer declines replacing it (P7, P12) | That item is skipped and listed in the `Summary` |
 | A different `core.hooksPath` exists and the Maintainer declines replacing it (P11) | Hooks are not installed and this is listed in the `Summary` |
 | SSH to port 10022 fails and the `Submodule` cannot be added (P10) | The `Summary` lists the repositories as created, the submodule as failed, and the SSH prerequisite |
 ---
 [SSD-001]: ./ssd.md
 [DM-001]: ./dm.md
 [DICT-001]: ../dictionary.md
 [SD-001]: ./sd.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,190 @@
 # Sequence Diagram
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | SD-001 |
 | CrossReference | [OC-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 Design objects are conceptual; in `create-project.sh` each becomes a small function group. No Design Class Diagram exists yet.
 ## Sequence: startProjectCreation
 **Realizes:** `startProjectCreation` in [OC-001]
 ### Diagram
 ```plantuml
@startuml
 actor Maintainer
 participant ":ProjectCreator" as PC
 participant ":ConfigLoader" as CL
 participant ":ToolChecker" as TC
 Maintainer -> PC : startProjectCreation()
 activate PC
 create CL
 PC -> CL : load(config.env, .env)
 activate CL
 CL --> PC : configuration
 deactivate CL
 create TC
 PC -> TC : check(git, curl, jq)
 activate TC
 TC --> PC : toolCheck
 deactivate TC
 PC --> Maintainer : promptSet
 deactivate PC
 destroy CL
 destroy TC
@enduml
 ```
 ### Pattern Annotations
 | Pattern (GRASP / GoF) | Applied to | Rationale |
 | --- | --- | --- |
 | Controller (GRASP) | `ProjectCreator` | Receives the system operations and coordinates, without doing the work itself |
 | Pure Fabrication (GRASP) | `ConfigLoader`, `ToolChecker` | No domain concept owns parsing or tool checks; separate small units keep cohesion high |
 | Creator (GRASP) | `ConfigLoader` creates `Configuration` | It holds the data needed to build and validate it |
 ### Postcondition Coverage
 | Postcondition (from contract) | Satisfied by message |
 | --- | --- |
 | P1 Run created | `startProjectCreation` received by `ProjectCreator` |
 | P2 Configuration created and validated | `load(config.env, .env)` |
 | P3 ToolCheck created | `check(git, curl, jq)` |
 | P4 PromptSet returned | `promptSet` return to the Maintainer |
 ### Responsibility Check
 `ProjectCreator` only sequences two calls; parsing and validation sit in `ConfigLoader`, tool detection in `ToolChecker`. No object receives every message.
 ## Sequence: provideProjectDetails
 **Realizes:** `provideProjectDetails` in [OC-001]
 ### Diagram
 ```plantuml
@startuml
 actor Maintainer
 participant ":ProjectCreator" as PC
 participant ":Preflight" as PF
 participant ":GiteaClient" as GT
 participant ":GitHubClient" as GH
 participant ":LocalProjectBuilder" as LB
 participant ":FrameworkInstaller" as FI
 participant ":SummaryReport" as SR
 Maintainer -> PC : provideProjectDetails(name, description, visibility, giteaOwner, githubOwner, directory, enablePlanGate)
 activate PC
 create GT
 PC -> GT : new(configuration)
 opt githubOwner present
  create GH
  PC -> GH : new(configuration)
 end
 create PF
 PC -> PF : check(request)
 activate PF
 PF -> GT : verifyToken(), ownerAccepts(giteaOwner), nameFree(name), hasLicense(AGPL-3.0)
 opt githubOwner present
  PF -> GH : verifyToken(), ownerAccepts(githubOwner), nameFree(name)
 end
 PF --> PC : preflightResult
 deactivate PF
 opt githubOwner present
  PC -> GH : createEmptyRepository(githubOwner, name)
  activate GH
  GH --> PC : gitHubRepository
  deactivate GH
 end
 alt githubOwner present
  PC -> GT : createRepository(giteaOwner, name, license=AGPL-3.0)
 else no GitHub
  PC -> GT : createRepository(giteaOwner, name, license=none)
 end
 activate GT
 GT --> PC : giteaRepository
 deactivate GT
 opt githubOwner present
  PC -> GT : addPushMirror(giteaRepository, gitHubRepository)
  activate GT
  GT -> GT : requestSync()
  GT --> PC : pushMirror
  deactivate GT
 end
 create LB
 PC -> LB : build(directory, giteaRepository, gitHubRepository, sshPassed)
 activate LB
 LB --> PC : localProject (remotes origin, github)
 deactivate LB
 create FI
 PC -> FI : install(localProject, enablePlanGate)
 activate FI
 FI --> PC : submodule, hookSetup, templates
 deactivate FI
 create SR
 PC -> SR : compose(all results)
 SR --> PC : summary
 PC --> Maintainer : summary
 deactivate PC
 destroy PF
 destroy GT
 destroy GH
 destroy LB
 destroy FI
 destroy SR
@enduml
 ```
 ### Pattern Annotations
 | Pattern (GRASP / GoF) | Applied to | Rationale |
 | --- | --- | --- |
 | Controller (GRASP) | `ProjectCreator` | Single entry for the system operation; sequences the steps and stops on the first failure |
 | Pure Fabrication (GRASP) | `Preflight`, `LocalProjectBuilder`, `FrameworkInstaller`, `SummaryReport` | Each groups one responsibility that no domain concept owns |
 | Facade (GoF) | `GiteaClient`, `GitHubClient` | Hide each host's HTTP API and credential handling behind a small interface; tokens never leave them |
 | Protection from variations (GRASP) | Client classes | The `github`-optional and license variations are decided by the controller's `alt` and `opt`, not inside the clients |
 ### Postcondition Coverage
 | Postcondition (from contract) | Satisfied by message |
 | --- | --- |
 | P1 ProjectRequest created | `provideProjectDetails` received by `ProjectCreator` |
 | P2 PreflightResult created | `check(request)` |
 | P3 GiteaRepository created | `createRepository(giteaOwner, name, license)` |
 | P4 LicenseFile when GitHub chosen, otherwise empty | `createRepository(..., license=AGPL-3.0)` and the `alt` branch `license=none` |
 | P5 empty GitHubRepository when chosen | `createEmptyRepository(githubOwner, name)` |
 | P6 PushMirror and first sync | `addPushMirror(...)` and `requestSync()` |
 | P7 LocalProject created, history from Gitea when not empty | `build(directory, ...)` |
 | P8 origin remote (SSH if the test passed, else HTTPS) | `build(..., sshPassed)` |
 | P9 github remote when chosen | `build(...)` |
 | P10 framework Submodule | `install(localProject, ...)` |
 | P11 HookSetup, plan gate if chosen | `install(localProject, enablePlanGate)` |
 | P12 AGENTS.md and registry copied or kept | `install(...)` returning `templates` |
 | P13 Summary created and returned | `compose(all results)` and the final return |
 ### Responsibility Check
 `ProjectCreator` sequences and decides on the optional paths but performs no HTTP, git or file work. Host calls are in the two clients, local work in `LocalProjectBuilder` and `FrameworkInstaller`, reporting in `SummaryReport`, so cohesion stays high and no object receives all messages. Failure handling (exceptions in [OC-001]) is the controller's single stop-and-report rule and is not drawn.
 ---
 [OC-001]: ./oc.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -4,12 +4,13 @@
 | Key | Value |
 | --- | --- |
 | ID | SSD-001 |
-| CrossReference | [UC-001] |
+| CrossReference | [UC-001], [DM-001], [OC-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
+| 2026-10-05 | Rejected | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Optional GitHub; choosing GitHub applies the AGPL license to the Gitea repository<br>Cited OC-001 and DM-001 | [02875ae] |
 ---
@@ -25,7 +26,7 @@ actor Maintainer as A
 participant ":System" as S
 A -> S : startProjectCreation()
 S --> A : prompts for project details
-A -> S : provideProjectDetails(name, description, visibility, githubOwner, giteaOwner, directory, enablePlanGate)
+A -> S : provideProjectDetails(name, description, visibility, giteaOwner, githubOwner, directory, enablePlanGate)
 S --> A : checks passed
 S --> A : creation summary
@enduml
@@ -36,7 +37,7 @@ S --> A : creation summary
 | Step | Message | Parameters | Return | Use case step |
 | --- | --- | --- | --- | --- |
 | 1 | startProjectCreation | none | prompts for project details (after configuration and tool checks) | 1, 2 |
-| 2 | provideProjectDetails | name, description, visibility, githubOwner, giteaOwner, directory, enablePlanGate | checks passed, then a creation summary | 3 to 10 |
+| 2 | provideProjectDetails | name, description, visibility, giteaOwner, githubOwner (optional; given means GitHub is chosen and the Gitea repository gets the AGPL license; omitted means no GitHub and no license), directory, enablePlanGate | checks passed, then a creation summary | 3 to 10 |
 Steps 4 to 9 are internal to the system, so one operation covers them. A consent question (step 8a, 9a, 9b) is a prompt from the system and is out of scope for this diagram; failure flows are out of scope here.
@@ -47,4 +48,7 @@ The system is one script run. It starts with the first operation and ends after
 ---
 [UC-001]: ./uc.md
 [DM-001]: ./dm.md
 [OC-001]: ./oc.md
 [424f14f]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/424f14f4f5577bb47fea41c8f3a655dca953e6d8
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -4,12 +4,13 @@
 | Key | Value |
 | --- | --- |
 | ID | UC-001 |
-| CrossReference | [US-001], [SA-001] |
+| CrossReference | [UCD-001], [US-001], [SA-001], [DM-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
+| 2026-10-05 | Deprecated | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Optional GitHub; choosing GitHub applies the AGPL license to the Gitea repository<br>Cited DM-001 and UCD-001 | [02875ae] |
 ---
@@ -27,23 +28,23 @@
 - **Preconditions:**
  - `config.env` and `.env` exist and are valid.
  - `git` and `curl` are installed.
-  - The Maintainer has a GitHub PAT, a Gitea token and SSH access to Gitea on port 10022.
+  - The Maintainer has a Gitea token, a GitHub PAT (only when GitHub is chosen) and SSH access to Gitea on port 10022.
 - **Postconditions (success guarantee):**
-  - An empty repository exists on GitHub and on Gitea under the chosen owners.
+  - A repository exists on Gitea under the chosen owner. It is empty, or, when the Maintainer chose GitHub, it holds the AGPL license file.
-  - The Gitea repository is a push mirror to GitHub.
+  - When the Maintainer chose to create a GitHub repository, an empty repository exists on GitHub under the chosen owner, the Gitea repository is a push mirror to it, and the AGPL license file reaches GitHub through the mirror.
-  - A local project directory exists with credential-free remotes `origin` (Gitea) and `github`, the `framework` submodule, installed skills and hooks, and the copied templates.
+  - A local project directory exists with credential-free remotes `origin` (Gitea) and, when GitHub was chosen, `github`, the `framework` submodule, installed skills and hooks, and the copied templates.
  - The Maintainer has a summary of what was created.
 ### Main Success Scenario
 1. The Maintainer starts the project creation.
 2. The system loads and validates the configuration and credentials and checks that the required tools exist.
-3. The Maintainer provides the repository name, description, visibility, the GitHub owner, the Gitea owner, the local directory, and whether to enable the plan gate.
+3. The Maintainer provides the repository name, description, visibility, the Gitea owner, whether to also create a GitHub repository (and if so its owner), the local directory, and whether to enable the plan gate.
-4. The system checks that both tokens work, that the owners accept new repositories, that the name is free on both hosts, and whether SSH to Gitea works.
+4. The system checks that the tokens needed for the chosen hosts work, that the owners accept new repositories, that the name is free on those hosts, and whether SSH to Gitea works.
-5. The system creates the empty GitHub repository.
+5. Optional: if the Maintainer chose GitHub, the system creates the empty GitHub repository.
-6. The system creates the empty Gitea repository.
+6. The system creates the Gitea repository. If the Maintainer chose GitHub, the repository is created with the AGPL license file and so is not empty; otherwise it is empty and has no license.
-7. The system configures the Gitea repository as a push mirror to GitHub and verifies it.
+7. Optional: if GitHub was chosen, the system configures the Gitea repository as a push mirror to GitHub and verifies it. A license file in the Gitea repository is pushed to GitHub by the mirror.
-8. The system creates the local project with the `origin` and `github` remotes.
+8. The system creates the local project with the `origin` remote and, if GitHub was chosen, the `github` remote.
 9. The system adds the framework submodule, installs its skills and hooks (and the plan gate if chosen) and copies the templates.
 10. The system reports a summary of what was created.
@@ -52,14 +53,16 @@
 - 2a. A required tool is missing, or a configuration value is missing or malformed:
  1. The system stops before any change and names the problem without showing a credential.
 - 4a. A token is invalid, an owner does not accept the repository, or the name is taken:
-  1. The system stops before creating anything and says which check failed.
+  1. The system stops before creating anything and says which check failed. The GitHub token is only checked when GitHub was chosen.
 - 4c. GitHub was chosen and the Gitea server does not offer the `AGPL-3.0` license:
  1. The system stops before creating anything and names the missing license.
 - 4b. SSH to Gitea does not work:
  1. The system uses HTTPS for `origin` and warns that the framework submodule step will fail until SSH is configured.
 - 5a, 6a, 7a. A step fails after an earlier one succeeded:
  1. The system stops and reports what exists, what failed and how to continue.
 - 8a, 9a. The target directory or a target file already exists:
  1. The system asks the Maintainer before replacing it; on no, it skips that item and reports it.
- 9b. A different `core.hooksPath` is already set:
+- 9b. A different git hooks setup is already configured in the project:
  1. The system asks before replacing it.
 ### Special Requirements / Business Rules
@@ -68,8 +71,10 @@
 | --- | --- |
 | 2, 4 | A token never appears in output, logs, command lines, remote URLs or temporary files left behind |
 | 3 | The GitHub owner and the Gitea owner are chosen separately; `GITHUB_USER` is only the authenticating account |
-| 7 | The mirror direction is Gitea to GitHub |
+| 3, 5, 7 | GitHub is optional; without it no GitHub repository, mirror or `github` remote is created and the GitHub credentials are not required |
-| 8 | `origin` uses HTTPS derived from `GITEA_URL`, or SSH when the SSH test in step 4 passed |
+| 6 | Choosing GitHub applies the AGPL license (key `AGPL-3.0`) to the Gitea repository when it is created, so that repository is not empty; without GitHub there is no license and the repository is empty |
 | 7 | The mirror direction is Gitea to GitHub; the GitHub repository stays empty and receives its content from the mirror |
 | 8 | `origin` uses HTTPS derived from `GITEA_URL`, or SSH when the SSH test in step 4 passed; when the Gitea repository is not empty (GitHub chosen) the local project is created by fetching it, not by an unrelated `git init` history |
 | 8, 9 | Nothing is overwritten or deleted without consent, and no commit is made |
 ### Open Issues
@@ -78,6 +83,9 @@
 ---
 [UCD-001]: ../use-case-diagram.md
 [US-001]: ../user-stories.md
 [SA-001]: ../stakeholder-analysis.md
 [DM-001]: ./dm.md
 [424f14f]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/424f14f4f5577bb47fea41c8f3a655dca953e6d8
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -0,0 +1,57 @@
 # Use Case Diagram
 ## Metadata
 | Key | Value |
 | --- | --- |
 | ID | UCD-001 |
 | CrossReference | [SA-001], [BC-001], [US-001], [UC-001] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Initial version | [02875ae] |
 ---
 ## Purpose and Scope
 The system boundary is RepoFoundry, the `create-project.sh` script. Inside it is one goal: creating a new project. The only actor is the Maintainer. GitHub, Gitea and the framework repository are services the system calls; they are outside the boundary and are not actors, because no use case describes their goals and the Stakeholder Analysis has no stakeholder for them.
 ## Diagram
 ```plantuml
@startuml
 left to right direction
 actor "Maintainer" as M <<Actor>>
 rectangle "RepoFoundry" <<System>> {
  usecase "Create a new project" as UC1
 }
 M --> UC1
@enduml
 ```
 ## Actor Table
 | Actor | Stereotype | Stakeholder ID (SA) | Goals (use cases) |
 | --- | --- | --- | --- |
 | Maintainer | `<<Actor>>` | S01, S02 | Create a new project |
 ## Use Case Table
 | Use Case | Actor(s) | Goal |
 | --- | --- | --- |
 | Create a new project ([UC-001]) | Maintainer | Start a new project with a Gitea repository, optionally a GitHub repository and mirror, and a local project with the SQA-QC-Framework |
 ## Relationships
 | From | Relationship (`<<include>>` / `<<extend>>`) | To | Justification |
 | --- | --- | --- | --- |
 | None | - | - | The optional GitHub steps are steps 5 and 7 of [UC-001], not a separate goal of the Maintainer, so they are not modelled as an `<<extend>>` use case |
 ---
 [SA-001]: ./stakeholder-analysis.md
 [BC-001]: ./business-case.md
 [US-001]: ./user-stories.md
 [UC-001]: ./uc-001/uc.md
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a
@@ -4,46 +4,78 @@
 | Key | Value |
 | --- | --- |
 | ID | US-001 |
-| CrossReference | [BC-001], [MIL-001], [MIL-002], [MIL-003] |
+| CrossReference | [BC-001], [UCD-001], [MIL-001], [MIL-002], [MIL-003] |
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-05 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
+| 2026-10-05 | Deprecated | Jens Tirsvad Nielsen | S02 | Initial version | [424f14f] |
 | 2026-10-05 | Accepted | Jens Tirsvad Nielsen | S02 | Optional GitHub; choosing GitHub applies the AGPL license to the Gitea repository<br>Cited UCD-001<br>Split the epic into three stories, one per milestone | [02875ae] |
 ---
 ## Purpose and Scope
-One epic: setting up a new project on GitHub and Gitea with the SQA-QC-Framework in place. The actor is the Maintainer (S01 or S02; for now one person holds both roles). No Use Case Diagram exists yet, so the actor name is defined here and must be reused by the use case.
+One epic: "Create a new project" ([UC-001]), setting up a new project on Gitea, optionally on GitHub, with the SQA-QC-Framework in place. The actor is the Maintainer, as in [UCD-001] (S01 or S02; for now one person holds both roles).
 The epic is split into three stories, one per milestone. Each story fits one two-week phase and can be shown working at the end of it.
 ## Story List
-### US-001.01 — Create a new project
+### US-001.01 — Create a new project: check and collect
-**As a** Maintainer, **I want** to create a new project with empty GitHub and Gitea repositories, a Gitea to GitHub push mirror and a local project with the SQA-QC-Framework, **so that** every new project starts from the same secure, repeatable baseline.
+**As a** Maintainer, **I want** the script to check my configuration, credentials and tools and ask for the project details before it changes anything, **so that** a mistake or a missing prerequisite is caught early and no token is ever exposed.
 **Acceptance Criteria**
- Given valid configuration and credentials, when the Maintainer answers the prompts, then an empty GitHub repository and an empty Gitea repository exist under the chosen owners.
+- Given `config.env` and `.env`, when the Maintainer starts the script, then the values are read and validated without being executed, and no token appears in any output.
- Given both repositories exist, when the mirror step finishes, then the Gitea repository is a push mirror to GitHub and no credential is stored in any remote URL.
+- Given a missing tool, or a missing or malformed value, when the script starts, then it stops before any change and names the problem without showing a credential.
- Given the repositories exist, when the local step finishes, then the project directory has `origin` (Gitea) and `github` remotes, the `framework` submodule, installed skills and hooks, and the copied templates.
+- Given valid configuration, when the script asks for the details, then the Maintainer can give the repository name, description, visibility, the Gitea owner, whether to also use GitHub (and its owner), the local directory and whether to enable the plan gate.
 - Given a step fails, when the script stops, then it reports what was created and how to continue.
 - Given a target directory or file already exists, when the script would replace it, then it asks first.
 | Traces to | Size | INVEST exceptions |
 | --- | --- | --- |
-| [UC-001], [MIL-001], [MIL-002], [MIL-003] | spans three phases; delivered by the tasks of each | Small: the story is split into tasks per phase |
+| [UC-001] steps 1 to 3, [MIL-001] | fits one phase | none |
 ### US-001.02 — Create a new project: repositories and mirror
 **As a** Maintainer, **I want** the script to create the Gitea repository and, if I chose GitHub, an empty GitHub repository with a mirror from Gitea, **so that** the project starts with its repositories in place under the owners I chose.
 **Acceptance Criteria**
 - Given valid tokens and owners, when the script runs, then a Gitea repository exists under the chosen owner: empty, or holding the AGPL license when GitHub was chosen.
 - Given GitHub was chosen, when the script runs, then an empty GitHub repository exists under its chosen owner (not assumed to be `GITHUB_USER`) and Gitea mirrors to it, and no credential is stored in any address.
 - Given a step fails, when the script stops, then it reports what was created and how to continue.
 | Traces to | Size | INVEST exceptions |
 | --- | --- | --- |
 | [UC-001] steps 4 to 7, [MIL-002] | fits one phase | Independent: needs the checked input of US-001.01 |
 ### US-001.03 — Create a new project: local project
 **As a** Maintainer, **I want** the script to create the local project with its remotes and the SQA-QC-Framework, **so that** I can start work in a ready project.
 **Acceptance Criteria**
 - Given the repositories exist, when the script finishes, then the project directory has an `origin` remote and, if GitHub was chosen, a `github` remote, neither containing a credential.
 - Given the project directory, when the script finishes, then the framework, its skills and git hooks (and the plan gate if chosen) and the copied templates are in place.
 - Given a directory or file already exists, when the script would replace it, then it asks first.
 | Traces to | Size | INVEST exceptions |
 | --- | --- | --- |
 | [UC-001] steps 8 to 10, [MIL-003] | fits one phase | Independent: needs the repositories of US-001.02 |
 ## INVEST Check
-Independent, Negotiable, Valuable, Estimable and Testable hold. Small does not: this is an epic-sized story, delivered through the tasks of the three milestones, with an exception recorded above.
+Valuable, Negotiable, Estimable, Small and Testable hold for each story. Independent holds only in part: the stories are ordered, each using what the one before it delivers, which follows the milestone order in [PP-001]. This is flagged as an exception on US-001.02 and US-001.03.
 ---
 [BC-001]: ./business-case.md
 [UCD-001]: ./use-case-diagram.md
 [UC-001]: ./uc-001/uc.md
 [MIL-001]: ./milestones/mil-001-foundation.md
 [MIL-002]: ./milestones/mil-002-repositories-and-mirror.md
 [MIL-003]: ./milestones/mil-003-scaffold-and-release.md
 [PP-001]: ./project-plan.md
 [424f14f]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/424f14f4f5577bb47fea41c8f3a655dca953e6d8
 [02875ae]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/02875aee5f2953473924074eea0056eb31af6b7a