작은 변경
한 단계가 실패해도 원인을 좁힐 수 있는 크기로 쪼갭니다.
PHILOSOPHY / EVALUATION
코딩은 생성보다
증거의 연쇄입니다
이 레포가 지향하는 코딩은 큰 변경을 한 번에 밀어 넣는 방식이 아니라, 각 단계의 목적·검증·복구를 작게 남기는 방식입니다.
CODING PHILOSOPHY
작고, 검증 가능하고, 다시 실행 가능하게
근거 우선
완료라는 말보다 exit code·로그·diff·현재 SHA를 남깁니다.
복구 가능
실패를 예외로 숨기지 않고 다음 cycle의 입력으로 저장합니다.
EVALUATION GRAPH
검증 단계는 어디에서 이어지는가
01Plan모호성을 줄이고 non-goal·acceptance criteria를 저장→
02Build작은 단계·TDD·재개 가능한 state로 구현→
03Review정확성·보안·아키텍처를 병렬 검토하고 verifier로 필터→
04Verify실제 exit code·test count·GitHub head SHA로 완료 주장 검증→
05Recover실패 로그를 읽고 최소 수정 후 같은 gate를 반복→
06MeasureTraceLog evidence로 하니스 효과와 드리프트 측정
↩ Review/Verify 실패 → Build 또는 Recover로 돌아가고, 같은 evidence gate를 재실행
`$dev-kit:code-viz`로 표현할 수 있는 것은 이 단계 간 실제 관계입니다. inventory는 fan-out, 실제 실행 전후는 chained edge, retry는 labeled back-edge로 표현해야 하며 단순히 보기 좋은 순서를 발명하면 안 됩니다.
THIN HARNESS
agent가 바뀌어도 하네스는 덜 바뀌어야 합니다
하네스의 안정적인 계약은 모델의 문체나 특정 agent의 내부 추론이 아니라, 입력·출력·상태·증거 형식입니다. 따라서 skill은 얇은 orchestration layer로 두고, GitHub 상태·TraceLog schema·verdict precedence·exit code 같은 결정론적 경계를 중심에 둡니다.
agent가 바뀌어도 유지되어야 할 항목은 skill contract compatibility, evidence schema compatibility, workflow replayability입니다. 모델별 프롬프트 튜닝이 아니라 contract test와 측정 결과로 회귀를 발견합니다.
METRIC EXTENSION
thinness를 harness-effectiveness에 포함하는 방법
현재 `harness-effectiveness`는 prevention, first-pass, recovery, learning, measurement-integrity 5개 축을 측정합니다. 여기에 별도 점수를 임의로 추가하기보다 measurement_integrity에 harness stability submetric을 넣고, 평가 report에는 다음 증거를 함께 표시하는 방향이 안전합니다.
- agent/model 교체 후 skill contract test 통과율
- 동일 입력 replay의 verdict·evidence schema 호환율
- agent-specific branch와 prompt coupling의 개수
- 하네스 코드 변경 없이 provider/model만 바꿔도 유지된 gate 비율
이 확장은 현재 reducer의 사실과 제안 지표를 구분해 기록해야 하므로 GitHub Issue로 추적합니다.