自动关联目录：质量门禁：Error、Warning 与 Retryable 是三个维度

核心判断：严重度回答“能否继续”，可重试性回答“原输入不变时再跑是否可能成功”，二者不能合成一个成功/失败布尔值。

一、业务冲突

导入失败可能来自缺少必需引用、参数越界、工具崩溃、凭证暂不可用或远端拒绝。它们对用户的下一步完全不同：修内容、改配置、等待、重试或联系工具维护者。只有一个错误字符串会把所有失败都变成“再点一次试试”。

二、实际实现

实际合约中的 Issue 同时包含稳定 code、warning/error、目标列表和 retryable。目标可以指向任务、输入、字段、节点、缺失引用、产品或平台表示。提交资格只在错误数为零且计划仍有效时放行；运行失败另外记录 Stage、错误码、可重试性和下一次重试时间，业务拒绝不会进入自动退避循环。

三、值得保留

Issue 与运行 Failure 分层合理：前者描述内容或配置事实，后者描述一次执行结果。结构化 target 让 UI 能定位到具体字段或节点，而不是只弹 Toast；Warning 可以保留可见性而不阻断所有创作。

四、结构性缺陷

若 code 没有中央目录，字符串仍会逐渐失去稳定语义；retryable=true 也不代表应该自动重试，还需要错误类别、预算和副作用安全性。自由文本 message 无法稳定映射修复入口，多个 target 的主次关系也未必明确。

五、目标设计

struct Diagnostic {
    DiagnosticCode code;
    Severity severity;
    RetryPolicy retry;
    Array<TargetRef> targets;
    RepairAction action;
    StageId stage;
    IntentId intent;
};

enum RetryPolicy { Never, AutomaticBounded, ManualAfterChange, ReconcileFirst };

诊断目录定义参数 Schema、默认文案、阻断规则和允许的 RepairAction。管线只产生 code 与结构化参数，UI 决定本地化展示；自动重试还必须同时通过幂等性和剩余预算检查。

六、取舍与验证

类型化诊断增加维护成本，却能统计真实故障分布并自动跳转修复。契约测试应拒绝未知 code、缺参数和非法 target；E2E 测试验证阻断、警告、自动重试、人工修改和对账五类路径不会互相混淆。