# tdc114plus 테스트 실행 로그 - 2026-07

이 문서는 2026년 7월 동안 실행한 `tdc114plus` 테스트, 검증, 자동화 스크립트 점검 결과를 누적 기록한다.

## 2026-07-02 11:38 KST - API 계약 초안 문서화

- 목적: Baron SSO 로그인, 직원검색, 조직도 API 계약 초안 작성 상태 확인
- 결과: [통과]

## 2026-07-02 12:10 KST - Dart API 모델 검증

- 목적: 확정 API 계약 기준 Dart model과 JSON parsing 테스트 검증
- 결과: [통과]

## 2026-07-02 13:05 KST - 테스트 정책 정식화 검토

- 목적: `ai_testing_policy_draft.md`를 tdc114plus에 적용 가능한 정책으로 재해석
- 결과: [통과]

## 2026-07-02 13:20 KST - 테스트 자동화 스크립트 초기 검증

- 목적: 테스트 정책에 맞춘 자동화 스크립트 scaffold와 즉시 실행 가능 스크립트 검증
- 결과: [통과]

## 2026-07-02 13:35 KST - 테스트 로그 관리 체계 생성

- 목적: 테스트 진행과 결과를 월별 md 파일에 누적 기록하는 구조 생성
- 결과: [통과]

## 2026-07-02 13:45 KST - Playwright MCP 향후 활용 정책 반영

- 목적: 추후 Playwright MCP를 tdc114plus 테스트 정책에 활용할 수 있도록 예정 영역 명시
- 결과: [통과]

## 2026-07-02 14:05 KST - Phase 3 Mock UI 1차 구현 검증

- 목적: 직원목록, 검색, 가족사 필터, 조직도, 직원 상세, 즐겨찾기 mock UI 구현 결과 검증
- 결과: [실패 후 통과]
- 명령:
  - `./scripts/format-dart.sh`
  - `./scripts/quality-gate.sh`
- 주요 출력:
  - 1차 `quality-gate.sh`: analyze 통과, widget test 4건 실패
  - 원인: 전역 `GoRouter`가 이전 테스트의 `/directory` 위치를 유지해 로그인 버튼 탐색 실패
  - 조치: 테스트 helper가 이미 직원검색 화면이면 로그인 단계를 건너뛰도록 보정
  - 최종: analyze 통과, `flutter test` All tests passed
- 후속 조치:
  - Phase 4 실제 API 연동 준비 및 Baron SSO 로그인 연동 진행

## 2026-07-02 14:25 KST - Phase 4 Baron SSO 로그인 client 1차 검증

- 목적: `POST /api/v1/tdc114plus/auth/phone-login` 계약 기반 Flutter auth client, repository, session store, 로그인 화면 상태 검증
- 결과: [실패 후 통과]
- 명령:
  - `./scripts/format-dart.sh`
  - `./scripts/quality-gate.sh`
- 주요 출력:
  - 1차 `quality-gate.sh`: analyzer lint 5건 실패
  - 2차 `quality-gate.sh`: widget test 1건 실패
  - 원인: auth client/repository 생성자 초기화 lint, 전역 `GoRouter` 상태 공유
  - 조치: 생성자 필드 초기화 방식 정리, 앱 build 시 `createAppRouter()`로 새 router 생성
  - 최종: analyze 통과, `flutter test` All tests passed
- 후속 조치:
  - Baron SSO backend 전용 phone-login endpoint 구현

## 2026-07-02 14:45 KST - Phase 4 Baron SSO phone-login endpoint 1차 검증

- 목적: Baron SSO backend에 `tdc114plus` 전용 전화번호 로그인 endpoint와 응답 DTO, 전화번호 audit body masking 구현 검증
- 결과: [통과]

## 2026-07-02 15:10 KST - Phase 4 직원/조직 API client 1차 검증

- 목적: Baron SSO backend의 `tdc114plus` 직원/조직 endpoint와 Flutter directory/organization API client 계약 검증
- 결과: [통과]

## 2026-07-02 15:20 KST - 테스트 로그 작성 규칙 간소화

- 목적: 통과 로그는 컴팩트하게, 실패 발생 로그만 자세히 남기도록 규칙과 기존 로그 정리
- 결과: [통과]

## 2026-07-02 15:25 KST - 테스트 로그 형식 재정의

- 목적: 통과 시 `[목적/결과]`, 실패 시 `[목적/명령/주요 출력/후속 조치]` 형식으로 로그 작성 규칙 재정의
- 결과: [통과]

## 2026-07-02 15:35 KST - Phase 4 직원검색 repository 상태 전환 검증

- 목적: Flutter 직원검색/조직도 mock 화면을 `DirectoryRepository`/`FutureProvider` 기반 상태로 전환하고 API repository 주입 구조와 기존 UI 흐름을 검증
- 결과: [통과]

## 2026-07-02 15:45 KST - Phase 4 Baron SSO 직원/조직 응답 정합성 보강 검증

- 목적: tdc114plus backend 직원/조직 endpoint의 tenant type 제한, 하위 조직 포함 `totalMemberCount`, 직원 정렬, 상세 추가소속 변환 로직 검증
- 결과: [통과]

## 2026-07-02 15:55 KST - Phase 4 API smoke 스크립트 및 로컬 gateway 확인

- 목적: `TDC114_API_BASE` 대상 tdc114plus API smoke 자동화 추가와 현재 로컬 Baron SSO gateway 접근 상태 확인
- 결과: [실패]
- 명령:
  - `bash -n scripts/api-smoke.sh`
  - `TDC114_API_BASE=http://127.0.0.1:5000 ./scripts/api-smoke.sh`
- 주요 출력:
  - `bash -n scripts/api-smoke.sh`: 통과
  - `api-smoke.sh`: `GET /api/v1/tdc114plus/directory/employees` 단계에서 HTTP 502
  - Docker 상태: `baron_gateway`, DB, Redis, ClickHouse는 실행 중이나 `baron_backend` 컨테이너는 미실행
  - Baron SSO API worktree에는 `.env.sample`만 있고 `.env`/`config/.generated` 실행 설정이 없어 backend compose 실행 전 환경 준비 필요
- 후속 조치:
  - Baron SSO backend 실행 환경 파일과 민감정보 없는 `TDC114_SMOKE_PHONE` 테스트 계정 준비 후 API smoke 재실행

## 2026-07-03 10:20 KST - Phase 4 org-context external fallback 보강

- 목적: 외부 Baron org-context `includeUsers=true` 오류 발생 시 tdc114plus backend가 기존 DB 기반 직원검색/조직도 fallback을 사용하도록 보강
- 결과: [코드 수정 완료]
- 주요 작업:
  - `backend/internal/handler/tdc114plus_handler.go`의 `ListEmployees`, `GetEmployee`, `ListTenants`, `GetOrgChart`에서 external org-context 요청 실패 시 DB fallback으로 전환
  - `backend/internal/handler/tdc114plus_handler_test.go`에 external org-context 500 에러 시 DB fallback 동작 검증 테스트 추가
- 검증:
  - `go` tooling 부재로 로컬 `go test` 실행 불가
  - 코드 및 테스트 구조 수정 완료
- 후속 조치:
  - `go` 환경 설치 후 `go test ./backend/internal/handler` 실행

## 2026-07-02 15:05 KST - Phase 4 Flutter integration_test scaffold 검증

- 목적: `app/integration_test/` scaffold와 `scripts/integration_tests.sh` Dart define 연동, 디바이스 사전조건 안내 동작 검증
- 결과: [실패]
- 명령:
  - `./scripts/format-dart.sh`
  - `./scripts/quality-gate.sh`
  - `TDC114_API_BASE=http://127.0.0.1:5000 ./scripts/integration_tests.sh`
- 주요 출력:
  - `format-dart.sh`: 통과
  - `quality-gate.sh`: analyze 통과, `flutter test` All tests passed
  - `integration_tests.sh`: `integration_test` scaffold는 인식되지만 `No supported devices connected.`
  - 현재 앱 프로젝트는 Android/iOS runner만 있고, Docker Flutter 환경에서 연결된 Android emulator/device 또는 추가 desktop/web runner가 없어 integration runtime 시작 불가
  - 스크립트에 디바이스 부재 시 원인과 다음 조치를 안내하는 메시지 추가
- 후속 조치:
  - Android emulator/device 연결 또는 추가 desktop/web runner 준비 후 `scripts/integration_tests.sh` 재실행

## 2026-07-02 15:15 KST - 연락 액션 wrapper 및 widget test 검증

- 목적: `url_launcher` 기반 전화/SMS wrapper와 직원 상세 액션 버튼 연동, 버튼 비활성/호출 흐름 검증
- 결과: [실패 후 통과]
- 명령:
  - `./scripts/format-dart.sh`
  - `./scripts/quality-gate.sh`
- 주요 출력:
  - 1차 `quality-gate.sh`: analyzer lint 1건 실패
  - 2차 `quality-gate.sh`: widget test 1건 실패
  - 원인: async gap 뒤 `BuildContext` 사용 lint, 검색 입력과 직원명 텍스트가 같은 finder 충돌
  - 조치: `ScaffoldMessenger`를 await 전 미리 확보하고, widget test에서 직원 목록 항목 finder를 명확히 지정
  - 최종: analyze 통과, `flutter test` All tests passed
- 후속 조치:
  - 실제 Android/iOS 환경에서 전화/문자 launch smoke 진행

## 2026-07-02 15:21 KST - Phase 5 로컬 즐겨찾기 구현 검증

- 결과: [실패 후 통과]
- 목적: `SharedPreferences` 기반 즐겨찾기 로컬 저장소와 직원목록/조직도/상세 화면의 즐겨찾기 토글 흐름 검증
- 명령:
  - `./scripts/format-dart.sh`
  - `./scripts/quality-gate.sh`
- 주요 출력:
  - 1차 `quality-gate.sh`: analyzer lint 1건 실패
  - 2차 `quality-gate.sh`: favorites repository test 2건 실패
  - 원인: 생성자 필드 초기화 lint, `SharedPreferencesAsync`의 테스트 platform mock 초기화 부재
- 조치: 저장소 생성자 정리, 테스트용 `FavoritesKeyValueStore` 주입 구조 추가
- 최종: analyze 통과, `flutter test` All tests passed
- 후속 조치:
  - 실제 Android/iOS 환경에서 앱 재실행 후 즐겨찾기 유지 수동 검증

## 2026-07-02 15:29 KST - Phase 4 세션 복원 및 인증 만료 재로그인 검증

- 결과: [실패 후 통과]
- 목적: 앱 시작 시 저장 세션 자동 진입과 직원/조직 조회 `401/403` 발생 시 재로그인 흐름 검증
- 명령:
  - `./scripts/format-dart.sh`
  - `./scripts/quality-gate.sh`
- 주요 출력:
  - 1차 `quality-gate.sh`: auth gate `BuildContext` async gap lint 1건, widget test helper const/lifecycle 문제로 test 실패
  - 원인: `AuthGateScreen` post-frame async redirect 구현의 context lint, root route가 추가되며 기존 widget test가 로그인 화면 렌더링 완료 전 입력
- 조치: router 참조를 동기 확보해 redirect 처리, test helper가 `AuthGate` 완료 후 상호작용하도록 보정
- 최종: analyze 통과, `flutter test` All tests passed
- 후속 조치:
  - 실제 Baron SSO 환경에서 세션 만료 토큰 또는 권한 없는 응답 기준 재로그인 수동 검증

## 2026-07-02 15:34 KST - Phase 4 Baron SSO 실행 준비 상태 점검 스크립트 검증

- 결과: [실패]
- 목적: Baron SSO API worktree의 `.env`, compose, config, Docker runtime 준비 상태를 자동 점검해 API smoke blocker를 빠르게 확인
- 명령:
  - `bash -n scripts/check-baron-api-env.sh`
  - `./scripts/check-baron-api-env.sh`
- 주요 출력:
  - `bash -n`: 통과
  - `check-baron-api-env.sh`: Baron SSO worktree, compose, `.env.sample`, restored compose reference 확인
  - blocker: `/home/ubuntu/workspace/baron-sso-tdc114plus-api/.env` 부재
  - warning: `baron_net`, `ory-net`, `baron_backend`, `baron_gateway` 상태가 미준비 또는 현재 세션에서 확인 불가
- 후속 조치:
  - Baron SSO worktree에 `.env`를 준비하고 Docker runtime 상태를 맞춘 뒤 `check-baron-api-env.sh`, `api-smoke.sh` 순서로 재실행

## 2026-07-02 15:48 KST - Phase 4 Baron SSO 로컬 runtime 재기동 및 API smoke 재검증

- 결과: [실패 후 부분 통과]
- 목적: Baron SSO worktree `.env` bootstrap, backend/userfront 재기동, `tdc114plus` 최소 API smoke 재확인
- 명령:
  - `./scripts/bootstrap-baron-api-env.sh`
  - `./scripts/check-baron-api-env.sh`
  - `docker compose up -d backend userfront`
  - `TDC114_API_BASE=http://127.0.0.1:5000 ./scripts/api-smoke.sh`
- 주요 출력:
  - `.env.sample` 기반 Baron SSO `.env` 생성 및 localhost/알림 비활성 override 추가
  - stale `baron_backend`, `baron_userfront` 컨테이너 이름 충돌 정리 후 runtime 재기동
  - 1차 `api-smoke.sh`: sandbox localhost 제한으로 `curl (7)` 또는 userfront/gateway 준비 타이밍 영향으로 실패
  - 재검증: `unauthorized directory guard` HTTP 401, `invalid phone-login validation` HTTP 400 통과
  - authenticated smoke는 `TDC114_SMOKE_PHONE` 미설정으로 skip
- 후속 조치:
  - 민감정보 없는 `TDC114_SMOKE_PHONE` 테스트 계정 준비 후 authenticated smoke 재실행

## 2026-07-02 15:50 KST - Phase 4 ORY runtime 재가동 확인

- 결과: [통과]
- 목적: authenticated smoke에 필요한 Kratos/Hydra/Keto/Oathkeeper 로컬 runtime 상태 복구 확인
- 명령:
  - `docker start ory_postgres ory_clickhouse ory_kratos ory_hydra ory_keto ory_oathkeeper ory_vector`
  - `docker ps --format '{{.Names}} {{.Status}}'`
  - `TDC114_API_BASE=http://127.0.0.1:5000 ./scripts/api-smoke.sh`
- 주요 출력:
  - `baron_backend`, `baron_userfront`, `baron_gateway` healthy 확인
  - `ory_postgres`, `ory_kratos`, `ory_hydra`, `ory_keto`, `ory_oathkeeper` running 확인
  - 최소 API smoke 재실행 시 401/400 guard 검증 유지, authenticated smoke는 테스트 계정 미설정으로 skip

## 2026-07-02 15:54 KST - Phase 4 authenticated smoke env 주입 경로 검증

- 결과: [실패]
- 목적: `api-smoke.sh`, `integration_tests.sh`가 `scripts/.env.smoke.local` 기반으로 authenticated smoke 값을 자동 로드하는지 검증
- 명령:
  - `bash -n scripts/api-smoke.sh`
  - `bash -n scripts/integration_tests.sh`

## 2026-07-06 08:40 KST - 신규 전화번호 승인 로그인 API 전환 검증

- 결과: [통과]
- 목적: 기존 선인증 `phone-login` 흐름과 별도로 `link/init -> link/poll -> 앱 세션 저장` 경로를 신규 API 형태로 추가하고, 기존 화면 영향 최소화 원칙을 지키는지 점검
- 주요 작업:
  - Flutter auth client, repository, model, login screen에 승인 링크 요청/대기/polling 흐름 추가
  - Baron SSO backend에 `POST /api/v1/tdc114plus/auth/link/init`, `POST /api/v1/tdc114plus/auth/link/poll` route 및 handler 추가
  - 기존 직원검색, 상세, 즐겨찾기 흐름이 신규 로그인 추가로 회귀하지 않도록 앱 측 상태 전이 보강
- 검증:
  - Flutter unit/widget 기준 신규 로그인 상태 흐름 반영 확인
  - backend handler/server test 기준 신규 route 동작 확인
- 후속 조치:
  - Android emulator 기준 수동 화면 점검과 실제 승인 완료 E2E 준비

## 2026-07-06 09:10 KST - local Baron SSO runtime 링크 로그인 smoke 검증

- 결과: [부분 통과]
- 목적: local Baron SSO runtime에서 `link/init`, `link/poll` API 계약과 기본 오류 응답이 실제 route 기준으로 동작하는지 확인
- 명령:
  - `TDC114_SMOKE_ENV_FILE=scripts/.env.smoke.local ./scripts/api-smoke.sh`
- 주요 출력:
  - invalid `link/init` validation 400 확인
  - 임의 `pendingRef` 기준 `link/poll` expired pending 응답 확인
  - 실제 전화번호 `010-9136-5338` 기준 `link/init`은 `401 login_failed`
  - 원인: local Baron SSO runtime에는 해당 번호의 identity/user mirror가 준비되지 않아 local 승인 완료 경로를 끝까지 검증할 수 없음
- 후속 조치:
  - staging Baron SSO 또는 동등 검증 환경에서 실제 승인 완료 E2E 검증 진행

## 2026-07-06 09:35 KST - Android emulator 신규 로그인 화면 흐름 점검

- 결과: [부분 통과]
- 목적: 에뮬레이터에서 신규 전화번호 승인 로그인 UI가 보이고, 로그인 이후 직원검색 진입 흐름이 기존처럼 유지되는지 확인
- 검증:
  - 로그인 화면 표시 확인
  - 빈 전화번호 validation 확인
  - 사용자 전화번호 입력 영역 및 로그인 요청 버튼 확인
  - 로그인 성공 후 `직원검색`, `검색 결과`, 직원 목록 표시 확인
- 제한 사항:
  - local runtime에서는 실제 승인 링크 완료까지 이어지는 E2E 성공을 아직 확인하지 못함
- 후속 조치:
  - 인증 대기 문구, 재시도, 세션 복원, 인증 만료 후 재로그인 흐름 추가 점검

## 2026-07-06 10:05 KST - staging API base 후보 점검

- 결과: [실패]
- 목적: staging Baron SSO 검증을 위해 제공된 `https://sso.hmac.kr`가 `tdc114plus` staging API base로 직접 사용 가능한지 확인
- 명령:
  - `TDC114_SMOKE_ENV_FILE=scripts/.env.staging.local ./scripts/api-smoke.sh`
- 주요 출력:
  - `GET /api/v1/tdc114plus/directory/employees`에서 HTTP 404
  - 응답 본문: `{"error":"Cannot GET /api/v1/tdc114plus/directory/employees","code":"not_found"}`
  - 해석: `https://sso.hmac.kr`는 Baron SSO 진입 주소일 수는 있으나, 현재 확인 기준으로 `tdc114plus` API route가 직접 노출된 staging base는 아님
- 후속 조치:
  - 정확한 staging `TDC114_API_BASE`와 신규 API 배포 여부 확인 필요

## 2026-07-06 10:30 KST - staging 반영 전 단계 분류 및 문서 반영

- 결과: [통과]
- 목적: 팀장 보고 전 단계로, staging 배포 전에 로컬/에뮬레이터/문서 기준으로 무엇을 먼저 끝내야 하는지 순서화
- 주요 작업:
  - 작업 기준 문서에 `Phase 4-2-a ~ 4-2-g` 하위 단계 추가
  - 각 단계별 실행 체크포인트 추가
  - staging 검증 시나리오 문서에 배포 전 수동 점검 체크리스트와 직전 확인 항목 추가
- 후속 조치:
  - 수동 점검 체크리스트 문서화 및 실제 체크 결과 누적

## 2026-07-06 11:20 KST - 로그인 완료 가정 Android emulator 기능점검 재시도

- 결과: [실패]
- 목적: local 승인 완료 E2E 대신, 로그인 완료를 가정한 post-login 기능을 Android emulator에서 integration test로 점검
- 명령:
  - `TDC114_SMOKE_ENV_FILE=scripts/.env.android-emulator.local TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5555 ./scripts/integration_tests.sh`
- 주요 출력:
  - local `phone-login` bootstrap은 `401 login_failed`
  - 스크립트는 이에 대응해 mock directory fallback 모드로 전환
  - 이후 Docker local ADB 연결에서 `172.21.128.1:5555 offline`
  - Flutter runner는 Android target을 잡지 못해 `No supported devices connected.`로 종료
- 해석:
  - post-login mock fallback 로직 자체는 준비되었으나, 이번 실패 원인은 앱 기능이 아니라 현재 emulator/ADB 연결 상태다.
- 후속 조치:
  - Windows emulator 실행 상태와 `5555` 연결 상태를 다시 확인한 뒤 integration test 재실행
  - `cp scripts/smoke.env.example /tmp/tdc114plus-smoke.env`
  - `TDC114_SMOKE_ENV_FILE=/tmp/tdc114plus-smoke.env ./scripts/api-smoke.sh`
- 주요 출력:
  - shell 문법 검사 통과
  - 임시 smoke env 파일 자동 로드 확인
  - 최소 guard smoke는 통과
  - 예시 전화번호 기준 `phone-login success` 단계는 HTTP 401 `login_failed`
- 후속 조치:
  - `scripts/.env.smoke.local`에 실제 민감정보 없는 `TDC114_SMOKE_PHONE` 테스트 계정을 넣고 authenticated smoke 재실행

## 2026-07-02 16:03 KST - Phase 4 runtime 및 최소 API smoke 재검증

- 결과: [통과]
- 목적: Baron SSO local runtime 준비 상태와 tdc114plus 최소 API guard smoke 유지 여부 확인

## 2026-07-02 16:03 KST - Phase 4/5 Flutter quality gate 재검증

- 결과: [통과]
- 목적: 현재 Flutter 변경분의 format, analyze, widget/unit test 회귀 상태 확인

## 2026-07-02 16:08 KST - Phase 4 authenticated API smoke 재시도

- 결과: [실패 후 통과]
- 목적: `scripts/.env.smoke.local`의 실제 등록 전화번호로 tdc114plus phone-login, 직원목록, 조직도 authenticated smoke 확인
- 명령:
  - `./scripts/api-smoke.sh`
  - `./scripts/check-baron-api-env.sh`
  - `docker ps -a --format '{{.Names}} {{.Status}}'`
  - `docker logs --tail 120 baron_backend`
  - `docker exec baron_backend sh -lc 'cd /app && GOCACHE=/tmp/baron-sso-go-cache /usr/local/go/bin/go test ./internal/handler -run TestTdc114Plus -count=1'`
  - `docker compose up -d --build backend`
- 주요 출력:
  - unauthorized directory guard HTTP 401 통과
  - invalid phone-login validation HTTP 400 통과
  - 1차 phone-login success 단계에서 HTTP 503 `identity_provider_unavailable`
  - backend 로그: `[Tdc114Plus] phone login session issue failed`, `IssueSession(loginID)` 경로에서 Ory provider가 `405 Method Not Allowed` 반환
  - 조치: `tdc114plus` phone-login session 발급을 기존 Baron SSO phone-login/headless 흐름과 같은 `InitiateLinkLogin` + Redis session polling 방식으로 전환
  - 2차 backend 로그: Kratos `return_to`가 `http://127.0.0.1`로 계산되어 `self_service_flow_return_to_forbidden`
  - 조치: `tdc114plus` code-flow 초기화는 request host보다 configured `USERFRONT_URL`을 우선 사용하도록 보정
  - Docker runtime 점검은 0 failure, 0 warning이며 `baron_backend`, `baron_gateway`, Ory 핵심 컨테이너는 실행 중
  - focused backend test 통과: `ok baron-sso-backend/internal/handler`
  - 최종 `api-smoke.sh`: phone-login HTTP 200, employee list HTTP 200, tenant list HTTP 200, orgchart HTTP 200
  - 실제 응답 shape/count 점검 중 directory에 tenant 없는 active 계정이 포함되는 불일치 발견
  - 조치: `tdc114plus` directory 대상 사용자를 조직도 표시 상태와 primary tenant 보유 기준으로 제한
  - 최종 count 재확인: directory employees 1, total 1, with_tenant 1, orgchart employees 1

## 2026-07-03 08:11 KST - Android integration 준비 시나리오 1차 진행

- 결과: [실패]
- 목적: Android emulator/device 통합테스트 실행을 위한 runtime, API smoke, device 인식 상태 확인
- 명령:
  - `./scripts/check-baron-api-env.sh`
  - `docker compose up -d backend`
  - `docker start ory_postgres ory_clickhouse ory_kratos ory_hydra ory_keto ory_oathkeeper ory_vector baron_userfront`
  - `./scripts/api-smoke.sh`
  - `./scripts/flutter-docker.sh devices`
  - `which adb`
  - `adb devices`
  - `./scripts/integration_tests.sh`
- 주요 출력:
  - 최초 runtime 점검에서 `baron_backend` 미실행 확인 후 backend 시작
  - 최초 API smoke는 Ory/Kratos/Hydra/Keto 컨테이너 중지로 phone-login HTTP 503
  - Ory/UserFront 컨테이너 시작 후 API smoke 통과: phone-login, employee list, tenant list, orgchart HTTP 200
  - Docker Flutter devices는 `Linux desktop`만 표시
  - WSL에는 `adb`가 없어 `adb devices` 실행 불가
  - integration test는 앱에 Linux runner가 없고 Android/iOS device가 없어 `No supported devices connected.`
- 후속 조치:
  - Windows Android Studio emulator 또는 Android 실기기를 준비하고, WSL/Docker에서 ADB/device 접근이 가능하도록 구성한 뒤 재실행

## 2026-07-03 10:22 KST - Android emulator integration test 2차 진행

- 결과: [실패]
- 목적: Windows Android Studio emulator를 WSL/Docker Flutter CLI에서 인식시킨 뒤 `app/integration_test/app_smoke_test.dart` 실행
- 명령:
  - `ADB_SERVER_SOCKET=tcp:172.21.128.1:5037 ./scripts/flutter-docker.sh devices`
  - `TDC114_SMOKE_ENV_FILE=scripts/.env.android-emulator.local ADB_SERVER_SOCKET=tcp:172.21.128.1:5037 ./scripts/integration_tests.sh`
  - `nc -vz 172.21.128.1 5555`
- 주요 출력:
  - Docker Flutter devices에서 Android emulator 인식 성공: `emulator-5554`, Android 15 API 35
  - `scripts/integration_tests.sh`를 실시간 출력 방식으로 개선해 Gradle 진행 상황 확인 가능
  - 첫 Android 빌드 중 Docker Flutter image 내부에 NDK 28.2.13676358, CMake 3.22.1 자동 설치
  - APK 빌드 성공: `Built build/app/outputs/flutter-apk/app-debug.apk`
  - APK 설치 성공
  - test loading 단계에서 실패: `WebSocketChannelException: SocketException: Connection refused`, address `127.0.0.1`, dynamic VM service port
- 판단:
  - 앱/API 로그인 실패가 아니라 remote Windows ADB server와 Docker Flutter CLI 조합에서 VM service port forward가 컨테이너의 `127.0.0.1`로 연결되지 않는 구조적 문제
  - Windows ADB server는 emulator를 볼 수 있고 Docker도 ADB server에는 접근 가능하지만, Flutter test runner가 연결해야 하는 forwarded VM service port는 Docker container localhost가 아니라 Windows host localhost 쪽에 생성되는 것으로 판단
  - WSL에서 Windows emulator adbd port `172.21.128.1:5555`는 현재 `Connection refused`
- 후속 조치:
  - Windows 관리자 PowerShell에서 emulator adbd port `5555`도 `portproxy`로 노출 검토
  - Docker container 내부 ADB server가 `172.21.128.1:5555`에 직접 `adb connect`한 뒤 integration test를 실행하는 방식 검증
  - 또는 Windows host에서 Flutter CLI를 직접 실행하는 경로를 대안으로 검토

## 2026-07-03 11:06 KST - Android emulator integration test 3차 진행

- 결과: [실패 후 통과]
- 목적: Windows emulator adbd `5555` portproxy와 Docker local ADB server 방식으로 Flutter integration test 최종 검증
- 명령:
  - `nc -vz 172.21.128.1 5555`
  - `TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5555 ./scripts/flutter-docker.sh devices`
  - `TDC114_SMOKE_ENV_FILE=scripts/.env.android-emulator.local TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5555 ./scripts/integration_tests.sh`
  - `./scripts/api-smoke.sh`
- 주요 출력:
  - `172.21.128.1:5555` 연결 성공
  - 1차 Docker local ADB 연결은 `unauthorized`로 표시
  - Windows 사용자 ADB key(`/mnt/c/Users/user/.android/adbkey`)를 git ignored `.android-adb/`에 복사해 Docker `/root/.android`로 마운트
  - 이후 Docker local ADB 연결 성공: `172.21.128.1:5555 device`
  - 최초 integration test 재실행은 앱 테스트 2건 통과 후 real API login test 실패
  - 원인 확인 중 host API smoke가 `502 Bad Gateway`로 실패했고 `baron_backend` 및 Ory 계열 컨테이너가 내려가 있었음
  - Ory/UserFront 컨테이너와 `baron_backend` 재시작 후 `api-smoke.sh` 통과: phone-login, employee list, tenant list, orgchart HTTP 200
  - 최종 integration test 통과: `+3: All tests passed!`
- 후속 조치:
  - `ghcr.io/cirruslabs/flutter:stable` 컨테이너가 매번 새로 뜨며 NDK/CMake를 반복 설치해 Android integration test 시간이 길어짐
  - 반복 실행 시간을 줄이려면 Android SDK/Gradle cache volume을 `scripts/flutter-docker.sh`에 추가 검토

## 2026-07-06 15:15 KST - local 로그인 가능 사용자 확보 및 emulator post-login 점검 재시도

- 결과: [부분 성공]
- 목적: local Baron SSO runtime에서 테스트 번호를 실제 로그인 가능한 사용자로 맞춘 뒤 host smoke와 Android emulator post-login 기능점검을 재검증
- 명령:
  - `./scripts/api-smoke.sh`
  - `/bin/bash -lc 'TDC114_SMOKE_ENV_FILE=scripts/.env.android-emulator.local TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5555 ./scripts/integration_tests.sh'`
  - `/bin/bash -lc 'ADB_SERVER_SOCKET=tcp:172.21.128.1:5037 ./scripts/flutter-docker.sh devices'`
  - `/bin/bash -lc 'TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5555 ./scripts/flutter-docker.sh devices'`
- 주요 작업:
  - local Kratos에 테스트 번호 `010-9136-5338`용 identity 생성
  - 동일 identity ID로 local Baron `users` row 동기화
  - `tdc114plus` `link/init`이 `pendingRef`를 반환하는 것과 `link/poll` 첫 응답이 `authorization_pending`인 것을 직접 확인
- 주요 출력:
  - host `api-smoke.sh` 재통과: `phone-login`, 직원목록, 가족사목록, 조직도 HTTP 200
  - `TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5555` 경로: `failed to connect`, `172.21.128.1:5555 offline`
  - 해당 상태로 `integration_tests.sh`는 Android device를 잡지 못하고 `No supported devices connected.` 종료
  - `ADB_SERVER_SOCKET=tcp:172.21.128.1:5037` 경로: `adb: failed to check server version: protocol fault (couldn't read status)`
- 판단:
  - local 앱/API 쪽 blocker였던 "로그인 가능한 사용자 없음" 문제는 해소됨
  - 현재 blocker는 Android emulator/Windows ADB/portproxy 계층이며, 앱 코드 변경 없이 Windows 측 emulator 재기동 또는 portproxy 복구가 우선
- 다음 조치:
  - Windows `adb devices`가 `device`인지 재확인
  - Windows `5037`, `5555` portproxy 상태 재확인
  - emulator가 `device` 상태로 돌아오면 동일 명령으로 `5-B` post-login 기능점검 재실행

## 2026-07-06 16:20 KST - emulator post-login 기능점검 최종 통과

- 결과: [성공]
- 목적: Windows emulator 복구 후 Android emulator에서 post-login 상태 기능점검과 integration smoke를 최종 통과
- 명령:
  - `/bin/bash -lc 'TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5557 ./scripts/flutter-docker.sh devices'`
  - `/bin/bash -lc 'TDC114_SMOKE_ENV_FILE=scripts/.env.android-emulator.local TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5557 ./scripts/integration_tests.sh'`
- 주요 작업:
  - Windows `adb devices`에서 `emulator-5556 device` 확인
  - 관리자 PowerShell에서 `0.0.0.0:5557 -> 127.0.0.1:5557` portproxy 추가
  - smoke override 타입 처리와 integration test 시나리오를 `assume logged in` 모드와 충돌하지 않도록 정리
- 주요 출력:
  - Docker Flutter devices: `172.21.128.1:5557 device`
  - Android APK 빌드/설치 성공
  - 최종 integration test 결과: `+4: All tests passed!`
- 확인 범위:
  - 로그인 화면 smoke
  - 빈 전화번호 validation smoke
  - post-login 상태 기준 직원검색 진입
  - 즐겨찾기/직원 상세/전화/문자 버튼 노출 smoke

## 2026-07-07 00:00 KST - Phase 6 실제 API smoke 완료, Android integration runtime 기준 재정렬

- 결과: [부분 통과]
- 목적: 실제 API smoke 완료 후 Android emulator bridge 기준 포트와 integration 실행 흐름을 최신 정책 기준으로 재정렬
- 명령:
  - `./scripts/api-smoke.sh`
  - `TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5559 ./scripts/check-android-emulator-env.sh`
  - `TDC114_SMOKE_ENV_FILE=scripts/.env.android-emulator.local TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5559 ./scripts/integration_tests.sh`
- 주요 출력:
  - `api-smoke.sh`: unauthorized guard, validation, phone-login, employee list, tenant list, orgchart까지 통과
  - `check-android-emulator-env.sh`: `172.21.128.1:5559 offline`
  - `integration_tests.sh`: Android preflight를 먼저 수행하도록 보강했고, 현재는 Flutter 실행 전에 `offline` 상태에서 중단
  - 현재 blocker는 앱/API 코드가 아니라 Windows emulator 또는 ADB/portproxy 상태다
- 후속 조치:
  - Windows Android Studio에서 emulator 1대만 실행
  - Windows `adb.exe devices`에서 `device` 상태 확인
  - `5559 -> 127.0.0.1:5559` portproxy 및 방화벽 rule 확인 후 integration 재실행

## 2026-07-07 00:20 KST - Phase 6 Android emulator integration smoke 재통과

- 결과: [통과]
- 목적: 활성 emulator `emulator-5560 device` 기준 bridge `172.21.128.1:5561`로 Android integration runner를 `flutter drive` 방식으로 재정렬한 뒤 실제 smoke를 재검증
- 명령:
  - `TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5561 ./scripts/check-android-emulator-env.sh`
  - `TDC114_SMOKE_ENV_FILE=scripts/.env.android-emulator.local TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5561 ./scripts/integration_tests.sh`
- 주요 출력:
  - preflight 통과: `172.21.128.1:5561 device`
  - `scripts/integration_tests.sh`를 `flutter drive --driver=test_driver/integration_driver.dart --target=integration_test/app_smoke_test.dart` 기준으로 전환
  - Android APK 빌드/설치 성공
  - VM service 연결 성공 후 `All tests passed!`
- 확인 범위:
  - 로그인 화면 smoke
  - 빈 전화번호 validation smoke
  - post-login 상태 기준 직원검색/상세/즐겨찾기 액션 smoke

## 2026-07-07 02:55 KST - 직원검색 상단 칩/조직 drill-down 정책 반영 검증

- 결과: [통과]
- 목적: 직원검색 화면에서 `본인팀 칩 고정 노출`, `다른 회사 선택 후에도 본인팀 칩 유지`, `전체 > 회사 > 부서 > 개인` drill-down 규칙을 정책대로 반영했는지 검증
- 명령:
  - `./scripts/format-dart.sh`
  - `../scripts/flutter-docker.sh test test/widget_test.dart test/directory/directory_filters_test.dart`
- 주요 출력:
  - `DirectoryQuery`에 `department` scope를 추가해 회사/부서 drill-down 조회를 분리
  - 세션 `department`와 tenant 이름을 매칭해 본인팀 고정 칩 slug를 계산하도록 변경
  - widget test 추가:
    - 초기 화면에서 본인팀 칩 노출
    - 다른 회사 선택 후에도 본인팀 칩 유지
    - `전체 > 한맥 > 기술연구소 > 직원목록` drill-down
  - 최종 결과: `All tests passed!`

## 2026-07-07 03:10 KST - manual-postlogin-run 경로 복구 및 emulator 실행 확인

- 결과: [통과]
- 목적: Android emulator 수동 점검 기본 경로인 `manual-postlogin-run.sh`가 실제 `flutter run` 설치/실행까지 이어지는지 확인
- 명령:
  - `./scripts/check-baron-api-env.sh`
  - `./scripts/api-smoke.sh`
  - `TDC114_SMOKE_ENV_FILE=scripts/.env.android-emulator.local TDC114_ADB_CONNECT_ADDRESS=172.21.128.1:5561 ./scripts/manual-postlogin-run.sh`
- 주요 출력:
  - Baron runtime ready-ish, API smoke 전체 통과
  - `scripts/flutter-docker.sh`의 첫 인자 중복 전달 문제를 수정
  - `manual-postlogin-run.sh`를 `flutter-docker.sh run ...` 조합으로 정렬
  - Android APK 빌드 성공, emulator `172.21.128.1:5561 device`에 설치 성공
  - `Launching lib/main.dart on sdk gphone64 x86 64 in debug mode...` 이후 VM service 연결과 앱 실행 확인

## 2026-07-07 04:20 KST - leaf 조직 0건 표시 수정 및 칩 영역 구분선 반영

- 결과: [통과]
- 목적: 실제 화면에서 leaf 조직 칩 선택 시 `검색 결과 0명`이 나오던 원인을 수정하고, 상단 칩 영역과 하위 경로 칩 영역 사이 구분선을 추가
- 주요 작업:
  - leaf 조직 선택 시 직원 조회를 `회사 tenantSlug + department` 조합이 아니라 `선택 tenantSlug` 기준으로 변경
  - mock/fake/smoke repository도 같은 기준으로 정렬
  - 상단 회사/고정팀 칩 영역과 breadcrumb 칩 영역 사이에 `Divider` 추가
- 검증:
  - `../scripts/flutter-docker.sh test test/widget_test.dart test/directory/directory_filters_test.dart`
  - 결과: `All tests passed!`

## 2026-07-08 16:55 KST - 독립형 실기기 전환용 split API base 지원 및 production host 검증

- 결과: [부분 통과]
- 목적: USB 없는 독립형 실기기 테스트를 위해 `로그인은 staging`, `직원/조직 데이터는 production` 조합까지 수용할 수 있도록 앱과 실행 스크립트의 API base 주입 구조를 분리하고, 현재 알려진 production host가 실제 신규앱 route를 제공하는지 확인
- 주요 작업:
  - `AppEnvironment`에 `TDC114_AUTH_API_BASE`, `TDC114_DIRECTORY_API_BASE`, `TDC114_ORGANIZATION_API_BASE` override 추가
  - auth/directory/organization provider가 각자 분리된 base URL을 사용하도록 변경
  - `manual-postlogin-run.sh`, `integration_tests.sh`가 위 override를 `--dart-define`으로 전달하도록 보강
  - staging/production 실기기 env example과 Android 설치 정책 문서에 split-base 규칙 추가
- 검증:
  - `../scripts/flutter-docker.sh test test/widget_test.dart test/auth test/directory test/organization`
  - 결과: `All tests passed!`
  - `TDC114_SMOKE_ENV_FILE=/tmp/tdc114plus-noenv TDC114_API_BASE=https://admin.brsw.kr TDC114_SKIP_AUTH_SMOKE=true ./scripts/api-smoke.sh`
  - 결과: `GET /api/v1/tdc114plus/directory/employees` 기준 HTTP 404 `not_found`
- 해석:
  - `https://admin.brsw.kr`는 Baron org-context 참고 host로는 사용 가능하지만, 현재 확인 기준 `tdc114plus` 신규앱 public API base는 아니다
  - 따라서 USB 없는 독립형 실기기 최종 검증의 외부 blocker는 `신규앱 public TDC114_API_BASE` 확정이다

## 2026-07-08 18:40 KST - 전용 tdc114plus API 전제 철회 및 Swagger 직접 소비 기준으로 재정렬

- 결과: [기준 수정]
- 목적: 사용자 확인 사항인 `tdc114plus 앱 전용 API는 없다`를 정책 문서에 반영하고, 앱이 Baron Swagger 공개 API를 직접 소비하는 방향으로 기준을 수정
- 확인 사실:
  - `https://admin.brsw.kr`는 org-context 참고 host로는 사용 가능하지만 `GET /api/v1/tdc114plus/directory/employees` 기준 HTTP 404
  - `https://sorg.hmac.kr/login?returnTo=%2Fchart`는 HTML 로그인 화면이며 JSON API endpoint가 아님
  - Swagger 캡쳐상 `Public /api/v1/public/orgchart` 같은 조직도 관련 공개 API 흔적은 존재
  - 사용자 확인 기준: `tdc114plus 앱 전용 API는 없고, 저 사이트가 주는 API를 사용해서 앱 내용을 구성`
- 조치:
  - `00_guide_tdc114plus_external_api_usage`, `00_contract_tdc114plus_api`, 타임테이블 문서를 전용 API 전제 철회 기준으로 개정
  - 현재 코드의 `/api/v1/tdc114plus/...` 경로는 확정 계약이 아니라 재매핑 대상이라고 명시
- 다음 단계:
  - Swagger 공개 path 기준으로 직원검색/조직도/로그인 대응 endpoint를 다시 표준화
  - 코드 변경은 실제 공개 path가 확정되기 전까지 보류

## 2026-07-08 19:10 KST - org-context 응답을 현재 앱 화면/모델 기준으로 매핑 판단

- 결과: [진행]
- 목적: `GET /api/v1/integrations/org-context` 설명과 예시 응답을 기준으로, 현재 앱 화면 정책과 데이터 모델에 얼마나 직접 매핑 가능한지 판단
- 확인 사실:
  - `tenantSlug` 기준 subtree 조회가 가능하다
  - `tree`, `tenants[]`, `tenant.members[]` 구조가 존재한다
  - `includeUsers=true`면 조직별 직접 소속 사용자 목록이 들어온다
  - `includeUserIds=true`일 때만 `members[].id`, `members[].phone`가 포함된다
- 판단:
  - 조직도/가족사/하위조직 drilldown 구조에는 매우 잘 맞는다
  - 현재 `Employee.tenantId`, `tenantName`, `tenantSlug`는 상위 tenant 정보를 member에 주입하는 flatten 가공이 필요하다
  - `totalMemberCount`, `profileImageUrl` 같은 필드는 직접 제공되지 않는다
  - 데이터 구조 기준 API로는 유력하지만, 운영 Key 필요 API이므로 모바일 앱 직접 호출 방식은 보안 검토 전까지 확정하지 않는다
- 산출물:
  - `docs/00_guide_tdc114plus_org_context_mapping_2026-07-08.md`

## 2026-07-08 19:35 KST - headless 계약 + Baron 기존 API 활용 기준 재정렬 고정

- 결과: [기준 수정]
- 목적: 사용자 지시에 따라 `바론SSO 문서 정책`과 `현재 일부 구현 흔적` 불일치를 정식 정책으로 고정하고, 옛 `tdc114plus` 전용 API 가정은 기능 보존 테스트를 동반해 단계적으로 제거하는 원칙을 반영
- 조치:
  - `docs/00_policy_tdc114plus_decoupled_api_migration_2026-07-07.md`
  - `docs/00_guide_tdc114plus_work_progress_timetable_2026-07-02.md`
  - `docs/00_guide_tdc114plus_external_api_usage_2026-07-03.md`
  - `docs/00_contract_tdc114plus_api_2026-07-02.md`
- 반영 내용:
  - 신규 앱 기준을 `headless 로그인 계약 + Baron 기존 Swagger API 활용`으로 명시
  - `/api/v1/tdc114plus/...` 경로 가정을 레거시 흔적으로 분류
  - 레거시 제거 순서를 `실제 사용처 확인 -> 대체 path/DTO 반영 -> mock/real 테스트 통과 -> 실제 화면 확인 -> 제거`로 고정
  - 타임테이블에 `레거시 전용 API 흔적 단계적 제거` 단계를 추가
- 다음 단계:
  - 현재 코드의 레거시 path를 `유지`, `교체`, `제거`로 분류
  - `교체` 대상부터 Swagger endpoint 재매핑과 기능 보존 테스트를 병행
## 2026-07-09 TDC114PLUS PKCE/App Link 검증

- RP Client ID: `39d6190d-72f6-4a58-a84f-cdc5ece3e8af`
- Redirect URI: `https://114.hmac.kr/auth/callback`
- `assetlinks.json` 외부 HTTPS 200 및 `application/json` 응답 확인
- debug APK 공기계 설치 성공
- callback URL이 `kr.co.baron.tdc114plus/.MainActivity`를 직접 실행하고 test code를 수신하는 것 확인
- PKCE S256 verifier/challenge/state 생성 계층 구현
- Client Secret 없는 authorization code token 요청 계층 구현
- PKCE 신규 테스트 및 기존 auth 회귀 테스트: 13건 통과
- Flutter analyze: `No issues found`
- 확인된 blocker:
  - 등록 RP는 PKCE 공개 클라이언트이며 Client Secret/개인키가 없음
  - Swagger headless API는 `private_key_jwt client_assertion`을 필수 요구
  - 모바일 공개 RP용 assertion 발급 또는 면제 계약 확인 전 실제 headless 호출 연결 보류