69 lines
4.9 KiB
Markdown
69 lines
4.9 KiB
Markdown
# GPT—RDC—Codex 协作执行约定 v1.0
|
||
|
||
> **定位：GSRL 维护者自己的开发协作规则；不是 GSRL 对外通用发行规范的强制部分。**
|
||
>
|
||
> 适用于维护者所有独立 Git 项目及 Win11、Mac、Linux 等设备。正式发行的普遍要求仍以 [GSRL.md](../GSRL.md) 为准。
|
||
|
||
## 1. 角色与职责
|
||
|
||
| 角色 | 责任 |
|
||
| --- | --- |
|
||
| **用户** | 确定目标、授权边界、关键发布决定及必要的人工验收。 |
|
||
| **GPT** | 与用户讨论方案、明确任务和验收标准、指挥 RDC、核查证据、向用户汇报。 |
|
||
| **RDC** | GPT 指挥下的统一设备操作入口；直接调查、改代码、执行命令，或调用 Codex；负责正式编译、打包、Source Lock、发行、接收校验的实际操作。 |
|
||
| **Codex** | 由 RDC 按需调用，负责代码调查、实现、重构、修复、开发测试、文档及授权范围内的开发 Git 操作。原则上不负责正式发行。 |
|
||
| **其他工具** | 根据 GPT 的任务调度执行专用工作，不自行改变发行规则。 |
|
||
|
||
**核心关系：用户与 GPT 定目标 → GPT 指挥 RDC → RDC 直接执行或调用 Codex → GPT 审核结果。**
|
||
|
||
## 2. 日常开发
|
||
|
||
1. 用户与 GPT 明确开发目标、范围、限制和是否涉及正式交付。
|
||
2. GPT 在执行前概述 RDC 的步骤、目标、关键约束及验收点；用户已有明确授权时直接执行。
|
||
3. RDC 可以直接修改项目代码或执行命令，不必事事调用 Codex；复杂任务可通过 RDC 调用 Codex。
|
||
4. Codex 负责开发成果，不因完成代码任务而被视为已正式发行。
|
||
5. RDC 返回实际执行信息，GPT 核验后决定下一步；日常开发和临时调试不自动进行 GSRL。
|
||
|
||
Codex 可按具体开发任务要求创建开发 Commit、Push 开发分支；这些操作不等于正式发布、Tag 或 Source Lock。
|
||
|
||
## 3. RDC 严格串行与 Codex 完成判定
|
||
|
||
- 每个 RDC 步骤必须有明确的完成结果、关键产物及验收结论，才能进入有依赖的下一步；超时、仍在运行、连接中断均不是完成。
|
||
- RDC 调用 Codex 时，优先使用 `codex exec --json`，依据完整 JSONL 的 `turn.completed` 或 `turn.failed` 识别 Codex 轮次终态，不能用 PID 退出代替。
|
||
- Codex 完成后，RDC 还需核对文件修改、约定的测试、必做报告、Git Commit/Push（如果任务要求）及远端实际状态；才能认定任务通过。
|
||
- GPT 应向用户逐步报告每步的执行内容、最终状态、关键输出以及是否进入下一步。
|
||
- 失败时在当前步骤诊断和处理，遵循既有 RDC 串行、重试和安全规则；不得越权自动清理或继续后续步骤。
|
||
- 项目已指定必须由用户手工执行的真机编译、安装、签名或验收，不能被 RDC 或 Codex 虚报为已完成。
|
||
|
||
## 4. 正式发行与 GSRL
|
||
|
||
**只有任务进入正式交付阶段，才启动 GSRL 发行流程。**
|
||
|
||
1. GPT 与用户明确发布对象、版本、交付范围与验收标准，并向 RDC 下达发行任务。
|
||
2. RDC 检查实际使用的仓库/Worktree、完整 Commit、Dirty 状态及远端可恢复性，不以其他工作树的 HEAD 或版本常量猜测。
|
||
3. RDC 按项目既有方式实际编译、打包和校验文件，生成或更新 `SOURCE_LOCK.json`，并维护项目自己的 `release/README.md`。
|
||
4. 在任务授权范围内，RDC 执行发行相关 Commit、Tag、Push、制品上传和远端核验。
|
||
5. GPT 根据实际 Git、哈希、文件和远端证据，判断是否达到 GSRL PASS 并报告。
|
||
|
||
**Codex 原则上不负责正式编译打包、Source Lock、发行 Tag、制品上传或正式发布验收。** 发行检查发现代码缺陷时，可由 GPT 指挥 RDC 调用 Codex 修复；之后仍由 RDC 重新检查、打包和发行。
|
||
|
||
未经授权不得强制 Push、覆盖发行版本、丢弃无关 Dirty 修改或以未验证的结果冒称发行成功。
|
||
|
||
## 5. 使用方接收正式成果
|
||
|
||
1. GPT 指挥 RDC 读取交付项目公布的 `release/README.md`，确定版本及使用方法。
|
||
2. RDC 获取正式发行包与 Source Lock，核对来源、依赖并重新计算收到文件的 SHA-256。
|
||
3. 验证通过后执行接入；涉及业务代码修改时，RDC 可以直接处理或调用 Codex。
|
||
4. GPT 根据接收与运行验证结果验收，不能把“复制成功”视为“版本正确且运行通过”。
|
||
|
||
## 6. 范围与维护
|
||
|
||
- 该流程适用于维护者**所有独立 Git 项目**，不以 NavSea 或任何设备为中心。
|
||
- Git 及正式发行文件是事实依据；GPT 聊天记忆不能替代 Git 证明。
|
||
- GSRL 本身是与语言、设备、工具无关的**发行规范**。此文档只是维护者的协作实践，其他 GSRL 使用者可以采用完全不同的团队和工具。
|
||
- 后续新工具加入，只扩充执行手段；角色或授权边界如需改变，应由用户与 GPT 明确更新此约定。
|
||
|
||
---
|
||
|
||
**开发由 Codex 按需协助；正式交付由 GPT 指挥 RDC 执行；是否真正完成由 GPT 依据 RDC 返回的客观证据审核。**
|