Cline rules for LangChain

# Cline and Roo rules

Project rules for Cline and Roo Code in this LangChain repository.
Use the project's commands. Do not invent a package manager, and do not run destructive shell commands.

## Tool use

- Read the files you will change before editing them.
- Prefer a focused patch over rewriting a whole file.
- Run the test command from this file after a behavior change, or say why you could not.
- Do not delete generated folders, lockfiles, or migrations unless the task says so.

## Stack

This repository builds LLM agents or chains. Model names and prompts are explicit. Tool calls validate their arguments. API keys stay in the environment.

## Layout

- Prompts and chain construction live in a module, not only in a notebook.
- Tools are small functions with a schema. They do not import the whole agent.
- Evals live next to the chain they score.

## Commands

- Tests: `pytest`
- Lint: `ruff check .`
- Eval: `Run the project's eval script if it has one`

Use the script the repo already defines when it differs from the command above.

## Conventions

- Name the model in code or config. Do not rely on an implicit default that can change under you.
- Validate tool arguments with the schema before side effects.
- Bound retries and timeouts on model and tool calls.
- Keep prompts in one place so a change is reviewable.
- Add or update an eval when you change a prompt that affects behavior.
- Secrets come from the environment. They are not default arguments.

## Testing

Add or update tests when behavior changes.

Test the tool with a fake model or a direct function call. Assert the side effect did not run on invalid input.

## Style

- Optimize for the next reader over the shortest diff.
- Comment only when the why is non-obvious.
- Name things the way neighboring files already do.
- Do not reformat code you did not change.

## Errors

- Fail at the boundary. Do not swallow errors.
- Return a structured tool error the model can read. Unexpected exceptions should fail the call, not invent an answer.

## Scope

- Do the requested task. Do not refactor unrelated code.
- Match the rigor already in the repo. Fix what you touch.
- Ask one clarifying question only when the task cannot be finished without it. Otherwise state the assumption and continue.

## Avoid

- Do not give a tool unrestricted shell or filesystem access.
- Do not log full prompts when they may contain user secrets.
- Do not catch a tool error and return a success string.
- Do not add a second orchestration library beside the one the repo uses.

## Done when

- The requested behavior works.
- `pytest` passes, including a test that a bad tool argument does not reach the side effect.
- The diff stays inside the task.
- You list anything you could not run.