[Zara reuse][BLOCKED] Extract generic plugin catalog/status projection from Zara #382

New issue

Open

opened 2026-09-08 01:29:17 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-08 01:29:17 +00:00

Owner

Downstream proving ground: lost-rob0t/zara#655
Design/architecture epic: lost-rob0t/zara#648
Design freeze: lost-rob0t/zara#649

Why this exists

Zara Android is implementing a real Plugins surface over installed/discovered local and remote plugins, enabled state, capability/permission summary, safe configuration entry points and health/degraded state.

Zara implements and proves this first. This issue is a later extraction/reuse task, not permission to design a parallel plugin loader or capability system in Prolog-RLM.

prolog_agent_ui_v1 already has generic tool rendering semantics, but it does not currently define a reusable frontend-safe plugin/catalog projection for plugin identity, source, health and configuration metadata. If Zara #655 proves that seam is domain-neutral, extract it here.

Extraction target after Zara proves it

Potential generic data includes:

stable plugin/provider identity;
local/remote/source metadata;
discovered/installed/enabled/disabled/unavailable/degraded states;
tool/capability summaries without implying execution authority;
safe non-secret configuration schema metadata;
health/readiness summaries;
bounded structured failures;
extension/facade integration with the existing frontend protocol.

Do not freeze exact fields here before the Zara fixtures exist.

Required linkage before implementation starts

A worker must first link:

Zara #655 implementation PR/commit;
concrete Zara projection types/adapter;
RED-first tests/fixtures, including secret redaction and authority separation;
a Zara-specific vs generic seam table.

If those links are absent, leave this blocked and implement Zara #655 instead.

Invariants

no second plugin loader/runtime;
tool/schema visibility != capability possession != enabled state != execution authority;
secrets/private config never enter frontend-safe snapshots;
malformed plugin metadata fails structurally;
catalog snapshots remain bounded;
Android/UI/theme/product policy stays downstream.

Acceptance

Zara #655 executable behavior/tests are linked first;
extraction reuses existing tool/capability/authority architecture;
deterministic conformance fixture covers catalog/status/redaction states;
UI protocol compatibility/versioning is explicit;
Zara can replace its generic adapter portion with the extracted contract;
no Zara-specific product policy moves upstream.

Downstream proving ground: `lost-rob0t/zara#655` Design/architecture epic: `lost-rob0t/zara#648` Design freeze: `lost-rob0t/zara#649` ## Why this exists Zara Android is implementing a real Plugins surface over installed/discovered local and remote plugins, enabled state, capability/permission summary, safe configuration entry points and health/degraded state. **Zara implements and proves this first.** This issue is a later extraction/reuse task, not permission to design a parallel plugin loader or capability system in Prolog-RLM. `prolog_agent_ui_v1` already has generic tool rendering semantics, but it does not currently define a reusable frontend-safe plugin/catalog projection for plugin identity, source, health and configuration metadata. If Zara #655 proves that seam is domain-neutral, extract it here. ## Extraction target after Zara proves it Potential generic data includes: - stable plugin/provider identity; - local/remote/source metadata; - discovered/installed/enabled/disabled/unavailable/degraded states; - tool/capability summaries without implying execution authority; - safe non-secret configuration schema metadata; - health/readiness summaries; - bounded structured failures; - extension/facade integration with the existing frontend protocol. Do **not** freeze exact fields here before the Zara fixtures exist. ## Required linkage before implementation starts A worker must first link: 1. Zara #655 implementation PR/commit; 2. concrete Zara projection types/adapter; 3. RED-first tests/fixtures, including secret redaction and authority separation; 4. a `Zara-specific` vs `generic` seam table. If those links are absent, leave this blocked and implement Zara #655 instead. ## Invariants - no second plugin loader/runtime; - tool/schema visibility != capability possession != enabled state != execution authority; - secrets/private config never enter frontend-safe snapshots; - malformed plugin metadata fails structurally; - catalog snapshots remain bounded; - Android/UI/theme/product policy stays downstream. ## Acceptance - [ ] Zara #655 executable behavior/tests are linked first; - [ ] extraction reuses existing tool/capability/authority architecture; - [ ] deterministic conformance fixture covers catalog/status/redaction states; - [ ] UI protocol compatibility/versioning is explicit; - [ ] Zara can replace its generic adapter portion with the extracted contract; - [ ] no Zara-specific product policy moves upstream.

nsaspy referenced this issue

2026-09-08 01:29:20 +00:00

[EPIC][experts] Closed-loop integration: Requirement→Knowledge→Plan→Experts→VERIFY→Repair→Review→completion #411

nsaspy referenced this issue

2026-09-08 01:29:21 +00:00

[EPIC][expert] Review / critic expert: adversarial change analysis, regression discovery, and evidence-backed findings #412

nsaspy referenced this issue

2026-09-08 01:29:21 +00:00

[EPIC][expert] Repair / diagnosis expert: failure hypotheses, evidence gaps, bounded repair, and no-progress detection #413

nsaspy referenced this issue

2026-09-08 01:29:21 +00:00

[EPIC][expert] Write / edit / create expert: symbolic target resolution, typed changes, preimage safety, and model fallback #415