원문: https://github.com/facebook/astryx/wiki/Component-Specification-Protocol · 번역 기준: 2026-09-03

처음이신가요? 전체 end-to-end 가이드는 Component Lifecycle부터 시작하세요. 이 페이지는 specification 단계를 상세히 다룹니다.

모든 새로운 Astryx 컴포넌트는 코드를 한 줄이라도 작성하기 전에 전체 specification 프로토콜을 거쳐야 합니다. 스펙은 계약입니다 — build 중에 스펙에서 벗어나려면 정당한 사유가 필요합니다.

Phase 1: Triage

• 컴포넌트 gap을 식별합니다 (내부 사용 데이터, builder 피드백, 또는 마일스톤 필요에서)
• 새로 만들기 전에 기존 컴포넌트의 조합으로 문제를 해결할 수 있는지 확인합니다
• 필요가 도메인 특화적이라면 그것은 recipe/example이지 core 컴포넌트가 아닙니다

Phase 2: Research — Internal

• 코드 검색(tbgs, tbgf, tbcs, zbgs)으로 내부 구현을 연구합니다
• 수집 항목: 현재 API, prop 타입, 내부 아키텍처, delegation 패턴
• 사용 분석: 어떤 prop이 실제로 쓰이는지, 얼마나 자주 쓰이는지, 흔한 패턴은 무엇인지
• 이식할 가치를 식별합니다 — 내부 구조가 아니라. 내부 아키텍처는 OSS에는 적용되지 않을 수 있는 내부 제약을 반영합니다

Phase 3: Research — External

• 다른 디자인 시스템(Radix, shadcn, Ant, MUI, Chakra)의 동등한 컴포넌트와 비교합니다
• 네이밍 컨벤션, API 패턴, slot 유연성을 기록합니다
• 업계가 수렴한 지점과 의미 있게 갈라지는 지점을 식별합니다

Phase 4: Enumerate Use Cases

API를 제안하기 전에 그 API가 처리해야 할 시나리오를 빠짐없이 나열합니다. 이는 happy path만 위한 설계를 하다가 build 중에 gap을 발견하는 일을 방지합니다.

모든 컴포넌트는 최소한 다음을 다뤄야 합니다: