# Reproduce one app bug: evidence card

Use one fixed starting state, ordered actions and an explicit expected rule. Keep a shorter failure sequence beside a nearby passing case so the next person can repeat both. This card sends nothing and changes no app.

## Filled teaching example

All outcomes in this section are **supplied fictional traces**. No real app, customer incident, bug reproduction or repair was executed. Attempt counts and device observations are **Not tested**.

| Context | Supplied example |
| --- | --- |
| App and page | Fictional made-to-order bag request form |
| Revision | R7, a fabricated teaching label |
| Surface / URL | No running preview or published app; no real URL |
| Actor | The same authorized operator in every supplied trace |
| Start for every trace | Fresh unsent form: Tote selected, instruction empty, sizing help closed |
| Expected rule | Instruction text is independent of category. Changing category must keep the exact instruction text. |
| Sample instruction | `Wide blue handle` |
| Browser, device and observed-at | Not tested; supplied teaching data only |
| Scope | Local unsent fields only; no save, submit, account transition or network behavior |

### F1 — original four-action report

1. Open sizing help.
2. Close sizing help.
3. Enter `Wide blue handle` in the instruction field.
4. Change category from Tote to Pouch.

**Supplied result:** the instruction becomes empty. This violates the declared retention rule. The help actions occurred before the loss; that alone does not establish that they caused it.

### F2 — remove the two help actions

Start fresh with the same R7 state.

1. Enter `Wide blue handle` in the instruction field.
2. Change category from Tote to Pouch.

**Supplied result:** the instruction becomes empty. F2 retains the failure after removing both help actions. It is the shortest failing sequence **among these four supplied traces**.

### F3 — reverse the two remaining actions

Start fresh with the same R7 state.

1. Change category from Tote to Pouch.
2. Enter `Wide blue handle` in the instruction field.

**Supplied result:** the instruction remains `Wide blue handle`. This is a two-action passing order contrast. It does not establish that every Pouch flow works.

### F4 — omit the category change

Start fresh with the same R7 state.

1. Enter `Wide blue handle` in the instruction field.

**Supplied result:** the instruction remains `Wide blue handle`. This is a one-action no-change control.

### What the four traces support

Within this teaching example, entering an instruction and then changing category is the isolated failing transition. Removing the help actions preserves the supplied failure; reversing the order or omitting the category change does not show that failure.

This is a focused trigger, not a diagnosed code cause or a proof of universal minimality. The traces do not establish frequency, other revisions, other roles, other field values, a different category transition, reload behavior or saved records. There is no screenshot or actual attempt log behind the fictional outcomes.

### Example request for the affected existing app

The following request belongs to the fictional case. Replace it with your own checked context and actual results before using it.

```text
On the made-to-order bag request form, instruction text must remain
unchanged when category changes. In the supplied R7 teaching case,
start with a fresh unsent form: Tote selected, instruction empty,
sizing help closed. Enter "Wide blue handle", then change Tote to Pouch.
Expected: the exact instruction remains. Supplied result: it becomes empty.

The same loss is supplied with or without opening and closing sizing help.
Changing to Pouch before entering the instruction retains it; entering
the instruction without changing category also retains it.

Investigate and correct this field-retention behavior without changing
the category-independent instruction rule or adding a save/submission flow.
After the change, record the actual revision and repeat the original
four-action sequence, the two-action trigger and both passing contrasts.
Report observed results and anything still untested. No code cause,
repair or successful recheck has been established by this teaching card.
```

### Repair recheck, still untested

| Sequence on the actual changed revision | Expected instruction after the sequence | Actual result |
| --- | --- | --- |
| F1: help open → help close → enter → category change | `Wide blue handle` | Not tested |
| F2: enter → category change | `Wide blue handle` | Not tested |
| F3: category change → enter | `Wide blue handle` | Not tested |
| F4: enter only | `Wide blue handle` | Not tested |

Keep the changed revision, starting state and attempt counts with these results. A builder reply or code change does not fill in the Actual result column.

## Blank card for your own app

Use an app and sample data you are authorized to inspect. Keep private customer information, credentials and tokens out of copied requests or screenshots. If a check would submit, purchase or contact someone, establish a suitable authorized test path before trying it.

| Context | Your record |
| --- | --- |
| App, exact page and permitted sample URL | |
| Build/revision, or Unknown | |
| Preview or published surface | |
| Actor role and relevant starting records | |
| Browser/device and observation date | |
| Expected rule and its source/owner | |
| Fresh starting state and reset procedure | |
| Permitted test scope; actions excluded | |

### Original sequence

1. [First exact action and sample value]
2. [Next action]
3. [Add or remove steps as needed]

- Expected result:
- Actual result, including exact visible values:
- Attempts / reproductions: **Not tested** until recorded. If intermittent, record the actual counts and differing conditions.
- Evidence reference, with private data removed:

### Reduced sequence and comparisons

- Steps removed from the original:
- Starting state kept the same:
- Shorter sequence tried:
- Actual result and attempts / reproductions:
- Nearby order contrast, if relevant:
- No-change or other comparison, if relevant:
- Actual comparison results:
- Shortest failing sequence among the sequences actually tried:
- What remains unknown:

Do not invent a passing contrast or a successful reproduction. If the shorter sequence does not reproduce the symptom, retain that result and the longer sequence. If none reproduces it, describe the report as **not reproduced under these conditions**.

### Existing-app request

On [exact page / actual revision], starting from [state], when I [ordered
actions], I expected [declared rule] but observed [actual result]. This
occurred in [reproductions] of [attempts], or remains [not reproduced / not
tested]. [Removed steps and relevant comparison results.] Please
investigate this scoped behavior. Preserve [rules and unrelated valid
behavior]. Recheck [original failing and nearby passing cases], record the
changed revision, and report anything still unverified.

### After-change record

| Changed revision and context | Sequence repeated | Expected | Observed | Attempts / reproductions | Evidence / next action |
| --- | --- | --- | --- | --- | --- |
| Unknown | Original sequence | | Not tested | Not tested | |
| Unknown | Reduced sequence | | Not tested | Not tested | |
| Unknown | Nearby comparison | | Not tested | Not tested | |

## Use the request in the right place

Open the affected existing app and review the request in its builder. Overskill's [Getting help](https://www.overskill.com/help/articles/getting-help-in-overskill) distinguishes the editor's AI Prompt Builder from Help Chat, which answers support questions. This card does not open an app, import its contents, run a request or create a support ticket. Normal account access and credit requirements still apply.

The [design review guide](https://www.overskill.com/learn/make-an-app-easier-to-use) owns broader usability checks. Use the [interruption guide](https://www.overskill.com/learn/test-ai-app-interruptions) for sign-in, retry, reload and saved-state questions. This card stays focused on reproducing one local symptom before requesting a change.