Found while verifying that the app still works after 3337c129 refactor(routes): delete app/Routes.ts. It does, and that part is fine. These two files are a separate, pre-existing loose end.
The routes
routes/ holds four files. Only api.ts is ever loaded:
| File | Routes | Reachable |
|---|---|---|
api.ts | 379 | yes |
buddy.ts | 2 (/versions, /commands) | no |
users.ts | 2 (/:id, /) | no |
Confirmed against production:
200 /
200 /api
200 /api/hello/world
401 /api/users <- declared in api.ts, auth-gated, so registered
404 /buddy/versions
404 /buddy/commands
404 /users
404 /users/1Why
The registry is a manifest naming which route files to load. Deleting app/Routes.ts falls back to the framework default, which is exactly one entry:
// storage/framework/core/router/src/route-loader.ts:63
export const DEFAULT_ROUTE_REGISTRY: RouteRegistry = { api: 'api' }Nothing names buddy or users, so nothing loads them. This is not a regression from the deletion. 1fa96add chore(routes): trim the route registry to the one line that is load-bearing had already reduced the file to { api: 'api' }, and the entry it dropped was v1: { path: 'v1', prefix: 'v1' }, which pointed at a routes/v1.ts that does not exist here. By the time 3337c129 deleted the file, it was a restatement of the default. Neither buddy nor users was in the registry before the trim either.
So these two files have never been served, under any version of the registry.
What to do with them
routes/users.tslooks redundant rather than missing:api.tsalready serves/api/users, which answers 401 rather than 404. Registeringusers.tswould add a second, unauthenticated surface for the same resource, so deleting it is probably what is wanted.routes/buddy.tsexposes/versionsand/commands. Worth deciding whether those are wanted at all before addingbuddy: 'buddy'to a registry, since bringing them back means re-addingapp/Routes.tspurely to name them.
Either way the current state is the worst of the three: the files read as live routing to anyone opening routes/, and they are not.