upsert / set のように渡された値でコレクションやフィールドを丸ごと置き換える書き込み操作は、対になる読み取り（get / list）が、その全置換で必須になるフィールドを エージェント（クライアント）が実際に消費する出力面すべて に描画していないと、既存値を見ないまま空・推測値で全置換し、無自覚にデータを消す。書き込み側の省略セマンティクス（省略＝維持か省略＝クリアか）とは別軸で、こちらは「読み取り側にそもそも現在値が見えるか」という可視性の対称性の問題。

つまずきの型

• 読み取りツールが 2 系統の出力を返すとき（例: 人間可読の整形テキストと、機械可読の構造化データの両方を返す種類の API/ツール）、あるフィールドが片方の面にしか出ていないと、もう片方だけを読むクライアントからは「そのフィールドが存在しない」ように見える。
• 消費側は見えないフィールドを再構成できず、値を推測する・ユーザーに尋ねる・空のまま送る、のいずれかに倒れる。そこへ全置換の書き込みが走ると、実際には存在していた既存値が上書きで失われる。
• 症状として「read の応答にこの項目が無いので既存値を読めなかった」という報告や、書き込み時に片方の面だけ見て組み立てたペイロードでの意図しない消失が出る。

判断基準

• 全置換（丸ごと差し替え）の書き込みを設計・レビューするときは、そのペイロードでラウンドトリップに必須となるフィールド集合を洗い出し、対になる読み取りの 各消費チャンネルごとに それらが漏れなく出ているかを確認する。必須全置換フィールドの集合は、各チャンネルが描画するフィールド集合の部分集合でなければならない。
• 片方の面（整形テキスト等）にだけ出ていない必須フィールドが 1 つでもあれば、それがラウンドトリップの穴になる。全チャンネルに出すか、当該フィールドを「省略＝既存維持」の部分更新セマンティクスに変えて全置換の対象から外す、のどちらかで塞ぐ。
• どの面が実際に読まれるかはクライアント/ハーネス依存で一定しない前提に立つ。「構造化データには含めてある」は、テキスト面しか見ない消費者には届かないので免罪符にしない。

検証

読み取りツールの各出力チャンネルを個別に開き、そのチャンネルだけを情報源にして書き込みペイロードを再構成できるかを試す。再構成に必要なフィールドが欠ける面があれば、そのチャンネル経由の消費者は全置換で当該フィールドを失う。ラウンドトリップ（読む→そのまま書き戻す→値が保存される）を面ごとに再現して確認する。