Oil Frontend
먼저 사용자 작업, 비즈니스 객체 및 데이터 출처를 식별한 후, 유효하지 않은 내용을 삭제하고 올바른 정보, 상태, 코드 소속 및 공유 구현을 구축합니다.
항상 준수
- 실제 사용자 작업, 비즈니스 객체 및 완료 결과에서 출발합니다. 보이는 내용은 정보를 식별, 비교, 판단, 조작 또는 이해하는 데 도움이 되는 것만 남깁니다.
- 하나의 사용자 의도는 한 번만 실행하며, 동작은 실제 결과를 생성해야 합니다. 데이터, 작업, 바쁨 상태 및 제출 경계는 일관되게 유지하며, 실패 시 현재 객체, 위치 및 입력된 내용을 보존합니다.
- 일반적인 작업은 사용자의 기존 인식을 따릅니다. 리소스 탐색은 기본적으로 표시하고, 편집은 명시적으로 트리거해야 하며, 폼은 현재 작업에 필수적이고 현재 객체가 소유한 데이터만 수집합니다.
- 아이콘, 강조 방식 및 고정 크기는 모두 안정적인 의미를 표현해야 합니다. 범용 AI 장식, 무의미한 강조선 또는 현재 인스턴스에만 맞는 크기로 계층을 만들지 않습니다.
- 시각적 조정은 먼저 프로젝트의 기존 디자인 변수, 컴포넌트 및 밀도를 사용한 후, 계층, 간격, 타이포그래피, 표면 및 피드백을 처리합니다. 프로젝트 표준이 없을 때만 참조 규칙의 대체 값을 사용하며, 대체 값을 새로운 디자인 시스템으로 확장하지 않습니다.
- 동일한 비즈니스 데이터 및 동일한 의미는 하나의 권위 있는 출처만 유지합니다. 데이터 흐름, 상위 레이아웃 및 공유 구현을 우선적으로 수정하고, 페이지 사용 위치에서 반복적으로 패치를 적용하지 않습니다.
- 비즈니스 소속에 따라 컴포넌트, Hook, 함수, 타입, 스타일 및 테스트를 구성합니다. 단일 모듈 코드는 가까이 배치하고, 안정적으로 여러 모듈에서 재사용될 때만 공유 계층으로 이동합니다.
- 복잡한 로직에 직면하면 먼저 프로젝트의 기존 기능과 성숙한 라이브러리를 확인합니다. 기존 종속성이 적절하지 않은 경우, 유지 관리가 잘되고 프로젝트와 호환되는 새로운 라이브러리를 도입할 수 있지만, 기존 성숙한 솔루션이 다루는 핵심 기능을 직접 구현하지 않습니다. 간단한 로직은 직접 구현하며, 적은 양의 코드를 위해 새로운 종속성을 도입하지 않습니다.
- 프로젝트 기록이 정확성의 증거는 아닙니다. 오류 패턴은 대체되어야 하며, 관련 사용 위치를 마이그레이션한 후에만 이전 코드, fallback, legacy 로직 및 유효하지 않은 상태를 삭제합니다.
참조 파일 읽기 순서
- 트리거 후 먼저 이 파일만 읽고, 작업, 객체 및 변경 범위를 명확히 하며, 참조 파일을 미리 읽지 않습니다.
- 작업이 사용자에게 보이는 UI, 프런트엔드 상태와 데이터 흐름, 컴포넌트 구현 또는 프런트엔드 코드 구성과 관련되지 않은 경우, 이 Skill 사용을 중단합니다.
- 먼저 사용자가 변경하려는 결과에 따라 하나의 주요 규칙을 선택하며, 파일 유형이나 코드에 나타난 CSS, 애니메이션 키워드로 규칙을 선택하지 않습니다.
- 간단한 로컬 변경은 하나의 주요 규칙만 읽습니다. 작업에 실제로 두 번째 독립적인 문제가 포함된 경우에만 하나를 추가합니다. 여러 페이지에 걸친 종합 검토에서만 세 개를 읽을 수 있으며, 그 이상은 안 됩니다.
- 키워드 출현, 파일 내 링크 또는 "안전을 위해" 계속해서 규칙을 읽지 않습니다. 시각적 증상이 데이터, 상태 또는 상위 레이아웃으로 인해 발생한 경우, 실제 근본 원인을 담당하는 규칙을 읽고, 시각적 규칙을 추가로 로드하지 않습니다.
| 현재 작업 | 주요 규칙 | 다음 경우에만 추가 |
|---|---|---|
| "보기에 이상함", 시각적 정밀 조정, 계층, 간격, 타이포그래피, 색상, 둥근 모서리, 테두리, 그림자 또는 아이콘 | 시각적 엔지니어링 | 공유 토큰, 컴포넌트 기본 스타일 또는 변형을 수정해야 할 때 컴포넌트 및 코드 구성 읽기; 분할, 스크롤 또는 반응형 구조를 변경할 때 뷰포트 및 대화상자를 주요 규칙으로 변경하여 읽기 |
| 애니메이션, 전환, 마이크로 인터랙션, 펼치기/접기, 드래그 피드백, 스크롤 효과 또는 끊김 | 모션 및 성능 | 모션이 동작 피드백 또는 시각적 계층을 담당할 때 시각적 엔지니어링 읽기; 근본 원인이 비동기 상태일 때 상태 및 로딩으로 주요 규칙을 변경하여 읽기 |
| 모듈 경계, 컴포넌트, Hook, 함수, 타입, 스타일 소속, 공유 스타일, CSS 구성 또는 공유 구현 | 컴포넌트 및 코드 구성 | 새로운 검사가 필요할 때 자동화 읽기 |
| 새로운 또는 변경된 텍스트, 동작 의미, 아이콘, 클릭 피드백 또는 시각적 강조 | 정보 및 동작 | 객체 식별, 이미지 또는 선택기가 관련될 때 리소스 식별 읽기 |
데이터, 상태 및 레이아웃은 계속해서 결과에 따라 선택합니다:
| 현재 작업 | 주요 규칙 | 다음 경우에만 추가 |
|---|---|---|
| 목록, 카드, 상세, 테이블 또는 일괄 작업 | 컬렉션 및 상세 | 리소스 식별이 관련될 때 리소스 식별 읽기; 편집이 관련될 때 상호작용 및 편집 읽기 |
| 폼, 선택, 편집 또는 다단계 워크플로우 | 상호작용 및 편집 | 저장 범위 및 프로세스 연속성이 관련될 때 데이터 및 작업 범위 읽기 |
| 쿼리 결과, 페이지네이션, 후보 집합, 저장 범위, 일괄 범위 또는 요청 결과 소속 | 데이터 및 작업 범위 | 동시에 로딩, 새로고침, 빈 상태, 오류 또는 처리 중 표시가 변경될 때 상태 및 로딩 읽기 |
| 로딩, 새로고침, 빈 상태, 필터링됨-빈 상태, 오류, 대기 중, 처리 중 또는 스켈레톤 | 상태 및 로딩 | 동시에 쿼리 스냅샷, 작업 범위 또는 저장 결과 소속이 관련될 때 데이터 및 작업 범위 읽기 |
| 페이지 크기, 분할, 스크롤, 팝업 구조 또는 반응형 동작 변경 | 뷰포트 및 대화상자 | 드롭다운, 메뉴, 툴팁 등 트리거에 부착된 플로팅 레이어가 관련될 때 오버레이 읽기 |
다음 경우 추가 읽기를 트리거하지 않습니다:
- 코드에 Tailwind, CSS,
transition또는 애니메이션 라이브러리가 존재한다고 해서 작업이 시각적 또는 모션 작업인 것은 아닙니다. - 색상, 간격, 테두리, 그림자, 타이포그래피 등 보이는 속성을 변경할 때는 시각적 엔지니어링을 주요 규칙으로 합니다. 작업이 동시에 스타일 소속, 공유 방식 또는 모듈 경계 조정을 요구할 때만 컴포넌트 및 코드 구성 규칙을 추가합니다.
- 색상 변수명, 클래스명, 타입 또는 임포트 오류만 수정하고 시각적 결과를 변경하지 않을 때는 시각적 엔지니어링 규칙을 읽지 않습니다.
- 기존 모션에 대해 비즈니스 상태, 이벤트 바인딩 또는 데이터 출처만 변경하고 모션 방식이나 성능을 변경하지 않을 때는 모션 규칙을 읽지 않습니다.
- 기존 컨트롤만 이동하고 텍스트, 동작 의미 또는 피드백을 변경하지 않을 때는 정보 및 동작 규칙을 읽지 않습니다.
- 일반적인 부모-자식 컨테이너 소속만 조정하고 크기, 스크롤, 팝업 또는 반응형 동작을 변경하지 않을 때는 뷰포트 및 팝업 규칙을 읽지 않습니다.
- 참조 파일의 링크는 관련 규칙의 위치를 설명할 뿐, 계속 읽어야 함을 의미하지는 않습니다.
용어 빠른 참조
이 파일 및 참조 규칙의 핵심 용어는 다음 정의에 따라 이해합니다:
- 리소스 식별: 사용자가 "이것이 어떤 객체인지"를 인식할 수 있는 최소 정보 조합 - 이미지 + 이름 + 하나의 구분 필드. 예: 멤버 목록에 "아바타 + 이름 + 부서" 표시, "uuid + 유형 태그"가 아님.
- 가짜 작업: 사용 가능해 보이지만 실제 결과를 생성하지 않는 컨트롤. 예: "저장"을 클릭하면 로컬 state만 변경되고 새로고침 시 손실됨; 삭제 버튼이 영구적으로 비활성화된 자리 표시자.
- 단일 컴포넌트의 시각적 패치: 공유 컴포넌트를 사용하는 페이지 위치에서 이 컴포넌트 하나에만 스타일을 추가하는 것. 예:
<Dialog className="h-[640px]">,!important오버라이드, 페이지 전용 선택자로 컴포넌트 내부 수정. 올바른 방법은 공유 컴포넌트 자체를 수정하거나, 사용 목적에 따라 명명된 컴포넌트 변형을 추가하는 것입니다. - 용도별 명명된 컴포넌트 변형(variant): "왜 다른지"로 명명합니다. 예:
variant="destructive",size="compact"는 적합;variant="blue",variant="userListPage"는 부적합. - 주요 동작: 현재 페이지, 팝업 또는 작업 영역에서 주요 작업을 완료하는 하나의 동작. 동일 영역에서 최대 하나의 높은 강조 버튼.
- 제출 경계: 한 번의 수정이 실제로 언제 적용되는지 - 즉시 적용, 자동 저장, 명시적 통합 제출, 또는 임시 미리보기만.
- 바쁨 범위: 요청 진행 중 중복 작업을 방지해야 하는 최소 영역. 단일 항목 요청은 해당 항목만 잠그고, 전체 페이지 마스크를 사용하지 않습니다.
- 제출된 쿼리 스냅샷: 동일한 응답에 의해 공동으로 결정된 쿼리 조건, 목록, 결과 총 개수 및 페이지 정보. 새 쿼리가 완료되기 전에 이전 스냅샷은 여전히 이전 조건에 속합니다.
- 동일 유형 일괄 작업: 동일한 유형의 객체 집합에 대해 동일한 필드를 반복해서 채우는 작업(예: 일괄 일정 조정, 일괄 가격 변경).
- 편집 가능한 워크시트: 동일 유형의 일괄 작업을 위해 여러 행이 지속적으로 편집 상태에 있는 테이블. 이와 반대는 리소스 목록: 기본적으로 표시, 편집은 명시적으로 트리거해야 함.
의사 결정 순서
변경 전에 순서대로 답변합니다.
작업 및 객체:
- 사용자가 현재 완료하려는 작업은 무엇이며, 어떤 결과가 완료를 나타냅니까?
- 페이지가 관리하는 핵심 객체는 무엇이며, 필드는 각각 누구의 소유입니까?
- 현재 탐색, 비교, 선택 또는 편집 중이며, 사용자에게 익숙한 구조와 용어를 따르고 있습니까?
데이터 및 범위:
- 데이터는 전체 컬렉션, 현재 표시되는 컬렉션 또는 검색 결과에서 가져옵니까?
- 작업, 바쁨 상태 및 제출 경계는 각각 어떤 범위에 영향을 미칩니까; 원격 쿼리 조건과 현재 목록이 이미 동일한 제출된 결과에 속합니까?
- 사용자는 어떤 정보를 사용하여 인접 객체를 구분합니까?
- 텍스트, 단계, 확인, 반복 입력 또는 시스템이 이미 알고 있는 필드를 삭제할 수 있습니까?
- 어떤 정보가 컬렉션에 속하고, 어떤 정보가 상세 정보에만 속합니까?
구조 및 상태:
- 현재 페이지, 팝업 또는 작업 영역의 주요 동작은 무엇입니까?
- 첫 화면, 스크롤 컨테이너 및 오버레이 경계는 각각 누가 담당합니까?
- 로딩, 빈 상태, 필터링됨-빈 상태, 대기 중, 처리 중, 오류, 준비 상태는 어떻게 상호 배타적입니까?
시각적 및 모션, 작업이 변경을 요구할 때만 답변:
- 현재 프로젝트는 어떤 Token, 컴포넌트 및 인접 페이지를 사용하여 계층, 밀도 및 모션 언어를 정의합니까? 실제로 일관성이 없는 보이는 속성은 무엇입니까?
- 모션은 상태 피드백, 공간 관계 설명 또는 장식입니까;
transform,opacity또는 기존 컴포넌트 기능만으로 완료할 수 있습니까?
착점:
- 올바른 소속의 모듈, 컴포넌트, Hook, 함수, 타입, 통합 디자인 변수 또는 스타일이 이미 존재합니까? 최종적으로 어떤 데이터 소스, 상위 레이아웃 또는 공유 구현을 수정해야 합니까?
명확하게 답변할 수 없을 때는 먼저 UI 요소 추가를 중단합니다: 사용자에게 가장 중요한 1-2개의 질문을 합니다; 질문할 수 없을 때는 최소 검증 가능 범위로 구현하고, 출력에서 가정한 내용을 명시합니다.
실행 흐름
1. 사실 복원
- 프로젝트의 기존 모듈, 컴포넌트, Hook, 함수, 타입, 통합 디자인 변수 및 스타일을 검색하여 동일한 의미가 이미 올바르게 구현되었는지 확인합니다.
- 공유 컴포넌트를 사용하는 모든 페이지와 컴포넌트, 그리고 동일한 데이터의 다른 진입점을 찾습니다.
- 검토 요청은 증거와 제안만 제공합니다; 사용자가 수정을 요청할 때만 구현합니다.
2. 범위 명확화
- 핵심 객체, 필드 소유자, 데이터 컬렉션, 작업 범위, 바쁨 범위 및 제출 경계를 명확히 합니다.
- 페이지 구조 문제, 컴포넌트 기본 동작, 페이지 사용 방식 오류 및 데이터 흐름 오류를 구분합니다.
- 시각적 문제는 특정 요소, 속성, 기존 근거 및 코드 착점을 지적할 수 있는 차이만 기록합니다; 올바른 값을 확신할 수 없을 때는 먼저 프로젝트의 기존 Token 또는 인접 유사 컴포넌트를 사용하고, 미적 감각으로 정확한 수치를 발명하지 않습니다.
3. 먼저 삭제
- 판단에 영향을 주지 않는 내용, 중복 상태, 중복 진입점, 중복 확인 및 단일 컴포넌트에만 적용된 시각적 패치를 삭제합니다.
- 실제 상태 변경이 없거나 데이터를 실제로 저장할 수 없는 가짜 작업을 삭제합니다.
- 새로운 구현으로 대체된 이전 컴포넌트, 이전 함수, 이전 타입, 이전 상태, fallback, legacy 로직, 이전 스타일 및 유효하지 않은 참조를 삭제합니다.
4. 구조 선택
- 먼저 프로젝트에서 유사한 작업 페이지 및 공유 컨테이너 컴포넌트의 기존 사용법을 확인합니다; 기존 패턴이 본 규범을 따를 때만 계속 사용하고, 그렇지 않으면 실제 작업에 따라 구조를 다시 선택합니다.
- 탐색, 비교, 선택, 일괄 구성 또는 심층 편집 작업에 따라 목록, 테이블, 워크시트, 선택기, 팝업 또는 전체 작업 영역을 선택합니다.
- 목록은 식별 및 비교를 담당하고, 상세 정보는 전체 내용을 담당하며, 편집기는 수정을 담당하게 합니다.
- 시각적 조정은 "정보 계층 → 공간 및 정렬 → 타이포그래피 → 표면 → 컨트롤 상태 → 모션" 순서로 처리합니다; 이전 계층에서 문제를 해결했으면 중단하고, 계속해서 장식을 추가하지 않습니다.
5. 실제 오류 위치 수정
- 데이터 범위, 작업 범위, 상위 레이아웃, 공유 컴포넌트 기본 동작 및 의미가 안정적인 컴포넌트 변형을 우선적으로 수정합니다.
- 반복되는 리소스 식별, 메뉴, 오버레이, 로딩, 팝업 및 작업 표시줄은 공유 컴포넌트를 사용합니다.
- 책임, 입력/출력 및 동작이 안정적으로 반복될 때만 추상화합니다; 국소적 구조가 유사하다고 컴포넌트를 복사하지 말고, 많은 페이지 스위치로 만능 컴포넌트를 만들지 마십시오.
- 기존 공유 컴포넌트, 함수, 스타일 또는 데이터 흐름 자체에 오류가 있는 경우, 권한 범위 내에서 실제로 잘못된 공유 구현을 직접 수정하거나 교체하고, 영향을 받는 모든 사용 위치를 처리합니다; 이전 역사와 호환되도록 오류 구현을 계속 추가하지 마십시오.
- 현재 범위 내에서 모두 수정할 수 없는 경우, 이전 패턴을 확장하지 말고, 남은 이전 사용 위치와 이번에 수정된 범위를 명확히 보고하며, 통합되었다고 주장하지 않습니다.
- 반복적으로 감지할 수 있는 문제를 수정할 때, 프로젝트에 lint, 테스트 또는 검사 규칙을 새로 추가해야 하는지 판단합니다; 필요하면 경로 테이블에 따라 자동화를 추가로 읽고, 추가 규칙 수에 포함시킵니다. 작은 변경을 위해 이를 위한 자동화를 사전에 구축하지 않습니다.
- 관련 없는 영역을 수정하지 않습니다.
6. 검증
- 프로젝트의 기존 타입 검사, Lint, 테스트 또는 빌드 중 변경 사항과 관련된 것을 실행합니다.
- 간단한 로컬 변경은 수정 위치, 직접적인 동작 및 가장 가까운 사용 위치만 검사하고, 전체 상태 매트릭스를 펼치지 않습니다.
- 변경이 공유 컴포넌트, 데이터 범위, 비동기 상태, 폼 흐름, 스크롤, 반응형 또는 여러 페이지에 영향을 미칠 때, 영향을 받는 상태, 데이터 범위, 대표적인 뷰포트 및 모든 사용 위치를 검사합니다.
- 시각적 변경은 실제 내용, 주요 상태 및 영향을 받는 뷰포트를 검사합니다; 모션 변경은 유형에 따라 적용 가능한 중단, 반복 트리거, 종료, 언마운트 또는 스크롤 동작만 검사합니다. 복잡한 모션이나 실제 끊김이 있을 때만 성능 기록을 사용하며, 모든 전환을 성능 전담 작업으로 격상시키지 않습니다.
- 검증된 항목, 검증되지 않은 항목 및 차단 이유만 보고합니다.
독립 자체 점검
프런트엔드 검토가 여러 페이지, 모든 공유 컴포넌트 사용 위치, 여러 뷰포트 또는 상태를 포함하거나, 대규모 규칙 조정을 포함할 때만 대화 기록 없이 독립 자체 점검을 수행합니다. 단일 페이지, 단일 컴포넌트, 단일 스크린샷 및 국소적 차이는 메인 Agent가 직접 검사합니다.
독립 자체 점검은 검사 대상, 범위 및 oil-frontend만 수신하며, 대화 기록, 기존 결론, 문제 추측, 예상 답변 또는 수정 계획은 수신하지 않습니다.
출력 요구 사항
먼저 결론을 제시한 다음 증거를 제시합니다. 다음만 출력합니다:
- 구체적인 문제
- 삭제해야 할 내용
- 올바른 정보, 동작 및 공간 구조
- 수정해야 할 모듈, 공유 컴포넌트 또는 데이터 흐름
- 검증된 항목 및 검증되지 않은 항목
"경험 개선", "더 현대적인", "더 직관적인" 등 구현을 안내할 수 없는 설명은 사용을 금지합니다.
능동적으로 접근성 전담 감사로 확장하지 않습니다. UI를 구현할 때 기본 상호작용 요소를 계속 사용하고, 프로젝트의 기존 포커스, 키보드, 레이블 및 ARIA 동작을 손상시키지 않습니다; 사용자가 명시적으로 요청하거나 현재 변경으로 인해 작업을 완료할 수 없는 경우에만 검사를 확장합니다.