Verify 는 Contract 를 읽어

verification 은 recorded work 가 pipeline policy 를 만나는 지점이야. required stage 가 전부 있는지, claim 이 landing session 것인지, review obligation 이 만족됐는지, landing summary 가 있는지 검사해. author 기억 말고 canonical row data 에서 요구를 뽑아야 해.

stage 가 sequence 를 표현하면 order 가 중요해. compose 뒤 log 한 plan gate 는 mutation 전 gate 와 같지 않아. verifier 는 timestamp 나 event order 와 허용 sequence 를 이름 댄 contract 가 필요해. set 이 완전해도 workflow 는 깨져 있을 수 있어.

verification 은 structural gate 와 domain acceptance 도 가른다. workshop trail 이 완전한 건 자기가 증명해. deliverable 은 task 자체 evidence 가 증명하고. landing decision 이 둘을 만나게 하되 실패를 주인별로 보고해야지 green badge 하나로 뭉개면 안 돼.

current-row verifier 는 의도적으로 in-flight work 를 더 세게 만들 수 있어. 그게 제품 선택이면 output 이 effective row version 과 missing stage 를 분명히 보여야 해. policy identity 없이 “verification failed”만 던지면 live policy 가 운영상 적대적으로 변해.

거절마다 이유를 말해

gate 마다 missing 또는 misordered stage, 그걸 요구한 policy version, 다음 valid action 을 돌려줘. verifier 는 assertion dump 가 아니라 제품 surface 야.

complete-but-misordered trail, tightened live policy 아래 stale brief, wrong-session landing, commit 없는 non-code task 를 시험해. 이 case 들이 happy path 말고 contract 를 증명해.

verify 는 land 할 permission 을 다시 계산해. frozen work order, required stages, current artifact, review disposition 을 함께 읽고 관계가 어긋나면 거절해야 해. green unit test 나 polished source file 은 좋은 evidence 지만 run 이 선언한 contract 를 대신하지는 못해.

Code

Verify stage membership and order·python

required = ["plan-gate", "work", "review"]
events = ["plan-gate", "work", "review"]

def verify(required: list[str], events: list[str]) -> None:
    positions = {name: events.index(name) for name in required if name in events}
    missing = [name for name in required if name not in positions]
    if missing:
        raise RuntimeError(f"missing stages: {missing}")
    if [positions[name] for name in required] != sorted(positions.values()):
        raise RuntimeError("stages are out of order")

verify(required, events)
print("workflow contract satisfied")

Verify 는 Contract 를 읽어