Design a reproduction path — GPT 6 Prompt Template

Complete prompt

Task
Turn a bug report into a minimal diagnostic plan.

Instructions
Diagnose [BUG REPORT] in [STACK]. First restate the observable symptom and expected behavior. List competing hypotheses, the cheapest discriminating check for each, required logs, and a minimal reproduction. Do not implement a fix until the failing behavior is isolated.

Expected output
Symptom, hypotheses, ordered checks, reproduction, and evidence needed.

Checks
- Expected behavior is explicit.
- Checks distinguish hypotheses.
- No fix is claimed without evidence.

Expected output and checks

Expected output

Symptom, hypotheses, ordered checks, reproduction, and evidence needed.

Checks

Expected behavior is explicit.
Checks distinguish hypotheses.
No fix is claimed without evidence.

Worked example

Design a reproduction path: recorded example

Codex · GPT-6 Astra · medium reasoning · 2026-09-07

Original input

Task
Turn a bug report into a minimal diagnostic plan.

Instructions
Diagnose Synthetic reproduction: const original=[{name:"Bo",cents:900},{name:"Ada",cents:400}]; the UI should show signup orderBo,Ada even after another view requests prices sorted ascending. After sorting, original.map(x=>x.name) is Ada,Bo. This happens without a reload. Do not fix yet. in TypeScript browser app; module with a sorting helper, shared array, and two view components. Source implementation is not supplied.. First restate the observable symptom and expected behavior. List competing hypotheses, the cheapest discriminating check for each, required logs, and a minimal reproduction. Do not implement a fix until the failing behavior is isolated.

Expected output
Symptom, hypotheses, ordered checks, reproduction, and evidence needed.

Checks
- Expected behavior is explicit.
- Checks distinguish hypotheses.
- No fix is claimed without evidence.

What the checks found

The exact minimal reproduction was executed. It logs Bo,Ada before sorting and Ada,Bo afterward, then throws the intended signup-order assertion.
The response distinguishes that demonstration from proof about the unavailable real helper and gives several discriminating hypotheses.

Revisions after the first output

No model response edited. The execution log confirms the reproduction fails in the expected way; no production helper fix is claimed.

Original output

Symptom and expected behavior

Reported symptom: during one browser session, requesting ascending prices in one view changes original.map(x => x.name) from Bo,Ada to Ada,Bo. The signup-order view should continue showing Bo,Ada; the price view should show Ada,Bo.

This points toward mutation or replacement of shared ordering, but the helper implementation is unavailable. No cause or fix is confirmed.

Competing hypotheses and discriminating checks

Hypothesis	Cheapest discriminating check	Evidence that distinguishes it
The helper sorts its argument in place.	Call the real helper once, outside either component; snapshot input order immediately before and after.	Input order changes synchronously in the helper-only test.
The helper is pure, but the price component sorts or assigns the shared list afterward.	Compare helper-only behavior with the component handler; snapshot before helper, after helper, and after state update.	Input stays unchanged after helper but shared ordering changes later.
A subscriber, computed value, or effect reacts to the price request and changes shared state.	Timestamp state writes and effect entry/exit around one request.	Ordering changes in a later callback, rather than in the helper call.
The two views read an alias or the wrong selector rather than independent ordering projections.	Record reference equality between original, store list, helper result, and each view's selected list.	Both views select the same sorted result; raw original may or may not change.
The apparent change is a browser console live-object display artifact.	Log serialized scalar snapshots, not expandable array references.	Captured strings stay `Bo,Ada` even though an expanded old array appears sorted. This would not explain a genuinely captured changed string.
A separate data refresh changes order without reloading the page.	Record network activity and store-write origin for one price request.	A response or unrelated store write precedes the changed order. No reload alone does not exclude this.

Ordered checks and required logs

Begin with a fresh two-record fixture. Capture JSON.stringify(original) and original.map(x => x.name).join(',') before the price request.
Invoke the actual sorting helper directly on that fixture. Capture both input and output immediately afterward and record result === original. Equal references alone do not prove mutation; changed input order does.
If helper-only behavior does not reproduce the issue, repeat through the price component handler and instrument state writes, subscribers, and both view selectors. Record a sequence number, performance.now(), operation label, names, cents, reference-equality booleans, and write origin. Snapshot immediately after the handler and after the next render.
If ordering changes outside the synchronous call, inspect the corresponding callback or network response. If raw data remains correct but rendered order is wrong, reduce to the two selectors/components and inspect their actual selected lists and rendered names.

Use synthetic records only. Serialized snapshots avoid console reference ambiguity.

Minimal reproduction

This runnable baseline reproduces the reported behavior with native sort; it is a diagnostic comparison, not evidence that the missing helper uses this implementation. TypeScript accepts this JavaScript-compatible snippet, which also runs directly in a browser console:

const original = [
  { name: "Bo", cents: 900 },
  { name: "Ada", cents: 400 },
];
const before = original.map(x => x.name).join(",");
const prices = original.sort((a, b) => a.cents - b.cents);
const after = original.map(x => x.name).join(",");
console.log(JSON.stringify({
  before,
  after,
  priceOrder: prices.map(x => x.name).join(","),
  sameReference: prices === original,
}));
if (after !== "Bo,Ada") {
  throw new Error(`Signup order changed: expected Bo,Ada; got ${after}`);
}

Expected baseline observation: before is Bo,Ada, after and priceOrder are Ada,Bo, and the assertion throws. I have not executed this snippet here.

For the project reproduction, replace only the native-sort expression with the real helper invocation using its actual signature. Keep the fixture, snapshots, and assertion. If that passes, add the real price-request handler, then the store/subscriber path, then both components until the assertion or rendered-order check fails.

Evidence needed before a fix

The helper source and signature; the shared-array/store declaration; both selectors and relevant event handlers; captured before/after snapshots; the first operation that changes order; and a failing reproduction using the real project path. Stop at diagnosis until that path is isolated.

Files from this run