Web Structure

The frame, routes, and modules layout gives every file one predictable home: cross-route values in the frame, one address per route file or folder, and use-case code under the module that owns it. A reader moves from a use case to its code by path alone, on either stack. This realizes litespec/frontend/structure#organize-a-frontend-into-frame-routes-and-modules.

React:

apps/{frontend}/
  src/
    app/       the frame: client configuration, session, language, permissions, formatting, shell data
    routes/    one file per address, compiled into a typed route tree
    modules/   one folder per backend module, aggregate, and use case
  tests/
    unit/      logic tests
    routes/    the route contract suite
    e2e/       evidence specifications
  package.json
  vite.config.ts

Svelte:

apps/{frontend}/
  src/
    routes/    one folder per address, with a page per folder
    lib/
      app/       the frame: client configuration, session, language, permissions, formatting, shell data
      modules/   one folder per backend module, aggregate, and use case
  tests/
    unit/      logic tests
    routes/    the route contract suite
    e2e/       evidence specifications
  svelte.config.js
  vite.config.ts
  package.json

The generated route artifacts, build output, and dependency folders stay untracked.

Reviewed forWhich frontend trees break from the frame, routes, and modules layout their stack page states? Look in the frontend tree.

Marked guidance: a reviewer answers this question.

The folder path mirrors the backend use case, which tells a reader where to look but tells a tool only a resemblance. A typed constant is the frontend mark in both mark styles: a mistyped identifier fails the consumer's type check against the generated union, and litespec model check reports it as mark-unknown where no type check ran, and the route files import the module instead of restating the identifier. The calls a screen makes through the generated client remain the computed calls link; the mark adds the written link from the screen to the use case it serves. A query folder at {module}/use-cases/{use-case}/ mirrors a use case with no one aggregate, so its expected mark still names use-case/<module>.<use-case>, from the module and use-case segments alone.

The list-expenses module in the Claimwick web frontend exports its mark.

Svelte:

// src/lib/modules/spending/expenses/list-expenses/litespec.ts
import type { LiteSpecMark } from "#lib/app/litespec-records.ts";

export const litespec = { implements: "use-case/spending.list-expenses" } as const satisfies LiteSpecMark;

React:

// src/modules/spending/expenses/list-expenses/litespec.ts
import type { LiteSpecMark } from "src/app/litespec-records";

export const litespec = { implements: "use-case/spending.list-expenses" } as const satisfies LiteSpecMark;

Checked bylitespec model check reports mark-missing (level S) for a use-case folder exporting no litespec constant, and mark-unknown (level S) for one naming a use case its path does not mirror; for a folder at {module}/use-cases/{use-case}/ the mirrored use case is the one its module and use-case segments name, with no aggregate segment.

Marked checkable: the tool named here checks it.

The records file is a cross-route value every module and route imports, which is what the frame holds on both stacks: src/app/ on React and src/lib/app/ on Svelte, so no stack-specific folder is needed. A union holding every browser use case of the project would let one frontend mark a use case only another frontend reaches, and the type check would pass; a union per frontend makes that mistake a type error. The file exports the UseCaseId and ScreenId unions, the LiteSpecMark type, and the proves helper browser tests annotate with.

litespec model render writes apps/web/src/lib/app/litespec-records.ts for the Claimwick web frontend, whose UseCaseId holds the use cases its entry point reaches and nothing else.

Checked bylitespec model render writes each frontend's file into its frame from its own entry points, and litespec model check reports mark-unknown (level S) for a mark naming a use case or screen outside its frontend's entry points.

Marked checkable: the tool named here checks it.

A lib folder on React would sit beside src/app as a second frame, and src/app already holds the frame. A stores folder on Svelte would gather shared state in one place, while the rules put shared state in the frame or beside its readers. Refusing both names stops the second home before anything moves into it.

Reviewed forWhich React folders take the name lib, and which Svelte folders under src/lib take the name stores? Look in the frontend tree.

Marked guidance: a reviewer answers this question.

Client configuration, session read, language choice, permissions, formatting, and shell data cross every route. Filed in the frame folder, each has one home; filed in a route, each exists once per route with copies to keep equal. A browser API reached from a use-case module belongs here too, because a module renders and reads data rather than touching the device. This realizes litespec/frontend/structure#locate-cross-route-values-in-the-frame.

Reviewed forWhich cross-route values or browser uses sit outside the frame folder their stack page names? Look in the frame folder and the route and module sources.

Marked guidance: a reviewer answers this question.