# 의도와 조건 관측을 따로 담는 입력

2026-10-10. [SDK PR16](https://github.com/kimjooyoon/gooo-decision-runtime/pull/16)을
원래 push·PR CI 통과 후 main `13d7f010ed3d69735e59d3abb58fbd5d19a72881`에 병합했습니다.
실험한 후보는 `c2e095964e9f7867f62328bbd6dc254b047dbe38`이며 병합된 파일 트리가 같습니다.
새 모델 학습에 쓸 `ConditionFeaturesInto` 입력 함수를 추가했습니다.

기존 방식에서는 실패 메모를 길게 붙이면 의도 문장의 위치 특징도 바뀔 수 있었습니다.
새 방식은 소스 구조 64개, 한글·영문 의도 128개, 관측 조건 64개를 서로 다른 칸에 담습니다.
출력 배열은 256개 float32, 즉 1,024바이트입니다. 이는 출력 배열의 크기이며 전체 모델이나
프로세스 RAM 측정값은 아닙니다.

기대 참/거짓, 실제 미관측/참/거짓, 관련된 선택, 후보 조합과 입력 정수가 각각 자리를 갖습니다.
정수는 여덟 바이트로 나눈 다음 표현하므로 큰 값을 통째로 실수로 바꾸지 않습니다.
전체 SDK race·정적 검사와, signed int64 양 끝값·큰 정수·512바이트 의도·동시 호출·실패 시
출력 보존 검사를 통과했습니다. 정상 입력의 특징 추출은 계약 검사에서 힙 할당 0회였습니다.

## 실제 Gooo 기록에 적용한 확인

컴파일러 `92dc06b3`로 이미 실행한 조건 피드백 기록을 읽었습니다. 원래 입력의 소스 특징과
한영 의도는 당시 기록된 바이트 수와 각각의 해시로 확인했습니다. 조건값은 첫 완료된 후보의
정확한 정수·기대값·실제 관측·조합을 그대로 사용했습니다.

| 확인 | 결과 |
| --- | --- |
| 원래 재판단 입력 | 2개 라운드 × 3개 선택 = 6개 |
| 새 특징 추출 | 원본·관측 없음·가상 참거짓 교환, 총 18회 |
| 소스와 의도 구간 보존 | 6/6, 세 변형의 앞 192개 값 동일 |
| 참거짓 교환 시 바뀐 위치 | 모두 197·198·200·201, 기대값·관측값 칸만 변경 |
| 입력 정수 | 원래 `-9007199254740995` 보존 |
| 새 모델 판단 / 새 native 실행 / 학습 | 0 / 0 / 0 |

가상으로 교환한 값은 원래 실행 결과나 Gooo 기대값에 반영하지 않았습니다.
여기서 확인한 것은 입력 표현입니다. 선택 정답률은 새 가중치를 학습하고 새 코드 구조에서
평가해야 알 수 있습니다. 현재 모델 로더는 새 입력 버전을 거절해 기존 가중치와 섞이지 않게 합니다.

## 원본

`original/`에는 사전 프로토콜, 당시 Go 확인 코드, 여섯 결과 행, SDK 소스 번호,
원래 피드백 기록과 SDK CI·병합 응답이 있습니다. 압축 해제 후 원본과 바이트 비교를 했습니다.
첫 확인 명령은 헤더 길이를 한 바이트 짧게 계산해 특징 추출 전에 중단됐습니다.
경계를 문자열 길이에서 계산하도록 고친 뒤 18개 투영을 완료했으며 이 이력도 남겼습니다.

```sh
shasum -a 256 -c SHA256SUMS
gzip -dc original/result.json.gz
```

각 결과에는 원래 기록의 해시와 원본·관측 없음·가상 교환 배열의 해시가 있습니다.
확인 코드의 생산자는 위의 SDK 후보 소스입니다. 기존 모델로 수행했던24회 점수 비교와
이번18회 특징 추출은 서로 다른 관측입니다.

[배열의 전체 항목과 다음 학습 기준](https://github.com/kimjooyoon/gooo-decision-runtime/blob/13d7f010ed3d69735e59d3abb58fbd5d19a72881/docs/condition-feature-channels.md).
병합 후 [SDK CI38017911450](https://github.com/kimjooyoon/gooo-decision-runtime/actions/runs/38017911450)도
같은 소스에서 통과했습니다. 최초 공개 뒤 확인한 완료 응답과 작업 결과를 원본에 추가했습니다.