{"owner":"0xPlaygrounds","repo":"rig","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nOperational instructions for AI coding agents working in Rig.\n\nFor contributor-facing policy, PR expectations, and accountability guidance, see\n`CONTRIBUTING.md`. This file is for repository-specific engineering rules that\nagents must follow while reading, editing, testing, and documenting code.\n\n## First Principles\n\n- Read the existing implementation before changing code.\n- Keep changes scoped to the user's request.\n- Prefer existing Rig traits, builders, modules, and error types over new abstractions.\n- Do not add TODOs, stubs, placeholder implementations, or speculative APIs.\n- Do not make commits, stage changes, push branches, or open PRs unless the user explicitly asks.\n- Do not discard user changes.\n\n## Repository Shape\n\n- Root facade crate: `rig`\n- Core crate: `crates/rig-core`\n- Companion provider and vector-store crates: `crates/rig-*`\n- Derive macros: `crates/rig-derive`\n- Workspace example packages: `examples/*`\n- Per-crate examples: `crates/<crate>/examples/`\n- Root integration test targets: `tests/*.rs`\n- Provider test modules: `tests/providers/<provider>/`\n- Provider cassette fixtures: `tests/cassettes/<provider>/`\n- External-service integration tests: `tests/integrations/`\n\nThe root `rig` crate re-exports `rig-core` and exposes companion crates behind\nfeature flags. Check `Cargo.toml` and `src/lib.rs` before documenting or changing\nexposed features, integrations, or module paths. If adding or exposing a\ncompanion provider/vector-store crate, update the root dependency, feature,\nfacade re-export, examples, README, and crate docs as applicable.\n\n## Core Architecture\n\nRig is built around provider-agnostic traits:\n\n- `CompletionModel` for text completion and chat models\n- `EmbeddingModel` for embedding generation\n- `VectorStoreIndex` for vector similarity search\n- `Tool` for callable tools\n\nUse these traits instead of creating parallel abstractions.\n\nConfigurable public types should follow Rig's builder style:\n\n```rust\nlet agent = client\n    .agent(openai::GPT_5_2)\n    .preamble(\"System prompt\")\n    .tool(my_tool)\n    .temperature(0.8)\n    .build();\n```\n\nProvider clients use the generic client architecture:\n\n```rust\npub struct Client<Ext = Nothing, H = reqwest::Client> {\n    // ...\n}\n```\n\nProviders declare capabilities explicitly with `Capable<T>` and `Nothing`.\n\n## WASM Compatibility\n\nRig supports WebAssembly targets.\n\nUse `WasmCompatSend` and `WasmCompatSync` in trait bounds instead of raw `Send`\nand `Sync`.\n\nUse `WasmBoxedFuture` for boxed futures.\n\nWhen an error type stores boxed errors, use platform-specific bounds:\n\n```rust\n#[cfg(not(target_family = \"wasm\"))]\nBox<dyn std::error::Error + Send + Sync + 'static>\n\n#[cfg(target_family = \"wasm\")]\nBox<dyn std::error::Error + 'static>\n```\n\n## Error Handling\n\n- Do not use `String` as an error type for new fallible APIs.\n- Use explicit error enums with `thiserror`.\n- Do not use `.unwrap()` or `.expect()` on fallible operations unless the condition is genuinely impossible and obvious from the code.\n- Prefer `?` and meaningful error conversions.\n\n## Documentation\n\n- Add `///` docs to new public items.\n- Add `//!` docs to new public modules.\n- Keep examples current with actual APIs, model constants, module paths, and feature flags.\n- Mark examples `no_run` when they require external credentials or services.\n- Do not document integrations, features, model constants, or crate paths without checking the code and manifests.\n- Keep root README, crate READMEs, and crate-level Rust docs consistent when changing public-facing behavior.\n\n## Provider Changes\n\nBefore implementing or modifying a provider, study the closest existing provider\nimplementation. For OpenAI-compatible chat APIs, start with:\n\n`crates/rig-core/src/providers/openai/`\n\nProvider implementations should include:\n\n- Provider extension and builder types\n- `Provider` implementation\n- `Capabilities` declaration\n- `ProviderBuilder` implementation\n- `ProviderClient::{from_env, from_val}`\n- public `Client` and `ClientBuilder` aliases; the `ClientBuilder` API-key generic must match `ProviderBuilder::ApiKey`\n- explicit API-key marker/auth types with redacted debug behavior for credential-bearing values\n- model constants where useful\n- request conversion from Rig request types\n- response conversion into Rig response types\n- streaming support when the provider supports streaming\n- provider-response error preservation through the relevant Rig error helpers\n- `ProviderResponseExt` and telemetry spans following existing GenAI conventions\n- tests or examples appropriate to the provider\n\nDo not add request or response fields that do not exist in the provider's real API.\n\nFor provider bug fixes or behavior changes, add or update regression coverage in\none of these places, preferring the smallest reliable scope:\n\n- unit tests near the implementation in `crates/rig-core/src/providers/...`;\n- cassette-backed provider tests in `tests/providers/<provider>/cassette/`;\n- ignored live tests only when cassette replay is unsuitable.\n\n## Vector Store Changes\n\nVector stores should live in companion crates unless there is a strong reason to\nplace them in `rig-core`.\n\nImplement both:\n\n- `top_n`\n- `top_n_ids`\n\nUse an appropriate backend-specific filter type.\n\nReturn `VectorStoreError` variants instead of ad hoc string errors.\n\nUse `WasmCompatSend` and `WasmCompatSync` bounds.\n\n## Agent Hook Changes\n\nAgent hooks are per-run lifecycle observers and steerers. `AgentHook` exposes\none method per lifecycle event, and every method receives the run-scoped\n`HookContext` (run id, turn, streaming flag, agent name, shared `Scratchpad`).\nEach method returns an event-specific action type, so unsupported combinations\nare rejected by the compiler.\n\nComposition through `HookStack` remains event-dependent:\n\n- **Completion calls accumulate and merge.** Every\n  `CompletionCallAction::Patch(RequestPatch)` is merged in registration order;\n  `Stop` short-circuits the stack.\n- **Tool calls and results chain.** `ToolCallAction::Rewrite` and\n  `ToolResultAction::Rewrite` are threaded into later hooks. A tool-call `Skip`\n  or either event's `Stop` is terminal.\n- **Invalid tool calls** return `InvalidToolCallAction` (`Fail`, `Retry`,\n  `Repair`, `Skip`, or `Stop`).\n- **Observe-only events** return `ObservationAction` (`Continue` or `Stop`).\n\nRegister observe-only hooks before steering hooks because stop actions\nshort-circuit. Nested `HookStack`s must preserve merge and chaining semantics.\n`RequestPatch` remains per-turn and non-sticky; its documented merge rules are\nappend `extra_context`, shallow-merge `additional_params`, intersect\n`active_tools`, and last-writer-wins scalars/history with a warning.\n\nEvery hook semantic must behave identically on streaming and non-streaming\nsurfaces (`AgentRunner::stream` and `AgentRunner::run` share `drive_agent`).\n\n## Style\n\n- Use full `where` clauses for complex trait bounds.\n- Comments should explain why, not restate what the code does.\n- Follow local naming, module layout, and test patterns.\n- Avoid unrelated refactors.\n\n## Cassette Regression Tests\n\nProvider regressions should usually include cassette-backed tests. Read\n`tests/README.md` before adding, updating, or running provider tests.\n\n- Test code lives under `tests/providers/<provider>/cassette/`.\n- Fixtures live under `tests/cassettes/<provider>/...`.\n- Replay cassettes by default; this should not require provider API keys.\n- Record mode requires the relevant provider API key and overwrites fixtures.\n- Keep record runs targeted to the provider and test being changed.\n\nReplay examples:\n\n```bash\ncargo test -p rig --all-features --test openai openai::cassette -- --nocapture --test-threads=1\ncargo test -p rig --all-features --test anthropic anthropic::cassette -- --nocapture --test-threads=1\ncargo test -p rig --all-features --test gemini gemini::cassette -- --nocapture --test-threads=1\n```\n\nRecord example:\n\n```bash\nRIG_PROVIDER_TEST_MODE=record \\\n  cargo test -p rig --all-features --test openai openai::cassette -- --nocapture --test-threads=1\n```\n\nReview cassette diffs carefully. They must not contain API keys, bearer tokens,\ncookies, provider account identifiers, or unrelated request/response churn. The\nrepo includes cassette scrub/safety checks in `tests/common/cassette_safety.rs`,\nbut agents are still responsible for inspecting generated fixtures before\npresenting changes.\n\n## Verification\n\nRun the smallest useful checks first, then broaden as needed. For tests, prefer\nthe targeted commands in `tests/README.md` before running broad workspace checks.\n\nBefore considering code complete, run when feasible:\n\n```bash\ncargo fmt\ncargo clippy --all-targets --all-features\ncargo test\n```\n\nFor documentation changes, also consider:\n\n```bash\ncargo doc --workspace --no-deps\n```\n\nIf a command cannot be run, say why and tell the user exactly what remains\nunverified.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nOperational instructions for AI coding agents working in Rig.\n\nFor contributor-facing policy, PR expectations, and accountability guidance, see\n`CONTRIBUTING.md`. This file is for repository-specific engineering rules that\nagents must follow while reading, editing, testing, and documenting code.\n\n## First Principles\n\n- Read the existing implementation before changing code.\n- Keep changes scoped to the user's request.\n- Prefer existing Rig traits, builders, modules, and error types over new abstractions.\n- Do not add TODOs, stubs, placeholder implementations, or speculative APIs.\n- Do not make commits, stage changes, push branches, or open PRs unless the user explicitly asks.\n- Do not discard user changes.\n\n## Repository Shape\n\n- Root facade crate: `rig`\n- Core crate: `crates/rig-core`\n- Companion provider and vector-store crates: `crates/rig-*`\n- Derive macros: `crates/rig-derive`\n- Workspace example packages: `examples/*`\n- Per-crate examples: `crates/<crate>/examples/`\n- Root integration test targets: `tests/*.rs`\n- Provider test modules: `tests/providers/<provider>/`\n- Provider cassette fixtures: `tests/cassettes/<provider>/`\n- External-service integration tests: `tests/integrations/`\n\nThe root `rig` crate re-exports `rig-core` and exposes companion crates behind\nfeature flags. Check `Cargo.toml` and `src/lib.rs` before documenting or changing\nexposed features, integrations, or module paths. If adding or exposing a\ncompanion provider/vector-store crate, update the root dependency, feature,\nfacade re-export, examples, README, and crate docs as applicable.\n\n## Core Architecture\n\nRig is built around provider-agnostic traits:\n\n- `CompletionModel` for text completion and chat models\n- `EmbeddingModel` for embedding generation\n- `VectorStoreIndex` for vector similarity search\n- `Tool` for callable tools\n\nUse these traits instead of creating parallel abstractions.\n\nConfigurable public types should follow Rig's builder style:\n\n```rust\nlet agent = client\n    .agent(openai::GPT_5_2)\n    .preamble(\"System prompt\")\n    .tool(my_tool)\n    .temperature(0.8)\n    .build();\n```\n\nProvider clients use the generic client architecture:\n\n```rust\npub struct Client<Ext = Nothing, H = reqwest::Client> {\n    // ...\n}\n```\n\nProviders declare capabilities explicitly with `Capable<T>` and `Nothing`.\n\n## WASM Compatibility\n\nRig supports WebAssembly targets.\n\nUse `WasmCompatSend` and `WasmCompatSync` in trait bounds instead of raw `Send`\nand `Sync`.\n\nUse `WasmBoxedFuture` for boxed futures.\n\nWhen an error type stores boxed errors, use platform-specific bounds:\n\n```rust\n#[cfg(not(target_family = \"wasm\"))]\nBox<dyn std::error::Error + Send + Sync + 'static>\n\n#[cfg(target_family = \"wasm\")]\nBox<dyn std::error::Error + 'static>\n```\n\n## Error Handling\n\n- Do not use `String` as an error type for new fallible APIs.\n- Use explicit error enums with `thiserror`.\n- Do not use `.unwrap()` or `.expect()` on fallible operations unless the condition is genuinely impossible and obvious from the code.\n- Prefer `?` and meaningful error conversions.\n\n## Documentation\n\n- Add `///` docs to new public items.\n- Add `//!` docs to new public modules.\n- Keep examples current with actual APIs, model constants, module paths, and feature flags.\n- Mark examples `no_run` when they require external credentials or services.\n- Do not document integrations, features, model constants, or crate paths without checking the code and manifests.\n- Keep root README, crate READMEs, and crate-level Rust docs consistent when changing public-facing behavior.\n\n## Provider Changes\n\nBefore implementing or modifying a provider, study the closest existing provider\nimplementation. For OpenAI-compatible chat APIs, start with:\n\n`crates/rig-core/src/providers/openai/`\n\nProvider implementations should include:\n\n- Provider extension and builder types\n- `Provider` implementation\n- `Capabilities` declaration\n- `ProviderBuilder` implementation\n- `ProviderClient::{from_env, from_val}`\n- public `Client` and `ClientBuilder` aliases; the `ClientBuilder` API-key generic must match `ProviderBuilder::ApiKey`\n- explicit API-key marker/auth types with redacted debug behavior for credential-bearing values\n- model constants where useful\n- request conversion from Rig request types\n- response conversion into Rig response types\n- streaming support when the provider supports streaming\n- provider-response error preservation through the relevant Rig error helpers\n- `ProviderResponseExt` and telemetry spans following existing GenAI conventions\n- tests or examples appropriate to the provider\n\nDo not add request or response fields that do not exist in the provider's real API.\n\nFor provider bug fixes or behavior changes, add or update regression coverage in\none of these places, preferring the smallest reliable scope:\n\n- unit tests near the implementation in `crates/rig-core/src/providers/...`;\n- cassette-backed provider tests in `tests/providers/<provider>/cassette/`;\n- ignored live tests only when cassette replay is unsuitable.\n\n## Vector Store Changes\n\nVector stores should live in companion crates unless there is a strong reason to\nplace them in `rig-core`.\n\nImplement both:\n\n- `top_n`\n- `top_n_ids`\n\nUse an appropriate backend-specific filter type.\n\nReturn `VectorStoreError` variants instead of ad hoc string errors.\n\nUse `WasmCompatSend` and `WasmCompatSync` bounds.\n\n## Agent Hook Changes\n\nAgent hooks are per-run lifecycle observers and steerers. `AgentHook` exposes\none method per lifecycle event, and every method receives the run-scoped\n`HookContext` (run id, turn, streaming flag, agent name, shared `Scratchpad`).\nEach method returns an event-specific action type, so unsupported combinations\nare rejected by the compiler.\n\nComposition through `HookStack` remains event-dependent:\n\n- **Completion calls accumulate and merge.** Every\n  `CompletionCallAction::Patch(RequestPatch)` is merged in registration order;\n  `Stop` short-circuits the stack.\n- **Tool calls and results chain.** `ToolCallAction::Rewrite` and\n  `ToolResultAction::Rewrite` are threaded into later hooks. A tool-call `Skip`\n  or either event's `Stop` is terminal.\n- **Invalid tool calls** return `InvalidToolCallAction` (`Fail`, `Retry`,\n  `Repair`, `Skip`, or `Stop`).\n- **Observe-only events** return `ObservationAction` (`Continue` or `Stop`).\n\nRegister observe-only hooks before steering hooks because stop actions\nshort-circuit. Nested `HookStack`s must preserve merge and chaining semantics.\n`RequestPatch` remains per-turn and non-sticky; its documented merge rules are\nappend `extra_context`, shallow-merge `additional_params`, intersect\n`active_tools`, and last-writer-wins scalars/history with a warning.\n\nEvery hook semantic must behave identically on streaming and non-streaming\nsurfaces (`AgentRunner::stream` and `AgentRunner::run` share `drive_agent`).\n\n## Style\n\n- Use full `where` clauses for complex trait bounds.\n- Comments should explain why, not restate what the code does.\n- Follow local naming, module layout, and test patterns.\n- Avoid unrelated refactors.\n\n## Cassette Regression Tests\n\nProvider regressions should usually include cassette-backed tests. Read\n`tests/README.md` before adding, updating, or running provider tests.\n\n- Test code lives under `tests/providers/<provider>/cassette/`.\n- Fixtures live under `tests/cassettes/<provider>/...`.\n- Replay cassettes by default; this should not require provider API keys.\n- Record mode requires the relevant provider API key and overwrites fixtures.\n- Keep record runs targeted to the provider and test being changed.\n\nReplay examples:\n\n```bash\ncargo test -p rig --all-features --test openai openai::cassette -- --nocapture --test-threads=1\ncargo test -p rig --all-features --test anthropic anthropic::cassette -- --nocapture --test-threads=1\ncargo test -p rig --all-features --test gemini gemini::cassette -- --nocapture --test-threads=1\n```\n\nRecord example:\n\n```bash\nRIG_PROVIDER_TEST_MODE=record \\\n  cargo test -p rig --all-features --test openai openai::cassette -- --nocapture --test-threads=1\n```\n\nReview cassette diffs carefully. They must not contain API keys, bearer tokens,\ncookies, provider account identifiers, or unrelated request/response churn. The\nrepo includes cassette scrub/safety checks in `tests/common/cassette_safety.rs`,\nbut agents are still responsible for inspecting generated fixtures before\npresenting changes.\n\n## Verification\n\nRun the smallest useful checks first, then broaden as needed. For tests, prefer\nthe targeted commands in `tests/README.md` before running broad workspace checks.\n\nBefore considering code complete, run when feasible:\n\n```bash\ncargo fmt\ncargo clippy --all-targets --all-features\ncargo test\n```\n\nFor documentation changes, also consider:\n\n```bash\ncargo doc --workspace --no-deps\n```\n\nIf a command cannot be run, say why and tell the user exactly what remains\nunverified.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\nOperational instructions for AI coding agents working in Rig.\n\nFor contributor-facing policy, PR expectations, and accountability guidance, see\n`CONTRIBUTING.md`. This file is for repository-specific engineering rules that\nagents must follow while reading, editing, testing, and documenting code.\n\n## First Principles\n\n- Read the existing implementation before changing code.\n- Keep changes scoped to the user's request.\n- Prefer existing Rig traits, builders, modules, and error types over new abstractions.\n- Do not add TODOs, stubs, placeholder implementations, or speculative APIs.\n- Do not make commits, stage changes, push branches, or open PRs unless the user explicitly asks.\n- Do not discard user changes.\n\n## Repository Shape\n\n- Root facade crate: `rig`\n- Core crate: `crates/rig-core`\n- Companion provider and vector-store crates: `crates/rig-*`\n- Derive macros: `crates/rig-derive`\n- Workspace example packages: `examples/*`\n- Per-crate examples: `crates/<crate>/examples/`\n- Root integration test targets: `tests/*.rs`\n- Provider test modules: `tests/providers/<provider>/`\n- Provider cassette fixtures: `tests/cassettes/<provider>/`\n- External-service integration tests: `tests/integrations/`\n\nThe root `rig` crate re-exports `rig-core` and exposes companion crates behind\nfeature flags. Check `Cargo.toml` and `src/lib.rs` before documenting or changing\nexposed features, integrations, or module paths. If adding or exposing a\ncompanion provider/vector-store crate, update the root dependency, feature,\nfacade re-export, examples, README, and crate docs as applicable.\n\n## Core Architecture\n\nRig is built around provider-agnostic traits:\n\n- `CompletionModel` for text completion and chat models\n- `EmbeddingModel` for embedding generation\n- `VectorStoreIndex` for vector similarity search\n- `Tool` for callable tools\n\nUse these traits instead of creating parallel abstractions.\n\nConfigurable public types should follow Rig's builder style:\n\n```rust\nlet agent = client\n    .agent(openai::GPT_5_2)\n    .preamble(\"System prompt\")\n    .tool(my_tool)\n    .temperature(0.8)\n    .build();\n```\n\nProvider clients use the generic client architecture:\n\n```rust\npub struct Client<Ext = Nothing, H = reqwest::Client> {\n    // ...\n}\n```\n\nProviders declare capabilities explicitly with `Capable<T>` and `Nothing`.\n\n## WASM Compatibility\n\nRig supports WebAssembly targets.\n\nUse `WasmCompatSend` and `WasmCompatSync` in trait bounds instead of raw `Send`\nand `Sync`.\n\nUse `WasmBoxedFuture` for boxed futures.\n\nWhen an error type stores boxed errors, use platform-specific bounds:\n\n```rust\n#[cfg(not(target_family = \"wasm\"))]\nBox<dyn std::error::Error + Send + Sync + 'static>\n\n#[cfg(target_family = \"wasm\")]\nBox<dyn std::error::Error + 'static>\n```\n\n## Error Handling\n\n- Do not use `String` as an error type for new fallible APIs.\n- Use explicit error enums with `thiserror`.\n- Do not use `.unwrap()` or `.expect()` on fallible operations unless the condition is genuinely impossible and obvious from the code.\n- Prefer `?` and meaningful error conversions.\n\n## Documentation\n\n- Add `///` docs to new public items.\n- Add `//!` docs to new public modules.\n- Keep examples current with actual APIs, model constants, module paths, and feature flags.\n- Mark examples `no_run` when they require external credentials or services.\n- Do not document integrations, features, model constants, or crate paths without checking the code and manifests.\n- Keep root README, crate READMEs, and crate-level Rust docs consistent when changing public-facing behavior.\n\n## Provider Changes\n\nBefore implementing or modifying a provider, study the closest existing provider\nimplementation. For OpenAI-compatible chat APIs, start with:\n\n`crates/rig-core/src/providers/openai/`\n\nProvider implementations should include:\n\n- Provider extension and builder types\n- `Provider` implementation\n- `Capabilities` declaration\n- `ProviderBuilder` implementation\n- `ProviderClient::{from_env, from_val}`\n- public `Client` and `ClientBuilder` aliases; the `ClientBuilder` API-key generic must match `ProviderBuilder::ApiKey`\n- explicit API-key marker/auth types with redacted debug behavior for credential-bearing values\n- model constants where useful\n- request conversion from Rig request types\n- response conversion into Rig response types\n- streaming support when the provider supports streaming\n- provider-response error preservation through the relevant Rig error helpers\n- `ProviderResponseExt` and telemetry spans following existing GenAI conventions\n- tests or examples appropriate to the provider\n\nDo not add request or response fields that do not exist in the provider's real API.\n\nFor provider bug fixes or behavior changes, add or update regression coverage in\none of these places, preferring the smallest reliable scope:\n\n- unit tests near the implementation in `crates/rig-core/src/providers/...`;\n- cassette-backed provider tests in `tests/providers/<provider>/cassette/`;\n- ignored live tests only when cassette replay is unsuitable.\n\n## Vector Store Changes\n\nVector stores should live in companion crates unless there is a strong reason to\nplace them in `rig-core`.\n\nImplement both:\n\n- `top_n`\n- `top_n_ids`\n\nUse an appropriate backend-specific filter type.\n\nReturn `VectorStoreError` variants instead of ad hoc string errors.\n\nUse `WasmCompatSend` and `WasmCompatSync` bounds.\n\n## Agent Hook Changes\n\nAgent hooks are per-run lifecycle observers and steerers. `AgentHook` exposes\none method per lifecycle event, and every method receives the run-scoped\n`HookContext` (run id, turn, streaming flag, agent name, shared `Scratchpad`).\nEach method returns an event-specific action type, so unsupported combinations\nare rejected by the compiler.\n\nComposition through `HookStack` remains event-dependent:\n\n- **Completion calls accumulate and merge.** Every\n  `CompletionCallAction::Patch(RequestPatch)` is merged in registration order;\n  `Stop` short-circuits the stack.\n- **Tool calls and results chain.** `ToolCallAction::Rewrite` and\n  `ToolResultAction::Rewrite` are threaded into later hooks. A tool-call `Skip`\n  or either event's `Stop` is terminal.\n- **Invalid tool calls** return `InvalidToolCallAction` (`Fail`, `Retry`,\n  `Repair`, `Skip`, or `Stop`).\n- **Observe-only events** return `ObservationAction` (`Continue` or `Stop`).\n\nRegister observe-only hooks before steering hooks because stop actions\nshort-circuit. Nested `HookStack`s must preserve merge and chaining semantics.\n`RequestPatch` remains per-turn and non-sticky; its documented merge rules are\nappend `extra_context`, shallow-merge `additional_params`, intersect\n`active_tools`, and last-writer-wins scalars/history with a warning.\n\nEvery hook semantic must behave identically on streaming and non-streaming\nsurfaces (`AgentRunner::stream` and `AgentRunner::run` share `drive_agent`).\n\n## Style\n\n- Use full `where` clauses for complex trait bounds.\n- Comments should explain why, not restate what the code does.\n- Follow local naming, module layout, and test patterns.\n- Avoid unrelated refactors.\n\n## Cassette Regression Tests\n\nProvider regressions should usually include cassette-backed tests. Read\n`tests/README.md` before adding, updating, or running provider tests.\n\n- Test code lives under `tests/providers/<provider>/cassette/`.\n- Fixtures live under `tests/cassettes/<provider>/...`.\n- Replay cassettes by default; this should not require provider API keys.\n- Record mode requires the relevant provider API key and overwrites fixtures.\n- Keep record runs targeted to the provider and test being changed.\n\nReplay examples:\n\n```bash\ncargo test -p rig --all-features --test openai openai::cassette -- --nocapture --test-threads=1\ncargo test -p rig --all-features --test anthropic anthropic::cassette -- --nocapture --test-threads=1\ncargo test -p rig --all-features --test gemini gemini::cassette -- --nocapture --test-threads=1\n```\n\nRecord example:\n\n```bash\nRIG_PROVIDER_TEST_MODE=record \\\n  cargo test -p rig --all-features --test openai openai::cassette -- --nocapture --test-threads=1\n```\n\nReview cassette diffs carefully. They must not contain API keys, bearer tokens,\ncookies, provider account identifiers, or unrelated request/response churn. The\nrepo includes cassette scrub/safety checks in `tests/common/cassette_safety.rs`,\nbut agents are still responsible for inspecting generated fixtures before\npresenting changes.\n\n## Verification\n\nRun the smallest useful checks first, then broaden as needed. For tests, prefer\nthe targeted commands in `tests/README.md` before running broad workspace checks.\n\nBefore considering code complete, run when feasible:\n\n```bash\ncargo fmt\ncargo clippy --all-targets --all-features\ncargo test\n```\n\nFor documentation changes, also consider:\n\n```bash\ncargo doc --workspace --no-deps\n```\n\nIf a command cannot be run, say why and tell the user exactly what remains\nunverified.\n","category":"root","tokens":2221}]}