docs(agent): 테스트 범위를 로직으로 제한한다

AGENTS.md

@@ -121,6 +121,9 @@ Strong success criteria let you loop independently. Weak criteria ("make it work
 - 작업 도중 범위가 변경되면 계획/TASK 문서 체크리스트를 먼저 업데이트한 뒤 구현한다.
 - 특정 Phase 또는 Task에 직접 대응되는 검증 기록은 해당 Phase 또는 Task 아래에 한국어로 남긴다.
 - 여러 Phase에 걸치거나 문서 전체에 해당하는 통합 검증, 회귀 검증, 최종 수동 확인 기록은 문서 최하단 `Verification Log`에 한국어로 남긴다.
+- 자동 테스트는 기본적으로 `app/src/test`의 로직/local unit test만 작성하고 실행한다.
+- 사용자가 명시적으로 요청하지 않으면 `app/src/androidTest` UI/계측 테스트를 작성하거나 `connectedDebugAndroidTest`, 기기·에뮬레이터 UI 조작, 스크린샷·시각 QA를 실행하지 않는다.
+- UI 변경의 테스트 코드는 adapter 분기, mapper, formatter, presentation model, 라우팅처럼 화면 표현을 결정하는 로직만 검증하며 View 크기·간격·constraint·visibility 등 레이아웃 속성을 직접 검증하지 않는다.
 - 코드 리뷰, 코드 품질 점검, 완료 Phase 재검토를 수행하면 `docs/sample/sample-review.md`를 참조해 `docs/[날짜]_구현할내용한글/reviews/[리뷰범위]-review.md`에 결과를 기록한다.
 - 리뷰 보고서명의 `[리뷰범위]`는 `phase<번호>-<구현 내용을 나타내는 영문 kebab-case>` 형식으로 작성한다. 예: `phase2-main-home-recommendation-review.md`
 - 일반 빌드, 테스트, 린트 실행 결과는 리뷰 보고서를 만들지 않고 계획/TASK 문서의 Task별 검증 기록 또는 `Verification Log`에 남긴다.

docs/agent-guides/build-test-style.md

@@ -34,13 +34,14 @@
 ./gradlew :app:test
 ./gradlew :app:testDebugUnitTest
 ./gradlew :app:testReleaseUnitTest
-./gradlew :app:connectedDebugAndroidTest
 ```
 
 주의:
-- `:app:connectedDebugAndroidTest`는 기기/에뮬레이터 연결이 필요하다.
+- 기본 자동 검증은 `app/src/test`의 로직/local unit test만 사용한다.
+- 사용자가 명시적으로 요청하지 않으면 `app/src/androidTest` UI/계측 테스트를 작성하거나 `:app:connectedDebugAndroidTest`를 실행하지 않는다.
+- 사용자가 명시적으로 요청하지 않으면 기기·에뮬레이터 UI 조작, 스크린샷 캡처, 시각 QA를 검증 계획이나 완료 증거에 포함하지 않는다.
+- UI 변경은 adapter 분기, mapper, formatter, presentation model, 라우팅 등 화면 표현을 결정하는 로직만 테스트한다. View 크기·margin·padding·constraint·visibility 같은 레이아웃 속성 테스트는 작성하지 않는다.
 - `app/build.gradle`에 `lint { checkReleaseBuilds false }`가 있어 릴리스 린트는 `:app:lintRelease`를 명시 실행해야 한다.
-- 현재 `app/src/androidTest`에는 테스트 소스가 없으므로 계측 테스트 명령은 신규 테스트 추가 시 사용한다.
 
 ### 1) 단일 테스트 실행 (중요)
 로컬 단위 테스트(`app/src/test`)는 `--tests` 필터를 사용한다.
@@ -144,14 +145,6 @@ Chat Action Phase 테스트 예시:
 - 한글 테스트명을 `--tests`로 실행할 때도 클래스명과 메서드명을 포함한 전체 문자열을 따옴표로 감싼다.
 - 메서드 매칭이 불안정하면 클래스 단위로 먼저 실행한다.
 
-### 2) 계측 테스트 클래스/메서드 타깃 실행
-Gradle 인자 방식:
-```bash
-./gradlew :app:connectedDebugAndroidTest -Pandroid.testInstrumentationRunnerArguments.class=kr.co.vividnext.sodalive.SomeInstrumentedTest
-./gradlew :app:connectedDebugAndroidTest -Pandroid.testInstrumentationRunnerArguments.class=kr.co.vividnext.sodalive.SomeInstrumentedTest#someMethod
-```
-
-ADB 대안:
-```bash
-adb shell am instrument -w -e class kr.co.vividnext.sodalive.SomeInstrumentedTest#someMethod <test_package>/<runner>
-```
+### 2) UI/계측 테스트 예외
+- UI/계측 테스트가 반드시 필요한 경우에도 사용자의 명시 요청을 먼저 확인한다.
+- 승인된 작업에서만 해당 Task의 계획 문서에 대상, 실행 명령, 종료 조건과 정리 절차를 기록하고 실행한다.

docs/agent-guides/code-style.md

@@ -41,6 +41,7 @@
 - 테스트 추가 시 단일 실행 명령 예시도 `docs/agent-guides/build-test-style.md`에 갱신한다.
 - 신규 테스트는 로직에 대한 테스트 코드만 작성한다. View 크기, margin, padding, constraint, visibility 같은 UI 레이아웃/표현 속성 검증 테스트는 작성하지 않는다.
 - UI 작업에서 테스트가 필요하면 adapter view type 선택, rank 구간 분류, mapper, formatter, presentation model, visibility를 결정하는 순수 로직처럼 화면 표현을 결정하는 입력/출력 계약만 검증한다.
+- 사용자가 명시적으로 요청하지 않으면 `app/src/androidTest` UI/계측 테스트를 추가하거나 기기·에뮬레이터 UI 조작, 스크린샷·시각 QA를 실행하지 않는다.
 
 ### 6) 주석
 - 의미 단위별로 주석을 작성한다.

docs/agent-guides/work-plan-docs.md

@@ -5,7 +5,7 @@
 ## 작업 절차 체크리스트
 - 변경 전: 유사 기능 코드를 먼저 찾아 네이밍/예외/응답 패턴을 맞춘다.
 - 변경 중: 공개 API 스키마를 임의 변경하지 말고 작은 단위로 안전하게 수정한다.
-- 변경 후: 최소 단일 테스트(`--tests`) 또는 `./gradlew :app:test`를 실행하고 필요 시 `./gradlew :app:ktlintCheck`를 수행한다.
+- 변경 후: `app/src/test`의 최소 로직 단일 테스트(`--tests`) 또는 `./gradlew :app:test`를 실행하고 필요 시 `./gradlew :app:ktlintCheck`를 수행한다.
 
 ## 작업 계획 문서 규칙 (docs)
 - 모든 구현 작업은 PRD 문서와 구현 계획/TASK 문서가 모두 준비된 뒤에 시작한다.
@@ -38,8 +38,10 @@
 - 각 Task 또는 Phase Gate에는 독립적으로 실행·판정할 수 있는 목표, 시작 조건, 완료 증거, 범위 밖 항목을 명시한다.
 - 각 Task에는 구현 시 생성·수정·확인할 파일 경로와 필요한 인터페이스를 명시한다.
 - 구현 Task의 실행 단계는 `RED → RED 확인 → GREEN → GREEN 확인 → REFACTOR` 순서의 체크박스로 작성하고 완료 즉시 `- [x]`로 갱신한다.
+- 테스트 계획은 `app/src/test`의 로직/local unit test로 한정한다. 사용자가 명시적으로 요청하지 않으면 `app/src/androidTest`, `connectedDebugAndroidTest`, 기기·에뮬레이터 UI 조작, 스크린샷·시각 QA를 Task·Gate·완료 증거에 포함하지 않는다.
+- UI 변경의 자동 테스트는 adapter 분기, mapper, formatter, presentation model, 라우팅 같은 입력/출력 로직만 대상으로 하며 레이아웃 속성을 직접 검증하지 않는다.
 - 테스트 작성이 현실적으로 불가능한 read-only 리뷰·문서·외부 확인 Task에는 `TDD 예외 사유`와 실행 명령·대조표·수동 확인을 포함한 `대체 검증 방법`을 명시한다.
-- 각 Phase 또는 Task에는 실행 명령, 기대 결과, 수동 확인 항목 등 검증 기준을 함께 작성한다.
+- 각 Phase 또는 Task에는 실행 명령과 기대 결과 등 검증 기준을 함께 작성한다. 수동 확인은 사용자가 명시적으로 요청한 경우에만 포함한다.
 - 작업 도중 범위가 변경되면 계획 문서 체크리스트를 먼저 업데이트한 뒤 구현한다.
 - 실제 실행 결과는 샘플의 `Progress` 형식에 맞춰 무엇을/왜/어떻게 수행했는지와 남은 항목을 한국어로 누적한다.
 - 특정 phase 또는 task에 직접 대응되는 검증 기록(무엇/왜/어떻게, 실행 명령, 결과)은 해당 phase 또는 task 아래에 `검증 기록`으로 한국어로 남긴다.

docs/sample/sample-plan-task.md

@@ -49,6 +49,7 @@
 - 의존성: 실제 소비 Task에서 필요한 최소 dependency만 추가한다.
 - 계약: 제공되지 않은 endpoint, DTO, enum, 오류 status/key와 validation 상한을 추정하지 않는다.
 - backend 구현 전 UI 확인이 필요하면 제공 계약 기반 explicit mock mode를 사용하고 실제 404 자동 fallback·production mock을 금지하며 mock/server 완료 증거를 분리한다.
+- 테스트 범위: `app/src/test`의 로직/local unit test만 계획한다. 사용자가 명시적으로 요청하지 않으면 `app/src/androidTest`, 기기·에뮬레이터 UI 조작, 스크린샷·시각 QA를 Task·Gate·완료 증거에 포함하지 않는다. UI 변경은 화면 표현을 결정하는 입력/출력 로직만 테스트하고 레이아웃 속성을 직접 검증하지 않는다.
 - 구현: 모든 구현 Task는 아래 `RED → GREEN → REFACTOR` 순서를 체크박스에 명시하고, 가장 작은 실패 test에서 시작해 최소 구현으로 통과시킨다.
 - 검증: focused test에서 시작해 영향받는 package/feature 회귀로 확장한다. 전체 회귀는 공통 경계 변경, 여러 domain/phase 변경,
   release/final Gate에서 전체 상태 증거를 별도로 요구하는 경우, targeted test만으로 영향 범위를 판단할 수 없는 실패 또는 사용자