구현: 화면·실행 스크립트 (u4·u5)

화면 u4(Vue 3)와 실행 스크립트 u5를 만듭니다. 검토 에이전트가 화면 설계를 한 번 반려한 기록, 화면 시험까지 돌도록 사람이 승인해 바꾼 검증 명령, Docker 없이 네 서비스를 띄우는 스크립트의 비밀 값 처리를 차례로 봅니다.

무엇을 · 왜#

u5는 패키징 유닛이므로 기능 설계 단계가 없습니다. 보안·실행 설계가 그 역할을 맡습니다.

산출물과 바뀐 점#

① u4 컴포넌트 u4-web-ui/functional-design/frontend-components.md: 라우터나 상태 관리 라이브러리는 쓰지 않습니다. composable 하나(useApp)가 상태를 관리하고, 컴포넌트는 props와 이벤트로만 소통합니다.

App.vue
├─ QueryInput          입력창과 전송
├─ ErrorNotice         오류 안내
├─ ReservationStatus   결제 대기·완료·실패·취소
├─ RecommendationList  추천 카드 (최적 1 + 후보 최대 2)
├─ EmptyNotice         후보 없음
└─ ScenarioPanel       접힌 시연 설정 (모의 결제 결과, 지연 초)

② u4 설계 검토 u4-web-ui/functional-design/reviews/: 첫 검토(review-01.md) 결과는 NOT-READY였으며, Major 지적은 6건이었습니다. 예를 들어 R-02는 다른 주차권으로 다시 결제하면 새 예약의 version이 처음부터 시작하는데, 화면이 하나의 version 기준만 쓰면 새 예약의 갱신을 모두 버린다는 지적입니다. 문서를 고친 뒤 두 번째 검토(review-02.md)에서는 "이전 Major 6건은 모두 고쳐졌고"라는 평가와 함께 READY를 받았습니다. 남은 지적은 Status 열에 New·Unresolved로 표시됩니다.

③ 검증 명령 aidlc-state.md: u4를 만든 뒤 AI가 검증 명령 변경을 제안했습니다. 기존 mvn -q verify는 Java 서비스만 시험하므로 화면 시험도 실행하자는 제안입니다. 사람이 승인한 뒤 다음 명령이 기록되었습니다. 이후 모든 유닛의 체크포인트는 이 명령으로 기록됩니다.

- **Construction Verification Command**: mvn -q verify && npm --prefix services/u4-web-ui run verify

④ u4 결과 u4-web-ui/code-generation/code-summary.md: 시험 374개(단위 351, 시간 4, 프록시 19)가 통과했습니다. 라인 커버리지는 98.29%입니다. 경과 시간 표시(틱) 시험이 부하가 높을 때 가끔 실패한다는 사실도 「미해결」로 적혀 있습니다.

⑤ u5 보안·실행 설계 u5-local-run/nfr-design/security-design.md

⑥ u5 결과 u5-local-run/code-generation/code-summary.md: 스크립트 세 개를 만듭니다. run-local.sh(네 서비스 기동과 정리), smoke-local.sh(화면 프록시를 거쳐 추천 → 결제 → 예약 완료 확인), verify-all.sh(전체 검증)입니다. bash 시험 79개(확인 439건)가 통과했습니다. 줄 커버리지는 100%입니다.

사람이 내린 결정#

"호스트 한계로 기록하고 승인"을 고르면 검증 명령이 실제로 통과하지 않아도 유닛이 승인됩니다. 그래서 기준을 그대로 두고 다시 시도했습니다. 감사 기록을 보면 u4 검증은 세 번 실패한 뒤 네 번째에 통과했고, u5는 첫 검증에서 통과했습니다.

확인 문제#