미래에 Version 을 붙여

pipeline 편집은 이전 세션이 받은 글을 다시 쓰지 않으면서 미래 작업을 더 좋게 해야 해. row version 이 오르고, live catalog 가 수정값을 보이고, 다음 brief 가 새 version 을 찍어. 과거 brief 는 물질화된 template 와 version 을 지켜서 review 가 저자의 전제를 복구하게 해.

간단한 문장 안에 수명 둘이 숨어 있어. brief text 는 snapshot 이야. 반면 engine 이 verify 때 current row 를 의도적으로 읽는다면 운영 gate 는 live policy 일 수 있어. 작업장은 이 차이를 말해야 해. 어떤 field 가 어는지 안 밝히고 “taken work 는 frozen”이라고만 하면 거짓 안심을 줘.

완전 frozen policy 는 required stages 와 review 요구를 delegation 안에 복사해. live-policy 설계는 운영자가 이미 진행 중인 작업의 gate 를 더 세게 만들 수 있고. 어느 쪽도 항상 맞진 않아. 선택이 명시적이고, 시험 가능하고, landing record 에 보여야 한다는 게 핵심이야.

오늘 Crucible 은 집필된 brief snapshot 을 지키면서 current required stages 가 verify 에 참여할 수 있어. 손 흔들고 넘길 우연이 아니라 계약 이음새로 가르쳐야 해. 나중에 더 많은 policy 를 얼리더라도, 이력은 brief version 과 착지 때 적용된 gate policy 를 둘 다 식별해야 해.

수명 둘 다 찍어

brief 를 물질화한 row version 과 착지에서 검사한 effective policy 를 기록해. 둘이 다르면 timestamp 하나가 다 설명하는 척하지 말고 흔적에 보이게 해.

편집 시험에는 in-flight delegation 이 필요해. version 1 에서 take 하고, version 2 로 고친 다음, 뭐가 그대로고 뭐가 바뀌는지 assertion 해. 중간 상태가 없으면 생성만 증명하고 생애주기 모호함은 못 잡아.

version change 는 과거 기록이 아니라 future intake 를 다스려. take 할 때 row version 과 rendered brief 를 stamp 하고, live policy 가 바뀌어도 그 snapshot 은 보존해. verify 가 명시적으로 current gate 를 읽는 seam 은 있을 수 있어. 다만 모든 input 이 함께 얼었다고 뭉개지 말고 어느 값이 current 인지 이름을 붙여야 해.

Code

Model snapshot text and live landing policy separately·python

brief = {"pipeline_version": 1, "text": "Run plan gate"}
current_row = {"version": 2, "required_stages": ["plan-gate", "review"]}
logged = {"plan-gate", "review"}

assert brief["pipeline_version"] == 1
assert set(current_row["required_stages"]) <= logged
print({"brief_version": 1, "landing_policy_version": 2})

미래에 Version 을 붙여