docs(plan): correct pre-step (0) — two callers, two pins, not one

[kyle-sexton]

Summary

Pre-step (0) (merged in #301) states that re-pinning the standards sync engine
to 8202e03f also activates the never-armed watchdog, "so ONE pin satisfies
both." The commit does carry both halves; standards does not consume it that
way, so the guidance is wrong for the operator who follows it.

Verified against the live repos:

Claim	Reality
One pin activates arming + watchdog	Two separate callers, two separate pins
Watchdog rides sync.yml's pin	Watchdog is standards-sync-stuck-automerge-alert.yml, a different reusable

standards/.github/workflows/sync.yml:33
  → standards-sync.yml@8202e03f…                      (standards#293, in flight)
standards/.github/workflows/standards-sync-stuck-automerge-alert.yml:19
  → standards-sync-stuck-automerge-alert.yml@43bc8d0f  # 43bc8d0 2026-07-22

Re-pinning sync.yml therefore activates the arming half only.

43bc8d0 predates two commits, not one — git log --oneline 43bc8d0..8202e03f -- .github/workflows/standards-sync-stuck-automerge-alert.yml:

• 8202e03 fix(standards-sync-stuck-automerge-alert): detect sync PRs that were never armed #291 — never-armed detection
• 42329ef fix(standards-sync-stuck-automerge-alert): split the stuck-PR scan into a cheap page fetch and a per-candidate merge-state probe with retry #234 — split the stuck-PR scan into a cheap page fetch + per-candidate merge-state probe with retry

The deadline the old text implied was already met. The never-armed scan
selects targets with jq '[.include[] | select(.automerge) | .repo_name]' and
gates candidates on automergeRepoNames.has(repo), so it is inert while the
rollout window holds all 8 targets at automerge: false — and becomes
load-bearing at the exact moment automerge: true is restored. The watchdog
re-pin must land before that restore.

One nuance the correction records, because it cuts against reading the
stale pin as wholly dormant: the armed-but-stuck scan is not
automerge-gated. It loops repoNames (all 8 targets) at :299 and pushes
isArmedCandidate matches at :315 with no automerge check — only :316's
never-armed branch is gated. It sweeps every target on the hourly cron today,
and is quiet only because no sync PR is currently armed (checked: dotfiles#361,
provisioning#231, github-iac#244, medley#1676 all report autoMergeRequest: null).

No phase tag advances. Scope is the pre-step (0) paragraph only.

Test plan

• markdownlint-cli2 docs/topics/claude-review-lanes/PLAN.md → Summary: 0 error(s)
• git diff -U0 | grep -E "^[+-].*\[(DONE|DOING|TODO)\]" → no matches (no phase tag touched)
• Every factual claim above regenerated from a command against the live repos,
  on a full clone — the local clone was shallow, which can make
  git diff <sha>^ <sha> error in a way that reads as a false positive;
  git fetch --unshallow was run and every finding re-derived. All held.
• Independently re-verified by a fresh-context verifier (verdict in the PR thread).

Related

No linked issue. Corrects text merged in #301; describes work delivered by #291
and #234. The paired standards-side watchdog re-pin ships as its own PR.

[claude]

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

---

Reviewing PR #303

• Gather context (diff, PLAN.md, referenced workflow file)
• Understand the request (code review of a docs-only correction)
• Review the diff for correctness and alignment with CLAUDE.md
• Post findings

Summary

Docs-only change to docs/topics/claude-review-lanes/PLAN.md, correcting pre-step (0) of the Phase 3d rollout plan. No workflow files are touched, so none of the CLAUDE.md security ground rules for the Claude-lane reusable workflows are implicated, and this PR doesn't touch the pin-by-SHA rules either (it's prose about pins, not a pin itself).

Verification performed

• Confirmed no [DONE]/[DOING]/[TODO] phase tags were touched — the edit is scoped entirely to prose inside the existing [DOING] phase 3d bullet (PLAN.md#L667-L688).
• Cross-checked the new components/runner-policy/policy.json reference (PLAN.md#L677) against this repo — it's a real, established component name, not a fabricated detail: it's already referenced in standards-sync-stuck-automerge-alert.yml:81-82 and README.md:71,402.
• Verified the never-armed vs. armed-but-stuck gating claim (automerge-gated vs. not) directly against this repo's own reusable workflow: automergeRepoNames is built from select(.automerge) and consulted only at the never-armed branch (standards-sync-stuck-automerge-alert.yml:316), while the armed-but-stuck branch at line 315 has no such gate and loops all repoNames at line 299 — this matches the PR body's claim exactly.
• The corrected text's claims about the standards repo (two separate callers/pins, the 43bc8d0/8202e03f SHAs) are outside this repo and can't be re-verified from here, but the PR body documents the exact gh/git log commands used and states independent re-verification after an unshallow fetch — reasonable diligence for a docs correction of this kind.
• Style/tone (heavy ALL-CAPS emphasis, inline SHA/command references) is consistent with the surrounding, pre-existing PLAN.md prose — not a new convention introduced by this PR.

Findings

None. This is an accurate, narrowly-scoped, well-substantiated correction to planning documentation. No code, workflow, or security-relevant files are affected.

[github-actions]

Claude has reviewed this PR 1 time. The lane skips further automatic reviews after 5; deleting this comment resets the count.