release: v0.8.1 [skip ci]

GRM-83: fix: add build/twine to ci deps, activate venv in notify_failure
chore: update badge URLs to commit a7a72d7d [skip ci]
2026-06-25 00:29:27 +02:00 · 2026-06-24 22:28:08 +00:00 · 2026-06-25 00:14:31 +02:00 · 2026-06-24 22:11:48 +00:00 · 2026-06-24 21:06:40 +00:00 · 2026-06-24 21:03:53 +00:00
32 changed files with 1983 additions and 228 deletions
@@ -29,7 +29,7 @@ jobs:
          PYTHONPATH: src
        run: |
          . .venv/bin/activate
-          python3 -m devx.tools.check_test_speed --max-seconds 10
+          python3 -m devx.tools.check_test_speed --max-seconds 4 --max-single-seconds 0.5
      - name: Dependency security scan
        run: |
          . .venv/bin/activate
@@ -174,7 +174,9 @@ jobs:
      - name: Install dependencies
        run: |
          . .env 2>/dev/null || true
-          python3 -m pip install --break-system-packages "git+https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/oblachno-oss/devx.git@v0.4.1"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
      - name: Run automated PR review
        env:
          REPO_TOKEN: ${{ secrets.REPO_TOKEN }}
@@ -187,10 +189,16 @@ jobs:

  auto-merge:
    # Auto-merge runs after all CI checks pass. It reads the task ID
-    # from .taskid file, validates the PR title, and squash-merges.
-    # No manual label or review needed — CI is the quality gate.
-    needs: [quality, detect-changes, pr-review]
-    if: github.event_name == 'pull_request'
+    # from the branch name, validates the PR title, and squash-merges.
+    # Uses always() so it evaluates even when molecule-tests is skipped
+    # (Gitea Actions skips dependent jobs of skipped jobs by default).
+    needs: [quality, detect-changes, pr-review, molecule-tests]
+    if: >-
+      always() &&
+      github.event_name == 'pull_request' &&
+      needs.quality.result == 'success' &&
+      needs.pr-review.result == 'success' &&
+      (needs.molecule-tests.result == 'success' || needs.molecule-tests.result == 'skipped')
    runs-on: docker
    timeout-minutes: 10
    steps:
@@ -201,7 +209,9 @@ jobs:
      - name: Install dependencies
        run: |
          . .env 2>/dev/null || true
-          python3 -m pip install --break-system-packages "git+https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/oblachno-oss/devx.git@v0.4.1"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
      - name: Squash merge with task ID
        env:
          REPO_TOKEN: ${{ secrets.REPO_TOKEN }}
@@ -43,7 +43,7 @@ jobs:
      - name: Install dependencies
        run: |
          . .env 2>/dev/null || true
-          python3 -m pip install --break-system-packages "git+https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/oblachno-oss/devx.git@v0.4.1"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
      - name: Check if this is a release commit
        id: check
        env:
@@ -62,10 +62,11 @@ jobs:
      - name: Install dependencies
        run: |
          . .env 2>/dev/null || true
-          python3 -m pip install --break-system-packages "git+https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/oblachno-oss/devx.git@v0.4.1"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
      - name: Validate latest commit message
        env:
          PYTHONPATH: src
+          DEVX_TASK_PREFIX: GRM
        run: |
          git log -1 --format=%B > commit-msg.txt
          python3 -m devx.ci.validate_commit_msg commit-msg.txt --branch master
@@ -75,7 +76,7 @@ jobs:
    needs: [detect-type]
    if: needs.detect-type.outputs.is-release == 'false'
    runs-on: docker
-    timeout-minutes: 10
+    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
        with:
@@ -99,17 +100,35 @@ jobs:
          . .venv/bin/activate
          export PATH="$HOME/.local/bin:$PATH"
          python3 -m devx.ci.release
+      - name: Publish release
+        env:
+          REPO_TOKEN: ${{ secrets.REPO_TOKEN }}
+          PYTHONPATH: src
+        run: |
+          . .venv/bin/activate
+          export PATH="$HOME/.local/bin:$PATH"
+          TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "")
+          if [ -z "$TAG" ]; then
+            echo "No tag found — skipping publish"
+            exit 0
+          fi
+          HEAD_MSG=$(git log -1 --format=%s)
+          if echo "$HEAD_MSG" | grep -q "^release: ${TAG}"; then
+            echo "Publishing release $TAG..."
+            python3 -m devx.ci.publish "$TAG" "${{ github.repository }}"
+          else
+            echo "HEAD is not a release commit for $TAG — skipping publish"
+          fi
      - name: Notify on failure
        if: failure()
        env:
          REPO_TOKEN: ${{ secrets.REPO_TOKEN }}
          PYTHONPATH: src
        run: |
+          . .venv/bin/activate 2>/dev/null || true
          export PATH="$HOME/.local/bin:$PATH"
          python3 -m devx.tools.install_tools --tool tea
-          tea login add --name grm --url "${{ github.server_url }}" --token "$REPO_TOKEN" || true
-          tea login default grm || true
-          python3 -m devx.ci.notify_failure \
+          python3 -m devx.ci.notify_failure --auto-login \
            --repo "${{ github.repository }}" \
            --run-id "${{ github.run_id }}" \
            --workflow "post-merge/release" \
@@ -143,9 +162,7 @@ jobs:
        run: |
          export PATH="$HOME/.local/bin:$PATH"
          python3 -m devx.tools.install_tools --tool tea
-          tea login add --name grm --url "${{ github.server_url }}" --token "$REPO_TOKEN" || true
-          tea login default grm || true
-          python3 -m devx.ci.notify_failure \
+          python3 -m devx.ci.notify_failure --auto-login \
            --repo "${{ github.repository }}" \
            --run-id "${{ github.run_id }}" \
            --workflow "post-merge/sync-wiki" \
@@ -184,9 +201,7 @@ jobs:
        run: |
          export PATH="$HOME/.local/bin:$PATH"
          python3 -m devx.tools.install_tools --tool tea
-          tea login add --name grm --url "${{ github.server_url }}" --token "$REPO_TOKEN" || true
-          tea login default grm || true
-          python3 -m devx.ci.notify_failure \
+          python3 -m devx.ci.notify_failure --auto-login \
            --repo "${{ github.repository }}" \
            --run-id "${{ github.run_id }}" \
            --workflow "post-merge/badges" \
@@ -204,7 +219,7 @@ jobs:
      - name: Install dependencies
        run: |
          . .env 2>/dev/null || true
-          python3 -m pip install --break-system-packages "git+https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/oblachno-oss/devx.git@v0.4.1"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
      - name: Update Vikunja task
        env:
          VIKUNJA_TOKEN: ${{ secrets.VIKUNJA_TOKEN }}
@@ -220,9 +235,7 @@ jobs:
        run: |
          export PATH="$HOME/.local/bin:$PATH"
          python3 -m devx.tools.install_tools --tool tea
-          tea login add --name grm --url "${{ github.server_url }}" --token "$REPO_TOKEN" || true
-          tea login default grm || true
-          python3 -m devx.ci.notify_failure \
+          python3 -m devx.ci.notify_failure --auto-login \
            --repo "${{ github.repository }}" \
            --run-id "${{ github.run_id }}" \
            --workflow "post-merge/vikunja" \
@@ -238,11 +251,13 @@ jobs:
      - name: Install dependencies
        run: |
          . .env 2>/dev/null || true
-          python3 -m pip install --break-system-packages "git+https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/oblachno-oss/devx.git@v0.4.1"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
      - name: Ensure branch protection and labels
        env:
          REPO_TOKEN: ${{ secrets.REPO_TOKEN }}
          PYTHONPATH: src
+          DEVX_REPO_NAME: grm
+          DEVX_REPO_OWNER: oblachno-oss
          DEVX_STATUS_CHECKS: "CI / quality (pull_request),CI / molecule-tests (1) (pull_request),CI / molecule-tests (2) (pull_request),CI / molecule-tests (3) (pull_request)"
        run: python3 -m devx.tools.configure_repo
      - name: Notify on failure
@@ -253,9 +268,7 @@ jobs:
        run: |
          export PATH="$HOME/.local/bin:$PATH"
          python3 -m devx.tools.install_tools --tool tea
-          tea login add --name grm --url "${{ github.server_url }}" --token "$REPO_TOKEN" || true
-          tea login default grm || true
-          python3 -m devx.ci.notify_failure \
+          python3 -m devx.ci.notify_failure --auto-login \
            --repo "${{ github.repository }}" \
            --run-id "${{ github.run_id }}" \
            --workflow "post-merge/configure-repo" \
@@ -4,6 +4,12 @@ on:
  push:
    tags:
      - 'v*'
+  workflow_dispatch:
+    inputs:
+      tag:
+        description: 'Tag to publish (e.g. v0.7.0)'
+        required: true
+        type: string

 jobs:
  publish:
@@ -16,7 +22,7 @@ jobs:
      - name: Install CI tools
        run: |
          . .env 2>/dev/null || true
-          python3 -m pip install --break-system-packages "git+https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/oblachno-oss/devx.git@v0.4.1"
+          python3 -m pip install --break-system-packages --target=src "devx==0.10.2" --extra-index-url "https://emil:${{ secrets.REPO_TOKEN }}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"
          python3 -m devx.tools.install_tools --tool git-cliff --tool tea
      - name: Install build tools
        run: python3 -m pip install --break-system-packages build twine
@@ -30,12 +36,11 @@ jobs:
      - name: Build and publish release
        env:
          REPO_TOKEN: ${{ secrets.REPO_TOKEN }}
-          PYPI_TOKEN: ${{ secrets.PYPI_TOKEN }}
          PYTHONPATH: src
        run: |
          export PATH="$HOME/.local/bin:$PATH"
          python3 -m devx.ci.publish \
-            "${{ github.ref_name }}" \
+            "${{ github.event.inputs.tag || github.ref_name }}" \
            "${{ github.repository }}"
      - name: Notify on failure
        if: failure()
@@ -44,7 +49,7 @@ jobs:
          PYTHONPATH: src
        run: |
          export PATH="$HOME/.local/bin:$PATH"
-          python3 -m devx.ci.notify_failure \
+          python3 -m devx.ci.notify_failure --auto-login \
            --repo "${{ github.repository }}" \
            --run-id "${{ github.run_id }}" \
            --workflow "publish" \
@@ -38,3 +38,6 @@ activate.zsh

 # Generated badges (CI pushes to badges branch)
 .badges/
+
+# Deprecated CI task tracking (branch name is the sole source of truth)
+.taskid
@@ -1 +0,0 @@
-GRM-66
@@ -127,9 +127,9 @@ must go through **every category** in `REVIEW_CHECKLIST.md` and verify
 the **[manual]** items by reviewing the full diff
 (`git diff master...HEAD`).

-Post review comments using `devx.ci.review_pr` (run as `python -m devx.ci.review_pr`):
+Post review comments using `devx.ci.pr_review` (run as `python -m devx.ci.pr_review`):
 ```bash
-REPO_TOKEN=<token> python -m devx.ci.review_pr <pr_number> <owner/repo> \
+REPO_TOKEN=<token> python -m devx.ci.pr_review <pr_number> <owner/repo> \
  --event REQUEST_CHANGES \
  --body "Review summary" \
  --comments-json comments.json
@@ -142,7 +142,7 @@ Fix each comment one by one, commit, and push. Re-review until satisfied.
 Once all checklist items are verified and comments are addressed, post
 an approval review with `--checklist-confirmed` and `--checklist-categories`:
 ```bash
-REPO_TOKEN=<token> python -m devx.ci.review_pr <pr_number> <owner/repo> \
+REPO_TOKEN=<token> python -m devx.ci.pr_review <pr_number> <owner/repo> \
  --event APPROVE --checklist-confirmed \
  --checklist-categories 1,2,3,4,5,6,7,8,9,10,11,12,13 \
  --body "All 13 REVIEW_CHECKLIST.md categories verified. Architecture: <summary>. Security: <summary>. Tests: <summary>. Docs: <summary>."
@@ -254,7 +254,6 @@ via `[tool.devx.classify]` in `pyproject.toml`.
 - `.devin/**` — Agent/CI tooling config
 - `hooks/**` — Git hooks
 - `activate.sh`, `activate.fish`, `activate.zsh` — Generated venv scripts
- `.taskid` — CI task tracking file

 **User-facing paths** (tool changes → release needed) — everything else:
 - `src/gitea_runner_manager/**` — Python CLI source (except `__init__.py` and `api_clients.py`)
@@ -263,7 +262,7 @@ via `[tool.devx.classify]` in `pyproject.toml`.
 - Any new file type not in the allowlist

 **devx module structure** (installed from git, not in this repo):
- `devx.ci.*` — CI/CD automation (run by workflows): release, publish, auto_merge, classify_changes, detect_release_commit, push_badges, doc_coverage, sync_wiki, distribute_molecule, molecule_ci_guard, discover_runners, notify_failure, post_merge, pr_review, review_pr, validate_commit_msg
+- `devx.ci.*` — CI/CD automation (run by workflows): release, publish, auto_merge, classify_changes, detect_release_commit, push_badges, doc_coverage, sync_wiki, distribute_molecule, molecule_ci_guard, discover_runners, notify_failure, post_merge, pr_review, validate_commit_msg
 - `devx.tools.*` — Dev tools (run locally): check_test_speed, configure_repo, install_checkmake, install_tools, setup, generate_badges
 - `devx.molecule.*` — Molecule helpers: molecule_all, platforms, discover_runners, distribute_molecule, molecule_ci_guard
 - `devx.gitea_cli` — Tea CLI wrapper
@@ -319,7 +318,7 @@ The `tea` Gitea CLI tool is used for Gitea API interactions in devx. It is insta
 - `devx.tools.configure_repo` — Creates labels via `tea labels create` (falls back to `GiteaClient` if tea fails; branch protection still uses `GiteaClient` since tea only supports basic protect/unprotect)

 **Operations still using `GiteaClient` (not supported by tea):**
- PR reviews (`devx.ci.review_pr`) — tea v0.14.1 only supports interactive reviews
+- PR reviews (`devx.ci.pr_review`) — tea v0.14.1 only supports interactive reviews
 - Wiki page management (`devx.ci.sync_wiki`)
 - Commit status checks (`devx.ci.auto_merge`)
 - Runner discovery (`devx.molecule.discover_runners`)
@@ -332,7 +331,7 @@ Since devx is installed as a package (via `pip install` from git), it is importa

 | PYTHONPATH | When to use | Example modules |
 |------------|-------------|-----------------|
-| `src` | Module imports from `gitea_runner_manager` | `devx.ci.auto_merge`, `devx.ci.pr_review`, `devx.ci.review_pr`, `devx.ci.sync_wiki`, `devx.ci.post_merge`, `devx.ci.classify_changes`, `devx.molecule.discover_runners`, `devx.ci.doc_coverage` |
+| `src` | Module imports from `gitea_runner_manager` | `devx.ci.auto_merge`, `devx.ci.pr_review`, `devx.ci.pr_review`, `devx.ci.sync_wiki`, `devx.ci.post_merge`, `devx.ci.classify_changes`, `devx.molecule.discover_runners`, `devx.ci.doc_coverage` |
 | (none) | Module has no GRM imports | `devx.ci.detect_release_commit`, `devx.molecule.distribute_molecule`, `devx.molecule.molecule_ci_guard`, `devx.ci.push_badges`, `devx.ci.validate_commit_msg` |

 **In workflows**, always use `env:` blocks (not inline `PYTHONPATH=value`):
@@ -2,6 +2,48 @@

 All notable changes to this project will be documented in this file.

+## [0.8.1] - 2026-06-24
+
+### Bug Fixes
+
+- Repair publish workflow and add publish step to post-merge
+- Add build/twine to ci deps, activate venv in notify_failure
+
+## [0.8.0] - 2026-06-24
+
+### Features
+
+- Remove .taskid file, use branch name only for task ID
+
+### Bug Fixes
+
+- Add workflow_dispatch to publish workflow and update devx to 0.9.12
+
+## [0.7.0] - 2026-06-24
+
+### Features
+
+- Switch devx installation from git to Gitea PyPI registry
+- Adopt per-test timing quality gate from devx 0.7.0
+
+### Bug Fixes
+
+- Update devx to v0.4.2 and fix workflow env vars
+- Pin devx to v0.4.3 to fix post-merge workflow failures
+- Pin devx to v0.4.4 to fix validate-commit-msg and sync-wiki
+- Rewrite CHANGELOG with correct version ordering and missing sections
+- Lower test speed threshold to 4s and update devx to v0.8.2
+- Retrospective fixes for CI/CD friction
+- Replace stale badge SHA URLs with raw/branch/badges/
+
+## [0.6.4] - 2026-06-22
+
+### Bug Fixes
+
+- Update devx to v0.4.2 and fix workflow env vars
+- Pin devx to v0.4.3 to fix post-merge workflow failures
+- Pin devx to v0.4.4 to fix validate-commit-msg and sync-wiki
+
 ## [0.6.3] - 2026-06-22

 ### Bug Fixes
@@ -24,20 +66,6 @@ All notable changes to this project will be documented in this file.
 - Separate GRM and CI translations with validation
 - Migrate from scripts/ to devx package

-## [0.7.0] - 2026-06-22
-
-### Bug Fixes
-
- Include lint extras in setup-ci and setup-release
- Use commit SHA URLs for badges to bypass Gitea cache
- Make sync-wiki and vikunja depend on release
-
-### Refactor
-
- Fully automate PR merge — no manual label/review needed
- Require tea CLI everywhere, fail on missing Vikunja task
- Separate GRM and CI translations with validation
- Migrate from scripts/ to devx package
 ## [0.6.1] - 2026-06-22

 ### Bug Fixes
@@ -45,6 +73,7 @@ All notable changes to this project will be documented in this file.
 - Badges always update on release commits + fix configure-repo PYTHONPATH
 - Enforce commit message convention on master with CI validation
 - Post-merge workflow failures (4 jobs)
+
 ## [0.6.0] - 2026-06-22

 ### Bug Fixes
@@ -58,6 +87,18 @@ All notable changes to this project will be documented in this file.
 ### Revert

 - Remove v0.6.0 release (no user-facing changes)
+
+## [0.5.0] - 2026-06-22
+
+### Features
+
+- Enforce commit naming conventions and workflow discipline
+
+### Bug Fixes
+
+- Clean up infrastructure-only releases and fix release classification
+- Rewrite changelog and re-tag releases at user-facing milestones
+
 ## [0.4.0] - 2026-06-21

 ### Features
@@ -104,6 +145,8 @@ All notable changes to this project will be documented in this file.
 - Add default(0) to gitea_runner_uid in environment blocks
 - Set runner_name in deregister verify.yml
 - Security, dead code, idempotence, and documentation cleanup
+- Use content_base64 for Gitea wiki API, add --verify flag (#33)
+- Wiki links, add --strict integrity check for wiki sync (#34)

 ### Refactor

@@ -112,26 +155,46 @@ All notable changes to this project will be documented in this file.
 - Rework all scripts to use click and i18n
 - *(scripts)* Centralize constants, API clients, and HTTP status codes
 - Rootless Docker, fix auto-merge, molecule platform matrix
-## [0.3.0] - 2026-06-19
+
+## [0.3.2] - 2026-06-21

 ### Features

- Add translated operation report for success and failure cases
- Replace print() with stdlib logging module
- Use click.echo() for user-facing messages with dual logging
- Add colorized output for better visual feedback
- Add --force flag to grm remove for unreachable runners
- Make --ask-become-pass the default behavior
+- Smart CI and release skipping for workflow-only changes

 ### Bug Fixes

- Eliminate duplicate console output, restore GRM_LOG_LEVEL filtering
- Make grm list retrieve runner status correctly
+- Set PYTHONPATH=. for release.py to find scripts.ci module (#32)

 ### Refactor

- Deduplicate CLI, remove dead code, move validation to business layer
- Resolve_runner returns gitea_url, add --url CLI option, force remove improvements, code quality fixes
+- Split CI scripts, fix release PYTHONPATH, dynamic runner discovery
+
+## [0.3.1] - 2026-06-21
+
+### Bug Fixes
+
+- Use correct Gitea 1.26 wiki API endpoints
+
+## [0.3.0] - 2026-06-21
+
+### Features
+
+- Implement documentation-as-code with wiki sync and doc-coverage
+
+## [0.2.2] - 2026-06-21
+
+### Bug Fixes
+
+- Bypass commit-msg hook for release commits
+- Enforce tests pass before tagging a release
+
+## [0.2.1] - 2026-06-21
+
+### Bug Fixes
+
+- Strip git-cliff header from CHANGELOG.md updates
+
 ## [0.2.0] - 2026-06-18

 ### Features
@@ -143,6 +206,12 @@ All notable changes to this project will be documented in this file.
 - Add systemd template units and multi-instance Ansible support
 - Add lifecycle CLI commands and RunnerManager extensions
 - Add runner registry for simplified CLI UX
+- Add translated operation report for success and failure cases
+- Replace print() with stdlib logging module
+- Use click.echo() for user-facing messages with dual logging
+- Add colorized output for better visual feedback
+- Add --force flag to grm remove for unreachable runners
+- Make --ask-become-pass the default behavior

 ### Bug Fixes

@@ -155,12 +224,17 @@ All notable changes to this project will be documented in this file.
 - Remove recursive var definitions from install-runner.yml
 - Convert runner config from TOML to YAML format
 - Rewrite integration test to verify .runner file and container health instead of unreliable API checks
+- Eliminate duplicate console output, restore GRM_LOG_LEVEL filtering
+- Make grm list retrieve runner status correctly

 ### Refactor

 - Remove dead code and legacy artifacts
 - Migrate source terminology from act_runner to gitea_runner
 - Consolidate systemd checks and deduplicate role structure
+- Deduplicate CLI, remove dead code, move validation to business layer
+- Resolve_runner returns gitea_url, add --url CLI option, force remove improvements, code quality fixes
+
 ## [0.1.0] - 2026-06-17

 ### Features
@@ -9,13 +9,14 @@ all: setup

 # Pinned devx version — update this when upgrading devx.
 # All workflow files (.gitea/workflows/*.yml) must be updated to match.
-DEVX_VERSION := v0.4.1
+DEVX_VERSION := v0.10.2

 install-devx: $(VENV)/bin/activate
 	@# REPO_TOKEN may come from .env (local) or environment (CI secrets)
-	@if [ -z "$$REPO_TOKEN" ]; then . .env 2>/dev/null; fi; \
+	@if [ -z "$$REPO_TOKEN" ]; then . ./.env 2>/dev/null; fi; \
 	if [ -z "$$REPO_TOKEN" ]; then echo "REPO_TOKEN not set (check .env or environment)"; exit 1; fi; \
-	$(BIN)/pip install "git+https://emil:$$REPO_TOKEN@git.oblachno.oblachno.fyi/oblachno-oss/devx.git@$(DEVX_VERSION)"
+	$(BIN)/pip install "devx==$(shell echo $(DEVX_VERSION) | sed 's/^v//')" \
+		--extra-index-url "https://emil:$$REPO_TOKEN@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"

 # Full setup for local development (all deps, tools, collections, hooks)
 # install-devx must run before install-tools (which uses devx modules)
@@ -126,10 +127,14 @@ lint-deps:
 		.venv/bin/pip-audit --desc --skip-editable 2>&1 || true

 ansible-lint:
-	$(BIN)/ansible-lint ansible/
+	PATH="$(PWD)/$(BIN):$$PATH" $(BIN)/ansible-lint ansible/

 makefile-lint:
-	@$(CHECKMAKE) Makefile
+	@if command -v $(CHECKMAKE) >/dev/null 2>&1 || [ -x "$(CHECKMAKE)" ]; then \
+		$(CHECKMAKE) Makefile; \
+	else \
+		echo "checkmake not found, skipping Makefile lint"; \
+	fi

 lint-all: lint ansible-lint makefile-lint workflow-lint

@@ -2,18 +2,42 @@

 A lean command-line tool to automate the installation, configuration, and lifecycle management of Gitea Actions runners on Arch Linux, Ubuntu, and Debian hosts.

-Each runner runs in an isolated **rootless Docker** environment under a dedicated system user, enabling multiple runners to operate in parallel on the same host without conflicts.
+Each runner runs in an isolated **rootless Docker** environment under a dedicated system user, enabling multiple runners to operate in parallel on the same host without conflicts. GRM handles the entire runner lifecycle — from initial installation and registration with Gitea, through start/stop/enable/disable operations, to clean removal with deregistration.

 > **Pronunciation:** GRM is short for *Gitea Runner Manager*, but say it like **ГРЪМ** (roughly "GRUM") — the Bulgarian word for **thunder**. An open-source project from **Oblachno** (облачно means *cloudy* in Bulgarian).

 [![CI](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions/workflows/ci.yml/badge.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
 [![License: GPL-3.0](https://img.shields.io/badge/license-GPL--3.0-blue)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/src/branch/master/LICENSE)
-[![Coverage](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki)
-[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases)
-[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/python.svg)](https://www.python.org/downloads/)
+[![Coverage](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki)
+[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases)
+[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/python.svg)](https://www.python.org/downloads/)
+
+## Why GRM?
+
+Managing Gitea Actions runners manually is tedious and error-prone: you need to create system users, set up rootless Docker, download and configure the runner binary, register it with Gitea, create systemd services, and set up Docker prune timers — all per runner instance. GRM automates this entire process with a single command, and ensures it is idempotent (safe to re-run).
+
+Key problems GRM solves:
+
+- **Isolation without root**: Each runner operates under a dedicated system user with its own rootless Docker daemon, so runners on the same host never interfere with each other or with the host's Docker installation.
+- **Reproducible setup**: The Ansible role is idempotent — running `grm install` twice produces zero changes on the second run, so it is safe for CI/CD pipelines and configuration management.
+- **Full lifecycle management**: Install, start, stop, enable (boot persistence), disable (deregister), update the binary, check status, and remove — all from one CLI.
+- **Local registry**: GRM stores connection metadata locally, so after installation you manage runners by name alone without repeating SSH credentials.
+
+## Features
+
+- **Rootless Docker isolation** — Each runner gets its own rootless Docker daemon under a dedicated system user (`grm-<name>`), with its own Docker socket at `/run/user/<UID>/docker.sock`.
+- **Multi-instance support** — Install and manage multiple isolated runners on the same host, each with independent users, data directories, and systemd user services.
+- **Idempotent Ansible role** — Safe to re-run; the role detects existing state and only applies changes when needed.
+- **Full lifecycle CLI** — `install`, `update`, `start`, `stop`, `enable`, `disable`, `status`, `remove`, `list` — all from a single `grm` command.
+- **Automatic integration testing** — Every installation runs an integration test that verifies the `.runner` registration file and systemd service state.
+- **Docker prune automation** — A systemd user timer automatically prunes old Docker images and volumes on a daily schedule.
+- **Local runner registry** — Connection details are stored in `~/.local/share/grm/runners.json`, so lifecycle commands work by runner name alone.
+- **Internationalisation** — Console messages support English, Bulgarian, German, Russian, and Chinese via the `GRM_LANG` environment variable.
+- **Security-conscious** — Secrets (registration tokens) are passed via temporary JSON files with `0600` permissions, never on the command line (CWE-214).
+- **Comprehensive CI/CD** — 100% test coverage, automated releases via conventional commits and git-cliff, Molecule tests across 4 OS platforms.

 ## Quick Start

@@ -26,10 +50,233 @@ cp .env.example .env  # Edit with your Gitea URL and tokens
 grm install 192.168.1.10 --user ubuntu --key ~/.ssh/id_ed25519 --name prod-runner
 ```

-> **Important:** Always checkout the latest release tag before running `make setup`. The `master` branch may contain unreleased changes that are not yet stable. The command above automatically selects the most recent tagged release.
+> **Important:** Always checkout the latest release tag before running `make setup`. The `master` branch may contain unreleased changes that are not yet stable. The command above automatically selects the most recent tagged release. To see all available releases, run `git tag --sort=-version:refname` or check the [releases page](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases).

 > **Tokens:** You need two tokens from your Gitea instance — a **registration token** to register runners, and an **admin API token** for optional post-install verification. See [Getting Started](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Getting-Started.-) for detailed setup instructions.

+## Prerequisites
+
+### On your local machine (where you run `grm`)
+
+- **Python 3.12+** — GRM targets Python 3.12 and requires it for development setup.
+- **Ansible** — Installed automatically by `make setup` (via pip). GRM delegates all remote operations to `ansible-playbook`.
+- **SSH access** — A private key that grants access to the target host(s) as a user with sudo privileges.
+
+### On the target host(s) (where runners will be installed)
+
+- **SSH server** — Reachable via the key specified with `--key`.
+- **Sudo access** — The SSH user must have sudo privileges for creating system users, installing packages, and configuring rootless Docker. By default, you will be prompted for the sudo password interactively. For automation, configure passwordless sudo and pass `--no-ask-become-pass`.
+- **Docker** — Installed automatically by the Ansible role (rootless mode). No pre-existing Docker installation is required.
+- **systemd** — Required for user services and lingering. All supported OSes ship with systemd.
+
+## Installation
+
+### Option 1: From source (recommended for full control)
+
+```bash
+git clone https://git.oblachno.oblachno.fyi/oblachno-oss/grm.git
+cd grm
+git checkout $(git describe --tags --abbrev=0)  # Latest stable release
+make setup
+source .venv/bin/activate
+```
+
+`make setup` performs the following:
+
+1. Verifies Python 3.12+ is installed
+2. Creates a virtualenv in `.venv`
+3. Installs all Python dependencies (including Ansible, Click, python-dotenv)
+4. Creates `.env` from `.env.example` if not present
+5. Installs development tools (actionlint, git-cliff, act_runner, checkmake)
+6. Sets up pre-commit hooks
+
+### Option 2: Via pip (for using GRM without the full repo)
+
+```bash
+pip install gitea-runner-manager
+```
+
+This installs the `grm` CLI and its Python dependencies. Note that the Ansible playbooks and role are bundled with the package, so `grm install` will work out of the box. However, for development or access to Make targets, clone the repository.
+
+### Post-install configuration
+
+After installation, create your `.env` file:
+
+```bash
+cp .env.example .env
+# Edit .env with your Gitea URL and registration token
+```
+
+See the [Configuration](#configuration) section below for details.
+
+## CLI Commands Overview
+
+GRM provides a single `grm` command with subcommands for the full runner lifecycle:
+
+| Command | Description |
+|---------|-------------|
+| `grm install <host>` | Install and configure a runner on a remote host |
+| `grm update <host>` | Update the Gitea Runner binary on a remote host |
+| `grm start <name>` | Start a registered runner |
+| `grm stop <name>` | Stop a registered runner |
+| `grm enable <name>` | Enable a runner to start on boot |
+| `grm disable <name>` | Disable and deregister a runner |
+| `grm status <name>` | Check the status of a registered runner |
+| `grm remove <name>` | Remove a runner completely (with remote cleanup) |
+| `grm list` | List all registered runners with live status |
+| `grm --version` | Show the installed version |
+
+All lifecycle commands (`start`, `stop`, `enable`, `disable`, `status`, `remove`) work by runner name and pull connection details from the local registry. You can override any stored value with `--host`, `--user`, or `--key`.
+
+See the [CLI Commands](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/CLI-Commands.-) wiki page for full argument and option reference.
+
+## Configuration
+
+GRM reads configuration from a `.env` file in the current directory (loaded automatically via python-dotenv). You can also set environment variables directly.
+
+### Required variables
+
+| Variable | Description |
+|----------|-------------|
+| `GITEA_URL` | Your Gitea instance URL (e.g., `https://git.example.com`) |
+| `GITEA_REGISTRATION_TOKEN` | Runner registration token from Gitea (starts with `GR`) |
+
+### Optional variables
+
+| Variable | Default | Description |
+|----------|---------|-------------|
+| `REPO_TOKEN` | — | Gitea admin API token for optional post-install API verification |
+| `GITEA_INTEGRATION_RETRIES` | `3` | Number of API check retries during integration test |
+| `GITEA_RUNNER_USER` | current login | Default SSH user (overrides `--user`) |
+| `GITEA_RUNNER_KEY` | — | Default SSH key path (overrides `--key`) |
+| `GITEA_RUNNER_LABELS` | — | Default runner labels (overrides `--labels`) |
+| `GRM_LANG` | `en` | UI language: `en`, `bg`, `de`, `ru`, `zh` |
+| `GRM_LOG_LEVEL` | `INFO` | Console log level: `DEBUG`, `INFO`, `WARNING`, `ERROR`, `CRITICAL` |
+
+### Getting tokens
+
+**Registration token** (required): Navigate to your Gitea instance:
+
+- **Instance-level**: Site Administration → Actions → Runners → Create Registration Token
+- **Organization-level**: Organization → Settings → Actions → Runners → Create Registration Token
+- **Repository-level**: Repository → Settings → Actions → Runners → Create Registration Token
+
+Use instance-level tokens for shared runners, and repo-level tokens for dedicated runners.
+
+**Admin API token** (optional): Settings → Applications → Generate New Token, with the `admin` scope (or at minimum: `read:user`, `read:repository`, `read:admin`). When set, GRM queries the Gitea API after installation to confirm the runner appears in the runner list. This is purely informational and does not affect pass/fail.
+
+## Multi-Instance Support
+
+One of GRM's core features is the ability to run multiple isolated runners on the same host. Each runner instance gets:
+
+- **Dedicated system user**: `grm-<name>` with its own home directory at `/home/grm-<name>/`
+- **Rootless Docker daemon**: Isolated Docker socket at `/run/user/<UID>/docker.sock`
+- **Data directory**: `/var/lib/gitea-runner/<name>/`
+- **Config directory**: `/etc/gitea-runner/<name>/`
+- **Systemd user service**: `gitea-runner.service` (independent start/stop/enable)
+- **Docker prune timer**: Per-instance daily cleanup
+
+```bash
+# Install two runners on the same host
+grm install 192.168.1.10 --user ubuntu --name workflow-runner
+grm install 192.168.1.10 --user ubuntu --name build-runner
+
+# Manage them independently by name
+grm stop workflow-runner
+grm status build-runner
+grm list
+```
+
+## Security Model
+
+GRM is designed with security as a first-class concern:
+
+- **Rootless Docker**: Each runner operates under a dedicated unprivileged system user. The Docker daemon runs in rootless mode, so containers never have root access to the host. User namespaces (`subuid`/`subgid`) are configured automatically.
+- **Dedicated users**: Each runner gets its own system user (`grm-<name>`) with lingering enabled, so the user's systemd services run without an active login session.
+- **Secret handling**: Registration tokens and admin tokens are never passed on the command line. They are written to temporary JSON files with `0600` permissions and passed to Ansible via `--extra-vars @tempfile`. The temp file is deleted immediately after execution. This prevents secrets from being visible in the process list (`ps aux`), addressing CWE-214.
+- **No shell injection**: The CLI never uses `shell=True` with subprocess. All Ansible commands are constructed as argument lists.
+- **Bandit security scan**: The CI pipeline runs Bandit on every PR to catch common Python security issues.
+
+## Supported Operating Systems
+
+GRM supports and tests the following operating systems:
+
+| OS | Versions | Package manager |
+|----|----------|-----------------|
+| Arch Linux | rolling | pacman |
+| Ubuntu | 22.04, 24.04 | apt |
+| Debian | 12 | apt |
+
+All supported OSes are tested in CI via Molecule scenarios on every PR that changes Ansible files. The platform matrix is defined in `devx.molecule.platforms` as the single source of truth.
+
+## Development Setup
+
+GRM uses a comprehensive development setup with 100% test coverage enforcement, multiple linters, and Molecule integration tests.
+
+### Quick development setup
+
+```bash
+git clone https://git.oblachno.oblachno.fyi/oblachno-oss/grm.git
+cd grm
+git checkout $(git describe --tags --abbrev=0)  # Latest stable release
+make setup
+source .venv/bin/activate
+```
+
+### Make targets
+
+| Target | Description |
+|--------|-------------|
+| `make setup` | Full setup: venv, deps, hooks, CI tools |
+| `make lint-all` | ruff + pyright + bandit + ansible-lint + checkmake + actionlint |
+| `make pytest-cov` | Unit tests with 100% coverage enforcement |
+| `make test-unit` | Unit tests without coverage |
+| `make molecule` | All 6 Molecule scenarios on Ubuntu 22.04 |
+| `make molecule-all` | All 6 scenarios on all 4 supported OSes |
+| `make test-all` | pytest-cov + molecule |
+| `make workflow-lint` | Static lint of workflow YAML (actionlint) |
+| `make workflow-dryrun` | Dry-run all workflows in Docker |
+| `make workflow-check` | workflow-lint + workflow-dryrun |
+
+See the [Development Setup](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Development-Setup.-) wiki page for full details.
+
+## Architecture Overview
+
+GRM consists of two layers:
+
+1. **Python CLI** (`src/gitea_runner_manager/`) — Built with Click, handles argument parsing, environment loading, i18n translations, and delegates to Ansible via the `ansible-playbook` subprocess. Secrets are passed via temporary JSON files to avoid exposure in the process list.
+
+2. **Ansible Role** (`ansible/roles/gitea-runner/`) — Idempotent role that creates a dedicated system user, sets up rootless Docker, installs the runner binary, creates a systemd user service, registers the runner with Gitea, and sets up a Docker prune timer.
+
+```
+grm install <host>
+  └── RunnerManager.install()
+      └── ansible-playbook ansible/install-runner.yml
+          └── role: gitea-runner
+              ├── user_setup.yml       (create per-runner system user + lingering)
+              ├── rootless_docker.yml  (rootless Docker setup under runner user)
+              ├── install_runner.yml   (download binary, config, register, service)
+              ├── prune.yml            (Docker prune timer)
+              └── integration_test.yml (validate service is active)
+```
+
+### Python modules
+
+| Module | Description |
+|--------|-------------|
+| `cli.py` | Click-based CLI entry point — defines all commands |
+| `runner_manager.py` | Ansible orchestration + registry integration |
+| `executor.py` | Ansible subprocess execution with log capture |
+| `registry.py` | Local JSON runner registry at `~/.local/share/grm/runners.json` |
+| `i18n.py` | Internationalisation (en, bg, de, ru, zh) |
+| `exceptions.py` | Custom exceptions (`GRMError`, `AnsibleError`, `APIError`) |
+| `config.py` | Configuration constants (API URLs, repo owner/name) |
+| `logging_config.py` | Logging to `~/.local/state/grm/logs/grm.log` |
+| `report.py` | Operation report tracking with step status |
+| `ui.py` | Colorised console output via Click |
+
+See the [Architecture](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Architecture) wiki page for the full component diagram and data flow.
+
 ## Documentation

 Full documentation lives on the [**GRM Wiki**](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki).
@@ -44,13 +291,22 @@ Full documentation lives on the [**GRM Wiki**](https://git.oblachno.oblachno.fyi

 ### Technical Documentation

- [Architecture](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Architecture) — High-level design, component interactions
+- [Architecture](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Architecture) — High-level design, component interactions, data flow
 - [Development Setup](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Development-Setup.-) — Environment setup, dependencies, local testing
 - [CI/CD Workflow](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/CI-CD-Workflow.-) — How CI works, release process, branch protection
 - [Testing Strategy](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Testing-Strategy.-) — Unit, integration, and Molecule tests
 - [Decision Log](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Decision-Log.-) — Key technical decisions and rationale
 - [Contributing Guide](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Contributing-Guide.-) — Coding standards, PR workflow, commit rules

+## Links
+
+- [Repository](https://git.oblachno.oblachno.fyi/oblachno-oss/grm)
+- [Releases](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases)
+- [Issues](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/issues)
+- [CI/CD Pipeline](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+- [Changelog](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/src/branch/master/CHANGELOG.md)
+- [Wiki](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki)
+
 ## License

-GPL-3.0
+GPL-3.0 — See [LICENSE](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/src/branch/master/LICENSE) for the full text.
@@ -40,6 +40,30 @@
      changed_when: true
      failed_when: false

+    - name: Force-remove all Docker containers (rootless)
+      ansible.builtin.shell: |
+        set -o pipefail
+        docker ps -aq 2>/dev/null | xargs -r docker rm -f 2>/dev/null || true
+      args:
+        executable: /bin/bash
+      become: true
+      become_user: "{{ gitea_runner_service_user | default('grm-' ~ runner_name) }}"
+      environment:
+        XDG_RUNTIME_DIR: "/run/user/{{ gitea_runner_uid | default('') }}"
+        DOCKER_HOST: "unix:///run/user/{{ gitea_runner_uid | default('') }}/docker.sock"
+      changed_when: false
+      failed_when: false
+
+    - name: Prune all Docker images, volumes, and build cache (rootless)
+      ansible.builtin.command: docker system prune -af --volumes
+      become: true
+      become_user: "{{ gitea_runner_service_user | default('grm-' ~ runner_name) }}"
+      environment:
+        XDG_RUNTIME_DIR: "/run/user/{{ gitea_runner_uid | default('') }}"
+        DOCKER_HOST: "unix:///run/user/{{ gitea_runner_uid | default('') }}/docker.sock"
+      changed_when: false
+      failed_when: false
+
    - name: Stop rootless Docker daemon
      ansible.builtin.command: systemctl --user stop docker
      become: true
@@ -55,11 +79,23 @@
        tasks_from: deregister.yml
      when: not skip_runner_registration | default(false)

+    - name: Remove docker-prune user service file
+      ansible.builtin.file:
+        path: "{{ gitea_runner_home | default('/home/grm-' ~ runner_name) }}/.config/systemd/user/docker-prune.service"
+        state: absent
+      failed_when: false
+
+    - name: Remove docker-prune user timer file
+      ansible.builtin.file:
+        path: "{{ gitea_runner_home | default('/home/grm-' ~ runner_name) }}/.config/systemd/user/docker-prune.timer"
+        state: absent
+      failed_when: false
+
    - name: Remove systemd user unit file
      ansible.builtin.file:
        path: "{{ gitea_runner_home | default('/home/grm-' ~ runner_name) }}/.config/systemd/user/gitea-runner.service"
        state: absent
-      when: remove_systemd_template | default(false)
+      when: remove_systemd_template | default(true)

    - name: Kill remaining processes of runner user
      ansible.builtin.command: loginctl terminate-user "{{ gitea_runner_service_user | default('grm-' ~ runner_name) }}"
@@ -84,6 +120,27 @@
      when: remove_runner_user | default(true)
      failed_when: false

+    - name: Remove Docker data root when user is kept
+      ansible.builtin.file:
+        path: "{{ gitea_runner_home | default('/home/grm-' ~ runner_name) }}/.local/share/docker"
+        state: absent
+      when: not (remove_runner_user | default(true))
+      failed_when: false
+
+    - name: Remove act cache when user is kept
+      ansible.builtin.file:
+        path: "{{ gitea_runner_home | default('/home/grm-' ~ runner_name) }}/.cache/act"
+        state: absent
+      when: not (remove_runner_user | default(true))
+      failed_when: false
+
+    - name: Remove systemd user config dir when user is kept
+      ansible.builtin.file:
+        path: "{{ gitea_runner_home | default('/home/grm-' ~ runner_name) }}/.config/systemd/user"
+        state: absent
+      when: not (remove_runner_user | default(true))
+      failed_when: false
+
    - name: Remove subuid entry for runner user
      ansible.builtin.lineinfile:
        path: /etc/subuid
@@ -24,6 +24,10 @@ gitea_runner_prune_label: "gitea-runner=true"
 # Service configuration
 gitea_runner_service_restart_sec: "5"

+# Removal defaults
+remove_systemd_template: true
+remove_runner_user: true
+
 # Runner configuration
 gitea_runner_log_level: "info"
 gitea_runner_container_label: "gitea-runner=true"
@@ -0,0 +1,12 @@
+---
+- name: Converge
+  hosts: all
+  become: true
+  vars:
+    gitea_url: "http://localhost:3000"
+    registration_token: "fake-token-for-testing"
+    runner_name: "remove-test-runner"
+    skip_runner_registration: true
+    docker_rootless_setup: false
+  roles:
+    - role: gitea-runner
@@ -0,0 +1,39 @@
+---
+driver:
+  name: docker
+
+platforms:
+  - name: ${MOLECULE_PLATFORM_NAME:-ubuntu-2204}
+    image: ${MOLECULE_PLATFORM_IMAGE:-ubuntu:22.04}
+    command: ${MOLECULE_PLATFORM_COMMAND:-sleep infinity}
+    volumes:
+      - /sys/fs/cgroup:/sys/fs/cgroup:rw
+    cgroupns_mode: host
+    privileged: true
+    pre_build_image: false
+
+provisioner:
+  name: ansible
+  playbooks:
+    converge: converge.yml
+    prepare: ../common/prepare.yml
+    side_effect: side_effect.yml
+  env:
+    ANSIBLE_ROLES_PATH: "../../.."
+
+scenario:
+  test_sequence:
+    - dependency
+    - cleanup
+    - destroy
+    - syntax
+    - create
+    - prepare
+    - converge
+    - side_effect
+    - verify
+    - cleanup
+    - destroy
+
+verifier:
+  name: ansible
@@ -0,0 +1,8 @@
+---
+- name: Remove runner via remove-runner playbook
+  ansible.builtin.import_playbook: "../../../../remove-runner.yml"
+  vars:
+    runner_name: "remove-test-runner"
+    registration_token: "fake-token-for-testing"
+    gitea_url: "http://localhost:3000"
+    skip_runner_registration: true
@@ -0,0 +1,114 @@
+---
+- name: Verify runner was fully removed
+  hosts: all
+  become: true
+  vars:
+    runner_name: "remove-test-runner"
+  pre_tasks:
+    - name: Load role defaults
+      ansible.builtin.include_vars:
+        dir: "{{ lookup('env', 'MOLECULE_PROJECT_DIRECTORY') }}/defaults"
+  tasks:
+    - name: Check runner user is absent
+      ansible.builtin.getent:
+        database: passwd
+        key: "{{ gitea_runner_service_user }}"
+      register: user_check
+      failed_when: false
+
+    - name: Assert runner user is absent
+      ansible.builtin.assert:
+        that:
+          - user_check.ansible_facts.getent_passwd is none or
+            gitea_runner_service_user not in (user_check.ansible_facts.getent_passwd | default({}))
+        fail_msg: "Runner user still exists after removal"
+
+    - name: Check runner home directory is absent
+      ansible.builtin.stat:
+        path: "{{ gitea_runner_home }}"
+      register: home_stat
+
+    - name: Assert runner home directory is absent
+      ansible.builtin.assert:
+        that:
+          - not home_stat.stat.exists
+        fail_msg: "Runner home directory still exists after removal"
+
+    - name: Check runner data directory is absent
+      ansible.builtin.stat:
+        path: "{{ gitea_runner_data_dir }}"
+      register: data_stat
+
+    - name: Assert runner data directory is absent
+      ansible.builtin.assert:
+        that:
+          - not data_stat.stat.exists
+        fail_msg: "Runner data directory still exists after removal"
+
+    - name: Check runner config directory is absent
+      ansible.builtin.stat:
+        path: "{{ gitea_runner_config_dir }}"
+      register: config_stat
+
+    - name: Assert runner config directory is absent
+      ansible.builtin.assert:
+        that:
+          - not config_stat.stat.exists
+        fail_msg: "Runner config directory still exists after removal"
+
+    - name: Check gitea-runner service unit is absent
+      ansible.builtin.stat:
+        path: "{{ gitea_runner_home }}/.config/systemd/user/gitea-runner.service"
+      register: service_stat
+
+    - name: Assert gitea-runner service unit is absent
+      ansible.builtin.assert:
+        that:
+          - not service_stat.stat.exists
+        fail_msg: "gitea-runner service unit still exists after removal"
+
+    - name: Check docker-prune service unit is absent
+      ansible.builtin.stat:
+        path: "{{ gitea_runner_home }}/.config/systemd/user/docker-prune.service"
+      register: prune_service_stat
+
+    - name: Assert docker-prune service unit is absent
+      ansible.builtin.assert:
+        that:
+          - not prune_service_stat.stat.exists
+        fail_msg: "docker-prune service unit still exists after removal"
+
+    - name: Check docker-prune timer unit is absent
+      ansible.builtin.stat:
+        path: "{{ gitea_runner_home }}/.config/systemd/user/docker-prune.timer"
+      register: prune_timer_stat
+
+    - name: Assert docker-prune timer unit is absent
+      ansible.builtin.assert:
+        that:
+          - not prune_timer_stat.stat.exists
+        fail_msg: "docker-prune timer unit still exists after removal"
+
+    - name: Check subuid entry is absent
+      ansible.builtin.command: "grep -c '^{{ gitea_runner_service_user }}:' /etc/subuid"
+      register: subuid_check
+      changed_when: false
+      failed_when: false
+
+    - name: Assert subuid entry is absent
+      ansible.builtin.assert:
+        that:
+          - subuid_check.rc != 0
+        fail_msg: "subuid entry still exists after removal"
+
+    - name: Check subgid entry is absent
+      ansible.builtin.command: "grep -c '^{{ gitea_runner_service_user }}:' /etc/subgid"
+      register: subgid_check
+      changed_when: false
+      failed_when: false
+
+    - name: Assert subgid entry is absent
+      ansible.builtin.assert:
+        that:
+          - subgid_check.rc != 0
+        fail_msg: "subgid entry still exists after removal"
@@ -2,34 +2,66 @@

 A lean command-line tool to automate the installation, configuration, and lifecycle management of Gitea Actions runners on Arch Linux, Ubuntu, and Debian hosts.

+Each runner runs in an isolated **rootless Docker** environment under a dedicated system user, enabling multiple runners to operate in parallel on the same host without conflicts. GRM handles the entire runner lifecycle — from initial installation and registration with Gitea, through start/stop/enable/disable operations, to clean removal with deregistration.
+
 > **Pronunciation:** GRM is short for *Gitea Runner Manager*, but say it like **ГРЪМ** (roughly "GRUM") — the Bulgarian word for **thunder**. An open-source project from **Oblachno** (облачно means *cloudy* in Bulgarian).

 [![CI](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions/workflows/ci.yml/badge.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Coverage](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki)
-[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/424af0deb20f7fff36433285b486ddf10aea07fc/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases)
+[![License: GPL-3.0](https://img.shields.io/badge/license-GPL--3.0-blue)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/src/branch/master/LICENSE)
+[![Coverage](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki)
+[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases)
+[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/a7a72d7d1dbfebed51083c9eb06713d272dda77d/python.svg)](https://www.python.org/downloads/)
+
+## Overview
+
+GRM is a two-layer tool: a Python CLI (built with Click) that delegates to an idempotent Ansible role for all remote operations. The CLI handles argument parsing, environment loading, internationalisation, and local registry management. The Ansible role handles the actual runner setup — creating dedicated system users, configuring rootless Docker, downloading and registering the runner binary, creating systemd user services, and setting up Docker prune timers.
+
+### Key capabilities
+
+- **Rootless Docker isolation** — Each runner gets its own rootless Docker daemon under a dedicated system user (`grm-<name>`).
+- **Multi-instance support** — Multiple isolated runners on the same host, each with independent users, data directories, and systemd services.
+- **Full lifecycle CLI** — `install`, `update`, `start`, `stop`, `enable`, `disable`, `status`, `remove`, `list`.
+- **Idempotent Ansible role** — Safe to re-run; second run produces zero changes.
+- **Automatic integration testing** — Every installation verifies the `.runner` registration file and systemd service state.
+- **Local runner registry** — Connection details stored locally; manage runners by name after installation.
+- **Internationalisation** — Console messages in English, Bulgarian, German, Russian, and Chinese.
+- **Security-conscious** — Secrets passed via temporary JSON files with `0600` permissions (CWE-214).
+
+### Supported operating systems
+
+| OS | Versions | Package manager |
+|----|----------|-----------------|
+| Arch Linux | rolling | pacman |
+| Ubuntu | 22.04, 24.04 | apt |
+| Debian | 12 | apt |
+
+All supported OSes are tested in CI via Molecule scenarios on every PR that changes Ansible files.

 ## User Documentation

- [Getting Started](Getting-Started.-) — Installation, quick start, first run
- [Installation](Installation) — Prerequisites, setup, multiple instances
- [CLI Commands](CLI-Commands.-) — All commands with arguments and options
- [Troubleshooting](Troubleshooting) — Common issues and solutions
+- [Getting Started](Getting-Started.-) — Installation, quick start, token setup, first run, log viewing
+- [Installation](Installation) — Prerequisites, setup methods, multiple instances, runner registry
+- [CLI Commands](CLI-Commands.-) — All commands with arguments, options, and examples
+- [Troubleshooting](Troubleshooting) — Common issues, diagnostics, and solutions
 - [FAQ](FAQ) — Frequently asked questions

 ## Technical Documentation

- [Architecture](Architecture) — High-level design, component interactions, data flow
- [Development Setup](Development-Setup.-) — Environment setup, dependencies, local testing
- [CI/CD Workflow](CI-CD-Workflow.-) — How CI works, release process, branch protection
- [Testing Strategy](Testing-Strategy.-) — Unit, integration, and Molecule tests
- [Decision Log](Decision-Log.-) — Key technical decisions and rationale
- [Contributing Guide](Contributing-Guide.-) — Coding standards, PR workflow, commit rules
+- [Architecture](Architecture) — High-level design, component diagram, data flow, security model, per-runner isolation
+- [Development Setup](Development-Setup.-) — Environment setup, project structure, dependencies, linting, testing
+- [CI/CD Workflow](CI-CD-Workflow.-) — PR workflow, branch protection, release pipeline, change classification, badge generation
+- [Testing Strategy](Testing-Strategy.-) — Unit tests, Molecule scenarios, integration tests, CI distribution
+- [Decision Log](Decision-Log.-) — Key technical decisions and rationale (ADRs)
+- [Contributing Guide](Contributing-Guide.-) — Coding standards, PR workflow, commit conventions, Ansible role conventions

 ## Quick Links

 - [Repository](https://git.oblachno.oblachno.fyi/oblachno-oss/grm)
+- [Releases](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases)
+- [Issues](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/issues)
 - [CI/CD Pipeline](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
 - [Changelog](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/src/branch/master/CHANGELOG.md)
+- [License (GPL-3.0)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/src/branch/master/LICENSE)
@@ -5,6 +5,21 @@ GRM consists of two layers:
 1. **Python CLI** (`src/gitea_runner_manager/`) — built with Click, handles argument parsing, environment loading, i18n translations, and delegates to Ansible via the `ansible-playbook` subprocess.
 2. **Ansible Role** (`ansible/roles/gitea-runner/`) — idempotent role that creates a dedicated system user, sets up rootless Docker, installs the runner binary, creates a systemd user service, and registers the runner with Gitea.

+## High-Level Design
+
+The CLI is a thin orchestration layer. It does not perform any remote operations itself — every action (install, update, start, stop, etc.) is delegated to an Ansible playbook. The CLI's responsibilities are:
+
+- Parsing command-line arguments and options
+- Loading configuration from `.env` (via python-dotenv)
+- Resolving runner connection details from the local registry
+- Writing secrets to temporary JSON files (CWE-214 mitigation)
+- Constructing the `ansible-playbook` command with appropriate inventory, user, key, and extra-vars
+- Capturing and streaming Ansible output to log files
+- Maintaining the local runner registry (`~/.local/share/grm/runners.json`)
+- Providing colorised console output and operation reports
+
+The Ansible role handles all remote state: user creation, package installation, Docker configuration, binary download, runner registration, systemd service management, and Docker prune timers.
+
 ## Component Tree

 ```
@@ -30,6 +45,33 @@ main.yml → systemd_check → user_setup → rootless_docker → install_runner
 - `systemctl --user` tasks must be guarded by `docker_rootless_setup`
 - Template creation tasks are NOT guarded by `docker_rootless_setup` (they just create files)

+### Ansible task files
+
+| Task file | Responsibility |
+|-----------|---------------|
+| `main.yml` | Entry point — includes all other task files in order |
+| `systemd_check.yml` | Verifies systemd is available on the target host |
+| `user_setup.yml` | Creates the per-runner system user, enables lingering, configures subuid/subgid, creates data and config directories |
+| `rootless_docker.yml` | Installs Docker packages (apt for Debian/Ubuntu, pacman for Arch), runs `dockerd-rootless-setuptool.sh install`, starts and enables the rootless Docker daemon |
+| `install_runner.yml` | Downloads the gitea_runner binary, creates the config file, validates the binary, registers the runner with Gitea, creates and starts the systemd user service |
+| `download_gitea_runner.yml` | Downloads the gitea_runner binary from GitHub releases |
+| `validate.yml` | Validates the downloaded binary |
+| `register.yml` | Registers the runner with Gitea using the registration token |
+| `service.yml` | Creates the systemd user service file and starts/enables the service |
+| `prune.yml` | Creates a systemd user timer for daily Docker image and volume pruning |
+| `integration_test.yml` | Verifies the `.runner` file exists and the systemd service is active; optionally queries the Gitea API |
+| `deregister.yml` | Deregisters the runner from Gitea and removes the `.runner` file |
+| `update_runner.yml` | Downloads a new version of the gitea_runner binary |
+
+### Ansible templates
+
+| Template | Purpose |
+|----------|---------|
+| `gitea-runner-user.service.j2` | Systemd user service for the gitea_runner daemon |
+| `gitea-runner-config.yaml.j2` | Runner configuration file (labels, capacity, log level) |
+| `docker-prune.service.j2` | Systemd user service for Docker pruning (oneshot) |
+| `docker-prune.timer.j2` | Systemd user timer triggering daily Docker prune |
+
 ## Per-Runner Isolation

 Each runner runs as a systemd user service under a dedicated system user (`grm-<name>`). Each instance has fully isolated resources:
@@ -40,6 +82,9 @@ Each runner runs as a systemd user service under a dedicated system user (`grm-<
 - **Config**: `/etc/gitea-runner/<name>/`
 - **Service**: `gitea-runner.service` (systemd user service)
 - **Docker socket**: `/run/user/<UID>/docker.sock` (rootless, per-runner)
+- **subuid/subgid**: `grm-<name>:100000:65536` (user namespace mapping)
+
+Lingering is enabled via `loginctl enable-linger` so the user's systemd services run without an active login session. This is essential for runners that need to operate continuously.

 ## Component Interactions

@@ -58,11 +103,13 @@ flowchart TD
    TEST["integration_test.yml<br/>validate service active"]
    GITEA["Gitea instance<br/>registration + API"]
    SYSTEMD["systemd user service<br/>gitea-runner.service"]
+    LOG["Log files<br/>~/.local/state/grm/logs/"]

    CLI --> RM
    RM --> REG
    RM --> EXEC
    EXEC -->|subprocess| ANS
+    EXEC -->|stream output| LOG
    ANS --> ROLE
    ROLE --> USER
    ROLE --> DOCKER
@@ -72,14 +119,85 @@ flowchart TD
    INSTALL -->|register| GITEA
    INSTALL --> SYSTEMD
    DOCKER --> SYSTEMD
+    TEST -->|optional API check| GITEA
 ```

+## Data Flow
+
+### Installation flow
+
+1. User runs `grm install <host> --user <user> --key <key> --name <name>`
+2. CLI loads `.env` for `GITEA_URL` and `GITEA_REGISTRATION_TOKEN`
+3. `RunnerManager.install()` constructs extra-vars dict with registration token, runner name, Gitea URL, and optional admin token/labels
+4. Extra-vars are written to a temporary JSON file with `0600` permissions
+5. `AnsibleExecutor.run()` invokes `ansible-playbook ansible/install-runner.yml` with the temp file via `--extra-vars @tempfile`
+6. Ansible connects to the remote host via SSH and executes the role:
+   - Creates system user `grm-<name>` with lingering
+   - Installs Docker packages and sets up rootless Docker
+   - Downloads the gitea_runner binary
+   - Creates the runner config file
+   - Registers the runner with Gitea
+   - Creates and starts the systemd user service
+   - Sets up the Docker prune timer
+   - Runs the integration test (verifies `.runner` file and service state)
+7. Ansible output is streamed to a timestamped log file at `~/.local/state/grm/logs/ansible-<timestamp>.log`
+8. On success, the runner is added to the local registry at `~/.local/share/grm/runners.json`
+9. The temporary extra-vars file is deleted
+
+### Lifecycle command flow
+
+1. User runs `grm <command> <runner_name>` (e.g., `grm stop prod-runner`)
+2. `RunnerManager._resolve_runner()` looks up the runner in the local registry
+3. If `--host` and `--user` are provided, they override registry values
+4. The corresponding playbook is executed (e.g., `stop-runner.yml`)
+5. Ansible connects to the remote host and performs the action
+
+### List command flow
+
+1. User runs `grm list`
+2. `RunnerManager.list_runners()` reads all entries from the local registry
+3. For each runner, an Ansible ad-hoc command checks `systemctl --user is-active gitea-runner`
+4. Results are displayed in a table with columns: NAME, HOST, USER, LABELS, STATUS
+
+## Security Model
+
+### Rootless Docker
+
+Each runner operates under a dedicated unprivileged system user. The Docker daemon runs in rootless mode via `dockerd-rootless-setuptool.sh install`, which configures:
+
+- User namespace mapping via `/etc/subuid` and `/etc/subgid` (range: 100000-165535)
+- Rootless Docker socket at `/run/user/<UID>/docker.sock`
+- `slirp4netns` for user-mode networking
+- `fuse-overlayfs` for rootless container storage
+
+Containers launched by the runner never have root access to the host. The rootless Docker daemon is started as a systemd user service and persists via lingering.
+
+### Secret handling
+
+Registration tokens and admin API tokens are never exposed on the command line. The `RunnerManager._extra_vars_file()` context manager:
+
+1. Creates a temporary file via `tempfile.mkstemp()`
+2. Writes the extra-vars JSON to the file
+3. Sets permissions to `0600` (owner read/write only)
+4. Passes the file to Ansible via `--extra-vars @tempfile`
+5. Deletes the file in a `finally` block, even if an exception occurs
+
+This prevents secrets from appearing in the process list (`ps aux`), addressing CWE-214.
+
+### No shell injection
+
+The CLI never uses `shell=True` with subprocess. All Ansible commands are constructed as argument lists (`list[str]`), preventing shell injection attacks. The `subprocess.Popen` and `subprocess.run` calls are marked with `nosec` comments after security review.
+
+### Bandit security scanning
+
+The CI pipeline runs Bandit on every PR to catch common Python security issues. The scan covers all source code in `src/`.
+
 ## Additional Components

 From `AGENTS.md`, the project also includes:

- **devx package** (installed from git) — Reusable CI/CD tools: auto-merge, post-merge, release, publishing, molecule distribution, PR reviews, failure notifications
- **Versioning** (`cliff.toml`) — git-cliff configuration for automated semver versioning from conventional commits
+- **devx package** (installed from git) — Reusable CI/CD tools: auto-merge, post-merge, release, publishing, molecule distribution, PR reviews, failure notifications. This package is not part of the GRM tool itself — it provides the CI/CD automation infrastructure.
+- **Versioning** (`cliff.toml`) — git-cliff configuration for automated semver versioning from conventional commits.

 ## Python Modules

@@ -89,9 +207,27 @@ The Python CLI layer (`src/gitea_runner_manager/`) consists of the following mod
 |--------|-------------|
 | `cli.py` | Click-based CLI entry point — defines all commands (install, update, start, stop, enable, disable, status, remove, list) |
 | `runner_manager.py` | Ansible orchestration + registry integration — delegates to executor and manages runner lifecycle |
-| `executor.py` | Ansible subprocess execution — runs `ansible-playbook` with extra-vars via temp JSON files |
+| `executor.py` | Ansible subprocess execution — runs `ansible-playbook` with extra-vars via temp JSON files, streams output to log files |
 | `registry.py` | Local JSON runner registry at `~/.local/share/grm/runners.json` — stores connection metadata |
-| `i18n.py` | Internationalization translations (en, bg, de, ru, zh) |
-| `exceptions.py` | Custom exceptions (`GRMError`, `APIError`) |
-| `api_clients.py` | Gitea and Vikunja API client classes for CI automation scripts |
+| `i18n.py` | Internationalisation translations (en, bg, de, ru, zh) — opt-in via `GRM_LANG` environment variable |
+| `exceptions.py` | Custom exceptions (`GRMError`, `AnsibleError`, `APIError`) |
 | `config.py` | Configuration constants (API URLs, repo owner/name, project IDs) — overridable via environment variables |
+| `logging_config.py` | Logging configuration — writes all messages to `~/.local/state/grm/logs/grm.log` at DEBUG level |
+| `report.py` | Operation report tracking — prints a step-by-step report with status icons after each command |
+| `ui.py` | User-facing output utilities — colorised console output via `click.style`, with log file always receiving plain text |
+| `api_clients.py` | Gitea and Vikunja API client classes for CI automation scripts (not used by the CLI itself) |
+| `translations.json` | Translation strings for all supported languages |
+
+## Logging
+
+GRM writes to two destinations:
+
+| Destination | Level | Content |
+|-------------|-------|---------|
+| Console (stdout) | `GRM_LOG_LEVEL` (default: INFO) | Colorised user-facing messages and operation reports |
+| `~/.local/state/grm/logs/grm.log` | DEBUG | All messages with timestamps and severity |
+| `~/.local/state/grm/logs/ansible-<timestamp>.log` | — | Full Ansible playbook output per execution |
+
+Console output is automatically colorised via `click.style`: operation headers in bright cyan, completed steps in green, failures in red, and status updates in yellow. The log file always captures plain text (no ANSI codes) at DEBUG level regardless of the console setting.
+
+Set `GRM_LOG_LEVEL` to one of `DEBUG`, `INFO`, `WARNING`, `ERROR`, or `CRITICAL` to control console verbosity.
@@ -1,5 +1,16 @@
 # CI/CD Workflow

+GRM uses a fully automated CI/CD pipeline built on Gitea Actions. Every change to master goes through a mandatory PR workflow with branch protection, automated review, and auto-merge. Releases are automated via git-cliff and conventional commits.
+
+## Workflow Overview
+
+| Workflow | Trigger | Purpose |
+|----------|---------|---------|
+| `ci.yml` | PR opened/synchronized | Quality checks (lint, test, coverage) + molecule tests |
+| `auto-merge.yml` | PR labeled `ready-to-merge` | Validates and squash-merges the PR |
+| `post-merge.yml` | Push to `master` | Release, wiki sync, badges, Vikunja task update |
+| `publish.yml` | Tag push (`v*`) | Build and publish package to PyPI, create Gitea release |
+
 Every change to master goes through a mandatory PR workflow. No exceptions.

 ## PR Workflow
@@ -60,10 +71,10 @@ Review the full diff (`git diff master...HEAD`) focusing on:
 - **User experience**: Clear error messages, intuitive CLI flags, helpful output
 - **Documentation**: Completeness and relevance of docs, CHANGELOG entries, AGENTS.md updates

-Post review comments using `devx.ci.review_pr`:
+Post review comments using `devx.ci.pr_review`:

 ```bash
-REPO_TOKEN=<token> python -m devx.ci.review_pr <pr_number> <owner/repo> \
+REPO_TOKEN=<token> python -m devx.ci.pr_review <pr_number> <owner/repo> \
  --event REQUEST_CHANGES \
  --body "Review summary" \
  --comments-json comments.json
@@ -78,7 +89,7 @@ Fix each comment one by one, commit, and push. Re-review until satisfied.
 Once all comments are addressed:

 ```bash
-REPO_TOKEN=<token> python -m devx.ci.review_pr <pr_number> <owner/repo> \
+REPO_TOKEN=<token> python -m devx.ci.pr_review <pr_number> <owner/repo> \
  --event APPROVE \
  --body "All comments addressed. LGTM."
 ```
@@ -145,12 +156,13 @@ After a PR is merged to master, the release pipeline runs automatically.
 - Installs git-cliff (version 2.13.0)
 - Configures git as `grm-ci-bot`
 - Runs `devx.ci.release` which uses **git-cliff** to:
+  - **Checks for user-facing changes** via `devx.ci.classify_changes` — if only workflow/infrastructure files changed, the release is **skipped entirely** — no version bump, no tag, no publish
  - Calculate the next semver version from conventional commits since the last tag
  - Update `__version__` in `src/gitea_runner_manager/__init__.py` (single source of truth)
  - Update `CHANGELOG.md` with the new version section
  - **Run `make lint-ruff` and `make pytest-cov`** to verify the release is healthy
  - If lint or tests fail, **abort immediately** — no commit, no tag
-  - Commit with `release: vX.Y.Z` prefix (cleaner than `chore(release):`)
+  - Commit with `release: vX.Y.Z [skip ci]` prefix (the `[skip ci]` prevents re-triggering post-merge on the release commit)
  - Create an annotated tag `vX.Y.Z` on the release commit
  - Push both the commit and tag to master
 - `--skip-tests` flag bypasses test verification (emergency use only, not recommended)
@@ -178,13 +190,22 @@ After a PR is merged to master, the release pipeline runs automatically.
 ### Post-Merge Workflow (`.gitea/workflows/post-merge.yml`)

 - Triggers on push to `master`
- Runs `devx.ci.post_merge` with the latest commit message and commit SHA
- Marks the corresponding Vikunja task as done
+- Consolidates release, wiki sync, badge generation, and Vikunja task updates into a single workflow
+- **detect-type** — Runs `devx.ci.detect_release_commit` to check if the commit is a release commit (`release: vX.Y.Z`). All subsequent jobs skip for release commits (the `[skip ci]` tag also prevents re-triggering).
+- **release** — Runs `devx.ci.release` (see Automated Release Pipeline below)
+- **sync-wiki** — Syncs documentation to the Gitea wiki via `devx.ci.sync_wiki`
+- **badges** — Generates and pushes quality badge SVGs to the `badges` branch via `devx.ci.push_badges`. Runs after the release job (even if release fails or is skipped) so the version badge always reflects the latest state.
+- **vikunja** — Marks the corresponding Vikunja task as done via `devx.ci.post_merge`

 ### Smart CI: User-Facing vs Workflow-Only Changes

 Not all changes require the full CI pipeline or a new release. The project uses
-`devx.ci.classify_changes` to classify changed files into two categories:
+`devx.ci.classify_changes` to classify changed files into two categories.
+
+**Classification strategy (safe-by-default):** Any file NOT in the explicit
+workflow-only allowlist is treated as user-facing. This prevents new file types
+from accidentally skipping releases. Classification is config-driven via
+`[tool.devx.classify]` in `pyproject.toml`.

 **User-facing paths** (tool changes → release needed):
 - `src/gitea_runner_manager/**` — Python CLI source
@@ -9,6 +9,15 @@
 - Line length: 120 chars
 - Secrets are passed via temp JSON files, never on the command line (CWE-214)
 - CI triggers only on `opened` and `synchronize` PR events (not `labeled`)
+- No `print()` — use `click.echo()` via `ui.say()` for console output
+- No bare `except` — catch specific exceptions
+- No `TODO`/`FIXME` comments in committed code
+- No functions longer than 50 lines
+- No `shell=True` with subprocess
+- No `eval()` or `exec()`
+- No raw strings in `click.echo()` without `_()` wrapper (i18n)
+- No `open()` without `with` statement
+- No `Popen()` without cleanup

 ## Code Style Rules

@@ -16,7 +25,11 @@
 - **Line length**: 120 characters
 - **Test coverage**: 100% required (`--cov-fail-under=100`)
 - **Secrets handling**: Secrets are passed via temp JSON files with `0600` permissions, never on the command line (CWE-214). Extra-vars are written to a temporary JSON file and passed via `--extra-vars @tempfile`, which is deleted after execution. This prevents secrets from being visible in the process list (`ps aux`).
- **Linting**: `make lint-all` runs ruff + pyright + bandit + ansible-lint + checkmake
+- **Linting**: `make lint-all` runs ruff + pyright + bandit + ansible-lint + checkmake + actionlint
+- **Formatting**: `ruff format` with double quotes and space indentation
+- **Type checking**: `pyright` in strict mode for `src/gitea_runner_manager/`
+- **Security scanning**: `bandit -r src/` on every PR
+- **Import rules**: `src/gitea_runner_manager/` NEVER imports from devx — the GRM tool is self-contained

 ## Commit Rules

@@ -26,8 +39,14 @@ Branch commits use conventional commit format (no `GRM-N:` prefix):
 feat: add new feature
 fix: resolve bug
 docs: update README
+ci: update workflow
+refactor: simplify executor
+test: add molecule scenario
+chore: update dependencies
 ```

+The pre-commit hook validates that commit messages follow the conventional commit format. Non-conventional commits are rejected.
+
 ### Version Bumping Rules

 | Commit type | Version bump |
@@ -55,14 +74,104 @@ Every change to master goes through this workflow. No exceptions.
 3. **Implement** — write code, tests (100% coverage), update docs
 4. **Commit** — conventional commits (no `GRM-N:` prefix on branch)
 5. **Push & create PR** — title: `GRM-N: <vikunja task title>`, body: summary + `Closes GRM-N`
-6. **Review** — review the full diff focusing on: functional completeness, edge cases, technical excellence (architecture, SRP, deduplication, code smells, best practices, code quality, reusability, clean code, readability, maintainability, extensibility), performance, security, UX, documentation completeness/relevance. Post review comments via `devx.ci.review_pr`.
+6. **Review** — review the full diff focusing on: functional completeness, edge cases, technical excellence (architecture, SRP, deduplication, code smells, best practices, code quality, reusability, clean code, readability, maintainability, extensibility), performance, security, UX, documentation completeness/relevance. Post review comments via `devx.ci.pr_review`.
 7. **Address comments** — fix each comment, commit, push, re-review
-8. **Approve** — post an `APPROVE` review via `devx.ci.review_pr`
+8. **Approve** — post an `APPROVE` review via `devx.ci.pr_review`
 9. **Add `ready-to-merge` label** — auto-merge workflow squash-merges with title `GRM-N <conventional commit message>`, post-merge workflow marks the Vikunja task as done, release workflow automatically versions and tags
+### 1. Create Vikunja task
+
+Create a task in Vikunja project 6 to get a `GRM-N` identifier.
+
+### 2. Create branch
+
+```bash
+git checkout master && git pull
+git checkout -b GRM-N-short-description
+```
+
+### 3. Implement changes
+
+- Write code following conventions above
+- Write/update tests (100% coverage required)
+- Update documentation (CHANGELOG, README, AGENTS.md, docs/ as needed)
+
+### 4. Commit (conventional commits)
+
+Branch commits use conventional commit format (no `GRM-N:` prefix):
+
+```
+feat: add new feature
+fix: resolve bug
+docs: update README
+```
+
+### 5. Push and create PR
+
+- **PR title format**: `GRM-N: <vikunja task title>` (must match the Vikunja task title exactly)
+- PR body: summary of changes, `Closes GRM-N`
+- Add `ready-to-merge` label **only after review is complete**
+
+### 6. Review the PR
+
+Review the full diff (`git diff master...HEAD`) focusing on:
+
+- **Functional completeness**: Does the code do what it claims? Are all requirements met?
+- **Edge cases**: Are boundary conditions, empty inputs, error paths handled?
+- **Technical excellence**:
+  - Architecture compliance and evolution
+  - Single Responsibility Principle (SRP)
+  - Deduplication (no copy-paste, single source of truth)
+  - Code smells detection and removal
+  - Best industry practices
+  - Industry-grade code quality
+  - Reusability
+  - Clean code
+  - Readability
+  - Maintainability
+  - Extensibility
+- **Performance**: No unnecessary allocations, O(n) vs O(n^2), efficient data structures
+- **Security**: No secrets in logs/process list, input validation, no injection vectors
+- **User experience**: Clear error messages, intuitive CLI flags, helpful output
+- **Documentation**: Completeness and relevance of docs, CHANGELOG entries, AGENTS.md updates
+
+Post review comments using `devx.ci.review_pr`:
+
+```bash
+REPO_TOKEN=<token> python -m devx.ci.review_pr <pr_number> <owner/repo> \
+  --event REQUEST_CHANGES \
+  --body "Review summary" \
+  --comments-json comments.json
+```
+
+### 7. Address review comments
+
+Fix each comment one by one, commit, and push. Re-review until satisfied.
+
+### 8. Approve and merge
+
+Once all comments are addressed, post an approval review:
+
+```bash
+REPO_TOKEN=<token> python -m devx.ci.review_pr <pr_number> <owner/repo> \
+  --event APPROVE --checklist-confirmed \
+  --checklist-categories 1,2,3,4,5,6,7,8,9,10,11,12,13 \
+  --body "All 13 REVIEW_CHECKLIST.md categories verified."
+```
+
+Then add the `ready-to-merge` label. The auto-merge workflow will:
+
+1. Validate PR title format and match against Vikunja task title
+2. Check that at least one APPROVE review exists
+3. Wait for all CI checks to pass
+4. Squash-merge with title: `GRM-N <conventional commit message>` (space-separated)
+5. The post-merge workflow marks the Vikunja task as done
+6. The release workflow automatically versions, tags, and publishes
+
+> **IMPORTANT**: Never manually merge PRs via the API. Always use the auto-merge workflow by adding the `ready-to-merge` label. Manual merges bypass the `GRM-N <conventional>` format enforcement.

 ### Branch Protection (Required Gitea Settings)

-Configure the following branch protection rules for `master` in Gitea repo settings:
+Branch protection is automatically configured by `devx.tools.configure_repo` (runs as a `configure-repo` job in the post-merge workflow). The following rules are enforced for `master`:

 - **Require pull request**: No direct pushes to master
 - **Require approval review**: At least 1 `APPROVE` review before merge
@@ -74,13 +183,14 @@ The auto-merge workflow enforces the APPROVE review check programmatically as a
 ## Build & Test Commands

 ```bash
-make setup          # Create venv, install deps, set up hooks
-make lint-all       # ruff + pyright + bandit + ansible-lint + checkmake
+make setup          # Create venv, install deps, set up hooks, install CI tools
+make lint-all       # ruff + pyright + bandit + ansible-lint + checkmake + actionlint
 make pytest-cov     # Unit tests with 100% coverage enforcement
 make test-unit      # Unit tests without coverage
 make molecule       # All 6 scenarios on Ubuntu 22.04
 make molecule-all   # All 6 scenarios on all 4 supported OSes
 make test-all       # pytest-cov + molecule
+make workflow-check # Static lint + dry-run of workflow YAML
 ```

 ## Ansible Role Conventions
@@ -93,6 +203,24 @@ main.yml → systemd_check → user_setup → rootless_docker → install_runner
 - `main.yml` handles: prune, integration_test (NOT install_runner — avoids duplicates)
 - `systemctl --user` tasks must be guarded by `docker_rootless_setup`
 - Template creation tasks are NOT guarded by `docker_rootless_setup` (they just create files)
+- `apt` tasks use `cache_valid_time: 3600` to avoid unnecessary cache updates
+- `remove-runner.yml` runs `loginctl disable-linger` and removes subuid/subgid entries
+
+## Change Classification
+
+Not all changes require a new release. The project classifies changes using `devx.ci.classify_changes`:
+
+**Workflow-only paths** (no release needed):
+- `.gitea/**`, `docs/**`, `tests/**`, `scripts/**`
+- `AGENTS.md`, `README.md`, `CHANGELOG.md`, `Makefile`, `cliff.toml`
+- Lint config files, `.env.example`, `.gitignore`
+
+**User-facing paths** (release needed):
+- `src/gitea_runner_manager/**` (except `__init__.py` and `api_clients.py`)
+- `ansible/**`
+- `pyproject.toml`
+
+When working on workflow/CI/docs-only changes, use `ci:` or `docs:` commit prefixes. Do NOT bump the version or create tags for workflow-only changes.

 ## Known Issues

@@ -22,7 +22,7 @@ Key technical decisions for the GRM project, extracted from `CHANGELOG.md` and `

 **Decision:** Each runner instance runs in an isolated rootless Docker environment under a dedicated system user (`grm-<name>`), with its own Docker socket at `/run/user/<UID>/docker.sock`.

-**Rationale:** Rootless Docker per-runner avoids conflicts with the host's Docker installation and enables true parallel execution of multiple runners on the same host. Each instance has fully isolated resources: user, home, data directory, config directory, systemd user service, and Docker socket. This is a core feature of GRM — enabling multiple isolated runners on the same host.
+**Rationale:** Rootless Docker per-runner avoids conflicts with the host's Docker installation and enables true parallel execution of multiple runners on the same host. Each instance has fully isolated resources: user, home, data directory, config directory, systemd user service, and Docker socket. This is a core feature of GRM — enabling multiple isolated runners on the same host. User namespace mapping is configured via `/etc/subuid` and `/etc/subgid` entries (range: 100000-165535). Lingering is enabled so the user's systemd services run without an active login session.

 **Source:** `README.md` (Architecture, Features), `AGENTS.md` (Architecture)

@@ -34,7 +34,7 @@ Key technical decisions for the GRM project, extracted from `CHANGELOG.md` and `

 **Decision:** Use conventional commits on feature branches and git-cliff (`cliff.toml`) to calculate the next semver version from commit history, generate the changelog, and automate releases.

-**Rationale:** `devx.ci.release` uses git-cliff to calculate the next version from conventional commits since the last tag. Merge commits on master have the format `GRM-N <conventional commit>`, so `cliff.toml` includes a `commit_preprocessors` entry that strips the `GRM-N ` prefix before parsing. Version bumping rules: `feat:` → minor, `fix:` → patch, `feat!:`/`BREAKING CHANGE` → minor (pre-1.0), `chore:`/`ci:`/`docs:` → no bump. This fully automates versioning and changelog generation.
+**Rationale:** `devx.ci.release` uses git-cliff to calculate the next version from conventional commits since the last tag. Merge commits on master have the format `GRM-N <conventional commit>`, so `cliff.toml` includes a `commit_preprocessors` entry that strips the `GRM-N ` prefix before parsing. Version bumping rules: `feat:` → minor, `fix:` → patch, `feat!:`/`BREAKING CHANGE` → minor (pre-1.0), `chore:`/`ci:`/`docs:` → no bump. This fully automates versioning and changelog generation — no manual version bumps are needed.

 **Source:** `CHANGELOG.md` (Unreleased — Added), `AGENTS.md` (Automated Release Pipeline, git-cliff Commit Preprocessing, Version Bumping Rules), `cliff.toml`

@@ -58,7 +58,7 @@ Key technical decisions for the GRM project, extracted from `CHANGELOG.md` and `

 **Decision:** Require branch protection on `master` (require pull request, require approval review, require status checks, block force pushes) and use an auto-merge workflow that programmatically enforces the APPROVE review check.

-**Rationale:** Branch protection is the primary gate — no direct pushes to master, at least 1 APPROVE review before merge, CI quality + molecule tests must pass, and no history rewriting. The auto-merge workflow (`devx.ci.auto_merge`) enforces the APPROVE review check programmatically as a defense-in-depth measure. When the `ready-to-merge` label is added, the workflow validates PR title format, checks for APPROVE review, waits for CI, and squash-merges with title `GRM-N <conventional commit message>`. The post-merge workflow then marks the Vikunja task as done.
+**Rationale:** Branch protection is the primary gate — no direct pushes to master, at least 1 APPROVE review before merge, CI quality + molecule tests must pass, and no history rewriting. The auto-merge workflow (`devx.ci.auto_merge`) enforces the APPROVE review check programmatically as a defense-in-depth measure. When the `ready-to-merge` label is added, the workflow validates PR title format, checks for APPROVE review, waits for CI, and squash-merges with title `GRM-N <conventional commit message>`. The post-merge workflow then marks the Vikunja task as done. Branch protection is automatically configured by `devx.tools.configure_repo`.

 **Source:** `CHANGELOG.md` (Unreleased — Added: mandatory PR review step, auto_merge.py), `AGENTS.md` (Branch Protection, PR Workflow step 8)

@@ -73,3 +73,51 @@ Key technical decisions for the GRM project, extracted from `CHANGELOG.md` and `
 **Rationale:** This prevents non-Ansible changes (e.g., Python scripts, workflow YAML, docs) from being blocked by molecule test infrastructure flakiness. Molecule tests are only relevant when Ansible files change. The `molecule-tests` job depends on both `quality` and `detect-changes`, and only runs if `ansible-changed == 'true'`. CI triggers only on `opened` and `synchronize` PR events (not `labeled`) to avoid redundant runs.

 **Source:** `AGENTS.md` (CI Path Filtering), `.gitea/workflows/ci.yml` (detect-changes job)
+
+---
+
+## ADR-007: Secrets via Temporary JSON Files (CWE-214)
+
+**Date:** Project inception
+
+**Decision:** Pass secrets (registration tokens, admin API tokens) to Ansible via temporary JSON files with `0600` permissions, never on the command line.
+
+**Rationale:** Passing secrets as command-line arguments (e.g., `--extra-vars '{"token": "..."}'`) makes them visible in the process list (`ps aux`), which is a known security weakness (CWE-214). The `RunnerManager._extra_vars_file()` context manager writes extra-vars to a temporary file via `tempfile.mkstemp()`, sets permissions to `0600`, passes the file to Ansible via `--extra-vars @tempfile`, and deletes the file in a `finally` block — even if an exception occurs. This ensures secrets are never visible in the process list.
+
+**Source:** `AGENTS.md` (Key Conventions), `src/gitea_runner_manager/runner_manager.py` (`_extra_vars_file` method)
+
+---
+
+## ADR-008: Smart CI — User-Facing vs Workflow-Only Change Classification
+
+**Date:** 2026-06-21 (v0.2.0 unreleased)
+
+**Decision:** Classify changed files into user-facing and workflow-only categories using `devx.ci.classify_changes`. Only user-facing changes trigger a release; workflow-only changes (CI, docs, tests, lint config) do not.
+
+**Rationale:** Not all changes require a new release. CI workflow updates, documentation improvements, and test additions should not produce a new version tag. The classification is config-driven via `[tool.devx.classify]` in `pyproject.toml`. The strategy is safe-by-default: any file NOT in the explicit workflow-only allowlist is treated as user-facing, preventing new file types from accidentally skipping releases. User-facing paths include `src/gitea_runner_manager/**` (except `__init__.py` and `api_clients.py`) and `ansible/**`. Workflow-only paths include `.gitea/**`, `docs/**`, `tests/**`, `scripts/**`, and various config files.
+
+**Source:** `AGENTS.md` (Smart CI: User-Facing vs Workflow-Only Changes), `pyproject.toml` (`[tool.devx.classify]`)
+
+---
+
+## ADR-009: devx Package Separation
+
+**Date:** 2026-06-21 (v0.6.2)
+
+**Decision:** Separate CI/CD and development tooling into the `devx` package (installed from git), keeping the GRM tool itself self-contained in `src/gitea_runner_manager/`.
+
+**Rationale:** The GRM CLI tool must be self-contained — it never imports from devx. This ensures the installed package has no dependency on CI infrastructure. devx MAY import from `gitea_runner_manager` (one-way dependency), as it uses the tool's API clients, config, and i18n for CI automation. Cross-module imports within devx are allowed. This separation was formalised when scripts were migrated from the `scripts/` directory to the devx package in GRM-64.
+
+**Source:** `AGENTS.md` (Source Code Separation and devx Integration), `CHANGELOG.md` (0.6.2 — Refactor: "Migrate from scripts/ to devx package")
+
+---
+
+## ADR-010: Dynamic Runner Discovery for Molecule CI
+
+**Date:** 2026-06-21 (v0.5.0+)
+
+**Decision:** Molecule tests are distributed across available Gitea Actions runners dynamically via `devx.molecule.discover_runners`, which queries the Gitea API for runners at all levels (repo, org, instance) and generates a dynamic matrix.
+
+**Rationale:** Hardcoding the number of CI runners would require manual updates when runners are added or removed. Dynamic discovery auto-detects repo/org-level runners via the API. For instance-level runners (which may not be visible without admin scope), it falls back to the `MOLECULE_RUNNERS` repo variable, then to a default of 3. The workflow automatically scales the matrix to match available runners, distributing test pairs evenly.
+
+**Source:** `AGENTS.md` (Dynamic Runner Discovery), `.gitea/workflows/ci.yml` (discover-runners job)
@@ -10,13 +10,19 @@
 │   ├── executor.py                # Ansible subprocess execution
 │   ├── registry.py                # Local JSON runner registry
 │   ├── i18n.py                    # Translations (en, bg, de, ru, zh)
-│   └── exceptions.py              # Custom exceptions
+│   ├── exceptions.py              # Custom exceptions
+│   ├── config.py                  # Configuration constants
+│   ├── logging_config.py          # Logging to ~/.local/state/grm/logs/
+│   ├── report.py                  # Operation report tracking
+│   ├── ui.py                      # Colorised console output
+│   ├── api_clients.py             # Gitea/Vikunja API clients (for CI scripts)
+│   └── translations.json          # Translation strings
 ├── ansible/
 │   ├── roles/gitea-runner/        # Main Ansible role
 │   │   ├── defaults/main.yml      # Default variables
-│   │   ├── tasks/                 # Task files
-│   │   ├── templates/             # Jinja2 templates
-│   │   └── molecule/              # Test scenarios
+│   │   ├── tasks/                 # Task files (13 files)
+│   │   ├── templates/             # Jinja2 templates (4 files)
+│   │   └── molecule/              # Test scenarios (7 scenarios)
 │   ├── install-runner.yml         # Install playbook
 │   ├── update-runner.yml          # Update playbook
 │   ├── start-runner.yml           # Start playbook
@@ -28,38 +34,68 @@
 ├── tests/
 │   ├── unit/                      # Unit tests
 │   └── integration/               # Integration tests
+├── .gitea/workflows/              # CI/CD workflows
+├── docs/                          # Documentation (synced to wiki)
 ├── Makefile                       # Build & test automation
-└── pyproject.toml                # Python project metadata
+├── pyproject.toml                 # Python project metadata
+├── cliff.toml                     # git-cliff configuration
+└── .env.example                   # Environment variable template
 ```

+## Prerequisites
+
+- **Python 3.12+** — Required. The Makefile verifies this before creating the venv. Use `pyenv` to manage Python versions if needed.
+- **Git** — For cloning the repository and checking out release tags.
+- **Docker** — Only needed for running Molecule tests locally (`make molecule`).
+- **Go** — Only needed if you want to install `checkmake` manually (alternatively, `make setup` installs it via `devx.tools.install_checkmake`).
+
 ## Setup Development Environment

+### Step 1: Clone and checkout latest release
+
 ```bash
-make setup        # Creates venv, installs deps, sets up hooks
+git clone https://git.oblachno.oblachno.fyi/oblachno-oss/grm.git
+cd grm
+git checkout $(git describe --tags --abbrev=0)  # Checkout latest stable release
+```
+
+> **Important:** Always checkout the latest release tag before running `make setup`. The `master` branch may contain unreleased changes that are not yet stable. To see all available releases, run `git tag --sort=-version:refname` or check the [releases page](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases).
+
+### Step 2: Ensure Python 3.12+ is available
+
+If you use pyenv:
+
+```bash
+pyenv install 3.12
+pyenv local 3.12
+```
+
+Verify your Python version:
+
+```bash
+python3 --version  # Must be 3.12 or higher
+```
+
+### Step 3: Run make setup
+
+```bash
+make setup
 source .venv/bin/activate
 ```

-The `make setup` target (from the `Makefile`):
+The `make setup` target performs the following:

- Verifies Python 3.12+ is installed
- Creates a virtualenv in `.venv`
- Installs/updates `pip`, `setuptools`, and `wheel`
- Creates `.env` from `.env.example` if not present
- Generates shell activation scripts (`activate.sh`, `activate.fish`, `activate.zsh`)
- Installs `checkmake` via `devx.tools.install_checkmake`
- Runs `python -m devx.tools.setup` to install dependencies and hooks
+1. Verifies Python 3.12+ is installed
+2. Creates a virtualenv in `.venv`
+3. Installs/updates `pip`, `setuptools`, and `wheel`
+4. Creates `.env` from `.env.example` if not present
+5. Generates shell activation scripts (`activate.sh`, `activate.fish`, `activate.zsh`)
+6. Installs the `devx` package from the Oblachno PyPI registry (provides CI/CD tools)
+7. Installs `checkmake` via `devx.tools.install_checkmake` (Makefile linter)
+8. Installs CI/CD tools via `devx.tools.install_tools` (actionlint, git-cliff, act_runner, tea) to `~/.local/bin`
+9. Runs `python -m devx.tools.setup` to install Python dependencies, Ansible Galaxy collections, pre-commit hooks, and configure tea CLI login

-### Developer Quick Start
-
-```bash
-git clone https://git.oblachno.oblachno.com/oblachno/gitea-runner-manager.git
-cd gitea-runner-manager
-pyenv install 3.12
-pyenv local 3.12
-make setup
-```
-
-### Configure Gitea Credentials
+### Step 4: Configure Gitea credentials

 ```bash
 cp .env.example .env
@@ -70,28 +106,49 @@ cp .env.example .env

 `GITEA_REGISTRATION_TOKEN` is the runner registration token obtained from your Gitea instance (Admin → Actions → Runners → Create Registration Token).

-#### Admin API Token (optional)
+#### Admin API token (optional)

-Set `GITEA_ADMIN_TOKEN` to enable informational API checks during integration test. This is **optional** — the test primarily verifies the runner by checking:
+Set `REPO_TOKEN` to enable informational API checks during integration test. This is **optional** — the test primarily verifies the runner by checking:

 1. **`.runner` registration file** exists and contains valid JSON (proves successful registration)
 2. **Systemd user service** is active (proves daemon is polling for jobs)

 API checks, if enabled, are purely informational and do not affect pass/fail.

+### Step 5: Verify the setup
+
+```bash
+grm --version          # Should print the version
+make lint-all          # Should pass with no errors
+make pytest-cov        # Should pass with 100% coverage
+```
+
+## Shell activation scripts
+
+`make setup` generates convenience activation scripts for different shells:
+
+```bash
+source activate.sh     # bash
+source activate.fish   # fish
+source activate.zsh    # zsh
+```
+
+These scripts activate the `.venv` virtualenv from the project root.
+
 ## Running Linters

 ```bash
-make lint          # Python (ruff + pyright + bandit)
+make lint          # Python (ruff + format check + pyright + bandit)
 make lint-bandit   # Security scan only
 make ansible-lint  # Ansible
 make makefile-lint # Makefile
+make workflow-lint # Gitea Actions workflows (actionlint)
 ```

 The full lint target (`make lint-all`) runs all of the above:

 ```bash
-make lint-all       # ruff + pyright + bandit + ansible-lint + checkmake
+make lint-all       # ruff + pyright + bandit + ansible-lint + checkmake + actionlint
 ```

 Individual lint targets from the `Makefile`:
@@ -102,7 +159,84 @@ Individual lint targets from the `Makefile`:
 | `lint-format` | `ruff format --check src/ tests/` |
 | `typecheck` | `pyright` |
 | `lint-bandit` | `bandit -r src/` |
+| `lint-deps` | `pip-audit` — checks dependencies for known vulnerabilities |
 | `ansible-lint` | `ansible-lint ansible/` |
 | `makefile-lint` | `checkmake Makefile` |
 | `lint` | ruff + format check + pyright + bandit |
-| `lint-all` | lint + ansible-lint + makefile-lint |
+| `lint-all` | lint + ansible-lint + makefile-lint + workflow-lint |
+
+## Running Tests
+
+### Unit tests
+
+```bash
+make test-unit      # Without coverage
+make pytest-cov     # With 100% coverage enforcement
+```
+
+The coverage requirement is `--cov-fail-under=100` — 100% test coverage is required for all code in `src/gitea_runner_manager/`.
+
+### Integration tests
+
+```bash
+make test-integration
+```
+
+Tests the full CLI lifecycle commands end-to-end (mocked executor boundary).
+
+### Molecule tests
+
+```bash
+make molecule      # Quick: all 6 scenarios on Ubuntu 22.04
+make molecule-all  # Full: all 6 scenarios on all 4 supported OSes
+```
+
+Requires Docker to be installed and running on your machine. Molecule creates Docker containers as test hosts, applies the Ansible role, and verifies the results.
+
+### Full test suite
+
+```bash
+make test-all      # pytest-cov + molecule
+```
+
+## Workflow verification
+
+GRM includes Gitea Actions workflow files in `.gitea/workflows/`. These are verified with two tools:
+
+```bash
+make workflow-lint     # Static lint via actionlint
+make workflow-dryrun   # Dry-run via act_runner exec --dryrun
+make workflow-check    # Both of the above
+```
+
+The pre-commit hook runs actionlint automatically when workflow files change.
+
+## Pre-commit hooks
+
+`make setup` installs pre-commit hooks that run:
+
+- **pre-commit**: `ruff check`, `ruff format --check`, conventional commit message validation
+- **pre-push**: `make pytest-cov` (ensures tests pass before pushing)
+
+## Make targets reference
+
+| Target | Description |
+|--------|-------------|
+| `make setup` | Full setup: venv, deps, hooks, CI tools |
+| `make setup-ci` | Lean setup for CI jobs (pytest + lint, no Ansible collections) |
+| `make setup-quality` | Setup for the quality CI job (lint + test deps) |
+| `make setup-molecule` | Full setup for molecule testing |
+| `make setup-release` | Setup for release jobs (git-cliff, tea, lint tools) |
+| `make install-tools` | Install actionlint, git-cliff, act_runner, tea to `~/.local/bin` |
+| `make install-devx` | Install the devx package from the Oblachno PyPI registry |
+| `make lint-all` | ruff + pyright + bandit + ansible-lint + checkmake + actionlint |
+| `make pytest-cov` | Unit tests with 100% coverage enforcement |
+| `make test-unit` | Unit tests without coverage |
+| `make test-integration` | Integration tests |
+| `make molecule` | All 6 Molecule scenarios on Ubuntu 22.04 |
+| `make molecule-all` | All 6 scenarios on all 4 supported OSes |
+| `make test-all` | pytest-cov + molecule |
+| `make workflow-lint` | Static lint of workflow YAML (actionlint) |
+| `make workflow-dryrun` | Dry-run all workflows in Docker |
+| `make workflow-check` | workflow-lint + workflow-dryrun |
+| `make clean` | Remove `__pycache__`, `.pyc`, `.coverage`, `htmlcov/`, `.molecule/` |
@@ -1,9 +1,12 @@
 # Testing Strategy

+GRM employs a multi-layered testing strategy: unit tests with 100% coverage enforcement, integration tests for the CLI lifecycle, and Molecule scenarios for Ansible role validation across multiple OS platforms.
+
 ## Unit Tests

 ```bash
-make test-unit
+make test-unit      # Without coverage
+make pytest-cov     # With 100% coverage enforcement
 ```

 Runs pytest with 100% coverage requirement.
@@ -11,9 +14,27 @@ Runs pytest with 100% coverage requirement.
 From the `Makefile`:

 - `test-unit` — `pytest tests/unit/ -v --no-cov` (unit tests without coverage)
- `pytest-cov` — `pytest tests/unit/ -v --cov=src/gitea_runner_manager --cov=scripts --cov-report=term-missing --cov-fail-under=100` (unit tests with 100% coverage enforcement)
+- `pytest-cov` — `pytest tests/ -v --cov=src/gitea_runner_manager --cov-report=term-missing --cov-fail-under=100` (unit tests with 100% coverage enforcement)

-The coverage requirement is `--cov-fail-under=100` — 100% test coverage is required.
+The coverage requirement is `--cov-fail-under=100` — 100% test coverage is required for all code in `src/gitea_runner_manager/`. The CI quality job runs `make pytest-cov` on every PR, and the release workflow runs it again before tagging a release.
+
+### Test speed verification
+
+The CI quality job also runs `python -m devx.tools.check_test_speed --max-seconds 10` to verify that unit tests run fast (under 10 seconds total). This catches performance regressions early.
+
+## Integration Tests
+
+```bash
+make test-integration
+```
+
+Tests the full CLI lifecycle commands end-to-end with a mocked executor boundary. This verifies that the CLI correctly parses arguments, resolves runners from the registry, constructs the right Ansible commands, and handles errors — all without actually connecting to remote hosts.
+
+From the `Makefile`:
+
+- `test-integration` — `pytest tests/integration/ -v --no-cov`
+
+Integration tests are marked with `@pytest.mark.integration` and are not counted toward coverage.

 ## Molecule Tests

@@ -22,60 +43,80 @@ make molecule      # Quick: all 6 scenarios on Ubuntu 22.04
 make molecule-all  # Full: all 6 scenarios on all 4 supported OSes
 ```

-Runs six scenarios:
+Molecule tests validate the Ansible role (`ansible/roles/gitea-runner/`) by creating Docker containers as test hosts, applying the role, and verifying the results. Each scenario tests a specific aspect of the role.

- **default** — Rootless Docker runner installation
- **multi-instance** — Two isolated runner instances on the same host
- **lifecycle** — Stop, disable, re-enable, and start sequence
- **template-content** — Verify rendered systemd user service and prune templates
- **deregister** — Runner deregistration
- **update** — Runner binary update
+### Scenarios

-All scenarios test idempotence (second run produces zero changes).
+Seven Molecule scenarios are defined under `ansible/roles/gitea-runner/molecule/`:
+
+| Scenario | Description | What it verifies |
+|----------|-------------|------------------|
+| `default` | Rootless Docker runner installation | Basic role convergence — user creation, directory structure, binary download, config file, systemd service template, prune timer templates |
+| `multi-instance` | Two isolated runner instances on the same host | Two separate converge plays with different runner names; verifies both instances coexist with independent users, data directories, and service files |
+| `lifecycle` | Stop, disable, re-enable, and start sequence | Converge, then side_effect stops and disables the service, then re-enables and starts it; verify confirms the service is active again |
+| `template-content` | Verify rendered systemd and prune templates | Checks that the systemd user service file contains expected directives (`Type=simple`, `ExecStart`, `Restart=on-failure`, `DOCKER_HOST`, `XDG_RUNTIME_DIR`), and that the prune service and timer templates are correctly rendered |
+| `deregister` | Runner deregistration | Creates a fake `.runner` file, then runs the deregister tasks; verifies the `.runner` file is removed |
+| `update` | Runner binary update | Converge, then side_effect runs the update playbook; verifies the binary is updated |
+| `remove` | Runner removal | Converge, then side_effect runs the remove playbook; verifies the user, directories, and service files are cleaned up |
+
+All scenarios test idempotence (second run produces zero changes), which is a core requirement of the Ansible role.
+
+### Common scenario configuration
+
+All scenarios use `docker_rootless_setup: false` and `skip_runner_registration: true` in their converge playbooks. This is because:
+
+- **Rootless Docker** requires kernel user namespace support, which is not available in all Docker-in-Docker CI environments. The role handles this gracefully via the `docker_rootless_setup` guard.
+- **Runner registration** requires a real Gitea instance. The role handles this via the `skip_runner_registration` flag, which skips the `register.yml` and `integration_test.yml` tasks.

 ### Platforms

-4 platforms are tested: `ubuntu-2204`, `ubuntu-2404`, `debian-12`, `archlinux`.
+4 platforms are tested:

-The platform list is defined in `devx.molecule.distribute_molecule` (single source of truth).
+| Platform | Docker image |
+|----------|-------------|
+| `ubuntu-2204` | `geerlingguy/docker-ubuntu2204-ansible` |
+| `ubuntu-2404` | `geerlingguy/docker-ubuntu2404-ansible` |
+| `debian-12` | `geerlingguy/docker-debian12-ansible` |
+| `archlinux` | `archlinux:latest` |
+
+The platform list is defined in `devx.molecule.platforms` (single source of truth), shared between `devx.molecule.distribute_molecule` (CI) and `devx.molecule.molecule_all` (local dev tool).

 ### CI Test Distribution

-CI runs all 6 scenarios × 4 platforms (24 test pairs) distributed across 3 parallel runners.
+CI runs all 6 scenarios x 4 platforms (24 test pairs) distributed across available Gitea Actions runners.

-From `.gitea/workflows/ci.yml`, the `molecule-tests` job uses a matrix of `runner-index: [0, 1, 2]` and calls `python -m devx.molecule.distribute_molecule --runner-index <index> --max-runners 3` to discover assigned test pairs, then runs `python -m devx.molecule.molecule_ci_guard` with those pairs.
+The `discover-runners` job runs `devx.molecule.discover_runners` which queries the Gitea API for registered runners at three levels (repo, org, instance) and generates a dynamic matrix. If the API query fails (e.g., no admin access for instance-level runners), it falls back to the `MOLECULE_RUNNERS` repo variable, then to a default of 3.

-## Integration Tests
+The `molecule-tests` job uses `fromJSON()` to consume the dynamic matrix, and passes the runner count to `python -m devx.molecule.distribute_molecule --max-runners` so test pairs are evenly distributed.

-```bash
-make test-integration
-```
+`devx.molecule.distribute_molecule` discovers all molecule scenarios under `ansible/roles/*/molecule/` and crosses them with the supported OS platform matrix, then splits the resulting test pairs evenly across the requested number of runners. Each pair is encoded as `scenario|platform_name|platform_image|platform_command`.

-Tests the full CLI lifecycle commands end-to-end (mocked executor boundary).
+`devx.molecule.molecule_ci_guard` runs the actual molecule test for a given test pair, with CI context (Gitea URL, token, run ID) for reporting results back to the commit status API.

-From the `Makefile`:
+### Path-based CI filtering

- `test-integration` — `pytest tests/integration/ -v --no-cov`
+The CI workflow includes a `detect-changes` job that checks whether any files under `ansible/` or `.ansible-lint` have changed. If no Ansible files are changed, molecule tests are skipped — this prevents non-Ansible changes (e.g., Python scripts, workflow YAML, docs) from being blocked by molecule test infrastructure flakiness.

 ## Full Test Suite

 ```bash
-make test-all      # Runs unit tests + linters + molecule
+make test-all      # Runs pytest-cov + molecule (Ubuntu 22.04)
 ```

 From the `Makefile`:

 - `test-all` — `pytest-cov + molecule` (unit tests with coverage + all 6 molecule scenarios on Ubuntu 22.04)

+For a complete test across all platforms, use `make molecule-all` separately.
+
 ## Build & Test Commands Summary

-From `AGENTS.md`:
-
 ```bash
-make setup          # Create venv, install deps, set up hooks
-make lint-all       # ruff + pyright + bandit + ansible-lint + checkmake
+make setup          # Create venv, install deps, set up hooks, install CI tools
+make lint-all       # ruff + pyright + bandit + ansible-lint + checkmake + actionlint
 make pytest-cov     # Unit tests with 100% coverage enforcement
 make test-unit      # Unit tests without coverage
+make test-integration # Integration tests
 make molecule       # All 6 scenarios on Ubuntu 22.04
 make molecule-all   # All 6 scenarios on all 4 supported OSes
 make test-all       # pytest-cov + molecule
@@ -2,6 +2,32 @@

 GRM provides the following CLI commands for managing Gitea Actions runners. The base command is `grm`.

+## Command Summary
+
+| Command | Arguments | Description |
+|---------|-----------|-------------|
+| `grm install` | `<host>` | Install and configure a runner on a remote host |
+| `grm update` | `<host>` | Update the gitea_runner binary on a remote host |
+| `grm start` | `<runner_name>` | Start a registered runner |
+| `grm stop` | `<runner_name>` | Stop a registered runner |
+| `grm enable` | `<runner_name>` | Enable a runner to start on boot |
+| `grm disable` | `<runner_name>` | Disable and deregister a runner |
+| `grm status` | `<runner_name>` | Check the status of a registered runner |
+| `grm remove` | `<runner_name>` | Remove a runner completely |
+| `grm list` | — | List all registered runners with live status |
+| `grm --version` | — | Show the installed version |
+
+### Common lifecycle options
+
+The `start`, `stop`, `enable`, `status`, `disable`, and `remove` commands all accept these override options. By default, connection details are read from the local registry (`~/.local/share/grm/runners.json`).
+
+| Option | Short | Description |
+|--------|-------|-------------|
+| `--host` | — | Override host from registry |
+| `--user` | `-u` | Override user from registry |
+| `--key` | `-k` | Override SSH key from registry |
+| `--ask-become-pass/--no-ask-become-pass` | — | Prompt for sudo password (default) or skip it |
+
 ## install

 Install and configure a Gitea Runner on a remote host.
@@ -231,3 +257,47 @@ grm list
 ```

 This command takes no arguments or options. It displays a table with columns: NAME, HOST, USER, LABELS, STATUS for all runners stored in the local registry at `~/.local/share/grm/runners.json`.
+
+The status is checked live by running an Ansible ad-hoc command on each remote host (`systemctl --user is-active gitea-runner`). Possible status values: `active`, `inactive`, `failed`, `unknown`.
+
+**Example output:**
+
+```
+NAME              HOST            USER       LABELS                         STATUS
+------------------------------------------------------------------------------------------
+prod-runner       192.168.1.10    ubuntu     docker:docker://gitea/...      active
+build-runner      192.168.1.10    ubuntu     docker:docker://gitea/...      active
+test-runner       192.168.1.20    ubuntu                                    inactive
+```
+
+If no runners are registered:
+
+```
+No runners registered. Use 'grm install' to add one.
+```
+
+## --version
+
+Show the installed GRM version.
+
+```bash
+grm --version
+```
+
+This reports the version from `__version__` in `src/gitea_runner_manager/__init__.py`, which is the single source of truth set by the automated release pipeline.
+
+## Environment Variables
+
+All CLI options can be set via environment variables (loaded from `.env` via python-dotenv). Command-line flags take precedence over environment variables.
+
+| Variable | Used by | Description |
+|----------|---------|-------------|
+| `GITEA_URL` | `install`, `disable`, `remove` | Gitea instance URL |
+| `GITEA_REGISTRATION_TOKEN` | `install`, `disable`, `remove` | Runner registration token |
+| `REPO_TOKEN` | `install` | Admin API token for integration test |
+| `GITEA_INTEGRATION_RETRIES` | `install` | API check retries (default: 3) |
+| `GITEA_RUNNER_USER` | `install`, `update` | Default SSH user |
+| `GITEA_RUNNER_KEY` | `install`, `update` | Default SSH key path |
+| `GITEA_RUNNER_LABELS` | `install` | Default runner labels |
+| `GRM_LANG` | all | UI language: `en`, `bg`, `de`, `ru`, `zh` |
+| `GRM_LOG_LEVEL` | all | Console log level: `DEBUG`, `INFO`, `WARNING`, `ERROR`, `CRITICAL` |
@@ -22,18 +22,152 @@ If you skip it, GRM will still verify the runner correctly — it just won't sho

 Configure passwordless sudo on the remote host and pass `--no-ask-become-pass` to the CLI command. This is recommended for CI/CD pipelines.

+On the remote host, add a sudoers entry:
+
+```bash
+echo "ubuntu ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/grm
+```
+
+Then use:
+
+```bash
+grm install 192.168.1.10 --user ubuntu --key ~/.ssh/id_ed25519 --name prod-runner --no-ask-become-pass
+```
+
 ### Can I run multiple runners on the same host?

 Yes. Each runner instance is fully isolated with its own system user (`grm-<name>`), rootless Docker daemon, data directory, and systemd user service. Install additional runners with different `--name` values and manage them independently by name.

+```bash
+grm install 192.168.1.10 --user ubuntu --name workflow-runner
+grm install 192.168.1.10 --user ubuntu --name build-runner
+grm list
+```
+
+Runners on the same host never interfere with each other or with the host's Docker installation.
+
 ### Why does my runner appear offline after installation?

 Check that `GITEA_URL` and `GITEA_REGISTRATION_TOKEN` are correct, verify the runner service is running with `sudo -u grm-<name> systemctl --user status gitea-runner`, and check the logs for registration errors. You can also confirm the runner appears as **Online** in the Gitea UI under **Actions → Runners**.

+Common causes:
+- Registration token expired — generate a new one from Gitea
+- Network connectivity issue between the runner host and Gitea
+- Rootless Docker daemon not running — check `sudo -u grm-<name> systemctl --user status docker`
+- Lingering not enabled — check `loginctl show-user grm-<name> | grep Linger`
+
 ### What does the "Event loop is closed" warning mean?

 This is a harmless cleanup traceback from Molecule's Docker driver when the test process is interrupted. It does not indicate a test failure.

 ### Where are runner connection details stored?

-GRM stores each runner's connection details (host, user, SSH key, Gitea URL) in a local JSON registry at `~/.local/share/grm/runners.json`. After installation, lifecycle commands work by runner name only — you can override any stored value by passing the corresponding flag.
+GRM stores each runner's connection details (host, user, SSH key, Gitea URL, labels) in a local JSON registry at `~/.local/share/grm/runners.json`. After installation, lifecycle commands work by runner name only — you can override any stored value by passing the corresponding flag.
+
+### How do I update the gitea_runner binary?
+
+Use the `grm update` command:
+
+```bash
+grm update 192.168.1.10 --user ubuntu
+```
+
+To update to a specific version:
+
+```bash
+grm update 192.168.1.10 --user ubuntu --version 1.0.8
+```
+
+The update command downloads the new binary and replaces the existing one at `/usr/local/bin/gitea_runner`. The runner service is restarted automatically.
+
+### How do I completely remove a runner?
+
+Use the `grm remove` command:
+
+```bash
+grm remove prod-runner --token <registration-token>
+```
+
+This deregisters the runner from Gitea, stops and disables the systemd service, removes the system user, deletes data and config directories, removes subuid/subgid entries, disables lingering, and removes the entry from the local registry.
+
+If the remote host is already gone or unreachable, use `--force` to skip remote cleanup and only remove the local registry entry:
+
+```bash
+grm remove prod-runner --force
+```
+
+### What is the difference between disable and remove?
+
+- **`grm disable <name>`** — Deregisters the runner from Gitea and stops the service, but leaves the user, directories, and service files in place. The runner can be re-enabled later with `grm enable` and re-registered with a new token.
+- **`grm remove <name>`** — Completely removes the runner: deregisters from Gitea, stops and disables the service, removes the system user, deletes all directories, and removes the local registry entry. This is irreversible.
+
+### What operating systems are supported?
+
+GRM supports Arch Linux (rolling), Ubuntu 22.04/24.04, and Debian 12. All supported OSes are tested in CI via Molecule scenarios on every PR that changes Ansible files.
+
+### How do I change the UI language?
+
+Set the `GRM_LANG` environment variable to one of the supported languages: `en` (English, default), `bg` (Bulgarian), `de` (German), `ru` (Russian), `zh` (Chinese).
+
+```bash
+GRM_LANG=bg grm install 192.168.1.10 --user ubuntu --name prod-runner
+```
+
+Or set it in your `.env` file:
+
+```bash
+GRM_LANG=bg
+```
+
+### How do I enable debug logging?
+
+Set the `GRM_LOG_LEVEL` environment variable to `DEBUG`:
+
+```bash
+GRM_LOG_LEVEL=DEBUG grm install 192.168.1.10 --user ubuntu --name prod-runner
+```
+
+The log file at `~/.local/state/grm/logs/grm.log` always captures DEBUG level regardless of this setting. Ansible execution logs are stored in timestamped files at `~/.local/state/grm/logs/ansible-<timestamp>.log`.
+
+### What runner labels should I use?
+
+By default, runners are registered with `docker,ubuntu-latest:docker://runner-images:ubuntu-22.04`. You can override this with `--labels` or the `GITEA_RUNNER_LABELS` environment variable.
+
+Use an official Gitea runner image with Node.js, Python, and Docker CLI. Avoid bare OS images like `alpine:latest` because `actions/checkout@v4` needs Node.js.
+
+Example:
+
+```bash
+grm install 192.168.1.10 --user ubuntu --name prod-runner \
+  --labels "docker:docker://gitea/runner-images:ubuntu-latest"
+```
+
+### Is GRM secure?
+
+Yes. GRM is designed with security as a first-class concern:
+
+- **Rootless Docker**: Each runner operates under a dedicated unprivileged system user. Containers never have root access to the host.
+- **Secret handling**: Registration tokens are passed via temporary JSON files with `0600` permissions, never on the command line (CWE-214).
+- **No shell injection**: The CLI never uses `shell=True` with subprocess.
+- **Bandit security scan**: The CI pipeline runs Bandit on every PR.
+
+### Can I install GRM via pip?
+
+Yes:
+
+```bash
+pip install gitea-runner-manager
+```
+
+This installs the `grm` CLI and its Python dependencies. The Ansible playbooks and role are bundled with the package. For development or access to Make targets, clone the repository instead.
+
+### How does GRM handle idempotence?
+
+The Ansible role is idempotent — running `grm install` twice produces zero changes on the second run. Each task checks for existing state before making changes. For example:
+
+- User creation uses `ansible.builtin.user` which only creates if the user doesn't exist
+- Package installation uses `state: present` which only installs if not already installed
+- Template creation uses `ansible.builtin.template` which only writes if the content changed
+- Rootless Docker setup uses `creates:` to skip if already configured
+
+This makes GRM safe for CI/CD pipelines and configuration management.
@@ -1,23 +1,44 @@
 # Getting Started

-## Developer Setup
+This guide walks you through setting up GRM, configuring Gitea credentials, and installing your first runner.
+
+## Prerequisites
+
+Before you begin, ensure you have:
+
+- **Python 3.12+** on your local machine
+- **SSH access** to the target host(s) where runners will be installed
+- **Sudo privileges** on the target host(s) for the SSH user
+- **A Gitea instance** with admin access to create registration tokens
+- **Git** for cloning the repository
+
+## Step 1: Clone and Setup

 ```bash
 git clone https://git.oblachno.oblachno.fyi/oblachno-oss/grm.git
 cd grm
 git checkout $(git describe --tags --abbrev=0)  # Checkout latest stable release
+make setup
+source .venv/bin/activate
+```
+
+> **Important:** Always checkout the latest release tag before running `make setup`. The `master` branch may contain unreleased changes that are not yet stable. The `git describe --tags --abbrev=0` command automatically selects the most recent tagged release. To see all available releases, run `git tag --sort=-version:refname` or check the [releases page](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases).
+
+`make setup` creates a virtualenv, installs all dependencies (including Ansible), creates `.env` from `.env.example`, and sets up pre-commit hooks.
+
+If you use pyenv for Python version management:
+
+```bash
 pyenv install 3.12
 pyenv local 3.12
 make setup
 ```

-> **Important:** Always checkout the latest release tag before running `make setup`. The `master` branch may contain unreleased changes that are not yet stable. The `git describe --tags --abbrev=0` command automatically selects the most recent tagged release. To see all available releases, run `git tag --sort=-version:refname` or check the [releases page](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases).
-
-## Configure Gitea Credentials
+## Step 2: Configure Gitea Credentials

 GRM needs two tokens from your Gitea instance: a **registration token** (required) and an **admin API token** (optional, for post-install verification).

-### Step 1: Get the Registration Token
+### Get the Registration Token

 The registration token tells Gitea to accept the runner when it connects.

@@ -33,7 +54,7 @@ The registration token tells Gitea to accept the runner when it connects.
 >
 > Use instance-level tokens for shared runners, and repo-level tokens for dedicated runners.

-### Step 2: Get the Admin API Token (optional)
+### Get the Admin API Token (optional)

 The admin API token enables post-install API checks that verify the runner appears in Gitea's runner list. This is purely informational — the integration test primarily verifies the runner by checking:

@@ -47,7 +68,7 @@ To get an admin API token:
 3. Select the **admin** scope (or at minimum: `read:user`, `read:repository`, `read:admin`)
 4. Click **Generate Token** and copy it immediately (it won't be shown again)

-### Step 3: Create the `.env` File
+### Create the `.env` File

 ```bash
 cp .env.example .env
@@ -68,18 +89,19 @@ REPO_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

 ### Environment Variables Reference

-| Variable | Required | Description |
-|----------|----------|-------------|
-| `GITEA_URL` | Yes | Gitea instance URL (e.g., `https://git.example.com`) |
-| `GITEA_REGISTRATION_TOKEN` | Yes | Runner registration token from Gitea admin panel |
-| `REPO_TOKEN` | No | Admin API token for post-install verification |
-| `GITEA_INTEGRATION_RETRIES` | No | API check retries (default: 3) |
-| `GITEA_RUNNER_USER` | No | Default SSH user (overrides `--user`) |
-| `GITEA_RUNNER_KEY` | No | Default SSH key path (overrides `--key`) |
-| `GITEA_RUNNER_LABELS` | No | Default runner labels (overrides `--labels`) |
-| `GRM_LANG` | No | UI language: `en`, `bg`, `de`, `ru`, `zh` (default: `en`) |
+| Variable | Required | Default | Description |
+|----------|----------|---------|-------------|
+| `GITEA_URL` | Yes | — | Gitea instance URL (e.g., `https://git.example.com`) |
+| `GITEA_REGISTRATION_TOKEN` | Yes | — | Runner registration token from Gitea admin panel |
+| `REPO_TOKEN` | No | — | Admin API token for post-install verification |
+| `GITEA_INTEGRATION_RETRIES` | No | `3` | API check retries (default: 3) |
+| `GITEA_RUNNER_USER` | No | current login | Default SSH user (overrides `--user`) |
+| `GITEA_RUNNER_KEY` | No | — | Default SSH key path (overrides `--key`) |
+| `GITEA_RUNNER_LABELS` | No | — | Default runner labels (overrides `--labels`) |
+| `GRM_LANG` | No | `en` | UI language: `en`, `bg`, `de`, `ru`, `zh` |
+| `GRM_LOG_LEVEL` | No | `INFO` | Console log level: `DEBUG`, `INFO`, `WARNING`, `ERROR`, `CRITICAL` |

-## Install a Runner
+## Step 3: Install Your First Runner

 Using the CLI (you will be prompted for the sudo password by default):

@@ -87,6 +109,19 @@ Using the CLI (you will be prompted for the sudo password by default):
 grm install 192.168.1.10 --user ubuntu --key ~/.ssh/id_ed25519 --name prod-runner
 ```

+This command:
+
+1. Connects to `192.168.1.10` via SSH as user `ubuntu` using the specified key
+2. Creates a dedicated system user `grm-prod-runner` with lingering enabled
+3. Installs Docker in rootless mode under the `grm-prod-runner` user
+4. Downloads and installs the gitea_runner binary
+5. Creates the runner configuration file at `/etc/gitea-runner/prod-runner/config.yaml`
+6. Registers the runner with your Gitea instance
+7. Creates and starts a systemd user service (`gitea-runner.service`)
+8. Sets up a Docker prune timer (daily cleanup)
+9. Runs an integration test to verify the installation
+10. Saves the runner to the local registry at `~/.local/share/grm/runners.json`
+
 > **Automation tip:** Configure passwordless sudo on the remote host and pass `--no-ask-become-pass` to skip the password prompt. This is recommended for CI/CD pipelines.

 Using Make:
@@ -95,7 +130,18 @@ Using Make:
 make install HOST=192.168.1.10 USER=ubuntu KEY=~/.ssh/id_ed25519 NAME=prod-runner
 ```

-## Verify Runner
+### Runner labels
+
+By default, runners are registered with the label `docker,ubuntu-latest:docker://runner-images:ubuntu-22.04`. You can override this with `--labels`:
+
+```bash
+grm install 192.168.1.10 --user ubuntu --name prod-runner \
+  --labels "docker:docker://gitea/runner-images:ubuntu-latest"
+```
+
+> **Note:** Use an official Gitea runner image with Node.js, Python, and Docker CLI. Avoid bare OS images like `alpine:latest` because `actions/checkout@v4` needs Node.js.
+
+## Step 4: Verify the Installation

 The installer performs an automated integration test that verifies:

@@ -106,9 +152,41 @@ You can also check the Gitea UI under **Actions → Runners** to confirm the run

 Optional: If `REPO_TOKEN` is set, the installer will also query the Gitea API and report whether the runner appears in the admin or repo runners list. This is purely informational.

+### Check runner status via CLI
+
+```bash
+grm status prod-runner
+```
+
+This connects to the remote host and checks the systemd user service status.
+
+### List all runners
+
+```bash
+grm list
+```
+
+This displays a table with columns: NAME, HOST, USER, LABELS, STATUS for all runners in the local registry. The status is checked live via an Ansible ad-hoc command.
+
+## Step 5: Manage the Runner Lifecycle
+
+Once installed, you can manage the runner by name (connection details are stored in the local registry):
+
+```bash
+grm stop prod-runner       # Stop the runner service
+grm start prod-runner      # Start the runner service
+grm enable prod-runner     # Enable the runner to start on boot
+grm status prod-runner     # Check the runner status
+grm update 192.168.1.10 --user ubuntu  # Update the runner binary
+grm disable prod-runner    # Disable and deregister the runner
+grm remove prod-runner     # Remove the runner completely
+```
+
+See [CLI Commands](CLI-Commands.-) for the full command reference.
+
 ## View Logs

-**GRM application logs** (Python CLI output):
+### GRM application logs (on your local machine)

 ```bash
 # Application log file (all messages including DEBUG)
@@ -118,20 +196,42 @@ cat ~/.local/state/grm/logs/grm.log
 GRM_LOG_LEVEL=DEBUG grm install 192.168.1.10 --user ubuntu --name prod-runner
 ```

-**Runner logs** (on the remote host):
+### Ansible execution logs
+
+Each `grm` command that invokes Ansible creates a timestamped log file:
+
+```bash
+ls ~/.local/state/grm/logs/ansible-*.log
+cat ~/.local/state/grm/logs/ansible-20260622-143012.log
+```
+
+### Runner logs (on the remote host)

 ```bash
 # Runner logs (via systemd user service)
-sudo -u grm-<name> journalctl --user -u gitea-runner -f
+sudo -u grm-prod-runner journalctl --user -u gitea-runner -f
+
+# Rootless Docker daemon logs
+sudo -u grm-prod-runner journalctl --user -u docker -f
 ```

-The GRM application writes to two destinations:
+### Logging destinations
+
+The GRM application writes to three destinations:

 | Destination | Level | Content |
 |-------------|-------|---------|
 | Console (stdout) | `GRM_LOG_LEVEL` (default: INFO) | Colorised user-facing messages and operation reports |
 | `~/.local/state/grm/logs/grm.log` | DEBUG | All messages with timestamps and severity |
+| `~/.local/state/grm/logs/ansible-<timestamp>.log` | — | Full Ansible playbook output per execution |

 Set `GRM_LOG_LEVEL` to one of `DEBUG`, `INFO`, `WARNING`, `ERROR`, or `CRITICAL` to control console verbosity. The log file always captures everything at DEBUG level regardless of the console setting.

-Console output is automatically colorised via ``click.echo``: operation headers in bright cyan, completed steps in green, failures in red, and status updates in yellow.
+Console output is automatically colorised via `click.style`: operation headers in bright cyan, completed steps in green, failures in red, and status updates in yellow.
+
+## Next Steps
+
+- **Install more runners** on the same or different hosts — see [Installation](Installation)
+- **Learn all CLI commands** — see [CLI Commands](CLI-Commands.-)
+- **Troubleshoot issues** — see [Troubleshooting](Troubleshooting)
+- **Understand the architecture** — see [Architecture](Architecture)
@@ -1,20 +1,79 @@
 # Installation

-> **Before you start:** Make sure you have cloned the repo and checked out the latest stable release tag. See [Getting Started](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Getting-Started.-) for setup instructions. Do not run from `master` — it may contain unreleased changes.
+> **Before you start:** Make sure you have cloned the repo and checked out the latest stable release tag. See [Getting Started](Getting-Started.-) for setup instructions. Do not run from `master` — it may contain unreleased changes.

 ## Prerequisites

- **SSH key authentication** — The remote host must be reachable via SSH using the user specified with `--user` and the private key specified with `--key`. GRM uses Ansible under the hood, which connects to the target host over SSH to execute all installation and configuration tasks. Without valid SSH credentials, Ansible cannot establish a connection and the deployment will fail.
+### On your local machine (where you run `grm`)
+
+- **Python 3.12+** — GRM targets Python 3.12 and requires it for development setup. Use `pyenv` if you need to manage multiple Python versions.
+- **Ansible** — Installed automatically by `make setup` (via pip). GRM delegates all remote operations to `ansible-playbook`.
+- **SSH key** — A private key that grants access to the target host(s) as a user with sudo privileges.
+
+### On the target host(s) (where runners will be installed)
+
+- **SSH server** — The remote host must be reachable via SSH using the user specified with `--user` and the private key specified with `--key`. GRM uses Ansible under the hood, which connects to the target host over SSH to execute all installation and configuration tasks. Without valid SSH credentials, Ansible cannot establish a connection and the deployment will fail.
 - **Sudo access** — GRM requires root privileges on the remote host to create system users, install packages, and configure rootless Docker. By default, you will be prompted interactively for the sudo password. For automation or uninterrupted workflows, configure passwordless sudo on the remote host and pass `--no-ask-become-pass`.
- **Gitea registration token** — You need a runner registration token from your Gitea instance. See [Getting Started](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki/Getting-Started.-) for detailed instructions on obtaining tokens.
+- **Gitea registration token** — You need a runner registration token from your Gitea instance. See [Getting Started](Getting-Started.-) for detailed instructions on obtaining tokens.
+- **systemd** — Required for user services and lingering. All supported OSes ship with systemd.
+- **Docker** — Installed automatically by the Ansible role (rootless mode). No pre-existing Docker installation is required.

 ## Supported Operating Systems

- Arch Linux
- Ubuntu 22.04 / 24.04
- Debian 12
+| OS | Versions | Package manager |
+|----|----------|-----------------|
+| Arch Linux | rolling | pacman |
+| Ubuntu | 22.04, 24.04 | apt |
+| Debian | 12 | apt |

-All supported OSes are tested in CI via molecule scenarios on every PR.
+All supported OSes are tested in CI via Molecule scenarios on every PR that changes Ansible files. The platform matrix is defined in `devx.molecule.platforms` as the single source of truth.
+
+## Installation Methods
+
+### Method 1: From source (recommended for full control)
+
+```bash
+git clone https://git.oblachno.oblachno.fyi/oblachno-oss/grm.git
+cd grm
+git checkout $(git describe --tags --abbrev=0)  # Latest stable release
+make setup
+source .venv/bin/activate
+```
+
+`make setup` performs the following:
+
+1. Verifies Python 3.12+ is installed
+2. Creates a virtualenv in `.venv`
+3. Installs all Python dependencies (including Ansible, Click, python-dotenv)
+4. Creates `.env` from `.env.example` if not present
+5. Installs development tools (actionlint, git-cliff, act_runner, checkmake)
+6. Sets up pre-commit hooks
+
+### Method 2: Via pip
+
+```bash
+pip install gitea-runner-manager
+```
+
+This installs the `grm` CLI and its Python dependencies. The Ansible playbooks and role are bundled with the package, so `grm install` will work out of the box. However, for development or access to Make targets, clone the repository.
+
+### Post-install configuration
+
+After installation, create your `.env` file:
+
+```bash
+cp .env.example .env
+# Edit .env with your Gitea URL and registration token
+```
+
+Required variables:
+
+| Variable | Description |
+|----------|-------------|
+| `GITEA_URL` | Your Gitea instance URL (e.g., `https://git.example.com`) |
+| `GITEA_REGISTRATION_TOKEN` | Runner registration token from Gitea (starts with `GR`) |
+
+See [Getting Started](Getting-Started.-) for detailed token setup instructions.

 ## Quick Start Install

@@ -34,13 +93,63 @@ Using Make:
 make install HOST=192.168.1.10 USER=ubuntu KEY=~/.ssh/id_ed25519 NAME=prod-runner
 ```

+The Make target wraps the `grm install` CLI command. All Make install variables are optional except `HOST`:
+
+| Variable | Description |
+|----------|-------------|
+| `HOST` | Remote host (IP address or hostname) — **required** |
+| `USER` | SSH user |
+| `KEY` | Path to SSH private key |
+| `NAME` | Gitea Runner name |
+| `TOKEN` | Registration token |
+| `ASK_BECOME_PASS` | Set to `1` to prompt for sudo password |
+
+## What Gets Installed on the Target Host
+
+When you run `grm install`, the Ansible role creates the following on the remote host:
+
+| Resource | Path | Description |
+|----------|------|-------------|
+| System user | `grm-<name>` | Dedicated system user with `/bin/bash` shell |
+| Home directory | `/home/grm-<name>/` | User home with `.config/systemd/user/` |
+| Data directory | `/var/lib/gitea-runner/<name>/` | Runner data including `.runner` registration file |
+| Config directory | `/etc/gitea-runner/<name>/` | Runner configuration file (`config.yaml`) |
+| Runner binary | `/usr/local/bin/gitea_runner` | The gitea_runner executable |
+| Docker socket | `/run/user/<UID>/docker.sock` | Rootless Docker socket |
+| Systemd service | `gitea-runner.service` | User service for the runner daemon |
+| Docker prune timer | `docker-prune.timer` | Daily Docker cleanup timer |
+| subuid/subgid | `/etc/subuid`, `/etc/subgid` | User namespace mapping (100000-165535) |
+| Lingering | `loginctl enable-linger` | Ensures services run without active login |
+
 ## Runner Registry

-After installation, GRM stores each runner's connection details (host, user, SSH key, Gitea URL) in a local JSON registry at `~/.local/share/grm/runners.json`. This means you rarely need to repeat connection arguments:
+After installation, GRM stores each runner's connection details (host, user, SSH key, Gitea URL, labels) in a local JSON registry at `~/.local/share/grm/runners.json`. This means you rarely need to repeat connection arguments:

 ```bash
 # List all registered runners with live systemd status
 grm list
+
+# Manage runners by name — connection details come from the registry
+grm status prod-runner
+grm stop prod-runner
+grm start prod-runner
+```
+
+You can override any stored value by passing the corresponding flag (`--host`, `--user`, `--key`).
+
+### Registry file format
+
+```json
+{
+  "prod-runner": {
+    "host": "192.168.1.10",
+    "user": "ubuntu",
+    "key": "/home/user/.ssh/id_ed25519",
+    "gitea_url": "https://git.example.com",
+    "labels": "docker:docker://gitea/runner-images:ubuntu-latest",
+    "created_at": "2026-06-22T14:30:12.000000+00:00"
+  }
+}
 ```

 ## Multiple Instances on the Same Host
@@ -55,4 +164,56 @@ grm install 192.168.1.10 --user ubuntu --name build-runner
 # Manage them independently by name
 grm stop workflow-runner
 grm status build-runner
+grm list
+```
+
+Each instance gets:
+
+- **Dedicated system user**: `grm-<name>` with its own home directory
+- **Rootless Docker daemon**: Isolated Docker socket at `/run/user/<UID>/docker.sock`
+- **Data directory**: `/var/lib/gitea-runner/<name>/`
+- **Config directory**: `/etc/gitea-runner/<name>/`
+- **Systemd user service**: `gitea-runner.service` (independent start/stop/enable)
+- **Docker prune timer**: Per-instance daily cleanup
+
+Runners on the same host never interfere with each other or with the host's Docker installation.
+
+## Updating Runners
+
+To update the gitea_runner binary on a remote host:
+
+```bash
+grm update 192.168.1.10 --user ubuntu
+```
+
+To update to a specific version:
+
+```bash
+grm update 192.168.1.10 --user ubuntu --version 1.0.8
+```
+
+Using Make:
+
+```bash
+make update HOST=192.168.1.10 USER=ubuntu VERSION=1.0.8
+```
+
+## Removing Runners
+
+To remove a runner completely (deregisters from Gitea, removes user, directories, and service files):
+
+```bash
+grm remove prod-runner --token <registration-token>
+```
+
+To skip remote cleanup and only remove the local registry entry (useful when the remote host is already gone):
+
+```bash
+grm remove prod-runner --force
+```
+
+Using Make:
+
+```bash
+make remove NAME=prod-runner TOKEN=<registration-token>
 ```
@@ -1,42 +1,189 @@
 # Troubleshooting

-## "Event loop is closed" warning
+## Installation Issues

-This is a harmless cleanup traceback from Molecule's Docker driver when the test process is interrupted. It does not indicate a test failure.
+### Ansible connection fails (UNREACHABLE)

-## Runner appears offline after installation
+**Symptom:** Ansible reports `UNREACHABLE` when trying to connect to the target host.
+
+**Causes and solutions:**
+
+- **SSH key not found or wrong path** — Verify the key path with `--key`. The key must be readable by the user running `grm`.
+- **SSH user does not exist on the target** — Verify the `--user` argument. The user must exist on the remote host and have sudo privileges.
+- **Host is not reachable** — Verify the host IP/hostname with `ping` and `ssh -u <user> <host>`.
+- **SSH port is not 22** — GRM uses the default SSH port. If your host uses a different port, you may need to configure SSH config (`~/.ssh/config`) with the appropriate port.
+
+### Sudo password prompt fails or is not displayed
+
+**Symptom:** The sudo password prompt does not appear or the command hangs.
+
+**Causes and solutions:**
+
+- **Non-interactive session** — If running in a CI/CD pipeline or script without a TTY, the password prompt cannot be displayed. Configure passwordless sudo on the remote host and pass `--no-ask-become-pass`.
+- **Wrong sudo password** — Ensure you are entering the correct sudo password for the remote user.
+
+### GITEA_URL must be set
+
+**Symptom:** Error message `GITEA_URL must be set (or pass --url)`.
+
+**Solution:** Set `GITEA_URL` in your `.env` file or pass it via `--url`:
+
+```bash
+# In .env
+GITEA_URL=https://git.example.com
+
+# Or on the command line
+grm install 192.168.1.10 --user ubuntu --url https://git.example.com
+```
+
+### GITEA_REGISTRATION_TOKEN must be set
+
+**Symptom:** Error message `GITEA_REGISTRATION_TOKEN must be set (or pass --token)`.
+
+**Solution:** Set `GITEA_REGISTRATION_TOKEN` in your `.env` file or pass it via `--token`. The token must be a valid registration token from your Gitea instance (it starts with `GR`).
+
+## Runner Issues
+
+### Runner appears offline after installation

 - Check that the `GITEA_URL` and `GITEA_REGISTRATION_TOKEN` environment variables are correct.
 - Verify the registration token has not expired — generate a new one from Gitea if needed (Site Administration → Actions → Runners → Create Registration Token).
 - Verify the runner service is running: `sudo -u grm-<name> systemctl --user status gitea-runner`.
- Check logs for registration errors.
+- Check logs for registration errors: `sudo -u grm-<name> journalctl --user -u gitea-runner -f`.
+- Confirm the runner appears in the Gitea UI under **Actions → Runners**. If it shows as offline, the runner daemon may not be polling — check network connectivity between the runner host and Gitea.

-## Integration test fails
+### Runner service fails to start
+
+- Check the service status: `sudo -u grm-<name> systemctl --user status gitea-runner`
+- Check logs: `sudo -u grm-<name> journalctl --user -u gitea-runner -f`
+- Verify the runner binary exists: `ls -la /usr/local/bin/gitea_runner`
+- Verify the config file exists: `ls -la /etc/gitea-runner/<name>/config.yaml`
+- Verify the `.runner` registration file exists: `ls -la /var/lib/gitea-runner/<name>/.runner`
+
+### Rootless Docker: service fails to start
+
+- Check the service status: `sudo -u grm-<name> systemctl --user status gitea-runner`.
+- Verify the rootless Docker daemon is running: `sudo -u grm-<name> systemctl --user status docker`.
+- Verify the Docker socket exists: `ls /run/user/$(id -u grm-<name>)/docker.sock`.
+- Check logs: `sudo -u grm-<name> journalctl --user -u gitea-runner -f`.
+- Ensure lingering is enabled for the runner user: `loginctl show-user grm-<name> | grep Linger`. If not enabled, run `sudo loginctl enable-linger grm-<name>`.
+- Verify subuid/subgid entries exist: `grep grm-<name> /etc/subuid /etc/subgid`. If missing, the rootless Docker setup will fail.
+
+### Runner not found in registry
+
+**Symptom:** Error message `Runner '<name>' not found in registry. Use 'grm install' first or provide --host and --user.`
+
+**Solution:** The runner was not installed via `grm install`, or the registry file was deleted. Either:
+
+1. Install the runner first: `grm install <host> --user <user> --name <name>`
+2. Or provide explicit connection details: `grm status <name> --host <host> --user <user>`
+
+## Integration Test Issues
+
+### Integration test fails

 The test checks two things:

 1. **`.runner` file missing or invalid** — Registration failed. Check:
   - `GITEA_URL` and `GITEA_REGISTRATION_TOKEN` are correct
   - The registration token is valid and has not expired
-   - Runner logs for registration errors
+   - Runner logs for registration errors: `sudo -u grm-<name> journalctl --user -u gitea-runner`
   - The `.runner` file should exist at `/var/lib/gitea-runner/<name>/.runner`
+   - The `.runner` file should contain valid JSON with `id`, `uuid`, `token`, `address` fields

 2. **Service not running** — Daemon failed to start. Check:
   - `sudo -u grm-<name> systemctl --user status gitea-runner`
-   - Logs for connection errors
+   - Logs for connection errors: `sudo -u grm-<name> journalctl --user -u gitea-runner`
+   - Verify the rootless Docker daemon is running (see above)

-## Rootless Docker: service fails to start
+### API verification shows error status

- Check the service status: `sudo -u grm-<name> systemctl --user status gitea-runner`.
- Verify the rootless Docker daemon is running: `sudo -u grm-<name> systemctl --user status docker`.
- Verify the Docker socket exists: `ls /run/user/$(id -u grm-<name>)/docker.sock`.
- Check logs: `sudo -u grm-<name> journalctl --user -u gitea-runner -f`.
- Ensure lingering is enabled for the runner user: `loginctl show-user grm-<name> | grep Linger`.
+If `REPO_TOKEN` is set, the integration test queries the Gitea API. If the API returns `401` or `403`, the token does not have sufficient permissions. This is **informational only** and does not affect pass/fail. The test passes as long as the `.runner` file exists and the systemd service is active.
+
+## Logging and Diagnostics
+
+### Enable debug logging
+
+```bash
+GRM_LOG_LEVEL=DEBUG grm install 192.168.1.10 --user ubuntu --name prod-runner
+```
+
+This prints all debug messages to the console. The log file at `~/.local/state/grm/logs/grm.log` always captures DEBUG level regardless of this setting.
+
+### View Ansible execution logs
+
+Each `grm` command that invokes Ansible creates a timestamped log file:
+
+```bash
+ls ~/.local/state/grm/logs/ansible-*.log
+cat ~/.local/state/grm/logs/ansible-<timestamp>.log
+```
+
+These logs contain the full Ansible output, including task results, changed/failed counts, and any error messages.
+
+### View runner logs on the remote host
+
+```bash
+# Runner daemon logs
+sudo -u grm-<name> journalctl --user -u gitea-runner -f
+
+# Rootless Docker daemon logs
+sudo -u grm-<name> journalctl --user -u docker -f
+
+# Docker prune timer logs
+sudo -u grm-<name> journalctl --user -u docker-prune.service
+```
+
+## Development Issues
+
+### "Event loop is closed" warning
+
+This is a harmless cleanup traceback from Molecule's Docker driver when the test process is interrupted. It does not indicate a test failure.
+
+### Pre-commit rejects commit message
+
+The pre-commit hook validates that commit messages follow conventional commit format (`feat:`, `fix:`, `docs:`, etc.). The `GRM-N:` prefix is not allowed on branch commits — use it only in PR titles.
+
+**Correct:**
+```
+feat: add new runner label option
+```
+
+**Incorrect:**
+```
+GRM-33: add new runner label option
+update README
+```
+
+### `make pytest-cov` fails with coverage below 100%
+
+Add tests for any new code paths. The coverage requirement is strict (`--cov-fail-under=100`). Run `make pytest-cov` locally to see which lines are not covered:
+
+```bash
+make pytest-cov
+# The output shows "Missing" lines for each file
+```
+
+### `make molecule` fails with Docker not available
+
+Molecule requires Docker to be installed and running on your machine. Verify:
+
+```bash
+docker info  # Should print Docker server info
+```
+
+If Docker is not installed, install it via your package manager or [Docker's official installation guide](https://docs.docker.com/get-docker/).

 ## Common Issues Reference Table

 | Symptom | Likely Cause | Solution |
 |---------|-------------|----------|
+| Ansible UNREACHABLE | SSH connection failed | Verify `--user`, `--key`, and host reachability |
+| `GITEA_URL must be set` | Missing environment variable | Set `GITEA_URL` in `.env` or pass `--url` |
+| `GITEA_REGISTRATION_TOKEN must be set` | Missing environment variable | Set `GITEA_REGISTRATION_TOKEN` in `.env` or pass `--token` |
+| Runner appears offline | Registration failed or service not running | Check GITEA_URL, token validity, and service status |
+| Rootless Docker fails to start | subuid/subgid missing or lingering disabled | Verify `/etc/subuid`, `/etc/subgid`, and `loginctl show-user` |
+| Runner not found in registry | Runner not installed or registry deleted | Run `grm install` or provide `--host` and `--user` |
 | Pre-commit rejects commit message | Missing conventional format or GRM-N prefix present | Use `feat: description` format without `GRM-N:` |
 | `make molecule` fails with `runner_name is undefined` | Verify playbook missing variable | Fixed in Phase 1.1; ensure you're on latest master |
 | CI molecule job fails | Docker not available on runner host | Ensure Gitea runner host has Docker installed and running |
@@ -1,5 +1,6 @@
 #!/usr/bin/env bash
-# pre-commit hook: fail if unit tests take longer than 10 seconds.
-# Aligned with CI timeout (ci.yml uses --max-seconds 10).
+# pre-commit hook: fail if unit tests are too slow.
+# Checks both total suite time (10s) and per-test time (0.5s).
+# Aligned with CI (ci.yml uses same thresholds).
 set -e
-python3 -m devx.tools.check_test_speed --max-seconds 10
+python3 -m devx.tools.check_test_speed --max-seconds 4 --max-single-seconds 0.5
@@ -1,5 +1,6 @@
 #!/usr/bin/env bash
-# pre-push hook: fail if unit tests take longer than 10 seconds.
-# Aligned with CI timeout (ci.yml uses --max-seconds 10).
+# pre-push hook: fail if unit tests are too slow.
+# Checks both total suite time (10s) and per-test time (0.5s).
+# Aligned with CI (ci.yml uses same thresholds).
 set -e
-python3 -m devx.tools.check_test_speed --max-seconds 10
+python3 -m devx.tools.check_test_speed --max-seconds 4 --max-single-seconds 0.5
@@ -32,6 +32,8 @@ version = {attr = "gitea_runner_manager.__version__"}
 ci = [
    "pytest>=9.1.0",
    "pytest-cov>=7.1.0",
+    "build>=1.5.0",
+    "twine>=6.2.0",
 ]
 # Lint and type-checking tools (quality job)
 lint = [
@@ -1,3 +1,3 @@
 """Gitea Runner Manager — lean CLI for managing Gitea Actions runners."""

-__version__ = "0.6.3"
+__version__ = "0.8.1"
@@ -556,7 +556,8 @@ class TestVikunjaClient:
            json={"done": True},
        )

-    def test_http_error_raises_api_error(self) -> None:
+    @patch("gitea_runner_manager.api_clients.time.sleep")
+    def test_http_error_raises_api_error(self, mock_sleep: MagicMock) -> None:
        client = VikunjaClient("https://work.example.com", "tok")
        mock_resp = MagicMock()
        mock_resp.raise_for_status.side_effect = _mock_http_error(http.HTTPStatus.INTERNAL_SERVER_ERROR, "server error")
Author	SHA1	Message	Date
grm-ci-bot	acc768eaea	release: v0.8.1 [skip ci]	2026-06-25 00:29:27 +02:00
emil	cf2314c20f	GRM-83: fix: add build/twine to ci deps, activate venv in notify_failure	2026-06-24 22:28:08 +00:00
gitea-actions-bot	aac47e3472	chore: update badge URLs to commit a7a72d7d [skip ci]	2026-06-25 00:14:31 +02:00
emil	811e7a2309	GRM-82: fix: repair publish workflow and add publish step to post-merge	2026-06-24 22:11:48 +00:00
gitea-actions-bot	cb68c85bb5	chore: update badge URLs to commit 123065d0 [skip ci]	2026-06-24 21:06:40 +00:00
emil	0ba30e09ea	GRM-81: ci: update devx to v0.10.2 for badge testpaths fix	2026-06-24 21:03:53 +00:00
gitea-actions-bot	6a02581687	chore: update badge URLs to commit e32f1c05 [skip ci]	2026-06-24 22:45:35 +02:00
grm-ci-bot	4679473183	release: v0.8.0 [skip ci]	2026-06-24 22:44:06 +02:00
emil	6359eab962	GRM-80: ci: update devx to v0.10.1 for badge generation fix	2026-06-24 20:42:27 +00:00
emil	2017a5ee3e	GRM-79: feat: remove .taskid file, use branch name only for task ID	2026-06-24 20:15:59 +00:00
emil	465e9bd484	GRM-78: fix: add workflow_dispatch to publish workflow and update devx to 0.9.12	2026-06-24 20:05:54 +00:00
grm-ci-bot	da0656b949	release: v0.7.0 [skip ci]	2026-06-24 21:19:57 +02:00
emil	64ab0f059b	GRM-75: feat: thoroughly clean Docker artifacts on runner removal ## Summary Thoroughly cleans Docker artifacts on runner removal, updates devx to v0.9.11, fixes Makefile checkmake graceful skip, and comprehensive docs rewrite. Molecule tests fail due to pre-existing Docker infrastructure issue (Docker socket not available in CI runners). Closes GRM-75	2026-06-24 19:18:23 +00:00
emil	a58f5ec301	GRM-77: fix: replace stale badge SHA URLs with raw/branch/badges/	2026-06-24 17:30:17 +00:00
emil	1dc20025d8	GRM-76: fix: retrospective fixes for CI/CD friction	2026-06-24 16:47:01 +00:00
emil	e6918a9be9	GRM-74: fix: lower test speed threshold to 4s and update devx to v0.8.2	2026-06-23 20:47:42 +00:00
emil	c5d8cbef5a	GRM-73: feat: adopt per-test timing quality gate from devx 0.7.0	2026-06-23 16:51:52 +00:00
emil	6032a07038	GRM-72: feat: switch devx installation from git to Gitea PyPI registry	2026-06-23 14:16:44 +00:00
emil	af251ffdaa	GRM-70: fix: rewrite CHANGELOG with correct version ordering and missing sections	2026-06-22 22:23:32 +00:00
emil	493051b79b	GRM-69: fix: pin devx to v0.4.4 to fix validate-commit-msg and sync-wiki	2026-06-22 21:49:27 +00:00
emil	cb94709091	GRM-68: fix: pin devx to v0.4.3 to fix post-merge workflow failures	2026-06-22 21:36:28 +00:00
emil	7987778a4f	GRM-67: fix: update devx to v0.4.2 and fix workflow env vars	2026-06-22 21:30:23 +00:00