Weekly insights: name babysit-prs' stuck-conflict gap, refresh PR hygiene

AGENTS.md

@@ -144,6 +144,9 @@ Deals → CRM (via MCP). Tasks → task tool. Priorities → `ops/priorities.md`
 ### To-do list has one canonical render spec
 Every entry point (session start, each ritual, each cloud routine) uses the spec in `.claude/rules/todo-single-source.md`. Don't re-derive the grouping or filtering inside a command.
 
+### Keep this map in sync
+This file's repository map, commands table, and hooks table have drifted from the actual repo three separate times in about two months (#38, #58, #60 each caught a different gap — a missing command, a wrong file path, a description carried over from a different repo). Any PR that adds, removes, renames, or moves a command, hook, skill, or top-level file updates the matching table here in the same diff — don't leave it for the next audit to notice.
+
 ## Available Commands
 
 | Command | Cadence | Role |
@@ -177,6 +180,8 @@ Three layers — run the rituals without your machine awake:
 2. **Cloud Routines** — Anthropic-hosted Claude Code sessions triggered on a schedule. Runbook in `.claude/scheduling/cloud-routines.md`.
 3. **GitHub Actions CI backstop** — deterministic checks only (`.claude/scripts/checks/growth-os-checks.sh`).
 
+**Known gap: `babysit-prs`.** A recurring PR-health check (CI status, review threads, merge conflicts, external launch dependencies) has been posting dated status comments on this repo's own open PRs since 2026-06-13 — visible directly in the PR history — but it has no `.claude/commands/babysit-prs.md`, isn't listed in `.claude/scheduling/cloud-routines.md`'s routine table, and isn't in the *Available Commands* table below. A prior attempt to formalize it (#53) was closed as superseded before the command file itself landed. Treat this as an open item, not a shipped feature — if you're adapting this kit and want the same check, write your own `.claude/commands/babysit-prs.md` rather than assuming one exists.
+
 ## Source-of-Truth Hierarchy
 
 1. **`.claude/rules/crm-usage.md`** — canonical for CRM access protocol and write guardrails

CHANGELOG.md

@@ -9,6 +9,27 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Changed
 
+- **`CLAUDE.md`** — refreshed the *Open-PR hygiene* note again (5 open PRs as of
+  2026-08-23; #53 closed as superseded, #58/#60 merged) and reframed it around a
+  **blocked-on-external vs. needs-review split** instead of a single PR-number
+  narrative, since the prior version's mention of #53 was already stale one week
+  after being written. Added a new subsection, *PR-health checks should resolve
+  mechanical conflicts, not just re-report them*: `babysit-prs` had been holding
+  purely additive `CHANGELOG.md` `## [Unreleased]` conflicts (two branches, two
+  non-contradicting entries) to the same "editorial call, out of scope" standard as
+  genuinely contradicting conflicts — PR #44's conflict was reported unchanged
+  across at least seven consecutive check-ins (07-27 → 08-22) as a result, and #55
+  hit the same failure mode. States the fix: merge both entries when neither side
+  altered the other's lines.
+- **`AGENTS.md`** — documented `babysit-prs` as a known gap in the *Scheduling*
+  section: it has been posting dated PR-health comments since 2026-06-13 (visible
+  in this repo's own PR history) but has no `.claude/commands/babysit-prs.md` and
+  isn't listed in `.claude/scheduling/cloud-routines.md` or the commands table — a
+  prior attempt to formalize it (#53) was closed as superseded before the command
+  file landed. Also added a *Keep this map in sync* convention under *Key
+  Conventions*, naming that this file's tables have drifted from the actual repo
+  three times in two months (#38, #58, #60) with no check tying a new
+  command/hook/skill/file to a required update here.
 - **`CLAUDE.md`** — refreshed the *Open-PR hygiene* note (7 open PRs as of 2026-07-05,
   #38 since merged, but the count has drifted back up to 6 as of 2026-08-09) and named
   the pattern plainly: `insights-loop`'s own prior deliverable (#53, opened

CLAUDE.md

@@ -37,9 +37,15 @@ Run the rituals on a clock — locally (cron/launchd), in the cloud, or as a CI
 
 ## Open-PR hygiene
 
-This repo has accumulated open, unmerged PRs from prior sessions (7 open as of 2026-07-05; #38 has since merged, but the count has since drifted back up to 6 as of 2026-08-09, several dating to early July). Before opening a new PR: check `repo:etrebels/claude-code-growth-os is:pr is:open` for existing work on the same topic and continue or merge it rather than adding a near-duplicate. If a recurring skill's own prior PR is still open, that's a signal worth surfacing in its output, not a fresh PR to pile on top.
+This repo has accumulated open, unmerged PRs from prior sessions. As of 2026-08-23: **5 open** (#44, #48, #49, #55, #57) — down from 6 as of 2026-08-09, since #53 was closed as superseded by #58 (merged 2026-08-22) and #60 merged directly. Before opening a new PR: check `repo:etrebels/claude-code-growth-os is:pr is:open` for existing work on the same topic and continue or merge it rather than adding a near-duplicate. If a recurring skill's own prior PR is still open, that's a signal worth surfacing in its output, not a fresh PR to pile on top.
 
-**The rule keeps getting proven on `insights-loop` itself.** #38 sat unmerged for four weeks before merging; its successor, #53 (opened 2026-07-19, "codify `/babysit-prs`, fix hygiene drift" — itself a fix for this exact problem), sat as a draft for three weeks and has since drifted into a real merge conflict with `main` (`mergeable_state: dirty`) as unrelated content landed on top of it. A routine that opens a fresh dated branch every week without checking back on last week's branch is *how* PRs pile up, not just a bystander reporting it — the fix is to extend or close out the prior branch before starting a new one, not just to log the number.
+**Not all open PRs carry the same urgency — split them before reporting the count.** Three of the five (#44, #48, #49) are *intentionally* held open, each blocked on a human-only event in a different repo (a "flip this live" step, a sibling kit going public) that no amount of re-checking resolves any faster. The other two (#55, #57) are the ones actually waiting on review or a rebase. A raw "N open PRs" number treats both groups the same and understates how much is genuinely stuck — when reporting the count, name the split: `<blocked-on-external> blocked on an external/manual event, <needs-review> ready for review`.
+
+**The rule keeps getting proven on `insights-loop` itself, and this note needed refreshing again this run.** #53 (last week's fix for this exact hygiene problem) is now closed — but the sentence that described it as "still a draft, drifting into conflict" was already stale one week later, because it named a specific PR's live state rather than a pattern. That's why this version leans on the blocked-vs-needs-review split above instead of a single PR number: a split-by-status framing keeps describing reality after the PR it was written about has closed.
+
+### PR-health checks should resolve mechanical conflicts, not just re-report them
+
+`babysit-prs` — the recurring PR-health check referenced above and documented (as a known gap) in `AGENTS.md`'s *Scheduling* section — correctly treats a **content-contradicting** merge conflict as an editorial call outside its authority to resolve on its own. But it has been applying that same hold to conflicts that are purely **additive and non-contradicting** — two branches each adding their own entry under `CHANGELOG.md`'s single `## [Unreleased]` heading, where the fix is simply "keep both entries." The cost is concrete: PR #44's `CHANGELOG.md` conflict was reported unchanged, almost verbatim, across at least seven consecutive check-ins (07-27 through 08-22) with zero resolution, and #55 hit the identical failure mode. **The fix:** before flagging a `CHANGELOG.md`-only conflict as "outside authorization," diff the two sides — if neither deleted or altered the other's lines (a pure two-way addition to the same section), merge `main` in, keep both entries, and say so in the status comment. Reserve the hold-and-flag behavior for conflicts where the two sides actually disagree about the same content.
 
 ## Session-analysis routines (e.g. `insights-loop`)