@fitlab-ai/agent-infra 0.8.5 → 0.9.0

package/templates/.agents/rules/issue-sync.github.zh-CN.md

@@ -2,7 +2,7 @@
 
 ## Marker 注册表
 
-以下隐藏标记是 Issue 同步的唯一权威注册表：
+以下 key 及格式是 Issue 评论身份的兼容契约；调用方只传 key/资源，不自行拼 marker。
 
 | Key | Marker |
 |---|---|
@@ -12,312 +12,61 @@
 | `summary` | `<!-- sync-issue:{task-id}:summary -->` |
 | `cancel` | `<!-- sync-issue:{task-id}:cancel -->` |
 
-Skill 正文应引用 marker key，具体 marker 字符串只保留在本规则或平台适配器默认值中。
+`prSummary` 属于 `.agents/rules/pr-sync.md`，本规则不实现 PR 聚合。
 
-在任务技能需要更新 GitHub Issue 时先读取本文件。
+## 平台 intent
 
-## Upstream 仓库检测
-
-外部开发者在 fork 仓库中执行 `gh` 命令时，默认目标会指向 fork，而不是原始仓库。所有后续 `gh issue` 和 `gh api "repos/..."` 操作都必须先检测 upstream 仓库，并统一复用 `upstream_repo`。
-
-```bash
-upstream_repo=$(gh api "repos/$(gh repo view --json nameWithOwner -q .nameWithOwner)" \
-  --jq 'if .fork then .parent.full_name else .full_name end' 2>/dev/null)
-```
-
-- 非 fork 仓库：返回当前仓库自身的 `full_name`
-- fork 仓库：返回父仓库的 `full_name`
-- 后续所有 `gh issue` 命令统一使用 `-R "$upstream_repo"`
-- 后续所有 `gh api "repos/..."` 命令统一使用 `"repos/$upstream_repo/..."`
-
-## 权限检测
-
-所有需要写权限的操作都先对 upstream 仓库做一次权限检测。检测失败时按无权限处理，确保安全降级。
-
-```bash
-repo_perms=$(gh api "repos/$upstream_repo" --jq '.permissions' 2>/dev/null || echo '{}')
-has_triage=$(printf '%s' "$repo_perms" | grep -q '"triage":true' 2>/dev/null && echo true || echo false)
-has_push=$(printf '%s' "$repo_perms" | grep -q '"push":true' 2>/dev/null && echo true || echo false)
-```
-
-操作与权限映射：
-
-| 操作 | 所需权限 | 说明 |
-|------|---------|------|
-| 设置/移除 label | `has_triage` | triage 是最低权限 |
-| 设置/移除 milestone | `has_triage` | 同上 |
-| 编辑 Issue body | `has_triage` | 需求复选框同步使用 |
-| 设置 Issue Type | `has_push` | 需要 write 权限 |
-| 设置 Issue 字段 | `has_push` | pinned custom fields；失败不阻断 |
-| 设置 assignee | 不检测 | 无权限时直接跳过 |
-| 发布/更新评论 | 无需检测 | 公开仓库中认证用户可执行 |
-
-## 降级行为定义
-
-| 层级 | 操作类型 | 有权限 | 无权限 |
-|------|---------|--------|--------|
-| 静默降级 | label / milestone / Issue Type / Issue 字段 | 直接执行 `gh` 命令，同时更新 task 留言 | 跳过 `gh` 直接操作，仅更新 task 留言，由 bot 补位 |
-| 直接跳过 | assignee | 直接执行 `gh` 命令 | 不做任何替代 |
-| 正常执行 | 评论 | 正常执行 | 正常执行 |
-
-关键原则：
-
-- 无论是否有写权限，task 留言同步都必须继续执行
-- 权限不足只影响直接写 Issue 元数据的步骤，不中断整个技能
-- 现有 `2>/dev/null || true` 容错模式保持不变
-
-当调用方存在 `{task-id}` / task 目录时，权限降级或关键同步失败必须写入 `## 工作流告警`：
-
-```bash
-node .agents/scripts/workflow-warnings.js add .agents/workspace/active/{task-id} \
-  --step issue-sync --severity IMPORTANT --code PERMISSION_DEGRADED \
-  --target "{operation}" --message "{reason}" \
-  --action "等待 bot/维护者补位，或在具备权限后重跑对应 workflow 步骤"
-```
-
-评论创建 / 更新失败、网络重试耗尽等影响后续 reviewer 可见性的失败使用 `severity=ACTION_REQUIRED` 和 `code=COMMENT_SYNC_FAILED` 或 `NETWORK_RETRY_EXHAUSTED`。
-
-## 外部开发者锁定机制
-
-维护者（`has_triage=true`）不受限制。外部开发者（`has_triage=false`）在开始任务前，必须先检查 Issue 上是否已有当前任务的 `task` 留言作者。
-
-```bash
-task_comment_author=$(gh api "repos/$upstream_repo/issues/{issue-number}/comments" \
-  --paginate --jq '[.[] | select(.body | test("<!-- sync-issue:{task-id}:task -->")) | .user.login] | first' \
-  2>/dev/null || echo "")
-current_user=$(gh api user --jq '.login' 2>/dev/null || echo "")
-```
-
-判定规则：
-
-- 没有 `task` 留言：允许开始
-- `task` 留言作者等于当前用户：允许继续
-- `task` 留言作者不等于当前用户：立即停止，并提示先与维护者协调，避免多人同时接手同一任务
-
-## status label 设置
-
-算法说明：下面的流程与 `.github/scripts/sync-labels-to-set.sh` 保持一致（集合差集）。本章节是 AI Agent 侧的等价实现（`target_set = {"{target-status-label}"}` 的特例）。修改任一侧时，必须同步另一侧，避免 Agent 与 Bot 的行为漂移。
-
-如果 task.md 中存在有效的 `issue_number`（非空、非 `N/A`），且 Issue 状态为 `OPEN`，则按幂等差集方式将 `status:` label 同步到目标值：
+GitHub upstream、认证、capability、分页、marker 查找、幂等 create/update、分片、重试与错误分类由 typed platform core 统一处理：
 
 ```bash
-state=$(gh issue view {issue-number} -R "$upstream_repo" --json state --jq '.state' 2>/dev/null)
-if [ "$state" = "OPEN" ]; then
-  current_status_labels=$(gh issue view {issue-number} -R "$upstream_repo" \
-    --json labels --jq '.labels[].name | select(startswith("status:"))' 2>/dev/null || true)
-  printf '%s\n' "$current_status_labels" | while IFS= read -r label; do
-    [ -z "$label" ] && continue
-    if [ "$label" != "{target-status-label}" ] && [ "$has_triage" = "true" ]; then
-      gh issue edit {issue-number} -R "$upstream_repo" --remove-label "$label" 2>/dev/null || true
-    fi
-  done
-  if [ "$has_triage" = "true" ] && ! printf '%s\n' "$current_status_labels" | grep -qxF "{target-status-label}"; then
-    gh issue edit {issue-number} -R "$upstream_repo" --add-label "{target-status-label}" 2>/dev/null || true
-  fi
-fi
+agent-infra-internal platform-context resolve [--cwd <path>]
+agent-infra-internal platform-comment list --issue <N> [--cwd <path>]
+agent-infra-internal platform-comment owner <task-ref>
+agent-infra-internal platform-comment sync <task-ref> \
+  --kind task|artifact|summary|cancel --agent <agent> \
+  [--artifact <canonical.md>] [--body-file <path|->] [--backfill]
 ```
 
-使用 `while IFS= read -r label` 按行处理，可避免 `status: in-progress` 这类含空格 label 被 shell 按空格拆开。
-
-如果 `has_triage=false`，则跳过直接设置 label，只更新 task 留言，由 bot 根据最新 task 元数据补位。
-
-如果 `gh` 命令失败，跳过并继续，不中断技能执行。
-
-## Assignee 同步
-
-当技能创建或导入 Issue 时，自动将当前执行者添加为 assignee：
-
-- `create-task` 的平台规则触发 Issue 创建时：在 `gh issue create` 命令中使用 `--assignee @me` 参数，并附带 `-R "$upstream_repo"`
-- `import-issue`：导入后执行 `gh issue edit {issue-number} -R "$upstream_repo" --add-assignee @me 2>/dev/null || true`
+- `applied|no-op|degraded` → exit 0；`failed` → exit 1；`blocked` → exit 2。
+- task 评论保持 `<details>` frontmatter 可逆格式；artifact 原文内联并在超过 profile 上限时使用 `artifactChunk`。
+- 相同 intent 重放必须收敛为 `no-op`；重复 marker 返回 `COMMENT_MARKER_CONFLICT` 且不写入。
+- 外部贡献者锁定统一使用 `platform-comment owner`；不同作者且无 triage 时返回 `COMMENT_OWNER_CONFLICT`。
 
-`@me` 由 `gh` CLI 自动解析为当前认证用户。此操作是幂等的（重复添加不会报错）。如果命令失败（如权限不足），直接跳过，不做任何替代。
+## 降级与告警
 
-## `in:` label 同步
+平台结果不直接写 task.md。调用方在有关联任务时把关键失败映射为 workflow warning：
 
-> **触发时机**：`in:` label 同步应在代码提交后（commit 技能）执行，不在 code-task 阶段执行。create-pr 阶段仅从 Issue 复制到 PR，不重新计算。
+- capability 不足：`IMPORTANT / PERMISSION_DEGRADED`
+- 评论同步永久失败：`ACTION_REQUIRED / COMMENT_SYNC_FAILED`
+- 网络重试耗尽：`ACTION_REQUIRED / NETWORK_RETRY_EXHAUSTED`
 
-读取 `.agents/.airc.json` 的 `labels.in` 映射。
+使用 `agent-infra-internal task-warning {task-id} add ...` 登记；不得手写 warning 表。
 
 ```bash
-git diff {base-branch}...HEAD --name-only
+agent-infra-internal task-warning {task-id} add \
+  --step issue-sync --severity {severity} --code {code} \
+  --target {target} --message {message} --action {action}
 ```
 
-`{base-branch}` 通常为 `main`；如果在 PR 上下文中，则使用 PR 的 base branch。
+## Issue 元数据 intent
 
-### 有映射时（精确增删）
-
-1. 获取分支全部改动文件
-2. 对每个文件按目录前缀匹配 `labels.in` 中的值，得到"应有的 `in:` labels"集合
-3. 查询 Issue/PR 当前的 `in:` labels
-4. 差集比较：
-   - 应有但没有：仅当 `has_triage=true` 时执行 `gh issue edit {issue-number} -R "$upstream_repo" --add-label "in: {module}" 2>/dev/null || true`
-   - 有但不应有：仅当 `has_triage=true` 时执行 `gh issue edit {issue-number} -R "$upstream_repo" --remove-label "in: {module}" 2>/dev/null || true`
-
-### 无映射时（只增不删回退）
-
-如果 `.airc.json` 中不存在 `labels.in` 或为空对象：
-
-1. 查询仓库已有 `in:` labels
-2. 从改动文件提取第一级目录
-3. 仅当 `has_triage=true` 时添加匹配的 label，不移除已有 `in:` label
-
-如果 `has_triage=false`，则跳过直接修改 `in:` label，只保留 task 留言同步，由后续自动化补位。
-
-## 产物评论发布
-
-隐藏标记必须保持兼容：
-
-```html
-<!-- sync-issue:{task-id}:{file-stem} -->
-```
-
-发布前先检查是否已存在同标记评论：
+所有 Issue 元数据写入统一使用：
 
 ```bash
-gh api "repos/$upstream_repo/issues/{issue-number}/comments" \
-  --paginate --jq '.[].body' \
-  | grep -qF "<!-- sync-issue:{task-id}:{file-stem} -->"
+agent-infra-internal platform-issue inspect {task-id}
+agent-infra-internal platform-issue create {task-id} --agent {agent}
+agent-infra-internal platform-issue bind {task-id} --issue {number} --agent {agent}
+agent-infra-internal platform-issue sync {task-id} --agent {agent} {desired-state-flags}
 ```
 
-如果已存在则跳过。
-
-发布流程：
-
-1. 先读取本地产物文件全文
-2. 将文件全文作为 `{artifact body}` 原文内联到评论中
-3. 禁止自行组织摘要、改写或截断正文
-
-评论格式统一为：
-
-```markdown
-<!-- sync-issue:{task-id}:{file-stem} -->
-## {artifact-title}
-
-> **{agent}** · {task-id}
-
-{artifact body}
-
----
-*由 {agent} 自动生成 · 内部追踪：{task-id}*
-```
-
-其中 `{agent}` 使用当前执行该技能的 AI 代理名称（如 `claude`、`codex`、`gemini`）。
-
-`summary` 评论需要额外处理：
-
-- 先查找已有 `<!-- sync-issue:{task-id}:summary -->` 评论的 ID
-- 不存在则创建
-- 已存在且正文有变化时，使用 `gh api "repos/$upstream_repo/issues/comments/{comment-id}" -X PATCH -f body=...` 原地更新
-
-```bash
-summary_comment_id=$(gh api "repos/$upstream_repo/issues/{issue-number}/comments" \
-  --paginate --jq '.[] | select(.body | startswith("<!-- sync-issue:{task-id}:summary -->")) | .id' \
-  | head -n 1)
-gh api "repos/$upstream_repo/issues/comments/{comment-id}" -X PATCH -f body="$(cat <<'EOF'
-{comment-body}
-EOF
-)"
-```
-
-评论发布不受 `has_triage` / `has_push` 限制，认证用户可正常执行。
-
-若评论查询、创建或更新失败且调用方有关联任务目录，记录 Workflow Warning（`step=issue-sync`、`severity=ACTION_REQUIRED`、`code=COMMENT_SYNC_FAILED`、`target={file-stem}`），并在最终输出的 Workflow Warnings 块提示人工处理。
-
-## task.md 评论同步
-
-隐藏标记：
-
-```html
-<!-- sync-issue:{task-id}:task -->
-```
-
-`task.md` 使用幂等更新路径：
-
-1. 读取 `task.md` 全文
-2. 将 YAML frontmatter（`---` 到 `---` 之间的内容）包裹在 `<details><summary>元数据 (frontmatter)</summary>` 和 `` ```yaml `` 代码块中，其余正文保持原样作为 Markdown 渲染
-3. 使用 `task` 作为 `{file-stem}`
-4. 查找已有标记评论 ID
-5. 不存在则创建
-6. 已存在且正文有变化则 PATCH 原地更新
-7. 已存在且正文相同则跳过
-
-task.md 评论格式：
-
-```markdown
-<!-- sync-issue:{task-id}:task -->
-## 任务文件
-
-> **{agent}** · {task-id}
-
-<details><summary>元数据 (frontmatter)</summary>
-
-​```yaml
----
-{frontmatter fields}
----
-​```
-
-</details>
-
-{task.md body after frontmatter}
-
----
-*由 {agent} 自动生成 · 内部追踪：{task-id}*
-```
-
-还原时，从 `<details>` 块中提取 frontmatter，与正文拼合恢复为原始 `task.md`。
-
-评论标题映射：
-
-- `task` -> `任务文件`
-
-task 留言同步始终执行，不受权限降级影响。
-
-## 补发规则（`/complete-task` 归档前执行）
-
-- 扫描任务目录中的 `task.md`、`analysis*.md`、`review-analysis*.md`、`plan*.md`、`review-plan*.md`、`code*.md`、`review-code*.md`
-- 对每个 `{file-stem}` 用隐藏标记检查是否已发布；未发布则补发，已发布则跳过
-- 补发只追加缺失评论，不删除或重排已有评论
-- 补发评论的 `{agent}` 按以下顺序确定：
-  1. 从 Activity Log 中匹配对应产物文件名（如 `→ analysis.md`），提取 `by {agent}` 中的执行者
-  2. 若未匹配到，则回退到 task.md frontmatter 的 `assigned_to`
-  3. 若 `assigned_to` 也不可用，则使用当前执行补发的 agent
-- 位置说明从 Activity Log 推导时间线中的前后邻居，并加在评论标题下方：
-
-```markdown
-> ⚠️ 本评论为补发产物，按时间线应位于「{前一个产物标题}」之后、「{后一个产物标题}」之前。
-```
-
-- 如果只有前邻居或后邻居，仅保留存在的一侧说明；如果两侧都不存在，则不添加位置说明
-
-标题映射：
-
-- `task` -> `任务文件`
-- `analysis` / `analysis-r{N}` -> `需求分析` / `需求分析（Round {N}）`
-- `review-analysis` / `review-analysis-r{N}` -> `需求分析审查（Round 1）` / `需求分析审查（Round {N}）`
-- `plan` / `plan-r{N}` -> `技术方案` / `技术方案（Round {N}）`
-- `review-plan` / `review-plan-r{N}` -> `技术方案审查（Round 1）` / `技术方案审查（Round {N}）`
-- `code` / `code-r{N}` -> `实现报告（Round 1）` / `实现报告（Round {N}）`
-- `review-code` / `review-code-r{N}` -> `代码审查（Round 1）` / `代码审查（Round {N}）`
-- `summary` -> `交付摘要`
-
-补发评论同样不受 `has_triage` / `has_push` 限制。
-
-## 需求复选框同步
-
-从 task.md 的 `## 需求` 段落提取已勾选的 `- [x]` 条目；如果没有，跳过。
-
-读取 Issue 当前正文：
-
-```bash
-gh issue view {issue-number} -R "$upstream_repo" --json body --jq '.body'
-```
+`sync` 支持 status/in labels、assignee、milestone、Issue Type、pinned fields、需求复选框与 Issue state。省略 flag 表示 preserve，`none` 表示显式清空。适配层统一处理集合差集、动态 schema、权限降级、dry-run、重试、错误分类与幂等重放；SKILL 不得拼装 `gh issue`、GraphQL 或权限分支。
 
-按复选框文本匹配，将对应的 `- [ ] {text}` 单向替换为 `- [x] {text}`。只有正文实际变化且 `has_triage=true` 时，才使用 `gh api` PATCH 更新完整 body。
+- `planned|applied|no-op|degraded` → exit 0
+- `failed` → exit 1
+- `blocked` → exit 2
 
-如果 `has_triage=false`，则跳过正文 PATCH，只更新 task 留言，由 bot 根据最新任务状态补位。
+status labels 始终至多一个；关闭后不保留 status label。`in:` labels 只从项目允许映射与仓库实际 labels 交集产生。需求复选框以 task.md 原文为身份，歧义时 fail closed。
 
-## Shell 安全规则
+## 补发
 
-1. 先用 Read 工具读取产物全文，再把实际文本内联到 heredoc 中；禁止在 `<<'EOF'` 内使用命令替换或变量展开。
-2. 构造含 `<!-- -->` 的内容时禁止使用 `echo`；统一使用 `cat <<'EOF'` heredoc 或 `printf '%s\n'`。
+complete-task 按 artifact catalog 时间线遍历本地已有产物：task 使用 `--kind task`，其余使用 `--kind artifact --artifact <file> --backfill`；最后用 `--kind summary --body-file <path>` 原地同步交付摘要。artifact backfill 在远端缺少 marker 时创建带“历史产物补发”提示的评论；已存在合法 marker 集合时保持原评论和分片不变并返回 `no-op`；marker 冲突仍失败。该判定由 core 完成，不由 Skill 扫描评论或拼标题。

package/templates/.agents/rules/issue-sync.zh-CN.md

@@ -14,6 +14,6 @@
 
 Skill 正文应引用 marker key，具体 marker 字符串只保留在本规则或平台适配器默认值中。
 
-当前代码平台未内置 Issue 同步支持。
+当前代码平台未提供 Issue 适配器；`platform-issue` 返回结构化 no-op/degraded operations。
 
 自定义平台会跳过 Issue 元数据、标签、里程碑、负责人和评论同步，除非你提供匹配的 `.{platform}.zh-CN.md` 规则模板和平台适配器。请继续正常写入本地任务产物。

package/templates/.agents/rules/milestone-inference.en.md

@@ -1,5 +1,5 @@
 # Milestone Inference
 
-This code platform does not provide built-in milestone inference.
+This code platform does not provide milestone inference; `platform-issue sync --milestone ...` returns a structured no-op/degraded result.
 
 Milestone narrowing and reuse are skipped for custom platforms unless you provide matching `.{platform}.en.md` rule templates. Do not block task progress when no platform-specific milestone implementation is available.

package/templates/.agents/rules/milestone-inference.github.en.md

@@ -1,125 +1,13 @@
-# Milestone Inference Rules
+# Milestone Inference
 
-Read this file before the `create-task` platform rule, `code-task`, or `create-pr` handles a milestone.
-
-## General Principles
-
-- Narrow the milestone over the skill lifecycle: release line -> concrete version -> reuse
-- Every phase must fall back safely instead of blocking the skill
-- If `gh` is unavailable, unauthenticated, or the GitHub API call fails, skip milestone handling and continue
-- Before any repository-scoped `gh api`, `gh issue edit`, or Issue lookup runs, the caller must resolve `upstream_repo` and `has_triage`
-- Only use milestones that actually exist in the repository; if a target milestone is unavailable, apply the fallback for that phase
-
-## Branch Mode Detection
-
-Use the following command to detect whether the repository has remote release-line branches:
-
-```bash
-git branch -r | grep -v 'HEAD' | grep -E 'origin/[0-9]+\.[0-9]+\.x$'
-```
-
-- Any output: multi-version branch mode
-- No output: trunk mode
-
-## Phase 1: `create-task` (when the platform rule creates an Issue)
-
-Goal: choose a coarse-grained release line when the Issue is created.
-
-Priority:
-1. If task.md provides a valid explicit `milestone`, use it
-2. Otherwise infer a release line:
-   - Trunk mode: query open `X.Y.x` milestones and choose the lowest release line
-   - Multi-version branch mode: try open `X.Y.x` milestones and choose the lowest release line; if that is not reliable, fall back to `General Backlog`
-3. If the inferred release line does not exist, fall back to `General Backlog`
-4. If `General Backlog` also does not exist, omit `--milestone`
-
-Suggested release-line query:
-
-```bash
-gh api "repos/$upstream_repo/milestones?state=open&per_page=100" \
-  --jq '.[].title'
-```
-
-Only match titles in `X.Y.x` format and choose the smallest major/minor pair numerically.
-
-Direct milestone writes are triage-gated. When the caller detected `has_triage=false`, omit `--milestone` and continue.
-
-### Backfill when called from `import-issue`
-
-When `import-issue` imports an existing Issue whose current milestone is empty, infer a release line using the priority above, including the `General Backlog` fallback. When a non-empty release line is found, write it back to the remote Issue:
-
-```bash
-if [ "$has_triage" = "true" ]; then
-  gh issue edit {issue-number} -R "$upstream_repo" --milestone "{version}" 2>/dev/null || true
-fi
-```
-
-If `has_triage=false`, inference returns empty, or `gh issue edit` fails, skip and continue without blocking the `import-issue` workflow.
-
-## Phase 2: `code-task`
-
-Goal: narrow the Issue milestone from a release line to a concrete version when implementation starts.
-
-Preconditions:
-- task.md contains a valid `issue_number`
-- the current Issue milestone matches the release-line format `X.Y.x` or is `General Backlog`
-
-Sequence:
-1. Query the current Issue milestone
-2. If it is `General Backlog`, re-infer the release line using Phase 1, then try to narrow it to a concrete version; if inference fails, keep `General Backlog` unchanged
-3. If it is not in `X.Y.x` format, treat it as already specific enough and keep it unchanged
-4. If it is in `X.Y.x` format, narrow it according to branch mode:
-   - Trunk mode: query open concrete-version milestones on that release line (for example `0.4.4`) and choose the latest one
-   - Multi-version branch mode:
-     - If the task branch was created from `origin/X.Y.x`, choose the latest concrete version on that line
-     - If the task branch was created from `main`, find the highest release line and choose the latest concrete version on that line
-5. When a target concrete version is found, run:
-
-```bash
-if [ "$has_triage" = "true" ]; then
-  gh issue edit {issue-number} -R "$upstream_repo" --milestone "{version}"
-fi
-```
-
-6. Keep the original milestone unchanged only in the following cases (otherwise narrow per step 5):
-   - Trunk mode with no open concrete version under the release line — the `code-task` / `create-pr` `verify_milestone_specific` gate will fail and prompt maintainers to create the missing concrete version
-   - Multi-release-line mode when both `git merge-base --is-ancestor` checks are unreliable or the remote refs are missing
-   - In any mode, `has_triage=false` (the bot will reconcile later)
-
-Suggested concrete-version query:
-
-```bash
-gh api "repos/$upstream_repo/milestones?state=open&per_page=100" \
-  --jq '.[].title'
-```
-
-- Release-line match: `^X\.Y\.x$`
-- Concrete-version match: `^X\.Y\.[0-9]+$`
-- "Latest" means the largest patch number
-
-Suggested branch-origin checks:
+Milestones narrow through declarative Issue intents:
 
 ```bash
-git merge-base --is-ancestor origin/{release-line} HEAD
-git merge-base --is-ancestor origin/main HEAD
-```
-
-If neither check is reliable or the remote refs are unavailable, keep the original milestone and avoid guessing.
+# create/import phase
+agent-infra-internal platform-issue sync {task-id} --agent {agent} --milestone initial
 
-## Phase 3: `create-pr`
-
-Goal: reuse the linked Issue milestone on the PR instead of inferring a new one.
-
-Sequence:
-1. If `issue_number` exists, query the Issue milestone
-2. If the Issue has a milestone, run:
-
-```bash
-if [ "$has_triage" = "true" ]; then
-  gh pr edit {pr-number} --milestone "{milestone}"
-fi
+# code phase
+agent-infra-internal platform-issue sync {task-id} --agent {agent} --milestone specific
 ```
 
-3. If the Issue has no milestone, or `has_triage=false`, skip PR milestone assignment
-
-Do not infer a PR milestone separately from task.md, branch names, tags, or `General Backlog`.
+`initial` prefers a valid task milestone, otherwise the lowest open `X.Y.x`, then `General Backlog`. `specific` narrows a release line to the highest open patch version using main/release-line ancestry. Missing facts or triage permission preserve the remote value and return skipped/degraded. `create-pr` reuses the Issue milestone in the 09/10 PR adapter.

package/templates/.agents/rules/milestone-inference.github.zh-CN.md

@@ -1,125 +1,25 @@
 # Milestone 推断规则
 
-在 `create-task` 的平台规则、`code-task` 或 `create-pr` 处理 milestone 之前先读取本文件。
+Milestone 继续按生命周期逐步收窄，但候选读取、分支判断、权限降级和写入统一由 `platform-issue` 处理。
 
-## 通用原则
-
-- milestone 在技能生命周期中逐步收窄：版本线 -> 具体版本 -> 复用
-- 任一步骤推断失败时都必须回退，不得阻塞技能执行
-- 如果 `gh` CLI 不可用、未认证，或 GitHub API 请求失败，跳过 milestone 处理并继续
-- 在执行 repo 级 `gh api`、`gh issue edit` 或 Issue 查询前，调用方必须先完成 `upstream_repo` / `has_triage` 检测
-- 只使用仓库中实际存在的 milestone；目标 milestone 不存在时按各阶段 fallback 处理
-
-## 分支模式检测
-
-使用以下命令检测仓库是否存在远程 release line 分支：
-
-```bash
-git branch -r | grep -v 'HEAD' | grep -E 'origin/[0-9]+\.[0-9]+\.x$'
-```
-
-- 有输出：多版本分支模式
-- 无输出：主干模式
-
-## 阶段 1：`create-task`（平台规则创建 Issue 时）
-
-目标：在创建 Issue 时先确定粗粒度版本线。
-
-优先级：
-1. `task.md` 显式存在 `milestone` 字段且值有效 -> 直接使用
-2. 否则推断版本线：
-   - 主干模式：查询 open 的 `X.Y.x` 里程碑，取最低版本线
-   - 多版本分支模式：优先查询 open 的 `X.Y.x` 里程碑，取最低版本线；如果无法确定则回退到 `General Backlog`
-3. 推断出的版本线不存在 -> 回退到 `General Backlog`
-4. `General Backlog` 也不存在 -> 省略 `--milestone`
-
-版本线查询建议：
-
-```bash
-gh api "repos/$upstream_repo/milestones?state=open&per_page=100" \
-  --jq '.[].title'
-```
-
-只匹配 `X.Y.x` 格式的标题；按 major、minor 数值升序取最小版本线。
-
-Milestone 设置属于 `has_triage` 权限范围；如果调用方检测到 `has_triage=false`，则省略 `--milestone` 并继续。
-
-### `import-issue` 调用时的兜底
-
-`import-issue` 导入既有 Issue 时，若 Issue 当前 milestone 为空，按上述优先级推断版本线（含 `General Backlog` 回退）。命中非空版本线后，回写到远端 Issue：
+## 阶段 1：创建或导入
 
 ```bash
-if [ "$has_triage" = "true" ]; then
-  gh issue edit {issue-number} -R "$upstream_repo" --milestone "{version}" 2>/dev/null || true
-fi
+agent-infra-internal platform-issue sync {task-id} --agent {agent} --milestone initial
 ```
 
-如果 `has_triage=false`、推断结果为空、或 `gh issue edit` 失败，跳过并继续，不阻断 `import-issue` 工作流。
+优先使用 task.md 中存在且有效的显式 milestone；否则从 open milestones 选择最低 `X.Y.x` 版本线，最后回退 `General Backlog`。`triage=false` 或外部事实不足时保持远端值并返回 skipped/degraded。
 
 ## 阶段 2：`code-task`
 
-目标：开始开发时，把 Issue milestone 从版本线收窄到具体版本。
-
-前置条件：
-- `task.md` 存在有效 `issue_number`
-- 当前 Issue milestone 为版本线格式 `X.Y.x` 或 `General Backlog`
-
-执行顺序：
-1. 查询 Issue 当前 milestone
-2. 如果 milestone 是 `General Backlog` -> 按阶段 1 规则重新推断版本线，再尝试收窄到具体版本；如果推断失败则保持 `General Backlog` 不变
-3. 如果 milestone 不是 `X.Y.x` 格式 -> 视为已足够具体，保持不变
-4. 如果 milestone 是 `X.Y.x` -> 按分支模式收窄：
-   - 主干模式：查询该版本线下 open 的具体版本 milestone（如 `0.4.4`），取最新版本
-   - 多版本分支模式：
-     - 当前任务分支来自 `origin/X.Y.x` release line -> 在该版本线下取最新具体版本
-     - 当前任务分支来自 `main` -> 找最高版本线，再取该版本线下的最新具体版本
-5. 找到目标具体版本后，执行：
-
-```bash
-if [ "$has_triage" = "true" ]; then
-  gh issue edit {issue-number} -R "$upstream_repo" --milestone "{version}"
-fi
-```
-
-6. 仅在以下情况保持原 milestone 不变（其余情形必须按步骤 5 收窄）：
-   - 主干模式下版本线下没有 open 具体版本 —— `code-task` / `create-pr` 的 `verify_milestone_specific` gate 会 FAIL，提醒维护者补建具体版本
-   - 多版本分支模式下 `git merge-base --is-ancestor` 两条判断都不可靠或远程引用缺失
-   - 任意模式下 `has_triage=false`（由 bot 后补）
-
-具体版本查询建议：
-
-```bash
-gh api "repos/$upstream_repo/milestones?state=open&per_page=100" \
-  --jq '.[].title'
-```
-
-- 版本线匹配：`^X\.Y\.x$`
-- 具体版本匹配：`^X\.Y\.[0-9]+$`
-- “最新”按 patch 数值最大确定
-
-分支来源判断建议：
-
 ```bash
-git merge-base --is-ancestor origin/{release-line} HEAD
-git merge-base --is-ancestor origin/main HEAD
+agent-infra-internal platform-issue sync {task-id} --agent {agent} --milestone specific
 ```
 
-如果两个判断都不可靠或远程引用缺失，保持原 milestone，不做错误推断。
+版本线收窄规则保持不变：主干模式在当前版本线取最高 patch；多版本分支模式依据 release-line/main 祖先关系选择版本线。无法可靠判断时保持原值。完成门禁仍拒绝 `X.Y.x`。
 
 ## 阶段 3：`create-pr`
 
-目标：PR 直接复用关联 Issue 的 milestone，不再独立推断。
-
-执行顺序：
-1. 如果存在 `issue_number`，查询 Issue milestone
-2. Issue 有 milestone -> 执行：
-
-```bash
-if [ "$has_triage" = "true" ]; then
-  gh pr edit {pr-number} --milestone "{milestone}"
-fi
-```
-
-3. Issue 没有 milestone，或 `has_triage=false` -> 跳过，不设置 PR milestone
+PR 只复用关联 Issue 的具体 milestone；该 PR 资源写入属于 09/10，不在 `platform-issue` 中实现。
 
-不要再使用 `task.md`、分支名、tag 或 `General Backlog` 为 PR 单独推断 milestone。
+调用方不得重新实现 milestone 列表、排序、分支祖先或 `gh issue edit` 逻辑。

package/templates/.agents/rules/milestone-inference.zh-CN.md

@@ -1,5 +1,5 @@
 # Milestone 推断
 
-当前代码平台未内置里程碑推断支持。
+当前代码平台未提供里程碑推断；`platform-issue sync --milestone ...` 返回结构化 no-op/degraded 结果。
 
 自定义平台会跳过里程碑收窄和复用逻辑，除非你提供匹配的 `.{platform}.zh-CN.md` 规则模板。没有平台专属里程碑实现时，不要阻塞任务推进。