Opsx 支持将代码仓库作为 Repo Asset 管理，并让 Agent 在指定仓库中读取和修改代码。整个过程不依赖开发者本地 IDE，代码差异、提交记录和恢复路径仍由 Git 管理。
MES Workspace 下的 issue_50 和 issue_77 分别验证了仓库查询与代码修改能力。
从 Repo Asset 定位代码
Repo Asset 保存仓库的稳定身份和执行上下文，包括：
- 仓库类型、技术栈和默认分支；
- Runtime 中的工作目录；
- 源码仓库与应用服务的关联关系；
- 能够访问该仓库的 Runtime。
创建 Issue 时只需绑定目标 Repo Asset。Opsx 根据资产与 Runtime 的映射，将任务交给具备仓库访问能力的 Agent，无需在 Prompt 中重复提供主机、路径和分支信息。
issue_50 绑定 Java 后端仓库 repo-enmo-support。Claude Runner 读取 Asset Metadata 后，在对应 Runtime 中执行 Git 查询，确认仓库包含四个远端分支：dev、master、report 和 word，默认分支为 dev。
Execution 先执行 git fetch --all --prune 更新远端引用，再通过 git branch -r 返回分支清单。
在真实仓库中完成代码修改
issue_77 的需求是将 /service 服务请求页面中的“环境信息”改为必填。Issue 绑定前端仓库 Asset repo-service-front，其中已经记录 dev 分支、Vue 技术栈、仓库工作目录以及与前端服务的 source_of 关系。
Claude Runner 通过对应 Runtime 读取源码，确认 /service 经 BreakInit.vue 分别进入桌面端 Break.vue 和移动端 BreakMobile.vue，环境信息字段由共享组件 MenuForm.vue 渲染。
修改同时覆盖桌面端、移动端和共享组件：
MenuForm.vue支持由调用方传入校验规则，未传入时保持原有行为；Break.vue为桌面端增加必填规则，并覆盖正常提交与补录路径；BreakMobile.vue增加移动端表单规则和保存前校验。
实际代码变更为 3 个文件、22 行新增、5 行删除。以下是经过删减的关键 diff：
- <el-form-item :label="...">
+ <el-form-item prop="menuId" :rules="rules" :label="...">
+ if (!breakInfo.value.menuId) {
+ Message('请选择环境信息')
+ return false
+ }
+ name="menuId"
+ :rules="[{ required: true, message: '请选择环境信息' }]"
Agent 完成修改后，先在 Issue 中返回文件清单、关键 diff 和影响说明，并保留未提交的 Git 工作区，等待人工确认。
代码变更仍由 Git 控制
经人工检查修改内容后，在 Issue 中明确授权 Agent 将代码提交并推送到 dev 分支。
提交过程中，远端分支出现了新的并发 Commit，Git 拒绝了非 Fast-forward Push。Agent 获取最新代码并执行 git pull --rebase，将本次修改重放到最新版本后再次推送，没有覆盖其他人的提交。
最终 Git 结果如下：
Commit 8daf61c
Message feat(sr): /service 提交页面将“环境信息”字段改为必填
Changes 3 files changed, 22 insertions(+), 5 deletions(-)
Push 0f6573a..8daf61c dev -> dev
Hooks PASSED
Status working tree clean
Git Diff 和 Commit 保存了变更范围与操作身份，分支机制处理多人并发修改，远端 Hook 执行仓库已有检查。如需撤销，可以通过 git revert 8daf61c 创建反向 Commit，并保留完整历史。本次没有实际执行回退，因此只能确认代码具备审计和恢复路径，不能据此认为自动修改不存在风险。
代码推送到 dev 后，仓库已有的 CI/CD 自动触发构建。本次修改首次构建即成功，没有经过返工。虽然 Agent 所在 Runtime 当时没有安装 Node.js，无法在仓库工作区直接执行 vue-cli-service build，但并未影响现有流水线完成自动构建。
生产发布采用同样清晰的分支规则：代码合并到 master 后自动触发生产流水线。本案例验证到 dev 自动构建成功，没有将“具备生产发布路径”表述为“已经发布到生产”。
Opsx 在这条链路中提供平台化的代码操作入口：Repo Asset 确定仓库和服务关系，Issue 保存需求、授权与执行记录，Runtime 提供执行环境，Agent 修改代码，Git 管理差异、提交和恢复，现有 CI/CD 继续负责构建与发布。Claude Code、OpenCode、LLM 或其他执行后端可以替换，仓库信息和任务记录仍保留在平台中。
这条链路一旦完成联调，Opsx 就可以继续承接更多端到端任务：从 Issue 理解问题或需求，在正确仓库中修改代码，经过人工或策略 Gate 后提交，由 CI/CD 自动构建；生产发布则通过合并 master 触发。它既可以缩短已定位问题的修复时间，也可以支持小型需求快速实现和上线，同时保留 Git 与流水线原有的工程控制。
针对 Repo Asset，Opsx 后续还计划在 Discovery 阶段增加类似 Repo Wiki 的能力，持续整理代码结构、模块职责、路由、依赖关系、构建方式和历史变更。Agent 在执行新任务前可以直接复用这些仓库认知，减少重复扫描源码的成本，提高代码定位与修改效率。该能力目前属于规划，不是本案例已经实现的功能。