[factory] The automatic babysitter only covers Factory-created PRs, so it shepherds almost nothing

[khaliqgant]

Repo: factory · recipe: agent:team

The gap

babysitter.enabled: true has been set all day and has shepherded nothing, because the automatic babysitter only covers PRs Factory itself created.

From this repo's own verification procedure (.agentworkforce/features/verify/procedures.md:352):

"Enable babysitter.enabled, open a non-draft PR through the issue-driven path, and confirm only one babysitter starts."

Everything else requires the manual, explicitly opt-in command — README:300:

"factory babysit 10 … The explicit command is opt-in on its own and does not require babysitter.enabled."

Why that makes the feature nearly inert here

The org has 302 open PRs, 248 ready for review, across 41 repositories (GitHub API, 2026-08-07). Recent authorship is dominated by humans and non-Factory bots — khaliqgant 30, barryollama 4, kjgbot 3, miyaontherelay 3 in the recent window. Almost none were created by Factory, so almost none are in the automatic babysitter's scope.

The result is that a human runs factory babysit <url> by hand, one PR at a time — which is precisely the labour the babysitter exists to remove. Twelve of those PRs are over sixty days old.

What is being asked for

Shepherd any open PR in a routed repository, regardless of who opened it — not only PRs Factory created from an issue it dispatched.

That is a scope change with real consequences, so design it deliberately rather than widening a predicate:

1. Discovery. What set of PRs is in scope? Bounded by repos.names, presumably — but state the rule, and state what happens to a PR in a repo that is routed but whose issue never went through Factory. There is no linked issue spec for most of these; the standalone path already handles that by falling back to the PR title and body, and the automatic path will need the same.
2. Ownership and dedup. The existing model keys a babysitter to exact repo/PR ownership so only one wakes. Widening the intake must not weaken that. A claim belongs to the work unit; two babysitters on one PR is the AR-448 duplicate in a new costume.
3. Opt-out, and it must be honoured. A blanket babysitter touching every open PR in 41 repos affects other people's work. There must be a way to say no — a label, a config exclusion — and it must be checked before the first write, not after.
4. Rate and volume. 248 PRs is not 5. Say what the concurrency and pacing are, and log anything you drop. A truncated sweep that reads as full coverage is worse than an honest partial one.
5. No silent escalation to humans. Whatever notification behaviour exists must stay off, or behind an explicit flag, until a human has seen what it would have said on a real sweep.

Related, and probably a prerequisite

The babysitter currently writes to GitHub by shelling out to gh, so it acts as the local user rather than the app. That is filed separately. Widening the babysitter to hundreds of PRs before fixing the identity would attribute a large volume of automated activity to a person's account. Sequence accordingly.

Constraints

• Do not merge anything. The merge gate belongs to the principal, and mergePolicy is never.
• Do not enable notifications as part of this.
• Report validation by exit code, not by output.
• Any figure in the PR cites a measurement; no round numbers.