|
1 | | -# [PROJECT_NAME] Constitution |
2 | | -<!-- Example: Spec Constitution, TaskFlow Constitution, etc. --> |
| 1 | +<!-- |
| 2 | + Sync Impact Report |
| 3 | + - Version: v1.0.0 (Initial establishment of the project constitution) |
| 4 | + - Added Principles: |
| 5 | + - I. Convention and Structure |
| 6 | + - II. Rigorous Testing |
| 7 | + - III. Performance via Zero-Cost Abstractions |
| 8 | + - IV. Uncompromising Safety |
| 9 | + - V. Clear and Private APIs |
| 10 | + - Added Sections: |
| 11 | + - Development Workflow |
| 12 | + - Code Style and Formatting |
| 13 | + - Templates Requiring Updates: |
| 14 | + - ✅ .specify/templates/plan-template.md |
| 15 | + - Follow-up TODOs: |
| 16 | + - TODO(RATIFICATION_DATE): Set initial adoption date. |
| 17 | +--> |
| 18 | + |
| 19 | +# deep_causality Constitution |
3 | 20 |
|
4 | 21 | ## Core Principles |
5 | 22 |
|
6 | | -### [PRINCIPLE_1_NAME] |
7 | | -<!-- Example: I. Library-First --> |
8 | | -[PRINCIPLE_1_DESCRIPTION] |
9 | | -<!-- Example: Every feature starts as a standalone library; Libraries must be self-contained, independently testable, documented; Clear purpose required - no organizational-only libraries --> |
| 23 | +### I. Convention and Structure |
| 24 | +All contributions MUST adhere to the established conventions, style, and structure of the existing codebase. Each crate MUST follow the established `src/{errors, traits, types}` layout. Each file within these modules MUST contain only a single, corresponding definition (one type per file, one trait per file, etc.). |
| 25 | +Rationale: This ensures consistency, maintainability, and predictability across the monorepo, making it easier for contributors to navigate and understand the code. |
10 | 26 |
|
11 | | -### [PRINCIPLE_2_NAME] |
12 | | -<!-- Example: II. CLI Interface --> |
13 | | -[PRINCIPLE_2_DESCRIPTION] |
14 | | -<!-- Example: Every library exposes functionality via CLI; Text in/out protocol: stdin/args → stdout, errors → stderr; Support JSON + human-readable formats --> |
| 27 | +### II. Rigorous Testing |
| 28 | +All new features, bug fixes, or substantial changes MUST be accompanied by corresponding tests. Crate-specific tests MUST be run via `cargo test -p <crate_name>`. Before submitting a contribution with multi-crate impact, the entire project test suite MUST pass via `make test`. |
| 29 | +Rationale: Guarantees code quality, prevents regressions, and ensures that individual components and the system as a whole behave as expected. |
15 | 30 |
|
16 | | -### [PRINCIPLE_3_NAME] |
17 | | -<!-- Example: III. Test-First (NON-NEGOTIABLE) --> |
18 | | -[PRINCIPLE_3_DESCRIPTION] |
19 | | -<!-- Example: TDD mandatory: Tests written → User approved → Tests fail → Then implement; Red-Green-Refactor cycle strictly enforced --> |
| 31 | +### III. Performance via Zero-Cost Abstractions |
| 32 | +Code MUST prefer static dispatch over dynamic dispatch (e.g., `dyn Trait`). All abstractions should strive to be 'zero-cost,' meaning they have no runtime overhead. A functional style (e.g., `map`, `filter`) is preferred for its clarity and potential for optimization. |
| 33 | +Rationale: Aligns with Rust's core philosophy and is critical for a high-performance computational causality library. It ensures that high-level code does not compromise low-level performance. |
20 | 34 |
|
21 | | -### [PRINCIPLE_4_NAME] |
22 | | -<!-- Example: IV. Integration Testing --> |
23 | | -[PRINCIPLE_4_DESCRIPTION] |
24 | | -<!-- Example: Focus areas requiring integration tests: New library contract tests, Contract changes, Inter-service communication, Shared schemas --> |
| 35 | +### IV. Uncompromising Safety |
| 36 | +The use of `unsafe` code is strictly prohibited in all library crates (`/src`). External dependencies should be minimized and vetted for security. All code MUST be checked with `make check` before submission. |
| 37 | +Rationale: Ensures memory safety, robustness, and security, which are non-negotiable for a foundational library intended for production-grade systems. |
25 | 38 |
|
26 | | -### [PRINCIPLE_5_NAME] |
27 | | -<!-- Example: V. Observability, VI. Versioning & Breaking Changes, VII. Simplicity --> |
28 | | -[PRINCIPLE_5_DESCRIPTION] |
29 | | -<!-- Example: Text I/O ensures debuggability; Structured logging required; Or: MAJOR.MINOR.BUILD format; Or: Start simple, YAGNI principles --> |
| 39 | +### V. Clear and Private APIs |
| 40 | +All fields in public-facing types MUST be private. Access MUST be provided through explicit constructors, getters, and setters. Internal modules MUST remain private at the crate root, and all public APIs MUST be explicitly exported from `src/lib.rs`. |
| 41 | +Rationale: Enforces strong encapsulation, creating stable and predictable public APIs while allowing internal implementation details to evolve without breaking downstream users. |
30 | 42 |
|
31 | | -## [SECTION_2_NAME] |
32 | | -<!-- Example: Additional Constraints, Security Requirements, Performance Standards, etc. --> |
| 43 | +## Development Workflow |
33 | 44 |
|
34 | | -[SECTION_2_CONTENT] |
35 | | -<!-- Example: Technology stack requirements, compliance standards, deployment policies, etc. --> |
| 45 | +All development follows a crate-centric model. Changes should be confined to a single crate where possible. Build and test commands (`cargo build -p <name>`, `cargo test -p <name>`) MUST be run on the affected crate. For changes spanning multiple crates, `make format && make fix` MUST be run before submission to ensure repository-wide consistency. |
36 | 46 |
|
37 | | -## [SECTION_3_NAME] |
38 | | -<!-- Example: Development Workflow, Review Process, Quality Gates, etc. --> |
| 47 | +## Code Style and Formatting |
39 | 48 |
|
40 | | -[SECTION_3_CONTENT] |
41 | | -<!-- Example: Code review requirements, testing gates, deployment approval process, etc. --> |
| 49 | +All code MUST be formatted using `cargo fmt` according to the `rustfmt.toml` configuration. Lints are enforced by `clippy`, and all warnings MUST be resolved by running `make fix` or addressing them manually. |
42 | 50 |
|
43 | 51 | ## Governance |
44 | | -<!-- Example: Constitution supersedes all other practices; Amendments require documentation, approval, migration plan --> |
45 | 52 |
|
46 | | -[GOVERNANCE_RULES] |
47 | | -<!-- Example: All PRs/reviews must verify compliance; Complexity must be justified; Use [GUIDANCE_FILE] for runtime development guidance --> |
| 53 | +This Constitution is the single source of truth for development standards and supersedes all other practices. All contributions and reviews MUST verify compliance with these principles. Any deviation requires a formal amendment to this document. The `AGENTS.md` file provides runtime development guidance for AI agents and MUST remain in sync with these principles. |
48 | 54 |
|
49 | | -**Version**: [CONSTITUTION_VERSION] | **Ratified**: [RATIFICATION_DATE] | **Last Amended**: [LAST_AMENDED_DATE] |
50 | | -<!-- Example: Version: 2.1.1 | Ratified: 2025-06-13 | Last Amended: 2025-07-16 --> |
| 55 | +**Version**: v1.0.0 | **Ratified**: TODO(RATIFICATION_DATE): Set initial adoption date. | **Last Amended**: 2025-09-30 |
0 commit comments