babysit-prs: decouple self-identity from --author so configured self-login extras survive autopilot widening

[kyle-sexton]

Problem

pr_queue_snapshot.py derives ClassifyConfig.self_logins from the discovery --author filter. PR #494 (commit 116337a) closed the reported autopilot vector by resolving the authenticated @me login independently (resolve_self_logins()) and unioning it into a dedicated resolved_self_logins carrier — but it only guarantees the authenticated identity.

Configured extra self identities (babysit_self_logins) still ride on --author per SKILL.md:367-368 (--author @me,<self-logins>). Autopilot / explicit widening deliberately drops --author entirely (SKILL.md:371), so any extra (non-@me) posting identity is absent from self_logins in widened runs. If a deployment posts babysit classification/follow-up comments under a bot-identity wrapper whose login differs from the authenticated @me, those comments still re-fire new_human_blocking_feedback every widened cycle — the same self-dispatch symptom as #473, for the extras case.

Root asymmetry

self_logins (whose comments to suppress = the posting identities) is a distinct concern from --author (which authors' PRs to discover). The snapshot conflates them. The readiness gate already models this correctly with dedicated --self / --extra-self flags; the snapshot lacking the equivalent is the asymmetry.

Suggested fix direction

Add a dedicated self-identity input to pr_queue_snapshot.py (e.g. --self / --extra-self, mirroring the readiness gate), always resolved and applied to self_logins regardless of the discovery --author value and regardless of --pr vs --queue mode. Update the SKILL.md step-4 invocation contract so the orchestrator passes the configured self logins via the new flag instead of overloading --author, and drops the --author @me,<self-logins> extension guidance.

This is the same root seam as #497 (single---pr mode leaves self_logins empty): both are "self_logins must be resolved from the posting identity, not the discovery filter." A single dedicated self-identity resolution — applied before the one build_config call, independent of discovery — would resolve #497 and this issue together, and would supersede the @me-only union added in #494.

Related

• source-control:babysit-prs: needs_worker's new_human_blocking_feedback fires on the worker's own self-authored replies (same-login false positive) #473 (engine-level self-filter, delta arms)
• babysit-prs: single---pr snapshot mode leaves self_logins empty (self-filter + foreign-activity dormant) #497 (single---pr mode leaves self_logins empty — sibling facet; note its assumption that fix(source-control): exclude self-login from babysit new_human_blocking_feedback #494 fully fixed the --queue path holds only for the @me identity, not configured extras in autopilot)
• PR fix(source-control): exclude self-login from babysit new_human_blocking_feedback #494 / commit 116337a (fixed the --queue autopilot @me vector; deliberately deferred the extras/--self-flag decoupling)

[kyle-sexton]

Additional facet surfaced during PR #494 review (Codex P2, pr_queue_snapshot.py:138) — the over-inclusion direction of this same root asymmetry, complementing the under-inclusion symptom in the description:

resolve_self_logins(authors) unions the discovery authors with @me. So a supported --queue --author alice run (authenticated as a different login) makes alice a self-login, and the new-feedback dispatch filter then drops Alice-authored human feedback from both delta arms. Human-stop safety is unaffected (feedback["human_blocking"] still sets human_stop["required"] and halts the merge gate) — only the dispatch arm is suppressed, which is strictly less wrong than the pre-#494 infinite re-dispatch — but a non-self author's blocking comment gets no prompt worker dispatch.

The dedicated --self / --extra-self seam this issue proposes (resolve posting identities independently of the --author discovery filter) closes both directions at once: under-inclusion (configured extras dropped in widening) and this over-inclusion (discovery authors wrongly treated as self). Recording it here so the deferral is complete and the facet isn't lost.

[kyle-sexton]

This was generated by AI during triage (historic normalization, rule 8g).

This issue's own analysis already converges on a single fix: self_logins must be resolved from the posting identity, independent of the --author discovery filter, mirroring the readiness gate's existing --self/--extra-self pattern. The issue explicitly names #497 as the same root seam ("single dedicated self-identity resolution... would resolve #497 and this issue together").

Decision defaulted: add a single dedicated self-identity resolution input to pr_queue_snapshot.py (mirroring the readiness gate's --self/--extra-self flags), resolved once before the one build_config call, independent of --author — superseding the @me-only union added in #494 — veto before merge (additive/reversible: existing --author @me,<self-logins> callers keep working during migration; the alternative would be patching --author handling per-mode instead, which is what produced this exact asymmetry in the first place).

#497 (single---pr mode leaves self_logins empty) is the sibling facet of the same seam — cluster-routed as blocked-by this issue rather than triaged separately.

[kyle-sexton]

Claimed by tower overnight worker, 2026-07-21 ~16:xxZ. Implementing the ratified default: a dedicated --self/--extra-self self-identity input to pr_queue_snapshot.py (mirroring babysit-readiness-gate.sh), resolved independently of the --author discovery filter — superseding the @me-only union from #494 and removing the author-derived self path in both directions; plus the SKILL.md step-4 + userConfig-table contract update and a red-green regression test. PR to follow (Closes #511).