# 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.`