Delivery Evidence Package: How to Review a Small Script Repair

Every example below is a hypothetical illustration with sample values. No runs were performed for this guide, so observed outcomes stay pending.

A "done" message does not establish what was tested. A delivery evidence package is one folder that answers three questions: what exactly changed, what stayed untouched, and what ran. This review uses one concrete defect as the worked case.

A worked defect: the duplicate alert

Suppose the frozen scope names one defect in AlertHandler: the same event, delivered twice, produces two alerts instead of one. The folder should state expected outcomes per exact test condition.

1. Duplicate event. Fixture events_dup_01.txt holds two copies of event ID EVT-4751. Expected count: two alerts on the old source, one alert on the repaired source. Observed: PENDING.
2. Invalid event. Fixture events_invalid_01.txt holds ID EVT-0000 with a missing payload. Expected: rejected, zero alerts, no stored change. Observed: PENDING.
3. Restart replay. Run events_dup_01.txt, restart, then feed the same stream again. Expected: the already handled ID is not replayed. Observed: PENDING.

Only paired expected and actual logs can close these conditions.

What the folder must contain

• scope-frozen.md: target file, single defect, allowed files, out of scope items, acceptance conditions.
• src_before/ and src_after/: complete files, not snippets.
• hashes.txt: one complete-file hash per file.
• build-version.txt: compiler or build version, platform version, date.
• fixtures/: named inputs like the three above, each with a stated purpose.
• logs/: full expected and actual logs for every condition.
• control/: one item that should not change.

Sample manifest

Compare a complete-file hash against a trusted earlier record to check whether the bytes match. The hash does not establish who produced the file or whether its behavior is correct. A wrong file also has a valid hash. Paired logs support only the behavior and conditions actually tested.

The paired defect check

Ask for the same check on the old source and the new source, with the same fixture and steps. The old source should show the defect present. The new source should show it absent. In the worked case, that means two alerts on src_before and one on src_after, each backed by a full log. One run on one version says nothing about the other.

Three result types

1. Positive: the intended change works under the exact condition it targets.
2. Negative: invalid input is rejected without touching stored state.
3. Failure path: an unconfirmed result is treated as unresolved, and stored state is inspected before any retry.

A package with only positive results has not been reviewed for failure.

Fixes are not additions

A fix restores the frozen scope. An addition changes behavior outside it, like a new setting or alert channel. Additions need their own scope and tests. Compare the complete source changes with the frozen scope. Logs may miss extra behavior on paths the tests never exercised. Ask about any unexplained addition.

Why compile and screenshots fall short

A clean compile proves the code parsed and built. It says nothing about which item received the change, whether the control stayed unchanged, or what happens at runtime with a duplicate event. A screenshot is one moment on screen. Neither shows alert counts under a fixture or replayed IDs after restart. For behavior, you need expected and actual logs.

One dated example

On 23 August 2026, public issue 475 reported Pine tools writing over the currently open saved script while returning success (https://github.com/tradesdontlie/tradingview-mcp/issues/475). That is a dated report, not a current-version claim. Save-specific safeguards are covered separately at https://stratcorealpha.com/engineering-notes/pine-save-binding.

Free handoff review checklist

• Frozen scope names target, defect, allowed files, acceptance.
• Complete before and after files for the target.
• Complete-file hashes recorded, treated as identity only.
• Compiler or build version with date.
• Named fixtures with purposes and exact conditions.
• Full expected and actual logs for each condition.
• One unchanged control with before and after evidence.
• One defect shown present, then absent, same fixture and steps.
• Positive, negative and failure path results present.
• Fixes listed separately from additions.
• Missing items recorded in a gap table.

Sample gap table