belay은(는) 무엇을 하나요?
당신은 작은 단계들로 목표에 도달합니다. 체크가 인간의 개입 없이 각 단계를 채점합니다.
scripts/belay.py가 점수를 관리합니다: 당신이 편집하면, 체크를 실행하고,
성공 시 커밋하거나 실패 시 되돌리며, 로그를 기록합니다. 당신은 직접 점수를 기록하지 않으며,
단계가 "기본적으로" 통과했다고 판단하지 않습니다.
모든 목표는 결국 같은 것으로 귀결됩니다: 숫자를 출력하는 명령어. 더 빠름은 시간 또는 횟수입니다. 감사는 실패한 테스트의 수이며, 찾은 문제 하나당 하나입니다. 포트는 일치하는 출력의 수입니다. UI는 심사자의 점수입니다.
작업 방법:
- 사용자가 클라임을 시작하고 떠납니다. 업데이트를 위해 멈추지 마십시오. 사용자는 세 가지만 읽습니다: 카드, 오직 사용자만이 답할 수 있는 질문, 그리고 보고서입니다. 하네스에 질문 도구가 있다면 그것을 사용하여 질문하십시오.
- 상태는 채팅이 아닌 디스크에 저장됩니다. 카드, 로그, 노트, 마지막 체크 출력은
.belay/<이름>/아래에 있습니다. 압축 또는 충돌 후에status명령어 하나로 모든 것을 복원할 수 있습니다. - sleep 루프로 기다리지 마십시오. 긴 명령은 백그라운드에서 실행하고 실행 중에 다음 단계를 계획하십시오.
BELAY는 이 파일 옆에 있는scripts/belay.py의 절대 경로입니다. 각 명령에 전체 경로를 작성하십시오. 대상 저장소 내에서 실행하십시오. 전달하는 경로와 명령은 저장소 루트를 기준으로 합니다.- 클라임은 자체 브랜치
climb/<이름>을 사용합니다. 취소된 단계는 트리를 재설정하고 git이 무시하지 않는 추적되지 않은 파일을 삭제합니다. 다른 사람이 이 체크아웃에서 작업 중이라면, 별도의 워크트리에서 클라임하십시오. 이미 이 작업을 위해 만들어진 브랜치에 있는 경우--here를 전달하십시오.
1. 시작하기 전에 재개
python3 "$BELAY" list를 실행하십시오. 이 목표에 대한 클라임이 존재하면, 해당 브랜치로
전환하고, status <이름>을 실행한 후 4단계로 계속 진행하십시오. "계속"은
충돌이나 새 세션 후에 이를 의미합니다. 처음부터 다시 시작하지 마십시오.
2. 체크 구축
클라임은 체크의 품질만큼만 좋습니다. 잘못된 것을 측정하는 체크는 전체 실행을
잘못된 것을 개선하는 데 낭비합니다. 먼저 대략적인 체크를 실행하고 나중에 relock으로
세밀하게 다듬으십시오.
질문: 목표가 달성되었는지 확인하기 위해 무엇을 실행하겠습니까? 해당 명령이 숫자를 출력하도록 만드십시오. 상황에 가장 적합한 가장 강력한 형태를 사용하십시오: 정확한 일치 또는 테스트 수, 그 다음 작업량(쿼리, 왕복, 바이트), 그 다음 시계, 그리고 오직 취향만이 판단할 수 있을 때 판사를 사용하십시오.
| 목표 | 점수 |
|---|---|
| 버그 또는 기능 | 수정 사항이 아닌 명세서에서 작성된 실패하는 테스트 |
| 감사, 안정화, "X 작동하게 만들기" | 찾은 문제 하나당 실패하는 테스트 하나 |
| 속도 또는 크기 | 시간 이면의 작업량 또는 시간 자체 |
| 포팅 또는 복제 | 실제 도구와 일치하는 출력 |
| 여러 목표 동시에 | 가장 나쁜 기준에 대한 진행 상황 |
| 외관, 느낌, 작성 | 루브릭과 좋은 예시가 있는 judge.py |
각각에 대한 레시피는 references/checks.md에 있습니다. 체크를 작성하기 전에
목표와 일치하는 부분을 읽으십시오.
저장소에 있는 것을 사용하십시오. --score '<regex>'는 테스트 러너 출력에서
점수를 읽습니다. 예: --score '(\d+) failed'. 마지막 일치하는 줄을 가져와서
캡처한 숫자를 합산합니다. 일치 항목이 없는 통과 실행은 0점입니다.
--score 없이 체크 표준 출력의 마지막 줄은 순수한 숫자여야 합니다.
--check를 반복하여 여러 명령을 동시에 실행할 수 있습니다. 점수는 합산됩니다.
클라임이 편집하는 다른 각 체크아웃에 대해 --repo <경로>를 추가하십시오.
단계는 모든 체크아웃에서 함께 유지되거나 취소됩니다.
체크를 신뢰하기 전에 입증하십시오:
- 실패할 수 있어야 합니다. 의도적으로 코드를 망가뜨리고 점수가 나빠지는지
확인하십시오.
git checkout -- <파일>로 복원하십시오. - 성공을 볼 수 있어야 합니다. 작은 실제 개선이 점수를 움직여야 합니다.
- 안정적이어야 합니다. 3번 실행하십시오. 코드 변경 없이 점수가 흔들리면,
시계를 작업량으로 대체하거나
--runs 3, 흔들림보다 큰--min-gain(점수가 많이 줄어들 때3%와 같은 백분율), 그리고--paired를 사용하십시오. - 속일 수 없어야 합니다. 실행마다 입력을 변경하고 참조와 비교하십시오. 예를 들어 정답을 하드코딩하는 등 한 가지 속임수를 직접 시도해보고 체크 또는 가드가 이를 잡는지 확인하십시오.
- 빨라야 합니다. 각 단계에서 체크 시간을 지불합니다. 단계를 2분 미만으로 만드십시오: 샘플 또는 단계당 작업량을 채점하고, 전체 스위트 또는 시간 측정 실행을 가드 또는 홀드아웃으로 유지하십시오.
- 기준에 도달 가능해야 합니다. 현재 설계로 할 수 있는 최선을 계산하십시오. 기준이 그 이상이면 카드에 그렇게 말하고 도달할 수 있는 기준을 제안하십시오.
점수가 측정하지 않는 모든 것을 보호하십시오:
- 가드 (
--guard, 종료 코드 0으로 통과). 변경할 코드가 건드리는 것을 나열하십시오: 호출자, 다른 플랫폼, 저장된 데이터, 공개 API. 각각 가드가 필요합니다: 오늘 통과하는 테스트, 타입체크, 린트, 빌드. 점수가 실패 횟수인 경우, 충돌이 "더 적은 실패"로 통과할 수 없도록 통과하는 테스트를 자체 파일에 가드로 유지하십시오. - 잠금 (
--lock) 체크, 테스트, 픽스처, 홀드아웃을 잠급니다.try는 잠긴 파일이 다를 때 채점을 거부합니다.--lock경로 아래의 새 파일은 클라임 브랜치의 첫 번째 커밋이 됩니다. 다른 커밋되지 않은 변경은init을 중단합니다. - 홀드아웃 (
--holdout), 체크가 샘플, 벤치마크, 또는 판사를 사용할 때: 클라임이 절대 학습하지 않는 사례로,.belay/<이름>/holdout/아래에 보관합니다. 다시 열지 마십시오. 점수가 오르고 홀드아웃이 오르지 않으면 클라임이 과적합된 것입니다. 중단하고 그렇게 말하십시오.
감사 및 열린 목표. 목표가 다루는 내용을 .belay/<이름>/notes.md에
체크리스트로 나열하십시오. 영역별로 버그를 찾으십시오. 실제 발견 사항당 하나의
실패하는 테스트를 명세서 또는 버그 보고서에서 작성하십시오. 이후 단계에서 새 버그를
찾으면 테스트를 추가하고 relock --why "<버그 발견>"을 실행하십시오.
점수는 정직한 이유로 올라가고 로그는 이유를 보여줍니다. 사용자의 결정이 필요한
발견 사항은 점수가 아닌 노트와 보고서에 기록하십시오.
3. 카드, 그 다음 init
카드가 포함된 메시지 하나를 보내고 다른 것은 보내지 말고 결정을 기다리십시오:
클라임 카드:
build-speed목표: 동일한 출력으로 콜드 빌드 2배 속도 향상
점수 중간 빌드 시간(초), 낮을수록 좋음: 현재 47.0, 기준 23.5 체크 ./scripts/bench-build.sh, 3회 실행, 페어드, 최소 이득 3%가드 npm test,npm run typecheck홀드아웃 12개 샘플 앱 중 3개 잠금 scripts/bench-build.sh,test/,samples/제한 없음 (단계당 약 2분) 답변이 필요한 사항: 없음
가세요라고 답하거나, 한 줄을 변경하십시오.
모든 줄을 최선의 선택으로 채우십시오. 사용자가 기준 없이 목표를 주었다면 "2배 빠르게" 또는 "모든 샘플 일치"와 같이 야심 차고 확인 가능한 기준을 제안하십시오. "go"를 기다리십시오. 이는 카드, 브랜치 및 커밋을 승인합니다. 사용자가 이미 물어보지 말고 실행하라고 했거나, 목표가 작고 기준이 의심의 여지가 없을 때는 기다리지 말고 카드를 보고서 상단에 배치하십시오. 그 후에는 스스로 알아내거나 결정할 수 있는 것은 묻지 마십시오.
python3 "$BELAY" init build-speed --goal "cold build 2x faster" \
--check ./scripts/bench-build.sh --direction min --target 2x \
--runs 3 --paired --min-gain 3% --guard "npm test" --guard "npm run typecheck" \
--holdout ./scripts/bench-holdout.sh --lock scripts --lock test \
--lock .belay/build-speed/holdout
백엔드와 프론트엔드에 대한 감사:
python3 "$BELAY" init billing-audit --goal "every billing finding fixed" \
--check "pytest tests/billing -q" --check "cd ../web && npx vitest run billing" \
--score '(\d+) failed' --direction min --target 0 --repo ../web \
--guard "pytest tests/legacy -q" --guard "cd ../web && npx tsc --noEmit" \
--lock tests/billing --lock ../web/src/billing/__tests__
init은 브랜치를 만들고, 기준선을 측정하며, 가드가 이미 실패하면 시작을 거부합니다.
첫 번째 단계 전에 경고하는 내용을 수정하십시오. 사용자가 제한을 지정한 경우에만
--max-hours 또는 --max-steps를 설정하십시오. 제한이 없으면 클라임은
기준이 충족되거나 막힐 때까지 실행됩니다.
4. 클라임
각 단계는 하나의 아이디어, 하나의 변경, 하나의 try입니다:
- 아이디어를 선택하십시오. 로그가 이미 취소한 것을 다시 시도하지 마십시오.
달라진 점을 말할 수 있는 경우는 예외입니다. 판사가 사용 중이면
.belay/judge-notes.md를 읽으십시오. - 하나의 이유로 하나의 변경을 하고 그 효과를 추측하십시오. 추측을
아이디어에 넣으십시오:
"파서 캐싱 (-10% 예상)". 추측이 크게 빗나가면 코드에 대한 모델이 잘못된 것입니다. 다음 단계 전에 프로파일링하십시오. python3 "$BELAY" try "<아이디어>". 성공 시 커밋하거나 트리를 재설정합니다. 어느 쪽이든 계속 진행하십시오. 단계의 전체 체크 출력은.belay/<이름>/last.txt에 있고, 최고 단계의 출력은best.txt에 있습니다. 체크를 다시 실행하는 대신 이것들을 읽으십시오.- 체크가 실행되는 동안 트리를 편집하지 마십시오. 클라임을 변경하는
belay.py명령은 한 번에 하나만 실행됩니다. 다른 명령이 여전히 실행 중이라고 표시되면 기다리십시오. - 매 5단계마다
.belay/<이름>/notes.md를 몇 줄로 업데이트하십시오: 무엇이 효과가 있고, 무엇이 효과가 없으며, 다음에 시도할 것은 무엇인지. 다음 세션은 여기서부터 재개됩니다.
체크가 두 번 취소한 아이디어를 믿는다면, 체크가 그것을 볼 수 없는 것입니다.
체크를 더 세밀하게 만들고 relock하십시오. 단계를 통과시키기 위해 잠긴 파일을
편집하지 마십시오.
절대 체크를 속이지 마십시오
다음 각각은 점수를 올리지만 작업을 더 나쁘게 만듭니다. 각각은 try가 유지하더라도
실패한 클라임입니다:
- 체크가 사용하는 입력을 특별 대응하거나, 예상 출력을 하드코딩 또는 캐싱하는 것.
- 테스트를 건너뛰거나, 약화시키거나, 삭제하거나, 오류를 잡아 숨기는 것.
- 코드를 더 빠르게 만드는 대신 벤치마크가 더 적은 작업을 수행하도록 하는 것.
relock을 사용하여 까다로운 사례를 제거하거나 완화하여 기준을 충족시키는 것. Relock은 체크를 더 정확하게 만들기 위한 것입니다. 기준에 도달할 수 없으면 측정한 최저점을 보고하십시오.- 홀드아웃을 읽는 것.
진정한 승리는 체크가 본 적 없는 입력에 대해 동일한 코드를 더 좋게 만듭니다. 앞으로 나아갈 유일한 방법이 이 중 하나라면 체크가 잘못된 것입니다. 그렇게 말하십시오.
계속 재평가하십시오
점수는 사용자가 원하는 것을 대신할 뿐입니다. 여전히 그런지 확인하십시오:
- 매 10번의 유지된 단계마다, 그리고 기준에 도달했을 때: 직접 실제 결과를
살펴보십시오. 앱을 열고, 출력을 읽고, 스크린샷을 보십시오. 전체 테스트 스위트와
holdout을 실행하십시오. 점수와 실제 결과가 벌어졌다면 체크를 수정하고relock --why "..."을 실행하십시오. - 가드가 잡지 못한 무언가가 고장났을 때:
git bisect run <실패한 명령>으로 단계를 찾은 다음,try --fix "<무엇이 고장났는지>"로 수리하십시오. 이는 점수를 유지하는 변경을 유지합니다. 유일한 수리가 해당 단계의 이득을 포기하는 것이라면git revert로 단계를 되돌리고relock --why "단계 N 되돌림: X 고장"을 실행하십시오. 누락된 가드를 추가하십시오. - 보고서 전에:
git diff <시작>..HEAD를 하나의 변경으로 새 눈으로 검토하십시오. 제거된 테스트, 삼켜진 오류, 꺼진 기능, 변경된 기본값, 데이터 및 API 변경을 찾으십시오.try --fix로 수리한 다음, 보고서가 측정된 숫자를 인용할 수 있도록 체크와holdout --why 최종을 한 번 더 실행하십시오.
5. 막혔을 때
try와 status는 5단계 동안 이득이 없으면 PLATEAU를 출력합니다. 아이디어를
시도하는 것을 멈추고 막힌 원인을 찾으십시오. 추측하기 전에 측정하십시오:
- 시간이나 오류 수는 실제로 어디서 오는가? 프로파일링하십시오.
- 체크가 불안정하거나, 작은 승리를 보기에는 너무 거칠거나, 문제를 보지 못하는가?
- 작은 단계로는 도달할 수 없는 더 큰 아이디어가 있는가?
- 어떤 도구, 접근 권한, 데이터 또는 계산이 다음 10단계를 변화시킬 것인가?
python3 "$BELAY" review "<발견한 것>"으로 기록하십시오. 이는 PLATEAU를
5단계 동안 조용하게 만듭니다. 수정할 수 있는 것을 수정하십시오: 더 빠른 체크,
더 세밀한 메트릭, 다른 접근 방식. 오직 사용자만이 제공할 수 있는 것(예: 접근 권한
또는 비용)에 대해서만 물어보고, 다른 모든 아이디어가 소진된 후에만 물어보십시오.
6. 중단 및 보고
다음 중 하나가 참일 때 중단하십시오:
try가 BAR REACHED를 출력합니다. 자동으로 홀드아웃을 실행합니다. 홀드아웃이 평평한 상태에서의 가시적 승리는 승리가 아닙니다.status가 STUCK을 출력합니다: 그 사이에 이득 없이 두 번의 블로커 검토.try가 "Budget used"로 거부합니다.- 홀드아웃이 점수와 일치하지 않습니다.
- 다음 단계에 사용자만이 제공할 수 있는 것이 필요합니다.
그런 다음 위의 최종 검토를 수행하고, .belay/<이름>/data/를 삭제한 후
보고서를 보내십시오. 10초 안에 읽을 수 있도록 만드십시오:
클라임
build-speed: 기준 도달47.1초 → 18.7초, 2.5배 더 빠름 (기준 23.5초, 41단계에서 도달)
홀드아웃 51.0초 → 20.2초, 점수와 함께 움직임 단계 52개 중 19개 유지 안전 모든 유지된 단계에서 가드 통과. 전체 스위트 및 최종 검토 깔끔함 브랜치 climb/build-speed, 19개 커밋효과 있었던 것
- 증분 타입 캐시: −12초
시도했으나 취소된 것
- swc 교체: 3개의 가드 고장
당신의 결정
- 검토:
git log --oneline 1a2b3c4..climb/build-speed
제목 줄은 다음 중 하나입니다: 기준 도달, 막힘, 예산 소진, 홀드아웃 불일치, 사용자 필요. 스크립트가 측정한 숫자를 인용하고, 추정치는 절대 인용하지 마십시오. 도중에 체크나 기준을 변경했다면 제목에 그렇게 명시하십시오. 가장 큰 승리부터 먼저. 섹션당 최대 3개의 글머리 기호. 빈 섹션은 건너뛰십시오.
사용자가 더 원하면 동일한 주장에 대해 더 어려운 기준을 raise 2x --why "..."으로
설정하고 계속 클라임하십시오. 새로운 목표로 전환하지 마십시오.
서브에이전트
하네스가 서브에이전트를 시작할 수 있다면, 설정 중 병렬 읽기와 블로커 검토 및 최종
검토에 새로운 시각을 위해 사용하십시오. 파일 덤프가 아닌 결론을 요청하십시오.
오직 당신만이 클라임 트리에 씁니다. try가 트리를 재설정하기 때문입니다.
도우미는 읽거나, 자체 워크트리에서 패치 초안을 작성하여 당신이 적용하고 try할
수 있도록 합니다. 서브에이전트가 없으면 인라인으로 수행하십시오.
명령어
| 명령어 | 기능 |
|---|---|
init <이름> --goal "..." --check "..." --direction min|max | 기준선, 브랜치, 잠금. 옵션: --check (반복), --score '<regex>', --target (숫자 또는 2x), --guard (반복), --lock (반복), --holdout, --repo (반복), --runs, --paired, --min-gain, --timeout, --max-hours, --max-steps, --here |
try "<아이디어>" [--fix] | 편집을 채점한 후 유지 또는 취소합니다. --fix는 점수를 유지하는 수리를 유지합니다 |
status [이름] | 점수, 마지막 단계, 노트, PLATEAU 또는 STUCK |
relock --why "..." | 변경된 체크를 수락하고 다시 측정합니다 |
holdout --why "..." | 지금 홀드아웃을 실행합니다 |
review "<발견>" | 블로커 검토를 기록합니다 |
raise <기준> --why "..." | 이 기준에 도달한 후 더 어려운 기준을 설정합니다 |
budget [--hours N] [--steps N] [--remaining] | 예산을 표시하거나 설정합니다 |
list | 모든 알려진 클라임을 나열합니다 |