ECC Tools 비용 감사
이 스킬은 사용자가 ECC Tools GitHub App이 비용을 소모하고, PR을 과도하게 생성하며, 사용량 제한을 우회하거나, 무료 사용자를 프리미엄 분석 경로로 라우팅하고 있다고 의심될 때 사용합니다.
이것은 형제 ECC-Tools 저장소를 위한 집중된 운영자 워크플로우입니다. 일반적인 결제 스킬이나 저장소 전체 코드 리뷰 패스가 아닙니다.
스킬 스택
필요에 따라 다음 ECC 기본 스킬을 워크플로우에 통합하세요:
autonomous-loops: 웹훅, 큐, 결제, 재시도를 교차하는 제한된 다단계 감사용agentic-engineering: 요청 경로를 분리 가능하고 증명 가능한 단위로 추적용customer-billing-ops: 저장소 동작과 고객 영향 수학을 깔끔하게 분리해야 할 때search-first: 도우미를 새로 만들거나 저장소 로컬 유틸리티를 다시 구현하기 전에security-review: 인증, 사용량 게이트, 권한, 비밀번호가 관련될 때verification-loop: 재실행 안전성과 정확한 수정 후 상태 증명용tdd-workflow: 수정 사항에 워커, 라우터, 결제 경로의 회귀 테스트가 필요할 때
사용 시기
- 사용자가 ECC Tools 소모율, PR 재귀, 과도하게 생성된 PR, 사용량 제한 우회, 프리미엄 모델 누출을 언급할 때
- 작업이 형제
ECC-Tools저장소에 있으며 웹훅 핸들러, 큐 워커, 사용량 예약, PR 생성 로직, 유료 게이트 시행에 의존할 때 - 고객 보고서에 앱이 너무 많은 PR을 생성했거나, 잘못 청구했거나, 사용 가능한 결과를 생성하지 않고 코드를 분석했다고 나올 때
범위 가드레일
- 형제
ECC-Tools저장소에서 작업하며,everything-claude-code에서는 작업하지 않음 - 사용자가 명확히 수정을 요청하지 않는 한 읽기 전용으로 시작
- 분석 소모를 추적하는 동안 관련 없는 결제, 체크아웃, UI 흐름을 변경하지 않음
- 앱이 생성한 브랜치와 앱이 생성한 PR을 반대 증명이 있을 때까지 적색 플래그 재귀 경로로 취급
- 다음 세 가지를 명시적으로 분리:
- 저장소 측 소모 근본 원인
- 고객 대상 결제 영향
- 백로그 후속 조치가 필요한 제품 또는 권한 격차
워크플로우
1. 저장소 범위 고정
- 형제
ECC-Tools저장소로 전환 - 먼저 브랜치와 로컬 diff 확인
- 감사 대상 정확한 표면 식별:
- 웹훅 라우터
- 큐 프로듀서
- 큐 컨슈머
- PR 생성 경로
- 사용량 예약 / 결제 경로
- 모델 라우팅 경로
2. 이론화 전에 인그레스 추적
- 먼저
src/index.*또는 기본 진입점 검사 - 수정 제안 전에 모든 인큐 경로 매핑
- 어떤 GitHub 이벤트가 동일한 큐 유형을 공유하는지 확인
- push, pull_request, synchronize, comment 또는 수동 재실행 이벤트가 동일한 비용 경로로 수렴할 수 있는지 확인
3. 워커 및 부작용 추적
- 분석을 처리하는 큐 컨슈머 또는 예약 워커 검사
- 큐에 넣은 분석이 항상 다음 중 하나로 끝나는지 확인:
- PR 생성
- 브랜치 생성
- 파일 업데이트
- 프리미엄 모델 호출
- 사용량 증가
- 분석이 토큰을 소비한 후 출력이 유지되기 전에 실패할 수 있으면, 출력이 손상된 소모로 분류
4. 높은 신호 소모 경로 감사
PR 배수
- PR 도우미 및 브랜치 명명 검사
- 중복 제거, synchronize 이벤트 처리, 기존 PR 재사용 확인
- 앱 생성 브랜치가 분석에 다시 진입할 수 있으면 우선순위 0 재귀 위험으로 처리
할당량 우회
- 할당량이 확인되는 위치와 사용량이 예약되거나 증가되는 위치 검사
- 할당량이 인큐 전에 확인되지만 사용량이 워커 내에서만 청구되면, 동시 프론트도어 통과를 실제 경합 조건으로 처리
프리미엄 모델 누출
- 모델 선택, 티어 분기, 공급자 라우팅 검사
- 프리미엄 키가 있을 때 무료 또는 제한된 사용자가 여전히 프리미엄 분석기에 도달할 수 있는지 확인
재시도 소모
- 재시도 루프, 중복 큐 작업, 결정적 실패 재실행 검사
- 동일한 비일시적 오류가 분석을 반복적으로 소비할 수 있으면, 품질 개선보다 먼저 수정
5. 소모 순서로 수정
사용자가 코드 변경을 요청한 경우, 다음 순서로 수정 우선순위를 지정:
- 자동 PR 배수 중단
- 할당량 우회 중단
- 프리미엄 누출 중단
- 중복 작업 팬아웃 및 무의미한 재시도 중단
- 재실행/업데이트 안전성 격차 해소
동일한 근본 원인이 명확히 여러 파일에 걸쳐 있지 않는 한, 하나에서 세 개의 직접 수정으로 패스를 제한합니다.
6. 가장 작은 증명 단계로 검증
- 변경된 경로를 다루는 대상 테스트 또는 통합 조각만 재실행
- 소모 경로가 현재 다음 중 어떤 상태인지 확인:
- 차단됨
- 중복 제거됨
- 더 저렴한 분석으로 다운그레이드됨
- 또는 조기 거부됨
- 최종 상태를 정확히 명시:
- 로컬에서 변경됨
- 로컬에서 검증됨
- 푸시됨
- 배포됨
- 여전히 차단됨
높은 신호 실패 패턴
1. 모든 트리거에 대해 하나의 큐 유형
푸시, PR 동기화, 수동 감사가 모두 동일한 작업을 인큐하고 워커가 항상 PR을 생성하면, 분석은 PR 스팸과 같습니다.
2. 인큐 후 사용량 예약
사용량이 프론트 도어에서 확인되지만 워커에서만 증가되면, 동시 요청이 모두 게이트를 통과하여 할당량을 초과할 수 있습니다.
3. 프리미엄 경로의 무료 티어
키가 존재할 때 무료 큐 작업이 여전히 Anthropic 또는 다른 프리미엄 공급자로 라우팅될 수 있으면, 사용자가 프리미엄 결과를 보지 못하더라도 실제 지출 누출입니다.
4. 앱 생성 브랜치가 웹훅에 재진입
pull_request.synchronize, 브랜치 푸시 또는 댓글 트리거 실행이 앱 소유 브랜치에서 발생하면, 앱이 자신의 출력을 재귀적으로 분석할 수 있습니다.
5. 지속성 안전 전의 고비용 작업
시스템이 토큰을 소비한 후 PR 생성, 파일 업데이트 또는 브랜치 충돌에서 실패할 수 있으면, 가치를 제공하지 않고 비용을 소모하는 것입니다.
함정
- 광범위한 저장소 탐색으로 시작하지 말고, 웹훅 -> 큐 -> 워커를 먼저 확정
- 고객 결제 추론과 코드 기반 제품 진실을 혼합하지 않음
- 가장 높은 소모 경로가 차단되기 전에 낮은 가치의 품질 문제를 수정하지 않음
- 좁은 증명 단계가 재실행될 때까지 소모가 수정되었다고 주장하지 않음
- 사용자가 요청하지 않으면 푸시하거나 배포하지 않음
- 이미 진행 중인 관련 없는 저장소 로컬 변경 사항을 건드리지 않음
검증
- 근본 원인은 정확한 파일 경로와 코드 영역을 인용
- 수정 사항은 코드의 깔끔함이 아닌 소모 영향 순서로 정렬
- 증명 명령어의 이름이 지정됨
- 최종 상태는 로컬 변경, 검증, 푸시, 배포를 구분