Bizonyítékra épülő megállapítások

Evidence-Based Findings

A high-signal review never asserts a plausible guess as a proven bug, never invents requirements, and never buries critical defects inside a wall of minor commentary (Richard Feynman & Gerald Weinberg).

Self-Falsification Check Before Reporting Any Finding

Before writing a finding, test your own hypothesis against five questions:

1. Trigger condition: Under what exact input, state, or timing does this issue occur?
2. Code path: Which exact file, function, and line range (path/to/file.ts#L20-L35) executes this path?
3. Violated contract: Which explicit requirement, API contract, or correctness invariant does it break?
4. User or system impact: What is the concrete consequence (data corruption, wrong calculation, permission bypass, crash, broken UI flow)?
5. Existing defense check: Is there an upstream validator, type constraint, database check, or transaction wrapper that already prevents this scenario? (If yes, drop the false positive!)

Strict Classification of Review Items

Always separate items into three distinct categories:

• Proven Defect (Requires Fix): Backed by a concrete trigger, traced code path (or failing test), and clear violation of requirements or system integrity.
• Open Requirement / Design Question: An ambiguity, contradiction, or unverified edge case that requires a decision or targeted specialist check.
• Optional Suggestion (Non-Blocking): A minor clarity or maintainability improvement that does not block approval.

Concise Finding Format

Report every actionable finding in four compact lines:

Finding: [Concrete problem statement] Trigger & Code Location: [When it occurs and exact file#Lstart-Lend] Consequence: [What requirement, invariant, or user workflow it breaks] Required Fix: [What outcome must hold after the fix, plus a concrete solution where helpful]

When no material defects exist, state clearly that the change meets the specification and note any boundaries of what was inspected.