kbagent: kai / docs / component ignore the "project use" default project

[soustruh]

Tracked in Linear: CLI-2

Summary

kbagent project use <alias> sets a persistent default project. It writes config.default_project. Several read commands do not read that default. They use the first registered project instead. The command then acts on the wrong project, and the user gets no warning.

Found on kbagent 0.90.1.

Reproduce

1. Register two or more projects. The first row of kbagent project list must not be the project you want.
2. Run kbagent project use <wanted-alias>.
3. Confirm kbagent project list shows the default star on <wanted-alias>.
4. Run kbagent kai preflight without --project.

Result: the command reports the first project, not the pinned one.

Example: the pin was on an internal test project (id 4214). kai preflight reported a different internal test project (id 5011), which is the first row of project list.

Root cause (found — please verify)

kbagent has two project resolvers.

The correct one is resolve_project_alias in commands/_helpers.py:214. Its cascade is:

1. explicit --project
2. env override (ENV_PROJECT_ALIAS)
3. the config.default_project pin from project use
4. the single-project shortcut

The kai path does not use it. KaiService.resolve_alias (services/kai_service.py:32) returns next(iter(projects)) when the alias is None. That value is the first registered project. It never reads config.default_project. The inline comment reads "Fall back to default (first project)", which conflates "default" with "first".

Same defect in other commands (found)

The same next(iter(projects)) shortcut selects the project here:

• services/kai_service.py:52 — kai ping, kai preflight, kai ask, kai chat
• services/docs_service.py:59 — docs query
• services/component_service.py:591 — component detail
• services/component_service.py:783 — component search

All four ignore the project use pin. Each acts on the first registered project.

Not a defect (leave alone)

These next(iter(...)) uses set or repoint the pin. They are correct.

• config_store.py:464, config_store.py:642, commands/init.py:205 — repoint default_project when the current one becomes invalid.
• config_store.py:802 — the same, for the dev-portal identity.

Scope

1. Fix the four sites. Make each honor config.default_project. Prefer routing through the shared resolve_project_alias cascade over a second copy of the logic.

2. Verify the root cause above.

3. Audit every project-selection site in kbagent. For each command group, check the no---project path. It must reach the shared cascade, not a local shortcut. Confirm these in particular:

   • services/snapshot_service.py:253
   • services/token_service.py:224
   • services/stream_service.py:211

   Each has a _resolve_project(alias) with a required alias. Check that the command layer resolves the alias through the shared cascade before the call.

4. Add a regression test. Register two projects. Pin the second with project use. Run a no---project command. Assert it acts on the pinned project.

Workaround (until fixed)

Pass the alias explicitly.

kbagent kai preflight --project <alias>