19 lines
1.8 KiB
Markdown
19 lines
1.8 KiB
Markdown
# 契约目录维护规则
|
|
|
|
## 目录边界
|
|
|
|
- `schema/` 是共享仓库 `git@gitee.com:zzmbac/sip-contracts.git` 的 Git submodule，只保留 SaaS↔Dispatcher 对接所需的业务规范、Schema、MQ 拓扑和正常示例。
|
|
- `schema/README.md` 将 Schema 和 Examples 分为两张用途表；业务规范 Markdown 和 `mq-topology.json` 在正文单独链接说明，不列入表格，不列 README 自身，不放本项目维护或验证说明。
|
|
- 本项目的验证材料留在当前目录：`manifest.json`、`verify.py`、`test_verify.py`、Go 测试、`examples/invalid/`、`archive/sources/`。不得重新写入共享仓库或嵌入运行契约。
|
|
- `archive/sources/` 中两份历史来源保留原字节；不作为当前规范、运行配置或真实签收依据。
|
|
- 共享 Schema 是唯一字段定义，不在本地复制或维护另一份 Schema。
|
|
|
|
## 同步与检查
|
|
|
|
- 调研或修改契约前必须在项目根目录执行 `make contracts-update`；失败即停止，保留现存改动。
|
|
- 普通构建只使用固定 submodule 提交，不自动联网追新，不回退旧契约。
|
|
- 现行合同只由 Git submodule 提交号固定，不维护逐文件或整包 hash。`manifest.json` 仅保存冻结历史归档的来源证据，不是 SaaS 配置；历史证据不可改写。`verify.py` 仍检查离线 Schema 引用和历史来源完整性。
|
|
- 共享变更须提交并推送共享仓库，再同步本项目 submodule 指针、实现、测试和文档，并通知 SaaS 开发人员。共享仓库单独提交不算完成。
|
|
- 交付前执行 `make contract-check`、`make check` 和 `make release-check-local`；本地模拟验证不代替真实 SaaS、线路或生产签收。
|
|
- 不暂存、提交、覆盖或清理使用者无关修改。具体同步流程见 `../docs/contracts.md`。
|