自动关联目录：管线进度：百分比必须来自已确认工作账本

核心判断：Stage 名称只能说明“正在做哪类工作”，不能计算可信百分比；可恢复管线的进度必须由提交前冻结的工作集合和已确认完成项推导。

一、业务冲突

一个导入任务可能产生多个产品、平台包、源文件、封面和最终提交。若 UI 把“进入上传阶段”直接显示为固定百分比，重试、并行上传或新增产品会导致倒退、长时间卡住，甚至在远端结果未知时显示完成。

二、实际实现

运行在制品验证后冻结工作单元，按 Cook、源发布、平台发布、封面和 Finalize 分类。每个确认完成的单元以稳定 key 记入账本，重复完成不重复计数，计划变化则拒绝沿用旧账本。Stage 区间只负责视觉映射，上传区间内部使用 completed / total；结果未知停在对应区间，不假装成功。

三、值得保留

进度来自确认事实而非日志行数量，进程重启后可以重算。冻结工作集还防止重试时“总工作量偷偷变化”。测试覆盖乱序冻结、重复完成、计划漂移和非法计数，基础语义扎实。

四、结构性缺陷

所有工作单元等权时，一个小封面和一个大平台包贡献相同进度；单个长 Cook 仍会长时间不动。Stage 区间是手工配置，新阶段插入后可能改变用户对历史耗时的理解。百分比也无法表达“等待凭证”或“结果待对账”的不确定性。

五、目标设计

struct ProgressSnapshot {
    Hash frozenWorkPlan;
    uint64 confirmedWeight;
    uint64 totalWeight;
    RunPhase phase;
    ProgressConfidence confidence; // Confirmed, Estimated, Blocked, Unknown
};

double DisplayProgress(ProgressSnapshot p) {
    Require(p.frozenWorkPlan == CurrentIntent().workPlan);
    return Clamp01(double(p.confirmedWeight) / p.totalWeight);
}

权重由可解释的制品字节数或历史成本桶给出，不能使用实时漂移的随意估时。活动单元可显示独立状态，但只有可验证检查点才能推进 confirmed progress。

六、取舍与验证

更真实的进度可能不够平滑，产品上应优先准确表达“处理中、等待、待确认”，而不是伪造连续动画。验证同一 Intent 下进度单调、重启不倒退、重试不重复、未知结果不越过确认点；新 Intent 则明确重置。