carlos / platform Public

What

handleAPIDomainAttach recognises the caller's own first-route claim (empty Route) when the request names no route, or names the host itself. It leaves the route alone, applies any --wildcard/--catchall flip through setDomainCapabilities, and answers {host, route: host, created: false} like the static path does. Any other holder's claim falls through to the ordinary path and its neutral refusals, unchanged.

Why

carlos domains attach --app <a> --wildcard <host> on a first-route claim, the claim carlos deploy --kind static --host makes, went like this:

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 converged the claim into an alias of its own host.

The result still served, but:

• every box pass logged alias <host> skipped: a real route owns that host;
• detach stopped deleting the record. Its first-route branch keys on an empty Route, so the route outlived the claim.

Found while preparing --wildcard on letsjelly.dev (a static first-route claim) for a delegated wildcard certificate (see #233).

Testing

• apidomains_firstroute_test.go covers four re-attaches: no route, route equal to the host, a wildcard flip, and 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 cases were watched to fail with the fix disabled.
• gofmt, go vet ./... and go test ./... are clean, with all 59 packages passing.