"계산 못 하는 경계는, 없는 경계야."
한 단계만, cwk 로 시작하는 것만, 지원 소스는 제외
'가족'을 관리하는 허브한테는 '누가 가족이냐'에 대한 딱 떨어지는 답이 있어야 해. Firelink 의 답은 일부러 좁아. 한 프로젝트 디렉터리 바로 밑에 있고 이름이 cwk 로 시작하는 자식들, 딱 한 단계만 훑어. 이름이 조건에 맞더라도 지원 repository 인 cwkFamilyAppBirthTemplate 은 명시적으로 제외해. 안에 또 들어앉은 repository, 옆에 있는 비-cwk 폴더, roster 문서가 말로만 언급한 '조상'이나 '인접 repo' 도 자격이 없어.
너무 단순해 보이지? 그게 핵심이야. 루프로 돌릴 수 있는 규칙은 흔들리지 않거든. 멤버십이 사람 판단에 기대는 순간 — '음, 저건 좀 쳐줘야 하나' — census 는 매번 같은 답을 못 내놓고, 허브는 자기가 뭘 관리하는지부터 거짓말하기 시작해.
글로 적었다고 멤버가 되진 않아
Firelink 는 roster 랑 network 문서를 읽어서 멤버에 제목, 한 줄 설명, lifecycle 을 덧입혀. 근데 그 문서엔 사람 보라고 쓴 계보 얘기, '조상', '인접 repo' 같은 절도 섞여 있어. 여기 규칙이 하나 있어. 그 글은 관리 대상을 절대 못 넓혀. 직계 프로젝트 밖에 앉은 roster 항목은 그냥 참고 자료야. drift 도 아니고, 카드도 아니고, 맞춰볼 대상도 아니야. 경계를 정하는 건 프로젝트 루트고, 문서는 그 안쪽을 꾸밀 뿐이야.
Birth 가 멤버를 만들고, 템플릿은 멤버가 아니야
Firelink Birth 는 cwkFamilyAppBirthTemplate 을 plan 전용 staging 공간으로 복사하고, 새 앱의 정체성과 계약을 materialize 한 다음, 비공개 Git repository 를 초기화해서 push 해. 마지막에는 완성된 shell 을 프로젝트 디렉터리의 새 직계 자식으로 publish 하지. 템플릿은 계속 지원 소스로 남고 가족 카드에는 나타나지 않아. 새 앱이 census 에 들어오는 이유는 publish 된 목적지가 멤버십 규칙을 만족해서야. 원본 템플릿이나 문서가 등록해줘서가 아니고.