docs: record GPT RDC Codex collaboration protocol

README.md

@@ -35,6 +35,7 @@ project/
 
 - [GSRL.md](GSRL.md)：正式规则和交付/接收验收标准
 - [SOURCE_LOCK.example.json](SOURCE_LOCK.example.json)：最小 Source Lock 格式示例（占位符不是实际发行）
+- [GPT—RDC—Codex 协作执行约定](docs/GPT_RDC_Codex_协作执行约定.md)：维护者的具体工作流程，仅供参考，**不是 GSRL 的通用强制条件**。
 
 **本仓库**：https://git.eyaku.jp/tei/GSRL
 

docs/GPT_RDC_Codex_协作执行约定.md

@@ -0,0 +1,68 @@
+# 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 返回的客观证据审核。**