Fix schema constraint loss in json_schema_updater.py recursive_update() #3095

What happened

PR #3093 regenerated developer documentation. CodeRabbit's review found that the generated docs/user_doc/config.json schema diverges from runtime Pydantic validators in two ways: (1) streaming_output_check_interval_tokens (a PositiveInt field, valid values ≥ 1) was emitted as minimum: 0, allowing zero; (2) AllowedModel.model_type (typed as Optional[Literal["llm", "embedding", "rerank"]]) was emitted as bare type: string with no enum constraint. Both inaccuracies are pre-existing, introduced by the recursive_update() function in src/utils/json_schema_updater.py which transforms Pydantic-generated JSON Schema into OpenAPI 3.0.

What could go better

The recursive_update() function has two bugs that silently drop schema constraints:

1. exclusiveMinimum conversion (line 52-53): Pydantic v2 emits {"exclusiveMinimum": 0} for PositiveInt (meaning value > 0). The function rewrites this to {"minimum": 0} (meaning value ≥ 0), losing the exclusive semantics. For OpenAPI 3.0, the correct output is {"minimum": 0, "exclusiveMinimum": true} or equivalently {"minimum": 1} for integer types.

2. anyOf nullable handling (lines 36-49): When converting anyOf: [{type, enum, format, ...}, {type: null}] to a nullable type, the function extracts only value[0]["type"] and discards all other constraints (enum, format, maxLength, items, etc.). This is why Literal enums and array item types are lost in the generated schema.

The existing unit tests in tests/unit/utils/test_json_schema_updater.py encode the incorrect behavior as expected — e.g., test_exclusive_minimum_handling_zero_value asserts that exclusiveMinimum: 0 becomes minimum: 0, and test_anyof_with_additional_fields_on_first_item asserts that format and maxLength are dropped.

Confidence: High. The bugs are visible in the source code and confirmed by the test expectations matching the observed schema output.

Proposed change

Fix both bugs in src/utils/json_schema_updater.py::recursive_update():

1. exclusiveMinimum: Change the conversion from new["minimum"] = value to new["minimum"] = value; new["exclusiveMinimum"] = True (OpenAPI 3.0 style), which correctly encodes "strictly greater than value".

2. anyOf nullable: After extracting val = value[0]["type"], copy all remaining keys from value[0] into new (e.g., enum, format, maxLength, items, $ref). Something like:

for k, v in value[0].items():
    if k != "type":
        new[k] = recursive_update(v) if isinstance(v, dict) else v

3. Update unit tests to assert the corrected behavior: exclusiveMinimum: 0 → {"minimum": 0, "exclusiveMinimum": true}; nullable types preserve enum, format, maxLength, etc.

4. Regenerate all doc artifacts (uv run make generate-documentation) to propagate the fixes to docs/user_doc/config.json, docs/models/requests.json, etc.

Validation criteria

After the fix: (1) docs/user_doc/config.json should show streaming_output_check_interval_tokens with "minimum": 0, "exclusiveMinimum": true or "minimum": 1. (2) AllowedModel.model_type schema should include "enum": ["llm", "embedding", "rerank"]. (3) All existing unit tests pass after updating expectations. (4) uv run make verify passes.

Related issues checked

Searched: PositiveInt schema minimum; config schema generation accuracy; openapi schema accuracy validation; json_schema_updater exclusiveMinimum anyOf constraint loss
No overlapping issues found.

Generated by retro agent from #3093