두 번째 사용 시험

두 번째 발생은 recurrence 를 상상하지 않고 관찰할 수 있는 첫 순간이야. oneoff record 둘을 나란히 둬. scope shape, repeated instruction, required stage, review policy, destination kind, evidence, failure mode 를 비교해. 둘 사이에서 stable 한 것만 promote 해.

우연한 명사를 일반화하지 마. task 둘이 invoice 를 다뤄도 하나는 file repair 고 다른 하나는 vendor process 조사일 수 있어. 반대로 명사가 다른 task 가 같은 evidence-audit shape 를 공유할 수도 있고. reusable unit 은 topic label 이 아니라 behavior 와 proof 야.

첫 notes 가 어디서 길었는지 봐. 반복 설명은 named template 후보야. stage 가 어디서 달랐는지도 봐. 그 차이는 optional policy 일 수도 있고 shape 둘이 pipeline 하나가 아니라는 증거일 수도 있어. review observation 이 author 가 못 본 common craft 를 드러낼 수 있고.

second-use rule 은 threshold 지 automatic promotion 이 아니야. 발생 둘은 비교를 가능하게 하지 stable intersection 을 보장하지 않아. 공통 부분이 “조심해서 일해”뿐이면 둘 다 oneoff 로 둬.

work order 를 diff 해

premises, method guidance, stages, review, destination, proof 행이 있는 표를 만들어. exact shared behavior, task-specific detail, unresolved difference 를 표시해. 첫 column 만 pipeline row 에 들어가.

row draft 뒤 historical task 둘을 머릿속으로 replay 해. 어느 한쪽이라도 자기 이름을 댄 exception sentence 가 필요하면 proposed pipeline 이 너무 넓거나 shared shape 가 아직 안 익은 거야.

promotion 에는 단순한 횟수가 아니라 비교 가능한 evidence 가 필요해. 두 task 에서 instance detail 을 걷어낸 뒤에도 shared instruction, gate, proof shape 가 남아야 named row 를 만들 근거가 돼. 여러 번 일어났어도 stable seam 이 없다면 여전히 정직한 oneoff 들의 연속이야.

Code

Find the stable intersection of two oneoff records·python

first = {"stages": ("plan-gate", "review"), "proof": "served-check", "topic": "links"}
second = {"stages": ("plan-gate", "review"), "proof": "served-check", "topic": "images"}
shared = {k: first[k] for k in first.keys() & second if first[k] == second[k]}
assert shared == {"stages": ("plan-gate", "review"), "proof": "served-check"}
print(shared)

두 번째 사용 시험