feat: update codex live chat workflow

This commit is contained in:
2026-04-22 20:00:38 +09:00
parent 9e4b70f1f1
commit b0b9980a6c
70 changed files with 5178 additions and 2401 deletions

View File

@@ -1,249 +0,0 @@
# Chat Frontend Rewrite Plan
## Goal
Rebuild the chat frontend around explicit feature boundaries instead of one large panel. The rewrite keeps the current server contract for now, but removes direct API coupling from UI components and preserves the current mobile visual structure.
## Non-Goals
The first rewrite wave does not change:
1. Work server REST endpoint shapes
2. Work server WebSocket event payload shapes
3. Existing chat database schema
4. Current mobile interaction model and visual hierarchy
## Current Pain Points
The existing frontend mixes too many concerns in the same render tree:
1. Session routing and panel selection
2. Conversation list fetch and sort
3. Conversation detail recovery
4. Composer draft and upload lifecycle
5. WebSocket connection and reconnect
6. Runtime dashboard fetch and live updates
7. Error log loading
8. Notification unread sync
9. Visibility, focus, reconnect, and page restore sync
This creates three classes of failures:
1. Render loops from unstable effect dependencies
2. Request storms from duplicate fetch paths
3. Partial outages where one failing concern blanks the whole chat workspace
## Rewrite Strategy
The rewrite is frontend-first, but not frontend-only in architecture. The new frontend must assume that API latency and WebSocket reconnects can fail, and each feature controller must degrade independently.
### Guiding Rules
1. UI components do not call REST helpers directly
2. UI components do not build WebSocket URLs directly
3. One feature controller owns one feature's network lifecycle
4. Shell state never performs data fetches
5. Mobile layout is preserved while data flow is replaced under it
## Feature Inventory
### 1. Workspace Shell
Responsibilities:
1. Hold `chat | runtime | errors` selection
2. Hold active session id
3. Hold mobile split-pane visibility
4. Compose feature panes
Rules:
1. No direct REST calls
2. No direct socket usage
3. No data caching
### 2. Conversation List
Responsibilities:
1. Load room summaries
2. Search and sort locally
3. Create, rename, delete, and select rooms
4. Expose unread and processing badges
Rules:
1. One fetch source
2. One short-lived in-flight dedupe layer
3. No room detail fetch inside the list controller
### 3. Conversation Room
Responsibilities:
1. Load one room detail
2. Merge server messages with optimistic local state
3. Recover state after reconnect
4. Mark replies as read
Rules:
1. Only one active detail request at a time
2. Detail loading must never fan out into list reloads
3. Loading and recovery state must be local to the active room
### 4. Composer
Responsibilities:
1. Hold draft and attachments
2. Submit queue or direct requests
3. Retry, cancel, and delete pending items
4. Manage optimistic user/request messages
Rules:
1. No list-wide refresh on send
2. No runtime refresh coupled to draft input
### 5. Live Connection
Responsibilities:
1. Open and maintain the shared chat socket
2. Route message, job, runtime, and activity events
3. Reconnect with bounded recovery
4. Publish connection state through a shared adapter
Rules:
1. No duplicate context writes
2. Background transitions are throttled
3. Reconnect only restores the active room by default
### 6. Runtime
Responsibilities:
1. Load runtime snapshot
2. Show queue and active jobs
3. Load per-job detail
4. Support remove and cancel actions
Rules:
1. Runtime refresh is separate from room detail refresh
2. Runtime failure must not blank the chat room UI
### 7. Error Viewer
Responsibilities:
1. Load error log list
2. Render error detail and resource previews
Rules:
1. Fully isolated from chat room state
### 8. Notification Integration
Responsibilities:
1. Unread badges
2. Notification center list/detail
3. Offline room notifications
Rules:
1. No room detail polling from notification badge refresh
2. No direct dependency from notification UI to chat room rendering
## New Frontend Layers
### A. UI Layer
Files under `components/` and pane files.
Responsibilities:
1. Render props only
2. Emit user actions only
### B. Feature Controller Layer
Files under `hooks/`.
Responsibilities:
1. Manage one feature's state machine
2. Translate UI actions to gateway calls
3. Own loading and error state
### C. Gateway Layer
Files under `data/`.
Responsibilities:
1. Wrap all chat REST calls
2. Wrap all chat socket entry points
3. Normalize fallback behavior and timeouts in one place
This is the critical separation that the old frontend does not have.
## Target Folder Shape
```text
src/app/main/chatV2/
ChatWorkspaceV2.tsx
types.ts
data/
chatGateway.ts
chatConnectionGateway.ts
hooks/
useChatWorkspaceState.ts
useConversationListController.ts
useConversationRoomController.ts
useComposerController.ts
useRuntimeController.ts
useNotificationController.ts
components/
ConversationListPane.tsx
ConversationRoomPane.tsx
Composer.tsx
RuntimePane.tsx
ErrorPane.tsx
```
## Migration Waves
### Wave 1
1. Freeze mobile layout
2. Introduce chatV2 gateway layer
3. Move list/detail/runtime access behind the gateway
### Wave 2
1. Replace list controller
2. Replace room controller
3. Replace composer controller
### Wave 3
1. Reconnect runtime and notifications through new controllers
2. Remove old `MainChatPanel` effect chains
### Wave 4
1. Make `MainChatPanel` a thin compatibility wrapper or replace it entirely
## Success Criteria
1. Main load triggers one list fetch
2. Opening one room triggers one detail fetch
3. No direct browser fallback to external `:3100` ports on remote hosts
4. WebSocket and REST routing live in one gateway boundary
5. One pane can fail without blanking the others
6. Mobile layout matches the pre-rewrite visual structure

View File

@@ -1,100 +0,0 @@
# 프로젝트 구성 개요
## 목적
현재 저장소의 화면 구조와 문서 체계를 빠르게 파악하기 위한 최신 개요 문서입니다.
## 기술 스택
- React
- Vite
- TypeScript
- Ant Design
- Recharts
- React Router
## 최상위 앱 구조
- `src/app/main`: 메인 앱 프레임, 상단 메뉴, 사이드바, 본문, 검색 연동
- `src/features`: 프로젝트 전용 기능 화면
- `src/components`: 재사용 가능한 UI 컴포넌트
- `src/widgets`: 샘플/위젯 단위 UI
- `docs`: 기능/컴포넌트/작업일지 문서
- `etc/servers/work-server`: Plan API 연동 서버 자산
## 현재 주요 기능 축
### Docs
- `docs/**/*.md`를 수집해 문서 화면에 노출
- 작업일지, 기능 문서, 컴포넌트 문서를 같은 흐름으로 탐색
- `docs/features` 아래 문서는 `Docs / 기능문서` 메뉴에서 동적으로 확인 가능
### APIs
- 컴포넌트 샘플
- 위젯 샘플
### Plans
- Plan 자동화 목록/상세
- release 검수
- 차트
- 스케줄
- 히스토리 확장 영역
### Chat
- Codex Live
- 에러 로그
`Codex Live`는 현재 프로젝트 환경의 `main_project`를 기준 저장소로 사용합니다. 소스 수정이 필요하면 **현재 프로젝트 루트의 로컬 `main` 작업본을 바로 수정**합니다.
일반 채팅 요청과 작업메모 반영 요청도 같은 기준을 따르며, 별도 브랜치 생성 없이 현재 프로젝트 루트에서 바로 수정하는 것을 기본 동작으로 사용합니다.
채팅에서 제공되는 파일/문서/이미지/코드 리소스와 첨부 파일은 세션별로 `public/.codex_chat/<chat-session-id>/resource/...` 아래에 노출됩니다.
### Play
- Layout Editor
- 저장된 레이아웃 기록
## Plan 기능 구조
Plan 관련 코드는 `src/features/planBoard`에 집중되어 있습니다.
- `PlanBoardPage.tsx`: 자동화 목록과 상세 편집
- `ReleaseReviewPage.tsx`: release 검수
- `PlanSchedulePage.tsx`: 반복 등록 스케줄
- `charts.tsx`: 작업 추이 차트
- `api.ts`: API 통신
- `types.ts`: 상태/타입 정의
## 문서 구조
- `docs/worklogs`: 날짜별 작업 기록
- `docs/features`: 기능 설명과 운영 가이드
- `docs/components`: 공통 컴포넌트 설명
- `docs/templates`: 기능/작업일지 템플릿
현재 `docs/features`의 핵심 문서는 다음과 같습니다.
- `project-setup.md`
- `search-layer.md`
- `plan-board-review.md`
- `plan-automation.md`
- `plan-schedule.md`
- `plan-usage.md`
## 검색/문서 연계
- 통합 검색 옵션은 `src/app/main/mainView/searchOptions.ts`에서 구성
- 문서, Plan 화면, 컴포넌트 샘플, 위젯 샘플을 하나의 검색 엔트리로 제공
- 선택 시 해당 메뉴와 포커스 대상으로 바로 이동
## 운영 메모
- 기능 문서는 구현 파일명과 메뉴명을 그대로 써서 찾기 쉽게 유지
- `docs/features` 변경분이 보이지 않으면 현재 선택한 Docs 폴더가 `기능문서`인지 먼저 확인
- Plan 관련 변경은 문서와 라우팅/검색 옵션을 함께 확인
- 스케줄, release 검수, 차트처럼 화면이 분리된 기능은 개별 문서를 유지

View File

@@ -0,0 +1,34 @@
# 2026-04-21 작업일지
## 오늘 작업
- 화면 캡처 추가 예정
## 스크린샷
![feature-chat-live](../assets/worklogs/2026-04-21/feature-chat-live.png)
## 소스
### 파일 1: `path/to/file.tsx`
- 변경 목적과 핵심 수정 내용을 한 줄로 정리
```diff
# 이 파일의 핵심 diff
- before
+ after
```
### 파일 2: `path/to/another-file.ts`
- 필요 없으면 이 섹션은 삭제
## 실행 커맨드
```bash
```
## 변경 파일
-