This is a recommended blueprint for turning a Recorder session into a bug report. Adapt the report template and investigation depth to the defect. The useful result is a short account of how to reach the problem, what should happen, and evidence that puts the developer on the exact screen, request, or field.

If a failed-test recording already shows the problem, start with its Investigate viewer. You do not need another reproduction just to file a report. The steps below cover both a local file handoff and a configured tracker submission.

For a first investigation, follow the worked example below. Once the approach is familiar, use the decision table to choose the next evidence and the final report example to check your handoff.

Follow this 10-step path

1. Select Explore. Leave Issue empty for a new report, or select the issue you intend to update.
2. Write a specific Title and the shortest known path, expected result, actual result, and conditions in Description.
3. Select Start recording, capture the failure and enough surrounding state to identify it, then Stop → Investigate.
4. Confirm the affected subject and visible discrepancy in Screenshots & Attachments.
5. Follow the same subject through the trigger action, sent value, returned state, and later read or update.
6. Pin useful sources, then add comments explaining what they establish and what remains open.
7. Edit Description into minimal reproduction steps, expected/actual behavior, evidence, scope, and next check.
8. Review Privacy preview, choose the intended send action or Download report, and inspect the actual output.
9. Open the issue and verify its text and attachments; issue mutation, attachments, and report storage can have different outcomes.
10. Retry only the failed part, preserve the ready recording, and select New recording only after the handoff is usable.

Understand the report fields and destinations

Part	Recorder does	You decide
Explore	Uses an optional issue lookup and no result selector	Whether this is a new report or an update
Issue lookup	Can fill an unchanged Title and offer the fetched issue description	Whether to choose Add; the text is appended, not synchronized
Description	Saves one Markdown account after a pause or blur	The minimal path, expected/actual result, evidence, and scope
Create	Uses Title and Description for a new issue	Whether the discovery is ready to file
Update	Adds Description and screenshots to the selected issue	Whether the existing description should remain unchanged
Replace description	Makes Description the issue description after confirmation	Whether replacement is truly intended
Send data to Fairlead	Stores the report without a tracker mutation	Whether report storage is the intended destination

Older stored reports can contain a separate legacy reproduction-notes value. The current local Viewer uses Description for new edits and sends.

Capture the failure if you do not have it yet

1. Open the application and Recorder’s side panel. Use the account-free path for a local handoff or select the connected project and tracker. Choose Explore. Leave Issue empty for a new report or select the known issue.
2. Prepare safe data and the shortest known route to the symptom. If creating a record or changing a setting is necessary evidence, do that after Start; otherwise put it in the report’s preconditions.
3. Select Start recording, wait for the active state, and perform the actions. When the wrong result appears, use Capture for the visible viewport or Area for a region. Include identifying context, such as both the affected card and its lane heading.
4. Capture any immediately relevant response or follow-up check, then select Stop and Investigate. Avoid continuing unrelated exploration: older actions can leave the retained timeline.
5. Edit the Title when needed and press Enter: for example Board: Blocked badge remains after move to In progress. A found issue can prefill an unchanged Title; keep it unless a rename is intended. Put attempt details in Description.

If the event already left the retained interval, download what remains and describe the gap before making a new attempt. New recording clears the current local session and notes.

Find the deciding evidence

Start with one discrepancy: what should have changed, and what did you actually see? Then follow the same subject through the action, sent data, returned data and image. The aim is to show where the evidence first stops matching the expectation and give a developer a useful next check.

The sample reproduction bundle makes this concrete. The tester expected a card’s Blocked badge to clear when it left that lane. All six captured requests returned HTTP 200. Error counts alone would miss the defect.

Download the sample and open session.md, notes.md, network.har, and the three PNGs together. The walkthrough below reconstructs an investigation from those files; it does not claim to recover the author’s inspection history. Follow the bold UI actions in your own stopped recording and use the sample’s observations to see what each comparison accomplishes.

1. Establish the subject and the visible discrepancy

Open Screenshots & Attachments and select the failure image. Ask whether it identifies both the affected record and the state that makes the result wrong. Pin it while you follow the lead.

In the sample, 003-area.png shows QB-DEMO sticky Blocked with a red badge. It does not show the lane heading. Its note says the card is in In progress; that part must be supported by the action/returned data. For your capture, include the card and lane heading in the same image.

Compare the earlier images: 001-area.png shows this card in Backlog without the badge; 002-full.png shows it in Blocked with the badge. These establish the starting state and the transition that made the flag relevant. They prevent “this card always had that badge” from becoming an unnoticed assumption.

2. Locate the transition that should remove the symptom

1. Open Actions → Recorded Actions. In this example, locate Clicked ‘In progress’, after opening the same card. Select the action and inspect Target to confirm the control and subject; use available What changed, Element & form state, Page changes, or URL changed when the operation depends on them.
2. Look back at the earlier Clicked ‘Blocked’ action. Add a note there if entering that state is a required precondition. A useful note says why the earlier action belongs in the reproduction, instead of repeating “clicked Blocked.”
3. Expand the In progress action’s request-count control, then select the move request. You can also open it from Related activity in the action detail. It opens beside the action so you retain the sequence while inspecting the data.
4. In Payload, confirm the record ID and requested state. In the sample the move carries ID 3229d3de-fb6d-4196-8f89-f0bf94d63392 and status in_progress. Right-click the status field → Pin. Read the containing object as well: the move contains ID and status, with no separate blocked property.

You do not need to recognize the endpoint name first. The sample uses long generated /_serverFn/… paths. Identify the operation by its time and contents. If the request contains only an unfamiliar ID, find the visible card title in a board response, read the ID in that same card object, and use it to follow the move and subsequent reads. Confirm both identity and state; two cards can have similar titles.

This answers “did the browser send the intended lane?” It does not answer “which layer should clear the flag?” The server may be responsible for deriving it. If your payload names the wrong record or state, go back to the action’s target and captured input before investigating the returned data.

The sample uses an encoded JSON format with parallel key/value arrays. Find the record by its ID, pair names with values in the same object, and preserve the raw structure. An array position is not a stable record identity across captures. In a large response, use the detail search to locate the ID, then clear it to read neighboring fields; otherwise the comparison itself may be hidden.

3. Follow the write into the next read

Open Response on the move request. If it only acknowledges the move, it cannot tell you the card’s complete resulting state. Use Open in Network tab on the related request row to inspect the following board read for the same card. Open Network directly if that read has no action association.

Compare three points, not just the final value:

Sample board read, by request start time (UTC)	Same card’s returned status	Raw node paired with blocked	What the comparison establishes
04:43:38.732 after creation	backlog	{t:2,s:3}	Baseline value before entering Blocked
04:43:50.465 after the Blocked move	blocked	{t:2,s:2}	The value changed when the card entered Blocked
04:43:57.141 after the In progress move	in_progress	{t:2,s:2}	The status changed again, while the blocked node stayed the same

The sample author interprets those nodes as false → true → true. The raw comparison is independently visible in the HAR; Recorder does not decode arbitrary application formats or prove the server’s implementation.

In your recording, right-click the deciding returned value → Pin, then mark the sibling status or containing record when needed to preserve identity. In the sample, the Important note targets response.p.v[0].p.v[2].a[44].p.k[10], whose content is the name blocked. The paired node is in p.v[10]; status is the paired field at index 4. A note on the key alone is a useful locator, but read the paired value before claiming what it means.

You now have a narrower finding: the returned card already contains the unchanged blocked representation alongside the new status. That makes the update/read path worth investigating as well as the badge rendering. It does not prove a particular database write, cache, or handler is responsible.

4. Try to disprove the explanation before writing it

Open Timeline when order could change the conclusion. Check that the move concerns the same card and precedes the read; open the request’s Timing to check completion before interpreting a later screenshot. A request’s Timeline position is its start time. Inspect any intervening action or update that could legitimately change the state again.

Use Console when a relevant exception or browser diagnostic offers another explanation. Open the entry and read Message, Stack trace, source and available arguments; use Cause where offered to revisit the associated action. In Network → Headers, inspect recorded cancellation, blocking, redirect or cache information if it matters. Initiator can give a developer a script-origin lead. These details help test a specific hypothesis; there is no need to collect every warning.

Choose your next move from the evidence:

What you find	What to inspect next	What to preserve
The payload sends the wrong ID/value	Action target, captured value and control state; compare with the intended subject	The earliest wrong value and the action that preceded it
The intended value is sent, but the returned record is wrong	Earlier state, following read, cache/redirect context and intervening updates	Sent value and returned discrepancy on the same record; leave ownership of the defect open
Returned state is correct, but the screen is wrong	Screenshot timing, page reaction, relevant exceptions, and later HTTP/stream updates	Correct returned value and the later incorrect visible state
There is no associated request	Broader Network and Timeline, plus action/form state	Whether any matching request was captured; absence of a link is not absence of traffic
The decisive value/image is missing or ambiguous	Body-availability reason, capture scope, or a better-framed new attempt	The known observation and exact gap; do not fill it with an assumption

If the request has a Trace badge or recorded correlation headers, preserve the identifier with its request time and method/path. A developer can use it to look for the corresponding backend activity when their services record those identifiers; see backend correlation. This can carry the investigation beyond the browser without guessing the server function.

For a live-update issue, inspect EventStream or WebSocket messages where present; see the request detail guide. For timing, follow the responsiveness blueprint.

Stop this investigation when another tab would not change the report’s conclusion. If one uncertainty matters, save this attempt and choose one follow-up experiment. For the sample, a new recording of reloading the affected state would test whether the badge/data recur on a fresh read. The sample description mentions earlier Done/reload observations; this particular capture does not establish them.

Turn useful pins into explanations

Open Notes. Your pins now form a short list of evidence to assess without rediscovering it in the full recording. Select each item and use View evidence to check the complete source, identity, time and surrounding fields.

For each useful pin, choose Add comment; for an existing note, Edit comment. Write an observation, its significance, and any limit. Select Important for the deciding finding and Save comment. A draft is not saved just because you leave the editor. If saving fails, resolve the error while the draft remains available.

The sample’s four notes serve different purposes. These are tighter versions of their explanations, not changes to the original files:

Note location	Why keep it	Example wording
Earlier Blocked action	Establish the required state before the failure	“After this move, the board read changes the card’s blocked node from its baseline representation to {t:2,s:2}; the screenshot shows the badge in Blocked.”
In progress request payload	Confirm the intended change left the browser	“This move sends the same card ID and in_progress. The payload contains no separate blocked property. Which layer should clear it remains to be checked.”
Following board response, Important	Identify the decisive data inconsistency	“For this card, status is now in_progress, while the raw blocked node is unchanged from the Blocked state. Compare the paired value and status in this object.”
Failure screenshot	Connect data investigation to user impact	“The named card still shows the red badge. This crop omits the lane heading; use the preceding move/read for lane context.”

Avoid “later moves never reset it” when you have inspected only one departure from Blocked. Keep a baseline note if it explains the change; remove speculative or duplicate pins that add no value. Remove pin / Remove note removes the mark after confirmation; Delete comment leaves the pin. Important does not reorder the account or set issue priority.

Assemble the report

Open Description → Split. If a found issue offered its description, choose Add only when that context belongs in this account; Recorder appends it and does not remove or synchronize it later. Paste and adapt this template:

Build / environment / role: [fill in]
Test case / run / attempt: [if applicable]
Preconditions: [setup performed before recording]

### Steps to reproduce
[STEPS]

### Expected
[what should happen]

### Actual
[what happened at the failure point]

### Evidence
[NOTES]

### Scope
[frequency, conditions tried, and missing evidence]

1. Select [STEPS] in the editable Markdown and choose Add → Recorded actions. This local operation inserts the starting page and retained actions into your selection, regardless of Actions filters.
2. Edit the inserted list into the necessary numbered user steps. Remove irrelevant narrative and duplicate clicks from this text; add required pre-Start setup under Preconditions. Editing the description does not delete captured actions or change generated test commands.
3. Select [NOTES] and choose Add → Notes. Comments and bare pins are inserted with source context. For an image, the text identifies the attachment; attach the image file too.
4. Check Preview. Use Undo if an insertion landed in the wrong place. If you change source notes afterwards, replace or edit the inserted copy; it does not update automatically.

With a configured connected recording, Add → Steps to reproduce requests deterministic steps and Steps written by AI requests AI-generated text. Both contact the project Data Plane; the latter sends the full report, while deterministic generation uses a reduced report. Review captured and authored data before generation. The menu displays the reason when unavailable, such as a recording started without sign-in or disabled project storage. Use Recorded actions as the local alternative.

Every generation click inserts another result. Review it against the actual attempt before sharing; generated text does not establish steps outside the recording. Description edits save after a pause or leaving the field. Resolve any save error above the editor or on the tab.

Example: the investigation condensed into a report

This is a suggested rewrite based on the sample, with gaps left visible. Fill in your own build and conditions; do not copy its conclusion onto a different recording.

Title: Blocked badge remains after card moves to In progress

Build: not recorded in the supplied sample
Context: Quackban / Pond Redesign; signed-in application session
Recording: 2026-10-07T04:43:24.309Z, 42 seconds
Subject: QB-DEMO sticky Blocked
Card ID: 3229d3de-fb6d-4196-8f89-f0bf94d63392

Steps:
1. Create the card in Backlog (Data Diver, 2 points in this attempt).
2. Open it, move it to Blocked, and close it. The badge is visible.
3. Open the same card, move it to In progress, and close it.
4. Inspect the card's badge.

Expected: leaving Blocked clears the badge.
Actual: the badge remains after the In progress move.

Evidence:
- 001-area.png: this card starts in Backlog without the badge.
- 002-full.png: the card is in Blocked with the badge.
- network.har, POST at 04:43:56.539Z: same ID, status=in_progress.
- Following GET at 04:43:57.141Z: status=in_progress, with the
  blocked node unchanged from the previous Blocked response.
  Raw node: {t:2,s:2}; the sample author interprets it as true.
- 003-area.png: the named card still has the badge. The crop omits
  the lane heading; use the move/read for that context.
- notes.md identifies the marked action, request fields and image.

Investigation finding:
The discrepancy is present in returned card data as well as the
visible badge. Inspect how lane changes update and return blocked
state. This capture does not identify the responsible handler.

Limits / next check:
All six HTTP requests returned 200. Creation bodies are redacted.
Done/reload observations in the original description concern earlier
runs. Capture a separate reload attempt to check the subsequent state.

The report’s reproduction steps are shorter than the full captured action list. Keep the original technical sequence with the evidence, so the developer can inspect detail without first reading every click. The finding says where to begin and what remains unknown; QA does not need to claim a proven code-level cause to make the report actionable.

Give each attachment a purpose

Recipient needs to…	Preserve and cite
Understand and repeat the failure	Edited description with preconditions, minimal steps and expected/actual; session.md for the session context and recorded sequence
Follow your reasoning	notes.md and finalized notes inserted into the narrative; each comment explains its source’s role
Inspect the exact sent/returned data	network.har with method, request time, record ID and field reference in the narrative; Copy as HAR can isolate a selected request when a smaller handoff suffices
See the visible discrepancy	The referenced PNGs, including baseline/context when needed; note text alone does not carry image bytes
Follow a relevant exception or browser error	The available console output and a precise message/stack/time reference; confirm the file exists
Turn the reproduction into a regression check	A reviewed script from Tests, plus the expected result that needs assertions and the setup/data requirements
Investigate viewer-only evidence	Copy the essential safe measurements or stream excerpts, their source and timestamps into the account before reset

A saved note excerpt is a pointer into evidence, not a replacement for the complete body. Request URLs in inserted notes identify endpoints; they are not hosted copies of the captured request. The sample’s session.md links to console.log, but no such file is in that ZIP. Check actual files before promising them to the recipient.

Review and deliver

1. Open Privacy preview and inspect the intended export. Review console text, your own prose, and screenshots as well as request data. Apply supported Redact controls where needed. The Originals display toggle does not select export values.
2. Select Download and confirm the files finished in Chrome. Open the title/session-ID folder, inspect session.md and available notes.md, and check the relevant PNGs. Local downloads include report-excluded images; select the actual reviewed files to share. ZIP them yourself if required.
3. For manual filing, copy the Title and Description into the tracker. Attach the images, network.har or console output needed to inspect the claim, and the Markdown summaries.
4. For connected filing, check the selected destination and issue key. Choose Create issue, Update ISSUE-123, or Replace description of ISSUE-123 from the send menu. Recorder substitutes the selected key. Picking a menu item does not send until you press the primary button. Keep the fetched Title unless a rename is intended.
5. Open the resulting issue and verify its text and attachments. Issue submission, image attachments, and report storage can have different outcomes. Retry a failed attachment rather than creating the issue again. HAR files are not automatically attached by the screenshot workflow; attach one manually if the developer needs it.

If submission times out, check the tracker before retrying. Preserve your local files and text before New recording. The report is ready when the reproduction steps, expected/actual result, and referenced evidence can be followed by the recipient. The shared workflow guide has additional capture and preservation details.