load-protocols.js의 프로토콜/유틸리티 판별이 하드코딩 배열의 보수 관계뿐 — 등록 누락이 무증상 면제가 된다

[jongwony]

관찰

scripts/load-protocols.js:201-202

isProtocol: protocolNodeSet.has(pluginDir),
isUtility: !protocolNodeSet.has(pluginDir),

protocolNodeSet(:146)은 CANONICAL_PROTOCOL_SET(:41-45)에서 만들어지고, 그 집합은 CANONICAL_PRECEDENCE(:30-34)의 소문자화 + anamnesis + katalepsis다. 즉 프로토콜 여부는 하드코딩 배열의 원소인지로만 결정되고, 유틸리티는 그 여집합으로 정의된다. 제3의 상태가 없다.

귀결

새 프로토콜 디렉터리를 추가하고 CANONICAL_PRECEDENCE에 등록하지 않으면 isUtility: true가 된다. isProtocol 필터를 통과해야 하는 검사(:218, :223 경유)들이 그 디렉터리를 말없이 건너뛴다. 실패가 아니라 무증상 면제라서 검사 결과는 초록으로 남는다.

docs/co-change.md의 "New protocol added" 행이 CANONICAL_PRECEDENCE 갱신을 요구하지만, 그 표는 강제 채널이 없는 손유지 문서다 (#764).

미해결 — 수정 기준

구조적 판별식으로 대체하려 했으나 후보 하나가 실패했다. MORPHISM 블록 보유 여부는 판별식이 되지 못한다: 모든 핵심 프로토콜이 보유하지만 유틸리티 중 misuse, probe, realign, steer도 보유한다.

후보 방향:

1. 3상태화 — protocol / utility / 미분류로 넓히고 미분류를 명시 실패로 올린다. 판별식을 찾지 않아도 침묵만은 없앤다.
2. 등록 누락 전용 검사 — 플러그인 디렉터리 집합과 CANONICAL_PROTOCOL_SET의 차집합이 알려진 유틸리티 목록과 일치하는지 검사한다. 유틸리티 목록도 손유지가 되므로 문제를 한 칸 옮기는 것에 가깝다.
3. 구조적 판별식 재설계 — 프로토콜만 가지는 형식 블록 조합을 찾는다. 위 실패는 단일 블록으로는 안 된다는 것만 보여줬을 뿐, 조합 판별식은 아직 시도되지 않았다.

1번이 가장 싸고, 판별식 문제를 열어둔 채로도 침묵을 없앤다.

[jongwony]

Addendum — 무증상 면제의 실제 사례: epistemic-cooperative가 언어 렌더링 규약 밖에 있습니다

이 이슈가 이름한 모양은 하드코딩 배열의 여집합으로 유틸리티가 정의되므로, 등록되지 않은 디렉터리가 실패가 아니라 무증상 면제가 된다는 것입니다. 그 면제가 정적 검사 밖에서도 걸린 사례를 확인했습니다.

관찰

git ls-tree -r --name-only origin/main | grep round-composition.md 결과:

프로토콜 16/16 — 전부 references/round-composition.md 보유
epistemic-cooperative — 0

references/round-composition.md는 사용자 대면 발화를 사용자의 언어로 렌더하도록 결속하는 문서입니다. 각 파일 첫 절이 적습니다:

"User-facing emit (… convergence traces, gate options, and any text shown to the user) uses everyday language."
"What the user reads is the action, observation, or question in their idiom."
"a reader who switches language has moved the whole rendering, terms included."

epistemic-cooperative/skills/onboard/SKILL.md에는 이 규칙도, Round composition 규칙 항목도 없습니다(grep 0건). 그리고 질문 줄기뿐 아니라 선택지 레이블까지 고정 영어입니다 — "Yes"/"No", "1 and 2"/"2 and 3", "Done — I have enough" (:318, :326-327, :385-386).

왜 이 이슈의 자리인가

epistemic-cooperative는 CANONICAL_PROTOCOL_SET에 없으므로 isUtility: true입니다. 프로토콜 규약의 커버리지 경계가 그 술어를 따라 그어져 있고, onboard는 그 경계의 바깥에 조용히 놓여 있습니다.

이 이슈가 예측한 그대로입니다 — 실패가 아니라 면제이고, 검사 결과는 초록으로 남습니다. 다만 여기서는 면제된 것이 정적 검사가 아니라 규약 자체입니다. 그래서 이 이슈의 귀결이 스크립트 커버리지보다 넓다는 것을 보여주는 사례이기도 합니다: 하드코딩 집합이 결정하는 것은 "어느 검사가 도는가"만이 아니라 "어느 규약이 미친다고 여겨지는가"입니다.

특히 잡히지 않는 이유

사용자가 막히지 않습니다. onboard에는 맞춰 보는 문자열이 없으므로 조건 미발화 문제가 아니고, 호스트가 렌더링해 주면 잘 돌아갑니다. 그래서 이 공백은 "사용자가 막히는가"로는 영영 안 잡히고 "무엇이 보장되는가"로만 잡힙니다.

AGENTS.md ## Runtime Contract이 그 구분을 이미 갖고 있습니다:

"SKILL.md must be self-contained."
"How a host realizes the contract is platform realization and not part of it."

Output Style 같은 실현 층위는 SKILL.md의 의무를 대신 지지 못합니다. 그러니 "호스트가 렌더링해 주니 괜찮다"는 성립하지 않습니다. 동시에 같은 조항이 반대쪽도 자릅니다 — 덮지 못한다는 것은 패키지가 그 렌더링을 보장하지 않는다는 뜻이지 계약이 위반됐다는 뜻이 아닙니다. onboard의 결함은 보장 범위의 공백이지 오기가 아닙니다.

대비가 선명합니다: 16개 프로토콜은 패키지 안에 자기 규칙을 갖고 있어 Output Style 없이도 계약이 섭니다. onboard는 호스트가 마침 해 주면 되고 아니면 안 되는 상태입니다.

독자 취약성

onboard는 이 프로토콜 묶음을 처음 배우는 사람이 쓰는 스킬입니다. 커버리지 경계가 만든 면제가 하필 가장 취약한 독자에게 떨어져 있습니다.

이것이 결정을 요구하는 것 — 여기서 정하지 않습니다

수리 형태가 다른 자리들과 다릅니다. 다른 곳은 이미 있는 규칙이 미치는지를 판정하는 일이었지만, 여기는 규칙을 새로 더하는 일이고 입증책임이 반대입니다. AGENTS.md §Design Placement가 그 방향을 경계합니다 — "do not add a runtime rule just because a concept is philosophically attractive."

열린 질문 셋:

1. 다른 16개처럼 Round composition 규칙 + references/round-composition.md를 이식할 것인가, 아니면 유틸리티 스킬에 프로토콜 규약을 옮기는 것이 층위 위반인가.
2. 그보다 가벼운 형태 — 선택지 레이블 렌더링만 진술 — 로 충분한가.
3. onboard가 교육용이라 의도된 고정이 어디까지인가. 프로토콜 이름과 /command는 당연히 영어여야 하고, 선택지 레이블과는 다른 축입니다.

함께 확인된 것

같은 부류의 결함(활성화 조건이 인용된 영어 문구로 잠긴 것)이 프로토콜 16개에서는 오늘 전부 닫혔으나(git grep 'explicitly says "' -- '*/skills/*/SKILL.md' → 0건), onboard/SKILL.md:150-152에는 살아 있습니다.

그 완결성 주장 자체는 거짓이 아니었습니다 — 커밋 e1e6c617의 해당 절 제목이 "## 다른 프로토콜의 같은 자리"로 범위를 프로토콜에 한정해 두었고, AGENTS.md가 요구하는 대로 부재 주장의 범위를 명시한 좋은 관행입니다.

공백은 다른 자리입니다: 범위 밖 잔여물을 이어받는 기록이 아무 데도 없습니다. 부재 주장에서 조용히 실패하는 곳은 주장이 아니라 그 범위의 바깥이고, 이 이슈의 하드코딩 집합이 바로 그 바깥을 정하고 있습니다.