[max-sixty]

Reverts the branded half of the exact-label classifier and deletes the
diagnostic built to explain it. github-enterprise.acme.com, mygithub.life-white.uk,
gitlab-internal.company.com, and the github-personal SSH alias resolve to
their forge again, so CI status, wt switch --prs, and repo.provider work
with no config.

Why the label boundary goes

It looked like an ownership check and wasn't one. An attacker controls their own
DNS, so github.attacker.example has the exact label github and classified
fine; gitlab.evil.co.uk likewise. What the rule actually excluded was the
self-hoster who put the brand in a hyphenated name. It failed open for the
adversary and closed for the customer.

The residual case for it doesn't survive either. The hostname comes out of the
user's own .git/config, and whoever can put a host there can put code there
too — the trust decision happens at clone time, and by the time worktrunk reads
the remote the user is already building from it. All the classification decides
is which forge CLI (gh, glab, tea, az) runs against it.

So the rule is recall-first: any host carrying github, gitlab, or gitea
matches, first match winning. The cost is a host that merely sounds like a forge
getting a forge CLI run at it, which surfaces as that CLI's error rather than as
silence — the better of the two failures, and forge.platform overrides it.

What stays

Azure DevOps keeps suffix matching on its two service domains, and for a reason
unrelated to security: those are service domains rather than a brand in the
host, so every real hosted instance already matches, and the on-prem edition
carries neither string. dev.azure.com.attacker.example and
evil-visualstudio.com are outside the domains and carry no brand to fall back
on, so they stay unclassified. Userinfo still resolves to the network host, so
https://github.com@attacker.example/… is attacker.example.

What goes

LegacyForgeAlias, Repository::legacy_forge_alias,
legacy_forge_alias_diagnostic, and its three emit sites in wt list,
wt switch --prs, and wt config show --full. Every host the diagnostic fired
on now classifies, so it could only ever return None. A host with no brand at
all still reaches the existing generic hint, which is the right message there —
there is no platform to infer.

The end-to-end warning-dedup test goes with it, since no warning is raised from
both the collect and --prs threads any more; stash_warning_preserves_order
keeps the mechanism covered.

Docs

## Forge platform in src/cli/mod.rs described the override as being for SSH
aliases and self-hosted instances, which now detect on their own. It states the
rule and scopes the override to hosts carrying no brand — a Forgejo instance at
forge.example.com. Mirrors, dev/wt.example.toml, and the two config help
snapshots regenerate from it.

---

The branch's history has a false start — the first commit widened the diagnostic, the second deletes it in favour of relaxing classification — plus a merge of main after v0.71.0 shipped. The net diff is the second approach; it all squashes on merge.

Also supersedes #3672, the triage bot's PR for the same issue — it widens the diagnostic rather than removing the need for one, so it should be closed too.

Closes #3671

This was written by Claude Code on behalf of @max-sixty

[worktrunk-bot]

Reviewing as a draft — flagging anything that looks worth a quick fix. Mark ready for a full review.

The classifier change reads cleanly: from_host (which drives dispatch) stays exact-label, branded_forge_name is diagnostic-only and opt-in, and the test matrix pins both the widened hint set and the unchanged dispatch boundary. No concerns there.

One stale doc, outside this diff: the unreleased ## 0.71.0 CHANGELOG entry for #3662 describes the behavior this PR replaces. Its third paragraph still reads "Only one case announces itself — a single-label SSH alias of the github-personal form … A self-hosted instance at a hyphenated hostname gets no such message; it simply stops reporting CI," and quotes the old SSH host alias github-personal is not auto-detected… wording. After this change every branded host announces itself, a hyphenated self-hosted instance does get the message, and the lead-in is now Remote host …. Since #3662 and #3673 land in the same unreleased release, that paragraph would ship describing behavior that never existed — worth updating that entry (or folding a note into it) before marking ready. Happy to push that CHANGELOG edit if you'd like.

[worktrunk-bot]

Reviewing as a draft — flagging anything that looks worth a quick fix. Mark ready for a full review.

The revert reads cleanly: from_host is now a straight substring test with Azure kept on suffix matching, LegacyForgeAlias and its three emit sites are fully removed with no dangling references, and the tests pin both the widened classification and the Azure boundary. Docs and help snapshots are regenerated, and the test suite is green. No concerns in the code.

One thing to reconcile before this lands — and it supersedes the CHANGELOG note on my previous (draft) review, which is now stale on two counts.

Since that review, v0.71.0 shipped — it's tagged at this PR's base commit (aac20ee), and the Forge hosts are classified by exact DNS label entry under ## 0.71.0 is in the released changelog. So that entry is now history describing what users actually got in 0.71.0; it shouldn't be rewritten. This PR reverts that shipped, breaking behavior (gitlab-internal.company.com, github-mirror.example.com, mygithub.life-white.uk, and the github-personal alias all classify again with no config), but adds no CHANGELOG entry. Worth a new ## 0.72.0 section documenting the reversal, so a user who read the 0.71.0 breaking-change note sees it rolled back.

My earlier suggestion to fold a note into the #3662 entry no longer applies — that was written when 0.71.0 was still unreleased and the approach was to widen the diagnostic rather than remove it.

[max-sixty]

Right that v0.71.0 shipped — it's tagged at aac20ee, and the exact-label entry is in the released changelog. I've merged main in, so this now sits on top of the release.

Not adding a ## 0.72.0 section, though. Entries here are written when the version is cut, not by the PRs that go into it: ## 0.71.0 was still absent from CHANGELOG.md while #3662, #3664, #3665, #3666, and #3669 sat merged on main, and the release skill puts "Add ## X.Y.Z section at top with changes" at step 9 of the release itself. Step 12 is the backstop for exactly this case — it lists everything that reached main since the cut and folds what's user-facing into the changelog before the tag, so the reversal gets documented when 0.72.0 is cut, alongside whatever else lands first.

The concern behind the suggestion is right and worth carrying forward: a user who read 0.71.0's breaking-change note should see it rolled back, so the 0.72.0 entry needs to name the reversal rather than describe the new rule from scratch.

This was written by Claude Code on behalf of @max-sixty