Review the draft as executable behavior, not confident prose

Inspect the deliberately flawed specimen

"""Synthetic review specimen. Deliberately flawed; not a production tool."""
def classify_ticket(ticket):
    if ticket['severity'] == 'high' and ticket['age_hours'] > ticket['target_hours']:
        return 'URGENT_CANDIDATE'
    return 'ROUTINE_CANDIDATE'

Trace T002: severity is low, so the and expression is false regardless of elapsed time. It is marked routine even though age equals target. Trace T003: severity is high but age is below target, so it also becomes routine. Both violate the written OR rule. A high-severity ticket beyond target passes this flawed branch, which means a single dramatic example would miss the problem.

The specimen also uses > instead of >=, ignores type and range contracts, and loses separate reasons. A missing field can raise an exception without a row-level rejection policy. A text age may compare incorrectly or fail at runtime. It has no batch duplicate policy and no provenance or output interface. These are distinct review findings; repairing the boolean operator alone does not finish the job.

Turn the review into a defect ledger

For each defect, record the requirement, a smallest exposing input, observed result and expected result. Avoid “the script looks unsafe” as the only review comment. For the OR defect, T003 is useful: high severity with age zero must be urgent. For the equality defect, T002 is useful: low severity at exactly four hours must be urgent. For missing numeric validation, use True, NaN, infinity and numeric text as separate cases.

Python booleans have a relationship to integers that makes a broad isinstance(value, int) check insufficient for this contract. The implementation uses exact type membership. Floating-point non-finite values also need deliberate handling: a comparison with NaN does not behave like an ordinary measurement. Do not “clean” it into zero just to keep arithmetic convenient.

Huge integers introduce another edge case. Converting an arbitrarily large integer to a float just to check finiteness can fail before the range check returns a useful validation error. Here, Python integers are checked by range without unnecessary floating conversion; finite checking applies to actual floating values. The approved maximum makes an enormous integer invalid regardless of its representation.

Separate record errors from batch ambiguity

A bad numeric field can be rejected with its safe fixture identity and reason while valid records continue. A repeated valid ID is different: two rows now claim the same ticket identity, and the exercise has no revision field to determine whether either is current. The program refuses the batch. That choice prevents hidden “last row wins” behavior in a dictionary.

For an invalid ID such as a list, do not attempt to use it as a set key or echo arbitrary data into a report. The output uses unavailable when no valid fixture ID exists. A test for this invalid shape caught a real review defect in the initial replacement's rejection path. Error handling deserves tests too; code that carefully validates normal fields can still crash while reporting invalid input.

Read side effects before running

Inspect imports and calls for network libraries, subprocesses, file writes, deletion, environment access and credential handling. Names alone do not establish safety: follow how a path is constructed and whether an action is authorized. In this lab, the only final write is a new local JSON report, opened exclusively. Source data is read, not modified. The pure classifier itself performs no I/O.

Run a syntax check and tests in the new fixture directory before using a new output path. A successful syntax check does not prove the rule, and successful tests do not prove an arbitrary package or hidden adapter is authorized. Maintain a review boundary around the exact files being exercised.

Exercise: avoid a shared-oracle trap

An assistant generates both the function and a test that expects T002 to be routine. Both run successfully. What has been established? How would you repair the verification process?

Worked reasoning

The implementation agrees with that test, but both contradict the approved matrix. Recover the expected value from the specification and manual case trace, not from the generated branch. Review production and test diffs independently. Ask the assistant to explain discrepancies if useful, but do not give it unilateral authority to rewrite the requirement.

Evidence laboratory — attempt before reading the solution

An assistant generates a cleanup script for files older than30 days in a selected practice directory. The requirement actually says: report candidates only, never delete; exclude symlinks and subdirectories; treat exactly30 days as not older. The draft calls unlink(), follows recursive traversal and uses age>=30. Identify each contract violation before execution and design a safe replacement interface.

Official reference for further study