코덱스에서 현재 작업공간을 확인한 뒤, 내가 지정하는 AI비서 작업공간에 4주차용 OSMU 스레드 자동 발행 스킬을 설치해줘.

[역할 구분]
- 코덱스: 대상 AI비서의 파일과 스킬을 설치하고, Threads API 연결 상태를 진단하고, DRY_RUN을 검증하는 설치기다.
- 사용자: Meta 로그인·앱 생성·OAuth 권한 승인과 실제 게시·예약 활성화를 직접 승인한다.
- 대상 AI비서: 설치가 완료된 뒤 정본·피드백을 읽고 콘텐츠를 생성·검수·예약·발행·검증하는 운영자다.

[최종 목표]
- 스킬명은 osmu-autopublish로 통일한다.
- 코덱스가 설치 대상 AI비서의 작업공간을 확정하고, 그 곳에만 스킬·발행기·상태 구조를 만든다.
- 정본 → 콘텐츠 선택 → 검수 → 예약 → 발행 → 공개 검증 → 피드백 반영을 한 흐름으로 만든다.
- 이번 설치 채널은 스레드 하나로 고정한다. 파일 구조만 만들고 끝내지 말고, Meta 앱·OAuth·토큰·계정 확인·테스트 게시까지 연결 마법사로 진행한다.
- 설치 완료와 실제 자동 발행 활성화를 구분한다.

[먼저 질문]
아직 파일을 만들지 말고 아래 내용을 최대 5개 질문으로 한 번에 물어라.
1. 설치할 AI비서 이름, 그 AI비서의 작업공간 루트 경로, 운영체제는 무엇인가? 코덱스의 현재 폴더와 다르면 반드시 절대경로를 받아라.
2. 자동화할 사업·제품·콘텐츠 시리즈와 정본노트 위치는 어디인가?
3. 자동 발행할 Threads 계정의 username은 무엇이며 Meta 개발자 앱을 만든 적이 있는가?
4. 스레드 수동 발행·수정·피드백 기록이 있는가? 있다면 위치는 어디인가?
5. 게시 요일·시간·최대 횟수, 예상 계정명, 반드시 멈춰야 할 조건은 무엇인가?

[기존 구조 확인]
답을 받은 뒤 다음을 확인하고 유지할 파일, 새로 만들 파일, 건드리지 않을 파일을 먼저 제안하라.
0. 코덱스의 현재 작업공간과 설치 대상 AI비서 작업공간이 서로 다른지 확인하라.
1. 작업공간의 AGENTS.md 또는 운영 규칙
2. 기존 OSMU·콘텐츠 생성 스킬
3. 정본노트·채널 규칙·피드백 기록
4. 현재 AI비서가 스킬을 발견하는 실제 설치 경로
5. 비밀값을 저장할 저장소 밖 경로 또는 운영체제 보안 저장소

[2·3주차 결과물 가져오기]
- 대상 작업공간에서 2주차 정본 노트와 3주차 수동 발행 기록을 먼저 찾아라. 파일명이 다르더라도 내용과 링크 관계로 식별하라.
- 2주차에서 가져올 것: 사업·시리즈 ID, 고객, 핵심 메시지, 사실·금지선, 채널 레퍼런스, 정본 버전.
- 3주차에서 가져올 것: AI 초안, 사용자가 고친 최종본, 수정 이유, 수동 발행 URL·시각, 사용자 피드백.
- 찾은 자료와 찾지 못한 자료를 표로 보여주고 사용자 확인을 받은 뒤 자동화 파일로 옮겨라.
- 3주차에 이미 발행한 본문은 `PUBLISHED_MANUAL`로 기록하고 READY 풀에 다시 넣지 마라.
- 정본 노트가 없으면 `BLOCKED_CANONICAL`, 수동 발행·수정·피드백 기록이 없으면 `BLOCKED_MANUAL_BASELINE`으로 멈춰라. 추측으로 채우지 마라.
- 가져온 원본 파일은 수정하지 말고, `config.md`, `content-pool.json`, `feedback-rules.md`, `history.json`에는 출처 경로와 버전만 남겨 추적 가능하게 하라.

[코덱스의 설치 작업]
- 대상 작업공간의 AGENTS.md와 기존 스킬 지침을 먼저 읽어라.
- 기존 파일을 보존하고 대상 작업공간 밖을 수정하지 마라.
- `osmu-autopublish/SKILL.md`, 필요한 `references/`, `scripts/threads_api_publisher.py`, 시리즈별 `automation/` 상태 구조를 대상 AI비서가 발견하는 실제 경로에 설치하라.
- 스킬 메타데이터를 검증하고, 스크립트는 외부 게시 없는 명령과 DRY_RUN으로 테스트하라.
- 설치 후 대상 AI비서가 어떤 스킬을 어떤 명령으로 실행하는지 인수인계 문장을 남겨라.
- Meta 로그인·비밀번호·OTP·앱 생성·OAuth 승인은 사용자가 직접 하게 하고, 코덱스는 화면별 다음 행동과 검증 결과를 안내하라.

[공통 설치 구조]
<AI비서 작업공간>/automation/<series-id>/<channel>/
├── config.md
├── content-pool.json
├── feedback-rules.md
├── history.json
├── state.json
└── runs/

config.md에는 실제 비밀값을 쓰지 말고 아래 항목만 기록하라.
- series_id
- channel
- canonical_version
- schedule
- max_posts_per_day
- expected_username
- stop_conditions
- credential_source: 환경 변수 이름 또는 보안 저장소 이름
- live_publish_approved: false

[설치 상태]
진행 상태를 아래 값 중 하나로 기록하고, 통과하지 않은 단계를 건너뛰지 마라.
1. SCAFFOLD_READY
2. META_APP_READY
3. OAUTH_READY
4. TOKEN_STORED
5. IDENTITY_PASS
6. DRY_RUN_PASS
7. TEST_PUBLISH_VERIFIED
8. SCHEDULE_READY

[Threads API 연결 마법사]
이번 실습은 스레드만 설치한다. 아래 순서로 사용자와 한 단계씩 진행하라.

1단계 · 공식 사양 확인
- 설치 당일 Meta의 공식 Threads API 개발자 문서 또는 Meta 공식 Postman 컬렉션을 확인하라.
- 공식 자료에 없는 엔드포인트·권한·응답값을 추측하지 마라.
- 확인 날짜와 공식 URL을 설치 기록에 남겨라.

2단계 · Meta 앱 준비
- 사용자에게 Meta for Developers에서 Threads 사용 사례가 포함된 앱을 새로 만들거나 기존 앱을 선택하게 하라.
- Threads App ID와 App Secret을 채팅에 붙여넣게 하지 마라.
- Threads 설정에서 정확한 OAuth Redirect URI를 등록하게 하라.
- 개발 모드라면 발행할 Threads 계정이 앱을 승인할 수 있는 역할·테스터 상태인지 화면에서 확인하게 하라.
- 최소 권한은 threads_basic, threads_content_publish로 시작하라. 답글·인사이트·삭제 기능은 실제 필요할 때만 별도로 추가하라.
- 각 항목을 사용자가 확인하기 전에는 META_APP_READY로 올리지 마라.

3단계 · OAuth 방식 선택
- 아래 중 하나를 사용자에게 선택하게 하라.
  A. Meta 공식 Postman 컬렉션으로 Authorization Code 발급
  B. 현재 작업공간에 로컬 OAuth callback helper 생성
- Postman 방식이면 Grant Type, Callback URL, Auth URL, Access Token URL, Client ID, Client Secret, Scope가 모두 필요하다고 안내하라.
- 현재 공식 문서에서 값을 다시 확인하되 기본 API 호스트는 https://graph.threads.net 이다.
- 인증 URL은 현재 공식 문서에서 확인한 Threads OAuth authorize endpoint를 사용하라.
- 토큰 교환은 POST /oauth/access_token에 client_id, client_secret, code, grant_type=authorization_code, redirect_uri를 사용한다.
- redirect_uri는 승인 요청과 토큰 교환에서 완전히 같아야 한다.
- state 값을 생성·검증해 다른 세션의 authorization code를 받지 않게 하라.
- 사용자가 브라우저에서 직접 로그인하고 권한을 승인하게 하라. 비밀번호·OTP를 대신 받지 마라.

4단계 · 토큰 교환과 장기 토큰
- authorization code를 짧은 수명의 Threads User Access Token으로 교환하라.
- 필요하면 공식 절차의 GET /access_token, grant_type=th_exchange_token을 사용해 장기 토큰으로 교환하라.
- 실제 토큰과 App Secret은 저장소 밖 .env, 권한 600 파일, 운영체제 키체인 중 현재 환경에 맞는 한 곳에만 저장하라.
- 저장소에는 .env.example만 만들고 변수 이름만 기록하라.
  THREADS_ACCESS_TOKEN=
  THREADS_EXPECTED_USERNAME=
  THREADS_API_BASE=https://graph.threads.net
- 비밀값을 출력·로그·Markdown·Git·state.json에 남기지 마라.
- 토큰 저장 뒤 파일 권한과 Git 제외 여부를 확인하라.

5단계 · 실제 API 클라이언트 생성
- scripts/threads_api_publisher.py를 만들고 최소한 아래 명령을 구현하라.
  identity: GET /me?fields=id,username,name
  create-text: POST /me/threads with media_type=TEXT and text
  publish: POST /me/threads_publish with creation_id
  details: GET /<published-id>?fields=id,permalink,username,text,timestamp
  refresh-token: 공식 refresh_access_token 절차
- Authorization: Bearer 헤더로 토큰을 전송하라.
- HTTP 오류를 토큰이 제거된 상태로 보고하라.
- container_id와 published_id를 즉시 state.json에 저장해 재시도 때 중복 게시하지 않게 하라.
- 같은 본문 해시, RESERVED 상태, 기존 published_id가 있으면 새 컨테이너를 만들지 마라.

6단계 · 계정 확인
- THREADS_ACCESS_TOKEN을 읽어 identity를 실행하라.
- 반환 username이 사용자가 지정한 expected_username과 정확히 일치해야 한다.
- 권한·만료 상태를 Access Token Debugger 또는 공식 API 결과로 확인하게 하라.
- 토큰 누락, 권한 부족, 만료, 계정 불일치면 BLOCKED_THREADS_API_AUTH 또는 BLOCKED_IDENTITY로 멈춰라.
- 브라우저 UI 게시로 우회하지 마라.

7단계 · DRY_RUN
- 외부 API의 게시 엔드포인트를 호출하지 말고 정본 읽기, 콘텐츠 선택, 중복 검사, 사실·개인정보·말투 검수, 상태 전이만 시험하라.
- DRY_RUN 결과에는 사용할 계정명, 본문 해시, 호출 예정 엔드포인트, 중지 조건만 보여주고 토큰은 보여주지 마라.

8단계 · 테스트 게시
- 사용자의 명시적 승인을 받은 뒤에만 테스트 본문 1개를 게시하라.
- 게시 직전에 계정명과 정확한 테스트 본문을 다시 보여주고 최종 승인을 받아라.
- 컨테이너 생성 → 컨테이너 ID 저장 → 게시 → 게시 ID 저장 → details 재조회 순서로 실행하라.
- details의 username과 text가 예상값과 일치하고 permalink가 확인될 때만 TEST_PUBLISH_VERIFIED로 기록하라.
- 검증 실패 시 새 테스트 글을 만들지 말고 저장된 ID로 재조회하라.
- 삭제 권한이 없다면 자동 삭제를 약속하지 말고, 사용자가 공개 글을 유지하거나 직접 삭제하도록 안내하라.

9단계 · 토큰 갱신과 예약 발행
- 장기 토큰의 만료 시각을 비밀값 없이 기록하라.
- 공식 refresh_access_token 절차를 사용하는 갱신 명령과 만료 전 알림을 준비하라.
- TEST_PUBLISH_VERIFIED 전에는 예약 발행을 만들지 마라.
- 예약 작업은 정본, 피드백 규칙, READY 콘텐츠, 계정 identity를 매번 다시 읽게 하라.
- 공개 URL 검증 실패, 연속 오류, 중복, 개인정보, 계정 불일치가 발생하면 자동 일시정지하라.

[피드백 반영]
1. 발행 URL과 함께 좋음 / 일부만 좋음 / 별로 / 보류를 묻는다.
2. 왜 그렇게 평가했는지 한 문장으로 묻는다.
3. 사실 오류·개인정보·위험은 즉시 중지 규칙으로 반영한다.
4. 취향 피드백은 다음 생성부터 적용하고 applied_feedback_ids를 남긴다.
5. 반응 기반 규칙은 비교 가능한 게시물 3개 이상에서 반복될 때만 기본값 승격을 제안한다.
6. 다음 콘텐츠를 만들 때 적용한 2주차 정본 버전, 3주차 기준 게시물, 피드백 ID를 기록하고 무엇이 달라졌는지 전후 한 줄 비교를 남긴다.

[최종 완료 조건]
- 파일을 만들었다고 설치 완료라고 말하지 마라.
- 스레드는 META_APP_READY, OAUTH_READY, TOKEN_STORED, IDENTITY_PASS, DRY_RUN_PASS가 확인돼야 “API 연결 준비 완료”다.
- 실제 테스트 게시를 승인받은 경우에만 TEST_PUBLISH_VERIFIED까지 진행한다.
- 자동 예약은 TEST_PUBLISH_VERIFIED 이후 별도 승인으로 SCHEDULE_READY가 된 뒤에만 켠다.
- 매 단계가 끝날 때 현재 상태, 확인 증거, 막힌 조건, 사용자에게 필요한 다음 행동 한 가지만 보고하라.
- 완료 보고에 `코덱스 설치 완료 / AI비서 운영 준비 완료 / 실제 게시 비활성` 여부를 따로 표시하라.