cucuwang/visual-fix

Visual Fix

하나의 눈에 보이는 UI 문제를 하나의 지역화되고, 승인되고, 검증된 코드 변경으로 전환합니다.

지원되는 증거

다음의 유용한 조합을 허용합니다:

• 현재 UI의 스크린샷
• 스크린샷 내 주석 처리되거나 설명된 영역
• 역할이 식별된 현재 및 대상 스크린샷
• 라우트, 뷰포트, 컴포넌트 이름, 표시 문자열, 선택자 또는 테스트 ID
• "이 카드가 잘렸습니다" 또는 "이 컨트롤이 정렬되지 않았습니다"와 같은 일반 언어 증상

신뢰할 수 있는 위치 파악을 방해하는 증거만 요청하세요. 라우트와 고유 표시 문자열이 있으면 스크린샷 없이도 충분할 수 있습니다. 반복되는 컴포넌트가 있는 스크린샷은 여전히 라우트, 레이블 또는 상태가 필요할 수 있습니다.

한 번에 하나의 시각적 문제를 처리하세요. 관련 없는 증상은 별도의 수정으로 분할하세요.

워크플로우

1. 대상 설정

경계가 정해진 결과를 구체적인 용어로 다시 설명하세요:

• 현재 무엇이 잘못 보이는지
• 사용자가 무엇을 보기를 기대하는지
• 알려진 경우 관련 라우트, 컴포넌트, 상태 및 뷰포트
• 대상을 식별하는 표시 앵커

요청된 결과가 주관적이거나 다른 요소에 영향을 미칠 수 있는 경우, 이를 구분할 수 있는 가장 작은 질문을 하세요.

2. 읽기 전용 기준선 설정

편집 전:

• 저장소 지침과 진실 공급원(Source of truth)을 찾으세요.
• 작업 트리 상태를 검사하고 기존 사용자 변경 사항을 보존하세요.
• 프레임워크, 라우트 진입점, 컴포넌트 트리, 스타일링 시스템 및 사용 가능한 실행 또는 테스트 명령을 식별하세요.
• 환경이 허용하는 경우 대상 라우트와 뷰포트를 재현하세요.
• 변경 전에 현재 상태를 캡처하거나 기록하세요.

유지 관리되는 소스 파일이 존재하는 경우 생성된 출력을 편집하지 마세요. 관련 없는 작업 트리 변경 사항을 정리하거나 덮어쓰지 마세요.

기준선을 간략하게 보고하세요:

컨텍스트
- 라우트/상태: /catalog, 필터 열림
- 뷰포트: 390 x 844
- 진실 공급원: src/routes/catalog.tsx + src/styles/catalog.css
- 기존 사용자 변경 사항: 없음
- 재현: 가능

3. 렌더링된 소스 찾기

렌더링된 요소의 증거를 유지 관리되는 코드로 추적하세요. 라우트, 접근 가능한 이름, 표시 텍스트, DOM 선택자, 컴포넌트 이름, 테스트 ID, 클래스, 스타일 토큰 또는 스크린샷 지오메트리를 사용하세요. 여러 파일이나 스타일 레이어가 관련된 경우 references/locating.md를 읽으세요.

하나의 기본 소스 위치와 최대 두 개의 필수 관련 위치를 식별하세요. 파일 및 라인 증거는 현재 작업 트리에서 가져와야 합니다.

위치 파악됨
- 기본: src/components/ProductGrid.tsx:42, ProductGrid
- 관련: src/styles/products.css:18
- 증거: `.grid`가 카드 사이에 보이는 반복적인 가로 간격을 제어합니다
- 확신: 높음

두 개의 유사한 요소가 가능성이 있는 경우, 구별되는 증거를 설명하고 명확성을 위해 중지하세요.

4. 증거를 기반으로 진단

보이는 증상을 실제 코드와 연결하세요. 하나의 지지되는 원인을 선호하세요. 증거가 여전히 모호한 경우에만 두세 가지 가설을 제시하세요.

각 가설에 대해 다음을 포함하세요:

• 관련된 속성, 선택자, 토큰 또는 컴포넌트
• 이를 뒷받침하는 코드 또는 렌더링된 증거
• 의도된 수정 방향
• 이를 반증할 관찰

스크린샷에서 CSS 값을 임의로 만들지 마세요. 먼저 현재 값과 주변 디자인 시스템을 검사하세요.

5. 정확한 변경 계획 제시

편집 전에 제안된 패치를 보여주세요:

변경 계획
- 파일: src/components/ProductGrid.tsx:42
- 현재: gap: 8px
- 제안: 기존 space-4 토큰(16px) 사용
- 범위: /catalog 및 /search의 ProductGrid
- 보존: 카드 패딩, 모바일 열 개수, 관련 없는 라우트
- 검증: 대상 테스트, 린트, 390 x 844 및 1280 x 800에서의 스크린샷
- 위험: 중간; 컴포넌트가 두 라우트에서 공유됨

이 계획에 대한 명시적 승인을 기다리세요. 진단을 선택한다고 해서 코드 변경이 승인되는 것은 아닙니다. 계획이 나중에 다른 파일, 종속성, 잠금 파일, 생성된 아티팩트 또는 라우트로 확장되는 경우, 수정된 계획을 제시하고 다시 승인을 받으세요.

6. 승인된 패치 적용

계획을 구현하는 가장 작은 변경을 만드세요. 승인된 파일과 범위 내에서 편집을 유지하세요. 그런 다음 즉시 diff를 검사하세요:

• 프로젝트가 Git을 사용하는 경우 git diff --check를 실행하세요.
• diff에 계획된 변경 사항만 포함되어 있는지 확인하세요.
• 기존 변경 사항을 보존하고 관련 없는 서식 변경을 피하세요.
• 별도로 승인되지 않는 한 커밋, 푸시, 종속성 설치 또는 외부 서비스 수정을 하지 마세요.

7. 결과 확인

성공을 주장하기 전에 references/verification.md를 읽으세요.

사용 가능한 가장 강력한 증거를 사용하세요:

1. 변경된 코드와 관련된 대상 테스트, 포맷팅, 타입 검사 또는 빌드를 실행하세요.
2. 기준선에 사용된 것과 동일한 라우트, 상태 및 뷰포트를 렌더링하세요.
3. 시각적으로 이전과 이후를 비교하세요.
4. 변경된 소스의 범위가 더 넓은 경우 하나의 근처 뷰포트 또는 공유 라우트를 확인하세요.

정확히 하나의 확인 상태를 보고하세요:

• 시각적으로 확인됨: 비교 가능한 이전 및 이후 렌더링 증거가 있는 경우
• 정적으로 확인됨: 코드 검사는 통과했지만 UI를 렌더링할 수 없는 경우
• 시각적으로 확인 불가: 환경에 라우트, 브라우저, 픽스처 또는 시작 경로가 없는 경우
• 확인 실패: 실패한 명령 또는 관찰된 회귀와 함께

확인에 실패하면 진단으로 돌아가세요. 승인되지 않은 두 번째 수정을 첫 번째 수정 위에 쌓지 마세요.

완료 보고서

인계를 간결하고 증거 기반으로 유지하세요:

수정됨
- 대상: 모바일 너비에서 카탈로그 카드 간격
- 소스: src/components/ProductGrid.tsx:42
- 변경: gap이 이제 space-4 사용
- 확인: 390 x 844에서 시각적으로 확인됨; 단위 테스트 및 린트 통과
- 광범위 확인: 390 x 844의 /search 및 1280 x 800의 /catalog

남아 있는 시각적 불확실성을 언급하세요. 코드 diff를 시각적 증거로 설명하지 마세요.