State the Build Profile's CI Type Check as the Validator Runs It

.agents/skills/python-codestyle/SKILL.md

@@ -33,7 +33,8 @@ Then read the `pyproject.toml` shape and pick the profile before running Python
 - **build** (Project): third-party runtime dependencies, or the repo's deliverable. Either a uv
   project (`[project]` + `[build-system]` + committed `uv.lock`, run with `uv run`) or a
   `pyproject.toml` beside a `requirements*.txt` and no `uv.lock`, installed with pip. Uses pytest,
-  and pyright strict, mypy with its strict flags, or both as the CI type checker.
+  and pyright strict or mypy with its strict flags as the CI type checker. A repo enforcing
+  pyright beside mypy runs pyright itself, per Toolchain below.
 - **lint-only** (Scripts): no `[project]`, no `[build-system]`, no lockfile, no `requirements*.txt`
   (the hub validator runs pytest wherever one sits). Uses `uvx` for third-party tools, unittest
   for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
@@ -76,7 +77,10 @@ than one checker is normal when each serves a purpose (the .NET side pairs CShar
 `mypy --strict` because the platinum `strict-typing` quality-scale tier requires it, and a
 pydantic-heavy library may opt in for the plugin. When a repo uses mypy it runs in CI and the
 editor (the `ms-python.mypy-type-checker` extension) so the two stay consistent, and its mypy
-command joins the clean-compile. mypy may also be a build repo's only CI checker, run with its
+command joins the clean-compile. The hub validator runs at most one checker in each Python
+directory, mypy where both are configured. A repo enforcing pyright beside mypy runs pyright from
+its own `.github/actions/validate/action.yml` hook. That hook starts from a bare checkout, so it
+sets up its own Python environment. mypy may also be a build repo's only CI checker, run with its
 strict flags, and Pylance's pyright diagnostics are then advisory, since CI never runs them. A
 pyright-only repo is the lightest and is inherently consistent, since the editor and CI run one
 engine.
@@ -101,9 +105,13 @@ uv build                         # produce wheel + sdist in ./dist (published pa
 ```
 
 The **build**-profile Python clean-compile, in its uv form, is `uv run ruff format` +
-`uv run ruff check` + the repo's type checker: `uv run pyright`, or `uv run mypy src` where mypy is
-the CI checker, or both where the repo runs both (see Type checking above). Run it, plus
-`uv run pytest`, before committing.
+`uv run ruff check` + the repo's type checker. That checker is `uv run pyright`, or `uv run mypy`
+where mypy is the CI checker, or both where the repo runs both (see Type checking above). Where the
+config sits in the project directory, CI passes the checker no path, so the config's own target
+settings decide what is checked. mypy left with no target that way exits with an error. A declared
+subdirectory with no config of its own uses the repository root's instead. CI then runs the checker
+from the root with the directory as its path, `uv run --project <dir> <checker> <dir>`, so run it
+the same way. Run the clean-compile, plus `uv run pytest`, before committing.
 
 A **build**-profile directory in its pip form builds its environment the way CI does, through uv's
 pip interface, which writes no `uv.lock`. It installs every `requirements*.txt` in one command, since
@@ -225,10 +233,10 @@ Before pushing or opening a PR:
 - VS Code's Problems pane should be quiet for the files you touched. The relevant linters are ruff
   (via the `charliermarsh.ruff` extension) and pyright (via the `ms-python.python` extension's
   bundled Pylance).
-- The **build**-profile CI gate, in its uv form, is `uv run ruff check`,
-  `uv run ruff format --check`, the repo's type checker (`uv run pyright` or `uv run mypy src`), and
-  `uv run pytest`, the same commands as the local loop above, run from the Python project directory
-  (invoked as separate steps, not `&&`-chained, so the runner shell is irrelevant). The pip form's
+- The **build**-profile CI gate, in its uv form, runs the local loop's commands above, each from
+  where that loop runs it. Those are `uv run ruff check`, `uv run ruff format --check`, the repo's
+  type checker, and `uv run pytest`. CI invokes them as separate steps, not `&&`-chained, so the
+  runner shell is irrelevant. The pip form's
   CI gate is its commands in the local loop above, and a **lint-only** profile's is its `uvx`
   equivalents plus its `unittest` suite, each per `references/profiles.md`. The local loop names
   what CI relaxes for an undeclared root.

.agents/skills/python-codestyle/references/profiles.md

@@ -9,7 +9,8 @@ than copying verbatim (a verbatim copy that misdescribes the repo is inaccurate
 in review). The axes that commonly vary per repo:
 
 - **Type checker in CI**: pyright strict, mypy with its strict flags (run in CI and the editor, with
-  pyright kept editor-only through Pylance), or both. The clean-compile runs every checker CI runs.
+  pyright kept editor-only through Pylance), or both. A repo running both runs pyright itself,
+  per `SKILL.md` "Toolchain". The clean-compile runs every checker CI runs.
 - **Dependency declaration**: the uv form declares the dev tools CI runs in the `dev` group of
   `[dependency-groups]`, the one group a plain local `uv sync` or `uv run` installs, and which CI's
   `uv sync --all-groups --frozen` installs too, since it takes every group and no extra. PEP 621

.claude-plugin/fleet-skills/.source-digests/python-codestyle

@@ -1 +1 @@
-29f1d243d1548ec9
+9c5b651ffcf53d3c

.claude-plugin/fleet-skills/skills/python-codestyle/SKILL.md

@@ -33,7 +33,8 @@ Then read the `pyproject.toml` shape and pick the profile before running Python
 - **build** (Project): third-party runtime dependencies, or the repo's deliverable. Either a uv
   project (`[project]` + `[build-system]` + committed `uv.lock`, run with `uv run`) or a
   `pyproject.toml` beside a `requirements*.txt` and no `uv.lock`, installed with pip. Uses pytest,
-  and pyright strict, mypy with its strict flags, or both as the CI type checker.
+  and pyright strict or mypy with its strict flags as the CI type checker. A repo enforcing
+  pyright beside mypy runs pyright itself, per Toolchain below.
 - **lint-only** (Scripts): no `[project]`, no `[build-system]`, no lockfile, no `requirements*.txt`
   (the hub validator runs pytest wherever one sits). Uses `uvx` for third-party tools, unittest
   for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
@@ -76,7 +77,10 @@ than one checker is normal when each serves a purpose (the .NET side pairs CShar
 `mypy --strict` because the platinum `strict-typing` quality-scale tier requires it, and a
 pydantic-heavy library may opt in for the plugin. When a repo uses mypy it runs in CI and the
 editor (the `ms-python.mypy-type-checker` extension) so the two stay consistent, and its mypy
-command joins the clean-compile. mypy may also be a build repo's only CI checker, run with its
+command joins the clean-compile. The hub validator runs at most one checker in each Python
+directory, mypy where both are configured. A repo enforcing pyright beside mypy runs pyright from
+its own `.github/actions/validate/action.yml` hook. That hook starts from a bare checkout, so it
+sets up its own Python environment. mypy may also be a build repo's only CI checker, run with its
 strict flags, and Pylance's pyright diagnostics are then advisory, since CI never runs them. A
 pyright-only repo is the lightest and is inherently consistent, since the editor and CI run one
 engine.
@@ -101,9 +105,13 @@ uv build                         # produce wheel + sdist in ./dist (published pa
 ```
 
 The **build**-profile Python clean-compile, in its uv form, is `uv run ruff format` +
-`uv run ruff check` + the repo's type checker: `uv run pyright`, or `uv run mypy src` where mypy is
-the CI checker, or both where the repo runs both (see Type checking above). Run it, plus
-`uv run pytest`, before committing.
+`uv run ruff check` + the repo's type checker. That checker is `uv run pyright`, or `uv run mypy`
+where mypy is the CI checker, or both where the repo runs both (see Type checking above). Where the
+config sits in the project directory, CI passes the checker no path, so the config's own target
+settings decide what is checked. mypy left with no target that way exits with an error. A declared
+subdirectory with no config of its own uses the repository root's instead. CI then runs the checker
+from the root with the directory as its path, `uv run --project <dir> <checker> <dir>`, so run it
+the same way. Run the clean-compile, plus `uv run pytest`, before committing.
 
 A **build**-profile directory in its pip form builds its environment the way CI does, through uv's
 pip interface, which writes no `uv.lock`. It installs every `requirements*.txt` in one command, since
@@ -225,10 +233,10 @@ Before pushing or opening a PR:
 - VS Code's Problems pane should be quiet for the files you touched. The relevant linters are ruff
   (via the `charliermarsh.ruff` extension) and pyright (via the `ms-python.python` extension's
   bundled Pylance).
-- The **build**-profile CI gate, in its uv form, is `uv run ruff check`,
-  `uv run ruff format --check`, the repo's type checker (`uv run pyright` or `uv run mypy src`), and
-  `uv run pytest`, the same commands as the local loop above, run from the Python project directory
-  (invoked as separate steps, not `&&`-chained, so the runner shell is irrelevant). The pip form's
+- The **build**-profile CI gate, in its uv form, runs the local loop's commands above, each from
+  where that loop runs it. Those are `uv run ruff check`, `uv run ruff format --check`, the repo's
+  type checker, and `uv run pytest`. CI invokes them as separate steps, not `&&`-chained, so the
+  runner shell is irrelevant. The pip form's
   CI gate is its commands in the local loop above, and a **lint-only** profile's is its `uvx`
   equivalents plus its `unittest` suite, each per `references/profiles.md`. The local loop names
   what CI relaxes for an undeclared root.

.claude-plugin/fleet-skills/skills/python-codestyle/references/profiles.md

@@ -9,7 +9,8 @@ than copying verbatim (a verbatim copy that misdescribes the repo is inaccurate
 in review). The axes that commonly vary per repo:
 
 - **Type checker in CI**: pyright strict, mypy with its strict flags (run in CI and the editor, with
-  pyright kept editor-only through Pylance), or both. The clean-compile runs every checker CI runs.
+  pyright kept editor-only through Pylance), or both. A repo running both runs pyright itself,
+  per `SKILL.md` "Toolchain". The clean-compile runs every checker CI runs.
 - **Dependency declaration**: the uv form declares the dev tools CI runs in the `dev` group of
   `[dependency-groups]`, the one group a plain local `uv sync` or `uv run` installs, and which CI's
   `uv sync --all-groups --frozen` installs too, since it takes every group and no extra. PEP 621

.github/skills/python-codestyle/SKILL.md

@@ -33,7 +33,8 @@ Then read the `pyproject.toml` shape and pick the profile before running Python
 - **build** (Project): third-party runtime dependencies, or the repo's deliverable. Either a uv
   project (`[project]` + `[build-system]` + committed `uv.lock`, run with `uv run`) or a
   `pyproject.toml` beside a `requirements*.txt` and no `uv.lock`, installed with pip. Uses pytest,
-  and pyright strict, mypy with its strict flags, or both as the CI type checker.
+  and pyright strict or mypy with its strict flags as the CI type checker. A repo enforcing
+  pyright beside mypy runs pyright itself, per Toolchain below.
 - **lint-only** (Scripts): no `[project]`, no `[build-system]`, no lockfile, no `requirements*.txt`
   (the hub validator runs pytest wherever one sits). Uses `uvx` for third-party tools, unittest
   for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
@@ -76,7 +77,10 @@ than one checker is normal when each serves a purpose (the .NET side pairs CShar
 `mypy --strict` because the platinum `strict-typing` quality-scale tier requires it, and a
 pydantic-heavy library may opt in for the plugin. When a repo uses mypy it runs in CI and the
 editor (the `ms-python.mypy-type-checker` extension) so the two stay consistent, and its mypy
-command joins the clean-compile. mypy may also be a build repo's only CI checker, run with its
+command joins the clean-compile. The hub validator runs at most one checker in each Python
+directory, mypy where both are configured. A repo enforcing pyright beside mypy runs pyright from
+its own `.github/actions/validate/action.yml` hook. That hook starts from a bare checkout, so it
+sets up its own Python environment. mypy may also be a build repo's only CI checker, run with its
 strict flags, and Pylance's pyright diagnostics are then advisory, since CI never runs them. A
 pyright-only repo is the lightest and is inherently consistent, since the editor and CI run one
 engine.
@@ -101,9 +105,13 @@ uv build                         # produce wheel + sdist in ./dist (published pa
 ```
 
 The **build**-profile Python clean-compile, in its uv form, is `uv run ruff format` +
-`uv run ruff check` + the repo's type checker: `uv run pyright`, or `uv run mypy src` where mypy is
-the CI checker, or both where the repo runs both (see Type checking above). Run it, plus
-`uv run pytest`, before committing.
+`uv run ruff check` + the repo's type checker. That checker is `uv run pyright`, or `uv run mypy`
+where mypy is the CI checker, or both where the repo runs both (see Type checking above). Where the
+config sits in the project directory, CI passes the checker no path, so the config's own target
+settings decide what is checked. mypy left with no target that way exits with an error. A declared
+subdirectory with no config of its own uses the repository root's instead. CI then runs the checker
+from the root with the directory as its path, `uv run --project <dir> <checker> <dir>`, so run it
+the same way. Run the clean-compile, plus `uv run pytest`, before committing.
 
 A **build**-profile directory in its pip form builds its environment the way CI does, through uv's
 pip interface, which writes no `uv.lock`. It installs every `requirements*.txt` in one command, since
@@ -225,10 +233,10 @@ Before pushing or opening a PR:
 - VS Code's Problems pane should be quiet for the files you touched. The relevant linters are ruff
   (via the `charliermarsh.ruff` extension) and pyright (via the `ms-python.python` extension's
   bundled Pylance).
-- The **build**-profile CI gate, in its uv form, is `uv run ruff check`,
-  `uv run ruff format --check`, the repo's type checker (`uv run pyright` or `uv run mypy src`), and
-  `uv run pytest`, the same commands as the local loop above, run from the Python project directory
-  (invoked as separate steps, not `&&`-chained, so the runner shell is irrelevant). The pip form's
+- The **build**-profile CI gate, in its uv form, runs the local loop's commands above, each from
+  where that loop runs it. Those are `uv run ruff check`, `uv run ruff format --check`, the repo's
+  type checker, and `uv run pytest`. CI invokes them as separate steps, not `&&`-chained, so the
+  runner shell is irrelevant. The pip form's
   CI gate is its commands in the local loop above, and a **lint-only** profile's is its `uvx`
   equivalents plus its `unittest` suite, each per `references/profiles.md`. The local loop names
   what CI relaxes for an undeclared root.

.github/skills/python-codestyle/references/profiles.md

@@ -9,7 +9,8 @@ than copying verbatim (a verbatim copy that misdescribes the repo is inaccurate
 in review). The axes that commonly vary per repo:
 
 - **Type checker in CI**: pyright strict, mypy with its strict flags (run in CI and the editor, with
-  pyright kept editor-only through Pylance), or both. The clean-compile runs every checker CI runs.
+  pyright kept editor-only through Pylance), or both. A repo running both runs pyright itself,
+  per `SKILL.md` "Toolchain". The clean-compile runs every checker CI runs.
 - **Dependency declaration**: the uv form declares the dev tools CI runs in the `dev` group of
   `[dependency-groups]`, the one group a plain local `uv sync` or `uv run` installs, and which CI's
   `uv sync --all-groups --frozen` installs too, since it takes every group and no extra. PEP 621