[Task] Harness 승인 게이트와 workflow skill 정리

[alexization]

대상 저장소

• git-ranker-workflow

문제 / 배경

• Harness가 spec approval을 다루는 순서는 policy에 일부 있었지만, 질문 루프 종료 뒤 승인 요청을 하고 사용자 명시적 동의가 있어야만 Approved가 된다는 경계가 충분히 직접적이지 않았습니다.
• workflow-local red, green, refactor skill도 현재 유지 대상이 아니라서 registry와 실제 파일을 정리할 필요가 있었습니다.

왜 지금 필요한가요?

• 최근 작업에서 요청과 승인 사이 경계가 실제로 흔들렸고, policy와 skill을 함께 맞추지 않으면 같은 오류가 반복될 수 있습니다.

완료 조건 / 기대 결과

• sdd-spec-policy.md와 workflow-governance.md가 question loop -> Harness no-more-questions judgment -> user approval request -> explicit approval -> Approved 순서를 직접 설명한다.
• request-intake와 socratic-spec-authoring skill이 같은 경계를 handoff 수준으로 반영한다.
• workflow-local red, green, refactor skill이 제거되고 registry가 현재 유지 대상만 설명한다.

이번 이슈에서 다루는 것

• approval semantics policy 보강
• 관련 workflow-local skill handoff 보강
• legacy workflow TDD skill 제거
• active spec tracking 업데이트

이번 이슈에서 다루지 않는 것

• git-ranker repo-local TDD skill 내용 자체
• backend production code 또는 test infra 변경
• request routing category 재설계

접근 메모

• canonical policy를 먼저 강화하고, skill은 thin-layer rule에 맞게 같은 순서를 handoff와 anti-pattern 수준까지만 반영합니다.
• workflow-local red, green, refactor는 제거하고 registry에서 제외합니다.

영향 / 의존성

• 새 라이브러리: 없음
• 선행조건: 없음
• 운영 영향: Harness 작업 절차와 publish gate 해석이 더 엄격해집니다.

리스크 / 확인이 필요한 점

• 문구가 과도하게 엄격하면 작은 직접 요청에서도 승인 마찰이 커질 수 있습니다.
• skill이 policy를 과하게 복제하지 않도록 유지해야 합니다.