diff --git a/book/300_architecture/311_backend_coding_principles.md b/book/300_architecture/311_backend_coding_principles.md
index 620540d..d4a3af9 100644
--- a/book/300_architecture/311_backend_coding_principles.md
+++ b/book/300_architecture/311_backend_coding_principles.md
@@ -321,6 +321,14 @@ utils
 - ❌ 복잡한 규칙 체인 구축 (LLM이 더 정확하고 유지보수 용이)
 - ❌ 새로운 패턴마다 규칙 추가하는 방식 (LLM이 자동으로 처리)
 - ❌ "규칙으로 처리 가능하면 규칙 사용" 사고방식 (LLM 우선 사고)
+- ❌ 질문별 `if` 분기와 질문별 프롬프트/답변 문장을 코드에 누적해 시나리오를 닫는 방식
+- ❌ 대표 질문 몇 개만 통과시키는 특례 처리로 `완료` 판단하는 방식
+- ❌ `검색 hit 있음 = 성공`처럼 취급하고 질문 적합도/근거 부족 판정을 생략하는 방식
+
+### 추가 강제 규칙
+- LLM/RAG 응답 경로는 `질문 유형 계약`, `근거 채택 규칙`, `근거 부족 시 실패 규칙`을 공통 구조로 먼저 정의해야 합니다.
+- 질문이 늘어날수록 분기와 프롬프트가 늘어나는 구조는 설계 실패로 간주합니다.
+- 특정 질문 대응이 필요하면 질문별 특례를 추가하기 전에 공통 계약으로 올릴 수 없는지 먼저 검토합니다.
 
 ### 장점
 - **유연성**: 새로운 패턴에 대한 규칙 추가 없이 LLM이 자연스럽게 처리
@@ -400,6 +408,46 @@ utils
 - **실제 테스트 필수**: 코드 수정 후 추측하지 말고 실제로 테스트 (curl, Slack 직접 사용, DB 조회)
 - **컨테이너 테스트 파일 반영**: tests 디렉토리는 볼륨 마운트 아님 (빌드 시 COPY). 새 테스트 파일 추가 시 `docker cp [파일경로] [컨테이너명]:/code/tests/` 사용 또는 컨테이너 재빌드
 
+## 18-1. 변경 실행 워크플로우
+
+**핵심 원칙**: 변경은 `계획 -> 구현 -> 테스트 -> push -> 배포 대기 -> 실제 검증 -> worklog` 순서를 기본으로 고정합니다.
+
+### 기본 순서
+1. **계획 확인**
+- 열린 `troubleshooting/scenario`와 대응 `research/plans`를 먼저 확인합니다.
+- 이번 변경이 어떤 문서를 닫기 위한 실행인지 먼저 고정합니다.
+
+2. **구현**
+- 계획 범위 안에서만 수정합니다.
+- 질문별 특례 하드코딩, 광범위 폴백, 임시 우회로 닫지 않습니다.
+
+3. **테스트**
+- 관련 단위 테스트, 통합 테스트, 최소 재현 질문셋을 먼저 돌립니다.
+- 가능하면 실패 케이스도 함께 검증합니다.
+
+4. **push**
+- 자동 배포 레포는 `git push origin main`을 실행합니다.
+- 수동 배포 레포는 해당 서비스 배포 절차를 따릅니다.
+
+5. **배포 대기**
+- Actions/배포 파이프라인 완료를 기다립니다.
+- 성공 메시지만으로 완료 판단하지 않습니다.
+
+6. **실제 검증**
+- `docker ps`, 헬스체크, 실제 API 응답, 실제 로그를 확인합니다.
+- 이번 변경의 재현 질문셋/시나리오 기준 질문을 운영 경로에서 다시 확인합니다.
+
+7. **문서 마감**
+- 문제 없이 끝났으면 `worklog`를 남깁니다.
+- 실행 중 새 문제가 생기면 `worklog`가 아니라 `troubleshooting`으로 되돌립니다.
+- `plans`는 완료 보고서로 길게 덮어쓰지 않고, 상태와 연결 문서만 갱신합니다.
+
+### 완료 금지 기준
+- 테스트 전 `push`하고 끝냈다고 말하지 않습니다.
+- 배포 완료 메시지만 보고 끝냈다고 말하지 않습니다.
+- 실제 재현 질문/실제 응답/실제 로그 확인 없이 `해결`이라고 말하지 않습니다.
+- 문제가 남아 있으면 `worklog`로 보내지 않습니다.
+
 ## 19. 리팩토링 시 로직 상실 방지 원칙
 
 ### 필수 체크리스트 (코드 이동/리팩토링 전)
diff --git a/book/600_appendix/650_용어집.md b/book/600_appendix/650_용어집.md
index 78d3537..451853f 100644
--- a/book/600_appendix/650_용어집.md
+++ b/book/600_appendix/650_용어집.md
@@ -19,6 +19,12 @@ LLM 출력을 후처리하여 로빙의 고유한 성격과 윤리적 기준을
 ### 경험치 (Experience Points, XP)
 로빙이 작업을 수행하거나 사용자와 상호작용할 때 획득하는 포인트. 일정량 누적 시 레벨업이 발생함.
 
+### 공통 계약 (Common Contract)
+특정 기능 경로가 따라야 하는 공통 `입력-판단-출력` 약속. 질문별 예외 문장을 계속 추가하는 대신, 질문 유형 분류, 근거 채택 기준, 실패 조건 같은 규칙을 한 번 정의해 코드·프롬프트·테스트가 함께 따르도록 고정한 기준을 뜻한다.
+관련 문서:
+- [311_backend_coding_principles.md](../300_architecture/311_backend_coding_principles.md)
+- [Company X RAG 답변합성 시나리오·트러블 동시종결 리서치](../../journey/research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md)
+
 ## ㄷ
 
 ### 디지털 동료 (Digital Colleague)
diff --git a/journey/plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md b/journey/plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md
new file mode 100644
index 0000000..05a578d
--- /dev/null
+++ b/journey/plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md
@@ -0,0 +1,138 @@
+---
+tags: [plans, companyx, rag, answer-composition, scenario, troubleshooting]
+---
+
+# Company X RAG 답변합성 시나리오·트러블 동시종결 계획
+
+**작성일**: 2026-03-15  
+**상태**: planned  
+**목표**: Company X 내부문서 근거응답 경로를 `대표 질문 특례 처리`에서 `공통 계약 기반 답변합성` 구조로 바꿔, 대응 troubleshooting 문서와 scenario 문서를 함께 닫습니다.
+
+## 관련 문서
+- [Company X RAG 답변 합성 회귀](../troubleshooting/260312_companyx_rag_answer_composition_regression.md)
+- [Company X 내부 문서 근거응답 사용자 시나리오](../scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md)
+- [Company X RAG 답변합성 시나리오·트러블 동시종결 리서치](../research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md)
+- [Company X RAG 스킬 문서](../../skills/companyx-rag/SKILL.md)
+
+## 1. 이번 계획의 결정
+- 이 문제는 `검색 인프라 확장`보다 `답변 합성 계약 부재` 문제로 다룹니다.
+- 질문별 `if` 분기, 질문별 direct answer, 질문별 프롬프트 추가로 닫지 않습니다.
+- `Company X grounding` 경로에 공통 계약 3개를 먼저 고정합니다.
+  1. 질문 유형 계약
+  2. 근거 채택 계약
+  3. 근거 부족 시 실패 계약
+- 성공 기준은 `검색 hit 존재`가 아니라 `직접 답 + 질문 적합 근거 또는 명시적 부족 안내`로 바꿉니다.
+
+## 2. 범위
+- 포함:
+  - `rb8001/app/services/companyx_grounding_service.py`
+  - Company X 재오픈 기준 질문 3개의 응답 계약
+  - `SKILL.md`와 코드 계약 정합화
+  - 테스트 보강
+- 제외:
+  - Company X 전체 문서셋 대규모 확대
+  - 다른 RAG 경로 공통화
+  - Prompt DB 전면화
+  - `skill-rag-file` 자체 리팩토링
+
+## 3. 공통 계약 고정안
+
+### A. 질문 유형 계약
+- 최소 유형은 아래 4개로 고정합니다.
+  - 설명형
+  - 사실 확인형
+  - 수치 확인형
+  - 재정리형
+- 판단 결과는 코드 내부 enum 또는 동등한 상수로 다룹니다.
+- 질문별 문자열 특례가 아니라 유형별 처리로 묶습니다.
+
+### B. 근거 채택 계약
+- 검색 결과가 있다고 바로 근거로 채택하지 않습니다.
+- 채택 기준:
+  - 질문의 핵심 엔티티와 직접 관련이 있어야 합니다.
+  - 질문 유형에 맞는 문서여야 합니다.
+  - 상위 결과라도 질문과 무관하면 버립니다.
+- `relevance_score`는 후보 신호일 뿐, 최종 성공 판정 기준이 아닙니다.
+
+### C. 실패 계약
+- 아래 경우는 성공처럼 반환하지 않습니다.
+  - 검색 결과 0개
+  - 검색 결과는 있으나 질문과 무관
+  - 수치/규정 질문인데 단정 가능한 근거가 없음
+- 실패 응답은 아래 셋 중 하나로 고정합니다.
+  - `문서 없음`
+  - `질문과 맞는 문서 미확인`
+  - `내부 문서만으로는 단정 불가`
+
+## 4. 구현 원칙
+- `SKILL.md`의 답변 순서(`direct answer -> evidence documents -> short evidence summary`)를 코드 계약으로 내립니다.
+- 질문별 direct answer 하드코딩을 더 늘리지 않습니다.
+- 질문 유형 판정과 근거 채택 판정은 별도 함수로 분리합니다.
+- `검색됨`과 `답할 수 있음`을 같은 상태로 취급하지 않습니다.
+- 메타 대화(`어떤 부분이 더 필요하신지...`)는 실패 기본 경로로 사용하지 않습니다.
+
+## 5. 구현 단계
+
+### Phase 1. 구조 분리
+- `companyx_grounding_service`에서 아래 책임을 분리합니다.
+  - 질문 유형 판정
+  - query candidate 생성
+  - retrieval 결과 수집
+  - 근거 채택 판정
+  - direct answer 생성
+  - failure answer 생성
+- 목표:
+  - 현재 질문별 특례 분기와 generic fallback이 어디서 작동하는지 코드상 경계를 명확히 나눕니다.
+
+### Phase 2. 질문 유형 계약 도입
+- 최소 4개 유형 분류 함수를 추가합니다.
+- 재오픈 기준 질문 3개는 각 유형에 명시 매핑돼야 합니다.
+  - `컴퍼니엑스의 투자사는 몇개야?` -> 수치 확인형
+  - `그럼 컴퍼니엑스 내부 규정 상 휴가는 얼마나 쓸 수 있어?` -> 사실 확인형 또는 규정 확인형 성격
+  - `오늘전통 프로그램을 Company X가 옐로펀치랑 같이 운영한다는 근거 있어?` -> 사실 확인형
+
+### Phase 3. 근거 채택 판정 추가
+- 검색 결과를 그대로 상위 3개 노출하지 않습니다.
+- 질문 유형에 맞지 않는 청크는 버립니다.
+- 필요 최소 판정:
+  - 엔티티 일치 여부
+  - 문서 성격 일치 여부
+  - 답변 가능 근거인지 여부
+- `휴가` 질문에 `todaytradition` 청크가 잡히는 경우는 `무관한 결과`로 실패 처리해야 합니다.
+
+### Phase 4. direct/failure 응답 계약 재구성
+- direct answer는 유형별 템플릿과 채택된 근거 상태를 바탕으로 생성합니다.
+- 질문별 하드코딩 문장을 추가하지 않습니다.
+- failure answer는 `문서 없음 / 문서 미확인 / 단정 불가` 중 하나로 분명히 떨어져야 합니다.
+
+### Phase 5. 테스트 고정
+- 최소 테스트:
+  - 대표 성공 질문은 계속 성공
+  - 투자사 질문은 generic 문장 금지
+  - 휴가 질문은 무관한 청크 반환 금지
+  - 근거 부족 시 명시적 실패 응답
+  - 재정리형 질문은 근거 목록 재사용 또는 재구성
+- 테스트는 질문별 예외 성공이 아니라 공통 계약 준수 여부를 검증해야 합니다.
+
+## 6. 검증 기준
+- 재오픈 기준 질문 3개에서 아래가 확인돼야 합니다.
+  1. 직접 답이 먼저 나온다.
+  2. 질문과 맞는 근거만 붙는다.
+  3. 근거가 부족하면 명시적으로 부족하다고 답한다.
+- `검색 hit 있음 = success` 경로가 제거돼야 합니다.
+- 질문별 특례 추가 없이도 재오픈 질문셋이 통과해야 합니다.
+- `SKILL.md` 요구사항과 실제 응답 형식이 일치해야 합니다.
+
+## 7. 완료 판정 기준
+1. [260312_companyx_rag_answer_composition_regression.md](../troubleshooting/260312_companyx_rag_answer_composition_regression.md)에서 정의한 재현 질문셋이 더 이상 회귀하지 않습니다.
+2. [260312_companyx_내부문서_근거응답_사용자시나리오.md](../scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md)의 재오픈 기준 질문 3개가 기대 결과를 만족합니다.
+3. `companyx_grounding_service`에 질문별 direct answer 특례를 추가하지 않고 공통 계약 구조로 바뀝니다.
+4. 테스트가 추가되고 통과합니다.
+5. 실행 결과는 `worklog 1건`으로 마감하고, 시나리오/트러블 문서와 양방향 링크를 연결합니다.
+
+## 8. 후속 경계
+- 이 계획이 닫혀도 Company X 전체 문서군 확대나 범용 RAG 정책 공통화는 별도 계획으로 다룹니다.
+- `Prompt DB`나 전역 오케스트레이션 구조 변경은 이번 계획 범위 밖입니다.
+
+## 한 줄 결론
+- 이번 계획은 `대표 질문 특례 처리 제거` 자체가 아니라, Company X 근거응답을 `질문 유형 계약 + 근거 채택 계약 + 실패 계약`으로 재구성해 시나리오와 트러블을 함께 닫는 작업입니다.
diff --git a/journey/plans/README.md b/journey/plans/README.md
index 197453a..3575cde 100644
--- a/journey/plans/README.md
+++ b/journey/plans/README.md
@@ -59,6 +59,11 @@
 
 **참고**: `plans/archive/250808_감정시스템_현실적용_5단계_로드맵.md`
 
+### 6. Company X RAG 답변합성 시나리오·트러블 동시종결 (260315)
+**상태**: planned
+**목표**: Company X 내부문서 근거응답을 질문별 특례 처리에서 공통 계약 기반 답변합성 구조로 전환
+**참고**: `plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md`
+
 ---
 
 ## 🟡 부분 완료 항목 (남은 작업만)
diff --git a/journey/research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md b/journey/research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md
new file mode 100644
index 0000000..00ed4b2
--- /dev/null
+++ b/journey/research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md
@@ -0,0 +1,192 @@
+---
+tags: [research, companyx, rag, answer-composition, scenario, troubleshooting]
+---
+
+# Company X RAG 답변합성 시나리오·트러블 동시종결 리서치
+
+## 상위 원칙
+- [Writing Principles](../../book/300_architecture/312_writing-principles.md)
+- [Company X RAG 답변 합성 회귀](../troubleshooting/260312_companyx_rag_answer_composition_regression.md)
+- [Company X 내부 문서 근거응답 사용자 시나리오](../scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md)
+
+## 목적
+- `Company X` 근거응답 이슈를 `트러블슈팅 + 시나리오` 한 문제로 보고, 둘을 함께 닫기 위한 원인 기준을 고정합니다.
+- 현재 실패가 `검색 인프라 문제`인지, `답변 합성 문제`인지, `질문별 하드코딩 구조 문제`인지 단일 경로로 좁힙니다.
+- 이 문서는 해결안 확장보다 `다음 plan 1건`을 만들 수 있을 정도로 직접 원인을 확정하는 데만 집중합니다.
+
+## 조사 질문
+1. 현재 실패의 직접 레이어는 검색인가, 답변 합성인가
+2. `컴퍼니엑스의 투자사는 몇개야?`, `내부 규정 상 휴가는 얼마나 쓸 수 있어?`가 왜 깨지는가
+3. 현재 Company X 경로는 일반 규칙 기반인가, 질문별 하드코딩 기반인가
+4. 트러블 문서와 시나리오 문서를 함께 닫으려면 무엇을 plan에서 고정해야 하는가
+
+## 범위 / 비범위
+- 범위:
+  - `rb8001`의 Company X grounding 진입/검색/응답 합성 경로
+  - 재오픈 기준 질문 3개에 대한 처리 구조
+  - 프롬프트/if 분기/질문 적합도 선별 구조
+- 비범위:
+  - Company X 전체 문서셋 확대 작업
+  - `skill-rag-file` 인덱싱 성능 일반론
+  - 다른 프로젝트나 다른 RAG 경로 전면 리팩토링
+  - 최종 수정안 구현 자체
+
+## 사실(Facts)
+
+### 1. Company X 질문은 의도 분류 전에 전용 grounding 경로로 우선 진입한다
+- `route_message()`는 사용자 컨텍스트 생성 직후 `try_companyx_grounding()`을 먼저 호출합니다.
+- 위치:
+  - `rb8001/app/services/message_service.py:81-93`
+- 의미:
+  - Company X 질문은 일반 intent/skill 경로 전에 별도 처리됩니다.
+  - 따라서 이번 실패는 `일반 의도 분류가 Company X 질문을 놓쳤다`만으로 설명되지 않습니다.
+
+### 2. Company X 경로 진입 조건은 팀 ID + 문자열 marker 기반 휴리스틱이다
+- `should_handle_companyx_grounding()`은 `team_id == COMPANYX_TEAM_ID`와 `_looks_like_companyx_grounding_question(message)`로만 판단합니다.
+- `_looks_like_companyx_grounding_question()`은 `근거`, `내부 문서`, `공동 운영`, `컴퍼니엑스`, `companyx` 같은 marker 포함 여부를 봅니다.
+- 위치:
+  - `rb8001/app/services/companyx_grounding_service.py:28-60`
+- 의미:
+  - 질문 유형이나 필요한 답변 방식보다 문자열 포함 여부가 우선입니다.
+  - `컴퍼니엑스`만 들어가도 grounding 경로로 진입할 수 있습니다.
+
+### 3. 검색 질의 확장은 사실상 질문 2종만 별도 하드코딩돼 있다
+- `_build_query_candidates()`는 기본적으로 원문 질문 1개를 그대로 사용합니다.
+- 추가 질의 확장은 아래 경우에만 있습니다.
+  - `오늘전통 + 옐로펀치`
+  - `X-COURSE`
+- 위치:
+  - `rb8001/app/services/companyx_grounding_service.py:63-91`
+- 의미:
+  - `투자사 몇 개`, `휴가 규정` 같은 재오픈 질문은 전용 query expansion이 없습니다.
+  - 대표 질문만 상대적으로 유리한 구조입니다.
+
+### 4. 검색 결과는 질문 적합도 재평가 없이 relevance score 순으로만 합쳐진다
+- `_search_companyx_documents()`는 후보 질의별 검색 결과를 병합한 뒤 `relevance_score` 내림차순으로만 정렬합니다.
+- 질문 유형, 문서 종류, 문서-질문 정합성 재평가 단계는 없습니다.
+- 위치:
+  - `rb8001/app/services/companyx_grounding_service.py:113-127`
+- 의미:
+  - 검색 hit가 있어도 그 hit가 질문에 맞는 근거인지 다시 검증하지 않습니다.
+
+### 5. 직접 답 생성은 질문별 if 분기 하드코딩이고, 기본값은 generic 문장이다
+- `_build_direct_answer()`는 아래 경우만 별도 문장을 가집니다.
+  - `오늘전통 + 옐로펀치`
+  - `X-COURSE`
+- 그 외 모든 질문은 기본값 `Company X 내부 문서에서 관련 근거를 찾았습니다.`를 반환합니다.
+- 위치:
+  - `rb8001/app/services/companyx_grounding_service.py:136-153`
+- 의미:
+  - `투자사는 몇개야?` 같은 수치형 질문은 답을 계산하거나 `단정 불가`를 판단하지 않고 generic 문장으로 끝납니다.
+  - 현재 구조는 질문 유형별 답변 계약이 아니라 일부 질문별 문장 하드코딩입니다.
+
+### 6. 실패 처리는 `검색 결과가 0개일 때`만 작동하고, `검색은 됐지만 무관한 경우`를 다루지 않는다
+- `_build_grounded_response()`의 실패 문장은 `if not results`일 때만 반환됩니다.
+- 결과가 1개라도 있으면 질문 적합성 검증 없이 `근거 문서:` 목록을 붙입니다.
+- 위치:
+  - `rb8001/app/services/companyx_grounding_service.py:155-171`
+- 의미:
+  - 휴가 질문에 무관한 `companyx_todaytradition.pdf` 청크가 잡히면, 시스템은 이를 실패가 아니라 성공처럼 출력합니다.
+  - 즉 현재 실패 경계는 `no result`만 있고 `irrelevant result`는 없습니다.
+
+### 7. 현재 Company X 응답은 LLM 기반 합성이 아니라 규칙 기반 문자열 조합이다
+- Company X 전용 경로는 검색 결과를 가져온 뒤 `_build_direct_answer()`와 청크 요약 문자열을 이어붙여 응답을 만듭니다.
+- 위치:
+  - `rb8001/app/services/companyx_grounding_service.py:130-171`
+- 의미:
+  - 현재 이 문제의 본질은 `프롬프트가 약해서`라기보다, `규칙 설계가 질문 유형을 감당하지 못하는 상태`입니다.
+  - 다만 구현 형태는 질문별 문장/분기 하드코딩에 의존하고 있어 유지보수성이 낮습니다.
+
+### 8. 스킬 문서가 요구하는 계약과 현재 구현 계약은 일치하지 않는다
+- `SKILL.md`는 답변 순서를 `direct answer -> evidence documents -> short evidence summary`로 고정합니다.
+- 또한 `documents are missing, say the evidence is insufficient`를 요구합니다.
+- 위치:
+  - `DOCS/skills/companyx-rag/SKILL.md`
+- 현재 구현은 아래 차이가 있습니다.
+  - `직접 답`이 generic 문장으로 대체될 수 있음
+  - `문서 부족`과 `무관한 문서 반환`을 구분하지 않음
+  - 증거 문서 적합성 검증 없이 score 상위 청크를 그대로 노출함
+- 의미:
+  - 문제의 직접 원인은 스킬 문서 부재가 아니라, 구현이 스킬 계약을 끝까지 지키지 못하는 데 있습니다.
+
+### 9. 대표 성공 질문은 구조적으로 우대돼 있고, 재오픈 질문은 일반화 경로에 놓여 있다
+- `오늘전통 + 옐로펀치` 질문은
+  - 별도 query expansion이 있고
+  - 별도 direct answer 하드코딩이 있으며
+  - 대표 근거 문서셋도 이미 worklog에 남아 있습니다.
+- 관련 문서:
+  - [Company X 내부문서 RAG 근거응답 1차 구현 및 부분 검증](../worklog/260312_companyx_내부문서_rag_근거응답_구현및시나리오검증.md)
+- 반면 재오픈 질문 2개는
+  - 전용 query expansion이 없고
+  - 질문 유형 분기 규칙도 없고
+  - generic fallback 문장으로 마감됩니다.
+- 의미:
+  - 현재 성공은 일반화된 성공이 아니라 `대표 질문 최적화 성공`에 가깝습니다.
+
+### 10. 따라서 지금 실패는 `검색 부재`보다 `답변 합성 + 실패 판정 부재 + 질문별 하드코딩 편향`의 결합이다
+- 앞선 사실을 합치면 현재 경로는 아래 구조입니다.
+  1. marker 기반으로 Company X 경로 진입
+  2. 일부 질문만 유리한 query expansion
+  3. relevance score만으로 검색 결과 채택
+  4. 일부 질문만 direct answer 하드코딩
+  5. 결과가 하나라도 있으면 성공처럼 문서 목록 노출
+- 의미:
+  - 이번 이슈의 직접 레이어는 `answer composition`입니다.
+  - 그러나 더 깊게 보면 `질문 유형 계약이 없는 규칙 하드코딩 구조`가 상위 원인입니다.
+
+## 해석(Interpretation)
+
+### 1. 이 문제는 검색 인프라 장애가 아니라 응답 정책 부재 문제다
+- Company X 전용 경로는 실제로 존재하고, 검색 호출도 수행합니다.
+- 실패가 나는 지점은 `질문에 대한 직접 답을 어떻게 만들고, 어떤 검색 결과를 근거로 채택하며, 언제 모른다고 말할지`가 비어 있다는 점입니다.
+
+### 2. 지금 구조는 시나리오를 닫기 어려운 형태다
+- 시나리오는 `설명형`, `사실 확인형`, `수치 확인형`, `재정리형`을 모두 요구합니다.
+- 하지만 현재 구현은 실질적으로 `대표 사실 확인형 2종`만 특례 처리합니다.
+- 따라서 새 질문이 들어올수록 `if`와 문장 하드코딩이 늘어날 가능성이 높고, 시나리오를 일반 규칙으로 닫을 수 없습니다.
+
+### 3. 트러블 문서가 지적한 회귀의 직접 원인은 질문 적합도 검증 부재다
+- 재오픈 질문들은 검색 결과가 0개라서 실패한 것이 아닙니다.
+- 결과가 있어도 질문과 무관한 청크를 success처럼 출력했습니다.
+- 즉 이번 회귀를 닫는 핵심은 `retrieval result exists`가 아니라 `retrieval result is fit for this question`를 판정하는 단계입니다.
+
+### 4. 스킬 문서는 방향이 맞지만, 구현 계약으로 내려오지 않았다
+- `SKILL.md`는 이미 직접 답, 근거 문서, 부족 시 명시를 요구합니다.
+- 문제는 그 계약이 코드에서 재현 가능한 판정 규칙으로 변환되지 않은 것입니다.
+- 따라서 다음 plan은 새 문구를 더 쓰는 게 아니라, 스킬 계약을 코드가 판정 가능한 구조로 바꾸는 데 집중해야 합니다.
+
+### 5. 하드코딩 프롬프트/문장 증식은 이 문제의 해법이 아니다
+- 현재도 대표 질문 성공은 이미 하드코딩 특례에 기대고 있습니다.
+- 이 상태에서 `투자사`, `휴가`, `투자 건수`, `규정`, `복지` 식으로 질문별 문장을 더 추가하면,
+  - 시나리오는 겉보기로만 닫히고
+  - 트러블은 다른 질문에서 다시 열리며
+  - 프롬프트와 if 분기 중복만 쌓이게 됩니다.
+
+## 미확정 항목(Unresolved)
+1. `skill-rag-file`의 반환 score만으로 질문 적합도를 판정할 수 있는지, 별도 rerank가 필요한지는 아직 미확정입니다.
+2. 수치형 질문의 `단정 가능 / 단정 불가`를 문서 메타데이터만으로 먼저 판정할지, 후속 요약 계층을 둘지는 아직 미확정입니다.
+3. `재정리형 질문`을 이전 응답 재사용으로 처리할지, 다시 검색해도 되는지는 아직 미확정입니다.
+4. Company X 전용 규칙을 독립 계약 모듈로 둘지, 범용 grounding 정책으로 올릴지는 아직 미확정입니다.
+
+## 결론
+- 이 이슈의 직접 원인은 `Company X 검색 실패`가 아니라 `질문 적합 근거 선별 없는 답변 합성`입니다.
+- 더 근본 원인은 `질문 유형 계약 없이 일부 질문만 하드코딩 특례 처리하는 구조`입니다.
+- 따라서 다음 plan은 `프롬프트 문장 추가`가 아니라 아래 3가지를 고정해야 합니다.
+  1. 질문 유형별 판정 계약
+  2. 검색 결과의 질문 적합도 판정 계약
+  3. 근거 부족 시 명시적 실패 계약
+
+## 다음 plan이 반드시 고정해야 할 항목
+1. 재오픈 기준 질문 3개를 공통 검증셋으로 고정할 것
+2. `success`의 정의를 `검색 hit 존재`가 아니라 `직접 답 + 질문 적합 근거 또는 명시적 부족 안내`로 바꿀 것
+3. 질문별 direct answer 하드코딩 추가를 금지하고, 질문 유형별 공통 계약으로 대체할 것
+4. `무관한 청크 반환`을 `실패`로 판정하는 경계를 추가할 것
+5. 스킬 문서 계약과 코드 계약을 1:1로 맞출 것
+
+## 관련 문서
+- [Company X RAG 답변 합성 회귀](../troubleshooting/260312_companyx_rag_answer_composition_regression.md)
+- [Company X 내부 문서 근거응답 사용자 시나리오](../scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md)
+- [Company X 내부문서 RAG 근거응답 현황 리서치](./260312_companyx_내부문서_rag_근거응답_현황_리서치.md)
+- [Company X RAG 답변합성 시나리오·트러블 동시종결 계획](../plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md)
+- [Company X 내부문서 RAG 근거응답 1차 구현 및 부분 검증](../worklog/260312_companyx_내부문서_rag_근거응답_구현및시나리오검증.md)
+- [Company X RAG 스킬 문서](../../skills/companyx-rag/SKILL.md)
diff --git a/journey/research/README.md b/journey/research/README.md
index 87fad06..ea610cc 100644
--- a/journey/research/README.md
+++ b/journey/research/README.md
@@ -13,6 +13,7 @@
 - [자가수정 에이전트 프레임워크 및 Workspace CLI 검증 리서치 (260311)](./260311_자가수정_에이전트_프레임워크_및_workspace_cli_검증_리서치.md)
 - [NAVER WORKS 브리핑 인사이트 서두 누출 종료 리서치 (260311)](./260311_naverworks_briefing_insight_preamble_leak_closure_research.md)
 - [인간 업무행동과 원자스킬 분류 리서치 (260312)](./260312_인간_업무행동과_원자스킬_분류_리서치.md)
+- [Company X RAG 답변합성 시나리오·트러블 동시종결 리서치 (260315)](./260315_companyx_rag_답변합성_시나리오동시종결_리서치.md)
 - [스킬 계약 문서 기반 컨텍스트 오케스트레이션 리서치 (260314)](./260314_스킬_계약_문서_기반_컨텍스트_오케스트레이션_리서치.md)
 
 ### [기억(Memory)](./memory/README.md)
diff --git a/journey/scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md b/journey/scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md
index b4da30f..ee937df 100644
--- a/journey/scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md
+++ b/journey/scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md
@@ -23,6 +23,11 @@ tags: [robeing, companyx, rag, scenarios, user-experience]
 - 수치 확인형 질문: "이번 달 확정 투자 건수 몇 건이야?"
 - 재정리형 질문: "근거 문서명만 다시 정리해줘."
 
+## 이 시나리오의 운영 범위
+- 대상은 `Company X 소속 사용자`의 `내부 문서 근거응답 경험`입니다.
+- 핵심은 검색 성공 자체보다 `답변을 어떻게 마무리해 사용자에게 신뢰 가능한 형태로 보여주느냐`입니다.
+- 따라서 이 시나리오는 `검색됨`만으로 닫히지 않고, `직접 답 + 맞는 근거 + 부족 시 명시적 한계 고지`까지 충족해야 닫힙니다.
+
 ## 장면 1. 프로그램 자료를 빠르게 찾고 설명받고 싶다
 1. 사용자가 묻습니다. "X-COURSE가 뭐야? 내부 자료 기준으로 설명해줘."
 2. 로빙은 Company X 내부 문서에서 `X-COURSE` 관련 소개서, 운영 문서, 제안서 등을 먼저 찾습니다.
@@ -86,6 +91,17 @@ tags: [robeing, companyx, rag, scenarios, user-experience]
 - 근거가 부족하면 추정 대신 부족한 이유와 다음 확인 대상을 말합니다.
 - 사용자가 재사용할 수 있게 근거 문서 목록을 다시 뽑아줄 수 있어야 합니다.
 
+## 재오픈 기준 질문과 기대 결과
+1. `컴퍼니엑스의 투자사는 몇개야?`
+- 기대 결과: 수치를 말할 수 있으면 문서 근거와 함께 말하고, 말할 수 없으면 `내부 문서만으로는 단정 불가`를 분명히 답합니다.
+
+2. `그럼 컴퍼니엑스 내부 규정 상 휴가는 얼마나 쓸 수 있어?`
+- 기대 결과: 휴가 규정 문서가 확인되지 않으면 `관련 내부 규정을 아직 확인하지 못했다`고 답합니다.
+
+3. `오늘전통 프로그램을 Company X가 옐로펀치랑 같이 운영한다는 근거 있어?`
+- 기대 결과: 직접 답 + 근거 문서명 + 근거 요약이 함께 나와야 합니다.
+- 의미: 이미 일부 동작 확인된 질문이므로, 재오픈 이후에도 계속 유지돼야 하는 기준 질문입니다.
+
 ## 금지 답변
 - 내부 문서에 없는 최신 수치를 추정해 단정하지 않습니다.
 - 근거 문서 없이 "알고 있다", "그럴 것이다" 같은 표현으로 넘기지 않습니다.
@@ -116,6 +132,12 @@ tags: [robeing, companyx, rag, scenarios, user-experience]
 - 사용자가 답변 후 "근거 문서가 뭐냐"를 다시 묻는 빈도가 줄어듭니다.
 - 설명형, 사실 확인형, 수치 확인형, 재정리형 질문 모두에서 답변 형식이 크게 흔들리지 않습니다.
 
+## 닫힘 판정 기준
+- 재오픈 기준 질문 3개에서 각각 기대 결과가 실제 응답으로 재현돼야 합니다.
+- 성공 질문 1개만 맞고 다른 질문에서 무관한 청크를 반환하는 상태는 닫힘으로 보지 않습니다.
+- 사용자가 추가 질문을 했을 때도 메타 대화로 빠지지 않고, 근거 재정리 또는 근거 부족 안내로 이어져야 합니다.
+- 이 시나리오는 대응 troubleshooting 문서와 함께 만족하는 단일 research와 단일 plan이 작성돼야 다음 단계로 넘어갑니다.
+
 ## 현재 재오픈 이유
 - 대표 질문 일부는 동작했지만, Slack 실응답 `컴퍼니엑스의 투자사는 몇개야?`에서 기대 형식이 깨졌습니다.
 - 실제 응답은 직접 답 없이 관련성 낮은 청크만 반환했고, 이는 이 시나리오의 완료 기준을 만족하지 못합니다.
@@ -126,4 +148,6 @@ tags: [robeing, companyx, rag, scenarios, user-experience]
 - [Company X 내부 문서 RAG 응답 아이디어](../ideas/260312_companyx_내부문서_rag_응답_아이디어.md)
 - [Company X 내부문서 RAG 근거응답 구현 및 시나리오 검증](../worklog/260312_companyx_내부문서_rag_근거응답_구현및시나리오검증.md)
 - [Company X RAG 답변 합성 회귀](../troubleshooting/260312_companyx_rag_answer_composition_regression.md)
+- [Company X RAG 답변합성 시나리오·트러블 동시종결 리서치](../research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md)
+- [Company X RAG 답변합성 시나리오·트러블 동시종결 계획](../plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md)
 - [컴퍼니엑스(Company X) 개요](../../book/500_business/560_컴퍼니엑스_개요.md)
diff --git a/journey/troubleshooting/260312_companyx_rag_answer_composition_regression.md b/journey/troubleshooting/260312_companyx_rag_answer_composition_regression.md
index e72fa2c..633ebbf 100644
--- a/journey/troubleshooting/260312_companyx_rag_answer_composition_regression.md
+++ b/journey/troubleshooting/260312_companyx_rag_answer_composition_regression.md
@@ -8,6 +8,13 @@ tags: [robeing, companyx, rag, troubleshooting, answer-quality]
 - [Company X 내부 문서 근거응답 사용자 시나리오](../scenarios/260312_companyx_내부문서_근거응답_사용자시나리오.md)
 - [Company X 내부문서 RAG 근거응답 구현 및 시나리오 검증](../worklog/260312_companyx_내부문서_rag_근거응답_구현및시나리오검증.md)
 - [Company X 내부문서 RAG 근거응답 구현계획](../plans/260312_companyx_내부문서_rag_근거응답_구현계획.md)
+- [Company X RAG 답변합성 시나리오·트러블 동시종결 리서치](../research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md)
+- [Company X RAG 답변합성 시나리오·트러블 동시종결 계획](../plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md)
+
+## 이 문서가 다루는 범위
+- 대상은 `Company X 내부문서 근거응답`의 `답변 합성 단계`입니다.
+- 검색 인프라 자체 장애, 권한 차단, 문서 업로드 실패는 본 문서의 1차 범위가 아닙니다.
+- 핵심은 `질문에 맞는 직접 답`, `질문 적합 근거 선별`, `근거 부족 시 실패 처리`가 실제 응답에서 깨진 문제입니다.
 
 ## 문제
 - Company X RAG 연결 자체는 되었지만, 실제 Slack 실응답이 시나리오의 기대 답변 형식을 만족하지 못했습니다.
@@ -34,12 +41,30 @@ tags: [robeing, companyx, rag, troubleshooting, answer-quality]
 - 규정형 질문처럼 아예 문서군이 다를 가능성이 큰 질의에서도, `근거 없음` 대신 무관한 청크를 억지로 반환했습니다.
 - 즉 현재 구현은 `질문별 답변 합성 품질`이 안정화되지 않았습니다.
 
+## 재현 질문셋과 기대 결과
+1. `컴퍼니엑스의 투자사는 몇개야?`
+- 기대 결과: 직접 답이 먼저 나와야 하며, 내부 문서만으로 단정 불가하면 그 사실을 명확히 말해야 합니다.
+- 금지 결과: `관련 근거를 찾았습니다` 같은 메타 문장만 반환하거나, 개수와 무관한 청크를 그대로 노출하는 것
+
+2. `그럼 컴퍼니엑스 내부 규정 상 휴가는 얼마나 쓸 수 있어?`
+- 기대 결과: 휴가 규정 문서가 없거나 확인되지 않으면 `내부 문서 기준으로는 확인되지 않는다`고 답해야 합니다.
+- 금지 결과: 휴가와 무관한 사업계획서 청크를 근거처럼 붙이는 것
+
+3. `오늘전통 프로그램을 Company X가 옐로펀치랑 같이 운영한다는 근거 있어?`
+- 기대 결과: 직접 답 + 근거 문서명 + 짧은 근거 요약이 함께 나와야 합니다.
+- 의미: 이 질문은 이미 일부 성공한 기준 질문으로, 회귀 여부를 함께 봐야 합니다.
+
 ## 원인 가설
 1. retrieval 결과를 질문 적합도 기준으로 재정렬/필터링하지 않습니다.
 2. 수치형 질문과 사실 확인형 질문을 분리하지 않고 같은 응답 포맷으로 처리합니다.
 3. `직접 답 생성` 전에 `근거 청크 선별`이 충분히 정교하지 않습니다.
 4. 적절한 근거가 없을 때 `모른다/문서 미확인`로 빠지는 실패 경로가 약합니다.
 
+## 범위 밖으로 고정하는 것
+- Company X 전체 문서셋 확대 자체를 이번 회귀의 직접 원인으로 단정하지 않습니다.
+- `skill-rag-file` 검색 API 자체가 항상 실패한다고 보지 않습니다.
+- `rb8001` 메모리 컬렉션의 `768/384` 차원 드리프트는 별도 이슈이며, 이번 회귀의 직접 원인으로 섞지 않습니다.
+
 ## 필요한 조치
 1. 질문 유형별 응답 규칙 분기
    - 수치 확인형
@@ -50,5 +75,10 @@ tags: [robeing, companyx, rag, troubleshooting, answer-quality]
 4. Slack 실응답 기준으로 시나리오 질문셋 재검증
 5. 근거 부족 시 메타 대화가 아니라 `문서 없음 또는 미확인`으로 답하는 실패 경로 고정
 
+## 닫힘 판정 기준
+- 위 재현 질문셋에서 `직접 답 없음`, `무관한 청크 노출`, `메타 대화로 회피`가 더 이상 재현되지 않아야 합니다.
+- 성공 질문은 계속 성공해야 하고, 근거 부족 질문은 억지 답변 대신 명시적 부족 안내로 고정돼야 합니다.
+- 이 문서와 시나리오 문서를 함께 만족시키는 단일 research 문서가 후속으로 작성돼야 합니다.
+
 ## 상태
 - 열림