major · jmrenouard · May 17, 2026 · May 2, 2026 · Apr 13, 2026 · Apr 15, 2026
diff --git a/.agent/README.md b/.agent/README.md
@@ -35,24 +35,20 @@ This directory contains the project's technical constitution, specialized skills
 | File | Description |
 | :--- | :--- |
 | [`compliance-sentinel.md`](./workflows/compliance-sentinel.md) | Automated audit to enforce project constitution rules |
-| [`doc-sync.md`](./workflows/doc-sync.md) | Synchronize .agent/README.md with current Rules, Skills, and Workflows |
 | [`docker-clean.md`](./workflows/docker-clean.md) | Reclaim disk space by removing unused containers and images |
 | [`examples-cleanup.md`](./workflows/examples-cleanup.md) | Maintain only the 10 most recent results in the examples directory |
-| [`git-flow.md`](./workflows/git-flow.md) | Automate git-flow release process |
 | [`git-rollback.md`](./workflows/git-rollback.md) | Rollback a failed release (delete tags and revert commits) |
 | [`hey-agent.md`](./workflows/hey-agent.md) | Unified management for Rules, Skills, and Workflows. |
 | [`lab-down.md`](./workflows/lab-down.md) | Stops and cleans up the database laboratory. |
 | [`lab-up.md`](./workflows/lab-up.md) | Starts a persistent database laboratory and injects data. |
 | [`markdown-lint.md`](./workflows/markdown-lint.md) | Check markdown content for cleanliness and project standard compliance (AFF, keywords, links) |
 | [`plan.md`](./workflows/plan.md) | Create or update an implementation plan (implementation_plan.md) |
-| [`release-manager.md`](./workflows/release-manager.md) | High-level release orchestrator for the Release Manager role |
-| [`release-notes-gen.md`](./workflows/release-notes-gen.md) | Generate detailed technical release notes for the current version |
-| [`release-preflight.md`](./workflows/release-preflight.md) | Pre-flight checks before triggering a git-flow release |
+| [`release-manager.md`](./workflows/release-manager.md) | Unified orchestrator for the complete release lifecycle |
 | [`run-tests.md`](./workflows/run-tests.md) | Comprehensive test suite execution (Unit, Regression, and Multi-DB) |
 | [`snapshot-to-test.md`](./workflows/snapshot-to-test.md) | Transform a running production issue into a reproducible test case |
 | [`specify.md`](./workflows/specify.md) | Create or update a feature specification (specification.md) |
 | [`tasks.md`](./workflows/tasks.md) | Break down an approved plan into actionable tasks (task.md) |
 
 
 ---
-*Generated automatically by `/doc-sync` on Sun Feb 15 22:45:08 CET 2026*
+*Generated automatically by `/doc-sync` on Thu Apr 16 17:03:00 CEST 2026*
diff --git a/.agent/rules/00_constitution.md b/.agent/rules/00_constitution.md
@@ -38,7 +38,7 @@ This project follows a standardized governance structure:
 - **Tier 03**: [03_execution_rules.md](file:///.agent/rules/03_execution_rules.md) (Constraints)
 - **Tier 04**: [04_best_practices.md](file:///.agent/rules/04_best_practices.md) (Implementation)
 - **Tier 05**: [05_memory_protocol.md](file:///.agent/rules/05_memory_protocol.md) (History)
-- **Dynamic**: [remembers.md](file:///.agent/rules/remembers.md) (Session Buffer)
+- **Dynamic**: Native Gemini Knowledge Items (KIs) managed via Antigravity Memory Protocol.
 
 ## ✅ Verification
 

diff --git a/.agent/rules/03_execution_rules.md b/.agent/rules/03_execution_rules.md
@@ -19,7 +19,7 @@ category: governance
 7. **ARTIFACT ROTATION:** Keep the `brain/` directory lean. Rotate old plans/walkthroughs after integration.
 8. **WEB SEARCH:** Assume world knowledge is out of date. Use web search for up-to-date documentation.
 
-9. **VERSION CONSISTENCY:** Version numbers MUST be synchronized across `CURRENT_VERSION.txt`, `Changelog`, and all occurrences within `mysqltuner.pl` (Header, internal variable, and POD documentation) before any release. Use `/release-preflight` to verify.
+9. **VERSION CONSISTENCY:** Version numbers MUST be synchronized across `CURRENT_VERSION.txt`, `Changelog`, and all occurrences within `mysqltuner.pl` (Header, internal variable, and POD documentation) before any release.
 10. **CONVENTIONAL COMMITS:** All commit messages MUST follow the [Conventional Commits](https://www.conventionalcommits.org/) specification. Use `npm run commit` for interactive commit creation. Compliance is enforced via `commitlint` and Git hooks.
 11. **NO DIRECT COMMIT:** All changes MUST be committed via `npm run commit` or `git cz` to ensure metadata quality and automated changelog compatibility.
 12. **VERSION SUPPORT POLICY:** Automated test example generation (via `run-tests`) MUST only target "Supported" versions of MySQL and MariaDB as defined in `mysql_support.md` and `mariadb_support.md`.
@@ -61,15 +61,17 @@ To ensure quality and clarity in every development cycle, all non-trivial featur
 1. **NO CHATTER:** No intro or conclusion sentences.
 2. **CODE ONLY:** Use Search_block / replace_block format for files > 50 lines.
 3. **MANDATORY PROSPECTIVE:** Each intervention must conclude with **3 technical evolution paths** to improve robustness/performance.
-4. **Compliance Sentinel Mandatory**: The `/compliance-sentinel` workflow MUST be successful before any major commit or release, ensuring adherence to the core constitution and dynamic rules from `remembers.md`.
-5. **MEMORY UPDATE:** Include the JSON MEMORY_UPDATE_PROTOCOL block at the very end.
+4. **Compliance Sentinel Mandatory**: The `/compliance-sentinel` workflow MUST be successful before any major commit or release, ensuring adherence to the core constitution and dynamic rules from native memory (KIs).
+5. **NATIVE MEMORY UPDATE:** Periodically synthesize learned project patterns into Gemini Knowledge Items (KIs) using native memory protocols instead of flat files.
 
 ### **4.4. Development Workflow**
 
 1. **Validation by Proof:** All changes must be verifiable via `make test-*` or dedicated test scripts.
 2. **Git Protocol:**
 
-- **STRICT PROHIBITION:** No `git commit`, `git push`, or `git tag` without using `/git-flow` or an explicit user order.
+- **STRICT PROHIBITION:** No `git commit`, `git push`, or `git tag` without an explicit user order.
+- **BRANCHING MANDATORY:** ALL developments, features, bug fixes, and interventions MUST be done in a dedicated Git branch separated from `master`. Committing directly to the `master` branch is strictly prohibited.
+- **UNIFIED RELEASE MANAGEMENT:** The entire release process (doc sync, testing, changelog generation, tagging, and branch creation) is now orchestrated exclusively by the `/release-manager` workflow. Do not run disjointed commands (`/git-flow`, `/release-preflight`, `/doc-sync`) manually.
 - **Conventional Commits:** Use `feat:`, `fix:`, `chore:`, `docs:`, `perf:`, `refactor:`, `style:`, `test:`, `ci:`. Breaking changes must be marked with `!` after type/scope or `BREAKING CHANGE:` in footer.
 - **Commit Validation:** Commits are automatically linted via `commitlint`. Non-compliant messages will be rejected by the pre-commit hook.
 - **History Documentation:** Use `npm run commit` to generate structured history.
@@ -82,5 +84,4 @@ To ensure quality and clarity in every development cycle, all non-trivial featur
     - _Requirement_: All feature completions MUST be synchronized with `ROADMAP.md` before final PR/Commit.
     - _Ordering_: Changelog entries MUST be ordered by category: `chore`, `feat`, `fix`, `test`, `ci`, then others.
     - _Release Notes_: All release notes generated in `releases/` MUST follow the same category ordering in their "Executive Summary" section.
-    - _Requirement_: The `/git-flow` workflow MUST always be preceded by a successful `/release-preflight` execution.
     - _Requirement_: Report files (HTML and logs) MUST NOT contain negative keywords (error, warning, fatal, failed) unless they are expected as part of a reproduction test case.
diff --git a/.agent/rules/04_best_practices.md b/.agent/rules/04_best_practices.md
@@ -80,14 +80,14 @@ Beyond hard constraints, following established patterns ensures code durability,
 
 ### 11. Release Integrity & Tagging
 
-- Release workflows (via `/git-flow`) MUST force push tags to the origin at each release to ensure synchronization with GitHub.
-- The `/git-flow` workflow MUST always be preceded by a successful `/release-preflight` execution.
-- Only the Release Manager is authorized to decide when to increment version numbers, or incrementing occurs automatically after a `git-flow` commit.
+- Release workflows MUST force push tags to the origin at each release to ensure synchronization with GitHub.
+- The entire release sequence (preflight, documentation sync, tagging, branch delivery) MUST be executed through the unified `/release-manager` workflow.
+- Version incrementing MUST only happen upon an explicit request. Automatic version bumping is strictly prohibited.
 
 ### 13. Release Artifact Integrity
 
 - Every release MUST be accompanied by a technical release note in `releases/v[VERSION].md`.
-- The `/release-preflight` workflow MUST verify the existence of this file before allowing a release to proceed.
+- The `/release-manager` workflow handles the generation and verification of this file automatically.
 - Omission of release artifacts is considered a regression in project governance.
 
 ### 14. Artifact Hygiene (Workstation Abstraction)
@@ -97,7 +97,7 @@ Beyond hard constraints, following established patterns ensures code durability,
 
 ### 15. Release Note Integrity
 
-- Release notes MUST be verified in `/release-preflight` to prevent omission on the remote repository.
+- Release notes MUST be verified during the `/release-manager` orchestration to prevent omission on the remote repository.
 - Ensure `releases/v[VERSION].md` exists and is synchronized with the current release.
 
 ## ✅ Verification

diff --git a/.agent/rules/05_memory_protocol.md b/.agent/rules/05_memory_protocol.md
diff --git a/.agent/rules/remembers.md b/.agent/rules/remembers.md
diff --git a/.agent/workflows/git-flow.md b/.agent/workflows/git-flow.md
@@ -8,7 +8,27 @@ category: tool
 
 This workflow MUST be orchestrated by the **Release Manager**.
 
-1. **Run Release Preflight Workflow**
+## 🧠 Constraints
+
+- **Branch Mandatory**: The release process MUST only be executed on a dedicated branch named `vX.XX.XX` (e.g., `v2.8.41`).
+- **No Main Modification**: Pushing to the `main` or `master` branch is strictly prohibited here.
+- **No Automatic Bumping**: Version numbers MUST NOT be automatically incremented after release unless explicitly requested by the user.
+
+## 🛠️ Implementation
+
+// turbo
+1. **Branch Verification**
+   - Verify the current Git branch matches the `vX.XX.XX` pattern.
+
+   ```bash
+   CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
+   if [[ ! "$CURRENT_BRANCH" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+     echo "ERROR: Release process must be executed on a vX.XX.XX branch."
+     exit 1
+   fi
+   ```
+
+2. **Run Release Preflight Workflow**
    - Execute the `/release-preflight` workflow to ensure full consistency and test passing.
    - **CRITICAL**: Do NOT proceed if `/release-preflight` fails.
 
@@ -18,8 +38,8 @@ This workflow MUST be orchestrated by the **Release Manager**.
    ```
 
    // turbo
-2. **Commit Current Changes**
-   - Commit all pending changes including `Changelog` updates for the current version.
+3. **Commit Release Notes**
+   - Commit all pending changes. The commit message MUST be strictly formatted as the release notes extracted from the `Changelog`.
 
    ```bash
    # Extract content between the first version header and the next one
@@ -30,47 +50,19 @@ This workflow MUST be orchestrated by the **Release Manager**.
    ```
 
    // turbo
-3. **Create Tag for Current Version with Changelog content**
-   - Extract the latest release notes and create an annotated tag.
+4. **Create Tag for Current Version**
+   - Create an annotated tag incorporating the release notes.
 
    ```bash
-   # Extract content between the first version header and the next one
-   TAG_MSG=$(awk "/^$CURRENT_VER/,/^([0-9]+\.[0-9]+\.[0-9]+)/ {if (\$0 !~ /^([0-9]+\.[0-9]+\.[0-9]+)/) print}" Changelog | sed '/^$/d')
-   git tag -a v$CURRENT_VER -m "Release $CURRENT_VER" -m "$TAG_MSG"
+   git tag -a v$CURRENT_VER -m "Release $CURRENT_VER" -m "$RELEASE_NOTES"
    ```
 
    // turbo
-4. **Push Branch and Tag**
-   - Push to the remote repository.
+5. **Push Branch and Tag**
+   - Push the current branch and the tag to the remote repository.
 
    ```bash
-   git push origin main
-   git push origin v$CURRENT_VER
+   git push origin refs/heads/$CURRENT_BRANCH
+   git push origin refs/tags/v$CURRENT_VER
    ```
 
-   // turbo
-5. **Post-Push: Increment Version for Next Cycle**
-   - Calculate the next patch version and update files.
-
-   ```bash
-   NEW_VER=$(echo $CURRENT_VER | awk -F. '{print $1"."$2"."($3+1)}')
-   echo $NEW_VER > CURRENT_VERSION.txt
-   # Update all version occurrences in mysqltuner.pl
-   perl -pi -e "s/\Q$CURRENT_VER\E/$NEW_VER/g" mysqltuner.pl
-
-   DATE=$(date +%Y-%m-%d)
-   echo -e "$NEW_VER $DATE\n\n- \n" > tmp_changelog && cat Changelog >> tmp_changelog && mv tmp_changelog Changelog
-   ```
-
-   // turbo
-6. **Commit Version Bump**
-   - Commit the incremented version for the next development cycle.
-
-   ```bash
-   git add CURRENT_VERSION.txt mysqltuner.pl Changelog
-   npx commitlint --from=HEAD~1 # Or simply use npm run commit if not automated
-   git commit -m "chore: bump version to $NEW_VER"
-   git push origin main
-   ```
-
-   // turbo
diff --git a/.agent/workflows/release-manager.md b/.agent/workflows/release-manager.md
@@ -9,23 +9,16 @@ This workflow orchestrates the full release lifecycle. It MUST be executed by th
 
 ## 🧠 Rationale
 
-Release integrity is guaranteed through a formal, guided protocol that minimizes manual error and ensures 100% logic validation across all transports (Standard, Container, Dumpdir).
+Release integrity is guaranteed through a unified, formal protocol that minimizes manual error, consolidates numerous fragmented steps, and ensures 100% logic validation across all environments.
 
 ## 🛠️ Implementation
 
 ### 1. Preparation & Validation
 
 Before cutting a release, ensure the environment and code are stable.
-
-// turbo
-
-```bash
-# 1. Synchronize documentation
-/doc-sync
-
-# 2. Run comprehensive pre-flight checks
-/release-preflight
-```
+1. Synchronize `.agent/README.md` with current Rules, Skills, and Workflows.
+2. Verify version consistency across `CURRENT_VERSION.txt`, `Changelog`, and `mysqltuner.pl`.
+3. Audit for any uncommitted changes or missing files.
 
 ### 2. Multi-Version Testing
 
@@ -34,34 +27,28 @@ Execute the industrial-grade test suite against multiple DB versions.
 // turbo
 
 ```bash
-# 3. Validating against all core versions
+# Validating against all core versions
 make test-all
 ```
 
-### 3. Artifact Generation
+### 3. Artifact & Notes Generation
 
 Generate technical documents for the new version.
-
-// turbo
-
-```bash
-# 4. Generate release notes
-/release-notes-gen
-```
+1. Draft comprehensive release notes in `releases/v[VERSION].md` summarizing changes from `@Changelog`.
+2. Format using Conventional Commits classification.
 
 ### 4. Git-Flow Execution
 
 If all previous steps pass (Exit Code 0), proceed with the formal release.
-
-// turbo
-
-```bash
-# 5. Execute git-flow
-/git-flow
-```
+1. Ensure you are on a release branch `vX.XX.XX`.
+2. Commit all changes including documentation and release notes via `npm run commit` or `git cz`.
+3. Merge branch back to `master`.
+4. Tag the release on `master` with the new version.
+5. Force push tags and `master` to origin.
 
 ## ✅ Verification
 
-- All workflows must return Success.
-- Final version consistency check in `v2.9.0` release notes.
-- Tag and Push verified in remote repository.
+- Tests pass successfully across all supported versions.
+- Release notes exist in `releases/v[VERSION].md`.
+- Git history correctly reflects semantic versions and tags.
+
diff --git a/.agent/workflows/release-preflight.md b/.agent/workflows/release-preflight.md
@@ -27,7 +27,7 @@ SCRIPT_POD_NAME_VER=$(grep "MySQLTuner [0-9.]* - MySQL High Performance" mysqltu
 SCRIPT_POD_VER=$(grep "^Version [0-9.]*" mysqltuner.pl | awk '{print $2}')
 
 # 6. Changelog latest version
-LOG_VER=$(head -n 1 Changelog | awk '{print $1}')
+LOG_VER=$(grep "^[0-9]" Changelog | head -n 1 | awk '{print $1}')
 ```
 
 ## 2. Validate Consistency
@@ -85,7 +85,7 @@ Ensure all commits since the last release follow Conventional Commits.
 ```bash
 LAST_TAG=$(git describe --tags --abbrev=0)
 echo "Validating commits since $LAST_TAG..."
-npx commitlint --from=$LAST_TAG --to=HEAD
+npx commitlint --from="tags/$LAST_TAG" --to=HEAD
 ```
 
 ## 5. Markdown Integrity

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
@@ -0,0 +1,11 @@
+# To get started with Dependabot version updates, you'll need to specify which
+# package ecosystems to update and where the package manifests are located.
+# Please see the documentation for all configuration options:
+# https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
+
+version: 2
+updates:
+  - package-ecosystem: "" # See documentation for possible values
+    directory: "/" # Location of package manifests
+    schedule:
+      interval: "weekly"