用途：这是一份针对 ty 类型检查器的使用策略，用于约束在项目中如何运行 ty、如何处理类型错误与规则冲突，以及如何解决未解析导入问题。它假定读者已了解 ty 的通用用法，CLI 参数、配置 schema 等以官方文档为准。
主要能力与规则：禁止添加 # ty: ignore 或 # type: ignore，包括被要求时；应修复类型错误，或带具体阻塞点上报。放宽 ty 规则只能通过 pyproject.toml 中的 [[tool.ty.overrides]]，不得内联，且仅限真实规则冲突、测试规则本身的代码、故意写坏的负例或 fixture、不修改的外部托管 vendored 代码、语法或类型上限更低的运行时（如旧版固定 CPython、MicroPython/CircuitPython），或修复成本高于合规收益的情况；覆盖旁需注释说明属于哪一类及具体原因。ty 是唯一允许的类型检查器，不得同时添加、安装、配置或运行 mypy、pyright、basedpyright。调用方式固定为 uv run ty，不用裸 ty 或 uvx ty，以免解析到与 lockfile 不同的版本。
未解析导入：把缺失目录加入 pyproject.toml 的 [tool.ty.environment] extra-paths，再用 uv run ty check <path> 验证；根目录 ty.toml 优先于 pyproject.toml，需先确认 ty 实际读取哪个文件。PEP 723 独立脚本（带 # /// script 头并导入同级模块）不适用项目 pyproject.toml，应设置 root 而非 extra-paths，且 root 会完全替换默认根自动检测，必须包含 "."。语言服务器中脚本自身内联依赖的未解析导入，需通过 TY_UV=scripts 或 experimental.useUv 设为 "scripts" 启用同步（要求 uv >= 0.12.3）；"scripts" 是唯一可接受值，拼错会被静默忽略，且 uv 元数据调用失败时 ty 会跳过该文件而非报错，因此应通过实际运行 uv run ty check <script>.py 观察诊断来确认行为。
适用场景与限制：适用于采用 ty 并希望统一类型检查策略的 Python 项目，尤其是使用 uv 管理依赖、包含 PEP 723 脚本或 vendored 代码的仓库。资料未提供 ty 的安装步骤、版本号、收费信息及完整配置示例，这些需参考官方文档。