Promote the pr_review.py Wait Rework, the Semicolon Gate Fix, and Doc Corrections to Main

.agents/skills/backlog-burndown/SKILL.md

@@ -170,9 +170,11 @@ for, and it binds harder than any throughput target.
   invisible to the round that has to respect it, and recording it on the issue is what makes the
   next bullet a read of durable state rather than of the orchestrator's memory.
 - **Verify the prediction before dispatching**, against everything in flight, which is wider than
-  this round: the files changed by every open **feature** pull request on this repository (`gh pr
-  diff <number> --name-only` per open pull request), and the claim comments of every group still
-  holding a branch, parked groups from earlier rounds included. `git worktree list` reports the
+  this round: the files changed by every open **feature** pull request on this repository, and the
+  claim comments of every group still holding a branch, parked groups from earlier rounds included.
+  `gh pr list --state open --limit 1000 --json number,baseRefName,headRefName,isCrossRepository --jq '.[] | select(.headRefName != "develop" or .baseRefName != "main" or .isCrossRepository) | .number'`
+  lists the open pull requests, its filter applying the promotion exclusion below.
+  `gh pr diff <number> --name-only` then reads each one's files. `git worktree list` reports the
   registered worktrees and the branch checked out in each, which is not the same as every branch
   that exists, so pair it with `git branch -r`, after `git fetch --prune origin`, for one that was
   pushed and whose worktree is already gone, and with `git branch` for one that was never pushed

.agents/skills/check-this-repo/SKILL.md

@@ -35,7 +35,9 @@ repo.
    content in the first place, and no amount of re-reading `GOVERNANCE.md` fixes that. For a
    Claude Code session, read `live` as well, since that channel loads the registered directory in
    place rather than the copy. A registered directory that is missing is an answer there whatever
-   the exit code says.
+   the exit code says. So is a `live.plugin` reading `installed: false` or `enabled: false`, which
+   describes the user-scope install the installer makes, as Claude Code reports it for the
+   directory the report runs in, and a project-level install does not count. A null there means the plugin listing could not be read.
    - Where `live` carries `vcs: archive`, the channel serves the tree the hub's
      `host-setup/bootstrap.sh` or `bootstrap.ps1` keeps, which has no git, so `branch: null` there
      is not a detached checkout. A `live.commit` behind the hub's `main` is the answer, and so is
@@ -69,13 +71,13 @@ per the hub's `RESYNC.md` by this repo's own session or by `resync-a-repo` from
 
 ## Refresh cadence
 
-Re-run the installer from a hub checkout on a freshly fetched `main` when `--report` exits
-non-zero, and after any promotion to `main` that touches `.agents/skills/`. A copy taken from
-`develop` reads not current by design, since the snapshot is judged against the promoted
-revision. Session entry runs no automatic check, by design: the trigger is suspicion,
-and the restated-rule symptom below is the loudest form of it. `docs/host-setup.md`
-"Fleet Skills Install" in the hub states the same cadence for the host side, and an automated
-refresh stays out of scope until the fleet has evidence the manual cadence fails.
+This skill refreshes only when `--report` exits non-zero, and only with the `--snapshot-only` run
+above, from its own freshly fetched `main` checkout. A copy taken from `develop` reads not current
+by design, since the snapshot is judged against the promoted revision. Session entry runs no
+automatic check, by design. The trigger is suspicion, and the restated-rule symptom this skill
+triggers on is the loudest form of it. The refresh from the maintainer's own long-lived hub
+checkout is a different run, and `docs/host-setup.md` "Fleet Skills Install" in the hub states its
+cadence.
 
 ## What it escalates instead of touching
 

.agents/skills/comment-and-doc-style/SKILL.md

@@ -322,7 +322,8 @@ silent pass, a letter of a recorded name excepted per the bullet below.
   before using it. A letter of a recorded name is the one exception, per the bullet above.
 - **No semicolon in agent-authored prose.** Recast a mid-sentence semicolon as a comma or as two
   sentences. A semicolon separating items in a list that already contains commas, or a statement
-  terminator in code, is unaffected.
+  terminator in code, is unaffected. A single semicolon separates such a list only between two
+  labeled items, as in `Inputs: a, b; outputs: c`, and a list item's bold opening label is not one.
 - **No spaced hyphen joining or interrupting a sentence** (` - `, or the paired aside ` - x - `).
   Recast as a comma, two sentences, or parentheses. A hyphen inside a compound word, a leading
   list marker, a range, and the `- **Label** - explanation` bullet separator are unaffected.

.agents/skills/comment-and-doc-style/references/line-endings.md

@@ -113,8 +113,10 @@ JSONC (it has `//` comments), so strip them before JSON-parsing it.
 
 Editing CRLF files programmatically with a regex has a sharper trap: `.` matches `\r`, so a
 captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. A text-mode
-rewrite has the mirror failure, silently flattening CRLF to LF. Prefer line-based edits
-(`splitlines(keepends=True)`) or literal replacement over regex reassembly. In Python the
-text-mode failure is the default: `Path.read_text()` decodes through universal newlines and
-`write_text()` writes `\n` back, so a read-edit-write round trip flattens the whole file while the
-edit itself looks correct. Pass `newline=''` to both, or work in bytes.
+rewrite has the mirror failure, silently rewriting every line ending to the host's own. Prefer
+line-based edits (`splitlines(keepends=True)`) or literal replacement over regex reassembly. In
+Python the text-mode failure is the default. `Path.read_text()` decodes through universal
+newlines, and `write_text()` translates each `\n` to `os.linesep`. A read-edit-write round trip
+therefore rewrites every ending in the file while the edit itself looks correct. Work in bytes, or
+use `open()` with `newline=''` on both the read and the write. `Path.read_text()` is no substitute,
+since it accepts `newline` only on Python 3.13 and newer and raises `TypeError` below 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
@@ -125,8 +133,12 @@ uvx ruff@latest format --check            # verify format clean
 Its type checker runs against that environment. mypy runs as `.venv/bin/python -m mypy` where the
 environment installs it, and otherwise as `uvx mypy@latest --python-executable .venv/bin/python`,
 adding `--python-version` with the environment's version unless the mypy config pins one. pyright
-runs as `uvx pyright@latest --pythonpath .venv/bin/python`. On Windows the environment's interpreter
-is `.venv\Scripts\python.exe` instead. Those ruff commands and that type checker are the pip form's
+runs as `uvx pyright@latest --pythonpath .venv/bin/python`. Where the config sits in the project
+directory, CI runs the checker there with no path, as in the uv form. 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 and the interpreter as `<dir>/.venv/bin/python`. Run it the same
+way, as in `<dir>/.venv/bin/python -m mypy <dir>`. On Windows each interpreter path ends in
+`.venv\Scripts\python.exe` instead. Those ruff commands and that type checker are the pip form's
 clean-compile, run with pytest before committing.
 
 A **lint-only** profile's clean-compile substitutes its `uvx` and `unittest` equivalents, per Two
@@ -225,10 +237,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

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

@@ -70,8 +70,8 @@ depend on Python either. Everything else is Python, with a test under its own sc
 - **`shellcheck` clean, and a deliberate exception carries its reason inline.** A
   `# shellcheck disable=SCxxxx` names why the rule does not apply here, so the next reader can
   tell a considered exception from an unread warning. The hub's own `repo-config/configure.sh` is
-  the worked example, carrying `SC2016` disables where a single-quoted `jq` program must stay
-  unexpanded, each with its reason on the same line.
+  the worked example. Its `SC2016` disables sit only where shellcheck flags a single-quoted `jq`
+  program or GraphQL query that must stay unexpanded. Each carries its reason on the same line.
 - **Comments say why, never what.** The code states what it does. A comment restating it goes
   stale silently, where a comment carrying a reason fails visibly when the reason stops being
   true.

.agents/skills/skill-lifecycle/SKILL.md

@@ -32,7 +32,7 @@ A skill surfaces at a trigger moment. A rule that binds every action all the tim
 5. **Apply the doc-packaging pattern below in the same change** when the skill packages a law doc or one of its sections.
 6. **Regenerate and commit all trees together**: `python3 scripts/build_dist.py`, then, once authorized, commit the source and both generated trees in one commit, per `git-commit-conventions`. CI runs `--check` on every pull request and fails a desynced distribution. `python3 tests/test_build_dist.py` covers the generator itself.
 7. **Record the surfacing**: annotate the `AGENTS.md` "Where the Rules Live" row when the skill packages a GOVERNANCE section, or its closing paragraph when the skill is new content, so the map stays the one place coverage is read from.
-8. **Refresh the machines after promotion**: re-run `python3 scripts/skills_install.py --snapshot-only` per machine, from a freshly fetched `main`, the cadence `docs/host-setup.md` "Fleet Skills Install" states. Until then each machine's Codex and opencode copy holds the previous skill set, which `--report` says, while Claude Code serves whatever the hub checkout holds.
+8. **Refresh the machines after promotion**, per machine, as `docs/host-setup.md` "Fleet Skills Install" states. Until then each machine's Codex and opencode copy holds the previous skill set, which `--report` says, while Claude Code serves whatever the hub checkout holds.
 
 ## Changing or Retiring a Skill
 

.agents/skills/workflow-ci-contract/references/architecture.md

@@ -28,7 +28,7 @@ flowchart LR
 
 The direct commit is an **allowance, not a substitute for review**. The ruleset drops the pull-request *requirement*, which permits a direct push without withdrawing the pull request, so a change worth reviewing still takes one and both paths reach `develop` legally. Which changes those are is stated as a shape rather than a line count in `GOVERNANCE.md` "Operational Repositories", which owns the test and is the one place it is written, since nothing in a ruleset can apply it. What differs is when validation lands. On the direct-commit path the commit is already on the branch, so CI can only be advisory after the fact, and that is the accepted cost of the model. On the pull-request path the change has not landed, so validation is pre-merge and actionable, which is the moment it is worth the most, and the lint workflow's `pull_request` trigger therefore names `develop` alongside `main` (`WORKFLOW.md` section 6). That is what makes **D1.2** hold here, since its input is *any* PR and the operational model is no exception. The check is reported on a `develop` PR rather than required, because a required status check on `develop` binds the direct push too and would dissolve the allowance the model is built on.
 
-Their CI is lint/validation only (editorconfig/EOL plus domain linters such as Home Assistant or ESPHome config validation or a firmware build, but **no unit tests**), so the D-guarantees in `WORKFLOW.md` section 4 that assume a build/test pipeline are **N/A** exactly as for `source-only` (`WORKFLOW.md` section 6). What binds: the promotion gate, where the `develop -> main` PR must pass the required `Check pull request workflow status job`, and the source-only release on manual dispatch (`releaseTrigger: dispatch-only`; tag + source zip). Branch-model rulesets are specified in `GOVERNANCE.md` "Branching Model" rather than in `WORKFLOW.md`.
+Their CI is lint/validation only (editorconfig/EOL plus domain linters such as Home Assistant or ESPHome config validation or a firmware build, but **no unit tests**), so the D-guarantees in `WORKFLOW.md` section 4 that assume a build/test pipeline are **N/A** exactly as for `source-only` (`WORKFLOW.md` section 6). What binds: the promotion gate, where the `develop -> main` PR must pass the required `Check pull request workflow status job`, and the source-only release on manual dispatch (`releaseTrigger: dispatch-only`, tag + source zip). Branch-model rulesets are specified in `GOVERNANCE.md` "Branching Model" rather than in `WORKFLOW.md`.
 
 ### Two Layers: Orchestration vs Build