Final slice of the Welcome surface. Four steps that prove
the operator has the basic loop wired up; each step is
a live probe against the running hub, no manual ticks.
The four checked signals:
1. System AI configured
→ `HubService.systemAiStatus().enabled`
2. Public capability source added
→ `listMcpClients()` returns at least one entry
3. Text module installed
→ `listModules()` contains a name starting with `text.`
4. Saved flow run
→ any `flow.completed` event in the last 100 audit
events
All four probes fire in parallel from `_OnboardingChecklist`'s
`_refresh()`. Failures stay false (catchError) so a hub that
is briefly unreachable doesn't blank the whole row — the
operator hits the explicit Refresh icon to retry.
UX:
- Renders between hero and pillars so the actionable path
beats the educational content for screen real estate.
- Each row: status icon (○ pending / ✓ done) + title +
one-line hint pointing the operator at the right Studio
surface + status pill.
- Done rows strike-through the title and dim it; pending
rows stay full-strength.
- When all four flip to done, an "All four steps complete"
footer appears with a `Hide checklist` button. Clicking
persists `welcome.checklist.dismissed = true` via
SharedPreferences; the section is gone for good (we don't
re-nag operators who chose a non-default path).
15 new ARB keys for the section header, body, four rows
plus done/pending pills, all-done footer, dismiss /
refresh / refreshing button labels.
Three-phase plan from `docs/landing-page-design.md` is now
fully shipped: Phase A scaffolding (v0.37.0), Phase B
embedded doc reader (v0.38.0), Phase C live checklist
(v0.39.0).
Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
|
||
|---|---|---|
| assets/docs | ||
| docs | ||
| lib | ||
| linux | ||
| macos | ||
| test | ||
| tools/today | ||
| windows | ||
| .gitignore | ||
| .metadata | ||
| analysis_options.yaml | ||
| l10n.yaml | ||
| pubspec.lock | ||
| pubspec.yaml | ||
| README.md | ||
F∆I Studio
Desktop GUI client for the F∆I Platform hub. Tier-2 generic
platform client per docs/architecture/client.md. Connects to a
local or remote fai serve over gRPC.
Status (2026-05-05): MVP scaffold. Three pages with mock data, no live gRPC connection yet. Validates the visual direction before the Dart SDK is wired in.
Pages (MVP scope)
- Modules — installed modules, capabilities, declared permissions. Click → manifest detail.
- Audit — live stream of hub events (when wired). Filter by event type and flow.
- Approvals — pending
system.approval@^0reviews with approve / reject buttons.
These three cover the platform's central properties: composition (modules), audit (events), human-in-the-loop (approvals).
Stack
- Flutter 3.40+ (Desktop: macOS, Linux, Windows)
- gRPC client via
fai_dart_sdk(sibling repo; pinned by relative path during development) - No external runtime dependencies; bundles its own Dart VM
Run locally
flutter run -d macos
Repo placement
Will be published as fai/studio on Forgejo (git.flemming.ws).
The local directory fai_studio/ follows the established
fai_platform/ layout convention.
Why "Studio" and not "Stage"
"Stage" collided too easily with "staging environment" in
developer English. "Studio" is the established industry pattern
for creator-tools (Visual Studio, Android Studio, RStudio) and
matches the GUI's audience of module developers, operators, and
power users. The rename was applied across all docs/ in the
platform repo on 2026-05-05.