Next.js App Router: app/**/route.ts handlers produce 0 Route nodes, so cross-repo-intelligence finds no edges

Environment

• codebase-memory-mcp 0.8.1 (ui variant), macOS arm64 (Apple Silicon)
• Fleet of TypeScript repos indexed into one store with mode: full

Problem

Next.js App Router projects define HTTP endpoints via the file convention: app/api/**/route.ts exporting GET / POST / PUT / DELETE handler functions. These handlers are indexed as plain Function nodes, but zero Route nodes are extracted:

search_graph(project=..., label="Route")
→ {"total":0, "results":[], "hint":"No nodes with this label. Available labels: Function, Method, Class, Interface, Route, ..."}

Verified on two independent Next.js App Router codebases (one with ~20 route handlers under src/app/api/, including nested dynamic segments). Both index cleanly (~4k nodes) with correct call graphs — only route extraction is affected.

Because no Route nodes exist, index_repository(mode="cross-repo-intelligence", target_projects=["*"]) reports projects_scanned: N but 0 edges of every CROSS_* type, even though sibling repos in the store call these endpoints.

Expected

Route nodes derived from the file convention:

• path from the directory structure relative to app/ (e.g. src/app/api/chatgpt/actions/route.ts → /api/chatgpt/actions), with [param] / [...slug] segments normalized
• method from the export name (GET, POST, etc.)

App Router has been the Next.js default since v13, so this likely affects a large share of modern TS repos — the pages-style pages/api/*.ts convention may deserve the same treatment.

Related

Possibly also worth covering: Convex httpRouter registrations (http.route({ path, method, handler }) in convex/http.ts) are similarly not extracted as Route nodes — happy to split that into a separate issue if you prefer.

Adjacent existing reports for other frameworks: #678 (FastAPI), #686 (Fiber), #734 (Spring prefix), #292 (protocol-aware matching design).