The hub copies the reviewer string a client sends straight into decided_by (DecideApproval, ClearEventLog); nothing on the wire ties it to the authenticated caller. Studio filled it from the OS account, so an export read like non-repudiation while being an arbitrary client claim — the legal finding of the 2026-07-26 usertest panel. The real fix is hub-side (derive decided_by from CALLER_IDENTITY); that contract is written down in docs/reviewer-identity.md and needs a hub release. Until then Studio does the one thing it can do honestly and marks its own claim as a claim, inside the record: - data/reviewer_identity.dart is the single place that produces and reads the value; wire() is idempotent, so page and HubService may both normalise. Every write path funnels through HubService, so no surface can send a bare handle. - The inbox states before the decision who will be recorded, what that attribution is worth on this hub (from AuthStatus), and the literal string that lands in decided_by. An unreadable auth policy stays unreadable — never optimistic. - Reading back: a marked value shows its plain name plus an unchecked flag; an unmarked one (legacy row, CLI decision, or a future hub-derived identity) is not classified either way. - The audit wipe seeds the same kind of marked attribution into its chain.reset marker. When the hub starts deriving the value it overwrites the field and the prefix disappears by itself — no Studio release needed. Guards: reviewer_identity_test (the value) and approvals_reviewer_identity_test (every surface that writes or renders it, against the hermetic fake hub). Visual proof for both themes via the dialog-shot harness. Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com> |
||
|---|---|---|
| .forgejo/workflows | ||
| .githooks | ||
| assets | ||
| docs | ||
| integration_test | ||
| lib | ||
| linux | ||
| macos | ||
| test | ||
| tools | ||
| windows | ||
| .gitignore | ||
| .metadata | ||
| .security-allow | ||
| analysis_options.yaml | ||
| CHANGELOG.md | ||
| CLAUDE.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.