Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Fixius50/WorlBuilding-Writting-App/llms.txt

Use this file to discover all available pages before exploring further.

Chronos Atlas is built as a local-first thick client: all worldbuilding data lives in the user’s browser via the Origin Private File System (OPFS), and the React frontend is the authoritative runtime for reading, writing, and rendering that data. The stack combines React 19, TypeScript 5.7, and Vite 6 with SQLite WASM (via SQLocal) executing inside a dedicated Web Worker — delivering zero-latency persistence with no cloud dependency.

​
Tech Stack

LayerTechnologyVersion
UI FrameworkReact19.2.4
LanguageTypeScript (strict mode)5.7
Build ToolVite6
Local StateZustand5.x
Async State / CachingTanStack Queryv5
Data TablesTanStack Tablev8
Client-Side RoutingReact Routerv7
Map RenderingMapLibre GL5.x
Rich Text EditorTiptapv2
StylingTailwind CSSv3
Local DatabaseSQLocal (SQLite WASM over OPFS)0.17.0

​
Feature-Sliced Architecture

The frontend is organised around Feature-Sliced Architecture (Vertical Slice). Every product capability — World Bible, Timeline, Maps, Linguistics, Graph, Writing, Shell — lives in its own self-contained feature directory under src/features/. Features own all their layers internally and expose a single public contract through a root index.ts. Cross-feature communication happens through those public APIs only; deep imports into another feature’s internals are forbidden. The standard folder structure for every feature is: 
src/features/<FeatureName>/
├── application/   # use cases, business orchestration
├── components/    # visual components reusable within the feature
├── hooks/         # reusable hooks within the feature
├── pages/         # route views + co-located screen hooks
├── domain/        # types, models, domain contracts
└── store/         # local Zustand store (if needed)
Not every feature requires all six folders. Only create a layer when there are real files that justify it. Placement rules:
  • A hook used by a single screen lives next to that screen in pages/.
  • A hook shared across two or more components or pages moves to hooks/.
  • use* hooks must never reside inside components/; they always belong in hooks/ or pages/.

​
The Shared Kernel

src/features/Shared is the transversal UI utility layer. It provides primitive components, navigation helpers, modals, panels, feedback toasts, visual tokens, and adapter bridges — but it must never import business features directly. It is a pure utility kernel, not a container for domain logic.
Temporary integrations that must cross the boundary (such as feature-aware adapters) are the only permitted exception. These must be declared explicitly inside src/features/Shared/adapters/ to keep the violation isolated and trackable.
Shared exports are consumed using the @components and @components/* aliases. There is no additional ui/ segment in the import path.

​
Path Aliases

All path aliases are declared in frontend/vite.config.ts (and mirrored in frontend/tsconfig.json) and are the canonical way to navigate the codebase. Never use relative ../../../ traversals across feature or infrastructure boundaries.
AliasResolves ToPurpose
@srcRepository root shorthand
@featuressrc/featuresFeature directory root
@features/*src/features/*Any feature root or public export
@componentssrc/features/Shared/indexShared kernel barrel export
@components/*src/features/Shared/*Shared kernel sub-paths
@contextsrc/features/App/contextApp-level React contexts
@context/*src/features/App/context/*Individual context files
@databasesrc/infrastructure/localDB/clientSQLocal client instance
@networksrc/infrastructure/networkNetwork service layer
@network/*src/infrastructure/network/*Individual network services
@assetssrc/assetsStatic assets
@assets/*src/assets/*Individual asset files
@domain/databasesrc/features/App/domain/databaseCore database type contracts
@domain/mapssrc/features/Maps/domain/mapsMap feature domain types
@domain/timelinesrc/features/Timeline/domain/timelineTimeline domain types
@domain/writingsrc/features/Writing/domain/writingWriting feature domain types
@domain/linguisticssrc/features/Linguistics/domain/linguisticsLinguistics domain types
@domain/canvassrc/features/Linguistics/domain/canvasCanvas/glyph domain types
@domain/hierarchysrc/features/WorldBible/domain/hierarchyWorld Bible hierarchy types
@domain/graphsrc/features/Graph/domain/graphGraph feature domain types
@domain/uisrc/features/Shell/domain/uiShell/UI domain types
@infrastructuresrc/infrastructureInfrastructure root
@infrastructure/*src/infrastructure/*Individual infrastructure modules
@repositoriessrc/infrastructure/localDB/repositoriesRepository layer
@repositories/*src/infrastructure/localDB/repositories/*Individual repository services
@utilssrc/infrastructure/utilsShared utility functions
@utils/*src/infrastructure/utils/*Individual utility files
@localessrc/localesi18n locale files
@locales/*src/locales/*Individual locale files

​
Infrastructure Layer

All database access is mediated through a dedicated repository layer at src/infrastructure/localDB/repositories/. This layer wraps every SQL operation and exposes typed, domain-aware service functions (e.g., projectService, folderService, entityService, settingsService). Components, hooks, and use-cases import from @repositories/* — they never call sql or sqlocal directly.
Direct SQL calls (sql\…`orsqlocal.) inside feature components, hooks, or use-cases are a hard architectural violation. All data access must go through @repositories/`.
The SQLocal client in src/infrastructure/localDB/client.ts initialises the SQLite WASM Web Worker and exports the sql tagged-template function and sqlocal instance. The Vite build explicitly excludes sqlocal from dependency pre-bundling (optimizeDeps.exclude) and configures Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: credentialless headers — both required for SharedArrayBuffer and the SQLite WASM runtime. 
import { SQLocal } from "sqlocal";

export const sqlocal = new SQLocal("worldbuilding_app.sqlite3");
export const { sql } = sqlocal;

​
Architecture Guardrails

The frontend ships an automated architecture linting script in frontend/package.json: 
# Generate a report without failing CI
npm run arch:check

# Fail if any violations are found
npm run arch:check:strict
Both commands write their output to: 
frontend/reports/architecture-guard-report.json
The script verifies two rule sets:
1

Cross-feature deep imports

No feature may import from @features/<OtherFeature>/(components|hooks|pages|application|domain|store)/*. Only the public root @features/<OtherFeature> export is allowed.
2

Business logic in Shared

src/features/Shared/* must not import business features. The only permitted exception is inside src/features/Shared/adapters/*, which must be declared explicitly.

Build docs developers (and LLMs) love

Get started for freeTalk to us