ci(release): prepare stable Docker version aliases

Prepare Path Header Scanner's production image workflows for the stable
`v1.0.0` release after the published `v1.0.0-rc.1` validation boundary.

### 🐋 Stable image aliases

- Publish one stable image under the exact `v1.0.0` tag and the coordinated
  `v1.0`, `v1`, and `latest` aliases on GitHub and GitLab.
- Keep prereleases exact-only so candidate images cannot move stable aliases.
- Derive major and minor aliases from the validated release tag and keep all
  aliases attached to the same built image.
- Apply the same stable-versus-prerelease alias classification on GitHub and
  GitLab while preserving the package gate's rejection of build metadata.

### 🧪 Regression protection and documentation

- Add structural workflow tests for alias generation, provider parity, and
  prerelease isolation.
- Document immutable exact tags, moving minor and major aliases, and the
  stable-only `latest` policy in repository and public documentation.
- Preserve the existing annotated-tag, package-version, protected-publication,
  and provider-registry safeguards.

Release phase: post-RC stabilization
Tag: none
Previous release: v1.0.0-rc.1
Target release: v1.0.0

🔖 **Tags**:
- Type: `#ci`, `#release`
- Delivery: `#docker`, `#github-actions`, `#gitlab-ci`
- Scope: `#stable-aliases`, `#regression-tests`, `#documentation`

Author: devalltect00

.config/custy/templates/backups/commit/commit-message_20260908_105815.bak.txt

@@ -0,0 +1,33 @@
+ci(release): prepare stable Docker version aliases
+
+Prepare Path Header Scanner's production image workflows for the stable
+`v1.0.0` release after the published `v1.0.0-rc.1` validation boundary.
+
+### 🐋 Stable image aliases
+
+- Publish one stable image under the exact `v1.0.0` tag and the coordinated
+  `v1.0`, `v1`, and `latest` aliases on GitHub and GitLab.
+- Keep prereleases exact-only so candidate images cannot move stable aliases.
+- Derive major and minor aliases from the validated release tag and keep all
+  aliases attached to the same built image.
+- Apply the same stable-versus-prerelease alias classification on GitHub and
+  GitLab while preserving the package gate's rejection of build metadata.
+
+### 🧪 Regression protection and documentation
+
+- Add structural workflow tests for alias generation, provider parity, and
+  prerelease isolation.
+- Document immutable exact tags, moving minor and major aliases, and the
+  stable-only `latest` policy in repository and public documentation.
+- Preserve the existing annotated-tag, package-version, protected-publication,
+  and provider-registry safeguards.
+
+Release phase: post-RC stabilization
+Tag: none
+Previous release: v1.0.0-rc.1
+Target release: v1.0.0
+
+🔖 **Tags**:
+- Type: `#ci`, `#release`
+- Delivery: `#docker`, `#github-actions`, `#gitlab-ci`
+- Scope: `#stable-aliases`, `#regression-tests`, `#documentation`

.config/custy/templates/commit-message.txt

@@ -1,68 +1,33 @@
-release(rc): promote Path Header Scanner v1.0.0-rc.1
+ci(release): prepare stable Docker version aliases
 
-Promote the combined implementation from four untagged development checkpoints
-to the first Path Header Scanner 1.0 release candidate. This is the promotion
-and validation boundary, not another implementation checkpoint.
+Prepare Path Header Scanner's production image workflows for the stable
+`v1.0.0` release after the published `v1.0.0-rc.1` validation boundary.
 
-### 🧭 Checkpoint lineage
+### 🐋 Stable image aliases
 
-- Checkpoint 1 owns the complete application foundation, general GitHub and
-  GitLab CI/CD corrections, runtime compatibility, Docker build-version
-  resolution, ignore rules, quality tooling, regression tests, and documentation.
-- Checkpoint 2 owns private GitLab Python distribution, canonical PEP 440
-  package metadata, protected-tag publication, validation-only unprotected
-  tags, and immutable package safeguards.
-- Checkpoint 3 owns the optional source-checkout repository-metadata helper and
-  related README/TODO maintenance. It remains outside the installed CLI and
-  automated release workflow; its recorded follow-ups remain subject to review.
-- Checkpoint 4 owns safe GitHub release-note rendering, populated release
-  metadata, literal Docker examples, and regression protection.
+- Publish one stable image under the exact `v1.0.0` tag and the coordinated
+  `v1.0`, `v1`, and `latest` aliases on GitHub and GitLab.
+- Keep prereleases exact-only so candidate images cannot move stable aliases.
+- Derive major and minor aliases from the validated release tag and keep all
+  aliases attached to the same built image.
+- Apply the same stable-versus-prerelease alias classification on GitHub and
+  GitLab while preserving the package gate's rejection of build metadata.
 
-### ✅ Release-candidate contract
+### 🧪 Regression protection and documentation
 
-- Establish the first supported release line; there is no earlier published
-  stable version to migrate from.
-- Keep `path-header-scanner init` and `path-header-scanner scan <target>` as
-  the supported public commands.
-- Preserve preview-first scanning, explicit apply control, language-aware
-  headers, deterministic targets, ignores, and concise command errors.
-- Keep `--dry-run` authoritative over CLI or configured apply mode and keep
-  initialization dry-run non-writing and non-interactive.
-- Preserve Python 3.11+ compatibility and Python 3.14 as the standard
-  development and container runtime.
-- Carry forward active-repository registry naming, root multi-stage builds,
-  non-empty annotated release-tag checks, package/tag version agreement,
-  complete provider release notes, exact prerelease images, and stable-only
-  `latest`.
-- Use `path-header-scanner==1.0.0rc1` as the canonical RC Python package version while
-  retaining `v1.0.0-rc.1` as the SemVer Git tag.
-- Preserve `CI_JOB_TOKEN` publication, authorized deploy-token installation,
-  and the package validation → production image → private package → release
-  ordering established by checkpoint 2.
+- Add structural workflow tests for alias generation, provider parity, and
+  prerelease isolation.
+- Document immutable exact tags, moving minor and major aliases, and the
+  stable-only `latest` policy in repository and public documentation.
+- Preserve the existing annotated-tag, package-version, protected-publication,
+  and provider-registry safeguards.
 
-### 🧪 Recorded validation and final RC gates
-
-- Treat the validation recorded in checkpoints 1 and 2 as historical evidence,
-  not a substitute for checks against the exact RC commit.
-- Re-run the approved test, lint, formatting, pre-commit, packaging,
-  documentation, CLI-help, dry-run, Make, Docker, Compose, and workflow checks.
-- Confirm the reviewed target paths, output or mutation boundaries, package
-  metadata, image destinations, annotated tag message, and release links.
-- Review the maintainer helper's pending follow-ups separately; this promotion
-  message does not assert that live metadata synchronization was validated.
-- Document and validate release-blocking fixes discovered during candidate
-  review before promoting the stable release.
-
-Tag: v1.0.0-rc.1
-Previous release: none — first formal release
-Checkpoints:
-- commit-message-v1.0.0-development-checkpoint.txt
-- commit-message-v1.0.0-development-checkpoint-2.txt
-- commit-message-v1.0.0-development-checkpoint-3.txt
-- commit-message-v1.0.0-development-checkpoint-4.txt
+Release phase: post-RC stabilization
+Tag: none
+Previous release: v1.0.0-rc.1
+Target release: v1.0.0
 
 🔖 **Tags**:
-- Type: `#release`, `#validation`
-- Delivery: `#release-candidate`, `#semver`, `#github`, `#gitlab`
-- Quality: `#tests`, `#dry-run`, `#packaging`, `#compatibility`
-- Safety: `#annotated-tags`, `#protected-tags`, `#stable-latest`
+- Type: `#ci`, `#release`
+- Delivery: `#docker`, `#github-actions`, `#gitlab-ci`
+- Scope: `#stable-aliases`, `#regression-tests`, `#documentation`

.config/custy/templates/tag-message.txt

@@ -1,155 +1,11 @@
-🚧 Path Header Scanner v1.0.0-rc.1 — First Production Release Candidate
-
-Path Header Scanner v1.0.0-rc.1 is the first formal release candidate for a
-configuration-driven CLI that previews, validates, inserts, and updates
-repository-relative path headers across supported source and documentation
-files.
-
-There is no previous production release to upgrade from. This candidate defines
-the initial supported CLI, configuration, safety model, language coverage, and
-automation foundation that will become v1.0.0 after release-candidate validation.
-
-### 🌟 Highlights
-
-- Preview-first scanning: files remain unchanged unless `--apply` is selected.
-- Recursive discovery and validation of missing, valid, and stale path headers.
-- Language-aware support for Python, JavaScript and TypeScript, Shell, PHP, HTML, and Markdown.
-- Explicit target and working-directory selection for predictable repository-relative headers.
-- Configurable ignore rules for Git metadata, environments, caches, dependencies, and build output.
-- `path-header-scanner init` for generating the namespaced project configuration.
-- `path-header-scanner scan <target>` for previewing or applying reviewed corrections.
-- Rich command help, banners, progress, summaries, and failure reporting.
-- Concise, actionable command errors with reliable nonzero exits and debug-only implementation tracebacks.
-- Console and rotating-file logging for troubleshooting.
-- Local, Docker, Docker Compose, and modular Make workflows.
-- Automated tests, MkDocs documentation, GitHub Actions, and GitLab CI support.
-- Hardened delivery pipelines that use the active repository's registry namespace, require non-empty annotated release tags, preserve safely rendered complete tag-message release notes with populated metadata and literal Docker commands, keep RC images on their exact tag, and reserve `latest` for stable releases.
-- Private GitLab PyPI delivery for `path-header-scanner`, with the RC tag
-  published as canonical package version `1.0.0rc1` only after the protected
-  release pipeline passes.
-
-### 📦 Install the private RC package
-
-Authorized users can install the candidate from the private GitLab package
-registry. Configure pip authentication with a deploy token limited to
-`read_package_registry`, then use the token-free project index URL:
-
-```bash
-python -m pip install \
-  --index-url "https://gitlab.com/api/v4/projects/<project-id>/packages/pypi/simple" \
-  "path-header-scanner==1.0.0rc1"
-```
-
-Supply the deploy-token username and token through an approved protected pip
-credential mechanism or its interactive authentication flow. Never place tokens
-in committed configuration or shared command history. Unprotected tags validate
-the same artifacts but cannot publish them.
-
-### 🛡️ Safety model
-
-Path Header Scanner is intentionally conservative:
-
-- A normal scan is a preview and does not change target files.
-- `--apply` is required before eligible files are updated.
-- `--dry-run` prevents mutations even if `--apply` or configured apply mode is present.
-- Initialization dry-run does not create configuration directories or files and does not prompt for overwrite.
-- Read-only discovery and validation still run during dry-run so the preview remains useful.
-- Diagnostic logs may be written to the configured log destination, but target-project files remain unchanged.
-
-### 🧭 Core workflows
-
-Preview a target:
-
-```bash
-path-header-scanner scan app
-```
-
-Apply reviewed corrections:
-
-```bash
-path-header-scanner scan app --apply
-```
-
-Force an explicit simulation, including when apply mode is configured:
-
-```bash
-path-header-scanner scan app --apply --dry-run
-```
-
-Preview project initialization:
-
-```bash
-path-header-scanner init --dry-run
-```
-
-### ⚙️ Configuration
-
-Project settings live in:
-
-```text
-.config/path_header_scanner/config.toml
-```
-
-Configuration can define scan defaults, ignored content, logging, banner
-behavior, apply mode, and dry-run mode. Explicit CLI options take precedence for
-the current invocation.
-
-### 🧩 Language behavior
-
-Each supported language uses syntax appropriate to that file type. The scanner
-preserves relevant leading content, including shebangs and language-specific
-special lines, while inserting or replacing only the managed path header.
-
-Markdown path headers use HTML comments intentionally so generated documentation
-remains readable without displaying internal header metadata.
-
-### 🧰 For contributors and integrators
-
-- CLI parsing and presentation are separated from scan and update behavior.
-- Language strategies provide focused extension points for additional file types.
-- Scanner, processor, and updater responsibilities can be tested independently.
-- Initialization planning is separated from persistence to enforce dry-run safety.
-- Modular Make, Docker, Compose, CI, lint, format, test, package, and documentation workflows support repeatable development.
-
-### 🧪 Recommended RC validation
-
-Please validate the candidate on a disposable or version-controlled test project:
-
-1. Install v1.0.0-rc.1 in an isolated Python environment.
-2. Run `path-header-scanner --help` and command-specific help.
-3. Preview initialization with `path-header-scanner init --dry-run`.
-4. Initialize and review `.config/path_header_scanner/config.toml`.
-5. Preview representative source and documentation targets.
-6. Verify `--apply --dry-run` leaves every target file unchanged.
-7. Apply a reviewed scan and inspect the resulting path headers and summary.
-8. Report unsupported syntax, incorrect relative paths, unsafe writes, or confusing output before v1.0.0 is promoted.
-
-### 🚧 Release-candidate status
-
-This release candidate brings together four untagged development checkpoints.
-The product and general delivery foundation belongs to checkpoint 1; private
-GitLab package delivery belongs to checkpoint 2; source-checkout maintenance
-belongs to checkpoint 3; and safe GitHub Release rendering belongs to checkpoint
-4. RC.1 promotes their reviewed, cumulative result rather than introducing a
-separate implementation checkpoint.
-
-Recorded development validation is not final release sign-off. Complete the
-RC checks against the exact candidate commit before publishing its tag, and
-validate the workflows relevant to your project before production use.
-
-- Version: `v1.0.0-rc.1`
-- Previous version: none — first formal release
-- Strategy: Semantic Versioning
-- Package compatibility: Python 3.11+
-- Standard development/container runtime: Python 3.14
-- Stability: Release candidate; validate before production automation
-- Stable target: `v1.0.0`
-
-The stable release may include final cleanup, documentation corrections, and
-fixes discovered during RC validation, without changing the documented safety
-model unexpectedly.
-
-Thank you for validating the first Path Header Scanner production release line.
-
-_Release candidate: v1.0.0-rc.1_
-_Author: Devalltect / Rizky Fernandes_
+✅ Final Release path-header-scanner v1.0.0
+
+**path-header-scanner v1.0.0** is now stable and production-ready. All feature and fixes from pre-releases (alpha, beta, rc) are included.
+
+### ✨ Highlights
+
+- *(Nothing yet)*
+
+---
+
+✅ This version is **stable** and **suitable** for production use.

.github/workflows/docker-prod.yml

@@ -5,8 +5,8 @@ name: 🐋 Docker Production Image
 run-name: 🐋 Production Docker Build • ${{ inputs.tag || github.ref_name }}
 
 # Production images are release artifacts. They are built only from existing,
-# non-empty annotated SemVer tags. Stable tags update `latest`; prerelease
-# tags publish only their exact version.
+# non-empty annotated SemVer tags. Stable tags update the matching major,
+# minor, and `latest` aliases; prerelease tags publish only their exact version.
 
 on:
   push:
@@ -49,8 +49,9 @@ jobs:
           python -m pip install --disable-pip-version-check packaging
 
           TAG_REGEX='^v[0-9]+\.[0-9]+\.[0-9]+([.-](alpha|beta|rc|dev|post)\.[0-9]+)?(\+[0-9A-Za-z.]+)?$'
-          STABLE_TAG_REGEX='^v[0-9]+\.[0-9]+\.[0-9]+(\+[0-9A-Za-z.]+)?$'
+          STABLE_TAG_REGEX='^v[0-9]+\.[0-9]+\.[0-9]+$'
           TAG="$RELEASE_TAG"
+          PUBLISH_ALIASES=false
           PUBLISH_LATEST=false
 
           if [[ ! "$TAG" =~ $TAG_REGEX ]]; then
@@ -83,14 +84,21 @@ jobs:
           fi
 
           if [[ "$TAG" =~ $STABLE_TAG_REGEX ]]; then
+            PUBLISH_ALIASES=true
             PUBLISH_LATEST=true
           fi
 
           IMAGE_TAG="${TAG//+/-}"
+          VERSION_CORE="${TAG#v}"
+          VERSION_CORE="${VERSION_CORE%%+*}"
+          IFS='.' read -r MAJOR MINOR _ <<< "$VERSION_CORE"
 
           echo "tag=$TAG" >> "$GITHUB_OUTPUT"
           echo "image_tag=$IMAGE_TAG" >> "$GITHUB_OUTPUT"
           echo "version=$VERSION" >> "$GITHUB_OUTPUT"
+          echo "major=$MAJOR" >> "$GITHUB_OUTPUT"
+          echo "minor=$MINOR" >> "$GITHUB_OUTPUT"
+          echo "publish_aliases=$PUBLISH_ALIASES" >> "$GITHUB_OUTPUT"
           echo "publish_latest=$PUBLISH_LATEST" >> "$GITHUB_OUTPUT"
 
       - name: 🐳 Set up Docker Buildx
@@ -117,6 +125,8 @@ jobs:
             ghcr.io/${{ steps.vars.outputs.image_name }}
           tags: |
             type=raw,value=${{ steps.version.outputs.image_tag }}
+            type=raw,value=v${{ steps.version.outputs.major }}.${{ steps.version.outputs.minor }},enable=${{ steps.version.outputs.publish_aliases }}
+            type=raw,value=v${{ steps.version.outputs.major }},enable=${{ steps.version.outputs.publish_aliases }}
             type=raw,value=latest,enable=${{ steps.version.outputs.publish_latest }}
 
       - name: 🏗️ Build and push production image