docs: record 1.0.4 package verification

docs/PLAYOUT_OPERATIONS.md

@@ -7,9 +7,9 @@
 | 항목 | 상태 |
 |---|---|
 | 기본 모드 | `DryRun`; COM 객체와 `KTAPConnect`를 만들지 않음 |
-| 자동 테스트 | 최종 전체 재검증에서 Core Debug/Release x64 각각 1,259/1,259, Playout 각각 387/387, Infrastructure 각각 173/173(합계 각 1,819/1,819), Web 371/371 통과; 실패·skip 0건 |
+| 자동 테스트 | 최종 전체 재검증에서 Core Debug/Release x64 각각 1,377/1,377, Playout 각각 387/387, Infrastructure 각각 173/173(합계 각 1,937/1,937), Web 413/413 통과; 실패·skip 0건 |
 | Visual Studio 2026 | MSBuild `18.7.8.30822` Debug x64와 signed Release x64 패키지 빌드 성공 |
-| trusted Release x64 MSIX | clean commit `a01836a`에서 `1.0.3.0` 생성·`CN=Comtrophy` 서명/SignTool 검증·x64 설치·package context 실행 성공. SHA-256 `B46C225B6859F7EBBFDDA83F4433DC64AFDCD59230B667A28BAEC0AE328534C6`; 288개 항목, source Web 31개 byte 일치, 금지 자산 0건. WebView2 6개, 단일 인스턴스, 종료 확인 취소/정상 종료/재시작, `DryRunReady`, Oracle/MariaDB `Healthy`를 확인 |
+| trusted Release x64 MSIX | clean commit `af80c36`에서 `1.0.4.0` 생성·`CN=Comtrophy` 서명/SignTool 검증·x64 update 설치·package context 실행 성공. SHA-256 `E8DB3C0E94963130548FAEF1880A9F9B99829064257F7196F41B7B8F0EE50B6C`; 290개 항목, source Web 33개 byte 일치, 금지 자산 0건. 단일 인스턴스, 실제 종목 검색·업무 탭 상태·비교 8쌍, `DryRunReady`, Oracle/MariaDB `Healthy`를 확인 |
 | 실제 DB read→DTO→mutation smoke | 34개 도달 가능 data route 통과: 33개 DB + `s5025` trusted 외부 CP949 파일. `s8086` diagnostic과 NXT restore audit를 포함한 Oracle/MariaDB query 58건 통과. 종속 asset·운영 DB-W·PGM 검증은 포함하지 않음 |
 | `s5025` trusted 수동 파일 | 외부 CP949 source 통합 검증 통과; 실제 파일/환경은 계속 Git 밖에서 회차별 preflight |
 | `s5006` `Video\큐브배경.vrv` | 현재 승인 Cuts root에서 누락 |
@@ -18,6 +18,12 @@
 
 1.0.2 Visual Studio 개발 등록본을 signed 1.0.3으로 교체할 때 `Remove-AppxPackage -PreserveApplicationData`를 사용했다. 재등록 구간에서 바뀐 파일은 Windows package Settings transaction log `settings.dat.LOG1/LOG2`뿐이었고, WebView LocalState와 외부 `%LOCALAPPDATA%\MBN_STOCK_WEBVIEW` 운영 데이터는 삭제·덮어쓰지 않았다. 이 패키지 검증 회차는 기본 설정 부재와 환경 override 0건을 확인한 `DryRun`으로만 실행했으며 Tornado 실제 명령은 보내지 않았다.
 
+1.0.3에서 1.0.4로는 앱 종료 확인창을 통한 정상 종료 뒤 같은 package family에
+in-place update했다. remove/reset 없이 비교 8쌍과 one-time marker가 유지됐고,
+설치본에서 실제 `삼성` 63건 검색과 10개 업무 탭 상태 유지, 단일 인스턴스를
+확인했다. 로그는 `DryRunReady`와 DB Healthy만 기록했으며 playout command는 0건이다.
+상세 내용은 [`RELEASE_1_0_4_AUDIT.md`](RELEASE_1_0_4_AUDIT.md)에 있다.
+
 과거 고정 `5001 → 5006` runner의 실제 PGM 기록은 연결과 기본 K3D 명령 표면의 증거다. 현재 WebView playlist, fresh TAKE IN, Page NEXT, timer refresh, callback/unload의 동등성 완료 증거는 아니다.
 
 2026-07-11의 승인 회차 `MBNWEB-20260711-A`에서는 현재 MSIX WebView runtime으로 `CONNECT → PREPARE 5001/page 1`까지 성공했다. Network Monitoring에 `HELLO`, `LOAD_SCENE`, `BEGIN_TRANSACTION`, 데이터 mutation, `QUERY_VARIABLES`, `END_TRANSACTION`, `SCENE_PREPARE`의 request/success가 기록됐고 PREPARE 동안 PGM은 검은 화면이었다. TAKE IN은 두 번째 K3D Prepare/Play 전에 수행하는 fresh Oracle 조회에서 `DATABASE_UNAVAILABLE`로 명확히 실패했다. `PLAY`가 없고 PGM도 검은 상태임을 확인해 TAKE IN을 반복하지 않았으며, 승인 범위의 `TAKE OUT All` 한 번으로 `STOPAL → UNLOAD_SCENE 5001` 성공을 확인하고 `BYE` 뒤 앱을 정상 종료했다. 직후 probe는 Oracle unhealthy/MariaDB healthy와 정상 DNS/TCP 도달을 보였고, 회차 종료 뒤 전체 55-query 스모크는 두 DB 모두 다시 통과했다. 이 회차는 실패·복구 증거이며 동등성 완료 증거가 아니다. 새 package/계획 SHA-256과 새 Gate A/B로 처음부터 다시 시작한다.
@@ -68,9 +74,9 @@ Round H 전에 Core 790, Infrastructure 65, Playout 374개 테스트를 Debug/Re
 ## 화면/계약과 운영 검증의 분리
 
 - 화면·native bridge·DTO·mutation·identity 상관 계약이 존재하고 자동 테스트가 통과한 상태를 화면/계약 구현으로 기록한다.
-- PList의 기존 한국어 `DC_TITLE`/`LIST_TEXT` 복원과 GraphE·FSell·VI를 포함한 manual named save→fresh restore는 적용 중이며 운영 검증 완료가 아니다.
+- PList의 기존 한국어 `DC_TITLE`/`LIST_TEXT` 2,213행은 read-only 무손상 대조를 마쳤고 통합 `selectionMapped=1,603`/차단 610이다. 이는 scene/asset/PREPARE/PGM 완료가 아니며 manual named 운영 write→reload는 미검증이다.
 - ThemeA/EList의 expected identity 계약은 구현됐지만 실제 운영 DB에서 KRX/NXT·동명이름·코드 경계와 정확한 selected-row replace/delete를 확인하지 않았다.
-- 원본 `종목비교.dat`, FSell, VI 파일의 one-time private-store importer 코드는 적용했고, 실제 package profile의 명시적 1회 실행은 미검증이다.
+- 원본 `종목비교.dat` 8쌍은 signed package에서 one-time 실행·재시작 영속성을 확인했다. FSell/VI는 격리 import fixture와 현재 운영 파일 read-only 불변 검증을 마쳤지만 기존 운영 파일은 덮어쓰지 않았다.
 - GraphE·PList/AList·ThemeA·EList의 실제 운영 DB-W와 승인된 `5001`/`5074` 밖의 PGM은 미검증이다. 이 작업은 승인된 테스트 데이터·rollback과 장면별 별도 회차가 있어야 한다.
 
 ## 절대 안전 규칙