Imported from jbk9572-law/Osungtech-erp (AGENTS.md). Install upstream with npx skills add jbk9572-law/Osungtech-erp. Copyright stays with the author.

This is NOT the Next.js you know

This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in node_modules/next/dist/docs/ (resolved from this file's directory; in monorepos the next package may not be visible from the repo root) before writing any code. Heed deprecation notices.

This block is written and re-added by next dev — verify at node_modules/next/dist/server/lib/generate-agent-files.js. Removing it from a diff only re-creates the uncommitted change; committing it with your work keeps the tree clean.

버그 수정 시 반드시 지킬 규칙 (모든 세션에 적용, 정기 감사 세션 포함)

한 곳의 버그를 고칠 때, 같은 패턴이 다른 곳에도 있는지 확인하지 않고 그 지점만 좁게 고치면, 사용자가 나중에 다른 위치에서 같은 버그를 또 발견해 같은 지시를 반복하게 되고 이는 토큰 낭비다. 그래서 다음을 예외 없이 지킨다:

1. 패턴 기반 버그를 찾으면, 고치기 전에 먼저 코드베이스 전체에서 같은 패턴을 검색한다 (Grep으로 유사 구조 검색, 또는 같은 컴포넌트/헬퍼를 쓰는 다른 호출부 확인). 찾은 인스턴스를 전부 한 번에 고친다 — 지적받은 한 곳만 고치고 끝내지 않는다.
2. 가능하면 반복될 수 있는 구조 자체를 없앤다: 똑같은 로직/스타일이 2곳 이상에 복붙돼 있으면 공용 함수·훅·CSS 클래스로 합친다(예: clampDropdownLeft, sumOutstandingBalance, .erp-kpi-row).
3. 사람이 매번 다시 찾아야 하는 종류의 버그라면 자동 검사 스크립트로 만든다: scripts/check-*.mjs를 새로 추가하거나 확장해서 npm run lint에 물린다(기존 예: check-pagination.mjs, check-mutation- errors.mjs, check-search-autocomplete.mjs). 스크립트를 만든 뒤에는 반드시 직접 실행해서 수동으로 놓친 인스턴스가 없는지 확인한다 — 실제로 이 방식이 손으로 다 고쳤다고 생각한 뒤에도 누락분을 잡아낸 전례가 있다.
4. 위 세 가지 중 어느 것도 적용할 수 없는 진짜 일회성 버그라면 그냥 그 자리에서 고치면 된다 — 모든 수정에 억지로 공용화/자동검사를 끼워 넣으라는 뜻은 아니다. 판단 기준은 "같은 실수가 다른 곳에서 반복될 수 있는가"이다.

절대 규칙(헌법) — 모든 세션에 예외 없이 적용

이 네 가지는 사용자가 "헌법"이라고 명시적으로 지정한 규칙이다. 정기 감사 세션을 포함해 이 저장소에서 작업하는 모든 세션이 예외 없이 지킨다.

1. 병합(main)·배포는 사용자가 그 대화에서 "배포해"라고 명시적으로 말하기 전까지 절대 하지 않는다. 넷리파이 크레딧이 한정돼 있어 배포 한 번마다 비용이 든다 — 정기 감사 세션도 예외 없이 이 규칙을 지킨다. 아무리 수정이 사소하거나 "이 정도는 바로 배포해도 될 것 같아도" 절대 먼저 병합/배포하지 않는다. claude/nextjs-supabase- erp-init-f51i5x 브랜치에 커밋+푸시까지만 하고 멈춘다.
2. 뭔가를 수정했으면 항상 수정 전/후(비포/애프터) 목업(스크린샷 등 시각적 증거)을 사용자에게 보여준다. UI가 바뀌는 수정이든, 화면에 드러나는 계산 결과가 바뀌는 수정이든 마찬가지다 — 코드만 보고 "고쳤습니다"라고 말로 끝내지 않는다. 실제 CSS/컴포넌트로 렌더링해 Before/After를 나란히 보여주는 방식(이 세션에서 계속 써온 Playwright 스크린샷 검증 방식)을 계속 쓴다.
3. 같은 종류의 화면/UI 패턴을 한 곳에서 고치거나 새로 도입하면, 그 요청에서 이름이 언급되지 않은 다른 화면이라도 같은 패턴을 쓰는 곳인지 반드시 먼저 확인하고 전부 같이 통일한다. (예: 매출/매입 목록의 조회기간 필터 UI를 바꾸면서 재고관리 > 입출고내역처럼 같은 getDatePresets/프리셋 줄 패턴을 쓰는 화면을 빼놓고 넘어갔다가 "이런걸 공용화해서 같이 고쳤어야지, 이러니 시스템이 꼬이잖아"라는 지적을 받은 전례가 있다.) 구체적으로:
   • 수정 전에 같은 컴포넌트/훅/헬퍼 함수를 쓰는 다른 호출부가 있는지 Grep으로 검색한다(버그 수정 규칙 1번과 동일한 검색 습관을, 버그가 아니라 기능 변경/리팩터에도 그대로 적용).
   • 사용자가 특정 화면(예: 매출/매입)만 콕 집어 요청했더라도, 같은 종류의 UI/로직이 다른 화면에도 있으면 "요청받은 화면만" 고치고 끝내지 말고 같이 통일할지 먼저 판단한다 — 애매하면 나중에 되묻지 말고 통일하는 쪽으로 진행하고 결과 보고에 "이 화면도 같이 통일했습니다"라고 명시한다.
   • 이미 공용 컴포넌트/훅이 있는데 특정 화면만 그걸 안 쓰고 자기 스타일로 따로 마크업을 들고 있다면(예: 목록 페이지는 공용 DateRangeQuickFilters를 쓰는데 상세 페이지는 똑같은 프리셋 줄을 직접 인라인으로 그리고 있는 경우), 그 화면도 공용 컴포넌트를 쓰게 바꾼다 — "일단 이 화면은 그대로 둬도 되겠지"라고 판단해서 넘어가지 않는다.
4. UI/레이아웃을 만들거나 고칠 때는 정기 감사 때만이 아니라 매번 모바일 환경을 확인한다. 데스크톱 화면에서만 확인하고 "화면 깨짐 없음"이라고 보고한 뒤 나중에 좁은 화면에서 깨져 보이는 걸 따로 또 지적받는 식으로 반복되지 않게 한다. 구체적으로:
   • 새 화면/컴포넌트를 추가하거나 기존 레이아웃(그리드, 표, 버튼 줄, 모달, 카드 등)을 수정했으면, Before/After 스크린샷(헌법 2번)을 데스크톱 뷰포트 하나로만 찍고 끝내지 않는다 — 좁은 화면 (모바일 폭, 대략 375~430px)에서도 최소 한 장을 같이 찍어서 overflow/clipping, 터치 타겟 크기, 줄바꿈이 깨지지 않는지 직접 확인한다.
   • 표/그리드처럼 원래 가로로 넓은 요소는 좁은 화면에서 전체 레이아웃이 깨지는 대신 그 요소만 가로 스크롤되는지, 또는 의도한 방식으로 반응형 처리가 되는지 확인한다.
   • 이 확인은 정기 "헌법검사"의 2번 항목(모바일 환경성 검사)과 같은 기준이지만, 거기서 그치지 않고 그 자리에서 하는 모든 UI 작업에 바로 적용한다 — 정기 감사가 나중에 잡아줄 거라고 미루지 않는다.

정기 "헌법검사" — 매일 오후 18:30 자동 실행 + "헌법검사 진행해" 즉시 실행

사용자가 대화 중에 "헌법검사 진행해"라고 말하면, 아래 체크리스트를 그 자리에서 바로 시작한다(되묻지 않는다). 이 체크리스트는 또한 매일 한국 시간 오후 18:30에 자동으로 실행되는 정기 세션의 내용이기도 하다:

1. 전체 버그 체크 — 코드 첫 줄부터 마지막 줄까지, 영역별로 나눠 병렬 서브에이전트로 읽기 전용 감사 (git log를 참고해 이미 고친 건 재보고하지 않도록 지시)
2. 모바일 환경성 검사 — 반응형 레이아웃, 터치 타겟, 좁은 화면 overflow/clipping
3. 유기성 검사 — 화면 간 데이터/로직 연결이 자연스러운지(예: 이번에 지적된 재고현황↔재고실사↔입출고내역처럼 관련 화면끼리 끊겨 있지 않은지)
4. 확장성 검사 — 새 기능을 추가하기 쉬운 구조인지, 억지로 끼워 맞춘 부분은 없는지
5. 모듈화 검사 — 컴포넌트/파일 책임이 적절히 분리돼 있는지
6. 함수화 검사 — 반복되는 로직이 공용 함수/훅으로 묶여 있는지 (버그 수정 규칙의 2번과 같은 기준)
7. 일괄성(일관성) 검사 — 같은 종류의 UI/동작이 화면마다 다르게 구현돼 있지 않은지(예: 폼마다 Enter 키 동작이 제각각이던 문제)
8. 디자인 언어 검사 / CSS 검사 — erp-theme.css 기준 색상·간격· 컴포넌트 스타일이 화면마다 일관된지, 죽은 규칙/중복 선언은 없는지

진행 방식은 이 세션에서 계속 써온 방식을 그대로 따른다: 병렬 서브에이전트로 감사 → 보고받은 내용을 직접 코드에서 재검증 → 진짜 버그만 고침 → 반복 패턴은 공용 함수/자동검사 스크립트로 묶음 → tsc/ lint/test/build 전부 통과 확인 → 수정 전/후 목업 제시 → claude/ nextjs-supabase-erp-init-f51i5x에 커밋+푸시만 하고 절대 main에 병합/배포하지 않음(위 헌법 1번) → 결과를 리포트.