pipeline 은 두 번째 engine 이 아니야
named pipeline 은 반복 task shape 가 existing engine 에 어떻게 들어올지 설명하는 policy row 야. name, title, description, brief template, required stages, review default, optional brain hint, version, archive state 정도가 core 를 이뤄. lifecycle code 를 복제하지 않아.
stable mechanic 과 changing craft 를 가르는 선택이야. claim, status transition, review round, attachment freeze, landing record 는 모든 task 에 같은 invariant 가 필요해서 code 로 남아. instruction 과 stage choice 는 운영자가 경험을 쌓으며 다듬어야 해서 data 가 돼.
data-driven 은 free-form 이 아니야. live Crucible 은 unique kebab-case name 과 비어 있지 않은 template 을 요구해. required_stages 는 빈 list 여도 괜찮지만, 들어 있는 각 stage name 은 빈 문자열이면 안 돼. review default 는 boolean 으로 받고 SQLite 에 0 또는 1로 저장한 뒤 다시 boolean 으로 돌려줘. default brain 은 advisory hint 로 둬. 아직 global stage vocabulary 를 소유하지 않으니 stage spelling 검토는 enforced invariant 가 아니라 operator 책임으로 남아 있어.
inspect 가능한 것도 장점이야. source 를 안 읽고 pipeline list 에서 version, review, stages, archive state 를 볼 수 있어. 아빠가 운영 표면에서 craft 를 직접 이해하고 바꿀 수 있지.
field 마다 행동을 붙여
field 하나씩 값을 바꿨을 때 brief, verify, compose 중 무엇이 달라지는지 써봐. 아무것도 안 바뀌면 decoration 이거나 자리를 잘못 잡았고, validation 을 우회하면 executable policy 경계를 넘어선 거야.
예를 들어 review_default 를 바꾸면 다음 compose 화면과 brief 가 달라져야 해. accent_color 를 바꿨는데 실행 계약이 달라지면 저장 층이 표현을 소유하고 있다는 냄새고. 반대로 required_stages 를 바꿨는데 verify 결과가 그대로면 행이 정책인 척만 하는 거야. field 마다 읽는 소비자와 실패 시험을 붙이면 schema 가 실제 제품 계약인지 바로 드러나.