FullAgenticStack WhatsApp-first: RFC-WF-0018

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you’ve already provided) here? Once I have the text, I’ll translate it into Korean while preserving the original formatting, markdown syntax, and technical terms.

초록

이 문서는 WhatsApp‑first 시스템을 위한 **State Model & Command Lifecycle (SMCL)**을 명시합니다. SMCL은 명령 실행 및 복구를 위한 규범적인 유한 상태 기계(FSM)를 정의하며, 다음을 포함합니다:

• 허용된 상태
• 유효한 전이
• 종료 조건
• 증거 방출 요구사항

SMCL은 모든 구성 요소(명령 실행, 보안 게이팅, 가시성, 복구/보상 및 감사)가 일관된 라이프사이클 모델을 사용하도록 보장하여 단계 드리프트를 방지하고 결정론적 도구 및 인증을 가능하게 합니다.

Index Terms – finite‑state machine, lifecycle states, command execution, recovery states, evidence emission, idempotency, distributed systems.

Relationship to Other RFCs

구현체들은 종종 라이프사이클 단계와 전이 순서에서 차이를 보이며, 이는 상호 운용성 및 감사를 방해합니다. SMCL은 단일 규범적인 라이프사이클 FSM을 제공하여:

1. 상태 명명 규칙을 표준화하고
2. 유효한 전이를 제한하며
3. 종료 상태를 정의하고
4. 각 전이에 필요한 증거를 명시하며
5. 중복/재시도 상황에서의 멱등 재진입 동작을 공식화합니다

NOTE: SMCL은 내부 워크플로 엔진을 정의하지 않으며, 관찰 가능한 동작만을 정의합니다.

일반적인 RFC 규범 키워드 (MUST, MUST NOT, SHOULD, SHOULD NOT, MAY)가 적용됩니다.

용어

주요 명령 수명 주기 상태

Notes

• 읽기 전용 명령은 확인 상태(S2/S3)를 건너뛸 수 있음.
• 일부 구현은 authz_pending/authorized를 병합할 수 있음; 이 경우에도 의미적으로 동등한 증거와 순서를 제공해야 함.
• received는 전‑엔벨로프이며 상태를 변형 해서는 안 됨.
• canonicalized는 command_id가 존재하는 가장 초기 시점임.
• confirmed는 인간 확인 게이트가 만족됨을 나타냄.
• authorized는 범위/스텝‑업 게이트가 만족됨을 나타냄.
• started는 실행이 시작되었으며 부수 효과가 발생할 수 있음을 나타냄.
• executed는 효과가 완료되고 일관됨을 나타냄.
• failed는 실행이 오류와 함께 종료되었으며 복구가 가능할 수 있음을 나타냄.
• compensated는 보상이 정의된 터미널 교정을 달성했음을 나타냄.

허용된 전이

다음 전이들은 반드시 적용되어야 합니다:

received               → canonicalized
canonicalized          → confirmation_required   (변경 작업이며 정책에 의해 자동 확인되지 않은 경우)
confirmation_required → confirmed
canonicalized          → authz_pending          (읽기 전용 또는 사전 확인 검증 경로 허용)
confirmed              → authz_pending
authz_pending          → authorized
authz_pending          → rejected
authorized             → started
started                → executed
started                → failed
started                → canceled
failed                 → compensated            (보상이 성공적으로 실행된 경우에만)
executed               → compensated            (비즈니스 정의 보상이 존재하고 관리되는 경우에만 허용)

잘못된 전이

잘못된 전이가 시도될 경우(예: executed → started), 시스템은 반드시:

1. 전이를 거부한다.
2. invalid_transition_attempt 를 나타내는 증거를 발행한다.
3. 이전의 최종 상태를 유지한다.

추가 제약 조건:

• 모든 변이 명령에 대해 started는 confirmed가 발생하지 않은 경우 절대 발생해서는 안 된다(정책에 명시된 “안전 자동 확인”이 명시적으로 선언된 경우는 예외이며, 이는 반드시 감사 가능하고 드물어야 함).
• 모든 변이 명령에 대해 started는 authorized가 발생하지 않은 경우 절대 발생해서는 안 된다.

멱등성 및 중복 처리

• 동일한 논리 명령이 여러 번 전달될 경우(동일 idempotency_key):

  • 터미널 상태(executed | rejected | canceled | compensated): 시스템은 결과를 재생해야 하며 재실행을 하지 않아야 합니다.
  • Started: 중복은 in_progress 보기를 반환해야 하며 병렬 실행을 생성해서는 안 됩니다.

• 기본 명령은 executed, rejected, canceled, compensated 중 하나에 도달한 후 started 상태로 다시 진입해서는 안 됩니다.

복구‑명령 규칙

복구 명령은 동일한 FSM을 따르며 다음 추가 규칙이 적용됩니다:

1. Reference the target_command_id. → target_command_id를 참조합니다.
2. Emit evidence linking to the target. → 대상에 연결되는 증거를 발행합니다.
3. Respect authorization/confirmation/step‑up according to risk class (RCP/ACSM/PPGP). → 위험 등급(RCP/ACSM/PPGP)에 따라 권한 부여/확인/스텝‑업을 준수합니다.

보상 모델

1. target_command is in failed or executed (depending on business semantics). → target_command가 failed 또는 executed 상태에 있습니다 (비즈니스 의미에 따라).
2. A recovery command executes the compensation plan. → 복구 명령은 보상 계획을 실행합니다.
3. target_command enters compensated only when the plan succeeds and evidence confirms convergence. → target_command는 계획이 성공하고 증거가 수렴을 확인할 때만 compensated 상태가 됩니다.

• Compensation MUST be append‑only and auditable. → 보상은 반드시 추가 전용이며 감사 가능해야 합니다.

증거 방출

각 라이프사이클 전환마다 시스템은 최소한 다음을 포함하는 증거 아티팩트를 반드시 생성해야 합니다:

• lifecycle.command_id
• lifecycle.transition (예: received→canonicalized)
• lifecycle.timestamp
• lifecycle.evidence_type (예: state_change, invalid_transition_attempt)
• 종속 RFC (CCP, EAS, RCP, IDS)에서 요구하는 추가 컨텍스트

정확한 스키마는 **RFC‑WF‑0006 (EAS)**에 정의되어 있습니다.

적합성

• 최소 준수 테스트는 **RFC‑WF‑0017 (TVRS/CATS)**에 매핑됩니다.
• 구현은 MUST 각 상태, 전이, 종료 조건 및 증거 방출 요구사항을 테스트하는 모든 TVRS 테스트 벡터를 통과해야 합니다.

Security & Privacy Considerations

• All evidence artifacts MUST be signed and tamper‑evident.
• Sensitive fields (e.g., user identifiers) MUST be redacted or encrypted per the privacy policy defined in RFC‑WF‑0003 (CCP).

IANA 고려사항

• IANA 조치는 필요하지 않습니다.

참고 문헌

• [RFC‑WF‑0003] 명령 엔벨로프 및 확인 (CCP)
• [RFC‑WF‑0006] 증거 아티팩트 (EAS)
• [RFC‑WF‑0008] 복구 작업 (RCP)
• [RFC‑WF‑0010] 재생 안전 실행 (IDS)
• [RFC‑WF‑0017] 테스트 벡터 참조 스위트 (TVRS/CATS)

Source: …

수명 주기 상태 매핑

추적 바인딩: (conversation_id, message_ids)
보안 결정: 관련이 있을 경우 authz, 단계‑업, 그리고 확인을 포함합니다.

X. 관측 가능성 요구사항 (OoC 호환성)

OoC는 최소한 다음을 보고할 수 있어야 합니다:

• 현재 라이프사이클 상태.
• 마지막 전환 타임스탬프.
• 종료 결과 (상태가 종료 상태인 경우).
• 거부/실패 이유 (정책 / 이유 코드).
• 다음 허용 복구 옵션 (있는 경우).

SMCL‑compliant 구현은 다음을 검증하는 테스트를 통과해야 합니다:

1. 잘못된 전환 거부 – 불법적인 상태로 이동하려는 시도가 거부됩니다.
2. 정렬 불변식 – 예: confirm + authorize 없이 start가 없도록 보장합니다.
3. 중복 처리 – 명령을 재전송해도 실행이 다시 시작되지 않습니다.
4. 증거 방출 – 각 필수 전환 시 요구되는 아티팩트가 방출됩니다.

이러한 테스트는 TVRS(Test Vectors & Reference Scenarios) 시나리오로 표현되어야 합니다.

관련 사양

Source:

보안 및 일관성 메모

• 라이프사이클 불일치(예: “인증 전 시작”)는 우회 경로를 만들 수 있습니다.
• 구현은 불변 조건을 강제하고 잘못된 시도는 증거 아티팩트로 로그해야 합니다.
• 터미널 상태 보호는 재생 공격 및 “이중 효과” 공격을 방지하는 데 핵심입니다.

SMCL은 “WhatsApp‑first” 실행 의미론을 위한 결정론적 백본을 제공합니다: 라이프사이클 상태, 전이, 증거‑발생 지점, 그리고 멱등 재진입 동작을 표준화하는 정규 FSM. 이는 서비스 간 라이프사이클 드리프트를 방지하고 신뢰할 수 있는 가시성, 복구 및 인증 도구를 가능하게 합니다.

참고 문헌

1. RFC‑WF‑0003, Conversational Command Protocol (CCP).
2. Evidence Artifact Schema (EAS).
3. Recovery & Compensation Protocol (RCP).
4. Idempotency & Delivery Semantics (IDS).
5. Test Vectors & Reference Scenarios (TVRS).

키워드: 유한 상태 머신, 라이프사이클 불변 조건, 터미널 상태 보호, 증거 발산 매핑, 멱등 재진입 규칙, 복구/보상 상태 모델링, 적합성 테스트.