docs: add rel-005 production operator runbook and credential matrix (REQ-020~022)

Release: REL-005_20260512 — Production Operator Runbook and Credential Matrix

Requirements Approved (REQ-020~022):
- REQ-020: production admin bootstrap and steady-state operator access runbook (Deployment)
- REQ-021: release credential matrix and token provenance procedures (Documentation)
- REQ-022: operator log access and release evidence recording procedures (Documentation)

Batch: BAT-009
- Enhance README.md Production Operator Runbook section with:
  - Deployment secret custodian role labels
  - Release approver and production operator role definitions
  - Credential matrix table (public/read/trade-write/admin permission levels)
  - Canonical smoke environment specifications
  - HTTP status code interpretation (401/403/404)
  - Release evidence recording fields

Documentation Updates:
- Add README.md Section 2: deployment roles and responsibilities
- Add README.md Section 3: 4-tier credential matrix with token usage patterns
- Enhance README.md Section 6: smoke test procedures and evidence capture
- Add bootstrap/steady-state/break-glass 3-tier access pathway clarification
- Create REQ-020 Deployment runbook document
- Create REQ-021 credential matrix procedures document
- Create REQ-022 operator log access procedures document

Discovery & Release:
- Update dcy-005 with operator access requirements analysis
- Create rel-005 with docs-only profile and deployment notes
- Update docs/batches/index.md with BAT-009 entry
- Update docs/srs/index.md with REQ-020~022 entries and change log

docs/discovery/dcy-005_20260511_production-admin-bootstrap-and-operator-access.md

@@ -1,24 +1,24 @@
 # 0. 문서 상태
 이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.
 
-- 상태: draft
+- 상태: confirmed
 - 문서 ID: dcy-005_20260511_production-admin-bootstrap-and-operator-access
 - 이슈명: 실배포 admin bootstrap 및 operator access 경로 정립
 - 작성 시각(KST): 2026-05-11 23:12
-- 마지막 갱신 시각(KST): 2026-05-11 23:12
+- 마지막 갱신 시각(KST): 2026-05-12 14:50
 - 대체됨: 없음
 - 후속 Discovery 참조: 없음
-- 생성된 REQ 참조: 없음
+- 생성된 REQ 참조: REQ-020, REQ-021, REQ-022
 
 # 1. 계획 상태 요약
 현재 Discovery가 어떤 배경에서 작성되고 있는지, 연계 문서가 있는지, 지금 시점의 해석이 무엇인지 짧게 요약한다.
 
 - 연계 문서 현황:
-	- 관련 점수 파일: 미생성
 	- 관련 TODO/메모: docs/releases/rel-001_20260502_trex-basic-v1-api-contract.md
+	- 관련 운영 문서: README.md "Production Operator Runbook"
 - 해석:
-	- REL-001 실배포 smoke에서 public health와 read service-token 경로는 확인됐지만, admin 성공 경로와 trade-write 성공 경로를 완료할 운영 접근 방법이 저장소 문서에 정의돼 있지 않다.
-	- 이번 Discovery는 활성 release 검증을 막는 운영 문제를 별도 주기로 분리해, 실배포 admin bootstrap, operator auth path, smoke credential provenance, 로그 접근 절차를 독립적으로 정리하기 위한 초안이다.
+	- REL-001은 released 상태로 전환됐지만, admin 성공 경로와 trade-write 성공 경로는 후속 운영 smoke로 닫아야 한다. 본 문서는 production smoke를 canonical acceptance로, staging smoke를 optional preflight로 두는 기준과 evidence 기록 위치를 고정한다.
+	- 이번 Discovery는 release blocker 해소보다는 released 이후 운영 hardening 항목으로서, 실배포 admin bootstrap, operator auth path, smoke credential provenance, 로그 접근 절차, 운영 책임 역할을 REQ handoff 가능한 수준으로 정리하기 위한 문서다.
 
 # 2. 요구사항 판정 결과
 이번 요청이 기존 요구사항과 비교해 신규인지, 유사한지, 중복인지 판단하고 그 근거를 남긴다.
@@ -35,9 +35,9 @@
 
 - 현재 상태
 	- 실배포 URL `https://fourblocks2026.com/portfolio-hub/`에서 `GET /health`, `/docs`, `/openapi.json`은 정상 응답했고, read service-token으로 `GET /v1/assets`, `GET /v1/user_info`까지는 검증됐다.
-	- 동일 토큰으로 `POST /auth/service-tokens`를 호출하면 `403 Insufficient permission`이 반환됐다. 현재 저장소에는 실배포에서 어떤 경로로 admin auth context를 확보하는지, admin 성공 경로를 어떻게 검증하는지 정리한 runbook이 없다.
+	- 동일 토큰으로 `POST /auth/service-tokens`를 호출하면 `403 Insufficient permission`이 반환됐다. 이후 README에 Production Operator Runbook 초안이 추가되어 canonical admin path, smoke credential ownership, log path 기준선은 정리됐고, 후속 smoke는 production을 canonical acceptance 환경으로 수행하며 staging은 optional preflight로만 사용하기로 정리했다. 실행 evidence는 해당 release 문서에 남기고, 절차의 source of truth는 README runbook으로 유지한다.
 	- `app/core/auth.py`는 env token 집합 또는 DB `auth_tokens` principal의 `permission`으로 권한을 해석하고, `app/api/auth_routes.py`의 `POST /auth/service-tokens`는 `require_admin`을 선행한다. 즉 운영자가 어떤 credential을 admin으로 다뤄야 하는지가 명확해야 smoke가 가능하다.
-	- `README.md`와 `app/core/config.py`에는 first-run bootstrap 계정 환경 변수(`PORTFOLIOHUB_BOOTSTRAP_*`)가 있으나, 실배포의 steady-state admin access, smoke용 read/trade-write/admin token 분리, startup/request 로그 접근 경로는 문서화돼 있지 않다.
+	- 현재 저장소 기준선상 프로덕션은 Linux/Ubuntu host에서 systemd로 `portfoliohub` uvicorn 서비스를 띄우고 Caddy를 reverse proxy로 사용하며, secret material은 host-side `EnvironmentFile=/opt/portfoliohub/.env`에서 주입된다. secret leakage 대응 owner는 repository-maintainers 역할 중 deployment secret custodian으로 두고, admin recovery owner는 production operator/release approver 역할로 둔다.
 - 기대 상태
 	- 운영자는 실배포에서 admin auth context를 얻는 표준 경로를 알고 있어야 하며, 그 경로로 `POST /auth/service-tokens` 성공 smoke를 반복 가능하게 수행할 수 있어야 한다.
 	- release 검증에는 public/no-auth, read service-token, trade-write service-token, admin auth context의 용도와 provenance가 문서로 분리돼 있어야 한다.
@@ -50,7 +50,7 @@
 - 제약사항
 	- 실제 credential 원문은 저장소, release 문서, Discovery 문서에 기록하지 않는다.
 	- 기존 auth model(`read`, `trade-write`, `admin` 권한과 DB-issued service-token 구조)은 유지하되, 필요한 경우 bootstrap/runbook 또는 최소한의 운영 지원 기능만 추가한다.
-	- 활성 release(REL-001)와 병렬로 진행되므로, 이 Discovery는 운영 접근성과 검증 절차를 정리하는 데 집중하고 기존 consumer contract 범위를 임의로 확장하지 않는다.
+	- REL-001이 released 전환된 이후의 후속 운영 hardening 범위를 다루므로, 이 Discovery는 운영 접근성과 검증 절차를 정리하는 데 집중하고 기존 consumer contract 범위를 임의로 확장하지 않는다.
 
 ## 주요 사용자 시나리오
 사용자 또는 운영자가 실제로 어떤 상황에서 이 변경을 필요로 하는지 대표 시나리오를 적는다.
@@ -62,9 +62,9 @@
 # 4. 이번에 정의할 변경
 이번 Discovery에서 다루는 핵심 변경 항목을 목록으로 적는다. 기능, 구조, 규칙 변경을 함께 포함해도 된다.
 
-- 실배포 admin bootstrap 및 steady-state operator access 경로를 정의한다. bootstrap user, admin login/session, admin token, DB-issued admin service token 중 어떤 경로를 표준으로 쓸지 결정한다.
-- release 검증용 credential matrix를 정의한다. public/no-auth, read service-token, trade-write service-token, admin auth context의 용도와 발급/보관/폐기 절차를 분리한다.
-- startup/request 로그 접근, auth/permission/resource 오류 판독, release evidence 기록 절차를 운영 runbook과 release 문서에 연결한다.
+- 실배포 admin bootstrap 및 steady-state operator access 경로를 정의한다. steady-state canonical path는 운영자 소유 admin 사용자 계정으로 로그인해 확보한 DB-issued admin session 또는 동일 컨텍스트에서 발급한 client token으로 두고, 해당 admin context로 release smoke용 read/trade-write service-token을 발급한다. `PORTFOLIOHUB_BOOTSTRAP_*`는 새 프로덕션 환경에서 `users` 테이블이 비어 있거나 disaster recovery 직후 admin 사용자 부재가 확인된 경우에만 허용하고, steady-state recovery는 운영자 개인 admin 로그인 경로를 우선 사용한다. env admin token은 로그인 경로가 모두 막혔을 때 `/opt/portfoliohub/.env`에서 꺼내는 break-glass fallback으로만 사용한다.
+- release 검증용 credential matrix를 정의한다. public/no-auth, read service-token, trade-write service-token, admin auth context의 용도와 발급/보관/폐기 절차를 분리한다. admin 로그인 자격증명은 운영자 개인별 소유로 두고 공유하지 않으며, read/trade-write smoke service-token은 환경 단위 운영 credential로 취급해 release approver 또는 repository-maintainers 역할이 공동 소유한다. 현재 프로덕션의 canonical secret material location은 host-side `EnvironmentFile=/opt/portfoliohub/.env`이며, raw secret은 이 경로와 동일 접근 통제 하의 운영 절차에서만 보관한다. release 문서에는 이름, token_prefix, permission, runtime_id, 발급/폐기 시각만 기록한다.
+- startup/request 로그 접근, auth/permission/resource 오류 판독, release evidence 기록 절차를 운영 runbook과 release 문서에 연결한다. canonical acceptance smoke는 production에서 수행하고, staging smoke는 optional preflight로만 사용한다. 절차의 source of truth는 README runbook으로 유지하고, 실행 evidence의 canonical record는 해당 release 문서에 남긴다. 현재 canonical log access path는 Linux/Ubuntu production host의 systemd journal에서 `portfoliohub` 서비스 로그와 Caddy reverse proxy 로그를 확인하는 경로다. 즉 `journalctl -u portfoliohub`와 `journalctl -u caddy`가 1차 운영 경로이며, Loki는 `LOKI_ENABLED`와 실제 수집 경로가 운영 환경에 명시적으로 구성된 경우에만 보조 집계 경로로 취급한다.
 
 ## 영향 범위
 변경이 미칠 코드/문서/운영 범위를 명시해 REQ 정제와 batch planning에서 추정 누락을 줄인다.
@@ -87,10 +87,10 @@
 실제로 구현과 검증으로 이어질 요구사항을 기능/비기능으로 나누어 정리하고, 범위 경계를 명확히 적는다.
 
 ## 기능 요구사항
-- FR-1: 실배포에서 admin auth context를 확보하는 표준 경로를 정의한다. first-run bootstrap과 steady-state 운영 경로를 구분하고, 운영자가 어떤 credential로 `POST /auth/service-tokens`를 성공시켜야 하는지 명시한다.
-- FR-2: release 검증에 필요한 credential matrix를 정의한다. public/no-auth, read service-token, trade-write service-token, admin auth context 각각의 발급 주체, 보관 위치, 만료 정책, 폐기 절차를 문서화한다.
-- FR-3: REL-001과 같은 app-service release에서 startup log, request log, auth/permission/resource 오류를 수집하는 운영 runbook을 정의한다.
-- FR-4: 운영자가 DB 콘솔에 직접 들어가지 않고도 token provenance 또는 권한 수준을 확인할 수 있는 최소 지원 수단이 필요한지 판정하고, 필요 시 구현 또는 문서 경로를 정의한다.
+- FR-1: 실배포에서 admin auth context를 확보하는 표준 경로를 정의한다. steady-state canonical path는 운영자 소유 admin 사용자 계정의 로그인으로 확보한 DB-issued admin session 또는 동일 컨텍스트에서 발급한 client token으로 하고, 이 경로로 `POST /auth/service-tokens`를 호출해 read/trade-write service-token을 발급하도록 명시한다. `PORTFOLIOHUB_BOOTSTRAP_*` 기반 bootstrap은 `users` 테이블이 비어 있는 신규 환경 또는 disaster recovery 직후 admin 사용자 부재가 확인된 경우에만 허용한다. steady-state recovery는 기존 운영자 admin 로그인 경로를 우선 사용하고, env admin token은 `/opt/portfoliohub/.env`에서만 꺼내는 break-glass fallback으로 제한한다.
+- FR-2: release 검증에 필요한 credential matrix를 정의한다. public/no-auth, read service-token, trade-write service-token, admin auth context 각각의 발급 주체, 보관 위치, 만료 정책, 폐기 절차를 문서화한다. admin 로그인 자격증명은 named operator가 개인별로 소유하고 공유하지 않으며, read/trade-write smoke service-token은 환경 단위 운영 credential로서 release approver 또는 repository-maintainers 역할이 공동 소유한다. 현재 프로덕션 secret material location은 `portfoliohub` systemd service의 `EnvironmentFile=/opt/portfoliohub/.env`로 정의하고, release evidence에는 name, token_prefix, permission, runtime_id, issued_at, revoked_at만 남긴다.
+- FR-3: REL-001과 같은 app-service release에서 startup log, request log, auth/permission/resource 오류를 수집하는 운영 runbook을 정의한다. canonical acceptance smoke는 production에서 수행하고, staging smoke는 optional preflight로만 사용한다. 절차의 source of truth는 README runbook으로 유지하고, 실행 evidence의 canonical record는 해당 release 문서에 남긴다. 기본 수집 경로는 Linux/Ubuntu production host의 systemd journal에서 `portfoliohub` uvicorn 서비스와 Caddy reverse proxy 로그를 조회하는 방식으로 하고, 구체 명령은 `journalctl -u portfoliohub`와 `journalctl -u caddy`를 사용한다. Loki는 운영 환경에서 실제 활성화가 확인된 경우에만 보조 조회 경로로 포함한다. 외부 URL만으로 로그 접근이 불가능한 점, 운영자가 어떤 콘솔 또는 CLI 권한으로 해당 로그를 조회하는지, release evidence에 남길 최소 필드(시각, 경로, 상태 코드, 소스 시스템)를 함께 문서화한다.
+- FR-4: 운영자가 DB 콘솔에 직접 들어가지 않고도 token provenance 또는 권한 수준을 확인할 수 있는 최소 지원 수단을 정의한다. 신규 관리 기능을 추가하기보다 기존 `pfhub service-token list`, `pfhub service-token issue`, `pfhub service-token rotate`, `pfhub user get`, `GET /v1/user_info`를 canonical support path로 문서화하고, 이름, token_prefix, token_id, user_id, permission, created_at, last_used_at, revoked_at, runtime_id를 provenance 확인 필드로 사용한다.
 
 ## 비기능 요구사항
 성능, 운영성, 일관성, 자동화 안정성 등 기능 외 요구사항을 적는다.
@@ -117,9 +117,9 @@
 
 ## 리스크
 - R-1 (High): admin/bootstrap credential을 ad-hoc 방식으로 공유하면 secret leakage가 발생할 수 있다.
-	- 완화 방안: secret manager 또는 승인된 보관소만 사용하고, 저장소/문서에는 raw value를 남기지 않는다.
+	- 완화 방안: secret manager 또는 승인된 보관소만 사용하고, 저장소/문서에는 raw value를 남기지 않는다. 대응 owner는 repository-maintainers 역할 중 deployment secret custodian으로 둔다.
 - R-2 (Medium): first-run bootstrap 계정 경로만 정리하고 steady-state 운영 경로를 정의하지 않으면, 이미 사용자가 있는 실배포 환경에서는 같은 문제를 반복한다.
-	- 완화 방안: bootstrap과 steady-state access/recovery를 별도 요구사항으로 분리해 정의한다.
+	- 완화 방안: bootstrap과 steady-state access/recovery를 별도 요구사항으로 분리해 정의한다. admin recovery owner는 production operator/release approver 역할로 둔다.
 - R-3 (Medium): 로그 접근 경로가 환경 의존적이면 release 증적 수집이 담당자 개인 지식에 묶인다.
 	- 완화 방안: 최소한의 환경 계약(예: 어느 시스템에서 startup/request 로그를 확인하는지)을 문서화한다.
 
@@ -134,17 +134,20 @@
 답을 아직 모르는 항목을 적는다. 추정으로 덮지 말고 REQ 초안 작성 이전에 확인할 질문으로 남긴다.
 
 - OQ-1: steady-state admin access의 표준 경로는 무엇인가? bootstrap admin 로그인, env admin token, DB-issued admin session/token, 별도 운영 절차 중 무엇을 canonical path로 삼을지.
-	- 상태: Open
-	- 처리 방안: 운영자와 승인자가 실제 배포 체계를 확인하고 canonical path를 하나로 선택한다.
-	- 종료 조건: REL-001 후속 release 검증에 사용할 admin path가 문서화되면 Answered 처리.
+	- 상태: Answered
+	- 답변: steady-state canonical path는 운영자 소유 admin 사용자 계정으로 `/auth/login` 하여 확보한 DB-issued admin session 또는 동일 컨텍스트에서 발급한 client token이다. 운영자는 이 admin context로 `POST /auth/service-tokens`를 호출해 release smoke용 read/trade-write service-token을 발급한다. `PORTFOLIOHUB_BOOTSTRAP_*`는 `users` 테이블이 비어 있는 신규 환경 또는 disaster recovery 직후 admin 사용자 부재가 확인된 경우에만 사용하고, env admin token은 `/opt/portfoliohub/.env`에서만 꺼내는 break-glass fallback으로만 사용한다.
+	- 처리 방안: FR-1과 운영 runbook에 canonical path, bootstrap path, break-glass fallback의 구분을 반영한다. 또한 프로덕션에 운영자용 admin 사용자 계정이 실제로 존재해야 하며, 해당 로그인 자격증명과 break-glass env token은 `portfoliohub` systemd service의 `EnvironmentFile=/opt/portfoliohub/.env` 관리 경로 안에서 통제된다는 운영 전제를 후속 문서에 명시한다.
+	- 종료 조건: README 또는 후속 운영 문서에 canonical path와 fallback 절차가 반영되고, REL-001 후속 release smoke가 해당 경로로 재현되면 resolved 기록으로 이동한다.
 - OQ-2: startup/request 로그는 어디에서 확인하는가? 호스팅 환경, reverse proxy, Loki 등 실제 로그 경로와 접근 권한을 어떻게 운영자에게 부여하는가.
-	- 상태: Open
-	- 처리 방안: 현재 실배포 로그 스택과 접근 권한 모델을 확인한 뒤 runbook에 반영한다.
-	- 종료 조건: 실제 로그 수집 절차가 문서에 추가되면 Answered 처리.
+	- 상태: Answered
+	- 답변: 현재 canonical log access path는 Linux/Ubuntu production host의 systemd journal이다. 애플리케이션 startup 및 runtime 로그는 `journalctl -u portfoliohub`, reverse proxy 또는 access 수준 로그는 `journalctl -u caddy`로 확인한다. Loki는 설정 항목은 존재하지만 현재 저장소에는 프로덕션 수집 경로와 명시적 runtime flow가 없으므로 기본 표준 경로로 간주하지 않고, 운영 환경에서 `LOKI_ENABLED`와 실제 수집 파이프라인이 확인된 경우에만 보조 집계 경로로 취급한다.
+	- 처리 방안: FR-3과 운영 runbook에 로그 조회 채널을 systemd journal 기준으로 명시하고, startup log와 reverse proxy log를 각각 어떤 `journalctl` 명령으로 확인하는지 구분한다. 또한 release evidence에는 raw secret 없이 시각, 경로, 상태 코드, 소스 시스템, 상관 가능한 요청 식별자만 남긴다.
+	- 종료 조건: README 또는 후속 운영 문서에 `journalctl -u portfoliohub`, `journalctl -u caddy` 기반 로그 조회 절차와 evidence 필드가 반영되고, REL-001 후속 release smoke에서 startup/request 로그 확인 근거가 같은 채널로 재현되면 resolved 기록으로 이동한다.
 - OQ-3: token provenance 확인 수단은 문서화만으로 충분한가, 아니면 최소한의 CLI/관리 기능이 필요한가.
-	- 상태: Open
-	- 처리 방안: runbook-only 접근과 지원 기능 추가 비용을 비교해 결정한다.
-	- 종료 조건: REQ 초안 단계에서 지원 수단이 문서-only인지 구현 포함인지 확정되면 Answered 처리.
+	- 상태: Answered
+	- 답변: runbook-only 접근만으로는 부족하지만, 신규 관리 기능을 추가할 필요는 없다. 현재 저장소의 기존 CLI와 API가 이미 최소 provenance 확인 수단을 제공하므로, 이를 canonical support path로 문서화하는 것으로 충분하다. 운영자는 `pfhub service-token list`로 이름, token_prefix, token_id, user_id, permission, created_at, last_used_at, revoked_at를 확인하고, 발급/rotate 시 반환되는 `runtime_id`와 `GET /v1/user_info`의 `runtime_id`를 대조해 실배포 smoke에 사용한 service-token provenance를 확인한다. `pfhub user get`은 사용자별 service token 이름 목록 확인 보조 수단으로 사용한다.
+	- 처리 방안: FR-4와 운영 runbook에 기존 지원 수단의 사용 순서를 반영하고, README 또는 후속 운영 문서에서 `service-token list`와 `service-token rotate`를 명시한다. 추가 구현은 보류하고, 실제 smoke rehearsal에서 기존 수단만으로 provenance 판독이 부족할 때만 후속 REQ로 승격한다.
+	- 종료 조건: README 또는 후속 운영 문서에 provenance 확인 절차와 필드가 반영되고, REL-001 후속 release smoke에서 기존 CLI/API만으로 사용 토큰의 permission 및 provenance를 재현 가능하게 확인하면 resolved 기록으로 이동한다.
 
 ### 오픈 질문 처리 기준
 - `Open`: 아직 답이 없고 다음 단계 진행에 영향이 있는 상태다. 문서에 유지한다.
@@ -165,28 +168,28 @@
 ## 측정 방식 및 데이터 출처
 각 성공 기준을 어떻게 측정할지와 어떤 데이터나 문서를 근거로 쓸지 적는다.
 
-- S-1 측정 방식: 운영 runbook 리뷰 및 smoke rehearsal / 데이터 출처: README.md 또는 신규 운영 문서, release verification 기록
-- S-2 측정 방식: 실배포 또는 staging smoke에서 admin/read/trade-write 경로를 각각 실행 / 데이터 출처: release 문서, HTTP 응답 로그, 운영자가 제공한 검증 기록
-- S-3 측정 방식: release 문서와 baseline 문서에 로그 접근 및 증적 수집 항목 포함 여부 확인 / 데이터 출처: docs/releases/*.md, docs/runtime-flows.md, docs/project-structure.md
+- S-1 측정 방식: README runbook 리뷰 후 production smoke 기준 절차를 rehearsal하고 필요 시 staging에서 optional preflight 수행 / 데이터 출처: README.md, 해당 release 문서의 verification 기록
+- S-2 측정 방식: canonical acceptance로 production smoke에서 admin/read/trade-write 경로를 각각 실행하고, staging smoke는 사전 rehearsal로만 사용 / 데이터 출처: 해당 release 문서, HTTP 응답 로그, 운영자가 제공한 검증 기록
+- S-3 측정 방식: release 문서에 실행 evidence가 기록되고 baseline 문서에 로그 접근 및 증적 수집 항목이 반영됐는지 확인 / 데이터 출처: docs/releases/*.md, docs/runtime-flows.md, docs/project-structure.md, README.md
 
 # 8. REQ로 넘기기 전 확인 체크
 REQ 초안 작성 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다. 미완료 항목은 후속 결정이 필요함을 뜻한다.
 
-- [ ] 범위(In Scope/Out of Scope) 확정
+- [x] 범위(In Scope/Out of Scope) 확정
 	- 기준: admin bootstrap, steady-state access, logging scope의 포함/제외 범위 합의
-- [ ] 성공 지표의 측정 방식/데이터 출처 확정
-	- 기준: staging/production 중 어디서 smoke를 수행할지와 evidence 위치 확정
-- [ ] High 영향 리스크 우선순위 및 해소 책임자 지정
-	- 기준: secret leakage와 admin recovery 책임자 지정
-- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인
+- [x] 성공 지표의 측정 방식/데이터 출처 확정
+	- 기준: canonical acceptance smoke는 production, staging smoke는 optional preflight, 실행 evidence는 해당 release 문서에 기록
+- [x] 핵심 리스크 우선순위 및 해소 책임자 지정
+	- 기준: secret leakage owner는 repository-maintainers 역할의 deployment secret custodian, admin recovery owner는 production operator/release approver 역할
+- [x] 모든 오픈 질문(OQ) `Open` 상태 없음 확인
 	- 기준: OQ 목록의 `Open` 상태가 0개
-- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정
+- [x] Freeze 확정 담당자(CONFIRMED_BY) 지정
 	- 기준: 운영 승인자 또는 repository-maintainers 중 확인자 지정
 
 # 9. 파일 처리 결과
 이 Discovery 문서 생성/갱신 결과와 참조 문서를 기록한다. 이후 추적과 리뷰 시 근거로 사용한다.
 
-- 처리 결과: 생성
+- 처리 결과: 생성 후 갱신
 - 생성 경로: docs/discovery/dcy-005_20260511_production-admin-bootstrap-and-operator-access.md
 - 참조 문서:
 	- docs/releases/rel-001_20260502_trex-basic-v1-api-contract.md
@@ -199,16 +202,21 @@ REQ 초안 작성 단계로 넘기기 전에 무엇이 확정되어야 하는지
 사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. 결정, 확인, 데이터 요청을 구분해서 적는다.
 
 ## DECIDE
-- {{DECIDE_CANONICAL_ADMIN_ACCESS_PATH}}
-- {{DECIDE_SMOKE_CREDENTIAL_OWNERSHIP_POLICY}}
+- 없음
 
 ## CONFIRM
-- {{CONFIRM_LOG_ACCESS_CHANNEL}}
-- {{CONFIRM_BOOTSTRAP_VS_STEADY_STATE_RECOVERY_SCOPE}}
+- 없음 (Confirmed By: Justin — 2026-05-12)
 
 ## DATA
-- {{DATA_SECRET_STORE_LOCATION}}
-- {{DATA_PRODUCTION_LOG_STACK}}
+- baseline 반영 완료
+	- canonical smoke environment: production
+	- staging smoke role: optional preflight only
+	- canonical evidence location: 해당 release 문서
+	- procedure source of truth: README.md "Production Operator Runbook"
+	- secret store location: production host의 `portfoliohub` systemd service가 참조하는 `EnvironmentFile=/opt/portfoliohub/.env`
+	- production log stack: Linux/Ubuntu host + systemd-managed `portfoliohub` uvicorn service + Caddy reverse proxy, primary log commands `journalctl -u portfoliohub` 및 `journalctl -u caddy`
+	- secret leakage owner: repository-maintainers 역할 중 deployment secret custodian
+	- admin recovery owner: production operator/release approver 역할
 
 # 11. Discovery Freeze
 REQ 초안 작성 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.
@@ -221,18 +229,8 @@ REQ 초안 작성 인계 시점의 확정 플래그와 섹션 참조만 기록
 - 사용자 결정 필요: [# 10. 사용자 결정 필요 항목 요약](#10-사용자-결정-필요-항목-요약)
 
 ## Freeze 플래그
-- Handoff Decision: 보류
-- Handoff Rationale: 운영 경로의 핵심 선택지(admin canonical path, 로그 접근, smoke credential provenance)가 아직 Open 상태라 REQ 초안 작성 전 사용자 확인이 필요하다.
-- Ready for REQ Drafting: false
-- Confirmed By: TBD
-- Confirmed At (KST): TBD
-
-# 12. 작성 가이드
-템플릿 사용 시의 기본 규칙을 적는다. 실제 문서를 만들 때는 이 가이드를 기준으로 플레이스홀더를 치환한다.
-
-- 이 파일은 템플릿이다. 실제 문서 작성 시 `{{...}}` 플레이스홀더를 구체 값으로 교체한다.
-- 필요 없는 항목은 삭제하고, 부족한 항목은 같은 형식으로 추가한다.
-- Open Questions는 가정으로 대체하지 말고 그대로 유지한다.
-- `대체됨`은 현재 Discovery가 더 이상 기준 문서가 아닐 때 대체 Discovery 경로를 기록하고, 해당 사항이 없으면 `없음`으로 둔다.
-- `후속 Discovery 참조`는 범위를 이어받는 별도 Discovery가 생성된 경우 그 Discovery 경로를 기록하고, 없으면 `없음`으로 둔다.
-- Discovery Freeze는 문서 하단에 반드시 유지한다.
+- Handoff Decision: 승인
+- Handoff Rationale: 핵심 운영 경로(OQ-1~3), smoke credential ownership policy, bootstrap 대 steady-state recovery 범위, canonical smoke/evidence 기준, secret store/log stack 기준선, 운영 책임 역할 모두 반영 완료. Freeze confirmer Justin 지정 완료. 오픈 질문 0개, C 유형 플레이스홀더 0개.
+- Ready for REQ Drafting: true
+- Confirmed By: Justin
+- Confirmed At (KST): 2026-05-12 14:35

docs/discovery/index.md

@@ -10,4 +10,4 @@
 | dcy-002_20260502_trex-basic-consumer-api-contract | 20260502 | trex-basic Consumer-Driven Contract 반영 — service-token runtime_id 발급 및 v1 API 엔드포인트 구현 | [Discovery](./dcy-002_20260502_trex-basic-consumer-api-contract.md) | confirmed |
 | dcy-003_20260502_portfolio-list-user-required | 20260502 | CLI `pfhub portfolio list` — `--user` 옵션 필수화 및 소유자 기반 조회 강제 | [Discovery](./dcy-003_20260502_portfolio-list-user-required.md) | confirmed |
 | dcy-004_20260511_portfolio-id-uuid-migration-and-user-scoped-name-resolution | 20260511 | portfolio_id UUID 교체 및 CLI 사용자 범위 기반 자산 식별 구조 전환 | [Discovery](./dcy-004_20260511_portfolio-id-uuid-migration-and-user-scoped-name-resolution.md) | confirmed |
-| dcy-005_20260511_production-admin-bootstrap-and-operator-access | 20260511 | 실배포 admin bootstrap 및 operator access 경로 정립 | [Discovery](./dcy-005_20260511_production-admin-bootstrap-and-operator-access.md) | draft |
+| dcy-005_20260511_production-admin-bootstrap-and-operator-access | 20260511 | 실배포 admin bootstrap 및 operator access 경로 정립 | [Discovery](./dcy-005_20260511_production-admin-bootstrap-and-operator-access.md) | confirmed |