Repository navigation
Releases: sean5940/harness-scouter
Release list
v0.3.1
게이트가 "재봤고 아니었다" 와 "아직 못 쟀다" 를 갈라서 냅니다.
왜 이 릴리스가 존재하는가
v0.3.0 릴리스 노트에 이렇게 적었습니다.
그 0/6 은 여섯 축이 재현에 실패했다는 뜻이 아니라, split-half 통계를 아직 계산할 수
없다는 뜻입니다.
틀렸습니다. 화면을 갈라 인쇄하게 만들고 나서야 알았습니다.
before All-time view 0/6 axes · per-period view 0/6 axes
after All-time view 0/6 axes supported · 3 failed · 3 not computable
Per-period view 0/6 axes supported · 3 failed · 3 not computable
3 은 진짜 미달입니다. 상한 도달 가능성 검사가 세 축에서 걸립니다. 행동을 하나도
안 바꾸고 점수를 100 까지 밀 수 있는 경로가 있다는 뜻입니다.
3.1 → 100.0 커밋 전 검증 신선도
92.7 → 100.0 읽기 왕복 절제
89.1 → 100.0 검증 공회전 절제
나머지 3 만 split-half 를 아직 못 재는 축입니다.
무엇이 바뀌었나
split-half 가 통계를 못 냈을 때 미달로 세던 것을 고쳤습니다
값 칸에는 계산 불가 를 적으면서 판정만 X 로 줬습니다.
X split-half not computable >= 0.5
순열 split-half 는 구간 안에서 세션을 반으로 갈라 묻습니다. 구간이나 세션이 얇으면
통계 자체가 안 나옵니다. 그때는 "재현이 안 됐다" 가 아니라 "아직 못 쟀다" 입니다.
PR #3 이 고친 것이 계산 불가를 통과로 세는 것이었고, 이건 그 거울상입니다. 부호만
반대일 뿐 재보지 못한 것을 재본 것처럼 다룹니다.
축의 화면 지지 여부가 boolean 이라 그 구분을 도로 접던 것을 고쳤습니다
검사는 처음부터 3값이었는데 supportsAllTime·supportsPerPeriod 가 boolean 이었습니다.
검사에서 살린 구분이 축 단위에서 사라지고 있었습니다.
화면이 미달과 판정 불가를 갈라 적습니다
축 줄의 지지 표시도 "미달" 하나였던 것을 "미달" 과 "판정 불가" 로 나눴습니다. 미달이
하나도 없고 못 잰 것만 있을 때는 "고칠 것이 아니라 세션을 더 쌓아야 하는 자리" 라고
직접 적습니다.
이 릴리스가 스스로 증명한 것
이 화면을 만들자마자 쓸모가 증명됐습니다. 이 저장소의 0/6 을 저자가 일주일 동안
"여섯 축 전부 아직 못 쟀다" 로 설명해 왔고, 그건 더 듣기 좋은 쪽이었습니다.
악의가 아니라 화면이 그 구분을 접고 있었기 때문입니다.
계측기를 만드는 사람이 자기 계측기에 속는 방식이 이렇습니다. v0.3.0 노트도 정정했습니다.
안 바뀐 것
축 독립성 위반 4건은 여전히 답이 없습니다.
읽기 왕복 절제 ~ 검증 공회전 절제 rho=-1.000
두 축이 완벽하게 반대로 움직인다는 것은 6축이 맞느냐에 대한 반론입니다.
외부 타당성도 여전히 없습니다.
Full Changelog: v0.3.0...v0.3.1
v0.3.0
이 릴리스는 이슈 #2 때문에 존재합니다.
낯선 사람이 v0.2.1 을 자기 하네스에 돌렸습니다. Go·Swift 를 headless SDK 로 굴리는
환경이고, 세션 2,350개에 트랜스크립트 996MB 입니다. 화면은 커밋 전 검증 신선도 0%
라고 말했습니다. 그쪽은 거의 모든 커밋 앞에서 검증을 합니다.
틀린 것은 그 하네스가 아니라 이 도구였습니다. 그분이 다섯 항목을 숫자와 함께 보고해
주셨고, 이 릴리스는 대부분 그 보고서입니다.
바뀐 것
검증 판정이 JS 생태계 밖에서도 섭니다 (#7)
tsc·eslint·jest 같은 명령 이름 목록이라 Go·Swift 하네스에서 거의 안 잡혔습니다.
제보된 코퍼스에서 Bash 28,414건 중 인식된 것이 3건, 검증 형태인데 못 잡은 것이
10,937건이었습니다. 종류를 도구 이름에서 하는 일(typecheck·lint·format·test·
build)로 바꾸고 Go·Rust·Swift·.NET·Maven·Gradle·make·셸 검증 스크립트를 넣었습니다.
같이 고친 두 가지가 없으면 위가 헛수고입니다. -v 를 도구를 보고 가릅니다 —
tsc -v 는 판버전이고 go test -v 는 자세히 보기입니다. 그리고 go test ./... 의
./... 을 모듈 전체로 읽습니다. 그대로 두면 "고친 것을 안 덮은 검증" 이 됩니다.
하네스의 능력을 밖에서 선언할 수 있습니다 (#8)
--capabilities file-read,file-edit,shell 또는 SCOUTER_CAPABILITIES.
선언에서 빠진 능력에 기대는 축은 0 이 아니라 판정 불가로 나가고 평균에서 빠집니다.
qmd·graphify 가 없는 하네스에서 인덱스 검색 축이 구조적으로 0 이던 것을 막습니다.
README 가 약속한 커버리지 게이트가 실제로 걸립니다 (#9)
MIN_COVERAGE_TO_SCORE 와 measureCoverage() 를 부르는 프로덕션 경로가 없었습니다.
이제 매핑 커버리지가 90% 아래면 점수 대신 무엇이 안 잡혔는지를 냅니다.
얇은 분모가 두꺼운 분모와 같은 무게를 갖지 않습니다 (#10)
0 (n=477) 과 100 (n=3) 을 반씩 섞어 50 을 내던 것을 고쳤습니다.
비교할 수 없는 구간을 세션 수만 채웠다고 닫지 않습니다 (#11)
축이 하나도 예산에 안 닿은 구간은 모든 축이 회색인데 게이트에 같은 무게로 들어갔습니다.
scouter periods 가 구간 크기 편차도 함께 냅니다.
MIT 라이선스
지금까지 고지가 없었습니다. 배포 tarball 에도 LICENSE 를 넣습니다.
README 를 재현 가능하게
예시 화면·테스트 수·라벨 건수·축 이름 출처가 실제와 어긋나 있었습니다. 근거였던
366세션 코퍼스가 사라져 되살릴 수 없어서, 오늘 실제로 나오는 출력으로 바꾸고
docs/measurements/2026-09-07/ 에 박제했습니다. npm run check:docs 가 처음으로
전부 통과합니다.
안 바뀐 것
게이트는 여전히 0/6 을 인쇄합니다. 그게 요점입니다.
정정 (2026-09-07, v0.3.1 에서 고침). 이 노트는 원래 "그 0/6 은 여섯 축이 재현에
실패한 것이 아니라 split-half 를 아직 계산할 수 없는 것" 이라고 적었습니다. 틀렸습니다.
v0.3.1 에서 화면이 두 값을 갈라 인쇄하게 하고 나서야 실제 내역이 보였습니다.
전수 집계 화면 0/6 축 지지 · 미달 3 · 판정 불가 3
구간별 화면 0/6 축 지지 · 미달 3 · 판정 불가 3
3 은 진짜 미달입니다. 상한 도달 가능성 검사가 세 축에서 걸립니다 — 행동을 안 바꾸고
점수를 100 까지 밀 수 있는 경로가 있습니다(3.1 → 100.0 · 92.7 → 100.0 · 89.1 → 100.0).
나머지 3 만 split-half 를 아직 못 재는 축입니다.
v0.3.0 에는 split-half 가 통계를 못 냈을 때 그것을 미달로 세는 버그도 있었습니다.
값 칸에는 "계산 불가" 를 적으면서 판정만 미달로 줬습니다. v0.3.1 이 고쳤습니다.
축 독립성 위반 4건은 답이 없습니다.
읽기 범위 규율 ~ 검증 신선도 rho=-0.949
읽기 왕복 절제 ~ 검증 공회전 절제 rho=-1.000
축 둘이 완벽하게 반대로 움직인다는 것은 6축이 맞느냐에 대한 반론입니다.
외부 타당성도 여전히 없습니다. validity.ts 가 소스에 그렇게 적어두고 있습니다.
필요한 것
자기 것이 아닌 코퍼스에서 나온 측정 보고입니다. 지금 1건이고, 그 1건이 이 릴리스를
만들었습니다. 돌려보시고 scouter gate 가 몇 축을 지원하는지 알려주시면 그게 가장
값진 기여입니다.
Full Changelog: v0.2.1...v0.3.0
v0.2.1
v0.2.0
v0.1.0
Full Changelog: https://github.com/sean5940/harness-scouter/commits/v0.1.0