# Semantic Code Generation Constitution ## Core Principles ### I. Semantic Protocol Compliance The file `semantic_protocol.md` is the **authoritative technical standard** for this project. All code generation, refactoring, and architecture must strictly adhere to the standards, syntax, and workflows defined therein. - **Syntax**: `[DEF]` anchors, `@RELATION` tags, and metadata must match the Protocol specification. - **Structure**: File layouts and headers must follow the "File Structure Standard". - **Workflow**: The technical steps for generating code must align with the Protocol. ### II. Causal Validity (Contracts First) As defined in the Protocol, Semantic definitions (Contracts) must ALWAYS precede implementation code. Logic is downstream of definition. We define the structure and constraints (`[DEF]`, `@PRE`, `@POST`) before writing the executable logic. ### III. Immutability of Architecture Architectural decisions in the Module Header (`@LAYER`, `@INVARIANT`, `@CONSTRAINT`) are treated as immutable constraints. Changes to these require an explicit refactoring step, not ad-hoc modification during implementation. ### IV. Design by Contract (DbC) Contracts are the Source of Truth. Functions and Classes must define their purpose, specifications, and constraints in the metadata block before implementation, strictly following the **Contracts (Section IV)** standard in `semantic_protocol.md`. ### V. Belief State Logging Agents must maintain belief state logs for debugging and coherence checks, strictly following the **Logging Standard (Section V)** defined in `semantic_protocol.md`. ### VI. Fractal Complexity Limit To maintain semantic coherence, code must adhere to the complexity limits (Module/Function size) defined in the **Fractal Complexity Limit (Section VI)** of `semantic_protocol.md`. ### VII. Everything is a Plugin All functional extensions, tools, or major features must be implemented as modular Plugins inheriting from `PluginBase`. Logic should not reside in standalone services or scripts unless strictly necessary for core infrastructure. This ensures a unified execution model via the `TaskManager`, consistent logging, and modularity. ## File Structure Standards Refer to **Section III (File Structure Standard)** in `semantic_protocol.md` for the authoritative definitions of: - Python Module Headers (`.py`) - Svelte Component Headers (`.svelte`) ## Generation Workflow The development process follows a streamlined single-phase workflow: ### 1. Code Generation Phase (Mode: `code`) **Input**: `tasks.md` **Responsibility**: - Select task from `tasks.md`. - Generate Scaffolding (`[DEF]` anchors, Headers, Contracts) AND Implementation in one pass. - Ensure strict adherence to Protocol Section IV (Contracts) and Section VII (Generation Workflow). - **Output**: Working code with passing tests. ### 2. Validation If logic conflicts with Contract -> Stop -> Report Error. ## Governance This Constitution establishes the "Semantic Code Generation Protocol" as the supreme law of this repository. - **Authoritative Source**: `semantic_protocol.md` defines the specific implementation rules for these Principles. - **Automated Enforcement**: Tools must validate adherence to the `semantic_protocol.md` syntax. - **Amendments**: Changes to core principles require a Constitution amendment. Changes to technical syntax require a Protocol update. - **Compliance**: Failure to adhere to the Protocol constitutes a build failure. **Version**: 1.7.1 | **Ratified**: 2025-12-19 | **Last Amended**: 2026-01-13