Queued 는 바뀌고 Taken 은 못 바뀌어

take 가 material ownership 을 넘겨

queued 상태는 아직 intake 야. requester 가 typo 를 고치고 attachment 를 갈고 brain hint 를 바꾸거나 delegation 을 거둘 수 있어. executor 가 premises 를 받기 전이라 mutation 이 정당해.

take 순간 live session 이 package 를 받아. 그때부터 brief 와 manifest 는 그 session 이 무엇을 허가받았는지 보여주는 evidence 야. notes 나 bytes 를 뒤에서 바꾸면 author 가 본 history 와 database 가 봤다고 주장하는 history 둘이 생겨.

rule 은 UI 편의가 아니라 engine 구조에 있어야 해. mutation endpoint 가 status 를 writer transaction 안에서 확인하고 taken, landed, abandoned 에는 conflict 를 돌려. stale tab 과 direct client 도 같은 거절을 받아야 해.

take 뒤 correction 은 visible transition 으로 처리해. abandon 후 requeue 하거나 original 에 연결된 superseding delegation 을 만들어. 원래 package 는 그대로 남아야 reviewer 가 왜 첫 work 가 멈췄는지 설명할 수 있어.

race 를 시험해

edit 와 take 를 barrier 뒤에서 동시에 시작해 정확히 하나만 성공하게 해. 성공한 take 뒤 material digest 가 안정적인지도 확인해. sequential happy path 로는 freeze boundary 를 증명 못 해.

take 는 draft 와 evidence 사이의 경계야. queued order 는 아직 실행 owner 가 없으니 고칠 수 있어. claim 뒤에 내용을 바꾸면 active author 발밑의 instruction 이 달라져. 그때 필요한 건 silent edit 가 아니라 이유가 남는 replacement, abandon, 또는 new delegation 이야.

UI 가 버튼을 껐다는 캡처만으로는 이 불변식을 증명 못 해. stale client 가 같은 endpoint 를 직접 부르는 시험까지 통과해야 take 가 진짜 freeze boundary 가 돼.

recovery path 도 같은 원칙을 따라. administrative release 가 필요하면 original claim owner, release reason, next session 을 event 로 남기고 package byte 는 건드리지 않아야 해.

Code

Make mutation conditional on lifecycle state·python

def edit_material(delegation: dict, replacement: str) -> None:
    if delegation["status"] != "queued":
        raise RuntimeError(f"material frozen at {delegation['status']}")
    delegation["material"] = replacement

d = {"status": "queued", "material": "v1"}
edit_material(d, "v2")
d["status"] = "taken"
try:
    edit_material(d, "v3")
except RuntimeError as exc:
    print(exc)
assert d["material"] == "v2"

take 가 material ownership 을 넘겨

race 를 시험해

Code

External links

Exercise

Progress

댓글 0