@buzzni/saycode-cli 0.9.8 → 0.9.10

package/README.md

@@ -211,10 +211,20 @@ saycode를 따로 설치하지 않은 작업PC는 `npx @buzzni/saycode-cli searc
 마무리합니다(specs/codexcli-approval-session-binding R12). 값이 없거나 모르는 값이면 아무것도 싣지 않고,
 자식은 지금처럼 사람의 답을 기다립니다.
 
+`agent prompt`의 결과는 `resultVersion:2`입니다. `ok:true`는 서버 저장 행을 다시 조회·복호화하여 본문과 설정까지 확인했다는 뜻이며 `storage.seq`가 확인한 위치입니다. `delivered:true`는 그 서버 메시지 ID의 **런타임 소비 증거**가 있어야 나옵니다. 구버전의 `delivered`는 같은 뜻으로 읽으면 안 됩니다. 큐 수락(receipt)만으로는 소비나 답변 성공이 아닙니다.
+
+`--wait` 없이도 저장 뒤 runtime의 수락·거부 receipt를 최대 5초 기다려 거부를 바로 알려 주며, receipt가 없으면 `outcome:unconfirmed`로 돌아옵니다. `--wait`는 저장 이후 같은 입력 ID의 증인으로 기다립니다(최대 600초, 저장·검사 포함 620초). `response.attribution=bound`일 때만 `response.answer`가 이번 질문의 단독 답변이며, 공동 배치·steer·질문/자유문 권한 답변이 끼면 `consumed-with`와 입력 목록/사유를 돌려줍니다. receipt timeout은 `outcome:unconfirmed`이고 실패로 확정하지 않습니다. 소비는 확인됐지만 마감까지 작업이 끝나지 않으면 같은 증거를 담은 `wait_timeout`(exit 3)이고, 소비된 턴이 `--until` 조건 없이 끝나면(예: `consumed-with`) 마감을 기다리지 않고 `outcome:unconfirmed`로 바로 돌려줍니다. `next.command` 또는 `happy agent read <id> --since <storage.seq>`로 늦은 receipt·소비를 정산하세요.
+
+재실행에 대비하려면 **송신 전** `--local-id <id>`와 대상·본문·설정을 보관합니다(1–128 ASCII 영숫자 및 `._:-`). 같은 ID/동일 intent로 저장 응답 유실을 한 번만 재시도하며, 다른 본문이나 설정이면 `localid_conflict`입니다. CLI가 죽은 뒤에는 보관한 같은 ID로 다시 실행해 원래 저장 행을 확인합니다. 그사이 대상 runtime이 재시작되면 확인 조건이 달라져 `localid_conflict`가 되지만, 본문이 같으면(`storage.existing.sameBody:true`) `storage.existing`과 `next.command`(`happy agent read <id> --since <seq>`)로 원래 요청의 소비 여부를 확인할 수 있습니다. 본문이 다르면 그 행은 다른 질문이므로 `next.command`를 주지 않습니다. ID를 보관하지 않은 송신은 본문·시각으로 찾지 않으므로 결과를 알 수 없습니다. 복호화/조회 실패는 `storage-verification-unknown`입니다. 미확인 요청을 새 ID로 자동 재전송하지 않습니다.
+
+입력 증거는 지원 Claude/Codex 세션의 명시적 opt-in(`HAPPY_INPUT_EVIDENCE=1`, 기본 OFF)과 살아 있는 동일 runtime/remote epoch 확인이 필요합니다. 그 확인이 안 되는 세션(ON marker 없는 .358, 미지원·OFF 세션)은 `CLI_GUARDED_PROMPT_ROLLOUT`(기본 off) 동안 이전처럼 보내되 결과는 `resultVersion:2`, `delivered:false`, `delivery.state:"unsupported"`로 소비를 주장하지 않습니다. 이 플래그를 켜면 같은 세션은 `prompt_unsupported`로 보내기 전에 닫힙니다. Desktop 자동 opt-in은 T2r pin 전까지 꺼져 있습니다. A6 생성 안내는 T4rt와 함께 수락합니다. 허브 자동 알림은 `HUB_BRIDGE_OWNERSHIP_ROLLOUT`(기본 off) 동안 이전과 같고, 켜면 main이 개인은 같은 계정, 회사는 confirmed owner만 수신하도록 확인하며 확인 실패 시 배지에서 복구를 안내합니다. 사람의 직접 입력은 유지됩니다.
+
 `steer` 성공의 `accepted:true`는 세션 RPC가 요청을 받았다는 뜻이며 실제 transcript 전달 완료를
 뜻하지 않습니다(`delivered:false`). 끝난 턴의 후속 작업에는 `prompt`를 사용합니다. 에이전트 세션은
 자기 자신에게 입력할 수 없고, `steer`와 `stop`은 depth와 관계없이 원장에 기록된 자기 후손에게만 보낼 수
-있습니다. 후손이 아닌 세션에 `prompt`하려면 소유가 검증돼야 하며, `not_owned`를 받으면 `read`로만 보고
+있습니다. 예외로 사람이 시작한 Claude·Codex 허브(broker 경로, depth 0)는 소유가 검증된 형제 세션(`ls`의
+`ownership.relation:"own-sibling"`)에도 보낼 수 있으며, 이때 `stop`은 프로세스를 끄지 않고 지금 응답만 끊습니다
+(`mode:"turn-abort"`, 터미널에서 쓰는 Claude는 stop을 `controlled-by-user`, steer를 `local-mode`로 거부). 형제 결과에는 대상 `title`과 `ownership.relation`이 붙습니다. 형제에게 보내기 전에 대상 제목과 전체 ID를 확인합니다. 후손이 아닌 세션에 `prompt`하려면 소유가 검증돼야 하며, `not_owned`를 받으면 `read`로만 보고
 다시 시도하지 않습니다(ADR-078). `stop`은 보관·삭제를 하지 않습니다. spawn 한도(`whoami`의 `maxSpawn`)는 세션이
 도는 머신의 코어·메모리에서 산정하므로 머신마다 다르고, 최근 6시간 안의 spawn만 세는 롤링 윈도우라
 소진돼도 시간이 지나면 회복됩니다(`budgetResetsAt`, ADR-063). 데몬이 확인하지 못한 시도도 같은
@@ -510,3 +520,9 @@ node ../../scripts/verify-cli-tarball.mjs out/cli/buzzni-saycode-cli-*.tgz
 
 번들에 포함된 서드파티 오픈소스는 각자의 라이선스를 유지하며, 목록과 전문은 패키지에
 동봉된 `THIRD-PARTY-NOTICES.md`에 있습니다 (빌드 시 실제 번들 내용에서 자동 생성).
+
+T2 응답은 소비한 native turn과 runtime에 결속합니다. `prompt --wait`의 질문·구조화 출력도 그 턴만 판정하며 `structuredOutput`과 `structured_output_missing`을 v2에 유지합니다. 명시적 runtime 거부는 `prompt_rejected`, exit 3이며 localId·storage·거부 증거를 보존합니다. 백그라운드 후속 관측은 `response.followUps`에 따로 남기고 최초 답변을 덮지 않습니다.
+
+송신 당시 검증된 runtime/epoch는 암호화 요청에 보존하므로 host 재시작 뒤에도 `read --since`로 과거 소비 사실을 조회할 수 있습니다. 이 기록은 새 runtime에 송신 권한을 주지 않습니다. 검증 기록이 없는 구 요청은 현재 runtime이 같고 ON이어도 unknown으로 남습니다. 기록을 소급 생성하거나 과거 소비를 확인됐다고 표시하지 않습니다.
+
+Codex 명령/패치 승인은 tool 시작 전에 대기할 수 있지만 .359의 REST pending 상태에는 approval↔turn 결속이 없습니다. `prompt --wait --until waiting-input`은 이 승인을 현재 턴으로 추측하지 않습니다. 해당 대기가 확인되지 않은 채 timeout되면 `outcome:unconfirmed`, `waitingInput:{state:"unsupported",reason:"pending-approval-turn-binding-unavailable"}`를 반환합니다. 이는 pending 승인이 요청 B에 속한다는 뜻이 아닙니다. Claude 질문·Codex 질문은 실제 tool-call ID/턴 결속이 있을 때 판정하며, 채널 routing requestId로 대체하지 않습니다. 미확인 결과를 새 메시지로 자동 재시도하지 마세요.