評価境界と実行契約を先に置く

何が新しいか実行時間やRAM契約を入力に入れると、生成コードの構造と資源消費が変わる。

なぜ重要かCodexや分析workflowに、実行環境を先に明示する根拠になる。

読む観点memory_budget、time_budget、allowed_io、failure_policyをprompt contract化する。

何が新しいか評価ハーネスのreward-relevant eventsを有限状態モデルで監査する。

なぜ重要かagent評価では、採点経路そのものを守らないと結果を信用しにくい。

読む観点採点ファイル、参照可能ファイル、提出物、検証コマンドをfixtureに明記する。

何が新しいかrepo規模refactoring agentをtokens、diff、transcript、AST検証つきで評価する。

なぜ重要かCodex小タスクを、patchだけでなく再現可能な検証ログにできる。

読む観点本体導入ではなく、入力、制約、変更、テスト、判断ログを残す。

何が新しいか長期記憶poisoningを、書き込み、検索、利用をまたぐend-to-end問題として扱う。

なぜ重要か記憶の保存前フィルタだけでは、将来行動への影響を防ぎきれない。

読む観点外部コンテンツは永続方針へ自動昇格しない。

何が新しいか画像や音声内の指示が、認識、計画、tool callへ届く過程を測る。

なぜ重要か文書処理や画像入力つきプロンプト設計で、資料内指示を命令にしない境界が必要。

読む観点画像/PDF内の文字は、ユーザー命令ではなく処理対象データとして扱う。

何が新しいかA2A仕様準拠でも起こるcontext injection、identity loss、未検証capability claimを分析する。

なぜ重要かMCP tool安全性だけでなく、agent間委譲の信頼境界も必要になる。

読む観点caller_identity、delegated_by、capability_sourceを設計メモに残す。

何が新しいかLLM coding agentが、npm、PEP 440、Cargoのバージョン制約で系統的に失敗する。

なぜ重要か依存更新提案は説明だけでなく、実resolverで検証すべき。

読む観点dependency_constraint_fixtureを作り、LLM提案とpackage manager結果を比較する。

何が新しいか高性能モデルほど判断が相関し、共通誤情報下で市場リスクになり得る。

なぜ重要か投資系アプリでは、予測精度だけでなく同質化した誤判断を減らす必要がある。

読む観点強気/弱気根拠、情報源独立性、反証トリガーを記録する。

何が新しいか文章フィードバックを、作品固有で行動可能な助言へ寄せるreward設計。

なぜ重要かDaily Writingでは、たくさん直すより、次に直せる一観点が効く可能性がある。

読む観点本文根拠、最重要の一観点、次に直す一文を返す。

何が新しいか`ai@7.0.99`、`@ai-sdk/workflow@2.0.30` などのpatch releaseが確認できる。

なぜ重要かworkflow/gateway周辺の更新が続くため、LLMアプリではバージョン固定と差分確認が必要。

読む観点即更新ではなく、lockfile差分とsemver fixtureで確認する。