운영과 검증

이 가이드는 위에 고정된 원본에서 발행됩니다. 영어 정본을 한국어로 완역했으며, 명령 구문과 출시 상태 경계, 기능 한계, 원본 hash는 그대로 보존합니다.

그림은 사이트를 빌드할 때 정적 이미지로 그려집니다. 같은 흐름을 각 그림 아래에 글로도 적어 두므로, 어떤 스크립트에도 의존하지 않습니다.

Virgo의 운영 증거는 실제 작업이 지나가는 경로를 그대로 따라가야 합니다. 설치된 바이트와 실제 프로세스에서 시작해, 프로토콜, 권한, 지속 상태, 수신 대화를 차례로 검증합니다. 이 아래에서 위로의 점검은 변경을 계획할 때 쓰는 요구사항·승인 사례를 보완합니다.

올바른 상태를 읽기

관찰	그것이 입증하는 것
설치된 아티팩트와 설정	어떤 릴리스와 설정이 선택되었는지
정확한 프로세스 관찰	어느 프로세스가 돌고 있으며 Virgo가 그것을 소유하는지
프로토콜 상태	그 서비스가 기대한 프로토콜로 응답하는지
Seat 상태	인증된 호출자의 binding과 보고된 전달 상태
커밋된 메시지	지속적으로 제출되었다는 사실. 수신자는 아직 없을 수 있음
네이티브 수신·회신 증거	그 조작이 실제 provider 대화에 도달했다는 사실

설치 프로그램이 반환한 정확한 설치 디렉터리를 사용하세요. 이미 설정된 설치본에 대해 CLI는 다음을 제공합니다.

"$VIRGO_BIN" --directory "$VIRGO_INSTALLATION" hub address --network local

"$VIRGO_BIN" --directory "$VIRGO_INSTALLATION" installation inspect \
  --machine "$VIRGO_MACHINE" --component agent_host --instance local-hub

여기서 VIRGO_BIN, VIRGO_MACHINE, VIRGO_INSTALLATION은 검증된 CLI, 대상 머신, 반환된 설치 디렉터리를 가리킵니다. Hub 주소 확인은 호출하는 머신에서 본 설정 주소를 점검합니다. 설치 확인은 지속된 설치 상태를 읽으며, 새로운 네이티브 전달 시험이 아닙니다.

status 조작은 Seat 조작입니다. 설정된 인증 호출자가 필요하며, 막 설치되어 비어 있는 Hub가 살아 있는지 확인하는 일반 시험이 아닙니다. 런타임의 엔드포인트 영수증이 실제 /health 주소를 알려 줍니다.

명시한 인스턴스를 업데이트하고 복구하기

현재 preview CLI는 선택한 인스턴스 하나를 prepare, apply, activate 순으로 업그레이드합니다. 모든 Host를 한 번에 업데이트하지 않습니다.

"$VIRGO_BIN" upgrade \
  --root "$VIRGO_ROOT" \
  --release "$VIRGO_NEW_RELEASE" \
  --machine "$VIRGO_MACHINE" \
  --instance local-hub \
  --manifest-directory "$VIRGO_MANIFESTS"

VIRGO_NEW_RELEASE에는 승인된 정확한 릴리스를 넣고, 의도한 대상에 맞는 인스턴스를 쓰세요. 그 preimage와 적용된 계획 영수증을 보존하세요. 업데이트는 Seat/세션 정체성, 이력, 보내지 않은 초안, 해결되지 않은 효과를 보존해야 합니다.

롤백은 임의의 이전 릴리스가 아니라 저장된 정확한 계획을 선택합니다.

"$VIRGO_BIN" rollback \
  --root "$VIRGO_ROOT" \
  --machine "$VIRGO_MACHINE" \
  --plan-id "$VIRGO_APPLIED_PLAN" \
  --manifest-directory "$VIRGO_MANIFESTS"

VIRGO_APPLIED_PLAN은 의도한 변경에 대해 보관해 둔 계획 id입니다. 현재 preview에서 이 명령은 실행을 멈추고 이전 파일과 설정을 복원합니다. 복원된 서비스를 다시 활성화하지는 않습니다. 보고된 설치 상태가 active라고 해서 프로세스가 돌고 있다는 뜻으로 읽어서는 안 됩니다. 재활성화에는 지원되는 설치 수명주기와 새로운 프로세스·상태 검증이 필요하며, 이 스냅숏에는 공개 installation activate 명령이 없습니다.

자동 외부 복구와 Host 간 업데이트 수렴은 구현 중입니다. 복구는 의도적 중지, 준비된 업그레이드, 소유자를 알 수 없는 프로세스, 실제 서비스 장애를 구분해야 합니다. 결과를 알 수 없는 메시지는 실패한 것처럼 재전송하지 말고 그대로 보존해야 합니다.

통합 기능을 진입점에서 검증하기

기능	아래에서 위로의 경로	필요한 최종 관찰
Ponytail	설치된 훅/프로필 → provider 수명주기 이벤트 → 인코딩된 맥락 → 실제 대화	그 세션이 기대한 지침을 받고, Virgo의 우선순위가 보존됨
Memory	provider 이벤트 → 인증된 Host 큐 → Hub가 인가한 원본 → 자동 파생 자격 → 요약 → 복원	이어지는 대화가 허용된 원본에서 파생된 맥락을 받음
Graphify	선택된 저장소 → 필터링된 스냅숏 → 고정된 엔진 → 검증된 결과 → 공용 색인 → 인가된 질의	질의가 정확한 저장소 리비전에 대해 출처가 연결된 관계를 반환함
대화 라우팅	검증된 사람의 메시지 → 선택·인가 → 지속적 수신자 트랜잭션 → 네이티브 전달 → 상관된 회신	회신이 정확히 원래의 채팅 대화와 thread/topic에 도달함
Host 복구	정확히 설치된 프로세스 → 외부 장애 탐지 → 범위를 한정한 복구 → 프로토콜/네이티브 승인	같은 논리적 작업이 재개되고, 독립적인 경보 목적지가 실제 알림을 받음

의도된 경로와 경계별 실패를 함께 확인하세요. 낡은 attachment, 장애, 재시도, 제외된 파일, 인가되지 않은 요청자, 지원되지 않는 provider 동작이 그것입니다. 소스 테스트, 격리된 설치 테스트, 실제 provider 관찰은 구분해서 두세요.

자기 파생 작업을 직접 넣는 테스트는 캡처된 이벤트가 작업을 만든다는 것을 증명할 수 없습니다. 손으로 실행한 훅은 provider가 그 훅을 호출한다는 것을 증명할 수 없습니다. fixture로 메시지를 확인 처리하는 것은 사용자의 네이티브 대화가 그것을 받았다는 것을 증명할 수 없습니다. 증명되지 않은 연결과 그 승인 조건을 기록해, 초록색 컴포넌트 테스트가 빠진 통합을 가리지 못하게 하세요.

소비자별로 준비 상태를 보고하기

영향받는 Host와 provider 세션마다 결과를 기록하세요. 파일럿 한 건의 성공이 모든 Seat을 입증하지는 않습니다. rollout 중에는 적용됨, 검증됨, 막힘을 따로 보고하고, 완료되지 않은 소비자마다 정확한 blocker를 함께 적으세요.

서비스 자신의 상태 엔드포인트가 그 서비스가 사라졌음을 알아채는 유일한 수단이어서는 안 됩니다. 독립적인 장애 탐지와 실제로 전달되는 소유자 알림은 요구되는 운영 결과의 일부로 남습니다.