dcness-architecture-validatorlisted

# dcness-architecture-validator ## 언제 쓰나 dcNess가 `architecture-validator`를 Codex 교차 검토로 보낼 때 사용한다. 구현 착수 전 또는 architecture PR merge 전에 module-architect epic-batch 또는 revision mode 산출물과 opt-in system checkpoint 산출물이 구현 가능한 계약으로 이어지는지 읽기 전용으로 검토한다. ## 목적 Claude-side `architecture-validator` prompt를 복제하지 않는다. 같은 결론 어휘를 쓰되, 구현 churn, 숨은 coupling, 검증 불가능한 acceptance criteria를 만들 설계 gap을 별도 시각으로 찾는다. 특히 epic-batch 산출물이 파일 경계와 병렬성에는 맞지만 사용자가 검증할 제품 동작 수직 슬라이스를 만들지 못하는 상태를 설계 실패로 본다. 용어·공개 진입점·분기 표현을 수정하거나 리뷰할 때만 [`terms.md`](../../../docs/plugin/terms.md)를 확인한다. ## 입력 - architecture 또는 epic 디렉터리 경로 - PRD, story, ADR/decision, architecture, 선택 domain-model, implementation task 경로 - 메인이 `scripts/report_ac_coverage.mjs` 로 생성한 Story AC ↔ REQ advisory report - final epic validation인지, system boundary opt-in checkpoint 이후 검증인지에 대한 호출 맥락 - revision mode 이면 사용자 개정 의도, 변경된 UX 산출물 포인터(해당 시), 파생 drift 체크리스트 결과 - 필요하면 이전 finding과 재검토 맥락 ## 먼저 볼 기준 - 원 요구사항: PRD 유저 시나리오, Story AC, epic 완료 기준 - 현재 설계 산출물: architecture, decisions, 선택 domain-model, implementation tasks - 모듈 설계 원칙: `docs/plugin/agents/_shared/module-design-principles.md` - 구현 전 결정 완전성: dcNess 저장소의 진본은 `docs/plugin/decision-completeness.md`다. 외부 프로젝트에는 이 파일이 함께 배포되지 않으므로 아래 내장 계약을 skill 본문만으로 적용한다. - Claude-side validator와 공유하는 Must finding 분류: `SYSTEM_BOUNDARY`, `TASK_LOCAL` ### 내장 결정 완전성 계약 고정 검���표를 채우지 말고 현재 작업과 관련된 의미만 읽는다. 결정 범위는 actor, 데이터와 관계, 상태와 lifecycle, 실패와 복구, 권한과 보안, 외부 연동, 사용자 경험과 정책, 운영 제약이다. 이 목록은 질문 순서나 별