Start with the symptom, not a diagnosis
Consider a PHP endpoint that receives an optional price and calls number_format on it. The request sometimes contains a nonnumeric string. This is an invented teaching scenario, not a production incident. Report the observed input and error rather than declaring that PHP is broken or that the database must be wrong. A useful request separates expected behavior from actual behavior: a valid decimal should produce a formatted price, while invalid input should receive a controlled validation response. It does not assume which part of the code failed.
Reduce the reproduction without removing the failure
Include only the route's validation and formatting logic plus one failing request. Remove unrelated styling, authentication credentials and entire database dumps. State the PHP version you actually ran and whether the value arrived through JSON, a query string or form data, because input representations can differ. If the minimal case no longer fails, restore the removed boundary one piece at a time. The goal is not the shortest possible snippet; it is the smallest snippet that preserves the observed behavior and relevant constraints.
Ask for a hypothesis and a narrow change
Request a distinction between evidence and hypothesis, the affected expression, and the smallest candidate change consistent with your contract. A sensible hypothesis here is that unchecked input reaches a numeric formatter. The assistant should not silently cast all invalid strings to zero, since zero may be a valid price and is different from a bad request. Specify how missing, empty, negative and nonnumeric values should be handled before evaluating the patch. If the intended contract is unclear, a question is more useful than a confident rewrite.
Review the authored reference plan
The reference below is a review plan, not a universal drop-in patch. It validates type and permitted numeric values before formatting. It distinguishes an absent optional field from a field supplied with invalid data. It asks for a controlled error status when validation fails. The exact implementation depends on the application and monetary representation; binary floating point may be inappropriate for some financial calculations. Do not present a formatting example as a complete money-handling design. Keep validation and business requirements visible to the person approving the change.
Test boundaries and regressions
Try an ordinary positive value, zero, a nonnumeric string, an empty value, an array and an absent field. Add a negative value if the application prohibits it. Verify both status codes and body shape, not only that a fatal error disappeared. Check that an invalid request does not update a database row or trigger a downstream action. Run the previously valid case after the patch to detect regressions. If the assistant suggests changes unrelated to the reproduced failure, evaluate them separately so a narrow fix does not become an unreviewed redesign.
Keep the investigation reproducible
Record the input, sanitized error, runtime, candidate change and test results. Do not fabricate a “tested” result merely because the proposed code looks reasonable. If you cannot run the environment, label the patch unverified and explain the missing dependency. Remove access tokens, customer records and internal host details from prompts shared with an external provider. Logs can contain instruction-like text; treat them as diagnostic data rather than instructions. A useful debugging outcome is a reproducible explanation and a verified boundary, not a longer list of plausible causes.
Worked example
REPORT
Runtime: the PHP version used in your reproduction.
Input: price=not-a-number
Expected: controlled validation error; no database write.
Actual: numeric formatting fails.
AUTHORED REFERENCE PLAN
1. Confirm that unchecked request data reaches number_format.
2. Define accepted numeric representation and range.
3. Reject invalid types and values before formatting.
4. Test positive, zero, negative, empty, array and absent input.
5. Record observed statuses; do not claim tests that were not run.How to check the result
A disappearing exception is not enough. Check error handling, valid inputs and side effects. Avoid using this example as complete financial validation or a provider-specific API recipe.