Repeat the reported steps and compare this attempt with the original evidence. Record whether the symptom occurred, where the behavior first differs from the expected result, and what the developer should inspect next. Support the outcome with evidence another person can verify.

Found a new bug without an existing report? Start with Prepare a bug report. Already captured this attempt? Start at step 4 below. An original stored session is reference evidence; make and annotate your own local attempt. Downloaded files do not reopen as an interactive Viewer.

Follow the affected item in your report through interaction → sent data → returned state → visible result. Actions, Network, Timeline and Screenshots expose different parts of this chain. Their links let you change perspective while following the same evidence.

Example references: the card and Blocked-badge examples below use the Quackban sample bug report and evidence. Follow the procedure with your own recording and expected result.

Follow this 12-step path

1. Define the failure. Read the original report. Write the expected result, reported result, required starting state and observation point. Separate an observed symptom from the reporter’s explanation. Set up the comparison.
2. Prepare this attempt. Select Explore, choose the reported issue, identify A1, record its conditions and check that capture rules cover the path. Set up the comparison.
3. Record the reported path. Select Start recording, repeat the original interaction, capture the relevant starting and final states, then Stop recording → Investigate. Include a reload when the tested path requires a fresh page load. Capture the transitions.
4. Verify the actual trigger. In Actions → Recorded Actions, open the relevant action and inspect Target and captured state. Confirm the control and subject even if the row’s name looks right. Check the action.
5. Check what left the browser. Open the action’s request count, select the request, then Payload. Match the subject ID and requested change; pin the deciding value. Follow the sent operation.
6. Check what came back. Inspect Response. Use Open in Network tab to find a following read when the write only acknowledges receipt. Compare the same record before and after the trigger. Compare returned state.
7. Reconcile data with the screen. Open the result in Screenshots & Attachments. Use Timeline and request Timing to check that the image describes the state after completion. Pin the visible result. Check the observation.
8. Resolve the first unexplained difference. Follow relevant logs, live updates or condition differences only when they could change your explanation. Choose the next useful detail.
9. Decide the attempt’s result. Record reproduced, not reproduced, blocked or inconclusive, and state separately how far the technical comparison goes. Choose a verdict and next check.
10. Explain the retained evidence. In Notes, use View evidence, then Add comment → Save comment. Keep the findings that explain the setup, sent change, returned state and visible impact. Turn pins into findings.
11. Write the short account. Open Description. Start with Result, Path, Expected and Actual; add conditions and Add → Notes underneath. Write the attempt summary.
12. Preserve and verify. Review Privacy preview, download the evidence, update the original issue and verify the text/files at the destination. Only then choose New recording for a follow-up. Deliver the evidence.

Which “notes” goes where?

Name	Use it for
Pin / Note on evidence	Save a particular action, field, request, log or image. Pin keeps a lead immediately; a comment explains its significance.
Notes tab	Review those saved marks and return to their sources. This is your evidence collection.
Description	Write the overall account for local and connected recordings. A found issue can offer its existing description to append; review it before adding.
Add → Notes	Insert a copy of saved comments and bare pins into that account. It does not create new annotations or track later edits.
notes.md / session.md	Downloaded files. notes.md contains source annotations; session.md contains Description and session context. Older stored reports can contain a separate legacy reproduction-notes value.

Set up the comparison

Read the original issue and its evidence side by side. If it includes notes.md, follow each note into the supplied request, image or action before adopting its conclusion. A note can contain a useful observation and an untested explanation in the same sentence.

For the Quackban example, write: “After this card enters Blocked and then moves to In progress through Move to lane, close the card and inspect the board. Expected: no Blocked badge. Reported: badge remains.” This is a testable criterion. “The server never clears the flag” is a hypothesis to investigate.

Capture these conditions in your attempt account:

• Subject and history: which card or equivalent test record; whether prior entry into Blocked is required.
• Interaction and observation: menu versus drag, relevant pace, where and when the result is inspected, and whether reload is part of the reported path.
• Application context: build, project, role and relevant settings. Recorder’s Environment tab does not supply the application’s build or role.
• Known differences: missing original build, different permissions, unavailable data, or earlier-run observations that the original recording itself does not cover.

Select Explore. For a local attempt, put the issue key and attempt number in the Title and the original issue link in Description. Below, QB-17 is illustrative and A1 means the first attempt. For a connected update, select the existing issue and check its key and fetched summary. Recorder can fill an unchanged Title and offer the issue description. Choose Add only when appending it helps; the text does not stay synchronized. If lookup fails, read the issue in the tracker and prepare a manual update.

Prepare backend lookup when relevant. Connected requests can carry reproduction and per-request correlation identifiers when project configuration enables them and the backend retains them. Preserve an available Trace/correlation value with method, path, time and environment. Account-free recording does not send these headers. See backend correlation for the receipt check; do not invent an ID when it is absent.

Check capture coverage before Start. For a connected project, review Settings → Recording: Domain filter, Request filter when shown, Capture response body for and Max response body size. Page and request coverage can differ: allowing an external API request does not also record interactions on that site’s page. Account-free capture follows the starting hostname family and defaults to JSON response bodies with a 512 KiB payload limit; connected project rules can differ. An HTML error page or an excluded SSO step may therefore leave a gap. Resolve required coverage with the project administrator or plan to document the missing evidence; see capture rules.

Ready to record: you can name the state you must reach, the observation that decides the result, and any known capture gap. If a missing prerequisite prevents that path, report the blocker or label a narrower check explicitly.

Capture the transitions that matter

Start recording before any setup that might trigger the defect. Describe earlier setup as a precondition. In the example, preserve three states: before entering Blocked, after entering Blocked, and after leaving it. The middle state matters: no badge at the end means little if the card never acquired one.

If a fresh page load is part of that setup, Start recording, then reload to retain the navigation and baseline requests. If the reported bug depends on an already-open page or accumulated state, preserve that attempt first and make reload a separate diagnostic variation.

Use Capture for the visible viewport or Area for a region. Include the subject and its surrounding context, such as the lane heading. Repeat the reported interaction and capture the result at the reported observation point, including a successful result when the bug does not appear. If reload is part of the claim, preserve both sides of it.

Select Stop recording, then Investigate, while the decisive events remain in the retained timeline. For a long path, save ordered checkpoints and identify which steps each covers.

Capture limits: pre-Start or evicted events cannot be recovered. For a timing-sensitive bug, avoid inserting pauses just to take intermediate images. Preserve the original pace and capture the endpoint; label a slower diagnostic run as a separate attempt.

Verify the trigger, even when its label looks right

In Actions → Recorded Actions, select the trigger and read the preceding setup actions. Open Target. Compare Label with available Visible text, Aria label, Role, Selector, frame and group context. These help distinguish repeated controls and reveal a name borrowed from nearby content.

Have an ID or error code but no known step? Enter it in Search actions, requests, and messages. Matches in: tells you whether the match came from the step, a linked request body or a log. Expand the matching request and open it; when that request matched, the query follows into its detail search. This takes you from business identity to the relevant interaction even with unfamiliar endpoints. Actions searches associated evidence; use Network or Console directly for unassociated traffic/messages, then clear the detail query to inspect surrounding fields.

Use the other details to answer a concrete question:

Question	Inspect	Decision it helps make
Did the intended value actually change?	Captured value, What changed	Continue to the request, or investigate an earlier input/control problem.
Was the control able to act?	Element & form state	A recorded disabled or invalid state may explain why the expected operation did not start.
Did the page take a different path?	Page changes, URL changed	Check unexpected navigation or context before comparing downstream data.
Did keyboard/gesture order matter?	Event Log; turn Key actions only off for keydown	Reconstruct the relevant events instead of relying on the shorter action narrative.

In Page changes, captured Appeared or Changed from … to … text can preserve the application’s toast or validation message. Quote it with the action context. This text comes from live/alert/status regions in a short observation window, normally 500 ms after a click or 1,500 ms after submit; nearby actions can extend the window. Use a screenshot for slower or uncaptured feedback. Rage click detected records repeated clicks, a lead to investigate alongside the response and visible state.

If the action name and request disagree, preserve the disagreement. For example, a row might say Blocked while a request for the intended card sends in_progress. Verify the target, request time and ID. Use the payload to state what was sent; keep the row name as evidence of a label mismatch. Pin the action and the request value, then explain both in Notes. Do not classify the test as the wrong interaction from the row label alone.

If the label remains confusing, Rename can clarify the action narrative after you have documented the original mismatch. It does not correct the captured target or generated test. Avoid deleting the action to tidy the account: that removes evidence and can change associations.

Interpretation limit: request associations can be inferred from nearby events. A contradictory payload may belong to another action. Confirm subject, operation and timing in Network before assigning it. An absent state field also does not mean a recorded false.

Follow the sent operation

Expand the action’s request-count control and select a request, or select one in Related activity. It opens beside the action sequence, keeping the question “what happened around this interaction?” in view.

1. Read any failure explanation above the request details, then use Headers to identify method, destination and time. The explanation distinguishes recorded cancellation, network/CORS blocking, HTTP failure and GraphQL response errors. Preserve it with the visible symptom; a canceled background request alone does not explain the bug.
2. Open Payload. Locate the subject ID and requested change. In this example, that is this attempt’s card ID and in_progress.
3. If the ID is unfamiliar, open a response containing the board, locate the visible card title, and read the ID in that same object. Use the ID from then on; duplicate titles are possible.
4. Right-click the deciding value and choose Pin. Inspect the containing operation too. A claim that a property is missing needs the complete relevant object, not a single selected field.

An unfamiliar generated endpoint can still be investigated this way: the subject, payload and time establish what it is doing without requiring QA to know the application’s route names.

If the outgoing ID or value is wrong: pin it, return to the action, and compare target/input against the intended subject. Your first known discrepancy is already in the sent operation. Investigate that before blaming a later response.

If the outgoing data is right: retain it and follow the result. A payload containing ID and status but no blocked flag raises the question of which layer should clear that flag. Check the API expectation with the developer before calling the absent property a client defect.

If no request is linked: open Network directly and inspect the surrounding traffic, including live connections where relevant. Unassociated/background requests may still be present. A missing action link is a navigation gap, not evidence that the browser sent nothing.

Compare the same record before and after

Open Response on the write. Does it return the changed record, an application error, or only an acknowledgement? A GraphQL: … errors in response badge can flag an HTTP-200 failure; inspect the returned error details. For GraphQL reports, Network → More filters → GraphQL → With errors helps locate those responses. When the application reads the updated data separately, follow that read.

Use the request row’s Open in Network tab arrow. You now see session-wide traffic, which can reveal the following board read, a retry or another update outside the original action’s request group. Select the relevant read, open Response, and locate the same card by ID. Check identity, new status and the field connected to the symptom together.

The Quackban example compares these three points. For your bug, identify the equivalent baseline, prerequisite and reported failure point:

Point	Question
Before the prerequisite	Was the subject initially in the expected baseline state?
After entering Blocked	Did the prerequisite actually create the state that must later be cleared?
After moving to In progress	Did status change, and did the blocked-related state change as expected?

Pin the deciding value or smallest useful containing object. A pin on a key name does not necessarily preserve its value or siblings. Reopen the containing record and check the saved context. If a detail search hides sibling fields, clear it before comparing identity and state. Before claiming a property is absent, check the body’s completeness: Privacy preview → Not sanitized → Truncated bodies lists affected requests. A truncation marker in the body is also an evidence gap, not the server’s content.

Move between details without losing the comparison. The viewer header’s Back and Forward restore the selected record, request subtab, scroll and opened JSON branches. Use them to alternate between the outgoing value and following response. Clicking a main tab opens its list. The request subtab also carries across requests, so once Response is selected you can inspect consecutive reads there. Check the request heading each time. Cause, where available, returns to an associated action; verify that lead as you would any other association.

If the returned record is already wrong: compare it with the earlier read and any intervening update. You have narrowed the discrepancy to the captured update/read sequence.

If it is correct: move to the visible result and look for a later update or display problem. Both branches need the screenshot and timing comparison below.

Evidence limits: unavailable, redacted or truncated bodies constrain this comparison; keep the displayed reason. If the baseline read happened before Start, record that gap and include the relevant load/setup in a follow-up if needed. Encoded values need the application’s format to interpret them; preserve the raw observation if meaning is uncertain. Viewer history clears on reload; pins are the landmarks for later review.

Check the visible result and its timing

Open Screenshots & Attachments, select the result image, and verify the subject, destination context and symptom. Pin the image. An image can establish a visible badge while omitting the lane heading; then the lane needs separate supporting evidence.

An action’s screenshot control opens linked captures. Recorder associates a viewport/area capture with the nearest eligible preceding action within five seconds; that may be closing the card, rather than the earlier move. Capture when the deciding state is visible, then verify the link and timing. The association window is a navigation aid, not the application’s response-time requirement.

Open Timeline to inspect what happened between the trigger and image. Select the request and inspect Timing for completion. A request appears in Timeline at its start: an image listed after it might still precede its response. Check for another move, retry, navigation or live update before the image.

The useful chain is: intended move → relevant read completes → image shows the result for that subject. If the image predates completion, preserve what it shows and identify the later observation needed to distinguish a temporary state from the reported failure. If the original requirement defines a response-time limit, compare against it; otherwise do not invent an arbitrary wait as the pass criterion.

Checkpoint: can you state separately what was returned and what was visible, at the relevant point? A matching screenshot with unavailable diagnostics can still reproduce the symptom. A mismatched or poorly timed image may leave that criterion inconclusive.

Choose the next useful detail

Investigate the earliest unexplained difference. Open another view when it can distinguish competing explanations:

What you found	Where to go and what to compare	Useful next decision
Returned state contains the discrepancy	Earlier/following responses, intervening writes, Headers for relevant cache information	Which update or read first differs from the expected transition?
Returned state is correct but the later screen is wrong	Console: Message, Stack trace, source and available arguments near the update	Is there a relevant exception or failed UI update to give the developer?
State changes again after the read	Captured EventStream or WebSocket messages: subject, changed value and time	Did a live update replace the state you first inspected?
Equivalent attempts send different operations	Targets/payloads, relevant Headers and Cookies, then Environment	Is role/session/browser context a condition worth controlling in the next attempt?
The delay itself changes the outcome	Request Timing and relevant Timeline performance/lifecycle details	Is the image early, a request slow, or later page work delaying the visible state?
The developer needs a code/backend lead	Initiator, the request’s Trace: … badge and available correlation headers	Copy Trace using its badge; preserve the relevant request headers and reproduction ID with operation, time and environment.
A repeatable automated check would help	Tests, highlighted script lines or Review locator	Identify setup/locator work and the missing assertion, such as “badge absent after leaving Blocked.”
A successful image response looks wrong or stale	Response → Load from cache, when offered, then Add as attachment if useful	Compare the retrieved image with the screenshot. Record that it was loaded later; cache lookup or Re-download image does not certify the original bytes.

Pin relevant log messages or stack fields. Console → Source: Browser helps isolate browser diagnostics such as CORS messages; keep the exact message and time. Explain the connection to this operation. A request’s Served from … line can identify recorded cache/service-worker use when stale state is plausible. Retain the inferred qualification on an Initiator lead.

Environment records browser and initial page conditions. For layout or timing differences, inspect Timeline’s viewport resize, visibility and back/forward-cache events, and recorded browser-zoom actions. A long task can explain a delayed reaction; initial document-load timing does not measure a later move. Copy useful safe facts/time from Environment, standalone performance/lifecycle details or WebSocket messages into the account where source-note controls are unavailable.

Scope limit: Tests previews/exports do not execute the reproduction or add the business assertion automatically. Reviewing every tab is unnecessary once the evidence supports an outcome and useful next check.

Decide the result and the next check

Keep the symptom verdict separate from the diagnostic finding:

What the attempt establishes	Result	Preserve / do next
Reported path reaches the same visible failure	Reproduced	State whether sent/returned data also matches, differs, or could not be compared.
Reported path completes and the expected state is positively observed	Not reproduced under these conditions	Save that successful state and identify the first meaningful difference from the original.
A missing prerequisite or earlier failure prevents the observation point	Blocked	Record the last reached step and evidence of the blocker. The reported transition remains untested.
Decisive observation is missing or ambiguous	Inconclusive	Name the one observation needed to settle it.

Before settling the result, use Actions → Issues · N or Needs attention for a quick check of related failures and error logs, and Overview → Review checklist for session-wide leads. These flags do not determine the verdict. If a required action is missing, inspect Timeline for Recorder injection failed and check capture scope/retention. A capture gap cannot establish that the user never performed the action; preserve the gap and choose the outcome your remaining evidence supports.

For a non-reproduction, work backwards: did the card actually enter Blocked? Was the same move method used? Did the outgoing operation match? Did the returned value clear when the original retained it? Or did the returned state match while the screen differed? Each answer places the first known difference at a different point in the chain.

Choose one follow-up question before starting A2. If prior history may matter, compare a fresh direct move with the original Backlog → Blocked → In progress path. If persistence is unresolved, preserve A1, then record a fresh read after reload. If role differs, repeat with the reported role and equivalent setup. Keep other known conditions alike and explain unavoidable differences.

For intermittent behavior, keep successful and failing attempts. Compare their earliest different state, operation or timing. A not-reproduced attempt does not prove a fix; a reproduced symptom does not establish the same root cause. Stop when you can state the result, strongest finding and next useful check. QA need not identify the faulty handler to deliver valuable evidence.

Turn pins into findings

Open Notes. Treat the saved pins as a review queue, not a finished report.

To keep the original screenshot beside this attempt’s evidence collection, optionally use Screenshots & Attachments → Upload image or Paste image in the local Viewer after stopping. Add an image note such as “Reporter-supplied image from QB-17; original capture time unknown; reference only.” Its attachment time is when it was added, and it is not linked to an action in A1. Open each image through Notes → View evidence to compare them; check report inclusion for an image added outside the recorded period.

1. Select a pin and View evidence. Recheck identity, value, timing and surrounding context.
2. Return to Notes, select Add comment, and write what is observed → why it matters → what remains open. If the explanation is already clear at the source, its Note control opens the editor directly.
3. Mark the deciding finding Important, then Save comment. Closing the editor does not save its draft. Important highlights evidence; it does not set issue priority.
4. Remove duplicate or unsupported leads. Delete comment keeps the pin; Remove pin or Remove note removes the mark after confirmation.

For an attempt reproducing the Quackban badge discrepancy, useful comments have different jobs:

Source	Example comment to adapt to verified evidence
Prerequisite action and supporting state	“A1 entered Blocked before the departure. The following read/image establishes the state that this test expects to clear.”
Outgoing destination value	“This operation sends the intended card ID and in_progress. The original action row says Blocked; Target and timing support a label mismatch. Preserve both when interpreting the steps.”
Deciding response value/object	“The following read returns this card in In progress while its blocked-related value remains unchanged from the Blocked read. The first observed inconsistency is in returned state; flag-clearing ownership remains open.”
Final screenshot	“This image shows the badge still present at the reported observation point. Expected: absent after leaving Blocked. The lane and completion timing are established by [the evidence actually available].”

Use the mismatch comment only if there is a mismatch in your attempt. For a non-reproduction, preserve positive evidence instead: “Same prior Blocked state; this later image shows the badge absent after the move,” with the corresponding returned-state observation on its own source.

Note limits: excerpts are bounded and may omit nearby fields; include the full HTTP Archive (HAR) of captured requests and responses when needed. Comments are saved as written, so check your own text for sensitive data. Later insertion into the summary makes a copy, not a live link to edited wording.

Write the attempt summary

Open Description and choose Split to edit and preview together. Put the outcome first. This opening illustrates the Quackban case; replace the example issue key, path and result with your own:

Result: QB-17 / A1: reproduced.
Path: Backlog → Blocked → In progress, using Move to lane; inspect board.
Expected: Blocked badge disappears after leaving Blocked.
Actual: Badge remains on the same card at the reported observation point.

Below it add the tested build/role/subject, known differences, strongest technical finding and next check. For example: “The intended status was sent; the following read changed status but retained the blocked-related value. Original build is unknown. Developer next check: how the move handler and subsequent read derive that value.” Change this account when the evidence differs.

For backend handoff, add the reproduction ID and the deciding request’s available Trace/correlation ID with its method, URL/path, timestamp and environment. If an ID was not captured or backend receipt is unverified, say so and retain the request context. IDs help locate server evidence; they are not required to establish every visible reproduction.

Insert your evidence beneath that explanation:

1. Type and select [EVIDENCE], then choose Add → Notes. Recorder inserts saved comments and bare pins, with their source context. Finish comments first so the recipient does not receive unexplained bookmarks.
2. If the path needs detail, use Add → Recorded actions in another selected placeholder. Edit the inserted copy into the meaningful steps and add pre-Start setup explicitly. Check misleading action names against the evidence. Actions filters do not limit this insertion.
3. Check Preview. Without editor focus/selection, insertion appends a headed block. Use Undo if it lands in the wrong place. Description saves after a pause or leaving the field; resolve any save error before continuing.

Optional writing assistance: when enabled, Add → Steps to reproduce, Steps written by AI, and Improve → Rewrite with AI use a configured service. Review privacy before using them and check their output against the captured path; generation can reorganize text but cannot decide the verdict for you. A recording started without sign-in does not become eligible for generation by signing in afterwards. Local Recorded actions and Notes insertion remain useful without generation.

Update the Title only when an intentional rename helps. For an existing issue, keep the fetched Title and put A1/result in Description. Explore has no Recorder result selector. Writing the reproduction outcome does not set a test-management result; use test outcomes when required.

Deliver the evidence before starting again

The recipient needs the short attempt account, source comments, relevant images and captured requests/responses. For a focused developer check, select the deciding request and use Copy as cURL or Copy as HAR after privacy review. The latter copies a one-request HAR document; save and attach it manually if useful. Keep the complete capture when the finding depends on earlier/following requests. See copy and reproduce a request for adapting credentials, destination and state before replay.

If replaying the UI path helps, include steps.json for Chrome DevTools Recorder, or a script from Tests. Supply login/data setup and the expected-result assertion. Keyboard, paste and drop events are not directly exported as replay steps; inspect whether subsequent supported input/submit events cover the intended interaction and fill remaining gaps.

Review Privacy preview, captured values, images and authored text before sharing or using remote writing assistance. Originals changes local display/search; export choices are separate. Apply the supported review decisions, then select Download. Confirm completion in Chrome and open the actual folder.

Deliverable	What to check before handoff
Attempt summary	Result/path/expected/actual first; conditions, comparison and next check underneath.
session.md and notes.md	Description/session context and saved annotations match what you intend to share. Notes identify sources; endpoint links do not host captured responses.
network.har	The relevant operation and following reads are present. Cite method, time, subject ID and field so the developer can find the comparison.
Referenced screenshots	Actual files show the claimed subject/state with sufficient context.
Relevant logs or copied observations	The precise message/value/time used by your finding survives in the handoff.

Delivery limits: the standard local files omit WebSocket frames and dedicated browser-diagnostic, performance or lifecycle files. The downloaded HAR also omits recorded timing phases and initiator stacks; Copy as HAR retains available timing phases for the selected request. Preserve decisive measurements, script-origin details and IDs in the account or an available stored report. Local downloads can include screenshots excluded from the report, so review the actual files. Tracker screenshot submission does not automatically attach either HAR; attach reviewed files manually.

For a manual update, paste the attempt account into the original issue and attach the reviewed evidence. For a configured connected update, verify the issue key and choose Update ISSUE-123 or Replace description of ISSUE-123 from the send menu; Recorder substitutes the selected key. Selecting an item changes the primary action; nothing is sent until you press it. Issue submission explains the choices.

Open the destination and verify text and attachments. Issue update, image attachment and report storage have independent outcomes. Retry a failed attachment through its retry control when available. After a timeout, check whether the update already landed before submitting again. For file failures, use download recovery.

Only after the attempt is preserved, return to the application, open Recorder’s side panel and select New recording. Reset clears local evidence and notes. Label the next attempt A2, record its changed condition, and retain A1 separately. When a candidate fix is ready, continue with Verify a bug fix.

Worked example: read the supplied bundle

This section interprets the Quackban sample reproduction bundle for Blocked tag stays after card leaves the Blocked lane. Start with its session.md bug report and notes.md evidence comments. Its filenames and encoded values belong to that capture; they are not instructions to find the same positions in your own recording.

The bundle follows one card through Backlog → Blocked → In progress. All six HTTP responses are 200. Compare the board reads for the same card ID:

Stage in the sample	Returned state	Visible evidence
After creation	status: backlog; node paired with blocked: {t:2,s:3}	001-area.png: card in Backlog, no badge
After entering Blocked	status: blocked; node changes to {t:2,s:2}	002-full.png: card in Blocked, badge present
After leaving Blocked	status: in_progress; node remains {t:2,s:2}	003-area.png: card still has the badge; crop omits lane heading

In this encoded response, p.k holds keys and p.v their paired values. The saved Important note targets the blocked key at p.k[10]; inspect p.v[10] and the same object’s status/identity to understand it. The card’s array position a[44] is incidental. The author interprets the nodes as false → true → true; without the application’s serializer contract, the directly verifiable finding is the node changing on entry and remaining unchanged on departure. Recorder does not provide a universal decoder for these numbers.

Read the four notes as an argument: Blocked action establishes the prerequisite; outgoing in_progress establishes sent intent; following response establishes retained state; image establishes visible impact. Each contributes a different fact. The payload’s lack of a separate blocked property leaves open who should clear it. The final crop needs other evidence for its lane. The description’s Done/reload observations refer to earlier runs, so they do not extend this recording’s tested path.

A supported conclusion is that the reported visible symptom and the returned-state discrepancy occur together in this captured transition. A useful next check is how the update/read path derives the blocked-related value, followed by a separate persistence check if needed. That is enough to direct developer investigation without claiming the exact faulty code is already proved.

Choose another testing workflow.