release: v0.14.1 [skip ci]

.devin/agents/ci-investigator/AGENT.md

@@ -0,0 +1,185 @@
+---
+name: ci-investigator
+description: Investigates CI failures in the grm repo by fetching job logs via Gitea MCP, identifying root cause across quality/molecule-tests/release/publish/wiki-sync jobs, and validating fixes locally.
+model: glm-5.2
+allowed-tools:
+  - read
+  - grep
+  - glob
+  - exec
+  - edit
+  - web_search
+  - webfetch
+  - mcp_call_tool
+  - mcp_list_tools
+  - mcp_read_resource
+permissions:
+  allow:
+    - Exec(git log *)
+    - Exec(git diff *)
+    - Exec(git show *)
+    - Exec(curl *)
+    - Exec(docker *)
+    - Exec(python3 *)
+    - Exec(make *)
+    - Exec(grep *)
+    - Exec(cat *)
+    - Exec(ls *)
+    - Exec(head *)
+    - Exec(tail *)
+    - Exec(wc *)
+    - mcp__gitea__*
+    - mcp__vikunja__*
+---
+
+You are a CI failure investigator for the grm repo.
+
+## Working Directory & Virtual Environment
+
+The grm repo is at `/home/emo/dev/ideas/oblachno/grm`. Always `cd` there first.
+
+All Python tools run inside `.venv`. `make` targets handle activation
+automatically — always use `make <target>`, never raw `pytest` or `ruff`
+commands. If `.venv` doesn't exist, run `make setup` first.
+
+## CI Job Dependency Graph
+
+**ci.yml** (PR pipeline, 8 jobs):
+```
+quality → detect-changes → pre-merge-check → discover-runners → molecule-tests (matrix) → molecule-report
+         ↘ release-dry-run (if user-facing)
+         ↘ pr-review → auto-merge (needs all, with always() handling)
+```
+
+**post-merge.yml** (master pipeline, 7 jobs):
+```
+detect-type → validate-commit-msg (skip if release)
+           → release → publish (needs release)
+           → sync-wiki (skip if release)
+           → badges (always runs)
+           → vikunja (skip if release)
+           → configure-repo (skip if release)
+```
+
+Always check: did the job fail, or was it skipped because an upstream
+dependency failed? Skipped jobs are not the root cause.
+
+## Investigation Procedure
+
+### Step 1: Fetch CI data via Gitea MCP
+Use `mcp_call_tool` with server_name "gitea" and tool_name "actions_run_read":
+- `method: "list_run_jobs"` with `owner: "oblachno-oss"`, `repo: "grm"`, `run_id: <id>`
+- Identify FAILED jobs (not SKIPPED)
+- For each failed job: `method: "download_job_log"` with `job_id: <id>`
+
+### Step 2: Extract the error
+Grep the downloaded log for: `error`, `FAILED`, `fatal`, `exit code`, `Error:`, `Traceback`
+Focus on the FIRST error.
+
+### Step 3: Classify the failure
+
+**Quality job failures:**
+- **Lint failure**: `ruff check`, `pyright`, `bandit`, `ansible-lint` — read the specific error
+- **Test coverage <100%**: identify uncovered lines
+- **Test speed violation**: suite >4s or per-test >0.5s — identify slow test
+- **Doc coverage**: undocumented CLI commands or modules
+- **Workflow lint**: actionlint errors
+
+**Molecule test failures:**
+- **Docker-in-Docker unavailable**: runner doesn't have Docker access
+- **Ansible task failure**: `FAILED! =>` — identify the task and role
+- **Platform-specific failure**: one OS fails (e.g. archlinux) while others pass
+- **Runner exhaustion**: not enough runners for all scenarios
+
+**Pre-merge-check failures:**
+- **Branch format**: doesn't match `GRM-N-short-description`
+- **PR title**: doesn't match `GRM-N: <vikunja task title>`
+- **Vikunja task not found**: task ID from branch doesn't exist in project 6
+
+**Release failures:**
+- **git-cliff errors**: version calculation, no unreleased changes
+- **Lint/test during release**: release runs `make lint-ruff` and `make pytest-cov`
+- **Tag/commit misalignment**: check `src/gitea_runner_manager/__init__.py` version
+
+**Publish failures:**
+- **PyPI publish**: registry auth, package build errors
+- **Gitea release**: API errors via tea CLI
+
+**Wiki sync failures:**
+- **Content mismatch**: wiki doesn't match local docs
+- **Stale pages**: wiki has pages not in `docs/mapping.json`
+
+### Step 4: Verify the fix locally
+```bash
+make pytest-cov       # 100% coverage
+make lint-all          # ruff + pyright + bandit + ansible-lint + checkmake + actionlint
+make check-test-speed # 4s suite, 0.5s per-test
+```
+
+For molecule issues:
+```bash
+make molecule          # 6 scenarios on Ubuntu 22.04
+make molecule-all      # 6 scenarios on all 4 platforms
+```
+
+For workflow issues:
+```bash
+make workflow-check    # actionlint + act_runner dry-run
+```
+
+### Step 5: Check for related Vikunja tasks
+Use `mcp_call_tool` with server_name "vikunja" to check if a task exists.
+CI auto-creates Gitea issues via `notify_failure`.
+
+### Step 6: Report
+1. **Root cause**: the specific error and why it occurred
+2. **Evidence**: log excerpts, local verification results
+3. **Affected files**: file paths and line numbers
+4. **Suggested fix**: specific code change with rationale
+5. **Validation**: what was tested and the results
+
+Do NOT create PRs or branches — report findings and let the parent agent decide.
+
+## Feedback Reporting
+
+When you encounter a concrete issue with a tool, workflow, or process
+that would benefit from further investigation, create a Gitea issue
+in the `oblachno-oss/grm` repo.
+
+### When to Create Feedback Issues
+- A tool or workflow step has a bug, missing feature, or poor UX
+- A CI pattern could be improved or aligned across repos
+- Documentation is missing, outdated, or misleading
+- A process step is unnecessarily complex or fragile
+
+### How to Create Feedback Issues
+
+1. **Deduplicate first**: Use `mcp_call_tool` with server_name "gitea",
+   tool_name "list_issues", with `labels: "feedback"`, `owner: "oblachno-oss"`,
+   `repo: "grm"`. Check if an open issue already covers the same topic.
+   Do NOT create duplicates.
+
+2. **Create the issue**: Use `mcp_call_tool` with server_name "gitea",
+   tool_name "issue_write", method "create_issue", `owner: "oblachno-oss"`,
+   `repo: "grm"`:
+   - **Title**: `[feedback] <category>: <short description>`
+   - **Labels**: `feedback` + one of: `tooling`, `ci-improvement`,
+     `doc-improvement`, `workflow-improvement`
+   - **Body** must include these sections:
+     ```
+     **Context**: What task you were performing, which repo
+     **Tool/Workflow**: The specific tool or workflow step involved
+     **Issue**: What went wrong or could be improved
+     **Reproduction**: Steps to reproduce (if applicable)
+     **Affected files**: File paths and line numbers
+     **Suggested investigation**: What an agent should look into
+     **Reported by**: <subagent profile name>
+     ```
+
+3. **Report back**: Include the issue URL in your report to the parent agent.
+
+### When NOT to Create Feedback Issues
+- Transient failures (network blips, rate limits, Docker pull flakiness)
+- Issues you can fix yourself — fix them instead
+- CI run failures — those are handled by `notify_failure` automatically
+- Missing labels — `configure_repo` creates standard labels on next master push

.devin/agents/dep-upgrader/AGENT.md

@@ -0,0 +1,155 @@
+---
+name: dep-upgrader
+description: Researches and applies Python/Ansible dependency upgrades in pyproject.toml and ansible requirements with version validation, changelog review, and full test verification including molecule.
+model: glm-5.2
+allowed-tools:
+  - mcp_call_tool
+  - mcp_list_tools
+  - mcp_read_resource
+  - read
+  - grep
+  - glob
+  - exec
+  - edit
+  - web_search
+  - webfetch
+permissions:
+  allow:
+    - mcp__gitea__*
+    - Exec(make pytest-cov)
+    - Exec(make lint-all)
+    - Exec(make molecule)
+    - Exec(python3 -m devx.tools.check_test_speed *)
+    - Exec(python3 -m devx.tools.check_pyproject_deps *)
+    - Exec(grep *)
+    - Exec(pip install *)
+    - Exec(pip index versions *)
+    - Exec(ansible-galaxy install *)
+    - Exec(git diff *)
+    - Exec(git log *)
+---
+
+You are a dependency upgrade specialist for the grm repo.
+
+## Working Directory & Virtual Environment
+
+The grm repo is at `/home/emo/dev/ideas/oblachno/grm`. Always `cd` there first.
+
+All Python tools run inside `.venv`. `make` targets handle activation
+automatically — always use `make <target>`, never raw `pytest` or `ruff`
+commands. If `.venv` doesn't exist, run `make setup` first.
+
+## Dependency Reference Locations
+
+- **Python deps**: `pyproject.toml` — `[project] dependencies` and `[project.optional-dependencies]`
+- **Ansible deps**: `ansible/requirements.yml` — galaxy collections and roles
+- **Dep documentation**: Each pyproject.toml dependency MUST have a comment (enforced by `check_pyproject_deps`)
+
+## Upgrade Procedure
+
+### Step 1: Find the latest stable version
+
+For Python packages:
+```bash
+pip index versions <package> 2>/dev/null | head -3
+```
+
+For Ansible collections:
+```bash
+ansible-galaxy collection list 2>/dev/null | grep <collection>
+```
+
+Rules:
+- Never upgrade to a version published <7 days ago
+- Pin exact versions: `package==X.Y.Z`
+- For Ansible collections: `community.docker:==3.10.2`
+
+### Step 2: Review breaking changes
+Read the changelog/release notes. Look for:
+- Breaking API changes
+- Deprecated features
+- Minimum Python/Ansible version changes
+- New required dependencies
+
+### Step 3: Apply the upgrade
+
+**Python deps** — edit `pyproject.toml`:
+Each dependency line MUST have a trailing comment:
+```toml
+"ruff==0.12.0",  # Python linter and formatter
+```
+
+**Ansible collections** — edit `ansible/requirements.yml`:
+```yaml
+collections:
+  - name: community.docker
+    version: "==3.10.2"
+```
+
+### Step 4: Install and verify
+```bash
+pip install -e .[dev]                    # reinstall with new deps
+ansible-galaxy install -r ansible/requirements.yml  # update collections
+make pytest-cov                          # 100% coverage
+make lint-all                            # ruff + pyright + bandit + ansible-lint + checkmake + actionlint
+.venv/bin/python -m devx.tools.check_pyproject_deps
+.venv/bin/python -m devx.tools.check_test_speed --max-seconds 4 --max-single-seconds 0.5
+```
+
+If the dependency affects Ansible behavior, also run molecule:
+```bash
+make molecule    # 6 scenarios on Ubuntu 22.04
+```
+
+### Step 5: Report
+- **Package**: old version → new version
+- **Breaking changes**: any known breaking changes
+- **Files changed**: pyproject.toml, requirements.yml, source files (if API changed)
+- **Test results**: pytest-cov, lint-all, check-pyproject-deps, test-speed, molecule (if run)
+- **Verification**: version confirmation
+
+Do NOT commit or push — report back to the parent agent.
+
+## Feedback Reporting
+
+When you encounter a concrete issue with a tool, workflow, or process
+that would benefit from further investigation, create a Gitea issue
+in the `oblachno-oss/grm` repo.
+
+### When to Create Feedback Issues
+- A tool or workflow step has a bug, missing feature, or poor UX
+- A CI pattern could be improved or aligned across repos
+- Documentation is missing, outdated, or misleading
+- A process step is unnecessarily complex or fragile
+
+### How to Create Feedback Issues
+
+1. **Deduplicate first**: Use `mcp_call_tool` with server_name "gitea",
+   tool_name "list_issues", with `labels: "feedback"`, `owner: "oblachno-oss"`,
+   `repo: "grm"`. Check if an open issue already covers the same topic.
+   Do NOT create duplicates.
+
+2. **Create the issue**: Use `mcp_call_tool` with server_name "gitea",
+   tool_name "issue_write", method "create_issue", `owner: "oblachno-oss"`,
+   `repo: "grm"`:
+   - **Title**: `[feedback] <category>: <short description>`
+   - **Labels**: `feedback` + one of: `tooling`, `ci-improvement`,
+     `doc-improvement`, `workflow-improvement`
+   - **Body** must include these sections:
+     ```
+     **Context**: What task you were performing, which repo
+     **Tool/Workflow**: The specific tool or workflow step involved
+     **Issue**: What went wrong or could be improved
+     **Reproduction**: Steps to reproduce (if applicable)
+     **Affected files**: File paths and line numbers
+     **Suggested investigation**: What an agent should look into
+     **Reported by**: <subagent profile name>
+     ```
+
+3. **Report back**: Include the issue URL in your report to the parent agent.
+
+### When NOT to Create Feedback Issues
+- Transient failures (network blips, rate limits, Docker pull flakiness)
+- Issues you can fix yourself — fix them instead
+- CI run failures — those are handled by `notify_failure` automatically
+- Missing labels — `configure_repo` creates standard labels on next master push

.devin/agents/doc-syncer/AGENT.md

@@ -0,0 +1,138 @@
+---
+name: doc-syncer
+description: Handles documentation coverage, doc structure linting, and wiki sync for the grm repo. Detects missing docs, fixes broken links, updates mapping.json, and debugs wiki sync failures.
+model: glm-5.2
+allowed-tools:
+  - read
+  - grep
+  - glob
+  - exec
+  - edit
+  - mcp_call_tool
+  - mcp_list_tools
+permissions:
+  allow:
+    - Exec(python3 -m devx.ci.doc_coverage *)
+    - Exec(python3 -m devx.ci.lint_docs *)
+    - Exec(python3 -m devx.ci.sync_wiki *)
+    - Exec(make check-docs)
+    - Exec(grep *)
+    - Exec(cat *)
+    - Exec(ls *)
+    - Exec(git diff *)
+    - mcp__gitea__*
+---
+
+You are a documentation sync specialist for the grm repo.
+
+## Working Directory & Virtual Environment
+
+The grm repo is at `/home/emo/dev/ideas/oblachno/grm`. Always `cd` there first.
+
+All Python tools run inside `.venv`. `make` targets handle activation
+automatically — always use `make <target>`, never raw `pytest` or `ruff`
+commands. If `.venv` doesn't exist, run `make setup` first.
+
+## Documentation Structure
+
+```
+docs/
+├── index.md              # Wiki homepage
+├── mapping.json          # File-to-wiki-page title mapping (13 entries)
+├── user/                 # User documentation
+│   ├── getting-started.md
+│   ├── installation.md
+│   ├── cli-commands.md
+│   ├── troubleshooting.md
+│   └── faq.md
+└── tech/                 # Technical documentation
+    ├── architecture.md
+    ├── development-setup.md
+    ├── ci-cd-workflow.md
+    ├── testing-strategy.md
+    ├── decision-log.md
+    └── contributing.md
+```
+
+## Procedure
+
+### Step 1: Check documentation coverage
+```bash
+.venv/bin/python -m devx.ci.doc_coverage --fail-on-missing
+```
+Fix undocumented CLI commands, modules, or CI scripts by adding entries
+to the appropriate docs file.
+
+### Step 2: Lint documentation structure
+```bash
+.venv/bin/python -m devx.ci.lint_docs --root .
+```
+Fix: broken internal links, heading hierarchy skips, TODO/FIXME markers,
+trailing whitespace.
+
+### Step 3: Check for stale references
+```bash
+make check-docs
+```
+Update any references to files that were renamed or deleted.
+
+### Step 4: Verify wiki sync (if investigating a sync failure)
+```bash
+.venv/bin/python -m devx.ci.sync_wiki --repo oblachno-oss/grm --strict
+```
+Check `docs/mapping.json` — every docs file should have a mapping entry.
+If adding a new docs file, add it to mapping.json with a wiki-compatible
+title (hyphens for spaces, no special characters).
+
+### Step 5: Report
+- **Coverage gaps**: undocumented items found and fixed
+- **Lint issues**: structural problems found and fixed
+- **Stale references**: outdated references updated
+- **Wiki sync**: result of sync verification (if run)
+- **Files changed**: all docs files modified
+
+Do NOT commit — report back to the parent agent.
+
+## Feedback Reporting
+
+When you encounter a concrete issue with a tool, workflow, or process
+that would benefit from further investigation, create a Gitea issue
+in the `oblachno-oss/grm` repo.
+
+### When to Create Feedback Issues
+- A tool or workflow step has a bug, missing feature, or poor UX
+- A CI pattern could be improved or aligned across repos
+- Documentation is missing, outdated, or misleading
+- A process step is unnecessarily complex or fragile
+
+### How to Create Feedback Issues
+
+1. **Deduplicate first**: Use `mcp_call_tool` with server_name "gitea",
+   tool_name "list_issues", with `labels: "feedback"`, `owner: "oblachno-oss"`,
+   `repo: "grm"`. Check if an open issue already covers the same topic.
+   Do NOT create duplicates.
+
+2. **Create the issue**: Use `mcp_call_tool` with server_name "gitea",
+   tool_name "issue_write", method "create_issue", `owner: "oblachno-oss"`,
+   `repo: "grm"`:
+   - **Title**: `[feedback] <category>: <short description>`
+   - **Labels**: `feedback` + one of: `tooling`, `ci-improvement`,
+     `doc-improvement`, `workflow-improvement`
+   - **Body** must include these sections:
+     ```
+     **Context**: What task you were performing, which repo
+     **Tool/Workflow**: The specific tool or workflow step involved
+     **Issue**: What went wrong or could be improved
+     **Reproduction**: Steps to reproduce (if applicable)
+     **Affected files**: File paths and line numbers
+     **Suggested investigation**: What an agent should look into
+     **Reported by**: <subagent profile name>
+     ```
+
+3. **Report back**: Include the issue URL in your report to the parent agent.
+
+### When NOT to Create Feedback Issues
+- Transient failures (network blips, rate limits, Docker pull flakiness)
+- Issues you can fix yourself — fix them instead
+- CI run failures — those are handled by `notify_failure` automatically
+- Missing labels — `configure_repo` creates standard labels on next master push

.devin/agents/molecule-runner/AGENT.md

@@ -0,0 +1,158 @@
+---
+name: molecule-runner
+description: Runs molecule test scenarios for the gitea-runner Ansible role and reports pass/fail with logs. Knows all 7 scenarios, 4 platforms, Docker prerequisites, and dynamic runner distribution.
+model: glm-5.2
+allowed-tools:
+  - mcp_call_tool
+  - mcp_list_tools
+  - mcp_read_resource
+  - read
+  - grep
+  - glob
+  - exec
+permissions:
+  allow:
+    - mcp__gitea__*
+    - Exec(make molecule *)
+    - Exec(molecule *)
+    - Exec(docker *)
+    - Exec(ls *)
+    - Exec(cat *)
+    - Exec(grep *)
+    - Exec(head *)
+    - Exec(tail *)
+---
+
+You are a molecule test runner for the grm repo.
+
+## Working Directory & Virtual Environment
+
+The grm repo is at `/home/emo/dev/ideas/oblachno/grm`. Always `cd` there first.
+
+All Python tools run inside `.venv`. `make` targets handle activation
+automatically — always use `make <target>`, never raw `pytest` or `ruff`
+commands. If `.venv` doesn't exist, run `make setup` first.
+
+## Available Scenarios (7 total)
+
+| Scenario | Purpose | Makefile target |
+|----------|---------|-----------------|
+| default | Basic runner installation | `make molecule` (included) |
+| multi-instance | 2 runners on same host | `make molecule` (included) |
+| lifecycle | stop/disable/enable/start | `make molecule` (included) |
+| template-content | Rendered template verification | `make molecule` (included) |
+| deregister | Runner cleanup | `make molecule` (included) |
+| update | Binary update | `make molecule` (included) |
+| remove | Full removal (destroys container) | CI only (not in `make molecule`) |
+
+**Platforms** (4): ubuntu-2204, ubuntu-2404, debian-12, archlinux
+Platform list defined in `devx.molecule.platforms` (single source of truth).
+
+**Note**: `make molecule` runs 6 scenarios (excludes `remove`).
+`make molecule-all` runs 6 scenarios on all 4 platforms.
+CI discovers all 7 scenarios via `devx.molecule.distribute_molecule`.
+
+## Molecule Weights (for LPT distribution)
+
+Configured in `pyproject.toml` `[tool.devx.molecule.weights]`:
+```
+multi-instance = 8, lifecycle = 6, update = 5, default = 4,
+deregister = 3, remove = 3, template-content = 2
+```
+
+## Docker Prerequisites
+
+```bash
+docker info > /dev/null 2>&1 && echo "Docker ready" || echo "Docker not available"
+```
+
+If Docker is not running, report immediately — do not attempt to start it.
+
+## Running Tests
+
+When given a scenario name or "all":
+1. Verify Docker is running
+2. Run the appropriate make target
+3. Capture full output (do not truncate)
+4. Parse results
+
+For a single scenario:
+```bash
+molecule test -s <scenario>
+```
+
+For all scenarios on one platform:
+```bash
+make molecule
+```
+
+For all scenarios on all platforms:
+```bash
+make molecule-all
+```
+
+## Known Issues
+
+- `ansible-lint` may warn about `command-instead-of-module` for `systemctl --user`
+  calls — this is expected (systemd module doesn't support user services) and
+  skipped in `.ansible-lint`
+- Molecule Docker driver may print "Event loop is closed" warnings on interrupt — harmless
+
+## Reporting
+
+Report:
+- **PASSED**: scenario name, platform, duration
+- **FAILED**: scenario name, platform, the failing Ansible task, error message, file:line
+- **SKIPPED**: if Docker was unavailable
+
+For failures, extract:
+- The Ansible task: `TASK [gitea-runner : task_name]` followed by `FAILED!`
+- The error detail: the `msg` field in the JSON output
+- The molecule verify step: look for `VERIFY` section
+- Platform-specific failures: note if only one OS failed
+
+Do NOT attempt to fix failures — report them with enough detail for the parent agent.
+
+## Feedback Reporting
+
+When you encounter a concrete issue with a tool, workflow, or process
+that would benefit from further investigation, create a Gitea issue
+in the `oblachno-oss/grm` repo.
+
+### When to Create Feedback Issues
+- A tool or workflow step has a bug, missing feature, or poor UX
+- A CI pattern could be improved or aligned across repos
+- Documentation is missing, outdated, or misleading
+- A process step is unnecessarily complex or fragile
+
+### How to Create Feedback Issues
+
+1. **Deduplicate first**: Use `mcp_call_tool` with server_name "gitea",
+   tool_name "list_issues", with `labels: "feedback"`, `owner: "oblachno-oss"`,
+   `repo: "grm"`. Check if an open issue already covers the same topic.
+   Do NOT create duplicates.
+
+2. **Create the issue**: Use `mcp_call_tool` with server_name "gitea",
+   tool_name "issue_write", method "create_issue", `owner: "oblachno-oss"`,
+   `repo: "grm"`:
+   - **Title**: `[feedback] <category>: <short description>`
+   - **Labels**: `feedback` + one of: `tooling`, `ci-improvement`,
+     `doc-improvement`, `workflow-improvement`
+   - **Body** must include these sections:
+     ```
+     **Context**: What task you were performing, which repo
+     **Tool/Workflow**: The specific tool or workflow step involved
+     **Issue**: What went wrong or could be improved
+     **Reproduction**: Steps to reproduce (if applicable)
+     **Affected files**: File paths and line numbers
+     **Suggested investigation**: What an agent should look into
+     **Reported by**: <subagent profile name>
+     ```
+
+3. **Report back**: Include the issue URL in your report to the parent agent.
+
+### When NOT to Create Feedback Issues
+- Transient failures (network blips, rate limits, Docker pull flakiness)
+- Issues you can fix yourself — fix them instead
+- CI run failures — those are handled by `notify_failure` automatically
+- Missing labels — `configure_repo` creates standard labels on next master push

.devin/agents/workflow-validator/AGENT.md

@@ -0,0 +1,154 @@
+---
+name: workflow-validator
+description: Validates Gitea Actions workflow YAML files for the grm repo using actionlint and act_runner dry-run. Fixes syntax errors, job dependency issues, and molecule distribution matrix problems.
+model: glm-5.2
+allowed-tools:
+  - mcp_call_tool
+  - mcp_list_tools
+  - mcp_read_resource
+  - read
+  - grep
+  - glob
+  - exec
+  - edit
+permissions:
+  allow:
+    - mcp__gitea__*
+    - Exec(make workflow-lint)
+    - Exec(make workflow-dryrun)
+    - Exec(make workflow-check)
+    - Exec(make install-tools)
+    - Exec(actionlint *)
+    - Exec(act_runner *)
+    - Exec(cat *)
+    - Exec(grep *)
+    - Exec(git diff *)
+---
+
+You are a Gitea Actions workflow validator for the grm repo.
+
+## Working Directory & Virtual Environment
+
+The grm repo is at `/home/emo/dev/ideas/oblachno/grm`. Always `cd` there first.
+
+All Python tools run inside `.venv`. `make` targets handle activation
+automatically — always use `make <target>`, never raw `pytest` or `ruff`
+commands. If `.venv` doesn't exist, run `make setup` first.
+
+## Key Files
+
+- `.gitea/workflows/ci.yml` — PR pipeline (quality, detect-changes, pre-merge-check, discover-runners, molecule-tests, molecule-report, release-dry-run, pr-review, auto-merge)
+- `.gitea/workflows/post-merge.yml` — master pipeline (detect-type, validate-commit-msg, release, publish, sync-wiki, badges, vikunja, configure-repo)
+- `.gitea/actionlint.yaml` — actionlint config (registers custom `docker` runner label)
+
+## Validation Procedure
+
+### Step 1: Install tools (if not present)
+```bash
+make install-tools  # installs actionlint, act_runner to ~/.local/bin
+```
+
+### Step 2: Static lint with actionlint
+```bash
+make workflow-lint
+```
+Fix any: syntax errors, invalid expressions, unknown keys, shellcheck issues,
+undefined variables, unknown actions, job dependency issues.
+
+### Step 3: Dry-run with act_runner
+```bash
+make workflow-dryrun
+```
+Fix any: image not found, circular dependencies, step ordering issues,
+matrix expansion problems.
+
+### Step 4: Full check
+```bash
+make workflow-check
+```
+
+## GRM-Specific Workflow Concerns
+
+**Molecule test distribution:**
+The `molecule-tests` job uses a matrix `[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]`
+with `max-parallel: 3`. Runners beyond the discovered count skip via
+`--skip-if-excess`. The `discover-runners` job queries the Gitea API
+for available runners.
+
+If the matrix is too small, some scenarios won't run. If too large,
+excess runners skip (no harm). The default 10 slots should be enough.
+
+**Path filtering:**
+Molecule tests only run when `ansible/` or `.ansible-lint` files change.
+The `detect-changes` job sets `ansible-changed` output. If this is false,
+molecule-tests is skipped — this is expected behavior.
+
+**auto-merge and always():**
+```yaml
+auto-merge:
+  needs: [quality, detect-changes, pre-merge-check, pr-review, molecule-tests]
+  if: >-
+    always() &&
+    github.event_name == 'pull_request' &&
+    needs.quality.result == 'success' &&
+    needs.pre-merge-check.result == 'success' &&
+    needs.pr-review.result == 'success' &&
+    (needs.molecule-tests.result == 'success' || needs.molecule-tests.result == 'skipped')
+```
+
+**Gitea Actions limitations (1.26.x):**
+- No `fromJSON()` in matrix context
+- `concurrency` blocks can cause stuck jobs
+- `GITHUB_OUTPUT` for step outputs
+
+## Report
+- **actionlint results**: pass/fail per workflow file, specific errors
+- **dry-run results**: pass/fail per workflow, job dependency issues
+- **Files changed**: if any workflow YAML was modified
+- **Verification**: re-run results after fixes
+
+Do NOT commit — report back to the parent agent.
+
+## Feedback Reporting
+
+When you encounter a concrete issue with a tool, workflow, or process
+that would benefit from further investigation, create a Gitea issue
+in the `oblachno-oss/grm` repo.
+
+### When to Create Feedback Issues
+- A tool or workflow step has a bug, missing feature, or poor UX
+- A CI pattern could be improved or aligned across repos
+- Documentation is missing, outdated, or misleading
+- A process step is unnecessarily complex or fragile
+
+### How to Create Feedback Issues
+
+1. **Deduplicate first**: Use `mcp_call_tool` with server_name "gitea",
+   tool_name "list_issues", with `labels: "feedback"`, `owner: "oblachno-oss"`,
+   `repo: "grm"`. Check if an open issue already covers the same topic.
+   Do NOT create duplicates.
+
+2. **Create the issue**: Use `mcp_call_tool` with server_name "gitea",
+   tool_name "issue_write", method "create_issue", `owner: "oblachno-oss"`,
+   `repo: "grm"`:
+   - **Title**: `[feedback] <category>: <short description>`
+   - **Labels**: `feedback` + one of: `tooling`, `ci-improvement`,
+     `doc-improvement`, `workflow-improvement`
+   - **Body** must include these sections:
+     ```
+     **Context**: What task you were performing, which repo
+     **Tool/Workflow**: The specific tool or workflow step involved
+     **Issue**: What went wrong or could be improved
+     **Reproduction**: Steps to reproduce (if applicable)
+     **Affected files**: File paths and line numbers
+     **Suggested investigation**: What an agent should look into
+     **Reported by**: <subagent profile name>
+     ```
+
+3. **Report back**: Include the issue URL in your report to the parent agent.
+
+### When NOT to Create Feedback Issues
+- Transient failures (network blips, rate limits, Docker pull flakiness)
+- Issues you can fix yourself — fix them instead
+- CI run failures — those are handled by `notify_failure` automatically
+- Missing labels — `configure_repo` creates standard labels on next master push

.devin/skills/testing-and-debugging/SKILL.md

@@ -0,0 +1,71 @@
+# testing-and-debugging
+
+Make targets for testing, debugging, and CI investigation. **Use these
+instead of raw `pytest`, `ruff`, or `molecule` commands.**
+
+## Why Make Targets
+
+Make targets encapsulate the correct venv activation, PYTHONPATH, env
+vars, and flags. Running raw commands bypasses venv activation and
+produces false failures (missing dependencies, wrong Python version).
+
+## Unit Tests
+
+| Task | Command | Notes |
+|------|---------|-------|
+| Run all unit tests | `make test-unit` | Fast, no coverage |
+| Run with coverage | `make pytest-cov` | **Required before push** — enforces 100% |
+| Run single test | `make pytest-cov TEST=tests/test_foo.py::test_bar` | |
+
+## Linting
+
+| Task | Command | Notes |
+|------|---------|-------|
+| Full lint | `make lint-all` | ruff + pyright + bandit + ansible-lint + checkmake + actionlint |
+| Ruff only | `make lint-ruff` | |
+| Type check | `make typecheck` | pyright |
+| Bandit | `make lint-bandit` | Security linter |
+| Workflow lint | `make workflow-check` | actionlint + act_runner dry-run |
+
+## Molecule Tests
+
+| Task | Command | Notes |
+|------|---------|-------|
+| All scenarios | `make molecule` | All 6 scenarios on Ubuntu 22.04 |
+| All platforms | `make molecule-all` | All 6 scenarios on all 4 OSes |
+| Parallel | `make molecule-all-parallel` | MOLECULE_JOBS=4 |
+
+## Pre-Push Verification
+
+**Before pushing any branch:**
+
+```bash
+make pre-push
+```
+
+This runs `lint-all` + `pytest-cov`. The pre-push git hook only
+validates the Vikunja task exists — it does NOT run tests. You must
+run `make pre-push` manually.
+
+## CI Failure Investigation
+
+When investigating a CI failure:
+
+1. **Fetch logs via MCP** — use `mcp_call_tool` with gitea server,
+   `actions_run_read` method, `download_job_log` tool
+2. **Reproduce locally** — use `make pytest-cov` or `make lint-ci`
+   depending on which CI job failed
+3. **Never run raw pytest** — always use the make target
+
+## Virtual Environment
+
+All commands run inside `.venv`. `make` targets handle activation
+automatically. For raw commands (rare), activate first:
+
+```bash
+source activate.sh       # bash/zsh
+source activate.fish     # fish
+source activate.zsh      # zsh
+```
+
+If `.venv` doesn't exist, run `make setup` first.

.gitea/workflows/ci.yml

@@ -23,12 +23,12 @@ jobs:
         run: make setup-image EXTRAS=lint
       - name: Lint all
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           export PATH="$HOME/.local/bin:$PATH"
           make lint-all
       - name: Unit tests with 100% coverage
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           make pytest-cov
       - name: Documentation lint check
         env:
@@ -36,31 +36,31 @@ jobs:
           CI_GITEA_TOKEN: ${{ secrets.CI_GITEA_TOKEN }}
           CI_GITEA_USERNAME: ${{ vars.CI_GITEA_USERNAME }}
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           pip install --upgrade devx \
             --index-url "https://${CI_GITEA_USERNAME}:${CI_GITEA_TOKEN}@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/" \
             --no-deps
           python3 -m devx.ci.lint_docs --root .
       - name: Translation completeness check
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.check_translations --translations src/gitea_runner_manager/translations.json
       - name: Check unit test speed
         env:
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.tools.check_test_speed --max-seconds 4 --max-single-seconds 0.5
       - name: Dependency security scan
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           # Install pip in venv if missing (needed by pip-audit)
           .venv/bin/python -m ensurepip 2>/dev/null || true
           PIPAPI_PYTHON_LOCATION=$PWD/.venv/bin/python \
             pip-audit --desc --skip-editable 2>&1 || true
       - name: Workflow dry-run validation
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           export PATH="$HOME/.local/bin:$PATH"
           # Best-effort: only runs if act_runner is installed
           if command -v act_runner >/dev/null 2>&1; then
@@ -90,7 +90,7 @@ jobs:
           DEVX_VERSION_FILE: src/gitea_runner_manager/__init__.py
           DEVX_TASK_PREFIX: GRM
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           export PATH="$HOME/.local/bin:$PATH"
           python3 -m devx.ci.release --dry-run
 
@@ -116,7 +116,7 @@ jobs:
           PYTHONPATH: src
           DEVX_TASK_PREFIX: GRM
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.classify_changes \
             --base "origin/master" \
             --head "${{ github.event.pull_request.head.sha || github.sha }}" \
@@ -176,7 +176,7 @@ jobs:
           MOLECULE_RUNNERS: ${{ vars.MOLECULE_RUNNERS }}
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.molecule.discover_runners \
             --owner "${{ github.repository_owner }}" \
             --repo "${{ github.event.repository.name }}" \
@@ -202,7 +202,7 @@ jobs:
         run: make setup-image EXTRAS=ci,molecule
       - name: Install Ansible collections
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.tools.setup --skip-install --no-pre-commit --no-tea-login
       - name: Discover assigned test pairs
         env:
@@ -210,7 +210,7 @@ jobs:
           MAX_RUNNERS: ${{ needs.discover-runners.outputs.runner-count }}
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.molecule.distribute_molecule \
             --runner-index "$RUNNER_INDEX" \
             --max-runners "$MAX_RUNNERS" \
@@ -218,7 +218,7 @@ jobs:
       - name: Run molecule tests
         if: env.SKIP != 'true'
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           if [ -z "$TEST_PAIRS" ]; then exit 0; fi
           if ! python3 -c "import docker; docker.from_env().ping()" 2>/dev/null; then
             echo "Docker not available in CI container — skipping molecule tests"
@@ -260,7 +260,7 @@ jobs:
           PYTHONPATH: src
         run: |
           set -euo pipefail
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.pr_review \
             "${{ github.event.number }}" \
             "${{ github.repository }}"
@@ -302,7 +302,7 @@ jobs:
           REPOSITORY: ${{ github.repository }}
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.pr_review \
             "$PR_NUMBER" \
             "$REPOSITORY" \
@@ -322,7 +322,7 @@ jobs:
           REPOSITORY: ${{ github.repository }}
           PR_NUMBER: ${{ github.event.number }}
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.auto_merge \
             "$HEAD_REF" \
             "$PR_TITLE" \

.gitea/workflows/post-merge.yml

@@ -56,7 +56,7 @@ jobs:
         env:
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.detect_release_commit
 
   validate-commit-msg:
@@ -79,7 +79,7 @@ jobs:
           PYTHONPATH: src
           DEVX_TASK_PREFIX: GRM
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           git log -1 --format=%B > commit-msg.txt
           python3 -m devx.ci.validate_commit_msg commit-msg.txt --branch master
           rm -f commit-msg.txt
@@ -114,7 +114,7 @@ jobs:
           DEVX_TASK_PREFIX: GRM
           DEVX_VIKUNJA_PROJECT_ID: 6
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           export PATH="$HOME/.local/bin:$PATH"
           python3 -m devx.ci.release
       - name: Notify on failure
@@ -152,7 +152,7 @@ jobs:
           CI_GITEA_TOKEN: ${{ secrets.CI_GITEA_TOKEN }}
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           export PATH="$HOME/.local/bin:$PATH"
           python3 -m devx.ci.publish \
             "${{ needs.release.outputs.tag }}" \
@@ -191,7 +191,7 @@ jobs:
           CI_GITEA_TOKEN: ${{ secrets.CI_GITEA_TOKEN }}
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.sync_wiki --repo "${{ github.repository }}" --strict
       - name: Notify on failure
         if: failure()
@@ -231,7 +231,7 @@ jobs:
         env:
           PRE_COMMIT_ALLOW_NO_CONFIG: "1"
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.push_badges
       - name: Notify on failure
         if: failure()
@@ -268,7 +268,7 @@ jobs:
           DEVX_TASK_PREFIX: GRM
           DEVX_VIKUNJA_PROJECT_ID: 6
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.post_merge --git-sha "${{ github.sha }}"
       - name: Notify on failure
         if: failure()
@@ -304,7 +304,7 @@ jobs:
           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: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.tools.configure_repo
       - name: Notify on failure
         if: failure()

AGENTS.md

@@ -1,5 +1,19 @@
 # AGENTS.md — Project Conventions for GRM
 
+## Virtual Environment
+
+All Python tools, tests, and scripts run inside a standard `.venv` directory.
+Activate it before running any non-`make` command:
+
+```bash
+source activate.sh       # bash/zsh
+source activate.fish     # fish
+source activate.zsh      # zsh
+```
+
+If `.venv` doesn't exist, run `make setup` first. The `make` targets handle
+venv activation automatically — always prefer `make <target>` over raw commands.
+
 ## Build & Test Commands
 
 ```bash
@@ -419,6 +433,33 @@ Change classification is config-driven via `[tool.devx.classify]` in `pyproject.
 - 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`)
 
+### Container-Level Fix Verification (Mandatory)
+
+**Rule:** Before pushing any fix that modifies container state (CA certs,
+config files, installed packages, daemon restarts), reproduce the exact
+sequence locally with the actual Docker image. Do not push to CI as the
+first test.
+
+This is a hard rule, not a suggestion. CI cycles take 20+ minutes and
+ephemeral staging VMs are destroyed after each run, making interactive
+debugging impossible. A local reproduction takes 30 seconds and catches
+silent failures immediately.
+
+**Procedure:**
+1. `docker pull <actual_image>`
+2. `docker run -d --name <test> ...` and wait for it to start
+3. Run the exact commands from the Ansible task or script
+4. Verify the state change took effect
+5. Clean up: `docker rm -f <test>`
+
+### Verified State Modification (Mandatory)
+
+Ansible tasks that modify container state with `changed_when: false`
+MUST include a post-task verification step that confirms the state
+change took effect. `changed_when: false` suppresses both change
+detection AND failure visibility — a task can silently do nothing and
+report `ok`.
+
 ## Ansible Role Structure
 
 ```
@@ -487,3 +528,86 @@ docs/
 2. If adding a new page, add it to `docs/mapping.json`
 3. Commit and create a PR (standard PR workflow)
 4. On merge, wiki is automatically synced
+
+## Subagent Delegation Policy
+
+Custom subagent profiles are defined in `.devin/agents/` (project-specific)
+and `~/.config/devin/agents/` (global, shared across repos). The agent MUST
+automatically delegate to the appropriate subagent based on the task —
+the user should not need to specify which profile to use.
+
+### Available Profiles
+
+**Global** (shared with infra and devx):
+
+| Profile | Location | Purpose |
+|---------|----------|---------|
+| `pr-reviewer` | `~/.config/devin/agents/` | 13-category PR checklist + quality gates |
+| `release-check` | `~/.config/devin/agents/` | Pre-merge readiness validation |
+
+**grm-specific** (in `.devin/agents/`):
+
+| Profile | Purpose |
+|---------|---------|
+| `ci-investigator` | Investigate CI failures (quality, molecule, release, publish, wiki sync) |
+| `molecule-runner` | Run 7 molecule scenarios across 4 platforms, report pass/fail |
+| `dep-upgrader` | Python + Ansible dependency upgrades with molecule verification |
+| `doc-syncer` | Doc coverage, doc linting, wiki sync for grm docs |
+| `workflow-validator` | actionlint + act_runner dry-run for grm workflows |
+
+### When to Delegate Automatically
+
+| Trigger | Profile | Mode |
+|---------|---------|------|
+| CI run failure (quality, molecule-tests, release, publish, sync-wiki) | `ci-investigator` | Background |
+| PR ready for review | `pr-reviewer` | Foreground |
+| Molecule tests need to run | `molecule-runner` | Background |
+| Dependency upgrade requested | `dep-upgrader` | Background |
+| Doc coverage failure or wiki sync issue | `doc-syncer` | Background |
+| Workflow YAML modified or validation needed | `workflow-validator` | Background |
+| Branch ready for merge | `release-check` | Foreground |
+
+### Delegation Rules
+
+1. **Auto-select the profile.** Do not ask the user which profile to use.
+2. **Background by default, foreground when blocking.**
+3. **Provide full context in the prompt** — subagents don't inherit conversation history.
+4. **One subagent per concern.** Chain: investigate → fix in main session → review.
+5. **Don't delegate trivial work** (<30s, <50 lines of context).
+6. **Compact after subagent returns.**
+7. **Never skip delegation to save time** — it keeps main context small.
+
+
+## Feedback Issue Handling
+
+Subagents create Gitea issues in the current repo when they encounter
+tool, workflow, or process issues that warrant follow-up. These issues
+use the `feedback` label plus a category label (`tooling`,
+`ci-improvement`, `doc-improvement`, `workflow-improvement`).
+
+Standard labels are created automatically by `configure_repo` (runs in
+post-merge on every master push). If a label does not exist yet, the
+subagent's issue creation will still succeed — labels can be added
+afterwards.
+
+### When a Subagent Reports a Feedback Issue URL
+
+1. **Acknowledge it** in your response to the user — mention the issue URL
+2. **Do NOT close or modify** the issue — it is for follow-up work
+3. **Do NOT create a PR** to address it unless the user explicitly asks
+4. If the user asks to address feedback, spawn a subagent to investigate
+   the issue and implement a fix
+
+### Creating Feedback Issues Manually
+
+As the parent agent, you can also create feedback issues directly using
+the Gitea MCP (`issue_write` with `create_issue` method). Follow the
+same format as subagents:
+
+- Title: `[feedback] <category>: <short description>`
+- Labels: `feedback` + category label
+- Body: include context, tool/workflow, issue, reproduction, affected
+  files, suggested investigation, and "Reported by: parent agent"
+
+Always deduplicate first via `list_issues` with `labels: "feedback"`.
+

CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to this project will be documented in this file.
 
+## [0.14.1] - 2026-07-01
+
+### Refactor
+
+- Align venv management to devx.mak targets
+
+## [0.14.0] - 2026-07-01
+
+### Features
+
+- Bump devx to v0.30.0
+
 ## [0.13.0] - 2026-07-01
 
 ### Features

Makefile

@@ -25,6 +25,18 @@ DEVX_LINT_PATHS := src/ scripts/ tests/
 DEVX_MAK := $(shell $(BIN)/python -c \
 	"from pathlib import Path; import devx; print(Path(devx.__file__).parent / 'make' / 'devx.mak')" \
 	2>/dev/null)
+# Fallback: when the venv doesn't exist yet, try system python3 or /opt/venv.
+# In CI, /opt/venv has devx pre-installed; locally, devx may be in system python.
+ifeq ($(strip $(DEVX_MAK)),)
+DEVX_MAK := $(shell python3 -c \
+	"from pathlib import Path; import devx; print(Path(devx.__file__).parent / 'make' / 'devx.mak')" \
+	2>/dev/null)
+endif
+ifeq ($(strip $(DEVX_MAK)),)
+DEVX_MAK := $(shell /opt/venv/bin/python -c \
+	"from pathlib import Path; import devx; print(Path(devx.__file__).parent / 'make' / 'devx.mak')" \
+	2>/dev/null)
+endif
 -include $(DEVX_MAK)
 
 # Full setup for local development (all deps, tools, collections, hooks)
@@ -77,28 +89,14 @@ setup-image:
 		pip install -e .$(if $(EXTRAS),[$(EXTRAS)],); \
 	else echo "[setup-image] /opt/venv not found — falling back to setup-ci"; $(MAKE) setup-ci; fi
 
-# Helper: run pip install with Gitea registry configured
-# Usage: $(PIP_INSTALL) install -e '.[ci,lint]'
-PIP_INSTALL := if [ -z "$$CI_GITEA_TOKEN" ]; then . ./.env 2>/dev/null; fi; \
-	CI_GITEA_TOKEN="$$CI_GITEA_TOKEN"; \
-	if [ -n "$$CI_GITEA_TOKEN" ]; then export PIP_EXTRA_INDEX_URL="https://$$CI_GITEA_USERNAME:$$CI_GITEA_TOKEN@git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple/"; fi; \
-	$(BIN)/pip
-
-$(VENV)/bin/activate:
-	@python3 -c "import sys; v=sys.version_info; assert v >= (3, 12), f'Python 3.12+ required, found {v.major}.{v.minor}'; print(f'Python {v.major}.{v.minor}.{v.micro} OK')"
-	$(PYTHON) -m venv $(VENV)
-	$(BIN)/pip install --upgrade pip setuptools wheel
-
-.env:
-	@if [ ! -f .env ]; then \
-		cp .env.example .env; \
-		echo "Created .env from .env.example — please edit it with your credentials."; \
-	fi
-
-activate-scripts: $(VENV)/bin/activate
-	@test -f activate.sh || (echo '#!/usr/bin/env bash' > activate.sh && echo 'source "$$(cd "$$(dirname "$${BASH_SOURCE[0]}")" && pwd)/.venv/bin/activate"' >> activate.sh && chmod +x activate.sh)
-	@test -f activate.fish || (echo '#!/usr/bin/env fish' > activate.fish && echo 'set -l script_dir (dirname (status --current-filename))' >> activate.fish && echo 'source "$$script_dir/.venv/bin/activate.fish"' >> activate.fish && chmod +x activate.fish)
-	@test -f activate.zsh || (echo '#!/usr/bin/env zsh' > activate.zsh && echo '0="$${ZERO:-$${0:#$$ZSH_ARGZERO}}"' >> activate.zsh && echo '0="$${$${(M)0:#/*}:-$$PWD/$$0}"' >> activate.zsh && echo 'source "$${0:A:h}/.venv/bin/activate"' >> activate.zsh && chmod +x activate.zsh)
+# venv, .env, activate-scripts, and PIP_INSTALL are provided by devx.mak
+# (devx-venv, devx-env, devx-activate-scripts, DEVX_PIP_INSTALL)
+# Aliases for convenience and backward compatibility:
+.PHONY: venv activate-scripts
+PIP_INSTALL := $(DEVX_PIP_INSTALL)
+venv: devx-venv
+.env: devx-env
+activate-scripts: devx-activate-scripts
 
 install:
 	@if [ -z "$(HOST)" ]; then echo "HOST is required. Example: make install HOST=192.168.1.10"; exit 1; fi

README.md

@@ -8,12 +8,12 @@ Each runner runs in an isolated **rootless Docker** environment under a dedicate
 
 [![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/b8aa4072d2669b513080d0e40446b1da5fead98e/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/b8aa4072d2669b513080d0e40446b1da5fead98e/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/b8aa4072d2669b513080d0e40446b1da5fead98e/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki)
-[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/b8aa4072d2669b513080d0e40446b1da5fead98e/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/b8aa4072d2669b513080d0e40446b1da5fead98e/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases)
-[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/b8aa4072d2669b513080d0e40446b1da5fead98e/python.svg)](https://www.python.org/downloads/)
+[![Coverage](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki)
+[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases)
+[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/python.svg)](https://www.python.org/downloads/)
 
 ## Why GRM?
 

docs/index.md

@@ -8,12 +8,12 @@ Each runner runs in an isolated **rootless Docker** environment under a dedicate
 
 [![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/b8aa4072d2669b513080d0e40446b1da5fead98e/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/b8aa4072d2669b513080d0e40446b1da5fead98e/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/b8aa4072d2669b513080d0e40446b1da5fead98e/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki)
-[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/b8aa4072d2669b513080d0e40446b1da5fead98e/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
-[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/b8aa4072d2669b513080d0e40446b1da5fead98e/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases)
-[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/b8aa4072d2669b513080d0e40446b1da5fead98e/python.svg)](https://www.python.org/downloads/)
+[![Coverage](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/wiki)
+[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/actions)
+[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/releases)
+[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/grm/raw/commit/627be1f191b334de9f4f83426ae3cbe6810ff69a/python.svg)](https://www.python.org/downloads/)
 
 ## Overview
 

pyproject.toml

@@ -34,7 +34,7 @@ ci = [
     "build==1.5.0",
     "twine==6.2.0",
     # Reusable CI/CD and dev tools (auto-merge, pr-review, pre-push checks, etc.)
-    "devx==0.29.1",
+    "devx==0.32.0",
 ]
 # Lint and type-checking tools (quality job)
 lint = [
@@ -54,7 +54,7 @@ molecule = [
 dev = [
     "gitea-runner-manager[ci,lint,molecule]",
     # Reusable CI/CD and dev tools (pre-push hooks, create-task, create-pr)
-    "devx==0.29.1",
+    "devx==0.32.0",
     # Non-Python dev dependency: checkmake (Makefile linter)
     # Install via: go install github.com/checkmake/checkmake/cmd/checkmake@latest
 ]

src/gitea_runner_manager/__init__.py

@@ -1,3 +1,3 @@
 """Gitea Runner Manager — lean CLI for managing Gitea Actions runners."""
 
-__version__ = "0.13.0"
+__version__ = "0.14.1"