feat: sandcastle reworks PRs with requested changes #39
No reviewers
Labels
No labels
in-review
ready-for-agent
ready-for-human
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
weiwen/evie!39
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "sandcastle/issue-21"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #21
What changed and why
The sandcastle planner previously only handled CI-failure rework on open PRs. This adds a second rework path: when a human reviewer submits a REQUEST_CHANGES review, the planner picks up the PR and the pr-fixer addresses the feedback, then re-queues it for human review.
New Forgejo Actions workflow —
.github/workflows/pr-triage.ymlForgejo Actions does not support the
pull_request_reviewtrigger available in GitHub Actions. The workflow fires onon: pull_requestinstead (which also fires on review comments), then queries the reviews API directly to check whether the latest non-COMMENT/non-PENDING review state isREQUEST_CHANGES. When it is, it addsready-for-agentand removesready-for-humanfrom the PR. It uses the automatic runner token and falls back to aFORGEJO_TOKENActions secret if label-write permissions are insufficient.Plan schema and orchestrator —
.sandcastle/main.mts+plan-prompt.mdThe
planSchemaandPrReworkItemtype now include areworkReasonfield ("ci-failure" | "review-requested-changes"). The planner query inplan-prompt.mduses ajqexpression to separate the two signals: a PR withready-for-agentisreview-requested-changes(takes priority); a PR withci == "failure"and noready-for-agentisci-failure. TheREWORK_REASONenv var is passed into each pr-fixer sandbox.PR-fixer prompt —
.sandcastle/pr-fixer-prompt.mdThe prompt is now branched on
{{REWORK_REASON}}:ci-failure: unchanged behaviour — reproduce, fix, push, comment; no relabelling.review-requested-changes: read the reviews API + inline comments, address the feedback, run the check gate, push, then relabelready-for-agent → ready-for-humanand post a summary comment. The relabel is mandatory to prevent the planner from re-picking the PR.Also fixed the
tea commentcommand syntax to use the validtea commentsubcommand (nottea comment create).Docs —
docs/agents/triage-labels.mdUpdated to document both rework paths, the pr-triage workflow design rationale (Forgejo
pull_request_reviewlimitation), label-edit authentication, and the accepted limitation for reviews with no comment thread.Key decisions
on: pull_requestas a substitute forpull_request_review: This is the only workable Forgejo trigger for review events. The reviews-API guard ensures the workflow only acts on actual REQUEST_CHANGES events.ready-for-agentas the signal: Using a label (set by automation) rather than querying the reviews API from the planner keeps the planner query simple (tea pulls list) and avoids a per-PR API call in the planning phase.ready-for-agentwins. This is correct because a human has explicitly requested changes, and the CI may be failing for the same reason.Reviewer checklist
pr-triage.yml: does thejqfilter correctly identify REQUEST_CHANGES vs COMMENT/PENDING/APPROVED?pr-triage.yml: does the label-resolve + add/delete API call sequence look correct for Forgejo's labels API?plan-prompt.md: does thejqexpression correctly separateci-failurefromreview-requested-changeswhen both signals are present?pr-fixer-prompt.md: are thetea commentandtea pulls review-commentscommands valid for the version ofteain use?pull_request) is correctly documented and acceptable.