fix(spec): enforce scope and evidence boundaries in reviews

This commit is contained in:
2026-10-06 02:30:14 +00:00
parent a65171775c
commit 9cda9733c6
4 changed files with 107 additions and 5 deletions
+14
View File
@@ -58,6 +58,20 @@ Discovery는 Gitea Issue 본문으로 작성한다.
- 내용 검토: 저장소 근거가 작성 내용을 뒷받침하는지, 요구사항 문서의 갱신·신규 선택이 적절한지, 확정된 결정과 미해결 질문이 서로 모순되지 않는지 확인한다.
- 형식 검증 통과만으로 내용 검토나 구현 준비가 완료됐다고 판단하지 않는다. 미해결 질문이 있는 초안은 질문을 남긴 상태로 게시할 수 있으며, 완료 보고에 이를 명시한다.
## 범위 분류와 blocking 판단
새 OQ 또는 인수 조건을 제안하기 전에 원본 요청, 현재 사용자 결정과 pinned source의 기존 계약을 근거로 다음 중 하나로 분류한다.
- 핵심 요청: 원래 문제 해결에 직접 필요한 조건.
- 기존 호환성: 기존 동작·인증·보안·데이터 계약을 보존하는 조건. 핵심 요청 밖이라는 이유로 선택적 확장으로 낮추지 않는다.
- 선택적 확장: 원래 요청·기존 계약에 없는 추가 기능. 명시적으로 채택되지 않은 선택적 확장은 필수 범위·acceptance criterion·blocking OQ로 승격하지 않는다.
분류와 승인 근거는 trusted workflow의 검토 기록에 남긴다. Discovery marker·H2 순서·hidden metadata나 제품 문서 schema는 변경하지 않는다. 선택적 제안을 남긴다면 현재 승인 범위가 아님을 명시하고 핵심 해결을 차단하지 않는다.
- Blocking OQ는 핵심 요청 또는 기존 호환성을 안전하게 확정하는 데 실제 사용자 결정이 필요한 경우에만 만든다. 구현 후 실행할 acceptance 검증과 사용자 선택이 필요한 결정 공백을 구분한다.
- 이미 사용자가 명시적으로 채택한 추가 요구나 기존 미선택 OQ를 분류만으로 임의 삭제·해결 처리하지 않는다. 재분류로 기존 결정과 충돌하면 원문 선택을 보존하고 사용자 판단을 받는다.
- 작성 후 각 새 OQ·인수 조건의 분류와 승인 근거를 확인하고, 미채택 선택적 확장이 핵심 해결의 blocker가 되지 않았는지 검증한다.
## OQ(${open_questions}) 작성 방법
각 OQ에는 질문에 대한 설명과 선택지를 작성하고 추천안을 표시한다. 모든 선택지는 체크박스(`[ ]`)를 사용한다.