[P1][Android Plugins] Implement plugin catalog, permissions, configuration, and health surface #315

New issue

Open

opened 2026-09-08 02:03:31 +00:00 by nsaspy · 1 comment

nsaspy commented

2026-09-08 02:03:31 +00:00

Owner

Parent: #648
Depends on: #650
Design freeze: PR #649

Goal

Implement Plugins as a first-class Zara Android surface for the actual plugin/tool ecosystem. Zara owns the product UX and proves the contract first.

Required Zara behavior

installed/discovered plugin catalog;
local vs remote source;
enabled/disabled state;
capability and permission summary;
safe configuration entry point where supported;
health/readiness/degraded/error state;
plugin-provided tools/features discoverable without dumping raw internal schemas;
explicit unavailable state when a provider/runtime is missing;
bounded diagnostics with secret redaction.

Architecture

Do not create an Android-only plugin loader or second capability/authority model. Project the canonical Zara plugin/runtime state through a typed UI model.

Availability, visibility, enabled state, capability possession and execution authority remain distinct.

Zara-first reuse rule

If the implementation reveals reusable domain-neutral plugin metadata/catalog/status primitives, implement and test them in Zara first. Then open a focused Prolog-RLM extraction issue linking this issue, the Zara implementation and conformance fixtures. Upstream may own generic symbolic catalog/selection metadata; Android screens and Zara plugin policy stay here.

RED-first tests

local/remote plugin classification;
enabled/disabled/unavailable/degraded states;
capability summary does not imply authority;
config secrets never render in list/diagnostics;
plugin removal/unavailability updates UI without stale usable actions;
principal/tool permission boundaries remain enforced;
malformed plugin metadata fails structurally;
large plugin catalogs are bounded/searchable.

Screenshot evidence

installed plugin list;
plugin details/capabilities;
disabled/unavailable plugin;
degraded/error plugin;
empty plugin state.

Acceptance

Plugins is backed by real Zara plugin/runtime state;
no second loader/capability/authority system exists;
configuration and health state are useful without exposing secrets;
local/remote and enabled/authority distinctions are explicit;
any generic Prolog-RLM follow-up points back to executable Zara behavior/tests;
deterministic screenshots and Android/Core exact-head gates are green.

Parent: #648 Depends on: #650 Design freeze: PR #649 ## Goal Implement Plugins as a first-class Zara Android surface for the actual plugin/tool ecosystem. Zara owns the product UX and proves the contract first. ## Required Zara behavior - installed/discovered plugin catalog; - local vs remote source; - enabled/disabled state; - capability and permission summary; - safe configuration entry point where supported; - health/readiness/degraded/error state; - plugin-provided tools/features discoverable without dumping raw internal schemas; - explicit unavailable state when a provider/runtime is missing; - bounded diagnostics with secret redaction. ## Architecture Do not create an Android-only plugin loader or second capability/authority model. Project the canonical Zara plugin/runtime state through a typed UI model. Availability, visibility, enabled state, capability possession and execution authority remain distinct. ## Zara-first reuse rule If the implementation reveals reusable domain-neutral plugin metadata/catalog/status primitives, implement and test them in Zara first. Then open a focused Prolog-RLM extraction issue linking this issue, the Zara implementation and conformance fixtures. Upstream may own generic symbolic catalog/selection metadata; Android screens and Zara plugin policy stay here. ## RED-first tests - local/remote plugin classification; - enabled/disabled/unavailable/degraded states; - capability summary does not imply authority; - config secrets never render in list/diagnostics; - plugin removal/unavailability updates UI without stale usable actions; - principal/tool permission boundaries remain enforced; - malformed plugin metadata fails structurally; - large plugin catalogs are bounded/searchable. ## Screenshot evidence - installed plugin list; - plugin details/capabilities; - disabled/unavailable plugin; - degraded/error plugin; - empty plugin state. ## Acceptance - [ ] Plugins is backed by real Zara plugin/runtime state; - [ ] no second loader/capability/authority system exists; - [ ] configuration and health state are useful without exposing secrets; - [ ] local/remote and enabled/authority distinctions are explicit; - [ ] any generic Prolog-RLM follow-up points back to executable Zara behavior/tests; - [ ] deterministic screenshots and Android/Core exact-head gates are green.

nsaspy commented

2026-09-08 02:16:17 +00:00

Author

Owner

Reuse follow-up

Prolog-RLM extraction issue: lost-rob0t/prolog-rlm#416.

#416 is intentionally blocked on this Zara implementation. When this issue produces the catalog/status adapter plus redaction/authority fixtures, link those exact artifacts there and extract the generic seam. Zara keeps plugin UX/product policy.

### Reuse follow-up Prolog-RLM extraction issue: `lost-rob0t/prolog-rlm#416`. #416 is intentionally **blocked on this Zara implementation**. When this issue produces the catalog/status adapter plus redaction/authority fixtures, link those exact artifacts there and extract the generic seam. Zara keeps plugin UX/product policy.