Add enablement filters to the plugin inventory

[saulo-silva]

Problem

The Settings → Plugins → Plugin list view can contain a large number of entries. Search helps when the plugin name or Loader entry ID is known, but it does not answer a common operational question: which plugins are currently enabled, and which ones are explicitly disabled?

This becomes especially difficult in larger compositions, where disabled platform-specific or optional entries are mixed into the same catalog as active entries.

This proposal is complementary to #1017, which suggests filtering plugins by category. Category answers what a plugin belongs to; enablement answers whether the effective Loader entry participates in the current composition.

Proposal

Add a compact, single-select enablement filter beside the plugin count:

• All — show every inventory entry.
• Enabled — show only entries whose effective Loader state is enabled.
• Disabled — show only entries whose effective Loader state is disabled.

The selection should compose with the existing name/entry-ID search and operate only on the inventory snapshot already loaded by the tab. It should not trigger another Remote request, persist a preference, or modify any plugin configuration.

Expected behavior

• All is selected by default.
• The visible count reflects the combined search and enablement filters.
• Changing the filter closes an expanded card if that entry is no longer visible.
• An empty status filter has its own explanatory state, distinct from an unmatched search.
• The control uses native buttons with aria-pressed, visible keyboard focus, localized copy, and a responsive layout.
• Enabled/disabled filtering remains separate from Cordis runtime phases such as pending, loading, active, failed, and unloading.

Reference implementation

A working implementation is available here:

• Compare: master...saulo-silva:deepseek-harness:codex/plugin-inventory-enablement-filter
• Commit: saulo-silva@7cd2613

The implementation keeps the inventory read-only, adds English and Chinese copy, updates the package documentation, and covers the behavior with component tests and the assembled Web settings scenario.

Validation completed:

• Package-focused tests: 9 passed.
• Web settings scenario: 11 passed.
• Build, lint, client UI i18n, package typecheck, and the pre-push typecheck passed.

Open questions

• Is a three-option segmented control the preferred presentation for this filter?
• Should enablement remain view-local, or should the selected value persist while Settings stays mounted?
• Should runtime phase filtering be considered separately in a later change?

[saulo-silva]

[argszero]

Reviewed the proposal against the inventory data source and the reference implementation — the foundation holds, and the one subtle correctness point checks out.

Feasibility — the enabled field already exists in the snapshot. PluginInventoryEntry carries enabled: boolean ("Effective Loader enablement, including disabled ancestor groups") and the Remote computes it directly from the Loader: enabled: !entry.disabled (packages/host/plugin-inventory/src/index.ts, list()). So the filter needs no new Remote field, and the "operate only on the inventory snapshot already loaded" constraint is satisfiable as specified.

The ancestor-group semantics are real, not aspirational. The subtle case is whether a group-disabled entry lands in the Disabled filter. Cordis's Entry.disabled getter is documented "True when this entry or any owning parent entry is disabled" and walks the parent chain (vendor/loader/src/config/entry.ts:83-95 — _disabled() checks the entry's own disabledOf() then each owning parent's). So enabled: !entry.disabled in the inventory genuinely reflects effective enablement including group inheritance — a platform-specific entry disabled via an ancestor group will correctly appear under Disabled.

Reference implementation review (against the diff):

• Filter predicate entry.enabled === (enablement === 'enabled') is correct against that field; composes with search via a single combined filter pass, and no second Remote call is introduced.
• The emptyFilter vs emptySearch distinction is right: with entries present but zero matching, a non-empty query shows the search-empty state while a bare filter shows the filter-empty state.
• The visible count reflects the combined search+enablement filter per spec; expanded-card dismissal on filter-out is covered; localized labels and aria-pressed/role="group"/data-filter are in place.

One optional a11y note: the three buttons form a single-select group — role="radiogroup" with role="radio" (or aria-current on a nav-style group) would be semantically tighter than three toggle aria-pressed buttons, though the current pattern is a defensible choice. Not a blocker.

Solid proposal and implementation — verified against master (cd5ef81481).

[saulo-silva]

Thank you for the thorough review, especially for verifying effective Loader enablement through disabled ancestor groups.

I agreed with the accessibility note and updated the reference implementation in 4dcfb23e21. The selector now uses radiogroup/radio semantics, aria-checked, roving tabindex, and the expected Arrow, Home, and End keyboard interactions.

The component tests cover the keyboard and selection behavior with 100% focused coverage, and the assembled Web settings scenario passes all 11 tests. Build, lint, and typecheck also pass.

Thanks for identifying the semantic improvement.