diff --git a/docs/analysis.md b/docs/analysis.md
new file mode 100644
index 00000000..d08580a3
--- /dev/null
+++ b/docs/analysis.md
@@ -0,0 +1,127 @@
+## 2025-12-21 — Analysis Entry
+
+### Summary
+Rhiza is a production-grade Python project template repository providing reusable CI/CD, testing, and documentation configurations. The repository demonstrates strong automation with 10 GitHub workflows, comprehensive Makefile (19 documented targets), and modern tooling (uv, ruff, marimo). Architecture is intentionally minimal on the Python side (~620 LOC in `src/rhiza/__init__.py`), focusing instead on battle-tested configuration templates and shell-based automation scripts (~784 LOC across `.github/scripts/`). The self-referential design (using Rhiza to manage itself via `.github/template.yml`) validates template quality. Active Renovate automation maintains dependencies via recent PRs. Critical gaps remain in security scanning and test coverage enforcement.
+
+### Strengths
+- **Comprehensive CI/CD Pipeline**: 10 distinct GitHub workflows covering testing (dynamic Python version matrix via `.github/workflows/scripts/version_matrix.py` evaluating candidates 3.11-3.14 against `pyproject.toml` requires-python), pre-commit hooks, dependency analysis (deptry), documentation generation, marimo notebooks, Docker/devcontainer validation, release automation with OIDC-based PyPI publishing, and template synchronization
+- **Makefile Excellence**: 19 well-organized documented targets in `Makefile` with color-coded output, self-documenting help system, and intelligent dependency chaining; automatically syncs help text to README.md via pre-commit hook (`.github/scripts/update-readme-help.sh`)
+- **Modern Python Tooling**: Uses uv for fast package management, ruff for linting/formatting (`ruff.toml` configured with Google-style docstrings, 120 char line length, and comprehensive rule set: D, E, F, I, N, W, UP), Hatch for building, and marimo for interactive notebooks
+- **Robust Shell Scripting**: All scripts in `.github/scripts/` use error handling (`set -e` or `set -eu`), color-coded output, interactive prompts with safeguards, and are thoroughly tested (see `tests/test_rhiza/test_bump_script.py`, `test_release_script.py`, `test_marimushka_script.py`)
+- **Quality Pre-commit Hooks**: 9 hooks in `.pre-commit-config.yaml` including ruff, markdownlint, check-jsonschema for GitHub workflows and Renovate config, actionlint, and validate-pyproject
+- **Self-Referential Architecture**: Repository uses itself for infrastructure management via `.github/template.yml`, demonstrating confidence and providing living documentation
+- **Excellent Documentation**: 682-line README.md with clear value proposition, multiple integration paths (automated via `uvx rhiza .` or manual cherry-picking), troubleshooting section, and auto-synchronized Makefile help output
+- **Dev Container Support**: Complete `.devcontainer/devcontainer.json` with Python 3.14, uv pre-installed, SSH agent forwarding for Git operations, Marimo VS Code extension, and port 8080 forwarding
+- **Test Coverage**: 1,291 LOC of tests across 10 test files in `tests/test_rhiza/` including tests for scripts, Makefile targets, README code blocks (executable documentation), and structural validation
+- **Secure Release Process**: `.github/workflows/release.yml` implements OIDC-based PyPI publishing (no stored credentials), draft releases with artifacts, conditional devcontainer image publishing, and multi-phase validation
+- **Active Dependency Management**: Renovate automation (`.github/renovate.json`) is properly configured and actively maintaining dependencies with recent PRs (#67, #66, #65, #64, #63) across pep621, pre-commit, and github-actions managers; weekly schedule ensures timely updates
+
+### Weaknesses
+- **No Security Scanning**: Missing CodeQL, Snyk, or similar security analysis workflows; no dependency vulnerability scanning beyond basic deptry checks; no SAST/DAST tooling
+- **Minimal Python Code**: Only ~620 LOC in `src/rhiza/__init__.py`, primarily docstrings and version detection fallback logic using `tomllib`; limited surface area to demonstrate Python best practices
+- **Test Coverage Not Enforced**: While `pytest-cov` is in dev dependencies (`pyproject.toml` line 33), no coverage thresholds, badges, or CI enforcement; potential for test coverage regression
+- **No CHANGELOG**: No automated changelog generation despite semantic versioning (`v0.3.0` in `pyproject.toml` line 3); users cannot track changes between releases
+- **Limited Template Variants**: One-size-fits-all approach with no profiles for minimal/standard/full configurations; `.github/template.yml` uses blanket `include: - .github` pattern (lines 2-3)
+- **Incomplete Documentation**: Missing Architecture Decision Records (ADRs) explaining design choices (e.g., why uv over pip, why shell scripts over Python); no diagrams of sync workflow or release pipeline
+- **Windows Support Unclear**: Shell scripts use `#!/bin/sh` but unclear if they work on Windows without WSL; no Windows-specific CI testing or documentation
+
+### Risks / Technical Debt
+- **Security Vulnerability Exposure**: Without automated security scanning, vulnerabilities in dependencies (currently: marimo 0.18.4, pytest 9.0.2, pre-commit 4.5.1) could go undetected; particularly risky for a template repository that others will depend on
+- **Test Coverage Regression**: No coverage enforcement means tests could be removed or code added without tests; in `tests/test_rhiza/test_structure.py`, tests only warn (lines 40, 54) rather than fail on missing expected files/directories
+- **Breaking Template Changes**: No versioning strategy for templates themselves; `.github/workflows/sync.yml` pulls from `main` branch without guarantees; could break consuming repositories during automated sync
+- **Makefile Lacks Advanced Error Recovery**: While `Makefile` has basic error handling (e.g., install-uv exits on curl failure at lines 49-52), subsequent targets don't validate prerequisites; if install-uv was skipped but uv isn't actually installed, dependent targets like install (line 66) will fail with cryptic errors rather than clear guidance
+- **Limited Git History**: Only 625 commits total, but current branch shows shallow history; unclear if full history is accessible for forensic analysis
+- **Hardcoded Assumptions**: Scripts assume POSIX environment (e.g., `.github/scripts/release.sh` uses `sed`, `awk`, `grep`); will fail on non-Unix systems
+- **No Rollback Mechanism**: Template sync via `.github/workflows/sync.yml` has no easy rollback if sync introduces breaking changes; consuming repos must manually revert
+- **Insufficient Error Messages**: Some scripts (e.g., `.github/scripts/bump.sh`) have cryptic error messages that don't guide users to resolution
+- **API Documentation Minimal**: While `make docs` generates pdoc documentation, there's little Python API to document; could mislead users about project scope
+
+### Score
+**8/10** — Strong repository with minor gaps. The repository excels at CI/CD automation (10 workflows), developer experience tooling, active dependency management (Renovate working well with recent PRs), and self-referential architecture demonstration. Shell script quality, Makefile organization (19 targets), comprehensive pre-commit hooks, and automated release process are exemplary. The discovery of active Renovate automation addresses a previously assumed weakness. However, critical security scanning absence, missing test coverage enforcement, and unclear Windows support prevent a higher rating. The minimal Python codebase (intentional for a template repo) limits assessment of Python-specific best practices. Production-ready for Unix-based development teams, and closer to exemplary (9-10) than initially assessed. Primary gap remains security tooling (CodeQL/Snyk). Suitable for teams seeking battle-tested Python project templates with modern automation.
+
+**Note**: This score (8/10) differs from the existing `REPOSITORY_ANALYSIS.md` (9.0/10) primarily due to emphasis on security tooling presence. The original analysis score of 7/10 in this entry was revised upward after discovering active Renovate automation. Both assessments identify similar strengths but weigh security gaps differently. This analysis weights security tooling more heavily while acknowledging the repository's strong automation foundation.
+
+---
+
+## 2025-12-22 — Analysis Entry
+
+### Summary
+Rhiza has undergone significant evolution since the previous analysis. The repository now addresses the most critical gap identified earlier: **security scanning via CodeQL** (`.github/workflows/security.yml`). The Makefile architecture has been modernized through modularization, splitting into 4 component files (main + book/tests/presentation) with 22 documented targets. Workflow count increased to 11 (security.yml added). A comprehensive `SECURITY.md` policy establishes vulnerability reporting procedures. Test suite expanded to 1,392 LOC across 12 test files. The repository demonstrates continuous improvement and responsiveness to technical debt. Architecture now scales better with modular Makefiles enabling domain-specific customization while maintaining central coordination.
+
+### Strengths
+- **Security Scanning Implemented**: CodeQL workflow (`.github/workflows/security.yml`) now provides automated Python security analysis on push/PR to main/master branches; addresses the most critical gap from previous analysis; includes proper permissions (security-events: write) and language specification
+- **Modular Makefile Architecture**: Split from monolithic 19-target Makefile into 4 component files (`Makefile`, `book/Makefile.book`, `tests/Makefile.tests`, `presentation/Makefile.presentation`) with 22 total documented targets; uses `-include` for graceful degradation; variables properly scoped (book-specific like BOOK_TITLE in book/Makefile.book, test-specific like TESTS_FOLDER in tests/Makefile.tests)
+- **Comprehensive Security Policy**: New `SECURITY.md` (100 lines) establishes clear vulnerability reporting process, supported versions table, 48-hour acknowledgment commitment, 7-day critical vulnerability resolution timeline, and documents existing security measures (CodeQL, Renovate, pre-commit hooks)
+- **Expanded Test Coverage**: Test suite grown to 1,392 LOC across 12 test files (up from 1,291 LOC/10 files); includes new benchmark target (`make benchmark`) using pytest-benchmark for performance regression detection; tests now cover modular Makefile structure
+- **Enhanced CI/CD Pipeline**: 11 distinct workflows (up from 10) with security.yml providing SAST; workflows maintain proper permissions models (e.g., security workflow runs only on public repos via `if: github.repository_visibility != 'private'`)
+- **Presentation Infrastructure**: New `presentation/` directory with dedicated Makefile.presentation enables talk/slide generation; demonstrates repository's expanding scope beyond templates into educational content
+- **Refined Sync Workflow**: Refactored to remove unnecessary validation steps and explicit git push commands; cleaner design relying on Create Pull Request action's branch management; renamed to "RHIZA VALIDATE" for clarity
+- **Continuous Active Maintenance**: Recent commits show ongoing development (Makefile split #107, security workflow #112, sync refactor #113, benchmark target #114); demonstrates living, evolving codebase rather than stagnant template collection
+- **All Previous Strengths Maintained**: Dynamic Python version matrix, modern tooling (uv, ruff, marimo), robust shell scripting, 9 pre-commit hooks, self-referential architecture, dev container support, OIDC release process, and active Renovate automation all remain operational
+
+### Weaknesses
+- **Test Coverage Still Not Enforced**: Despite expanded test suite (1,392 LOC), no coverage thresholds in CI; `pytest-cov` configured in test target but no `--cov-fail-under` flag; coverage reports generated to `_tests/html-coverage` but not validated or published
+- **No CHANGELOG Still Missing**: Despite semantic versioning (v0.3.0) and clear release process, no automated changelog generation; security.md mentions "CHANGELOG (if applicable)" suggesting it's optional rather than standard
+- **Limited Template Variants**: Architecture remains one-size-fits-all; no profiles for minimal/standard/full project configurations despite modular Makefile demonstrating capability to support variants
+- **Incomplete Documentation**: Still missing Architecture Decision Records (ADRs) to explain key decisions (e.g., why split Makefile now? why CodeQL vs Snyk? why modular approach over monolithic?); no diagrams of workflows
+- **Windows Support Unclear**: Shell scripts still use `#!/bin/sh`; no Windows-specific CI testing despite cross-platform aspirations; devcontainer helps but doesn't cover native Windows development
+- **Minimal Python Code**: Still only ~619 LOC in `src/rhiza/__init__.py` (unchanged from previous analysis); limited demonstration of Python best practices for a Python template repository
+- **Security Workflow Limited Scope**: CodeQL only runs on public repos (`if: github.repository_visibility != 'private'`); no Snyk or Dependabot security advisories integration; no container scanning for devcontainer images
+
+### Risks / Technical Debt
+- **Test Coverage Regression Risk Remains**: Expanded test suite without enforcement means coverage could silently decrease; manual review of coverage reports required; no badge or metric tracking over time
+- **Breaking Template Changes**: Still no versioning strategy for templates; sync workflow pulls from `main` without semantic guarantees; modular Makefiles add more files that could break during sync
+- **Makefile Complexity Increased**: 4-file Makefile structure more maintainable but harder for newcomers to understand; `-include` silently skips missing files which could mask configuration issues; phony targets must be declared in both main and component files
+- **Security Workflow Blind Spot**: Private repositories skip CodeQL scanning; template repositories often forked to private repos for customization, creating security gap for those users
+- **Documentation Drift**: SECURITY.md documents CodeQL as existing measure, but previous analysis showed it missing; suggests documentation added after-the-fact rather than during implementation; risk of docs/reality divergence
+- **Benchmark Target Immature**: New benchmark infrastructure (`tests/benchmarks/`) not yet integrated into CI; no baseline metrics established; analyze_benchmarks.py script existence uncertain (referenced but not verified); could mislead users about performance testing maturity
+- **Presentation Directory Unclear Purpose**: New presentation/ infrastructure lacks README explaining purpose, usage, or relationship to core templates; increases repository scope without clear documentation
+- **Modular Makefile Migration Path**: Users with existing `.github/template.yml` syncing full Makefile will get conflicts when upstream splits into modules; no migration guide or backward compatibility strategy documented
+
+### Score
+**8.5/10** — Excellent repository with continued improvement trajectory. The addition of CodeQL security scanning directly addresses the most critical gap from the previous analysis, demonstrating responsiveness to technical debt. Makefile modularization shows architectural maturity and planning for scale. Test suite expansion (+101 LOC, +2 files) and security policy formalization indicate professional engineering practices. The 0.5 point improvement reflects: (1) security scanning implementation closing the primary gap, (2) modular architecture enabling better maintainability, (3) clear security policy establishing processes, and (4) continued active development. Remaining gaps (test coverage enforcement, CHANGELOG, ADRs) are process issues rather than technical deficiencies. The repository now sits firmly between "strong with minor gaps" (8/10) and "exemplary, production-grade" (9/10). Primary remaining concern is test coverage enforcement; adding `--cov-fail-under=80` to CI would likely push this to 9/10. Highly suitable for teams seeking battle-tested Python templates with active security posture and professional maintenance.
+
+**Note**: Score improved from 8/10 (previous entry) to 8.5/10 due to security scanning implementation, modular architecture adoption, and formalized security policy. The repository demonstrates responsiveness to identified technical debt and continues active evolution.
+
+---
+
+## 2026-01-01 — Analysis Entry
+
+### Summary
+Rhiza has undergone transformative evolution, now fully embracing its identity as a **pure template/configuration repository**. The `src` folder has been removed (commit c24f0ee #196), eliminating inappropriate Python library artifacts and clarifying focus on reusable CI/CD templates and build configurations. Major additions include comprehensive GitLab CI support (.gitlab/ directory with workflows, testing documentation, and comparison guides), workflow standardization with rhiza_ prefix naming, and version advancement to 0.4.1. The repository now supports dual CI platforms (GitHub Actions + GitLab CI) while maintaining modular Makefile architecture (4 components, 24 documented targets). Test suite expanded to 1,602 LOC validating template quality. CodeQL security scanning remains operational. The repository has matured into a focused, professional-grade template collection with clear architectural boundaries.
+
+### Strengths
+- **Pure Template Repository**: Removed `src` folder entirely (commit c24f0ee), clarifying this is NOT a Python library but a collection of reusable configurations; eliminates confusion about code coverage metrics; demonstrates architectural clarity and self-awareness of repository purpose
+- **Dual CI Platform Support**: Comprehensive GitLab CI integration (.gitlab/ directory) with 4 workflow templates, COMPARISON.md documenting GitHub vs GitLab differences, TESTING.md explaining testing strategies, and template/ directory with reusable job definitions; enables users to choose GitHub Actions or GitLab CI
+- **Standardized Workflow Naming**: All workflows renamed with rhiza_ prefix (rhiza_ci.yml, rhiza_codeql.yml, etc.) providing clear namespace separation; prevents naming conflicts when synced to consuming repositories; demonstrates consideration for downstream users
+- **Expanded Makefile Targets**: 24 documented targets across 4 component files (up from 22); modular architecture proven scalable; new targets support GitLab workflows and presentation generation
+- **Enhanced Test Suite**: 1,602 LOC across test files (up from 1,392); tests validate template correctness, script behavior, and Makefile functionality; includes benchmark infrastructure for performance regression detection
+- **CodeQL Security Scanning**: rhiza_codeql.yml provides advanced security analysis for both Python and GitHub Actions; scans on push/PR and weekly schedule; proper permissions model (security-events: write); analyzes configuration code itself
+- **GitLab CI Documentation Excellence**: .gitlab/COMPARISON.md (7KB) provides detailed feature parity analysis; .gitlab/TESTING.md (8KB) explains testing approaches across platforms; .gitlab/SUMMARY.md (8KB) provides quick reference; demonstrates commitment to multi-platform support
+- **Version Progression**: Advanced to 0.4.1 showing active release cycle; semantic versioning maintained; dependencies updated (marimo>=0.18.0, numpy>=2.4.0, plotly>=6.5.0, pandas>=2.3.3) indicating modern toolchain
+- **Mature Presentation Infrastructure**: presentation/ directory with dedicated Makefile.presentation and PRESENTATION.md (11KB) enables educational content generation; demonstrates repository's value beyond raw templates
+- **All Core Strengths Maintained**: Modular Makefiles, active Renovate automation, pre-commit hooks, dev container support, OIDC release process, and comprehensive documentation all operational
+
+### Weaknesses
+- **No CHANGELOG**: Despite active development (0.3.0 → 0.4.1) and multiple PRs (#196, #197, #200), no automated changelog generation; users must manually parse git history or PR descriptions to understand changes between versions
+- **Limited Template Variants**: Architecture remains one-size-fits-all; no profiles for minimal/standard/full project types; modular Makefile structure could support variants but doesn't offer them; all-or-nothing sync approach
+- **Incomplete Documentation**: Missing Architecture Decision Records (ADRs) explaining key decisions (why remove src folder? why add GitLab CI? why namespace workflows?); these decisions should be documented for historical context and to guide future contributors
+- **Windows Support Unclear**: Shell scripts still use `#!/bin/sh`; no Windows-specific CI testing on either GitHub Actions or GitLab CI; dev container helps but doesn't address native Windows development; limits cross-platform claim
+- **GitLab CI Adoption Path Unclear**: .gitlab/ directory well-documented but no guide for migrating existing GitHub Actions workflows to GitLab equivalents; COMPARISON.md explains differences but not migration strategy
+- **CodeQL Limited Scope**: Scanning skips private repositories (`if: ${{ !github.event.repository.private }}`); template repositories often forked privately for customization; creates security blind spot for significant user segment
+- **Presentation Purpose Ambiguous**: PRESENTATION.md exists (11KB) but relationship to core template functionality unclear; appears to be repository introduction/pitch rather than template component; scope creep concern
+
+### Risks / Technical Debt
+- **Breaking Changes Without CHANGELOG**: Removal of src folder (c24f0ee) is breaking change for users who synced it; no clear communication mechanism for such changes; users discover breaks during sync rather than proactively
+- **Dual CI Maintenance Burden**: Supporting both GitHub Actions and GitLab CI doubles workflow maintenance; changes must be tested on both platforms; .gitlab/COMPARISON.md documents 29 differences creating sync complexity
+- **Workflow Namespace Pollution**: rhiza_ prefix protects from conflicts but makes workflows less portable; users copying individual workflows must rename them; creates friction for selective adoption
+- **GitLab CI Documentation Drift**: .gitlab/ directory has 4 markdown files totaling ~30KB; maintaining parity with actual workflow behavior requires discipline; already shows signs of being documentation-first rather than test-first
+- **Template Versioning Strategy Absent**: Version 0.4.1 applies to repository but templates themselves unversioned; sync pulls from main without semantic guarantees; breaking template changes could occur between patch versions
+- **Makefile Complexity Scaling**: 24 targets across 4 files harder to discover than monolithic structure; new users must know to check book/, tests/, presentation/ for relevant targets; help system doesn't show cross-file targets
+- **Presentation Directory Scope Creep**: Adding educational content (PRESENTATION.md, presentation/ infrastructure) diverges from "reusable templates" mission; risk of repository becoming multipurpose rather than focused
+- **Test Coverage Metric Removed**: Commit 34dd25e removed coverage badge; while appropriate for template repo, no alternative quality metrics introduced; users can't quickly assess template test robustness
+
+### Score
+**9/10** — Exemplary template repository with clear architectural vision. The removal of the `src` folder represents mature self-awareness: this is a template collection, not a library, and should not pretend otherwise. GitLab CI support demonstrates commitment to user choice and platform independence. Standardized workflow naming (rhiza_ prefix) shows consideration for downstream consumption patterns. The 0.5 point improvement from 8.5/10 reflects: (1) architectural clarity through src removal, (2) dual CI platform support significantly expanding utility, (3) workflow namespace protection, (4) continued test suite expansion, and (5) version progression showing active maintenance. The repository now sits at the threshold of "exemplary, production-grade" (9-10 range). Only one point deducted for missing CHANGELOG and ADRs—these are process gaps rather than technical deficiencies. Primary recommendation: implement automated changelog generation tied to release process. Adding ADRs for major decisions (src removal, GitLab CI addition) would push this to 9.5/10. Perfect for teams seeking battle-tested, platform-agnostic Python project templates.
+
+**Note**: Score improved from 8.5/10 (previous entry) to 9/10 due to architectural clarity (src folder removal), dual CI platform support (GitLab CI addition), and workflow standardization (rhiza_ prefix). The repository demonstrates mature understanding of its purpose as a template collection rather than a traditional software project.