carlos / platform Public

What

A claim on *.<parent>, made with carlos domains attach --app <a> '*.<parent>', makes every box derive one ordinary route_aliases row for each local instance of the app: <slug>.<parent> → <instance host>. This is the managed-Jelly layout. With it, a team at acme.bad.carlos.exciting.io also answers at acme.letsjelly.dev, with no per-team claim and no per-team DNS.

Why

The existing catch-all (--wildcard --catchall) sends every subdomain to ONE route, and it belongs to whoever holds the apex. Here that is a static site. So the Jelly manager makes one exact claim per team at signup.

Rules

• Only a person in the account that holds <parent>'s own claim may attach a catch-all. The box re-checks the parent on every pass.
• Deployment zones, console/tunnel/steering names, the apps domain and public suffixes are refused as parents: at the parent, under it, or above it.
• An exact claim on a derived name wins, whoever holds it. That is decided from the bucket listing, so an unreadable claim still wins. Real routes win too.
• While a catch-all is live, the attach doors refuse other accounts the names of the app's existing instances, with the neutral 409. They never refuse the caller's own older claim.
• Only provisioned, non-sidecar, non-replica routes of the claim's own account and app derive. At most 1000 per box.
• Old binaries skip the claim. All wire changes are additive.

The research across deployment types, the security cases and the review dispositions are in docs/superpowers/specs/2026-10-05-instance-catchall-design.md.

Testing

• Unit and door tests in internal/domains, internal/console and the CLI.
• Amadan CI is green on df6029c8, and so is go test ./... locally.
• An Opus review found three medium issues, all fixed with tests: an older claim's re-attach was refused, a read failure failed open, and the guard amplified a squat.
• Live on carlos.exciting.io (both binaries at df6029c8), 2026-10-05. - The letsjelly.dev testbed (account jelly-dev) was torn down and re-staged with *.letsjelly.dev attached to dev-managed-jelly. - A throwaway instance catchtest gained catchtest.letsjelly.dev within seconds. The name has no claim behind it. It got its own Let's Encrypt certificate, and the request reached the instance. - Deleting the instance dropped the name on the next pass. - letsjelly.dev, www and auth were unaffected, since their exact claims win. - An unknown label fails TLS over HTTPS and gets 404 over HTTP. - The letsjelly.com aliases in the other account were untouched. - A real signup through the manager then created team alpha-bravo-123 on the new layout.

Not landed. It is proposed in a discussion on this branch.