74 lines
3.5 KiB
Markdown
74 lines
3.5 KiB
Markdown
# 项目协作原则
|
|
|
|
## 核心原则
|
|
|
|
- 保持简单：优先选择最小、清晰、可维护的方案。
|
|
- 先读后改：以实际代码、配置和文档为依据，不凭经验猜测。
|
|
- 聚焦目标：不做无关重构，不扩大任务范围。
|
|
- 保持兼容：未经确认，不改变公开接口、数据结构、认证方式或既有行为。
|
|
- 如实验证：没有实际执行的检查，不得声称通过。
|
|
- 默认使用中文编写说明和项目文档；代码标识符遵循技术规范。
|
|
|
|
## 项目现状
|
|
|
|
- 本项目是风险防控管理系统，目前处于需求与方案整理阶段。
|
|
- `deprecated/docs/前期讨论/` 仅作为参考输入，不代表最终需求。
|
|
- 技术栈尚未确定，不得臆造目录、依赖、构建或测试命令。
|
|
|
|
## 智能体分工
|
|
|
|
- 主智能体：理解需求、制定方案、拆分任务、集成结果和最终审查。
|
|
- `spark`：代码搜索、结构定位、简单验证和微小修改。
|
|
- `luna`：执行目标、范围和验收标准均已明确的局部实现与测试。
|
|
- `terra`：复杂实现、跨模块调试、深度审查和根因分析。
|
|
- 升级顺序：`spark` 或 `luna` → `terra` → 主智能体。
|
|
|
|
## 协作规则
|
|
|
|
- 简单任务由主智能体直接完成；仅在子任务独立且可验证时使用多个智能体。
|
|
- 委派时必须说明目标、负责范围、禁止修改范围、验收标准和验证方式。
|
|
- 并行修改必须划分文件或模块所有权，不得让两个智能体同时修改同一处代码。
|
|
- 不得撤销、覆盖或整理用户及其他智能体的修改。
|
|
- 子智能体发现任务超出职责时立即上报，不得继续猜测性探索。
|
|
- 主智能体负责审查子智能体的修改和验证证据。
|
|
|
|
## 开发要求
|
|
|
|
- 修改前检查仓库状态并阅读相关文件。
|
|
- 优先复用现有模式，实施能够解决问题的最小改动。
|
|
- 未经允许，不新增生产依赖，不修改数据库结构，不扩大权限。
|
|
- 修复缺陷应处理根因，并补充必要的回归验证。
|
|
- 涉及风险状态流转时，检查权限、审计、幂等、并发、回滚和非法状态跃迁。
|
|
- 不得泄露或提交密码、令牌、个人敏感信息和内部安全数据。
|
|
- 对于Windows系统，必须在WSL环境中进行开发。中间件推荐使用WSL中的docker运行。Python使用WSL中的venv虚拟环境进行开发与测试。
|
|
- 在尚未完成1.0版本发布之前，不需要考虑数据库迁移问题，直接重构数据库即可。
|
|
|
|
## 验证与交付
|
|
|
|
- 从项目实际配置中识别测试、检查和构建命令。
|
|
- 先运行与修改直接相关的最小验证，再按风险扩大范围。
|
|
- 无法验证时，说明原因和剩余风险。
|
|
- 最终说明应包含：完成内容、修改文件、验证结果和未解决问题。
|
|
- 未经用户明确要求，不创建分支、不提交、不推送。
|
|
|
|
## 完成标准
|
|
|
|
- 用户要求已经满足。
|
|
- 没有无关修改或临时内容。
|
|
- 相关验证已通过，或限制与风险已明确说明。
|
|
- 主智能体已审查最终差异。
|
|
|
|
## Agent skills
|
|
|
|
### Issue tracker
|
|
|
|
本仓库使用 `.scratch/<feature>/` 下的本地 Markdown 文件管理需求、规格和任务。详见 `docs/agents/issue-tracker.md`。
|
|
|
|
### Triage labels
|
|
|
|
本仓库使用五类默认 triage 状态：`needs-triage`、`needs-info`、`ready-for-agent`、`ready-for-human`、`wontfix`。详见 `docs/agents/triage-labels.md`。
|
|
|
|
### Domain docs
|
|
|
|
本仓库采用单上下文领域文档结构：根目录使用 `CONTEXT.md`，架构决策记录放置于 `docs/adr/`。详见 `docs/agents/domain.md`。
|