[Bug] includeAgentsMd doesn't work as expected

[Non-J]

Description

Expectation:

• If includeAgentsMd is set to false in agents.config.json, then it should take priority over everything else second only to session override (i.e., using /tune command should only override for that session).

Reality:

• The function loadAppConfig() never reads tune config from agents.config.json.
• The function resolveTune will use includeAgentsMd in user preference over app config.
• sessionOverride isn't actually passed into resolveTune.

Environment

• OS: N/A
• Node version: N/A
• Nanocoder version: 1.28.1
• Provider: N/A
• Model: N/A

Steps to Reproduce

1. Set agents.config.json to

 {
   "nanocoder": {
     "tune": {
       "includeAgentsMd": false
     }
   }
 }

2. Open the app.
3. The config isn't respected.

Expected Behavior

If includeAgentsMd is set to false in agents.config.json, then it should take priority over everything else second only to session override (i.e., using /tune command should only override for that session).

Actual Behavior

• The function loadAppConfig() never reads tune config from agents.config.json.
• The function resolveTune will use includeAgentsMd in user preference over app config.
• sessionOverride isn't actually passed into resolveTune.

Logs/Screenshots

If applicable, add logs or screenshots to help explain the problem

Additional Context

• I have searched existing issues to ensure this is not a duplicate
• I can reproduce this issue consistently
• This issue occurs with the latest version of nanocoder

[rakshith1928]

I investigated this issue and it looks like the project-level nanocoder.tune configuration isn't making it all the way through the initialization flow.

From what I found:

• loadAppConfig() never loads the nanocoder.tune section from agents.config.json, so those settings are dropped before they ever become part of AppConfig.
• useAppState initializes the tune state by calling resolveTune(undefined, undefined, preferences), so even if the app config contained tune settings, they aren't considered during initialization.
• The existing resolveTune() precedence logic already appears to be covered by unit tests, so this looks more like an integration/wiring issue than a problem with the merge logic itself.

Currently, when the application starts, the flow is effectively:

Defaults → User Preferences → resolveTune()

The project-level nanocoder.tune configuration from agents.config.json never enters the resolution flow.

My plan is to:

1. Add a loadTuneConfig() helper (following the existing load*Config() pattern) and include tune in loadAppConfig().
2. Update useAppState to pass getAppConfig() into resolveTune() so project-level tune settings are considered during initialization.
3. Add an integration test that verifies nanocoder.tune.includeAgentsMd from agents.config.json is loaded and respected end-to-end.

With these changes, the startup flow would become:

Defaults → User Preferences → Project Config (agents.config.json) → resolveTune()

or, from the loading perspective:

agents.config.json → loadTuneConfig() → loadAppConfig() → getAppConfig() → resolveTune()

This should ensure that project-level nanocoder.tune settings are loaded and applied as expected during startup.

The only remaining question is whether /tune should be implemented as a true session-only override (with the highest precedence) or continue to update persisted preferences. That seems like a separate behavioral decision, so I'd like to confirm the intended behavior before making changes in that area.

[akramcodez]

@rakshith1928 Nice investigation! I agree with the root cause and the overall implementation plan. One thing I'd also include is the precedence described in the issue. Right now, simply wiring agents.config.json into resolveTune() may still allow persisted preferences to override nanocoder.tune, which doesn't match the expected behavior. It seems the merge order in resolveTune() should also be updated so the precedence becomes: Defaults → ProviderConfig → Preferences → AppConfig (agents.config.json) → SessionOverride.

If you have any questions or want to discuss the implementation, just tag me and I'm happy to help.

[rakshith1928]

@akramcodez
One question before I update the merge order: I noticed there's an existing test (tune.spec.ts) asserting that per-provider tune overrides the top-level app config. The precedence you suggested above (Defaults → ProviderConfig → Preferences → AppConfig → SessionOverride) would make AppConfig override ProviderConfig instead.

Is that an intentional behavior change, or was the intent specifically for AppConfig to override Preferences while keeping the existing ProviderConfig > AppConfig relationship?