update agents file
build / build (push) Successful in 11s
pytest / pytest (push) Successful in 29s

This commit is contained in:
Matteo Rosati
2026-04-23 22:03:16 +02:00
parent ebf664a25a
commit 55bbd897f4
+5 -5
View File
@@ -2,9 +2,9 @@
## Project Structure & Module Organization ## Project Structure & Module Organization
`chromy/` contains the Python package and CLI implementation. The entrypoint is `chromy/main.py`, parser wiring is in `chromy/cli_parser.py`, command dispatch is in `chromy/cli_app.py`, and typed command inputs live in `chromy/command_inputs.py`. Command-specific behavior belongs in `chromy/handlers/`. Shared Chroma, embedding, chunking, and formatting helpers live in package modules such as `chroma_functions.py`, `embed.py`, `chunk_functions.py`, and `utilities.py`. `chromy/` contains the Python package and CLI implementation. The entrypoint is `chromy/main.py`, which loads environment variables and invokes the Typer app defined in `chromy/cli.py`. Command-specific behavior belongs in `chromy/handlers/`. Shared Chroma, embedding, chunking, and formatting helpers live in package modules such as `chroma_functions.py`, `embed.py`, `chunk_functions.py`, and `utilities.py`.
`tests/` contains the pytest suite. `plans/` holds planning notes. Generated data and build outputs such as `chroma/`, `dist/`, `chromy.egg-info/`, caches, and `.venv/` are not source. `tests/` contains the test suite for the CLI, handlers, and embedding helpers. Generated data and build outputs such as `chroma/`, `dist/`, `chromy.egg-info/`, `.pytest_cache/`, `.mypy_cache/`, `.ruff_cache/`, and `.venv/` are not source.
## Build, Test, and Development Commands ## Build, Test, and Development Commands
@@ -16,15 +16,15 @@
## Coding Style & Naming Conventions ## Coding Style & Naming Conventions
Use Python 3.12+ syntax, type hints, and `from __future__ import annotations`. Follow the current style: 4-space indentation, snake_case functions and modules, PascalCase dataclasses/classes, and explicit command input objects instead of raw `argparse.Namespace` in handlers. Keep handlers focused on CLI orchestration; place reusable database or formatting logic in shared modules. Use Python 3.12+ syntax, type hints, and `from __future__ import annotations`. Follow the current style: 4-space indentation, snake_case functions and modules, PascalCase classes, and Typer command functions in `chromy/cli.py` that delegate to small handler functions. Keep handlers focused on CLI orchestration and user-facing output; place reusable database, chunking, embedding, and formatting logic in shared modules.
## Testing Guidelines ## Testing Guidelines
Tests use pytest and currently include `unittest.TestCase`-style cases. Name test files `test_*.py` and test methods `test_*`. Prefer mocking Chroma-facing functions in handler tests so unit tests stay deterministic. Run `uv run pytest -q` before submitting changes, and add tests for new commands, parser behavior, handlers, and error paths. Tests run with pytest and are currently written in `unittest.TestCase` style. Name test files `test_*.py` and test methods `test_*`. Prefer mocking Chroma-facing and filesystem-facing functions in CLI and handler tests so unit tests stay deterministic. Run `uv run pytest -q` before submitting changes, and add tests for new commands, Typer wiring, handlers, and error paths.
## Commit & Pull Request Guidelines ## Commit & Pull Request Guidelines
Git history uses short, imperative, lowercase commit subjects, for example `move top-level modules into a real package` and `replace argparse.Namespace plumbing with typed command inputs`. Keep commits scoped to one logical change. Git history uses short, imperative, lowercase commit subjects, for example `move top-level modules into a real package` and `add typer-based delete command`. Keep commits scoped to one logical change.
Pull requests should include a concise description, test results, and notes for any CLI behavior changes. Link related issues or plan files when applicable. Include terminal output examples or screenshots only when user-facing command output changes. Pull requests should include a concise description, test results, and notes for any CLI behavior changes. Link related issues or plan files when applicable. Include terminal output examples or screenshots only when user-facing command output changes.