github-security-report 0.14.2__tar.gz → 0.15.0__tar.gz

{github_security_report-0.14.2 → github_security_report-0.15.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: github-security-report
-Version: 0.14.2
+Version: 0.15.0
 Summary: Security and quality reporting across GitHub organisations
 Project-URL: Homepage, https://github.com/lfreleng-actions/github-security-report-action
 Project-URL: Repository, https://github.com/lfreleng-actions/github-security-report-action
@@ -736,17 +736,17 @@ organisation](#inside-or-outside-the-organisation):
 
 ```text
 Pull Requests
-┏━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━┳━━━━━━┳━━━━━━━━━━┳━━━━━━┳━━━━━━━━━┳━━━━━━━┳━━━━━━━┓
-┃ Repository           ┃ Human ┃ Ext ┃ Auto ┃ Conflict ┃ Fail ┃ Copilot ┃ Draft ┃ Total ┃
-┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━╇━━━━━━╇━━━━━━━━━━╇━━━━━━╇━━━━━━━━━╇━━━━━━━╇━━━━━━━┩
-│ lftools-uv           │     8 │   0 │    0 │        0 │    0 │       0 │     0 │     8 │
-│ dependamerge         │     3 │   0 │    0 │        0 │    0 │       2 │     0 │     3 │
-│ gha-workflow-linter  │     2 │   0 │    0 │        0 │    1 │       0 │     1 │     2 │
-│ harden-runner-block- │     1 │   0 │    0 │        1 │    0 │       0 │     1 │     1 │
-│ action               │       │     │      │          │      │         │       │       │
-├─────────────────────┼───────┼─────┼──────┼──────────┼──────┼─────────┼───────┼───────┤
-│ Total                │    14 │   0 │    0 │        1 │    1 │       2 │     2 │    14 │
-└─────────────────────┴───────┴─────┴──────┴──────────┴──────┴─────────┴───────┴───────┘
+┏━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━┳━━━━━━┳━━━━━━━━━━┳━━━━━━┳━━━━━━━━┳━━━━━━━━━┳━━━━━━━┳━━━━━━━┓
+┃ Repository           ┃ Human ┃ Ext ┃ Auto ┃ Conflict ┃ Fail ┃ Review ┃ Copilot ┃ Draft ┃ Total ┃
+┡━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━╇━━━━━━╇━━━━━━━━━━╇━━━━━━╇━━━━━━━━╇━━━━━━━━━╇━━━━━━━╇━━━━━━━┩
+│ lftools-uv           │     8 │   0 │    0 │        0 │    0 │      0 │       0 │     0 │     8 │
+│ dependamerge         │     3 │   0 │    0 │        0 │    0 │      1 │       2 │     0 │     3 │
+│ gha-workflow-linter  │     2 │   0 │    0 │        0 │    1 │      0 │       0 │     1 │     2 │
+│ harden-runner-block- │     1 │   0 │    0 │        1 │    0 │      0 │       0 │     1 │     1 │
+│ action               │       │     │      │          │      │        │         │       │       │
+├──────────────────────┼───────┼─────┼──────┼──────────┼──────┼────────┼─────────┼───────┼───────┤
+│ Total                │    14 │   0 │    0 │        1 │    1 │      1 │       2 │     2 │    14 │
+└──────────────────────┴───────┴─────┴──────┴──────────┴──────┴────────┴─────────┴───────┴───────┘
   … and 9 more
   ❌ 13 With open pull requests
   ✅ 104 No open pull requests
@@ -760,34 +760,73 @@ The columns form **two independent groupings**:
 | `Ext` | Human pull requests raised from outside the organisation — a **subset of Human**, which is why it sits beside it. |
 | `Conflict` | Blocked on a merge conflict. |
 | `Fail` | Latest checks did not pass. The rollup includes optional checks, so this is not by itself proof that the merge is blocked. |
+| `Review` | A reviewer has **requested changes** — a person waiting on the author. |
 | `Copilot` | Carries at least one **unresolved review thread** opened by GitHub's automated code reviewer. |
 | `Draft` | Marked as a draft. |
 
-`Conflict`, `Fail`, `Copilot` and `Draft` **overlap** each other and the author
-split, so they do not sum to `Total` and are not meant to: one pull request that
-is conflicting, failing *and* a draft is counted once in each of those three
-columns, and once under `Human` or `Auto`. Only `Human` + `Auto` reconciles with
-the collected total. They are ordered worst-first — a conflict needs a human to
-rebase, a failing check may only need a re-run, unresolved review feedback needs
-a human but does not hold the merge button down, and a draft is not blocked at
-all.
+`Conflict`, `Fail`, `Review`, `Copilot` and `Draft` **overlap** each other and
+the author split, so they do not sum to `Total` and are not meant to: one pull
+request that is conflicting, failing *and* a draft is counted once in each of
+those three columns, and once under `Human` or `Auto`. Only `Human` + `Auto`
+reconciles with the collected total. They are ordered worst-first — a conflict
+needs a human to rebase, a failing check may only need a re-run, requested
+changes need the author to act, unresolved automated feedback needs somebody but
+does not hold the merge button down, and a draft is not blocked at all.
+
+`Review` and `Copilot` sit together inside the blocker group, and deliberately
+not beside `Human`: that column names who **raised** a pull request, whereas
+these two name who is **waiting on** it. The grouping is what keeps those two
+readings of "human" apart.
+
+#### Requested changes
+
+`Review` counts pull requests where **a person** has asked for changes and not
+withdrawn it.
+
+Two fields answer that, each covering the other's blind spot. `reviewDecision` is
+GitHub's own verdict, computed over every review and accounting for dismissals,
+so it is **exact at any review count** — but it names nobody, and a GitHub App
+holding pull-request write permission can request changes exactly as a person
+can. `latestOpinionatedReviews` names the reviewers, but is a bounded window of
+five (one review per reviewer, so five reviewers rather than five reviews).
+
+So the decision **gates** and the window **attributes**. Anything other than
+`CHANGES_REQUESTED` is a definite zero whatever the window holds, and only once
+GitHub says changes are outstanding does the reviewer's identity matter — which
+keeps the cheap exact answer for almost every pull request and pays the window's
+uncertainty on the few where it changes the reading. Automated reviewers are
+recognised by the same rule as the `Auto` column.
+
+Only `CHANGES_REQUESTED` gates. **`REVIEW_REQUIRED` is deliberately excluded**:
+it reports that a branch rule demands a review, not that anybody objected, so on
+an organisation that requires review by default it would mark nearly every human
+pull request and distinguish none of them. The rule is written as an allow-list
+of the one blocking state rather than as "anything that is not `APPROVED`", so a
+state GitHub adds later arrives uncounted rather than pre-counted as a blocker.
+
+Where a request for changes cannot be attributed — the reviews were unreadable,
+the author is gone, or the window held only automated requests without covering
+every reviewer — the pull request is left **uncounted rather than credited to a
+person**, and the table says so in its description.
 
 #### Unresolved Copilot feedback
 
-`Copilot` counts the pull requests **waiting on a human to answer a review**. A
-review thread counts when it was opened by GitHub's automated code reviewer (the
-`copilot-pull-request-reviewer` bot) and nobody has resolved it. The reviewer is
-identified from each thread's **opening** comment, since later replies are
-usually the human answering the review.
+`Copilot` counts the pull requests **waiting on somebody to answer an automated
+review**. A review thread counts when it was opened by GitHub's automated code
+reviewer (the `copilot-pull-request-reviewer` bot) and nobody has resolved it.
+The reviewer is identified from each thread's **opening** comment, since later
+replies are usually the human answering the review.
 
 An **outdated** thread still counts: GitHub marks a thread outdated when the
 code beneath it changes, but that does not resolve it, so the feedback remains
 unanswered.
 
-Any non-zero count is coloured **red**, like `Conflict` and `Fail` — it marks a
-pull request that cannot progress until somebody responds. The count also feeds
-the row ranking, so a backlog awaiting review outranks an untouched one of the
-same size.
+Any non-zero count is coloured **amber**, one step below the red of `Conflict`,
+`Fail` and `Review`. Automated feedback is worth answering, but nobody is
+waiting on it, and there is far more of it — colouring the two alike would let
+the bot's threads mask the rarer case that actually holds a person up. The count
+still feeds the row ranking, so a backlog awaiting review outranks an untouched
+one of the same size.
 
 The scan reads the **newest 20 review threads per pull request**, which is the
 single most expensive part of the prefetch (see the cost figures above). The
@@ -802,8 +841,8 @@ clear — see below.
 #### Automation backlog thresholds
 
 On the terminal the counts are coloured so the table reads at a glance: `Human`
-and `Ext` **green**, `Conflict`, `Fail` and `Copilot` **red**, and `Auto`
-coloured against two configured thresholds.
+and `Ext` **green**, `Conflict`, `Fail` and `Review` **red**, `Copilot`
+**amber**, and `Auto` coloured against two configured thresholds.
 
 Dependabot stops raising pull requests once a repository reaches its
 `open-pull-requests-limit`, so the repository quietly stops receiving dependency
@@ -1025,7 +1064,7 @@ reports as an App and any unrecognised login carrying the `[bot]` marker — so
 future bot is classified as automation rather than mistaken for an outside
 contributor.
 
-`Fail`, `Conflict` and `Copilot` count only **established** states. GitHub
+`Fail`, `Conflict`, `Review` and `Copilot` count only **established** states. GitHub
 computes mergeability lazily and answers `UNKNOWN` until it settles, and reports
 no check rollup at all when no checks have run; neither absence is evidence that
 a pull request is ready, so neither is counted either way. `Copilot` follows the
@@ -1039,10 +1078,15 @@ holding any such reading says so in its description: `Copilot` then
 **undercounts and should be read as a lower bound**, exactly as `Ext` does when
 membership cannot be read.
 
+`Review` carries a weaker version of the same hedge, and earns it far less
+often: `reviewDecision` is exact, so only a pull request GitHub *does* report
+changes requested on can leave the question open, and then only when the
+opinionated-review window fails to attribute it to anybody.
+
 Repositories with no open pull requests are counted in the footer rather than
 listed. Rows rank by total open pull requests, then by those failing,
-conflicting or awaiting Copilot feedback (counted once each, since the columns
-overlap), so two repositories with equal backlogs surface the more
+conflicting or awaiting review — automated or human (counted once each, since
+the columns overlap) — so two repositories with equal backlogs surface the more
 stuck one first.
 
 > **Accuracy note.** As with the issues table, `Total` is exact at any size,

{github_security_report-0.14.2 → github_security_report-0.15.0}/README.md

@@ -692,17 +692,17 @@ organisation](#inside-or-outside-the-organisation):
 
 ```text
 Pull Requests
-┏━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━┳━━━━━━┳━━━━━━━━━━┳━━━━━━┳━━━━━━━━━┳━━━━━━━┳━━━━━━━┓
-┃ Repository           ┃ Human ┃ Ext ┃ Auto ┃ Conflict ┃ Fail ┃ Copilot ┃ Draft ┃ Total ┃
-┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━╇━━━━━━╇━━━━━━━━━━╇━━━━━━╇━━━━━━━━━╇━━━━━━━╇━━━━━━━┩
-│ lftools-uv           │     8 │   0 │    0 │        0 │    0 │       0 │     0 │     8 │
-│ dependamerge         │     3 │   0 │    0 │        0 │    0 │       2 │     0 │     3 │
-│ gha-workflow-linter  │     2 │   0 │    0 │        0 │    1 │       0 │     1 │     2 │
-│ harden-runner-block- │     1 │   0 │    0 │        1 │    0 │       0 │     1 │     1 │
-│ action               │       │     │      │          │      │         │       │       │
-├─────────────────────┼───────┼─────┼──────┼──────────┼──────┼─────────┼───────┼───────┤
-│ Total                │    14 │   0 │    0 │        1 │    1 │       2 │     2 │    14 │
-└─────────────────────┴───────┴─────┴──────┴──────────┴──────┴─────────┴───────┴───────┘
+┏━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━┳━━━━━━┳━━━━━━━━━━┳━━━━━━┳━━━━━━━━┳━━━━━━━━━┳━━━━━━━┳━━━━━━━┓
+┃ Repository           ┃ Human ┃ Ext ┃ Auto ┃ Conflict ┃ Fail ┃ Review ┃ Copilot ┃ Draft ┃ Total ┃
+┡━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━╇━━━━━━╇━━━━━━━━━━╇━━━━━━╇━━━━━━━━╇━━━━━━━━━╇━━━━━━━╇━━━━━━━┩
+│ lftools-uv           │     8 │   0 │    0 │        0 │    0 │      0 │       0 │     0 │     8 │
+│ dependamerge         │     3 │   0 │    0 │        0 │    0 │      1 │       2 │     0 │     3 │
+│ gha-workflow-linter  │     2 │   0 │    0 │        0 │    1 │      0 │       0 │     1 │     2 │
+│ harden-runner-block- │     1 │   0 │    0 │        1 │    0 │      0 │       0 │     1 │     1 │
+│ action               │       │     │      │          │      │        │         │       │       │
+├──────────────────────┼───────┼─────┼──────┼──────────┼──────┼────────┼─────────┼───────┼───────┤
+│ Total                │    14 │   0 │    0 │        1 │    1 │      1 │       2 │     2 │    14 │
+└──────────────────────┴───────┴─────┴──────┴──────────┴──────┴────────┴─────────┴───────┴───────┘
   … and 9 more
   ❌ 13 With open pull requests
   ✅ 104 No open pull requests
@@ -716,34 +716,73 @@ The columns form **two independent groupings**:
 | `Ext` | Human pull requests raised from outside the organisation — a **subset of Human**, which is why it sits beside it. |
 | `Conflict` | Blocked on a merge conflict. |
 | `Fail` | Latest checks did not pass. The rollup includes optional checks, so this is not by itself proof that the merge is blocked. |
+| `Review` | A reviewer has **requested changes** — a person waiting on the author. |
 | `Copilot` | Carries at least one **unresolved review thread** opened by GitHub's automated code reviewer. |
 | `Draft` | Marked as a draft. |
 
-`Conflict`, `Fail`, `Copilot` and `Draft` **overlap** each other and the author
-split, so they do not sum to `Total` and are not meant to: one pull request that
-is conflicting, failing *and* a draft is counted once in each of those three
-columns, and once under `Human` or `Auto`. Only `Human` + `Auto` reconciles with
-the collected total. They are ordered worst-first — a conflict needs a human to
-rebase, a failing check may only need a re-run, unresolved review feedback needs
-a human but does not hold the merge button down, and a draft is not blocked at
-all.
+`Conflict`, `Fail`, `Review`, `Copilot` and `Draft` **overlap** each other and
+the author split, so they do not sum to `Total` and are not meant to: one pull
+request that is conflicting, failing *and* a draft is counted once in each of
+those three columns, and once under `Human` or `Auto`. Only `Human` + `Auto`
+reconciles with the collected total. They are ordered worst-first — a conflict
+needs a human to rebase, a failing check may only need a re-run, requested
+changes need the author to act, unresolved automated feedback needs somebody but
+does not hold the merge button down, and a draft is not blocked at all.
+
+`Review` and `Copilot` sit together inside the blocker group, and deliberately
+not beside `Human`: that column names who **raised** a pull request, whereas
+these two name who is **waiting on** it. The grouping is what keeps those two
+readings of "human" apart.
+
+#### Requested changes
+
+`Review` counts pull requests where **a person** has asked for changes and not
+withdrawn it.
+
+Two fields answer that, each covering the other's blind spot. `reviewDecision` is
+GitHub's own verdict, computed over every review and accounting for dismissals,
+so it is **exact at any review count** — but it names nobody, and a GitHub App
+holding pull-request write permission can request changes exactly as a person
+can. `latestOpinionatedReviews` names the reviewers, but is a bounded window of
+five (one review per reviewer, so five reviewers rather than five reviews).
+
+So the decision **gates** and the window **attributes**. Anything other than
+`CHANGES_REQUESTED` is a definite zero whatever the window holds, and only once
+GitHub says changes are outstanding does the reviewer's identity matter — which
+keeps the cheap exact answer for almost every pull request and pays the window's
+uncertainty on the few where it changes the reading. Automated reviewers are
+recognised by the same rule as the `Auto` column.
+
+Only `CHANGES_REQUESTED` gates. **`REVIEW_REQUIRED` is deliberately excluded**:
+it reports that a branch rule demands a review, not that anybody objected, so on
+an organisation that requires review by default it would mark nearly every human
+pull request and distinguish none of them. The rule is written as an allow-list
+of the one blocking state rather than as "anything that is not `APPROVED`", so a
+state GitHub adds later arrives uncounted rather than pre-counted as a blocker.
+
+Where a request for changes cannot be attributed — the reviews were unreadable,
+the author is gone, or the window held only automated requests without covering
+every reviewer — the pull request is left **uncounted rather than credited to a
+person**, and the table says so in its description.
 
 #### Unresolved Copilot feedback
 
-`Copilot` counts the pull requests **waiting on a human to answer a review**. A
-review thread counts when it was opened by GitHub's automated code reviewer (the
-`copilot-pull-request-reviewer` bot) and nobody has resolved it. The reviewer is
-identified from each thread's **opening** comment, since later replies are
-usually the human answering the review.
+`Copilot` counts the pull requests **waiting on somebody to answer an automated
+review**. A review thread counts when it was opened by GitHub's automated code
+reviewer (the `copilot-pull-request-reviewer` bot) and nobody has resolved it.
+The reviewer is identified from each thread's **opening** comment, since later
+replies are usually the human answering the review.
 
 An **outdated** thread still counts: GitHub marks a thread outdated when the
 code beneath it changes, but that does not resolve it, so the feedback remains
 unanswered.
 
-Any non-zero count is coloured **red**, like `Conflict` and `Fail` — it marks a
-pull request that cannot progress until somebody responds. The count also feeds
-the row ranking, so a backlog awaiting review outranks an untouched one of the
-same size.
+Any non-zero count is coloured **amber**, one step below the red of `Conflict`,
+`Fail` and `Review`. Automated feedback is worth answering, but nobody is
+waiting on it, and there is far more of it — colouring the two alike would let
+the bot's threads mask the rarer case that actually holds a person up. The count
+still feeds the row ranking, so a backlog awaiting review outranks an untouched
+one of the same size.
 
 The scan reads the **newest 20 review threads per pull request**, which is the
 single most expensive part of the prefetch (see the cost figures above). The
@@ -758,8 +797,8 @@ clear — see below.
 #### Automation backlog thresholds
 
 On the terminal the counts are coloured so the table reads at a glance: `Human`
-and `Ext` **green**, `Conflict`, `Fail` and `Copilot` **red**, and `Auto`
-coloured against two configured thresholds.
+and `Ext` **green**, `Conflict`, `Fail` and `Review` **red**, `Copilot`
+**amber**, and `Auto` coloured against two configured thresholds.
 
 Dependabot stops raising pull requests once a repository reaches its
 `open-pull-requests-limit`, so the repository quietly stops receiving dependency
@@ -981,7 +1020,7 @@ reports as an App and any unrecognised login carrying the `[bot]` marker — so
 future bot is classified as automation rather than mistaken for an outside
 contributor.
 
-`Fail`, `Conflict` and `Copilot` count only **established** states. GitHub
+`Fail`, `Conflict`, `Review` and `Copilot` count only **established** states. GitHub
 computes mergeability lazily and answers `UNKNOWN` until it settles, and reports
 no check rollup at all when no checks have run; neither absence is evidence that
 a pull request is ready, so neither is counted either way. `Copilot` follows the
@@ -995,10 +1034,15 @@ holding any such reading says so in its description: `Copilot` then
 **undercounts and should be read as a lower bound**, exactly as `Ext` does when
 membership cannot be read.
 
+`Review` carries a weaker version of the same hedge, and earns it far less
+often: `reviewDecision` is exact, so only a pull request GitHub *does* report
+changes requested on can leave the question open, and then only when the
+opinionated-review window fails to attribute it to anybody.
+
 Repositories with no open pull requests are counted in the footer rather than
 listed. Rows rank by total open pull requests, then by those failing,
-conflicting or awaiting Copilot feedback (counted once each, since the columns
-overlap), so two repositories with equal backlogs surface the more
+conflicting or awaiting review — automated or human (counted once each, since
+the columns overlap) — so two repositories with equal backlogs surface the more
 stuck one first.
 
 > **Accuracy note.** As with the issues table, `Total` is exact at any size,

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.14.2'
-__version_tuple__ = version_tuple = (0, 14, 2)
+__version__ = version = '0.15.0'
+__version_tuple__ = version_tuple = (0, 15, 0)
 
 __commit_id__ = commit_id = None

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/categories.py

@@ -311,9 +311,11 @@ _CATEGORIES: dict[CategoryKey, CategoryMeta] = {
             "Conflict counts pull requests blocked on a merge conflict; Fail "
             "counts those whose latest checks did not pass, which includes "
             "optional checks and so is not by itself proof that a merge is "
-            "blocked; Copilot counts those still carrying an unresolved review "
-            "thread opened by GitHub's automated code reviewer; Draft counts "
-            "those still marked as drafts. Those four "
+            "blocked; Review counts those a reviewer has asked for changes on, "
+            "which is a person waiting on the author; Copilot counts those "
+            "still carrying an unresolved review thread opened by GitHub's "
+            "automated code reviewer; Draft counts "
+            "those still marked as drafts. Those five "
             "are independent of the author split and of each other, so one "
             "pull request can appear in more than one of them. Ranked by total "
             "open pull requests, then by those failing, conflicting or "

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/client/parsers.py

@@ -17,6 +17,7 @@ from typing import cast
 import httpx
 
 from github_security_report.client.copilot import _copilot_unresolved
+from github_security_report.client.reviews import _changes_requested
 from github_security_report.models import (
     AuthorRef,
     IssueRef,
@@ -341,6 +342,7 @@ def _pull_request_ref(node: object) -> PullRequestRef | None:
         conflicting=conflicting,
         failing=_check_rollup_failed(node),
         copilot_unresolved=_copilot_unresolved(node),
+        changes_requested=_changes_requested(node),
     )
 
 

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/client/queries.py

@@ -111,6 +111,17 @@ _PULL_REQUEST_WINDOW = 25
 # truncate, and the assignment breakdown is therefore exact for every collected
 # pull request.
 _ASSIGNEE_WINDOW = 10
+# Opinionated reviews inspected per pull request, to tell whose request for
+# changes is outstanding. ``reviewDecision`` says *that* changes are requested
+# but names nobody, and a GitHub App with pull-request write permission can
+# request them exactly as a person can -- so identity needs its own field.
+#
+# The connection returns at most one review per reviewer, so five covers a pull
+# request with five opinionated reviewers rather than five reviews. Measured
+# against a 25-repository batch this adds 6 points, which is the cheapest of the
+# three windows here by an order of magnitude, and ``totalCount`` rides along
+# free to keep it honest.
+_OPINIONATED_REVIEW_WINDOW = 5
 # Review threads inspected per pull request, to spot outstanding Copilot review
 # feedback. This is the most expensive window in the fragment, because it
 # multiplies the pull-request window and then again by the one comment needed to
@@ -179,9 +190,14 @@ fragment RepoData on Repository {{
       number
       isDraft
       mergeable
+      reviewDecision
       authorAssociation
       author {{ __typename login }}
       assignees(first: {_ASSIGNEE_WINDOW}) {{ nodes {{ login }} }}
+      latestOpinionatedReviews(first: {_OPINIONATED_REVIEW_WINDOW}) {{
+        totalCount
+        nodes {{ state author {{ __typename login }} }}
+      }}
       reviewThreads(last: {_REVIEW_THREAD_WINDOW}) {{
         totalCount
         nodes {{

github_security_report-0.15.0/src/github_security_report/client/reviews.py

@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: Apache-2.0
+# SPDX-FileCopyrightText: 2026 The Linux Foundation
+"""Reading an outstanding request for changes from a pull-request node.
+
+One question, asked of the two review fields the batched prefetch requests: is a
+*person* waiting on this pull request's author? Kept apart from the general node
+parsing for the same reason as the Copilot reading beside it -- it has to reason
+about a bounded window, and so about what that window's edge does and does not
+prove.
+"""
+
+from __future__ import annotations
+
+from github_security_report.authors import is_automation_author
+
+# The one review decision that means somebody objected. An allow-list of that
+# single state rather than "anything that is not APPROVED": REVIEW_REQUIRED says
+# a branch rule demands a review, not that a reviewer objected, so counting it
+# would mark nearly every pull request in an organisation that requires review by
+# default. Writing the rule positively also means a state GitHub adds later
+# arrives *uncounted* rather than pre-counted as a blocker.
+_BLOCKING_DECISION = "CHANGES_REQUESTED"
+
+
+def _changes_requested(node: dict) -> bool | None:
+    """Whether a *person* has asked for changes and not withdrawn it.
+
+    Two fields, each covering the other's blind spot. ``reviewDecision`` is
+    GitHub's own verdict, computed over every review and accounting for
+    dismissals, so it is exact however long the review ran -- but it names
+    nobody, and a GitHub App holding pull-request write permission can request
+    changes exactly as a person can. ``latestOpinionatedReviews`` names the
+    reviewers but is a bounded window.
+
+    So the decision *gates* and the window *attributes*. Anything other than
+    ``CHANGES_REQUESTED`` is a definite False whatever the window holds, and
+    only once GitHub says changes are outstanding does identity matter. That
+    keeps the cheap exact answer for the overwhelming majority of pull requests
+    and pays the window's uncertainty on the few where it changes the reading.
+
+    ``None`` is the open question: the fields could not be read, a requested
+    change carried no author to attribute it to, or the window held only
+    automated requests without covering every opinionated reviewer -- in which
+    case a person's may sit among the reviews this run never saw. As elsewhere,
+    None is "not established" rather than "nothing outstanding".
+    """
+    if "reviewDecision" not in node:
+        return None
+    decision = node["reviewDecision"]
+    if not isinstance(decision, str) or decision != _BLOCKING_DECISION:
+        return False
+    reviews = node.get("latestOpinionatedReviews")
+    if not isinstance(reviews, dict):
+        return None
+    nodes = reviews.get("nodes")
+    if not isinstance(nodes, list):
+        return None
+    seen = 0
+    for review in nodes:
+        if not isinstance(review, dict):
+            continue
+        seen += 1
+        if review.get("state") != _BLOCKING_DECISION:
+            continue
+        author = review.get("author")
+        if not isinstance(author, dict):
+            # A request for changes we cannot attribute -- a deleted account,
+            # say. Counting it would guess at a person; skipping it would let
+            # the loop fall through to a confident False.
+            return None
+        if not is_automation_author(author.get("login"), author.get("__typename")):
+            return True
+    total = reviews.get("totalCount")
+    if not isinstance(total, int) or isinstance(total, bool) or total > seen:
+        return None
+    return False

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/models.py

@@ -4,9 +4,9 @@
 
 Encodes the Phase 0 design (see ``docs/BRIEF.md`` and
 ``docs/phase0-findings.md``): the six ranked signals, the four-state per-report
-classification, severity counts with hierarchical worst-first ordering, and the
-ranking rules (alert tables sort by severity descending; Scorecard by its worst
-populated severity rung descending, then by score ascending).
+classification, and severity counts with hierarchical worst-first ordering.
+The rules for ordering offenders *between* repositories live in ``ranking.py``,
+which reads these models rather than being part of them.
 """
 
 from __future__ import annotations
@@ -178,7 +178,7 @@ class IssueRef:
 class PullRequestRef:
     """One open pull request's review-load facts.
 
-    ``draft`` and the three blocked flags are independent of the author and of
+    ``draft`` and the four blocked flags are independent of the author and of
     each other, so one pull request may be a draft *and* conflicting *and*
     awaiting review; the table counts each axis separately rather than bucketing
     rows.
@@ -207,6 +207,24 @@ class PullRequestRef:
     # the threads this run never saw. As with ``conflicting`` and ``failing``,
     # None is "not established" rather than "nothing outstanding".
     copilot_unresolved: bool | None = None
+    # True when a *person* has requested changes and not withdrawn it. Read
+    # from ``reviewDecision``, which GitHub computes over every review and so is
+    # exact at any review count, attributed through the bounded window of
+    # opinionated reviews -- the decision names nobody, and a GitHub App can
+    # request changes exactly as a person can.
+    #
+    # None where that attribution could not be settled: the fields were
+    # unreadable, a request carried no author, or the window held only automated
+    # requests without covering every reviewer. As with the flags above, None is
+    # "not established" rather than "nothing outstanding" -- though it is far
+    # rarer here, since it needs GitHub to report changes requested *and* the
+    # window to fall short.
+    #
+    # Only CHANGES_REQUESTED counts. REVIEW_REQUIRED is deliberately excluded:
+    # it reports that a branch rule demands a review, not that anyone objected,
+    # so on an organisation that requires review by default it would mark almost
+    # every human pull request and say nothing about any of them.
+    changes_requested: bool | None = None
 
 
 @dataclass
@@ -367,70 +385,3 @@ class RepoSignal:
     @property
     def is_offender(self) -> bool:
         return self.state is RepoState.OFFENDER
-
-
-# The rungs eligible to lead the Scorecard ordering, worst-first.
-# ``INFORMATIONAL`` is deliberately absent: it is the non-actionable rung, so it
-# never displaces the score as the primary key.
-LEAD_RUNGS: tuple[Severity, ...] = tuple(
-    rung for rung in RUNGS_WORST_FIRST if rung is not Severity.INFORMATIONAL
-)
-
-
-def lead_rung(offenders: list[RepoSignal]) -> Severity | None:
-    """The worst severity rung any offender actually carries.
-
-    Returns ``None`` when no offender carries a finding at Low or above, in
-    which case there is no severity tier worth leading on.
-    """
-    return next(
-        (rung for rung in LEAD_RUNGS if any(s.counts.at(rung) for s in offenders)),
-        None,
-    )
-
-
-def rank_offenders(signals: list[RepoSignal]) -> list[RepoSignal]:
-    """Sort offenders worst-first for a single signal.
-
-    Alert-based signals sort by the hierarchical severity key descending, with
-    total as a tiebreaker.
-
-    Scorecard sorts on two tiers: the count at the worst severity rung present
-    anywhere in the table (descending), then the aggregate score (ascending,
-    lower == worse). The leading rung cascades -- Critical, else High, else
-    Medium, else Low -- so the rung that actually discriminates between
-    repositories leads, and a lone Critical can never be buried mid-table by a
-    weaker repository with a lower score. When no offender carries a finding at
-    Low or above, the score alone orders the table.
-
-    Repo name breaks remaining ties, ascending.
-
-    Numeric components are negated so the whole sort runs ascending (no
-    ``reverse=True``); that keeps the name tiebreaker correctly ascending even
-    when one name is a prefix of another.
-    """
-    offenders = [s for s in signals if s.is_offender]
-    if not offenders:
-        return []
-    signal = offenders[0].signal
-    if signal.sort_ascending:
-        rung = lead_rung(offenders)
-        return sorted(
-            offenders,
-            key=lambda s: (
-                -s.counts.at(rung) if rung is not None else 0,
-                s.score if s.score is not None else float("inf"),
-                s.repo.name,
-            ),
-        )
-    return sorted(
-        offenders,
-        key=lambda s: (
-            -s.counts.critical,
-            -s.counts.high,
-            -s.counts.medium,
-            -s.counts.low,
-            -s.counts.total,
-            s.repo.name,
-        ),
-    )

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/ordering.py

@@ -30,7 +30,7 @@ whose rendered columns vary by surface and by data (Slack abbreviates the
 headers and drops Total, and the Informational column appears only when
 populated), so resolving against a renderer's column list would make the
 ordering depend on which surface asked. Omitting ``sort`` keeps
-:func:`models.rank_offenders`, whose default encodes domain logic a column sort
+:func:`ranking.rank_offenders`, whose default encodes domain logic a column sort
 cannot express -- notably Scorecard's cascade through the worst populated
 severity rung, which stops a lone Critical being buried by a weaker repository
 with a lower score.
@@ -417,7 +417,7 @@ def apply_configured_signal_order(
 ) -> None:
     """Reorder each signal's offenders in place using its configured ordering.
 
-    A signal with no ``sort`` keeps :func:`models.rank_offenders`, whose default
+    A signal with no ``sort`` keeps :func:`ranking.rank_offenders`, whose default
     is not expressible as a column list: Scorecard cascades through the worst
     severity rung any offender actually carries, which is a property of the
     table as a whole rather than of any one row.

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/pulls/__init__.py

@@ -71,6 +71,7 @@ from github_security_report.pulls.columns import (
     OTHERS_ROW,
     PERSONAL_ASSIGNMENT_ROWS,
     REPOSITORY_COLUMN,
+    REVIEW_COLUMN,
     TOTAL_COLUMN,
     TRUNCATED_MARKER,
     UNASSIGNED_ROW,
@@ -84,6 +85,7 @@ from github_security_report.pulls.counting import (
     copilot_indeterminate,
     count_pull_requests,
     is_mine,
+    review_indeterminate,
 )
 from github_security_report.pulls.presentation import (
     _cell_levels,
@@ -131,6 +133,7 @@ __all__ = [
     "PERSONAL_ASSIGNMENT_ROWS",
     "PullRequestRef",
     "REPOSITORY_COLUMN",
+    "REVIEW_COLUMN",
     "Repo",
     "RepoGraphData",
     "Set",
@@ -151,4 +154,5 @@ __all__ = [
     "is_automation_author",
     "is_external_author",
     "is_mine",
+    "review_indeterminate",
 ]

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/pulls/columns.py

@@ -15,6 +15,7 @@ DRAFT_COLUMN = "Draft"
 EXTERNAL_COLUMN = "Ext"
 FAILING_COLUMN = "Fail"
 CONFLICT_COLUMN = "Conflict"
+REVIEW_COLUMN = "Review"
 COPILOT_COLUMN = "Copilot"
 TOTAL_COLUMN = "Total"
 
@@ -22,15 +23,21 @@ TOTAL_COLUMN = "Total"
 # Ordered so related columns read together: the author split first, with Ext
 # beside Human because it qualifies it (Ext is a subset of Human, never of
 # Auto), then the blockers, worst first -- a conflict needs a human to rebase,
-# a failing check may only need a re-run, unresolved Copilot feedback needs a
-# human but does not hold the merge button down, and a draft is not blocked at
-# all.
+# a failing check may only need a re-run, a reviewer who requested changes needs
+# the author to act, unresolved Copilot feedback needs somebody but does not
+# hold the merge button down, and a draft is not blocked at all.
+#
+# Review sits beside Copilot because the two answer the same question about
+# different reviewers, and both sit inside the blocker group rather than beside
+# Human -- which names who *raised* a pull request, not who reviewed it. The
+# grouping is what keeps those two readings of "human" apart.
 BREAKDOWN_COLUMNS = (
     HUMAN_COLUMN,
     EXTERNAL_COLUMN,
     AUTOMATION_COLUMN,
     CONFLICT_COLUMN,
     FAILING_COLUMN,
+    REVIEW_COLUMN,
     COPILOT_COLUMN,
     DRAFT_COLUMN,
 )

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/pulls/counting.py

@@ -25,6 +25,7 @@ from github_security_report.pulls.columns import (
     HUMAN_COLUMN,
     MINE_ROW,
     OTHERS_ROW,
+    REVIEW_COLUMN,
     UNASSIGNED_ROW,
 )
 
@@ -86,6 +87,12 @@ def count_pull_requests(
             counts[CONFLICT_COLUMN] += 1
         if pull.copilot_unresolved is True:
             counts[COPILOT_COLUMN] += 1
+        # Review needs the same hedge, though it earns it far less often: the
+        # decision is exact, so only a pull request GitHub *does* report changes
+        # requested on can leave the question open, and then only if the window
+        # failed to attribute it.
+        if pull.changes_requested is True:
+            counts[REVIEW_COLUMN] += 1
     return counts
 
 
@@ -148,6 +155,17 @@ def copilot_indeterminate(pulls: tuple[PullRequestRef, ...]) -> bool:
     return any(pull.copilot_unresolved is None for pull in pulls)
 
 
+def review_indeterminate(pulls: tuple[PullRequestRef, ...]) -> bool:
+    """Whether any of these pull requests left the Review question unsettled.
+
+    Same rule as :func:`copilot_indeterminate` and for the same reason -- a
+    bounded window, not a moment that will settle itself -- but reached far
+    less often, since it needs GitHub to report changes requested *and* the
+    window of opinionated reviews to fail to attribute them to anybody.
+    """
+    return any(pull.changes_requested is None for pull in pulls)
+
+
 def _blocked_count(pulls: tuple[PullRequestRef, ...]) -> int:
     """Pull requests that are failing, conflicting *or* awaiting Copilot, once each.
 
@@ -157,10 +175,11 @@ def _blocked_count(pulls: tuple[PullRequestRef, ...]) -> int:
     stuck ones. The table already says the columns overlap; the ranking has
     to agree with it.
 
-    Unresolved Copilot feedback joins the union because it is the same kind of
-    fact as the other two -- work the pull request is waiting on a human for --
-    and the table already colours it as blocking. Leaving it out would rank a
-    repository whose whole backlog is awaiting review below an untouched one.
+    Unresolved Copilot feedback and a reviewer's requested changes join the
+    union because they are the same kind of fact as the other two -- work the
+    pull request is waiting on somebody for -- and the table already colours
+    both as blocking. Leaving them out would rank a repository whose whole
+    backlog is awaiting review below an untouched one.
     """
     return sum(
         1
@@ -168,4 +187,5 @@ def _blocked_count(pulls: tuple[PullRequestRef, ...]) -> int:
         if pull.failing is True
         or pull.conflicting is True
         or pull.copilot_unresolved is True
+        or pull.changes_requested is True
     )

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/pulls/presentation.py

@@ -19,6 +19,7 @@ from github_security_report.pulls.columns import (
     EXTERNAL_COLUMN,
     FAILING_COLUMN,
     HUMAN_COLUMN,
+    REVIEW_COLUMN,
     TRUNCATED_MARKER,
 )
 from github_security_report.report import CELL_BAD, CELL_GOOD, CELL_WARN
@@ -68,6 +69,13 @@ def _cell_levels(
 
     The trailing Total is never emphasised: it is the sum of columns that
     disagree about what good looks like, so no one colour is true of it.
+
+    The blocked columns are not all one severity. Conflict, Fail and Review are
+    red: each needs a person to do something before the pull request can move.
+    Copilot is amber, a deliberate step down -- automated review feedback is
+    worth answering, but it is not a human waiting on a reply, and colouring the
+    two identically would let the louder, more numerous bot threads mask the
+    rarer case that actually holds somebody up.
     """
     levels: list[str | None] = []
     for column in BREAKDOWN_COLUMNS:
@@ -82,8 +90,10 @@ def _cell_levels(
             )
         elif column in (HUMAN_COLUMN, EXTERNAL_COLUMN):
             levels.append(CELL_GOOD if value else None)
-        elif column in (CONFLICT_COLUMN, FAILING_COLUMN, COPILOT_COLUMN):
+        elif column in (CONFLICT_COLUMN, FAILING_COLUMN, REVIEW_COLUMN):
             levels.append(CELL_BAD if value else None)
+        elif column == COPILOT_COLUMN:
+            levels.append(CELL_WARN if value else None)
         else:
             # Draft is neither good nor bad: a draft is not blocked, it is
             # simply not finished, so it carries no emphasis.
@@ -98,6 +108,7 @@ def _describe(
     *,
     filtered: bool,
     copilot_partial: bool = False,
+    review_partial: bool = False,
 ) -> str:
     """Extend the category description with the caveats the table earned.
 
@@ -146,4 +157,13 @@ def _describe(
             "answered, so Copilot undercounts and should be read as a lower "
             "bound."
         )
+    if review_partial:
+        description += (
+            " Who asked for changes could not be settled for at least one pull "
+            "request, whose opinionated reviews were unreadable, carried no "
+            "author to attribute a request to, or held only automated requests "
+            "without covering every reviewer. Such a pull request is left "
+            "uncounted rather than credited to a person, so Review undercounts "
+            "and should be read as a lower bound."
+        )
     return description

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/pulls/table.py

@@ -24,6 +24,7 @@ from github_security_report.pulls.counting import (
     copilot_indeterminate,
     count_pull_requests,
     is_mine,
+    review_indeterminate,
 )
 from github_security_report.pulls.presentation import (
     _cell_levels,
@@ -57,6 +58,7 @@ def _build_table(
     clean_count = 0
     unknown_count = 0
     copilot_partial = False
+    review_partial = False
     footer_labels = assignment_rows(viewer) if footer else ()
     for repo in repos:
         data = graph.get(repo.name, RepoGraphData())
@@ -91,6 +93,7 @@ def _build_table(
         counts = count_pull_requests(selected, members)
         blocked = _blocked_count(selected)
         copilot_partial = copilot_partial or copilot_indeterminate(selected)
+        review_partial = review_partial or review_indeterminate(selected)
         cells = (
             *(str(counts[column]) for column in BREAKDOWN_COLUMNS),
             _total_cell(total, truncated),
@@ -129,6 +132,7 @@ def _build_table(
         members,
         filtered=select is not None,
         copilot_partial=copilot_partial,
+        review_partial=review_partial,
     )
     return TableSection(
         category=meta,

github_security_report-0.15.0/src/github_security_report/ranking.py

@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: Apache-2.0
+# SPDX-FileCopyrightText: 2026 The Linux Foundation
+"""Worst-first ordering of the repositories a signal found something in.
+
+The domain default behind every offender table: which repository a reader meets
+first. ``ordering.py`` owns the *configurable* orderings a report may ask for
+and defers to :func:`rank_offenders` when a signal names none, so the two are
+separate concerns -- what the reader chose, and what the domain says when they
+chose nothing.
+
+Kept out of ``models.py`` because these are decisions taken *about* the models
+rather than part of them, and out of ``severity.py`` because they read a
+``RepoSignal``, which would make that module import the models that already
+import it.
+"""
+
+from __future__ import annotations
+
+from github_security_report.models import RepoSignal
+from github_security_report.severity import RUNGS_WORST_FIRST, Severity
+
+# The rungs eligible to lead the Scorecard ordering, worst-first.
+# ``INFORMATIONAL`` is deliberately absent: it is the non-actionable rung, so it
+# never displaces the score as the primary key.
+LEAD_RUNGS: tuple[Severity, ...] = tuple(
+    rung for rung in RUNGS_WORST_FIRST if rung is not Severity.INFORMATIONAL
+)
+
+
+def lead_rung(offenders: list[RepoSignal]) -> Severity | None:
+    """The worst severity rung any offender actually carries.
+
+    Returns ``None`` when no offender carries a finding at Low or above, in
+    which case there is no severity tier worth leading on.
+    """
+    return next(
+        (rung for rung in LEAD_RUNGS if any(s.counts.at(rung) for s in offenders)),
+        None,
+    )
+
+
+def rank_offenders(signals: list[RepoSignal]) -> list[RepoSignal]:
+    """Sort offenders worst-first for a single signal.
+
+    Alert-based signals sort by the hierarchical severity key descending, with
+    total as a tiebreaker.
+
+    Scorecard sorts on two tiers: the count at the worst severity rung present
+    anywhere in the table (descending), then the aggregate score (ascending,
+    lower == worse). The leading rung cascades -- Critical, else High, else
+    Medium, else Low -- so the rung that actually discriminates between
+    repositories leads, and a lone Critical can never be buried mid-table by a
+    weaker repository with a lower score. When no offender carries a finding at
+    Low or above, the score alone orders the table.
+
+    Repo name breaks remaining ties, ascending.
+
+    Numeric components are negated so the whole sort runs ascending (no
+    ``reverse=True``); that keeps the name tiebreaker correctly ascending even
+    when one name is a prefix of another.
+    """
+    offenders = [s for s in signals if s.is_offender]
+    if not offenders:
+        return []
+    signal = offenders[0].signal
+    if signal.sort_ascending:
+        rung = lead_rung(offenders)
+        return sorted(
+            offenders,
+            key=lambda s: (
+                -s.counts.at(rung) if rung is not None else 0,
+                s.score if s.score is not None else float("inf"),
+                s.repo.name,
+            ),
+        )
+    return sorted(
+        offenders,
+        key=lambda s: (
+            -s.counts.critical,
+            -s.counts.high,
+            -s.counts.medium,
+            -s.counts.low,
+            -s.counts.total,
+            s.repo.name,
+        ),
+    )

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/report/__init__.py

@@ -37,7 +37,7 @@ from github_security_report.models import RepoSignal as RepoSignal
 from github_security_report.models import RepoState as RepoState
 from github_security_report.models import SeverityCounts as SeverityCounts
 from github_security_report.models import SignalType as SignalType
-from github_security_report.models import rank_offenders as rank_offenders
+from github_security_report.ranking import rank_offenders as rank_offenders
 from github_security_report.report.aggregate import (
     SIGNAL_ORDER,
     OrgReport,

{github_security_report-0.14.2 → github_security_report-0.15.0}/src/github_security_report/report/aggregate.py

@@ -22,8 +22,8 @@ from github_security_report.models import (
     RepoSignal,
     RepoState,
     SignalType,
-    rank_offenders,
 )
+from github_security_report.ranking import rank_offenders
 from github_security_report.report.signals import SignalSection
 from github_security_report.report.tables import TableSection