fix: write PR body edits before pushes and push once per review round

[kyle-sexton]

No related issue: CI-volume follow-up from the wave-2 waste audit (section J), which has no tracker item.

Summary

Agent lanes multiply CI runs on one pull-request head. Measured over a week: 730 contract-only runs, mostly PR body edits within a minute of a push; 305 runs cancelled by a newer push from the same lane; 345 draft runs cancelled by the ready flip. This changes the lane instructions so a PR body or label edit lands before the push that triggers CI (or after its run finished), and fixes go up in one push per round instead of one per finding.

Fix

• implementation: implement Step 4 and implement-dispatch Phase boundaries write a plan refresh in the PR body before the push, or after its run finished. implement-dispatch keeps the early push only for the time before the PR exists; a worker dispatched onto an open PR pushes once after its change set passes.
• work-items: /work-items:work waits until every CI and reviewer check run on the head finished, then hands every failing check and finding to one fix worker that pushes once; the deferred-finding ## Related write precedes that push.
• source-control: monitor.md section 3.3.2 gains step 0 (wait for every reviewer on the head before pushing; CI fixes from section 3.2 share the push); D6 in SKILL.md and review-discipline.md pushes once per round; ready-for-review.md pushes the security review's commits in one push right before gh pr ready, and records that gh pr update-branch already pushes nothing when the head contains the base tip; babysit-prs starts a comment wave only after every reviewer check run on the head completed.
• playbooks: repo-sweep next ticks the committed step before pushing it.
• Patch bumps with changelog entries: implementation 0.20.3, work-items 0.44.3, source-control 0.73.1, playbooks 0.17.3 (main took 0.20.1, 0.20.2 and 0.17.2 while this branch was open; merged forward).

Verification

• markdownlint-cli2 over the 13 changed markdown files: 0 issues.
• scripts/check-changed-skills.sh origin/main: implement, implement-dispatch, pull-request, babysit-prs and work PASS. repo-sweep FAILs locally only on its bundled state.test.sh and tick.test.sh, whose scripts this PR does not touch; the failures are CRLF byte comparisons under Git Bash on Windows, and CI on Linux is the check of record.
• scripts/affected-tests.sh --run --jobs 4 (87 suites) on Windows, stopped at the one-hour limit after 48 suites: 41 pass, 7 fail, all in plugins this PR does not touch (instruction-placement timing and symlinks, ai-slop no-git PATH shim, harness-config concurrency, skill-quality, testing hooks). CI on Linux is the check of record.
• gh pr update-branch skipping an up-to-date head: cli/cli pkg/cmd/pr/update-branch/update_branch.go, the BehindBy == 0 return, read 2026-10-02.

Related

• Wave-2 waste audit section 5 and item J; volume diagnosis R2, R5, R6.
• The CI side (ci-status no-wait, draft runs without lint) is owned by separate PRs.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-02T23:27:56.757363Z	8da77cd	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8da77cda48

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Claude finished @kyle-sexton's task in 3m 5s —— View job

---

Security review (/review:security-review)

• Gather context (PR body, diff, review comments)
• Understand the request: custom instructions require invoking /review:security-review for this PR
• Run /review:security-review against PR fix: write PR body edits before pushes and push once per review round #5899 (base origin/main, head 764b7424adcbedfc7951752ace7edd97f613b629)
• Post findings

Scope: all 18 changed files are markdown (skill/changelog bodies) and plugin.json version bumps
plus one evals.json expectation update — no application code, no GitHub Actions workflow files,
no secrets/credential handling touched. Per this lane's criteria, a diff that only edits standing
instructions is checked under the instruction-surface-deletion lens before being waved through
as "prose-only."

1 finding, posted inline — plugins/playbooks/skills/repo-sweep/reference/next.md lines 139–146:

IMPORTANT — reordering tick-before-push removes the only guarantee that a "done" step actually
shipped. This diff flips S/tick.sh <id> committed <sha> ... (which writes "step done" into the
remote PR body) to run before git push, to avoid a second CI run on the bot's own edited
event. The only backstop is "a failed push is retried before anything else," which covers an
in-session push failure but not a session dying or losing network between the tick and the push.

Walked the two scripts this reference drives:

• tick.sh only verifies its own edit landed on the PR body — it never checks the committed <sha>
  is reachable from the remote branch.
• state.sh (plugins/playbooks/skills/repo-sweep/scripts/state.sh:112,120) skips any line already
  marked [x] with a committed <sha> tail before it cross-checks that sha against git log —
  a ticked-done line is never re-examined.

Exploit path: commit the step, tick it done, session dies before push — exactly the crash scenario
state.sh's own exit-14 flow anticipates (fresh fetch + worktree on another machine/session). That
fresh worktree never received <sha>; state.sh reads the body, sees [x], treats it as done. The
step and its commit are silently dropped, while the shared PR body keeps asserting work that was
never pushed. The previous order (push, then tick) made this structurally impossible: the body
could only be marked done after the commit was confirmed on the remote.

This matches this repo's data-integrity class in the
instruction exception register
— one of the protected classes a trimming/reordering pass may not weaken — and nothing else in the
tree reconciles a ticked line against remote reachability to cover the gap this reorder opens. (The
automated Codex review already flagged this reorder as a P2 correctness issue; it's reported here
too because it also falls inside this lane's protected-class check, not just general code quality.)

Suggested fix: keep push before tick. If the double-CI-run cost this PR is solving still needs
addressing, solve it by suppressing/ignoring the workflow run the bot's own edited event
triggers, not by letting the record of "done" outrun the fact it describes.

No other findings — the remaining changes (push/tick ordering elsewhere, wait-for-reviewers
batching, gh pr update-branch no-op note, version bumps, changelog entries) are additive timing
changes that don't remove or weaken an existing check, authorization gate, or guardrail.

[claude]

Claude finished @kyle-sexton's task in 5m 40s —— View job

---

Code review (/review:code-review)

• Gather context (PR diff, changed files, CLAUDE.md/AGENTS.md rules)
• Run /review:code-review criteria over the diff
• Post inline findings
• Final summary

This PR is documentation-only (plugin skill/reference markdown), reordering when PR-body edits and pushes happen to cut duplicate CI runs. Posted 5 inline findings on the diff; the first three are the high-confidence ones.

Systemic issue: the "batch fixes, push once per round" rewrite wasn't applied consistently. monitor.md §3.3.2 restructured its fix phase into an explicit batch (wait → fix-all → one commit → one push), so there's no gate conflict. But the same push-batching line was dropped into two other places that still run a per-finding loop with a verification gate between each step:

• review-discipline.md:258 and the identical pull-request/SKILL.md:186: D6 defers the push to "once for the whole round," but the very next bullet, "verify commit pushed" (git merge-base --is-ancestor <fix-sha> FETCH_HEAD), is unchanged and still gates each finding's move from D6 to D7. For every finding but the one that happens to coincide with the round's actual push, that gate fails with no documented recovery, stalling the checklist before D7/D7.5.
• babysit-prs/reference/loop.md:416: the new "start a wave's fixes only after every reviewer check run completes" line sits right below §5.1.4's untouched per-finding lane_push step (line 409), which still pushes after each individual fix — so the wave-batching instruction has nothing to defer.

repo-sweep/reference/next.md:138-145: confirms and extends the Codex review comment already on this hunk. tick.sh writes the "done, committed <sha>" line straight to the remote PR body before the push happens under the new order. I traced state.sh's reconciliation logic: once a line reads [x] ... committed <sha>, it's treated as fully resolved with no check that <sha> is reachable — that path only exists for the reverse case (local commit, not yet ticked). A session that dies between the tick and the push leaves the remote body falsely claiming the step is done, and the new "failed push is retried" clause only covers a push that errors out, not one that never runs. The old push-then-tick order didn't have this window.

Minor: ready-for-review.md:79 says "push it all in one push" without showing the command, unlike every other git-mutating step in that file; the plugin's canonical push path elsewhere resolves the remote explicitly to avoid pushing to a fork's wrong remote.

Also noted, not filed as inline findings: the PR body's "Patch bumps" line lists source-control 0.73.1 and implementation 0.20.3, but the actual diff bumps those to 0.74.1 and 0.20.4 respectively — looks like the description went stale after a merge-forward and wasn't updated to match the final version bumps.

Verification commands the PR description cites (markdownlint, check-changed-skills.sh, affected-tests.sh) were not independently re-run; treat those as author-claimed.

[claude]

Claude finished @kyle-sexton's task in 2m 1s —— View job

---

Code review (/review:code-review)

• Gather context (PR diff, changed files, CLAUDE.md/AGENTS.md rules)
• Run /review:code-review criteria over the diff
• Post inline findings (none new; see below)
• Final summary

Skip gate hit (criterion 4): this head's PR diff is unchanged from the already-reviewed commit.

The synchronize that triggered this run (764b742 → 1381be8) is a merge-forward from origin/main
only. I diffed the two commits directly:

• The five files carrying this lane's open findings — plugins/playbooks/skills/repo-sweep/reference/next.md,
  plugins/source-control/reference/review-discipline.md, plugins/source-control/skills/pull-request/SKILL.md,
  plugins/source-control/skills/pull-request/reference/monitor.md, plugins/source-control/skills/babysit-prs/reference/loop.md,
  and plugins/source-control/skills/pull-request/reference/ready-for-review.md — are byte-identical between
  764b742 and 1381be8 (git diff 764b742 1381be8 -- <those files> returns nothing).
• git diff origin/main...HEAD --stat at the current head matches the PR description's own numbers exactly
  (18 files, +85/-22), confirming the merge didn't fold in any new edits to this PR's own content, only
  version-number churn in plugin.json/CHANGELOG.md from rebasing onto main's own patch releases
  (e.g. implementation now reads 0.20.5, source-control 0.74.2 — further ahead of what the PR
  body's "Patch bumps" line claims, which was already flagged as stale in the prior round).

So there is no new review surface on this head. The two findings already posted against 764b742 by
this lane still apply unaddressed:

• next.md:139-146 —
  tick-before-push lets a session death between the two calls leave the remote PR body claiming a step is
  committed <sha> when that commit never reached the remote; neither tick.sh nor state.sh reconciles
  a ticked line against remote reachability.
• review-discipline.md:258 /
  pull-request/SKILL.md:186 —
  D6 defers the push to "once for the whole round," but the unchanged "verify commit pushed" gate right
  below it still checks git merge-base --is-ancestor <fix-sha> FETCH_HEAD per finding, which fails for
  every finding but the one coinciding with the round's actual push.
• babysit-prs/reference/loop.md:416 —
  the new wave-batching guidance sits above §5.1.4's untouched per-finding lane_push step, so the
  per-finding loop still pushes before the batching paragraph can apply.
• Minor: ready-for-review.md:79 —
  "push it all in one push" names no command, unlike every other git-mutating step in the file.

No new inline comments posted — the diff content anchoring the existing threads hasn't moved, so a
fresh inline comment would duplicate them rather than add signal.

[claude]

Claude finished @kyle-sexton's task in 2m 36s —— View job

---

Security review (/review:security-review)

• Gather context (PR body, diff, prior review comments)
• Check skip gate / whether prior review still applies to new HEAD
• Run /review:security-review against PR fix: write PR body edits before pushes and push once per review round #5899 (base origin/main, head 1381be8a64cce42ffab3bd4b4e2deae772fa5ec4)
• Post findings

Skip gate hit: criterion 3 ("this head already has a successful security review that still applies").

This synchronize event is a merge-forward only: git log shows the branch picked up two
unrelated origin/main commits (89556c8 campfire/restart-consumer fix, 8849482 test-windows
trigger scoping) via merge commit 1381be8. Diffing origin/main...HEAD (three-dot, i.e. the
PR's actual changeset) against the diff already reviewed at the prior head (764b742) shows byte-identical content in every one of the 18 files — same hunks, same line counts. The large
two-dot diff between those two SHAs is just main's independent, unrelated evolution of some of
the same files (e.g. implement/SKILL.md gained unrelated session-flow routing prose on main)
getting folded in by the merge; none of it is part of this PR's diff.

So the review already completed on this PR stands. Restating its one finding, since it's still
present and still applies at this head:

IMPORTANT — plugins/playbooks/skills/repo-sweep/reference/next.md lines 139–146 — reordering tick.sh (writes committed <sha> into the remote PR body) before git push removes the only guarantee that a step marked "done" actually reached the remote. tick.sh never checks <sha> is reachable from the branch, and state.sh (plugins/playbooks/skills/repo-sweep/scripts/state.sh:112,120) skips any line already ticked [x] with a committed <sha> tail without re-checking it against git log. A session dying between the tick call and the push — the exact crash scenario state.sh's own exit-14 flow anticipates (fresh fetch + worktree elsewhere) — leaves the remote PR body asserting a commit that never left the local worktree, and nothing in the tree reconciles that gap. This falls under the data-integrity protected class in the instruction exception register: the old push-then-tick order made the body-says-done claim structurally dependent on the commit already being remote; this reorder trades that guarantee for avoiding a second CI run, with no replacement safeguard. Already posted inline on this PR (both by the automated Codex review and by this lane's prior pass at commit 764b742) — not re-posted here as a duplicate. Suggested fix: keep push before tick; if the double-CI-run cost still needs solving, suppress/ignore the workflow run triggered by the bot's own edited event instead.

No other security findings. Everything else in the diff (push-timing changes in monitor.md, review-discipline.md, pull-request/SKILL.md, babysit-prs/loop.md, implement/implement-dispatch, work-items/work/SKILL.md, ready-for-review.md, version bumps, changelog entries) is additive timing/sequencing guidance that doesn't remove or weaken an existing check, authorization gate, or guardrail — it's a scope the code-review lane already covers for workflow-correctness gaps (e.g. the D6 "verify commit pushed" gate now being unsatisfiable mid-round), not a security issue.

[claude]

Claude finished @kyle-sexton's task in 1m 49s —— View job

---

Code review (/review:code-review)

• Gather context (PR diff, changed files, CLAUDE.md/AGENTS.md rules)
• Check skip gate against prior review on this lane
• Run /review:code-review against PR fix: write PR body edits before pushes and push once per review round #5899 (base origin/main, head 75d37d8fecbd3ab8ac033237bc2b0f0b7ab7fea0)
• Post findings (none new; see below)

Skip gate hit (criterion 4): this head's PR diff is unchanged from the already-reviewed commit.

The synchronize that produced this head is another merge-forward only: 75d37d8 = 1381be8 merged
with origin/main (which had since picked up a48b6be, an unrelated multi-agent refactor in the
bugs plugin). Comparing git diff origin/main...HEAD at this head against the diff already
reviewed at 1381be8:

• --stat is identical: 18 files, +85/-22, matching the PR description's own numbers.
• Every hunk in the five files carrying this lane's open findings (next.md,
  review-discipline.md, pull-request/SKILL.md, babysit-prs/loop.md, ready-for-review.md)
  is byte-identical in content to what was already reviewed — only monitor.md and the
  plugin.json/CHANGELOG.md version-bump files show line-number drift, from unrelated upstream
  edits elsewhere in those files picked up by the merge, not from this PR's own changes.

So there is no new review surface on this head. The findings already posted against this PR by
this lane (and independently by Codex) still apply unaddressed, now at these locations:

• next.md:139-146 —
  tick-before-push lets a session die between tick.sh (writes committed <sha> into the remote
  PR body) and git push, leaving the remote body claiming a step is done when the commit never
  reached the remote. Neither tick.sh nor state.sh reconciles a ticked [x] line against
  remote reachability.
• review-discipline.md:263-264
  and the identical D6 wording in
  pull-request/SKILL.md:186 —
  the push is now deferred to "once for the whole round," but the "verify commit pushed" gate right
  below it (unchanged by this PR) still checks git merge-base --is-ancestor <fix-sha> FETCH_HEAD
  per finding, which fails for every finding but the one that happens to coincide with the round's
  actual push. The per-finding D1–D7 loop above these lines was never restructured into a batch,
  unlike monitor.md §3.3.2's Phase A/Phase B split.
• babysit-prs/loop.md:416 —
  the new wave-batching guidance sits above §5.1.4's untouched per-finding lane_push step, so the
  per-finding fix cycle still pushes after each individual finding, making the "push a partial
  wave" deferral unreachable as written.
• Minor: ready-for-review.md:79 —
  "push it all in one push" names no command, unlike every other git-mutating step in the file.

No new inline comments posted — the diff content anchoring the existing threads hasn't moved
(only line numbers shifted slightly from unrelated upstream edits), so a fresh inline comment would
duplicate the threads already open rather than add signal.

[claude]

Claude finished @kyle-sexton's task in 2m 27s —— View job

---

Security review (/review:security-review)

• Gather context (PR body, diff, prior review comments)
• Check skip gate / whether prior review still applies to new HEAD
• Run /review:security-review against PR fix: write PR body edits before pushes and push once per review round #5899 (base origin/main, head 75d37d8fecbd3ab8ac033237bc2b0f0b7ab7fea0)
• Post findings

Skip gate hit: criterion 3 ("this head already has a successful security review that still applies").

This synchronize event is another merge-forward only: git log 1381be8..75d37d8 shows one new
commit, a48b6be (refactor(bugs): route scan stage models through multi-agent), which only
touches the bugs plugin and (incidentally) plugins/source-control/reference/review-discipline.md
prose unrelated to this PR's changes. Confirming the PR's actual diff is unchanged:

• git diff origin/main...HEAD --stat at this head: 18 files, +85/-22 — matches the PR
  description's own numbers exactly, and matches every per-file count in the PR's "Changed Files"
  list.
• The extra lines visible in a raw git diff 1381be8 75d37d8 -- review-discipline.md (the
  D4.6's scope test phrase, a the three records → the records wording tweak) are not part of
  this PR's diff — they're already present in origin/main's current review-discipline.md via
  a48b6be, confirmed with git show origin/main:plugins/source-control/reference/review-discipline.md.
  They get folded in by the merge commit but sit outside origin/main...HEAD.

So there is no new review surface on this head. The one finding already posted against this PR
(at 764b742 and restated at 1381be8) still applies unaddressed at 75d37d8:

IMPORTANT — plugins/playbooks/skills/repo-sweep/reference/next.md lines 139–146 — reordering tick.sh (writes committed <sha> into the remote PR body) before git push removes the only guarantee that a step marked "done" actually reached the remote. tick.sh never checks <sha> is reachable from the branch, and state.sh (plugins/playbooks/skills/repo-sweep/scripts/state.sh lines 112 and 120) skips any line already ticked [x] with a committed <sha> tail without re-checking it against git log. A session dying between the tick call and the push — the exact crash scenario state.sh's own exit-14 flow anticipates (fresh fetch + worktree elsewhere) — leaves the remote PR body asserting a commit that never left the local worktree, and nothing in the tree reconciles that gap.

This falls under the data-integrity protected class. docs/conventions/instruction-exception-register/README.md is present in this checkout and confirms the class list (irreversible-action, secret-handling, data-integrity, external-publication, legal-compliance, agent-authority) is adopted by reference from Gate 0 in plugins/instruction-placement/context/routing-rubric.md. The old push-then-tick order made the body-says-done claim structurally dependent on the commit already being on the remote; this reorder trades that guarantee for avoiding a second CI run, with no replacement safeguard.

Already posted inline on this PR (by the automated Codex review and by this lane's prior passes at 764b742 and 1381be8) — not re-posted here as a duplicate. Suggested fix: keep push before tick; if the double-CI-run cost still needs solving, suppress/ignore the workflow run triggered by the bot's own edited event instead.

No other security findings. The remaining diff content (push-timing changes in monitor.md, review-discipline.md, pull-request/SKILL.md, babysit-prs/loop.md, implement/implement-dispatch, work-items/work/SKILL.md, ready-for-review.md, version bumps, changelog entries) is additive timing/sequencing guidance that doesn't remove or weaken an existing check, authorization gate, or guardrail. The D6 "verify commit pushed" gate becoming unsatisfiable mid-round, and the babysit-prs wave-batching text sitting above an untouched per-finding push step, are workflow-correctness gaps the code-review lane already flagged — not security issues.

No new inline comments posted — the diff content anchoring the existing thread hasn't moved, so a fresh inline comment would duplicate it rather than add signal.

[claude]

Claude finished @kyle-sexton's task in 3m 10s —— View job

---

Skip gate: does not apply. The synchronize since the last review added c6b5354 (a real content change, not a merge-forward), so this head has new review surface.

What changed since the last review round

c6b5354 fixes all five issues this lane (and Codex) previously flagged at 75d37d8:

• next.md restores push-then-tick, with the eval (evals.json) updated to match.
• review-discipline.md D6 and pull-request/SKILL.md D6 now explicitly defer D7/D7.5 until after the round's single push, resolving the "verify commit pushed" gate that was unsatisfiable mid-round.
• babysit-prs/loop.md §5.1.4 is restructured into a real batch: commit each fix with no push, one lane_push for the wave, then verify + D7 per finding.
• ready-for-review.md now shows the actual push command (push-branch.sh) instead of describing the step with no command.

Verified these by reading the full diff of c6b5354 and the current state of each file, not just trusting the commit message.

New finding (1)

plugins/source-control/reference/review-discipline.md lines 150–160 — the multi-finding ledger contract still chains D6 straight into D7 per row, reopening the gate this PR otherwise just fixed.

This passage (the "main-session contract" for the ≥3-findings subagent-ledger path) is untouched by this PR — confirmed with git diff origin/main...HEAD -- plugins/source-control/reference/review-discipline.md, which shows only the D6 bullet at lines 263–267 changed. It still reads:

For each ledger row, the main session runs D4.5 ... + D5 ... + D6 (fix if VALID (fix now)) + D7 (follow-up SHA) with verification gates between each step.

That's a strict per-row D6→D7 chain with a gate between them. But §3's D6 (the part this PR did fix, lines 263–267) now says the round pushes once after every finding's D6 commit, and "D7 and D7.5 for every finding in the round wait for that push." A worker following §2 literally — process ledger row 1's D4.5 through D7 with a gate before moving to row 2 — hits exactly the stall the earlier reviews flagged for D6→D7 elsewhere: row 1's D7 gate (commit pushed) can't pass until every other row's D6 commit has also landed and the round has pushed, but §2 never says to wait, only "gates between each step."

Since §2 governs decomposing any single comment with ≥3 findings, and that path is common (subagent ledger dispatch), this reintroduces the same correctness bug in a passage the fix commit didn't touch. Suggested fix: add the same "D7 and D7.5 wait for the round's push" clause to §2's contract, or have §2 point at §3's D6 bullet instead of restating its own D6/D7 sequencing.

Minor, not re-filed as a new finding

The PR body's "Patch bumps" versions (e.g. implementation 0.20.3) are stale again — current plugins/implementation/.claude-plugin/plugin.json reads 0.21.1. This lane flagged the same drift at an earlier head; it's cosmetic (description vs. actual bump) and doesn't block.

Verification

Read the full diff of c6b5354 against the prior reviewed head, and independently re-read the current content of next.md, review-discipline.md, pull-request/SKILL.md, babysit-prs/loop.md, monitor.md, and ready-for-review.md in the checkout (not just the diff) to confirm no other passage was left inconsistent with the new batched-push model. Did not independently re-run the PR description's cited verification commands (markdownlint, check-changed-skills.sh, affected-tests.sh); treat those as author-claimed.
· branch fix/lane-push-habits

[claude]

Claude finished @kyle-sexton's task in 1m 30s —— View job

---

Security review (/review:security-review)

• Gather context (PR body, diff, prior review comments)
• Check skip gate / whether prior review still applies to new HEAD
• Run /review:security-review against PR fix: write PR body edits before pushes and push once per review round #5899 (base origin/main, head 6b881dc6159c2945dae07ecd1c96f8c273ca0c1d)
• Post findings

Skip gate not hit — new review surface. The synchronize that produced this head includes a real content commit, not just a merge-forward: c6b5354 ("fix: push before tick and batch the per-finding verify gate"), on top of the already-reviewed 75d37d8. git diff origin/main...HEAD --stat (19 files, +110/-36) matches the PR description's own numbers exactly, so this is the full current diff.

The one finding this lane raised at every prior head is fixed.

plugins/playbooks/skills/repo-sweep/reference/next.md lines 139–150 now restores push-then-tick (commit c6b5354), reverting the earlier tick-before-push reorder this lane flagged under the data-integrity protected class at 764b742, 1381be8, and 75d37d8. The text now states the guarantee explicitly: tick.sh writes the remote PR body and state.sh never re-checks a committed line, so ticking before the push could leave the body naming a commit the branch lacks if the session died in between; a death after the push and before the tick is safe, since state.sh reports the pushed commit as untick-committed. This matches the original pre-PR ordering and closes the exploit path described in the earlier rounds of this review. The eval expectation (evals/evals.json) was updated to match (now asserts push before tick).

The other three locations this PR's code-review lane flagged as a gate-conflict (not security) issue are also resolved in the same commit, which removes any residual ambiguity that could be read as weakening a check:

• review-discipline.md D6 and the identical wording in pull-request/SKILL.md now explicitly say the single round push lands, and D7/D7.5 for every finding wait for it, before the per-finding "verify commit pushed" gate runs — no longer an unsatisfiable gate for findings other than the one coinciding with the push.
• babysit-prs/reference/loop.md §5.1.4 is now a true two-step wave: commit each VALID finding without pushing, one lane_push for the wave, then verify + D7 reply per finding after that push — no longer contradicted by an untouched per-finding push step.
• ready-for-review.md §2.5.4 now shows the actual command (push-branch.sh, resolving the push remote) rather than naming the action without a command.

No new security findings. The rest of the diff (implement/implement-dispatch body-refresh timing, work-items/work/SKILL.md batched fix-worker dispatch, monitor.md §3.3.2 step 0, version bumps, changelog entries) is additive sequencing guidance over when a PR-body/label edit or a push happens — it doesn't remove or weaken an existing check, authorization gate, or guardrail, and none of it touches secrets, credentials, injection surfaces, or authorization logic. The docs/conventions/instruction-exception-register/README.md protected-class list was consulted directly from this checkout (present, confirms data-integrity as one of Gate 0's classes).

[claude]

Claude finished @kyle-sexton's task in 1m 37s —— View job

---

Code review (/review:code-review)

• Gather context (PR diff, changed files, CLAUDE.md/AGENTS.md rules)
• Check skip gate against prior review on this lane
• Confirm no new review surface at this head
• Post findings (none new — see below)

Skip gate hit (criterion 4): this head's PR diff is unchanged from the already-reviewed commit.

The synchronize that produced head 4cf65d5 is another merge-forward only: 4cf65d5 = 6b881dc
merged with origin/main (which had since picked up 79fe3dc, an unrelated prerequisites.json
refactor). Verified directly rather than trusting the merge commit message:

• git diff origin/main...HEAD --stat at this head: 19 files, +110/-36 — matches the PR
  description's own numbers and the already-reviewed diff at 6b881dc exactly.
• git diff 6b881dc 4cf65d5 -- <every file this PR touches> returns no output — every one of
  the 11 content files (next.md, review-discipline.md, babysit-prs/SKILL.md,
  babysit-prs/reference/loop.md, pull-request/SKILL.md, pull-request/reference/monitor.md,
  pull-request/reference/ready-for-review.md, work/SKILL.md, implement/SKILL.md,
  implement-dispatch/SKILL.md, repo-sweep/evals/evals.json) is byte-identical to what this lane
  already reviewed at 6b881dc.

So there is no new review surface on this head. The one finding this lane opened against 6b881dc
and hasn't seen addressed yet still applies, unchanged, at
plugins/source-control/reference/review-discipline.md lines 150–160:

The ≥3-findings subagent-ledger contract (§2) still chains D6 straight into D7 per row, which is the same gate conflict this PR's own c6b5354 fixed in §3.

This passage is outside this PR's diff — git diff origin/main...HEAD -- plugins/source-control/reference/review-discipline.md only touches the D6 bullet at lines 263–267. §2 still reads:

For each ledger row, the main session runs D4.5 ... + D5 ... + D6 (fix if VALID (fix now)) + D7 (follow-up SHA) with verification gates between each step.

That's a strict per-row D6→D7 chain with a gate between them, while §3's own D6 (lines 263–264, fixed by this PR) now defers the push to once per round and makes D7/D7.5 for every finding wait for it. A worker following §2 literally for a ≥3-finding comment — D4.5 through D7 per row, gated — hits the same stall this lane flagged and this PR already fixed elsewhere in the file: row 1's D7 (commit pushed) can't pass until every other row's D6 has landed and the round has pushed, but §2 never says to wait.

No inline comment is posted for this: the anchoring lines (150–160) aren't part of this PR's diff hunks, so GitHub's inline-comment API can't attach a comment there — flagging it here in the summary per this lane's cross-file/no-changed-line convention.

No other findings. Nothing else in the diff changed since the last full review pass (commit c6b5354, which fixed the push/tick ordering and the D6/D7 batching this lane and Codex had flagged at earlier heads).
· branch fix/lane-push-habits

[claude]

Claude finished @kyle-sexton's task in 1m 5s —— View job

---

Security review (/review:security-review)

• Gather context (PR body, diff, prior review comments)
• Check skip gate / whether prior review still applies to new HEAD
• Run /review:security-review against PR fix: write PR body edits before pushes and push once per review round #5899 (base origin/main, head 4cf65d5fb57a49a742420cc65961475b6330c9af)
• Post findings

Skip gate hit: criterion 3 ("this head already has a successful security review that still applies").

This synchronize event is a merge-forward only. git log 6b881dc..4cf65d5 shows one new commit, 79fe3dc (refactor(prerequisites): convert the existing prerequisites.json files and move the fleet reader to the node checker, #5980), which lands via the merge commit 4cf65d5. Confirming this PR's actual diff is unchanged:

• git diff origin/main...HEAD --stat at this head: 19 files, +110/-36 — matches the PR description's own numbers and the "Changed Files" list exactly.
• git diff 6b881dc 4cf65d5 -- plugins/implementation/skills plugins/playbooks/skills/repo-sweep/reference plugins/playbooks/skills/repo-sweep/evals plugins/source-control/reference plugins/source-control/skills plugins/work-items/skills returns nothing — every line of this PR's own skill/reference content is byte-identical to what was already reviewed at 6b881dc.
• The visible git diff 6b881dc 4cf65d5 churn (new lib/prerequisites.mjs/.sh/.ps1 files, plugin.json/CHANGELOG.md version bumps to 0.77.2/0.77.3 etc.) is 79fe3dc's own content, already present on origin/main — confirmed plugins/source-control/lib/prerequisites.mjs exists byte-identical on origin/main, i.e. outside origin/main...HEAD and not part of this PR's changeset.

So there is no new review surface on this head. The one finding this lane raised at every earlier head (764b742, 1381be8, 75d37d8) was fixed in c6b5354 and confirmed fixed at 6b881dc: plugins/playbooks/skills/repo-sweep/reference/next.md lines 139–150 restores push-then-tick, closing the data-integrity gap (a session dying between tick.sh's remote PR-body write and git push could previously leave the body claiming a step was committed <sha> when that commit never reached the remote; neither tick.sh nor state.sh reconciled a ticked line against remote reachability). That fix is still present, unchanged, at this head.

No other security findings. The rest of the diff (push/tick and wait-for-reviewers timing in implement/implement-dispatch, work-items/work/SKILL.md, monitor.md, review-discipline.md, pull-request/SKILL.md, babysit-prs/loop.md, ready-for-review.md, version bumps, changelog entries) is additive sequencing guidance that doesn't remove or weaken an existing check, authorization gate, or guardrail — it was already reviewed clean at prior heads and is unchanged here.
· branch fix/lane-push-habits