ba1a1a4f06
Some checks are pending
Security / Security check (push) Waiting to run
The flow-run dialog showed a single spinner + "running…" label
for the whole run. For multi-step flows the operator had no
way to see *which* step was busy or how close the run was to
finishing.
Replace the spinner with a live step list driven by a
StreamEvents subscription:
✔ extract 0.41s
⏳ summarize
◻ notify
━━━━━━━━━━──── 35%
Mirrors the `fai run` CLI rendering — one shared visual
language across both surfaces. Steps appear in execution
order as the hub emits step.started events; check + duration
on completion; cross + first-line error on failure; pause
icon on approval gates.
Implementation:
- HubService.streamEvents(backfill, types) — new public
stream-facade method that wraps HubClient.streamEvents and
maps proto LoggedEvent → AuditEvent for the rest of Studio.
Subscribed with backfill=0 so the dialog only sees events
from this very run.
- _FlowRunDialogState.initState subscribes BEFORE submitting
the run, so the first step.started never gets lost in the
gRPC handshake gap.
- Two-layer filter on incoming events: same flow name AND
timestamp >= dialog open time. The timestamp gate is what
stops a previous run's tail-end from painting stale rows
if the user re-runs the same saved flow.
- _LiveStep + _LiveStepList — insertion-ordered map renders
rows in runtime execution order (not alphabetical), so
what the operator sees matches what the hub did.
Version 0.51.5 → 0.51.6.
Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
|
||
|---|---|---|
| .forgejo/workflows | ||
| .githooks | ||
| assets/docs | ||
| docs | ||
| lib | ||
| linux | ||
| macos | ||
| test | ||
| tools | ||
| windows | ||
| .gitignore | ||
| .metadata | ||
| .security-allow | ||
| 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_client_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.