queue는 cron이 아니야

두 runtime 사이의 빈자리

짧은 fragment rewrite는 request-response light lane에서 끝날 수 있어. 하지만 vault 여러 note를 읽고 Dad와 disposition을 정하고 index까지 reconcile하는 일은 Web UI connection과 agent turn lifetime을 넘어가.

그렇다고 scheduler에 넘기면 안 돼. 오래 걸린다는 사실이 자동 판단의 근거는 아니야. queue는 자동 시작 대신 work order를 durable하게 보관하고, Dad와 함께 있는 live terminal session이 take할 때만 실행돼.

queued는 approved가 아니야

task row가 있다는 건 할 일이 concretized됐다는 뜻이지 plan이 승인됐다는 뜻은 아니야. take 뒤 survey나 diag가 현재 source를 읽고 plan gate에서 scope와 verdict vocabulary와 open tradeoff를 Dad에게 보여줘.

승인 전엔 source를 바꾸지 않고, 승인 뒤엔 per-fragment permission을 다시 묻지 않으며 bounded scope 안에서 자율로 진행해. 비싼 대화는 모양을 바꾸기 싼 지점에 한 번 둔다.

engine은 기록자야

queue engine은 content를 쓰지 않아. delegation, claim, stages, base, checkpoint, land, release를 기록하고 어느 session이 무엇을 했는지 연결해. brain은 자연스러운 tool로 source를 편집하지만 record 없는 work는 landing gate를 통과하지 못해.

UI와 CLI도 engine database를 직접 만지는 별도 writer가 아니야. API client로 같은 single writer를 사용해야 claim race와 half-updated row가 줄어.

dispatch도 state transition이 아니야

native launcher가 task prompt를 열었다고 taken이 되면 창만 열고 실행하지 않은 작업이 active claim을 잡아먹어. launch ticket과 open attempt는 audit event일 뿐이고 실제 session이 take command를 보낼 때 상태가 바뀌어.

이 구별은 failure recovery를 단순하게 해. app launch가 실패하거나 사용자가 창을 닫아도 delegation은 queued로 남고 다른 session이 다시 dispatch할 수 있어.

queue는 시간을 예약하는 장치가 아니라 책임 있는 session에 scoped work를 인계하는 durable record야. 자동 시작과 판단을 빼고 claim·stage·evidence를 남겨.

Code

launch와 take를 다른 state로 모델링하기·python

task = {"status": "queued", "launch_attempts": 0}

def launch(task):
    task["launch_attempts"] += 1
    return "ticket-issued"

def take(task, session):
    assert task["status"] == "queued"
    task.update(status="taken", session=session)

assert launch(task) == "ticket-issued"
assert task["status"] == "queued"
take(task, "session-1")
assert task["status"] == "taken"

두 runtime 사이의 빈자리

queued는 approved가 아니야

engine은 기록자야

dispatch도 state transition이 아니야

Code

External links

Exercise

Progress

댓글 0