req-change-workflow

name

req-change-workflow

description

Standardize requirement/feature changes in an existing codebase (especially Chrome extensions) by turning "改需求/需求变更/调整交互/改功能/重构流程" into a repeatable loop: clarify acceptance criteria, confirm current behavior from code, assess impact/risk, design the new logic, implement with small diffs, run a fixed regression checklist, and update docs/decision log. Use when the user feels the change process is chaotic, when edits tend to sprawl across files, or when changes touch manifest/service worker/OAuth/storage/UI and need reliable verification + rollback planning.

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.js).
• Core modules (e.g., src/core/...) and storage (src/core/local/...).
• Config/permissions changes (e.g., manifest.json).

Use scripts/impact_scan.sh to quickly find likely files, then read only the necessary ones.

Output artifact: “Current behavior summary” + a short file list (with why each file matters).

Step 3: Impact + risk assessment (change budget)

Before proposing a new design, list:

• Files/modules that must change and why.
• Risks: auth/session, storage migration, concurrency, caching, permission scopes, UX regressions.
• Testing checkpoints: what to verify manually (use references/regression-checklist.md).
• Rollback plan: what is safe to revert; what needs cleanup.

If changes touch manifest.json or service_worker.js, require a manual reload step in the validation plan (Chrome extensions cache aggressively).

Output artifact: “Impact & risk list” + “Rollback plan (1–3 bullets)”.

Step 4: Propose the new design (get approval)

Describe the new behavior using:

• New flow (bullet sequence) including edge cases.
• State model: key states, transitions, and failure recovery.
• Change boundaries: what stays unchanged.
• Observability: logs/events/UI hints for debugging.

Then ask the user to approve:

• The acceptance criteria (Step 1) as final.
• The file list (Step 2/3) as the change budget.
• The proposed design (this step).

Do not start editing code until the user says “同意/OK/按这个做”.

Step 5: Implement with minimal, localized diffs

Implementation rules:

• Prefer root-cause fixes over patches, but keep diffs small and focused.
• Avoid scattering logic across multiple entrypoints; centralize in one module when possible.
• Keep ES module imports explicit; avoid implicit globals.
• Add short JSDoc for exported functions when introducing new exports.
• User-visible logs: actionable Chinese messages (explain what to do next).

If the change involves async flows/cross-module calls/fallbacks, add Chinese comments explaining assumptions and failure handling.

Step 6: Validate (fixed regression loop)

• Run the manual pages referenced in references/regression-checklist.md.
• If manifest.json or service_worker.js changed: reload the extension before retesting.
• Record what you tested and the observed outcome (even if it is manual).

Step 7: Maintain (docs + decision log)

• Update project docs or inline notes for future maintainers.
• Add a short “Decision log” entry: why this design, what alternatives were rejected, and how to roll back.

Use the template in references/decision-log-template.md.

Resources

scripts/

• scripts/impact_scan.sh: fast file candidate scan via rg for keywords + common extension entrypoints.

references/

• references/change-brief-template.md: input template to lock scope + acceptance criteria.
• references/regression-checklist.md: manual regression checklist for this repo’s Chrome extension.
• references/decision-log-template.md: lightweight decision record template.