하네스(harness) — AI가 "다 했다"고 넘어가지 못하도록 증거를 강제하는 장치 모음 — 에 새 요구사항 장치를 넣었는데, 그 지시가 일을 지휘하는 리드의 지시문에만 적혀 있고 실제 일이 벌어지는 하류에는 전달되지 않았다. 이 페이지는 그 지적에서 출발해 하류 7지점의 빈 곳을 수리하고, 독립 검증이 잡아낸 실행 체인 끊김 2건(허공 시드·게이트 충돌)까지 닫은 기록과 기대효과다.
결론부터: 규칙을 문서에 적는 것과 실행 경로에 연결하는 것은 다른 일이다. 새로 채택한 장치가 총괄(리드) 지시문에만 있으면, 계획 담당·QA 담당·검문 장치는 그 장치를 모른 채 예전처럼 움직인다. 아래 세 장이 이번 작업의 전체 맥락이다.
ouroboros(우로보로스, 자기 꼬리를 무는 뱀)는 오픈소스 AI 에이전트 프레임워크다. 2026-08-06 검토에서 두 장치를 가져왔다 — 요구사항을 목표·제약·용어 세 축으로 적어두는 "spec 3축", 그리고 대화 중 요구가 바뀌었는지 확인하는 "의도 전환 체크".
두 장치가 /team 스킬(여러 AI 담당을 지휘해 프로젝트를 완성하는 작업 절차서)의 리드 문구에만 적혀 있었다. 계획을 세우는 담당, QA를 도는 담당, 코드를 올리기 전 막아서는 검문 장치 — 실제 실행 지점에는 아무것도 전달되지 않았다.
team 쪽 5지점과 init-project 쪽 2지점, 합쳐 갭 7건을 수리했다. 그리고 독립 검증자가 수용 기준 밖에서 찾아낸 실행 체인 끊김 2건(허공 시드·게이트 충돌)까지 닫고, 게이트가 오작동하지 않음을 패턴 검색(grep) 3건으로 실증했다.
읽는 법: 위에서 아래로 흐른다. init(프로젝트 준비 단계)이 심은 요구사항 시드가 team(실행 단계)으로 넘어가 계획 문서(plan)에 적혀 남고, QA를 거쳐, 마지막 push 게이트(코드를 서버에 올리기 전 자동 검문)까지 이어진다. 붉은 점선 두 곳이 문구만 보면 멀쩡한데 실행이 끊겨 있던 지점이다.
용어 셋만 미리 풀어둔다. plan은 이번 작업의 계획을 적어두는 문서, compaction(컴팩션)은 AI의 긴 대화가 압축되며 오래된 내용이 지워지는 일, fan-out(팬아웃)은 QA 검사를 여러 하위 AI에게 동시에 뿌려 돌리는 일이다. 일곱 지점 각각에서 무엇이 비어 있었는지는 실제 문서를 검색해(실측) 확인했다.
| 지점 | 없었던 것 (실측) | 수리 |
|---|---|---|
team 경로 A planner |
반환 계약이 "계획+AC"뿐 — 3축이 반환에 없어 planner가 정리해도 소실 | 반환 계약에 "spec 3축(목표·제약·용어)" 명시 |
team Phase 1 plan 정본 |
§4 산출물이 "메모리 컨텍스트만" — 기준선이 compaction에 소실되는 구조 | plan에 ## Spec (목표/제약/용어) 섹션 필수 — 영속 기준선 |
team Step 1 |
전환 체크가 Step 2.5(fan-out 이후)에만 — 전환 감지 시 QA 한 라운드 낭비 | §0 주 지점 신설 (fan-out 전) — 기존 delta spawn에 얹어 spawn 추가 0 |
team Step 2.5 |
재도출의 실행 주체·방법 미명시 | 백스톱으로 재정의 + delta 재스폰·영향 TC 재실행 구체화 |
qa-scenario-gen delta 모드 |
"요구 변경 없으면 AC 불변"만 — 전환 케이스 미지원 (append-only뿐) | 전환 예외 신설: 폐기 AC 매핑 제거·TC obsolete·근거 없으면 미발동 |
init intake goal 스키마 |
제약(execution_constraints)은 기존재, 용어(ontology) 축만 부재 | ontology 선택 필드 추가 — handoff로 /team에 상속 |
init .requirements-lock.md |
LOCK 행(기능 시그니처)뿐 — 프로젝트 수준 3축 시드 없음 | ## Spec 헤더 섹션 지시 — 가드가 ^LOCK|만 파싱함을 실측 후 무충돌 배치 |
문서에 문구가 있는지 확인하는 검사(문구 검증)와, 그 문구대로 따라가면 실제로 일이 흘러가는지 확인하는 검사(실행 체인 검증)는 다른 검사다. 독립 검증자는 합의된 수용 기준 7개를 전부 통과시키고도, 기준 밖에서 배선을 따라가 두 곳의 끊김을 찾았다.
"상속되어…출발점으로 삼는다" — 주장만 있고 소비 지시 0건
"폐기 TC를 plan에 남겨라"가 게이트 분모에 그대로 계수
문구 검증과 실행 체인 검증은 다른 검사다. 독립 검증자는 수용 기준 7개를 전부 통과시키면서도, 기준 밖에서 "이 배선을 따라가면 실제로 무슨 일이 일어나는가"를 추적해 끊김 2건을 찾았다 — 하나는 생산자만 있고 소비자가 없는 허공 배선, 하나는 새 계약이 기존 HARD 게이트와 충돌해 push가 차단되는 미래였다. 배선 추가는 항상 생산자·소비자 쌍으로, 그리고 그 산출물이 통과할 게이트의 파서까지 대조해야 끝난 것이다.
| 전파 전 실패모드 | 전파 후 | 근거 |
|---|---|---|
| 3축이 리드 메모리에만 존재 — compaction 한 번이면 기준선 소실, 전환 판정이 감으로 회귀 | plan ## Spec 섹션이 디스크 기준선 — 세션이 끊겨도 대조 가능 |
compaction-governance-decay 규칙: 산문 제약은 압축이 지운다 (제약 생존 시 위반 0% vs 드롭 시 38%) |
| 전환 감지가 Step 2.5 — 이미 낡은 TC로 QA 한 라운드 소진 후에야 재도출 | Step 1 §0에서 fan-out 전 감지 — 갱신된 TC로 첫 실행 | QA fan-out 1라운드 = 하위 AI 3~5기 실행 비용. 주 지점 이동은 spawn 추가 0으로 달성 |
| 전환 시 obsolete TC가 게이트 분모에 계수 — push HARD 차단 또는 거짓 PASS 계수 강요 | 비계수 표기 계약으로 전환 런도 게이트 정상 통과 (미실행 TC의 거짓 증거 없이) | 게이트 4개 계수 패턴(심각도 CRITICAL/HIGH/MEDIUM + TC-E2E 헤딩)에 대해 변형의 비계수를 grep 실증 |
| init 시드가 있어도 team이 안 읽음 — 프로젝트 제약·용어가 런마다 재발명(불일치 위험) | handoff·lock 시드 → team 3축 상속 체인 완성 — 프로젝트 수준 일관성 | team SKILL:60이 handoff를 실행 전제로 이미 읽던 구조에 소비 지시만 추가 (비용 0) |
여기까지는 문서 계약 + 게이트 grep 실증이다 — 실제 /team 런에서 시드 로드·전환 체크·obsolete 비계수가 발동하는 행동 실증은 아직 없다. 다음 /team 런들이 그 관측 지점이고, ## Spec 섹션 존재의 HARD 게이트화는 사용 실적을 본 뒤 soft-to-hard 승격으로 판단한다. 효과가 없으면 archive가 정답이라는 원칙은 이 배선에도 똑같이 적용된다.