HMDesign/AGENTS.md

HMDesignSystem 작업 지침

AI 화면 구현 Quick Start

화면 구현 요청을 받으면 아래 순서를 그대로 따른다. 파일이나 API의 존재를 확인할 수 없으면 추측하지 말고 미확인으로 기록한다.

1. 프로젝트 구조와 Runtime 확인: 제공된 파일 범위를 살펴보고 REACT_VITE | STATIC_HTML | VANILLA_WEB | OTHER_RUNTIME 중 대상을 정한다. Component·Pattern 파일이 실제 범위에 있는지 확인한다.
2. Component 검색: packages/ui/src/components/ui/와 packages/ui/src/index.ts에서 공개 Component·Props를 찾고, docs/components/<component>.md를 확인한다. 기존 공개 Component를 우선 사용한다.
3. Pattern 검색: packages/ui/src/patterns/, src/patterns/, packages/ui/src/index.ts와 docs/patterns/에서 맞는 Pattern·공개 API를 찾아 구조와 상태 규칙을 따른다.
4. Storybook 확인: src/components/, src/patterns/, src/theme/의 대표 All Story와 관련 문서를 확인한다. verification 전용 Story는 일반 화면의 기준으로 쓰지 않는다. Storybook을 실행할 수 없으면 Story 소스와 문서만 확인하고 시각 동작은 추측하지 않는다.
5. Theme 연결: themes/default.json, packages/ui/src/theme.css, Runtime 계약과 Token 가이드를 확인해 기존 CSS Custom Properties 구조를 사용한다.
6. 화면 구성: Component와 Pattern을 조합하고 아래 단일 Navigation 정책을 지킨다. 기존 구성으로 해결되지 않을 때만 새 Component를 검토한다.
7. 결과 확인 및 보고: 실제 적용한 Component·Pattern, Theme 연결, Navigation Mode, 실행/화면 확인 결과와 미검증 항목을 보고한다.

Storybook / 화면 생성 분리: Storybook은 기존 Component·Pattern·Theme·Variant·State·Interaction을 확인하는 Reference 환경이다. 일반 업무 화면 생성은 Storybook Story·사이드바에 등록하지 않고, 기존 대표 Story를 생성 화면으로 교체하지 않으며, Storybook 실행을 필수 확인 경로로 요구하지 않는다. 별도의 React 화면과 독립 미리보기를 만들고 화면별 빌드·필요한 검증을 수행한다. H-2(AI 생성 화면의 자동 빌드·캡처·검증, Storybook 배포와 별도이며 구현 완료 여부는 현재 파일로 확인)나 유사 자동화가 사용 가능한 경우에도 preview.html·desktop/mobile 이미지 같은 독립 미리보기 산출에만 사용하며 Storybook 등록과 혼동하지 않는다. Storybook 수정은 Component/Pattern 추가·수정, 대표/Verification Story 작성 또는 Storybook Reference 개선을 사용자가 명시한 경우에만 허용한다. Storybook 전용 helper/CSS는 운영 화면에 사용하지 않는다.

상세 규칙은 이 문서의 구현 기본값, Runtime 계약, 단일 Navigation 정책과 Component / Pattern Reference Index, Component 구현 원칙, Runtime Theme, Navigation 정책을 따른다.

검색 원칙(도구 중립): 변경과 관련된 소스 경로부터 좁혀 검색하고, 생성물(node_modules, dist, storybook-static)과 로컬 작업본은 기본 제외한다. 필요한 최소 범위만 검증하며 실제로 확인하지 않은 기능을 PASS로 보고하지 않는다. 존재하지 않는 Component·Pattern·공개 API를 임의로 만들지 않고 없으면 없다고 보고한다.

Story 구분: 운영 기준은 대표 All Story이고 verification·Compatibility·Fixture Story는 운영 예제가 아니다. Storybook 문서 화면은 StoryPage 공통 Inner를 사용하며, 이는 Storybook 표현용으로 @hm-design/ui 공개 API가 아니다.

화면 생성 시 필수 확인: Navigation을 지정받으면 우선 적용하고, 미지정이면 화면 구조·대표 Pattern에서 선택 근거를 기록한다(선택 기준). GNB는 Desktop 메뉴와 GNBMobileMenu를 함께 구성하며 내부 Sidebar도 모바일 Sheet 하나만 사용한다(GNB 모바일). Dashboard 운영 화면에는 Sidebar를 생성하지 않는다. DashboardSidebar 공개 Export와 선택적 sidebar slot은 기존 호환성·검증용이며 운영 허용을 뜻하지 않는다. Dashboard 상태는 Theme 다음에 공개 Status CSS를 로드하고 기존 Badge mapping을 소비한다(상태 예제). FilterBar의 입력 조건과 조회 적용 조건·초기화 책임을 구분한다(조회 예제). REACT_VITE 독립 화면은 bootstrap에서 기존 앱 CSS entry(@/index.css → @/hm-theme.css → 필요 시 공개 상태 CSS)를 로드하며, @hm-design/ui/tailwind.css만 단독 import하지 않는다. 빌드 후 .flex, .grid 등 대표 utility의 생성·실제 적용과 캡처 레이아웃을 확인하고, 빌드 성공만으로 화면 검증을 PASS 처리하지 않는다. React 소비자는 Tailwind 검색 범위와 HM package source를 확인하고(Tailwind), 폰트·Asset 경로는 실행 위치별로 확인한다(Asset).

AI Implementation Defaults

사용자가 별도로 "기존 컴포넌트/디자인 시스템을 사용해줘", "테마를 적용해줘", "Semantic Token을 사용해줘", "Navigation 정책을 따라줘"라고 요청하지 않아도 AI는 이를 모든 신규·수정 UI의 기본 구현 조건으로 자동 적용한다.

• 구현 전에 STORYBOOK_ONLY | PRODUCTION_UI | BOTH 중 변경 범위를 정한다.
• 기존 Component와 유사 대표 Story를 먼저 검색한다. packages/ui, src/components, src/patterns, src/center, 기존 Storybook stories와 shared helpers를 확인하고 도메인에 맞는 구현을 재사용한다.
• 재사용 순서: 기존 HM Component → 기존 Variant / Prop → 기존 Composition → shadcn → Radix Primitive → 최소 Custom. 새 Component는 기존 Component·Composition으로 표현 불가능하고 Variant 확장이 부적절하며 shadcn/Radix 조합도 어려운 경우에만 만든다. 재사용 불가 사유와 최소 추가 범위를 설명한다.
• Storybook은 구현 Reference Catalog다. 대표/PRIMARY Story의 시각 언어와 공통 상태 mapping을 재사용하고 검증 전용 Story를 운영 예제로 삼지 않는다. 신규 업무 화면의 등록 대상이 아니며, 생성 결과는 별도 React 화면·독립 미리보기로 제공한다.
• Theme은 구현 시작부터 적용한다. 기존 Semantic Token → 해당 Component Token → 기존 CSS Variable을 먼저 확인하고, 없을 때만 필요한 최소 Semantic 확장을 검토한다. 기존 Token이 있는 색상·spacing·값을 하드코딩하거나 같은 Token을 여러 파일에 중복 정의하지 않는다.
• Theme 사용은 별도 승인 없이 기본 적용한다. Theme Source/값 수정은 명시적 필요성과 영향 범위를 확인한다. themes/*.json → Runtime Loader → CSS Custom Properties → Semantic → Component Mapping과 Primary / On Accent의 독립 fallback을 유지한다.
• 한 페이지에 GNB | LNB | DASHBOARD 중 하나만 사용한다. 반응형도 같은 Navigation Mode를 유지한다.
• 화면 구현 순서는 Quick Start를 따른다. 변경 작업 범위(STORYBOOK_ONLY | PRODUCTION_UI | BOTH)는 구현 전에 정한다.
• package exports, public props/types, package entry, Story ID, meta.title을 불필요하게 변경하지 않는다. 필요한 변경은 소비처·호환성 영향을 먼저 확인한다. Storybook 표현 문제와 Production 동작 문제는 해당 범위에서 해결한다.
• Badge/Button/FilterBar를 재사용하더라도 동일한 상태 ID·라벨·필터 매칭이 반복되면 화면별 helper로 남기지 말고 Runtime-neutral 상태 계약을 먼저 검토한다. 계약은 React 구현과 분리하고 data-status, 독립 flag attribute, aria-pressed 등 다른 Runtime이 재현할 수 있는 상태 vocabulary를 정의한다.
• 명시적 실험·Theme 미적용 prototype·외부 디자인 완전 재현·독립 POC만 별도 격리 범위에서 예외를 검토한다. Navigation 혼합은 아래 단일 모드 정책의 별도 기준을 따른다.
• Button은 brand | solid | outline의 사용 위치와 세트 규칙을 docs/components/button.md 기준으로 따른다: 실제 화면 Brand 최대 1개·팝업 Brand 금지, 일반 확인/작성은 Solid 세트, 삭제 확인·행/반복 작업은 Outline 세트이며 세트의 appearance와 size를 통일한다. Runtime 변환은 docs/guidelines/runtime-portability.md의 DOM/Theme/keyboard 계약을 함께 보존한다.
• Dashboard 운영 화면은 전용 Header(48px)·업무 상태 필터와 Content로 구성하며 Sidebar 사용을 금지한다. Dashboard 대표 Patterns/Layout/Dashboard → Dashboard Story와 docs/patterns/dashboard-layout.md를 기준으로 하며, Header를 GNB로 대체하거나 일반 LNB/GNB를 함께 넣지 않는다. Sidebar verification Story는 신규 운영 화면의 Reference가 아니다.
• Dashboard 및 DataTable은 기존 Pattern 구조를 우선한다. Data Table 대표 Story를 기준으로 하고 숨김 With Filter Bar는 verification 용도다.
• Story의 fixture나 장식은 Component API나 Production 규칙과 구분한다. 대표 Story와 공개 API·사용 문서를 함께 확인한다.

상세 Source of Truth: AI/Component 구현 원칙, Theme/Token 정책, Runtime Theme 계약. 이 기본 정책은 과거 문서·예제의 상충 지침보다 우선한다.

Runtime Portability Policy

• 설치 없는 테스트 배포의 현재 검증 기준은 HMDesignTest-Portable-Test-r3.zip이다(r2·원본 HMDesignTest-Portable-Test.zip은 과거 기록). 포터블 ZIP은 기본 포트 6007이며 충돌 시 자동으로 다른 포트를 쓰고, 개발 저장소 Storybook은 6024다. 이 ZIP은 start-preview.bat과 동봉된 Windows x64 Node 런타임으로 사전 빌드된 Storybook을 실행한다. 테스트 사용자는 ZIP 해제 → 배치 더블클릭 → 표시된 로컬 URL 열기만 수행하며 Node/npm 설치, npm 명령, Git 작업, CDN/운영 업로드가 필요 없다. 아래 의존성 복원·빌드 절차는 소스 개발자 전용이다. 테스트 배포 안내.
• Runtime 구분: React 화면은 실제 packages/ui 공개 API와 workspace를 쓰는 REACT_VITE; 압축 ZIP에서 React 개발환경을 쓸 때는 먼저 npm ci로 의존성을 복원한다. STATIC_HTML은 파일을 file://로 직접 여는 HTML이며 Vite나 bare package import에 의존하지 않는다. VANILLA_WEB은 서버/정적 호스팅의 HTML·CSS·JS다. Storybook은 구현 기준을 확인하는 Reference 환경이며 Production Runtime을 뜻하지 않는다.
• HMDesignTest.zip에는 .storybook/ 설정·Story 소스·패키지 소스와 dist가 있지만 node_modules/, storybook-static/은 없다. 실제 포함 파일과 package.json scripts를 먼저 확인한다. HMDesignTest.zip의 Storybook 개발 서버는 기본 포트 6007이며(현재 개발 저장소는 6024) 정적 빌드가 필요하면 의존성을 복원한 뒤 npm run build-storybook을 실행한다. 현재 개발 저장소와 ZIP의 설정 차이가 있으면 대상 package.json을 다시 확인한다. 생성되기 전의 storybook-static/을 필수 Reference로 요구하지 않는다.
• React는 구현 방식 중 하나일 뿐이다. 신규·변환 작업은 먼저 REACT_VITE | STATIC_HTML | VANILLA_WEB | OTHER_RUNTIME 중 Target Runtime을 정하고, HM Design/Theme/Component Contract를 유지한다.
• themes/default.json, packages/ui/src/theme/contract.ts, packages/ui/src/theme/runtime.ts, packages/ui/src/theme.css와 Runtime 계약표를 실제 Source of Truth로 사용한다. 색상·spacing·radius·Typography를 추측하거나 하드코딩하지 않는다.
• HTML/다른 Runtime 결과물은 기존 React를 대체하거나 별도 디자인으로 재작성하지 않고, 동일한 시각·상태·접근성·responsive 계약을 소비하는 adapter로 만든다. STATIC_HTML은 file:// 직접 실행 검증을 포함한다.
• Dashboard 상태 색상은 src/patterns/dashboard-status-contract.css의 Runtime-neutral 변수(--hm-dashboard-status-active|hold|done|issue)를 우선 사용한다. 이 파일의 active/hold/issue 값은 기존 승인된 Story 색상을 보존하는 compatibility mapping이며 Public Theme token으로 승격하지 않는다. 실제 Production 공통 소비가 확인될 때만 Semantic Token 승격을 제안한다.
• 상세한 Target Runtime, asset 경로, 변환 규칙과 검증 기준은 Runtime Portability Policy를 따른다.

Navigation Single Mode Policy

ONE PAGE = ONE NAVIGATION MODE = ONE HEADER/NAVIGATION EXPERIENCE

• 페이지 구현 전에 navigationMode = GNB | LNB | DASHBOARD 중 정확히 하나를 선택한다.
• 허용: GNB ONLY, LNB ONLY, DASHBOARD ONLY.
• GNB ONLY 내부 Sidebar는 기존 LNB 부품을 재사용하는 허용 Composition이며 독립 LNB Mode가 아니다. 브랜드·사용자와 모바일 Header/Sheet는 GNB 하나가 담당한다(상세 범위).
• 금지: GNB + LNB, GNB + Dashboard, LNB + Dashboard, GNB + LNB + Dashboard.
• 이 정책은 AI 기반 코드 생성·제안, 신규 페이지 구현, 기존 화면 수정, 프로토타입, Storybook, 실제 Production 구현 전체에 동일하게 적용한다.
• AI는 별도 요청이 없는 한 Navigation 조합을 생성하거나 제안하지 않는다. 별도 요청이 있더라도 기존 단일 모드 정책과 충돌함을 알리고 정책 변경인지 기술 검증인지 구분한다.
• 반응형에서도 선택한 체계를 유지한다. LNB Desktop(≥1024px) → LNB Mobile Header(≤1023px)는 같은 LNB Mode이며 GNB로 전환하지 않는다.
• Dashboard 운영 화면은 전용 Header/Menu와 Content만 사용하며 Sidebar는 금지한다. 외부 GNB나 일반 LNB를 slot에 넣지 않는다. 기존 DashboardSidebar와 sidebar slot은 호환성·검증용으로 유지하며 신규 운영 화면에 사용하지 않는다.
• Dashboard Header는 GNB가 아니다. Dashboard 화면은 Dashboard Pattern과 대표 Story를 따르고, Header의 역할을 GNB로 대체하지 않는다.
• GNB/LNB/Dashboard의 함께 쓰기는 위 단일 모드 허용 범위만 따른다. 과거 혼합 Navigation verification Story는 운영 화면 기준으로 사용하지 않는다.
• Dashboard 운영 최소 폭은 Sidebar 없는 960px이며 그 이하에서는 Dashboard 내부 가로 스크롤을 유지한다. Sidebar 포함 1232px은 기존 호환성·검증 구성의 값으로 현재 운영 기준이 아니다.
• Navigation 간 CSS 변수, height/width 계산, breakpoint, spacing override의 교차 의존성을 추가하지 않는다.
• 대표/PRIMARY Story는 단일 모드만 사용한다. 기존 혼합 Story를 기술 검증 목적으로 유지할 경우 verification 태그와 VERIFICATION ONLY 표시를 모두 적용하고 운영 예제로 추천하지 않는다.

상세 기준: Navigation Single Mode Policy. 이 사용자 확정 정책은 이전 Navigation 조합 문서·예제보다 우선한다.