source-control: migrate ten babysit repository-tooling keys from userConfig to the source-control.md cascade

[kyle-sexton]

Summary

Migrate ten source-control babysit userConfig keys that describe a repository's tooling to the
layered .claude/source-control.md surface, with per-key trust binding and a deprecation window.
The ruling that splits the 17 babysit identity and topology keys into declare, migrate-now and
migrate-later sets is recorded in the ADR added by the linked pull request. This issue tracks only
the migrate-later set, which needs new resolution machinery.

Keys

babysit_merge_method, babysit_merge_block_labels, babysit_extra_dependency_manager_logins,
babysit_approval_downgrade_logins, babysit_skip_downgrade_logins,
babysit_review_trigger_phrase, babysit_review_bot_logins, babysit_review_settle_minutes,
babysit_review_gate_context, babysit_ci_gateway_context.

Out of scope, by the ruling: babysit_watched_owners, babysit_self_logins,
babysit_intended_write_identity, babysit_lane_logins, babysit_approver_bot_logins,
babysit_extra_bot_logins stay userConfig (a repo-writable value would widen authority).
branch_issue_pattern migrates in the linked pull request.

Design to settle

1. Per-target-repo resolution. /source-control:babysit-prs is a fleet loop and substitutes
   ${user_config.*} once at skill load. Reading the launching checkout's file would apply one
   repo's values to every other repo's PRs. Resolve per target repository, per PR, per cycle, from
   that repository's tracked .claude/source-control.md on its default branch (gh api contents),
   never a working tree, following the babysit_loop_trusted_internal_bot_logins precedent in
   plugins/source-control/reference/config-resolution.md.
2. Merge mode per key.
   • Hold and veto lists (babysit_merge_block_labels, babysit_extra_dependency_manager_logins,
     babysit_approval_downgrade_logins): add-only union across layers and the deprecated
     userConfig value, so no later layer can drop an entry. The surface has no union mode today
     (closed lists are taken whole), so this is a new, declared policy-floor merge mode.
   • babysit_review_bot_logins with babysit_review_settle_minutes: bound as one unit from one
     layer, so a per-key merge cannot take one half from each layer and leave the settle hold
     silently dormant. A lower layer may lengthen the settle window, never shorten it.
   • babysit_skip_downgrade_logins: decide whether it is a floor or a preference before choosing.
   • babysit_merge_method, babysit_review_trigger_phrase, babysit_review_gate_context,
     babysit_ci_gateway_context: plain per-key override.
3. Deprecation window. The userConfig value stays a fallback (a union member for the hold
   lists) and emits one deprecation note when it is used. Remove it in a later minor release with a
   CHANGELOG Removed entry, no earlier than 90 days after the resolver ships.
4. Tests. Resolver cases for each merge mode, the default-branch-only read, precedence against
   the deprecated fallback, and a fleet run over two repositories with different values.

Security

Any design that lets a repo-writable layer shorten a hold, drop a veto label, or replace a hold list
under plain per-key override loosens a merge-safety check. That needs the maintainer's explicit
decision before implementation. A security review is mandatory on the implementing pull request.

[kyle-sexton]

Reopened. This comes from the 2026-09-29 audit of the Cursor run. Draft PR: #5317 (Refs #4572).

What happened. #4913 was docs-only: no resolver, no migration, no tests. The ten keys still resolve from userConfig, and plugins/source-control/reference/config-resolution.md titles the section "Deferred". ADR 0039 decision 3 says the ten keys move "under #4572" with a mandatory security review, so this issue must stay open. ADR 0039 came from #4581, which was authored under the maintainer's account (kyle-sexton) but merged by app/cursor, so the merge-mode table below was never ratified by a human merge.

Q1. Is babysit_skip_downgrade_logins a floor or a preference?

• Options: floor (a repo layer can only narrow the effective value) or preference (plain per-key override).
• What the code does: a login in this set has its not-approving review text downgraded from blocking to material when the review provably could not run (babysit_feedback.py:237, babysit_classify.py:346-360). Adding a login therefore shortens a hold. That is the opposite direction from the hold lists (babysit_merge_block_labels, babysit_approval_downgrade_logins), where adding makes the gate stricter. A repo-writable layer that can add logins can weaken the gate; one that can only remove them cannot.
• RECOMMENDED: floor in that inverted sense (a repo layer may remove logins, never add), or leave the key in userConfig. Basis: the two cited locations. Whether a repository may control this key at all is a security decision the code does not settle. Evidence that would settle it: your stated preference on whether a repository may relax reviewer-skip handling.

Q2. Do you ratify the merge-mode table in ADR 0039 decision 3? Add-only union for hold lists; babysit_review_bot_logins and babysit_review_settle_minutes bound as one pair, where the settle window may lengthen but never shorten; default-branch-only reads for gate contexts. The config-resolution.md security note says a repo-writable layer shortening a hold needs your explicit decision. Options: ratify as written; amend (name the change); reject. RECOMMENDED: ratify as written, since every entry only lengthens or preserves a hold (basis: ADR 0039 lines 56-59, config-resolution.md checklist item 4).

Q3. Authorize implementing the per-target-repo resolver (checklist in config-resolution.md, "Required resolver behavior": per-PR default-branch cascade read, 90-day fallback window, tests, mandatory security review on the implementing PR)? Options: authorize now; authorize after Q1 and Q2 are answered; defer. RECOMMENDED: authorize after Q1 and Q2, because the resolver's merge modes depend on them (basis: judgment from the dependency, plus the checklist).

Unblocks. The resolver implementation PR and the start of the userConfig deprecation window.

Labels needs-human and status: needs-decision added.

[kyle-sexton]

Owner decision (2026-09-29): Q2: the ADR 0039 decision 3 merge-mode table is ratified as written. Q1 (babysit_skip_downgrade_logins, floor or preference): decide with evidence; the recommendation's leaning is floor in the inverted sense (a repo layer may remove logins, never add) or leave the key in userConfig. Q3: the per-target-repo resolver is authorized after Q1 and Q2 are settled.

Next: an agent posts the Q1 evidence on this issue (current use of the key at babysit_feedback.py:237 and babysit_classify.py:346-360, and what each option would change) and stops. Q1 is a security choice, so the final ruling stays with the owner and needs-human stays. Resolver implementation waits on Q1; it needs a mandatory security review.