diff --git a/journey/plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md b/journey/plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md
index 09fe88c..60d9e8a 100644
--- a/journey/plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md
+++ b/journey/plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md
@@ -15,10 +15,12 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, plans]
 
 ## 결정
 - 이번 문제는 `rb8001` 코드가 아니라 `배포 인프라 경로` 문제로 다룬다.
-- 따라서 수정 우선순위는 `workflow -> secret/variable -> SSH 검증 -> task 로그` 순서다.
+- 따라서 수정 우선순위는 `workflow가 읽는 .env.deploy 복구 -> 구주소 예시 제거 -> 필요 시 secret/variable화 -> SSH 검증 -> task 로그` 순서다.
 
 ## 범위
 - 포함:
+  - `rb8001/.env.deploy` 실파일 복구 또는 대체 주입 경로 확정
+  - `.env.deploy.example`의 구주소/구포트 제거
   - 24 배포 대상 host/port/path SSOT 확인
   - Gitea Actions secret/variable 교정
   - `cicd.yml` 하드코딩 경로 제거 또는 SSOT 기준 교정
@@ -29,10 +31,11 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, plans]
 
 ## 실행 단계
 1. `rb8001/.gitea/workflows/cicd.yml`의 deploy host/port/path 참조를 확인한다.
-2. Gitea의 `SSH_HOST_51124`, 포트, 배포 경로 관련 secret/variable이 `192.168.0.106` 기준과 일치하는지 확인한다.
-3. 23 제어면에서 같은 값으로 24 실행면 SSH 접속이 실제 되는지 검증한다.
-4. 하드코딩 값이 있으면 제거하고 `DEPLOY_PROJECT_DIR` 또는 단일 기준 변수로 맞춘다.
-5. 테스트 커밋 또는 재실행으로 Actions task가 실제 실행되고, 24 서버 컨테이너가 재시작되는지 검증한다.
+2. `rb8001/.env.deploy`를 다른 서비스와 같은 형식으로 복구하고 `192.168.0.106:51124` 기준으로 맞춘다.
+3. `.env.deploy.example`의 구주소 `192.168.219.45:51123`를 제거한다.
+4. 필요 시 Gitea Actions secret/variable 기반으로 전환하되, 값 기준은 여전히 `192.168.0.106`, `51124`, 실제 배포 경로로 고정한다.
+5. 23 제어면에서 같은 값으로 24 실행면 SSH 접속이 실제 되는지 검증한다.
+6. 테스트 커밋 또는 재실행으로 Actions task가 실제 실행되고, 24 서버 컨테이너가 재시작되는지 검증한다.
 
 ## 완료 기준
 - `cicd.yml` task가 `0s` 종료가 아니라 실제 실행 로그를 남긴다.
diff --git a/journey/research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md b/journey/research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md
index 176f39e..cf228b2 100644
--- a/journey/research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md
+++ b/journey/research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md
@@ -20,21 +20,22 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, research]
 - 배포 경로 기준: 서비스별 하드코딩이 아니라 workflow 변수/secret의 단일 기준 사용
 
 ## 이번 문제에 가장 가까운 원인 후보
-1. `SSH_HOST_51124` 또는 대응 secret/variable이 아직 구 IP를 가리킨다.
-2. SSH 포트가 현재 실제 접속 규칙과 어긋난다.
-3. workflow가 `DEPLOY_PROJECT_DIR` 대신 오래된 절대경로를 사용한다.
-4. runner는 뜨지만 실제 task가 시작 조건을 못 맞춰 즉시 종료된다.
+1. `rb8001` 저장소에 `.env.deploy` 실파일이 없어 workflow가 시작 직후 필수 파일 검증에서 실패한다.
+2. `.env.deploy.example`가 아직 `192.168.219.45:51123`를 가리켜 복원하더라도 잘못된 값을 주입할 위험이 있다.
+3. repo-level Actions secrets/variables가 비어 있어, 현재 workflow를 대체할 다른 배포값 주입 경로도 없다.
+4. workflow가 `DEPLOY_PROJECT_DIR` 대신 오래된 절대경로를 사용한다.
 
 ## 이번 이슈에서 중요한 해석
 - 수동 배포가 같은 서버에서 정상 성공했기 때문에 `rb8001` 코드, Dockerfile, compose 자체가 주원인일 가능성은 낮다.
-- 따라서 우선순위는 `workflow 정의`, `Actions secret/variable`, `23 -> 24 SSH 대상값` 검증이다.
+- 따라서 우선순위는 `workflow가 읽는 실제 배포값 파일(.env.deploy)`, `예시 파일의 구주소`, `보완용 secret/variable 부재` 확인이다.
 - 기존 인프라 문서와도 일치하게, 이런 배포 실패는 대개 애플리케이션보다 `경로/권한/런타임 값`의 단일 기준 붕괴에서 발생한다.
 
 ## 닫힘에 필요한 최소 확인
 - `cicd.yml`의 실제 deploy host/port/path 참조값
-- Gitea Actions secret/variable의 현재값이 24 SSOT와 일치하는지
-- 23 제어면에서 24 실행면으로 SSH가 실제 성공하는지
+- `rb8001/.env.deploy` 실파일 존재 여부
+- `.env.deploy.example`의 구주소 제거 여부
+- Gitea Actions secret/variable 부재를 유지할지, 변수 기반으로 바꿀지 결정
 - task가 왜 `0s`로 끝났는지 runner/task 로그 확인
 
 ## 결론
-- 현재 가장 강한 가설은 `24 runtime SSOT는 192.168.0.106으로 정리됐지만, 자동 배포 경로 일부는 아직 그 기준으로 완전히 수렴하지 않았다`는 것이다.
+- 현재는 가설 수준을 넘어서, `rb8001` 자동 배포 경로가 `.env.deploy` 부재와 구주소 예시 파일 때문에 실제 SSOT에 수렴하지 않았음`이 실증된 상태다.
diff --git a/journey/troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md b/journey/troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md
index 391d433..137c5ea 100644
--- a/journey/troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md
+++ b/journey/troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md
@@ -19,10 +19,15 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, troubleshooting]
 - 24 실행면의 공용 런타임 값은 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`가 SSOT다.
 - 기존 인프라 문서상 배포 실패의 대표 원인은 `DEPLOY_PROJECT_DIR` 같은 단일 기준을 안 쓰고 서비스별 하드코딩 경로/값을 남긴 경우였다.
 - 이번 건은 자동 배포가 실행되지 않았지만, 같은 서버에서 수동 배포는 정상 성공했다.
+- `rb8001/.gitea/workflows/cicd.yml`은 `secrets.*`나 `vars.*`가 아니라 저장소 루트 `.env.deploy`를 직접 읽도록 작성돼 있다.
+- 현재 `rb8001` 저장소에는 `.env.deploy`가 없고 `.env.deploy.example`만 존재한다.
+- `rb8001/.env.deploy.example`에는 아직 `DEPLOY_SSH_HOST=192.168.219.45`, `DEPLOY_SSH_PORT=51123`가 남아 있다.
+- 반면 `skill_email`, `robeing-monitor`, `skill-rag-file`의 실제 `.env.deploy`는 모두 `DEPLOY_SSH_HOST=192.168.0.106`, `DEPLOY_SSH_PORT=51124`로 맞춰져 있다.
+- Gitea API 기준 `rb8001` 저장소의 Actions secrets/variables 목록은 현재 빈 배열(`[]`)이다.
 
 ## 현재 해석
 - 애플리케이션 코드 자체 문제보다는 `Gitea Actions -> 24 배포 경로`의 SSOT 불일치 가능성이 높다.
-- 특히 `workflow secret/host/port/path` 중 하나 이상이 현재 24 runtime SSOT(`192.168.0.106`, 올바른 SSH 포트, 실제 배포 경로)와 어긋났을 가능성이 크다.
+- 특히 `rb8001`은 다른 서비스와 달리 `.env.deploy` 실파일이 없고, 예시 파일도 구주소를 가리켜 자동 배포 경로가 SSOT에 수렴하지 않은 상태다.
 
 ## 직접 영향
 - `git push origin main`이 배포 완료를 의미하지 않게 된다.