Prove your review and build a reusable workflow

Run independent tests

from pathlib import Path
import json
import math
import unittest
from reviewed_classifier import classify_ticket,evaluate,ContractError

def ticket(**changes):
    return {'ticket_id':'T099','severity':'low','age_hours':1,'target_hours':4,**changes}

class ReviewTests(unittest.TestCase):
    def test_literal_baseline(self):
        rows=json.loads(Path(__file__).with_name('tickets.json').read_text())
        report=evaluate(rows)
        self.assertEqual([report[k] for k in ['input_records','urgent_candidates','routine_candidates','rejected_records']],[5,2,1,2])
        self.assertEqual([r['classification'] for r in report['results']],['ROUTINE_CANDIDATE','URGENT_CANDIDATE','URGENT_CANDIDATE','REJECTED','REJECTED'])
    def test_exact_target_is_urgent(self):
        self.assertEqual(classify_ticket(ticket(age_hours=4))['reasons'],['AT_OR_OVER_TARGET'])
    def test_high_alone_is_urgent(self):
        self.assertEqual(classify_ticket(ticket(severity='high'))['reasons'],['HIGH_SEVERITY'])
    def test_both_reasons_retained(self):
        self.assertEqual(classify_ticket(ticket(severity='high',age_hours=4))['reasons'],['HIGH_SEVERITY','AT_OR_OVER_TARGET'])
    def test_invalid_numbers_rejected(self):
        for value in [True,'4',math.nan,math.inf,-1,169,None]:
            with self.subTest(value=value),self.assertRaises(ContractError):
                classify_ticket(ticket(age_hours=value))
    def test_target_zero_rejected(self):
        with self.assertRaises(ContractError): classify_ticket(ticket(target_hours=0))
    def test_large_integer_rejected_without_float_overflow(self):
        with self.assertRaises(ContractError): classify_ticket(ticket(age_hours=10**1000))
    def test_unhashable_identity_becomes_rejection(self):
        self.assertEqual(evaluate([ticket(ticket_id=[])])['rejected_records'],1)
    def test_wrong_schema_rejected(self):
        with self.assertRaises(ContractError): classify_ticket(ticket(extra='ignore me'))
    def test_duplicate_identity_rejected(self):
        with self.assertRaises(ContractError): evaluate([ticket(),ticket()])
    def test_empty_fixture_has_zero_counts(self):
        report=evaluate([])
        self.assertEqual([report[k] for k in ['input_records','urgent_candidates','routine_candidates','rejected_records']],[0,0,0,0])

if __name__=='__main__':
    unittest.main()

Run python -m unittest -v from the downloaded project directory. Eleven tests should pass. The literal baseline and boundary expectations are specified independently of the classifier. The tests include both reasons, unsupported numbers, zero target, oversized integer, invalid list-shaped identity, wrong schema, duplicate identity and empty population.

That evidence is useful and bounded. It does not cover every possible nested JSON payload, runtime failure or operational integration. A coverage percentage would also not prove that the tested assertions match the requirement. Ask what each test can detect and what important boundary remains unverified.

Mutation: demonstrate that verification can fail

In a separate copy, change if age >= target to if age > target. The equality and baseline checks must fail. Restore the code. Next disable the high-severity branch while leaving the age branch intact. The high-alone and both-reasons checks must detect the loss. These two mutants isolate separate requirements rather than producing one large broken program with no clear diagnosis.

Compare the supplied flawed specimen with the reviewed solution on T002 and T003. Record the mismatched labels. Do not run the specimen over real data just to gather more examples. A small synthetic counterexample already demonstrates that it violates the contract.

Project A — Add an approved “near target” category

Propose a third valid label, NEAR_TARGET_CANDIDATE, for non-high tickets with age at least 75% of target but below target. Keep high severity and at/over target as urgent. Write expected cases before coding: low severity at 2.99 of 4 is routine; at 3 of 4 is near; at 4 of 4 is urgent; high severity at zero remains urgent.

Retain rejection rules and update reconciliation counts so every row appears in exactly one category. Avoid overlapping independent counters that count the same row twice. Add a reason vocabulary and explain whether percentages are measured on elapsed hours or a different approved business clock. Do not claim the extension is implemented or tested until your own code and assertions establish it.

Project B — Review an assistant's proposed live adapter

Write an adapter review without implementing external writes. Identify the endpoint, authentication identity, read permission, pagination, source coverage, timestamp normalization, timeouts, retry budgets and duplicate revision semantics. Define the evidence needed to trust the age and target fields. Unknown source coverage cannot be repaired by testing the classifier more often.

If a future requirement includes ticket updates, add authorization, approved states, a durable action identity, concurrency handling, ambiguous-success recovery and human escalation. Retrying a request after a lost response can duplicate an action or apply it in the wrong state. A read-only candidate report is a safer bounded first task, but it is not the complete design for a write workflow.

Project C — Produce a code-verification portfolio

Deliver a specification, expected-value matrix, flawed draft, defect ledger, reviewed replacement, tests, baseline report, mutation results and limitations. Record the exact source version and runtime. Include one review finding that was not obvious from the normal happy path, such as the invalid-ID rejection path or huge-integer handling.

For each finding, explain the actual failure, not just a generic warning. A useful portfolio demonstrates that you can disagree with a fluent answer using evidence and improve it without inventing new requirements. It also shows when you stop: a model's suggestion is not authority to access secrets, install tools or modify a production service.

A repeatable review loop

Start with an approved bounded task; define input, output and side effects; prepare independent cases; request a draft; inspect interfaces and error paths; run isolated tests; inject a targeted defect; review the repair diff; and verify a clean copy. Only then consider an authorized integration with separate staging and rollback checks.

Keep the prompt and review notes useful, but do not confuse them with execution evidence. “The assistant says it tested the code” is not a substitute for your captured command, runtime, input and result. Likewise, a green local suite does not authorize deployment. The distinction between drafting, testing, reviewing and releasing is the central skill in this course.

Consult official Python documentation for unittest, numeric types, math.isfinite, JSON parsing and exclusive file opening. The ticket policy, prompts, scenarios and review portfolio are original exercises. You can finish the standalone course without purchasing a book or using any paid AI model.

Official references: unittest, math.isfinite, JSON and open.

Transfer project — changed conditions

Build fixtures at29,30 and31 days, plus a directory and symlink where supported. Assert that only the intended31-day regular file is listed and every original remains unchanged. Add an unreadable entry and a path outside the allowed root; define explicit error/scope behavior. Ask the assistant to explain a failing test, then independently review its proposed patch. Submit the specification, diff, executed results and limitations.

Practical assessment rubric

Score each dimension 0–2: 0 = absent or materially incorrect; 1 = partly correct with an unresolved gap; 2 = correct, explicit and supported by the supplied evidence or an actual labeled lab result.

1. Evidence/model: identify the relevant entities, inputs, assumptions and boundaries without inventing facts.
2. Main result: derive the case-specific expected result, calculation or decision and show the intermediate reasoning.
3. Failure/boundary: test the changed condition and explain why the original conclusion does or does not transfer.
4. Verification: supply reproducible steps and expected/observed results; label manual traces as manual, not executed.
5. Communication/safety: explain limitations, owners and a proportionate next action without unsafe or unnecessary access.

Target: at least 8/10, with no zero in main result or communication/safety. This is a local learning rubric, not an accredited certification standard. A written/manual solution demonstrates reasoning only; operational competence additionally requires the relevant executable lab in an authorized environment. The native multiple-choice score is separate and does not automatically grade this rubric.

Submission template

• My input/evidence and assumptions:
• Expected result with calculations or trace:
• My implementation/decision and justification:
• Changed-condition result:
• Observed execution, or explicitly labeled manual trace:
• Failure and recovery evidence:
• Unverified limitation and next action:
• Self-score with evidence for each dimension:

Remediation

If the main result is wrong, reconstruct the supplied case from the raw inputs before changing code or controls. If the boundary case is wrong, identify the assumption that changed and rerun both the original and changed case. If verification is missing, do not convert a prediction into an observed result. Reattempt the transfer task without copying the worked solution, then explain it to another person.

Official reference for further study

Assessment: explain your decisions

Choose an answer and write your reason before opening each explanation. Then explain why the other choices do not fit the evidence. Use missed questions to revisit the lesson. This knowledge check is only one part of assessment: complete the practical transfer project as well. It does not predict certification-exam success.

1. Which input reveals the supplied comparison bug?

1. 10
2. 9 only
3. Any screenshot

Answer and explanation

10 — The equality boundary distinguishes < from <=.

2. What should you do when an acceptance test reveals a defect?

1. Delete the test
2. Correct the implementation or clarify the requirement
3. Trust confident prose

Answer and explanation

Correct the implementation or clarify the requirement — Tests express the requirement; defects should be addressed.

3. What belongs in a safe coding request?

1. Production secrets
2. Unbounded system access
3. Input/output contract and permitted actions

Answer and explanation

Input/output contract and permitted actions — A bounded specification makes review and testing possible.

4. A low-severity ticket is exactly at its target age. Under the written rule, which label is expected?

1. URGENT_CANDIDATE, because age >= target independently satisfies the OR rule.
2. ROUTINE_CANDIDATE, because only high severity can qualify.
3. REJECTED, because equality is invalid.

Answer and explanation

URGENT_CANDIDATE, because age >= target independently satisfies the OR rule. — The specification contains an OR condition and an inclusive age boundary. A dramatic high-severity overdue example cannot independently test either of those distinctions.

5. Generated code and generated tests both say T002 is routine, but the approved matrix says urgent. What has the green suite proved?

1. The approved specification is wrong.
2. The two generated artifacts agree; independent requirement verification is still missing.
3. The script is ready to update real tickets.

Answer and explanation

The two generated artifacts agree; independent requirement verification is still missing. — Shared assumptions can make implementation and tests agree on the same mistake. Recover expected values from the approved specification and manual trace, then review both code and assertion changes.

6. The assistant proposes replacing unknown age with zero and automatically updating priorities. What is appropriate?

1. Accept both because they simplify the workflow.
2. Run on real tickets to see if users complain.
3. Reject the invented measurement and external action unless separately specified and authorized.

Answer and explanation

Reject the invented measurement and external action unless separately specified and authorized. — Unknown is not measured zero. Live writes also expand the side-effect and authority contract. A local candidate label neither establishes SLA compliance nor authorizes a production action.

7. Which violation should stop execution immediately?

1. The draft deletes files despite a report-only requirement.
2. It uses readable variable names.
3. It returns a list.

Answer and explanation

The draft deletes files despite a report-only requirement. — Unexpected destructive behavior exceeds the contract. Review must precede running the code.

8. Should an exactly30-day file be included?

1. Only if its name is short.
2. No; older than30 is a strict boundary.
3. Yes; >= is always equivalent to older than.

Answer and explanation

No; older than30 is a strict boundary. — The requirement explicitly excludes the exact boundary. Tests should lock down that distinction.

9. Why inject the reference time?

1. To avoid all filesystem permission checks.
2. To make deletion safe automatically.
3. To make age classification deterministic and testable.

Answer and explanation

To make age classification deterministic and testable. — A fixed clock makes boundary tests reproducible. It does not replace scope or permission safeguards.

Open the scored course assessment to use the existing practice-test engine. Earlier attempts remain part of your history.