코드 리뷰 대신 SPEC과 EVIDENCE 보고서 활용하기

Old Coder 스킬이 실제로 변경하는 것

Old Coder 스킬은 코드 리뷰를 문서 리뷰로 대체합니다. 코딩 에이전트는 코드를 작성하기 전에 먼저 SPEC을 작성하며, 사용자가 해당 문서를 승인해야만 구현을 시작합니다. 이후 에이전트는 gauntlet이라 불리는 고정된 자동화 검사 스택을 통해 자신의 작업을 실행하고, 정확한 명령어와 실제 수치가 담긴 EVIDENCE 보고서를 사용자에게 전달합니다. 사용자는 두 개의 문서를 읽을 뿐, diff를 직접 읽지는 않습니다.

이러한 방식은 두 문서가 기존의 diff가 가졌던 신뢰를 담보할 때만 유효합니다. SPEC은 코드가 존재하기 전에 사용자가 승인하므로, 에이전트가 이미 작성한 코드에 맞춰 내용을 조작할 수 없어 신뢰를 얻습니다. EVIDENCE 보고서는 보고서 내의 모든 수치가 사용자가 직접 실행하여 동일한 결과를 확인할 수 있는 명령어에서 도출되므로 신뢰를 얻습니다. 만약 두 부분 중 하나라도 허술해지면, 리뷰를 리뷰의 요약본으로 대체하는 꼴이 됩니다. 이는 완료된 것처럼 느껴지기 때문에 diff를 읽는 것보다 더 위험합니다.

이 스킬은 일반적인 markdown 형식이므로 Claude Code, Codex CLI, Cursor 또는 사용자가 직접 만든 루프 등 서면 지침을 따르는 모든 에이전트와 함께 사용할 수 있습니다. 이 스킬은 Ponytail lazy senior developer persona 스킬과 같은 계열에 속합니다. 파일 형식이 생소하다면 에이전트 스킬의 정의와 에이전트가 이를 로드하는 방식에서 관련 메커니즘을 확인할 수 있습니다.

SPEC은 여전히 직접 내려야 하는 결정입니다

SPEC은 코드가 존재하기 전에 작성하는 테스트 계획입니다. 기술 파일(skill file)에는 다음 네 가지 항목이 포함되어야 합니다.

• 구체적인 시나리오: 입력값, 예상 출력값, 경계 사례, 오류 사례. divide(1, 0) raises ZeroDivisionError with message X와 같이 명시해야 하며, "잘못된 입력을 처리함"과 같이 모호하게 작성해서는 안 됩니다.
• 부정적 제약 조건: 기존 테스트나 공개 API 시그니처와 같이 변경되어서는 안 되는 사항.
• 설정 계획: 모든 도구와 새로운 의존성. 각 항목마다 왜 필요한지 한 줄로 설명해야 합니다.
• 절대 파일 경로: 파일을 찾느라 시간을 낭비하지 않고 바로 열 수 있도록 명시해야 합니다.

설정 계획은 모델의 학습 데이터 차단 시점이 드러나는 부분입니다. 메모리에서 불러온 도구나 고정된 버전은 1년 이상 지난 것일 수 있으므로, 에이전트에게 웹 검색을 위한 자체 호스팅 SearXNG 인스턴스를 제공하여 제안하기 전에 최신 버전을 확인하도록 하는 것이 좋습니다.

SPEC을 승인한 뒤 커밋하십시오. 승인 후 수정할 수 있는 SPEC은 계약서가 아니며, 커밋은 나중에 증거가 서명한 내용과 일치하는지 확인할 수 있게 해주는 수단입니다.

이것은 사용자에게 남은 유일한 '예/아니오' 결정이며, 이는 곧 핵심이자 위험 요소이기도 합니다. 이를 프로덕션 변경 사항처럼 다루십시오. 실제로도 그렇기 때문입니다. 이미 에이전트 작업 앞에 명시적인 승인 게이트를 운영하고 있다면, SPEC 승인 절차를 워크플로의 동일한 위치에 배치하면 됩니다.

EVIDENCE 보고서: 명령어가 포함된 수치

EVIDENCE 보고서는 마지막에 확인하는 문서입니다. 이 기술을 활용하려면 각 사양의 동작을 검증하는 테스트에 매핑하고, 각 가운틀(gauntlet) 계층의 실행 명령어와 실제 결과를 보고하며, 마지막 코드 수정 후 새로 실행한 결과에서 얻은 모든 수치를 기록하고, 건너뛴 계층은 그 이유와 함께 나열해야 합니다. 형용사는 증거가 될 수 없습니다. "41개의 테스트가 모두 통과되었으며, 49/49 구문 커버리지를 달성함"은 결과입니다. "충분히 테스트됨"은 결과가 아닙니다.

저장소의 데모 보고서인 demo-rate-limiter/evidence.md은 소스 상태를 커밋과 sha256 트리 해시로 식별합니다. 해당 수치를 생성한 정확한 바이트를 알려주기 때문에 이 줄은 보이는 것보다 중요합니다. 이 정보가 없으면 보고서는 더 이상 존재하지 않는 작업 트리를 설명하는 상태가 될 수 있습니다.

보고서의 신뢰성을 유지하기 위해 세 가지 부정 방지 규칙이 있으며, 기술 파일은 이를 절대적인 것으로 규정합니다. 테스트를 통과시키기 위해 테스트를 약화하지 마십시오. 단언을 넓히거나 허용 오차를 높여서는 안 됩니다. 테스트 통과를 위해 테스트와 구현을 같은 단계에서 수정하지 마십시오. 동시에 수정하면 어느 쪽이 잘못되었는지 알 수 없기 때문입니다. 실행되지 않은 계층을 보고하지 마십시오. "건너뜀, 도구 없음, 대신 수동 변이 수행"과 같이 기록해야 신뢰가 유지되며, 결과를 조작하면 전체 체계가 무너집니다.

스킬 설치 및 설치한 커밋 고정

저장소는 AmazingAng/old-coder이며 MIT 라이선스를 따릅니다. README에는 skills CLI를 통한 한 줄 설치 명령어가 명시되어 있습니다.

npx skills add https://github.com/amazingang/old-coder

이 명령은 실행 시점에 main에 있는 모든 내용을 설치하며, CLI 자체도 계속 변경되는 요소입니다. 스킬이 활성화되었다고 가정하기 전에 파일이 어디에 위치했는지 확인하십시오.

ls ~/.claude/skills/old-coder/

SKILL.md와 references/ 디렉터리가 보여야 합니다. 아무것도 없다면 Claude Code가 해당 스킬을 찾을 수 없는 위치에 있는 것입니다. 이전 버전의 skills CLI는 ~/.claude/skills/에 링크를 생성하지 않고 ~/.agents/skills/에 파일을 기록했기 때문에, 디스크에는 파일이 존재해도 에이전트가 이를 불러오지 못했습니다. npx skills@latest add ...을 실행하면 오래된 CLI로 인한 문제를 방지할 수 있습니다.

설치한 내용을 기록할 수 있도록 수동 설치 방식을 권장합니다.

git clone https://github.com/AmazingAng/old-coder.git
cd old-coder
git checkout acc5a89
git rev-parse HEAD
mkdir -p ~/.claude/skills
cp -r skills/old-coder ~/.claude/skills/

acc5a89는 2026년 8월 17일 기준 main의 최신 커밋입니다. 직접 원하는 커밋을 선택하여 기록해 두십시오. 저장소는 활발하게 개발 중이며, gauntlet 참조, 템플릿, 검증 프로토콜 등이 이미 파일 간에 이동했습니다. EVIDENCE 보고서에 어떤 버전의 스킬로 평가했는지 명시되어 있지 않으면, 코드 변경으로 인한 결과인지 규칙 변경으로 인한 결과인지 구분할 수 없습니다. 해당 커밋 해시를 SPEC 옆의 동일한 코드 저장소에 저장하십시오.

~/.claude/skills을 읽지 않는 에이전트의 경우, 시스템 프롬프트나 규칙 파일에 skills/old-coder/SKILL.md와 skills/old-coder/references/gauntlet.md을 추가하십시오. 이것으로 통합 과정이 완료됩니다.

건틀릿 내부에서 실행되는 작업

건틀릿은 모든 명세 동작이 정상일 때 한 번씩 실행되는 계층형 스택입니다. 기술적 명칭은 다음과 같습니다.

• 회귀 테스트를 위한 전체 테스트 스위트. 새로운 실패가 없어야 하며, 기존 실패는 사전에 기준선으로 기록합니다.
• 정적 타입 검사, 린트, 포맷팅. 전체적인 버그 유형을 방지하고 코드 표류를 막습니다.
• 변경된 라인에 대한 커버리지. 임계값을 충족하지 못하면 0이 아닌 종료 코드를 반환해야 합니다.
• 뮤테이션 테스트. 아무것도 검증하지 않는 테스트를 찾아냅니다.
• 속성 기반 테스트. 아무도 예상하지 못한 엣지 케이스를 찾아냅니다.
• 복잡도 예산, 실제 프로그램의 1회 실행, 공급망 및 비밀 정보 스캔, 무작위 순서로 실행되는 스위트 상태 점검.
• 작업의 위험도에 따라 선택되는 도메인 계층: 동시성 스트레스, API 호환성, 롤백 리허설, 지연 시간 벤치마크.

데모에서는 이 작업들을 demo-rate-limiter/tools/gauntlet.sh 스크립트 하나로 묶고, requirements-dev.txt에 고정된 툴체인을 사용합니다. pytest, pytest-cov, coverage, hypothesis, mypy, ruff, pip-audit, pytest-randomly가 포함되며, 각각 정확한 버전으로 고정되어 있습니다(2026년 8월 기준 pytest 9.1.1, ruff 0.16.0). 다음 명령으로 실행합니다.

cd demo-rate-limiter
python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e .
./tools/gauntlet.sh

스크립트는 === tests + coverage ===이나 === mutation ===과 같이 계층별로 배너를 출력하며, 마지막에 === gauntlet: all layers green ===을 출력합니다. 이 스크립트는 set -e 환경에서 실행되므로, 첫 번째로 실패하는 계층에서 즉시 중단되며 마지막 배너는 출력되지 않습니다. 마지막 배너를 확인하는 것이 곧 검증입니다. 이는 상위의 모든 계층이 0을 반환하며 성공했음을 의미합니다.

스크립트에서 여러분의 환경으로 복사해둘 만한 세부 사항이 하나 있습니다. 커버리지 계층은 다음과 같이 작성됩니다.

pytest -q --cov=ratelimiter --cov-report=term-missing --cov-fail-under=100

--cov-fail-under이 없으면, pytest --cov은 커버리지가 얼마나 떨어지든 상관없이 백분율을 출력하고 0을 반환하며 종료됩니다. 이는 첫 번째 실패 시 중단하겠다는 스크립트의 첫 줄 약속을 어기는, 실패를 무시하는 계층이 됩니다. 실패할 수 없는 건틀릿 계층은 장식에 불과합니다.

뮤테이션 테스팅이 커버리지보다 나은 점

커버리지는 테스트 스위트가 해당 라인을 실행했는지 여부만 알려줍니다. 하지만 실제로 중요한 것은 해당 라인이 잘못되었을 때 단언문(assertion)이 실패하는지 여부입니다. 함수를 호출하기만 하고 아무것도 검증하지 않는 테스트도 실행된 모든 라인에 대해 100% 커버리지를 보고합니다. 커버리지는 테스트되지 않은 코드를 찾아낼 뿐, 아무것도 검증하지 않는 테스트는 찾아내지 못합니다.

뮤테이션 테스팅은 이 두 번째 질문에 직접 답합니다. 코드를 의도적으로 조금씩 수정하며 테스트 스위트를 반복 실행합니다. 테스트가 실패하면 뮤턴트(mutant)가 제거(killed)된 것으로 간주하며, 이는 특정 단언문이 해당 동작을 감시하고 있음을 의미합니다. 테스트가 여전히 통과한다면 뮤턴트가 살아남은 것입니다. 즉, 라인은 실행되었지만 결과값을 검증하는 장치가 없다는 뜻입니다.

데모에서는 tools/mutants.py를 사용하여 이를 수행합니다. src/ratelimiter/__init__.py에 번호가 매겨진 단일 수정 사항을 삽입하고, 매번 pytest를 실행한 뒤 파일을 복구합니다. 수정 사항은 사람이 피로할 때 흔히 저지르는 실수들입니다. 예를 들어 >=가 >로 바뀌거나, 반환값이 누락되는 식입니다.

이 러너(runner)에서 가장 중요한 규칙은 제거(kill) 판정입니다. 직접 만든 뮤테이션 스크립트에서 가장 흔히 실수하는 부분입니다. 오직 pytest의 종료 코드 1만 제거로 간주해야 합니다. 코드 1은 테스트가 실행되었고 최소 하나 이상이 실패했음을 의미하기 때문입니다. 종료 코드 0은 뮤턴트가 살아남았음을 의미합니다. 그 외의 코드(수집 오류나 테스트 미발견 등)는 아무것도 검증되지 않았음을 뜻하므로 제거 수치에 포함해서는 안 됩니다. "0이 아닌 모든 값"을 제거로 처리하는 스크립트는 자신의 충돌조차 성공으로 기록하게 되며, 결과 수치는 무의미하게 상승하기만 합니다.

같은 파일에는 두 가지 더 정직한 세부 사항이 있습니다. M11이라는 뮤턴트는 목록에서 제외되는데, 이는 등가(equivalent) 뮤턴트이기 때문입니다. 모든 만료 항목을 삭제하는 대신 하나만 삭제해도 단조 시계(monotone clock) 환경에서는 동일한 동작을 보이므로, 어떤 테스트로도 이를 제거할 수 없습니다. 또한 러너는 PYTHONDONTWRITEBYTECODE=1을 설정하고 가운틀렛(gauntlet)은 __pycache__을 먼저 삭제합니다. 동일한 시간에 작성된 동일한 크기의 두 뮤턴트가 캐시된 .pyc을 공유하여, 두 번째 뮤턴트가 첫 번째 뮤턴트의 판정을 그대로 물려받을 위험이 있기 때문입니다.

이러한 위험 때문에 가운틀렛은 실제 뮤테이션을 수행하기 전에 음성 대조군(negative control) 테스트를 먼저 실행합니다.

.venv/bin/python tools/mutants.py --negative-control
.venv/bin/python tools/mutants.py

대조군은 수정 시간을 고정한 상태에서 두 개의 뮤턴트를 실행합니다. 하나는 반드시 제거되어야 하고, 다른 하나는 엄격히 등가이므로 반드시 살아남아야 합니다. 만약 둘 다 제거된 것으로 나온다면 바이트코드 캐시가 실행 간에 유출된 것이며, 보고서의 모든 제거 수치는 부풀려진 것입니다. 이는 검증 도구 자체를 검증해야 한다는 기술의 원칙을 구체화한 것입니다. pytest와 mypy는 수년간의 검증을 통해 실패 동작을 신뢰할 수 있게 되었습니다. 지난주에 작성한 스크립트는 그렇지 않으므로, 통과했을 때 신뢰하기 전에 먼저 실패할 수 있음을 증명하고 그 증거를 EVIDENCE에 기록하십시오.

[
  {
    "label": "Scenario tests",
    "mutants_killed": 22,
    "mutants_run": 22
  },
  {
    "label": "Property tests",
    "mutants_killed": 3,
    "mutants_run": 22
  }
]

데모의 EVIDENCE 보고서는 단일 집계 수치가 어떻게 진실을 가리는지 보여줍니다. 시나리오 스위트는 22개의 뮤턴트 중 22개를 제거했습니다. 속성 기반 테스트(property-based tests)만 따로 떼어 같은 뮤턴트를 대상으로 실행했을 때는 3개를 제거했습니다. 제거 판정은 가장 먼저 실패한 테스트에 귀속되므로, 완벽한 총합은 스위트 전체의 유효성을 입증할 뿐 내부의 각 계층에 대해서는 아무것도 말해주지 않습니다. 속성 기반 테스트는 사람이 미처 열거하지 못한 입력 형태를 잡아내므로 여전히 제 역할을 합니다. 하지만 이들이 정확성을 전적으로 책임지는 것은 아니며, 각 계층을 개별적으로 측정해야만 그 사실을 알 수 있습니다.

노트북이 아닌 서버에서 gauntlet 실행하기

EVIDENCE 보고서는 특정 명령어가 특정 수치를 생성했다는 주장입니다. 이 주장은 다른 누군가가 동일한 수치를 재현할 수 있을 때만 검증 가능하며, 노트북은 이를 시도하기에 가장 부적합한 환경입니다. 사용자의 Python은 패치 버전이 다를 수 있고, PATH에는 다음 머신에는 없을 도구들이 포함되어 있을 수 있기 때문입니다. 변이 테스트(mutation testing)는 상황을 더 악화시킵니다. 변이체 하나당 전체 테스트 스위트를 한 번씩 다시 실행하므로, 데모 목록만으로도 22만큼의 추가 테스트 실행이 필요합니다.

VPS의 컨테이너 안에서 실행하십시오. 컨테이너는 운영 체제와 인터프리터를 고정하고, 고정된 requirements-dev.txt은 도구를 고정하며, VPS는 브라우저를 실행하지 않는 독립적인 머신을 제공합니다.

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y --no-install-recommends \
      python3 python3-venv git ca-certificates \
 && rm -rf /var/lib/apt/lists/*
WORKDIR /work

docker build -t gauntlet:24.04 .
docker run --rm -v "$PWD:/work" -w /work/demo-rate-limiter gauntlet:24.04 \
  sh -c 'python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e . && ./tools/gauntlet.sh'

정상적인 실행은 === gauntlet: all layers green ===에서 종료됩니다. 두 단계에서 외부 네트워크 연결이 필요합니다. 고정된 도구를 설치하는 pip 과정과, 취약점 서비스에 의존성을 확인하는 pip-audit 계층입니다. 오프라인 실행 시 이 계층을 조용히 건너뛰지 않습니다. 게이트(gate)로서 기대하는 동작대로, 실행은 실패하게 됩니다.

모든 푸시마다 실행하려면 동일한 스크립트를 CI 작업 단계로 만듭니다. 저장소는 ubuntu-latest 환경의 Python 3.12에서 GitHub Actions를 통해 자체적인 gauntlet을 실행합니다. runs-on를 자체 호스팅 러너(self-hosted runner)로 지정하면 작업이 사용자의 VPS에서 실행됩니다.

name: gauntlet
on:
  push:
    branches: [main]
jobs:
  gauntlet:
    runs-on: self-hosted
    defaults:
      run:
        working-directory: demo-rate-limiter
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: python -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e .
      - run: ./tools/gauntlet.sh

트리거는 사용자가 제어하는 브랜치에 대한 푸시로 유지하십시오. 포크된 풀 리퀘스트를 빌드하는 자체 호스팅 러너는 낯선 사람의 코드를 사용자의 서버에서 러너의 자격 증명으로 실행하게 됩니다. 에이전트 자체도 마찬가지입니다. 워크스테이션 대신 폐기 가능한 VM을 제공하십시오. gauntlet 결과를 변경 사항이 논의되는 곳으로 전달하려면 자체 호스팅 PR 리뷰 에이전트에 연결하십시오.

이 접근 방식이 실패하는 경우

첫 번째 실패는 구조적인 문제이며, 어떤 도구를 사용하더라도 해결되지 않습니다. gauntlet은 SPEC의 제약 조건을 실행 가능한 증거로 변환할 뿐입니다. SPEC이 올바른지 여부는 판단할 수 없습니다. 잘못된 요구 사항을 인코딩한 SPEC을 승인하면, 잘못된 프로그램에 대해 완벽한 EVIDENCE 보고서를 얻게 됩니다. 전체 커버리지, 모든 뮤턴트 제거, 모든 계층의 통과 상태를 확인하더라도, 결과물은 원하지 않는 동작을 수행하는 소프트웨어가 됩니다. diff를 읽지 않아 절약한 모든 시간은 SPEC을 검토하는 데 투자해야 합니다.

두 번째는 체커(checker)의 문제입니다. 저장소는 자체 증거 파일에서 이 사실을 솔직하게 밝히고 있습니다. 독립적인 검증 프로토콜은 6라운드에 걸쳐 실행되었으나, 6라운드에서 failed를 반환했습니다. 해당 라운드 이후에 이루어진 수정 사항은 재검증되지 않았으므로, 배포되는 상태는 전체 구간에 대해 검증된 것이 아닙니다. shell lint 계층은 통과가 아닌 사용할 수 없는 상태로 기록되어 있습니다. 초기 라운드에서는 실제 동작상의 결함과 이미 녹색(통과)으로 보고된 상태 뒤에 숨겨진 불완전한 뮤테이션 러너가 발견되었습니다. 녹색 gauntlet이 스스로를 인증하지는 않습니다.

세 번째는 범위의 문제입니다. 수동으로 작성된 뮤턴트 목록은 누군가가 심어두겠다고 생각한 버그만 다룰 뿐이며, 해당 목록에서 제외된 모든 동등 뮤턴트(equivalent mutant)는 여러분이 신뢰하기로 결정한 판단의 결과입니다. 기성 뮤테이션 도구(mutmut, cosmic-ray, Stryker, PIT)는 체계적으로 뮤턴트를 생성하므로, 사용하는 언어에서 지원한다면 이를 기본값으로 사용하는 것이 더 좋습니다.

위험 수준에 따른 작업 강도 조정

이 기술은 세 가지 단계를 정의하며, 에이전트는 자신이 선택한 단계를 명시해야 합니다.

• 1단계, 사소함: 오타, 주석, 설정 값 수정. 전체 테스트 스위트와 린트(lint)를 실행하며, 새로운 테스트가 필요 없는 이유를 한 문장으로 기술합니다.
• 2단계, 일반: 버그 수정 또는 소규모 기능 구현. 전체 루프를 수행하며, 버그 수정 시에는 반드시 해당 버그를 재현하는 실패 테스트 케이스부터 시작해야 합니다. 이를 통해 어제의 버그가 내일의 회귀 테스트가 되도록 합니다.
• 3단계, 고위험: 금전, 인증, 데이터 손실, 동시성, 공개 API 관련 작업. 변경 사항이 문제를 일으킬 수 있는 방식을 나열한 실패 모델에서 시작합니다. 각 위험 요소에 대한 방어 계층을 추가하고, 전체 루프와 함께 속성 기반 테스트(property testing), 변이 테스트(mutation testing)를 수행합니다. 마지막으로 악의적인 입력을 사용하여 구현부를 공격하는 검증 과정을 한 번 거칩니다.

3단계에는 실험적인 단계가 추가됩니다. 새로운 컨텍스트를 가진 두 번째 에이전트가 작업 계약, 승인된 SPEC, 소스 상태만을 확인하고, EVIDENCE가 서명되기 전에 완성된 결과물을 파괴하려고 시도합니다. 이 에이전트는 수정하지 않고 보고만 하며, 사람이 발견된 내용을 평가합니다. 이는 작업 컨텍스트 공유로 인해 발생하는 상관관계를 줄여줍니다. 단, 모델 공유로 인한 상관관계는 줄이지 못합니다.

이 방식을 채택하는 대신 직접 구축하고 싶다면, 나만의 에이전트 기술 작성하기에서 파일 레이아웃과 에이전트가 해당 기술을 로드할 시점을 결정하는 설명 필드에 대해 다룹니다.

FAQ

코드 커버리지가 놓치는 부분을 뮤테이션 테스팅은 어떻게 잡아냅니까?

커버리지는 특정 라인이 실행되었는지 여부만 기록합니다. 해당 라인이 잘못되었을 때 단언문(assertion)이 실패하는지까지는 확인하지 못하므로, 함수를 호출하기만 하고 아무것도 검증하지 않는 테스트도 100% 커버리지로 보고됩니다. 뮤테이션 테스팅은 코드를 의도적으로 한 번에 하나씩 수정하며 테스트 스위트를 다시 실행합니다. 살아남은 뮤턴트(mutant)는 해당 라인이 실행되었음에도 그 결과를 검증하는 장치가 없음을 의미합니다. 이것이 바로 이 기술에서 "커버리지 수치를 맹신하지 말 것"을 절대 원칙으로 삼고, 수치 조작을 잡아내는 계층으로 뮤테이션 테스팅을 지목하는 이유입니다.

에이전트가 작성한 코드를 여전히 직접 읽어야 합니까?

이 워크플로우에서는 코딩 전에 SPEC을 읽고, 작업 후에는 EVIDENCE 보고서를 읽습니다. 보고서에 인용된 명령어를 직접 실행해 보며 내용을 검증하십시오. 코드 변경 사항(diff) 확인은 선택 사항입니다. 주의할 점은 모든 판단이 하나의 문서에 집중된다는 것입니다. 잘못된 요구사항이 포함된 스펙은 원치 않는 프로그램에 대해서도 성공(green) 결과를 내놓기 때문입니다. 절약한 시간은 스펙을 검토하는 데 투자하십시오.

제 서버의 CI 환경에서 Old Coder gauntlet을 실행할 수 있습니까?

네, 그곳이 가장 적합한 실행 환경입니다. requirements-dev.txt에서 고정된 툴체인을 컨테이너 내부에 설치하고 프로젝트의 gauntlet 스크립트를 하나의 작업 단계로 실행하십시오. GitHub Actions를 사용한다면 runs-on: self-hosted을 설정하고 귀하의 VPS에 러너(runner)를 등록하십시오. 직접 제어하는 브랜치에 푸시할 때만 트리거가 작동하도록 설정하십시오. 포크된 저장소의 풀 리퀘스트를 빌드하는 자체 호스팅 러너는 신뢰할 수 없는 코드를 러너의 권한으로 실행하기 때문입니다.

어떤 버전의 기술을 설치해야 합니까?

특정 버전을 고정하십시오. 이 저장소는 활발히 개발 중이며 참조 파일들이 이미 분리 및 이동되었으므로, 지난달에 생성된 보고서는 현재와 다른 규칙으로 평가되었을 수 있습니다. 저장소를 클론하고 특정 커밋을 체크아웃한 뒤, skills/old-coder을 ~/.claude/skills/로 복사하고 해당 커밋 해시를 SPEC 옆에 기록해 두십시오. 이렇게 하면 EVIDENCE의 변경 사항이 곧 코드의 변경 사항임을 보장할 수 있습니다.