Debugging Judgment Assessment with a Mid-Task Requirement ChangeThe spec moved at rung five. Half your work survived. Which half?

Methodology: Forty original exercises across five formats. Sixteen are the rungs of two fixed-state trails through a real debugging task, eight rungs each; the other twenty-four are eight keyed single-choice items, eight select-every-that-applies items, four true or false claims and four ordering exercises. Construct statement: it measures whether somebody establishes a fault before changing anything, makes the smallest change that restores the behaviour without breaking what already passed, reads what a changed requirement does and does not touch, and lets go of work the change has invalidated without discarding the work it has not. It does not measure programming language knowledge, algorithm design, system design, speed, or any particular technology. No code is written and none is read. Declared response instruction: behavioural tendency throughout the two trails - each rung asks what the respondent is most likely to do. The twenty-four supporting exercises are keyed knowledge items and are reported as their own strands rather than folded into the trail score. The trails are FIXED-STATE and the report says so in plain words. A static item bank cannot branch, so the position at every rung is authored and is identical for every respondent, and each rung is scored against the moves available at that rung rather than against the whole trail. That is what makes recovery real: the best move from a bad position earns full credit at that rung, so one early error is not counted four more times. Without that normalisation the instrument would be measuring rung one, four times over, and presenting it as the respondent's failure. The drift: at rung five of each trail the requirement changes, and it changes in a way that invalidates part of the work and leaves the rest standing. The keep-or-drop exercises are balanced - half the pieces of prior work survive the change and half do not - so carrying on regardless and starting over both score at chance. The two directions are reported separately and are named in the language of the work rather than as over and under. Construct grounding, drawn across sources rather than from one framework: the sunk-cost effect and escalation of commitment (Arkes and Blumer, 1985; Staw, 1976), and the finding that it survives expertise and is reduced by separating the decision from the person who made it; the psychology of debugging, in which the dominant failure is changing code before the fault has been located (Zeller, Why Programs Fail, 2009; Gould, 1975); delta debugging and the value of the smallest change that reproduces or removes a behaviour (Zeller and Hildebrandt, 2002); the distinction between a slip and a mistake (Reason, Human Error, 1990); confirmation bias in hypothesis testing (Wason, 1960) as the reason a fix that passes is not a fix that is understood; requirements volatility and the measured relationship between late change and defect density (Boehm, 1981; Curtis, Krasner and Iscoe, 1988); psychological safety as the condition under which a team can abandon work in progress (Edmondson, 1999); the path-dependence problem in scoring a sequence of decisions, and normalisation against the moves available at each node; the criterion validity of work-sample and situational-judgment methods (Roth, Bobko and McFarland, 2005; McDaniel and colleagues, 2007); McDonald's omega in place of alpha (McDonald, 1999); and the standard error of measurement as the reason a band rather than a point is reported (AERA, APA and NCME Standards, 2014). All items are original works. No item, scale name or report section is taken from any commercial instrument, and no affiliation with or endorsement by any vendor is claimed or implied.