Back to Details

fix

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fix a Bug

修复 Bug

$ARGUMENTS
names what is broken — an error message, a stack trace, a class, or a description of the wrong behaviour. When you cannot tell from it what the right behaviour would be, ask the user before you start.
$ARGUMENTS
指明出了什么问题——可以是错误消息、堆栈跟踪、class，或对异常行为的描述。如果无法从中判断正确的行为，应在开始前询问用户。

1. Prove the cause

1. 证明根因

Call the 
diagnosing-bugs
skill and hold its loop: one command you have already run that goes red on this bug and will go green once it is fixed.
Then name the cause — the line the symptom comes from and why it produces it — and quote the code or the diff that proves it. A cause the red loop has not confirmed is a guess; keep digging until the two agree.
Done when you can paste the red command with its output and state the cause in one sentence.
调用 
diagnosing-bugs
skill，并贯彻其循环：运行一个你已经执行过的命令，该命令会针对此 Bug 变红，并在修复后变绿。
然后明确指出根因——症状源自哪一行代码，以及该行代码为何会产生这一症状——并引用能够证明根因的代码或 diff。未被失败循环确认的根因只是猜测；继续排查，直到二者一致。
当你能够粘贴失败命令及其输出，并用一句话陈述根因时，即完成。

2. Carry the smallest fix

2. 实施最小修复

Turn the repro into a regression test where a seam reaches the real bug, watch it go red, then fix. When no such seam exists, say so and fix without one.
Hold to the cause you named — a bug fix stays small. What you notice on the way that is not this bug goes to the user as a note, not into the diff.
Name the project from its root marker and keep its checks green alongside the tests, after every change.
ProjectKeep running
Laravel — 
artisan
in the root		Larastan / PHPStan, Pint; the type check when you touched Vue / TypeScript
Flutter — 
pubspec.yaml
in the root
flutter analyze
Done when the loop that was red is green, the whole suite has run green once, and every class, variable, and function your change orphaned is gone.
将 repro 转化为回归测试，使测试 seam 能够触达真实 Bug，观察测试变红，然后再进行修复。如果不存在这样的 seam，就明确说明，并在没有该 seam 的情况下完成修复。
严格围绕已指出的根因——Bug 修复必须保持最小。过程中发现但与本 Bug 无关的问题，应作为 note 告知用户，不要纳入 diff。
根据根目录 marker 识别项目，并在每次变更后，让 checks 与 tests 一起保持通过状态。
项目保持运行
Laravel——根目录中有 
artisan
Larastan / PHPStan、Pint；触及 Vue / TypeScript 时运行类型检查
Flutter——根目录中有 
pubspec.yaml
flutter analyze
当原本失败的循环变为通过、完整测试套件至少完整运行一次并全部通过，且你的改动所遗留的每个孤立 class、variable 和 function 都已清理时，即完成。

3. Review what you touched

3. 审查改动的部分

Call 
solid-check
on the classes or namespaces you touched, and work its report to empty.
  • A break your own fix brought in — carry the fix, then run the check again
  • A break that was there before you started — tell the user and ask; a bug fix stays small, so the refactor is theirs to call
Done when every finding is accounted for: fixed, or raised with the user.
对触及的 class 或 namespace 调用 
solid-check
，并处理其报告，直到没有任何问题。
  • 如果是你自己的修复引入的问题——继续修复，然后再次运行检查
  • 如果是开始前就存在的问题——告知用户并询问；Bug 修复必须保持最小，因此是否进行 refactor 由用户决定
当每项发现都有明确处理结果时，即完成：要么已修复，要么已向用户提出。

House rules

基本规则

  • When it fits, use PHP Attribute and Laravel Attribute in place of the old way
  • The back office runs Filament v5; look its API up before you change back-office code
  • Look a package up with context7 before you reach for a method you have not already seen in this codebase
  • When a build is truly needed, remind the dev person to run it themselves (
    npm run build
    )
  • 在适用场景下，使用 PHP Attribute 和 Laravel Attribute 替代旧写法
  • 后台管理系统运行 Filament v5；修改后台管理代码前，先查阅其 API
  • 在调用本 codebase 中尚未见过的 method 前，先使用 context7 查阅该 package
  • 当确实需要执行 build 时，提醒开发人员自行运行（
    npm run build
    ）