[Kaap10]

Summary

• When a PR branch is updated or force-pushed, GitHub GraphQL's commits(last: 1) can lag behind or return a statusCheckRollup belonging to a prior commit rather than the PR's true headRefOid.
• In cr-open.graphql and cr-pr.graphql, request oid on latest: commits(last: 1) { nodes { commit { oid statusCheckRollup ... } } }.
• In pr_management.code_review.data.from_node():
  • Guard against lagging commit edges: verify commit_oid strictly matches headRefOid (case-normalized); on mismatch, fail closed by clearing rollup = {}.
  • Handle query skew defensively: if statusCheckRollup exists but commit_oid is absent (e.g. an older installed vetted-ops that lacks oid under latest), fail closed on rollup and set ci_outdated_query = True.
• In disposition.pick():
  • When ci_outdated_query is set, block APPROVE with an explicit gate ("CI rollup cannot be verified — vetted-ops is out of date (latest commit lacks OID)") and provide an actionable ci_action ("upgrade vetted-ops to update GraphQL queries, then re-run disposition"), rather than silently showing "CI is not reported".

Type of change

• Skill change (.claude/skills/<name>/) — eval fixtures updated below
• Tool / bridge contract (tools/<system>/*.md)
• Python package (tools/*/ with pyproject.toml)
• Groovy reference impl
• Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
• Documentation (docs/, README.md, CONTRIBUTING.md)
• Project template (projects/_template/)
• CI / dev loop (prek, workflows, validators)
• Other:

Test plan

• ruff check passes across tools/ and plugins/
• ruff format --check passes across tools/ and plugins/
• mypy passes (76 source files checked, 0 issues) in both tools/ and plugins/
• pytest tools/pr-management/tests/code_review/ passes (241 passed)
• Dual-tree parity verified: byte-for-byte identical match between tools/ and plugins/ for pr_management and vetted_ops
• Added unit tests in test_data.py:
  • test_from_node_accepts_matching_head_and_commit_oid
  • test_from_node_discards_rollup_when_commit_oid_mismatches_head_ref_oid (lagging commit edge guard)
  • test_from_node_discards_rollup_and_flags_outdated_query_when_commit_oid_missing (query skew handling)
  • test_from_node_discards_rollup_when_head_ref_oid_missing
  • test_from_node_accepts_rollup_case_insensitively
• Added integration tests in test_decisions.py:
  • test_pr_with_lagging_commit_edge_fails_closed_to_comment
  • test_pr_with_outdated_vetted_ops_query_gates_approval_with_upgrade_action

RFC-AI-0004 compliance

• HITL — any new mutation is gated on explicit user confirmation
• Sandbox — no new unrestricted host access; network reach declared in the adapter
• Vendor neutrality — placeholders (<PROJECT>, <tracker>, <upstream>, <security-list>) used in all skill / tool prose (the check-placeholders prek hook is the mechanical gate)
• Conversational + correctable — agentic-override path documented if behaviour is adopter-tunable
• Write-access discipline — no autonomous outbound messages; drafts only, sent on confirmation
• Privacy LLM — private content does not reach a non-approved LLM; redactor invoked where needed

Linked issues

Refs #2034 (part 1 of 2: Direction 1 fail-closed guard against lagging GraphQL commit edges, plus query-skew defense)

Notes for reviewers (optional)

• Scope of Part 1 vs code-review: APPROVE proposed on a CI rollup that did not belong to the PR head #2034: This PR implements Direction 1 of code-review: APPROVE proposed on a CI rollup that did not belong to the PR head #2034. It guards against lagging GraphQL connection edges where latest commit has not advanced to headRefOid. It does not claim to address cases where GitHub's API attaches a stale rollup to a commit node that already carries headRefOid; that case will be addressed in Direction 2 (probing check-runs for the head commit).
• Package Skew Defense: Addressed maintainer review regarding independent updates of pr-management and vetted-ops. A missing OID fails closed to prevent unverified approvals, but surfaces an explicit "vetted-ops is out of date" approval gate and ci_action so maintainers are immediately informed.

[shahar1]

This adds a fail-closed check that the CI rollup belongs to the head commit, but the case it tests is not the one #2034 reported, and a missing oid (an older vetted-ops install) looks the same as an unreported CI.

Smaller observations

• See inline comments on tools/pr-management/tests/code_review/test_data.py:82, tools/pr-management/src/pr_management/code_review/data.py:218.

Worth a second look from

Folks with the most context on these paths:

• @potiuk — 6 recent commit(s) on the changed paths (frequent contributor, not a committer)

None of them have been notified — asking any of them for an
extra pass is the maintainer's call, and optional.

---

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. The findings
below are observations, not blockers; an Apache Magpie
maintainer — a real person — will take the next look at the
PR. If you think a finding is mis-applied, please reply on
the PR and a maintainer will weigh in.

More on how Apache Magpie handles maintainer review:
Contributing guide.

[shahar1]

The head-commit check and the missing-oid handling look right and both earlier threads are addressed; two smaller points remain, about where the out-of-date-query signal shows up and the texts that describe the CI gates.

Smaller observations

• See inline comments on tools/pr-management/src/pr_management/code_review/cli.py:446, tools/pr-management/src/pr_management/code_review/disposition.py:148.

---

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. The findings
below are observations, not blockers; an Apache Magpie
maintainer — a real person — will take the next look at the
PR. If you think a finding is mis-applied, please reply on
the PR and a maintainer will weigh in.

More on how Apache Magpie handles maintainer review:
Contributing guide.

[shahar1]

maintainers are immediately informed

A missing OID fails closed to prevent unverified approvals, but surfaces an explicit "vetted-ops is out of date" approval gate and ci_action so maintainers are immediately informed.

ci_outdated_query reaches only disposition (Step 6). Under the same skew, context still prints CI: none reported (_ci_line reads only rollup_state) and returns "ci": {"state": null, "real_ci": false}, and queue ranks every PR as real-CI-never-ran with no announcement. The maintainer reads the wrong headline for the whole review and learns the cause at the last step. Have _ci_line return something like CI: cannot be verified (vetted-ops query out of date) when the flag is set, and carry the flag in the ci object; a queue announcement can follow in part 2.

[shahar1]

Spec-sync pre-check before pushing a functionality PR

Before pushing a PR that ships or changes a skill, tool, or mode — and before pushing a rebase of one onto a main that has moved — confirm tools/spec-loop/.last-sync is at (or near) the current main tip and that the affected specs reflect what actually shipped.

This adds a CI gate and a third meaning of ci_action, and two texts still describe the old set. tools/spec-loop/specs/pr-management-family.md lists the gates as "Failing CI, a rollup green from bot checks only, and workflows waiting for approval". plugins/magpie-pr-management/skills/code-review/review-flow.md (Step 6) tells the agent "When ci_action is set, the project's workflows have not run (waiting for approval, or bot checks only)", which is now wrong for the upgrade case: the agent would point the maintainer at workflow approval. Add the head-commit rule and the out-of-date-query gate to both.