리서치 팀에 팀원 2명을 추가하고, 기존 팀원 하나의 역할을 넓히고 싶어.

[새 하위 에이전트 2개] .codex/agents/ 폴더에 TOML 파일로 만들어 줘. 각 파일에 name, description, developer_instructions를 넣어 줘.
- designer.toml: model = "gpt-6-sol", model_reasoning_effort = "medium"
  웹 도구의 화면 디자인 안을 글로 쓴다. 코드는 쓰지 않는다.
  디자인 안에는 화면 배치, 색과 글꼴, 상태별 표시(충족/미충족/확인 불가/참고), 버튼과 안내 문구의 말투, 모바일 화면 처리를 적는다.
  처음 보는 마케터가 설명 없이 쓸 수 있게, 간결하고 읽기 쉬운 화면을 기본으로 한다.
  레퍼런스 사이트나 이미지를 받으면 분위기와 구성만 참고하고, 로고·이미지·문구는 그대로 가져오지 않는다.
- builder.toml: model = "gpt-6.1-sol", model_reasoning_effort = "high"
  디자인 안(design.md)과 점검 기준표(criteria.md)대로 웹 도구를 만든다.
  기준표에 없는 판정, 점수, 효과 주장은 넣지 않는다. 외부 라이브러리는 쓰지 않는다. 배포는 하지 않는다.
  URL을 대신 가져오는 서버 기능을 만들 때는 반드시 아래 안전 규칙을 지킨다.
  · 한 번에 URL 하나, http와 https만 허용
  · 10초 안에 응답이 없으면 중단
  · localhost와 내부망 주소는 거부
  · 가져온 내용은 저장하지 않음
  · 상대 사이트가 막으면(403 등) 오류가 아니라 "확인 불가"로 돌려줌

[reviewer 역할 추가] reviewer.toml의 developer_instructions에 아래 두 가지 검토를 추가해 줘. 읽기 전용 설정은 그대로 둬.
1. 점검 기준표의 각 항목이 근거 출처와 맞는지, 공식 안내와 업계 제안이 구분됐는지
2. 만든 도구가 기준표에 없는 판정, 점수, 효과 주장을 하지 않는지, 안전 규칙을 지키는지

[AGENTS.md] 기존 리서치 순서는 그대로 두고, "점검 도구 만들기 순서"를 새로 추가해 줘.
1) 보충 리서치가 필요한 항목을 정해 researcher에게 맡긴다 (최대 3개)
2) analyst가 점검 기준표를 만든다
3) designer가 디자인 안을 쓴다
4) builder가 도구를 만든다
5) reviewer가 검토하고, 지적 목록을 메인이 research/review-notes-5-2.md에 저장한 뒤 builder가 반영한다
6) 마지막에 에이전트별로 맡은 일, 사용한 모델, 한 일을 표로 알려 준다
배포는 내가 "배포 승인"이라고 말하기 전에는 하지 않는다.

새 팀원 지침에도 기존 작업 규칙 6개를 넣어 줘.
지정한 모델 중 쓸 수 없는 것이 있으면 쓸 수 있는 모델로 바꾸고 알려 줘.
파일을 만들거나 고치기 전에 무엇을 바꿀지 먼저 목록으로 보여 주고 내 확인을 받아.

AGENTS.md의 "점검 도구 만들기 순서"대로 에이전트 팀으로 GEO 점검 대시보드를 만들어 줘.
재료는 research/research-1-2.md야.

[1. 보충 리서치] research-1-2.md에서 점검 기준을 만들기에 부족한 내용을 공식 문서로 보충해 줘. 결과는 research/research-5-2-gap.md.
아래 후보는 공식 근거를 확인한 것만 판정 항목으로 쓰고, 공식 근거가 없으면 "참고(업계 제안)"로 분류해.
- 검색 노출용 로봇의 robots.txt 허용 여부: OAI-SearchBot(ChatGPT), PerplexityBot, Googlebot, Claude-SearchBot, Yeti(네이버)
- 학습용 로봇(GPTBot, Google-Extended, ClaudeBot): 검색 노출과 별개인지 확인하고, 판정하지 않고 "참고"로만 보여 줄 것
- 페이지의 noindex, nosnippet, max-snippet 설정
- 구조화 데이터(JSON-LD) 유무 (내용이 화면과 맞는지는 사람이 확인하도록 안내)
- robots.txt의 사이트맵 표기
- 네이버 AI 브리핑 관련 공식 안내가 있는지
- llms.txt (공식 안내가 없으면 "참고(업계 제안)")

[2. 점검 기준표] site/criteria.md에 항목마다 정리해 줘.
항목 / 무엇을 확인하나 / 판정 방법(충족·미충족·확인 불가 조건) / 근거 출처와 확인일 / 공식 안내 또는 업계 제안 / 미충족일 때 고치는 방법

[3. 디자인 안] site/design.md

[4. 대시보드] site/ 폴더
- index.html: 화면
- api/check.js: URL을 받아 robots.txt와 페이지 HTML을 대신 가져오는 Vercel 서버 기능
화면에 꼭 들어갈 것:
- URL 입력칸과 점검 버튼
- URL 점검이 안 될 때를 위한 "직접 붙여 넣기"(robots.txt 내용, 페이지 HTML)
- 맨 위 판정 요약(충족 몇 개, 미충족 몇 개). 점수는 만들지 마
- 항목별 결과 카드: 판정, 고치는 방법, 근거 링크
- 하단 안내: "AI 검색 노출을 보장하지 않는 준비 상태 점검입니다. 기준 확인일: {날짜}. 수업 실습용으로 AI가 공개 자료를 정리했습니다."
- 한국어, 모바일에서도 보기 좋게

[5. 검토] reviewer

@vercel 로 site 폴더를 공개하려고 해.
수업 친구들이 로그인 없이 볼 수 있도록 정식(production) 배포를 할 거야.
배포하기 전에 프로젝트 이름, 배포할 폴더, 공개 범위를 먼저 보여 줘.
화면이 동작하는 데 필요한 파일만 올리고, criteria.md·design.md 같은 작업 문서와 테스트용 파일은 올리지 마.
내가 "배포 승인"이라고 말하기 전에는 배포하지 마.

공개한 대시보드에서 URL 점검으로 사이트 3곳을 점검해 봐 줘.
잘 알려진 대형 사이트 1곳, 공공기관 사이트 1곳, 그리고 점검이 막힐 만한 사이트 1곳으로 골라.
결과가 criteria.md 기준대로 나오는지, 막힌 경우 "확인 불가"로 제대로 표시되는지 확인해 줘.
고칠 게 있으면 무엇을 고칠지 먼저 보여 주고, 내가 승인하면 고친 뒤 같은 프로젝트로 다시 배포해 줘.