에이전트가 구축한 앱의 라이브 URL 수락 검사

무해한 쓰기 작업, 새로고침 후 읽기 작업, 그리고 접근 제어 확인을 통해 배포된 URL에서 에이전트가 구축한 앱을 검증합니다. 모든 실패 사례는 동일 간격의 서비스 로그 및 리소스 메트릭과 함께 기록해야 합니다.

저희는 Lizard (lizard.build) 팀입니다. 지난 10월 8일 발표에서는 터미널 또는 GitHub를 통한 배포, 관리형 서비스, 그리고 라이브 관측 가능성(live observability)에 대해 설명했습니다.

배포 경로를 명시적으로 유지하세요. lizard up은 로컬 코드를 업로드하며, 기존의 GitHub와 연결된 앱은 해당 리포지토리 배포 워크플로우를 따르는 것이 좋습니다. 동작을 진단하기 전에 배포된 버전을 기록해야 합니다.

데이터베이스 기반 앱의 경우, Managed Postgres를 명시적으로 프로비저닝하고 소비하는 서비스에 연결하세요. 문서화된 프로비저닝 명령어는 lizard add postgres입니다. 애플리케이션 구성 및 마이그레이션은 별도의 작업입니다. 성공적인 배포가 작동하는 연결을 의미하지는 않습니다.

가상의 이슈 트래커의 경우, 실제 URL에 폐기 가능한(disposable) 이슈를 생성하고, 새로고침한 다음, 다른 계정에서 비공개 이슈를 읽을 수 없는지 확인합니다. 이는 주장된 테스트 결과가 아닌 제안된 수락 단계입니다.

실패 시에는 자격 증명이나 개인 데이터 없이 요청 시간, 예상 동작, 관찰 결과를 기록하세요. 해당 서비스 로그를 검사하고, 리소스 압박 징후를 비교하는 메트릭을 확인합니다. 에이전트에게 그 증거로 정당화된 변경 사항을 요청한 다음, 실패했던 단계를 반복합니다. 비밀 정보, 권한 부여(authorization), 그리고 복구 결정에 대해서는 항상 사람이 책임지도록 하세요.

10월 8일 발표 · Lizard 문서 · Lizard 탐색하기