fix(kiro): send the full tool contract and native effort to Kiro Claude models

docs-site/src/content/docs/fr/reference/adapters.md

@@ -124,6 +124,8 @@ Les comptes inactifs n’ont pas encore nécessairement de liste observée.
 - Construit le `conversationState` de Kiro, mappe les outils Codex et leurs résultats, puis envoie les blocs d’image pris en charge par le protocole Kiro.
 - Décode `application/vnd.amazon.eventstream`, reconstruit les événements de texte, de raisonnement et d’outil, détecte les données JSON d’outil tronquées et estime l’utilisation, car le service en amont ne renvoie aucun nombre de jetons.
   Les jetons restent estimés, mais les crédits de `meteringEvent` sont mesurés dans `providerCredits` : la dernière valeur d'une réponse est retenue, puis les envois physiques facturés séparément sont additionnés. Aucun crédit n'est déduit des jetons.
+- Envoie au plus 48 outils client et 96 Ko de JSON d’outil converti par requête, et coupe chaque description d’outil à 1 024 caractères (9 216 pour `gpt-5.6-sol`). Les outils chargés par tool search et l’outil d’exécution du code mode Codex passent en premier ; le modèle est informé des outils omis. Réglez `OCX_KIRO_TOOL_BUDGET=off` dans l’environnement du proxy pour envoyer tout le catalogue client, et `OCX_KIRO_TOOL_DESCRIPTION_LIMIT=off` pour envoyer les descriptions complètes. Les deux sont lus à la conversion de la requête, s’appliquent à tous les modèles Kiro et laissent les autres limites intactes. Désactiver le budget supprime la limite elle-même : il n’y a plus rien à prioriser ni à omettre. Tous les outils déclarés partent dans l’ordre de déclaration, l’avis d’omission disparaît, et un client qui en déclare plus que Kiro n’en accepte reçoit le `ValidationException` amont au lieu d’un catalogue réduit. La taille des requêtes suit alors le catalogue du client. Ces interrupteurs sont une option de retrait pour un compte mesuré comme acceptant la requête plus grande, pas un moyen de rendre un catalogue surdimensionné sûr.
+- Retire les mots-clés JSON Schema que le validateur de Kiro rejette (`pattern`, `minLength`, `maximum`, `additionalProperties` et 25 autres) des schémas d’outil et de sortie structurée, sauf ceux qu’une sonde a mesurés sur le modèle concerné. `claude-opus-4.5` les conserve tous. `claude-opus-5.5` et `claude-sonnet-5.5` conservent `pattern` et `maximum` ; leurs autres mots-clés restent retirés, faute de sonde qui les leur ait envoyés. Tout autre modèle Kiro, y compris les autres identifiants Claude, garde le retrait complet. L’exception est par modèle et par mot-clé parce que ce protocole sépare déjà les modèles Claude sur l’effort de raisonnement, et un mot-clé rejeté par Kiro fait échouer la requête entière au lieu de seulement priver le modèle d’une indication.
 - Utilise à l’identique le `baseUrl` configuré lorsqu’il est personnalisé. Une URL canonique `runtime.{region}.kiro.dev` suit la région d’API de l’identifiant importé ; seule cette forme canonique peut faire l’objet d’un unique repli borné vers `q.{region}.amazonaws.com` après un échec de point de terminaison, de signature, de DNS ou de connexion, ou une réponse HTTP 502/503/504 reçue avant toute sortie.
 - Gère la récupération après réinitialisation de connexion lorsqu’un rejeu est sûr, cet unique repli de point de terminaison admissible, une actualisation OAuth suivie d’un rejeu après une réponse HTTP 401, ainsi qu’une récupération bornée pour les réponses Kiro 429 transitoires. Un délai de récupération partagé et une seule sonde après ce délai empêchent les requêtes concurrentes d’épuiser des budgets de nouvelle tentative indépendants ; un quota épuisé n’est pas réessayé sur le même compte, et les autres erreurs de service ne sont pas rejouées. Tous les envois Kiro utilisent la sortie réseau configurée ; un délai d’en-tête dépassé renvoie 504, l’annulation du client arrête la requête et les erreurs HTTP 5xx finales affichent un texte public fixe.
 - Avec deux comptes enregistrés, un refus de débit refroidit brièvement le compte concerné. Un refus mensuel confirmé (HTTP 400 ou 429) l’exclut jusqu’à la réinitialisation observée ou l’expiration des données ; une suspension confirmée (HTTP 403) le met temporairement en quarantaine, mais un 403 ordinaire ne déclenche pas de rotation. La rotation après refus reste active lorsque la préférence proactive est désactivée. Le choix d’un autre compte avant le premier envoi exige une préférence proactive, où le réglage du fournisseur prime sur le réglage global. Un tour terminé par le même compte efface un ancien verdict d’épuisement.
@@ -141,12 +143,43 @@ Si Kiro s’arrête sans appeler l’outil d’achèvement, l’adaptateur effec
 
 ### Effort de raisonnement
 
-Les modèles GPT-5.6 utilisent `additionalModelRequestFields.reasoning.effort`, et `claude-opus-5`
-utilise `additionalModelRequestFields.output_config.effort`. Pour `gpt-5.6-luna` et `gpt-5.6-terra`,
-seuls `low`, `medium`, `high` et `max` empruntent le chemin natif vérifié. Leur niveau `xhigh`
-conserve les instructions de réflexion bornées existantes, car ce niveau natif n’a pas été vérifié.
-`gpt-5.6-sol` et `claude-opus-5` conservent leurs niveaux natifs existants : `low`, `medium`, `high`,
-`xhigh` et `max`. Les autres modèles Kiro utilisent une émulation ; un réglage d’effort ne prouve pas une prise en charge native.
+Les modèles GPT-5.6 et GPT-6 (`gpt-6-sol`, `gpt-6-luna`, `gpt-6.1-sol`, `gpt-6.1-terra`)
+utilisent `additionalModelRequestFields.reasoning.effort`, et les modèles Claude listés ci-dessous
+utilisent `additionalModelRequestFields.output_config.effort`.
+Pour `gpt-5.6-luna` et `gpt-5.6-terra`, seuls `low`, `medium`, `high` et `max` empruntent le
+chemin natif vérifié. Leur niveau `xhigh` conserve les instructions de réflexion bornées
+existantes, car ce niveau natif n’a pas été vérifié.
+`gpt-5.6-sol` et les modèles GPT-6 conservent leurs niveaux natifs `low`, `medium`, `high`,
+`xhigh` et `max` par ce même champ `reasoning.effort`.
+
+Kiro accepte `output_config.effort` pour `claude-opus-5`, `claude-opus-5.5`, `claude-opus-4.8`,
+`claude-opus-4.7`, `claude-opus-4.6`, `claude-sonnet-5.5`, `claude-sonnet-5`, `claude-sonnet-4.6`
+et `claude-haiku-5.5` aux niveaux `low`, `medium`, `high`, `xhigh` et `max`, avec une
+exception : `claude-opus-4.6` et `claude-sonnet-4.6` rejettent le `xhigh` natif, donc ce niveau
+garde le bloc de réflexion émulé.
+
+Kiro n’a pas de niveau `minimal`. Sur les neuf modèles ci-dessus sauf `claude-opus-5` et
+`claude-opus-5.5`, `minimal` conserve le bloc émulé au lieu de faire échouer une requête qui
+fonctionnait avant l’activation de l’effort natif. Ces deux modèles Opus 5, ainsi que les modèles GPT
+qui portent un effort natif, rejettent `minimal` par une erreur 400 `invalid_request_error` avant
+que quoi que ce soit ne soit envoyé.
+
+Les surfaces rapportent ce refus différemment. Une requête Responses place dans `error.message` une
+phrase qui nomme le modèle et le niveau refusé. Les chemins Messages et Chat Completions y placent le
+texte fixe du proxy, `The provider rejected the request.`, parce qu’ils remplacent le détail de
+l’adaptateur par leur propre libellé au lieu de le relayer. Seul Responses nomme le modèle et le
+niveau. Les requêtes en flux et hors flux se lisent à l’identique sur toutes les surfaces : le refus
+survient pendant la construction du corps envoyé en amont, donc aucun flux ne s’ouvre et aucun appel
+amont n’a lieu.
+
+Le `ultra` envoyé par l’appelant est réduit à `max` à l’analyse. Les pins `pinnedReasoningEffort`,
+`modelPinnedReasoningEfforts` et `modelPinnedEfforts` sont appliqués ensuite : pour les modèles à
+effort natif Kiro, l’adaptateur réduit aussi `ultra` à `max`. Pour les modèles en émulation, ce pin
+est ignoré et la requête part sans signal de raisonnement.
+
+`claude-haiku-4.5`, `claude-opus-4.5`, `claude-sonnet-4.5`, ainsi que tout modèle Kiro non
+listé ci-dessus, utilisent une émulation à chaque niveau ; un réglage d’effort ne prouve pas une
+prise en charge native.
 
 ## `cursor`
 

docs-site/src/content/docs/ja/reference/adapters.md

@@ -136,6 +136,25 @@ HTTP リトライ ループの対象外です。
   block を送ります。
 - `application/vnd.amazon.eventstream` をデコードして text/thinking/tool イベントを復元し、途切れたツール JSON を検出します。上流がトークン数を返さないため使用量は推定します。
 - `fetchResponse` で限られた回数だけリトライし、エラーを分類/マスクします。非ストリーミングパーサーはウェブ検索ループのために同じイベントストリームを最後まで消費します。
+- リクエストごとにクライアントツールを最大 48 個、変換後のツール JSON を 96 KB まで送り、ツールの説明は
+  1,024 文字（`gpt-5.6-sol` は 9,216 文字）で切り詰めます。tool search で読み込んだツールと Codex
+  code-mode の実行ツールを先に採用し、省略したツールはモデルに伝えます。プロキシの環境に
+  `OCX_KIRO_TOOL_BUDGET=off` を設定するとクライアントのカタログ全体を、
+  `OCX_KIRO_TOOL_DESCRIPTION_LIMIT=off` を設定すると説明の全文を送ります。どちらもリクエスト変換時に
+  読み取られ、すべての Kiro モデルに適用され、他の上限は変わりません。予算を切ると上限自体がなくなり、
+  優先順位も省略も対象がなくなります。宣言したツールがすべて宣言順に送られ、省略の通知も消え、
+  Kiro が受け付ける数より多く宣言したクライアントは、切り詰めたカタログではなく上流の
+  `ValidationException` を受け取ります。リクエストサイズもクライアントのカタログに比例して大きくなります。
+  このスイッチは、より大きなリクエストを受け付けると測定されたアカウント向けのオプトアウトであり、
+  過大なカタログを安全にする手段ではありません。
+- Kiro のバリデータが拒否する JSON Schema キーワード（`pattern`、`minLength`、`maximum`、
+  `additionalProperties` など 29 個）をツールと構造化出力のスキーマから取り除きます。ただし、
+  プローブでそのモデルが受け付けたと確認できたキーワードは残します。`claude-opus-4.5` はすべて残ります。
+  `claude-opus-5.5` と `claude-sonnet-5.5` は `pattern`、`maximum` だけが残り、それ以外は取り除かれたままです。この 2 つの
+  モデルに他のキーワードを送ったプローブがないためです。他の Claude id を含むその他の Kiro モデルは
+  すべて取り除きます。例外をモデル単位・キーワード単位にしているのは、この wire が reasoning effort で
+  すでに Claude モデルを分けているためであり、Kiro が拒否するキーワードはヒントを失うだけで済まず、
+  リクエスト全体を失敗させるからです。
 ### 完了とネイティブ stop reason
 
 Kiro のアシスタントテキストには、それ自体で end-turn を示す信頼できる区別がありません。ただし終端の
@@ -155,12 +174,39 @@ filtered incomplete になります。実際のツール呼び出しを伴わな
 
 ### Reasoning effort
 
-GPT-5.6 系は `additionalModelRequestFields.reasoning.effort`、`claude-opus-5` は
-`additionalModelRequestFields.output_config.effort` を使用します。`gpt-5.6-luna` と
-`gpt-5.6-terra` では、検証済みの `low`、`medium`、`high`、`max` だけをネイティブフィールドで送信します。
+GPT-5.6 系と GPT-6 系（`gpt-6-sol`、`gpt-6-luna`、`gpt-6.1-sol`、`gpt-6.1-terra`）は
+`additionalModelRequestFields.reasoning.effort`、以下に挙げる Claude のモデルは
+`additionalModelRequestFields.output_config.effort` を使用します。
+`gpt-5.6-luna` と `gpt-5.6-terra` では、検証済みの `low`、`medium`、`high`、`max` だけをネイティブフィールドで送信します。
 両モデルの `xhigh` は未検証のため、従来の上限付き thinking 指示によるエミュレーションを維持します。
-`gpt-5.6-sol` と `claude-opus-5` の既存のネイティブ段階（`low`、`medium`、`high`、`xhigh`、`max`）は変更しません。
-その他の Kiro モデルはエミュレーションを使用し、effort の選択肢だけではネイティブ対応を意味しません。
+`gpt-5.6-sol` と GPT-6 系は、同じ `reasoning.effort` フィールドでネイティブの `low`、`medium`、
+`high`、`xhigh`、`max` を維持します。
+
+Kiro は `claude-opus-5`、`claude-opus-5.5`、`claude-opus-4.8`、`claude-opus-4.7`、
+`claude-opus-4.6`、`claude-sonnet-5.5`、`claude-sonnet-5`、`claude-sonnet-4.6`、
+`claude-haiku-5.5` で `low`、`medium`、`high`、`xhigh`、`max` を `output_config.effort` として
+受け付けます。例外が 1 つあります。`claude-opus-4.6` と `claude-sonnet-4.6` はネイティブの `xhigh` を
+拒否するため、その段階だけエミュレーションの thinking ブロックを使います。
+
+Kiro には `minimal` の段階がありません。`claude-opus-5` と `claude-opus-5.5` を除く上記の 9 モデルは、
+ネイティブ effort を有効にする前から動作していたリクエストを失敗させないよう、`minimal` でエミュレーションの
+ブロックを維持します。この 2 つの Opus 5 モデルとネイティブ effort を持つ GPT 系は、何も送信する前に
+`minimal` を 400 `invalid_request_error` で拒否します。
+
+拒否の伝え方はサーフェスごとに異なります。Responses リクエストはモデルと拒否された effort を示す文を
+`error.message` に入れます。Messages と Chat Completions の経路はその位置にプロキシの固定文言
+`The provider rejected the request.` を入れます。どちらもアダプターの詳細文をそのまま中継せず、自前の
+文言に置き換えるためです。モデルと effort を示すのは Responses だけです。ストリーミングと非ストリーミングは
+どのサーフェスでも同じ応答になります。拒否は上流へ送る本文を組み立てる途中で起きるため、ストリームは
+開かれず上流呼び出しも発生しません。
+
+呼び出し元の `ultra` は解析時に `max` へ変換されます。`pinnedReasoningEffort`、
+`modelPinnedReasoningEfforts`、`modelPinnedEfforts` はその後に適用されます。ネイティブ Kiro
+effort を持つモデルでは、アダプターも pin の `ultra` を `max` に変換します。エミュレーション
+モデルでは pin は破棄され、推論シグナルなしでリクエストが送られます。
+
+`claude-haiku-4.5`、`claude-opus-4.5`、`claude-sonnet-4.5` と、上記にない Kiro モデルは
+すべての effort でエミュレーションを使います。effort の選択肢だけではネイティブ対応を意味しません。
 
 ## `cursor`