root-cause-finder

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Chinese

Before fixing the error, prove whether the code path that produced it was intended.

Do not stop at the first contract, parsing, type, null, or schema error. Treat it as a possible symptom.

在修复错误之前，先确认产生该错误的代码路径是否是预期的。

不要在遇到第一个契约、解析、类型、空值或模式错误时就停止排查，要将其视为可能的症状。

State the expected behavior in plain language.
State the invariant in one sentence.
State what definitely did not happen.
Trace the causal chain from the intended action or system event to the observed system effect.
Ask whether the request or mutation should have happened at all.
Identify the canonical source of truth and every competing source.
Find the first unintended side effect or write.
Only then decide whether a downstream contract fix is still necessary.

What user action or system event was supposed to happen?
What exact call path caused this request or response?
Should this request, mutation, or side effect have happened at all under the expected behavior and invariants?
Who owns the state at each layer?
Is there observer-driven syncing, lifecycle startup code, persistence restore, retry logic, background work, or multiple sources of truth causing an unintended side effect?
If a contract is violated, is the contract wrong, or did unintended logic reach the contract?

Do not make the contract more permissive unless you can prove the observed payload is intended in the final design.
Prefer fixing the upstream logic bug over accepting bad downstream data.
Separate symptom, trigger, root cause, minimal safe fix, and architectural follow-up.
If a low-level fix is still needed, explain why the upstream fix is not sufficient or why both are required.
Identify the correct layer to fix first.
Name the first visible wrong behavior, not only the final error.

Treat non-explicit writes as suspicious by default.

Audit lifecycle hooks, callbacks, subscribers, watchers, interceptors, middleware, retries, background jobs, cache refreshers, persistence restore, scheduled tasks, and startup code.
Check whether derived data is being mirrored into another store, cache, file, queue, session, or database through an observer or helper layer.
Prefer explicit command handlers, request handlers, job runners, or user actions as writers; treat startup-time and background writes as suspects until proven intentional.
If a framework has automatic reactivity or lifecycle execution, map this rule onto its equivalent constructs without assuming the framework behavior is correct.

默认将非显式写入视为可疑操作。

Use this structure:

使用以下结构：