用途：按“本地代码→Preview→发布→公开 URL”的顺序定位 Replit 首个失败边界，在排查时保留生产状态，并依据当前 Replit 文档而非旧套餐名或旧部署控件。
主要能力：区分 Preview 空白/不可达、发布构建失败、发布进程反复重启、健康检查失败、生产 Secret 缺失、数据库仅 Preview 可用、重新发布后上传文件丢失、登录仅 Preview 成功、静态部署无法访问 API、公开 URL 仍显示旧版本等场景，并给出对应检查点。
使用方式：先复现最小失败动作且不改配置；Preview 失败时检查运行命令、依赖安装、服务器日志与端口绑定；Preview 正常但发布失败时检查发布构建/运行命令、生产 Secrets、长驻进程与健康检查时序；发布成功但公开 URL 失败时对比生产回调、数据库配置、CORS/API 白名单、持久化存储、访问策略与浏览器行为。用 Read 看配置、Grep 找调用点，不要导出环境变量、原始请求体、会话 Cookie 或完整日志。每次只改一个有界原因，经批准后再发布，并验证原故障与核心用户旅程。
关键限制：发布文件系统不跨版本持久，结构化数据应放 Replit Database、文件放 App Storage；静态部署仅适合纯客户端文件，含服务端路由、认证回调、数据库或后台逻辑需 Autoscale 或 Reserved VM；不要把 Secret 移入客户端代码；不要靠打印 process.env 排查；不要关闭 TLS 证书校验；健康检查要求首页在五秒内响应；涉及成本、访问、DNS、生产数据或部署类型的修复需明确批准。若无法复现或遇平台事件，保留时间戳与监控证据，避免推测性改配置。