Enforce Ubuntu runner policy

AGENTS.md

@@ -9,6 +9,14 @@ This file is for Codex agents working on the Codex Agent Repository Kit itself.
 - If local changes exist, preserve them and do not overwrite user work.
 - Conserve context tokens: use `rg`, targeted file reads, and short summaries instead of loading unrelated files or long logs.
 
+## Runner Policy
+
+- The only supported build runners are the Gitea global runners `global-runner-1`, `global-runner-2`, and `global-runner-3`.
+- Use only these Linux runner labels in workflow templates and generated setup instructions: `ubuntu-latest`, `ubuntu-24.04`, and `ubuntu-22.04`.
+- Never run project builds, tests, audits, package jobs, installers, dependency bootstraps, or release jobs on the local machine. Use the Gitea Ubuntu runners so the user's machine stays clean.
+- Do not introduce Windows or macOS runners. If a project appears to need Windows-specific tooling, document or implement an open-source Linux-compatible workaround that runs on the Ubuntu runners.
+- Lightweight local checks are allowed when they do not install dependencies or create build artifacts, for example JSON parsing, manifest path checks, `rg`, `git diff --check`, and API status checks.
+
 ## Repository Purpose
 
 This repository ships reusable baseline files for other repositories:
@@ -21,6 +29,7 @@ This repository ships reusable baseline files for other repositories:
 ## Editing Rules
 
 - Keep repository owner, repository name, project names, and local paths dynamic. This kit intentionally targets `https://git.wilkensxl.de` and SSH port `2222`, so keep that host/port consistent in user-facing setup and Gitea workflow defaults.
+- Keep workflow examples and generated CI defaults on the supported Ubuntu runner labels only.
 - If a new placeholder is introduced, update `manifest.json`, the README placeholder list, and placeholder scans in workflow templates.
 - Keep `README.md` user-facing. Put agent operating rules in this file or the workflow docs.
 - Keep `files/AGENTS.md` generic; it is copied into target repositories and must not describe this repository specifically.

CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to the Codex Agent Repository Kit are documented here.
 
+## 1.0.6 - 2026-05-16
+
+- Added a runner policy that limits project build, test, audit, package, installer, dependency setup, and release work to `global-runner-1`, `global-runner-2`, and `global-runner-3`.
+- Documented the supported Ubuntu labels: `ubuntu-latest`, `ubuntu-24.04`, and `ubuntu-22.04`.
+- Clarified that heavy project commands must not run on the user's local machine and that Windows or macOS runners should be replaced with Linux-compatible workflow workarounds.
+
+## 1.0.5 - 2026-05-15
+
+- Restored the rainbow section divider theme in the human-facing `README.md`.
+- Added separate minimal permission guidance for `REGISTRY_TOKEN` and `GITEA_TOKEN`.
+- Clarified where package-only and API-capable tokens should be used.
+
 ## 1.0.4 - 2026-05-15
 
 - Set the documented Gitea host to `git.wilkensxl.de` instead of a generic URL placeholder.

README.md

@@ -4,6 +4,8 @@ Reusable setup kit for new or existing repositories that should be easy for Code
 
 This README is for humans. Agent-facing rules live in `AGENTS.md`, `agent-quickstart.md`, `new-repository.md`, and `existing-project.md`.
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## What This Kit Adds
 
 - `AGENTS.md` and `.codex/project.md` for agent context.
@@ -12,6 +14,8 @@ This README is for humans. Agent-facing rules live in `AGENTS.md`, `agent-quicks
 - README blueprint templates for projects that want generated README output.
 - Stack notes for Node, Electron, Python, Docker, and static-site projects.
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Recommended New Repository Setup
 
 1. Create the repository in Gitea.
@@ -22,6 +26,26 @@ This README is for humans. Agent-facing rules live in `AGENTS.md`, `agent-quicks
 6. Commit and push the baseline.
 7. Let the Gitea workflows report any missing setup.
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
+## Runner Policy
+
+This kit assumes these are the only available build runners:
+
+| Runner | Type | Allowed labels |
+| --- | --- | --- |
+| `global-runner-1` | Gitea global runner | `ubuntu-latest`, `ubuntu-24.04`, `ubuntu-22.04` |
+| `global-runner-2` | Gitea global runner | `ubuntu-latest`, `ubuntu-24.04`, `ubuntu-22.04` |
+| `global-runner-3` | Gitea global runner | `ubuntu-latest`, `ubuntu-24.04`, `ubuntu-22.04` |
+
+Agents must run project builds, tests, audits, package jobs, installers, dependency setup, and releases on those Gitea Ubuntu runners. They must not run those heavy project commands on the user's local machine.
+
+Do not add Windows or macOS runners. If a project appears to need platform-specific tooling, use an open-source Linux-compatible workaround that runs on the Ubuntu runners.
+
+Lightweight local checks are still acceptable when they do not install dependencies or create build artifacts, for example `git status --short`, `rg`, JSON validation, manifest path checks, API status checks, and `git diff --check`.
+
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## SSH Setup
 
 Generate a key if you do not already have one:
@@ -79,6 +103,8 @@ git remote -v
 git status --short
 ```
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Applying The Kit With Codex
 
 For a new repository, start Codex in the target repository and use:
@@ -102,6 +128,8 @@ Preserve current CI behavior and project style.
 Do not create a release.
 ```
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Manual Copy Map
 
 Use `manifest.json` as the source of truth. Common targets:
@@ -123,6 +151,8 @@ Use `manifest.json` as the source of truth. Common targets:
 | `files/security-review.md` | `docs/security-review.md` |
 | `files/agent-handoff.md` | `docs/agent-handoff.md` |
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Required Placeholder Values
 
 Replace or remove all placeholders before considering a repository ready:
@@ -154,6 +184,8 @@ COMMIT_OR_VERSION
 
 If a value does not apply, remove that section instead of leaving fake data. If a value is genuinely unknown, mark it as `PENDING`.
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Token Overview
 
 Use separate tokens for separate jobs.
@@ -165,15 +197,44 @@ Use separate tokens for separate jobs.
 
 Repository secrets are available to workflows. They are not visible to local Codex sessions. Local Codex API actions need a local environment variable.
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Gitea Token Permissions
 
-For the token permission screen shown in Gitea, choose:
+For both tokens, choose this repository access level:
 
 ```text
 Repository and Organization Access: All (public, private, and limited)
+```
 
-issue: Read and Write
+Use separate tokens where possible. A package-only token should not be able to create issues or releases.
+
+### REGISTRY_TOKEN Permissions
+
+Use this token as a repository secret for package publishing from Gitea Actions:
+
+```text
 package: Read and Write
+repository: Read
+user: Read
+
+activitypub: No Access
+admin: No Access
+issue: No Access
+misc: No Access
+notification: No Access
+organization: No Access
+```
+
+These permissions cover generic package uploads while still allowing the workflow to read repository metadata.
+
+### GITEA_TOKEN Permissions
+
+Use this token locally on the PC for Codex API actions, or as a repository secret only when workflows need issue, release, or workflow API access:
+
+```text
+issue: Read and Write
+package: Read
 repository: Read and Write
 user: Read
 
@@ -184,16 +245,12 @@ notification: No Access
 organization: No Access
 ```
 
-These permissions cover:
-
-- creating and reading issues,
-- creating and reading releases,
-- uploading package registry files,
-- reading repository metadata,
-- polling workflow runs where the Gitea API allows it.
+These permissions cover creating and reading issues, creating and reading releases, reading repository metadata, and polling workflow runs where the Gitea API allows it. `package: Read` is enough for API checks; use `package: Read and Write` only if this same token must publish packages.
 
 Use a dedicated bot or automation user when possible.
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Setting Local Tokens
 
 Set a local token for Codex or shell-based API work.
@@ -229,6 +286,8 @@ Invoke-RestMethod `
   -Headers $headers
 ```
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Setting Repository Secrets
 
 In Gitea:
@@ -251,6 +310,8 @@ GITEA_TOKEN
 
 Keep package publishing and release or issue automation separate when possible. It makes permission reviews easier.
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Package Publishing
 
 `files/build-gitea.yml` can publish generic packages when `REGISTRY_TOKEN` is available.
@@ -273,6 +334,8 @@ REGISTRY_TOKEN
 
 When those values are unavailable, replace `REPOSITORY_OWNER`, `REPOSITORY_NAME`, and related placeholders before use. The default Gitea server is `https://git.wilkensxl.de`.
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Agent Follow-up Issues
 
 Agents should create focused tracker issues for real follow-up work that is outside the current scope or can be handled independently by humans or other agents.
@@ -287,6 +350,8 @@ An issue should include:
 
 Agents must not create issues for vague reminders, duplicate work, or tasks they can safely finish immediately. Sensitive details belong in private channels or `docs/agent-handoff.md`, not public issues.
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Release Checklist For A New Repo
 
 Before the first release of a target project:
@@ -296,11 +361,13 @@ Before the first release of a target project:
 3. Configure `REGISTRY_TOKEN` if packages are published.
 4. Configure `GITEA_TOKEN` only if workflows need issue or release API access.
 5. Verify SSH push access.
-6. Run lint, test, build, and audit commands that exist.
-7. Run `git diff --check`.
+6. Run lint, test, build, and audit commands on Gitea Ubuntu runners only.
+7. Run lightweight local validation such as `git diff --check`.
 8. Confirm release artifacts do not include Codex kit metadata unless explicitly wanted.
 9. Push and poll workflows to success or document the blocker.
 
+<p align="center"><img src="https://raw.githubusercontent.com/andreasbm/readme/master/assets/lines/rainbow.png" alt="-----------------------------------------------------" width="100%"></p>
+
 ## Updating The Kit In A Project
 
 When this kit changes, update target repositories conservatively:

agent-quickstart.md

@@ -12,6 +12,10 @@ Use matching profiles/*.md guidance after detecting the stack.
 Conserve context tokens: search first, read only relevant files, summarize large outputs, and avoid generated folders, dependency folders, build outputs, or full logs unless directly relevant.
 At the start of each user-requested task, check for upstream repository updates and apply them immediately with a safe fast-forward pull when the working tree is clean.
 If local changes exist, do not overwrite them; fetch or report the blocker before editing.
+Treat global-runner-1, global-runner-2, and global-runner-3 as the only supported build runners.
+Run project builds, tests, audits, package jobs, installers, dependency setup, and releases only on Gitea Ubuntu runners with ubuntu-latest, ubuntu-24.04, or ubuntu-22.04.
+Never run those heavy project commands on the user's local machine.
+Use open-source Linux-compatible workflow workarounds instead of adding Windows or macOS runners.
 For releasable projects, add or preserve scheduled security automation.
 For active projects, add or preserve non-destructive scheduled repository cleanup checks.
 For Codex-maintained projects, add or preserve dependency, release dry-run, and template compliance checks when useful.
@@ -23,7 +27,7 @@ Update README.md whenever blueprint.md or blueprint.json changes.
 Create tracker issues for real, actionable follow-ups that are outside the current scope or independently parallelizable; use docs/agent-handoff.md when no issue tracker is available.
 Exclude Codex kit metadata from user-facing release, package, installer, archive, and GitHub/Gitea upload artifacts unless explicitly requested.
 Run git diff --check before finishing.
-Run the cheapest reliable verification command, or explain why it could not run.
+Run lightweight local validation before finishing, and run the cheapest reliable project verification through Gitea Actions or explain why runner verification could not run.
 ```
 
 ## New Repository Prompt
@@ -38,7 +42,8 @@ Use manifest.json as the source of truth for copy targets.
 Keep the README generator only if it adds value.
 When using the README generator, keep the rainbow `{{ template:section-line }}` divider between major sections.
 Do not create a release.
-Run the cheapest available verification before finishing.
+Run lightweight local validation before finishing.
+Use Gitea Ubuntu runners for project build, test, audit, package, and release commands.
 ```
 
 ## Existing Repository Prompt
@@ -52,7 +57,8 @@ Keep commands truthful: do not add commands that cannot run.
 Use manifest.json as the source of truth for copy targets.
 When using or adding the README generator, keep the rainbow `{{ template:section-line }}` divider between major sections.
 Do not create a release.
-Run the cheapest available verification before finishing.
+Run lightweight local validation before finishing.
+Use Gitea Ubuntu runners for project build, test, audit, package, and release commands.
 ```
 
 ## Agent Decision Tree
@@ -90,6 +96,10 @@ Does the project have CI?
   yes -> patch existing workflow
   no  -> add .gitea/workflows/build.yml only when commands are known
 
+Does any workflow use Windows, macOS, local-machine builds, or unsupported runner labels?
+  yes -> replace it with Gitea Ubuntu runner usage on ubuntu-latest, ubuntu-24.04, or ubuntu-22.04; if a platform-specific step is needed, implement a Linux-compatible workaround
+  no  -> continue
+
 Is the project releasable or does it process user/secrets/config data?
   yes -> add .gitea/workflows/security-scan.yml or preserve equivalent scheduled security automation
   no  -> document why scheduled security automation is not needed
@@ -152,7 +162,7 @@ Is this a private Gitea repo with Actions?
 
 Did you push a commit that should trigger a workflow?
   yes -> poll the workflow run until success; if it fails, inspect logs, fix in scope, push again, and keep looping after the follow-up push
-  no  -> finish with local verification status
+  no  -> finish with lightweight local validation status and explain why runner verification was not required or not available
 ```
 
 ## Minimal File Set

existing-project.md

@@ -35,6 +35,8 @@ If local changes exist, do not overwrite them. Fetch or report the blocker befor
 
 Conserve context tokens while inspecting: start with targeted searches and file lists, then read only files that affect the retrofit decision. Do not load generated folders, dependency folders, build outputs, or full logs unless they are directly relevant.
 
+Treat `global-runner-1`, `global-runner-2`, and `global-runner-3` as the only supported build runners. Project builds, tests, audits, package jobs, installers, dependency setup, and releases must run on Gitea Ubuntu runners with `ubuntu-latest`, `ubuntu-24.04`, or `ubuntu-22.04`, not on the user's local machine. If tooling looks Windows-specific, use an open-source Linux-compatible workaround instead of adding a Windows runner.
+
 Read:
 
 ```text
@@ -122,7 +124,7 @@ The default section divider is the rainbow line from `andreasbm/readme`, configu
 If CI already exists:
 
 - add missing audit/check steps,
-- keep existing runner labels,
+- replace unsupported runner labels with `ubuntu-latest`, `ubuntu-24.04`, or `ubuntu-22.04`,
 - keep existing artifact names unless they are broken,
 - avoid changing deployment behavior.
 
@@ -180,7 +182,8 @@ Use the stack-native audit command when possible:
 Before final response:
 
 - run `git diff --check`,
-- run the smallest reliable verification command,
+- run only lightweight local validation that does not install dependencies or create build artifacts,
+- run the smallest reliable project verification command through Gitea Actions on a supported Ubuntu runner,
 - if using Gitea Actions, poll the pushed workflow run until it reaches a terminal state; for private Gitea repositories on `https://git.wilkensxl.de`, use a locally set `GITEA_TOKEN` for read-only API status checks when available,
 - if the pushed workflow fails or is cancelled, inspect the failing job/logs, fix in scope, push again, and repeat the workflow check loop; fixing and pushing is not a stopping point,
 - list files changed,

files/AGENTS.md

@@ -13,6 +13,10 @@ PROJECT_NAME: PROJECT_DESCRIPTION
 - Prefer existing project patterns over new abstractions.
 - Keep changes scoped to the user's request.
 - Do not commit secrets, `.env` files, private keys, certificates, or tokens.
+- Treat `global-runner-1`, `global-runner-2`, and `global-runner-3` as the only available build runners.
+- Run project builds, tests, audits, package jobs, installers, dependency setup, and releases only on Gitea Ubuntu runners with `ubuntu-latest`, `ubuntu-24.04`, or `ubuntu-22.04`.
+- Do not run those heavy project commands on the user's local machine. Local checks are limited to lightweight reads and validation that do not install dependencies or create build artifacts.
+- Do not add Windows or macOS runners. Use open-source Linux-compatible tooling or workflow workarounds that run on the Ubuntu runners.
 - Do not rewrite history or run destructive git commands unless explicitly requested.
 - Do not create a release unless explicitly requested.
 - At the start of every user-requested task, briefly check the repository for upstream updates and apply them immediately with a safe fast-forward pull when the working tree is clean. If local changes exist, do not overwrite them; fetch or report the blocker before editing.
@@ -46,6 +50,8 @@ AUDIT_COMMAND
 
 If a command is missing, inspect the project and document the closest safe alternative in `.codex/project.md`.
 
+Run these commands through Gitea Actions on the configured Ubuntu runners, not on the user's local machine.
+
 Keep `.codex/project.md` and this `AGENTS.md` aligned when commands, artifact paths, or release rules change.
 
 ## Artifacts
@@ -80,7 +86,7 @@ ARTIFACT_NAME
 ## Finish Checklist
 
 - `git diff --check` passes.
-- The cheapest reliable verification command has been run, or the reason it could not be run is documented.
+- Lightweight local validation has passed, and the cheapest reliable runner-based verification command has been run through Gitea Actions or the reason it could not be run is documented.
 - README, changelog, security review, and release checklist are updated when the change touches release behavior.
 - `docs/agent-handoff.md` is updated when work is interrupted, risky, or spans multiple sessions.
 - Independent follow-up work has tracker issues, or `docs/agent-handoff.md` explains why issues could not be created.

files/CONTRIBUTING.md

@@ -7,11 +7,13 @@
 - Do not commit secrets, generated credentials, local `.env` files, or private keys.
 - Do not create releases unless explicitly requested.
 - Preserve unrelated user changes.
+- Use only the configured Gitea Ubuntu runners for project builds, tests, audits, packages, installers, dependency setup, and releases. Do not run those commands on the local machine.
+- Do not add Windows or macOS runners; use Linux-compatible workarounds that run on `ubuntu-latest`, `ubuntu-24.04`, or `ubuntu-22.04`.
 - Create focused issues for real follow-up work that is outside the current change or can be worked on independently. Do not put secrets, tokens, private data, or sensitive logs in public issues.
 
 ## Before Committing
 
-Run the cheapest reliable verification commands for this project:
+Run the cheapest reliable project verification commands through Gitea Actions:
 
 ```bash
 LINT_COMMAND
@@ -25,7 +27,7 @@ Also run:
 git diff --check
 ```
 
-If a command cannot run, document why in the final response or handoff notes.
+Local checks should stay lightweight and must not install dependencies or create build artifacts. If a runner-based command cannot run, document why in the final response or handoff notes.
 
 ## Pull Requests
 

files/project.md

@@ -24,6 +24,10 @@ README_COMMAND
 
 If a command does not exist, document the closest safe alternative. Do not invent commands that cannot run.
 
+Project build, test, audit, package, installer, dependency setup, and release commands must run on Gitea Ubuntu runners only. Supported labels are `ubuntu-latest`, `ubuntu-24.04`, and `ubuntu-22.04` on `global-runner-1`, `global-runner-2`, and `global-runner-3`.
+
+Local checks are limited to lightweight validation that does not install dependencies or create build artifacts.
+
 ## Stack
 
 ```text
@@ -63,11 +67,11 @@ ARTIFACT_NAME
 Before a release:
 
 1. run the release checklist,
-2. verify CI is green,
+2. verify CI is green on a supported Gitea Ubuntu runner,
 3. verify download links,
 4. update README and changelog,
 5. verify release artifacts exclude Codex kit metadata such as `AGENTS.md`, `.codex/`, `blueprint.md`, `blueprint.json`, template workflows, and agent handoff notes unless the user explicitly wants those shipped,
 6. create a tag,
-7. create the release.
+7. create the release through Gitea Actions or the Gitea API.
 
 Do not create releases unless the user explicitly asks for a release.

files/release-checklist.md

@@ -9,9 +9,11 @@
 ## Quality
 
 - [ ] Working tree is clean.
-- [ ] Lint/type checks pass.
-- [ ] Tests pass or missing tests are documented.
-- [ ] Build succeeds in CI.
+- [ ] Lightweight local validation passes without installing dependencies or creating build artifacts.
+- [ ] Lint/type checks pass on a Gitea Ubuntu runner.
+- [ ] Tests pass on a Gitea Ubuntu runner or missing tests are documented.
+- [ ] Build succeeds in CI on `ubuntu-latest`, `ubuntu-24.04`, or `ubuntu-22.04`.
+- [ ] No project build, test, audit, package, installer, dependency setup, or release command was run on the local machine.
 
 ## Security
 
@@ -32,5 +34,5 @@
 
 - [ ] Git tag created.
 - [ ] Release notes written.
-- [ ] Release published.
+- [ ] Release published from Gitea Actions or through the Gitea API, not by running local release tooling.
 - [ ] Post-release download smoke test completed.

manifest.json

@@ -1,12 +1,15 @@
 {
   "name": "codex-agent-repository-kit",
-  "version": "1.0.4",
+  "version": "1.0.6",
   "description": "Universal repository baseline for Codex-assisted projects.",
   "agentResponsibilities": [
     "Read manifest.json before copying files.",
     "Use copyMap target paths unless the repository already has an equivalent convention.",
     "Conserve context tokens by searching first, reading only relevant files, summarizing large outputs, and avoiding generated folders, dependency folders, build outputs, or full logs unless directly relevant.",
     "At the start of each user-requested task, check for upstream repository updates and apply them immediately with a safe fast-forward pull when the working tree is clean.",
+    "Use only the configured Gitea Ubuntu runners global-runner-1, global-runner-2, and global-runner-3 for project builds, tests, audits, package jobs, installers, dependency setup, and releases.",
+    "Never run heavy project commands on the user's local machine; keep local verification limited to lightweight checks that do not install dependencies or create build artifacts.",
+    "Do not add Windows or macOS runners; use open-source Linux-compatible workarounds that run on ubuntu-latest, ubuntu-24.04, or ubuntu-22.04.",
     "Check git status before editing and before finishing.",
     "Preserve unrelated user changes.",
     "Replace applicable placeholders and remove non-applicable placeholder sections.",
@@ -18,7 +21,7 @@
     "Add or preserve non-destructive scheduled repository cleanup checks for active projects.",
     "Add or preserve dependency, release dry-run, and template compliance checks when they fit the project.",
     "Run git diff --check before finishing.",
-    "Run the cheapest reliable verification command or document why it could not run.",
+    "Run lightweight local validation before finishing, then use Gitea Actions for project verification or document why runner verification could not run.",
     "After pushing workflow-triggering commits, poll Gitea workflow runs until success or a concrete blocker."
   ],
   "securityAutomation": {

new-repository.md

@@ -32,6 +32,8 @@ If local changes exist, do not overwrite them. Fetch or report the blocker befor
 
 Conserve context tokens while inspecting: start with targeted searches and file lists, then read only files that affect the baseline decision. Do not load generated folders, dependency folders, build outputs, or full logs unless they are directly relevant.
 
+Treat `global-runner-1`, `global-runner-2`, and `global-runner-3` as the only supported build runners. Project builds, tests, audits, package jobs, installers, dependency setup, and releases must run on Gitea Ubuntu runners with `ubuntu-latest`, `ubuntu-24.04`, or `ubuntu-22.04`, not on the user's local machine. If tooling looks Windows-specific, use an open-source Linux-compatible workaround instead of adding a Windows runner.
+
 Identify:
 
 - repository name,
@@ -173,6 +175,8 @@ build
 upload artifacts
 ```
 
+Use only the supported Gitea Ubuntu runner labels. Do not add Windows, macOS, self-hosted local-machine, or undocumented runner labels.
+
 Only publish artifacts to a package registry when the artifact names and credentials are known. `actions/upload-artifact` creates a workflow-run artifact, not a Gitea Package Registry package. If users need a package/download entry, add a separate generic package upload step with `REGISTRY_TOKEN`, copy artifacts to URL-safe filenames before upload, and verify the final package URL after the workflow succeeds.
 
 Keep Codex kit files tracked in the source repository when they help agents, but exclude them from user-facing release, package, installer, archive, and GitHub/Gitea upload artifacts unless the user explicitly wants repository-maintenance files shipped. Typical excluded paths are `AGENTS.md`, `.codex/`, `blueprint.md`, `blueprint.json`, template workflow files, and `docs/agent-handoff.md`.
@@ -193,8 +197,8 @@ When the setup reveals real follow-up work that is outside the current scope or
 
 Before final response:
 
-- run formatting or validation if available,
-- run the cheapest reliable verification command,
+- run lightweight local validation if available and it does not install dependencies or create build artifacts,
+- run the cheapest reliable project verification command through Gitea Actions on a supported Ubuntu runner,
 - check `git diff --check`,
 - if using Gitea Actions, poll the pushed workflow run until it reaches a terminal state; for private Gitea repositories on `https://git.wilkensxl.de`, use a locally set `GITEA_TOKEN` for read-only API status checks when available,
 - if the pushed workflow fails or is cancelled, inspect the failing job/logs, fix in scope, push again, and repeat the workflow check loop; fixing and pushing is not a stopping point,