resilience-review 用于评估应用在出错时的表现，例如网络失败、API 错误、慢连接、缺失数据和边界情况。资料称其聚焦于多数应用未覆盖的“非理想路径”。
适用时机：上线面向用户的功能前；新增 API 集成或数据源后；可靠性关键场景（医疗、金融、电商结算）；因未处理错误导致生产事故后；从原型转向生产质量时。引用的标准包括 Google SRE、Netflix 混沌工程、OWASP 错误处理、Nielsen Norman Group 错误信息可用性启发式。
流程分为五阶段：1 教育（说明韧性重要性）；2 范围（从代码库自动检测 API 调用、错误边界、加载态、空状态、重试逻辑、离线支持、第三方依赖，并向用户询问目标 URL、关键流程、关键 API、脆弱区域，映射失败点）；3 分析（用 new_session 并设 record_evidence: true，在浏览器中做故障注入与边界测试）；4 报告（保存到 shiplight/reports/resilience-review-{date}.md，含总分、分类评分、失败矩阵、发现与证据）；5 修复（给出修复指导与 YAML 回归测试，保存到 shiplight/tests/resilience-review.test.yaml）。
检查分五类：ERR 错误处理（如 500 友好提示、超时状态、404 页、JS 错误不崩溃、可操作错误信息、不暴露技术细节、表单验证、可重试、并发错误、日志不含 PII）；DEG 优雅降级（禁用 JS、慢速 3G、第三方脚本失败、离线、图片/字体失败、特性检测）；EDGE 空与边界状态（空数据提示、零结果分页、长文本、特殊字符、大数据、重复提交、前进后退、刷新、多标签、超大文件）；API 契约与数据处理（各 HTTP 码、null/undefined、空集合、错误类型、加载态、竞态、限流、会话过期）；REC 恢复与沟通（自动重试、手动重试、进度不丢、降级告知、恢复操作清晰、后台状态）。
用法要点：使用 page.route() 在 description: 与 js: 语句中拦截请求模拟失败；用 get_browser_console_logs 检查未捕获的 Promise 拒绝；用 act 交互；用 close_session 关闭会话并用 generate_html_report 生成证据。置信度低于 50% 不报告。限制：资料未提供具体价格、平台或运行环境要求。