OpenMAIC

これは OpenMAIC v1.1.2 の既知のバグです。カスタムのキーレスプロバイダー（requiresApiKey: false、例：ローカルの OpenAI 互換 TTS エンドポイント）を追加すると、lib/store/settings.ts の addCustomTTSProvider はエンドポイントを customDefaultBaseUrl にのみ保存し、baseUrl: '' のままにします。リロード時に、lib/store/settings-validation.ts の検証関数 isProviderUsable が if (cfg.requiresApiKey === false) return !!cfg.baseUrl; を実行し、プロバイダーを使用不可と判定して、通知なく browser-native-tts にフォールバックします。ダビング UI（行ごとのプレビュー/再生成ボタン、「すべてのダビングを再生成」、音声付きチップ）は ttsProviderId !== 'browser-native-tts' を条件としてゲートされているため、すべてのダビングコントロールが消えてしまいます。

修正方法（検証済み）: lib/store/settings.ts で、カスタムプロバイダーの追加/更新時に URL を両方のフィールドに書き込みます:

addCustomTTSProvider: (id, name, baseUrl, requiresApiKey, defaultModel) =>
  set((state) => ({
    ttsProvidersConfig: { ...state.ttsProvidersConfig, [id]: {
      ...,
      baseUrl,                  // was ''
      customDefaultBaseUrl: baseUrl,
      ...
    }},
    ttsProviderId: id,
  })),

代替の修正方法: isProviderUsable で、custom-* のプロバイダー ID に対して customDefaultBaseUrl をフォールバックとして受け入れます。例えば、キーレスの分岐で return !!(cfg.baseUrl || cfg.customDefaultBaseUrl); とします。カスタム ASR プロバイダーにも同じ変更を適用し、その後リビルドしてください（pnpm build && pnpm start）。コードを変更しない一時的な回避策: リロードのたびに 設定 → モデルサービス → TTS でカスタムプロバイダーを再選択するか（次のリロードまでは動作します）、セッションごとにプロバイダーを削除して再追加してください。

これは OpenMAIC 1.2.0-rc.2 の既知のバグです。PBL v3 の studentFeedback ゲート（lib/server/pbl-v3/guided-review.ts、71〜79行目）は、最新の学生メッセージに対してリテラルな部分文字列マッチを行っていたため、エージェントがラップまたは要約したフィードバック（例: Student reply: "..."）はすべてチェックに失敗し、read_next_skill または complete_stage による進行がブロックされていました。修正方法: PR #1963（コミット 4de9467d、integration/shared-sandbox ブランチにマージ済み）を含むビルドにアップグレードしてください。この修正では、引用または要約されたフィードバックや、複数の学習者メッセージに分散した回答を受け入れる一方で、実際の返信、ステージ、アーティファクトバージョンのチェックは引き続き強制されます。

これは、生成されたHTMLに katex という文字列がすでに含まれている場合、postProcessInteractiveHtml（packages/@openmaic/generation/src/interactive-post-processor.ts 内）がKaTeXの auto-render スクリプトと MutationObserver の注入をスキップするために発生します。モデルが生成したページが独自の katex.min.js/katex.min.css を同梱している場合（よくあるケース）、自動レンダリングは一切インストールされず、\(...\) や $...$ が文字通りそのまま表示されます。サンドボックス化された about:srcdoc iframe内では、外部のCDNスクリプトを読み込めないため、ページ自身の renderMathInElement() 呼び出しも Uncaught ReferenceError: renderMathInElement is not defined で失敗します。障害モードは2つあります：(1) ページにKaTeXコアが含まれている場合、数式が一切レンダリングされない；(2) オブザーバーが初期レンダリングパスの後にインストールされるため、ページ自身の init() で埋められたラベルが初回ペイント時に生のまま残る。修正（PR #1606）：注入のガードを裸の katex 文字列ではなく auto-render/renderMathInElement に基づいて行う；KaTeXコアがすでに存在する場合は、不足しているauto-render contribスクリプトと MutationObserver のみを注入する；オブザーバーをインストールした後、約300msの安定化タイムアウト後に追加のレンダリングパスを1回実行し、さらに window の load でも実行して、init() で埋められたラベルが初回ペイント時にレンダリングされるようにする。

このエラーは、PBL v3 のバックグラウンドポーリングとティーチングツール(例:read_next_skill、request_skill_review、complete_stage)が同じ study に対して同時に touchEnvironment を呼び出した場合に発生します。この場合、2 回目の更新が環境アドバイザリロックの取得に失敗し、結果を記録する前に 409 を返します。**回避策:** もう一方の操作が完了してからティーチングアクションを再試行してください — 再試行は通常成功します。**恒久的な修正:** PR #1964 を含むビルド(integration/shared-sandbox 上のマージコミット 3446978c)にアップグレードしてください。この修正では、永続化された更新タイムスタンプを再読み取りし、ティーチングアクションを再実行せずに、5 秒の予算内で明示的な環境ロックの競合を再試行します。なお、この修正は v1.2.0-rc.2 の後に取り込まれたものであり、まだ main にマージされていない可能性があります。

パーサーが設定されていない場合、マテリアルは 'Parsing service unavailable' で失敗します。管理者はまずナレッジベース用のパーサーを設定し、次にナレッジベースページを開いて、失敗したマテリアルに対して 'Parse again' を使用して再試行する必要があります。長すぎることが原因で失敗したメディアについては、失敗理由に表示されている再生時間の上限を確認してください。会話をソースとするマテリアルには 'Parse again' の行アクションがないことに注意してください。ナレッジベースページから直接管理および再パースしてください。より明確な理由別の失敗ガイダンス、ローカライズされたビジネスエラーメッセージ（以前は英語のみ）、および修正された単数/複数形の文言（'1 materials' ではなく '1 material'）が PR #1923 でリリースされ、コミット 84a88bc4 としてマージされました。