caspian-utils 0.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/docs/auth.md +690 -0
- package/dist/docs/cache.md +257 -0
- package/dist/docs/commands.md +117 -0
- package/dist/docs/database.md +351 -0
- package/dist/docs/fetch-data.md +260 -0
- package/dist/docs/index.md +65 -0
- package/dist/docs/installation.md +98 -0
- package/dist/docs/metadata.md +196 -0
- package/dist/docs/project-structure.md +193 -0
- package/dist/docs/pulsepoint.md +368 -0
- package/dist/docs/routing.md +231 -0
- package/dist/docs/state.md +264 -0
- package/dist/docs/validation.md +293 -0
- package/package.json +16 -0
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Installation
|
|
3
|
+
description: Learn how to create a new Caspian application so AI agents use the first-time setup flow instead of assuming an existing project is already in place.
|
|
4
|
+
related:
|
|
5
|
+
title: Related docs
|
|
6
|
+
description: Continue with the routing and structure guides after scaffold so the new app follows Caspian conventions.
|
|
7
|
+
links:
|
|
8
|
+
- /docs/routing
|
|
9
|
+
- /docs/project-structure
|
|
10
|
+
- /docs/index
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
This page documents the first-time Caspian setup flow for new applications.
|
|
14
|
+
|
|
15
|
+
## Overview
|
|
16
|
+
|
|
17
|
+
Caspian provides a CLI that scaffolds a production-ready project with a FastAPI backend and a PulsePoint-based reactive frontend workflow.
|
|
18
|
+
|
|
19
|
+
## Default App Stack
|
|
20
|
+
|
|
21
|
+
The scaffolded Caspian baseline is:
|
|
22
|
+
|
|
23
|
+
- PulsePoint for reactive frontend behavior.
|
|
24
|
+
- `@rpc()` plus `pp.rpc()` for browser-triggered data fetching and mutations.
|
|
25
|
+
- `casp.validate` with `Validate` and `Rule` for input validation and sanitization.
|
|
26
|
+
|
|
27
|
+
## System Requirements
|
|
28
|
+
|
|
29
|
+
Install the supported runtimes before creating a project.
|
|
30
|
+
|
|
31
|
+
- Node.js `v24.14.0` or newer
|
|
32
|
+
- Python `v3.14.0` or newer
|
|
33
|
+
|
|
34
|
+
You can verify your environment with:
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
node -v
|
|
38
|
+
python -V
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## Create a New App
|
|
42
|
+
|
|
43
|
+
Run the scaffold command:
|
|
44
|
+
|
|
45
|
+
```bash
|
|
46
|
+
npx create-caspian-app@latest
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
The interactive wizard walks through the main project options, including:
|
|
50
|
+
|
|
51
|
+
- Project name
|
|
52
|
+
- Tailwind CSS support
|
|
53
|
+
- Prisma ORM setup
|
|
54
|
+
- Swagger API documentation
|
|
55
|
+
|
|
56
|
+
## Recommended VS Code Setup
|
|
57
|
+
|
|
58
|
+
For the best development experience, use these VS Code extensions:
|
|
59
|
+
|
|
60
|
+
- [Caspian Official Framework Support](https://marketplace.visualstudio.com/items?itemName=JeffersonAbrahamOmier.caspian)
|
|
61
|
+
- [Python](https://marketplace.visualstudio.com/items?itemName=ms-python.python)
|
|
62
|
+
- [Pyright](https://marketplace.visualstudio.com/items?itemName=ms-pyright.pyright)
|
|
63
|
+
- [Pyrefly](https://marketplace.visualstudio.com/items?itemName=tamasfe.pyrefly)
|
|
64
|
+
- [Prisma](https://marketplace.visualstudio.com/items?itemName=Prisma.prisma)
|
|
65
|
+
- [Tailwind CSS IntelliSense](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss)
|
|
66
|
+
|
|
67
|
+
The Caspian extension is the key piece for Python component snippets and autocomplete.
|
|
68
|
+
|
|
69
|
+
## Start the Development Server
|
|
70
|
+
|
|
71
|
+
After scaffolding, move into the generated project and start the development server:
|
|
72
|
+
|
|
73
|
+
```bash
|
|
74
|
+
cd my-app
|
|
75
|
+
npm run dev
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
## After Setup
|
|
79
|
+
|
|
80
|
+
Once the project is scaffolded:
|
|
81
|
+
|
|
82
|
+
- Read `database.md` when the app includes Prisma ORM support or needs database changes.
|
|
83
|
+
- Read `auth.md` before wiring session config, sign-in or signout routes, route guards, or OAuth providers.
|
|
84
|
+
- Read `pulsepoint.md` before generating interactive frontend behavior.
|
|
85
|
+
- Read `fetch-data.md` before adding browser-triggered reads, writes, uploads, or streams.
|
|
86
|
+
- Read `validation.md` before handling forms, auth input, or RPC payloads.
|
|
87
|
+
- Read `routing.md` to learn how `src/app` folders map to URLs.
|
|
88
|
+
- Read `project-structure.md` to place route code, shared libraries, config, and database files in the correct directories.
|
|
89
|
+
|
|
90
|
+
## AI Routing Notes
|
|
91
|
+
|
|
92
|
+
If an AI agent is reading this page, treat it as the source for new-project installation steps.
|
|
93
|
+
|
|
94
|
+
- Use this workflow when the user is creating a Caspian app from scratch.
|
|
95
|
+
- Do not use existing-project migration or update commands unless the project already exists.
|
|
96
|
+
- After scaffold, default to PulsePoint for interactive UI, RPC for browser-to-server data flow, and `casp.validate` for validation.
|
|
97
|
+
- Once the app exists, check [routing.md](./routing.md) before creating or changing routes under `src/app/`.
|
|
98
|
+
- Check [index.md](./index.md) first when deciding which local doc to follow.
|
|
@@ -0,0 +1,196 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Metadata & SEO
|
|
3
|
+
description: Define static and dynamic metadata in Caspian so titles, descriptions, and social cards inherit correctly from layouts to pages.
|
|
4
|
+
related:
|
|
5
|
+
title: Related docs
|
|
6
|
+
description: Use the routing guide to place layout.py and index.py files correctly, then use the structure guide when deciding where metadata defaults belong.
|
|
7
|
+
links:
|
|
8
|
+
- /docs/routing
|
|
9
|
+
- /docs/project-structure
|
|
10
|
+
- /docs/index
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
This page explains how Caspian handles document metadata, SEO fields, and social sharing tags.
|
|
14
|
+
|
|
15
|
+
At render time, Caspian resolves metadata through the layout engine and exposes the merged result to templates as `[[ metadata.* ]]`.
|
|
16
|
+
|
|
17
|
+
## Overview
|
|
18
|
+
|
|
19
|
+
Caspian uses a cascading metadata model similar to the Next.js App Router. Define defaults high in the tree, then override them closer to the final route.
|
|
20
|
+
|
|
21
|
+
Use the `Metadata` class from `casp.layout` when you need to set:
|
|
22
|
+
|
|
23
|
+
- Page titles
|
|
24
|
+
- Meta descriptions
|
|
25
|
+
- Open Graph tags
|
|
26
|
+
- Twitter card tags
|
|
27
|
+
- Other head metadata through the `extra` dictionary
|
|
28
|
+
|
|
29
|
+
Metadata is typically defined in one of two files:
|
|
30
|
+
|
|
31
|
+
- `layout.py` for defaults shared by everything below that folder
|
|
32
|
+
- `index.py` for route-specific metadata
|
|
33
|
+
|
|
34
|
+
The current `Metadata` implementation supports three fields:
|
|
35
|
+
|
|
36
|
+
- `title`
|
|
37
|
+
- `description`
|
|
38
|
+
- `extra`
|
|
39
|
+
|
|
40
|
+
## Static Definition
|
|
41
|
+
|
|
42
|
+
For metadata that does not depend on route params or fetched data, define a module-level `metadata` variable.
|
|
43
|
+
|
|
44
|
+
Example:
|
|
45
|
+
|
|
46
|
+
```python
|
|
47
|
+
from casp.layout import Metadata, render_page
|
|
48
|
+
|
|
49
|
+
metadata = Metadata(
|
|
50
|
+
title="About Us | My App",
|
|
51
|
+
description="Learn more about our team and mission.",
|
|
52
|
+
extra={
|
|
53
|
+
"og:title": "About Us | My App",
|
|
54
|
+
"og:description": "Learn more about our team and mission.",
|
|
55
|
+
"og:image": "/assets/og-about.jpg",
|
|
56
|
+
"twitter:card": "summary_large_image",
|
|
57
|
+
},
|
|
58
|
+
)
|
|
59
|
+
|
|
60
|
+
async def page():
|
|
61
|
+
return render_page(__file__)
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
Use static metadata for:
|
|
65
|
+
|
|
66
|
+
- Marketing pages
|
|
67
|
+
- Docs pages
|
|
68
|
+
- Any route where the SEO copy is fixed at build or authoring time
|
|
69
|
+
|
|
70
|
+
The explicit `metadata = Metadata(...)` form is the clearest pattern and should be preferred in project code.
|
|
71
|
+
|
|
72
|
+
Implementation note:
|
|
73
|
+
|
|
74
|
+
- If you call `Metadata(...)` at module scope without assigning it, the current layout engine auto-registers that instance as the module's `metadata` value.
|
|
75
|
+
- That shortcut works because `Metadata.__post_init__()` inspects the caller frame and writes to module globals.
|
|
76
|
+
- Prefer the explicit assignment anyway so the intent is obvious to readers and tools.
|
|
77
|
+
|
|
78
|
+
## Dynamic Generation
|
|
79
|
+
|
|
80
|
+
For metadata that depends on a dynamic segment or fetched content, instantiate `Metadata(...)` inside the route function. Runtime metadata overrides the static defaults inherited from layouts.
|
|
81
|
+
|
|
82
|
+
Example:
|
|
83
|
+
|
|
84
|
+
```python
|
|
85
|
+
from casp.layout import Metadata, render_page
|
|
86
|
+
|
|
87
|
+
async def page(slug: str):
|
|
88
|
+
product_name = f"Product {slug.capitalize()}"
|
|
89
|
+
|
|
90
|
+
Metadata(
|
|
91
|
+
title=f"{product_name} | Store",
|
|
92
|
+
description=f"Buy {product_name} at the best price.",
|
|
93
|
+
extra={
|
|
94
|
+
"og:title": f"{product_name} | Store",
|
|
95
|
+
"twitter:title": f"{product_name} | Store",
|
|
96
|
+
},
|
|
97
|
+
)
|
|
98
|
+
|
|
99
|
+
return render_page(__file__, {"name": product_name})
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
Set dynamic metadata before calling `render_page(...)` so the route renders with the correct head values.
|
|
103
|
+
|
|
104
|
+
Inside the same module, runtime `Metadata(...)` overrides matching keys from the module-level static `metadata` object.
|
|
105
|
+
|
|
106
|
+
## How Inheritance Works
|
|
107
|
+
|
|
108
|
+
Caspian merges metadata from the root layout down to the final page. Lower levels override higher levels when they define the same field.
|
|
109
|
+
|
|
110
|
+
Priority order:
|
|
111
|
+
|
|
112
|
+
1. `src/app/layout.py` sets site-wide defaults.
|
|
113
|
+
2. Nested `layout.py` files override those defaults for a section.
|
|
114
|
+
3. `index.py` metadata or runtime `Metadata(...)` inside the route has the highest priority.
|
|
115
|
+
|
|
116
|
+
Within a single file, the layout engine applies static metadata first and then applies runtime metadata from `Metadata(...)`, so runtime values win for matching keys.
|
|
117
|
+
|
|
118
|
+
If a child route overrides only the title, the description and other fields continue to fall through from the nearest parent that defines them.
|
|
119
|
+
|
|
120
|
+
Example structure:
|
|
121
|
+
|
|
122
|
+
```text
|
|
123
|
+
src/
|
|
124
|
+
app/
|
|
125
|
+
layout.py
|
|
126
|
+
blog/
|
|
127
|
+
layout.py
|
|
128
|
+
[slug]/
|
|
129
|
+
index.py
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
Typical result:
|
|
133
|
+
|
|
134
|
+
- Root layout defines the site-wide title template and default description.
|
|
135
|
+
- Blog layout overrides section-level fields for `/blog/*`.
|
|
136
|
+
- Blog page overrides the final post title and any page-specific social tags.
|
|
137
|
+
|
|
138
|
+
## Template Access
|
|
139
|
+
|
|
140
|
+
Resolved metadata is passed into layout rendering as a `metadata` object.
|
|
141
|
+
|
|
142
|
+
Example:
|
|
143
|
+
|
|
144
|
+
```html
|
|
145
|
+
<title>[[ metadata.title ]]</title>
|
|
146
|
+
<meta name="description" content="[[ metadata.description ]]" />
|
|
147
|
+
<meta property="og:image" content="[[ metadata['og:image'] ]]" />
|
|
148
|
+
<meta name="twitter:card" content="[[ metadata['twitter:card'] ]]" />
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
Use bracket access for `extra` keys that contain characters such as `:`.
|
|
152
|
+
|
|
153
|
+
## Social Cards With `extra`
|
|
154
|
+
|
|
155
|
+
Use the `extra` dictionary for Open Graph and Twitter card tags.
|
|
156
|
+
|
|
157
|
+
Common keys include:
|
|
158
|
+
|
|
159
|
+
- `og:title`
|
|
160
|
+
- `og:description`
|
|
161
|
+
- `og:image`
|
|
162
|
+
- `twitter:card`
|
|
163
|
+
- `twitter:title`
|
|
164
|
+
- `twitter:description`
|
|
165
|
+
- `twitter:image`
|
|
166
|
+
|
|
167
|
+
Use stable, publicly reachable image paths for social cards so crawlers can fetch them reliably.
|
|
168
|
+
|
|
169
|
+
## Layout Props vs Metadata
|
|
170
|
+
|
|
171
|
+
Keep visual layout data and SEO metadata separate.
|
|
172
|
+
|
|
173
|
+
- Values returned from `layout()` are exposed as `[[ layout.* ]]`.
|
|
174
|
+
- SEO values are exposed as `[[ metadata.* ]]`.
|
|
175
|
+
- Do not return `title` or `description` from `layout()` expecting SEO changes.
|
|
176
|
+
- The layout engine explicitly strips `title` and `description` from layout props to avoid mixing visual props with metadata.
|
|
177
|
+
|
|
178
|
+
## Where To Put Defaults
|
|
179
|
+
|
|
180
|
+
- Put site-wide defaults in `src/app/layout.py`.
|
|
181
|
+
- Put section defaults in nested `layout.py` files such as `src/app/blog/layout.py`.
|
|
182
|
+
- Put page-specific static metadata in `index.py`.
|
|
183
|
+
- Put dynamic metadata inside `page()` after you have route params or fetched data.
|
|
184
|
+
|
|
185
|
+
## AI Routing Notes
|
|
186
|
+
|
|
187
|
+
If an AI agent is deciding where to put SEO fields, apply these rules first.
|
|
188
|
+
|
|
189
|
+
- Use `Metadata` from `casp.layout` for Caspian metadata.
|
|
190
|
+
- Prefer module-level `metadata = Metadata(...)` for static routes.
|
|
191
|
+
- Instantiate `Metadata(...)` inside `page()` when metadata depends on params, fetched records, or generated content.
|
|
192
|
+
- Put shared defaults in `layout.py` and let leaf pages override only what they need.
|
|
193
|
+
- Use `extra` for Open Graph and Twitter card tags.
|
|
194
|
+
- Access `extra` values in templates with bracket syntax such as `metadata['og:image']`.
|
|
195
|
+
- Keep `layout()` return data in `[[ layout.* ]]` and keep SEO fields in `Metadata(...)`.
|
|
196
|
+
- Check [routing.md](./routing.md) when deciding whether metadata belongs in a layout or a specific route folder.
|
|
@@ -0,0 +1,193 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Project Structure
|
|
3
|
+
description: Understand the default Caspian project layout so AI agents place files in the correct directories before generating PulsePoint templates, RPC actions, validation helpers, auth code, configuration, or database changes.
|
|
4
|
+
related:
|
|
5
|
+
title: Related docs
|
|
6
|
+
description: Start with installation for new apps, then use the auth guide for bootstrap and session wiring, the routing guide to map URLs correctly, and the cache guide when route HTML should be reused safely.
|
|
7
|
+
links:
|
|
8
|
+
- /docs/installation
|
|
9
|
+
- /docs/auth
|
|
10
|
+
- /docs/routing
|
|
11
|
+
- /docs/cache
|
|
12
|
+
- /docs/database
|
|
13
|
+
- /docs/index
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
This page explains the default layout of a Caspian application, where Caspian core files live, and which paths AI agents should treat as project code versus framework internals.
|
|
17
|
+
|
|
18
|
+
## Overview
|
|
19
|
+
|
|
20
|
+
Caspian uses a lean project layout that keeps application code in `src`, database files in `prisma`, static assets in `public`, configuration in `caspian.config.json`, and framework internals in the installed package.
|
|
21
|
+
|
|
22
|
+
In that layout, the default stack is PulsePoint in route templates, RPC for browser-triggered server calls, and `casp.validate` for input validation at route and action boundaries.
|
|
23
|
+
|
|
24
|
+
For public pages that can safely reuse rendered HTML, Caspian also supports route-level page caching through `casp.cache_handler`.
|
|
25
|
+
|
|
26
|
+
## Top-Level Areas
|
|
27
|
+
|
|
28
|
+
- `src/` contains routes, page templates, styles, and shared libraries.
|
|
29
|
+
- `src/lib/auth/auth_config.py` contains auth-specific configuration for the app.
|
|
30
|
+
- `prisma/` contains the Prisma schema and seed scripts.
|
|
31
|
+
- `public/` contains static assets served directly.
|
|
32
|
+
- `main.py` is the application entry point.
|
|
33
|
+
- `caspian.config.json` is the core feature configuration file.
|
|
34
|
+
- `.venv/Lib/site-packages/casp/` contains the installed Caspian framework core.
|
|
35
|
+
- `node_modules/caspian/dist/docs/` contains the packaged Caspian docs.
|
|
36
|
+
|
|
37
|
+
## Example Layout
|
|
38
|
+
|
|
39
|
+
```text
|
|
40
|
+
my-app/
|
|
41
|
+
main.py
|
|
42
|
+
caspian.config.json
|
|
43
|
+
prisma/
|
|
44
|
+
schema.prisma
|
|
45
|
+
seed.ts
|
|
46
|
+
public/
|
|
47
|
+
src/
|
|
48
|
+
app/
|
|
49
|
+
layout.html
|
|
50
|
+
index.py
|
|
51
|
+
index.html
|
|
52
|
+
globals.css
|
|
53
|
+
lib/
|
|
54
|
+
auth/
|
|
55
|
+
auth_config.py
|
|
56
|
+
prisma/
|
|
57
|
+
__init__.py
|
|
58
|
+
db.py
|
|
59
|
+
models.py
|
|
60
|
+
.venv/
|
|
61
|
+
Lib/
|
|
62
|
+
site-packages/
|
|
63
|
+
casp/
|
|
64
|
+
node_modules/
|
|
65
|
+
caspian/
|
|
66
|
+
dist/
|
|
67
|
+
docs/
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
## Directory Breakdown
|
|
71
|
+
|
|
72
|
+
### `src/`
|
|
73
|
+
|
|
74
|
+
This is the main application area. It contains route files, templates, styles, and shared code used across the app.
|
|
75
|
+
|
|
76
|
+
### `src/app/`
|
|
77
|
+
|
|
78
|
+
This directory handles file-based routing. Route templates and route-specific backend logic live here.
|
|
79
|
+
|
|
80
|
+
See `routing.md` for the full App Router-style rules for dynamic segments, route groups, and nested layouts.
|
|
81
|
+
|
|
82
|
+
### `src/lib/`
|
|
83
|
+
|
|
84
|
+
Use this folder for shared helpers, reusable validators, RPC-facing service wrappers, reusable UI utilities, and app-level support code.
|
|
85
|
+
|
|
86
|
+
When Prisma ORM is enabled, this folder also contains the shared database client imports under `src/lib/prisma/`.
|
|
87
|
+
|
|
88
|
+
### `src/lib/prisma/`
|
|
89
|
+
|
|
90
|
+
When a Caspian app includes Prisma support, this folder contains the shared ORM imports used by route code and RPC actions.
|
|
91
|
+
|
|
92
|
+
Typical files include:
|
|
93
|
+
|
|
94
|
+
- `src/lib/prisma/db.py` for the shared Prisma client instance
|
|
95
|
+
- `src/lib/prisma/models.py` for generated Python model types
|
|
96
|
+
- `src/lib/prisma/__init__.py` for package-level re-exports such as `prisma` and `models`
|
|
97
|
+
|
|
98
|
+
See `database.md` for the Prisma-specific workflow, generation step, and usage patterns.
|
|
99
|
+
|
|
100
|
+
### `src/lib/auth/`
|
|
101
|
+
|
|
102
|
+
Use this folder for authentication-specific project code. The main auth configuration file lives at `src/lib/auth/auth_config.py`.
|
|
103
|
+
|
|
104
|
+
### `prisma/`
|
|
105
|
+
|
|
106
|
+
This folder contains your database model definitions in `schema.prisma` and any seed logic such as `seed.ts`.
|
|
107
|
+
|
|
108
|
+
### `public/`
|
|
109
|
+
|
|
110
|
+
Store static assets here, including images, fonts, and generated frontend assets that should be served directly.
|
|
111
|
+
|
|
112
|
+
## Key Files
|
|
113
|
+
|
|
114
|
+
### `main.py`
|
|
115
|
+
|
|
116
|
+
The application entry point for the project.
|
|
117
|
+
|
|
118
|
+
In the current Caspian app shape, this file is where startup wiring happens:
|
|
119
|
+
|
|
120
|
+
- load environment variables
|
|
121
|
+
- call `configure_auth(build_auth_settings())`
|
|
122
|
+
- register OAuth providers with `Auth.set_providers(...)`
|
|
123
|
+
- create the FastAPI app
|
|
124
|
+
- register routes and RPC handlers
|
|
125
|
+
- add `SessionMiddleware`, CSRF middleware, auth middleware, and RPC middleware
|
|
126
|
+
|
|
127
|
+
Use `main.py` for auth bootstrap and middleware-order changes. Use `src/lib/auth/auth_config.py` for auth policy values such as public routes, redirects, and RBAC maps.
|
|
128
|
+
|
|
129
|
+
### `caspian.config.json`
|
|
130
|
+
|
|
131
|
+
The core feature configuration file for the application.
|
|
132
|
+
|
|
133
|
+
### `src/lib/auth/auth_config.py`
|
|
134
|
+
|
|
135
|
+
The project auth configuration file. Use this path when changing authentication behavior.
|
|
136
|
+
|
|
137
|
+
### `src/app/layout.html`
|
|
138
|
+
|
|
139
|
+
The root layout shared across pages.
|
|
140
|
+
|
|
141
|
+
### `src/app/index.py`
|
|
142
|
+
|
|
143
|
+
The backend logic for the route. This is where route behavior can load first-render data, expose `@rpc()` actions, and import framework features such as auth helpers, `casp.validate`, and route-level `Cache(...)` declarations.
|
|
144
|
+
|
|
145
|
+
### `src/app/index.html`
|
|
146
|
+
|
|
147
|
+
The route template. It supports standard HTML, PulsePoint directives, and component imports, and it should be the default place for reactive frontend behavior in Caspian.
|
|
148
|
+
|
|
149
|
+
### `src/app/globals.css`
|
|
150
|
+
|
|
151
|
+
Global application styles.
|
|
152
|
+
|
|
153
|
+
### `.venv/Lib/site-packages/casp/`
|
|
154
|
+
|
|
155
|
+
The installed Caspian framework package. This is framework internals, not normal application code.
|
|
156
|
+
|
|
157
|
+
Notable internal files include:
|
|
158
|
+
|
|
159
|
+
- `.venv/Lib/site-packages/casp/rpc.py` for the RPC decorator and related server-action internals
|
|
160
|
+
- `.venv/Lib/site-packages/casp/layout.py` for layout rendering, metadata handling, and routing-related internals
|
|
161
|
+
- `.venv/Lib/site-packages/casp/cache_handler.py` for route-level cache declarations, cache manifest handling, disk-backed HTML writes, and invalidation internals
|
|
162
|
+
- `.venv/Lib/site-packages/casp/validate.py` for direct validators, rule-based validation, sanitization, and file-validation internals
|
|
163
|
+
|
|
164
|
+
### `node_modules/caspian/dist/docs/`
|
|
165
|
+
|
|
166
|
+
The packaged Caspian documentation location distributed with the framework.
|
|
167
|
+
|
|
168
|
+
## AI Routing Notes
|
|
169
|
+
|
|
170
|
+
If an AI agent is deciding where to make changes, use these rules first.
|
|
171
|
+
|
|
172
|
+
- Put route templates and route-specific backend logic in `src/app/`.
|
|
173
|
+
- Check [routing.md](./routing.md) when you need URL segment rules, layout nesting behavior, or dynamic route conventions.
|
|
174
|
+
- Put shared helpers and reusable libraries in `src/lib/`.
|
|
175
|
+
- Use PulsePoint conventions in route templates for reactive frontend behavior.
|
|
176
|
+
- Use `@rpc()` in route/backend code and `pp.rpc()` in client code for browser-triggered data flows.
|
|
177
|
+
- Use `casp.cache_handler` when a route's first-render HTML should be reused safely across requests.
|
|
178
|
+
- Use `casp.validate` at route and RPC boundaries, and move reusable validators into `src/lib/` when multiple routes share them.
|
|
179
|
+
- Use `database.md` when the task involves Prisma schema changes, generated client usage, or the shared files under `src/lib/prisma/`.
|
|
180
|
+
- Put authentication configuration in `src/lib/auth/auth_config.py`.
|
|
181
|
+
- Put auth bootstrap, session middleware, and provider registration changes in `main.py`.
|
|
182
|
+
- Put database models and seed logic in `prisma/`.
|
|
183
|
+
- Put static files in `public/`.
|
|
184
|
+
- Put entry-point changes in `main.py`.
|
|
185
|
+
- Put feature and framework-level project configuration in `caspian.config.json`.
|
|
186
|
+
- Treat `.venv/Lib/site-packages/casp/` as framework internals unless the task is specifically about Caspian core behavior.
|
|
187
|
+
- Use `.venv/Lib/site-packages/casp/rpc.py` when investigating or documenting Caspian RPC internals.
|
|
188
|
+
- Use `.venv/Lib/site-packages/casp/layout.py` when investigating or documenting Caspian routing, layout, or metadata internals.
|
|
189
|
+
- Use `.venv/Lib/site-packages/casp/cache_handler.py` when investigating or documenting Caspian page-caching internals.
|
|
190
|
+
- Use `.venv/Lib/site-packages/casp/validate.py` when investigating or documenting Caspian validation internals.
|
|
191
|
+
- Look in `node_modules/caspian/dist/docs/` when you need the packaged framework docs.
|
|
192
|
+
|
|
193
|
+
Check [index.md](./index.md) first if you need to choose between local Caspian docs.
|