Small patch, visible proof

IDEA 1

Turn a bug report into a measurable contract

The fictional club's ticketTotal function charges 200 cents per ticket. For this exercise, its input is an integer count and a nonpositive count must return zero. The original function multiplies every count by 200, so negative counts expose the missing condition.

A patch is a proposed change to source code. Here it is represented by an allowed path and a complete replacement function. The proposed code actually executes inside the same isolated JavaScript runtime as the lab; no shell, package installation, repository write, or deployment occurs.

Show the bug before the fix

1. Rule. Integer count at or below zero must produce zero cents.
2. Original. The original multiplication makes a negative bill.
3. Candidate. A clamp can enforce the lower boundary before multiplication.
4. Check. Execute positive, zero, and negative inputs under the same rule.

The repository, issue, and candidate patches are authored classroom examples.

Repair a rule, not one example

function ticketTotal(count) { return Math.max(0, count) * 200; }

Math.max selects the larger of zero and count. With a negative count it chooses zero; with a positive count it preserves count. The contract here assumes integer counts and does not claim to validate every possible input type.

Think it through: A candidate returns 400 for every input. Which observation defeats it?

IDEA 2

Keep the evaluator independent of the candidate

Run the same case set before and after a patch. The tests are fixed fixture data inside the tools, so the proposed replacement function cannot legitimately redefine the expected results. A visible before-and-after count explains what improved and what still fails.

The test tool evaluates a function expression and calls it with each fixture input. A thrown error is recorded as a failed case. A nonterminating function is stopped by the outer runtime limit, producing a run error rather than fabricated test results. Passing these few cases is evidence for this narrow contract, not proof of general correctness.

Unchanged tests, comparable runs

1. Before. Run the original source against all three cases.
2. After. Run the proposed function against exactly the same cases.
3. Inspect. Keep the changed path visible for the reviewer.
4. Limit. Add new cases when the contract expands; do not claim these cover every input.

Real JavaScript execution on classroom cases; these are not benchmark results.

Do not accept on improvement alone

if (after.passed !== after.total) {
  return { status: "tests-failed", ...report };
}

Improving from one passing case to two is not enough when all three checks are required. The gate compares against the declared acceptance criterion, not merely against the previous score.

Think it through: The patch improves from 1/3 to 2/3 passing cases. Should this acceptance rule approve it?

IDEA 3

Scope and human review still apply after tests pass

A successful test result does not authorize editing any file. proposePatch accepts only the allowlisted path, and inspectDiff reports which path the preview would replace. An out-of-scope patch is rejected before execution.

A human-review fixture also names the exact approved source code. A changed candidate requires matching review, even if it passes the same tests. savePatchPreview checks the approval again and returns a local preview; it never commits or publishes the patch.

Three independent gates

1. Allowed path. The candidate must target the permitted file.
2. Behavior. The actual replacement function must pass the fixed cases.
3. Exact review. The reviewer-approved code must match this candidate.

Fixture approvals demonstrate scope; they are not real user credentials.

Tests cannot grant permission

if (!input.approval || input.approvedCode !== patch.code) {
  return { status: "needs-review", ...report };
}

The review gate is separate from test success. The preview tool repeats the approval and path checks so skipping this controller guard does not make the operation authorized.

Think it through: A tested patch targets a file outside the allowlist. What should happen?

Put it into practice

Reject out-of-scope or failing candidates, report before/after results, and preview only the exact approved code.

1. Read the integer ticket-count contract and the proposed function.
2. Run the starter with the example-only patch and notice the missing behavioral gate.
3. Insert the all-tests-pass check before the review gate.
4. Compare a correct approved patch, an example-only patch, an unapproved patch, and an out-of-scope edit.
5. In the experiment, try the suggested nonterminating function only to observe the runtime timeout; no result should be called passed.

Your next experiment: Try count === 0 ? 0 : count * 200 as the patch. Which case remains broken? Advanced trial: function ticketTotal() { while (true) {} } should trigger a runtime timeout, never a pass.

Show a failing original, run the candidate under unchanged checks, inspect its scope, and keep acceptance under review.

Key terms

Patch

A proposed source-code change; this exercise represents one complete replacement function and its path.

Regression check

A test that checks required behavior still holds after a change.

Evaluator

The checks used to judge a candidate's behavior under stated inputs and rules.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.