Plan Gate 는 장식이 아니야

plan gate 는 방법과 전제가 보인 뒤 autonomous execution 이 제일 쓸모 있어서 존재해. author 는 diagnosis, intended targets, exclusions, approach, risk, proof 를 말해. requester 는 tool 이 잘못된 전제를 크고 일관된 실수로 만들기 전에 잡을 수 있어.

gate 는 작업 시작 뒤 쓰는 progress update 가 아니야. 뒤늦게 log 하면 timestamp 는 남고 control 은 사라져. 가능한 곳에서는 system 이 mutation 전에 stage 를 요구해야 하고, reviewer 는 final artifact 를 정확히 approved gate 와 비교해야 해.

approval 은 task name 하나가 아니라 premises 에 붙어. plan 이 clean destination 이나 shared file 교체 권한을 가정한다면 그걸 말해야 해. 나중 발견이 전제를 깨면 gate 를 다시 열어. autonomy 가 바뀐 premise 를 implicit approval 로 바꾸진 않아.

generic workshop 은 모든 분야 method 를 정할 수 없어. 그래도 책임 있는 plan 의 모양은 요구할 수 있어. 그걸로 충분해. task 는 content-specific judgment 를 소유하고, workshop 은 그 judgment 가 execution 전에 inspect 가능하게 만들어.

review 에 gate 를 그대로 인용해

approved gate 를 stage note 로 저장하고 reviewer request 에 verbatim 으로 넣어. author 가 더 깔끔한 회고 plan 을 내미는 걸 막고 reviewer 에게 scope drift 를 볼 stable contract 를 줘.

좋은 gate 는 짧아도 falsifiable 해야 해. “조심해서 구현”은 artifact 와 비교 못 해. “이 target 을 바꾸고, 이 exclusion 을 지키고, 이 proof 를 돌려”는 비교할 수 있어.

gate 는 artifact 를 바꾸는 결정을 기록해. compose 가 속도를 내기 전에 approved shape, boundaries, proof, unresolved trade-offs 를 이름 붙여야 해. “좋아 보여” 같은 decorative approval 로는 author 가 authority 안에 머물렀는지 나중에 판정할 수 없어.

Code

A falsifiable plan gate·json

{
  "diagnosis": "queued material is mutable after claim",
  "targets": ["mutation policy", "race test"],
  "exclusions": ["no storage migration", "no UI redesign"],
  "method": "enforce status under writer transaction",
  "proof": ["edit-before-take passes", "edit-after-take returns conflict"]
}

Plan Gate 는 장식이 아니야