工作流边界
PR preview 不是默认开启的隐式行为。仓库需要自己声明触发事件、权限、secret 和目标部署路径。
GitHub PR preview
让 pull request 触发可检查的 preview deployment。
PR preview 需要用户显式写 workflow。Appaloft 的职责是让部署路径、preview URL、状态、日志、清理和恢复信息可追踪，而不是偷偷替你修改仓库策略。
preview workflow 必须显式订阅 pull_request 事件
close cleanup 使用单独 workflow，避免预览环境长期残留
需要 secret 时只引用 GitHub Secrets 名称，不打印值
状态反馈
成功后返回 preview URL、deployment id 和检查状态；失败时返回日志和诊断，不把失败包装成成功。
清理策略
PR close 或 merge 后应触发清理 workflow。若清理失败，需要明确提示人工 cleanup 缺口。
部署流程
1
添加 preview workflow
在仓库里声明 pull_request 触发的部署 workflow。
2
配置 secrets
把 SSH key、server、token 等放进 GitHub Secrets。
3
添加 cleanup workflow
为 pull_request close 事件准备单独清理路径。
相关主题
继续沿着同一条部署路径看。
Appaloft 的 SEO 页面按真实部署任务组织。每个主题页都应该把用户带到下一步，而不是停在孤立介绍。
GitHub deployment
用 GitHub Actions 把仓库事件接到 Appaloft 部署路径，并保留显式 workflow。
AI deployment
让 agent 先识别项目形态，再选择 skill、CLI、静态发布或 Cloud 控制台路径。
Own server deployment
把控制面、CLI、服务器、回滚和 Cloud 协作边界连在同一个自部署主题里。
Static site publishing
从 build 输出、浏览器上传、CLI 部署到一键部署按钮，覆盖静态站点的主要入口。