이 capstone은 Telegram 형식 요청 하나를 통제된 콘텐츠 job으로 바꿉니다. Telegram에 메시지를 보내거나 WordPress를 수정하지는 않습니다. 대신 발신자 권한, 전문 역할 의존성, 재시도, 검토, 사람 승인, Git commit, 전송 결과를 모두 로컬 상태로 드러냅니다.
- 같은 update가 반복되면 기존 job으로 연결됩니다.
- 조사는 한 번 실패한 뒤 제한된 두 번째 시도에서 성공합니다.
- 명시적인 사람 승인 없이는 발행 단계가 시작되지 않습니다.
- 최종 artifact는 로컬 Git 저장소에 commit됩니다.
- 전송 결과 JSON에는
simulated가 명시됩니다.
1. Telegram을 입력 경계로 다루기
운영 Telegram Gateway에서는 숫자 user ID를 allowlist에 넣고 bot token을 Hermes profile의 비밀 저장소에 보관해야 합니다. Username은 안정적인 권한 식별자가 아닙니다. Fixture는 저장된 update를 읽고 숫자 발신자를 검사한 뒤 /article TOPIC 형식만 받으며, topic이 비어 있으면 거부합니다.
Update ID는 idempotency key 역할을 합니다. 같은 update를 다시 처리해도 card를 중복 생성하지 않고 원래 job을 반환합니다.
2. 전문 역할 graph 만들기
Orchestrator는 researcher, code verifier, Korean writer, English localizer, reviewer 역할을 만듭니다. 각 역할은 입력 작업이 끝날 때까지 의존성에 막혀 있습니다. English draft는 Korean draft 전에 시작할 수 없고, review는 localization 전에 시작할 수 없습니다.
이 fixture는 역할을 SQLite 데이터베이스 하나에 기록합니다. 실제 Hermes 환경에서는 이름 있는 profile에 역할을 배정하고 dispatcher가 각 profile을 실행합니다. Worker는 kanban_* 도구로 board를 갱신합니다.
3. Context를 잃지 않고 재시도하기
모의 researcher는 첫 시도에 일시적인 source timeout을 기록하고 두 번째 시도에서 성공합니다. 성공 전에는 하위 역할이 시작되지 않습니다. 영구적인 실패라면 설정된 한도에서 멈추고 blocked로 가야 하며 무한히 반복해서는 안 됩니다.
운영 runbook에는 이 상태를 점검하고 복구하는 방법이 담겨 있습니다. 일반 review 의견과 외부 blocker도 구분합니다.
4. Side effect 앞에 승인 두기
Review가 끝나면 job은 awaiting_approval로 이동합니다. 이때 publish()를 호출하면 ApprovalRequired가 발생합니다. approve()만 job을 approved로 바꾸며, 승인자 식별자가 artifact에 포함됩니다.
이 순서가 중요합니다. Git 생성과 전송은 승인 후에만 일어나므로 reviewer가 실수로 후보 글을 전송 결과로 바꿀 수 없습니다. 준비 단계를 다시 실행해도 승인되거나 전송된 job이 이전 상태로 돌아가지 않습니다. 로컬 commit은 주변 system 및 global Git 설정을 무시하고, 사용자 template 없이 저장소를 만들며, hook도 비활성화합니다.
5. 전체 simulation 실행하기
cd examples/chapter-12-telegram-kanban-capstone
python3 pipeline.py --workspace demo-output --input telegram-update.json
python3 pipeline.py --workspace demo-approved --input telegram-update.json --approve
python3 -m unittest discover -s tests -v첫 명령은 승인 단계에서 멈춥니다. 두 번째 명령은 별도 workspace를 사용하고 demo human approval을 적용한 뒤 Markdown artifact를 commit하고 전송 기록을 씁니다. 테스트는 권한, 중복 입력, 승인 장벽, 두 번의 조사 시도, 40자 commit ID, 목적지 chat ID를 검사합니다.
6. 실제 시스템 운영하기
운영 환경에서는 Telegram 요청이 Gateway를 통해 Hermes에 도착합니다. Orchestrator가 Kanban task를 만들고 연결하면 specialist가 구조화된 handoff를 바탕으로 작업합니다. Reviewer는 수정을 요청하거나 승인하고, 그다음 사람이 발행을 허가합니다. 전송은 Gateway를 사용하고 대상 결과를 readback한 뒤 성공 처리해야 합니다.
포함된 runbook은 시작, 점검, 복구, 정리를 다룹니다. 실제 자격 증명과 인증된 platform 응답은 저장소 밖에 보관하세요.
7. 완료가 증명하는 범위 알기
Fixture는 로컬 workflow contract를 증명합니다. 실제 Telegram 연결, provider 가용성, WordPress 권한, 공개 rendering까지 증명하지는 않습니다. 그 검사는 Git 밖에서 제공한 실제 자격 증명과 각 대상 service의 별도 readback이 필요합니다.
경계는 분명합니다. 로컬 테스트로 orchestration logic을 승인할 수 있지만, 외부 write는 대상 시스템에서 다시 읽어야 확인할 수 있습니다.
답글 남기기