Can this change
be called done?
Conceptual simulation · synthetic work and evidence
A fictional retry-limit change moves through code, checks and review. Watch what happens when evidence fails, goes missing or belongs to an older revision. A merge still waits for an owner.
One small code change.
Give a fictional job runner a cap of three total calls, including the initial call. Keep successful jobs from running twice.
- 01Transient errors retryTwo transient errors, then success: exactly three calls.
- 02Three total attempts maximumPersistent transient errors stop after three calls, including the initial one.
- 03No duplicate successful jobA second request for the same successful synthetic job does not execute it again.
Intent
Candidate register · synthetic
- Candidate
- none
- Worker
- sim-worker-1
- Repair retries
- 0 / 2
- Bounded run
- sim-run-1
Repair retries are separate from the job runner's three-call limit.
Evidence register · synthetic
Owner decision · your role
Acceptance pending
The candidate, under glass.
The tiny checks execute deterministic, in-memory teaching logic in your browser. Their synthetic results say nothing about a real repository.
Leave a useful checkpoint.
Pause with the blocker and next step intact. Replacing a worker changes neither the saved record nor its remaining budget.
Checkpoints live within this simulation. Reset or reload clears the run.
Why the token moved.
A stop is information.
Failed means an available check contradicted a criterion. Unknown means the report is unavailable. Stale means a record belongs to another candidate. None of these can quietly turn into current acceptance.
Play follows the selected scenario. Step performs one transition. Pause freezes travel while stations remain inspectable. Playback stops for owner acceptance, a checkpoint or a human budget decision.
Reduced motion removes token travel. The same stations, reasons, records and explicit decisions remain available.
A policy experiment,
not a universal rule.
This example borrows the separation of bounded intent, evidence and acceptance from Workpacket design material. Workpacket's README describes design material, not a runtime. Workpacket-light is a draft proposal: GitHub PR/CI can hold code and engineering evidence, while a smaller work record retains intent, criteria, unknowns and a resumable checkpoint.
Exact revision freshness, mandatory owner acceptance, a simulated merge before acceptance and two autonomous repair retries are this demo's policy choices. The core ADR separates generation, verification, approval and acceptance; it leaves detailed freshness policy open. A worker's completion claim cannot self-certify this run.
Everything here is fictional and local: code, job IDs, revision IDs, workers, tests, review, merge and acceptance. There are no runtime API calls, credentials, real GitHub actions or private task data. These client-side guards illustrate a policy; they are not an authorization system.