1f1e050b42
Post-apply the wizard now renders real Studio actions instead of CLI
text: a start-hub button that polls until the daemon answers,
per-module install buttons (capability-name install via the hub's
store index) with done/progress states, and an open-the-starter-flow
button that navigates to the Flows page. Regulated plans explain in
plain language that modules come from a signed source; the preview
offers 'allow installing from the public store' as one deliberate,
reversible switch that re-assembles the plan (allow_unsigned_modules).
Fresh installs (no config, no setup-plan.yaml) auto-open the wizard
once per run — the wizard IS the onboarding — and it steps back once
a setup exists. The welcome CTA is framed honestly ('get started in
3 questions'), and after the wizard closes the onboarding checklist
remounts, re-probes, and says what the assistant already covered
(profile line from setup-plan.yaml) instead of acting as a second,
disconnected onboarding surface.
Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
|
||
|---|---|---|
| .forgejo/workflows | ||
| .githooks | ||
| assets | ||
| docs | ||
| lib | ||
| linux | ||
| macos | ||
| test | ||
| tools | ||
| windows | ||
| .gitignore | ||
| .metadata | ||
| .security-allow | ||
| analysis_options.yaml | ||
| CHANGELOG.md | ||
| l10n.yaml | ||
| pubspec.lock | ||
| pubspec.yaml | ||
| README.md | ||
Ch∆In Studio
Desktop GUI client for the Ch∆In Platform hub. Tier-2 generic
platform client per docs/architecture/client.md in the
platform repo. Connects to a local or remote chain serve over
gRPC / gRPC-Web.
Status: live product (v0.70+). Every page talks to the hub through
chain_client_sdk; there is no mock data. End users launch Studio viachain studio, which downloads and verifies a prebuilt bundle from the release mirror (sha256 + signature) or rebuilds from source when a dev workspace is configured.
Pages
- Welcome — onboarding checklist, guided setup wizard, bundled documentation reader.
- Store — browse/search/install modules across multiple stores (pinned publisher keys, private sources, AI AskBar); installed modules live here as a filter.
- Flows — graph + text flow editor with a live Run tab
(streamed step events, inline approvals). Editor ships as the
chain_studio_flow_editorpackage. - Audit — live event stream (
StreamEvents) with filters, hash-chain verification, gated log reset. - Approvals — pending
system.approval@^0reviews with approve / reject and payload disclosure. - Doctor — diagnostics, daemon lifecycle, binary recovery.
- Föderation — satellite list, bootstrap-token enrolment, revocation.
Plus: settings dialog (System-AI, integrations/MCP/n8n, security, maintenance), Cmd+K palette, release-channel switcher.
Stack
- Flutter 3.40+ (Desktop: macOS, Linux, Windows)
- gRPC client via
chain_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 # or -d linux / -d windows
flutter test
chain studio prefers a configured dev workspace and will
flutter run from source when one resolves — see
crates/chain_runtime_mgmt in the platform repo.
Repo placement
Published as fai/chain-studio on Forgejo (git.flemming.ai).
The local directory follows the established fai_chain_* 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.