ty.schema.json

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Options",
  "type": "object",
  "properties": {
    "analysis": {
      "anyOf": [
        {
          "$ref": "#/definitions/AnalysisOptions"
        },
        {
          "type": "null"
        }
      ]
    },
    "editor": {
      "description": "Configures the parts of the editor experience that type checking does not decide.",
      "anyOf": [
        {
          "$ref": "#/definitions/EditorOptions"
        },
        {
          "type": "null"
        }
      ]
    },
    "environment": {
      "description": "Configures the type checking environment.",
      "anyOf": [
        {
          "$ref": "#/definitions/EnvironmentOptions"
        },
        {
          "type": "null"
        }
      ]
    },
    "overrides": {
      "description": "Override configurations for specific file patterns.\n\nEach override specifies include/exclude patterns and rule configurations\nthat apply to matching files. Multiple overrides can match the same file,\nwith later overrides taking precedence.",
      "anyOf": [
        {
          "$ref": "#/definitions/OverridesOptions"
        },
        {
          "type": "null"
        }
      ]
    },
    "rules": {
      "description": "Configures the enabled rules and their severity.\n\nThe keys are either rule names or `all` to set a default severity for all rules.\nSee [the rules documentation](https://ty.dev/rules) for a list of all available rules.\n\nValid severities are:\n\n* `ignore`: Disable the rule.\n* `warn`: Enable the rule and create a warning diagnostic.\n* `error`: Enable the rule and create an error diagnostic.\n\nBy default, ty exits with code 1 if it emits any warning or error diagnostics.\nSet `terminal.error-on-warning` to `false` to exit with code 0 if all diagnostics have `warning` severity.",
      "anyOf": [
        {
          "$ref": "#/definitions/Rules"
        },
        {
          "type": "null"
        }
      ]
    },
    "run": {
      "description": "Configures how `by run` executes the project.",
      "anyOf": [
        {
          "$ref": "#/definitions/RunOptions"
        },
        {
          "type": "null"
        }
      ]
    },
    "src": {
      "anyOf": [
        {
          "$ref": "#/definitions/SrcOptions"
        },
        {
          "type": "null"
        }
      ]
    },
    "terminal": {
      "anyOf": [
        {
          "$ref": "#/definitions/TerminalOptions"
        },
        {
          "type": "null"
        }
      ]
    }
  },
  "additionalProperties": false,
  "definitions": {
    "AnalysisOptions": {
      "type": "object",
      "properties": {
        "allowed-unresolved-imports": {
          "description": "A list of module glob patterns for which `unresolved-import` diagnostics should be suppressed.\n\nDetails on supported glob patterns:\n- `*` matches zero or more characters except `.`. For example, `foo.*` matches `foo.bar` but\n  not `foo.bar.baz`; `foo*` matches `foo` and `foobar` but not `foo.bar` or `barfoo`; and `*foo`\n  matches `foo` and `barfoo` but not `foo.bar` or `foobar`.\n- `**` matches any number of module components (e.g., `foo.**` matches `foo`, `foo.bar`, etc.)\n- Prefix a pattern with `!` to exclude matching modules\n\nWhen multiple patterns match, later entries take precedence.\n\nGlob patterns can be used in combinations with each other. For example, to suppress errors for\nany module where the first component contains the substring `test`, use `*test*.**`.",
          "type": [
            "array",
            "null"
          ],
          "items": {
            "$ref": "#/definitions/string"
          }
        },
        "bivariant-private-attributes": {
          "description": "Whether a private attribute leaves an inferred type parameter bivariant. This is a\nbasedpython feature.\n\nA private (single-underscore or name-mangled) member is invisible to external observers, so\nit cannot be used to distinguish two specializations of its class, and therefore cannot\nconstrain the class's variance:\n\n```python\nclass A[T]:\n    _t: T\n```\n\nWith this option enabled, `T` is inferred bivariant: nothing on `A`'s public surface\nmentions `T`, so `A[int]` and `A[object]` are mutually assignable. As soon as a public\nmember mentions `T`, that member drives the inference as usual.\n\nWhen set to `false`, a private attribute is instead treated as immutable-but-readable,\nwhich constrains the type parameter to covariance.\n\nDefaults to `true`.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "dependency-groups": {
          "description": "The requirement groups the matching files may import from.\n\n`project` names `[project].dependencies`, an extra or a PEP 735 dependency group\nis named by its own name, and `*` names every group.\n\nWhen this is unset, a file may import from every group unless it is part of what\nthe project ships — the modules named by `shipped-modules` — in which case it may\nimport only `project` and the extras. Nothing the project ships can import a\ndependency group, because nothing installs one alongside the project.",
          "type": [
            "array",
            "null"
          ],
          "items": {
            "$ref": "#/definitions/string"
          }
        },
        "disable-fluid-specializations": {
          "description": "Whether to disable \"fluid specializations\", a basedpython feature that widens the\ninferred generic specialization of an unannotated binding flow-sensitively based on\nits later uses in the same scope.\n\nWhen set to `true`, each unannotated binding keeps the specialization it was inferred\nwith at its creation site; later uses no longer widen or lock it.\n\nDefaults to `false`.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "exported-dependencies": {
          "description": "The dependencies this project hands to its own users.\n\nA library whose interface is partly made of another distribution's types — one that\nreturns numpy arrays, or takes a pydantic model — can say so, and then a project\nthat depends on this one may import those distributions without declaring them\nitself.\n\nOnly what the project already depends on can be exported, and the claim only\ntravels one link: exporting a distribution does not export whatever *it* depends\non, unless that distribution exports it in turn.\n\nThis is written into the `by.typed` marker when the project is built, because that\nis what its users have — a `pyproject.toml` is not installed with the package.",
          "type": [
            "array",
            "null"
          ],
          "items": {
            "$ref": "#/definitions/string"
          }
        },
        "implicit-object-repr-exempt-types": {
          "description": "A list of classes never reported as an\n[`implicit-object-repr`](rules.md#implicit-object-repr).\n\nA class deriving from one of these is exempt too, so listing a base opts out a whole\nhierarchy.\n\nEntries are qualified class names (`decimal.Decimal`). A class in `builtins` may also be\nspelled bare (`int`).",
          "type": [
            "array",
            "null"
          ],
          "items": {
            "$ref": "#/definitions/string"
          }
        },
        "implicit-object-repr-report-types": {
          "description": "A list of classes whose stub is taken at its word when looking for an\n[`implicit-object-repr`](rules.md#implicit-object-repr).\n\nA stub normally settles nothing, because it omits `__str__` and `__repr__` whether or not\nthe runtime class has them — `int` declares neither and still prints as a number. For a\nclass listed here the omission counts as real, the same way it would for a class written\nin source, so a value of that class is reported unless the stub does declare one.\n\nDefaults to the two whose bare repr is seen most often: `types.FunctionType`, which prints\n`<function f at 0x...>`, and `builtins.type`, which prints `<class 'C'>`.\n\nEntries are qualified class names (`decimal.Decimal`). A class in `builtins` may also be\nspelled bare (`int`).",
          "type": [
            "array",
            "null"
          ],
          "items": {
            "$ref": "#/definitions/string"
          }
        },
        "infer-unannotated-signatures": {
          "description": "Whether a function with no annotations is given the signature its body determines. This is\na basedpython feature.\n\nPython's gradual guarantee makes an unannotated `def` say nothing: its parameters accept\nanything and it returns `Unknown`. That is the largest remaining source of `Unknown` in an\notherwise typed project, and it silently swallows real mistakes. With this enabled, the\nmissing half of the signature is recovered from what the function itself already determines:\n\n- **Each unannotated parameter** opens an anonymous type parameter named after it — the same\n  hole `some` spells by hand — bounded by everything the function requires of it: the\n  promoted type of its default, the members its body reads and calls, the parameters it is\n  forwarded into, and any `assert` at the top of the body. Naming the hole is what keeps\n  what a call passes in connected to what it gets back, so `def ident(x): return x` is\n  inferred as the identity function.\n- **A missing return type** is the union of what the body returns, plus `None` when control\n  can also fall off the end. An empty body returns `None`, a body that always raises returns\n  `Never`, and a generator returns a generator.\n\nNothing is invented from a use this analysis cannot read, so such a parameter stays gradual\nand its body keeps type-checking exactly as it did. An explicit annotation always wins, and\nso does anything an overload group or an overridden base method already supplies.\n\nDefaults to `true`.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "overlapping-condition-assume-truthy-instances": {
          "description": "Whether an instance with no `__bool__` and no `__len__` counts as always truthy when\nlooking for an [`overlapping-condition`](rules.md#overlapping-condition).\n\nSuch an instance is only *ambiguously* truthy — a subclass may define `__bool__` — so by\ndefault it is a falsy member of `if not x` just as `None` is. Enabling this assumes the\nclass means what it looks like it means, which drops the reports for the very common\n`if not x` over an optional instance.\n\nDefaults to `false`.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "overlapping-condition-exempt-types": {
          "description": "A list of classes whose values do not count as a distinct member of an\n[`overlapping-condition`](rules.md#overlapping-condition).\n\n`if not x` over an `int | None` selects both a falsy `int` and `None`, and is reported\nbecause the branch cannot tell them apart. Listing `int` here says that conflating a falsy\n`int` with anything else is fine, so only `None` is left and the condition is accepted.\n\nEntries are qualified class names (`decimal.Decimal`). A class in `builtins` may also be\nspelled bare (`int`), and `None` stands for the type of `None`.",
          "type": [
            "array",
            "null"
          ],
          "items": {
            "$ref": "#/definitions/string"
          }
        },
        "precise-unsolved-typevars": {
          "description": "Whether a type variable that a call leaves unsolved is solved to `Never`. This is a\nbasedpython feature.\n\nA call can leave a type variable entirely unsolved, because no argument mentions it:\n\n```python\ndef f[T]() -> T: ...\n\na = f()\n```\n\n`Never` is the precise answer here: no value ever reaches that position, so nothing the\ncall returns can be observed at type `T`. When set to `false`, the type variable falls back\nto the gradual `Unknown` instead, which silences any error that would follow from the call\nsite.\n\nThis applies where the type variable is an output. Where it is instead written through or\npassed back in — the element of an invariant `list[T]`, the parameter of a returned\n`Callable[[T], R]` — `Never` would say that nothing can ever be put there, so an invariant\nor contravariant occurrence keeps the gradual `Unknown`.\n\nA PEP 696 default (`def f[T = str]()`) always takes priority, and a `ParamSpec`,\n`TypeVarTuple` or keyword-variadic pack is unaffected because `Never` is not a valid\nsolution for one.\n\nDefaults to `true`.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "replace-imports-with-any": {
          "description": "A list of module glob patterns whose imports should be replaced with `typing.Any`.\n\nUnlike `allowed-unresolved-imports`, this setting replaces the module's type information\nwith `typing.Any` even if the module can be resolved. Import diagnostics are\nunconditionally suppressed for matching modules.\n\n- Prefix a pattern with `!` to exclude matching modules\n\nWhen multiple patterns match, later entries take precedence.\n\nGlob patterns can be used in combinations with each other. For example, to suppress errors for\nany module where the first component contains the substring `test`, use `*test*.**`.\n\nWhen multiple patterns match, later entries take precedence.",
          "type": [
            "array",
            "null"
          ],
          "items": {
            "$ref": "#/definitions/string"
          }
        },
        "respect-type-ignore-comments": {
          "description": "Whether ty should respect `type: ignore` comments.\n\nWhen set to `false`, `type: ignore` comments are treated like any other normal\ncomment and can't be used to suppress ty errors (you have to use `ty: ignore` instead).\n\nSetting this option can be useful when using ty alongside other type checkers or when\nyou prefer using `ty: ignore` over `type: ignore`.\n\nDefaults to `true`.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "shipped-modules": {
          "description": "The top-level modules the project ships.\n\nDefaults to the module named after `[project].name`: a project named `my-lib`\nships `my_lib`. Only a project that ships several unrelated modules, or one whose\nmodule is not named after it, needs to say.",
          "type": [
            "array",
            "null"
          ],
          "items": {
            "$ref": "#/definitions/string"
          }
        },
        "sound-types": {
          "description": "Whether to infer sound (non-gradual) types wherever a precise type is available. This is a\nbasedpython feature.\n\nPython's gradual guarantee requires a type checker to fall back to a gradual type whenever\nan annotation is missing, even when a precise type could be inferred. In a fully typed\nproject that is pure boilerplate: it forces an annotation to be written for something the\nchecker already knows. When set to `true`, this option deliberately breaks the gradual\nguarantee and uses the precise type instead. It affects:\n\n- **Unannotated parameters**: each one opens an anonymous type parameter named after it,\n  bounded by everything the function requires of it — the promoted type of its default, the\n  members its body reads and calls, the parameters it is forwarded into, and any `assert` at\n  the top of the body. So `def f(a=1)` rejects a `str` at a call site, and\n  `def ident(x): return x` is inferred as the identity function. A lambda parameter with a\n  default takes that default's promoted type directly.\n- **Unannotated return types**: the union of what the body returns, plus `None` when control\n  can fall off the end. An empty body returns `None` and a body that always raises returns\n  `Never`; a generator returns a generator.\n- **Unannotated methods that override a base method**: the parameter and return types are\n  inherited from the overridden method, including from `Protocol` members and\n  `abstractmethod` declarations.\n- **Bare `ClassVar` annotations**: `x: ClassVar = 1` declares `int` rather than the union of\n  `Unknown` and the inferred type.\n- **Empty collection literals**: `[]` has element type `Never`, so passing one to a generic\n  call solves from it precisely instead of leaking `Unknown`.\n\nAn explicit annotation always takes priority over any of the above.\n\nDefaults to `false`.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "strict-equality-semantics": {
          "description": "Configure ty's behavior regarding type inference and narrowing of equality\nchecks. Defaults to `false`.\n\nBy default, ty makes various assumptions about equality checks that match the\nintuitions of most Python programmers, but may not be fully sound in all situations.\nEnabling this option makes ty more conservative about these assumptions, making it\nless likely to infer `Literal[True]` or `Literal[False]` as the result of an\nequality check. This has various effects on type checking, including fewer type\nnarrowing opportunities and more conservative assumptions regarding control flow.\n\nOne way in which ty will by default make unsound assumptions is by narrowing an\nobject `x` of type `str` to `Literal[\"a\"]` after an `if x == \"a\"` check. This is\nunsound because a subclass of `str` with value `\"a\"` will (by default) compare equal\nto `\"a\"`, but will not be of type `Literal[\"a\"]`:\n\n```pycon\n>>> # `Literal[\"a\"]` can only be inhabited by instances of exactly `str`, not\n>>> # subclasses, but str subclasses compare equal by default:\n>>> class StringSubclass(str): ...\n...\n>>> StringSubclass(\"a\") == \"a\"\nTrue\n>>>\n>>> # This also applies to `StrEnum`s:\n>>> from enum import StrEnum\n>>> class MyEnum(StrEnum):\n...     A = \"a\"\n...\n>>> MyEnum.A == \"a\"\nTrue\n```\n\nEnabling this option prevents the unsound narrowing of `x` to `Literal[\"a\"]`,\nand instead keeps it as `str`:\n\n```python\nfrom typing import Literal\n\ndef parse(value: str) -> Literal[\"a\"] | None:\n    # with `strict-equality-semantics = true`, no narrowing will occur here,\n    # and an error will be emitted on the `return` statement.\n    if value == \"a\":\n        return value\n    return None\n```\n\nAnother assumption ty makes by default is that subclasses will never override `__eq__` or\n`__ne__`. This allows ty to narrow the following union based on an equality check, despite\nthe fact that an instance of a subclass of `Foo` could compare equal to `None`, and it's\nperfectly valid to pass an instance of a subclass into the `x` parameter of this function:\n\n```python\ndef narrow(x: Foo | None, other: Foo) -> None:\n    if x == other:\n        # with this option enabled, `x` will still have type `Foo | None` here,\n        # since it is legal to subclass `Foo` and override its `__eq__` method.\n        reveal_type(x)\n```\n\nMany operations in Python implicitly call `__eq__` under the hood; enabling this option\nwill also impact those operations. For example, this option will also impact narrowing from\n`in` checks, and narrowing in `match` statements that use value patterns:\n\n```python\ndef narrow_in(x: Foo | None, other: list[Foo]) -> None:\n    if x in other:\n        # with this option enabled, `x` will still have type `Foo | None` here,\n        # since the `in` operator implicitly calls `__eq__` on each element of `other`.\n        reveal_type(x)\n\n\ndef narrow_match(x: str) -> None:\n    match x:\n        case \"a\":\n            # with this option enabled, `x` will still have type `str` here,\n            # since this `case` branch will be taken by any object that compares\n            # equal to `\"a\"`, including subclasses of `str`.\n            reveal_type(x)\n```",
          "type": [
            "boolean",
            "null"
          ]
        },
        "strict-float": {
          "description": "Whether `float` and `complex` annotations mean *only* themselves. This is a\nbasedpython feature.\n\nThe typing spec's special case says an `int` is acceptable wherever a `float` is\nasked for, so `x: float` really declares `int | float`. A `.by` file opts out of\nthat already; this makes the same model available to a `.py` one, per module.\n\nIt is not only a checking question. The wider annotation is why a `.py`\n`list[float]` cannot be laid out as an unboxed buffer and a `.py` class cannot\nhave `double` fields, so `by compile` reads this to choose a representation.\n\nDefaults to `false`.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "strict-generic-narrowing": {
          "description": "Whether ty should use strict narrowing for unspecialized generic classes in\n`isinstance()` and `issubclass()` checks, as well as `match` class patterns.\n\nWhen enabled, ty narrows to the top materialization of the class. For example,\n`isinstance(value, list)` narrows a value of type `object` to `Top[list[Unknown]]`,\nrepresenting the (infinite) union of all possible `list` specializations. Iterating\nover the list would yield values of type `object`.\n\nWhen disabled, ty uses gradual generic narrowing, preserving compatible type\narguments from the original type where possible. For example,\n`isinstance(value, list)` narrows a value of type `Sequence[int]` to `list[int]`.\nIf no specialization is available, the same check narrows a value of type `object`\nto `list[Unknown]`; items of any type can then be appended to the list. Class\npatterns such as `case list():` follow the same behavior.\n\nDefaults to `false`.",
          "type": [
            "boolean",
            "null"
          ]
        }
      },
      "additionalProperties": false
    },
    "Array_of_string": {
      "type": "array",
      "items": {
        "$ref": "#/definitions/string"
      }
    },
    "CommonAliases": {
      "type": "object",
      "additionalProperties": {
        "type": "string"
      }
    },
    "EditorOptions": {
      "type": "object",
      "properties": {
        "common-aliases": {
          "description": "The modules a name is a common alias of, keyed by the alias.\n\nA file that writes `np.` before importing anything almost always means numpy, because `np`\nis what numpy is conventionally imported as. The editor completes such a name as the module\nit names, and accepting one of those completions writes the `import numpy as np` that makes\nthe name real.\n\nThis adds aliases of your own to the ones ty already knows; an entry whose alias ty knows\nreplaces it. An alias for a module the project does not have is never offered, so an entry\nfor a module nobody installed costs nothing.\n\nDefaults to `{}`, which leaves ty's own aliases as they are.",
          "anyOf": [
            {
              "$ref": "#/definitions/CommonAliases"
            },
            {
              "type": "null"
            }
          ]
        }
      },
      "additionalProperties": false
    },
    "EnvironmentOptions": {
      "type": "object",
      "properties": {
        "extra-paths": {
          "description": "User-provided paths that should take first priority in module resolution.\n\nThis is an advanced option that should usually only be used for first-party or third-party\nmodules that are not installed into your Python environment in a conventional way.\nUse the `python` option to specify the location of your Python environment.\n\nThis option is similar to mypy's `MYPYPATH` environment variable and pyright's `stubPath`\nconfiguration setting.",
          "type": [
            "array",
            "null"
          ],
          "items": {
            "$ref": "#/definitions/RelativePathBuf"
          }
        },
        "python": {
          "description": "Path to your project's Python environment or interpreter.\n\nty uses the `site-packages` directory of your project's Python environment\nto resolve third-party (and, in some cases, first-party) imports in your code.\n\nThis can be a path to:\n\n- A Python interpreter, e.g. `.venv/bin/python3`\n- A virtual environment directory, e.g. `.venv`\n- A system Python [`sys.prefix`] directory, e.g. `/usr`\n\nIf you're using a project management tool such as uv, you should not generally need to\nspecify this option, as commands such as `uv run` will set the `VIRTUAL_ENV` environment\nvariable to point to your project's virtual environment. ty can also infer the location of\nyour environment from an activated Conda environment, and will look for a `.venv` directory\nin the project root if none of the above apply. Failing that, ty will look for a `python3`\nor `python` binary available in `PATH`.\n\n[`sys.prefix`]: https://docs.python.org/3/library/sys.html#sys.prefix",
          "anyOf": [
            {
              "$ref": "#/definitions/RelativePathBuf"
            },
            {
              "type": "null"
            }
          ]
        },
        "python-platform": {
          "description": "Specifies the target platform that will be used to analyze the source code.\nIf specified, ty will understand conditions based on comparisons with `sys.platform`, such\nas are commonly found in typeshed to reflect the differing contents of the standard library across platforms.\nIf `all` is specified, ty will assume that the source code can run on any platform.\n\nIf no platform is specified, ty will use the current platform:\n- `win32` for Windows\n- `darwin` for macOS\n- `android` for Android\n- `ios` for iOS\n- `linux` for everything else",
          "anyOf": [
            {
              "$ref": "#/definitions/PythonPlatform"
            },
            {
              "type": "null"
            }
          ]
        },
        "python-version": {
          "description": "Specifies the version of Python that will be used to analyze the source code.\nThe version should be specified as a string in the format `M.m` where `M` is the major version\nand `m` is the minor (e.g. `\"3.7\"` or `\"3.12\"`).\nIf a version is provided, ty will generate errors if the source code makes use of language features\nthat are not supported in that version.\n\nty officially supports type checking code that targets Python 3.10 and later. Python 3.7\nthrough 3.9 can still be selected, but ty may produce false positives or false negatives for\nstandard-library APIs because its bundled stubs do not fully describe those versions.\n\nIf a version is not specified, ty will try the following techniques in order of preference\nto determine a value:\n1. Check for the `project.requires-python` setting in a `pyproject.toml` file\n   and use the minimum version from the specified range\n2. Check for an activated or configured Python environment\n   and attempt to infer the Python version of that environment\n3. Fall back to the default value (see below)\n\nFor some language features, ty can also understand conditionals based on comparisons\nwith `sys.version_info`. These are commonly found in typeshed, for example,\nto reflect the differing contents of the standard library across Python versions.",
          "anyOf": [
            {
              "$ref": "#/definitions/SupportedPythonVersion"
            },
            {
              "type": "null"
            }
          ]
        },
        "root": {
          "description": "The root paths of the project, used for finding first-party modules.\n\nAccepts a list of directory paths searched in priority order (first has highest priority).\n\nIf left unspecified, ty will try to detect common project layouts and initialize `root` accordingly.\nThe project root (`.`) is always included. Additionally, the following directories are included\nif they exist and are not packages (i.e. they do not contain `__init__.py` or `__init__.pyi` files):\n\n* `./src`\n* `./<project-name>` (if a `./<project-name>/<project-name>` directory exists)\n* `./python`",
          "type": [
            "array",
            "null"
          ],
          "items": {
            "$ref": "#/definitions/RelativePathBuf"
          }
        },
        "typeshed": {
          "description": "Optional path to a \"typeshed\" directory on disk for us to use for standard-library types.\nIf this is not provided, we will fallback to our vendored typeshed stubs for the stdlib,\nbundled as a zip file in the binary",
          "anyOf": [
            {
              "$ref": "#/definitions/RelativePathBuf"
            },
            {
              "type": "null"
            }
          ]
        }
      },
      "additionalProperties": false
    },
    "Level": {
      "oneOf": [
        {
          "title": "Ignore",
          "description": "The lint is disabled and should not run.",
          "type": "string",
          "const": "ignore"
        },
        {
          "title": "Warn",
          "description": "The lint is enabled and diagnostic should have a warning severity.",
          "type": "string",
          "const": "warn"
        },
        {
          "title": "Error",
          "description": "The lint is enabled and diagnostics have an error severity.",
          "type": "string",
          "const": "error"
        }
      ]
    },
    "OutputFormat": {
      "description": "The diagnostic output format.",
      "oneOf": [
        {
          "description": "The default full mode will print \"pretty\" diagnostics.\n\nThat is, color will be used when printing to a `tty`.\nMoreover, diagnostic messages may include additional\ncontext and annotations on the input to help understand\nthe message.",
          "type": "string",
          "const": "full"
        },
        {
          "description": "Print diagnostics in a concise mode.\n\nThis will guarantee that each diagnostic is printed on\na single line. Only the most important or primary aspects\nof the diagnostic are included. Contextual information is\ndropped.\n\nThis may use color when printing to a `tty`.",
          "type": "string",
          "const": "concise"
        },
        {
          "description": "Print diagnostics in the JSON format expected by GitLab [Code Quality] reports.\n\n[Code Quality]: https://docs.gitlab.com/ci/testing/code_quality/#code-quality-report-format",
          "type": "string",
          "const": "gitlab"
        },
        {
          "description": "Print diagnostics in the format used by [GitHub Actions] workflow error annotations.\n\n[GitHub Actions]: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-commands#setting-an-error-message",
          "type": "string",
          "const": "github"
        },
        {
          "description": "Print diagnostics as a JUnit-style XML report.",
          "type": "string",
          "const": "junit"
        }
      ]
    },
    "OverrideOptions": {
      "type": "object",
      "properties": {
        "analysis": {
          "anyOf": [
            {
              "$ref": "#/definitions/AnalysisOptions"
            },
            {
              "type": "null"
            }
          ]
        },
        "exclude": {
          "description": "A list of file and directory patterns to exclude from this override.\n\nPatterns follow a syntax similar to `.gitignore`.\nExclude patterns take precedence over include patterns within the same override.\n\nIf not specified, defaults to `[]` (excludes no files).",
          "anyOf": [
            {
              "$ref": "#/definitions/Array_of_string"
            },
            {
              "type": "null"
            }
          ]
        },
        "include": {
          "description": "A list of file and directory patterns to include for this override.\n\nThe `include` option follows a similar syntax to `.gitignore` but reversed:\nIncluding a file or directory will make it so that it (and its contents)\nare affected by this override.\n\nIf not specified, defaults to `[\"**\"]` (matches all files).",
          "anyOf": [
            {
              "$ref": "#/definitions/Array_of_string"
            },
            {
              "type": "null"
            }
          ]
        },
        "rules": {
          "description": "Rule overrides for files matching the include/exclude patterns.\n\nThese rules will be merged with the global rules, with override rules\ntaking precedence for matching files. You can set rules to different\nseverity levels or disable them entirely.",
          "anyOf": [
            {
              "$ref": "#/definitions/Rules"
            },
            {
              "type": "null"
            }
          ]
        }
      },
      "additionalProperties": false
    },
    "OverridesOptions": {
      "description": "Configuration override that applies to specific files based on glob patterns.\n\nAn override allows you to apply different rule configurations to specific\nfiles or directories. Multiple overrides can match the same file, with\nlater overrides take precedence. Override rules take precedence over global\nrules for matching files.\n\nFor example, to relax enforcement of rules in test files:\n\n```toml\n[[tool.ty.overrides]]\ninclude = [\"tests/**\", \"**/test_*.py\"]\n\n[tool.ty.overrides.rules]\npossibly-unresolved-reference = \"warn\"\n```\n\nOr, to ignore a rule in generated files but retain enforcement in an important file:\n\n```toml\n[[tool.ty.overrides]]\ninclude = [\"generated/**\"]\nexclude = [\"generated/important.py\"]\n\n[tool.ty.overrides.rules]\npossibly-unresolved-reference = \"ignore\"\n```",
      "type": "array",
      "items": {
        "$ref": "#/definitions/OverrideOptions"
      }
    },
    "PythonPlatform": {
      "description": "The target platform to assume when resolving types.\n",
      "anyOf": [
        {
          "type": "string"
        },
        {
          "description": "Do not make any assumptions about the target platform.",
          "const": "all"
        },
        {
          "description": "Darwin",
          "const": "darwin"
        },
        {
          "description": "Linux",
          "const": "linux"
        },
        {
          "description": "Windows",
          "const": "win32"
        }
      ]
    },
    "RelativePathBuf": {
      "description": "A possibly relative path in a configuration file.\n\nRelative paths in configuration files or from CLI options\nrequire different anchoring:\n\n* CLI: The path is relative to the current working directory\n* Configuration file: The path is relative to the project's root.",
      "allOf": [
        {
          "$ref": "#/definitions/SystemPathBuf"
        }
      ]
    },
    "Rules": {
      "type": "object",
      "properties": {
        "abstract-and-final-method": {
          "title": "detects methods that are both abstract and final",
          "description": "## What it does\n\nChecks for methods decorated with both `@abstractmethod` and `@final`.\n\n## Why is this bad?\n\nAn abstract method must be overridden for a subclass to become concrete, but a final\nmethod cannot be overridden. Combining the decorators therefore makes it impossible\nfor a subclass to provide a concrete implementation.\n\n## Example\n\n```python\nfrom abc import ABC, abstractmethod\nfrom typing import final\n\n\nclass Base(ABC):\n    @final\n    @abstractmethod\n    def method(self) -> None: ...  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "abstract-method-in-final-class": {
          "title": "detects `@final` classes with unimplemented abstract methods",
          "description": "## What it does\n\nChecks for `@final` classes that have unimplemented abstract methods.\n\n## Why is this bad?\n\nA class decorated with `@final` cannot be subclassed. If such a class has abstract\nmethods that are not implemented, the class can never be properly instantiated, as\nthe abstract methods can never be implemented (since subclassing is prohibited).\n\nAt runtime, instantiation of classes with unimplemented abstract methods is only\nprevented for classes that have `ABCMeta` (or a subclass of it) as their metaclass.\nHowever, type checkers also enforce this for classes that do not use `ABCMeta`, since\nthe intent for the class to be abstract is clear from the use of `@abstractmethod`.\n\n## Example\n\n```python\nfrom abc import ABC, abstractmethod\nfrom typing import final\n\n\nclass Base(ABC):\n    @abstractmethod\n    def method(self) -> int: ...\n\n\n@final\n# `Derived` does not implement `method`\nclass Derived(Base):  # error\n    pass\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "all": {
          "title": "set the default severity level for all rules",
          "description": "Configure a default severity level for all rules. Individual rule settings override this default.",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "ambiguous-context-argument": {
          "title": "detects calls whose `context` parameter matches several context values",
          "description": "## What it does\nChecks for calls where several `context` declarations in the same scope\ncould fill one `context` parameter.\n\n## Why is this bad?\nThe implicit argument is chosen by assignability, not by name. When two\ndeclarations in the winning scope both match, either choice would be\narbitrary — the call must pass the argument explicitly (or the extra\ndeclaration must move to another scope).\n\n## Examples\n```python\ndef f(a: int, context b: str): ...\n\ncontext s1 = \"hello\"\ncontext s2 = \"world\"\nf(1)          # error: `s1` and `s2` both match\nf(1, b=s1)    # ok — explicit\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "ambiguous-conversion": {
          "title": "detects conversion sites served by more than one conversion",
          "description": "## What it does\nChecks for conversion sites where more than one conversion applies — two\ndunders, a dunder and an in-scope conformance, or two applicable\n`implementation`s of the same interface and type.\n\n## Why is this bad?\n`__from__` and `__into__` are hand-written bodies that can disagree, so\nwhich one runs must not depend on arbitrary ordering. Remove one of them,\nor write the conversion you want explicitly.\n\n## Example\n\n```by\nclass Celsius:\n    def __into__(self) -> Fahrenheit: ...\n\nclass Fahrenheit:\n    @classmethod\n    def __from__(cls, value: Celsius) -> Self: ...\n\nreport(Celsius())  # error: two conversions apply\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "ambiguous-extension-member": {
          "title": "detects attribute accesses supplied by more than one extension",
          "description": "## What it does\nChecks for attribute accesses that resolve to a member supplied by more\nthan one applicable basedpython extension.\n\n## Why is this bad?\nWhen two extensions in scope both add the same member to the receiver's\ntype, the access is ambiguous — which implementation runs would depend\non arbitrary ordering. Constrain one of the extensions (or drop the\nimport that brings the second into scope) so exactly one applies.\n\n## Example\n\n```by\nextension list:\n    def second(self) -> Element: ...\n\nextension list:\n    def second(self) -> Element: ...\n\n[1, 2].second()  # error: ambiguous extension member\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "ambiguous-protocol-member": {
          "title": "detects protocol classes with ambiguous interfaces",
          "description": "## What it does\n\nChecks for protocol classes with members that will lead to ambiguous interfaces.\n\n## Why is this bad?\n\nAssigning to an undeclared variable in a protocol class, or to an undeclared attribute\nthrough a protocol method's `self` or `cls` receiver, leads to an ambiguous interface\nwhich may lead to the type checker inferring unexpected things. It's recommended to\nensure that all members of a protocol class are explicitly declared.\n\n## Examples\n\n```py\nfrom typing import ClassVar, Protocol\n\n\nclass BaseProto(Protocol):\n    a: int  # fine (explicitly declared as `int`)\n    instance_member: str\n    class_member: ClassVar[str]\n\n    # fine: a method definition using `def` is considered a declaration\n    def method_member(self) -> int: ...\n\n    def method(self) -> None:\n        self.instance_member = \"value\"  # fine (declared in the class body)\n        self.implicit = \"value\"  # error: [ambiguous-protocol-member]\n\n    @classmethod\n    def class_method(cls) -> None:\n        cls.class_member = \"value\"  # fine (declared in the class body)\n        cls.implicit_class = \"value\"  # error: [ambiguous-protocol-member]\n\n    # no explicit declaration, leading to ambiguity\n    c = \"some variable\"  # error\n    # no explicit declaration, leading to ambiguity\n    b = method_member  # error\n\n    # This creates implicit assignments of `d` and `e` in the protocol class body.\n    # Were they really meant to be considered protocol members?\n    # error: \"`d` is not declared as a protocol member\"\n    # error: \"`e` is not declared as a protocol member\"\n    for d, e in enumerate(range(42)):\n        pass\n\n\nclass SubProto(BaseProto, Protocol):\n    a = 42  # fine (declared in superclass)\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "assert-type-unspellable-subtype": {
          "title": "detects failed type assertions",
          "description": "## What it does\n\nChecks for `assert_type()` calls where the actual type\nis an unspellable subtype of the asserted type.\n\n## Why is this bad?\n\n`assert_type()` is intended to ensure that the inferred type of a value\nis exactly the same as the asserted type. But in some situations, ty\nhas nonstandard extensions to the type system that allow it to infer\nmore precise types than can be expressed in user annotations. ty emits a\ndifferent error code to `type-assertion-failure` in these situations so\nthat users can easily differentiate between the two cases.\n\n## Example\n\n```toml\n[environment]\npython-version = \"3.11\"\n```\n\n```python\nfrom typing import assert_type\n\n\ndef _(x: int):\n    assert_type(x, int)  # fine\n    if x:\n        # the actual type is `int & ~AlwaysFalsy`,\n        # which excludes types like `Literal[0]`\n        # error: [assert-type-unspellable-subtype]\n        assert_type(x, int)\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "blanket-ignore-comment": {
          "title": "detects blanket `ty: ignore` comments",
          "description": "## What it does\n\nChecks for `ty: ignore` comments that don't specify which rules to ignore.\n\n## Why is this bad?\n\nA blanket `ty: ignore` comment suppresses every type-checking diagnostic on the\napplicable line or file. Specifying rule codes documents which diagnostics are\nexpected and prevents the comment from silencing unrelated errors.\n\n## Examples\n\n```py\n# error\nvalue = unknown  # ty: ignore\n```\n\nUse instead:\n\n```py\nvalue = unknown  # ty: ignore[unresolved-reference]\n```",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "bool-as-int": {
          "title": "detects a `bool` implicitly used as an `int`",
          "description": "## What it does\nChecks for a `bool` value in a position that expects a number, where it is\nadmitted only because `bool` is a subclass of `int`.\n\n## Why is this bad?\nNothing is converted here — `bool` really is a subclass of `int`, and `True`\nand `False` really are `1` and `0`. That is the problem: the value satisfies\nan `int` (or `float`, or `complex`) annotation silently, so a boolean that\nreached a numeric slot by mistake type-checks exactly like one that was meant\nto. Writing `int(...)` says the number is what you meant, and widening the\nannotation to `bool` says the flag is.\n\nThe value has to be a boolean and the target a number for this to fire, so\narithmetic on booleans, a `bool` annotation, and a container of booleans are\nall left alone. Note that `int | bool` is not an escape hatch: a union of a\nclass and its subclass simplifies to the supertype, so that annotation *is*\n`int` and is reported as such.\n\n## Examples\n```python\ndef take(n: int): ...\n\na: int = True       # warning: `bool` used as `int`\ntake(True)          # warning: `bool` used as `int`\n\na2: int = int(True) # ok — explicit\na3: bool = True     # ok\na4 = True + 1       # ok — a boolean used as a boolean\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "call-abstract-method": {
          "title": "detects calls to abstract methods with trivial bodies on class objects",
          "description": "## What it does\n\nChecks for calls to abstract `@classmethod`s or `@staticmethod`s\nwith \"trivial bodies\" when accessed on the class object itself.\n\n\"Trivial bodies\" are bodies that solely consist of `...`, `pass`,\na docstring, and/or `raise NotImplementedError`.\n\n## Why is this bad?\n\nAn abstract method with a trivial body has no concrete implementation\nto execute, so calling such a method directly on the class will probably\nnot have the desired effect.\n\nIt is also unsound to call these methods directly on the class. Unlike\nother methods, ty permits abstract methods with trivial bodies to have\nnon-`None` return types even though they always return `None` at runtime.\nThis is because it is expected that these methods will always be\noverridden rather than being called directly. As a result of this\nexception to the normal rule, ty may infer an incorrect type if one of\nthese methods is called directly, which may then mean that type errors\nelsewhere in your code go undetected by ty.\n\nCalling abstract classmethods or staticmethods via `type[X]` is allowed,\nsince the actual runtime type could be a concrete subclass with an implementation.\n\n## Example\n\n```python\nfrom abc import ABC, abstractmethod\n\n\nclass Foo(ABC):\n    @classmethod\n    @abstractmethod\n    def method(cls) -> int: ...\n\n\n# cannot call abstract classmethod\nFoo.method()  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "call-non-callable": {
          "title": "detects calls to non-callable objects",
          "description": "## What it does\n\nChecks for calls to non-callable objects.\n\n## Why is this bad?\n\nCalling a non-callable object will raise a `TypeError` at runtime.\n\n## Examples\n\n```python\n# TypeError: 'int' object is not callable\n4()  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "call-top-callable": {
          "title": "detects calls to the top callable type",
          "description": "## What it does\n\nChecks for calls to objects typed as `Top[Callable[..., T]]` (the infinite union of all\ncallable types with return type `T`).\n\n## Why is this bad?\n\nWhen an object is narrowed to `Top[Callable[..., object]]` (e.g., via `callable(x)` or\n`isinstance(x, Callable)`), we know the object is callable, but we don't know its\nprecise signature. This type represents the set of all possible callable types\n(including, e.g., functions that take no arguments and functions that require arguments),\nso no specific set of arguments can be guaranteed to be valid.\n\n## Examples\n\n```python\ndef f(x: object):\n    if callable(x):\n        # We know `x` is callable, but not what arguments it accepts\n        x()  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "conflicting-declarations": {
          "title": "detects conflicting declarations",
          "description": "## What it does\n\nChecks whether a variable has been declared as two conflicting types.\n\n## Why is this bad\n\nA variable with two conflicting declarations likely indicates a mistake.\nMoreover, it could lead to incorrect or ill-defined type inference for\nother code that relies on these variables.\n\n## Examples\n\n```python\nif __name__ == \"__main__\":\n    a: int\nelse:\n    a: str\n\na = 1  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "conflicting-metaclass": {
          "title": "detects conflicting metaclasses",
          "description": "## What it does\n\nChecks for class definitions where the metaclass of the class\nbeing created would not be a subclass of the metaclasses of\nall the class's bases.\n\n## Why is it bad?\n\nSuch a class definition raises a `TypeError` at runtime.\n\n## Examples\n\n```pyi\nclass M1(type): ...\nclass M2(type): ...\nclass A(metaclass=M1): ...\nclass B(metaclass=M2): ...\n\n# TypeError: metaclass conflict\nclass C(A, B): ...  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "cyclic-class-definition": {
          "title": "detects cyclic class definitions",
          "description": "## What it does\n\nChecks for class definitions in stub files that inherit\n(directly or indirectly) from themselves.\n\n## Why is it bad?\n\nAlthough forward references are natively supported in stub files,\ninheritance cycles are still disallowed, as it is impossible to\nresolve a consistent [method resolution order] for a class that\ninherits from itself.\n\n## Examples\n\n`foo.pyi`:\n\n```pyi\nclass A(B): ...  # error\nclass B(A): ...  # error\n```\n\n[method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "cyclic-type-alias-definition": {
          "title": "detects cyclic type alias definitions",
          "description": "## What it does\n\nChecks for type alias definitions that (directly or mutually) refer to themselves.\n\n## Why is it bad?\n\nAlthough it is permitted to define a recursive type alias, it is not meaningful\nto have a type alias whose expansion can only result in itself, and is therefore not allowed.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\ntype Itself = Itself  # error\n\ntype A = B  # error\ntype B = A  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "dataclass-field-order": {
          "title": "detects dataclass definitions with required fields after fields with default values",
          "description": "## What it does\n\nChecks for dataclass definitions where required fields are defined after\nfields with default values.\n\n## Why is this bad?\n\nIn dataclasses, all required fields (fields without default values) must be\ndefined before fields with default values. This is a Python requirement that\nwill raise a `TypeError` at runtime if violated.\n\n## Example\n\n```python\nfrom dataclasses import dataclass\n\n\n@dataclass\nclass Example:\n    x: int = 1  # Field with default value\n    # Required field after field with default\n    y: str  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "deprecated": {
          "title": "detects uses of deprecated items",
          "description": "## What it does\n\nChecks for uses of deprecated items\n\n## Why is this bad?\n\nDeprecated items should no longer be used.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.13\"\n```\n\n```python\nimport warnings\n\n\n@warnings.deprecated(\"use new_func instead\")\ndef old_func(): ...\n\n\nold_func()  # error: [deprecated]\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "division-by-zero": {
          "title": "detects division by zero",
          "description": "## What it does\n\nIt detects division by zero.\n\n## Why is this bad?\n\nDividing by zero raises a `ZeroDivisionError` at runtime.\n\n## Rule status\n\nThis rule is currently disabled by default because of the number of\nfalse positives it can produce.\n\n## Examples\n\n```python\n5 / 0  # error\n```",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "duplicate-base": {
          "title": "detects class definitions with duplicate bases",
          "description": "## What it does\n\nChecks for class definitions with duplicate bases.\n\n## Why is this bad?\n\nClass definitions with duplicate bases raise `TypeError` at runtime.\n\n## Examples\n\n```python\nclass A: ...\n\n\n# TypeError: duplicate base class\nclass B(A, A): ...  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "duplicate-kw-only": {
          "title": "detects dataclass definitions with more than one usage of `KW_ONLY`",
          "description": "## What it does\n\nChecks for dataclass definitions with more than one field\nannotated with `KW_ONLY`.\n\n## Why is this bad?\n\n`dataclasses.KW_ONLY` is a special marker used to\nemulate the `*` syntax in normal signatures.\nIt can only be used once per dataclass.\n\nAttempting to annotate two different fields with\nit will lead to a runtime error.\n\n## Examples\n\n```python\nfrom dataclasses import dataclass, KW_ONLY\n\n\n# Crash at runtime\n@dataclass\nclass A:  # error\n    b: int\n    _1: KW_ONLY\n    c: str\n    _2: KW_ONLY\n    d: bytes\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "empty-body": {
          "title": "detects functions with empty bodies that have a non-`None` return type annotation",
          "description": "## What it does\n\nDetects functions with empty bodies that have a non-`None` return type annotation.\n\nThe errors reported by this rule have the same motivation as the `invalid-return-type`\nrule. The diagnostic exists as a separate error code to allow users to disable this\nrule while prototyping code. While we strongly recommend enabling this rule if\npossible, users migrating from other type checkers may also find it useful to\ntemporarily disable this rule on some or all of their codebase if they find it\nresults in a large number of diagnostics.\n\n## Why is this bad?\n\nA function with an empty body (containing only `...`, `pass`, or a docstring) will\nimplicitly return `None` at runtime. Returning `None` when the return type is non-`None`\nis unsound, and will lead to ty inferring incorrect types elsewhere.\n\nFunctions with empty bodies are permitted in certain contexts where they serve as\ndeclarations rather than implementations:\n\n- Functions in stub files (`.pyi`)\n- Methods in Protocol classes\n- Abstract methods decorated with `@abstractmethod`\n- Overload declarations decorated with `@overload`\n- Functions in `if TYPE_CHECKING` blocks\n\n## Examples\n\n```python\ndef foo() -> int: ...  # error: [empty-body]\n\n\ndef bar() -> str:  # error: [empty-body]\n    \"\"\"A function that does nothing.\"\"\"\n    pass\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "erased-cast-argument": {
          "title": "detects casts whose type arguments cannot be checked at runtime",
          "description": "## What it does\nChecks for a basedpython `cast` / `cast?` whose target type carries type\narguments that are erased at runtime.\n\n## Why is this bad?\nA checked cast validates its value with `isinstance`, which can only test\na class — a builtin container erases its type arguments, so `list[int]`\nis checkable only as `list`. The cast still narrows the static type to\n`list[int]`, but nothing verifies the `int` claim at runtime, which is\nexactly the assumption a checked cast exists to rule out.\n\nThis only fires where the claim really is assumed. A *user* generic\ncarries `__orig_class__`, so `A[int]` is checked in full. A value typed by\na *reified* type parameter carries the answer in a runtime cell, so\ncasting `list[T]` to `list[int]` compares `T == int` exactly. A *protocol*\nis checked structurally against the value's reified annotations — data\nmembers against class annotations, method members against\nparameter/return annotations. Only a protocol member whose specialized\ntype has no runtime spelling (a callable attribute) leaves the cast with\nno runtime residue, so the whole cast — not just its arguments — is left\nunchecked.\n\n## Example\n\n```by\nfrom typing import Protocol\nfrom collections.abc import Callable\n\ndef f(x: object):\n    a = x cast! list[int]   # warning: only `list` is checked\n    b = x cast! list        # ok — no argument claimed\n\nclass A[T]:\n    init(self, t: T)\n\ndef g(x: object):\n    a = x cast! A[int]      # ok — checked in full via `__orig_class__`\n\ndef r[T](data: list[T]):\n    a = data cast! list[int]  # ok — the reified `T` cell decides it\n\nclass HasCb[T](Protocol):\n    cb: Callable[[T], T]\n\ndef h(x: object):\n    a = x cast! HasCb[int]  # warning: a callable member has no runtime check\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "erased-type-check": {
          "title": "detects parametric type tests against a protocol with no runtime residue",
          "description": "## What it does\nChecks for parametric type tests (`x is P[int]`) against a protocol,\nwhich has no sound runtime residue.\n\n## Why is this bad?\nA parametric `is` test is answered from static types wherever possible\n(Rust-style). When it cannot be — the value's type is dynamic or a mixed\nunion — the last resort is a runtime probe that unwinds the value's\n`__orig_class__` and its class's generic bases across the mro. A protocol\nhas nothing to unwind: an instance's `__orig_class__` names its concrete\nclass, never the protocol, and a structural `isinstance` check sees no\ntype arguments (and raises outright unless the protocol is\n`@runtime_checkable`). So the test can never confirm the specialization.\n\n## Example\n\n```by\nfrom typing import Protocol\nclass P[T](Protocol):\n    def get(self) -> T: ...\n\ndef f(x):\n    return x is P[int]  # error: a protocol records no specialization\n```\n\nReify the type parameter (so the test compares the reified cell), or test\nagainst a concrete class that fixes the arguments (a user generic, or a\nsubclass whose `__orig_bases__` records the specialization):\n\n```by\ndef f[T](x: T):\n    return x is list[int]  # ok — compares the reified `T`\n\nclass A[T]: ...\ndef g(x):\n    return x is A[int]     # ok — unwinds `x`'s mro\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "escape-character-in-forward-annotation": {
          "title": "detects forward type annotations with escape characters",
          "description": "## What it does\n\nChecks for forward annotations that contain escape characters.\n\n## Why is this bad?\n\nStatic analysis tools like ty can't analyze type annotations that contain escape characters.\n\n## Example\n\n```python\ndef foo() -> \"intt\\b\": ...  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "escaping-local": {
          "title": "detects a `local` parameter whose value escapes its call",
          "description": "## What it does\nChecks for a basedpython `local` parameter whose value escapes the call it\nis bound in — returned to the caller, stored on a parameter-rooted object,\nassigned to a `global` / `nonlocal` binding, or passed on to a parameter\nthat is not itself a borrow.\n\nA callable type may declare its own parameters `local` too\n(`(local int) -> None`), which puts the same constraint on the trailing\nlambda block filling it: the block's implicit `it` is borrowed from the\ncall.\n\n## Why is this bad?\nA `local` parameter is borrowed only for the duration of the call. Letting\nits value outlive the call defeats the borrow: the caller may release the\nunderlying resource, leaving a dangling reference behind.\n\n## Example\n\n```by\n_saved: object\n\ndef f(local fn: () -> None):\n    global _saved\n    _saved = fn  # error: `fn` is local and cannot escape the call\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "escaping-loop-variable": {
          "title": "detects a trailing-lambda block capturing a loop variable with a non-borrow callee",
          "description": "## What it does\nChecks for a trailing-lambda block inside a loop that captures a loop\nvariable while its callee's callback parameter is **not** a borrow\n(`local` / `once`).\n\n## Why is this bad?\nA trailing-lambda block lowers to a closure that captures the loop variable\nby reference. If the callee is a borrow (`local` / `once`), it runs the\nblock synchronously — the variable still holds this iteration's value. But\na non-borrow callee may store the block and call it after the loop has\nadvanced, at which point every deferred call sees the loop variable's final\nvalue — the classic late-binding trap.\n\nThis is the type-aware complement to ruff's syntactic `B023`, which cannot\nresolve the callee's marker. An opaque callee (not a resolvable function or\nbound method) is left alone.\n\n## Example\n\n```by\ndef defer(fn: () -> None):  # not a borrow — may keep `fn`\n    _saved.append(fn)\n\nfor x in [1, 2, 3]:\n    defer:\n        print(x)  # error: captures loop variable `x`\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "experimental-syntax": {
          "title": "detects experimental syntax",
          "description": "## What it does\n\nChecks for experimental syntax that is not part of the Python typing specification.\n\n## Why is this bad?\n\nExperimental syntax is specific to ty. It may be rejected by other type checkers and may never be\nstandardized, or be subject to breaking changes.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.14\"\n```\n\n```python\nclass A: ...\n\n\nclass B: ...\n\n\ndef f(value: A & B) -> None: ...  # error: [experimental-syntax]\ndef g(value: ~A) -> None: ...  # error: [experimental-syntax]\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "final-on-non-method": {
          "title": "detects `@final` applied to non-method functions",
          "description": "## What it does\n\nChecks for `@final` decorators applied to non-method functions.\n\n## Why is this bad?\n\nThe `@final` decorator is only meaningful on methods and classes.\nApplying it to a module-level function or a nested function has no\neffect and is likely a mistake.\n\n## Example\n\n```python\nfrom typing import final\n\n\n# @final is not allowed on non-method functions\n@final  # error\ndef my_function() -> int:\n    return 0\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "final-on-variable": {
          "title": "detects the `final` modifier on a bare variable assignment",
          "description": "## What it does\nChecks for the basedpython `final` modifier applied to a bare variable\nassignment outside of a class body, e.g. `final a = 1`.\n\n## Why is this bad?\n`final` is a class/method modifier. On a bare assignment it lowers to a\nplain assignment and makes the variable no more final than before, so it\nis almost certainly a mistake. A final variable is declared with `let`,\nwhich lowers to `Final`.\n\n`final override` is a legitimate assignment marker and is not flagged.\n\n## Example\n\n```by\n# Error: `final` on a variable has no effect\nfinal a = 1\n\n# Correct: `let` declares a final variable\nlet a = 1\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "final-without-value": {
          "title": "detects `Final` declarations without a value",
          "description": "## What it does\n\nChecks for `Final` symbols that are declared without a value and are never\nassigned a value in their scope.\n\n## Why is this bad?\n\nA `Final` symbol must be initialized with a value at the time of declaration\nor in a subsequent assignment. At module or function scope, the assignment must\noccur in the same scope. In a class body, the assignment may occur in `__init__`.\nProtocol members are declarations of an interface and do not require a value.\n\n## Examples\n\n```python\nfrom typing import Final\n\n# `Final` symbol without a value\nMY_CONSTANT: Final[int]  # error\n\n# OK: `Final` symbol with a value\nINITIALIZED_CONSTANT: Final[int] = 1\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "ignore-comment-unknown-rule": {
          "title": "detects `ty: ignore` comments that reference unknown rules",
          "description": "## What it does\n\nChecks for `ty: ignore[code]` or `type: ignore[ty:code]` comments where `code` isn't a known lint rule.\n\n## Why is this bad?\n\nA `ty: ignore[code]` or a `type: ignore[ty:code]` directive with a `code` that doesn't match\nany known rule will not suppress any type errors, and is probably a mistake.\n\n## Examples\n\n```py\n# error\na = 20 / 1  # ty: ignore[division-by-zer]\n```\n\nUse instead:\n\n```py\na = 20 / 0  # ty: ignore[division-by-zero]\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "implicit-concatenated-string-type-annotation": {
          "title": "detects implicit concatenated strings in type annotations",
          "description": "## What it does\n\nChecks for implicit concatenated strings in type annotation positions.\n\n## Why is this bad?\n\nStatic analysis tools like ty can't analyze type annotations that use implicit concatenated strings.\n\n## Examples\n\n<!-- fmt:off -->\n\n```python\nfrom typing import Literal\n\ndef test() -> \"Literal[\" \"5\" \"]\":  # error\n    return 5\n```\n\n<!-- fmt:on -->\n\nUse instead:\n\n```python\nfrom typing import Literal\n\n\ndef test() -> \"Literal[5]\":\n    return 5\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "implicit-object-repr": {
          "title": "detects a value printed through `object.__repr__`",
          "description": "## What it does\nChecks for a value rendered as text when its class says nothing about\nhow it should look.\n\n## Why is this bad?\nA class that defines nothing the site can use falls back to the\ninterpreter's own default, which prints the class name and the address\nthe object happens to sit at — `<__main__.A object at 0x102bcc6a0>`.\nThat is never what the message was meant to say, and the address makes\nthe output differ on every run.\n\nWhich dunders count depends on what the site asks for, because the\nfallbacks run one way only: `object.__str__` calls `__repr__`, and\n`object.__format__` calls `str`, but nothing falls back to `__str__`.\n\n- `repr(x)`, `ascii(x)`, `f\"{x!r}\"` — only `__repr__`\n- `str(x)`, `print(x)`, `f\"{x!s}\"` — `__str__` or `__repr__`\n- `format(x)`, `f\"{x}\"` — `__format__`, `__str__` or `__repr__`\n\nOnly a class written in source is judged. A stub leaves these dunders\nout whether or not the runtime class has them — `int` declares none of\nthe three and still prints as a number — so a class that comes from a\nstub, or that inherits from one, is not reported. The exception is a\nstub named in `analysis.implicit-object-repr-report-types`, which\ndefaults to `types.FunctionType` and `builtins.type`: printing a bare\nfunction or class object is the same mistake, and neither stub is\nhiding a rendering.\n\n## Options\n- `analysis.implicit-object-repr-exempt-types`\n- `analysis.implicit-object-repr-report-types`\n\n## Examples\n```python\nclass Point:\n    def __init__(self, x: int):\n        self.x = x\n\nprint(Point(1))    # warning: prints `<__main__.Point object at 0x...>`\nf\"at {Point(1)}\"   # warning\n\nclass Spoken:\n    def __str__(self) -> str:\n        return \"Spoken()\"\n\nprint(Spoken())    # ok\nrepr(Spoken())     # warning: `__str__` is not what `repr` asks for\n\nclass Labelled:\n    def __repr__(self) -> str:\n        return \"Labelled()\"\n\nprint(Labelled())  # ok — `str` falls back to `__repr__`\nrepr(Labelled())   # ok\n\ndef helper() -> None: ...\n\nprint(helper)      # warning: prints `<function helper at 0x...>`\nprint(Labelled)    # warning: prints `<class '__main__.Labelled'>`\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "inconsistent-mro": {
          "title": "detects class definitions with an inconsistent MRO",
          "description": "## What it does\n\nChecks for classes with an inconsistent [method resolution order] (MRO).\n\n## Why is this bad?\n\nClasses with an inconsistent MRO will raise a `TypeError` at runtime.\n\n## Examples\n\n```python\nclass A: ...\n\n\nclass B(A): ...\n\n\n# TypeError: Cannot create a consistent method resolution order\nclass C(A, B): ...  # error\n```\n\n[method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "index-out-of-bounds": {
          "title": "detects index out of bounds errors",
          "description": "## What it does\n\nChecks for attempts to use an out of bounds index to get an item from\na container.\n\n## Why is this bad?\n\nUsing an out of bounds index will raise an `IndexError` at runtime.\n\n## Examples\n\n```python\nt = (0, 1, 2)\n# IndexError: tuple index out of range\nt[3]  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "ineffective-final": {
          "title": "detects calls to `final()` that type checkers cannot interpret",
          "description": "## What it does\n\nChecks for calls to `final()` that type checkers cannot interpret.\n\n## Why is this bad?\n\nThe `final()` function is designed to be used as a decorator. When called directly\nas a function (e.g., `final(type(...))`), type checkers will not understand the\napplication of `final` and will not prevent subclassing.\n\n## Example\n\n```python\nfrom typing import final\n\n# Incorrect: type checkers will not prevent subclassing\nMyClass = final(type(\"MyClass\", (), {}))  # error\n\n\n# Correct: use `final` as a decorator\n@final\nclass MyClass: ...\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "instance-layout-conflict": {
          "title": "detects class definitions that raise `TypeError` due to instance layout conflict",
          "description": "## What it does\n\nChecks for classes definitions which will fail at runtime due to\n\"instance memory layout conflicts\".\n\nThis error is usually caused by attempting to combine multiple classes\nthat define non-empty `__slots__` in a class's [Method Resolution Order][method-resolution-order]\n(MRO), or by attempting to combine multiple builtin classes in a class's\nMRO.\n\n## Why is this bad?\n\nInheriting from bases with conflicting instance memory layouts\nwill lead to a `TypeError` at runtime.\n\nAn instance memory layout conflict occurs when CPython cannot determine\nthe memory layout instances of a class should have, because the instance\nmemory layout of one of its bases conflicts with the instance memory layout\nof one or more of its other bases.\n\nFor example, if a Python class defines non-empty `__slots__`, this will\nimpact the memory layout of instances of that class. Multiple inheritance\nfrom more than one different class defining non-empty `__slots__` is not\nallowed:\n\n```python\nclass A:\n    __slots__ = (\"a\", \"b\")\n\n\nclass B:\n    __slots__ = (\"a\", \"b\")  # Even if the values are the same\n\n\n# TypeError: multiple bases have instance lay-out conflict\nclass C(A, B): ...  # error\n```\n\nAn instance layout conflict can also be caused by attempting to use\nmultiple inheritance with two builtin classes, due to the way that these\nclasses are implemented in a CPython C extension:\n\n```python\n# TypeError: multiple bases have instance lay-out conflict\nclass A(int, float): ...  # error\n```\n\nNote that pure-Python classes with no `__slots__`, or pure-Python classes\nwith empty `__slots__`, are always compatible:\n\n```python\nclass A: ...\n\n\nclass B:\n    __slots__ = ()\n\n\nclass C:\n    __slots__ = (\"a\", \"b\")\n\n\n# fine\nclass D(A, B, C): ...\n```\n\n## Known problems\n\nClasses that have \"dynamic\" definitions of `__slots__` (definitions do not consist\nof string literals, or tuples of string literals) are not currently considered disjoint\nbases by ty.\n\nAdditionally, this check is not exhaustive: many C extensions (including several in\nthe standard library) define classes that use extended memory layouts and thus cannot\ncoexist in a single MRO. Since it is currently not possible to represent this fact in\nstub files, having a full knowledge of these classes is also impossible. When it comes\nto classes that do not define `__slots__` at the Python level, therefore, ty, currently\nonly hard-codes a number of cases where it knows that a class will produce instances with\nan atypical memory layout.\n\n## Further reading\n\n- [CPython documentation: `__slots__`](https://docs.python.org/3/reference/datamodel.html#slots)\n- [CPython documentation: Method Resolution Order](https://docs.python.org/3/glossary.html#term-method-resolution-order)\n\n[method-resolution-order]: https://docs.python.org/3/glossary.html#term-method-resolution-order",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-argument-type": {
          "title": "detects call arguments whose type is not assignable to the corresponding typed parameter",
          "description": "## What it does\n\nDetects call arguments whose type is not assignable to the corresponding typed parameter.\n\n## Why is this bad?\n\nPassing an argument of a type the function (or callable object) does not accept violates\nthe expectations of the function author and may cause unexpected runtime errors within the\nbody of the function.\n\n## Examples\n\n```python\ndef func(x: int): ...\n\n\nfunc(\"foo\")  # error: [invalid-argument-type]\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-assignment": {
          "title": "detects invalid assignments",
          "description": "## What it does\n\nChecks for assignments where the type of the value\nis not [assignable to] the type of the assignee.\n\n## Why is this bad?\n\nSuch assignments break the rules of the type system and\nweaken a type checker's ability to accurately reason about your code.\n\n## Examples\n\n```python\na: int = \"\"  # error\n```\n\n[assignable to]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-attribute-access": {
          "title": "Invalid attribute access",
          "description": "## What it does\n\nChecks for assignments to class variables from instances\nand assignments to instance-only attributes from their class.\n\nAn \"instance-only\" variable is one which is only ever assigned to or declared\nwhen accessed via `self` in an instance method.\n\n## Why is this bad?\n\nIncorrect assignments break the rules of the type system and\nweaken a type checker's ability to accurately reason about your code.\n\n## Examples\n\n```python\nfrom typing import ClassVar\n\n\nclass C:\n    instance_var: int\n    class_var: ClassVar[int] = 1\n\n    def __init__(self):\n        # instance variable declared in the class body\n        self.instance_var = 42\n\n        # instance-only variable not declared in the class body\n        self.instance_only_var: int = 42\n\n\nC.class_var = 3  # okay\n\nC.instance_var = 56  # okay\nC().instance_var = 72  # okay\n\nC().instance_only_var = 100  # okay\n\n# Cannot assign to class variable from instance\nC().class_var = 3  # error\n\n# Cannot assign to instance-only variable from class\nC.instance_only_var = 56  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-attribute-override": {
          "title": "detects attribute overrides that change class-variable or instance-variable behavior",
          "description": "## What it does\n\nDetects attribute overrides that change whether an inherited attribute\nis a class variable or an instance variable.\n\nThis rule currently only covers class-variable and instance-variable\ncategory changes.\n\n## Why is this bad?\n\nPure class variables and instance variables have different access and\nassignment behavior. Overriding one with the other violates the\n[Liskov Substitution Principle][liskov-substitution-principle] (\"LSP\"), because code that is valid for\nthe superclass may no longer be valid for the subclass.\n\n## Example\n\n```python\nfrom typing import ClassVar\n\n\nclass Base:\n    instance_attr: int\n    class_attr: ClassVar[int]\n\n\nclass Sub(Base):\n    instance_attr: ClassVar[int]  # error: [invalid-attribute-override]\n    class_attr: int  # error: [invalid-attribute-override]\n```\n\n[liskov-substitution-principle]: https://en.wikipedia.org/wiki/Liskov_substitution_principle",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-await": {
          "title": "detects awaiting on types that don't support it",
          "description": "## What it does\n\nChecks for `await` being used with types that are not [Awaitable][awaitable-abc].\n\n## Why is this bad?\n\nSuch expressions will lead to `TypeError` being raised at runtime.\n\n## Examples\n\n```python\nimport asyncio\n\n\nclass InvalidAwait:\n    def __await__(self) -> int:\n        return 5\n\n\nasync def main() -> None:\n    await InvalidAwait()  # error: [invalid-await]\n    await 42  # error: [invalid-await]\n\n\nasyncio.run(main())\n```\n\n[awaitable-abc]: https://docs.python.org/3/library/collections.abc.html#collections.abc.Awaitable",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-base": {
          "title": "detects class bases that will cause the class definition to raise an exception at runtime",
          "description": "## What it does\n\nChecks for class definitions that have bases which are not instances of `type`.\n\n## Why is this bad?\n\nClass definitions with bases like this will lead to `TypeError` being raised at runtime.\n\n## Examples\n\n```python\nclass A(42): ...  # error: [invalid-base]\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-conformance": {
          "title": "detects invalid basedpython conformance declarations",
          "description": "## What it does\nChecks for invalid basedpython conformance declarations\n(`extension str(A):`): an interface that is neither a protocol nor an\nabstract class, or a requirement nothing answers.\n\n## Why is this bad?\nA conformance states that an existing type satisfies an existing\ninterface, and registers a witness table so that a call through an\ninterface-typed receiver reaches it. Conforming to a concrete class would\nmean promising its fields, which a conformance has nowhere to store; and a\nrequirement neither the block, a default on the interface's own extension,\nnor the type itself answers is an `AttributeError` the first time anything\ndispatches through the conformance.\n\n## Example\n\n```by\nprotocol A:\n    def bar(self)\n\nextension str(A):  # error: `str` does not answer every member of `A`\n    ...\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-context-manager": {
          "title": "detects expressions used in with statements that don't implement the context manager protocol",
          "description": "## What it does\n\nChecks for expressions used in `with` statements\nthat do not implement the context manager protocol.\n\n## Why is this bad?\n\nSuch a statement will raise `TypeError` at runtime.\n\n## Examples\n\n```python\n# TypeError: 'int' object does not support the context manager protocol\nwith 1:  # error\n    print(2)\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-conversion": {
          "title": "detects malformed basedpython conversion dunders",
          "description": "## What it does\nChecks that the basedpython conversion dunders have the shape their\nlowered call needs: `__from__` and `__of__` are classmethods on the target\ntaking one value and returning it, and `__into__` is a plain instance\nmethod on the source taking nothing.\n\n## Why is this bad?\nA conversion site lowers to `Target.__from__(value)` or `value.__into__()`.\nA `__from__` that is not a classmethod would bind the value to its first\nparameter, and an overloaded `__into__` would have nothing to dispatch on —\nso a malformed dunder converts nothing, silently, wherever it was meant to.\n\n## Example\n\n```by\nclass Fahrenheit:\n    def __from__(cls, value: Celsius) -> Self:  # error: not a classmethod\n        ...\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-dataclass": {
          "title": "detects invalid `@dataclass` applications",
          "description": "## What it does\n\nChecks for invalid applications of the `@dataclass` decorator.\n\n## Why is this bad?\n\nApplying `@dataclass` with incompatible arguments raises an exception while creating the\nclass:\n\n- `order=True` with `eq=False`\n- `weakref_slot=True` with `slots=False`\n\nApplying `@dataclass` to a class that inherits from `NamedTuple`, `TypedDict`,\n`Enum`, or `Protocol` is also invalid:\n\n- `NamedTuple` and `TypedDict` classes will raise an exception at runtime when\n    instantiating the class.\n- `Enum` classes with `@dataclass` are [explicitly not supported].\n- `Protocol` classes define interfaces and cannot be instantiated.\n\n## Examples\n\n```python\nfrom dataclasses import dataclass\nfrom typing import NamedTuple\n\n\n@dataclass(order=True, eq=False)  # error: [invalid-dataclass]\nclass Ordered: ...\n\n\n@dataclass\nclass Foo(NamedTuple):  # error: [invalid-dataclass]\n    x: int\n```\n\nSee: <https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass>\n\n[explicitly not supported]: https://docs.python.org/3/howto/enum.html#dataclass-support",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-dataclass-override": {
          "title": "detects dataclasses with `frozen=True` that have a custom `__setattr__` or `__delattr__` implementation",
          "description": "## What it does\n\nChecks for dataclass definitions that have both `frozen=True` and a custom `__setattr__` or\n`__delattr__` method defined.\n\n## Why is this bad?\n\nFrozen dataclasses synthesize `__setattr__` and `__delattr__` methods which raise a\n`FrozenInstanceError` to emulate immutability.\n\nOverriding either of these methods raises a runtime error.\n\n## Examples\n\n```python\nfrom dataclasses import dataclass\n\n\n@dataclass(frozen=True)\nclass A:\n    def __setattr__(self, name: str, value: object) -> None: ...  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-declaration": {
          "title": "detects invalid declarations",
          "description": "## What it does\n\nChecks for declarations where the inferred type of an existing symbol\nis not [assignable to] its post-hoc declared type.\n\n## Why is this bad?\n\nSuch declarations break the rules of the type system and\nweaken a type checker's ability to accurately reason about your code.\n\n## Examples\n\n```python\na = 1\na: str  # error\n```\n\n[assignable to]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-enum-member-annotation": {
          "title": "detects type annotations on enum members",
          "description": "## What it does\n\nChecks for enum members that have explicit type annotations.\n\n## Why is this bad?\n\nThe [typing spec] states that type checkers should infer a literal type\nfor all enum members. An explicit type annotation on an enum member is\nmisleading because the annotated type will be incorrect — the actual\nruntime type is the enum class itself, not the annotated type.\n\nIn CPython's `enum` module, annotated assignments with values are still\ntreated as members at runtime, but the annotation will confuse readers of the code.\n\n## Examples\n\n```python\nfrom enum import Enum\n\n\nclass Pet(Enum):\n    CAT = 1  # OK\n    # enum members should not be annotated\n    DOG: int = 2  # error\n```\n\nUse instead:\n\n```python\nfrom enum import Enum\n\n\nclass Pet(Enum):\n    CAT = 1\n    DOG = 2\n```\n\n## References\n\n- [Typing spec: Enum members](https://typing.python.org/en/latest/spec/enums.html#enum-members)\n\n[typing spec]: https://typing.python.org/en/latest/spec/enums.html#enum-members",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-exception-caught": {
          "title": "detects exception handlers that catch classes that do not inherit from `BaseException`",
          "description": "## What it does\n\nChecks for exception handlers that catch non-exception classes.\n\n## Why is this bad?\n\nCatching classes that do not inherit from `BaseException` will raise a `TypeError` at runtime.\n\n## Example\n\n```python\nimport random\n\n\ndef might_raise() -> float:\n    return 1 / random.choice([0, 1, 2, 3, 4, 5])\n\n\ntry:\n    might_raise()\nexcept 1:  # error\n    ...\n```\n\nUse instead:\n\n```python\nimport random\n\n\ndef might_raise() -> float:\n    return 1 / random.choice([0, 1, 2, 3, 4, 5])\n\n\ntry:\n    might_raise()\nexcept ZeroDivisionError:\n    ...\n```\n\n## References\n\n- [Python documentation: except clause](https://docs.python.org/3/reference/compound_stmts.html#except-clause)\n- [Python documentation: Built-in Exceptions](https://docs.python.org/3/library/exceptions.html#built-in-exceptions)\n\n## Ruff rule\n\nThis rule corresponds to Ruff's [`except-with-non-exception-classes` (`B030`)](https://docs.astral.sh/ruff/rules/except-with-non-exception-classes)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-explicit-override": {
          "title": "detects methods that are decorated with `@override` but do not override any method in a superclass",
          "description": "## What it does\n\nChecks for methods that are decorated with `@override` but do not override any method in a superclass.\n\n## Why is this bad?\n\nDecorating a method with `@override` declares to the type checker that the intention is that it should\noverride a method from a superclass.\n\n## Example\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\nfrom typing import override\n\n\nclass A:\n    @override\n    def foo(self): ...  # error\n\n\nclass B(A):\n    @override\n    def ffooo(self): ...  # error\n\n\nclass C:\n    @override\n    def __repr__(self): ...  # fine: overrides `object.__repr__`\n\n\nclass D(A):\n    @override\n    def foo(self): ...  # fine: overrides `A.foo`\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-extension": {
          "title": "detects invalid basedpython extension declarations",
          "description": "## What it does\nChecks for invalid basedpython `extension` declarations: an extended\nname that does not resolve to a class, a bracket type parameter the\nextended type does not declare, or a member that would add stored state.\n\n## Why is this bad?\nAn extension adds behaviour to an existing type. Its name must reference\na class declaration, its bracket parameters reuse (and constrain) that\nclass's own type parameters by name, and its members are resolved at\ntranspile time with nowhere to store new fields on already-constructed\ninstances.\n\n## Example\n\n```by\nextension list[T: int]:  # error: `list` declares no type parameter `T`\n    def total(self) -> int:\n        return sum(self)\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-field-lookup": {
          "title": "detects invalid django model field lookups and field-name arguments",
          "description": "## What it does\nChecks django ORM lookups, `create()` keywords, and field-name string\narguments (`order_by`, `only`, …) against the model's fields.\n\n## Why is this bad?\nThe queryset API accepts `**kwargs`, so a mistyped field name or an\noperand of the wrong type for a lookup is silently accepted by the\nstubs and only fails at runtime.\n\n## Example\n\n```py\nAuthor.objects.filter(nam=\"x\")            # error: no field `name`\nAuthor.objects.filter(name__startswith=1) # error: lookup wants `str`\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-fixture-type": {
          "title": "detects a pytest parameter annotation incompatible with its fixture",
          "description": "## What it does\nChecks that a pytest test or fixture parameter's type annotation is\ncompatible with the type provided by the fixture of the same name.\n\n## Why is this bad?\npytest fills the parameter by name from the fixture registry. If the\nannotation drifts from the fixture's real type, the test body is\nchecked against a type the parameter never actually has, hiding real\nerrors.\n\n## Example\n\n```py\nimport pytest\n\n@pytest.fixture\ndef user() -> str:\n    return \"alice\"\n\ndef test_user(user: int) -> None:  # error: fixture provides `str`\n    ...\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-format-spec": {
          "title": "detects a format spec the value's `__format__` does not accept",
          "description": "## What it does\nChecks the format spec in an f-string replacement field against the\n`__format__` that will read it.\n\n## Why is this bad?\n`f\"{value:spec}\"` calls `type(value).__format__(value, \"spec\")`, so a\nspec the type does not accept is a `TypeError` or `ValueError` at\nruntime, on a line that looks like nothing but text.\n\nTwo things are checked. The spec has to be an argument `__format__`\naccepts, which for a class that defines none of its own means the empty\nspec, because that is all `object.__format__` can do. And when the\n`__format__` reached is one of the four that read the [format\nspecification mini-language] — `str`, `int`, `float`, `complex` — the\nspec has to be one those rules allow: `str` has no sign, `int` has no\nprecision, and neither has the other's presentation types.\n\nA type with a `__format__` of its own outside that set is checked only\nas a call. `datetime` reads the same string as strftime codes, and\nnothing about the mini-language applies to it.\n\n## Examples\n```python\nclass Point:\n    pass\n\nf\"{Point():>10}\"  # error: `Point` only has `object.__format__`\nf\"{'name':d}\"     # error: `d` is not a presentation type for `str`\nf\"{1:.2}\"         # error: an integer has no precision\nf\"{1:.2f}\"        # ok — `f` formats the integer as a float\nf\"{'name':>10}\"   # ok\n```\n\n[format specification mini-language]: https://docs.python.org/3/library/string.html#format-specification-mini-language",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-frozen-dataclass-subclass": {
          "title": "detects dataclasses with invalid frozen/non-frozen subclassing",
          "description": "## What it does\n\nChecks for dataclasses with invalid frozen inheritance:\n\n- A frozen dataclass cannot inherit from a non-frozen dataclass.\n- A non-frozen dataclass cannot inherit from a frozen dataclass.\n\n## Why is this bad?\n\nPython raises a `TypeError` at runtime when either of these inheritance\npatterns occurs.\n\n## Example\n\n```python\nfrom dataclasses import dataclass\n\n\n@dataclass\nclass Base:\n    x: int\n\n\n@dataclass(frozen=True)\nclass Child(Base):  # error\n    y: int\n\n\n@dataclass(frozen=True)\nclass FrozenBase:\n    x: int\n\n\n@dataclass\nclass NonFrozenChild(FrozenBase):  # error\n    y: int\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-generic-class": {
          "title": "detects invalid generic classes",
          "description": "## What it does\n\nChecks for the creation of invalid generic classes\n\n## Why is this bad?\n\nThere are several requirements that you must follow when defining a generic class.\nMany of these result in `TypeError` being raised at runtime if they are violated.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\nfrom typing_extensions import Generic, TypeVar\n\nT = TypeVar(\"T\")\nU = TypeVar(\"U\", default=int)\nV = TypeVar(\"V\", covariant=True)\n\n\n# class uses both PEP-695 syntax and legacy syntax\nclass C[U](Generic[T]): ...  # error\n\n\n# type parameter with default comes before type parameter without default\nclass D(Generic[U, T]): ...  # error\n\n\n# covariant type parameter used in a position that requires contravariance\nclass E(Generic[V]):  # error\n    def set(self, value: V) -> None: ...\n```\n\n## References\n\n- [Typing spec: Generics](https://typing.python.org/en/latest/spec/generics.html#introduction)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-generic-enum": {
          "title": "detects generic enum classes",
          "description": "## What it does\n\nChecks for enum classes that are also generic.\n\n## Why is this bad?\n\nEnum classes cannot be generic. Python does not support generic enums:\nattempting to create one will either result in an immediate `TypeError`\nat runtime, or will create a class that cannot be specialized in the way\nthat a normal generic class can.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\nfrom enum import Enum\nfrom typing import Generic, TypeVar\n\nT = TypeVar(\"T\")\n\n\n# enum class cannot be generic (class creation fails with `TypeError`)\nclass E[T](Enum):  # error\n    A = 1\n\n\n# enum class cannot be generic (class creation fails with `TypeError`)\nclass F(Enum, Generic[T]):  # error\n    A = 1\n\n\n# enum class cannot be generic -- the class creation does not immediately fail...\nclass G(Generic[T], Enum):  # error\n    A = 1\n\n\n# ...but this raises `KeyError`:\nx: G[int]\n```\n\n## References\n\n- [Python documentation: Enum](https://docs.python.org/3/library/enum.html)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-ignore-comment": {
          "title": "detects ignore comments that use invalid syntax",
          "description": "## What it does\n\nChecks for `type: ignore` and `ty: ignore` comments that are syntactically incorrect.\n\n## Why is this bad?\n\nA syntactically incorrect ignore comment is probably a mistake and is useless.\n\n## Examples\n\n```py\n# error\na = 20 / 1  # type: ignoree\n```\n\nUse instead:\n\n```py\na = 20 / 0  # type: ignore\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-key": {
          "title": "detects invalid subscript accesses or TypedDict literal keys",
          "description": "## What it does\n\nChecks for subscript accesses with invalid keys and `TypedDict` construction with an\nunknown key.\n\n## Why is this bad?\n\nSubscripting with an invalid key will raise a `KeyError` at runtime.\n\nCreating a `TypedDict` with an unknown key is likely a mistake; if the `TypedDict` is\n`closed=true` it also violates the expectations of the type.\n\n## Examples\n\n```python\nfrom typing import TypedDict\nfrom typing_extensions import NotRequired\n\n\nclass Person(TypedDict):\n    name: NotRequired[str]\n    age: NotRequired[int]\n\n\nalice = Person(name=\"Alice\", age=30)\n# KeyError: 'height'\nalice[\"height\"]  # error\n\n# error\nbob: Person = {\"nickname\": \"Bob\", \"age\": 30}  # typo!\n\n# error\ncarol = Person(name=\"Carol\", aeg=25)  # typo!\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-legacy-positional-parameter": {
          "title": "detects incorrect usage of the legacy convention for specifying positional-only parameters",
          "description": "## What it does\n\nChecks for parameters that appear to be attempting to use the legacy convention\nto specify that a parameter is positional-only, but do so incorrectly.\n\nThe \"legacy convention\" for specifying positional-only parameters was\nspecified in [PEP 484][pep-484]. It states that parameters with names starting with\n`__` should be considered positional-only by type checkers. [PEP 570][pep-570], introduced\nin Python 3.8, added dedicated syntax for specifying positional-only parameters,\nrendering the legacy convention obsolete. However, some codebases may still\nuse the legacy convention for compatibility with older Python versions.\n\n## Why is this bad?\n\nIn most cases, a type checker will not consider a parameter to be positional-only\nif it comes after a positional-or-keyword parameter, even if its name starts with\n`__`. This may be unexpected to the author of the code.\n\n## Example\n\n```python\n# `__y` is not considered positional-only\ndef f(x, __y):  # error\n    pass\n```\n\nUse instead:\n\n```python\ndef f(__x, __y):  # If you need compatibility with Python <=3.7\n    pass\n```\n\nor:\n\n```python\ndef f(x, y, /):  # Python 3.8+ syntax\n    pass\n```\n\n## References\n\n- [Typing spec: positional-only parameters (legacy syntax)](https://typing.python.org/en/latest/spec/historical.html#pos-only-double-underscore)\n- [Python glossary: parameters](https://docs.python.org/3/glossary.html#term-parameter)\n\n[pep-484]: https://peps.python.org/pep-0484/#positional-only-arguments\n[pep-570]: https://peps.python.org/pep-0570/",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-legacy-type-variable": {
          "title": "detects invalid legacy type variables",
          "description": "## What it does\n\nChecks for the creation of invalid legacy `TypeVar`s\n\n## Why is this bad?\n\nThere are several requirements that you must follow when creating a legacy `TypeVar`.\n\n## Examples\n\n```python\nfrom typing import TypeVar\n\nT = TypeVar(\"T\")  # okay\nT = TypeVar(\"T\")  # error: \"Cannot redefine `T` as a type variable\"\n\n\n# TypeVar must be immediately assigned to a variable\n# error\ndef f(t: TypeVar(\"U\")): ...  # ty: ignore[invalid-type-form]\n```\n\n## References\n\n- [Typing spec: Generics](https://typing.python.org/en/latest/spec/generics.html#introduction)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-match-pattern": {
          "title": "detect invalid match patterns",
          "description": "## What it does\n\nChecks for invalid match patterns.\n\n## Why is this bad?\n\nInvalid match patterns can cause a `TypeError` or a `SyntaxError` at runtime.\nThis includes:\n\n- Using a non-type object in a class pattern.\n- Providing positional subpatterns when `__match_args__` is missing or has an invalid static type.\n- Matching against `collections.abc.Callable` with positional subpatterns.\n- Matching against a non-runtime-checkable protocol.\n- Matching against a `TypedDict`.\n- basedpython: a bare `case A:` that captures rather than naming a member of the subject's type.\n\n## Examples\n\n```python\nclass Point:\n    __match_args__ = (\"x\", \"y\")\n\n\ndef describe(p: Point) -> None:\n    match p:\n        # TypeError at runtime: Point() accepts 2 positional sub-patterns (3 given)\n        case Point(x, y, z):  # error: [invalid-match-pattern]\n            ...\n```\n\n```python\nNotAClass = 42\n\nmatch object():\n    # TypeError at runtime: called match pattern must be a class\n    case NotAClass():  # error: [invalid-match-pattern]\n        ...\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-metaclass": {
          "title": "detects invalid `metaclass=` arguments",
          "description": "## What it does\n\nChecks for arguments to `metaclass=` that are invalid.\n\n## Why is this bad?\n\nPython allows arbitrary expressions to be used as the argument to `metaclass=`.\nThese expressions, however, need to be callable and accept the same arguments\nas `type.__new__`.\n\n## Example\n\n```python\n# TypeError: 'int' object is not callable\nclass B(metaclass=42): ...  # error\n```\n\n## References\n\n- [Python documentation: Metaclasses](https://docs.python.org/3/reference/datamodel.html#metaclasses)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-method-override": {
          "title": "detects method definitions that violate the Liskov Substitution Principle",
          "description": "## What it does\n\nDetects method overrides that violate the [Liskov Substitution Principle][liskov-substitution-principle] (\"LSP\").\n\nThe LSP states that an instance of a subtype should be substitutable for an instance of its supertype.\nApplied to Python, this means:\n\n1. All argument combinations a superclass method accepts\n    must also be accepted by an overriding subclass method.\n1. The return type of an overriding subclass method must be a subtype\n    of the return type of the superclass method.\n\n## Why is this bad?\n\nViolating the Liskov Substitution Principle will lead to many of ty's assumptions and\ninferences being incorrect, which will mean that it will fail to catch many possible\ntype errors in your code.\n\n## Example\n\n```python\nclass Super:\n    def method(self, x) -> int:\n        return 42\n\n\nclass Sub(Super):\n    # Liskov violation: `str` is not a subtype of `int`,\n    # but the supertype method promises to return an `int`.\n    def method(self, x) -> str:  # error: [invalid-method-override]\n        return \"foo\"\n\n\ndef accepts_super(s: Super) -> int:\n    return s.method(x=42)\n\n\n# The result of this call is a string, but ty will infer it to be an `int`\n# due to the violation of the Liskov Substitution Principle.\naccepts_super(Sub())\n\n\nclass Sub2(Super):\n    # Liskov violation: the superclass method can be called with a `x=`\n    # keyword argument, but the subclass method does not accept it.\n    def method(self, y) -> int:  # error: [invalid-method-override]\n        return 42\n\n\n# TypeError at runtime: method() got an unexpected keyword argument 'x'\n# ty cannot catch this error due to the violation of the Liskov Substitution Principle.\naccepts_super(Sub2())\n```\n\n## Common issues\n\n### Why does ty complain about my `__eq__` method?\n\n`__eq__` and `__ne__` methods in Python are generally expected to accept arbitrary\nobjects as their second argument, for example:\n\n```python\nclass A:\n    x: int\n\n    def __eq__(self, other: object) -> bool:\n        # gracefully handle an object of an unexpected type\n        # without raising an exception\n        if not isinstance(other, A):\n            return False\n        return self.x == other.x\n```\n\nIf `A.__eq__` here were annotated as only accepting `A` instances for its second argument,\nit would imply that you wouldn't be able to use `==` between instances of `A` and\ninstances of unrelated classes without an exception possibly being raised. While some\nclasses in Python do indeed behave this way, the strongly held convention is that it should\nbe avoided wherever possible. As part of this check, therefore, ty enforces that `__eq__`\nand `__ne__` methods accept `object` as their second argument.\n\n### Why does ty disagree with Ruff about how to write my method?\n\nRuff has several rules that will encourage you to rename a parameter, or change its type\nsignature, if it thinks you're falling into a certain anti-pattern. For example, Ruff's\n[ARG002](https://docs.astral.sh/ruff/rules/unused-method-argument/) rule recommends that an\nunused parameter should either be removed or renamed to start with `_`. Applying either of\nthese suggestions can cause ty to start reporting an `invalid-method-override` error if\nthe function in question is a method on a subclass that overrides a method on a superclass,\nand the change would cause the subclass method to no longer accept all argument combinations\nthat the superclass method accepts.\n\nThis can usually be resolved by adding [`@typing.override`][override] to your method\ndefinition. Ruff knows that a method decorated with `@typing.override` is intended to\noverride a method by the same name on a superclass, and avoids reporting rules like ARG002\nfor such methods; it knows that the changes recommended by ARG002 would violate the Liskov\nSubstitution Principle.\n\nCorrect use of `@override` is enforced by ty's `invalid-explicit-override` rule.\n\n[liskov-substitution-principle]: https://en.wikipedia.org/wiki/Liskov_substitution_principle\n[override]: https://docs.python.org/3/library/typing.html#typing.override",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-named-tuple": {
          "title": "detects invalid `NamedTuple` class definitions",
          "description": "## What it does\n\nChecks for invalidly defined `NamedTuple` classes.\n\n## Why is this bad?\n\nAn invalidly defined `NamedTuple` class may lead to the type checker\ndrawing incorrect conclusions. It may also lead to `TypeError`s or\n`AttributeError`s at runtime.\n\n## Examples\n\nA class definition cannot combine `NamedTuple` with other base classes\nin multiple inheritance; doing so raises a `TypeError` at runtime. The sole\nexception to this rule is `Generic[]`, which can be used alongside `NamedTuple`\nin a class's bases list.\n\n```pycon\n>>> from typing import NamedTuple\n>>> class Foo(NamedTuple, object): ...\nTypeError: can only inherit from a NamedTuple type and Generic\n```\n\nFurther, `NamedTuple` field names cannot start with an underscore:\n\n```pycon\n>>> from typing import NamedTuple\n>>> class Foo(NamedTuple):\n...     _bar: int\nValueError: Field names cannot start with an underscore: '_bar'\n```\n\n`NamedTuple` classes also have certain synthesized attributes (like `_asdict`, `_make`,\n`_replace`, etc.) that cannot be overwritten. Attempting to assign to these attributes\nwithout a type annotation will raise an `AttributeError` at runtime.\n\n```pycon\n>>> from typing import NamedTuple\n>>> class Foo(NamedTuple):\n...     x: int\n...     _asdict = 42\nAttributeError: Cannot overwrite NamedTuple attribute _asdict\n```\n\nFinally, `NamedTuple` field annotations cannot use the `ClassVar` or `Final` type\nqualifiers. These qualifiers also cause a runtime error when annotations are evaluated eagerly:\n\n```pycon\n>>> from typing import ClassVar, NamedTuple\n>>> class Foo(NamedTuple):\n...     x: ClassVar[int]\nTypeError: typing.ClassVar[int] is not valid as type argument\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-named-tuple-override": {
          "title": "detects subclass members that override inherited `NamedTuple` fields",
          "description": "## What it does\n\nChecks for subclass members that override inherited `NamedTuple` fields.\n\n## Why is this bad?\n\nReusing an inherited `NamedTuple` field name in a subclass creates a\nclass where tuple indexing and `repr()` still reflect the original\nfield, while attribute access follows the subclass member.\n\n## Default level\n\nThis rule is a warning by default because these overrides do not make\nthe class invalid at runtime.\n\n## Examples\n\n```python\nfrom typing import NamedTuple\n\n\nclass User(NamedTuple):\n    name: str\n\n\nclass Admin(User):\n    name = \"shadowed\"  # error: [invalid-named-tuple-override]\n\n\nadmin = Admin(\"Alice\")\nadmin.name  # \"shadowed\"\nadmin[0]  # \"Alice\"\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-newtype": {
          "title": "detects invalid NewType definitions",
          "description": "## What it does\n\nChecks for the creation of invalid `NewType`s\n\n## Why is this bad?\n\nThere are several requirements that you must follow when creating a `NewType`.\n\n## Examples\n\n```python\nfrom typing import NewType\n\n\ndef get_name() -> str:\n    return \"name\"\n\n\nFoo = NewType(\"Foo\", int)  # okay\n# The first argument to `NewType` must be a string literal\nBar = NewType(get_name(), int)  # error\n# invalid base for `typing.NewType`\nBaz = NewType(\"Baz\", int | str)  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-overload": {
          "title": "detects invalid `@overload` usages",
          "description": "## What it does\n\nChecks for various invalid `@overload` usages.\n\n## Why is this bad?\n\nThe `@overload` decorator is used to define functions and methods that accepts different\ncombinations of arguments and return different types based on the arguments passed. This is\nmainly beneficial for type checkers. But, if the `@overload` usage is invalid, the type\nchecker may not be able to provide correct type information.\n\n## Examples\n\n### Single overload\n\n```py\nfrom typing import overload\n\n\n@overload\ndef foo(x: int) -> int: ...  # error\ndef foo(x: int | None) -> int | None:\n    return x\n```\n\n### Missing implementation\n\n```py\nfrom typing import overload\n\n\n@overload\ndef foo() -> None: ...  # error\n@overload\ndef foo(x: int) -> int: ...\n```\n\n## References\n\n- [Python documentation: `@overload`](https://docs.python.org/3/library/typing.html#typing.overload)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-parameter-default": {
          "title": "detects default values that can't be assigned to the parameter's annotated type",
          "description": "## What it does\n\nChecks for default values that can't be\nassigned to the parameter's annotated type.\n\n## Why is this bad?\n\nThis breaks the rules of the type system and\nweakens a type checker's ability to accurately reason about your code.\n\n## Examples\n\n```python\ndef f(a: int = \"\"): ...  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-parametrize": {
          "title": "detects a pytest parametrize name or arity mismatch",
          "description": "## What it does\nChecks `@pytest.mark.parametrize` argument names against the decorated\nfunction's parameters, and each parameter set's arity against the\nnumber of names.\n\n## Why is this bad?\npytest raises a collection error when a parametrized name is not a\nfunction parameter, or when a value row's length does not match the\nnumber of names. These fail only when the test is collected.\n\n## Example\n\n```py\nimport pytest\n\n@pytest.mark.parametrize(\"a, b\", [(1, 2), (3,)])  # error: row has 1 value, expected 2\ndef test_add(a: int, b: int) -> None:\n    ...\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-paramspec": {
          "title": "detects invalid ParamSpec usage",
          "description": "## What it does\n\nChecks for the creation of invalid `ParamSpec`s\n\n## Why is this bad?\n\nThere are several requirements that you must follow when creating a `ParamSpec`.\n\n## Examples\n\n```python\nfrom typing import ParamSpec\n\nP1 = ParamSpec(\"P1\")  # okay\n# ParamSpec requires a name\nP2 = ParamSpec()  # error\n```\n\n## References\n\n- [Typing spec: ParamSpec](https://typing.python.org/en/latest/spec/generics.html#paramspec)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-protocol": {
          "title": "detects invalid protocol class definitions",
          "description": "## What it does\n\nChecks for protocol classes that will raise `TypeError` at runtime.\n\n## Why is this bad?\n\nAn invalidly defined protocol class may lead to the type checker inferring\nunexpected things. It may also lead to `TypeError`s at runtime.\n\n## Examples\n\nA `Protocol` class cannot inherit from a non-`Protocol` class;\nthis raises a `TypeError` at runtime:\n\n```pycon\n>>> from typing import Protocol\n>>> class Foo(int, Protocol): ...\nTraceback (most recent call last):\n  File \"<python-input-1>\", line 1, in <module>\n    class Foo(int, Protocol): ...\nTypeError: Protocols can only inherit from other protocols, got <class 'int'>\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-raise": {
          "title": "detects `raise` statements that raise invalid exceptions or use invalid causes",
          "description": "Checks for `raise` statements that raise non-exceptions or use invalid\ncauses for their raised exceptions.\n\n## Why is this bad?\n\nOnly subclasses or instances of `BaseException` can be raised.\nFor an exception's cause, the same rules apply, except that `None` is also\npermitted. Violating these rules results in a `TypeError` at runtime.\n\n## Examples\n\n```python\ndef something():\n    raise NameError\n\n\ndef cause() -> None:\n    pass\n\n\ndef f():\n    try:\n        something()\n    except NameError:\n        # error: \"Cannot raise object of type `Literal[\"oops!\"]`\"\n        # error: \"Cannot use object of type `def cause()` as an exception cause\"\n        raise \"oops!\" from cause\n\n\ndef g():\n    # error: \"Cannot raise `NotImplemented`\"\n    # error: \"Cannot use object of type `Literal[42]` as an exception cause\"\n    raise NotImplemented from 42\n```\n\nUse instead:\n\n```python\ndef something():\n    raise NameError\n\n\ndef f():\n    try:\n        something()\n    except NameError as e:\n        raise RuntimeError(\"oops!\") from e\n\n\ndef g():\n    raise NotImplementedError from None\n```\n\n## References\n\n- [Python documentation: The `raise` statement](https://docs.python.org/3/reference/simple_stmts.html#raise)\n- [Python documentation: Built-in Exceptions](https://docs.python.org/3/library/exceptions.html#built-in-exceptions)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-raises-clause": {
          "title": "detects a `raises` clause that is not a set of exceptions",
          "description": "## What it does\nChecks for a basedpython `raises` clause that does not describe a set of\nexceptions.\n\n## Why is this bad?\nOnly a `BaseException` subclass can be raised, so a clause with no\nexception in it can never be satisfied by anything the function does.\n\n## Example\n\n```by\ndef f() raises int:  # error: `int` is not an exception\n    ...\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-regex": {
          "title": "detects an invalid regular expression or a reference to a group it has not got",
          "description": "## What it does\nChecks a literal regular expression passed to the `re` module: that it\ncompiles at all, and that every group a match is asked for exists in it.\n\n## Why is this bad?\nThe stubs type every `re` pattern as a plain `str`, so a pattern that\n`re.compile` rejects, or a `m.group(3)` on a pattern with two groups,\nonly fails once the line runs.\n\n## Example\n\n```py\nimport re\n\nre.compile(\"(\")  # error: missing ), unterminated subpattern at position 0\n\nif m := re.match(\"(a)(b)\", \"ab\"):\n    m.group(3)  # error: No such group: 3\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-reified-type-param": {
          "title": "detects `reified` type parameters that cannot be reified",
          "description": "## What it does\nChecks for a basedpython `reified` type parameter declared somewhere\nreification cannot happen.\n\n## Why is this bad?\nReification is a property of a *function*: the specialization step\nrebuilds the function's closure so the body sees the type argument as a\nruntime value. A class, a type alias and a `type def` have no such step —\ntheir type parameters are erased — so `reified` there promises a runtime\nvalue that never arrives.\n\n## Example\n\n```by\nclass C[reified T]:  # error: a class type parameter is never reified\n    ...\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-return-type": {
          "title": "detects returned values that can't be assigned to the function's annotated return type",
          "description": "## What it does\n\nDetects returned values that can't be assigned to the function's annotated return type.\n\nNote that the special case of a function with a non-`None` return type and an empty body\nis handled by the separate `empty-body` error code.\n\n## Why is this bad?\n\nReturning an object of a type incompatible with the annotated return type\nis unsound, and will lead to ty inferring incorrect types elsewhere.\n\n## Examples\n\n```python\ndef func() -> int:\n    return \"a\"  # error: [invalid-return-type]\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-route-arguments": {
          "title": "detects a `{% url %}` whose arguments the route cannot take",
          "description": "## What it does\nChecks the arguments a `{% url %}` passes against the route's own pattern.\n\n## Why is this bad?\nDjango raises `NoReverseMatch` when it renders the template, so the page\n500s. A route's pattern names the arguments it takes and the converter\neach of them goes through, so a missing, extra or misnamed argument — and\na literal the converter would reject — is a reversal that cannot match.\n\nOnly a route whose whole pattern is known is checked, and a name several\nroutes share is reported only when none of them accepts the arguments.\n\n## Examples\n```django\n{# path(\"<int:pk>/\", detail, name=\"detail\") #}\n{% url 'detail' %}          {# error: `pk` is missing #}\n{% url 'detail' pk='x' %}   {# error: `pk` goes through `int` #}\n{% url 'detail' pk=1 %}     {# ok #}\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-route-handler": {
          "title": "detects a view that cannot take the arguments its route gives it",
          "description": "## What it does\nChecks that the view a route names can take the arguments the route's\npattern gives it.\n\n## Why is this bad?\nA route pattern names its arguments, and django hands each of them to the\nview as a keyword argument. A view that names them differently, or does\nnot take them at all, raises `TypeError` when the url is requested — a\nfailure nothing reports until the page 500s.\n\nOnly a project whose url tree could be walked in full is checked, since a\nroute's arguments include the ones the patterns it is mounted behind\ncontribute. A view taking `*args` or `**kwargs` accepts anything and is\nnever reported, nor is one reached through a decorator the type checker\ncannot see through. A class-based view is checked through the handler\nmethods it declares itself: what it inherits from django takes `**kwargs`.\n\n## Examples\n```python\npath(\"books/<int:pk>/\", views.detail, name=\"detail\")\n```\n\n```python\ndef detail(request, id): ...     # error: the route names `pk`\ndef detail(request): ...         # error: `pk` has nowhere to go\ndef detail(request, pk): ...     # ok\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-route-parameter-type": {
          "title": "detects a view declaring a type its route's converter does not produce",
          "description": "## What it does\nChecks the type a view declares for a route argument against the type the\nroute's converter produces.\n\n## Why is this bad?\nA path converter parses the url before django calls the view:\n`<int:pk>` hands the view an `int` and `<uuid:key>` a `uuid.UUID`. A view\ndeclaring something else is annotated with a type its argument never has,\nso everything written against the annotation is written against a value\nthat is not there.\n\nUnlike `invalid-route-handler` this does not stop the request: django\ncalls the view and the wrong value arrives silently.\nAn unannotated parameter declares nothing and is never reported,\nand neither is one matched by a regular expression, which goes through no\nconverter at all.\n\n## Examples\n```python\npath(\"books/<int:pk>/\", views.detail, name=\"detail\")\n```\n\n```python\ndef detail(request, pk: str): ...    # warning: the converter gives an `int`\ndef detail(request, pk: int): ...    # ok\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-super-argument": {
          "title": "detects invalid arguments for `super()`",
          "description": "## What it does\n\nDetects `super()` calls where:\n\n- the first argument is not a valid class literal, or\n- the second argument is not an instance or subclass of the first argument.\n\n## Why is this bad?\n\n`super(type, obj)` expects:\n\n- the first argument to be a class,\n- and the second argument to satisfy one of the following:\n    - `isinstance(obj, type)` is `True`\n    - `issubclass(obj, type)` is `True`\n\nViolating this relationship will raise a `TypeError` at runtime.\n\n## Examples\n\n```python\nclass A: ...\n\n\nclass B(A): ...\n\n\nsuper(A, B())  # it's okay! `A` satisfies `isinstance(B(), A)`\n\n# `A()` is not a class\nsuper(A(), B())  # error\n\n# `A()` does not satisfy `isinstance(A(), B)`\nsuper(B, A())  # error\n# `A` does not satisfy `issubclass(A, B)`\nsuper(B, A)  # error\n```\n\n## References\n\n- [Python documentation: super()](https://docs.python.org/3/library/functions.html#super)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-syntax-in-forward-annotation": {
          "title": "detects invalid syntax in forward annotations",
          "description": "## What it does\n\nChecks for string-literal annotations where the string cannot be\nparsed as a Python expression.\n\n## Why is this bad?\n\nType annotations are expected to be Python expressions that\ndescribe the expected type of a variable, parameter, attribute or\n`return` statement.\n\nType annotations are permitted to be string-literal expressions, in\norder to enable forward references to names not yet defined.\nHowever, it must be possible to parse the contents of that string\nliteral as a normal Python expression.\n\n## Example\n\n```python\ndef foo() -> \"instance of C\":  # error\n    return 42\n\n\nclass C: ...\n```\n\nUse instead:\n\n```python\ndef foo() -> \"C\":\n    return C()\n\n\nclass C: ...\n```\n\n## References\n\n- [Typing spec: The meaning of annotations](https://typing.python.org/en/latest/spec/annotations.html#the-meaning-of-annotations)\n- [Typing spec: String annotations](https://typing.python.org/en/latest/spec/annotations.html#string-annotations)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-total-ordering": {
          "title": "detects `@total_ordering` classes without an ordering method",
          "description": "## What it does\n\nChecks for classes decorated with `@functools.total_ordering` that don't\ndefine any ordering method (`__lt__`, `__le__`, `__gt__`, or `__ge__`).\n\n## Why is this bad?\n\nThe `@total_ordering` decorator requires the class to define at least one\nordering method. If none is defined, Python raises a `ValueError` at runtime.\n\n## Example\n\n```python\nfrom functools import total_ordering\n\n\n# no ordering method defined\n@total_ordering  # error\nclass MyClass:\n    def __eq__(self, other: object) -> bool:\n        return True\n```\n\nUse instead:\n\n```python\nfrom functools import total_ordering\n\n\n@total_ordering\nclass MyClass:\n    def __eq__(self, other: object) -> bool:\n        return True\n\n    def __lt__(self, other: \"MyClass\") -> bool:\n        return True\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-type-alias-type": {
          "title": "detects invalid TypeAliasType definitions",
          "description": "## What it does\n\nChecks for the creation of invalid `TypeAliasType`s\n\n## Why is this bad?\n\nThere are several requirements that you must follow when creating a `TypeAliasType`.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\nfrom typing import TypeAliasType, TypeVar\n\n\ndef get_name() -> str:\n    return \"NewAlias\"\n\n\nIntOrStr = TypeAliasType(\"IntOrStr\", int | str)  # okay\n# TypeAliasType name must be a string literal\nNewAlias = TypeAliasType(get_name(), int)  # error\n\nT = TypeVar(\"T\")\nGenericAlias = TypeAliasType(\"GenericAlias\", list[T], type_params=(T,))  # okay\n# TypeAliasType type parameters must be type variables\nInvalidAlias = TypeAliasType(\"InvalidAlias\", list[T], type_params=(list[T],))  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-type-arguments": {
          "title": "detects invalid type arguments in generic specialization",
          "description": "## What it does\n\nChecks for invalid type arguments in explicit type specialization.\n\n## Why is this bad?\n\nProviding the wrong number of type arguments or type arguments that don't\nsatisfy the type variable's bounds or constraints will lead to incorrect\ntype inference and may indicate a misunderstanding of the generic type's\ninterface.\n\n## Examples\n\nUsing legacy type variables:\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\nfrom typing import Generic, TypeVar\n\nT1 = TypeVar(\"T1\", int, str)\nT2 = TypeVar(\"T2\", bound=int)\n\n\nclass Foo1(Generic[T1]): ...\n\n\nclass Foo2(Generic[T2]): ...\n\n\n# bytes does not satisfy T1's constraints\nFoo1[bytes]  # error\n# str does not satisfy T2's bound\nFoo2[str]  # error\n```\n\nUsing PEP 695 type variables:\n\n```python\nclass Foo[T]: ...\n\n\nclass Bar[T, U]: ...\n\n\n# too many arguments\nFoo[int, str]  # error\n# too few arguments\nBar[int]  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-type-checking-constant": {
          "title": "detects invalid `TYPE_CHECKING` constant assignments",
          "description": "## What it does\n\nChecks for a value other than `False` assigned to the `TYPE_CHECKING` variable, or an\nannotation not assignable from `bool`.\n\n## Why is this bad?\n\nThe name `TYPE_CHECKING` is reserved for a flag that can be used to provide conditional\ncode seen only by the type checker, and not at runtime. Normally this flag is imported from\n`typing` or `typing_extensions`, but it can also be defined locally. If defined locally, it\nmust be assigned the value `False` at runtime; the type checker will consider its value to\nbe `True`. If annotated, it must be annotated as a type that can accept `bool` values.\n\n## Examples\n\n```python\nTYPE_CHECKING: str  # error\nTYPE_CHECKING = \"\"  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-type-form": {
          "title": "detects invalid type forms",
          "description": "## What it does\n\nChecks for expressions that are used as [type expressions]\nbut cannot validly be interpreted as such.\n\n## Why is this bad?\n\nSuch expressions cannot be understood by ty.\nIn some cases, they might raise errors at runtime.\n\n## Examples\n\n```python\nfrom typing import Annotated\n\n# Int literals are not allowed in this context in type expressions\na: list[1]  # error\n# `Annotated` expects at least two arguments\nb: Annotated[int]  # error\n```\n\n[type expressions]: https://typing.python.org/en/latest/spec/annotations.html#type-and-annotation-expressions",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-type-guard-definition": {
          "title": "detects malformed type guard functions",
          "description": "## What it does\n\nChecks for type guard functions without\na first non-self-like non-keyword-only non-variadic parameter.\n\n## Why is this bad?\n\nType narrowing functions must accept at least one positional argument\n(non-static methods must accept another in addition to `self`/`cls`).\n\nExtra parameters/arguments are allowed but do not affect narrowing.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.13\"\n```\n\n```python\nfrom typing import TypeIs\n\n\n# no parameter\ndef f() -> TypeIs[int]:  # error\n    return True\n\n\n# no positional arguments allowed\ndef f(*, v: object) -> TypeIs[int]:  # error\n    return True\n\n\n# expected variadic arguments\ndef f(*args: object) -> TypeIs[int]:  # error\n    return True\n\n\nclass C:\n    # only positional argument is `self`\n    def f(self) -> TypeIs[int]:  # error\n        return True\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-type-variable-bound": {
          "title": "detects invalid type variable bounds",
          "description": "## What it does\n\nChecks for [type variables][type variable] whose bounds reference type variables.\n\n## Why is this bad?\n\nThe bound of a type variable must be a concrete type.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\nfrom typing import TypeVar\n\n# error: [invalid-type-variable-bound]\nRecursiveT = TypeVar(\"RecursiveT\", bound=list[\"RecursiveT\"])\nU = TypeVar(\"U\")\n# error: [invalid-type-variable-bound]\nBoundT = TypeVar(\"BoundT\", bound=U)\n\n\ndef f[T: list[T]](): ...  # error: [invalid-type-variable-bound]\ndef g[U, T: U](): ...  # error: [invalid-type-variable-bound]\n```\n\n[type variable]: https://docs.python.org/3/library/typing.html#typing.TypeVar",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-type-variable-constraints": {
          "title": "detects invalid type variable constraints",
          "description": "## What it does\n\nChecks for constrained [type variables] with only one constraint,\nor that those constraints reference type variables.\n\n## Why is this bad?\n\nA constrained type variable must have at least two constraints.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\nfrom typing import TypeVar\n\nI = TypeVar(\"I\", bound=int)\n# constraint references `I`\nS = TypeVar(\"S\", list[I], int)  # error\n\n\n# a constrained type variable needs at least two constraints\ndef f[T: (int,)](): ...  # error\n```\n\nUse instead:\n\n```python\nfrom typing import TypeVar\n\nU = TypeVar(\"U\", str, int)  # valid constrained TypeVar\n\n# or\n\nT = TypeVar(\"T\", bound=str)  # valid bound TypeVar\n\nV = TypeVar(\"V\", list[int], int)  # valid constrained Type\n```\n\n[type variables]: https://docs.python.org/3/library/typing.html#typing.TypeVar",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-type-variable-default": {
          "title": "detects invalid type variable defaults",
          "description": "## What it does\n\nChecks for [type variables] whose default type is not compatible with\nthe type variable's bound or constraints.\n\n## Why is this bad?\n\nIf a type variable has a bound, the default must be assignable to that\nbound (see: [bound rules]). If a type variable has constraints, the default\nmust be one of the constraints (see: [constraint rules]).\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.13\"\n```\n\n```python\nfrom typing import TypeVar\n\nT = TypeVar(\"T\", bound=str, default=int)  # error: [invalid-type-variable-default]\nU = TypeVar(\"U\", int, str, default=bytes)  # error: [invalid-type-variable-default]\n```\n\n[bound rules]: https://typing.python.org/en/latest/spec/generics.html#bound-rules\n[constraint rules]: https://typing.python.org/en/latest/spec/generics.html#constraint-rules\n[type variables]: https://docs.python.org/3/library/typing.html#typing.TypeVar",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-typed-dict-field": {
          "title": "detects invalid `TypedDict` field declarations",
          "description": "## What it does\n\nDetects invalid `TypedDict` field declarations.\n\n## Why is this bad?\n\n`TypedDict` subclasses cannot redefine inherited fields incompatibly. Doing so breaks the\nsubtype guarantees that `TypedDict` inheritance is meant to preserve.\n\n## Example\n\n```python\nfrom typing import TypedDict\n\n\nclass Base(TypedDict):\n    x: int\n\n\nclass Child(Base):\n    x: str  # error: [invalid-typed-dict-field]\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-typed-dict-header": {
          "title": "detects invalid statements in `TypedDict` class headers",
          "description": "## What it does\n\nDetects errors in `TypedDict` class headers, such as unexpected arguments\nor invalid base classes.\n\n## Why is this bad?\n\nThe typing spec states that `TypedDict`s are not permitted to have\ncustom metaclasses. Using `**` unpacking in a `TypedDict` header\nis also prohibited by ty, as it means that ty cannot statically determine\nwhether keys in the `TypedDict` are intended to be required or optional.\n\n## Example\n\n```python\nfrom typing import TypedDict\n\n\nclass Meta(type): ...\n\n\nclass Foo(TypedDict, metaclass=Meta):  # error: [invalid-typed-dict-header]\n    ...\n\n\ndef f(options: dict[str, object]):\n    class Bar(TypedDict, **options):  # error: [invalid-typed-dict-header]\n        ...\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-typed-dict-statement": {
          "title": "detects invalid statements in `TypedDict` class bodies",
          "description": "## What it does\n\nDetects statements other than annotated declarations in `TypedDict` class bodies.\n\n## Why is this bad?\n\n`TypedDict` class bodies aren't allowed to contain any other types of statements. For\nexample, method definitions and field values aren't allowed. None of these will be\navailable on \"instances of the `TypedDict`\" at runtime (as `dict` is the runtime class of\nall \"`TypedDict` instances\").\n\n## Example\n\n```python\nfrom typing import TypedDict\n\n\nclass Foo(TypedDict):\n    def bar(self):  # error: [invalid-typed-dict-statement]\n        pass\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-variance-declaration": {
          "title": "detects a variance keyword the program does not honour",
          "description": "## What it does\nChecks for a basedpython variance keyword (`in`, `out`, `in out`) that\nthe program does not honour: one on a type parameter that never\nspecializes, and one on a type alias that names a variance its expansion\ndoes not have.\n\n## Why is this bad?\nVariance says how two *specializations* relate. A function's type\nparameter is solved afresh at each call and never specializes, and a\n`type def` is erased before anything could observe one — so the keyword\ndecides nothing in either position. Reported rather than dropped, because\na keyword nothing checks reads as a promise that something does.\n\nA generic class and a generic type alias both specialize and both keep\nthe keyword. An alias has no variance of its own — it relates exactly as\nthe type it expands to does — so its keyword is a claim about that\nexpansion, and a claim the expansion contradicts is reported too. A\nclass's own keyword is checked against its members by\n`invalid-generic-class`.\n\n## Example\n\n```by\ndef f[out T](t: T) -> None: ...  # error: a function's `T` has no variance\n\ntype Alias[out T] = list[T]      # error: `list` is invariant\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-yield": {
          "title": "detects yield expressions where the \"yield\" or \"send\" type is incompatible with the annotated return type",
          "description": "## What it does\n\nDetects `yield` and `yield from` expressions where the \"yield\" or \"send\" type\nis incompatible with the generator function's annotated return type.\n\n## Why is this bad?\n\nYielding a value of a type that doesn't match the generator's declared yield type,\nor using `yield from` with a sub-iterator whose yield or send type is incompatible,\nis a type error that may cause downstream consumers of the generator to receive\nvalues of an unexpected type.\n\n## Examples\n\n```python\nfrom typing import Iterator\n\n\ndef gen() -> Iterator[int]:\n    yield \"not an int\"  # error: [invalid-yield]\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "isinstance-against-protocol": {
          "title": "reports invalid runtime checks against protocol classes",
          "description": "## What it does\n\nReports invalid runtime checks against `Protocol` classes.\nThis includes explicit calls `isinstance()`/`issubclass()` against\nnon-runtime-checkable protocols, `issubclass()` calls against protocols\nthat have non-method members, and implicit `isinstance()` checks against\nnon-runtime-checkable protocols via pattern matching.\n\n## Why is this bad?\n\nThese calls (implicit or explicit) raise `TypeError` at runtime.\n\n## Examples\n\n```python\nfrom typing_extensions import Protocol, runtime_checkable\n\n\nclass HasX(Protocol):\n    x: int\n\n\n@runtime_checkable\nclass HasY(Protocol):\n    y: int\n\n\ndef f(arg: object, arg2: type):\n    # not runtime-checkable\n    isinstance(arg, HasX)  # error: [isinstance-against-protocol]\n    # not runtime-checkable\n    issubclass(arg2, HasX)  # error: [isinstance-against-protocol]\n\n\ndef g(arg: object):\n    match arg:\n        # not runtime-checkable\n        case HasX():  # error: [isinstance-against-protocol]\n            pass\n\n\ndef h(arg2: type):\n    isinstance(arg2, HasY)  # fine (runtime-checkable)\n\n    # `HasY` is runtime-checkable, but has non-method members,\n    # so it still can't be used in `issubclass` checks)\n    issubclass(arg2, HasY)  # error: [isinstance-against-protocol]\n```\n\n## References\n\n- [Typing documentation: `@runtime_checkable`](https://docs.python.org/3/library/typing.html#typing.runtime_checkable)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "isinstance-against-typed-dict": {
          "title": "reports runtime checks against `TypedDict` classes",
          "description": "## What it does\n\nReports runtime checks against `TypedDict` classes.\nThis includes explicit calls to `isinstance()`/`issubclass()` and implicit\nchecks performed by `match` class patterns.\n\n## Why is this bad?\n\nUsing a `TypedDict` class in these contexts raises `TypeError` at runtime.\n\n## Examples\n\n```python\nfrom typing_extensions import TypedDict\n\n\nclass Movie(TypedDict):\n    name: str\n    director: str\n\n\ndef f(arg: object, arg2: type):\n    isinstance(arg, Movie)  # error: [isinstance-against-typed-dict]\n    issubclass(arg2, Movie)  # error: [isinstance-against-typed-dict]\n\n\ndef g(arg: object):\n    match arg:\n        case Movie():  # error: [isinstance-against-typed-dict]\n            pass\n```\n\n## References\n\n- [Typing specification: `TypedDict`](https://typing.python.org/en/latest/spec/typeddict.html)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "iteration-over-character": {
          "title": "detects iteration over a single-character string (`Character`)",
          "description": "## What it does\nChecks for iteration over a basedpython `Character` (a single-character string).\n\n## Why is this bad?\nA `Character` always has a length of exactly 1, so iterating over it yields a\nsingle element — the `Character` itself. Code that does this almost always\nmeant to iterate over the enclosing string instead, or believed the value\nwas a longer string.\n\n## Example\n\n```by\ndef f(s: str):\n    first = s[0]\n    for c in first:  # warning: iterating over a `Character`\n        ...\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "mismatched-type-name": {
          "title": "detects functional typing definitions whose declared name does not match the assigned variable",
          "description": "## What it does\n\nChecks for functional typing definitions whose declared name does not match\nthe variable they are assigned to.\n\n## Why is this bad?\n\nConstructors like `TypeVar`, `ParamSpec`, `NewType`, `NamedTuple`,\n`TypedDict`, and `TypeAliasType` all take a name argument that is\nnormally expected to match the assigned variable. A mismatch is usually a\ntypo and makes later diagnostics harder to understand.\n\n## Default level\n\nThis rule is a warning by default because ty can usually recover and\ncontinue understanding the resulting type.\n\n## Examples\n\n```python\nfrom typing import NewType, ParamSpec, TypeVar\nfrom typing_extensions import TypedDict\n\nT = TypeVar(\"U\")  # error: [mismatched-type-name]\nP = ParamSpec(\"Q\")  # error: [mismatched-type-name]\nUserId = NewType(\"Id\", int)  # error: [mismatched-type-name]\nMovie = TypedDict(\"Film\", {\"title\": str})  # error: [mismatched-type-name]\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "misplaced-dependency": {
          "title": "detects shipped code importing a dependency group",
          "description": "## What it does\n\nChecks for imports, from code the project ships, of a distribution declared\nonly in a dependency group.\n\n## Why is this bad?\n\nA dependency group is for the people working on the project, not the people\ninstalling it. Nothing installs one alongside the project, so an import of\none from shipped code raises `ModuleNotFoundError` for every user — and\nnever for the person who wrote it, whose environment has the whole group.\n\n## Examples\n\n```toml\n[project]\nname = \"my-lib\"\ndependencies = [\"requests\"]\n\n[dependency-groups]\ndev = [\"pytest\"]\n```\n\n```python\n# src/my_lib/fixtures.py\nimport pytest  # error: [misplaced-dependency]\n```\n\nThe same import from `tests/` is fine: tests are not shipped.\n\n## Configuration\n\nWhich files ship is derived from the name the project gives itself — a\nproject named `my-lib` ships the module `my_lib` — and can be stated\noutright when that is not right:\n\n```toml\n[tool.ty.analysis]\nshipped-modules = [\"my_lib\", \"my_lib_plugins\"]\n```\n\nA file's groups can also be set directly, which overrides the derivation:\n\n```toml\n[[tool.ty.overrides]]\ninclude = [\"src/my_lib/_dev_only/**\"]\n\n[tool.ty.overrides.analysis]\ndependency-groups = [\"*\"]\n```\n\nA project that does not name itself ships nothing this check can identify,\nand nothing is reported.",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "missing-argument": {
          "title": "detects missing required arguments in a call",
          "description": "## What it does\n\nChecks for missing required arguments in a call.\n\n## Why is this bad?\n\nFailing to provide a required argument will raise a `TypeError` at runtime.\n\n## Examples\n\n```python\ndef func(x: int): ...\n\n\n# TypeError: func() missing 1 required positional argument: 'x'\nfunc()  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "missing-context-argument": {
          "title": "detects calls whose `context` parameter has no matching context value",
          "description": "## What it does\nChecks for calls that leave a basedpython `context` parameter unfilled:\nno explicit argument matches it and no `context` declaration in scope\nhas a type assignable to it.\n\n## Why is this bad?\nA `context` parameter has no default — the call raises `TypeError` at\nruntime unless something supplies the argument.\n\n## Examples\n```python\ndef f(a: int, context b: str): ...\n\nf(1)                  # error: no context value in scope\ncontext s = \"hello\"\nf(1)                  # ok — `s` is passed implicitly\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "missing-framework-stubs": {
          "title": "detects framework imports whose external stubs package is not installed",
          "description": "## What it does\nChecks for imports of frameworks that ship no inline type annotations\nwhen their external PEP 561 stubs package is not installed.\n\n## Why is this bad?\nWithout the stubs package the framework's types resolve from its untyped\nruntime source, so most framework-aware checking silently degrades to\n`Unknown`. Installing the stubs package restores precise types.\n\n## Example\n\n```py\nfrom django.db import models  # warning: install `django-stubs` for precise types\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "missing-override-decorator": {
          "title": "detects methods that override a superclass member without an `@override` annotation",
          "description": "## What it does\n\nChecks for methods that override a method or attribute in a superclass but are not decorated with `@override`.\n\nThis rule is disabled by default. Enable it to opt in to strict `@override` enforcement for a project.\n\n## Exemptions\n\nOverriding `__init__`, `__new__`, `__init_subclass__`, or `__post_init__` does not require\n`@override`, even if the method is explicitly declared by a superclass.\n\n## Why is this bad?\n\nWithout an `@override` annotation, refactors can silently change whether a method is an override.\nRequiring `@override` on every override lets ty report when an intended override stops overriding\nanything, and when a method unexpectedly starts overriding a superclass member.\n\n## Example\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\nfrom typing import override\n\n\nclass Parent:\n    def method(self) -> int:\n        return 1\n\n\nclass Child(Parent):\n    # when the rule is enabled\n    def method(self) -> int:  # error\n        return 2\n\n\nclass ExplicitChild(Parent):\n    @override\n    def method(self) -> int:  # fine\n        return 2\n```",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "missing-type-argument": {
          "title": "detects generic types used without explicit type parameters in type expressions",
          "description": "## What it does\n\nChecks for generic types used without type parameters in type expressions.\n\n## Why is this bad?\n\nUsing a generic type without specifying its type parameters results in the\ntype parameters being implicitly filled with `Unknown`, reducing the\nprecision of type checking. Explicit type parameters make the intended types\nclear and enable the type checker to catch more errors.\n\n## Examples\n\n```python\nimport re\n\n\ndef handle(m: re.Match) -> str:  # error: [missing-type-argument]\n    return m.string\n\n\n# Use explicit type parameters instead:\ndef handle(m: re.Match[str]) -> str:\n    return m.string\n```",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "missing-typed-dict-key": {
          "title": "detects missing required keys in `TypedDict` constructors",
          "description": "## What it does\n\nDetects missing required keys in `TypedDict` constructor calls.\n\n## Why is this bad?\n\n`TypedDict` requires all non-optional keys to be provided during construction.\nMissing items can lead to a `KeyError` at runtime.\n\n## Example\n\n```python\nfrom typing import TypedDict\n\n\nclass Person(TypedDict):\n    name: str\n    age: int\n\n\n# missing required key 'age'\nalice: Person = {\"name\": \"Alice\"}  # error\n\nalice[\"age\"]  # KeyError\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "narrowing-guard-as-value": {
          "title": "detects an assertion guard whose result is used as a value",
          "description": "## What it does\nChecks for a call to a basedpython assertion guard whose result is used as a value.\n\n## Why is this bad?\nAn assertion guard narrows once it *returns*, so it is written as a statement:\n`check(x)`. Its value is `None` — it raises when the assertion doesn't hold — so\ntesting that value (`if check(x):`) or binding it (`ok = check(x)`) never gets the\nnarrowing, and the test is always false.\n\n## Example\n\n```by\ndef check(x: int | None) -> asserts x:\n    if x is None:\n        raise ValueError\n\ndef f(a: int | None):\n    if check(a):  # error: the guard narrows as a statement, not as a test\n        ...\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "no-matching-overload": {
          "title": "detects calls that do not match any overload",
          "description": "## What it does\n\nChecks for calls to an overloaded function that do not match any of the overloads.\n\n## Why is this bad?\n\nFailing to provide the correct arguments to one of the overloads will raise a `TypeError`\nat runtime.\n\n## Examples\n\n```python\nfrom typing import overload\n\n\n@overload\ndef func(x: int): ...\n@overload\ndef func(x: bool): ...\ndef func(x: int | bool): ...\n\n\nfunc(\"string\")  # error: [no-matching-overload]\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "non-callable-init-subclass": {
          "title": "detects class definitions that will fail due to non-callable `__init_subclass__`",
          "description": "## What it does\n\nChecks for class definitions that will fail due to non-callable `__init_subclass__`\nmethods.\n\n## Why is this bad?\n\nIf a class defines a non-callable `__init_subclass__` method/attribute, any attempt\nto subclass that class will raise a `TypeError` at runtime.\n\n## Examples\n\n```python\nclass Super:\n    __init_subclass__ = None\n\n\nclass Sub(Super): ...  # error: [non-callable-init-subclass]\n```\n\n## References\n\n- [Python data model: Customizing class creation](https://docs.python.org/3/reference/datamodel.html#customizing-class-creation)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "non-exhaustive-statement-expression": {
          "title": "detects a statement expression that can complete without a value",
          "description": "## What it does\nChecks for a basedpython statement expression that can complete without\nproducing a value.\n\n## Why is this bad?\nA statement expression stands where a value is expected. If some path\nthrough it reaches the end of the statement without evaluating a tail\nexpression or a `break <value>`, there is no value to stand in.\n\n## Examples\n```by\ndef f(x: int | str) -> int:\n    # error: no value when `x` is a `str`\n    return match x:\n        case int():\n            1\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "non-overlapping-cast": {
          "title": "detects casts between non-overlapping types",
          "description": "## What it does\nChecks for a `cast` whose value type is disjoint from the target type,\nso no value could ever belong to both.\n\n## Why is this bad?\nA cast between non-overlapping types can never succeed: `cast!` always\nraises at runtime, and `cast?` always yields `None`. The cast is almost\ncertainly a mistake.\n\n## Examples\n```by\ndef f(a: object):\n    a cast! int      # ok — `object` overlaps `int`\n    \"\" cast! int     # warning: `str` and `int` are disjoint\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "non-overlapping-type-test": {
          "title": "detects `is` type tests between non-overlapping types",
          "description": "## What it does\nChecks for an `is` / `is not` type test whose tested value is disjoint\nfrom the type it is tested against, so no value could ever belong to both.\n\n## Why is this bad?\nThe test has a constant answer: `is` is always `False` and `is not` is\nalways `True`. Either the branch it guards is dead code, or the wrong type\nwas named.\n\nThe value's *narrowed* type is what is tested, which is often sharper\nthan its declaration: a constructor call is a `final Shape`, a value whose\nruntime class is exactly `Shape`'s.\n\n## Examples\n```by\nclass Shape\n\ndef f(x: None):\n    if x is int:          # warning: `None` and `int` are disjoint\n        ...\n    s = Shape()\n    if s is str:          # warning: `final Shape` and `str` are disjoint\n        ...\n\ndef g(o: object, shape: Shape):\n    if o is int:          # ok — `object` overlaps `int`\n        ...\n    if shape is str:      # ok — a `Shape` subclass could inherit `str`\n        ...\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "not-iterable": {
          "title": "detects iteration over an object that is not iterable",
          "description": "## What it does\n\nChecks for objects that are not iterable but are used in a context that requires them to be.\n\n## Why is this bad?\n\nIterating over an object that is not iterable will raise a `TypeError` at runtime.\n\n## Examples\n\n```python\n# TypeError: 'int' object is not iterable\nfor i in 34:  # error\n    pass\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "not-subscriptable": {
          "title": "detects subscripting objects that do not support subscripting",
          "description": "## What it does\n\nChecks for subscripting objects that do not support subscripting.\n\n## Why is this bad?\n\nSubscripting an object that does not support it will raise a `TypeError` at runtime.\n\n## Examples\n\n```python\n# TypeError: 'int' object is not subscriptable\n4[1]  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "once-called-twice": {
          "title": "detects a `once` callback that may be called more than once",
          "description": "## What it does\nChecks for a basedpython `once` callback parameter that a function body may\ncall more than once — two unconditional calls, or a call inside a loop.\n\n## Why is this bad?\nA `once` callback must be called exactly once. Calling it again — or in a\nloop that may run more than once — breaks that contract.\n\n## Example\n\n```by\ndef f(once done: () -> None):\n    for _ in range(3):\n        done()  # error: `done` may be called more than once\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "once-not-called": {
          "title": "detects a `once` callback that is never called",
          "description": "## What it does\nChecks for a basedpython `once` callback parameter that the function body\nnever calls.\n\n## Why is this bad?\nA `once` callback must be called exactly once. A body that never mentions\nit has forgotten to call it — a common completion-handler bug.\n\n## Example\n\n```by\ndef f(once done: () -> None):\n    do_work()  # error: `done` is never called\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "optional-object-conversion": {
          "title": "detects an optional value implicitly widened to `object`",
          "description": "## What it does\nChecks for an optional value passed where `object` is expected, silently\ndiscarding a layer of optionality.\n\n## Why is this bad?\n`object` swallows both the present value and `None`, so consuming an\noptional as `object` loses the information that the value could be\nabsent. It is almost always unintended: either the value should be\nunwrapped first with `!`, or the widening should be made explicit with\n`cast object`.\n\nAssigning an optional to a declared `object` variable is *not* flagged —\nthe target narrows back to the optional type, so nothing is lost there.\nThe diagnostic surfaces at each use of the value as `object` instead.\n\n## Examples\n```by\ndef sink(o: object): ...\n\ndef f(x: int?):\n    sink(x)             # warning: `int | None` widened to `object`\n    sink(x!)            # ok — unwrapped first\n    sink(x cast object) # ok — explicit\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "overlapping-condition": {
          "title": "detects a condition that several members of the tested type answer the same way",
          "description": "## What it does\nChecks for a truthiness test whose selected branch holds a value that is\nalways there alongside one that is only sometimes there.\n\n## Why is this bad?\nA condition collapses a value to a single bit, so two members that answer\nthe test the same way become indistinguishable inside the branch. The case\nthat bites is a sentinel meeting the falsy corner of a value that normally\nbelongs to the other branch — `None` meeting `\"\"` in `if not name:`.\n\nOnly the branch the condition *selects* is analyzed: `if a` looks at the\ntruthy members, `if not a` at the falsy ones. A boolean operator is one\ncondition per operand rather than one over its value, since each operand's\ntruthiness is tested on its own.\n\nTwo members that are *each* only partly in the branch are not reported:\n`if x:` over a `str | bytes` conflates nothing the union did not already\nconflate. Neither are members of one class, or of two classes where one\nderives the other, which a condition was never going to tell apart:\n`Literal[1] | Literal[2]` and `list[A] | list[B]` are each one kind of\nvalue.\n\n## Examples\n```python\ndef f(a: bool | None):\n    if a:      # ok — only `True` is truthy\n        ...\n    if not a:  # warning: `False` and `None` are both falsy\n        ...\n\ndef g(name: str | None):\n    if not name:  # warning: `\"\"` and `None` are both falsy\n        ...\n    if name is None:  # ok — the members are told apart\n        ...\n```\n\n## Options\n- `analysis.overlapping-condition-exempt-types`\n- `analysis.overlapping-condition-assume-truthy-instances`",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "override-of-final-method": {
          "title": "detects overrides of final methods",
          "description": "## What it does\n\nChecks for methods on subclasses that override superclass methods decorated with `@final`.\n\n## Why is this bad?\n\nDecorating a method with `@final` declares to the type checker that it should not be\noverridden on any subclass.\n\n## Example\n\n```python\nfrom typing import final\n\n\nclass A:\n    @final\n    def foo(self): ...\n\n\nclass B(A):\n    def foo(self): ...  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "override-of-final-variable": {
          "title": "detects overrides of Final class variables",
          "description": "## What it does\n\nChecks for class variables on subclasses that override a superclass variable\nthat has been declared as `Final`.\n\n## Why is this bad?\n\nDeclaring a variable as `Final` indicates to the type checker that it should not be\noverridden on any subclass.\n\n## Example\n\n```python\nfrom typing import Final\n\n\nclass A:\n    X: Final[int] = 1\n\n\nclass B(A):\n    X = 2  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "override-raise": {
          "title": "detects an override that raises more than the method it overrides",
          "description": "## What it does\nChecks for a method that can raise an exception the method it overrides\ncannot.\n\n## Why is this bad?\nA call is checked against the type it can see. When a base-class method\ncannot raise, its callers are told nothing escapes — but a subclass\nsubstituted for the base can still raise from that call, and no caller\non the base type has any reason to handle it.\n\nThis is off by default: it is a strictness option, and honouring it means\na base method's exception set bounds every override of it.\n\n## Example\n\n```by\nclass A:\n    def foo(self): ...\n\nclass B(A):\n    override def foo(self):\n        raise TypeError  # error: `A.foo` cannot raise\n\ndef get() -> A:\n    return B()\n\ndef main():\n    get().foo()  # nothing here says this can raise\n```",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "parameter-already-assigned": {
          "title": "detects multiple arguments for the same parameter",
          "description": "## What it does\n\nChecks for calls which provide more than one argument for a single parameter.\n\n## Why is this bad?\n\nProviding multiple values for a single parameter will raise a `TypeError` at runtime.\n\n## Examples\n\n```python\ndef f(x: int) -> int:\n    return x\n\n\nf(1, x=2)  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "positional-only-parameter-as-kwarg": {
          "title": "detects positional-only parameters passed as keyword arguments",
          "description": "## What it does\n\nChecks for keyword arguments in calls that match positional-only parameters of the callable.\n\n## Why is this bad?\n\nProviding a positional-only parameter as a keyword argument will raise `TypeError` at runtime.\n\n## Example\n\n```python\ndef f(x: int, /) -> int:\n    return x\n\n\nf(x=1)  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "possibly-missing-attribute": {
          "title": "detects references to possibly missing attributes",
          "description": "## What it does\n\nChecks for possibly missing attributes.\n\n## Why is this bad?\n\nAttempting to access a missing attribute will raise an `AttributeError` at runtime.\n\n## Rule status\n\nThis rule is currently disabled by default because of the number of\nfalse positives it can produce.\n\n## Examples\n\n```python\nclass A:\n    if __name__ == \"__main__\":\n        c = 0\n\n\n# AttributeError: type object 'A' has no attribute 'c'\nA.c  # error\n```",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "possibly-missing-implicit-call": {
          "title": "detects implicit calls to possibly missing methods",
          "description": "## What it does\n\nChecks for implicit calls to possibly missing methods.\n\n## Why is this bad?\n\nExpressions such as `x[y]` and `x * y` call methods\nunder the hood (`__getitem__` and `__mul__` respectively).\nCalling a missing method will raise an `AttributeError` at runtime.\n\n## Examples\n\n```python\nimport datetime\n\n\nclass A:\n    if datetime.date.today().weekday() != 6:\n\n        def __getitem__(self, v): ...\n\n\n# TypeError: 'A' object is not subscriptable\nA()[0]  # error\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "possibly-missing-import": {
          "title": "detects possibly missing imports",
          "description": "## What it does\n\nChecks for imports of symbols that may be missing.\n\n## Why is this bad?\n\nImporting a missing module or name will raise a `ModuleNotFoundError`\nor `ImportError` at runtime.\n\n## Rule status\n\nThis rule is currently disabled by default because of the number of\nfalse positives it can produce.\n\n## Examples\n\n`module.py`:\n\n```python\nimport datetime\n\nif datetime.date.today().weekday() != 6:\n    a = 1\n```\n\n`main.py`:\n\n```python\n# ImportError: cannot import name 'a' from 'module'\nfrom module import a  # error\n```",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "possibly-missing-submodule": {
          "title": "detects accesses of submodules that may not be available as attributes on their parent module",
          "description": "## What it does\n\nChecks for accesses of submodules that might not've been imported.\n\n## Why is this bad?\n\nWhen module `a` has a submodule `b`, `import a` isn't generally enough to let you access\n`a.b.` You either need to explicitly `import a.b`, or else you need the `__init__.py` file\nof `a` to include `from . import b`. Without one of those, `a.b` is an `AttributeError`.\n\n## Examples\n\n```python\nimport html\n\n# AttributeError: module 'html' has no attribute 'parser'\nhtml.parser  # error\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "possibly-unresolved-reference": {
          "title": "detects references to possibly undefined names",
          "description": "## What it does\n\nChecks for references to names that are possibly not defined.\n\n## Why is this bad?\n\nUsing an undefined variable will raise a `NameError` at runtime.\n\n## Rule status\n\nThis rule is currently disabled by default because of the number of\nfalse positives it can produce.\n\n## Example\n\n```python\nfor i in range(int(input())):\n    x = i\n\n# NameError: name 'x' is not defined\nprint(x)  # error\n```",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "private-import": {
          "title": "detects imports of another module's `private` symbols",
          "description": "## What it does\nChecks for imports of a symbol another module declared `private`.\n\n## Why is this bad?\nA `private` declaration is part of its module's implementation, not its\ninterface. It is renamed with a leading underscore by the lowering, so an\nimporting module is reaching past a boundary the author drew explicitly,\nand the symbol may be renamed or removed without notice.\n\n## Example\n\n```by\n# helpers.by\nprivate type Key = str | int\n\n# main.by\nfrom helpers import Key  # error: `Key` is private to `helpers`\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "pydantic-discarded-extra-argument": {
          "title": "detects extra constructor arguments that Pydantic silently discards",
          "description": "## What it does\n\nChecks for extra keyword arguments that Pydantic silently discards when a model uses\n`extra=\"ignore\"`, either implicitly or explicitly.\n\n## Why is this bad?\n\nA discarded argument has no effect on the constructed model, but it may indicate a misspelled field\nname or an incorrect assumption about the model's schema.\n\n## Example\n\n```python {data-mdtest=\"ignore\"}\nfrom pydantic import BaseModel\n\n\nclass User(BaseModel):\n    name: str\n    admin: bool = False\n\n\nuser = User(name=\"Alice\", admni=True)  # error: [pydantic-discarded-extra-argument]\n```\n\nIf the field name has been misspelled, fix the typo. Otherwise, consider removing the extra argument,\nor explicitly configure the model with `extra=\"allow\"`.",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "raw-string-type-annotation": {
          "title": "detects raw strings in type annotation positions",
          "description": "## What it does\n\nChecks for raw-strings in type annotation positions.\n\n## Why is this bad?\n\nStatic analysis tools like ty can't analyze type annotations that use raw-string notation.\n\n## Examples\n\n```python\ndef test() -> r\"int\":  # error\n    return 1\n```\n\nUse instead:\n\n```python\ndef test() -> \"int\":\n    return 1\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "redundant-boolean-comparison": {
          "title": "detects a comparison of a `bool` against `True` or `False`",
          "description": "## What it does\nChecks for a comparison of a `bool` against `True` or `False`.\n\n## Why is this bad?\nThe operand is already the value the comparison produces, so the\ncomparison only adds noise. Testing the operand — or its negation —\nsays the same thing.\n\nAn operand that is *not* a `bool` is left alone: `x == True` where\n`x: bool | None` really does tell `True` apart from `False` and `None`,\nand `x == True` where `x: int` is a value comparison. A chained comparison\n(`a == True == b`) is left alone too: it is two comparisons over one\nliteral, and neither the operand nor its negation replaces the chain.\n\n## Examples\n```python\ndef f(a: bool):\n    if a == True:   # warning: redundant comparison\n        ...\n    if a is False:  # warning: redundant comparison\n        ...\n    if a:           # ok\n        ...\n\ndef g(a: bool | None):\n    if a == True:  # ok — tells `True` apart from `False` and `None`\n        ...\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "redundant-cast": {
          "title": "detects redundant `cast` calls",
          "description": "## What it does\n\nDetects redundant `cast` calls where the value already has the target type.\n\n## Why is this bad?\n\nThese casts have no effect and can be removed.\n\n## Example\n\n```python\nfrom typing import cast\n\n\ndef f() -> int:\n    return 10\n\n\n# Redundant\ncast(int, f())  # error\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "redundant-condition": {
          "title": "detects a condition whose outcome is fixed by the tested type",
          "description": "## What it does\nChecks for a condition whose outcome is fixed by the tested type, so the\nbranch is not conditional at all.\n\n## Why is this bad?\nOne of the two branches is dead. Either the annotation is wider than the\nauthor believed, or the test is left over from an earlier version of the\ncode.\n\nOnly a value *read* is reported — a name, an attribute, a subscript. A\ncomparison or a call computes a fresh value, and ty folding that one is the\nstatically-known-branch machinery doing its job: `elif isinstance(x, B):`\nclosing an exhaustive chain is deliberate, and so is `while True:`, which\nis a literal rather than a read.\n\nA read whose constant outcome comes from the checker's model of the build\nenvironment (`TYPE_CHECKING`, `sys.version_info`, `sys.platform`, `os.name`)\nrather than from the program's own types is not reported either — those are\n*artificially* constant, and selecting a branch at check time is exactly\nwhat they are for.\n\n## Examples\n```python\nimport sys\nfrom typing import TYPE_CHECKING, Literal\n\ndef f(a: Literal[True], x: int):\n    if a:  # warning: always true\n        ...\n    if x is not None:  # ok — a comparison, not a value read\n        ...\n\nwhile True:  # ok — a literal, not a value read\n    ...\n\nif TYPE_CHECKING:  # ok — artificially constant\n    ...\nif sys.version_info >= (3, 12):  # ok — artificially constant\n    ...\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "redundant-final-classvar": {
          "title": "detects redundant combinations of `ClassVar` and `Final`",
          "description": "## What it does\n\nChecks for redundant combinations of the `ClassVar` and `Final` type qualifiers.\n\n## Why is this bad?\n\nAn attribute that is marked `Final` in a class body is implicitly a class variable.\nMarking it as `ClassVar` is therefore redundant.\n\nNote that this diagnostic is not emitted for dataclass fields or protocol members,\nwhere `ClassVar[Final[int]]` has a distinct meaning from `Final[int]`.\n\n## Examples\n\n```python\nfrom typing import ClassVar, Final\n\n\nclass C:\n    # redundant\n    x: ClassVar[Final[int]] = 1  # error\n    # redundant\n    y: Final[ClassVar[int]] = 1  # error\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "redundant-return-annotation": {
          "title": "detects an explicit `-> None` that is already the default",
          "description": "## What it does\nChecks for an explicit `-> None` return annotation that leaves the function's\ntype exactly where deleting it would.\n\n## Why is this bad?\nOnce unannotated signatures are recovered, `None` is what a `def` already\nmeans when it says nothing about its return type, so writing it out adds a\nword without adding information. Leaving it off is also how the type reads\nback: `reveal_type` of such a function shows `def f()`, not `def f() -> None`.\n\nNothing is reported when neither option below is on — there `-> None` is\nload-bearing, since removing it makes the function return `Unknown`.\n\nWhere the type would come from instead does not matter, only whether it is\nstill `None`. A `def` that would return something else keeps its annotation: a\nbody that always raises returns `Never`, a generator returns a generator, and\nan override or an overload implementation returns whatever it inherits.\n\n## Examples\n```python\ndef f() -> None:  # warning: redundant `-> None`\n    print(\"hi\")\n\ndef g():  # ok — says the same thing\n    print(\"hi\")\n\ndef h() -> None:  # ok — the body returns `Never`, not `None`\n    raise ValueError\n\nclass Base:\n    def m(self) -> int | None: ...\n\nclass Sub(Base):\n    def m(self) -> None:  # ok — without it, `m` would return `int | None`\n        print(\"hi\")\n```\n\n## Options\n- `analysis.infer-unannotated-signatures`\n- `analysis.sound-types`",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "refutable-destructuring": {
          "title": "detects a destructuring binder whose pattern may not match, with nothing to handle the failure",
          "description": "## What it does\n\nChecks for a basedpython destructuring binder whose pattern may not match the\nvalue it destructures, with nothing to handle the failure.\n\n## Why is this bad?\n\nA destructuring binder — a `let` statement, a `for` target, a `with` item, a\nparameter — binds its captures unconditionally. A pattern that does not match\nleaves them unbound, which is a `NameError` at the first use.\n\nA `let` statement can handle the failure with an `else` block, but only if the\nblock diverges: control that falls out of it reaches the same unbound captures.\n\n## Examples\n\n```by\ndef f(value: int | str) -> int:\n    let int(n) := value  # error: [refutable-destructuring]\n    return n\n\ndef g(value: int | str) -> int:\n    let int(n) := value else:  # error: [refutable-destructuring]\n        print(\"not an int\")\n    return n  # error: [possibly-unresolved-reference]\n```\n\nUse a pattern that matches every value of the type, or an `else` block that\ndiverges:\n\n```by\ndef f(value: int | str) -> int:\n    let int(n) := value else:\n        return 0\n    return n\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "refutable-unpacking": {
          "title": "detects an unpacking whose value is not known to have the number of elements the targets require",
          "description": "## What it does\n\nChecks for an unpacking assignment whose value is not known to have the number\nof elements the targets require.\n\n## Why is this bad?\n\n`a, b = value` binds both names unconditionally, but the unpacking only succeeds\nif `value` yields exactly two elements. A `tuple[int, ...]`, a `list[int]`, or\nany other iterable whose length is not part of its type satisfies the annotation\nat every length, so nothing rules out a `ValueError` at runtime.\n\nA starred target absorbs any number of elements, so it only requires the ones\naround it: `a, *rest = value` still needs at least one element, and reports for\nthe same reason. A splatted argument is the same question against a parameter\nlist: `f(*value)` binds the parameters positionally, so a length that does not\nmatch raises `TypeError` rather than `ValueError`.\n\nThree values are left alone: one whose type is `Any`, which has opted out of\nchecking altogether; one whose element type is `Unknown`, which ty fills in\nwhere the code said nothing at all; and an unannotated parameter, whose type is\nbounded by what its function's body asks of it — including the unpacking itself.\n\n## Examples\n\n```python\ndef f() -> tuple[int, ...]:\n    return ()\n\n\ndef take(a: int, b: int) -> None: ...\n\n\na, b = f()  # error: [refutable-unpacking]\ntake(*f())  # error: [refutable-unpacking]\n```\n\nGive the value a length the type carries, or narrow it to one:\n\n```python\ndef f() -> tuple[int, int]:\n    return (1, 2)\n\n\na, b = f()\n\n\ndef g(values: tuple[int, ...]) -> None:\n    if len(values) == 2:\n        c, d = values  # ok — narrowed to `tuple[int, int]`\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "reified-classmethod": {
          "title": "detects classmethods with reified type parameters",
          "description": "## What it does\nChecks for classmethods whose type parameters are reified.\n\n## Why is this bad?\nA type parameter referenced in a value position is *reified*: the\nspecialization step (`f[int]`) becomes a runtime operation that\nrebuilds the function's closure with the type arguments. The\nclassmethod binding hides the underlying function behind an opaque\nbound method, so a reified classmethod can be neither specialized\nnor called at runtime.\n\n## Example\n\n```by\nclass C:\n    @classmethod\n    def make[T](cls) -> object:\n        return T()  # error: `T` is reified, but `make` is a classmethod\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "shadowed-receiver-member": {
          "title": "detects a block declaration that shadows the receiver's member of the same name",
          "description": "## What it does\nChecks for a declaration inside a [trailing lambda] block that gives the block a\nname the block's receiver already has a member for.\n\n## Why is this bad?\nThe declaration takes the name away from the member for the whole block. A bare\n`href = \"/x\"` there writes the receiver's `href`, and reading `href` means the\nreceiver's `href` — so a `let href` two lines away silently makes both mean\nsomething else.\n\nShadowing is what a declaration is for, so this is a warning rather than an error:\nit is how you ask for a name of your own when the receiver happens to have one\nalready. Renaming the local says the same thing without the ambiguity.\n\n## Examples\n```by\nclass Tag:\n    var href: str\n\n    def div(self, block: Tag.() -> None) -> None:\n        block(self)\n\ndef build(t: Tag) -> None:\n    t.div:\n        href = \"/x\"      # ok, writes `t.href`\n        let href = \"/x\"  # warning: shadows `t.href` for the whole block\n```\n\n[trailing lambda]: https://basedpython.org/features/trailing-lambdas/",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "shadowed-type-variable": {
          "title": "detects type variables that shadow type variables from outer scopes",
          "description": "## What it does\n\nChecks for type variables in nested generic classes or functions that shadow type variables\nfrom an enclosing scope.\n\n## Why is this bad?\n\nShadowing type variables makes the code confusing and is disallowed by the typing spec.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\nclass Outer[T]:\n    # `T` is already used by `Outer`\n    class Inner[T]: ...  # error\n\n    # `T` is already used by `Outer`\n    def method[T](self, x: T) -> T:  # error\n        return x\n```\n\n## References\n\n- [Typing spec: Generics](https://typing.python.org/en/latest/spec/generics.html#introduction)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "static-assert-error": {
          "title": "Failed static assertion",
          "description": "## What it does\n\nMakes sure that the argument of `static_assert` is statically known to be true.\n\n## Why is this bad?\n\nA `static_assert` call represents an explicit request from the user\nfor the type checker to emit an error if the argument cannot be verified\nto evaluate to `True` in a boolean context.\n\n## Examples\n\n```python\nfrom ty_extensions import static_assert\n\n# evaluates to `False`\nstatic_assert(1 + 1 == 3)  # error\n\n# does not have a statically known truthiness\nstatic_assert(int(2.0 * 3.0) == 6)  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "subclass-of-dataclass-with-order": {
          "title": "detects subclasses of dataclasses with `order=True`",
          "description": "## What it does\n\nChecks for classes that inherit from a dataclass with `order=True`.\n\n## Why is this bad?\n\nWhen a dataclass has `order=True`, comparison methods (`__lt__`, `__le__`, `__gt__`, `__ge__`)\nare generated that compare instances as tuples of their fields. These methods raise a\n`TypeError` at runtime when comparing instances of different classes in the inheritance\nhierarchy, even if one is a subclass of the other.\n\nThis violates the [Liskov Substitution Principle][liskov-substitution-principle] because child class instances cannot be\nused in all contexts where parent class instances are expected.\n\n## Example\n\n```python\nfrom dataclasses import dataclass\n\n\n@dataclass(order=True)\nclass Parent:\n    value: int\n\n\nclass Child(Parent):  # error\n    pass\n\n\n# At runtime, this raises TypeError:\n# Child(1) < Parent(2)\n```\n\nConsider using [`functools.total_ordering`][total_ordering] instead, which does not have this limitation.\n\n[liskov-substitution-principle]: https://en.wikipedia.org/wiki/Liskov_substitution_principle\n[total_ordering]: https://docs.python.org/3/library/functools.html#functools.total_ordering",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "subclass-of-final-class": {
          "title": "detects subclasses of final classes",
          "description": "## What it does\n\nChecks for classes that subclass final classes.\n\n## Why is this bad?\n\nDecorating a class with `@final` declares to the type checker that it should not be subclassed.\n\n## Example\n\n```python\nfrom typing import final\n\n\n@final\nclass A: ...\n\n\nclass B(A): ...  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "subclass-of-sealed-class": {
          "title": "detects subclasses of sealed classes from outside their workspace",
          "description": "## What it does\nChecks for classes that subclass a basedpython `sealed` class from outside\nthe workspace in which the sealed class is defined.\n\n## Why is this bad?\nA `sealed` class declares a closed set of subclasses. It may be subclassed\nfreely from anywhere within its own workspace, but not from a dependency,\nso that the set of subclasses is fully known.\n\n## Example\n\n```by\n# in a dependency:\nsealed class Shape\n\n# in your workspace:\nclass Circle(Shape): ...  # error: `Shape` is sealed in another workspace\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "super-call-in-named-tuple-method": {
          "title": "detects `super()` calls in methods of `NamedTuple` classes",
          "description": "## What it does\n\nChecks for calls to `super()` inside methods of `NamedTuple` classes.\n\n## Why is this bad?\n\nUsing `super()` in a method of a `NamedTuple` class will raise an exception at runtime.\n\n## Examples\n\n```python\nfrom typing import NamedTuple\n\n\nclass F(NamedTuple):\n    x: int\n\n    def method(self):\n        # super() is not supported in methods of NamedTuple classes\n        super()  # error\n```\n\n## References\n\n- [Python documentation: super()](https://docs.python.org/3/library/functions.html#super)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "template-member-alters-data": {
          "title": "detects a template lookup landing on a method django refuses to call",
          "description": "## What it does\nChecks for a `{{ }}` lookup landing on a method django refuses to call\nfrom a template.\n\n## Why is this bad?\nDjango calls whatever a lookup lands on, except a method marked\n`alters_data = True` — a template is not allowed to write to the\ndatabase. Rather than call it, django renders `string_if_invalid` — the\nempty string by default — silently, with no error and no output.\n\nThe methods django marks are the ones that write: `save`, `delete` and\ntheir `async` twins on a model, and the `create`/`update`/`bulk_*`\nfamily on a queryset, a manager and the manager behind a relation.\nOverriding one keeps the mark, so an override is reported too, exactly\nas django's own `AltersData` propagates it at runtime.\n\n## Examples\n```django\n{{ book.save }}     {# warning: renders nothing #}\n{{ book.title }}    {# ok #}\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "template-member-needs-arguments": {
          "title": "detects a template lookup landing on a method that needs arguments",
          "description": "## What it does\nChecks for a `{{ }}` lookup landing on a method that cannot be called\nwithout arguments.\n\n## Why is this bad?\nDjango calls whatever a lookup lands on. A method that needs an argument\ncannot be called, so django renders `string_if_invalid` — the empty string\nby default — silently, with no error and no output.\n\n## Examples\n```python\nclass Book:\n    def headline(self, length: int) -> str: ...\n    def title(self) -> str: ...\n```\n\n```django\n{{ book.headline }}    {# warning: renders nothing #}\n{{ book.title }}       {# ok #}\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "too-many-positional-arguments": {
          "title": "detects calls passing too many positional arguments",
          "description": "## What it does\n\nChecks for calls that pass more positional arguments than the callable can accept.\n\n## Why is this bad?\n\nPassing too many positional arguments will raise `TypeError` at runtime.\n\n## Example\n\n```python\ndef f(): ...\n\n\nf(\"foo\")  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "trailing-lambda-control-flow": {
          "title": "detects non-local control flow in a non-`once` trailing-lambda block",
          "description": "## What it does\nChecks for a `return` in a trailing-lambda block whose callback is **not**\n`once`.\n\n## Why is this bad?\nA block bound to a `once` callback runs exactly once, like a `with` body,\nso its `return` may target the enclosing function. A non-`once` callback\nmay run any number of times (or not at all), so the block is an ordinary\nclosure — a `return` would leave the block, not the enclosing scope, which\nis almost never what the caller intends.\n\nA `break` / `continue` that would leave the block is already reported as\nbeing outside a loop (the block is a function scope), so this lint covers\nonly `return`.\n\n## Example\n\n```by\ndef each(items: list[int], fn: (int) -> None): ...\n\ndef find(items: list[int]) -> int:\n    each(items):\n        return it  # error: `return` in a non-`once` block leaves the block\n    return -1\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "trailing-lambda-parameters": {
          "title": "detects a trailing-lambda callback taking arguments the block cannot bind",
          "description": "## What it does\nChecks for a trailing-lambda block whose callback takes arguments the\nblock has no parameter for.\n\n## Why is this bad?\nA block binds one argument, as `it` — plus its callback's implicit\nreceiver, which the body spells `self` and reads members off\nunqualified. A callback that takes more than that, or takes a variadic\nparameter, passes arguments the block cannot name, and would be called\nwith more arguments than it declares.\n\n## Example\n\n```by\ndef f(a: (int, str) -> None):\n    a(1, \"two\")\n\nf:  # error: the block binds only `it`, so `\"two\"` has nowhere to go\n    print(it)\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "trailing-lambda-return-type": {
          "title": "detects a trailing-lambda callback whose return type does not accept `None`",
          "description": "## What it does\nChecks for a trailing-lambda block whose callback's declared return type\ndoes not accept `None`.\n\n## Why is this bad?\nA trailing-lambda block lowers to a function that returns `None` (in a\n`once` block a `return` targets the *enclosing* function, not the block).\nA callback whose return type does not accept `None` — `int`, `str`, … —\ncan never be satisfied by the block. A return type that merely accepts\n`None` (`None` itself, `int | None`, `object`) is fine; other non-`None`\nreturn types are not yet supported.\n\n## Example\n\n```by\ndef f(a: (int) -> str):  # callback returns `str`\n    print(a(1))\n\nf:  # error: the block returns `None`, not `str`\n    print(it)\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "type-assertion-failure": {
          "title": "detects failed type assertions",
          "description": "## What it does\n\nChecks for `assert_type()` and `assert_never()` calls where the actual type\nis not the same as the asserted type.\n\n## Why is this bad?\n\n`assert_type()` allows confirming the inferred type of a certain value.\n\n## Example\n\n```toml\n[environment]\npython-version = \"3.11\"\n```\n\n```python\nfrom typing import assert_type\n\n\ndef _(x: int):\n    assert_type(x, int)  # fine\n    # Actual type does not match asserted type\n    assert_type(x, str)  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unannotated-model-field": {
          "title": "detects a pydantic model field specifier without a type annotation",
          "description": "## What it does\nChecks for a pydantic model field assigned a field specifier\n(`Field(...)`) without a type annotation.\n\n## Why is this bad?\nPydantic requires every field to be annotated. An unannotated\n`name = Field(...)` is not collected as a field and raises\n`PydanticUserError` when the model class is created.\n\n## Example\n\n```py\nfrom pydantic import BaseModel, Field\n\nclass User(BaseModel):\n    name = Field(default=\"\")  # error: needs a type annotation\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unavailable-implicit-super-arguments": {
          "title": "detects invalid `super()` calls where implicit arguments are unavailable.",
          "description": "## What it does\n\nDetects invalid `super()` calls where implicit arguments like the enclosing class or first method argument are unavailable.\n\n## Why is this bad?\n\nWhen `super()` is used without arguments, Python tries to find two things:\nthe nearest enclosing class and the first argument of the immediately enclosing function (typically self or cls).\nIf either of these is missing, the call will fail at runtime with a `RuntimeError`.\n\n## Examples\n\n```python\n# no enclosing class or function found\nsuper()  # error\n\n\ndef func():\n    # no enclosing class or first argument exists\n    super()  # error\n\n\nclass A:\n    # no enclosing function to provide the first argument\n    f = super()  # error\n\n    def method(self):\n        def nested():\n            # first argument does not exist in this nested function\n            super()  # error\n\n        # first argument does not exist in this lambda\n        lambda: super()  # error\n\n        # argument is not available in generator expression\n        (super() for _ in range(10))  # error\n\n        super()  # okay! both enclosing class and first argument are available\n```\n\n## References\n\n- [Python documentation: super()](https://docs.python.org/3/library/functions.html#super)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unbound-type-variable": {
          "title": "detects type variables used outside of their bound scope",
          "description": "## What it does\n\nChecks for type variables that are used in a scope where they are not bound\nto any enclosing generic context.\n\n## Why is this bad?\n\nUsing a type variable outside of a scope that binds it has no well-defined meaning.\n\n## Examples\n\n```python\nfrom typing import TypeVar, Generic\n\nT = TypeVar(\"T\")\nS = TypeVar(\"S\")\n\n# unbound type variable in module scope\nx: T  # error\n\n\nclass C(Generic[T]):\n    # S is not in this class's generic context\n    x: list[S] = []  # error\n```\n\n## References\n\n- [Typing spec: Scoping rules for type variables](https://typing.python.org/en/latest/spec/generics.html#scoping-rules-for-type-variables)",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unclosed-template-block": {
          "title": "detects a django template block tag that is never closed",
          "description": "## What it does\nChecks for a block tag in a django template whose closing tag is missing.\n\n## Why is this bad?\nDjango raises `TemplateSyntaxError` when it compiles the template, so the\npage does not render at all.\n\nOnly a tag known to open a block is reported: one of django's own, or one\nthe project registers with `@register.simple_block_tag`.\n\n## Examples\n```django\n{% if user.is_staff %}    {# error: no `{% endif %}` #}\n  <p>hello</p>\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "undeclared-dependency": {
          "title": "detects imports of a distribution the project does not depend on",
          "description": "## What it does\n\nChecks for imports of an installed distribution the project never declared\na dependency on.\n\n## Why is this bad?\n\nThe import only works because something else the project depends on\nhappened to pull the distribution in. Nothing keeps that true: the\ndependency that brought it can drop it, or move to a version that no longer\nneeds it, and then the import fails for everyone installing the project\nfresh — while continuing to work in the environment it was written in.\n\nDepending on something means saying so.\n\n## Examples\n\n`requests` installs `charset_normalizer`, but a project that only declares\n`requests` has not declared `charset_normalizer`:\n\n```toml\n[project]\nname = \"my-lib\"\ndependencies = [\"requests\"]\n```\n\n```python\nimport charset_normalizer  # error: [undeclared-dependency]\n```\n\nAdding it to `[project].dependencies` fixes the import. In an editor this\nis offered as a quick fix.\n\n## Configuration\n\nThe check is only made when the project says what it depends on: a project\nwith no `[project]` table, an environment with no install metadata, and a\nmodule ty cannot attribute to a distribution are all cases where nothing is\nreported.\n\nA dependency can also declare that part of what it hands out is another\ndistribution, and then importing that one is not reported:\n\n```toml\n# the dependency's own pyproject.toml\n[tool.basedpython.analysis]\nexported-dependencies = [\"numpy\"]\n```\n\nA build writes this into the `by.typed` marker its package ships, which is\nwhat the projects depending on it read.",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "undeclared-raise": {
          "title": "detects an exception a `raises` clause does not include",
          "description": "## What it does\nChecks for a basedpython function that can raise an exception its\n`raises` clause does not include.\n\n## Why is this bad?\nA `raises` clause is the function's contract about what can escape a\ncall to it. Callers rely on that set to decide what they must handle, so\nan exception outside it escapes somewhere nobody expects it.\n\n## Example\n\n```by\ndef f() raises TypeError:\n    raise ValueError  # error: `ValueError` is not declared\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "undefined-reveal": {
          "title": "detects usages of `reveal_type` without importing it",
          "description": "## What it does\n\nChecks for calls to `reveal_type` without importing it.\n\n## Why is this bad?\n\nUsing `reveal_type` without importing it will raise a `NameError` at runtime.\n\n## Examples\n\n```python\n# NameError: name 'reveal_type' is not defined\n# error\nreveal_type(1)  # revealed: Literal[1]\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unhandled-exception": {
          "title": "detects an exception escaping the `main` entry point",
          "description": "## What it does\nChecks for an exception that can escape a basedpython `main` function.\n\n## Why is this bad?\n`main` is the program's entry point, so it has no caller to handle what\nit raises. An exception escaping it terminates the program with a\ntraceback rather than an error the program chose to report.\n\n## Example\n\n```by\ndef read() raises OSError: ...\n\ndef main():\n    read()  # error: `OSError` can escape `main`\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unknown-argument": {
          "title": "detects unknown keyword arguments in calls",
          "description": "## What it does\n\nChecks for keyword arguments in calls that don't match any parameter of the callable.\n\n## Why is this bad?\n\nProviding an unknown keyword argument will raise `TypeError` at runtime.\n\n## Example\n\n```python\ndef f(x: int) -> int:\n    return x\n\n\nf(x=1, y=2)  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unknown-fixture": {
          "title": "detects a pytest parameter that resolves to no known fixture",
          "description": "## What it does\nChecks a pytest test or fixture parameter that resolves to no known\nfixture.\n\n## Why is this bad?\npytest fails such a request at collection time with a \"fixture not\nfound\" error. A renamed or misspelled fixture leaves a parameter that\nno provider satisfies.\n\n## Off by default\nThird-party plugins inject fixtures through `pytest11` entry points,\nwhich this check does not yet discover, so it would false-positive on\nany plugin-provided fixture. It ships as an opt-in lint until plugin\ndiscovery lands.\n\n## Example\n\n```py\ndef test_thing(no_such_fixture) -> None:  # requests an unknown fixture\n    ...\n```",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unknown-template-block": {
          "title": "detects a `{% block %}` no ancestor template declares",
          "description": "## What it does\nChecks for a `{% block %}` overriding a block no ancestor template\ndeclares.\n\n## Why is this bad?\nA child template's blocks are rendered by the parent, so a block the\nparent never declares is never rendered — silently, with no error and no\noutput.\n\nOnly a block written at the top level of a template that `{% extends %}`\nsomething is reported. A block nested inside another one is rendered as\npart of its enclosing block and needs no declaration above it.\n\n## Examples\n```django\n{# base.html declares `content`, and nothing else #}\n{% extends \"base.html\" %}\n{% block sidebar %}hello{% endblock %}    {# warning: never rendered #}\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unknown-template-filter": {
          "title": "detects a django template filter nothing registers",
          "description": "## What it does\nChecks for a filter no library the template can reach registers.\n\n## Why is this bad?\nDjango raises `TemplateSyntaxError` when it compiles the template, so the\npage does not render at all.\n\nA filter whose library the template has simply not loaded is reported as\n`unloaded-template-library` instead.\n\n## Examples\n```django\n{{ book.title|uppercase }}    {# error: the filter is `upper` #}\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unknown-template-library": {
          "title": "detects a `{% load %}` of a library the project does not have",
          "description": "## What it does\nChecks for a `{% load %}` of a tag library the project does not have.\n\n## Why is this bad?\nDjango raises `TemplateSyntaxError` when it compiles the template, so the\npage does not render at all.\n\nA library is a `templatetags` module of the project or of one of the apps\n`INSTALLED_APPS` names. Nothing is reported unless the settings module was\nfound and every installed app resolved, since a library that cannot be\nreached is not a library that is missing.\n\n## Examples\n```django\n{% load blog_xtras %}    {# error: the library is `blog_extras` #}\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unknown-template-tag": {
          "title": "detects a django template tag nothing registers",
          "description": "## What it does\nChecks for a tag no library the template can reach registers.\n\n## Why is this bad?\nDjango raises `TemplateSyntaxError` when it compiles the template, so the\npage does not render at all.\n\nA tag whose library the template has simply not loaded is reported as\n`unloaded-template-library` instead.\n\n## Examples\n```django\n{% iff user.is_staff %}    {# error: no such tag #}\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unloaded-template-library": {
          "title": "detects a tag or filter used without the `{% load %}` it needs",
          "description": "## What it does\nChecks for a tag or filter used without the `{% load %}` it needs.\n\n## Why is this bad?\nDjango raises `TemplateSyntaxError` when it compiles the template, so the\npage does not render at all — the tag exists, but not in this template.\n\nA library named by `TEMPLATES[*][\"OPTIONS\"][\"builtins\"]` is loaded into\nevery template already and is never reported.\n\n## Examples\n```django\n{% static 'css/site.css' %}    {# error: needs `{% load static %}` #}\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unmatched-template-close": {
          "title": "detects a django template closing tag that closes nothing",
          "description": "## What it does\nChecks for a closing tag in a django template that closes nothing.\n\n## Why is this bad?\nDjango raises `TemplateSyntaxError` when it compiles the template, so the\npage does not render at all.\n\n## Examples\n```django\n{% for book in books %}\n  <p>{{ book.title }}</p>\n{% endwith %}    {# error: nothing here opened a `{% with %}` #}\n{% endfor %}\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unresolved-attribute": {
          "title": "detects references to unresolved attributes",
          "description": "## What it does\n\nChecks for unresolved attributes.\n\n## Why is this bad?\n\nAccessing an unbound attribute will raise an `AttributeError` at runtime.\nAn unresolved attribute is not guaranteed to exist from the type alone,\nso this could also indicate that the object is not of the type that the user expects.\n\n## Examples\n\n```python\nclass A: ...\n\n\n# AttributeError: 'A' object has no attribute 'foo'\nA().foo  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unresolved-global": {
          "title": "detects `global` statements with no definition in the global scope",
          "description": "## What it does\n\nDetects variables declared as `global` in an inner scope that have no explicit\nbindings or declarations in the global scope.\n\n## Why is this bad?\n\nFunction bodies with `global` statements can run in any order (or not at all), which makes\nit hard for static analysis tools to infer the types of globals without\nexplicit definitions or declarations.\n\n## Example\n\n### Assigning without a global-scope declaration\n\n```python\ndef f():\n    # unresolved global\n    global x  # error\n    x = 42\n\n\ndef g():\n    print(x)  # unresolved reference\n```\n\n### Use instead\n\n#### Declare the global\n\n```python\nx: int\n\n\ndef f():\n    global x\n    x = 42\n\n\ndef g():\n    print(x)\n```\n\n#### Initialize the global\n\n```python\nx: int | None = None\n\n\ndef f():\n    global x\n    x = 42\n\n\ndef g():\n    print(x)\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unresolved-import": {
          "title": "detects unresolved imports",
          "description": "## What it does\n\nChecks for import statements for which the module cannot be resolved.\n\n## Why is this bad?\n\nImporting a module that cannot be resolved will raise a `ModuleNotFoundError`\nat runtime.\n\n## Examples\n\n```python\n# ModuleNotFoundError: No module named 'foo'\nimport foo  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unresolved-narrowing-guard": {
          "title": "detects a narrowing return annotation that names no place",
          "description": "## What it does\nChecks for a basedpython narrowing return annotation whose place doesn't exist.\n\n## Why is this bad?\n`-> asserts x` and `-> x is T` name the place a call narrows. The name is\nresolved against the function's parameters, and otherwise against the places\nvisible where the guard is written. A name that is neither — a typo, or a\nparameter that was later renamed — silently narrows nothing at every call site.\n\n## Example\n\n```by\ndef check(value: int | None) -> asserts values:  # error: `values` is nothing\n    if value is None:\n        raise ValueError\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unresolved-reference": {
          "title": "detects references to names that are not defined",
          "description": "## What it does\n\nChecks for references to names that are not defined.\n\n## Why is this bad?\n\nUsing an undefined variable will raise a `NameError` at runtime.\n\n## Example\n\n```python\n# NameError: name 'x' is not defined\nprint(x)  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unresolved-route": {
          "title": "detects a `{% url %}` naming a route that does not exist",
          "description": "## What it does\nChecks for a `{% url %}` naming a route the url configuration does not\nhave.\n\n## Why is this bad?\nDjango raises `NoReverseMatch` when it renders the template, so the page\n500s.\n\nThe route names are the ones the walk from `ROOT_URLCONF` finds. A project\nthat does not say where its url tree starts, or whose tree could not be\nwalked in full, reports nothing.\n\n## Examples\n```django\n<a href=\"{% url 'blog:detail' book.pk %}\">    {# error: it is `blog:detail` #}\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unresolved-static-file": {
          "title": "detects a `{% static %}` naming a file that is not there",
          "description": "## What it does\nChecks for a `{% static %}` naming a file that is not there.\n\n## Why is this bad?\nDjango's default storage builds the url from the name without checking it,\nso the page renders and the asset 404s — a failure nothing reports.\n\nA name whose directory holds no discovered file at all is left alone: that\nis what a bundle built into `static/` at deploy time looks like, and it is\nnot something the source tree can answer.\n\n## Examples\n```django\n{% load static %}\n<link href=\"{% static 'css/sight.css' %}\">    {# warning: it is `css/site.css` #}\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unresolved-template": {
          "title": "detects a reference to a template that is not there",
          "description": "## What it does\nChecks for an `{% extends %}` or `{% include %}` naming a template that\nis not there.\n\n## Why is this bad?\nDjango raises `TemplateDoesNotExist` when it renders the template, so the\npage 500s.\n\nNothing is reported unless the project's template directories are known:\na project with no readable settings *and* no directory named `templates`\nis one whose template set cannot be established.\n\n## Examples\n```django\n{% extends \"blog/bass.html\" %}    {# error: the template is `blog/base.html` #}\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unsound-cast": {
          "title": "detects a plain `cast` that is not a widening",
          "description": "## What it does\nChecks for a plain `cast` that is not a widening — one whose value is not\nalready known to be the target type.\n\n## Why is this bad?\n`cast` reinterprets a value without looking at it, so it is only ever\ntruthful when the checker can already prove the value is the target.\nCasting *down* — `object` to `int` — makes a claim about the value that\nnothing verifies, and the program carries on with a type it may not have.\n\nThe two suffixed forms make the claim honest by saying what happens when\nit turns out to be false: `cast!` raises a `TypeError`, and `cast?`\nyields `None`, so its type is `<target> | None`.\n\nA gradual `Any` or `Unknown` value is not \"already the target\" either —\nnothing is known about it, which is exactly when a check is worth having.\n\n## Examples\n```by\ndef f(a: object, b: int, c: Any):\n    b cast object    # ok — `int` is already an `object`\n    a cast int       # error: `object` is not already an `int`\n    c cast int       # error: nothing is known about an `Any`\n\n    a cast! int      # raises unless `a` really is an `int`\n    a cast? int      # `int | None`\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unsound-return-statement": {
          "title": "detects return statements that unsoundly return a type that is not a subtype of the function's annotated return type",
          "description": "## What it does\n\nDetects `return` statements that unsoundly return a type that is not a [subtype] of the function's\nannotated return type.\n\nThis lint is a stricter version of `invalid-return-type`.\n\n## Why is this bad?\n\nBy default, type checkers consider a `return` statement valid if the inferred type of the object\nbeing returned is [assignable] to the annotated return type of the function it's in. However, this\nmakes it easy for incorrect types to percolate through your code unexpectedly due to a single\nexpression being inferred as `Any`. This can easily lead to runtime errors that are not caught by\nthe type checker:\n\n```py\nfrom typing import Any\n\n\ndef returns_any() -> Any:\n    return \"foo\"\n\n\ndef returns_int() -> int:\n    # error: \"Unsound return statement: `Any` is not a subtype of `int`\"\n    return returns_any()\n\n\n# fails at runtime, even though the type checker infers both operands as being of type `int`!\nreturns_int() + 42\n```\n\nThis rule allows you to use [\"fully static\"][fully-static] return types as \"typed boundaries\" for\nyour code. With this rule enabled, ty would emit an error on the `return returns_any()` statement\nin `returns_int`, since the `returns_any()` call is inferred as having type `Any`, and `Any` is not\na subtype of `int`. This helps prevent the unsoundness from spreading far from its original source\n(in this case, the return type of the `returns_any` function).\n\nNote that this rule is only applied to functions annotated as returning\n[fully static][fully-static] types. It will not trigger if `Any` or `Unknown` appear anywhere in\nyour return type, either implicitly or explicitly:\n\n```py\nfrom typing import Any\n\n\ndef returns_any() -> Any:\n    return \"foo\"\n\n\n# error: [missing-type-argument]\ndef returns_unparameterized_tuple() -> tuple:\n    # no error, since the return type is implicitly `tuple[Unknown, ...]`\n    # (which is what the `missing-type-argument` error is complaining about on the line above!)\n    return returns_any()\n\n\ndef returns_list_of_any() -> list[Any]:\n    # no error, since the return type is explicitly `list[Any]`\n    return returns_any()\n```\n\nThis rule works especially well when combined with ty's\n`missing-type-argument` rule, and the Ruff rules [`ANN201`][ann201],\n[`ANN202`][ann202], [`ANN204`][ann204], [`ANN205`][ann205], and [`ANN206`][ann206]. Enabling all\nthese rules at once effectively makes it much less likely that a `return` statement can lead to\nunsoundness \"leaking\" out of a function unless that function has been *explicitly* annotated with\na dynamic type in some way (`-> Any` or `-> tuple[Any]`, for example).\n\nThis rule is analogous to mypy's [`no-any-return`][no-any-return] error code, which is enabled by\nmypy’s [`--strict`][mypy-strict] mode and can also be enabled on its own using mypy’s\n[`--warn-return-any`][warn-return-any] option.\n\n## Examples\n\n```py\nfrom typing import Any\n\n\ndef returns_any() -> Any:\n    return 42\n\n\ndef returns_int() -> int:\n    # error: \"Unsound return statement: `Any` is not a subtype of `int`\"\n    return returns_any()\n```\n\nNarrow the type to a subtype of `int` to fix the diagnostic:\n\n```py\nfrom typing import Any\nfrom typing_extensions import reveal_type\n\n\ndef returns_any() -> Any:\n    return 42\n\n\ndef returns_int() -> int:\n    my_int = returns_any()\n    assert isinstance(my_int, int)\n    reveal_type(my_int)  # revealed: Any & int\n    return my_int  # no error: `Any & int` is a subtype of `int`\n```\n\n## Default level\n\nThis rule is disabled by default. It is intended for advanced users wanting additional soundness\nchecks from their type checker, not for users who have just started to use type checkers on their\nPython code.\n\n## See also\n\n- `unsound-yield` is a similar rule that triggers on unsound `yield` expressions rather than unsound `return` statements\n\n[ann201]: https://docs.astral.sh/ruff/rules/missing-return-type-undocumented-public-function/\n[ann202]: https://docs.astral.sh/ruff/rules/missing-return-type-private-function/\n[ann204]: https://docs.astral.sh/ruff/rules/missing-return-type-special-method/\n[ann205]: https://docs.astral.sh/ruff/rules/missing-return-type-static-method/\n[ann206]: https://docs.astral.sh/ruff/rules/missing-return-type-class-method/\n[assignable]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable\n[fully-static]: https://typing.python.org/en/latest/spec/glossary.html#term-fully-static-type\n[mypy-strict]: https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-strict\n[no-any-return]: https://mypy.readthedocs.io/en/stable/error_code_list2.html#code-no-any-return\n[subtype]: https://typing.python.org/en/latest/spec/glossary.html#term-subtype\n[warn-return-any]: https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-warn-return-any",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unsound-yield": {
          "title": "detects yield expressions that unsoundly yield a type that is not a subtype of the generator's annotated yield type",
          "description": "## What it does\n\nDetects `yield` and `yield from` expressions that unsoundly yield a type that is not a [subtype] of\nthe generator function's annotated yield type.\n\nThis lint is a stricter version of `invalid-yield`.\n\n## Why is this bad?\n\nBy default, type checkers consider a yielded value valid if its inferred type is [assignable] to the\ngenerator's annotated yield type. However, this\nmakes it easy for incorrect types to percolate through your code unexpectedly due to a single\nexpression being inferred as `Any`. This can easily lead to runtime errors that are not caught by\nthe type checker:\n\n```py\nfrom typing import Any, Generator\n\n\ndef returns_any() -> Any:\n    return \"not an integer\"\n\n\ndef integers() -> Generator[int]:\n    # error: \"Unsound `yield`: `Any` is not a subtype of `int`\"\n    yield returns_any()\n\n\n# Fails at runtime, even though the type checker infers `integers` as yielding only `int`s!\nsum(integers())\n```\n\nThis rule treats [fully static][fully-static] yield types as \"typed boundaries\" for your code. With this rule enabled, ty would emit an error on the `yield returns_any()` statement\nin `integers`, since the `returns_any()` call is inferred as having type `Any`, and `Any` is not\na subtype of `int`. This helps prevent the unsoundness from spreading far from its original source\n(in this case, the return type of the `returns_any` function).\n\nNote that this rule is only applied to functions annotated as yielding\n[fully static][fully-static] types. It will not trigger if `Any` or `Unknown` appear anywhere in\nyour function's yield type, either implicitly or explicitly. It will still trigger on functions that have non-fully-static send and/or return types, however:\n\n```py\nfrom typing import Any, Generator\n\n\ndef returns_any() -> Any:\n    return \"not an integer\"\n\n\ndef dynamic_yield_type() -> Generator[Any]:\n    yield returns_any()\n\n\ndef static_yield_type() -> Generator[int, Any, Any]:\n    # error: \"Unsound `yield`: `Any` is not a subtype of `int`\"\n    yield returns_any()\n```\n\nThis rule works especially well when combined with ty's\n`missing-type-argument` rule, and the Ruff rules [`ANN201`][ann201],\n[`ANN202`][ann202], [`ANN204`][ann204], [`ANN205`][ann205], and [`ANN206`][ann206]. Enabling all\nthese rules at once effectively makes it much less likely that a `yield` expression can lead to\nunsoundness \"leaking\" out of a function unless that function has been *explicitly* annotated with\na dynamic type in some way (`-> Generator[Any]` or `-> Generator[tuple[Any]]`, for example).\n\n## Examples\n\n```py\nfrom typing import Any, Iterator\n\n\ndef returns_any() -> Any:\n    return \"foo\"\n\n\ndef any_iterator() -> Iterator[Any]:\n    yield \"foo\"\n\n\ndef integers() -> Iterator[int]:\n    # error: \"Unsound `yield`: `Any` is not a subtype of `int`\"\n    yield returns_any()\n    # error: \"Unsound `yield from`: `Any` is not a subtype of `int`\"\n    yield from any_iterator()\n```\n\nNarrow the value before yielding it to fix the diagnostics:\n\n```py\nfrom typing import Any, Iterator\n\n\ndef returns_any() -> Any:\n    return 42\n\n\ndef any_iterator() -> Iterator[Any]:\n    yield \"foo\"\n\n\ndef integers() -> Iterator[int]:\n    value = returns_any()\n    assert isinstance(value, int)\n    yield value\n\n    for value in any_iterator():\n        assert isinstance(value, int)\n        yield value\n```\n\n## Default level\n\nThis rule is disabled by default. It is intended for users who want stricter soundness checks at\ngenerator boundaries.\n\n## See also\n\n- `unsound-return-statement` is a similar rule that triggers on unsound `return` statements rather than unsound `yield` expressions\n\n[ann201]: https://docs.astral.sh/ruff/rules/missing-return-type-undocumented-public-function/\n[ann202]: https://docs.astral.sh/ruff/rules/missing-return-type-private-function/\n[ann204]: https://docs.astral.sh/ruff/rules/missing-return-type-special-method/\n[ann205]: https://docs.astral.sh/ruff/rules/missing-return-type-static-method/\n[ann206]: https://docs.astral.sh/ruff/rules/missing-return-type-class-method/\n[assignable]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable\n[fully-static]: https://typing.python.org/en/latest/spec/glossary.html#term-fully-static-type\n[subtype]: https://typing.python.org/en/latest/spec/glossary.html#term-subtype",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unspecialized-reified-generic": {
          "title": "detects calls to reified generic functions without explicit specialization",
          "description": "## What it does\nChecks for calls to a basedpython reified generic function whose\nspecialization is neither written explicitly nor inferable from the\narguments.\n\n## Why is this bad?\nA function whose type parameter is referenced in a value position is\n*reified*: the type parameter behaves like a positional parameter that\nis filled by the `[...]` specialization step. A bare call is legal only\nwhen the transpiler can inject that step — every type parameter must\nsolve, from the arguments or its PEP 696 default, to a type with a\nruntime spelling at the call site. Otherwise the parameter has no\nvalue at runtime.\n\n## Example\n\n```by\ndef f[T](t: object):\n    print(T)\n\nf[int](1)  # ok\nf(1)       # error: `T` appears nowhere in the signature\n\ndef g[T](t: T):\n    print(T)\n\ng(1)       # ok — transpiles to g[int](1)\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unsupported-base": {
          "title": "detects class bases that are unsupported as ty could not feasibly calculate the class's MRO",
          "description": "## What it does\n\nChecks for class definitions that have bases which are unsupported by ty.\n\n## Why is this bad?\n\nIf a class has a base that is an instance of a complex type such as a union type,\nty will not be able to resolve the [method resolution order] (MRO) for the class.\nThis will lead to an inferior understanding of your codebase and unpredictable\ntype-checking behavior.\n\n## Examples\n\n```python\nimport datetime\n\n\nclass A: ...\n\n\nclass B: ...\n\n\nif datetime.date.today().weekday() != 6:\n    C = A\nelse:\n    C = B\n\n\nclass D(C): ...  # error: [unsupported-base]\n```\n\n[method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unsupported-bool-conversion": {
          "title": "detects boolean conversion where the object incorrectly implements `__bool__`",
          "description": "## What it does\n\nChecks for bool conversions where the object doesn't correctly implement `__bool__`.\n\n## Why is this bad?\n\nIf an exception is raised when you attempt to evaluate the truthiness of an object,\nusing the object in a boolean context will fail at runtime.\n\n## Examples\n\n```python\nclass NotBoolable:\n    __bool__ = None\n\n    def __lt__(self, other: object) -> \"NotBoolable\":\n        return self\n\n\nb1 = NotBoolable()\nb2 = NotBoolable()\n\n# exception raised here\nif b1:  # error\n    pass\n\n# exception raised here\nb1 and b2  # error\n# exception raised here\nnot b1  # error\n\n# A chained comparison converts the result of `b1 < b2` to bool.\n# exception raised here\nb1 < b2 < b1  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unsupported-dynamic-base": {
          "title": "detects dynamic class bases that are unsupported as ty could not feasibly calculate the class's MRO",
          "description": "## What it does\n\nChecks for dynamic class definitions (using `type()`) that have bases\nwhich are unsupported by ty.\n\nThis is equivalent to `unsupported-base` but applies to classes created\nvia `type()` rather than `class` statements.\n\n## Why is this bad?\n\nIf a dynamically created class has a base that is an unsupported type\nsuch as `type[T]`, ty will not be able to resolve the\n[method resolution order] (MRO) for the class. This may lead to an inferior\nunderstanding of your codebase and unpredictable type-checking behavior.\n\n## Default level\n\nThis rule is disabled by default because it will not cause a runtime error,\nand may be noisy on codebases that use `type()` in highly dynamic ways.\n\n## Examples\n\n```python\nclass Base: ...\n\n\ndef factory(base: type[Base]) -> type:\n    # `base` has type `type[Base]`, not `type[Base]` itself\n    return type(\"Dynamic\", (base,), {})  # error: [unsupported-dynamic-base]\n```\n\n[method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order",
          "default": "ignore",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unsupported-operator": {
          "title": "detects binary, unary, or comparison expressions where the operands don't support the operator",
          "description": "## What it does\n\nChecks for binary expressions, comparisons, and unary expressions where\nthe operands don't support the operator.\n\n## Why is this bad?\n\nAttempting to use an unsupported operator will raise a `TypeError` at\nruntime.\n\n## Examples\n\n```python\nclass A: ...\n\n\n# TypeError: unsupported operand type(s) for +: 'A' and 'A'\nA() + A()  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unused-awaitable": {
          "title": "detects awaitable objects that are used as expression statements without being awaited",
          "description": "## What it does\n\nChecks for awaitable objects (such as coroutines) used as expression\nstatements without being awaited.\n\n## Why is this bad?\n\nCalling an `async def` function returns a coroutine object. If the\ncoroutine is never awaited, the body of the async function will never\nexecute, which is almost always a bug. Python emits a\n`RuntimeWarning: coroutine was never awaited` at runtime in this case.\n\n## Examples\n\n```python\nasync def fetch_data() -> str:\n    return \"data\"\n\n\nasync def main() -> None:\n    # Warning: coroutine is not awaited\n    fetch_data()  # error\n    await fetch_data()  # OK\n```",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unused-ignore-comment": {
          "title": "detects unused `ty: ignore` comments",
          "description": "## What it does\n\nChecks for `ty: ignore` directives that are no longer applicable.\n\n## Why is this bad?\n\nA `ty: ignore` directive that no longer matches any diagnostic violations is likely\nincluded by mistake, and should be removed to avoid confusion.\n\n## Examples\n\n```py\n# error\na = 20 / 2  # ty: ignore[division-by-zero]\n```\n\nUse instead:\n\n```py\na = 20 / 2\n```\n\n## Options\n\nSet [`analysis.respect-type-ignore-comments`](https://docs.astral.sh/ty/reference/configuration/#respect-type-ignore-comments)\nto `false` to prevent this rule from reporting unused `type: ignore` comments.",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unused-type-ignore-comment": {
          "title": "detects unused `type: ignore` comments",
          "description": "## What it does\n\nChecks for `type: ignore` directives that are no longer applicable.\n\n## Why is this bad?\n\nA `type: ignore` directive that no longer matches any diagnostic violations is likely\nincluded by mistake, and should be removed to avoid confusion.\n\n## Examples\n\n```py\n# error\na = 20 / 2  # type: ignore\n```\n\nUse instead:\n\n```py\na = 20 / 2\n```\n\n## Options\n\nThis rule is skipped if [`analysis.respect-type-ignore-comments`](https://docs.astral.sh/ty/reference/configuration/#respect-type-ignore-comments)\nto `false`.",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "useless-overload-body": {
          "title": "detects `@overload`-decorated functions with non-stub bodies",
          "description": "## What it does\n\nChecks for various `@overload`-decorated functions that have non-stub bodies.\n\n## Why is this bad?\n\nFunctions decorated with `@overload` are ignored at runtime; they are overridden\nby the implementation function that follows the series of overloads. While it is\nnot illegal to provide a body for an `@overload`-decorated function, it may indicate\na misunderstanding of how the `@overload` decorator works.\n\n## Example\n\n```toml\n[environment]\npython-version = \"3.11\"\n```\n\n```py\nfrom typing import overload\n\n\n@overload\ndef foo(x: int) -> int:\n    # will never be executed\n    return x + 1  # error\n\n\n@overload\ndef foo(x: str) -> str:\n    # will never be executed\n    return \"Oh no, got a string\"  # error\n\n\ndef foo(x: int | str) -> int | str:\n    raise Exception(\"unexpected type encountered\")\n```\n\nUse instead:\n\n```py\nfrom typing import assert_never, overload\n\n\n@overload\ndef foo(x: int) -> int: ...\n\n\n@overload\ndef foo(x: str) -> str: ...\n\n\ndef foo(x: int | str) -> int | str:\n    if isinstance(x, int):\n        return x + 1\n    elif isinstance(x, str):\n        return \"Oh no, got a string\"\n    else:\n        assert_never(x)\n```\n\n## References\n\n- [Python documentation: `@overload`](https://docs.python.org/3/library/typing.html#typing.overload)",
          "default": "warn",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "zero-stepsize-in-slice": {
          "title": "detects a slice step size of zero",
          "description": "## What it does\n\nChecks for a step size of zero in slices when the operation is known to fail.\n\n## Why is this bad?\n\nPython's built-in sequence types raise a `ValueError` when sliced with a step size of zero.\n\n## Known problems\n\nThis check is not exhaustive. It reports zero-step slices for certain built-in sequence\ntypes where the operation is known to fail. A custom `__getitem__` implementation can\naccept or reject such a slice, so ty cannot detect every runtime failure.\n\n## Examples\n\n```python\nvalues = list(range(10))\n# ValueError: slice step cannot be zero\nvalues[1:10:0]  # error\n\ntuple_values = (1, 2, 3)\n# ValueError: slice step cannot be zero\ntuple_values[1:10:0]  # error\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        }
      },
      "additionalProperties": {
        "$ref": "#/definitions/Level"
      }
    },
    "RunOptions": {
      "type": "object",
      "properties": {
        "main": {
          "description": "The module `by run` executes when no module is given on the command line.\n\nThis is the project's entry point: with it set, `by run` alone transpiles the project and\nruns `python -m <main>`, exactly as if the module had been named on the command line. A\nmodule named explicitly always wins.\n\nThe value is a module path, not a file path — `app.cli`, not `app/cli.by`.\n\nDefaults to `null`, in which case `by run` requires a module argument.",
          "anyOf": [
            {
              "$ref": "#/definitions/string"
            },
            {
              "type": "null"
            }
          ]
        }
      },
      "additionalProperties": false
    },
    "SrcOptions": {
      "type": "object",
      "properties": {
        "exclude": {
          "description": "A list of file and directory patterns to exclude from type checking.\n\nPatterns follow a syntax similar to `.gitignore`:\n\n- `./src/` matches only a directory\n- `./src` matches both files and directories\n- `src` matches files or directories named `src`\n- `*` matches any (possibly empty) sequence of characters (except `/`).\n- `**` matches zero or more path components.\n  This sequence **must** form a single path component, so both `**a` and `b**` are invalid and will result in an error.\n  A sequence of more than two consecutive `*` characters is also invalid.\n- `?` matches any single character except `/`\n- `[abc]` matches any character inside the brackets. Character sequences can also specify ranges of characters, as ordered by Unicode,\n  so e.g. `[0-9]` specifies any character between `0` and `9` inclusive. An unclosed bracket is invalid.\n- `!pattern` negates a pattern (undoes the exclusion of files that would otherwise be excluded)\n\nAll paths are anchored relative to the project root (`src` only\nmatches `<project_root>/src` and not `<project_root>/test/src`).\nTo exclude any directory or file named `src`, use `**/src` instead.\n\nBy default, ty excludes commonly ignored directories:\n\n- `**/.bzr/`\n- `**/.direnv/`\n- `**/.eggs/`\n- `**/.git/`\n- `**/.git-rewrite/`\n- `**/.hg/`\n- `**/.mypy_cache/`\n- `**/.nox/`\n- `**/.pants.d/`\n- `**/.pytype/`\n- `**/.ruff_cache/`\n- `**/.svn/`\n- `**/.tox/`\n- `**/.venv/`\n- `**/__pypackages__/`\n- `**/_build/`\n- `**/buck-out/`\n- `**/dist/`\n- `**/node_modules/`\n- `**/venv/`\n\nYou can override any default exclude by using a negated pattern. For example,\nto re-include `dist` use `exclude = [\"!dist\"]`, or `exclude = [\"!**/dist/\"]` to\nre-include every `dist` directory rather than only the one at the project root.\n\nA negated pattern can only re-include something that is still walked, so it cannot\nreach into a directory that is itself excluded. `exclude = [\"!dist/generated.py\"]`\nre-includes nothing, because the walk stops at `dist`. Re-include the directory\nfirst: `exclude = [\"!**/dist/\", \"**/dist/**\", \"!**/dist/generated.py\"]`",
          "anyOf": [
            {
              "$ref": "#/definitions/Array_of_string"
            },
            {
              "type": "null"
            }
          ]
        },
        "exclude-scripts": {
          "description": "Whether to exclude files containing PEP 723 inline script metadata unless they are\nexplicitly passed on the command line.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "include": {
          "description": "A list of files and directories to check. The `include` option\nfollows a similar syntax to `.gitignore` but reversed:\nIncluding a file or directory will make it so that it (and its contents)\nare type checked.\n\n- `./src/` matches only a directory\n- `./src` matches both files and directories\n- `src` matches a file or directory named `src`\n- `*` matches any (possibly empty) sequence of characters (except `/`).\n- `**` matches zero or more path components.\n  This sequence **must** form a single path component, so both `**a` and `b**` are invalid and will result in an error.\n  A sequence of more than two consecutive `*` characters is also invalid.\n- `?` matches any single character except `/`\n- `[abc]` matches any character inside the brackets. Character sequences can also specify ranges of characters, as ordered by Unicode,\n  so e.g. `[0-9]` specifies any character between `0` and `9` inclusive. An unclosed bracket is invalid.\n\nAll paths are anchored relative to the project root (`src` only\nmatches `<project_root>/src` and not `<project_root>/test/src`).\n\n`exclude` takes precedence over `include`.",
          "anyOf": [
            {
              "$ref": "#/definitions/Array_of_string"
            },
            {
              "type": "null"
            }
          ]
        },
        "respect-ignore-files": {
          "description": "Whether to automatically exclude files that are ignored by `.ignore`,\n`.gitignore`, `.git/info/exclude`, and global `gitignore` files.\nEnabled by default.",
          "type": [
            "boolean",
            "null"
          ]
        }
      },
      "additionalProperties": false
    },
    "SupportedPythonVersion": {
      "description": "A Python version explicitly supported by ty configuration and CLI parsing.",
      "oneOf": [
        {
          "description": "Python 3.7",
          "type": "string",
          "const": "3.7"
        },
        {
          "description": "Python 3.8",
          "type": "string",
          "const": "3.8"
        },
        {
          "description": "Python 3.9",
          "type": "string",
          "const": "3.9"
        },
        {
          "description": "Python 3.10",
          "type": "string",
          "const": "3.10"
        },
        {
          "description": "Python 3.11",
          "type": "string",
          "const": "3.11"
        },
        {
          "description": "Python 3.12",
          "type": "string",
          "const": "3.12"
        },
        {
          "description": "Python 3.13",
          "type": "string",
          "const": "3.13"
        },
        {
          "description": "Python 3.14",
          "type": "string",
          "const": "3.14"
        },
        {
          "description": "Python 3.15",
          "type": "string",
          "const": "3.15"
        }
      ]
    },
    "SystemPathBuf": {
      "description": "An owned, mutable path on [`System`](`super::System`) (akin to [`String`]).\n\nThe path is guaranteed to be valid UTF-8.",
      "type": "string"
    },
    "TerminalOptions": {
      "type": "object",
      "properties": {
        "error-on-warning": {
          "description": "Use exit code 1, even if all diagnostics only had `warning` severity.\n\nDefaults to `true`.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "output-format": {
          "description": "The format to use for printing diagnostic messages.\n\nDefaults to `full`.",
          "anyOf": [
            {
              "$ref": "#/definitions/OutputFormat"
            },
            {
              "type": "null"
            }
          ]
        }
      },
      "additionalProperties": false
    },
    "string": {
      "type": "string"
    }
  }
}