Checkpoint 1: Program State and Failure Trace

This checkpoint is not a syntax quiz. Submit a small Java program whose behavior you can trace and defend.

Build

Create a compact-source Java 25 program that:

• begins with at least two typed values;
• receives or simulates one text input;
• parses or transforms that text;
• performs a numeric calculation;
• produces a labeled result.

The program may model a score, sensor reading, inventory count, game statistic, or another school-appropriate system.

Evidence package

Submit all of the following.

1. Expected behavior

State the normal input and exact expected output before showing execution evidence.

2. State trace

Trace at least four meaningful values or state changes from initialization through output.

3. Passing run

Show source plus enough input/output context to verify the normal case. A cropped result with no source/input relationship is not sufficient.

4. Preserved failure

Create and preserve one deliberate failure. It may be compile-time, runtime, or logic, but you must identify which category it belongs to and why.

5. Smallest responsible correction

Identify the line, expression, type relationship, parsing assumption, or state transition responsible for the failure. Make the smallest defensible correction rather than rewriting the whole program.

6. Regression case

Run one additional case after the fix. Explain why that case tests something different from the original happy path.

Mastery standard

A strong submission lets another programmer answer these questions without guessing:

• What was the program supposed to do?
• What values existed at important moments?
• Where did the failure first become observable?
• Why did the correction address that boundary?
• What evidence suggests the correction did not only work for one input?

"It works now" is not a root-cause explanation.