Development Pilot KO

개발 작업의 진행·완료·질문 표시: 1차 shadow 파일럿 초안

English

상태: 설계 초안, 실제 Riido 파일럿0회. 기존 Go 모델의 이어 학습·게시와 별도 CLI 합성4문장 시험은 완료했다. 아래 실제 reader·화면 연결과100/400/2400건 검수는 아직 실행하지 않았다. 공개 합성 사례와 명시적인 test double로 다음 검사를 준비한다.

사용자가 고른 첫 범위는 개발 작업 메시지의 진행 보고·완료 보고·질문 표시다. completion_report는 **“완료됐다고 쓴 문장”**을 뜻한다. 코드 실행 성공, CI 성공, 검증된 전체 업무 완료, 승인 완료를 증명하지 않는다. 화면의 표시명도 “완료됨” 대신 “완료 보고”를 사용한다.

이미 구현한 것과 아직 없는 것

구분	현재 확인한 범위
구현: 분류와 학습	고정된 8개 의미를 분류하는 Go 모델과 규칙 기준선. V2는 별도로 작성한 합성 학습 320개와 validation/calibration/test 각40개로 실제 학습·평가했다.
구현: 선택된 모델	v1_warm_start, 1,024구간, 32,960바이트, step 1,520→1,920, temperature 0.9. 두 2,048구간 후보는 비교했으나 선택하지 않았다. 이 파일럿을 위해 새 3-class 모델을 학습한 것은 아니다.
구현: 공개 bridge	SnapshotReader.Read와 Adapter.Propose, opaque 참조, 현재 active 라벨의 명시적 의미 연결, 중복·누락·inactive·그룹 제외, canonical 버전 확인, shadow 출력.
구현: 경계 테스트	test double로 읽기 범위·상태 후보의 모호함·버전 없음·중복 표시·본문 비노출 등을 검사하는 테스트가 있다. 실제 native reader나 실제 catalog를 호출한 검증은 아니다.
미구현	실제 Riido reader, 현재 native catalog 확인, 표시를 받을 정확한 메시지/업무 위치, 본문 revision 연결, 리비전 이벤트 검증, 실제 화면 통합, 새 파일럿 harness와 비용 측정.
첫 범위 밖	업무 상태 쓰기, 실제 reaction 추가, 알림 발송, 취소 실행, 모델/추론 수준 조절, 실제 원문을 외부 학습·공개에 사용하는 작업.

기존 V2의 새 평가 결과는 34/40이며 언어별로17/20이다. 완료 보고5/5, 질문4/5였지만 각 의미가5개뿐이다. 전체 8개 의미에서 confidence 0.9 이상인 비모호 제안17개가 맞았다는 결과를 이 세 표시의 실사용 정확도나 운영 정밀도100%로 바꾸지 않는다. 현재 native 라벨과 팀별 이모지 설정은 알 수 없다. 이번 초안은 운영 연결 완료나 2,400개의 실제 업무 검증을 주장하지 않는다.

다시 내려받은 모델의 실제 CLI 확인

게시 revision 81335eadd9f2753d3b86c932e9b00c636714e3b4의 모델로 공개 합성 예문4개를 실행했다. 의도는4/4맞았지만 고정 confidence0.9를 넘긴 질문 한 건만 라벨·이모지를 제안했다.

예문 의도	confidence(반올림)	실제 shadow 결과
진행 보고	0.858	기준 미달로 보류
완료 보고	0.821	기준 미달로 보류
질문	0.971	라벨·이모지 제안
계획	0.815	기준 미달로 보류; 첫 세 표시 범위 밖

모든 출력의 mutation/state change는false였고 실제 reader는 연결하지 않았다. 이4개의 짧은 입력을 처리한 macOS 프로세스의 최대 OS RSS는5,488,640바이트(약5.23MiB)였다. 모델 읽기·분류·JSONL·제안 처리를 포함한 이 프로세스의 관측이며 실제 catalog 조회·화면 배치 비용이나 처리량의 증거가 아니다. “의도4/4”와 “표시 제안1/4”, “실제 adapter 파일럿0회”를 구분해 기록한다. 낮은 confidence를 통과시키려고 threshold를 낮추지 않는다.

근거: V2 결과와 한계, 학습 기준, catalog bridge. 별도 smoke receipt는 이 private cache의 publication/DEVELOPMENT-SMOKE.json에 있다.

표시 후보와 현재 라벨 허용집합

분류 결과	파일럿 표시명	기본 이모지 후보	canonical code	업무 상태 변경
progress	진행 보고	🛠️	1f6e0-fe0f	없음
completion_report	완료 보고	✅	2705	없음
question	질문	❓	2753	없음

표시명과 이모지는 설정 가능한 초안이며 실제 catalog에 존재한다고 가정하지 않는다. blocker, reference, cancel_request, planned, unclear에는 이번 파일럿의 세 표시를 강제로 붙이지 않는다. 8개 의미의 확률을 그대로 사용하며 세 의미만 남겨 확률을 재정규화하거나 차선의 허용 의미를 대신 선택하지 않는다.

라벨 허용집합은 읽기마다 다음 교집합으로 만든다.

1. 앱의 신뢰할 수 있는 조회 경계가 현재 scope에서 읽은 라벨이다.
2. 현재 active이고 그룹 container가 아닌 실제 라벨이다.
3. 사용자가 설정한 세 의미 중 하나에 opaque 참조로 명시적으로 연결돼 있다.
4. 같은 참조 또는 의미 연결이 중복·충돌하지 않는다.

현재 연결이 누락·삭제·inactive이면 해당 라벨을 제안하지 않는다. 이름이나 색, 배열 순서로 라벨 의미를 추측하거나 새 라벨을 만들지 않는다. 실제 native ID·이름·인증정보와 opaque 대응표는 private reader 안에 둔다. 이미 붙은 라벨·동일 이모지는 추가 표시 제안이 없는 no-op이다. 이모지도 확인된 허용목록만 전달하고, 초안의 기본 후보를 native 설정으로 자동 승격하지 않는다.

모델 기준은 기존 catalog bridge의 confidence 0.9와 margin 0.05를 유지한다. 앞의 CLI 시험은 margin0이므로 다음 catalog 파일럿과 구분한다. guarded input, 범위 밖 결과, 모호한 내용, 기준 미달은 표시를 보류한다. 모델 파일을 읽지 못하면 학습하지 않은 규칙으로 조용히 대체하지 않는다. 규칙은 명시적으로 표시한 별도 비교군이고 점수는 보정된 확률이 아니다.

제안 흐름과 업무 revision 이벤트

계획하는 흐름은 이미 보유한 메시지 → 현재 opaque snapshot 조회 → 잠긴 모델 분류 → 세 표시 허용집합 검사 → revision 연결 검사 → private shadow 미리보기/관측이다. 실제 원문이나 추가 문서를 reader가 새로 가져올 필요는 없다. 현재 bridge는 이미 보유한 Request.Text를 받으며, metadata 조회에는 요청한 opaque Work 참조만 전달한다.

파일럿 harness는 StatePlanningAvailable=false로 두고 lifecycle event를 공급하지 않는다. mutation_executed:false, state_change:false를 모든 행에서 확인한다. CandidateStatusRef는 업무 완료나 상태 변경 승인으로 취급하지 않는다. 이 bridge에는 verified event나 사용자 JSON의 trusted flag를 받는 API 자체가 없다.

표시 배치용 revision 근거와 업무 상태 전이 근거를 구분한다.

근거	향후 요구할 연결	현재 상태
revision 관측 receipt/event	인증된 앱 조회 경계의 provenance, owner scope, opaque Work 참조, 원본 canonical 업무 revision, 표시할 content 참조와 content revision, 관측/변경 event 참조	새 파일럿 harness 및 실제 reader에 아직 연결하지 않음
진행/완료 lifecycle 사실	별도 업무 시스템이 확인한 started/completed 사실, 대상 업무·scope·명령, 기대/현재 revision, 실제 업무 결과와 중복 처리 receipt	첫 표시 파일럿 범위 밖. 모델 문장이나 JSON flag로 생성할 수 없음

revision 관측 receipt는 “이 표시가 어느 업무와 본문 revision에 속하는가”를 고정하기 위한 것이다. 관측 시각이나 ReadTimes만으로 최신 revision 또는 실행 성공을 증명하지 않는다. 업무의 기대 revision과 현재 revision이 다르거나 본문이 수정됐으면 이전 제안은 배치하지 않고 stale로 기록한다. 새 revision을 다시 읽은 뒤 별도 제안을 계산해야 한다. 시간·행 번호·임의0/1을 canonical revision 대신 쓰지 않는다.

canonical 버전이 없는 항목에서도 현재 bridge는 라벨·이모지 추천을 계산할 수 있다. 다만 그 결과는 현재 업무에 배치 가능한 표시로 검증되지 않은 내용 추천이다. 새 파일럿 harness에서 revision 연결을 확인하기 전에는 업무 위치에 붙이지 않고 unavailable로 남긴다. 기존 bridge의 Request/Work에는 별도의 content revision과 event receipt가 없으므로 이 연결은 추가 설계·구현 대상이다.

Work·라벨·상태의 별도 읽기를 단일 atomic snapshot이라고 하지 않는다. 읽기 시점을 그대로 남기고 catalog_consistency:unqualified를 유지한다. 이후 실제 표시를 연결할 때도 현재 조회 권한·scope·catalog·본문/업무 revision을 앱이 확인해야 한다. shadow 출력은 lasting permission이 아니다.

합성 test double로 먼저 준비할 검사

아래는 검사 설계이며 이번 문서 작성에서 실행하지 않았다. 수작업 fake prediction을 사용하는 정책 테스트와 실제 잠긴 모델의 분류 테스트를 분리해 기록한다. fake score의 통과를 모델 정확도나 native 조회 성공으로 표현하지 않는다.

합성 조건	기대하는 결과
현재 진행 보고 + 허용된 진행 라벨/이모지 + 동일 revision	진행 보고 표시 후보만 제안. 업무 상태 유지
전체 업무를 끝냈다는 문장 + 완료 표시 허용	“완료 보고” 후보. 실행 성공·업무 done 사실 없음
완료/취소를 언급하는 실제 정보 질문	질문 후보만 허용. lifecycle 변경 없음
일부 검사는 끝났지만 같은 업무의 작업을 계속함	진행/완료 구분을 검수하며 전체 완료로 단정하지 않음
인용·부정·가정·충돌·다른 5개 의미	세 표시를 강제로 선택하지 않음
active catalog에서 연결 누락·inactive·group·중복·foreign scope	잘못된 참조 제외 또는 요청 거절
canonical 업무 revision 없음·비canonical 값·revision 변경·본문 수정	가짜 버전 없음. 업무 위치에 배치하지 않음
같은 본문 revision/명령의 재전달·동일 표시 존재	중복 표시 없음. 재전달/기존 표시 no-op 구분
reader error 또는 scope에 없는 Work	원문/credential 노출 없음. 해당 Work를 분류·배치하지 않음
숫자상 일관되지 않은 확률·guarded input·oversized text	표시 보류/거절

관측 항목은 모델 hash·의미·confidence·원문 없이 해석 가능한 보류 이유·opaque case/family 참조·현재 라벨 허용집합 fingerprint·revision 연결 결과·기존 표시 여부·분류/조회/전체 처리 비용이다. 실제 원문과 native 대응표는 별도 private 저장소에 둔다. 분류기 hot-path의 기존 allocation0 측정을 reader·JSON·harness의 총 비용으로 바꾸지 않는다.

100개 → 400개 → 2,400개 표본 계획

1. 초기100개 검수: 먼저 공개 합성 test double로 배치/보류 경계를 확인한다. 실제 자료를 다룰 단계에서는 사용자가 허용한 개발 업무 원문을 private에 보관하고, 가능하면 예측을 보지 않은 검수자가 세 표시와 경계 사례를 주석한다. 완료 보고의 문장 의미와 실제 업무 완료 사실은 별도 칸이다. 이100개는 개발·검수 자료이고 새 최종 평가셋이라고 부르지 않는다.
2. 서로 다른 업무·문맥400개: 여러 개발 작업, 단계, 문체, 두 언어 및 혼합 언어, 질문/인용/부정/부분 완료/현재 진행을 포함한다. 100개에서 본 실패는 공개 합성 재현으로 별도 기록하고 원문을 그대로 외부로 옮기지 않는다. 업무·incident·대화 문맥 family 수를 행 수와 함께 센다.
3. 총2,400개로 확대: 부족한 family를 늘리는 것이 목적이다. 같은 문장의 반복·이름 변경·번역·같은 업무 revision 연쇄는 독립 샘플로 집계하지 않는다. 같은 사건의 변형은 같은 family에 묶어 train/validation/calibration/최종 평가를 함께 넘나들지 않게 한다. 행2,400개가 family2,400개를 뜻하지 않는다.

새 학습을 시작하기 전에 실제 자료의 사용 범위, 주석 기준, family grouping, split, 모델 후보, calibration과 고정 기준을 잠근다. 이미 관측한100/400개와 노출된 V1/V2 평가를 다음 최종 모델 선택용 시험으로 다시 쓰지 않는다. 새 최종 평가에는 새 family를 남기고 별도 검수한다. 단계마다 잘못된 완료 보고 표시, 질문 오분류, 보류율, 중복/오래된 표시, 전체 비용을 언어·의미·family별로 확인하며, 틀린 결과를 삭제하거나 threshold를 내려 통과시키지 않는다.

비공개와 공개 주장의 경계

실제 원문·실제 사건 receipt·native ID·업무 링크·credential은 private가 기본이다. 외부 공개는 허가된 요약과 합계만 사용한다. 사례 문장을 공개해야 한다면 별도로 허가된 내용 또는 새로운 공개 합성 재현으로 준비한다. 원문 hash·opaque 참조도 자동으로 공개 목록에 넣지 않는다.

정책 test double 통과, 합성 모델 평가, 실제 read-only 조회, 실제 화면 표시, 실제 업무 상태 전이를 각각 따로 집계한다. 이번 초안으로 주장할 수 있는 것은 세 표시의 범위와 다음 검사 계획을 구체화했다는 사실뿐이다. 새 훈련, 실제 reader 접속, 실제 표시 설치, 서비스 쓰기, 100/400/2,400개 검수 완료, 실사용 정확도 향상을 주장하지 않는다.

게시·전체파일검증기록. OS RSS와Go heap/GPU메모리는 측정 범위가 달라 더하지 않는다.