用评审反馈修复 SpecRepairing Specs with Feedback評価フィードバックでSpecを修復する

2026 年 6—10 月June–October 20262026年6–10月

用户要求统计培训完成度，设计里也有一个同名进度字段，但没有写明怎样从培训记录计算。管理员原本可以维护业务数据，修复后却变成只读。这两种设计都曾通过文档检查，直到执行建表后才暴露问题。A user asked to track training completion. The design included a progress field with the right name, but never explained how to calculate it from training records. In another case, an administrator who could maintain business data became read-only after repair. Both designs passed document checks; their problems surfaced only after the applications were built.研修の完了率を集計する要求に対し、設計には同名の進捗フィールドがあっても、研修記録からの計算方法がなかった。別の例では、業務データを管理できた管理者が修復後に読み取り専用になった。どちらも文書審査を通過し、実際に構築して初めて問題が現れた。

Judge–Fix 要解决的就是这类错误：Judge 找出设计缺口，Fix 修改文档，Router 决定先修哪个业务域。项目还尝试了 Verifier，在写回之前比较修前、修后两份文档，判断这次修改是否应该接受。Judge–Fix addresses these failures: Judge identifies design gaps, Fix edits the document, and Router chooses which domain to repair first. We also tried a Verifier that compares the before-and-after documents and decides whether to accept an edit before writing it back.Judge–Fixはこうした誤りを扱う。Judgeが設計の不足を指摘し、Fixが文書を修正し、Routerが修復する領域の順序を決める。書き戻す前に修復前後の文書を比較し、変更を採用するか判断するVerifierも試した。

几个月的实验没有得到“检查越多、修得越好”的结果。限制无关修改有过明确收益；增加候选、投票和修复轮数则经常只增加成本。判断一个改动是否值得保留，需要看原问题有没有解决，也需要看原来的业务还能不能完成。Across several months of experiments, more checks did not consistently produce better repairs. Restricting unrelated edits helped; adding candidates, votes, or repair rounds often just added cost. A useful change must resolve the original problem while preserving the original task.数か月の実験では、確認を増やすほど修復が良くなるとは限らなかった。無関係な変更の制限には効果があったが、候補、投票、修復回数の追加は費用だけを増やすことも多かった。元の問題を解消し、元の業務も実行できることが採用条件となる。

静态图Static figure静止図

先修依赖，再修下游Repair dependencies before downstream design依存関係を先に修復する

静态图Static figure静止図

图注与口径Figure notes図注と評価条件

修复块内保留候选接纳 / 拒绝与按根因回退；点击模块可展开完整内部路径。投票只累计同一 Spec 版本。Repair blocks retain candidate acceptance/rejection and root-cause retries; select a module to inspect its internal paths. Votes accumulate only for the same Spec version.各修復ブロックは候補の採否と根本原因別の再試行を保持。選択すると内部経路を表示。投票は同一 Spec バージョン内で集計する。

格式缺口 → 对应领域回修 共用格式回退预算：1 次Format gap → domain repair Shared format return budget: 1形式不備 → 該当領域へ差し戻し 形式用の共有予算：1回

多维表格设计分为数据表、仪表盘、工作流和权限四个域。后三域依赖表和字段，因此不能把四份错误清单各自交给模型，最后拼起来。例如统计图和工作流同时缺一个字段，应先补表，再修改两个下游设计。A Bitable design has four domains: tables, dashboards, workflows, and permissions. The latter three depend on tables and fields, so four independent error lists cannot simply be repaired and stitched together. If a chart and a workflow both lack the same field, repair the table first, then update both consumers.多次元テーブルの設計は、テーブル、ダッシュボード、ワークフロー、権限の四領域に分かれる。後ろの三領域はテーブルとフィールドに依存するため、別々のエラー一覧を修復して結合するだけでは足りない。グラフとワークフローが同じフィールドを必要とするなら、まずテーブルを補い、その後で両方を修正する。

主链路先检查四域，由 Router 选择修复位置。修改后重新检查；普通阶段未解决的样本可以进入难例阶段，但总预算有限。最后对同一份文档投票，确认业务通过后再处理格式。格式候选如果改变了文档，也需要重新确认业务判断。The main pipeline checks all four domains, lets Router choose a repair location, then checks the revised document again. Unresolved cases can move from the regular stage to a hard-case stage within a bounded budget. Finally, votes on the same document confirm semantic acceptance before formatting. If a formatting candidate changes the document, its semantics must be checked again.主処理は四領域を審査し、Routerが修復箇所を選び、修正後に再審査する。通常段階で解決しない例は難例段階へ進めるが、総予算には上限がある。最後に同一文書への投票で業務要件の合格を確認し、形式を整える。形式修正で文書が変われば、業務面も再確認する。

A · 入口检查A · Entry checksA · 入口の確認

静态图Static figure静止図

B · 普通修复 · 共用回退预算 2 次B · Regular repair · Shared fallback budget: 2B · 通常修復 · 共通フォールバック予算2回

静态图Static figure静止図

C · 难例修复 · 独立回退预算 3 次C · Hard-case repair · Separate fallback budget: 3C · 難例修復 · 独立フォールバック予算3回

静态图Static figure静止図

D · 准出 · 格式回退预算 1 次D · Release checks · Formatting fallback budget: 1D · 准出確認 · 形式フォールバック予算1回

静态图Static figure静止図

流程图对应 2026-10-16 的实现；各实验采用各自固定的配置。The diagrams show the implementation as of October 16, 2026; each experiment uses its own fixed configuration.フロー図は2026年10月16日時点の実装を示します。各実験では、それぞれ固定した設定を用いています。

一次修复包含什么What a repair contains一回の修復で行うこと

Fix 读取用户需求、当前设计和待修问题。对 Markdown SpecDoc，它主要生成局部补丁；对 HostPlan，则按 JSON 结构写回。程序先确认输出能解析、补丁能应用，才把候选送去评审。原文没匹配上，不能算作修复已完成。Fix reads the user requirements, current design, and outstanding issues. It mainly produces local patches for Markdown SpecDocs and writes structured JSON for HostPlan. A candidate is reviewed only after its output parses and its patch applies. A patch that cannot match the original text is not a completed repair.Fixはユーザー要求、現在の設計、未解決の問題を読む。Markdown SpecDocでは主に局所パッチを作り、HostPlanではJSON構造で書き戻す。出力を解析でき、パッチを適用できた候補だけを審査する。元の文面に一致しないパッチは、修復完了とは扱わない。

每轮候选从同一个输入版本生成，分别检查、择优接纳，不把不同候选直接拼接。候选被拒绝时保留旧文档，下一轮接收失败原因。局部通过后，还要返回主链路做整体检查。Candidates in a round start from the same input version. They are checked separately and accepted by comparison, not spliced together. Rejection preserves the old document and sends the failure reason to the next round. A locally accepted repair still returns to the main pipeline for an overall check.同じラウンドの候補は同一の入力版から生成する。個別に審査して比較採用し、異なる候補を直接つなぎ合わせない。却下時は元の文書を保持し、失敗理由を次のラウンドへ渡す。局所的に合格しても、主処理に戻して全体を確認する。

A · 生成候选A · Generate candidatesA · 候補生成

静态图Static figure静止図

B · 评估候选B · Evaluate candidatesB · 候補評価

静态图Static figure静止図

C · 接纳候选C · Accept a candidateC · 候補採用

静态图Static figure静止図

局部补丁、输出恢复、对象替换、候选去重和回退都已有实现。后续发现同类错误，应查它在哪个入口失效，而不是再加一层同名机制。Local patches, output recovery, object replacement, candidate deduplication, and fallback already exist. When a similar failure recurs, trace where the existing mechanism failed before adding another layer.局所パッチ、出力復旧、オブジェクト置換、候補重複排除、フォールバックは実装済みである。同類の失敗が起きたら、同名の仕組みを追加する前に既存の入口のどこで機能しなかったかを調べる。

少改一些，确实有用Smaller edits helped変更を絞る効果

6 月的 Non-Table 对照固定了同一批 300 条输入。仅增加能力说明，Fix 阶段通过数从 156 变为 154；进一步要求保留合格段落、只修改问题及必要依赖后，通过数达到 177，已合格域的退化次数从 76 降到 47。另一组 Table 对照都是 179/300，未出现同样提升。June’s Non-Table comparison used the same 300 inputs. Adding capability descriptions alone changed Fix-stage passes from 156 to 154. Requiring preservation of valid sections and limiting edits to issues and necessary dependencies raised passes to 177 and reduced regressions in already-passing domains from 76 to 47. A separate Table comparison stayed at 179/300 in both arms.6月のNon-Table比較は同じ300件の入力を固定した。機能説明の追加だけではFix段階の合格数は156から154になった。合格済みの段落を保持し、問題と必要な依存関係だけを修正する条件を加えると177件になり、合格済み領域の退化は76回から47回に減った。別のTable比較は両群とも179/300で、同じ改善はなかった。

保留下来的做法是限制无关修改，不是禁止修改所有旧内容。若工作流缺少必要字段，只保护旧表、不允许补字段，同样修不好。We retained the restriction on unrelated edits, not a blanket ban on editing old content. A workflow missing a required field cannot be fixed if the old table is protected against every addition.残したのは無関係な変更の制限であり、既存部分をすべて変更禁止にする方針ではない。ワークフローに必要なフィールドがないとき、古いテーブルを保護して追加まで禁じれば修復できない。

8 月的 50 条策略实验进一步比较了模型和修改方式：An August experiment on 50 cases compared models and editing methods:8月の50件実験では、モデルと修正方法を比較した。

末轮换模型在这组多修好 3 条；加入局部历史保持结果，少了 429 次调用。全文方案增加了审核和回滚，却没有生成足够多可接受的替代文档。Switching the final-round model repaired three additional cases. Local history preserved that result with 429 fewer calls. The full-document approach added review and rollback, but failed to produce enough acceptable replacements.最終回のモデル変更で、この組ではさらに3件を修復した。局所履歴を加えると結果を維持したまま429回の呼び出しを削減できた。全文方式は審査とロールバックを増やしたが、採用可能な代替文書を十分に生成できなかった。

另一组 8 个工作流难例更直接：原文补丁准出 3 条，换成对象 ID 加文档哈希后只有 1 条；保留原补丁，只明确流程分支范围、首次命中和完成状态来源，准出 7 条。新定位协议拒绝了大量候选。定位更稳定是设计目标，并不等于整链结果更好。Eight hard workflow cases made the trade-off clearer. Original-text patches accepted three cases; replacing them with object IDs and document hashes accepted only one. Keeping the original patch protocol but clarifying branch scope, first-match behavior, and the source of completion status accepted seven. The new addressing protocol rejected many candidates: more stable targeting did not translate into better end-to-end results.ワークフローの難例8件では差がより明確だった。原文パッチの准出は3件、オブジェクトIDと文書ハッシュへの変更後は1件だった。元のパッチを保ち、分岐の範囲、最初の一致、完了状態の出所だけを明確にすると7件になった。新しい位置指定方式は多くの候補を却下した。位置の安定性という設計目標が、そのままチェーン全体の改善になるわけではない。

静态图Static figure静止図

扩大预算也未必有用。17 条难例从五轮增加到七轮，准出仍为 13 条，token 从 44.57M 增至 53.11M。上述结果来自不同样本集，不能把它们的绝对通过率排列成一条提升曲线。More budget also failed to guarantee improvement. Expanding 17 hard cases from five to seven rounds left acceptance at 13 while tokens rose from 44.57M to 53.11M. These experiments use different samples; their absolute pass rates are not points on one improvement curve.予算を増やしても改善するとは限らない。難例17件を5回から7回に増やしても准出は13件のまま、トークンは44.57Mから53.11Mに増えた。これらは異なる標本の結果なので、絶対合格率を一本の改善曲線として並べることはできない。

重复判断解决不了所有错误Repeated judgments cannot fix every error判断の繰り返しで直せない誤り

同一文档重复检查会得到不同结果。6,457 条 SpecDoc 曾在链内通过 6,291 条，单次独立重判只通过 5,315 条。这推动了同版本多数投票：最多三票，至少两票通过；结论已确定就不再凑满票数。Repeated checks of one document can disagree. Of 6,457 SpecDocs, 6,291 had passed inside the pipeline, but only 5,315 passed a single independent reassessment. This motivated majority voting on the same version: at most three votes, at least two passes, stopping as soon as the outcome is determined.同じ文書を繰り返し審査しても結果は揺れる。6,457件のSpecDocはチェーン内で6,291件が合格したが、独立した単回再審査では5,315件だった。そこで同一版への多数決を導入した。最大3票、2票以上で合格とし、結論が決まった時点で打ち切る。

静态图Static figure静止図

固定已有票据的回放中，早停和有效首票复用让 146 个节点的调用从 2,442 次降至 2,190 次，结果相同。但在线重新采样时还有限流、重试和延迟，一次耗时对照只缩短约 0.66%。不能用离线调用节省比例代替实际加速。A replay with fixed recorded votes reduced calls across 146 nodes from 2,442 to 2,190 through early stopping and reuse of valid first votes, with identical outcomes. Online sampling also involves rate limits, retries, and latency: one timing comparison improved by only about 0.66%. Saved replay calls are not equivalent to measured wall-clock speedup.既存の票を固定したリプレイでは、早期停止と有効な初回票の再利用により、146ノードの呼び出しが2,442回から2,190回へ減り、結果は同じだった。オンライン再生成には制限、再試行、遅延もあるため、ある実測比較での時間短縮は約0.66%にとどまった。リプレイでの呼び出し削減率を実際の高速化率とは扱えない。

投票主要减少随机翻转。Verifier 的 H002 错误图表连续三次被接受，H003 正确日期修改连续三次被暂缓，重复判断没有纠正它们。此时要改的是判断依据。Voting mainly reduces random flips. Verifier accepted H002’s incorrect chart three times in a row and deferred H003’s correct date edit three times. Repetition did not fix either mistake; their judgment criteria need attention.投票が主に減らすのはランダムな反転である。VerifierはH002の誤ったグラフを3回連続で採用し、H003の正しい日付変更を3回連続で保留した。繰り返しでは直らず、判断根拠を見直す必要がある。

Verifier 卡在了哪里Where the Verifier stalledVerifierが停滞した理由

Verifier 比较的不只是两个分数。它先列出当前问题，再确认候选是否修好了目标、保留了需求、没有破坏别处。只有这些条件满足，连续评分才用于比较候选；高分不能抵消删除需求或权限退化。Verifier does more than compare two scores. It enumerates current problems, then checks whether a candidate fixes the target, preserves requirements, and avoids damage elsewhere. Continuous scores rank candidates only after these conditions hold; high scores cannot compensate for deleted requirements or degraded permissions.Verifierは二つの点数を比較するだけではない。まず現在の問題を列挙し、候補が対象を修復し、要求を保持し、他所を壊していないかを確認する。これらを満たした後に連続スコアで候補を比較する。高得点でも要求の削除や権限の退化は相殺できない。

静态图Static figure静止図

一项固定 10 份文档、四域共 40 个判断单元的实验中，原方案由 Gemini 分析并评分，替代方案先让 Sol 分析、再由 Gemini 评分。参考一致数从 33 增至 38，问题类型 F1 从 56.3% 增至 88.4%。这项实验没有执行修复，且参考评审也来自 Sol；两组评分 token 上限存在差异，不能把全部变化归到同一个因素。With 10 fixed documents and 40 domain-level judgment units, the original setup used Gemini for both analysis and scoring. Replacing analysis with Sol while retaining Gemini scoring increased reference agreement from 33 to 38 and issue-type F1 from 56.3% to 88.4%. No repair was performed, the reference also came from Sol, and the scoring token caps differed, so this comparison changes more than one factor.10文書、四領域で計40判断単位を固定した実験では、元の構成はGeminiが分析と採点を担当した。分析をSol、採点をGeminiとすると、参照との一致は33から38、問題タイプF1は56.3%から88.4%へ上がった。ただし修復は実行せず、参照もSol由来で、採点トークン上限も異なる。変化を一つの要因だけに帰属させる比較ではない。

另一组 10 条完整修复对照却得到相反结果：生产 Judge–Fix 的独立参考通过数为 4 条，Verifier 只有 1 条。原始 145 个问题分别关闭了 133 个和 15 个。A separate end-to-end repair comparison on 10 cases went the other way. Production Judge–Fix passed four cases against the independent reference; Verifier passed one. They closed 133 and 15 of the original 145 issues, respectively.別の10件の全修復比較では逆の結果だった。独立参照での合格は本番Judge–Fixが4件、Verifierが1件。元の145問題のうち、それぞれ133件と15件を解消した。

静态图Static figure静止図

瓶颈出在修改没有真正落下去：大量候选重复，或补丁无法应用，最终 10 份文档中有 6 份仍是初稿。第 4 轮后继续跑到第 24 轮，通过内部检查的文档数也没有增加。较少引入新问题，主要是因为文档没怎么变；应先修候选生成和补丁写入，再考虑增加轮数。The bottleneck was getting edits applied. Many candidates were duplicates or unusable patches, leaving 6 of the 10 documents unchanged. Extending the run from round 4 to round 24 produced no additional releases. Few new problems appeared largely because little changed. Candidate generation and patch application need attention before adding more rounds.詰まっていたのは、変更を実際に反映する段階です。候補の重複や適用できないパッチが多く、10件中6件が初稿のままでした。第4ラウンドから第24ラウンドまで続けても、通過文書は増えませんでした。新しい問題が少なかったのは、文書がほとんど変わらなかったためです。反復回数を増やす前に、候補生成とパッチ適用を改善する必要があります。

结构化修复目标的单次对照也暴露了相似问题。N02 把净现金流改成收入，N04 用创建人替代业务负责人：报错可能消失了，需求却变了。这组 10 个修复事务的 token 减少约 25.6%，可安全接纳的候选从 6 个降到 5 个。下一步必须确认目标真的实现，而不是只检查旧问题是否还出现在新列表中。A single comparison of structured repair targets exposed the same risk. N02 replaced net cash flow with revenue; N04 replaced the business owner with the record creator. The error disappeared by changing the requirement. Across 10 repair transactions, tokens fell about 25.6%, while safely acceptable candidates fell from six to five. Acceptance must verify that the target was achieved, not merely that an old error vanished from a new list.構造化した修復目標の単回比較でも同じ危険が現れた。N02は純キャッシュフローを収入へ、N04は業務担当者を作成者へ置き換えた。エラーは消えても要求が変わっている。10修復トランザクションでトークンは約25.6%減ったが、安全に採用できる候補は6件から5件になった。新しい一覧から旧エラーが消えただけでなく、目標が実現したかを確認する必要がある。

格式通过以后，还要看业务Check semantics after formatting形式の確認後も業務要件を検証する

格式模块处理下游无法可靠读取的表达问题。若修复需要改变字段来源、授权范围或业务资源，就应交回业务域，而不能当成标点或结构整理。The formatting module handles expressions that downstream consumers cannot reliably read. Changes to field sources, authorization scope, or business resources belong back in a domain repair, not in punctuation or structural cleanup.形式モジュールは下流が安定して読めない表現を処理する。フィールドの出所、認可範囲、業務リソースを変える修復は、句読点や構造整理としてではなく、業務領域へ戻して扱う。

对 1,312 份历史未准出的文档继续修复，831 份最终准出。余下问题中，补丁写不进去、写入后格式仍不合规各有 108 份：前者要修写入过程，后者要修表达规则，不能都交给模型再改一遍。与此前数据合并后累计交付 3,999 份；这个总量包含多轮修复。Resuming repair on 1,312 previously unreleased documents produced 831 releases. Among the remainder, 108 had patches that could not be applied and another 108 still violated formatting rules. The first group needs application fixes; the second needs better formatting rules. Sending both back for another rewrite misses that distinction. Combined with earlier releases, delivery reached 3,999 documents across multiple repair rounds.過去に未通過だった1,312件の修復を再開し、831件が最終的に通過しました。残りのうち、パッチを適用できないものと、適用後も書式が不適合なものが各108件ありました。前者は書き込み処理、後者は表現規則の問題であり、どちらも再生成させれば済むわけではありません。以前の分と合わせた累計納品は3,999件で、複数回の修復を含む総数です。

交付后扫描也需要核对规则。94 条“工作流非标准 Key”里，88 条是当前规则允许的通知正文 Key；另外 6 条确有非标准 Key，旧准出 2 条，恢复后准出 4 条。不能把规则差异全部算成漏判，也不能因为多数是误报而忽略真实错误。Post-delivery scans also need rule checks. Of 94 flags for nonstandard workflow keys, 88 involved notification-body keys permitted by the current rules. Six were real nonstandard keys: two had passed earlier, and four passed after recovery. Rule differences must be separated from missed errors, while genuine failures still need attention.納品後の走査でもルールとの照合が必要だった。「ワークフローの非標準Key」94件のうち88件は現行ルールで許される通知本文Keyだった。残る6件は実際の非標準Keyで、旧准出は2件、復旧後は4件だった。ルール差異をすべて見逃しとは数えず、誤報が多数でも実際の誤りを無視しない。

文档准出不等于建表通过Passing the document check is not passing the build文書の合格と構築の成功は別

静态图Static figure静止図

图注与口径Figure notes図注と評価条件

这是下游退化诊断：两组都未获文档准出，实验仍执行 CodeAgent 对照。图保留 G/K 状态差异，不把 K 的产物画成已发布结果。This is a downstream regression diagnosis: neither document was released, but the experiment executed both with CodeAgent. K’s artifact is not a released result.下流の退行を診断する実験。両文書ともリリース不合格だが、比較のため CodeAgent を実行した。K の成果物をリリース済みとは扱わない。

G 提示词的一轮 Building 50 实验，Judge–Fix 准出 31 条，CodeAgent E2E 也通过 31 条，但交集只有 24 条。两个数字相同，并不说明文档检查预测了每一条建表结果。In one Building 50 run with prompt G, Judge–Fix accepted 31 cases and CodeAgent E2E also passed 31, but their intersection was only 24. Equal totals did not mean document checks predicted each build outcome.GプロンプトのBuilding 50の一回では、Judge–Fix准出もCodeAgent E2E合格も31件だったが、共通部分は24件だけだった。総数が同じでも、文書審査が各構築結果を予測できたことにはならない。

后续 G/K 使用相同原始 50 条输入、相同 SFT CodeAgent、SDK 和 E2E Judge，分别创建独立 Base。K 改了 Workflow Judge、Table Fix 和 Non-Table Fix，Permission Judge 未变。同期 G 的 E2E 为 30/50，K 为 26/50：9 条通过转失败，5 条失败转通过。A later G/K comparison used the same original 50 inputs, SFT CodeAgent, SDK, and E2E Judge, building separate Bases. K changed Workflow Judge, Table Fix, and Non-Table Fix but left Permission Judge unchanged. The contemporaneous E2E scores were G 30/50 and K 26/50: nine passes became failures and five failures became passes.後のG/K比較は同じ原始50入力、SFT CodeAgent、SDK、E2E Judgeを使い、Baseを独立に構築した。KはWorkflow Judge、Table Fix、Non-Table Fixを変更し、Permission Judgeは変えていない。同時期のE2EはGが30/50、Kが26/50で、合格から不合格が9件、逆が5件だった。

静态图Static figure静止図

逐例追查才能判断责任。Case 41 的原始管理员可编辑，K 的 Judge 建议缩为只读，Fix 接受后，代码把七张表设为只读，退化确实发生在设计阶段。Case 14 则是 G、K 都有同样退化，只在 K 的 E2E 中报出，不能全部归给新增提示词。Case traces locate responsibility. Case 41 originally allowed administrators to edit; K’s Judge suggested read-only access, Fix accepted it, and the code made all seven tables read-only. The regression began in the design. Case 14 had the same regression under both G and K but was flagged only in K’s E2E, so it cannot all be attributed to the new prompt.責任の所在は個別の追跡で確認する。Case 41は元々管理者が編集可能だったが、KのJudgeが読み取り専用を提案し、Fixが採用し、コードが7テーブルを読み取り専用にした。退化は設計段階で起きた。一方Case 14はGとKに同じ退化があり、KのE2Eだけで報告されたため、すべて新プロンプトのせいにはできない。

Case 38 用 Lookup 替代不支持的关联下钻，却没交代单值或集合以及比较含义。Case 50 补了配置表，却没补齐维护权限和状态更新。它们要求的是合法且完整的替代设计，不是删除能力限制或多写一句“保持闭环”。Case 38 replaced unsupported linked-record traversal with Lookup but left single-value versus collection behavior and comparison semantics unspecified. Case 50 added a configuration table without maintenance permissions or state updates. Both need complete, supported alternative designs—not fewer capability constraints or another instruction to keep the loop closed.Case 38は未対応の関連フィールド下位参照をLookupに置き換えたが、単一値か集合か、比較の意味を定義していなかった。Case 50は設定テーブルを追加しても管理権限と状態更新を補わなかった。必要なのは制約の削除や「閉ループを保つ」という一文ではなく、実現可能で完全な代替設計である。

后续候选的 E2E 降到 18/50，但同时更换了评审版本，已无法单独衡量提示词的影响。另一次 CodeAgent 因限流未完成执行，只留下运行故障，没有得到可比较的业务结果。这两次都需要先恢复可比的运行条件。A later candidate fell to 18/50 on E2E, but the evaluator changed at the same time, preventing attribution to the prompt alone. Another CodeAgent run was interrupted by rate limits and yielded no comparable business result. Both require comparable execution conditions before drawing quality conclusions.後続候補のE2Eは18/50まで下がりましたが、同時に評価器も変わっており、プロンプトだけの影響は測れません。別のCodeAgent実行はレート制限で完了せず、比較可能な業務結果が得られませんでした。どちらも、まず比較条件をそろえて再実行する必要があります。

接下来只改确认有问题的判断Next: correct the judgments we can substantiate次に直すのは根拠を確認できた判断

Judge–Fix 首先应统一 Workflow Judge 和 Fix 的能力表述：记录筛选的左右值都不能沿关联字段下钻；替代方式必须保留原记录范围、字段类型和比较含义。其他位置合法的引用，不因这条规则一并禁止。Judge–Fix should first align Workflow Judge and Fix on supported capabilities: neither side of a record-filter comparison may traverse linked fields. Alternatives must preserve record scope, field types, and comparison semantics. References that are valid elsewhere should remain allowed.Judge–FixはまずWorkflow JudgeとFixの機能表現を統一する。レコードフィルターの左右の値とも関連フィールドを下位参照できず、代替方法は元のレコード範囲、型、比較の意味を保つ必要がある。他の箇所で合法な参照まで一律に禁止しない。

权限和计算已有相关要求，应检查它们是否真正生效。用 Case 14/41 检验必要职责权限，用 Case 2 检验需要自动生成的计算结果，同时保留明确只读、允许手工记录的反例，避免一刀切。Permissions and calculations already have relevant requirements; test whether they actually take effect. Use Cases 14/41 for necessary role permissions and Case 2 for calculations that must be automatic, alongside explicit read-only and manual-recording counterexamples.権限と計算には既存要件があるため、実際に効いているかを確かめる。Case 14/41で必要な職務権限、Case 2で自動計算が必要な結果を検証する。同時に明示的な読み取り専用や手動記録を許す反例も残し、一律化を避ける。

Verifier 则先修两类判断：不能仅凭对象名称相互包含就把新旧问题合并；不能仅凭修后列表不再报错就认为目标关闭。H003 检验旧问题是否误判为新增，N02/N04 检验指标和负责人是否被偷偷替换。现有函数已发现这些判定风险，但尚未复现证明它们就是每个历史案例的直接原因。Verifier should correct two judgment patterns: merging old and new issues merely because object names overlap, and declaring a target closed because it disappears from the post-repair list. H003 tests whether an old issue is mistaken for a new one; N02/N04 test silent replacement of metrics and owners. Existing functions reveal these risks, though reproductions have not yet tied them causally to every historical case.Verifierは二種類の判断を修正する。オブジェクト名の包含だけで新旧問題を統合することと、修復後の一覧で報告されないだけで目標達成とすることである。H003は旧問題の新規誤認、N02/N04は指標や担当者のすり替えを検査する。既存関数からリスクは見つかったが、各過去事例の直接原因だという再現確認はまだない。

稳定对象定位、候选去重和回退不是待新增功能；全文重写、更多投票和扩大预算也没有足够证据支持默认启用。先用固定修前/修后对检查明确缺口，再用原始 Building 50 做配对修复和同版本 E2E，才知道下一次修改究竟改善了什么。Stable object addressing, deduplication, and fallback are already implemented. The evidence does not support enabling full rewrites, more votes, or larger budgets by default. First test specific gaps on fixed before-and-after pairs, then run paired repair and same-version E2E on the original Building 50 to measure the next change.安定した位置指定、重複排除、フォールバックは実装済みである。全文書き直し、投票追加、予算拡大を標準化する根拠も十分ではない。まず固定した修復前後の対で具体的な不足を確認し、次に原始Building 50で対応のある修復と同一版E2Eを行い、変更の効果を測る。