{"owner":"lance-format","repo":"lance","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nLance is a modern columnar data format optimized for ML workflows and datasets, providing high-performance random access, vector search, zero-copy automatic versioning, and ecosystem integrations. The vision is to become the de facto standard columnar data format for machine learning and large language models.\n\nAlso see directory-specific guidelines: [rust/](rust/AGENTS.md) | [python/](python/AGENTS.md) | [java/](java/AGENTS.md) | [protos/](protos/AGENTS.md) | [docs/src/format/](docs/src/format/AGENTS.md)\n\n## File Format Stability and Compatibility\n\n- Treat every file format marked stable as a durable compatibility contract. All changes to a stable format must preserve both backward and forward compatibility.\n- Treat every file format marked unstable as disposable. It may change freely; do not add compatibility code, migrations, fallbacks, or tests for files written by earlier unstable revisions.\n- Evaluate compatibility against the latest released stable version while continuing to honor all stable format contracts. Changes that exist only on the current branch or `main` are not compatibility constraints; do not compromise a cleaner or more complete design to preserve those intermediate states.\n\n### Legacy Compatibility Boundaries\n\n- Treat formats and code paths that current writers no longer emit as frozen compatibility surfaces. Preserve their existing read behavior, but exclude them from new feature design unless legacy support is explicitly required.\n- Implement new features in the current format and write paths. Do not extend legacy writers, retrofit new capabilities into legacy readers, or reuse legacy implementations as the foundation for new code.\n- Avoid refactoring or otherwise modifying legacy code during feature work. If a shared boundary makes a legacy change unavoidable, isolate the change, preserve existing behavior, and add targeted regression coverage using released historical fixtures.\n\n## Development Commands\n\n### Rust\n\n* Check: `cargo check --workspace --tests --benches`\n* Test: `cargo test --workspace` or `cargo test -p <package> <test_name>`\n* Lint: `cargo clippy --all --tests --benches -- -D warnings`\n* Format: `cargo fmt --all`\n* Coverage: `cargo +nightly llvm-cov -q -p <crate> --branch`\n* Coverage HTML: `cargo +nightly llvm-cov -q -p <crate> --branch --html`\n* Coverage for file: `python ci/coverage.py -p <crate> -f <file_path>`\n* Use repository-defined Cargo profiles instead of ad hoc LTO overrides.\n* Use `release-with-debug` for benchmarks and profiling so optimized builds keep debug symbols without a rebuild.\n* Use `release-no-lto` only for local debugging, IO-bound benchmarks, or compile-time-sensitive performance investigation where LTO would not affect the measured bottleneck.\n\n## Language-Specific Environment Contract\n\n- For language-specific tasks, always follow the environment and command rules in the corresponding subdirectory guide before running build, test, lint, format, or tooling commands.\n- Do not substitute a different environment manager or toolchain just because a command appears missing, unavailable, or slow.\n- If a language-specific command fails outside the documented workflow, treat that as an environment usage mistake first. Fix the environment usage, rerun with the prescribed commands, and only then conclude that a dependency or tool is unavailable.\n\n## Coding Standards\n\n### General\n\n- Always use English in code, examples, and comments.\n- Code is for readability, not just execution. Only add meaningful comments and tests.\n- Comments should explain non-obvious \"why\" reasoning, not restate what the code does.\n- Remove debug prints (`println!`, `dbg!`, `print()`) before merging — use `tracing` or logging frameworks.\n- Think carefully before adding a helper: only introduce one when it materially reduces cognitive load or eliminates substantial duplication, and do not add thin wrappers that only rename or forward existing calls.\n- Keep PRs focused — no drive-by refactors, reformatting, or cosmetic changes.\n- Be mindful of memory use: avoid collecting streams of `RecordBatch` into memory; use `RoaringBitmap` instead of `HashSet<u32>`.\n\n### Cross-Language Bindings\n\n- Keep Python and Java bindings as thin wrappers — centralize validation and logic in the Rust core.\n- Keep parameter names consistent across all bindings (Rust, Python, Java) — rename everywhere or nowhere.\n- Never break public API signatures — deprecate with `#[deprecated]`/`@deprecated` and add a new method.\n- Replace mutually exclusive boolean flags with a single enum/mode parameter.\n\n### Naming\n\n- Name variables after what the value *is* (e.g., `partition_id` not `mask`) — precise names act as inline docs.\n- Drop redundant prefixes when the struct/module already implies the domain.\n- Use `indices` (not `indexes`) consistently in all APIs and docs.\n- Use storage-agnostic terms in API names (e.g., `base` not `bucket`).\n- When renaming a type/struct/enum, update all references (methods, fields, variables, test names).\n\n### Error Handling\n\n- Validate inputs and reject invalid values with descriptive errors at API boundaries — never silently clamp or adjust.\n- Validate mutually exclusive options in builders/configs — throw a clear error if both are set.\n- Include full context in error messages: variable names, values, sizes, types.\n\n### Dependencies\n\n- Prefer implementing functionality with the standard library or existing workspace dependencies before adding new external crates.\n- Keep `Cargo.lock` changes intentional; revert unrelated dependency bumps. Pin broken deps with a comment linking the upstream issue.\n- The repo has three lockfiles: the root `Cargo.lock`, `python/Cargo.lock`, and `java/lance-jni/Cargo.lock` (the latter two are excluded from the workspace). A `workspace.dependencies` change must be reflected in all three — refresh the excluded ones with `cargo check --manifest-path python/Cargo.toml` and `cargo check --manifest-path java/lance-jni/Cargo.toml`, then commit the updated lockfiles. The `cargo-lock-sync` pre-commit hook catches a miss offline.\n- Gate optional/domain-specific deps behind Cargo feature flags. Prefer separate crates for domain functionality (geo, NLP).\n\n## Testing Standards\n\n- **All bugfixes and features must have corresponding tests. We do not merge code without tests.**\n- Use `rstest` (Rust) or `@pytest.mark.parametrize` (Python) for tests that differ only in inputs. Use `#[case::{name}(...)]` for readable case names.\n- Replace `print()` in tests with `assert` — prints don't catch regressions.\n- Extend existing tests instead of adding overlapping new ones. Add to existing test files.\n- Link a GitHub issue when skipping a test — never bare `@pytest.mark.skip` or `@Ignore` without a tracking URL.\n- Include multi-fragment scenarios for dataset operations (reads, indexes, scans).\n- Cover NULL edge cases in index tests: null items, all-null collections, empty collections, null columns.\n- Vector index tests must assert recall metrics (>=0.5 threshold), not just verify creation succeeds.\n- For backwards compatibility, use the `test_data` directory with checked-in datasets from older versions. Include a `datagen.py` that asserts the Lance version used. Use `copy_test_data_to_tmp` to read this data.\n- Avoid `ignore` in doctests — write Rust doctests that compile a function instead:\n  ```\n  /// ```\n  /// # use lance::{Dataset, Result};\n  /// # async fn test(dataset: &Dataset) -> Result<()> {\n  /// dataset.delete(\"id = 25\").await?;\n  /// # Ok(())\n  /// # }\n  /// ```\n  ```\n- Skip coverage for test utilities using `#[cfg_attr(coverage, coverage(off))]`.\n\n## Documentation Standards\n\n- All public APIs must have documentation with examples. Link to relevant structs and methods.\n- Use ASCII tree diagrams for hierarchical structures (encoding layers, file formats, storage layouts).\n- Keep doc examples in sync with actual API signatures — update when refactoring.\n- Indent content under MkDocs admonition directives (`!!! note`, etc.) with 4 spaces.\n- Proofread comments and docs for typos before committing.\n\n## Filing Issues\n\n- When opening an issue with `gh issue create` or the API, classify it and pass the matching label: `--label bug`, `--label feature`, or `--label performance`. These paths bypass the `.github/ISSUE_TEMPLATE` forms, so the label is not applied automatically.\n- Prefix the title to match, e.g. `bug: ...`, `feature: ...`, or `perf: ...`. A content-based labeler (`.github/workflows/issue-labeler.yml`) uses this as a fallback signal, but an explicit `--label` is the reliable path.\n\n## Pull Requests\n\n- Before creating a PR, search for similar PRs and inspect any PRs linked to the issue being addressed. If a matching PR exists, verify its current status and scope before proceeding to avoid creating duplicate work.\n- PR titles must follow the Conventional Commits specification because `.github/workflows/pr-title.yml` validates the PR title and body with commitlint. Use prefixes like `feat:`, `fix:`, `docs:`, `perf:`, `ci:`, `test:`, `build:`, `style:`, or `chore:`; add a scope when useful.\n- Before creating or updating a PR, run the lint checks for every touched language surface, even when they are expensive. For Rust changes, run `cargo fmt --all` and `cargo clippy --all --tests --benches -- -D warnings`. For Python changes, follow the environment workflow in `python/AGENTS.md` and run `uv run make lint` from `python/`. If a required lint check cannot be run, state the blocker explicitly in the PR summary.\n\n## Review Guidelines\n\nContributor and maintainer attention is the most valuable resource. Less is more.\n\n- Be concise and clear. Focus on P0/P1 issues: severe bugs, performance degradation, security concerns.\n- Do not reiterate detailed changes or repeat what's already well done.\n- Check naming consistency, error handling patterns, and test coverage.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nLance is a modern columnar data format optimized for ML workflows and datasets, providing high-performance random access, vector search, zero-copy automatic versioning, and ecosystem integrations. The vision is to become the de facto standard columnar data format for machine learning and large language models.\n\nAlso see directory-specific guidelines: [rust/](rust/AGENTS.md) | [python/](python/AGENTS.md) | [java/](java/AGENTS.md) | [protos/](protos/AGENTS.md) | [docs/src/format/](docs/src/format/AGENTS.md)\n\n## File Format Stability and Compatibility\n\n- Treat every file format marked stable as a durable compatibility contract. All changes to a stable format must preserve both backward and forward compatibility.\n- Treat every file format marked unstable as disposable. It may change freely; do not add compatibility code, migrations, fallbacks, or tests for files written by earlier unstable revisions.\n- Evaluate compatibility against the latest released stable version while continuing to honor all stable format contracts. Changes that exist only on the current branch or `main` are not compatibility constraints; do not compromise a cleaner or more complete design to preserve those intermediate states.\n\n### Legacy Compatibility Boundaries\n\n- Treat formats and code paths that current writers no longer emit as frozen compatibility surfaces. Preserve their existing read behavior, but exclude them from new feature design unless legacy support is explicitly required.\n- Implement new features in the current format and write paths. Do not extend legacy writers, retrofit new capabilities into legacy readers, or reuse legacy implementations as the foundation for new code.\n- Avoid refactoring or otherwise modifying legacy code during feature work. If a shared boundary makes a legacy change unavoidable, isolate the change, preserve existing behavior, and add targeted regression coverage using released historical fixtures.\n\n## Development Commands\n\n### Rust\n\n* Check: `cargo check --workspace --tests --benches`\n* Test: `cargo test --workspace` or `cargo test -p <package> <test_name>`\n* Lint: `cargo clippy --all --tests --benches -- -D warnings`\n* Format: `cargo fmt --all`\n* Coverage: `cargo +nightly llvm-cov -q -p <crate> --branch`\n* Coverage HTML: `cargo +nightly llvm-cov -q -p <crate> --branch --html`\n* Coverage for file: `python ci/coverage.py -p <crate> -f <file_path>`\n* Use repository-defined Cargo profiles instead of ad hoc LTO overrides.\n* Use `release-with-debug` for benchmarks and profiling so optimized builds keep debug symbols without a rebuild.\n* Use `release-no-lto` only for local debugging, IO-bound benchmarks, or compile-time-sensitive performance investigation where LTO would not affect the measured bottleneck.\n\n## Language-Specific Environment Contract\n\n- For language-specific tasks, always follow the environment and command rules in the corresponding subdirectory guide before running build, test, lint, format, or tooling commands.\n- Do not substitute a different environment manager or toolchain just because a command appears missing, unavailable, or slow.\n- If a language-specific command fails outside the documented workflow, treat that as an environment usage mistake first. Fix the environment usage, rerun with the prescribed commands, and only then conclude that a dependency or tool is unavailable.\n\n## Coding Standards\n\n### General\n\n- Always use English in code, examples, and comments.\n- Code is for readability, not just execution. Only add meaningful comments and tests.\n- Comments should explain non-obvious \"why\" reasoning, not restate what the code does.\n- Remove debug prints (`println!`, `dbg!`, `print()`) before merging — use `tracing` or logging frameworks.\n- Think carefully before adding a helper: only introduce one when it materially reduces cognitive load or eliminates substantial duplication, and do not add thin wrappers that only rename or forward existing calls.\n- Keep PRs focused — no drive-by refactors, reformatting, or cosmetic changes.\n- Be mindful of memory use: avoid collecting streams of `RecordBatch` into memory; use `RoaringBitmap` instead of `HashSet<u32>`.\n\n### Cross-Language Bindings\n\n- Keep Python and Java bindings as thin wrappers — centralize validation and logic in the Rust core.\n- Keep parameter names consistent across all bindings (Rust, Python, Java) — rename everywhere or nowhere.\n- Never break public API signatures — deprecate with `#[deprecated]`/`@deprecated` and add a new method.\n- Replace mutually exclusive boolean flags with a single enum/mode parameter.\n\n### Naming\n\n- Name variables after what the value *is* (e.g., `partition_id` not `mask`) — precise names act as inline docs.\n- Drop redundant prefixes when the struct/module already implies the domain.\n- Use `indices` (not `indexes`) consistently in all APIs and docs.\n- Use storage-agnostic terms in API names (e.g., `base` not `bucket`).\n- When renaming a type/struct/enum, update all references (methods, fields, variables, test names).\n\n### Error Handling\n\n- Validate inputs and reject invalid values with descriptive errors at API boundaries — never silently clamp or adjust.\n- Validate mutually exclusive options in builders/configs — throw a clear error if both are set.\n- Include full context in error messages: variable names, values, sizes, types.\n\n### Dependencies\n\n- Prefer implementing functionality with the standard library or existing workspace dependencies before adding new external crates.\n- Keep `Cargo.lock` changes intentional; revert unrelated dependency bumps. Pin broken deps with a comment linking the upstream issue.\n- The repo has three lockfiles: the root `Cargo.lock`, `python/Cargo.lock`, and `java/lance-jni/Cargo.lock` (the latter two are excluded from the workspace). A `workspace.dependencies` change must be reflected in all three — refresh the excluded ones with `cargo check --manifest-path python/Cargo.toml` and `cargo check --manifest-path java/lance-jni/Cargo.toml`, then commit the updated lockfiles. The `cargo-lock-sync` pre-commit hook catches a miss offline.\n- Gate optional/domain-specific deps behind Cargo feature flags. Prefer separate crates for domain functionality (geo, NLP).\n\n## Testing Standards\n\n- **All bugfixes and features must have corresponding tests. We do not merge code without tests.**\n- Use `rstest` (Rust) or `@pytest.mark.parametrize` (Python) for tests that differ only in inputs. Use `#[case::{name}(...)]` for readable case names.\n- Replace `print()` in tests with `assert` — prints don't catch regressions.\n- Extend existing tests instead of adding overlapping new ones. Add to existing test files.\n- Link a GitHub issue when skipping a test — never bare `@pytest.mark.skip` or `@Ignore` without a tracking URL.\n- Include multi-fragment scenarios for dataset operations (reads, indexes, scans).\n- Cover NULL edge cases in index tests: null items, all-null collections, empty collections, null columns.\n- Vector index tests must assert recall metrics (>=0.5 threshold), not just verify creation succeeds.\n- For backwards compatibility, use the `test_data` directory with checked-in datasets from older versions. Include a `datagen.py` that asserts the Lance version used. Use `copy_test_data_to_tmp` to read this data.\n- Avoid `ignore` in doctests — write Rust doctests that compile a function instead:\n  ```\n  /// ```\n  /// # use lance::{Dataset, Result};\n  /// # async fn test(dataset: &Dataset) -> Result<()> {\n  /// dataset.delete(\"id = 25\").await?;\n  /// # Ok(())\n  /// # }\n  /// ```\n  ```\n- Skip coverage for test utilities using `#[cfg_attr(coverage, coverage(off))]`.\n\n## Documentation Standards\n\n- All public APIs must have documentation with examples. Link to relevant structs and methods.\n- Use ASCII tree diagrams for hierarchical structures (encoding layers, file formats, storage layouts).\n- Keep doc examples in sync with actual API signatures — update when refactoring.\n- Indent content under MkDocs admonition directives (`!!! note`, etc.) with 4 spaces.\n- Proofread comments and docs for typos before committing.\n\n## Filing Issues\n\n- When opening an issue with `gh issue create` or the API, classify it and pass the matching label: `--label bug`, `--label feature`, or `--label performance`. These paths bypass the `.github/ISSUE_TEMPLATE` forms, so the label is not applied automatically.\n- Prefix the title to match, e.g. `bug: ...`, `feature: ...`, or `perf: ...`. A content-based labeler (`.github/workflows/issue-labeler.yml`) uses this as a fallback signal, but an explicit `--label` is the reliable path.\n\n## Pull Requests\n\n- Before creating a PR, search for similar PRs and inspect any PRs linked to the issue being addressed. If a matching PR exists, verify its current status and scope before proceeding to avoid creating duplicate work.\n- PR titles must follow the Conventional Commits specification because `.github/workflows/pr-title.yml` validates the PR title and body with commitlint. Use prefixes like `feat:`, `fix:`, `docs:`, `perf:`, `ci:`, `test:`, `build:`, `style:`, or `chore:`; add a scope when useful.\n- Before creating or updating a PR, run the lint checks for every touched language surface, even when they are expensive. For Rust changes, run `cargo fmt --all` and `cargo clippy --all --tests --benches -- -D warnings`. For Python changes, follow the environment workflow in `python/AGENTS.md` and run `uv run make lint` from `python/`. If a required lint check cannot be run, state the blocker explicitly in the PR summary.\n\n## Review Guidelines\n\nContributor and maintainer attention is the most valuable resource. Less is more.\n\n- Be concise and clear. Focus on P0/P1 issues: severe bugs, performance degradation, security concerns.\n- Do not reiterate detailed changes or repeat what's already well done.\n- Check naming consistency, error handling patterns, and test coverage.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\nLance is a modern columnar data format optimized for ML workflows and datasets, providing high-performance random access, vector search, zero-copy automatic versioning, and ecosystem integrations. The vision is to become the de facto standard columnar data format for machine learning and large language models.\n\nAlso see directory-specific guidelines: [rust/](rust/AGENTS.md) | [python/](python/AGENTS.md) | [java/](java/AGENTS.md) | [protos/](protos/AGENTS.md) | [docs/src/format/](docs/src/format/AGENTS.md)\n\n## File Format Stability and Compatibility\n\n- Treat every file format marked stable as a durable compatibility contract. All changes to a stable format must preserve both backward and forward compatibility.\n- Treat every file format marked unstable as disposable. It may change freely; do not add compatibility code, migrations, fallbacks, or tests for files written by earlier unstable revisions.\n- Evaluate compatibility against the latest released stable version while continuing to honor all stable format contracts. Changes that exist only on the current branch or `main` are not compatibility constraints; do not compromise a cleaner or more complete design to preserve those intermediate states.\n\n### Legacy Compatibility Boundaries\n\n- Treat formats and code paths that current writers no longer emit as frozen compatibility surfaces. Preserve their existing read behavior, but exclude them from new feature design unless legacy support is explicitly required.\n- Implement new features in the current format and write paths. Do not extend legacy writers, retrofit new capabilities into legacy readers, or reuse legacy implementations as the foundation for new code.\n- Avoid refactoring or otherwise modifying legacy code during feature work. If a shared boundary makes a legacy change unavoidable, isolate the change, preserve existing behavior, and add targeted regression coverage using released historical fixtures.\n\n## Development Commands\n\n### Rust\n\n* Check: `cargo check --workspace --tests --benches`\n* Test: `cargo test --workspace` or `cargo test -p <package> <test_name>`\n* Lint: `cargo clippy --all --tests --benches -- -D warnings`\n* Format: `cargo fmt --all`\n* Coverage: `cargo +nightly llvm-cov -q -p <crate> --branch`\n* Coverage HTML: `cargo +nightly llvm-cov -q -p <crate> --branch --html`\n* Coverage for file: `python ci/coverage.py -p <crate> -f <file_path>`\n* Use repository-defined Cargo profiles instead of ad hoc LTO overrides.\n* Use `release-with-debug` for benchmarks and profiling so optimized builds keep debug symbols without a rebuild.\n* Use `release-no-lto` only for local debugging, IO-bound benchmarks, or compile-time-sensitive performance investigation where LTO would not affect the measured bottleneck.\n\n## Language-Specific Environment Contract\n\n- For language-specific tasks, always follow the environment and command rules in the corresponding subdirectory guide before running build, test, lint, format, or tooling commands.\n- Do not substitute a different environment manager or toolchain just because a command appears missing, unavailable, or slow.\n- If a language-specific command fails outside the documented workflow, treat that as an environment usage mistake first. Fix the environment usage, rerun with the prescribed commands, and only then conclude that a dependency or tool is unavailable.\n\n## Coding Standards\n\n### General\n\n- Always use English in code, examples, and comments.\n- Code is for readability, not just execution. Only add meaningful comments and tests.\n- Comments should explain non-obvious \"why\" reasoning, not restate what the code does.\n- Remove debug prints (`println!`, `dbg!`, `print()`) before merging — use `tracing` or logging frameworks.\n- Think carefully before adding a helper: only introduce one when it materially reduces cognitive load or eliminates substantial duplication, and do not add thin wrappers that only rename or forward existing calls.\n- Keep PRs focused — no drive-by refactors, reformatting, or cosmetic changes.\n- Be mindful of memory use: avoid collecting streams of `RecordBatch` into memory; use `RoaringBitmap` instead of `HashSet<u32>`.\n\n### Cross-Language Bindings\n\n- Keep Python and Java bindings as thin wrappers — centralize validation and logic in the Rust core.\n- Keep parameter names consistent across all bindings (Rust, Python, Java) — rename everywhere or nowhere.\n- Never break public API signatures — deprecate with `#[deprecated]`/`@deprecated` and add a new method.\n- Replace mutually exclusive boolean flags with a single enum/mode parameter.\n\n### Naming\n\n- Name variables after what the value *is* (e.g., `partition_id` not `mask`) — precise names act as inline docs.\n- Drop redundant prefixes when the struct/module already implies the domain.\n- Use `indices` (not `indexes`) consistently in all APIs and docs.\n- Use storage-agnostic terms in API names (e.g., `base` not `bucket`).\n- When renaming a type/struct/enum, update all references (methods, fields, variables, test names).\n\n### Error Handling\n\n- Validate inputs and reject invalid values with descriptive errors at API boundaries — never silently clamp or adjust.\n- Validate mutually exclusive options in builders/configs — throw a clear error if both are set.\n- Include full context in error messages: variable names, values, sizes, types.\n\n### Dependencies\n\n- Prefer implementing functionality with the standard library or existing workspace dependencies before adding new external crates.\n- Keep `Cargo.lock` changes intentional; revert unrelated dependency bumps. Pin broken deps with a comment linking the upstream issue.\n- The repo has three lockfiles: the root `Cargo.lock`, `python/Cargo.lock`, and `java/lance-jni/Cargo.lock` (the latter two are excluded from the workspace). A `workspace.dependencies` change must be reflected in all three — refresh the excluded ones with `cargo check --manifest-path python/Cargo.toml` and `cargo check --manifest-path java/lance-jni/Cargo.toml`, then commit the updated lockfiles. The `cargo-lock-sync` pre-commit hook catches a miss offline.\n- Gate optional/domain-specific deps behind Cargo feature flags. Prefer separate crates for domain functionality (geo, NLP).\n\n## Testing Standards\n\n- **All bugfixes and features must have corresponding tests. We do not merge code without tests.**\n- Use `rstest` (Rust) or `@pytest.mark.parametrize` (Python) for tests that differ only in inputs. Use `#[case::{name}(...)]` for readable case names.\n- Replace `print()` in tests with `assert` — prints don't catch regressions.\n- Extend existing tests instead of adding overlapping new ones. Add to existing test files.\n- Link a GitHub issue when skipping a test — never bare `@pytest.mark.skip` or `@Ignore` without a tracking URL.\n- Include multi-fragment scenarios for dataset operations (reads, indexes, scans).\n- Cover NULL edge cases in index tests: null items, all-null collections, empty collections, null columns.\n- Vector index tests must assert recall metrics (>=0.5 threshold), not just verify creation succeeds.\n- For backwards compatibility, use the `test_data` directory with checked-in datasets from older versions. Include a `datagen.py` that asserts the Lance version used. Use `copy_test_data_to_tmp` to read this data.\n- Avoid `ignore` in doctests — write Rust doctests that compile a function instead:\n  ```\n  /// ```\n  /// # use lance::{Dataset, Result};\n  /// # async fn test(dataset: &Dataset) -> Result<()> {\n  /// dataset.delete(\"id = 25\").await?;\n  /// # Ok(())\n  /// # }\n  /// ```\n  ```\n- Skip coverage for test utilities using `#[cfg_attr(coverage, coverage(off))]`.\n\n## Documentation Standards\n\n- All public APIs must have documentation with examples. Link to relevant structs and methods.\n- Use ASCII tree diagrams for hierarchical structures (encoding layers, file formats, storage layouts).\n- Keep doc examples in sync with actual API signatures — update when refactoring.\n- Indent content under MkDocs admonition directives (`!!! note`, etc.) with 4 spaces.\n- Proofread comments and docs for typos before committing.\n\n## Filing Issues\n\n- When opening an issue with `gh issue create` or the API, classify it and pass the matching label: `--label bug`, `--label feature`, or `--label performance`. These paths bypass the `.github/ISSUE_TEMPLATE` forms, so the label is not applied automatically.\n- Prefix the title to match, e.g. `bug: ...`, `feature: ...`, or `perf: ...`. A content-based labeler (`.github/workflows/issue-labeler.yml`) uses this as a fallback signal, but an explicit `--label` is the reliable path.\n\n## Pull Requests\n\n- Before creating a PR, search for similar PRs and inspect any PRs linked to the issue being addressed. If a matching PR exists, verify its current status and scope before proceeding to avoid creating duplicate work.\n- PR titles must follow the Conventional Commits specification because `.github/workflows/pr-title.yml` validates the PR title and body with commitlint. Use prefixes like `feat:`, `fix:`, `docs:`, `perf:`, `ci:`, `test:`, `build:`, `style:`, or `chore:`; add a scope when useful.\n- Before creating or updating a PR, run the lint checks for every touched language surface, even when they are expensive. For Rust changes, run `cargo fmt --all` and `cargo clippy --all --tests --benches -- -D warnings`. For Python changes, follow the environment workflow in `python/AGENTS.md` and run `uv run make lint` from `python/`. If a required lint check cannot be run, state the blocker explicitly in the PR summary.\n\n## Review Guidelines\n\nContributor and maintainer attention is the most valuable resource. Less is more.\n\n- Be concise and clear. Focus on P0/P1 issues: severe bugs, performance degradation, security concerns.\n- Do not reiterate detailed changes or repeat what's already well done.\n- Check naming consistency, error handling patterns, and test coverage.\n","category":"root","tokens":2473}]}