Opt-in serial task dependencies#
Mainline supports an opt-in serial plan of 1–8 ordered required items in one repository, with one final PR (spec 059). The feature flag is off by default. The whole plan is approved up front; failure pauses for an explicit owner retry. This does not introduce an arbitrary parallel dependency graph.
For a change across several repositories, Rovara loop runs one loop per pull request on your computer.
When work is blocked#
A blocked step says why and offers the owner’s options: retry planning, send back to coding, retry reviews, retry opening the PR, or close the task. Inspect the reason before retrying. What to do at each step →
Track the complete PR set#
Rovara Code registers the PRs it opens against the task. GitHub events arrive signed, and missed deliveries are recovered; unrelated PR events do not advance this task. GitHub’s API remains the authority on PR state.
Understand partial merges#
The task finishes when GitHub reports every required PR merged; a coding tool then shows it as closed with stage MERGED. A partial merge stays incomplete. If a linked PR reopens, inspect the updated task state rather than relying on an earlier notification.
Recover without creating duplicate work#
Read current task state and authoritative PR links first. Event delivery can be retried, so duplicate notices should not be treated as permission for a new coding run. Use the installed retry action for a blocked operation and inspect its result.
Work starts with an explicit request#
Hosted Rovara Code starts work only when asked in Slack or through your coding tool. Creating or updating a GitHub issue does not start a hosted task. PR comments produce feedback proposals; the owner approves fixes before implementation.
The separate Rovara loop runs on your own computer and does start work from collaborators’ /rovara comments on issues.