jules-delivery

Create a GitHub issue from the jules-issue template with outcome, in-scope and out-of-scope paths, acceptance criteria, and finite verification commands, then validate the companion brief JSON. Add the `jules` label only after the issue is complete and approved.

Build a phase plan where every task in a phase has zero dependencies and exclusive fileOwnership paths. The validate_jules_phase_plan.py script rejects overlapping paths or misplaced dependencies, and the next phase launches only after all prior PRs pass independent review.

Use a GitHub issue for planned product work needing a durable decision record and PR audit trail. Use `jules remote new` for fast, individual, bounded tasks from the current repository, and reserve the alpha API for automation with requirePlanApproval set to true.

Keep tasks involving secrets, production access, destructive migrations, authentication, payments, or unapproved untrusted input local. The brief validator also rejects high- and critical-risk work, since those changes must not be dispatched to a remote VM.

Inspect the full diff locally, run every project-declared verification command, and record results in the jules-review-record.json with exit codes and output digests. The reviewer identity must differ from Jules, and a passing Jules summary alone is not accepted as evidence.

Send one scoped correction using the jules-feedback template with the exact failing command output, the unmet criterion, and the minimal remediation. If the corrected result still fails, close or quarantine the PR and decompose the remaining work instead of looping indefinitely.