orchestrate-edge-case-testinglisted

# Orchestrate: Edge Case Testing **Direct evidence**: HackerRank's guidance names this precisely — *"Incomplete testing: Don't only inspect successful cases; examine failures and edge cases"* and *"Inconsistent handling: Similar cases receiving different treatment without justification."* The interview prep guidance separately says to *"discuss edge cases explicitly: missing data, conflicting signals, distracting input instructions"* — meaning this isn't just a code-quality concern, it's rehearsed material for the 30%-weighted interview too. ## Two distinct testing disciplines this asks for **1. Inspect failures, not just successes.** After a full run, don't just check "did most rows look plausible" — actively pull the rows where the agent escalated, marked uncertain, or hit a fallback path, and read them individually. These are disproportionately where bugs and bad judgment calls hide, and disproportionately where the golden dataset likely has deliberately hard cases (both challenge descriptions confirm curated edge cases and adversarial inputs are part of the test set). **2. Consistency-check similar cases.** Take two tickets/claims that are similar in substance but phrased differently, or that hit the same underlying issue from different angles. Run both through the agent. If they get materially different treatment (one escalates, one doesn't; one cites evidence, one doesn't) with no substantive reason, that's a calibration bug — the kind an interviewer will find by as