diff --git a/docs-site/static/presentation/awsops-intro/02-architecture.html b/docs-site/static/presentation/awsops-intro/02-architecture.html
index 31ca7075..6b0769ca 100644
--- a/docs-site/static/presentation/awsops-intro/02-architecture.html
+++ b/docs-site/static/presentation/awsops-intro/02-architecture.html
@@ -265,7 +265,7 @@ <h3>Chat UX</h3>
     <div class="columns">
 <div class="col">
 <h3>잡 종류 (2026-06-18 이후 증가)</h3>
-<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; ADR-13이 명시적으로 승인한 건 스케줄 진단 요약뿐이라 수동 실행분까지 배치하는 현재 구현은 ADR 범위를 넘어섬 — 후속 ADR 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
+<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; 승인된 범위는 스케줄 진단 요약뿐이지만 현재 구현은 수동 실행분까지 함께 묶음 — 후속 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
 </div><div class="col">
 <p><div style="text-align:center"><img src="../../screenshots/operations/jobs.png" alt="" class="slide-img" style="max-width:90%" /></div></p>
 </div>
@@ -305,7 +305,7 @@ <h3>Read-Only Query</h3>
 </div>
 
 <div class="slide" data-remarp-id="s14" style="transition: transform var(--transition-normal), opacity var(--transition-normal)">
-  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out (ADR-011)</h2></div>
+  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out</h2></div>
   <div class="slide-body" data-remarp-id="s14-body">
     <div class="columns">
 <div class="col">
@@ -313,7 +313,7 @@ <h3>Registry + Assume</h3>
 <ul><li>Aurora <strong>accounts</strong> 레지스트리 — 호스트 계정은 lazy seed</li><li>대상 계정 <code>AWSopsReadOnlyRole</code>을 host task role이 <strong>STS AssumeRole</strong></li><li><strong>ExternalId</strong> — 1st-party(trust policy가 task-role ARN 핀) = <strong>선택</strong>, 3rd-party/와일드카드 = <strong>필수</strong>(confused-deputy 방어)</li><li>글로벌 셀렉터: 단일 계정 스코프 / <code>__all__</code> = 전 계정 fan-out</li></ul>
 </div><div class="col">
 <h3>Safety</h3>
-<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음(ADR-005 동결과 정합)</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
+<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
 </div>
 </div>
   </div>
@@ -326,7 +326,7 @@ <h3>Safety</h3>
 <div class="col">
 <h3>Cognito + Lambda@Edge</h3>
 <ul><li><strong>us-east-1</strong>, py3.12, viewer-request</li><li><strong>RS256 JWKS</strong> 서명 검증 (iss/aud/token_use)</li><li>OAuth <code>state</code> + <strong>PKCE public client</strong></li></ul>
-<h3>Login (ADR-002)</h3>
+<h3>Login</h3>
 <ul><li><strong>Primary</strong> = 자체 <code>/login</code> 폼</li><li>BFF <code>POST /api/auth/login</code> → 무서명 공개 <code>InitiateAuth(USER_PASSWORD_AUTH)</code> → <code>awsops_token</code> (id_token 12h)</li><li>Hosted UI PKCE = <strong>dark fallback</strong>, signout = 쿠키 삭제</li></ul>
 </div><div class="col">
 <p><div style="display:flex;flex-direction:column;gap:0.75rem;margin-top:0.5rem;"><div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00ff88;font-weight:bold;font-size:0.9375rem;">🔒 Private Edge</div><div style="color:#8b95a5;font-size:0.8125rem;">공개 ALB 없음 — 진입점은 CloudFront 하나</div></div><div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00d4ff;font-weight:bold;font-size:0.9375rem;">🔑 ECS Secrets</div><div style="color:#8b95a5;font-size:0.8125rem;">execution role 권한 (task role 아님)</div></div><div style="background:rgba(168,85,247,0.1);border:1px solid rgba(168,85,247,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#a855f7;font-weight:bold;font-size:0.9375rem;">👤 Admin</div><div style="color:#8b95a5;font-size:0.8125rem;">SSM + Cognito group (fail-closed)</div></div></div></p>
@@ -371,16 +371,16 @@ <h3>Login (ADR-002)</h3>
   <div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">🔒</div>
     <div style="color:#00ff88;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">동결 (do-not-enable)</div>
-    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">ADR-005 (029/036/031P4 통합, 2026-06-11 reversal)<br>AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
+    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
   </div>
   <div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">📥</div>
-    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External (ADR-007)</div>
+    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External</div>
     <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">외부 DATA read + 기록/티켓/메시지 <b>write</b> 허용<br>SSRF · Secrets · DLP · human-gate 하</div>
   </div>
 </div>
 <div style="background:rgba(239,68,68,0.06);border:1px solid rgba(239,68,68,0.3);border-radius:10px;padding:0.625rem 1rem;margin-top:0.875rem;font-size:0.75rem;color:#8b95a5;">
-  <b style="color:#ef4444;">예외 1건 — ADR-015</b> (2026-07-01 owner-override): 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지 ADR-005 전부는 그대로 동결.
+  <b style="color:#ef4444;">예외 1건</b>: 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지는 전부 그대로 동결.
 </div>
 <div style="background:rgba(245,158,11,0.08);border:1px solid rgba(245,158,11,0.35);border-radius:12px;padding:1.125rem;margin-top:0.875rem;text-align:center;">
   <span style="font-size:1.5rem;">🧠</span>
@@ -394,7 +394,7 @@ <h3>Login (ADR-002)</h3>
   <div class="slide-header" data-remarp-id="s18-header"><h2>Key Takeaways — Architecture</h2></div>
   <div class="slide-body" data-remarp-id="s18-body">
     <p><!-- Slide 19: Key Takeaways --></p>
-<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>ADR-003 하이브리드 라우팅 + ADR-011 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결(ADR-005, 새 결정 전까지) + ADR-015 예외 1건, in-account Bedrock</li></ul>
+<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>하이브리드 라우팅 + 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결 + 예외 1건, in-account Bedrock</li></ul>
   </div>
 </div>
 
@@ -428,15 +428,15 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
     8: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. ADR-004가 2026년 6월 24일에 개정되면서 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
     9: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 ADR-003 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
     10: "❓ ⏸️ [4min] AWSops의 대표 기능은 AI 종합진단입니다.\n진단은 워커가 생성하는 종합 리포트입니다. light·mid 티어는 9섹션인데, 8개 기본 섹션에 intended-vs-actual drift 섹션이 하나 더 붙습니다. deep 티어는 16섹션으로, 같은 8개 기본 섹션에 7개 deep-only 섹션과 drift 섹션이 더해집니다. deep은 기본 Sonnet으로 돌고, cost-gate를 거쳐 Opus를 선택할 수도 있습니다. 모든 섹션은 Well-Architected 6대 기둥에 매핑됩니다.\n\n생성 중에는 SSE로 진행률이 흐르고, 끝나면 워커 LLM이 자동으로 제목을 붙이고 태그를 제안합니다. 제목 수정, 태그 수동 추가, soft-delete도 됩니다. 내보내기는 DOCX, PDF, Markdown 세 가지를 지원하는데, 워커가 python-docx와 chromium으로 생성합니다.\n가장 중요한 건 이 모든 게 철저히 읽기 전용이라는 점입니다. 진단하고 권고할 뿐 자동으로 고치지 않습니다. auto-remediation은 없습니다. 그래서 안심하고 운영 환경에 붙일 수 있습니다.\n\nWell-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠? 이게 그 작업을 대신합니다.\n\n이 무거운 생성 작업을 안전하게 받쳐주는 워커 티어를 보겠습니다.",
-    11: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용, ADR-009) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
+    11: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
     12: "[1min] 이 백본에 얹히는 잡 종류도 계속 늘었습니다.\nschedule_dispatcher는 시간별로 report_schedules를 스캔해서 예약된 진단 잡을 큐에 넣고, diagnosis_digest는 리포트가 끝날 때마다 개별 이메일을 보내던 걸 배치 SNS 다이제스트로 바꾸는 작업인데, 이미 workers.tf에 병합되어 `workers_enabled && diagnosis_notify_enabled` 게이트로 배포되어 있습니다. 그리고 Powerpipe 기반 compliance 잡이 CIS 벤치마크를 이 워커 티어 위에서 돌립니다. schedule_dispatcher와 compliance는 flag-gated로 라이브 환경에서 이미 켜져 있습니다.\n\n관측성과 토폴로지로 넘어갑니다.",
     13: "⏸️ [3min] 관측성 데이터는 읽기 전용 데이터소스 플랫폼으로 통합합니다.\nClickHouse, Prometheus, Loki, Tempo, Mimir 커넥터를 지원합니다. 각 커넥터는 Lambda로 구현되고, 스키마는 Aurora에 캐시합니다. 이 데이터를 챗에 주입하면 AI가 여러 데이터소스를 교차 조회할 수 있습니다. `/datasources` Explore 페이지에서는 자연어를 쿼리로 변환해 직접 탐색할 수도 있습니다. 모두 읽기 전용입니다.\n\n토폴로지는 리소스 간 관계를 그래프로 보여줍니다. flow 그래프와 infra 리소스 그래프 두 가지가 있고, CloudFront에서 로드밸런서, 타깃 그룹, DB로 이어지는 경로를 시각화합니다. `/topology/resource/[id]`로 들어가면 개별 리소스의 상세 패널을 볼 수 있습니다.\n\n컨테이너 운영자를 위한 EKS 통합을 보겠습니다.",
     14: "⏸️ [3min] EKS도 읽기 전용으로 통합되는데, 인증 경로가 3가지로 늘었습니다. 원래 경로는 configure.mjs 멀티선택으로 시작해서 eks.tf가 웹 task role에 Access Entry를 부여하고 AmazonEKSAdminViewPolicy를 클러스터 스코프로 붙이는 방식입니다. View가 아니라 AdminView인 이유는, View 정책엔 클러스터 스코프 리소스가 없어서 노드 목록 조회가 403이 나기 때문입니다. AdminView는 */*/get,list,watch라 시크릿까지 읽을 수 있지만, BFF가 노출하는 kind는 화이트리스트로 제한되어 있어서 시크릿·컨피그맵은 절대 통과하지 않습니다.\n\n여기에 sa-token과 assume-role 두 가지 경로가 Aurora의 eks_registrations.auth에 더해졌습니다. 클러스터별로 등록하면 되고 terraform 온보딩이 필요 없습니다. 그리고 지금 라이브인 auto-register 경로가 있는데, EventBridge가 CloudTrail의 AssociateAccessPolicy나 DeleteAccessEntry 이벤트를 잡아서 Lambda를 거쳐 eks_registrations에 자동으로 기록합니다. 버튼을 누를 필요가 없습니다.\n조회는 nodes, pods, deployments, services 같은 핵심 리소스를 BFF가 직접 처리합니다. 워커를 거치지 않습니다. 그리고 한 가지 더, ListClusters·DescribeCluster 같은 핵심 discovery 권한은 이제 게이트가 아니라 workload.tf에 상시로 붙어 있습니다. 그래서 온보딩 플래그가 꺼져 있어도 /api/eks, /api/overview, /api/cost는 항상 정상 동작합니다.\nEKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워크로드 뷰가 있습니다.\n\n계정을 하나 더 늘리면 어떻게 되는지, 멀티 계정 구조를 보겠습니다.",
-    15: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. ADR-011이 이걸 STS AssumeRole 기반 read-only 페더레이션으로 정의합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
-    16: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 ADR-002에 따라 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
+    15: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
+    16: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
     17: "⏸️ [3min] 배포는 Makefile로 단계가 깔끔하게 나뉩니다.\n먼저 `make configure`로 대화형 TUI를 돌립니다. VPC, 도메인, 버킷, EKS를 고르면 terraform.tfvars와 backend.hcl이 생성됩니다. 그다음 terraform init과 plan으로 tfplan을 저장하고, 공유 인프라는 컨트롤러가 직접 apply tfplan으로 적용합니다. 에이전트가 공유 프로덕션 인프라를 임의로 apply하지 않도록 막혀 있습니다.\n\n앱은 `make deploy`로 배포합니다. 중요한 건 migrate가 먼저 돌고 그다음 웹 이미지를 배포한다는 순서입니다. ULID 마이그레이션을 먼저 적용한 뒤 arm64로 빌드해서 ECR에 푸시하고, ECS 롤링 배포 후 stable을 기다린 다음 `/api/health`로 smoke 테스트를 합니다. 여기서 terraform apply는 하지 않습니다.\nAgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make workers`로 이미지와 provisioner를 실행합니다.\n\n마지막으로 이 아키텍처가 가진 태세와 차별점을 정리하겠습니다.",
-    18: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. ADR-005(옛 029/036/031 Phase4를 통합, 2026년 6월 11일 reversal 합의)에 따라 AWS 리소스 변경과 자율 실행은 동결입니다. 다만 여기서 정확히 말씀드릴 게 있는데, 이건 \"영구 금지\"가 아닙니다. BASELINE 문서가 그 표현을 명시적으로 거부합니다. 정확히는 \"안전조건 충족 + 새로운 명시적 결정 전까지\" 동결이고, 완화하려면 새 ADR과 멀티-AI 패널, 날짜가 박힌 owner override가 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. ADR-015인데, 2026년 7월 1일에 오준석님이 owner-override로 승인했습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지 ADR-005는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. ADR-007이 이걸 다루는데, 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
-    19: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 ADR-003 하이브리드고 ADR-011 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 ADR-015라는 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
+    18: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 새 결정 문서와 멀티 AI 패널 검토, 날짜가 기록된 소유자 승인이 모두 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
+    19: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
     20: "❓ [1min] 두 번째 파트를 마칩니다.\n지금까지 AWSops의 기술 아키텍처를 레이어별로 살펴봤습니다. Terraform 기반 MSA, 비공개 엣지, Aurora 영속 상태, AgentCore 섹션 에이전트, 하이브리드 라우팅, OOM에 안전한 워커 티어, 그리고 읽기 전용 동결 태세까지 모두 하나의 일관된 설계로 묶여 있습니다.\n\n질문 있으시면 편하게 주세요.\n\n잠시 쉬고 마지막 파트, 실전 데모와 진단 리포트로 이어가겠습니다."
   };
   const deck = new SlideFramework({
diff --git a/docs-site/static/presentation/awsops-intro/02-architecture.md b/docs-site/static/presentation/awsops-intro/02-architecture.md
index 66cdcbc5..ffa26157 100644
--- a/docs-site/static/presentation/awsops-intro/02-architecture.md
+++ b/docs-site/static/presentation/awsops-intro/02-architecture.md
@@ -484,7 +484,7 @@ Well-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠
 :::notes
 {timing: 2min}
 무거운 작업은 모두 비동기 워커 티어가 받습니다.
-흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용, ADR-009) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.
+흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.
 {cue: pause}
 그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.
 워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.
@@ -506,7 +506,7 @@ Well-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠
 ### 잡 종류 (2026-06-18 이후 증가)
 
 - **schedule_dispatcher** — 시간별 EventBridge → `report_schedules` 스캔 → 진단 잡 enqueue (`diagnosis_schedule_enabled`, LIVE)
-- **diagnosis_digest** (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (`workers_enabled && diagnosis_notify_enabled` 게이트로 이미 배포됨; ADR-13이 명시적으로 승인한 건 스케줄 진단 요약뿐이라 수동 실행분까지 배치하는 현재 구현은 ADR 범위를 넘어섬 — 후속 ADR 정리 필요)
+- **diagnosis_digest** (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (`workers_enabled && diagnosis_notify_enabled` 게이트로 이미 배포됨; 승인된 범위는 스케줄 진단 요약뿐이지만 현재 구현은 수동 실행분까지 함께 묶음 — 후속 정리 필요)
 - **compliance** (Powerpipe) — CIS 벤치마크 Fargate 잡 (`steampipe_enabled`)
 
 :::
@@ -618,7 +618,7 @@ EKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워
 @type: content
 @transition: slide
 
-# Multi-Account — STS AssumeRole Fan-Out (ADR-011)
+# Multi-Account — STS AssumeRole Fan-Out
 
 ::: left
 
@@ -636,7 +636,7 @@ EKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워
 ### Safety
 
 - **host self-assume 가드** — target == host면 `get_role_arn()`이 `None` 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)
-- **read-only 한정** — 대상 계정 변경 작업 없음(ADR-005 동결과 정합)
+- **read-only 한정** — 대상 계정 변경 작업 없음
 - `/accounts` admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)
 
 :::
@@ -648,7 +648,7 @@ EKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워
 • ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수
 • host self-assume 가드로 "cross-account 차단" 오진을 방지
 
-AWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. ADR-011이 이걸 STS AssumeRole 기반 read-only 페더레이션으로 정의합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.
+AWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.
 {cue: pause}
 ExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.
 전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.
@@ -675,7 +675,7 @@ ExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AW
 - **RS256 JWKS** 서명 검증 (iss/aud/token_use)
 - OAuth `state` + **PKCE public client**
 
-### Login (ADR-002)
+### Login
 
 - **Primary** = 자체 `/login` 폼
 - BFF `POST /api/auth/login` → 무서명 공개 `InitiateAuth(USER_PASSWORD_AUTH)` → `awsops_token` (id_token 12h)
@@ -696,7 +696,7 @@ ExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AW
 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.
 Lambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.
 {cue: pause}
-로그인의 기본 경로는 ADR-002에 따라 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.
+로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.
 오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.
 {cue: transition}
 이걸 실제로 배포하는 흐름을 보겠습니다.
@@ -760,16 +760,16 @@ AgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make wo
   <div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">🔒</div>
     <div style="color:#00ff88;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">동결 (do-not-enable)</div>
-    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">ADR-005 (029/036/031P4 통합, 2026-06-11 reversal)<br>AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
+    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
   </div>
   <div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">📥</div>
-    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External (ADR-007)</div>
+    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External</div>
     <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">외부 DATA read + 기록/티켓/메시지 <b>write</b> 허용<br>SSRF · Secrets · DLP · human-gate 하</div>
   </div>
 </div>
 <div style="background:rgba(239,68,68,0.06);border:1px solid rgba(239,68,68,0.3);border-radius:10px;padding:0.625rem 1rem;margin-top:0.875rem;font-size:0.75rem;color:#8b95a5;">
-  <b style="color:#ef4444;">예외 1건 — ADR-015</b> (2026-07-01 owner-override): 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지 ADR-005 전부는 그대로 동결.
+  <b style="color:#ef4444;">예외 1건</b>: 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지는 전부 그대로 동결.
 </div>
 <div style="background:rgba(245,158,11,0.08);border:1px solid rgba(245,158,11,0.35);border-radius:12px;padding:1.125rem;margin-top:0.875rem;text-align:center;">
   <span style="font-size:1.5rem;">🧠</span>
@@ -781,10 +781,10 @@ AgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make wo
 :::notes
 {timing: 3min}
 이 아키텍처의 태세를 정확히 정의하겠습니다.
-AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. ADR-005(옛 029/036/031 Phase4를 통합, 2026년 6월 11일 reversal 합의)에 따라 AWS 리소스 변경과 자율 실행은 동결입니다. 다만 여기서 정확히 말씀드릴 게 있는데, 이건 "영구 금지"가 아닙니다. BASELINE 문서가 그 표현을 명시적으로 거부합니다. 정확히는 "안전조건 충족 + 새로운 명시적 결정 전까지" 동결이고, 완화하려면 새 ADR과 멀티-AI 패널, 날짜가 박힌 owner override가 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.
+AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 새 결정 문서와 멀티 AI 패널 검토, 날짜가 기록된 소유자 승인이 모두 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.
 {cue: pause}
-딱 하나 예외가 있습니다. ADR-015인데, 2026년 7월 1일에 오준석님이 owner-override로 승인했습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지 ADR-005는 전부 그대로 동결입니다.
-다만 외부 데이터에 대해서는 다릅니다. ADR-007이 이걸 다루는데, 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.
+딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.
+다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.
 그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.
 {cue: transition}
 전체를 한 장으로 정리하겠습니다.
@@ -802,16 +802,16 @@ AWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니
 - **Terraform MSA on private edge** — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음
 - **Aurora 영속 상태** — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)
 - **AgentCore 섹션 에이전트** — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기
-- **ADR-003 하이브리드 라우팅 + ADR-011 멀티 계정** — regex + Haiku 분류기 + caching, STS AssumeRole fan-out
+- **하이브리드 라우팅 + 멀티 계정** — regex + Haiku 분류기 + caching, STS AssumeRole fan-out
 - **OOM-safe 비동기 워커 티어** — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리
-- **읽기 전용 동결 태세** — AWS 변경·자율 동결(ADR-005, 새 결정 전까지) + ADR-015 예외 1건, in-account Bedrock
+- **읽기 전용 동결 태세** — AWS 변경·자율 동결 + 예외 1건, in-account Bedrock
 
 :::notes
 {timing: 2min}
 아키텍처 파트를 한 장으로 정리합니다.
 첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.
 {cue: pause}
-셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 ADR-003 하이브리드고 ADR-011 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 ADR-015라는 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.
+셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.
 {cue: transition}
 세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.
 :::
diff --git a/docs-site/static/presentation/awsops-intro/index.html b/docs-site/static/presentation/awsops-intro/index.html
index c9518e3c..b41b6d6f 100644
--- a/docs-site/static/presentation/awsops-intro/index.html
+++ b/docs-site/static/presentation/awsops-intro/index.html
@@ -564,7 +564,7 @@ <h3>Chat UX</h3>
     <div class="columns">
 <div class="col">
 <h3>잡 종류 (2026-06-18 이후 증가)</h3>
-<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; ADR-13이 명시적으로 승인한 건 스케줄 진단 요약뿐이라 수동 실행분까지 배치하는 현재 구현은 ADR 범위를 넘어섬 — 후속 ADR 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
+<ul><li><strong>schedule_dispatcher</strong> — 시간별 EventBridge → <code>report_schedules</code> 스캔 → 진단 잡 enqueue (<code>diagnosis_schedule_enabled</code>, LIVE)</li><li><strong>diagnosis_digest</strong> (workers.tf) — 리포트별 이메일 대신 배치 SNS 다이제스트 (<code>workers_enabled && diagnosis_notify_enabled</code> 게이트로 이미 배포됨; 승인된 범위는 스케줄 진단 요약뿐이지만 현재 구현은 수동 실행분까지 함께 묶음 — 후속 정리 필요)</li><li><strong>compliance</strong> (Powerpipe) — CIS 벤치마크 Fargate 잡 (<code>steampipe_enabled</code>)</li></ul>
 </div><div class="col">
 <p><div style="text-align:center"><img src="../../screenshots/operations/jobs.png" alt="" class="slide-img" style="max-width:90%" /></div></p>
 </div>
@@ -604,7 +604,7 @@ <h3>Read-Only Query</h3>
 </div>
 
 <div class="slide" data-remarp-id="s14" style="transition: transform var(--transition-normal), opacity var(--transition-normal)">
-  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out (ADR-011)</h2></div>
+  <div class="slide-header" data-remarp-id="s14-header"><h2>Multi-Account — STS AssumeRole Fan-Out</h2></div>
   <div class="slide-body" data-remarp-id="s14-body">
     <div class="columns">
 <div class="col">
@@ -612,7 +612,7 @@ <h3>Registry + Assume</h3>
 <ul><li>Aurora <strong>accounts</strong> 레지스트리 — 호스트 계정은 lazy seed</li><li>대상 계정 <code>AWSopsReadOnlyRole</code>을 host task role이 <strong>STS AssumeRole</strong></li><li><strong>ExternalId</strong> — 1st-party(trust policy가 task-role ARN 핀) = <strong>선택</strong>, 3rd-party/와일드카드 = <strong>필수</strong>(confused-deputy 방어)</li><li>글로벌 셀렉터: 단일 계정 스코프 / <code>__all__</code> = 전 계정 fan-out</li></ul>
 </div><div class="col">
 <h3>Safety</h3>
-<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음(ADR-005 동결과 정합)</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
+<ul><li><strong>host self-assume 가드</strong> — target == host면 <code>get_role_arn()</code>이 <code>None</code> 반환 → host 실행 role 직접 사용(v1 전용 role을 host에서 self-assume → AccessDenied 오진 방지)</li><li><strong>read-only 한정</strong> — 대상 계정 변경 작업 없음</li><li><code>/accounts</code> admin UI + CFN으로 대상 계정에 read-only role 배포(코드 변경 없음)</li></ul>
 </div>
 </div>
   </div>
@@ -625,7 +625,7 @@ <h3>Safety</h3>
 <div class="col">
 <h3>Cognito + Lambda@Edge</h3>
 <ul><li><strong>us-east-1</strong>, py3.12, viewer-request</li><li><strong>RS256 JWKS</strong> 서명 검증 (iss/aud/token_use)</li><li>OAuth <code>state</code> + <strong>PKCE public client</strong></li></ul>
-<h3>Login (ADR-002)</h3>
+<h3>Login</h3>
 <ul><li><strong>Primary</strong> = 자체 <code>/login</code> 폼</li><li>BFF <code>POST /api/auth/login</code> → 무서명 공개 <code>InitiateAuth(USER_PASSWORD_AUTH)</code> → <code>awsops_token</code> (id_token 12h)</li><li>Hosted UI PKCE = <strong>dark fallback</strong>, signout = 쿠키 삭제</li></ul>
 </div><div class="col">
 <p><div style="display:flex;flex-direction:column;gap:0.75rem;margin-top:0.5rem;"><div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00ff88;font-weight:bold;font-size:0.9375rem;">🔒 Private Edge</div><div style="color:#8b95a5;font-size:0.8125rem;">공개 ALB 없음 — 진입점은 CloudFront 하나</div></div><div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#00d4ff;font-weight:bold;font-size:0.9375rem;">🔑 ECS Secrets</div><div style="color:#8b95a5;font-size:0.8125rem;">execution role 권한 (task role 아님)</div></div><div style="background:rgba(168,85,247,0.1);border:1px solid rgba(168,85,247,0.35);border-radius:10px;padding:0.875rem;"><div style="color:#a855f7;font-weight:bold;font-size:0.9375rem;">👤 Admin</div><div style="color:#8b95a5;font-size:0.8125rem;">SSM + Cognito group (fail-closed)</div></div></div></p>
@@ -670,16 +670,16 @@ <h3>Login (ADR-002)</h3>
   <div style="background:rgba(0,255,136,0.1);border:1px solid rgba(0,255,136,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">🔒</div>
     <div style="color:#00ff88;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">동결 (do-not-enable)</div>
-    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">ADR-005 (029/036/031P4 통합, 2026-06-11 reversal)<br>AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
+    <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">AWS-리소스 <b>변경 + 자율</b> — 새 명시적 결정 전까지 동결(영구 아님)</div>
   </div>
   <div style="background:rgba(0,212,255,0.1);border:1px solid rgba(0,212,255,0.4);border-radius:12px;padding:1.375rem;">
     <div style="font-size:2.5rem;margin-bottom:0.625rem;">📥</div>
-    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External (ADR-007)</div>
+    <div style="color:#00d4ff;font-weight:bold;font-size:1.0625rem;margin-bottom:0.5rem;">거버넌스된 External</div>
     <div style="color:#8b95a5;font-size:0.8125rem;line-height:1.6;">외부 DATA read + 기록/티켓/메시지 <b>write</b> 허용<br>SSRF · Secrets · DLP · human-gate 하</div>
   </div>
 </div>
 <div style="background:rgba(239,68,68,0.06);border:1px solid rgba(239,68,68,0.3);border-radius:10px;padding:0.625rem 1rem;margin-top:0.875rem;font-size:0.75rem;color:#8b95a5;">
-  <b style="color:#ef4444;">예외 1건 — ADR-015</b> (2026-07-01 owner-override): 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지 ADR-005 전부는 그대로 동결.
+  <b style="color:#ef4444;">예외 1건</b>: 호스트 자기 web 서비스의 <code style="color:#ef4444;">ecs:UpdateService force-new-deployment</code>(재시작)만, Aurora secret 회전 이벤트 트리거 한정, IAM 1 ARN, secret-id fail-closed, default-off. 나머지는 전부 그대로 동결.
 </div>
 <div style="background:rgba(245,158,11,0.08);border:1px solid rgba(245,158,11,0.35);border-radius:12px;padding:1.125rem;margin-top:0.875rem;text-align:center;">
   <span style="font-size:1.5rem;">🧠</span>
@@ -693,7 +693,7 @@ <h3>Login (ADR-002)</h3>
   <div class="slide-header" data-remarp-id="s18-header"><h2>Key Takeaways — Architecture</h2></div>
   <div class="slide-body" data-remarp-id="s18-body">
     <p><!-- Slide 19: Key Takeaways --></p>
-<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>ADR-003 하이브리드 라우팅 + ADR-011 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결(ADR-005, 새 결정 전까지) + ADR-015 예외 1건, in-account Bedrock</li></ul>
+<ul><li><strong>Terraform MSA on private edge</strong> — CloudFront VPC Origin → 내부 ALB → Fargate, 공개 ALB 없음</li><li><strong>Aurora 영속 상태</strong> — PostgreSQL 17.9 (Steampipe = flag-gated 인벤토리 sync일 뿐)</li><li><strong>AgentCore 섹션 에이전트</strong> — 9 게이트웨이 · ~160 read-only 도구(30슬라이스 전부 LIVE)로 라이브 AWS 읽기</li><li><strong>하이브리드 라우팅 + 멀티 계정</strong> — regex + Haiku 분류기 + caching, STS AssumeRole fan-out</li><li><strong>OOM-safe 비동기 워커 티어</strong> — SQS + SFN + Lambda/Fargate, 진단·스케줄·알림·컴플라이언스 처리</li><li><strong>읽기 전용 동결 태세</strong> — AWS 변경·자율 동결 + 예외 1건, in-account Bedrock</li></ul>
   </div>
 </div>
 
@@ -1523,15 +1523,15 @@ <h1 style="position:absolute; left:5%; top:45%; font-family:var(--font-display);
     19: "⏸️ [2min] 도구는 9개 섹션 게이트웨이로 묶입니다.\nnetwork, container, data, security, cost, monitoring, iac, ops, 그리고 external-obs입니다. ADR-004가 2026년 6월 24일에 개정되면서 external-obs에 Prometheus·ClickHouse 커넥터가 붙었고, 그때부터 9번째 라우팅 가능한 게이트웨이로 승격됐습니다. 예전 버전에서 \"9번째 게이트웨이가 아니다\"라고 했던 건 그 커넥터가 붙기 전 부트스트랩 상태를 말한 거였고, 지금은 정반대입니다.\n\n전체 카탈로그는 30개 슬라이스, 약 160개 읽기 전용 도구이고, 함대 배포가 완료돼 30개 슬라이스 전부, 9개 게이트웨이 전부 READY 상태로 라이브입니다.\n\n그럼 이 9개 게이트웨이 중 어디로 보낼지는 어떻게 정할까요?",
     20: "⏸️ [3min] 9개 게이트웨이 중 어디로 보낼지는 ADR-003 하이브리드 라우팅이 정합니다.\n파이프라인은 3단계입니다. 먼저 regex fast-path가 명백한 질의를 즉시 라우팅합니다. 애매하면 Haiku 4.5 분류기가 판단합니다. 그리고 prompt caching으로 약 59% 캐시 히트를 내서 비용과 지연을 줄입니다. 결정된 섹션으로 라우팅한 뒤 SSE로 응답을 스트리밍하면서 어떤 도구를 호출하는지도 함께 보여줍니다.\n\n게이트 정확도는 69.2%에서 96.9%로 27.7 포인트 올랐고, 2026년 6월 10일에 라이브입니다.\n오른쪽은 챗 UX입니다. 크기 조절과 최대화가 되는 드로어, `/assistant` 풀페이지, react-markdown 렌더링, 그리고 Aurora에 저장되는 스레드 영속까지. 사이드바는 Claude 앱 스타일이라 익숙합니다.\n\n이 챗 위에 얹힌 대표 기능이 AI 진단입니다.",
     21: "❓ ⏸️ [4min] AWSops의 대표 기능은 AI 종합진단입니다.\n진단은 워커가 생성하는 종합 리포트입니다. light·mid 티어는 9섹션인데, 8개 기본 섹션에 intended-vs-actual drift 섹션이 하나 더 붙습니다. deep 티어는 16섹션으로, 같은 8개 기본 섹션에 7개 deep-only 섹션과 drift 섹션이 더해집니다. deep은 기본 Sonnet으로 돌고, cost-gate를 거쳐 Opus를 선택할 수도 있습니다. 모든 섹션은 Well-Architected 6대 기둥에 매핑됩니다.\n\n생성 중에는 SSE로 진행률이 흐르고, 끝나면 워커 LLM이 자동으로 제목을 붙이고 태그를 제안합니다. 제목 수정, 태그 수동 추가, soft-delete도 됩니다. 내보내기는 DOCX, PDF, Markdown 세 가지를 지원하는데, 워커가 python-docx와 chromium으로 생성합니다.\n가장 중요한 건 이 모든 게 철저히 읽기 전용이라는 점입니다. 진단하고 권고할 뿐 자동으로 고치지 않습니다. auto-remediation은 없습니다. 그래서 안심하고 운영 환경에 붙일 수 있습니다.\n\nWell-Architected Review를 수동으로 며칠씩 만들어 보신 분 계시죠? 이게 그 작업을 대신합니다.\n\n이 무거운 생성 작업을 안전하게 받쳐주는 워커 티어를 보겠습니다.",
-    22: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용, ADR-009) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
+    22: "⏸️ [2min] 무거운 작업은 모두 비동기 워커 티어가 받습니다.\n흐름은 이렇습니다. 웹이 진단은 `/api/diagnosis`, 컴플라이언스는 `/api/compliance/run`으로 제출하면(범용 `POST /api/jobs`는 `noop` 계열만 허용) worker_jobs 테이블에 queued 상태로 기록하고 SQS에 넣습니다. ESM이 킬스위치 역할을 하면서 dispatcher Lambda를 호출하는데, dispatcher는 job_id 기준으로 멱등하게 동작합니다.\n\n그다음 Step Functions Standard가 `$.runtime` 값을 보고 분기합니다. 짧은 작업은 RunLambda로, 길거나 OOM 위험이 있는 작업은 ecs:runTask.sync로 Fargate 워커에 넘깁니다. 진단 리포트나 DOCX·PDF 생성 같은 무거운 작업이 여기로 갑니다.\n워커는 스스로 running과 succeeded를 Aurora에 기록합니다. 실패해서 Catch로 빠지면 status_updater Lambda가 failed로 표시하는데, 이건 SFN이 VPC 안 Aurora에 직접 쓸 수 없기 때문입니다. 마지막으로 reaper가 5분마다 stale 작업을 정합화합니다. 그래서 OOM에 안전한 백본입니다. 참고로 Fargate 워커는 ENTRYPOINT가 아니라 CMD를 써야 SFN command override가 정상 동작합니다.\n\n이 백본 위에서 어떤 잡들이 도는지 보겠습니다.",
     23: "[1min] 이 백본에 얹히는 잡 종류도 계속 늘었습니다.\nschedule_dispatcher는 시간별로 report_schedules를 스캔해서 예약된 진단 잡을 큐에 넣고, diagnosis_digest는 리포트가 끝날 때마다 개별 이메일을 보내던 걸 배치 SNS 다이제스트로 바꾸는 작업인데, 이미 workers.tf에 병합되어 `workers_enabled && diagnosis_notify_enabled` 게이트로 배포되어 있습니다. 그리고 Powerpipe 기반 compliance 잡이 CIS 벤치마크를 이 워커 티어 위에서 돌립니다. schedule_dispatcher와 compliance는 flag-gated로 라이브 환경에서 이미 켜져 있습니다.\n\n관측성과 토폴로지로 넘어갑니다.",
     24: "⏸️ [3min] 관측성 데이터는 읽기 전용 데이터소스 플랫폼으로 통합합니다.\nClickHouse, Prometheus, Loki, Tempo, Mimir 커넥터를 지원합니다. 각 커넥터는 Lambda로 구현되고, 스키마는 Aurora에 캐시합니다. 이 데이터를 챗에 주입하면 AI가 여러 데이터소스를 교차 조회할 수 있습니다. `/datasources` Explore 페이지에서는 자연어를 쿼리로 변환해 직접 탐색할 수도 있습니다. 모두 읽기 전용입니다.\n\n토폴로지는 리소스 간 관계를 그래프로 보여줍니다. flow 그래프와 infra 리소스 그래프 두 가지가 있고, CloudFront에서 로드밸런서, 타깃 그룹, DB로 이어지는 경로를 시각화합니다. `/topology/resource/[id]`로 들어가면 개별 리소스의 상세 패널을 볼 수 있습니다.\n\n컨테이너 운영자를 위한 EKS 통합을 보겠습니다.",
     25: "⏸️ [3min] EKS도 읽기 전용으로 통합되는데, 인증 경로가 3가지로 늘었습니다. 원래 경로는 configure.mjs 멀티선택으로 시작해서 eks.tf가 웹 task role에 Access Entry를 부여하고 AmazonEKSAdminViewPolicy를 클러스터 스코프로 붙이는 방식입니다. View가 아니라 AdminView인 이유는, View 정책엔 클러스터 스코프 리소스가 없어서 노드 목록 조회가 403이 나기 때문입니다. AdminView는 */*/get,list,watch라 시크릿까지 읽을 수 있지만, BFF가 노출하는 kind는 화이트리스트로 제한되어 있어서 시크릿·컨피그맵은 절대 통과하지 않습니다.\n\n여기에 sa-token과 assume-role 두 가지 경로가 Aurora의 eks_registrations.auth에 더해졌습니다. 클러스터별로 등록하면 되고 terraform 온보딩이 필요 없습니다. 그리고 지금 라이브인 auto-register 경로가 있는데, EventBridge가 CloudTrail의 AssociateAccessPolicy나 DeleteAccessEntry 이벤트를 잡아서 Lambda를 거쳐 eks_registrations에 자동으로 기록합니다. 버튼을 누를 필요가 없습니다.\n조회는 nodes, pods, deployments, services 같은 핵심 리소스를 BFF가 직접 처리합니다. 워커를 거치지 않습니다. 그리고 한 가지 더, ListClusters·DescribeCluster 같은 핵심 discovery 권한은 이제 게이트가 아니라 workload.tf에 상시로 붙어 있습니다. 그래서 온보딩 플래그가 꺼져 있어도 /api/eks, /api/overview, /api/cost는 항상 정상 동작합니다.\nEKS 페이지에는 접근 권한 배지와 CLI 가이드, 클러스터별 워크로드 뷰가 있습니다.\n\n계정을 하나 더 늘리면 어떻게 되는지, 멀티 계정 구조를 보겠습니다.",
-    26: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. ADR-011이 이걸 STS AssumeRole 기반 read-only 페더레이션으로 정의합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
-    27: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 ADR-002에 따라 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
+    26: "⏸️ ⏸️ [3min] [요약]\n• Aurora accounts 레지스트리 + STS AssumeRole로 여러 AWS 계정을 read-only 페더레이션\n• ExternalId는 1st-party(task-role ARN 핀)면 선택, 3rd-party면 필수\n• host self-assume 가드로 \"cross-account 차단\" 오진을 방지\n\nAWSops는 단일 호스트 계정에서 돌지만, 여러 AWS 계정을 통합 대시보드로 보여줄 수 있습니다. STS AssumeRole 기반 read-only 페더레이션으로 조회합니다. Aurora에 accounts 레지스트리를 두고, 호스트 계정은 처음 접근할 때 lazy seed로 등록됩니다. 대상 계정에는 AWSopsReadOnlyRole을 미리 배포해 두고, host task role이 그 role을 assume합니다.\n\nExternalId는 상황에 따라 다릅니다. 대상 계정의 trust policy가 AWSops task-role ARN을 정확히 핀해 두면 1st-party로 보고 ExternalId를 생략할 수 있습니다. 반대로 3rd-party거나 와일드카드 principal이면 ExternalId가 필수입니다 — confused-deputy 공격을 막기 위해서입니다. 이 구분은 코드가 강제하는 게 아니라 trust policy로 운영적으로 강제됩니다.\n전역 계정 셀렉터로 한 계정만 볼 수도 있고, __all__을 선택하면 전 계정을 fan-out으로 조회해서 비용이나 Bedrock 사용량 같은 걸 집계합니다.\n\n한 가지 함정이 있었는데, 호스트 계정을 선택했을 때 에이전트가 host를 마치 다른 계정인 것처럼 착각해서 host에는 없는 v1 전용 role을 self-assume하려다 AccessDenied가 나고, 이걸 \"cross-account 차단\"으로 오진했던 적이 있습니다. 지금은 target이 host와 같으면 get_role_arn()이 None을 반환해서 host 실행 role을 그대로 씁니다.\n\n이 모든 접근 경로를 지탱하는 인증과 보안 레이어를 보겠습니다.",
+    27: "⏸️ [3min] 인증은 Cognito와 Lambda@Edge가 함께 처리합니다.\nLambda@Edge는 us-east-1에서 viewer-request로 동작하며 RS256 JWKS로 토큰 서명을 검증합니다. iss, aud, token_use를 모두 확인하고, OAuth state와 PKCE public client를 씁니다. 시크릿이 없는 공개 클라이언트입니다.\n\n로그인의 기본 경로는 자체 `/login` 폼입니다. BFF의 `POST /api/auth/login`이 무서명 공개 InitiateAuth를 USER_PASSWORD_AUTH 방식으로 호출해 awsops_token을 발급합니다. id_token은 12시간 유효합니다. 미인증 요청은 엣지가 `/login`으로 보냅니다. Hosted UI PKCE 플로우는 다크 폴백으로 남겨두고, signout은 쿠키만 삭제합니다.\n오른쪽 세 가지가 보안 기둥입니다. 공개 ALB가 없는 비공개 엣지, ECS 시크릿은 task role이 아니라 execution role 권한이어야 한다는 점, 그리고 admin 모델은 SSM과 Cognito group 기반으로 fail-closed입니다.\n\n이걸 실제로 배포하는 흐름을 보겠습니다.",
     28: "⏸️ [3min] 배포는 Makefile로 단계가 깔끔하게 나뉩니다.\n먼저 `make configure`로 대화형 TUI를 돌립니다. VPC, 도메인, 버킷, EKS를 고르면 terraform.tfvars와 backend.hcl이 생성됩니다. 그다음 terraform init과 plan으로 tfplan을 저장하고, 공유 인프라는 컨트롤러가 직접 apply tfplan으로 적용합니다. 에이전트가 공유 프로덕션 인프라를 임의로 apply하지 않도록 막혀 있습니다.\n\n앱은 `make deploy`로 배포합니다. 중요한 건 migrate가 먼저 돌고 그다음 웹 이미지를 배포한다는 순서입니다. ULID 마이그레이션을 먼저 적용한 뒤 arm64로 빌드해서 ECR에 푸시하고, ECS 롤링 배포 후 stable을 기다린 다음 `/api/health`로 smoke 테스트를 합니다. 여기서 terraform apply는 하지 않습니다.\nAgentCore와 워커는 각각의 flag로 apply한 뒤 `make agentcore`, `make workers`로 이미지와 provisioner를 실행합니다.\n\n마지막으로 이 아키텍처가 가진 태세와 차별점을 정리하겠습니다.",
-    29: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. ADR-005(옛 029/036/031 Phase4를 통합, 2026년 6월 11일 reversal 합의)에 따라 AWS 리소스 변경과 자율 실행은 동결입니다. 다만 여기서 정확히 말씀드릴 게 있는데, 이건 \"영구 금지\"가 아닙니다. BASELINE 문서가 그 표현을 명시적으로 거부합니다. 정확히는 \"안전조건 충족 + 새로운 명시적 결정 전까지\" 동결이고, 완화하려면 새 ADR과 멀티-AI 패널, 날짜가 박힌 owner override가 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. ADR-015인데, 2026년 7월 1일에 오준석님이 owner-override로 승인했습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지 ADR-005는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. ADR-007이 이걸 다루는데, 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
-    30: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 ADR-003 하이브리드고 ADR-011 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 ADR-015라는 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
+    29: "⏸️ [3min] 이 아키텍처의 태세를 정확히 정의하겠습니다.\nAWSops는 읽기 전용 AWS 운영 대시보드에 AI 진단을 더한 것입니다. AWS 리소스 변경과 자율 실행은 동결입니다. 영구 금지는 아니지만, 해제하려면 새 결정 문서와 멀티 AI 패널 검토, 날짜가 기록된 소유자 승인이 모두 필요합니다. do-not-enable, 그냥 조용히 다시 켜지 않는다는 뜻입니다.\n\n딱 하나 예외가 있습니다. 호스트 자기 web 서비스를 Aurora secret 회전 이벤트에 맞춰 force-new-deployment로 재시작하는 것, 그거 하나만 허용됩니다. IAM은 서비스 1개 ARN으로 스코프되고, secret id가 안 맞으면 fail-closed로 아예 안 돕니다. 기본값은 off입니다. 나머지는 전부 그대로 동결입니다.\n다만 외부 데이터에 대해서는 다릅니다. 외부 관측성 데이터 읽기, 그리고 외부 기록·티켓·메시지 write는 거버넌스 하에 허용됩니다. SSRF 방어, Secrets 관리, DLP와 redaction, human-gate를 모두 거칩니다. 즉 AWS 리소스는 안 건드리지만, 외부 시스템에 리포트를 보내거나 티켓을 끊는 건 통제된 형태로 가능합니다.\n그리고 핵심 차별점, AI 추론은 고객 계정 안 Bedrock에서 돌립니다. 외부 AI SaaS API가 없으므로 운영 데이터가 계정 밖으로 나가지 않습니다.\n\n전체를 한 장으로 정리하겠습니다.",
+    30: "⏸️ [2min] 아키텍처 파트를 한 장으로 정리합니다.\n첫째, 비공개 엣지 위의 Terraform MSA입니다. CloudFront VPC Origin에서 내부 ALB를 거쳐 Fargate로 가고, 공개 ALB는 없습니다. 둘째, 영속 상태는 Aurora PostgreSQL 17.9입니다. Steampipe는 라이브 엔진이 아니라 flag로 켜는 인벤토리 sync일 뿐입니다.\n\n셋째, 라이브 AWS 읽기는 AgentCore 섹션 에이전트가, 9개 게이트웨이에 약 160개 읽기 전용 도구로 처리합니다. 30개 슬라이스 전부 LIVE입니다. 넷째, 라우팅은 하이브리드고 멀티 계정 STS AssumeRole로 여러 계정을 fan-out 조회합니다. 다섯째, 무거운 작업은 OOM에 안전한 비동기 워커 티어가 받는데, 진단 리포트뿐 아니라 스케줄, 알림 다이제스트, 컴플라이언스 잡까지 늘었습니다. 여섯째, 그 위에 읽기 전용 동결 태세가 있는데 영구 금지는 아니고 좁은 예외 1건이 있습니다. 그리고 in-account Bedrock입니다.\n\n세 번째 파트, 실제 데모와 진단 리포트로 이어가겠습니다.",
     31: "❓ [1min] 두 번째 파트를 마칩니다.\n지금까지 AWSops의 기술 아키텍처를 레이어별로 살펴봤습니다. Terraform 기반 MSA, 비공개 엣지, Aurora 영속 상태, AgentCore 섹션 에이전트, 하이브리드 라우팅, OOM에 안전한 워커 티어, 그리고 읽기 전용 동결 태세까지 모두 하나의 일관된 설계로 묶여 있습니다.\n\n질문 있으시면 편하게 주세요.\n\n잠시 쉬고 마지막 파트, 실전 데모와 진단 리포트로 이어가겠습니다.",
     32: "[1min] 마지막 파트입니다. 지금까지 왜 필요한지, 어떻게 만들었는지를 봤고, 이제 실제로 어떻게 쓰는지를 데모로 보여드리겠습니다.\nAI 어시스턴트, 비용/인벤토리/토폴로지 시나리오, 그리고 종합진단 리포트까지 순서대로 보겠습니다.\n\n한 가지 먼저 짚고 갈 점은, 오늘 보여드리는 모든 데모는 read-only라는 것입니다. 조회와 진단만 하고, AWS 리소스를 변경하지 않습니다.\n\n먼저 AI 어시스턴트 데모입니다.",
     33: "⏸️ [2min] AI 어시스턴트의 동작 흐름을 보겠습니다. 자연어 질문 하나가 답변으로 이어지는 과정입니다.\n\n사용자가 \"EKS 비용 개선점 찾아줘\"라고 질문합니다. 첫 단계는 ADR-003 하이브리드 라우팅입니다. regex fast-path가 먼저 매칭을 시도하고, 애매하면 Haiku 분류기가 판단합니다. 프롬프트 캐싱으로 약 59% 히트율을 내고, 이 질문은 cost 섹션 게이트웨이로 라우팅됩니다.\n\n\n\n선택된 AgentCore 섹션 에이전트가 MCP 도구로 라이브 read-only AWS 조회를 수행합니다. Cost Explorer, EKS 메트릭 등 필요한 도구만 호출합니다. 그리고 in-account Bedrock이 결과를 분석합니다.\n\n\n같은 질문이 실제 화면에서 어떻게 보이는지 이어서 보겠습니다.",