GRM-146: ci: consolidate CI and post-merge workflows

docs/tech/ci-cd-workflow.md

@@ -6,10 +6,9 @@ GRM uses a fully automated CI/CD pipeline built on Gitea Actions. Every change t
 
 | Workflow | Trigger | Purpose |
 |----------|---------|---------|
-| `ci.yml` | PR opened/synchronized | Quality checks (lint, test, coverage) + molecule tests |
+| `ci.yml` | PR opened/synchronized | Validate (lint, test, coverage, detect-changes, release-dry-run, pr-review, discover-runners) + molecule tests |
 | `auto-merge.yml` | PR labeled `ready-to-merge` | Validates and squash-merges the PR |
-| `post-merge.yml` | Push to `master` | Release, wiki sync, badges, Vikunja task update |
-| `publish.yml` | Tag push (`v*`) | Build and publish package to PyPI, create Gitea release |
+| `post-merge.yml` | Push to `master` | Detect-and-configure + release-and-maintain (release, publish, wiki sync, badges, Vikunja task update) |
 
 Every change to master goes through a mandatory PR workflow. No exceptions.
 
@@ -101,14 +100,14 @@ Then add the `ready-to-merge` label. The auto-merge workflow will:
 3. Wait for all CI checks to pass
 4. Squash-merge with title: `GRM-N <conventional commit message>` (space-separated)
 5. The post-merge workflow marks the Vikunja task as done
-6. The release workflow automatically versions, tags, and publishes
+6. The release-and-maintain job automatically versions, tags, and publishes
 
 ### 9. Post-Merge Automation
 
 After the squash-merge:
 
-- The **post-merge workflow** (`.gitea/workflows/post-merge.yml`) triggers on push to `master` and runs `devx.ci.post_merge` to mark the Vikunja task as done, extracting the task ID from the merge commit message.
-- The **release workflow** (`.gitea/workflows/release.yml`) triggers on push to `master` and automatically versions, tags, and publishes (see below).
+- The **post-merge workflow** (`.gitea/workflows/post-merge.yml`) triggers on push to `master`. The `detect-and-configure` job configures the repo and detects the commit type. The `release-and-maintain` job then runs the release, publish, sync-wiki, badges, and Vikunja steps as appropriate.
+- The **release step** (in the `release-and-maintain` job) automatically versions, tags, and publishes (see below).
 
 ## Branch Protection (Required Gitea Settings)
 
@@ -116,42 +115,46 @@ Configure the following branch protection rules for `master` in Gitea repo setti
 
 - **Require pull request**: No direct pushes to master
 - **Require approval review**: At least 1 `APPROVE` review before merge
-- **Require status checks**: CI quality + molecule tests must pass
+- **Require status checks**: CI validate + molecule tests must pass
 - **Block force pushes**: No history rewriting on master
 
 The auto-merge workflow enforces the APPROVE review check programmatically as a defense-in-depth measure, but branch protection is the primary gate.
 
 ## CI Path Filtering
 
-The CI workflow (`.gitea/workflows/ci.yml`) includes a `detect-changes` job that checks whether any files under `ansible/` or `.ansible-lint` have changed. If no Ansible files are changed, molecule tests are skipped — this prevents non-Ansible changes (e.g., Python scripts, workflow YAML, docs) from being blocked by molecule test infrastructure flakiness.
+The CI workflow (`.gitea/workflows/ci.yml`) includes a `detect-changes` step in the `validate` job that checks whether any files under `ansible/` or `.ansible-lint` have changed. If no Ansible files are changed, molecule tests are skipped — this prevents non-Ansible changes (e.g., Python scripts, workflow YAML, docs) from being blocked by molecule test infrastructure flakiness.
 
-The `detect-changes` job:
+The `detect-changes` step:
 
 - For pull requests: compares `origin/master` against the PR head SHA
 - For pushes to master: compares `HEAD~1` against `HEAD`
 - Outputs `ansible-changed` as `true` or `false`
 
-The `molecule-tests` job depends on both `quality` and `detect-changes`, and only runs if `ansible-changed == 'true'`.
+The `molecule-tests` job depends on the `validate` job (which includes the `detect-changes` step), and only runs if `ansible-changed == 'true'`.
 
 CI triggers only on `opened` and `synchronize` PR events (not `labeled`).
 
-## CI Quality Job
+## CI Validate Job
 
-The `quality` job in `.gitea/workflows/ci.yml` runs:
+The `validate` job in `.gitea/workflows/ci.yml` consolidates the former quality, detect-changes, release-dry-run, pre-merge-check, pr-review, and discover-runners jobs into a single job. It runs:
 
 1. `make setup` — full environment setup
 2. `make lint-all` — ruff + pyright + bandit + ansible-lint + checkmake
 3. `make pytest-cov` — unit tests with 100% coverage enforcement
 4. `python -m devx.tools.check_test_speed --max-seconds 10` — verify unit tests run fast
-5. `PYTHONPATH=src python -m devx.ci.release --dry-run` — release dry-run validation
+5. `PYTHONPATH=src python -m devx.ci.release --dry-run` — release dry-run validation (release-dry-run step)
+6. Pre-merge validation step — validates branch format, PR title, and Vikunja task match
+7. `detect-changes` step — checks whether Ansible files changed (gates molecule tests)
+8. `pr-review` step — automated PR review via `devx.ci.pr_review`
+9. `discover-runners` step — dynamic runner discovery for molecule tests (conditional on ansible-changed)
 
 ## Automated Release Pipeline
 
 After a PR is merged to master, the release pipeline runs automatically.
 
-### Release Workflow (`.gitea/workflows/release.yml`)
+### Release Step (in the release-and-maintain job)
 
-- Triggers on push to `master`
+- Runs as a conditional step in the `release-and-maintain` job (skipped for release commits)
 - Sets up full dev environment (`make setup`) so lint and tests can run
 - Installs git-cliff (version 2.13.0)
 - Configures git as `grm-ci-bot`
@@ -169,9 +172,10 @@ After a PR is merged to master, the release pipeline runs automatically.
 - Loops are prevented by `has_unreleased_changes` — after a release commit is tagged, the next run finds no unreleased changes and exits
 - On failure, creates a Gitea issue via `devx.ci.notify_failure`
 
-### Publish Workflow (`.gitea/workflows/publish.yml`)
+### Publish Step (in the release-and-maintain job)
 
-- Triggers on tag push (`v*`)
+- Runs as a conditional step in the `release-and-maintain` job (only if the release step created a tag)
+- Checks out the release tag within the same job
 - Installs git-cliff (version 2.13.0)
 - Installs build tools (`build`, `twine`, `requests`, `python-dotenv`, `click`)
 - Validates `PYPI_TOKEN` is set (warns if missing)
@@ -190,12 +194,17 @@ After a PR is merged to master, the release pipeline runs automatically.
 ### Post-Merge Workflow (`.gitea/workflows/post-merge.yml`)
 
 - Triggers on push to `master`
-- Consolidates release, wiki sync, badge generation, and Vikunja task updates into a single workflow
-- **detect-type** — Runs `devx.ci.detect_release_commit` to check if the commit is a release commit (`release: vX.Y.Z`). All subsequent jobs skip for release commits (the `[skip ci]` tag also prevents re-triggering).
-- **release** — Runs `devx.ci.release` (see Automated Release Pipeline below)
-- **sync-wiki** — Syncs documentation to the Gitea wiki via `devx.ci.sync_wiki`
-- **badges** — Generates and pushes quality badge SVGs to the `badges` branch via `devx.ci.push_badges`. Runs after the release job (even if release fails or is skipped) so the version badge always reflects the latest state.
-- **vikunja** — Marks the corresponding Vikunja task as done via `devx.ci.post_merge`
+- Consolidated from 7 jobs into 2 jobs to reduce runner overhead
+- **detect-and-configure** — Configures repo (branch protection, labels), detects release commit, validates commit message. Outputs `is-release` and `is-automated` for the next job.
+  - **detect-type step** — Runs `devx.ci.detect_release_commit` to check if the commit is a release commit (`release: vX.Y.Z`). All subsequent steps skip for release commits (the `[skip ci]` tag also prevents re-triggering).
+  - **validate-commit-msg step** — Validates the commit message follows conventional commit format.
+  - **configure-repo step** — Runs `devx.tools.configure_repo` to set up branch protection and labels.
+- **release-and-maintain** — Runs all post-merge maintenance as conditional steps:
+  - **release step** (if not a release commit) — Runs `devx.ci.release` (see Automated Release Pipeline below)
+  - **publish step** (if release created a tag) — Builds and publishes the package to the Gitea PyPI registry
+  - **sync-wiki step** (if not automated) — Syncs documentation to the Gitea wiki via `devx.ci.sync_wiki`
+  - **vikunja step** (if not automated) — Marks the corresponding Vikunja task as done via `devx.ci.post_merge`
+  - **badges step** (always) — Generates and pushes quality badge SVGs to the `badges` branch via `devx.ci.push_badges`. Runs even if release fails or is skipped so the version badge always reflects the latest state.
 
 ### Smart CI: User-Facing vs Workflow-Only Changes
 
@@ -218,16 +227,16 @@ from accidentally skipping releases. Classification is config-driven via
 
 **CI behavior based on classification:**
 - **Molecule tests**: Only run when `ansible/` or `.ansible-lint` files change
-- **Release dry-run**: Only runs when user-facing files change (separate `release-dry-run` job)
-- **Quality job** (lint, unit tests, coverage, doc-coverage): Always runs
-- **Release workflow**: `release.py` calls `classify_changes` to check if any
+- **Release dry-run**: Only runs when user-facing files change (release-dry-run step in the validate job)
+- **Validate job** (lint, unit tests, coverage, doc-coverage): Always runs
+- **Release step**: `release.py` calls `classify_changes` to check if any
   user-facing files changed since the last tag. If not, the release is skipped
   entirely — no version bump, no tag, no publish.
 
 ### Dynamic Runner Discovery
 
 Molecule tests are distributed across available Gitea Actions runners
-dynamically. The `discover-runners` job runs `devx.molecule.discover_runners` which queries the Gitea API for
+dynamically. The `discover-runners` step in the `validate` job runs `devx.molecule.discover_runners` which queries the Gitea API for
 registered runners at three levels (repo, org, instance) and generates
 a matrix of runner indices. If the API query fails (e.g., no admin
 access for instance-level runners), it falls back to the
@@ -263,15 +272,15 @@ feature branches.
 
 ### Release Commit Detection
 
-The `detect-type` job in the post-merge workflow runs
+The `detect-type` step in the `detect-and-configure` job (post-merge workflow) runs
 `devx.ci.detect_release_commit` to check whether the latest commit
 is a release commit (format: `release: vX.Y.Z`). When a release commit
-is detected, all post-merge jobs (release, sync-wiki, badges, vikunja)
-are skipped — the tag push triggers the publish workflow instead.
+is detected, all subsequent steps in the `release-and-maintain` job (release, publish, sync-wiki, vikunja)
+are skipped — the tag push triggers the publish step instead.
 
 ### Badge Generation and Push
 
-The `badges` job in the post-merge workflow runs
+The `badges` step in the `release-and-maintain` job (post-merge workflow) runs
 `devx.ci.push_badges` which:
 1. Fetches the latest master and hard-resets to it (picks up release commits)
 2. Generates quality badge SVG files via `devx.tools.generate_badges`
@@ -279,8 +288,8 @@ The `badges` job in the post-merge workflow runs
 4. Copies SVG files to the branch root
 5. Force-pushes the branch to the remote
 
-The badges job depends on the `release` job and uses `if: always()` so it
-runs even if release fails or is skipped. This ensures the version badge
+The badges step runs with `if: always()` so it
+runs even if the release step fails or is skipped. This ensures the version badge
 always reflects the actual state of the repository after any release
 commits have been pushed.