Files
MBN_STOCK_WEBVIEW/docs/RELEASE_1_0_5_AUDIT.md

5.9 KiB

1.0.5 Release x64 MSIX 감사

기준일: 2026-07-12

패키지 소스 커밋: df60e09884acac2e9cb47d50ba902fa13cf7e154

변경 목적

Round I MBNWEB-20260712-I에서 승인된 자동 refresh 최대 1회를 넘어 9회가 실행된 회귀를 차단하기 위해 trusted JSON-only maximumAutomaticRefreshesPerTakeIn 상한을 추가했다. 유한 상한에서는 두 번째 refresh를 scheduler와 실제 dispatch 경계에서 모두 차단하고, 마지막 OnScenePlayed가 drain된 뒤에만 refreshLimitReached=trueCAPPED를 보고한다. callback timeout·취소·구세대 상태는 fail-closed이며 자동 재시도하지 않는다.

빌드와 자동 검증

  • Core 1,383, Infrastructure 173, Playout 393 테스트가 Debug/Release x64에서 각각 모두 통과했다. 구성별 1,949개, 두 구성 합계 3,898개이며 실패·skip은 0건이다.
  • Web 구문 27개, Web 테스트 415/415, scene catalog 35, reachable preset 34, 원본 scene 기준선 35/35가 통과했다.
  • 실제 Oracle/MariaDB SELECT-only smoke는 query 58건과 필수 scene loader 33/33을 통과했다. writesAttempted=false이며 운영 DB write는 수행하지 않았다.
  • Release x64 앱과 MSIX 생성은 경고 0, 오류 0으로 끝났다.

서명 패키지

항목 결과
identity Wickedness.MBNStockWebView
버전·아키텍처 1.0.5.0, x64
package family Wickedness.MBNStockWebView_qbv3jkvsn3aj0
설치본 Wickedness.MBNStockWebView_1.0.5.0_x64__qbv3jkvsn3aj0
SHA-256 1B0BA713619CC3BD7CB3E03D78FD1EB1CEAF49E7D50F5C00DDFB483917BA5437
크기 48,472,530 bytes
서명 CN=Comtrophy, SignTool /pa 검증 성공, warning/error 0
내용 290개 항목, source Web 33개 byte-for-byte 일치
제외 검사 vendor/K3D/Tornado DLL, 인증서·개인 키, Cuts, .t2s, .vrv, 운영 local config 0건

서명에는 timestamp가 없으므로 이 파일을 인증서 만료 뒤 장기 유효 서명으로 간주하지 않는다. MSIX는 .gitignore 대상이며 로컬 경로는 AppPackages\MBN_STOCK_WEBVIEW_1.0.5.0_x64_Test\MBN_STOCK_WEBVIEW_1.0.5.0_x64.msix다.

설치 package-context DryRun

1.0.4를 정상 종료한 뒤 같은 package family의 1.0.5로 in-place update했으며 app-data reset이나 강제 종료를 사용하지 않았다. 설치된 WindowsApps 실행 파일은 C:\Program Files\WindowsApps\Wickedness.MBNStockWebView_1.0.5.0_x64__qbv3jkvsn3aj0\MBN_STOCK_WEBVIEW.exe였다.

임시 trusted 설정을 DryRun, maximumAutomaticRefreshesPerTakeIn=1로 고정하고 실제 종목 검색에서 삼성전자를 선택해 1열판기본_현재가 5001 한 건을 구성했다. 다음 상태 전이가 모두 통과했다.

  1. 시작: IDLE, completed=0, maximum=1, limitReached=false, connected=false, ktapConnectAttempted=false
  2. PREPARE: 5001/page 1, builder s5001, 실제 DB mutation preview 생성
  3. TAKE IN 뒤 정확히 한 번 refresh: PROGRAM, completed=1, maximum=1, limitReached=true, refreshActive=false, playCompletionPending=false, 화면 CAPPED · 1/1
  4. 3.5초 추가 대기: count와 refreshLastSuccessAt가 변하지 않아 두 번째 dispatch가 없음을 확인
  5. TAKE OUT: IDLE, completed=0, maximum=1, limitReached=false, OutcomeUnknown=false

전 과정에서 Oracle/MariaDB는 2/2 정상이고 COM/KTAPConnect는 호출되지 않았다. NEXT와 DB write도 실행하지 않았다. preliminary DryRun에서 현재 시점의 1열판기본_예상체결가는 DB row-count precondition이 맞지 않아 SCENE_DATA_INVALID로 명확히 거부됐다. native 상태는 IDLE이었고 KTAP 호출은 없었다. 이 컷은 이번 1.0.5 성공 범위로 계산하지 않으며 별도 데이터 시점 검증이 필요하다.

로컬 증거 해시는 다음과 같다. 파일은 운영 정보 보존 정책에 따라 Git에 넣지 않는다.

증거 SHA-256
초기 native/package 상태 154A87ACA8D46132CE06538013BC0DA4E08AB27FE6D92B38F42E3B881EE262EE
삼성전자·현재가 5001 구성 73064F13D4ECF89DF6549FEA348AA350CB13011A10BE47C34A7BC9DC4168E60A
PREPARED 5001/page 1 1DA53B5E9E33D8CE820BBDA87D6B8E0897ACAED6DE28F73AD0599EDC42F45C5B
TAKE IN 단일 발행 B35D9E664983E7D232952EF699A0C9D0D12A8CE3D604DACA6E847E1B4BA9D74C
CAPPED 1/1 및 3.5초 안정성 1C34FF5780F8F75E52C02C064D776D7E6E8321116C448E13805C77565D8D6547
CAPPED 화면 35F7D7BA67417C4595D5F6F2306CC5EC4BEE0EAEA719D5165CA59BFEC7BAAD70
TAKE OUT 단일 발행 BC6186648FB09B1C4A4210D5853AF3FE39E0A2FE2C68E6EE8A0629FCAF500648
최종 IDLE 5F5C16853048BD269A29BA9BA045CF6BC47C88623ADFA4548FC99A8947E3DFB5

검증 뒤 ContentDialog의 종료를 명시적으로 눌러 정상 종료했고 앱 프로세스와 CDP listener가 모두 0임을 확인했다. 임시 playout local config를 삭제했으며 process/user/machine 범위 MBN_STOCK_PLAYOUT_*도 모두 0이다. 1.0.5 signed 설치본은 Status=Ok로 유지한다.

Round I 실패 증거와 다음 회차

Round I의 결과는 계속 FAIL이다. 로컬 증거는 artifacts\pgm-evidence\MBNWEB-20260712-I\round-result.json, SHA-256은 E5FD13E7FCDF87B6ADCFB696EFF2E957B70ECA821A424FC15EE41043CFA0E37E다. 적용했던 Live 설정의 SHA-256은 BE282B9AF0AC5D8C243234D70587497ADACC7A47ED85C1865ED595949FC8759F다. Round I 계획에는 자동 refresh 1회가 허용됐지만 일부 예상 native range가 이를 반영하지 못한 불일치도 있었다. 새 회차는 cumulative PREPARE 3회와 PLAY/ OnScenePlayed 2회를 명시하고, 새 package hash와 cap=1 설정 hash를 함께 고정해야 한다.

1.0.5 DryRun 통과는 실제 Tornado callback/PGM 검증을 대신하지 않는다. 새 계획 SHA-256에 대한 Gate A 승인 전에는 CONNECT/PREPARE를 보내지 않고, 같은 회차의 Gate B 승인 전에는 TAKE IN을 보내지 않는다. 결과 불명확 상태에서는 어떤 명령도 반복하지 않는다.