wronglisted

# Wrong: reset and re-evaluate The user has rejected the current approach or the attempted solution has failed. Stop extending or defending it. Return to the last supported facts and reassess the problem. ## Boundaries Use `wrong` when the object of rejection is the assistant's work or the active solution path. - “Your fix is wrong; start over” → `wrong` - “That explanation does not match the code” → `wrong`, then re-investigate - “This endpoint returns the wrong status; why?” → `clarify` - “Explore three alternative architectures” → `brainstorm` A rejection does not automatically require several new designs, a formal plan, implementation, or comprehensive tests. Match the response to what the user rejected and requested. ## Workflow ### 1. Identify the rejected claim or approach State concisely: - what the assistant attempted; - what the user says is wrong; - which assumptions or evidence supported the failed direction; - what remains established. Do not make the user repeat context already present in the conversation. ### 2. Discard the failed premise Stop layering fixes on the rejected approach. Remove it from the working hypothesis unless independent evidence still supports a specific part. If changes were already made, inspect the actual diff before deciding whether to revise or revert them. Do not preserve failed machinery as compatibility scaffolding. ### 3. Re-investigate the responsible boundary Read the relevant code, configuration, documentation, err