architecture: rethink config loading system and config files #774

Activity

1. jbeda commented on Aug 26, 2026

   

   jbeda

   on Aug 26, 2026

   ContributorAuthor

   More actions

   Concrete symptom: composition downcasts a policy resolver for operator settings

   internal/app.Config stores permResolver as the intentionally narrow permpolicy.RuleResolver, because the permission-policy consumer should only resolve workspace rules. app.Build then repeatedly downcasts it back to *permconfig.Resolver to access unrelated operator settings, for example provider definitions/overrides at internal/app/build.go:1431.

   The assertion is guarded and works in production because Build constructs that concrete resolver, but it is a sign that one object is serving two contracts:

   • a narrow per-workspace permission-rule resolver consumed by policy; and
   • a broad operator-settings accessor consumed by composition for providers, MCP, models, guardrails, posture, retention, and similar subtrees.

   Do not widen permpolicy.RuleResolver with unrelated configuration accessors. The redesign should provide separate views over one underlying concrete source:

   *permconfig.Resolver
     ├─ permpolicy.RuleResolver  → policy/workspace rules
     └─ OperatorConfigSource     → composition/operator settings
   

   An interim implementation could retain a concrete operator-resolver reference inside internal/app; the longer-term source abstraction should permit file, Kubernetes, database, or remote operator configuration without app.Build downcasts.
2. jbeda commented on Oct 28, 2026

   

   jbeda

   on Oct 28, 2026

   ContributorAuthor

   More actions

   Additional configuration/composition cleanup evidence

   Reviewing MCP credential resolution in PR #2583 exposed another instance of the ownership problem tracked here:

   • app.Config.permResolver stores the settings resolver as the narrow permpolicy.RuleResolver interface, even though composition needs the wider operator-settings object.
   • buildPermResolver constructs a concrete *permconfig.Resolver, narrows it on return, and composition then repeatedly asserts it back to that concrete type to access provider definitions, credential-store configuration, MCP configuration, model routing, learning, retention, harness context, and other operator settings.
   • At the time of review, there were roughly three dozen such assertions across about 15 files under internal/app. A representative example is internal/app/build.go:1855 at PR head 538bfa59c54bedf069a0efbbb8150678574797f9.

   Suggested cleanup within this architecture work

   Retain the wider concrete settings resolver at the composition layer, preferably with a name such as settingsResolver, and narrow it to permpolicy.RuleResolver only at permission-policy and child-resolver boundaries. Do not widen the permission interface with unrelated operator-settings methods, and do not introduce another resolver/cache or settings-discovery pass.

   Preserve these constraints:

   • Explicitly handle nil before conversion to an interface, avoiding typed-nil permission resolvers.
   • Preserve settings construction order, project-trust admission, source precedence, and workspace/session pinning.
   • Keep narrow permission test seams; tests that currently install a fake rule resolver into the broad composition field should instead exercise the appropriate permission-wrapper boundary.

   This is follow-up work for #774, not scope to fold into the MCP credential PR. The current MCP implementation does not depend on this cleanup for correctness.