Give each finding a next step
Open a review, inspect the finding and its evidence, then choose Address, Defer, or Dismiss. Those are the current dashboard labels for deciding to work on an observation, keep it for later, or record why no fix is needed.
A decision describes your response to a finding. It does not change the original observation, severity, evidence, or persona score. Use findings and evidence to understand the claim before deciding what to do with it.
Address: select work and verify it afterward
Address adds a finding to the selected repair scope. For a supported finding, the dashboard records a fix attempt and keeps it pending until rerun verification. For a Directional observation, Address adds reproduce-first validation scope: establish the observation before implementing a repair.
You can link an issue or pull request and record a fix attempt. Selecting Address is not proof that the code has changed, the goal was achieved, or the issue was resolved. After a repair, rerun the relevant experience and inspect the comparison and evidence.
Older reviews may show Legacy accepted. That state does not record a fix attempt; choose Address to put the finding into the current repair workflow.
Defer: keep future work visible
Defer records that the finding is future work. You can link it to a ticket so the reason for postponing it stays connected to the review.
When a durable target and finding identity are available, Flock saves the deferral for matching future reviews in the same workspace. The finding remains visible with a deferred status and attribution; it is not deleted or silently treated as fixed. The dashboard says Deferred for future reviews when that persistence is available, and Deferred for this review only when it is not.
For example, defer a known pricing explanation issue while a larger redesign is in progress. If the same finding appears in a later review of the same logical target, it can arrive already deferred, with the earlier decision attached. It still gives you evidence about the experience without adding itself to the current repair scope.
What carries into another review
Persistent deferral matches the workspace, logical target, and finding fingerprint. It is not a text search for a similar title.
- For a repository-backed target, identity uses the repository, configured target key, and scope fingerprint. This can preserve the logical target across changing preview URLs when that identity is present.
- For a URL target, identity uses the target URL’s recorded hash. Do not assume that a different URL automatically matches the previous target.
- The finding needs an unambiguous fingerprint in the current review. Missing or ambiguous identity cannot establish a persistent match.
Native technical audit observations currently have review-local identities, so their deferrals do not create the same persistent cross-review deferral. Check the status shown beside the decision rather than assuming every finding type supports it.
The inherited deferral applies to reviews created at or after the original deferral, rather than rewriting an older review’s decision. A decision already saved directly on a review remains its own decision.
Address and Dismiss are saved for their review. Comparison can show Previously marked to address, Previously dismissed, or Previously deferred on matched findings. That previous-decision context is different from an active deferral inherited into the new review. Do not assume that every earlier decision automatically becomes the new review’s decision.
To stop a persistent deferral, choose Reopen on an inherited deferred finding, clear its selected Defer decision, or change it to Address or Dismiss. This ends the active future deferral; it does not erase the decision history or evidence from earlier reviews.
Dismiss: explain why no fix is needed
Dismiss requires a reason: False positive, Expected, Not actionable, Duplicate, or Not reproducible. Choose the reason that describes your conclusion, rather than using dismissal to hide work that belongs in the backlog.
For example, a suggested change that would remove intentional behavior may be Expected. An observation you want to investigate later belongs in Defer. A Directional observation that has not been reproduced needs investigation before you can conclude it is a false positive.
The saved decision remains part of the review. A later comparison may show the prior dismissal as context; dismissal does not create a universal suppression rule for similar future observations.
Hand the selected work to a coding agent
The selected findings prompt includes the findings marked Address and carries the deferred and dismissed exclusions. A coding agent should respect those saved choices, reproduce Directional observations before repairing them, and verify the selected changes.
Copying a finding prompt does not itself save a decision. Select Address when you intend to add it to the repair scope. If you change your mind, click the selected decision again to clear it; inherited deferrals show Reopen.
Triage controls depend on workspace permissions and usable finding evidence. A review that is still building its finalized findings, or one whose feedback cannot be read safely, may show read-only or unavailable controls. If a save fails or another member changes the decision, refresh the review and check the displayed saved state before continuing.