req-change-workflowlisted

# Req Change Workflow ## Overview Use a lightweight, repeatable workflow to modify an existing requirement without scope creep or “边改边炸”. Produce clear artifacts at each gate so the user can approve before the implementation starts. ## Workflow (gated loop) Follow the steps in order. Do not implement code changes until the user approves Step 4. ### Step 0: Set the plan (optional but recommended) - Use `update_plan` to create 5–7 short steps: clarify → baseline → impact → design → implement → validate → document. - Keep exactly one step `in_progress` at a time and advance as you finish. ### Step 1: Clarify the change (lock scope first) Ask the user for the minimal inputs, then rewrite them into a clear “change brief”: - Target (1 sentence): what outcome changes. - Out of scope (1 sentence): explicitly what must NOT change. - Acceptance criteria (3–6 bullets): observable behaviors that can be verified. - “Must keep” constraints: compatibility, performance, security, no new dependencies, no network, etc. - Rollback expectation: can we revert by reverting a diff, or does it require data migration/backfill? Use the template in `references/change-brief-template.md`. ### Step 2: Confirm current behavior from code (baseline) Do not trust memory or assumptions. Locate the real entrypoints + current data flow and summarize it in 5–10 lines: - UI entrypoints (e.g., `sidepanel/`, `options/`) and where user actions are wired. - Background orchestration (e.g., `service_worker.