Add the reusable quality-check workflows for C++ and C#

Task: MIL-007#4 Task: MIL-007#5
2026-10-11 12:55:59 +08:00
45 changed files with 98 additions and 1300 deletions
@@ -23,13 +23,12 @@ jobs:
    permissions:
      contents: read
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - name: Check out the repository
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
      - name: Fetch the shared script
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
        with:
          repository: TirSystem/github-action
          ref: v1
@@ -16,10 +16,9 @@ jobs:
    permissions:
      contents: read
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - name: Fetch the shared script
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
        with:
          repository: TirSystem/github-action
          ref: v1
@@ -43,7 +43,6 @@ jobs:
    permissions:
      contents: read
    runs-on: ubuntu-latest
    timeout-minutes: 15
    env:
      WORKING_DIRECTORY: ${{ inputs.working-directory }}
      STD: ${{ inputs.std }}
@@ -53,10 +52,10 @@ jobs:
      QC_VENV: /tmp/quality-tools
    steps:
      - name: Check out the repository
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
      - name: Fetch the shared script
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
        with:
          repository: TirSystem/github-action
          ref: ${{ inputs.tools-ref }}
@@ -34,7 +34,6 @@ jobs:
    permissions:
      contents: read
    runs-on: ubuntu-latest
    timeout-minutes: 15
    env:
      WORKING_DIRECTORY: ${{ inputs.working-directory }}
      PROJECT: ${{ inputs.project }}
@@ -42,10 +41,10 @@ jobs:
      DOTNET_ROOT: /tmp/dotnet
    steps:
      - name: Check out the repository
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
      - name: Fetch the shared script
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
        with:
          repository: TirSystem/github-action
          ref: ${{ inputs.tools-ref }}
@@ -45,7 +45,6 @@ jobs:
    permissions:
      contents: read
    runs-on: ubuntu-latest
    timeout-minutes: 15
    env:
      LANGUAGES: ${{ inputs.languages }}
      WORKING_DIRECTORY: ${{ inputs.working-directory }}
@@ -56,10 +55,10 @@ jobs:
      QC_VENV: /tmp/quality-tools
    steps:
      - name: Check out the repository
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
      - name: Fetch the shared script
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
        with:
          repository: TirSystem/github-action
          ref: ${{ inputs.tools-ref }}
@@ -26,10 +26,9 @@ jobs:
    permissions:
      contents: write
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - name: Check out the repository
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
      - name: Check and publish the release
        env:
@@ -45,10 +45,9 @@ jobs:
    permissions:
      contents: read
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - name: Check out the project
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
        with:
          token: ${{ secrets.TOKEN_FOR_GITEA }}
@@ -68,11 +67,23 @@ jobs:
          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
+        run: |
          set -euo pipefail
          if command -v curl >/dev/null && command -v jq >/dev/null; then exit 0; fi
          sudo_cmd=""
          if [ "$(id -u)" -ne 0 ]; then sudo_cmd="sudo"; fi
          $sudo_cmd apt-get update -qq
          $sudo_cmd apt-get install -y -qq curl jq
      - 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
+        run: |
          set -euo pipefail
          if [ "$DRY_RUN" = "true" ]; then
            bash framework/scripts/sync-project.sh --accepted-only
          else
            bash framework/scripts/sync-project.sh --accepted-only --apply
          fi
@@ -11,10 +11,9 @@ jobs:
    permissions:
      contents: read
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - name: Check out the repository
-        uses: actions/checkout@v4.2.2
+        uses: actions/checkout@v4
      - name: Create a virtual environment and install test dependencies
        run: |
@@ -7,10 +7,8 @@
 # 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/
@@ -1,123 +1,19 @@
 # AGENTS.md
- `framework/` — the reusable SQA and QC framework (QC checklists, the
+This project uses the SQA and QC framework mounted at `framework/`.
  `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
+skill. For planning a project or a phase into tasks, and syncing phases and
-the `create-project` skill. For planning a project or a phase into tasks, and
+tasks to Gitea/GitHub as Milestones and Issues, use the `project-planning`
-syncing phases and tasks to Gitea/GitHub as Milestones and Issues, use the
+skill. For writing or reviewing source code (Python, C, C++, C#) 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
+`bash framework/scripts/install-skills.sh` — re-run it after updating the
-`framework/.agents/skills/`, then re-run the script.
+framework.
 ## 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,
+apply once a commit has been asked for.
 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
@@ -129,56 +25,37 @@ 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
+for a go-ahead. Only the user can waive the plan, in chat, for that request.
-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
-A project with no baseline yet starts with the `create-project` skill.
+`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.
 ## 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`
+2. Owners, reviewers and RACI use stakeholder IDs from the project's
-   (`SA-001`), never invented role names.
+   Stakeholder Analysis, never invented role names.
-3. Every QC criterion is tagged with an ISO/IEC 25010:2023 characteristic
+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
+5. Do not edit `framework/` from this project; propose changes upstream.
   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
+   opening the PR (no amend). Never ask for or perform the merge: a reviewer
-   merge; a reviewer merges. Autonomous mode: the AI merges, as set out in
+   merges.
-   `Modes`.
+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.
@@ -20,54 +20,18 @@ Each release lists its changes in these groups, in this order:
 ## [Unreleased]
 ## [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
+  repository needs a `.clang-format`.
  `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
@@ -458,7 +458,6 @@ Rows that say Implemented or Guides written exist today. The rest is planned and
 | 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) |
 | 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)) |
 | 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
@@ -11,7 +11,7 @@ each document lives in *this* project and the next version to use.
 | 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 | 060 |
+| RC | SQA Review Record | docs/sqa/reviews/rc-*.md | 058 |
 | TM | Traceability Matrix | docs/sqa/traceability-matrix.md | 002 |
 | ADR | Architecture Decision Record | docs/adr/adr-NNNN-*.md | 0009 |
 | UCD | Use Case Diagram | docs/use-case-diagram.md | 002 |
@@ -9,8 +9,8 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-11 | Deprecated | Jens Tirsvad Nielsen | S01 | Criterion 1 evidence amended; added the verification results of the pilot | [d575f27] |
+| 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-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] |
+| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Criterion 1 evidence amended; added the verification results of the pilot | [d575f27] |
 ---
@@ -71,7 +71,6 @@ 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
@@ -96,4 +95,3 @@ 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
@@ -9,8 +9,8 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-11 | Deprecated | Jens Tirsvad Nielsen | S01 | Amendment reviewed (RC-055) and accepted: current tool versions, .NET SDK 10 or later, results of run 699, the contract of ADR-0008 in task 3 | [faf13b2] |
+| 2026-10-11 | Deprecated | Jens Tirsvad Nielsen | S01 | Current tool versions only, .NET SDK 10 or later: results of run 699 replace the SDK 8 result; tasks 3 and criterion 1 amended | [7bcc67a] |
-| 2026-10-13 | Accepted | 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-11 | Accepted | Jens Tirsvad Nielsen | S01 | Amendment reviewed (RC-055) and accepted: current tool versions, .NET SDK 10 or later, results of run 699, the contract of ADR-0008 in task 3 | [faf13b2] |
 ---
@@ -112,30 +112,6 @@ 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 are kept until the user says to delete
 them.
 ---
 [BC-001]: ../business-case.md
@@ -148,4 +124,3 @@ them.
 [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
@@ -1,51 +0,0 @@
 # 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
@@ -1,51 +0,0 @@
 # 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 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | [2481c26] |
 ---
 ## 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`, and adopt the workflows in a real C++ and 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
@@ -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], [RC-054], [RC-055], [RC-056], [RC-057], [RC-058], [RC-059], [ADR-0007], [ADR-0008], [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], [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], [ADR-0007], [ADR-0008], [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-13 | Proposed | Jens Tirsvad Nielsen | S01 | Added RC-058 (MIL-006 task 6 amendment) | [8051cc4] |
+| 2026-10-11 | Deprecated | Jens Tirsvad Nielsen | S01 | Added RC-055 (MIL-007 amendment) | [faf13b2] |
-| 2026-10-13 | Proposed | Jens Tirsvad Nielsen | S01 | Added RC-059 (MIL-007 task 7 results) | [2481c26] |
+| 2026-10-11 | Accepted | Jens Tirsvad Nielsen | S01 | Added RC-056 and RC-057 (UC-005 and US-001 for C++ and C#) | [1bc56f8] |
 ---
@@ -38,8 +38,8 @@ 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], [RC-058] |
+| [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], [ADR-0008] | - | [RC-052], [RC-055], [RC-059] |
+| [MIL-007] | MIL | [BC-001], [PP-001], [MIL-003], [MIL-004], [ADR-0008] | - | [RC-052], [RC-055] |
 | [RC-007] | RC | [MIL-004] | - | - |
 | [RC-008] | RC | [BC-001] | - | - |
 | [RC-009] | RC | [PP-001] | - | - |
@@ -108,8 +108,6 @@ updated whenever an artifact instance is created or reviewed.
 | [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] | - | - |
 ## Coverage Notes
@@ -197,8 +195,6 @@ updated whenever an artifact instance is created or reviewed.
 [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
 [ADR-0008]: ../adr/adr-0008-cpp-csharp-quality-check-contract.md
 [ADR-0007]: ../adr/adr-0007-release-publish-destination.md
 [UC-007]: ../uc-007/uc.md
@@ -208,5 +204,3 @@ updated whenever an artifact instance is created or reviewed.
 [ADR-0005]: ../adr/adr-0005-quality-check-contract.md
 [faf13b2]: https://git.tirsystem.com/TirSystem/github-action/commit/faf13b2c2a4901c0171977de1ffc2841023f537a
 [1bc56f8]: https://git.tirsystem.com/TirSystem/github-action/commit/1bc56f8b771531f221f218fc00b147ecc73c051e
 [8051cc4]: https://git.tirsystem.com/TirSystem/github-action/commit/8051cc4489ee9bcf3b6c62f2eafcb2013b7d2f90
 [2481c26]: https://git.tirsystem.com/TirSystem/github-action/commit/2481c26d802464decd51d75539157093b60e08e8
@@ -51,8 +51,7 @@ like the sync workflow, but it writes only where a repository opts in.
 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. A hyphen in the name is a space in the page name: `Home-da.md`
+   the home page.
   is the page "Home da", and a link to it is `[Dansk](Home-da)`.
 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.
@@ -1,102 +0,0 @@
 # 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) |
@@ -1,97 +0,0 @@
 # 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) |
@@ -16,9 +16,8 @@ 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 workflows (`quality-checks.yml`, `quality-checks-cpp.yml` and
+The quality-checks workflow fetches its script at its input `tools-ref`, which
-`quality-checks-csharp.yml`) fetch their script at their input `tools-ref`, which
+defaults to `v1`. To pin it completely, call it at an exact tag and set
 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
@@ -98,16 +98,7 @@ def _write_sources(root: Path) -> None:
        "## 📄 License\nMIT.\n",
        encoding="utf-8",
    )
-    guide_names = (
+    for name in ("onboarding", "credentials", "troubleshooting", "quality-checks", "upgrading"):
        "onboarding",
        "credentials",
        "troubleshooting",
        "quality-checks",
        "quality-checks-cpp",
        "quality-checks-csharp",
        "upgrading",
    )
    for name in guide_names:
        (root / "guides" / f"{name}.md").write_text(
            f"# {name.title()}\nBody.\n", encoding="utf-8"
        )
@@ -67,15 +67,6 @@ class TestReadPages:
            publish_wiki.read_pages(tmp_path)
 class TestPageTitle:
    @pytest.mark.parametrize(
        ("key", "title"), [("Home", "Home"), ("Home-da", "Home da"), ("Getting-Started-ms", "Getting Started ms")]
    )
    def test_a_hyphen_is_sent_as_a_space(self, publish_wiki, key, title):
        # Gitea keeps a hyphen in a title literal (Home-da.-.md, address Home%2Dda).
        assert publish_wiki.page_title(key) == title
 class TestPageKey:
    @pytest.mark.parametrize(
        ("name", "key"),
@@ -116,13 +107,12 @@ class FakeGitea:
                raise self.error("configuration", "404")
            return [{"title": key.replace("-", " "), "sub_url": key} for key in self.wiki]
        if method == "POST" and url == f"{WIKI_URL}/new":
-            self.wiki[body["title"].replace(" ", "-")] = body["content_base64"]
+            self.wiki[body["title"]] = body["content_base64"]
            return None
        title = url.rsplit("/", 1)[-1]
        if method == "GET":
            return {"title": title, "content_base64": self.wiki[title]}
        if method == "PATCH":
            assert " " in body["title"] or "-" not in body["title"], body["title"]
            self.wiki[title] = body["content_base64"]
            return None
        if method == "DELETE":
@@ -5,7 +5,6 @@ network, no clang and no .NET SDK are needed.
 """
 import os
 import re
 import shutil
 import subprocess
 from pathlib import Path
@@ -286,94 +285,7 @@ class TestCppRun:
        result, calls = self.run(repo, tmp_path, cpp_bin, COMPILE_COMMANDS_DIR="build")
        assert result.returncode == 0, result.stdout
        assert len(calls) == 2
-        database = re.search(r"-p (\S+)", calls[1])
+        assert "-p build" in calls[1] and "-std=" not in calls[1]
        assert database is not None and database.group(1).endswith(f"/{repo.name}/build")
        assert "-std=" not in calls[1]
    def test_clang_tidy_gets_default_checks_without_a_clang_tidy_file(
        self,
        repo: Path,
        tmp_path: Path,
        cpp_bin: Path,
    ) -> None:
        add_files(repo, "a.cpp")
        _, calls = self.run(repo, tmp_path, cpp_bin)
        assert "--checks=clang-diagnostic-*,clang-analyzer-*" in calls[1]
        assert "--checks=" not in calls[0]
    def test_no_default_checks_when_a_clang_tidy_file_is_in_the_repository_root(
        self,
        repo: Path,
        tmp_path: Path,
        cpp_bin: Path,
    ) -> None:
        add_files(repo, "a.cpp", ".clang-tidy")
        _, calls = self.run(repo, tmp_path, cpp_bin)
        assert len(calls) == 2
        assert not any("--checks=" in call for call in calls)
    @pytest.mark.parametrize(
        ("files", "extra", "tidy_calls"),
        [
            (("a.cpp", "lib/c.c"), {}, 2),
            (("a.cpp", ".clang-tidy"), {}, 1),
            (("a.cpp", "build/compile_commands.json"), {"COMPILE_COMMANDS_DIR": "build"}, 1),
        ],
        ids=["no-clang-tidy-file", "clang-tidy-file", "compile-database"],
    )
    def test_every_clang_tidy_call_treats_warnings_as_errors(
        self,
        repo: Path,
        tmp_path: Path,
        cpp_bin: Path,
        files: tuple[str, ...],
        extra: dict[str, str],
        tidy_calls: int,
    ) -> None:
        add_files(repo, *files)
        _, calls = self.run(repo, tmp_path, cpp_bin, **extra)
        tidy = [c for c in calls if c.startswith("clang-tidy")]
        assert len(tidy) == tidy_calls
        assert all("--warnings-as-errors=*" in call for call in tidy)
        assert "--warnings-as-errors" not in calls[0] and calls[0].startswith("clang-format")
    def test_no_default_checks_when_a_clang_tidy_file_is_above_the_working_directory(
        self,
        repo: Path,
        tmp_path: Path,
        cpp_bin: Path,
    ) -> None:
        add_files(repo, "service/a.cpp", ".clang-tidy")
        _, calls = self.run(repo, tmp_path, cpp_bin, WORKING_DIRECTORY="service")
        assert len(calls) == 2
        assert not any("--checks=" in call for call in calls)
    def test_a_compile_database_is_resolved_from_the_repository_root(
        self,
        repo: Path,
        tmp_path: Path,
        cpp_bin: Path,
    ) -> None:
        add_files(repo, "service/a.cpp", "build/compile_commands.json")
        result, calls = self.run(
            repo, tmp_path, cpp_bin, WORKING_DIRECTORY="service", COMPILE_COMMANDS_DIR="build"
        )
        assert result.returncode == 0, result.stdout
        database = re.search(r"-p (\S+)", calls[1])
        assert database is not None and database.group(1).endswith(f"/{repo.name}/build")
    def test_a_compile_database_only_inside_the_working_directory_is_not_found(
        self,
        repo: Path,
        tmp_path: Path,
        cpp_bin: Path,
    ) -> None:
        add_files(repo, "service/a.cpp", "service/build/compile_commands.json")
        result, calls = self.run(
            repo, tmp_path, cpp_bin, WORKING_DIRECTORY="service", COMPILE_COMMANDS_DIR="build"
        )
        assert result.returncode == 1 and "[configuration]" in result.stdout
        assert calls == []
    def test_a_missing_compile_database_is_a_configuration_error(
        self,
@@ -44,8 +44,6 @@ PAGES: tuple[Page, ...] = (
    Page("Credentials", "guides/credentials.md"),
    Page("Troubleshooting", "guides/troubleshooting.md"),
    Page("QualityChecksPythonShell", "guides/quality-checks.md"),
    Page("QualityChecksCpp", "guides/quality-checks-cpp.md"),
    Page("QualityChecksCSharp", "guides/quality-checks-csharp.md"),
    Page("Upgrading", "guides/upgrading.md"),
    Page("Capabilities", "README.md", ("Capabilities",)),
 )
@@ -64,8 +62,6 @@ _PAGE_FOR_SOURCE = {
    "guides/credentials.md": "Credentials",
    "guides/troubleshooting.md": "Troubleshooting",
    "guides/quality-checks.md": "QualityChecksPythonShell",
    "guides/quality-checks-cpp.md": "QualityChecksCpp",
    "guides/quality-checks-csharp.md": "QualityChecksCSharp",
    "guides/upgrading.md": "Upgrading",
 }
@@ -191,9 +187,9 @@ def render_page(page: Page, repo_root: Path = REPO_ROOT) -> str:
 # Link text of the sidebar: English, then one list per translation code.
 SIDEBAR_TITLE = "TirSystem GitHub Actions"
 SIDEBAR_LABELS: dict[str, tuple[str, ...]] = {
-    "en": ("Home", "Onboarding", "Credentials", "Troubleshooting", "Quality checks (Python, shell)", "Quality checks (C and C++)", "Quality checks (C#)", "Upgrading", "Capabilities"),
+    "en": ("Home", "Onboarding", "Credentials", "Troubleshooting", "Quality checks (Python, shell)", "Upgrading", "Capabilities"),
-    "da": ("Hjem", "Tilslutning", "Credentials", "Fejlfinding", "Kvalitetskontrol (Python, shell)", "Kvalitetskontrol (C og C++)", "Kvalitetskontrol (C#)", "Opgradering", "Kapabiliteter"),
+    "da": ("Hjem", "Tilslutning", "Credentials", "Fejlfinding", "Kvalitetskontrol (Python, shell)", "Opgradering", "Kapabiliteter"),
-    "ms": ("Utama", "Menyertakan", "Kelayakan", "Diagnosis", "Semakan kualiti (Python, shell)", "Semakan kualiti (C dan C++)", "Semakan kualiti (C#)", "Menaik taraf", "Keupayaan"),
+    "ms": ("Utama", "Menyertakan", "Kelayakan", "Diagnosis", "Semakan kualiti (Python, shell)", "Menaik taraf", "Keupayaan"),
 }
 SIDEBAR_NAME = "_Sidebar.md"
@@ -135,16 +135,6 @@ def page_key(title):
    return str(title).replace(" ", "-")
 def page_title(key):
    """Return the title to send to Gitea for a page key.
    A hyphen in a title is a literal hyphen to Gitea, which then stores the page
    as Home-da.-.md and addresses it as Home%2Dda, so a link to Home-da finds
    nothing. A space is stored as a hyphen (Home-da.md) and addressed as Home-da.
    """
    return key.replace("-", " ")
 def read_pages(wiki_dir):
    """Return {page key: content} for every Markdown file in wiki_dir."""
    pages = {}
@@ -217,7 +207,7 @@ def publish(pages, wiki_url, headers, send, prune):
    result = {"created": [], "updated": [], "deleted": [], "kept": []}
    for title, content in pages.items():
        body = {
-            "title": page_title(title),
+            "title": title,
            "content_base64": base64.b64encode(content).decode("ascii"),
            "message": COMMIT_MESSAGE,
        }
@@ -13,7 +13,6 @@
 # Every failure is printed as ::error::[category] message.
 C_STANDARD="${C_STANDARD:-c17}"
 DEFAULT_TIDY_CHECKS="clang-diagnostic-*,clang-analyzer-*"
 validate_inputs() {
  set -u
@@ -51,19 +50,16 @@ install_tools() {
    "clang-format==${CLANG_FORMAT_VERSION}" "clang-tidy==${CLANG_TIDY_VERSION}"
 }
-# Succeeds when one of the named files exists in the working directory or above
+# A .clang-format must exist in the working directory or above it, up to the
-# it, up to the top of the repository: clang-format and clang-tidy find their
+# top of the repository: clang-format finds its style the same way.
-# configuration the same way.
+find_clang_format_config() {
-find_config_upwards() {
+  local top dir parent
  local top dir parent name
  top="$(cd "$(git rev-parse --show-toplevel)" && pwd -P)"
  dir="$(pwd -P)"
  while true; do
-    for name in "$@"; do
+    if [ -f "$dir/.clang-format" ] || [ -f "$dir/_clang-format" ]; then
-      if [ -f "$dir/$name" ]; then
+      return 0
-        return 0
+    fi
      fi
    done
    parent="$(dirname "$dir")"
    # stop at the top of the repository, or at the file system root
    if [ "$dir" = "$top" ] || [ "$parent" = "$dir" ]; then
@@ -80,12 +76,6 @@ run_checks() {
    echo "::error::[configuration] working-directory '$WORKING_DIRECTORY' does not exist."
    exit 1
  fi
  # compile-commands-dir is relative to the repository root, not to the working directory
  local repo_top compile_db=""
  repo_top="$(cd "$(git rev-parse --show-toplevel)" && pwd -P)"
  if [ -n "$COMPILE_COMMANDS_DIR" ]; then
    compile_db="$repo_top/$COMPILE_COMMANDS_DIR"
  fi
  cd "$WORKING_DIRECTORY"
  local all_files cpp_files c_files
@@ -95,11 +85,11 @@ run_checks() {
    echo "All selected checks passed."
    exit 0
  fi
-  if ! find_config_upwards .clang-format _clang-format; then
+  if ! find_clang_format_config; then
    echo "::error::[configuration] No .clang-format found in '$WORKING_DIRECTORY' or above it; add the style of the project."
    exit 1
  fi
-  if [ -n "$compile_db" ] && [ ! -f "$compile_db/compile_commands.json" ]; then
+  if [ -n "$COMPILE_COMMANDS_DIR" ] && [ ! -f "$COMPILE_COMMANDS_DIR/compile_commands.json" ]; then
    echo "::error::[configuration] compile-commands-dir '$COMPILE_COMMANDS_DIR' has no compile_commands.json; build it before the call."
    exit 1
  fi
@@ -125,23 +115,14 @@ run_checks() {
  run_tool "clang-format" "$QC_BIN/clang-format" --dry-run -Werror "${all_files[@]}"
-  # Without a .clang-tidy, clang-tidy enables no check and refuses to run, so
+  if [ -n "$COMPILE_COMMANDS_DIR" ]; then
-  # the project gets the compiler diagnostics and the static analyzer.
+    run_tool "clang-tidy" "$QC_BIN/clang-tidy" --quiet -p "$COMPILE_COMMANDS_DIR" "${all_files[@]}"
  # clang-tidy exits 0 on a warning, so every finding is made an error: a
  # finding must fail the check, as a failing tool does for the other languages.
  local tidy_args=(--quiet "--warnings-as-errors=*")
  if ! find_config_upwards .clang-tidy _clang-tidy; then
    tidy_args+=("--checks=${DEFAULT_TIDY_CHECKS}")
  fi
  if [ -n "$compile_db" ]; then
    run_tool "clang-tidy" "$QC_BIN/clang-tidy" "${tidy_args[@]}" -p "$compile_db" "${all_files[@]}"
  else
    if [ "${#cpp_files[@]}" -gt 0 ]; then
-      run_tool "clang-tidy (C++)" "$QC_BIN/clang-tidy" "${tidy_args[@]}" "${cpp_files[@]}" -- "-std=${STD}"
+      run_tool "clang-tidy (C++)" "$QC_BIN/clang-tidy" --quiet "${cpp_files[@]}" -- "-std=${STD}"
    fi
    if [ "${#c_files[@]}" -gt 0 ]; then
-      run_tool "clang-tidy (C)" "$QC_BIN/clang-tidy" "${tidy_args[@]}" "${c_files[@]}" -- "-std=${C_STANDARD}"
+      run_tool "clang-tidy (C)" "$QC_BIN/clang-tidy" --quiet "${c_files[@]}" -- "-std=${C_STANDARD}"
    fi
  fi
@@ -1,4 +1,4 @@
-<!-- translation of Capabilities.md, source sha256 1f12a6b27e5d -->
+<!-- translation of Capabilities.md, source sha256 a8c03a001880 -->
 > Dette er en oversættelse af [`Capabilities`](Capabilities). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
@@ -15,5 +15,4 @@ Rækker, der siger Implementeret eller Vejledninger er skrevet, findes i dag. Re
 | 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) |
 | 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)) |
 | Versioneret udgivelse og publicering | Udgivelsesproces, changelog og opgraderingsvejledning er defineret; udgivelsesworkflowet findes, og `v1.0.0` er udgivet (MIL-004) ([vejledning](Upgrading.da)) |
@@ -15,5 +15,4 @@ Rows that say Implemented or Guides written exist today. The rest is planned and
 | 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) |
 | 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)) |
 | 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)) |
@@ -1,4 +1,4 @@
-<!-- translation of Capabilities.md, source sha256 1f12a6b27e5d -->
+<!-- translation of Capabilities.md, source sha256 a8c03a001880 -->
 > Ini ialah terjemahan [`Capabilities`](Capabilities). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
@@ -15,5 +15,4 @@ Baris yang menyatakan Dilaksanakan atau Panduan telah ditulis wujud hari ini. Se
 | 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) |
 | 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)) |
 | 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)) |
@@ -1,4 +1,4 @@
-<!-- translation of Onboarding.md, source sha256 0b11defd563a -->
+<!-- translation of Onboarding.md, source sha256 1d431898754e -->
 > Dette er en oversættelse af [`Onboarding`](Onboarding). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
@@ -35,7 +35,7 @@ Leveringen er automatisk, så et repository behøver ingen kopi af workflowet. S
 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.
 1. Aktivér wikien i repositoryets indstillinger.
-2. Tilføj Markdown-sider til `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)`.
+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.
 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>`.
@@ -57,8 +57,7 @@ like the sync workflow, but it writes only where a repository opts in.
 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. A hyphen in the name is a space in the page name: `Home-da.md`
+   the home page.
   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 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.
@@ -1,4 +1,4 @@
-<!-- translation of Onboarding.md, source sha256 0b11defd563a -->
+<!-- translation of Onboarding.md, source sha256 1d431898754e -->
 > Ini ialah terjemahan [`Onboarding`](Onboarding). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
@@ -35,7 +35,7 @@ Penghantaran adalah automatik, jadi repositori tidak memerlukan salinan aliran k
 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.
 1. Aktifkan wiki dalam tetapan repositori.
-2. Tambah halaman Markdown ke `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)`.
+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.
 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>`.
@@ -1,85 +0,0 @@
 <!-- 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) |
@@ -1,103 +0,0 @@
 <!-- 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) |
@@ -1,85 +0,0 @@
 <!-- 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) |
@@ -1,88 +0,0 @@
 <!-- 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) |
@@ -1,108 +0,0 @@
 <!-- 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) |
@@ -1,88 +0,0 @@
 <!-- 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) |
@@ -1,4 +1,4 @@
-<!-- translation of Upgrading.md, source sha256 7fba937279b1 -->
+<!-- translation of Upgrading.md, source sha256 3f119a1ab12d -->
 > Dette er en oversættelse af [`Upgrading`](Upgrading). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
@@ -18,7 +18,7 @@ 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-workflowene (`quality-checks.yml`, `quality-checks-cpp.yml` og `quality-checks-csharp.yml`) henter deres script 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.
+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.
 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.
@@ -22,9 +22,8 @@ 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 workflows (`quality-checks.yml`, `quality-checks-cpp.yml` and
+The quality-checks workflow fetches its script at its input `tools-ref`, which
-`quality-checks-csharp.yml`) fetch their script at their input `tools-ref`, which
+defaults to `v1`. To pin it completely, call it at an exact tag and set
 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
@@ -1,4 +1,4 @@
-<!-- translation of Upgrading.md, source sha256 7fba937279b1 -->
+<!-- translation of Upgrading.md, source sha256 3f119a1ab12d -->
 > Ini ialah terjemahan [`Upgrading`](Upgrading). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
@@ -18,7 +18,7 @@ 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 (`quality-checks.yml`, `quality-checks-cpp.yml` dan `quality-checks-csharp.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.
+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.
 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.
@@ -9,8 +9,6 @@
 - [Credentials](Credentials)
 - [Troubleshooting](Troubleshooting)
 - [Quality checks (Python, shell)](QualityChecksPythonShell)
 - [Quality checks (C and C++)](QualityChecksCpp)
 - [Quality checks (C#)](QualityChecksCSharp)
 - [Upgrading](Upgrading)
 - [Capabilities](Capabilities)
@@ -21,8 +19,6 @@
 - [Credentials](Credentials.da)
 - [Fejlfinding](Troubleshooting.da)
 - [Kvalitetskontrol (Python, shell)](QualityChecksPythonShell.da)
 - [Kvalitetskontrol (C og C++)](QualityChecksCpp.da)
 - [Kvalitetskontrol (C#)](QualityChecksCSharp.da)
 - [Opgradering](Upgrading.da)
 - [Kapabiliteter](Capabilities.da)
@@ -33,7 +29,5 @@
 - [Kelayakan](Credentials.ms)
 - [Diagnosis](Troubleshooting.ms)
 - [Semakan kualiti (Python, shell)](QualityChecksPythonShell.ms)
 - [Semakan kualiti (C dan C++)](QualityChecksCpp.ms)
 - [Semakan kualiti (C#)](QualityChecksCSharp.ms)
 - [Menaik taraf](Upgrading.ms)
 - [Keupayaan](Capabilities.ms)