3b07d340d5
Second slice of the Welcome surface. Operator-facing
documentation now lives inside Studio as bundled assets and
renders inline via a modal sheet — no browser, no external
link, air-gap-tauglich.
- Four operator-readable explainers under `assets/docs/`,
each with an EN + DE pair:
architecture[_de].md — Hub / Module / Flow + how they fit
security[_de].md — sandbox model, declared perms,
operator ceiling
audit[_de].md — hash-chained log, WORM-1 mechanics,
`fai admin verify-events`
flows[_de].md — flow YAML, templating reference,
extract→summarize example
These are short (≈ 300-500 words each), operator-shaped
prose. Not copies of the architecture docs in
fai_platform/docs/architecture/ — those are
contributor-dense.
- pubspec.yaml declares `assets/docs/` so the markdown ships
inside the Studio binary. Air-gap deployments read them
with no network access.
- New `_DocReaderSheet` modal: 85 %-of-viewport bottom sheet,
drag handle + title bar with the doc icon and close button,
scrollable Markdown body styled to match Studio chrome.
Loads `assets/docs/<slug>_<locale>.md` first, falls back to
the EN file. Locale comes from
`Localizations.localeOf(context)`.
- `_DocsRow` on the Welcome page sits below the trust-posture
deck. Two-column grid on ≥ 640 dp, single column below.
Each card is icon + title + one-line blurb + chevron;
click opens the reader sheet for that slug.
- 12 new ARB keys for the docs section (header, blurb, four
card titles + blurbs, close button, error message).
- 4 new icons reused: `account_tree_outlined` (architecture),
`shield_outlined` (security), `verified_outlined` (audit),
`alt_route_outlined` (flows).
Implements Phase B of `docs/landing-page-design.md`. Phase C
(live getting-started checklist with persistent state) is the
last remaining slice.
Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
2 KiB
Architecture in one paragraph
F∆I has three concepts you'll meet everywhere: Hub, Module, Flow.
The hub is a single Rust binary called fai. It runs as a
gRPC server, loads modules, executes flows, and writes events
to a SQLite database. One binary, no Docker, no message broker,
no cluster. You can run it on a laptop, a Raspberry Pi, or a
locked-down KRITIS server — same artefact every time.
A module is a small WebAssembly component that does one
thing well. Modules are sandboxed: each one declares the
network endpoints, files, and environment variables it needs,
and the hub enforces that list. A module that doesn't ask for
network access can't reach the network. Modules ship as .fai
bundles with a CycloneDX SBOM and a sigstore signature.
A flow is a YAML file with three top-level keys:
inputs:, steps:, outputs:. Steps run in declared order,
each step calls one module, and outputs from one step can feed
inputs of the next. Flows are deterministic — same inputs
produce the same audit trail.
How the pieces fit
Studio ──gRPC──▶ Hub ──loads──▶ Module (WASM)
│
├──executes──▶ Flow (YAML chain of modules)
│
└──writes────▶ Audit log (hash-chained, in
SQLite; WORM-1 by construction)
What you don't need
- No container runtime. The hub doesn't shell out to Docker or Podman. Modules are WASM components loaded in-process.
- No external database. SQLite ships with the hub.
- No background services. One process; restart with
fai daemon restart— see Doctor → Daemon control.
Where to go next in this app
- Store to discover modules and federated MCP / n8n capabilities, install them in one click.
- Flows to run the sample flows that ship with the hub
(e.g.
extract-summarize). - Audit to see every event the hub recorded — the hash-chained log is the platform's source of truth.