Spaces:
Running
Running
| # Copilot Instructions for the Project | |
| ## Ignore files and folders | |
| - You should ignore the files and folder bellow: | |
| - .venv/ | |
| - .vscode/ | |
| - __pycache__/ | |
| - build/ | |
| - chroma.db/ | |
| - vibe_dspy.egg-info/ | |
| - Ignore files that are mentioned inside .gitignore | |
| ## Environment and Secrets | |
| - All credentials and config are loaded from `.env` using `python-dotenv`. | |
| - For DB access, use `DB_USER`, `DB_PASS_ENCODED`, `DB_HOST`, `DB_PORT`, `DB_DATABASE`. | |
| - For LLMs, use `AZURE_OPENAI_API_KEY`, `AZURE_OPENAI_ENDPOINT`, `AZURE_OPENAI_DEPLOYMENT_NAME`. | |
| ## Conventions and Workflows | |
| - Always use environment variables for secrets and config. | |
| - Always use `uv run ` to run code and code tools | |
| - Always use `pytest` for unit tests and run then with `uv run pytest`. | |
| - Always use `uv` and `uv add` to manage dependencies. | |
| ## References | |
| - See `README.md` for high-level goals and links. | |
| ## Security and Environment File Handling | |
| - **Never read, modify, index, or delete any `.env` files.** | |
| - Do not access, print, or manipulate environment variable files (e.g., `.env`) in any way. | |
| - All environment configuration is managed outside of AI agent operations for security and compliance. | |
| ## Commit Message Guidelines (Conventional Commits) | |
| All commit messages should adhere to the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/). This provides a standardized format for commit messages, making it easier to understand the purpose of a commit and to automate changelog generation. | |
| The basic structure of a commit message is: | |
| ``` | |
| <type>[optional scope]: <description> | |
| [optional body] | |
| [optional footer(s)] | |
| ``` | |
| ### Type | |
| The `type` is a mandatory prefix that indicates the kind of change introduced by the commit. Common types include: | |
| * `feat`: A new feature | |
| * `fix`: A bug fix | |
| * `docs`: Documentation only changes | |
| * `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.) | |
| * `refactor`: A code change that neither fixes a bug nor adds a feature | |
| * `perf`: A code change that improves performance | |
| * `test`: Adding missing tests or correcting existing tests | |
| * `build`: Changes that affect the build system or external dependencies (example scopes: npm, gulp, broccoli, make) | |
| * `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) | |
| * `chore`: Other changes that don't modify src or test files | |
| * `revert`: Reverts a previous commit | |
| ### Scope (Optional) | |
| The `scope` provides additional contextual information about the change. It is enclosed in parentheses after the `type`. For example, `feat(parser): add ability to parse arrays`. | |
| ### Description | |
| The `description` is a concise, imperative, present-tense summary of the change. It should not be capitalized and should not end with a period. | |
| ### Body (Optional) | |
| The `body` provides a longer, more detailed explanation of the commit's changes. It should be separated from the description by a blank line. | |
| ### Footer(s) (Optional) | |
| The `footer` can contain information about breaking changes, references to issues, or other metadata. Breaking changes should start with `BREAKING CHANGE:` followed by a description. | |
| ### Examples | |
| * `feat: add new user authentication module` | |
| * `fix(auth): correct password validation bug` | |
| * `docs: update README with installation instructions` | |
| * `refactor(api): simplify error handling logic` | |
| * `BREAKING CHANGE: refactor(core): remove old API endpoint` | |
| `The /api/v1/old-endpoint has been removed. Use /api/v1/new-endpoint instead.` |