프로세스가 살아있습니다. 트랜스크립트(transcript)가 변경되었습니다. 중단 훅(stop hook)이 실행되었습니다. 권한 프롬프트가 나타났습니다.

이것들은 관찰(observations)이지, 세션 상태(session states)가 아닙니다.

만약 개발자 도구가 각 신호를 직접 배지(badge)로 변환한다면, 결국 완료된 턴(turn)을 여전히 대기 중이라고 보고하거나, 조용한 작업을 성공한 것으로 보고하거나, 장부 기록(bookkeeping write)을 새로운 작업으로 보고하게 될 것입니다. 더 신뢰할 수 있는 모니터는 증거(evidence)와 사용자에게 보여지는 시간 제한적 결론(time-bounded conclusion)을 분리해야 합니다.

하나의 제공자가 아닌, 하나의 세션부터 시작하세요

관찰의 단위는 단일 로컬 세션(session) 또는 스레드(thread)여야 합니다. 제공자 배지는 나중에 여러 스레드를 요약할 수 있지만, 그들의 정체성을 지워서는 안 됩니다.

모든 관찰에는 최소한 다음 항목이 필요합니다:

• 제공자(provider);
• 안정적인 세션 키(session key);
• 관찰 시간(observation time);
• 가장 최근의 관련 의미론적 활동 시간(newest relevant semantic activity time).

이것은 운영 모델(operational model)입니다. 생성된 코드가 정확하다거나 프로젝트 수준의 작업이 완료되었다고 주장하는 것이 아닙니다.

7가지 주요 상태를 사용하세요

제가 발견한 가장 작으면서도 유용한 상태 집합은 다음과 같습니다:

inactive
running
waiting_for_user
...

running은 현재 턴(turn)과 연결된 새로운 시작, 진행 상황, 도구 사용(tool-use), 또는 스트리밍(streaming) 증거를 필요로 합니다.

waiting_for_user는 아직 답변되지 않은 명시적인 권한 요청, 유도(elicitation), 명확화(clarification), 또는 기타 입력 요청을 필요로 합니다.

completed는 현재 턴에 대한 종료 이벤트(terminal event)와 이를 대체하는 이후의 활동이 없음을 필요로 합니다. 이것이 코드가 정확하다는 것을 의미하지는 않습니다.

blocked는 인증, 할당량(quota), 정책, 제공자(provider), 또는 실행 실패와 같이 정상적인 지속을 방해하는 명시적인 실패를 필요로 합니다.

stalled는 의도적으로 더 약한 상태입니다. 턴이 실행 중이었으나, 종료 또는 차단 이벤트 없이 기록된 침묵 임계값(silence threshold)을 초과한 경우입니다. 침묵은 정체된 추론(stalled inference)을 뒷받침할 수는 있지만, 완료를 증명할 수는 없습니다.

unknown은 유휴(idle) 상태와 같지 않습니다. 이는 증거가 누락되었거나, 모순되거나, 지원되지 않거나, 더 강력한 결론을 내리기에는 너무 오래되었음을 의미합니다.

상태 이름에서 원인과 확신을 제외하세요

제품들은 종종 표현(presentation)과 증거(evidence)를 혼합함으로써 상태(state)를 불필요하게 늘리곤 합니다. 대신 다음 항목들을 수식어(modifier)로 유지하세요:

• reason (원인): 권한(permission), 인증(auth), 속도 제한(rate limit), 프로세스 종료(process exit), 또는 침묵 타임아웃(silence timeout);
• freshness (신선도): 의미론적 이벤트(semantic event)의 시점;
• confidence (확신도): 명시적(explicit), 추론된(inferred), 또는 폴백(fallback);
• attention (주의): 없음(none), 정보성(informational), 사용자 작업(user action), 또는 긴급 복구(urgent recovery);
• turn identity (턴 식별자): 중복 제거(deduplication)에 사용되는 키;
• source (출처): 훅(hook), 세션 기록(session record), 프로세스 신호(process signal), 파일 메타데이터(file metadata), 또는 휴리스틱(heuristic).

이렇게 하면 UI에서 모든 에러 유형마다 새로운 최상위 상태(top-level state)를 생성하지 않고도 blocked: authentication과 같이 표현할 수 있습니다.

상충하는 신호를 의도적으로 해결하세요

신호들이 서로 일치하지 않을 때는, 현재 턴(turn)에 속하는 가장 구체적이고 신선한 증거를 우선시하세요:

1. 권한 요청(permission request), 터미널 이벤트(terminal event), 또는 구조화된 제공자 에러(structured provider error)와 같은 명시적인 의미론적 이벤트(semantic events).
2. 이전 이벤트를 대체하는 이후의 사용자 또는 에이전트 활동.
3. 상관관계가 있는 프로세스 및 세션 활동.
4. 의미론적 타임스탬프(semantic timestamp)가 존재하지 않을 때의 파일 수정 시간.
5. 침묵 기반 추론(silence-based inference). 이는 stalled 상태를 생성할 수는 있지만, 결코 completed 상태를 생성해서는 안 됩니다.

두 번째 규칙은 첫 번째 규칙만큼 중요합니다. 유효한 완료(completion) 이벤트는 이후의 사용자 프롬프트가 새로운 턴을 시작하는 즉시 오래된 것(stale)이 됩니다.

문자열뿐만 아니라 전이(transition)를 테스트하세요

모니터가 단 하나의 해피 패스(happy-path) 마커를 인식한다고 해서 견고한 것은 아닙니다. 최소한 다음 사항들을 테스트해야 합니다:

• 새로운 턴(turn)이 이전의 완료(completion)를 상속받지 않는지;
• 하나의 이벤트를 재현(replaying)했을 때 하나의 알림(notification)이 생성되는지;
• 이후의 활동이 이전에 완료되었거나 대기 중인 상태를 취소(revokes)하는지;
• 권한 요청(permission requests)이 일반적인 완료(completion)와 구별되는지;
• 에러 형태의 터미널 레코드(terminal records)가 완료가 아닌 차단(blocked) 상태가 되는지;
• 침묵(silence)이 결코 성공을 조작(fabricates)하지 않는지;
• 재시작 복구(restart recovery)가 오래된 경고를 재현하지 않고 상태를 재구성하는지;
• 하나의 완료된 세션이 실행 중인 다른 세션을 숨기지 않는지;
• 잘못된 형식의 타임스탬프(malformed timestamps)와 부분적 쓰기(partial writes)가 안전하게 저하(degrade)되는지;
• 오래된 완료 상태 및 정체된(stalled) 상태가 만료되는지;
• 테스트가 로우 세션 데이터(raw session data)가 읽히고, 유지되고, 전송되는 지점을 검증하는지.

이러한 어휘는 특정 제품을 넘어 유용하게 사용될 수 있습니다. 이는 유지보수자, 검토자, 연구자들에게 상태 주장(status claim)이 무엇을 의미하는지, 그리고 어떤 증거가 이를 취소(revoke)할 수 있는지 묻는 공통된 방식을 제공합니다.

전체 분류 체계(taxonomy), 전이 모델(transition model), 그리고 평가 수준(evaluation levels)을 읽어보세요