mptyl/ThothII
1
0
Fork 0
Code Issues 25 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs: reconcile catalog run history and fleet state

Browse Source
This commit is contained in:
Codex
2026-08-31 15:59:26 +02:00
parent ded66fde9c
commit b4b97436e1
7 changed files with 106 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture/components.md
+26
View File
@@ -67,6 +67,26 @@ sequenceDiagram
The backend uses `ThtRunner` for CLI subprocesses, `PiProcessManager` for one Pi process per session, `SessionBridge` to adapt RPC events, and `SseHub` to distribute them to clients.
## Database Management frontend
`AppShell` mounts Fleet Ledger as the default Database Management presentation. The controller keeps
the existing React Query, AG Grid, permission, dirty-state, synchronization, SSE, and polling
contracts; Fleet Ledger changes the information architecture without introducing a second catalog
client. It shows exactly one grid at a time along the database → table → column hierarchy, with
relationships as a sibling database view. An emphasized back control and breadcrumb move to the
parent view.
Selected-row operations are exposed through a single action selector and explicit **Run** control.
Row-specific actions remain icon controls in the pinned final column. Configuration, metadata
editing, synchronization, description generation, and sensitive-field review/history use the real
catalog state and open in right-side drawers. A drawer can close independently of a durable run.
The KPI strip calls `GET /catalog/metrics`: omitting `databaseId` returns installation-wide catalog
aggregates, while supplying it scopes the same aggregate contract to the selected database. The
previous renderer is reachable only as a temporary development/staging comparison with
`?db-ui=legacy` when Vite development or `VITE_DB_MANAGEMENT_LEGACY=true` enables it. The standalone
prototype on port `5173` remains outside `AppShell` only until the integrated surface is accepted.
## Catalog description generation
Catalog description generation is a backend-owned administrative operation, separate from the
@@ -83,6 +103,12 @@ or second orchestration subsystem. A target receives at most one provider retry;
exhausted technical batches fail the run. Stale work is marked interrupted at startup and must be
explicitly unlocked; it never resumes automatically.
Sensitive-field suggestion generation remains a synchronous administrative request, but each
attempt has its own durable run and ordered sanitized events. This history is separate from
Description Generation because its lifecycle and counters differ. Only execution metadata and
aggregate counts are stored; proposed flags, prompts, raw model output, and provider diagnostics
remain transient.
## Main backend classes
The diagram shows the classes that form the bridge between the browser, Pi, and `tht`. Fastify routes receive requests and delegate to these services.