T-3HIC-wire-pr-survey-pr-update-into-orchestrate-s-merges-loop
State: closed/done · Impact: medium · Complexity: medium
sdlc pr survey and sdlc pr update are built and tested (report
every open PR’s drift from its base; bring out-of-date PRs up to date
and push, in stack order) and the plan’s execution model names them as
part of the merges loop (“on a merge, runs close-out, then pr-update
across the open PRs and stacked phase branches, then re-queues
review”), but no code path calls them from anywhere in
sdlc orchestrate. Today sdlc orchestrate only ships log-tick and
watch; the run --loop work,prs,merges op itself does not exist yet,
so this task’s job is specifically the merges loop’s use of
pr survey/pr update once that loop exists — or, per the audit’s own
alternative, dropping them from the plan if the design changes.
sdlc pr survey --repo <owner/name> and sdlc pr update --repo <owner/name> --apply work standalone and are exercised by their own
test suites (lib/services/pr/tests/survey.test.ts, update.test.ts).
Nothing in lib/services/orchestrator/ or an orchestrate run op
invokes either.
Proposed
Section titled “Proposed”Once the orchestrate run --loop work,prs,merges op exists (Phase
2’s own deliverable), its merges iteration — triggered on a detected
merge — calls pr survey to find every open PR/stacked phase branch
behind its base, then pr update --apply to restack them, before
re-queuing pr-review on the updated PRs. If, once that loop’s design
is in hand, pr-update-on-merge turns out to be redundant with
restacking already performed elsewhere, this task’s alternative is to
remove the pr-update/pr survey mention from
docs/planning/notes/N-S4AJ-sdlc-0-8-plan.md’s execution model instead, with a
one-line note explaining why.
Approach
Section titled “Approach”- Once
sdlc orchestrate run --loop <names>exists, locate itsmergesloop’s per-tick handler. - On a detected merge (a PR the loop just closed out), call
pr survey --repo <owner/name>scoped to the repo whose PR merged, to enumerate every open PR/stacked branch now behind its base. - For each PR/branch reported behind, call
pr update --repo <owner/name> --pr <n> --apply(or the batch form) to restack it. - After a successful update, mark the updated PR for a fresh pr-review pass (the loop’s existing re-queue mechanism) rather than trusting the stale prior review.
- If step 1’s loop design makes this redundant (e.g., restacking already happens elsewhere in
merges), instead edit
docs/planning/notes/N-S4AJ-sdlc-0-8-plan.md’s execution model bullet to drop the pr-update mention, with a one-line rationale, and skip steps 2-4. - Add a test exercising the
mergesloop against a fixture with a stale stacked PR, asserting either thatpr update --applywas invoked for it, or (if the drop path was taken) that the plan doc no longer claims this wiring.
| Area | Note |
|---|---|
solutions/ontological/lib/services/pr/ | ops/survey.ts, ops/update.ts; call sites only, no functional change expected |
solutions/ontological/lib/services/orchestrator/ | Wherever the merges loop iteration lives once orchestrate run exists |
docs/planning/notes/N-S4AJ-sdlc-0-8-plan.md | Only touched if the drop-from-plan alternative is taken |
Acceptance criteria
Section titled “Acceptance criteria”- AC-1: Either (a) the merges loop’s handler calls
pr surveyandpr update --applyfor the repo whose PR just merged, verified by a test that stubs/fixtures a stale stacked PR and asserts it gets updated, or (b)docs/planning/notes/N-S4AJ-sdlc-0-8-plan.md’s execution model no longer mentions pr-update in the merges loop bullet, with a one-line note explaining the removal. - AC-2: If (a), a PR updated by this wiring is queued for a fresh pr-review pass rather than left with its pre-restack review standing.
- AC-3:
bun test solutions/ontological/lib/services/orchestrator solutions/ontological/lib/services/prpasses.
Out of scope
Section titled “Out of scope”- Building the
orchestrate run --loop work,prs,mergesop itself — this task only wires pr survey/pr update into its merges iteration once that op exists. - The work and prs loop iterations.
Dependencies
Section titled “Dependencies”- The
orchestrate run --loop <names>op (Phase 2’s own core deliverable) must exist before step 2 onward can land.