English {#english}

Scope: Apply the platform logpath model (correlation IDs + D1 trace_events + x-trace-id on Zuplo/CP traffic) across the full m.pregoi.com journey: package selection → auth → Stripe checkout → tenant create → provision → client-web.

Canonical doc: Onboarding, provisioning, logpath, admin console

Related plans: Plan A — Stripe · Plan B — funnel · Plan D — Activate

---

한국어 {#korean}

1. ID 정의

ID	생성 주체	저장 예시
trace_id	CP(권장)	D1 traces, provision_jobs, Stripe metadata
job_id	CP	provision_jobs
tenant_id	CP	tenants_master
stripe_checkout_session_id	Stripe	웹훅·D1
anonymous_id	(선택) 브라우저	로그인 전 계측

2. 유료 플로우 생명주기 (상세)

1. T0: URL plan, region — trace 선택.
2. T1: 로그인 성공 직후 — 옵션 A: CP “예약 trace” 발급 후 브라우저 보관 / 옵션 B: 첫 POST /v1/checkout 또는 POST /v1/tenants에서만 생성. 제품 결정 필요.
3. T2: POST /v1/checkout — 요청 헤더 x-trace-id(있으면); Stripe client_reference_id 또는 metadata.trace_id.
4. T3: 웹훅 — metadata에서 trace 읽어 provider_events/빌링과 연결.
5. T4: POST /v1/tenants — 동일 trace 승계(충돌 시 유료 webhook trace 우선 등 정책).
6. T5: GET /v1/jobs/:id 폴링 — 헤더 x-trace-id.
7. T6: client-web·API — x-trace-id + prego_trace 쿼리 유지.

3. 헤더·metadata 규칙

• HTTP: 클라이언트 → CP/Zuplo 시 x-trace-id.
• Stripe: metadata.trace_id, 가능 시 metadata.tenant_id.
• Zuplo 로그: trace_id 구조화 필드 고정(기존 gateway-runtime 로그 필드 계획과 합치).

4. 레포별 체크리스트

레포	할 일
Prego apps/admin-web	모든 CP 호출에 trace 헤더; sessionStorage 키 단일화
prego-control-plane	checkout/webhook/tenants/jobs에서 metadata 수신·저장·병합 규칙
prego-zuplo	auth 라우트 trace 전파·로그
prego_ai	해당 시 동일 헤더
문서	onboarding-provisioning-logpath-admin-console-plan.md에 Paid+Stripe 절 추가

5. 검증 시나리오

• E2E 한 번: Stripe metadata = D1 trace_events = Zuplo 로그 = admin 폴링 요청 헤더.
• trace 없는 레거시 잡: API·UI에서 null 허용 문서화.

6. DoD

• Plan B funnel_events.trace_id와 조인 가능한 플로우 문서화.
• 운영 런북에 “trace로 장애 추적” 1페이지.

7. 교차 참조

	A	B	D
C	checkout metadata	funnel trace 필터	메일·readiness trace