feat(config): match [projects."…"] keys by pattern, and carry forge there

[max-sixty]

Problem

Forge platform is readable only from project config ([forge].platform) or a brand substring in the remote hostname. A self-hosted host carrying none of github/gitlab/gitea — a GitLab at git.company.example, a company git server — needs the same [forge] block in every repository's .config/wt.toml. Closes #3678.

The user-level [projects."…"] table is where per-repository settings already live without touching each repo, but its keys are exact, so covering a host means one entry per repository.

Solution

Pattern keys. A [projects] key containing * matches any run of characters, / included, so one entry covers every repository on a host, nested groups and all. * is the only metacharacter.

[projects."git.company.example/*"]
forge.platform = "gitlab"

[projects."git.company.example/platform/*"]
worktree-path = ".worktrees/{{ branch | sanitize }}"

Every matching entry applies, least- to most-specific, so a narrower key wins where two set the same field and leaves the rest alone. A literal key is the most specific of all; specificity is the count of non-* characters. Rules and rationale: the project_match module docstring.

forge on [projects]. Same shape as the repository's own block, carrying platform and hostname. Both describe the host rather than the repository — which is why an SSH alias resolved through ~/.ssh/config, a name local to one machine, belongs in user config rather than a repository's committed one. A repository's own [forge] still wins field by field, being the more specific of the two: a repository that sets only platform still takes a matching entry's hostname.

One resolver. wt list, its statusline, wt switch pr:, and CI-platform detection each read project config separately, so a configured platform could resolve in one command and read unknown in the next. They now share Repository::configured_forge_platform (and forge_hostname for the API host).

Approvals

approved-commands matches by the same rules, so a pattern entry approves its commands for every repository it covers. That widening is the user's to opt into — only a hand-written key is ever a pattern:

• wt config approvals add and the interactive prompt record under the exact project identifier, so approving in one repository never reaches another. An identifier that itself contains * (a starred remote URL or no-remote path fallback) is refused outright — persisting it verbatim would create an entry reads treat as a pattern; the interactive flow degrades to a warning plus a per-run approval.
• wt config approvals clear empties only the exact entry, leaving a pattern other repositories share intact — and both its outcomes end with a hint naming any pattern entries still approving commands for the project, so a surviving approval is traceable to the hand-written entry supplying it.
• --stale judges only the exact entry, so one repository's config can't revoke approvals the others rely on.

Tests

project_match unit tests cover * spanning /, . staying literal, specificity ordering, and the lexicographic tie-break. Config tests cover a host-wide entry applying to nested groups, exact-over-pattern precedence, field-by-field layering, hooks appending across both entries, and forge platform/hostname. Forge resolution tests cover the unbranded host, nested groups, a narrower entry winning, project config overriding, falling through to inference, and an invalid value leaving the host unresolved. Approvals tests cover pattern lookup plus the two exactness guarantees above.

Docs

src/cli/mod.rs (the primary source) gains "Matching several repositories with one entry" and "Forge platform and hostname" under user project-specific settings, plus a pointer from the project-config forge section. Generated mirrors and --help snapshots regenerated.

Review hardening

An adversarial review pass surfaced eight findings, all fixed:

• Approval widening (moderate): the starred-identifier refusal above. Previously such an approval persisted verbatim and silently approved its commands for every repository the star matched.
• Literal-key tie (moderate): a pattern whose stars all match empty (github.com/owner/repo*) ties the exact key on literal count and sorted after it, so its values won the fold. Literal keys now outrank any pattern outright.
• Docs vs behavior (moderate): the layering paragraph claimed "most specific wins" for everything; hooks and aliases actually append across matching entries (all run, least-specific first). Docs now say so, and state the forge field-by-field precedence.
• Minor: matches() is a two-pointer byte glob (was a per-call regex compile, ~0.7 ms per pattern key, a few hundred calls per wt list), pinned by an exhaustive differential test against a reference matcher; the invalid-platform diagnostics name their two possible config homes; a root [forge] in user config now points at [projects."<id>"].forge; docs note a host-wide key should end in /*; approve_command delegates to approve_commands, unifying their dedup predicates.

Relationship to #3681

This is an alternative to #3681, which adds a bespoke [forge-hosts] section for the same issue. Both can't land — they'd be two ways to write one sentence. This one puts the setting in the table that already carries per-repository user config, and the pattern keys are reusable for the workspace-scoped ask in #3654 where repositories share a host or namespace.

🤖 Generated with Claude Code

[worktrunk-bot]

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

One correctness gap in the specificity ordering: the "literal key is most specific" invariant isn't enforced when a pattern equals a literal key plus a star that matches the empty string. Inline suggestion with a one-line fix. Everything else — the resolver consolidation into configured_forge_platform/forge_hostname, the exact-only write/clear paths for approvals, and the layering tests — reads well.