部署里最让人放松的一刻，通常是最后那一行。
打开这个 URL。
看起来只是一个链接，但它其实是部署契约的一部分。用户靠它访问，支持团队靠它定位，workflow 靠它验证，AI agent 也会拿它判断“是不是已经完成”。如果平台把所有部署结果都处理成“给你一条链接”，很多重要差异会被抹掉。
有些 URL 应该是证据。有些应该是会移动的产品入口。有些属于用户自己的域名。有些被禁用后必须安静地隐藏旧目标。这些不是同一种承诺。
这篇接着从 GitHub Actions 到 Appaloft：一次部署应该留下哪些证据和安装进度不应该是一堆互不相干的日志往下说。一次部署可以有很好的 provenance，但如果返回的 URL 没说清楚“什么会变”，人还是会被误导。
能打开，不等于说清楚了
一个 URL 返回 200 OK，只能证明一件事：这一刻，这个地址上有东西响应。
这当然有用，但它回答不了后面那些更麻烦的问题：
- 这个 URL 会一直指向这次部署吗？
- 它会不会在生产环境 promotion 后移动？
- 它适合贴到 issue、事故记录或审计材料里吗？
- rollback 是把这个 URL 指回去，还是再创建一个新 URL？
- 这是用户自己的 custom domain，还是平台提供的 default address？
- route 被 block 后，会不会泄露原来的 target？
- AI agent 检查它时，到底验证了什么？
很多部署工具会把这些问题混在一起，因为 happy path 很简单：构建、部署、打印 URL。第一次 rollback、preview cleanup、自定义域名变更、支持交接或缓存异常出现之后，混乱才会显出来。
Appaloft 的方向是把 URL class 说清楚。route 的名字应该携带产品承诺。
Immutable URL 是证据
Immutable deployment URL 不应该 repoint。
如果它是为 deployment A 创建的，它就应该一直指向 deployment A，直到过期或被明确禁用。它适合贴在 PR、审计记录、deployment record、支持工单和事故时间线里。它是一个稳定的证人。
这让它不只是“能点开的链接”。它可以绑定：
- source revision；
- image digest 或 static artifact manifest digest；
- config snapshot；
- deployment attempt；
- route behavior；
- health 或 access readback；
- retention 和 cleanup policy。
如果这个 URL 后来指向 deployment B，它就不再是证据了。上周验证通过的 preview，今天可能已经显示了新的代码。bug report 变得不可复现。AI agent 说自己验证了部署，实际检查的却是一个已经移动过的 alias。
这条规则很朴素，也很重要：immutable URL 不跟随 latest。
Alias 是产品入口
Mutable alias 解决的是另一个问题。
用户不想每次发布都记一条新的 deployment URL。团队需要稳定的项目 URL、生产 URL 或环境 URL，指向当前选中的版本。这个 URL 本来就应该可以移动。
但移动要留下记录。
一个 production alias 至少应该知道：
- 当前 active target 是谁；
- 上一个 target 是谁；
- 谁或哪个流程移动了它；
- 为什么移动；
- 这次移动是 promotion、rollback、manual repair，还是 automated recovery；
- 移动后 readback 是否通过。
Alias 可以变，但不应该悄悄变。如果生产入口因为 rollback 指回了一个旧的 verified artifact，这不是奇怪的副作用，而是部署状态的一部分。
这也是 alias 和 immutable URL 互相配合的地方。Alias 给用户一个正常入口。Immutable URL 给控制面一个稳定 target，用来 promote、比较、检查和回滚。
Custom domain 多了所有权承诺
Custom domain 是第三种承诺。
它不只是“这个 route 指向这次部署”，还意味着“这个用户有权绑定这个 hostname”。平台必须处理 ownership verification、冲突、TLS、禁用状态和 takeover prevention。
项目请求绑定一个域名，不应该直接激活。系统需要证据证明当前 owner 控制这个域名或 hostname。如果域名被移除或转移，平台不应该永远复用旧证明。如果两个 resource 想要同一个 hostname 或 path，默认应该 fail closed。
这些安全工作会比一句 CNAME 指引重一些。但另一种结果更糟：过期验证、错误绑定、或 owner 以为已经关闭的 route 还在继续服务旧 target。
更清楚的模型是：
- 平台拥有的 default route 来自平台 route provider；
- 用户拥有的 custom domain 必须有用户侧所有权验证；
- Enterprise 或 private deployment 可以替换成自己的内部 DNS 或 wildcard provider；
- public core 只保留中性语言，hosted Cloud 的策略和 provider 细节留在 Cloud layer。
用户不需要为了部署读完这些细节。系统内部仍然要区分清楚。
被 block 的 route 应该安静
还有一种 URL 状态经常被忽略：blocked 或 disabled。
当 route 被 block、过期、暂停或移除时，响应应该是安全的。它不应该泄露之前的 target、deployment id、bucket path、内部 host、provider account，或者像 secret 的诊断信息。它也不应该被缓存成“看起来还活着”的旧状态。
这关系到 abuse 处理、preview 过期、账号恢复、支持操作和普通清理。
一个不再服务应用的 route 也有产品契约。它应该表达的是：这个 route 当前不可用，而且旧 target 不会在这里暴露。
平时看起来是小事。等到一个已经禁用的 preview 还在泄露内部构建，或者一个被 block 的 route 还暴露 workload 位置时，就不小了。
AI agent 也需要 URL 语义
AI agent 很擅长把“部署这个”拆成一串命令。它也很容易过度相信浅层信号。
如果 agent 拿到一个 URL，并且看到 200 OK，它可能会直接汇报成功。但成功取决于 URL class。
如果是 immutable deployment URL，agent 应该问：这个 URL 是否指向刚刚创建的那个 deployment 或 artifact？
如果是 production alias，它应该问：alias 是否移动到了预期的 verified target？rollback 证据是否存在？
如果是 custom domain，它应该问：ownership 是否验证？TLS/readiness 是否完成？有没有 hostname 冲突？
如果是 blocked 或 expired route，它应该问：route 是否安全失败，并且没有暴露旧 target？
这些问题也是人类 operator 需要的。Agent 不应该拥有一条私有捷径，把“URL 能访问”粗暴等同于“部署成功”。
Routing 也是 rollback 的一部分
Rollback 常被描述成 runtime 动作：切 image、重启服务、恢复配置。
对用户能访问的系统来说，rollback 也是 routing 动作。公开入口必须指回一个 verified target。如果平台没有区分 URL 类型，rollback 也会变得含糊。
一条更安全的 rollback record 可以写清楚：
- production alias 从 target
B移回 targetA； - target
A之前已经验证过； - config snapshot 符合 rollback plan；
- 指针移动后 route readback 通过；
- cache purge 或 provider readback 是 verified、deferred，还是 blocked；
- 两个 target 的 immutable URL 仍然稳定。
这比“我们重新部署了一次旧版本”更容易推理，也避免为了恢复 route 而重新构建旧 artifact。如果 verified artifact 和 route target 已经存在，rollback 可以是一次受控的 pointer move，再加 readback。
代价是要多命名几个东西
这个模型有成本。你得给更多东西命名。
Immutable deployment URL。Mutable project alias。Production alias。Custom domain binding。Blocked route。Route activation。Route readback。Retention。Cleanup。
这比一个 url 字段重。
好处是每个 surface 都能更诚实。Web Console 可以把 preview 和 production 标清楚。CLI 可以返回结构化 route state。GitHub Actions workflow 可以验证正确类型的链接。AI agent 不会检查错 URL 后就宣布成功。支持团队排查时可以要 immutable URL，确认用户入口时可以看 alias。
产品体验仍然可以简单。用户可以只点一个链接。控制面应该知道这个链接承诺了什么。
好 URL 会少留很多疑问
部署里有很多会动的部分：source、artifact、config、route、domain、TLS、health check、cache、log、rollback target。返回给用户的 URL 刚好坐在这些东西的边缘。
所以它需要更清楚的契约。
Immutable URL 应该是稳定证据。Alias 可以移动，但要有审计。Custom domain 要有所有权证明。Blocked route 要隐藏旧 target。Rollback 应该把已知 route 移向 verified target，而不是希望复制一条旧命令就能还原过去。
目标不是为了显得专业而增加术语。目标是让最后那条链接少一点歧义。当人、workflow、支持团队或 AI agent 打开一个 deploy URL 时，他们应该知道自己正在看哪一种承诺。