1903babc5a
Some checks failed
Security / Security check (push) Failing after 2s
Two operator surfaces shipped together:
**Multi-version uninstall picker** — when more than one version
of a `(provider, name)` is installed side-by-side, both the
module-sheet "Uninstall" affordance and the store-detail
"Uninstall" affordance now ask the operator which version to
remove before calling the RPC. The hub's wire-level support for
this (UninstallModuleRequest.version) was already there; Studio
just wasn't using it. Picker pre-selects the highest version so
single-version flows still take one click.
- `HubService.installedVersions(name)` enumerates the installed
versions via the capabilities list.
- `HubService.uninstallModule(name, version: ...)` forwards
the version into the RPC.
- `_UninstallVersionPickerDialog` (module sheet) and
`_StoreUninstallVersionPickerDialog` (store) host the
picker — separate widgets so each surface can evolve copy
independently. Uses `RadioGroup<String>` for Flutter
3.32+ deprecation compliance.
**Default scope editor** — new DEFAULT SCOPE panel in Settings
that calls the freshly-added HubAdmin RPCs
`GetDefaultScope` / `SetDefaultScope`. Operators can:
- reorder publisher segments with up/down buttons
(first match wins in the bare-form resolver),
- delete entries (hub still rejects empty list — Studio
surfaces the constraint inline),
- add arbitrary entries via the text field,
- add catalog-known publishers via suggestion chips
(sorted alphabetically, populated from the catalog).
Every change persists to `~/.fai/config.yaml` via the hub
and hot-swaps the in-memory copy without a daemon restart.
Bumped pubspec to 0.48.0. dart analyze clean (No issues
found!); flutter test green (11 tests).
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.