GacUI/.github/prompts/1-design.prompt.md

# Design

- Check out `Accessing Task Documents` and `Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md` and `*.ps1` files.
- All `*.md` and `*.ps1` files should exist; you should not create any new files unless explicitly instructed.
  - The `Copilot_Scrum.md` file should already exist.
  - If you cannot find the file, you are looking at a wrong folder.
  - `Copilot_Task.md` should be put in the same folder.
- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.

## Goal and Constraints

- Your goal is to finish a design document in `Copilot_Task.md` to address a problem.
- You are only allowed to update `Copilot_Task.md`
  - When the task comes from `Copilot_Scrum.md`, you should mark a task being taken in `Copilot_Scrum.md`.
- You are not allowed to modify any other files.
- The phrasing of the request may look like asking for code change, but your actual work is to write the design document.

## Copilot_Task.md Structure

- `# !!!TASK!!!`: This file always begins with this title.
- `# PROBLEM DESCRIPTION`: An exact copy of the problem description I gave you.
- `# UPDATES`: For multiple `## UPDATE` sections. It should always exist even there is no update.
  - `## UPDATE`: There could be multiple occurrences. Each one has an exact copy of the update description I gave you.
- `# INSIGHTS AND REASONING`.
- `# AFFECTED PROJECTS`.

## Step 1. Identify the Problem

- The problem I would like to solve is in the chat messages sent with this request.
- Find `# Problem` or `# Update` in the LATEST chat message.
  - Ignore any of these titles in the chat history.
  - If there is nothing: it means you are accidentally stopped. Please continue your work.
    - Read `Copilot_Task.md` thoroughly, it is highly possible that you were working on the request described in the last section in `# PROBLEM DESCRIPTION`.

### Create new Document (only when "# Problem" appears in the LATEST chat message)

Ignore this section if there is no "# Problem" in the LATEST chat message
I am starting a fresh new request.

- Find and execute `copilotPrepare.ps1` to clean up everything from the last run.
  - This script will clean up everything in `Copilot_Task.md`, `Copilot_Planning.md` and `Copilot_Execution.md`.
  - It is normal to find large amount of changes in these 3 files, DO NOT panic.
- After `copilotPrepare.ps1` finishes, copy precisely my problem description in `# Problem` from the LATEST chat message under a `# PROBLEM DESCRIPTION`.
  - Find task from `Copilot_Scrum.md` if the problem description is in the following format:
    - `Next`: Find the first incomplete task in `Copilot_Scrum.md`.
    - `Complete task No.X`: Locate the specific task in `Copilot_Scrum.md`.
    - There is a bullet list of all tasks at the beginning of `# TASKS`. Mark the specific task as being taken by changing `[ ]` to `[x]`.
  - Otherwise, the task is the problem description itself.
  - Find the details of the specific task, copy everything in this task to `# PROBLEM DESCRIPTION`.
- Add an empty `# UPDATES` section after `# PROBLEM DESCRIPTION`.

### Update current Document (only when "# Update" appears in the LATEST chat message)

Ignore this section if there is no "# Update" in the LATEST chat message
I am going to propose some change to `Copilot_Task.md`.

- Copy precisely my problem description in `# Update` from the LATEST chat message to the `# PROBLEM DESCRIPTION` section, with a new sub-section `## UPDATE`.
- The new `## UPDATE` should be appended to the end of the existing `# UPDATES` section (aka before `# INSIGHTS AND REASONING`).
  - **NOTICE**: When the update is triggered by the automatic review process (aka `review.prompt.md`), do not insert such `## UPDATE`.
- Follow my update to change the design document.

## Step 2. Understand the Goal and Quality Requirement

- Analyse the source code and provide a high-level design document.
- The design document must present your idea, about how to solve the problem in architecture-wide level.
- The design document must describe the what to change, keep the description in high-level without digging into details about how to update the source code.
- The design document must explain the reason behind the proposed changes.
- The design document must include any support evidences from source code or knowledge base.

### Tips about Designing

- Leverage the source code from dependencies in `Import` folder as much as you can.
- Source code in the `Source` and `Test` folder is subject to modify.
- The project should be highly organized in a modular way. In most of the cases you are using existing code as API to complete a new feature.
- If you think any existing API in the current project should offer enough functionality, but it is currently missing something:
  - Such issue may prevent the current task from being able to complete.
    - You should point it out.
    - I need such information to review incomplete tasks.
    - If the current task cannot be completed without fixing this issue, it is acceptable to only having the analysis.
  - DO NOT make assumption that you can't prove.
- If you have multiple proposals for a task:
  - List all of them with pros and cons.
  - You should decide which is the best one.

## Step 3. Finish the Document

- Your goal is to write a design document to `Copilot_Task.md`. DO NOT update any other file including source code.
- Whatever you think or found, write it down in the `# INSIGHTS AND REASONING` section.

## Step 3.1. Fill the "# AFFECTED PROJECTS" section

- Solutions and projects you need to work on could be found in `REPO-ROOT/Project.md`.
- Identify all changes you need to make in a high level.
- According to what you need to change, selectively fill this section using bullet-list, each item could be one of the following:
  - `- Build the solution in folder <SOLUTION-ROOT>`.
    - When the configuration is important, also specify the configuration, e.g., `Debug|x64`.
  - `- Run CLI|UnitTest project <PROJECT-NAME>`.
    - When the configuration is important, also specify the configuration, e.g., `Debug|x64`.
  - If a project could be skipped conditionally, write down what should trigger the running, usually it should be a list of files or projects. But you can describe it in a high level instead of listing all files.
  - If a project should always run, use `Always Run` instead of just `Run`.
- The bullet-list will be executed in its order in the future.

## Step 4. Mark the Completion

- Ensure there is a `# !!!FINISHED!!!` mark at the end of `Copilot_Task.md` to indicate the document reaches the end.