---
name: cofa-verify
description: "Cofa 결과물을 제출 전에 요구사항과 실제 실행 증거로 점검한다. 구현 완료 주장, 제출 파일, 데이터 처리, 수동 화면 확인의 누락을 찾을 때 사용한다."
---

# 제출 전 사실 확인

제출 확정 전용이다. 확정 후에는 질문 준비 대기 중에도 이 스킬과 AI 작업을 중단한다.

구현자의 설명보다 과제 안내, 실제 파일, 실행 결과를 먼저 확인한다. `만들었음`, `실행됨`, `요구를 충족함`을 구분한다. 코드를 읽거나 증거 파일이 존재한다는 사실만으로 기능 통과를 선언하지 않는다.

## 가장 큰 실패부터 점검

1. **필수 산출물:** 실제 안내의 파일명·경로·형식과 비교한다. 빈 파일, 임시 문구, 깨진 참조, 실제 결과와 다른 문서를 찾는다. 키트 예시 파일을 공식 제출 양식으로 취급하지 않는다.
2. **재현:** 현재 제공 환경에서 알려진 실행 명령으로 시작할 수 있는지 확인한다. 설치 성공과 서비스 준비 완료를 구분한다. 외부 서비스나 비밀키가 없으면 작동하지 않는 경로가 핵심 기능에 숨어 있지 않은지 확인한다.
3. **정확성:** 과제에 영향이 큰 정상 사례, 경계 사례, 잘못된 입력을 골라 기대 결과와 대조한다. 데이터라면 집계 기준·단위·결측·중복·날짜 경계를 우선한다. 모델 과제라면 분할·누수·기준선·지표의 의미를 확인한다.
4. **설명과 증거:** 핵심 주장마다 실제 파일 위치나 관찰 결과가 있는지 확인한다. 실행하지 않은 테스트는 미실행, 실패는 실패, 가정은 가정으로 남긴다. 테스트 개수보다 어떤 실패를 잡는지가 중요하다.

프로젝트의 적절한 기존 검사부터 실행한다. UI를 자동으로 조작하는 검사는 실행하지 않고, 가능한 순수 로직·서버 단위 검사와 참가자의 수동 점검으로 나눈다. 작업과 무관한 광범위한 검사나 대규모 의존성 설치로 제출 시간을 소모하지 않는다.

반복 개선 요청에서는 참가자가 원한 품질 기준도 실제 결과와 대조한다. 테스트 통과와 가독성·사용성 만족은 별개다. 관련 실패를 수정한 뒤 같은 사례와 영향을 받는 기존 동작을 다시 확인하고, 다음으로 중요한 미충족 기준이 있으면 같은 작업을 이어간다. 변경·새 위험·실패 없이 검사 횟수만 늘리지 않는다. 수동 화면 확인은 확인할 행동과 기대 결과를 짧게 전달하고 실제 피드백 전에는 미확인으로 둔다.

핵심 결과의 기대값은 요구사항·작은 손계산·독립된 기준에서 먼저 정한다. 잘못된 실제 출력에 맞춰 기대값을 바꾸지 않는다. 수정 효과를 비교할 때는 입력·기준을 유지하고 전후의 실패와 개선을 함께 확인한다. 기준 자체가 잘못됐다면 변경 이유와 근거를 따로 남긴다.

기존 코드 수정이면 변경 전 실패와 수정 후 결과를 연결하고, 유지할 API·함수 계약과 관련 정상 동작도 확인한다. 테스트의 실제 실행 개수·실패·skip을 읽는다. 종료코드 0, 대역 테스트, 키트의 구조 검사만으로 전체 기능이나 실제 외부 통합 성공을 주장하지 않는다.

**검증 결과가 현재 파일에 해당하는지 확인한다.** 마지막 검사 뒤 영향받는 코드·입력·설정이 바뀌거나 병렬 수정이 통합됐다면 관련 검사를 다시 실행한다. 예전 로그를 현재 결과의 증거로 재사용하지 않는다. 기존에 키트 실행 기록을 쓰고 있고 선택한 파일을 추적하려면 [검증 기록과 파일 비교](references/evidence.md)를 읽는다. 추적하지 않은 파일·외부 환경까지 자동으로 검증하지는 않는다.

## Browser를 쓰는 결과물

실제 서버가 준비됐고 `0.0.0.0`에 바인딩되는지 확인한다. 참가자가 플랫폼 Browser의 실제 포트·경로를 맞추고 핵심 버튼·입력·이동·오류 상황을 직접 점검하도록 짧은 순서를 제공한다. 서버 터미널을 유지하도록 안내한다. 사람이 확인하지 않은 화면은 확인됐다고 기록하지 않는다. 외부 터널, Computer Use, Playwright·Selenium·브라우저 MCP 조작은 이 키트의 확인 경로에 포함하지 않는다.

## 결과 전달

먼저 **무엇을 확인했는지 → 왜 그 검사가 필요한지 → 어떻게 확인했는지 → 실제 결과·미확인**을 쉬운 말로 짧게 요약한다. 오류를 고쳤으면 변경 이유와 방법도 포함한다. 아래 상세 구분은 요약 뒤에 필요한 항목만 덧붙이며 긴 표를 기본으로 강제하지 않는다.

아래를 구분해 간결하게 보고한다.

- **제출 전 수정 필요:** 필수조건 실패, 실행 불가, 잘못된 결과, 누락된 파일.
- **확인됨:** 요구사항, 실행한 방법, 실제 관찰, 증거 위치.
- **아직 확인 안 됨:** 이유와 남은 확인법. 시간이 없으면 한계에 명시한다.

수정은 남은 시간에 맞는 최소 범위로 적용하고 관련된 검사만 다시 수행한다. 증거를 채우기 위해 로그·수치·테스트 성공을 만들어내지 않는다.

작업 내역의 구현·AI 활용 요약이 있으면 현재 파일·실제 실행 기록과 대조한다. 마지막 수정 전 검사와 미확인 수동 점검을 현재 성공으로 기록하지 않고, 완료·실패·미검증 상태를 맞춘다. 참가자의 판단이나 AI 기여는 확인 가능한 대화·기록이 없으면 추정하지 않는다.

## 제출 확인은 참가자가 직접

에디터의 저장·충돌 상태와 필수 파일 경로를 확인하도록 안내한다. 공식 가이드는 작업 종료 10분 전부터 제출을 시작하도록 권장한다. 제출 미리보기는 전체 파일 목록이 아닐 수 있다. 제출물 확정 후 수정이 불가능하며, 확정 버튼을 AI가 조작하지 않는다.

11월 4일 안내의 전체 제출 용량은 10GB 이하다. 키트 CLI가 실제로 있으면 선택형 `submission-check --workspace .`로 숨김 파일을 포함한 디스크 용량·실제 필수 경로를 확인할 수 있다. 설치된 스킬만 있다면 CLI가 있다고 가정하지 말고 기존 로컬 도구를 쓴다. 링크·읽기 오류·한도 때문에 미완료인 집계를 성공으로 바꾸지 않는다. 파일 존재·용량은 내용 정확성, 미저장 에디터, 플랫폼의 실제 제출 파일 집합을 검증하지 않는다. 큰 파일을 자동 삭제하지 않는다.

사람에게 안내할 순서는 `저장됨 확인 → 제출하고 문제풀기 → 미리보기 → 제출물 확정하고 문제풀기`다. 수정이 필요하면 미리보기를 닫게 한다. 마지막 서술형의 `답안 제출하고 마치기` 이후 처리·업로드를 기다리고 `과제가 잘 제출됐어요.` 표시까지 확인한다. 작업 확정·서술형 완료·최종 업로드 완료를 구분한다.

후속 서술형에서는 AI와 복사·붙여넣기가 금지된다. 최종 완료는 서술형과 업로드까지 마친 뒤 완료 화면의 제출 ID·시각·파일 수·크기를 확인하는 단계다. AI에게 실제 후속 문항의 답을 요청하도록 안내하지 않는다.

근거: 「1_시험_필수확인사항_브리프」 p.1(Computer Use·후속 서술형), 「3_사전_체험_및_응시환경_상세_가이드」 p.3(Browser·저장·제출), p.4(확정과 완료). 브라우저 자동 테스트를 쓰지 않는 것은 도구별 허용 여부가 불명확한 데 대한 이 키트의 보수적 선택이다.