@fitlab-ai/agent-infra 0.9.2 → 0.9.3

package/templates/.agents/skills/run-task/config/verify.zh-CN.json

@@ -4,6 +4,7 @@
     "task-meta": {
       "required_fields": ["id", "status", "updated_at", "agent_infra_version", "current_step", "assigned_to"]
     },
-    "orchestration-state": {}
+    "orchestration-state": {},
+    "orchestration-evidence": {}
   }
 }

package/templates/.agents/skills/run-task/reference/host-validation.en.md

@@ -0,0 +1,20 @@
+# Host Contract Validation
+
+Before publishing support for a client, prove the lifecycle evidence chain with real host events. Bridge tests prove field mapping only; they do not prove host provenance.
+
+## Required Evidence
+
+- Client version, enabled multi-agent capability, launch surface, and trust boundary.
+- Raw start/stop events stably provide event type, managed agent, parent/child identity, fresh spawn mode, actual model, and actual reasoning effort.
+- Explicit requested model/effort reaches each executor/reviewer. A fallback of either field reports the corresponding actual value and its own non-empty reason.
+- Candidate-checkout and packed-install behavior match, with model policy, receipts, and verification results auditable in `orchestration.json`.
+
+## Validation Sequence
+
+1. Record client version, feature state, and launch command in a clean temporary repository.
+2. Start a fresh executor and reviewer, retaining redacted raw stdin and the structured run. Never synthesize a field the host did not emit.
+3. Validate model/effort match paths, single and dual justified fallbacks, and fail-closed behavior for missing actual fields.
+4. Validate the same commit from a candidate checkout and an `npm pack` install; record the tarball hash and results.
+5. Commit only redacted summaries and non-sensitive fixtures. Remove or replace tokens, user-specific absolute paths, transcript content, and credentials.
+
+If any required field cannot be observed reliably from the real host, keep that client's orchestration capability `unsupported` and record the gap as manual validation.

package/templates/.agents/skills/run-task/reference/host-validation.zh-CN.md

@@ -0,0 +1,20 @@
+# 宿主契约验证
+
+发布支持某个客户端前，必须用真实宿主事件证明生命周期证据链；bridge 单测只证明字段映射，不能证明事件来自宿主。
+
+## 必须证明的字段
+
+- 客户端版本、启用的多代理能力、启动入口与信任边界。
+- 原始 start/stop 事件能稳定给出 event type、managed agent、parent/child identity、fresh spawn mode、actual model 和 actual reasoning effort。
+- 显式 requested model/effort 能传给 executor/reviewer；宿主对任一字段回退时，事件能给出对应 actual 值与独立的非空 fallback reason。
+- candidate checkout 与打包安装后的行为一致，且模型策略、receipt 与验证结果可从 `orchestration.json` 复核。
+
+## 验证顺序
+
+1. 在干净临时仓库记录客户端版本、feature 状态和启动命令。
+2. 分别启动 fresh executor 与 fresh reviewer，保存去敏后的原始 stdin 和结构化 run；不得补写宿主未产生的字段。
+3. 分别验证 model/effort 的 requested/actual 一致路径、单项与双项有理由 fallback 路径，并确认缺 actual 字段会失败关闭。
+4. 对同一 commit 执行 candidate checkout 与 `npm pack` 安装验证，记录 tarball 哈希和结果。
+5. 仅把去敏摘要与非敏感 fixture 纳入版本库；token、绝对用户路径、transcript 内容和凭证必须删除或替换。
+
+任一字段无法从真实宿主稳定观察时，该客户端的 orchestration capability 保持 `unsupported`，并把缺口记录为人工验证项。

package/templates/.agents/skills/update-agent-infra/scripts/sync-templates.js

@@ -40,7 +40,7 @@ const DEFAULTS = {
       "installInSandbox": true
     },
     {
-      "id": "gemini-cli",
+      "id": "antigravity-cli",
       "enabled": true,
       "installInSandbox": true
     },
@@ -146,18 +146,12 @@ const AGENT_CLIENT_MANIFEST = [
     "ejected": []
   },
   {
-    "id": "gemini-cli",
-    "displayName": "Gemini CLI",
-    "invocation": "/${projectName}:${skillName}",
-    "ownedPathPrefixes": [
-      ".gemini/"
-    ],
-    "managed": [
-      ".gemini/commands/"
-    ],
-    "merged": [
-      ".gemini/settings.json"
-    ],
+    "id": "antigravity-cli",
+    "displayName": "Antigravity CLI",
+    "invocation": "/${skillName}",
+    "ownedPathPrefixes": [],
+    "managed": [],
+    "merged": [],
     "ejected": []
   },
   {
@@ -276,10 +270,11 @@ function normalizeAgentClientConfig(cfg) {
     }
     const keys = Object.keys(candidate);
     if (
-      keys.length !== 3
+      (keys.length !== 3 && keys.length !== 4)
       || !own(candidate, 'id')
       || !own(candidate, 'enabled')
       || !own(candidate, 'installInSandbox')
+      || (keys.length === 4 && !own(candidate, 'orchestration'))
     ) {
       return failure('INVALID_AGENT_CLIENTS', entryPath);
     }
@@ -290,9 +285,32 @@ function normalizeAgentClientConfig(cfg) {
     if (typeof candidate.enabled !== 'boolean' || typeof candidate.installInSandbox !== 'boolean') {
       return failure('INVALID_AGENT_CLIENTS', entryPath);
     }
+    let orchestration;
+    if (own(candidate, 'orchestration')) {
+      const policy = candidate.orchestration;
+      const exact = (value) => typeof value === 'string' && value.length > 0 && value.trim() === value;
+      const validRole = (role) => role
+        && typeof role === 'object'
+        && !Array.isArray(role)
+        && Object.keys(role).length === 2
+        && exact(role.model)
+        && exact(role.reasoningEffort);
+      if (
+        !policy
+        || typeof policy !== 'object'
+        || Array.isArray(policy)
+        || Object.keys(policy).length !== 2
+        || !validRole(policy.executor)
+        || !validRole(policy.reviewer)
+      ) {
+        return failure('INVALID_AGENT_CLIENTS', `${entryPath}.orchestration`);
+      }
+      orchestration = structuredClone(policy);
+    }
     entries.set(candidate.id, {
       enabled: candidate.enabled,
-      installInSandbox: candidate.installInSandbox
+      installInSandbox: candidate.installInSandbox,
+      ...(orchestration ? { orchestration } : {})
     });
   }
   if (BUILTIN_TUI_IDS.some((id) => !entries.has(id))) {
@@ -547,14 +565,13 @@ function detectCustomSkills(projectRoot, templateSkillNames) {
     .sort((left, right) => left.dirName.localeCompare(right.dirName));
 }
 
-function isCustomProtected(targetPath, customSkills, project, customTUICommandTargets) {
+function isCustomProtected(targetPath, customSkills, customTUICommandTargets) {
   const normalized = norm(targetPath);
 
   return customSkills.some(({ dirName }) => (
     normalized.startsWith(`.agents/skills/${dirName}/`) ||
     normalized === `.claude/commands/${dirName}.md` ||
     normalized === `.opencode/commands/${dirName}.md` ||
-    normalized === '.gemini/commands/' + project + '/' + dirName + '.toml' ||
     customTUICommandTargets.has(normalized)
   ));
 }
@@ -763,15 +780,6 @@ function formatYamlMetadata(key, value) {
   return [`${key}: |-`, ...value.split('\n').map((line) => `  ${line}`)];
 }
 
-function formatTomlMetadata(key, value) {
-  if (!value.includes('\n')) {
-    return `${key} = ${JSON.stringify(value)}`;
-  }
-
-  const lines = value.split('\n').map((line) => JSON.stringify(line).slice(1, -1));
-  return `${key} = """${lines.join('\n')}"""`;
-}
-
 function generateClaudeCommand(skill, lang) {
   const isZhCN = lang === 'zh-CN';
   const lines = ['---', ...formatYamlMetadata('description', skill.description)];
@@ -796,31 +804,6 @@ function generateClaudeCommand(skill, lang) {
   return `${lines.join('\n')}\n`;
 }
 
-function generateGeminiCommand(skill, lang) {
-  const isZhCN = lang === 'zh-CN';
-  const promptLines = [];
-
-  if (skill.args) {
-    promptLines.push(isZhCN ? '参数：{{args}}' : 'Arguments: {{args}}');
-    promptLines.push('');
-  }
-
-  promptLines.push(
-    isZhCN
-      ? `读取并执行 \`.agents/skills/${skill.dirName}/SKILL.md\` 中的 ${skill.dirName} 技能。`
-      : `Read and execute the ${skill.dirName} skill from \`.agents/skills/${skill.dirName}/SKILL.md\`.`
-  );
-  promptLines.push('');
-  promptLines.push(isZhCN ? '严格按照技能中定义的所有步骤执行。' : 'Follow all steps defined in the skill exactly.');
-
-  return [
-    formatTomlMetadata('description', skill.description),
-    'prompt = """',
-    ...promptLines,
-    '"""'
-  ].join('\n') + '\n';
-}
-
 function generateOpenCodeCommand(skill, lang) {
   const isZhCN = lang === 'zh-CN';
   const lines = [
@@ -1069,7 +1052,6 @@ function learnAndGenerateCommands(projectRoot, customSkills, tool, templateSkill
 function generateCustomCommands(
   projectRoot,
   customSkills,
-  project,
   lang,
   report,
   customTUIs,
@@ -1085,13 +1067,6 @@ function generateCustomCommands(
         report.custom.commands
       );
     }
-    if (enabledTUIs.has('gemini-cli')) {
-      managedWriter(
-        '.gemini/commands/' + project + '/' + skill.dirName + '.toml',
-        generateGeminiCommand(skill, lang),
-        report.custom.commands
-      );
-    }
     if (enabledTUIs.has('opencode')) {
       managedWriter(
         `.opencode/commands/${skill.dirName}.md`,
@@ -1699,7 +1674,7 @@ function syncTemplates(projectRoot, templateRootOverride) {
         for (const projFile of projFiles) {
           if (expectedTargets.has(projFile)) continue;
           if (projFile === configPathRel) continue;
-          if (isCustomProtected(projFile, protectedCustomSkills, project, customTUICommandTargets)) continue;
+          if (isCustomProtected(projFile, protectedCustomSkills, customTUICommandTargets)) continue;
           if (matchesAny(projFile, merged) || matchesAny(projFile, ejected)) continue;
           if (assetPlan.enabledManaged.includes(entry)) {
             const baseline = trustedBaseline(managedBaselines[projFile]);
@@ -1741,7 +1716,6 @@ function syncTemplates(projectRoot, templateRootOverride) {
   generateCustomCommands(
     projectRoot,
     customSkills,
-    project,
     lang,
     report,
     customTUIs,

package/templates/.agents/skills/watch-pr/SKILL.en.md

@@ -1,17 +1,17 @@
 ---
 name: watch-pr
 description: >
-  Watch a PR's required checks and self-heal on failure.
-  Use when you need to monitor a PR's required checks and auto-recover on failure.
+  Watch PR readiness and self-heal required-check failures or merge conflicts.
+  Use when a PR must be monitored until checks pass and it is explicitly mergeable.
 ---
 
 # Watch Pull Request
 
-After `create-pr`, continuously watch the PR's required CI checks: when everything is green, guide toward merge; when a required check fails, pull the logs, fix and push locally, then re-poll; when the fix attempt limit is reached or the failure is non-code / unlocatable, stop and ask the user for help. Platform-specific commands live in `.agents/rules/pr-checks-commands.md`; this skill body stays platform-agnostic.
+After `create-pr`, continuously watch required checks and mergeability for the same PR head. Only passed checks plus explicit mergeability may reach success; check failures use the existing repair path, conflicts use constrained rebase healing, and unknown or unsafe states fail closed.
 
 ## Behavior Boundaries / Key Rules
 
-- Only watch + self-heal the current PR's required checks; make no changes unrelated to the failing check.
+- Only self-heal the current PR's required checks and text merge conflicts; do not add approval or repository-rule readiness dimensions.
 - Self-heal publishes through Git workflow intents, but **affected tests must pass first**; the attempt cap and code-layer authorization remain unchanged.
 - The help exit is "produce-then-stop": end this round, output the blocker explanation, and wait for the user to trigger the next step — **never** ask mid-flow.
 - Bare numbers / `NN` / `TASK-id` arguments are always resolved as task short ids (see `.agents/rules/task-short-id.md`); a PR number is passed only via `--pr <number>` / a PR URL / omission (current branch), never reusing the bare-number syntax.
@@ -44,21 +44,21 @@ Resolve the target PR number `{pr#}` and an optional `{task-id}` via these deter
 - Scenario C (`--pr <number>` or a PR URL): use that PR number directly as `{pr#}`; then determine `{task-id}` via "Reverse-lookup task".
 - Reverse-lookup task (scenarios A / C): use task context/query capabilities to find the unique active task bound to `{pr#}`. If none exists, stop and request binding first; the typed checks intent does not create a second taskless state machine.
 
-### 2. Watch Required Checks
+### 2. Watch PR Readiness
 
 Before running this step, read `reference/monitor-and-heal.md` and `.agents/rules/pr-checks-commands.md`.
 
-Initialize the in-memory list `repairCommits=[]` for this run. Run `agent-infra-internal platform-checks watch {task-id} --interval-seconds 30 --deadline-seconds 1800`, then route its structured `checks.state` to the all-green, failure, or pending path.
+Initialize `repairCommits=[]` and `rebaseAttempts=0`. Run `agent-infra-internal platform-checks watch {task-id} --interval-seconds 30 --deadline-seconds 1800`, then route only by `readiness.state`: `ready` to step 7, `conflicting|checks-failed` to step 3, and `pending|timed-out|cancelled` to step 4.
 
-### 3. Failure Self-Heal Loop
+### 3. Self-Heal Loop
 
 Before running this step, read the "Self-Heal Decision Tree" of `reference/monitor-and-heal.md` and "Resolve a Failing Run id and Pull Logs" of `.agents/rules/pr-checks-commands.md`.
 
-For a locatable code-layer failure, make the minimum fix and run relevant tests. Then call `git-workflow commit` and `git-workflow push`; append only a remotely verified SHA to `repairCommits`.
+For `checks-failed`, minimally fix a locatable code-layer failure, test, and publish through the existing commit/push intents. For `conflicting`, follow the reference's same-repository, clean-tree, head/base identity, rebase, full-test, and `git-workflow push-rebased` exact-lease flow, capped at two attempts. Append only remotely verified SHAs, then watch the new head again; any failed safety check goes to step 4.
 
 ### 4. Help Exit (Produce-Then-Stop)
 
-When self-heal hits the cap, the failure is non-code, the run id is unlocatable, or step 2 times out while pending, stop this round and summarize for the user: the blocker, the fixes attempted (including each fix commit), and the relevant failing job and run/log links (report shape in the "Help report template" of `reference/monitor-and-heal.md`). Do **not** render a next-step command; wait for the user. Then, on the task-anchored path, run steps 5/6 to record this round's outcome.
+When healing hits a cap, a check failure is non-code/unlocatable, readiness stays unknown, or rebase, tests, remote identity, or exact lease cannot close safely, stop and report the PR head/base, conflict paths, remote facts, tests, and attempts using the reference template. Do **not** render a next-step command. Then run steps 5/6 on the task-anchored path.
 
 ### 5. Update Task State
 
@@ -77,7 +77,7 @@ Update `.agents/workspace/active/{task-id}/task.md`:
 - **Do not change** `pr_status` (keep `created`) or `current_step`
 - **Append** to `## Activity Log` (do not overwrite prior entries; `{N}` = number of existing Watch PR entries for this task + 1):
   ```
-  - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Watch PR (Round {N})** by {agent} — {green: all required checks green, repair commits: {k} [{SHA summary}] / blocked: blocked: {summary}}
+  - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Watch PR (Round {N})** by {agent} — {success: PR ready, repair commits: {k} [{SHA summary}] / blocked: blocked: {summary}}
   ```
 
 ### 6. Verification Gate
@@ -104,7 +104,7 @@ Keep the gate output in your reply as the verification evidence. Without current
 > Before rendering next steps, read `.agents/rules/next-step-output.md`, invoke the shared helper only for the selected scenario, and insert its stdout at `{next-step-commands}`.
 
 Output per scenario:
-- "All green" + task-anchored: state that all required checks passed, then render exactly one exit based on whether this run created repair commits (`{task-ref}` becomes the short id):
+- `ready` + task-anchored: state that required checks passed and the current head is explicitly mergeable, then render exactly one exit based on whether this run created repair commits (`{task-ref}` becomes the short id):
 
   `repairCommits.length == 0`:
 
@@ -129,8 +129,8 @@ Populate `{next-step-commands}` for this scenario by running `agent-infra-intern
 ## Completion Checklist
 
 - [ ] Resolved the target PR (and any task context)
-- [ ] Completed required-checks watching with an all-green / blocked conclusion
-- [ ] Self-heal limited to locatable code-layer failures, with local tests passing before push and within the fix cap
+- [ ] Completed readiness watching; success requires passed checks and explicit mergeability
+- [ ] Check/rebase healing passed local tests and its safety intent within the attempt cap
 - [ ] Task-anchored path: updated task.md and appended the Watch PR Activity Log entry
 - [ ] Task-anchored path: verification gate passed
 - [ ] Rendered the selected next-step commands through the shared helper

package/templates/.agents/skills/watch-pr/SKILL.zh-CN.md

@@ -1,17 +1,17 @@
 ---
 name: watch-pr
 description: >
-  监控 PR 的 required checks 并在失败时自愈。
-  当需要监控 PR 的 required checks 并在失败时自愈时使用。
+  监控 PR readiness，并在 required checks 失败或合并冲突时自愈。
+  当需要持续监控 PR 直到门禁通过且明确可合入时使用。
 ---
 
 # 监控 Pull Request
 
-在 `create-pr` 之后持续监控 PR 的 required CI checks：全绿则引导合入，required check 失败则自动拉日志、本地修复并推送、重新轮询；达修复上限或属非代码层/不可定位失败则停止并向用户求助。平台专属命令集中在 `.agents/rules/pr-checks-commands.md`，本技能正文保持平台无关。
+在 `create-pr` 之后持续监控同一 PR head 的 required checks 与 mergeability。只有 checks 通过且平台明确可合入才进入成功出口；check 失败走既有修复，合并冲突走受限 rebase 自愈，未知或无法安全闭环时 fail-closed。
 
 ## 行为边界 / 关键规则
 
-- 仅监控 + 自愈当前 PR 的 required checks；不做与失败 check 无关的改动。
+- 仅监控 + 自愈当前 PR 的 required checks 与文本合并冲突；不扩展到审批或其他仓库规则。
 - 自愈通过 Git workflow intent 发布修复，但**发布前必须本地跑通相关测试**；修复上限与代码层分类授权不变。
 - 求助出口是「产出后停止」语义：停止本轮、输出阻塞说明、等待用户主动触发，**不**中途提问。
 - 裸数字 / `NN` / `TASK-id` 入参一律按任务短号解析（见 `.agents/rules/task-short-id.md`）；PR 号只走 `--pr <number>` / PR URL / 省略（当前分支），不复用裸数字语法。
@@ -44,21 +44,21 @@ description: >
 - 场景 C（`--pr <number>` 或 PR URL）：直接取该 PR 号为 `{pr#}`；随后按「反查任务」确定 `{task-id}`。
 - 反查任务（场景 A / C）：通过任务上下文/任务查询取得与 `{pr#}` 唯一绑定的 active task。未命中时停止并提示先绑定 PR；typed checks intent 不建立第二套无任务状态机。
 
-### 2. 监控 required checks
+### 2. 监控 PR readiness
 
 执行此步骤前，先读取 `reference/monitor-and-heal.md` 与 `.agents/rules/pr-checks-commands.md`。
 
-进入本轮时初始化内存列表 `repairCommits=[]`。调用 `agent-infra-internal platform-checks watch {task-id} --interval-seconds 30 --deadline-seconds 1800`，按结构化 `checks.state` 分为「全绿」/「失败」/「挂起」，分别进入步骤 7、步骤 3 或步骤 4。
+进入本轮时初始化 `repairCommits=[]` 与 `rebaseAttempts=0`。调用 `agent-infra-internal platform-checks watch {task-id} --interval-seconds 30 --deadline-seconds 1800`，只按结构化 `readiness.state` 分流：`ready` 进入步骤 7，`conflicting` 或 `checks-failed` 进入步骤 3，`pending|timed-out|cancelled` 进入步骤 4。
 
-### 3. 失败自愈循环
+### 3. 自愈循环
 
 执行此步骤前，先读取 `reference/monitor-and-heal.md` 的「自愈决策树」与 `.agents/rules/pr-checks-commands.md` 的「解析失败 run id 并拉日志」。
 
-只对可定位代码层失败最小修复并测试；通过后依次调用 `git-workflow commit` 与 `git-workflow push`，仅记录远端复核成功的 SHA。达硬上限或 run 不可定位时转步骤 4。
+`checks-failed` 只对可定位代码层失败做最小修复和测试，再用既有 commit/push intent 发布。`conflicting` 严格执行 reference 的同仓库、干净工作树、head/base 身份、rebase、完整测试与 `git-workflow push-rebased` 精确 lease 流程；上限 2 次。仅记录远端复核成功的 SHA，随后重新监控新 head；任一安全检查失败转步骤 4。
 
 ### 4. 求助出口（产出后停止）
 
-当自愈达上限、失败属非代码层、run id 不可定位、或步骤 2 挂起超时时，停止本轮并向用户汇总：阻塞原因、已尝试的修复（含每次修复 commit）、相关失败 job 与 run/log 链接（报告结构见 `reference/monitor-and-heal.md` 的「求助报告模板」）。**不**渲染下一步命令，等待用户裁定。随后在任务锚定路径下执行步骤 5/6 记录本轮结果。
+当自愈达上限、失败属非代码层、run id 不可定位、readiness 未知/超时，或 rebase、测试、远端身份、精确 lease 任一无法闭环时，停止本轮并按 reference 汇总 PR head/base、冲突文件、远端事实、测试与尝试记录。**不**渲染下一步命令。随后在任务锚定路径下执行步骤 5/6。
 
 ### 5. 更新任务状态
 
@@ -77,7 +77,7 @@ date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
 - **不改** `pr_status`（保持 `created`）与 `current_step`
 - **追加**到 `## 活动日志`（不要覆盖之前的记录；`{N}` = 本任务已有 Watch PR 条目数 + 1）：
   ```
-  - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Watch PR (Round {N})** by {agent} — {全绿：all required checks green, repair commits: {k} [{sha 摘要}] / 阻塞：blocked: {简述}}
+  - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Watch PR (Round {N})** by {agent} — {成功：PR ready, repair commits: {k} [{sha 摘要}] / 阻塞：blocked: {简述}}
   ```
 
 ### 6. 完成校验
@@ -104,7 +104,7 @@ agent-infra-internal task-verify {task-id} watch-pr.completed --format text
 > 渲染下一步前先读取 `.agents/rules/next-step-output.md`，仅为已选场景调用统一 helper，并将 stdout 填入 `{next-step-commands}`。
 
 按场景输出：
-- 「全绿」+ 任务锚定：说明所有 required checks 已通过，并只按本轮是否产生修复 commit 渲染一个出口（`{task-ref}` 替换为短号）：
+- `ready` + 任务锚定：说明 required checks 已通过且当前 head 明确可合入，并只按本轮是否产生修复 commit 渲染一个出口（`{task-ref}` 替换为短号）：
 
   `repairCommits.length == 0`：
 
@@ -129,8 +129,8 @@ agent-infra-internal task-verify {task-id} watch-pr.completed --format text
 ## 完成检查清单
 
 - [ ] 解析出目标 PR（及可能的任务上下文）
-- [ ] 完成 required checks 监控，得到全绿 / 阻塞结论
-- [ ] 自愈仅限可定位的代码层失败，且推送前本地测试通过、未超修复上限
+- [ ] 完成 readiness 监控，只有 checks 通过且明确可合入才得到成功结论
+- [ ] check / rebase 自愈均通过本地测试和对应安全 intent，且未超修复上限
 - [ ] 任务锚定路径：更新了 task.md 并追加 Watch PR 的 Activity Log
 - [ ] 任务锚定路径：完成校验通过
 - [ ] 已通过统一 helper 渲染已选场景的下一步命令

package/templates/.agents/skills/watch-pr/reference/monitor-and-heal.en.md

@@ -2,13 +2,14 @@
 
 Platform-agnostic decision logic for `watch-pr` steps 2/3/4. The concrete platform commands (watch, resolve a failing run, pull logs, read the PR number) live in `.agents/rules/pr-checks-commands.md`; this file only describes platform-independent classification and decisions.
 
-## Outcome Classification
+## Readiness Classification
 
-After running the watch command from `.agents/rules/pr-checks-commands.md`, classify by its exit code into three buckets:
+After the watch command, route by structured `readiness.state`:
 
-- All required checks passed → "all green" (SKILL step 7 green exit).
-- At least one failed / errored → "failure" (SKILL step 3 self-heal).
-- Still pending or the overall time cap was reached → "pending" (SKILL step 4 help exit).
+- `ready`: required checks passed and the same head is explicitly mergeable → SKILL step 7.
+- `checks-failed`: a required check failed or was cancelled → CI healing in SKILL step 3.
+- `conflicting`: the platform explicitly reports a head/base conflict → rebase healing in SKILL step 3.
+- `pending|timed-out|cancelled`: no reliable success fact exists → SKILL step 4.
 
 ## Self-Heal Decision Tree
 
@@ -34,6 +35,23 @@ For each failing check, decide "self-heal" vs "ask for help" in this order:
    - Append the fix commit SHA to this run's `repairCommits`, increment the fix count, and return to SKILL step 2. When checks turn green, an empty list routes to `complete-task`; a non-empty list routes to `review-code`.
    - Never make unrelated "drive-by" optimizations; never loosen / skip the failing assertion to "make it green".
 
+## Merge-Conflict Healing
+
+```text
+# conflict-heal-contract
+strategy: rebase
+remote-update: exact-lease
+unsafe: help
+```
+
+1. Continue only when the PR, head, and base repositories match; the current branch equals the head ref; local HEAD equals the snapshot head SHA; and the worktree/index are clean.
+2. Select a remote that exactly matches the PR repository, fetch the base ref, record the full `expectedBaseHead`, and confirm the remote head still equals the full old SHA.
+3. Run `git rebase <expectedBaseHead>`. Handle only Git-reported text unmerged paths. If resolution is unsafe, run `git rebase --abort`, record paths and both SHAs, and use help.
+4. After rebase, run the project `test` skill's full validation. Never push a failing result.
+5. Write remote, branch, full `expectedOldHead`, `newHead`, baseBranch, and full `expectedBaseHead` to a temporary intent outside the repository; call `agent-infra-internal git-workflow push-rebased --input {intent.json}`.
+6. Core verifies clean state, branch/HEAD, remote head/base, ancestry, exact `--force-with-lease`, and the post-push SHA. Never fall back to generic force; refresh the PR snapshot or use help.
+7. On success, append the new SHA to `repairCommits`, increment `rebaseAttempts`, and watch the new head. Cap at two attempts; a final ready state with repairs routes only to `review-code`.
+
 ## Help Report Template
 
 When entering the help exit, output the following fixed structure to the user (not written to any artifact file):
@@ -41,7 +59,10 @@ When entering the help exit, output the following fixed structure to the user (n
 ```
 PR #{pr#} monitoring is blocked; manual intervention needed.
 
-Blocker: {non-code layer / fix cap reached / run unlocatable / poll timeout}
+Blocker: {non-code layer / cap reached / run unlocatable / readiness unknown / unsafe rebase or update}
+PR head/base: {repository/ref/SHA}
+Conflict and remote facts: {paths / expected and actual head/base / rebase abort state}
+Validation: {command and failure summary, or why it did not run}
 Failing check: {name} (workflow: {workflow})
 Failing run / logs: {run/job link}
 Fixes attempted ({k} total):

package/templates/.agents/skills/watch-pr/reference/monitor-and-heal.zh-CN.md

@@ -2,13 +2,14 @@
 
 `watch-pr` 步骤 2/3/4 的平台无关判定逻辑。具体平台命令（监控、解析失败 run、拉日志、读取 PR 号）见 `.agents/rules/pr-checks-commands.md`；本文件只描述与平台无关的分类与决策。
 
-## 结果分类
+## Readiness 分类
 
 按 `.agents/rules/pr-checks-commands.md` 的监控命令执行后，依其退出码归为三类：
 
-- 全部 required checks 通过 → 「全绿」（SKILL 步骤 7 全绿出口）。
-- 至少一个失败 / 出错 → 「失败」（SKILL 步骤 3 自愈）。
-- 仍有 pending 或达到总时长上限 → 「挂起」（SKILL 步骤 4 求助）。
+- `ready`：同一 head 的 required checks 通过且平台明确可合入 → SKILL 步骤 7。
+- `checks-failed`：至少一个 required check 失败或取消 → SKILL 步骤 3 的 CI 自愈。
+- `conflicting`：平台明确当前 head 与 base 冲突 → SKILL 步骤 3 的 rebase 自愈。
+- `pending|timed-out|cancelled`：mergeability/checks 未形成可靠成功事实 → SKILL 步骤 4。
 
 ## 自愈决策树
 
@@ -34,6 +35,23 @@ unknown: help
    - 将本次修复的 commit SHA 追加到当前运行的 `repairCommits`，修复计数 +1，回到 SKILL 步骤 2 重新监控；全绿时列表为空走 `complete-task`，非空走 `review-code`。
    - 绝不执行与失败无关的「顺手优化」；不放宽 / 跳过失败的断言来「修绿」。
 
+## 合并冲突自愈
+
+```text
+# conflict-heal-contract
+strategy: rebase
+remote-update: exact-lease
+unsafe: help
+```
+
+1. 仅当 PR、head 与 base repository 完全相同，当前分支等于 head ref，本地 HEAD 等于快照 head SHA，且工作树/暂存区干净时继续；否则求助。
+2. 找到与 PR repository 精确匹配的 remote，抓取 base ref，记录完整 `expectedBaseHead`，并确认远端 head 仍等于完整旧 SHA。
+3. 执行 `git rebase <expectedBaseHead>`。只处理 Git 报告的文本 unmerged paths；无法可靠解决时 `git rebase --abort`，记录冲突路径和双方 SHA 后求助。
+4. rebase 完成后运行项目 `test` skill 的完整验证。失败时不推送。
+5. 把 remote、branch、完整 `expectedOldHead`、`newHead`、baseBranch 和完整 `expectedBaseHead` 写入仓库外的临时 intent JSON，调用 `agent-infra-internal git-workflow push-rebased --input {intent.json}`。
+6. core 会复核干净状态、分支/HEAD、远端 head/base、ancestor、精确 `--force-with-lease` 与推送后远端 SHA。任一失败不得改用普通 force；重新取 PR 快照或求助。
+7. 推送成功后把新 SHA 加入 `repairCommits`，`rebaseAttempts += 1`，重新监控新 head。上限 2 次；最终 ready 且列表非空时只进入 `review-code` 出口。
+
 ## 求助报告模板
 
 进入求助出口时，向用户输出以下固定结构（不写入产物文件）：
@@ -41,7 +59,10 @@ unknown: help
 ```
 PR #{pr#} 监控阻塞，需人工介入。
 
-阻塞原因：{非代码层 / 达修复上限 / run 不可定位 / 轮询超时}
+阻塞原因：{非代码层 / 达修复上限 / run 不可定位 / readiness 未知 / rebase 或安全更新失败}
+PR head/base：{repository/ref/SHA}
+冲突与远端事实：{conflict paths / expected 与 actual head/base / rebase abort 状态}
+验证：{命令与失败摘要；未运行则说明原因}
 失败 check：{name}（workflow：{workflow}）
 失败 run / 日志：{run/job 链接}
 已尝试的修复（共 {k} 次）：

package/templates/.agents/templates/task.en.md

@@ -12,7 +12,7 @@ effort:                         # Optional Issue field: High | Medium | Low
 start_date:                     # Optional Issue field for Feature: YYYY-MM-DD
 target_date:                    # Optional Issue field for Feature: YYYY-MM-DD
 current_step: requirement-analysis # requirement-analysis | requirement-analysis-review | technical-design | technical-design-review | code | code-review | completed
-assigned_to:                   # claude | codex | gemini | opencode | human
+assigned_to:                   # claude | codex | antigravity | opencode | human
 pr_status: pending             # PR status: pending (default) | created (PR created) | skipped (explicitly skipped)
 ---
 

package/templates/.agents/templates/task.zh-CN.md

@@ -12,7 +12,7 @@ effort:                         # 可选 Issue 字段：High | Medium | Low
 start_date:                     # Feature 可选 Issue 字段：YYYY-MM-DD
 target_date:                    # Feature 可选 Issue 字段：YYYY-MM-DD
 current_step: requirement-analysis # requirement-analysis | requirement-analysis-review | technical-design | technical-design-review | code | code-review | completed
-assigned_to:                   # claude | codex | gemini | opencode | human
+assigned_to:                   # claude | codex | antigravity | opencode | human
 pr_status: pending             # PR 状态：pending（默认）| created（已创建 PR）| skipped（显式跳过）
 ---
 

package/templates/.agents/workflows/bug-fix.en.yaml

@@ -14,7 +14,7 @@ steps:
     description: Reproduce the defect, identify the root cause, and define the fix scope.
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - Understand the defect report and expected behavior
       - Reproduce the defect when possible
@@ -39,7 +39,7 @@ steps:
     description: Review whether the defect analysis has sufficient reproduction evidence, a clear root cause, and a scoped fix.
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - Verify reproduction evidence or the non-reproducible explanation
       - Check root-cause reasoning and impact scope
@@ -93,7 +93,7 @@ steps:
     description: Review whether the fix plan addresses the root cause, has sufficient tests, and controls side effects.
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - Verify the plan covers the approved root-cause analysis
       - Check regression test strategy and potential side effects

package/templates/.agents/workflows/bug-fix.zh-CN.yaml

@@ -13,7 +13,7 @@ steps:
     description: 复现缺陷，识别根本原因，确定修复范围。
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - 理解缺陷报告和预期行为
       - 复现缺陷（如果可能）
@@ -38,7 +38,7 @@ steps:
     description: 审查缺陷分析是否复现充分、根因明确且修复范围清晰。
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - 验证缺陷复现或不可复现说明
       - 检查根因推导和影响范围
@@ -92,7 +92,7 @@ steps:
     description: 审查修复方案是否覆盖根因、测试充分且副作用可控。
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - 验证方案覆盖已批准的根因分析
       - 检查回归测试策略和潜在副作用

package/templates/.agents/workflows/code-review.en.yaml

@@ -9,7 +9,7 @@ steps:
     description: Load context and understand the scope of changes.
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - Read the PR description and linked issues
       - Review the diff to understand what changed

package/templates/.agents/workflows/code-review.zh-CN.yaml

@@ -9,7 +9,7 @@ steps:
     description: 加载上下文并理解变更范围。
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - 阅读 PR 描述和关联的 Issue
       - 审查差异以理解变更内容

package/templates/.agents/workflows/feature-development.en.yaml

@@ -14,7 +14,7 @@ steps:
     description: Analyze feature requirements, explore the codebase, and identify affected areas.
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - Read and understand the feature requirements
       - Explore the codebase to identify relevant files and modules
@@ -37,7 +37,7 @@ steps:
     description: Review whether the requirement analysis is complete, verifiable, and clearly scoped.
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - Check requirement scope, constraints, and acceptance criteria
       - Verify affected areas and risk identification
@@ -63,7 +63,7 @@ steps:
     description: Create the technical design for the feature implementation.
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - Define interfaces and data structures
       - Outline the implementation approach
@@ -93,7 +93,7 @@ steps:
     description: Review whether the technical design is implementable, low-risk, and requirement-complete.
     recommended_agents:
       - claude
-      - gemini
+      - antigravity
     tasks:
       - Verify the plan covers the approved analysis
       - Check architecture fit, risks, and test strategy