feat: expand live chat and work server tools
This commit is contained in:
@@ -100,6 +100,9 @@ src/components
|
||||
- 위치: `src/features/layout`
|
||||
- 대상: 현재 프로젝트 화면에서만 사용하는 레이아웃
|
||||
- 예시: 컴포넌트 샘플 목록, 위젯 샘플 목록, Docs markdown preview, Plan 게시판
|
||||
- `Layout Editor`의 기능 명세는 위젯 기본 스펙 정의가 아니라, 현재 레이아웃에 배치된 컴포넌트의 화면 역할과 상호작용을 기술하는 데이터로 취급
|
||||
- 따라서 컴포넌트 간 이벤트/상태 연결과 API 연결 흐름도 `Layout Editor` 기능 명세에서 구현 가능한 범위로 본다
|
||||
- 따라서 샘플 메타나 위젯 기본 기능을 `Layout Editor` 기능 명세에 자동 주입하지 않음
|
||||
|
||||
프로젝트 종속 기능 규칙:
|
||||
|
||||
@@ -135,6 +138,13 @@ src/components
|
||||
- alpha 버전 배포는 `npm publish --tag alpha`
|
||||
- Nexus 인증은 `~/.npmrc`의 `username / _password(base64) / email` 방식으로 확인
|
||||
|
||||
## 8-1. 웹푸쉬 작업 메모
|
||||
|
||||
- 동일한 웹푸쉬를 새 알림으로 교체하려면 DB에서 이전 알림을 지우지 말고 `POST /api/notifications/send` 호출 시 `data.notificationKey` 또는 `threadId`를 고정값으로 보냅니다.
|
||||
- 서비스워커는 같은 `notificationKey`를 `tag`로 사용하므로 같은 브라우저의 이전 알림이 자동으로 대체됩니다.
|
||||
- 특정 브라우저 클라이언트에만 보내려면 같은 API payload에 `targetClientIds: ['클라이언트ID']`를 넣습니다.
|
||||
- 대상 클라이언트 ID가 필요하면 `web_push_subscriptions.device_id`를 조회하고, raw SQL 대신 `/api/crud/web_push_subscriptions/select` 같은 기존 CRUD API를 우선 사용합니다.
|
||||
|
||||
## 9. etc 운영 기준
|
||||
|
||||
- 부가 서버/DB/타언어 프로젝트는 `etc` 아래에서 분리 관리
|
||||
|
||||
@@ -22,16 +22,22 @@
|
||||
## 입력 항목
|
||||
|
||||
- `workId`: 반복 등록할 작업 ID
|
||||
- 스케줄이 실제 자동화 접수로 Plan을 만들 때 이 값을 베이스 ID로 사용합니다.
|
||||
- 생성되는 Plan 작업 ID는 `workId-1`부터 `workId-999` 범위의 suffix를 붙여 유니크하게 관리합니다.
|
||||
- `note`: 매번 생성될 요청 메모
|
||||
- `automationType`: 자동화 유형
|
||||
- `plan`: Markdown 스타일 Plan 문서 등록/접수
|
||||
- `auto_worker`: 실제 자동 작업 실행
|
||||
- `command_execution`, `non_source_work`: 기존 분류 유지
|
||||
- 자동화 유형 관리를 통해 등록된 항목을 그대로 선택합니다.
|
||||
- 스케줄 실행 시 선택한 자동화 유형 ID를 유지한 채 자동화 작업메모를 등록하고 즉시 접수합니다.
|
||||
- `releaseTarget`: 반영 대상 브랜치
|
||||
- `jangsingProcessingRequired`: 기능동작확인 필요 여부
|
||||
- `autoDeployToMain`: main 자동 반영 대상 여부
|
||||
- `enabled`: 스케줄 사용 여부
|
||||
- `immediateRunEnabled`: 생성 직후 바로 등록 허용 여부
|
||||
- `refreshContextSnapshotOnNextRun`: 다음 자동 실행 1회에 한해 프로젝트 구조/관련 소스를 다시 읽고 `.auto_codex/schedule/<id>/` 아래 Markdown 문서를 재정리할지 여부
|
||||
- `executionMode`: `codex` 또는 `managed-service`
|
||||
- `managed-service`를 선택하면 스케줄 PK가 포함된 `.auto_codex/schedule/<id>/managed-service/...` 경로에 서비스 패키지 번들을 생성해 구분합니다.
|
||||
- 스케줄 삭제 시 해당 디렉터리도 함께 삭제합니다.
|
||||
- `recreateManagedServiceOnNextSave`: 관리형 서비스 패키지를 저장 시 다시 생성할지 여부
|
||||
|
||||
## 스케줄 모드
|
||||
|
||||
@@ -75,6 +81,8 @@
|
||||
- 자주 반복되는 운영 작업은 고정 `workId`로 등록
|
||||
- 사람이 검토해야 하는 작업은 `autoDeployToMain`을 끄고 release 검수 단계에서 확인
|
||||
- 단순 알림성/반복성 작업은 `immediateRunEnabled`를 켜서 누락 없이 시작
|
||||
- 기존 스케줄 참조 문서를 다시 만들고 싶으면 `refreshContextSnapshotOnNextRun`을 켠 뒤 저장하면 다음 실행 1회 후 자동 해제
|
||||
- 외부 프로그램으로 확장할 예정인 작업은 `managed-service`로 분리해 두면 스케줄 PK 기준 서비스 키와 패키지 경로를 고정할 수 있음
|
||||
- 짧은 주기 스케줄은 10분 이상으로 유지해 중복 생성 위험을 낮춤
|
||||
|
||||
## API 경로 메모
|
||||
|
||||
Reference in New Issue
Block a user