framework symbols

path symbols (_, $, ()) carry meaning only because a specific parser in a specific directory gives them behavior. reused elsewhere they become decorative lies: readers assume grammar that does not exist, import paths expecting special handling, and tribal naming rules form around symbols that mean nothing. keeping symbols inside their owning parser preserves the invariant that a name's shape predicts its behavior.

symbols in files and folders are framework grammar, not a project-wide naming palette: use a symbol only in the directory and framework that parses it, never as decorative shorthand elsewhere.

reusing a routing symbol outside its parsing context creates false meaning: services/_internal/billing reads as a pathless layout, but no parser enforces it — readers open files instead of trusting names, and eventually someone writes a rule "all internal services start with _" based on a lie (tribal memory instead of enforced grammar).

before creating or using a symbolic filename/folder convention, answer: which parser recognizes it, which directory enables that grammar, what behavior it causes, where the authoritative framework documentation is. any answer missing → use ordinary domain/responsibility names.

for each symbol-bearing path, locate the framework/parser configuration and prove the generated route/resource behavior. list symbol-prefixed folders in the source tree; each must be explainable by one row of this document, not by local convention memory.

the ~ source-root prefix and its resource families are owned by the cloudflare stack; this file defers to that owner and does not restate its rules.

TanStack router does not assign a general filename meaning to +.

bad

app/(features)/billing/       // route group grammar outside app directory
services/_internal/           // pathless-layout token, no parser reads it here
components/+panel.tsx         // sveltekit route file token on a component
utils/[cacheKey]/index.ts     // next.js dynamic segment syntax in utils folder

routing symbols are reused where no parser reads them: services/_internal/logging reads as "internal", the parser never enforces it, imitators create services/_helpers expecting the same behavior, and the tokens become tribal memory instead of enforced grammar.

good

app/(features)/billing/page.tsx   // next.js route group in app/: parser enforces url-omitting
src/routes/_auth.login.tsx        // tanstack pathless layout in src/routes/: parser recognizes it
src/routes/+page.svelte           // sveltekit route file in src/routes/: framework-invoked
components/AuthPanel.tsx          // ordinary PascalCase component name: no parsing context needed
infra/database/index.ts           // folder barrel for schema/mapper leaves: documented nesting rule

each symbol lives only in the directory and framework whose parser assigns it that exact meaning; outside that context, use plain explicit names. a symbol seen in the tree is either enforced grammar or nothing, never a guess — new team members and agents navigate by that contract instead of opening files.

• reuse routing tokens in unrelated source folders.
• invent a special symbol without documenting its parser, scope, and owner.
• treat the same symbol as having the same meaning across frameworks.

TanStack Router, Next.js App Router, SvelteKit, Remix, and Nuxt publish the authoritative naming lists for their own symbols; this standard defers to them by name, not by link.

file naming · cloudflare stack · import aliases · layered source organization