Reject invalid review ranges before dispatch
Use when
A controller hands committed changes to an agent reviewer, especially across worktrees or multi-commit tasks. A wrong checkout can produce an empty range; a moving main-branch tip can make unrelated additions look like deletions. Neither is reliable review input.
Action
For
each
task,
record
BASE
before
dispatch;
afterward,
confirm
the
expected
worktree
and
branch,
then
resolve
HEAD
to
a
commit
ID.
Do
not
recompute
the
task’s
base
to
make
suspicious
execution
pass.
For
a
whole-branch
review,
resolve
the
branch
point
with
git
merge-base
origin/main
HEAD,
not
bare
origin/main.
With
an
already-authorized,
reviewed
6.4.1
installation,
run
the
helper
from
the
intended
checkout;
SP_ROOT
names
that
installation:
bash "$SP_ROOT/skills/subagent-driven-development/scripts/review-package" \
"$PLAN" "$BASE_SHA" "$HEAD_SHA"The helper requires BASE to be an ancestor and the commit range to be nonempty. Stop reviewer dispatch on failure; never reuse an old package as today’s evidence.
Acceptance check
In an owned disposable repository, BASE=HEAD and a divergent BASE must return exit 3, identify the defect, and produce no new package or reviewer dispatch. A valid multi-commit task must include every intended change. Advance main separately: branch-point review must not invent deletions. Retain endpoints, status, package, and independent task-outcome evidence. An empty commit or commit-and-revert sequence must not satisfy an unimplemented requirement merely because range validation passes.
Evidence
The dated release, merged PRs, tagged helper, and regression assertions are inspectable. Tests explicitly cover divergent ancestry and BASE=HEAD. The phantom-deletion report includes exact reproduction steps and maintainer-account triage confirmation; Git’s manual independently explains the endpoint semantics. This is shipped code, not just a prompt recommendation.
Caveat
No tests or installation were run today. Ancestry and commit count prove neither branch identity nor nonempty net changes, and the package excludes uncommitted work. Keep checkout attestation and independent acceptance. Legitimate no-change tasks need an explicit no-change disposition, not dummy commits. Upgrading also changes other workflows; this newsletter does not authorize an upgrade or adoption of the entire release.