docs: initialize constitution v1.0.0

This commit is contained in:
Alex Selimov 2025-10-01 22:47:40 -04:00
commit ef65e38bb2
Signed by: aselimov
GPG key ID: 3DDB9C3E023F1F31
17 changed files with 2226 additions and 0 deletions

View file

@ -0,0 +1,42 @@
<!--
Sync Impact Report:
- Version change: none → 1.0.0
- Added sections:
- Core Principles
- Governance
- Removed sections:
- [SECTION_2_NAME]
- [SECTION_3_NAME]
- Modified principles: none
- Templates requiring updates:
- ✅ .specify/memory/constitution.md
- ⚠ pending: .specify/templates/plan-template.md
- ⚠ pending: .specify/templates/spec-template.md
- ⚠ pending: .specify/templates/tasks-template.md
- ⚠ pending: .gemini/commands/analyze.toml
- ⚠ pending: .gemini/commands/clarify.toml
- ⚠ pending: .gemini/commands/constitution.toml
- ⚠ pending: .gemini/commands/implement.toml
- ⚠ pending: .gemini/commands/plan.toml
- ⚠ pending: .gemini/commands/specify.toml
- ⚠ pending: .gemini/commands/tasks.toml
- Follow-up TODOs: none
-->
# notex.nvim Constitution
## Core Principles
### I. Clean Code
Code should be written in a way that is easy to read, understand, and maintain. Follow established style guides and best practices.
### II. Functional Style
Favor a functional programming style with immutable data structures and pure functions where possible and appropriate for the language.
### III. Descriptive Coding
Write self-documenting code with descriptive function and variable names. Avoid comments that explain *what* the code is doing; the code should speak for itself. Comments should only be used to explain *why* a certain implementation was chosen when it's not obvious.
## Governance
All pull requests and reviews must verify compliance with this constitution. Any deviation from these principles must be explicitly justified and approved.
**Version**: 1.0.0 | **Ratified**: 2025-10-01 | **Last Amended**: 2025-10-01