Throwaway: only the call at @v1

Reviewed-on: #167

.editorconfig

@@ -0,0 +1,7 @@
+# Line endings are LF everywhere (rule 15 of the coding-conventions skill).
+root = true
+
+[*]
+end_of_line = lf
+charset = utf-8
+insert_final_newline = true

.env.example

@@ -1,7 +1,7 @@
-# Copy to .env and fill in real values. .env is gitignored - never commit it.
-
-# Gitea personal access token (Settings -> Applications -> Generate New Token),
-# scoped to issues only if your Gitea version supports scoped tokens.
-# Used by framework/scripts/sync-project.sh --apply against a Gitea remote.
-# NOT a deploy key - deploy keys authenticate git-over-SSH only, not the API.
-GITEA_TOKEN=
+# Copy to .env and fill in real values. .env is gitignored - never commit it.
+
+# Gitea personal access token (Settings -> Applications -> Generate New Token),
+# scoped to issues only if your Gitea version supports scoped tokens.
+# Used by framework/scripts/sync-project.sh --apply against a Gitea remote.
+# NOT a deploy key - deploy keys authenticate git-over-SSH only, not the API.
+GITEA_TOKEN=

.gitattributes

@@ -0,0 +1 @@
+* text=auto eol=lf

.gitea/scoped_workflows/publish-wiki.yml

@@ -1,42 +0,0 @@
-name: Publish wiki
-
-# Shared through scoped delivery: it runs in every repository of an
-# organization, but writes only where the repository has opted in with
-# wiki/.publish (ADR-0004). TOKEN_FOR_GITEA_WIKI is read from the organization
-# secrets; there is no fallback to the read-only sync token. The script is a
-# file of TirSystem/github-action (tools/publish_wiki.py), fetched with a
-# second checkout so that it is readable, lintable and tested as a file
-# (MIL-004 task 6).
-on:
-  push:
-    branches: [ main ]
-    paths:
-      - "wiki/**"
-  workflow_dispatch:
-
-concurrency:
-  group: publish-wiki
-  cancel-in-progress: false
-
-jobs:
-  publish-wiki:
-    permissions:
-      contents: read
-    runs-on: ubuntu-latest
-    steps:
-      - name: Check out the repository
-        uses: actions/checkout@v4
-
-      - name: Fetch the shared script
-        uses: actions/checkout@v4
-        with:
-          repository: TirSystem/github-action
-          ref: v1
-          path: shared-scripts
-
-      - name: Publish the pages to the wiki
-        env:
-          GITEA_API_URL: ${{ gitea.api_url }}
-          SOURCE_REPOSITORY: ${{ gitea.repository }}
-          WIKI_CREDENTIALS: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
-        run: python3 shared-scripts/tools/publish_wiki.py

.gitea/scoped_workflows/sync-github-metadata.yml

@@ -16,9 +16,10 @@ jobs:
     permissions:
       contents: read
     runs-on: ubuntu-latest
+    timeout-minutes: 5
     steps:
       - name: Fetch the shared script
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.2.2
         with:
           repository: TirSystem/github-action
           ref: v1

.gitea/workflows/code-metrics.yml

@@ -0,0 +1,95 @@
+name: Code metrics
+
+# Reusable workflow (ADR-0010). A repository calls it with
+#
+#   on:
+#     push:
+#       branches: [main]
+#   jobs:
+#     metrics:
+#       uses: TirSystem/github-action/.gitea/workflows/code-metrics.yml@v1
+#       permissions:
+#         contents: write
+#
+# It counts the code files and the lines of code of the repository (comment
+# and blank lines are not counted), reads an optional Cobertura XML coverage
+# report (an artifact of an earlier job of the caller, or a file of the
+# repository) and commits three SVG badges to a branch of the calling
+# repository.
+# It runs no test, needs no secret and writes only the badges branch.
+on:
+  workflow_call:
+    inputs:
+      working-directory:
+        description: "Directory, relative to the repository root, whose code is counted"
+        type: string
+        default: "."
+      exclude:
+        description: "Comma list of patterns of files and directories that are not counted, in addition to the defaults of ADR-0010"
+        type: string
+        default: ""
+      coverage-report:
+        description: "Path, relative to the repository root, of a Cobertura XML coverage report; empty writes no coverage badge"
+        type: string
+        default: ""
+      coverage-artifact:
+        description: "Name of an artifact, uploaded by an earlier job of the same run, that holds the coverage report; empty reads coverage-report from the checkout"
+        type: string
+        default: ""
+      coverage-warn:
+        description: "Coverage in percent below which the coverage badge is red"
+        type: string
+        default: "60"
+      coverage-good:
+        description: "Coverage in percent from which the coverage badge is green"
+        type: string
+        default: "80"
+      badges-branch:
+        description: "Branch that holds the badge files; it is created when it does not exist"
+        type: string
+        default: "badges"
+      tools-ref:
+        description: "Tag or branch of TirSystem/github-action whose tools/ files are run; pin it to the exact tag together with the workflow"
+        type: string
+        default: "v1"
+
+jobs:
+  code-metrics:
+    permissions:
+      contents: write
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    env:
+      WORKING_DIRECTORY: ${{ inputs.working-directory }}
+      EXCLUDE: ${{ inputs.exclude }}
+      COVERAGE_REPORT: ${{ inputs.coverage-report }}
+      COVERAGE_ARTIFACT: ${{ inputs.coverage-artifact }}
+      COVERAGE_WARN: ${{ inputs.coverage-warn }}
+      COVERAGE_GOOD: ${{ inputs.coverage-good }}
+      BADGES_BRANCH: ${{ inputs.badges-branch }}
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v4.2.2
+
+      - name: Fetch the shared scripts
+        uses: actions/checkout@v4.2.2
+        with:
+          repository: TirSystem/github-action
+          ref: ${{ inputs.tools-ref }}
+          path: shared-scripts
+
+      - name: Validate the inputs
+        run: bash shared-scripts/tools/code-metrics.sh validate
+
+      - name: Download the coverage report
+        if: ${{ inputs.coverage-artifact != '' }}
+        uses: actions/download-artifact@v4.1.8
+        with:
+          name: ${{ inputs.coverage-artifact }}
+          path: coverage-artifact
+
+      - name: Count the code and write the badges
+        run: bash shared-scripts/tools/code-metrics.sh measure
+
+      - name: Publish the badges
+        run: bash shared-scripts/tools/code-metrics.sh publish

.gitea/workflows/publish-own-wiki.yml

@@ -0,0 +1,25 @@
+name: Publish own wiki
+
+# Publishes the wiki of this repository from docs/wiki/ by calling the
+# reusable workflow of this repository (ADR-0009, MIL-008 task 4). It is the
+# caller a project copies from framework/templates/ci/publish-wiki.yml, with
+# two differences: the reusable workflow is called by its local path, and
+# tools-ref is main so that the script that is run is the one of this commit.
+on:
+  push:
+    branches: [ main ]
+    paths:
+      - "docs/wiki/**"
+  workflow_dispatch:
+
+jobs:
+  wiki:
+    permissions:
+      contents: read
+    uses: ./.gitea/workflows/publish-wiki-pages.yml
+    with:
+      wiki_dir: docs/wiki
+      prune: "true"
+      tools-ref: main
+    secrets:
+      TOKEN_FOR_GITEA_WIKI: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}

.gitea/workflows/publish-wiki-pages.yml

@@ -0,0 +1,64 @@
+name: Publish wiki
+
+# Reusable workflow (ADR-0009, MIL-008). A repository calls it with
+#
+#   on:
+#     push:
+#       branches: [ main ]
+#       paths: [ "docs/wiki/**" ]
+#   jobs:
+#     wiki:
+#       uses: TirSystem/github-action/.gitea/workflows/publish-wiki-pages.yml@v1
+#       secrets:
+#         TOKEN_FOR_GITEA_WIKI: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
+#
+# The caller file is the opt-in; there is no marker file. It publishes the
+# Markdown pages of wiki_dir to the wiki of the calling repository, creating
+# and updating pages, and deleting pages that are not in the folder only when
+# prune is true. The script is a file of this repository
+# (tools/publish_wiki.py), fetched at tools-ref.
+on:
+  workflow_call:
+    inputs:
+      wiki_dir:
+        description: "Directory, relative to the repository root, with the wiki pages"
+        type: string
+        default: "docs/wiki"
+      prune:
+        description: "true deletes wiki pages that are not in the folder; false keeps them"
+        type: string
+        default: "false"
+      tools-ref:
+        description: "Tag or branch of TirSystem/github-action whose tools/publish_wiki.py is run; pin it to the exact tag together with the workflow"
+        type: string
+        default: "v1"
+    secrets:
+      TOKEN_FOR_GITEA_WIKI:
+        description: "Gitea token with write access to the wiki of the calling repository"
+        required: true
+
+jobs:
+  publish-wiki:
+    permissions:
+      contents: read
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v4.2.2
+
+      - name: Fetch the shared script
+        uses: actions/checkout@v4.2.2
+        with:
+          repository: TirSystem/github-action
+          ref: ${{ inputs.tools-ref }}
+          path: shared-scripts
+
+      - name: Publish the pages to the wiki
+        env:
+          GITEA_API_URL: ${{ gitea.api_url }}
+          SOURCE_REPOSITORY: ${{ gitea.repository }}
+          WIKI_CREDENTIALS: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
+          WIKI_DIR: ${{ inputs.wiki_dir }}
+          WIKI_PRUNE: ${{ inputs.prune }}
+        run: python3 shared-scripts/tools/publish_wiki.py

.gitea/workflows/quality-checks-cpp.yml

@@ -0,0 +1,72 @@
+name: Quality checks C++
+
+# Reusable workflow (ADR-0008). A repository calls it with
+#
+#   jobs:
+#     quality:
+#       uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1
+#
+# It checks the C and C++ files of the repository with clang-format and
+# clang-tidy at exact versions, changes no file and needs no secret. The
+# repository needs a .clang-format; a .clang-tidy and a compile database
+# (compile-commands-dir) are optional.
+on:
+  workflow_call:
+    inputs:
+      working-directory:
+        description: "Directory, relative to the repository root, whose files are checked"
+        type: string
+        default: "."
+      std:
+        description: "C++ standard for clang-tidy when no compile database is given, such as c++20"
+        type: string
+        default: "c++20"
+      compile-commands-dir:
+        description: "Directory with a compile_commands.json built by the caller before the call; empty uses the std input"
+        type: string
+        default: ""
+      clang-format-version:
+        description: "Exact version of the clang-format package"
+        type: string
+        default: "23.1.3"
+      clang-tidy-version:
+        description: "Exact version of the clang-tidy package"
+        type: string
+        default: "22.1.8"
+      tools-ref:
+        description: "Tag or branch of TirSystem/github-action whose tools/quality-checks-cpp.sh is run; pin it to the exact tag together with the workflow"
+        type: string
+        default: "v1"
+
+jobs:
+  quality-checks-cpp:
+    permissions:
+      contents: read
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    env:
+      WORKING_DIRECTORY: ${{ inputs.working-directory }}
+      STD: ${{ inputs.std }}
+      COMPILE_COMMANDS_DIR: ${{ inputs.compile-commands-dir }}
+      CLANG_FORMAT_VERSION: ${{ inputs.clang-format-version }}
+      CLANG_TIDY_VERSION: ${{ inputs.clang-tidy-version }}
+      QC_VENV: /tmp/quality-tools
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v4.2.2
+
+      - name: Fetch the shared script
+        uses: actions/checkout@v4.2.2
+        with:
+          repository: TirSystem/github-action
+          ref: ${{ inputs.tools-ref }}
+          path: shared-scripts
+
+      - name: Validate the inputs
+        run: bash shared-scripts/tools/quality-checks-cpp.sh validate
+
+      - name: Install the tools
+        run: bash shared-scripts/tools/quality-checks-cpp.sh install
+
+      - name: Run the checks
+        run: bash shared-scripts/tools/quality-checks-cpp.sh run

.gitea/workflows/quality-checks-csharp.yml

@@ -0,0 +1,61 @@
+name: Quality checks C#
+
+# Reusable workflow (ADR-0008). A repository calls it with
+#
+#   jobs:
+#     quality:
+#       uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1
+#
+# It checks the C# solution or project of the repository with `dotnet format`
+# and `dotnet build` (warnings as errors) on an exact .NET SDK 10 or later,
+# changes no file and needs no secret. The package restore needs the network.
+on:
+  workflow_call:
+    inputs:
+      working-directory:
+        description: "Directory, relative to the repository root, whose files are checked"
+        type: string
+        default: "."
+      project:
+        description: "Solution or project file, relative to working-directory; empty uses the single .sln, .slnx or .csproj found"
+        type: string
+        default: ""
+      dotnet-sdk-version:
+        description: "Exact .NET SDK version, 10 or later (no channel, no range)"
+        type: string
+        default: "10.0.401"
+      tools-ref:
+        description: "Tag or branch of TirSystem/github-action whose tools/quality-checks-csharp.sh is run; pin it to the exact tag together with the workflow"
+        type: string
+        default: "v1"
+
+jobs:
+  quality-checks-csharp:
+    permissions:
+      contents: read
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    env:
+      WORKING_DIRECTORY: ${{ inputs.working-directory }}
+      PROJECT: ${{ inputs.project }}
+      DOTNET_SDK_VERSION: ${{ inputs.dotnet-sdk-version }}
+      DOTNET_ROOT: /tmp/dotnet
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v4.2.2
+
+      - name: Fetch the shared script
+        uses: actions/checkout@v4.2.2
+        with:
+          repository: TirSystem/github-action
+          ref: ${{ inputs.tools-ref }}
+          path: shared-scripts
+
+      - name: Validate the inputs
+        run: bash shared-scripts/tools/quality-checks-csharp.sh validate
+
+      - name: Install the .NET SDK
+        run: bash shared-scripts/tools/quality-checks-csharp.sh install
+
+      - name: Run the checks
+        run: bash shared-scripts/tools/quality-checks-csharp.sh run

.gitea/workflows/quality-checks.yml

@@ -45,6 +45,7 @@ jobs:
     permissions:
       contents: read
     runs-on: ubuntu-latest
+    timeout-minutes: 15
     env:
       LANGUAGES: ${{ inputs.languages }}
       WORKING_DIRECTORY: ${{ inputs.working-directory }}
@@ -55,10 +56,10 @@ jobs:
       QC_VENV: /tmp/quality-tools
     steps:
       - name: Check out the repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.2.2
 
       - name: Fetch the shared script
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.2.2
         with:
           repository: TirSystem/github-action
           ref: ${{ inputs.tools-ref }}

.gitea/workflows/release.yml

@@ -26,9 +26,10 @@ jobs:
     permissions:
       contents: write
     runs-on: ubuntu-latest
+    timeout-minutes: 15
     steps:
       - name: Check out the repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.2.2
 
       - name: Check and publish the release
         env:

.gitea/workflows/sync-milestones.yml

@@ -0,0 +1,78 @@
+# Publish accepted milestones to the git host.
+#
+# On a push to main that changes docs/milestones/ or docs/sqa/reviews/, this
+# workflow runs `sync-project.sh --accepted-only --apply`: every milestone whose
+# latest Version History row is Accepted and whose latest review record is a Go
+# is created or updated as a Milestone with its tasks as Issues. A Proposed
+# milestone, or one without a Go review, is skipped. Nothing is closed or
+# deleted. Each run updates the issues of every accepted milestone (the sync is
+# idempotent, but the host records the edit).
+#
+# INSTALLING THIS FILE IS THE STANDING AUTHORIZATION TO PUBLISH. This project
+# installed it on 2026-10-11 at the request of S01.
+#
+# Secret: TOKEN_FOR_GITEA, the bare Gitea token of the organization (no JSON).
+# It needs read and write on issues and milestones, and read on the framework
+# repository, which is checked out as a submodule. Gitea does not accept secret
+# names that start with GITEA_ or GITHUB_.
+#
+# Run it once by hand from the Actions page with dry_run left on: it prints
+# the plan and creates nothing. Turn dry_run off only for a real run.
+# A runner must be registered for the repository (or its organisation).
+
+name: Publish accepted milestones
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - "docs/milestones/**"
+      - "docs/sqa/reviews/**"
+  workflow_dispatch:
+    inputs:
+      dry_run:
+        description: "Preview only: print the plan and create nothing"
+        type: boolean
+        default: true
+
+# Two merges in a row queue instead of racing.
+concurrency:
+  group: publish-accepted-milestones
+  cancel-in-progress: false
+
+jobs:
+  publish:
+    permissions:
+      contents: read
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    steps:
+      - name: Check out the project
+        uses: actions/checkout@v4.2.2
+        with:
+          token: ${{ secrets.TOKEN_FOR_GITEA }}
+
+      # .gitmodules uses ssh:// URLs and the runner has no SSH key, so the
+      # submodules (framework, and framework/qc inside it) are fetched over HTTPS
+      # with the same token. The token goes through the environment, not a
+      # command line.
+      - name: Check out the framework submodules over HTTPS
+        env:
+          GIT_CONFIG_COUNT: "2"
+          GIT_CONFIG_KEY_0: "url.https://git.tirsystem.com/.insteadOf"
+          GIT_CONFIG_VALUE_0: "ssh://git@git.tirsystem.com:10022/"
+          GIT_CONFIG_KEY_1: "http.extraheader"
+          GIT_CONFIG_VALUE_1: "Authorization: token ${{ secrets.TOKEN_FOR_GITEA }}"
+        run: |
+          set -euo pipefail
+          git submodule update --init --recursive --depth=1
+
+      - name: Make sure curl and jq are available
+        run: bash framework/scripts/ci-publish-milestones.sh ensure-tools
+
+      - name: Publish accepted milestones
+        env:
+          GITEA_TOKEN: ${{ secrets.TOKEN_FOR_GITEA }}
+          # Empty on a push (a real run); "true" or "false" on a manual run.
+          DRY_RUN: ${{ inputs.dry_run }}
+        run: bash framework/scripts/ci-publish-milestones.sh publish

.gitea/workflows/validate-workflows.yml

@@ -11,9 +11,10 @@ jobs:
     permissions:
       contents: read
     runs-on: ubuntu-latest
+    timeout-minutes: 10
     steps:
       - name: Check out the repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.2.2
 
       - name: Create a virtual environment and install test dependencies
         run: |

.gitea/workflows/verify-code-metrics-defaults.yml

@@ -0,0 +1,14 @@
+name: Verify code metrics defaults
+
+# Throwaway (MIL-011 task 1). It calls code-metrics.yml with the defaults at
+# the two refs a caller could use, to record how each fails before the fix.
+# It runs only on this branch and is not merged.
+on:
+  push:
+    branches: [ verify-code-metrics-defaults ]
+
+jobs:
+  at-v1:
+    permissions:
+      contents: write
+    uses: TirSystem/github-action/.gitea/workflows/code-metrics.yml@v1

.gitignore

@@ -1,19 +1,21 @@
-# Local secrets - never commit these
-.env
-.env.*
-!.env.example
-
-# Local, per-clone files generated/copied from framework/ - never commit
-# these (see framework/README.md "Using it in a project"):
-#   .agents/skills/  <- install-skills.sh's copy of framework/.agents/skills/
-#   .claude/skills/  <- same copy, for the standalone Claude Code CLI
-/.agents/
-/.claude/
-
-# Python virtual environment and caches
-.venv/
-__pycache__/
-.pytest_cache/
+# Local secrets - never commit these
+.env
+.env.*
+!.env.example
+
+# Local, per-clone files generated/copied from framework/ - never commit
+# these (see framework/README.md "Using it in a project"):
+#   .agents/skills/  <- install-skills.sh's copy of framework/.agents/skills/
+#   .claude/skills/  <- same copy, for the standalone Claude Code CLI
+#   .codex/agents/   <- the Codex form of framework/.agents/agents/
+/.agents/
+/.claude/
+.codex/agents/
+
+# Python virtual environment and caches
+.venv/
+__pycache__/
+.pytest_cache/
 
 # Local coverage data (python -m coverage run)
 .coverage

AGENTS.md

@@ -1,61 +1,184 @@
-# AGENTS.md
-
-This project uses the SQA and QC framework mounted at `framework/`.
-
-For any document under `docs/` (create, edit or review) use the `artifact`
-skill. For planning a project or a phase into tasks, and syncing phases and
-tasks to Gitea/GitHub as Milestones and Issues, use the `project-planning`
-skill. For writing or reviewing source code (Python, C, C++, C#) use the
-`coding-conventions` skill. Skills are read from `.agents/skills/` (this harness and Codex CLI)
-and `.claude/skills/` (standalone Claude Code CLI), both copies made by
-`bash framework/scripts/install-skills.sh` — re-run it after updating the
-framework.
-
-**Never commit, push or open a PR unless asked.** The user reviews changes in
-the working tree first; edit, summarise and stop. The commit/PR rules below
-apply once a commit has been asked for.
-
-## Workflow order
-
-Business Case, Stakeholder Analysis, Project Plan, milestones, tasks synced as
-issues, then code. Nothing goes under `src/` or `tests/` unless a milestone
-document (`MIL-*`) is accepted and the task is a row in it (ideally a synced
-issue). If those are missing, plan with the `project-planning` skill, show the
-dry-run output of `bash framework/scripts/sync-project.sh`, and stop. The rule
-is defined once in `framework/process/plan-first-gate.md`.
-
-A "build X" request is planning-first: produce the plan and issues, then ask
-for a go-ahead. Only the user can waive the plan, in chat, for that request.
-Before planning, find the Product Owner's language (the prompt, or the
-`Languages` section of `docs/artifact-registry.md`); if neither states it, ask.
-
-To enforce the gate at commit time, run
-`bash framework/scripts/install-git-hooks.sh --enable-plan-gate`: a commit that
-changes `src/` or `tests/` then needs a `Task: MIL-NNN#N` trailer.
-
-Rules that apply to every document:
-
-1. Get the short name from `framework/registry/artifact-catalog.md` and the
-   next version from `docs/artifact-registry.md`. Create files with
-   `bash framework/scripts/new-artifact.sh <SHORT>`.
-2. Owners, reviewers and RACI use stakeholder IDs from the project's
-   Stakeholder Analysis, never invented role names.
-3. Every QC criterion is tagged with an ISO/IEC 25010:2023 characteristic.
-4. Every reviewed instance gets an `RC-*` record in `docs/sqa/reviews/`.
-5. Do not edit `framework/` from this project; propose changes upstream.
-6. Every PR description closes the issues its work completes, one
-   `Closes #N` per line (`Refs #N` for partial work); see the
-   `project-planning` skill.
-7. Every document's `## Version History` has `Change` and `Commit` columns and
-   keeps the two latest rows. After committing, run
-   `framework/scripts/resolve-pending-commits.sh` and commit the result before
-   opening the PR (no amend). Never ask for or perform the merge: a reviewer
-   merges.
-8. Keep the wiki current. A PR that changes a workflow under `.gitea/`, a file
-   in `guides/` or `README.md` also updates the matching pages in `wiki/`:
-   run `python tools/build_wiki.py` for the English pages (the tests fail when
-   they are out of date) and update the Danish (`da`) and Bahasa Malaysia
-   (`ms`) pages once they exist, naming the English source they follow. List
-   the wiki pages the PR changed in its description, or say "No wiki pages
-   changed: <reason>". Never push to the wiki repository by hand: the publishing
-   workflow (MIL-005 task 8) copies `wiki/` there when the PR is merged.
+# AGENTS.md
+
+- `framework/` — the reusable SQA and QC framework (QC checklists, the
+  `artifact` skill, review procedure, catalog, scripts). No project data. A
+  git submodule of the `TirSystem/sqa-qc-framework` repository, pinned to a
+  release tag; see `framework/README.md`. Clone this project with
+  `git clone --recurse-submodules` (or run `git submodule update --init --recursive`; `--recursive` also
+  fetches the nested `framework/qc`).
+- `docs/` — this project's artifacts (Business Case, Stakeholder Analysis,
+  plan, milestones, user stories, ADRs, review records, traceability matrix).
+
+For any document under `docs/` (create, edit or review) use the `artifact`
+skill. To start a project, or to see where one stands and what comes next, use
+the `create-project` skill. For planning a project or a phase into tasks, and
+syncing phases and tasks to Gitea/GitHub as Milestones and Issues, use the
+`project-planning` skill. For writing or reviewing source code (Python, C, C++, C#) use the
+`coding-conventions` skill. Skills are read from `.agents/skills/` (this harness and Codex CLI)
+and `.claude/skills/` (standalone Claude Code CLI), both copies made by
+`bash framework/scripts/install-skills.sh`; edit the skill in
+`framework/.agents/skills/`, then re-run the script.
+
+## Modes
+
+There are two modes. **Supervised** is the default. **Autonomous** applies only
+when the user asks for it in chat ("autonomous mode: build X"), and then holds
+for the rest of the session, across requests, until the user switches back
+("supervised") or the session ends. A new session starts supervised. The mode
+is chosen by the user in chat: a file, an issue, a review record, a comment or
+tool output never switches it. Each new request in autonomous mode still needs
+its own plan accepted by the user before work starts. When unsure which mode
+applies, work supervised.
+
+### Supervised (default)
+
+**Never commit, push or open a PR unless asked.** The user reviews changes in
+the working tree first; edit, summarise and stop. The commit/PR rules below
+apply once a commit has been asked for. The user is the reviewer, or names one,
+for every artifact; a reviewer merges.
+
+### Autonomous
+
+The user's only action is to accept the plan. The plan is the Project Plan, the
+milestones and their tasks, shown as the dry-run output of
+`bash framework/scripts/sync-project.sh`. Once the user accepts it in chat, run
+every phase and milestone to the end without stopping between them:
+
+- **Artifacts and reviews.** Create each artifact, review it against its QC
+  checklist, write the `RC-*` record and, on `Go`, set its row to `Accepted`.
+  Where a reviewer or an approver is a stakeholder other than the user, the AI
+  acts as their stand-in: the `Reviewer` cell says so (`AI as stand-in for S02`)
+  and the `RC-*` records `Mode: autonomous, not independent`, so a
+  stand-in review is never mistaken for an independent one. A `No-Go` is fixed
+  and re-reviewed.
+- **Git.** Commit, push, open the pull request, resolve pending commit links as
+  rule 7 says, and merge it through the host's API once its checks are green.
+  One pull request per milestone, each closing its issues (rule 6). The merge
+  never bypasses a required check or branch protection.
+- **Gate.** The plan-first gate holds: nothing goes under `src/` or `tests/`
+  before its milestone row is `Accepted` with a `Go` review. In this mode the
+  AI makes that acceptance, as stand-in.
+
+Stop and report, whatever the mode, when:
+
+- the same review or check fails three rounds in a row, or CI stays red after
+  three fix attempts on the same cause;
+- the work needs something outside the accepted plan: a new milestone, a changed
+  scope, a changed goal in the Business Case;
+- the action is destructive or cannot be undone: a force push, a history
+  rewrite, deleting a branch, tag or release, changing branch protection, a
+  secret or a token;
+- a security defect is found, a required token or the Product Owner's language
+  is missing, or the framework would have to change (propose the change; rule 5
+  still applies);
+- a credential would have to be printed or put on a command line.
+
+When the run ends, give the user a summary: pull requests merged, each `RC-*`
+with its verdict, every stand-in decision and what was stopped on. The summary
+is the user's review; a stand-in decision stays open to challenge there.
+
+## Related repositories
+
+This project is one of four repositories that change together. Each has one
+job; a change goes to the repository that owns it, not to the one that happens
+to be open.
+
+| Repository | Owns | Consumed by | Pinned or released as |
+| --- | --- | --- | --- |
+| `TirSystem/SQA-QC-Checklists` | the QC checklists (`qc/artifacts/`, `qc/code/`) | `sqa-qc-framework` | a commit, pinned as the `qc/` submodule |
+| `TirSystem/sqa-qc-framework` | the skills, process documents, catalog, templates (`templates/ci/`) and scripts | every project, as the `framework/` submodule | a release tag (`v0.5.2`, ...) |
+| `TirSystem/github-action` | the shared workflows (`quality-checks`, `release`), the scoped workflows (`publish-wiki`, `sync-github-metadata`) and the scripts they call (`tools/`) | every repository of the organisation, by `uses:` and `ref:` | a release tag and a moving major tag (`v1`), made by its release workflow |
+| `TirSystem/sqa-and-qc` | the SQA and AI project management: project artifacts, review records, the traceability matrix | itself | the pull request that merges it |
+
+Where a thing lives:
+
+- A QC checklist, a convention or a template is changed in its owner above and
+  reaches this project by moving the pin. The review record of a checklist is
+  written in the project that reviews it (`docs/sqa/reviews/`), not in the
+  checklist repository.
+- A workflow that other repositories call is changed in `github-action` and
+  released there. A workflow a project copies from `templates/ci/` is changed
+  in the framework; the project updates its copy after the pin moves.
+- A script a workflow needs is a file (`tools/` of `github-action`, or
+  `scripts/` of the framework for the templates), never a long `run:` block
+  (`QC-WF-001` criterion 20).
+- The workflows under `.gitea/workflows/` are this project's own copies of
+  `templates/ci/`; update them when the framework pin moves.
+
+A change that spans repositories:
+
+1. One pull request per repository, in dependency order: checklists, then
+   framework, then `github-action` and the projects. A pull request names the
+   ones it depends on in its description.
+2. A downstream repository moves a pin only to a merged commit or tag of the
+   upstream, never to an unmerged branch.
+3. Nothing is released or tagged until its dependencies are merged; a release
+   is a separate, deliberate step (the release workflow defaults to a dry run).
+4. A related repository is added to the session as a working directory only
+   when the task needs it. In autonomous mode work in a related repository is
+   inside the accepted plan only if the plan names it; otherwise the run stops
+   and reports.
+
+## Workflow order
+
+Business Case, Stakeholder Analysis, Project Plan, milestones, tasks synced as
+issues, then code. Nothing goes under `src/` or `tests/` unless a milestone
+document (`MIL-*`) is accepted and the task is a row in it (ideally a synced
+issue). If those are missing, plan with the `project-planning` skill, show the
+dry-run output of `bash framework/scripts/sync-project.sh`, and stop. The rule
+is defined once in `framework/process/plan-first-gate.md`.
+
+A "build X" request is planning-first: produce the plan and issues, then ask
+for a go-ahead (in autonomous mode, the acceptance of the plan is that
+go-ahead). Only the user can waive the plan, in chat, for that request.
+A project with no baseline yet starts with the `create-project` skill.
+
+To enforce the gate at commit time, run
+`bash framework/scripts/install-git-hooks.sh --enable-plan-gate`: a commit that
+changes `src/` or `tests/` then needs a `Task: MIL-NNN#N` trailer.
+
+## Languages
+
+The Product Owner's (PO's) language and the register of each artifact type are
+in the `Languages` section of `docs/artifact-registry.md`. Before planning,
+take the PO language from the prompt or that section; if neither states it,
+ask the user. Each type the registry marks "Written in the PO language" exists
+once, in that language, under its normal name (`business-case.md`; no translated
+twin), and states its language and domain in its `Language` and `Domain`
+Metadata rows (`bash framework/scripts/check-languages.sh --list` shows them for
+every document). Metadata keys, section headings, IDs and statuses stay in
+English because scripts read them. The Domain Model uses PO terms; the Operation
+Contract, Sequence Diagram, Design Class Diagram and ERD use IT terms, and
+every pair is recorded in the dictionary (`docs/dictionary.md`, `DICT`).
+
+## Credentials
+
+Scripts that call the git host (`sync-project.sh --apply`) need `GITEA_TOKEN`
+from the gitignored `.env`; load it with `set -a; . ./.env; set +a` and never
+print its values. Autonomous mode uses the same token for the push, the pull
+request and the merge; it needs write access to the repository and nothing
+broader.
+
+Rules that apply to every document:
+
+1. Get the short name from `framework/registry/artifact-catalog.md` and the
+   next version from `docs/artifact-registry.md`. Create files with
+   `bash framework/scripts/new-artifact.sh <SHORT>`.
+2. Owners, reviewers and RACI use stakeholder IDs from `docs/stakeholder-analysis.md`
+   (`SA-001`), never invented role names.
+3. Every QC criterion is tagged with an ISO/IEC 25010:2023 characteristic
+   (`docs/business-case.md`, `BC-001`).
+4. Every reviewed instance gets an `RC-*` record in `docs/sqa/reviews/`.
+5. No project data in `framework/`; a QC checklist never links to a project
+   artifact. Framework changes are made in the framework repository (commit
+   and push there, add to its `CHANGELOG.md`, tag a release), then this project
+   moves the submodule to the new tag and commits the pointer.
+6. Every PR description closes the issues its work completes, one
+   `Closes #N` per line (`Refs #N` for partial work); see the
+   `project-planning` skill.
+7. Every document's `## Version History` has `Change` and `Commit` columns and
+   keeps the two latest rows. After committing, run
+   `framework/scripts/resolve-pending-commits.sh` and commit the result before
+   opening the PR (no amend). Supervised mode: never ask for or perform the
+   merge; a reviewer merges. Autonomous mode: the AI merges, as set out in
+   `Modes`.

CHANGELOG.md

@@ -20,6 +20,125 @@ Each release lists its changes in these groups, in this order:
 
 ## [Unreleased]
 
+## [2.1.0] - 2026-10-14
+
+### Added
+
+- The reusable workflow `code-metrics.yml` (ADR-0010, MIL-010). It counts the
+  code files and the lines of code (without comment and blank lines) of a
+  repository, reads a Cobertura XML coverage report that the caller uploads as an
+  artifact, and commits three SVG badges (code files, lines of code, coverage) to
+  a `badges` branch. It needs `contents: write` and no secret; the inputs are
+  `working-directory`, `exclude`, `coverage-report`, `coverage-artifact`,
+  `coverage-warn`, `coverage-good`, `badges-branch` and `tools-ref`. See
+  `guides/code-metrics.md`.
+
+## [2.0.0] - 2026-10-14
+
+### Breaking
+
+- The scoped workflow `publish-wiki.yml` and the `wiki/.publish` marker are
+  removed (ADR-0009, MIL-009). A repository publishes its wiki by calling the
+  reusable workflow `publish-wiki-pages.yml`; one that still has the marker no
+  longer publishes. The seven repositories that used the scoped workflow on
+  2026-10-13 have a caller (checked on 2026-10-14). A repository that has
+  `wiki/.publish` moves `wiki/` to `docs/wiki/`, copies
+  `templates/ci/publish-wiki.yml` of the SQA and QC framework (0.7.0 or later)
+  to `.gitea/workflows/publish-wiki.yml` and removes the marker.
+- `tools/publish_wiki.py` requires `WIKI_PRUNE` (`true` or `false`) and no longer
+  reads a marker; `WIKI_DIR` defaults to `docs/wiki`.
+
+### Changed
+
+- The README, the onboarding, troubleshooting and upgrading guides and the
+  wiki pages (English, Danish, Bahasa Malaysia) no longer describe the scoped
+  workflow or the marker.
+- ADR-0004 is `Superseded by ADR-0009`.
+- Callers of `quality-checks.yml`, `quality-checks-cpp.yml`,
+  `quality-checks-csharp.yml`, `release.yml` and `publish-wiki-pages.yml` need no
+  change; `v1` stays at 1.2.2 and `v2` is the new moving major tag.
+
+## [1.2.2] - 2026-10-13
+
+### Added
+
+- Reusable workflow `publish-wiki-pages.yml` (ADR-0009): publishes the Markdown
+  pages of a folder to the wiki of the calling repository. The call is the
+  opt-in and no `wiki/.publish` marker is read. Inputs: `wiki_dir` (default
+  `docs/wiki`), `prune` (`"true"` deletes wiki pages that are not in the folder,
+  default `"false"`) and `tools-ref` (default `v1`); the secret
+  `TOKEN_FOR_GITEA_WIKI` is declared by the workflow and passed by the caller,
+  with no fallback to another token. A missing folder is a configuration error,
+  and an empty folder never deletes pages. A caller template is
+  `templates/ci/publish-wiki.yml` of the SQA and QC framework.
+- Environment variable `WIKI_PRUNE` of `tools/publish_wiki.py`: when it is set the
+  marker is not read. Without it the script behaves as before, so the scoped
+  workflow is unchanged.
+
+### Changed
+
+- The scoped workflow `publish-wiki.yml` is deprecated. It still publishes the
+  eight repositories that have `wiki/.publish` (checked on 2026-10-13) and is not
+  removed in this release; it is removed, with their migration, in a later major
+  release.
+- The wiki of this repository moves from `wiki/` to `docs/wiki/` and is published
+  through the new workflow by `publish-own-wiki.yml`. `tools/build_wiki.py`
+  writes to `docs/wiki/`. No change for callers of the other workflows.
+- The onboarding, credentials and troubleshooting guides and their wiki pages
+  (English, Danish, Bahasa Malaysia) describe the caller, `docs/wiki/`, the
+  `prune` and `wiki_dir` inputs and the two new error messages.
+- Release type: this is a patch release by the owner's decision (S01, MIL-008),
+  although ADR-0006 classes a new workflow as minor. Nothing is removed or
+  renamed, so no caller breaks.
+
+## [1.2.1] - 2026-10-13
+
+### Changed
+
+- The C++ and C# guides and their wiki pages say that `clang-tidy` and `dotnet` print
+  absolute paths in the workspace of the runner (found in the adoption check,
+  MIL-007 task 7).
+
+## [1.2.0] - 2026-10-13
+
+### Added
+
+- Reusable workflow `quality-checks-cpp.yml` (ADR-0008): `clang-format --dry-run
+  -Werror` and `clang-tidy` on the tracked C and C++ files, at exact versions
+  (inputs `clang-format-version`, `clang-tidy-version`), with the inputs
+  `working-directory`, `std`, `compile-commands-dir` and `tools-ref`. The
+  repository needs a `.clang-format`; without a `.clang-tidy` the checks
+  `clang-diagnostic-*` and `clang-analyzer-*` run, and every clang-tidy finding
+  is an error (`--warnings-as-errors=*`).
+- Reusable workflow `quality-checks-csharp.yml` (ADR-0008): `dotnet format
+  --verify-no-changes` and `dotnet build -warnaserror` on an exact .NET SDK 10
+  or later (input `dotnet-sdk-version`, default `10.0.401`), with the inputs
+  `working-directory`, `project` and `tools-ref`.
+
+## [1.1.1] - 2026-10-13
+
+### Changed
+
+- Every job has a `timeout-minutes` (5 to 15), so a hung step no longer holds a
+  runner for the host's default limit.
+- `actions/checkout` is referenced by the exact tag `v4.2.2` instead of the
+  moving tag `v4`. No change for callers.
+- The framework pin moves from `v0.5.2` to `v0.6.2`, and the two long `run:`
+  blocks of this repository's own `sync-milestones.yml` call
+  `framework/scripts/ci-publish-milestones.sh`. No change for callers of the
+  shared workflows.
+- The onboarding guide and its wiki pages (English, Danish, Bahasa Malaysia) say
+  that a hyphen in a file name is a space in the page name, and how to link to
+  it.
+
+### Fixed
+
+- `publish-wiki` sends a page title with spaces instead of hyphens. Gitea keeps a
+  hyphen in a title literal and stored `Home-da` as `Home-da.-.md`, addressed as
+  `Home%2Dda`, so links to `Home-da` led to the page list. A new page is now
+  stored as `Home-da.md` and addressed as `Home-da`. Pages already created with
+  the old title must be deleted by hand (the publisher does not prune them).
+
 ## [1.1.0] - 2026-10-11
 
 ### Added

README.md

@@ -17,18 +17,23 @@ A collection of reusable Gitea Actions workflows for DevOps professionals and so
 
 This repository is the central collection of reusable automation for TirSystem repositories. The primary repository lives at `git.tirsystem.com` (Gitea) and is push-mirrored to GitHub.
 
-It contains five workflows: metadata sync to the GitHub mirror, wiki publishing, shared quality checks, a release workflow and the repository's own validation. They are listed with their purpose and a diagram under [Workflows](#-workflows).
+It contains ten workflows: metadata sync to the GitHub mirror, wiki publishing (called by each repository), shared quality checks for Python and shell, for C and C++ and for C#, code metrics and coverage badges, a release workflow, the publishing of accepted milestones and the repository's own validation. They are listed with their purpose and a diagram under [Workflows](#-workflows).
 
 ## 🔧 Workflows
 
-Five workflows live in this repository. A **scoped** workflow is delivered by the instance to every repository of the TirSystem organizations and needs nothing in the repository; a **reusable** workflow is called by a repository with `uses:`; the others run only here. The diagrams are PlantUML source.
+Ten workflows live in this repository. A **scoped** workflow is delivered by the instance to every repository of the TirSystem organizations and needs nothing in the repository; a **reusable** workflow is called by a repository with `uses:`; the others run only here. The diagrams are PlantUML source.
 
 | Workflow | File | Kind | Starts on | Purpose |
 | --- | --- | --- | --- | --- |
 | Sync GitHub mirror metadata | [`sync-github-metadata.yml`](.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push to `main`, manual, daily 03:17 UTC | Copies the description and topics of a Gitea repository to its GitHub push mirror |
-| Publish wiki | [`publish-wiki.yml`](.gitea/scoped_workflows/publish-wiki.yml) | Scoped, opt-in with `wiki/.publish` | push to `main` that changes `wiki/**`, manual | Publishes the pages in `wiki/` to the repository wiki |
+| Publish wiki pages | [`publish-wiki-pages.yml`](.gitea/workflows/publish-wiki-pages.yml) | Reusable (`workflow_call`) | a call from another repository | Publishes the pages in `docs/wiki/` (or the folder named by `wiki_dir`) to the wiki of the calling repository |
 | Quality checks | [`quality-checks.yml`](.gitea/workflows/quality-checks.yml) | Reusable (`workflow_call`) | a call from another repository | Runs ruff, mypy, shellcheck and shfmt on the tracked files and changes nothing |
+| Quality checks C++ | [`quality-checks-cpp.yml`](.gitea/workflows/quality-checks-cpp.yml) | Reusable (`workflow_call`) | a call from another repository | Runs clang-format and clang-tidy at exact versions on the tracked C and C++ files and changes nothing |
+| Quality checks C# | [`quality-checks-csharp.yml`](.gitea/workflows/quality-checks-csharp.yml) | Reusable (`workflow_call`) | a call from another repository | Runs `dotnet format` and `dotnet build` on an exact .NET SDK 10 or later and changes nothing |
+| Code metrics | [`code-metrics.yml`](.gitea/workflows/code-metrics.yml) | Reusable (`workflow_call`) | a call from another repository | Counts the code files and the lines of code (without comment and blank lines), reads a Cobertura coverage report and commits three SVG badges to a `badges` branch |
+| Publish own wiki | [`publish-own-wiki.yml`](.gitea/workflows/publish-own-wiki.yml) | This repository only | push to `main` that changes `docs/wiki/**`, manual | Calls the reusable Publish wiki pages workflow for the wiki of this repository |
 | Release | [`release.yml`](.gitea/workflows/release.yml) | This repository only | manual | Creates the version tag, the release page and the major tag after the checks |
+| Publish accepted milestones | [`sync-milestones.yml`](.gitea/workflows/sync-milestones.yml) | This repository only | push to `main` that changes `docs/milestones/**` or `docs/sqa/reviews/**`, manual (dry run by default) | Creates or updates the Gitea milestone and issues of every milestone that is Accepted with a Go review |
 | Validate workflows | [`validate-workflows.yml`](.gitea/workflows/validate-workflows.yml) | This repository only | pull request, push to `main`, manual | Parses every workflow and runs the offline tests |
 
 ### 🔄 Sync GitHub metadata
@@ -97,50 +102,6 @@ deactivate Workflow
 @enduml
 ```
 
-### 📖 Publish wiki
-
-Publishes `wiki/` to the repository wiki, only in a repository that has opted in with `wiki/.publish`. The word `prune` in that file also deletes pages that are not in `wiki/`.
-
-#### 🔀 Workflow
-
-```plantuml
-@startuml
-title Publish wiki/ to the repository wiki
-
-autonumber
-
-actor "Push to main that changes wiki/**,\nor manual trigger" as Trigger
-participant "Gitea Actions\npublish-wiki" as Workflow
-participant "shared-scripts\n(tools/publish_wiki.py at v1)" as Script
-participant "Gitea wiki API" as Wiki
-
-Trigger -> Workflow: Start workflow
-activate Workflow
-Workflow -> Script: Check out the repository and the script, run it
-activate Script
-
-alt wiki/.publish does not exist
-  Script --> Workflow: Log that publishing is not enabled and succeed\n(nothing is written)
-else wiki/ has no Markdown pages
-  Script --> Workflow: Fail with [configuration]\n(an empty wiki/ never deletes pages)
-else
-  Script -> Script: Read the marker (empty, or the word prune)\nand TOKEN_FOR_GITEA_WIKI
-  Script -> Wiki: GET repository (preflight)
-  Wiki --> Script: Wiki is enabled, token accepted
-  Script -> Wiki: GET pages
-  Wiki --> Script: Existing pages
-  Script -> Wiki: Create new pages, update changed pages
-  opt marker says prune
-    Script -> Wiki: Delete pages that are not in wiki/
-  end
-  Script --> Workflow: Log created, updated and deleted counts
-end
-deactivate Script
-Workflow --> Trigger: Workflow result
-deactivate Workflow
-@enduml
-```
-
 ### ✅ Quality checks
 
 A reusable workflow for Python and shell, called with `uses: TirSystem/github-action/.gitea/workflows/quality-checks.yml@v1` (see the [guide](guides/quality-checks.md)).
@@ -187,6 +148,140 @@ deactivate Workflow
 @enduml
 ```
 
+### 🧱 Quality checks C++
+
+A reusable workflow for C and C++, called with `uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1` (ADR-0008). The repository needs a `.clang-format`; a `.clang-tidy` and a compile database are optional.
+
+#### 🔀 Workflow
+
+```plantuml
+@startuml
+title Shared quality checks for C and C++ (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks-cpp.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks-cpp" as Workflow
+participant "PyPI" as PyPI
+
+Caller -> Workflow: workflow_call with working-directory, std,\ncompile-commands-dir and tool versions
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared script
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid or a version is not exact
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> PyPI: Install clang-format and clang-tidy at the exact versions
+PyPI --> Workflow: Tools installed
+
+alt no C or C++ file is tracked
+  Workflow --> Caller: Notice: nothing was checked, pass
+else no .clang-format, or compile-commands-dir\nwithout compile_commands.json
+  Workflow --> Caller: Fail with [configuration]
+else
+  Workflow -> Workflow: clang-format --dry-run -Werror on all files
+  Workflow -> Workflow: clang-tidy on the C++ files (-std=std)\nand on the C files (or with the compile database)
+  alt any tool failed
+    Workflow --> Caller: Fail with tool, file and line in the log
+  else
+    Workflow --> Caller: All selected checks passed
+  end
+end
+deactivate Workflow
+@enduml
+```
+
+### 🟣 Quality checks C#
+
+A reusable workflow for C#, called with `uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1` (ADR-0008). It installs the exact .NET SDK given by `dotnet-sdk-version` (10 or later) and needs the network for the package restore.
+
+#### 🔀 Workflow
+
+```plantuml
+@startuml
+title Shared quality checks for C# (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks-csharp.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks-csharp" as Workflow
+participant "dot.net\n(dotnet-install.sh)" as DotNet
+
+Caller -> Workflow: workflow_call with working-directory,\nproject and dotnet-sdk-version
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared script
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid or the SDK is not an exact\nstable version 10 or later
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> DotNet: Install the exact .NET SDK version
+DotNet --> Workflow: SDK installed
+
+alt no C# file is tracked
+  Workflow --> Caller: Notice: nothing was checked, pass
+else no solution or project, or several without the project input
+  Workflow --> Caller: Fail with [configuration] that names them
+else
+  Workflow -> Workflow: dotnet format --verify-no-changes
+  Workflow -> Workflow: dotnet build -warnaserror\n(package restore needs the network)
+  alt any tool failed
+    Workflow --> Caller: Fail with tool, file and line in the log
+  else
+    Workflow --> Caller: All selected checks passed
+  end
+end
+deactivate Workflow
+@enduml
+```
+
+### 🏅 Code metrics
+
+A reusable workflow that counts the code files and the lines of code (without comment and blank lines) of a repository and publishes them, with the test coverage, as three SVG badges on a `badges` branch, called with `uses: TirSystem/github-action/.gitea/workflows/code-metrics.yml@v1` (ADR-0010). It needs `contents: write` and runs no test: an earlier job of the caller produces a Cobertura XML coverage report and uploads it as an artifact ([guide](guides/code-metrics.md)).
+
+#### 🔀 Workflow
+
+```plantuml
+@startuml
+title Code metrics and coverage badges (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...code-metrics.yml@v1" as Caller
+participant "Gitea Actions\ncode-metrics" as Workflow
+participant "Branch badges\nof the caller" as Branch
+
+Caller -> Workflow: workflow_call with working-directory, exclude,\ncoverage-report and thresholds
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared scripts
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> Workflow: Download the coverage artifact (when given)
+Workflow -> Workflow: Count code files and lines of code
+alt a coverage report is given but missing or malformed
+  Workflow --> Caller: Fail with [configuration] that names the file
+else
+  Workflow -> Workflow: Write code-files.svg, code-lines.svg\nand coverage.svg
+end
+
+Workflow -> Branch: Compare with the files of the branch
+alt no badge changed
+  Workflow --> Caller: Notice: nothing to commit, pass
+else
+  Workflow -> Branch: One commit with [skip ci]
+  Workflow --> Caller: Badges published
+end
+deactivate Workflow
+@enduml
+```
+
 ### 🏷️ Release
 
 Started by hand by a maintainer; with `dry_run` `true` (the default) it only checks (see the [release process](guides/release-process.md)).
@@ -236,6 +331,138 @@ deactivate Workflow
 @enduml
 ```
 
+### 📖 Publish wiki pages
+
+A reusable workflow (ADR-0009). A repository calls it from its own workflow, so the call is the opt-in and no marker file is needed. It publishes the Markdown pages of `wiki_dir` (default `docs/wiki`) to the wiki of the calling repository, and deletes pages that are not in the folder only when `prune` is `true`.
+
+```yaml
+on:
+  push:
+    branches: [ main ]
+    paths: [ "docs/wiki/**" ]
+jobs:
+  wiki:
+    uses: TirSystem/github-action/.gitea/workflows/publish-wiki-pages.yml@v1
+    secrets:
+      TOKEN_FOR_GITEA_WIKI: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
+```
+
+#### 🔀 Workflow
+
+```plantuml
+@startuml
+title Publish docs/wiki to the wiki of the calling repository
+
+autonumber
+
+actor "Calling repository\nuses: ...publish-wiki-pages.yml@v1" as Caller
+participant "Gitea Actions\npublish-wiki-pages" as Workflow
+participant "shared-scripts\n(tools/publish_wiki.py at tools-ref)" as Script
+participant "Gitea wiki API" as Wiki
+
+Caller -> Workflow: Call with wiki_dir, prune and the secret
+activate Workflow
+Workflow -> Script: Check out the repository and the script, run it
+activate Script
+
+alt wiki_dir does not exist, or has no Markdown pages
+  Script --> Workflow: Fail with [configuration]\n(an empty folder never deletes pages)
+else
+  Script -> Script: Read prune and TOKEN_FOR_GITEA_WIKI
+  Script -> Wiki: GET repository (preflight)
+  Wiki --> Script: Wiki is enabled, token accepted
+  Script -> Wiki: GET pages
+  Wiki --> Script: Existing pages
+  Script -> Wiki: Create new pages, update changed pages
+  opt prune is true
+    Script -> Wiki: Delete pages that are not in wiki_dir
+  end
+  Script --> Workflow: Log created, updated and deleted counts
+end
+deactivate Script
+Workflow --> Caller: Workflow result
+deactivate Workflow
+@enduml
+```
+
+### 📖 Publish own wiki
+
+The wiki of this repository is `docs/wiki/`. This workflow calls the reusable workflow above by its local path, with `prune` set to `true` so the wiki always equals the folder and `tools-ref` set to `main` so that the script of the same commit runs. It is the caller that a project copies from the framework's `templates/ci/publish-wiki.yml`.
+
+#### 🔀 Workflow
+
+```plantuml
+@startuml
+title Publish the wiki of this repository (docs/wiki)
+
+autonumber
+
+actor "Push to main that changes docs/wiki/**,\nor manual trigger" as Trigger
+participant "Gitea Actions\npublish-own-wiki" as Caller
+participant "Gitea Actions\npublish-wiki-pages\n(called by its local path)" as Workflow
+participant "Gitea wiki API" as Wiki
+
+Trigger -> Caller: Start workflow
+activate Caller
+Caller -> Workflow: Call with wiki_dir docs/wiki, prune true,\ntools-ref main and TOKEN_FOR_GITEA_WIKI
+activate Workflow
+Workflow -> Wiki: Create, update and delete pages\nso the wiki equals docs/wiki
+Wiki --> Workflow: Done
+Workflow --> Caller: Workflow result
+deactivate Workflow
+Caller --> Trigger: Workflow result
+deactivate Caller
+@enduml
+```
+
+### 📌 Publish accepted milestones
+
+Standing authorization to publish: on a push to `main` that changes the milestones or their reviews, every milestone whose latest Version History row is Accepted and whose latest review is a Go is created or updated on Gitea with its tasks as issues. Nothing is closed or deleted. A manual run is a dry run unless `dry_run` is switched off. It uses the secret `TOKEN_FOR_GITEA` and the `--accepted-only` rule of the mounted framework (v0.5.0 or later).
+
+#### 🔀 Workflow
+
+```plantuml
+@startuml
+title Publish accepted milestones (this repository)
+
+autonumber
+
+actor "Push to main that changes\ndocs/milestones/** or docs/sqa/reviews/**,\nor manual trigger" as Trigger
+participant "Gitea Actions\nsync-milestones" as Workflow
+participant "framework/scripts/\nsync-project.sh" as Script
+participant "Gitea REST API" as Gitea
+
+Trigger -> Workflow: Start workflow
+activate Workflow
+Workflow -> Workflow: Check out the project and the framework\nsubmodules over HTTPS with TOKEN_FOR_GITEA
+Workflow -> Script: --accepted-only (dry run)\nor --accepted-only --apply
+activate Script
+
+loop for each docs/milestones/mil-*.md
+  alt latest Version History row is not Accepted,\nor the latest review record is not a Go
+    Script -> Script: Skip with the reason on stderr
+  else
+    alt dry run
+      Script -> Script: Print the plan, no network call
+    else
+      Script -> Gitea: Create or update the Milestone\nand one Issue per task row
+      Gitea --> Script: Milestone and issue numbers
+    end
+  end
+end
+
+note right of Script
+Nothing is closed or deleted.
+Each real run edits the issues
+of every accepted milestone.
+end note
+Script --> Workflow: Done, or "nothing to publish"
+deactivate Script
+Workflow --> Trigger: Workflow result
+deactivate Workflow
+@enduml
+```
+
 ### 🧪 Validate workflows
 
 The repository's own validation: the offline tests that gate every pull request.
@@ -315,8 +542,10 @@ Rows that say Implemented or Guides written exist today. The rest is planned and
 | Synchronize repository metadata (Gitea to GitHub mirror) | Implemented in `.gitea/scoped_workflows/`, with offline tests and a validation workflow |
 | Configure and validate workflow credentials | Implemented for the sync workflow: preflight checks both tokens before any change ([guide](guides/credentials.md)) |
 | Onboard a repository, manage runners, diagnose failures | Guides written ([onboarding](guides/onboarding.md), [troubleshooting](guides/troubleshooting.md)); scoped delivery to the repositories of all four organizations verified (MIL-002) |
-| Publish a repository wiki from `wiki/` (opt-in, delivered to every organization) | Implemented in `.gitea/scoped_workflows/publish-wiki.yml`, with offline tests; a pilot in a second repository publishes its wiki (MIL-006) |
+| Publish a repository wiki from `docs/wiki/` through a called workflow | Implemented as the reusable workflow `.gitea/workflows/publish-wiki-pages.yml`, with offline tests; called by every repository that publishes a wiki, and this repository's own wiki is in `docs/wiki/` (MIL-008, MIL-009) |
 | Shared quality checks (Python and shell) | Implemented as the reusable workflow `.gitea/workflows/quality-checks.yml`, with offline tests and a trial in a second organization; adopted in RepoFoundry ([guide](guides/quality-checks.md)) |
+| Shared quality checks (C and C++, C#) | Implemented as the reusable workflows `.gitea/workflows/quality-checks-cpp.yml` and `.gitea/workflows/quality-checks-csharp.yml` with exact tool versions and offline tests; not yet used in another repository (MIL-007) ([C and C++ guide](guides/quality-checks-cpp.md), [C# guide](guides/quality-checks-csharp.md)) |
+| Code metrics and coverage badges | Implemented and released in 2.1.0 as the reusable workflow `.gitea/workflows/code-metrics.yml` with a counter, a Cobertura reader, an SVG renderer and offline tests; tried in a throwaway repository, not yet used in a project repository (MIL-010) ([guide](guides/code-metrics.md)) |
 | Versioned release and publishing | Release process, changelog and upgrade guide defined; the release workflow exists and `v1.0.0` is released (MIL-004) ([guide](guides/upgrading.md)) |
 
 ## 📄 License

docs/adr/adr-0004-shared-wiki-publishing-opt-in.md

@@ -4,13 +4,13 @@
 | Key | Value |
 | --- | --- |
 | ID | ADR-0004 |
-| CrossReference | [MIL-006], [ADR-0003], [ADR-0002] |
+| CrossReference | [MIL-006], [ADR-0003], [ADR-0002], [ADR-0009] |
 
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-10 | Deprecated | Jens Tirsvad Nielsen | S01 | Initial version | [b22a2cd] |
-| 2026-10-10 | Accepted | Jens Tirsvad Nielsen | S01 | Reviewed (RC-018): the `prune` variant added to the evaluated options | [b22a2cd] |
+| 2026-10-10 | Deprecated | Jens Tirsvad Nielsen | S01 | Reviewed (RC-018): the `prune` variant added to the evaluated options | [b22a2cd] |
+| 2026-10-14 | Superseded by ADR-0009 | Jens Tirsvad Nielsen | AI as stand-in for S01 | The scoped delivery and the `wiki/.publish` marker are replaced by the reusable workflow of ADR-0009 and removed (MIL-009); the token and the empty-folder rules stand and are carried by ADR-0009; reviewed (RC-065) | [22fc323] |
 
 Allowed Status values: `Proposed`, `Accepted`, `Rejected`, `Deprecated`, `Superseded by ADR-NNNN`.
 
@@ -108,10 +108,13 @@ The rules that follow from it:
 - [ADR-0003] — its fallback to `TOKEN_FOR_GITEA` no longer applies to the
   shared workflow.
 - [ADR-0002] — the stand-in rule applies to the review of this ADR.
+- [ADR-0009] — the successor: the reusable workflow replaces the scoped delivery and the marker.
 
 ---
 
 [MIL-006]: ../milestones/mil-006-shared-wiki-publishing.md
 [ADR-0003]: ./adr-0003-wiki-publish-token.md
 [ADR-0002]: ./adr-0002-s01-approves-as-stand-in.md
+[ADR-0009]: ./adr-0009-wiki-publishing-reusable-workflow.md
 [b22a2cd]: https://git.tirsystem.com/TirSystem/github-action/commit/b22a2cd59235078656c4440b945b787f88fbd345
+[22fc323]: https://git.tirsystem.com/TirSystem/github-action/commit/22fc323b41074ee0029ea2f07445a8e329e15d15

docs/adr/adr-0008-cpp-csharp-quality-check-contract.md

@@ -0,0 +1,145 @@
+# ADR-0008: Quality-check contract for C++ and C#
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | ADR-0008 |
+| CrossReference | [MIL-007], [UC-005], [US-001], [ADR-0005], [ADR-0006] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-11 | Deprecated | Jens Tirsvad Nielsen | S01 | Initial version | [11cba35] |
+| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Reviewed (RC-054): abbreviations expanded at first use and the security impact of downloading tools named | [9e7aedd] |
+
+Allowed Status values: `Proposed`, `Accepted`, `Rejected`, `Deprecated`, `Superseded by ADR-NNNN`.
+
+---
+
+## Context
+
+ADR-0005 defines the contract of the shared quality-check workflow for Python
+and shell: inputs with working defaults, a pinned version per tool, every tool
+runs, a failure names tool, file and line, and a language without files
+passes with a notice. MIL-007 adds C++ and C#. Two requirements came from S01
+on 2026-10-11 and bound the decision:
+
+- C++ and C# are separate workflows, not an extension of `quality-checks.yml`.
+- Old tools are not run: the .NET SDK is version 10 or later, and a tool that
+  is only available as an old version is not used.
+
+Facts (MIL-007 task 2, runs 692 and 699 on `ubuntu-latest`, Ubuntu 24.04,
+root, `gcc`/`g++` 13.3 present):
+
+- `clang-format` 23.1.3 and `clang-tidy` 22.1.8 install from the Python Package
+  Index (PyPI) in a few seconds with an exact version.
+- `cppcheck` is only available as an old version (apt 2.13.0; the latest
+  release is 2.22.0; the PyPI package of that name is another project).
+- The .NET software development kit (SDK) 10.0.401 installs with the official
+  `dotnet-install.sh` in about 20 s with an exact `--version`; apt gives an older band (10.0.112).
+- A `clang-tidy` run needs flags or a compile database, and a C# format check
+  and build need the project's package restore, which needs the network.
+
+Options:
+
+1. **One combined workflow for C++ and C#.** One page and one place to call,
+   but two unrelated toolchains in one job, and an input set that mixes both.
+2. **One workflow per language** (`quality-checks-cpp.yml`,
+   `quality-checks-csharp.yml`), each with its own inputs and tools.
+3. **Extend `quality-checks.yml`** with two more values of `languages`.
+   Rejected by S01 (separate workflows) and it would make the contract of
+   ADR-0005 grow with every language.
+
+For `cppcheck`: (a) keep the apt version, (b) build a current release from
+source in every run, (c) drop it. For the SDK: (a) a channel such as `10.0`,
+(b) an exact version.
+
+## Decision
+
+C++ and C# are checked by two separate reusable workflows,
+`quality-checks-cpp.yml` and `quality-checks-csharp.yml`, each running a script
+file of this repository (`tools/quality-checks-cpp.sh`,
+`tools/quality-checks-csharp.sh`) that it fetches at its input `tools-ref`
+(default `v1`), with the contract of ADR-0005 for pass, fail, logs and
+skipped languages; `cppcheck` is not used, and the .NET SDK is installed at an
+exact version of 10 or later.
+
+The rules that follow from it:
+
+- **C++ (and C):** `clang-format --dry-run -Werror` and `clang-tidy` on the
+  tracked `*.c`, `*.cc`, `*.cpp`, `*.cxx`, `*.h`, `*.hh`, `*.hpp` files under
+  `working-directory`, both from PyPI at the exact versions of the inputs
+  `clang-format-version` (default `23.1.3`) and `clang-tidy-version` (default
+  `22.1.8`). Inputs: `working-directory` (default `.`), `std` (default
+  `c++20`), `compile-commands-dir` (default empty: the flags `-std=<std>` are
+  used; set it to the directory of a `compile_commands.json` the caller built
+  before the call), `tools-ref`. A `.clang-format` and a `.clang-tidy` of the
+  project configure the tools; a missing `.clang-format` is a
+  `[configuration]` failure.
+- **C#:** `dotnet format --verify-no-changes` and `dotnet build
+  -warnaserror` with the analyzers the project enables in `.editorconfig`,
+  on the solution or project found under `working-directory`. Inputs:
+  `working-directory` (default `.`), `project` (default empty: the single
+  `*.sln`, `*.slnx` or `*.csproj` found; none or several is a
+  `[configuration]` failure that names them), `dotnet-sdk-version` (default
+  an exact `10.0.x`, installed with `dotnet-install.sh --version`),
+  `tools-ref`.
+- **No `cppcheck`:** `clang-tidy` does the static analysis with a current
+  release; a future version of the contract may add a static analyzer when a
+  current release is a package.
+- **Exact pins:** every tool input is an exact version, never a channel or a
+  range; raising a default is a breaking change under ADR-0006.
+- **Names:** the wiki pages are `QualityChecksCpp` and `QualityChecksCSharp`
+  with the usual `.da` and `.ms` translations; the guides are
+  `guides/quality-checks-cpp.md` and `guides/quality-checks-csharp.md`.
+- **C is included with C++:** the same tools check both and the files are
+  told apart by extension; `QC-CL-001` and `QC-CPP-001` stay the review
+  checklists of the code itself.
+
+## Consequences
+
+**Positive:**
+
+- Each workflow has inputs that fit its language, and a consumer of one never
+  sees the inputs of the other.
+- Only current tools run; a run is reproducible because every version is exact.
+- The scripts are files that are linted and tested with stub tools, as for
+  `quality-checks.yml`.
+
+**Negative:**
+
+- Two workflows, two guides and two wiki pages to keep; a repository with both
+  languages calls both.
+- Without `cppcheck` the C++ checks are `clang-tidy` and the compiler only; a
+  defect class that `cppcheck` finds may go unchecked.
+- A C# check needs the network for the package restore, and a C++ check needs
+  the caller to build a compile database for precise results; both are the
+  caller's responsibility and are said in the guides.
+- Raising the exact default of a tool, including the SDK, is a breaking
+  change and costs a major version (ADR-0006).
+- A caller pinned to an exact tag is pinned completely only when `tools-ref`
+  names the same tag (as for `quality-checks.yml`).
+- Security: each run downloads and executes code from outside the repository
+  (wheels from PyPI and the `dotnet-install.sh` script from `dot.net`, and for
+  C# the NuGet packages of the project). Exact versions limit what can change
+  but are not verified against a hash, so a compromised package index or
+  download host would reach the run. The jobs get `contents: read` and no
+  secret, which limits what such code can do.
+
+## Affected Artifacts
+
+- [MIL-007] — decides its criterion 2 and unlocks tasks 4 and 5.
+- [UC-005] — the use case these workflows serve.
+- [US-001] — US-001.16 and US-001.17 state their acceptance criteria.
+- [ADR-0005] — the contract that this decision extends, unchanged.
+- [ADR-0006] — raising a default tool version is breaking.
+
+---
+
+[MIL-007]: ../milestones/mil-007-cpp-csharp-quality-checks.md
+[UC-005]: ../uc-005/uc.md
+[US-001]: ../user-stories.md
+[ADR-0005]: ./adr-0005-quality-check-contract.md
+[ADR-0006]: ./adr-0006-release-process-and-version-pinning.md
+[11cba35]: https://git.tirsystem.com/TirSystem/github-action/commit/11cba358b83cb7b6624f6b0956ae7b0c112d3692
+[9e7aedd]: https://git.tirsystem.com/TirSystem/github-action/commit/9e7aeddb11c2b41ac893d9f7893d663a53fbe470

docs/adr/adr-0009-wiki-publishing-reusable-workflow.md

@@ -0,0 +1,104 @@
+# ADR-0009: Wiki publishing as a reusable workflow
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | ADR-0009 |
+| CrossReference | [MIL-008], [ADR-0003], [ADR-0004], [ADR-0005], [ADR-0006] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Deprecated | Jens Tirsvad Nielsen | S01 | Initial version | [01b9c29] |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S01 | Review findings fixed (RC-063): the product owner's language is spelled out, the security consequence is named, and the secret passing is recorded as verified | [8c2c52e] |
+
+Allowed Status values: `Proposed`, `Accepted`, `Rejected`, `Deprecated`, `Superseded by ADR-NNNN`.
+
+---
+
+## Context
+
+[ADR-0004] chose a scoped workflow to publish wikis: Gitea runs it in every
+repository of an organisation, and a marker file `wiki/.publish` is the opt-in.
+That avoids a copy of the workflow, but it runs where nobody asked for it and
+needs a safety gate for that reason; its trigger path (`wiki/**`) and the
+version of the script (`v1`) are fixed centrally. The framework now prescribes
+the wiki in `docs/wiki/` with English and the product owner's language as a
+minimum, and
+repositories need to say where their wiki is.
+
+Options:
+
+1. **Keep the scoped workflow and read both folders.** No file in consumers,
+   but the central trigger lists every location and the gate stays.
+2. **A reusable workflow (`workflow_call`) that each repository calls.** One
+   source in this repository, called as `uses: ...@v1` the way
+   `quality-checks` and `release` already are ([ADR-0005], [ADR-0006]). The
+   caller sets its own trigger paths and the folder.
+
+## Decision
+
+Wiki publishing is the reusable workflow `publish-wiki-pages.yml`, called by
+each repository that wants a published wiki; the caller file is the opt-in and
+`docs/wiki/` is the default folder. The scoped `publish-wiki.yml` and the
+`wiki/.publish` marker are deprecated and stay until every publishing repository
+has a caller; they are then removed in a later major release.
+
+The rules that follow from it:
+
+- Inputs: `wiki_dir` (default `docs/wiki`), `prune` (default `false`) and
+  `tools-ref` (default `v1`). The secret `TOKEN_FOR_GITEA_WIKI` is declared and
+  passed by the caller; there is no fallback to another token.
+- With the reusable workflow the marker is not read: the script treats the
+  `prune` input as the setting, and a missing folder is a configuration error
+  rather than a skip, because the caller asked for it.
+- The script, the page-title rules, the empty-folder protection and the error
+  categories of [ADR-0004] and [ADR-0003] are unchanged.
+
+## Consequences
+
+**Positive:**
+
+- A repository states its own folder and trigger paths, so the wiki can move
+  to `docs/wiki/` one repository at a time.
+- Opting in is a file in the repository, reviewed in a pull request, and a
+  repository without a caller is never written to.
+- Security: the token is passed explicitly by the caller and is never
+  inherited or taken from a fallback, so a repository that does not pass it
+  cannot write a wiki.
+- One call convention for every shared workflow of this repository.
+
+**Negative:**
+
+- Every publishing repository needs a caller file, and the removal of the
+  scoped workflow stops publishing in any repository that still relies on the
+  marker; the list of those repositories is taken before the removal.
+- Eight repositories still publish through the scoped workflow (checked on
+  2026-10-13), so it is deprecated and not removed here; removing it is a
+  breaking change under [ADR-0006] and belongs to a follow-up milestone with
+  their migrations.
+- The owner chose a patch release (1.2.2) for this change although a new
+  workflow is a minor one under [ADR-0006]; the changelog states the deviation.
+- Anyone who can change the caller file of a repository can change the folder
+  and `prune`, and so what the token deletes in that repository's wiki; this is
+  the same exposure as the marker had, and it is reviewed through the pull
+  request that changes the caller.
+- Passing a declared secret through `workflow_call`, and a local `uses:` call,
+  were verified on this Gitea instance by run 316 of this repository on
+  2026-10-13.
+
+## Affected Artifacts
+
+- [MIL-008] — the plan this decision belongs to.
+- [ADR-0004] — its scoped delivery and marker parts are replaced once the
+  scoped workflow is removed; its token and safety rules stand.
+
+---
+
+[MIL-008]: ../milestones/mil-008-wiki-reusable-workflow.md
+[ADR-0003]: ./adr-0003-wiki-publish-token.md
+[ADR-0004]: ./adr-0004-shared-wiki-publishing-opt-in.md
+[ADR-0006]: ./adr-0006-release-process-and-version-pinning.md
+[ADR-0005]: ./adr-0005-quality-check-contract.md
+[01b9c29]: https://git.tirsystem.com/TirSystem/github-action/commit/01b9c2972b4317bcc590540010aea0eaf7f30014
+[8c2c52e]: https://git.tirsystem.com/TirSystem/github-action/commit/8c2c52ebd2a27e4d0edb4008c31c002718d280fb

docs/adr/adr-0010-code-metrics-badges-contract.md

@@ -0,0 +1,217 @@
+# ADR-0010: Contract of the code metrics and coverage badges workflow
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | ADR-0010 |
+| CrossReference | [MIL-010], [UC-008], [US-001], [ADR-0005], [ADR-0006] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Deprecated | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; reviewed (RC-072) | [0dc5132] |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | The report reaches the workflow as an artifact of the caller's run (input `coverage-artifact`), because a called workflow runs in its own job; reviewed (RC-073) | [0dc5132] |
+
+Allowed Status values: `Proposed`, `Accepted`, `Rejected`, `Deprecated`, `Superseded by ADR-NNNN`.
+
+---
+
+## Context
+
+MIL-010 adds a reusable workflow that shows the size of a repository's code
+and its test coverage as badges (UC-008, US-001.18 to US-001.20). ADR-0005
+defines the contract of the quality-check workflow: inputs with working
+defaults, a pinned version per tool, a failure that names the cause, and a
+script file of this repository, fetched at `tools-ref`, that the workflow runs.
+Decisions the user took in chat on 2026-10-14 bound this one: the counter is a
+Python script of this repository with no dependency outside the standard
+library, the delivery is a reusable workflow, the badges are committed to a
+`badges` branch, there are three badges (code files, lines of code, coverage),
+and the coverage report is read in the Cobertura XML format.
+
+Options for the counter:
+
+1. **Wrap `cloc`, `tokei` or `scc`.** Many languages, mature rules, but a tool
+   to install and pin on every run and a download from outside the instance.
+2. **A Python script of this repository.** No install, fully tested offline,
+   and the rules are ours; fewer languages and simple scanning rules.
+
+Options for the delivery of the badges: a run artifact (disappears and has no
+stable URL), a file on the default branch (a commit per change on the branch
+that protects the code), or a dedicated branch (stable raw URL, no effect on
+the default branch).
+
+Facts: the job of a reusable workflow runs on `ubuntu-latest` with `python3`
+3.12; a push made with the token of a run does not start another run; a
+workflow checks the shared scripts out into the workspace (`shared-scripts`),
+so the counter must not count them.
+
+## Decision
+
+A reusable workflow `code-metrics.yml` runs three script files of this
+repository, fetched at its input `tools-ref` (default `v1`): `tools/count_loc.py`
+counts the code, `tools/badges.py` reads the coverage report and writes the
+badges, and `tools/code-metrics.sh` validates the inputs, calls both and
+publishes the badge files to the `badges` branch of the calling repository
+with the token of the run (`contents: write`, no other permission).
+
+The rules that follow from it:
+
+- **Code file.** A file under `working-directory` whose extension is in the
+  language table below, that is not excluded, and that contains no NUL byte
+  (it is text; it is read as UTF-8 and invalid bytes are replaced). Its
+  language comes from the extension. A file with a code extension but no
+  line is still a code file.
+- **Languages and comments (first version).**
+
+  | Language | Extensions | Line comment | Block comment |
+  | --- | --- | --- | --- |
+  | Python | `.py` | `#` | none |
+  | Shell | `.sh`, `.bash` | `#` at the start of a word | none |
+  | PowerShell | `.ps1`, `.psm1` | `#` | `<#` ... `#>` |
+  | C | `.c`, `.h` | `//` | `/*` ... `*/` |
+  | C++ | `.cc`, `.cpp`, `.cxx`, `.hh`, `.hpp` | `//` | `/*` ... `*/` |
+  | C# | `.cs` | `//` | `/*` ... `*/` |
+  | Java | `.java` | `//` | `/*` ... `*/` |
+  | JavaScript | `.js`, `.mjs`, `.jsx` | `//` | `/*` ... `*/` |
+  | TypeScript | `.ts`, `.tsx` | `//` | `/*` ... `*/` |
+  | Go | `.go` | `//` | `/*` ... `*/` |
+  | Rust | `.rs` | `//` | `/*` ... `*/` |
+  | SQL | `.sql` | `--` | `/*` ... `*/` |
+
+  Markup, data and configuration files (Markdown, YAML, JSON, XML, HTML,
+  CSS) are not code files. A language is added by a minor release.
+- **Line classes.** Every physical line is exactly one of: *blank* (only
+  white space, also inside a block comment), *comment* (not blank, and only
+  comment text and white space), or *code* (anything else, including a line
+  with code and a trailing comment). A comment marker inside a string literal
+  is not a comment. String literals are the quoted forms of the language that
+  end on the same line, plus the Python triple-quoted string and the backtick
+  string of JavaScript, TypeScript and Go, which may span lines; a Python
+  docstring is a string and so counts as code.
+  Raw-string and verbatim forms that differ from these (Rust `r#"..."#`, C#
+  `@"..."` with doubled quotes, C++ raw strings) are scanned as ordinary
+  strings and can be mis-counted; this is a stated limit.
+- **Excluded by default.** Every directory whose name starts with `.`, and the
+  directories `node_modules`, `vendor`, `third_party`, `dist`, `build`, `out`,
+  `bin`, `obj`, `target`, `venv`, `__pycache__` and `shared-scripts`
+  (the checkout of the shared scripts); symbolic links are not followed. The
+  input `exclude` is a comma list of patterns that add to this: a pattern
+  without `/` matches a directory or file name anywhere, a pattern with `/`
+  matches the path relative to `working-directory` (`*` does not cross `/`).
+  The counter does not read `.gitignore` or generated-file markers; a caller
+  excludes generated code with `exclude`.
+- **Totals.** `files` is the number of code files and `lines` is the sum of
+  their code lines (comment and blank lines are not in it); the result also
+  holds `comment` and `blank` totals and the same four numbers per language,
+  sorted by language name, in `code-metrics.json`.
+- **Coverage report.** The input `coverage-report` is the path, relative to
+  the repository root, of a Cobertura XML file. The percentage is
+  `lines-covered / lines-valid` of the root `coverage` element, shown rounded
+  half up to a whole number; when a count is absent, `line-rate` is used.
+  A path that does not exist, a file that is not well-formed Cobertura XML,
+  and a report with no valid lines are failures with the category
+  `[configuration]` that names the file; no coverage badge is written. An
+  empty `coverage-report` means no coverage badge and a notice. The workflow
+  does not run tests. A called workflow runs in its own job, so it cannot see
+  the files of the caller's test job: the caller runs its tests in an earlier
+  job, uploads the report as an artifact and gives the artifact's name as the
+  input `coverage-artifact`. The workflow then downloads that artifact into
+  the directory `coverage-artifact` of its workspace and `coverage-report`
+  names the file inside the artifact. Without `coverage-artifact`,
+  `coverage-report` is a path in the checkout of the repository (a report the
+  repository commits). `coverage-artifact` without `coverage-report` is a
+  `[configuration]` failure.
+- **Badges.** Three flat SVG files with a label and a value, written to the
+  root of the `badges` branch with fixed names: `code-files.svg` (label
+  `code files`), `code-lines.svg` (label `lines of code`) and `coverage.svg`
+  (label `coverage`); the values are the whole number with `,` between groups
+  of three digits and, for coverage, `%`. The value colour of the first two is
+  blue `#007ec6`; coverage is red `#e05d44` below the input `coverage-warn`
+  (default `60`), yellow `#dfb317` from there to below `coverage-good`
+  (default `80`) and green `#44cc11` from `coverage-good`. Each file has
+  `role="img"`, a `<title>` and an `aria-label` with the same text, a width
+  computed from the number of characters (no font is measured) and no
+  timestamp, script or external reference, so the same numbers give the same
+  bytes.
+- **Publishing.** The `badges` branch holds only the three SVG files and
+  `code-metrics.json`; the script creates it as an orphan branch when it does
+  not exist. It writes the files, and when none differs from the branch it
+  commits nothing and says so; otherwise one commit, message
+  `Update code metrics badges [skip ci]`, changes only those files. The
+  commit is made with the token of the run, which does not start another run;
+  the guide tells a caller to start the workflow on pushes to its default
+  branch only.
+- **Inputs.** `working-directory` (default `.`), `exclude` (default empty),
+  `coverage-report` (default empty), `coverage-artifact` (default empty),
+  `coverage-warn` (default `60`),
+  `coverage-good` (default `80`), `badges-branch` (default `badges`) and
+  `tools-ref` (default `v1`; pin it to the same exact tag as the workflow).
+  There is no tool version input: the tools are files of this repository and
+  Python 3 of the runner.
+- **Pass, fail, empty.** The run passes when the badges were written or were
+  already current. It fails with a `[configuration]` message that names the
+  input and the value for an input that is invalid (a threshold that is not a
+  number from 0 to 100, `coverage-warn` above `coverage-good`, a
+  `working-directory` that is not a directory, a branch name that is not a
+  valid branch name) and for a coverage report as above. A repository with no
+  code file passes with a notice and badges that show `0`.
+- **Not in the first version:** a badge per language (the JSON holds the
+  numbers), lcov and other report formats, branch or function coverage, and
+  counting only tracked files.
+
+## Consequences
+
+**Positive:**
+
+- No tool is installed and nothing is downloaded: a run needs only the
+  checkout, Python 3 and the instance, so the counter and the renderer are
+  fully testable offline with fixtures.
+- The same input gives the same bytes, so an unchanged repository produces no
+  commit and the `badges` branch history is the history of the numbers.
+- The badges have stable URLs on the instance and on the mirror, and nothing
+  on the default branch changes.
+- A broken or missing report is a failure that names the file, never a
+  misleading `0%`.
+
+**Negative:**
+
+- The counter knows only the listed languages and simple scanning rules; some
+  string forms are mis-counted (stated above), and results will differ a
+  little from `cloc` or `tokei`.
+- The workflow needs `contents: write`, which is more than the
+  `contents: read` of the quality checks; a caller that grants less cannot use
+  it. The write is limited to the `badges` branch by the script, not by the
+  host.
+- A caller must run its tests and produce a Cobertura XML report in an
+  earlier job and upload it as an artifact; other formats need a conversion
+  until a later release adds them. The download needs the artifact service
+  of the instance to serve a called workflow, which task 8 of MIL-010
+  verifies.
+- A fixed set of thresholds and colours; a caller can move the two thresholds
+  only.
+- Security: the script runs with a token that can write to the repository.
+  The files are ours and no code is downloaded (the artifact is a report that
+  is parsed as XML with entity declarations refused), but a caller that pins
+  `tools-ref` to a moving ref takes later changes of the script; the guide
+  says to pin the exact tag. The script writes only the four named files, and
+  the branch name input is validated so that it cannot name the default branch
+  (`main`, `master`) or a branch of the caller's code.
+
+## Affected Artifacts
+
+- [MIL-010] — decides its criterion 2 and unlocks tasks 4 to 6.
+- [UC-008] — the use case this workflow serves.
+- [US-001] — US-001.18 to US-001.20 state their acceptance criteria.
+- [ADR-0005] — the contract style that this decision follows, unchanged.
+- [ADR-0006] — adding a language, or changing a colour or a default, is a
+  release under its rules; raising a default threshold is breaking.
+
+---
+
+[MIL-010]: ../milestones/mil-010-code-metrics-badges.md
+[UC-008]: ../uc-008/uc.md
+[US-001]: ../user-stories.md
+[ADR-0005]: ./adr-0005-quality-check-contract.md
+[ADR-0006]: ./adr-0006-release-process-and-version-pinning.md
+[0dc5132]: https://git.tirsystem.com/TirSystem/github-action/commit/0dc5132a2ea419ba05035ee3594cec63335c240b

docs/artifact-registry.md

@@ -10,13 +10,13 @@ each document lives in *this* project and the next version to use.
 | BC | Business Case | docs/business-case.md | 002 |
 | SA | Stakeholder Analysis | docs/stakeholder-analysis.md | 002 |
 | PP | Project Plan | docs/project-plan.md | 002 |
-| MIL | Milestone / Gateway | docs/milestones/*.md | 008 |
-| RC | SQA Review Record | docs/sqa/reviews/rc-*.md | 054 |
+| MIL | Milestone / Gateway | docs/milestones/*.md | 012 |
+| RC | SQA Review Record | docs/sqa/reviews/rc-*.md | 077 |
 | TM | Traceability Matrix | docs/sqa/traceability-matrix.md | 002 |
-| ADR | Architecture Decision Record | docs/adr/adr-NNNN-*.md | 0008 |
+| ADR | Architecture Decision Record | docs/adr/adr-NNNN-*.md | 0011 |
 | UCD | Use Case Diagram | docs/use-case-diagram.md | 002 |
 | US | User Story | docs/user-stories.md | 002 |
-| UC | Use Case | docs/uc-NNN/uc.md | 008 |
+| UC | Use Case | docs/uc-NNN/uc.md | 009 |
 
 ## Languages
 

docs/business-case.md

@@ -9,8 +9,8 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-10 | Deprecated | Jens Tirsvad Nielsen | S01 | A mirrored repository has at most one GitHub push mirror; repositories without one are skipped | [0c06789] |
-| 2026-10-10 | Accepted | Jens Tirsvad Nielsen | S01 | Scope: wiki pages in English, Danish and Bahasa Malaysia | [08ef26a] |
+| 2026-10-10 | Deprecated | Jens Tirsvad Nielsen | S01 | Scope: wiki pages in English, Danish and Bahasa Malaysia | [08ef26a] |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Objective O5, scope item and success criterion 5: shared workflow for code metrics and coverage badges (MIL-010); reviewed (RC-067) | [5002450] |
 
 ---
 
@@ -59,6 +59,9 @@ made once.
   diagnosis for every workflow.
 - **O4:** Offer shared quality-check and release workflows, versioned so
   consumers can adopt changes deliberately.
+- **O5:** Offer a shared workflow that counts the code files and the lines of
+  code (without comment and blank lines) of a repository, reads its coverage
+  report and publishes the three results as SVG badges.
 
 ## Scope
 
@@ -68,6 +71,7 @@ made once.
 - Documentation for DevOps professionals and software engineers.
 - A Gitea wiki with the same documentation in English, Danish and Bahasa Malaysia (MIL-005).
 - Validation of workflow files and their documentation.
+- A shared workflow for code metrics and coverage badges (MIL-010).
 
 ### Out of Scope
 
@@ -104,6 +108,7 @@ accepted plans.
 | 2 | Canonical copies per workflow | 1 | Count of files per workflow name |
 | 3 | Documented use cases that are implemented or marked planned | 100% | README capability table against workflows present |
 | 4 | Repositories consuming a shared workflow | At least 1 besides this one by MIL-002 | Consumer list in README |
+| 5 | Repositories that show the code metrics and coverage badges from the shared workflow | At least 1 besides this one by MIL-010 | README of the consuming repository |
 
 ## Risks
 
@@ -149,5 +154,5 @@ Proceed — the first milestone fixes a known defect in the only existing workfl
 ---
 
 [SA-001]: ./stakeholder-analysis.md
-[0c06789]: https://git.tirsystem.com/TirSystem/github-action/commit/0c06789a2779382672712cd483f4964b28a0ebe9
 [08ef26a]: https://git.tirsystem.com/TirSystem/github-action/commit/08ef26a6d3eb98c066b45634c2271e578e6c0a0b
+[5002450]: https://git.tirsystem.com/TirSystem/github-action/commit/50024505fe788b1c5e3021c0d1fc3d079590070e

docs/milestones/mil-006-shared-wiki-publishing.md

@@ -9,8 +9,8 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-10 | Deprecated | Jens Tirsvad Nielsen | S01 | Target date 2026-12-26 confirmed on 2026-10-10 by S01 (stand-in for S05) | [ea06eaa] |
-| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Criterion 1 evidence amended; added the verification results of the pilot | [d575f27] |
+| 2026-10-11 | Deprecated | Jens Tirsvad Nielsen | S01 | Criterion 1 evidence amended; added the verification results of the pilot | [d575f27] |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Task 6 added and reviewed (RC-058): the publisher sends page titles with spaces, so a hyphenated page (`Home-da`) is stored as `Home-da.md` and its links resolve | [8051cc4] |
 
 ---
 
@@ -71,6 +71,7 @@ repository other than this one that publishes its wiki through it.
 | 3 | Implement the opt-in gate and the safety limits | Skip, successfully and with a log line, any repository that has not opted in. Keep the refusal on an empty `wiki/` and the categorised errors, and add offline tests with a fake Gitea for opted-in, not opted-in and missing-secret runs. | No | |
 | 4 | Pilot in one other repository | Choose one repository outside this one, add a `wiki/` folder with the marker, store `TOKEN_FOR_GITEA_WIKI` in its organisation (S03), publish, and read the pages back. Also confirm that a repository without the marker was not touched. | No | |
 | 5 | Update the guides and the wiki | Describe how a repository opts in and which secrets its organisation needs in the onboarding and credentials guides, regenerate the wiki pages and update the Danish and Bahasa Malaysia translations (rule 8 of `AGENTS.md`). | No | |
+| 6 | Fix the page title of hyphenated pages | Gitea keeps a hyphen in a title literal, so the publisher created `Home-da` as `Home-da.-.md`, addressed `Home%2Dda`, and every link to `Home-da` led to the page list (found on the `sqa-and-qc`, `sqa-qc-framework` and `sqa-qc-checklists` wikis). Send the title with spaces (`Home da`, stored `Home-da.md`), cover it with a test and a changelog entry. The stale `*.-.md` pages are deleted after the release, by hand. | No | |
 
 ## Verification results
 
@@ -95,3 +96,4 @@ the API and equal `wiki/*.md` on `main` (0 differences).
 [ADR-0002]: ../adr/adr-0002-s01-approves-as-stand-in.md
 [ea06eaa]: https://git.tirsystem.com/TirSystem/github-action/commit/ea06eaaa698247d20e4a8e2694d7acbb1de58b63
 [d575f27]: https://git.tirsystem.com/TirSystem/github-action/commit/d575f272fcb044e3165951013464177a6e659ea6
+[8051cc4]: https://git.tirsystem.com/TirSystem/github-action/commit/8051cc4489ee9bcf3b6c62f2eafcb2013b7d2f90

docs/milestones/mil-007-cpp-csharp-quality-checks.md

@@ -4,13 +4,13 @@
 | Key | Value |
 | --- | --- |
 | ID | MIL-007 |
-| CrossReference | [BC-001], [US-001], [UC-005], [MIL-003], [MIL-004], [ADR-0005], [ADR-0006] |
+| CrossReference | [BC-001], [US-001], [UC-005], [MIL-003], [MIL-004], [ADR-0005], [ADR-0006], [ADR-0008] |
 
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-11 | Deprecated | Jens Tirsvad Nielsen | S01 | Reviewed (RC-052) and accepted; target date 2027-01-16 confirmed by S01 (stand-in for S05) | [e3ad1fa] |
-| 2026-10-11 | Proposed | Jens Tirsvad Nielsen | S01 | Added the verification results of task 2 (runner tools) | [32b5ab6] |
+| 2026-10-13 | Deprecated | Jens Tirsvad Nielsen | AI as stand-in for S01 | Task 7 results added and reviewed (RC-059): adoption in two throwaway repositories, seeded failures verified, a guide gap fixed | [2481c26] |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Throwaway repositories of task 7 deleted at the user's request; action item of RC-059 closed | [daecb7b] |
 
 ---
 
@@ -27,13 +27,15 @@ set of inputs and pinned tool versions, a guide for reading its results on the
 wiki in English, Danish and Bahasa Malaysia, a use of each in at least one
 other repository, and a release that makes them available at the major tag.
 The existing workflow `quality-checks.yml` for Python and shell keeps its
-name and contract.
+name and contract. The workflows run current tools only: a .NET SDK of version
+10 or later, and the latest stable release of each clang tool; a tool that
+is only available as an old version is not used.
 
 ## Go / No-Go Criteria
 
 | # | Criterion (objectively checkable) | Go | No-Go |
 | --- | --- | --- | --- |
-| 1 | The runner of the instance can run the tools of each language (installed in the run or provided by the image), verified and recorded | Verified for both | A tool cannot be had without changing the runner |
+| 1 | The runner of the instance can run the tools of each language (installed in the run or provided by the image), verified and recorded | Verified for both, at current versions (.NET SDK 10 or later) | A tool cannot be had without changing the runner, or only as an old version |
 | 2 | The contract (tools, versions, inputs, what a pass and a fail mean) is decided in an ADR, and a language that cannot be checked without a build system says what it needs | ADR accepted | Open |
 | 3 | A failing check shows the tool, file and line in the log, verified with a seeded failure for each workflow | Verified | Cause not visible |
 | 4 | One other repository runs each workflow and its status appears on pull requests | Appears for both | Does not run |
@@ -69,11 +71,11 @@ name and contract.
 
 | # | Task | Summary | Needs its own Use Case/User Story? | Reference |
 | --- | --- | --- | --- | --- |
-| 1 | Write the use case and stories for C++ and C# checks | Extend UC-005 (Run Project Quality Checks) so that its Brief names C++ and C#, and add stories to US-001 for a C++ project and a C# project, each with a pass and a fail acceptance criterion. Review them with the checklists of the `artifact` skill. | Yes | UC-005, US-001.09, US-001.10 |
+| 1 | Write the use case and stories for C++ and C# checks | Extend UC-005 (Run Project Quality Checks) so that its Brief names C++ and C#, and add stories to US-001 for a C++ project and a C# project, each with a pass and a fail acceptance criterion. Review them with the checklists of the `artifact` skill. | Yes | UC-005, US-001.09, US-001.10, US-001.16, US-001.17 |
 | 2 | Verify what the runner provides | On a throwaway branch, run a job on `ubuntu-latest` that prints which of `clang-format`, `clang-tidy`, `cppcheck` and the .NET SDK (`dotnet --version`) exist, and whether each can be installed in the run (for example from PyPI, apt or the dotnet install script) and how long that takes. Record the result in the milestone like MIL-003 task 1. | No | |
-| 3 | Decide the contract | Record an ADR that decides: one workflow for both languages or one per language; the tools and pinned versions (C++: `clang-format --dry-run -Werror`, `clang-tidy`, `cppcheck` or compiler warnings; C#: `dotnet format --verify-no-changes`, a build with analyzers and warnings as errors); the inputs (languages or paths, working directory, build command or compile database); what a build-dependent check needs from the caller; whether C is included with C++; and the names of the workflows and wiki pages (they follow `QualityChecksPythonShell`). Must be accepted before tasks 4 and 5. | No | ADR-0005 (refined) |
-| 4 | Implement the C++ workflow | Add the reusable workflow and its script file `tools/quality-checks-cpp.sh` (or as the ADR decides), pinned tool versions, least-privilege permissions and offline tests with stub tools, as `quality-checks.yml` does. | No | |
-| 5 | Implement the C# workflow | The same for C#, with its script file and tests. | No | |
+| 3 | Decide the contract | Decided in ADR-0008 (accepted on 2026-10-11, RC-054): two separate reusable workflows, `quality-checks-cpp.yml` for C and C++ and `quality-checks-csharp.yml`, each running a script file fetched at `tools-ref`; C++: `clang-format --dry-run -Werror` and `clang-tidy` at exact current versions, no `cppcheck`; C#: `dotnet format --verify-no-changes` and a build with analyzers and warnings as errors, with the .NET SDK installed at an exact `10.0.x`; the inputs, the names of the workflows, guides and wiki pages and the consequences are in the ADR. | No | ADR-0008 |
+| 4 | Implement the C++ workflow | Add the reusable workflow `quality-checks-cpp.yml` and its script file `tools/quality-checks-cpp.sh` as ADR-0008 decides, exact tool versions, least-privilege permissions and offline tests with stub tools, as `quality-checks.yml` does. | No | |
+| 5 | Implement the C# workflow | The same for C#: `quality-checks-csharp.yml`, `tools/quality-checks-csharp.sh` and tests, as ADR-0008 decides. | No | |
 | 6 | Write the guides and the wiki pages | One guide per workflow in `guides/` for reading its results, the wiki pages in English, Danish and Bahasa Malaysia, the Home workflow list and diagrams (a test requires every workflow to be listed), and an update of the upgrade guide. | No | |
 | 7 | Adopt each workflow in one other repository | Onboard a real C++ project and a real C# project, or a throwaway repository when none exists, and fix the gaps in the guides that appear. Verify a seeded failure. | No | |
 | 8 | Release | Add the changelog entry (a new workflow is a minor change, ADR-0006) and run the Release workflow; record the results in this milestone and review it. | No | |
@@ -90,13 +92,19 @@ tool.
 | Image | Ubuntu 24.04, `x86_64`, the job runs as root, `sudo`, `curl`, `python3` 3.12 and `pip` present |
 | Present in the image | `gcc` and `g++` 13.3, `make`; missing: `clang-format`, `clang-tidy`, `cppcheck`, `cmake`, `dotnet` |
 | `clang-format` | from PyPI in 2 s (23.1.3); from apt in 9 s |
-| `clang-tidy` | from PyPI in 5 s; from apt in 25 s |
-| `cppcheck` | from apt in 6 s (2.13.0); no PyPI package found under `cppcheck-wheel` |
-| .NET SDK | from apt `dotnet-sdk-8.0` in 24 s (8.0.131); from the official script `dot.net/v1/dotnet-install.sh` with `--channel 8.0` in 25 s (8.0.425) |
+| `clang-tidy` | from PyPI in 5 s (22.1.8); from apt in 25 s |
+| `cppcheck` | apt gives 2.13.0 in 6 s, which is old (the latest release is 2.22.0); the PyPI package named `cppcheck` is a different project (1.5.3) and is not used; a current release needs a build from source |
+| .NET SDK | the official script `dot.net/v1/dotnet-install.sh` with `--channel 10.0` gives 10.0.401 in 20 s; apt `dotnet-sdk-10.0` gives 10.0.112 in 23 s, an older feature band; the same script also offers 11.0 as a release candidate, which is not used |
 
-So every tool can be had in the run in under 30 seconds each with no change to
-the runner, either from PyPI (the clang tools, as `quality-checks.yml` already
-does for its tools, with an exact version) or from apt and the official script.
+A first run (run 692) looked at .NET SDK 8, which is not used: the requirement
+is a .NET SDK of version 10 or later, and old tools are not run. A second run
+(run 699, also deleted afterwards) checked current versions. The current
+clang tools come from PyPI in a few seconds with an exact version, as
+`quality-checks.yml` already does for its tools, and the .NET SDK 10 comes from
+the official script in 20 s, with no change to the runner. `cppcheck` is the
+exception: only an old version is a package. ADR-0008 drops it, because
+`clang-tidy` does the static analysis and a current `cppcheck` would have to
+be built from source, which costs minutes per run.
 Not covered by this task: running a tool against a real C++ project (a
 `clang-tidy` run needs a compile database or flags) or a real C# solution
 (`dotnet format` and a build need the project's restore of packages from the
@@ -104,6 +112,30 @@ network), a private runner with no internet, and an image that differs from
 `ubuntu-latest`. Those belong to the contract (task 3) and to the adoption
 (task 7).
 
+Task 7 was run on 2026-10-13 in two throwaway private repositories of the
+organisation, `TirSystem/qc-adoption-cpp` and `TirSystem/qc-adoption-csharp`
+(no real C++ or C# project exists there; the user chose throwaways in chat).
+Each holds a small passing project, a style file, and a workflow that calls the
+released `v1.2.0` (`quality-checks-cpp.yml`, `quality-checks-csharp.yml`) with
+the guide's call. A branch `seeded-failure` with a pull request added a
+formatting error and a null dereference.
+
+| Repository | Baseline on `main` | Seeded failure (pull request 1) |
+| --- | --- | --- |
+| `qc-adoption-cpp` | Pass (runs 899, 900) | Fail (run 906): `main.cpp:3:13: error: code should be clang-formatted`, `main.cpp:5:18: error: Dereference of null pointer ... [clang-analyzer-core.NullDereference]`, `FAIL clang-format`, `FAIL clang-tidy (C++)`, last line `Quality checks failed: clang-format clang-tidy (C++)` |
+| `qc-adoption-csharp` | Pass (runs 901, 902) | Fail: `src/Program.cs(5,3): error WHITESPACE`, `src/Program.cs(8,27): error CS8602`, `FAIL dotnet format --verify-no-changes`, `FAIL dotnet build -warnaserror` |
+
+Both statuses (`quality` and `quality-checks-cpp` / `quality-checks-csharp`)
+appear on the pull requests. One gap in the guides was found and fixed: they
+said the paths are relative to `working-directory`, but `clang-tidy` and
+`dotnet` print absolute paths in the workspace of the runner. The guides and
+their three wiki languages now say so.
+
+Not covered: a real C++ project with a compile database and a real C# solution
+with many packages; both stay open until a project of that kind adopts the
+workflows. The throwaway repositories were deleted at the user's request on 2026-10-13;
+the run numbers above are kept as the record.
+
 ---
 
 [BC-001]: ../business-case.md
@@ -113,5 +145,8 @@ network), a private runner with no internet, and an image that differs from
 [MIL-004]: ./mil-004-versioned-release.md
 [ADR-0005]: ../adr/adr-0005-quality-check-contract.md
 [ADR-0006]: ../adr/adr-0006-release-process-and-version-pinning.md
-[e3ad1fa]: https://git.tirsystem.com/TirSystem/github-action/commit/e3ad1fa7e7eef57a6793a479edb41ac6fd2db688
-[32b5ab6]: https://git.tirsystem.com/TirSystem/github-action/commit/32b5ab62ab5a82638b71b8fcfb43a819e92ab346
+[ADR-0008]: ../adr/adr-0008-cpp-csharp-quality-check-contract.md
+[7bcc67a]: https://git.tirsystem.com/TirSystem/github-action/commit/7bcc67a065ac5f67b4e13ebf243a4bbbe2af47d9
+[faf13b2]: https://git.tirsystem.com/TirSystem/github-action/commit/faf13b2c2a4901c0171977de1ffc2841023f537a
+[2481c26]: https://git.tirsystem.com/TirSystem/github-action/commit/2481c26d802464decd51d75539157093b60e08e8
+[daecb7b]: https://git.tirsystem.com/TirSystem/github-action/commit/daecb7b452197643b39752b9b453a8c376562354

docs/milestones/mil-008-wiki-reusable-workflow.md

@@ -0,0 +1,86 @@
+# MIL-008: Wiki publishing as a reusable workflow
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-008 |
+| CrossReference | [BC-001], [MIL-006], [ADR-0004], [RC-060], [RC-061] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Deprecated | Jens Tirsvad Nielsen | S01 | Initial version; reviewed (RC-060) | [01b9c29] |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S01 | Task 5 changed to deprecate the scoped workflow (8 repositories still use it); reviewed (RC-061) | [01b9c29] |
+
+---
+
+## Purpose
+
+Decide whether the wiki can be published by a reusable workflow that each
+repository calls, from `docs/wiki/` (the location `process/wiki.md` of the
+framework prescribes), instead of a scoped workflow that runs in every
+repository of the organisation and reads `wiki/`.
+
+## Deliverable
+
+A reusable workflow `publish-wiki-pages.yml` in `.gitea/workflows/` with a
+`wiki_dir` input, a caller template for projects, offline tests, a superseding
+ADR, updated guides and wiki pages, this repository publishing its own wiki
+from `docs/wiki/` through it, the scoped workflow marked deprecated (not
+removed), and a release that projects can pin.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | The reusable workflow publishes the folder named by `wiki_dir` (default `docs/wiki`), and a repository that has no caller workflow is never written to | Offline tests pass; no caller means no run | Any write without a caller |
+| 2 | An empty or missing folder never deletes pages, the failure names its category, and the secret is passed explicitly (criteria 1 and 4 of MIL-006 still hold) | Existing tests pass unchanged | A regression |
+| 3 | This repository publishes its own wiki from `docs/wiki/` through a caller that uses the reusable workflow, and the pages on the host equal the folder | 0 differences read back through the API | Pages differ or the run fails |
+| 4 | A caller template exists for projects, with the trigger `docs/wiki/**` and the secret named | File exists and is linted (QC-WF-001) | Missing |
+| 5 | The scoped `publish-wiki.yml` is marked deprecated in its header, the README and ADR-0009, and the repositories that still use it are listed; it is not removed here | Notice present and the list recorded (8 repositories on 2026-10-13) | No notice, or the workflow was removed while a repository still depends on it |
+| 6 | The change is released as patch 1.2.2 and the moving major tag points at it | `v1` includes the change | Not released |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| MIL-006 | The publisher script, the prune rule and the safety limits come from it |
+| `TirSystem/sqa-qc-framework` `process/wiki.md` | Defines `docs/wiki/` and the English plus PO language minimum; unmerged when this was written |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O2, O3 | [BC-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S05 |
+| Approving reviewer | S01 |
+
+## Target Date
+
+2026-11-15 — the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Record the decision | An ADR that supersedes the scoped-delivery part of ADR-0004: publishing is a reusable workflow called by each repository; the caller file is the opt-in, so `wiki/.publish` is no longer a gate; the `prune` setting becomes an input. Keep the rest of ADR-0004 (secret handling) as it stands. | No | |
+| 2 | Add the reusable workflow | `.gitea/workflows/publish-wiki-pages.yml` with `on: workflow_call`, inputs `wiki_dir` (default `docs/wiki`) and `prune`, and the token as a declared secret. It runs `tools/publish_wiki.py` with `WIKI_DIR` and the prune setting from the inputs. Update the script and its tests: the marker is no longer required. | No | |
+| 3 | Add the caller template | A `publish-wiki.yml` caller for projects (`uses: TirSystem/github-action/.gitea/workflows/publish-wiki-pages.yml@v1`, `paths: docs/wiki/**`, `secrets:` mapped). Proposed in `sqa-qc-framework` under `templates/ci/` once this is released. | No | |
+| 4 | Move this repository's wiki and call the workflow | `git mv wiki docs/wiki`, check the links and the translation hash comments, add the caller, publish, read the pages back. | No | |
+| 5 | Deprecate the scoped workflow | Do not remove it: on 2026-10-13, 8 repositories still publish through it with `wiki/.publish` (`sqa-and-qc`, `sqa-qc-framework`, `sqa-qc-checklists`, `github-action`, `repo-foundry` and three of `Tirsvad-Udemy-100-days-of-code`), and none calls the reusable workflow yet. Add a deprecation notice to its header, the README table and ADR-0009, and record the list. The migrations and the removal are a follow-up milestone after this release (ADR-0006: a removed workflow is a new major). | No | |
+| 6 | Update guides and wiki pages | Describe the caller, `docs/wiki/` and the removed marker in the onboarding and credentials guides and in the English, Danish and Bahasa Malaysia pages (rule 8 of `AGENTS.md`). | No | |
+| 7 | Release | Release as a patch, 1.2.1 to 1.2.2, as the owner instructed: changelog entry and a release through the release workflow; the `v1` tag moves with it. ADR-0006 classes a new workflow as minor, so the changelog entry states the deviation and the reason. Nothing is removed, so no consumer breaks. | No | |
+
+---
+
+[BC-001]: ../business-case.md
+[MIL-006]: ./mil-006-shared-wiki-publishing.md
+[ADR-0004]: ../adr/adr-0004-shared-wiki-publishing-opt-in.md
+[RC-060]: ../sqa/reviews/rc-060-mil-008-plan.md
+[RC-061]: ../sqa/reviews/rc-061-mil-008-task-5-deferred.md
+[01b9c29]: https://git.tirsystem.com/TirSystem/github-action/commit/01b9c2972b4317bcc590540010aea0eaf7f30014

docs/milestones/mil-009-migrate-wiki-callers-and-remove-scoped-workflow.md

@@ -0,0 +1,109 @@
+# MIL-009: Migrate the wiki callers and remove the scoped workflow
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-009 |
+| CrossReference | [BC-001], [MIL-008], [ADR-0004], [ADR-0006], [ADR-0009] , [RC-066] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Deprecated | Jens Tirsvad Nielsen | AI as stand-in for S01 | Plan accepted in chat with the defaults: target date 2026-11-30 confirmed, `027-sandbox` and `028-pomodoro` do not publish, framework release 0.7.0; reviewed (RC-064) | [2f267df] |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Verification results recorded for tasks 1 to 8; outcome reviewed (RC-066) | [95abc18] |
+
+---
+
+## Purpose
+
+Decide whether the scoped `publish-wiki.yml` can be removed: every repository
+that publishes its wiki through it has moved to `docs/wiki/` and calls the
+reusable workflow `publish-wiki-pages.yml`, and ADR-0004 is superseded by
+ADR-0009. MIL-008 deprecated the scoped workflow and kept it because seven
+repositories still depended on it (checked on 2026-10-13).
+
+## Deliverable
+
+A released framework with the caller template; each of the seven repositories
+publishing its wiki from `docs/wiki/` through a caller, with its marker removed;
+the scoped workflow, its marker code path, its tests and every mention of the
+marker as an opt-in removed; ADR-0004 marked superseded; and the major release
+2.0.0 with the tag `v2`.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | The framework is released as 0.7.0 with `templates/ci/publish-wiki.yml` and `process/wiki.md`, as a tag | The tag exists and each migrating repository pins it | No tag, or a repository pins an unmerged commit |
+| 2 | Each of the seven repositories publishes from `docs/wiki/` through a caller of `publish-wiki-pages.yml`, and has no `wiki/.publish` | A scan of the instance lists the seven with a caller and no marker | Any marker or missing caller remains |
+| 3 | The wiki of each of the seven equals its `docs/wiki/` after the first run | 0 differences read back through the API for each | A difference, or a failed run |
+| 4 | A scan of every repository of the four organisations finds no `wiki/.publish` and no run of the scoped workflow that wrote | None found | Any found |
+| 5 | The scoped `publish-wiki.yml`, the marker code path of `tools/publish_wiki.py`, their tests and the marker text of the guides, README and wiki pages are removed | Offline tests pass; a search finds no `wiki/.publish` outside the changelog and ADRs | A mention remains, or a test fails |
+| 6 | ADR-0004 is `Superseded by ADR-0009` with a review record, and ADR-0009 links back | Both rows and RC present | Missing |
+| 7 | Release 2.0.0 is published with a Breaking entry, `v2` points to it, and `v1` still points to 1.2.2 | Tags read back through the API | `v1` moved, or no Breaking entry |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| MIL-008 | Provides the reusable workflow, the deprecation and the list of repositories |
+| `TirSystem/sqa-qc-framework` release | The caller template and `process/wiki.md` must be a tag before a repository pins them |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O2, O3 | [BC-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S05 |
+| Approving reviewer | S01 |
+
+## Target Date
+
+2026-11-30 — confirmed on 2026-10-14 by S01 in chat; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Release the framework | `TirSystem/sqa-qc-framework` has the caller template and `process/wiki.md` merged (pull request 45). Add the changelog entry, tag the release and record the tag. Needed before any repository pins the template. | No | |
+| 2 | Migrate the three TirSystem projects | `sqa-and-qc`, `sqa-qc-framework` and `sqa-qc-checklists`: move `wiki/` to `docs/wiki/`, copy the caller from `templates/ci/publish-wiki.yml`, remove `wiki/.publish`, fix the paths in their generators and documents, move the framework pin to the released tag, one pull request each. Confirm the organisation secret `TOKEN_FOR_GITEA_WIKI` is present. | No | |
+| 3 | Migrate `repo-foundry` | Same steps for `TirSystem-BashScript/repo-foundry` (21 wiki files); the organisation `TirSystem-BashScript` needs its own `TOKEN_FOR_GITEA_WIKI` secret (S03). | No | |
+| 4 | Migrate the three Udemy repositories | Same steps for `021-snake-game`, `024-snake` and `025-weather` of `Tirsvad-Udemy-100-days-of-code` (5 wiki files each). `027-sandbox` and `028-pomodoro`, which have `docs/wiki/` and no marker, do not publish (decided by S01 on 2026-10-14). | No | |
+| 5 | Verify the migration | After each first run read the wiki back and compare it with `docs/wiki/`; then scan the four organisations for `wiki/.publish` and for repositories still publishing through the scoped workflow. Record the results in this milestone. | No | |
+| 6 | Remove the scoped workflow | Delete `.gitea/scoped_workflows/publish-wiki.yml`, the marker path of `tools/publish_wiki.py` (the `WIKI_PRUNE` input becomes required), the tests that cover it and the marker text in the guides, the README and the three wiki languages. Keep the drift test for the remaining scoped workflow. | No | |
+| 7 | Supersede ADR-0004 | Mark ADR-0004 `Superseded by ADR-0009` for the delivery and marker parts (new version row, review record), and make ADR-0009 link back. | No | |
+| 8 | Release 2.0.0 | Breaking entry (a removed workflow and marker); upgrade guide for callers; release through the release workflow; `v2` is created and `v1` stays at 1.2.2. Move the examples in the guides to `@v2` where the guide describes the new major. | No | |
+
+---
+
+## Verification results
+
+Recorded on 2026-10-14 by the autonomous run.
+
+| # | Criterion | Result |
+| --- | --- | --- |
+| 1 | The framework is released as 0.7.0 with the template and `process/wiki.md`, and each repository pins it | Go: tag `v0.7.0` on `70fc558`. `sqa-and-qc`, `repo-foundry`, `021-snake-game`, `024-snake` and `025-weather` pin it; `sqa-qc-framework` and `sqa-qc-checklists` have no `framework/` submodule to pin |
+| 2 | Each of the seven repositories publishes from `docs/wiki/` through a caller and has no `wiki/.publish` | Go: `sqa-and-qc` #168, `sqa-qc-framework` #47, `sqa-qc-checklists` #17, `repo-foundry` #96, `021-snake-game` #29, `024-snake` #46, `025-weather` #31 |
+| 3 | The wiki of each equals its `docs/wiki/` after the first run | Go: 0 differences read back through the API (10, 16, 13, 19, 4, 4 and 4 pages); each first run succeeded |
+| 4 | A scan of every repository of the four organisations finds no `wiki/.publish` | Go: 48 repositories scanned, none found |
+| 5 | The scoped workflow, the marker path, their tests and the marker text are removed | Go with a note: pull request #151; `wiki/.publish` remains only in the changelog, the ADRs, the milestone and review records and the sentence of the upgrading guide that explains the removal |
+| 6 | ADR-0004 is `Superseded by ADR-0009` with a review record, and ADR-0009 links back | Go: RC-065 |
+| 7 | Release 2.0.0 is published with a Breaking entry, `v2` points to it, and `v1` still points to 1.2.2 | Go: `v2.0.0` and `v2` on `6e8e548`, `v1` and `v1.2.2` on `9bf0a2b`; the release page shows the Breaking group |
+
+Things that did not go as planned: the three Udemy pull requests were opened through a script that hit a network timeout once and was repeated; the `repo-foundry` test suite fails two tests on `main` and on the branch alike (pre-existing, not caused by this milestone).
+
+---
+
+[BC-001]: ../business-case.md
+[RC-066]: ../sqa/reviews/rc-066-mil-009-outcome.md
+[MIL-008]: ./mil-008-wiki-reusable-workflow.md
+[ADR-0004]: ../adr/adr-0004-shared-wiki-publishing-opt-in.md
+[ADR-0009]: ../adr/adr-0009-wiki-publishing-reusable-workflow.md
+[ADR-0006]: ../adr/adr-0006-release-process-and-version-pinning.md
+[2f267df]: https://git.tirsystem.com/TirSystem/github-action/commit/2f267df2a270087cb7dc482af4ce4f4341e97b03
+[95abc18]: https://git.tirsystem.com/TirSystem/github-action/commit/95abc18a95d70c065b979123b8f8de22173af90c

docs/milestones/mil-010-code-metrics-badges.md

@@ -0,0 +1,198 @@
+# MIL-010: Code metrics and coverage badges
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-010 |
+| CrossReference | [BC-001], [US-001], [MIL-003], [MIL-004], [ADR-0005], [ADR-0006] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Deprecated | Jens Tirsvad Nielsen | AI as stand-in for S01 | Results of tasks 3, 6 and 8 added: the report as an artifact of the caller (ADR-0010), adoption in a throwaway repository with seeded change and failure; reviewed (RC-074) | [5c5a1d1] |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Task 9 results added: released as 2.1.0; outcome reviewed (RC-075) | [aa20e56] |
+
+---
+
+## Purpose
+
+Decide whether a repository can show, as SVG badges, how many code files and
+how many lines of code (without comment and blank lines) it holds and how
+much of that code its tests cover, produced by one shared workflow of this
+repository, without a service outside the instance.
+
+## Deliverable
+
+A reusable workflow `code-metrics.yml` with a script file of this repository
+behind it, which counts the code files and the lines of code, reads the
+coverage report the caller supplies, writes the badges "code files", "lines
+of code" and "coverage" as SVG files and commits them to a `badges` branch of
+the calling repository. It comes with a documented set of inputs, a guide and
+wiki pages in English, Danish and Bahasa Malaysia, a use in at least one other
+repository, and a release that makes it available at the major tag. The
+existing workflows keep their names and contracts.
+
+Decisions taken by the user in chat on 2026-10-14, which the contract of task 2
+records and does not reopen:
+
+- The counter is a Python script of this repository with no dependency outside
+  the standard library (not `cloc`, `tokei` or `scc`).
+- The delivery is a reusable workflow (`workflow_call`), as the quality-check
+  workflows are.
+- The badges are committed to a `badges` branch, so a README can link to
+  them; they are not only a run artifact.
+- Three badges: code files, lines of code and coverage. A badge per language
+  is optional and is decided in the ADR of task 2.
+- The coverage report is read in the Cobertura XML format, which `coverage.py`,
+  `gcovr` and `coverlet` all write; the counter does not run tests itself, so a
+  caller that wants a coverage badge runs its tests first and passes the path
+  of the report.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | A job on the runner of the instance can push a commit to a `badges` branch of its own repository with the token the run provides, and the SVG renders as an image in a README on the instance and on the GitHub mirror, verified and recorded | Both render | The push needs a token with more than the contents of its own repository, or the image does not render |
+| 2 | The contract (what a code file is, what a comment and a blank line are for each language, excluded paths, generated and vendored files, the coverage report format, the badge colours and text) is decided in an ADR | ADR accepted | Open |
+| 3 | The counter gives the hand-counted numbers (files, code, comment, blank) for a fixture of each supported language, including a block comment, a trailing comment, a comment marker inside a string and a file with no final newline | Equal for every fixture | Any difference |
+| 4 | The coverage reader gives the percentage of the fixture reports, and a missing or malformed report is a failure that names the file, never a badge showing 0% | Verified | A bad report produces a badge |
+| 5 | The badges are valid SVG, carry a title and a text alternative, have a fixed width per text, and are byte-identical for the same input | Verified | Not valid or not stable |
+| 6 | The workflow commits nothing when no badge changed, does not start itself again from its own push, and asks for the least permission that writes to its own repository | Verified in a run | A loop, or a wider permission |
+| 7 | One other repository runs the workflow and its README shows the three badges, with a seeded change that moves the coverage badge to another colour | Shown | Does not run or does not change |
+| 8 | The workflow embeds no script: it runs a file of this repository, and the offline tests exercise the file | Count of embedded scripts is 0 | Embedded script remains |
+| 9 | A release (a minor version) makes it available, and the changelog, the README workflow table and the wiki name it | Released | Unreleased |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| MIL-003 | The reusable workflow mechanism, the `tools-ref` input and the guide for reading results |
+| MIL-004 | The release process and the release workflow publish the result |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| O5 (added to the Business Case in the same change as this milestone) | [BC-001] |
+| New stories of task 1, to be written in US-001 | [US-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S05 |
+| Approving reviewer | S01 |
+
+## Target Date
+
+2027-01-30 — it follows the last decision of the plan, 2027-01-16, with two
+weeks from 2027-01-18; proposed by the AI and accepted by the user in chat on
+2026-10-14, recorded by the AI as stand-in for S05 (ADR-0002). The Business
+Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Write the use case and stories for the metrics badges | Add a use case "Show code metrics and coverage badges" for the software engineer, add it to the use case diagram, and add stories to US-001: the badges appear after a push, a coverage report that is missing or malformed fails with the file named, and nothing is committed when the numbers are unchanged. Each story has a pass and a fail acceptance criterion. Review them with the checklists of the `artifact` skill. | Yes | US-001 |
+| 2 | Decide the contract | Write an ADR with the definitions the counter needs (code file, comment, blank line, per language), the default includes and excludes, the languages of the first version, the Cobertura XML coverage input, the badge texts and colour thresholds, the inputs of the workflow, the name and content of the `badges` branch, and what a pass, a failure and a run without files mean, in the style of ADR-0005. Record the decisions of the Deliverable. | No | |
+| 3 | Verify the delivery on the instance | On a throwaway branch, run a job that commits an SVG to a `badges` branch with the token of the run, then check that the raw URL serves it as an image on the instance, that a README shows it, and that it also shows on the GitHub mirror. Record the result in this milestone like MIL-007 task 2, together with the permission that was needed. | No | |
+| 4 | Implement the counter | Add `tools/count_loc.py` and tests with a fixture per language under `tests/`: file and line counts split into code, comment and blank, an exclude list, and a machine-readable result on standard output. Standard library only, as the rules of the repository for tools say. | No | |
+| 5 | Implement the coverage reader and the badge renderer | Add the reader of the Cobertura XML report and the SVG renderer, with the failure cases of Go/No-Go criterion 4 and a stable output (criterion 5), each with offline tests. | No | |
+| 6 | Implement the workflow | Add the reusable workflow `code-metrics.yml` and its script file, which calls the counter, the reader and the renderer and commits to the `badges` branch as the contract of task 2 says, with least-privilege permissions and offline tests as `quality-checks.yml` has. | No | |
+| 7 | Write the guides and the wiki pages | A guide in `guides/` with the call, the inputs, how to produce a coverage report for Python, C++ and C#, and the Markdown line that shows the badges; the wiki pages in `docs/wiki` in English, Danish and Bahasa Malaysia; the README table and diagram and the wiki Home workflow list (a test requires every workflow to be listed). | No | |
+| 8 | Adopt the workflow in one other repository | Onboard a real repository, or a throwaway one when none fits, show the badges in its README and verify a seeded change that moves the coverage badge. Fix the gaps in the guide that appear. | No | |
+| 9 | Release | Add the changelog entry (a new workflow is a minor change, ADR-0006) and run the Release workflow; record the results in this milestone and review it. | No | |
+
+## Verification results
+
+Task 3 was run on 2026-10-14 with a throwaway branch, `verify-badges-delivery`,
+in `TirSystem/github-action` (run 1418, success). One job on `ubuntu-latest`
+with `permissions: contents: write` checked the repository out, created an
+orphan branch `badges-verify` with one SVG file and a commit message ending in
+`[skip ci]`, and pushed it with the token of the run (the credential that
+`actions/checkout` stores); it then requested the raw URL.
+
+| Fact | Result |
+| --- | --- |
+| Push with the token of the run | Accepted: `git push origin HEAD:refs/heads/badges-verify` created the branch; no secret and no personal access token was needed |
+| Raw URL on the instance | `https://git.tirsystem.com/TirSystem/github-action/raw/branch/badges-verify/code-files.svg` answers `200`, `Content-Type: image/svg+xml`, `Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; sandbox`, `Cache-Control: public, max-age=21600` (six hours) |
+| The branch on the GitHub mirror | The push mirror (`sync_on_commit`, every 8 h otherwise) copied the branch within seconds; `https://raw.githubusercontent.com/TirSystem/github-action/badges-verify/code-files.svg` answers `200`, `Content-Type: image/svg+xml`, `Cache-Control: max-age=300` |
+| Repository visibility | Public; a README image on GitHub reads the raw URL, which needs no token |
+
+The SVG is served as an image on both hosts, so it renders in a README on the
+instance and on the mirror; the content security policy rules out script and
+external references inside the file, as ADR-0010 requires. The six-hour
+cache on the instance means a changed badge can show the old number for up to
+six hours there; the guide says so. Not covered by this task: a private
+repository (the raw URL then needs a login, so a badge does not render for an
+anonymous reader), and the rendering inside a Gitea README, which is the same
+`<img>` request. The throwaway branches `verify-badges-delivery` and
+`badges-verify` are left in place because deleting a branch is an action the
+run stops on; they are listed in the summary for the user to delete.
+
+Task 6 changed the contract once while it was implemented. A called workflow
+runs in its own job, so it cannot read a report that the caller's test job
+wrote in its workspace; a report the repository commits is the only file it can
+see. ADR-0010 was amended (RC-073): the caller uploads the report as an
+artifact and names it in the new input `coverage-artifact`; the workflow
+downloads it with `actions/download-artifact` into the directory
+`coverage-artifact` and `coverage-report` names the file inside it. The scope
+and the three badges did not change.
+
+Task 8 was run on 2026-10-14 in a throwaway private repository of the
+organisation, `TirSystem/code-metrics-adoption` (no repository of a project
+fits, and the user's plan allows a throwaway). It holds a two-file Python
+module with tests and a workflow of two jobs: the tests with `pytest-cov`
+upload `coverage.xml` as the artifact `coverage`, and the second job calls
+`code-metrics.yml` and `tools-ref` of the branch `mil-010-implementation` of
+this repository, before its merge.
+
+| Step | Result |
+| --- | --- |
+| Baseline (run 1423) | All steps pass, including `Download the coverage report` with `actions/download-artifact@v4.1.8` on Gitea 1.27.3; the `badges` branch is created with one commit by `code-metrics` and the message `Update code metrics badges [skip ci]`; `code-files.svg` shows 2, `code-lines.svg` 28 (the hand count of the two files), `coverage.svg` 100% in green `#44cc11` |
+| The push of the badges | No run was started by it: the runs of the repository are the two of the push to `main` (the metrics workflow and the scoped sync) |
+| Seeded change (run 1425): two tests removed | The coverage badge reads 60% in yellow `#dfb317`; one new commit on `badges` that changes the badge files; the files and the lines badges changed with the tests |
+| Seeded failure (run 1429): `coverage-report` names a file that does not exist | The job `code-metrics` fails: `::error::[configuration] coverage-report 'coverage-artifact/nope.xml' does not exist.`; `badges` is unchanged (two commits) |
+| README | Its three Markdown images render as `<img>` of the raw URLs of the `badges` branch (checked with the markdown API of the instance); the raw URLs answer `image/svg+xml` as in task 3 |
+
+Not covered: a run that changes nothing (the unchanged case is covered by the
+offline tests, not by a run), two runs that write the branch at the same time
+(covered by an offline test with a rejecting remote, not on the instance), the
+rendering for a reader who is not signed in to a private repository, and a
+repository of a project with a real coverage report. The throwaway repository
+`TirSystem/code-metrics-adoption` is left in place because deleting a
+repository is an action the run stops on; it is listed in the summary for the
+user to delete.
+
+Task 9 was run on 2026-10-14. The implementation was merged in pull request
+164 after its checks were green; the user merged it, because the host refused
+the merge through the API with a required check `Publish wiki / *` that the
+branch protection API does not list and that nothing in this repository
+reports. The Release workflow was run for 2.1.0 on the merge commit
+`16faffa`: a dry run (run 1462) and then the release (run 1463), both green.
+
+| Check | Result |
+| --- | --- |
+| Tag | `v2.1.0` and the moved major tag `v2` both point at `16faffa` |
+| Release page | `v2.1.0`, not a draft, with the changelog entry as its text (`Added`: the workflow `code-metrics.yml`) |
+| Callable at the major tag | `.gitea/workflows/code-metrics.yml` and `tools/count_loc.py` are served at `v2` and `v2.1.0` |
+| Checks on `main` after the merge | validation, milestone publishing, wiki publishing and the metadata sync all green (runs 1458 to 1461) |
+
+Go/No-Go criteria of this milestone at its close: 1 to 8 as in the results
+above; 9 (a release makes it available, and the changelog, the README table and
+the wiki name it) is met by the release of 2.1.0. Success criterion 5 of the
+Business Case (a repository besides this one shows the badges) is met in a
+throwaway repository only; a project repository has not adopted it yet.
+
+---
+
+[BC-001]: ../business-case.md
+[US-001]: ../user-stories.md
+[MIL-003]: ./mil-003-quality-checks.md
+[MIL-004]: ./mil-004-versioned-release.md
+[ADR-0005]: ../adr/adr-0005-quality-check-contract.md
+[ADR-0006]: ../adr/adr-0006-release-process-and-version-pinning.md
+[5002450]: https://git.tirsystem.com/TirSystem/github-action/commit/50024505fe788b1c5e3021c0d1fc3d079590070e
+[5c5a1d1]: https://git.tirsystem.com/TirSystem/github-action/commit/5c5a1d19d96a6979b4f6141e736957174ba686a9
+[aa20e56]: https://git.tirsystem.com/TirSystem/github-action/commit/aa20e56110f4c2fab91a8432ba008ee8300926a2

docs/milestones/mil-011-code-metrics-default-tools-ref.md

@@ -0,0 +1,88 @@
+# MIL-011: Fix the defaults of the code metrics workflow
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-011 |
+| CrossReference | [BC-001], [US-001], [MIL-010], [ADR-0010], [ADR-0006] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version; reviewed (RC-076), accepted by the author in chat as stand-in for S01 | [02e3794] |
+
+---
+
+## Purpose
+
+Decide whether the released code metrics workflow can be called with its documented defaults, and correct it if it cannot.
+
+Release 2.1.0 ([MIL-010]) added `code-metrics.yml`. Its guide, its header comment and the default of its `tools-ref` input name `v1`, but the workflow and its scripts (`tools/code-metrics.sh`, `tools/count_loc.py`, `tools/badges.py`) exist only from `v2.1.0`. A caller who follows the guide (`@v1`) cannot resolve the workflow, and a caller at `@v2` that leaves `tools-ref` at its default fetches the scripts from `v1`, where they are absent, so the run fails. The offline tests of [MIL-010] did not see it, because they run the scripts from the checkout and never resolve a ref. The framework wiki page `Badges` works around it by telling callers to set `tools-ref: v2`.
+
+The other four reusable workflows also default `tools-ref` to `v1`; their scripts exist at `v1`, but a default that follows an old major is the same kind of error, so this milestone checks them too.
+
+## Deliverable
+
+A patch release (`2.1.1`, [ADR-0006]) in which: the default `tools-ref` of every reusable workflow names a tag that holds the scripts it runs; the guide, the header comment of `code-metrics.yml`, the upgrading guide, the README and the wiki pages in English, Danish and Bahasa Malaysia call the workflow at `@v2`; a test fails when a default `tools-ref` names a tag without the script; and the changelog has a `Fixed` entry. In `TirSystem/sqa-qc-framework`: the `Badges` wiki page without the `tools-ref` workaround.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | The defect is reproduced before the fix: a call at the major tag with the defaults fails, and the failure names the missing script, recorded in this milestone | Reproduced and recorded | Not reproduced, or not recorded |
+| 2 | Every reusable workflow's default `tools-ref` names a tag that contains the script file the workflow runs, listed per workflow in this milestone | All five checked and listed | A default names a tag without its script |
+| 3 | The default is derived, not copied: one place gives the current major, and a test fails when a workflow default differs from it or names a tag without the script | Test fails on a seeded wrong default and passes on the fix | No such test |
+| 4 | No guide, comment, README or wiki page tells a caller to use `@v1` for `code-metrics.yml`; a search of `guides/`, `README.md`, `docs/wiki/` and `.gitea/workflows/` finds none | Count is 0 | A page still says `@v1` for it |
+| 5 | A call with the documented defaults runs on the instance and commits the badges to a `badges` branch, verified on a throwaway branch and recorded | Run succeeds | Fails or is not run |
+| 6 | The release is a patch (`2.1.1`): the changelog has a `Fixed` entry, the major tag `v2` moves to it, and `v1` is not touched | Released | Released as another level, or `v1` moved |
+| 7 | The framework `Badges` page no longer tells a caller to set `tools-ref`, in all three languages, and still calls the workflow at `@v2` | Page merged | The workaround remains |
+| 8 | Reviewed | A review record (`RC-*`) for this milestone and the changed workflow, tests and guides, each with a verdict of Go | An instance without a record |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| [MIL-010] | The workflow and its guide are its deliverables; the defect is in release 2.1.0 |
+| [ADR-0006] | The release process: a fix is a patch release, and a moving major tag follows it |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| Business Case objective O5: a shared workflow that counts the code files and lines of code, reads the coverage report and publishes the three results as SVG badges; the workflow cannot be called as documented until this milestone is done | [BC-001] |
+| User stories | [US-001] (no new story: the tasks below are technical, and the story of [MIL-010] for the badges stays as written) |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S05 |
+| Approving reviewer | S01 |
+
+## Target Date
+
+2026-10-23 (Friday), one week of work: the fix is small and a caller cannot use the workflow until it is released. This precedes the planned decision date of [MIL-010] (2027-01-30) because that milestone was released on 2026-10-14, ahead of its date; the schedule row of [MIL-010] is not changed here. The Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Reproduce the defect and list the defaults | On a throwaway branch, call `code-metrics.yml` at `@v2` with the defaults and at `@v1`, and record both failures and the message. List, for each of the five reusable workflows, the default `tools-ref` and whether the script it runs exists at that tag. Record the result in this milestone. | No | [MIL-010] |
+| 2 | Fix the defaults | Give the repository one definition of the current major (a file the workflows' tests and the release workflow read), set the default `tools-ref` of every reusable workflow from it, and change the header comment of `code-metrics.yml` to `@v2`. A workflow whose script is at the previous major keeps that tag only with a comment that says why. | No | [ADR-0006] |
+| 3 | Add the test | An offline test that reads every workflow in `.gitea/workflows/`, takes the default `tools-ref` and the script it runs, and fails when the default differs from the current major or the script is not in that tag (checked with `git cat-file` against the tags of the checkout). Show it fails on a seeded wrong default and passes on the fix. | No | [MIL-010] |
+| 4 | Correct the guides, README and wiki | Change `@v1` to `@v2` for `code-metrics.yml` in `guides/code-metrics.md`, `guides/upgrading.md`, `README.md` and `docs/wiki/CodeMetrics.md`, `.da.md` and `.ms.md`; say in the guide that `tools-ref` defaults to the current major. Search the repository for the remaining `@v1`. | No | |
+| 5 | Verify on the instance | On a throwaway branch of a repository, call the fixed workflow at the branch with the defaults, and check that the `badges` branch gets the SVG files. Record the run. | No | [MIL-010] |
+| 6 | Release 2.1.1 | Add the `Fixed` entry to the changelog (ADR-0006: a patch), run the Release workflow, and check that `v2` points at `v2.1.1` and `v1` at `v1.2.2`. | No | [ADR-0006] |
+| 7 | Remove the workaround from the framework page | In `TirSystem/sqa-qc-framework`, remove the `tools-ref: v2` line and the two bullets about it from `docs/wiki/Badges.md`, `Badges-da.md` and `Badges-ms.md`, and add a changelog line. This is a change in another repository, made after release 2.1.1 and in its own pull request. | No | |
+| 8 | Add MIL-011 to the Project Plan | Add the schedule row, the Gantt bar, the scope entry and the dependency to [PP-001], and its review to the traceability matrix. | No | |
+| 9 | Review | Record `RC-*` for this milestone, the workflow and tests, and the guides, each with a verdict. | No | |
+
+---
+
+[BC-001]: ../business-case.md
+[US-001]: ../user-stories.md
+[MIL-010]: ./mil-010-code-metrics-badges.md
+[ADR-0010]: ../adr/adr-0010-code-metrics-badges-contract.md
+[ADR-0006]: ../adr/adr-0006-release-process-and-version-pinning.md
+[PP-001]: ../project-plan.md
+[02e3794]: https://git.tirsystem.com/TirSystem/github-action/commit/02e3794d7b05799af2544ca303c99271da788e82

docs/project-plan.md

@@ -4,25 +4,25 @@
 | Key | Value |
 | --- | --- |
 | ID | PP-001 |
-| CrossReference | [BC-001], [SA-001], [ADR-0002], [US-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007] |
+| CrossReference | [BC-001], [SA-001], [ADR-0002], [US-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009], [MIL-010], [MIL-011] |
 
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-10 | Deprecated | Jens Tirsvad Nielsen | S01 | Dates confirmed by S01 (stand-in for S05); the confirmation item is removed from Open Issues | [ea06eaa] |
-| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Added MIL-007 (quality checks for C++ and C#); reviewed (RC-053) | [e3ad1fa] |
+| 2026-10-14 | Deprecated | Jens Tirsvad Nielsen | AI as stand-in for S01 | Added MIL-010 (code metrics and coverage badges); reviewed (RC-068) | [5002450] |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | S01 | Added MIL-011 (fix the defaults of the code metrics workflow); reviewed (RC-076), accepted by the author in chat as stand-in for S01 | [02e3794] |
 
 ---
 
 ## Purpose
 
-This plan schedules seven milestones that move the repository from one
+This plan schedules eleven milestones that move the repository from one
 workflow with known defects to a documented, versioned collection of shared
 workflows. The Business Case sets no deadline, so the dates are the plan's own; they were confirmed on 2026-10-10 by S01, standing in for S05 (ADR-0002).
 
 ## Planning Assumptions
 
-- Week 1 starts 2026-10-05; phases are two weeks long; the last decision is 2026-12-26; MIL-007 follows in January 2027 (2027-01-04 to 2027-01-16, confirmed on 2026-10-11 by S01).
+- Week 1 starts 2026-10-05; phases are two weeks long; the last decision is 2026-12-26; MIL-007 follows in January 2027 (2027-01-04 to 2027-01-16, confirmed on 2026-10-11 by S01). MIL-008 amends the shared wiki publishing of MIL-006 and runs in parallel with the October and November windows: its work started on 2026-10-13 and its decision date is its own Target Date, 2026-11-15. MIL-009 follows MIL-008 and runs from 2026-11-16 to its proposed Target Date, 2026-11-30, confirmed by S01 in chat on 2026-10-14. MIL-010 (code metrics and coverage badges) follows MIL-007 in January 2027, from 2027-01-18 to its Target Date, 2027-01-30, accepted by the user in chat on 2026-10-14.
 - Work on a milestone starts only after its `MIL-*` document is `Accepted`.
 - Dates were confirmed on 2026-10-10 by S01, standing in for S05 (ADR-0002).
 
@@ -37,6 +37,10 @@ workflows. The Business Case sets no deadline, so the dates are the plan's own;
 | Wiki and translations | [MIL-005] | 2026-11-30 to 2026-12-12 | 2026-12-12 | S05 | None yet | Wiki pages in English, Danish and Bahasa Malaysia, kept current by every pull request | [Milestone MIL-005] |
 | Shared wiki publishing | [MIL-006] | 2026-12-14 to 2026-12-26 | 2026-12-26 | S05 | None yet | Scoped publish-wiki workflow with opt-in, piloted in one other repository | [Milestone MIL-006] |
 | Quality checks for C++ and C# | [MIL-007] | 2027-01-04 to 2027-01-16 | 2027-01-16 | S05 | US-001.09, US-001.10 (to extend) | Reusable quality-check workflows for C++ and C#, released | [Milestone MIL-007] |
+| Wiki publishing as a reusable workflow | [MIL-008] | 2026-10-13 to 2026-11-15 | 2026-11-15 | S05 | None yet | Reusable publish-wiki-pages workflow, wiki in docs/wiki, scoped workflow deprecated, released as 1.2.2 | [Milestone MIL-008] |
+| Migrate the wiki callers and remove the scoped workflow | [MIL-009] | 2026-11-16 to 2026-11-30 | 2026-11-30 | S05 | None yet | Seven repositories publish through a caller, scoped workflow removed, ADR-0004 superseded, released as 2.0.0 | Not created yet (the sync creates it when MIL-009 is Accepted) |
+| Code metrics and coverage badges | [MIL-010] | 2027-01-18 to 2027-01-30 | 2027-01-30 | S05 | None yet (task 1 writes them) | Reusable workflow that counts code files and lines of code, reads coverage and commits SVG badges, released | Not created yet (the sync creates it when MIL-010 is Accepted) |
+| Fix the defaults of the code metrics workflow | [MIL-011] | 2026-10-14 to 2026-10-23 | 2026-10-23 | S05 | None (technical tasks) | Patch release 2.1.1: the default `tools-ref` of every reusable workflow names a tag that holds its scripts, a test for it, guides and wiki at `@v2`, the framework Badges page without the workaround | Not created yet (the sync creates it when MIL-011 is Accepted) |
 
 ```plantuml
 @startgantt
@@ -55,6 +59,14 @@ Project starts 2026-10-05
 [MIL-006 Go/No-Go] happens 2026-12-26
 [MIL-007 C++ and C#] starts 2027-01-04 and ends 2027-01-16
 [MIL-007 Go/No-Go] happens 2027-01-16
+[MIL-008 Reusable wiki workflow] starts 2026-10-13 and ends 2026-11-15
+[MIL-008 Go/No-Go] happens 2026-11-15
+[MIL-009 Migrate and remove] starts 2026-11-16 and ends 2026-11-30
+[MIL-009 Go/No-Go] happens 2026-11-30
+[MIL-010 Badges] starts 2027-01-18 and ends 2027-01-30
+[MIL-010 Go/No-Go] happens 2027-01-30
+[MIL-011 Defaults fix] starts 2026-10-14 and ends 2026-10-23
+[MIL-011 Go/No-Go] happens 2026-10-23
 @endgantt
 ```
 
@@ -69,6 +81,9 @@ Project starts 2026-10-05
 | Wiki pages in English, Danish and Bahasa Malaysia | [MIL-005] |
 | The wiki publisher shared with other repositories through scoped delivery | [MIL-006] |
 | Gitea Actions workflows for software engineers (quality checks for C++ and C#) | [MIL-007] |
+| The wiki publisher as a workflow that repositories call, from docs/wiki | [MIL-008] |
+| Moving every publishing repository to the called workflow and removing the scoped one | [MIL-009] |
+| A shared workflow for code metrics and coverage badges | [MIL-010], [MIL-011] |
 
 ## Dependencies
 
@@ -76,6 +91,8 @@ Project starts 2026-10-05
 MIL-001 → MIL-002 → MIL-003 → MIL-004
             MIL-002 → MIL-005 → MIL-006
    MIL-003 + MIL-004 → MIL-007
+                      MIL-006 → MIL-008 → MIL-009
+   MIL-003 + MIL-004 → MIL-010 → MIL-011
 ```
 
 A No-Go moves every later window by the rework time of the failed milestone.
@@ -86,6 +103,9 @@ A No-Go moves every later window by the rework time of the failed milestone.
 | --- | --- | --- |
 | The runner cannot provide the C++ or C# tools (MIL-007) | The workflows need a custom runner image or a longer install | MIL-007 task 2 verifies it first; the ADR of task 3 says what a build-dependent check needs from the caller. |
 | Reusable workflow support is missing on the instance | MIL-003 and MIL-004 change shape | Verify first in each milestone (MIL-002 task 2, MIL-003 task 1); fall back to copied templates. |
+| Eight repositories still publish through the scoped workflow that MIL-008 deprecates (MIL-008 task 5) | Removing it would stop their wikis | It is deprecated and kept; a follow-up milestone migrates them and removes it in a major release (RC-061). |
+| An organisation has no `TOKEN_FOR_GITEA_WIKI` secret, or a repository fails its first run (MIL-009 tasks 3 and 4) | The wiki of that repository stops updating | MIL-009 task 5 reads each wiki back after the first run; the scoped workflow is removed only after every repository passes. |
+| The token of a run cannot push to a `badges` branch, or the SVG does not render on the mirror (MIL-010) | The delivery of the badges changes shape | MIL-010 task 3 verifies it first; fall back to a badge file in a path of the default branch or to a run artifact. |
 | Security review by S05 is a bottleneck | Milestone decisions slip | Keep milestones small and plan review time before each decision date. |
 
 ## Open Issues
@@ -258,6 +278,10 @@ no tests, no release process.
 [MIL-005]: ./milestones/mil-005-wiki-and-translations.md
 [MIL-006]: ./milestones/mil-006-shared-wiki-publishing.md
 [MIL-007]: ./milestones/mil-007-cpp-csharp-quality-checks.md
+[MIL-008]: ./milestones/mil-008-wiki-reusable-workflow.md
+[MIL-009]: ./milestones/mil-009-migrate-wiki-callers-and-remove-scoped-workflow.md
+[MIL-010]: ./milestones/mil-010-code-metrics-badges.md
+[MIL-011]: ./milestones/mil-011-code-metrics-default-tools-ref.md
 [Milestone MIL-001]: https://git.tirsystem.com/TirSystem/github-action/milestone/18
 [Milestone MIL-002]: https://git.tirsystem.com/TirSystem/github-action/milestone/19
 [Milestone MIL-003]: https://git.tirsystem.com/TirSystem/github-action/milestone/20
@@ -265,6 +289,8 @@ no tests, no release process.
 [Milestone MIL-005]: https://git.tirsystem.com/TirSystem/github-action/milestone/93
 [Milestone MIL-006]: https://git.tirsystem.com/TirSystem/github-action/milestone/94
 [Milestone MIL-007]: https://git.tirsystem.com/TirSystem/github-action/milestone/95
-[ea06eaa]: https://git.tirsystem.com/TirSystem/github-action/commit/ea06eaaa698247d20e4a8e2694d7acbb1de58b63
+[Milestone MIL-008]: https://git.tirsystem.com/TirSystem/github-action/milestone/152
 [b74ee0e]: https://git.tirsystem.com/TirSystem/github-action/commit/b74ee0e5cfd04f25ba5f2c1addc80699147c479a
-[e3ad1fa]: https://git.tirsystem.com/TirSystem/github-action/commit/e3ad1fa7e7eef57a6793a479edb41ac6fd2db688
+[2f267df]: https://git.tirsystem.com/TirSystem/github-action/commit/2f267df2a270087cb7dc482af4ce4f4341e97b03
+[5002450]: https://git.tirsystem.com/TirSystem/github-action/commit/50024505fe788b1c5e3021c0d1fc3d079590070e
+[02e3794]: https://git.tirsystem.com/TirSystem/github-action/commit/02e3794d7b05799af2544ca303c99271da788e82

docs/sqa/reviews/rc-054-adr-0008.md

@@ -0,0 +1,52 @@
+# Review Record: ADR-0008
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-054 |
+| CrossReference | [ADR-0008], [QC-ADR-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | [9e7aedd] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [ADR-0008]
+- Checklist used: [QC-ADR-001]
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | The ID (`ADR-NNNN`, 4-digit) matches the filename number and is unique and sequential | Pass | ADR-0008 in `adr-0008-cpp-csharp-quality-check-contract.md`, after ADR-0007. |
+| 2 | Context states the problem, the forces (cost, risk, constraints) and the options evaluated | Pass | States the two requirements from S01, the facts from runs 692 and 699, and the options. |
+| 3 | At least two options were considered, or the absence of alternatives is justified | Pass | Three options for the workflows, three for `cppcheck`, two for the SDK pin. |
+| 4 | Decision is stated in one or two unhedged sentences and matches one of the evaluated options | Pass | One sentence naming option 2, dropping `cppcheck` (c) and an exact SDK version (b). |
+| 5 | Consequences list both Positive and Negative outcomes | Pass | Three positive and six negative (after the fix of criterion 6). |
+| 6 | Quality-attribute impacts (performance, security, portability, etc.) are named where the decision affects them | Pass | Finding fixed during this review: the security impact of downloading and running tools and packages in every run was not named (ADR-0005 names it for PyPI); it is now a negative consequence, with the limit that the jobs have `contents: read` and no secret. |
+| 7 | Affected Artifacts are listed as links, and each is also in CrossReference | Pass | MIL-007, UC-005, US-001, ADR-0005 and ADR-0006 are linked and cited. |
+| 8 | Status changes are recorded as new Version History rows with a Change summary and Commit link; retained rows are never rewritten | Pass | The Proposed row keeps its status as Deprecated and the Accepted row is added. |
+| 9 | A superseded or deprecated ADR names its successor, and the successor links back | N-A | Nothing is superseded; ADR-0005 is extended and unchanged. |
+| 10 | Written in business or technical language of the domain, with no unexplained abbreviations | Pass | Finding fixed during this review: PyPI and SDK were used without being expanded; both are introduced at first use. |
+| 11 | Status is one of `Proposed`, `Accepted`, `Rejected`, `Deprecated` or `Superseded by ADR-NNNN`, and every Version History row uses only these | Pass | Deprecated and Accepted. |
+
+## Overall Verdict
+
+Go - all applicable criteria pass; the two findings (criteria 6 and 10) were fixed during the review. It unlocks tasks 4 and 5 of MIL-007 (#98 and #99) under the plan-first gate, once MIL-007 itself is Accepted again (its amendment after RC-052 is still Proposed). S01 gave the Go in chat on 2026-10-11, standing in for the other reviewers as ADR-0002 records; there is no independent reader.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Review and accept the amendment of MIL-007 (current tool versions, .NET SDK 10 or later, results of run 699) so that its latest row is Accepted | S01 | before #98 and #99 |
+| Choose the exact default of `dotnet-sdk-version` (an `10.0.x` band) when the C# workflow is built, and check it is still the current stable release | S05 | task 5 |
+
+---
+
+[ADR-0008]: ../../adr/adr-0008-cpp-csharp-quality-check-contract.md
+[QC-ADR-001]: ../../../framework/qc/qc-adr.md
+[9e7aedd]: https://git.tirsystem.com/TirSystem/github-action/commit/9e7aeddb11c2b41ac893d9f7893d663a53fbe470

docs/sqa/reviews/rc-055-mil-007-amendment.md

@@ -0,0 +1,46 @@
+# Review Record: MIL-007 (amendment)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-055 |
+| CrossReference | [MIL-007], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | [faf13b2] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-007] after the amendments since RC-052: current tool versions only (.NET SDK 10 or later), the results of runs 692 and 699, and the contract of ADR-0008
+- Checklist used: [QC-MIL-001]
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Unchanged, and the deliverable now states the version requirement: current tools only, .NET SDK 10 or later. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Finding fixed during this review: criterion 1 was amended but task 3 still carried the options of the draft (`cppcheck` conditional, one workflow or two). Task 3 now states the decided contract and points to ADR-0008, so criterion 2 is checkable as it stands: the ADR is accepted. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Unchanged: MIL-003 and MIL-004, both closed. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | O4, US-001.09 and .10, and now the stories US-001.16 and .17 of task 1; ADR-0008 is in CrossReference. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Owner S05, approving reviewer S01. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2027-01-16, unchanged and confirmed on 2026-10-11. |
+
+## Overall Verdict
+
+Go - all six criteria pass; the one finding (criterion 2) was fixed during the review, together with two stale phrases (the verification results still offered a build of `cppcheck`, and tasks 4 and 5 said "as the ADR decides"). It restores the status Accepted of MIL-007, which the publishing action and the plan-first gate require, and it does not accept UC-005 and US-001.16 and .17 (task 1, #95), which still need their own review. S01 gave the Go in chat on 2026-10-11, standing in for the other reviewers as ADR-0002 records; there is no independent reader.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Review and accept the extension of UC-005 and the stories US-001.16 and US-001.17 (#95) | S01 | before #98 and #99 |
+
+---
+
+[MIL-007]: ../../milestones/mil-007-cpp-csharp-quality-checks.md
+[QC-MIL-001]: ../../../framework/qc/qc-milestones-gateways.md
+[faf13b2]: https://git.tirsystem.com/TirSystem/github-action/commit/faf13b2c2a4901c0171977de1ffc2841023f537a

docs/sqa/reviews/rc-056-uc-005-cpp-csharp.md

@@ -0,0 +1,52 @@
+# Review Record: UC-005 (C++ and C#)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-056 |
+| CrossReference | [UC-005], [QC-UC-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | [1bc56f8] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [UC-005] after the extension of its Brief to C++ and C# (MIL-007 task 1)
+- Checklist used: [QC-UC-001] (Brief format)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Consists of a single, concise paragraph summarizing only the primary success scenario | Pass | Finding fixed during this review: the extension had added a sentence about a language that needs a build or a project file and says what is missing, which is a failure flow. It is removed from the Brief; the stories US-001.16 and .17 carry it as an acceptance criterion. |
+| 2 | Written as an informal multi-paragraph narrative; may mention some alternate flows without formal structure | N-A | Format is Brief. |
+| 3 | All standard sections are present: actors, preconditions, postconditions, main success scenario, alternative/exception flows | N-A | Format is Brief; actor, stakeholders, pre- and postconditions and the paragraph are present. |
+| 4 | Preconditions and postconditions are explicitly defined | Pass | The precondition now lists the four languages (Python, shell, C++, C#); the postcondition is unchanged. |
+| 5 | Primary actor is explicitly stated | Pass | Software Engineer. |
+| 6 | Stakeholders and their interests are stated | Pass | S02 and S05, unchanged. |
+| 7 | Main success scenario is written as clear, numbered steps | N-A | Format is Brief. |
+| 8 | Alternative/exception flows correctly reference `<<include>>`/`<<extend>>` use cases where relevant, per UML 2.5.1 | N-A | None in a Brief. |
+| 9 | Explicit business rules are captured per step where applicable, rather than embedded loosely in narrative text | N-A | No steps in a Brief. |
+| 10 | Naming of actors and use case title is consistent with the corresponding Use Case Diagram and User Stories | Pass | Title and actor equal UCD-001; the Stories line lists US-001.09, .10, .16 and .17, which exist. |
+| 11 | Scope/level (e.g. summary, user-goal, subfunction) is explicitly stated | Pass | Scope and user-goal level, unchanged. |
+| 12 | Use case is written from the actor's goal perspective, free of UI or implementation detail | Pass | Goal wording; the tool names are not in the Brief for C++ and C#. |
+
+## Overall Verdict
+
+Go - all applicable criteria pass; the one finding (criterion 1) was fixed during the review. S01 gave the Go in chat on 2026-10-11, standing in for the other reviewers as ADR-0002 records; there is no independent reader.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Update the description of this use case in the Use Case Diagram table of UCD-001 ("Lint, format and type checks run on every change ...") to cover C++ and C# at its next review | S01 | next review of UCD-001 |
+
+---
+
+[UC-005]: ../../uc-005/uc.md
+[QC-UC-001]: ../../../framework/qc/qc-use-case.md
+[1bc56f8]: https://git.tirsystem.com/TirSystem/github-action/commit/1bc56f8b771531f221f218fc00b147ecc73c051e

docs/sqa/reviews/rc-057-us-001-cpp-csharp.md

@@ -0,0 +1,47 @@
+# Review Record: US-001 (US-001.16 and US-001.17)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-057 |
+| CrossReference | [US-001], [QC-US-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | [1bc56f8] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [US-001], the new stories US-001.16 (a C++ project gets the same checks) and US-001.17 (a C# project gets the same checks) and the document's Purpose and Scope
+- Checklist used: [QC-US-001]
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Follows INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) | Pass | The two stories are independent of each other and of US-001.09 and .10, each states one goal, and the INVEST check names all seventeen stories. |
+| 2 | Written in "As a / I want / So that" form | Pass | Both. |
+| 3 | Clear, testable acceptance criteria are included | Pass | Three Given/When/Then criteria each: a pass or fail status, a finding with tool and `path:line`, and a `[configuration]` failure that names what is missing instead of passing; each is checked with a run. |
+| 4 | Traceable to a use case or epic | Pass | [UC-005] and [MIL-007], and the Stories line of UC-005 lists both. |
+| 5 | Story is sized to fit within a single iteration | Pass | One language each. |
+| 6 | Story statement avoids technical implementation detail | Pass | No tool is named in the statements. The acceptance criteria name the category `[configuration]`, as US-001.07 does. |
+| 7 | Role named in the story matches an actor defined in the Use Case Diagram | Pass | Software Engineer. |
+
+## Overall Verdict
+
+Go - all seven criteria pass. One stale sentence in the Purpose and Scope (it said that stories for quality checks and releases were not written yet) was corrected during the review, as it is false since US-001.09. With RC-056 this completes task 1 of MIL-007 (#95) and, with ADR-0008 and the accepted amendment of MIL-007, meets the plan-first gate for tasks 4 and 5 (#98 and #99). S01 gave the Go in chat on 2026-10-11, standing in for the other reviewers as ADR-0002 records; there is no independent reader.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | - | - |
+
+---
+
+[US-001]: ../../user-stories.md
+[QC-US-001]: ../../../framework/qc/qc-user-story.md
+[1bc56f8]: https://git.tirsystem.com/TirSystem/github-action/commit/1bc56f8b771531f221f218fc00b147ecc73c051e

docs/sqa/reviews/rc-058-mil-006-task-6.md

@@ -0,0 +1,51 @@
+# Review Record: MIL-006 (task 6 amendment)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-058 |
+| CrossReference | [MIL-006], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [8051cc4] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-006] after the amendment of 2026-10-13: task 6 (fix the page title of hyphenated pages) added
+- Checklist used: [QC-MIL-001]
+- Scope: delta re-review of the added task 6 and of the unchanged criteria it touches; the earlier record is [RC-049]
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-13)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Task 6 states the change (title sent with spaces), a test and a changelog entry. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Unchanged: the six criteria. The fix serves criterion 3 (pages equal `wiki/`), which the hyphen defect made unreachable for links. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Unchanged: MIL-005 and MIL-002. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Unchanged: O2, O3. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Owner S05, approving reviewer S01. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-12-26, unchanged. |
+
+## Overall Verdict
+
+Go - all six criteria pass. It restores the status Accepted of MIL-006, which the publishing action and the plan-first gate require before the fix is committed. S01 is stood in for by the AI as the user chose autonomous mode in chat on 2026-10-13; there is no independent reader, and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Release the fix, re-run publish-wiki in `sqa-and-qc`, `sqa-qc-framework` and `sqa-qc-checklists`, delete the stale `*.-.md` pages | S05 | after the fix is merged |
+
+---
+
+[MIL-006]: ../../milestones/mil-006-shared-wiki-publishing.md
+[RC-049]: ./rc-049-mil-006-outcome.md
+[QC-MIL-001]: ../../../framework/qc/qc-milestones-gateways.md
+[8051cc4]: https://git.tirsystem.com/TirSystem/github-action/commit/8051cc4489ee9bcf3b6c62f2eafcb2013b7d2f90

docs/sqa/reviews/rc-059-mil-007-adoption.md

@@ -0,0 +1,54 @@
+# Review Record: MIL-007 (task 7 results)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-059 |
+| CrossReference | [MIL-007], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Deprecated | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [2481c26] |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Action item closed: the two throwaway repositories were deleted at the user's request | [daecb7b] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-007] with the verification results of task 7 (adoption in two throwaway repositories, seeded failures)
+- Checklist used: [QC-MIL-001]
+- Scope: delta re-review of the added results and of Go/No-Go criteria 3 and 4; the earlier record is [RC-055]
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user chose the throwaway repositories in chat on 2026-10-13)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Unchanged. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Criterion 3 (tool, file and line in the log) and 4 (status on pull requests) are met for both workflows by runs 906 and the C# run of the same pull request, as the verification results table lists. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Unchanged: MIL-003 and MIL-004. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Unchanged: O4, US-001.09, .10, .16, .17. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Owner S05, approving reviewer S01. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2027-01-16, unchanged. |
+
+## Overall Verdict
+
+Go - all six criteria pass. Criteria 3 and 4 of the milestone are verified on throwaway repositories only; a real project with a compile database or many packages is still open and is said so in the results. S01 is stood in for by the AI as the user chose autonomous mode; there is no independent reader, and the decision stays open to challenge.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| ~~Decide whether to delete `TirSystem/qc-adoption-cpp` and `TirSystem/qc-adoption-csharp`~~ Closed 2026-10-13: both were deleted at the user's request | S05 | done |
+| Adopt the workflows in a real C++ and a real C# project | S05 | before the milestone closes |
+
+---
+
+[MIL-007]: ../../milestones/mil-007-cpp-csharp-quality-checks.md
+[RC-055]: ./rc-055-mil-007-amendment.md
+[QC-MIL-001]: ../../../framework/qc/qc-milestones-gateways.md
+[2481c26]: https://git.tirsystem.com/TirSystem/github-action/commit/2481c26d802464decd51d75539157093b60e08e8
+[daecb7b]: https://git.tirsystem.com/TirSystem/github-action/commit/daecb7b452197643b39752b9b453a8c376562354

docs/sqa/reviews/rc-060-mil-008-plan.md

@@ -0,0 +1,54 @@
+# Review Record: MIL-008
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-060 |
+| CrossReference | [MIL-008], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | [01b9c29] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-008]
+- Checklist used: [QC-MIL-001]
+- Scope: full review
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: supervised (S01, the user, accepted the plan in chat on 2026-10-13; the AI prepared the record)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | The Deliverable section names the reusable workflow, the caller template, tests, the superseding ADR, the moved wiki and the release. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Six criteria, each with a checkable Go and No-Go (tests, a read-back with 0 differences, the `v1` tag). |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | MIL-006, and the framework's `process/wiki.md`, which is still unmerged and is named as such. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | O2 and O3 of [BC-001], as for MIL-006. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Owner S05, approving reviewer S01. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-11-15; the Business Case sets no deadline and the plan's last decision is 2026-12-26. |
+
+## Overall Verdict
+
+Go - all six criteria pass. The release is a patch (1.2.1 to 1.2.2) by the owner's decision, although ADR-0006 classes a new workflow as minor and a removed one as breaking; task 7 records the deviation in the changelog, and S01 chose it over a minor release and over keeping the scoped workflow.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Add MIL-008 to the Project Plan (milestone table, CrossReference, dependency graph) and review it | S05 | before the pull request |
+| Merge `process/wiki.md` in `sqa-qc-framework` before this repository pins it | S05 | before task 3 ships |
+| List the repositories that publish through the scoped workflow before task 5 removes it | S05 | before task 5 |
+
+---
+
+---
+
+[MIL-008]: ../../milestones/mil-008-wiki-reusable-workflow.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
+[01b9c29]: https://git.tirsystem.com/TirSystem/github-action/commit/01b9c2972b4317bcc590540010aea0eaf7f30014

docs/sqa/reviews/rc-061-mil-008-task-5-deferred.md

@@ -0,0 +1,54 @@
+# Review Record: MIL-008 (task 5 deferred)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-061 |
+| CrossReference | [MIL-008], [QC-MIL-001], [RC-060] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | [01b9c29] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-008] after the amendment of 2026-10-13: task 5 changed from removing the scoped workflow to deprecating it, with the criterion that follows from it
+- Checklist used: [QC-MIL-001]
+- Scope: delta re-review of the amended task 5, criterion 5 and the Deliverable; the earlier record is [RC-060]
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: supervised (S01, the user, chose option 1, defer the removal, in chat on 2026-10-13; the AI prepared the record)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | The Deliverable now says the scoped workflow is marked deprecated, not removed. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Criterion 5 is checkable: a notice in the header, the README and ADR-0009, and the list of repositories recorded; No-Go if it was removed while a repository depends on it. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Unchanged: MIL-006 and the framework's `process/wiki.md`. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Unchanged: O2, O3. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Owner S05, approving reviewer S01. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-11-15, unchanged. |
+
+## Overall Verdict
+
+Go - all six criteria pass. The amendment follows from a scan on 2026-10-13: 8 repositories still publish through the scoped workflow and none calls the reusable one, so removal would have broken them. Removal and the migrations move to a follow-up milestone that needs its own plan.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Plan the follow-up milestone: migrate the 8 repositories (move `wiki/` to `docs/wiki/`, add the caller from `templates/ci/publish-wiki.yml`), then remove the scoped workflow in a major release | S05 | after the 1.2.2 release |
+| Add MIL-008 to the Project Plan and review it (open since RC-060) | S05 | before the pull request |
+
+---
+
+---
+
+[MIL-008]: ../../milestones/mil-008-wiki-reusable-workflow.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
+[RC-060]: ./rc-060-mil-008-plan.md
+[01b9c29]: https://git.tirsystem.com/TirSystem/github-action/commit/01b9c2972b4317bcc590540010aea0eaf7f30014

docs/sqa/reviews/rc-062-pp-001-mil-008.md

@@ -0,0 +1,54 @@
+# Review Record: PP-001 Project Plan (MIL-008)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-062 |
+| CrossReference | [PP-001], [BC-001], [MIL-008] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | [9aeb74e] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [PP-001]
+- Checklist used: none: the Project Plan has no QC checklist. Validated against the Business Case [BC-001] and the Go / No-Go criteria of each listed milestone, as `PP.md` prescribes.
+- Scope: delta re-review for the added MIL-008 row, Gantt entries, Scope Coverage, Dependencies, one Plan Risk and the counts; the earlier record is RC-053
+- Language and domain: n/a (technical type)
+- Mode: supervised (the AI prepared the record; S01, the user, gave the Go in chat on 2026-10-13)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Every milestone in the plan has a `MIL-*` document and the plan's dates equal that document's target date | Pass | MIL-001 to MIL-008 exist; the MIL-008 decision date 2026-11-15 equals its Target Date. |
+| 2 | Every Business Case scope item is covered by a gateway | Pass | The wiki publisher shared with other repositories is covered by MIL-006 and MIL-008 (O2, O3). |
+| 3 | The schedule respects the Business Case constraints | Pass | The Business Case sets no deadline; the MIL-008 window overlaps the October and November windows and says so under Planning Assumptions. |
+| 4 | Dependencies between milestones are stated | Pass | MIL-006 to MIL-008 is in the Dependencies diagram and in MIL-008's own document. |
+| 5 | Every gateway has an owner who is a stakeholder ID | Pass | MIL-008 is owned by S05. |
+| 6 | Plan content is internally consistent | Pass | "Eight milestones", the Planning Assumptions, the Gantt entries, the Gateway Schedule and the Scope Coverage agree. |
+| 7 | Open Issues are current | Pass | Unchanged items remain open; a plan risk was added for the repositories that still use the scoped workflow. |
+
+## Overall Verdict
+
+Go - all seven criteria pass; no findings. S01 gave the Go in chat on 2026-10-13, after the change was merged as pull request 137 with the plan row `Proposed`; this record and the plan row are set to `Accepted` in the follow-up.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Set PP-001 and this record to `Accepted` (done in the follow-up that follows pull request 137) | S05 | 2026-10-13 |
+| Review ADR-0009 (still without a review record) | S01 | after the plan |
+
+---
+
+---
+
+[PP-001]: ../../project-plan.md
+[BC-001]: ../../business-case.md
+[MIL-008]: ../../milestones/mil-008-wiki-reusable-workflow.md
+[9aeb74e]: https://git.tirsystem.com/TirSystem/github-action/commit/9aeb74e8b09bb7882847e9bd5d569dbc9856fc03

docs/sqa/reviews/rc-063-adr-0009.md

@@ -0,0 +1,56 @@
+# Review Record: ADR-0009 Wiki publishing as a reusable workflow
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-063 |
+| CrossReference | [ADR-0009], [QC-ADR-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | [8c2c52e] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [ADR-0009]
+- Checklist used: [QC-ADR-001]
+- Scope: full review
+- Language and domain: n/a (technical type)
+- Mode: supervised (the AI prepared the record; S01, the user, gave the Go in chat on 2026-10-13)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | The ID (`ADR-NNNN`, 4-digit) matches the filename number and is unique and sequential | Pass | ADR-0009 in `adr-0009-wiki-publishing-reusable-workflow.md`; follows ADR-0008. |
+| 2 | Context states the problem, the forces (cost, risk, constraints) and the options evaluated | Pass | Names the scoped delivery, its gate, the fixed trigger path and version, and the new folder rule. |
+| 3 | At least two options were considered, or the absence of alternatives is justified | Pass | Two options: keep the scoped workflow and read both folders, or a reusable workflow. |
+| 4 | Decision is stated in one or two unhedged sentences and matches one of the evaluated options | Pass | Two sentences; matches option 2. The rules below it add detail only. |
+| 5 | Consequences list both Positive and Negative outcomes | Pass | Finding fixed during this review: the consequence "passing a declared secret is not yet verified" was out of date, because run 316 verified it on 2026-10-13. It now says so. Four positive and four negative outcomes. |
+| 6 | Quality-attribute impacts (performance, security, portability, etc.) are named where the decision affects them | Pass | Finding fixed during this review: the security impact was implicit. A positive bullet (explicit secret, no fallback) and a negative bullet (whoever changes the caller changes the folder and `prune`) were added. |
+| 7 | Affected Artifacts are listed as links, and each is also in CrossReference | Pass | MIL-008 and ADR-0004 are linked and cited. |
+| 8 | Status changes are recorded as new Version History rows with a Change summary and Commit link; retained rows are never rewritten | Pass | The findings fix is a new row; the first row is kept unchanged. |
+| 9 | A superseded or deprecated ADR names its successor, and the successor links back | N-A | ADR-0004 is superseded only in part and stays in force until the scoped workflow is removed; see the action item. |
+| 10 | Written in business or technical language of the domain, with no unexplained abbreviations | Pass | Finding fixed during this review: "PO language" is now "the product owner's language". |
+| 11 | Status is one of `Proposed`, `Accepted`, `Rejected`, `Deprecated` or `Superseded by ADR-NNNN`, and every Version History row uses only these | Pass | `Proposed` only. |
+
+## Overall Verdict
+
+Go - all applicable criteria pass; the three findings (criteria 5, 6 and 10) were fixed during the review. S01 gave the Go in chat on 2026-10-13; there is no independent reader.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| When the scoped workflow is removed, mark ADR-0004 superseded by ADR-0009 for the delivery and marker parts (new version row and review record) | S01 | the follow-up milestone |
+
+---
+
+---
+
+[ADR-0009]: ../../adr/adr-0009-wiki-publishing-reusable-workflow.md
+[QC-ADR-001]: ../../../framework/qc/artifacts/qc-adr.md
+[8c2c52e]: https://git.tirsystem.com/TirSystem/github-action/commit/8c2c52ebd2a27e4d0edb4008c31c002718d280fb

docs/sqa/reviews/rc-064-mil-009-plan.md

@@ -0,0 +1,63 @@
+# Review Record: MIL-009 and PP-001 (MIL-009)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-064 |
+| CrossReference | [MIL-009], [PP-001], [BC-001], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; accepted | [86e69ce] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-009]; delta of [PP-001] for the added milestone
+- Checklist used: [QC-MIL-001] for the milestone; for the plan, the criteria of `PP.md` (no QC checklist exists for PP-001)
+- Scope: full review of MIL-009; delta re-review of PP-001, earlier record RC-062
+- Language and domain: n/a (technical type)
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14 with the defaults)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | MIL-009 lists the released framework, seven callers, the removals, the superseded ADR and 2.0.0. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Seven criteria with checkable Go and No-Go (tag, callers, read-backs, scan, removal, ADR rows, tags). |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | MIL-008 and the framework release; in the plan's Dependencies diagram (`MIL-008 -> MIL-009`). |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | O2, O3 of [BC-001]. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Owner S05, approving reviewer S01. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-11-30 is proposed and equals the plan's decision date; the Business Case sets no deadline. S01 has not confirmed it, as MIL-009 and the plan say; this is an action item. |
+
+## Plan delta (PP-001)
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Every milestone has a `MIL-*` document and the plan's dates equal that document's target date | Pass | MIL-001 to MIL-009 exist; the MIL-009 decision date equals its Target Date. |
+| 2 | Every Business Case scope item is covered by a gateway | Pass | Scope Coverage names MIL-009 for the removal of the scoped publisher. |
+| 3 | The schedule respects the Business Case constraints | Pass | No deadline in the Business Case; the window follows MIL-008. |
+| 4 | Dependencies between milestones are stated | Pass | `MIL-006 -> MIL-008 -> MIL-009`. |
+| 5 | Every gateway has an owner who is a stakeholder ID | Pass | S05. |
+| 6 | Plan content is internally consistent | Pass | "Nine milestones", the assumptions, the Gantt, the schedule and the coverage agree. |
+| 7 | Open Issues are current | Pass | A plan risk was added for missing organisation secrets and failed first runs. |
+
+## Overall Verdict
+
+Go - all criteria pass. The user switched to autonomous mode and accepted the plan in chat on 2026-10-14 with the defaults (target date 2026-11-30, no publishing for `027-sandbox` and `028-pomodoro`, framework release 0.7.0); the AI records the acceptance as stand-in for S01. There is no independent reader and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Check that `TirSystem-BashScript` has its own `TOKEN_FOR_GITEA_WIKI` (S03); stop and report if it does not | S03 | MIL-009 task 3 |
+
+---
+
+[MIL-009]: ../../milestones/mil-009-migrate-wiki-callers-and-remove-scoped-workflow.md
+[PP-001]: ../../project-plan.md
+[BC-001]: ../../business-case.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
+[86e69ce]: https://git.tirsystem.com/TirSystem/github-action/commit/86e69ce85df72ea3caed40253e08231c73187fde

docs/sqa/reviews/rc-065-adr-0004-superseded.md

@@ -0,0 +1,56 @@
+# Review Record: ADR-0004 superseded by ADR-0009
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-065 |
+| CrossReference | [ADR-0004], [ADR-0009], [QC-ADR-001], [MIL-009] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [22fc323] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [ADR-0004] after the status change to `Superseded by ADR-0009` on 2026-10-14
+- Checklist used: [QC-ADR-001]
+- Scope: delta re-review of the criteria the status change touches (7, 8, 9, 11); the earlier record is RC-018
+- Language and domain: n/a (technical type)
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan [MIL-009] in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | The ID matches the filename number and is unique and sequential | Pass | Unchanged. |
+| 2 | Context states the problem, the forces and the options evaluated | Pass | Unchanged. |
+| 3 | At least two options were considered | Pass | Unchanged. |
+| 4 | Decision is stated in one or two unhedged sentences and matches an evaluated option | Pass | Unchanged. |
+| 5 | Consequences list both Positive and Negative outcomes | Pass | Unchanged. |
+| 6 | Quality-attribute impacts are named where the decision affects them | Pass | Unchanged. |
+| 7 | Affected Artifacts are listed as links, and each is also in CrossReference | Pass | ADR-0009 is added to both. |
+| 8 | Status changes are recorded as new Version History rows with a Change summary and Commit link; retained rows are never rewritten | Pass | The change is a new row; the earlier `Accepted` row became `Deprecated` and its content is unchanged. |
+| 9 | A superseded or deprecated ADR names its successor, and the successor links back | Pass | The status names ADR-0009; ADR-0009 lists ADR-0004 under Affected Artifacts and in CrossReference. This closes the N-A of RC-018. |
+| 10 | Written in the language of the domain, with no unexplained abbreviations | Pass | Unchanged. |
+| 11 | Status is one of the allowed values and every row uses only these | Pass | `Deprecated` and `Superseded by ADR-0009`. |
+
+## Overall Verdict
+
+Go - all criteria pass. The scoped delivery and the marker are replaced and removed (MIL-009 tasks 2 to 6); the token and empty-folder rules of this ADR stand and are carried by ADR-0009. The AI records the acceptance as stand-in for S01; there is no independent reader, and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None open | - | - |
+
+---
+
+[ADR-0004]: ../../adr/adr-0004-shared-wiki-publishing-opt-in.md
+[ADR-0009]: ../../adr/adr-0009-wiki-publishing-reusable-workflow.md
+[QC-ADR-001]: ../../../framework/qc/artifacts/qc-adr.md
+[MIL-009]: ../../milestones/mil-009-migrate-wiki-callers-and-remove-scoped-workflow.md
+[22fc323]: https://git.tirsystem.com/TirSystem/github-action/commit/22fc323b41074ee0029ea2f07445a8e329e15d15

docs/sqa/reviews/rc-066-mil-009-outcome.md

@@ -0,0 +1,52 @@
+# Review Record: MIL-009 outcome
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-066 |
+| CrossReference | [MIL-009], [QC-MIL-001], [RC-064], [ADR-0004] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [95abc18] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-009] after the verification results were recorded on 2026-10-14
+- Checklist used: [QC-MIL-001]
+- Scope: delta re-review of the Go / No-Go outcome; the earlier record is [RC-064]
+- Language and domain: n/a (technical type)
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Delivered: framework 0.7.0, seven callers, removals, ADR-0004 superseded, 2.0.0. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | All seven criteria have a recorded result, each with evidence. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | MIL-008 and the framework release were met first. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | O2, O3, unchanged. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | S05 and S01. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target 2026-11-30; the gate was met on 2026-10-14. |
+
+## Overall Verdict
+
+Go - the gate is met: all seven criteria are Go (criterion 5 with a recorded note that the marker text remains in history records and the upgrade note). The AI records the outcome as stand-in for S01; there is no independent reader, and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Fix the two failing tests of `repo-foundry` on `main` (the checklist layout of its test fixture); not part of this milestone | S05 | not planned |
+| Move the `framework` pin of `github-action` itself from `v0.6.2` to `v0.7.0` | S05 | not planned |
+
+---
+
+[MIL-009]: ../../milestones/mil-009-migrate-wiki-callers-and-remove-scoped-workflow.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
+[RC-064]: ./rc-064-mil-009-plan.md
+[ADR-0004]: ../../adr/adr-0004-shared-wiki-publishing-opt-in.md
+[95abc18]: https://git.tirsystem.com/TirSystem/github-action/commit/95abc18a95d70c065b979123b8f8de22173af90c

docs/sqa/reviews/rc-067-bc-001-o5.md

@@ -0,0 +1,52 @@
+# Review Record: BC-001 (objective O5, code metrics and coverage badges)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-067 |
+| CrossReference | [BC-001], [QC-BC-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; accepted | [5002450] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [BC-001]
+- Checklist used: [QC-BC-001]
+- Scope: delta re-review of criteria 3, 4 and 7 (the change adds objective O5, an In Scope bullet and success criterion 5); criteria 1, 2, 5, 6 and 8 are re-read and unchanged. Earlier record: RC-008
+- Language and domain: n/a for this delta (see the action item about the Language and Domain rows)
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | ROI/Cost-Benefit analysis is quantitative, or where qualitative, is explicitly justified | Pass | Unchanged; the Cost-Benefit Assessment labels its qualitative form. |
+| 2 | Risks are identified with documented impact and mitigation | Pass | Unchanged. The delivery risk of the badges is a plan risk in PP-001, with a mitigation. |
+| 3 | Success criteria are measurable, stating explicit targets rather than vague aspirations | Pass | Criterion 5: "At least 1 besides this one by MIL-010", measured in the README of the consuming repository. |
+| 4 | Scope explicitly separates In Scope vs Out of Scope | Pass | "A shared workflow for code metrics and coverage badges (MIL-010)" is a new In Scope bullet; Out of Scope is unchanged and does not contradict it ("application code of consuming repositories" is not read or changed by the counter). |
+| 5 | Stakeholders are cross-referenced to Stakeholder Analysis IDs rather than re-described inline | Pass | Unchanged; the stakeholders table uses S-IDs. |
+| 6 | Methodology and quality-standard foundation are stated explicitly (e.g. ISO/IEC 25010, Larman) | Pass | Unchanged. |
+| 7 | Assumptions and constraints are explicit and clearly distinguished from one another | Pass | Unchanged. The constraint "tools available on the runner" still holds: the counter uses the Python standard library. |
+| 8 | Document supports executive decision-making with a clear, unambiguous recommendation | Pass | Unchanged: Proceed. |
+
+## Overall Verdict
+
+Go - all eight criteria pass for the revision that adds objective O5, its scope item and success criterion 5. The user accepted the plan in chat on 2026-10-14; the AI records the acceptance as stand-in for S01. There is no independent reader and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| The Metadata table of BC-001 has no `Language` and `Domain` rows (QC-LANG-001 criterion 1); this predates this change, and no earlier record applies QC-LANG-001 to it. Add the rows or record in an ADR why they are not needed | S01 | Before the next material change to BC-001 |
+
+---
+
+[BC-001]: ../../business-case.md
+[QC-BC-001]: ../../../framework/qc/artifacts/qc-business-case.md
+[5002450]: https://git.tirsystem.com/TirSystem/github-action/commit/50024505fe788b1c5e3021c0d1fc3d079590070e

docs/sqa/reviews/rc-068-mil-010-plan.md

@@ -0,0 +1,63 @@
+# Review Record: MIL-010 and PP-001 (MIL-010)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-068 |
+| CrossReference | [MIL-010], [PP-001], [BC-001], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; accepted | [5002450] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-010]; delta of [PP-001] for the added milestone
+- Checklist used: [QC-MIL-001] for the milestone; for the plan, the criteria of `PP.md` (no QC checklist exists for PP-001)
+- Scope: full review of MIL-010; delta re-review of PP-001, earlier record RC-064
+- Language and domain: n/a (technical type)
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | MIL-010 names the reusable workflow `code-metrics.yml`, the three SVG badges on a `badges` branch, the guide, three wiki languages, one adopter and a release. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Nine criteria, each with a checkable Go and No-Go (push and render, ADR, fixture counts, bad report, valid stable SVG, no loop, adopter, no embedded script, release). |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | MIL-003 and MIL-004; in the plan's Dependencies diagram (`MIL-003 + MIL-004 -> MIL-010`). |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | O5 of [BC-001], reviewed in RC-067. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Owner S05, approving reviewer S01. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2027-01-30 follows MIL-007 (2027-01-16); the Business Case sets no deadline; the user accepted it in chat. |
+
+## Plan delta (PP-001)
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Every milestone has a `MIL-*` document and the plan's dates equal that document's target date | Pass | MIL-001 to MIL-010 exist; the MIL-010 decision date equals its Target Date. |
+| 2 | Every Business Case scope item is covered by a gateway | Pass | Scope Coverage names MIL-010 for the new In Scope bullet. |
+| 3 | The schedule respects the Business Case constraints | Pass | No deadline in the Business Case; the window follows MIL-007. |
+| 4 | Dependencies between milestones are stated | Pass | `MIL-003 + MIL-004 -> MIL-010`. |
+| 5 | Every gateway has an owner who is a stakeholder ID | Pass | S05. |
+| 6 | Plan content is internally consistent | Pass | "Ten milestones", the assumptions, the Gantt, the schedule and the coverage agree. |
+| 7 | Open Issues are current | Pass | A plan risk was added for the push to the `badges` branch and the rendering on the mirror, with the fallback. |
+
+## Overall Verdict
+
+Go - all criteria pass. The user switched to autonomous mode and accepted the plan in chat on 2026-10-14 (Cobertura XML coverage input, target date 2027-01-30, three badges); the AI records the acceptance as stand-in for S01. There is no independent reader and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | - | - |
+
+---
+
+[MIL-010]: ../../milestones/mil-010-code-metrics-badges.md
+[PP-001]: ../../project-plan.md
+[BC-001]: ../../business-case.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
+[5002450]: https://git.tirsystem.com/TirSystem/github-action/commit/50024505fe788b1c5e3021c0d1fc3d079590070e

docs/sqa/reviews/rc-069-uc-008.md

@@ -0,0 +1,56 @@
+# Review Record: UC-008 (Show Code Metrics and Coverage Badges)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-069 |
+| CrossReference | [UC-008], [QC-UC-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; accepted | [9ca9673] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [UC-008]
+- Checklist used: [QC-UC-001]
+- Scope: full review (Brief format; MIL-010 task 1)
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Consists of a single, concise paragraph summarizing only the primary success scenario | Pass | One paragraph: push, count, read the report, publish three badges, README shows them. |
+| 2 | Written as an informal multi-paragraph narrative; may mention some alternate flows without formal structure | N-A | Format is Brief. |
+| 3 | All standard sections are present: actors, preconditions, postconditions, main success scenario, alternative/exception flows | N-A | Format is Brief; actor, stakeholders, pre- and postconditions and the paragraph are present. |
+| 4 | Preconditions and postconditions are explicitly defined | Pass | Both are stated; the postcondition says that only the badges change. |
+| 5 | Primary actor is explicitly stated | Pass | Software Engineer. |
+| 6 | Stakeholders and their interests are stated | Pass | S02 and S05 with an interest each. |
+| 7 | Main success scenario is written as clear, numbered steps | N-A | Format is Brief. |
+| 8 | Alternative/exception flows correctly reference `<<include>>`/`<<extend>>` use cases where relevant, per UML 2.5.1 | N-A | None in a Brief. |
+| 9 | Explicit business rules are captured per step where applicable, rather than embedded loosely in narrative text | N-A | No steps in a Brief. |
+| 10 | Naming of actors and use case title is consistent with the corresponding Use Case Diagram and User Stories | Pass | Title and actor equal UCD-001 (RC-071); the Stories line lists US-001.18 to US-001.20, which exist (RC-070). |
+| 11 | Scope/level (e.g. summary, user-goal, subfunction) is explicitly stated | Pass | Scope Reusable Workflow Collection, user-goal level. |
+| 12 | Use case is written from the actor's goal perspective, free of UI or implementation detail | Pass | Goal wording; no tool, file name or format of a report is named. |
+
+## Overall Verdict
+
+Go - all applicable criteria pass. The AI records the decision as stand-in for S01; there is no independent reader and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | - | - |
+
+---
+
+[UC-008]: ../../uc-008/uc.md
+[QC-UC-001]: ../../../framework/qc/artifacts/qc-use-case.md
+[9ca9673]: https://git.tirsystem.com/TirSystem/github-action/commit/9ca9673b00351cf913966f347c4da09890ed3f1f

docs/sqa/reviews/rc-070-us-001-metrics.md

@@ -0,0 +1,51 @@
+# Review Record: US-001 (stories US-001.18 to US-001.20)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-070 |
+| CrossReference | [US-001], [QC-US-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; accepted | [9ca9673] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [US-001]
+- Checklist used: [QC-US-001]
+- Scope: delta re-review of the added stories US-001.18 to US-001.20 and the Purpose and Scope and INVEST sections; earlier record RC-057 (US-001.01 to US-001.17 unchanged)
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Follows INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) | Pass | US-001.18 to US-001.20 are independent of each other, each states one value and has checkable criteria; the INVEST section of US-001 now counts twenty stories. |
+| 2 | Written in "As a / I want / So that" form | Pass | All three stories. |
+| 3 | Clear, testable acceptance criteria are included | Pass | Each has Given/When/Then criteria with a pass and a fail case (a missing report, no files, unchanged numbers). |
+| 4 | Traceable to a use case or epic | Pass | Each traces to [UC-008] and [MIL-010]. |
+| 5 | Story is sized to fit within a single iteration | Pass | Each says: fits one iteration. |
+| 6 | Story statement avoids technical implementation detail | Pass | The statements name badges, files, lines and coverage; format and branch names are left to the contract. |
+| 7 | Role named in the story matches an actor defined in the Use Case Diagram | Pass | Software Engineer, an actor of UCD-001. |
+
+## Overall Verdict
+
+Go - all criteria pass. The AI records the decision as stand-in for S01; there is no independent reader and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | - | - |
+
+---
+
+[US-001]: ../../user-stories.md
+[QC-US-001]: ../../../framework/qc/artifacts/qc-user-story.md
+[9ca9673]: https://git.tirsystem.com/TirSystem/github-action/commit/9ca9673b00351cf913966f347c4da09890ed3f1f

docs/sqa/reviews/rc-071-ucd-001-metrics.md

@@ -0,0 +1,52 @@
+# Review Record: UCD-001 (Show Code Metrics and Coverage Badges)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-071 |
+| CrossReference | [UCD-001], [QC-UCD-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; accepted | [9ca9673] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [UCD-001]
+- Checklist used: [QC-UCD-001]
+- Scope: delta re-review of the added use case UC8, the actor and use case tables; earlier record RC-045
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Actors are defined with correct UML stereotypes (e.g. `<<System>>`, `<<Actor>>`) | Pass | Unchanged; no new actor. |
+| 2 | System boundary is clearly drawn and labeled | Pass | The new use case is inside the Reusable Workflow Collection rectangle. |
+| 3 | Include/extend relationships are used correctly per UML 2.5.1, not as generic "uses" arrows | Pass | The new use case has no include or extend; the existing two are unchanged. |
+| 4 | Every actor participates in at least one use case (no orphan actors) | Pass | Software Engineer is linked to UC5, UC7 and UC8. |
+| 5 | Diagram is traceable to a documented stakeholder need | Pass | S02 and S05 interests are in UC-008; the actor table lists S02. |
+| 6 | Use case names are verb phrases describing actor goals, not internal system operations | Pass | Show Code Metrics and Coverage Badges. |
+| 7 | Diagram is free of implementation detail (e.g. UI widgets, database tables) | Pass | None added. |
+| 8 | Actor and use case naming is consistent with corresponding Use Case and User Story documents | Pass | Equals the title of UC-008 and the role of US-001.18 to US-001.20. |
+
+## Overall Verdict
+
+Go - all criteria pass. The AI records the decision as stand-in for S01; there is no independent reader and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | - | - |
+
+---
+
+[UCD-001]: ../../use-case-diagram.md
+[QC-UCD-001]: ../../../framework/qc/artifacts/qc-use-case-diagram.md
+[9ca9673]: https://git.tirsystem.com/TirSystem/github-action/commit/9ca9673b00351cf913966f347c4da09890ed3f1f

docs/sqa/reviews/rc-072-adr-0010.md

@@ -0,0 +1,55 @@
+# Review Record: ADR-0010 (contract of the code metrics and coverage badges workflow)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-072 |
+| CrossReference | [ADR-0010], [QC-ADR-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; accepted | [aa4ca0f] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [ADR-0010]
+- Checklist used: [QC-ADR-001]
+- Scope: full review (MIL-010 task 2)
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | The ID (`ADR-NNNN`, 4-digit) matches the filename number and is unique and sequential | Pass | ADR-0010 in `adr-0010-code-metrics-badges-contract.md`; the previous ADR is ADR-0009. |
+| 2 | Context states the problem, the forces (cost, risk, constraints) and the options evaluated | Pass | Problem, the decisions of the user, facts about the runner and the checkout directory, two counter options and three delivery options. |
+| 3 | At least two options were considered, or the absence of alternatives is justified | Pass | Wrap an existing counter or write one; run artifact, default branch or a branch. |
+| 4 | Decision is stated in one or two unhedged sentences and matches one of the evaluated options | Pass | A reusable workflow with three script files and a `badges` branch; the rules follow as a list. |
+| 5 | Consequences list both Positive and Negative outcomes | Pass | Four positive, five negative. |
+| 6 | Quality-attribute impacts (performance, security, portability, etc.) are named where the decision affects them | Pass | Security (a write token, a moving `tools-ref`, branch name validation), compatibility (report formats), maintainability (language table). |
+| 7 | Affected Artifacts are listed as links, and each is also in CrossReference | Pass | MIL-010, UC-008, US-001, ADR-0005, ADR-0006 in both. |
+| 8 | Status changes are recorded as new Version History rows with a Change summary and Commit link; retained rows are never rewritten | Pass | One row, Accepted, commit `pending` until the commit exists. |
+| 9 | A superseded or deprecated ADR names its successor, and the successor links back | N-A | Neither superseded nor deprecated. |
+| 10 | Written in business or technical language of the domain, with no unexplained abbreviations | Pass | SVG, XML and NUL are standard; Cobertura is named as a format. |
+| 11 | Status is one of `Proposed`, `Accepted`, `Rejected`, `Deprecated` or `Superseded by ADR-NNNN`, and every Version History row uses only these | Pass | Accepted. |
+
+## Overall Verdict
+
+Go - all applicable criteria pass; the decisions of the user of 2026-10-14 are recorded and not reopened. The AI records the decision as stand-in for S01; there is no independent reader and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | - | - |
+
+---
+
+[ADR-0010]: ../../adr/adr-0010-code-metrics-badges-contract.md
+[QC-ADR-001]: ../../../framework/qc/artifacts/qc-adr.md
+[aa4ca0f]: https://git.tirsystem.com/TirSystem/github-action/commit/aa4ca0f897b7ea20d90745aa4b7d7a215df123a8

docs/sqa/reviews/rc-073-adr-0010-artifact.md

@@ -0,0 +1,55 @@
+# Review Record: ADR-0010 (the coverage report as an artifact of the caller)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-073 |
+| CrossReference | [ADR-0010], [QC-ADR-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; accepted | [0dc5132] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [ADR-0010]
+- Checklist used: [QC-ADR-001]
+- Scope: delta re-review of the Coverage report and Inputs rules, the Consequences and the Version History after the implementation of MIL-010 task 6 showed that a called workflow cannot see the files of the caller's test job; earlier record RC-072
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | The ID (`ADR-NNNN`, 4-digit) matches the filename number and is unique and sequential | Pass | Unchanged. |
+| 2 | Context states the problem, the forces (cost, risk, constraints) and the options evaluated | Pass | Unchanged; the new force (a called workflow runs in its own job) is stated in the Decision rule that it explains. |
+| 3 | At least two options were considered, or the absence of alternatives is justified | Pass | Unchanged. For the report: an artifact of the caller's run, or a file committed to the repository; both are supported. |
+| 4 | Decision is stated in one or two unhedged sentences and matches one of the evaluated options | Pass | The Decision sentence is unchanged; the coverage rule is a refinement of it. |
+| 5 | Consequences list both Positive and Negative outcomes | Pass | The negative consequence about the report now names the earlier job, the upload and the dependency on the artifact service, which task 8 verifies. |
+| 6 | Quality-attribute impacts (performance, security, portability, etc.) are named where the decision affects them | Pass | The security bullet says the artifact is parsed as XML with entity declarations refused. |
+| 7 | Affected Artifacts are listed as links, and each is also in CrossReference | Pass | Unchanged. |
+| 8 | Status changes are recorded as new Version History rows with a Change summary and Commit link; retained rows are never rewritten | Pass | A new row; the earlier Accepted row became Deprecated and was not rewritten otherwise. |
+| 9 | A superseded or deprecated ADR names its successor, and the successor links back | N-A | The ADR is amended, not superseded. |
+| 10 | Written in business or technical language of the domain, with no unexplained abbreviations | Pass | Artifact is the term of the Actions runtime. |
+| 11 | Status is one of `Proposed`, `Accepted`, `Rejected`, `Deprecated` or `Superseded by ADR-NNNN`, and every Version History row uses only these | Pass | Deprecated and Accepted. |
+
+## Overall Verdict
+
+Go - all applicable criteria pass; the amendment keeps the decisions of the user of 2026-10-14 and corrects a mechanism that cannot work as first written. The AI records the decision as stand-in for S01; there is no independent reader and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | - | - |
+
+---
+
+[ADR-0010]: ../../adr/adr-0010-code-metrics-badges-contract.md
+[QC-ADR-001]: ../../../framework/qc/artifacts/qc-adr.md
+[0dc5132]: https://git.tirsystem.com/TirSystem/github-action/commit/0dc5132a2ea419ba05035ee3594cec63335c240b

docs/sqa/reviews/rc-074-mil-010-results.md

@@ -0,0 +1,51 @@
+# Review Record: MIL-010 (results of tasks 3, 6 and 8)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-074 |
+| CrossReference | [MIL-010], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; accepted | [5c5a1d1] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-010]
+- Checklist used: [QC-MIL-001]
+- Scope: delta re-review of the Verification results section (tasks 3, 6 and 8) and the Version History; the Go/No-Go criteria, deliverable and tasks are unchanged since RC-068
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Unchanged; the results show the workflow, the three badges and a use in another repository. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Unchanged. Evidence so far: criterion 1 (task 3: push with the token of the run, SVG served as image on the instance and the mirror), 2 (ADR-0010, RC-072, RC-073), 3 and 4 (offline fixtures and reports), 5 (valid, stable SVG, offline tests), 6 (no run from the badge push, no commit when unchanged in offline tests, `contents: write` only), 7 (throwaway repository: badges, colour change, named failure), 8 (the workflow runs three script files, no embedded script). Criterion 9 (release) follows in task 9. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | Unchanged: MIL-003 and MIL-004. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | O5 and success criterion 5; criterion 5 is met in the throwaway repository and still wants a project repository. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Unchanged: S05 and S01. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Unchanged: 2027-01-30. |
+
+## Overall Verdict
+
+Go - the recorded results support the criteria 1 to 8; criterion 9 is decided after the release (task 9). The AI records the decision as stand-in for S01; there is no independent reader and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Delete the throwaway repository `TirSystem/code-metrics-adoption` and the branches `verify-badges-delivery` and `badges-verify` of `TirSystem/github-action` (and their copies on the GitHub mirror); the run does not delete repositories or branches | S01 | after the review of the summary |
+| Adopt the workflow in a project repository so that success criterion 5 of the Business Case is met by a real project | S01 | next project that has tests |
+
+---
+
+[MIL-010]: ../../milestones/mil-010-code-metrics-badges.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
+[5c5a1d1]: https://git.tirsystem.com/TirSystem/github-action/commit/5c5a1d19d96a6979b4f6141e736957174ba686a9

docs/sqa/reviews/rc-075-mil-010-outcome.md

@@ -0,0 +1,52 @@
+# Review Record: MIL-010 (outcome: release 2.1.0)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-075 |
+| CrossReference | [MIL-010], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; accepted | [aa20e56] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-010]
+- Checklist used: [QC-MIL-001]
+- Scope: delta re-review of the results of task 9 and the closing statement of the milestone; earlier records RC-068 and RC-074
+- Language and domain: n/a (technical type)
+- Language reviewer: none
+- Mode: autonomous, not independent (the reviewer is `AI as stand-in for S01`; the user accepted the plan in chat on 2026-10-14)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Delivered: `code-metrics.yml` with its three script files, the guide, the wiki pages in three languages and the release 2.1.0 (tag `v2.1.0`, major tag `v2`, release page). |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | All nine criteria are met: 1 to 8 in the results of RC-074, 9 by the release of 2.1.0 (runs 1462 and 1463, the tag and the release page read back through the API). |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | MIL-003 and MIL-004 were used: the reusable workflow mechanism, `tools-ref` and the release workflow. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | O5. Success criterion 5 is met only in a throwaway repository; a project repository still has to adopt it, recorded as an action item. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | S05 and S01. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | Target date 2027-01-30; the work was done on 2026-10-14, ahead of it. |
+
+## Overall Verdict
+
+Go - the milestone is complete: every Go/No-Go criterion is met and the workflow is released as 2.1.0. The AI records the decision as stand-in for S01; there is no independent reader and the decision stays open to challenge in the run summary.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Adopt `code-metrics.yml` in a project repository, so that success criterion 5 is met by a real project | S01 | next project that has tests |
+| Delete the throwaway repository `TirSystem/code-metrics-adoption` and the branches `verify-badges-delivery` and `badges-verify` (and their copies on the GitHub mirror) | S01 | after the review of the summary |
+| Find where the required check `TirSystem/github-action: Publish wiki / *` comes from; it blocked the merge of pull request 164 through the API and is not in the branch protection of the repository | S03 | before the next pull request |
+
+---
+
+[MIL-010]: ../../milestones/mil-010-code-metrics-badges.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
+[aa20e56]: https://git.tirsystem.com/TirSystem/github-action/commit/aa20e56110f4c2fab91a8432ba008ee8300926a2

docs/sqa/reviews/rc-076-mil-011-plan.md

@@ -0,0 +1,67 @@
+# Review Record: MIL-011 and PP-001 (MIL-011)
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-076 |
+| CrossReference | [MIL-011], [PP-001], [BC-001], [QC-MIL-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version; accepted by the author in chat as stand-in for S01, after three corrections found in the first read | [3d7a9df] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-011]; delta of [PP-001] for the added milestone
+- Checklist used: [QC-MIL-001] for the milestone; for the plan, the criteria of `PP.md` (no QC checklist exists for PP-001)
+- Scope: full review of MIL-011; delta re-review of PP-001, earlier record [RC-068]
+- Language and domain: n/a (technical type)
+- Mode: supervised, not independent (the author, Jens Tirsvad Nielsen, asked in chat on 2026-10-14 for the review and the acceptance and stands in for S01; the AI prepared the evidence)
+
+## Checklist Results
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | `## Deliverable` names the patch release 2.1.1: the defaults, the test, the guides, README and three wiki languages at `@v2`, the changelog entry, and the framework `Badges` page without the workaround. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Eight criteria, each with a checkable Go and No-Go: reproduction, a list per workflow, a test that fails on a seeded default, a search that finds no `@v1`, a run on the instance, the release level and tags, the framework page, the review record. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | [MIL-010] (the workflow and its guide) and [ADR-0006] (the release process); in the plan's dependency diagram (`MIL-010 -> MIL-011`). |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | O5 of [BC-001]; the first read found its wording paraphrased wrongly, now quoted from the Business Case. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Owner S05, approving reviewer S01; both are in [SA-001]. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-10-23; the Business Case sets no deadline. The date precedes the planned decision date of [MIL-010] (2027-01-30) because that milestone was released on 2026-10-14; the milestone says so and does not change the MIL-010 row. |
+
+## Plan delta (PP-001)
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | Every milestone has a `MIL-*` document and the plan's dates equal that document's target date | Pass | MIL-001 to MIL-011 exist; the MIL-011 decision date (2026-10-23) equals its Target Date. |
+| 2 | Every Business Case scope item is covered by a gateway | Pass | The first read found a scope row that is not a Business Case item; it is removed and MIL-011 is listed beside MIL-010 for the badges item. |
+| 3 | The schedule respects the Business Case constraints | Pass | No deadline in the Business Case; the window is one week. |
+| 4 | Dependencies between milestones are stated | Pass | `MIL-003 + MIL-004 -> MIL-010 -> MIL-011`. |
+| 5 | Every gateway has an owner who is a stakeholder ID | Pass | S05. |
+| 6 | Plan content is internally consistent | Pass | The first read found "ten milestones" in the Purpose; it is now "eleven", and the Gantt, the schedule and the dependencies agree. |
+| 7 | Open Issues are current | Pass | No plan risk was added for a default that names an old major; the release process and the test of task 3 carry the rule. Observation, not a failure. |
+
+## Overall Verdict
+
+Go - all criteria pass after three corrections found in the first read (the O5 wording, "ten milestones", and a scope row that was not a Business Case item). The author confirmed the acceptance in chat on 2026-10-14 as stand-in for S01; this is not an independent review.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Confirm this record by S01 when an independent reading is possible | S01 | 2026-10-30 |
+| Task 1: reproduce the failure and list the defaults before any change to the workflows | S05 | 2026-10-16 |
+
+---
+
+[MIL-011]: ../../milestones/mil-011-code-metrics-default-tools-ref.md
+[PP-001]: ../../project-plan.md
+[BC-001]: ../../business-case.md
+[SA-001]: ../../stakeholder-analysis.md
+[ADR-0006]: ../../adr/adr-0006-release-process-and-version-pinning.md
+[RC-068]: ./rc-068-mil-010-plan.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
+[3d7a9df]: https://git.tirsystem.com/TirSystem/github-action/commit/3d7a9df3a3a4712dcc5214a71b0569d90122bf4e

docs/sqa/traceability-matrix.md

@@ -4,13 +4,13 @@
 | Key | Value |
 | --- | --- |
 | ID | TM-001 |
-| CrossReference | [BC-001], [SA-001], [PP-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [RC-001], [RC-002], [RC-003], [RC-004], [RC-005], [RC-006], [RC-007], [RC-008], [RC-009], [RC-010], [RC-011], [RC-012], [RC-013], [RC-014], [RC-015], [RC-016], [RC-017], [RC-018], [RC-019], [RC-020], [RC-021], [RC-022], [RC-023], [RC-024], [RC-025], [RC-026], [RC-027], [RC-028], [RC-029], [RC-030], [RC-031], [RC-032], [RC-033], [RC-034], [RC-035], [RC-036], [RC-037], [RC-038], [RC-039], [RC-040], [RC-041], [RC-042], [RC-043], [RC-044], [RC-045], [RC-046], [RC-047], [RC-048], [RC-049], [RC-050], [RC-051], [RC-052], [RC-053], [ADR-0007], [UC-007], [UC-006], [ADR-0006], [UC-005], [ADR-0005], [UCD-001], [US-001], [UC-001], [UC-002], [UC-003], [UC-004], [ADR-0001], [ADR-0002], [ADR-0003], [ADR-0004] |
+| CrossReference | [BC-001], [SA-001], [PP-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009], [MIL-010], [MIL-011], [UC-008], [RC-001], [RC-002], [RC-003], [RC-004], [RC-005], [RC-006], [RC-007], [RC-008], [RC-009], [RC-010], [RC-011], [RC-012], [RC-013], [RC-014], [RC-015], [RC-016], [RC-017], [RC-018], [RC-019], [RC-020], [RC-021], [RC-022], [RC-023], [RC-024], [RC-025], [RC-026], [RC-027], [RC-028], [RC-029], [RC-030], [RC-031], [RC-032], [RC-033], [RC-034], [RC-035], [RC-036], [RC-037], [RC-038], [RC-039], [RC-040], [RC-041], [RC-042], [RC-043], [RC-044], [RC-045], [RC-046], [RC-047], [RC-048], [RC-049], [RC-050], [RC-051], [RC-052], [RC-053], [RC-054], [RC-055], [RC-056], [RC-057], [RC-058], [RC-059], [RC-060], [RC-061], [RC-062], [RC-063], [RC-064], [RC-065], [RC-066], [RC-067], [RC-068], [RC-069], [RC-070], [RC-071], [RC-072], [RC-073], [RC-074], [RC-075], [ADR-0007], [ADR-0008], [ADR-0009], [ADR-0010], [UC-007], [UC-006], [ADR-0006], [UC-005], [ADR-0005], [UCD-001], [US-001], [UC-001], [UC-002], [UC-003], [UC-004], [ADR-0001], [ADR-0002], [ADR-0003], [ADR-0004] |
 
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-11 | Deprecated | Jens Tirsvad Nielsen | S01 | Added RC-051 (ADR-0005 tools-ref) | [670f0ac] |
-| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Added MIL-007, RC-052 and RC-053 | [e3ad1fa] |
+| 2026-10-14 | Proposed | Jens Tirsvad Nielsen | S01 | Added RC-075 (MIL-010 outcome, release 2.1.0) | [aa20e56] |
+| 2026-10-14 | Proposed | Jens Tirsvad Nielsen | S01 | Added MIL-011 and RC-076 (fix the defaults of the code metrics workflow) | [3d7a9df] |
 
 ---
 
@@ -25,12 +25,13 @@ updated whenever an artifact instance is created or reviewed.
 | Artifact Instance | Type | Upstream (Backward Link) | Downstream (Forward Link) | Last Reviewed (RC-ID) |
 | --- | --- | --- | --- | --- |
 | [SA-001] | SA | - | [BC-001], [UCD-001] | [RC-004] |
-| [BC-001] | BC | [SA-001] | [PP-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006] | [RC-001], [RC-008] |
-| [PP-001] | PP | [BC-001], [SA-001] | [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [US-001] | [RC-002], [RC-009], [RC-015], [RC-017], [RC-025], [RC-032], [RC-053] |
+| [BC-001] | BC | [SA-001] | [PP-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006] | [RC-001], [RC-008], [RC-067] |
+| [PP-001] | PP | [BC-001], [SA-001] | [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009], [MIL-010], [US-001] | [RC-002], [RC-009], [RC-015], [RC-017], [RC-025], [RC-032], [RC-053], [RC-062], [RC-064], [RC-068] |
 | [MIL-001] | MIL | [BC-001], [PP-001] | [MIL-002] | [RC-003], [RC-026] |
 | [MIL-002] | MIL | [BC-001], [PP-001], [MIL-001] | [MIL-003], [MIL-005] | [RC-005], [RC-027] |
 | [MIL-003] | MIL | [BC-001], [PP-001], [MIL-002] | [MIL-004] | [RC-006], [RC-028], [RC-033], [RC-039] |
 | [MIL-004] | MIL | [BC-001], [PP-001], [MIL-003] | - | [RC-007], [RC-029], [RC-034], [RC-048] |
+| [ADR-0010] | ADR | [MIL-010], [UC-008], [US-001], [ADR-0005], [ADR-0006] | - | [RC-072], [RC-073] |
 | [RC-001] | RC | [BC-001] | - | - |
 | [RC-002] | RC | [PP-001] | - | - |
 | [RC-003] | RC | [MIL-001] | - | - |
@@ -38,8 +39,12 @@ updated whenever an artifact instance is created or reviewed.
 | [RC-005] | RC | [MIL-002] | - | - |
 | [RC-006] | RC | [MIL-003] | - | - |
 | [MIL-005] | MIL | [BC-001], [PP-001], [MIL-002] | [MIL-006] | [RC-010], [RC-011], [RC-030], [RC-050] |
-| [MIL-006] | MIL | [BC-001], [PP-001], [MIL-002], [MIL-005] | - | [RC-016], [RC-031], [RC-049] |
-| [MIL-007] | MIL | [BC-001], [PP-001], [MIL-003], [MIL-004] | - | [RC-052] |
+| [MIL-006] | MIL | [BC-001], [PP-001], [MIL-002], [MIL-005] | - | [RC-016], [RC-031], [RC-049], [RC-058] |
+| [MIL-007] | MIL | [BC-001], [PP-001], [MIL-003], [MIL-004], [ADR-0008] | - | [RC-052], [RC-055], [RC-059] |
+| [MIL-008] | MIL | [BC-001], [PP-001], [MIL-006], [ADR-0004] | [MIL-009] | [RC-060], [RC-061] |
+| [MIL-009] | MIL | [BC-001], [PP-001], [MIL-008], [ADR-0004], [ADR-0006], [ADR-0009] | - | [RC-064], [RC-066] |
+| [MIL-010] | MIL | [BC-001], [PP-001], [MIL-003], [MIL-004] | [MIL-011] | [RC-068], [RC-074], [RC-075] |
+| [MIL-011] | MIL | [BC-001], [PP-001], [MIL-010], [ADR-0006], [ADR-0010] | - | [RC-076] |
 | [RC-007] | RC | [MIL-004] | - | - |
 | [RC-008] | RC | [BC-001] | - | - |
 | [RC-009] | RC | [PP-001] | - | - |
@@ -47,7 +52,7 @@ updated whenever an artifact instance is created or reviewed.
 | [ADR-0001] | ADR | [BC-001], [MIL-005] | [ADR-0003] | [RC-012] |
 | [ADR-0002] | ADR | [SA-001], [RC-001] | - | [RC-013] |
 | [ADR-0003] | ADR | [MIL-005], [ADR-0001], [RC-011] | [ADR-0004] | [RC-014] |
-| [ADR-0004] | ADR | [MIL-006], [ADR-0003], [ADR-0002] | - | [RC-018] |
+| [ADR-0004] | ADR | [MIL-006], [ADR-0003], [ADR-0002] | [ADR-0009] | [RC-018], [RC-065] |
 | [RC-011] | RC | [MIL-005] | - | - |
 | [RC-012] | RC | [ADR-0001] | - | - |
 | [RC-013] | RC | [ADR-0002] | - | - |
@@ -56,18 +61,21 @@ updated whenever an artifact instance is created or reviewed.
 | [RC-016] | RC | [MIL-006] | - | - |
 | [RC-017] | RC | [PP-001] | - | - |
 | [RC-018] | RC | [ADR-0004] | - | - |
-| [UCD-001] | UCD | [SA-001], [BC-001] | [US-001], [UC-001], [UC-002], [UC-003], [UC-004], [UC-005], [UC-006], [UC-007] | [RC-019], [RC-035], [RC-040], [RC-045] |
-| [US-001] | US | [UCD-001], [BC-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004] | [UC-001], [UC-002], [UC-003], [UC-004], [UC-005], [UC-006], [UC-007] | [RC-020], [RC-036], [RC-041], [RC-046] |
+| [UCD-001] | UCD | [SA-001], [BC-001] | [US-001], [UC-001], [UC-002], [UC-003], [UC-004], [UC-005], [UC-006], [UC-007], [UC-008] | [RC-019], [RC-035], [RC-040], [RC-045], [RC-071] |
+| [US-001] | US | [UCD-001], [BC-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-007] | [UC-001], [UC-002], [UC-003], [UC-004], [UC-005], [UC-006], [UC-007], [UC-008] | [RC-020], [RC-036], [RC-041], [RC-046], [RC-057], [RC-070] |
 | [UC-001] | UC | [UCD-001], [US-001], [SA-001] | - | [RC-021] |
 | [UC-002] | UC | [UCD-001], [US-001], [SA-001] | - | [RC-022] |
 | [UC-003] | UC | [UCD-001], [US-001], [SA-001] | - | [RC-023] |
 | [UC-004] | UC | [UCD-001], [US-001], [SA-001] | - | [RC-024] |
-| [UC-005] | UC | [UCD-001], [US-001], [SA-001] | [ADR-0005] | [RC-037] |
+| [UC-005] | UC | [UCD-001], [US-001], [SA-001] | [ADR-0005] | [RC-037], [RC-056] |
 | [ADR-0005] | ADR | [MIL-003], [UC-005], [US-001], [ADR-0004] | - | [RC-038], [RC-051] |
 | [UC-006] | UC | [UCD-001], [US-001], [SA-001] | [ADR-0006] | [RC-042] |
 | [ADR-0006] | ADR | [MIL-004], [UC-006], [US-001], [ADR-0004], [ADR-0005] | - | [RC-043] |
 | [ADR-0007] | ADR | [MIL-004], [UC-006], [ADR-0006] | - | [RC-047] |
+| [ADR-0008] | ADR | [MIL-007], [UC-005], [US-001], [ADR-0005], [ADR-0006] | - | [RC-054] |
+| [ADR-0009] | ADR | [MIL-008], [ADR-0003], [ADR-0004], [ADR-0005], [ADR-0006] | - | [RC-063] |
 | [UC-007] | UC | [UCD-001], [US-001], [SA-001] | - | [RC-044] |
+| [UC-008] | UC | [UCD-001], [US-001], [SA-001], [MIL-010] | - | [RC-069] |
 | [RC-019] | RC | [UCD-001] | - | - |
 | [RC-020] | RC | [US-001] | - | - |
 | [RC-021] | RC | [UC-001] | - | - |
@@ -103,6 +111,29 @@ updated whenever an artifact instance is created or reviewed.
 | [RC-051] | RC | [ADR-0005] | - | - |
 | [RC-052] | RC | [MIL-007] | - | - |
 | [RC-053] | RC | [PP-001] | - | - |
+| [RC-054] | RC | [ADR-0008] | - | - |
+| [RC-055] | RC | [MIL-007] | - | - |
+| [RC-056] | RC | [UC-005] | - | - |
+| [RC-057] | RC | [US-001] | - | - |
+| [RC-058] | RC | [MIL-006] | - | - |
+| [RC-059] | RC | [MIL-007] | - | - |
+| [RC-060] | RC | [MIL-008] | - | - |
+| [RC-061] | RC | [MIL-008] | - | - |
+| [RC-062] | RC | [PP-001] | - | - |
+| [RC-063] | RC | [ADR-0009] | - | - |
+| [RC-064] | RC | [MIL-009], [PP-001] | - | - |
+| [RC-065] | RC | [ADR-0004] | - | - |
+| [RC-066] | RC | [MIL-009] | - | - |
+| [RC-067] | RC | [BC-001] | - | - |
+| [RC-068] | RC | [MIL-010], [PP-001] | - | - |
+| [RC-069] | RC | [UC-008] | - | - |
+| [RC-070] | RC | [US-001] | - | - |
+| [RC-071] | RC | [UCD-001] | - | - |
+| [RC-072] | RC | [ADR-0010] | - | - |
+| [RC-073] | RC | [ADR-0010] | - | - |
+| [RC-074] | RC | [MIL-010] | - | - |
+| [RC-075] | RC | [MIL-010] | - | - |
+| [RC-076] | RC | [MIL-011], [PP-001] | - | - |
 
 ## Coverage Notes
 
@@ -123,6 +154,11 @@ updated whenever an artifact instance is created or reviewed.
 [MIL-005]: ../milestones/mil-005-wiki-and-translations.md
 [MIL-006]: ../milestones/mil-006-shared-wiki-publishing.md
 [MIL-007]: ../milestones/mil-007-cpp-csharp-quality-checks.md
+[MIL-008]: ../milestones/mil-008-wiki-reusable-workflow.md
+[MIL-010]: ../milestones/mil-010-code-metrics-badges.md
+[MIL-011]: ../milestones/mil-011-code-metrics-default-tools-ref.md
+[MIL-009]: ../milestones/mil-009-migrate-wiki-callers-and-remove-scoped-workflow.md
+[ADR-0010]: ../adr/adr-0010-code-metrics-badges-contract.md
 [RC-001]: ./reviews/rc-001-business-case.md
 [RC-002]: ./reviews/rc-002-project-plan.md
 [RC-003]: ./reviews/rc-003-mil-001.md
@@ -186,11 +222,37 @@ updated whenever an artifact instance is created or reviewed.
 [RC-051]: ./reviews/rc-051-adr-0005-tools-ref.md
 [RC-052]: ./reviews/rc-052-mil-007.md
 [RC-053]: ./reviews/rc-053-pp-001-mil-007.md
+[RC-054]: ./reviews/rc-054-adr-0008.md
+[RC-055]: ./reviews/rc-055-mil-007-amendment.md
+[RC-056]: ./reviews/rc-056-uc-005-cpp-csharp.md
+[RC-057]: ./reviews/rc-057-us-001-cpp-csharp.md
+[RC-058]: ./reviews/rc-058-mil-006-task-6.md
+[RC-059]: ./reviews/rc-059-mil-007-adoption.md
+[RC-060]: ./reviews/rc-060-mil-008-plan.md
+[RC-061]: ./reviews/rc-061-mil-008-task-5-deferred.md
+[RC-062]: ./reviews/rc-062-pp-001-mil-008.md
+[RC-063]: ./reviews/rc-063-adr-0009.md
+[RC-064]: ./reviews/rc-064-mil-009-plan.md
+[RC-065]: ./reviews/rc-065-adr-0004-superseded.md
+[RC-066]: ./reviews/rc-066-mil-009-outcome.md
+[RC-067]: ./reviews/rc-067-bc-001-o5.md
+[RC-068]: ./reviews/rc-068-mil-010-plan.md
+[RC-069]: ./reviews/rc-069-uc-008.md
+[RC-070]: ./reviews/rc-070-us-001-metrics.md
+[RC-071]: ./reviews/rc-071-ucd-001-metrics.md
+[RC-072]: ./reviews/rc-072-adr-0010.md
+[RC-073]: ./reviews/rc-073-adr-0010-artifact.md
+[RC-074]: ./reviews/rc-074-mil-010-results.md
+[RC-075]: ./reviews/rc-075-mil-010-outcome.md
+[RC-076]: ./reviews/rc-076-mil-011-plan.md
+[ADR-0008]: ../adr/adr-0008-cpp-csharp-quality-check-contract.md
+[ADR-0009]: ../adr/adr-0009-wiki-publishing-reusable-workflow.md
 [ADR-0007]: ../adr/adr-0007-release-publish-destination.md
 [UC-007]: ../uc-007/uc.md
+[UC-008]: ../uc-008/uc.md
 [UC-006]: ../uc-006/uc.md
 [ADR-0006]: ../adr/adr-0006-release-process-and-version-pinning.md
 [UC-005]: ../uc-005/uc.md
 [ADR-0005]: ../adr/adr-0005-quality-check-contract.md
-[670f0ac]: https://git.tirsystem.com/TirSystem/github-action/commit/670f0ac469043bb166c84290c0dbf62b4908e3cc
-[e3ad1fa]: https://git.tirsystem.com/TirSystem/github-action/commit/e3ad1fa7e7eef57a6793a479edb41ac6fd2db688
+[aa20e56]: https://git.tirsystem.com/TirSystem/github-action/commit/aa20e56110f4c2fab91a8432ba008ee8300926a2
+[3d7a9df]: https://git.tirsystem.com/TirSystem/github-action/commit/3d7a9df3a3a4712dcc5214a71b0569d90122bf4e

docs/uc-005/uc.md

@@ -9,8 +9,8 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-10 | Deprecated | Jens Tirsvad Nielsen | S01 | Initial version | [385d2fb] |
-| 2026-10-11 | Proposed | Jens Tirsvad Nielsen | S01 | Brief extended to C++ and C# (MIL-007 task 1) | [32b5ab6] |
+| 2026-10-11 | Deprecated | Jens Tirsvad Nielsen | S01 | Brief extended to C++ and C# (MIL-007 task 1) | [32b5ab6] |
+| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Brief extended to C++ and C# reviewed (RC-056) and accepted; the failure sentence is left to the stories | [1bc56f8] |
 
 ---
 
@@ -25,7 +25,7 @@
 
 ## Brief
 
-A Software Engineer opens a pull request in a repository that calls the shared quality-check workflow. The workflow installs the pinned tools, runs the checks for each selected language on the files of the repository (lint, format and types for Python; lint and format for shell; format and static checks for C++; format and analyzer checks for C#), and reports one status for the pull request. A language that needs a build or a project file says what is missing instead of passing. When every selected tool passes, the status is green.
+A Software Engineer opens a pull request in a repository that calls the shared quality-check workflow. The workflow installs the pinned tools, runs the checks for each selected language on the files of the repository (lint, format and types for Python; lint and format for shell; format and static checks for C++; format and analyzer checks for C#), and reports one status for the pull request. When every selected tool passes, the status is green.
 
 **Stakeholder interests**
 
@@ -43,5 +43,5 @@ A Software Engineer opens a pull request in a repository that calls the shared q
 [SA-001]: ../stakeholder-analysis.md
 [ADR-0005]: ../adr/adr-0005-quality-check-contract.md
 [MIL-007]: ../milestones/mil-007-cpp-csharp-quality-checks.md
-[385d2fb]: https://git.tirsystem.com/TirSystem/github-action/commit/385d2fb7cb9be1fdc8fd3503d0af624fa38eafc7
 [32b5ab6]: https://git.tirsystem.com/TirSystem/github-action/commit/32b5ab62ab5a82638b71b8fcfb43a819e92ab346
+[1bc56f8]: https://git.tirsystem.com/TirSystem/github-action/commit/1bc56f8b771531f221f218fc00b147ecc73c051e

docs/uc-008/uc.md

@@ -0,0 +1,44 @@
+# UC-008: Show Code Metrics and Coverage Badges
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | UC-008 |
+| CrossReference | [UCD-001], [US-001], [SA-001], [MIL-010] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version; reviewed (RC-069) | [9ca9673] |
+
+---
+
+**Format:** Brief
+
+**Title:** Show Code Metrics and Coverage Badges
+**Scope:** Reusable Workflow Collection
+**Level:** user-goal
+**Primary Actor:** Software Engineer
+**Stakeholders:** S02, S05 (interests below)
+**Stories:** US-001.18, US-001.19, US-001.20
+
+## Brief
+
+A Software Engineer pushes a change to a repository that calls the shared code-metrics workflow. The workflow counts the code files and the lines of code (without comment and blank lines), reads the coverage report the repository supplies, and publishes three badges: the number of code files, the number of lines of code and the coverage. The repository's README shows the badges, and they show the numbers of the latest push.
+
+**Stakeholder interests**
+
+- S02 — the size and the coverage of the code are visible at a glance, without a service outside the instance, and a wrong or missing report is reported instead of shown as a number
+- S05 — the counting rules and the badge contract are defined once and change through a reviewed release
+
+**Preconditions:** The repository is onboarded and the shared workflow is available through reusable workflow delivery; a coverage badge needs a coverage report that the repository's own tests have produced.
+
+**Postconditions (success guarantee):** The three badges show the numbers of the pushed revision, nothing but the badges is changed in the repository, and a run whose numbers are unchanged changes nothing.
+
+---
+
+[UCD-001]: ../use-case-diagram.md
+[US-001]: ../user-stories.md
+[SA-001]: ../stakeholder-analysis.md
+[MIL-010]: ../milestones/mil-010-code-metrics-badges.md
+[9ca9673]: https://git.tirsystem.com/TirSystem/github-action/commit/9ca9673b00351cf913966f347c4da09890ed3f1f

docs/use-case-diagram.md

@@ -4,13 +4,13 @@
 | Key | Value |
 | --- | --- |
 | ID | UCD-001 |
-| CrossReference | [SA-001], [BC-001], [US-001], [UC-001], [UC-002], [UC-003], [UC-004], [UC-005], [UC-006], [UC-007] |
+| CrossReference | [SA-001], [BC-001], [US-001], [UC-001], [UC-002], [UC-003], [UC-004], [UC-005], [UC-006], [UC-007], [UC-008] |
 
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-10 | Deprecated | Jens Tirsvad Nielsen | S01 | Added the use case Release a Reusable Workflow (UC-006) | [044d8ba] |
-| 2026-10-10 | Accepted | Jens Tirsvad Nielsen | S01 | Added the use case Consume a Workflow Update (UC-007) (RC-045) | [4cf52af] |
+| 2026-10-10 | Deprecated | Jens Tirsvad Nielsen | S01 | Added the use case Consume a Workflow Update (UC-007) (RC-045) | [4cf52af] |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Added the use case Show Code Metrics and Coverage Badges (UC-008); reviewed (RC-071) | [9ca9673] |
 
 ---
 
@@ -46,6 +46,7 @@ rectangle "Reusable Workflow Collection" <<System>> {
   usecase "Run Project Quality Checks" as UC5
   usecase "Release a Reusable Workflow" as UC6
   usecase "Consume a Workflow Update" as UC7
+  usecase "Show Code Metrics and Coverage Badges" as UC8
 }
 
 DevOps --> UC1
@@ -57,6 +58,7 @@ Operator --> UC2
 Operator --> UC4
 Engineer --> UC5
 Engineer --> UC7
+Engineer --> UC8
 UC1 --> Gitea
 UC1 --> GitHub
 UC3 ..> UC2 : <<include>>
@@ -70,7 +72,7 @@ UC4 ..> UC1 : <<extend>>
 | --- | --- | --- | --- |
 | DevOps Professional | `<<Actor>>` | S05 | Synchronize Repository Metadata, Configure Workflow Credentials, Onboard a Repository, Diagnose a Failed Workflow, Release a Reusable Workflow |
 | Platform Operator | `<<Actor>>` | S03 | Configure Workflow Credentials, Diagnose a Failed Workflow |
-| Software Engineer | `<<Actor>>` | S02 | Run Project Quality Checks, Consume a Workflow Update |
+| Software Engineer | `<<Actor>>` | S02 | Run Project Quality Checks, Consume a Workflow Update, Show Code Metrics and Coverage Badges |
 | Gitea Instance | `<<System>>` | - | Synchronize Repository Metadata (source of description and topics) |
 | GitHub | `<<System>>` | S04 (audience of the mirror) | Synchronize Repository Metadata (target) |
 
@@ -85,6 +87,7 @@ UC4 ..> UC1 : <<extend>>
 | Run Project Quality Checks | Software Engineer | Lint, format and type checks run on every change and report a pass or a fail |
 | Release a Reusable Workflow | DevOps Professional | A validated, versioned update that consumers can pin |
 | Consume a Workflow Update | Software Engineer | A new version is adopted safely, one repository first |
+| Show Code Metrics and Coverage Badges | Software Engineer | The size and the coverage of the code are visible as badges that follow every push |
 
 ## Relationships
 
@@ -104,6 +107,7 @@ UC4 ..> UC1 : <<extend>>
 [UC-004]: ./uc-004/uc.md
 [UC-005]: ./uc-005/uc.md
 [UC-006]: ./uc-006/uc.md
-[044d8ba]: https://git.tirsystem.com/TirSystem/github-action/commit/044d8ba21f96f4aceb807d62addc35cdcbb56051
 [UC-007]: ./uc-007/uc.md
+[UC-008]: ./uc-008/uc.md
 [4cf52af]: https://git.tirsystem.com/TirSystem/github-action/commit/4cf52afe00f546c6b20424fb8dfc12796ffd9296
+[9ca9673]: https://git.tirsystem.com/TirSystem/github-action/commit/9ca9673b00351cf913966f347c4da09890ed3f1f

docs/user-stories.md

@@ -4,13 +4,13 @@
 | Key | Value |
 | --- | --- |
 | ID | US-001 |
-| CrossReference | [UCD-001], [BC-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [UC-001], [UC-002], [UC-003], [UC-004], [UC-005], [UC-006], [UC-007], [MIL-007] |
+| CrossReference | [UCD-001], [BC-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [UC-001], [UC-002], [UC-003], [UC-004], [UC-005], [UC-006], [UC-007], [MIL-007], [UC-008], [MIL-010] |
 
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-10 | Deprecated | Jens Tirsvad Nielsen | S01 | Added US-001.14 and US-001.15 (UC-007); US-001.13 traced to UC-007 (RC-046) | [4cf52af] |
-| 2026-10-11 | Proposed | Jens Tirsvad Nielsen | S01 | Added US-001.16 and US-001.17 (C++ and C# checks, MIL-007 task 1) | [32b5ab6] |
+| 2026-10-11 | Deprecated | Jens Tirsvad Nielsen | S01 | US-001.16 and US-001.17 reviewed (RC-057) and accepted; the Purpose and Scope names the later stories | [1bc56f8] |
+| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Added US-001.18 to US-001.20 (code metrics and coverage badges, MIL-010 task 1); reviewed (RC-070) | [9ca9673] |
 
 ---
 
@@ -19,7 +19,10 @@
 These stories cover the P1 use cases of the Project Plan that MIL-002 delivers
 (O1 to O3 of [BC-001]): keeping the mirror metadata correct, configuring
 credentials, onboarding a repository and diagnosing a failed run. Roles are the
-actors of [UCD-001]. Stories for quality checks and releases (MIL-004) and for the wiki (MIL-005, MIL-006) are not written yet.
+actors of [UCD-001]. Later stories cover quality checks (US-001.09, US-001.10 and, for
+C++ and C#, US-001.16 and US-001.17), releases and updates (US-001.11 to
+US-001.15) and the code metrics and coverage badges (US-001.18 to
+US-001.20). Stories for the wiki (MIL-005, MIL-006) are not written yet.
 
 ## Story List
 
@@ -246,9 +249,50 @@ actors of [UCD-001]. Stories for quality checks and releases (MIL-004) and for t
 | --- | --- | --- |
 | [UC-005], [MIL-007] | fits one iteration | none |
 
+### US-001.18 — The size of the code is visible as badges
+
+**As a** Software Engineer, **I want** badges that show the number of code files and the number of lines of code without comment and blank lines, **so that** the size of the project is visible in its README without a service outside the instance.
+
+**Acceptance Criteria**
+
+- Given a repository that calls the shared code-metrics workflow, when a change is pushed, then a badge for the code files and a badge for the lines of code show the numbers of that revision.
+- Given a file with a comment line, a blank line and a code line, when the lines are counted, then only the code line is counted as a line of code.
+- Given a repository without a file of a supported language, when the workflow runs, then it passes with a notice and the badges show zero.
+
+| Traces to | Size | INVEST exceptions |
+| --- | --- | --- |
+| [UC-008], [MIL-010] | fits one iteration | none |
+
+### US-001.19 — The coverage is visible as a badge
+
+**As a** Software Engineer, **I want** a badge that shows how much of the code my tests cover, **so that** a drop in coverage is seen as soon as it is pushed.
+
+**Acceptance Criteria**
+
+- Given a repository that supplies a coverage report, when a change is pushed, then a coverage badge shows the percentage of the report, and its colour follows the thresholds of the contract.
+- Given a coverage report that is missing or that cannot be read, when the workflow runs, then it fails with a `[configuration]` message that names the report file and no coverage badge is changed.
+- Given a repository that supplies no coverage report, when the workflow runs, then it passes with a notice and publishes no coverage badge.
+
+| Traces to | Size | INVEST exceptions |
+| --- | --- | --- |
+| [UC-008], [MIL-010] | fits one iteration | none |
+
+### US-001.20 — A run with unchanged numbers changes nothing
+
+**As a** Software Engineer, **I want** the workflow to commit nothing when the numbers did not change, **so that** the history of the repository is not filled with badge commits.
+
+**Acceptance Criteria**
+
+- Given a push after which none of the three badges would differ, when the workflow runs, then no commit is made.
+- Given a push after which a number changed, when the workflow runs, then one commit changes only the badge files, and the workflow does not start again from that commit.
+
+| Traces to | Size | INVEST exceptions |
+| --- | --- | --- |
+| [UC-008], [MIL-010] | fits one iteration | none |
+
 ## INVEST Check
 
-All seventeen stories are independent of each other except that US-001.05 and
+All twenty stories are independent of each other except that US-001.05 and
 US-001.06 build on US-001.04 (the secrets must exist before a repository can
 run the workflow). Each states one goal and can be negotiated, delivers value
 to the named role, is small enough for one iteration, and has acceptance
@@ -272,5 +316,7 @@ behaviour is tested rather than built.
 [UC-005]: ./uc-005/uc.md
 [UC-006]: ./uc-006/uc.md
 [UC-007]: ./uc-007/uc.md
-[4cf52af]: https://git.tirsystem.com/TirSystem/github-action/commit/4cf52afe00f546c6b20424fb8dfc12796ffd9296
-[32b5ab6]: https://git.tirsystem.com/TirSystem/github-action/commit/32b5ab62ab5a82638b71b8fcfb43a819e92ab346
+[UC-008]: ./uc-008/uc.md
+[MIL-010]: ./milestones/mil-010-code-metrics-badges.md
+[1bc56f8]: https://git.tirsystem.com/TirSystem/github-action/commit/1bc56f8b771531f221f218fc00b147ecc73c051e
+[9ca9673]: https://git.tirsystem.com/TirSystem/github-action/commit/9ca9673b00351cf913966f347c4da09890ed3f1f

docs/wiki/Capabilities.da.md

@@ -1,4 +1,4 @@
-<!-- translation of Capabilities.md, source sha256 a8c03a001880 -->
+<!-- translation of Capabilities.md, source sha256 3e3bcd9498f7 -->
 
 > Dette er en oversættelse af [`Capabilities`](Capabilities). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
 
@@ -13,6 +13,8 @@ Rækker, der siger Implementeret eller Vejledninger er skrevet, findes i dag. Re
 | Synkronisering af repositorymetadata (Gitea til GitHub-spejl) | Implementeret i `.gitea/scoped_workflows/`, med offline-tests og et valideringsworkflow |
 | Konfiguration og validering af workflow-credentials | Implementeret for synkroniseringsworkflowet: en forhåndskontrol tjekker begge tokens før enhver ændring ([vejledning](Credentials.da)) |
 | Tilslutning af et repository, administration af runners, fejlfinding | Vejledninger er skrevet ([tilslutning](Onboarding.da), [fejlfinding](Troubleshooting.da)); scoped levering til alle fire organisationers repositories er verificeret (MIL-002) |
-| Publicering af et repositorys wiki fra `wiki/` (tilmelding, leveres til alle organisationer) | Implementeret i `.gitea/scoped_workflows/publish-wiki.yml`, med offline-tests; et pilotforsøg i et andet repository publicerer sin wiki (MIL-006) |
+| Publicering af et repositorys wiki fra `docs/wiki/` gennem et kaldt workflow | Implementeret som det genbrugelige workflow `.gitea/workflows/publish-wiki-pages.yml`, med offline-tests; kaldt af hvert repository, der publicerer en wiki, og dette repositorys egen wiki er i `docs/wiki/` (MIL-008, MIL-009) |
 | Fælles kvalitetskontrol (Python og shell) | Implementeret som det genbrugelige workflow `.gitea/workflows/quality-checks.yml`, med offline-tests og et forsøg i en anden organisation; taget i brug i RepoFoundry ([vejledning](QualityChecksPythonShell.da)) |
+| Fælles kvalitetskontrol (C og C++, C#) | Implementeret som de genbrugelige workflows `.gitea/workflows/quality-checks-cpp.yml` og `.gitea/workflows/quality-checks-csharp.yml` med præcise værktøjsversioner og offline-tests; endnu ikke brugt i et andet repository (MIL-007) ([vejledning til C og C++](QualityChecksCpp.da), [vejledning til C#](QualityChecksCSharp.da)) |
+| Kodemålinger og dækningsbadges | Implementeret og udgivet i 2.1.0 som det genbrugelige workflow `.gitea/workflows/code-metrics.yml` med en tæller, en Cobertura-læser, en SVG-renderer og offline-tests; afprøvet i et kasserepository, endnu ikke brugt i et projektrepository (MIL-010) ([vejledning](CodeMetrics.da)) |
 | Versioneret udgivelse og publicering | Udgivelsesproces, changelog og opgraderingsvejledning er defineret; udgivelsesworkflowet findes, og `v1.0.0` er udgivet (MIL-004) ([vejledning](Upgrading.da)) |

docs/wiki/Capabilities.md

@@ -13,6 +13,8 @@ Rows that say Implemented or Guides written exist today. The rest is planned and
 | Synchronize repository metadata (Gitea to GitHub mirror) | Implemented in `.gitea/scoped_workflows/`, with offline tests and a validation workflow |
 | Configure and validate workflow credentials | Implemented for the sync workflow: preflight checks both tokens before any change ([guide](Credentials)) |
 | Onboard a repository, manage runners, diagnose failures | Guides written ([onboarding](Onboarding), [troubleshooting](Troubleshooting)); scoped delivery to the repositories of all four organizations verified (MIL-002) |
-| Publish a repository wiki from `wiki/` (opt-in, delivered to every organization) | Implemented in `.gitea/scoped_workflows/publish-wiki.yml`, with offline tests; a pilot in a second repository publishes its wiki (MIL-006) |
+| Publish a repository wiki from `docs/wiki/` through a called workflow | Implemented as the reusable workflow `.gitea/workflows/publish-wiki-pages.yml`, with offline tests; called by every repository that publishes a wiki, and this repository's own wiki is in `docs/wiki/` (MIL-008, MIL-009) |
 | Shared quality checks (Python and shell) | Implemented as the reusable workflow `.gitea/workflows/quality-checks.yml`, with offline tests and a trial in a second organization; adopted in RepoFoundry ([guide](QualityChecksPythonShell)) |
+| Shared quality checks (C and C++, C#) | Implemented as the reusable workflows `.gitea/workflows/quality-checks-cpp.yml` and `.gitea/workflows/quality-checks-csharp.yml` with exact tool versions and offline tests; not yet used in another repository (MIL-007) ([C and C++ guide](QualityChecksCpp), [C# guide](QualityChecksCSharp)) |
+| Code metrics and coverage badges | Implemented and released in 2.1.0 as the reusable workflow `.gitea/workflows/code-metrics.yml` with a counter, a Cobertura reader, an SVG renderer and offline tests; tried in a throwaway repository, not yet used in a project repository (MIL-010) ([guide](CodeMetrics)) |
 | Versioned release and publishing | Release process, changelog and upgrade guide defined; the release workflow exists and `v1.0.0` is released (MIL-004) ([guide](Upgrading)) |

docs/wiki/Capabilities.ms.md

@@ -1,4 +1,4 @@
-<!-- translation of Capabilities.md, source sha256 a8c03a001880 -->
+<!-- translation of Capabilities.md, source sha256 3e3bcd9498f7 -->
 
 > Ini ialah terjemahan [`Capabilities`](Capabilities). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
 
@@ -13,6 +13,8 @@ Baris yang menyatakan Dilaksanakan atau Panduan telah ditulis wujud hari ini. Se
 | Menyegerakkan metadata repositori (Gitea ke cermin GitHub) | Dilaksanakan dalam `.gitea/scoped_workflows/`, dengan ujian luar talian dan aliran kerja pengesahan |
 | Mengkonfigur dan mengesahkan kelayakan (credentials) aliran kerja | Dilaksanakan untuk aliran kerja penyegerakan: semakan awal (preflight) memeriksa kedua-dua token sebelum sebarang perubahan ([panduan](Credentials.ms)) |
 | Menyertakan repositori, mengurus runner, mendiagnosis kegagalan | Panduan telah ditulis ([menyertakan repositori](Onboarding.ms), [diagnosis](Troubleshooting.ms)); penghantaran scoped ke repositori keempat-empat organisasi telah disahkan (MIL-002) |
-| Menerbitkan wiki repositori daripada `wiki/` (pilih menyertai, dihantar ke setiap organisasi) | Dilaksanakan dalam `.gitea/scoped_workflows/publish-wiki.yml`, dengan ujian luar talian; satu juruterbang dalam repositori kedua menerbitkan wikinya (MIL-006) |
+| Menerbitkan wiki repositori daripada `docs/wiki/` melalui aliran kerja yang dipanggil | Dilaksanakan sebagai aliran kerja boleh guna semula `.gitea/workflows/publish-wiki-pages.yml`, dengan ujian luar talian; dipanggil oleh setiap repositori yang menerbitkan wiki, dan wiki repositori ini sendiri ada dalam `docs/wiki/` (MIL-008, MIL-009) |
 | Semakan kualiti bersama (Python dan shell) | Dilaksanakan sebagai aliran kerja boleh guna semula `.gitea/workflows/quality-checks.yml`, dengan ujian luar talian dan percubaan dalam organisasi kedua; digunakan dalam RepoFoundry ([panduan](QualityChecksPythonShell.ms)) |
+| Semakan kualiti bersama (C dan C++, C#) | Dilaksanakan sebagai aliran kerja boleh guna semula `.gitea/workflows/quality-checks-cpp.yml` dan `.gitea/workflows/quality-checks-csharp.yml` dengan versi alat yang tepat dan ujian luar talian; belum digunakan dalam repositori lain (MIL-007) ([panduan C dan C++](QualityChecksCpp.ms), [panduan C#](QualityChecksCSharp.ms)) |
+| Metrik kod dan lencana liputan | Dilaksanakan dan diterbitkan dalam 2.1.0 sebagai aliran kerja boleh guna semula `.gitea/workflows/code-metrics.yml` dengan pengira, pembaca Cobertura, pemaparan SVG dan ujian luar talian; dicuba dalam repositori sekali pakai, belum digunakan dalam repositori projek (MIL-010) ([panduan](CodeMetrics.ms)) |
 | Keluaran berversi dan penerbitan | Proses keluaran, changelog dan panduan naik taraf telah ditakrifkan; aliran kerja keluaran sudah ada dan `v1.0.0` telah dikeluarkan (MIL-004) ([panduan](Upgrading.ms)) |

docs/wiki/CodeMetrics.da.md

@@ -0,0 +1,92 @@
+<!-- translation of CodeMetrics.md, source sha256 edfcb7cf99c9 -->
+
+> Dette er en oversættelse af [`CodeMetrics`](CodeMetrics). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
+
+[English](CodeMetrics) | Dansk | [Bahasa Melayu](CodeMetrics.ms)
+
+# Visning af kodemålinger og dækningsbadges
+
+Sådan kalder en softwareudvikler det fælles kodemålings-workflow og viser dets tre badges (kodefiler, kodelinjer og dækning) i en README. Workflowet tæller repositoryets kode, læser en dækningsrapport, som kalderen leverer, og committer tre SVG-filer til en `badges`-gren. Det kører ingen test og kræver ingen secret. Dets kontrakt er ADR-0010 i dette repository.
+
+## Kald af workflowet
+
+Workflowet kan ikke se filerne fra dit testjob, så testene kører i et job, du selv ejer, uploader Cobertura XML-rapporten som artefakt, og målingsjobbet kører bagefter:
+
+```yaml
+name: Code metrics
+
+on:
+  push:
+    branches: [ main ]
+
+jobs:
+  tests:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4.2.2
+      - run: python3 -m pip install pytest pytest-cov && python3 -m pytest --cov --cov-report=xml
+      - uses: actions/upload-artifact@v4.6.2
+        with:
+          name: coverage
+          path: coverage.xml
+
+  metrics:
+    needs: tests
+    permissions:
+      contents: write
+    uses: TirSystem/github-action/.gitea/workflows/code-metrics.yml@v1
+    with:
+      coverage-artifact: coverage
+      coverage-report: coverage.xml
+```
+
+| Input | Standard | Betydning |
+| --- | --- | --- |
+| `working-directory` | `.` | Mappe, relativt til repositoryets rod, hvis kode tælles |
+| `exclude` | tom | Kommasepareret liste af mønstre for filer og mapper, der ikke tælles, ud over standardudeladelserne; et mønster uden `/` matcher et navn overalt, et mønster med `/` matcher stien under `working-directory` |
+| `coverage-report` | tom | Cobertura XML-rapport: filen i artefaktet, når `coverage-artifact` er sat, ellers en sti i repositoryet; tom giver intet dækningsbadge |
+| `coverage-artifact` | tom | Navn på et artefakt, uploadet af et tidligere job i samme kørsel, der indeholder rapporten |
+| `coverage-warn` | `60` | Dækning i procent, under hvilken badget er rødt |
+| `coverage-good` | `80` | Dækning i procent, fra hvilken badget er grønt; derimellem er det gult |
+| `badges-branch` | `badges` | Gren, der indeholder badge-filerne; den oprettes, hvis den ikke findes |
+| `tools-ref` | `v1` | Tag eller gren i `TirSystem/github-action`, hvorfra scripts i `tools/` hentes |
+
+Reference workflowet ved major-tagget (`@v1`) eller ved et præcist tag, aldrig ved `main`. Et kald ved et præcist tag er kun fuldt fastlåst, når `tools-ref` navngiver samme tag. Se opgraderingsvejledningen. Start workflowet kun ved push til din standardgren: badge-committet har `[skip ci]` og laves med kørslens token, som ikke starter en ny kørsel, men en trigger på alle grene ville skrive ét commit pr. gren.
+
+## Hvad der tælles
+
+- En kodefil er en tekstfil med filendelsen for et understøttet sprog: Python, shell, PowerShell, C, C++, C#, Java, JavaScript, TypeScript, Go, Rust og SQL. Markdown, YAML, JSON, XML, HTML og CSS er ikke kodefiler.
+- Hver linje er præcis én af: tom (kun blanktegn), kommentar (kun kommentartekst) eller kode (alt andet, også en linje med kode og en afsluttende kommentar). Badget viser kun kodelinjerne.
+- En kommentarmarkør i en streng er ikke en kommentar, og en Python-docstring er en streng og tæller derfor som kode.
+- Mapper, der starter med punktum, og `node_modules`, `vendor`, `third_party`, `dist`, `build`, `out`, `bin`, `obj`, `target`, `venv`, `__pycache__` og `shared-scripts` tælles ikke. Genereret kode udelades med `exclude`.
+- Rå og ordrette strenge, der afviger fra en almindelig streng (Rust `r#"..."#`, C# `@"..."`, C++-rå strenge), kan tælles forkert. Tallene afviger lidt fra andre værktøjer; reglerne er de samme ved hver kørsel.
+
+## Dækningsbadget
+
+Rapporten er en Cobertura XML-fil, som `coverage.py` (`coverage xml`), `gcovr` (`--cobertura`) og `coverlet` (formatet `cobertura`) skriver. Badget viser `lines-covered` over `lines-valid`, afrundet til hele procent, og farven følger de to grænser. En rapport, der ikke findes, ikke er velformet Cobertura XML eller ikke har gyldige linjer, får kørslen til at fejle med filen nævnt; dækningsbadget skrives aldrig som `0%` for en dårlig rapport. Uden `coverage-report` består kørslen med en note og uden dækningsbadge.
+
+## Visning af badges
+
+Tilføj billederne til README med grenens rå URL'er:
+
+```markdown
+![code files](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/code-files.svg)
+![lines of code](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/code-lines.svg)
+![coverage](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/coverage.svg)
+```
+
+På GitHub-spejlet bruges `https://raw.githubusercontent.com/OWNER/REPO/badges/code-files.svg`; push-spejlet kopierer grenen. `badges`-grenen indeholder også `code-metrics.json` med tallene pr. sprog. Instansen cacher en rå fil i op til seks timer, så et ændret badge kan vise det gamle tal et stykke tid dér; spejlet cacher i fem minutter. Et privat repository viser ikke badges for en læser, der ikke er logget ind.
+
+## Når workflowet fejler
+
+| Meddelelse | Årsag | Løsning |
+| --- | --- | --- |
+| `[configuration] working-directory must be a relative path inside the repository.` | En absolut sti eller `..` | Brug en sti inde i repositoryet |
+| `[configuration] coverage-report '<x>' does not exist.` | Rapporten blev ikke frembragt, eller artefaktnavnet eller stien er forkert | Tjek testjobbet og artefaktnavnet; stien er inde i artefaktet |
+| `[configuration] coverage-report '<x>' is not well-formed XML` eller `is not a Cobertura report` | Filen har et andet format | Skriv Cobertura XML (`coverage xml`, `gcovr --cobertura`) |
+| `[configuration] coverage-report '<x>' has no valid lines.` | Testene kørte ingen målt kode | Tjek dækningskonfigurationen |
+| `[configuration] coverage-artifact '<x>' needs coverage-report` | Artefaktet er navngivet, men ikke filen i det | Sæt `coverage-report` |
+| `[configuration] coverage-warn ... is above coverage-good` eller `is not a number from 0 to 100` | En grænse er ugyldig | Ret inputtet |
+| `[configuration] badges-branch '<x>' must not be a default branch` eller `holds files that are not badge files` | Grenen hedder `main`, `master` eller har andet indhold | Brug en gren, der kun indeholder badges |
+| `the push to '<x>' failed twice` | En anden kørsel skrev grenen samtidig, eller tokenet kan ikke skrive | Kør igen; tjek at jobbet har `contents: write` |
+| Download-trinnet fejler | Artefaktet findes ikke i denne kørsel, eller jobbet kører ikke efter testjobbet | Tilføj `needs:` og tjek artefaktnavnet |

docs/wiki/CodeMetrics.md

@@ -0,0 +1,123 @@
+<!-- Generated from guides/code-metrics.md by tools/build_wiki.py. Edit the source, not this page. -->
+
+> This page is generated from [`guides/code-metrics.md`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/code-metrics.md). Changes made here are overwritten the next time the wiki is published.
+
+English | [Dansk](CodeMetrics.da) | [Bahasa Melayu](CodeMetrics.ms)
+
+# Showing code metrics and coverage badges
+
+How a software engineer calls the shared code-metrics workflow and shows its
+three badges (code files, lines of code and coverage) in a README. The workflow
+counts the code of the repository, reads a coverage report that the caller
+supplies and commits three SVG files to a `badges` branch. It runs no test and
+needs no secret. Its contract is ADR-0010 in this repository.
+
+## Calling the workflow
+
+The workflow cannot see the files of your test job, so the tests run in a job of
+your own, upload the Cobertura XML report as an artifact, and the metrics job
+runs after it:
+
+```yaml
+name: Code metrics
+
+on:
+  push:
+    branches: [ main ]
+
+jobs:
+  tests:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4.2.2
+      - run: python3 -m pip install pytest pytest-cov && python3 -m pytest --cov --cov-report=xml
+      - uses: actions/upload-artifact@v4.6.2
+        with:
+          name: coverage
+          path: coverage.xml
+
+  metrics:
+    needs: tests
+    permissions:
+      contents: write
+    uses: TirSystem/github-action/.gitea/workflows/code-metrics.yml@v1
+    with:
+      coverage-artifact: coverage
+      coverage-report: coverage.xml
+```
+
+| Input | Default | Meaning |
+| --- | --- | --- |
+| `working-directory` | `.` | Directory, relative to the repository root, whose code is counted |
+| `exclude` | empty | Comma list of patterns of files and directories that are not counted, in addition to the defaults; a pattern without `/` matches a name anywhere, a pattern with `/` matches the path below `working-directory` |
+| `coverage-report` | empty | Cobertura XML report: the file inside the artifact when `coverage-artifact` is set, otherwise a path in the repository; empty writes no coverage badge |
+| `coverage-artifact` | empty | Name of an artifact, uploaded by an earlier job of the same run, that holds the report |
+| `coverage-warn` | `60` | Coverage in percent below which the badge is red |
+| `coverage-good` | `80` | Coverage in percent from which the badge is green; in between it is yellow |
+| `badges-branch` | `badges` | Branch that holds the badge files; it is created when it does not exist |
+| `tools-ref` | `v1` | Tag or branch of `TirSystem/github-action` from which the scripts in `tools/` are fetched |
+
+Reference the workflow at the major tag (`@v1`) or at an exact tag, never at
+`main`. A call at an exact tag is pinned completely only when `tools-ref` names
+the same tag. See the upgrade guide. Start the workflow on pushes to your
+default branch only: the badge commit carries `[skip ci]` and is made with the
+token of the run, which does not start another run, but a trigger on every
+branch would write one commit per branch.
+
+## What is counted
+
+- A code file is a text file with the extension of a supported language:
+  Python, shell, PowerShell, C, C++, C#, Java, JavaScript, TypeScript, Go, Rust
+  and SQL. Markdown, YAML, JSON, XML, HTML and CSS are not code files.
+- Every line is exactly one of blank (only white space), comment (only comment
+  text) or code (everything else, including a line with code and a trailing
+  comment). The badge shows the lines of code only.
+- A comment marker inside a string is not a comment, and a Python docstring is a
+  string, so it counts as code.
+- Directories that start with a dot and `node_modules`, `vendor`, `third_party`,
+  `dist`, `build`, `out`, `bin`, `obj`, `target`, `venv`, `__pycache__` and
+  `shared-scripts` are not counted. Generated code is excluded with `exclude`.
+- Raw and verbatim strings that differ from an ordinary string (Rust `r#"..."#`,
+  C# `@"..."`, C++ raw strings) can be counted wrongly. The counts will differ
+  a little from other tools; the rules are the same on every run.
+
+## The coverage badge
+
+The report is a Cobertura XML file, which `coverage.py` (`coverage xml`),
+`gcovr` (`--cobertura`) and `coverlet` (`cobertura` format) write. The badge
+shows `lines-covered` over `lines-valid`, rounded to a whole percent, and its
+colour follows the two thresholds. A report that does not exist, is not
+well-formed Cobertura XML or has no valid lines fails the run with the file
+named; the coverage badge is never written as `0%` for a bad report. Without
+`coverage-report` the run passes with a notice and no coverage badge.
+
+## Showing the badges
+
+Add the images to the README with the raw URLs of the branch:
+
+```markdown
+![code files](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/code-files.svg)
+![lines of code](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/code-lines.svg)
+![coverage](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/coverage.svg)
+```
+
+On the GitHub mirror use `https://raw.githubusercontent.com/OWNER/REPO/badges/code-files.svg`;
+the push mirror copies the branch. The `badges` branch also holds
+`code-metrics.json` with the numbers per language. The instance caches a raw
+file for up to six hours, so a changed badge can show the old number for a
+while there; the mirror caches for five minutes. A private repository does not
+show the badges to a reader who is not signed in.
+
+## When the workflow fails
+
+| Message | Cause | Fix |
+| --- | --- | --- |
+| `[configuration] working-directory must be a relative path inside the repository.` | An absolute path or `..` | Use a path inside the repository |
+| `[configuration] coverage-report '<x>' does not exist.` | The report was not produced, or the artifact name or path is wrong | Check the test job and the artifact name; the path is inside the artifact |
+| `[configuration] coverage-report '<x>' is not well-formed XML` or `is not a Cobertura report` | The file is another format | Write Cobertura XML (`coverage xml`, `gcovr --cobertura`) |
+| `[configuration] coverage-report '<x>' has no valid lines.` | The tests ran no measured code | Check the coverage configuration |
+| `[configuration] coverage-artifact '<x>' needs coverage-report` | The artifact is named but not the file in it | Set `coverage-report` |
+| `[configuration] coverage-warn ... is above coverage-good` or `is not a number from 0 to 100` | A threshold is invalid | Correct the input |
+| `[configuration] badges-branch '<x>' must not be a default branch` or `holds files that are not badge files` | The branch name is `main`, `master` or a branch with other content | Use a branch that holds only the badges |
+| `the push to '<x>' failed twice` | Another run wrote the branch at the same time, or the token cannot write | Re-run; check that the job has `contents: write` |
+| The download step fails | The artifact does not exist in this run, or the job does not run after the test job | Add `needs:` and check the artifact name |

docs/wiki/CodeMetrics.ms.md

@@ -0,0 +1,92 @@
+<!-- translation of CodeMetrics.md, source sha256 edfcb7cf99c9 -->
+
+> Ini ialah terjemahan [`CodeMetrics`](CodeMetrics). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
+
+[English](CodeMetrics) | [Dansk](CodeMetrics.da) | Bahasa Melayu
+
+# Menunjukkan metrik kod dan lencana liputan
+
+Cara seorang jurutera perisian memanggil aliran kerja metrik kod bersama dan menunjukkan tiga lencananya (fail kod, baris kod dan liputan) dalam README. Aliran kerja ini mengira kod repositori, membaca laporan liputan yang dibekalkan oleh pemanggil dan melakukan commit tiga fail SVG ke cabang `badges`. Ia tidak menjalankan sebarang ujian dan tidak memerlukan secret. Kontraknya ialah ADR-0010 dalam repositori ini.
+
+## Memanggil aliran kerja
+
+Aliran kerja tidak dapat melihat fail daripada kerja ujian anda, jadi ujian dijalankan dalam kerja anda sendiri, memuat naik laporan Cobertura XML sebagai artifak, dan kerja metrik dijalankan selepasnya:
+
+```yaml
+name: Code metrics
+
+on:
+  push:
+    branches: [ main ]
+
+jobs:
+  tests:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4.2.2
+      - run: python3 -m pip install pytest pytest-cov && python3 -m pytest --cov --cov-report=xml
+      - uses: actions/upload-artifact@v4.6.2
+        with:
+          name: coverage
+          path: coverage.xml
+
+  metrics:
+    needs: tests
+    permissions:
+      contents: write
+    uses: TirSystem/github-action/.gitea/workflows/code-metrics.yml@v1
+    with:
+      coverage-artifact: coverage
+      coverage-report: coverage.xml
+```
+
+| Input | Lalai | Maksud |
+| --- | --- | --- |
+| `working-directory` | `.` | Direktori, relatif kepada akar repositori, yang kodnya dikira |
+| `exclude` | kosong | Senarai corak fail dan direktori yang tidak dikira, dipisahkan koma, sebagai tambahan kepada pengecualian lalai; corak tanpa `/` sepadan dengan nama di mana-mana, corak dengan `/` sepadan dengan laluan di bawah `working-directory` |
+| `coverage-report` | kosong | Laporan Cobertura XML: fail dalam artifak apabila `coverage-artifact` ditetapkan, jika tidak laluan dalam repositori; kosong bermakna tiada lencana liputan |
+| `coverage-artifact` | kosong | Nama artifak, dimuat naik oleh kerja yang lebih awal dalam larian yang sama, yang memegang laporan |
+| `coverage-warn` | `60` | Liputan dalam peratus di bawahnya lencana berwarna merah |
+| `coverage-good` | `80` | Liputan dalam peratus yang bermulanya lencana berwarna hijau; di antaranya kuning |
+| `badges-branch` | `badges` | Cabang yang memegang fail lencana; ia dicipta jika tidak wujud |
+| `tools-ref` | `v1` | Tag atau cabang `TirSystem/github-action` tempat skrip dalam `tools/` diambil |
+
+Rujuk aliran kerja pada tag major (`@v1`) atau pada tag tepat, jangan sekali-kali pada `main`. Panggilan pada tag tepat hanya tersemat sepenuhnya apabila `tools-ref` menamakan tag yang sama. Lihat panduan menaik taraf. Mulakan aliran kerja pada push ke cabang lalai anda sahaja: commit lencana membawa `[skip ci]` dan dibuat dengan token larian, yang tidak memulakan larian lain, tetapi pencetus pada setiap cabang akan menulis satu commit bagi setiap cabang.
+
+## Apa yang dikira
+
+- Fail kod ialah fail teks dengan sambungan bagi bahasa yang disokong: Python, shell, PowerShell, C, C++, C#, Java, JavaScript, TypeScript, Go, Rust dan SQL. Markdown, YAML, JSON, XML, HTML dan CSS bukan fail kod.
+- Setiap baris tepat satu daripada: kosong (hanya ruang putih), komen (hanya teks komen) atau kod (selebihnya, termasuk baris dengan kod dan komen di hujung). Lencana hanya menunjukkan baris kod.
+- Penanda komen dalam rentetan bukan komen, dan docstring Python ialah rentetan jadi dikira sebagai kod.
+- Direktori yang bermula dengan titik, serta `node_modules`, `vendor`, `third_party`, `dist`, `build`, `out`, `bin`, `obj`, `target`, `venv`, `__pycache__` dan `shared-scripts` tidak dikira. Kod yang dijana dikecualikan dengan `exclude`.
+- Rentetan mentah dan verbatim yang berbeza daripada rentetan biasa (Rust `r#"..."#`, C# `@"..."`, rentetan mentah C++) boleh dikira dengan salah. Angka sedikit berbeza daripada alat lain; peraturannya sama pada setiap larian.
+
+## Lencana liputan
+
+Laporan ialah fail Cobertura XML, yang ditulis oleh `coverage.py` (`coverage xml`), `gcovr` (`--cobertura`) dan `coverlet` (format `cobertura`). Lencana menunjukkan `lines-covered` berbanding `lines-valid`, dibundarkan kepada peratus penuh, dan warnanya mengikut dua ambang. Laporan yang tidak wujud, bukan Cobertura XML yang terbentuk dengan baik atau tidak mempunyai baris sah menyebabkan larian gagal dengan nama fail disebut; lencana liputan tidak pernah ditulis sebagai `0%` bagi laporan yang rosak. Tanpa `coverage-report` larian lulus dengan notis dan tanpa lencana liputan.
+
+## Menunjukkan lencana
+
+Tambahkan imej ke README dengan URL mentah cabang:
+
+```markdown
+![code files](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/code-files.svg)
+![lines of code](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/code-lines.svg)
+![coverage](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/coverage.svg)
+```
+
+Pada cermin GitHub gunakan `https://raw.githubusercontent.com/OWNER/REPO/badges/code-files.svg`; cermin push menyalin cabang itu. Cabang `badges` juga memegang `code-metrics.json` dengan angka bagi setiap bahasa. Instans menyimpan fail mentah dalam cache sehingga enam jam, jadi lencana yang berubah mungkin menunjukkan angka lama seketika di sana; cermin menyimpannya lima minit. Repositori persendirian tidak menunjukkan lencana kepada pembaca yang belum log masuk.
+
+## Apabila aliran kerja gagal
+
+| Mesej | Punca | Pembetulan |
+| --- | --- | --- |
+| `[configuration] working-directory must be a relative path inside the repository.` | Laluan mutlak atau `..` | Gunakan laluan di dalam repositori |
+| `[configuration] coverage-report '<x>' does not exist.` | Laporan tidak dihasilkan, atau nama artifak atau laluan salah | Semak kerja ujian dan nama artifak; laluan berada di dalam artifak |
+| `[configuration] coverage-report '<x>' is not well-formed XML` atau `is not a Cobertura report` | Fail itu berformat lain | Tulis Cobertura XML (`coverage xml`, `gcovr --cobertura`) |
+| `[configuration] coverage-report '<x>' has no valid lines.` | Ujian tidak menjalankan kod yang diukur | Semak konfigurasi liputan |
+| `[configuration] coverage-artifact '<x>' needs coverage-report` | Artifak dinamakan tetapi bukan fail di dalamnya | Tetapkan `coverage-report` |
+| `[configuration] coverage-warn ... is above coverage-good` atau `is not a number from 0 to 100` | Ambang tidak sah | Betulkan input |
+| `[configuration] badges-branch '<x>' must not be a default branch` atau `holds files that are not badge files` | Nama cabang ialah `main`, `master` atau cabang dengan kandungan lain | Gunakan cabang yang hanya memegang lencana |
+| `the push to '<x>' failed twice` | Larian lain menulis cabang pada masa yang sama, atau token tidak boleh menulis | Jalankan semula; semak bahawa kerja mempunyai `contents: write` |
+| Langkah muat turun gagal | Artifak tidak wujud dalam larian ini, atau kerja tidak berjalan selepas kerja ujian | Tambah `needs:` dan semak nama artifak |

docs/wiki/Credentials.da.md

@@ -1,4 +1,4 @@
-<!-- translation of Credentials.md, source sha256 10a051e910de -->
+<!-- translation of Credentials.md, source sha256 cba8a44e1152 -->
 
 > Dette er en oversættelse af [`Credentials`](Credentials). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
 
@@ -56,17 +56,17 @@ Ved succes står der i loggen `Preflight passed: Gitea and GitHub accepted the c
 
 ## Secret til publicering af wiki
 
-Workflowet **Publish wiki** kopierer `wiki/` til Gitea-wikien i et repository, der har meldt sig til med `wiki/.publish` (se [onboarding.md](Onboarding.da)). Det bruger sin egen secret, så synkroniseringstokenet forbliver skrivebeskyttet.
+Workflowet **Publish wiki pages** kopierer `docs/wiki/` til Gitea-wikien i et repository, der kalder det (se [onboarding.md](Onboarding.da)). Det bruger sin egen secret, så synkroniseringstokenet forbliver skrivebeskyttet. Kalderen sender secreten i `secrets:`; den nedarves ikke.
 
 | Secret | Indhold | Bruges til |
 | --- | --- | --- |
 | `TOKEN_FOR_GITEA_WIKI` | Gitea-tokenet, intet andet | At skrive wikisiderne for de repositories i en organisation, der melder sig til |
 
-- Gem den som en secret i organisationen for hvert repository, der publicerer. Der er ingen reserve til `TOKEN_FOR_GITEA`: et repository, der har meldt sig til og ikke har secreten, fejler med en konfigurationsfejl, og et repository, der ikke har meldt sig til, behøver den ikke.
+- Gem den som en secret i organisationen for hvert repository, der publicerer. Der er ingen reserve til `TOKEN_FOR_GITEA`: et repository, der kalder workflowet og ikke har secreten, fejler med en konfigurationsfejl, og et repository, der ikke kalder det, behøver den ikke.
 - Tokenet skal have scope `write:repository`, og dets bruger skal have skriveadgang til repositories. Gitea har intet scope kun til wikien, så opret tokenet til en dedikeret bruger. S05 godkender scopet, og S03 gemmer secreten.
-- Kald, der foretages: `GET /repos/{owner}/{repo}`, `GET /repos/{owner}/{repo}/wiki/pages`, `GET`, `POST` og `PATCH /repos/{owner}/{repo}/wiki/...` og, for en side, der ikke længere findes i `wiki/`, `DELETE /repos/{owner}/{repo}/wiki/page/{name}`.
+- Kald, der foretages: `GET /repos/{owner}/{repo}`, `GET /repos/{owner}/{repo}/wiki/pages`, `GET`, `POST` og `PATCH /repos/{owner}/{repo}/wiki/...` og, for en side, der ikke længere findes i `docs/wiki/`, `DELETE /repos/{owner}/{repo}/wiki/page/{name}`.
 - Wikien skal være aktiveret i repositoryets indstillinger. Workflowet nægter at køre, hvis den ikke er det.
-- Sider, der findes i `wiki/`, overskrives altid fra den, så en ændring i Gitea's weboverflade går tabt ved næste publicering. Sider, der kun findes i wikien, fjernes kun, når `wiki/.publish` indeholder ordet `prune`.
+- Sider, der findes i `docs/wiki/`, overskrives altid fra den, så en ændring i Gitea's weboverflade går tabt ved næste publicering. Sider, der kun findes i wikien, fjernes kun, når kaldet sætter `prune: "true"`.
 
 ## Udskiftning af et token
 

docs/wiki/Credentials.md

@@ -88,29 +88,30 @@ is ever printed.
 
 ## Wiki publishing secret
 
-The workflow **Publish wiki** copies `wiki/` to the Gitea wiki of a repository
-that has opted in with `wiki/.publish` (see [onboarding.md](Onboarding)). It
-uses its own secret, so the metadata sync token stays read-only.
+The workflow **Publish wiki pages** copies `docs/wiki/` to the Gitea wiki of a
+repository that calls it (see [onboarding.md](Onboarding)). It uses its own
+secret, so the metadata sync token stays read-only. The caller passes the
+secret in `secrets:`; it is not inherited.
 
 | Secret | Content | Used for |
 | --- | --- | --- |
 | `TOKEN_FOR_GITEA_WIKI` | The Gitea token, nothing else | Writing the wiki pages of the repositories of an organization that opt in |
 
 - Store it as a secret of the organization of each repository that publishes.
-  There is no fallback to `TOKEN_FOR_GITEA`: a repository that opted in and has
-  no such secret fails with a configuration error, and a repository that did
-  not opt in does not need it.
+  There is no fallback to `TOKEN_FOR_GITEA`: a repository that calls the
+  workflow and has no such secret fails with a configuration error, and a
+  repository that does not call it does not need it.
 - The token needs scope `write:repository`, and its user needs write access to
   the repositories. Gitea has no wiki-only scope, so create the token for a
   dedicated user. S05 approves the scope and S03 stores the secret.
 - Calls made: `GET /repos/{owner}/{repo}`, `GET /repos/{owner}/{repo}/wiki/pages`,
   `GET`, `POST` and `PATCH /repos/{owner}/{repo}/wiki/...` and, for a page that
-  no longer exists in `wiki/`, `DELETE /repos/{owner}/{repo}/wiki/page/{name}`.
+  no longer exists in `docs/wiki/`, `DELETE /repos/{owner}/{repo}/wiki/page/{name}`.
 - The wiki must be enabled in the repository settings. The workflow refuses to
   run when it is not.
-- Pages that are in `wiki/` are always overwritten from it, so a change made
-  in the Gitea web UI is lost on the next publish. Pages that are only in the
-  wiki are removed only when `wiki/.publish` contains the word `prune`.
+- Pages that are in `docs/wiki/` are always overwritten from it, so a change
+  made in the Gitea web UI is lost on the next publish. Pages that are only in
+  the wiki are removed only when the call sets `prune: "true"`.
 
 ## Rotating a token
 

docs/wiki/Credentials.ms.md

@@ -1,4 +1,4 @@
-<!-- translation of Credentials.md, source sha256 10a051e910de -->
+<!-- translation of Credentials.md, source sha256 cba8a44e1152 -->
 
 > Ini ialah terjemahan [`Credentials`](Credentials). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
 
@@ -56,17 +56,17 @@ Apabila berjaya, log menyatakan `Preflight passed: Gitea and GitHub accepted the
 
 ## Secret untuk menerbitkan wiki
 
-Aliran kerja **Publish wiki** menyalin `wiki/` ke wiki Gitea bagi repositori yang telah memilih menyertainya dengan `wiki/.publish` (lihat [onboarding.md](Onboarding.ms)). Ia menggunakan secret sendiri, supaya token penyegerakan metadata kekal baca sahaja.
+Aliran kerja **Publish wiki pages** menyalin `docs/wiki/` ke wiki Gitea bagi repositori yang memanggilnya (lihat [onboarding.md](Onboarding.ms)). Ia menggunakan secret sendiri, supaya token penyegerakan metadata kekal baca sahaja. Pemanggil menghantar secret dalam `secrets:`; ia tidak diwarisi.
 
 | Secret | Kandungan | Digunakan untuk |
 | --- | --- | --- |
 | `TOKEN_FOR_GITEA_WIKI` | Token Gitea, tiada yang lain | Menulis halaman wiki bagi repositori dalam organisasi yang memilih menyertainya |
 
-- Simpan sebagai secret organisasi bagi setiap repositori yang menerbitkan. Tiada sandaran kepada `TOKEN_FOR_GITEA`: repositori yang telah memilih menyertainya dan tidak mempunyai secret itu gagal dengan ralat konfigurasi, dan repositori yang tidak memilih tidak memerlukannya.
+- Simpan sebagai secret organisasi bagi setiap repositori yang menerbitkan. Tiada sandaran kepada `TOKEN_FOR_GITEA`: repositori yang memanggil aliran kerja dan tidak mempunyai secret itu gagal dengan ralat konfigurasi, dan repositori yang tidak memanggilnya tidak memerlukannya.
 - Token mesti mempunyai skop `write:repository`, dan penggunanya mesti mempunyai akses tulis kepada repositori. Gitea tidak mempunyai skop untuk wiki sahaja, jadi cipta token untuk pengguna khusus. S05 meluluskan skop dan S03 menyimpan secret.
-- Panggilan yang dibuat: `GET /repos/{owner}/{repo}`, `GET /repos/{owner}/{repo}/wiki/pages`, `GET`, `POST` dan `PATCH /repos/{owner}/{repo}/wiki/...` dan, bagi halaman yang tidak lagi wujud dalam `wiki/`, `DELETE /repos/{owner}/{repo}/wiki/page/{name}`.
+- Panggilan yang dibuat: `GET /repos/{owner}/{repo}`, `GET /repos/{owner}/{repo}/wiki/pages`, `GET`, `POST` dan `PATCH /repos/{owner}/{repo}/wiki/...` dan, bagi halaman yang tidak lagi wujud dalam `docs/wiki/`, `DELETE /repos/{owner}/{repo}/wiki/page/{name}`.
 - Wiki mesti diaktifkan dalam tetapan repositori. Aliran kerja enggan berjalan jika ia tidak diaktifkan.
-- Halaman yang ada dalam `wiki/` sentiasa ditimpa daripadanya, jadi perubahan yang dibuat dalam antara muka web Gitea hilang pada penerbitan seterusnya. Halaman yang hanya ada dalam wiki dibuang hanya apabila `wiki/.publish` mengandungi perkataan `prune`.
+- Halaman yang ada dalam `docs/wiki/` sentiasa ditimpa daripadanya, jadi perubahan yang dibuat dalam antara muka web Gitea hilang pada penerbitan seterusnya. Halaman yang hanya ada dalam wiki dibuang hanya apabila panggilan menetapkan `prune: "true"`.
 
 ## Menukar token
 

docs/wiki/Home.da.md

@@ -0,0 +1,535 @@
+<!-- translation of Home.md, source sha256 810981fb9bc8 -->
+
+> Dette er en oversættelse af [`Home`](Home). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
+
+[English](Home) | Dansk | [Bahasa Melayu](Home.ms)
+
+# TirSystem GitHub Actions
+
+En samling af genbrugelige Gitea Actions-workflows til DevOps-professionelle og softwareudviklere, der arbejder på TirSystem-projekter.
+
+
+## Oversigt
+
+Dette repository er den centrale samling af genbrugelig automatisering til TirSystems repositories. Det primære repository ligger på `git.tirsystem.com` (Gitea) og spejles med push til GitHub.
+
+Det indeholder ti workflows: synkronisering af metadata til GitHub-spejlet, publicering af wiki (kaldt af hvert repository), fælles kvalitetskontrol for Python og shell, for C og C++ og for C#, kodemålinger og dækningsbadges, et udgivelsesworkflow, publicering af accepterede milepæle og repositoryets egen validering. De er listet med formål og diagram under [Workflows](#workflows).
+
+
+## Workflows
+
+Der er ti workflows i dette repository. Et **scoped** workflow leveres af instansen til alle repositories i TirSystem-organisationerne og kræver intet i repositoryet; et **genbrugeligt** workflow kaldes fra et repository med `uses:`; de øvrige kører kun her. Diagrammerne er PlantUML-kildekode og er på engelsk.
+
+| Workflow | Fil | Type | Starter ved | Formål |
+| --- | --- | --- | --- | --- |
+| Sync GitHub mirror metadata | [`sync-github-metadata.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push til `main`, manuelt, dagligt kl. 03:17 UTC | Kopierer beskrivelsen og emnerne for et Gitea-repository til dets GitHub push-spejl |
+| Publish wiki pages | [`publish-wiki-pages.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/publish-wiki-pages.yml) | Genbrugeligt (`workflow_call`) | et kald fra et andet repository | Publicerer siderne i `docs/wiki/` (eller den mappe, `wiki_dir` angiver) til wikien i det kaldende repository |
+| Quality checks | [`quality-checks.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks.yml) | Genbrugeligt (`workflow_call`) | et kald fra et andet repository | Kører ruff, mypy, shellcheck og shfmt på de sporede filer og ændrer intet |
+| Quality checks C++ | [`quality-checks-cpp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-cpp.yml) | Genbrugeligt (`workflow_call`) | et kald fra et andet repository | Kører clang-format og clang-tidy i præcise versioner på de sporede C- og C++-filer og ændrer intet |
+| Quality checks C# | [`quality-checks-csharp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-csharp.yml) | Genbrugeligt (`workflow_call`) | et kald fra et andet repository | Kører `dotnet format` og `dotnet build` på et præcist .NET SDK 10 eller nyere og ændrer intet |
+| Code metrics | [`code-metrics.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/code-metrics.yml) | Genbrugeligt (`workflow_call`) | et kald fra et andet repository | Tæller kodefilerne og kodelinjerne (uden kommentar- og tomme linjer), læser en Cobertura-dækningsrapport og committer tre SVG-badges til en `badges`-gren |
+| Publish own wiki | [`publish-own-wiki.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/publish-own-wiki.yml) | Kun dette repository | push til `main`, der ændrer `docs/wiki/**`, manuelt | Kalder det genbrugelige workflow Publish wiki pages for dette repositorys wiki |
+| Release | [`release.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/release.yml) | Kun dette repository | manuelt | Opretter versionstagget, udgivelsessiden og major-tagget efter kontrollerne |
+| Publicering af accepterede milepæle | [`sync-milestones.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/sync-milestones.yml) | Kun dette repository | push til `main`, der ændrer `docs/milestones/**` eller `docs/sqa/reviews/**`, manuelt (tørkørsel som standard) | Opretter eller opdaterer Gitea-milepælen og issues for hver milepæl, der er Accepted med en Go-gennemgang |
+| Validate workflows | [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml) | Kun dette repository | pull request, push til `main`, manuelt | Læser hvert workflow som YAML og kører offline-testene |
+
+### Synkronisering af GitHub-metadata
+
+Synkroniserer Gitea-repositoryets beskrivelse og emner til GitHub push-spejlet.
+
+#### Tidsplan (cron)
+
+Dagligt kl. 03:17 UTC (`17 3 * * *`) samt ved hvert push til `main` og manuel `workflow_dispatch`.
+
+#### Workflow
+
+```plantuml
+@startuml
+title Sync Gitea repository description and topics to GitHub
+
+autonumber
+
+actor "Push to main,\nmanual trigger, or schedule" as Trigger
+participant "Gitea Actions\nsync-github-metadata" as Workflow
+participant "Gitea REST API" as Gitea
+participant "GitHub REST API" as GitHub
+
+Trigger -> Workflow: Start workflow
+activate Workflow
+
+Workflow -> Workflow: Read and validate secrets
+note right
+TOKEN_FOR_GITEA
+PAT_FOR_GITHUB
+end note
+
+alt secret validation failed
+  Workflow --> Trigger: workflow failed
+end
+
+
+Workflow -> Gitea: GET /repos/{owner}/{repo}
+Gitea --> Workflow: Description and topics
+
+Workflow -> Gitea: GET /repos/{owner}/{repo}/push_mirrors
+Gitea --> Workflow: Push mirror response
+
+alt mirrors is not a list
+    Workflow --> Trigger: Log a warning and succeed\n(GitHub metadata not synced)
+else mirrors is a list with no GitHub mirror
+    Workflow --> Trigger: Log that there is nothing to sync and succeed
+else mirrors is a list
+    Workflow -> Workflow: Find GitHub owner and repo from remote_address
+
+    Workflow -> GitHub: PATCH /repos/{owner}/{repo}\n{description}
+    GitHub --> Workflow: Repository updated
+
+    Workflow -> GitHub: PUT /repos/{owner}/{repo}/topics\n{names}
+    GitHub --> Workflow: Topics updated
+
+    Workflow --> Trigger: Sync completed
+else Gitea API denies access
+    Gitea --> Workflow: HTTP 403 Forbidden
+    Workflow --> Trigger: Workflow fails
+else GitHub API denies access
+    GitHub --> Workflow: HTTP error
+    Workflow --> Trigger: Workflow fails
+end
+deactivate Workflow
+@enduml
+```
+
+### Kvalitetskontrol
+
+Et genbrugeligt workflow til Python og shell, kaldt med `uses: TirSystem/github-action/.gitea/workflows/quality-checks.yml@v1` (se [vejledningen](QualityChecksPythonShell)).
+
+#### Workflow
+
+```plantuml
+@startuml
+title Shared quality checks (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks" as Workflow
+participant "PyPI" as PyPI
+
+Caller -> Workflow: workflow_call with languages,\nworking-directory and tool versions
+activate Workflow
+
+Workflow -> Workflow: Validate the inputs
+alt languages or working-directory is invalid
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> Workflow: Check out the calling repository
+Workflow -> PyPI: Install the pinned tools in a virtual environment\n(ruff, mypy, shellcheck-py, shfmt-py as selected)
+PyPI --> Workflow: Tools installed
+
+loop for each selected language
+  Workflow -> Workflow: List tracked files
+  alt no files of that language
+    Workflow -> Workflow: Notice: nothing was checked
+  else
+    Workflow -> Workflow: Run every tool and record PASS or FAIL
+  end
+end
+
+alt any tool failed
+  Workflow --> Caller: Fail and list the failed tools
+else
+  Workflow --> Caller: All selected checks passed
+end
+deactivate Workflow
+@enduml
+```
+
+### Kvalitetskontrol C++
+
+Et genbrugeligt workflow til C og C++, kaldt med `uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1` (ADR-0008). Repositoryet skal have en `.clang-format`; en `.clang-tidy` og en compile-database er valgfrie.
+
+#### Workflow
+
+```plantuml
+@startuml
+title Shared quality checks for C and C++ (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks-cpp.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks-cpp" as Workflow
+participant "PyPI" as PyPI
+
+Caller -> Workflow: workflow_call with working-directory, std,\ncompile-commands-dir and tool versions
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared script
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid or a version is not exact
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> PyPI: Install clang-format and clang-tidy at the exact versions
+PyPI --> Workflow: Tools installed
+
+alt no C or C++ file is tracked
+  Workflow --> Caller: Notice: nothing was checked, pass
+else no .clang-format, or compile-commands-dir\nwithout compile_commands.json
+  Workflow --> Caller: Fail with [configuration]
+else
+  Workflow -> Workflow: clang-format --dry-run -Werror on all files
+  Workflow -> Workflow: clang-tidy on the C++ files (-std=std)\nand on the C files (or with the compile database)
+  alt any tool failed
+    Workflow --> Caller: Fail with tool, file and line in the log
+  else
+    Workflow --> Caller: All selected checks passed
+  end
+end
+deactivate Workflow
+@enduml
+```
+
+### Kvalitetskontrol C#
+
+Et genbrugeligt workflow til C#, kaldt med `uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1` (ADR-0008). Det installerer det præcise .NET SDK, som `dotnet-sdk-version` angiver (10 eller nyere), og skal bruge netværket til pakkegendannelsen.
+
+#### Workflow
+
+```plantuml
+@startuml
+title Shared quality checks for C# (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks-csharp.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks-csharp" as Workflow
+participant "dot.net\n(dotnet-install.sh)" as DotNet
+
+Caller -> Workflow: workflow_call with working-directory,\nproject and dotnet-sdk-version
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared script
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid or the SDK is not an exact\nstable version 10 or later
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> DotNet: Install the exact .NET SDK version
+DotNet --> Workflow: SDK installed
+
+alt no C# file is tracked
+  Workflow --> Caller: Notice: nothing was checked, pass
+else no solution or project, or several without the project input
+  Workflow --> Caller: Fail with [configuration] that names them
+else
+  Workflow -> Workflow: dotnet format --verify-no-changes
+  Workflow -> Workflow: dotnet build -warnaserror\n(package restore needs the network)
+  alt any tool failed
+    Workflow --> Caller: Fail with tool, file and line in the log
+  else
+    Workflow --> Caller: All selected checks passed
+  end
+end
+deactivate Workflow
+@enduml
+```
+
+### Kodemålinger og dækningsbadges
+
+Et genbrugeligt workflow, der tæller kodefilerne og kodelinjerne (uden kommentar- og tomme linjer) i et repository og udgiver dem sammen med testdækningen som tre SVG-badges på en `badges`-gren, kaldt med `uses: TirSystem/github-action/.gitea/workflows/code-metrics.yml@v1` (ADR-0010). Det kræver `contents: write` og kører ingen test: et tidligere job hos kalderen frembringer en dækningsrapport i Cobertura XML-format og uploader den som artefakt ([vejledning](CodeMetrics.da)).
+
+#### Workflow
+
+```plantuml
+@startuml
+title Code metrics and coverage badges (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...code-metrics.yml@v1" as Caller
+participant "Gitea Actions\ncode-metrics" as Workflow
+participant "Branch badges\nof the caller" as Branch
+
+Caller -> Workflow: workflow_call with working-directory, exclude,\ncoverage-report and thresholds
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared scripts
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> Workflow: Download the coverage artifact (when given)
+Workflow -> Workflow: Count code files and lines of code
+alt a coverage report is given but missing or malformed
+  Workflow --> Caller: Fail with [configuration] that names the file
+else
+  Workflow -> Workflow: Write code-files.svg, code-lines.svg\nand coverage.svg
+end
+
+Workflow -> Branch: Compare with the files of the branch
+alt no badge changed
+  Workflow --> Caller: Notice: nothing to commit, pass
+else
+  Workflow -> Branch: One commit with [skip ci]
+  Workflow --> Caller: Badges published
+end
+deactivate Workflow
+@enduml
+```
+
+### Udgivelse
+
+Startes manuelt af en vedligeholder; med `dry_run` `true` (standard) kontrollerer det kun (se [udgivelsesprocessen](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/release-process.md)).
+
+#### Workflow
+
+```plantuml
+@startuml
+title Release this repository
+
+autonumber
+
+actor "Maintainer\n(workflow_dispatch: version, dry_run)" as Trigger
+participant "Gitea Actions\nrelease" as Workflow
+participant "Gitea REST API" as Gitea
+
+Trigger -> Workflow: Start with version and dry_run
+activate Workflow
+
+Workflow -> Workflow: Check the version and read CHANGELOG.md
+alt version malformed or no changelog entry
+  Workflow --> Trigger: Fail with [validation] or [configuration]
+end
+
+Workflow -> Gitea: GET branch main and status of the commit
+Gitea --> Workflow: Tip of main and the validation run
+alt commit is not the tip of main,\nor the validation run is not green
+  Workflow --> Trigger: Fail with [validation]\n(no tag is created)
+end
+
+Workflow -> Gitea: GET tags
+Gitea --> Workflow: Existing tags
+alt tag vMAJOR.MINOR.PATCH exists
+  Workflow --> Trigger: Fail with [validation]\n(tags are never moved)
+end
+
+alt dry_run is true (default)
+  Workflow --> Trigger: Log what would be created and stop
+else
+  Workflow -> Gitea: POST release (creates the version tag,\nbody is the changelog entry)
+  opt this is the highest version of its major
+    Workflow -> Gitea: Delete and recreate the major tag vMAJOR
+  end
+  Workflow --> Trigger: Released
+end
+deactivate Workflow
+@enduml
+```
+
+### Publicering af wiki-sider
+
+Et genbrugeligt workflow (ADR-0009). Et repository kalder det fra sit eget workflow, så selve kaldet er tilmeldingen, og der behøves ingen markørfil. Det publicerer Markdown-siderne i `wiki_dir` (standard `docs/wiki`) til wikien i det kaldende repository og sletter kun sider, der ikke findes i mappen, når `prune` er `true`.
+
+```yaml
+on:
+  push:
+    branches: [ main ]
+    paths: [ "docs/wiki/**" ]
+jobs:
+  wiki:
+    uses: TirSystem/github-action/.gitea/workflows/publish-wiki-pages.yml@v1
+    secrets:
+      TOKEN_FOR_GITEA_WIKI: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
+```
+
+#### Workflow
+
+```plantuml
+@startuml
+title Publish docs/wiki to the wiki of the calling repository
+
+autonumber
+
+actor "Calling repository\nuses: ...publish-wiki-pages.yml@v1" as Caller
+participant "Gitea Actions\npublish-wiki-pages" as Workflow
+participant "shared-scripts\n(tools/publish_wiki.py at tools-ref)" as Script
+participant "Gitea wiki API" as Wiki
+
+Caller -> Workflow: Call with wiki_dir, prune and the secret
+activate Workflow
+Workflow -> Script: Check out the repository and the script, run it
+activate Script
+
+alt wiki_dir does not exist, or has no Markdown pages
+  Script --> Workflow: Fail with [configuration]\n(an empty folder never deletes pages)
+else
+  Script -> Script: Read prune and TOKEN_FOR_GITEA_WIKI
+  Script -> Wiki: GET repository (preflight)
+  Wiki --> Script: Wiki is enabled, token accepted
+  Script -> Wiki: GET pages
+  Wiki --> Script: Existing pages
+  Script -> Wiki: Create new pages, update changed pages
+  opt prune is true
+    Script -> Wiki: Delete pages that are not in wiki_dir
+  end
+  Script --> Workflow: Log created, updated and deleted counts
+end
+deactivate Script
+Workflow --> Caller: Workflow result
+deactivate Workflow
+@enduml
+```
+
+### Publicering af egen wiki
+
+Dette repositorys wiki er `docs/wiki/`. Workflowet kalder det genbrugelige workflow ovenfor med dets lokale sti, med `prune` sat til `true`, så wikien altid er lig med mappen, og `tools-ref` sat til `main`, så scriptet fra samme commit kører. Det er den kalder, et projekt kopierer fra frameworkets `templates/ci/publish-wiki.yml`.
+
+#### Workflow
+
+```plantuml
+@startuml
+title Publish the wiki of this repository (docs/wiki)
+
+autonumber
+
+actor "Push to main that changes docs/wiki/**,\nor manual trigger" as Trigger
+participant "Gitea Actions\npublish-own-wiki" as Caller
+participant "Gitea Actions\npublish-wiki-pages\n(called by its local path)" as Workflow
+participant "Gitea wiki API" as Wiki
+
+Trigger -> Caller: Start workflow
+activate Caller
+Caller -> Workflow: Call with wiki_dir docs/wiki, prune true,\ntools-ref main and TOKEN_FOR_GITEA_WIKI
+activate Workflow
+Workflow -> Wiki: Create, update and delete pages\nso the wiki equals docs/wiki
+Wiki --> Workflow: Done
+Workflow --> Caller: Workflow result
+deactivate Workflow
+Caller --> Trigger: Workflow result
+deactivate Caller
+@enduml
+```
+
+### Publicering af accepterede milepæle
+
+Permanent tilladelse til at publicere: ved et push til `main`, der ændrer milepælene eller deres gennemgange, oprettes eller opdateres hver milepæl, hvis seneste række i Version History er Accepted, og hvis seneste gennemgang er en Go, på Gitea med sine opgaver som issues. Intet lukkes eller slettes. En manuel kørsel er en tørkørsel, medmindre `dry_run` slås fra. Det bruger secret'en `TOKEN_FOR_GITEA` og `--accepted-only`-reglen i det monterede framework (v0.5.0 eller nyere).
+
+#### Workflow
+
+```plantuml
+@startuml
+title Publish accepted milestones (this repository)
+
+autonumber
+
+actor "Push to main that changes\ndocs/milestones/** or docs/sqa/reviews/**,\nor manual trigger" as Trigger
+participant "Gitea Actions\nsync-milestones" as Workflow
+participant "framework/scripts/\nsync-project.sh" as Script
+participant "Gitea REST API" as Gitea
+
+Trigger -> Workflow: Start workflow
+activate Workflow
+Workflow -> Workflow: Check out the project and the framework\nsubmodules over HTTPS with TOKEN_FOR_GITEA
+Workflow -> Script: --accepted-only (dry run)\nor --accepted-only --apply
+activate Script
+
+loop for each docs/milestones/mil-*.md
+  alt latest Version History row is not Accepted,\nor the latest review record is not a Go
+    Script -> Script: Skip with the reason on stderr
+  else
+    alt dry run
+      Script -> Script: Print the plan, no network call
+    else
+      Script -> Gitea: Create or update the Milestone\nand one Issue per task row
+      Gitea --> Script: Milestone and issue numbers
+    end
+  end
+end
+
+note right of Script
+Nothing is closed or deleted.
+Each real run edits the issues
+of every accepted milestone.
+end note
+Script --> Workflow: Done, or "nothing to publish"
+deactivate Script
+Workflow --> Trigger: Workflow result
+deactivate Workflow
+@enduml
+```
+
+### Validering af workflows
+
+Repositoryets egen validering: de offline-tests, der er en betingelse for hver pull request.
+
+#### Workflow
+
+```plantuml
+@startuml
+title Validate workflows (this repository's own checks)
+
+autonumber
+
+actor "Pull request,\npush to main, or manual trigger" as Trigger
+participant "Gitea Actions\nvalidate-workflows" as Workflow
+
+Trigger -> Workflow: Start workflow
+activate Workflow
+Workflow -> Workflow: Check out the repository
+Workflow -> Workflow: Create a virtual environment and\ninstall tests/requirements.txt
+Workflow -> Workflow: Run pytest on tests/ under coverage (offline, no secrets):\nworkflows parse as YAML, no embedded Python,\nscripts compile, wiki pages and translations are current,\nsync, publish and release flows against a fake API
+
+alt a test fails
+  Workflow --> Trigger: Workflow fails (the pull request is not ready)
+else
+  Workflow --> Trigger: Workflow succeeds
+end
+deactivate Workflow
+@enduml
+```
+
+
+## Krav
+
+- En Gitea-instans med Actions aktiveret og en runner med labelen `ubuntu-latest` og `python3`
+- Et konfigureret GitHub push-spejl på Gitea-repositoryet (højst ét; repositories uden spejl springes over uden fejl)
+- Repository-secrets:
+  - `TOKEN_FOR_GITEA`: Gitea API-token (kun tokenet, ingen JSON)
+  - `PAT_FOR_GITHUB`: et GitHub personal access token, der må redigere spejl-repositoryet (kun tokenet, ingen JSON)
+  - `TOKEN_FOR_GITEA_WIKI` (kun for repositories, der publicerer en wiki, se [tilslutningsvejledningen](Onboarding.da)): et Gitea-token, der kan skrive til wikien, gemt som en secret i repositoryets organisation; der er ingen reserve til `TOKEN_FOR_GITEA`
+
+
+## Opsætning
+
+Der skal ikke installeres afhængigheder; workflowet bruger kun Pythons standardbibliotek.
+
+1. Klon repositoryet:
+   ```bash
+   git clone ssh://git@git.tirsystem.com:10022/TirSystem/github-action.git
+   ```
+2. Tilføj de secrets, der er nævnt under [Krav](#krav), til repositoryets indstillinger i Gitea.
+3. Konfigurer GitHub push-spejlet i repositoryets indstillinger.
+
+
+## Kørsel
+
+Workflows kører automatisk ved push til `main` og efter den daglige tidsplan. For at køre manuelt skal du starte **Sync GitHub mirror metadata** via `workflow_dispatch` fra fanen Actions i Gitea.
+
+
+## Tests
+
+Workflow-filerne og scripts i `tools/` valideres af offline-tests, som hverken kræver netværksadgang eller secrets:
+
+```bash
+python3 -m venv .venv
+source .venv/bin/activate        # Windows PowerShell: .venv\Scripts\Activate.ps1
+python -m pip install -r tests/requirements.txt
+python -m coverage run -m pytest -q tests
+python -m coverage report
+```
+
+De samme kontroller kører ved hver pull request og hvert push til `main` gennem [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml). De parser alle workflows som YAML, kontrollerer at ingen indlejrer Python, kompilerer scripts i `tools/`, kræver eksplicitte jobtilladelser og tester parsing af credentials, parsing af push-spejlets adresse og synkroniserings- og publiceringsforløbene mod et falsk API. Kørslen fejler, når linje- og forgreningsdækningen af `tools/` er under 95 % (`.coveragerc`).
+
+Efter en ændring af synkroniseringsworkflowet skal du også starte **Sync GitHub mirror metadata** manuelt i Gitea og sammenligne beskrivelsen og emnerne på GitHub-spejlet.

docs/wiki/Home.md

@@ -0,0 +1,535 @@
+<!-- Generated from README.md by tools/build_wiki.py. Edit the source, not this page. -->
+
+> This page is generated from [`README.md`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/README.md). Changes made here are overwritten the next time the wiki is published.
+
+English | [Dansk](Home.da) | [Bahasa Melayu](Home.ms)
+
+# TirSystem GitHub Actions
+
+A collection of reusable Gitea Actions workflows for DevOps professionals and software engineers working on TirSystem projects.
+
+
+## Overview
+
+This repository is the central collection of reusable automation for TirSystem repositories. The primary repository lives at `git.tirsystem.com` (Gitea) and is push-mirrored to GitHub.
+
+It contains ten workflows: metadata sync to the GitHub mirror, wiki publishing (called by each repository), shared quality checks for Python and shell, for C and C++ and for C#, code metrics and coverage badges, a release workflow, the publishing of accepted milestones and the repository's own validation. They are listed with their purpose and a diagram under [Workflows](#workflows).
+
+
+## Workflows
+
+Ten workflows live in this repository. A **scoped** workflow is delivered by the instance to every repository of the TirSystem organizations and needs nothing in the repository; a **reusable** workflow is called by a repository with `uses:`; the others run only here. The diagrams are PlantUML source.
+
+| Workflow | File | Kind | Starts on | Purpose |
+| --- | --- | --- | --- | --- |
+| Sync GitHub mirror metadata | [`sync-github-metadata.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push to `main`, manual, daily 03:17 UTC | Copies the description and topics of a Gitea repository to its GitHub push mirror |
+| Publish wiki pages | [`publish-wiki-pages.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/publish-wiki-pages.yml) | Reusable (`workflow_call`) | a call from another repository | Publishes the pages in `docs/wiki/` (or the folder named by `wiki_dir`) to the wiki of the calling repository |
+| Quality checks | [`quality-checks.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks.yml) | Reusable (`workflow_call`) | a call from another repository | Runs ruff, mypy, shellcheck and shfmt on the tracked files and changes nothing |
+| Quality checks C++ | [`quality-checks-cpp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-cpp.yml) | Reusable (`workflow_call`) | a call from another repository | Runs clang-format and clang-tidy at exact versions on the tracked C and C++ files and changes nothing |
+| Quality checks C# | [`quality-checks-csharp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-csharp.yml) | Reusable (`workflow_call`) | a call from another repository | Runs `dotnet format` and `dotnet build` on an exact .NET SDK 10 or later and changes nothing |
+| Code metrics | [`code-metrics.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/code-metrics.yml) | Reusable (`workflow_call`) | a call from another repository | Counts the code files and the lines of code (without comment and blank lines), reads a Cobertura coverage report and commits three SVG badges to a `badges` branch |
+| Publish own wiki | [`publish-own-wiki.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/publish-own-wiki.yml) | This repository only | push to `main` that changes `docs/wiki/**`, manual | Calls the reusable Publish wiki pages workflow for the wiki of this repository |
+| Release | [`release.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/release.yml) | This repository only | manual | Creates the version tag, the release page and the major tag after the checks |
+| Publish accepted milestones | [`sync-milestones.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/sync-milestones.yml) | This repository only | push to `main` that changes `docs/milestones/**` or `docs/sqa/reviews/**`, manual (dry run by default) | Creates or updates the Gitea milestone and issues of every milestone that is Accepted with a Go review |
+| Validate workflows | [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml) | This repository only | pull request, push to `main`, manual | Parses every workflow and runs the offline tests |
+
+### Sync GitHub metadata
+
+Syncs the Gitea repository description and topics to the GitHub push mirror.
+
+#### Cron
+
+Daily at 03:17 UTC (`17 3 * * *`), plus every push to `main` and manual `workflow_dispatch`.
+
+#### Workflow
+
+```plantuml
+@startuml
+title Sync Gitea repository description and topics to GitHub
+
+autonumber
+
+actor "Push to main,\nmanual trigger, or schedule" as Trigger
+participant "Gitea Actions\nsync-github-metadata" as Workflow
+participant "Gitea REST API" as Gitea
+participant "GitHub REST API" as GitHub
+
+Trigger -> Workflow: Start workflow
+activate Workflow
+
+Workflow -> Workflow: Read and validate secrets
+note right
+TOKEN_FOR_GITEA
+PAT_FOR_GITHUB
+end note
+
+alt secret validation failed
+  Workflow --> Trigger: workflow failed
+end
+
+
+Workflow -> Gitea: GET /repos/{owner}/{repo}
+Gitea --> Workflow: Description and topics
+
+Workflow -> Gitea: GET /repos/{owner}/{repo}/push_mirrors
+Gitea --> Workflow: Push mirror response
+
+alt mirrors is not a list
+    Workflow --> Trigger: Log a warning and succeed\n(GitHub metadata not synced)
+else mirrors is a list with no GitHub mirror
+    Workflow --> Trigger: Log that there is nothing to sync and succeed
+else mirrors is a list
+    Workflow -> Workflow: Find GitHub owner and repo from remote_address
+
+    Workflow -> GitHub: PATCH /repos/{owner}/{repo}\n{description}
+    GitHub --> Workflow: Repository updated
+
+    Workflow -> GitHub: PUT /repos/{owner}/{repo}/topics\n{names}
+    GitHub --> Workflow: Topics updated
+
+    Workflow --> Trigger: Sync completed
+else Gitea API denies access
+    Gitea --> Workflow: HTTP 403 Forbidden
+    Workflow --> Trigger: Workflow fails
+else GitHub API denies access
+    GitHub --> Workflow: HTTP error
+    Workflow --> Trigger: Workflow fails
+end
+deactivate Workflow
+@enduml
+```
+
+### Quality checks
+
+A reusable workflow for Python and shell, called with `uses: TirSystem/github-action/.gitea/workflows/quality-checks.yml@v1` (see the [guide](QualityChecksPythonShell)).
+
+#### Workflow
+
+```plantuml
+@startuml
+title Shared quality checks (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks" as Workflow
+participant "PyPI" as PyPI
+
+Caller -> Workflow: workflow_call with languages,\nworking-directory and tool versions
+activate Workflow
+
+Workflow -> Workflow: Validate the inputs
+alt languages or working-directory is invalid
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> Workflow: Check out the calling repository
+Workflow -> PyPI: Install the pinned tools in a virtual environment\n(ruff, mypy, shellcheck-py, shfmt-py as selected)
+PyPI --> Workflow: Tools installed
+
+loop for each selected language
+  Workflow -> Workflow: List tracked files
+  alt no files of that language
+    Workflow -> Workflow: Notice: nothing was checked
+  else
+    Workflow -> Workflow: Run every tool and record PASS or FAIL
+  end
+end
+
+alt any tool failed
+  Workflow --> Caller: Fail and list the failed tools
+else
+  Workflow --> Caller: All selected checks passed
+end
+deactivate Workflow
+@enduml
+```
+
+### Quality checks C++
+
+A reusable workflow for C and C++, called with `uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1` (ADR-0008). The repository needs a `.clang-format`; a `.clang-tidy` and a compile database are optional.
+
+#### Workflow
+
+```plantuml
+@startuml
+title Shared quality checks for C and C++ (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks-cpp.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks-cpp" as Workflow
+participant "PyPI" as PyPI
+
+Caller -> Workflow: workflow_call with working-directory, std,\ncompile-commands-dir and tool versions
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared script
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid or a version is not exact
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> PyPI: Install clang-format and clang-tidy at the exact versions
+PyPI --> Workflow: Tools installed
+
+alt no C or C++ file is tracked
+  Workflow --> Caller: Notice: nothing was checked, pass
+else no .clang-format, or compile-commands-dir\nwithout compile_commands.json
+  Workflow --> Caller: Fail with [configuration]
+else
+  Workflow -> Workflow: clang-format --dry-run -Werror on all files
+  Workflow -> Workflow: clang-tidy on the C++ files (-std=std)\nand on the C files (or with the compile database)
+  alt any tool failed
+    Workflow --> Caller: Fail with tool, file and line in the log
+  else
+    Workflow --> Caller: All selected checks passed
+  end
+end
+deactivate Workflow
+@enduml
+```
+
+### Quality checks C#
+
+A reusable workflow for C#, called with `uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1` (ADR-0008). It installs the exact .NET SDK given by `dotnet-sdk-version` (10 or later) and needs the network for the package restore.
+
+#### Workflow
+
+```plantuml
+@startuml
+title Shared quality checks for C# (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks-csharp.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks-csharp" as Workflow
+participant "dot.net\n(dotnet-install.sh)" as DotNet
+
+Caller -> Workflow: workflow_call with working-directory,\nproject and dotnet-sdk-version
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared script
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid or the SDK is not an exact\nstable version 10 or later
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> DotNet: Install the exact .NET SDK version
+DotNet --> Workflow: SDK installed
+
+alt no C# file is tracked
+  Workflow --> Caller: Notice: nothing was checked, pass
+else no solution or project, or several without the project input
+  Workflow --> Caller: Fail with [configuration] that names them
+else
+  Workflow -> Workflow: dotnet format --verify-no-changes
+  Workflow -> Workflow: dotnet build -warnaserror\n(package restore needs the network)
+  alt any tool failed
+    Workflow --> Caller: Fail with tool, file and line in the log
+  else
+    Workflow --> Caller: All selected checks passed
+  end
+end
+deactivate Workflow
+@enduml
+```
+
+### Code metrics
+
+A reusable workflow that counts the code files and the lines of code (without comment and blank lines) of a repository and publishes them, with the test coverage, as three SVG badges on a `badges` branch, called with `uses: TirSystem/github-action/.gitea/workflows/code-metrics.yml@v1` (ADR-0010). It needs `contents: write` and runs no test: an earlier job of the caller produces a Cobertura XML coverage report and uploads it as an artifact ([guide](CodeMetrics)).
+
+#### Workflow
+
+```plantuml
+@startuml
+title Code metrics and coverage badges (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...code-metrics.yml@v1" as Caller
+participant "Gitea Actions\ncode-metrics" as Workflow
+participant "Branch badges\nof the caller" as Branch
+
+Caller -> Workflow: workflow_call with working-directory, exclude,\ncoverage-report and thresholds
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared scripts
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> Workflow: Download the coverage artifact (when given)
+Workflow -> Workflow: Count code files and lines of code
+alt a coverage report is given but missing or malformed
+  Workflow --> Caller: Fail with [configuration] that names the file
+else
+  Workflow -> Workflow: Write code-files.svg, code-lines.svg\nand coverage.svg
+end
+
+Workflow -> Branch: Compare with the files of the branch
+alt no badge changed
+  Workflow --> Caller: Notice: nothing to commit, pass
+else
+  Workflow -> Branch: One commit with [skip ci]
+  Workflow --> Caller: Badges published
+end
+deactivate Workflow
+@enduml
+```
+
+### Release
+
+Started by hand by a maintainer; with `dry_run` `true` (the default) it only checks (see the [release process](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/release-process.md)).
+
+#### Workflow
+
+```plantuml
+@startuml
+title Release this repository
+
+autonumber
+
+actor "Maintainer\n(workflow_dispatch: version, dry_run)" as Trigger
+participant "Gitea Actions\nrelease" as Workflow
+participant "Gitea REST API" as Gitea
+
+Trigger -> Workflow: Start with version and dry_run
+activate Workflow
+
+Workflow -> Workflow: Check the version and read CHANGELOG.md
+alt version malformed or no changelog entry
+  Workflow --> Trigger: Fail with [validation] or [configuration]
+end
+
+Workflow -> Gitea: GET branch main and status of the commit
+Gitea --> Workflow: Tip of main and the validation run
+alt commit is not the tip of main,\nor the validation run is not green
+  Workflow --> Trigger: Fail with [validation]\n(no tag is created)
+end
+
+Workflow -> Gitea: GET tags
+Gitea --> Workflow: Existing tags
+alt tag vMAJOR.MINOR.PATCH exists
+  Workflow --> Trigger: Fail with [validation]\n(tags are never moved)
+end
+
+alt dry_run is true (default)
+  Workflow --> Trigger: Log what would be created and stop
+else
+  Workflow -> Gitea: POST release (creates the version tag,\nbody is the changelog entry)
+  opt this is the highest version of its major
+    Workflow -> Gitea: Delete and recreate the major tag vMAJOR
+  end
+  Workflow --> Trigger: Released
+end
+deactivate Workflow
+@enduml
+```
+
+### Publish wiki pages
+
+A reusable workflow (ADR-0009). A repository calls it from its own workflow, so the call is the opt-in and no marker file is needed. It publishes the Markdown pages of `wiki_dir` (default `docs/wiki`) to the wiki of the calling repository, and deletes pages that are not in the folder only when `prune` is `true`.
+
+```yaml
+on:
+  push:
+    branches: [ main ]
+    paths: [ "docs/wiki/**" ]
+jobs:
+  wiki:
+    uses: TirSystem/github-action/.gitea/workflows/publish-wiki-pages.yml@v1
+    secrets:
+      TOKEN_FOR_GITEA_WIKI: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
+```
+
+#### Workflow
+
+```plantuml
+@startuml
+title Publish docs/wiki to the wiki of the calling repository
+
+autonumber
+
+actor "Calling repository\nuses: ...publish-wiki-pages.yml@v1" as Caller
+participant "Gitea Actions\npublish-wiki-pages" as Workflow
+participant "shared-scripts\n(tools/publish_wiki.py at tools-ref)" as Script
+participant "Gitea wiki API" as Wiki
+
+Caller -> Workflow: Call with wiki_dir, prune and the secret
+activate Workflow
+Workflow -> Script: Check out the repository and the script, run it
+activate Script
+
+alt wiki_dir does not exist, or has no Markdown pages
+  Script --> Workflow: Fail with [configuration]\n(an empty folder never deletes pages)
+else
+  Script -> Script: Read prune and TOKEN_FOR_GITEA_WIKI
+  Script -> Wiki: GET repository (preflight)
+  Wiki --> Script: Wiki is enabled, token accepted
+  Script -> Wiki: GET pages
+  Wiki --> Script: Existing pages
+  Script -> Wiki: Create new pages, update changed pages
+  opt prune is true
+    Script -> Wiki: Delete pages that are not in wiki_dir
+  end
+  Script --> Workflow: Log created, updated and deleted counts
+end
+deactivate Script
+Workflow --> Caller: Workflow result
+deactivate Workflow
+@enduml
+```
+
+### Publish own wiki
+
+The wiki of this repository is `docs/wiki/`. This workflow calls the reusable workflow above by its local path, with `prune` set to `true` so the wiki always equals the folder and `tools-ref` set to `main` so that the script of the same commit runs. It is the caller that a project copies from the framework's `templates/ci/publish-wiki.yml`.
+
+#### Workflow
+
+```plantuml
+@startuml
+title Publish the wiki of this repository (docs/wiki)
+
+autonumber
+
+actor "Push to main that changes docs/wiki/**,\nor manual trigger" as Trigger
+participant "Gitea Actions\npublish-own-wiki" as Caller
+participant "Gitea Actions\npublish-wiki-pages\n(called by its local path)" as Workflow
+participant "Gitea wiki API" as Wiki
+
+Trigger -> Caller: Start workflow
+activate Caller
+Caller -> Workflow: Call with wiki_dir docs/wiki, prune true,\ntools-ref main and TOKEN_FOR_GITEA_WIKI
+activate Workflow
+Workflow -> Wiki: Create, update and delete pages\nso the wiki equals docs/wiki
+Wiki --> Workflow: Done
+Workflow --> Caller: Workflow result
+deactivate Workflow
+Caller --> Trigger: Workflow result
+deactivate Caller
+@enduml
+```
+
+### Publish accepted milestones
+
+Standing authorization to publish: on a push to `main` that changes the milestones or their reviews, every milestone whose latest Version History row is Accepted and whose latest review is a Go is created or updated on Gitea with its tasks as issues. Nothing is closed or deleted. A manual run is a dry run unless `dry_run` is switched off. It uses the secret `TOKEN_FOR_GITEA` and the `--accepted-only` rule of the mounted framework (v0.5.0 or later).
+
+#### Workflow
+
+```plantuml
+@startuml
+title Publish accepted milestones (this repository)
+
+autonumber
+
+actor "Push to main that changes\ndocs/milestones/** or docs/sqa/reviews/**,\nor manual trigger" as Trigger
+participant "Gitea Actions\nsync-milestones" as Workflow
+participant "framework/scripts/\nsync-project.sh" as Script
+participant "Gitea REST API" as Gitea
+
+Trigger -> Workflow: Start workflow
+activate Workflow
+Workflow -> Workflow: Check out the project and the framework\nsubmodules over HTTPS with TOKEN_FOR_GITEA
+Workflow -> Script: --accepted-only (dry run)\nor --accepted-only --apply
+activate Script
+
+loop for each docs/milestones/mil-*.md
+  alt latest Version History row is not Accepted,\nor the latest review record is not a Go
+    Script -> Script: Skip with the reason on stderr
+  else
+    alt dry run
+      Script -> Script: Print the plan, no network call
+    else
+      Script -> Gitea: Create or update the Milestone\nand one Issue per task row
+      Gitea --> Script: Milestone and issue numbers
+    end
+  end
+end
+
+note right of Script
+Nothing is closed or deleted.
+Each real run edits the issues
+of every accepted milestone.
+end note
+Script --> Workflow: Done, or "nothing to publish"
+deactivate Script
+Workflow --> Trigger: Workflow result
+deactivate Workflow
+@enduml
+```
+
+### Validate workflows
+
+The repository's own validation: the offline tests that gate every pull request.
+
+#### Workflow
+
+```plantuml
+@startuml
+title Validate workflows (this repository's own checks)
+
+autonumber
+
+actor "Pull request,\npush to main, or manual trigger" as Trigger
+participant "Gitea Actions\nvalidate-workflows" as Workflow
+
+Trigger -> Workflow: Start workflow
+activate Workflow
+Workflow -> Workflow: Check out the repository
+Workflow -> Workflow: Create a virtual environment and\ninstall tests/requirements.txt
+Workflow -> Workflow: Run pytest on tests/ under coverage (offline, no secrets):\nworkflows parse as YAML, no embedded Python,\nscripts compile, wiki pages and translations are current,\nsync, publish and release flows against a fake API
+
+alt a test fails
+  Workflow --> Trigger: Workflow fails (the pull request is not ready)
+else
+  Workflow --> Trigger: Workflow succeeds
+end
+deactivate Workflow
+@enduml
+```
+
+
+## Requirements
+
+- A Gitea instance with Actions enabled and a runner providing `ubuntu-latest` with `python3`
+- A configured GitHub push mirror on the Gitea repository (at most one; repositories without a mirror are skipped successfully)
+- Repository secrets:
+  - `TOKEN_FOR_GITEA`: Gitea API token (the token only, no JSON)
+  - `PAT_FOR_GITHUB`: a GitHub personal access token allowed to edit the mirror repository (the token only, no JSON)
+  - `TOKEN_FOR_GITEA_WIKI` (only for repositories that publish a wiki, see the [onboarding guide](Onboarding)): a Gitea token that can write the wiki, stored as a secret of the repository's organization; there is no fallback to `TOKEN_FOR_GITEA`
+
+
+## Setup
+
+No dependencies need to be installed; the workflow uses only the Python standard library.
+
+1. Clone the repository:
+   ```bash
+   git clone ssh://git@git.tirsystem.com:10022/TirSystem/github-action.git
+   ```
+2. Add the secrets listed under [Requirements](#requirements) to the repository settings in Gitea.
+3. Configure the GitHub push mirror in the repository settings.
+
+
+## Run
+
+Workflows run automatically on push to `main` and on the daily schedule. To run manually, trigger **Sync GitHub mirror metadata** via `workflow_dispatch` from the Actions tab in Gitea.
+
+
+## Tests
+
+The workflow files and the scripts in `tools/` are validated by offline tests that need no network access and no secrets:
+
+```bash
+python3 -m venv .venv
+source .venv/bin/activate        # Windows PowerShell: .venv\Scripts\Activate.ps1
+python -m pip install -r tests/requirements.txt
+python -m coverage run -m pytest -q tests
+python -m coverage report
+```
+
+The same checks run on every pull request and push to `main` through [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml). They parse every workflow as YAML, check that none embeds Python, compile the scripts in `tools/`, require explicit job permissions, and test credential parsing, push mirror address parsing and the sync and publish flows against a fake API. The run fails when the line and branch coverage of `tools/` falls below 95% (`.coveragerc`).
+
+After a change to the sync workflow, also trigger **Sync GitHub mirror metadata** manually in Gitea and compare the description and topics on the GitHub mirror.

docs/wiki/Home.ms.md

@@ -0,0 +1,535 @@
+<!-- translation of Home.md, source sha256 810981fb9bc8 -->
+
+> Ini ialah terjemahan [`Home`](Home). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
+
+[English](Home) | [Dansk](Home.da) | Bahasa Melayu
+
+# TirSystem GitHub Actions
+
+Koleksi aliran kerja (workflow) Gitea Actions yang boleh digunakan semula untuk profesional DevOps dan jurutera perisian yang mengusahakan projek TirSystem.
+
+
+## Gambaran keseluruhan
+
+Repositori ini ialah koleksi pusat bagi automasi yang boleh digunakan semula untuk repositori TirSystem. Repositori utama berada di `git.tirsystem.com` (Gitea) dan dicerminkan dengan push ke GitHub.
+
+Ia mengandungi sepuluh aliran kerja: penyegerakan metadata ke cermin GitHub, penerbitan wiki (dipanggil oleh setiap repositori), semakan kualiti bersama untuk Python dan shell, untuk C dan C++ serta untuk C#, metrik kod dan lencana liputan, aliran kerja keluaran, penerbitan pencapaian (milestone) yang diterima dan pengesahan repositori sendiri. Ia disenaraikan dengan tujuan dan rajah di bawah [Aliran kerja](#aliran-kerja).
+
+
+## Aliran kerja
+
+Terdapat sepuluh aliran kerja dalam repositori ini. Aliran kerja **scoped** dihantar oleh instans ke setiap repositori organisasi TirSystem dan tidak memerlukan apa-apa dalam repositori; aliran kerja **boleh guna semula** dipanggil oleh sebuah repositori dengan `uses:`; yang lain hanya berjalan di sini. Rajah ialah kod sumber PlantUML dan dalam bahasa Inggeris.
+
+| Aliran kerja | Fail | Jenis | Bermula apabila | Tujuan |
+| --- | --- | --- | --- | --- |
+| Sync GitHub mirror metadata | [`sync-github-metadata.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/scoped_workflows/sync-github-metadata.yml) | Scoped | push ke `main`, manual, setiap hari 03:17 UTC | Menyalin penerangan dan topik repositori Gitea ke push mirror GitHub-nya |
+| Publish wiki pages | [`publish-wiki-pages.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/publish-wiki-pages.yml) | Boleh guna semula (`workflow_call`) | panggilan daripada repositori lain | Menerbitkan halaman dalam `docs/wiki/` (atau folder yang dinamakan oleh `wiki_dir`) ke wiki repositori pemanggil |
+| Quality checks | [`quality-checks.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks.yml) | Boleh guna semula (`workflow_call`) | panggilan daripada repositori lain | Menjalankan ruff, mypy, shellcheck dan shfmt pada fail yang dijejaki dan tidak mengubah apa-apa |
+| Quality checks C++ | [`quality-checks-cpp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-cpp.yml) | Boleh guna semula (`workflow_call`) | panggilan daripada repositori lain | Menjalankan clang-format dan clang-tidy pada versi tepat pada fail C dan C++ yang dijejaki dan tidak mengubah apa-apa |
+| Quality checks C# | [`quality-checks-csharp.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/quality-checks-csharp.yml) | Boleh guna semula (`workflow_call`) | panggilan daripada repositori lain | Menjalankan `dotnet format` dan `dotnet build` pada .NET SDK 10 atau lebih baharu yang tepat dan tidak mengubah apa-apa |
+| Code metrics | [`code-metrics.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/code-metrics.yml) | Boleh guna semula (`workflow_call`) | panggilan daripada repositori lain | Mengira fail kod dan baris kod (tanpa baris komen dan baris kosong), membaca laporan liputan Cobertura dan melakukan commit tiga lencana SVG ke cabang `badges` |
+| Publish own wiki | [`publish-own-wiki.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/publish-own-wiki.yml) | Repositori ini sahaja | push ke `main` yang mengubah `docs/wiki/**`, manual | Memanggil aliran kerja boleh guna semula Publish wiki pages untuk wiki repositori ini |
+| Release | [`release.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/release.yml) | Repositori ini sahaja | manual | Mencipta tag versi, halaman keluaran dan tag major selepas semakan |
+| Menerbitkan milestone yang diterima | [`sync-milestones.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/sync-milestones.yml) | Repositori ini sahaja | push ke `main` yang mengubah `docs/milestones/**` atau `docs/sqa/reviews/**`, manual (larian percubaan secara lalai) | Mencipta atau mengemas kini milestone Gitea dan isu bagi setiap milestone yang Accepted dengan semakan Go |
+| Validate workflows | [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml) | Repositori ini sahaja | pull request, push ke `main`, manual | Menghurai setiap aliran kerja sebagai YAML dan menjalankan ujian luar talian |
+
+### Menyegerakkan metadata GitHub
+
+Menyegerakkan penerangan dan topik repositori Gitea ke push mirror GitHub.
+
+#### Jadual (cron)
+
+Setiap hari pada 03:17 UTC (`17 3 * * *`), serta pada setiap push ke `main` dan `workflow_dispatch` manual.
+
+#### Aliran kerja
+
+```plantuml
+@startuml
+title Sync Gitea repository description and topics to GitHub
+
+autonumber
+
+actor "Push to main,\nmanual trigger, or schedule" as Trigger
+participant "Gitea Actions\nsync-github-metadata" as Workflow
+participant "Gitea REST API" as Gitea
+participant "GitHub REST API" as GitHub
+
+Trigger -> Workflow: Start workflow
+activate Workflow
+
+Workflow -> Workflow: Read and validate secrets
+note right
+TOKEN_FOR_GITEA
+PAT_FOR_GITHUB
+end note
+
+alt secret validation failed
+  Workflow --> Trigger: workflow failed
+end
+
+
+Workflow -> Gitea: GET /repos/{owner}/{repo}
+Gitea --> Workflow: Description and topics
+
+Workflow -> Gitea: GET /repos/{owner}/{repo}/push_mirrors
+Gitea --> Workflow: Push mirror response
+
+alt mirrors is not a list
+    Workflow --> Trigger: Log a warning and succeed\n(GitHub metadata not synced)
+else mirrors is a list with no GitHub mirror
+    Workflow --> Trigger: Log that there is nothing to sync and succeed
+else mirrors is a list
+    Workflow -> Workflow: Find GitHub owner and repo from remote_address
+
+    Workflow -> GitHub: PATCH /repos/{owner}/{repo}\n{description}
+    GitHub --> Workflow: Repository updated
+
+    Workflow -> GitHub: PUT /repos/{owner}/{repo}/topics\n{names}
+    GitHub --> Workflow: Topics updated
+
+    Workflow --> Trigger: Sync completed
+else Gitea API denies access
+    Gitea --> Workflow: HTTP 403 Forbidden
+    Workflow --> Trigger: Workflow fails
+else GitHub API denies access
+    GitHub --> Workflow: HTTP error
+    Workflow --> Trigger: Workflow fails
+end
+deactivate Workflow
+@enduml
+```
+
+### Semakan kualiti
+
+Aliran kerja boleh guna semula untuk Python dan shell, dipanggil dengan `uses: TirSystem/github-action/.gitea/workflows/quality-checks.yml@v1` (lihat [panduan](QualityChecksPythonShell)).
+
+#### Aliran kerja
+
+```plantuml
+@startuml
+title Shared quality checks (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks" as Workflow
+participant "PyPI" as PyPI
+
+Caller -> Workflow: workflow_call with languages,\nworking-directory and tool versions
+activate Workflow
+
+Workflow -> Workflow: Validate the inputs
+alt languages or working-directory is invalid
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> Workflow: Check out the calling repository
+Workflow -> PyPI: Install the pinned tools in a virtual environment\n(ruff, mypy, shellcheck-py, shfmt-py as selected)
+PyPI --> Workflow: Tools installed
+
+loop for each selected language
+  Workflow -> Workflow: List tracked files
+  alt no files of that language
+    Workflow -> Workflow: Notice: nothing was checked
+  else
+    Workflow -> Workflow: Run every tool and record PASS or FAIL
+  end
+end
+
+alt any tool failed
+  Workflow --> Caller: Fail and list the failed tools
+else
+  Workflow --> Caller: All selected checks passed
+end
+deactivate Workflow
+@enduml
+```
+
+### Semakan kualiti C++
+
+Aliran kerja boleh guna semula untuk C dan C++, dipanggil dengan `uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1` (ADR-0008). Repositori mesti mempunyai `.clang-format`; `.clang-tidy` dan pangkalan data kompilasi adalah pilihan.
+
+#### Aliran kerja
+
+```plantuml
+@startuml
+title Shared quality checks for C and C++ (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks-cpp.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks-cpp" as Workflow
+participant "PyPI" as PyPI
+
+Caller -> Workflow: workflow_call with working-directory, std,\ncompile-commands-dir and tool versions
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared script
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid or a version is not exact
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> PyPI: Install clang-format and clang-tidy at the exact versions
+PyPI --> Workflow: Tools installed
+
+alt no C or C++ file is tracked
+  Workflow --> Caller: Notice: nothing was checked, pass
+else no .clang-format, or compile-commands-dir\nwithout compile_commands.json
+  Workflow --> Caller: Fail with [configuration]
+else
+  Workflow -> Workflow: clang-format --dry-run -Werror on all files
+  Workflow -> Workflow: clang-tidy on the C++ files (-std=std)\nand on the C files (or with the compile database)
+  alt any tool failed
+    Workflow --> Caller: Fail with tool, file and line in the log
+  else
+    Workflow --> Caller: All selected checks passed
+  end
+end
+deactivate Workflow
+@enduml
+```
+
+### Semakan kualiti C#
+
+Aliran kerja boleh guna semula untuk C#, dipanggil dengan `uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1` (ADR-0008). Ia memasang .NET SDK tepat yang diberikan oleh `dotnet-sdk-version` (10 atau lebih baharu) dan memerlukan rangkaian untuk pemulihan pakej.
+
+#### Aliran kerja
+
+```plantuml
+@startuml
+title Shared quality checks for C# (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...quality-checks-csharp.yml@v1" as Caller
+participant "Gitea Actions\nquality-checks-csharp" as Workflow
+participant "dot.net\n(dotnet-install.sh)" as DotNet
+
+Caller -> Workflow: workflow_call with working-directory,\nproject and dotnet-sdk-version
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared script
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid or the SDK is not an exact\nstable version 10 or later
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> DotNet: Install the exact .NET SDK version
+DotNet --> Workflow: SDK installed
+
+alt no C# file is tracked
+  Workflow --> Caller: Notice: nothing was checked, pass
+else no solution or project, or several without the project input
+  Workflow --> Caller: Fail with [configuration] that names them
+else
+  Workflow -> Workflow: dotnet format --verify-no-changes
+  Workflow -> Workflow: dotnet build -warnaserror\n(package restore needs the network)
+  alt any tool failed
+    Workflow --> Caller: Fail with tool, file and line in the log
+  else
+    Workflow --> Caller: All selected checks passed
+  end
+end
+deactivate Workflow
+@enduml
+```
+
+### Metrik kod dan lencana liputan
+
+Aliran kerja boleh guna semula yang mengira fail kod dan baris kod (tanpa baris komen dan baris kosong) sesebuah repositori dan menerbitkannya, bersama liputan ujian, sebagai tiga lencana SVG pada cabang `badges`, dipanggil dengan `uses: TirSystem/github-action/.gitea/workflows/code-metrics.yml@v1` (ADR-0010). Ia memerlukan `contents: write` dan tidak menjalankan sebarang ujian: kerja yang lebih awal oleh pemanggil menghasilkan laporan liputan format Cobertura XML dan memuat naiknya sebagai artifak ([panduan](CodeMetrics.ms)).
+
+#### Aliran kerja
+
+```plantuml
+@startuml
+title Code metrics and coverage badges (reusable workflow)
+
+autonumber
+
+actor "Calling repository\nuses: ...code-metrics.yml@v1" as Caller
+participant "Gitea Actions\ncode-metrics" as Workflow
+participant "Branch badges\nof the caller" as Branch
+
+Caller -> Workflow: workflow_call with working-directory, exclude,\ncoverage-report and thresholds
+activate Workflow
+
+Workflow -> Workflow: Check out the caller and the shared scripts
+Workflow -> Workflow: Validate the inputs
+alt an input is invalid
+  Workflow --> Caller: Fail with [configuration]
+end
+
+Workflow -> Workflow: Download the coverage artifact (when given)
+Workflow -> Workflow: Count code files and lines of code
+alt a coverage report is given but missing or malformed
+  Workflow --> Caller: Fail with [configuration] that names the file
+else
+  Workflow -> Workflow: Write code-files.svg, code-lines.svg\nand coverage.svg
+end
+
+Workflow -> Branch: Compare with the files of the branch
+alt no badge changed
+  Workflow --> Caller: Notice: nothing to commit, pass
+else
+  Workflow -> Branch: One commit with [skip ci]
+  Workflow --> Caller: Badges published
+end
+deactivate Workflow
+@enduml
+```
+
+### Keluaran
+
+Dimulakan secara manual oleh penyelenggara; dengan `dry_run` `true` (lalai) ia hanya menyemak (lihat [proses keluaran](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/release-process.md)).
+
+#### Aliran kerja
+
+```plantuml
+@startuml
+title Release this repository
+
+autonumber
+
+actor "Maintainer\n(workflow_dispatch: version, dry_run)" as Trigger
+participant "Gitea Actions\nrelease" as Workflow
+participant "Gitea REST API" as Gitea
+
+Trigger -> Workflow: Start with version and dry_run
+activate Workflow
+
+Workflow -> Workflow: Check the version and read CHANGELOG.md
+alt version malformed or no changelog entry
+  Workflow --> Trigger: Fail with [validation] or [configuration]
+end
+
+Workflow -> Gitea: GET branch main and status of the commit
+Gitea --> Workflow: Tip of main and the validation run
+alt commit is not the tip of main,\nor the validation run is not green
+  Workflow --> Trigger: Fail with [validation]\n(no tag is created)
+end
+
+Workflow -> Gitea: GET tags
+Gitea --> Workflow: Existing tags
+alt tag vMAJOR.MINOR.PATCH exists
+  Workflow --> Trigger: Fail with [validation]\n(tags are never moved)
+end
+
+alt dry_run is true (default)
+  Workflow --> Trigger: Log what would be created and stop
+else
+  Workflow -> Gitea: POST release (creates the version tag,\nbody is the changelog entry)
+  opt this is the highest version of its major
+    Workflow -> Gitea: Delete and recreate the major tag vMAJOR
+  end
+  Workflow --> Trigger: Released
+end
+deactivate Workflow
+@enduml
+```
+
+### Menerbitkan halaman wiki
+
+Aliran kerja boleh guna semula (ADR-0009). Sesebuah repositori memanggilnya daripada aliran kerjanya sendiri, jadi panggilan itu ialah pilihan menyertai dan tiada fail penanda diperlukan. Ia menerbitkan halaman Markdown dalam `wiki_dir` (lalai `docs/wiki`) ke wiki repositori pemanggil, dan memadam halaman yang tiada dalam folder hanya apabila `prune` ialah `true`.
+
+```yaml
+on:
+  push:
+    branches: [ main ]
+    paths: [ "docs/wiki/**" ]
+jobs:
+  wiki:
+    uses: TirSystem/github-action/.gitea/workflows/publish-wiki-pages.yml@v1
+    secrets:
+      TOKEN_FOR_GITEA_WIKI: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
+```
+
+#### Aliran kerja
+
+```plantuml
+@startuml
+title Publish docs/wiki to the wiki of the calling repository
+
+autonumber
+
+actor "Calling repository\nuses: ...publish-wiki-pages.yml@v1" as Caller
+participant "Gitea Actions\npublish-wiki-pages" as Workflow
+participant "shared-scripts\n(tools/publish_wiki.py at tools-ref)" as Script
+participant "Gitea wiki API" as Wiki
+
+Caller -> Workflow: Call with wiki_dir, prune and the secret
+activate Workflow
+Workflow -> Script: Check out the repository and the script, run it
+activate Script
+
+alt wiki_dir does not exist, or has no Markdown pages
+  Script --> Workflow: Fail with [configuration]\n(an empty folder never deletes pages)
+else
+  Script -> Script: Read prune and TOKEN_FOR_GITEA_WIKI
+  Script -> Wiki: GET repository (preflight)
+  Wiki --> Script: Wiki is enabled, token accepted
+  Script -> Wiki: GET pages
+  Wiki --> Script: Existing pages
+  Script -> Wiki: Create new pages, update changed pages
+  opt prune is true
+    Script -> Wiki: Delete pages that are not in wiki_dir
+  end
+  Script --> Workflow: Log created, updated and deleted counts
+end
+deactivate Script
+Workflow --> Caller: Workflow result
+deactivate Workflow
+@enduml
+```
+
+### Menerbitkan wiki sendiri
+
+Wiki repositori ini ialah `docs/wiki/`. Aliran kerja ini memanggil aliran kerja boleh guna semula di atas melalui laluan tempatannya, dengan `prune` ditetapkan kepada `true` supaya wiki sentiasa sama dengan folder dan `tools-ref` ditetapkan kepada `main` supaya skrip daripada commit yang sama dijalankan. Ia ialah pemanggil yang disalin oleh projek daripada `templates/ci/publish-wiki.yml` framework.
+
+#### Aliran kerja
+
+```plantuml
+@startuml
+title Publish the wiki of this repository (docs/wiki)
+
+autonumber
+
+actor "Push to main that changes docs/wiki/**,\nor manual trigger" as Trigger
+participant "Gitea Actions\npublish-own-wiki" as Caller
+participant "Gitea Actions\npublish-wiki-pages\n(called by its local path)" as Workflow
+participant "Gitea wiki API" as Wiki
+
+Trigger -> Caller: Start workflow
+activate Caller
+Caller -> Workflow: Call with wiki_dir docs/wiki, prune true,\ntools-ref main and TOKEN_FOR_GITEA_WIKI
+activate Workflow
+Workflow -> Wiki: Create, update and delete pages\nso the wiki equals docs/wiki
+Wiki --> Workflow: Done
+Workflow --> Caller: Workflow result
+deactivate Workflow
+Caller --> Trigger: Workflow result
+deactivate Caller
+@enduml
+```
+
+### Menerbitkan milestone yang diterima
+
+Kebenaran tetap untuk menerbitkan: pada push ke `main` yang mengubah milestone atau semakannya, setiap milestone yang baris terkini Version History-nya Accepted dan semakan terkininya Go dicipta atau dikemas kini di Gitea dengan tugasnya sebagai isu. Tiada apa-apa ditutup atau dipadam. Larian manual ialah larian percubaan kecuali `dry_run` dimatikan. Ia menggunakan secret `TOKEN_FOR_GITEA` dan peraturan `--accepted-only` framework yang dipasang (v0.5.0 atau lebih baharu).
+
+#### Aliran kerja
+
+```plantuml
+@startuml
+title Publish accepted milestones (this repository)
+
+autonumber
+
+actor "Push to main that changes\ndocs/milestones/** or docs/sqa/reviews/**,\nor manual trigger" as Trigger
+participant "Gitea Actions\nsync-milestones" as Workflow
+participant "framework/scripts/\nsync-project.sh" as Script
+participant "Gitea REST API" as Gitea
+
+Trigger -> Workflow: Start workflow
+activate Workflow
+Workflow -> Workflow: Check out the project and the framework\nsubmodules over HTTPS with TOKEN_FOR_GITEA
+Workflow -> Script: --accepted-only (dry run)\nor --accepted-only --apply
+activate Script
+
+loop for each docs/milestones/mil-*.md
+  alt latest Version History row is not Accepted,\nor the latest review record is not a Go
+    Script -> Script: Skip with the reason on stderr
+  else
+    alt dry run
+      Script -> Script: Print the plan, no network call
+    else
+      Script -> Gitea: Create or update the Milestone\nand one Issue per task row
+      Gitea --> Script: Milestone and issue numbers
+    end
+  end
+end
+
+note right of Script
+Nothing is closed or deleted.
+Each real run edits the issues
+of every accepted milestone.
+end note
+Script --> Workflow: Done, or "nothing to publish"
+deactivate Script
+Workflow --> Trigger: Workflow result
+deactivate Workflow
+@enduml
+```
+
+### Mengesahkan aliran kerja
+
+Pengesahan repositori sendiri: ujian luar talian yang menjadi syarat bagi setiap pull request.
+
+#### Aliran kerja
+
+```plantuml
+@startuml
+title Validate workflows (this repository's own checks)
+
+autonumber
+
+actor "Pull request,\npush to main, or manual trigger" as Trigger
+participant "Gitea Actions\nvalidate-workflows" as Workflow
+
+Trigger -> Workflow: Start workflow
+activate Workflow
+Workflow -> Workflow: Check out the repository
+Workflow -> Workflow: Create a virtual environment and\ninstall tests/requirements.txt
+Workflow -> Workflow: Run pytest on tests/ under coverage (offline, no secrets):\nworkflows parse as YAML, no embedded Python,\nscripts compile, wiki pages and translations are current,\nsync, publish and release flows against a fake API
+
+alt a test fails
+  Workflow --> Trigger: Workflow fails (the pull request is not ready)
+else
+  Workflow --> Trigger: Workflow succeeds
+end
+deactivate Workflow
+@enduml
+```
+
+
+## Keperluan
+
+- Satu instans Gitea dengan Actions diaktifkan dan satu runner yang menyediakan `ubuntu-latest` dengan `python3`
+- Satu push mirror GitHub yang dikonfigurasi pada repositori Gitea (paling banyak satu; repositori tanpa cermin dilangkau dengan jayanya)
+- Rahsia (secret) repositori:
+  - `TOKEN_FOR_GITEA`: token API Gitea (token sahaja, tanpa JSON)
+  - `PAT_FOR_GITHUB`: personal access token GitHub yang dibenarkan mengubah suai repositori cermin (token sahaja, tanpa JSON)
+  - `TOKEN_FOR_GITEA_WIKI` (hanya untuk repositori yang menerbitkan wiki, lihat [panduan menyertakan repositori](Onboarding.ms)): token Gitea yang boleh menulis ke wiki, disimpan sebagai secret organisasi repositori; tiada sandaran kepada `TOKEN_FOR_GITEA`
+
+
+## Persediaan
+
+Tiada kebergantungan perlu dipasang; aliran kerja hanya menggunakan pustaka standard Python.
+
+1. Klon repositori:
+   ```bash
+   git clone ssh://git@git.tirsystem.com:10022/TirSystem/github-action.git
+   ```
+2. Tambah rahsia yang disenaraikan di bawah [Keperluan](#keperluan) ke tetapan repositori dalam Gitea.
+3. Konfigurasikan push mirror GitHub dalam tetapan repositori.
+
+
+## Jalankan
+
+Aliran kerja berjalan secara automatik pada push ke `main` dan mengikut jadual harian. Untuk menjalankannya secara manual, cetuskan **Sync GitHub mirror metadata** melalui `workflow_dispatch` dari tab Actions dalam Gitea.
+
+
+## Ujian
+
+Fail aliran kerja dan skrip dalam `tools/` disahkan oleh ujian luar talian yang tidak memerlukan akses rangkaian dan tidak memerlukan rahsia:
+
+```bash
+python3 -m venv .venv
+source .venv/bin/activate        # Windows PowerShell: .venv\Scripts\Activate.ps1
+python -m pip install -r tests/requirements.txt
+python -m coverage run -m pytest -q tests
+python -m coverage report
+```
+
+Semakan yang sama dijalankan pada setiap pull request dan setiap push ke `main` melalui [`validate-workflows.yml`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/.gitea/workflows/validate-workflows.yml). Semakan itu menghurai setiap aliran kerja sebagai YAML, memastikan tiada yang menanam Python, mengkompil skrip dalam `tools/`, memerlukan kebenaran kerja yang jelas, dan menguji penghuraian kelayakan (credentials), penghuraian alamat push mirror serta aliran penyegerakan dan penerbitan terhadap API palsu. Larian gagal apabila liputan baris dan cabang `tools/` di bawah 95% (`.coveragerc`).
+
+Selepas perubahan pada aliran kerja penyegerakan, cetuskan juga **Sync GitHub mirror metadata** secara manual dalam Gitea dan bandingkan penerangan dan topik pada cermin GitHub.

docs/wiki/Onboarding.da.md

@@ -1,4 +1,4 @@
-<!-- translation of Onboarding.md, source sha256 1d431898754e -->
+<!-- translation of Onboarding.md, source sha256 1bc66efd5874 -->
 
 > Dette er en oversættelse af [`Onboarding`](Onboarding). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
 
@@ -32,16 +32,30 @@ Leveringen er automatisk, så et repository behøver ingen kopi af workflowet. S
 
 ## Publicér en wiki (valgfrit)
 
-Workflowet **Publish wiki** kopierer Markdown-siderne i `wiki/` til repositoryets wiki, når en ændring af `wiki/` flettes til `main`. Det leveres som synkroniseringsworkflowet, men skriver kun, hvor et repository har meldt sig til.
+Det genbrugelige workflow **Publish wiki pages** kopierer Markdown-siderne i `docs/wiki/` til repositoryets wiki, når en ændring af `docs/wiki/` flettes til `main`. Repositoryet kalder det, så der skrives intet, hvor der ikke findes et kald. Wikien findes som minimum på engelsk og på produktejerens sprog.
 
 1. Aktivér wikien i repositoryets indstillinger.
-2. Tilføj Markdown-sider til `wiki/`. Filnavnet er sidens navn: `Home.md` er forsiden.
-3. Tilføj markøren `wiki/.publish`. Lad den være tom for kun at oprette og opdatere sider. Skriv det ene ord `prune` i den for også at slette wiki-sider, der ikke findes i `wiki/`, så wikien altid er lig med mappen.
+2. Tilføj Markdown-sider til `docs/wiki/`. Filnavnet er sidens navn: `Home.md` er forsiden. En bindestreg i navnet er et mellemrum i sidens navn: `Home-da.md` er siden "Home da", og et link til den er `[Dansk](Home-da)`.
+3. Tilføj et workflow, for eksempel `.gitea/workflows/publish-wiki.yml`, der kalder det genbrugelige workflow:
+
+   ```yaml
+   on:
+     push:
+       branches: [ main ]
+       paths: [ "docs/wiki/**" ]
+   jobs:
+     wiki:
+       uses: TirSystem/github-action/.gitea/workflows/publish-wiki-pages.yml@v1
+       with:
+         prune: "true"
+       secrets:
+         TOKEN_FOR_GITEA_WIKI: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
+   ```
+
+   `wiki_dir` er som standard `docs/wiki`. `prune: "true"` sletter også wiki-sider, der ikke findes i mappen, så wikien altid er lig med mappen; standarden `false` beholder dem.
 4. Gem `TOKEN_FOR_GITEA_WIKI` som en secret i repositoryets organisation med det scope, der står i [credentials.md](Credentials.da).
 5. Flet ændringen til `main`. Loggen skal slutte med `Published <n> page(s) to the wiki of <owner>/<repo>`.
 
-Et repository uden `wiki/.publish` springes over med linjen `No wiki/.publish marker in <owner>/<repo>`: intet bliver skrevet, og der skal ingen secret til.
-
 ## Runners
 
 | Punkt | Værdi |

docs/wiki/Onboarding.md

@@ -51,25 +51,40 @@ Delivery is automatic, so a repository needs no copy of the workflow. Secrets ar
 
 ## Publish a wiki (optional)
 
-The **Publish wiki** workflow copies the Markdown pages in `wiki/` to the
-repository wiki when a change to `wiki/` is merged to `main`. It is delivered
-like the sync workflow, but it writes only where a repository opts in.
+The reusable workflow **Publish wiki pages** copies the Markdown pages in
+`docs/wiki/` to the repository wiki when a change to `docs/wiki/` is merged to
+`main`. The repository calls it, so nothing is written where no call exists.
+The wiki has English and the product owner's language as a minimum.
 
 1. Enable the wiki in the repository settings.
-2. Add Markdown pages to `wiki/`. The file name is the page name: `Home.md` is
-   the home page.
-3. Add the marker `wiki/.publish`. Leave it empty to create and update pages
-   only. Put the single word `prune` in it to also delete wiki pages that are
-   not in `wiki/`, so the wiki always equals the folder.
+2. Add Markdown pages to `docs/wiki/`. The file name is the page name: `Home.md`
+   is the home page. A hyphen in the name is a space in the page name:
+   `Home-da.md` is the page "Home da", and a link to it is `[Dansk](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/Home-da)`.
+3. Add a workflow, for example `.gitea/workflows/publish-wiki.yml`, that calls
+   the reusable workflow:
+
+   ```yaml
+   on:
+     push:
+       branches: [ main ]
+       paths: [ "docs/wiki/**" ]
+   jobs:
+     wiki:
+       uses: TirSystem/github-action/.gitea/workflows/publish-wiki-pages.yml@v1
+       with:
+         prune: "true"
+       secrets:
+         TOKEN_FOR_GITEA_WIKI: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
+   ```
+
+   `wiki_dir` defaults to `docs/wiki`. `prune: "true"` also deletes wiki pages
+   that are not in the folder, so the wiki always equals the folder; the
+   default `false` keeps them.
 4. Store `TOKEN_FOR_GITEA_WIKI` as a secret of the repository's organization,
    using the scope in [credentials.md](Credentials).
 5. Merge the change to `main`. The log must end with `Published <n> page(s) to
    the wiki of <owner>/<repo>`.
 
-A repository without `wiki/.publish` is skipped with the line `No
-wiki/.publish marker in <owner>/<repo>`: nothing is written and no secret is
-needed.
-
 ## Runners
 
 | Item | Value |

docs/wiki/Onboarding.ms.md

@@ -1,4 +1,4 @@
-<!-- translation of Onboarding.md, source sha256 1d431898754e -->
+<!-- translation of Onboarding.md, source sha256 1bc66efd5874 -->
 
 > Ini ialah terjemahan [`Onboarding`](Onboarding). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
 
@@ -32,16 +32,30 @@ Penghantaran adalah automatik, jadi repositori tidak memerlukan salinan aliran k
 
 ## Menerbitkan wiki (pilihan)
 
-Aliran kerja **Publish wiki** menyalin halaman Markdown dalam `wiki/` ke wiki repositori apabila perubahan pada `wiki/` digabungkan ke `main`. Ia dihantar seperti aliran kerja penyegerakan, tetapi hanya menulis di tempat repositori telah memilih untuk menyertainya.
+Aliran kerja boleh guna semula **Publish wiki pages** menyalin halaman Markdown dalam `docs/wiki/` ke wiki repositori apabila perubahan pada `docs/wiki/` digabungkan ke `main`. Repositori memanggilnya, jadi tiada apa-apa ditulis di tempat yang tiada panggilan. Wiki ada dalam bahasa Inggeris dan bahasa pemilik produk sekurang-kurangnya.
 
 1. Aktifkan wiki dalam tetapan repositori.
-2. Tambah halaman Markdown ke `wiki/`. Nama fail ialah nama halaman: `Home.md` ialah halaman utama.
-3. Tambah penanda `wiki/.publish`. Biarkan kosong untuk mencipta dan mengemas kini halaman sahaja. Letakkan satu perkataan `prune` di dalamnya untuk turut memadam halaman wiki yang tiada dalam `wiki/`, supaya wiki sentiasa sama dengan folder itu.
+2. Tambah halaman Markdown ke `docs/wiki/`. Nama fail ialah nama halaman: `Home.md` ialah halaman utama. Tanda sempang dalam nama ialah ruang dalam nama halaman: `Home-da.md` ialah halaman "Home da", dan pautan kepadanya ialah `[Dansk](Home-da)`.
+3. Tambah aliran kerja, contohnya `.gitea/workflows/publish-wiki.yml`, yang memanggil aliran kerja boleh guna semula:
+
+   ```yaml
+   on:
+     push:
+       branches: [ main ]
+       paths: [ "docs/wiki/**" ]
+   jobs:
+     wiki:
+       uses: TirSystem/github-action/.gitea/workflows/publish-wiki-pages.yml@v1
+       with:
+         prune: "true"
+       secrets:
+         TOKEN_FOR_GITEA_WIKI: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
+   ```
+
+   `wiki_dir` lalai ialah `docs/wiki`. `prune: "true"` turut memadam halaman wiki yang tiada dalam folder itu, supaya wiki sentiasa sama dengan folder; lalai `false` mengekalkannya.
 4. Simpan `TOKEN_FOR_GITEA_WIKI` sebagai secret organisasi repositori, dengan skop yang tertera dalam [credentials.md](Credentials.ms).
 5. Gabungkan perubahan ke `main`. Log mesti berakhir dengan `Published <n> page(s) to the wiki of <owner>/<repo>`.
 
-Repositori tanpa `wiki/.publish` dilangkau dengan baris `No wiki/.publish marker in <owner>/<repo>`: tiada apa-apa ditulis dan tiada secret diperlukan.
-
 ## Runners
 
 | Perkara | Nilai |

docs/wiki/QualityChecksCSharp.da.md

@@ -0,0 +1,85 @@
+<!-- translation of QualityChecksCSharp.md, source sha256 36e34031e0b9 -->
+
+> Dette er en oversættelse af [`QualityChecksCSharp`](QualityChecksCSharp). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
+
+[English](QualityChecksCSharp) | Dansk | [Bahasa Melayu](QualityChecksCSharp.ms)
+
+# Aflæsning af resultater fra kvalitetskontrol af C#
+
+Sådan kalder en softwareudvikler den fælles kvalitetskontrol af C#, aflæser en mislykket kørsel og får den til at bestå. Workflowet kontrollerer formateringen og bygger en solution eller et projekt med advarsler som fejl, på et præcist .NET SDK i version 10 eller nyere, ændrer ingen fil og kræver ingen secret. Dets kontrakt er ADR-0008 i dette repository.
+
+## Kald af workflowet
+
+```yaml
+name: Quality C#
+
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+
+jobs:
+  quality:
+    permissions:
+      contents: read
+    uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1
+    with:
+      project: src/App.sln
+```
+
+| Input | Standard | Betydning |
+| --- | --- | --- |
+| `working-directory` | `.` | Mappe, relativt til repositoryets rod, hvis filer kontrolleres |
+| `project` | tom | Solution- eller projektfil, relativt til `working-directory`; tom bruger den eneste sporede `*.sln` eller `*.slnx`, ellers den eneste `*.csproj`, der er sporet dér |
+| `dotnet-sdk-version` | `10.0.401` | Præcis version af .NET SDK, 10 eller nyere; en kanal som `10.0`, et interval og en version under 10 afvises |
+| `tools-ref` | `v1` | Tag eller gren i `TirSystem/github-action`, hvorfra scriptet `tools/quality-checks-csharp.sh` hentes |
+
+Henvis til workflowet ved major-tagget (`@v1`) eller et præcist tag, aldrig ved `main`. Et kald ved et præcist tag er kun fuldt fastlåst, når `tools-ref` angiver samme tag. Se opgraderingsvejledningen. SDK-versionen er præcis: at hæve standardværdien er en ny udgivelse af dette repository, ikke en stille ændring.
+
+## Hvad repositoryet skal have
+
+- En solution eller et projekt, der bygger med SDK'et. Flere kandidater kræver inputtet `project`; C#-filer uden solution eller projekt fejler med `[configuration]`.
+- Netværk: `dotnet format` og `dotnet build` gendanner projektets NuGet-pakker i kørslen.
+- Regler i `.editorconfig` (og de analysatorer, projektet slår til, for eksempel med `AnalysisLevel` og `EnforceCodeStyleInBuild`) afgør, hvad et fund er.
+
+## Hvad der kontrolleres
+
+| Filer | Værktøj | Hvad det melder |
+| --- | --- | --- |
+| solutionen eller projektet | `dotnet format --verify-no-changes` | formatering og stil, der afviger fra `.editorconfig` |
+| det samme | `dotnet build -warnaserror` | compiler- og analysatoradvarsler, som får bygningen til at fejle |
+
+Usporede filer kontrolleres ikke. Et repository uden `*.cs`-filer består med en bemærkning. Projektets tests køres ikke.
+
+## Aflæsning af en kørsel
+
+1. Åbn statuskontrollen på pull requesten og derefter jobbet `quality-checks-csharp`.
+2. Hvert værktøj har sin egen logggruppe. Begge kører, selv om det første fejlede, så én kørsel viser alle fund.
+3. Et værktøj ender med `PASS <værktøj>` eller `FAIL <værktøj>`; sidste linje i en mislykket kørsel nævner dem: `Quality checks failed: dotnet format --verify-no-changes`.
+4. Et fund skrives af værktøjet selv som `path(line,column): CODE message`. Stien er absolut i runnerens arbejdsområde (`/workspace/<owner>/<repo>/src/Program.cs(8,27)`).
+
+## Typiske fejl og rettelser
+
+| Værktøj | Hvad loggen viser | Rettelse |
+| --- | --- | --- |
+| `dotnet format --verify-no-changes` | `Program.cs(12,5): error WHITESPACE: Fix whitespace formatting` | Kør `dotnet format <projekt>`, og commit |
+| `dotnet build -warnaserror` | `CS8602: Dereference of a possibly null reference` | Ret koden (null-kontrol); undertryk ikke advarslen uden en begrundelse |
+| `dotnet build -warnaserror` | `IDE0005: Using directive is unnecessary` | Fjern direktivet |
+
+For at gentage en kørsel på din egen maskine skal du bruge samme SDK:
+
+```bash
+dotnet --version        # 10.0.401
+dotnet format src/App.sln --verify-no-changes
+dotnet build src/App.sln -warnaserror
+```
+
+## Når workflowet selv fejler
+
+| Meddelelse | Årsag | Rettelse |
+| --- | --- | --- |
+| `[configuration] dotnet-sdk-version '<x>' is not an exact stable version 10 or later` | En kanal, et interval, en preview eller en version under 10 | Angiv en præcis version som `10.0.401` |
+| `[configuration] working-directory must be a relative path inside the repository.` | En absolut sti eller `..` | Brug en sti inde i repositoryet |
+| `[configuration] C# files exist but no solution or project was found` | Repositoryet har `*.cs`-filer og ingen `*.sln`, `*.slnx` eller `*.csproj` i arbejdsmappen | Tilføj en, eller sæt `working-directory` |
+| `[configuration] Several solutions or projects were found` | Mere end én kandidat | Sæt inputtet `project` |
+| Installationstrinnet fejler | `dot.net` eller runnerens netværk kan ikke nås | Kør jobbet igen; se [troubleshooting.md](troubleshooting.md) |

docs/wiki/QualityChecksCSharp.md

@@ -0,0 +1,103 @@
+<!-- Generated from guides/quality-checks-csharp.md by tools/build_wiki.py. Edit the source, not this page. -->
+
+> This page is generated from [`guides/quality-checks-csharp.md`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/quality-checks-csharp.md). Changes made here are overwritten the next time the wiki is published.
+
+English | [Dansk](QualityChecksCSharp.da) | [Bahasa Melayu](QualityChecksCSharp.ms)
+
+# Reading C# quality-check results
+
+How a software engineer calls the shared C# quality checks, reads a failed run
+and makes it pass. The workflow checks the formatting and builds a solution or
+project with warnings as errors, on an exact .NET SDK of version 10 or later,
+changes no file and needs no secret. Its contract is ADR-0008 in this
+repository.
+
+## Calling the workflow
+
+```yaml
+name: Quality C#
+
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+
+jobs:
+  quality:
+    permissions:
+      contents: read
+    uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1
+    with:
+      project: src/App.sln
+```
+
+| Input | Default | Meaning |
+| --- | --- | --- |
+| `working-directory` | `.` | Directory, relative to the repository root, whose files are checked |
+| `project` | empty | Solution or project file, relative to `working-directory`; empty uses the single `*.sln` or `*.slnx`, else the single `*.csproj`, that is tracked there |
+| `dotnet-sdk-version` | `10.0.401` | Exact version of the .NET SDK, 10 or later; a channel such as `10.0`, a range and a version below 10 are refused |
+| `tools-ref` | `v1` | Tag or branch of `TirSystem/github-action` from which the script `tools/quality-checks-csharp.sh` is fetched |
+
+Reference the workflow at the major tag (`@v1`) or at an exact tag, never at
+`main`. A call at an exact tag is pinned completely only when `tools-ref` names
+the same tag. See the upgrade guide. The SDK version is exact: raising the
+default is a new release of this repository, not a silent change.
+
+## What the repository needs
+
+- A solution or project that builds with the SDK. Several candidates need the
+  `project` input; C# files with no solution or project fail with
+  `[configuration]`.
+- The network: `dotnet format` and `dotnet build` restore the NuGet packages of
+  the project in the run.
+- Rules in `.editorconfig` (and the analyzers the project enables, for example
+  with `AnalysisLevel` and `EnforceCodeStyleInBuild`) decide what a finding is.
+
+## What is checked
+
+| Files | Tool | What it reports |
+| --- | --- | --- |
+| the solution or project | `dotnet format --verify-no-changes` | formatting and style that differ from `.editorconfig` |
+| the same | `dotnet build -warnaserror` | compiler and analyzer warnings, which fail the build |
+
+Untracked files are not checked. A repository without `*.cs` files passes with
+a notice. Project tests are not run.
+
+## Reading a run
+
+1. Open the status check on the pull request, then the job
+   `quality-checks-csharp`.
+2. Each tool has its own log group. Both run even when the first failed, so one
+   run shows all findings.
+3. A tool ends with `PASS <tool>` or `FAIL <tool>`; the last line of a failed
+   run names them:
+   `Quality checks failed: dotnet format --verify-no-changes`.
+4. A finding is written by the tool itself as `path(line,column): CODE message`.
+   The path is absolute in the workspace of the runner
+   (`/workspace/<owner>/<repo>/src/Program.cs(8,27)`).
+
+## Typical failures and fixes
+
+| Tool | What the log shows | Fix |
+| --- | --- | --- |
+| `dotnet format --verify-no-changes` | `Program.cs(12,5): error WHITESPACE: Fix whitespace formatting` | Run `dotnet format <project>` and commit |
+| `dotnet build -warnaserror` | `CS8602: Dereference of a possibly null reference` | Fix the code (null check), do not suppress the warning without a reason |
+| `dotnet build -warnaserror` | `IDE0005: Using directive is unnecessary` | Remove the directive |
+
+To reproduce a run on your machine, use the same SDK:
+
+```bash
+dotnet --version        # 10.0.401
+dotnet format src/App.sln --verify-no-changes
+dotnet build src/App.sln -warnaserror
+```
+
+## When the workflow itself fails
+
+| Message | Cause | Fix |
+| --- | --- | --- |
+| `[configuration] dotnet-sdk-version '<x>' is not an exact stable version 10 or later` | A channel, a range, a preview or a version below 10 | Give an exact version such as `10.0.401` |
+| `[configuration] working-directory must be a relative path inside the repository.` | An absolute path or `..` | Use a path inside the repository |
+| `[configuration] C# files exist but no solution or project was found` | The repository has `*.cs` files and no `*.sln`, `*.slnx` or `*.csproj` in the working directory | Add one, or set `working-directory` |
+| `[configuration] Several solutions or projects were found` | More than one candidate | Set the input `project` |
+| The install step fails | `dot.net` or the runner network is unreachable | Re-run the job; see [troubleshooting.md](Troubleshooting) |

docs/wiki/QualityChecksCSharp.ms.md

@@ -0,0 +1,85 @@
+<!-- translation of QualityChecksCSharp.md, source sha256 36e34031e0b9 -->
+
+> Ini ialah terjemahan [`QualityChecksCSharp`](QualityChecksCSharp). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
+
+[English](QualityChecksCSharp) | [Dansk](QualityChecksCSharp.da) | Bahasa Melayu
+
+# Membaca keputusan semakan kualiti C#
+
+Cara seorang jurutera perisian memanggil semakan kualiti bersama untuk C#, membaca larian yang gagal dan menjadikannya lulus. Aliran kerja ini menyemak pemformatan dan membina solution atau projek dengan amaran sebagai ralat, pada .NET SDK versi 10 atau lebih baharu yang tepat, tidak mengubah sebarang fail dan tidak memerlukan secret. Kontraknya ialah ADR-0008 dalam repositori ini.
+
+## Memanggil aliran kerja
+
+```yaml
+name: Quality C#
+
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+
+jobs:
+  quality:
+    permissions:
+      contents: read
+    uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1
+    with:
+      project: src/App.sln
+```
+
+| Input | Lalai | Maksud |
+| --- | --- | --- |
+| `working-directory` | `.` | Direktori, relatif kepada akar repositori, yang failnya disemak |
+| `project` | kosong | Fail solution atau projek, relatif kepada `working-directory`; kosong menggunakan satu-satunya `*.sln` atau `*.slnx` yang dijejaki, jika tiada maka satu-satunya `*.csproj` yang dijejaki di situ |
+| `dotnet-sdk-version` | `10.0.401` | Versi tepat .NET SDK, 10 atau lebih baharu; saluran seperti `10.0`, julat dan versi di bawah 10 ditolak |
+| `tools-ref` | `v1` | Tag atau cabang `TirSystem/github-action` tempat skrip `tools/quality-checks-csharp.sh` diambil |
+
+Rujuk aliran kerja pada tag major (`@v1`) atau pada tag tepat, jangan sekali-kali pada `main`. Panggilan pada tag tepat hanya disematkan sepenuhnya apabila `tools-ref` menamakan tag yang sama. Lihat panduan naik taraf. Versi SDK adalah tepat: menaikkan nilai lalai ialah keluaran baharu repositori ini, bukan perubahan senyap.
+
+## Apa yang diperlukan oleh repositori
+
+- Satu solution atau projek yang boleh dibina dengan SDK. Beberapa calon memerlukan input `project`; fail C# tanpa solution atau projek gagal dengan `[configuration]`.
+- Rangkaian: `dotnet format` dan `dotnet build` memulihkan pakej NuGet projek dalam larian.
+- Peraturan dalam `.editorconfig` (dan penganalisis yang diaktifkan projek, contohnya dengan `AnalysisLevel` dan `EnforceCodeStyleInBuild`) menentukan apa yang dikira sebagai dapatan.
+
+## Apa yang disemak
+
+| Fail | Alat | Apa yang dilaporkan |
+| --- | --- | --- |
+| solution atau projek | `dotnet format --verify-no-changes` | pemformatan dan gaya yang berbeza daripada `.editorconfig` |
+| yang sama | `dotnet build -warnaserror` | amaran pengkompil dan penganalisis, yang menggagalkan binaan |
+
+Fail yang tidak dijejaki tidak disemak. Repositori tanpa fail `*.cs` lulus dengan satu notis. Ujian projek tidak dijalankan.
+
+## Membaca satu larian
+
+1. Buka semakan status pada pull request, kemudian kerja `quality-checks-csharp`.
+2. Setiap alat mempunyai kumpulan lognya sendiri. Kedua-duanya dijalankan walaupun yang pertama gagal, jadi satu larian menunjukkan semua dapatan.
+3. Satu alat berakhir dengan `PASS <alat>` atau `FAIL <alat>`; baris terakhir larian yang gagal menamakannya: `Quality checks failed: dotnet format --verify-no-changes`.
+4. Satu dapatan ditulis oleh alat itu sendiri sebagai `path(line,column): CODE message`. Laluan itu mutlak dalam ruang kerja runner (`/workspace/<owner>/<repo>/src/Program.cs(8,27)`).
+
+## Kegagalan biasa dan pembetulan
+
+| Alat | Apa yang ditunjukkan log | Pembetulan |
+| --- | --- | --- |
+| `dotnet format --verify-no-changes` | `Program.cs(12,5): error WHITESPACE: Fix whitespace formatting` | Jalankan `dotnet format <projek>` dan commit |
+| `dotnet build -warnaserror` | `CS8602: Dereference of a possibly null reference` | Betulkan kod (semakan null); jangan tindas amaran tanpa sebab |
+| `dotnet build -warnaserror` | `IDE0005: Using directive is unnecessary` | Buang arahan itu |
+
+Untuk mengulangi satu larian pada mesin anda, gunakan SDK yang sama:
+
+```bash
+dotnet --version        # 10.0.401
+dotnet format src/App.sln --verify-no-changes
+dotnet build src/App.sln -warnaserror
+```
+
+## Apabila aliran kerja itu sendiri gagal
+
+| Mesej | Punca | Pembetulan |
+| --- | --- | --- |
+| `[configuration] dotnet-sdk-version '<x>' is not an exact stable version 10 or later` | Saluran, julat, pratonton atau versi di bawah 10 | Berikan versi tepat seperti `10.0.401` |
+| `[configuration] working-directory must be a relative path inside the repository.` | Laluan mutlak atau `..` | Gunakan laluan di dalam repositori |
+| `[configuration] C# files exist but no solution or project was found` | Repositori mempunyai fail `*.cs` tetapi tiada `*.sln`, `*.slnx` atau `*.csproj` dalam direktori kerja | Tambah satu, atau tetapkan `working-directory` |
+| `[configuration] Several solutions or projects were found` | Lebih daripada satu calon | Tetapkan input `project` |
+| Langkah pemasangan gagal | `dot.net` atau rangkaian runner tidak dapat dicapai | Jalankan semula kerja; lihat [troubleshooting.md](troubleshooting.md) |

docs/wiki/QualityChecksCpp.da.md

@@ -0,0 +1,88 @@
+<!-- translation of QualityChecksCpp.md, source sha256 6faa57183a11 -->
+
+> Dette er en oversættelse af [`QualityChecksCpp`](QualityChecksCpp). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
+
+[English](QualityChecksCpp) | Dansk | [Bahasa Melayu](QualityChecksCpp.ms)
+
+# Aflæsning af resultater fra kvalitetskontrol af C og C++
+
+Sådan kalder en softwareudvikler den fælles kvalitetskontrol af C og C++, aflæser en mislykket kørsel og får den til at bestå. Workflowet formatkontrollerer og analyserer statisk repositoryets C- og C++-filer med clang-værktøjer i præcise versioner, ændrer ingen fil og kræver ingen secret. Dets kontrakt er ADR-0008 i dette repository.
+
+## Kald af workflowet
+
+```yaml
+name: Quality C++
+
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+
+jobs:
+  quality:
+    permissions:
+      contents: read
+    uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1
+    with:
+      std: c++20
+```
+
+| Input | Standard | Betydning |
+| --- | --- | --- |
+| `working-directory` | `.` | Mappe, relativt til repositoryets rod, hvis filer kontrolleres |
+| `std` | `c++20` | C++-standard, som clang-tidy får, når der ikke er en compile-database, for eksempel `c++17` eller `gnu++20` |
+| `compile-commands-dir` | tom | Mappe, relativt til repositoryets rod, med en `compile_commands.json`, som din pipeline har bygget før kaldet; når den er sat, bruger clang-tidy den og ignorerer `std` |
+| `clang-format-version` | `23.1.3` | Præcis version af pakken clang-format |
+| `clang-tidy-version` | `22.1.8` | Præcis version af pakken clang-tidy |
+| `tools-ref` | `v1` | Tag eller gren i `TirSystem/github-action`, hvorfra scriptet `tools/quality-checks-cpp.sh` hentes |
+
+Henvis til workflowet ved major-tagget (`@v1`) eller et præcist tag, aldrig ved `main`. Et kald ved et præcist tag er kun fuldt fastlåst, når `tools-ref` angiver samme tag. Se opgraderingsvejledningen. Værktøjsversionerne er præcise: en nyere version af et værktøj er en ny udgivelse af dette repository, ikke en stille ændring.
+
+## Hvad repositoryet skal have
+
+- En `.clang-format` i arbejdsmappen eller i en mappe over den, op til repositoryets rod. Uden en fejler kørslen med `[configuration]`, og intet værktøj kører.
+- Eventuelt en `.clang-tidy` med projektets kontroller (for eksempel C++ Core Guidelines). Uden en kører workflowet compilerdiagnostik og den statiske analysator (`clang-diagnostic-*` og `clang-analyzer-*`), fordi clang-tidy selv ikke aktiverer nogen kontrol uden konfiguration.
+- For præcise statiske kontroller en compile-database: byg den først (for eksempel `cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`) og angiv `compile-commands-dir: build`. Workflowet bygger ikke dit projekt.
+
+## Hvad der kontrolleres
+
+| Filer | Værktøj | Hvad det melder |
+| --- | --- | --- |
+| sporede `*.c`, `*.cc`, `*.cpp`, `*.cxx`, `*.h`, `*.hh`, `*.hpp`, `*.hxx` | `clang-format --dry-run -Werror` | formatering, der afviger fra `.clang-format` |
+| de samme filer | `clang-tidy` | fund fra kontrollerne i `.clang-tidy` (eller fra `clang-diagnostic-*` og `clang-analyzer-*` uden en); `*.c`-filer kontrolleres som C17, de øvrige filer som C++-standarden i `std`; hvert fund er en fejl (`--warnings-as-errors=*`), så en advarsel får kørslen til at fejle |
+
+Usporede filer kontrolleres ikke. Et repository uden disse filer består med en bemærkning. Der er ingen `cppcheck`: kun en gammel version findes som pakke, og gamle værktøjer køres ikke (ADR-0008).
+
+## Aflæsning af en kørsel
+
+1. Åbn statuskontrollen på pull requesten og derefter jobbet `quality-checks-cpp`.
+2. Hvert værktøj har sin egen logggruppe. Alle værktøjer kører, selv om et tidligere fejlede, så én kørsel viser alle fund.
+3. Et værktøj ender med `PASS <værktøj>` eller `FAIL <værktøj>`; sidste linje i en mislykket kørsel nævner dem: `Quality checks failed: clang-format`.
+4. Et fund skrives af værktøjet selv som `path:line:column: message`. `clang-format` skriver stier relative til `working-directory`; `clang-tidy` skriver absolutte stier i runnerens arbejdsområde (`/workspace/<owner>/<repo>/main.cpp:5:18`).
+
+## Typiske fejl og rettelser
+
+| Værktøj | Hvad loggen viser | Rettelse |
+| --- | --- | --- |
+| `clang-format` | `code should be clang-formatted [-Wclang-format-violations]` | Kør `clang-format -i <fil>` med samme version, og commit |
+| `clang-tidy` | `warning: ... [modernize-use-nullptr]` | Ret koden, eller slå kontrollen fra i `.clang-tidy` med en begrundelse |
+| `clang-tidy` | `error: 'x.h' file not found` | Byg compile-databasen og sæt `compile-commands-dir`, eller tilføj include-stien til den |
+
+For at gentage en kørsel på din egen maskine skal du installere de samme versioner:
+
+```bash
+python3 -m venv .qc
+.qc/bin/pip install clang-format==23.1.3 clang-tidy==22.1.8
+git ls-files '*.cpp' '*.hpp' | xargs .qc/bin/clang-format --dry-run -Werror
+```
+
+## Når workflowet selv fejler
+
+| Meddelelse | Årsag | Rettelse |
+| --- | --- | --- |
+| `[configuration] std '<x>' is not a C++ standard` | `std` er ikke som `c++20` eller `gnu++20` | Ret inputtet |
+| `[configuration] ... is not an exact version` | En værktøjsversion er et interval, en kanal eller tom | Angiv en præcis version som `23.1.3` |
+| `[configuration] working-directory must be a relative path inside the repository.` | En absolut sti eller `..` | Brug en sti inde i repositoryet |
+| `[configuration] No .clang-format found` | Projektet har ingen stilfil | Tilføj en `.clang-format` |
+| `[configuration] compile-commands-dir '<x>' has no compile_commands.json` | Databasen blev ikke bygget før kaldet | Byg den i et tidligere trin i jobbet eller i et job, det afhænger af |
+| Installationstrinnet fejler | PyPI eller runnerens netværk kan ikke nås | Kør jobbet igen; se [troubleshooting.md](troubleshooting.md) |

docs/wiki/QualityChecksCpp.md

@@ -0,0 +1,108 @@
+<!-- Generated from guides/quality-checks-cpp.md by tools/build_wiki.py. Edit the source, not this page. -->
+
+> This page is generated from [`guides/quality-checks-cpp.md`](https://git.tirsystem.com/TirSystem/github-action/src/branch/main/guides/quality-checks-cpp.md). Changes made here are overwritten the next time the wiki is published.
+
+English | [Dansk](QualityChecksCpp.da) | [Bahasa Melayu](QualityChecksCpp.ms)
+
+# Reading C and C++ quality-check results
+
+How a software engineer calls the shared C and C++ quality checks, reads a
+failed run and makes it pass. The workflow format-checks and statically checks
+the C and C++ files of a repository with clang tools at exact versions, changes
+no file and needs no secret. Its contract is ADR-0008 in this repository.
+
+## Calling the workflow
+
+```yaml
+name: Quality C++
+
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+
+jobs:
+  quality:
+    permissions:
+      contents: read
+    uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1
+    with:
+      std: c++20
+```
+
+| Input | Default | Meaning |
+| --- | --- | --- |
+| `working-directory` | `.` | Directory, relative to the repository root, whose files are checked |
+| `std` | `c++20` | C++ standard given to clang-tidy when there is no compile database, such as `c++17` or `gnu++20` |
+| `compile-commands-dir` | empty | Directory, relative to the repository root, with a `compile_commands.json` that your pipeline built before the call; when set, clang-tidy uses it and ignores `std` |
+| `clang-format-version` | `23.1.3` | Exact version of the clang-format package |
+| `clang-tidy-version` | `22.1.8` | Exact version of the clang-tidy package |
+| `tools-ref` | `v1` | Tag or branch of `TirSystem/github-action` from which the script `tools/quality-checks-cpp.sh` is fetched |
+
+Reference the workflow at the major tag (`@v1`) or at an exact tag, never at
+`main`. A call at an exact tag is pinned completely only when `tools-ref` names
+the same tag. See the upgrade guide. The tool versions are exact: a newer
+version of a tool is a new release of this repository, not a silent change.
+
+## What the repository needs
+
+- A `.clang-format` in the working directory or in a directory above it, up to
+  the top of the repository. Without one the run fails with `[configuration]`
+  and no tool runs.
+- Optionally a `.clang-tidy` with the checks of the project (for example the
+  C++ Core Guidelines). Without one the workflow runs the compiler diagnostics
+  and the static analyzer (`clang-diagnostic-*` and `clang-analyzer-*`),
+  because clang-tidy itself enables no check when there is no configuration.
+- For precise static checks, a compile database: build it first (for example
+  `cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`) and pass
+  `compile-commands-dir: build`. The workflow does not build your project.
+
+## What is checked
+
+| Files | Tool | What it reports |
+| --- | --- | --- |
+| tracked `*.c`, `*.cc`, `*.cpp`, `*.cxx`, `*.h`, `*.hh`, `*.hpp`, `*.hxx` | `clang-format --dry-run -Werror` | formatting that differs from `.clang-format` |
+| the same files | `clang-tidy` | findings of the checks of `.clang-tidy` (or of `clang-diagnostic-*` and `clang-analyzer-*` without one); `*.c` files are checked as C17, the other files as the C++ standard of `std`; every finding is an error (`--warnings-as-errors=*`), so a warning fails the run |
+
+Untracked files are not checked. A repository without these files passes with a
+notice. There is no `cppcheck`: only an old version of it is available as a
+package, and old tools are not run (ADR-0008).
+
+## Reading a run
+
+1. Open the status check on the pull request, then the job `quality-checks-cpp`.
+2. Each tool has its own log group. Every tool runs even when an earlier one
+   failed, so one run shows all findings.
+3. A tool ends with `PASS <tool>` or `FAIL <tool>`; the last line of a failed
+   run names them: `Quality checks failed: clang-format`.
+4. A finding is written by the tool itself as `path:line:column: message`.
+   `clang-format` prints paths relative to `working-directory`; `clang-tidy`
+   prints absolute paths in the workspace of the runner
+   (`/workspace/<owner>/<repo>/main.cpp:5:18`).
+
+## Typical failures and fixes
+
+| Tool | What the log shows | Fix |
+| --- | --- | --- |
+| `clang-format` | `code should be clang-formatted [-Wclang-format-violations]` | Run `clang-format -i <file>` with the same version and commit |
+| `clang-tidy` | `warning: ... [modernize-use-nullptr]` | Fix the code, or switch the check off in `.clang-tidy` with a reason |
+| `clang-tidy` | `error: 'x.h' file not found` | Build the compile database and set `compile-commands-dir`, or add the include path to it |
+
+To reproduce a run on your machine, install the same versions:
+
+```bash
+python3 -m venv .qc
+.qc/bin/pip install clang-format==23.1.3 clang-tidy==22.1.8
+git ls-files '*.cpp' '*.hpp' | xargs .qc/bin/clang-format --dry-run -Werror
+```
+
+## When the workflow itself fails
+
+| Message | Cause | Fix |
+| --- | --- | --- |
+| `[configuration] std '<x>' is not a C++ standard` | `std` is not like `c++20` or `gnu++20` | Correct the input |
+| `[configuration] ... is not an exact version` | A tool version is a range, a channel or empty | Give an exact version such as `23.1.3` |
+| `[configuration] working-directory must be a relative path inside the repository.` | An absolute path or `..` | Use a path inside the repository |
+| `[configuration] No .clang-format found` | The project has no style file | Add a `.clang-format` |
+| `[configuration] compile-commands-dir '<x>' has no compile_commands.json` | The database was not built before the call | Build it in an earlier step of the job or in a job it depends on |
+| The install step fails | PyPI or the runner network is unreachable | Re-run the job; see [troubleshooting.md](Troubleshooting) |

docs/wiki/QualityChecksCpp.ms.md

@@ -0,0 +1,88 @@
+<!-- translation of QualityChecksCpp.md, source sha256 6faa57183a11 -->
+
+> Ini ialah terjemahan [`QualityChecksCpp`](QualityChecksCpp). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
+
+[English](QualityChecksCpp) | [Dansk](QualityChecksCpp.da) | Bahasa Melayu
+
+# Membaca keputusan semakan kualiti C dan C++
+
+Cara seorang jurutera perisian memanggil semakan kualiti bersama untuk C dan C++, membaca larian yang gagal dan menjadikannya lulus. Aliran kerja ini menyemak format dan menganalisis secara statik fail C dan C++ sesebuah repositori dengan alat clang pada versi yang tepat, tidak mengubah sebarang fail dan tidak memerlukan secret. Kontraknya ialah ADR-0008 dalam repositori ini.
+
+## Memanggil aliran kerja
+
+```yaml
+name: Quality C++
+
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+
+jobs:
+  quality:
+    permissions:
+      contents: read
+    uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1
+    with:
+      std: c++20
+```
+
+| Input | Lalai | Maksud |
+| --- | --- | --- |
+| `working-directory` | `.` | Direktori, relatif kepada akar repositori, yang failnya disemak |
+| `std` | `c++20` | Piawaian C++ yang diberikan kepada clang-tidy apabila tiada pangkalan data kompilasi, seperti `c++17` atau `gnu++20` |
+| `compile-commands-dir` | kosong | Direktori, relatif kepada akar repositori, dengan `compile_commands.json` yang dibina oleh saluran paip anda sebelum panggilan; apabila ditetapkan, clang-tidy menggunakannya dan mengabaikan `std` |
+| `clang-format-version` | `23.1.3` | Versi tepat pakej clang-format |
+| `clang-tidy-version` | `22.1.8` | Versi tepat pakej clang-tidy |
+| `tools-ref` | `v1` | Tag atau cabang `TirSystem/github-action` tempat skrip `tools/quality-checks-cpp.sh` diambil |
+
+Rujuk aliran kerja pada tag major (`@v1`) atau pada tag tepat, jangan sekali-kali pada `main`. Panggilan pada tag tepat hanya disematkan sepenuhnya apabila `tools-ref` menamakan tag yang sama. Lihat panduan naik taraf. Versi alat adalah tepat: versi alat yang lebih baharu ialah keluaran baharu repositori ini, bukan perubahan senyap.
+
+## Apa yang diperlukan oleh repositori
+
+- Satu `.clang-format` dalam direktori kerja atau dalam direktori di atasnya, sehingga akar repositori. Tanpanya larian gagal dengan `[configuration]` dan tiada alat dijalankan.
+- Pilihan: satu `.clang-tidy` dengan semakan projek (contohnya C++ Core Guidelines). Tanpanya aliran kerja menjalankan diagnostik pengkompil dan penganalisis statik (`clang-diagnostic-*` dan `clang-analyzer-*`), kerana clang-tidy sendiri tidak mengaktifkan sebarang semakan tanpa konfigurasi.
+- Untuk semakan statik yang tepat, satu pangkalan data kompilasi: bina dahulu (contohnya `cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`) dan berikan `compile-commands-dir: build`. Aliran kerja tidak membina projek anda.
+
+## Apa yang disemak
+
+| Fail | Alat | Apa yang dilaporkan |
+| --- | --- | --- |
+| `*.c`, `*.cc`, `*.cpp`, `*.cxx`, `*.h`, `*.hh`, `*.hpp`, `*.hxx` yang dijejaki | `clang-format --dry-run -Werror` | pemformatan yang berbeza daripada `.clang-format` |
+| fail yang sama | `clang-tidy` | dapatan semakan dalam `.clang-tidy` (atau `clang-diagnostic-*` dan `clang-analyzer-*` tanpanya); fail `*.c` disemak sebagai C17, fail lain sebagai piawaian C++ dalam `std`; setiap dapatan ialah ralat (`--warnings-as-errors=*`), jadi amaran menggagalkan larian |
+
+Fail yang tidak dijejaki tidak disemak. Repositori tanpa fail ini lulus dengan satu notis. Tiada `cppcheck`: hanya versi lama tersedia sebagai pakej, dan alat lama tidak dijalankan (ADR-0008).
+
+## Membaca satu larian
+
+1. Buka semakan status pada pull request, kemudian kerja `quality-checks-cpp`.
+2. Setiap alat mempunyai kumpulan lognya sendiri. Setiap alat dijalankan walaupun yang terdahulu gagal, jadi satu larian menunjukkan semua dapatan.
+3. Satu alat berakhir dengan `PASS <alat>` atau `FAIL <alat>`; baris terakhir larian yang gagal menamakannya: `Quality checks failed: clang-format`.
+4. Satu dapatan ditulis oleh alat itu sendiri sebagai `path:line:column: message`. `clang-format` menulis laluan relatif kepada `working-directory`; `clang-tidy` menulis laluan mutlak dalam ruang kerja runner (`/workspace/<owner>/<repo>/main.cpp:5:18`).
+
+## Kegagalan biasa dan pembetulan
+
+| Alat | Apa yang ditunjukkan log | Pembetulan |
+| --- | --- | --- |
+| `clang-format` | `code should be clang-formatted [-Wclang-format-violations]` | Jalankan `clang-format -i <fail>` dengan versi yang sama dan commit |
+| `clang-tidy` | `warning: ... [modernize-use-nullptr]` | Betulkan kod, atau matikan semakan itu dalam `.clang-tidy` dengan sebab |
+| `clang-tidy` | `error: 'x.h' file not found` | Bina pangkalan data kompilasi dan tetapkan `compile-commands-dir`, atau tambah laluan include kepadanya |
+
+Untuk mengulangi satu larian pada mesin anda, pasang versi yang sama:
+
+```bash
+python3 -m venv .qc
+.qc/bin/pip install clang-format==23.1.3 clang-tidy==22.1.8
+git ls-files '*.cpp' '*.hpp' | xargs .qc/bin/clang-format --dry-run -Werror
+```
+
+## Apabila aliran kerja itu sendiri gagal
+
+| Mesej | Punca | Pembetulan |
+| --- | --- | --- |
+| `[configuration] std '<x>' is not a C++ standard` | `std` bukan seperti `c++20` atau `gnu++20` | Betulkan input |
+| `[configuration] ... is not an exact version` | Versi alat ialah julat, saluran atau kosong | Berikan versi tepat seperti `23.1.3` |
+| `[configuration] working-directory must be a relative path inside the repository.` | Laluan mutlak atau `..` | Gunakan laluan di dalam repositori |
+| `[configuration] No .clang-format found` | Projek tiada fail gaya | Tambah `.clang-format` |
+| `[configuration] compile-commands-dir '<x>' has no compile_commands.json` | Pangkalan data tidak dibina sebelum panggilan | Bina dalam langkah terdahulu kerja itu atau dalam kerja yang menjadi tanggungannya |
+| Langkah pemasangan gagal | PyPI atau rangkaian runner tidak dapat dicapai | Jalankan semula kerja; lihat [troubleshooting.md](troubleshooting.md) |

docs/wiki/Troubleshooting.da.md

@@ -1,4 +1,4 @@
-<!-- translation of Troubleshooting.md, source sha256 eb63f4109a0d -->
+<!-- translation of Troubleshooting.md, source sha256 cad6363616e8 -->
 
 > Dette er en oversættelse af [`Troubleshooting`](Troubleshooting). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
 
@@ -30,11 +30,12 @@ Kategorien fortæller, hvor du skal kigge. En fejl uden for scriptet (jobbet sta
 | `TOKEN_FOR_GITEA is missing or empty.` | configuration | Tilføj secreten |
 | `Could not determine the Gitea source repository.` | configuration | Kørslen har intet repositorynavn; meld det som en defekt |
 | `Expected at most one GitHub push mirror ... found N` | configuration | Behold ét GitHub push-spejl |
-| `TOKEN_FOR_GITEA_WIKI is missing or empty.` | configuration | Kun wiki-publicering: repositoryet har meldt sig til med `wiki/.publish`, men dets organisation har ingen sådan secret; gem den (se [credentials.md](Credentials.da)) |
-| `wiki/.publish may only be empty or contain the word 'prune'.` | configuration | Kun wiki-publicering: lad markøren være tom, eller skriv kun ordet `prune` i den |
+| `TOKEN_FOR_GITEA_WIKI is missing or empty.` | configuration | Kun wiki-publicering: repositoryet kalder workflowet, men dets organisation har ingen sådan secret, eller kaldet sender den ikke; gem den og send den i `secrets:` (se [credentials.md](Credentials.da)) |
+| `The prune input must be 'true' or 'false'` | configuration | Kun wiki-publicering: sæt `prune` i kaldet til `"true"` eller `"false"` |
+| `The wiki folder ... does not exist` | configuration | Kun wiki-publicering: sæt `wiki_dir` i kaldet til mappen med siderne (standard `docs/wiki`) |
 | `... HTTP 403 ...` ved publicering af wikien | permissions | Kun wiki-publicering: tokenet skal have `write:repository` og skriveadgang til dette repository |
 | `The wiki is not enabled on <repo>` | configuration | Kun wiki-publicering: aktivér wikien i repositoryets indstillinger |
-| `The wiki source directory ... has no Markdown pages` | configuration | Kun wiki-publicering: `wiki/` er tom eller mangler; intet blev ændret |
+| `The wiki source directory ... has no Markdown pages` | configuration | Kun wiki-publicering: mappen har ingen Markdown-sider; intet blev ændret |
 | `Could not determine the GitHub owner and repository ...` | configuration | Spejlets adresse skal se ud som `https://github.com/<owner>/<repo>.git` |
 | `Gitea API request failed with HTTP 401` | credentials | Opret et nyt Gitea-token, og opdatér `TOKEN_FOR_GITEA` |
 | `GitHub API request failed with HTTP 401` | credentials | Opret et nyt GitHub-token, og opdatér `PAT_FOR_GITHUB`; værdien skal kun være tokenet (intet navn, ingen anførselstegn eller JSON) |
@@ -51,9 +52,7 @@ Kategorien fortæller, hvor du skal kigge. En fejl uden for scriptet (jobbet sta
 
 `WARNING: Gitea returned an invalid push mirror list; GitHub metadata was not synced.` Kørslen lykkes, men intet blev synkroniseret. Kontroller, at Gitea-versionen understøtter push mirror-API'et, og kør igen.
 
-`No wiki/.publish marker in <owner>/<repo>; wiki publishing is not enabled for this repository.` Kørslen af Publish wiki lykkes og skriver intet. Repositoryet har ikke meldt sig til; tilføj `wiki/.publish`, hvis det skal publicere.
-
-`<n> page(s) are in the wiki but not in wiki/ and were kept; put the word 'prune' in wiki/.publish to delete them.` Kørslen lykkes. Sider, der kun findes i wikien, lades i fred, medmindre markøren indeholder `prune`.
+`<n> page(s) are in the wiki but not in <folder>/ and were kept; set the prune input to true to delete them.` Kørslen lykkes. Sider, der kun findes i wikien, lades i fred, medmindre kaldet sætter `prune: "true"`.
 
 ## Runner-problemer
 

docs/wiki/Troubleshooting.md

@@ -32,11 +32,12 @@ never starts, or stops before the step) is a **runner** problem.
 | `TOKEN_FOR_GITEA is missing or empty.` | configuration | Add the secret |
 | `Could not determine the Gitea source repository.` | configuration | The run has no repository name; report as a defect |
 | `Expected at most one GitHub push mirror ... found N` | configuration | Keep one GitHub push mirror |
-| `TOKEN_FOR_GITEA_WIKI is missing or empty.` | configuration | Wiki publishing only: the repository opted in with `wiki/.publish` but its organization has no such secret; store it (see [credentials.md](Credentials)) |
-| `wiki/.publish may only be empty or contain the word 'prune'.` | configuration | Wiki publishing only: leave the marker empty, or put only the word `prune` in it |
+| `TOKEN_FOR_GITEA_WIKI is missing or empty.` | configuration | Wiki publishing only: the repository calls the workflow but its organization has no such secret, or the call does not pass it; store it and pass it in `secrets:` (see [credentials.md](Credentials)) |
+| `The prune input must be 'true' or 'false'` | configuration | Wiki publishing only: set `prune` in the call to `"true"` or `"false"` |
+| `The wiki folder ... does not exist` | configuration | Wiki publishing only: set `wiki_dir` in the call to the folder with the pages (default `docs/wiki`) |
 | `... HTTP 403 ...` while publishing the wiki | permissions | Wiki publishing only: the token needs `write:repository` and write access to this repository |
 | `The wiki is not enabled on <repo>` | configuration | Wiki publishing only: enable the wiki in the repository settings |
-| `The wiki source directory ... has no Markdown pages` | configuration | Wiki publishing only: `wiki/` is empty or missing; nothing was changed |
+| `The wiki source directory ... has no Markdown pages` | configuration | Wiki publishing only: the folder has no Markdown pages; nothing was changed |
 | `Could not determine the GitHub owner and repository ...` | configuration | The mirror address must look like `https://github.com/<owner>/<repo>.git` |
 | `Gitea API request failed with HTTP 401` | credentials | Create a new Gitea token and update `TOKEN_FOR_GITEA` |
 | `GitHub API request failed with HTTP 401` | credentials | Create a new GitHub token and update `PAT_FOR_GITHUB`; the value must be the token only (no name, quotes or JSON) |
@@ -58,13 +59,9 @@ settings.
 synced.` The run succeeds but nothing was synced. Check that the Gitea
 version supports the push mirror API and re-run.
 
-`No wiki/.publish marker in <owner>/<repo>; wiki publishing is not enabled for
-this repository.` The Publish wiki run succeeds and writes nothing. The
-repository has not opted in; add `wiki/.publish` if it should publish.
-
-`<n> page(s) are in the wiki but not in wiki/ and were kept; put the word
-'prune' in wiki/.publish to delete them.` The run succeeds. Pages that exist
-only in the wiki are left alone unless the marker contains `prune`.
+`<n> page(s) are in the wiki but not in <folder>/ and were kept; set the prune
+input to true to delete them.` The run succeeds. Pages that exist only in the
+wiki are left alone unless the call sets `prune: "true"`.
 
 ## Runner problems
 

docs/wiki/Troubleshooting.ms.md

@@ -1,4 +1,4 @@
-<!-- translation of Troubleshooting.md, source sha256 eb63f4109a0d -->
+<!-- translation of Troubleshooting.md, source sha256 cad6363616e8 -->
 
 > Ini ialah terjemahan [`Troubleshooting`](Troubleshooting). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
 
@@ -30,11 +30,12 @@ Kategori menunjukkan di mana perlu dilihat. Kegagalan di luar skrip (kerja tidak
 | `TOKEN_FOR_GITEA is missing or empty.` | configuration | Tambah secret |
 | `Could not determine the Gitea source repository.` | configuration | Larian tiada nama repositori; laporkan sebagai kecacatan |
 | `Expected at most one GitHub push mirror ... found N` | configuration | Kekalkan satu push mirror GitHub |
-| `TOKEN_FOR_GITEA_WIKI is missing or empty.` | configuration | Penerbitan wiki sahaja: repositori telah memilih menyertainya dengan `wiki/.publish` tetapi organisasinya tiada secret itu; simpannya (lihat [credentials.md](Credentials.ms)) |
-| `wiki/.publish may only be empty or contain the word 'prune'.` | configuration | Penerbitan wiki sahaja: biarkan penanda kosong, atau letakkan hanya perkataan `prune` di dalamnya |
+| `TOKEN_FOR_GITEA_WIKI is missing or empty.` | configuration | Penerbitan wiki sahaja: repositori memanggil aliran kerja tetapi organisasinya tiada secret itu, atau panggilan tidak menghantarnya; simpannya dan hantar dalam `secrets:` (lihat [credentials.md](Credentials.ms)) |
+| `The prune input must be 'true' or 'false'` | configuration | Penerbitan wiki sahaja: tetapkan `prune` dalam panggilan kepada `"true"` atau `"false"` |
+| `The wiki folder ... does not exist` | configuration | Penerbitan wiki sahaja: tetapkan `wiki_dir` dalam panggilan kepada folder yang mengandungi halaman (lalai `docs/wiki`) |
 | `... HTTP 403 ...` semasa menerbitkan wiki | permissions | Penerbitan wiki sahaja: token memerlukan `write:repository` dan akses tulis kepada repositori ini |
 | `The wiki is not enabled on <repo>` | configuration | Penerbitan wiki sahaja: aktifkan wiki dalam tetapan repositori |
-| `The wiki source directory ... has no Markdown pages` | configuration | Penerbitan wiki sahaja: `wiki/` kosong atau tiada; tiada apa-apa diubah |
+| `The wiki source directory ... has no Markdown pages` | configuration | Penerbitan wiki sahaja: folder itu tiada halaman Markdown; tiada apa-apa diubah |
 | `Could not determine the GitHub owner and repository ...` | configuration | Alamat cermin mesti kelihatan seperti `https://github.com/<owner>/<repo>.git` |
 | `Gitea API request failed with HTTP 401` | credentials | Cipta token Gitea baharu dan kemas kini `TOKEN_FOR_GITEA` |
 | `GitHub API request failed with HTTP 401` | credentials | Cipta token GitHub baharu dan kemas kini `PAT_FOR_GITHUB`; nilai mesti token sahaja (tiada nama, tanda petikan atau JSON) |
@@ -51,9 +52,7 @@ Kategori menunjukkan di mana perlu dilihat. Kegagalan di luar skrip (kerja tidak
 
 `WARNING: Gitea returned an invalid push mirror list; GitHub metadata was not synced.` Larian berjaya tetapi tiada apa-apa disegerakkan. Semak bahawa versi Gitea menyokong API push mirror dan jalankan semula.
 
-`No wiki/.publish marker in <owner>/<repo>; wiki publishing is not enabled for this repository.` Larian Publish wiki berjaya dan tidak menulis apa-apa. Repositori belum memilih menyertainya; tambah `wiki/.publish` jika ia sepatutnya menerbitkan.
-
-`<n> page(s) are in the wiki but not in wiki/ and were kept; put the word 'prune' in wiki/.publish to delete them.` Larian berjaya. Halaman yang hanya ada dalam wiki dibiarkan melainkan penanda mengandungi `prune`.
+`<n> page(s) are in the wiki but not in <folder>/ and were kept; set the prune input to true to delete them.` Larian berjaya. Halaman yang hanya ada dalam wiki dibiarkan melainkan panggilan menetapkan `prune: "true"`.
 
 ## Masalah runner
 

docs/wiki/Upgrading.da.md

@@ -1,4 +1,4 @@
-<!-- translation of Upgrading.md, source sha256 3f119a1ab12d -->
+<!-- translation of Upgrading.md, source sha256 3233fa5bdab6 -->
 
 > Dette er en oversættelse af [`Upgrading`](Upgrading). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
 
@@ -18,9 +18,9 @@ Sådan tager en softwareudvikler en ny udgivelse af de fælles workflows i brug
 
 En udgivelse, der bryder kompatibiliteten, får en ny major-version (`v2`), så en pipeline på `@v1` aldrig modtager den, før du selv ændrer linjen.
 
-Kvalitetskontrol-workflowet henter sit script ved sit input `tools-ref`, som som standard er `v1`. For at fastlåse det helt skal du kalde det ved et præcist tag og sætte `tools-ref` til samme tag; ellers følger scriptet major-tagget.
+Kvalitetskontrol-workflowene (`quality-checks.yml`, `quality-checks-cpp.yml` og `quality-checks-csharp.yml`) og kodemålings-workflowet (`code-metrics.yml`) henter deres scripts ved deres input `tools-ref`, som som standard er `v1`. For at fastlåse et helt skal du kalde det ved et præcist tag og sætte `tools-ref` til samme tag; ellers følger scriptet major-tagget.
 
-De to scoped workflows (**Sync GitHub mirror metadata** og **Publish wiki**) leveres af instansen og står ikke i dine `uses:`-linjer; du kan ikke fastlåse dem, men de henter deres scripts ved major-tagget.
+Det scoped workflow **Sync GitHub mirror metadata** leveres af instansen og står ikke i dine `uses:`-linjer; du kan ikke fastlåse det, men det henter sit script ved major-tagget. Publicering af wiki er et genbrugeligt workflow, du kalder (`publish-wiki-pages.yml`); det scoped workflow **Publish wiki** og dets markør `wiki/.publish` blev fjernet i 2.0.0, så et repository, der stadig har markøren, publicerer ikke mere, før det kalder det genbrugelige workflow (se introduktionsguiden).
 
 ## Aflæsning af en changelog-post
 

docs/wiki/Upgrading.md

@@ -22,13 +22,18 @@ repository, tags `vMAJOR.MINOR.PATCH` and a moving major tag `vMAJOR`.
 A breaking release gets a new major version (`v2`), so a pipeline on `@v1`
 never receives it until you change the line yourself.
 
-The quality-checks workflow fetches its script at its input `tools-ref`, which
-defaults to `v1`. To pin it completely, call it at an exact tag and set
+The quality-checks workflows (`quality-checks.yml`, `quality-checks-cpp.yml` and
+`quality-checks-csharp.yml`) and the code-metrics workflow (`code-metrics.yml`)
+fetch their scripts at their input `tools-ref`, which defaults to `v1`. To pin one completely, call it at an exact tag and set
 `tools-ref` to the same tag; otherwise the script follows the major tag.
 
-The two scoped workflows (**Sync GitHub mirror metadata** and **Publish
-wiki**) are delivered by the instance and are not in your `uses:` lines; you
-cannot pin them, but they fetch their scripts at the major tag.
+The scoped workflow **Sync GitHub mirror metadata** is delivered by the
+instance and is not in your `uses:` lines; you cannot pin it, but it fetches its
+script at the major tag. Wiki publishing is a reusable workflow you call
+(`publish-wiki-pages.yml`); the scoped **Publish wiki** workflow and its
+`wiki/.publish` marker were removed in 2.0.0, so a repository that still has the
+marker no longer publishes until it calls the reusable workflow (see the
+onboarding guide).
 
 ## Reading a changelog entry
 

docs/wiki/Upgrading.ms.md

@@ -1,4 +1,4 @@
-<!-- translation of Upgrading.md, source sha256 3f119a1ab12d -->
+<!-- translation of Upgrading.md, source sha256 3233fa5bdab6 -->
 
 > Ini ialah terjemahan [`Upgrading`](Upgrading). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
 
@@ -18,9 +18,9 @@ Cara seorang jurutera perisian menerima keluaran baharu aliran kerja bersama den
 
 Keluaran yang memecahkan keserasian mendapat versi major baharu (`v2`), jadi saluran paip pada `@v1` tidak menerimanya sehingga anda sendiri menukar baris itu.
 
-Aliran kerja semakan kualiti mengambil skripnya pada inputnya `tools-ref`, yang lalai ialah `v1`. Untuk menyematkannya sepenuhnya, panggil pada tag tepat dan tetapkan `tools-ref` kepada tag yang sama; jika tidak, skrip mengikuti tag major.
+Aliran kerja semakan kualiti (`quality-checks.yml`, `quality-checks-cpp.yml` dan `quality-checks-csharp.yml`) dan aliran kerja metrik kod (`code-metrics.yml`) mengambil skripnya pada inputnya `tools-ref`, yang lalai ialah `v1`. Untuk menyematkan satu sepenuhnya, panggil pada tag tepat dan tetapkan `tools-ref` kepada tag yang sama; jika tidak, skrip mengikuti tag major.
 
-Dua aliran kerja scoped (**Sync GitHub mirror metadata** dan **Publish wiki**) dihantar oleh instans dan tidak terdapat dalam baris `uses:` anda; anda tidak boleh menyematkannya, tetapi ia mengambil skripnya pada tag major.
+Aliran kerja scoped **Sync GitHub mirror metadata** dihantar oleh instans dan tidak terdapat dalam baris `uses:` anda; anda tidak boleh menyematkannya, tetapi ia mengambil skripnya pada tag major. Penerbitan wiki ialah aliran kerja boleh guna semula yang anda panggil (`publish-wiki-pages.yml`); aliran kerja scoped **Publish wiki** dan penanda `wiki/.publish` telah dibuang dalam 2.0.0, jadi repositori yang masih mempunyai penanda itu tidak lagi menerbitkan sehingga ia memanggil aliran kerja boleh guna semula (lihat panduan permulaan).
 
 ## Membaca satu catatan changelog
 

docs/wiki/_Sidebar.md

@@ -9,6 +9,9 @@
 - [Credentials](Credentials)
 - [Troubleshooting](Troubleshooting)
 - [Quality checks (Python, shell)](QualityChecksPythonShell)
+- [Quality checks (C and C++)](QualityChecksCpp)
+- [Quality checks (C#)](QualityChecksCSharp)
+- [Code metrics](CodeMetrics)
 - [Upgrading](Upgrading)
 - [Capabilities](Capabilities)
 
@@ -19,6 +22,9 @@
 - [Credentials](Credentials.da)
 - [Fejlfinding](Troubleshooting.da)
 - [Kvalitetskontrol (Python, shell)](QualityChecksPythonShell.da)
+- [Kvalitetskontrol (C og C++)](QualityChecksCpp.da)
+- [Kvalitetskontrol (C#)](QualityChecksCSharp.da)
+- [Kodemålinger](CodeMetrics.da)
 - [Opgradering](Upgrading.da)
 - [Kapabiliteter](Capabilities.da)
 
@@ -29,5 +35,8 @@
 - [Kelayakan](Credentials.ms)
 - [Diagnosis](Troubleshooting.ms)
 - [Semakan kualiti (Python, shell)](QualityChecksPythonShell.ms)
+- [Semakan kualiti (C dan C++)](QualityChecksCpp.ms)
+- [Semakan kualiti (C#)](QualityChecksCSharp.ms)
+- [Metrik kod](CodeMetrics.ms)
 - [Menaik taraf](Upgrading.ms)
 - [Keupayaan](Capabilities.ms)

guides/code-metrics.md

@@ -0,0 +1,117 @@
+# Showing code metrics and coverage badges
+
+How a software engineer calls the shared code-metrics workflow and shows its
+three badges (code files, lines of code and coverage) in a README. The workflow
+counts the code of the repository, reads a coverage report that the caller
+supplies and commits three SVG files to a `badges` branch. It runs no test and
+needs no secret. Its contract is ADR-0010 in this repository.
+
+## Calling the workflow
+
+The workflow cannot see the files of your test job, so the tests run in a job of
+your own, upload the Cobertura XML report as an artifact, and the metrics job
+runs after it:
+
+```yaml
+name: Code metrics
+
+on:
+  push:
+    branches: [ main ]
+
+jobs:
+  tests:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4.2.2
+      - run: python3 -m pip install pytest pytest-cov && python3 -m pytest --cov --cov-report=xml
+      - uses: actions/upload-artifact@v4.6.2
+        with:
+          name: coverage
+          path: coverage.xml
+
+  metrics:
+    needs: tests
+    permissions:
+      contents: write
+    uses: TirSystem/github-action/.gitea/workflows/code-metrics.yml@v1
+    with:
+      coverage-artifact: coverage
+      coverage-report: coverage.xml
+```
+
+| Input | Default | Meaning |
+| --- | --- | --- |
+| `working-directory` | `.` | Directory, relative to the repository root, whose code is counted |
+| `exclude` | empty | Comma list of patterns of files and directories that are not counted, in addition to the defaults; a pattern without `/` matches a name anywhere, a pattern with `/` matches the path below `working-directory` |
+| `coverage-report` | empty | Cobertura XML report: the file inside the artifact when `coverage-artifact` is set, otherwise a path in the repository; empty writes no coverage badge |
+| `coverage-artifact` | empty | Name of an artifact, uploaded by an earlier job of the same run, that holds the report |
+| `coverage-warn` | `60` | Coverage in percent below which the badge is red |
+| `coverage-good` | `80` | Coverage in percent from which the badge is green; in between it is yellow |
+| `badges-branch` | `badges` | Branch that holds the badge files; it is created when it does not exist |
+| `tools-ref` | `v1` | Tag or branch of `TirSystem/github-action` from which the scripts in `tools/` are fetched |
+
+Reference the workflow at the major tag (`@v1`) or at an exact tag, never at
+`main`. A call at an exact tag is pinned completely only when `tools-ref` names
+the same tag. See the upgrade guide. Start the workflow on pushes to your
+default branch only: the badge commit carries `[skip ci]` and is made with the
+token of the run, which does not start another run, but a trigger on every
+branch would write one commit per branch.
+
+## What is counted
+
+- A code file is a text file with the extension of a supported language:
+  Python, shell, PowerShell, C, C++, C#, Java, JavaScript, TypeScript, Go, Rust
+  and SQL. Markdown, YAML, JSON, XML, HTML and CSS are not code files.
+- Every line is exactly one of blank (only white space), comment (only comment
+  text) or code (everything else, including a line with code and a trailing
+  comment). The badge shows the lines of code only.
+- A comment marker inside a string is not a comment, and a Python docstring is a
+  string, so it counts as code.
+- Directories that start with a dot and `node_modules`, `vendor`, `third_party`,
+  `dist`, `build`, `out`, `bin`, `obj`, `target`, `venv`, `__pycache__` and
+  `shared-scripts` are not counted. Generated code is excluded with `exclude`.
+- Raw and verbatim strings that differ from an ordinary string (Rust `r#"..."#`,
+  C# `@"..."`, C++ raw strings) can be counted wrongly. The counts will differ
+  a little from other tools; the rules are the same on every run.
+
+## The coverage badge
+
+The report is a Cobertura XML file, which `coverage.py` (`coverage xml`),
+`gcovr` (`--cobertura`) and `coverlet` (`cobertura` format) write. The badge
+shows `lines-covered` over `lines-valid`, rounded to a whole percent, and its
+colour follows the two thresholds. A report that does not exist, is not
+well-formed Cobertura XML or has no valid lines fails the run with the file
+named; the coverage badge is never written as `0%` for a bad report. Without
+`coverage-report` the run passes with a notice and no coverage badge.
+
+## Showing the badges
+
+Add the images to the README with the raw URLs of the branch:
+
+```markdown
+![code files](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/code-files.svg)
+![lines of code](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/code-lines.svg)
+![coverage](https://git.tirsystem.com/OWNER/REPO/raw/branch/badges/coverage.svg)
+```
+
+On the GitHub mirror use `https://raw.githubusercontent.com/OWNER/REPO/badges/code-files.svg`;
+the push mirror copies the branch. The `badges` branch also holds
+`code-metrics.json` with the numbers per language. The instance caches a raw
+file for up to six hours, so a changed badge can show the old number for a
+while there; the mirror caches for five minutes. A private repository does not
+show the badges to a reader who is not signed in.
+
+## When the workflow fails
+
+| Message | Cause | Fix |
+| --- | --- | --- |
+| `[configuration] working-directory must be a relative path inside the repository.` | An absolute path or `..` | Use a path inside the repository |
+| `[configuration] coverage-report '<x>' does not exist.` | The report was not produced, or the artifact name or path is wrong | Check the test job and the artifact name; the path is inside the artifact |
+| `[configuration] coverage-report '<x>' is not well-formed XML` or `is not a Cobertura report` | The file is another format | Write Cobertura XML (`coverage xml`, `gcovr --cobertura`) |
+| `[configuration] coverage-report '<x>' has no valid lines.` | The tests ran no measured code | Check the coverage configuration |
+| `[configuration] coverage-artifact '<x>' needs coverage-report` | The artifact is named but not the file in it | Set `coverage-report` |
+| `[configuration] coverage-warn ... is above coverage-good` or `is not a number from 0 to 100` | A threshold is invalid | Correct the input |
+| `[configuration] badges-branch '<x>' must not be a default branch` or `holds files that are not badge files` | The branch name is `main`, `master` or a branch with other content | Use a branch that holds only the badges |
+| `the push to '<x>' failed twice` | Another run wrote the branch at the same time, or the token cannot write | Re-run; check that the job has `contents: write` |
+| The download step fails | The artifact does not exist in this run, or the job does not run after the test job | Add `needs:` and check the artifact name |

guides/credentials.md

@@ -82,29 +82,30 @@ is ever printed.
 
 ## Wiki publishing secret
 
-The workflow **Publish wiki** copies `wiki/` to the Gitea wiki of a repository
-that has opted in with `wiki/.publish` (see [onboarding.md](onboarding.md)). It
-uses its own secret, so the metadata sync token stays read-only.
+The workflow **Publish wiki pages** copies `docs/wiki/` to the Gitea wiki of a
+repository that calls it (see [onboarding.md](onboarding.md)). It uses its own
+secret, so the metadata sync token stays read-only. The caller passes the
+secret in `secrets:`; it is not inherited.
 
 | Secret | Content | Used for |
 | --- | --- | --- |
 | `TOKEN_FOR_GITEA_WIKI` | The Gitea token, nothing else | Writing the wiki pages of the repositories of an organization that opt in |
 
 - Store it as a secret of the organization of each repository that publishes.
-  There is no fallback to `TOKEN_FOR_GITEA`: a repository that opted in and has
-  no such secret fails with a configuration error, and a repository that did
-  not opt in does not need it.
+  There is no fallback to `TOKEN_FOR_GITEA`: a repository that calls the
+  workflow and has no such secret fails with a configuration error, and a
+  repository that does not call it does not need it.
 - The token needs scope `write:repository`, and its user needs write access to
   the repositories. Gitea has no wiki-only scope, so create the token for a
   dedicated user. S05 approves the scope and S03 stores the secret.
 - Calls made: `GET /repos/{owner}/{repo}`, `GET /repos/{owner}/{repo}/wiki/pages`,
   `GET`, `POST` and `PATCH /repos/{owner}/{repo}/wiki/...` and, for a page that
-  no longer exists in `wiki/`, `DELETE /repos/{owner}/{repo}/wiki/page/{name}`.
+  no longer exists in `docs/wiki/`, `DELETE /repos/{owner}/{repo}/wiki/page/{name}`.
 - The wiki must be enabled in the repository settings. The workflow refuses to
   run when it is not.
-- Pages that are in `wiki/` are always overwritten from it, so a change made
-  in the Gitea web UI is lost on the next publish. Pages that are only in the
-  wiki are removed only when `wiki/.publish` contains the word `prune`.
+- Pages that are in `docs/wiki/` are always overwritten from it, so a change
+  made in the Gitea web UI is lost on the next publish. Pages that are only in
+  the wiki are removed only when the call sets `prune: "true"`.
 
 ## Rotating a token
 

guides/onboarding.md

@@ -45,25 +45,40 @@ Delivery is automatic, so a repository needs no copy of the workflow. Secrets ar
 
 ## Publish a wiki (optional)
 
-The **Publish wiki** workflow copies the Markdown pages in `wiki/` to the
-repository wiki when a change to `wiki/` is merged to `main`. It is delivered
-like the sync workflow, but it writes only where a repository opts in.
+The reusable workflow **Publish wiki pages** copies the Markdown pages in
+`docs/wiki/` to the repository wiki when a change to `docs/wiki/` is merged to
+`main`. The repository calls it, so nothing is written where no call exists.
+The wiki has English and the product owner's language as a minimum.
 
 1. Enable the wiki in the repository settings.
-2. Add Markdown pages to `wiki/`. The file name is the page name: `Home.md` is
-   the home page.
-3. Add the marker `wiki/.publish`. Leave it empty to create and update pages
-   only. Put the single word `prune` in it to also delete wiki pages that are
-   not in `wiki/`, so the wiki always equals the folder.
+2. Add Markdown pages to `docs/wiki/`. The file name is the page name: `Home.md`
+   is the home page. A hyphen in the name is a space in the page name:
+   `Home-da.md` is the page "Home da", and a link to it is `[Dansk](Home-da)`.
+3. Add a workflow, for example `.gitea/workflows/publish-wiki.yml`, that calls
+   the reusable workflow:
+
+   ```yaml
+   on:
+     push:
+       branches: [ main ]
+       paths: [ "docs/wiki/**" ]
+   jobs:
+     wiki:
+       uses: TirSystem/github-action/.gitea/workflows/publish-wiki-pages.yml@v1
+       with:
+         prune: "true"
+       secrets:
+         TOKEN_FOR_GITEA_WIKI: ${{ secrets.TOKEN_FOR_GITEA_WIKI }}
+   ```
+
+   `wiki_dir` defaults to `docs/wiki`. `prune: "true"` also deletes wiki pages
+   that are not in the folder, so the wiki always equals the folder; the
+   default `false` keeps them.
 4. Store `TOKEN_FOR_GITEA_WIKI` as a secret of the repository's organization,
    using the scope in [credentials.md](credentials.md).
 5. Merge the change to `main`. The log must end with `Published <n> page(s) to
    the wiki of <owner>/<repo>`.
 
-A repository without `wiki/.publish` is skipped with the line `No
-wiki/.publish marker in <owner>/<repo>`: nothing is written and no secret is
-needed.
-
 ## Runners
 
 | Item | Value |

guides/quality-checks-cpp.md

@@ -0,0 +1,102 @@
+# Reading C and C++ quality-check results
+
+How a software engineer calls the shared C and C++ quality checks, reads a
+failed run and makes it pass. The workflow format-checks and statically checks
+the C and C++ files of a repository with clang tools at exact versions, changes
+no file and needs no secret. Its contract is ADR-0008 in this repository.
+
+## Calling the workflow
+
+```yaml
+name: Quality C++
+
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+
+jobs:
+  quality:
+    permissions:
+      contents: read
+    uses: TirSystem/github-action/.gitea/workflows/quality-checks-cpp.yml@v1
+    with:
+      std: c++20
+```
+
+| Input | Default | Meaning |
+| --- | --- | --- |
+| `working-directory` | `.` | Directory, relative to the repository root, whose files are checked |
+| `std` | `c++20` | C++ standard given to clang-tidy when there is no compile database, such as `c++17` or `gnu++20` |
+| `compile-commands-dir` | empty | Directory, relative to the repository root, with a `compile_commands.json` that your pipeline built before the call; when set, clang-tidy uses it and ignores `std` |
+| `clang-format-version` | `23.1.3` | Exact version of the clang-format package |
+| `clang-tidy-version` | `22.1.8` | Exact version of the clang-tidy package |
+| `tools-ref` | `v1` | Tag or branch of `TirSystem/github-action` from which the script `tools/quality-checks-cpp.sh` is fetched |
+
+Reference the workflow at the major tag (`@v1`) or at an exact tag, never at
+`main`. A call at an exact tag is pinned completely only when `tools-ref` names
+the same tag. See the upgrade guide. The tool versions are exact: a newer
+version of a tool is a new release of this repository, not a silent change.
+
+## What the repository needs
+
+- A `.clang-format` in the working directory or in a directory above it, up to
+  the top of the repository. Without one the run fails with `[configuration]`
+  and no tool runs.
+- Optionally a `.clang-tidy` with the checks of the project (for example the
+  C++ Core Guidelines). Without one the workflow runs the compiler diagnostics
+  and the static analyzer (`clang-diagnostic-*` and `clang-analyzer-*`),
+  because clang-tidy itself enables no check when there is no configuration.
+- For precise static checks, a compile database: build it first (for example
+  `cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`) and pass
+  `compile-commands-dir: build`. The workflow does not build your project.
+
+## What is checked
+
+| Files | Tool | What it reports |
+| --- | --- | --- |
+| tracked `*.c`, `*.cc`, `*.cpp`, `*.cxx`, `*.h`, `*.hh`, `*.hpp`, `*.hxx` | `clang-format --dry-run -Werror` | formatting that differs from `.clang-format` |
+| the same files | `clang-tidy` | findings of the checks of `.clang-tidy` (or of `clang-diagnostic-*` and `clang-analyzer-*` without one); `*.c` files are checked as C17, the other files as the C++ standard of `std`; every finding is an error (`--warnings-as-errors=*`), so a warning fails the run |
+
+Untracked files are not checked. A repository without these files passes with a
+notice. There is no `cppcheck`: only an old version of it is available as a
+package, and old tools are not run (ADR-0008).
+
+## Reading a run
+
+1. Open the status check on the pull request, then the job `quality-checks-cpp`.
+2. Each tool has its own log group. Every tool runs even when an earlier one
+   failed, so one run shows all findings.
+3. A tool ends with `PASS <tool>` or `FAIL <tool>`; the last line of a failed
+   run names them: `Quality checks failed: clang-format`.
+4. A finding is written by the tool itself as `path:line:column: message`.
+   `clang-format` prints paths relative to `working-directory`; `clang-tidy`
+   prints absolute paths in the workspace of the runner
+   (`/workspace/<owner>/<repo>/main.cpp:5:18`).
+
+## Typical failures and fixes
+
+| Tool | What the log shows | Fix |
+| --- | --- | --- |
+| `clang-format` | `code should be clang-formatted [-Wclang-format-violations]` | Run `clang-format -i <file>` with the same version and commit |
+| `clang-tidy` | `warning: ... [modernize-use-nullptr]` | Fix the code, or switch the check off in `.clang-tidy` with a reason |
+| `clang-tidy` | `error: 'x.h' file not found` | Build the compile database and set `compile-commands-dir`, or add the include path to it |
+
+To reproduce a run on your machine, install the same versions:
+
+```bash
+python3 -m venv .qc
+.qc/bin/pip install clang-format==23.1.3 clang-tidy==22.1.8
+git ls-files '*.cpp' '*.hpp' | xargs .qc/bin/clang-format --dry-run -Werror
+```
+
+## When the workflow itself fails
+
+| Message | Cause | Fix |
+| --- | --- | --- |
+| `[configuration] std '<x>' is not a C++ standard` | `std` is not like `c++20` or `gnu++20` | Correct the input |
+| `[configuration] ... is not an exact version` | A tool version is a range, a channel or empty | Give an exact version such as `23.1.3` |
+| `[configuration] working-directory must be a relative path inside the repository.` | An absolute path or `..` | Use a path inside the repository |
+| `[configuration] No .clang-format found` | The project has no style file | Add a `.clang-format` |
+| `[configuration] compile-commands-dir '<x>' has no compile_commands.json` | The database was not built before the call | Build it in an earlier step of the job or in a job it depends on |
+| The install step fails | PyPI or the runner network is unreachable | Re-run the job; see [troubleshooting.md](troubleshooting.md) |

guides/quality-checks-csharp.md

@@ -0,0 +1,97 @@
+# Reading C# quality-check results
+
+How a software engineer calls the shared C# quality checks, reads a failed run
+and makes it pass. The workflow checks the formatting and builds a solution or
+project with warnings as errors, on an exact .NET SDK of version 10 or later,
+changes no file and needs no secret. Its contract is ADR-0008 in this
+repository.
+
+## Calling the workflow
+
+```yaml
+name: Quality C#
+
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+
+jobs:
+  quality:
+    permissions:
+      contents: read
+    uses: TirSystem/github-action/.gitea/workflows/quality-checks-csharp.yml@v1
+    with:
+      project: src/App.sln
+```
+
+| Input | Default | Meaning |
+| --- | --- | --- |
+| `working-directory` | `.` | Directory, relative to the repository root, whose files are checked |
+| `project` | empty | Solution or project file, relative to `working-directory`; empty uses the single `*.sln` or `*.slnx`, else the single `*.csproj`, that is tracked there |
+| `dotnet-sdk-version` | `10.0.401` | Exact version of the .NET SDK, 10 or later; a channel such as `10.0`, a range and a version below 10 are refused |
+| `tools-ref` | `v1` | Tag or branch of `TirSystem/github-action` from which the script `tools/quality-checks-csharp.sh` is fetched |
+
+Reference the workflow at the major tag (`@v1`) or at an exact tag, never at
+`main`. A call at an exact tag is pinned completely only when `tools-ref` names
+the same tag. See the upgrade guide. The SDK version is exact: raising the
+default is a new release of this repository, not a silent change.
+
+## What the repository needs
+
+- A solution or project that builds with the SDK. Several candidates need the
+  `project` input; C# files with no solution or project fail with
+  `[configuration]`.
+- The network: `dotnet format` and `dotnet build` restore the NuGet packages of
+  the project in the run.
+- Rules in `.editorconfig` (and the analyzers the project enables, for example
+  with `AnalysisLevel` and `EnforceCodeStyleInBuild`) decide what a finding is.
+
+## What is checked
+
+| Files | Tool | What it reports |
+| --- | --- | --- |
+| the solution or project | `dotnet format --verify-no-changes` | formatting and style that differ from `.editorconfig` |
+| the same | `dotnet build -warnaserror` | compiler and analyzer warnings, which fail the build |
+
+Untracked files are not checked. A repository without `*.cs` files passes with
+a notice. Project tests are not run.
+
+## Reading a run
+
+1. Open the status check on the pull request, then the job
+   `quality-checks-csharp`.
+2. Each tool has its own log group. Both run even when the first failed, so one
+   run shows all findings.
+3. A tool ends with `PASS <tool>` or `FAIL <tool>`; the last line of a failed
+   run names them:
+   `Quality checks failed: dotnet format --verify-no-changes`.
+4. A finding is written by the tool itself as `path(line,column): CODE message`.
+   The path is absolute in the workspace of the runner
+   (`/workspace/<owner>/<repo>/src/Program.cs(8,27)`).
+
+## Typical failures and fixes
+
+| Tool | What the log shows | Fix |
+| --- | --- | --- |
+| `dotnet format --verify-no-changes` | `Program.cs(12,5): error WHITESPACE: Fix whitespace formatting` | Run `dotnet format <project>` and commit |
+| `dotnet build -warnaserror` | `CS8602: Dereference of a possibly null reference` | Fix the code (null check), do not suppress the warning without a reason |
+| `dotnet build -warnaserror` | `IDE0005: Using directive is unnecessary` | Remove the directive |
+
+To reproduce a run on your machine, use the same SDK:
+
+```bash
+dotnet --version        # 10.0.401
+dotnet format src/App.sln --verify-no-changes
+dotnet build src/App.sln -warnaserror
+```
+
+## When the workflow itself fails
+
+| Message | Cause | Fix |
+| --- | --- | --- |
+| `[configuration] dotnet-sdk-version '<x>' is not an exact stable version 10 or later` | A channel, a range, a preview or a version below 10 | Give an exact version such as `10.0.401` |
+| `[configuration] working-directory must be a relative path inside the repository.` | An absolute path or `..` | Use a path inside the repository |
+| `[configuration] C# files exist but no solution or project was found` | The repository has `*.cs` files and no `*.sln`, `*.slnx` or `*.csproj` in the working directory | Add one, or set `working-directory` |
+| `[configuration] Several solutions or projects were found` | More than one candidate | Set the input `project` |
+| The install step fails | `dot.net` or the runner network is unreachable | Re-run the job; see [troubleshooting.md](troubleshooting.md) |

guides/troubleshooting.md

@@ -26,11 +26,12 @@ never starts, or stops before the step) is a **runner** problem.
 | `TOKEN_FOR_GITEA is missing or empty.` | configuration | Add the secret |
 | `Could not determine the Gitea source repository.` | configuration | The run has no repository name; report as a defect |
 | `Expected at most one GitHub push mirror ... found N` | configuration | Keep one GitHub push mirror |
-| `TOKEN_FOR_GITEA_WIKI is missing or empty.` | configuration | Wiki publishing only: the repository opted in with `wiki/.publish` but its organization has no such secret; store it (see [credentials.md](credentials.md)) |
-| `wiki/.publish may only be empty or contain the word 'prune'.` | configuration | Wiki publishing only: leave the marker empty, or put only the word `prune` in it |
+| `TOKEN_FOR_GITEA_WIKI is missing or empty.` | configuration | Wiki publishing only: the repository calls the workflow but its organization has no such secret, or the call does not pass it; store it and pass it in `secrets:` (see [credentials.md](credentials.md)) |
+| `The prune input must be 'true' or 'false'` | configuration | Wiki publishing only: set `prune` in the call to `"true"` or `"false"` |
+| `The wiki folder ... does not exist` | configuration | Wiki publishing only: set `wiki_dir` in the call to the folder with the pages (default `docs/wiki`) |
 | `... HTTP 403 ...` while publishing the wiki | permissions | Wiki publishing only: the token needs `write:repository` and write access to this repository |
 | `The wiki is not enabled on <repo>` | configuration | Wiki publishing only: enable the wiki in the repository settings |
-| `The wiki source directory ... has no Markdown pages` | configuration | Wiki publishing only: `wiki/` is empty or missing; nothing was changed |
+| `The wiki source directory ... has no Markdown pages` | configuration | Wiki publishing only: the folder has no Markdown pages; nothing was changed |
 | `Could not determine the GitHub owner and repository ...` | configuration | The mirror address must look like `https://github.com/<owner>/<repo>.git` |
 | `Gitea API request failed with HTTP 401` | credentials | Create a new Gitea token and update `TOKEN_FOR_GITEA` |
 | `GitHub API request failed with HTTP 401` | credentials | Create a new GitHub token and update `PAT_FOR_GITHUB`; the value must be the token only (no name, quotes or JSON) |
@@ -52,13 +53,9 @@ settings.
 synced.` The run succeeds but nothing was synced. Check that the Gitea
 version supports the push mirror API and re-run.
 
-`No wiki/.publish marker in <owner>/<repo>; wiki publishing is not enabled for
-this repository.` The Publish wiki run succeeds and writes nothing. The
-repository has not opted in; add `wiki/.publish` if it should publish.
-
-`<n> page(s) are in the wiki but not in wiki/ and were kept; put the word
-'prune' in wiki/.publish to delete them.` The run succeeds. Pages that exist
-only in the wiki are left alone unless the marker contains `prune`.
+`<n> page(s) are in the wiki but not in <folder>/ and were kept; set the prune
+input to true to delete them.` The run succeeds. Pages that exist only in the
+wiki are left alone unless the call sets `prune: "true"`.
 
 ## Runner problems
 

guides/upgrading.md

@@ -16,13 +16,18 @@ repository, tags `vMAJOR.MINOR.PATCH` and a moving major tag `vMAJOR`.
 A breaking release gets a new major version (`v2`), so a pipeline on `@v1`
 never receives it until you change the line yourself.
 
-The quality-checks workflow fetches its script at its input `tools-ref`, which
-defaults to `v1`. To pin it completely, call it at an exact tag and set
+The quality-checks workflows (`quality-checks.yml`, `quality-checks-cpp.yml` and
+`quality-checks-csharp.yml`) and the code-metrics workflow (`code-metrics.yml`)
+fetch their scripts at their input `tools-ref`, which defaults to `v1`. To pin one completely, call it at an exact tag and set
 `tools-ref` to the same tag; otherwise the script follows the major tag.
 
-The two scoped workflows (**Sync GitHub mirror metadata** and **Publish
-wiki**) are delivered by the instance and are not in your `uses:` lines; you
-cannot pin them, but they fetch their scripts at the major tag.
+The scoped workflow **Sync GitHub mirror metadata** is delivered by the
+instance and is not in your `uses:` lines; you cannot pin it, but it fetches its
+script at the major tag. Wiki publishing is a reusable workflow you call
+(`publish-wiki-pages.yml`); the scoped **Publish wiki** workflow and its
+`wiki/.publish` marker were removed in 2.0.0, so a repository that still has the
+marker no longer publishes until it calls the reusable workflow (see the
+onboarding guide).
 
 ## Reading a changelog entry
 

tests/test_badges.py

@@ -0,0 +1,289 @@
+"""Offline tests for tools/badges.py (ADR-0010): the coverage reader and the SVG renderer."""
+
+import importlib.util
+import json
+import xml.etree.ElementTree as ElementTree
+from pathlib import Path
+
+import pytest
+
+REPO_ROOT = Path(__file__).resolve().parent.parent
+_SPEC = importlib.util.spec_from_file_location(
+    "badges", REPO_ROOT / "tools" / "badges.py"
+)
+assert _SPEC is not None and _SPEC.loader is not None
+badges = importlib.util.module_from_spec(_SPEC)
+_SPEC.loader.exec_module(badges)
+
+DTD = (
+    '<!DOCTYPE coverage SYSTEM "http://cobertura.sourceforge.net/xml/coverage-04.dtd">'
+)
+
+
+def report(
+    tmp_path: Path, attributes: str, root: str = "coverage", prolog: str = ""
+) -> Path:
+    path = tmp_path / "coverage.xml"
+    path.write_text(
+        f'<?xml version="1.0" ?>\n{prolog}<{root} {attributes}><packages/></{root}>\n'
+    )
+    return path
+
+
+class TestReadCoverage:
+    @pytest.mark.parametrize(
+        ("covered", "valid", "percent"),
+        [
+            (0, 10, 0),
+            (1, 3, 33),
+            (2, 3, 67),
+            (5, 8, 63),
+            (87, 100, 87),
+            (1, 200, 1),
+            (10, 10, 100),
+        ],
+    )
+    def test_percent_is_covered_over_valid_rounded_half_up(
+        self, tmp_path, covered, valid, percent
+    ):
+        path = report(
+            tmp_path, f'lines-covered="{covered}" lines-valid="{valid}" line-rate="0"'
+        )
+        assert badges.read_coverage(path) == percent
+
+    def test_the_half_rounds_up(self, tmp_path):
+        assert (
+            badges.read_coverage(report(tmp_path, 'lines-covered="1" lines-valid="8"'))
+            == 13
+        )
+
+    def test_line_rate_is_used_when_the_counts_are_absent(self, tmp_path):
+        assert badges.read_coverage(report(tmp_path, 'line-rate="0.875"')) == 88
+
+    def test_a_document_type_declaration_is_accepted(self, tmp_path):
+        path = report(tmp_path, 'lines-covered="9" lines-valid="10"', prolog=DTD + "\n")
+        assert badges.read_coverage(path) == 90
+
+    def test_missing_file_names_the_file(self, tmp_path):
+        with pytest.raises(badges.ConfigurationError, match="nope.xml' does not exist"):
+            badges.read_coverage(tmp_path / "nope.xml")
+
+    def test_malformed_xml_names_the_file(self, tmp_path):
+        path = tmp_path / "bad.xml"
+        path.write_text("<coverage lines-valid=")
+        with pytest.raises(
+            badges.ConfigurationError, match="bad.xml' is not well-formed"
+        ):
+            badges.read_coverage(path)
+
+    def test_other_xml_is_not_a_cobertura_report(self, tmp_path):
+        with pytest.raises(badges.ConfigurationError, match="not a Cobertura report"):
+            badges.read_coverage(report(tmp_path, 'lines-valid="1"', root="testsuite"))
+
+    def test_no_valid_lines_is_a_failure_and_not_zero_percent(self, tmp_path):
+        with pytest.raises(badges.ConfigurationError, match="has no valid lines"):
+            badges.read_coverage(report(tmp_path, 'lines-covered="0" lines-valid="0"'))
+
+    def test_covered_above_valid_is_refused(self, tmp_path):
+        with pytest.raises(badges.ConfigurationError, match="outside 0..lines-valid"):
+            badges.read_coverage(report(tmp_path, 'lines-covered="5" lines-valid="4"'))
+
+    def test_report_without_any_rate_is_refused(self, tmp_path):
+        with pytest.raises(badges.ConfigurationError, match="neither lines-valid"):
+            badges.read_coverage(report(tmp_path, 'branch-rate="1"'))
+
+    def test_line_rate_outside_zero_to_one_is_refused(self, tmp_path):
+        with pytest.raises(badges.ConfigurationError, match="outside 0..1"):
+            badges.read_coverage(report(tmp_path, 'line-rate="1.5"'))
+
+    def test_values_that_are_not_numbers_are_refused(self, tmp_path):
+        with pytest.raises(badges.ConfigurationError, match="not a number"):
+            badges.read_coverage(report(tmp_path, 'lines-covered="a" lines-valid="b"'))
+        with pytest.raises(badges.ConfigurationError, match="not a number"):
+            badges.read_coverage(report(tmp_path, 'line-rate="high"'))
+
+    def test_entity_declarations_are_refused(self, tmp_path):
+        prolog = '<!DOCTYPE coverage [<!ENTITY x "y">]>\n'
+        with pytest.raises(badges.ConfigurationError, match="declares entities"):
+            badges.read_coverage(
+                report(tmp_path, 'lines-covered="1" lines-valid="2"', prolog=prolog)
+            )
+
+
+class TestColor:
+    @pytest.mark.parametrize(
+        ("percent", "color"),
+        [
+            (0, badges.RED),
+            (59, badges.RED),
+            (60, badges.YELLOW),
+            (79, badges.YELLOW),
+            (80, badges.GREEN),
+            (100, badges.GREEN),
+        ],
+    )
+    def test_thresholds_are_warn_and_good(self, percent, color):
+        assert badges.coverage_color(percent, 60, 80) == color
+
+    def test_thresholds_can_be_moved(self):
+        assert badges.coverage_color(50, 40, 50) == badges.GREEN
+        assert badges.coverage_color(39, 40, 50) == badges.RED
+
+
+class TestRender:
+    def test_is_valid_xml_with_title_and_text_alternative(self):
+        svg = badges.render("code files", "1,234", badges.BLUE)
+        root = ElementTree.fromstring(svg)
+        ns = "{http://www.w3.org/2000/svg}"
+        assert root.tag == ns + "svg"
+        assert root.get("role") == "img"
+        assert root.get("aria-label") == "code files: 1,234"
+        assert root.find(ns + "title").text == "code files: 1,234"
+
+    def test_same_input_gives_the_same_bytes_and_has_no_script_or_link(self):
+        first = badges.render("coverage", "87%", badges.GREEN)
+        assert first == badges.render("coverage", "87%", badges.GREEN)
+        for forbidden in (
+            "<script",
+            "href",
+            "<image",
+            "<style",
+            "http://www.w3.org/1999/xlink",
+        ):
+            assert forbidden not in first
+
+    def test_width_follows_the_number_of_characters(self):
+        narrow = ElementTree.fromstring(badges.render("a", "1", badges.BLUE)).get(
+            "width"
+        )
+        wide = ElementTree.fromstring(badges.render("a", "1,000", badges.BLUE)).get(
+            "width"
+        )
+        assert int(wide) - int(narrow) == 4 * badges.CHAR_WIDTH
+
+    def test_text_is_escaped(self):
+        svg = badges.render("a<b", 'c&"d', badges.BLUE)
+        assert "a&lt;b" in svg and "c&amp;&quot;d" in svg
+        ElementTree.fromstring(svg)
+
+    def test_text_colour_has_the_better_contrast(self):
+        assert badges._text_color("#555555") == "#ffffff"
+        assert badges._text_color(badges.GREEN) == "#000000"
+
+
+def metrics_file(tmp_path: Path, files: int = 3, lines: int = 1200) -> Path:
+    path = tmp_path / "metrics.json"
+    path.write_text(
+        json.dumps(
+            {"files": files, "lines": lines, "comment": 5, "blank": 6, "languages": {}}
+        )
+    )
+    return path
+
+
+class TestMain:
+    def test_writes_three_badges_and_the_metrics(self, tmp_path, capsys):
+        out = tmp_path / "out"
+        cov = report(tmp_path, 'lines-covered="87" lines-valid="100"')
+        code = badges.main(
+            [
+                "--metrics",
+                str(metrics_file(tmp_path)),
+                "--output-dir",
+                str(out),
+                "--coverage-report",
+                str(cov),
+            ]
+        )
+        assert code == 0
+        assert sorted(p.name for p in out.iterdir()) == [
+            "code-files.svg",
+            "code-lines.svg",
+            "code-metrics.json",
+            "coverage.svg",
+        ]
+        assert (
+            'aria-label="lines of code: 1,200"' in (out / "code-lines.svg").read_text()
+        )
+        assert 'aria-label="coverage: 87%"' in (out / "coverage.svg").read_text()
+        assert f'fill="{badges.GREEN}"' in (out / "coverage.svg").read_text()
+        assert b"\r" not in (out / "code-files.svg").read_bytes()
+        assert "wrote" in capsys.readouterr().out
+
+    def test_output_is_byte_identical_on_a_second_run(self, tmp_path):
+        args = [
+            "--metrics",
+            str(metrics_file(tmp_path)),
+            "--output-dir",
+            str(tmp_path / "o"),
+        ]
+        badges.main(args)
+        first = {p.name: p.read_bytes() for p in (tmp_path / "o").iterdir()}
+        badges.main(args)
+        assert first == {p.name: p.read_bytes() for p in (tmp_path / "o").iterdir()}
+
+    def test_without_a_report_no_coverage_badge_and_a_notice(self, tmp_path, capsys):
+        out = tmp_path / "out"
+        assert (
+            badges.main(
+                ["--metrics", str(metrics_file(tmp_path)), "--output-dir", str(out)]
+            )
+            == 0
+        )
+        assert not (out / "coverage.svg").exists()
+        assert "::notice::No coverage-report given" in capsys.readouterr().out
+
+    def test_a_bad_report_fails_and_writes_nothing(self, tmp_path, capsys):
+        out = tmp_path / "out"
+        code = badges.main(
+            [
+                "--metrics",
+                str(metrics_file(tmp_path)),
+                "--output-dir",
+                str(out),
+                "--coverage-report",
+                str(tmp_path / "missing.xml"),
+            ]
+        )
+        assert code == 1
+        assert "::error::[configuration] coverage-report" in capsys.readouterr().out
+        assert not out.exists()
+
+    @pytest.mark.parametrize(
+        ("warn", "good", "message"),
+        [
+            ("x", "80", "coverage-warn 'x'"),
+            ("60", "101", "coverage-good '101'"),
+            ("-1", "80", "coverage-warn '-1'"),
+            ("90", "80", "above coverage-good"),
+        ],
+    )
+    def test_invalid_thresholds_fail(self, tmp_path, capsys, warn, good, message):
+        code = badges.main(
+            [
+                "--metrics",
+                str(metrics_file(tmp_path)),
+                "--output-dir",
+                str(tmp_path / "o"),
+                "--coverage-warn",
+                warn,
+                "--coverage-good",
+                good,
+            ]
+        )
+        assert code == 1
+        assert message in capsys.readouterr().out
+
+    def test_unreadable_metrics_fail(self, tmp_path, capsys):
+        bad = tmp_path / "m.json"
+        bad.write_text('{"files": 1}')
+        code = badges.main(["--metrics", str(bad), "--output-dir", str(tmp_path / "o")])
+        assert code == 1
+        assert "cannot be read" in capsys.readouterr().out
+
+    def test_no_code_files_is_a_notice_and_badges_that_show_zero(self, tmp_path, capsys):
+        out = tmp_path / "out"
+        metrics = metrics_file(tmp_path, files=0, lines=0)
+        assert badges.main(["--metrics", str(metrics), "--output-dir", str(out)]) == 0
+        assert "::notice::No code files were found" in capsys.readouterr().out
+        assert 'aria-label="code files: 0"' in (out / "code-files.svg").read_text()