ag/unisono
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Copy Link feature designed

Browse Source
This commit is contained in:
AG
2025-10-13 20:00:59 +03:00
parent 60e9c24440
commit 696c3ed6c7
10 changed files with 333 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
.specify/memory/constitution.md
View File

@@ -1,36 +1,40 @@
# Unisono Constitution
<!--
Sync Impact Report:
- Version change: 0.0.0 → 1.0.0
- List of modified principles: N/A (initial creation)
- Added sections: Core Principles, Governance
- Removed sections: N/A
- Templates requiring updates:
- ✅ .specify/templates/plan-template.md (verified)
- ✅ .specify/templates/spec-template.md (verified)
- ✅ .specify/templates/tasks-template.md (verified)
- Follow-up TODOs: None
-->
# Agree on Desires Constitution
## Core Principles
### I. Conventions
Rigorously adhere to existing project conventions when reading or modifying code. Analyze surrounding code, tests, and configuration first.
### I. Defined Technology Stack
All development MUST adhere to the approved technology stack. This ensures consistency, maintainability, and streamlined operations.
- **Backend**: Node.js
- **Frontend**: React
- **UI Framework**: Material Design 3 (Material-UI / MUI)
- **Containerization**: Docker
### II. Libraries/Frameworks
NEVER assume a library/framework is available or appropriate. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', 'build.gradle', etc., or observe neighboring files) before employing it.
### II. UI/UX Consistency
All user interfaces MUST adhere to Material Design 3 principles and components. This creates a cohesive, predictable, and high-quality user experience. Rationale: Avoids fragmented design and reduces redundant styling efforts.
### III. Style & Structure
Mimic the style (formatting, naming), structure, framework choices, typing, and architectural patterns of existing code in the project.
### III. Container-First Development
All application services and development environments MUST run within Docker containers. This ensures environment parity from local development to production, simplifies setup, and improves deployment reliability.
### IV. Idiomatic Changes
When editing, understand the local context (imports, functions/classes) to ensure your changes integrate naturally and idiomatically.
### IV. Test-Driven Development (TDD)
New features and bug fixes MUST follow a Test-Driven Development approach. Tests should be written first to define the requirements, fail before implementation, and pass upon completion. This ensures code quality, reduces regressions, and clarifies requirements.
### V. Comments
Add code comments sparingly. Focus on *why* something is done, especially for complex logic, rather than *what* is done. Only add high-value comments if necessary for clarity or if requested by the user. Do not edit comments that are separate from the code you are changing. *NEVER* talk to the user or describe your changes through comments.
## Quality Gates
### I. Proactiveness
Fulfill the user's request thoroughly. When adding features or fixing bugs, this includes adding tests to ensure quality. Consider all created files, especially tests, to be permanent artifacts unless the user says otherwise.
### II. Verification (Tests)
If applicable and feasible, verify the changes using the project's testing procedures. Identify the correct test commands and frameworks by examining 'README' files, build/package configuration (e.g., 'package.json'), or existing test execution patterns. NEVER assume standard test commands.
### III. Verification (Standards)
VERY IMPORTANT: After making code changes, execute the project-specific build, linting and type-checking commands (e.g., 'tsc', 'npm run lint', 'ruff check .') that you have identified for this project (or obtained from the user). This ensures code quality and adherence to standards. If unsure about these commands, you can ask the user if they'd like you to run them and if so how to.
### V. API-First Design
The backend and frontend are decoupled and communicate via a well-defined API contract. The API contract SHOULD be defined and reviewed before implementation begins. This allows for parallel development and clear integration points.
## Governance
All PRs/reviews must verify compliance with these principles. Complexity must be justified.
All development activities, code reviews, and architectural decisions must align with this constitution. Proposed deviations require a formal amendment to this document.
**Version**: 1.0 | **Ratified**: 2025-10-13 | **Last Amended**: 2025-10-13
<!-- Example: Version: 2.1.1 | Ratified: 2025-06-13 | Last Amended: 2025-07-16 -->
**Version**: 1.0.0 | **Ratified**: 2025-10-09 | **Last Amended**: 2025-10-09