Changelog & Release History

Relevant source files

The following files were used as context for generating this wiki page:

• CHANGELOG.md
• SYNC_LOG.md
• copilot-instructions.md
• ROADMAP.md
• infrastructure_planning/RULE_SYNC_PROCEDURE.md
• README.md

Introduction

The Changelog and Release History of NeuralDBG serves as a comprehensive record of all notable changes, architectural shifts, and rule synchronizations within the project. It tracks the evolution of the causal inference engine, ensuring transparency for developers and maintaining strict adherence to project standards such as Semantic Versioning and the "Keep a Changelog" format.

This documentation is critical for maintaining the "Hub & Spokes" architecture, where the core logic (Hub) remains stable while adapters and external dependencies (Spokes) evolve. It also serves as a historical log for the project's rigid progress tracking, which uses pessimistic estimation and milestone-based validation gates.
Sources: CHANGELOG.md:3-7, copilot-instructions.md:35-40

Versioning Strategy

NeuralDBG adheres to SemVer-Author versioning (e.g., v0.1.0-kuro). This convention combines standard Semantic Versioning with an author-specific identifier to maintain traceability across different development branches and contributors.

Versioning Rules

Requirement	Description
Major	Significant architectural changes or breaking core logic updates.
Minor	New features or "Spokes" added without breaking the core Hub.
Patch	Bug fixes, security patches, or documentation updates.
Suffix	Author tag (e.g., -kuro) for branch-specific identification.

Sources: copilot-instructions.md:28-29, CHANGELOG.md:6-7

Release Lifecycle and Milestone Gates

The project progresses through specific validation milestones (25%, 50%, 75%, 90%, 95%). Development must stop at these gates for mandatory product and quality validation.

The diagram shows the progression through progress gates, where development is locked until validation criteria (like the "Mom Test" or security scans) are met.
Sources: copilot-instructions.md:213-221, ROADMAP.md:10-15

Notable Changes and History

Rule Synchronization (2026-03-04)

A significant update occurred regarding the "Physical Laws" of the repository. Rule 39 (CI/CD Debugging First) was implemented and synchronized across all AI instruction files. This ensures that any failing GitHub Actions checks are prioritized over new feature work.

Synchronized Files:

• AGENTS.md
• AI_GUIDELINES.md
• .cursorrules
• copilot-instructions.md
• GAD.md

Sources: SYNC_LOG.md:3-13, CHANGELOG.md:13-14

Initial Feature Additions (Unreleased)

The following infrastructure and core features were recently integrated into the project:

• Automation Tools: Added scripts/publish_session_summary_to_gdocs.py for direct Google Docs synchronization.
• Security Infrastructure: Integrated CodeQL and Codacy static analysis workflows for Python.
• Rule Enforcement: Established the "Explain as if First Time" pedagogical protocol for mathematical and ML concepts.
• CI/CD: Added workflows for publish-summary-to-google-docs.yml and secret-based authentication.

Sources: CHANGELOG.md:10-25

Change Management Process

All changes to the codebase and rules follow a strict "Traceability" protocol. Every session must produce a multi-lingual (English/French) update in SESSION_SUMMARY.md.

Rule Authority Tiers

The ability to modify the project's "laws" is restricted based on branch scope.

Branch Scope	Authority Level	Description
ceo/**	Highest	Can modify Rules (AGENTS.md) and Code.
infra/**	Operational	Can modify infrastructure; Rules via merge only.
feat/**	Functional	New features only; no Rule modification.
main	Stable	Protected branch; no direct pushes.

Sources: infrastructure_planning/RULE_SYNC_PROCEDURE.md:57-65, copilot-instructions.md:310-315

This sequence illustrates the mandatory synchronization flow required by Rule 33 to maintain global rule parity across all branches.
Sources: infrastructure_planning/RULE_SYNC_PROCEDURE.md:19-27

Summary

The NeuralDBG Changelog and Release History provide a structured audit trail of the project's evolution from a research phase toward a stable 1.0 release. By enforcing mandatory sync logs, milestone validation gates, and author-attributed versioning, the project ensures that every change—whether code-based or rule-based—is traceable, secure, and pedagogically sound.