Row 로 충분할 때

named row 는 task shape 차이를 existing engine 이 이미 enforce 할 줄 아는 policy 로 표현할 수 있을 때 충분해. template 는 instruction, required stages 는 proof boundary, review default 는 평소 scrutiny 를 표현하고, hint 는 authority 를 바꾸지 않고 launch 를 낫게 해.

row 는 inspect, version, archive, compare 비용이 작아. operator 를 queue 하나와 record system 하나 안에 둬. 그 경제성이 중요해. 새 application 마다 runtime ownership, deployment, UI maintenance, health check, documentation, state 가 갈라질 자리 하나가 더 생기거든.

긴 instruction 을 product pressure 로 착각하지 마. long template 도 recurring task 하나를 설명하면 row 에 맞을 수 있어. 더 강한 graduation signal 은 new lifecycle state, durable domain entity, specialized material rule, interactive workflow, generic engine 이 표현 못 하는 verification semantics 야.

high stakes 하나만으로 app 이 필요한 것도 아니야. strict review default 와 추가 required stages 가 드물지만 민감한 task 를 안전하게 실을 수 있어. generic contract 가 거짓이거나 비틀릴 때만 software 를 낳아.

row-fit 질문을 써

모든 차이가 template, known stages, review policy, hint 로 표현되는지, destination 이 task-owned 로 남는지, existing record 가 work 를 설명하는지 물어. 전부 yes 면 row 를 지켜.

충분해 보이려고 row 가 arbitrary code 를 호출하면 안 돼. lifecycle 곳곳에 product-specific executable hook 이 필요해지는 순간 configuration 안에 application 을 숨긴 거야.

variation 을 bounded input 으로 표현할 수 있는 동안은 row 로 남아. hidden branch 없이 template 하나, stage vocabulary, review policy, landing receipt 로 일을 운반할 수 있다면 configuration 이 충분해. 이때 새 app 을 만들지 않아야 fix 와 audit rule 도 shared kernel 에 계속 모여.

Code

Use capability questions instead of a prestige score·python

needs = {
    "new_lifecycle_states": False,
    "durable_domain_entities": False,
    "specialized_material_policy": False,
    "custom_interactive_workflow": False,
}
row_is_enough = not any(needs.values())
assert row_is_enough
print("keep the named pipeline row")

Row 로 충분할 때