현재 행은 한 주인에게서 읽어
pipeline 이 row 라면 CLI 와 UI 가 current state 를 볼 길이 필요해. 각 client 가 database 를 직접 읽으면 validation, archive, version rule 이 복사되고, startup snapshot 만 쓰면 edit 뒤 restart 전까지 낡은 policy 로 brief 를 만들 수 있어.
provider 는 persistence 와 validation 을 한곳에 두고 list, get, resolve 같은 좁은 interface 로 current row 를 내줘. client 는 table layout 을 모르고 contract 보다 오래 cache 하지 않아. canonical writer 하나가 mutation 을 소유하고 provider 가 같은 의미를 읽게 해야 해.
live catalog 와 frozen history 는 모순이 아니야. provider 는 오늘의 row version 을 주고, materialized brief 는 run 하나가 받은 당시 version 과 text 를 보존해. object 수명이 달라서 둘이 동시에 참일 수 있어.
thin client 도 제품 판단을 소유해. CLI 는 command grammar 와 human error 를, UI 는 form·sort·confirmation 을 정해. thin 이라는 말은 persistence semantics 를 위임한다는 뜻이지 아무 책임 없는 pass-through 라는 뜻이 아니야.
restart 없는 통합 시험
같은 process 에서 row 를 읽고 edit 하고 다시 읽어 새 version 이 보이는지 확인해. 동시에 edit 전에 materialize 한 brief 는 옛 version 을 지켜야 해. 이 assertion 둘이 liveness 와 history 를 따로 증명해.
cache 가 만드는 조용한 거짓말
UI 에서 review 기본값을 켰는데 같은 프로세스 CLI 가 여전히 꺼진 값으로 브리프를 만들면 둘 다 정상처럼 보여 더 위험해. 저장은 성공했고 화면도 맞지만 실행 재료가 낡았거든. provider 시험은 수정 직후 같은 프로세스에서 읽는 경로를 꼭 포함해야 해. 동시에 이미 taken 된 브리프는 바뀌지 않아야 하고. live 와 frozen 을 한 assertion 에 섞지 말고 서로 다른 수명의 객체 둘로 확인해야 실패 원인이 선명해져.