센서 숫자는 정의부터 맞추고,
AI 작업은 승인을 거치게 합니다.

광학필름 생산 라인의 가이드롤(동력 없이 필름 장력으로 도는 롤)에 붙은 센서 노드 4대가 10분마다 11초씩 속도·진동을 측정하고, 이를 FastAPI·React 대시보드로 보여 주는 시스템입니다. 통계 화면에 가동 1.2시간 · 가동 0회가 함께 표시되는 모순이 있었습니다. 원인은 두 지표의 판정 기준 차이였습니다. 가동 횟수는 30분 이상 이어진 구간만 세고, 가동 시간은 길이와 무관하게 합산해, 10분 가동 6회가 횟수에서는 빠지고 시간에는 1.2시간으로 들어갔습니다.

"가동 1회"의 정의를 현장과 다시 합의하고, 합산 함수를 단일화해 일간·주별·월별 화면이 같은 함수를 사용하도록 했습니다.

같은 센서 사이클 한 행이 화면 세 곳에서 세 가지 규칙으로 "가동"인지 판정됩니다. 노드 카드는 속도가 0만 아니면 가동, 기간 통계는 모든 노드가 함께 1 MPM 이상으로 돌아야 가동, 공정 분류는 0~1 MPM을 판정 보류로 둡니다. 어느 쪽이 현장의 "가동"인지는 생산 라벨이 없어 아직 정하지 않았습니다.

기획자가 명령어 한 줄로 상세기획 산출물을 만들고, 승인된 기획만 개발 저장소 이슈·PR로 넘기는 Claude Code 플러그인입니다. 프롬프트마다 결과가 달라지는 문제를 고정된 스킬 8개와 가드레일로 묶었고, GitHub에 쓰는 작업은 dry-run과 사람 승인을 거치게 했습니다.

제조 현장에 맞춰 바꾸면 같은 구조가 "원인 확인 → 수정안 → 승인 → 배포 → 보고"가 됩니다. evol 작업에서도 이 순서를 스킬로 만들어 씁니다.

사용자가 확인한 회의 텍스트 한 덩어리가 인증 → 입력·사용량 검사 → 프롬프트 조립 → 모델 호출 → 저장 순서로 처리됩니다. 모델은 Workers AI를 먼저 부르고, 실패하면 Gemini로 넘어갑니다. 둘 다 실패하면 저장 전에 멈추므로 회의록도 사용량 기록도 생기지 않습니다.

허구 센서 사이클 30건(노드 4개 · 속도 · 진동) 위에서 공정 판단 → 원인 추적 → 행동 제안 → 사람 승인 → 모의 명령을 한 화면에 구현한 샘플입니다. 메일 승인 에이전트(Javis)가 "초안은 사람이 승인해야만 저장된다"를 지키던 승인 구조를 제조 데이터로 옮겼습니다. Monitor는 결정대장 규칙 2개만 쓰고(LLM 없음), Root Cause는 Tool로 앞 5사이클을 거슬러 시작 노드·사이클·이벤트를 ID로 찍습니다. 행동 제안은 승인 8조건을 통과해야만 모의 명령 1회가 되고, 자동으로 넘어가는 전이는 0개입니다.