Back to Details

win

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

WIN: Complete Coverage Framework

WIN: 全覆盖框架

Core Rule: Before writing any code, enumerate what could go wrong. Before calling anything done, verify nothing was missed. Before saying "looks good", prove every path is covered.
核心规则：编写任何代码前，列举所有可能出错的情况。在宣告完成前，验证无任何遗漏。在说“看起来没问题”前，证明所有路径都已覆盖。

PHASE 1: PLANNING — Think Like an Attacker

阶段1：规划——以攻击者思维思考

When planning any feature, fix, or change, work through every section below. If a section doesn't apply, explicitly state why.
在规划任何功能、修复或变更时，逐一梳理以下每个部分。若某个部分不适用，请明确说明原因。

1.1 Input Space Analysis

1.1 输入空间分析

For every input the feature accepts (user input, API params, DB data, URL params, file uploads, environment variables):
  • Valid inputs: What are all the valid forms? (types, ranges, formats)
  • Boundary values: Empty string, 0, -1, MAX_INT, max length, min length, exactly-at-limit
  • Invalid inputs: Wrong type, null, undefined, NaN, Infinity, empty array, nested nulls
  • Malicious inputs: SQL injection, XSS payloads, path traversal, oversized payloads, unicode edge cases (ZWJ, RTL, emoji)
  • Concurrent inputs: Same user submitting twice, race between two users, stale data
针对功能接受的每一类输入（用户输入、API参数、数据库数据、URL参数、文件上传、环境变量）：
  • 有效输入：所有合法形式有哪些？（类型、范围、格式）
  • 边界值：空字符串、0、-1、MAX_INT、最大长度、最小长度、刚好达到限制值
  • 无效输入：错误类型、null、undefined、NaN、Infinity、空数组、嵌套null
  • 恶意输入：SQL injection、XSS payloads、路径遍历、超大负载、Unicode边缘情况（ZWJ、RTL、表情符号）
  • 并发输入：同一用户重复提交、两名用户间的竞争条件、过期数据

1.2 State Space Analysis

1.2 状态空间分析

Map every state the system can be in during and after this change:
  • Loading states: Initial load, refresh, pagination, background sync
  • Empty states: No data yet, data deleted, filtered to nothing
  • Error states: Network failure, auth expired, rate limited, server 500, partial failure
  • Success states: Single result, many results, exactly-at-limit results
  • Transition states: Optimistic update that rolls back, concurrent modification, mid-operation failure
  • Stale states: Cached data that's outdated, browser tab left open, websocket disconnected
梳理此变更过程中及变更后系统可能处于的所有状态：
  • 加载状态：初始加载、刷新、分页、后台同步
  • 空状态：尚无数据、数据已删除、过滤后无结果
  • 错误状态：网络故障、认证过期、速率限制、服务器500错误、部分失败
  • 成功状态：单一结果、多个结果、刚好达到限制数量的结果
  • 转换状态：乐观更新后回滚、并发修改、操作中途失败
  • 过期状态：已过时的缓存数据、长时间打开的浏览器标签、WebSocket断开连接

1.3 Failure Mode Analysis

1.3 故障模式分析

For every external dependency (API call, DB query, file read, third-party service):
  • What if it's slow (5s, 30s, timeout)?
  • What if it fails (network error, 500, malformed response)?
  • What if it returns unexpected data (empty, wrong shape, extra fields, null where not expected)?
  • What if it partially succeeds (3 of 5 items saved, then crash)?
  • What if the user retries while the first attempt is still in-flight?
  • What is the recovery path? Can the user retry? Is the data left in a consistent state?
针对每一个外部依赖（API调用、数据库查询、文件读取、第三方服务）：
  • 如果它响应缓慢（5秒、30秒、超时）会怎样？
  • 如果它调用失败（网络错误、500错误、格式错误的响应）会怎样？
  • 如果它返回意外数据（空结果、错误结构、多余字段、非预期的null）会怎样？
  • 如果它部分成功（5个项目中保存了3个，然后崩溃）会怎样？
  • 如果用户在首次请求仍在处理时重试会怎样？
  • 恢复路径是什么？用户能否重试？数据是否会保持一致状态？

1.4 Security Threat Model

1.4 安全威胁模型

  • Authentication: Can this be accessed without login? With an expired token?
  • Authorization: Can user A access user B's data? Can a free user access pro features?
  • Data exposure: Are we returning more fields than the client needs? PII in logs?
  • Injection: Any string concatenation in SQL, HTML, or shell commands?
  • Rate limiting: Can this endpoint be abused? Is there a cost multiplier (e.g., triggers expensive AI call)?
  • 认证：无需登录即可访问吗？使用过期令牌可以访问吗？
  • 授权：用户A能否访问用户B的数据？免费用户能否访问专业版功能？
  • 数据泄露：我们返回的字段是否超出客户端需求？日志中是否包含个人身份信息（PII）？
  • 注入攻击：SQL、HTML或Shell命令中是否存在字符串拼接？
  • 速率限制：此端点是否可能被滥用？是否存在成本乘数（例如触发昂贵的AI调用）？

1.5 Assumption Discovery

1.5 假设发现

Before building or fixing anything, step back from the immediate task and ask: what is the current context assuming?
  • Identify every assumption the current task, test case, or bug report is making about who uses this, what data they provide, how they use it, and in what context
  • Challenge each assumption: What if a real user doesn't match this assumption? What breaks, degrades, or behaves unexpectedly?
  • Enumerate what SHOULD work but isn't being considered — scenarios, user types, data types, or contexts beyond the one in front of you right now
  • Enumerate what should NOT work — scenarios the app should explicitly reject, block, or handle gracefully. Are they actually handled, or would they silently break or accidentally be allowed?
Do not use a predefined checklist. The assumptions are different for every app and every feature. You must discover them from the specific context you're working in.
在构建或修复任何内容之前，暂时脱离当前任务，思考：当前上下文存在哪些假设？
  • 识别所有假设：当前任务、测试用例或Bug报告针对用户群体、提供的数据、使用方式及使用场景所做出的所有假设
  • 质疑每个假设：如果真实用户不符合该假设，会出现什么问题？哪些功能会崩溃、降级或表现异常？
  • 列举本应支持但未被考虑的场景——超出当前任务范围的场景、用户类型、数据类型或上下文
  • 列举本应被禁止的场景——应用应明确拒绝、阻止或优雅处理的场景。这些场景是否真的被处理了？还是会静默崩溃或被意外允许？
请勿使用预定义的检查清单。每个应用和功能的假设都不同，你必须从当前工作的特定上下文中发现它们。

1.6 Impact Analysis

1.6 影响分析

  • What existing features could this break? Trace all callers and consumers.
  • What data could this corrupt? Check migration safety, default values, nullable columns.
  • What performance could this degrade? New queries without indexes? N+1? Large payloads?
  • What's the rollback plan? If this goes wrong in production, how do we undo it?
  • 此变更可能会破坏哪些现有功能？ 追踪所有调用方和消费者。
  • 此变更可能会损坏哪些数据？ 检查迁移安全性、默认值、可为空的列。
  • 此变更可能会降低哪些性能？ 新增的查询是否无索引？是否存在N+1问题？是否有大负载？
  • 回滚计划是什么？ 如果在生产环境中出现问题，我们如何撤销变更？

1.7 Plan Completeness Checklist

1.7 规划完备性检查清单

Before finalizing any plan, verify:
  1. Every user-facing state is accounted for (loading, empty, error, success, partial)
  2. Every external call has error handling specified
  3. Every input has validation rules defined
  4. Edge cases are explicitly listed (not "handle edge cases" — LIST them)
  5. The testing strategy covers more than just the happy path
  6. Performance implications are noted for any new queries or API calls
  7. Security implications are noted for any new endpoints or data access
  8. Migration safety is confirmed (no data loss, backwards compatible)
  9. Assumptions about users, data, and context have been identified and challenged
在最终确定任何计划前，验证：
  1. 所有面向用户的状态都已覆盖（加载、空、错误、成功、部分成功）
  2. 每个外部调用都已指定错误处理方式
  3. 每个输入都已定义验证规则
  4. 边缘情况已明确列出（不是“处理边缘情况”——要列出具体情况）
  5. 测试策略不仅覆盖正常路径
  6. 已注明新增查询或API调用对性能的影响
  7. 已注明新增端点或数据访问的安全影响
  8. 已确认迁移安全性（无数据丢失、向后兼容）
  9. 已识别并质疑针对用户、数据和上下文的假设

PHASE 2: IMPLEMENTATION — Defensive by Default

阶段2：实现——默认防御式编程

2.1 Error Handling Rules

2.1 错误处理规则

  • Every 
    await
    gets error handling     — no unhandled promise rejections
  • Every API/DB client call checks for errors before accessing response data
  • Every array index access is bounds-checked — 
    array[i]
    needs 
    if (i < array.length)
  • Every optional chain has a fallback — what happens when the value IS nullish?
  • Network errors get user-facing messages — not silent failures or console.log only
  • Partial failure states are handled — if step 2 of 3 fails, what happens to step 1's data?
  • 每个
    await
    都需处理错误    ——不允许未处理的Promise拒绝
  • 每次API/数据库客户端调用都需在访问响应数据前检查错误
  • 每个数组索引访问都需进行边界检查——
    array[i]
    需要搭配
    if (i < array.length)
  • 每个可选链都需有回退方案——当值为nullish时会怎样？
  • 网络错误需提供面向用户的提示信息——不能静默失败或仅在控制台打印日志
  • 处理部分失败状态——如果三步操作中的第二步失败，第一步的数据会怎样？

2.2 UI State Coverage

2.2 UI状态覆盖

For every component that displays data, implement ALL states:
  • Loading: Skeleton or spinner (not blank screen)
  • Empty: Helpful message with action (not blank screen)
  • Error: Specific message with retry option (not generic "Something went wrong")
  • Success: The actual content
  • Partial: Some data loaded, some failed (don't hide the successes)
  • Stale: Visual indicator if data might be outdated
针对每个展示数据的组件，实现所有状态：
  • 加载中：骨架屏或加载动画（而非空白屏幕）
  • 空状态：带有操作指引的友好提示（而非空白屏幕）
  • 错误状态：具体提示信息及重试选项（而非通用的“出了点问题”）
  • 成功状态：实际内容
  • 部分加载状态：部分数据已加载，部分加载失败（不要隐藏已成功加载的内容）
  • 过期状态：如果数据可能已过时，需提供视觉提示

2.3 Implementation Completeness Check

2.3 实现完备性检查

After writing each piece of code, verify:
  1. What happens if called with null? undefined? empty string? empty array?
  2. What happens if the network call fails? Times out? Returns unexpected shape?
  3. What happens if the user navigates away mid-operation?
  4. What happens if two users do this simultaneously?
  5. Did I handle the error path in the UI, not just console.log it?
  6. Am I exposing any data the user shouldn't see?
  7. Is this implementation built around assumptions from the current test case? Would it break for a user in a different context?
  8. Are unsupported or invalid scenarios explicitly handled (clear rejection, error message), or will they silently fail or accidentally be allowed?
在编写完每一段代码后，验证：
  1. 如果传入null、undefined、空字符串、空数组会怎样？
  2. 如果网络调用失败、超时、返回意外结构会怎样？
  3. 如果用户在操作中途导航离开会怎样？
  4. 如果两名用户同时执行此操作会怎样？
  5. 我是否在UI中处理了错误路径，而不只是在控制台打印日志？
  6. 我是否暴露了用户不应看到的数据？
  7. 此实现是否基于当前测试用例的假设？对于处于不同上下文的用户，它会崩溃吗？
  8. 不支持或无效的场景是否已被明确处理（明确拒绝、错误提示），还是会静默失败或被意外允许？

PHASE 3: TESTING — Prove It Works, Then Prove It Fails Gracefully

阶段3：测试——先证明功能可用，再证明故障时可优雅处理

3.1 Test Categories (ALL Required)

3.1 测试类别（全部必填）

For every feature or fix, address each category:
Happy Path Tests
  • Basic functionality works with typical inputs
  • Verify the exact output/behavior, not just "no errors"
Input Boundary Tests
  • Empty inputs (empty string, empty array, null, undefined)
  • Minimum valid input (1 character, single item)
  • Maximum valid input (at the limit)
  • Just over the limit (should reject gracefully)
  • Special characters, unicode, very long strings
Error Path Tests
  • Network failure during operation
  • Auth token expired mid-session
  • Invalid data from API (missing fields, wrong types)
  • Database constraint violations (duplicate key, foreign key)
  • Rate limit hit
State Transition Tests
  • Component handles loading → success correctly
  • Component handles loading → error → retry → success
  • State is consistent after error recovery
  • Back button / navigation during async operation
Security Tests
  • Unauthorized access returns 401/403, not 500
  • Cross-user data access is blocked
  • SQL/XSS payloads in inputs are handled safely
  • Sensitive data isn't leaked in error messages
Assumption Tests
  • Test with scenarios beyond the immediate test case — different types of users, data, or contexts the feature should support
  • Test scenarios that should NOT work — verify they are properly rejected with clear feedback, not silently broken or accidentally allowed
Regression Tests
  • Existing functionality still works after the change
  • Related features aren't broken by side effects
针对每个功能或修复，覆盖以下每一类测试：
正常路径测试
  • 基础功能在典型输入下可正常工作
  • 验证确切的输出/行为，而非仅“无错误”
输入边界测试
  • 空输入（空字符串、空数组、null、undefined）
  • 最小有效输入（1个字符、单个条目）
  • 最大有效输入（达到限制值）
  • 略超过限制值（应优雅拒绝）
  • 特殊字符、Unicode、超长字符串
错误路径测试
  • 操作过程中网络故障
  • 会话中途认证令牌过期
  • API返回无效数据（缺失字段、错误类型）
  • 数据库约束违反（重复键、外键错误）
  • 触发速率限制
状态转换测试
  • 组件可正确处理加载→成功的转换
  • 组件可正确处理加载→错误→重试→成功的流程
  • 错误恢复后状态保持一致
  • 异步操作期间点击返回按钮/导航
安全测试
  • 未授权访问返回401/403，而非500
  • 跨用户数据访问被阻止
  • 输入中的SQL/XSS payloads被安全处理
  • 敏感数据未在错误提示中泄露
假设验证测试
  • 测试超出当前测试用例的场景——功能应支持的不同用户类型、数据或上下文
  • 测试本应被禁止的场景——验证它们被正确拒绝并给出明确反馈，而非静默崩溃或被意外允许
回归测试
  • 变更后现有功能仍可正常工作
  • 相关功能未因副作用而崩溃

3.2 Testing Completeness Check

3.2 测试完备性检查

Verify before moving on:
  1. Every public function/endpoint has at least one happy path test
  2. Every error code/message returned has a test that triggers it
  3. Every conditional branch in the code is exercised by a test
  4. Boundary values for every input are tested
  5. The test suite would CATCH a regression if someone broke this feature
在进入下一阶段前验证：
  1. 每个公共函数/端点至少有一个正常路径测试
  2. 返回的每个错误代码/提示都有对应的触发测试
  3. 代码中的每个条件分支都有测试覆盖
  4. 每个输入的边界值都已测试
  5. 如果有人破坏此功能，测试套件能够捕获回归问题

PHASE 4: ANALYSIS & REVIEW — Audit Like a Senior Engineer

阶段4：分析与评审——以资深工程师的视角审计

When analyzing existing code, reviewing a feature, investigating a bug, or auditing for improvements, apply this systematic framework. Do NOT give surface-level "looks fine" answers.
在分析现有代码、评审功能、排查Bug或审计优化点时，应用此系统化框架。请勿给出“看起来没问题”这类表面化的结论。

4.1 Existing Code Audit

4.1 现有代码审计

When asked to analyze or review existing code:
  • Read the full flow, not just the file mentioned — trace the data from entry point to database and back
  • Map every conditional branch — is every if/else/switch case handled? Are there missing cases?
  • Check every external call — does each API/DB/service call have proper error handling?
  • Identify silent failures — places where errors are caught but swallowed (empty catch blocks, 
    .catch(() => {})
    , missing error states in UI)
  • Check null/undefined paths — what happens when optional data is actually missing? Is the code assuming data always exists?
  • Verify auth boundaries — is every endpoint/query properly scoped to the authenticated user?
  • Challenge assumptions — is this code built on assumptions about who uses it, what data they provide, or in what context? Would it break for someone in a different situation?
当需要分析或评审现有代码时：
  • 通读完整流程，而非仅查看提及的文件——追踪数据从入口点到数据库再返回的完整路径
  • 梳理所有条件分支——每个if/else/switch分支是否都已处理？是否存在遗漏的分支？
  • 检查每个外部调用——每个API/数据库/服务调用是否有适当的错误处理？
  • 识别静默失败——捕获错误但未处理的地方（空catch块、
    .catch(() => {})
    、UI中缺失错误状态）
  • 检查null/undefined路径——当可选数据实际缺失时会怎样？代码是否假设数据始终存在？
  • 验证认证边界——每个端点/查询是否都已正确限定给已认证用户？
  • 质疑假设——此代码是否基于对用户群体、提供的数据或使用场景的假设？对于处于不同场景的用户，它会崩溃吗？

4.2 Bug Investigation

4.2 Bug排查

When investigating a bug or unexpected behavior:
  • Reproduce the full path — don't guess. Trace the exact code path from trigger to symptom
  • Check ALL callers — if the bug is in a shared function, who else calls it? Are they affected too?
  • Look for the systemic cause — a bug in one place often indicates the same pattern elsewhere. Search for similar patterns in the codebase
  • Identify what ELSE could break — fixing the immediate bug is not enough. What related code has the same vulnerability?
  • Check data integrity — has the bug corrupted any existing data? Does the fix need a data migration or backfill?
  • Verify the fix prevents recurrence — will this same bug happen again for new users, new data, or new features? If yes, fix the root cause, not the symptom
  • Challenge the assumption that caused the bug — did this bug exist because the code assumed a specific type of user, data, or context? Does the fix hold for all real-world scenarios, not just the reported case?
在排查Bug或意外行为时：
  • 复现完整路径——不要猜测。追踪从触发点到症状的确切代码路径
  • 检查所有调用方——如果Bug出现在共享函数中，还有谁在调用它？他们是否也受影响？
  • 寻找系统性原因——一处的Bug通常表明其他地方也存在相同模式。在代码库中搜索类似模式
  • 识别其他可能受影响的部分——修复当前Bug还不够。哪些相关代码存在相同漏洞？
  • 检查数据完整性——此Bug是否已损坏现有数据？修复是否需要数据迁移或回填？
  • 验证修复可防止复发——对于新用户、新数据或新功能，此Bug是否会再次出现？如果是，修复根本原因而非症状
  • 质疑导致Bug的假设——此Bug是否因代码对用户类型、数据或上下文的假设而产生？修复是否适用于所有真实场景，而非仅报告的案例？

4.3 Feature Improvement Analysis

4.3 功能优化分析

When asked to improve or optimize an existing feature:
  • Benchmark the current state — what's the actual performance/behavior now? Don't optimize blindly
  • Identify ALL consumers — who depends on this feature? Will improvements break any downstream consumers?
  • Check for unhandled edge cases in the current implementation:
    • What inputs/states does the current code NOT handle?
    • What error paths are missing or incomplete?
    • Are there race conditions or timing issues?
    • Does it degrade gracefully under load?
  • Assess the blast radius — how many files, functions, and features does this change touch?
  • Propose with tradeoffs — every improvement has a cost (complexity, performance, migration). State the tradeoffs explicitly
  • Check assumption coverage — does the current implementation only handle the scenario it was built and tested with, or does it account for the full range of real-world usage?
当需要优化现有功能时：
  • 基准测试当前状态——当前的实际性能/行为如何？不要盲目优化
  • 识别所有消费者——谁依赖此功能？优化是否会破坏下游消费者？
  • 检查当前实现中未处理的边缘情况：
    • 当前代码未处理哪些输入/状态？
    • 哪些错误路径缺失或不完整？
    • 是否存在竞争条件或时序问题？
    • 高负载下是否能优雅降级？
  • 评估影响范围——此变更会涉及多少文件、函数和功能？
  • 提出带权衡的方案——每项优化都有成本（复杂度、性能、迁移）。明确说明权衡点
  • 检查假设覆盖范围——当前实现是否仅处理了其构建和测试时的场景，还是覆盖了所有真实使用场景？

4.4 Architecture Review

4.4 架构评审

When reviewing system design or architecture:
  • Data flow completeness — trace data from user input through every layer to storage and back. Are there gaps?
  • Error propagation — when something fails deep in the stack, does the error surface correctly to the user? Or does it get lost?
  • Consistency guarantees — if a multi-step operation fails halfway, is the system in a valid state?
  • Scaling bottlenecks — what happens at 10x current load? 100x? Where does it break first?
  • Dependency risks — what happens if a third-party service goes down? Is there a fallback?
  • Security surface area — every new endpoint, every new data flow is an attack surface. Map them all
在评审系统设计或架构时：
  • 数据流完整性——追踪数据从用户输入到每一层再到存储并返回的完整路径。是否存在缺口？
  • 错误传播——当栈深处发生故障时，错误是否能正确呈现给用户？还是会丢失？
  • 一致性保障——如果多步操作中途失败，系统是否处于有效状态？
  • 扩展瓶颈——当前负载提升10倍、100倍时会怎样？哪里会先崩溃？
  • 依赖风险——如果第三方服务宕机会怎样？是否有 fallback 方案？
  • 安全攻击面——每个新端点、每个新数据流都是一个攻击面。梳理所有攻击面

4.5 Analysis Completeness Check

4.5 分析完备性检查

Before delivering any analysis or review, verify:
  1. I traced the complete data flow, not just the surface-level code
  2. I identified edge cases the current code does NOT handle
  3. I checked for the same pattern/bug elsewhere in the codebase
  4. I assessed security implications (auth, data exposure, injection)
  5. I considered performance under stress (concurrent users, large data)
  6. I noted specific file:line references for every finding
  7. My recommendations include tradeoffs, not just "do this"
  8. I answered "will this happen again?" and addressed recurrence prevention
在提交任何分析或评审结果前，验证：
  1. 我已追踪完整的数据流，而非仅表层代码
  2. 我已识别当前代码未处理的边缘情况
  3. 我已在代码库中检查是否存在相同模式/Bug
  4. 我已评估安全影响（认证、数据泄露、注入）
  5. 我已考虑高压力下的性能（并发用户、大数据）
  6. 我已为每个发现标注具体的文件:行号引用
  7. 我的建议包含权衡点，而非仅“做这件事”
  8. 我已回答“此问题会再次发生吗？”并给出预防复发的方案

PHASE 5: FINAL VERIFICATION — The "Ship It" Checklist

阶段5：最终验证——“上线”检查清单

Before declaring ANY task complete, verify every item:
在宣告任何任务完成前，验证以下所有项：

Code Quality

代码质量

  1. TypeScript compiles with zero errors
  2. No lint warnings
  3. No 
    any
    types, no 
    @ts-ignore
    , no 
    eslint-disable
    added
  4. No console.log/debug statements left in
  5. No hardcoded values that should be constants or config
  1. TypeScript编译无错误
  2. 无Lint警告
  3. 未新增
    any
    类型、
    @ts-ignore
    或
    eslint-disable
  4. 无残留的console.log/调试语句
  5. 无应改为常量或配置的硬编码值

Functional Completeness

功能完备性

  1. Every requirement from the original request is addressed
  2. Every edge case identified in planning has code handling it
  3. Error states have user-facing feedback, not just thrown exceptions
  4. The feature works on first use, not just happy path demo
  5. The feature works beyond the specific scenario it was built and tested with — assumptions have been identified and addressed
  1. 原始需求中的每一项都已覆盖
  2. 规划阶段识别的每一个边缘情况都有代码处理
  3. 错误状态有面向用户的反馈，而非仅抛出异常
  4. 功能首次使用即可正常工作，而非仅在正常路径演示中可用
  5. 功能可在其构建和测试场景之外正常工作——已识别并处理相关假设

Safety

安全性

  1. No new security vulnerabilities (check OWASP top 10)
  2. No data leaks in API responses or error messages
  3. Auth/authz is enforced on every new endpoint
  4. Database migrations are backwards compatible and reversible
  1. 无新增安全漏洞（检查OWASP Top 10）
  2. API响应或错误提示中无数据泄露
  3. 每个新端点都已强制执行认证/授权
  4. 数据库迁移向后兼容且可回滚

Resilience

韧性

  1. External service failures are handled gracefully
  2. User can recover from errors without refreshing the page
  3. Data integrity is maintained even if operations are interrupted
  4. No race conditions in concurrent access scenarios
  1. 外部服务故障可被优雅处理
  2. 用户无需刷新页面即可从错误中恢复
  3. 即使操作被中断，数据完整性仍可保持
  4. 并发访问场景中无竞争条件