68 lines
3.9 KiB
Markdown
68 lines
3.9 KiB
Markdown
<!--
|
|
SYNC IMPACT REPORT
|
|
Version: 1.7.1 (Simplified Workflow)
|
|
Changes:
|
|
- Simplified Generation Workflow to a single phase: Code Generation from `tasks.md`.
|
|
- Removed multi-phase Architecture/Implementation split to streamline development.
|
|
Templates Status:
|
|
- .specify/templates/plan-template.md: ✅ Aligned (Dynamic check).
|
|
- .specify/templates/spec-template.md: ✅ Aligned.
|
|
- .specify/templates/tasks-template.md: ✅ Aligned.
|
|
-->
|
|
# 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
|