diff --git a/.gitignore b/.gitignore
index 75cafa0..3255a8e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -71,4 +71,5 @@ cmake/*
 db.sql
 revoir.md
 main.cpp
-.vix-scripts
\ No newline at end of file
+.vix-scripts
+Makefile
\ No newline at end of file
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 2dfd4a5..18d3a47 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -8,7 +8,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ---
 
 ## [Unreleased]
-## [1.14.7] - 2025-12-19
+## [1.15.0] - 2025-12-20
 
 ### Added
 - 
@@ -20,6 +20,46 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - 
 
 
+## v1.15.0 — 2025-12-20
+
+### Added
+
+- **`vix check`**: validate a project or compile a single `.cpp` file without execution.
+- **`vix tests`**: run project tests (alias of `vix check --tests`).
+- **`vix verify`**: verify packaged artifacts and signatures.
+- CLI reference documentation (`docs/vix-cli-help.md`).
+- Pull Request template to standardize contributions.
+
+### Changed
+
+- Improved global CLI help output formatting and readability.
+- Updated README with clearer CLI usage and script mode examples.
+- Updated security testing documentation with realistic, tool-based practices.
+- Improved contributing guidelines and code of conduct.
+
+### Removed
+
+- Deprecated `SECURITY.md` in favor of a more accurate security testing guide.
+
+### Notes
+
+- This release significantly improves **CLI usability**, **testing workflow**, and **project governance**.
+- Recommended upgrade for all users relying on the Vix CLI.
+
+## [1.14.7] - 2025-12-19
+
+### Added
+
+-
+
+### Changed
+
+-
+
+### Removed
+
+-
+
 ## v1.14.7 — CLI Packaging Stability Update
 
 ### Fixed
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a423382..ec552e6 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -13,7 +13,7 @@ cmake_minimum_required(VERSION 3.20)
 #   cmake --build build -j
 # ====================================================================
 
-project(vix VERSION 1.14.0 LANGUAGES CXX)
+project(vix VERSION 1.15.0 LANGUAGES CXX)
 
 # Make find_package honor *_ROOT hints (e.g. MYSQLCPPCONN_ROOT)
 if (POLICY CMP0144)
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 41d0213..018947b 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -1,107 +1,119 @@
-# 🌍 Vix.cpp Code of Conduct
+# Vix.cpp Code of Conduct
 
-## 🧭 Our Commitment
+## Our Commitment
 
-We are committed to building a welcoming, collaborative, and respectful community around **Vix.cpp** —  
-a place where developers from all backgrounds can learn, build, and innovate together.
+We are committed to fostering a welcoming, inclusive, and professional community around **Vix.cpp**.
 
-We pledge to make participation in this project and community a harassment-free experience for everyone,  
-regardless of:
+We want this project to be a place where developers from all backgrounds can collaborate, learn, and build high-quality software together, free from harassment or discrimination.
 
-- age, body size, disability, ethnicity, gender identity and expression,
-- level of experience, education, nationality, personal appearance, race,
-- religion, sexual identity and orientation.
+We pledge to make participation in this project a harassment-free experience for everyone, regardless of:
+
+- age, body size, disability, ethnicity, nationality
+- gender identity or expression
+- level of experience or education
+- personal appearance
+- race, religion, sexual identity, or orientation
 
 ---
 
-## 🤝 Our Standards
+## Our Standards
+
+### Expected Behavior
 
-### Examples of behavior that contribute to a positive environment:
+Contributors are expected to:
 
-- Being respectful and constructive in all interactions.
-- Providing helpful feedback without personal attacks.
-- Welcoming new members and supporting beginners.
-- Focusing on what is best for the community and the project.
-- Giving credit where it is due and recognizing contributions.
+- Be respectful, professional, and constructive in all interactions
+- Provide feedback focused on ideas and code, not individuals
+- Welcome newcomers and support less experienced contributors
+- Respect differing viewpoints and experiences
+- Give proper credit for others’ work and ideas
+- Act in the best interest of the project and its community
 
-### Examples of unacceptable behavior:
+### Unacceptable Behavior
 
-- Use of sexualized language or imagery, or unwelcome advances.
-- Trolling, insulting or derogatory comments.
-- Public or private harassment of any kind.
-- Publishing others’ private information (addresses, emails, etc.) without explicit permission.
-- Any behavior that would reasonably be considered inappropriate in a professional setting.
+The following behaviors are not tolerated:
+
+- Sexualized language, imagery, or unwelcome advances
+- Trolling, insulting, or derogatory comments
+- Harassment, intimidation, or threats (public or private)
+- Publishing private information about others without explicit permission
+- Any conduct that would reasonably be considered inappropriate in a professional environment
 
 ---
 
-## 🛠 Enforcement Responsibilities
+## Enforcement Responsibilities
+
+Project maintainers are responsible for clarifying and enforcing this Code of Conduct.
 
-Project maintainers are responsible for clarifying and enforcing our standards.  
-They may remove, edit, or reject contributions that violate this Code of Conduct.
+They may remove, edit, or reject comments, commits, issues, pull requests, or other contributions that violate these standards.
 
-They have the right and responsibility to temporarily or permanently ban any contributor  
-for behavior they deem inappropriate, threatening, or harmful.
+Maintainers may also temporarily or permanently ban contributors whose behavior they deem harmful, abusive, or disruptive.
 
 ---
 
-## 🧾 Scope
+## Scope
 
-This Code of Conduct applies both within project spaces (GitHub issues, discussions, pull requests)  
-and in public spaces when an individual is representing the project or its community.
+This Code of Conduct applies within all project spaces, including but not limited to:
 
-Examples include:
+- GitHub issues, pull requests, discussions, and code reviews
+- Official communication channels related to Vix.cpp
 
-- Using the official project email or social media accounts.
-- Acting as an official representative at an event or conference.
+It also applies when an individual is representing the project in public spaces, such as:
+
+- Using official project communication channels
+- Representing Vix.cpp at events, conferences, or online discussions
 
 ---
 
-## ⚖️ Enforcement
+## Enforcement
 
-If you experience or witness unacceptable behavior, please report it as soon as possible by emailing:
+If you experience or witness behavior that violates this Code of Conduct, please report it by contacting:
 
-📧 **vixcpp.framework@gmail.com**
+**Email:** gaspardkirira@outlook.com
 
-All complaints will be reviewed and investigated promptly and fairly.  
-All maintainers are obligated to respect the privacy and safety of reporters.
+All reports will be reviewed promptly and handled with discretion.  
+Project maintainers are committed to respecting the privacy and safety of everyone involved.
 
 ---
 
-## ⚙️ Enforcement Guidelines
+## Enforcement Guidelines
 
-Project maintainers will follow these guidelines when determining consequences for any action they deem in violation of this Code of Conduct.
+When determining appropriate consequences, maintainers will consider the context, severity, and history of the behavior.
 
 ### 1. Correction
 
-**Impact:** Use of inappropriate language or other unprofessional conduct.  
-**Consequence:** Private, written warning and clarification of expected behavior.
+**Impact:** Minor unprofessional or inappropriate behavior.  
+**Consequence:** Private clarification and guidance on expected conduct.
 
 ### 2. Warning
 
-**Impact:** A single incident or series of small violations.  
-**Consequence:** Warning and temporary exclusion from some interactions.
+**Impact:** Repeated minor violations or a single significant incident.  
+**Consequence:** Formal warning and possible temporary limitations on participation.
 
 ### 3. Temporary Ban
 
-**Impact:** Repeated or severe violations.  
-**Consequence:** Temporary ban from participation in discussions, issues, or contributions.
+**Impact:** Serious or repeated violations of community standards.  
+**Consequence:** Temporary suspension from participation in project spaces.
 
 ### 4. Permanent Ban
 
-**Impact:** Long-term pattern of harmful behavior.  
-**Consequence:** Permanent removal from all community channels.
+**Impact:** Sustained pattern of abusive, hostile, or harmful behavior.  
+**Consequence:** Permanent removal from all project-related spaces.
 
 ---
 
-## ❤️ Attribution
+## Attribution
+
+This Code of Conduct is adapted from the  
+[Contributor Covenant, version 2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html).
 
-This Code of Conduct is adapted from the [Contributor Covenant, version 2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html).  
-For answers to common questions, see the FAQ at:  
-👉 https://www.contributor-covenant.org/faq
+For additional information, see:  
+https://www.contributor-covenant.org/faq
 
 ---
 
-### 💡 Summary
+## Summary
+
+All contributors are expected to act with professionalism, respect, and integrity.
 
-> **Be kind. Be professional. Be helpful.**  
-> We are all here to make **Vix.cpp** — and the C++ ecosystem — better for everyone.
+By participating in **Vix.cpp**, you help build not only high-performance software, but also a healthy and collaborative community.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index e40664b..cc59bf0 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,32 +1,49 @@
-# 🧭 Contributing to Vix.cpp
+# Contributing to Vix.cpp
 
-Thank you for your interest in contributing to **Vix.cpp** —  
+Thank you for your interest in contributing to **Vix.cpp**,  
 a modern, high-performance C++ backend framework.
 
-We welcome contributions of all kinds:
+This document explains **how to contribute effectively**, what kinds of contributions are welcome, and the standards expected when submitting changes.
 
-- 🧱 Core improvements (routing, HTTP, middleware, etc.)
-- ⚙️ Utility modules (logging, validation, JSON, etc.)
-- 🧩 Examples and documentation
-- 🐛 Bug reports and performance tuning
+---
+
+## Project Scope & Contribution Areas
+
+We welcome contributions in the following areas:
+
+- Core runtime improvements (HTTP server, routing, middleware, async model)
+- Utility modules (logging, validation, JSON, configuration)
+- CLI tooling (commands, UX, diagnostics, dev workflow)
+- ORM and database integrations
+- WebSocket and real-time components
+- Documentation, guides, and examples
+- Bug fixes, performance improvements, and benchmarks
+
+If you are unsure where to start, look for issues labeled **`good first issue`** or **`devx`**.
 
 ---
 
-## 🧠 Philosophy
+## Project Philosophy
 
-Vix.cpp aims to bring **FastAPI-like developer experience** and **Go-like speed**  
-to the C++ world — without sacrificing simplicity or readability.
+Vix.cpp aims to bring:
 
-Contributions should always follow these principles:
+- FastAPI-like developer experience
+- Go-like performance characteristics
+- C++20/23 correctness and control
 
-- 🧼 Clear and readable C++20 code
-- 🧩 Modular, header-only where possible
-- ⚡ High performance and low memory overhead
-- 🧠 Self-documenting with concise comments
+All contributions should follow these core principles:
+
+- Clear, readable, modern C++ (C++20 minimum)
+- Modular design with minimal coupling
+- High performance and predictable memory usage
+- Explicit behavior and well-defined ownership
+- Concise, meaningful comments where needed
+
+Simplicity and correctness are preferred over cleverness.
 
 ---
 
-## ⚙️ Setup for Local Development
+## Local Development Setup
 
 ### 1. Clone the repository
 
@@ -36,65 +53,77 @@ cd vix
 git submodule update --init --recursive
 ```
 
-2. Build with CMake
+### 2. Configure and build
 
 ```bash
 cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
 cmake --build build -j
 ```
 
-You can enable examples for quick testing:
+To enable examples:
 
 ```bash
 cmake -S . -B build -DVIX_BUILD_EXAMPLES=ON
 ```
 
-## 🧪 Running Examples
+---
+
+## Running Examples
 
-To test your environment:
+To verify your setup:
 
 ```bash
 cd build
 ./main
 ```
 
-##### Test the basic route:
+Test the basic route:
 
 ```bash
 curl http://localhost:8080/hello
 ```
 
-### Expected output:
+Expected output:
 
 ```json
 { "message": "Hello, Vix!" }
 ```
 
-# 🧩 Code Style Guidelines
+---
+
+## Code Style Guidelines
 
-Follow C++ Core Guidelines and modern C++20 conventions.
-Prefer auto only when the type is obvious.
-Use namespaces to organize code (Vix::core, Vix::utils, etc.).
-Avoid global state (use singletons or dependency injection when necessary).
-Each .hpp file should have proper include guards or #pragma once.
+Vix.cpp follows modern C++ best practices:
 
-## Example
+- Follow the C++ Core Guidelines
+- Prefer explicit types over excessive `auto`
+- Use namespaces consistently (`Vix::core`, `Vix::utils`, etc.)
+- Avoid global state; use dependency injection or scoped singletons
+- All headers must use `#pragma once` or include guards
+- Header files should not include unnecessary dependencies
+
+### Example
 
 ```cpp
 namespace Vix::utils {
+
 class Logger {
 public:
-    static Logger& getInstance();
-    void info(const std::string& msg);
+    static Logger& instance();
+    void info(const std::string& message);
+
 private:
     Logger() = default;
 };
+
 } // namespace Vix::utils
 ```
 
-# 🧱 CMake Conventions
+---
+
+## CMake Conventions
 
-Each module must define its own CMakeLists.txt:
+Each module must define its own `CMakeLists.txt`.
 
 ```cmake
 add_library(vix_core STATIC
@@ -107,16 +136,21 @@ target_link_libraries(vix_core PUBLIC Boost::asio nlohmann_json::nlohmann_json)
 add_library(Vix::core ALIAS vix_core)
 ```
 
-Use the Vix:: namespace for all exported targets.
-Never use global include_directories() — use target_include_directories().
+Rules:
 
-# 🧩 Submitting Changes
+- Use the `Vix::` namespace for all exported targets
+- Never use global `include_directories()`
+- Prefer `target_*` commands exclusively
+
+---
+
+## Submitting Changes
 
 1. Fork the repository
 2. Create a feature branch:
 
 ```bash
-git checkout -b feat/my-awesome-feature
+git checkout -b feat/my-feature
 ```
 
 3. Make your changes and commit them:
@@ -128,77 +162,94 @@ git commit -m "feat(core): add new router handler"
 4. Push your branch:
 
 ```bash
-git push origin feat/my-awesome-feature
+git push origin feat/my-feature
 ```
 
-5. Open a Pull Request (PR) with:
+5. Open a Pull Request including:
+   - A clear description of the change
+   - Motivation and design decisions
+   - Linked issues (if applicable)
+   - Benchmarks or usage examples when relevant
+
+---
+
+## Testing Guidelines
 
-. A clear description of your change
-. Linked issues (if any)
-. Example usage or benchmark results
+All new features and fixes must include tests.
 
-# 🧪 Testing Guidelines
+- Place unit tests under `tests/` or `unittests/`
+- Use GoogleTest for consistency
 
-All modules must include basic unit tests under /tests or /unittests.
+Run tests with:
 
 ```bash
 cd build
 ctest --output-on-failure
 ```
 
-Use GoogleTest for consistency:
+Example test:
 
 ```cpp
 #include <gtest/gtest.h>
 
 TEST(LoggerTest, BasicOutput) {
-    auto& log = Vix::Logger::getInstance();
-    EXPECT_NO_THROW(log.info("Hello"));
+    auto& logger = Vix::utils::Logger::instance();
+    EXPECT_NO_THROW(logger.info("Hello"));
 }
 ```
 
-# ⚡ Performance Benchmarks
+---
+
+## Performance Considerations
 
-Before merging significant changes, run:
+For performance-sensitive changes, run benchmarks before submitting:
 
 ```bash
 wrk -t8 -c100 -d10s http://localhost:8080/hello
 ```
 
-Record your results (Requests/sec, Latency, Memory).
+Include results when relevant:
 
-```markdown
-## 🧾 Commit Convention
+- Requests/sec
+- Latency (avg / p99)
+- Memory impact
 
-Suivez le format [Conventional Commits](https://www.conventionalcommits.org/) :
+---
 
-| Type        | Description                |
-| ----------- | -------------------------- |
-| `feat:`     | New feature or improvement |
-| `fix:`      | Bug fix                    |
-| `refactor:` | Code refactoring           |
-| `test:`     | Adding or improving tests  |
-| `docs:`     | Documentation updates      |
-| `chore:`    | Maintenance tasks          |
-```
+## Commit Convention
+
+Vix.cpp follows **Conventional Commits**:
+
+| Type      | Description                    |
+| --------- | ------------------------------ |
+| feat:     | New feature or improvement     |
+| fix:      | Bug fix                        |
+| refactor: | Internal code refactoring      |
+| test:     | Adding or improving tests      |
+| docs:     | Documentation updates          |
+| chore:    | Maintenance or tooling changes |
 
-# Example:
+Examples:
 
 ```bash
 feat(core): add middleware chaining support
 fix(utils): prevent null pointer in UUID generator
 ```
 
-# 💬 Communication
+---
+
+## Communication
 
-Open issues for bugs or ideas.
-Discuss architecture in PR comments or GitHub Discussions.
-Be respectful and concise.
+- Use GitHub Issues for bugs and feature proposals
+- Use Pull Request discussions for design decisions
+- Keep discussions technical, respectful, and focused
+
+---
 
-# 🪪 License
+## License
 
 By contributing to Vix.cpp, you agree that your contributions
-will be licensed under the same MIT License as the main project.
+will be licensed under the **MIT License**, the same as the main project.
 
 ---
 
diff --git a/Makefile.release b/Makefile.release
new file mode 100644
index 0000000..59f577d
--- /dev/null
+++ b/Makefile.release
@@ -0,0 +1,159 @@
+# -------- Release Makefile (robuste et reprenable) --------
+#
+# Compatible with strict GitHub repository rules:
+# - main is protected: changes must go through a Pull Request
+# - main must not contain merge commits (use SQUASH or REBASE in GitHub)
+#
+# Workflow:
+#   make -f Makefile.release release VERSION=vX.Y.Z
+#   -> prepares release on dev (commit + push) + prints PR instructions
+#   -> open PR dev -> main and merge using SQUASH/REBASE (no merge commit)
+#   make -f Makefile.release tag VERSION=vX.Y.Z
+#   -> creates annotated tag on main after PR merge (recommended)
+#
+# ----------------------------------------------------------
+
+VERSION ?= v0.1.0
+BRANCH_DEV  = dev
+BRANCH_MAIN = main
+
+# If VERSION doesn't start with "v", prefix it.
+# Examples:
+#   VERSION=1.9.0  -> TAG=v1.9.0
+#   VERSION=v1.9.0 -> TAG=v1.9.0
+TAG := $(if $(filter v%,$(VERSION)),$(VERSION),v$(VERSION))
+
+.PHONY: help \
+	release release-fast \
+	commit push \
+	tag resume-tag \
+	pr-instructions \
+	test changelog \
+	submodules submodules-remote \
+	gh-release \
+	assert-dev assert-main assert-clean
+
+help:
+	@echo "Available commands:"
+	@echo "  make -f Makefile.release release VERSION=vX.Y.Z       - Prepare release on $(BRANCH_DEV): changelog + commit + push + PR instructions"
+	@echo "  make -f Makefile.release release-fast VERSION=vX.Y.Z  - Same as release but without changelog step"
+	@echo "  make -f Makefile.release commit                       - Commit on $(BRANCH_DEV) (if there are changes)"
+	@echo "  make -f Makefile.release push                         - Push $(BRANCH_DEV)"
+	@echo "  make -f Makefile.release tag VERSION=vX.Y.Z           - Create and push annotated tag on $(BRANCH_MAIN) (run after PR merge)"
+	@echo "  make -f Makefile.release resume-tag VERSION=vX.Y.Z    - Only (re)push the tag step"
+	@echo "  make -f Makefile.release gh-release VERSION=vX.Y.Z    - Create GitHub release from TAG (needs 'gh')"
+	@echo "  make -f Makefile.release submodules                   - Sync/init submodules"
+	@echo "  make -f Makefile.release test                         - Run ctest from ./build"
+	@echo "Current VERSION=$(VERSION) -> TAG=$(TAG)"
+
+# --- Guards ---
+
+assert-dev:
+	@if [ "$$(git rev-parse --abbrev-ref HEAD)" != "$(BRANCH_DEV)" ]; then \
+		echo "ℹ️  Switching to $(BRANCH_DEV)"; \
+		git checkout $(BRANCH_DEV); \
+	fi
+
+assert-main:
+	@if [ "$$(git rev-parse --abbrev-ref HEAD)" != "$(BRANCH_MAIN)" ]; then \
+		echo "ℹ️  Switching to $(BRANCH_MAIN)"; \
+		git checkout $(BRANCH_MAIN); \
+	fi
+
+assert-clean:
+	@if [ -n "$$(git status --porcelain)" ]; then \
+		echo "❌ Working tree not clean. Commit or stash before continuing."; \
+		exit 1; \
+	fi
+
+# --- Steps ---
+
+commit: assert-dev
+	@if [ -n "$$(git status --porcelain)" ]; then \
+		echo "📝 Committing changes on $(BRANCH_DEV)..."; \
+		git add .; \
+		git commit -m "chore(release): prepare $(TAG)"; \
+	else \
+		echo "✅ Nothing to commit on $(BRANCH_DEV)."; \
+	fi
+
+push: assert-dev
+	@echo "⬆️  Pushing $(BRANCH_DEV)..."
+	@for i in 1 2 3; do \
+		git push origin $(BRANCH_DEV) && s=0 && break || s=$$?; \
+		echo "⚠️  Push $(BRANCH_DEV) failed (try $$i/3). Retrying in 2s..."; \
+		sleep 2; \
+	done; exit $$s
+
+# Create and push annotated tag on main AFTER the PR is merged.
+tag: assert-main assert-clean
+	@if git rev-parse --verify --quiet $(TAG) >/dev/null; then \
+		echo "ℹ️  Local tag $(TAG) already exists."; \
+	else \
+		echo "🏷️  Creating annotated tag $(TAG) on $(BRANCH_MAIN)..."; \
+		git tag -a $(TAG) -m "Release version $(TAG)"; \
+	fi; \
+	if git ls-remote --tags origin $(TAG) | grep -q "$(TAG)"; then \
+		echo "✅ Remote already has tag $(TAG). Nothing to push."; \
+	else \
+		echo "⬆️  Pushing tag $(TAG) to origin..."; \
+		for i in 1 2 3; do \
+			git push origin $(TAG) && s=0 && break || s=$$?; \
+			echo "⚠️  Push tag failed (try $$i/3). Retrying in 2s..."; \
+			sleep 2; \
+		done; exit $$s; \
+	fi
+
+resume-tag:
+	@$(MAKE) -f Makefile.release tag VERSION=$(VERSION)
+
+release:
+	@$(MAKE) -f Makefile.release changelog
+	@$(MAKE) -f Makefile.release commit VERSION=$(VERSION)
+	@$(MAKE) -f Makefile.release push
+	@$(MAKE) -f Makefile.release pr-instructions VERSION=$(VERSION)
+	@echo "✅ Release $(TAG) prepared on $(BRANCH_DEV)."
+	@echo "ℹ️  After merging the PR (SQUASH/REBASE), run:"
+	@echo "    make -f Makefile.release tag VERSION=$(VERSION)"
+
+release-fast:
+	@$(MAKE) -f Makefile.release commit VERSION=$(VERSION)
+	@$(MAKE) -f Makefile.release push
+	@$(MAKE) -f Makefile.release pr-instructions VERSION=$(VERSION)
+	@echo "✅ Release $(TAG) prepared on $(BRANCH_DEV) (fast)."
+	@echo "ℹ️  After merging the PR (SQUASH/REBASE), run:"
+	@echo "    make -f Makefile.release tag VERSION=$(VERSION)"
+
+pr-instructions:
+	@echo ""
+	@echo "Next step (required by repo rules):"
+	@echo "  1) Open a Pull Request: $(BRANCH_DEV) -> $(BRANCH_MAIN)"
+	@echo "  2) Merge using SQUASH (recommended) or REBASE."
+	@echo "     Do NOT create a merge commit."
+	@echo "  3) After merge, tag on main:"
+	@echo "     make -f Makefile.release tag VERSION=$(VERSION)"
+	@echo "  4) Optionally publish a GitHub Release from tag $(TAG)."
+	@echo ""
+
+gh-release:
+	@if ! command -v gh >/dev/null 2>&1; then \
+		echo "❌ 'gh' CLI not found. Install GitHub CLI to use this target."; \
+		exit 1; \
+	fi
+	@echo "📦 Creating GitHub Release for $(TAG)..."
+	@gh release create $(TAG) --title "$(TAG)" --notes-file CHANGELOG.md || \
+		{ echo "⚠️  'gh release' failed. Maybe it already exists?"; exit 0; }
+
+test:
+	@cd build && ctest --output-on-failure
+
+changelog:
+	@bash scripts/update_changelog.sh
+
+submodules:
+	@./scripts/submodules-sync.sh
+
+submodules-remote:
+	@./scripts/submodules-sync.sh remote
+
+# ----------------------------------------------------------
diff --git a/PULL_REQUEST_TEMPLATE.md b/PULL_REQUEST_TEMPLATE.md
new file mode 100644
index 0000000..a08c04e
--- /dev/null
+++ b/PULL_REQUEST_TEMPLATE.md
@@ -0,0 +1,100 @@
+# Pull Request Checklist
+
+Thank you for contributing to **Vix.cpp**.  
+Please review this checklist before submitting your Pull Request.
+
+---
+
+## Summary
+
+### What does this PR do?
+
+<!-- Briefly describe the change and its purpose -->
+
+### Related issues
+
+<!-- Link related issues, e.g. Fixes #123 -->
+
+---
+
+## Type of Change
+
+Please check the relevant option(s):
+
+- [ ] New feature
+- [ ] Bug fix
+- [ ] Refactoring (no behavior change)
+- [ ] Performance improvement
+- [ ] Documentation update
+- [ ] Build / tooling / CI change
+- [ ] Other (please describe):
+
+---
+
+## Code Quality
+
+- [ ] Code follows the project style and conventions
+- [ ] C++20 (or newer) features are used appropriately
+- [ ] No unnecessary complexity introduced
+- [ ] No unused code, headers, or debug logs
+- [ ] Public APIs are documented where applicable
+
+---
+
+## Tests
+
+- [ ] Existing tests pass locally
+- [ ] New tests were added for new behavior or fixes
+- [ ] Tests are located under `tests/` or `unittests/`
+- [ ] `ctest --output-on-failure` passes
+
+---
+
+## Performance (if applicable)
+
+- [ ] Change has no negative performance impact
+- [ ] Benchmarks were run for performance-sensitive changes
+- [ ] Results are included or described in the PR
+
+---
+
+## CLI / UX (if applicable)
+
+- [ ] CLI output is clear and consistent
+- [ ] Help (`-h` / `--help`) output was updated if needed
+- [ ] Exit codes follow project conventions
+
+---
+
+## Documentation
+
+- [ ] Documentation was updated (README / docs)
+- [ ] Examples were added or updated if relevant
+- [ ] Comments explain non-obvious logic
+
+---
+
+## CMake / Build System
+
+- [ ] CMakeLists changes are minimal and scoped
+- [ ] Uses `target_*` commands only (no global includes)
+- [ ] Targets are exported under the `Vix::` namespace
+
+---
+
+## Final Checks
+
+- [ ] I have rebased on the latest `dev` branch
+- [ ] Commit messages follow Conventional Commits
+- [ ] This PR is ready for review
+
+---
+
+## Additional Notes
+
+<!-- Add any additional context, trade-offs, or follow-up work -->
+
+---
+
+By submitting this Pull Request, I confirm that my contribution is licensed
+under the same **MIT License** as the Vix.cpp project.
diff --git a/README.md b/README.md
index af94b62..6b7229d 100644
--- a/README.md
+++ b/README.md
@@ -24,7 +24,7 @@
 
 ---
 
-# 🌍 What is Vix?
+# What is Vix?
 
 **Vix** is a next-generation **offline-first, peer-to-peer, ultra-fast runtime for modern C++**.
 
@@ -68,8 +68,6 @@ Results represent steady-state throughput on a simple `"OK"` endpoint.
 
 ---
 
-## 📝 Notes
-
 ### ✔ Why Vix.cpp reaches Go-level performance
 
 - zero-cost abstractions
@@ -82,13 +80,6 @@ Results represent steady-state throughput on a simple `"OK"` endpoint.
 
 ---
 
-## 🦕 Deno benchmark (reference)
-
-```bash
-$ wrk -t8 -c800 -d30s --latency http://127.0.0.1:8000
-Requests/sec: 48,868.73
-```
-
 ### ✔ Vix.cpp recommended benchmark mode
 
 When benchmarking from inside the Vix.cpp repository (using the built-in example):
@@ -132,7 +123,7 @@ using namespace Vix;
 int main() {
     App app;
 
-    app.get("/", [](auto&, auto& res) {
+    app.get("/", [](Request, Request res) {
         res.json({ "message", "Hello world" });
     });
 
@@ -140,13 +131,13 @@ int main() {
 }
 ```
 
-### QueryBuilder ORM
+## Route Parameters
 
 ```cpp
-QueryBuilder qb;
-qb.raw("UPDATE users SET age=? WHERE email=?")
-  .param(29)
-  .param("zoe@example.com");
+app.get("/users/{id}", [](Request req, Response res) {
+    auto id = req.param("id");
+    return json::o("user_id", id);
+});
 ```
 
 ### Minimal HTTP + WebSocket Server
@@ -203,170 +194,9 @@ client->on_open([] {
 client->send("chat.message", {"text", "Hello world!"});
 ```
 
-## 1. Hello World (JSON)
-
-```cpp
-app.get("/", [](Request req, Response res) {
-    return json::o("message", "Hello from Vix");
-});
-```
-
----
-
-## 2. Route Parameters
-
-```cpp
-app.get("/users/{id}", [](Request req, Response res) {
-    auto id = req.param("id");
-    return json::o("user_id", id);
-});
-```
-
----
-
-## 3. Query Parameters
-
-```cpp
-app.get("/search", [](Request req, Response res) {
-    auto q = req.query_value("q", "none");
-    auto page = req.query_value("page", "1");
-
-    return json::o(
-        "query", q,
-        "page", page
-    );
-});
-```
-
----
-
-## 4. Automatic Status + Payload (FastAPI style)
-
-```cpp
-app.get("/missing", [](Request req, Response res) {
-    return std::pair{
-        404,
-        json::o("error", "Not found")
-    };
-});
-```
-
----
-
-## 5. Redirect
-
-```cpp
-app.get("/go", [](Request req, Response res) {
-    res.redirect("https://vixcpp.com");
-});
-```
-
----
-
-## 6. Automatic Status Message
-
-```cpp
-app.get("/forbidden", [](Request req, Response res) {
-    res.status(403).send();
-});
-```
-
----
-
-## 7. POST JSON Body
-
-```cpp
-app.post("/echo", [](Request req, Response res) {
-    return json::o(
-        "received", req.json()
-    );
-});
-```
-
----
-
-## 8. Typed JSON Parsing
-
-```cpp
-struct UserInput {
-    std::string name;
-    int age;
-};
-
-app.post("/users", [](Request req, Response res) {
-    UserInput input = req.json_as<UserInput>();
-
-    return std::pair{
-        201,
-        json::o(
-            "name", input.name,
-            "age", input.age
-        )
-    };
-});
-```
-
----
-
-## 9. Headers
-
-```cpp
-app.get("/headers", [](Request req, Response res) {
-    res.header("X-App", "Vix")
-       .type("text/plain")
-       .send("Hello headers");
-});
-```
-
----
-
-## 10. Request-Scoped State
-
-```cpp
-app.get("/state", [](Request req, Response res) {
-    req.set_state<int>(42);
-
-    return json::o(
-        "value", req.state<int>()
-    );
-});
-```
-
----
-
-## 11. Void Handler
-
-```cpp
-app.get("/manual", [](Request req, Response res) {
-    res.status(200)
-       .json(json::o("ok", true));
-});
-```
-
----
-
-## 12. Params Map Access
-
-```cpp
-app.get("/items/{id}", [](Request req, Response res) {
-    const auto& params = req.params();
-    return json::o("id", params.at("id"));
-});
-```
-
 ---
 
-## 13. 204 No Content
-
-```cpp
-app.delete("/items/{id}", [](Request req, Response res) {
-    res.status(204).send();
-});
-```
-
----
-
-# 🧱 Why Vix Exists
+# Why Vix Exists
 
 Cloud-first frameworks assume:
 
@@ -392,107 +222,149 @@ C++20 + Asio + zero-overhead abstractions.
 
 ---
 
-# 🧩 Key Features
+## Key Features
 
-- 🌍 Offline-first runtime
-- 🔗 P2P-ready communication model
-- ⚙️ Async HTTP server
-- 🧭 Expressive routing
-- 💾 ORM for MySQL/SQLite
-- 🧠 Middleware system
-- 📡 WebSocket engine
-- 🧰 Modular design
-- 🚀 Developer experience similar to Node/Deno/Bun
-- ⚡ 80k+ requests/sec performance
+- Offline-first runtime architecture
+- Peer-to-peer–ready communication model
+- Asynchronous HTTP server
+- Expressive and composable routing
+- ORM support for MySQL and SQLite
+- Middleware system
+- WebSocket engine
+- Modular architecture
+- Developer experience comparable to Node.js, Deno, and Bun
+- High-performance runtime (80k+ requests/sec)
 
 ---
 
 ## 🚀 Getting Started
 
-To set up Vix.cpp on your system:
+To build **Vix.cpp** from source:
 
 ```bash
 git clone https://github.com/vixcpp/vix.git
 cd vix
 cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
 cmake --build build -j
-./build/hello_routes
 ```
 
+> This builds the Vix runtime and CLI.  
+> Make sure the resulting `vix` binary is available in your `PATH`.
+
 ---
 
 ## 🧰 Example (CLI Project)
 
-Once installed, you can generate a new project using the CLI:
+Create and run a new Vix project using the CLI:
 
 ```bash
 vix new myapp
 cd myapp
+
 vix build
 vix run
+```
 
-vix dev file.cpp
-vix run file.cpp
-vix orm migrate
+Common development commands:
+
+```bash
+vix dev                # watch, rebuild, reload
+vix run                # build (if needed) and run
+vix check              # validate project or compile a single .cpp (no execution)
+vix tests              # run project tests
+vix orm migrate        # run ORM migrations
 ```
 
 ---
 
-# 🎯 Script Mode — Run `.cpp` Files Directly
+## Script Mode — Run `.cpp` Files Directly
 
 Vix can execute a single `.cpp` file **like a script**, without creating a full project.
 
 ```bash
-vix run file.cpp
-vix dev file.cpp
+vix run main.cpp        # run once
+vix dev main.cpp        # run + watch (hot reload)
 ```
 
-### ✔ How it works
+---
 
-- Generates a temporary CMake project under:  
-  `./.vix-scripts/<filename>/`
-- Compiles the `.cpp` file as a standalone executable
-- Runs it immediately
-- Stops cleanly on Ctrl+C (no gmake noise)
+### ▶Run once (`vix run`)
 
-### Example:
+Runs the file once, then exits.
 
 ```bash
-~/myapp/test$ vix run server.cpp
-Script mode: compiling server.cpp
-Using script build directory:
-  • .vix-scripts/server
-
-✔ Build succeeded
-[I] Server running on port 8080
-^C
-ℹ Server interrupted by user (SIGINT)
+~/dev/scripts$ vix run main.cpp
+Hello, world
 ```
 
 ---
 
-## 📚 Documentation
+### Watch mode (`vix dev`)
+
+Runs the file **in watch mode**.  
+Vix recompiles and restarts automatically when the file changes.
+
+```bash
+~/dev/scripts$ vix dev main.cpp
+Starting Vix dev mode.
+➜ Tip: use `Ctrl+C` to stop dev mode; edit your files and Vix will rebuild & restart automatically.
+Watcher Process started (hot reload).
+➜ Watching: /home/softadastra/dev/scripts/main.cpp
+🏃 Script started (pid=125953)
+Hello, world
+```
+
+---
+
+### ✔ How Script Mode Works
+
+When running a `.cpp` file directly, Vix:
+
+- Creates a temporary build directory under:
+  ```
+  ./.vix-scripts/<filename>/
+  ```
+- Generates a minimal CMake project internally
+- Compiles the file as a standalone executable
+- Runs it immediately
+- In `dev` mode:
+  - Watches the source file
+  - Rebuilds and restarts automatically on changes
+- Stops cleanly on `Ctrl+C` (no noisy build output)
+
+---
+
+### Mental model
+
+| Command            | Behavior                           |
+| ------------------ | ---------------------------------- |
+| `vix run main.cpp` | Compile → run once                 |
+| `vix dev main.cpp` | Compile → run → watch & hot-reload |
+
+---
+
+## Documentation
 
-- 🧭 [Introduction](docs/introduction.md)
-- ⚡ [Quick Start](docs/quick-start.md)
-- 🧱 [Architecture & Modules](docs/architecture.md)
-- 💾 [ORM Overview](docs/orm/overview.md)
-- 📈 [Benchmarks](docs/benchmarks.md)
-- 🧰 [Examples](docs/examples/overview.md)
-- 🛠️ [Build & Installation](docs/build.md)
-- ⚙️ [CLI Options](docs/options.md)
+- [Introduction](docs/introduction.md)
+- [Quick Start](docs/quick-start.md)
+- [Architecture & Modules](docs/architecture.md)
+- [ORM Overview](docs/orm/overview.md)
+- [Benchmarks](docs/benchmarks.md)
+- [Examples](docs/examples/overview.md)
+- [Build & Installation](docs/build.md)
+- [CLI Options](docs/options.md)
+- [CLI Reference](docs/vix-cli-help.md)
 
-## 📦 Module Documentation Index
+## Module Documentation Index
 
-- 🧩 **Core Module** — [docs/modules/core.md](docs/modules/core.md)
-- 📡 **WebSocket Module** — [docs/modules/websocket.md](docs/modules/websocket.md)
-- 🗃️ **ORM Module** — [docs/modules/orm.md](docs/modules/orm.md)
-- 🔧 **JSON Module** — [docs/modules/json.md](docs/modules/json.md)
-- 🛠️ **Utils Module** — [docs/modules/utils.md](docs/modules/utils.md)
-- 🧰 **CLI Module** — [docs/modules/cli.md](docs/modules/cli.md)
-- ⚙️ **Rix Library (Essential C++ utilities)** — [docs/modules/rix.md](docs/modules/rix.md)
+- **Core Module** — [docs/modules/core.md](docs/modules/core.md)
+- **WebSocket Module** — [docs/modules/websocket.md](docs/modules/websocket.md)
+- **ORM Module** — [docs/modules/orm.md](docs/modules/orm.md)
+- **JSON Module** — [docs/modules/json.md](docs/modules/json.md)
+- **Utils Module** — [docs/modules/utils.md](docs/modules/utils.md)
+- **CLI Module** — [docs/modules/cli.md](docs/modules/cli.md)
 
-📊 Summary
+## Summary
 
 Vix.cpp sits at the top of modern backend runtimes, matching or exceeding high-performance frameworks like Go Fiber, and outperforming Deno, Node, PHP, Python, and even several C++ frameworks like Crow.
 
@@ -503,7 +375,7 @@ Vix.cpp = the C++ runtime pushing boundaries.
 ## 🤝 Contributing
 
 Contributions are welcome!  
-Please read the contributing guidelines.
+Please read the [contributing guidelines](CONTRIBUTING.md).
 
 ---
 
diff --git a/SECURITY.md b/SECURITY.md
deleted file mode 100644
index 518c049..0000000
--- a/SECURITY.md
+++ /dev/null
@@ -1,102 +0,0 @@
-# 🔐 Vix.cpp Security Policy
-
-Security is a top priority for the Vix.cpp project.  
-We appreciate your help in keeping the framework and its ecosystem safe.
-
----
-
-## 🧭 Supported Versions
-
-We actively maintain and apply security patches to the following versions:
-
-| Version                  | Supported  | Notes                                          |
-| ------------------------ | ---------- | ---------------------------------------------- |
-| `main` (development)     | ✅ Yes     | Actively developed and reviewed                |
-| `v0.x` (stable releases) | ✅ Yes     | Security fixes and maintenance updates         |
-| Pre-release / alpha      | ⚠️ Partial | Use at your own risk, no guarantee of patching |
-
-If you are using an older version, please upgrade to the latest stable release to receive security updates.
-
----
-
-## 🚨 Reporting a Vulnerability
-
-If you discover a security vulnerability in **Vix.cpp** or any of its modules, please report it **privately and responsibly**.
-
-### 🔒 How to report
-
-Send an email to:
-
-📧 **vixcpp.security@gmail.com**
-
-Include the following details:
-
-1. A detailed description of the issue.
-2. Steps to reproduce or proof-of-concept code.
-3. The affected version(s) or commit(s).
-4. Any suggestions or potential fixes (optional).
-
-> ⚠️ **Do not open a public GitHub issue** for security vulnerabilities.
-
-We take every report seriously and will:
-
-- Confirm receipt within **48 hours**.
-- Investigate and reproduce the issue.
-- Provide a fix or mitigation as soon as possible.
-- Acknowledge you in the release notes (if you wish).
-
----
-
-## 🧪 Responsible Disclosure Policy
-
-We kindly ask researchers and users to:
-
-- Report vulnerabilities **confidentially** via email.
-- Avoid publicly disclosing details until a fix is released.
-- Avoid exploiting or abusing vulnerabilities in production systems.
-
-We commit to working **transparently and collaboratively** with the reporter to resolve issues safely and promptly.
-
----
-
-## 🧰 Security Best Practices for Users
-
-When using Vix.cpp in production:
-
-- Always build with the **latest stable release**.
-- Use **compiler hardening flags**:
-  ```bash
-  -fstack-protector-strong -D_FORTIFY_SOURCE=2 -O2
-  ```
-
-. Prefer ASan/UBSan when debugging:
-
-```bash
-cmake -DVIX_ENABLE_SANITIZERS=ON
-```
-
-. Keep dependencies up to date (Boost, nlohmann/json, etc.).
-
-. Use HTTPS and secure headers in your deployments.
-
-# 🧱 Security Features in Vix.cpp
-
-. 🔒 Safe memory handling with RAII and smart pointers.
-
-. 🧠 Type-safe routing and JSON handling.
-
-. ⚙️ Built-in input validation utilities (Vix::utils::Validation).
-
-. 🧩 Modular isolation — each module can be audited independently.
-
-. 🧰 Optional runtime sanitizers (ASan + UBSan).
-
-# 📜 Acknowledgements
-
-We thank all security researchers and contributors who help make Vix.cpp safer for everyone.
-Your responsible disclosure is essential to maintaining a secure ecosystem.
-
-# 💡 Remember:
-
-Security is not a one-time event — it’s an ongoing commitment.
-Together, we keep Vix.cpp fast, modular, and secure.
diff --git a/SECURITY_TESTS.md b/SECURITY_TESTS.md
index dd475fa..63db9f5 100644
--- a/SECURITY_TESTS.md
+++ b/SECURITY_TESTS.md
@@ -1,233 +1,213 @@
-# 🧪 Vix.cpp — Security Testing Guide
+# Vix.cpp — Security Testing Guide
 
-This document describes how to **audit, test, and validate** the security of **Vix.cpp** and its modules.  
+This document describes how to **audit, test, and validate** the security properties of **Vix.cpp**.
 It is primarily intended for **maintainers** and **core contributors**.
 
+The goal is to ensure that every release of Vix.cpp remains **safe, robust, and predictable** under real-world conditions.
+
 ---
 
-## 🧭 Overview
+## Overview
+
+Security in Vix.cpp is based on **defensive engineering practices**, not on custom or opaque security layers.
 
-Vix.cpp includes several layers of protection:
+The project relies on:
 
-| Layer                   | Description                                                             |
-| ----------------------- | ----------------------------------------------------------------------- |
-| 🔒 **Memory safety**    | Use of smart pointers, RAII, and optional sanitizers                    |
-| 🧰 **Input validation** | Validation utilities under `Vix::utils::Validation`                     |
-| 🌐 **HTTP safety**      | Controlled header parsing and path sanitization                         |
-| ⚙️ **Runtime checks**   | Optional AddressSanitizer (ASan) and UndefinedBehaviorSanitizer (UBSan) |
-| 🧠 **Static analysis**  | Support for clang-tidy, cppcheck, and Coverity                          |
+- Modern C++ memory safety patterns (RAII, clear ownership)
+- Compiler-based runtime checks (sanitizers)
+- Static analysis tools
+- Careful validation of external inputs
+- Continuous testing and review
 
-Maintainers are encouraged to periodically **run full sanitizer builds** and **fuzz endpoints** before major releases.
+There is **no custom security framework** inside Vix.cpp.  
+All security testing relies on **standard, well-known tooling**.
 
 ---
 
-## 🧩 1. Sanitizer Testing (ASan + UBSan)
+## 1. Runtime Sanitizer Testing
+
+Sanitizers are the **primary security signal** during development.
+
+### Supported Sanitizers
 
-Sanitizers detect memory leaks, invalid reads/writes, and undefined behavior at runtime.
+- AddressSanitizer (ASan)
+- UndefinedBehaviorSanitizer (UBSan)
+- ThreadSanitizer (TSan, when applicable)
 
-### 🔧 Build with Sanitizers
+### Build with Sanitizers
 
 ```bash
-cmake -S . -B build-sanitize \
+cmake -S . -B build-san \
   -DCMAKE_BUILD_TYPE=Debug \
   -DVIX_ENABLE_SANITIZERS=ON
-cmake --build build-sanitize -j
+cmake --build build-san -j
 ```
 
-# ▶️ Run examples with ASan/UBSan enabled
+Run the CLI or examples:
 
 ```bash
-cd build-sanitize
-ASAN_OPTIONS=detect_leaks=1 ./main
+cd build-san
+./vix --help
 ```
 
-# Typical output (no errors):
+Any sanitizer finding must be treated as a **blocking error**.
 
-```sql
-==12345== All heap blocks were freed -- no leaks are possible
-```
-
-. 💡 Tip: Use -fsanitize=address,undefined in your own modules for deep inspection.
+---
 
-# 🔬 2. Fuzz Testing
+## 2. CLI & Script Mode Validation
 
-Fuzz testing helps uncover unexpected behavior under random or malformed input.
+The Vix CLI is part of the attack surface and must be tested accordingly.
 
-## ⚙️ Install dependencies (Linux/macOS)
+Recommended checks:
 
 ```bash
-sudo apt install clang llvm
+vix check .
+vix check main.cpp
+vix run main.cpp --san
+vix tests
 ```
 
-## 🧠 Run a simple fuzz test
+Verify that:
 
-Create tests/fuzz_http.cpp:
+- Invalid inputs do not crash the CLI
+- Errors are reported clearly
+- Exit codes are consistent
+- No undefined behavior occurs under sanitizers
 
-```cpp
-#include <vix/core.h>
-#include <string>
+---
 
-extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
-    try {
-        std::string input(reinterpret_cast<const char*>(data), size);
-        // Simulate route parsing
-        Vix::Router r;
-        r.add("/users/{id}", [](auto&, auto&, auto&){});
-        r.match(input);
-    } catch (...) {
-        // ignore malformed input
-    }
-    return 0;
-}
-```
+## 3. Static Analysis
 
-Build and run:
+Static analysis complements runtime checks.
+
+### clang-tidy
 
 ```bash
-clang++ -g -fsanitize=fuzzer,address,undefined \
-  -Iinclude -o fuzz_http tests/fuzz_http.cpp
-./fuzz_http
+cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
+clang-tidy -p build $(find . -name '*.cpp')
 ```
 
-. Fuzzer will mutate inputs and test your route-matching logic for memory or logic errors.
+Focus areas:
 
-# 🧱 3. Static Analysis
+- Undefined behavior warnings
+- Lifetime and ownership issues
+- Dangerous casts and conversions
 
-## 🔍 Run clang-tidy
+### cppcheck
 
 ```bash
-cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -B build
-clang-tidy -p build $(find modules -name '*.cpp')
+cppcheck --enable=all --std=c++20 --inconclusive --quiet .
 ```
 
-## 🧮 Run cppcheck
+---
 
-```bash
-cppcheck --enable=all --std=c++20 --inconclusive --quiet modules/
-```
+## 4. Fuzz Testing (Advanced)
 
-## 🧠 Optional (Advanced): Coverity Scan
+Fuzz testing is optional but recommended for **parsers and protocol boundaries**.
 
-If integrated with Coverity:
+Vix.cpp does not provide built-in fuzz targets.
+Contributors may create standalone fuzz harnesses using LLVM libFuzzer.
 
-```bash
-cov-build --dir cov-int cmake --build build
-tar czvf vix-cov.tgz cov-int
-```
+Example structure:
 
-## 🔐 4. Dependency Audit
+```cpp
+extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
+    // Feed arbitrary input into parsing or decoding logic
+    // Ensure no crashes, UB, or infinite loops
+    return 0;
+}
+```
 
-📦 Check system libraries
+Build and run:
 
 ```bash
-ldd build/vix_cli | grep -E 'boost|ssl|crypto'
+clang++ -fsanitize=fuzzer,address,undefined fuzz_target.cpp -o fuzz_target
+./fuzz_target
 ```
 
-## 🧩 Update dependencies
+Any crash or sanitizer report is considered a security defect.
 
-Ensure system dependencies are up to date:
+---
 
-```bash
-sudo apt update && sudo apt upgrade libboost-all-dev nlohmann-json3-dev
-```
+## 5. Unit Tests & Regression Coverage
 
-## ⚙️ Verify header integrity
+All security-related fixes must include **regression tests**.
 
-```bash
-sha256sum modules/json/include/vix/json/json.hpp
-```
-
-# 🧰 5. Security Unit Tests
+Guidelines:
 
-Write test cases for:
-. Request parameter sanitization
+- Tests must fail before the fix
+- Tests must pass after the fix
+- Prefer minimal reproductions
 
-. Validation rules (regex injection, XSS, overflow)
+Run the test suite:
 
-. JSON parser boundaries
+```bash
+ctest --output-on-failure
+```
 
-## Example:
+---
 
-```cpp
-#include <gtest/gtest.h>
-#include <vix/utils/Validation.hpp>
+## 6. Compiler Hardening Flags (Release Builds)
 
-using namespace Vix::utils;
+Release builds should enable standard hardening flags.
 
-TEST(ValidationTest, RejectsInvalidEmail) {
-    Schema sch{{"email", match(R"(^[^@\s]+@[^@\s]+\.[^@\s]+$)")}};
-    auto data = std::unordered_map<std::string, std::string>{{"email", "not-an-email"}};
-    auto res = validate_map(data, sch);
-    EXPECT_TRUE(res.is_err());
-}
+Recommended flags:
 
+```text
+-fstack-protector-strong
+-D_FORTIFY_SOURCE=2
+-fno-omit-frame-pointer
 ```
 
-# Run:
+Example:
 
 ```bash
-ctest --output-on-failure
+cmake -S . -B build-rel \
+  -DCMAKE_BUILD_TYPE=Release \
+  -DCMAKE_CXX_FLAGS="-fstack-protector-strong -D_FORTIFY_SOURCE=2"
 ```
 
-# 🧪 6. Runtime Hardening Flags
-
-Always compile releases with secure flags:
+---
 
-```bash
--ffunction-sections -fdata-sections -fstack-protector-strong -D_FORTIFY_SOURCE=2
-```
+## 7. Valgrind (Optional)
 
-On Linux:
+Valgrind can be used as a secondary memory diagnostic tool:
 
 ```bash
-cmake -DCMAKE_CXX_FLAGS="-O2 -fstack-protector-strong -D_FORTIFY_SOURCE=2" -B build-rel
+valgrind --leak-check=full ./build-rel/vix
 ```
 
-# ⚡ 7. Optional: Valgrind Leak Check
+Expected result:
 
-```bash
-valgrind --leak-check=full --show-leak-kinds=all ./build/main
-```
+- No invalid reads or writes
+- No definitely lost memory
 
-Example clean output:
+---
 
-```yaml
-HEAP SUMMARY:
-  definitely lost: 0 bytes in 0 blocks
-  indirectly lost: 0 bytes in 0 blocks
-```
+## 8. Recommended Testing Frequency
 
-```markdown
-## 📊 8. Recommended Frequency
+| Test Type       | Recommended Frequency     |
+| --------------- | ------------------------- |
+| Unit tests      | Every commit / PR         |
+| Sanitizers      | Before every release      |
+| Static analysis | Regularly or via CI       |
+| Fuzz testing    | Before large refactors    |
+| Valgrind        | Optional, targeted checks |
 
-Fréquences recommandées pour les différents types de tests et audits :
+---
 
-| **Test Type**    | **Recommended Frequency**        |
-| ---------------- | -------------------------------- |
-| Unit tests       | Every commit / PR                |
-| Sanitizers       | Before each release              |
-| Fuzz tests       | Weekly or before large refactors |
-| Static analysis  | Monthly or automated via CI      |
-| Dependency audit | Quarterly                        |
-```
+## Summary
 
-```markdown
-## 🧾 Summary
+Security in Vix.cpp is ensured through:
 
-Résumé des outils recommandés pour assurer la qualité du code :
+- Compiler-based runtime checks
+- Strict testing discipline
+- Standard and transparent tooling
+- Clear failure semantics
 
-| **Tool**    | **Purpose**             | **Command**                         |
-| ----------- | ----------------------- | ----------------------------------- |
-| ASan/UBSan  | Detect memory/UB errors | `-DVIX_ENABLE_SANITIZERS=ON`        |
-| Clang-Tidy  | Static analysis         | `clang-tidy -p build ...`           |
-| Cppcheck    | Light static check      | `cppcheck --enable=all modules/`    |
-| Valgrind    | Leak detection          | `valgrind --leak-check=full ./main` |
-| LLVM Fuzzer | Fuzzing                 | `clang++ -fsanitize=fuzzer,address` |
-```
+Every release must pass **sanitizers, tests, and static analysis** before being considered stable.
 
-🧠 Goal:
-Every release of Vix.cpp must pass sanitizer, fuzzing, and static analysis tests
-to ensure long-term stability and security of the framework.
+---
 
-Maintained by the Vix.cpp Security Team
-📧 mailto:vixcpp.security@gmail.com
+Maintained by the Vix.cpp maintainers  
+Contact: gaspardkirira@outlook.com
diff --git a/docs/vix-cli-help.md b/docs/vix-cli-help.md
new file mode 100644
index 0000000..dee40c0
--- /dev/null
+++ b/docs/vix-cli-help.md
@@ -0,0 +1,125 @@
+# Vix CLI — Help Reference
+
+Modern **C++ backend runtime & CLI** designed for performance, clarity, and developer experience.
+
+---
+
+## 🧭 Overview
+
+```text
+Vix.cpp — Modern C++ backend runtime
+Version: v1.11.0
+```
+
+Vix provides a fast, ergonomic CLI for building, running, testing, and packaging modern C++ applications.
+
+---
+
+## 📦 Usage
+
+```bash
+vix <command> [options] [args...]
+vix help <command>
+```
+
+---
+
+## ⚡ Quick Start
+
+```bash
+vix new api
+cd api && vix dev
+vix pack --version 1.0.0 && vix verify
+```
+
+---
+
+## 🧰 Commands
+
+### Project
+
+```text
+new <name>               Create a new Vix project in ./<name>
+build [name]             Configure + build (root project or app)
+run   [name] [--args]    Build (if needed) then run
+dev   [name]             Dev mode (watch, rebuild, reload)
+check [path]             Validate a project or compile a single .cpp (no execution)
+tests [path]             Run project tests (alias of check --tests)
+```
+
+---
+
+### Packaging & Security
+
+```text
+pack   [options]         Create dist/<name>@<version> (+ optional .vixpkg)
+verify [options]         Verify dist/<name>@<version> or a .vixpkg artifact
+```
+
+---
+
+### Database (ORM)
+
+```text
+orm <subcommand>         Migrations / status / rollback
+```
+
+---
+
+### Info
+
+```text
+help [command]           Show help for CLI or a specific command
+version                  Show version information
+```
+
+---
+
+## 🌍 Global Options
+
+```text
+--verbose                Enable debug logs (equivalent to --log-level debug)
+-q, --quiet              Only show warnings and errors
+--log-level <level>      trace | debug | info | warn | error | critical
+-h, --help               Show CLI help (or: vix help)
+-v, --version            Show version info
+```
+
+---
+
+## 🔐 Environment Variables
+
+```text
+VIX_LOG_LEVEL=level      Default log level (if --log-level not provided)
+VIX_MINISIGN_SECKEY=path Secret key used by `vix pack` to sign payload.digest
+VIX_MINISIGN_PUBKEY=path Public key used by `vix verify` if --pubkey not provided
+```
+
+---
+
+## 🧪 Examples
+
+```bash
+vix pack --name blog --version 1.0.0
+vix pack --verbose
+vix verify --require-signature
+vix help verify
+```
+
+---
+
+## 🔗 Links
+
+- GitHub: https://github.com/vixcpp/vix
+
+---
+
+## ✨ Notes
+
+- `vix tests` is the preferred way to run project tests.
+- `vix run <file.cpp>` supports **script mode** (no project required).
+- Designed for clean output, predictable exit codes, and high performance.
+
+---
+
+© Vix.cpp — Modern C++ Runtime
diff --git a/modules/cli b/modules/cli
index 5828f9e..16858b1 160000
--- a/modules/cli
+++ b/modules/cli
@@ -1 +1 @@
-Subproject commit 5828f9e7f56239e4d3381e8503d625da08d68b15
+Subproject commit 16858b12c29b8a05456aed492df3f94c09d8cd04