플랜 확인과 연결 복구
Plan은 구매한 상품과 결제 상태를 설명하고, entitlement는 현재 operation이 실제로 허용되는지를 판정한다. 구독 표시가 Pro여도 entitlement 확인이 끝나지 않았다면 기능을 열렸다고 단정하지 않는다.
requires-setup이다.

기능과 역할
| 기능 ID | 사용자 기능 | 확인 기준 |
|---|---|---|
| OP-07 | plan 상태 표시 | Free·Pro label과 billing source 상태를 구분 |
| OP-08 | billing refresh | 결제 뒤 최신 entitlement를 다시 읽음 |
| OP-09 | billing portal handoff | 앱이 URL을 조립하지 않고 외부 session으로 이동 |
| OP-10 | plan·upgrade view | core local authoring을 잠그지 않는 upgrade 안내 |
| AUTH-04 | refresh·revocation·connection health | operation에서 재연결·오류를 드러냄 |
1. Plan, subscription, entitlement 구분
| 용어 | 답하는 질문 | 예시 |
|---|---|---|
| Account | 누구의 상태인가 | 현재 로그인 사용자 |
| Plan | 어떤 상품인가 | Free, Pro Monthly, Pro Yearly |
| Subscription | 결제 계약은 어떤 상태인가 | active, past due, canceled |
| Entitlement | 이 기능을 지금 쓸 수 있는가 | enabled, grace, disabled |
UI badge는 요약이고 실제 기능 gate는 entitlement가 결정한다. client cache나 provider metadata만으로 유료 권한을 승격하지 않는다.
2. 현재 plan 확인
- 설정 → 계정 → Plan and billing을 펼친다.
- 현재 plan label과 상태 badge를 읽는다.
- 로그인 필요, 확인 실패, 불러오는 중을 Free와 혼동하지 않는다.
- 잠긴 기능의 설명에서 필요한 entitlement를 확인한다.
- local authoring이 계속 가능한지 분리해 확인한다.
Pro는 source나 provider ownership을 Glif로 이전하는 모드가 아니다. 사용자 소유 Cloudflare·GitHub 경로는 Free와 Pro 모두의 기본이며, Pro의 가치는 고급 표현과 반복 게시 운영 지원에 있다.
3. 결제 후 Refresh
결제나 plan 변경 뒤 앱으로 돌아왔다면 Refresh plan으로 최신 projection을 다시 읽는다.
- billing 화면에서 결제 또는 변경을 완료한다.
- Glif로 돌아와 같은 계정인지 확인한다.
- Refresh plan을 선택한다.
- plan label뿐 아니라 실행하려는 기능의 entitlement 상태를 확인한다.
- 아직 반영되지 않았다면 잠시 뒤 다시 시도하고 기능을 억지로 실행하지 않는다.
Refresh는 browser의 결제 provider를 직접 조작하는 버튼이 아니다. server가 정규화한 account-scoped 상태를 다시 읽는 동작이다.
4. View plans와 Manage billing
| Action | 목적 | 안전 경계 |
|---|---|---|
| View plans | canonical pricing·checkout entry 열기 | app bundle의 임의 price ID를 사용하지 않음 |
| Manage billing | account-bound billing portal session 열기 | session URL은 일회성 외부 handoff |
| Refresh plan | 돌아온 뒤 entitlement projection 확인 | 성공 전 유료 기능을 열지 않음 |
외부 화면을 닫거나 결제를 취소해도 local 문서와 Binder는 유지된다. 앱으로 돌아오면 실제 상태를 Refresh로 확인한다.
5. 연결 health 진단

Account Settings의 Diagnostics and connections는 main path와 상세 오류를 분리한다. 다음 상태를 구분한다.
연결됨: 해당 provider integration이 현재 account에 연결됨연결 안 됨: integration이 없으며 필요할 때 연결 가능재인증 필요: 만료, 철회 또는 scope 변경을 의심하고 같은 provider에서 재연결오류: 연결 결과가 확정되지 않았거나 설정·network 확인 필요사용 불가: 현재 빌드나 환경에 backend 설정이 없어 action을 실행할 수 없음
진단에 token, session, callback code나 raw provider response를 복사하지 않는다.
6. 만료·철회·오류 복구
- 실패한 operation이 deploy인지 source sync인지 확인한다.
- 해당 operation의 provider 상태만 확인한다.
재인증 필요면 같은 provider의 재연결을 선택한다.- 브라우저에서 계정과 요청 scope를 다시 검토한다.
- 앱으로 돌아와 connection badge를 확인한다.
- 원래 operation을 새로 실행한다.
Cloudflare 오류를 GitHub credential로 우회하거나 GitHub 오류를 Cloudflare 연결로 해결하지 않는다. 앱 로그인 만료와 provider connection 만료도 별도로 복구한다.
7. 연결 해제 결과가 불확실할 때
Provider 연결 해제에는 remote revoke와 local cleanup이 함께 포함될 수 있다.
- 둘 다 성공: disconnected로 확인
- remote revoke 성공, local cleanup 실패: cleanup pending 상태에서 재시도
- remote revoke 불확실: 연결됐다고 되돌리지 않고 진단 후 reconcile
- account가 바뀜: 이전 account의 상태를 새 account에 적용하지 않음
원격 Pages project 삭제는 provider integration 해제와 별도다. project를 실제 삭제하려면 게시·배포 운영의 typed confirmation 절차를 따른다.
8. 실습 기록
예제 Binder의 03_plan-and-entitlement.md와 04_recovery-checklist.md에 다음을 기록한다.
- 표시된 plan과 확인 시점
- 실행하려는 기능과 필요한 entitlement
- connection state와 실패한 operation
- Refresh 또는 재연결 결과
- 실제 provider mutation을 수행했는지 여부
token=, access_token, refresh_token, authorization header와 billing session URL은 절대 기록하지 않는다.
문제 해결
| 증상 | 가능한 경계 | 조치 |
|---|---|---|
| plan을 불러오지 못함 | 로그인·network·billing source 오류 | 계정 확인 후 Refresh, local 작업은 계속 |
| 결제 후 Free로 보임 | projection 반영 대기 또는 다른 account | account 확인, Refresh 후 재검증 |
| Manage billing이 없음 | portal session 대상 subscription 없음 | View plans 또는 support 경로 확인 |
| provider action이 잠김 | Glif account 미연결 | app login을 먼저 완료 |
| 계속 재인증 필요 | token 만료·철회·scope 부족 | 같은 provider 계정과 scope 재검토 |
| diagnostics에 오류 | 설정 또는 operation 실패 | credential을 제외한 오류 코드만 공유 |