docs: 组织升级 — 公司统一规范 + inbox消息系统 + PM个人逻辑
This commit is contained in:
30
.showen/COMPANY_RULES.md
Normal file
30
.showen/COMPANY_RULES.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# 公司统一规范
|
||||
|
||||
## 代码规范
|
||||
- 提交前必须执行 `cargo check`,并保持零 warning。
|
||||
- 提交前必须执行 `cargo test`,并确保全部通过。
|
||||
|
||||
## 提交规范
|
||||
- `git commit` 消息统一使用以下前缀:`feat:`、`fix:`、`docs:`、`test:`、`refactor:`。
|
||||
- 提交信息应简洁描述本次变更目的,避免无意义描述。
|
||||
|
||||
## 沟通规范
|
||||
- 集体沟通统一记录在 `.showen/TEAM_CHAT.md`。
|
||||
- 个人定向沟通统一写入 `.showen/inbox/<name>.md`。
|
||||
|
||||
## 文件结构规范
|
||||
- `docs/`:存放流程文档。
|
||||
- `.showen/`:存放管理状态与协作文档。
|
||||
- `souls/`:存放灵魂文件。
|
||||
|
||||
## 质量规范
|
||||
- 新功能必须附带测试。
|
||||
- P0 问题必须当天修复。
|
||||
|
||||
## kilo 使用规范
|
||||
- 不读大 diff,优先阅读必要文件和局部上下文。
|
||||
- 命令越简单越好,减少复杂链式操作。
|
||||
|
||||
## 执行纪律
|
||||
- 每个员工完成任务后,必须更新自己的 `soul` 文件。
|
||||
- 每个员工开始任务前,必须先检查 `.showen/inbox/<自己名字>.md` 是否有新消息。
|
||||
15
.showen/inbox/README.md
Normal file
15
.showen/inbox/README.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Inbox 消息系统
|
||||
|
||||
## 规则
|
||||
- 发送:将消息写入对方的 `.showen/inbox/<name>.md`。
|
||||
- 接收:读取后删除文件内容,可清空文件或直接删除文件。
|
||||
- 已读确认:文件被清空即表示对方已读。
|
||||
- 格式:每条消息必须包含 `[发送方] [时间] [消息内容]`。
|
||||
|
||||
## 命名
|
||||
- CEO 的 inbox 文件:`ceo.md`
|
||||
- PM 的 inbox 文件:`pm.md`
|
||||
|
||||
## 建议
|
||||
- 同一文件内按时间顺序追加消息,避免覆盖未读内容。
|
||||
- 处理完成后及时清空,保持 inbox 可读性。
|
||||
0
.showen/inbox/ceo.md
Normal file
0
.showen/inbox/ceo.md
Normal file
0
.showen/inbox/pm.md
Normal file
0
.showen/inbox/pm.md
Normal file
Reference in New Issue
Block a user