diff --git a/.github/chatmodes/debug.chatmode.md b/.github/chatmodes/debug.chatmode.md deleted file mode 100644 index cb02ceb03f..0000000000 --- a/.github/chatmodes/debug.chatmode.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -description: 'Debug application to find and fix a bug' -model: GPT-5 (Preview) -tools: ['extensions', 'codebase', 'usages', 'vscodeAPI', 'problems', 'changes', 'testFailure', 'terminalSelection', 'terminalLastCommand', 'fetch', 'findTestFiles', 'searchResults', 'githubRepo', 'todos', 'runTests', 'runCommands', 'runTasks', 'editFiles', 'runNotebooks', 'search', 'new', 'Microsoft Docs', 'get_issue', 'get_issue_comments', 'get-library-docs', 'playwright', 'pylance mcp server'] ---- - -# Debug Mode Instructions - -You are in debug mode. Your primary objective is to systematically identify, analyze, and resolve bugs in the developer's application. Follow this structured debugging process: - -## Debugging process - -• **Gather context**: Read error messages/stack traces, examine recent changes, identify expected vs actual behavior. If the issue is a GitHub issue link, use 'get_issue' and 'get_issue_comments' tools to fetch the issue and comments. -• **Root cause analysis**: Trace execution path, check for common issues, use search tools to understand component interactions -• **Targeted fix**: Make minimal changes addressing root cause, follow existing patterns, consider edge cases -• **Verify thoroughly**: Run tests to confirm fix, check for regressions, test edge cases -• **Document**: Summarize what was fixed, explain root cause, suggest preventive measures. Do not document this in the repo itself, only in the chat history and commit messages. - -## Local server setup - -You MUST check task output readiness before debugging, testing, or declaring work complete. - -- Start the app: Run the "Development" compound task (which runs both frontend and backend tasks) -- Check readiness from task output (both must be ready): - - Frontend (task: "Frontend: npm run dev"): look for the Vite URL line. Either of these indicates ready: - - "Local: http://127.0.0.1:..." or "➜ Local: http://127.0.0.1:..." - - Backend (task: "Backend: quart run"): wait for Hypercorn to bind. Ready when you see: - - "INFO:hypercorn.error:Running on http://127.0.0.1:50505" (port may vary if changed) -- If either readiness line does not appear, the server is not ready. Investigate and fix errors shown in the corresponding task terminal before proceeding. -- Hot reload behavior: - - Frontend: Vite provides HMR; changes in the frontend are picked up automatically without restarting the task. - - Backend: Quart is started with --reload; Python changes trigger an automatic restart. - - If watchers seem stuck or output stops updating, stop the tasks and run the "Development" task again. -- To interact with the application, use the Playwright MCP server -- To run the Python backend pytest tests, use the "run tests" tool -- To run the Playwright E2E tests of the whole app (with a mocked backend), run `pytest tests/e2e.py --tracing=retain-on-failure`. diff --git a/.github/chatmodes/fixer.chatmode.md b/.github/chatmodes/fixer.chatmode.md new file mode 100644 index 0000000000..0e35b6450b --- /dev/null +++ b/.github/chatmodes/fixer.chatmode.md @@ -0,0 +1,27 @@ +--- +description: 'Fix and verify issues in app' +model: GPT-5 (Preview) +tools: ['extensions', 'codebase', 'usages', 'vscodeAPI', 'problems', 'changes', 'testFailure', 'fetch', 'findTestFiles', 'searchResults', 'githubRepo', 'runTests', 'runCommands', 'runTasks', 'editFiles', 'runNotebooks', 'search', 'new', 'get_issue', 'get_issue_comments', 'get-library-docs', 'playwright', 'pylance mcp server'] +--- + +# Fixer Mode Instructions + +You are in fixer mode. When given an issue to fix, follow these steps: + +• **Gather context**: Read error messages/stack traces/related code. If the issue is a GitHub issue link, use 'get_issue' and 'get_issue_comments' tools to fetch the issue and comments. +• **Make targeted fix**: Make minimal changes to fix the issue. Do not fix any issues that weren't identified. If any other issues pop up, note them as potential issues to be fixed later. +• **Verify fix**: Test the application to ensure the fix works as intended and doesn't introduce new issues. For a backend change, add a new test in the tests folder and run the tests with VS Code "runTests" tool. RUN all the tests using that tool, not just the tests you added. Try to add tests to existing test files when possible, like test_app.py. DO NOT run the `pytest` command directly or create a task to run tests, ONLY use "runTests" tool. For a frontend change, use the Playwright server to manually verify or update e2e.py tests. + +## Local server setup + +You MUST check task output readiness before debugging, testing, or declaring work complete. + +- Start the app: Run the "Development" compound task (which runs both frontend and backend tasks) and check readiness from task output. Both must be in ready state: + - Frontend task: "Frontend: npm run dev" + - Backend task: "Backend: quart run" +- Investigate and fix errors shown in the corresponding task terminal before proceeding. You may sometimes see an error with /auth_setup in frontend task, that's due to the backend server taking longer to startup, and can be ignored. +- Both of the tasks provide hot reloading behavior: + - Frontend: Vite provides HMR; changes in the frontend are picked up automatically without restarting the task. + - Backend: Quart was started with --reload; Python changes trigger an automatic restart. + - If watchers seem stuck or output stops updating, stop the tasks and run the "Development" task again. +- To interact with a running application, use the Playwright MCP server diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md new file mode 100644 index 0000000000..9a9fe8e1b2 --- /dev/null +++ b/.github/copilot-instructions.md @@ -0,0 +1,51 @@ +# Adding new data + +New files should be added to the `data` folder, and then either run scripts/prepdocs.sh or scripts/prepdocs.ps1 to ingest the data. + +# Adding a new azd environment variable + +An azd environment variable is stored by the azd CLI for each environment. It is passed to the "azd up" command and can configure both provisioning options and application settings. +When adding new azd environment variables, update: + +1. infra/main.parameters.json : Add the new parameter with a Bicep-friendly variable name and map to the new environment variable +1. infra/main.bicep: Add the new Bicep parameter at the top, and add it to the `appEnvVariables` object +1. azure.yaml: Add the new environment variable under pipeline config section +1. .azdo/pipelines/azure-dev.yml: Add the new environment variable under `env` section +1. .github/workflows/azure-dev.yml: Add the new environment variable under `env` section + +# Adding a new setting to "Developer Settings" in RAG app + +When adding a new developer setting, update: + +* frontend: + * app/frontend/src/api/models.ts : Add to ChatAppRequestOverrides + * app/frontend/src/components/Settings.tsx : Add a UI element for the setting + * app/frontend/src/locales/*/translations.json: Add a translation for the setting label/tooltip for all languages + * app/frontend/src/pages/chat/Chat.tsx: Add the setting to the component, pass it to Settings + * app/frontend/src/pages/ask/Ask.tsx: Add the setting to the component, pass it to Settings + +* backend: + * app/backend/approaches/chatreadretrieveread.py : Retrieve from overrides parameter + * app/backend/approaches/retrievethenread.py : Retrieve from overrides parameter + * app/backend/app.py: Some settings may need to be sent down in the /config route. + +# When adding tests for a new feature: + +All tests are in the `tests` folder and use the pytest framework. +There are three styles of tests: + +* e2e tests: These use playwright to run the app in a browser and test the UI end-to-end. They are in e2e.py and they mock the backend using the snapshots from the app tests. +* app integration tests: Mostly in test_app.py, these test the app's API endpoints and use mocks for services like Azure OpenAI and Azure Search. +* unit tests: The rest of the tests are unit tests that test individual functions and methods. They are in test_*.py files. + +When adding a new feature, add tests for it in the appropriate file. +If the feature is a UI element, add an e2e test for it. +If it is an API endpoint, add an app integration test for it. +If it is a function or method, add a unit test for it. +Use mocks from conftest.py to mock external services. + +When you're running tests, make sure you activate the .venv virtual environment first: + +```bash +source .venv/bin/activate +```