TeamWicked Design System / 관리·검증

새 문서 작성 양식

사용 규칙과 구현 상태가 빠지지 않게 하는 공통 템플릿입니다.

적용 범위: TeamWicked 자체 브랜드·웹사이트. 호스팅 제품의 외형은 포함하지 않습니다. 공통 동작 규칙을 재사용하며, 다른 체계의 사례는 비교 근거일 뿐 스타일 상속이 아닙니다.

필수 메타데이터

id, title, category, order, summary, status, references를 frontmatter JSON 객체에 기록합니다. id는 파일 이름과 같은 영문 slug입니다. 날짜·현재 상태를 근거 없이 “검증 완료”로 쓰지 않습니다.

본문 순서

  1. 목적과 사용: 해결할 사용자 문제, 사용/비사용 조건.
  2. 구성과 변형: 의미 요소·변형·현재 제품 스타일 연결.
  3. 동작 규칙: 고유 ID와 MUST/SHOULD/MAY, 상태 전환·실패·복구.
  4. 접근성: 이름·역할·상태·키보드·focus·대비.
  5. 콘텐츠 예시: 올바른 예, 피해야 할 예, 한국어·단위.
  6. 우리 구현과 연결: 제품·파일·revision·해시·확인 범위.
  7. 코드 계약 예시: 필요한 경우에만 추가. 설명용인지 실행 가능한지 명시.
  8. 상태와 검증: 재현 절차·실제 결과·남은 미검증.
  9. 출처·변경 이유: Carbon 원문과 우리가 바꾼 이유.

작성 예

규칙 NEW-01 MUST: [사용자에게 보장할 동작].

구현 상태: ‘소스 확인 / 운영 미확인 / 브라우저 미검증’처럼 범위를 명시합니다. 예시 파일 이름으로 실제 구현이 존재하는 것처럼 링크하지 않습니다.

중요한 결정

[Decision Log]

  • 목적과 의도:
  • 기존 구현 및 제약 조건:
  • 검토한 주요 대안:
  • 선택한 방식:
  • 다른 대안 대신 이 방식을 선택한 이유:
  • 장점, 단점 및 영향:

갱신

문서 원본을 수정한 뒤 npm run docs:check와 npm run build를 실행합니다. source evidence 갱신은 별도 확인된 파일만 대상으로 합니다. references에 추가한 Carbon 페이지는 pin·해시·채택 범위를 함께 등록합니다.

출처와 적용 범위

원본 확인 범위와 운영 적용 여부를 구분합니다. 실행형 예제의 동작 확인은 모든 운영 화면의 접근성 검증을 의미하지 않습니다.

Markdown 원본 다운로드