화면 캡처 → API 응답 데이터

핵심은 화면을 그리려면 서버가 내려줘야 하는 응답 데이터를 필드 표로 뽑는 것이다. 기본 출력은 필드 표와 확인 질문뿐이다.

모드

• 추출(기본): 아래 절차대로 필드 표를 만든다.
• design: 사용자가 API 설계·DTO·OpenAPI를 명시적으로 요청할 때만. 추출 후 references/design.md를 따른다.
• verify: 사용자가 기존 API 검증을 명시적으로 요청할 때만. 추출 후 references/verify.md를 따른다.

요청에 없는 모드로 넘어가지 않는다.

입력

• 화면 캡처 1장 이상. Figma 커넥터가 연결돼 있고 프레임 URL이 주어지면 커넥터로 레이어 텍스트를 직접 가져온다.
• 화면정의서 설명 텍스트가 있으면 캡처보다 우선한다.
• 코드베이스가 있으면 기존 응답 DTO 1~2개를 읽고 네이밍·날짜 포맷·공통 응답 래퍼·페이지네이션 방식을 따른다.

분석 (내부에서만 하고 출력하지 않는다)

1. 마커(01, 02…) 단위로 요소를 훑는다. 마커가 없으면 위→아래로 A, B…를 붙인다. 마커 박스가 요소와 어긋나면 의미상 가장 가까운 요소를 기준으로 한다. 읽을 수 없는 글자는 추측하지 않고 [판독불가]로 둔다.
2. 요소를 응답 포함 여부로 가른다.
   • 포함: 서버 원천 값, 계산 값의 원천(D-7 → 마감 일시), 조회자별 값(내 투표 여부, 좋아요 여부, 버튼 활성 여부 → viewer.* 하위)
   • 제외: 고정 문구, 화면 이동, 쓰기 액션 자체(단 액션의 활성 여부·결과 상태는 조회자별 값으로 포함)
   • 고정 문구가 규칙을 암시하면(예: "종료 전 결과 비공개") 응답 형태에만 반영한다(예: 종료 전 null).
   • 서버 시각에 의존하는 상태(진행중/종료)는 서버가 status로 확정한다.
3. 캡처에 안 보이는 경우 중 응답 필드를 바꾸는 것만 점검한다: 다른 상태에서 생기는 필드, 표시 개수와 총 개수 차이(페이지네이션), 답글 같은 계층, 목업 데이터 모순.

출력

<결론 한 줄: 리소스 N개와 엔드포인트 후보>

### <엔드포인트 후보 또는 리소스명>
| 필드 | 타입 | null | 근거 | 비고 |
|---|---|---|---|---|

확인 필요
1. <질문> → <영향 필드>

• 필드: 점·[] 경로 표기(author.name, comments[].likeCount).
• 타입: string | integer | long | boolean | decimal | date | datetime | enum(보인 값, 추정 값은 …) | object | array.
• null: Y/N.
• 근거: 마커 번호. 화면 근거 없이 구현상 필요한 필드(id, 커서)는 -.
• 비고: 필요할 때만 짧게 쓴다. 계산 원천, null이 되는 조건, 추정·가정 여부.
• 근거 없는 필드는 만들지 않는다. 증가하는 하위 목록(댓글 등)은 별도 리소스 표로 뺀다.
• 확인 필요는 응답 필드를 바꾸는 것만, 최대 5개. 나머지는 합리적으로 가정해 표에 반영하고 비고에 "가정"이라고 적는다.
• 여러 화면이면 화면별로 표를 만들고, 공통 리소스(작성자 등)는 한 번만 정의한다.
• 인벤토리, 점검 목록, 액션·규칙 표, 요청 스키마, 개념 설명은 출력하지 않는다.

채워진 예시는 references/example.md를 본다.