Dynamic Apps
dynamic_app is the smallest checked dynamic app reference in the repository. Use it after the main Todo List tutorial when you want a compact specimen that shows how Pharos keeps app behavior in declarations while the runtime owns request handling.
What the reference teaches
dynamic_app shows the current dynamic-app profile in a small app root:
- a canonical app manifest in
pharos.app.yml - a declared home page in
templates/home.page.yml - app-owned HTML in
templates/home.body.html - route, action, workflow, integration, migration, and UI contracts under
data/contracts/ - SQLite as the default local persistence backend
- generated JSON artifacts under
dist/apps/dynamic_app/
The central interaction is simple: a browser form posts directly to a declared action. Pharos handles the request route, input handling, mutation behavior, response, and runtime mechanics without requiring an app-written JSON endpoint, client fetch layer, state library, or manual refetch loop.
Build
From the repository root:
pharos build app dynamic_app --build-dir dist
Expected artifact root:
dist/apps/dynamic_app/
Verify
pharos verify app dynamic_app --build-dir dist
Serve
pharos serve app dynamic_app --build-dir dist --port 8788
Open:
http://127.0.0.1:8788/
Open these files first
Read the app in this order:
apps/dynamic_app/pharos.app.ymlapps/dynamic_app/templates/home.page.ymlapps/dynamic_app/templates/home.body.htmlapps/dynamic_app/data/contracts/routes.ymlapps/dynamic_app/data/contracts/actions.ymlapps/dynamic_app/data/contracts/workflows.ymlapps/dynamic_app/data/contracts/integrations.yml
That path moves from app identity, to page structure, to UI, to declared behavior.
What to notice
The YAML files are authoring inputs. The build normalizes them into runtime JSON artifacts, and the native runtime serves the built app. That is the important boundary: the app declares structure and behavior in readable files, while Pharos owns routing, request parsing, rendering semantics, persistence coordination, sessions, jobs, generated surfaces, and operational behavior.
dynamic_app also exercises broader framework capabilities in a small surface area, including typed request hooks, route middleware, derived inputs, defaulted action inputs, scoped updates, reservation/release flows, status transitions, scheduled job effects, HTTP JSON and form delivery, and local audit/file adapters.