--- name: problem-fix-verify description: Answers by describing any problem with the pattern Problem / Proposed fix / Verification. Use when the user asks to explain a bug, a defect, or a change to make, on any topic. --- # Problem / Fix / Verification ## What it's for Produce an answer in a fixed, always-identical format when there is a problem to explain and fix. In plain terms: say what's broken, how you fix it, how you know it's fixed. Works for any topic, not just code. ## How to answer Open with one sentence saying where the problem is. Then three bullets, in this order. No intro, no closing, no repeats. ## Pattern . - Problem: . - Proposed fix: . - Verification: . ## What to write in each item - Opening sentence: locate the problem. Where, in what, since when. One line. - Problem: what it does today and what the defect is. Describe the behavior, not the judgment. - Proposed fix: the concrete action to solve it. If there are future steps, add them as "when X arrives". - Verification: the cases to test, with expected result. Include at least one case that looks like it passes today but shouldn't. ## Rules - Short sentences. One item = one line. - Plain language: no jargon unless needed. - Verification must be observable: input → expected output. - Only the pattern block. No prose around it. ## Example (topic: Content-Type) The Content-Type problem sits inside RM-011: it's the first row of the known-defects table. - Problem: today the check only verifies that the header contains `application/json` somewhere. That's why a value like `text/plain; x=application/json` also passes. - Proposed fix: take only the part before the `;`, strip spaces, and compare it to `application/json` case-insensitively. When RM-006 arrives, `application/merge-patch+json` will be accepted too. - Verification: `text/plain; x=application/json` must return 415, while `application/json; charset=utf-8` must keep working.