Initial commit from Spec Kit CN template
This commit is contained in:
@@ -0,0 +1,50 @@
|
||||
# [PROJECT_NAME] 项目章程
|
||||
<!-- 示例: Spec 章程, TaskFlow 章程等 -->
|
||||
|
||||
## 核心原则
|
||||
|
||||
### [PRINCIPLE_1_NAME]
|
||||
<!-- 示例: I. 库优先 -->
|
||||
[PRINCIPLE_1_DESCRIPTION]
|
||||
<!-- 示例: 每个功能都从独立的库开始; 库必须是自包含的、可独立测试的、有文档的; 需要明确的目的 - 不允许仅用于组织的库 -->
|
||||
|
||||
### [PRINCIPLE_2_NAME]
|
||||
<!-- 示例: II. CLI 接口 -->
|
||||
[PRINCIPLE_2_DESCRIPTION]
|
||||
<!-- 示例: 每个库都通过 CLI 暴露功能; 文本输入/输出协议: stdin/args → stdout, 错误 → stderr; 支持 JSON + 人类可读格式 -->
|
||||
|
||||
### [PRINCIPLE_3_NAME]
|
||||
<!-- 示例: III. 测试优先(不可协商) -->
|
||||
[PRINCIPLE_3_DESCRIPTION]
|
||||
<!-- 示例: TDD 强制要求: 编写测试 → 用户批准 → 测试失败 → 然后实现; 严格执行红-绿-重构循环 -->
|
||||
|
||||
### [PRINCIPLE_4_NAME]
|
||||
<!-- 示例: IV. 集成测试 -->
|
||||
[PRINCIPLE_4_DESCRIPTION]
|
||||
<!-- 示例: 需要集成测试的重点领域: 新库契约测试、契约变更、服务间通信、共享模式 -->
|
||||
|
||||
### [PRINCIPLE_5_NAME]
|
||||
<!-- 示例: V. 可观测性, VI. 版本控制和破坏性变更, VII. 简单性 -->
|
||||
[PRINCIPLE_5_DESCRIPTION]
|
||||
<!-- 示例: 文本 I/O 确保可调试性; 需要结构化日志; 或者: MAJOR.MINOR.BUILD 格式; 或者: 从简单开始, YAGNI 原则 -->
|
||||
|
||||
## [SECTION_2_NAME]
|
||||
<!-- 示例: 附加约束、安全要求、性能标准等 -->
|
||||
|
||||
[SECTION_2_CONTENT]
|
||||
<!-- 示例: 技术栈要求、合规标准、部署策略等 -->
|
||||
|
||||
## [SECTION_3_NAME]
|
||||
<!-- 示例: 开发工作流程、审查流程、质量门禁等 -->
|
||||
|
||||
[SECTION_3_CONTENT]
|
||||
<!-- 示例: 代码审查要求、测试门禁、部署审批流程等 -->
|
||||
|
||||
## 治理
|
||||
<!-- 示例: 章程优先于所有其他实践; 修正需要文档化、批准、迁移计划 -->
|
||||
|
||||
[GOVERNANCE_RULES]
|
||||
<!-- 示例: 所有 PR/审查必须验证合规性; 复杂性必须得到证明; 使用 [GUIDANCE_FILE] 进行运行时开发指导 -->
|
||||
|
||||
**版本**: [CONSTITUTION_VERSION] | **批准日期**: [RATIFICATION_DATE] | **最后修正**: [LAST_AMENDED_DATE]
|
||||
<!-- 示例: 版本: 2.1.1 | 批准日期: 2025-06-13 | 最后修正: 2025-07-16 -->
|
||||
Reference in New Issue
Block a user