画像、動画、音楽、音声、テキストを生成できる製品なら、そのどれについても報告できなければなりません。ほとんど、ではなく、どれについても。
ボタンは一部の画面にはありました。それは別物で、その差は見落としやすいものです。コンテンツの検査はパイプラインごとに手作業でつながれていたため、二つのスタジオはまったく検査なしで出荷され、監査が見に行くまで誰も気づきませんでした。同じ形は、この修正も忘れられた画面から一つずつ食い潰していたはずです。
すべての画面と、それを保証する検査
いまは報告の操作が、チャットの返信、画像、動画、音楽、音声、音声認識、読み上げ、翻訳、キャンバスの成果物、ワークフローの結果、アシスタントのバブル、公開共有ページに付いています。ウェブでもアプリでも同じです。
より重要なのは、ビルドごとに検査が走ることです。生成のインターフェースを取り込むファイルは、報告の操作を描くか、それを持つ部品に委ねるか、読み手が確かめられる理由を添えた例外を持つか、そのいずれかでなければなりません。最初の実行で本物の欠落を六件報告しました。この作業はそれを塞いだものです。
その後、オーナーが動いているアプリを開き、検査には見えなかった五件をさらに見つけました。検査が一度も開かないフォルダーにあったからです。これは問題のより厄介な半分で——一度も読んでいないコードの脇を通りながらゼロと報告する見張り——だからこそ検査はいま自分の探索範囲を明示し、そのどれかが解決しなくなったら失敗します。
一つのキューと、行の上での操作
共有ページには以前から報告の操作があり、何も読まないテーブルに書き込んでいました。読み手も、キューの項目も、通知もありません。その報告はいま本物の案件も開き、確認する人が必要とする本文をそのまま凍結して隣に置きます。
そして操作が別のページにあるキューは、やがて処理されなくなるキューです。内容を隠す、報告を終了する。それが行の上でできるようになり、結果は書き戻されるので、同じ話を蒸し返す必要がありません。