john/prompts
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

reformatted to be more skill-like

Browse Source
This commit is contained in:
John Lancaster
2026-06-16 23:46:05 -05:00
parent c8906cef7b
commit 35a3a8dbed
3 changed files with 241 additions and 321 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/nicegui/SKILL.md
+114 -321
View File
@@ -1,56 +1,61 @@
--- ---
name: nicegui name: nicegui
description: Build and scaffold production-ready NiceGUI + FastAPI app architecture. description: 'Design and scaffold a production-ready NiceGUI + FastAPI application architecture. Use for multi-page app planning, package boundaries, optional DB/LangGraph/docs integration, and implementation checklists.'
argument-hint: 'What should this app include (pages, DB, AI, docs, constraints)?'
--- ---
# NiceGUI # NiceGUI
Build a production-ready, multi-page NiceGUI application that follows modern FastAPI project layout and architecture practices. Design a production-minded NiceGUI + FastAPI architecture with clear boundaries, optional extensions, and a concrete implementation checklist.
## Goal ## When to Use
Create a clean, maintainable app structure where: - You need a reusable architecture plan before implementing a NiceGUI app.
- FastAPI is the underlying ASGI app. - You want FastAPI app-factory structure and lifespan wiring.
- NiceGUI is mounted/initialized in a way that aligns with FastAPI best practices. - You need optional guidance for database, LangGraph workflows, or mounted static docs.
- Each page is implemented as a separate module in `pages/`. - You want output that is concise, structured, and implementation-ready.
- The project is easy to test, extend, and deploy.
## Requirements ## Inputs to Collect
- Prefer Pydantic settings with a `.env` example. Collect these inputs up front. If not provided, make safe defaults and state assumptions.
- Consider adding structured logging configuration.
- Use a `src/`-style layout with clear package boundaries.
- Use an app factory (`create_app`) and avoid global side effects at import time.
- Register NiceGUI pages from modules in `pages/`.
- Keep UI logic in page modules and shared UI helpers/components in a separate package.
- Include at least these pages:
- Home (`/`)
- Dashboard (`/dashboard`)
- About (`/about`)
- Include a health endpoint (`/healthz`) on the FastAPI side.
- Provide minimal test examples for FastAPI routes and page registration.
- Use FastAPI lifespan for startup/shutdown resource management.
## Recommendations - Product scope and primary user journeys.
- Required pages and route map.
- Whether persistent data is required.
- Whether AI orchestration (multi-step, streaming, approvals) is required.
- Whether generated docs should be mounted in-app.
- Runtime/deployment constraints (single service vs split services, environment requirements).
- Consider a shared navigation/header component and left drawer used by all pages. ## Outcome
- Consider including dev tooling basics (formatting/lint/test commands).
- Prefer clear separation of concerns:
- `db/` for engine/session/base/models/repositories (if needed)
- `api/` for HTTP endpoints
- `ui/` for NiceGUI pages/components
- `services/` for business logic
- If you need database access, a solid pattern is to use FastAPI + SQLAlchemy best practices:
- Use one engine per application process (do not create per request).
- Prefer a request-scoped session dependency using `yield`.
- Keep transaction boundaries explicit (commit/rollback) in service/repository flows.
- Avoid sharing a session across concurrent tasks.
- Consider production-minded pool settings (`pool_pre_ping=True` and sensible recycle/timeout values).
- Prefer Alembic for schema migrations.
## Suggested Project Structure Produce:
Base structure (no database required): - A concise architecture explanation.
- How core services, UI pages, and UI components fit together.
- Explicit decision on DB ownership or involvement.
- Explicit decision on AI workflow (or no AI).
- A checklist implementation plan organized by package and domain.
## Procedure
1. Frame the baseline architecture.
2. Choose optional extensions (DB, AI, docs) using decision points below.
3. Map modules, dependencies, and key boundaries.
4. Define key functions/classes and configuration surfaces.
5. Produce phased checklist with rollout or migration notes when relevant.
6. Run completion checks before returning.
### 1) Baseline architecture
Use a src-layout with FastAPI as the ASGI app and NiceGUI registered via composition.
- App factory pattern: `create_app()`.
- Lifespan for startup and shutdown resource management.
- `api/` for HTTP handlers, `services/` for business logic.
- `ui/pages/` for page modules, `ui/components/` for shared UI.
- Health endpoint on FastAPI side: `/healthz`.
Recommended base shape:
```text ```text
. .
@@ -61,6 +66,7 @@ Base structure (no database required):
│ └─ app/ │ └─ app/
│ ├─ __init__.py │ ├─ __init__.py
│ ├─ main.py │ ├─ main.py
│ ├─ bootstrap.py
│ ├─ config.py │ ├─ config.py
│ ├─ logging.py │ ├─ logging.py
│ ├─ api/ │ ├─ api/
@@ -69,319 +75,106 @@ Base structure (no database required):
│ ├─ services/ │ ├─ services/
│ │ ├─ __init__.py │ │ ├─ __init__.py
│ │ └─ example_service.py │ │ └─ example_service.py
│ ├─ ui/ │ └─ ui/
│ │ ├─ __init__.py
│ │ ├─ components/
│ │ │ ├─ __init__.py
│ │ │ └─ nav.py
│ │ └─ pages/
│ │ ├─ __init__.py
│ │ ├─ home.py
│ │ ├─ dashboard.py
│ │ └─ about.py
│ └─ bootstrap.py
└─ tests/
├─ test_health.py
└─ test_pages_registration.py
```
### Conceptual boundaries for the base structure
- `main.py`: application entrypoint only; wires `create_app()` and process startup concerns.
- `bootstrap.py`: app composition layer; owns app factory, router registration, page registration, and lifespan wiring.
- `config.py`: configuration boundary; centralizes settings parsing and typed config objects.
- `logging.py`: observability boundary; centralizes logging format/levels/handlers so modules do not configure logging ad hoc.
- `api/`: transport boundary for HTTP endpoints; validate/shape request-response objects and delegate business work to `services/`.
- `services/`: use-case/business boundary; orchestrates domain behavior and dependencies, independent of UI rendering.
- `ui/pages/`: route-level UI boundary; one module per page, focused on layout/event handling for that page.
- `ui/components/`: reusable presentation boundary; shared UI widgets/composition utilities with no business side effects.
- `tests/`: behavior boundary; verify public behavior (health endpoint, page registration, service outcomes), not private implementation details.
### Dependency direction to keep clear
- Prefer this dependency flow:
- `main/bootstrap` -> `config/logging` + `api` + `ui/pages` + `services`
- `api` -> `services`
- `ui/pages` -> `ui/components` + `services`
- `services` -> pure helpers/clients (and later `db/` if enabled)
- Avoid reverse imports (for example, `services` importing from `ui/pages` or `api`).
- Keep page modules and API handlers as thin adapters; keep business decisions in `services/`.
## Extending This Pattern with a Database (Optional)
If database access is needed, extend with:
```text
.
├─ alembic.ini
├─ alembic/
│ ├─ env.py
│ └─ versions/
├─ src/
│ └─ app/
│ └─ db/
│ ├─ __init__.py │ ├─ __init__.py
│ ├─ base.py │ ├─ components/
│ ├─ session.py
│ ├─ models/
│ │ ├─ __init__.py │ │ ├─ __init__.py
│ │ └─ example.py │ │ └─ nav.py
│ └─ repositories/ │ └─ pages/
│ ├─ __init__.py │ ├─ __init__.py
│ └─ example_repo.py │ ├─ home.py
│ ├─ dashboard.py
│ └─ about.py
└─ tests/ └─ tests/
└─ test_db_session_dependency.py ├─ test_health.py
└─ test_pages_registration.py
``` ```
### Recommended database layering ### 2) Decision points
- Keep `db/` focused on persistence primitives: #### Database needed?
- `session.py`: engine + session factory + dependency helpers
- `models/`: ORM table mappings only
- `repositories/`: query/persistence operations only
- Keep transaction orchestration in `services/`, not in UI pages.
- Keep `ui/pages/` free of SQLAlchemy details; pages call services.
- Keep API handlers thin and delegate data work to services/repositories.
### Session and transaction pattern to request - If no: keep `services/` pure and skip persistence layers.
- If yes: add `db/` package with engine/session/model/repository layering.
- Prefer one process-level engine and request-scoped sessions via `yield`.
- Prefer Alembic migrations for schema changes.
- Use one engine and one sessionmaker per process, initialized at app startup. #### AI workflow needed?
- Use a `get_db_session()` dependency with `yield` for request-scoped sessions.
- In write flows, always use context managers for commit/rollback safety.
- In read-only flows, avoid unnecessary transactions and keep queries narrowly scoped.
- Do not share a session across concurrent tasks; open a new session per task/unit of work.
### Migration and schema workflow - If no: keep `services/` focused on app logic only.
- If yes: add `ai/` package (state, nodes, graph, runtime, contracts).
- Keep graph internals out of `ui/pages/` and API handlers.
- Use stable thread/session IDs for resumable flows.
- Treat Alembic migrations as the source of truth for schema evolution. #### Mounted docs needed?
- Prefer:
- `alembic revision --autogenerate -m "..."`
- review migration script
- `alembic upgrade head`
- Avoid relying on `metadata.create_all()` for production schema management.
- Include a lightweight startup check that logs current migration state (without mutating schema).
### Configuration and runtime concerns - If no: skip docs mounting.
- If yes: mount generated static site under configurable route (default `/docs`).
- Keep docs mounting in composition layer, not page modules.
- Read `DATABASE_URL` from settings (`pydantic-settings`) and keep secrets out of source control. ### 3) Page and component registration
- Configure pool options appropriate for environment (for example: `pool_pre_ping`, timeout/recycle tuning).
- Keep SQL echo/debug logging disabled in production by default.
- Consider a readiness probe (`/readyz`) that verifies DB connectivity when your deployment needs it.
### Testing guidance for DB-enabled projects - Require at minimum page modules for `/`, `/dashboard`, `/about`.
- Prefer explicit registration pattern:
- `ui/pages/__init__.py` exports `register_pages()`.
- Each page module exports `register_page()`.
- Shared shell components (header/nav/drawer) live in `ui/components/`.
- Unit test repositories against a disposable test database. ### 4) Dependency direction rules
- Integration test `get_db_session()` lifecycle and rollback behavior on failures.
- Add migration tests that validate model changes are represented in Alembic revisions.
- Add API/service tests for critical read/write paths (including uniqueness and constraint errors).
- Keep DB tests isolated and deterministic (fresh schema + transactional cleanup per test module/session).
## Extending This Pattern with LangGraph (Optional) Prefer:
If your app needs multi-step AI workflows, tool-calling loops, or human-in-the-loop approvals, a clean extension is to add a dedicated LangGraph domain layer. - `main/bootstrap` -> `config/logging` + `api` + `ui/pages` + `services`
- `api` -> `services`
- `ui/pages` -> `ui/components` + `services`
- `services` -> helpers/clients (and `db/` when enabled)
### Recommended architecture shape Avoid reverse imports from services into API or UI modules.
- Keep LangGraph logic out of `ui/pages/` and out of HTTP route handlers. ### 5) Testing minimums
- Add an `ai/` package (or similar) and keep graph definition, state schema, tools, and orchestration there.
- Call the graph from `services/` so your UI and API both use the same orchestration entry points.
- Continue using FastAPI lifespan for shared resources (models, clients, stores/checkpointers).
### Suggested project extension - Test FastAPI health route behavior.
- Test page registration wiring.
- If DB enabled: session lifecycle and rollback behavior tests.
- If AI enabled: graph happy path and interrupt/resume coverage.
- If docs enabled: mounted docs route returns index page.
```text ### 6) Styling architecture
.
└─ src/
└─ app/
├─ ai/
│ ├─ __init__.py
│ ├─ state.py # TypedDict / Pydantic state schemas + reducers
│ ├─ nodes/
│ │ ├─ __init__.py
│ │ ├─ llm.py
│ │ ├─ tools.py
│ │ └─ review.py # optional interrupt/human-review nodes
│ ├─ graphs/
│ │ ├─ __init__.py
│ │ └─ assistant_graph.py
│ ├─ runtime.py # compile() + checkpointer/store wiring
│ └─ contracts.py # input/output DTOs between services and graph
├─ services/
│ └─ ai_service.py # invoke/stream/resume wrappers
└─ api/
└─ ai.py # optional HTTP endpoints for run/stream/resume
```
### Idiomatic LangGraph practices to request - Keep structure and layout in Python modules using NiceGUI class composition.
- Keep visual polish in shared CSS files, loaded once at startup.
- Prefer semantic reusable classes over ad hoc per-page styling.
- Define explicit graph state schema (`TypedDict` or Pydantic) and use reducers for append/merge behavior where needed. ## Completion Checks
- Compile graphs with persistence primitives appropriate to environment:
- dev/testing: in-memory checkpointer/store
- production: durable checkpointer/store
- Always pass a stable `thread_id` in `configurable` for resumable sessions and conversation continuity.
- For interactive UX, prefer event streaming APIs and project-specific streaming adapters in service code.
- Use `interrupt()` for human approvals/reviews; resume with `Command(resume=...)` using the same `thread_id`.
- Keep interrupt payloads JSON-serializable.
- Place non-idempotent side effects after interrupts (or isolate them in separate nodes), because interrupted nodes re-run from the start.
- If using tools, prefer LangGraph’s `ToolNode` (or an equivalent centralized tool-execution node) for consistent execution/error handling.
- Keep graph nodes deterministic and narrow in scope (single responsibility per node).
- Add observability with LangSmith tracing for graph runs, transitions, and latency debugging.
### Integration guidance for NiceGUI + FastAPI - Uses app factory and FastAPI lifespan.
- Pages are modularized (not single-file UI).
- Health endpoint exists on FastAPI side.
- Dependency direction is clean and one-way.
- Optional DB/AI/docs decisions are explicit and reflected in structure.
- Output includes architecture summary and package-organized checklist.
- UI pages should call `ai_service` methods, not graph internals. ## Output Contract
- If the UX needs live token/progress updates, expose streaming from service -> UI in a transport-appropriate way.
- For approval workflows, surface interrupt payloads in UI, collect user response, then resume via service with `Command(resume=...)`.
- Keep graph invocation boundaries typed (request/response contracts) so changes in graph internals do not leak into page modules.
### Testing recommendations for LangGraph additions
- Unit test node functions as pure transformations where possible.
- Integration test graph routes (happy path, tool path, interrupt/resume path).
- Add tests ensuring `thread_id` reuse resumes correctly and new IDs start fresh sessions.
- Add regression tests for state-schema evolution and serialization compatibility.
## Extending This Pattern with a Static Docs Site via Zensical (Optional)
If the app should also host a static documentation site, mount the generated docs output directory under a configurable route (default: `/docs`).
### Recommended docs workflow
- Initialize docs in the project root:
- `uv run zensical new .`
- Keep source markdown in Zensical's `docs_dir` (default: `docs/`).
- Build docs as part of release or startup pipeline:
- `uv run zensical build`
- Serve the generated static output from Zensical's `site_dir` (default: `site/`).
### Config to include in app settings
- `docs_enabled: bool = true`
- `docs_mount_path: str = "/docs"`
- `docs_site_dir: str = "site"`
- Optional for local/dev convenience:
- `docs_require_build: bool = false` (if true, fail startup when `site/` is missing)
### FastAPI/NiceGUI integration pattern
- Keep docs mounting in the app composition layer (`bootstrap.py`), not in page modules.
- Use FastAPI static serving to mount the built directory (for example via `StaticFiles(..., html=True)`).
- Ensure `docs_mount_path` is normalized (leading slash, no trailing slash) and does not conflict with app/API routes.
- If docs are disabled or build artifacts are missing, log a clear warning and continue (unless `docs_require_build=true`).
### Suggested project additions
```text
.
├─ zensical.toml
├─ docs/
│ ├─ index.md
│ └─ ...
├─ site/ # generated by `uv run zensical build`
└─ src/
└─ app/
├─ config.py # docs_enabled/docs_mount_path/docs_site_dir
└─ bootstrap.py # mount static docs route
```
### Deployment notes for docs mounting
- In CI/CD, run `uv run zensical build` before packaging/deploying the app image.
- If `project.site_dir` in `zensical.toml` is changed, keep `docs_site_dir` in app settings aligned.
- If hosting behind a reverse proxy with a path prefix, verify docs links and static assets with the final external base path.
- Add a test asserting requests to `docs_mount_path` return the built index page when docs are enabled.
## Implementation Notes
- Prefer an explicit page registration function pattern, for example:
- `register_pages()` in `ui/pages/__init__.py`
- Each page module exports `register_page()`
- Keep imports one-way to avoid circular dependencies.
- Keep page modules cohesive: route declaration + page layout for that route.
- Prefer FastAPI lifespan hooks where appropriate for startup/shutdown behavior.
- Prefer type hints throughout.
### Styling architecture notes
- Prefer class-first UI composition for structure and layout using normal NiceGUI mechanics (`.classes(...)` on containers/components).
- Keep structural concerns in Python page/component modules (layout grids, spacing systems, responsive breakpoints, alignment).
- Keep cosmetic concerns in static CSS files (colors, gradients, shadows, border polish, typography fine-tuning, transitions).
- Avoid large inline `style(...)` strings except for one-off dynamic values that must be computed at runtime.
- Centralize CSS entrypoints in a small, predictable set (for example `ui/static/css/base.css`, `ui/static/css/theme.css`, `ui/static/css/components.css`).
- Include CSS once at app bootstrap/startup so pages share the same style contract; avoid per-page ad hoc includes.
- Prefer semantic class names for reusable patterns (`app-shell`, `page-section`, `card-surface`) and utility classes only for local layout tweaks.
- If using design tokens, define them as CSS custom properties in `:root` and reference them from component classes.
- Keep page modules focused on structure and behavior; reusable visual patterns should live in shared UI components plus shared CSS.
### Database-specific notes (only if your app needs a DB)
- Prefer settings via `pydantic-settings` and read `DATABASE_URL` from environment/dotenv.
- Configure the SQLAlchemy engine once at app setup level; avoid creating engine/sessionmaker in endpoint functions.
- Provide `get_db_session()` via `yield` so sessions are consistently closed.
- Prefer a repository/service boundary to keep SQL details out of page modules.
- Prefer Alembic for schema changes and include commands for `revision --autogenerate` and `upgrade head`.
- Avoid `metadata.create_all()` in production startup flow; reserve it for optional local/dev bootstrap paths.
- Consider a light DB readiness check in health reporting (or a dedicated `/readyz`) when relevant.
- Ensure logs do not leak secrets (for example, avoid unsafe SQL echo in production).
## Output Format
The goal of the output is to produce an output
Return: Return:
- A concise, high-level architecture explanation.
- An explanation of how the different parts of the concept will fit into this structure - Concise high-level architecture.
- What are the core services? - How core services, pages, and shared components fit.
- What are the main ui pages? - DB involvement and ownership stance.
- What are the main ui components? - AI workflow stance and runtime flow.
- Whether a database will be involved and whether the app owns the database - Checklist plan by package and domain:
- Whether any AI will be used and what the workflow looks like - key functions/classes
- A concrete implementation plan in the form of a checklist, organized into sections by concept which should roughly mirror the structure of sub-packages. - settings/config surfaces
- Key functions/classes - rollout/migration notes (when relevant)
- Configuration/settings available
- Migration or rollout notes (if relevant)
## Guardrails ## Guardrails
- Do not put all pages in a single file. - Do not collapse all pages into one file.
- Never use globals, implicit or otherwise. - Do not use globals or implicit global side effects.
- Keep code minimal but production-minded. - Keep code minimal but production-minded.
- Being clear and concise is a higher priority than being verbose.
- Prefer clarity and maintainability over clever abstractions. - Prefer clarity and maintainability over clever abstractions.
## Source Documentation (recommended references) ## References
- FastAPI lifespan events: - Architecture and integration details: [NiceGUI architecture reference](./references/architecture.md)
- https://fastapi.tiangolo.com/advanced/events/ - Source documentation links: [NiceGUI source documentation](./references/source-documentation.md)
- FastAPI settings and environment variables:
- https://fastapi.tiangolo.com/advanced/settings/
- FastAPI dependencies with `yield` (session lifecycle pattern):
- https://fastapi.tiangolo.com/tutorial/dependencies/dependencies-with-yield/
- FastAPI SQL databases tutorial (when using a DB):
- https://fastapi.tiangolo.com/tutorial/sql-databases/
- SQLAlchemy engine configuration and pooling (when using a DB):
- https://docs.sqlalchemy.org/en/20/core/engines.html
- SQLAlchemy session basics and lifecycle guidance (when using a DB):
- https://docs.sqlalchemy.org/en/20/orm/session_basics.html
- Alembic tutorial and migration environment (when using a DB):
- https://alembic.sqlalchemy.org/en/latest/tutorial.html
- Pydantic settings management:
- https://pydantic.dev/docs/validation/latest/concepts/pydantic_settings/
- NiceGUI pages/routing and FastAPI integration:
- https://www.nicegui.io/documentation/section_pages_routing
- NiceGUI security best practices:
- https://www.nicegui.io/documentation/section_security
- LangGraph overview:
- https://docs.langchain.com/oss/python/langgraph/overview
- LangGraph quickstart:
- https://docs.langchain.com/oss/python/langgraph/quickstart
- LangGraph workflows and agents:
- https://docs.langchain.com/oss/python/langgraph/workflows-agents
- LangGraph persistence (checkpointer vs store):
- https://docs.langchain.com/oss/python/langgraph/persistence
- LangGraph memory concepts:
- https://docs.langchain.com/oss/python/concepts/memory
- LangGraph streaming:
- https://docs.langchain.com/oss/python/langgraph/streaming
- LangGraph interrupts / human-in-the-loop:
- https://docs.langchain.com/oss/python/langgraph/interrupts
skills/nicegui/references/architecture.md
+92
View File
@@ -0,0 +1,92 @@
# NiceGUI Architecture Reference
This reference expands the workflow in the main skill file and is loaded only when needed.
## Baseline package boundaries
- `main.py`: process entrypoint only.
- `bootstrap.py`: app composition, router wiring, page registration, lifespan orchestration.
- `config.py`: typed settings and env parsing.
- `logging.py`: centralized logging setup.
- `api/`: HTTP transport layer; delegates to services.
- `services/`: business/use-case logic.
- `ui/pages/`: route-level NiceGUI pages.
- `ui/components/`: shared UI building blocks.
## Required baseline behavior
- FastAPI is the base ASGI app.
- NiceGUI pages are modular and registered from page modules.
- Minimum pages: `/`, `/dashboard`, `/about`.
- FastAPI health route: `/healthz`.
- Lifespan handles startup/shutdown resources.
- No global side effects at import time.
## Optional extension: Database
Use only if persistence is required.
Suggested additions:
```text
src/app/db/
├─ __init__.py
├─ base.py
├─ session.py
├─ models/
└─ repositories/
```
Guidelines:
- One engine and one sessionmaker per process.
- Request-scoped session dependency using `yield`.
- Explicit transaction boundaries in service/repository flows.
- Avoid shared sessions across concurrent tasks.
- Use Alembic as schema source of truth.
## Optional extension: LangGraph AI
Use only for multi-step AI orchestration or human-in-the-loop workflows.
Suggested additions:
```text
src/app/ai/
├─ state.py
├─ nodes/
├─ graphs/
├─ runtime.py
└─ contracts.py
```
Guidelines:
- Keep graph internals outside API/UI modules.
- Invoke graph through `services/ai_service.py`.
- Use stable thread/session IDs for resumable sessions.
- Keep interrupt payloads JSON-serializable.
## Optional extension: Mounted static docs
Use only when generated docs should be served in-app.
Suggested settings:
- `docs_enabled`
- `docs_mount_path`
- `docs_site_dir`
- `docs_require_build` (optional)
Guidelines:
- Mount docs in composition layer (`bootstrap.py`).
- Normalize mount path and avoid route conflicts.
- Warn on missing build artifacts unless strict mode is enabled.
## Suggested output quality criteria
- Clear architecture summary with assumptions.
- Explicit decisions for DB, AI, and docs.
- Package-scoped implementation checklist.
- Minimal test plan aligned to enabled features.
skills/nicegui/references/source-documentation.md
+35
View File
@@ -0,0 +1,35 @@
# Source Documentation
Use these links for framework-specific details.
## FastAPI
- FastAPI lifespan events: https://fastapi.tiangolo.com/advanced/events/
- FastAPI settings and environment variables: https://fastapi.tiangolo.com/advanced/settings/
- FastAPI dependencies with yield: https://fastapi.tiangolo.com/tutorial/dependencies/dependencies-with-yield/
- FastAPI SQL databases tutorial: https://fastapi.tiangolo.com/tutorial/sql-databases/
## SQLAlchemy and Alembic
- SQLAlchemy engine configuration and pooling: https://docs.sqlalchemy.org/en/20/core/engines.html
- SQLAlchemy session lifecycle basics: https://docs.sqlalchemy.org/en/20/orm/session_basics.html
- Alembic tutorial: https://alembic.sqlalchemy.org/en/latest/tutorial.html
## Pydantic
- Pydantic settings management: https://pydantic.dev/docs/validation/latest/concepts/pydantic_settings/
## NiceGUI
- NiceGUI pages/routing and FastAPI integration: https://www.nicegui.io/documentation/section_pages_routing
- NiceGUI security best practices: https://www.nicegui.io/documentation/section_security
## LangGraph
- LangGraph overview: https://docs.langchain.com/oss/python/langgraph/overview
- LangGraph quickstart: https://docs.langchain.com/oss/python/langgraph/quickstart
- LangGraph workflows and agents: https://docs.langchain.com/oss/python/langgraph/workflows-agents
- LangGraph persistence: https://docs.langchain.com/oss/python/langgraph/persistence
- LangGraph memory concepts: https://docs.langchain.com/oss/python/concepts/memory
- LangGraph streaming: https://docs.langchain.com/oss/python/langgraph/streaming
- LangGraph interrupts and human-in-the-loop: https://docs.langchain.com/oss/python/langgraph/interrupts