fix(spec): enforce scope and evidence boundaries in reviews
This commit is contained in:
@@ -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에는 질문에 대한 설명과 선택지를 작성하고 추천안을 표시한다. 모든 선택지는 체크박스(`[ ]`)를 사용한다.
|
||||
|
||||
Reference in New Issue
Block a user