# Repository Guidelines

## Project Structure & Module Organization
This repository is centered on [`supervisor.py`](./supervisor.py), which defines the LangGraph workflow, subgraphs, retrieval helpers, reporting, and the CLI entry point. Domain knowledge lives in [`kb/`](./kb): `contract_kb.md`, `safety_kb.md`, `arbiter_kb.md`, plus `sources_manifest.json`. Generated Markdown outputs are written to [`reports/`](./reports). Keep new runtime modules near `supervisor.py` unless they are large enough to justify a dedicated package.

## Build, Test, and Development Commands
- `python supervisor.py` runs the local CLI demo for the multi-agent workflow.
- `python -m py_compile supervisor.py` performs a fast syntax check before committing.
- `Copy-Item .env.example .env` creates a local environment file; then fill in model URLs, API keys, and KB/report paths.

There is no pinned build script or dependency lockfile in the repo, so keep setup lightweight and document any new required commands in this file.

## Coding Style & Naming Conventions
Use Python 3.12+ style with 4-space indentation, type hints, and small focused helpers. Follow existing naming patterns:
- `snake_case` for functions and variables
- `PascalCase` for Pydantic models and config/state types
- clear graph-node names such as `contract_risk_subgraph`

Prefer explicit state updates over hidden side effects. Keep prompts, routing logic, and report generation readable and close to the node that owns them.

## Testing Guidelines
There is no formal test suite yet. For now, treat `python -m py_compile supervisor.py` as the minimum gate and manually exercise key CLI flows with realistic cases. If you add tests, place them under `tests/` and use names like `test_supervisor_routing.py` and `test_report_generation.py`.

## Commit & Pull Request Guidelines
Git history is not available in this environment, so follow a simple standard: short imperative commit subjects such as `Add report source aggregation` or `Fix arbiter routing fallback`. Keep commits scoped to one concern.

Pull requests should include:
- a concise summary of behavior changes
- any `.env` or KB changes reviewers must apply
- sample CLI input/output or generated report paths when user-visible behavior changes

## Security & Configuration Tips
Do not commit real API keys or local secrets; use `.env` only. Treat files in `reports/` as generated artifacts unless a review specifically needs them. When updating `kb/`, preserve source traceability so reports can cite the correct rule or knowledge entry.