# Contributing

欢迎提交问题、补丁和设计建议。这个仓库现在是独立服务仓库，协作时默认按服务代码库的标准来处理，不再依赖 monorepo 语境。

## 提交前要求

在提交 PR 前，至少完成以下验证：

```bash
go test ./... -count=1 -p 1
go test -race ./... -p 1
go vet ./...
```

说明：

- 当前默认本地测试库是共享的 PostgreSQL `localhost:5434/ai_customer_service`
- 为避免跨包并发测试互相污染测试表，默认使用 `-p 1` 串行执行 Go 测试
- 如果后续切到隔离测试库或每包独立数据库，再考虑恢复并发

如果改动涉及生产门禁、回滚、平台适配或配置契约，还要补跑对应脚本或最小验证：

```bash
bash -n scripts/verify_preprod_gate_b.sh
bash -n scripts/verify_gate_c_rollback.sh
```

## 变更原则

- 保持改动最小、局部、可验证。
- 不要把 `Sub2API` / `NewAPI` 的边缘适配逻辑渗透到 `dialog`、`ticket`、`audit` 主链内部。
- 不要在没有证据的情况下把“测试通过”写成“可生产上线”。
- 修改配置契约时，同步更新文档和测试状态文件。

## 推荐提交流程

1. 先补失败测试。
2. 再实现最小改动。
3. 再跑全量测试和相关脚本。
4. 最后提交 Conventional Commit。

## 提交信息

建议格式：

```text
feat(scope): summary
fix(scope): summary
docs(scope): summary
test(scope): summary
refactor(scope): summary
chore(scope): summary
```

## 代码评审关注点

- 配置项是否与 `docs/CONFIG_CONTRACT_BASELINE.md` 一致
- 新接口是否有明确的错误码和测试
- 平台适配是否仍然只停留在边缘层
- callback / outbox / dead letter 是否可追踪、可重放
- `.github/workflows/ci.yml` 与 `.gitea/workflows/ci.yml` 的 `name: CI` 和 `jobs.verify` 是否保持稳定，避免破坏受保护状态上下文

## 参考文档

- [README](README.md)
- [Configuration Contract](docs/CONFIG_CONTRACT_BASELINE.md)
- [Platform Callback Runbook](docs/RUNBOOK_PLATFORM_CALLBACKS.md)
- [Sub2API Mapping](docs/SUB2API_MINIMAL_WEBHOOK_MAPPING.md)