用户点击“安装”之后，最想知道的通常不是系统正在跑哪条命令。
他更关心几个很朴素的问题：这个应用是不是还在安装？卡在哪一步？需要我做什么吗？失败以后我应该看哪里？如果我等几分钟再回来，页面还能不能告诉我刚才发生了什么？
这篇接着 Blueprint 不是 Marketplace 往下讲。上一篇说，一键安装不能直接执行，应该先让用户看到计划。今天的问题是：计划被接受以后，进度应该长什么样？
我们的答案是：用户应该看到一个安装进度，而不是一堆分散的日志。
用户安装的是一个应用
一个 Blueprint 安装看起来像一个按钮，但背后可能会做很多事。
它可能创建 project 和 environment，准备 volume 或数据库，创建一个或多个 resource，再启动对应的 deployment。对系统来说，这些步骤分属不同对象。对用户来说，他只是安装了一个应用，比如 PocketBase、n8n 或一个带后台服务的项目。
所以第一层进度应该按“这个应用现在怎么样了”来组织，而不是按内部对象摊开。
一个更友好的安装页应该能回答：
- 安装还在排队、执行、检查，还是已经完成？
- 当前正在准备哪一部分？
- 哪些组件已经有访问地址或状态？
- 哪些地方需要用户补充配置？
- 如果失败，失败原因能不能被普通用户看懂？
这些问题听起来不复杂，但它们决定了用户看到的是产品，还是一堆后台痕迹。
日志适合下钻，不适合当主体验
部署日志当然重要。
当某个组件启动失败，日志可能会告诉我们端口没开、环境变量缺失、镜像拉不下来、健康检查一直不过。工程师和 AI agent 都需要这些材料来排查问题。
但日志不应该成为用户理解安装进度的唯一入口。
如果 Marketplace 页面只丢给用户三条不同的日志链接，用户就得自己猜：哪一条代表整个应用？哪一条只是其中一个组件？哪条失败会影响最终访问地址？如果其中一个组件已经成功，另一个还在检查，应用到底算不算安装完成？
Appaloft 的进度体验把这几层分开：
- Marketplace 或 Installed Application 页面显示整体安装状态。
- 组件 deployment 页面保留详细日志和事件。
- 支持排查信息默认收起来，只在需要时给管理员或支持人员看。
这样用户先看到一句能理解的话：应用正在安装、正在验证、已经可访问，或安装失败。需要细看时，再进入组件日志。
失败状态要能交接
安装失败时，最糟糕的提示不是“失败”，而是“失败，但你不知道下一步该找谁”。
一个好的失败状态至少要留下三样东西。
第一，是用户能读懂的原因。比如缺少必填配置、健康检查没有通过、依赖还没准备好、访问地址无法确认。它不需要暴露内部任务编号，也不该把一整段后台堆栈甩到页面上。
第二，是可以继续查看的线索。哪个组件失败了？有没有对应的 deployment 页面？日志在哪里？如果需要支持团队介入，他们能不能拿到更细的排查信息？
第三，是重试或恢复的边界。用户应该知道自己是可以改配置后重试，还是需要等待平台恢复，或者应该联系支持。
这也是为什么我们不把后台执行细节当作普通用户语言。任务有没有被重试、由哪个后台进程处理、进入过几次排队，这些信息对支持排查有用，但它们不是用户安装应用时应该先理解的东西。
AI agent 也需要这个进度模型
这个问题不只影响 Web Console。
如果 AI agent 帮用户安装应用，它也需要一个稳定的进度模型。它不能只盯着 terminal 输出，也不该在日志里搜索几个固定词后就判断安装成功。
它应该能问控制面：这个应用安装现在是什么状态？有哪些组件？失败发生在哪个部分？有没有可访问地址？还缺什么用户动作？
这和人类用户看到的进度应该是一套语言。AI 可以更快地跟进下一步，但不应该拥有一条只有它能理解的暗道。
当进度被建模成“应用安装进度”，Web Console、CLI、AI skill 和支持流程都可以围绕同一个事实说话。用户看到的是简洁状态，工程师能下钻到日志，支持人员能拿到排查线索，agent 也能更可靠地继续工作。
我们想隐藏的是噪音，不是事实
把进度做得更友好，不等于把细节藏掉。
Appaloft 仍然保留组件日志、事件、失败原因和支持排查入口。区别在于：这些信息有层次。普通用户先看到安装结果和当前步骤；需要排查时，页面再把他带到合适的组件日志；更底层的后台任务信息留给管理员和支持场景。
这件事的目标很简单：用户点击安装后，不应该被迫理解平台内部怎么排队、怎么领取任务、怎么重试。他应该知道自己的应用是不是在路上、是不是可用了，以及失败时该从哪里继续。
一键安装可以从一个按钮开始，但按钮之后不应该只剩日志。进度本身也应该是产品体验的一部分。