docs(agents): 전체 테스트를 사용자 실행으로 분리한다

docs/agent-guides/문서유지보수.md

@@ -20,10 +20,9 @@
 - 각 task에는 TDD 절차를 명시한다. 기본 형식은 `RED: 실패 테스트 작성/실패 확인`, `GREEN: 최소 구현/통과 확인`, `REFACTOR: 정리/회귀 확인`을 포함한다.
 - 테스트 작성이 현실적으로 불가능한 task는 `TDD 예외 사유`와 `대체 검증 방법`을 task에 명시한다.
 - 각 phase 또는 task에는 실행 명령, 기대 결과, 수동 확인 항목 등 검증 기준을 함께 작성한다.
-- 각 task의 검증 기준에는 focused test와 직접 영향받는 회귀 명령을 우선 명시한다. 전체 회귀는 광범위한 공통 코드 변경,
-  여러 domain/phase 변경, release/final Gate에서 전체 상태 증거를 별도로 요구하는 경우, targeted test만으로 영향 범위를 판단할
-  수 없는 경우 또는 사용자 요청일 때만 포함한다.
-- 계획에서 전체 회귀를 조건부로 두면 실행 조건, 생략 시 기록할 근거와 대체 focused/영향 범위 회귀 명령을 함께 명시한다.
+- 각 Task와 Gate의 에이전트 검증 명령은 구현 기능의 focused test와 직접 영향받는 기능별 회귀로 한정한다. 전체 테스트는 사용자 실행 항목으로 분리한다.
+- 공통 코드·여러 domain/phase 변경·release/final Gate를 자동 전체 테스트 실행 조건으로 작성하지 않는다. `check`/`build`/`clean build`의 간접 전체 테스트도 피하고 필요한 빌드는 `bootJar`로 명시한다.
+- 계획과 결과 보고에 기능별 실행 명령·결과, 전체 테스트 미실행 사실 및 사용자 실행 명령 `./gradlew test`를 남긴다. 기능 범위 완료와 사용자 전체 검증 상태를 구분하며 기존 timeout·실패 이력은 보존한다.
 - 구현 완료 즉시 해당 task 체크박스를 `- [x]`로 갱신한다.
 - 작업 도중 범위가 변경되면 계획 문서 체크리스트를 먼저 업데이트한 뒤 구현한다.
 - 결과 보고 시 개별 task 검증 기록(무엇/왜/어떻게, 실행 명령, 결과)은 해당 task 아래에 한국어로 남긴다.

docs/agent-guides/실행명령어.md

@@ -3,25 +3,33 @@
 ## 실행 기준
 - 아래 명령은 저장소 루트(`/Users/klaus/Develop/sodalive/Server/sodalive`)에서 실행한다.
 - 변경 범위에 맞는 최소 명령으로 검증하고, 결과는 계획 문서 하단 검증 기록에 남긴다.
-- 검증은 focused test → 영향받는 package/feature 회귀 → 전체 회귀 순서로 범위를 넓힌다.
-- 전체 회귀 테스트(`./gradlew test`, `./gradlew check`, 전체 `build`)는 실행 시간이 길므로 매 Task나 일반적인 작은 변경에서
-  관성적으로 실행하지 않는다.
-- 공통 인증·보안·예외·설정·serialization처럼 영향 범위가 넓은 코드 변경, 여러 domain/phase에 걸친 변경, release/final Gate에서
-  전체 상태 증거를 별도로 요구하는 경우, targeted test만으로 영향 범위를 판단할 수 없는 실패 또는 사용자 명시 요청일 때만
-  전체 회귀를 실행한다.
-- 전체 회귀를 생략하면 실행하지 않은 사실, 생략 근거와 대신 실행한 focused/영향 범위 회귀 명령을 계획 문서에 기록한다.
+- 에이전트는 구현 중인 기능의 focused test와 직접 영향받는 package/feature 회귀만 각각 실행한다. `--tests`로 대상 클래스·메서드·패키지를 명시한다.
+- 전체 테스트는 10분 실행 제한으로 완료되지 않는 경우가 많으므로 사용자가 직접 실행한다. 에이전트는 무필터 `./gradlew test`를 자동 실행하거나 timeout 후 재시도하지 않는다.
+- 공통 코드 변경, 여러 domain/phase 변경, release/final Gate라도 자동으로 전체 테스트로 확대하지 않는다. 영향받는 기능을 식별해 각각 검증하고 확인하지 못한 범위를 보고한다.
+- `./gradlew check`, `./gradlew build`, `./gradlew clean build`도 전체 테스트를 포함하므로 에이전트가 자동 실행하지 않는다. 빌드 산출물 검증이 필요하면 `./gradlew bootJar`를 사용하고 기능별 테스트와 구분해 기록한다.
+- 계획 문서와 최종 보고에는 실행한 기능별 테스트 명령·결과, 전체 테스트 미실행 사실, 사용자 실행 명령 `./gradlew test`를 남긴다. 기능별 성공을 전체 테스트 성공으로 표현하지 않는다.
+- 전체 테스트의 사용자 실행 대기는 기능 범위 완료를 막지 않는다. 기능별 테스트 실패나 미검증 위험은 별도로 명시하며 실패를 무시하거나 테스트를 완화하지 않는다.
 
 ## Build/Lint/Test
 
-아래는 사용 가능한 명령 목록이며 모든 변경에서 전부 실행하라는 의미가 아니다.
+에이전트는 변경 범위에 필요한 명령만 선택한다. 아래 `--tests`는 기존 홈 기능의 예시이며 실제 작업 대상에 맞게 바꾼다.
 
 ```bash
 ./gradlew tasks --all
 ./gradlew bootRun
-./gradlew build
-./gradlew clean build
-./gradlew test
-./gradlew check
+./gradlew test --tests 'kr.co.vividnext.sodalive.v2.creator.channel.home.*' --tests 'kr.co.vividnext.sodalive.v2.api.creator.channel.home.*'
+./gradlew bootJar
 ./gradlew ktlintCheck
 ./gradlew ktlintFormat
 ```
+
+사용자가 직접 실행하는 전체 검증 명령:
+
+```bash
+./gradlew test
+./gradlew check
+./gradlew build
+./gradlew clean build
+```
+
+위 명령은 목적에 맞게 하나를 선택한다. 전체 테스트 확인만 필요하면 `./gradlew test`로 충분하다.

docs/agent-guides/작업절차.md

@@ -29,8 +29,8 @@
   전에는 goal이나 Phase Gate를 완료 처리하지 않는다.
 - 변경 중: 완료된 Task와 기존 검증 기록은 되돌리거나 삭제하지 않는다. 후속 리뷰에서 발견한 회귀는 별도 Task/Goal로 누적한다.
 - 변경 후: 변경 범위의 focused test를 우선 실행하고, 공유 경계와 직접 영향받는 package/feature 회귀까지만 단계적으로 확장한다.
-- 변경 후: 전체 회귀 테스트는 공통 인증·보안·예외·설정 등 광범위한 변경, 여러 domain/phase 변경, release/final Gate에서 전체
-  상태 증거를 별도로 요구하는 경우, targeted test만으로 영향 범위를 판단할 수 없는 실패 또는 사용자 명시 요청일 때만 실행한다.
-- 변경 후: 전체 회귀 테스트를 실행하지 않으면 생략 사실과 근거, 대신 실행한 focused/영향 범위 회귀 명령을 검증 기록에 남긴다.
+- 변경 후: 전체 테스트는 사용자가 직접 수행한다. 공통 코드·여러 domain/phase 변경이나 release/final Gate에서도 에이전트는 관련 기능을 각각 검증하며 전체 테스트로 자동 확대하지 않는다.
+- 변경 후: 전체 테스트를 포함하는 무필터 `test`, `check`, `build`, `clean build`를 자동 실행하지 않는다. 필요한 빌드 검증은 `bootJar`로 분리한다.
+- 변경 후: 검증 기록과 최종 보고에 실행한 기능별 명령·결과, 미검증 범위와 사용자용 전체 테스트 명령 `./gradlew test`를 남긴다. 전체 테스트 사용자 실행 대기만으로 기능 범위 완료를 막거나 전체 성공으로 표시하지 않는다.
 - 변경 후: 각 task의 검증 결과는 해당 task 아래에 무엇을, 왜, 어떻게 검증했는지, 실행 명령과 결과를 한국어로 누적 기록한다.
 - 변경 후: 여러 task/phase에 걸친 회귀 검증, 전체 빌드/포맷 검증, 문서 변경 범위 확인처럼 전체에 해당하는 검증은 계획 문서 하단의 검증 기록에 누적한다.