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

"Afraid to Ask" designed without Analyze

Browse Source
This commit is contained in:
aodulov
2025-10-13 10:44:17 +03:00
parent 093ff5b07d
commit 272c4f6148
13 changed files with 1406 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
.specify/memory/constitution.md
View File

@@ -1,40 +1,50 @@
<!--
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
# [PROJECT_NAME] Constitution
<!-- Example: Spec Constitution, TaskFlow Constitution, etc. -->
## Core Principles
### 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
### [PRINCIPLE_1_NAME]
<!-- Example: I. Library-First -->
[PRINCIPLE_1_DESCRIPTION]
<!-- Example: Every feature starts as a standalone library; Libraries must be self-contained, independently testable, documented; Clear purpose required - no organizational-only libraries -->
### 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.
### [PRINCIPLE_2_NAME]
<!-- Example: II. CLI Interface -->
[PRINCIPLE_2_DESCRIPTION]
<!-- Example: Every library exposes functionality via CLI; Text in/out protocol: stdin/args → stdout, errors → stderr; Support JSON + human-readable formats -->
### 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.
### [PRINCIPLE_3_NAME]
<!-- Example: III. Test-First (NON-NEGOTIABLE) -->
[PRINCIPLE_3_DESCRIPTION]
<!-- Example: TDD mandatory: Tests written → User approved → Tests fail → Then implement; Red-Green-Refactor cycle strictly enforced -->
### 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.
### [PRINCIPLE_4_NAME]
<!-- Example: IV. Integration Testing -->
[PRINCIPLE_4_DESCRIPTION]
<!-- Example: Focus areas requiring integration tests: New library contract tests, Contract changes, Inter-service communication, Shared schemas -->
### 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.
### [PRINCIPLE_5_NAME]
<!-- Example: V. Observability, VI. Versioning & Breaking Changes, VII. Simplicity -->
[PRINCIPLE_5_DESCRIPTION]
<!-- Example: Text I/O ensures debuggability; Structured logging required; Or: MAJOR.MINOR.BUILD format; Or: Start simple, YAGNI principles -->
## [SECTION_2_NAME]
<!-- Example: Additional Constraints, Security Requirements, Performance Standards, etc. -->
[SECTION_2_CONTENT]
<!-- Example: Technology stack requirements, compliance standards, deployment policies, etc. -->
## [SECTION_3_NAME]
<!-- Example: Development Workflow, Review Process, Quality Gates, etc. -->
[SECTION_3_CONTENT]
<!-- Example: Code review requirements, testing gates, deployment approval process, etc. -->
## Governance
<!-- Example: Constitution supersedes all other practices; Amendments require documentation, approval, migration plan -->
All development activities, code reviews, and architectural decisions must align with this constitution. Proposed deviations require a formal amendment to this document.
[GOVERNANCE_RULES]
<!-- Example: All PRs/reviews must verify compliance; Complexity must be justified; Use [GUIDANCE_FILE] for runtime development guidance -->
**Version**: 1.0.0 | **Ratified**: 2025-10-09 | **Last Amended**: 2025-10-09
**Version**: [CONSTITUTION_VERSION] | **Ratified**: [RATIFICATION_DATE] | **Last Amended**: [LAST_AMENDED_DATE]
<!-- Example: Version: 2.1.1 | Ratified: 2025-06-13 | Last Amended: 2025-07-16 -->