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