A 12-hour cache broke a 24-hour promise.

The fixture states SW-REQ-241: a retry using the same key before 24 elapsed hours returns the original reservation and creates no second reservation. The reason is simple: a client can lose the first response and retry later.

The author supplied this requirement and selected the checks. Its Proof record remains a draft. The expected values in cases.json are fixed; they are not calculated from the retention setting being tested.

Required retry window: 0 ≤ elapsed hours < 24
A: {"retention_hours": 24}
B: {"retention_hours": 12}
C: {"retention_hours": 24}

At 23 hours, A still finds the original key. B has expired it and inserts another reservation. C restores the retention window without weakening the requirement or changing the test. The actual A → B diff and B → C diff each change only config.json.

The 24-hour case is outside the promised window. It checks this implementation’s expiry convention, which permits a new reservation then. These five observations do not establish behavior for every timing, concurrency or failure scenario.

Read the failing execution, JUnit results and implementation.

Proof ran the configured test command at each real fixture commit. It then assembled an EvidencePackage from each persisted run. B is blocked and names the two failed cases. A and C are not_assessed, even though their test command passed.

The fixture’s author knows that retention affects SW-REQ-241. That mapping was not automatically established in the package. The example demonstrates command execution, a recorded failure and honest incomplete readiness. It does not demonstrate authorized acceptance.

The packages identify the actual local commits and the producing Proof run. Their example.invalid repository label is a reserved teaching identifier, not a hosted repository. The resolver’s provider field does not mean GitHub ran anything.

Only the tests_pass check ran. This is not a full Proof audit. Package assembly reads saved evidence; it does not rerun verification or make a draft requirement approved.

The runner records hashes for the implementation, test, requirement, cases and configuration. A → B changes only the configuration hash. That comparison uses an explicit file list written for this example; it is not an automatic Proof dependency-discovery or freshness result.

Before running B, A’s result is historical support for the 24-hour setup. After running B, there is a separate observed failure for the 12-hour setup. Stale evidence and failed behavior are different facts.

A local attempt to render A’s package through the GitHub projection with B’s head was rejected: not PR-scoped. These packages describe local commits. No PR, remote check, merge gate or deployment ran. The actual refusal is included.

Download and unzip the example. With Python 3 and Git installed, run from the extracted retained-obligation directory:

python3 run.py --output /tmp/retained-replay

Use a new output directory. The script creates a disposable Git repository with no remote, executes A, B and C, and saves a Git bundle plus results. Its own exit is successful only when the observed fixture exits are 0, 1, 0.

To also produce Proof audit artifacts and packages, supply an installed executable:

python3 run.py --output /tmp/retained-proof-replay   --proof /absolute/path/to/proof

The captured run used proof 0.1.0-teaching-b845ff313bac commit: b845ff313bacb887c4e9fb78145c681a15f6b3f0, built from source revision b845ff313bac. The README includes the build command, exact scope and interpretation. Different versions can produce different disclosures.

Force the configured command when that is the intent.

The example configures project.checks.tests_pass.affected.mode: full, then runs:

proof audit --check tests_pass --no-cache --format json

--no-cache does not force a nonempty affected-test plan. In an earlier setup attempt, a clean committed snapshot produced “no affected tests to run.” The published setup explicitly executes the full configured command and checks that fresh output files were produced.

Git commit dates are fixed teaching metadata so the three commits can be rebuilt. Actual execution times are recorded separately. No user identity, customer approval or live service is simulated.

On 3 October 2026, a local client opened the fixture at revision C through Proof’s stdio MCP server. It listed the tools, searched for retry without supplying a requirement ID or component, and received SW-REQ-241. It then used that returned ID to read the full draft requirement and its rationale: a client can lose the first response and retry later.

A protocol warning remains. The server rejected notifications/initialized with error -32601. The scripted client completed the subsequent reads, preserved that response and exited 1. This is not a clean interoperability result or a fresh-agent experiment.

Inspect the actual requests, actual responses, execution summary and scope and replay instructions. Download the scripted client separately; the fixture ZIP contains the original execution records and updated replay instructions.

• Concurrent requests, multiple replicas and restart durability.
• Different payloads reusing a key and production clock behavior.
• Automatic discovery of the configuration dependency and complete requirement-level evidence mapping.
• Approval of intent, effective acceptance, hosted CI enforcement and deployment.
• A fresh agent independently finding the obligation, preserving it during a change and saving reviewer time. Those outcomes have not been tested.

These limits are retained with the requirement and results. The next step is to choose a real component, record its important obligations and inspect the evidence a change actually needs.