SDD Brownfield stub blind spot — 5가지 개선 제안

[bluejayA]

배경

nexttui 프로젝트에서 BL-P2-015 (Volume Attach/Detach + FloatingIP Associate/Disassociate) 구현 시 발견된 SDD 프로세스의 구조적 맹점.

문제

CinderPort::attach_volume과 detach_volume이 trait에 이미 정의되어 있었지만, HTTP adapter에는 "not yet implemented" stub으로 남아있었다. SDD 서브에이전트 6개 Unit + 1017개 테스트가 모두 통과했지만, 실제 API 호출은 한 번도 검증되지 않았고 런타임에서 즉시 실패했다.

근본 원인 (4단계 모두 실패)

단계	맹점
설계	"기존 stub → 실제 구현" 전환을 컴포넌트로 명시하지 않음
SDD 프롬프트	신규 추가만 지시, 기존 stub 교체 지시 없음
테스트	Mock 기반 단위 테스트만 존재. HTTP adapter 레벨 테스트 없음
리뷰	Codex가 정확히 지적(C-1)했으나 "후속 처리"로 미룸

개선 제안 5건

1. construction-orchestrator에 "Stub Scan" 단계 추가

Unit 구현 시작 전 또는 build-and-test 전에:

grep -rn "not yet implemented\|todo!()\|unimplemented!()" src/ --include="*.rs" --include="*.py" --include="*.ts"

결과를 unit 프롬프트에 "교체 대상 stub" 섹션으로 포함.

2. implementer-prompt에 Brownfield 체크리스트 추가

## Brownfield Checklist (기존 코드베이스 확장 시)
- [ ] 관련 trait에 이미 정의되었지만 stub인 메서드가 있는지 확인
- [ ] 기존 adapter(HTTP/Mock) 모두에서 stub 여부 확인
- [ ] "not yet implemented", "todo!()", "unimplemented!()" 검색

3. build-and-test에 "Stub 잔존 검증" 추가

build-and-test 성공 후 추가 단계:

• 이번 PR에서 추가/변경된 trait 메서드 중 adapter가 stub인 것이 있는지 검사
• stub이 발견되면 경고 표시 + auto-fix 대상으로 분류

4. 리뷰 지적 분류 정책

• 핵심 기능의 API 호출 관련 지적 → 무조건 CRITICAL, 즉시 수정
• "후속 처리" 옵션을 제공하지 않음
• 리뷰어가 "runtime failure" 키워드를 사용하면 자동 CRITICAL 승격

5. Mock vs Real adapter 테스트 갭 인식

• Mock 테스트만으로는 adapter 구현을 검증할 수 없음을 SDD 리포트에 명시
• "Mock coverage: N tests, Real adapter coverage: 0 tests" 표시
• 수동 검증 필요 항목을 명시적으로 나열

참조

• nexttui PR feat: 행동 테스트 계층 (Layer 2) — LLM 기반 스킬 동작 검증 (BL-042) #61: feat: Volume/FIP Attach-Detach — Bidirectional Operations (#61) nexttui#61
• 메모리: feedback_stub_blind_spot.md, feedback_devflow_sdd_improvement.md