Choose the job before you record. Recorder uses that choice to label the lookup field, preserve the session’s purpose, offer the supported result choices after Stop, and decide which destinations are available. It does not decide whether the application behaved correctly.

Choose the session type

Your job	Select	Lookup	Result after Stop	Start with
Explore a question or report a newly found problem	Explore	Optional issue; leave empty for a new issue	No Recorder result control	Capture an exploratory discovery or report a bug
Execute a planned check	Test case	Type the test-case ID; TMS search is not available	Passed, Failed, or Blocked	Execute a test case
Check a candidate fix	Verify fix	Select the issue being verified	Fixed or Not fixed	Verify a fix

Use Reproduce a reported bug for a focused attempt against an existing report. The specialist blueprints cover smoke or regression batches, accessibility evidence, and slow interactions.

Follow the shared 10-step path

1. Choose the job. Select Explore, Test case, or Verify fix. Do not use a convenient result label for a different job.
2. Identify the subject. Enter the issue or test-case reference. For Test case, a typed ID is saved with the report but is not looked up in a TMS.
3. Write the criterion. In Description, record the build, starting state, expected result, and observation that will decide the outcome.
4. Capture the relevant path. Select Start recording, perform the check, capture the visible result with enough context, then select Stop before decisive evidence leaves the retained timeline.
5. Open the evidence. Select Investigate. Begin at the known action or symptom, not with an obligatory tour of every tab.
6. Follow one subject. Compare the intended action, sent data, returned state, later updates, and visible result. Preserve identity and time when moving between views.
7. Explain the evidence. Pin useful leads, then use Notes → View evidence → Add comment → Save comment to state what each source establishes and what remains uncertain.
8. Choose the supported result. Use the result control only when the selected session type offers one and the required criterion was actually checked.
9. Write the account. In Description, put the outcome or observation first, followed by conditions, expected/actual behavior, evidence, gaps, and the next useful check.
10. Preserve and verify. Review Privacy preview, download or send the result, open the destination/files, and only then select New recording.

Understand what Recorder fills and what you supply

Part	Recorder does	You do	Save or destination
Session type	Stores Explore, Test case, or Verify fix with the report	Choose the job that matches the attempt	Persists with the recording
Issue lookup	Searches a configured tracker for Explore or Verify fix	Select a result or type a key; verify the issue is correct	Found issue metadata stays with the recording
Test-case lookup	Stores the typed ID; shows TMS search as unavailable	Enter the authoritative case ID	Included with the report; no TMS is updated
Title	Can fill an unchanged Title from a found issue	Keep it or edit it intentionally	Saves with session details; can be sent to the tracker
Issue description	Offers Add when a found issue has text	Decide whether to append it; review earlier appended text	Appends to Description and never stays synchronized
Description	Provides one Markdown editor in the local Viewer	Write the attempt account and insert reviewed Notes/actions	Autosaves after a pause or blur; no submission occurs yet
Source comments	Keeps each note attached to an action, field, request, log, or image	Explain why the source changes the conclusion	Requires Save comment; exported to notes.md when present
Result	Shows choices for Test case and Verify fix after Stop	Choose only the supported outcome	Stored in the report and included in supported sends
Send menu	Shows currently configured and locked destinations	Choose the tracker action, Fairlead storage, or manual handoff	Nothing leaves the browser until the selected action is run

A found issue’s description is never copied automatically. Add appends it to Description; Not now leaves your text unchanged. If you later choose another issue, review any text already appended from the first one.

Investigate a result, not a tab list

Use the expected result to decide what evidence matters:

1. In Actions → Recorded Actions, confirm the intended control and subject. Read Target, captured values, form state, page changes, and URL changes where relevant.
2. Open associated requests. Check Payload for the subject and intended change; check Response or a following read for the resulting state. HTTP 200 alone does not establish a pass.
3. Open the result image. Confirm that it shows the claimed subject and context. Use Timeline and request Timing when completion order matters.
4. Follow Console, live messages, Environment, or performance evidence only when it can distinguish the remaining explanations.

Stop when you can state the supported result or observation, the evidence behind it, the important gap, and the next useful check. A clean Overview, absent error, or generated script is not a verdict.

Write and deliver the result

Use Description for the account of this recording. Older stored reports can contain a separate legacy reproduction-notes value; the current local editor does not edit that legacy field.

Job / reference / attempt: [fill in]
Build / environment / role: [fill in]
Expected: [criterion]
Observed: [specific result]
Recorder result: [when the selected type provides one]
Evidence: [insert reviewed Notes]
Capture gaps / next check: [fill in]

Select the evidence placeholder and choose Add → Notes. This inserts a copy of saved comments and bare pins. Finish comments first; later edits to source notes do not update the inserted text. Description autosaves after a pause or blur. Resolve any save error before handoff.

The send choices depend on the session:

• Explore without an issue can create one; Explore with an issue can update it or replace its description.
• A Failed or Blocked Test case can create an issue or keep No issue. Passed results have no issue action. TMS delivery remains locked and must be completed in the TMS manually.
• Verify fix can Add evidence only after an issue and Fixed/Not fixed result are chosen. Automatic issue transitions are not available; change status in the tracker yourself.
• Send data to Fairlead, when available, stores the report without sending anything to the tracker or a TMS.
• Download report supports a local/manual handoff for every ready recording.

Open the actual destination after sending. Issue mutation, screenshot attachment, report storage, download completion, and later TMS attachment can succeed or fail independently. Retry only the failed part; after an unknown tracker timeout, check the tracker before submitting again.

Shared example: Quackban

The workflow guides use a synthetic Quackban case to demonstrate investigation decisions. The reported problem is: a card enters Blocked, moves to In progress, but keeps its Blocked badge. Expected: leaving Blocked clears the badge. The sample follows one card across the action, move request, following board read, and final image.

Download the sample bundle, unzip it, and open session.md and notes.md. The archive also contains network.har, scripts, recorded steps, and screenshots. See the sample bundle reference or the worked reproduction.