Teknium e1be6fcfe0 fix(config): config_keys come from the loader's discovery, count only for active plugins, never widen a section ...

Review findings on the config_keys seam:

- Discovery: drop the glob scan. config_keys is parsed onto PluginManifest
  (plugin.yaml, and extensions.com.nousresearch.hermes in a portable
  plugin.json) and read from the loader's own collect_directory_manifests +
  entry points + resolve_manifest_winners, so skip rules, precedence and the
  project-plugin gate are the loader's.
- Only active plugins count: gate_manifest must load the plugin (disabled wins,
  plugins.enabled opt-in, requires_hermes); memory providers count when
  memory.provider selects them.
- Bounded: a declared path is at least two segments deep and is ignored when
  DEFAULT_CONFIG already defines it; runtime keys are consulted only after the
  schema walk refused a key, so a plugin declaring [agent] no longer hides
  agent.max_turnz.
- No lru_cache: a plugin installed or enabled in a long-running process counts
  on the next config get/set (the lookup runs only for refused keys).
- computer_use.backend (read by the plugins/computer_use selector) and
  dashboard.kanban move to a core table with their readers; the selection
  sections derive from read_selection's own _SELECTION_NAME_KEYS.
- Tests use fixture plugins (enabled/disabled, hostile [agent], selected memory
  provider, portable plugin.json, project opt-in).

2026-10-28 13:09:00 -07:00

..

cua

fix(config): config_keys come from the loader's discovery, count only for active plugins, never widen a section

2026-10-28 13:09:00 -07:00

__init__.py

ci: ruff UP037 fixes

2026-10-09 17:34:38 +02:00