# rawp 1.0.1 변경 사항 1.0.0와 비교 ## 개요 | 항목 | 값 | | --- | --- | | 원본 파일 | `rawp.md` | | 추가된 섹션 | 2 | | 삭제된 섹션 | 0 | | 수정된 섹션 | 8 | | 문서 변경 여부 | 예 | ## 추가된 섹션 - 8. 클라이언트 UI/UX 구현 지침 (Client UI Implementer Notes) - 9. Edge Node API (사용자 접점 통신 규약) ## 삭제된 섹션 - 없음 ## 수정된 섹션 - Document Overview - 1. 개요 (Introduction) - 3. Phase 1: 등록, 페어링 및 키 교환 (Registration & Lifecycle) - 4. Phase 2: 제어 및 모니터링 인터페이스 (Master → Client HTTP) - 5. Phase 3: 세션 라이프사이클 및 연결 (Session & I/O) - 6. 데이터 평면 스트리밍 규격 (Data Plane WSS Protocol) - 7. 보안 및 예외 처리 (Security & Errors) - 부록: 관련 규격 문서 ## 섹션별 변경 상세 ### Document Overview - 이전 앵커: `#document-overview` - 현재 앵커: `#document-overview` - 추가된 줄: 6 - 삭제된 줄: 5 ```diff # RAWP 1.0: Remote Agent Wire Protocol -| 항목 | 값 | -| ---------------- | ---------------- | -| 상태 | Stable | -| 버전 | 1.0 | -| 데이터 평면 규격 | **RAWP-DPS 1.0** | +| 항목 | 값 | +| ---------------------- | ---------------- | +| 상태 | Stable | +| 버전 | 1.0 | +| 데이터 평면 규격 | **RAWP-DPS 1.0** | +| 클라이언트 렌더링 규격 | **RAWP-CRS 1.0** | --- ``` ### 1. 개요 (Introduction) - 이전 앵커: `#1-introduction` - 현재 앵커: `#1-introduction` - 추가된 줄: 8 - 삭제된 줄: 6 ```diff ### 1.2. 용어 정의 (Terminology) -| 용어 | 정의 | -| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | -| Master Server | 클라이언트 노드를 관리하고 제어 명령을 하달하는 중앙 서버 (Control Plane). | -| Local Client | 마스터 서버의 명령을 수신하는 HTTP 엔드포인트를 소유하며, 로컬 프로세스(Agent)의 실행 및 I/O를 담당하는 에지 게이트웨이 (Execution Plane). | -| Agent | 클라이언트 환경에서 실행되는 실제 단위 작업 프로세스 (예: LLM, 스크립트 등). | -| Session | 특정 에이전트의 실행부터 종료까지의 라이프사이클 및 I/O 스트림의 논리적 단위. | +| 용어 | 정의 | +| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | +| Master Server | 클라이언트 노드를 관리하고 제어 명령을 하달하는 중앙 서버 (Control Plane). | +| Local Client | 마스터 서버의 명령을 수신하는 HTTP 엔드포인트를 소유하며, 로컬 프로세스(Agent)의 실행 및 I/O를 담당하는 에지 게이트웨이 (Execution Plane). | +| Agent | 클라이언트 환경에서 실행되는 실제 단위 작업 프로세스 (예: LLM, 스크립트 등). | +| Session | 특정 에이전트의 실행부터 종료까지의 라이프사이클 및 I/O 스트림의 논리적 단위. | +| Config Scope | 클라이언트 설정의 논리적 분류 단위. 각 스코프는 독립된 엔드포인트, 독립된 `config_version`, 독립된 갱신 주기를 갖는다. | +| Session-Pinned Config | 세션 초기화 시점에 바인딩된 설정 스냅샷. 해당 세션의 전체 라이프사이클 동안 불변이다. | ### 1.3. 호환성 및 파싱 규약 (Forward Compatibility) ``` ### 3. Phase 1: 등록, 페어링 및 키 교환 (Registration & Lifecycle) - 이전 앵커: `#3-phase-1-registration-lifecycle` - 현재 앵커: `#3-phase-1-registration-lifecycle` - 추가된 줄: 2 - 삭제된 줄: 2 ```diff 양측은 타 API 호출 시 `401 Unauthorized`를 받으면, 발급 주체의 갱신 엔드포인트를 호출하여 토큰을 갱신하고 원래 요청을 재시도해야 한다 (MUST). -#### 3.4.1. 클라이언트의 마스터 토큰 갱신 (Client → Master) +### 3.4.1. 클라이언트의 마스터 토큰 갱신 (Client → Master) - **Endpoint**: `POST /v1/auth/refresh` (Master Server 제공) ... - **Response**: §3.3의 Master → Client 응답 포맷과 동일. -#### 3.4.2. 마스터의 클라이언트 토큰 갱신 (Master → Client) +### 3.4.2. 마스터의 클라이언트 토큰 갱신 (Master → Client) - **Endpoint**: `POST /v1/auth/refresh` (Local Client 제공) ``` ### 4. Phase 2: 제어 및 모니터링 인터페이스 (Master → Client HTTP) - 이전 앵커: `#4-phase-2-master-client-http` - 현재 앵커: `#4-phase-2-master-client-http` - 추가된 줄: 178 - 삭제된 줄: 1 ```diff ### 4.1. 클라이언트 설정 동기화 (Client Configuration) -클라이언트는 구동 직후 시스템 한계치와 지원 능력을 서버에 동기화한다. 마스터는 이 값으로 요청을 스로틀링하며, `capabilities`에 없는 기능을 요구해서는 안 된다 (MUST). +클라이언트는 시스템 한계치와 지원 능력을 서버에 동기화한다. 설정은 의미적 성격에 따라 독립된 Config Scope로 분리되며, 각 스코프는 전용 엔드포인트를 통해 전체 교체(Full Replacement) 방식으로 동기화된다. 마스터 서버는 수신한 설정 값으로 요청을 스로틀링하며, 보고되지 않은 기능을 요구해서는 안 된다 (MUST). +### 4.1.1. Config Scope 분리 원칙 + +클라이언트 설정은 다음 두 개의 Config Scope로 분리된다: + +| Config Scope | 엔드포인트 | 성격 | 변경 트리거 | +| ------------------- | ----------------------------------- | -------------------------------------------------- | --------------------------------------------------------- | +| **Resource Limits** | `PUT /v1/nodes/config/limits` | 수량적 운영 제약 — 처리량, 전송 크기, 메모리, 정책 | 시스템 부하 변동, 메모리 압박, 운영 정책 조정 | +| **Capabilities** | `PUT /v1/nodes/config/capabilities` | 질적 기능 선언 — 클라이언트가 지원하는 기능 목록 | 플러그인/도구 로드·언로드, 모델 교체, 소프트웨어 업데이트 | + +각 스코프는 독립된 `config_version`을 가지며, 한 스코프의 갱신이 다른 스코프의 버전에 영향을 주지 않는다 (MUST). 클라이언트는 변경이 발생한 스코프의 엔드포인트만 호출하면 되고, 변경되지 않은 스코프를 함께 재전송할 필요가 없다. + +### 4.1.2. 초기 동기화 (Initial Synchronization) + +클라이언트는 페어링 완료(§3.3) 직후 그리고 재기동 직후, **양쪽 Config Scope를 모두** 동기화해야 한다 (MUST). 초기 동기화 시 `config_version`은 `1`로 시작한다. 서버는 양쪽 스코프의 초기 동기화가 완료되기 전까지 해당 클라이언트에 대한 세션 초기화(§5.1) 요청을 보류해야 한다 (MUST). 초기 동기화 미완료 상태에서 세션 초기화가 시도되면 서버는 `503 Service Unavailable`을 반환해야 한다 (MUST). + +마스터 서버가 특정 스코프에 대한 설정을 보유하지 않은 상태에서 해당 클라이언트의 헬스 체크(§4.2) 또는 에이전트 탐색(§4.3)을 수행하는 것은 허용된다. 설정 동기화 보류 규칙은 세션 초기화에만 적용된다. + +### 4.1.3. 런타임 설정 갱신 (Runtime Configuration Update) + +클라이언트는 런타임 중 설정 변경이 발생할 때마다 해당 스코프의 엔드포인트를 호출하여 서버에 변경 사항을 동기화해야 한다 (MUST). 각 호출은 해당 스코프의 **전체 필드를 포함하는 완전한 스냅샷**이어야 하며, 부분 필드만 포함하는 것은 허용되지 않는다 (MUST NOT). 서버는 수신한 스냅샷으로 해당 스코프의 기존 상태를 전체 교체한다. + +### 4.1.4. 설정 버전 관리 및 순서 보장 (Config Versioning) + +모든 Config Scope 요청에는 `config_version` 필드가 포함되어야 한다 (MUST). 이 값은 각 스코프별로 독립적이며, 클라이언트가 해당 스코프의 설정을 변경할 때마다 반드시 1씩 단조 증가시켜야 한다 (MUST). + +**순서 보장 규칙**: 마스터 서버는 수신한 `config_version`이 현재 보유한 해당 스코프의 버전보다 큰 경우에만 설정을 갱신해야 한다 (MUST). 현재 보유 버전 이하의 값이 수신되면 네트워크 지연에 의한 역전(stale update)으로 간주하고, `409 Conflict`를 반환하여 거부해야 한다 (MUST). 이때 응답 바디에는 서버가 현재 보유 중인 `config_version`을 포함하여 클라이언트가 재동기화할 수 있도록 해야 한다 (MUST). + +**클라이언트 재기동 시 버전 처리**: 클라이언트가 재기동될 때 이전 `config_version`을 영속적으로 보관하지 못하는 경우를 위해, 다음의 특수 규칙을 적용한다: `config_version`이 `1`인 요청은 서버가 보유한 버전과 무관하게 항상 수락해야 한다 (MUST). 이는 재기동 후 초기 동기화를 보장하기 위한 것이며, 서버는 `config_version: 1` 수신 시 내부 버전 카운터를 `1`로 리셋해야 한다. 단, 활성 세션이 존재하는 상태에서 `config_version: 1`이 수신되면, 서버는 이를 클라이언트 재기동 시그널로 해석하여 시스템 로그에 기록해야 한다 (MUST). + +### 4.1.5. Resource Limits 동기화 + +클라이언트의 수량적 운영 제약을 서버에 동기화한다. + +**Endpoint**: `PUT /v1/nodes/config/limits` (Master Server 제공) + +**Request** (Client → Master): + +```json +{ + "config_version": "Number (필수, 이 스코프의 단조 증가 정수, 초기값 1)", + "effective_at": "String (필수, ISO 8601, 클라이언트가 이 설정을 적용한 시각)", + "reason": "String (선택, 변경 사유. 예: 'memory_pressure', 'scheduled_maintenance')", + "limits": { + "rate_limit": "Number (필수, 초당 처리 가능한 최대 HTTP 요청 수. 양의 정수)", + "max_frame_size": "Number (필수, WSS 단일 프레임 최대 바이트. 최소 1024)", + "reattach_window": "Number (필수, WSS 단절 시 DETACHED 상태 유지 시간 초. 0 이상 정수. 0이면 DETACHED 미지원으로, 단절 시 즉시 TERMINATED 전이)", + "max_buffer_size": "Number (필수, 최대 메모리 버퍼 바이트. 양의 정수. max_frame_size 이상이어야 함)", + "buffer_overflow_policy": "String (필수, 'RING' 또는 'DROP')" + } +} +``` + +**서버 검증 규칙 (MUST)**: + +| 필드 | 검증 조건 | 위반 시 에러 | +| ------------------------------- | ----------------------------------------------------------------------------------- | --------------------------------- | +| `config_version` | 양의 정수. 현재 보유 버전보다 큰 값이거나, 정확히 `1` (재기동) | `409 Conflict` (버전 역전) | +| `effective_at` | 유효한 ISO 8601 형식. 미래 시각 불허 (서버 현재 시각 + 30초 허용 오차 초과 시 거부) | `422` `EFFECTIVE_AT_IN_FUTURE` | +| `limits.rate_limit` | 양의 정수 (> 0). 소수점 불허 | `422` `INVALID_RATE_LIMIT` | +| `limits.max_frame_size` | 양의 정수. 최소 `1024` | `422` `FRAME_SIZE_TOO_SMALL` | +| `limits.reattach_window` | 0 이상 정수 | `422` `INVALID_REATTACH_WINDOW` | +| `limits.max_buffer_size` | 양의 정수. `max_frame_size` 이상이어야 함 | `422` `BUFFER_SMALLER_THAN_FRAME` | +| `limits.buffer_overflow_policy` | `"RING"` 또는 `"DROP"` 중 하나 | `422` `INVALID_OVERFLOW_POLICY` | +| 모든 필드 존재 여부 | `limits` 객체 내 모든 필드가 존재해야 함 (전체 교체) | `400` `CONFIG_FIELD_MISSING` | + +**Response (200 OK):** + +```json +{ + "config_version": "Number (수신한 버전 에코백)", + "accepted_at": "String (ISO 8601, 서버가 설정을 수락하고 저장한 시각)", + "active_sessions_affected": "Number (현재 RUNNING 또는 DETACHED 상태의 세션 수. 이 세션들은 이전 설정으로 계속 동작함. §4.1.8 참조)" +} +``` + ... diff truncated ... ``` ### 5. Phase 3: 세션 라이프사이클 및 연결 (Session & I/O) - 이전 앵커: `#5-phase-3-session-io` - 현재 앵커: `#5-phase-3-session-io` - 추가된 줄: 2 - 삭제된 줄: 0 ```diff **제약 조건**: `reattach: true`이나 해당 `session_id`가 존재하지 않거나 종료된 경우 `404 Not Found` 반환 (MUST). +**Config 바인딩 제약 조건**: 마스터 서버는 `reattach: false`로 세션을 초기화할 때, §4.1.8에 따라 양쪽 Config Scope(limits, capabilities)의 최신 스냅샷을 해당 세션에 바인딩해야 한다 (MUST). 양쪽 스코프의 초기 동기화(§4.1.2)가 완료되지 않은 클라이언트에 대해서는 세션 초기화를 시도해서는 안 된다 (MUST NOT). + ### 5.2. 세션 명시적 종료 (Session Termination) ``` ### 6. 데이터 평면 스트리밍 규격 (Data Plane WSS Protocol) - 이전 앵커: `#6-data-plane-wss-protocol` - 현재 앵커: `#6-data-plane-wss-protocol` - 추가된 줄: 1 - 삭제된 줄: 0 ```diff > - **세션 이벤트** (`session.*`): 이력 복구, 컨텍스트 압축 보고, 사용량 지표, Turn 라이프사이클, 능력 협상 (RAWP-DPS §7, §12) > - **태스크 관리** (RAWP-DPS §8), **계획 문서** (RAWP-DPS §9), **서브에이전트 위임** (RAWP-DPS §10), **구조화 출력** (RAWP-DPS §11) +> - **파일 참조** (RAWP-DPS §16): 인라인 파일 참조 토큰 포맷, 실시간 퍼지 파일 검색, 토큰 이스케이프 규칙, 어댑터별 변환 규칙 > > 구현자는 RAWP-DPS 1.0 규격 문서를 참조하여 데이터 평면을 구현해야 한다 (MUST). ``` ### 7. 보안 및 예외 처리 (Security & Errors) - 이전 앵커: `#7-security-errors` - 현재 앵커: `#7-security-errors` - 추가된 줄: 11 - 삭제된 줄: 454 ```diff **상태 코드 매핑 규칙**: -| HTTP 상태 코드 | 사유 | -| --------------------------- | ----------------------------------------------------------- | -| `400 Bad Request` | 필수 파라미터 누락, 잘못된 UUID 포맷. | -| `401 Unauthorized` | 토큰 만료, 서명 불일치, WSS Upgrade 티켓 무효. | -| `403 Forbidden` | White-list 없는 명령어, 인가되지 않은 디렉토리 접근. | -| `404 Not Found` | 존재하지 않는 `session_id` 제어 시도. | -| `409 Conflict` | 이미 `RUNNING` 중인 세션에 `reattach: false`로 초기화 시도. | -| `429 Too Many Requests` | `rate_limit` 초과. | -| `500 Internal Server Error` | 내부 파일 시스템 오류, 바인딩 충돌 등. | +| HTTP 상태 코드 | 사유 | +| --------------------------- | --------------------------------------------------------------------------------------------------------------- | +| `400 Bad Request` | 필수 파라미터 누락, 잘못된 UUID 포맷. | +| `401 Unauthorized` | 토큰 만료, 서명 불일치, WSS Upgrade 티켓 무효. | +| `403 Forbidden` | White-list 없는 명령어, 인가되지 않은 디렉토리 접근. | +| `404 Not Found` | 존재하지 않는 `session_id` 제어 시도. | +| `409 Conflict` | 이미 `RUNNING` 중인 세션에 `reattach: false`로 초기화 시도. Config Scope의 `config_version` 역전 감지 (§4.1.4). | +| `422 Unprocessable Entity` | 설정 갱신 시 필드값 형식, 범위, 상호 정합성 위반 (§4.1.7). | +| `429 Too Many Requests` | `rate_limit` 초과. | +| `500 Internal Server Error` | 내부 파일 시스템 오류, 바인딩 충돌 등. | +| `503 Service Unavailable` | 초기 설정 동기화 미완료 상태에서 세션 초기화 시도 (§4.1.2). | ### 7.2. 보안 제약 및 필수 보호 장치 (MUST) ... --- - -### 8. 클라이언트 UI/UX 구현 지침 (Client UI Implementer Notes) - -프론트엔드 또는 시각적 피드백(터미널, 대시보드 등)을 구현하는 시스템은 본 프로토콜의 상호작용 이벤트 처리 시 다음의 UI 제약 사항을 엄격히 준수해야 한다. - -#### 8.1. 상호작용 및 애니메이션 기본 원칙 (필수 준수) - -**불필요한 애니메이션 제한**: 실제 클릭 등 인터랙션이 없는 정적 요소(단순 텍스트 스트림 출력부 등)에는 불필요하게 호버(Hover) 애니메이션을 적용하지 않아야 한다 (MUST NOT). - -**방해 없는 애니메이션 효과**: 버튼(상호작용 요청의 옵션 등)과 같이 실제 인터랙션이 존재하는 곳은, 반드시 사용자의 작업 흐름이나 시선을 방해하지 않는 선에서 부드러운 애니메이션 효과를 제공해야 한다 (MUST). - -#### 8.2. 실시간 스트리밍 환경 (WebSocket 지원 클라이언트) - -전용 웹 클라이언트나 데스크톱 앱과 같이 `agent.text.delta` 및 `agent.thinking.delta`를 실시간으로 수신할 수 있는 환경에 대한 지침이다. - -##### 8.2.1. 점진적 텍스트 렌더링 (Progressive Rendering) - -**버퍼 병합**: 클라이언트는 `content_index` 단위로 수신되는 텍스트 페이로드를 지연 없이 화면에 점진적으로 렌더링해야 한다 (MUST). - -**오토 스크롤 제어**: 텍스트 생성 중에는 뷰포트 하단을 자동으로 추적하되, 사용자가 과거 이력을 보기 위해 스크롤을 위로 올린 상태(Scroll Up)에서는 읽기 방해를 막기 위해 오토 스크롤을 일시 중단해야 한다 (SHOULD). - -**스크롤 안정성 (Scroll Stability)**: 텍스트가 점진적으로 생성되면 콘텐츠 높이가 지속적으로 증가하며, 이로 인해 뷰포트가 위아래로 떨리거나(jitter) 현재 읽고 있는 텍스트의 위치가 밀려나는 현상이 발생할 수 있다. 클라이언트는 사용자가 현재 읽고 있는 텍스트가 시각적으로 흔들리지 않도록 스크롤 위치를 능동적으로 제어해야 한다 (MUST). 구체적으로 다음을 준수한다: - -- **앵커 포인트 고정**: 오토 스크롤이 활성화된 상태에서는, 새로운 텍스트가 삽입될 때 뷰포트의 스크롤 위치를 **현재 생성 중인 마지막 라인이 뷰포트 하단의 일정 영역(예: 하단 20~30% 지점)에 고정**되도록 조정해야 한다 (MUST). 콘텐츠 높이 변화량만큼 단순히 `scrollTop`을 증가시키는 방식은 프레임 간 미세한 위치 차이로 떨림을 유발하므로 지양한다. -- **상방 삽입 보상 (Upward Insertion Compensation)**: 현재 읽고 있는 영역 **위쪽**에 콘텐츠가 삽입되거나 높이가 변하는 경우(예: 사고 블록 접힘/펼침, 도구 결과 렌더링, 이미지 로딩 완료 등), 삽입된 높이만큼 `scrollTop`을 보상하여 현재 보고 있는 텍스트의 화면상 절대 위치가 변하지 않도록 해야 한다 (MUST). 이 보상이 없으면 사용자가 읽고 있던 텍스트가 갑자기 아래로 밀려나는 현상이 발생한다. -- **부드러운 추종**: 오토 스크롤 시 `scrollTo`에 `behavior: 'instant'`를 사용하여 프레임 단위로 즉각 추종해야 한다 (SHOULD). `behavior: 'smooth'`는 빠른 텍스트 생성 속도에 스크롤 애니메이션이 뒤처져 누적 지연(scroll lag)을 유발할 수 있으므로, 스트리밍 중에는 사용하지 않아야 한다 (SHOULD NOT). 부드러운 시각 효과가 필요하면 CSS `scroll-behavior` 대신 `requestAnimationFrame` 기반으로 프레임 동기화된 위치 조정을 구현할 것을 권장한다. -- **높이 변동 최소화**: 마크다운 렌더링 시 코드 블록, 테이블, 이미지 등 높이가 확정되지 않은 요소는 예상 높이를 미리 확보(placeholder/skeleton)하여, 렌더링 완료 시 높이 변동폭을 최소화해야 한다 (SHOULD). 특히 코드 블록은 열림 태그(` ``` `) 수신 시점에 최소 높이를 할당하고, 내용이 채워지면서 점진적으로 확장하는 방식을 적용한다. - -**미완성 마크다운 방어**: 렌더러는 스트리밍 중 마크다운 태그(예: 코드 블록 ` ``` `, 볼드체 `**`)가 닫히지 않은 상태로 전달되더라도 UI가 깨지지 않도록 방어적으로 처리해야 한다 (MUST). - -##### 8.2.2. 사고 과정 (Thinking Process) 시각화 - -**시각적 분리**: `agent.thinking.delta`의 내용은 일반 응답 텍스트와 명확히 구분되는 별도의 컨테이너(예: 인용구, 배경색이 다른 블록)에 렌더링해야 한다 (MUST). - -**진행 상태 표현 (Thinking Indicator)**: 사고 과정이 진행 중일 때, 사용자에게 에이전트가 능동적으로 작업 중임을 시각적으로 전달해야 한다 (MUST). 구체적으로 다음을 권장한다: - -- **그라데이션 애니메이션**: 사고 컨테이너의 좌측 보더 또는 배경에 부드러운 그라데이션 펄스(gradient pulse) 또는 시머(shimmer) 효과를 적용하여 활성 상태를 표현해야 한다 (SHOULD). 색상은 일반 응답 영역과 구별되는 톤(예: 보라/남색 계열의 저채도 그라데이션)을 사용하되, 본문 가독성을 해치지 않아야 한다 (MUST NOT). -- **애니메이션 템포**: 그라데이션 또는 펄스의 주기는 1.5~3초 사이의 느린 호흡 리듬을 유지하여 사용자에게 안정감을 주어야 한다 (SHOULD). 빠르게 깜빡이거나 점멸하는 효과는 시각적 피로를 유발하므로 사용해서는 안 된다 (MUST NOT). -- **레이블 표시**: 컨테이너 상단에 "Thinking…" 또는 동등한 상태 레이블을 표시하여 해당 영역의 성격을 명시해야 한다 (MUST). 레이블에는 경과 시간 카운터(예: "Thinking… 3s")를 선택적으로 병행 표시할 수 있다 (MAY). - -**실시간 텍스트 노출 정책**: 사고 스트림의 텍스트 본문을 사용자에게 실시간으로 노출할지 여부는 클라이언트 설정에 따른다. 두 가지 모드를 지원할 것을 권장한다 (SHOULD): - -- **요약 모드 (기본값 권장)**: 사고 텍스트 본문을 숨기고, Thinking Indicator와 레이블만 표시한다. 사용자가 클릭 또는 토글하면 본문을 펼칠 수 있다. -- **실시간 모드**: `agent.thinking.delta`의 텍스트를 점진적으로 렌더링한다. 이 경우에도 일반 응답 텍스트와의 시각적 분리(배경색, 폰트 스타일, 불투명도 차등 등)를 유지해야 한다 (MUST). - -**상태 전이 및 제거**: `agent.thinking.done` 수신 시, 사고 영역은 다음 절차를 따라 전이되어야 한다 (MUST): - -1. **즉시 비활성화**: 그라데이션 애니메이션과 펄스 효과를 즉시 중단한다 (MUST). 사고가 끝난 후에도 애니메이션이 잔존하면 사용자에게 혼란을 줄 수 있으므로, 전이 지연 없이 정지해야 한다. -2. **축소 전환**: 비활성화 후, 컨테이너를 접힌 상태(Collapsed)로 전환하여 시각적 비중을 최소화해야 한다 (SHOULD). 접힌 상태에서는 "Thought for Ns" 형태의 요약 한 줄만 표시하고, 클릭 시 전체 내용을 펼칠 수 있어야 한다 (SHOULD). -3. **전환 애니메이션**: 활성 → 접힘 전환 시, 높이 축소(collapse)와 불투명도 감소(fade)를 150~300ms 이내의 부드러운 트랜지션으로 처리하여 시각적 점프를 방지해야 한다 (SHOULD). -4. **포커스 이동**: 사고 영역이 접힌 직후, 뷰포트 스크롤을 후속 `agent.text.delta` 영역으로 자연스럽게 이동시켜 사용자의 시선이 최종 응답에 집중되도록 유도해야 한다 (SHOULD). - -**마스킹 처리**: 페이로드에 `redacted: true`가 포함된 경우, 텍스트 원문 대신 `[사고 내용 생략]` 등의 플레이스홀더로 마스킹하여 표시해야 한다 (MUST). 마스킹된 사고 블록은 펼침(Expand) 동작 자체를 비활성화하여 원문 접근을 차단해야 한다 (MUST). ... diff truncated ... ``` ### 부록: 관련 규격 문서 - 이전 앵커: `#-` - 현재 앵커: `#-` - 추가된 줄: 1 - 삭제된 줄: 0 ```diff | ----------------------- | ----------------------------------------------------- | | **RAWP-DPS 1.0** | 데이터 평면 스트리밍 규격 (현행). 본 문서 §6이 참조. | +| **RAWP-CRS 1.0** | 클라이언트 렌더링 규격 (현행). 본 문서 §8이 참조. | | **RAWP-DPS-0.1-Legacy** | 데이터 평면 스트리밍 규격 (단종 예고). 레거시 호환용. | ```