docs(site): refresh DevRail project status

Author: BMAD CI Fix Agent

content/_index.md

@@ -102,6 +102,8 @@ See the full [OpenClaw integration guide](/docs/getting-started/agents/#openclaw
 
 Your agents don't read your conventions. They skip your linters, ignore your formatters, and commit code that fails CI. DevRail gives them one instruction and one gate -- `make check` -- that enforces every standard automatically. Same contract for your agents, your CI, and you.
 
+[Current project status](/docs/project-status/) tracks the v1 release line, public repository activity, and the GitLab v0.1.0 migration baseline rollout.
+
 {{% /blocks/section %}}
 
 {{% blocks/section color="white" type="row" %}}
@@ -148,6 +150,7 @@ Per-language standards define which tools run, how they are configured, and what
 - [Quick Start Guide](/docs/getting-started/) -- Set up a new or existing project
 - [Standards Reference](/docs/standards/) -- Per-language tooling conventions
 - [Container Documentation](/docs/container/) -- How the dev-toolchain works
+- [Project Status](/docs/project-status/) -- Current release and migration roadmap
 - [Contributing](/docs/contributing/) -- Help improve DevRail
 
 {{% /blocks/section %}}

content/blog/2026-08-18-project-status-and-gitlab-baseline.md

@@ -0,0 +1,21 @@
+---
+title: "Project Status and GitLab Baseline"
+date: 2026-08-18
+description: "DevRail v1 remains active on the v1.12 release line, and GitLab adoption work is being normalized around a v0.1.0 migration baseline."
+---
+
+DevRail's public docs have been quiet while the v1 release line kept moving. This update brings the site back in line with the current state of the project: the `dev-toolchain` v1.12 line is active, the latest public v1.12 tag observed is `v1.12.13`, and GitLab adoption work is now being tracked around a practical v0.1.0 migration baseline.
+
+## What changed on the site
+
+- Added a [Project Status](/docs/project-status/) page for the current release line, public repository map, and GitLab migration roadmap.
+- Linked the status page from the homepage and docs index so it is visible without digging through release posts.
+- Rechecked stale GitHub links in the May plugin posts and kept them pointed at their current public sources.
+
+The generated [Tool Versions](/docs/container/versions/) page is still owned by the scheduled release workflow. It remains the source of truth for exact container contents when the automation publishes a new version snapshot.
+
+## GitLab v0.1.0 baseline
+
+The GitLab work is about making existing repositories converge on the same contract new DevRail template projects already get: a declared `.devrail.yml`, a Makefile that preserves `make check`, review templates that ask for validation evidence, and CI that runs the DevRail check path where the project supports it.
+
+The public roadmap is intentionally high-level. Private repository status and migration MRs stay in the owning GitLab projects, while devrail.dev documents the contract and the migration shape.

content/docs/_index.md

@@ -13,6 +13,7 @@ Welcome to the DevRail documentation. These guides cover everything you need to
 ## Sections
 
 - **[Getting Started](/docs/getting-started/)** -- Quick start guides for new projects, retrofitting existing repos, and AI agent setup
+- **[Project Status](/docs/project-status/)** -- Current release line, repository activity, and GitLab migration roadmap
 - **[Standards](/docs/standards/)** -- Per-language reference pages for Python, Bash, Terraform, Ansible, Ruby, and universal security tools
 - **[Container](/docs/container/)** -- How to use the dev-toolchain container image
 - **[Templates](/docs/templates/)** -- How to use the GitHub and GitLab project templates

content/docs/project-status.md

@@ -0,0 +1,46 @@
+---
+title: "Project Status"
+linkTitle: "Project Status"
+weight: 5
+description: "Current DevRail release status, repository activity, and GitLab migration roadmap."
+---
+
+DevRail v1 is stable for current adopters. The public site, templates, standards, and container documentation are maintained from the GitHub organization, while active GitLab deployments are being normalized around the same baseline files and check contract.
+
+## Current Release Line
+
+- Public container release line: `ghcr.io/devrail-dev/dev-toolchain:v1`
+- Latest public v1.12 tag observed: `v1.12.13`
+- Current generated tool-version page: [Tool Versions](/docs/container/versions/)
+- Compatibility posture: v1 remains backward-compatible; breaking language/plugin changes are reserved for v2.
+
+## Public Repository Status
+
+The public repositories remain the canonical open-source surfaces:
+
+| Repository | Status |
+|---|---|
+| [dev-toolchain](https://github.com/devrail-dev/dev-toolchain) | Active v1 container release line |
+| [devrail-standards](https://github.com/devrail-dev/devrail-standards) | Canonical standards and schema source |
+| [devrail.dev](https://github.com/devrail-dev/devrail.dev) | Public documentation site |
+| [github-repo-template](https://github.com/devrail-dev/github-repo-template) | Public GitHub bootstrap template |
+| [gitlab-repo-template](https://gitlab.com/devrail-dev/gitlab-repo-template) | Public GitLab bootstrap template |
+
+## GitLab v0.1.0 Migration Baseline
+
+The GitLab migration work is focused on making existing repositories match the same operational contract as new template-based projects. The v0.1.0 baseline means a repository has, at minimum:
+
+- `DEVRAIL.md` or equivalent project-facing adoption notes
+- `.devrail.yml` with declared languages and project settings
+- Makefile targets that preserve the `make check` contract
+- Merge request templates that ask for validation evidence
+- GitLab CI that runs the DevRail check path where the project can support it
+
+### Roadmap
+
+1. Complete baseline-ready repositories that already have the docs, Makefile, `.devrail.yml`, and merge request template pieces.
+2. Fill Makefile and CI gaps in repositories that already have partial DevRail adoption.
+3. Classify repositories with no clear DevRail signal as adopt, defer, or exempt.
+4. Keep public docs aligned with the internal migration pattern without publishing private repository names or infrastructure details.
+
+This page is the public status note for that work. Detailed per-repository migration status stays with the owning GitLab projects.