feat(agent): add a bounded conservative implementation retry loop before artifact-only fallback

[dangzitou]

问题概述

当前 OpenMeta 在 agent 流程里，通常是：

1. 生成 patch draft
2. 基于当前 snippets / candidate files 生成一次 implementation draft
3. 如果没有产出可安全应用的 fileChanges
4. 就直接收口为 artifact-only run

这会导致一种比较常见的结果：

• Changed files: none
• Pull Request: not created
• 但仍然生成并发布 dossier / patch draft / PR draft / proof-of-work

从实际体验看，这说明 OpenMeta 目前更像“一次性尝试生成补丁”，而不是一个会在有限边界内继续推进的 contribution agent。

具体问题

很多仓库里，第一次 implementation draft 失败，并不一定说明这个 issue 不适合自动推进，更多时候只是因为：

• 当前上下文还不够
• patch target files 还不够准
• 缺少相邻实现文件 / tests / validators / services
• validation failure 需要再读一轮文件后才能修

但现在一旦第一次 implementation draft 没有产出安全改动，OpenMeta 很快就会退回到 artifacts，而不会继续做一小段有限轮次的“补上下文 -> 再试一次”。

这会放大 changed files: none 的出现频率。

目标

这个 issue 的目标不是提高 PR 数量本身。

目标是：

• 在不增加低质量 / 噪声 draft PR 的前提下
• 减少过早退化为 artifact-only run 的情况
• 让 OpenMeta 在第一次 implementation 失败后，先做有限、保守、可控的继续推进

也就是说，希望它更像：

• “再补一轮高信号上下文，再试一次改代码”

而不是：

• “第一次没改出来，就直接结束并写 dossier”

建议改进

建议在 Draft patch / Concrete patch 阶段增加一个 bounded conservative implementation retry loop，而不是第一次失败就立刻落到 artifact-only output。

可以做的事情

当 implementation draft 返回：

• status !== success
• 或 fileChanges.length === 0

不要立刻结束，而是先尝试再补一轮 implementation context，例如：

• patch target 的同目录文件
• 相邻 service / route / validator / query-config
• 对应 test / spec 文件
• 已命中路径族下的邻近实现文件

然后再次调用 generateImplementationDraft(...)。

建议限制

第一版建议保持保守：

• 最多重试 2 到 3 轮
• 每轮新增文件数有限
• 总 snippets / context 预算有限
• 仍然保留现有安全门：
  • 越界路径拒绝
  • 自动改动文件数上限
  • validation repair 越界拒绝
  • dirty workspace / invalid workspace 拒绝
• 如果多轮后仍无 changed files，则明确收口为 artifact-only run

非目标

本 issue 不追求：

• 为了提高 PR 数量而放宽安全门
• 在上下文不足时强行生成代码改动
• 在 validation 失败时默认继续开 PR
• 把 OpenMeta 变成完全开放式 coding agent
• 引入无限循环或无边界工具调用

目标是让 agent 在第一次实现失败后，更有一点保守型持续推进能力，而不是更激进、更吵闹地制造 PR。

预期效果

如果实现这个 bounded conservative loop，预期可以改善：

• 降低 changed files: none 的频率
• 提高真实代码改动产出率
• 提高触达到 draft PR 阶段的概率
• 保持 OpenMeta 当前 contribution pipeline 的可控性
• 避免为了“更像 agent”而产生更多垃圾 PR

为什么值得做

OpenMeta 当前已经有不错的：

• issue ranking
• patch drafting
• artifact publication
• PR drafting

现在真正缺的不是更多 artifacts，而是当 implementation 第一次失败时，能不能在不放松质量标准的前提下，再往前推一点。

这个 bounded conservative retry loop 会是一个比较小，但很关键的 agent 化增强。

---

Summary

Right now, OpenMeta usually does the following during an agent run:

1. generate a patch draft
2. generate one implementation draft from the current snippets / candidate files
3. if no safe fileChanges are produced
4. fall back directly to artifact-only output

This often leads to runs that end with:

• Changed files: none
• Pull Request: not created
• but still generate and publish dossier / patch draft / PR draft / proof-of-work artifacts

In practice, this makes OpenMeta feel more like a one-shot patch generator than a contribution agent that can continue pushing forward within controlled bounds.

Problem

In many repositories, a failed first implementation draft does not necessarily mean the issue is unsuitable for automation. More often, it means:

• the current context is still insufficient
• patch target files are still slightly off
• neighboring implementation files / tests / validators / services are missing
• validation repair would need one more round of file reads

Today, once the first implementation draft fails to produce safe file changes, OpenMeta tends to stop quickly and fall back to artifacts instead of attempting a small bounded “expand context and retry” step.

That makes changed files: none more common than it needs to be.

Goal

The goal of this issue is not to maximize PR creation volume.

The goal is to:

• reduce premature artifact-only fallbacks
• avoid increasing low-quality or noisy draft PRs
• make OpenMeta slightly more persistent after the first implementation failure, but only in a bounded and conservative way

In other words, the desired behavior is closer to:

• “gather one more round of high-signal context, then try patch generation again”

rather than:

• “fail once, then stop at dossier output”

Suggested Change

Add a bounded conservative implementation retry loop in the Draft patch / Concrete patch stage instead of immediately falling back to artifact-only output after the first failed implementation attempt.

What it could do

When an implementation draft returns:

• status !== success
• or fileChanges.length === 0

OpenMeta should avoid terminating immediately and instead try one more round of implementation context expansion, for example:

• sibling files near patch targets
• nearby service / route / validator / query-config files
• matching test / spec files
• neighboring implementation files within an already matched path family

Then it can call generateImplementationDraft(...) again.

Suggested limits

The first version should stay conservative:

• retry at most 2 to 3 rounds
• cap the number of newly added files per round
• cap total snippet / context budget
• keep existing safety gates unchanged:
  • reject out-of-scope paths
  • keep automatic changed-file limits
  • reject out-of-scope validation repair edits
  • keep dirty / invalid workspace protections
• if no changed files are produced after bounded retries, fall back explicitly to artifact-only output

Non-Goals

This issue does not aim to:

• relax safety gates just to increase PR volume
• force code changes when context is still insufficient
• continue to draft PR creation by default after validation failures
• turn OpenMeta into a fully open-ended coding agent
• introduce infinite loops or unbounded tool execution

The goal is to make the agent a bit more persistent in a careful, controlled way, not more aggressive or noisy.

Expected Outcome

A bounded conservative retry loop should help:

• reduce the frequency of changed files: none
• improve actual code-change production
• improve the rate of reaching draft PR creation
• preserve the controlled nature of the current contribution pipeline
• avoid producing more low-quality or noisy PRs just to look more autonomous

Why This Matters

OpenMeta already has strong:

• issue ranking
• patch drafting
• artifact publication
• PR drafting

What it currently lacks is a small amount of persistence when the first implementation attempt fails.

This bounded conservative retry loop would be a relatively small but high-leverage step toward making the agent meaningfully more effective without sacrificing its quality bar.