Merge pull request 'Bump the version to 0.3.4 and write the changelog entry (MIL-011)' (#93) from release-0-3-4-version-and-changelog into main

Reviewed-on: #93

.editorconfig

@@ -7,3 +7,6 @@ end_of_line = lf
 insert_final_newline = true
 charset = utf-8
 trim_trailing_whitespace = true
+
+[*.sh]
+switch_case_indent = true

.env.example

@@ -1,18 +1,21 @@
 # RepoFoundry credentials. Placeholders only: never put a real value in this
 # file or commit one.
 #
-# Everything in this file is optional: a credential that is missing here is
-# asked for when the script runs (the token is not echoed).
+# Every key in this file may be left empty: a credential that is missing here
+# is asked for when the script runs (the token is not echoed). GITEA_TOKEN is
+# always needed; GITHUB_PAT and GITHUB_USER only when you choose GitHub;
+# TOKEN_FOR_GITEA_WIKI is optional and never asked for.
 #
 # Copy this file to .env, fill in the values and keep it private
 # (chmod 600 .env on Linux and macOS). .env is ignored by git. The file is
 # read as plain KEY=VALUE lines and never executed. Values may be wrapped in
 # single or double quotes.
 
-# GitHub personal access token. Needed only when you choose to create a
-# GitHub repository. It creates the repository and is also the password of the
-# Gitea push mirror, so it needs permission to create repositories for the
-# chosen owner and to push to the new one. Prefer a fine-grained token.
+# GitHub personal access token. Required when you choose to create a GitHub
+# repository (the mirror); not used otherwise. It creates the repository and
+# is also the password of the Gitea push mirror, so it needs permission to
+# create repositories for the chosen owner and to push to the new one. Prefer
+# a fine-grained token.
 GITHUB_PAT=
 
 ########################################
@@ -27,3 +30,8 @@ GITHUB_USER=
 # Gitea access token. It needs permission to create repositories
 # for the chosen owner and to manage the repository's push mirror.
 GITEA_TOKEN=
+
+# Optional. Gitea access token for publishing the wiki, with repository write
+# scope only. RepoFoundry accepts it so one .env can serve both, but never uses
+# or asks for it.
+TOKEN_FOR_GITEA_WIKI=

.gitea/workflows/quality.yml

@@ -0,0 +1,23 @@
+name: Quality
+
+# Calls the shared quality-check workflow of TirSystem/github-action
+# (contract: ADR-0005 there). It runs shellcheck and shfmt on the tracked
+# shell files and changes no file. Configuration comes from .shellcheckrc
+# and .editorconfig in this repository. The release workflow requires this run
+# to be green on the commit it releases.
+on:
+  pull_request:
+  push:
+    branches: [ main ]
+  workflow_dispatch:
+
+jobs:
+  quality:
+    permissions:
+      contents: read
+    # Pinned to an exact tag, never to main; tools-ref pins the script to the
+    # same tag, so the whole check is fixed.
+    uses: TirSystem/github-action/.gitea/workflows/quality-checks.yml@v1.1.0
+    with:
+      languages: shell
+      tools-ref: v1.1.0

.gitea/workflows/release.yml

@@ -0,0 +1,56 @@
+name: Release
+
+# Releases this repository: creates the version tag and the release page from
+# the CHANGELOG.md entry, and only when the commit is the tip of main, its
+# Quality run is green and the changelog has an entry for the version. The
+# script is a file of TirSystem/github-action (tools/release.py), fetched at an
+# exact tag. dry_run defaults to true: it checks and prints and writes nothing,
+# so a release is a deliberate second run with dry_run false.
+#
+# release.py also keeps a moving major tag (v0 for 0.x versions) pointing to
+# the highest release of its major version, as in TirSystem/github-action.
+on:
+  workflow_dispatch:
+    inputs:
+      version:
+        description: "Version to release, MAJOR.MINOR.PATCH without a leading v"
+        required: true
+      dry_run:
+        description: "true checks only; false creates the tag and the release page"
+        required: false
+        default: "true"
+
+concurrency:
+  group: release
+  cancel-in-progress: false
+
+jobs:
+  release:
+    permissions:
+      contents: write
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v4.2.2
+
+      - name: Fetch the shared script
+        uses: actions/checkout@v4.2.2
+        with:
+          repository: TirSystem/github-action
+          ref: v1.1.0
+          path: shared-scripts
+
+      - name: Check and publish the release
+        env:
+          GITEA_API_URL: ${{ gitea.api_url }}
+          SOURCE_REPOSITORY: ${{ gitea.repository }}
+          RELEASE_CREDENTIALS: ${{ secrets.TOKEN_FOR_GITEA_RELEASE || github.token }}
+          RELEASE_VERSION: ${{ inputs.version }}
+          RELEASE_DRY_RUN: ${{ inputs.dry_run }}
+          RELEASE_SHA: ${{ gitea.sha }}
+          # The status context of the Quality run on the commit. Check the exact
+          # text on a pull request and correct it here if the dry run says the
+          # run was not found.
+          VALIDATION_CONTEXT: "Quality / quality (push)"
+        run: python3 shared-scripts/tools/release.py

.gitignore

@@ -188,3 +188,5 @@ repofoundry.*/
 
 !src/lib
 config.env
+.agents/
+.claude/

.gitmodules

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

AGENTS.md

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

CHANGELOG.md

@@ -0,0 +1,40 @@
+# Changelog
+
+All notable changes to RepoFoundry. Versions are tags `vMAJOR.MINOR.PATCH`.
+The release workflow takes the text of a release page from the entry of its
+version, so every release needs an entry here before it is started.
+
+Each release lists its changes in these groups, in this order: **Breaking**,
+**Added**, **Changed**, **Fixed**. A release with a Breaking entry has a new
+major version.
+
+`python tools/changelog.py check` of `TirSystem/github-action` verifies this
+file.
+
+## [Unreleased]
+
+## [0.3.4] - 2026-10-13
+
+### Added
+
+- Gitea workflows: Quality (shellcheck and shfmt through the shared reusable
+  workflow) and Release (tag and release page from this changelog).
+- A `wiki/` folder with a `.publish` marker, published to the Gitea wiki by the
+  shared Publish wiki workflow.
+- `switch_case_indent` for `*.sh` in `.editorconfig`, so `shfmt` accepts the
+  existing layout of `case` branches.
+- `TOKEN_FOR_GITEA_WIKI` is accepted in `.env`: an optional Gitea token with
+  the repository write scope only, for publishing the wiki. It is checked like
+  the other tokens, kept out of every message and never used or asked for, so
+  one `.env` can serve both RepoFoundry and the wiki publishing.
+- The wiki in English, Danish and Bahasa Malaysia: Getting started, SSH and
+  tokens, Access tokens, Updating the framework and Troubleshooting.
+
+### Changed
+
+- The guide for creating the access tokens moved from `howto/` to the wiki
+  page Access tokens, with its pictures and a Danish and a Bahasa Malaysia
+  translation.
+- The README, the wiki and `.env.example` say which credentials are required:
+  `GITEA_TOKEN` always, `GITHUB_PAT` and `GITHUB_USER` only when GitHub is
+  chosen, and `TOKEN_FOR_GITEA_WIKI` never.

README.md

@@ -52,8 +52,8 @@ Requirements:
 | `jq` (optional) | JSON parsing; without it a small built-in reader is used |
 
 ```bash
-git clone https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry.git
-cd RepoFoundry
+git clone https://git.tirsystem.com/TirSystem-BashScript/repo-foundry.git
+cd repo-foundry
 src/create-project.sh --help
 ```
 
@@ -69,7 +69,7 @@ command (below):
 
 ```bash
 cd ~/work                                  # the folder that will hold my-app
-~/src/RepoFoundry/src/create-project.sh    # creates ~/work/my-app
+~/src/repo-foundry/src/create-project.sh    # creates ~/work/my-app
 ```
 
 ### Make it a global command
@@ -104,7 +104,7 @@ run `export MSYS=winsymlinks:nativestrict` before the `ln -s`, or use an alias
 in `~/.bashrc`, which works because the script finds its own folder:
 
 ```bash
-alias repo-foundry='bash /c/Users/me/RepoFoundry/src/create-project.sh'
+alias repo-foundry='bash /c/Users/me/repo-foundry/src/create-project.sh'
 ```
 
 ## Configuration
@@ -197,12 +197,13 @@ src/create-project.sh --apply        # asks only "Create these now (y/n) [n]"
 | Key | Meaning |
 | --- | --- |
 | `GITEA_TOKEN` | Gitea access token |
-| `GITHUB_PAT` | GitHub personal access token (only when you choose GitHub) |
-| `GITHUB_USER` | the GitHub account the token belongs to (only when you choose GitHub) |
+| `GITHUB_PAT` | GitHub personal access token (required when you choose GitHub, so the mirror can be created; not used otherwise) |
+| `GITHUB_USER` | the GitHub account the token belongs to (required when you choose GitHub; not used otherwise) |
+| `TOKEN_FOR_GITEA_WIKI` | optional: Gitea access token for publishing the wiki, with the repository write scope (`write:repository`) only; accepted so one `.env` serves both, never used or asked for by this script |
 
 `.env` is ignored by git. The script warns if it is readable by other users or
 not ignored by git. See [Token permissions](#token-permissions) for what each
-token needs, and [How to create the access tokens](howto/create-access-tokens.md)
+token needs, and [How to create the access tokens](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/wiki/AccessTokens)
 for the steps, with pictures, to create the Gitea and the GitHub token.
 
 `.env` is optional, and so is each key in it. A credential that is not
@@ -364,7 +365,7 @@ Both tokens go in `.env` (never in `config.env`, never in a remote URL). The
 script sends them only in a request header, through a private temporary file,
 and never prints them.
 
-New to this? [How to create the access tokens](howto/create-access-tokens.md)
+New to this? [How to create the access tokens](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/wiki/AccessTokens)
 walks through both, step by step, with pictures.
 
 ### GitHub token (`GITHUB_PAT`, only when you choose GitHub)

docs/artifact-registry.md

@@ -14,7 +14,7 @@ document of a type. `Primary File` may contain a glob (e.g.
 | BC | Business Case | docs/business-case.md | 002 |
 | SA | Stakeholder Analysis | docs/stakeholder-analysis.md | 002 |
 | PP | Project Plan | docs/project-plan.md | 002 |
-| MIL | Milestone / Gateway | docs/milestones/*.md | 010 |
+| MIL | Milestone / Gateway | docs/milestones/*.md | 012 |
 | US | User Story | docs/user-stories.md | 002 |
 | UC | Use Case | docs/uc-*/uc.md | 003 |
 | SSD | System Sequence Diagram | docs/uc-*/ssd.md | 003 |
@@ -24,7 +24,7 @@ document of a type. `Primary File` may contain a glob (e.g.
 | DCD | Design Class Diagram | docs/dcd.md | 004 |
 | DICT | Domain Dictionary (PO and IT terms) | docs/dictionary.md | 002 |
 | UCD | Use Case Diagram | docs/use-case-diagram.md | 002 |
-| RC | SQA Review Record | docs/sqa/reviews/rc-*.md | 033 |
+| RC | SQA Review Record | docs/sqa/reviews/rc-*.md | 035 |
 | TM | Traceability Matrix | docs/sqa/traceability-matrix.md | 002 |
 
 ## Languages

docs/milestones/mil-010-wiki-token-and-access-token-guide.md

@@ -0,0 +1,77 @@
+# MIL-010 Wiki Token Accepted and Access-Token Guide in the Wiki
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-010 |
+| CrossReference | [BC-001], [US-001], [MIL-005] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S02 | Initial version | [9cca295] |
+
+---
+
+## Purpose
+
+Decide whether one `.env` can serve both RepoFoundry and the publishing of its wiki, and whether the guide for creating the access tokens belongs to the wiki. The wiki is published with its own Gitea token, `TOKEN_FOR_GITEA_WIKI`, which has only the repository write scope. Today `create-project.sh` refuses a `.env` that holds it, because it rejects every key it does not know. The guide for creating the tokens lives in `howto/`, outside the wiki that is published in English, Danish and Bahasa Malaysia.
+
+## Deliverable
+
+`create-project.sh` that accepts `TOKEN_FOR_GITEA_WIKI` in `.env`: the key is optional, checked like the other tokens, kept out of every message and never used or asked for. The credential rules read the same everywhere: `GITEA_TOKEN` is always needed, `GITHUB_PAT` and `GITHUB_USER` only when GitHub is chosen, `TOKEN_FOR_GITEA_WIKI` never. The guide for creating the access tokens moves from `howto/create-access-tokens.md` to the wiki page `AccessTokens`, with a Danish and a Bahasa Malaysia translation and its pictures in `wiki/img/`; `README.md`, the wiki Home pages, the sidebar and the SSH and tokens pages link to it. The tests cover the cases below.
+
+The credentials the script asks for do not change, and no host request changes. The use cases and models are not changed: no concept, operation or class is added. [US-001] gets this phase in its CrossReference and one acceptance criterion on US-001.05.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | A `.env` that holds `TOKEN_FOR_GITEA_WIKI` is read without an error, and a `.env` without it behaves as before | Tests pass | An error for the key, or a changed result without it |
+| 2 | A value of `TOKEN_FOR_GITEA_WIKI` that is not a valid token is refused with a message that names the key and never shows the value | Tests pass | The value shown, or an invalid value accepted |
+| 3 | The value is registered as a secret: it appears in no message, summary or trace, and is never written to the project's own `.env` | Tests pass | The value shown or written |
+| 4 | The key is never asked for, with or without GitHub chosen | Tests pass | A prompt for the key |
+| 5 | `GITHUB_PAT` and `GITHUB_USER` are asked only when GitHub is chosen, as before | Tests pass | A prompt without GitHub, or none with it |
+| 6 | `.env.example` is read without an error and documents the key as optional | Tests pass | An error, or the key undocumented |
+| 7 | The page `AccessTokens` exists in English, Danish and Bahasa Malaysia; each translation names the hash of the English page it follows, and the hash matches | Reviewed by S02 | A missing language or a stale hash |
+| 8 | The nine pictures are in `wiki/img/`, `howto/` is gone, and no file refers to `howto/` | Reviewed by S02 | A broken or leftover reference |
+| 9 | `README.md`, the wiki Home pages, the sidebar and the SSH and tokens pages state the same required and optional keys and link to `AccessTokens` | Reviewed by S02 | A page that contradicts the code |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| [MIL-005] | The `.env` parser, the credential checks and the credential prompts are the ones this phase extends |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| Objective 9 (a credential not provided in `.env` is asked, never exposed) | [BC-001] |
+| User story US-001.05 | [US-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S01 |
+| Approving reviewer | S02 |
+
+## Target Date
+
+2026-12-30 — proposed; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Accept TOKEN_FOR_GITEA_WIKI in .env | Add the key to `CREDENTIAL_KEYS` (`src/lib/constants.sh`) so the parser no longer rejects a `.env` that is shared with the wiki publishing. In `validate_credentials` (`src/lib/config.sh`) register its value as a secret and check it like the other tokens; it is never asked for and never written to the project's own `.env`. Add it, as optional, to `.env.example` and the header of `src/create-project.sh`. Test the key accepted, an invalid value refused without showing it, and `.env.example` read. | No | |
+| 2 | Move the access-token guide to the wiki | `git mv` `howto/create-access-tokens.md` to `wiki/AccessTokens.md` and its nine pictures to `wiki/img/`. Add the Danish and Bahasa Malaysia translations with the source-hash header the other pages use, and refresh the hashes of the pages whose English text changed. Link the page from `README.md` (it replaces the `howto/` links), the Home pages, the sidebar and the SSH and tokens pages. | No | |
+| 3 | Document which credentials are required | Say in `README.md`, the SSH and tokens pages, the guide and `.env.example` that `GITEA_TOKEN` is always needed, `GITHUB_PAT` and `GITHUB_USER` only when GitHub is chosen (the mirror), and `TOKEN_FOR_GITEA_WIKI` is optional and used only to publish the wiki. | No | |
+
+---
+
+[BC-001]: ../business-case.md
+[US-001]: ../user-stories.md
+[MIL-005]: ./mil-005-credentials.md
+[9cca295]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/9cca29579f032538902e9cfe929bb3c7768281ab

docs/milestones/mil-011-release-0-3-4.md

@@ -0,0 +1,73 @@
+# MIL-011 Release 0.3.4
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | MIL-011 |
+| CrossReference | [BC-001], [US-001], [MIL-010] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S02 | Initial version | [5f42d66] |
+
+---
+
+## Purpose
+
+Decide whether the work merged since `v0.3.3` is released as version 0.3.4. The last release is `v0.3.3` (2026-10-09); `main` is 24 commits ahead, and `VERSION` still says 0.3.3. [MIL-010] added no version bump, so the accepted `TOKEN_FOR_GITEA_WIKI` key and the wiki in three languages are in no release. A release is deliberate: the Release workflow runs only on request, defaults to a dry run, and refuses a version that has no entry in `CHANGELOG.md`.
+
+## Deliverable
+
+Version 0.3.4 of `create-project.sh`, released on Gitea: `VERSION` and the `--version` check say 0.3.4; `CHANGELOG.md` has a dated `## [0.3.4]` entry that lists every change since `v0.3.3` in the order Breaking, Added, Changed, Fixed, with `## [Unreleased]` left empty; the tag `v0.3.4` and its release page exist, made by the Release workflow from the tip of `main`, and the moving tag `v0` points to it.
+
+The change is a patch release: the one change to the script is that a `.env` that holds `TOKEN_FOR_GITEA_WIKI` is accepted ([MIL-010]), and the rest is documentation and the wiki. The credentials the script asks for, its host requests and its steps do not change. The framework pin is not part of this phase.
+
+## Go / No-Go Criteria
+
+| # | Criterion (objectively checkable) | Go | No-Go |
+| --- | --- | --- | --- |
+| 1 | `create-project.sh --version` prints `RepoFoundry 0.3.4` | Tests pass | Another version |
+| 2 | `CHANGELOG.md` has a `## [0.3.4]` entry with its date, in the groups Breaking, Added, Changed, Fixed, that names `TOKEN_FOR_GITEA_WIKI`, the wiki in English, Danish and Bahasa Malaysia, and the guide moved from `howto/` to the wiki; `## [Unreleased]` holds no entry | Reviewed by S02 | An entry missing, or text left under Unreleased |
+| 3 | The Quality run on the tip of `main` is green, and no test fails that passed at `v0.3.3` | Tests pass | A new failure |
+| 4 | The Release workflow, run with version `0.3.4` and `dry_run` true, checks the version, the tip of `main` and the changelog entry and writes nothing | Dry run passes | The dry run reports an error |
+| 5 | After the run with `dry_run` false, the tag `v0.3.4` and its release page exist on Gitea, and the page text is the changelog entry | Verified on Gitea | No tag, no page, or another text |
+| 6 | The moving tag `v0` points to the same commit as `v0.3.4` | Verified on Gitea | `v0` elsewhere |
+
+## Dependencies
+
+| Depends on | Reason |
+| --- | --- |
+| [MIL-010] | The accepted `.env` key and the wiki pages are what the release ships, and all of it must be merged first |
+
+## Traceability
+
+| Business Case objective / KPI / user story | Reference |
+| --- | --- |
+| Release of the script that creates a project repeatably | [BC-001] |
+| User story US-001 | [US-001] |
+
+## Ownership
+
+| Role | Stakeholder ID (SA) |
+| --- | --- |
+| Owner | S01 |
+| Approving reviewer | S02 |
+
+## Target Date
+
+2027-01-05 — proposed; the Business Case sets no deadline.
+
+## Tasks
+
+| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
+| --- | --- | --- | --- | --- |
+| 1 | Bump the version to 0.3.4 and write the changelog entry | Set `VERSION` in `src/lib/constants.sh` to 0.3.4 and the `--version` check in `tests/test-security.sh` to match. In `CHANGELOG.md` move the entries of `## [Unreleased]` under a dated `## [0.3.4]` and add what has merged since `v0.3.3`: `TOKEN_FOR_GITEA_WIKI` accepted in `.env` ([MIL-010]); the wiki in English, Danish and Bahasa Malaysia; the access-token guide moved from `howto/` to the wiki; the credential rules written down (`GITHUB_PAT` and `GITHUB_USER` only when GitHub is chosen). Leave `## [Unreleased]` empty. | No | |
+| 2 | Release v0.3.4 | After the pull request of task 1 is merged, run the Release workflow on `main` with version `0.3.4` and `dry_run` true, read its output, then run it again with `dry_run` false. Check that the tag, the release page and the moving tag `v0` are as in criteria 5 and 6. Starting the second run is S01's decision. | No | |
+
+---
+
+[BC-001]: ../business-case.md
+[US-001]: ../user-stories.md
+[MIL-010]: ./mil-010-wiki-token-and-access-token-guide.md
+[5f42d66]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/5f42d660cf2a4a5e8b7ef7fa20824bc527802597

docs/project-plan.md

@@ -4,23 +4,23 @@
 | Key | Value |
 | --- | --- |
 | ID | PP-001 |
-| CrossReference | [BC-001], [SA-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009], [US-001] |
+| CrossReference | [BC-001], [SA-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009], [MIL-010], [MIL-011], [US-001] |
 
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-08 | Deprecated | Jens Tirsvad Nielsen | S02 | Added phase MIL-008 (proposed dates 2026-12-14 to 2026-12-18): the local project has origin as its only remote | [039a28c] |
-| 2026-10-08 | Accepted | Jens Tirsvad Nielsen | S02 | Added phase MIL-009 (proposed dates 2026-12-21 to 2026-12-23): the framework files .claude, .agents and AGENTS.md are excluded from git | [08cb484] |
+| 2026-10-13 | Deprecated | Jens Tirsvad Nielsen | S02 | Added phase MIL-010 (proposed dates 2026-12-28 to 2026-12-30): the wiki token is accepted in .env and the access-token guide moves to the wiki | [9cca295] |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S02 | Added phase MIL-011 (proposed dates 2027-01-04 to 2027-01-05): release 0.3.4 | [5f42d66] |
 
 ---
 
 ## Purpose
 
-Schedule the nine phases that deliver RepoFoundry (`create-project.sh` and its documentation) in dependency order. The Business Case sets no deadline, so the dates below are proposals for S01 to confirm.
+Schedule the eleven phases that deliver RepoFoundry (`create-project.sh` and its documentation) in dependency order. The Business Case sets no deadline, so the dates below are proposals for S01 to confirm.
 
 ## Planning Assumptions
 
-- Week 1 starts 2026-10-05; the plan ends by 2026-12-23 (the last four phases are proposed).
+- Week 1 starts 2026-10-05; the plan ends by 2027-01-05 (the last six phases are proposed).
 - Phase length: two weeks.
 - S01 and S02 review each phase through a pull request, as described in [SA-001]. For now one person holds both roles.
 - The PO language is English, so no translated copies are kept.
@@ -38,6 +38,8 @@ Schedule the nine phases that deliver RepoFoundry (`create-project.sh` and its d
 | Framework Checklists and Usage | [MIL-007] | 2026-12-07 to 2026-12-11 | 2026-12-11 | S01 | US-001.07 | qc fetched with the framework; global command; README usage | |
 | Gitea Is the Only Remote | [MIL-008] | 2026-12-14 to 2026-12-18 | 2026-12-18 | S01 | US-001.03 | The local project has `origin` only; GitHub is reached through the mirror | |
 | Framework Files Excluded from Git | [MIL-009] | 2026-12-21 to 2026-12-23 | 2026-12-23 | S01 | US-001.03 | `.claude`, `.agents` and `AGENTS.md` excluded from git in the new project | |
+| Wiki Token and Access-Token Guide | [MIL-010] | 2026-12-28 to 2026-12-30 | 2026-12-30 | S01 | US-001.05 | `TOKEN_FOR_GITEA_WIKI` accepted in `.env`; access-token guide in the wiki | |
+| Release 0.3.4 | [MIL-011] | 2027-01-04 to 2027-01-05 | 2027-01-05 | S01 | US-001 | Version 0.3.4 released on Gitea with its changelog entry | |
 
 ```plantuml
 @startgantt
@@ -60,6 +62,10 @@ Project starts 2026-10-05
 [Gitea Is the Only Remote Go/No-Go] happens 2026-12-18
 [Framework Files Excluded from Git] starts 2026-12-21 and ends 2026-12-23
 [Framework Files Excluded from Git Go/No-Go] happens 2026-12-23
+[Wiki Token and Access-Token Guide] starts 2026-12-28 and ends 2026-12-30
+[Wiki Token and Access-Token Guide Go/No-Go] happens 2026-12-30
+[Release 0.3.4] starts 2027-01-04 and ends 2027-01-05
+[Release 0.3.4 Go/No-Go] happens 2027-01-05
 @endgantt
 ```
 
@@ -80,11 +86,13 @@ Project starts 2026-10-05
 | README usage from the target folder and as a global command | [MIL-007] |
 | The local project has `origin` as its only remote | [MIL-008] |
 | `.claude`, `.agents` and `AGENTS.md` excluded from git in the new project | [MIL-009] |
+| `TOKEN_FOR_GITEA_WIKI` accepted in `.env`; access-token guide in the wiki | [MIL-010] |
+| Version 0.3.4 released | [MIL-011] |
 
 ## Dependencies
 
 ```
-MIL-001 → MIL-002 → MIL-003 → MIL-004 → MIL-005 → MIL-006 → MIL-007 → MIL-008 → MIL-009
+MIL-001 → MIL-002 → MIL-003 → MIL-004 → MIL-005 → MIL-006 → MIL-007 → MIL-008 → MIL-009 → MIL-010 → MIL-011
 ```
 
 A No-Go moves every later date by the time needed to rework the failed criteria.
@@ -117,11 +125,13 @@ A No-Go moves every later date by the time needed to rework the failed criteria.
 [MIL-007]: ./milestones/mil-007-framework-checklists.md
 [MIL-008]: ./milestones/mil-008-gitea-only-remote.md
 [MIL-009]: ./milestones/mil-009-exclude-framework-files.md
+[MIL-010]: ./milestones/mil-010-wiki-token-and-access-token-guide.md
+[MIL-011]: ./milestones/mil-011-release-0-3-4.md
 [US-001]: ./user-stories.md
 [UC-001]: ./uc-001/uc.md
 [SSD-001]: ./uc-001/ssd.md
 [Milestone 43]: https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry/milestone/43
 [Milestone 44]: https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry/milestone/44
 [Milestone 45]: https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry/milestone/45
-[039a28c]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/039a28c01b56f8cf0af73f55d1a604b43d67ba03
-[08cb484]: https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry/commit/08cb484498bab3d9480decda9df89e9564438185
+[9cca295]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/9cca29579f032538902e9cfe929bb3c7768281ab
+[5f42d66]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/5f42d660cf2a4a5e8b7ef7fa20824bc527802597

docs/sqa/reviews/rc-033-wiki-token-and-access-token-guide.md

@@ -0,0 +1,76 @@
+# SQA Review Record: Wiki token accepted and access-token guide in the wiki
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-033 |
+| CrossReference | [MIL-010], [QC-MIL-001], [MIL-005], [BC-001], [US-001], [PP-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Deprecated | Jens Tirsvad Nielsen | S02 | Action item closed: the published wiki did not show the pictures, so the guide references them by their address on `main` | [bfe402d] |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S02 | Last action item closed: the nine pictures of AccessTokens, in three languages, return 200 on the published wiki | [294bb61] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-010], and the changes it causes in [US-001], [PP-001] and [TM-001].
+- Why: the wiki is published with its own Gitea token, `TOKEN_FOR_GITEA_WIKI`, which has only the repository write scope. A `.env` that holds it is refused today, because the parser rejects every key it does not know. The guide for creating the access tokens is also moved from `howto/` into the wiki, which is published in English, Danish and Bahasa Malaysia. The phase adds the key as an optional, never-asked credential, and states which credentials are required when.
+- Checklist used: [QC-MIL-001] for [MIL-010]. The other artifacts were changed, not created; their change is checked below.
+- Review date: 2026-10-13
+
+## Checklist Results (QC-MIL-001)
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | `create-project.sh` accepting `TOKEN_FOR_GITEA_WIKI` as an optional key that is checked, masked and never used or asked for; the access-token guide as the wiki page `AccessTokens` in three languages with its pictures in `wiki/img/`; the links in the README, Home pages, sidebar and SSH and tokens pages; the tests. The credentials the script asks for and every host request are stated as unchanged. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Nine criteria, each with an objective Go and No-Go: key accepted, invalid value refused without being shown, value registered as a secret and never written, never asked, GitHub keys asked only when GitHub is chosen, `.env.example` read, the page in three languages with matching hashes, no reference to `howto/`, and the documents in agreement. Criteria 7 to 9 are "Reviewed by S02", as in [MIL-009]. |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | [MIL-005], whose `.env` parser, credential checks and prompts are extended, with its reason. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | Objective 9 of [BC-001] (a credential not provided in `.env` is asked, never exposed), and US-001.05 of [US-001]. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Owner S01, approving reviewer S02. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2026-12-30, proposed in [PP-001]; the window 2026-12-28 (Monday) to 2026-12-30 (Wednesday) follows [MIL-009], which ends Wednesday 2026-12-23. The Business Case sets no deadline. |
+
+## Change checks on the other artifacts
+
+| Artifact | Change | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| [US-001] | [MIL-010] in the CrossReference; one acceptance criterion and the Traces row of US-001.05 | Pass | One given/when/then: a `.env` that also holds `TOKEN_FOR_GITEA_WIKI` is read, the key is never asked for and never shown. No new story: the behavior belongs to the credentials story. |
+| [PP-001] | Phase [MIL-010], its window, the Gantt, the scope coverage, the dependency chain, "ten phases" and the end date | Pass | Proposed dates 2026-12-28 to 2026-12-30. |
+| [TM-001] | Row for [MIL-010] and this record; Last Reviewed updated for each changed artifact | Pass | See the matrix. |
+
+The Business Case, the use cases, the operation contracts and the models are not changed: no concept, operation or class is added, and the credentials the script asks for are the same.
+
+Mechanical checks run for this review: every link definition of the changed files points at an existing file and none is unused; the Gantt dates fall on the weekdays named above; [MIL-010] has 9 criteria and 3 tasks; `sync-project.sh --milestone MIL-010` parses it (milestone 103, issues #83 to #85 created on Gitea); the English page `AccessTokens` and its two translations carry the same hash, and the Home and SSH and tokens translations carry the hash of their changed English pages; the credential tests (`tests/run-tests.sh credentials`) pass, including the new test for the wiki token.
+
+Not covered by this review: the code, the wiki pages and the README are the tasks of [MIL-010] and are checked at its gate. Two tests of the full suite (`test_the_framework_checklists_are_fetched` and `test_an_empty_qc_is_filled_by_a_second_run_and_a_complete_one_is_not_changed`) fail on an untouched `HEAD` as well; they fetch the framework checklists and are not caused by this phase.
+
+## Consequences S02 accepts with a Go
+
+- The shared `publish-wiki` workflow publishes the Markdown pages but not `wiki/img/`: the pictures returned 404 on the published wiki. The three pages therefore reference them by their address on `main` (`raw/branch/main/wiki/img/`), which resolves once the pull request is merged.
+- The pictures keep their English labels in the Danish and Bahasa Malaysia pages.
+
+## Overall Verdict
+
+Go — every criterion of the checklist passes and the changed documents agree with each other. Drafted by Claude Code for S02; the author and reviewer are the same person for now, as in [RC-032]. S02 accepted [MIL-010] in chat on 2026-10-13 and asked for this record; the Version History rows of [MIL-010] and the changed documents were set to `Accepted` and the rows before them to `Deprecated`.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| Closed 2026-10-13: the pictures were missing, the pages now use addresses on `main`, and after the merge of the fix all 27 picture references (nine in each of the three languages) return 200 on the published wiki | S01 | Done |
+
+---
+
+[MIL-010]: ../../milestones/mil-010-wiki-token-and-access-token-guide.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
+[MIL-005]: ../../milestones/mil-005-credentials.md
+[MIL-009]: ../../milestones/mil-009-exclude-framework-files.md
+[BC-001]: ../../business-case.md
+[US-001]: ../../user-stories.md
+[PP-001]: ../../project-plan.md
+[TM-001]: ../traceability-matrix.md
+[RC-032]: ./rc-032-exclude-framework-files.md
+[bfe402d]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/bfe402d217df6559ce9c018011393ba33e199592
+[294bb61]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/294bb61e53142fffce8eb6545356163ddd791148

docs/sqa/reviews/rc-034-release-0-3-4.md

@@ -0,0 +1,71 @@
+# SQA Review Record: Release 0.3.4
+
+## Metadata
+| Key | Value |
+| --- | --- |
+| ID | RC-034 |
+| CrossReference | [MIL-011], [QC-MIL-001], [MIL-010], [BC-001], [US-001], [PP-001] |
+
+## Version History
+| Date | Status | Author | Reviewer | Change | Commit |
+| --- | --- | --- | --- | --- | --- |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S02 | Initial version: draft for S02's decision | [5f42d66] |
+
+---
+
+## Artifact Under Review
+
+- Instance reviewed: [MIL-011], and the changes it causes in [US-001], [PP-001] and [TM-001].
+- Why: the last release is `v0.3.3` (2026-10-09), `main` is 24 commits ahead and `VERSION` still says 0.3.3. [MIL-010] added no version bump, so the accepted `TOKEN_FOR_GITEA_WIKI` key and the wiki in three languages are in no release. The phase bumps the version to 0.3.4, writes the changelog entry and releases `v0.3.4` with the Release workflow, whose real run stays S01's decision.
+- Checklist used: [QC-MIL-001] for [MIL-011]. The other artifacts were changed, not created; their change is checked below.
+- Review date: 2026-10-13
+
+## Checklist Results (QC-MIL-001)
+
+| # | Criterion | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| 1 | A concrete deliverable is defined for every gate | Pass | Version 0.3.4: `VERSION` and the `--version` check, a dated `## [0.3.4]` changelog entry with `[Unreleased]` empty, the tag `v0.3.4` and its release page, and the moving tag `v0`. What does not change (credentials asked, host requests, steps, framework pin) is stated. |
+| 2 | Explicit Go/No-Go criteria are stated for each gate | Pass | Six criteria, each with an objective Go and No-Go: the version output, the changelog entry, the Quality run and no new test failure, the dry run of the Release workflow, the tag and release page, and the moving tag. Criterion 2 is "Reviewed by S02"; criteria 5 and 6 are "Verified on Gitea". |
+| 3 | Dependencies on other milestones are explicitly mapped | Pass | [MIL-010], whose key, wiki pages and guide the release ships and which must be merged first. |
+| 4 | Each milestone is traceable to a Business Case objective or KPI | Pass | The Business Case ([BC-001]) as the script's release, and [US-001]. No objective is added or changed. |
+| 5 | Milestone owner and approving reviewer are identified | Pass | Owner S01, approving reviewer S02. |
+| 6 | Milestone has a defined target date consistent with project constraints | Pass | 2027-01-05, proposed in [PP-001]; the window 2027-01-04 (Monday) to 2027-01-05 (Tuesday) follows [MIL-010], which ends Wednesday 2026-12-30. The Business Case sets no deadline. |
+
+## Change checks on the other artifacts
+
+| Artifact | Change | Status | Evidence/Notes |
+| --- | --- | --- | --- |
+| [US-001] | [MIL-011] in the CrossReference | Pass | Link only; no story or acceptance criterion changes. |
+| [PP-001] | Phase [MIL-011], its window, the Gantt, the scope coverage, the dependency chain, "eleven phases" and the end date | Pass | Proposed dates 2027-01-04 to 2027-01-05. |
+| [TM-001] | Row for [MIL-011] and this record; Last Reviewed updated for each changed artifact | Pass | See the matrix. |
+
+Mechanical checks run for this review: every link definition of the changed files points at an existing file and none is unused; the Gantt dates fall on the weekdays named above; [MIL-011] has 6 criteria and 2 tasks; `sync-project.sh --milestone MIL-011` parses it (milestone 104, issues #90 and #91 created on Gitea); the version appears only in `src/lib/constants.sh` and `tests/test-security.sh` outside the changelog and the review records.
+
+Not covered by this review: the version bump, the changelog entry and the release are the tasks of [MIL-011] and are checked at its gate.
+
+## Consequences S02 accepts with a Go
+
+- The release ships everything on `main` since `v0.3.3`, including the wiki and documentation changes, not only the script change.
+- The real run of the Release workflow is not started by this record; S01 starts it when the dry run is read.
+
+## Overall Verdict
+
+Go — every criterion of the checklist passes and the changed documents agree with each other. Drafted by Claude Code for S02; the author and reviewer are the same person for now, as in [RC-033]. S02 accepted [MIL-011] in chat on 2026-10-13 and asked for this record; the Version History rows of [MIL-011] and the changed documents were set to `Accepted` and the rows before them to `Deprecated`.
+
+## Action Items
+
+| Action | Owner | Due |
+| --- | --- | --- |
+| None | - | - |
+
+---
+
+[MIL-011]: ../../milestones/mil-011-release-0-3-4.md
+[QC-MIL-001]: ../../../framework/qc/artifacts/qc-milestones-gateways.md
+[MIL-010]: ../../milestones/mil-010-wiki-token-and-access-token-guide.md
+[BC-001]: ../../business-case.md
+[US-001]: ../../user-stories.md
+[PP-001]: ../../project-plan.md
+[TM-001]: ../traceability-matrix.md
+[RC-033]: ./rc-033-wiki-token-and-access-token-guide.md
+[5f42d66]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/5f42d660cf2a4a5e8b7ef7fa20824bc527802597

docs/sqa/traceability-matrix.md

@@ -9,8 +9,8 @@
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-08 | Deprecated | Jens Tirsvad Nielsen | S02 | Added MIL-009 (framework files excluded from git); not yet reviewed | [08cb484] |
-| 2026-10-08 | Accepted | Jens Tirsvad Nielsen | S02 | Added review RC-032 (MIL-009: framework files excluded from git), Go | [1b1b6be] |
+| 2026-10-13 | Deprecated | Jens Tirsvad Nielsen | S02 | Added MIL-010 (wiki token accepted, access-token guide in the wiki) and review RC-033, Go | [9cca295] |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S02 | Added MIL-011 (release 0.3.4) and review RC-034, Go | [5f42d66] |
 
 ---
 
@@ -24,9 +24,9 @@ updated whenever an artifact instance is created or reviewed.
 
 | Artifact Instance | Type | Upstream (Backward Link) | Downstream (Forward Link) | Last Reviewed (RC-ID) |
 | --- | --- | --- | --- | --- |
-| [BC-001] | BC | - | [SA-001], [PP-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009], [US-001], [UCD-001] | [RC-010], [RC-018], [RC-020], [RC-022], [RC-029], [RC-031], [RC-032] |
+| [BC-001] | BC | - | [SA-001], [PP-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009], [MIL-010], [MIL-011], [US-001], [UCD-001] | [RC-010], [RC-018], [RC-020], [RC-022], [RC-029], [RC-031], [RC-032], [RC-033], [RC-034] |
 | [SA-001] | SA | [BC-001] | [UCD-001], [UC-001], [DICT-001] | [RC-013] |
-| [PP-001] | PP | [BC-001], [SA-001] | [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009] | [RC-012], [RC-018], [RC-020], [RC-022], [RC-031], [RC-032] |
+| [PP-001] | PP | [BC-001], [SA-001] | [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009], [MIL-010], [MIL-011] | [RC-012], [RC-018], [RC-020], [RC-022], [RC-031], [RC-032], [RC-033], [RC-034] |
 | [MIL-001] | MIL | [BC-001], [PP-001] | [US-001] | [RC-011], [RC-016] |
 | [MIL-002] | MIL | [BC-001], [PP-001] | [US-001] | [RC-014], [RC-017] |
 | [MIL-003] | MIL | [BC-001], [PP-001] | [US-001] | [RC-015], [RC-017], [RC-031] |
@@ -36,8 +36,10 @@ updated whenever an artifact instance is created or reviewed.
 | [MIL-007] | MIL | [BC-001], [PP-001] | [US-001], [UC-002] | [RC-022], [RC-029], [RC-030] |
 | [MIL-008] | MIL | [BC-001], [PP-001] | [US-001] | [RC-031] |
 | [MIL-009] | MIL | [BC-001], [PP-001] | [US-001] | [RC-032] |
+| [MIL-010] | MIL | [BC-001], [PP-001], [MIL-005] | [US-001] | [RC-033] |
+| [MIL-011] | MIL | [BC-001], [PP-001], [MIL-010] | [US-001] | [RC-034] |
 | [UCD-001] | UCD | [BC-001], [SA-001] | [US-001], [UC-001], [UC-002] | [RC-009], [RC-023] |
-| [US-001] | US | [BC-001], [UCD-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009] | [UC-001] | [RC-001], [RC-020], [RC-022], [RC-029], [RC-030], [RC-031], [RC-032] |
+| [US-001] | US | [BC-001], [UCD-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009], [MIL-010], [MIL-011] | [UC-001] | [RC-001], [RC-020], [RC-022], [RC-029], [RC-030], [RC-031], [RC-032], [RC-033], [RC-034] |
 | [UC-001] | UC | [UCD-001], [US-001], [SA-001] | [SSD-001], [DM-001] | [RC-002], [RC-020], [RC-023], [RC-031], [RC-032] |
 | [UC-002] | UC | [UCD-001], [US-001], [SA-001], [BC-001] | [SSD-002], [DM-003] | [RC-023], [RC-029], [RC-030] |
 | [SSD-002] | SSD | [UC-002], [DM-003] | [OC-002] | [RC-024], [RC-029] |
@@ -73,6 +75,8 @@ updated whenever an artifact instance is created or reviewed.
 [MIL-007]: ../milestones/mil-007-framework-checklists.md
 [MIL-008]: ../milestones/mil-008-gitea-only-remote.md
 [MIL-009]: ../milestones/mil-009-exclude-framework-files.md
+[MIL-010]: ../milestones/mil-010-wiki-token-and-access-token-guide.md
+[MIL-011]: ../milestones/mil-011-release-0-3-4.md
 [RC-018]: ./reviews/rc-018-mil-004.md
 [RC-019]: ./reviews/rc-019-mil-004-code.md
 [RC-020]: ./reviews/rc-020-mil-005.md
@@ -88,6 +92,8 @@ updated whenever an artifact instance is created or reviewed.
 [RC-030]: ./reviews/rc-030-env-optional.md
 [RC-031]: ./reviews/rc-031-gitea-only-remote.md
 [RC-032]: ./reviews/rc-032-exclude-framework-files.md
+[RC-033]: ./reviews/rc-033-wiki-token-and-access-token-guide.md
+[RC-034]: ./reviews/rc-034-release-0-3-4.md
 [DCD-001]: ../uc-001/dcd.md
 [DCD-002]: ../dcd.md
 [UCD-001]: ../use-case-diagram.md
@@ -122,5 +128,5 @@ updated whenever an artifact instance is created or reviewed.
 [RC-015]: ./reviews/rc-015-mil-003.md
 [RC-016]: ./reviews/rc-016-create-project-sh.md
 [RC-017]: ./reviews/rc-017-e2e-security-review.md
-[08cb484]: https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry/commit/08cb484498bab3d9480decda9df89e9564438185
-[1b1b6be]: https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry/commit/1b1b6bec2effe5f566479ef94fcc5bc73a9fd609
+[9cca295]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/9cca29579f032538902e9cfe929bb3c7768281ab
+[5f42d66]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/5f42d660cf2a4a5e8b7ef7fa20824bc527802597

docs/user-stories.md

@@ -4,13 +4,13 @@
 | Key | Value |
 | --- | --- |
 | ID | US-001 |
-| CrossReference | [BC-001], [UCD-001], [UC-002], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009] |
+| CrossReference | [BC-001], [UCD-001], [UC-002], [MIL-001], [MIL-002], [MIL-003], [MIL-004], [MIL-005], [MIL-006], [MIL-007], [MIL-008], [MIL-009], [MIL-010], [MIL-011] |
 
 ## Version History
 | Date | Status | Author | Reviewer | Change | Commit |
 | --- | --- | --- | --- | --- | --- |
-| 2026-10-08 | Deprecated | Jens Tirsvad Nielsen | S02 | US-001.03: one remote, origin; no github remote (MIL-008) | [039a28c] |
-| 2026-10-08 | Accepted | Jens Tirsvad Nielsen | S02 | US-001.03: `.claude`, `.agents` and `AGENTS.md` are excluded from git; MIL-009 added to CrossReference | [08cb484] |
+| 2026-10-13 | Deprecated | Jens Tirsvad Nielsen | S02 | US-001.05: a `.env` shared with the wiki publishing may hold `TOKEN_FOR_GITEA_WIKI`, which is never asked for; MIL-010 added to CrossReference | [9cca295] |
+| 2026-10-13 | Accepted | Jens Tirsvad Nielsen | S02 | MIL-011 added to CrossReference | [5f42d66] |
 
 ---
 
@@ -90,11 +90,12 @@ The epic is split into seven stories, one per milestone (US-001.01 to US-001.07)
 - Given an entered credential is not valid, when the script checks it, then it asks again and never shows the value.
 - Given the project exists, when the Maintainer agrees, then the new project has a `.env` that holds only the credentials the project needs, is readable by its owner only and is ignored by git.
 - Given the Maintainer declines, or `.env` already exists in the project and the Maintainer declines replacing it, then no `.env` is written or replaced and the summary says so.
+- Given `.env` also holds `TOKEN_FOR_GITEA_WIKI`, when the script runs, then it is read without an error, is never asked for, with or without GitHub chosen, and never appears in output.
 - Given any run, then no credential appears in output, remotes, tracked files or the summary.
 
 | Traces to | Size | INVEST exceptions |
 | --- | --- | --- |
-| [UC-001] steps 2 and 9, [MIL-005] | fits one phase | Independent: needs the local project of US-001.03 |
+| [UC-001] steps 2 and 9, [MIL-005], [MIL-010] | fits one phase | Independent: needs the local project of US-001.03 |
 
 ### US-001.06 — Create a new project: choose the license in `config.env`
 
@@ -168,6 +169,8 @@ Valuable, Negotiable, Estimable, Small and Testable hold for each story. Indepen
 [MIL-007]: ./milestones/mil-007-framework-checklists.md
 [MIL-008]: ./milestones/mil-008-gitea-only-remote.md
 [MIL-009]: ./milestones/mil-009-exclude-framework-files.md
+[MIL-010]: ./milestones/mil-010-wiki-token-and-access-token-guide.md
+[MIL-011]: ./milestones/mil-011-release-0-3-4.md
 [PP-001]: ./project-plan.md
-[039a28c]: https://git.tirsystem.com/TirSystem-BashScript/repo_foundry/commit/039a28c01b56f8cf0af73f55d1a604b43d67ba03
-[08cb484]: https://git.tirsystem.com/TirSystem-BashScript/RepoFoundry/commit/08cb484498bab3d9480decda9df89e9564438185
+[9cca295]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/9cca29579f032538902e9cfe929bb3c7768281ab
+[5f42d66]: https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/commit/5f42d660cf2a4a5e8b7ef7fa20824bc527802597

src/create-project.sh

@@ -40,8 +40,9 @@
 #               the optional GITEA_SSH_PORT (default 10022), MIRROR_INTERVAL
 #               (default 10m0s) and FRAMEWORK_REPO (default
 #               TirSystem/SQA-QC-Framework, the submodule's OWNER/NAME)
-#   .env        GITHUB_PAT, GITHUB_USER, GITEA_TOKEN (all optional, each
-#               asked when missing)
+#   .env        GITHUB_PAT, GITHUB_USER (required only when GitHub is chosen),
+#               GITEA_TOKEN (always required); each is asked when missing.
+#               TOKEN_FOR_GITEA_WIKI is optional and not used here
 #
 # Environment
 #   REPOFOUNDRY_NAME       project name used in messages (default: RepoFoundry)

src/lib/config.sh

@@ -155,6 +155,11 @@ validate_credentials() {
   if [[ -n ${CREDENTIALS[GITHUB_PAT]:-} ]]; then
     SECRET_VALUES+=("${CREDENTIALS[GITHUB_PAT]}")
   fi
+  if [[ -n ${CREDENTIALS[TOKEN_FOR_GITEA_WIKI]:-} ]]; then
+    SECRET_VALUES+=("${CREDENTIALS[TOKEN_FOR_GITEA_WIKI]}")
+    is_valid_token "${CREDENTIALS[TOKEN_FOR_GITEA_WIKI]}" ||
+      die "TOKEN_FOR_GITEA_WIKI in $ENV_FILE is not a valid token ($HINT_TOKEN)"
+  fi
   if [[ -n ${CREDENTIALS[GITEA_TOKEN]:-} ]] &&
     ! is_valid_token "${CREDENTIALS[GITEA_TOKEN]}"; then
     die "GITEA_TOKEN in $ENV_FILE is not a valid token ($HINT_TOKEN)"

src/lib/constants.sh

@@ -8,7 +8,7 @@
 # shellcheck disable=SC2034  # read and written by the other library files
 
 readonly PROJECT_NAME="${REPOFOUNDRY_NAME:-RepoFoundry}"
-readonly VERSION="0.3.2"
+readonly VERSION="0.3.4"
 readonly EXIT_FAILURE=1
 readonly EXIT_USAGE=2
 readonly MAX_VALUE_LENGTH=2048
@@ -41,7 +41,9 @@ readonly CONFIG_KEYS=(GITHUB_API_URL GITHUB_WEB_URL GITEA_URL GITEA_API_URL
   GITEA_SSH_PORT MIRROR_INTERVAL FRAMEWORK_REPO
   PROJECT_NAME PROJECT_DESCRIPTION PROJECT_VISIBILITY GITEA_OWNER USE_GITHUB
   GITHUB_OWNER PROJECT_DIRECTORY ENABLE_PLAN_GATE PROJECT_LICENSE)
-readonly CREDENTIAL_KEYS=(GITHUB_PAT GITHUB_USER GITEA_TOKEN)
+# TOKEN_FOR_GITEA_WIKI belongs to the wiki publishing; it is accepted so that
+# one .env can serve both, checked and kept secret, but never used here.
+readonly CREDENTIAL_KEYS=(GITHUB_PAT GITHUB_USER GITEA_TOKEN TOKEN_FOR_GITEA_WIKI)
 
 # The configuration files: named by --config and --env, or chosen by
 # locate_config_file. The origin is named, folder or checkout.

tests/test-config.sh

@@ -100,6 +100,7 @@ token too short|GITEA_TOKEN=short\n|not a valid token
 token with a backslash|GITEA_TOKEN=abc\\defgh12345\n|not a valid token
 bad GitHub token|GITEA_TOKEN=abcdefgh12345\nGITHUB_PAT=bad token\n|GITHUB_PAT
 bad GitHub user|GITEA_TOKEN=abcdefgh12345\nGITHUB_USER=-bad-\n|GITHUB_USER
+bad wiki token|TOKEN_FOR_GITEA_WIKI=short\n|TOKEN_FOR_GITEA_WIKI
 EOF
 }
 

tests/test-credentials.sh

@@ -136,6 +136,21 @@ test_github_credentials_are_asked_only_when_github_is_chosen() {
   assert_not_contains "token not shown" "$OUT$ERR" "$FAKE_GITHUB_PAT"
 }
 
+test_the_wiki_token_is_accepted_never_asked_and_never_shown() {
+  local wiki_token="wikiFAKEtoken1234567890"
+  setup_hosts
+  printf 'GITEA_TOKEN=%s\nTOKEN_FOR_GITEA_WIKI=%s\n' "$FAKE_GITEA_TOKEN" "$wiki_token" >"$WORK/.env"
+  run_dry_cred "$ANSWERS_GITEA_ONLY"
+  assert_status "accepted in .env" 0 "$STATUS"
+  assert_not_contains "not asked" "$ERR" "wiki"
+  assert_not_contains "not shown" "$OUT$ERR" "$wiki_token"
+  run_dry_cred "$ANSWERS_GITHUB$FAKE_GITHUB_PAT${NL}octo-user$NL"
+  assert_status "accepted with GitHub chosen" 0 "$STATUS"
+  assert_not_contains "not asked with GitHub" "$ERR" "wiki"
+  assert_not_contains "not shown with GitHub" "$OUT$ERR" "$wiki_token"
+  assert_not_contains "never sent to a host" "$(calls)" "$wiki_token"
+}
+
 test_an_invalid_asked_value_is_asked_again_and_never_shown() {
   setup_hosts
   without_env

tests/test-security.sh

@@ -103,7 +103,7 @@ test_usage_errors() {
   assert_contains "help shows exit codes" "$OUT" "Exit codes"
   run_cli "" --version
   assert_status "version" 0 "$STATUS"
-  assert_contains "version output" "$OUT" "RepoFoundry 0.3.2"
+  assert_contains "version output" "$OUT" "RepoFoundry 0.3.4"
 }
 
 test_warns_when_env_is_not_ignored_by_git() {

wiki/AccessTokens.da.md

@@ -0,0 +1,197 @@
+<!-- translation of AccessTokens.md, source sha256 ed97e5f40645 -->
+
+> Dette er en oversættelse af [`AccessTokens`](AccessTokens). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
+
+[English](AccessTokens) | Dansk | [Bahasa Melayu](AccessTokens.ms)
+
+# Sådan opretter du de adgangstokens, RepoFoundry har brug for
+
+RepoFoundry taler med to værter og har brug for ét token til hver:
+
+| Token | Nøgle | Nødvendig | Type |
+| --- | --- | --- | --- |
+| Gitea-adgangstoken | `GITEA_TOKEN` | altid | et adgangstoken med scopes |
+| GitHub personal access token | `GITHUB_PAT` | påkrævet, når du vælger GitHub (spejlet) | et **klassisk** personal access token (PAT) |
+| Gitea-adgangstoken til wikien | `TOKEN_FOR_GITEA_WIKI` | valgfri (kun for at udgive wikien) | et adgangstoken kun med repository-skriveadgang (`write:repository`) |
+
+`TOKEN_FOR_GITEA_WIKI` bruges ikke af RepoFoundry. Det er nævnt her, fordi den samme `.env` kan indeholde det, og RepoFoundry accepterer det dér. Opret det på samme måde som Gitea-tokenet i del 1, og sæt kun flueben ved repository-skriveadgang.
+
+Denne vejledning viser de to første trin for trin. De røde tal i hvert billede svarer til de nummererede trin ved siden af.
+
+> **Om billederne.** De er tegninger af siderne, ikke skærmbilleder, så de ikke viser kontodata. Navne, farver og placeringen af en knap kan afvige lidt i din version af Gitea eller GitHub. Ordene med fed skrift i trinene er de etiketter, du skal lede efter. Et nyt token vises som prikker i billederne; på din skærm ser du den rigtige værdi.
+
+Den fulde liste over, hvad hvert token må, står under [Token permissions](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#token-permissions) i README. Denne vejledning er klik-for-klik-udgaven af den.
+
+Indhold:
+
+1. [Opret et Gitea-adgangstoken](#1-opret-et-gitea-adgangstoken)
+2. [Opret et GitHub personal access token (klassisk)](#2-opret-et-github-personal-access-token-klassisk)
+3. [Giv tokens til RepoFoundry](#3-giv-tokens-til-repofoundry)
+4. [Opbevar tokens sikkert](#4-opbevar-tokens-sikkert)
+5. [Hvis noget går galt](#5-hvis-noget-går-galt)
+
+---
+
+## 1. Opret et Gitea-adgangstoken
+
+Eksemplerne bruger `https://git.tirsystem.com`. Hvis din Gitea kører et andet sted, så brug den adresse, du har sat som `GITEA_URL` i `config.env`.
+
+### Trin 1. Åbn dine indstillinger
+
+Log ind på Gitea. Klik på din **avatar** øverst til højre (1), og vælg **Settings** (2).
+
+![Trin 1: avatarmenuen øverst til højre med Settings fremhævet](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-1-open-settings.svg)
+
+### Trin 2. Åbn "Applications"
+
+Klik på **Applications** (1) i menuen til venstre.
+
+Du kan også gå direkte dertil: `<din Gitea-adresse>/user/settings/applications`.
+
+![Trin 2: Applications i venstre menu i indstillingerne](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-2-applications.svg)
+
+### Trin 3. Udfyld token-formularen
+
+Rul til **Generate New Token** og udfyld den:
+
+1. **Token Name:** et navn, du kan genkende senere, for eksempel `RepoFoundry`.
+2. **Repository and Organization Access:** vælg **All (public, private, and limited)**. Et token, der er begrænset til **Public only**, kan ikke se private repositories eller organisationer, så oprettelse af et privat projekt ville fejle.
+3. **Select permissions:** sæt disse tre til **Read and Write**, og lad alle andre linjer stå på **No Access**:
+
+   | Permission | Niveau | Hvorfor RepoFoundry har brug for den |
+   | --- | --- | --- |
+   | `organization` | Read and Write | slå ejeren og dine rettigheder op, oprette repositories i en organisation |
+   | `repository` | Read and Write | oprette repositoriet og styre dets push-spejl |
+   | `user` | Read and Write | læse hvilken konto tokenet tilhører, og oprette et repository under din **egen** konto |
+
+4. Klik på **Generate Token**.
+
+![Trin 3: token-formularen med navn, adgangsvalg og tre permissions sat til Read and Write](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-3-token-form.svg)
+
+> **Opretter du kun projekter i organisationer?** Så kan `user` blive på **Read**. `Read and Write` på `user` er kun nødvendigt for at oprette et repository under din egen konto; uden det svarer Gitea `required=[write:user]`.
+
+### Trin 4. Kopiér tokenet nu
+
+Gitea viser det nye token **én gang**, i en grøn besked øverst på siden (1). Kopiér det (brug kopiknappen, hvis din version har en, eller markér teksten og tryk Ctrl+C, Cmd+C på en Mac), og gem det til [del 3 i denne vejledning](#3-giv-tokens-til-repofoundry). Det nye token står nu på listen under (2) med sine permissions, men listen viser aldrig værdien igen.
+
+Hvis du mister værdien, så slet tokenet og opret et nyt.
+
+![Trin 4: den grønne besked med det nye token og en Copy-knap, og tokenet på listen nedenunder](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-4-copy-token.svg)
+
+---
+
+## 2. Opret et GitHub personal access token (klassisk)
+
+Spring denne del over, hvis du ikke vil oprette et GitHub-repository (`USE_GITHUB=no`, eller du svarer nej, når du bliver spurgt). `GITHUB_PAT` er så ikke nødvendig.
+
+Brug et **klassisk** token. RepoFoundry er ikke testet med fine-grained tokens, fordi GitHub ikke dokumenterer nogen fine-grained permission til at oprette et repository.
+
+### Trin 1. Åbn dine indstillinger
+
+Log ind på GitHub. Klik på dit **profilbillede** øverst til højre (1), og vælg **Settings** (2).
+
+![Trin 1: profilmenuen øverst til højre med Settings fremhævet](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-1-open-settings.svg)
+
+### Trin 2. Åbn "Developer settings"
+
+Rul ned i bunden af sidebjælken til venstre, og klik på **Developer settings** (1). Det er det sidste punkt.
+
+![Trin 2: Developer settings nederst i sidebjælken til venstre](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-2-developer-settings.svg)
+
+### Trin 3. Vælg "Tokens (classic)"
+
+1. Åbn **Personal access tokens** i sidebjælken til venstre, og klik på **Tokens (classic)** (1).
+2. Klik på **Generate new token** (2).
+3. I menuen, der åbner, vælg **Generate new token (classic)** (3). Ikke det første punkt, som er den fine-grained slags.
+
+GitHub kan bede dig bekræfte din adgangskode eller en tofaktorkode. Gør det selv; ingen andre bør skrive den.
+
+![Trin 3: Tokens (classic) i sidebjælken og Generate new token (classic) i knapmenuen](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-3-tokens-classic.svg)
+
+> Direkte adresse: `https://github.com/settings/tokens/new`
+
+### Trin 4. Udfyld formularen
+
+1. **Note:** et navn, du kan genkende senere, for eksempel `RepoFoundry`.
+2. **Expiration:** vælg en dato. En kortere levetid begrænser skaden, hvis tokenet lækker; du opretter så et nyt token, når det udløber.
+3. **Select scopes:** sæt flueben ved scopes nedenfor og intet andet.
+
+   | Scope | Sæt flueben, når | Hvorfor |
+   | --- | --- | --- |
+   | `repo` | altid (private eller offentlige projekter) | opretter repositoriet og er den adgangskode, Gitea bruger til at pushe spejlet |
+   | `public_repo` i stedet for `repo` | **kun** offentlige projekter | nok til at oprette og pushe et offentligt repository; `repo` omfatter det allerede |
+   | `read:org` | kun hvis scriptet siger, at du ikke tilhører din organisation | lader scriptet kontrollere dit medlemskab af en organisation som ejer |
+
+   Når du sætter flueben ved `repo`, får de fem underscopes (`repo:status`, `repo_deployment`, `public_repo`, `repo:invite`, `security_events`) også flueben; det er forventet. Lad `workflow`, `write:packages` og resten stå uden flueben.
+
+4. Rul ned, og klik på **Generate token** (4).
+
+![Trin 4: formularen til et nyt token med note, udløb, scopet repo afkrydset og knappen Generate token](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-4-token-form.svg)
+
+> **`read:org` og `admin:org`.** README fastslår, at kontrollen virkede med et token, der havde `repo` og `admin:org`, og at `read:org` alene er utestet. Prøv `read:org` først. `admin:org` giver langt mere magt, end RepoFoundry har brug for, så brug det kun, hvis `read:org` ikke er nok.
+
+### Trin 5. Kopiér tokenet nu
+
+GitHub viser tokenet **én gang**, i en grøn boks øverst (1). Klik på kopiikonet ved siden af. Det begynder med `ghp_`. Gem det til [del 3 i denne vejledning](#3-giv-tokens-til-repofoundry).
+
+Hvis ejeren af det nye repository er en organisation, der bruger SAML single sign-on, skal tokenet også godkendes til den organisation: klik på listen over tokens på **Configure SSO** (2) ved tokenet og derefter **Authorize** for organisationen.
+
+![Trin 5: den grønne boks med det nye token og et kopiikon, og Configure SSO på listen over tokens](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-5-copy-token.svg)
+
+---
+
+## 3. Giv tokens til RepoFoundry
+
+Vælg én måde. Begge holder tokenet ude af `config.env` (et token dér bliver afvist).
+
+**Mulighed A: skriv det, når du bliver spurgt (intet gemmes).** Gør ingenting på forhånd. RepoFoundry spørger efter `Gitea access token` fra start og efter `GitHub personal access token` og `GitHub account name`, når du vælger GitHub. Det, du skriver, vises ikke på skærmen. Indsæt kun tokenet, uden mellemrum, linjeskift eller anførselstegn.
+
+**Mulighed B: gem dem i `.env` (bekvemt, almindelig tekst på disken).** I RepoFoundry-mappen:
+
+```bash
+cp .env.example .env
+chmod 600 .env          # Linux og macOS: kun du kan læse den
+```
+
+Åbn `.env` og udfyld værdierne; erstat teksten i vinkelparenteser, og fjern parenteserne:
+
+```text
+GITEA_TOKEN=<Gitea-tokenet>
+GITHUB_PAT=<GitHub-tokenet>
+GITHUB_USER=<dit GitHub-kontonavn>
+TOKEN_FOR_GITEA_WIKI=<Gitea-tokenet til wikien, kun repository-skriveadgang>
+```
+
+`GITHUB_PAT` og `GITHUB_USER` er kun påkrævede, når du vælger GitHub (spejlet); udelad dem ellers. `TOKEN_FOR_GITEA_WIKI` er valgfri og kun nødvendig for at udgive wikien. Git ignorerer `.env`. Du må aldrig committe den, sende den eller indsætte den i en chat eller en issue.
+
+Kontrollér derefter opsætningen med en prøvekørsel, som kun læser fra værterne og ikke opretter noget:
+
+```bash
+src/create-project.sh
+```
+
+---
+
+## 4. Opbevar tokens sikkert
+
+- Et token er en adgangskode. Enhver, der har det, kan gøre det, det tillader.
+- Giv hvert token kun den adgang, der står i denne vejledning, og en udløbsdato.
+- Indsæt aldrig et token i en kommandolinje, en URL, en commit, en issue eller en chat.
+- Hvis et token kan være lækket, så slet det med det samme og opret et nyt:
+  - Gitea: **Settings**, **Applications**, derefter **Delete** ved det token.
+  - GitHub: **Settings**, **Developer settings**, **Personal access tokens**, **Tokens (classic)**, derefter **Delete** ved det token.
+- Når et token udløber, så opret et nyt på samme måde og erstat det i `.env`.
+
+---
+
+## 5. Hvis noget går galt
+
+| Det, du ser | Sandsynlig årsag | Hvad du skal gøre |
+| --- | --- | --- |
+| `authentication failed: the token is missing, expired or invalid` | tokenet er skrevet forkert, er udløbet eller er slettet | opret et nyt token og brug det |
+| `the token is valid but not allowed to do this (check its scopes)` | en permission mangler | Gitea: sæt `organization`, `repository` og `user` til **Read and Write**. GitHub: sæt flueben ved `repo` |
+| Gitea svarer `required=[write:user]` | projektet oprettes under din egen konto | sæt `user` til **Read and Write** |
+| `Gitea owner '...' is neither your account (...) nor an organization the token can see` | tokenet er begrænset til **Public only**, eller ejernavnet er forkert | gør tokenet **All (public, private, and limited)**, eller ret ejeren |
+| `GitHub owner '...' is neither your account (...) nor an organization you belong to (or the token lacks the read:org scope)` | tokenet kan ikke se organisationen | sæt flueben ved `read:org`, og godkend tokenet til organisationen, hvis den bruger single sign-on |
+| det indsatte token bliver afvist igen og igen | mellemrum, et linjeskift eller anførselstegn fulgte med indsætningen | kopiér det igen og indsæt kun tokenet |
+| `GITHUB_USER is '...' but the token belongs to '...'` | en advarsel: navnet i `.env` er ikke tokenets konto | ingen handling nødvendig; RepoFoundry bruger den konto, tokenet tilhører |

wiki/AccessTokens.md

@@ -1,3 +1,5 @@
+English | [Dansk](AccessTokens.da) | [Bahasa Melayu](AccessTokens.ms)
+
 # How to create the access tokens RepoFoundry needs
 
 RepoFoundry talks to two hosts and needs one token for each:
@@ -5,10 +7,15 @@ RepoFoundry talks to two hosts and needs one token for each:
 | Token | Key | Needed | Type |
 | --- | --- | --- | --- |
 | Gitea access token | `GITEA_TOKEN` | always | an access token with scopes |
-| GitHub personal access token | `GITHUB_PAT` | only when you choose GitHub | a **classic** personal access token (PAT) |
+| GitHub personal access token | `GITHUB_PAT` | required when you choose GitHub (the mirror) | a **classic** personal access token (PAT) |
+| Gitea access token for the wiki | `TOKEN_FOR_GITEA_WIKI` | optional (only to publish the wiki) | an access token with the repository write scope (`write:repository`) only |
 
-This guide shows both, step by step. The red numbers in each picture match the
-numbered steps next to it.
+`TOKEN_FOR_GITEA_WIKI` is not used by RepoFoundry. It is listed because the
+same `.env` may hold it, and RepoFoundry accepts it there. Create it the same
+way as the Gitea token in part 1, ticking only the repository write scope.
+
+This guide shows the first two, step by step. The red numbers in each picture
+match the numbered steps next to it.
 
 > **About the pictures.** They are drawings of the pages, not screenshots, so
 > that they show no account data. Names, colors and the position of a control
@@ -17,7 +24,7 @@ numbered steps next to it.
 > pictures; on your screen you see its real value.
 
 The full list of what each token may do is in
-[Token permissions](../README.md#token-permissions) in the README. This guide
+[Token permissions](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#token-permissions) in the README. This guide
 is the click-by-click version of it.
 
 Contents:
@@ -40,7 +47,7 @@ the address you set as `GITEA_URL` in `config.env`.
 Sign in to Gitea. Click your **avatar** in the top-right corner (1), then
 choose **Settings** (2).
 
-![Step 1: the avatar menu in the top-right corner, with Settings highlighted](img/gitea-1-open-settings.svg)
+![Step 1: the avatar menu in the top-right corner, with Settings highlighted](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-1-open-settings.svg)
 
 ### Step 2. Open "Applications"
 
@@ -48,7 +55,7 @@ In the menu on the left, click **Applications** (1).
 
 You can also go straight there: `<your Gitea address>/user/settings/applications`.
 
-![Step 2: the Applications entry in the left menu of the settings](img/gitea-2-applications.svg)
+![Step 2: the Applications entry in the left menu of the settings](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-2-applications.svg)
 
 ### Step 3. Fill in the token form
 
@@ -69,7 +76,7 @@ Scroll to **Generate New Token** and fill it in:
 
 4. Click **Generate Token**.
 
-![Step 3: the token form with the name, the access choice and three permissions set to Read and Write](img/gitea-3-token-form.svg)
+![Step 3: the token form with the name, the access choice and three permissions set to Read and Write](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-3-token-form.svg)
 
 > **Only creating projects in organizations?** Then `user` can stay at **Read**.
 > `Read and Write` on `user` is needed only to create a repository under your
@@ -86,7 +93,7 @@ value again.
 
 If you lose the value, delete that token and generate a new one.
 
-![Step 4: the green message with the new token and a Copy button, and the token in the list below](img/gitea-4-copy-token.svg)
+![Step 4: the green message with the new token and a Copy button, and the token in the list below](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-4-copy-token.svg)
 
 ---
 
@@ -104,14 +111,14 @@ repository.
 Sign in to GitHub. Click your **profile picture** in the top-right corner (1),
 then **Settings** (2).
 
-![Step 1: the profile menu in the top-right corner, with Settings highlighted](img/github-1-open-settings.svg)
+![Step 1: the profile menu in the top-right corner, with Settings highlighted](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-1-open-settings.svg)
 
 ### Step 2. Open "Developer settings"
 
 In the left sidebar, scroll to the bottom and click **Developer settings** (1).
 It is the last entry.
 
-![Step 2: Developer settings at the bottom of the left sidebar](img/github-2-developer-settings.svg)
+![Step 2: Developer settings at the bottom of the left sidebar](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-2-developer-settings.svg)
 
 ### Step 3. Choose "Tokens (classic)"
 
@@ -124,7 +131,7 @@ It is the last entry.
 GitHub may ask you to confirm your password or a two-factor code. Do that
 yourself; nobody else should type it.
 
-![Step 3: Tokens (classic) in the sidebar, and Generate new token (classic) in the button menu](img/github-3-tokens-classic.svg)
+![Step 3: Tokens (classic) in the sidebar, and Generate new token (classic) in the button menu](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-3-tokens-classic.svg)
 
 > Direct address: `https://github.com/settings/tokens/new`
 
@@ -147,7 +154,7 @@ yourself; nobody else should type it.
 
 4. Scroll down and click **Generate token** (4).
 
-![Step 4: the new token form with a note, an expiration, the repo scope ticked and the Generate token button](img/github-4-token-form.svg)
+![Step 4: the new token form with a note, an expiration, the repo scope ticked and the Generate token button](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-4-token-form.svg)
 
 > **`read:org` and `admin:org`.** The README records that the check worked with
 > a token that had `repo` and `admin:org`, and that `read:org` alone is
@@ -165,7 +172,7 @@ sign-on, the token must also be authorised for that organization: in the token
 list click **Configure SSO** (2) next to the token and then **Authorize**
 for the organization.
 
-![Step 5: the green box with the new token and a copy icon, and Configure SSO in the token list](img/github-5-copy-token.svg)
+![Step 5: the green box with the new token and a copy icon, and Configure SSO in the token list](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-5-copy-token.svg)
 
 ---
 
@@ -195,10 +202,12 @@ remove the brackets:
 GITEA_TOKEN=<the Gitea token>
 GITHUB_PAT=<the GitHub token>
 GITHUB_USER=<your GitHub account name>
+TOKEN_FOR_GITEA_WIKI=<the Gitea token for the wiki, repository write scope only>
 ```
 
-`GITHUB_PAT` and `GITHUB_USER` are needed only when you create a GitHub
-repository. Git ignores `.env`. Never commit it, send it, or paste it into a
+`GITHUB_PAT` and `GITHUB_USER` are required only when you choose GitHub (the
+mirror); otherwise leave them out. `TOKEN_FOR_GITEA_WIKI` is optional and only
+needed to publish the wiki. Git ignores `.env`. Never commit it, send it, or paste it into a
 chat or an issue.
 
 Then check the setup with a dry run, which only reads from the hosts and

wiki/AccessTokens.ms.md

@@ -0,0 +1,197 @@
+<!-- translation of AccessTokens.md, source sha256 ed97e5f40645 -->
+
+> Ini ialah terjemahan [`AccessTokens`](AccessTokens). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
+
+[English](AccessTokens) | [Dansk](AccessTokens.da) | Bahasa Melayu
+
+# Cara mencipta token akses yang diperlukan RepoFoundry
+
+RepoFoundry berhubung dengan dua hos dan memerlukan satu token untuk setiap satu:
+
+| Token | Kunci | Diperlukan | Jenis |
+| --- | --- | --- | --- |
+| Token akses Gitea | `GITEA_TOKEN` | sentiasa | token akses dengan skop |
+| GitHub personal access token | `GITHUB_PAT` | diperlukan apabila anda memilih GitHub (cermin) | personal access token **klasik** (PAT) |
+| Token akses Gitea untuk wiki | `TOKEN_FOR_GITEA_WIKI` | pilihan (hanya untuk menerbitkan wiki) | token akses dengan skop tulis repositori sahaja (`write:repository`) |
+
+`TOKEN_FOR_GITEA_WIKI` tidak digunakan oleh RepoFoundry. Ia disenaraikan kerana `.env` yang sama mungkin mengandunginya, dan RepoFoundry menerimanya di situ. Cipta ia dengan cara yang sama seperti token Gitea dalam bahagian 1, dan tandakan skop tulis repositori sahaja.
+
+Panduan ini menunjukkan dua yang pertama, langkah demi langkah. Nombor merah dalam setiap gambar sepadan dengan langkah bernombor di sebelahnya.
+
+> **Tentang gambar.** Ia ialah lukisan halaman, bukan tangkapan skrin, supaya tiada data akaun dipaparkan. Nama, warna dan kedudukan sesuatu kawalan mungkin sedikit berbeza dalam versi Gitea atau GitHub anda. Perkataan bercetak tebal dalam langkah ialah label yang perlu dicari. Token baharu ditunjukkan sebagai titik dalam gambar; pada skrin anda, anda melihat nilai sebenarnya.
+
+Senarai penuh perkara yang dibenarkan oleh setiap token terdapat di bawah [Token permissions](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#token-permissions) dalam README. Panduan ini ialah versi klik demi klik daripadanya.
+
+Kandungan:
+
+1. [Cipta token akses Gitea](#1-cipta-token-akses-gitea)
+2. [Cipta GitHub personal access token (klasik)](#2-cipta-github-personal-access-token-klasik)
+3. [Berikan token kepada RepoFoundry](#3-berikan-token-kepada-repofoundry)
+4. [Simpan token dengan selamat](#4-simpan-token-dengan-selamat)
+5. [Jika sesuatu tidak berjalan lancar](#5-jika-sesuatu-tidak-berjalan-lancar)
+
+---
+
+## 1. Cipta token akses Gitea
+
+Contoh menggunakan `https://git.tirsystem.com`. Jika Gitea anda berada di tempat lain, gunakan alamat yang anda tetapkan sebagai `GITEA_URL` dalam `config.env`.
+
+### Langkah 1. Buka tetapan anda
+
+Log masuk ke Gitea. Klik **avatar** anda di penjuru kanan atas (1), kemudian pilih **Settings** (2).
+
+![Langkah 1: menu avatar di penjuru kanan atas dengan Settings ditonjolkan](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-1-open-settings.svg)
+
+### Langkah 2. Buka "Applications"
+
+Dalam menu di sebelah kiri, klik **Applications** (1).
+
+Anda juga boleh terus ke sana: `<alamat Gitea anda>/user/settings/applications`.
+
+![Langkah 2: entri Applications dalam menu kiri tetapan](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-2-applications.svg)
+
+### Langkah 3. Isi borang token
+
+Tatal ke **Generate New Token** dan isikannya:
+
+1. **Token Name:** nama yang anda akan kenali kemudian, contohnya `RepoFoundry`.
+2. **Repository and Organization Access:** pilih **All (public, private, and limited)**. Token yang terhad kepada **Public only** tidak dapat melihat repositori atau organisasi persendirian, jadi mencipta projek persendirian akan gagal.
+3. **Select permissions:** tetapkan ketiga-tiga ini kepada **Read and Write** dan biarkan setiap baris lain pada **No Access**:
+
+   | Permission | Tahap | Mengapa RepoFoundry memerlukannya |
+   | --- | --- | --- |
+   | `organization` | Read and Write | mencari pemilik dan hak anda di dalamnya, mencipta repositori dalam organisasi |
+   | `repository` | Read and Write | mencipta repositori dan mengurus cermin push-nya |
+   | `user` | Read and Write | membaca akaun yang memiliki token, dan mencipta repositori di bawah akaun **anda sendiri** |
+
+4. Klik **Generate Token**.
+
+![Langkah 3: borang token dengan nama, pilihan akses dan tiga permission ditetapkan kepada Read and Write](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-3-token-form.svg)
+
+> **Hanya mencipta projek dalam organisasi?** Maka `user` boleh kekal pada **Read**. `Read and Write` pada `user` hanya diperlukan untuk mencipta repositori di bawah akaun anda sendiri; tanpanya Gitea menjawab `required=[write:user]`.
+
+### Langkah 4. Salin token sekarang
+
+Gitea menunjukkan token baharu **sekali sahaja**, dalam mesej hijau di bahagian atas halaman (1). Salinnya (gunakan butang salin jika versi anda ada, atau pilih teks dan tekan Ctrl+C, Cmd+C pada Mac) dan simpan untuk [bahagian 3 panduan ini](#3-berikan-token-kepada-repofoundry). Token baharu kini berada dalam senarai di bawahnya (2), bersama permission-nya, tetapi senarai itu tidak pernah menunjukkan nilainya lagi.
+
+Jika anda kehilangan nilai itu, padam token tersebut dan jana yang baharu.
+
+![Langkah 4: mesej hijau dengan token baharu dan butang Copy, serta token dalam senarai di bawah](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/gitea-4-copy-token.svg)
+
+---
+
+## 2. Cipta GitHub personal access token (klasik)
+
+Langkau bahagian ini jika anda tidak akan mencipta repositori GitHub (`USE_GITHUB=no` atau menjawab tidak apabila ditanya). `GITHUB_PAT` tidak diperlukan.
+
+Gunakan token **klasik**. RepoFoundry belum diuji dengan token fine-grained, kerana GitHub tidak mendokumenkan permission fine-grained untuk mencipta repositori.
+
+### Langkah 1. Buka tetapan anda
+
+Log masuk ke GitHub. Klik **gambar profil** anda di penjuru kanan atas (1), kemudian **Settings** (2).
+
+![Langkah 1: menu profil di penjuru kanan atas dengan Settings ditonjolkan](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-1-open-settings.svg)
+
+### Langkah 2. Buka "Developer settings"
+
+Dalam bar sisi kiri, tatal ke bahagian bawah dan klik **Developer settings** (1). Ia ialah entri terakhir.
+
+![Langkah 2: Developer settings di bahagian bawah bar sisi kiri](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-2-developer-settings.svg)
+
+### Langkah 3. Pilih "Tokens (classic)"
+
+1. Dalam bar sisi kiri, buka **Personal access tokens** dan klik **Tokens (classic)** (1).
+2. Klik **Generate new token** (2).
+3. Dalam menu yang terbuka, pilih **Generate new token (classic)** (3). Bukan entri pertama, iaitu jenis fine-grained.
+
+GitHub mungkin meminta anda mengesahkan kata laluan atau kod dua faktor. Lakukannya sendiri; tiada orang lain patut menaipnya.
+
+![Langkah 3: Tokens (classic) dalam bar sisi, dan Generate new token (classic) dalam menu butang](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-3-tokens-classic.svg)
+
+> Alamat terus: `https://github.com/settings/tokens/new`
+
+### Langkah 4. Isi borang
+
+1. **Note:** nama yang anda akan kenali kemudian, contohnya `RepoFoundry`.
+2. **Expiration:** pilih tarikh. Hayat yang lebih pendek mengehadkan kerosakan jika token bocor; anda kemudian mencipta token baharu apabila ia tamat.
+3. **Select scopes:** tandakan skop di bawah dan tiada yang lain.
+
+   | Skop | Tandakan apabila | Sebab |
+   | --- | --- | --- |
+   | `repo` | sentiasa (projek persendirian atau awam) | mencipta repositori, dan ialah kata laluan yang digunakan Gitea untuk mem-push cermin |
+   | `public_repo` sebagai ganti `repo` | **hanya** projek awam | cukup untuk mencipta dan mem-push repositori awam; menandakan `repo` sudah merangkumnya |
+   | `read:org` | hanya jika skrip berkata anda bukan ahli organisasi anda | membolehkan skrip menyemak keahlian anda dalam organisasi pemilik |
+
+   Menandakan `repo` turut menandakan lima sub-skopnya (`repo:status`, `repo_deployment`, `public_repo`, `repo:invite`, `security_events`); itu dijangka. Biarkan `workflow`, `write:packages` dan yang lain tidak bertanda.
+
+4. Tatal ke bawah dan klik **Generate token** (4).
+
+![Langkah 4: borang token baharu dengan nota, tarikh luput, skop repo ditandakan dan butang Generate token](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-4-token-form.svg)
+
+> **`read:org` dan `admin:org`.** README mencatatkan bahawa semakan itu berjaya dengan token yang mempunyai `repo` dan `admin:org`, dan bahawa `read:org` sahaja belum diuji. Cuba `read:org` dahulu. `admin:org` memberi kuasa jauh lebih banyak daripada yang diperlukan RepoFoundry, jadi gunakannya hanya jika `read:org` tidak mencukupi.
+
+### Langkah 5. Salin token sekarang
+
+GitHub menunjukkan token **sekali sahaja**, dalam kotak hijau di bahagian atas (1). Klik ikon salin di sebelahnya. Ia bermula dengan `ghp_`. Simpan untuk [bahagian 3 panduan ini](#3-berikan-token-kepada-repofoundry).
+
+Jika pemilik repositori baharu ialah organisasi yang menggunakan SAML single sign-on, token juga mesti dibenarkan untuk organisasi itu: dalam senarai token, klik **Configure SSO** (2) di sebelah token dan kemudian **Authorize** untuk organisasi.
+
+![Langkah 5: kotak hijau dengan token baharu dan ikon salin, serta Configure SSO dalam senarai token](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/raw/branch/main/wiki/img/github-5-copy-token.svg)
+
+---
+
+## 3. Berikan token kepada RepoFoundry
+
+Pilih satu cara. Kedua-duanya mengekalkan token di luar `config.env` (token di situ ditolak).
+
+**Pilihan A: taip apabila ditanya (tiada apa disimpan).** Jangan buat apa-apa terlebih dahulu. RepoFoundry meminta `Gitea access token` pada permulaan, dan `GitHub personal access token` serta `GitHub account name` setelah anda memilih GitHub. Apa yang anda taip tidak dipaparkan pada skrin. Tampal token sahaja, tanpa ruang, pemisah baris atau tanda petik.
+
+**Pilihan B: simpan dalam `.env` (mudah, teks biasa pada cakera).** Dalam folder RepoFoundry:
+
+```bash
+cp .env.example .env
+chmod 600 .env          # Linux dan macOS: hanya anda boleh membacanya
+```
+
+Buka `.env` dan isi nilai; gantikan teks dalam kurungan sudut dan buang kurungan itu:
+
+```text
+GITEA_TOKEN=<token Gitea>
+GITHUB_PAT=<token GitHub>
+GITHUB_USER=<nama akaun GitHub anda>
+TOKEN_FOR_GITEA_WIKI=<token Gitea untuk wiki, skop tulis repositori sahaja>
+```
+
+`GITHUB_PAT` dan `GITHUB_USER` hanya diperlukan apabila anda memilih GitHub (cermin); tinggalkannya jika tidak. `TOKEN_FOR_GITEA_WIKI` ialah pilihan dan hanya diperlukan untuk menerbitkan wiki. Git mengabaikan `.env`. Jangan sekali-kali commit, hantar atau tampal ia dalam sembang atau issue.
+
+Kemudian semak persediaan dengan larian percubaan, yang hanya membaca daripada hos dan tidak mencipta apa-apa:
+
+```bash
+src/create-project.sh
+```
+
+---
+
+## 4. Simpan token dengan selamat
+
+- Token ialah kata laluan. Sesiapa yang memilikinya boleh melakukan apa yang dibenarkannya.
+- Berikan setiap token hanya akses yang terdapat dalam panduan ini, dan tarikh luput.
+- Jangan tampal token dalam baris perintah, URL, commit, issue atau sembang.
+- Jika token mungkin telah bocor, padamnya serta-merta dan cipta yang baharu:
+  - Gitea: **Settings**, **Applications**, kemudian **Delete** pada token itu.
+  - GitHub: **Settings**, **Developer settings**, **Personal access tokens**, **Tokens (classic)**, kemudian **Delete** pada token itu.
+- Apabila token tamat tempoh, cipta yang baharu dengan cara yang sama dan gantikannya dalam `.env`.
+
+---
+
+## 5. Jika sesuatu tidak berjalan lancar
+
+| Apa yang anda lihat | Punca yang mungkin | Apa yang perlu dibuat |
+| --- | --- | --- |
+| `authentication failed: the token is missing, expired or invalid` | token tersalah taip, telah tamat tempoh atau telah dipadam | cipta token baharu dan gunakannya |
+| `the token is valid but not allowed to do this (check its scopes)` | sesuatu permission tiada | Gitea: tetapkan `organization`, `repository` dan `user` kepada **Read and Write**. GitHub: tandakan `repo` |
+| Gitea menjawab `required=[write:user]` | projek dicipta di bawah akaun anda sendiri | tetapkan `user` kepada **Read and Write** |
+| `Gitea owner '...' is neither your account (...) nor an organization the token can see` | token terhad kepada **Public only**, atau nama pemilik salah | jadikan token **All (public, private, and limited)**, atau betulkan pemilik |
+| `GitHub owner '...' is neither your account (...) nor an organization you belong to (or the token lacks the read:org scope)` | token tidak dapat melihat organisasi | tandakan `read:org`, dan benarkan token untuk organisasi jika ia menggunakan single sign-on |
+| token yang ditampal ditolak berulang kali | ruang, pemisah baris atau tanda petik turut tertampal | salin semula dan tampal token sahaja |
+| `GITHUB_USER is '...' but the token belongs to '...'` | amaran: nama dalam `.env` bukan akaun pemilik token | tiada tindakan diperlukan; RepoFoundry menggunakan akaun yang memiliki token |

wiki/GettingStarted.da.md

@@ -0,0 +1,42 @@
+<!-- translation of GettingStarted.md, source sha256 b030cafee29e -->
+
+> Dette er en oversættelse af [`GettingStarted`](GettingStarted). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
+
+[English](GettingStarted) | Dansk | [Bahasa Melayu](GettingStarted.ms)
+
+# Kom godt i gang
+
+## Krav
+
+| Værktøj | Bruges til |
+| --- | --- |
+| bash 4.4 eller nyere | scriptet (macOS leveres med 3.2: installér først en nyere bash) |
+| `git` | det lokale projekt og framework-submodulet |
+| `curl` | GitHub- og Gitea-API'erne |
+| `ssh` (valgfri) | SSH-kontrollen; uden den springes framework-trinnene over |
+| `jq` (valgfri) | JSON-læsning; uden den bruges en lille indbygget læser |
+
+## Installation
+
+```bash
+git clone https://git.tirsystem.com/TirSystem-BashScript/repo-foundry.git
+cd repo-foundry
+src/create-project.sh --help
+```
+
+Intet installeres på hele systemet: scriptet kører fra checkout'et.
+
+## Konfiguration
+
+Kopiér `config.env.example` til `config.env` og `.env.example` til `.env`, og angiv derefter tjenesternes adresser og tokens (se [SSH og tokens](SshAndTokens.da)). `.env` indeholder credentials og committes aldrig.
+
+## Kørsel
+
+Start scriptet fra den mappe, der skal indeholde det nye projekt:
+
+```bash
+src/create-project.sh            # tør kørsel: læser fra værterne, opretter intet
+src/create-project.sh --apply    # opretter alt efter et sidste ja
+```
+
+Der laves ingen commit i det nye projekt. Arbejd på en branch der: frameworkets hooks afviser commits på `main`.

wiki/GettingStarted.md

@@ -0,0 +1,38 @@
+English | [Dansk](GettingStarted.da) | [Bahasa Melayu](GettingStarted.ms)
+
+# Getting started
+
+## Requirements
+
+| Tool | Needed for |
+| --- | --- |
+| bash 4.4 or later | the script (macOS ships 3.2: install a newer bash first) |
+| `git` | the local project and the framework submodule |
+| `curl` | the GitHub and Gitea APIs |
+| `ssh` (optional) | the SSH check; without it the framework steps are skipped |
+| `jq` (optional) | JSON parsing; without it a small built-in reader is used |
+
+## Install
+
+```bash
+git clone https://git.tirsystem.com/TirSystem-BashScript/repo-foundry.git
+cd repo-foundry
+src/create-project.sh --help
+```
+
+Nothing is installed system-wide: the script runs from the checkout.
+
+## Configure
+
+Copy `config.env.example` to `config.env` and `.env.example` to `.env`, then set the service addresses and the tokens (see [SSH and tokens](SshAndTokens)). `.env` holds credentials and is never committed.
+
+## Run
+
+Start the script from the folder that should hold the new project:
+
+```bash
+src/create-project.sh            # dry run: reads from the hosts, creates nothing
+src/create-project.sh --apply    # creates everything after a final yes
+```
+
+No commit is made in the new project. Work on a branch there: the framework's hooks refuse commits on `main`.

wiki/GettingStarted.ms.md

@@ -0,0 +1,42 @@
+<!-- translation of GettingStarted.md, source sha256 b030cafee29e -->
+
+> Ini ialah terjemahan [`GettingStarted`](GettingStarted). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
+
+[English](GettingStarted) | [Dansk](GettingStarted.da) | Bahasa Melayu
+
+# Bermula
+
+## Keperluan
+
+| Alat | Digunakan untuk |
+| --- | --- |
+| bash 4.4 atau lebih baharu | skrip (macOS dibekalkan dengan 3.2: pasang bash yang lebih baharu dahulu) |
+| `git` | projek tempatan dan submodul framework |
+| `curl` | API GitHub dan Gitea |
+| `ssh` (pilihan) | semakan SSH; tanpanya langkah framework dilangkau |
+| `jq` (pilihan) | penghuraian JSON; tanpanya pembaca terbina dalam yang kecil digunakan |
+
+## Pemasangan
+
+```bash
+git clone https://git.tirsystem.com/TirSystem-BashScript/repo-foundry.git
+cd repo-foundry
+src/create-project.sh --help
+```
+
+Tiada apa-apa dipasang pada seluruh sistem: skrip berjalan dari checkout.
+
+## Konfigurasi
+
+Salin `config.env.example` ke `config.env` dan `.env.example` ke `.env`, kemudian tetapkan alamat perkhidmatan dan token (lihat [SSH dan token](SshAndTokens.ms)). `.env` mengandungi kelayakan (credentials) dan tidak pernah di-commit.
+
+## Larian
+
+Mulakan skrip dari folder yang akan menyimpan projek baharu:
+
+```bash
+src/create-project.sh            # larian percubaan: membaca dari hos, tidak mencipta apa-apa
+src/create-project.sh --apply    # mencipta semuanya selepas ya terakhir
+```
+
+Tiada commit dibuat dalam projek baharu. Bekerja pada branch di sana: hook framework menolak commit pada `main`.

wiki/Home.da.md

@@ -0,0 +1,28 @@
+<!-- translation of Home.md, source sha256 18808e63abb7 -->
+
+> Dette er en oversættelse af [`Home`](Home). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
+
+[English](Home) | Dansk | [Bahasa Melayu](Home.ms)
+
+# Repo Foundry
+
+Repo Foundry (`src/create-project.sh`) opretter et nyt projekt i én kørsel:
+
+- et **Gitea**-repository, som er den autoritative kilde;
+- eventuelt et tomt **GitHub**-repository, der får alt via et push-spejl fra Gitea;
+- et **lokalt projekt** med én remote uden credentials, `origin`, og SQA-QC-Framework som git-submodul, med dets skills, git-hooks og skabeloner installeret.
+
+Det er et Bash-script. Det viser først en plan og opretter intet, før du angiver `--apply` og svarer ja.
+
+## Sider
+
+| Side | Hvad den dækker |
+| --- | --- |
+| [Kom godt i gang](GettingStarted.da) | Krav, installation og første kørsel |
+| [SSH og tokens](SshAndTokens.da) | SSH-adgang til Gitea og de to adgangstokens |
+| [Adgangstokens](AccessTokens.da) | Opret adgangstokens trin for trin med billeder |
+| [Opdatering af frameworket](UpdatingTheFramework.da) | Hold et projekts framework-submodul opdateret |
+| [Fejlfinding](Troubleshooting.da) | Almindelige fejl og hvad du skal gøre |
+
+Den fulde reference (konfigurationsfiler, sikkerhedsbeslutninger, fejlhåndtering, kendte begrænsninger) er [README](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md).
+Meld et problem som en [issue](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/issues).

wiki/Home.md

@@ -0,0 +1,24 @@
+English | [Dansk](Home.da) | [Bahasa Melayu](Home.ms)
+
+# Repo Foundry
+
+Repo Foundry (`src/create-project.sh`) sets up a new project in one run:
+
+- a **Gitea** repository, the source of truth;
+- optionally an empty **GitHub** repository that receives everything through a push mirror from Gitea;
+- a **local project** with one credential-free remote, `origin`, and the SQA-QC-Framework as a git submodule, with its skills, git hooks and templates installed.
+
+It is a Bash script. It shows a plan first and creates nothing until you pass `--apply` and answer yes.
+
+## Pages
+
+| Page | What it covers |
+| --- | --- |
+| [Getting started](GettingStarted) | Requirements, install and the first run |
+| [SSH and tokens](SshAndTokens) | SSH access to Gitea and the two access tokens |
+| [Access tokens](AccessTokens) | Create the access tokens, step by step with pictures |
+| [Updating the framework](UpdatingTheFramework) | Keep the framework submodule of a project up to date |
+| [Troubleshooting](Troubleshooting) | Common failures and what to do |
+
+The full reference (configuration files, security decisions, error handling, known limitations) is the [README](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md).
+Report a problem as an [issue](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/issues).

wiki/Home.ms.md

@@ -0,0 +1,28 @@
+<!-- translation of Home.md, source sha256 18808e63abb7 -->
+
+> Ini ialah terjemahan [`Home`](Home). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
+
+[English](Home) | [Dansk](Home.da) | Bahasa Melayu
+
+# Repo Foundry
+
+Repo Foundry (`src/create-project.sh`) menyediakan projek baharu dalam satu larian:
+
+- repositori **Gitea**, iaitu sumber yang sah;
+- secara pilihan repositori **GitHub** kosong yang menerima semuanya melalui push mirror dari Gitea;
+- **projek tempatan** dengan satu remote tanpa kelayakan (credentials), `origin`, dan SQA-QC-Framework sebagai submodul git, dengan skill, git hook dan templatnya terpasang.
+
+Ia ialah skrip Bash. Ia memaparkan pelan dahulu dan tidak mencipta apa-apa sehingga anda memberikan `--apply` dan menjawab ya.
+
+## Halaman
+
+| Halaman | Kandungan |
+| --- | --- |
+| [Bermula](GettingStarted.ms) | Keperluan, pemasangan dan larian pertama |
+| [SSH dan token](SshAndTokens.ms) | Akses SSH ke Gitea dan dua token akses |
+| [Token akses](AccessTokens.ms) | Cipta token akses langkah demi langkah dengan gambar |
+| [Mengemas kini framework](UpdatingTheFramework.ms) | Pastikan submodul framework projek sentiasa terkini |
+| [Diagnosis](Troubleshooting.ms) | Kegagalan lazim dan tindakan yang perlu diambil |
+
+Rujukan penuh (fail konfigurasi, keputusan keselamatan, pengendalian ralat, had yang diketahui) ialah [README](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md).
+Laporkan masalah sebagai [issue](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/issues).

wiki/SshAndTokens.da.md

@@ -0,0 +1,32 @@
+<!-- translation of SshAndTokens.md, source sha256 ec9001c0248b -->
+
+> Dette er en oversættelse af [`SshAndTokens`](SshAndTokens). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
+
+[English](SshAndTokens) | Dansk | [Bahasa Melayu](SshAndTokens.ms)
+
+# SSH og tokens
+
+## SSH-adgang til Gitea
+
+Framework-submodulet hentes over SSH på port **10022**. Før du kører scriptet:
+
+1. Tilføj din offentlige SSH-nøgle til din Gitea-konto.
+2. Opret forbindelse én gang manuelt, så serverens hostnøgle er kendt (scriptet afviser ukendte hostnøgler):
+
+   ```bash
+   ssh -p 10022 -T git@git.tirsystem.com
+   ```
+
+   En besked om, at du er godkendt, uden shell-adgang, betyder, at det virker.
+
+> **Nøgler med adgangskode.** Scriptet beder aldrig om en adgangskode. En nøgle med adgangskode skal allerede være indlæst i `ssh-agent` (`ssh-add`). Det følges i [issue 77](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/issues/77).
+
+## Tokens
+
+| Token | Nøgle i `.env` | Nødvendig | Type |
+| --- | --- | --- | --- |
+| Gitea-adgangstoken | `GITEA_TOKEN` | altid | adgangstoken med scopes |
+| GitHub personal access token | `GITHUB_PAT` | påkrævet, når du vælger GitHub (spejlet) | **klassisk** personal access token |
+| Gitea-adgangstoken til wikien | `TOKEN_FOR_GITEA_WIKI` | valgfri (kun for at udgive wikien) | adgangstoken kun med repository-skriveadgang (`write:repository`); scriptet accepterer den, men bruger den aldrig |
+
+Trin for trin med billeder: [sådan opretter du adgangstokens](AccessTokens.da). De præcise tilladelser står under [Token permissions](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#token-permissions) i README.

wiki/SshAndTokens.md

@@ -0,0 +1,28 @@
+English | [Dansk](SshAndTokens.da) | [Bahasa Melayu](SshAndTokens.ms)
+
+# SSH and tokens
+
+## SSH access to Gitea
+
+The framework submodule is fetched over SSH on port **10022**. Before you run the script:
+
+1. Add your SSH public key to your Gitea account.
+2. Connect once by hand so the server's host key is known (the script refuses unknown host keys):
+
+   ```bash
+   ssh -p 10022 -T git@git.tirsystem.com
+   ```
+
+   A message that you have successfully authenticated, without shell access, means it works.
+
+> **Passphrase keys.** The script never prompts for a passphrase. A key with a passphrase must already be loaded in `ssh-agent` (`ssh-add`). This is tracked in [issue 77](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/issues/77).
+
+## Tokens
+
+| Token | Key in `.env` | Needed | Type |
+| --- | --- | --- | --- |
+| Gitea access token | `GITEA_TOKEN` | always | access token with scopes |
+| GitHub personal access token | `GITHUB_PAT` | required when you choose GitHub (the mirror) | **classic** personal access token |
+| Gitea access token for the wiki | `TOKEN_FOR_GITEA_WIKI` | optional (only to publish the wiki) | access token with the repository write scope (`write:repository`) only; the script accepts it but never uses it |
+
+Step by step with pictures: [how to create the access tokens](AccessTokens). The exact permissions are under [Token permissions](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#token-permissions) in the README.

wiki/SshAndTokens.ms.md

@@ -0,0 +1,32 @@
+<!-- translation of SshAndTokens.md, source sha256 ec9001c0248b -->
+
+> Ini ialah terjemahan [`SshAndTokens`](SshAndTokens). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
+
+[English](SshAndTokens) | [Dansk](SshAndTokens.da) | Bahasa Melayu
+
+# SSH dan token
+
+## Akses SSH ke Gitea
+
+Submodul framework diambil melalui SSH pada port **10022**. Sebelum anda menjalankan skrip:
+
+1. Tambahkan kunci awam SSH anda ke akaun Gitea anda.
+2. Sambung sekali secara manual supaya kunci hos pelayan dikenali (skrip menolak kunci hos yang tidak dikenali):
+
+   ```bash
+   ssh -p 10022 -T git@git.tirsystem.com
+   ```
+
+   Mesej bahawa anda telah berjaya disahkan, tanpa akses shell, bermakna ia berfungsi.
+
+> **Kunci dengan frasa laluan.** Skrip tidak pernah meminta frasa laluan. Kunci dengan frasa laluan mesti sudah dimuatkan dalam `ssh-agent` (`ssh-add`). Perkara ini dijejaki dalam [issue 77](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/issues/77).
+
+## Token
+
+| Token | Kunci dalam `.env` | Diperlukan | Jenis |
+| --- | --- | --- | --- |
+| Token akses Gitea | `GITEA_TOKEN` | sentiasa | token akses dengan skop |
+| GitHub personal access token | `GITHUB_PAT` | diperlukan apabila anda memilih GitHub (cermin) | personal access token **klasik** |
+| Token akses Gitea untuk wiki | `TOKEN_FOR_GITEA_WIKI` | pilihan (hanya untuk menerbitkan wiki) | token akses dengan skop tulis repositori sahaja (`write:repository`); skrip menerimanya tetapi tidak pernah menggunakannya |
+
+Langkah demi langkah dengan gambar: [cara mencipta token akses](AccessTokens.ms). Kebenaran yang tepat terdapat di bawah [Token permissions](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#token-permissions) dalam README.

wiki/Troubleshooting.da.md

@@ -0,0 +1,16 @@
+<!-- translation of Troubleshooting.md, source sha256 da17de6a5d61 -->
+
+> Dette er en oversættelse af [`Troubleshooting`](Troubleshooting). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
+
+[English](Troubleshooting) | Dansk | [Bahasa Melayu](Troubleshooting.ms)
+
+# Fejlfinding
+
+| Symptom | Hvad du skal kontrollere |
+| --- | --- |
+| Planen siger, at SSH-testen mislykkedes | Din nøgle er i din Gitea-konto, hostnøglen er kendt (`ssh -p 10022 -T git@git.tirsystem.com`), og en nøgle med adgangskode er indlæst med `ssh-add` |
+| Scriptet stopper ved værktøjskontrollen | bash er 4.4 eller nyere, og `git` og `curl` er installeret |
+| En vært afviser tokenet | Tokenet er gyldigt og har de scopes, der står under [SSH og tokens](SshAndTokens.da) |
+| En kørsel stoppede undervejs | Ret årsagen og kør den samme kommando igen med `--apply`: det, der allerede er oprettet, tilbydes genbrugt |
+
+Mere: [Error handling and recovery](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#error-handling-and-recovery) og [Known limitations](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#known-limitations) i README.

wiki/Troubleshooting.md

@@ -0,0 +1,12 @@
+English | [Dansk](Troubleshooting.da) | [Bahasa Melayu](Troubleshooting.ms)
+
+# Troubleshooting
+
+| Symptom | What to check |
+| --- | --- |
+| The plan says the SSH test failed | Your key is in your Gitea account, the host key is known (`ssh -p 10022 -T git@git.tirsystem.com`), and a passphrase key is loaded with `ssh-add` |
+| The script stops at the tool check | bash is 4.4 or later, and `git` and `curl` are installed |
+| A host rejects the token | The token is current and has the scopes in [SSH and tokens](SshAndTokens) |
+| A run stopped half way | Fix the cause and run the same command again with `--apply`: what was already created is offered for reuse |
+
+More: [Error handling and recovery](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#error-handling-and-recovery) and [Known limitations](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#known-limitations) in the README.

wiki/Troubleshooting.ms.md

@@ -0,0 +1,16 @@
+<!-- translation of Troubleshooting.md, source sha256 da17de6a5d61 -->
+
+> Ini ialah terjemahan [`Troubleshooting`](Troubleshooting). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
+
+[English](Troubleshooting) | [Dansk](Troubleshooting.da) | Bahasa Melayu
+
+# Diagnosis
+
+| Gejala | Perkara yang perlu disemak |
+| --- | --- |
+| Pelan menyatakan ujian SSH gagal | Kunci anda ada dalam akaun Gitea anda, kunci hos dikenali (`ssh -p 10022 -T git@git.tirsystem.com`), dan kunci dengan frasa laluan dimuatkan dengan `ssh-add` |
+| Skrip berhenti pada semakan alat | bash ialah 4.4 atau lebih baharu, dan `git` serta `curl` dipasang |
+| Hos menolak token | Token masih sah dan mempunyai skop yang disenaraikan dalam [SSH dan token](SshAndTokens.ms) |
+| Larian berhenti separuh jalan | Betulkan puncanya dan jalankan arahan yang sama sekali lagi dengan `--apply`: apa yang telah dicipta ditawarkan untuk digunakan semula |
+
+Lagi: [Error handling and recovery](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#error-handling-and-recovery) dan [Known limitations](https://git.tirsystem.com/TirSystem-BashScript/repo-foundry/src/branch/main/README.md#known-limitations) dalam README.

wiki/UpdatingTheFramework.da.md

@@ -0,0 +1,64 @@
+<!-- translation of UpdatingTheFramework.md, source sha256 3e450f6c8f34 -->
+
+> Dette er en oversættelse af [`UpdatingTheFramework`](UpdatingTheFramework). Den engelske side er autoritativ, og ændringer her bliver overskrevet, næste gang wikien publiceres.
+
+[English](UpdatingTheFramework) | Dansk | [Bahasa Melayu](UpdatingTheFramework.ms)
+
+# Opdatering af frameworket
+
+Et projekt oprettet af Repo Foundry har SQA-QC-Framework som git-submodulet `framework`. En clone eller en `git pull` flytter det ikke: projektet bliver på den framework-commit, det har registreret. For at holde frameworket opdateret kører du dette i projektet, fra dets rod:
+
+```bash
+git submodule update --init --remote --recursive framework
+```
+
+| Del | Hvorfor |
+| --- | --- |
+| `--init` | henter submodulet, hvis det ikke findes endnu |
+| `--remote` | flytter `framework` til den nyeste commit i framework-repositoryet i stedet for den commit, projektet har registreret |
+| `--recursive` | opdaterer også det submodul, frameworket selv har (`framework/qc`, checklisterne) |
+
+## Efter opdateringen
+
+1. Installér skills igen, så kopierne i `.claude/skills/` og `.agents/skills/` svarer til det nye framework:
+
+   ```bash
+   bash framework/scripts/install-skills.sh
+   ```
+
+2. Gennemgå, hvad der er ændret, og commit derefter den nye framework-commit på en branch (frameworkets hooks afviser commits på `main`):
+
+   ```bash
+   git status
+   git switch -c update-framework
+   git add framework
+   git commit -m "Update the framework"
+   ```
+
+3. Opdatér `AGENTS.md` (næste afsnit).
+
+## Opdatér AGENTS.md til den nyeste skabelon
+
+`AGENTS.md` i dit projekt blev kopieret fra `framework/templates/AGENTS-template.md`, da projektet blev oprettet. Det er en kopi, så den ændres ikke, når frameworket ændres. Skabelonen indeholder de regler, frameworkets skills og hooks forventer (for eksempel superviseret og autonom tilstand), så opdatér den efter hver framework-opdatering.
+
+1. Se, hvad der er forskelligt:
+
+   ```bash
+   diff -u AGENTS.md framework/templates/AGENTS-template.md
+   ```
+
+2. Hvis du aldrig har redigeret `AGENTS.md`, erstat den:
+
+   ```bash
+   cp framework/templates/AGENTS-template.md AGENTS.md
+   ```
+
+3. Hvis du har tilføjet egne regler, kopiér de nye eller ændrede skabelonafsnit ind i `AGENTS.md` i hånden og behold dine egne. Hvis du erstatter filen, mister du dem.
+
+Repo Foundry lægger `/AGENTS.md` i `.git/info/exclude` i det nye projekt, så git ikke viser filen, og ændringen er ikke en commit: den påvirker kun din arbejdskopi. Erstat ikke `docs/artifact-registry.md` på samme måde: den indeholder dit projekts egne rækker, så sammenlign den kun med `framework/templates/artifact-registry-template.md` og kopiér det, du har brug for.
+
+## Noter
+
+- `--remote` følger framework-repositoryets standardbranch, ikke et release-tag. For at blive på et release skal du i stedet checke tagget ud i submodulet: `git -C framework checkout <tag>`, og derefter committe `framework` som ovenfor.
+- En anden person, der clone'r projektet eller henter din commit, får den registrerede framework-commit med `git submodule update --init --recursive`.
+- Submodulet hentes over SSH på port 10022, så [SSH-opsætningen](SshAndTokens.da) gælder også for opdateringer.

wiki/UpdatingTheFramework.md

@@ -0,0 +1,60 @@
+English | [Dansk](UpdatingTheFramework.da) | [Bahasa Melayu](UpdatingTheFramework.ms)
+
+# Updating the framework
+
+A project created by Repo Foundry holds the SQA-QC-Framework as the git submodule `framework`. A clone or a `git pull` does not move it: the project stays on the framework commit it recorded. To keep the framework up to date, run this in the project, from its root:
+
+```bash
+git submodule update --init --remote --recursive framework
+```
+
+| Part | Why |
+| --- | --- |
+| `--init` | fetches the submodule if it is not there yet |
+| `--remote` | moves `framework` to the latest commit of the framework repository, instead of the commit the project recorded |
+| `--recursive` | also updates the submodule the framework holds itself (`framework/qc`, the checklists) |
+
+## After the update
+
+1. Re-install the skills, so the copies in `.claude/skills/` and `.agents/skills/` match the new framework:
+
+   ```bash
+   bash framework/scripts/install-skills.sh
+   ```
+
+2. Review what changed, then commit the new framework commit on a branch (the framework's hooks refuse commits on `main`):
+
+   ```bash
+   git status
+   git switch -c update-framework
+   git add framework
+   git commit -m "Update the framework"
+   ```
+
+3. Bring `AGENTS.md` up to date (next section).
+
+## Update AGENTS.md to the newest template
+
+`AGENTS.md` in your project was copied from `framework/templates/AGENTS-template.md` when the project was created. It is a copy, so it does not change when the framework does. The template holds the rules the framework's skills and hooks expect (for example the supervised and autonomous modes), so bring it up to date after each framework update.
+
+1. See what differs:
+
+   ```bash
+   diff -u AGENTS.md framework/templates/AGENTS-template.md
+   ```
+
+2. If you never edited `AGENTS.md`, replace it:
+
+   ```bash
+   cp framework/templates/AGENTS-template.md AGENTS.md
+   ```
+
+3. If you added your own rules, copy the new or changed template sections into `AGENTS.md` by hand and keep yours. Replacing the file would lose them.
+
+Repo Foundry adds `/AGENTS.md` to `.git/info/exclude` in the new project, so git does not list the file and the change is not a commit: it only affects your working copy. Do not replace `docs/artifact-registry.md` the same way: it holds your project's own rows, so only compare it with `framework/templates/artifact-registry-template.md` and copy what you need.
+
+## Notes
+
+- `--remote` follows the default branch of the framework repository, not a release tag. To stay on a release, check the tag out inside the submodule instead: `git -C framework checkout <tag>`, then commit `framework` as above.
+- Another person who clones the project, or pulls your commit, gets the recorded framework commit with `git submodule update --init --recursive`.
+- The submodule is fetched over SSH on port 10022, so the [SSH setup](SshAndTokens) applies to updates too.

wiki/UpdatingTheFramework.ms.md

@@ -0,0 +1,64 @@
+<!-- translation of UpdatingTheFramework.md, source sha256 3e450f6c8f34 -->
+
+> Ini ialah terjemahan [`UpdatingTheFramework`](UpdatingTheFramework). Halaman bahasa Inggeris ialah teks yang sah, dan perubahan di sini akan ditimpa pada penerbitan wiki yang seterusnya.
+
+[English](UpdatingTheFramework) | [Dansk](UpdatingTheFramework.da) | Bahasa Melayu
+
+# Mengemas kini framework
+
+Projek yang dicipta oleh Repo Foundry menyimpan SQA-QC-Framework sebagai submodul git `framework`. Clone atau `git pull` tidak menggerakkannya: projek kekal pada commit framework yang direkodkannya. Untuk memastikan framework sentiasa terkini, jalankan ini dalam projek, dari akarnya:
+
+```bash
+git submodule update --init --remote --recursive framework
+```
+
+| Bahagian | Sebab |
+| --- | --- |
+| `--init` | mengambil submodul jika ia belum ada |
+| `--remote` | menggerakkan `framework` ke commit terkini repositori framework, bukannya commit yang direkodkan oleh projek |
+| `--recursive` | turut mengemas kini submodul yang dimiliki framework sendiri (`framework/qc`, senarai semak) |
+
+## Selepas kemas kini
+
+1. Pasang semula skill, supaya salinan dalam `.claude/skills/` dan `.agents/skills/` sepadan dengan framework baharu:
+
+   ```bash
+   bash framework/scripts/install-skills.sh
+   ```
+
+2. Semak apa yang berubah, kemudian commit commit framework baharu pada sebuah branch (hook framework menolak commit pada `main`):
+
+   ```bash
+   git status
+   git switch -c update-framework
+   git add framework
+   git commit -m "Update the framework"
+   ```
+
+3. Kemas kini `AGENTS.md` (bahagian seterusnya).
+
+## Kemas kini AGENTS.md kepada templat terkini
+
+`AGENTS.md` dalam projek anda disalin daripada `framework/templates/AGENTS-template.md` semasa projek dicipta. Ia ialah salinan, jadi ia tidak berubah apabila framework berubah. Templat itu mengandungi peraturan yang dijangka oleh skill dan hook framework (contohnya mod diselia dan mod autonomi), jadi kemas kininya selepas setiap kemas kini framework.
+
+1. Lihat apa yang berbeza:
+
+   ```bash
+   diff -u AGENTS.md framework/templates/AGENTS-template.md
+   ```
+
+2. Jika anda tidak pernah mengedit `AGENTS.md`, gantikannya:
+
+   ```bash
+   cp framework/templates/AGENTS-template.md AGENTS.md
+   ```
+
+3. Jika anda menambah peraturan sendiri, salin bahagian templat yang baharu atau berubah ke dalam `AGENTS.md` secara manual dan kekalkan peraturan anda. Menggantikan fail akan menghilangkannya.
+
+Repo Foundry menambah `/AGENTS.md` ke `.git/info/exclude` dalam projek baharu, jadi git tidak menyenaraikan fail itu dan perubahan itu bukan commit: ia hanya memberi kesan kepada salinan kerja anda. Jangan gantikan `docs/artifact-registry.md` dengan cara yang sama: ia mengandungi baris projek anda sendiri, jadi bandingkannya sahaja dengan `framework/templates/artifact-registry-template.md` dan salin apa yang anda perlukan.
+
+## Nota
+
+- `--remote` mengikuti branch lalai repositori framework, bukan tag keluaran. Untuk kekal pada keluaran, checkout tag di dalam submodul: `git -C framework checkout <tag>`, kemudian commit `framework` seperti di atas.
+- Orang lain yang meng-clone projek, atau menarik commit anda, mendapat commit framework yang direkodkan dengan `git submodule update --init --recursive`.
+- Submodul diambil melalui SSH pada port 10022, jadi [persediaan SSH](SshAndTokens.ms) juga terpakai untuk kemas kini.

wiki/_Sidebar.md

@@ -0,0 +1,28 @@
+**Repo Foundry**
+
+**English**
+
+- [Home](Home)
+- [Getting started](GettingStarted)
+- [SSH and tokens](SshAndTokens)
+- [Access tokens](AccessTokens)
+- [Updating the framework](UpdatingTheFramework)
+- [Troubleshooting](Troubleshooting)
+
+**Dansk**
+
+- [Hjem](Home.da)
+- [Kom godt i gang](GettingStarted.da)
+- [SSH og tokens](SshAndTokens.da)
+- [Adgangstokens](AccessTokens.da)
+- [Opdatering af frameworket](UpdatingTheFramework.da)
+- [Fejlfinding](Troubleshooting.da)
+
+**Bahasa Melayu**
+
+- [Utama](Home.ms)
+- [Bermula](GettingStarted.ms)
+- [SSH dan token](SshAndTokens.ms)
+- [Token akses](AccessTokens.ms)
+- [Mengemas kini framework](UpdatingTheFramework.ms)
+- [Diagnosis](Troubleshooting.ms)