release: v0.30.0 [skip ci]

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

@@ -0,0 +1,193 @@
+---
+name: ci-investigator
+description: Investigates CI failures in the devx repo by fetching job logs via Gitea MCP, identifying root cause across quality/release/publish/wiki-sync/image-build 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 devx repo.
+
+## Working Directory
+
+The devx repo is at `/home/emo/dev/ideas/oblachno/devx`. Always `cd` there first:
+```bash
+cd /home/emo/dev/ideas/oblachno/devx
+```
+
+## CI Job Dependency Graph
+
+devx has 3 workflows:
+
+**ci.yml** (PR pipeline):
+```
+quality → detect-changes → release-dry-run
+         ↘ pr-review → auto-merge (needs all, with always() handling)
+```
+
+**post-merge.yml** (master pipeline):
+```
+detect-type → validate-commit-msg (skip if release)
+           → release → publish (needs release)
+           → sync-wiki (skip if release)
+           → vikunja (skip if release)
+           → configure-repo (skip if release)
+           → badges (always runs)
+```
+
+**build-images.yml** (master pipeline):
+```
+detect-type → build-and-push → cleanup (always if build succeeds)
+```
+
+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: "devx"`, `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 — subsequent errors are cascading.
+
+### Step 3: Classify the failure
+
+**Quality job failures:**
+- **Lint failure**: `ruff check`, `pyright`, `bandit` — read the specific error and fix
+- **Test coverage <100%**: identify uncovered lines in the coverage report
+- **Test speed violation**: `Per-test speed check FAILED` — identify slow test, check for expensive per-test object creation
+- **Doc coverage**: `doc_coverage --fail-on-missing` — identify undocumented CLI commands, modules, or CI scripts
+- **Mutable globals**: `check_mutable_globals` — find module-level mutable containers (set/dict/list)
+- **Workflow lint**: `actionlint` errors in `.gitea/workflows/*.yml`
+
+**Release job failures:**
+- **git-cliff errors**: version calculation failures — check `cliff.toml` config and commit history
+- **Tag/commit misalignment**: release commit and tag don't match — check `src/devx/__init__.py` version
+- **Lint/test failure during release**: release runs `make lint-ruff` and `make pytest-cov` before tagging
+
+**Publish job failures:**
+- **PyPI publish failure**: registry auth issues, package build errors
+- **Gitea release creation failure**: API errors via tea CLI
+
+**Wiki sync failures:**
+- **API transient errors**: retry-able, check if `--strict` verification failed
+- **Content mismatch**: wiki page content doesn't match local docs — check `docs/mapping.json`
+- **Stale pages**: wiki has pages not in mapping.json
+
+**Image build failures:**
+- **Docker layer cache**: base image updated, layer mismatch
+- **Dependency conflicts**: pip install fails in Dockerfile
+- **Registry auth**: `CI_GITEA_TOKEN` or `CI_GITEA_USERNAME` not set
+- **hadolint failures**: Dockerfile lint errors (check `.hadolint.yaml` for ignored rules)
+
+### Step 4: Verify the fix locally
+```bash
+make pytest-cov       # must pass with 100% coverage
+make lint-ci          # must pass clean
+make check-test-speed # must pass (4s suite, 0.5s per-test)
+```
+
+For workflow issues:
+```bash
+make workflow-check   # actionlint + act_runner dry-run
+```
+
+For Docker image issues:
+```bash
+make lint-dockerfiles          # hadolint
+make build-images-dry-run      # dry-run build
+```
+
+For doc coverage issues:
+```bash
+python3 -m devx.ci.doc_coverage --fail-on-missing
+python3 -m devx.ci.lint_docs --root .
+```
+
+### Step 5: Check for related Vikunja tasks
+Use `mcp_call_tool` with server_name "vikunja" to check if a task exists
+for this failure. 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/devx` 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: "devx"`. 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: "devx"`:
+   - **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,141 @@
+---
+name: dep-upgrader
+description: Researches and applies Python dependency upgrades in pyproject.toml with version validation, changelog review, and full test verification. Knows the dep documentation comment requirement.
+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-ci)
+    - Exec(make lint-all)
+    - 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(git diff *)
+    - Exec(git log *)
+---
+
+You are a dependency upgrade specialist for the devx repo.
+
+## Working Directory
+
+The devx repo is at `/home/emo/dev/ideas/oblachno/devx`. Always `cd` there first.
+
+## Dependency Reference Locations
+
+- **Primary**: `pyproject.toml` — `[project] dependencies` and `[project.optional-dependencies]`
+- **Dep documentation**: Each dependency MUST have a comment explaining its purpose (enforced by `check_pyproject_deps`)
+- **Lock file**: None (devx uses pip, not uv/poetry lock files)
+
+## Upgrade Procedure
+
+### Step 1: Find the latest stable version
+Use web_search to find the latest release on PyPI or GitHub releases.
+
+Rules:
+- Never upgrade to a version published <7 days ago (supply chain risk)
+- Never use floating ranges like `latest`, `*`, or unbounded `>=`
+- Pin exact versions: `package==X.Y.Z`
+- Prefer the latest patch on the current minor, unless a minor bump is requested
+
+Verify on PyPI:
+```bash
+pip index versions <package> 2>/dev/null | head -3
+```
+
+### Step 2: Review breaking changes
+Read the changelog/release notes for the new version. Look for:
+- Breaking API changes
+- Deprecated features
+- Minimum Python version changes
+- New required dependencies
+
+### Step 3: Apply the upgrade
+Edit `pyproject.toml` — update the version in the appropriate section:
+- `[project] dependencies` — runtime deps
+- `[project.optional-dependencies] dev` — dev tools (ruff, pyright, bandit, etc.)
+- `[project.optional-dependencies] ci` — CI tools
+- `[project.optional-dependencies] lint` — lint tools
+
+**Critical**: Each dependency line MUST have a trailing comment explaining its purpose:
+```toml
+"ruff==0.12.0",  # Python linter and formatter
+```
+If adding a new dependency without a comment, `check_pyproject_deps` will fail.
+
+### Step 4: Install and verify
+```bash
+pip install -e .[dev]    # reinstall with new deps
+make pytest-cov          # 100% coverage required
+make lint-all            # ruff + pyright + bandit + actionlint + hadolint
+python3 -m devx.tools.check_pyproject_deps  # verify dep docs
+python3 -m devx.tools.check_test_speed --max-seconds 4 --max-single-seconds 0.5
+```
+
+All must pass. If `check_pyproject_deps` fails, add the missing comment.
+
+### Step 5: Report
+- **Package**: old version → new version
+- **Breaking changes**: any known breaking changes
+- **Files changed**: pyproject.toml (and any source files if API changed)
+- **Test results**: pytest-cov, lint-all, check-pyproject-deps, test-speed
+- **Verification**: PyPI 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/devx` 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: "devx"`. 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: "devx"`:
+   - **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-sync-specialist/AGENT.md

@@ -0,0 +1,161 @@
+---
+name: doc-sync-specialist
+description: Handles documentation coverage gaps, doc structure linting, and wiki sync failures. Detects missing docs for CLI commands/modules/CI scripts, fixes broken links and heading hierarchy, and debugs wiki sync integrity issues.
+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 devx repo.
+
+## Working Directory
+
+The devx repo is at `/home/emo/dev/ideas/oblachno/devx`. Always `cd` there first.
+
+## Documentation Structure
+
+```
+docs/
+├── index.md              # Wiki homepage
+├── mapping.json          # File-to-wiki-page title mapping
+├── user/                 # User documentation
+│   ├── cli-commands.md
+│   ├── getting-started.md
+│   └── ...
+└── tech/                 # Technical documentation
+    ├── architecture.md
+    ├── ci-cd-workflow.md
+    └── ...
+```
+
+## Key Tools
+
+- `devx.ci.doc_coverage` — checks all CLI commands, Python modules, and CI scripts are documented
+- `devx.ci.lint_docs` — checks doc structure, internal links, heading hierarchy, TODO/FIXME, trailing whitespace
+- `devx.ci.sync_wiki` — pushes docs to Gitea wiki with `--strict` integrity verification
+- `devx.tools.check_agent_docs` — validates docs for stale file references
+
+## Procedure
+
+### Step 1: Check documentation coverage
+```bash
+python3 -m devx.ci.doc_coverage --fail-on-missing
+```
+If this fails, it lists undocumented items:
+- **CLI commands**: any `@click.command()` or `@click.group()` without a docs entry
+- **Python modules**: any `src/devx/*.py` without architecture documentation
+- **CI scripts**: any `src/devx/ci/*.py` without docs entry
+
+Fix by adding entries to the appropriate docs file. Cross-reference with
+`docs/user/cli-commands.md` for CLI commands and `docs/tech/architecture.md`
+for modules.
+
+### Step 2: Lint documentation structure
+```bash
+python3 -m devx.ci.lint_docs --root .
+```
+Common issues:
+- **Broken internal links**: `[text](page.md)` where `page.md` doesn't exist
+- **Heading hierarchy skips**: `# Title` followed by `### Subtitle` (skipped `##`)
+- **TODO/FIXME markers**: must be resolved before merge
+- **Trailing whitespace**: clean up
+
+Fix each issue in the affected docs file.
+
+### Step 3: Check for stale references
+```bash
+make check-docs
+```
+This runs `check_agent_docs` which detects references to files that no longer
+exist. If a script/module was renamed or deleted, update all doc references.
+
+### Step 4: Verify wiki sync (if investigating a sync failure)
+```bash
+python3 -m devx.ci.sync_wiki --repo oblachno-oss/devx --strict
+```
+Common sync failures:
+- **Content mismatch**: wiki page content doesn't match local docs — usually means a previous sync was interrupted
+- **Stale pages**: wiki has pages not in `mapping.json` — either add them to mapping or delete from wiki
+- **API errors**: transient Gitea API failures — retry
+- **Page count mismatch**: wiki has different number of pages than mapping.json
+
+Check `docs/mapping.json` — every docs file should have a mapping entry:
+```json
+{
+  "user/cli-commands.md": "CLI-Commands",
+  "tech/architecture.md": "Architecture"
+}
+```
+
+If adding a new docs file, add it to `mapping.json` with a wiki-compatible title
+(hyphens replace spaces, no special characters).
+
+### Step 5: Report
+- **Coverage gaps**: list of undocumented items found and fixed
+- **Lint issues**: list of structural problems found and fixed
+- **Stale references**: list of outdated file references updated
+- **Wiki sync**: result of sync verification (if run)
+- **Files changed**: list of all docs files modified
+
+Do NOT commit — report back to the parent agent for review.
+
+## 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/devx` 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: "devx"`. 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: "devx"`:
+   - **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/docker-image-builder/AGENT.md

@@ -0,0 +1,179 @@
+---
+name: docker-image-builder
+description: Handles Docker image build, push, and cleanup for the 3-tier runner images (ci-base, ci-quality, ci-full). Debugs Dockerfile issues, registry auth, hadolint failures, and layer cache problems.
+model: glm-5.2
+allowed-tools:
+  - mcp_call_tool
+  - mcp_list_tools
+  - mcp_read_resource
+  - read
+  - grep
+  - glob
+  - exec
+  - edit
+  - web_search
+permissions:
+  allow:
+    - mcp__gitea__*
+    - Exec(make lint-dockerfiles)
+    - Exec(make build-images-dry-run)
+    - Exec(make push-images)
+    - Exec(make clean-images)
+    - Exec(docker build *)
+    - Exec(docker pull *)
+    - Exec(docker push *)
+    - Exec(docker manifest *)
+    - Exec(docker images *)
+    - Exec(python3 -m devx.tools.build_image *)
+    - Exec(python3 -m devx.tools.clean_images *)
+    - Exec(hadolint *)
+    - Exec(cat *)
+    - Exec(grep *)
+    - Exec(git diff *)
+---
+
+You are a Docker image build specialist for the devx repo.
+
+## Working Directory
+
+The devx repo is at `/home/emo/dev/ideas/oblachno/devx`. Always `cd` there first.
+
+## Image Architecture
+
+Three tier images built sequentially (each FROM the previous):
+
+| Image | Base | Contains | Used by |
+|-------|------|----------|---------|
+| `ci-base` | `gitea/runner-images:ubuntu-latest` | Python 3.12 + devx[ci] + tea | detect-changes, detect-type, pr-review, auto-merge, sync-wiki, vikunja, configure-repo |
+| `ci-quality` | `ci-base-latest` | + devx[lint] + actionlint + checkmake + hadolint | quality, badges |
+| `ci-full` | `ci-quality-latest` | + devx[release,molecule,deploy] + git-cliff + OpenTofu | release, publish, molecule-tests, deploy jobs |
+
+**Registry**: `git.oblachno.oblachno.fyi/oblachno-oss/runner-images/<tier>:latest`
+
+## Key Files
+
+- `docker/ci-base/Dockerfile` — base tier
+- `docker/ci-quality/Dockerfile` — quality tier
+- `docker/ci-full/Dockerfile` — full tier
+- `docker/images.json` — build manifest (image definitions, tags, push targets)
+- `.hadolint.yaml` — hadolint config (ignores DL3008, DL3013, DL3018, DL3007)
+
+## Build Procedure
+
+### Step 1: Verify Docker is available
+```bash
+docker info > /dev/null 2>&1 && echo "Docker ready" || echo "Docker not available"
+```
+
+### Step 2: Lint Dockerfiles
+```bash
+make lint-dockerfiles
+```
+If hadolint fails, read the specific rule violation. Check `.hadolint.yaml`
+for already-ignored rules before adding new ignores.
+
+### Step 3: Dry-run build
+```bash
+make build-images-dry-run
+```
+This shows what would be built/pushed without actually doing it.
+Verify the image names, tags, and registry paths are correct.
+
+### Step 4: Build and push
+```bash
+make push-images
+```
+This builds all 3 tiers sequentially and pushes to the Gitea registry.
+
+If only one tier needs rebuilding:
+```bash
+python3 -m devx.tools.build_image \
+  --dockerfile docker/ci-quality/Dockerfile \
+  --name oblachno-oss/runner-images/ci-quality \
+  --tag latest \
+  --registry git.oblachno.oblachno.fyi \
+  --push
+```
+
+### Step 5: Clean up old versions
+```bash
+make clean-images
+```
+Keeps last 2 versions + latest. Uses Gitea API via `clean_images.py`.
+
+## Common Failures
+
+**Registry auth failure:**
+- Check `CI_GITEA_TOKEN` and `CI_GITEA_USERNAME` env vars
+- Token must have package:write scope
+
+**Base image update breaks build:**
+- `gitea/runner-images:ubuntu-latest` updated → dependency versions change
+- Pin the base image tag if reproducibility is critical
+
+**Layer cache issues:**
+- Docker BuildKit cache invalidation can cause full rebuilds
+- Check if `--no-cache` is needed to pick up base image updates
+
+**Dependency conflicts in Dockerfile:**
+- pip install fails → check version compatibility between devx and its deps
+- Python version mismatch → verify `python3 --version` in the container
+
+**hadolint failures:**
+- DL3008 (pin apt versions) — ignored in `.hadolint.yaml`
+- DL3013 (pin pip versions) — ignored (we use `==` in pyproject.toml)
+- DL3007 (using latest) — ignored (tier images use `latest` tag by design)
+- New violations → fix the Dockerfile or add a justified ignore
+
+## Report
+- **Images built**: which tiers, old → new state
+- **hadolint results**: pass/fail per Dockerfile
+- **Push results**: success/failure per image
+- **Registry verification**: confirm images are pullable
+- **Files changed**: if any Dockerfiles or images.json were modified
+
+Do NOT commit or push git changes — 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/devx` 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: "devx"`. 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: "devx"`:
+   - **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,163 @@
+---
+name: workflow-validator
+description: Validates Gitea Actions workflow YAML files using actionlint and act_runner dry-run. Fixes syntax errors, invalid expressions, job dependency issues, and Docker image selection 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 devx repo.
+
+## Working Directory
+
+The devx repo is at `/home/emo/dev/ideas/oblachno/devx`. Always `cd` there first.
+
+## Key Files
+
+- `.gitea/workflows/ci.yml` — PR pipeline (quality, detect-changes, release-dry-run, pr-review, auto-merge)
+- `.gitea/workflows/post-merge.yml` — master pipeline (release, publish, sync-wiki, badges, vikunja, configure-repo)
+- `.gitea/workflows/build-images.yml` — Docker image build pipeline
+- `.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
+```
+actionlint catches:
+- **Syntax errors**: invalid YAML, unknown keys, type mismatches
+- **Invalid expressions**: `${{ }}` syntax errors, undefined variables
+- **Shellcheck issues**: inline shell scripts in `run:` steps
+- **Unknown actions**: references to actions that don't exist
+- **Job dependency issues**: `needs:` referencing non-existent jobs
+
+If actionlint fails, read the specific error:
+- `invalid property`: check expression syntax
+- `undefined variable`: check job/step context
+- `unknown key`: check Gitea Actions docs for valid keys
+
+### Step 3: Dry-run with act_runner
+```bash
+make workflow-dryrun
+```
+act_runner validates:
+- **Job dependencies**: step ordering, `needs:` chains
+- **Docker image selection**: `container:` image references
+- **Step execution order**: sequential vs parallel
+- **Matrix expansion**: matrix values are valid
+
+If dry-run fails:
+- **Image not found**: check `container:` image exists in registry
+- **Job stuck in waiting**: check for circular `needs:` dependencies
+- **Step not found**: check `uses:` action references
+
+### Step 4: Full check
+```bash
+make workflow-check  # runs both workflow-lint and workflow-dryrun
+```
+
+## Common Issues
+
+**`always()` in auto-merge:**
+When `auto-merge` depends on a job that can be skipped (e.g. `molecule-tests`),
+the `if:` condition MUST include `always() &&` at the start. Without it,
+Gitea Actions skips `auto-merge` when any dependency is skipped, even if
+the condition explicitly allows `result == 'skipped'`.
+
+```yaml
+auto-merge:
+  needs: [quality, detect-changes, pr-review, molecule-tests]
+  if: >-
+    always() &&
+    github.event_name == 'pull_request' &&
+    needs.quality.result == 'success' &&
+    (needs.molecule-tests.result == 'success' || needs.molecule-tests.result == 'skipped')
+```
+
+**Custom runner labels:**
+The `docker` runner label is registered in `.gitea/actionlint.yaml`.
+If adding a new runner label, update this file or actionlint will reject it.
+
+**Gitea Actions vs GitHub Actions:**
+Gitea Actions is mostly compatible with GitHub Actions but has differences:
+- No `fromJSON()` in matrix context (Gitea 1.26.x)
+- `concurrency` blocks can cause jobs to get stuck (Gitea 1.26.2 bug)
+- `environment` approval works differently
+- `GITHUB_OUTPUT` is used for step outputs (same as GitHub)
+
+## 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/devx` 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: "devx"`. 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: "devx"`:
+   - **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

.gitea/workflows/ci.yml

@@ -19,47 +19,47 @@ jobs:
         run: make setup-image
       - 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: 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: Documentation coverage check
         env:
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.doc_coverage --fail-on-missing
       - name: Documentation lint check
         env:
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.lint_docs --root .
       - name: Translation completeness check
         env:
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           python3 -m devx.ci.check_translations
       - 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
@@ -88,7 +88,7 @@ jobs:
         env:
           PYTHONPATH: src
         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 }}" \
@@ -115,7 +115,7 @@ jobs:
         env:
           PYTHONPATH: src
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
           export PATH="$HOME/.local/bin:$PATH"
           python3 -m devx.ci.release --dry-run
 
@@ -137,7 +137,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 }}"
@@ -173,7 +173,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" \
@@ -192,7 +192,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

@@ -51,7 +51,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:
@@ -73,7 +73,7 @@ jobs:
         env:
           PYTHONPATH: src
         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
@@ -107,7 +107,7 @@ jobs:
         env:
           PYTHONPATH: src
         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
@@ -146,7 +146,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 }}" "${{ github.repository }}" --auto-login
       - name: Notify on failure
@@ -184,7 +184,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()
@@ -225,7 +225,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()
@@ -262,7 +262,7 @@ jobs:
           DEVX_VIKUNJA_PROJECT_ID: "8"
           PYTHONPATH: src
         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()
@@ -295,9 +295,11 @@ jobs:
         env:
           CI_GITEA_TOKEN: ${{ secrets.CI_GITEA_TOKEN }}
           PYTHONPATH: src
+          DEVX_REPO_NAME: devx
+          DEVX_REPO_OWNER: oblachno-oss
         run: |
-          . .venv/bin/activate
+          . .venv/bin/activate 2>/dev/null || true
-          python3 -m devx.tools.configure_repo --repo devx --owner oblachno-oss
+          python3 -m devx.tools.configure_repo
       - name: Notify on failure
         if: failure()
         env:

AGENTS.md

@@ -52,14 +52,14 @@ src/devx/
 ├── gitea_cli.py         # TeaCLI — wrapper around tea CLI with JSON parsing
 ├── i18n.py              # Translation system (gettext-based, translations.json)
 ├── exceptions.py        # Custom exception types
-├── translations.json    # Translation strings (en, bg)
+├── translations.json    # Translation strings (en, bg, de, pl, ru, zh)
 ├── ci/                  # CI/CD automation modules (run by workflows)
 │   ├── release.py       # Automated versioning, tagging, changelog
 │   ├── publish.py       # Build and publish to Gitea PyPI registry (--skip-build for non-Python repos)
 │   ├── auto_merge.py    # Squash-merge PRs with task ID validation
 │   ├── check_auto_merge_ready.py  # Pre-merge validation gate (branch, PR title, Vikunja, behind-master)
 │   ├── _shared.py      # Shared utilities (get_latest_tag)
-│   ├── classify_changes.py  # User-facing vs workflow-only change detection
+│   ├── classify_changes.py  # User-facing vs infrastructure change detection
 │   ├── detect_release_commit.py  # Detect release commits on master
 │   ├── validate_commit_msg.py    # Conventional commit validation
 │   ├── pr_review.py     # Automated PR review + manual reviews (--event, --body, --checklist-confirmed)
@@ -84,21 +84,24 @@ src/devx/
 │   ├── check_pyproject_deps.py   # Validate pyproject.toml deps have documentation comments
 │   ├── check_test_coverage.py    # Ensure changed files have corresponding tests (configurable rules)
 │   ├── check_agent_docs.py       # Validate docs for stale file references (configurable patterns)
+│   ├── check_config.py       # Validate pyproject.toml [tool.devx] config
 │   ├── configure_repo.py    # Branch protection and label setup
 │   ├── generate_badges.py   # Badge SVG generation
+│   ├── generate_cliff_config.py  # Generate git-cliff config (cliff.toml)
 │   ├── create_task.py       # Create Vikunja tasks
 │   ├── create_pr.py         # Create PRs with auto-derived title from Vikunja
 │   ├── pr_status.py         # Check CI status for a PR/commit (--wait polls)
 │   ├── pr_logs.py           # Fetch logs for failed CI jobs
 │   ├── pr_label.py          # Add labels to PRs (idempotent)
-│   ├── rebase.py            # Rebase current branch onto origin/master + force-push
+│   ├── pre_push_check.py    # Validate Vikunja task existence before push
-│   └── pr_rebase.py         # Rebase a PR's head branch via Gitea API (server-side)
+│   └── _shared.py           # Shared tool utilities
 ├── opentofu.py          # OpenTofu output helpers (get_tofu_output, get_tofu_vm_ip, get_tofu_vm_field)
 └── molecule/            # Optional molecule testing helpers (for Ansible projects)
     ├── discover_runners.py    # Dynamic Gitea runner discovery
     ├── distribute_molecule.py # Distribute molecule scenarios across runners (LPT scheduling, --roles-root for multi-role)
     ├── molecule_ci_guard.py   # Run molecule with cross-runner fail-fast (--roles-root)
     ├── molecule_all.py        # Run all molecule scenarios locally
+    ├── start_docker.py        # Ensure Docker daemon is running for molecule tests
     └── platforms.py           # Supported molecule platforms
 ```
 
@@ -183,12 +186,6 @@ the PR. Then add the `ready-to-merge` label. The auto-merge workflow will:
 5. The post-merge workflow marks the Vikunja task as done
 6. The release workflow automatically versions, tags, and publishes
 
-**If the branch is behind master** (another PR merged first), auto-merge
-automatically rebases the PR's head branch via the Gitea API
-(`POST /pulls/{index}/update?style=rebase`). This triggers a new CI run.
-The next auto-merge attempt will find the branch up-to-date and merge
-successfully. No manual intervention needed.
-
 > **IMPORTANT**: Never manually merge PRs via the API. Always use the auto-merge
 > workflow by adding the `ready-to-merge` label.
 
@@ -372,7 +369,7 @@ devx uses environment variables with `.env` file fallback for configuration.
 | `DEVX_REPO_NAME` | **(none — must be set)** | Repository name (or `owner/repo`) |
 | `DEVX_TASK_PREFIX` | `DEVX` | Task ID prefix (GRM, OBL-INFRA, etc.) |
 | `DEVX_VIKUNJA_PROJECT_ID` | `6` | Vikunja project ID |
-| `DEVX_LANG` | `en` | Language for i18n (en, bg) |
+| `DEVX_LANG` | `en` | Language for i18n (en, bg, de, pl, ru, zh) |
 | `CI_GITEA_TOKEN` | (from .env) | Gitea API token |
 | `VIKUNJA_TOKEN` | (from .env) | Vikunja API token |
 
@@ -417,8 +414,6 @@ projects.
 | `devx-pr-logs` | Fetch logs for failed CI jobs (`PR=`, `JOB=`, `TAIL=`) |
 | `devx-pr-label` | Add a label to a PR (`PR=`, `LABEL=ready-to-merge`) |
 | `devx-pr-review` | Post a review on a PR (`PR=`, `EVENT=`, `BODY=`, `CHECKLIST=`) |
-| `devx-rebase` | Rebase current branch onto origin/master + force-push (`NO_PUSH=1` for local only) |
-| `devx-pr-rebase` | Rebase a PR's head branch via Gitea API — server-side, no local git needed (`PR=`) |
 | `devx-check-config` | Validate devx configuration |
 | `devx-configure-gitea-pypi` | Configure Gitea private PyPI registry |
 | `devx-env` | Create .env from .env.example |
@@ -526,3 +521,86 @@ create-task: devx-create-task
 - Line length: 120 chars
 - Secrets are passed via environment variables, never on the command line
 - All user-facing strings wrapped in `_()` for i18n
+
+## 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 grm):
+
+| Profile | Location | Purpose |
+|---------|----------|---------|
+| `pr-reviewer` | `~/.config/devin/agents/` | 13-category PR checklist + quality gates |
+| `release-check` | `~/.config/devin/agents/` | Pre-merge readiness validation |
+
+**devx-specific** (in `.devin/agents/`):
+
+| Profile | Purpose |
+|---------|---------|
+| `ci-investigator` | Investigate CI failures (quality, release, publish, wiki sync, image build) |
+| `dep-upgrader` | Python dependency upgrades in pyproject.toml with dep-doc validation |
+| `docker-image-builder` | Build/push/cleanup 3-tier runner images (ci-base, ci-quality, ci-full) |
+| `doc-sync-specialist` | Doc coverage, doc linting, wiki sync integrity |
+| `workflow-validator` | actionlint + act_runner dry-run validation |
+
+### When to Delegate Automatically
+
+| Trigger | Profile | Mode |
+|---------|---------|------|
+| CI run failure (quality, release, publish, sync-wiki, build-images) | `ci-investigator` | Background |
+| PR ready for review | `pr-reviewer` | Foreground |
+| Dependency upgrade requested | `dep-upgrader` | Background |
+| Docker image build/push needed | `docker-image-builder` | Background |
+| Doc coverage failure or wiki sync issue | `doc-sync-specialist` | 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,12 @@
 
 All notable changes to this project will be documented in this file.
 
+## [0.30.0] - 2026-07-01
+
+### Features
+
+- Add standard label creation to configure_repo
+
 ## [0.29.1] - 2026-07-01
 
 ### Bug Fixes

README.md

@@ -16,12 +16,12 @@ quality badges.
 
 [![CI](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions/workflows/ci.yml/badge.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
 [![License: GPL-3.0](https://img.shields.io/badge/license-GPL--3.0-blue)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/src/branch/master/LICENSE)
-[![Coverage](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
+[![Coverage](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
-[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
+[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
-[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/wiki)
+[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/wiki)
-[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
+[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
-[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/releases)
+[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/releases)
-[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/python.svg)](https://www.python.org/downloads/)
+[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/python.svg)](https://www.python.org/downloads/)
 
 ## Why devx?
 
@@ -87,7 +87,7 @@ extra index and list devx in your dependencies:
 ```toml
 [project]
 dependencies = [
-    "devx>=0.11.1",
+    "devx>=0.27.0",
 ]
 
 [tool.pip]
@@ -101,8 +101,8 @@ pip install -e .
 ```
 
 > **Note:** If your project requires a specific devx version, pin it in
-> `dependencies` (e.g., `"devx==0.11.1"`) or use a version constraint
+> `dependencies` (e.g., `"devx==0.27.0"`) or use a version constraint
-> (e.g., `"devx>=0.11.1,<0.12"`).
+> (e.g., `"devx>=0.27.0,<0.28"`).
 
 ### Optional extras
 

docs/index.md

@@ -12,12 +12,12 @@ project to be reusable across all oblachno-oss repositories.
 
 [![CI](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions/workflows/ci.yml/badge.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
 [![License: GPL-3.0](https://img.shields.io/badge/license-GPL--3.0-blue)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/src/branch/master/LICENSE)
-[![Coverage](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
+[![Coverage](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/coverage.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
-[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
+[![Tests](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/tests.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
-[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/wiki)
+[![Docs](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/docs.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/wiki)
-[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
+[![Code Quality](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/quality.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/actions)
-[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/releases)
+[![Version](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/version.svg)](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/releases)
-[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/82fb419c325403ca5788feec435b2014be0d90c8/python.svg)](https://www.python.org/downloads/)
+[![Python](https://git.oblachno.oblachno.fyi/oblachno-oss/devx/raw/commit/d23c6b86736fbbc393345f862d575f23138dbc09/python.svg)](https://www.python.org/downloads/)
 
 ## Overview
 
@@ -74,14 +74,14 @@ Add devx to your `pyproject.toml` dependencies and configure the registry:
 ```toml
 [project]
 dependencies = [
-    "devx>=0.11.1",
+    "devx>=0.27.0",
 ]
 
 [tool.pip]
 extra-index-url = "https://git.oblachno.oblachno.fyi/api/packages/oblachno-oss/pypi/simple"
 ```
 
-Pin a specific version if needed: `"devx==0.11.1"` or `"devx>=0.11.1,<0.12"`.
+Pin a specific version if needed: `"devx==0.27.0"` or `"devx>=0.27.0,<0.28"`.
 
 ### Optional extras
 

docs/tech/architecture.md

@@ -103,7 +103,7 @@ Custom exception hierarchy:
 ### `i18n.py`
 
 Simple i18n system using a JSON translations file (`translations.json`).
-Supports five languages: `en`, `bg`, `de`, `ru`, `zh`. The `_()` function
+Supports six languages: `en`, `bg`, `de`, `pl`, `ru`, `zh`. The `_()` function
 wraps user-facing strings for translation.
 
 Projects can extend translations by setting `DEVX_TRANSLATIONS_PATH` to a

docs/user/getting-started.md

@@ -48,12 +48,12 @@ Add devx to your `pyproject.toml`:
 ```toml
 [project]
 dependencies = [
-    "devx>=0.26.0",
+    "devx>=0.27.0",
 ]
 
 [project.optional-dependencies]
 dev = [
-    "devx[dev]>=0.26.0",
+    "devx[dev]>=0.27.0",
 ]
 ```
 
@@ -115,8 +115,8 @@ Add `[tool.devx]` section to `pyproject.toml` for project-specific config:
 vikunja_project_id = 6
 
 [tool.devx.classify]
-# File patterns that are workflow-only (no release needed)
+# File patterns that are infrastructure (no release needed)
-workflow_only = [
+infrastructure = [
     ".gitea/**",
     "docs/**",
     "tests/**",

src/devx/__init__.py

@@ -1,3 +1,3 @@
 """devx — reusable development and CI/CD tools for oblachno-oss projects."""
 
-__version__ = "0.29.1"
+__version__ = "0.30.0"

src/devx/tools/configure_repo.py

@@ -1,9 +1,10 @@
 #!/usr/bin/env python3
-"""Configure repository: branch protection + repo settings via Gitea REST API.
+"""Configure repository: branch protection, repo settings, and standard labels.
 
-Uses ``GiteaClient`` for branch protection and repo settings.
+Uses ``GiteaClient`` for branch protection, repo settings, and label
-The ``tea`` CLI is used for label creation if available, with a
+creation. Standard labels (bug, ready-to-merge, feedback, tooling,
-fallback to ``GiteaClient`` if tea is not installed.
+ci-improvement, doc-improvement, workflow-improvement) are created
+idempotently via ``ensure_label``.
 
 Usage:
   CI_GITEA_TOKEN=<token> python3 -m devx.tools.configure_repo --repo my-repo
@@ -71,6 +72,19 @@ def _default_repo_settings_config() -> dict[str, Any]:
     }
 
 
+# Standard labels created in every oblachno repo.
+# These cover CI failure notifications, subagent feedback, and auto-merge.
+_STANDARD_LABELS: list[dict[str, str]] = [
+    {"name": "bug", "color": "#ee0701", "description": "Something is not working"},
+    {"name": "ready-to-merge", "color": "#a2eeef", "description": "PR has been reviewed and is ready for auto-merge"},
+    {"name": "feedback", "color": "#fbca04", "description": "Issues from subagent or agent feedback"},
+    {"name": "tooling", "color": "#c5def5", "description": "Tool-related feedback or improvements"},
+    {"name": "ci-improvement", "color": "#84b6eb", "description": "CI workflow improvements"},
+    {"name": "doc-improvement", "color": "#d4c5f9", "description": "Documentation improvements"},
+    {"name": "workflow-improvement", "color": "#fef2c0", "description": "Workflow alignment or pattern improvements"},
+]
+
+
 def _handle_http_error(e: APIError) -> None:
     """Raise a user-friendly Click exception for HTTP errors."""
     if e.status == http.HTTPStatus.FORBIDDEN:
@@ -138,6 +152,12 @@ def configure_repo(
         client.update_repo_settings(cast(dict[str, object], rs_config))
         click.echo(_("  - Auto-delete branch after merge: yes"))
 
+        click.echo("")
+        click.echo(_("Ensuring standard labels..."))
+        for label in _STANDARD_LABELS:
+            client.ensure_label(label["name"], label["color"], label["description"])
+        click.echo(_("  - {count} standard labels verified", count=len(_STANDARD_LABELS)))
+
         click.echo("")
         click.echo(_("Repository configuration complete."))
     except APIError as e:

src/devx/translations.json

@@ -3078,5 +3078,21 @@
     "pl": "Rebasing PR #{pr} via Gitea API...",
     "ru": "Rebasing PR #{pr} via Gitea API...",
     "zh": "Rebasing PR #{pr} via Gitea API..."
+  },
+  "Ensuring standard labels...": {
+    "bg": "Ensuring standard labels...",
+    "de": "Ensuring standard labels...",
+    "en": "Ensuring standard labels...",
+    "pl": "Ensuring standard labels...",
+    "ru": "Ensuring standard labels...",
+    "zh": "Ensuring standard labels..."
+  },
+  "  - {count} standard labels verified": {
+    "bg": "  - {count} standard labels verified",
+    "de": "  - {count} standard labels verified",
+    "en": "  - {count} standard labels verified",
+    "pl": "  - {count} standard labels verified",
+    "ru": "  - {count} standard labels verified",
+    "zh": "  - {count} standard labels verified"
   }
 }

tests/unit/test_configure_repo.py

@@ -8,6 +8,7 @@ from click.testing import CliRunner
 
 from devx.exceptions import APIError
 from devx.tools.configure_repo import (
+    _STANDARD_LABELS,
     _default_branch_protection_config,
     _default_repo_settings_config,
     _handle_http_error,
@@ -58,6 +59,7 @@ class TestConfigureRepo:
 
         mock_client.ensure_branch_protection.assert_called_once()
         mock_client.update_repo_settings.assert_called_once()
+        assert mock_client.ensure_label.call_count == len(_STANDARD_LABELS)
 
     @patch.dict("os.environ", {"CI_GITEA_TOKEN": "tok"}, clear=True)
     @patch("devx.tools.configure_repo.GiteaClient")
@@ -100,6 +102,21 @@ class TestConfigureRepo:
 
         mock_client.ensure_branch_protection.assert_called_once_with("develop", custom_bp)
         mock_client.update_repo_settings.assert_called_once_with(custom_rs)
+        # Labels are created regardless of custom configs
+        assert mock_client.ensure_label.call_count == len(_STANDARD_LABELS)
+
+    @patch.dict("os.environ", {"CI_GITEA_TOKEN": "tok"}, clear=True)
+    @patch("devx.tools.configure_repo.GiteaClient")
+    def test_configure_repo_creates_all_standard_labels(self, mock_client_cls: MagicMock) -> None:
+        """Verify all standard labels are ensured with correct names."""
+        mock_client = MagicMock()
+        mock_client_cls.return_value = mock_client
+
+        configure_repo(token="tok", owner="owner", repo="repo")
+
+        created_names = [call.args[0] for call in mock_client.ensure_label.call_args_list]
+        expected_names = [lbl["name"] for lbl in _STANDARD_LABELS]
+        assert created_names == expected_names
 
 
 class TestMain:
@@ -114,6 +131,7 @@ class TestMain:
         assert result.exit_code == 0
         mock_client.ensure_branch_protection.assert_called_once()
         mock_client.update_repo_settings.assert_called_once()
+        assert mock_client.ensure_label.call_count == len(_STANDARD_LABELS)
 
     @patch.dict("os.environ", {"CI_GITEA_TOKEN": "tok"}, clear=True)
     @patch("devx.tools.configure_repo.GiteaClient")
@@ -125,6 +143,7 @@ class TestMain:
         result = runner.invoke(main, ["--repo", "myrepo", "--owner", "myorg"])
         assert result.exit_code == 0
         mock_client.ensure_branch_protection.assert_called_once()
+        assert mock_client.ensure_label.call_count == len(_STANDARD_LABELS)
 
     @patch.dict("os.environ", {"CI_GITEA_TOKEN": "tok"}, clear=True)
     @patch("devx.tools.configure_repo.GiteaClient")