diff --git a/.agents/skills/finish-pr/SKILL.md b/.agents/skills/finish-pr/SKILL.md index 9858b30..d84cd79 100644 --- a/.agents/skills/finish-pr/SKILL.md +++ b/.agents/skills/finish-pr/SKILL.md @@ -46,9 +46,15 @@ Never request an automated review (`@coderabbitai review`, `@codex review`, or a timed re-request after a rate limit); reviews arrive on their own. Budget the loop: at most two review rounds after the first green head. When actionable findings keep arriving past that, keep the green head and triage the remaining findings yourself -with a concrete accept or push-back. Open one stacked follow-up PR for the accepted -fixes, then reply to each deferred finding with that PR's URL and resolve it: the -named follow-up is the disposition, not a promise. +with a concrete accept, push-back, or defer. Open one stacked follow-up PR for the +accepted fixes, then reply to each deferred finding with that PR's URL, and resolve +the thread where the finding has one: the named follow-up is the disposition, not a +promise. A deferred top-level comment stays open; the reply is its terminal state. + +The budget never defers a release-blocking defect. A finding that names a +security, authorization, data-loss, or data-corruption defect, and survives +verification, is fixed on this head however late it arrives: shipping a known +defect to keep a round count is the outcome the budget exists to avoid. ## 4. Stop at a Real Terminal State @@ -58,7 +64,8 @@ The latest pushed head has converged only when: - automated reviewers are terminal, not pending - no actionable automated finding remains in a review thread or a top-level comment: each is implemented, already addressed, pushed back with evidence, - or deferred to a named follow-up PR + or deferred to a named follow-up PR, and no verified release-blocking defect + was deferred - no unresolved human request for changes remains - no blocking review or merge conflict remains diff --git a/.agents/skills/open-pr/SKILL.md b/.agents/skills/open-pr/SKILL.md index 886e3cc..0af0aff 100644 --- a/.agents/skills/open-pr/SKILL.md +++ b/.agents/skills/open-pr/SKILL.md @@ -19,12 +19,17 @@ defaults to the fork and would miss an upstream PR: git branch --show-current git status --short gh pr list --repo "$BASE_REPO" --head "$(git branch --show-current)" \ - --state all --json number,state,isDraft,headRefName,baseRefName,url + --state all \ + --json number,state,isDraft,headRefName,headRepositoryOwner,baseRefName,url ``` -An empty PR list means no PR exists. Authentication, network, or repository -errors must remain visible and stop the workflow before history changes or -publication. +An empty PR list means no PR exists. `--head` filters by branch name alone, so +in a fork workflow the list can hold another contributor's PR from a branch of +the same name: treat a result as this checkout's PR only when its +`headRepositoryOwner` is the owner your head remote pushes to. + +Authentication, network, or repository errors must remain visible and stop the +workflow before history changes or publication. Never prepare a PR in a dirty shared checkout. If the checkout is on the default branch, detached, has unrelated changes, or spans repositories or diff --git a/.agents/skills/rabbit-round/SKILL.md b/.agents/skills/rabbit-round/SKILL.md index 7815f75..5561af6 100644 --- a/.agents/skills/rabbit-round/SKILL.md +++ b/.agents/skills/rabbit-round/SKILL.md @@ -18,9 +18,13 @@ identified. Fetch paginated review threads through GitHub GraphQL so unresolved state and thread replies are preserved. Fetch top-level issue comments separately. Record every participant and reply author in a thread, which comments apply to the -current head, and which are stale. Treat a thread as bot-authored only when every -participant is a confirmed allowed bot; a mixed or uncertain thread follows the -human-thread rules. +current head, and which are stale. Classify participants from a fresh fetch. +Record a receipt for every workflow reply with its returned reply-node ID and +exact content, and retain those receipts across resume or handoff. On later +fetches, exclude only replies matched to an exact receipt; never infer an +exclusion from the requester account or an attribution footer. All remaining +participants must be confirmed allowed bots; a human, mixed, or uncertain thread +follows the human-thread rules. Do not rely only on the REST review-comments list: it does not represent thread resolution or the complete conversation reliably. @@ -37,7 +41,10 @@ comment: - **Push back**: incorrect, stale, speculative, or contrary to documented constraints. - **Defer**: accepted, but landing in a named follow-up PR because the enclosing - workflow's review budget is spent. Only with the follow-up PR's URL. + workflow's review budget is spent. Only with the follow-up PR's URL, and every + defer in one run names the same PR. Never for a verified release-blocking + defect (security, authorization, data loss, corruption): those are fixed on the + current head. Read the cited code and applicable instructions before deciding. Treat security, authorization, data loss, and compatibility claims as hypotheses to verify, not @@ -69,11 +76,14 @@ finding. Keep responses short and factual: Follow repository attribution rules for GitHub comments. Do not claim a check passed unless it ran successfully on the reported head. -After replying, resolve only review threads whose every participant is a -confirmed allowed bot and that are implemented, already addressed, answered -with a supported pushback, or deferred to a named follow-up PR. Leave human, mixed-participant, and uncertain threads -open. Top-level comments have no thread-resolution state; do not minimize bot -summaries by default. +After replying, refetch each candidate thread before resolving it. Exclude only +exact workflow reply receipts, then require every remaining participant to be a +confirmed allowed bot. Triage any new bot finding before resolving; any human, +unknown, mixed-participant, or uncertain arrival leaves the thread open. Resolve +only when the finding is implemented, already addressed, answered with supported +pushback, or deferred to a named follow-up PR. Top-level comments have no +thread-resolution state: a reply naming the follow-up PR is the whole disposition +there. Do not minimize bot summaries by default. ## 5. Recheck the Current Head @@ -81,7 +91,10 @@ Refresh the PR after the push and report one status: - `clean`: all current-head automated reviewers are terminal, required checks are green, and no actionable automated finding remains in a review thread or - top-level comment + top-level comment. A top-level finding answered with a defer reply carrying the + follow-up PR's URL is no longer actionable on later rounds, unless it names a + verified release-blocking defect: no defer makes one of those non-actionable, + and the status stays `needs_changes` until it is fixed on the current head - `pending_bots`: this round pushed the current head, or a current-head automated review or required check is still running - `needs_changes`: actionable automated feedback remains diff --git a/.ai/shared b/.ai/shared index 2c81187..e4fad0b 160000 --- a/.ai/shared +++ b/.ai/shared @@ -1 +1 @@ -Subproject commit 2c81187ed1c93d60f340e266b26b79d2c7f6d952 +Subproject commit e4fad0b0c8f3d519c44deacd069262e28582400a diff --git a/.claude/skills/finish-pr/SKILL.md b/.claude/skills/finish-pr/SKILL.md index 9858b30..d84cd79 100644 --- a/.claude/skills/finish-pr/SKILL.md +++ b/.claude/skills/finish-pr/SKILL.md @@ -46,9 +46,15 @@ Never request an automated review (`@coderabbitai review`, `@codex review`, or a timed re-request after a rate limit); reviews arrive on their own. Budget the loop: at most two review rounds after the first green head. When actionable findings keep arriving past that, keep the green head and triage the remaining findings yourself -with a concrete accept or push-back. Open one stacked follow-up PR for the accepted -fixes, then reply to each deferred finding with that PR's URL and resolve it: the -named follow-up is the disposition, not a promise. +with a concrete accept, push-back, or defer. Open one stacked follow-up PR for the +accepted fixes, then reply to each deferred finding with that PR's URL, and resolve +the thread where the finding has one: the named follow-up is the disposition, not a +promise. A deferred top-level comment stays open; the reply is its terminal state. + +The budget never defers a release-blocking defect. A finding that names a +security, authorization, data-loss, or data-corruption defect, and survives +verification, is fixed on this head however late it arrives: shipping a known +defect to keep a round count is the outcome the budget exists to avoid. ## 4. Stop at a Real Terminal State @@ -58,7 +64,8 @@ The latest pushed head has converged only when: - automated reviewers are terminal, not pending - no actionable automated finding remains in a review thread or a top-level comment: each is implemented, already addressed, pushed back with evidence, - or deferred to a named follow-up PR + or deferred to a named follow-up PR, and no verified release-blocking defect + was deferred - no unresolved human request for changes remains - no blocking review or merge conflict remains diff --git a/.claude/skills/open-pr/SKILL.md b/.claude/skills/open-pr/SKILL.md index 886e3cc..0af0aff 100644 --- a/.claude/skills/open-pr/SKILL.md +++ b/.claude/skills/open-pr/SKILL.md @@ -19,12 +19,17 @@ defaults to the fork and would miss an upstream PR: git branch --show-current git status --short gh pr list --repo "$BASE_REPO" --head "$(git branch --show-current)" \ - --state all --json number,state,isDraft,headRefName,baseRefName,url + --state all \ + --json number,state,isDraft,headRefName,headRepositoryOwner,baseRefName,url ``` -An empty PR list means no PR exists. Authentication, network, or repository -errors must remain visible and stop the workflow before history changes or -publication. +An empty PR list means no PR exists. `--head` filters by branch name alone, so +in a fork workflow the list can hold another contributor's PR from a branch of +the same name: treat a result as this checkout's PR only when its +`headRepositoryOwner` is the owner your head remote pushes to. + +Authentication, network, or repository errors must remain visible and stop the +workflow before history changes or publication. Never prepare a PR in a dirty shared checkout. If the checkout is on the default branch, detached, has unrelated changes, or spans repositories or diff --git a/.claude/skills/rabbit-round/SKILL.md b/.claude/skills/rabbit-round/SKILL.md index 7815f75..5561af6 100644 --- a/.claude/skills/rabbit-round/SKILL.md +++ b/.claude/skills/rabbit-round/SKILL.md @@ -18,9 +18,13 @@ identified. Fetch paginated review threads through GitHub GraphQL so unresolved state and thread replies are preserved. Fetch top-level issue comments separately. Record every participant and reply author in a thread, which comments apply to the -current head, and which are stale. Treat a thread as bot-authored only when every -participant is a confirmed allowed bot; a mixed or uncertain thread follows the -human-thread rules. +current head, and which are stale. Classify participants from a fresh fetch. +Record a receipt for every workflow reply with its returned reply-node ID and +exact content, and retain those receipts across resume or handoff. On later +fetches, exclude only replies matched to an exact receipt; never infer an +exclusion from the requester account or an attribution footer. All remaining +participants must be confirmed allowed bots; a human, mixed, or uncertain thread +follows the human-thread rules. Do not rely only on the REST review-comments list: it does not represent thread resolution or the complete conversation reliably. @@ -37,7 +41,10 @@ comment: - **Push back**: incorrect, stale, speculative, or contrary to documented constraints. - **Defer**: accepted, but landing in a named follow-up PR because the enclosing - workflow's review budget is spent. Only with the follow-up PR's URL. + workflow's review budget is spent. Only with the follow-up PR's URL, and every + defer in one run names the same PR. Never for a verified release-blocking + defect (security, authorization, data loss, corruption): those are fixed on the + current head. Read the cited code and applicable instructions before deciding. Treat security, authorization, data loss, and compatibility claims as hypotheses to verify, not @@ -69,11 +76,14 @@ finding. Keep responses short and factual: Follow repository attribution rules for GitHub comments. Do not claim a check passed unless it ran successfully on the reported head. -After replying, resolve only review threads whose every participant is a -confirmed allowed bot and that are implemented, already addressed, answered -with a supported pushback, or deferred to a named follow-up PR. Leave human, mixed-participant, and uncertain threads -open. Top-level comments have no thread-resolution state; do not minimize bot -summaries by default. +After replying, refetch each candidate thread before resolving it. Exclude only +exact workflow reply receipts, then require every remaining participant to be a +confirmed allowed bot. Triage any new bot finding before resolving; any human, +unknown, mixed-participant, or uncertain arrival leaves the thread open. Resolve +only when the finding is implemented, already addressed, answered with supported +pushback, or deferred to a named follow-up PR. Top-level comments have no +thread-resolution state: a reply naming the follow-up PR is the whole disposition +there. Do not minimize bot summaries by default. ## 5. Recheck the Current Head @@ -81,7 +91,10 @@ Refresh the PR after the push and report one status: - `clean`: all current-head automated reviewers are terminal, required checks are green, and no actionable automated finding remains in a review thread or - top-level comment + top-level comment. A top-level finding answered with a defer reply carrying the + follow-up PR's URL is no longer actionable on later rounds, unless it names a + verified release-blocking defect: no defer makes one of those non-actionable, + and the status stays `needs_changes` until it is fixed on the current head - `pending_bots`: this round pushed the current head, or a current-head automated review or required check is still running - `needs_changes`: actionable automated feedback remains