runtime down: a lane name shared with a scruff child can't be qualified, the suggested repo/lane form is refused too

[JulienMartel]

What happened?

A lane name existed in two repos at once: hausfold-haus/workspace-bar-visibility, plus a scruff child lane in hausfold-hausfold.co with the same name. I tried to tear down the lane's tart VM:

$ scruff runtime down workspace-bar-visibility --backend tart
✗  'workspace-bar-visibility' exists in more than one repo — qualify it: scruff runtime hausfold-haus/workspace-bar-visibility | hausfold-hausfold.co/workspace-bar-visibility

$ scruff runtime down hausfold-haus/workspace-bar-visibility --backend tart
✗  'workspace-bar-visibility' exists in more than one repo — qualify it: scruff runtime hausfold-haus/workspace-bar-visibility | hausfold-hausfold.co/workspace-bar-visibility

Expected: the qualified name the error suggests to tear down that lane's VM. What happened: it gave the same refusal again, so runtime down couldn't be run by any name. I got around it with tart stop + tart delete scruff-workspace-bar-visibility.

Two smaller things in the same message:

• The suggested command is missing the verb and flag it needs (scruff runtime <repo>/<lane>, with no down and no --backend).
• The VM itself is called scruff-<lane>, not qualified by repo, so two same-named lanes in different repos would collide on one VM name too.

Where

scruff runtime down (and presumably up / enter), when resolving the lane name. The ambiguity came from a scruff child lane that took its parent's name in a sibling repo.

Diagnostics

scruff 1.6.0
scruff doctor: findings — none; lanes 2 across 1 repo — 2 live
tart backend, SCRUFF_TART_BASE=haus-golden

Anything else

scruff child gives the sibling lane the same name as its parent on purpose, so this ambiguity comes up every time a lane with a child starts a VM.