GEMINI.md

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