Score 말고 Artifact 를 고쳐

review 는 reviewer 에 맞춰 최적화하고 싶은 압력을 만들어. review 가 task contract 를 가리킬 때만 쓸모 있어. model 이 말 안 하게 하려고 prose 나 code 를 바꾸기 시작하면 artifact 는 destination 을 위해 좋아지는 게 아니라 계기 하나에 튜닝돼.

valid repair 는 artifact 를 바꾸고 defect 를 드러낸 evidence 를 다시 돌려. 그리고 새 change 가 다른 issue 를 만들 수 있으니 fresh review 를 받아. 마지막 review 뒤 edit 하고 옛 verdict 를 유지하면 provenance drift 야. review 받은 object 가 더는 존재하지 않거든.

finding count 를 quality score 로 쓰지 마. 큰 artifact 의 precise blocker 열 개가 작은 artifact 의 vague comment 하나보다 더 강한 결과를 만들 수 있어. count 는 disposition reconcile 에 쓰지 author, brain, artifact 순위에 쓰는 게 아니야.

repair 는 scoped 로 남아야 해. reviewer 가 adjacent debt 를 볼 수 있어. approved gate 를 만족하는 데 필요 없으면 observation 이나 new task 로 기록해. review 마다 cleanup 으로 키우면 authority 가 넓어지고 landing 을 추론할 수 없게 돼.

reproduction 을 수리해

accepted blocker 마다 smallest reproducer 를 지키고, scoped change 를 하고, reproducer 를 다시 돌리고, 결과를 note 해. 그다음 independent reviewer 에게 author 가 쓴 diff summary 말고 current artifact 를 inspect 하게 해.

reconciliation table 은 raised, repaired, stetted, remaining finding 을 셀 수 있어. 목적은 completeness 야. claim 마다 disposition 이 있는지 보는 거지 leaderboard 가 아니야.

repair 는 artifact 가 진실을 말하게 됐을 때 끝나. defect 를 만든 가장 작은 responsible surface 를 고치고, 문제를 드러낸 evidence 를 다시 돌린 뒤 fresh reviewer 에게 결과를 보여줘. 작업은 그대로인데 count 만 낮추는 건 scoreboard 편집이지 revision 이 아니야.

Code

Reconcile finding dispositions without scoring quality·python

findings = [
    {"id": "R1", "status": "repaired"},
    {"id": "R2", "status": "stetted"},
    {"id": "R3", "status": "repaired"},
]
allowed = {"repaired", "stetted"}
remaining = [f for f in findings if f["status"] not in allowed]
assert not remaining
print({s: sum(f["status"] == s for f in findings) for s in allowed})

Score 말고 Artifact 를 고쳐