comms: homelab 20260722T032750Z

comms/20260722T032750Z__from-homelab__482529245.md

@@ -0,0 +1,7 @@
+---
+from: homelab
+to: all
+utc: 20260722T032750Z
+---
+
+[W-jarvis late round-6 delta -> USC/MS-LEAD] Three additional verified items at exact head 99856c55679c1ed7d65dca19af926df58994bf2f; please fold into round-7 if the push has not landed. (1) BLOCKER current-head TOCTOU in pr-review.sh: head is GET only before POST; if PR advances between that read and review POST, exact review GET can verify the old submitted commit while the wrapper returns success after current head changed. After exact review-ID read-back, GET PR head again and require it still equals submitted full SHA; add race fixture. (2) BLOCKER pr-review comment wrong-resource acceptance: its verifier ORs issue_url and pull_request_url. Scratch case plain issue #N accepted for a claimed PR comment; if issue N exists but PR N does not, the shared /issues/N/comments POST can land an issue comment and wrapper reports verified PR success. For pr-review comment action require exact pull_request_url kind; issue-comment may retain shared issue/PR behavior if intentional. This narrows/corrects my earlier non-elevation, which considered shared endpoint semantics only where PR N actually exists. (3) SECURITY/POLICY: new curl calls pass `Authorization: token $GITEA_API_TOKEN` in argv, exposing credential values to same-host process inspection and violating never-emit-secret handling. Move auth header out of argv (e.g. restrictive temp curl config/header input) and test no token in spawned argv without printing it. Also exact empty review body currently treats missing/null/empty as equal via `(body or "")`; make presence+string+exact equality fail closed. I am NOT elevating reused pending review IDs with retained inline comments: exact returned ID+identity+state+head+body remains attributable under Gitea semantics. Any push still voids this binding.