fix(spec): enforce scope and evidence boundaries in reviews
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: gitea-discovery-review
|
||||
description: 수정된 Gitea Discovery를 검토하고 정규화한다.
|
||||
version: 0.3.0
|
||||
version: 0.3.1
|
||||
author: genichin, Hermes Agent
|
||||
license: MIT
|
||||
platforms: [linux]
|
||||
@@ -47,6 +47,20 @@ Gitea 인증과 readback은 [Gitea authenticated access 운영 지침](../../../
|
||||
- 미해결 OQ가 없으면 `## 미해결 질문`의 본문을 exact `없음`으로 쓴다.
|
||||
- 추천안을 사용자가 선택한 결정처럼 기록하거나 사용자 대신 checkbox를 선택하지 않는다.
|
||||
|
||||
## 범위와 기술적 결론의 경계
|
||||
|
||||
- 새 OQ·인수 조건은 [Discovery 작성 방법](../../../../docs/discovery/README.md)의 핵심 요청 / 기존 호환성 / 선택적 확장 분류와 blocking 규칙을 먼저 적용한다. 각 항목의 분류·원본 근거·사용자 채택 여부를 trusted workflow 검토 기록에 남긴다.
|
||||
- 미채택 선택적 확장을 필수 범위나 blocking OQ로 승격하지 않는다. 기존 보안·호환성 제약은 선택적으로 낮추지 않으며 사용자가 채택한 요구나 미선택 OQ를 임의 삭제·해결하지 않는다. 기존 결정과 충돌하면 선택을 보존하고 사용자 판단을 받는다.
|
||||
- 구현 후 acceptance 검증은 사용자 선택이 필요한 결정 공백과 구분한다. 단지 최종 구현 검증이 아직 없다는 이유로 새 OQ를 만들지 않는다.
|
||||
|
||||
기술적 전제 결론은 다음 세 수준을 구분한다.
|
||||
|
||||
1. 시험한 방식의 실패: 특정 후보·버전·환경에서 관찰한 실패만 보고하며 시험하지 않은 대안까지 부정하지 않는다.
|
||||
2. 소스로 확인된 제약: 적용 버전의 공식 문서·소스로 제한되는 API·조건과 근거 위치를 특정한다.
|
||||
3. 요구 충족 불가능: 승인된 제약 안의 가능한 대안까지 배제할 근거와 검토 범위를 제시할 수 있을 때만 사용한다. 근거가 부족하면 미검증 또는 판단 유보로 보고하고 전체 불가능으로 단정하지 않는다.
|
||||
|
||||
일부 prototype 실패만으로 사용자 요구·URL·dependency 정책 변경을 필수 선택으로 제안하지 않는다. 실험 기록과 기술 delegate 결과에는 대상 요구사항, 시험한 후보·버전·환경, 성공·실패 관찰, 시험하지 않은 대안·확인 한계와 결론 적용 범위를 포함한다. Main은 delegate의 불가능 결론을 원본 실험·공식 소스에 직접 대조한 뒤 채택하며, delegate summary만으로 결정하지 않는다.
|
||||
|
||||
## 절차
|
||||
|
||||
1. 요청에서 exact `owner`, `repository`, Issue 번호를 추출하고 단일 안전 경로 요소인지 검증한다. `operations/repository-cache.md`를 새로 읽고 canonical cache 경로를 계산·검증한다.
|
||||
@@ -56,7 +70,7 @@ Gitea 인증과 readback은 [Gitea authenticated access 운영 지침](../../../
|
||||
5. Issue lock을 유지한 채 canonical 지침에 따라 기존 cache를 검증한다. 검증에 실패하면 자동 초기화하거나 복구하지 않고 중단한다.
|
||||
6. repository lock을 canonical 순서로 획득해 origin을 fetch하고 Gitea default-branch SHA와 local ref가 정확히 일치하는 revision을 pin한다.
|
||||
7. pinned SHA에서 current Discovery의 모든 저장소 근거, 다섯 후속 문서 경로, 요구사항 ID·파일명과 사용자 prose 수정의 사실성을 조사한다. 움직이는 branch나 다른 workspace를 근거로 사용하지 않는다.
|
||||
8. 각 OQ의 선택 수를 판정한다. 선택된 결정이 특정 API·dependency·runtime·배포 기능에 의존하면 pinned 저장소와 적용 버전의 공식 문서·소스를 조사해 지원 여부와 구현 경로를 확인한다. 조사만으로 판단할 수 없고 실행 실험이 필요하면 기술적 전제 검증을 미완료로 남긴다. 선택된 결정을 관련 모든 섹션에 전파하고, 새 모순·누락으로 새 사용자 결정이 필요할 때만 OQ 검토 규칙에 따라 새 OQ를 추가한다.
|
||||
8. 범위 분류·blocking 판단과 기술적 결론의 경계를 먼저 적용하고 각 OQ의 선택 수를 판정한다. 선택된 결정이 특정 API·dependency·runtime·배포 기능에 의존하면 pinned 저장소와 적용 버전의 공식 문서·소스를 조사해 지원 여부와 구현 경로를 확인한다. 조사만으로 판단할 수 없고 실행 실험이 필요하면 기술적 전제 검증을 미완료로 남긴다. 선택된 결정을 관련 모든 섹션에 전파하고, 새 모순·누락으로 새 사용자 결정이 필요할 때만 OQ 검토 규칙에 따라 새 OQ를 추가한다.
|
||||
9. `문서 영향 및 산출물`을 README 정책에 따라 전부 다시 판정한다. 요구사항명세서의 exact ID·경로·제목·포함할 내용·제외할 내용과 다른 문서의 구체적 변경 계약을 현재 결정과 pinned SHA에 맞춘다.
|
||||
10. 조사 종료 시 Gitea default-branch SHA와 local ref가 pinned SHA와 여전히 일치하는지 확인하고 repository lock을 해제한다. Issue lock은 유지한다.
|
||||
11. trusted workflow directory에 revised body artifact를 만들고 marker, H2 순서, placeholder 부재, OQ ID·checkbox, 결정 전파, 문서 영향, repository evidence와 credential 부재를 검증한다.
|
||||
@@ -85,6 +99,7 @@ Gitea 인증과 readback은 [Gitea authenticated access 운영 지침](../../../
|
||||
- Issue/comment pre-write snapshot과 입력 승인 gate 결과
|
||||
- cache 경로, bare·remote 검증, fetch와 pinned Gitea/local SHA
|
||||
- 사용자 선택 OQ, 유지한 OQ, 제거한 OQ와 새로 연 OQ 및 기술적 전제 검증 결과·근거·미검증 항목
|
||||
- 새 OQ·인수 조건의 범위 분류·승인 근거·blocking 사유, 기술 결론 수준·시험 범위·미검증 대안과 main의 delegate 근거 대조 결과
|
||||
- 사용자 prose 수정의 수용·조정·거부 결과와 근거
|
||||
- 확정된 결정의 섹션별 전파 결과
|
||||
- 다섯 후속 문서의 조치·exact 경로·변경 내용 검증 결과
|
||||
|
||||
Reference in New Issue
Block a user