design kit 게이트

턴이 끝날 때 결과는 그냥 놓이지 않습니다. 먼저 design-kit gate를 통과합니다. 게이트는 에이전트가 쓴 파일에 kit의 검사를 실행하고 트랜스크립트에 보고합니다. Gate passed이거나, 깨진 규칙과 위치를 정확히 적은 FAIL 목록입니다.

무엇을 검사하나

게이트는 브라우저가 읽는 방식으로 결과를 읽습니다. 렌더링된 상태로, 실제 너비에서요.

  • 대비 — 텍스트는 배경에 대해 휘도 하한을 넘어야 합니다
  • 최소 타이포 — kit의 크기 하한 미만의 텍스트는 안 됩니다
  • 히트 타겟 — 인터랙티브 컨트롤은 탭 가능한 크기여야 합니다
  • 동작하는 내비게이션 — 모든 nav 항목은 어딘가에 도달해야 하며, 토글이 가장 자주 막히는 폰과 태블릿 너비에서 검사됩니다
  • 데드 존 — 레이아웃이 인터랙션을 삼켜버리는 영역

검사는 다섯 너비 — 데스크톱, 노트북, 태블릿, 두 개의 폰 너비 — 에서 실행됩니다. 에이전트가 마침 쓴 크기에서만 동작하는 디자인은 출시가 아니라 적발됩니다.

트랜스크립트의 게이트 PASS 카드 — 초록색 Design checks, 변경 파일 목록

PASS

Gate passed는 결과가 kit을 통과했다는 뜻입니다. 그대로 가져가거나, 더 스티어링하거나, 배포할 수 있습니다. 트랜스크립트는 그 턴이 손댄 파일을 나열해서 변경의 영향 범위를 한눈에 보여줍니다.

FAIL — 그리고 수정 루프

FAIL은 깨진 규칙마다 finding으로 나열합니다. 검사 id, 깨진 너비, 해당 요소까지요. finding의 **"Fix at this width"**는 정확히 그 이슈를 한 줄짜리 수정 브리프로 에이전트에게 다시 보냅니다. FAIL은 막다른 길이 아니라 이미 쓰여진 다음 턴입니다. 자동 수정 루프는 findings가 손에 닿기 전에 스스로 한 번 재시도합니다.

finding이 있는 design-checks 패널 — 검사, 너비, "Fix at this width"

검사하지 않는 것

게이트는 규칙을 강제하지 취향을 강제하지 않습니다. 통과한 결과도 브리프에 맞지 않는 디자인일 수 있고, 그래서 스티어링, 리뷰 모드, 눈이 있는 것입니다. 그리고 kit이 아는 것만 검사합니다. 규칙 밖의 새로운 인터랙션이나 특이한 구조는 판정이 아니라 기본 통과입니다.

어디서 실행되나

게이트는 모든 표준 프로젝트 턴의 끝에서 실행됩니다. 코드베이스 프로젝트는 다릅니다. 도입된 리포지토리는 그 턴이 바꾼 파일에 대해 diff 범위 검사를, 내 개발 서버에 대해 실행합니다. Build mode를 참조하세요. Free와 Pro는 같은 게이트를 돌립니다. 라이선스가 계량하는 대상이 아닙니다.

Tip: FAIL finding이 의도적으로 맞아 보일 때(고의적인 액센트 예외, 알고 있는 트레이드오프) 고치지 않아도 됩니다. 댓글이나 Tweak으로 우회하거나, finding을 받아들이고 넘어가세요. 게이트는 조언합니다. 결정은 당신이 합니다.

관련 문서