Directory structure
Understand the files in a scaffolded application and how modules grow.
The application scaffold#
Installation creates a small, explicit application rather than a hidden runtime convention.
| File or directory | Responsibility |
|---|---|
ket.workspace.ts |
Application composition and selected deployments. |
modules/ |
Module declarations: models, functions, routes and other owned contracts. |
test/ |
Deployment behavior exercised through the public testing API. |
tools/dev.mjs |
Development process and rebuild lifecycle. |
package.json |
Released dependencies and application commands. |
tsconfig.json |
TypeScript/TSX compilation to executable artifacts. |
The initial scaffold is intentionally small. Separate a growing module's functions, routes and views into its own files while keeping one explicit public module declaration.
Source and production artifacts#
Author TypeScript or TSX; deploy emitted JavaScript. A module catalogue descriptor names a real executable artifact in production. Source loaders belong to development. Read Module discovery and Deployment before packaging a catalogue.
Ownership boundaries#
A module owns its models and behavior. Dependencies expose contracts that other modules may extend. A deployment selects the complete module composition. File organization does not bypass extension rules or declared function effects.
View-only projects#
A static site has pages, island entries, styles, static assets and ket-view.config.ts. A Markdown adapter belongs to the site's content layer; its view stays pure. See Static sites and the runnable example.