Commit graph

4 commits

Author SHA1 Message Date
flemming-it
351c5a82bc feat(store): show module maintainers (0.79.0)
Some checks failed
Security / Security check (push) Failing after 2s
The detail sheet always answers 'who maintains this?': one
selectable line per maintainer from the store index's new
maintainers list, or an honest 'not specified' when the index
names nobody (StoreMaintainersSection, public for the widget
tests). The install trust gate carries the same fact when
present and stays terse otherwise. DE+EN; dialog-harness proof
captured with the maintainer row.

Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
2026-07-22 22:06:18 +02:00
flemming-it
08227410e6 fix(flows): only offer install for capabilities the store resolves
Some checks are pending
Security / Security check (push) Waiting to run
The capability set behind the flow editor's Install quick-fix and
the flow list's install badge ingested every store entry's
requiresCapabilities (dependencies, not provided capabilities) and
ignored entry status/kind. Clicking Install on such a capability
ended in the hub's "no store entry for '<name>'" error.

The set now mirrors the hub's install resolver (entry names only,
no planned or federated entries) via installableStoreCapabilities()
with unit tests for both classification states. Unresolvable
capabilities render the editor's 'not in store' state, which
explains the three recovery paths before any click; the editor pin
moves to 0.25.0 (commit-pinned until its tag exists) and the dialog
harness captures the badge states light+dark. Studio 0.78.0.

Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
2026-07-22 13:46:08 +02:00
flemming-it
2f076ccf29 feat(store,doctor): surface the hub's trust + exposure data (0.77.0)
Some checks failed
Security / Security check (push) Failing after 1s
The trust-gate dialog replaces its generic 'no per-entry status yet
(alpha)' note with the hub's classified verification statement —
pinned store key / trusted publishers (green), installs without
signature checking (amber), install would be refused (red), bridge
entry (neutral) — via one shared describeInstallVerification mapping.
Against a pre-0.23 hub the field is empty and the old honest wording
stays (pinned by test).

Information architecture: policy-off is a GLOBAL fact, so it appears
as ONE ChainInlineHelp notice above the store grid instead of a
warning pill on every card (card noise); only 'blocked' — a genuine
per-source anomaly — earns a card pill. Doctor's host services show
the hub-classified network reach per endpoint (local only / private
network / publicly reachable with a protect-it hint / reach unknown).

Verified end-to-end against the live dev hub (guide harness): the
wire field arrives, the store page shows exactly one policy notice
and quiet cards; trust-gate variants captured via the dialog
harness. Suite 123 green.

Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
2026-07-21 13:14:13 +02:00
flemming-it
87afa4dc05 feat(docs): in-place help pattern — explain a surface where it happens
Some checks failed
Security / Security check (push) Failing after 2s
New ChainInlineHelp (intro strip: what this is + what will happen, with
an optional 'Learn more' into the doc sheet) and ChainFieldHelp /
ChainFieldLabel (a '?' affordance per field). First applied to the
add-satellite dialog, which asked for a bare 'name' with no hint of
what a satellite is or does (usertest): it now leads with a plain
explanation + a federation 'Learn more', and the name field carries a
'?'. Both widgets are quiet by design.

Verified: field_help_test covers the widgets + that the dialog explains
itself; dialog_shots_test.dart (a reusable headed dialog-capture
harness) proved the layout in light + dark. Studio 0.76.0.

Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
2026-07-20 02:00:56 +02:00