EP-0000: Tur Enhancement Proposals¶
| Field | Value |
|---|---|
| EP | 0000 |
| Title | Tur Enhancement Proposals |
| Author | Eran Rivlis |
| Status | Active |
| Type | Process |
| Created | 2026-02-19 |
| Updated | 2026-08-18 |
Abstract¶
This document describes the process for creating, reviewing, and implementing Tur Enhancement Proposals (EPs). EPs are the primary mechanism for proposing major new features, collecting community input, and documenting design decisions.
Motivation¶
As Tur evolves, major architectural changes, protocol additions, and process adjustments require clear documentation and formal review to prevent architectural drift and preserve design continuity across maintainers and AI agents.
Rationale¶
To maintain the architectural integrity of Tur and adhere to the Council Framework, major changes require careful consideration. EPs provide a structured way to:
- Falsify ideas before implementation (Popper).
- Ensure Clarity in design (Feynman).
- Maintain a history of decisions (Harmony).
Specification¶
1. The EP Workflow¶
- Draft: The author creates a new file in
docs/proposals/using the template. - Review: The proposal is reviewed by the maintainers (The Council).
- Status Change:
- Accepted: The design is approved.
- Rejected: The design is flawed or misaligned.
- Deferred: Good idea, but not now.
- Superseded: Replaced by a newer EP.
- Withdrawn: The author withdrew the proposal.
- Implementation: The code is written.
- Final: The feature is released.
2. EP Types¶
- Standards Track: New features or behavioral changes.
- Process: Meta-EPs (like this one) describing procedures.
- Informational: Design issues or general guidelines.
3. Template¶
---
title: "EP-XXXX: Title"
description: "One-sentence summary of the proposal — used in navigation and search."
icon: lucide/<icon-name>
status: draft
---
# EP-XXXX: Title
| Field | Value |
|:-------------|:---------------------------------|
| **EP** | XXXX |
| **Title** | Title |
| **Author** | Author Name <author@example.com> |
| **Sponsor** | Core Maintainer Name (Optional) |
| **Delegate** | Council Member / Delegate Name |
| **Status** | Draft |
| **Type** | Standards Track |
| **Created** | YYYY-MM-DD |
| **Updated** | YYYY-MM-DD |
## Abstract
Short summary of the proposal.
## Motivation
Why is this change needed? What problem does it solve?
## Rationale
Why this specific design? How does it align with the Council Framework?
## Specification
Technical details of the implementation.
## Backwards Compatibility
Does this break existing code? How will the transition be handled?
## How to Teach This / Documentation Plan
Plan for user and AI agent documentation updates.
## Reference Implementation
Link to code or pseudo-code.
## Rejected Ideas
Explicit list of alternate designs considered and why they were rejected.
## Open Questions
Outstanding items pending feedback.
## Change Log
* **YYYY-MM-DD:** Initial Draft.
Backwards Compatibility¶
This EP establishes the formal proposal process for the Tur project. Existing informal design notes or architectural decisions are retroactively documented or superseded by formal EPs. No breaking software changes are introduced by this process document.
How to Teach This / Documentation Plan¶
The EP process is documented in docs/proposals/EP-0000-process.md and indexed in zensical.toml. AI agents interact
with EPs using the enhancement-proposals skill (.agents/skills/enhancement-proposals/).
Reference Implementation¶
- Process Definition:
docs/proposals/EP-0000-process.md - Agent Skill & Validator:
.agents/skills/enhancement-proposals/
Rejected Ideas¶
- Ad-hoc issue tracking only: Rejected in favor of version-controlled markdown proposals stored directly within
docs/proposals/to maintain an immutable, offline-accessible repository history.
Open Questions¶
None at this time.
Change Log¶
- 2026-02-19: Initial Draft.
- 2026-04-12: Updated workflow and status definitions.
- 2026-08-18: Standardized sections to align with Python PEP guidelines and automated EP validator.