문제
복구나 인수인계 과정에서 같은 결과물을 두 담당이 번갈아 다룰 수 있다. 이때 "공개가 끝났으니 알림도 끝났겠지"라고 넘겨짚으면, 이미 다른 담당이 보낸 채널에 같은 소식을 또 보내게 된다. 받는 사람 입장에서는 중복 알림이며, 신뢰도만 떨어뜨린다.
운영 패턴
1. 전송하기 전에 항목과 채널을 짝으로 하는 원장을 먼저 읽는다. 이미 sent 상태인 짝은 다시 보내지 않는다.
2. 원장에 오늘 날짜의 행이 없다고 해서 곧바로 "아무도 안 보냈다"로 단정하지 않는다. 다른 담당이 아직 원장에 기록하지 않았을 수도 있으므로, 실제 채널 최근 메시지를 함께 확인한다.
3. 배포 소유권이 다른 담당에게 있다고 알고 있다면, 그 담당이 실제로 원장을 채웠는지 확인될 때까지 대신 보내지 않는다. 대신 "배포 소유자 확인 대기"로 상태를 남긴다.
4. 확인이 애매하면 침묵보다 명시적 보류가 낫다. 왜 안 보냈는지, 무엇이 확인되면 보낼 것인지 기록에 남긴다.
5. 정말로 새로 보낸 경우에만 원장에 sent 행을 추가하고, 그 항목-채널 짝이 이전에 없었다는 사실도 함께 남긴다.
왜 중요한가
배포 소유권 경계가 흐려지면 두 가지 실패 중 하나가 일어난다: 아무도 안 보내서 공지가 빠지거나, 둘 다 보내서 중복이 생긴다. 둘 다 신뢰를 깎는다. 원장을 먼저 읽는 습관은 이 두 실패를 모두 막는 가장 값싼 방법이다.
완료 기준
전송 여부를 판단하기 전에 원장과 실제 채널 상태를 모두 확인했고, 애매한 경우 보류 사유를 남겼으며, 다른 담당이 소유한 전송을 대신 하지 않았으면 완료다.
Problem
During recovery or handoff, more than one owner can end up touching the same deliverable. Assuming "publication is done, so notification must be done too" leads to sending the same news again to a channel someone else already reached. To the recipient this is just a duplicate notice, and it only erodes trust.
Operating pattern
1. Before sending, read the ledger keyed by (item, channel) pair first. Never resend a pair already marked sent.
2. The absence of today's date in the ledger does not by itself mean "nobody sent it yet." Another owner may not have recorded it there yet, so also check the channel's recent messages directly.
3. If distribution ownership is known to belong to a different owner, do not send on their behalf until it is confirmed they actually populated the ledger. Instead, record the state as "awaiting distribution-owner confirmation."
4. When it is genuinely ambiguous, explicit hold beats silence. Write down why nothing was sent and what confirmation would unblock it.
5. Only when a send genuinely happened for the first time, append the sent row and also note that the (item, channel) pair had no prior entry.
Why it matters
A blurred distribution-ownership boundary produces one of two failures: nobody sends and the notice is missing, or both owners send and it duplicates. Both cost trust. Reading the ledger first is the cheapest way to prevent both.
Completion bar
Completion means both the ledger and the live channel state were checked before deciding to send, an ambiguous case was recorded with its hold reason, and no send was made on behalf of an owner who already holds that responsibility.
问题
在恢复或交接过程中，同一交付物可能被多个负责人先后经手。若想当然地认为“既然已经发布，通知也一定完成了”，就会向别人已经发送过的渠道再次发送同样的消息。对接收者来说这只是重复通知，只会削弱信任。
运行模式
1. 发送前先读取以（条目, 渠道）为键的账本。已经标记为 sent 的组合，绝不再次发送。
2. 账本里没有今天日期的行，并不能直接推断出“没人发过”。另一位负责人可能还没来得及记录，因此也要直接查看该渠道最近的消息。
3. 如果已知分发的所有权属于另一位负责人，就不要替他们发送，除非确认他们确实已经填写了账本。此时应记录状态为“等待分发负责人确认”。
4. 当情况确实模糊时，明确暂停比沉默更好。记下为什么没有发送，以及什么样的确认能解除阻塞。
5. 只有在真正是第一次发送时才追加 sent 行，并同时说明该（条目, 渠道）组合此前没有记录。
为什么重要
分发所有权边界一旦模糊，就会出现两种失败之一：谁都没发，通知缺失；或者两边都发了，造成重复。两者都会损耗信任。先读账本是同时防止这两种失败中最廉价的办法。
完成标准
在决定是否发送之前同时核对了账本和渠道的实际状态，对模糊情形记录了暂停原因，且没有替已经拥有该责任的负责人代为发送，就算完成。
問題
復旧や引き継ぎの過程で、同じ成果物を複数の担当者が入れ替わりで扱うことがある。「公開が終わったのだから通知も終わっているはずだ」と決めつけると、既に他の担当者が届けたチャンネルへ同じ知らせを再送してしまう。受け手にとってはただの重複通知であり、信頼を下げるだけである。
運用パターン
1. 送信前に、まず（項目, チャンネル）の組を鍵とする台帳を読む。既に sent と記録された組は絶対に再送しない。
2. 台帳に今日の日付の行が無いからといって、そのまま「誰も送っていない」と断定しない。別の担当者がまだ台帳に記録していない可能性があるため、チャンネルの直近のメッセージも直接確認する。
3. 配信の所有権が別の担当者にあると分かっている場合、その担当者が実際に台帳を埋めたと確認できるまで代わりに送らない。代わりに状態を「配信担当者の確認待ち」として記録する。
4. 本当に判断がつかない場合は、沈黙より明示的な保留の方がよい。なぜ送らなかったか、何が確認できれば送るかを記録に残す。
5. 本当に今回初めて送信した場合のみ台帳に sent 行を追加し、その（項目, チャンネル）の組に以前記録が無かったことも併せて残す。
なぜ重要か
配信の所有権境界が曖昧になると、二つの失敗のどちらかが起きる。誰も送らずに通知が欠落するか、両方が送って重複するかだ。どちらも信頼を損なう。台帳を先に読む習慣は、この両方を防ぐ最も安価な方法である。
完了基準
送信するかどうかを判断する前に台帳とチャンネルの実際の状態の両方を確認し、曖昧な場合は保留理由を記録し、既にその責任を持つ担当者の代わりに送信していなければ完了である。