크라우니클라우드 A절(프론트 미배선) + 신규 API 배선
개요
/Users/ef/crowny-services/docs/클라우드-미작동-보수목록.md A절 + 신규 통계/로그 API를 프론트에 배선. 백엔드 모듈(클라우드_서비스.한선)은 직전 단계에서 이미 구현돼 있었음 — 이번 세션은 프론트(index.html) 배선 + 검증.
무엇을 했는지
- A-1 서비스 설정 저장:
index.html cc-saveCur 클릭 핸들러를 showToast('...지원되지 않습니다')에서 실제 POST /api/services/update 호출로 교체. 성공 시 "저장 요청 대기열 등록됨 · 감사 로그 기록" 토스트, 실패 시 "저장 실패". 저장 후 loadServices()+loadGuard() 재조회.
- A-2 라우트 모달:
submitRoute 핸들러가 이미 /api/routes/add·/api/routes/edit를 정확히 호출하고 있음을 코드 확인(정적추출 누락일 뿐 실배선은 되어 있었음) → 확인됨, 추가 조치 불필요.
- 서비스 상세 통계 4칸: 하드코딩값(
12,408/14d 06:12/0.02%)을 S.svcStats(신규 상태) + loadServiceStats(id)(신규 함수, GET /api/services/stats?id=)로 교체. null 필드는 — 표시(허위 수치 금지 준수).
- 서비스 상세 실시간 로그: 하드코딩 로그 텍스트를
S.svcLogs + loadServiceLogs(id)(GET /api/services/logs?id=&lines=40)로 교체. 응답 lines 배열을 줄바꿈 join. 중지된 서비스는 기존 "서비스가 중지되어 로그가 없습니다" 문구 유지.
- 서비스 목록에서
cc-openSvc 클릭 시 loadServiceStats/loadServiceLogs를 뷰 전환과 함께 트리거(다른 loadDeployCheck 패턴과 동일한 스타일).
관련 파일
/Users/ef/crowny-services/public/cloud/index.html — 이번 세션 편집 대상(JS 데이터 계층만, 마크업/CSS 무변경)/Users/ef/crowny-services/클라우드_서비스.한선 — 이미 구현돼 있던 백엔드(update/stats/logs 핸들러, B-1~B-3)/Users/ef/crowny-services/클라우드관리.toau — 재컴파일 산출물(STRICT 0경고)- 백업:
/Users/ef/crowny-services/.bak-보수-20260730/index.html.<epoch>
검증 결과 (실측)
- 컴파일:
hanseonc_high 클라우드관리.한선 2>/dev/null → exit 0, STRICT 경고 0 (7모듈 전부 가져오기 성공, 62474 큐브 생성)
- GET 9종 전부 200: health·node·services·routes·guard·tier·chain·deploy/check·deploy/snapshot
- 신규
POST /api/services/update 실측: {"queued":1,"pendingId":"pend_..."}
- 신규
GET /api/services/stats?id=bible: {"requests":null,"errorRate":null,"mem":41,"uptime":"31:33","note":"..."}
- 신규
GET /api/services/logs?id=bible&lines=5: {"lines":["[크라우니서비스] bible ..."]}
디자인이식.sh diff crowny-cloud → 판정=티 점수=100 신규색=0 유실색=0 신규치수=0크라우니AI검증.sh dump → console.json=[](콘솔에러 0건), 렌더 정상(로그인 화면, meta.ok=true)- JS 문법 검증:
node -e "new Function(...)" → OK
- 큐 오염 정리: 검증 중 발생한 테스트용 대기큐 3건(
testsvc999·bible update/toggle) 제거, 백업 대기큐.psv.bak-검증정리-20260730 남김. 재기동 후 GET /api/guard → pendings:[] 확인.
잔여 이슈
/api/services/stats의 requests/errorRate는 서비스별 카운터 미구현으로 항상 null(설계상 의도, B-2 스펙대로 — 허위 수치 금지). 실제 카운팅은 이번 범위 밖.- 큐 파일이 SIGTERM 직후 즉시 kill한 프로세스가 재기동 전 파일을 되돌려 쓰는 듯한 현상 관측(구 PID가 완전히 죽기 전 새 PID가 붙어 stale 인메모리 캐시로 재저장 추정) →
kill -9 + 7초 대기 후에는 정상 반영됨. 향후 큐 정리 작업 시 kill -9+충분한 대기 권장(참고용 관찰, 이번 작업 자체는 정상 완료).