Product risks — Task Assistant
These are prospective decision risks for the fictional prototype and any later exploration. They do not describe incidents or customer outcomes.
| Risk | Early signal | Mitigation and decision trigger |
|---|---|---|
| Conversation is mistaken for completed action | Participants believe a message already changed a task | Keep proposal and confirmed state distinct. Redesign the transition if two or more participants misread it. |
| Preview does not establish scope | People cannot name the task or before-and-after value | Lead with readable titles and show values. Do not add bulk breadth until the tested preview is understood. |
| Ambiguity creates unsafe assumptions | People expect the guide to choose among similar tasks | Ask a clarification question and preserve a no-change state. Test clearer choices before any ranking approach. |
| Old conversational context targets the wrong task | A pronoun after a board-wide answer still proposes a change to an earlier task | Expire single-task context when an intervening answer has no single record. Treat any wrong-target proposal as a release blocker. |
| Hidden context survives an explicit cleanup or replacement | A pronoun after Clear chat, Reset, or Undo still targets the previously discussed task | Expire task context with transcript cleanup and confirmed board replacement. Block release if any context-expiry sequence opens a proposal. |
| Blocked status lacks an actionable reason | A task is moved to Blocked but the board cannot explain what needs attention | Disable or refuse the transition until a nonblank reason is confirmed through its own preview. Keep reason and status as separate reviewed decisions. |
| Entry points enforce different status rules | Conversation refuses a reasonless Blocked change while a selector or defensive handler still prepares it | Use one eligibility policy across interpretation, options, and mutation preparation. Treat any bypass as a release blocker. |
| Long requests obscure the intended action | A valid task change is buried inside an unreviewable prompt and still becomes a proposal | Cap one request at 500 characters, disclose the limit beside the field, and reject oversized input before interpreting it. |
| Transcript growth degrades the local workspace | Repeated exchanges create an increasingly heavy page or make recent context difficult to find | Retain the most recent 40 messages in the tab and confirm that trimming conversation never changes tasks or proposals. |
| Preview direction is unclear | A person can name the affected task but reverses the old and proposed values | Label Before and After explicitly, announce affected-task count, and include both in keyboard and screen-reader checks. |
| Recovery path is not discoverable | Participants cannot cancel or use reviewed undo | Keep both flows in the same review pattern; revise labels or sequence when sessions show failure. |
| Replacement preview hides a non-status change | Reset would silently restore a saved title, project, due date, priority, blocker, or task code because only status and owner were compared | Compare every visible task field and name each changed field. Treat any unlisted replacement difference as a release blocker. |
| Replacement changes membership without disclosure | A reset adds a missing fixture task or removes an extra saved task without naming that record | Build the review from the union of current and replacement task identities and label additions and removals explicitly. |
| No-op reset creates misleading recovery | An unchanged reset produces an Undo control even though no task value changed | Confirm storage recovery when requested, but create Undo only for a visible task difference and say when no new recovery step exists. |
| Oversized local state makes review unusable | A restored board or text field expands beyond a person’s practical ability to inspect the preview | Reject more than 50 tasks and bound identity/display fields while preserving the raw browser payload for explicit recovery. Revisit these limits only with a different information architecture. |
| Transient chat control is mistaken for a task action | Participants expect Clear chat to apply, cancel, reset, or undo a task update | Keep the open proposal visible and task values unchanged; test labels and placement before coupling chat cleanup to task state. |
| Local sample boundary is confused with a connected product | Participants assume login, permissions, audit trail, or external updates | State the deterministic local boundary. Gate integrations on access, privacy, reliability, support, and model-evaluation requirements. |
Review the signals alongside the proposed session protocol. For every safety misunderstanding, preserve the request, the visible proposal, the participant explanation, confirmation choice, and final task state in the study note. Repeated misunderstanding should change the tested workflow before language expansion or commercial investment.