20 个章节 · 支持关键词组合搜索
日常研发操作剧本
实践 / 建议日常研发：从一句需求到可合并 MR
剧本 A：单仓小需求
建议以 IDP 的 Issue/EARS 方式作为轻量参考。 产品/开发可在 Multica 或 PC 客户端给出触发条件、预期结果、异常路径； 澄清结果写入关联 GitLab Issue，领队固定当前 验收标准、合同内容摘要和规则版本，选适用流程。 开发 Agent 先 doctor，再按代码导航实现一个可验收增量，补有效回归测试并跑窄验证。 每次交接携带已推送分支和 SHA、变更范围、测试报告、阻塞项；本机 checkpoint 仅供本机恢复。 完整过程在 Multica Issue/topic reply 留存，里程碑摘要回写 GitLab Issue 备注。
确定性执行器负责必要检查、版本核验和结果收集；模型负责分析未知与实现。 验证者获取固定提交，独立重跑必需检查；评审者核对需求、diff 和实际证据。 Golden Path 分支验证与评审通过后创建 MR，由 DRI 合并；后续生产发布仍由现有人工流程执行。
剧本 B：跨 AppFramework、metadata、SFA 的变化（建议演练）
以“某项自定义对象契约调整”为演练主题，不假定三个仓的真实调用关系已经完整核实。 先用代码检索与服务目录确认生产者/消费者，再冻结接口与兼容条件。 ai-wiki 保留审定业务规则与稳定 验收标准，业务仓各自保留实现和测试；必要时用 FSpec 分解 DAG。
| 顺序 | 工作 | 交接产物 |
|---|---|---|
| 1 | 明确新旧客户端、旧数据、租户与权限行为 | 版本化契约、正负样例、明确未决问题 |
| 2 | 选择先兼容后切换的顺序，无法兼容则制定受控联合发布 | 仓库依赖图和每阶段可运行组合 |
| 3 | 各仓实现并独立验证 | 每仓 SHA、MR、必需套件与报告 |
| 4 | 在固定组合上执行消费端契约和用户旅程 | 交付集合：全部制品版本、配置、数据集、验收结果 |
| 5 | 按依赖合并与上线，观察后移除旧路径 | 完成条件、回退组合、后续清理任务 |
一个子 MR 合并不能关闭总需求；其中一个 SHA、基础依赖或环境组合变化，要重验受影响部分。 不能把“每仓单测都绿”自动解释为“跨仓组合兼容”。
剧本 C：验证失败、节点中断、人工接管
验证失败先分类：实现错误、测试错误、环境阻塞、数据问题、范围漏测、偶发不稳定。 只在对应原因上重试，保留首次失败；禁止通过删断言、忽略失败或缩小必需范围获取绿灯。 建议试点默认最多两轮修复反馈、一个总时限，由团队按成本与风险调整；无进展则转人工。 重大事故和越权请求即时升级，不等待次数耗尽。
节点中断后读取任务账本、已推送 revision、证据和锁租约；不能靠上一段模型聊天恢复。 写操作采用幂等键及结果核对，过期执行者不得继续发布或覆盖新结果。 这些恢复语义属于待验收的平台合同，不能由“Multica 支持重试”推导为全链路恰好执行一次。
接管卡应说明当前有效 SHA、已完成 验收标准、阻塞原因、最近失败、环境占用和建议下一步。 人工暂停后自动调度不得自行恢复；复开任务时重新确认输入版本和适用权限。
本节依据： IDP 任务流程、Git 与交接、Egress 委托合同；FSpec 交接见 L2。