사용자만 할 수 있는 것

Mapbox 회사 계정 토큰

답(2026-08-26) — 요모테리 토큰으로 일단 구현한다. 회사 계정은 담당자에게 요청해 뒀고, 시간이 없어 지도 없이 두는 쪽이 더 비싸다는 판단이다. 토큰은 소스에 안 넣는다 — .env.development 로 받는다(커밋 안 됨).

>

✅ 2026-08-26 저녁 — 로컬은 됐다. 옛 커밋에서 꺼내 .env.development 에 넣었고 지도가 그려진다(스타일·아이콘셋·폰트 전부 200). 연동 QA 세션이 개발 env 에도 넣어 관제·대시보드·현장 폼이 다 살았다.

>

🔴 남은 것 — 운영과 QA 환경에는 토큰이 아직 없다. 그대로 배포하면 그 환경에서만 지도가 안 뜬다. 배포 시크릿(DEV_DOTENV 같은 자리)에 넣어야 하고 그건 사용자만 할 수 있다.

옛 화면이 개인 계정(yomoteri) 토큰을 소스에 들고 있었다. 2026-08-25 에 지웠고 새 코드에 다시 넣지 않는다 — 남의 계정으로 요금이 나가고, 그쪽이 지우면 지도가 죽는다.

⚠️ 2026-08-26 — 개발 환경에는 토큰이 들어왔다. apps/web/.env.development 에 VITE_MAPBOX_TOKEN 이 있고 지도가 실제로 그려진다 — 관제·대시보드·현장 추가 모두. 연동 QA 로 현장 추가를 처음 끝까지 해 봤다(지도를 클릭해 좌표를 찍고 저장까지).

남은 것은 운영·QA 다. .env.production · .env.qa 에는 아직 없다 — 그대로 배포하면 그 환경에서는 지도가 안 뜬다.

회사 계정 토큰이 나오기 전까지 지도가 안 보이는 게 맞다. VITE_MAPBOX_TOKEN 환경변수로 받는다. 순서는 SETUP_GUIDE.md.

막는 화면: 대시보드 지도 · 관제 전 화면 · 현장/차고지 추가.

「지오펜스 지정만」이 아니다(2026-08-26 연동 QA 실측) — 현장 추가는 저장 자체가 막힌다. 주소·현장명·건설사·관리자·연락처를 다 채워도 [다음]이 disabled 그대로다. 서버가 좌표를 필수로 받는데 그 좌표를 지도에서만 찍을 수 있어서다. 화면은 그 이유를 말해 준다 — 「지도에서 위치를 선택해야 저장할 수 있습니다.」

서버 쪽 토큰은 별개다. 그것이 비면 eta 만 전부 null 이 된다 —

지도는 보이는데 도착 예정만 안 나오면 우리 토큰이 아니라 서버 쪽이다.

>

서버 쪽은 살아 있는 것이 확인됐다(2026-08-26 실측). 장비 23대 중 17대에 eta 가 온다 —

서버 토큰이 비었으면 전부 null 이어야 한다. 없는 것은 우리 VITE_MAPBOX_TOKEN 하나뿐이다.

확인요청서를 담당자에게 전달

답(2026-08-26) — 디자이너에게 보냈고 답이 오는 중이다(57건 도착). 백엔드·기획은 내일 보낸다.

docs/features/web/handoff/ 의 것을 각 담당자에게 보내야 한다. 우리가 못 보낸다.

#### 🔴 문서가 받는 사람마다 한 장이다 (2026-08-26 저녁에 다시 바꿨다)

이름에 날짜를 담던 것도, 「보낸 것 / 아직 안 보낸 것」으로 가르던 것도 걷어냈다. 이제 파일은 셋이고 빌드할 때마다 덮어쓴다.

| 받는 사람 | 파일 | 담긴 것 | |---|---|---| | 디자이너 | design_웹.html | 전부 (문항 + 표기 지적) | | 백엔드 | backend.md | 전부 | | 기획 | plan.md | 전부 |

「보낸 것 / 안 보낸 것」 분류는 디자이너 리뷰 사이트가 맡는다 — 우리가 파일로 안 가른다.

디자인 문항은 리뷰 사이트로도 나간다 — https://jlink-review.pages.dev 평일 08:00 에 디자이너 두 분께 메일이 나가고, 거기 숫자는 우리 문서에서 바로 센다.

보내신 뒤에 한 번 알려 주시면 대장에 적어 둔다(build.py web --sent). 파일은 안 바뀌고, 그때 문장의 해시만 남는다 — 그래야 나중에 문항을 고쳤을 때 「보낸 뒤에 바뀐 것」을 빌드가 한 줄로 짚어 준다.

#### 🔴 보낸 뒤에 묻는 말이 바뀐 문항 일곱 — 담당자가 든 판은 옛 문장이다

| 문항 | 무엇이 바뀌었나 | |---|---| | B-32 (백엔드) | 「예정 타설량」이 아니라 타설량 전체가 없다로 정정 | | P-35 (기획) | 막히는 화면 29장 실측과 도면에 조직 선택 UI 가 없다는 확인 | | P-28 (기획) | 한 화면이 아니라 여러 화면에서 코드가 그대로 뜬다로 넓힘 | | P-40 · P-32 (기획) | 묻는 말과 선택지 | | D-54 · D-61 (디자인) | 답이 안 맞아 다시 물었다 — 그래서 아직 열려 있다 |

문서에 「문장 고침」 배지가 붙어 있어 따로 설명 안 하셔도 됩니다. 빌드할 때마다 이 목록이 다시 찍히므로 외울 필요도 없습니다.

「지금 웹은 이렇습니다」만 바뀐 것은 여기 안 셉니다(2026-08-26 저녁에 기준을 바꿨습니다).

그 줄은 구현이 움직일 때마다 바뀌는데, 그것까지 알리면 정작 질문이 바뀐 것이 묻힙니다.

🔴 이미 보낸 디자이너 파일은 답을 못 적는다 — 고친 판으로 다시 보냈다

답(2026-08-26) — 더 이상 필요 없다 — 리뷰 사이트를 만들어 그쪽에서 답을 적는다.

문서 안에 답변 항목이 하나도 안 실렸다(const ITEMS = []). 그래서 받은 분 화면에서는

• 선택지를 눌러도 라디오 점이 안 찬다 — 무엇을 골랐는지 알 수 없다
• [답변 복사]가 머리말과 「그 밖에 알려 주신 것」만 뱉는다 — 고른 답이 하나도 안 실린다
• 그런데 「저장됨」은 뜬다(저장 자체는 됐다) — 그래서 더 헷갈린다

지금 파일은 고쳐져 있다. 답은 브라우저에 그대로 남아 있어서 다시 받은 파일을 열면 되살아난다.

다시 보낼 때 이 두 줄만 전하면 된다 — 「① 앞 파일은 답변 저장이 안 됩니다. 이 파일로 다시 열어 주세요(적으신 답은 그대로 살아납니다). ② D-62 하나 늘었습니다: 장비 추가의 2단계 화면이 저희에게 없습니다.」

디자이너에게 보낸 뒤 문항이 늘어난 것은 없다(늘어난 P-36·P-37 은 기획 몫이다).

디자인 문항이 늘면 새 날짜 파일을 만들어 「무엇이 늘었는지」와 함께 다시 보낸다.

3. 커밋을 푸시할지 판단 ✅ 끝냄(2026-08-26)

답(2026-08-26) — 푸시한다. 푸시하면 개발 서버에 배포된다(운영은 아니다).

agent 는 git push 를 하지 않는다(루트 CLAUDE.md §1). dev/JLink push 가 개발 서버 배포를 일으킨다(.github/workflows/deploy-jlink.yml, 경로 필터 없음). 2026-08-26 기준 미푸시 커밋 200개. 하룻밤치가 통째로 한 번에 나간다 — 그만큼 위험이 뭉쳐 있다. 푸시 전에 개발 서버가 잠깐 멈춰도 되는 시각인지 보고 판단한다.

푸시 전에 아침 QA 를 먼저 도는 편이 안전하다. 밤에 고친 것 중 화면을 봐야만 확인되는 것이 여럿이다(실패 표시 다섯 · 마이 페이지 높이 · 관제 수치). 03_screens/screen-qa-plan.md 맨 앞에 그 목록이 있다.

2026-08-26 — 그 QA 를 일부만 돌았다. 로그인이 안 돼 목 백엔드로 돌렸고 화면층 2장 · 연동 8건에서 멈췄다(사람이 중단). 아직 화면으로 확인 안 된 것이 남아 있다 — 어디까지 봤는지는 screen-qa-plan.md · wired-qa-plan.md 의 「실제로 돈 회차」에 있다.

초대 메일이 이미 발송된 적이 있나

답(2026-08-26) — 지금은 모른다. 확인되면 그때 판단한다.

확인요청 B-15 — 서버가 초대 메일에 {WEB_BASE_URL}/set-password?token=... 를 넣는데 우리 라우트는 /auth/new-admin 이다. 이미 나간 메일이 있으면 그 링크가 전부 죽어 있다. 있으면 웹이 경로를 추가하는 쪽이 안전하고, 없으면 서버 링크를 고치는 쪽이 깨끗하다.

확인요청을 나눠 보낼지 판단

답(2026-08-26) — 나눠 보내는 중이다 — 디자인은 보냈고 백엔드·기획은 내일이다.

숫자는 여기 안 적는다. 문항이 하루에도 여러 번 늘고 답이 오면 줄어서, 적어 두면 그날 안에 낡는다. 빌드가 찍어 주는 줄을 봐라.

python3 docs/features/_delivery/build.py web
→ 남은 질문 — 디자인 11/68 · 백엔드 16/38 · 기획 35/43

「남은 것」은 아직 답이 없어 입력칸이 살아 있는 것이고, 디자이너 리뷰 사이트가 세는 기준과 같다. 한 번에 보내면 답이 안 온다. 아래 경위는 처음 112건을 거를 때의 기록이다 — 그 뒤로 문항이 늘었다.

보내기 전에 115건의 「지금 웹은 이렇습니다」를 코드와 전수 대조했다. 열여섯이 낡아 있었고 전부 고쳤다(둘은 아예 취소했다 — 이미 서버에 있거나 이미 해결된 것이었다).

왜 이만큼 낡았나 — 그 칸은 질문을 쓸 때 맞았다가 구현이 바뀌면 거짓이 된다. 밤새 코드가 많이 움직였고, 질문은 그대로 있었다.

2026-08-26 — 115건 전수 대조가 끝났다. 마지막 열둘(Foundation·Icons)에서 하나가 더 나왔다 (만들어 놓고 「안 만들었다」고 적혀 있던 것). 총 열일곱이 낡아 있었고 전부 고쳤다.

그 뒤 둘이 늘어 117건이다(P-32 언어 드롭다운 · P-33 오프라인 상태). 둘은 아침에 쓴 것이라 낡지 않았다.

2026-08-26 — 그 거르기가 끝났다. 117 → 112건이다.

| 걷어낸 것 | 왜 | |---|---| | B-27 | 질문의 전제가 틀렸다 — 장비 위치 목록은 페이지로 안 끊긴다 | | B-29 | 서버에 커서 페이징이 이미 다 있다 — 우리가 안 쓴 것이다 | | B-14·B-24 | 이미 고쳐 놓고 질문만 남아 있었다 | | P-3 | 답할 것이 없는 기록용인데 숫자까지 낡았다 |

B-27 · B-29 는 우리 구현이 남은 것이다 — 무엇을 해야 하는지 _delivery/canceled.md 에 적었다.

「이미 구현했으니 취소」로 올라온 것 셋은 반려했다. P-6(로그인 후 언어 변경)과 P-9(영문 21개)는 그 사이에 우리가 확답 없이 채워 넣은 것이라 질문이 사라진 게 아니라 급해졌다 — 지어낸 것이 확정된 사양처럼 화면에 서 있게 된다. 둘 다 그 사실대로 고쳐 뒀다.

「지금 웹은 이렇습니다」가 낡은 것 넷도 고쳤다(D-8 · D-18 · D-28 · P-6 · P-9). 그중 D-28 은 문서만의 문제가 아니라 실제로 화면에 새던 아이콘이어서 코드도 함께 고쳤다.

이제 보내도 된다. 되돌릴 수 없는 것부터 먼저 보내는 편이 낫다 — 아래 넷은 답이 늦으면 그만큼 막힌다.

| 먼저 | 왜 | |---|---| | P-19 장비 「연결 해제」가 무엇을 끊나 | 잘못 고르면 차량이 지워진다. 지금은 버튼이 아무 일도 안 한다 | | P-22 배정 변경 중간 실패 | 실패하면 그 기사가 무배정으로 남고 앱에 미등록 화면이 뜬다 | | D-45 현장 반경 | 서버가 필수로 요구해 300m 를 지어 박아 뒀다 | | P-24 장비 추가 권한 | 도면이 고객 화면에 버튼을 뒀는데 서버는 최고 관리자만 허용한다 |

16. 🔴 자동 운전 프롬프트가 낡았다 — 다섯 줄을 고쳐야 한다 ✅ 끝냄(2026-08-26)

답(2026-08-26) — 고쳤다(v3). 낡은 다섯 줄을 지금 사실로 갈고, 숫자는 빌드가 찍은 것을 그대로 쓰게 했다.

프롬프트는 cron 안에 있어 제가 못 고칩니다. 매 회차 이 문장들을 읽고 시작하므로 낡은 채로 두면 안 해도 될 일을 하거나, 이미 없는 파일을 찾습니다.

| 어디 | 지금 적힌 것 | 사실 | |---|---|---| | §1 첫 줄 | 「확인요청 116건을 날짜 파일로 낸다 — design_웹_<날짜>.html…」 | 146건이고 날짜 파일이 없다. design_웹.html · backend.md · plan.md 한 장씩이고 빌드마다 덮는다 | | §1 둘째 줄 | 「이미 보낸 파일을 덮지 않는다」 | 덮는다. 안 덮는 규칙을 걷어냈다 | | §1 셋째 줄 | 「문항이 늘면 새 날짜 파일로 다시 보낸다」 | 같은 파일을 다시 보낸다. 늘어난 목록과 「문장을 고친 것」은 빌드가 찍어 준다 | | §2 우선순위 2 | 「일정 Drawer 완료 카드 10건 — 아직 안 고쳤다」 | 고쳤다(11건, screen-qa-plan.md) | | §2 우선순위 3 | 「함대 개요 페이징 결함 셋 — 첫 50대만 받는다」 | 고쳤다(넷 다, wired-qa-plan.md) |

남아 있는 우선순위는 1번(P-35 답 대기)과 4번(화면층 QA)뿐입니다. 둘만 남기고 2·3 을 지우면 됩니다.

7. 영문 화면은 이제 한국어가 보인다 (키 문자열은 아니다) ✅ 끝냄(2026-08-26)

답(2026-08-26) — 영문 사이트를 이미 공유했다. 이 항목은 닫는다.

en.json 에 192개 키가 없다(한국어 708 · 영문 516. 2026-08-26 재확인). 영문 정본을 아직 못 받아서다 — 영문 도면에 그 흐름 자체가 없는 것이 대부분이다(D-55).

2026-08-26 — 되돌아갈 언어를 영어에서 한국어로 바꿨다. 전에는 영어로 보다가 없는 키를 만나면 같은 영어로 되돌아가 실패해서 equipment.detail.title 같은 키 문자열이 화면에 그대로 찍혔다. 이제 그 자리에 한국어 문구가 나온다.

영문이 섞여 보이는 것은 맞고, 키가 보이는 것은 아니다. 번역을 지어낼 수 없는 동안은 한국어가 키 문자열보다 낫다는 판단이다. 영문 정본이 오면 이 되돌림 자체가 필요 없어진다. 영문을 시연에 쓸 일이 있으면 미리 알려 달라 — 한국어가 섞여 보인다.

웹·앱 하네스가 두 브랜치에서 갈라졌다 — 합칠지 판단

답(2026-08-26) — 개발이 끝난 뒤에 합친다. 지금은 갈라 둔다.

dev/app 이 dev/JLink 보다 144커밋 뒤고 CLAUDE.md·docs/ 만 71파일이 다르다(앱 세션 실측). 서로에게 없는 규칙이 있다 — 「없다」를 증명할 때의 대조군 규칙은 웹에만, 배선을 건너뛰는 테스트를 잡는 법은 앱에만 있다.

양쪽 다 지금은 안 합친다. 오늘 밤 공유 정본(routes.html · features-status.yaml · design-qa.md)을 양쪽이 각각 고쳐 충돌이 확실하고, 무인 운전 중에 조용히 할 일이 아니다. 언제 어느 방향으로 합칠지가 사람 판정이다.

알아 둘 것 — 앱 세션의 agent 들은 작업 폴더 때문에 dev/JLink 의 CLAUDE.md 를 읽는다.

그래서 이 브랜치의 루트 CLAUDE.md 를 고치면 앱 쪽 agent 에게 즉시 적용된다.

9. 공유 부품 넷이 폭·높이를 고정하고 있다 — 고칠지 승인 판단 ✅ 끝냄(2026-08-26)

답(2026-08-26) — 공용 부품을 고쳐도 된다 — 상시 승인이다. *"디자이너의 답과 피그마가 정본"*. 앞으로 도면과 다르면 승인을 다시 안 구한다.

부품을 고치려면 확인을 받아야 한다(루트 CLAUDE.md §1). 그래서 밤에는 안 고치고 올린다.

| 부품 | 박힌 값 | 지금 어떻게 되고 있나 | |---|---|---| | 캘린더 항목 | 폭 150 | 배차 캘린더가 자식 선택자로 덮는다 | | 캘린더 이벤트 상태 | 폭 445 | 일정 Drawer 가 덮는다 | | 알림 | 폭 716 | 마이 페이지가 가로 래퍼로 감싸 줄인다 | | 사이드 내비 | 높이 680 | 셸이 height: 100% 로 덮는다 |

넷 다 화면 쪽에서 덮고 있고 근거 주석이 달려 있다. 지금 깨진 곳은 없다. 다만 부품을 쓸 때마다 화면이 덮어야 한다는 것 자체가 신호다 — 부품에서 폭을 빼면 덮는 코드 넷이 사라진다. 바꾸면 그 부품을 쓰는 모든 화면이 함께 움직인다.

10. 안 쓰이는 부품이 여섯 — 지울지 남길지 판단 ✅ 지웠다(2026-08-26)

답(2026-08-26) — 지운다. → 지웠다(a4808b4). 자산 SVG 42장도 함께 지웠다.

calendar/ 는 디렉터리째 못 지웠다 — 같은 폴더의 DispatchCalendarItem 과 EventStatus 가 쓰인다.

되살릴 때는 git 에서 꺼내면 된다. Pagination 은 디자이너가 그날 「처음·마지막 버튼을 추가했다」(D-11)고

답한 부품이라, 서버가 전체 개수를 주기 시작하면 그 답과 함께 되살린다.

DatePicker · DatePickerDate · ContentsIcon(42종) · CpcStatusCard · Pagination · WeatherCard 가 어느 화면에서도 안 쓰인다(쇼케이스 제외).

2026-08-26 — SubNavMenuItem 은 목록에서 뺐다. 사이드바의 펼침이 붙어 지금은 실제로 쓰인다(pages/main/components/sideNav/SideNav.tsx:116).

• 날짜 선택기는 곧 쓸 것 같다(배차·현장 폼)
• 콘텐츠 아이콘 42종과 날씨 카드는 서버에 값이 없어 화면이 안 만들어졌다
• 페이지 번호는 서버에 전체 개수가 없어 그릴 수가 없다 — 쓸 일이 없을 수 있다

지우면 되살릴 때 다시 만들어야 하고, 두면 다음 사람이 「쓰는 것」으로 오해한다.

쿼리 하나가 실패하면 앱 전체가 백지가 된다 — 구조를 어떻게 막을지 판단

답(2026-08-26) — 오류 화면의 디자인까지 우리가 만든다. *"에러 경계에 대해서 구현을 하는데 디자인까지 신경을 못 쓴 것 같아. 일정상 우리가 직접 구현해야 할 것 같은데 구현하고 알려주는 방식이 좋겠다."* → 지어내는 것이 아니라 만들고 나서 알린다(D-70 도 그렇게 닫는다).

전역이 throwOnError: true 인데 에러 경계가 하나도 없다. react-query 가 렌더 중에 던지므로, 화면마다 준비해 둔 isError 문구는 도달조차 못 하는 사문이었다.

급한 것은 껐다 — 관제 차량 스냅샷 셋 · 배차 상세 · 일정 Drawer · 현장 상세 · 장비 상세 둘, 2026-08-26 기준 여덟 곳이다(throwOnError: false 전수). 전부 id 를 받아 부르는 조회다 — 남이 보낸 링크를 열거나, 목록을 보는 사이 남이 옮기면 404·403 이 나는 자리다. 목록·개요 조회는 해당 없다(id 가 없어 그 실패 경로가 없다).

남은 것은 구조 판단이다. 셋 중 하나를 골라야 한다.

| 고르면 | 무엇이 달라지나 | |---|---| | 전역을 false 로 | 한 줄로 끝나고 준비된 문구가 전부 살아난다. 대신 에러 UI 를 안 짠 목록 화면들이 조용히 빈 채로 멈춘다 | | 에러 경계를 만든다 | 근본 해결이고 새 화면도 자동 보호. 대신 어디에 두느냐가 UX 사양이라 기획 확인이 필요하다(셸 하나면 한 화면이 죽을 때 옆 화면도 같이 죽는다) | | 위험한 것만 개별로(지금) | 영향 범위가 명확하고 준비된 문구를 그대로 쓴다. 대신 새 상세 화면마다 매번 기억해서 꺼야 한다 — 놓치면 같은 사고가 반복된다 |

밤에 한 것은 세 번째다. 되돌리기 쉬운 쪽을 골랐을 뿐 결정이 아니다.

#### 🔴 「그러면 실제로 어떻게 되나」를 재 봤다 — 정말 백지다 (2026-08-26 실측)

연동 QA 가 /alarms 응답만 500 으로 바꿔(스텁이다 — 서버가 500 을 준다는 말이 아니다) 대시보드를 다시 띄웠다. 재시도가 끝난 뒤 화면에 글자가 하나도 안 남았다 (document.body.innerText.length === 0) — 사이드바와 상단바까지 같이 사라졌다. 스텁을 끄고 새로고침하니 정상으로 돌아왔다.

어디가 막혔고 어디가 안 막혔는지도 셌다. throwOnError: false 는 id 로 404 가 날 수 있는 자리 10곳에만 붙어 있고, 목록 쿼리 13개(11개 파일)는 안 붙어 있다. 분기 자체는 일관된 설계다 — 개별 404 는 삼키고 목록 실패는 전역에 맡긴다. 문제는 그 「전역」이 받아 줄 경계가 없다는 것뿐이다.

제일 무거운 것은 MainLayout 이다(MainLayout.tsx:37, /users/me). 거기 쿼리가 죽으면 어느 화면에 있든 백지다. 대시보드만의 문제가 아니다.

대조군 — 에러 경계 검색은 ErrorBoundary·componentDidCatch·errorElement 전부 0건인데 같은 방식으로 fallback 은 5개 파일이 잡힌다. 검색이 죽은 게 아니다.

관제 화면이 살아 있지 않다 — 실시간을 어떻게 줄지 판단

답(2026-08-26) — 서버에 물을 질문을 만든다. → B-42 로 올렸다.

「줄 수 있나요」로 묻지 않았다 — 스트림은 이미 서버에 있고 붙일 수 있게 준비돼 있다.

저희가 못 정하는 둘만 물었다: ① 스트림 토큰이 15분마다 만료되는데 어떻게 갱신하나

② 재연결 때 스냅샷을 주시나(안 주시면 재동기화 주기를 저희가 정해야 한다).

refetchInterval 이 저장소 전체에 0건이고 setInterval 도 0건이다(useQuery 57건이 대조군. 2026-08-26 재확인). 관제에 들어온 순간의 스냅샷이 그대로 굳어 있다 — 차가 움직여도, 알람이 떠도, 배차가 시작·완료돼도 사용자가 새로고침하거나 화면을 벗어났다 돌아오기 전까지 아무것도 안 바뀐다.

「몇 초 지연」이 아니라 「화면이 아예 안 움직인다」이다.

서버에는 스트림이 이미 있다. 그리고 붙일 수 있게 준비돼 있다 — EventSource 가 헤더를 못 붙이는 것을 알고 쿼리 파라미터 인증을 받게 해 뒀고, 배포 쪽 프록시에도 스트림 전용 설정이 이미 들어가 있다. 채널은 셋 — 위치·알람·배차 전이. 위치에는 1초 간격 궤적이 실려 온다.

| 고르면 | 무엇이 달라지나 | |---|---| | 주기 새로고침 | 한 줄이면 된다. 대신 주기 사이의 변화가 소실된다 — 알람이 떴다 꺼지면 아무도 못 본다 | | 스트림을 붙인다 | 화면이 실제로 살아난다. 대신 토큰이 15분마다 만료돼 연결을 다시 만들어야 하고, 이건 지금 자동 갱신 경로 밖이다 | | 지금 그대로 | 사용자가 직접 새로고침한다 |

붙이기로 정하면 조사부터 다시 하지 않아도 된다 — 서버가 무엇을 주고 무엇에 물리는지를 03_screens/ref/sse-stream.md 에 적어 뒀다(경로·인증·채널·끊김·재동기화·정리).

스트림을 붙여도 요청은 없어지지 않는다. 서버가 재연결 때 스냅샷을 다시 주지 않고, 느린 화면에는 이벤트를 조용히 버린다 — 이벤트만 쌓아 화면을 만들면 안 되고 주기적인 재동기화가 반드시 함께 있어야 한다는 것이 서버 쪽 전제다.

13. 한글이 어절 중간에서 갈린다 — 전역 규칙을 넣을지 판단 ✅ 넣었다(2026-08-26)

답(2026-08-26) — 전역 규칙을 넣는다. → 넣었다(a4808b4).

:where(html) { word-break: keep-all } — 상속되는 속성이라 뿌리 하나로 닿고,

:where 는 특정도 0 이라 부품이 필요하면 그냥 덮어쓴다. 화면에서 확인했다(html·body·자식 전부 keep-all).

아래 「전역 스타일 파일이 아예 없다」는 틀린 말이었다 — app/css/global.css 가 342줄 있었다.

word-break: keep-all 이 저장소 전체에 0건이다(*.css.ts 57개 대조군). 브라우저 기본값은 한글을 글자 사이 아무 데서나 끊는다 — 그래서 좁은 칸에서 「마모 상 / 태가」처럼 한 단어가 두 줄로 갈린다.

앱 세션이 골든 캡처에서 실제로 잡았고, 웹도 같은 자리다.

타입체크도 린트도 못 잡는다. 문구가 짧으면 안 나다가 번역이나 문구 교체로 한 글자만 길어져도 나타난다. 카드 제목·표 셀·툴팁처럼 폭이 좁은 자리가 위험하다.

반대 방향 설정은 이미 열세 곳에 있다 — overflow-wrap: anywhere/break-word(2026-08-26 재확인). 그건 더 끊는 쪽이라 헷갈리면 안 된다. 둘은 같이 쓸 수 있다 — keep-all 이 한글 단어를 지키고, overflow-wrap 이 끊을 데가 없는 긴 한 덩어리 (일련번호·메일주소)를 넘치지 않게 한다.

밤에 안 넣었다. 이유가 둘이다.

• 전역 스타일 파일이 아예 없다 — 리셋도 body 규칙도 없어서 넣으려면 새로 만들어야 한다
• 모든 화면의 줄바꿈이 바뀐다. 화면층 QA 는 밤에 안 도는데, 눈으로 안 보면 안 보이는 종류의 변경이라 확인 없이 넣으면 아침에 무엇이 달라졌는지 아무도 모른다

아침 화면층 QA 와 같은 회차에 넣는 것이 맞다 — 넣고 바로 눈으로 보는 것이다.

15. 운전자 계정이 하나도 없다 — 초대 1건이 필요하다 ✅ 안 하셔도 됩니다 (2026-08-26)

운전자는 이미 있습니다. 스무 명 넘게 있습니다.

서버를 직접 떠 보니 조직 넷에 걸쳐 계정이 26개고 그중 운전자가 스무 명이 넘습니다. 화면에 0명으로 보인 것은 저희가 조직을 지정하지 않고 물었기 때문입니다 — 현장 목록이 비는 것과 똑같은 자리입니다.

그래서 초대 메일을 보내실 필요가 없습니다. 아래 셋은 P-35 답이 오면 한 번에 열립니다.

• 장비 상세의 담당 운전자
• 일정 드로어 카드의 운전자
• 인원 목록의 운전자 탭

이 항목이 왜 여기 있었는지는 남겨 둡니다 — 「데이터가 없다」와 「있는데 안 부른다」가 화면에서는 똑같이 보입니다. 서버를 직접 떠 보고서야 갈렸습니다.

장비 사진 업로드 — 파일 선택기만 눌러 주면 된다 (30초)

답(2026-08-26) — 내일 한다.

agent 가 OS 파일 선택기를 못 연다. DataTransfer 주입도 브라우저가 거부해서 (input.files 가 0 으로 되돌아간다) 크롭 모달까지 못 간다. 자동화로는 이 한 자리가 막힌다.

그래서 사람 손이 한 번 필요하다. 장비 JKF-B-06 상세 → 사진 변경 → 아무 jpg/png 하나만 고르면 그 뒤는 agent 가 이어서 3단계 경로를 검증한다 (presign → S3 직접 PUT → PUT /kits/{s}/photo).

되돌릴 수 있다 — 서버에 킷 사진 삭제 경로가 있고(kit/router.py:13) JKF-B-06 은 지금 사진이 없어서 원래 상태가 「없음」이다. 검증 뒤 지우면 그대로 돌아간다.

안 해도 된다. 그러면 사진 업로드 경로는 영영 검증 안 된 채로 남는다 — 그것이 유일한 값이다.

2-b. 백엔드 저장소 접근 권한

https://github.com/motrex-cto/jlink-server 를 agent 가 클론하려 했으나 막혔다 — HTTPS 는 Repository not found, SSH 는 Permission denied. 2026-08-26 에 사용자가 직접 받아 뒀다 (Web/jlink-server, HEAD e44ed81). 내가 떠 두었던 사본과 app/ 차이는 0 이었다.

agent 계정으로는 여전히 git 접근이 안 된다 — 다음에 최신을 받아야 할 때도 사용자가 해야 한다.

5. 밤 운전이 도는 동안 터미널을 닫지 않기

cron 이 세션 메모리에만 살아서 창을 닫으면 밤 운전이 통째로 멈췄다. 2026-08-26 에 사용자가 크론을 껐다 — 이제 자동으로 도는 것이 없으므로 창을 닫아도 된다. 다시 밤 운전을 걸면 이 제약이 그대로 돌아온다.