Sync Kaizen dogfood contracts

skills/kaizen-bug-router/SKILL.md

@@ -42,11 +42,11 @@ Only pass `--label` values that exist. Prefer `bug` for ordinary bug reports and
 
 Issue creation and execution authorization are separate:
 
-- Add `kaizen` by default when the label exists, but do not add `kaizen:ready` or any other execution-selection label by default.
-- Add the execution authorization label only when the user asks to queue, approve, run, execute, or put the issue on the Kaizen Loop.
-- In opt-in selection mode, add the repository's configured execution authorization label only when it exists.
-- If the user asks for immediate execution, file the issue, add the execution authorization label when available, then report the explicit command that should run next, such as `kaizen fix <issue>`.
-- If the issue needs human clarification before automation, do not add an execution authorization label; state what clarification is needed.
+- Add `kaizen` by default when the label exists, but do not add `kaizen:authorized`, `kaizen:ready`, or any other authorization or selection label by default.
+- When the user asks to queue, approve, run, execute, or put the issue on the Kaizen Loop, add both the repository's execution authorization label and its configured `issues.selection.includeLabel` when those labels exist.
+- In the managed opt-in fleet, this means adding both `kaizen:authorized` and `kaizen:ready`; either label alone leaves the issue ineligible.
+- If the user asks for immediate execution, file the issue, add both labels when available, then report the explicit command that should run next, such as `kaizen fix <issue>`.
+- If the issue needs human clarification before automation, do not add an authorization or selection label; state what clarification is needed.
 
 ## Issue Body
 

skills/pr-guardian/references/pr-feedback-audit.md

@@ -27,7 +27,6 @@ query($owner:String!, $name:String!, $number:Int!, $cursor:String) {
   repository(owner:$owner, name:$name) {
     pullRequest(number:$number) {
       headRefOid
-      headRepository { nameWithOwner }
       reviewDecision
       mergeStateStatus
       reviewThreads(first:100, after:$cursor) {
@@ -57,19 +56,7 @@ query($owner:String!, $name:String!, $number:Int!, $cursor:String) {
   if [[ -n "${cursor}" ]]; then
     args+=(-f "cursor=${cursor}")
   fi
-  if ! page="$(gh "${args[@]}")"; then
-    echo 'failed to fetch review threads' >&2
-    exit 1
-  fi
-  if ! jq -e '
-    .data.repository.pullRequest.reviewThreads as $threads
-    | ($threads | type == "object")
-      and ($threads.nodes | type == "array")
-      and ($threads.pageInfo.hasNextPage | type == "boolean")
-  ' >/dev/null <<<"${page}"; then
-    echo 'reviewThreads returned an invalid or incomplete response' >&2
-    exit 1
-  fi
+  page="$(gh "${args[@]}")"
   jq -c '.data.repository.pullRequest.reviewThreads.nodes[]' <<<"${page}"
   if [[ "$(jq -r '.data.repository.pullRequest.reviewThreads.pageInfo.hasNextPage' <<<"${page}")" != true ]]; then
     break
@@ -106,19 +93,7 @@ query($threadId:ID!, $cursor:String) {
   if [[ -n "${cursor}" ]]; then
     args+=(-f "cursor=${cursor}")
   fi
-  if ! page="$(gh "${args[@]}")"; then
-    echo 'failed to fetch review comments' >&2
-    exit 1
-  fi
-  if ! jq -e '
-    .data.node.comments as $comments
-    | ($comments | type == "object")
-      and ($comments.nodes | type == "array")
-      and ($comments.pageInfo.hasNextPage | type == "boolean")
-  ' >/dev/null <<<"${page}"; then
-    echo 'review comments returned an invalid or incomplete response' >&2
-    exit 1
-  fi
+  page="$(gh "${args[@]}")"
   jq -c '.data.node.comments.nodes[]' <<<"${page}"
   if [[ "$(jq -r '.data.node.comments.pageInfo.hasNextPage' <<<"${page}")" != true ]]; then
     break
@@ -131,15 +106,14 @@ query($threadId:ID!, $cursor:String) {
 done
 ```
 
-Exhaust each REST endpoint with `--paginate`; summaries and first pages are incomplete evidence. Check runs can be owned by either side of a fork PR: head-repository workflows usually create runs in the head repository, while base-repository Actions and installed apps can create them in the base repository. Read `headRepository.nameWithOwner` from the GraphQL response above, query both base and head repositories when they differ, and retain the repository name alongside every returned check-run ID. Fetch each run's annotations from the same repository that returned it, deduplicating identical run IDs. If either repository query fails or the head repository is unavailable, stop and report the audit as incomplete.
+Exhaust each REST endpoint with `--paginate`; summaries and first pages are incomplete evidence:
 
 ```sh
 gh api --paginate 'repos/<owner>/<repo>/pulls/<pr>/reviews?per_page=100'
 gh api --paginate 'repos/<owner>/<repo>/pulls/<pr>/comments?per_page=100'
 gh api --paginate 'repos/<owner>/<repo>/issues/<pr>/comments?per_page=100'
 gh api --paginate 'repos/<owner>/<repo>/commits/<head-sha>/check-runs?per_page=100'
-gh api --paginate 'repos/<head-owner>/<head-repo>/commits/<head-sha>/check-runs?per_page=100' # when different
-gh api --paginate 'repos/<check-run-owner>/<check-run-repo>/check-runs/<check-run-id>/annotations?per_page=100'
+gh api --paginate 'repos/<owner>/<repo>/check-runs/<check-run-id>/annotations?per_page=100'
 ```
 
 ## Reply, then resolve