twg-jira-resolve-merged-work

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

twg-jira-resolve-merged-work

Resolve stale Jira workitems only when merged PR evidence is strong. Plan first; mutate only after approval.

Use exact command grammar from live

twg help

twg help describe <path>

; do not guess board, sprint, transition, workspace, repo, PR, or field syntax.

仅当已合并PR的证据充分时，才处理Jira中的过时工作项。先制定计划；仅在获得批准后再执行变更。

使用实时

twg help

twg help describe <path>

中的准确命令语法；请勿猜测看板、迭代、状态转换、工作区、代码仓库、PR或字段的语法。

CLI launcher fallback

CLI启动器备选方案

Run

twg <command>

. On shell

command not found

, use

$HOME/.local/bin/twg

(macOS/Linux) /

$env:LOCALAPPDATA\Programs\twg\bin\twg.exe

(PowerShell), then tell user to add that directory to PATH. Do not treat auth or command errors as PATH failures.

运行

twg <command>

。如果shell提示

command not found

，请使用

$HOME/.local/bin/twg

（macOS/Linux系统）或

$env:LOCALAPPDATA\Programs\twg\bin\twg.exe

（PowerShell），然后告知用户将该目录添加到PATH环境变量中。请勿将认证或命令错误视为PATH配置问题。

Scope

适用范围

Accept one Jira scope:

One Jira workitem key/URL.
A small explicit list of Jira workitem keys/URLs.
Board or sprint ID/URL.
Epic key.
Jira space/project key.

Default to dry run. Ask before mutating unless the user requests reviewed execution. Use a bounded window; otherwise inspect recent active/completed sprint work and nearby PR merge dates.

支持以下任一Jira范围：

单个Jira工作项密钥/URL。
明确指定的少量Jira工作项密钥/URL列表。
看板或迭代ID/URL。
史诗密钥。
Jira空间/项目密钥。

默认启用试运行模式。除非用户要求执行已审核的操作，否则在执行变更前需先询问用户。使用时间窗口限制范围；否则将检查近期活跃/已完成的迭代工作以及临近的PR合并日期。

Workflow

工作流程

Load Jira candidates.
- Single/list: hydrate each provided workitem directly.
- Sprint:
```
jira sprint workitems query
```
  .
- Board: board/backlog/sprint commands advertised by live help.
- Epic or space: JQL-backed
```
jira workitem query
```
  .
- Hydrate key, title, status/category, assignee, updated time, parent, subtasks/blockers, and URL.
Split the set.
- Candidates are not done/resolved. Peers are done in the same board, sprint, epic, or space.
- Exclude epics/parents. Skip unresolved blockers or incomplete subtasks unless the user explicitly allows them.
Discover shared repo context set-wise.
- Even for one item or a short list, infer context for the set together.
- Extract repos/workspaces from linked PRs, commits, branches, project links, Compass/components, context queries, and resolved peers.
- Use completed peers to infer common repos, assignees, Jira-key title/branch conventions, PR links, and merge-to-transition lag.
Check optional discovery signals.
- If
```
rovo list-apps
```
  shows Bitbucket or GitHub connected, use Rovo search for keys, titles, PR URLs, branches, and repos. Treat it as discovery until hydrated through TWG/provider/Jira evidence.
- If
```
search-code
```
  is available, search exact keys first, then distinctive title terms in discovered repos. Strong hits are branch names, commit text, changed files, or symbols; broad fuzzy hits stay weak.
Expand likely implementers.
- Prefer assignees from completed peer items and candidates. Treat reporters and commenters as weak hints.
- Query merged PRs authored by these assignees in the window, scoped by discovered repos first; if unknown, infer repos from author/date results.
Search merged PRs in batches.
- Prefer one merged-PR query per repo/window, then match locally across all candidate keys. One PR may satisfy multiple exact keys.
- Match exact keys in PR title, description, branch, commits, and linked issue metadata.
- Fall back to per-workitem lookup only for no evidence, priority items, or ambiguity.
Score confidence.
- High: exact key in merged PR or linked PR metadata, plausible timing, no open same-key PR, no blockers/subtasks, and target transition exists.
- Medium: same assignee/repo with strong title similarity, or exact key only in commit/search-code evidence.
- Low: fuzzy similarity, same author only, unknown repo, or ambiguity.
Produce the dry-run plan.
- Table columns: workitem key/title, current status, proposed transition, confidence, brief rationale, PR title/URL, merge date, last Jira update, link/repo proposal, PR title-fix proposal, skipped reason, and verification.
- Include exact commands only after live-help verification. Never present low-confidence rows as executable.

加载Jira候选工作项。
- 单个/列表：直接加载每个提供的工作项的详细信息。
- 迭代：执行
```
jira sprint workitems query
```
  命令。
- 看板：使用实时帮助中提供的看板/待办事项/迭代相关命令。
- 史诗或空间：基于JQL执行
```
jira workitem query
```
  命令。
- 加载的信息包括：密钥、标题、状态/分类、经办人、更新时间、父项、子任务/阻塞项以及URL。
拆分工作项集合。
- 候选工作项为未完成/未解决的工作项。同类项为同一看板、迭代、史诗或空间中已完成的工作项。
- 排除史诗/父项。除非用户明确允许，否则跳过未解决的阻塞项或未完成的子任务。
从集合层面发现共享代码仓库上下文。
- 即使是单个工作项或短列表，也要从整体集合推断上下文。
- 从关联的PR、提交、分支、项目链接、Compass组件、上下文查询以及已解决的同类项中提取代码仓库/工作区信息。
- 通过已完成的同类项推断通用代码仓库、经办人、Jira密钥标题/分支命名规范、PR链接以及合并到状态转换的延迟时间。
检查可选的发现信号。
- 如果
```
rovo list-apps
```
  显示已连接Bitbucket或GitHub，使用Rovo搜索密钥、标题、PR URL、分支和代码仓库。在通过TWG/供应商/Jira证据验证之前，仅将其作为发现线索。
- 如果
```
search-code
```
  可用，先搜索精确密钥，再在已发现的代码仓库中搜索独特的标题术语。强匹配结果包括分支名称、提交文本、变更文件或符号；宽泛的模糊匹配结果视为弱匹配。
扩展可能的执行者范围。
- 优先选择已完成同类项和候选工作项的经办人。将报告人和评论者视为弱线索。
- 查询时间窗口内这些经办人提交的已合并PR，首先限定在已发现的代码仓库范围内；如果代码仓库未知，则从作者/日期结果中推断代码仓库。
批量搜索已合并PR。
- 优先针对每个代码仓库/时间窗口执行一次已合并PR查询，然后在本地匹配所有候选密钥。一个PR可能匹配多个精确密钥。
- 在PR标题、描述、分支、提交以及关联问题元数据中匹配精确密钥。
- 仅在无证据、优先级工作项或存在歧义时，才退回到按单个工作项查询。
置信度评分。
- 高置信度：已合并PR或关联PR元数据中存在精确密钥，时间逻辑合理，无相同密钥的未关闭PR，无阻塞项/子任务，且目标状态转换存在。
- 中置信度：同一经办人/代码仓库且标题高度相似，或仅在提交/search-code证据中存在精确密钥。
- 低置信度：模糊匹配、仅同一作者、代码仓库未知或存在歧义。
生成试运行计划。
- 表格列包括：工作项密钥/标题、当前状态、建议的状态转换、置信度、简要理由、PR标题/URL、合并日期、Jira最后更新时间、链接/代码仓库建议、PR标题修复建议、跳过原因以及验证信息。
- 仅在通过实时帮助验证后才包含准确命令。绝不能将低置信度的行作为可执行内容呈现。

Mutations

变更操作

Only mutate after explicit approval of the exact rows or plan.

Transition: list transitions first, then use only the approved done/resolved target.
Link enrichment: if links are missing, offer
```
jira workitem link weblink
```
for PR/repo URLs after querying links and verifying help. Do not claim this creates native development-panel links.
PR title fix: for Bitbucket, update title only when a verified
```
bitbucket pull-requests get
```
leaf can read the PR, write access is verified, the PR is confidently tied to the item, and the user approved it. For GitHub, update only when an authenticated write tool is available and access is verified; otherwise skip with the reason.
Verification: re-read each changed workitem and PR. Report changed keys, statuses, URLs, and failed rows.

Do not transition medium-confidence items automatically. Do not transition declined/superseded PRs or rows supported only by same author, same repo, or fuzzy similarity.

仅在获得对具体行或计划的明确批准后，才可执行变更。

状态转换：先列出所有可用的状态转换选项，然后仅使用已批准的“完成/已解决”目标状态。
链接补充：如果缺少链接，在查询链接并验证帮助文档后，提供
```
jira workitem link weblink
```
命令来添加PR/代码仓库URL。请勿声称此操作会创建原生开发面板链接。
PR标题修复：对于Bitbucket，仅当已验证的
```
bitbucket pull-requests get
```
命令可以读取该PR、已验证写入权限、PR与工作项的关联具有高置信度且用户已批准时，才更新标题。对于GitHub，仅当存在已认证的写入工具且已验证访问权限时才更新；否则跳过并说明原因。
验证：重新读取每个已变更的工作项和PR。报告已变更的密钥、状态、URL以及执行失败的行。

请勿自动转换中置信度的工作项。请勿转换已拒绝/已被取代的PR，或仅基于同一作者、同一代码仓库或模糊匹配支持的工作项。

Output

输出

Lead with the decision summary:

executable high-confidence rows,
review-needed medium-confidence rows,
skipped unsafe rows,
missing repo/auth/permission coverage.

Then provide the dry-run table and exact approval question. Include URLs or stable IDs for every workitem and PR used as evidence.

首先展示决策摘要：

可执行的高置信度工作项行，
需要审核的中置信度工作项行，
已跳过的不安全工作项行，
缺失的代码仓库/认证/权限覆盖情况。

然后提供试运行表格和明确的批准确认问题。作为证据使用的每个工作项和PR都需包含URL或稳定ID。