source-control:babysit-prs: needs_worker's new_human_blocking_feedback fires on the worker's own self-authored replies (same-login false positive)

[kyle-sexton]

Lane

babysit (safe tier, /loop 15m /source-control:babysit-prs)

Triggering example

#377, cycle 3 of this session: dispatched solely because needs_worker_reasons: new_human_blocking_feedback (3 new human-authored items), with head_sha_changed false and zero new bot findings. The worker fetched all comments and found: every non-bot comment since the last snapshot was posted by kyle-sexton — which is BOTH the PR author's login AND the babysit session's own gh auth identity (gh api user --jq .login → kyle-sexton). All of them were the prior round's own classification-table replies and "Fixed in <sha>" follow-ups (the exact review-discipline §1 self-reply pattern), not genuine reviewer feedback. The worker did zero work, correctly, after re-deriving this from scratch.

Observed vs expected

• Observed: pr_queue_snapshot.py's new_human_blocking_feedback arm (per reference/orchestration.md) counts any new comment from a non-bot login as human feedback, with no exclusion for the same login the babysit engine itself posts under. Because the safe-tier worker's own classification replies and fix-SHA follow-ups are posted under the PR author's own GitHub identity (the common case for a solo maintainer babysitting their own PRs), every worker round that posts a reply automatically manufactures a new_human_blocking_feedback delta for the next round — a self-inflicted, unsuppressible dispatch reason (per orchestration.md, new_human_blocking_feedback is explicitly unsuppressible) that will re-fire forever on any PR the worker has ever replied to, even with zero real reviewer activity.
• Expected: the engine's human-feedback delta computation should apply the same self-reply exclusion that review-discipline.md §1 already mandates for the worker's own classification (filter comments authored by the configured self-login(s) / babysit_self_logins from counting as new human-authored feedback), so a worker's own prior-round replies never manufacture next-round dispatch. This is a deterministic, engine-level fix (comparable to the bot self-filtering already done for new_blocking_feedback), not something each dispatched worker should have to re-derive by reading every comment's author every cycle.

Category

bug

Impact

Confirmed to recur: this is the second consecutive cycle where PR #377 was dispatched a worker purely because of its own prior-round replies, with zero real work available both times. On a solo-maintainer babysit loop (the common default_tier: safe case, author == babysit identity), this silently inflates worker-dispatch counts every cycle a PR has ever received a reply — burning a full Opus worker round each time to re-derive "these are my own replies, nothing to do."

[kyle-sexton]

This was generated by AI during triage.

Triage → T2 planning complete · confidence: high. Bug confirmed real; fix bounded + deterministic. One premise correction (does not lower confidence): the issue's claimed "bot self-filter already done for new_blocking_feedback" does not exist — collect_feedback has zero self-login exclusion on either arm, so the bot arm carries the same latent gap. Real precedents to mirror: babysit_delta.py::detect_foreign_activity (already filters by config.self_logins) and reference/review-discipline.md §1 (which the engine does not implement today). Labeling status: ready.

Engine must not count its own prior-round replies as new human feedback

Root cause (verified)

skills/babysit-prs/scripts/babysit_feedback.py::collect_feedback classifies every comment/review/inline comment with no exclusion for the login(s) the engine itself posts under. babysit_delta.py then derives:

new_human_blocking_feedback = [
    item for item in feedback["human_blocking"]
    if item["id"] not in prev_human_blocking_ids
]

new_human_blocking_feedback is unsuppressible — feeds unsuppressible_delta + needs_worker_reasons directly. On a solo maintainer (PR author == babysit gh auth identity), the worker posts classification tables + "Fixed in <sha>" replies under that same identity; actor_kind → human; a table quoting severity tokens (P1, regression, blocking) matches has_blocking_text → lands in human_blocking → new id → fires. Fresh replies each round → self-perpetuating on any PR the worker ever replied to (confirmed: PR #377 dispatched two consecutive cycles).

Two manifestations, one root cause: the same self-authored human_blocking items also set human_stop["required"] = True + append the human-triage blocker in classify_pr, pinning the PR to active indefinitely. A delta-only patch would silence re-dispatch but leave the PR permanently self-blocked — so the fix belongs at collect_feedback, not the delta arm.

Behavioral contract

• The worker's own prior-round replies (any configured self-login) never manufacture next-round dispatch and never mark the PR human-blocked.
• Genuine human feedback from other logins counts exactly as today.
• Brings the engine into line with review-discipline.md §1 ("Only comments from OTHER authors are potential finding sources"); mirrors detect_foreign_activity's existing self-login handling.

The fix

Part A — exclude self-authored items in collect_feedback (root cause). At the top of the per-item loop, skip any item whose author_login(item) casefolds into the resolved self-login set, before routing into blocking/material/human_blocking/human. Safe: GitHub disallows self-reviews, so no legitimate self CHANGES_REQUESTED is suppressed. Covering both actor kinds also closes the identical bot-arm gap (the #450 posting-identity case). Thread the self-login set into collect_feedback (add self_logins to FeedbackConfig, or pass from classify_pr, which already holds config.self_logins).

Part B — decouple the self-login set from the discovery --author scope (load-bearing). Today config.self_logins derives from --author in pr_queue_snapshot.py::build_config. Autopilot drops --author → resolve_authors(None) == [] → empty set → the Part A filter is dormant in autopilot (the same reason detect_foreign_activity is already silently dead there). Source the self-login set independently: mirror babysit_merge.py's shipping --self-logins @me,<extras> flag — add --self-logins @me,<babysit_self_logins> to pr_queue_snapshot.py, resolved via resolve_authors, folding (not replacing) @me + babysit_self_logins. Wire SKILL.md's snapshot invocation + effective-config block.

Self-login resolution source

config.self_logins (ClassifyConfig.self_logins), from @me + babysit_self_logins (userConfig already in .claude-plugin/plugin.json, rendered in SKILL.md). @me → gh api user --jq .login via babysit_gh.resolve_authors — same source the merge gate's --self-logins and readiness gate's --self/--extra-self use, and the same set detect_foreign_activity consumes. Covers the solo-maintainer case (self-login == author).

Acceptance criteria

1. PR authored by a self-login whose only new items since the last snapshot are the engine's own classification tables / "Fixed in <sha>" replies → new_human_blocking_feedback empty, needs_worker not set by it, and human_stop["required"]/the human-triage blocker not raised by those self items.
2. A new CHANGES_REQUESTED/blocking/unresolved-inline item from a different login still sets new_human_blocking_feedback and dispatches.
3. Criterion 1 holds in autopilot (no --author), via the decoupled --self-logins source.
4. Self-authored bot posts (posting identity in babysit_self_logins) are excluded from feedback["blocking"]/new_blocking_feedback too.

Notes

• Do NOT write "mirror the existing bot filter" into the fix — there is none. Honest framing: "the engine doesn't implement review-discipline §1 today; this brings it into line." Mechanism precedent: detect_foreign_activity (author_login(...).casefold() not in {l.casefold() for l in config.self_logins}).
• source-control:babysit-prs: gh-bot.sh bot token generation fails, worker writes fall back to personal identity #450 overlap: sourcing self-logins from babysit_self_logins (not just personal @me) covers the case where the engine posts under a bot token whose login differs — the same collect_feedback exclusion then handles both 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 (human self-replies) and source-control:babysit-prs: gh-bot.sh bot token generation fails, worker writes fall back to personal identity #450 (bot self-posts). babysit_self_logins must enumerate every posting identity, including any reply bot token.
• Precision: only self items reaching human_blocking manufacture the delta (severity-token tables + self inline replies). Plain "Fixed in <sha>" follow-ups fall to human → material-only, never a dispatch trigger — so the issue's "counts ANY new comment" is slightly imprecise (doesn't change the fix).