ty.schema.json

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Options",
  "type": "object",
  "properties": {
    "analysis": {
      "anyOf": [
        {
          "$ref": "#/definitions/AnalysisOptions"
        },
        {
          "type": "null"
        }
      ]
    },
    "build": {
      "description": "Configures what `by build` writes, and what a wheel of this project carries.",
      "anyOf": [
        {
          "$ref": "#/definitions/BuildOptions"
        },
        {
          "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"
        }
      ]
    },
    "experimental": {
      "anyOf": [
        {
          "$ref": "#/definitions/ExperimentalOptions"
        },
        {
          "type": "null"
        }
      ]
    },
    "lowering": {
      "description": "Configures how basedpython spells constructs python has no spelling of its own for.",
      "anyOf": [
        {
          "$ref": "#/definitions/LoweringOptions"
        },
        {
          "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"
        }
      ]
    },
    "type-checking-preset": {
      "description": "The defaults that `rules` and `analysis` start from.\n\nA preset decides which diagnostics exist and which of them are enabled, and it supplies\nthe default for every `analysis` option. Both tables are still read, and both still win\nover the preset, so a preset is a starting point rather than a straitjacket.\n\n* `strict`: every diagnostic is enabled, and every analysis option that buys soundness\n  is on. This is the default.\n* `ty-compatible`: the defaults of [ty](https://github.com/astral-sh/ty), which\n  basedpython is built on. basedpython's own diagnostics and analysis options are off,\n  so that a project reports what ty itself would report. A diagnostic that doesn't exist\n  in ty can't be enabled under this preset, not even with `rules = { all = \"error\" }`.\n\nDefaults to `strict`.",
      "anyOf": [
        {
          "$ref": "#/definitions/TypeCheckingPreset"
        },
        {
          "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`, and to `false` under the `ty-compatible` type checking preset.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "block-scoped-declarations": {
          "description": "Whether a `let` or `var` declaration written inside a block binds its name for\nthat block only. This is a basedpython feature.\n\nPython has no block scopes: a name bound anywhere in a function is a local of\nthat whole function, and the python a `.by` file lowers to keeps it that way. So\nthis is a rule the checker enforces rather than something the emitted code does:\n\n```by\nif flag:\n    let a = 1\n\nprint(a)  # error: `a` is not in scope here\n```\n\nOnly the binding keyword scopes a name to its block. A plain `a = 1` binds for\nthe whole enclosing function or module, as it does in python.\n\nDefaults to `true`, and to `false` under the `ty-compatible` type checking preset.",
          "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`, and to `true` under the `ty-compatible` type checking preset.",
          "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`, and to `false` under the `ty-compatible` type checking preset.",
          "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`, and to `false` under the `ty-compatible` type checking preset.",
          "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 `true`, and to `false` under the `ty-compatible` type checking preset.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "strict-equality-semantics": {
          "description": "Configure ty's behavior regarding type inference and narrowing of equality\nchecks.\n\nDefaults to `true`, and to `false` under the `ty-compatible` type checking preset.\n\nWith this option disabled, ty makes various assumptions about equality checks that\nmatch the intuitions of most Python programmers, but may not be fully sound in all\nsituations. Leaving it enabled makes ty conservative about those 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 such unsound assumption is narrowing an object `x` of type `str` to `Literal[\"a\"]`\nafter an `if x == \"a\"` check. This is unsound because a subclass of `str` with value\n`\"a\"` will (by default) compare equal to `\"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\nThis option prevents the unsound narrowing of `x` to `Literal[\"a\"]`, and instead keeps\nit as `str`:\n\n```python\nfrom typing import Literal\n\ndef parse(value: str) -> Literal[\"a\"] | None:\n    # with `strict-equality-semantics` enabled, 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` still has 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, and this option\nimpacts those too. For example, it also impacts narrowing from `in` checks, and narrowing\nin `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` still has 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` still has 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"
      }
    },
    "BuildOptions": {
      "type": "object",
      "properties": {
        "exclude": {
          "description": "Files to keep out of the build output.\n\nThe syntax is the same as `src.exclude`, and paths are anchored to the\nproject root. Excluding a `.by` file keeps its transpiled output out of\nthe build as well.",
          "anyOf": [
            {
              "$ref": "#/definitions/Array_of_string"
            },
            {
              "type": "null"
            }
          ]
        },
        "include": {
          "description": "Files to carry into the build output verbatim, in addition to the ones\nthat are there by default.\n\n`by build` mirrors the whole module tree: a `.by` file is transpiled, and\nevery other file — a hand-written `.py`, a `py.typed` marker, a template,\na data file — is copied to the same place in the output. `include` is for\nthe files that sit *outside* a module root and still belong in the build,\nsuch as a data directory next to `src`.\n\nThe syntax is the same as `src.include`, and paths are anchored to the\nproject root. `exclude` takes precedence over `include`.",
          "anyOf": [
            {
              "$ref": "#/definitions/Array_of_string"
            },
            {
              "type": "null"
            }
          ]
        },
        "sources": {
          "description": "Whether the build output carries the `.by` sources alongside the python\nthey were transpiled into, with a `by.typed` marker naming them as the\nauthoritative surface.\n\nThis is what lets one basedpython project depend on another: a downstream\npython project reads the transpiled `.py` and is served perfectly, while a\ndownstream basedpython project reads the `.by` and keeps the declarations\nthat have no python spelling — `extension` blocks, `raises` clauses,\nread-only `let`, sum types.\n\nEnabled by default. Turn it off to ship python only.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "version-from": {
          "description": "The module to read `__version__` from, when `[project]` declares\n`dynamic = [\"version\"]`.\n\nThis is read when a wheel or a source distribution is built, not by the\nchecker: a version has to be settled before the packaging backend sees the\nproject, and the place it lives is a `.by` module that backend cannot\nread.\n\nThe value is a path relative to the project root.",
          "anyOf": [
            {
              "$ref": "#/definitions/string"
            },
            {
              "type": "null"
            }
          ]
        },
        "wheel-versions": {
          "description": "The python versions to build a wheel for, one wheel each.\n\n`by build --wheels` builds one wheel per version listed and tags each for\nthe python it was lowered to, so an installer hands every interpreter the\nbest wheel it can use. A python with no wheel of its own takes the newest\none below it.\n\nDefaults to every version from the one the project targets up to the\nnewest this release knows about — which is what `requires-python` already\nsays the project supports, so most projects need not set this. List them\nexplicitly to ship fewer.",
          "anyOf": [
            {
              "$ref": "#/definitions/Array_of_string"
            },
            {
              "type": "null"
            }
          ]
        }
      },
      "additionalProperties": false
    },
    "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\nScripts with inline metadata use their own Python environment. They can use an explicitly\nconfigured environment, an activated environment, or an environment selected by the editor.\nUnlike projects, they do not automatically use a `.venv` directory.\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\nScripts with inline metadata use their `requires-python` field instead of\n`project.requires-python`. They do not inherit the Python version of the enclosing project.\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`\n\nScripts with inline metadata have no first-party roots by default because they are\nsingle-file programs. Set `root = [\".\"]` to allow importing local modules.",
          "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
    },
    "ExperimentalOptions": {
      "description": "Features that are still being designed, and are off unless the project asks\nfor them by name.\n\nAn experimental feature may change or be withdrawn without the deprecation\nperiod a stable one gets. Opting in says you would rather have it than that\nguarantee.",
      "type": "object",
      "properties": {
        "build-stamps": {
          "description": "Whether a `build:` block declares build stamps.\n\n`build:` declares the values a build settles when it produces the artifact\n— the commit it was built from, the time it was built at — and each is read\nas `build.NAME` at the type it declares. With this off the block still\nparses and still lowers, so a program that reads a stamp keeps working, but\nwriting one is reported: nothing settles a stamp the project has not asked\nfor, so it would silently stand for its default, or for nothing.",
          "type": [
            "boolean",
            "null"
          ]
        },
        "module-api": {
          "description": "Whether an `implements` declaration is enforced.\n\n`implements Backend` obliges the module that writes it to answer the\nprotocol, and a `for` clause in a package's `__init__` imposes the same\nobligation on the modules its patterns name. With this off the declaration\nstill parses and still lowers, but nothing is checked against it — and a\ndeclaration written anyway is reported, rather than quietly doing nothing.",
          "type": [
            "boolean",
            "null"
          ]
        }
      },
      "additionalProperties": false
    },
    "FloatLiteralLowering": {
      "description": "How a float or complex literal type reaches the transpiled python.",
      "oneOf": [
        {
          "title": "Nominal",
          "description": "The type the literal is one of: `1.5` becomes `float`, `2j` becomes `complex`.",
          "type": "string",
          "const": "nominal"
        },
        {
          "title": "Literal",
          "description": "The literal itself, inside `Literal[...]`. Runs, but no checker accepts it.",
          "type": "string",
          "const": "literal"
        }
      ]
    },
    "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"
        }
      ]
    },
    "LoweringOptions": {
      "type": "object",
      "properties": {
        "float-literals": {
          "description": "How a float or complex literal type is spelled in the transpiled python.\n\nbasedpython reads `a: 1.5` as a literal type, and python has no spelling for one:\nPEP 586 admits only `None`, `int`, `bool`, `str`, `bytes` and enum members into\n`Literal[...]`.\n\n* `nominal` (the default) writes the type the literal is one of — `a: 1.5` becomes\n  `a: float`, `a: 2j` becomes `a: complex`. The precision is lost, and every checker\n  that reads the output accepts it.\n* `literal` keeps the literal, writing `a: Literal[1.5]`. The precision survives and\n  the output still runs, because `typing` does not check what it is handed — but a\n  checker reading it reports the argument as invalid.",
          "anyOf": [
            {
              "$ref": "#/definitions/FloatLiteralLowering"
            },
            {
              "type": "null"
            }
          ]
        }
      },
      "additionalProperties": false
    },
    "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 or script's configuration 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 method cannot\nbe overridden. Combining the decorators therefore makes it impossible for a subclass to provide a\nconcrete 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 methods that are\nnot implemented, the class can never be properly instantiated, as the abstract methods can never be\nimplemented (since subclassing is prohibited).\n\nAt runtime, instantiation of classes with unimplemented abstract methods is only prevented for\nclasses that have `ABCMeta` (or a subclass of it) as their metaclass. However, type checkers also\nenforce this for classes that do not use `ABCMeta`, since the intent for the class to be abstract is\nclear 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 through a\nprotocol method's `self` or `cls` receiver, leads to an ambiguous interface which may lead to the\ntype checker inferring unexpected things. It's recommended to ensure that all members of a protocol\nclass 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 is an unspellable subtype of the asserted\ntype.\n\n## Why is this bad?\n\n`assert_type()` is intended to ensure that the inferred type of a value is exactly the same as the\nasserted type. But in some situations, ty has nonstandard extensions to the type system that allow\nit to infer more precise types than can be expressed in user annotations. ty emits a different error\ncode to `type-assertion-failure` in these situations so that users can easily differentiate between\nthe 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 applicable line or\nfile. Specifying rule codes documents which diagnostics are expected and prevents the comment from\nsilencing 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": "warn",
          "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 with \"trivial bodies\" when accessed\non the class object itself.\n\n\"Trivial bodies\" are bodies that solely consist of `...`, `pass`, a docstring, and/or\n`raise NotImplementedError`.\n\n## Why is this bad?\n\nAn abstract method with a trivial body has no concrete implementation to execute, so calling such a\nmethod directly on the class will probably not have the desired effect.\n\nIt is also unsound to call these methods directly on the class. Unlike other methods, ty permits\nabstract methods with trivial bodies to have non-`None` return types even though they always return\n`None` at runtime. This is because it is expected that these methods will always be overridden\nrather than being called directly. As a result of this exception to the normal rule, ty may infer an\nincorrect type if one of these 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, since the actual runtime\ntype 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 callable\ntypes 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 precise signature.\nThis type represents the set of all possible callable types (including, e.g., functions that take no\narguments and functions that require arguments), so no specific set of arguments can be guaranteed\nto 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"
            }
          ]
        },
        "composable-outside-composition": {
          "title": "detects a composable or builder called outside a composition",
          "description": "## What it does\n\nChecks for a call to a `basedpython_ui` composable (a function decorated `@composable`) or to one\nof the framework's widget builders (`Text`, `Button`, `Column`, …) from somewhere that is not a\ncomposition: a function that is not itself a composable, a handler block, a lambda or a nested\n`def`. A composable's body, the `once` content blocks and `local` blocks written in it, and the\n`root` block of `run_app` / `compose_test` are compositions.\n\n## Why is this bad?\n\nA composable opens a scope in the composition being built and a builder emits into it; neither has\nanything to build into outside of one. The runtime raises `CompositionError` at the call; this\ncheck reports it at the source.\n\n## Examples\n\n```by\nfrom basedpython_ui import composable, run_app, Button, Text\n\n@composable\ndef Counter(): ...\n\ndef helper():\n    Counter()                 # error: `helper` is not a composable\n\n@composable\ndef App():\n    Button(\"x\"):\n        Text(\"clicked\")       # error: a handler runs after composition\n\ndef main():\n    run_app(\"app\"):\n        App()                 # ok: the root of the composition\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "conditional-slot": {
          "title": "detects a basedpython-ui slot created under a condition",
          "description": "## What it does\n\nChecks for a `basedpython_ui` slot — `state`, `state_list`, `state_dict`, `derived`, `remember`,\n`launched_effect`, `disposable_effect`, `side_effect` — created under a condition in a composable:\ninside an `if`, `for`, `while`, `try` or `match`, inside a comprehension, or inside a block that is\nnot a `once` content block (a handler block, a lambda, a nested `def`).\n\n## Why is this bad?\n\nA slot lives as long as its enclosing composition scope and is identified by its call site, so a\nconditional slot is created when the condition first holds and disposed — its state lost, its\neffect cancelled — as soon as it stops holding. That is rarely what the code means: state that\nshould outlive a condition belongs above it, and a slot created from a handler has no scope to live\nin at all. The runtime keys slots by call site, so this is safe at runtime; the check makes the\nlifetime visible.\n\n## Examples\n\n```by\nfrom basedpython_ui import composable, state, Text\n\n@composable\ndef Profile(show: bool):\n    if show:\n        let clicks = state(0)   # warning: created and disposed as `show` changes\n        Text(f\"{clicks.value}\")\n\n@composable\ndef Fixed(show: bool):\n    let clicks = state(0)       # ok: lives as long as `Fixed`\n    if show:\n        Text(f\"{clicks.value}\")\n```",
          "default": "warn",
          "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. Moreover, it could lead to\nincorrect or ill-defined type inference for other 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 being created would not be a subclass\nof the metaclasses of all 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"
            }
          ]
        },
        "content-block-control-flow": {
          "title": "detects a `return` inside a nested `once` content block",
          "description": "## What it does\n\nChecks for a `return` inside a `once` content block that is itself written inside another\ntrailing-lambda block.\n\n## Why is this bad?\n\nA `once` block runs exactly once, inline, so a `return` inside it is allowed to leave the enclosing\nscope — but only one level: the language propagates a block's `return` to the scope the block is\nwritten in. When that scope is itself a block, the `return` leaves the inner block and stops there;\nthe enclosing function keeps running, and the returned value is silently discarded.\n\n(A `break` or `continue` inside any block is already rejected as `break` outside loop: a block is\nits own function.)\n\n## Examples\n\n```by\ndef Column(once content: () -> None):\n    content()\n\ndef Row(once content: () -> None):\n    content()\n\ndef App(done: bool) -> int:\n    Column:\n        Row:\n            if done:\n                return 1  # error: [content-block-control-flow]\n        return 2  # ok: one level, leaves `App`\n    return 0\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 (directly or indirectly) from themselves.\n\n## Why is it bad?\n\nAlthough forward references are natively supported in stub files, inheritance cycles are still\ndisallowed, as it is impossible to resolve 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 circular type alias definitions.\n\n## Why is it bad?\n\nRecursive aliases are valid when recursive references occur inside another type, such as\n`list[Tree]`. An alias cannot expand directly to itself or include itself as a union member. This\napplies to both `type` statements and aliases created with `TypeAliasType`.\n\n## Examples\n\n```toml\n[environment]\npython-version = \"3.12\"\n```\n\n```python\nfrom typing import TypeAliasType\n\ntype Itself = Itself  # error\n\ntype A = B  # error\ntype B = A  # error\n\ntype IntOr = int | IntOr  # error\n\nCycle = TypeAliasType(\"Cycle\", \"Cycle\")  # error\n\ntype Tree = int | list[Tree]  # valid recursive alias\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 fields with default values.\n\n## Why is this bad?\n\nIn dataclasses, all required fields (fields without default values) must be defined before fields\nwith default values. This is a Python requirement that will raise a `TypeError` at runtime if\nviolated.\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"
            }
          ]
        },
        "disjoint-cast": {
          "title": "detects `cast` calls between disjoint types",
          "description": "## What it does\n\nDetects `cast` calls where the inferred type of the value is disjoint from the destination type.\n\nTwo types are disjoint if they are entirely non-overlapping. For example, `str` and `int` are\ndisjoint types because it is impossible to create a Python object that is both a `str` and an `int`\nat the same time: Python forbids multiple inheritance between these two classes:\n\n```pycon\n>>> class StrAndInt(int, str): ...\nTraceback (most recent call last):\n  File \"<python-input-0>\", line 1, in <module>\n    class StrAndInt(int, str): ...\nTypeError: multiple bases have instance lay-out conflict\n```\n\nThis means that any object of type `int` can never also be of type `str`, and any object of type\n`str` can never also inhabit the type `int`. The only common subtype of these two types is\n[`Never`][never], the uninhabited type, which has no members.\n\n## Why is this bad?\n\n`cast()` is deliberately designed as an \"escape hatch\" in the type system that is neither validated\nat runtime nor, by default, by type checkers. While upcasting to a supertype is always sound, and\ncasting to a subtype can be sound in some situations if accompanied by careful validation checks,\n`cast()` is also deliberately designed to allow unsound narrowing, and most useful applications of\n`cast()` in real-world code cannot be fully validated by a type checker.\n\nNonetheless, even while acknowledging the fact that `cast()` is intentionally designed to allow\nunsoundness, casting a value to an entirely *disjoint* type is especially likely to indicate a\nmistake in your code. A cast from an `int` to a `str`, for example, likely indicates a bug or\nmisunderstanding.\n\nThis rule therefore provides a means for codebases to partially validate their uses of `cast()`\nwithout banning the API -- or even banning all unsound uses of the API -- entirely.\n\n## Example\n\n```py\nfrom typing import cast\n\n\ndef parse(value: int) -> str:\n    return cast(str, value)  # error: [disjoint-cast]\n```\n\nCasts between overlapping (non-disjoint) types are allowed:\n\n```py\nfrom collections.abc import Sequence\nfrom typing import cast\n\n\ndef validate(numbers: Sequence[int | None]) -> Sequence[int]:\n    if None in numbers:\n        raise TypeError(\"must provide a sequence of numbers!\")\n    return cast(Sequence[int], numbers)\n```\n\nNote that disjointness between types can sometimes be surprising. For example, `list[int]` is\ndisjoint from `list[bool]` even though `bool` is a subtype of `int`. Due to the fact that `list` is\n[mutable and invariant], it would be deeply unsound for ty to ever narrow an object of type\n`list[int]` to the type `list[bool]`. As such, ty will complain about a cast from `list[int]` to\n`list[bool]` when this rule is enabled.\n\nSimilarly, two `NewType`s can be disjoint even when they share the same underlying nominal base\ntype, unless one `NewType` is explicitly declared as a sub-newtype of the other.\n\n```py\nfrom typing import NewType, cast\n\n\nUserId = NewType(\"UserId\", int)\nProUserId = NewType(\"ProUserId\", int)\n\n\ndef f(x: list[int], user_id: UserId):\n    y = cast(list[bool], x)  # error: [disjoint-cast]\n    pro_user_id = cast(ProUserId, user_id)  # error: [disjoint-cast]\n```\n\n## Alternatives\n\nIn many cases, the diagnostic can be avoided by switching to use covariant generic types rather than\ninvariant ones:\n\n```py\n# `Sequence`, unlike `list`, is immutable and covariant\nfrom collections.abc import Sequence\nfrom typing import cast\n\n\ndef f(x: Sequence[int]):\n    y = cast(Sequence[bool], x)  # no diagnostic\n```\n\nThough if you're able to use covariant types, a type-safe narrowing mechanism that provides runtime\nvalidation, such as using `TypeIs`, is generally preferable to using `cast`:\n\n```py\n# `Sequence`, unlike `list`, is immutable and covariant\nfrom collections.abc import Sequence\nfrom typing_extensions import TypeIs, reveal_type\n\n\ndef is_sequence_of_bools(x: Sequence[int]) -> TypeIs[Sequence[bool]]:\n    return all(isinstance(item, bool) for item in x)\n\n\ndef f(x: Sequence[int]):\n    assert is_sequence_of_bools(x)\n    reveal_type(x)  # revealed: Sequence[bool]\n```\n\nIf you're unable to switch to an immutable, covariant generic type, other solutions to this\nparticular diagnostic might include assigning a new list altogether:\n\n```py\ndef f(x: list[int]):\n    y: list[bool] = []\n    for item in x:\n        assert isinstance(item, bool)\n        y.append(item)\n```\n\nOr using a `TypeGuard`. While the \"narrowing\" below is still unsound, there is at least some runtime\nvalidation of the element types taking place, making it superior to the `cast`:\n\n```py\nfrom typing_extensions import TypeGuard, reveal_type\n\n\ndef is_list_of_bools(x: list[int]) -> TypeGuard[list[bool]]:\n    return all(isinstance(item, bool) for item in x)\n\n\ndef f(x: list[int]):\n    assert is_list_of_bools(x)\n    reveal_type(x)  # revealed: list[bool]\n```\n\n## Default level\n\nThis rule is disabled by default. It is designed as a strict rule for users who want additional\nsoundness checks from their type checker, and it may have false positives in some situations.\n\n## See also\n\n- The Ruff rule [`banned-api`][banned-api] can be used to ban the use of `cast()` entirely in your\n    codebase.\n- `redundant-cast` detects casts where the value already has the destination type.\n\n[banned-api]: https://docs.astral.sh/ruff/rules/banned-api/\n[mutable and invariant]: https://docs.astral.sh/ty/reference/typing-faq/#invariant-generics\n[never]: https://docs.python.org/3/library/typing.html#typing.Never",
          "default": "ignore",
          "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 false positives it can produce.\n\n## Examples\n\n```python\n5 / 0  # error\n```",
          "default": "error",
          "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 annotated with `KW_ONLY`.\n\n## Why is this bad?\n\n`dataclasses.KW_ONLY` is a special marker used to emulate the `*` syntax in normal signatures. It\ncan only be used once per dataclass.\n\nAttempting to annotate two different fields with it 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"
            }
          ]
        },
        "dynamic-function-decorator-return": {
          "title": "detects decorators that replace a function with a dynamic type such as `Any`",
          "description": "## What it does\n\nDetects decorator applications that replace a function with `Any` or another [dynamic type].\n\n## Why is this bad?\n\nA decorator can replace the function it receives with any object. Type checkers therefore use the\ndecorator's return type as the type of the decorated function. If the decorator returns `Any` or\n`Unknown`, the original type is lost, along with the type checker's ability to catch invalid calls\nand attribute accesses. basedpython infers an unannotated return, so a decorator reaches this state\nby saying `Any` outright, or by coming from code the checker cannot read:\n\n```py\nfrom collections.abc import Callable\nfrom typing import Any\n\n\ndef untyped_decorator(function: Callable[..., object]) -> Any:\n    return function\n\n\n# error: \"Decorator returns `Any`\"\n@untyped_decorator\ndef stringify(value: int) -> str:\n    return str(value)\n\n\n# No type error is reported, even though `stringify` expects an integer.\nstringify(\"not an integer\")\n```\n\nThis rule identifies the point where a decorator erases useful type information, before that\nimprecision spreads to every use of the decorated function. It can be especially useful in cases\nwhere the decorator is defined in a third-party library. Whereas linter rules such as\n[`ANN201`][ann201] and [`ANN202`][ann202] can complain about missing annotations in your first-party\ncode, they cannot identify instances where unsound types leak into your code due to missing type\nannotations in third-party code installed into `site-packages`.\n\n## Examples\n\n`third_party_library.py`:\n\n```py\nfrom collections.abc import Callable\nfrom typing import Any\n\n\ndef untyped_decorator(function: Callable[..., object]) -> Any:\n    return function\n```\n\n`first_party.py`:\n\n```py\nfrom third_party_library import untyped_decorator\n\n\n# error: \"Decorator returns `Any`\"\n@untyped_decorator\ndef greet(name: str) -> str:\n    return f\"Hello, {name}!\"\n```\n\nIf making a PR to the third-party library to improve their annotations is not possible, fixes for\nthis diagnostic could include writing your own decorator or introducing a type-safe wrapper:\n\n```py\nfrom collections.abc import Callable\nfrom typing import TypeVar\n\nfrom third_party_library import untyped_decorator\n\n\nFunctionT = TypeVar(\"FunctionT\", bound=Callable[..., object])\n\n\ndef typed_wrapper(f: FunctionT) -> FunctionT:\n    decorated = untyped_decorator(f)\n    assert decorated is f\n    return decorated\n\n\n@typed_wrapper\ndef greet(name: str) -> str:\n    return f\"Hello, {name}!\"\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[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[dynamic type]: https://typing.python.org/en/latest/spec/glossary.html#term-dynamic-type",
          "default": "ignore",
          "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` rule. The\ndiagnostic exists as a separate error code to allow users to disable this rule while prototyping\ncode. While we strongly recommend enabling this rule if possible, users migrating from other type\ncheckers may also find it useful to temporarily disable this rule on some or all of their codebase\nif they find it results 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 implicitly return\n`None` at runtime. Returning `None` when the return type is non-`None` is unsound, and will lead to\nty inferring incorrect types elsewhere.\n\nFunctions with empty bodies are permitted in certain contexts where they serve as declarations\nrather 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 with no runtime residue",
          "description": "## What it does\nChecks for parametric type tests (`x is P[int]`) that have no sound\nruntime residue — against a protocol, or against a class the runtime\nrefuses to subscript.\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\nThe probe also has to name the target specialization at runtime, and a\nclass can be generic to a type checker well before the runtime lets you\nsubscript it: `array.array` only grew a `__class_getitem__` in 3.12, and\n`memoryview` in 3.14. Below those versions, evaluating the probe's target\nraises `TypeError` instead of answering the test.\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\n```by\n# on a target below python 3.12\nimport array\n\ndef g(x):\n    return x is array.array[int]  # error: not subscriptable at runtime\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```\n\nA target that isn't subscriptable at runtime still has a bare-class test:\n\n```by\nimport array\n\ndef h(x):\n    return x is array.array  # ok — an ordinary `isinstance`\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. Applying it to a module-level\nfunction or a nested function has no effect 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 assigned a value in their\nscope.\n\n## Why is this bad?\n\nA `Final` symbol must be initialized with a value at the time of declaration or in a subsequent\nassignment. At module or function scope, the assignment must occur in the same scope. In a class\nbody, the assignment may occur in `__init__`. Protocol members are declarations of an interface and\ndo 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\nrule.\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 any\nknown 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-declaration": {
          "title": "detects a variable that is assigned without being declared with `let` or `var`",
          "description": "## What it does\n\nChecks for a variable that a basedpython file assigns without ever declaring it.\n\n## Why is this bad?\n\nPython introduces a variable by assigning to it, so a typo makes a new variable rather than an\nerror, and reading a statement tells you nothing about whether the name is new or one you have seen\nbefore.\n\nbasedpython has a keyword for each: `let` for a binding that never changes, and `var` for one that\ndoes. With this rule on, every variable a scope binds has to be declared once with one of them, and\nevery later assignment is visibly a re-assignment.\n\nThis rule is off by default, because a file written without the keywords is valid basedpython.\n\n## Examples\n\nEvery assignment to a name the scope never declares is reported, so a variable introduced this way\nis reported wherever it is written:\n\n`undeclared.by`:\n\n```by\ncount = 0  # error: [implicit-declaration]\ncount = count + 1  # error: [implicit-declaration]\n```\n\nDeclaring it once answers all of them:\n\n`declared.by`:\n\n```by\nvar count = 0\ncount = count + 1\n```\n\nAn assignment to something other than a plain name — an attribute, a subscript, an item of an\nunpacking — is not a declaration, and is never reported.",
          "default": "ignore",
          "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"
            }
          ]
        },
        "inaccessible-member": {
          "title": "detects access to a `private` or `protected` member from outside where it may be reached",
          "description": "## What it does\nChecks for reads and writes of a `private` or `protected` class member\nfrom outside the code allowed to reach it, and for a module's `private`\nsymbol reached as an attribute of the module from another one.\n\n## Why is this bad?\nA visibility keyword draws a boundary around a member: `private` says only\nthe declaring class's own body may use it, and `protected` extends that to\na subclass's body. Reaching past the boundary defeats the point of drawing\nit, and the member may be renamed or removed without notice.\n\nIt is also very likely to fail at runtime. The lowering spells the\nvisibility in the member's name, and for `private` that name is one python\nmangles: an access written outside the class names a different attribute,\nor none at all.\n\n## Example\n\n```by\nclass Account:\n    init(private let balance: int)\n\ndef audit(account: Account) -> int:\n    return account.balance  # error: `balance` is private to `Account`\n```",
          "default": "error",
          "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 a 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 as a function\n(e.g., `final(type(...))`), type checkers will not understand the application of `final` and will\nnot 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"
            }
          ]
        },
        "ineffective-private": {
          "title": "detects a visibility keyword on a name it cannot act on",
          "description": "## What it does\nChecks for the `private` modifier on a class member whose name it cannot\nhide.\n\n## Why is this bad?\n`private` hides a class member by renaming it so python's name-mangling\napplies, and python mangles only a name with at most one trailing\nunderscore. A dunder is therefore left with the name it was written\nwith, and the modifier does nothing — which is worse than an error,\nbecause the declaration reads as though the member were hidden.\n\n`init` is the exception. It is the one dunder `private` says something\nabout, and it is enforced at the construction site rather than by hiding\na name: see [`private-constructor`](private-constructor.md).\n\n## Example\n\n```by\nclass Point:\n    private def __repr__(self) -> str:  # error: `private` does nothing here\n        return \"Point()\"\n```",
          "default": "error",
          "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 \"instance memory layout conflicts\".\n\nThis error is usually caused by attempting to combine multiple classes that define non-empty\n`__slots__` in a class's [Method Resolution Order][method-resolution-order] (MRO), or by attempting\nto combine multiple builtin classes in a class's MRO.\n\n## Why is this bad?\n\nInheriting from bases with conflicting instance memory layouts will lead to a `TypeError` at\nruntime.\n\nAn instance memory layout conflict occurs when CPython cannot determine the memory layout instances\nof a class should have, because the instance memory layout of one of its bases conflicts with the\ninstance memory layout of one or more of its other bases.\n\nFor example, if a Python class defines non-empty `__slots__`, this will impact the memory layout of\ninstances of that class. Multiple inheritance from more than one different class defining non-empty\n`__slots__` is not allowed:\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 multiple inheritance with two\nbuiltin classes, due to the way that these classes 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 with empty `__slots__`,\nare 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 whose `__slots__` values cannot be determined statically are not always considered disjoint\nbases by ty. Static definitions can include string literals, fixed-length tuples, and literal lists,\nsets, or dictionaries of string literals.\n\nAdditionally, this check is not exhaustive: many C extensions (including several in the standard\nlibrary) define classes that use extended memory layouts and thus cannot coexist in a single MRO.\nSince it is currently not possible to represent this fact in stub files, having a full knowledge of\nthese classes is also impossible. When it comes to classes that do not define `__slots__` at the\nPython level, therefore, ty, currently only hard-codes a number of cases where it knows that a class\nwill produce instances with an 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 the\nexpectations of the function author and may cause unexpected runtime errors within the body of the\nfunction.\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 is 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 weaken a type checker's ability to\naccurately 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 and assignments to instance-only attributes\nfrom their class. Also checks for reads and writes of generic instance attributes through a generic\nclass or a specialized generic alias.\n\nAn \"instance-only\" variable is one which is only ever assigned to or declared when accessed via\n`self` in an instance method.\n\nA generic instance attribute has a type that depends on the class's type parameters. Specializing a\ngeneric class does not create separate class attribute storage, so these attributes cannot be\naccessed through the generic class or a specialized alias. Access through a `type[...]` receiver is\nallowed because it can refer to a concrete subclass with its own class attributes.\n\n## Why is this bad?\n\nIncorrect assignments break the rules of the type system and weaken a type checker's ability to\naccurately 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```\n\n```python\nfrom typing import Generic, TypeVar\n\nT = TypeVar(\"T\")\n\n\nclass Box(Generic[T]):\n    value: T\n\n\nBox[int].value = 1  # error\nBox.value  # error\n\nbox = Box[int]()\nbox.value = 1  # okay\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 is a class variable or an\ninstance variable.\n\nThis rule currently only covers class-variable and instance-variable category changes.\n\n## Why is this bad?\n\nPure class variables and instance variables have different access and assignment behavior.\nOverriding one with the other violates the\n[Liskov Substitution Principle][liskov-substitution-principle] (\"LSP\"), because code that is valid\nfor the 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-build-stamps": {
          "title": "detects a basedpython `build:` block the project has not opted in to",
          "description": "## What it does\nChecks that a `build:` block is one the project has asked for. Build\nstamps are experimental, so a project opts in by name:\n\n```toml\n# basedpython.toml\n[experimental]\nbuild-stamps = true\n```\n\n## Why is this bad?\nThe block parses and lowers whether or not the project opted in, because a\nprogram that reads `build.GIT_SHA` has to keep working when the feature is\nturned off — so nothing at the point of use says the value was never\nsettled. A stamp declared without a default fails the transpile, and one\nwith a default quietly stands for that default in an artifact that claims\nto know what commit it came from.\n\n## Example\n\n```by\nbuild:  # error: `build` is an experimental feature, and is off\n    GIT_SHA: str\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 that 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 class:\n\n- `order=True` with `eq=False`\n- `weakref_slot=True` with `slots=False`\n- `slots=True` when the class already defines `__slots__`\n\nApplying `@dataclass` to a class that inherits from `NamedTuple`, `TypedDict`, `Enum`, or `Protocol`\nis also invalid:\n\n- `NamedTuple` and `TypedDict` classes will raise an exception at runtime when instantiating the\n    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 is not [assignable to] its\npost-hoc declared type.\n\n## Why is this bad?\n\nSuch declarations break the rules of the type system and weaken a type checker's ability to\naccurately 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 for all enum members. An\nexplicit type annotation on an enum member is misleading because the annotated type will be\nincorrect — the actual runtime type is the enum class itself, not the annotated type.\n\nIn CPython's `enum` module, annotated assignments with values are still treated as members at\nruntime, 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\n[`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\nsuperclass.\n\n## Why is this bad?\n\nDecorating a method with `@override` declares to the type checker that the intention is that it\nshould override 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 patterns 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. Many of these\nresult 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]):\n    def set(self, value: V) -> None: ...  # error\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: attempting to create one will\neither result in an immediate `TypeError` at runtime, or will create a class that cannot be\nspecialized in the way that 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 unknown 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 `closed=true`\nit 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 to specify that a\nparameter is positional-only, but do so incorrectly.\n\nThe \"legacy convention\" for specifying positional-only parameters was specified in\n[PEP 484][pep-484]. It states that parameters with names starting with `__` should be considered\npositional-only by type checkers. [PEP 570][pep-570], introduced in Python 3.8, added dedicated\nsyntax for specifying positional-only parameters, rendering the legacy convention obsolete. However,\nsome codebases may still use 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 if it comes after\na positional-or-keyword parameter, even if its name starts with `__`. This may be unexpected to the\nauthor 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. This 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=`. These expressions,\nhowever, need to be callable and accept the same arguments as `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\n[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\nsupertype. Applied to Python, this means:\n\n1. All argument combinations a superclass method accepts must also be accepted by an overriding\n    subclass method.\n1. The return type of an overriding subclass method must be a subtype of the return type of the\n    superclass method.\n\n## Why is this bad?\n\nViolating the Liskov Substitution Principle will lead to many of ty's assumptions and inferences\nbeing incorrect, which will mean that it will fail to catch many possible type 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 objects as their\nsecond 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, it would\nimply that you wouldn't be able to use `==` between instances of `A` and instances of unrelated\nclasses without an exception possibly being raised. While some classes in Python do indeed behave\nthis way, the strongly held convention is that it should be avoided wherever possible. As part of\nthis check, therefore, ty enforces that `__eq__` and `__ne__` methods accept `object` as their\nsecond 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 signature,\nif 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 unused\nparameter should either be removed or renamed to start with `_`. Applying either of these\nsuggestions can cause ty to start reporting an `invalid-method-override` error if the function in\nquestion is a method on a subclass that overrides a method on a superclass, and the change would\ncause the subclass method to no longer accept all argument combinations that the superclass method\naccepts.\n\nThis can usually be resolved by adding [`@typing.override`][override] to your method definition.\nRuff knows that a method decorated with `@typing.override` is intended to override a method by the\nsame name on a superclass, and avoids reporting rules like ARG002 for such methods; it knows that\nthe changes recommended by ARG002 would violate the Liskov Substitution 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-module-api": {
          "title": "detects invalid basedpython `implements` declarations",
          "description": "## What it does\nChecks that an `implements` declaration is one a module can be held to:\nthat it names a protocol, that a `for` clause is written in a package's\n`__init__` with patterns relative to that package and reaching something,\nand that the module it obliges can actually be checked.\n\n## Why is this bad?\nAn obligation nothing can check is worse than no obligation: it reads, in\nreview and in the editor, as a promise that is being enforced. A rule\nwhose patterns match no module, or one written where no module will look\nfor it, enforces nothing at all.\n\nThis also covers a declaration written while the feature is off. `implements`\nis experimental, so a project opts in by name:\n\n```toml\n# basedpython.toml\n[experimental]\nmodule-api = true\n```\n\n## Example\n\n```by\nclass Backend:\n    def connect(self) -> None: ...\n\nimplements Backend  # error: `Backend` is not a protocol\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "invalid-module-getattr-call": {
          "title": "detects imports that fail while calling module-level `__getattr__`",
          "description": "## What it does\n\nChecks for imports that fail when calling a module-level `__getattr__` function.\n\n## Why is this bad?\n\nIf a module defines `__getattr__`, Python calls it when a `from` import requests a name that is not\notherwise defined. The import raises an exception if `__getattr__` cannot accept the requested name.\n\n## Examples\n\n`module.py`:\n\n```python\ndef __getattr__() -> str:\n    return \"fallback\"\n```\n\n`main.py`:\n\n```python\n# TypeError: __getattr__() takes 0 positional arguments but 1 was given\nfrom module import missing  # error\n```",
          "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 drawing incorrect conclusions.\nIt may also lead to `TypeError`s or `AttributeError`s at runtime.\n\n## Examples\n\nA class definition cannot combine `NamedTuple` with other base classes in multiple inheritance;\ndoing so raises a `TypeError` at runtime. The sole exception to this rule is `Generic[]`, which can\nbe used alongside `NamedTuple` in 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`, `_replace`,\netc.) that cannot be overwritten. Attempting to assign to these attributes without a type annotation\nwill 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 qualifiers. These\nqualifiers 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 class where tuple indexing and\n`repr()` still reflect the original field, 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 the 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 mainly\nbeneficial for type checkers. But, if the `@overload` usage is invalid, the type checker may not be\nable 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-override-visibility": {
          "title": "detects a member declared less visible than the one it overrides",
          "description": "## What it does\nChecks for a class member declared less visible than the one it inherits\nunder the same name.\n\n## Why is this bad?\nA visibility keyword decides the name the member is emitted under, so a\nmember declared less visible than the one it inherits does not override\nit. It sits beside it under a different name, and the inherited member is\nstill what a call finds — which is never what the declaration looks like\nit does.\n\n## Example\n\n```by\nclass A:\n    def f(self) -> int:\n        return 1\n\nclass B(A):\n    private def f(self) -> int:  # error: `f` is public on `A`\n        return 2\n\nB().f()  # 1, not 2\n```",
          "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 assigned to the parameter's annotated type.\n\n## Why is this bad?\n\nThis breaks the rules of the type system and weakens a type checker's ability to accurately reason\nabout 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 are invalid at runtime or do not satisfy the typing specification.\n\n## Why is this bad?\n\nAn invalidly defined protocol class may lead to the type checker inferring unexpected things or\naccepting unsafe operations. Some invalid protocol definitions also raise `TypeError` at runtime.\n\n## Examples\n\nA `Protocol` class cannot inherit from a non-`Protocol` class; this 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```\n\nA generic protocol's declared type-variable variance must match how that variable is used by its\nprotocol members. For example, a type variable that appears only in a method's return type must be\ncovariant:\n\n```py\nfrom typing import Protocol, TypeVar\n\nT = TypeVar(\"T\")\n\n\nclass Source(Protocol[T]):  # error: [invalid-protocol]\n    def read(self) -> T: ...\n```\n\nAlthough Python constructs this protocol successfully at runtime, it is invalid for static typing.\nDeclare the type variable with `TypeVar(\"T\", covariant=True)` instead.",
          "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 causes for their raised\nexceptions.\n\n## Why is this bad?\n\nOnly subclasses or instances of `BaseException` can be raised. For an exception's cause, the same\nrules apply, except that `None` is also permitted. Violating these rules results in a `TypeError` at\nruntime.\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\nA type parameter in a clause stands for one type the caller chooses, so\nit has to be declared an exception as well — a parameter with no bound\ncan be `int` as easily as `OSError`.\n\n## Example\n\n```by\ndef f() raises int:  # error: `int` is not an exception\n    ...\n\ndef g[T](value: T) raises T:  # error: `T@g` is not always 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* or a *class*: a function\nrebuilds its closure at the call so the body sees the type argument as a\nruntime value, and a class records it on the specialization its instances\nare built from. A type alias and a `type def` have no such step — their\ntype parameters are erased — and neither has a class's keyword-variadic\npack, which a subscript has no way to supply. `reified` there promises a\nruntime value that never arrives.\n\n## Example\n\n```by\ntype Alias[reified T] = list[T]  # error: an alias's parameters are erased\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 is handled\nby 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 is unsound, and will lead\nto 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-static-resource": {
          "title": "detects a static resource import that cannot be read",
          "description": "## What it does\n\nChecks for basedpython static resource imports that cannot be read.\n\n## Why is this bad?\n\n`import \"data/config.yaml\" as config` says the file is part of the program. A path that names\nnothing, a path that names a place on one machine, a file in a format that is not `.json`, `.toml`,\n`.yaml` or `.yml`, and a document the format's own parser rejects all leave the import with no value\nto bind.\n\n## Examples\n\n`main.by`:\n\n```by\n# error: [invalid-static-resource]\nimport \"data/config.txt\" as config\n\n# error: [invalid-static-resource]\nimport \"/etc/hosts.json\" as hosts\n\n# error: [invalid-static-resource]\nimport \"data/missing.json\" as missing\n```",
          "default": "error",
          "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 parsed as a Python expression.\n\n## Why is this bad?\n\nType annotations are expected to be Python expressions that describe the expected type of a\nvariable, parameter, attribute or `return` statement.\n\nType annotations are permitted to be string-literal expressions, in order to enable forward\nreferences to names not yet defined. However, it must be possible to parse the contents of that\nstring literal 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 define any ordering method\n(`__lt__`, `__le__`, `__gt__`, or `__ge__`).\n\n## Why is this bad?\n\nThe `@total_ordering` decorator requires the class to define at least one ordering method. If none\nis 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 satisfy the type\nvariable's bounds or constraints will lead to incorrect type inference and may indicate a\nmisunderstanding of the generic type's interface.\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 annotation not\nassignable 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 code seen\nonly by the type checker, and not at runtime. Normally this flag is imported from `typing` or\n`typing_extensions`, but it can also be defined locally. If defined locally, it must be assigned the\nvalue `False` at runtime; the type checker will consider its value to be `True`. If annotated, it\nmust 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] but cannot validly be interpreted as\nsuch.\n\n## Why is this bad?\n\nSuch expressions cannot be understood by ty. In 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 a first non-self-like non-keyword-only non-variadic\nparameter.\n\n## Why is this bad?\n\nType narrowing functions must accept at least one positional argument (non-static methods must\naccept 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 that are not in\nscope where the bound is written.\n\n## Why is this bad?\n\nA type parameter's bound may reference a type parameter that is already in scope *and* substituted\nwhere the bound is used: an earlier entry in the same type parameter list, or — for a method — an\nentry in its class's list, which binding the receiver settles.\n\nAnything else has nothing to resolve to. A later entry is not yet in scope, a parameter is not in\nscope inside its own bound, and a legacy `TypeVar` is declared by an assignment, so it has no list\nto hold a position in. A nested class or nested function is in scope but is never substituted, so\nthe reference would still be standing at every use of the generic. A variadic pack's bound describes\nits members rather than the pack's own value, so it cannot reference a type parameter at all.\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[T: U, U](): ...  # error: [invalid-type-variable-bound]\n\n\n# `U` precedes `T`, so `T`'s bound can name it\ndef h[U, T: U](x: U, y: T): ...\n\n\nclass Owner[U]:\n    # the receiver settles `U`, so a method's bound can name it\n    def narrow[T: U](self, x: T) -> U:\n        return x\n\n    # nothing settles `U` for a nested class\n    class Inner[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, or that those constraints\nreference 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 the type variable's bound or\nconstraints.\n\n## Why is this bad?\n\nIf a type variable has a bound, the default must be assignable to that bound (see: [bound rules]).\nIf a type variable has constraints, the default must be one of the constraints (see:\n[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 subtype\nguarantees 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 or invalid base classes.\n\n## Why is this bad?\n\nThe typing spec states that `TypedDict`s are not permitted to have custom metaclasses. Using `**`\nunpacking in a `TypedDict` header is also prohibited by ty, as it means that ty cannot statically\ndetermine whether 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 example,\nmethod definitions and field values aren't allowed. None of these will be available on \"instances of\nthe `TypedDict`\" at runtime (as `dict` is the runtime class of all \"`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-visibility": {
          "title": "detects a visibility keyword where it cannot do what it says",
          "description": "## What it does\nChecks for a visibility keyword written where it cannot do what it says.\n\n## Why is this bad?\nA visibility keyword renames the member or symbol it is written on, since\nthat is the only enforcement python offers. Some names cannot be renamed\nwithout changing what they mean: a dataclass field's name is its\nconstructor's keyword, an enum member's name is how the enum is looked up,\na `private` abstract method can never be overridden, and a dotted import\nbinds a package no rename can keep. The declaration would read as\nrestricted while doing something else.\n\n## Example\n\n```by\nfrom dataclasses import dataclass\n\n@dataclass\nclass Point:\n    private x: int  # error: a dataclass field's name is its constructor's keyword\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 is incompatible with\nthe 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, or using\n`yield from` with a sub-iterator whose yield or send type is incompatible, is a type error that may\ncause downstream consumers of the generator to receive values 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. This includes explicit calls\n`isinstance()`/`issubclass()` against non-runtime-checkable protocols, `issubclass()` calls against\nprotocols that 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. This includes explicit calls to\n`isinstance()`/`issubclass()` and implicit checks 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 the variable they are\nassigned to.\n\n## Why is this bad?\n\nConstructors like `TypeVar`, `ParamSpec`, `NewType`, `NamedTuple`, `TypedDict`, and `TypeAliasType`\nall take a name argument that is normally expected to match the assigned variable. A mismatch is\nusually a typo 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 continue understanding the\nresulting 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-direct-dependency": {
          "title": "detects imports of dependencies that are not declared directly",
          "description": "## What it does\n\nChecks for imports from installable packages that the current project or PEP 723 script does not\ndeclare as direct dependencies.\n\nThe name used in dependency declarations can differ from the import name: for example, the `pillow`\npackage is imported as `PIL`.\n\n## Why is this bad?\n\nA dependency can be installed because another package requires it. Importing that dependency without\ndeclaring it makes your code rely on another package's dependency list. If that package removes the\ndependency, your imports can fail.\n\nDeclare the packages that provide your imports in `project.dependencies` or\n`project.optional-dependencies` in `pyproject.toml`. Non-package files, such as tests and\ndevelopment scripts, can also use dependencies declared in dependency groups.\n\nSee uv's [guide to managing dependencies](https://docs.astral.sh/uv/concepts/projects/dependencies/)\nfor how to add these declarations.\n\n## Rule status\n\nThis rule is disabled by default and requires uv integration.\n\nFor projects, enable uv workspace integration (`TY_UV=1`) and use an existing, synchronized\nenvironment. Running [`uv check`](https://docs.astral.sh/uv/reference/cli/#uv-check) synchronizes\nthe environment automatically before invoking ty, unless `--no-sync` is passed. For these checks, ty\nreads the dependency graph and module ownership returned by `uv workspace metadata` without changing\ninstalled packages. uv may update the lockfile to match the current dependency declarations. uv\n0.12.3 or later is required.\n\nFor PEP 723 scripts, enable uv script integration with `TY_UV=scripts` or `TY_UV=1`. ty synchronizes\neach script's environment and checks imports against its inline `dependencies` list. Declarations\nand environments from the enclosing workspace or other scripts do not apply.\n\n## Known limitations\n\nThe current workspace integration applies to directory checks. Explicit file arguments and\n`--config-file` bypass uv workspace discovery.\n\nImports guarded by `TYPE_CHECKING` are not reported because they are not executed at runtime. They\ncan use development-only dependencies, such as type stub packages, without requiring those packages\nas runtime dependencies.\n\nStandard-library imports and imports whose owning package cannot be identified unambiguously are\nalso not reported.\n\nImports of [namespace packages](https://docs.python.org/3/reference/import.html#namespace-packages)\nthemselves, such as `import ns`, are not reported: the namespace can contain modules from several\ninstallable packages. Imports of their submodules, such as `import ns.child`, are checked when the\nowning package is known. An `__init__.pyi` stub does not change this distinction.\n\nNative packages that ty can resolve only as namespace packages at runtime are also skipped. For\nother native modules, ty can use stubs to resolve the import and uv's ownership map to identify\nwhich package to declare.\n\nSome editable installations add the whole project directory to Python's import path, making both\npackage code and files such as `tests/test_app.py` importable. If uv does not identify which modules\nbelong to the installable package, ty allows dependency-group imports throughout that directory,\nincluding in package code, to avoid incorrectly flagging imports in tests and scripts.\n\n## Examples\n\nWith `requests` as a direct dependency, `urllib3` may also be installed because `requests` depends\non it:\n\n```python {data-mdtest=\"ignore\"}\nimport requests\nimport urllib3  # error: [missing-direct-dependency]\n```\n\nAdd `urllib3` to `project.dependencies` if your code imports it directly.",
          "default": "ignore",
          "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-function-body": {
          "title": "detects a `def` written with no body in a position that needs an implementation",
          "description": "## What it does\n\nChecks for a `def` written with no body at all, in a position that needs an implementation.\n\n## Why is this bad?\n\nA `def` with no body declares a signature. The lowering fills in `: ...`, so the function exists and\nreturns `None`. That is what a declaration means in a stub file; anywhere else it is an\nimplementation that was never written, silently stood in for by one that does nothing.\n\nA body may be left out where a declaration is what the position asks for:\n\n- in a stub file\n- in an `if TYPE_CHECKING` block\n- as a member of a protocol class\n- as an `abstract def`, or an `@abstractmethod`-decorated method\n- as an overload declaration, written `@overload` or as a run of same-name `def`s\n\nAn `init(...)` may also be written without a body: what it does is store the attribute parameters it\ndeclares, and that body is built for it.\n\n## Examples\n\n```by\ndef parse(s: str) -> int  # ok: the run below makes this an overload declaration\ndef parse(s: bytes) -> int\ndef parse(s):\n    return int(s)\n\n# error: [missing-function-body]\ndef lookup() -> int\n```\n\nA function that is meant to do nothing says so with a body of its own:\n\n```by\ndef ignore(event: str): ...\n```",
          "default": "error",
          "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\n`@override`.\n\nThis rule is disabled by default. Enable it to opt in to strict `@override` enforcement for a\nproject.\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": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "missing-slot": {
          "title": "detects assignments to declared attributes without instance storage",
          "description": "## What it does\n\nChecks for assignments to declared attributes that have no matching `__slots__` entry on the class\nor its bases, and no instance dictionary to store their values.\n\n## Why is this bad?\n\nMost Python objects store their attributes in an \"instance dictionary\". Assigning to a new attribute\nadds an entry to this dictionary; deleting that attribute removes it again. Accordingly, most Python\nobjects allow for **arbitrary attributes to be set and read**. The advantage of this is that it\nallows for many dynamic features; the disadvantage is that it can be costly in terms of memory, and\ncan easily allow for typos to slip in accidentally, e.g.:\n\n```py\nclass Foo:\n    def __init__(self, x):\n        self.x = x\n\n    def update_x(self, x):\n        self.xx = x  # oops, this was meant to be the same attribute set in `__init__`,\n        # but ended up being an entirely separate one!\n```\n\nDefining `__slots__` lets a class reserve space for a fixed set of instance attributes instead.\nUnless an instance dictionary is inherited from a base class or requested by including `\"__dict__\"`\nin `__slots__`, instances of the class have no dictionary in which to store additional attributes.\nAttempting to assign to an attribute not declared in `__slots__` will often raise `AttributeError`\nat runtime if the instance has no instance dictionary.\n\n## Examples\n\n### Class definitions\n\n```python\nclass Item:\n    __slots__ = ()\n    value: int\n\n\nItem().value = 1  # error: [missing-slot]\n```\n\nIf you control the class, include the attribute in `__slots__` to make the assignment valid:\n\n```python\nclass Item:\n    __slots__ = (\"value\",)\n    value: int\n\n\nItem().value = 1\n```\n\n### Stub files\n\nStub files can use properties to indicate that instances have attributes that are readable and\nwritable but do not appear in `__slots__`, for example:\n\n```pyi\nclass Item:\n    __slots__ = ()\n    @property\n    def value(self) -> int: ...\n    @value.setter\n    def value(self, value: int) -> None: ...\n```\n\n## References\n\n- [Python data model: `__slots__`](https://docs.python.org/3/reference/datamodel.html#slots)",
          "default": "error",
          "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 type parameters being\nimplicitly filled with `Unknown`, reducing the precision of type checking. Explicit type parameters\nmake the intended types clear 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": "error",
          "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. Missing items can\nlead 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"
            }
          ]
        },
        "mutable-state-value": {
          "title": "detects a mutable value held in basedpython-ui state",
          "description": "## What it does\n\nChecks for a value that is not deeply immutable being placed in `basedpython_ui` state: the\ninitial value of `state(...)` / `State(...)`, the elements of `state_list(...)` / `StateList(...)`,\nthe value computed by `derived(...)` / `remember(...)`, a value assigned to a `State`'s `.value`,\nappended to or inserted into a `StateList`, stored into a `StateDict`, or given to `provide(...)`.\n\n## Why is this bad?\n\nA `State` notifies its readers when it is *assigned*. A change made *inside* the held value —\n`items.append(1)` on a held `list`, a field written on a held plain class — notifies nobody, so the\nui keeps showing the old value until something unrelated recomposes it. The runtime refuses such a\nvalue with a `TypeError`; this check reports it at the source.\n\nA value is deeply immutable when nothing reachable from it can change: the scalars, enum members, a\n`tuple` or `frozenset` of immutable elements, a `frozen data class` or `NamedTuple` of immutable\nfields, a type object, a callable, or one of the framework's own observables (`State`, `StateList`,\n`StateDict`, `Derived`, `Ambient`).\n\n## Examples\n\n```by\nfrom basedpython_ui import composable, state, state_list\n\nfrozen data class Todo:\n    title: str\n\n@composable\ndef App():\n    let items = state([1, 2])           # error: `list[int]` cannot be held in state\n    let names = state((1, 2))           # ok: a tuple of immutables\n    let todos = state_list([Todo(\"a\")]) # ok: an observable list of frozen records\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` at\nruntime.\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__` methods.\n\n## Why is this bad?\n\nIf a class defines a non-callable `__init_subclass__` method/attribute, any attempt to subclass that\nclass 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 overridden on\nany 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 that has been declared\nas `Final`.\n\n## Why is this bad?\n\nDeclaring a variable as `Final` indicates to the type checker that it should not be overridden on\nany 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": "error",
          "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 false 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": "error",
          "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 under the hood (`__getitem__` and `__mul__`\nrespectively). Calling 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` or `ImportError` at runtime.\n\n## Rule status\n\nThis rule is currently disabled by default because of the number of false 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": "error",
          "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 `a.b.` You\neither need to explicitly `import a.b`, or else you need the `__init__.py` file of `a` to include\n`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 false 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": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "private-constructor": {
          "title": "detects construction of a class with a `private` constructor",
          "description": "## What it does\nChecks for constructing a class whose `init` is declared `private`, from\noutside that class's own body.\n\n## Why is this bad?\nA `private` constructor says the class decides how its instances are\nmade: callers go through a factory the class provides, which can pick a\nsubclass, return a cached instance, or reject the arguments. Calling the\nconstructor directly bypasses that.\n\nA subclass is outside the class's body too, so it cannot construct the\nbase either.\n\n## Example\n\n```by\nclass Id:\n    private init(let raw: str)\n\n    @classmethod\n    def parse(cls, text: str) -> Id:\n        return Id(text.strip())  # ok: inside the class\n\nId(\"x\")  # error: `Id`'s constructor is private\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "private-export": {
          "title": "detects a `private` symbol listed in `__all__`",
          "description": "## What it does\nChecks for a `private` symbol listed in the module's `__all__`.\n\n## Why is this bad?\n`__all__` lists the module's interface, and a `private` symbol is declared\nnot to be part of it. The lowering renames the symbol with a leading\nunderscore, so `from m import *` would look up a name the module does not\nhave, and raise.\n\n## Example\n\n```by\nprivate def helper() -> int:\n    return 1\n\n__all__ = [\"helper\"]  # error: `helper` is private\n```",
          "default": "error",
          "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\nargument, or 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. Marking it as\n`ClassVar` is therefore redundant.\n\nNote that this diagnostic is not emitted for dataclass fields or protocol members, where\n`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 value it destructures,\nwith 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 parameter — binds its\ncaptures unconditionally. A pattern that does not match leaves them unbound, which is a `NameError`\nat the first use.\n\nA `let` statement can handle the failure with an `else` block, but only if the block diverges:\ncontrol 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 diverges:\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 of elements the\ntargets require.\n\n## Why is this bad?\n\n`a, b = value` binds both names unconditionally, but the unpacking only succeeds if `value` yields\nexactly two elements. A `tuple[int, ...]`, a `list[int]`, or any other iterable whose length is not\npart of its type satisfies the annotation at every length, so nothing rules out a `ValueError` at\nruntime.\n\nA starred target absorbs any number of elements, so it only requires the ones around it:\n`a, *rest = value` still needs at least one element, and reports for the same reason. A splatted\nargument is the same question against a parameter list: `f(*value)` binds the parameters\npositionally, so a length that does not match raises `TypeError` rather than `ValueError`.\n\nThree values are left alone: one whose type is `Any`, which has opted out of checking altogether;\none whose element type is `Unknown`, which ty fills in where the code said nothing at all; and an\nunannotated parameter, whose type is bounded by what its function's body asks of it — including the\nunpacking 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"
            }
          ]
        },
        "reified-without-receiver": {
          "title": "detects reads of a reified class type parameter with no receiver to read it from",
          "description": "## What it does\nChecks for a read of a reified class type parameter where nothing can\nanswer it.\n\n## Why is this bad?\nA class's type argument belongs to the *instance* that carries it, so a\nread is answered through the receiver of the method it sits in. The class\nbody itself, a method's decorators and parameter defaults, and the body of\na class nested directly in the class all run while the class is being\nbuilt, before any instance exists; a `staticmethod` runs later but is\nhanded no receiver. A read in any of those has no type argument to name.\n\n## Example\n\n```by\nclass C[T]:\n    kind = T  # error: the class body has no instance to read from\n\n    @staticmethod\n    def make():\n        return T()  # error: a static method is handed no receiver\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 from an\nenclosing 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"
            }
          ]
        },
        "silent-mutation": {
          "title": "detects an in-place mutation a basedpython-ui composition cannot observe",
          "description": "## What it does\n\nChecks for an in-place mutation written inside a `basedpython_ui` composable — in its body, in a\n`once` content block written in it, or in a handler block, lambda or nested `def` written in it: a\nmutating method call (`append`, `extend`, `insert`, `pop`, `remove`, `clear`, `sort`, `reverse`,\n`update`, `setdefault`, `popitem`, `add`, `discard`, …) on a builtin mutable container, an in-place\noperator (`+=`, `|=`, …) on one, a subscript store or delete on one, or an attribute store on an\ninstance of a class that is not frozen and not an observable.\n\nA container the same body creates itself — bound to a display, a comprehension or a constructor\ncall — is a fresh local, and mutating it is allowed.\n\n## Why is this bad?\n\nA composition re-runs when an observable it read is written. A `list` or a plain object is not\nobservable: mutating it in place changes what the ui *should* show without telling the runtime,\nso the change is not seen until something unrelated recomposes the scope. Mutate a `StateList` /\n`StateDict`, or rebuild an immutable value and assign it to a `State`, and the change notifies.\n\n## Examples\n\n```by\nfrom basedpython_ui import composable, state_list, Button\n\n@composable\ndef TodoList(items: list[str]):\n    Button(\"add\"):\n        items.append(\"x\")     # error: mutates `list[str]` in place\n\n@composable\ndef Observed():\n    let items = state_list([\"a\"])\n    Button(\"add\"):\n        items.append(\"x\")     # ok: a `StateList` write notifies its readers\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "state-write-in-composition": {
          "title": "detects a basedpython-ui state write made while composing",
          "description": "## What it does\n\nChecks for a write to `basedpython_ui` state made while a composition is running: in a composable's\nbody or in a `once` content block written in it, an assignment to a `State`'s `.value` (plain or\naugmented), a call to `State.set` / `State.update`, or a mutating call, subscript store or delete\non a `StateList` / `StateDict`.\n\nWrites made from a handler block, a lambda, a nested `def` or an effect block are not in\ncomposition: those run later, in response to an event, and are the right place for them.\n\n## Why is this bad?\n\nComposition is a pure description of the ui for the current state. A write made while composing\ninvalidates the very scope being composed (or one already composed this frame), which would loop\nor show a frame that is half old and half new. The runtime raises `CompositionError` before\napplying such a write; this check reports it at the source.\n\n## Examples\n\n```by\nfrom basedpython_ui import composable, state, Button, Text\n\n@composable\ndef Counter():\n    let count = state(0)\n    count.value = 1           # error: written while `Counter` is composing\n    Text(f\"{count.value}\")\n    Button(\"+\"):\n        count.value += 1      # ok: a handler runs after composition\n```",
          "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 for the type checker to emit an\nerror if the argument cannot be verified to 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__`) are\ngenerated that compare instances as tuples of their fields. These methods raise a `TypeError` at\nruntime when comparing instances of different classes in the inheritance hierarchy, even if one is a\nsubclass of the other.\n\nThis violates the [Liskov Substitution Principle][liskov-substitution-principle] because child class\ninstances cannot be used 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\nlimitation.\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 block and its callback disagreeing about what is passed",
          "description": "## What it does\nChecks for a trailing-lambda block and its callback disagreeing about\nwhat the call passes: a callback that takes arguments the block has no\nparameter for, and a body that reads an `it` the callback never fills.\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\nThe other direction is a callback that passes nothing. The block still\nhas its `it` parameter — the lambda the lowering writes always declares\none, so `it` inside the block always means that parameter and never an\nouter name — but a callback invoked as `fn()` leaves it at its `None`\ndefault, so reading it reads a value the call never sent.\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\ndef g(a: () -> None):\n    a()\n\ng:\n    print(it)  # error: `g`'s callback passes nothing for `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 is not the same as the\nasserted 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\nargument are unavailable.\n\n## Why is this bad?\n\nWhen `super()` is used without arguments, Python tries to find two things: the nearest enclosing\nclass and the first argument of the immediately enclosing function (typically self or cls). If\neither 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 to any enclosing generic\ncontext.\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": "error",
          "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"
            }
          ]
        },
        "unmet-module-api": {
          "title": "detects a module that does not answer an interface it is obliged to",
          "description": "## What it does\nChecks a module against the interfaces it is obliged to answer, whether it\ndeclared one itself with `implements` or a package it lives in imposed one\nwith `implements ... for`.\n\n## Why is this bad?\nA module that is meant to be used through an interface — a plugin, a\nbackend, a settings module — is otherwise only checked where something\nassigns it to an interface-typed place. A plugin loaded by name is never\nchecked at all, and an error that does surface lands on the consumer\nrather than on the module that broke.\n\n## Example\n\n```by\nprotocol Backend:\n    static def connect(url: str) -> None\n\nimplements Backend  # error: this module does not answer `Backend`\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unobservable-dependency": {
          "title": "detects a basedpython-ui composition reading a value it cannot observe",
          "description": "## What it does\n\nChecks for a read, made while a `basedpython_ui` composition runs, of a value it cannot observe:\na load of a parameter of the composable (a `context` parameter included), of a module global, or\nof a local captured from an enclosing function, whose type is neither deeply immutable nor one of\nthe framework's observables (`State`, `StateList`, `StateDict`, `Derived`, `Ambient`).\n\nWhat runs while composing is the composable's body, the `once` content blocks and `local` blocks\nwritten in it, and the lambda given to `derived(...)` / `remember(...)`. A handler block, a lambda,\na nested `def` or an effect block runs later, so a read there is not a dependency of the\ncomposition. A name the composition binds itself — a local of the body or of a block, a `for`\ntarget, a comprehension variable — is this run's own value and is not reported, whatever its\ntype; a `dynamic` value is exempt, as everywhere. A read-only view (`list[out str]`) is reported\nlike a plain `list`: it restricts this reader, not the other holders of the list.\n\n## Why is this bad?\n\nA mutation of non-observable data is never a trigger: an immutable value cannot change, an\nobservable notifies its readers when it does, and a mutable value changes without telling anyone.\nA composition that reads a mutable parameter or global therefore shows a stale ui after any change\nto it — wherever that change is made: another module, a `.py` caller, a `dynamic` value, a\ncallback. `silent-mutation` reports the writes it can see; this check is what makes the guarantee\ngeneral, by keeping a composition from depending on such a value in the first place.\n\nHold the value in state (`state_list`, `state_dict`), pass an immutable value (a `tuple`, a\n`frozen data class`), or read it only in a handler.\n\n## Examples\n\n```by\nfrom basedpython_ui import composable, state_list, Text\n\n@composable\ndef Names(items: list[str]):\n    Text(str(len(items)))       # error: read while `Names` composes, but nothing observes it\n\n@composable\ndef Frozen(items: tuple[str, ...]):\n    Text(str(len(items)))       # ok: a tuple cannot change\n\n@composable\ndef Held():\n    let items = state_list([\"a\"])\n    Text(str(len(items)))       # ok: a `StateList` notifies its readers\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. An unresolved attribute is\nnot guaranteed to exist from the type alone, so this could also indicate that the object is not of\nthe 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 bindings or\ndeclarations 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 it hard\nfor static analysis tools to infer the types of globals without explicit definitions or\ndeclarations.\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` at 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-assignment": {
          "title": "detects assignments that unsoundly assign a type that is not a subtype of the declared type",
          "description": "## What it does\n\nDetects variable assignments that unsoundly assign a type that is not a [subtype] of a variable's\ndeclared type.\n\nThis rule is a stricter version of `invalid-assignment`. Whereas that rule also flags assignments to\nattributes and subscripts, however, this rule is only applied to variable assignments.\n\nThis rule has no effect on stub files.\n\n## Why is this bad?\n\nBy default, type checkers consider an assignment valid if the inferred type of the assigned value is\n[assignable] to the target's declared type. However, this makes it easy for incorrect types to\npercolate through your code unexpectedly due to a single expression being inferred as `Any`. This\ncan easily lead to runtime errors that are not caught by the type checker:\n\n```py\nfrom typing import Any\n\n\ndef returns_any() -> Any:\n    return \"not an integer\"\n\n\n# error: \"Unsound assignment: `Any` is not a subtype of `int`\"\nmy_integer: int = returns_any()\n\n# Fails at runtime, even though the type checker infers both operands as being of type `int`!\nmy_integer + 42\n```\n\nThis rule treats [\"fully static\"][fully-static] declared types as \"typed boundaries\" for your code.\nWith this rule enabled, ty would emit an error on the `my_integer: int = returns_any()` assignment,\nsince the `returns_any()` call is inferred as having type `Any`, and `Any` is not a subtype of\n`int`. This helps prevent the unsoundness from spreading far from its original source (in this case,\nthe return type of the `returns_any` function).\n\nNote that this rule is only applied to assignments where the declared type is\n[fully static][fully-static]. It will not trigger if `Any` or `Unknown` appear anywhere in the\ndeclared type, either implicitly or explicitly:\n\n```py\nfrom typing import Any\n\n\ndef returns_any() -> Any:\n    return \"not an integer\"\n\n\nexplicitly_dynamic: Any = returns_any()  # no error\nalso_dynamic: list[Any] = returns_any()  # no error\n\n# no `unsound-assignment` error, since `list` is implicitly the same as `list[Unknown]`\n# (which is what the `missing-type-argument` error is complaining about)\n#\n# error: [missing-type-argument]\nimplicitly_dynamic: list = returns_any()\n```\n\nThis rule works especially well when combined with ty's `missing-type-argument` rule.\n\n## Examples\n\n```py\nfrom typing import Any\n\n\ndef returns_any() -> Any:\n    return 42\n\n\n# error: \"Unsound assignment: `Any` is not a subtype of `int`\"\nmy_integer: int = returns_any()\n\nanother_integer: int\n\n# error: \"Unsound assignment: `Any` is not a subtype of `int`\"\nanother_integer = returns_any()\n```\n\nNarrow the value before assigning it to fix the diagnostics:\n\n```py\nfrom typing import Any\n\n\ndef returns_any() -> Any:\n    return 42\n\n\nvalue = returns_any()\nassert isinstance(value, int)\nmy_integer: int = value  # 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-return-statement` is a similar rule that triggers on unsound `return` statements rather\n    than unsound assignments\n- `unsound-yield` is a similar rule that triggers on unsound `yield` expressions rather than unsound\n    assignments\n\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"
            }
          ]
        },
        "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 in\n`returns_int`, since the `returns_any()` call is inferred as having type `Any`, and `Any` is not a\nsubtype of `int`. This helps prevent the unsoundness from spreading far from its original source (in\nthis case, the return type of the `returns_any` function).\n\nNote that this rule is only applied to functions annotated as returning [fully static][fully-static]\ntypes. It will not trigger if `Any` or `Unknown` appear anywhere in your return type, either\nimplicitly 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 `missing-type-argument` and\n`unsound-assignment` rules, as well as the Ruff rules [`ANN201`][ann201], [`ANN202`][ann202],\n[`ANN204`][ann204], [`ANN205`][ann205], and [`ANN206`][ann206]. Enabling all these rules at once\neffectively makes it much less likely that a `return` statement can lead to unsoundness \"leaking\"\nout of a function unless that function has been *explicitly* annotated with a dynamic type in some\nway (`-> 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\n    `return` statements\n- `unsound-assignment` is a similar rule that triggers on unsound assignments\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 makes it easy for incorrect types to percolate\nthrough your code unexpectedly due to a single expression being inferred as `Any`. This can easily\nlead to runtime errors that are not caught by the 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.\nWith this rule enabled, ty would emit an error on the `yield returns_any()` statement in `integers`,\nsince the `returns_any()` call is inferred as having type `Any`, and `Any` is not a subtype of\n`int`. This helps prevent the unsoundness from spreading far from its original source (in this case,\nthe return type of the `returns_any` function).\n\nNote that this rule is only applied to functions annotated as yielding [fully static][fully-static]\ntypes. It will not trigger if `Any` or `Unknown` appear anywhere in your function's yield type,\neither implicitly or explicitly. It will still trigger on functions that have non-fully-static send\nand/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    # no error\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 `missing-type-argument` and\n`unsound-assignment` rules, as well as the Ruff rules [`ANN201`][ann201], [`ANN202`][ann202],\n[`ANN204`][ann204], [`ANN205`][ann205], and [`ANN206`][ann206]. Enabling all these rules at once\neffectively makes it much less likely that a `yield` expression can lead to unsoundness \"leaking\"\nout of a function unless that function has been *explicitly* annotated with a dynamic type in some\nway (`-> 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\n    than unsound `yield` expressions\n- `unsound-assignment` is a similar rule that triggers on unsound assignments\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 reified generics used without their 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, and a reified generic\n*class* records its type arguments on the specialization its instances\nare built from. Either is legal without writing the step only when the\ntranspiler can inject it — every type parameter must solve, from the\narguments or its PEP 696 default, to a type with a runtime spelling\nthere. Otherwise the parameter has no value 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\nclass A[T]:\n    def kind(self) -> type[T]:\n        return T\n\na: A[int] = A()  # ok — transpiles to A[int]()\nA()              # error: nothing says which specialization this is\n```",
          "default": "error",
          "oneOf": [
            {
              "$ref": "#/definitions/Level"
            }
          ]
        },
        "unstable-parameter": {
          "title": "detects a composable parameter whose type is not stable",
          "description": "## What it does\n\nChecks for a parameter of a `basedpython_ui` composable whose declared type is not *stable*:\nnot deeply immutable, and not a read-only view of immutable elements (`list[out int]`).\n\n## Why is this bad?\n\nA composable is skipped on recomposition only when every argument is stable and equal to the last\none. A `list`, `dict`, `set` or non-frozen class can be changed behind the composable's back, so the\nruntime cannot compare it and never skips the scope: the composable re-runs on every recomposition\nof its parent, however little changed. Prefer an immutable spelling (`tuple[int, ...]`, a\n`frozen data class`) or an observable (`state_list`, `state_dict`).\n\nThis is a warning about skipping alone: a mutable parameter that only a handler touches never\ntriggers a re-render, but does not make the composition stale on its own. Reading one while\ncomposing is what does that, and is reported as an `unobservable-dependency`. A read-only view\n(`list[out int]`) is stable for skipping — the runtime compares it structurally at recomposition —\nbut is still unobservable when read, so it is not the spelling to reach for.\n\n## Examples\n\n```by\nfrom basedpython_ui import composable, StateList\n\n@composable\ndef TodoList(items: list[int]): ...        # warning: never skipped\n\n@composable\ndef Skippable(items: tuple[int, ...]): ...  # ok\n\n@composable\ndef Observed(items: StateList[int]): ...   # ok: an observable handle\n```",
          "default": "warn",
          "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, ty will not be\nable to resolve the [method resolution order] (MRO) for the class. This will lead to an inferior\nunderstanding of your codebase and unpredictable type-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, using the object\nin 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 which are unsupported by ty.\n\nThis is equivalent to `unsupported-base` but applies to classes created via `type()` rather than\n`class` statements.\n\n## Why is this bad?\n\nIf a dynamically created class has a base that is an unsupported type such as `type[T]`, ty will not\nbe able to resolve the [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, and may be noisy on\ncodebases 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": "warn",
          "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 the operands don't support\nthe operator.\n\n## Why is this bad?\n\nAttempting to use an unsupported operator will raise a `TypeError` at runtime.\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"
            }
          ]
        },
        "unusable-resource-key": {
          "title": "detects a key in a static resource that python cannot name",
          "description": "## What it does\n\nChecks for keys in an imported static resource that python cannot name.\n\n## Why is this bad?\n\nA static resource is read through attributes, so a key that is not a valid python identifier —\n`build-backend`, `class`, `2` — has no attribute to be read through, and is left out of the value\nthe import binds. The document still holds it; nothing in the program can reach it.\n\nNames with two leading underscores are left out for the same reason: python mangles `__x` inside a\nclass body, so the attribute the reader would write is not the one that would exist.\n\n## Examples\n\n`data/project.json`:\n\n```json\n{ \"build-backend\": \"hatchling.build\", \"root\": \".\" }\n```\n\n`main.by`:\n\n```by\n# error: [unusable-resource-key]\nimport \"data/project.json\" as project\n\nreveal_type(project.root)  # revealed: \".\"\n```",
          "default": "warn",
          "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 statements without being\nawaited.\n\n## Why is this bad?\n\nCalling an `async def` function returns a coroutine object. If the coroutine is never awaited, the\nbody of the async function will never execute, 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 included by\nmistake, 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\n[`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-return-value": {
          "title": "detects a call whose result is thrown away",
          "description": "## What it does\nChecks for a call, written as a statement of its own, whose result is\nthrown away.\n\n## Why is this bad?\nA call on a line of its own keeps whatever the call did on the way to its\nanswer, and discards the answer. For most functions that is a mistake:\n`text.strip()` on its own line reads as if it strips `text`, and strips\nnothing — `str` is immutable, and the stripped string was the result.\n\nA function whose result really is optional says so with\n`@ignorable_return_value`, and a member of a class that says so says\notherwise with `@must_use_return_value`. A function returning `None` has\nno result to discard and is never reported.\n\n## Examples\n```python\ndef parse(text: str) -> int: ...\ndef log(message: str) -> None: ...\n\nparse(\"1\")      # warning: the parsed number goes nowhere\nlog(\"started\")  # ok — nothing was returned\n```\n\n```by\n@ignorable_return_value\ndef prime_cache(key: str) -> bytes: ...\n\nprime_cache(\"k\")  # ok — the call was for the caching\n```",
          "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 included by\nmistake, 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\n[`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 by the\nimplementation function that follows the series of overloads. While it is not illegal to provide a\nbody for an `@overload`-decorated function, it may indicate a misunderstanding of how the\n`@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 types where\nthe operation is known to fail. A custom `__getitem__` implementation can accept or reject such a\nslice, 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
    },
    "TypeCheckingPreset": {
      "description": "the set of defaults a project's rules and analysis settings start from",
      "oneOf": [
        {
          "title": "Strict",
          "description": "Every diagnostic is enabled, and every analysis option that buys soundness is on.",
          "type": "string",
          "const": "strict"
        },
        {
          "title": "Ty compatible",
          "description": "The defaults of [ty](https://github.com/astral-sh/ty), which basedpython is built on.\nbasedpython's own diagnostics and analysis options are off, so that a project reports\nwhat ty itself would report.",
          "type": "string",
          "const": "ty-compatible"
        }
      ]
    },
    "string": {
      "type": "string"
    }
  }
}