Blocker 와 Observation

review finding 은 action 가능할 만큼 구조가 필요해. classification, location, violated contract, consequence, proposed direction 이야. “좀 brittle 해 보여”는 대화를 시작할 수 있지만 landing 을 막진 못해. 무슨 proof 로 해결되는지 아무도 모르니까.

blocker 는 repair 하거나 명시적으로 stet 해야 하는 defect 야. wrong scope, false claim, broken behavior, missing acceptance evidence, safety failure, contract violation 같은 것들. observation 은 현재 task 를 무효로 만들진 않지만 값어치 있는 개선이나 risk 고. 둘을 섞으면 모든 제안이 위기가 되거나 모든 결함이 선택이 돼.

severity 는 model confidence score 가 아니야. reviewer 는 영향 큰 가능성에 확신이 낮을 수 있고 그 불확실성을 말해야 해. author 가 premise 를 검증하지. classification 은 참일 때 consequence 를 말하고, evidence strength 는 reviewer 가 truth 를 얼마나 세웠는지 말해.

location 은 촘촘해야 해. code 는 file 과 line 또는 symbol, document 는 section 과 claim, runtime behavior 는 private infrastructure 를 쏟지 않고 route 나 workflow 를 이름 대. precision 이 repair 를 줄이고 stet 을 review 가능하게 해.

claim 을 falsifiable 하게 만들어

blocker 마다 이렇게 다시 써. location X 에서 artifact 가 Y 를 말하거나 하고, contract 는 Z 를 요구하며, consequence 는 W 다. 그러면 author 가 reproduce, repair, 또는 premise 하나가 false 임을 증명할 수 있어.

즉시 repair 안 해도 observation 은 record 에 남겨. 현재 task 를 인질로 잡지 않으면서 future pipeline edit 나 dedicated product work 의 input 이 돼.

severity 는 거슬림이 아니라 consequence 를 따라가. blocker 는 artifact 를 false, unsafe, unrunnable, scope 밖으로 만들어. observation 은 landing 을 무효로 하지는 않지만 다음 개선에 값진 내용을 남겨. 이 선을 명시해야 quality 도 finish 할 능력도 함께 지킬 수 있어.

Code

A structured review finding·json

{
  "kind": "blocker",
  "location": "verification summary",
  "claim": "reports success without destination evidence",
  "contract": "task completion requires destination proof",
  "consequence": "a documented failure can land",
  "suggested_direction": "record and check the named acceptance evidence"
}

Blocker 와 Observation