source-control:babysit-prs: gh-bot.sh bot token generation fails, worker writes fall back to personal identity

[kyle-sexton]

Lane: babysit-prs (safe-tier fix-round worker)

Triggering example: melodic-software/medley#1600, babysit worker run on branch fix/comment-review-gate-runner-routing (head bbcc5a2ef2a2627acd677d975e4929b91f7f2483). Worker needed to react to a bot comment, post a classification reply, and edit the PR body to fix a failing pr-issue-linkage check.

What happened: tools/github-auth/gh-bot.sh (in melodic-software/medley) reported Bot token generation failed, using personal identity on every write attempt this cycle. All three writes (reaction, classification reply, PR body edit) landed authored as kyle-sexton instead of the intended bot identity. The fallback is silent/local-log-only — nothing surfaces it to the babysit orchestrator or the PR itself, so a run of writes silently drifts from the intended attribution convention with no signal unless a human happens to read the worker's own transcript.

What should happen: either bot token generation succeeds reliably for babysit-lane writes, or — if the graceful degrade is intentional — the fallback should be a reported/material finding the orchestrator surfaces in its cycle status (not just a script-local log line), so attribution drift is visible without reading raw worker output.

Category: operational

[kyle-sexton]

This was generated by AI during triage.

Triage → needs-human. Bot-identity/permissions cluster with #454. Cross-repo: tools/github-auth/gh-bot.sh (token generation) lives in melodic-software/medley, not here; the surfacing fix lives here in source-control/babysit — the orchestrator should report attribution-drift in its cycle status rather than leaving it a script-local log line. Decide: fix token-gen reliability (medley) vs make the personal-identity degrade a material reported finding (here). Silent drift to kyle-sexton on all writes is the exposure. Priority: high.

[kyle-sexton]

Maintainer decision (2026-07-19, batch-approved; relayed by planning session). Proceed, with the diagnosis reframed by evidence:

• The token machinery is sound where creds are bound — a melodic-ai[bot] installation token minted successfully on the desktop at 01:55 today. The medley-session failure is environment/scope-specific (unbound creds or App not installed on that repo), not a code defect. Confirm whether the environment half is already resolved before changing token code.
• The actionable fix is OBSERVABILITY: gh-bot.sh calls generate-token.sh with --quiet 2>/dev/null and discards the specific failure reason, then silently falls back to the personal identity. Surface the reason and make the fallback loud (warn with cause; consider a strict mode that refuses fallback for write operations).
• Sequencing: this is the hard prerequisite for feat(source-control): babysit autopilot merge tier — bot-account review + criteria-gated merge #476 (author≠approver needs a real distinct actor) and for auditable gate compliance. 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 is NOT gated on this — it ships independently.

[kyle-sexton]

This was generated by AI during triage. · Category: operational (bug) · Priority: priority: high (week: pipeline correctness — silent attribution drift). Routed status: ready.

#450 — Surface silent bot→personal identity fallback as a cycle-status finding

On a safe-tier worker run against melodic-software/medley, the consumer's identity wrapper reported "Bot token generation failed, using personal identity" and every write (reaction, classification reply, PR body edit) silently landed authored as the personal user. The fallback is local-log-only: nothing reaches the babysit orchestrator or the PR, so attribution silently drifts with no signal unless a human reads the worker transcript.

Root-cause split (why this is two tickets)

The token-generation failure lives in medley's tools/github-auth/gh-bot.sh — a different repo. This plugin has no identity wrapper of its own: babysit writes go through plain gh and git push, and the bot identity is entirely a consumer concern. So "make bot-token generation succeed" is not this plugin's code and is scoped out here (see cross-repo note below).

What is in-repo and actionable: the babysit orchestrator can and should detect that a write it recorded performing landed under the wrong identity, and surface it. That is this ticket.

In-repo behavioral change

The orchestrator already keeps a mutation ledger — every comment, push, resolve, and merge it recorded performing — and already reconciles it against GitHub timeline events in the foreign_activity detection arm. That arm today asks only "is this timeline event accounted for under one of my self-logins?" and treats every self-login as acceptable. A write that lands as the personal user (still a self-login) therefore passes clean and invisibly.

Extend that same ledger↔timeline reconciliation with an intended-write-identity dimension:

• Detection signal (in-repo): for each write the ledger recorded performing, verify the landed timeline event's author is the intended bot write-identity — not merely some accepted self-login. When a recorded write landed under a self-login other than the intended write-identity, that is attribution drift. This is pure plugin-side authorship verification; it requires no signal from the consumer's wrapper.
• Named gap this exposes: the plugin has no "canonical/intended write identity" concept today. babysit_self_logins defines acceptable-as-mine, not intended-as-author. Introducing that intended-write-identity notion (and its unset/degrade behavior) is part of the in-repo scope, not an incidental detail.
• Where it surfaces: the same material-finding channel the foreign_activity contention report already uses — the per-cycle status / Reporting surface, alongside the existing "suspicious state changes such as missing permissions / changed branch protection." It becomes a first-class attribution-drift material finding on the affected PR's status line, not a transcript log line.

Optional, medley-side (not the in-repo path): the consumer wrapper could additionally emit a structured, non-silent fallback marker as a faster trip-wire. That belongs in the medley bucket with the token-gen fix, because reaching for gh-bot.sh's marker would couple this plugin to consumer internals and re-import the cross-repo dependency this ticket scopes out.

Acceptance criteria

• A run in which bot-token generation fails and a write lands under the personal self-login instead of the intended bot write-identity produces a visible orchestrator-level material finding in the cycle status, naming the attribution drift and the affected PR — with no change to medley gh-bot.sh required to make the test pass. (If the test only passes by editing the consumer wrapper, detection is in the wrong repo.)
• The finding rides the existing material-finding / cycle-status channel; no new silent-log-only path is introduced.
• foreign_activity's existing behavior (unaccounted-event contention) is preserved; the new dimension is additive.
• The intended-write-identity concept has defined unset/degrade behavior (e.g. when no intended identity is configured, the check is dormant rather than firing false positives).

Cross-repo scope note

The token-generation root cause — bot token generation failing and falling back — is owned by medley (tools/github-auth/gh-bot.sh) and must be tracked as a separate item against medley, not this plugin. This plugin cannot and should not fix it; it can only make the drift visible.

Dependency

This unblocks #476 (autopilot merge tier), which lists #450 as a prerequisite: autopilot's stronger write autonomy makes silent attribution drift materially worse, so drift must be orchestrator-visible before that tier ships.

Decision defaulted: (b) surface the bot→personal-identity fallback as an orchestrator-visible material finding in the babysit cycle status; the token-generation root cause is cross-repo (medley gh-bot.sh) and tracked there, not in this plugin — veto before merge