원문: https://github.com/facebook/astryx/wiki/Component-Hardening-Protocol · 번역 기준: 2026-09-03
Hardening은 이미 출시된 컴포넌트를 붙잡고 이렇게 묻습니다: 이것은 정확하고, 완전하며, 다듬어져 있는가?
이 페이지의 대부분은 이동했습니다. 예전에 여기에 있던 검사 항목들은 이제 Component Audit Rubric에 있습니다 — 무엇을 검사하는지, 어떻게 검증하는지, 실패가 얼마나 심각한지, 어떻게 점수를 매기는지는 그 페이지가 소유합니다. scope 규칙(무엇이 hardening 수정으로 간주되고 무엇이 새 capability인지, API 변경이 언제 허용되는지, 네이밍 분쟁이 어떻게 라우팅되는지)은 Component Lifecycle §When Findings Route Back으로 옮겨갔습니다.
여전히 여기에만 있는 것은 Layer 3: 사람이 하는 디자인 리뷰와 그 form입니다. 그것이 이제 이 페이지의 역할입니다.
| Layer | 실행 주체 | 하는 일 | 위치 |
|---|---|---|---|
| 1. 자동화된 audit | nightly pass | 컨벤션 검사 — token, 네이밍, 테마, a11y 계약, export | Component Audit Rubric의 auto 및 semi 항목 |
| 2. 버그 및 비주얼 수정 | 에이전트 + 사람 리뷰 | 비주얼 버그, 상태 커버리지 공백, 엣지 케이스, 내부 일관성 | Component Audit Rubric §4, §5 |
| 3. 디자인 리뷰 | 사람 (준비 작업 지원) | 비례, 인터랙션 감각, 조합 품질, 비주얼 폴리시 | 이 페이지 |
Layer 1과 2는 사람의 주의를 필요로 하지 않아야 합니다: 객관적인 것은 자동화하고, 명백히 잘못된 것은 고치고, 정말로 사람의 눈이 필요한 것만 에스컬레이션합니다.
사람의 시각적 판단입니다. form을 준비해 두면 사람이 채웁니다.
Layer 3의 scope는 비주얼 및 인터랙션 품질입니다. 네이밍, API 형태, 특정 prop이 존재해야 하는지 여부는 다루지 않습니다 — 그것들은 엔지니어링과 spec의 관심사입니다.
rubric의 §5b는 스크린샷으로 같은 영역을 채점합니다. 이 form은 사람이 판단을 기록하고 발견한 것을 라우팅하는 방법입니다. Layer 1과 2가 끝난 뒤, §5b가 이미 요구한 스크린샷을 가지고 실행합니다.
다른 레퍼런스와 비교해서가 아니라, 독립적인 컴포넌트로서 그 자체로 올바르게 보이는가?
Proportions — 크기, 간격, 타이포그래피가 균형 있게 느껴집니까?