Repo settings exposes OpenClaw but updateRepo cannot persist OpenClaw defaults or model settings

[MicroMilo]

1. Problem

OpenClaw is exposed as a first-class agent/provider in shared metadata, the provider options API, the repo settings UI, and the database schema. However, the repo update API contract still omits OpenClaw from the default-agent validator and omits OpenClaw-specific fields from the update schema/service input.

Source anchors:

• packages/shared/src/agent-options/index.ts:34-40 includes openclaw in ALL_PROVIDER_IDS.
• packages/shared/src/agent-options/index.ts:48-57 includes openclaw in the persisted AgentType / AGENT_TYPES set.
• apps/api/src/routes/agent-options.ts:9-10 accepts openclaw as a provider parameter.
• apps/api/src/routes/agent-options.ts:69-81 documents OpenClaw as a provider whose options endpoint returns the hardcoded baseline.
• apps/web/src/app/repos/[id]/page.tsx:39-46 shows an OpenClaw agent settings tab.
• apps/web/src/app/repos/[id]/page.tsx:242-273 sends defaultAgentType and openclawModel through api.updateRepo(...).
• apps/web/src/app/repos/[id]/page.tsx:1194-1202 renders AgentOptionsPicker for provider="openclaw" and stores openclawModel.
• apps/web/src/lib/api-client.ts:267-268 sends repo updates as PATCH /api/repos/:id.
• apps/api/src/routes/repos.ts:32-40 defines updateRepoSchema.defaultAgentType with a hard-coded enum that excludes openclaw.
• apps/api/src/routes/repos.ts:43-54 includes model/settings fields for other providers but no openclawModel or openclawAgent.
• apps/api/src/routes/repos.ts:66-70 already uses shared AGENT_TYPES for reviewAgentType, showing a nearby validator that does accept the shared OpenClaw agent type set.
• apps/api/src/db/schema.ts:273-274 has openclawModel and openclawAgent columns.
• apps/api/src/services/repo-service.ts:189-238 types the update input without openclawModel or openclawAgent.
• apps/api/src/services/repo-service.ts:240-259 persists the validated update payload into the repo row.

Minimal reproduction path:

1. Open a repo settings page.
2. Select OpenClaw as the default agent and save.
3. The frontend sends defaultAgentType: "openclaw" through PATCH /api/repos/:id.
4. The backend update schema rejects it because defaultAgentType only allows claude-code, codex, copilot, opencode, and gemini.

Second reproduction path:

1. Open the OpenClaw tab in repo settings.
2. Select an OpenClaw model and save.
3. The frontend sends openclawModel.
4. The backend update schema does not include openclawModel, and the service update input also omits it, so the setting cannot be persisted through this API contract.

Actual behavior:

• OpenClaw appears as a selectable/defaultable agent in the UI and shared catalog.
• Saving OpenClaw as the default agent is rejected by the repo update validator.
• OpenClaw model settings are sent by the frontend but are not part of the accepted update contract.

Expected behavior:

• If OpenClaw is exposed in repo settings, PATCH /api/repos/:id should accept defaultAgentType: "openclaw" and should persist openclawModel / openclawAgent consistently with the database schema.
• If OpenClaw should not yet be configurable in repo settings, the UI and shared catalog should not present it as a saveable repo setting.

User impact:

This is a frontend/backend contract drift. Users can see and interact with OpenClaw repo settings, but the backend contract cannot save the same values. That can produce failed saves, settings that appear configurable but do not persist, and inconsistent behavior between the shared agent catalog, UI, API validator, and database schema.

2. Existing issue / PR coverage

I checked current open and closed GitHub issues and PRs with these searches:

• openclaw defaultAgentType repos
• openclawModel updateRepo
• OpenClaw repo settings

Related historical items:

• Issue feat(agent-adapters): add OpenClaw agent runtime support #409 / PR feat(agent-adapters): add OpenClaw agent runtime support #413, feat(agent-adapters): add OpenClaw agent runtime support, added OpenClaw runtime and touched repo settings and database schema, but the latest updateRepoSchema still rejects defaultAgentType: "openclaw" and omits OpenClaw update fields.
• Issue Dynamic per-provider model & options picker with refresh button #492 / PR Dynamic per-provider model & options picker with refresh button #493, Dynamic per-provider model & options picker with refresh button, added the provider options picker and touched the OpenClaw catalog/UI, but the latest repo update API still does not accept the OpenClaw values emitted by the UI.
• PR feat(web): split external PR review and tabify agent settings #487, feat(web): split external PR review and tabify agent settings, touched the repo settings UI only and does not cover the backend schema mismatch.

Coverage assessment: not covered. These items are adjacent feature work, but none fix the current API contract drift that remains in the latest source.

3. Should this be fixed?

Yes. This is a deterministic mismatch between shared metadata, UI request production, API validation, service typing, and database persistence. The intended behavior is strongly implied by the existing OpenClaw tab, provider options endpoint, shared AGENT_TYPES, and database columns.

4. Proposed fix / PR draft

Suggested implementation direction:

• Change updateRepoSchema.defaultAgentType to use the shared AGENT_TYPES set, matching reviewAgentType.
• Add openclawModel and openclawAgent to updateRepoSchema.
• Add openclawModel and openclawAgent to the updateRepo(...) service input type and persistence path.
• Add or update route tests for:
  • PATCH /api/repos/:id accepts defaultAgentType: "openclaw";
  • openclawModel persists when sent by the repo settings UI;
  • existing provider settings still work.
• If the product decision is that OpenClaw should not be configurable at repo level yet, hide or disable the OpenClaw repo settings UI instead of exposing a setting that the backend rejects.

Non-goals:

• This does not require changing OpenClaw runtime behavior.
• This does not require changing the provider options catalog itself.