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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: github-security-report
-Version: 0.14.1
+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,45 +760,89 @@ 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.
-
-The scan reads up to **20 review threads per pull request**, which is the single
-most expensive part of the prefetch (see the cost figures above). Where a pull
-request carries more threads than that and none of the collected ones qualifies,
-the pull request is treated as **indeterminate** rather than clear — see below.
+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
+newest end is deliberate: GitHub returns review threads oldest-first and offers
+no way to order them, so reading from the front would window the threads a
+review has already worked through — the resolved ones — and report a pull
+request still waiting on its latest round as clear. Unanswered feedback is the
+recent kind. Where a pull request carries more threads than the window and none
+of the collected ones qualifies, it is treated as **indeterminate** rather than
+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
@@ -1020,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
@@ -1034,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.1 → 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,45 +716,89 @@ 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.
-
-The scan reads up to **20 review threads per pull request**, which is the single
-most expensive part of the prefetch (see the cost figures above). Where a pull
-request carries more threads than that and none of the collected ones qualifies,
-the pull request is treated as **indeterminate** rather than clear — see below.
+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
+newest end is deliberate: GitHub returns review threads oldest-first and offers
+no way to order them, so reading from the front would window the threads a
+review has already worked through — the resolved ones — and report a pull
+request still waiting on its latest round as clear. Unanswered feedback is the
+recent kind. Where a pull request carries more threads than the window and none
+of the collected ones qualifies, it is treated as **indeterminate** rather than
+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
@@ -976,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
@@ -990,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.1 → 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.1'
-__version_tuple__ = version_tuple = (0, 14, 1)
+__version__ = version = '0.15.0'
+__version_tuple__ = version_tuple = (0, 15, 0)
 
 __commit_id__ = commit_id = None

{github_security_report-0.14.1 → 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.1 → github_security_report-0.15.0}/src/github_security_report/client/copilot.py

@@ -50,6 +50,11 @@ def _copilot_unresolved(node: dict) -> bool | None:
     every thread was seen. This mirrors the rule ``mergeable`` and the check
     rollup already follow: not established is not the same as nothing to report.
 
+    The window holds the *newest* threads (see ``_REVIEW_THREAD_WINDOW``), which
+    is what makes ``True`` reachable on a long review: unanswered feedback is
+    the recent kind, so a truncated window that finds nothing is a weak reading
+    rather than the usual one.
+
     An outdated thread still counts. GitHub marks a thread outdated when the
     code beneath it changes but does not resolve it, so the feedback remains
     unanswered -- which is exactly what the column reports.

{github_security_report-0.14.1 → 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.1 → 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
@@ -120,8 +131,17 @@ _ASSIGNEE_WINDOW = 10
 # without this connection and 57, 89 or 151 with a window of 5, 10 or 20. At 20
 # a 118-repository organisation costs ~755 points of the 5,000-point hourly
 # budget, which leaves room for the several organisations a scheduled run
-# covers, and 20 threads covers a realistic review cycle: this project's own
-# most-reviewed pull requests carry single-figure thread counts.
+# covers.
+#
+# The window is taken with ``last``, not ``first``, and which end it is anchored
+# to decides whether it can answer the question at all. ``reviewThreads`` is
+# ordered oldest-first and accepts no ``orderBy``, so ``first`` collects the
+# threads a review has already worked through -- exactly the ones most likely to
+# have been resolved. A pull request that has answered dozens of rounds and is
+# now waiting on the latest would fill the window with settled threads and
+# report the outstanding ones as never seen. Unresolved feedback ages into
+# resolution rather than the other way round, so the newest threads are where
+# the column's answer lives. Same node cost, opposite blind spot.
 #
 # ``totalCount`` rides along free of node cost and is what keeps the bounded
 # window honest -- a pull request carrying more threads than the window returned
@@ -170,10 +190,15 @@ fragment RepoData on Repository {{
       number
       isDraft
       mergeable
+      reviewDecision
       authorAssociation
       author {{ __typename login }}
       assignees(first: {_ASSIGNEE_WINDOW}) {{ nodes {{ login }} }}
-      reviewThreads(first: {_REVIEW_THREAD_WINDOW}) {{
+      latestOpinionatedReviews(first: {_OPINIONATED_REVIEW_WINDOW}) {{
+        totalCount
+        nodes {{ state author {{ __typename login }} }}
+      }}
+      reviewThreads(last: {_REVIEW_THREAD_WINDOW}) {{
         totalCount
         nodes {{
           isResolved

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