HMDesign/docs/org-chart/ai-page-generation-rules.md

HMDesign — AI 조직도 페이지 자동 생성 공통 정책

적용 대상은 Codex·Claude 등 AI 코딩 에이전트가 자연어 또는 제공 데이터에서 새로 생성하는 삽입용 조직도 컴포넌트 또는 조직도 전체 페이지다. 회사, 조직 유형, 계층, Depth, 인원수에 종속되지 않는다. 고정형(Fixed)과 확장형(Auto/Expanded) 모두 동일한 생성 방식 선택 원칙을 적용한다. 기존 Full Composition·Expanded OrgChart·Department Colors·Overview의 승인된 화면은 변경하지 않으며, 기존 P9.5·P-AI1 결과에도 소급 적용하지 않는다.

1. 실행 방식과 적용 우선순위

• 사용자가 코딩 에이전트에 요청을 전달하면 에이전트가 조직 JSON과 실제 페이지 코드를 생성한다. 웹페이지에 AI 채팅창이나 생성 입력 UI를 추가하지 않는다. 브라우저 AI Provider 연결은 이 실행 방식의 전제가 아니다.
• 사용자 요청에서 명시한 UI 요구사항 → 이 정책의 AI 조직도 전용 범위 → 기존 OrgChart Core의 디자인·동작 규칙 순으로 적용한다. 충돌하지 않는 AGENTS.md·CLAUDE.md와 HM 공개 계약·데이터 검증·접근성 규칙은 계속 준수한다. 관련 문서는 필요한 부분만 읽는다.
• 생성 방식은 아래 사전 선택 절차로 확정한다. 미지정 요청을 Chart Only 또는 Full Page로 임의 결정하지 않는다. Chart Only에는 일반 업무 화면의 GNB/LNB/DASHBOARD Navigation 의무를 가져와 메뉴나 Header를 추가하지 않는다. Full Page의 요청 UI·Navigation은 기존 HM 화면 계약을 따른다.
• 기존 Core·React Wrapper·Theme·카드·Storybook을 요청 없이 변경하지 않는다. 필요한 공통 변경은 사유와 영향 범위를 먼저 보고한다. 새 조직도 엔진이나 디자인 시스템은 만들지 않는다.

1.1 생성 방식 사전 선택

Codex·Claude가 조직도 생성 요청을 받았을 때 생성 방식이 명시되지 않았다면 코드 작성 전에 다음 질문을 먼저 하고, 사용자의 답변을 받은 뒤 구현한다. 이 질문은 에이전트 대화에서 하며 웹페이지에 생성 방식 선택 UI를 추가하지 않는다.

조직도만 기존 페이지에 삽입할까요, 아니면 레이아웃까지 구성한 새 페이지 전체를 생성할까요?

① 조직도만 생성 (Chart Only)

• 기존 페이지에 삽입 가능한 독립 조직도 컴포넌트를 생성한다.
• 흰색 캔버스 및 조직도 노드·연결선만 표시한다.
• 최초 Fit to View, 마우스 휠 확대·축소 및 Pan을 적용한다.
• 외부 제목·통계·설명·조작 패널을 생성하지 않는다. 상세 구성은 §6의 Chart Only 규칙을 따른다.

② 새 페이지 전체 생성 (Full Page)

• 새로운 페이지의 레이아웃까지 설계하고 화면 전체의 배치 및 반응형 구성을 구현한다.
• 기존 HMDesign UI 컴포넌트를 우선 재사용한다.
• 사용자가 요청한 제목·정보·필터·컨트롤 등을 반영한다. 선택 자체를 요청하지 않은 부가 기능의 승인으로 확대하지 않는다.
• 기존 OrgChart Core·React Wrapper로 조직도를 표시한다. 상세 구성은 §6.4를 따른다.

사용자가 이미 생성 방식을 명시했다면 같은 선택 질문을 다시 하지 않고 해당 방식으로 바로 구현한다. 두 방식 모두 사용자 요청의 조직 구조·인원수·데이터를 정확히 반영하고 기존 OrgChart 컴포넌트를 재사용한다. Fixed·Auto/Expanded는 조직도 배치 모드이며 Chart Only·Full Page 선택을 대신하지 않는다.

이미 Chart Only로 확정되어 진행 중인 구현에는 이 선택 절차를 다시 적용하거나 Full Page로 확대하지 않는다. 생성 방식 사전 선택 정책을 작성한 작업은 정책·참조 안내만 다뤘으며 진행 중인 구현·기존 Storybook 4개 화면은 수정하지 않았다. 별도로 승인된 2026-10-13 Feature 통합 범위와 결과는 최종 Feature 통합 보고서를 따른다.

2. 요청을 가변 구조로 정리

화면 구현 전에 다음 조건을 내부 생성 계획에 정리한다. 계획·가정·검증 결과는 작업 보고나 별도 파일에 기록하며 조직도 화면에 자동 삽입하지 않는다.

• 회사명·회사 수·회사 ID 및 회사별 독립 트리
• 대표이사 유무와 소속, 조직장·직원·직위 조건
• 부문·본부·실·부서·팀·사업부 등 요청된 조직 유형과 명칭
• 부모·자식 관계, 조직별 서로 다른 하위 조직 수와 직원 수
• 전체 직원 수, 조직 수, Depth 및 집계 범위
• 사용자 지정 추가 UI와 필요한 기존 탐색 기능

특정 중간 단계나 공통 Depth를 강제하지 않는다. 조직 수와 직원 수는 요청에서 산출하며 전용 회사 템플릿·배열 길이·고정 분배값으로 대체하지 않는다. 삼안의 6본부·17팀·500명은 테스트 사례일 뿐 기본값이나 완료 기준이 아니다.

다음 요청 형태를 모두 같은 해석·변환 절차로 처리한다. 실제 렌더링 가능 여부는 사용 중인 Core의 공개 계약을 확인한다.

• 회사 → 본부 → 팀 → 직원
• 회사 → 부문 → 본부 → 부서 → 팀 → 직원
• 대표이사 → 실 → 부서 → 직원
• 회사 → 사업부 → 직원
• 여러 회사 → 회사마다 다른 조직 계층과 Depth → 직원

Depth에 회사나 직원 카드를 포함하는지, 조직별 인원이 직접 소속인지 하위 조직 포함인지 구분한다. 의미가 불분명해 구조나 총원이 달라지는 경우 해당 항목만 질문한다. 내부 렌더러의 0부터 시작하는 인덱스를 사용자 Depth와 혼동하지 않는다.

3. 자연어에서 가상 데이터 생성

• 명시된 회사·조직명·관계·유형·조직 수·직원 수·직위·대표이사 유무를 정확히 반영한다. 합계가 충돌하거나 관계를 결정할 수 없으면 생성 전에 필요한 조건만 질문한다.
• 미지정 가상 명칭과 직원 분배는 요청 범위 안에서 합리적으로 결정할 수 있다. 선택한 값과 근거를 화면 밖에서 보고한다. 이전 테스트의 회사·Depth·팀 수·직원 수를 재사용하지 않는다.
• 요청하지 않은 대표이사, 중간 조직, 조직장용 추가 직원을 템플릿에서 자동 삽입하지 않는다. 대표이사가 직원 카드인지 조직 노드인지 구분하며 직원과 조직을 중복 생성하지 않는다.
• 전체 직원 수에는 별도 지시가 없는 한 요청된 대표이사·조직장을 포함한다. 직원 레코드는 한 번만 생성하고 조직장 참조를 연결한다. 조직별 직접 인원과 하위 조직 포함 인원을 분리해 집계한다.
• 직원 ID는 전체 데이터에서 고유하게 생성한다. 회사·조직 ID도 트리 간 충돌하지 않아야 한다. 입력 순서가 달라져도 같은 원본 항목의 내부 ID가 불필요하게 바뀌지 않도록 한다.
• 가상 데이터와 적용 가정을 사용자에게 명확히 보고한다. 화면 배너나 개발 안내는 기본적으로 추가하지 않고, 명시적으로 요청된 표시만 구현한다.

4. JSON·CSV·Excel 제공 데이터 변환

원본 구조와 값을 우선한다. 원본 파일·파싱 결과와 Contract 변환 결과를 분리해 관리한다.

• 직원·조직을 임의로 추가·삭제·합치지 않는다. 직원명·조직명·직위·원본 ID·상하위 관계를 변경하지 않는다. trim, 철자 교정, 누락 노드 합성, 임의 인원 분배를 적용하지 않는다.
• 행 수와 실제 조직·직원 수를 구분한다. 반복된 조직 정보가 같은 조직인지 원본 ID와 관계로 확인한다. 동명이인을 같은 직원으로 취급하거나 같은 이름의 조직을 자동 합치지 않는다.
• ID가 없는 항목에 변환용 내부 ID만 별도로 생성할 수 있다. 원본 필드와의 대응을 남긴다. 항목을 구별할 수 없으면 추가 식별 정보를 요청한다.
• 필요한 필드·컬럼 매핑을 확인한다. 원본에 없는 근무 상태·관계사·조직 유형·메타데이터를 실제 정보처럼 채우지 않는다. Contract 필수값이 없으면 사용자에게 확인하고, 명시적으로 허용된 변환 기본값은 원본과 구분해 기록한다.
• 중복 ID, 누락 조직·직원, 잘못된 부모·소속·조직장 참조, 순환 관계, 회사 간 계층 연결, 원본과 변환 결과의 조직 수·직원 수를 검사한다. 오류는 원본 행·셀 또는 변환 경로와 수정할 항목으로 표시한다.
• Excel의 선택 시트와 컬럼 범위를 확인한다. 여러 시트를 임의로 합치거나 제외하지 않는다. 수식·날짜·서식 있는 숫자·앞자리 0·인코딩을 보존할 수 없으면 지원 한계를 알리고 필요한 입력 형태를 요청한다.
• Contract에 없는 원본 정보는 별도 원본 자료에 보존한다. 미지원 필드를 Contract에 넣거나 원본을 조용히 버리지 않는다. 오류 데이터의 부분 렌더링은 사용자가 요청하고 안전하게 구분할 수 있을 때만 허용한다.

5. 현재 Core Contract와 공개 API 확인

관련 안내는 데이터 계약, Expanded 사용 안내와 실제 작업 기준 커밋의 패키지 exports·타입·Validator다. 문서의 초안이나 과거 검증을 현재 지원 증거로 사용하지 않는다.

• @hm-design/org-chart의 Organization·Employee, Validator·DataSource와 @hm-design/org-chart-react의 공개 OrgChart를 우선 재사용한다. 공개 CSS export와 실제 React bootstrap을 연결한다. 내부 src/dist 경로를 추측하거나 기존 Core를 복제하지 않는다.
• 업무상 조직 유형과 Contract의 기계적 type 값을 구분한다. 사용자 조직명은 유지하고 확인된 대응을 기록한다. 새 enum을 임의로 넣거나 맞지 않는 유형으로 조용히 치환하지 않는다.
• 회사별 독립 트리와 회사 ID·컬러 매핑을 확인한다. 특정 회사나 회사 수를 기본값으로 고정하지 않는다. 미등록 회사를 기존 회사 ID에 임의 연결하지 않는다. 필요한 프리셋이나 공개 확장 경로가 없으면 제약과 필요한 결정을 보고한다.
• 대표이사는 공개 조직장·상단 직원 표현 API로 연결한다. 기술적 루트가 필요한 경우 업무 조직과의 대응 및 집계 범위를 확인한다. 실제 제공 데이터에 가짜 회사·대표이사·조직을 추가하지 않는다.
• Core의 Validator를 통과한 데이터만 DataSource와 렌더러에 연결한다. 별도 사전 검사는 가능하지만 기존 Validator를 우회하거나 실패 항목을 삭제해 통과시키지 않는다.
• 레이아웃·Depth·대표이사 표현·다중 회사·TB/LR/Hybrid·Zoom/Pan·접기·팝업은 실제 공개 API가 지원하는 범위만 사용한다. 직원 연결 방향을 전체 트리 방향 지원으로 해석하지 않는다.
• 요청 구조나 최소 화면을 공개 API로 정확히 표현할 수 없으면 지원 한계와 대안을 보고한다. 임의 구현·합성 화면을 기존 Core 결과라고 주장하지 않는다. 공통 기능 확장이 필요하면 별도 승인 범위로 분리한다.

6. 선택한 생성 방식의 화면 구성

6.1 기본 출력과 제외 요소

Chart Only 결과물은 White Canvas + OrgChart Nodes + Connectors인 독립 조직도 컴포넌트다. 기존 페이지에 삽입할 수 있으며, 독립 미리보기에서는 흰색 조직도 영역을 최상위 화면으로 사용한다.

• 회사·조직 그룹, 요청에 포함된 대표자·본부장·팀장·직원 카드, 연결선과 필요한 화살표, 회사별 컬러를 표시한다. 조직명·직위·직원 이름 등 조직도를 구성하는 필수 텍스트는 유지한다.
• 해당 모드에서 지원되는 기존 Core의 그룹 접기·펼치기, Zoom/Pan·직원 정보 보기 등 조직도 내부 탐색 기능은 유지한다. 외부 조작 UI의 기본 제외를 Core 기능 삭제로 해석하지 않는다.
• 외부 제목·통계·설명·조작 패널은 Chart Only 컴포넌트에 생성하지 않는다. 새 페이지 레이아웃과 외부 UI 생성은 Full Page 범위로 구분하며, 한 요소의 요청을 다른 부가 UI의 승인으로 확대하지 않는다. 삽입 대상 기존 페이지의 UI를 삭제하거나 변경하지 않는다.

기본 제외 요소:

• 페이지 제목(예: 가상 조직도), 기준일, 회사 수·전체 인원 요약 문구
• 확대·축소·100% 복원·Fit to View 버튼 바 등 외부 컨트롤
• Zoom 배율 안내, Drag & Drop ON/OFF 상태 문구, 조작 방법 안내
• 설명 문단, 생성 조건 설명, 사용 설명·안내 패널
• JSON 미리보기, 테스트 결과·디버그 패널, 별도 통계 대시보드, 개발 안내
• 외부 회색 배경, 불필요한 Page Header·Wrapper·바깥 여백
• AI 채팅·생성 입력 UI, Navigation·추가 메뉴

저장·게시·다운로드·운영 API는 요청 범위 밖에서 추가하지 않는다. 테스트 결과·가정·제약은 조직도 화면 대신 작업 완료 보고서에 기록한다.

6.2 흰색 Root 캔버스와 초기 배치

• 캔버스는 Chart Only 컴포넌트의 Root 영역을 차지하며 배경은 흰색이다. 독립 미리보기에서는 화면의 Root로 사용하고, 기존 페이지 삽입 시에는 호스트가 제공한 영역 안에 배치한다. 호스트 페이지의 배경·레이아웃을 덮어쓰지 않는다. 외부 회색 영역이나 불필요한 바깥 여백을 생성하지 않으며 사용자가 지정한 캔버스 크기가 있으면 이를 우선한다.
• 초기 배치는 조직도 전체의 실제 Bounds와 캔버스 크기를 기준으로 가로·세로 중앙 정렬한다. 노드·그룹·연결선을 포함한 전체 범위와 위치를 확인하며 임의 고정 좌표·배율을 회사별 템플릿으로 만들지 않는다.
• 최초 Fit to View로 조직도 전체의 실제 Bounds를 캔버스에 맞춘다. 대규모 조직도에서는 초기 전체 개요와 확대 시 텍스트 읽기, 내부 이동, 외부 가로 넘침을 함께 확인한다. 공개 API의 배율 한계로 전체 Fit이 불가능하면 제약을 보고한다.
• 기존 Zoom/Pan을 재사용해 마우스 휠 확대·축소 및 Pan을 제공하고 내부 이벤트 기능을 유지한다. 초기 Fit은 배치 동작이며 Fit to View 버튼 바를 렌더링해야 한다는 뜻이 아니다. Chart Only에는 외부 컨트롤 버튼을 생성하지 않는다.
• 기존 카드·회사색·연결선·직원 팝업 디자인과 Theme를 유지한다. 캔버스 배경은 실제 선언된 공개 Theme·스타일 경로를 확인해 적용하며 없는 Token을 추측하지 않는다.
• 지원되는 공개 옵션으로 불필요한 내장 설명·요약·컨트롤을 제외한다. 옵션이 없거나 공개 API로 흰색 Root·중앙 배치를 구현할 수 없으면 제약을 보고한다. Shadow DOM 임의 조작, 공통 CSS 변경, Core·React Wrapper의 불필요한 공개 API 변경으로 해결하지 않는다.
• 최소 배율, 많은 직원, 긴 명칭, 깊은 계층, 여러 회사에서 전체 Fit과 가독성을 함께 만족할 수 없으면 잘림·읽기·탐색 한계를 보고한다. 이름·인원·Depth를 줄이거나 단순히 내용을 숨겨 잘림·레이아웃 문제를 감추지 않는다.

기본 구성은 다음과 같다.

• 기존 구성: Page Background → Header → Controls → Description → White Canvas → OrgChart
• Chart Only 구성: White Canvas → OrgChart

6.3 Fixed / Auto 공통 적용과 기존 화면 보호

• Fixed: 승인된 기존 카드·연결선 디자인과 해당 모드의 기존 배치를 재사용하고, 선택한 Chart Only 또는 Full Page 범위를 적용한다. 현재 공개 Chart Only 옵션은 Auto 전용이며 Fixed와 함께 쓰면 거부된다. Fixed Chart Only가 필요하면 제약으로 보고하고 별도 승인 범위로 분리한다.
• Auto / Expanded: 기존 Core 자동 배치를 재사용하고, Chart Only에서는 조직도 외부의 설명·테스트·조작 패널을 제외한다. Full Page에서는 요청된 외부 UI만 구성한다.
• 두 배치 모드 모두 가변 계층·정확한 인원·제공 데이터 보존 규칙을 유지한다. 배치 모드가 다르다는 이유로 추가 UI를 허용하지 않는다. 요청 데이터가 달라지면 계층과 렌더링도 그 데이터에서 달라져야 한다.
• Chart Only는 삽입용 독립 컴포넌트로, Full Page와 독립 미리보기는 독립 React entry로 제공한다. 기존 Full Composition·Expanded OrgChart·Department Colors·Overview·Storybook 메뉴·P9.5·P-AI1 결과를 교체하지 않으며 기존 Storybook 페이지의 제목·컨트롤·설명 UI를 삭제하지 않는다.
• Guard나 문서 분석기의 제약 때문에 요청하지 않은 Navigation·통계·설명 UI를 추가하지 않는다. 정책과 검사 도구가 충돌하면 원본 검사 결과와 원인을 보고하며 도구나 공통 계약을 이번 범위 밖에서 임의 수정하지 않는다.

6.4 Full Page 전체 페이지

• 기존 HMDesign Component·Pattern·Theme와 공개 API를 우선 재사용해 새 페이지의 전체 레이아웃을 구성한다. 기존 OrgChart Core·React Wrapper를 소비하며 새 조직도 엔진이나 카드 디자인을 만들지 않는다.
• 사용자가 요청한 제목·정보·필터·컨트롤과 필수 동작을 반영한다. 요구사항에 없는 통계·설명·다운로드·외부 API·추가 메뉴·AI 채팅·생성 입력 UI는 자동으로 추가하지 않는다.
• 조직도 캔버스와 요청 UI의 배치·크기·스크롤·반응형 동작을 함께 설계한다. Chart Only의 흰색 전체 Root·외부 UI 제외 규칙을 페이지 전체에 강제하지 않으며, 조직도 내부의 기존 디자인·탐색 기능은 유지한다.
• 일반 업무 화면의 HM 컴포넌트 선택·Navigation·Theme·React bootstrap·접근성·Guard 계약은 AGENTS.md의 필수 규칙을 따른다. Full Page 선택만으로 기존 Storybook 화면 수정이나 공통 Component·Pattern·Theme 변경을 허용하지 않는다.

7. 생성 절차와 최종 통합 검증

Chart Only 구현(2026-10-13): Chart Only를 선택한 Auto 조직도는 공개 옵션 layoutMode: 'auto' + presentationMode: 'chart-only'로 생성한다. 초기 Fit·가로/세로 중앙 배치(initialView: 'fit')와 Ctrl/⌘ 없는 커서 기준 휠 Zoom(wheelZoom: 'direct')이 기본 적용되며 React·Vanilla가 같다. 외부 제목·요약·버튼·안내를 따로 만들지 않고 Shadow DOM을 조작하지 않는다. Fixed는 이 옵션을 거부하므로(TypeError) Fixed 요청을 임의로 Auto로 바꾸지 않고 Chart Only 미지원 제약으로 보고한다. 생성 방식의 사전 선택과 Full Page 범위는 계속 §1.1을 따른다. 사용법은 공통 사용 가이드를 따른다. 아래 P10.2 문단은 구현 전 기록이다.

P10.2 구현 한계 확인: 이 정책은 목표이며 현재 Core의 모든 내장 UI를 끄는 공개 옵션을 의미하지 않는다. 실제 Auto/Fixed 독립 검사는 Chart Only PARTIAL이다. Auto의 기본 초기 배치는 가로 중앙·상단 정렬이고, Vanilla의 공개 fitToView()는 전체 Bounds 기준 가로·세로 중앙 배치를 지원한다. React Wrapper에는 이를 호스트가 직접 호출할 공개 handle/ref가 없다. 지원 범위·후속 개선 후보는 공통 사용 가이드를 확인한다. 기존 화면·Core·공개 API를 변경하거나 내장 DOM을 숨겨 정책 완료로 보고하지 않는다.

1. 코드 작성 전에 §1.1에 따라 생성 방식을 확인한다. 미지정이면 정해진 선택 질문에 대한 답변을 받은 뒤 진행하고, 이미 명시된 방식은 다시 묻지 않는다. 현재 작업 경로·Git 상태·기준 커밋·공개 API를 확인하고 기존 미커밋 변경과 병렬 작업, 서버 포트를 보호한다.
2. 회사별 계층·유형·Depth·조직 수·직원 수·조직장 집계 조건을 정리한다. 충돌하는 필수 조건만 확인한다.
3. 요청에서 가상 데이터를 생성하거나 제공 데이터를 보존해 변환한다. 계획과 변환 대응은 화면 밖에 기록한다.
4. 기존 Contract와 추가 정합성 검사를 통과시킨다. 이는 잘못된 데이터를 렌더러에 넘기지 않기 위한 필요한 사전 확인이다.
5. 선택한 방식으로 구현한다. Chart Only는 흰색 캔버스·노드·연결선의 삽입용 컴포넌트와 최초 Fit·휠 Zoom·Pan을 제공한다. Full Page는 기존 HM UI와 OrgChart Core·React Wrapper로 요청 UI·전체 배치·반응형 페이지를 구성한다. 새로운 구조를 고정된 사례로 바꾸지 않는다.
6. 구현 후 변경 범위의 코드·diff·계층·인원·중복 집계·보존·핵심 동작을 한 번에 검증한다. 필요한 Typecheck·Build·Guard를 수행하고 실제 브라우저에서 확인한다. 이미 성공한 동일 조건 검사를 반복하지 않고 수정·실패 범위만 다시 확인한다.
7. 390/768/1280/1440px와 사용자 지정 캔버스 크기에서 선택한 방식의 화면을 확인한다. Chart Only는 흰색 컴포넌트 Root·실제 Bounds 기준 최초 Fit과 중앙 배치·외부 UI 제외·호스트 삽입을, Full Page는 요청 UI·전체 배치·반응형·Navigation을 확인한다. 공통으로 배율·가독성·콘텐츠/내부 스크롤·줄바꿈·카드·연결선·회사색·Zoom/Pan 내부 이벤트·접기·팝업·키보드·포커스를 관련 사용 요소에 맞게 확인한다. 실제 실행 URL과 화면 캡처를 보고한다.
8. 선택한 생성 방식, 요청 대비 회사·조직·Depth·직원·조직장 집계, 생성 파일, 재사용 API, 가정, 제약, PASS/PARTIAL/FAIL와 NOT VERIFIED를 간결하게 보고한다. Guard 원본·정적·Runtime·STYLE 디자인 의도/최종 상태를 구분하고 미검증을 덮어쓰지 않는다.

정책 작성·연결만 수행하는 작업에는 화면 구현·빌드·브라우저 실행·전체 회귀를 필수로 추가하지 않는다. 독립 실험 환경에서 선택적으로 화면을 검증할 수 있으나 기존 Storybook·AI Playground 테스트 페이지는 수정하지 않는다. 화면 검증을 수행하지 않았다면 VISUAL NOT VERIFIED로 보고한다. 데이터 생성·렌더링 기능을 실행하지 않았다면 정책 작성 완료를 범용 런타임 지원 PASS로 보고하지 않는다.

8. 범위 보호와 완료 기준

• 기존 P9.5·P-AI1 산출물, P10 PARTIAL과 당시 Guard FAIL 10건의 검증 기록을 보존한다. 기존 P10.1 작업 폴더와 AI Playground Worktree를 수정하지 않으며 삼안 500명 테스트 페이지를 이관하지 않는다. 사전 선택 정책의 작성·연결 작업은 이 파일과 AGENTS.md·CLAUDE.md의 참조 안내만 다뤘으며 화면·데이터·Core 변경을 포함하지 않았다. 이후 2026-10-13 Feature 통합에는 Chart Only·초기 Fit·직접 Wheel Zoom, GuardFix 해결 5건, 생성 방식 사전 선택 정책만 포함한다. GuardFix는 F3–F7을 해결하며 잔여 FAIL 5건·NOT VERIFIED 9건과 원본 상태는 최종 Feature 통합 보고서에 구분해 기록한다. Cell 디자인·미리보기는 통합 대상에서 제외한다.
• 이 정책을 참조한 생성 요청만으로 Stage·Commit·Push·Merge를 승인받은 것으로 간주하지 않는다. 현재 사용자의 작업별 Git 지시를 우선한다. 사전 선택 정책의 작성 작업에서는 Stage·Commit·Push·Merge를 진행하지 않았으며, 이후 2026-10-13 통합 요청은 위 3개 작업의 변경 범위 검증 후 Feature Commit·Push를 명시적으로 승인했다. main Merge·Docker 작업·npm Registry Publish는 승인 범위에 포함되지 않는다.
• 서로 다른 회사·대표이사 유무·조직 유형·Depth·분기 수·직원 수가 같은 요청 분석 → 데이터 변환 → Contract 검증 → Core 소비 절차로 처리돼야 한다. 특정 테스트 수치나 전용 템플릿에 의존하면 완료가 아니다.
• 생성 작업의 완료는 명시 조건의 일치, 제공 데이터 보존, 기존 Core의 실제 렌더링, 요청 범위의 최소 UI, 실행 증거로 판단한다. 미지원 구조를 지원한 것처럼 보고하거나 분석·JSON만으로 화면 생성 성공을 선언하지 않는다.