[bug] subordinate_status: refusals report success, lookups need a UUID the model doesn't have, and repo GitHub coordinates are missing

[serge-ivo]

Two small defects in the same tool, both visible four times in one Coder Lead conversation
(2026-08-06, 5fab318d).

1. A refusal is reported as success

lib/connectors/supervision.ts:121:

const subs = await subordinateSummaries(ctx, only);
if (!subs.length) {
    return {
        content: only ? "You do not supervise that agent. Call list_subordinates…" : NO_SUBORDINATES,
        success: true,        // ← a refusal
    };
}

So the transcript shows:

✅ subordinate_status   You do not supervise that agent. Call list_subordinates to see who you may address.

A green tick on a call that did nothing. It appeared in four consecutive turns (22:33, 22:34,
22:35, 22:36), each time followed by a retry — so a reader scanning the tool log sees eight
successful status calls where there were four.

success is what the console renders and what the model reads back. A failed lookup should be
success: false, the same way check_work returns success: false for a run that is not yours.

2. It takes an instance id, and the model has a name

Every one of those four turns follows the same shape:

✅ subordinate_status   You do not supervise that agent…
✅ list_subordinates    [{ instanceId: "964594b6…", name: "FAS platform", … }]
✅ subordinate_status   { … the real answer … }

The user says "Focus on FAS platform"; the model has a name; the tool wants a UUID. It costs
an extra round trip on every single turn, and the tool description already tells it to go read
list_subordinates — so the retry is the documented path, not a mistake.

Accept a name (or a unique prefix) and resolve it against the roster the tool already loads. The
graph is small and owner-scoped; there is no ambiguity risk worth this cost. Keep the id working.

3. Related: the Lead has no GitHub coordinates for its subordinates

Same conversation, 22:36:31 — user asks "Are there any open tickets?":

❌ github_list_issues   Couldn't reach GitHub for "fws" (No github access for "fws".)

The Lead passed "fws", because that is what it has: subordinate_status reports the repo's
display name (fws/platform), never its githubRepo (freewebstore-online/platform). It then had
to ask the user for the owner/name — for a repo the platform already knows, since coding_repos
stores github_repo and the FAS diagnostics show it populated.

Include githubRepo in the per-subordinate repo block. Same class as #259: the supervisor was
missing a fact the platform holds, so it guessed and then asked the human.

Verification

• An unknown subordinate returns success: false.
• subordinate_status resolves "FAS platform" without a preceding list_subordinates.
• A Lead asked for open issues on a subordinate's repo reaches GitHub without asking the user for
  the path.

[serge-ivo]

Verified: GitHub access was never the problem

Called github_list_issues on the FWS instance with the correct coordinates:

repo: "freewebstore-online/platform"  →  success, 30 open issues

The GitHub App is installed and working. The Lead's failure was entirely the owner string — it
passed "fws", the display name, because that is all subordinate_status gives it (point 3 above).

But the error text sent the user to fix the wrong thing

❌ github_list_issues  Couldn't reach GitHub for "fws" (No github access for "fws".).
                       This is usually transient — try again. If it kee…

and the Lead concluded, reasonably:

Can't reach GitHub for the FWS repo — the API returned a no-access error. You may need to
re-authorize the ProAgentStore GitHub App for that repo.

Both halves of the message mislead:

• "No github access for X" reads as an authorization failure. The real cause is that X is not
  a GitHub owner at all — no installation could ever match it. A user following this would go
  re-authorize an App that is already correctly installed.
• "This is usually transient — try again" is false for this cause. Retrying with the same
  unknown owner fails identically, forever. The hint invites exactly the loop it should prevent.

Same shape as #271, where a 409 appended "(and run pags up)" unconditionally and sent a user
chasing a runner that was already up. An error that names the wrong remedy is worse than a terse
one, because it is actionable in the wrong direction.

Suggested

Distinguish the causes in installationTokenForOwner's failure path:

• no installation for a known owner → "the ProAgentStore GitHub App is not installed on <owner>"
  • the install URL. Actionable, and the current wording is right for this case only.
• owner not found / not an owner → "<owner> is not a GitHub owner — did you mean <githubRepo>?"
  The platform knows the answer: coding_repos.github_repo holds it.
• a real transient (5xx, timeout) → keep "try again", and only then.

Once point 3 lands (ship githubRepo in subordinate_status) this particular call stops failing —
but the misleading text stays reachable by any other caller with a bad owner, so it is worth fixing
on its own.

[serge-ivo]

Fixed in 792d7a0. All three.

1. Refusal reports success. observeSubordinates now returns success: false for a named agent that is not in the caller's graph. An empty roster deliberately stays success: true — that is a true answer to "what is everyone doing", not a failed lookup. I checked the neighbouring tools: no other connector tool had the pattern (delegate_goal, check_delegation's run-id branch and check_work already return false).

2. Lookups needed a UUID. subordinate_status, check_delegation and delegate_goal now take a name ("FAS platform") or a unique fragment, via a shared pure resolveSubordinate:

• exact instance id or exact name (case-insensitive) wins outright, so an agent named FAS stays reachable next to a sibling named FAS platform;
• otherwise a unique prefix/fragment;
• ambiguity is refused, not guessed — picking one of two would send a goal to the wrong repository, the failure a supervisor cannot see — and the refusal lists the roster so the next call can be right without a second lookup;
• resolution happens inside rows already restricted to the graph, and delegateToInstance re-checks membership on the resolved id, so a looser spelling cannot widen who is reachable;
• the payload echoes resolved: {asked, instanceId, name}, because otherwise the answer silently redefines the question.

3. GitHub coordinates. repo.githubRepo (from coding_repos.github_repo) is in the per-subordinate repo block, and the legend says which of the two is a GitHub path — "repo.name is a display label; it may look like a path and still not be one" — following the connectivity precedent from #259 of putting it in the payload, not only the description.

⚠️ No CI run verified this — GitHub Actions is in a declared major outage. Verified locally: pnpm -r typecheck, vitest (4389 passed), biome, docs:drift, check-file-size.