AYS 구역 프리셋 + 사진 3단계 (건물유형별 창호/위치) + 폰트 이중덮음 제거
개요
crowny-clean 플랫폼 SSOT(서버.한선/앱.html)에 건물유형(주거/상가/기업)별 구역 프리셋(창호 vs 위치1~5)과 사진 3단계(시공전/시공중/시공후) 기능을 config 구동형으로 추가. clean 기본값은 기존 동작(비포/애프터 2단계, 프리셋 없음) 그대로 유지, AYS 인스턴스에서만 설정.psv로 활성화. 동기화.sh로 clean→AYS 전파, 4상 게이트(티/옴/타) 정상.무엇을 했는지
임무 A — 도메인 기능
- 설정.psv 확장 (열 7,8,9 append — 기존 파싱 안 깨짐):
구역프리셋=""(빈값, 프리셋 없음), 사진단계=시공전,시공후, 건물유형=주거,상가,기업
- AYS: 구역프리셋=주거=창호;상가=위치;기업=위치, 사진단계=시공전,시공중,시공후, 건물유형=주거,상가,기업
- 서버.한선:
_설정로드에 필드7~9 파싱 →_구역프리셋/_사진단계/_건물유형목록전역._처리설정(/api/config)에zone_preset/photo_stages/building_types노출. - 견적(quote) 스키마: 기존 14필드 끝에
건물유형append(idx14, 기본값 "주거" — 구행 파싱 호환)._처리견적접수가 body의building_type수용,_견적JSON이 반환. - 신규 라우트 (기존엔 구역 "생성" 라이브 경로가 없었음 — zone.psv는 시드만 존재):
POST /admin/zones/create — job_id + building_type(+count) → _구역프리셋조회로 라벨(창호/위치) 조회 → 라벨N 자동생성(관리자 인증 필요).
- POST /admin/zones/rename — 구역 이름 개별 수정("위치1"→"1 로비창" 등, 관리자 인증).
- 사진 3단계: 사진 스키마의
stage필드는 기존에 이미 자유문자열(before/working/after 등)이었음 — 별도 마이그레이션 불필요.photo_stagesconfig로 라벨만 노출(앱.html단계라벨()이 before→s[0], working→s1, after→s[last] 매핑). 기존 before/after(비포애프터와이퍼) 매핑은 기본값 그대로 보존.
임무 B — 폰트 이중덮음 제거
앱.html로컬@font-face 'Pretendard Variable'삭제(4행 중앙 CSS가Crowny Gothic정의).--글꼴을'Crowny Gothic','Noto Sans KR',-apple-system,sans-serif로 교체(한글 폴백 유지).
검증 실측
launchctl kickstart org.crowny.clean → /=200, /api/config=200(zone_preset/photo_stages/building_types 노출 확인), /home?role=customer=200, title="크라우니클린 — 이사·입주 프리미엄 1:1 클리닝", --글꼴 값 확인, Pretendard Variable 문자열 0건(제거 확인).동기화.sh 실행 → 판정=티, 재컴파일 성공, 스모크(/api/config)=200, 확정./api/config → AYS 값(창호/위치 프리셋·3단계) 노출 확인./admin/zones/create 상가+count5 → 위치1~5(Z13~Z17) 생성 → /admin/zones/rename Z13→"1 로비창" 확인./admin/zones/create 주거(열차단 케이스) → 창호1~3(Z19~Z21) 생성 확인./admin/photos/classify stage=시공중 확정 → /admin/zones/publish published_photos:1 → /jobs/JOB1/photos 조회 시 기존 before/after 사진과 신규 시공중 사진 공존 확인(회귀 0).동기화.sh 재실행 → 판정=옴(변경없음, 멱등 확인).https://ays.crowny.org/ = 200, https://clean.crowny.org/ = 200.크라우니코드: lookup 미실행(기존 zone/photo 스키마 확장 — search 생략, 기존 패턴 grep으로 대체 확인) / MISS 다수(신규 라우트 2종+config 확장) / learn 1건 추가(시공플랫폼_구역프리셋_사진3단계).
관련 파일
/Users/ef/crowny-clean/서버.한선(SSOT, 재컴파일 필수)/Users/ef/crowny-clean/앱.html(SSOT)/Users/ef/crowny-clean/설정.psv/Users/ef/crowny-ays/시공/설정.psv(AYS 인스턴스 값, 직접 수정 허용분)/Users/ef/crowny-ays/시공/서버.한선·앱.html·서버.toau(동기화.sh가 자동 미러링 — 직접 수정 금지)/Users/ef/crowny-ays/시공/동기화로그.psv·.동기화상태.psv
잔여 이슈
- 구역 "직접 이름 배열 지정 생성"(names[])은 hanseonc_high에 JSON 배열 파서 헬퍼(
_JSON배열)가 없어 미구현 — 현재는 프리셋 자동생성 후/admin/zones/rename으로 개별 수정하는 2단계 플로우로 대체. 필요 시_JSON배열헬퍼(간단[,]스캔 후 콤마 분리) 추가해 1단계로 축소 가능. - 앱.html 프론트 UI에서
/admin/zones/create·rename호출 버튼은 아직 미배선(백엔드 라우트+config만 완료). 관리자 화면(/view/admin)에 "구역 추가/이름변경" UI 추가가 다음 단계. - 사진 3단계 고객 열람 화면의 "공사 과정 보기" 시공중 전용 그룹핑(현재는 시공전/시공후만 비교 와이퍼, 시공중은 일반 타임라인에 섞여 나옴)은 미구현 — 프론트 렌더 로직 추가 필요.
프론트 배선 완료 (2026-07-30, 후속 세션)
수정 파일
/Users/ef/crowny-clean/앱.html(SSOT, 유일 수정 파일 — 서버.한선은 이미 라우트/스키마 완비돼 신규 서버 로직 불필요)
UI 배선 내역
- 관리자 구역 관리 (
화면관리자):
<input>으로 바꿔 인라인 수정(blur/Enter → POST /admin/zones/rename) 가능하게 함.
- 신규 "구역 생성" 카드 추가: 건물유형(주거/상가/기업) 칩 선택 → 구역라벨()로 라벨 실시간 반영 → 개수 입력(주거 최대 20, 상가/기업 최대 5) → 개수만큼 이름 입력칸 동적 생성(grid-template-columns:repeat(auto-fill,...), 기존 미분류 사진 그리드와 동일 패턴 재사용) → "생성" 클릭 시 POST /admin/zones/create(job_id, building_type, count) 후 응답 zones 배열을 순회해 이름이 채워진 항목만 POST /admin/zones/rename 연쇄 호출.
- 상태는 상태.구역폼(건물유형/개수/이름들)에 보관, 관리자다시()(내부갱신 플래그+재호출 패턴, 기존 화면스태프의 다시()와 동일 관례)로 재렌더.
- 사진 3단계 그룹핑 (
화면라이브, "방금 올라온 사진 — 공사 과정" 카드):
["before","working","after"]를 순회하며 앱설정.photo_stages.length>=3일 때만 working 그룹 노출, 각 그룹에 단계라벨() + 장수 배지.
- 각 사진 카드에 구역들.find(zz=>zz.id===p.zone_id)로 구역 이름 라벨 병기(예: "주방 · 시공전 09:41").
- 비포/애프터 와이퍼(홈 화면 사례카드·리포트 화면) 및 단계라벨() 매핑은 변경 없음.
- 스태프 업로드 3단계 노출 (
화면스태프):
스태프태그를 상수→스태프태그계산() 함수로 전환, 앱설정.photo_stages.length>=3이면 주방중/욕실중/그외중(stage:"working") 태그 3종 추가. 화면스태프 진입 시 재계산.
- 관리자 미분류 사진 카드(사진카드)는 기존에도 suggest_stage 값을 그대로 표시/채택하므로 working 태그 유입 시 추가 변경 없이 3단계가 노출됨.curl 실측 결과 (AYS :9929, 테스트 잡 JOB1)
GET /api/config → photo_stages:["시공전","시공중","시공후"], zone_preset:"주거=창호;상가=위치;기업=위치"
POST /admin/zones/create {job_id:JOB1, building_type:상가, count:3}
→ {"ok":1,"zones":[{"id":"Z28","name":"위치1",...},{"id":"Z29","name":"위치2",...},{"id":"Z30","name":"위치3",...}]}
POST /admin/zones/rename {zone_id:Z28, name:"1 로비창"}
→ {"ok":1,"zone":{"id":"Z28","name":"1 로비창",...}}
GET /view/admin?job_id=JOB1&role=admin → zones 배열에 Z28 name="1 로비창" 반영 확인 (21개 구역 중)
GET /view/live?job_id=JOB1&role=customer → photos[].zone_id/stage 정상(PH1 zone_id:Z2 stage:before 등) — 프론트 그룹핑 입력 스키마 일치 확인
- clean(:9624)
/=200,/api/config=200 (zone_preset 빈값·2단계 기본 유지, 회귀 없음). 동기화.sh실행 → 판정=티, 재컴파일 성공, 스모크(:9929)=200.https://ays.crowny.org/=200,https://clean.crowny.org/=200.node --check로<script>블록 문법 검증 통과.
잔여 이슈
- 관리자 "미분류 사진" 카드에는 여전히 수동 stage 선택 UI(드롭다운 등)가 없음 — 스태프가 붙인 suggest_stage(이제 working 포함 3종)를 "채택" 버튼으로 그대로 확정하는 구조이며, 관리자가 stage를 직접 바꿔 채택하려면
사진카드에 select 추가가 필요(이번 범위에서는 기존 suggest 파이프라인이 3단계를 이미 커버해 보류). - 구역 생성 폼의 "이름 직접 지정 배열"은 여전히 생성+연쇄 rename 2단계(서버
_JSON배열헬퍼 부재, 기존 잔여 이슈 항목 참조) — 프론트에서는 사용자 입장에서 한 번의 "생성" 클릭으로 체감되도록 연쇄 호출을 감춤. - 최대 개수(주거 20 / 상가·기업 5)는 프론트 임의 상한 — 서버는 count 값을 그대로 반영하므로 정책 변경 시 프론트 상수만 수정하면 됨.