carlos / platform Public

Fix on branch first-route-wildcard (cb717dc0, CI green), on behalf of James.

The problem

A member turns --wildcard or --catchall on by re-attaching the hostname:

carlos domains attach --app dev-jelly-site --wildcard letsjelly.dev

On a first-route claim (the claim carlos deploy --kind static --host makes, with an empty Route), this went wrong:

1. resolveAliasRoute defaulted the route to the app's single instance record. For a first-route app, that is the static record the claim itself declared, at the same host.
2. AttachClaim then converged the claim into an alias of its own host.

The site still served. But:

• Log noise: every box pass logged alias <host> skipped: a real route owns that host.
• Detach broke: detach's first-route branch keys on an empty Route, so it stopped deleting the record. The route outlived the claim.

The static path (kind: "static") never applied capability flips at all, so the CLI had no clean way to put --wildcard on a first-route claim.

The fix

The attach door recognises the caller's own first-route claim when the request names no route, or names the host itself (a hostname cannot alias itself). It then:

• leaves the route alone;
• applies any capability flip through setDomainCapabilities;
• answers like the static path does.

Any other holder's claim falls through to the ordinary path and its neutral refusals, unchanged. Only the caller's own claim takes the branch, so it reveals nothing the list door doesn't already show them.

Evidence

• Tests: four re-attaches (no route, route equal to the host, wildcard flip, wildcard plus catchall). In each, the claim keeps its empty Route and gains the capabilities, and detach still removes the record. Another holder's first-route claim still gets the neutral 409. All four were watched to fail with the fix disabled.
• Live on carlos.exciting.io since 2026-10-05 (build 2cf481bc). --wildcard on letsjelly.dev left the claim first-route, with WILDCARD yes and DELEGATION delegated.

Possibly affected today: any existing first-route claim that had a capability flipped through the CLI. woodstar.app is the obvious candidate. Its claim may already carry route == host; carlos domains list shows it in the ROUTE column. If so, a one-off re-attach won't repair it. The claim would need its Route cleared.