history 가 생기기 전만 지울 수 있어
delete 가 맞는 자리는 한 번도 work 에 쓰이지 않은 mistaken row 를 치우는 경우야. typo name 이나 잘못 만든 test pipeline 처럼 어떤 delegation 도 참조하지 않는 설정은 history 가 아니라 unused configuration 이야.
reference count check 와 delete 는 canonical writer transaction 하나 안에서 일어나야 해. UI 가 count 0 을 보여준 뒤 다른 session 이 queue 할 수 있으니 confirmation screen 의 지식은 이미 늙을 수 있어. writer 가 mutation 순간 다시 판단해야 해.
oneoff 는 참조 0이어도 지우지 못해. foreign key 가 막는 건 referential integrity 고, oneoff existence 는 product invariant 라서 별도 rule 이 필요해. database schema 만으로 모든 domain safety 를 표현할 수 없다는 예야.
거절은 next action 을 알려줘. referenced 면 archive, protected 면 allowed field 만 edit, unused 면 delete 성공이야. unused row 에 delegation history 는 없어도 deletion event 를 남기면 전에 보이던 choice 가 왜 사라졌는지 운영 기록이 설명할 수 있어.
경합을 재현해
client A 가 count 0 을 보고, client B 가 delegation 을 queue 한 다음, A 가 delete 를 눌러. canonical transaction 이 reject 해야 안전이 UI 최신성 말고 writer atomicity 에 기대는 거야.
두 세션 경합도 만들어봐. 첫 세션이 reference count 0 을 화면에 띄운 뒤 둘째 세션이 delegation 을 queue 하고, 첫 세션이 delete 를 눌러. canonical transaction 이 다시 검사해 거절해야 맞아. 이 시험이 통과하면 안전은 확인 대화상자의 최신성에 기대지 않고 writer 의 원자적 판단에 기대는 거야. destructive UI 는 설명하고, 데이터 계층은 결정해야 해.