workspace-manager/.workspace-ops/shared/quality-evaluation.md

Quality Evaluation

목적

일간/주간 작업 평가에서 제품 기능 구현만을 품질의 중심으로 보지 않는다. AI-first 개발에서는 여러 repository에 걸친 표준화, 하네싱, 규칙 전파, drift 방지, 재현 가능한 운영 절차가 agent가 작업 가능한 제품 표면이자 개발 품질의 핵심 성과다.

기본 원칙

• 제품 코드 구현은 품질 항목 중 하나일 뿐이며, 유일한 진척 기준이 아니다.
• AI-first 개발에서 cross-repo 표준화/하네싱은 반복 작업 비용과 운영 위험을 낮추는 정도를 넘어, agent 작업의 안전성/재현성/지속성을 결정하는 1급 품질 작업으로 본다.
• 진입 파일, skill routing, ignore 정책, 동기화 절차, version propagation은 agent-operable surface로 평가한다.
• sync 여부 자체는 품질 항목으로 평가하지 않는다. sync로 반영된 내용이 agent-operable surface를 개선했는지 평가한다.
• 원천 repository에서 만든 변경은 설계 품질로, downstream repository에 반영된 변경은 적용 품질과 일관성 품질로 구분한다.
• 미커밋 변경은 작업 중인 유효 payload로 보고 커밋된 변경과 함께 평가한다.
• 미커밋 상태 자체를 위험/누락/감점 사유로 언급하지 않는다. 필요한 경우 변경 파일의 내용만 평가 축에 반영한다.
• version-only 반영은 낮은 품질 변화가 아니라 감사 가능성/version alignment 근거로 제한해 평가한다.
• 문서/roadmap 변경도 실행 절차, 책임 경계, 재현성, 의사결정 품질을 높이면 품질 개선으로 본다.
• 테스트/CI 근거가 없으면 검증 품질은 낮게 보되, 그 이유로 표준화/하네싱 품질 전체를 무효화하지 않는다.
• 전통적 구현 중심 기준으로 AI-first 하네싱 작업을 보조 업무처럼 낮게 평가하지 않는다.

품질 축

축	의미	주요 근거
작업 품질 종합평가	오늘/이번 주 변경이 장기 유지보수성과 실행 품질을 얼마나 높였는지	변경 범위, repo 확산도, 표준화 수준, 검증 근거
표준화/하네싱 품질	여러 프로젝트가 같은 규칙, 스킬, 스크립트, 진입 파일, 동기화 절차를 공유하게 만든 정도	agent-ops, rules, entry files, synchronization scripts, version propagation
AI 작업 가능성	agent가 암묵지 없이 안전하게 탐색, 수정, 평가, 이어받기를 할 수 있게 된 정도	AGENTS/GEMINI/CLAUDE, skill routing, target discovery, ignore policy, output format
일관성/드리프트 방지	repo별 운영 규칙 차이를 줄이고 이후 차이를 감지/방지하기 쉬워졌는지	공통 파일 동기화, 버전 정책, ignore 정책, routing 규칙
실행 가능성	문서가 실제 실행 절차, 다음 액션, 책임 경계로 이어지는지	GUIDE, README, roadmap/current, milestone, checklist
구현/제품 품질	사용자 기능, 제품 코드, 테스트가 실제로 좋아졌는지	code diff, test diff, CI/local verification
검증/감사 가능성	변경 근거와 완료 상태를 추적하고 재검증하기 쉬운지	커밋 메시지, shortstat, version, CI, archive/current 연결, working payload file set
원천/반영 구분	원천 설계 변경과 downstream 적용이 각각 어떤 품질을 높였는지	source repo commits, downstream reflected files, version alignment

출력 표

분석 결과에는 다음 표를 포함한다.

품질 항목	관측 근거	평가	판단
작업 품질 종합평가	<전체 변경 범위>	<예: 높음, 8/10>	<표준화/하네싱/검증 보정 이유>
표준화/하네싱	<공통 규칙과 하네싱 전파 근거>	<평가>	<판단>
AI 작업 가능성	<agent가 읽고 실행할 기준이 명시된 근거>	<평가>	<판단>
일관성/드리프트 방지	<repo 간 동일 기준 반영 근거>	<평가>	<판단>
구현/제품 품질	<코드/테스트 근거>	<평가 또는 판정 보류>	<판단>
검증/감사 가능성	<검증/추적 근거>	<평가>	<판단>
원천/반영 구분	<source 변경과 downstream 적용 근거>	<평가>	<판단>