Summary

Microsoft Foundry onboarding with Entra ID failed to persist: writing the
config hit a strict-schema validation error and updateConfig atomically rolled
the whole write back, so onboarding never completed.

models.providers.microsoft-foundry.models.0: Unrecognized key: "thinkingLevelMap"

Root cause — schema drift

thinkingLevelMap is part of the established model contract everywhere except
the persisted zod schema:

The foundry writer's persisted model entry carries thinkingLevelMap (7 keys),
but the strict persisted ModelDefinitionSchema had no such key, so the write
was rejected and rolled back. This is schema drift, not an illegal field — the
runtime normalizeResolvedModel re-adds the field anyway.

Fix

Add an optional thinkingLevelMap to the zod ModelDefinitionSchema, mirroring
the runtime TypeBox schema 1:1: the 7 ModelThinkingLevel keys
(off / minimal / low / medium / high / xhigh / max), values
string | null, with the object kept .strict().

• The writer (buildFoundryThinkingLevelMap, onModelSelected) and
  normalizeResolvedModel are unchanged — only the persisted schema needed
  to accept the existing field.

Tests

• Core regression — src/config/config.schema-regressions.test.ts:
  • Positive: a foundry-shaped model entry with thinkingLevelMap now passes
    validateConfigObject. This is the assertion that reproduces and would have
    caught the bug.
  • Negative: a thinkingLevelMap key outside ModelThinkingLevel (e.g.
    adaptive) is still rejected — proves .strict() was not loosened to
    passthrough.
• Extension — extensions/microsoft-foundry/index.test.ts: asserts the real
  writer output (Entra ID + reasoning model) emits only allowed thinkingLevelMap
  keys with string | null values.
  • It deliberately does not call the core validator: extensions/AGENTS.md
    forbids importing src/** from a plugin, so the persisted-validation
    assertion lives in the core test, and the extension side asserts the writer
    output is a subset of the allowed key set.

Real behavior proof (required for external PRs)

Note on affected version: the bug ships in the released 2026.6.1 (npm latest) and the beta channel (2026.6.5-beta.2), not just main — the originally reported version (2026.6.1) was correct. An interim grep of dist/extensions/microsoft-foundry/shared.js returned 0 and briefly suggested 2026.6.1 was unaffected, but that was a bundling artifact: the writer's thinkingLevelMap emission lives in a helper chunk that shared.js only imports. Actually running each shipped build's writer + validator confirms all three are affected (table below).

• Behavior or issue addressed: Microsoft Foundry Entra ID onboarding cannot persist. The Foundry writer puts a model entry carrying thinkingLevelMap into the config, but the persisted strict zod ModelDefinitionSchema had no such key, so updateConfig validation fails and atomically rolls the whole write back. Reported error: models.providers.microsoft-foundry.models.0: Unrecognized key: "thinkingLevelMap".

• Real environment tested: Node v22.22.1, win32 x64 (Windows 10.0.19045).

  • Shipped builds installed from npm to temp dirs and exercised directly: [email protected] (npm latest) and [email protected] (npm beta).
  • BEFORE source baseline: unpatched main at commit 4d142b185e (this PR's parent; contained in tag v2026.6.5-beta.2).
  • AFTER: this PR branch fix/91011-foundry-thinkinglevelmap-schema (60fb8c6bdc).
  • Collision uses the real code path: validateConfigObject (src/config/validation.ts) over the real output of buildFoundryAuthResult (extensions/microsoft-foundry/shared.ts). Nothing hand-edited — all ok values come from the validator.

• Exact steps or command run after this patch:
  Real Foundry writer output (Entra ID, reasoning model) fed to the real persisted validator, for a given checkout root:

  // proof.mjs (run: node --import tsx proof.mjs )
  const { validateConfigObject } = await import(`${repo}/src/config/validation.ts`);
  const { buildFoundryAuthResult } = await import(`${repo}/extensions/microsoft-foundry/shared.ts`);
  const { configPatch } = buildFoundryAuthResult({
    profileId: "microsoft-foundry:entra", apiKey: "__entra_id_dynamic__",
    endpoint: "https://example.services.ai.azure.com",
    modelId: "gpt-5.1-chat", modelNameHint: "gpt-5.1-chat",
    api: "openai-responses", authMethod: "entra-id",
  });
  console.log(validateConfigObject(configPatch).ok);                 // positive
  // + adaptive-key entry (negative) + writer-keys-subset check

Shipped builds were exercised the same way against their built ESM dist (dist/extensions/microsoft-foundry/shared.js + dist/config/config.js), with a control that removes only thinkingLevelMap.

• Evidence after fix (console output):
  ===== BEFORE (unpatched main 4d142b1) =====
  writer-emitted thinkingLevelMap: {"off":"none","minimal":null,"low":"low","medium":"medium","high":"high","xhigh":null,"max":null}
  [positive] validateConfigObject(real foundry configPatch).ok = false
  issues: [{"path":"models.providers.microsoft-foundry.models.0","message":"Unrecognized key: "thinkingLevelMap""}]
  [negative] adaptive-key entry .ok = false
  [subset] writer keys = {off,minimal,low,medium,high,xhigh,max} | outOfSet = []
  ===== AFTER (this PR branch) =====
  writer-emitted thinkingLevelMap: {"off":"none","minimal":null,"low":"low","medium":"medium","high":"high","xhigh":null,"max":null}
  [positive] validateConfigObject(real foundry configPatch).ok = true
  [negative] adaptive-key entry .ok = false
  [subset] writer keys = {off,minimal,low,medium,high,xhigh,max} | outOfSet = []
  ===== SHIPPED 2026.6.1 (npm latest) =====
  writer-emitted thinkingLevelMap: {"off":"none","minimal":null,"low":"low","medium":"medium","high":"high","xhigh":null,"max":null}
  [with thinkingLevelMap] ok = false | issues = [{"path":"models.providers.microsoft-foundry.models.0","message":"Invalid input"}]
  [without thinkingLevelMap] ok = true (control: thinkingLevelMap is the sole cause)
  ===== SHIPPED 2026.6.5-beta.2 (npm beta) =====
  writer-emitted thinkingLevelMap: {"off":"none","minimal":null,"low":"low","medium":"medium","high":"high","xhigh":null,"max":null}
  [with thinkingLevelMap] ok = false | issues = [{"path":"models.providers.microsoft-foundry.models.0","message":"Invalid input"}]
  [without thinkingLevelMap] ok = true (control: thinkingLevelMap is the sole cause)

• Observed result after fix: The real Foundry writer's Entra ID model entry (with the 7-key thinkingLevelMap) is rejected by the unpatched persisted schema (ok=false, the exact Unrecognized key: "thinkingLevelMap" rollback cause) and rejected identically by the shipped 2026.6.1 and 2026.6.5-beta.2 builds (control confirms thinkingLevelMap is the sole cause). With this patch the same entry validates (ok=true), an out-of-set level key (adaptive) is still rejected (ok=false, .strict() preserved), and the writer's emitted keys are a subset of the allowed ModelThinkingLevel set.

• What was not tested: A full end-to-end live Entra ID / Foundry onboarding run (openclaw models auth login) where updateConfig actually persists to disk and demonstrably does not roll back — that needs a real Azure Foundry endpoint plus Entra (managed identity) credentials, which I don't have.

• Proof limitations or environment constraints: Because there's no Azure Foundry/Entra environment, I reproduced the bug by colliding the two halves whose mismatch causes the rollback — the real shipped Foundry writer output and the real persisted config validator (the exact pair updateConfig runs) — rather than driving live onboarding. Shipped builds report a generic "Invalid input" (minified-bundle zod formatting); the control (removing only thinkingLevelMap flips ok to true) plus the unpatched-source run (verbatim Unrecognized key: "thinkingLevelMap") jointly pin the cause. Supplemental: this PR's vitest passes — node scripts/run-vitest.mjs extensions/microsoft-foundry/index.test.ts src/config/config.schema-regressions.test.ts src/commands/models/auth.test.ts (config-regressions 34, auth 37, foundry index 41).

• Before evidence: See the BEFORE, SHIPPED 2026.6.1, and SHIPPED 2026.6.5-beta.2 blocks above — all produced from unpatched/shipped builds, all rejecting the real Foundry writer output.

Generated baseline

docs/.generated/config-baseline.sha256 changed because the new (documented)
schema key alters the generated config-doc baseline. It was regenerated via
pnpm config:docs:gen — the sanctioned step that config:docs:check's own error
message instructs — and is not hand-edited; config:docs:check now passes.

Verification

node scripts/run-vitest.mjs extensions/microsoft-foundry/index.test.ts src/config/config.schema-regressions.test.ts src/commands/models/auth.test.ts

All three files green (config-regressions 34, auth 37, foundry index 41).
auth.test.ts mocks updateConfig, so it does not exercise the real rollback,
but it is included since the schema underpins that write path.

Not done: no live Microsoft Foundry / Entra ID verification (no environment).
Coverage is the schema↔writer alignment proven by the unit tests above.

Closes #91011