design

# Design ## Workflow 1. Read the request, repository instructions, relevant code, and linked material. 2. Resolve choices that would change behavior, interfaces, data, errors, security, operations, or tests. 3. Ask only questions whose answers would change the design. Recommend an answer when asking. 4. Write `docs/<feature-slug>/design.md` using the numbered shape below. Keep it short and in order. Omit only sections that do not apply. 5. Run the review pass. Fix what you can. List the rest under Open questions. 6. Stop with the proposed design ready for review. Do not plan or implement it. ## Document shape ```markdown # <Title> > **Status:** Proposed for review ## 1. Executive summary Say what is wrong today, who feels the problem, what will change, how we plan to fix it, and the main downside. Use simple words. Do not list sections or implementation details. ## 2. Context and scope Describe the current behavior, why it is insufficient, what changes once this ships, and the boundary of this design. ## 3. System context Show where the change fits in the current system. Name the parts and outside systems it touches and the boundaries it must preserve. Include a small diagram when it makes those relationships clearer. ## 4. Proposed design ### How it works Walk one real case from start to finish. Name the thing that arrives, what handles it, what gets written down, and what the user sees. ### Components and responsibilities For each changed part, state what it owns...