# Runtime Lifecycle Status: `R5 ICERTI DEPLOYED · WEB VIDEO ISSUE DEFERRED · EVPIN-01 VERIFIED · EVDEC-01 OPEN` Owner: `(test, ltb1021, work-session)` on `task/runtime-lifecycle-refactor` Last reviewed: `2026-11-01 10:27:49 KST`. ## 서버 호칭 2026-10-21 사용자 지정. 아래 이름은 같은 물리 AI 서버를 가리키는 호칭이며 설치 ID는 변경하지 않는다. | 현재 호칭 | 대상과 과거 표기 | | --- | --- | | 청계산 서버 / 청계산 AI 서버 / 현장 AI 서버 | 청계산 현장 설치 AI 서버. 과거 아이서티 AI 서버1 | | test 서버 | 스마트인사이드AI 회사의 개발 AI 서버이자 현재 Codex 작업 서버. 대응 Web은 101 서버 | | 아이서티 AI 서버 / 아이서티 테스트용 AI 서버 | 아이서티 회사 내부 테스트 AI 서버. 과거 아이서티 AI 서버2 / AI2 | 현장 Web·미디어 서버는 별도 대상이다. 과거 evidence의 AI2, machine ID, 경로는 일괄 개명하지 않는다. ## 세 서버 배포 기준과 ct Start 복구 [서버별 배포 차이·10/30 Start 차단 복구·후속 순서](analysis/20261030T145136+0900-analysis-three-server-baselines-ct-start-recovery.md). test의 빌드 경로 2항목과 ct 입력 기준을 정합화한 결과는 10/30 14:20 당시 확인값이며 현재 Runtime 재조회가 아니다. 세 서버의 source/image/transaction/ct와 다중 ROI 지원·운영 모드를 구분한다. 11/3 시연 이후 아이서티 변경의 test 수동 패치 시험과 다중 ROI 연계 검증을 거쳐 청계산 후보를 정한다. 기록 작성 당시 보류한 Owner 링크는 이번에 반영했다. ct 기능 개선·현장용 HTML·최종 오프라인 패키지는 계속 보류하며 기존 분석 기록 본문은 당시 상태로 보존한다. ## 쓰러짐·싸움 촬영 준비 [36개 촬영 사례·기대 결과·후속 영상 준비 계약](analysis/20261027T174110+0900-analysis-fall-fight-filming-plan.md). 자체촬영 원본01은 [사용자 관찰·인물 보정·Event 기대](analysis/20261029T125858+0900-analysis-self-filming-original01-user-observations.md), [클립 제작](run/20261029T133206+0900-run-self-filming-original01-clips.md), Pose cache 준비 완료 문맥을 수신했다. 현재 메인 상태는 [아이서티 R5 기본 적용 완료·Web 표시 문제 별도 보류](run/20261101T102749+0900-run-icerti-r5-deployment.md)다. 사용자는 [12입력 검토](run/20261030T215846+0900-run-r5-space-review.md)를 샘플 기반 시연 후보로 수용했고 source 통합 후 현장 반영을 승인했다. 기존 후보·영상·cache는 보존했다. 라이브 일반화나 Web 수용 완료로 확대하지 않는다. | 자료 | 준비 규모 | 진입점·현재 상태 | | --- | --- | --- | | 기존15입력 | Pose cache15개·B 진단45본 | [입력 기록](run/20261028T141320+0900-run-pose-input-review-15clips.md), [B 진단 기록](run/20261029T155214+0900-run-b-diagnostic-review.md); 피드백 수신 후 B 개선 비교 완료 | | 자체촬영 C01~C22 | 22클립·7,060관측 | [cache 기록](run/20261029T141954+0900-run-self-filming-pose-cache.md); [R5 통합 재현 검증](run/20261031T103126+0900-run-fight-r5-runtime-integration.md) | | 자체촬영 L01 / 후속 L02 | L01 영상1개·cache2파트·8,305관측; L02는P02의7,261관측 | [두 파트 기록](run/20261029T151658+0900-run-self-filming-l01-pose-cache.md); L01 기존 결과 보존. [L02 R5 검토 영상](run/20261030T215846+0900-run-r5-space-review.md) 제작 완료, 별도 무표시 물리 클립은 미생성 | 자체촬영 최신 진입점: [읽기용 안내](/data/codex-artifacts/contextra/action-model-eval/2026/2026-10-29_contextra-self-filming-l01-pose-cache_r01/00_README_ko.md), [통합 catalog](/data/codex-artifacts/contextra/action-model-eval/2026/2026-10-29_contextra-self-filming-l01-pose-cache_r01/metadata/catalog.json), [실제 보관 경로](/data/codex-artifacts/contextra/action-model-eval/2026/2026-10-29_contextra-self-filming-l01-pose-cache_r01/metadata/locations.json). 자료 준비 완료 상태는 이 catalog를 기준으로 읽는다. 이전 기록/catalog의 L01 보류는 historical로 보존한다. 앞선 진입점 정리는 문서·목록 대조였으며 과거 cache/영상 검증을 재수행한 결과가 아니다. 이후 B 개선 시험 근거는 위 최신 실행 기록을 따른다. 후속 재사용 시 주의사항: - 사용자 a/b와 실제 T/q는 별개다. 대략적 anchor는 정확한 Event GT가 아니다. 과거 자료의 높은 우선도는 자동으로 필수 수용 기준으로 승격하지 않는다. 새 D/N 구간에 명시하는 상/중/하는 위 최신 합의를 따르며 설명과 cache를 억지로 맞추지 않는다. - 자체촬영 전체 쓰러짐 비감지는 사용자 참고 전제다. 최신 사용자 합의상 C22 전체는 싸움 비감지 희망이며, 원문 O20/C22의 판단 대기는 당시 historical 상태로 보존한다. 나머지 상세 기대·예외는 관찰 원문과 최신 피드백 대응표를 따른다. - 클립·검토본·원본 번호는 대응표로 연결한다. 관찰 본문과 앞뒤 context를 구분하고, 한 클립의 여러 행동을 단일 정답으로 축약하거나 중첩 Cxx/L01을 독립 사례로 중복 집계하지 않는다. - L01은 실제 PTS와 `(part_id, T ID)`를 유지한다. `sample/10` 시간 대체, 두 cache 단순 연결, 경계를 가로지르는 연속 행동 입력은 하지 않는다. - bbox/관절은 원시 score를 사용한다. `valid_joints`는 기존 관절0.3 집계이므로 현재0.10 기준으로 그대로 쓰지 않는다. - 자체촬영 RGB는 원격 보관이며 실제 경로는 catalog/locations를 따른다. L01은 이번 승인으로 파트별 독립 엔진/episode/표시 상태를 사용한다. 경계 초기화는 자료 단절 처리이지 실제 Event 종료가 아니며, 관측 공백은 중립 안내로 표시한다. 운영 경계 정책으로 자동 적용하지 않는다. ## R5 Runtime 통합 2026-11-01: [실제 배포·검증·복귀 기록](run/20261101T102749+0900-run-icerti-r5-deployment.md). 현장 Analytics를 source-only image54ce2980ed2b로 교체하고 기존28채널·신규Web template을 R5로 전환했다.73검사·27subtest, source15파일·실효 설정·기존4모델READY 확인. 다른4서비스 identity와 모델/인증/volume을 보존하고 Gateway를 복구했으며 Codex 카메라 Start0·자동rollback0이다. 사용자는 영상 표시 문제를 보고하고 이번에는 조사하지 말고 마무리하도록 요청했다. R5는 유지하고 Web 표시·실제 알람/미디어 수용은 미확인/후속 보류다. 반영 시 camera24의 높은 관절 기준0.30은 보존했다. 기존 ERROR6의 초기화는 원인 해결로 해석하지 않는다. 2026-11-01 배포 전 추가 요청: [6채널 ERROR 사례·Web 전달사항](analysis/20261101T101310+0900-analysis-icerti-six-channel-errors.md). 운영 정지/리셋 전에 원격 제한 원본과 마스킹 공유본을 분리 보존했다.23/24/29 RTSP 서버 연결 종료,26/27 EOS 종료 주체 미확정,22 CROWD provider 정체를 구분했다. 최초 Start6건은 HTTP200이며 최종 원인 귀속·재발 방지 수정은 별도다. 근거 보존·bounded 분석 후 R5 배포를 재개하며 장애 조건은 임의 변경하지 않는다. 2026-11-01: [전체 R5 기본 적용·Web 무패치 배포 합의](decision/20261101T094844+0900-decision-r5-site-default-and-demo-deployment.md), [재사용 절차](../../../../deployment/SCENARIO_DEMO_COMPATIBILITY.ko.md). 사용자는 camera24 한정 대신 아이서티 전체 기존/신규 채널의 FIGHT 기본 R5를 요청했다. 합의 당시 미적용이었고 이후 위 배포에서 site 저장 설정/template으로 반영했다. 공용 source의 채널별 선택/미지정 legacy는 타 설치본 보호를 위해 유지한다. Web On/Off·ROI·cooldown과 반복 Start를 보존하고, 모든 채널 강제 Start/FIGHT On으로 해석하지 않는다. 필요한 컨테이너 교체·일시 중단과 실제 Event/미디어/Web 시험은 후속 적용 범위에 포함한다. AI 작업은 Codex, 브라우저 조작·수용은 사용자이며 자동 rollback/재Start는 하지 않는다. 쓰러짐에는 절차만 재사용하고 엔진/조건은 별도 검토한다. 이번에는 문서 기록만 수행했다. 2026-10-31: [결정 R5-CONFIG/RUNTIME/DISPLAY-01](decision/20261031T103126+0900-decision-fight-r5-runtime-contract.md), [구현·검증·배포/복귀 준비](run/20261031T103126+0900-run-fight-r5-runtime-integration.md), [Web 설정 명세](../../../../integration/FIGHT_R5_WEB_CONFIG.ko.md). 기본 legacy를 보존하고 AI 소유 R5 선택·구형 동작 설정 무시·score 하한·버전1 설정·실시간 빨강1초 유지를 연결했다.32입력18,045관측과12상세 진단 재현,18표적검사·73파일SHA256 PASS. 선택 계약 suite199 PASS/기존 HEAD에도 있는 실패5개이며 전체 suite PASS는 아니다. 운영 변경·실제 Event 전송0, 시험 자원 회수. 현장 소스 세대 차이로 배포 묶음 확인과 대상/중단/복귀 승인이 먼저 필요하다. 기존 Web 소비·알람/미디어·라이브10FPS는 별도 확인 대기이며, 샘플 수용을 운영 수용으로 승격하지 않는다. ## 싸움 엔진 A/B 격리 비교 2026-10-30: [고정 R5 공간색12영상](run/20261030T215846+0900-run-r5-space-review.md). 과거 R5 집계·변경 위치 재현,12본 전체 디코딩·Frame/PTS·117파일SHA256 PASS. 전체 Event 시각을 새로 보존해 C12와L02의 시점 이동을 개수 변화와 구분했다. 운영 변경 없이 사용자 시각 검토 대기다. 2026-10-30: [첫 접근·후속 연결 후보1개32입력 비교](run/20261030T203049+0900-run-fight-approach-link-comparison.md). 동일 상대 부위의 실제 접근과 후속 회수를 확인하는 후보를 고정 비교했다. 감지 희망31입력226→198/L02 58→54, 지정 비감지 Cxx10→7/L02 14→10으로 R4/R5보다 주요 집계가 불리하다. 새 비감지 빨강0이지만 C11 감지 희망 Event 소실과 L02 비감지 Event 시점 이동이 있어 교체 채택을 권하지 않는 상태다. 30합성검사·32입력18,045관측 원시 감사·76파일SHA256 PASS. 수치 탐색 없이 중단했으며 기준/R4/R5 재실행·영상/모델 추론·운영 변경은 없다. 다음은 사용자 비교 기록 검토다. 2026-10-30: [R4 제한적 억제32입력 비교·제작 보류](run/20261030T174436+0900-run-fight-robust-comparison.md). 기존31입력+L02의18,045관측을 저장 특징으로만 CPU 비교했다. R4는 지정 Cxx 비감지10→2이나 감지 희망226→214(12개 감소), L02는 지정 비감지14→7·감지 희망58→56이다. 중첩 자료를 독립 사례로 합산하지 않는다. 새 빨간 관측0,19합성검사·L02대응·기준 지문/전송 검증 PASS. C10 5→3/C12 8→6 등의 절충과 잔여 L02 오판을 보고했고 사용자는 **32영상 제작 보류·비교 기록만 정리**를 선택했다. 영상0본·R4 미채택이며 기존 기준 엔진과 운영 상태를 변경하지 않았다. 후속 검토 후보 (`2026-10-30`, 사용자 기록 요청): - `FIGHT-SIZE-01 · DEFERRED / LOW`: `06_KISA_fight_C00_008_0005`의 작은 객체 대응을 위해 bbox 높이(px), 영상 높이 대비 비율과 관절 관측 품질에 따른 규칙/파라미터 구분을 후속 검토한다. 현재 합격점과 낮은 우선순위를 유지하며 크기 경계값·별도 규칙은 미확정이다. - 기존 거리/동작량의 bbox 크기 정규화와 별개인 후보다. 입력 부족을 거리 완화로 해결했다고 보지 않으며, 두 사람의 유효 입력이 있는 구간에서 공간 조건 탈락과 동작 근거 부족을 먼저 구분한다. bbox0.25·관절0.10 기준은 유지한다. - 재검토 시 작은 보행자 등 비싸움 사례의 신규 발동과 기존 감지 희망 구간의 손실, 크기 경계에서 조건 전환이 흔들리는지를 함께 비교한다. 영상별 맞춤값이나 단순한 작은 객체 제외/완화를 기본안으로 삼지 않는다. 현재 통합 후보 변경·추가 시험·운영 적용 승인이 아니다. 2026-10-30: [고정 후보 공간 검토28본·L01](run/20261030T143608+0900-run-fight-space-review.md) 완료. 28판정 byte-identical,7표적 검사,29본19,426영상 Frame(실관측19,425+공백1) 디코딩·PTS·270파일 전송SHA256 PASS. 운영 제어/GPU 작업0, 시험 컨테이너 회수. 사용자는01/07/08/C09/C14 개선을 긍정 평가했고,02/03/14/C13 최종 조건0을 확인한 뒤 후보 유지에 동의했다. C09 Frame545~690/C14 Frame720~1005는 보완 검토 구간일 뿐 이번에 규칙을 변경하지 않는다. 이전11:40경 운영 중단은 아이서티의 VRAM 사용을 위한 의도된 작업이라는 사용자 설명을 수신했다. 시험에 직접 영향이 없으면 추가 조사하지 않으며 과거 snapshot은 보존한다. 2026-10-30: [B 통합 후보1개·37입력 진단·9검토본](run/20261030T121303+0900-run-fight-integrated-review.md). 손팔/발다리/근접 반전과 상대 몸통 반응을 분리하고 관계별 억제·중복 관측 제거를 적용했다. 표시/계산 bbox0.25·관절0.10, 노랑1초와 그룹별 기여 색을 반영했다. 26표적검사·37입력14,984관측 감사·9본3,864Frame 디코딩·전송SHA256 검증 완료.02/03/14/C13 현재 조건0,07은33→80이나08은21→18(B2 대비)이며01 감지 부족은 남는다. 사용자 수용·정오탐 확정은 아니다. 본 시험 운영 제어0·GPU0·시험 컨테이너 회수. 당시 개발용3개→Contextra5개 및 GPU PID 변경을 관측했고, 이후 위 사용자 설명을 수신했다. 과거 실행 snapshot은 보존하며 운영 무영향·10FPS를 검증했다고 표현하지 않는다. 2026-10-30: [B1/B2 전체 인상·D/N22키워드·후속 설계 경계](analysis/20261030T105510+0900-analysis-fight-feedback-and-action-keywords.md) 기록. 사용자 평가는 B2 정탐07/08 우세, B1 오신호 억제03/14 우세,01/C09/C14 양쪽 감지 부족,02 양쪽 억제 부족이다. C13은 B2가 더 좋고 B1 하이파이브 오신호가 관찰됐다. 정확한 Frame과 새 우선순위는 아직 미지정이다. [표시 합의](guides/action-review-visualization.ko.md#b-규칙-진단의-다음-표시-합의)는 후속 승인으로 위 통합 후보9본에 적용했다. 이전 B1/B2 영상은0.4초 그대로다. 이 analysis는 당시 협의 대기 snapshot이며, 확정·구현 범위와 시험값은 위 최신 실행 기록이 소유한다. 2026-10-29: [B 개선 prototype·37입력 비교·대표9입력18본](run/20261029T202629+0900-run-fight-b-refinement.md). 공간 후보 최대1초와 실제 동작 근거를 분리하고 B1 직접 근거/B2 같은 관절 후속 근거를 비교했다. 기존 B revision1과 운영 코드는 보존했다. 27표적검사·37입력 시간/조건 감사·18본7,728Frame 디코딩·392파일 전송SHA256 PASS. 조건 충족은 표시 유지와 구분한다. 02/03/14 조건 충족은 기존139에서3/20으로 줄었지만01도32에서1/7로 줄었다. 두 안 모두 충분한 개선으로 채택하지 않았으며 사용자 검토 대기다. 이번 착수 시 운영은 과거5개 Contextra 대신3개 rtsp-ai dev 컨테이너였다. 현재 전후 컨테이너/GPU 프로세스 집합 유지·운영 제어0·시험 자원 회수이며 실제 FPS/Event 품질은 미측정이다. 2026-10-29: [B 공간 그룹·동작 근거·연결 차이15입력/45검토본](run/20261029T155214+0900-run-b-diagnostic-review.md). 기존 cache와 B revision1을 유지한 CPU 진단이다. 그룹은 표시 전용이며 새 그룹 기반 엔진이 아니다. bbox0.25/관절0.10 표시·계산 기준을 일치시켰다. 기존6입력 B 결과 정확히 일치,38합성검사·15독립감사·45본 전체 디코딩·365파일 전송SHA256 PASS. 사용자 시각 검토 대기다. 운영 제어 없이 시험 자원 회수. 작업 중 camera27 run 및 runtime 설정 지문 변화는 관측했으나 주체/원인은 미확인이다. 저장 영상 변경으로 해석하지 않는다. 2026-10-28: [기존 Pose cache 기반6입력·A/B12검토본](run/20261028T181830+0900-run-fight-ab-review.md). A는ID쌍/쌍별episode, B는짧은공간대응/ROI episode의 시험 prototype이다. 공통 몸통상대 팔 움직임·타격/접촉 규칙을 적용했으며 운영코드 대체물이 아니다. 기존2353표시관측·2440처리관측으로12본/4706Frame,20합성검사·원시조건/Frame/PTS 감사·전송125파일SHA256 PASS. 재추론/Tracking/운영 변경 없음. 군중 입력에도 규칙 충족이 기록됐다. B의표시구간 새Event0건은 선행episode를 포함하므로 무검출/오탐 억제로 해석하지 않는다. 사용자 시각 검토·채택 판단 대기다. 운영5컨테이너·설정/모델·6running/22stopped 유지, CPU 시험 자원 회수. 자체촬영 자료는 전달문 수신 전이며 이번 입력에 추가하지 않았다. ## 기존 엔진 개선용 입력 검토 2026-10-28: [06·14 bbox/관절 score 비교2본](run/20261028T155935+0900-run-pose-score-compare.md). 기존 cache만 재사용해 bbox0.25/0.20·관절0.10/0.05를 초록/빨강으로 비교한다. 2본/1170Frame·원시 조건 독립 감사·전송33파일SHA256 PASS. bbox0.25는 기준,0.20은 비교 후보이며0.15 이하는 추천에서 제외한다. 관절0.10 중심·0.05~0.10 참고 구간은 아직 운영 설정이 아니다. 05·10은 입력 한계 사례로 보존하고14의 전원 확보는 약속하지 않는다. 낮은 score 단독 판정 금지·규칙별 필요한 관절 활용은 후속 엔진 설계 합의로만 남긴다. 운영5컨테이너·설정/모델·6running/22stopped와 run/child 유지, CPU 시험 자원 회수. 재추론·Tracking/엔진 변경 없이 사용자 검토 대기다. 2026-10-28: [Pose 입력 품질15검토본](run/20261028T141320+0900-run-pose-input-review-15clips.md). 등록 카메라4개와KISA11개를 목록화하고, 기존11cache 재사용·신규4개2100관측 추출 후15본/7924Frame을 검증했다. bbox0.5/0.25·관절0.3/0.05는 표시용 기준이며 객체 링/실제T·미추적q·중점/보조관절 상태를 구분한다. 원본Frame/PTS·표본RGB·독립 조건 감사·전송185파일SHA256 PASS. 운영 설정/모델/5컨테이너 유지, 시험 자원 회수. 착수 때 정리 대기였던camera22의stopped 전환을 관측했고 기존error3개는 유지됐다. 채널 제어·원인 확정·자동 복구는 하지 않았다. 사용자 검토 후 입력 기준을 정하고 기존ID쌍/ROI 판정 후보를 비교할 계획이며 이번에는 엔진 개발·행동 모델·Web Event 호출을 하지 않았다. 사용자 평가상4행동 인식 모델의 시연 적용은 보류다. 아래 비교 기록은 당시 evidence로 보존한다. ## 행동 인식 후보 비교 2026-10-27: [PoseC3D 비싸움 비교4입력·8검토본](run/20261027T171715+0900-run-posec3d-nonfight-review.md). 사용자가 싸움이 없다고 확인한 군중22·쓰러짐27·화재29·추가KISA에 기존 기본값 ge2/ge3을 적용했다. 동일 Pose/Tracking·PoseC3D의 격리 추론 후1,123표시 관측/1,108유효 점수,8본/2,246Frame과 전송95파일SHA256 검증 PASS. 운영 설정/run/child·5컨테이너 유지, 시험 자원 회수. 조건 충족률은 운영 오알람률이 아니며 사용자 검토 대기다. camera27은 이번 승인된 싸움 후보의 비싸움 비교에만 사용했다. 쓰러짐 판정 개발·AVA/YOWOv2 운영 적용은 계속 보류한다. 아래 과거 기록의 camera27 시험 보류는 해당 시점의 상태로 보존한다. 2026-10-27: [PoseC3D 주4개 조건 비교7입력·21검토본](run/20261027T161159+0900-run-posec3d-filter-review.md). 기존16관측 결과로 개별 신호3단계와 기본값 충족2종류 이상/3종류 이상을 비교한다. 원시값 독립 감사·14,103Frame/PTS·글자경계·전송199파일SHA256 PASS, 운영 전후 상태 유지. 모델 재추론·특정 사람 판정·운영 적용 없이 사용자 검토 대기이며, 시험 조건은 운영 싸움 규칙이 아니다. 2026-10-27: [PoseC3D 주4개 점수 분포·threshold 후보](analysis/20261027T151913+0900-analysis-posec3d-score-distribution.md). 짧은16관측 원시 결과7입력의4,701관측 중4,316유효값을 로컬 CPU로 분석했다. 클래스별 통계·최빈구간/폭 민감도·공통 P25/P50/P75 및 Top5 병용 통과율을 검증했다. 51번의 P50/P75는 후속 검토 후보일 뿐이며 정확도·싸움 판정 기준은 아니다. 재추론·영상 분석·운영 적용 없음. 사용자 평가상 YOWOv2도11/3 운영 적용은 보류하며, AVA 및 camera27 시험 보류를 유지한다. 2026-10-27: [군중22·배회23·침입26·화재29 기준 영상](run/20261027T145048+0900-run-four-scenario-recording-review.md). 각120초 순차 녹화·번호본·대응표4세트와 설정 요약을 준비했다. Frame/PTS·전송hash·운영 보존 확인 완료, [4채널 사용자 관찰 수신](analysis/20261027T155312+0900-analysis-four-scenario-user-observations.md): **관찰 수신·후속 시험 조건 협의 대기**. 인원 추정·참고 변화Frame은 정확한 정답 수치나 Event 발생 의무 시점이 아니다. 시험 조건은 미정이며 새 시험을 시작하지 않았다. 2026-10-27: [YOWOv2 A/B 필터7입력·7검토본](run/20261027T142312+0900-run-yowo-ab-filter-review.md). 같은 객체/관측의 주 후보 A/B 조건을 주황·빨강·초록으로 표시하고, 모든 통과bbox와 원시순서 첫3개 상세를 제공한다. 추가 페이지 없이 생략 수·원시 근거를 보존했다. 모델 재추론/운영 변경 없이 기술 검증 완료, 사용자 평가 대기다. AVA는 후속 사용자 평가상 보류이며 작은 객체 변별력 저하 관찰을 원인 확정으로 취급하지 않는다. camera27 시험은 보류한다. 2026-10-27: [AVA 표시 필터7입력·9검토본](run/20261027T134703+0900-run-ava-filter-review.md), [검토 영상 표시 가이드](guides/action-review-visualization.ko.md). 사용자는 camera24 AVA의 추가 필터 검토 가치를 확인했고, 합의한 fight/주/보조 조건을7입력에 표시용으로 적용했다. 원시 결과 재사용·고정 가로형/3객체 상세 페이지·기술 검증 완료. 재추론·운영 변경·성능 판정 없이 사용자 검토 대기다. 시험 threshold는 다른 모델·영상·camera27 쓰러짐에 자동 적용하지 않는다. 2026-10-27: [짧은 입력 7클립·56검토본 비교](run/20261027T125652+0900-run-action-short-7clips.md). camera24 cache와 추가6개 공통10FPS 입력으로 짧은 입력/근접 쌍 조건을 적용했다. 28모델·클립 단위와56영상 기술 검증 완료, 운영 설정/run/child 유지. 사용자 성능 판단은 대기 중이다. 기존4후보 사용자 평가는 모두 보류이며 이번 결과로 채택·정확도 개선을 확정하지 않는다. 2026-10-27: [camera27 쓰러짐 입력 2분 기준 영상](run/20261027T113133+0900-run-camera27-recording-review.md), [녹화·Frame 검토본 재사용 가이드](guides/recording-review.ko.md). 2,882Frame 원본/번호본·PTS 대응·전송hash를 확인했다. 운영 변경·모델/영상 의미 분석은 하지 않았다. [사용자 관찰 수신](analysis/20261027T125115+0900-analysis-camera27-fall-observation.md): 반복362~722/723~1083, 461·476·513 전후는 대략적 행동 경계다. 후속 모델 시험 조건 협의 대기이며 정확한 정답 시점이 아니다. 2026-10-27: [4후보 전체 클래스·사용자 신호 후보](analysis/20261027T104348+0900-analysis-action-class-candidates.md). 이번 checkpoint의 NTU60/AVA80 번호 대응과 미검증 주·보조 후보를 한 곳에 정리했다. 실제 싸움 판정 규칙은 아니다. 2026-10-27: [camera24 10FPS Tracking/skeleton 검토](run/20261027T103700+0900-run-tracking-skeleton-review.md). 기존 cache301관측(원본1~722/0.000~29.998초)으로 전체+확대·T ID·회색 미추적(q) 영상1개를 생성했다. 추론/Tracking 재실행 없이 CPU 렌더링,301Frame/PTS/전송hash/관측상태 검증과 표본 화면 확인을 완료했다. 운영 config/run/child는 유지했고 실제 동일인·ID 전환 평가는 사용자 검토 대기다. 사용자 평가상 ST-GCN++·AVA·PoseC3D는 보류, YOWOv2 피드백 대기. 과거 비교 evidence는 그대로 보존한다. 2026-10-26: [camera24 실제 녹화 4후보 비교](run/20261026T210248+0900-run-action-model-eval.md). 사용자 지정 반복242~482/483~723을 기준으로 공통10FPS 관측·모델별 Top5 검토 영상4개를 생성했다. 기존 Pose engine은 별도 시험 Triton에서 읽었고 운영 추론queue·채널·설정은 변경하지 않았다. ST-GCN++는 ID 관측 누락, AVA는 native ROI 수치 동등성 미검증을 명시했다. 정확도·채택은 사용자 검토 대기다. 최종 검토본·원시 결과·전체 클래스·Frame 대응은 새 eval run에 보존한다. 아래 준비 기록은 historical이다. 2026-10-26: [4후보 격리 준비·camera24 기준 영상](run/20261026T173515+0900-run-action-model-prep.md). 실제 등록 대조 후 사용자 승인으로 camera23에서 camera24로 변경했다. 약180초/4,322 Frame의 원본·번호 영상·PTS 대응표를 확보했다. ST-GCN++/PoseC3D/AVA SlowOnly/YOWOv2는 strict weight load와 합성 입력 GPU smoke를 통과했으며 AVA는 별도 ROI 호환 경로의 제한을 기록했다. 운영5서비스·6 running/22 stopped와 기존 run/config를 보존했다. 실제 영상 비교는 사용자 구간 지정 후 진행한다. 시험 image는 `contextra-action-eval:20261026-camera24-r03`; test Runtime·101·청계산은 변경하지 않았다. ## AI-Web 진단 기록 구현 2026-10-23: [EVPIN-01 Event 압축구간 보호](decision/20261023T161515+0900-decision-event-pin.md). 일반 FIFO와 Event별 보호 구간을 분리하고 유한 메모리/시간 상한을 적용한다. [아이서티 반영·비교 결과](validation/20261023T162601+0900-validation-event-pin.md): 각86 Event의 keyframe 실패25→0, 후보86 READY/SENT. 6채널 약10FPS 유지, CPU12.17→15.11%. APP671c7416f503·5서비스 정상·Web 자연 재유입6채널running. test Runtime·다중 ROI 설치는 변경하지 않았다. 브라우저/장시간/복합 고부하 수용과 EVDEC-01은 별도다. 재기동·자연부하 차이를 포함한 짧은 비교다. 2026-10-21: [Artifact 마무리·순환 보관·단독 fallback 개선](decision/20261021T164205+0900-decision-artifact-finalization.md) [구현·검증·양 서버 배포와 복구](validation/20261021T171120+0900-validation-artifact-lifecycle.md) 완료. 완료/예약/점유 원자성·유한 재시도·95% 선제 정리·단독 provider fallback 운반을 반영했다. test APP74c0e6fed106/36채널stopped, 아이서티 APPe5756f7bef49/Web 자연 재유입10채널running. 네 모델READY·Gateway복구·완료 마무리 대기0 확인. 자연180초에서179Event 중154 READY/SENT, 20 keyframe 실패/SENT,5진행 중이었다. 브라우저 수용·keyframe/EVDEC 문제 해결은 별도다. 2026-10-21: [TRACE-01~04 계약과 사용 안내](../../../../deployment/CT_TRACE.ko.md). test 구현·설치·표적 검증 완료. [검증과 재개점](validation/20261021-validation-ct-trace.md). [아이서티 TRACE 재배포·최소 수용](validation/20261021T144850+0900-validation-icerti-trace-redeploy.md) 완료: Event claim 복구 image를 기준으로 TRACE만 반영했고 legacy·인증·기존 정책을 보존했다. 5서비스 running, 자연 Web 복구 10채널 running/11 stopped/error0. 30.4초 표본 82행 증가, Event HTTP200 27건, APP/Sidecar queue0·누락0·오류 없음. 브라우저·정량 FPS 수용은 별도다. [이전 APP 복구·TRACE 보류 기록](validation/20261021T142123+0900-validation-icerti-trace-recovery.md)은 과거 상태다. 이번 정상 복귀 기준은 수정 전 image가 아닌 baa2c2f49593 복구 image다. [test 사용자 수동시험·후속 진단 보완](validation/20261021T124347+0900-validation-trace-manual-and-aliases.md): camera3 Start/실시간 표시/Event 알림/아티팩트 확인/Stop은 사용자 관측으로 수용했다. 공유된 진단 출력은 오류 없음·대기열0·Event HTTP200이다. [명령 완료 기록 보완·test 설치](validation/20261021T131823+0900-validation-trace-completion.md) 완료: 양 모드 runId/상태 읽기·실패/취소/미확인 구분, nonblocking 상태 관측, 관련17검사 통과. APP만 image751d2b859bef로 교체, legacy 유지·5서비스 running·36채널 stopped 확인. 사용자 Stop 완료 뒤 전환했으며 에이전트 카메라 Start/Stop은 없다. 정량 FPS·실 multi_roi 수용은 보류다. ## 청계산 설치·저장 구조 안내 (기존 기록) [배포 기록 대조·경로 계약·문서 검증](analysis/20261014T164652+0900-analysis-cheonggyesan-storage-guide.md). 문서4를 상세 오프라인 HTML로 정리했다. 실제 저장·통합 조회·container 경로와 설치/Docker/DB, Event·학습 보관 정책을 구분하며 기준은 09-27~28 배포 기록이다. 현장 접속·Runtime 변경 없음. 사용자 검토 대기이며 문서3의 Artifact 시각화 누락 조사는 계속 보류한다. ## 쓰러짐 오탐 3사례 문서화 [관찰·코드 근거·고도화 후보와 보류 조건](analysis/20261014T162501+0900-analysis-fall-false-positive-review.md). 2026-10-14 사용자 현장 관찰을 보고용 HTML과 내부 Markdown으로 분리했다. 같은 Frame 안에서 기존 판정에 근거를 통합하는 방향이며, 화면 잘림 추가 강화와 새 시간 관측은 기본 적용에서 제외한다. 구체 조건·수치는 미정이고 구현·Runtime·현장 시험은 하지 않았다. 보고서 초안 사용자 검토 대기이며, 아래 운영 상태 기록은 이번 작업에서 재확인한 것이 아니다. ## test Event 시간 fallback 반영 [설치·보존·준비 검증](validation/20261013T173700+0900-validation-test-event-time-fallback.md). 구현 d28a00d의 Python5파일만 기존 test APP 위에 반영했다. image2cdec3ea4d14, transaction `event-time-fallback-20261013-r01`. 실제 조회된 mode=legacy·ROI8/rule48/예약0은 변경하지 않았으며 다중 ROI 코드와 API도 보존했다. 아래16:14의 multi_roi 운영 관측은 과거 기록이다. 개발 표적32건·후보 image22건 통과(중복 포함), 네 모델/API/인증/Gateway 준비 확인. 전환 전7채널을 정상 회수했고, Gateway 복구 후 외부 Start는 허용한다. 에이전트 시험 Start는 없다. 브라우저·새 Event 실수용과 기존 EVDEC-01 해결은 이번 범위 밖이다. ## 다중 ROI 2채널 실입력과 디코더 재발 [2채널 격리 시험·샘플·미확인](validation/20261013T161400+0900-validation-multi-roi-dual-acceptance.md). 설치 APP image4f660ae3b484로 동시 실입력1회,6시나리오 Event 생성·같은 run 재사용·잘못된 참조 거절·Stop 회수, 추가 CPU mock15건을 확인했다. 실제 영상 대표10개와 동일 프레임 비교를 보존했다. 실시간 브라우저/최종 Web 스키마/정확도는 미수용이며 시험 수신기의 최초 HTTP 전달 실패도 구분한다. `EVDEC-01 · Event 클립 디코더 중단`은9월23일과 같은 libav assertion 재발이다. [별도 문제 기록·재개 기준](analysis/20261013T161400+0900-analysis-event-decoder-abort.md). 실패 캐시 단독 재생성은 성공했지만 원인 수정은 아니다. 영상 검토와 decoder 해결은 별도다. 사용자가 전환한 운영 mode=multi_roi·ROI8/rule48/예약0을 보존했고, 운영5서비스 running/36채널 stopped, 시험4서비스 exited0을 최종 확인했다. 운영 image/config와 아래 AI2 시간 패치는 변경하지 않았다. ## AI2 Event 시간 긴급 패치 2026-10-13 15:53:23 KST: EVTIME-01 구현·현장 baseline 한정 배포 완료. [시각 계약 결정](decision/20261013T155323+0900-decision-event-time-fallback.md), [검증·배포·복귀 근거](validation/20261013T155323+0900-validation-ai2-event-time-fallback.md). APP Python5파일만 변경했고 다중 ROI/API 후속 변경은 현장에 배포하지 않았다. 네 모델/API/인증 준비·기존 BLOCKED_TIME19,994행 hash 보존 확인. 실제 Web 수용은 사용자 확인 대기다. Gateway 복구 후 외부 camera3 Start 재유입은 사용자 최신 승인에 따라 허용한다. 에이전트 시험 Start는 없다. 아래 test 다중 ROI 설치·자동기동 및 과거 현장 기록은 별도 범위다. ## test 자동기동 정책 Last reviewed: `2026-10-12 13:21:11 KST`. [재부팅 확인·자동기동 적용·복귀 근거](validation/20261012T132111+0900-validation-test-autostart.md). test5서비스의 ct 지속 설정과 Runtime을 `unless-stopped`로 정합화했고, 재시작 없이 검증했다. 명시적 `ct stop`의 정지 상태와 채널 Start/Stop 계약은 유지한다. 다음 `ct start`의3서비스 재생성 계획은 dry-run으로만 확인했다. GPU 복구 뒤 사용자 재부팅·화면 확인은 완료했지만, 이번 자동기동 정책 적용 후 실제 재부팅 검증은 사용자 요청으로 보류하며 추가 재부팅/시험을 예약하지 않는다. 아래 다중 ROI/API2 질답과 현장 서버의 과거 운영 기록은 각각 별도 범위로 유지한다. ## 다중 ROI와 API 2.0 질답 아래는 각 시점의 기록이다. 현재 사용자 전환 모드·격리 실입력 결과는 상단16:14 기록을 우선한다. 2026-10-13 13:50:30 KST: 후속 승인으로 test APP·Sidecar·ct와 Gateway snapshot을 설치했다. [설치·필수 검증·복구](validation/20261013T135030+0900-validation-test-multi-roi-install.md). configured/effective legacy·ROI8/rule48/예약0,5서비스 running/채널36개 stopped를 확인했다. DB/Redis 재생성 없음, 기존 image·인증·원본자료·unless-stopped 정책 보존. 다중 ROI live 전환·Web 최종 스키마·영상·GPU 부하·재부팅은 미시험이다. 다음은 사용자 `ct roi status` 확인이다. 아래 11:30의 미설치는 source 단계 당시 기록이며 위 후속 설치가 현재 기준이다. 2026-10-13 11:30:56 KST: `MROI-01` source/test/docs 구현·격리 검증 완료. [개발 합의서·checkpoint](../../../../MULTI_ROI_CONTRACT.ko.md)가 최신 사용자 합의를 소유한다. 아래 10월 12일 질문 대기/상태 보존 제안보다 최신 합의가 우선한다. 운영 설치/Runtime/배포는 제외한다. [검증·미확인](validation/20261013T113056+0900-validation-multi-roi.md): 표적 337개 통과. 기본 legacy 유지, Web 최종 스키마/실연동/성능은 미확인이다. ct/설정/image 설치본은 변경하지 않았다. Last reviewed: `2026-10-12 12:54:40 KST`. [최신 비판적 비교·ROI 질문·재부팅 문맥](analysis/20261012T125440+0900-analysis-roi-api2-critical-review.md), [이전 HTML 비교 안내](analysis/20261012T102702+0900-analysis-roi-api2-comparison-guide.md), [외부5자료·현재 코드 비교와 질답 원장](analysis/20261012T095458+0900-analysis-roi-api2-intake.md). ROI별 config·상태·cooldown·이벤트 독립, AI의 감지 ROI 간 겹침 검사/통합 제외 방향을 합의했다. Web JSON 표현은 후속으로 받고 AI 공통 의미/adapter를 분리한다. 새 Start에서 빠진 ROI는 활성 설정에서 제거하는 전체 snapshot 방향을 합의했다. 빈 목록·ID·상태 보존·적용 경계는 HTML03-Q1~Q5 확인 대기다. 우리 Web 동료의 ROI 제안과 아이서티 API2 외부 제안을 분리한다. Web SOT는 외부안에서도 유지된다. Media 직접 조회·직결 WSS는 필요성/호환 검토를 먼저 하며, token 발급 주체의 문서 충돌을 새로 기록했다. test 재부팅 백업에서 필요한 원문만 조회했다. Runtime 현재 정상 여부는 판정하지 않았다. HTML R02의 고정01~11항목으로 질답한다. 구현/배포 착수 없음. 코드·Runtime·PDF·DB는 그대로다. 아래 운영 사실은 기존 관측이며 현재 실시간 상태를 다시 확인한 것이 아니다. ## AI2 외부 사용 안내 Last reviewed: `2026-10-07 17:54:21 KST`. [3종 PDF 작성·검증](validation/20261007T175421+0900-validation-ai2-user-guides.md). 통합9쪽·Web7쪽·AI2쪽을 같은 원본/절차 번호로 생성했다. 통합본만 인쇄하면 전체 내용이 포함된다. 6개 실제 화면과 지원 동작을 대조했고 군중 안전 입력값의 미사용을 사용자 승인에 따라 명시했다. 18페이지 렌더링·폰트 내장·링크·명령·잘림 검증 완료. 서버 접속/Runtime 조작은 하지 않았다. 최신 보존 기록은 사용자 Event 관측과 Web Stop, AI측4그룹 회수·새 APP/모델 준비 확인이다. 실제 재부팅·자료 삭제/초기화는 미시험이다. 아래 정지/활성화 대기는 과거 시점 기록으로 보존한다. ## AI2 수동시험: 자료 미리보기 Last reviewed: `2026-10-07 13:08:48 KST`. [worker 그룹 권한과 진단 보완](validation/20261007T130848+0900-validation-ai2-data-preview.md). 사용자 si 메뉴/server/storage PASS. plan의 errno13은 제한 worker의 data GID 누락으로 확인해 수정했다. 표적2건·현장plan PASS: 총3098/보호462/정리가능4.10GB. 삭제0, 기존5서비스 exited, helper0. 다음은 사용자 ct start 결과 확인이다. 새 APP Runtime·브라우저 수용·실제 정리는 아직 미실행이다. ## AI 서버2 VSCode 탐색 보호 Last reviewed: `2026-10-07 11:57:00 KST`. 기준 HEAD `f2443b6f2976496cc67e5e57f4fe3b4c829d48bb`. [원인·적용·검증](validation/20261007T115700+0900-validation-ai2-vscode-safety.md). 누락됐던 원격 npm/탐색 보호 설정을 적용하고 공통 ct에 /storage 검색·watcher 제외를 추가했다. 사용자 저장 승인 뒤 extensionHost만 회수, 사용자 재시작/화면 정상 확인. RSS12.03GiB→224.4MiB, 마지막15초 rg0개. 표적8사례 PASS와 설치 지문 확인. AI2 5컨테이너 정지·active 보존. test VSCode/Runtime·청계산·Web은 변경하지 않았다. 실제 재부팅·장시간 재발은 미검증이다. 아래 자료 관리 Runtime 활성화 대기는 계속 유지한다. ## ct 자료 관리·권한 보완 Last reviewed: `2026-10-07 11:40:00 KST`. 기준 HEAD `654c35d1994318d401408319b62fc100c2ce45fe`. [CTCLR 결정](decision/20261007T114000+0900-decision-ct-data-maintenance.md), [설치·필수 검증](validation/20261007T114000+0900-validation-ct-data-maintenance.md), [사용·복구 가이드](../../../../deployment/CT_DATA_MAINTENANCE.ko.md)를 우선한다. si launcher 권한과 재발 원인을 고치고 clean/reset/storage 도구를 AI2와 test에 반영했다. 실자료 삭제·초기화 없음. AI2 5서비스 exited, test 기존5서비스 running 유지. 새 APP image는 다음 명시적 기동 대상으로만 준비했고 새 Runtime 적용/사용자 수용은 보류한다. 최종13파일 설치 지문 일치·si sudo/menu와 격리 필수 검증 완료. 청계산/101 접근 없음. 재개점은 영구 evidence `2026-10-07_ct-storage-maintenance_r01/checkpoint.ko.md`다. 아래의 AI2 최종 Stop 대기는 과거 기록이며 현재 정지 상태로 갱신한다. ## AI 서버2 배포 재개 Last reviewed: `2026-10-06 19:58:03 KST`. 기준 source `4f0bd4eddd5b6e600b947eee5444fd34e7ee8a54`. 현재 커널용 NVIDIA 모듈 누락을 승인된595.91.07 구성으로 복구했다. 커널139와 Secure Boot를 유지했고 재부팅 없이 호스트/제한된 DeepStream 컨테이너에서 RTX PRO4000 Blackwell24GB 인식을 확인했다. 이전23패키지와 설정 복구본, 설치 계획/결과를 보존했다. 원인이 명확한 국소 helper 오류는 수정 후 재개한다. 고유 image·portable ct·네 모델 batch8/instance8/version8·Web 발급/apply·5서비스 기동 완료. 모델 검증 helper BLAS thread를1로 제한해 PID128 보호를 유지했고 표적21건과 네 모델 실행을 확인했다. Web측 Start4채널에서 Redis Frame·자연 Event·학습 저장을 읽기 전용 관측했다. 최종 Stop은 담당자 시험 여부 확인 대기다. 운영/시나리오 PDF 각4쪽 준비. Web UI 노출·브라우저 수용·실제 재부팅은 미확인으로 구분한다. [설치·검증과 남은 확인](validation/20261006T195803+0900-validation-ai2-deployment.md)을 우선 읽는다. 상세 재개점은 영구 evidence의 `2026-10-06_icerti-ai2-deploy_r01/checkpoint.ko.md`를 사용한다. test Runtime/기존 현장 서버는 변경하지 않는다. 아래 test 연결 대기 상태는 과거 기록이다. ## ct 서버별 재사용과 test 설치 Last reviewed: `2026-10-01 18:26:23 KST`. [CTG-01~13 결정](decision/20261001T182623+0900-decision-ct-portable.md), [설치·검증](validation/20261001T182623+0900-validation-ct-portable.md), [서버별 ct](../../../../deployment/CT_PORTABLE.ko.md). 서버 정의/환경 프로필과 Compose/transaction backend를 분리하고 test에 도구·관리 메타데이터만 설치했다. 표적98건 PASS, 기존5서비스 exited·Compose/env/mount/NIC/기동 정책 보존, Web 조건 읽기 전용 확인. 로그인·발급·기동은 미실행이며 다음은 사용자 `ct config status` → `ct profile credentials`다. 현장 설치 성공은 사용자 보고이며 이번에 아이서티에 접속하지 않았다. PDF/FINAL은 유지했다. 아래는 이전 작업 시점의 기록이다. ## 현장 매뉴얼과 재부팅 수용 Last reviewed: `2026-09-30 18:40:15 KST`. [PDF 생성·검증](validation/20260930T184015+0900-validation-field-gamebook.md), [동일 항목 번호의 GPT 참고 문서](../../../../deployment/CT_FIELD_GAMEBOOK_GPT.ko.md). 보존 기록에서 회사망 재부팅 후5서비스 자동 기동·4모델READY·WSS와 사용자 camera3 표시/Stop을 확인했다. 그 뒤 field 선택과 다음 부팅 고정 NIC 설정이 준비됐다. 마지막 앱 Runtime은 회사망이므로 현장 최초 로그인/발급/apply/start는 별도다. 회사망 재부팅 성공을 현장 수용으로 확대하지 않는다. 통합35쪽·빠른8쪽 PDF와 비민감 GPT 참고서를 같은 항목 원본으로 생성했다. 새 서버 접속·Runtime 조작·시험·배포는 없으며 원본 evidence를 보존했다. 아래 재부팅 대기는 이전 시점 기록이다. ## 수동 재부팅 직전 준비 Last reviewed: `2026-09-30 17:43:10 KST`. [사전 준비·검증](validation/20260930T174310+0900-validation-ct-preboot.md). Web 발급 설정·bbox Redis 고정값 문제 해결 뒤 camera3 시각화/수동Stop을 사용자 확인했다. side 포트 override 수정과 apply/start/WSS 성공을 유지하고, version 저장후표시·발급 reason 안내를 보완했다. 현장 CA·계정을 field 전용 파일에 준비했으며 office·NIC·현재 실행 설정은 유지했다. 표적26건+manifest4건/source67파일, 도구5파일 설치와 부팅 보호·데이터 mount 확인 PASS. 서비스/카메라 조작·새로그인·재부팅은 하지 않았다. 다음은 사용자 sudo reboot 후 수동 Start 전 자동 기동 관측. 회사망 ARP는 임시 예외이며 필요시 수동복구한다. 실제 현장 적용·PDF·test용 범용화는 후속이다. 아래는 이전 시점 기록이며 Web500 대기 상태로 되돌아가지 않는다. ## 연결 단절 전 ct 재사용 보존 Last reviewed: `2026-09-30 16:36:24 KST`. 기준 HEAD `6c621870ad17d3775685165afb9237755b79d55a`. [ct 재사용·오프라인 인계](../../../../deployment/CT_REUSE_HANDOFF.ko.md)에 모듈/설치 구조, 서버별 hardcode, test 이식 경계, 수동시험 결과와 남은 개선을 통합했다. 영구 evidence 위치도 해당 문서에 있다. 현장 read-only 설치 지문·profile 구조·mount/unit/ACL 상태를 보존했다. Runtime·인증·네트워크 변경 없음. 사용자 수동 version2 로그인은 성공, Web DB에 새 접속정보 반영. 인증서 발급은 Web의 CA/key 경로 미설정(CERTIFICATE_SIGNING_NOT_CONFIGURED)으로 대기 중이다. session 포함 pending 보존, 자동 retry/cancel 금지. test는 기존 유효한 leaf를 사용하며 신규 발급과 별개임을 확인했다. 두 Runtime은 stopped 유지. 다음은 Web signer 설정 반영 후 기존 stage 재시도 또는 별도 승인된 test용 ct adapter 구현이다. 이번 문서 보존은 test 설치·범용화·완전 복구 image 준비 완료가 아니다. 아래는 이전 단계 기록이다. ## 현장 도구 보완 후 재개점 Last reviewed: `2026-09-30 15:39:01 KST`. 수동시험은 사용자 요청으로 일시 중단하고, 연결 버전/오류 구분·USB 선택 해제·언어·자원 보호를 구현·현장 설치했다. [검증·재개](validation/20260930T153901+0900-validation-field-recovery-tools.md), [운영 명령](../../../../deployment/ICERTI_OFFLINE_MAINTENANCE.ko.md)을 우선 읽는다. Python3.12 표적72건, 설치18파일 지문, 명령/메뉴10개, 실패 준비본·Runtime 보호 확인 PASS. 사용자 승인 extensionHost 종료 뒤 새 host 실행 확인, RSS 약16.32GB→0.57GB. Python/Pylance도 root 탐색을 보존한 경량 설정으로 반영했다. 장기 재발 여부·물리 콘솔·Web 연동은 미확인이다. 사용자는 확장 호스트 재시작과 편집 화면 정상을 확인했다. 전체 IDE 기능·장시간 안정성 판정은 아니다. test/현장 Contextra stopped, 기존 모델/image·인증·pending·NIC 유지, 추가 로그인/Start/재부팅0회. 다음 사용자 단계는 `ct config status`와 `ct config version status` 확인 후, 명확한 실패 준비본을 보존·선택 해제하고 새 버전을 지정해 prepare/connect를 한 번씩 진행하는 것이다. 자동 실행하지 않는다. 아래 HTTP400 조사는 완료됐으며 당시 기록은 보존한다. ## 수동시험 최신 재개점 Last reviewed: `2026-09-30 13:41:06 KST`. 시험 합의·실패 전후·접근 근거는 [중간 handoff](validation/20260930T134106+0900-handoff-field-login-http400.md)를 먼저 읽는다. USB CA 오반입 교정→사용자 CA/계정 저장→prepare PASS. 잘못된 neighbor 임시 교정 뒤 TCP/TLS PASS. 사용자 명시 재시도 결과 LOGIN_REJECTED/HTTP400, session/발급 leaf 없음. 비밀번호 불일치로 단정하지 않는다. 다음은 이미 발생한400의 로그·입력 계약을 읽기 전용으로 대조하는 단계다. 새 로그인 반복/prepare 초기화 금지. 사용자 승인으로 기존 test5컨테이너도 중지 유지한다. 아이서티5컨테이너 stopped, apply/start 미실행. 아래는 이전 단계 snapshot 요약이며, 현재 수동시험 상태는 위 handoff가 우선한다. ## 현장 유지보수 A+B 재개점 Last reviewed: `2026-09-30 KST`. 사용자 구현·설치 승인, 기준 source `bbfbd13`. 설정 원본/메뉴 통합, 일반 설정 drift의 명시적 수용, 프로필별 계정·CA, 네트워크 대기 상한60초, 재개/복구와 비민감 반출 기록을 구현한다. 회사망 DHCP·현재 SSH 포트와 기존 Runtime 자료를 보존한다. 실제 주소 전환·재부팅·로그인·인증서 발급·카메라 실행·Web 수용은 후속 사용자 동반 시험이다. 임시 sudo 파일과 SSH 키는 사용자 삭제 지시 전까지 보존한다. 기존 자동 삭제 지침보다 우선한다. 현장 read-only 확인: 기존5컨테이너 stopped, active/site/Compose 지문 일치, 주소는 실제 NIC와 기존 앱 설정이 다르다. 어제 네트워크 대기 timeout 반복과 비활성 현장 고정주소 YAML을 확인했다. 진행: profile/긴급 수용/apply/recovery·CA UX·도구 설치·사용 가이드 완료. 표적54건 통과 (합동52건 및 후속 root/문법 복구2건). 서버 메뉴/경로/si 권한·설치10파일 지문과 wait-online60초 확인. active/site/Compose/unit 지문과5컨테이너 stopped 유지. Runtime/모델/인증·NIC 전환 없음. 다음: 사용자와 `ct config status` → `ct profile paths`에서 새 환경 계정/CA 준비·실연동 시험. [검증·재개 경계](validation/20260930T114810+0900-validation-field-maintenance-ab.md), [운영 가이드](../../../../deployment/ICERTI_OFFLINE_MAINTENANCE.ko.md). 수동시험 잠금 갱신: `2026-09-30 12:12:02 KST`. 사용자 MT-01~14 방향 동의, CA는 USB 먼저/SSH 다음. 기존 공개 CA의 test 영구 백업·지문 일치 확인 완료. 원본/인증/서비스 변경 없음. [수동시험 원장·현재 재개점](validation/20260930T121202+0900-handoff-field-manual-acceptance.md)을 우선 읽는다. 아직 실제 수동시험은 시작하지 않았다. 폐쇄 현장 주소의 실제 통신시험은 상대 PC/망 구성 확인 뒤 잠근다. ## Workspace 개방·저장 초기화·재부팅·인증 CLI Last reviewed: `2026-09-28 19:05:56 KST`. 후속 승인으로 /workspace si ACL을 개방하고 기동 필수 인증 영역은 보호했다. ct access 재적용을 추가했다. Event/학습 미디어 및 전용 원장0, 카메라·모델·인증·보관 설정 보존. root 전용 DB 복구본만 유지한다. CLI 기본 multi-user.target, 디스크/bind/Runtime 부팅 순서와 guard 확인. 실제 reboot는 하지 않았다. ct auth 계정변경·1회 로그인·WSS 확인·재개/취소를 추가했다. 새 계정 요청은 세션 미확보였고 사용자 Web PC Off 보고 후 재시도0, 기존 파일·Sidecar 복구/pendingfalse/WSSfalse. 5서비스running/4모델READY/44stopped. [검증](validation/20260928T190556+0900-validation-workspace-reset-auth.md), [현장 명령](../../../../../tools/icerti_offline/maintenance/OFFLINE_OPERATIONS.ko.md). 아래는 이전 작업 기록이다. ## 아이서티 오프라인 준비와 권한 최종 확인 Last reviewed: `2026-09-28 18:05:49 KST`. 부모 군중 패치 위 Python APP image 적용·ct 반자동 관리·local LLM/GUI·관측·USB r03 준비를 완료했다. si source124파일 읽기·쓰기와 app/inbox/outbox/notes의 실제 생성·정리, 설치 도구 hash를 재확인했다. 도구가 Git 밖에만 남아 있던 보관 누락을 `tools/icerti_offline`과 [운영 안내](../../../../deployment/ICERTI_OFFLINE_MAINTENANCE.ko.md)로 보완했다. [검증과 남은 확인](validation/20260928T180549+0900-validation-offline-prep-closeout.md). 사용자 ct start 이후5서비스실행/네모델READY/44stopped. 재로그인1회401, 기존세션·Sidecar복구/WSS미연결. Web계정·새현장IP/CA·Windows·물리GUI 수용은 별도이며, 이번 보관 단계에서 Runtime을 다시 바꾸지 않았다. 아래는 이전 작업 기록이다. ## 아이서티 군중 추가 패치와 A13 Last reviewed: `2026-09-28 16:28:00 KST`. source0f172d94, 현장 transaction `crowd-20260928-r02`. 군중/cooldown analytics·sidecar와 Gateway CROWD 미디어 허용을 함께 반영했다. 현장 base/네 모델version8·batch8·instance8/SDK/native/인증/보관 정책을 유지했다. [검증](validation/20260928T162800+0900-validation-icerti-crowd-a13.md), [사용·재개](../../../../deployment/ICERTI_PROVIDER_OPERATIONS.ko.md). 복합13(camera30~42) 안정화후30.000016초1회: Redis평균9.89/9.92/9.94, 최저9.67/9.80/9.83FPS(Pose/Fire/Crowd). queue만료/초과0, sender교체Pose1/오류0, CPU70.43%/GPU88.86%. 39child exit0/unforced/reaped. 기동~회수 자연Event304건: READY/SENT212, keyframe없는미디어실패43/SENT, capacity만료49. Crowd3건은모두READY/SENT. CAS 및 guarded 원본복귀 뒤44stopped. Gateway 복구시Web31~38 Start재유입을1회회수하고 Gateway중지대기. 최종4모델READY/analytics·sidecar실행/시험child0, no-capturefalse/상세계측Off. 이후Web수신설정은보존했다. 원자료 `/tmp/codex/ltb1021/2026-09-28_icerti-crowd-patch_r01/`, 현장동일자료는 deployment-inbox에보존. 다음은Web자동Start정리→Gateway기동→사용자수동Start/Stop·미디어확인이다. 추가성능시험/튜닝없음. 아래는 이전 작업 기록이다. ## Crowd 미디어 Gateway 보완 Last reviewed: `2026-09-28 15:39:39 KST`. HEADd0cdd435 기준, Gateway 미디어 경로 허용 목록에 누락된 CROWD를 추가했다. 수정 전 Crowd 파일 내부 조회200/외부404, 비교용 INTRUSION 외부206으로 경계를 확인했다. Python3.12 표적19PASS와 Nginx 설정 검사 후 graceful reload. image/build/모델/인증 변경 없음. 사용자 camera3 run/child 및 세 컨테이너 PID를 유지했고 WSS 연결을 확인했다. 수정 후 실제 미디어 수신은 사용자 요청에 따라 수동 확인으로 남겼다. [검증](validation/20260928T153939+0900-validation-crowd-gateway.md). 아이서티 후속 배포에는 analytics/sidecar뿐 아니라 Gateway template 및 유효 설정 반영도 포함한다. 아래는 이전 작업 기록이다. ## 최신 A조건 복합2채널 1회 Last reviewed: `2026-09-28 15:12:37 KST`. HEAD6226e74, 기존crowd-events-6355edabd6 analytics/sidecar 재사용. 코드·image·모델변경 없음. [검증 SOT](validation/20260928T151237+0900-validation-crowd-a2.md). camera3·8, reference_count50/6종On/저장On, 안정화후29.9974초1회. Redis평균/최저 Pose9.40/9.27, Fire9.78/9.70, Crowd9.82/9.73FPS. Pose평균은참고9.5미달, 나머지평균·모든최저는참고기준충족. queue만료/초과·sender교체/만료/오류0. CPU평균79.82%/GPU평균46.14%. Crowd모두SAFE/Event0, 다른자연Event30건READY/SENT. 이전기준인원1시험과입력위치/자연Event부하가달라 단일변경효과로해석하지 않는다. 6childexit0/unforced/reaped, 시험SettingsCAS복귀, Compose/학습/비대상보존. 최종36stopped/child0/4모델READY/Gatewayrunning/WSSconnected, 상세계측종료. 원자료 `/tmp/codex/ltb1021/2026-09-28_crowd-a2_r01/`; 최종근거 `final-state.json`. Web신규필드송신·표시수용과아이서티추가배포는후속이다. 아래는이전작업기록이다. ## 군중 Event·cooldown test 반영 Last reviewed: `2026-09-28 14:36:22 KST`. 기준HEAD13dfc206 + 승인task diff. [결정](decision/20260928T142231+0900-decision-crowd-events.md), [검증](validation/20260928T142231+0900-validation-crowd-events.md), [설정·사용](../../../../scenarios/CROWD_EVENTS.ko.md). Web Crowd필수5개 무효이면 Crowd만Off, 내부reference_count50과 누락fallback을 분리했다. 6종cooldown Web override/default10, Crowd4상태·DANGER episode/gap 보호·ROI Event·heatmap Artifact를 연결했다. analytics/sidecar image는 각각 `contextra-analytics:crowd-events-6355edabd6`, `contextra-sidecar:crowd-events-6355edabd6`. source hash/runtime/persistent와4모델READY 확인. Python3.12 표적171PASS/86subtests, 추가189PASS/2기존fixture실패 후 해당secure bridge74PASS 재검증(중복 포함). camera3·8복합30초 Redis9.60~10.07FPS, queue만료·sender교체/만료/오류0. CPU79.88%/GPU45.29%. CROWD2건READY/SENT, 두clip전체decode/PTS와thumbnail확인. 시험6child exit0/unforced/reaped. 시험Settings CAS복귀 뒤Gateway/WSS를 복구했으나 외부Start 재유입이 반복됐다. 사용자 추가지시로Gateway중지 대기, 최종36stopped/child0/WSS미접속. 사용자 후속카메라설정은 보존했다. no-capturefalse/ArtifactHTTP·학습On/B·freshnessOff/최신화On/queue1초32/Stream300과 모델설정 유지. 원자료 `/tmp/codex/ltb1021/2026-09-28_crowd-events_r01/`; 최종상태는 `final-state-blocked-gateway.json`. 다음은Web의 재Start희망상태 정리 후Gateway복구 및 사용자수동Start/표시/Stop이다. Web수용·아이서티추가배포·현장검증·전체확장시험은 미실행이다. 아래는 이전작업 기록이다. ## 현장 A/C 기준선 완료 HEAD `79c8f879`, 기존 현장 image/모델을 재사용했다. camera30~45의 Pose A/복합 A1~16과 사용자 최종 승인 범위인 복합 C16 한 번을 완료했다. Pose C1은 범위 축소 전 보조 자료다. [측정 SOT](validation/20260927T231521+0900-validation-icerti-ac-scale.md), [영역별 해석](analysis/20260927T231521+0900-analysis-icerti-ac-scale.md), [사용·재개](../../../../deployment/ICERTI_PROVIDER_OPERATIONS.ko.md). 원자료 `/tmp/codex/ltb1021/2026-09-27_icerti-ac-scale_r01/`, 현장 사본은 `/backup/contextra/deployment-inbox/icerti-ac-scale-20260927-r01/`이다. Pose A16 평균Redis9.93/최저9.77FPS. 복합 A는13까지 참고기준을 충족하고14부터 Pose가 낮아졌다. 복합16 A→C Redis는 Pose7.86→8.23/Fire9.12→9.36/Crowd9.16→9.50FPS, CPU70.7→33.8%/GPU93.9→98.0%다. C는 저장 전체 경로 제외이지 renderer 단독 효과가 아니다. 완료queue 만료/용량초과0, 송신 오류/만료0. 자연 Artifact의 keyframe 실패·capacity eviction/거절은 별도로 남았으며 정상 상한 거절로 시험을 중단하지 말라는 사용자 지시를 반영했다. Pose A12 재개는 새 run이고 C16은 신규 동시 기동이므로 완전한 동일 조건 비교로 표현하지 않는다. 최종 원래 채널 설정 bytes 복귀,44stopped/시험child·helper0/4모델READY/WSSconnected. C=false·Artifact/HTTP/학습On·최신화On·queue1초·상세계측Off, 기존 image/모델/인증 보존. 전체 C 곡선·장시간 안정성·하드웨어 절대 최대치·실제 Web 표시 성능은 미검증이다. 추가 튜닝 없이 이번 기준선으로 보고를 마무리하며, 실사용은 필요한 시나리오만 선택한다. Last reviewed: `2026-09-27 23:21:51 KST` 아래는 이전 배포와 test의 역사적 기록이다. ## 아이서티 Provider·경로·보관 정책 반영 [잠금 결정](decision/20260927T210700+0900-decision-icerti-storage.md). 기준HEAD d900910d, evidence `/tmp/codex/ltb1021/2026-09-27_icerti-provider-patch_r01/`. 현장44등록채널 중16running을 승인에 따라Stop/reap하고 최종44stopped/시험child0이다. [검증 SOT/한계](validation/20260927T215253+0900-validation-icerti-provider-patch.md), [사용·보관·재개](../../../../deployment/ICERTI_PROVIDER_OPERATIONS.ko.md). 최종image `contextra-analytics:icerti-provider-d900910-20260927-r02`, transaction `provider-20260927-r03`. 네 모델 현장 변환/version8/batch8/instance8 READY, 각batch1..8 shape/dtype/finite PASS. Pose/복합1채널 Redis·Frame/PTS·필드·Stop PASS, 자연Event11건 READY/SENT. 격리학습 raw/overlay/JSON·exactPTS·1280x720·owned삭제/포화skip PASS. 최초sample version unknown은 최종env version8로 보완했으며 수정 후 새 학습sample 저장까지 반복하지 않았다. Event4TB/학습2TB·최소여유100GB, root이전/bind/guarded재기동/cleanup cron대체 완료. 기존원장189955건 원래필드fingerprint와 카메라저장원문 보존. 미참조구설치230파일23.76GB만 이관hash검증뒤정리. WSS connected/ping-pong, Artifact/HTTP·학습On, C=false, 최신화On/B·freshnessOff/queue1초32/Stream300. 상세계측Off, test Runtime·비대상서비스조작없음. 전체부하/정확도/실제Web수용/호스트reboot는미검증이다. 사용자는현장Web에서필요한카메라를수동Start한다. 아래는직전test 기록이며 test Gateway중지는별개상태다. Last reviewed: `2026-09-27 21:52:53 KST` ## 최신 no-capture C 기준선 [측정 SOT](validation/20260927T194740+0900-validation-capture-off-scale.md), [영역별 해석](analysis/20260927T194740+0900-analysis-capture-off-scale.md), [옵션/재개](../../../../scenarios/INPUT_FRESHNESS_TRIAL.ko.md). HEAD1329e8c에서 기존 경로를 재사용하고 수집창2400초/상태 표본1..8 옵션만 보완했다. 최종image `contextra-analytics:capture-off-scale-d9a7f28185`. Python3.12 표적15PASS/native 경계 fixture PASS. Pose 단독1–16 완료: 평균Redis10채널9.64,16채널6.33FPS(최저4.87). 완료queue 만료532건. 복합1–12 완료:12채널 평균Redis Pose2.58/Fire2.83/Crowd2.76FPS, 완료queue 만료0건. 처음복합8 상태조회timeout 뒤 per-stream 조회로 보완했으나 재개8에서camera8 Pose stall. 상태export8→2 표본 축소로 다시8부터 측정,13확장 중camera15 Pose1213응답 뒤 stall/SIGTERM 강제회수. 13–16은미측정이며 stall 근본원인 미확정이다. 오류 무시/timeout확대/반복 재시작으로 통과시키지 않았다. 총103child회수(102exit0/1SIGTERM), reader4개회수. 실패기록을 보존하고 서비스 최종전환 뒤 잔여camera15 설정만CAS복귀했다. C 시험 중 신규원장0/시도0/표본renderer0, 미발행후보685건을실패Artifact로세지않았다. CPU90%대와 runnable wait 증가, analytics외부 약6.6–8논리core 상당 부하를 함께 기록했다. 복합8–12는 새run/계측표본2/실제30.6–88초로 측정됐으므로 완전히 연속된 동등30초 기준선이 아니다. 최신성은 source와 이후처리를 분리한다. 복합12 ingress→Redis 평균Pose1.74초이며 최신화On이 전체저지연을 보장하지 않는다. 최종 C=false/ArtifactHTTP·학습On/최신화On/B·freshnessOff/queue1초32/batch8·instance8/Event10초/Stream300. 상세계측Off,36stopped/child0/네모델READY/비대상변경0. Gateway/WSS는 사용자 지시로 중지 대기한다. evidence `/tmp/codex/ltb1021/2026-09-27_capture-off-scale_r01/`, 최종근거 `final-state.json`. 다음 최소후보는 고부하 상태수집의 경량 counter 요약화다. stall 해결/전체16수용/Web/아이서티검증은 완료하지 않았다. 아래는 이전 작업의 역사적 기록이다. ## 최신 입력 지연 / test 최신화 On [측정 SOT](validation/20260927T180610+0900-validation-input-lag.md), [해석](analysis/20260927T180610+0900-analysis-input-lag.md), [시험 계약](decision/20260927T175523+0900-decision-input-freshness.md), [사용자 기본On 결정](decision/20260927T180610+0900-decision-input-latest-default.md), [옵션/재개](../../../../scenarios/INPUT_FRESHNESS_TRIAL.ko.md). HEAD85d9b63 + task 변경. image `contextra-analytics:input-lag-f12524504a`. Pose/Artifact On/queue1초의6→8→6에서 depay→source248/1401/240ms, RTP 추가지연도 자연 회복했다. 같은 최종image8채널 Off45초/On120초에서 source1533→79ms, 완료8.72→7.67/Redis4.65→4.88FPS. decoded NVMM 대기queue만 최신1개로 제한한다. 압축queue/모델/전처리/완료queue/송신 구조는 유지한다. 입력 최신성 개선이며 추론 처리량 증가는 아니다. CPU92%대, 후처리/완료queue 만료는 남았다. 확장 계측 IPC64KiB 초과 오류와 뒤이은 SIGSEGV1건은 실패 증거로 보존했다. 표본8개/8KiB로 제한한 뒤 Off/On16child 정상회수. 전체31child 회수(30exit0/1SIGSEGV), native signal 근본 원인은 미확정이다. Python3.12 최종49PASS/IPC·process15PASS(중복), 시나리오42PASS와 native fixture PASS. 기존API fingerprint26/27 문제는 실제 route 대조와 explicit test로 수정했다. C no-capture는 기본false, CPU 검증만 완료, GPU C는 미실행이다. renderer/학습 실패 해결은 주장하지 않는다. 최신 사용자 승인으로 test 최신화On을 Runtime/persistent에 유지한다. 소스/다른 서버 미지정값은false다. 상세계측Off, queue1초/32, ArtifactHTTP/학습On, 네모델READY,36stopped/child0/설정CAS복귀/비대상보존. Gateway/WSS는 사용자 요청으로 **다음 시험까지 중지 대기**다. 앞선 WSS 복구 기록은 최종상태가 아니다. 최종 근거 `final-state-promoted.json`; helper/원자료 `/tmp/codex/ltb1021/2026-09-27_input-lag_r01/`. 다음 최소 후보는 동일 대표 부하의 no-capture C 비교이며 별도 승인 전 실행하지 않는다. 아래는 이전 기록이다. ## 최신 후처리 최소 개선 / queue1·2 비교 [측정 SOT](validation/20260927T153547+0900-validation-result-queue.md), [해석](analysis/20260927T153547+0900-analysis-result-queue.md), [사용/재개](../../../../scenarios/PROVIDER_PROCESS_RUNTIME.ko.md). HEAD06c3cf6에서300개이하 정렬생략/단일결과 재사용/NMS진단 보존/cameraId검증을 적용했다. queue대기 옵션과 제한된 후처리 wall/CPU·동일Frame 선택/완료→Redis 계측을 추가했다. Snapshot 공유/검증제거/병렬화는 하지 않았다. 최종image `result-queue-b-3e7be9737c`. Python3.12 표적44PASS 및 추가52PASS(중복),6subtest. API 구조 fingerprint1실패는 이전image에서도 같은27/26 불일치로 재현했다. 기대값 수정 없이 미해결로 남긴다. 같은 개선image에서 Pose4시나리오On B(queue2) 뒤 A(queue1), 각각6/8/12/16을 측정했다. B Redis평균6.15/5.03/4.74/4.09, A5.30/4.57/4.24/4.15FPS. B는 평균 결과나이가 약0.5–0.9초 더 길었다. 사용자 최종지시로 queue1초를 Runtime/persistent에 유지한다. 중간의2초유지 승인은 이 결정으로 대체됐다. Artifact Off C는 사용자가 보류했고, 복합B도 사용자 지시로 생략했다. 처리/회수 오류로 중단한 것이 아니다. 추가30초 Redis관측에서camera3/8/9/10은visible bbox를 계속 전송했다. 과거9월23일anchor로추정시각이9월23일인점은별도확인필요. 표시소실의Web원인/anchor정합은미확정. 성능시험은AI직접Start/Gateway중지조건이며Web수용시험이아니다. 이후사용자승인으로Pose1→6→8의첫Metadata부터RTP/벽시계연속관측5014건을추가했다. camera3의1채널대비8채널상대Redis지연은평균+3.65초(ingress까지+2.07초,이후+1.57초)였다. 각안정구간에서는높은지연수준에서변동하며장기무한증가여부는미검증이다.고정날짜오차와분리했다. 총40child exit0/unforced/reaped,36stopped/원설정CAS복귀/4모델READY/GatewayWSS/ArtifactHTTPOn/비대상보존. 기존collector준비·보관 비용이후처리의유의미한계측구간이다. 추가최적화/따라잡기/시간계약변경은미적용이다. 이하절은이전기록이다. ## 최신 학습 주기 개선 / Pose·복합 기준선 [측정 SOT](validation/20260927T123649+0900-validation-pose-mixed-baseline.md), [영역별 해석](analysis/20260927T123649+0900-analysis-pose-mixed-baseline.md), [사용/재개](../../../../scenarios/PROVIDER_PROCESS_RUNTIME.ko.md). HEAD66b3510에서 학습 주기가 남으면 score 후보/NMS 전에 반환하도록 최소 보완했다. 설정 확인은 초당 최대1회, 저장 주기 hint는 메모리에 유지하고 최종 reserve transaction은 보존한다. Python3.12 표적9PASS, 측정 창 합계 early skip18,598회. 속도 개선량의 독립 A/B는 하지 않았다. 최종image `pose-mixed-baseline-bd3e80f5dd`, batch8/instance8·B/Off·직접송신·Event10초·Stream300·학습 기본값 유지. 사람4시나리오On Pose 단독1–16 단계 완료. Pose16 평균 완료4.24/Redis3.54FPS. 복합6시나리오1–9 완료. 9채널 완료Pose3.70/Fire4.73/Crowd4.39, Redis3.71/4.73/4.38FPS. 10번째camera14 확장 중 기존camera12 Pose가650응답 뒤 provider_stalled. 근본 원인 미확정,10안정구간/11–16 미측정. Pose 완료queue 만료8,616건/송신교체5건, 복합148/37건으로 서로 다른 경계를 구분한다. 과거 B Pose16 약7.97FPS는 Event 시나리오Off였으며 이번4On/자연Event/학습On과 동등하지 않다. 전체 회수46child exit0/unforced, failed child는 terminal_failed=true이므로 정상 수행 성공으로 세지 않는다. 36stopped/child0/4모델READY/시험설정CAS복귀/GatewayWSS/ArtifactHTTPOn/비대상상태보존 확인. 학습 신규15READY/5QUEUE_EXPIRED, 자연Artifact Pose748READY/13FAILED/13EXPIRED, 복합322READY/9FAILED. 다음 최소 후보는 완료queue 이후 처리 구간 세분 계측이다. stall 원인 조사 전 고부하 확장 반복은 하지 않는다. 아이서티 배포/시험과 실제Web 수용은 미실행이다. 이하절은 이전 기록이다. ## 최신 송신 독립화 / 학습 저장 [결정](decision/20260927T003655+0900-decision-sender-training.md), [검증 SOT](validation/20260927T004500+0900-validation-sender-training.md), [해석](analysis/20260927T004500+0900-analysis-sender-training.md), [학습 설정/사용](../../../../scenarios/TRAINING_SNAPSHOTS.ko.md). HEAD10ddca4의 clean task에서 provider별 child 직접 Frame 송신과 부모 단일 상태/fencing/Stop 소유권을 연결했다. 최종image `sender-training-0cd60f5cb2`, B/Off·batch8/instance8·Event10초·Stream300 유지. 학습 조건은 활성 사람 시나리오의 score만 만족하는 person 합집합8개이며 ROI/Tracking/시간 조건은 제외한다. training900초/1280x720/200GB/최소여유100GB/owned oldest-first가 기본이며 인증 내부 Settings/CAS로 변경한다. 단일 압축cache 수집자/학습worker1/pending4/공통renderer4를 유지한다. Event clip/thumbnail은 해당 scenario ROI만 표시한다. Python3.12 표적50PASS+13/19PASS(중복), 실영상 학습6건 모두READY·동일PTS·3파일/1280x720 확인. GPU측정image6d1173df6e이후임시공간96MiB예약/크기확인,부모lastSeq갱신과기존provider메시지예산보호를보완했다. 관련6PASS와13PASS뒤최종본을반영했다.8채널재시험은없고최종1채널상태/송신/회수canary를별도기록한다. 최종canary parent lastSeq33/세provider송신/추가3child exit0·unforced·회수확인.기동직후값은FPS성능자료로사용하지않는다. 복합1/8 각30초.8채널 완료평균Pose3.59/Fire4.59/Crowd4.27,Redis3.56/4.58/4.26FPS. 이전Redis총40.87→99.27FPS,writewall181→12.2ms,송신교체1487→1.추론완료는121.37→99.57로감소했다. 비대상SSIMS계열7container의시작시각변경을관측했으나본작업에서조작하지않았다.서버부하동등/전체성능개선/GIL원인은미확정이다. 자연Artifact111READY/10FAILED(렌더9/keyframe1),기존문제해결아님.24child exit0/unforced/reap,36stopped/GatewayWSS복구. 전체1→16/17 성능기준선·아이서티배포·Web수용은후속승인이다.이하절은이전기록이다. ## 최신 batch8 / cooldown / Redis300 [결정](decision/20260926T230938+0900-decision-batch8-cooldown.md), [측정 SOT](validation/20260926T230938+0900-validation-batch8-scale.md), [독립 해석](analysis/20260926T230938+0900-analysis-batch8-scale.md). HEADb286446에서Event발급전run/scenario monotonic10초gate를추가하고경고/현재증거/episode/Event인계보호를유지했다. Crowd만batch8로변환,기존세후보재사용.네모델version8/max·preferred8/instance8,batch1/4/8실행PASS. 표적90PASS와추가23PASS(중복포함).LOITERING wrong-model1실패는변경전image에서도재현되는기존기대값충돌이다. 최종image batch8-cooldown-65294c6b51,B/Off·Event10초·공통Stream300 persistent유지.공개Redis/Web계약변경없음. 복합1/2/4/8각30초완료.8채널평균완료Pose4.30/Fire5.68/Crowd5.19,Redis1.63/1.85/1.63FPS. 8채널batch>4비율78.3/74.0/75.9%,batch8비율59.6/58.4/61.3%.증설효과판단은사용자에게남긴다. 16확장9번째camera13기동중camera12 Crowd가379응답뒤기존2초stall로중단.16정상측정은없고원인구간미분리다. 27child exit0/unforced/reap,36stopped/설정CAS복귀/4모델READY/GatewayWSS/ArtifactHTTPOn/비대상보존. 자연원장192건:READY184/FAILED6/EXPIRED2,pending최대14/최장age48.93초.지연/renderer실패해결완료아님. 이전DBlock은이번로그에관측되지않았지만해결입증으로표현하지않는다.자동rollback/재Start없음. ## 최신 B 기본값 / 복합 단계 측정 [측정 SOT](validation/20260926T214152+0900-validation-linear-scale.md), [영역별 해석](analysis/20260926T214152+0900-analysis-linear-scale.md), [사용/복귀](../../../../scenarios/PROVIDER_PROCESS_RUNTIME.ko.md). HEAD46f932b/기존image provider-linear-7d7a97e883을 재사용해 test persistent B=true/freshness=false로 승격했다. source/env 미지정 기본값과 다른 서버는 변경하지 않았다. Python3.12 표적24PASS, code/build/instance/batch 변경0. 6시나리오/Pose+Fire+Crowd로1/2/4/8 각30초 측정. 8채널 완료=수락 평균Pose4.22/Fire5.35/Crowd5.50FPS, Redis는각1.82/1.96/1.89FPS,최대batch4 실행비율90.2/84.0/87.7%. batch/instance 판단은 사용자에게 남긴다. 16 확장의11번째camera15 Start뒤camera8 Pose가DB lock timeout에 따른EventCapture/인계 실패로종료했다. exit0/terminal_failed/unforced이며OOM/native crash는아니다.16 정상구간은미측정,원인무시/timeout확대/재시도없음. 33child모두회수/36stopped/채널설정복귀/GatewayWSS연결/4모델READY/ArtifactHTTPOn/비대상보존. 자연원장380건:READY249/FAILED48/EXPIRED83,renderer19실패중SIGABRT8.생성실패HTTP200을클립성공으로세지않는다. 다음경계는ArtifactStore 공통예약행 lock 경합이며점유transaction은미측정이다.B/OFF는유지하되16채널수용완료가아니다. 아래 A/On 최종상태는이전기록이며현재는위B/Off가우선한다. ## 최신 Linear B 비교 [측정 SOT](validation/20260926T210406+0900-validation-provider-linear.md), [해석과 판정](analysis/20260926T210406+0900-analysis-provider-linear.md), [사용/재개](../../../../scenarios/PROVIDER_PROCESS_RUNTIME.ko.md). cb7d2a8에서 명시적 시험 B를 구현했다. 단일-provider 직선 경로에서 tee/강제 격리 복사/완료 relay를 사용하지 않고, 추론 전 slot 대신 완료 결과32개/queue대기1초를 사용한다. 현재 공통 시나리오/Event 인계는 재사용한다. 최종 Python3.12 표적49 PASS. B 기동 중Stop16.36초/exit0/unforced, Pose16 및 복합1의 모든child 정상회수. 직전 A 대비 Pose16 평균5.96→7.97FPS,Redis95.30→127.10FPS. 선택→제출223→508ms, TritonQueue44→300ms로 지연도 증가했다. 완료결과 queue폐기0,전송최신값교체4. 처리량 우선일 때 조건부 채택 추천이며16채널10FPS/저지연 달성은 아니다. 개별 변경의 효과는 미분리. Pose16은 c1e0fa2fe0 image, 최종보호본7d7a97e883은 blocking input의 미완료작업 stall guard만 추가했고 49PASS/복합1 GPU로 확인했다. 완료된 Pose16 전체를 반복하지 않았다. 자연Event5건(INTRUSION/LOITERING/FIGHT)은Artifact READY/HTTP200. FIRE/FALL 자연Event는 미확인이다. 최종image provider-linear-7d7a97e883, 시험B Off/운영A 및 freshnessOn,36stopped/child0/GatewayWSS연결. 모델/instance/batch/threshold/decoder/인증/ArtifactHTTP 및 비대상 보존. B 운영기본 승격은 별도 승인이다. ## 이전 Pose 단독 기준선 / 기동 중 Stop [측정 SOT](validation/20260926T195633+0900-validation-pose-reference.md), [영역별 해석](analysis/20260926T195633+0900-analysis-pose-reference.md), [사용/재개](../../../../scenarios/PROVIDER_PROCESS_RUNTIME.ko.md). 3c29d98 기준으로 unstarted graph Stop 제외, 기존 cleanup deadline 안의 source-ready EOS 순서, 출력 진행 관측 기반 steady stall 판정과 terminal 회수 진단을 보완했다. 최종 관련28 PASS. 첫 canary는 source-ready 고정5초 만료 뒤 이른 EOS/강제회수로 실패했다. 수정 후 같은 기동취소는 14.90초/exit0/unforced, Pose17 시험의 모든 child도 exit0/unforced로 회수했다. Pose+Tracking/시나리오Off/freshnessOff에서 1/2/4/8/16/17 모두 각30초 측정했다. 평균 완료=수락 FPS는 9.87/9.83/9.64/9.29/5.96/5.64, 응답 후 폐기0. 16→17 총량95.37→95.93FPS. 과거16채널 약10FPS와 engine/instance/batch는 같지만 입력/처리 경로가 달라 회귀 원인 확정은 아니다. 다음 최소 후보는 Pose JSON 복사/검증 bulk 처리의 동일조건 비교이며 아직 미적용이다. 최종image `pose-reference-334fde3791`, 36stopped/child0/4모델READY/Gateway running/WSS connected. 설정 복귀/freshnessOn/100ms/startup10/steady2/JPEGOff/Artifact HTTP On, 비대상 서비스 보존. 고부하 복합 stall의 근본 원인, Artifact 병렬 실패 해결, 실제 Web/아이서티 수용은 여전히 미확인이다. ## 이전 캡처 크기 / Freshness 비교 [결정](decision/20260926T190557+0900-decision-provider-freshness.md), [측정 SOT](validation/20260926T190557+0900-validation-provider-freshness.md), [해석](analysis/20260926T190557+0900-analysis-provider-freshness.md). 15a96ad에서 단일 provider mux 크기 정합, 시험 freshness Off, 진행 중 Frame 보호와 구간 계측을 추가했다. 최종 Python3.12 표적83 PASS. 기존 Pose planner 기대값1건은 이전image에서도 실패하며 이번 범위에서 수정하지 않았다. 4채널 ON/OFF와 OFF1/2/4를 측정했다. OFF는 응답 폐기0이나4채널 완료량도 낮아져 처리량 개선으로 판정하지 않는다. OFF8 확장 중 camera8 Pose steady-state 2초 stall, camera12 기동 중 Stop의 worker_join/강제회수가 발생했다. 8 steady 측정과16/17은 미실행이다. 초기 grace10초는 적용했지만 기존 고부하/회수 문제의 해결 완료는 아니다. 자연 Artifact226건: READY166/FAILED19/EXPIRED41. decoder 변경/별도 재현/재전송은 하지 않았다. 최종image provider-freshness-01df389ca6, 36stopped/child0/4모델READY/Artifact HTTP On. persistent freshness On/100ms, startup10초/steady2초, debug JPEG Off. 시험 채널 설정은 의미상 복귀했다. Gateway stopped/WSS disconnected: 기동 중 Stop 회수 안전성 확인 전 Web Start는 보류한다. ## 이전 복합 채널 단계별 계측 [측정 SOT](validation/20260926T170547+0900-validation-provider-scale-sot.md), [영역별 해석/종합](analysis/20260926T170547+0900-analysis-provider-scale.md). e74cc54에서 bounded histogram/전송 counter/renderer 시간 계측만 추가하고 Python3.12 표적39PASS. 1/2/4/8 각30초를 완료했다. 2→4에서 수락 저하,4→8에서 완료량도 감소했고8은99% 이상 응답폐기다. 16확장 중 누적10번째camera14 Pose 최초응답0/2초stall 뒤SIGTERM회수로 중단했다.16/17성능은 미측정이다. CPU 실행대기와Triton Queue/compute 증가를 함께 관측했지만CPU/GPU 기여율은 미확정이다. 자연Artifact83건 중6실패,그중3건 기존avdec_h264 assertion 재현.추가offline시험/decoder변경은 없다. 같은image provider-scale-d086494ab6로 정상재기동해sticky관리오류와시험설정을정리했다. 최종36stopped/child0/4모델READY/Artifact HTTP On,Gateway stopped/WSS disconnected로재유입보류. 기존설정의의미는복귀했고camera9~20에비활성Fire기본값이명시적으로남았다.원본은private backup보존. 후속성능후보는단일provider child의capture크기정합화이며미적용이다.16/17재개전startup-stall/회수경계도검토한다. ## 최신 provider process 운영 연결 [결정](decision/20260926T144835+0900-decision-provider-process.md), [실행 결과](runs/20260926T144835+0900-run-provider-process.md), [사용/재개 가이드](../../../../scenarios/PROVIDER_PROCESS_RUNTIME.ko.md). 사용자 승인으로 복합 채널은 provider별 child/독립 Decode, 단일 provider는 기존 process1개로 연결했다. camera/run 소유자와 fenced Redis writer는 하나이며, provider별 실제 Frame/PTS 메시지에 세 필드를 추가했다. Pose의 사람 시나리오/Tracking 공유와 provider-local capture/공통 Artifact 제한을 유지한다. image provider-process-9d6aedaed5, Python3.12 표적 검증과 2/3-provider/혼합30초 정상 회수 완료. 혼합 수락 Pose7.96/Fire8.89/Crowd9.43FPS, Medium10 합계47.84FPS로 공유 부하 저하는 남았다. 자연 FIGHT15건 Artifact READY/HTTP200, FIRE 자연 Event는 미발생이다. 최종36stopped/WSS연결/4모델READY/Artifact HTTP On, 원래 설정과 비대상 보존, 사용자 브라우저 확인 대기. 아래 native bulk 우선 후보/전면 보류는 이전 비교 당시 판단이며 이번 사용자 승인으로 우선순위가 바뀌었다. ## 최신 process 분리 비교 완료 [A/B/A 결과](runs/20260926T095733+0900-run-process-ab-comparison.md). 이전A오류는격리helper가source_id만변경한camera/source불일치였다. CPU재현후camera_id도동일별칭으로 맞춰관련2PASS, 실제A/B/재A각30초와정상회수를완료했다. 운영CROWD검증은완화하지않았다. 분리B에서Pose/Fire/Crowd수락9.11/9.81/9.88FPS로개선됐으나Medium10은65.46FPS로낮아졌다. A는80.20,재A는86.52FPS여서전면전환은보류한다. GIL단독원인/16채널90%폐기해결로표현하지않는다. 다음후보는single-decode유지와결과복사/검증native bulk경량화이며효과미검증/별도승인이다. pr13-process-compare-cdae6574d6와시험도구를유지하고운영분리default는변경하지않았다. 최종36채널stopped/WSS연결/4모델READY/Artifact HTTP On이며원본설정과비대상서비스를보존했다. ## 최신 child 수명 수정 / process 비교 [수정과 중단 기록](runs/20260926T093418+0900-run-process-ab-child-lifetime.md). 37b4613에서 요청thread 종료가 PDEATHSIG로child를 종료시키는 결함을 CPU fixture로재현하고, 기존supervisor가spawn부터reap까지소유하도록수정했다. parent-death보호는유지한다. 과거동시종료의원인으로는유력하지만당시signal기록이없어확정하지않는다. A(Medium10+Pose/Fire/Crowd)warmup에서combined가multi_provider_results오류를보고해중단했다. exit0/terminal_failed=true/forced=false이며Medium10은유지됐다. 이후11child정상회수, B는미실행으로process분리채택은보류다. 최종표적23PASS,추가fatal진단반영후GPU재시험없음. pr13-processdiag-f7679c23fb에수명수정/진단/명시적시험CLI를보존하며운영분리default는없다. 36채널stopped/helper회수/WSS연결/4모델READY/Artifact HTTP On으로마감했다. 다음은A최초failure의stall/exception구분후국소수정이다. Artifact는별도미해결상태를유지한다. ## 최신 Artifact 설정 비교 / 혼합 부하 [비교와 중단 기록](runs/20260923T173433+0900-run-artifact-and-mixed-load.md). dd5948a 기준 provider별 Frame/copy 계측을 분리하고 Python3.12 표적42 PASS. Artifact baseline/direct-rendering=false 각각6/6 성공으로 이번에는 실패가 재현되지 않았고 설정 변경 효과도 미입증이다. 운영 decoder는 변경하지 않았다. Medium10에 Pose/Fire를 추가하자 완료99.49->97.69FPS에 비해 수락95.16->61.86FPS, 폐기4.35->36.68%로 악화했다. 추론 전/Triton/copy wall 지연과 CPU runnable wait가 증가했다. CPU/GPU 지배 원인과16채널90%폐기는 미확정. Crowd 추가 warmup 중 child_exit로 중단, 모든 child/writer 회수를 확인했으나 정상 Stop 수용으로 표현하지 않는다. pr13-mixed-339141afa5는 진단 가능 image이며 decoder 해결 image가 아니다. 시험 overlay/진단On을 해제하고 원래35채널 설정을 보존했다. WSS 복구 후6채널이 재Start돼 한 번 Stop했으나 다시 실행됐다. 최종29stopped/6running이며 관제에서추가Start중단이 필요하다. 후속은 Crowd 기동 시 동시 child 종료 원인 확인, Artifact 실패 재현/diagnostic 확보다. ## 최신 PR13 전후 비교 / Artifact 실패 경계 [동일조건 비교와 재현 기록](runs/20260923T165500+0900-run-pr13-ab-and-artifact.md). PR13 직전PR12 image 핵심파일hash를0a08564와 대조하고, 별도 설정 사본에서 기존Medium10채널을 양쪽각30초 비교했다. 완료FPS합계100.07→99.19,복사wall20.26→20.66ms로 큰 처리량 회귀는 재현되지 않았고 PR13 수락폐기는약5.2%였다. 이전혼합16채널90%폐기의CPU/GPU 원인은미확정이다. FIRE 외 camera5 INTRUSION도Artifact실패를 확인했고,저장입력4개동시offline렌더에서 avdec_h264 프레임폭 assertion/SIGABRT 및decoder error를 재현했다. 최종근본원인/수정은후속이다. Python3.12 표적39 PASS. 시작image pr13-timing-44d56eed3f와전체Compose/env/원본설정으로복귀, 35채널stopped/reap,WSS연결,4모델READY,Artifact/HTTP On. 새진단코드는worktree/image후보에만있고 최종운영반영은없다. instance/batch/FPS/deadline·native최적화·process분리변경0. ## 최신 PR13 지연 계측 [계측/검증 기록](runs/20260923T143134+0900-run-pr13-provider-timing.md). 사용자 승인으로 bounded timing/rejection 계측만 추가하고 Python3.12 표적23 PASS, image pr13-timing-44d56eed3f를 반영했다. 기존 running 3/5/6/8의 설정을 유지해 30초 관측 후 35채널 stopped/reap, WSS connected, 4모델READY, Artifact/HTTP On으로 마감했다. 3번 Pose/Crowd의 callback 복사/검증 평균20.51/30.85ms, callback 진입 후100ms 초과21/22건을 확인했다. CPU thread 실행 대기는 채널별 확인됐지만 CPU/GPU 지배 원인과16채널 성능은 미확정이다. 최적화·instance/batch/FPS/deadline 변경은 하지 않았다. 다음은 SDK 수명/검증을 보존한 결과 변환 구간과 Frame eviction 분석이며, 기존 HTTP400 문제는 별도다. ## 최신 PR13 native crash 수정 / 최소 GPU 수용 [수정/검증 기록](runs/20260923T122048+0900-run-pr13-frame-wrapper-fix.md), [새 Web tuning 가이드](../../../../scenarios/SCENARIO_TUNING_GUIDE.ko.md). task fe6e94c 기준, SDK iterator가 빌려주는 FrameMetadata wrapper를 list로 보관한 뒤 읽던 두 지점을 순회 중 owned FrameEnvelope 복사로 변경했다. native crash 주소의 SDK symbol과 회귀 fixture가 일치하며, Python3.12 표적21 PASS 및 Pose/Fire 단독과 2/3-provider 실제 결과를 확인했다. 새 image pr13-framefix-84437c345c, RTSP1/decoder thread1/provider thread3, Redis Frame/PTS 증가와 Pose/CROWD 혼합 metadata 확인. 모든 시험 정상 Stop/reap. 4모델READY/29채널stopped/Gateway running/WSS connected/Artifact On HTTP On이다. 시험 설정은 CAS로 원래 configured revision까지 복구했으며 모델/threshold/SDK 변경은 없다. 자연 FALL4건의 Artifact READY이나 HTTP400 INVALID_PARAMS 전송 거부가 남았다. Start/metadata 시험은 준비됐지만 Event 수신 성공이나 실제 브라우저 수용은 완료로 표현하지 않는다. 느린 분기 GPU 지연 주입·EOS·다채널 부하는 미실행. 아래 실패 evidence는 당시 기록이다. ## 이전 PR13 test 통합 / GPU 중단 [결정](decision/20260923T111525+0900-decision-pr13-integration.md), [실행/재개 기록](runs/20260923T111525+0900-run-pr13-integration.md), [새 Web tuning 가이드](../../../../scenarios/SCENARIO_TUNING_GUIDE.ko.md). PR13 e514252를 task 0a08564 worktree에 통합하고 독립 queue/native completion relay, FINALIZING/Stop, FIRE gap, public300 참조/대표 보존을 보완했다. Python3.12 표적108 PASS (18 subtests, 1 deselected), Web22 PASS, 마지막 변경45 PASS를 확인했다. 합산은 중복이다. 새 Analytics pr13-5d42cb8e3a 반영/4모델READY까지 확인했지만 camera3 Pose+Fire 첫 결과 전 ServiceMaker native segmentation fault로 child가 종료됐다. 근본 원인은 아직 미확정이다. 입력 probe는1회 성공, 3-provider는NOT RUN. 다른 카메라 변경/동일 시험 재시도는 하지 않았다. child reap/writer release/25채널stopped, 임시 FIRE/시간 anchor CAS 정리와 원장 불변 확인. Analytics/Sidecar running, Gateway maintenance stopped, WSS disconnected, Artifact/HTTP On이다. 브라우저Start-ready가 아니며 .101 새 schema 적용도 미확인이다. image/config 자동rollback은 없다. 재개는 이 image와 원장/PID 확인 후 SDK crash 경계부터 진행한다. 아래 과거 READY는 당시 기록이다. ## 최신 아이서티 관제 재로그인 [수동 가이드](../../../../deployment/ICERTI_LOGIN.ko.md), [실행 기록](runs/20260921T155217+0900-run-icerti-login.md). 기존저장계정의로그인401 이후동료의비밀번호변경사실을사용자가확인했다. 새비밀번호로승인된1회로그인/TLS/세션저장은PASS, 현장private값과세션정합/Sidecar ready200확인. 관제의WSS연결은90초내미확인이며추가로그인은하지않았다. Analytics/카메라/test Runtime은변경하지않았다. 인증정보는문서/Git에저장하지않으며반복로그인대신관제측연결확인이후속이다. ## 최신 test FALL/FIGHT 시연 기본값 [결정](decision/20260921T131002+0900-decision-demo-sensitivity.md), [반영/중단 기록](runs/20260921T131002+0900-run-demo-sensitivity.md), [재개 완료](runs/20260921T132016+0900-run-demo-resume.md), [사용/복귀 가이드](../../../../scenarios/SCENARIO_WEB_READY.ko.md). PR12 d20aca8을 현재640acd4에 통합했다. FALL direct-down On, FIGHT fallback Off, 각2초 PTS cooldown과 낮춘 Runtime 기본값을 적용하고 Python3.12 표적199개 PASS. 기존 FALL6/FIGHT2 설정만 CAS로 변경했고 명시적 skip-hold Off5개는 보존했다. 새 Analytics의4파일hash/모델4종ready/24채널설정을 확인했지만 Gateway 재개 뒤 전체stopped Gate가 실패했다. cameraId1의 FALL confidence가 Web 값0.60으로 다시 저장된 동시 요청 정황을 확인했다. Gateway/Analytics는exit0으로 회수했으며 자동 재기동/rollback은 없다. 이후 사용자 전체Stop 확인과 재개 승인으로 같은image의Analytics/Gateway만 기동했다. 모델4종READY/WSS연결/Artifact On/HTTP On/24채널stopped를 확인해 브라우저Start 준비를 완료했다. 기존Event원장/비대상컨테이너보존, 재빌드/설정재적용/카메라Start는없다. Web의명시confidence는보존하며 시연에서는FALL/FIGHT0.15를사용자가지정한다. 실제영상수용은대기다. 아이서티는 이번에 변경/재조회하지 않았다. 아래 capsule의 기본값/수용 상태는 각 시점 기록이다. ## 최신 독립 영상 클립 도구 [사용 가이드](../../../../../tools/VIDEO_CLIP_GUIDE.ko.md), [결정](decision/20260921T112204+0900-decision-video-clip.md), [검증](runs/20260921T112204+0900-run-video-clip.md). PR11을 단일 구간 MP4 제작 도구로 통합했다. 기본CPU/H.264/reencode·오디오 제거·원본timing 유지, 기본출력 입력폴더/clips, 명시적 출력폴더 지원. 원자적 덮어쓰기 보호와 cgroup/잠금/취소를 보완했다. Python3.12 표적28 PASS, 실제 synthetic copy/reencode 각1회 PASS. AI Runtime/RTSP/현장 변경은0이다. 원본 경로·시작초·길이를 받으면 사용 가능하며 RTSP URI 생성/반복 송출과 사용자 영상 수용은 후속이다. ## 최신 현장 증분 반영 [현장 기록](runs/20260921T104408+0900-run-icerti-incremental.md), [증분 계약](decision/20260921T104408+0900-decision-icerti-incremental.md), [현장 가이드](../../../../deployment/ICERTI_INCREMENTAL.ko.md). 침입/배회/FIRE/FALL/FIGHT/CROWD source/native를 기존 현장 base image 위에 반영했다. Medium 재사용, Pose/Fire/CROWD Blackwell 변환·batch1~4 shape/dtype/finite PASS. 모델4종 instance8/batch4/5ms READY, idle VRAM4778/24467MiB이며 부하 시험은 아니다. WSS bootstrap, Redis reader/관리명령 차단, Artifact On/HTTP On, 3채널 stopped 확인. FALL 현장 기본은DOWN 대기 생략On, 공용 기본Off와 명시적 채널Off를 보존한다. 인증/원장/비대상 서비스 보존. 실제 카메라Start/Event/브라우저 수용은 사용자 시험 대기다. 기존 FULL과 실패 증거는 보존하며 아래 capsule은 각 시점의 기록이다. ## 최신 FIGHT/CROWD Web 준비 [통합 결정](decision/20260920T231430+0900-decision-fight-crowd-wire.md), [반영 기록](runs/20260920T231430+0900-run-fight-crowd-web-ready.md), [사용 가이드](../../../../scenarios/SCENARIO_WEB_READY.ko.md). PR9 임시 FIGHT와 PR10 CROWD를 통합했다. FIGHT는 Pose/Tracking 공유·독립 ROI/pair Event, CROWD는 신규512 모델 단독·Tracking/Event/Artifact 없이 P/H 숫자 표시다. Python3.12 표적145+새 연결7 PASS, native26 assertions, 공식 후처리200행 수치 일치, 512 GPU 정규화/pitch/FP16 검증 PASS. Analytics/native·Sidecar·Gateway와 새 모델 mount 반영. 모델4종 READY, WSS 재연결, Artifact On/HTTP On, 22채널 stopped와 기존 원장·비대상 컨테이너 보존. 실제 카메라Start/시나리오 정확도/브라우저 overlay는 미실행이며 사용자 수동 시험 대기다. FALL 보정과 복수 모델 실행은 보류하며 기존 시험 옵션을 보존했다. 이하 capsule은 당시 기록이다. ## 최신 신규 사람·머리 모델 후보 [변환 기록](runs/20260920T223620+0900-run-awiros-person-head-candidate.md), [후보 사용 가이드](../../../../deployment/AWIROS_PERSON_HEAD_CANDIDATE.ko.md). 사용자 업로드 RF-DETR-S weight를 공식 revision/hash와 대조해 새 원본으로 변환했다. 기존 동일 모델 weight/engine은 재사용하지 않았으며 승인 tooling/읽기 전용 export 환경만 재사용했다. 512x512 dynamic ONNX, A6000용 TensorRT10.16 FP16입력/FP32출력·batch1/4/4 후보 생성 완료. 원본487 tensor 일치·ONNX checker·engine 역직렬화·batch1~4 shape/dtype/finite PASS. 기존 컨테이너 보존, 모델 등록/시나리오 연결/현장 배포는 하지 않았다. 성능·정확도는 사용자 시각 검증 대기다. 아래 FALL 시험 capsule은 당시 기록이다. FALL 추가 민감도/Tracking ID 단절/빨강 유지 보완은 사용자 결정으로 보류됐으며 임시 옵션은 자동 원복하지 않았다. ## 최신 FALL 임시 시험 옵션 [반영 기록](runs/20260920T214915+0900-run-fall-skip-hold.md), [사용/원복 가이드](../../../../scenarios/SCENARIO_WEB_READY.ko.md). `fall.test_skip_down_hold` 기본 Off, cameraId 3만 명시적 On/person_score 0.30으로 저장했다. 선행 UPRIGHT/TRANSITION과 현재 DOWN 조건을 유지하며 DOWN_CANDIDATE 진입 Frame에서만 0.7초 대기를 생략한다. episode 1회/재무장/ROI/Frame 정합과 public schema는 유지한다. Python3.12 표적 20개 PASS. Analytics만 교체, Pose READY/WSS 연결/Artifact On/HTTP On, 22채널 stopped, 다른 컨테이너와 기존 Event 원장 불변. 실제 Event 시험은 사용자 수동 Start 대기다. 임시 옵션은 `RETAIN`: 3번 Event 연결 시험 종료 피드백 시 stopped 상태에서 Off로 RESET한다. 낙상 정확도 수용이 아니며, 오탐 위험 증가와 선행 조건 미충족 시 Event 없음은 그대로다. 이하 capsule은 각 시점의 기록이다. ## 최신 FALL Web 준비 [FALL-WIRE-01](decision/20260920T210000+0900-decision-fall-wire.md), [통합·반영 기록](runs/20260920T210000+0900-run-fall-web-ready.md), [사용 가이드](../../../../scenarios/SCENARIO_WEB_READY.ko.md). PR8 core를 보존해 통합하고 FALL ROI/Settings/Web/공통 Event/Artifact를 연결했다. FALL 포함 시 Pose 하나와 Tracking1회를 침입/배회/FALL이 공유한다. confidence와ROI/상태/UUID는독립이다. 96개core 및 Pose/연결보호 표적검증PASS. 결과worker fixture의계측오류2종은교정후3개PASS. Analytics/Sidecar 새image 및 Gateway 반영, Medium/Pose/Fire READY, WSS bootstrap4개·heartbeat2회PASS. 등록21개stopped, Artifact On/HTTP On·worker8idle·생성0·예약0. Event2732건/attempt1673/fingerprint불변. 비대상15컨테이너ID/image/기동시각보존. 실제FALL카메라Start/영상/Event시험0, 사용자브라우저Start대기. FIRE는단독유지, 사람/Pose+Fire는보류. 아이서티/FALL실제정확도/16채널/성능은이번미검증이다. ## PR6/7 사용자 시험 수용 보충 직전 대화에서 사용자가배회·침입/배회·화재의4채널시각화와Event발생을확인했다. 당시읽기전용확인에서4채널running/queue0/실행오류없음, 짧은5초결과약9.89~10.05FPS, 각시나리오Artifact READY/SENT/HTTP200을확인했다. 미지원FIGHT는skip기록이며실행하지않았다. 이후전체Stop과한채널재Start/재Stop에서정상child/writer회수·강제종료없음을확인했다. 이것은이전대화의최소수용근거이며이번새시험이나장시간성능/오탐미탐검증으로표현하지않는다. ## 최신 test 시나리오 Web 준비 [SCENARIO-FANOUT-01 결정](decision/20260920T184100+0900-decision-scenario-fanout.md), [반영·표적 검증](runs/20260920T184100+0900-run-scenario-web-ready.md), [사용 가이드](../../../../scenarios/SCENARIO_WEB_READY.ko.md). 승인 PR6/PR7을 worktree에 통합하고 같은 Medium 결과의 INTRUSION+LOITERING fan-out, 독립 ROI/상태/Event와 FIRE 단독 Web 전환을 보완했다. Python3.12 표적 검증 및 보호 검증PASS. Analytics/Sidecar image와 Gateway template 반영, Medium/Fire READY, WSS 재연결/bootstrap4개PASS. 등록19개 모두stopped, Artifact On/HTTP On, worker8 idle/생성0/예약0. Event2606건·시도1547·원장hash 불변. SSIMS·공유DB/Redis 등 비대상 컨테이너는ID/image/기동시각 불변. 카메라Start·실제Event시험0. 사용자가 준비한3종 채널의 cameraId 전달 및 브라우저Start 대기다. Person/Pose+Fire는 미지원 조합으로 명시 거부하며 선개발composer는 미연결이다. 아이서티/FALL 작업과 과거EOS/FPS분석은 변경하지 않았다. 이하 현장3채널running capsule은 당시 관측이며 현재 현장상태를 재확인한 기록이 아니다. ## 최신 현장 3채널 관측 [60초 최소 관측](runs/20260920T124545+0900-run-site-fps-observation.md). 현재3채널running을 유지한 채 기존API13snapshot만 수집했다. 입력19.76~19.90, 선택9.13~9.20, 결과9.13~9.20, Redis8.88~9.07FPS. 샘플 queue0, 실행오류/계측누락0. 관측 범위에서 선택 이후 처리량 부족은 확인되지 않았지만10FPS 수용/전체 AI 무결함을 주장하지 않는다. 개별PTS간격·빈선택칸·송출/네트워크/decoder 책임은 미확정. 추가 조합시험 없이 이번 관측 마감 권고. 채널/Artifact/서비스 설정 변경0. 이하 최초배포의 카메라0/시험대기는 당시 상태다. ## 최신 현장 최초 반영 [현장 배포·로그인·발급·WSS 수용](runs/20260920T115833+0900-run-site-bootstrap.md), [현장 bootstrap 가이드](../../../../deployment/SITE_BOOTSTRAP.ko.md). 검증된 Medium r02로 첫 FULL 배포를 완료했다. 기존 image/FULL/engine을 재사용하고 containerd manifest/config ID 연결 검증과 preloaded load 생략만 보완했다. 표적19개 PASS. 서비스5개running, Medium version1/instance8/batch4/5ms READY, 등록/실행카메라0, Artifact On/HTTP On. 승인 CA로 TLS/로그인/발급 성공, WSS bootstrap4개와 ping3/pong3 PASS. Redis reader인증/관리명령거부 PASS. 실제 관제Redis 소비·카메라Start/Stop·Event/영상 수용은 미실행이다. 다음은 브라우저 한채널 시험이다. test Runtime/SSIMS/관제서비스는 변경하지 않았다. 이하 준비/실패 capsule은 선행 기록이다. ## 최신 현장 모델 설정 보완 [소형 패치·표적 검증](runs/20260920T103510+0900-run-model-config-repair.md), [현장 수동 보완 가이드](../../../../deployment/MODEL_CONFIG_REPAIR.ko.md). 현장 engine 변환은 사용자 evidence상 성공했지만 Triton 설정 output 마지막 쉼표로 smoke가 실패했다. 생성기·실패 stderr 로그 보존·원본 보존 새후보 migration을 보완했다. 표적26개와 실제 protobuf12설정 PASS. 기존 FULL과 engine은 재생성하지 않는다. 현장 root 원장은 sudo 제한으로 직접 재조회하지 못했으며 현장 적용 도구가 해시를 다시 확인한다. 실제 현장 쓰기/재검증은 사용자 수동 단계 대기다. SSIMS4채널은 사용자가 복구·정상을 확인했다고 전달했으며 별도 조작하지 않았다. ## 최신 배포 세트 준비 [FULL export 완료·유지보수 기록](runs/20260920T002301+0900-run-full-export.md). 승인된 Docker 재시작1회로 daemon 임시 경로를 별도 디스크에 두고 이미지6개와 FULL163파일을 묶었다. 약12.91GiB archive의 모든 member hash/size/path 검증PASS, 루트 최저25.397GiB. 기존18컨테이너는 같은ID/image/restart policy로 복구했다. rtsp-repeter만 별도 승인된 강제종료1회; SSIMS4채널은 사용자 수동복구 대기이며 자동Start/영상검증은 하지 않았다. 임시설정은 현부팅 RETAIN, 재부팅 시 소멸한다. 대상 설치/GPU변환/인증 수용은 여전히 대기다. 아래는 최초 준비 당시 기록이며 FULL 보류는 이번 완료 기록으로 해소됐다. [현장 읽기 전용 확인·통합·부분 산출물](runs/20260919T152500+0900-run-deployment-kit-preparation.md), [현장 사용/승인 가이드](../../../../deployment/LOCAL_PREPARATION.ko.md). 후보 fb1b329를 기준80ad438 worktree에 통합하고 최초 설치 재개 소유권·모델 노출 일치·출력/진단· 현장 LAN 설정을 보완했다. 실제 대상은 최신 드라이버와 Docker가 있지만 NVIDIA runtime 연결과 관리자 적용이 필요하다. 대상 쓰기/설치/변환 및 test Runtime 변경은0이다. FULL 이미지 export는 daemon 루트 staging 여유 위험으로 보호선 전에 중단했으며 재시도하지 않았다. 도구·세 모델 ONNX·tooling image·private 설정 초안과 부분 원장은 보존했다. 설치 수용 완료가 아니다. ## 최신 내부망 파일 조회 [SECUREBRIDGE-06 반영·검증](runs/20260918T164819+0900-run-media-lan-public.md). Gateway의 lan_public 기본값으로 승인 LAN만 클립/썸네일 무토큰 조회가 가능하다. HTTPS·파일 경로·제어 인증 유지, 외부/위조헤더 차단을 확인했다. Gateway만 반영했고 Analytics/Sidecar/Redis/채널 PID와 run을 보존했다. WSS 재연결 정상이며 브라우저 CA/재생은 별도다. ## 최신 Event 전용 주소 변경 [반영 기록](runs/20260918T155808+0900-run-event-endpoint-http.md). 사용자가 지정한 관제 HTTP Event 경로를 private env에 반영하고 Sidecar만 교체했다. 표적11개/Sidecar auth readiness PASS, Analytics·Redis·채널 state/PID/run은 보존했다. 로그인/인증/WSS/Artifact URL은 HTTPS 유지. 실제 새 주소의 Web 접수는 별도 미확인이다. 아래 all-stopped는 이전 반영 직후 기록이며 이후 사용자 Web Start를 취소하지 않았다. ## 최신 Web 시험 직전 상태 [반영·정상 Stop/reap·관측 대기](runs/20260918T151156+0900-run-web-start-reflected.md). 승인된 후보 Analytics image와 template/Artifact On을 실제 반영했다. 기존1채널 정상 Stop/reap, 등록18개 모두 stopped이며 자동 재Start는 하지 않았다. Sidecar/Gateway/모델/공유서비스는 보존했다. readiness와 Artifact worker8 idle 확인. 기존 만료45건 예약은 서비스 복구 정책으로 반환됐으며 원장969건/전송시도합92는 동일하다. 최신 사용자 요청에 따라 모니터링과 Web 시험은 시작하지 않았다. 활성 구성은 private candidate.env + web-start overlay까지 포함한다. 기존3개 overlay만으로 재생성하지 않는다. 다음은 사용자 시험/관측 시작 요청 대기다. 아래 준비-only 상태는 선행 기록이다. ## 최신 Web Start 사전 준비 [SECUREBRIDGE-05](decision/20260918T145744+0900-decision-web-start-preparation.md), [준비·검증·현재/후보 구분](runs/20260918T145744+0900-run-web-start-preparation.md), [반영 가이드](../../../../integration/WEB_START_PREPARATION.ko.md). 신규 등록 template·ROI 누락/null/빈 배열 정규화·운영 Artifact On 후보와 Analytics image를 준비했다. 표적22개/최종image 소스·최소계약/Compose 차이 검증PASS. Runtime 교체나 실제 카메라/POST 시험은 하지 않았다. 관측 시작 시 기존한채널running/Artifact Off이며 과거 두채널 기록을 자동복구하지 않았다. 시험 종료는 Artifact Off 명령이 아니다. 별도 요청 없으면 후보 반영 이후 On을 유지한다. 새 관제 Redis 접근은 앞선 별도 승인/사용자 확인으로 완료됐고 이번에는 반복 적용하지 않았다. 기존 Event와 실제/persistent 설정은 보존하며 후보는 별도 private 경로다. 아래 내용은 과거 단계다. ## 최신 실제 WSS 수용 [실제 반영·관제 READY·최종 상태](runs/20260918T131803+0900-run-secure-wss-runtime.md). 동료 관제 로그인 수정 뒤 로그인/CSR 발급/서명 검증이 성공했고 준비한 Analytics/Sidecar/Gateway를 반영했다. 최초 login->WSS 실패는 replace 경로에서 재시도하지 않는 실제 관제 동작이었다. 동료 재기동 뒤 실제 Manager bootstrap4개/heartbeat와 관제 READY를 확인했다. 초기403 4회와 최종 성공을 구분한다. 기본2채널 정상 Stop/reap 후 새image에서 첫Frame·독립PID,20.07초 결과/Redis각10.02FPS·queue0·stale/drop증가0. 기존 Event 원장 불변, Artifact Off/HTTP On, 나머지16등록 stopped. 무인증 외부REST401 확인. 실제 Web REST Start/Stop·HTTPS media·새Event·브라우저 시각화는 미확인이다. 새 관제는 기존 Redis 허용IP 밖이므로 bbox소비는 별도 승인/확인 필요. ACL은 변경하지 않았다. 임시 neighbor는 유지하며 근본 네트워크 정비는 별도다. 아래 로그인 BLOCKED는 선행 단계 기록이다. ## 최신 Secure WSS 재개점 [SECUREBRIDGE-04](decision/20260918T130122+0900-decision-secure-bootstrap.md), [실행·검증·이미지 기록](runs/20260918T130122+0900-run-secure-wss-prepared.md), [최초 인증 가이드](../../../../integration/SECURE_BRIDGE_PROVISION.ko.md). 승인된 단일 neighbor 임시 고정 후 SSH host key/관제 CA 지문/HTTPS 검증은 통과했다. 첫 로그인은 관제 ServerSettings.streamingEnabled NULL -> boolean 변환 오류로 실패했다. 동료 수정 대기이며 로그인 반복·CSR POST·Runtime 반영은 하지 않았다. 원격 설정/서비스는 읽기 전용으로 보존했다. AI 로그인/CSR CLI·최소 WSS·bounded auth 복구/상한·session 인계는 source와 후보image로 준비했다. 초기32/영향22/최종image5 표적검증PASS(중복 포함), 실제 Manager 수용·Gateway 기동은 대기다. 기존 secure-rest image와2채널running·Artifact Off/HTTP On 유지, 새 후보는 미반영이다. 근본 ARP 문제는 미해결이며 임시 neighbor는 RETAIN·재부팅 영구 설정 없음. 제거/원장 값은 private에 있다. 다음 최소 작업은 관제 오류 수정 완료 뒤 같은 후보로 로그인/발급·실제 WSS/REST 확인을 이어가는 것이다. 이하 과거 capsule의 BOOTSTRAP_INPUT_WAIT/WSS 미구현 설명보다 이 절을 우선한다. ## 최신 인증서 준비 도구 [검토·실행 기록](runs/20260918T112819+0900-run-certificate-provision.md), [최초 준비 가이드](../../../../integration/SECURE_BRIDGE_PROVISION.ko.md). 시작 local cc6f8f2 clean과 문서4개 commit/push completed_exact를 확인했다. 동료 branch9ed210c의 provision 스크립트는 CA 설치/기존 Sidecar 로그인 확인용이며 인증서 서명·계정 발급·WSS 구현 도구가 아니다. 원본은 CA 출처 부족으로 사전검사 종료. 현재 env에 Manager/bridge 값이 없고 private 폴더에는 내부 control-token만 있었다. 현재 경로 AI_BRIDGE_SECRET_ROOT와 기존 TLS/Config에 연결한 host 점검·CA 설치 도구를 추가했다. 오프라인 보호 검증7개PASS. 실제 CA 설치·로그인·WSS·build/재기동0. Analytics 기존image/두채널running·Artifact Off를 유지했다. 다음은 실제 Manager 주소·계정·승인 CA/CSR 서명 경로를 받아 최초 연결을 준비하는 것이다. Token은 시간 만료가 없어도 폐기될 수 있으며 WSS 재접속 자체와 수명은 별개다. 관제의 검증 미구현을 AI 인증 생략으로 해석하지 않는다. WSS/복구/상한은 아래 합의대로 미구현이며 아래 이전 snapshot을 현재 완료 사실로 확대하지 않는다. ## 최신 질답·Compaction 재개 계약 먼저 [SECUREBRIDGE-03 결정·구현대기·필수준비물](decision/20260918T110708+0900-decision-secure-wss-minimum.md), [재개 가이드](../../../../integration/SECURE_REST_BRIDGE_HANDOFF.ko.md)를 읽는다. 현재 local de02add가 기준이며 PR4/동료 개정 코드 확보를 선행조건으로 요구하지 않는다. 얇은 Sidecar에 최소 WSS bootstrap4개/heartbeat만 추가한다. Start/Stop은 REST·SUCCESS는 접수 성공으로 확정했다. AI token은 HTTPS 로그인 발급, Manager token은 Web이 요청에 첨부한다. WSS는 secret/CA 자동배포 통로가 아니다. reload/refresh 관리 action·configuration.apply·외부 polling/UI 고도화는 보류한다. 일시적 로그인 실패는 최대 약60초 저빈도 재시도, HTTP 상한32/pool40/Uvicorn64·Nginx1은 합의됐으나 아직 미반영이다. 필수 접속 정보는 실제 Manager HTTPS 주소·AI 계정·승인 CA/AI 인증서 발급 경로다. 나머지 설치/진단 준비는 AI 쪽에서 처리한다. 작성 시 read-only 확인: 두 채널 PID594/454 running, 등록18개 중 나머지16개 stopped, Artifact Off/HTTP On/worker0. image는 secure-rest-b644461-9d617905 유지. 이번 변경은 문서뿐이며 기동·build·POST·DB 변경0이다. 기존 성능과 Event 원장 건수는 아래9월17일 근거이며 반복 측정하지 않았다. 아래 절의 과거 질문보다 이 절을 우선한다. ## Secure REST 내부 준비·두 채널 수용 [SECUREBRIDGE-02](decision/20260917T212657+0900-decision-secure-rest-internal.md), [실행·검증 기록](runs/20260917T212657+0900-run-secure-rest-two.md), [인증 준비·내일 확인할 질문](../../../../integration/SECURE_REST_BRIDGE_HANDOFF.ko.md). PR #4 후보da0149b를 현재b644461 worktree에 commit 없이 통합했다. bounded 접수 SUCCESS, 내부 operation 지연실패 조회·동일 synthetic Anchor 보존·Compose 연결을 보완했다. 새image `secure-rest-b644461-9d617905`·내부 인증 경로가 actual/persistent에 반영됐다. 표적31개PASS. helper의 revision 동일성 오인으로 정상정지 후 helper만 교정하고 같은image 추가확인1회. camera2/1 첫Frame·camera2 정상Stop/reap/재Start,21.21초 결과10.09FPS/Redis10.04·10.00FPS, 결과queue/stale/drop0. 최종두채널running,Artifact Off/HTTP On·worker0·원장969건/예약45건 불변. 다른14개/비시험등록/sample01 stopped. 모델·Redis·비대상container 보존, rollback/새Event POST 없음. Sidecar/Gateway는 실제HTTPS/CA/계정 미설정으로 미기동이며 Web인증·WSS·보호된파일조회는대기다. 사용자시각화응답은대기이며기존Redis시각화와새HTTPS연동을구분한다. 다음은인수문서의네가지계약확인이다. 이하절은당시기록이며현재상태는이절을우선한다. ## 기본2채널 유지·Event 단계 마감 [두 채널 기동·Artifact Off 근거](runs/20260917T173527+0900-run-artifact-off-two.md). 사용자 승인으로 기존image `artifact-parallel-aeae108-418e5ca3`를 재사용해 Analytics를 기동했다. camera2/1만 Medium·Tracking/INTRUSION On running, Artifact 접수/생성/POST Off, 기존 파일 HTTP On이다. 첫Frame/독립PID/Artifact worker0과 원장 전체행 불변을 확인했다. 추가14개·비시험등록·sample01은 stopped로 유지한다. 모델·등록·ROI·Anchor 변경과 새 성능시험은 없다. Event969건/미전송49건/예약45건은 그대로 보존한다. Off에서는 만료/recovery도 실행하지 않는다. 실제 기존clip HEAD200 확인은 영상전체GET 또는 Web시각화 수용과 구분한다. cooldown·worker/codec 최적화·16채널 비교는9월목표 이후로 보류하고 배포세트·반자동화 준비로 이동한다. 기능 단계마감이며16채널 성능 수용이나 낮은Event 빈도 안정성 보장은 아니다. 이하절은당시기록이며현재상태는이절을우선한다. ## Artifact 채널별 claim·병렬 처리와16채널 중단 [EVART-02](decision/20260917T162151+0900-decision-artifact-parallel.md), [실행·FPS·worker·원장·정지 근거](runs/20260917T162151+0900-run-artifact-parallel-sixteen.md). 사전 승인 정리 뒤Event/예약0에서 시작했다. 생성4/전송4 worker, 채널별생성1개, 전체예약64/채널8, 원자적예약counter/claim,30초신규우선/120초만료/오래된미실행교체를 구현했다. 같은PTS Metadata Frame만 출력하고 원본 PTS/마지막Frame duration을 유지한다. 생성·전송 상태/예약을 분리한다. 표적17개와80GiB warning 보완1개PASS.16개 첫Frame/PID 확인 뒤 정식7.684초 구간에서 결과6.51~8.98/Redis6.77~8.96FPS·queue최대7·stale3으로 중단,60초수용 미완료다. 실행 전체Artifact164개완성/473대기교체/276보호슬롯접수제외.기본2개HTTP200 accepted92건 중URL있는것42건. Runtime GET은 정지 뒤 연결거부로미확인.실행worker peak8/실제생성peak4.16child 정상회수·강제0. 최종image `artifact-parallel-aeae108-418e5ca3`는80GiB 경고노출만 실측image에 추가했으며 create/no-start/PID0. 모든채널stopped,ArtifactOn 설정은실패계약대로보존.미전송49건·예약45건·파일보존,claim0. 다음기동시기존120초기한유지/만료자료POST없음.다음은동일8/8입력ArtifactOff단일확인이다. 이하절은당시기록이며현재상태는이절을우선한다. ## AI-01·Web 접수 성공, Artifact 상한 중단 [최신 실행·보류·Web 접수·Capacity 근거](runs/20260917T135527+0900-run-event-ai01-acceptance.md). 등록18개/preset17개/배정 원장의 serverId를 AI-01로 영구 통일했다. camera2/1과 나머지 설정은 보존했다. 이전 미전송16건은 exact-row CAS로 HELD, 원문/시도/파일 보존 및 재기동 후 미전송을 확인했다. 새 자연 Event로 두 채널 모두37.48초 내 HTTP200/accepted1 접수 성공, 동일image76cb7089를 재사용했다. 성공 뒤 두 채널 유지 중 마감 확인에서 Artifact PENDING_CAP이 발생해 정상 Stop/reap/Analytics exit0으로 정리했다. 활성 예약49개와 HELD 예약15개가 기존 작업수64개 상한에 포함됐다. 유일 원인/처리율은 미분석이다. 최종 새Event135건 중 Web 접수31건, 미전송104건을 보존했다. 기존 HELD16건은 그대로다. AI-01/ID/image/config는 되돌리지 않았다. trial16/sample01 stopped, Redis/PostgreSQL 유지. 다음은 Artifact admission의 HELD 예약/활성 작업수 계산과 생성 대기 점검이다. 임의 재기동/상한확대 금지. Web 실제 시각화와 처리량/지속운용은 미검증이다. 이하절은 당시 기록이며 이절이 현재 상태를 소유한다. ## 두 채널 ID 변경·Web 서버 식별자 확인 [최신 실행·응답 근거·성능 한계](runs/20260917T133718+0900-run-event-web-camera-ids.md). web-cam08-test=2, web-cam01-test=1을 등록·persistent 설정·preset·배정 원장에 영구반영했다. 나머지14 trial/비시험2등록 및 과거77/78 Event18개는 보존했다. 실패해도ID를되돌리지않는다. 보완image76cb7089를actual/persistent 반영했다. 두 채널 새자연Event21개, camera2 media GET200, Web5건각1회 HTTP404/SERVER_NOT_FOUND·retry0으로조기중단했다. 문서밖 최상위필드는없으며 기존시험용 serverId가 Web에서조회되지않는문제다. 정상60초 결과/RedisFPS·CPU영향은미측정. 기동포함결과참고10.10/9.99FPS·stale/drop0이다. 두 child 정상회수/강제종료0, Analytics·trial16·sample01정지. Redis/PostgreSQL은유지한다. 새미전송Event16개는원장·파일에보존됐고Analytics재기동시처리재개가능하므로임의Start금지다. 다음은Web등록AI serverId와송신매핑확정이다. pending처리방향도재기동전에정한다. 이하절은당시기록이며현재값은이절을우선한다. ## Event·Artifact·Web 연결 [EVART-01 계약](decision/20260917T123200+0900-decision-event-artifact-web.md), [실제 결과/정지 상태](runs/20260917T123200+0900-run-event-artifact-web.md), [사용·진단·재개](EVENT_ARTIFACT_OPERATIONS.ko.md). 시험16등록을 정수77~92/두 Web 입력8·8로 재편했다. 두 원래 Web 채널만 Medium/Tracking/INTRUSION On 시험했다. 자연 Event18건 모두 Artifact READY, 두 채널 clip/thumbnail GET200. Web POST는18건각1회 HTTP404로 미수용이다. 정상window FPS는 조기중단으로 미측정. 과거bbox 재사용 없이 누락/부분clip을 기록한다. 16 trial·sample01 sender·Analytics 정지, 정상 child회수/Analytics exit0. Redis/PostgreSQL·파일·원장 보존, code/image/config 자동복원0. 실제 관측image df35a861은 stopped container/Compose에 남는다. 후속 작은 보완image76cb7089는 image-owned 표적 검증만 완료했고 아직 반영하지 않았다. 다음은 Web POST route404 확인 뒤 보완image에서 두 채널 최소 접수 확인이다. 실패Event 자동재전송은 하지 않는다. 이하절은 당시 기록이며 현재상태는 이절과 최신run이 우선한다. ## Fire16채널·세 모델 batch8 후보 준비 [반영·Fire16 결과·후보검증·유지 상태](runs/20260916T230000+0900-run-fire-batch8-candidates.md), [batch8 보관·전환/복원 가이드](BATCH8_CANDIDATES.ko.md). 기준6367102. Fire version4 FP16입력/FP32출력·CUDA sharing On·instance8/batch4/5ms를반영했다. 공통입력계약의Fire항목만변경하고기존Medium/Pose engine/config와전처리/adapter 계약은보존했다. Tracking On·Scenario Off,중간성능구간없이16개순차기동뒤약60초관측1회수용. 결과9.96~10.03·Redis9.98~10.02FPS,queue최대1·stale/drop/전송오류0·publisher교체1건. 표본objects는모두비어있어실제화염/연기bbox와track ID연결은미관측이다. 품질/다수객체부하수용이아니다. 새image `fire-fp16-6367102-d2a8f65e` 유지,기존3Fire running·추가13정상Stop/reap·등록/preset보존. 세모델batch8(version8,min/opt/max1/8/8,FP16입력/FP32출력)은별도변환및batch1/4/8실행확인완료. 후보는비활성,검증용server전부회수. 활성Fire batch4·instance8/설정은변환전후동일하다. batch8예제instance1은격리검증용이며향후시험instance수는별도지정한다. 품질/Web/batch8다채널성능은미검증. 다음최소작업은Medium batch8과줄인instance수의제한16채널비교시험이다. 이하절은당시기록이며현재상태는이절과최신run을우선한다. ## Pose FP16 입력·Tracking 16채널 수용 [변환·연결·상승시험·유지 상태](runs/20260916T223600+0900-run-pose-fp16-tracking.md). 기준e0c4e77. Pose version4를 별도 준비하고 FP32 정규화 계산→직접 FP16 buffer 저장→FP16 engine 입력, FP32 출력을 연결했다. CUDA sharing On·instance8/maxbatch4/preferred4/5ms·mux576/pool4 유지. 모델별 dtype/sharing 경계를 공통화했지만 Fire는 FP32/sharing Off와 기존 engine/config 그대로다. 4/8/12/16채널 상승시험1회 모두 제한 수용.16채널61.42초 결과9.97~10.02·Redis9.96~10.01FPS, queue최대1·stale/drop/전송오류0·publisher 최신Frame 교체6건. 무손실 판정은 아니다. Tracking 최근최대256표본 wall평균4.00~6.83ms/threadCPU2.74~3.61ms. FIFO개별대기는미측정이다. CPU7.62~8.33core상당·49.55CPU-ms/결과Frame, RAM6.79~6.81GiB, VRAM12400MiB. 새 image `pose-fp16-e0c4e77-bc9fb31c`·Pose mount를actual/persistent 유지한다. 기존3개Pose/Tracking On·Scenario Off running, 추가13개정상Stop/reap·등록보존.16등록모두새설정저장. 기존CLI preset은보존했으므로재적용하면설정이달라질수있다. 새Pose benchmark설정을사용한다. Medium의사용자품질/Web시각화수용과Pose품질/Web동기화대기를구분한다. 다음최소작업은Fire 변환·단독시험이다. 이하절은각당시기록이며현재상태는이절과최신run을우선한다. ## Tracking·INTRUSION On 16채널 수용 [조건·단계별 처리량·Tracking 표본·회수 결과](runs/20260916T215300+0900-run-tracking-sixteen.md). 기준84d219f. 기존image/Medium4·FP16입력/FP32출력·CUDA sharing·instance8/batch4/5ms를유지했다. 기존3개정상Stop뒤16등록에Tracking/INTRUSION enabled만CAS반영했다. 부분ROI/confidence0.5/확정0.5초보존. 상승시험1회4/8/12/16모두수용.16채널61.43초결과9.99~10.08·Redis9.98~10.08FPS, 결과queue최대2·최종최대1,stale/drop/publisher교체/전송오류0. CPU8.25~9.95core·59.13CPU-ms/결과Frame. 기존bounded 최근최대256표본의Tracking wall평균16.91~25.87ms/threadCPU10.80~14.75ms, Scenario wall평균1.18~1.85ms였다. FIFO대기/active·lost수는미지원이며0으로해석하지않는다. 모든16채널소량표본에서연속track ID·INTRUSION/event ID/빨간표시를확인했다. 품질/Artifact전달은미검증이다. 기존3개On running·추가13정상Stop/reap·등록보존. 설정은16개모두On으로저장돼API Start시On이다. 기존CLI preset은Off인원본을보존했다. 이를다시적용하면Off로바뀔수있으며새On benchmark설정과구분해야한다. 모델/image/container재생성·성능튜닝0,상세계측Off. 다음최소작업은Pose단독최적화후단계시험이다. 이하절은각당시검증기록이며현재설정은이절을우선한다. ## Medium B안·CUDA sharing·instance8 수용 [입력 계약 결정](decision/20260916T211700+0900-decision-medium-fp16-sharing.md), [반영·상승시험·CPU 계측·최종 상태](runs/20260916T211700+0900-run-medium-fp16-sharing.md). 기준4471edc. Medium만 FP32 정규화 계산 후 FP16 buffer에 직접 저장하고, 새 version4 engine 입력과 Triton을 FP16으로 맞췄다. 출력/adapter는 FP32, Pose/Fire는 기존 계약을 유지한다. CUDA input sharing On, instance8/maxbatch4/preferred4/5ms, mux576/pool4·동기화·채널별 process 유지. 정확도/시각 품질 비교와 sharing Off 재시험 없이 상승시험1회: 4/8/12/16 모두 제한 window 수용. 16채널61.70초 결과9.97~10.05·Redis9.97~10.02FPS, 결과queue최대1·stale/drop/전송오류0·publisher교체1. Triton160.01FPS·평균요청대기13.00ms·input0.32ms, 실제평균batch3.20이다. instance별분배는미측정. CPU7.42~7.70core 상당·47.24CPU-ms/결과Frame, RAM5.83~5.85GiB, VRAM10670MiB. 기존후보16채널CPU11.41~12.92core·98.58ms/Frame과비교해개선됐지만세변경의개별기여도는분리하지않는다. 새 image `medium-fp16-4471edc-d2ea7a33`와모델mount actual/persistent 유지. 기존3running·추가13정상회수/등록보존. 실패시자동복원하지않고전체시험대상Stop이라는승인계약을도구의명시옵션으로추가했다. 실제실패는없었다. 품질/실제Web동기화/Tracking On/장시간은미검증이다. 다음최소작업은새후보에서Tracking On의제한시험이다. 이하절은각당시기록이며현재값은이절과최신run을우선한다. ## Medium instance6·batch4와 재사용 시험 도구 [BENCH-01](decision/20260916T175000+0900-decision-stream-benchmark.md), [준비·단계별/채널별 결과·유지/복원](runs/20260916T175000+0900-run-medium6-batch4.md). 기준4cd05cc. 기존 dynamic ONNX로 별도 Medium version3 batch1~4 FP16 engine을 준비했다. instance6/maxbatch4/5000us를 실제반영하고 기존 process image·채널별요청batch1·mux576/pool4를 유지했다. 기존16등록/입력6/5/5·Tracking/Scenario Off를 재사용했다. 상승시험1회 결과4/8/12채널은각약10FPS, 16채널61.65초는결과7.43~7.70/Redis7.40~7.70FPS로목표미달이다. 마지막관측수용은12채널이다. 결과queue최대0/1/1/1, stale/drop/전송오류0, publisher교체0/0/1/8이다. 무손실판정은아니다. 16채널Triton은실제batch4 실행1875회/항목7500개,합계121.70FPS,평균요청대기363.80ms였다. 이전후보의약100FPS·대기568.71ms보다개선됐지만instance/batch각각의기여도나최적설정은미확정이다. 새엔진/모델mount actual/persistent 유지. 기존3채널running·짧은복구약10FPS/queue0,추가13정상Stop/reap·등록보존. repo도구로관측/요약/정리를공통화했고fixture7건PASS. 원본·구엔진·sender·Redis·인증/설정은보존했다. batch별수치차이는private에보존했으며사용자시각품질평가대기다. 실제Web동기화·Tracking/Pose성능은미검증이다. 다음최소작업은16채널에서남은Triton입력준비/요청대기와CPU경합의bounded 표적계측이다. 새조합탐색은하지않았다. 이하항목은각당시기록이며현재값은이절과최신run을우선한다. ## Medium instance4·재사용16채널 단계 시험 [조건·단계별/채널별 결과·최종 유지값](runs/20260916T165236+0900-run-medium4-sixteen.md). 기준d357942, 기존 process image·Medium version2/engine/maxbatch1을 유지하고 instance만1→4로 반영했다. 추가13채널의 등록/설정을 먼저 완료하고 반복입력3종을6/5/5로 배정했다. Tracking/Scenario/store/AL/capture Off. 4/8/12에서각20초,16에서60초의 상승시험1회: 결과9.99~10.09 / 9.93~10.13 / 8.39~8.59 / 6.16~6.35FPS. 마지막 관측 수용단계는8채널이며9~11채널은 미측정이다.16채널 기동/관측은 완료했지만각10FPS 목표는미달이다. 결과→Redis FPS는비슷하고 결과queue최대1·stale/drop0. 측정구간 publisher교체0/1/1/2,전송오류/만료0. Triton 합계처리량은12/16에서101.97/100.34FPS,평균요청대기401.81/568.71ms로증가했다. 공유Triton 대기경계를 확인했지만 GPU계산·복사·실행스케줄링의 기여도와instance별분배율은미확정이다. Triton2.67 기본지표는model/version합계이며instance식별자가없다. trace/SDK수정/조합탐색은하지않았다. 16개의서로다른child/전용worker를확인했고추가13개는정상Stop/reap했다. 등록·private preset·autostart=false는보존한다. 기존3개는재시작없이running·짧은복구확인약10FPS/queue0/stale0. 전체등록18개와실행3개를구분한다. 8채널수용·기동/자원안정·기존3개복구를근거로instance4 actual/persistent 유지.16채널성능해결판정은아니다. 다음최소작업은공유Triton/TensorRT 실행스케줄링·요청대기의표적확인이다. 필요시bounded timestamp trace1회만검토한다. 이하 항목은 각 이전검증 당시의기록이며현재수용범위는이절과연결된최신run을우선한다. ## 채널별 독립 프로세스 반영·포화 이후 수용 [CHANNELPROC-01 결정](decision/20260916T155256+0900-decision-channel-process.md), [구현·필수 보호 검증·실제3채널 결과](runs/20260916T155256+0900-run-channel-process.md). 기준0c0dd3d. 같은 Analytics에서 spawn child/활성채널1개·상한16개로 전환했다. 부모는 API/CAS/실행관리, 자식은 RTSP/DeepStream부터 결과·collector·Redis 직접 게시까지 소유한다. 공유 Triton·Medium instance1/maxbatch1·mux576/pool4·10FPS와 기존 설정/입력/Anchor는 유지했다. source/image 필수45tests PASS. Redis writer 소유권은 WATCH 기반 transaction으로 늦은 이전 run을 차단한다. 승인된 publisher GET/WATCH/UNWATCH만 actual/persistent에 추가했고 reader/키범위/인증/허용IP는 보존했다. 초기20.82초 결과 각10.04FPS, 실제collector1000개/채널 도달 이후31.54초 결과10.02/10.02/9.96, Redis10.02/10.02/9.99FPS. 포화구간 queue/stale/drop·publisher교체/만료/전송오류0이다. SDK child3개·parent SDK 미로드·image-owned source hash를 확인했다. 실제1채널 정상Stop/reap와 새PID/run 재기동을 확인했고 다른2개 run은 유지했다. 전체수명 누적교체1건과 계측누락3건은 별도로 기록했다. image `channel-process-0c0dd3d-c5706f45`, actual/active Compose process 모드와75초 종료 grace를 유지한다. 최종3채널 running, Tracking/Scenario/store/AL/capture Off, 상세계측Off·시험helper 회수 완료. 기존 API/CLI 제어를 유지한다. 전체collector·Tracking profile·publisher aggregate 상세계측은 미지원 표시다. 16개 process fixture 통과는 실제16채널10FPS·Tracking On·Pose·장시간/Web 동기화 보장이 아니다. 동일프로세스 저하의 특정 GIL/lock 원인은 확정하지 않는다. 후속은 승인된 입력으로 process 경로의 다채널 수용 확인이다. ## 적용한 재개 계약 [재개 요청·실행 계약](handoffs/20260916T151552+0900-handoff-channel-process-resume.md). 이번 채널별 프로세스 리팩토링에 한해 기존20/35분은 자동중단이 아닌 진행점검으로 변경한다. 승인범위 안에서 원인과 수정방향이 명확하고 진척이 있으면 구현·필수검증·반영·마감까지 계속한다. 근거 없는 반복탐색은 기본1회와 새근거에 의한 보정확인1회로 제한하며, 개별명령timeout·자원상한· 수명/Redis쓰기/설정저장 보호 검증은 유지한다. 전역AGENTS와다른작업의예산은변경하지 않는다. 위 handoff는 구현 전 snapshot이며 변경하지 않았다. 재개 actual HEAD는0c0dd3d·clean이었다. 이번 사용자 답변에서 publisher3개명령 추가가 승인되어 구현과 실제반영까지 완료했다. ## Medium3 최종 포화 확인·프로세스 분리 재개점 [제한 검증·복원·후속 구현 경계](runs/20260916T142725+0900-run-medium-saturation.md). 기준19c6353. 기존 새 후보에 기본Off/60초 bounded collector·결과 wall/thread CPU 진단만 추가했다. Pose 실행 없이 Medium instance1/maxbatch1·Tracking/Scenario Off로 같은3채널을 순차 기동했다. 초기21.93초 결과9.94~9.99FPS였으나 실제collector1000개/채널 이후11.31초 결과7.07~7.69FPS, queue8~12·stale22~28 증가로 예정30초를 채우지 않고 중단했다. collector는1000개 상한을 유지했다. 관측 종료시 bounded 표본의 collector 잠금대기는 작았고, publisher 제출준비/호출 wall 증가가 컸다. GIL/Redis 서버/특정 lock 원인은 확정하지 않는다. 계측 추가 외 성능교정·추가시험0. 기존image/Compose/env·Medium3 running 복원, 짧은확인9.83~10.01FPS·queue0·stale0. 상세계측Off·helper 종료·sender/Redis/identity/Anchor 보존. 계측image는비활성후보로 보존한다. 사용자 합의대로 추가원인탐색을 멈추고 다음은API제어층·공유Triton을 유지한 채널별child process 구현이다. 새image의 장시간성능,16채널,Pose품질/처리량과 Tracking 문제는 해결로 판정하지 않는다. ## 사용자 승인 재개·Pose4채널 결과 처리 저하 [재개·반영·4채널 관측·복원](runs/20260916T130958+0900-run-pose-batch-runtime.md). 사용자가 수치차를 향후 시각평가로 분리하고 성능시험 계속 진행을 승인했다. batch4 shape/finite 확인 후 새 image·Pose version3/instance4/maxbatch4/5000us를 actual/persistent에 반영했다. 전체16등록/설정 완료 후4채널만 기동해21.12초 관측: 결과/Redis 각1.70~1.85FPS, native7.86~8.66FPS에서 결과단계로 추가 급락, stale135~143/채널. Tracking/Scenario Off였다. Triton batch1/2/3 실제 실행을 확인했고 publisher 교체/만료/전송오류0이다. batch4 묶음은 해당window에 없었다. 지속 처리악화 중단기준으로8/12/16은 기동하지 않았다. 임시13등록 정리·시험worker 회수 후 기존3개Medium 설정/running 복원. Medium3 설정복원 뒤에도 결과4.36~5.11FPS/stale증가가 있어 image·model mount·compose/env를 작업 전 값으로복원했다. 이후 짧은확인에서9.69~9.88FPS·queue0~1·stale증가0. 새source/image/engine은미반영후보로RETAIN, 관절품질은사용자평가대기다. 다음은새image에서Pose실행이력없이동일Medium3를첫실행하여코드/설정영향과Pose종료후잔존영향을분리하는시험1회다. ## Pose batch 후보·최소 경로 정리, Runtime 반영 보류 [POSEBATCH-01 결정](decision/20260916T124403+0900-decision-pose-batch.md), [구현·표적 검증·미반영 결과](runs/20260916T124403+0900-run-pose-batch.md). 기준 c869cc4. 기존 dynamic ONNX로 batch1~4 FP16 engine을 생성했다. instance4/maxbatch4/5ms 후보 설정이며 DeepStream 요청/응답batch1은 유지한다. 전처리pool4, 추론전용mux576, 제외Frame 직렬화 생략, generation fence 경량조회와 collector 단일초과분 min 제거를 source에 구현하고 source/image67 tests PASS. 공식 Flow API에 작은 decoded queue 삽입 경계가 없어 해당 부분만 보류했다. 실제 보존 tensor의 batch2/3 객체수는 비교 표본에서 같았으나 batch3의 한 관절 좌표 차이0.031006이 이번 진단의0.03 경계를 넘었다. 해당 경계는 제품의 확정 품질 기준이 아니며, 좌표계/Frame 오매핑을 입증한 것도 아니다. 원인과 수용 범위 미확정으로 engine/image를 배포하지 않았다. 4/8/12/16채널 Runtime 모두 미실행, 기존3채널 run/설정/image/송출/Redis 그대로, Start/Stop/재생성0. 새 engine/image는 미반영 후보로 보존하며 다음 기동도 기존 설정을 사용한다. 다음 최소 작업은 저장된 batch1/3 출력의 동일 객체에 대해 Native decode/NMS 전후 선택과 관절 차이를 대조하는 CPU 분석이다. 허용치를 임의 확대하거나16채널 Start부터 반복하지 않는다. ## 다채널 처리 경계·초기화 실패 표적 확인 [경계·계측 의미·진단 보완](runs/20260915T221000+0900-run-runtime-boundaries.md). 기준761db9b. 새16채널 시험 없이 기존15.13초 자료를 대조하고 현재3채널24.8초만 관측했다. 과거 selected1.92~2.78/infer1.98~2.84/native1.98~2.78/result0.13~0.26FPS였다. 입력 callback부터 진행이 느리고, native→result 사이에서 추가 급락했다. GPU 계산 단독 FPS가 아니다. 재시도 publisher control_handoff_timeout 증가1·worker 생성7을 확인했다. 원본 예외는 소실되어 11번째 Start와의 연결은 강한 정황이며, 인계 지연의 Redis/CPU/GIL 기여도는 미확정이다. 실제SDK9.1·Medium2·576입력·max_batch1·GPU instance1 공유·gRPC/CPU output을 확인했다. 현재3채널 결과10.12/10.30/10.17, Redis10.08/10.18/9.97FPS, queue최종0·stale/drop0. publisher 최신 Frame 교체14건은 남았고 전송오류/만료0이다. 무손실·16채널 해결 판정은 아니다. bootstrap 예외 종류/코드 위치/마지막 단계만 bounded 기록하는 source 진단을 추가하고25tests PASS. image 반영/재기동/Start/Stop0. 공개 오류·설정·판정 의미는 그대로이며 현재 image에는 새 진단이 없다. 기존3개 run·설정·sender·Redis 보존, 실패등록1개는 cleanup완료/error 표시로 유지, 전용worker3/목록40. 다음은 진단 반영과 함께 최소 부하에서 Triton stats delta와 SDK callback/결과 worker wall·CPU·queue를 같은 window에 묶는 표적 관측1회다. 새16채널 반복·batch/instance/timeout 튜닝은 선행하지 않는다. ## 설정 선완료16채널·추가1회와 현재 상태 [실행·기동 직후 참고치·정리](runs/20260915T214311+0900-run-sixteen-prepared.md). 기준4380b7e. 반복 입력3종6/5/5, 모든 등록/설정 뒤 Start만 수행해 첫 시도16개 Frame 처리를 확인했다. 첫 Redis 표본의 없는 Stream을 helper가 예외 처리해60초 window는 미실행됐다. 기동 직후15.130초 참고 구간 결과0.132~0.264FPS/채널(합계2.974FPS), 정식60초 성능값은 아니다. 누락 기록 helper만 교정한 승인 추가1회는11번째 Start의 CONFIG_INVALID/stream_setup에서 중단됐다. 추가 반복·production source/image/튜닝 변경0. 기존3개 run·설정·sender/Redis/비대상은 보존했다. 전용worker3개·계측Off. 실패 임시등록1개는 실제cleanup 완료/observed error로 남겼고 반복 Stop은 하지 않았다. publisher 등록 목록40개와 활성worker3개를 구분한다. 다음 확인은 stream_setup 원인 예외의 bounded 확보다. ## 16채널 Off 기동·60초 관측 미실행 [실행·중단·복원 기록](runs/20260915T211508+0900-run-sixteen-off-blocked.md). 기준695028c. 기존3입력+등록된 실제RTSP1입력을 각각4개로 배정하는 총16채널 계획. 기존3+임시9=12채널까지 Frame 처리를 확인했으나, 다음 임시채널 settings PATCH 응답이 client5초를 초과했다. 13번째 Start는 호출하지 않았고60초 window도 시작하지 못했다. 결과/Redis FPS·16채널 수용 여부는 미판정. 정리 중 Stop202 뒤 GET status500(collector None 참조)1건이 있었다. 이후 같은 generation의 정상 cleanup을 확인하고 Stop 재호출 없이 등록을 삭제했다. 임시10개 등록 모두 제거, 원래 등록/설정과3개 run·sender/Redis/비대상 보존. 전용 worker3개·상세계측 Off. Delete API가 publisher 등록을 해제하지 않아 임시 STOPPED heartbeat10개는 남는다. source/image/build/변환/튜닝/반복시험0. 다음은 설정 API 응답 경계와 종료 중 상태 조회 경계의 표적 확인이다. ## 활성 채널별 전송 worker·최대16개 [METAPUB-04](decision/20260915T180615+0900-decision-channel-publisher.md), [구현·수명·제한3채널 검증](runs/20260915T180615+0900-run-channel-publisher.md). 활성 채널당 전용 worker/sink1개·최대16개, 등록만 된 stopped 채널은 공통 control heartbeat를 사용한다. 이전 전송/worker 종료 전 새 run 입장을 차단하고 DetResultPath Stop에서 회수 결과를 확인한다. source/image67 tests PASS:16개 동시 생성/회수·17번째 거부·느린 채널 격리·Stop/새 run·byte cap. 새 image에서 초기stopped worker0, 실제3채널 running 전용worker3/control1 확인. 24초 결과10.012/10.047/9.947FPS, Redis10.013/10.006/9.989FPS, 교체/오류/stale/drop0. 채널별100개/TTL10초 유지. 기존URI/identity/Anchor·카메라설정·sender/Redis/비대상 보존. image tracking-channel3-f444ab2-da96ab93, actual/active Compose/runtime.env mode=channel·limit16 정합. fixed workers4는 복원용으로 보존하며 channel 모드에서는 사용하지 않는다. 상세계측/capture Off. 신규worker 회수는 fixture/연결시험에서 확인했으며 실제3개는 사용자 시험용으로 유지한다. 실제16채널 각각10FPS는 미검증이다. 추가 승인입력/identity 준비 후 제한검증하며, 다음은 Tracking 동일입력 process 비교다. ## Redis 전달 대기 분리·채널별100개 저장 [METAPUB-03/METABUF-02](decision/20260915T173031+0900-decision-publisher-lanes-buffer100.md), [시점 대응·교정·실제100개 검증](runs/20260915T173031+0900-run-publisher-timeline-buffer100.md). 교체5건 모두 다른 채널 sink.write 중 발생했다. 새 Frame 간격34~90ms와 다른 채널 호출18~67ms가 겹쳤다. 완료 후 잠금 대기는 평균약0.01ms로 작았다. 정확한 Redis 서버/GIL 기여도는 미확정이다. 고정 worker4개와 독립 sink/connection을 사용하고 채널은 같은 worker에 계속 배정한다. 이번3채널은 서로 다른worker에 배정됐으며, 같은 채널의순서/새run/Stop·최신1개·전체대기byte상한은 유지한다. source/image41 tests PASS. 교정 후24초 결과9.95/9.95/9.99FPS, Redis9.99/9.99/9.99FPS, 상태/Frame 교체0·오류/만료/stale/drop 증가0. 이번 제한구간 외 무손실·16채널 보장은 아니다. Redis 저장은 별도로채널별100개로 확대했고 실제100개/TTL갱신을 확인했다. 기존8GiB/TTL10초/ACL 보존. image tracking-parallel-3ed6c35-7d146f38, actual/active Compose/runtime.env에 workers4·stream_length100을 고정했다. 01/02/03 running·Tracking/Scenario/capture/상세계측 Off, identity/Anchor/카메라설정·sender/Redis·비대상 보존. 현재3채널 Redis 전달시험의 필수 blocker는 없으며, 후속은 Tracking process 비교다. ## Redis 전달: 동일 상태 재등록의 Frame 유실 교정 [METAPUB-02](decision/20260915T163137+0900-decision-publisher-state-noop.md), [계측·교정·3채널 결과](runs/20260915T163137+0900-run-publisher-state-noop.md). 기준9881249. 결과마다 같은 RUNNING을 다시 알리면서 pending Frame을 상태-only 항목으로 덮어썼다. 진단 window의 교체4건은 모두 이 경로였다. 같은 run/generation/state 등록을 no-op으로 만들고, 실제 상태 전환·Stop·새 run 차단·heartbeat·채널별 최신1개/전체byte cap은 유지했다. 기본Off·최대60초 publisher 진단을 추가했다. 전송 대기, 전송 호출과 완료 계측의 wall/thread CPU, Frame/상태/heartbeat 구분을 bounded 집계한다. 채널별worker 분리·queue 확대는 하지 않았다. source/image35 tests PASS. 최종3채널 결과10.00/9.93/9.98FPS, Redis9.84/9.77/9.86FPS. 상태 재등록 교체0, 새 Frame 교체4/5/3건은 남았다. 오류·expired·결과stale/drop 증가0, publisher queue0~2. 이전수치와의 엄격한 개선배수나 전송누락0을 주장하지 않는다. image tracking-fixed-9881249-7e36d90f, actual/active Compose/runtime.env 정합. 01/02/03 running·Tracking/Scenario/capture/상세계측 Off. 설정·모델·Anchor·sender·Redis/비대상 보존. 다음 최소 계측은 교체 시 Frame 도착 간격과 전송 완료를 같은 monotonic 축에 묶는 bounded 관측이다. Redis 전달 누락0/각10FPS는 미완료이며 Tracking 병목·Web 영상 동기화와 별개다. ## 중간 시연: Tracking·Scenario Off 단일 채널 [TRACKMODE-01](decision/20260915T150719+0900-decision-tracking-mode.md), [구현·단일 채널 확인](runs/20260915T150719+0900-run-tracking-off-demo.md). 사용자 중간 지시로3채널 검증을 취소하고02만 실행했다. actual gate에서도01/03은 이미 stopped였다. `tracking.enabled` 기본True, False이면 ByteTracker 생성/update/FIFO를 생략하고 기존 null trackId를 보낸다. INTRUSION On과 Tracking Off 조합은 거부한다. API CAS/저장 실패/no-op 및 시험 CLI 부분 설정을 재사용한다. source/image41 tests, CLI20 tests PASS. image tracking-off-b597c1b-f2a7a7c5 반영. 24초 단일02 결과/Redis10.02FPS, queue0·stale/drop 증가0, RTP 유지·trackId null·Scenario Off 확인. 02만 running으로 유지하고01/03은 stopped다. 02의 실제/persistent 설정과 private preset을 Off로 맞췄다. 01/03의 기존 설정·ROI·모든 채널 identity/Anchor·sender·Redis·BLAS1·비대상 서비스는 보존했다. 상세 계측/capture Off. 다시 켤 때02 preset에 tracking.enabled=true를 명시하고 필요하면 intrusion.enabled=true도 함께 설정한 뒤 시험 CLI restart를 사용한다. 이번 결과는 탐지 전용 단일 채널 시연 확인이며 Tracking 포함3채널 병목 해결이나3채널Off 성능 검증이 아니다. ## 3채널 처리 저하·입력/추론과 Tracking 대기 구분 [24초 비교·복원 후 재발·보호 종료](runs/20260915T144413+0900-run-three-channel-contention.md). 기준 d48c404. 최초3채널 추론은 각9.84~9.94FPS이나 결과/Redis는 약2.6FPS였다. 03만 정상 Stop하면01/02는 run·설정·Tracker 초기화 없이 결과/Redis10.00/9.96FPS·stale 증가0으로 회복했다. 03 복원 후 짧은 확인에서도 각3.5FPS·stale 증가가 재발해 승인대로03만 다시 정상 Stop했다. 최종01/02 running·queue0, 03 stopped·cleanup 완료. 설정·Anchor·sender·Redis·image·restart 정책은 보존했다. 03은480x360·약30FPS decoded에서10FPS를 선택하며, 기존01/02는1280x720·약10FPS다. FIFO 대기뿐 아니라 실행권 안쪽 Tracking wall 시간도 늘었다. 채널당3개 표본에서 대기99~341ms, 계산 wall63~191ms/thread CPU19~35ms였으며 전체 구간 평균/p95가 아니다. 전체 Tracking 평균360~376ms에는 FIFO 대기가 포함된다. GIL/native 대기 비중과03 입력 callback의 정확한 영향은 미확정이다. 단순 GPU 포화·후보 폭증·FIFO 용량만으로 원인을 확정하지 않는다. 이번에는 production source/image/threshold/BLAS 변경0. 다음 최소 계측은 FIFO 점유 구간과 같은 process SDK/Native callback thread의 대기 stack을 동일 시간축으로 확인하는 것이다. 3채널 각10FPS는 미달이며, 당장 Web Metadata 시험은 유지된01/02를 사용한다. ## 활성 Tracking 실행 경합·2채널10FPS 회복 [TRACKEXEC-01](decision/20260915T141024+0900-decision-tracking-kernel-fifo.md), [동일 입력 비교·image/Runtime 결과](runs/20260915T141024+0900-run-active-tracking.md). 보존된 전체300후보×200 Frame을 같은 초기 상태로 재생해1-worker8.84ms→2-worker43.4ms 지연을 재현했다. 채널별 ID/상태는 일치했다. FIFO로 Tracking 계산만 순차 실행하면2-worker22.2ms로 줄어 최소 반영했다. 같은 process의 ByteTrack 계산만 공유 실행 순서를 사용하며 입력/추론·Tracker/Scenario 상태·Metadata 전송은 공유하지 않는다. 기존 idle fast path·threshold·ID/만료·OpenBLAS1을 유지한다. source/image35 tests PASS. 실제2채널 결과/Redis10.00/10.03FPS, stale/drop 증가0·queue 종료0을 확인했다. Tracking 평균109~117→24~26ms로 관측됐다. 간헐 최대327~409ms는 남았으나 해당 window에서 대기열이 회복됐다. 최종 image tracking-active-a61e8b5-959ce804를 actual/active Compose/runtime.env에 정합화했다. 두 채널 running·INTRUSION On·capture/상세 계측 Off, 설정·Anchor·sender/Redis·비대상 서비스 보존. 정확한 GIL/native 대기 비율은 미확정이며 이번 회복을16채널·장시간 처리 여유로 확대하지 않는다. 이번 제한2채널 시험의 필수 blocker는 해소됐다. Web 연동 피드백과 Event/Artifact를 재개할 수 있다. ## Tracking 비활성 class 최소 개선·잔여 병목 [분석·동등성·image/실행 결과](runs/20260915T134626+0900-run-tracking-idle-fastpath.md). 실제300개 후보·64개 class 중59개에 tracked/lost/removed 상태가 없었다. supervision0.30.2에서 상태가 없고 기존 activation 기준 이상 후보도 없으면 Frame clock만 진행하는 동등 fast path를 추가했다. 원본 후보·threshold·ID counter·첫 Frame 활성화·만료 의미는 보존했다. 최종 source/image30 tests와 INTRUSION 연결2 tests PASS. OpenBLAS1과 dependency/SDK는 변경하지 않았다. 과거2채널 결과5.94/6.32FPS 대비 이번8.72/8.15FPS, stale+74/+66 대비+21/+25로 관측됐다. 새 run·장면/track 수 차이가 있어 정확한 개선 배수는 주장하지 않는다. 각10FPS는 여전히 미달이다. 활성5~6개 class의 Tracking wall109~117ms/thread CPU32~34ms가 남아 있다. 다음은 활성 class 내부 Kalman/IoU/매칭 구간의 wall/thread CPU 분해이며 추측성 BLAS 확대·멀티프로세스 전환은 보류한다. 최종 image는 tracking-fix-7357cdd-d70b1a6c이며 actual/active Compose/runtime.env에 정합화했다. 두 채널 running·INTRUSION On·capture/상세 계측 Off, 설정·Anchor·sender·Redis/비대상 container는 보존했다. 중간 cProfile 계측은 동시 소유 오류와 비정상 시간값 때문에 전부 제거했다. 최종은 기본Off·최대3 Frame의 class별 직접 시간/상태 계측만 사용한다. 중간 실패/무효 계측은 새 실행 기록에서 별도로 보존한다. ## 두 채널 처리 지연·단독 비교 [18초 동시/단독 비교](runs/20260915T131344+0900-run-channel-contention.md). 기준 caf79f9. 새 채널의 입력·설정·run/Tracking 상태를 유지하고 기존 채널만 Stop1→Start1 했다. 2채널에서 새 채널 입력/추론10.00FPS, 결과6.32/Redis6.37FPS·결과 queue8~11·stale+66이었다. 단독에서는 결과/Redis9.98FPS·queue0·stale+0으로 회복했고 Tracking 평균146.41→17.83ms였다. 침입 판단은1.10→0.95ms, publisher queue는 모두0이다. 동시 실행 영향과 Tracking 비용 집중은 확인됐다. GIL/native 대기와 class별 후보·track 이력 비용의 비중은 미확정이며 입력 URI 결함이나 GPU 포화로 단정하지 않는다. 정상 cleanup0.153초 뒤 기존 채널을 복원했다. 두 채널 running·상세 계측/capture Off, sender·설정·image는 보존했다. 복원 후 두 결과 queue가 다시10인 상태를 확인했다. 기능 연동 시험은 가능하지만 2채널10FPS 충족 상태는 아니다. 다음 최소 작업은 Tracking 내부 후보/track 수·연산별 wall/thread CPU의 bounded 계측이다. 이번에는 source 수정·튜닝을 하지 않았다. ## 시험 실행 도구·Reader 허용 IP 확대 [TESTCLI-01/METALAN-04](decision/20260915T124300+0900-decision-test-run-cli.md), [구현·제한 실행 결과](runs/20260915T124300+0900-run-test-cli-reader.md), [사용 가이드](../../../../../tools/TEST_RUN_GUIDE.ko.md). tools/test_run.py가 YAML 검증/조회·기존 API Start/Stop/Restart를 묶는다. RTSP sender/container 제어와 Anchor 자동 조회는 없다. 실행 중 변경은 명시 restart만 허용하고 CAS PATCH가 controlled restart하면 중복 Restart를 보내지 않는다. 기존 URI/identity/store/AL/capture 설정이 맞지 않으면 조용히 덮어쓰지 않는다. 최소·상세 비식별 예제를 제공했다. 등록 URI/identity API가 없어 같은 서버의 등록 YAML을 읽기 전용 대조하며 remote API는 초기 범위에서 제외한다. 19개 표적 tests PASS. 실제 CLI Stop1→Start1, 정상 cleanup0.085초·결과/Redis9.96FPS·queue0~1/drop0 확인. 대상 AI running/sample01 continuous 유지, 상세 계측·capture Off. sender·image·Redis 재시작은 하지 않았다. 추가 승인 reader1개만 기존 Metadata 포트에 허용했다. 마지막 DROP 앞 삽입·순서 검증·두 번째 apply no-op PASS. Windows RTSP 재생은 사용자가 성공을 확인했으며 원인 인과관계나 Web 영상 동기화 PASS로 확대하지 않는다. 다음은 사용자 CLI 확인/Web reader 피드백과 공통 Event/Artifact 구현이다. 이전 오류 상황 SDK Stop 지연은 별도 후속이다. ## Shared pipe seek503 교정·Web 시험 실행 유지 [RTSPTEST-04](decision/20260915T114800+0900-decision-rtsp-live-nonseekable.md), [전후 수신·제한 AI 시험](runs/20260915T114800+0900-run-rtsp503-web-ready.md). 기존 송출은 OPTIONS200/DESCRIBE503, 같은 코드의 격리 H.264 송출은 새 client PLAY seek 실패를 재현했다. FFmpeg pipe를 seekable로 취급하던 경계를 GstBase live 선언과 public SEEKING query의 nonseekable 응답으로 교정했다. worker6 tests, 교정 후 비추론35 decoded/0 errors·20 Frame 출력, once EOF/Anchor null/반복 Stop 회수 PASS. sample01은 같은 URI/영상으로 승인 교체했고 새 실행의 실제 RTCP Anchor를 대상 AI에 CAS 적용했다. Analytics app/SDK 변경 없이 기존 image를 재사용했다. 단일 INTRUSION Start1/Stop0, 결과/Redis10.025 FPS, 226 Frame RTP90000/Anchor 계산 ESTIMATED·최근30개/TTL 갱신·queue/drop0, 표본 Event6개 확인. 현재 AI running/sample01 continuous 유지, actual/persistent restart=on-failure:3 복원. 상세 계측·store/AL/capture Off. 임시 sender/receiver는 모두 회수했다. Web reader의 실제 수신·파싱·영상 동기화와 Windows 재생은 사용자 확인 대기다. 이전 실패 시 SDK stop 대기는 이번에 별도 실패 시험이나 추측성 patch로 고치지 않았다. 정상 AI Stop도 실행하지 않았다. ## Web 시험용 단일 채널 기동 실패·안전 종료 아래는 이전 실패 당시 기록이다. 현재 running/정상 정책은 위 최신 결과를 우선한다. [제한 Start와 최초 실패 근거](runs/20260915T113000+0900-run-web-ready-blocked.md). 기준 b830b70. 기존 H.264 continuous sender·최신 CLI Anchor·Medium/10FPS·INTRUSION/부분 ROI는 정합했다. 설정 변경 없이 Start1회 했으나 RTSP503 응답으로 decoded Frame이 없었다. 40초 관측 뒤 Stop1회, cleanup도40초 안에 끝나지 않아 다른 채널 stopped 확인 후 Analytics만 안전 중지했다. 현재 Analytics stopped/restart=no(actual/persistent). sample01 sender/Redis8GiB/모델/카메라 설정은 보존했다. 새 Redis Frame 없음, FPS·RTP Metadata·Web 수신은 미검증이다. 정상 running 유지 목표는 달성하지 못했다. 다음은 AI 재시작 전에 송출 RTSP의 어느 요청 단계에서503을 반환하는지 bounded 비추론 수신기로 판별하는 것이다. Windows 조사·무관측 반복 Start·sender 재시작은 하지 않았다. 원인 보정 후 Analytics 정상 정책을 복원하고 재개한다. ## 조회 편의·Redis 재생성·Web 공유 문서 아래는 이전 Batch의 완료 사실이다. 현재 Analytics 실행 상태는 위 최신 안전 종료 결과를 우선한다. [METAREAD-04](decision/20260915T111200+0900-decision-reader-extension-html.md), [재생성·문서 검증](runs/20260915T111200+0900-run-redis-extension-html.md), [Web 연동 가이드 원본](../../../../integration/metadata-web-review.ko.md). 합의한 조회10개 명령 추가,27개 ACL DRYRUN PASS. key 범위·인증·쓰기/관리 거부를 보존했다. Redis만 같은 image/data volume으로 재생성했고 actual command/live/persistent 모두8 GiB으로 정합화했다. 첫 기동은 root:0600 bind 설정의 읽기 권한 때문에 실패했다. 최초 오류를 보존하고 자동 재시도를 중지한 뒤 Redis UID999/GID1000 소유·0600으로 exact config/ACL 두 파일만 보정해 재기동 PASS. SHUTDOWN SAVE/RDB 로드 확인, 기존 TTL key3개는 정상 만료되고 publisher가 상태·목록을 다시 게시했다. Frame 없는 stopped 상태의 검증이며 AI Start0/다른 container 교체0. 복구 후 queue0·송신 오류 증가 없음. Markdown 피드백과 standalone HTML을 완료했다. HTML은 architecture_docs/current/contextra_metadata_web의 표현본이다. 원본 예제 JSON/Python은 유지하고4개 reader tests 및 desktop/mobile 문서 검증을 수행했다. 다음은 Web reader의 실제 재접속·수신 확인이며 Windows RTSP·영상 동기화·Event/Artifact는 별도 후속이다. ## Reader 권한·Web 가이드 내용 검토 아래는 직전 Batch 당시 기록이며 Redis 재생성 보류와 HTML 미제작은 위 최신 결과로 해소됐다. [METAREAD-03/METABOUNDS-03](decision/20260915T102820+0900-decision-reader-guide-bounds.md), [권한 검증·재생성 보류](runs/20260915T102820+0900-run-redis-reader-guide.md), [7개 항목 검토안](../../../../integration/metadata-web-review.ko.md). Web reader에 SCAN/HSCAN/XINFO STREAM만 추가했고 actual/persistent ACL 반영과16개 DRYRUN 허용/거부 검증 PASS. 실제 SCAN/HSCAN은 소량 읽기로 확인했다. 쓰기/삭제/관리 권한은 추가하지 않았다. reader 연결5개와 blocking XREAD1개가 있어 Redis 재생성은 보류했다. AI2개 모두 stopped이며 사용자 연결을 끊지 않았다. Redis live/redis.conf/Compose/runtime.env는8 GiB, 기존 container command는2 GiB이므로 단순 restart 주의는 여전히 유효하다. 9월 배포 source 기본값도 JSON10 MiB/queue256 MiB/Redis8 GiB으로 명시했다. Metadata 활성화·인증은 별도 명시 설정을 유지한다. 예제 JSON은 실측 구조를 비식별화한 설명용이며, Python 예제의 cursor/새 run/Stop/만료 동작은4 tests로 확인했다. HTML은 아직 만들지 않았고 사용자1~7번 내용 검토를 기다린다. Windows RTSP 조사는 이번 범위에서 수행하지 않았다. ## H.264 호환 경로·RTP Metadata·시연 한도 아래는 직전 시험 결과다. 최신 ACL·기본값·검토안 상태는 위 내용을 우선한다. [RTSPTEST-03/METABOUNDS-02](decision/20260915T094924+0900-decision-rtsp-compat-capacity.md), [실행 결과와 한계](runs/20260915T094924+0900-run-rtsp-compat-intrusion.md). 사용자가 실행한 시험 채널을 정상 정리하고, 승인 원본의 H.264 준비본을1회 생성했다. 1280x720/10fps/121.8초/1218 Frame 보존, sample01은 준비본의 continuous 송출을 유지한다. `prepare-h264` CLI는 hash/recipe로 재사용하며 원본·registry를 자동 변경하지 않는다. MPEG-4 RTP hook 누락은 확인했고 미지원 경고를 추가했다. 일반 MPEG-4 시간정보 지원을 새로 구현한 것은 아니다. H.264 제한 INTRUSION1 window는 결과10.05 FPS/queue0, 보존90 Frame 모두 raw RTP/계산 시각 ESTIMATED, Event1개·빨강 상태 확인, Stop/cleanup PASS. 독립 wire-pixel 동일 Frame 대조와 Web 동기화는 미검증이다. Windows FFmpeg는 DLL load 오류로 실행되지 않아 팟플레이어 실패의 단독 원인은 미확정이다. 최종 재생은 사용자 확인 대기다. JSON10 MiB/송신 대기256 MiB/Redis live8 GiB 반영. 최근30개/TTL10초/eviction 정책 유지. Redis 재시작0이며 기존 container 시작 인자2 GiB은 남아 있다. Compose 재생성은8 GiB, 단순 docker restart는2 GiB 복귀 가능. AI 시험 채널은 stopped, INTRUSION/부분 ROI/새 Anchor 설정은 다음 수동 시험용으로 유지한다. 시연 후 용량 재검토와 Redis 안전 재생성 시 시작 인자 정합화를 남긴다. 모델·SDK 교체/모델 변환은 하지 않았다. ## Swagger 단일 채널 시험 준비 완료 아래는 직전 준비 단계다. 최신 시험 설정과 송출 codec은 위 결과를 우선한다. [once·image 반영·sample01 준비](runs/20260914T174625+0900-run-rtsp-swagger-ready.md). `b0d7d25` exact snapshot의 고유 image `contextra-analytics:rtsp-ready-b0d7d25-6feef755`를 반영했다. once 자연 EOF/inactive Anchor null/반복 Stop·회수 PASS. 새 image-owned API2 tests와 실제 OpenAPI PASS. Analytics healthy/기존1개 Stream stopped, Medium/Pose/Fire version2와 기존 env/mount/설정/restart 보존. 사용자 sample01은 기존 영상 그대로 LAN/continuous 송출을 유지한다. 실제 bridge receiver에서 SDP·1330 packets 수신 PASS. CLI list의 현재 URI/executionId/Anchor를 사용한다. 주소는 DHCP이며 Windows/Web 실제 수신·동기화는 미검증이다. 운영 AI Start0/시험 채널 등록0. 이제 사용자가 [Swagger 가이드](../../../../../tools/RTSP_SWAGGER_GUIDE.ko.md)의 등록(start=false)→설정 CAS→Start→상태→Stop 순서로1개 채널을 시험할 수 있다. 전체 액세스에서 이번 capacity 오류0. 재발하면 추가 실행·질문 없이 최소 안전 정리 후 중단한다. 다음은 사용자 단일 채널/Redis 수신 확인→소규모2채널→Event/Artifact다. 새 모델 변환·공유 송출 재시험은 불필요하다. ## 실제 공유 송출·Anchor·API 검증 아래는 직전 승인 서비스 차단 당시 기록이다. 최신 반영 상태는 위 준비 완료 결과를 우선한다. [이번 실제 검증과 반영 대기](runs/20260914T172440+0900-run-rtsp-shared-runtime.md). commit `05d525d`의 API 등록2 tests를 기존 Analytics image의 network-none/GPU0 환경에서 통과했다. explicit source cwd/import 경로/hash와 canonical identity 전달·중복 source 거부·저장 실패 보호를 확인했다. 별도 LAN URI에 실제 bridge-network receiver2개를 붙였다. 3초 늦게 합류한 B와 A의 공통59개 RTP Frame packet group에서 timestamp/SSRC/sequence 범위와 전체 압축 packet digest가 일치했다. clock90000/delta9000, wire RTCP SR과 CLI Anchor 계산 차이0~1ms. 원본 촬영시각/Web 동기화 PASS는 아니다. 외부 수신 전/모두 종료 후에도 keeper의 packets가 증가했고 A종료 뒤 B가 계속 수신했다. 임시 sender/receiver 회수 PASS. 실제 LAN IP는 현재 DHCP 할당이며 장기 고정 보장은 미확인이다. 새 IP나 방화벽 규칙을 만들지 않았다. 이어진 once 시험·image build 요청은 실행 승인 모델 capacity 오류로 각각 실행 전에 거부됐다. 같은 승인 실패2회 뒤 중단했으며 once0/build0/Analytics반영0/sample01교체0/운영AI Start0이다. 기존 env/overlay/active compose/registry/3모델 hash 불변. 아직 사용자가 Swagger 시험을 바로 시작할 상태는 아니다. 다음은 once EOF→exact image/cache build→image-owned API 확인→stopped Analytics 반영→승인 sample01 LAN 교체다. 공유 RTP 시험과 API source2 tests는 새 관련 변경이 없으면 반복하지 않는다. 이후 Swagger1개→Web Redis→2개→Event/Artifact. ## 공통 URI·공유 송출·Swagger 재개 준비 이하는 직전 source-only 단계다. 실제 shared/LAN/Anchor와 API source 상태는 위 최신 검증을 우선한다. [RTSPTEST-02](decision/20260914T165217+0900-decision-rtsp-shared-swagger.md), [source 검증·실행 보류](runs/20260914T165217+0900-run-rtsp-shared-swagger.md), [CLI](../../../../../tools/RTSP_TEST_GUIDE.ko.md) / [Swagger 재개 가이드](../../../../../tools/RTSP_SWAGGER_GUIDE.ko.md). 기존 LAN IP를 명시 configure하는 대표 URI와 실행 ID/Anchor 묶음, 조회-only accessChecks를 준비했다. continuous는 같은 worker의 내부 RTP keeper1개로 외부 수신자0에도 shared media를 유지하는 source다. 실제 RTCP Sender Report를 읽어 RTP-zero Anchor를 산출하며 arbitrary process-start wall clock은 쓰지 않는다. 0/null/감소·SSRC/rate 변경을 구분하고 새 기준은 AI에 자동 적용하지 않는다. source24 tests PASS, host Gst1.24.2의 실제 RTP/RTCP public parser callback 검증 포함. 내부/외부 URL로 media가 나뉘지 않게 public factory gen_key를 송출 실행 ID로 통일한다. **실제 shared RTSP/LAN/다중 수신/무수신 연속/Anchor wire 검증은 NOT_RUN**이다. 자동 승인 도구가 selected model capacity 오류로 read-only Docker 조회도2회 거부해 실행을 보류했다. 이를 우회하지 않았으며 sender create/start/stop0, 운영 AI/image/Redis 변경0이다. 사용자는 sample01 Stop 후 교체를 승인했지만 실제 교체는 별도 검증·실행 도구 복구 이후다. registry를 변경하지 않았고 보존 상태 파일은 STOPPED이나 actual container 상태는 재확인 필요다. Swagger StreamSpec의 server_id/source_id 누락과 중복 source_id 위험을 source에서 최소 보정했다. 추가 API2 tests는 Pydantic 없는 host에서 실행하지 못했다. 기존 source-test 환경 검증과 후속 image 반영이 필요하다. 우선순위는 RTSP 실제 검증/반영→Swagger1개→Web Redis 수신→소규모2개→Event/Artifact다. 기존 Event/Artifact 승인 계약은 유지하되 구현 진입 순서는 위 최신 합의를 따른다. ## 반복 시험 RTSP CLI 완료 이하 RTSPTEST-01 당시 PASS 범위다. 현재 보완 source의 Runtime 수용으로 확장하지 않는다. [RTSPTEST-01·Event/Artifact 후속 잠금](decision/20260914T152947+0900-decision-rtsp-test-event-artifact.md), [실제 송수신·수명 검증](runs/20260914T152947+0900-run-rtsp-test-cli.md), [사용자 CLI 가이드](../../../../../tools/RTSP_TEST_GUIDE.ko.md). 기존 local image의 FFmpeg stream-copy/GstRtspServer로 독립 sender를 제공한다. 설치/build/pull0, 운영 Analytics/Redis/모델/기존 송출 변경0. 등록/교체/list/start/stop/stop-all, 이름별 고정 URI, 명시 base-dir·한글/공백/쉼표 경로, atomic mapping·소유 container ID 확인, 동시4개 거부 로직을 구현했다. 기본 continuous/선택 once, 자동 기동Off. 첫 수신 접속에 재생을 시작하고 마지막 disconnect에는 종료한다. 재접속은 다시 start해야 하며 AI 상태 초기화나 자동 Anchor 생성은 하지 않는다. 표적11 tests PASS. 승인 MPEG-4 Part2 원본의3초 stream-copy 시험본으로 once30Frame/정상 EOF, 실제2개 동시 송수신·독립 Stop·반복 경계 RTP 연속을 확인했다. clock90000, delta9000/Frame, 역행/관측 sequence gap0. 실제4개 동시·다중 수신자·H.264/H.265 미디어·AI Metadata/Web 동기화는 미검증. 기본 sample01은 승인 원본으로 등록만 했으며 송출0/수신 helper0. 기존16개 container 상태 불변. 다음은 아래 decision의 공통 Event/Artifact 구현이다. AI container 연결용 접근 경계와 실제 Anchor 확인은 해당 Runtime 단계에서 적용한다. 동료 URI 조사·상시 무수신 방송·고급 재접속은 확대하지 않는다. 업무 clip overlay 필수·전후3초·분석FPS/원본시간·시간삭제Off·용량100/80GiB·여유50/60GiB 승인을 기록했다. Event 접수/Artifact READY/Web 접수는 별도이며 실제 구현은 아직 하지 않았다. ## INTRUSION 최소 정리 완료 [변경·판정 회귀·Runtime·후속 합의](runs/20260914T143245+0900-run-intrusion-preparation.md). Frame당 만료 순회를1회로 정리하고 idle/stale 만료도 queue lock 밖에서 실행한다. 상태 단일 worker 소유와 close의 join 후 clear는 유지한다. 전체 항목 목록 대신 만료 ID만 수집하며 전체 상태 순회 자체는 남는다. ROI 변 목록은 엔진 생성 시 준비하고 공개 config/revision에는 넣지 않는다. source/image 각17 tests와 이전 판정120Frame씩 비교 PASS. 동일 결과의 표시/Event 연결 회귀도 통과했다. 고유 image build1·Start1/Stop1·실패0. 기존10fps 승인 파일/Medium/INTRUSION/ROI로 capture Off, 첫 결과 후5초 워밍업 뒤15.202초 측정에서 입력/선택/추론/결과/Redis 모두9.9988 FPS. Tracking 평균22.04ms/p95 34.80ms, Scenario 평균1.00ms/p95 1.50ms. queue/drop/stale0, cleanup0.259초 PASS. 과거와 영상 구간·구성이 달라 개선 배수는 주장하지 않는다. 새 image 유지, 원래 camera 설정·restart on-failure:3 복원, 임시 mount/flag 제거, healthy/Stream stopped. Medium/Pose/Fire·Metadata 인증/LAN·비대상 서비스 보존. 다음은 공통 Event/Artifact 의미 잠금과 별도 RTSP 시험 CLI 준비다. URI 접속 조사는 보류한다. CLI 최대4개·고정 URI·continuous 기본/once 선택·한글/공백 경로·Stop 후 변경 등의 합의는 위 run에 후속 계약으로 기록했으며 구현하지 않았다. Artifact On의 설정 FPS/queue/drop/지연 추이 비교도 후속이다. ## Fire 실제 연결 완료 이하 Fire 완료 당시 재개 순서보다 위 최신 Event/Artifact 우선순위 합의를 우선한다. Fire 완료 범위는 유지한다. [HTTP·실제 전달·복원 검증](runs/20260914T113200+0900-run-fire-api-runtime.md). commit `7a51cb9`의 Fire 요청 교정을 source/image 각각 explicit cwd와 import 경로/hash로 확인했다. HTTP projection·CAS·저장 실패 tests 각2개 PASS. Native binary3개가 이전 SDK PASS image와 같아 재시험하지 않았다. 고유 image `fire-api-7a51cb9-92b2e488` build1, 승인 파일 단회 Start1/Stop1, 실패0. 실제 Fire class0 smoke_visible/class1 flame_visible 결과31Frame이 Redis에 전달됐고 JSON3개가 같은 run/generation/frameSeq·내용으로 일치했다. 추가 NMS/Scenario/Event/capture는 Off다. 결과 최초~마지막 monotonic 간격2.783초 기준10.061 FPS. 첫 관측0.5초 뒤의 공통2.065초 계수차는 결과9.687/Redis10.171 FPS이며 짧은 구간의 계수·poll 시점 차이를 포함한다. 지속10 FPS 보장은 아니다. queue drop/stale0, cleanup0.331초 PASS. 자연 EOF 전 명시 Stop했으며 현재 unlimited Stream의 자연 EOF 지원을 PASS로 확대하지 않는다. 파일 RTP 시각은 UNAVAILABLE로 보존했다. 새 image/Fire read-only version2/batch1/576 준비 유지, 원래 camera 설정 CAS 복원, restart on-failure:3 actual/persistent, 임시 mount/flag 제거, healthy/Stream stopped. 다음 일반 Start는 원래 Medium RTSP·표시0.25/10fps/Anchor 설정이다. Medium/Pose·Metadata 인증/LAN·비대상 불변. Fire 연결 필수 blocker 없음. 추가 최적화 없이 FALL 의미 잠금으로 진행한다. raw numerical FAIL·제한 시각 수용·권리 미확인 후속과 Fire Event/Artifact/HTTP 미구현은 그대로 유지한다. ## Fire image·SDK와 HTTP 설정 경계 아래는 직전 중단 당시 기록이다. 현재 API 교정·Runtime 완료·복원 상태는 위 최신 실행이 소유한다. [실행·중단·재개점](runs/20260914T111141+0900-run-fire-image-settings-boundary.md). 기존 exact FP16 plan을 재변환하지 않고 고유 image1개와 Fire version2/batch1/576 read-only mount를 준비했다. image-owned Medium/Pose/Fire factory3개, Medium 및 Fire 두 클래스의 SDK identity·빈 결과·copy/release는 PASS다. 실제 Analytics readiness와 세 모델 version2 load는 PASS이나, 내부 settings PATCH가 Fire 필드 누락으로 422를 반환해 Start 이전에 중단됐다. `SettingsPatch.fire`와 요청 projection/CAS/저장 실패 회귀를 source에 추가했다. 추가 helper가 cwd 우선순위로 옛 image 모듈을 import해 수정 후 회귀는 미검증이며, 누적 실패5회에서 종료했다. 오래된 fixture PTS/캡처 인터페이스·completion 생성 순서 보정과 격리 준비 실패도 실행 기록에 보존했다. 실제 Start0/Stop0, Fire→Redis·FPS·Stream worker cleanup은 NOT_RUN이다. SDK mock transport PASS와 구분한다. Analytics는 새 image를 유지한 stopped/restart=no(actual/persistent), 원래 카메라 설정은 CAS 복원했다. Medium/Pose·Metadata 인증/LAN·비대상 서비스 불변. Fire model과 중지 container의 임시 mount는 RETAIN이며 normal Compose 재생성 시 임시 mount가 빠진다. 자동 재기동하지 않는다. 다음은 explicit source cwd와 module `__file__` 확인→수정 API 표적 회귀→새 고유 image의 HTTP schema Gate →승인 영상1개 Start1/Stop1이다. 완료된 모델 변환/품질 비교/SDK 경계는 반복하지 않는다. 이 연결 완료 전까지 FALL 구현 진입은 보류하고 의미 질답은 가능하다. raw numerical FAIL·제한 시각 수용은 유지한다. ## Fire 오프라인 비교·반자동 CLI 이하 image/Runtime 대기는 해당 이전 Batch 종료 시점이며 현재 상태는 위 최신 실행 기록이 소유한다. [FIREVIDEO-01](decision/20260914T100325+0900-decision-fire-offline-video.md)과 [3개 영상/처리량 검증](validation/20260914T100325+0900-validation-fire-video-comparison.md). 기존 Medium 실행/Native decoder/진행/표시 helper를 재사용해 Fire CLI를 추가했다. FP16/weight Reference/모델 비교 및 score 제외 후보 Off/On/Compare, bounded 결과 재사용을 지원한다. 표적23 tests PASS. 첫 시도는 Reference module CPU 잔존으로 영상 처리 전 워밍업 실패했고, module.to(cuda)/device 검사로 교정한 다음3개 영상을 한 번씩 비교했다. 변환/운영 변경0. 각51Frame/5.033333초, 전체153Frame. 모델 FPS Reference31.654/FP16228.268, decode/그리기/인코딩 포함 비교 생성2.502 FPS. 준비23.593초는 제외했다. 표시 후보 관측 총합은 영상1 62/62, 영상2 45/45, 영상3 141/139다. 고유 객체 수가 아니다. 영상2 중앙2.5초는 양쪽 모두 미표시, 영상3은2Frame에서 표시 수가 다르다. 이후 사용자는 제공3개 clip의 Ref/FP16 품질이 거의 같고 일부 깜빡임/누락은 현재 시험에서 수용 가능한 수준이라고 피드백했다. 해당 exact 모델/영상/조건의 제한적 시각 수용으로 기록하며 추가 최적화·threshold 보정은 선행하지 않는다. 전체 정확도·현장 품질·실제 Runtime 수용은 아니다. RGB/같은 Frame 좌우/PTS/재생길이·대표3장 레이아웃 확인. raw numerical FAIL은 유지한다. 기존 container/image/env/mount·비대상 상태 불변, GPU4420→4420MiB/표본 peak5055MiB, task container 종료. 운영 API·Redis·Stream 연결0. 다음은 image-owned SDK와 제한 Runtime이다. [반복 실행 가이드](../../../../../model_tooling/FIRE_VIDEO_GUIDE.ko.md)에 FP16 debug On/Off 비교·구간/threshold 조절과 생성 FPS의 비용 해석을 정리했다. 이번 사용자 피드백/문서 갱신에서 새 추론·영상 생성·운영 변경0. ## Fire 내부 시험 변환·source 준비 [FIREPATH-01](decision/20260913T225300+0900-decision-fire-internal-provider.md)과 [변환/source 검증](validation/20260913T225300+0900-validation-fire-conversion-source.md). 사용자가 권리 미확정을 유지한 내부 개발 시험을 승인해 이전 내부 실행 HOLD만 해제했다. 상용/현장 배포·재배포 권리 검토는 계속 후속이다. 기존1.9.3 safe load에서 missing/unexpected key0, class0 smoke_visible/class1 flame_visible/background2 및 dets[1,300,4]/labels[1,300,3] 확인. ONNX export1·reference 수치 PASS, FP16 build1·plan 실행1·shape/finite PASS. 합성 입력의 FP16 raw 수치 비교는 bbox 최대1.03814/logit1.59608로 FAIL이며 재변환하지 않았다. 사용자 영상 품질 판단 WAIT. Fire 단독 설정·고정 input manifest·별도 Native mapping/factory·Metadata source 연결을 준비했다. person 자동 fallback/Fire 자동 fallback·동시 모델·Fire Event·추가 NMS는 없다. Native 컴파일/contract/oracle PASS, 관련 source 회귀는 검증별 PASS와 fixture 보정 이력을 아래 evidence에 분리했다. 마지막 독립 settings CAS/저장 실패 보호1 test PASS. 실제 image/SDK Fire Pipeline은 미검증이다. image build/pull/배포/Start0, 기존 healthy/Stream stopped, image/env/model/mount·비대상 불변, GPU4420→4420MiB/task container0. 다음은 승인 영상 품질 수용과 image-owned SDK 경계 검증 뒤 제한 Runtime. 기존 Pose 수용·NMS 모델별 적용·디버그 도구 후속 잠금은 유지한다. ## Pose 사용자 수용·Fire 입수 준비 아래는 이전 입수 Batch의 상태다. 내부 시험 HOLD 해제와 현재 변환 결과는 위 FIREPATH-01이 소유한다. [입수 계약·보류·재개점](runs/20260913T222700+0900-run-fire-intake-pose-closeout.md). 사용자는 직전 Pose 실제 206/236/266 Frame의 제공 자료 범위에서 NMS·관절 표시·기능과 약10 FPS 결과를 수용했다. exact FP16 제한 수용이며 기존 numerical FAIL과 장시간/다채널 미검증은 유지한다. NMS 최적화는 보류, 공통 기능 재사용과 모델별 활성화 판단을 분리한다. Medium/Fire 자동 적용은 없다. 필터링 skeleton·NMS 전후 비교·비동기 debug clip은 Scenario 반복 테스트 도구 Batch로 보류한다. 디버그는 기본 Off·bounded·Metadata 우선·포화 시 생략이며 서비스 저장 동작으로 승격하지 않는다. Fire weight는 고정 Hugging Face revision의 LFS SHA256/크기와 일치한다. 비실행 pickle opcode 검사에서 RFDETRMedium/1.10.0 및 smoke_visible, flame_visible 순서를 확인했다. 실제 load/export 계약 PASS는 아니다. 게시자 권리 문서가 미완성 publication template이므로 내부 실행/변환과 상용 배포 허용 모두 확인 대기다. candidate manifest만 보존하고 model load/ONNX/FP16/image/Start 및 production source 변경은 모두0이다. 기존1.9.3 public loader 존재·Medium 기본 shape 설정은 정적 부분 정합이며 실제 호환성은 미검증이다. 권리 근거 확보 뒤 최소 안전 load/export→Fire 전용 class mapping→승인 영상 시각 검증 순으로 재개한다. 기존 manifest validator는 Fire를 등록하지 않았으므로 candidate를 실행 가능한 input으로 취급하지 않는다. 기존 Analytics healthy/Stream stopped 및 image/env/model/mount·비대상 상태 불변을 확인했다. ## Pose NMS·실제 연결 마감 [POSE-NMS-01](decision/20260913T211634+0900-decision-pose-nms-output.md)과 [SDK/실제 Pose 검증](runs/20260913T211634+0900-run-pose-nms-runtime.md). 이전 ingress 실패는 fixture PYTHONPATH가 image의 /opt/contextra를 누락해 binding import에 실패한 준비 오류였다. 서비스 PYTHONPATH 보존 후 실제 SDK identity/Pose copy/release·Tracking/snapshot PASS. Pose만 class-aware greedy IoU NMS>.85 적용, 동점은 원본 순서, bbox/keypoints 일괄 선택. Frame 공통 COCO17 이름/좌표/score 의미와 NMS 집계를 추가했다. source/image 각51 tests PASS. 기존 exact FP16은 사용자 제한 수용, raw numerical FAIL은 보존. 재변환0. 새 image pose-nms-30af673-2ef8ad7e와 별도 Pose version2/batch1/576 config를 유지 반영했다. 승인 file sync=True·Pose만1 window에서 결과/Redis9.9798 FPS, stale/queue drop0, 실제 NMS 누적 평균3.107ms, Tracking 최근256표본 평균4.753ms, cleanup2.217초 PASS. 206/236/266 Frame의 JPEG/JSON은 같은 run/PTS로 Redis와 일치하고3초 간격이다. 기존 카메라 입력/ROI/표시/Pose 시험 설정 복원, capture/진단 mount 제거, restart on-failure:3, healthy/Stream stopped. 다음 일반 Start는 원래 카메라의 Medium 설정이며 Pose 자동 활성화는 아니다. 사용자 새 NMS 시각 확인은 위 최신 입수/마감 run에서 수용 완료했다. 단일 채널/짧은 검증 한계와 기술적 연결 blocker 없음은 유지한다. 다음은 추가 디버그 최적화 없이 Fire 경로와 FALL 의미 잠금. Artifact/HTTP는 계속 후속이다. ## Pose 연결 재개점 아래는 직전 Batch의 역사적 상태다. SDK blocker·사용자 FP16 수용·실제 반영의 현재 판정은 위 최신 run이 소유한다. [POSEPATH-01](decision/20260913T195901+0900-decision-pose-provider-output.md)과 [변환/source/SDK 한계](validation/20260913T195901+0900-validation-pose-conversion-source.md). 기존 Pose intake manifest/weight 동일성, 공식 exporter 1.9.3, weight load, reference→ONNX는 PASS. FP16 plan build1회 완료. 실제 weight는 legacy [0,17], 출력 dets[1,100,4], labels[1,100,2], keypoints[1,100,34,8]이다. C++ decoder는 공식 후처리와 최대차5.96e-8, 관련47 tests PASS. FP16 raw numerical FAIL은 보존하고 자동 재변환하지 않았다. 승인 영상20/23/26초의 offline reference/FP16 비교3쌍은 사용자 제한 수용 대기이며 실제 Pipeline/Redis 자료가 아니다. SDK fixture는 ingress observer false가 PTS 교정 전후2회 반복되어 중단. Pose copy/release까지 도달했는지 확인하지 못했다. 신규 image build0·배포0·Start0. 원인 미확정이며 실패 단계의 예외/선택 reason을 보존하도록 probe만 보강했고 세 번째 실행은 하지 않았다. 서비스는 기존 capture image healthy/Stream stopped, Metadata 인증/LAN·Medium version2·표시.25 유지. 다음은 보존 모델을 재변환하지 않고 SDK ingress 실제 원인 판별→필수 회귀→사용자 FP16 수용→ exact snapshot/image/실제 Pose window다. 부분 연결을 전체 Pose 완료로 선언하지 않는다. 기존 Det/Pose 무조건 병행/join은 POSEPATH-01 범위에서 superseded이며 one-decode/identity는 유지한다. ## 캡처 색상·Off/On 비교 마감 [CAPTURE-RGB-01](decision/20260913T162705+0900-decision-capture-rgb-isolation.md)과 [실제 Off/On·색상·복원](runs/20260913T162705+0900-run-capture-off-on-rgb.md). SDK CPU 배열을 RGB로 명시하고 render_rgb 경계를 사용했다. 약3.16초의 Torch/CUDA 준비는 opt-in lifespan으로, flag 조회는 visual worker로 옮겼다. callback은 nonblocking/상한/.5초 주기를 적용하고 검증되지 않은 GPU buffer 비동기 소유권은 추가하지 않았다. source/image각29 tests PASS. 동일 승인 영상의 새 실행2회, 공통Frame39→119에서 Off9.9906/On9.9860 FPS, stale/queue drop0. Tracking wall22.45/22.98ms와 thread CPU19.86/19.55ms, Scenario약.85ms로 관측됐다. 첫 캡처35는 공통 구간 직전이며 copy42.13ms로 별도 기록했다. 전체 capture 포함 보조 On 구간도 약9.987 FPS/drop0이지만 Off와 경계가 달라 별도 참고다.15FPS/16채널·최대 성능 보장은 아니다. 실제 이미지35/41/46와 Redis JSON3쌍 일치, 원본 같은 PTS와 RGB 정합 확인. 이후 사용자 시각 확인 완료. 새 capture-isolation-1e952a2-202a1938 image 유지, healthy/Stream stopped, 원래 입력/시험 설정/restart 복원·임시 mount 제거. 다음은 Pose/Fire이며 추가 debug 튜닝은 선행하지 않는다. ## INTRUSION 실제 영상·출력 설정 반영 아래는 선행 회차의 당시 결과다. 캡처 색상/성능의 현재 상태는 위 최신 run이 소유한다. [출력 선택 잠금](decision/20260913T151612+0900-decision-intrusion-output-settings.md)과 [실제 회차·교정·복원](runs/20260913T151612+0900-run-intrusion-offline-output.md). 표시 카테고리 선택(null=기존 전체/[]=일반 표시 없음), Scenario 우선권, ROI 이름/주황 점선, PTS와 계산 UTC 구분, opt-in 전체 후보 debug를 settings 경계에 연결했다. 초기 source/image각26 PASS, 캡처 교정 source16/image21 PASS. 새 고유 image2개/실제 offline2회. 첫 회차는 capture geometry 불일치와 실패 추출 상한 누락을 확인했고 API timeout/cleanup 미검증으로 안전 종료했다. 교정 뒤 회차2에서 Event3개·Redis, 실제 Frame28/29 이미지/JSON 정합·제어·cleanup0.239초 PASS. 캡처 포함8.267초간 Native 약10.040 FPS, Result/publisher submit 약7.500 FPS다. **10FPS 성능 PASS가 아니다.** 새 intrusion-live-bc70f1d-579e678b image를 유지하며 healthy/Stream stopped, 원래 입력/시험 설정/restart 복원, 임시 mount 제거 완료. 기존 RTSP 추가 실행0, Metadata 인증/LAN·모델·비대상 서비스 보존. 사용자 시각 확인과 capture-Off Scenario 처리량·capture 지연은 별도 미검증이다. Event는 NOT_SUBMITTED/URI null이며 durable 접수·Artifact·HTTP는 후속이다. 다음은 Pose/Fire 경로이며 추가 표시 최적화나 동일 Runtime 반복을 선행하지 않는다. ## 선행 INTRUSION source·재생 기록 아래는 직전 source Batch의 당시 범위다. 현재 image/실제 실행 상태는 위 최신 run이 소유한다. [최신 잠금 INTRUSION-01](decision/20260913T135551+0900-decision-intrusion-frame-contract.md)과 [구현·격리·재생 검증](validation/20260913T135551+0900-validation-intrusion-source-replay.md). 기존 엔진 판정/기본값/자동 등록은 상속하지 않고 제거했다. 실제 Frame result worker에서 person confidence>.5·ROI 내부 유효 .5초·방문1회·외부1초 재무장·.5초 유예·30초 bounded 이력을 처리한다. 카메라 settings CAS/controlled restart, Scenario 우선 표시, 같은 Frame Event/point/ROI/revision을 연결했다. 관련60 test 실행 PASS. 보존된 실제 영상/FP16 결과60 Frame 재생에서 Event7개, 처음은 Frame5, 사용자 확인용0/5/59 이미지·JSON3쌍을 준비했다. **새 GPU/Redis Runtime PASS가 아니라 replay**다. Event payload는 NOT_SUBMITTED, Artifact URI null이며 Outbox/HTTP 보존·접수와 구분한다. Image/build/운영 Start0. 기존 healthy/Stream stopped 유지. 다음은 승인 원본 offline 입력의 mount/CAS/ 복원 원장을 준비하고 이번 변경+Tracking source를 새 image에 묶어 실제1 window를 검증하는 것이다. 사용자 시각 승인·실제 FPS/SDK cleanup·Event durable 접수는 각각 미완료 범위로 남긴다. ## Tracking 비교·빈 클래스 wrapper 최소 개선 [동일 입력 비교와 source 검증](validation/20260913T115200+0900-validation-tracking-cost-comparison.md). 기존 image/CPU2/RAM4GiB/BLAS1에서 Contextra와 SSIMS 실제 함수에 동일 후보를 공급했다. 12후보/2클래스 평균은1.873/0.988ms였고,300후보/12클래스는23.049/61.596ms였다. SSIMS는 자체 Ultra core·다른 association/결과 가공이므로 항상5배 차이나는 동일 알고리즘으로 보지 않는다. Contextra의 빈 클래스에도 반복되던 Detections/wrapper 비용만 제거했다. 공개 update_with_tensors에 빈 tensor를 전달해 core update·lost/activation clock·ID counter는 그대로 유지하며 tracker를 삭제하지 않는다. 기존80클래스 중2개 활성인 동일 process 교대 비교는9.857→6.897ms(약30%)였다. 소수 객체 조건은 거의 같다. 관련18 tests·300 Frame의 candidate ID/상태 정합·추가110 Frame 교대 비교 PASS. 초기SDK import shim 누락은 fixture만 보완했다. Image build/배포/모델/RTSP0, SSIMS source/runtime 변경0. 이 변경은 **source에만 반영**됐고 실제 image는 반환값 교정 버전을 유지한다. 다음 기능 Batch에서 app/byte_tracking.py와 관련 tests를 함께 package/import 검증한다. 기존 운영9.982 FPS/cleanup evidence는 그대로이며 새 최적화의 실제 Runtime 효과는 미검증이다. 추가 core/threshold/알고리즘 변경은 선행하지 않는다. 다음은 Scenario 의미 잠금과 독립 Pose/Fire·Artifact 목표이며 이 source 개선의 필수 blocker는 없다. ## 소비자 반환 교정·실제10 FPS 회복 [최소 교정·SDK·image·실제1회](runs/20260913T105400+0900-run-receiver-return-fps.md). 정상 소비와 Stop/stale/finite 상한의 의도적 폐기는1, 실제 처리 예외는 기존 lifecycle 실패를 보존하고 -1을 반환한다. finite 상한 뒤 중복 처리/Stop 예약도 차단했다. Source/image 각41 tests PASS, 모델 없는 실제 SDK3buffer 대조는 반환0 약3.003초/반환1 약0.002초, 처리횟수·EOS·wait 종료 PASS다. 새 image1/build1·실제 Start1/Stop1에서 워밍업5초 뒤15.428초간 결과/Redis154 Frame, **약9.982 FPS**로 이전0.961 FPS에서 회복했다. RTP/identity·Tracking·모델·pool·threshold는 유지했다. 전처리→infer 평균2032→24.17ms, 첫 결과3.163초·cleanup0.109초. 단일 채널 정상 처리/종료 범위를 마감한다. Analytics healthy/Stream stopped, 새 image·인증/LAN·표시0.25·10 FPS 설정·BLAS1·explicit Anchor 유지. 상세 계측/capture Off·restart 복원·start diagnostics만 다음 승인 recreate까지 RETAIN. Stop 후 Redis key는 기존TTL로 만료돼 RTP 필드 별도 재확인은 하지 않았다. Live Redis 동일 run/geometry 읽기와154송신은 확인했다. 다중16채널/장시간/탐지·Tracking 품질/외부 동기화는 별개다. 이1 FPS 결함에 대한 추가 audit·RTP Off/On·성능 tuning은 선행하지 않는다. 다음은 사용자와 Scenario 의미를 잠근 뒤 기존 Tracking 기반 Scenario/Artifact 및 독립 Pose/Fire 목표로 진행한다. ## 최소 SDK 성능·소비자 반환값 결함 [기본1회와 표적 audit](runs/20260913T004100+0900-run-sdk-baseline-consumer-return.md). 현재 image·동일 version2 plan/config/custom 전처리·processor와 공식 Flow.retrieve를 재사용한 합성 live 기본 경로는 워밍업 뒤15초/225 Frame, 약15 FPS였다. 전처리 출력→infer 출력 평균23.87ms, SDK wait thread 종료8.2ms·전용 Triton 종료·GPU 복귀를 확인했다. 실제 RTSP Decode/identity/Tracking/ Redis/service callback은 제외했으므로 운영10 FPS나 RTP 단독 무영향 PASS는 아니다. 표적 대조에서 production `_make_retriever.R.consume()`가 정상 소비 후에도0을 반환함을 확인했다. 공식 SDK 계약은 소비 buffer 수를 반환하며 예제는1이다. Exact 설치 library의 공개 `DataReceiver::consume(Buffer)` 정적 분석에서 반환0이면 **1초 nanosleep**을 거친 뒤 retry 상한을 판단하는 분기를 확인했다. retries0도 최초 대기를 건너뛰지 않는다. 약1 FPS의 강한 설명이며 Snapshot/RTP를 주원인으로 단정하던 접근보다 이 계약 위반 교정이 우선이다. 기본과 production의 반환값 차이도 구성 차이로 명시했다. RTP 대조0: 합성/RTSP 혼합 비교는 하지 않았고, 구체적 소비자 결함을 찾은 뒤 추가 모델 실행을 중단했다. Production 수정/build/배포0, Analytics healthy 및 기존 stopped/설정 보존. 다음은 정상 소비1 반환·Stop의 의도적 폐기·실패 음수의 SDK/lifecycle 의미를 구분한 최소 source 교정, 직접 SDK 반환값 회귀와 실제 서비스 제한 검증이다. 수정 후 실제 FPS/cleanup은 미검증이며 단독 원인·전체 해결·16채널 성능은 주장하지 않는다. ## 상시 Snapshot 정리·Tracking/BLAS 보정 [최신 합의](decision/20260912T234000+0900-decision-snapshot-retirement-tracking-artifact.md)와 [source/image/실제2회](runs/20260912T234000+0900-run-snapshot-tracking.md). Web ROI용 Snapshot API·CPU 최신 Frame 캐시·매 Frame GPU→CPU 복사를 제거했다. opt-in debug/AL과 Metadata snapshot은 보존했다. DISCARD sink로 RGB 변환까지 제거한 후보는 첫 Frame/cleanup 실패로 채택하지 않았으며 최종은 기존 SDK retrieve/RGB 경로를 유지한다. 첫 실패에서 Analytics를 안전 중지했다. Tracking adapter의 한 번 배열화/그룹화는 300후보·12클래스·35 Frame 비교에서 이전 ID/empty/reset 정합을 보존하고 준비비용 약1.65→0.76ms, 전체19.62→18.41ms였다. BLAS 기본20/20→1/1 자체 속도 이득은 뚜렷하지 않았으며 Python process 시작에만 제한했다. Triton에는 전파0, OMP/MKL/OpenCV 변경0. 최종 source/image 각44 tests PASS, 실제 결과/Redis0.961 FPS·Tracking평균9.85ms·cleanup2.208초, healthy/stopped·표시0.25·모델/인증/LAN 보존. 상세 계측Off·restart 복원·start diagnostics RETAIN. **10 FPS는 여전히 미달**이다. Snapshot 제거 후에도 선택→전처리 약1.015초·전처리→infer 약2.032초 경과가 남아 Snapshot이 주원인이라는 가설은 약해졌다. callback/SDK queue·consumer 수명 대기는 미확정이다. build2/window2/실패묶음1. 세 번째 실행·새 옵션 탐색 없이 종료한다. 다음은 이미 제거한 Snapshot이 아닌 남은 SDK 경로의 대기 위치를 표적 구분하는 것이다. 모델/전체 Audit·종료 원인 조사는 반복하지 않는다. Artifact는 필요한 채널의 bounded 압축 캐시+Event 후 비동기 처리, clip1280x720/thumbnail640x360과 비율 유지/padding을 후속 목표로 기록했다. 아직 Artifact·Scenario·Pose/Fire 구현은 하지 않았다. ## 10 FPS 선택·저부하 계측 [최신 합의](decision/20260912T211644+0900-decision-fps-bounded-observation.md)와 [구현/실제 실행](runs/20260912T211644+0900-run-fps-metrics.md). canonical Det ingress의 모든 Frame identity 발급 뒤 PTS 선택, analysisFpsTarget 기본10과 settings CAS, 단일-camera batch 보호를 연결했다. ByteTrack threshold는 그대로이며 lost buffer 환산용 frame_rate만 analysis target과 맞춘다. Det/Pose one-decode/join·다중 batch는 아직 미완료다. 기존 SDK public probe에서 bounded 숫자 집계·try-lock·최대60초 상세 계측을 사용한다. 새 worker/I/O0, SDK per-frame stdout 계측 module은 그대로 붙이지 않았다. 관련 source/image 각43 tests·SDK copy/drop PASS. image1/build1·실제 Start1/Stop1에서 저장 Off·계측 Off/On 각12.5초를 측정했다. 실제 결과/Redis는 1.038/0.956 FPS로 **10 FPS 미달**이다. 선택→전처리 출력1021.8ms, 전처리 출력→infer 출력2043.0ms는 queue 포함 경과시간이며 GPU 연산시간이 아니다. Triton32요청 평균서버12.54ms/compute8.54ms, Tracking13.76ms/result worker16.50ms로 초 단위 지연의 직접 원인은 미확정이다. Off/On 차이는 짧은 순차 표본이며 계측 인과 부하율/무누수 보장이 아니다. observation missed0, cleanup2.606초·healthy/stopped·표시0.25·모델/인증/LAN 보존. 상세 계측 Off, 시각 env/mount 제거, start diagnostics만 다음 승인 recreate까지 RETAIN. 시험 Anchor는 기존 explicit synthetic 설정 유지. 다음 최소 범위는 기존 retrieve callback 전체·Snapshot GPU→CPU 복사·SDK queue 대기의 표적 구분이다. 모델 재변환/precision·pool 탐색 또는 같은 window 반복으로 확대하지 않는다. 원본1920x1080, 모델576x576, debug 최대1280x720이며 공통720p 처리 surface는 이번에 반영하지 않았다. 사용자 시각/JSON 간단 확인은 승인됐다. 업무 Event와 opt-in debug 저장은 별개이며 디버그 영상/RTSP 재생기는 첫 Scenario/Artifact 작업에 연결하고 상시 미리보기·관측 플랫폼은 후속이다. ## 실제 source 구성 교정·RTP 연결 마감 [최신 실행](runs/20260912T195459+0900-run-flow-boundary-rtp-pass.md)과 [개발단계 예산/복원 원칙](decision/20260912T195459+0900-decision-bounded-correction-recovery.md). 실제 nvurisrcbin의 상속 signal을 SDK attach가 거부하는 결함과 dynamic source pad의 사전 probe 한계를 모델/RTSP Start 없이 확인했다. 기존 mux static pad setup probe/public target·GstBin lookup으로 exact source에 GObject signal을 연결하도록 최소 교정했다. SDK/private pointer patch0. 실제 worker source 구성·image loader·SDK copy PASS, 관련25 tests PASS. 실제1회에서 Flow 모든 세부 호출, SDK start/wait 반환·첫 결과3.499초·독립 /live30/30·Start202/Stop202·cleanup2.527초 PASS. 실제 RTP/clock rate와 source Frame→Redis JSON/JPEG3쌍·임시 Anchor 계산 일치. SYNTHETIC_TEST_ANCHOR/ ESTIMATED이며 실제 촬영 절대시각/Web 동기화 PASS가 아니다. 표본 trackId 미관측/품질 평가는 보류다. 새 image 유지·Analytics healthy/Stream stopped·표시0.25·인증/LAN/모델/비대상 보존. capture Off·restart 복원. 시험 Anchor는 camera settings에 explicit synthetic으로 RETAIN하며 다음 restart/recreate에도 유지된다. 공동 연동에서 교체/null 처리한다. 시험 파일 env는 Off, 진단/시각 mount는 다음 승인 recreate에서 제외한다. 누적 실패2·build1·live1, 실제 검증은 시작 후 약17분에 완료했다. 이후 문서/마감만 수행한다. 아래 Flow/API WAIT는 과거 기록이다. 모든 과거 timeout의 GIL/lock 인과를 확정하지는 않지만 이번 연결 범위는 마감하며 같은 실험을 반복하지 않는다. 다음은 기존9월 목표 Pose/Fire 또는 사용자 설계 후 Scenario다. ## RTP loader 교정·남은 Flow 중단 [최신 loader 검증/실제1회/복원](runs/20260912T172837+0900-run-rtp-loader-flow-stall.md): plugin-local RUNPATH만 교정했다. 실제 서비스 library 환경에서 fresh scanner·blacklist·명시 load·factory attach와 CPU SDK RTP copy/release를 source/image 각각 통과했다. SDK lib 경로를 LD_LIBRARY_PATH에 추가하지 않았고 기존42개 전체 회귀는 반복하지 않았다. build1회/18.004초, 실제 window1회다. 실제 기동/readiness와 plugin 초기화 확인·기존 shared library 로딩 오류0. 그러나 Start202 이후 API timeout·Stop 응답 미확인이 재발했고 마지막 표식은 Pipeline 생성 반환→Flow enter다. Loader 오류는 해결됐지만 API 중단의 유일 원인은 아니었다. 실제 RTP/Frame/Redis/JPEG/정상 cleanup은 WAIT다. 이전 image/env/시험 설정으로 복원해 healthy/Stream stopped·표시0.25·on-failure:3·모델/인증/비대상 보존. 새 capture/진단 override 제거, 이전 시험 Anchor/진단 RETAIN만 복원했다. 후보 image는 보존·비활성이다. 다음은 source batch_capture/property/RTP attach→후단 Flow 구성의 정확한 정지 호출을 최소 분리하는 것이다. 모델/RTSP Start 없이 가능한 경계를 우선하며, 새 관측 없이 같은 live window를 반복하지 않는다. 아래 loader FIX WAIT는 이전 시점이며 이번으로 교정됐다. 외부 Anchor 개발 전제·9월 우선순위는 유지한다. ## 외부 Anchor·실제 RTP 연결 [최신 시간 계약](decision/20260912T170501+0900-decision-external-anchor-rtp-zero.md)과 [구현/실제1회/복원](runs/20260912T170501+0900-run-rtp-anchor-packaging.md): 미디어 서버→Web→AI의 외부 Anchor 전달을 기준으로 한다. startWallTimeMs를 현재 RTP-zero 절대시각으로 임시 해석하고 외부 시간축/실제 동기화 확인은 다음 주에 보정한다. 이 미확정 자체는 AI 개발 blocker가 아니다. 공식 RTP header/ReferenceTimestampMeta·SignalHandler·NvDsMeta를 이용한 source 연결과 Anchor settings CAS/계산을 구현했다. Source/image 격리 각42 tests·실제 SDK metadata copy/release PASS. 그러나 실제1회는 readiness/Start202 뒤 API timeout, 마지막 Flow enter에서 진행 미확인이다. 로그에 새 plugin의 libnvds_service_maker.so 로딩 실패가 확인됐으며 격리의 추가 library path가 이를 가렸다. RTP/첫 Frame/Redis/시각/cleanup PASS가 아니며 SDK/GIL 원인은 단정하지 않는다. 이전 image/config로 복원해 Analytics healthy/Stream stopped, 인증/LAN/version2/비대상 보존. 독립 승인된 표시 **0.25**는 기존 settings CAS로 저장/유지했다. ByteTrack/collector/global 기준은 불변이다. 새 RTP image는 보존·비활성, 새 시험 설정은 복원, 이전 시험 Anchor/진단 RETAIN은 다음 승인 recreate에서 제외. 다음은 plugin loader 경로 최소 교정→실제 서비스 환경 image load 확인→새 image에서 제한1회다. 전체 Audit·과거 종료 실험을 반복하지 않는다. 사용자 시각 레이아웃1~4 확인 완료, 탐지 품질은 별개다. ## 개발용 시각 확인·시험 Anchor [최신 승인](decision/20260912T091739+0900-decision-debug-visual-test-anchor.md)과 [구현·검증](runs/20260912T091739+0900-run-debug-visual-test-anchor.md): 상단 후보 집계/클래스별 수, 사람 초록·굵은 bbox, 다른 클래스 고정색, label 배경/겹침 회피와 생략 수를 개발용 렌더러에 반영했다. Redis color/업무 표시 의미는 바꾸지 않았다. 이 window 당시 표시0.1을 저장/유지했다. 현재는 위 승인0.25가 우선한다. source 및 최종 image 관련36 tests·실제 SDK Anchor copy/release PASS, 실제 Start1/Stop1에서 동일 Frame Redis JSON/JPEG3쌍 일치·첫 결과3.657초·cleanup2.441초 PASS. 사용자 시각 확인은 대기다. 시험 문서의 exact Anchor/clock rate는 명시 test-source 설정으로 전달하되 timeSource=SYNTHETIC_TEST_ANCHOR, syncStatus=UNAVAILABLE다. ingestTimeWallMs는 실제 AI 관측값이며 raw RTP·detectedAtWallMs는 null이다. 원본 RTP 추출/Frame 연결·시각 계산/wrap은 이번에 보류했다. NTP/PTS를 RTP로 rename하지 않는다. CLI/Runtime은 exact FP16 plan·정규화/decoder 계약이 같지만 resize 구현·decode 색 변환은 비트동일 검증이 아니다. 새 image 유지·Analytics healthy/Stream stopped·인증/LAN/모델/비대상 보존. capture Off·restart 복원, 현재 test Anchor/진단 mount는 다음 승인 recreate까지 RETAIN, 기본 active compose는 해당 시험 설정 Off다. 추가 Runtime/정확도 실험 없이 사용자 이미지/JSON feedback 뒤 기존 주간 목표로 진행한다. 아래 표시0.5 복원은 이전 window의 기록이며 현재 승인 테스트 카메라는 위 capsule의0.25가 최신이다. ## AI Metadata 유지 반영 완료 [유지 반영·자체검증](runs/20260911T210531+0900-run-metadata-active-lan.md): 같은 검증 image와 인증/LAN 설정을 실제 유지했다. Start1/Stop1에서 첫 결과5.412초·Redis Frame6·같은 Frame JPEG/JSON3쌍 일치, 표시 후보12/13/14·공통 trackId1, cleanup2.546초 PASS. production 수정/build/두 번째 실행0. 최종 Analytics healthy/Stream stopped·on-failure:3, 표시0.1은 원래0.5로 복원·capture Off. Metadata auth/LAN은 활성 유지하며 승인된 회사 PC2개만 reader 대상이다. AI host LAN 읽기/ACL 및 기존 Analytics 내부 reader 예시는 PASS, **동료 PC 접속 요청/공동 연동은 다음 주**다. Web 대기는 AI 준비 완료의 blocker가 아니다. 읽기 자료/별도 credentials는 private `/workspace/contextra-runtime-config/metadata-active/reader/`, 기본 반영 명령은 같은 부모의 `OPERATIONS.ko.md`에 있다. 기본 Compose만으로 recreate하지 않고 private override를 포함한다. 기본 persistent compose는 진단/capture Off다. 현재 container의 진단/visual mount/env는 추가 recreate를 피하려고 RETAIN했고 다음 승인 recreate에서 task diagnostic override를 제외한다. 재부팅/PC 실접속 미검증. 이전 미도착 원인·장시간 안정성·정확도 평가는 미확정으로 보존한다. AI 자체 전달 범위는 이번에 마감하고 기존 일정의 INTRUSION/독립 Pose·Fire·Artifact 후속으로 이동할 수 있다. 기존 종료 실험을 반복하지 않는다. 아래 복원 상태는 직전 진단 종료 시점이며 현재 Metadata 유지 상태는 이 capsule이 소유한다. ## Metadata 경계 진단 결과 [관측 보완·실제1회](runs/20260911T204432+0900-run-metadata-boundary-observation.md): 같은 lifespan image를 재사용하고 기존 runtime_observation/SDK 표식 보존을 보완했다. build/production 수정0, LAN 공개0. 이번에는 약28.16초에 첫 결과가 도착해 mux→preprocess→infer→Native→collector/result→Redis까지 전달됐고, 동일 Frame JSON/JPEG3쌍과 Redis payload가 일치했다. 표시 후보7/7/5·공통 trackId1, JPEG1280x720 확인. 이는 낮은 표시0.1 조건의 연결 검증이며 탐지/Tracking 정확도 PASS가 아니다. Stop 대상 일치·호출 반환·SDK wait 반환, Stream cleanup2.207초 완료. 두 번째 실행0. 마지막 도달 지점은 Redis/시각 저장이며 이번에 수정할 production 결함은 확인되지 않았다. 직전과 달리 진단을 활성화하고 LAN 공개를 제외했으므로 이전 first-result 실패 원인을 해결했다고 단정하지 않는다. 반복 진단/재build 대신 검증 image와 Metadata 접속 설정의 유지 반영·동료 읽기 준비가 다음 최소 범위다. 재발 시 이번 counter 원장을 사용하고 새 근거 없이 같은 실험을 반복하지 않는다. 요청대로 이전 actual 구성 복원: Analytics healthy/Stream stopped·on-failure:3·Redis port0, env/overlay/model/비대상 보존. 이번 capture/진단 mount 제거, task 결과만 private 보존. 아래 첫 결과 WAIT/cleanup FAIL은 직전 window의 historical 결과이며 이번 성공으로 삭제하지 않는다. ## 단일 lifespan 반영·Metadata 실제 window [최신 구현·실행](runs/20260911T202500+0900-run-lifespan-metadata-window.md): app 단일 lifespan으로 publisher/Stream load/retention 초기화·종료를 모았다. 실제 ASGI lifespan·부분 실패 cleanup·기존 API를 포함한 source/image 각17 tests PASS, incremental build4초. 새 image의 기동/Infra·인증 Redis·AI host LAN 읽기/ACL PASS이며 기존 FastAPI startup 중복 실패는 재현되지 않았다. 실제 Start1/Stop1은 첫 결과60초 미도착, result processed0/JPEG0. Stop202 뒤 cleanup60초 상한에서 오류가 남아 Analytics 안전 중지 후 이번 image/env/overlay/auth/LAN만 이전 actual 구성으로 복원했다. 최종 Analytics healthy/Stream stopped·on-failure:3, 모델/비대상 불변·Redis port0·새 방화벽/unit 제거. 표시0.1·capture flag 제거/복원. 새 private 설정은 미적용 staging이며 동료 접속용으로 전달하지 않는다. app startup/shutdown 완료와 Stream cleanup 실패는 서로 다른 범위다. Redis 실제 Frame·시각/ID는 WAIT. 이번 helper는 metadata_path 위주로 보존해 기존 단계별 runtime_observation을 누락했다. 다음은 이 기존 counter와 SDK 호출 표식을 같은 원장에 보존할 최소 helper 보완 후 전달 정지 경계 확인이다. 입력/전처리/infer/시각 callback 중 원인은 미확정이며 추가 source 수정·재배포·live 재실행은 하지 않았다. 아래 단일 lifespan 교정 대기는 이번 source 구현으로 해소됐다. 기존 종료 마감·9월 목표는 유지한다. ## 기동 실패 경계 확인 [기동1회 진단](runs/20260911T173053+0900-run-startup-lifespan-diagnostic.md): app69개/entrypoint와 image snapshot 정합·순수 설정 검사 PASS 뒤, LAN 공개 없이 같은 image/auth 설정으로 실제 기동1회·Stream0 수행. 시작부터12321bytes 로그 확보, 약16초 exit1/OOM false. Triton 준비 뒤 FastAPI startup이 실패했다. 설치 FastAPI0.138.1의 parent event 복사+child lifespan 병합이 router startup을 중복 실행하는 경계를 확인했다. 첫 Stream load 완료 뒤 두 번째 Metadata 초기화를 guard가 거부하는 source 경로와 실제 traceback이 일치한다. 다음은 app/main.py의 router legacy event를 앱 단일 lifespan으로 모으고 실제 lifespan 횟수/실패 cleanup을 검증하는 최소 교정이다. guard 제거·SDK/모델/버전 변경·재조사 불필요. 이번 source/test 수정0·두 번째 기동0. 복원 후 actual Analytics healthy/Stream stopped·on-failure:3, env/model/overlay·비대상 보존·Redis port0. 아래 원인 미확정은 직전 시점 기록이며 상세 실패 로그 미확보 한계는 이번 진단으로 보완됐다. ## 인증 적용·새 image 기동 결과 [최신 적용·복원](runs/20260911T171135+0900-run-metadata-auth-image-rollback.md): 기존 Redis URL/예외 로그 비노출 최소 교정, source/image 각3 tests PASS·새 image build24초 완료. Redis ACL/healthcheck와 무인증 PING 차단을 확인했으나 새 Analytics가 약15초 뒤 exit1로 종료해 이전 actual 구성으로 복원했다. 실패 container 상세 로그를 복원 전에 보존하지 못해 원인은 미확정이다. 관측 helper만 보완했고 재배포0. Start0/Stop0·표시0.1 적용0·실제 Redis Frame/JPEG/Tracking 검증0. 기존 source/SDK PASS는 보존한다. 종료 actual Analytics healthy·Stream stopped·on-failure:3 복원, env/모델/비대상 보존, 새 공개 port/rule/unit 제거. private metadata-lan 설정은 **미적용 실패 staging**으로 보존하며 그대로 재사용/동료 전달하지 않는다. 다음은 이미 만든 exact image의 기동 실패 로그를 확보하는 제한 진단이다. 재build·전체 SDK/종료 조사부터 반복하지 않는다. 아래 인증 로그 blocker는 이번 source 교정으로 해소됐고 현재 blocker는 기동 실패다. ## LAN 적용 사전 확인·중단 [최신 actual preflight](runs/20260911T164550+0900-run-metadata-lan-auth-preflight.md): commit1edaa70f/clean, Analytics healthy·Stream stopped, 기존 Redis key0/default nopass/host port0 확인. 회사 테스트 PC2대만 접근 대상이며 현장 주소는 참고로만 보존한다. 실제 주소는 private evidence에만 기록했다. 기존 `metadata_storage.RedisMetadataPublisher`가 접속 URL을 그대로 로그에 출력하므로 인증 적용 시 비밀번호 노출 위험이 확정됐다. 실제 credential 주입/유출0. 기존 client 비활성화나 무인증 공개로 우회하지 않는다. source 결함 중단 조건에 따라 이번 application 수정/build/배포/Redis 설정/Stream 실행0, 기존 Runtime 유지. 다음은 해당 성공/실패 로그 최소 교정·fake client 비노출 회귀 후 기존 Medium 적용 절차를 이어가는 것이다. 새 Redis 구조나 반복 SDK/종료 조사는 필요하지 않다. 아래 source/격리 PASS와 현재 배포 WAIT를 구분한다. ## Metadata 송신·시각 확인 source 준비 [공유/표시 승인](decision/20260911T155808+0900-decision-frame-result-display-sharing.md)과 [구현·검증/다음 Medium 실행 절차](validation/20260911T155808+0900-validation-metadata-transport-visual-source.md): 불변 FrameResult 최신 참조, visible-only Redis projection, 표시 threshold 독립 설정, process-owned publisher composition/상태 heartbeat, CAS settings GET/PATCH, 같은 Frame의 bounded JPEG+JSON을 구현했다. 테스트 표시0.1 승인, ByteTrack/기존 collector 필터 기본값 보존. 최신 후보 보존은 참조 공유이며 전체 후보 직렬화는 opt-in만 수행한다. 기존 collector는 compatibility consumer 때문에 유지한다. 관련97 tests·후속20 tests와 CPU SDK→fake 송신 경계 PASS. 추가한 SDK Frame wrapper list 보관의 실패를 관측해 iterator 안 소비로 교정했고 재검증 통과, 실패 evidence 보존. 기존26 API operation 보존+추가3개 분리. .dockerignore source type/COPY 정적 정합 PASS, 실제 build/Redis/GPU pixel/Runtime 미실행. Redis 재사용은 조건부 후보이며 tracked 무인증 설정을 그대로 외부 공개하지 않는다. actual ACL/영향은 다음 Gate. 다음 Medium은 exact Redis 보안 승인→새 image/Analytics 설정 CAS→표시0.1/짧은 실제 송신·시각/ID 검증이다. 시각 도구는 우선 최대3장/60초 이미지이며 구간 영상은 미구현이다. 동일 Frame 불일치는 대체하지 않는다. 이번 Analytics/모델/운영 config 변경0, actual Runtime 조회0. 아래 healthy/stopped는 이전 window evidence다. ## 실제 Metadata image·Runtime [최신 image/실제 window](runs/20260911T144102+0900-run-metadata-image-runtime.md): 새 binding/supervision image 반영, source/image 각16 tests·SDK probe PASS. 실제 설치/source identity를 발급·보존하고 승인 Det-only Start1/Stop1을 수행했다. 실제 snapshot1개, Frame/run identity·1920x1080·normalized bbox 후보/표시 의미 확인, ordered processed8 표본. sample 후보300/최대 confidence 약0.226/표시0/trackId0으로 **유효 탐지·실제 Tracking ID 연속성은 WAIT**다. 후보 수를 실제 객체 수로 표현하지 않는다. 조건 탐색/재실행0. 첫 결과19.36초·cleanup2.676초는 한 window 관측이다. 최종 Analytics healthy/Stream stopped·pending/error0, on-failure:3 복원·비대상/model 불변. 수집 switch는 제거해 Off, sample/진단 env·mount는 다음 승인 recreate까지 RETAIN. 실제 JSON은 private task root에만 보존. 다음은 Redis transport/채널 상태·동일 Metadata 시각 확인 연결이며, 명확한 승인 입력에서 유효 탐지/ID WAIT도 함께 확인한다. 기존 SDK·종료 범위 마감과 9월 일정은 유지한다. 아래 image/Runtime WAIT는 각 historical 시점의 상태다. ## Frame·Tracking 현재 구현 범위 [호환 headers·SDK 검증](validation/20260911T140749+0900-validation-frame-identity-sdk-pass.md): 공식 pybind11 2.13.6 headers를 task venv에만 준비해 기존 public C++ binding을 빌드했다. SDK와 v5 ABI 일치, production observer→SDK metadata 부착/복사/원본 해제→Native/실제 ByteTrack→snapshot과 복사본 해제·worker 종료 PASS. 관련13 tests PASS, application/native source 수정0·전체87 회귀 반복0. 이번 source/SDK 연결 범위는 마감한다. CPU SDK fixture이며 실제 GPU mux/infer·영상 Tracking/성능은 미검증이다. 다음은 binding/supervision image packaging·명시 설치/source identity 주입과 짧은 Det-only Runtime 승인이다. 그 뒤 실제 Redis transport/같은 Metadata 시각 확인으로 진행한다. 이번 image/운영 Runtime 변경0. 아래는 직전 제약 이력이다. ABI blocker의 현재 상태는 위 후속 검증으로 해소됐으며 실패 evidence는 보존한다. [구현·SDK 제약](validation/20260911T134730+0900-validation-frame-tracking-source-sdk-gap.md): 명시 설치/source identity의 Det-only 경로에 ingress→Native Observation→ByteTrack→snapshot/publisher 입력을 연결했고 기존 격리 환경의 실제 ByteTrack·group cleanup 포함87 tests PASS다. 이미지/Runtime/Redis 미반영. SDK Python은 generic UserMetadata append를 지원하지 않아 public C++ overload의 작은 binding을 준비했으나, SDK pybind ABI v5와 기존 headers v11 불일치로 실제 identity copy/release 검증은 미완료다. 단위 PASS를 SDK/전체 Pipeline PASS로 승격하지 않는다. 비호환 실험 binary는 배포 금지·guard로 차단한다. 다음은 별도 승인된 `pybind11==2.13.6` 개발 headers 준비→같은 SDK ABI 빌드→기존 identity probe 검증뿐이다. 기존 image에 없는 supervision0.30.2와 binding packaging은 그 뒤 image 승인 범위다. 설치/기동/모델 실행0. identity 미설정 기존 Stream은 API 호환 경로/NOT_CONNECTED로 구분한다. one-decode·Pose join은 계속 후속 목표다. 종료 이슈 마감과 아래 일정은 유지하고 Pose/Fire·Artifact의 독립 작업을 자동 차단하지 않는다. ## 최신 9월 목표·우선순위 [최신 일정·완료 기준](decision/20260911T131415+0900-decision-september-deadline-delivery-priority.md): 9월 목표는 월말이 아니라 **다음 주 종료**다. 대화 기준 이번 주는 `2026-09-07~13`, 다음 주는 `2026-09-14~20`이며 주말 포함 작업/exact 마감 시각은 확정하지 않는다. 이번 주 목표는 Pose·Fire 모델별 변환/Adapter/결과, Tracking, Scenario 최소1개, 실제 Frame의 채널별 AI Redis Metadata·최소 시각 확인, 실제 Event clip/thumbnail·URI/HTTP 자체 검증이다. 다음 주 전반2~3일 공동 연동·후반2~3일 현장 설치와 네 Scenario를 목표로 하되 보장 일정은 아니다. 순서: 실제 Frame identity/Native Metadata→ByteTrack→AI Redis/같은 Metadata 시각 확인→ INTRUSION→LOITERING→FALL→FIRE. Pose·Fire와 Event/Artifact는 독립 가능한 범위에서 병행한다. Web 소비/Browser 합성은 Web Owner다. one-decode·Det/Pose join, null·부분/all-skip 계약은 유지한다. Fire 입력이나 외부 접속 정보 부족은 해당 단계만 분리한다. 이번 구현/Runtime/외부 조회0. 현재 적용 기준은 상단 구현 capsule과 하단 재개점이다. 아래 과거 조사 capsule의 ‘다음/미결정/WAIT’는 각 시점의 기록이며 최신 종료 마감·일정과 충돌하는 부분은 위 Decision과 최신 run이 우선한다. ## 종료·controlled restart 현재 마감 [최신 승인](decision/20260911T122239+0900-decision-bounded-async-cleanup-restart.md)과 [구현·실제 window](runs/20260911T122239+0900-run-async-restart-pass.md): B 적용, source/image 각72 targeted tests·실제 SDK drop12→3 PASS. 기존 exact version2 FP16을 유지했다. 실제 API Start1→Restart1→Stop1, 첫 결과1.87초, 이전 cleanup2.49초, Restart 요청→새 결과3.87초(새 SDK start→결과1.36초), 최종 cleanup2.58초. 새 runId/generation과 이전 cleanup 완료 뒤 새 SDK start 순서 확인, drop counter 최대43 관측. 최종 Stream stopped/cleanup·restart pending false/오류0, 승인 RTSP TCP 연결0, Analytics healthy·restart0/OOM false·on-failure:3 복원. 전체 container 안전 중지 불필요. 5초 SLA·평균 성능 보장은 아니며 실제 설정 변경은 미공개 API라 격리 manager 검증으로 분리했다. multi-camera 실부하·Event/Artifact On·장시간 반복은 미검증. A fallback은 사용하지 않았다. 현재 Det-only 종료 이슈 범위는 마감한다. 동일 종료 실험·39초 원인 조사 반복 대신 기존 Frame ingress/Metadata 연결과 Tracking·Scenario 선행 연결 작업으로 이동한다. Pose·Fire는 최신 일정에 따라 이번 주 모델 경로 준비 목표다. 입력·모델별 계약 확인과 실행은 별도 Batch다. ## 종료 폐기·비동기 cleanup 최소안 [SDK 폐기·재Start 표적 확인](analysis/20260911T113525+0900-analysis-stop-discard-restart-scope.md): DeepStream9.1은 BufferOperator.handle_buffer=False로 현재 buffer drop을 공식 지원한다. 현재 카메라별 mux/pre-infer probe에서 Stop 이후 미제출 Frame을 차단하는 작은 후보가 있으며, 이미 제출된 infer 취소나 모든 queue 즉시 비우기와는 다르다. 실제 drop/release·종료시간 효과는 미검증이다. 권장안은 이 공개 drop 경계와 비동기 cleanup을 조합하되 후자는 필수, drop은 명시적 폐기 범위 승인 뒤 적용한다. 단순 join60초 변경은 global command lock·15초 외부 cleanup 대기·controlled restart의 동기 분기를 해결하지 못한다. 설정 저장→이전 실행 cleanup 완료→새 설정/새 runId 적용의 continuation과 동일 채널 경합 보호가 필요하다. 최신 사용자 승인: 이전 실행 혼입 차단·개별 Stop/재Start·타 채널 보호는9월 필수, trackId/Tracking/Scenario 상태 계승·무중단 연속성은9월 이후 보류. Event/접수된 Artifact 보존은 별개다. 미결정: 미제출 Frame 폐기 정책, STOPPING/응답 의미와 cleanup 상한(60초는 후보)·초과 후 상태. Runtime/source/config 변경0. Analytics stopped는 직전 관측 상태이며 이번 재조회0. 다음은 위 좁은 정책 승인 후 기존 lifecycle/manager/probe의 source 구현·격리 검증이다. ## 실제 Stop60 교차 관측 결과 [관측 구현·배포·실제 window](runs/20260911T111110+0900-run-stop60-late-worker-exit.md): source/image 각각60 tests와 GPU0 실제 SDK 호출 경계 PASS. 새 image에서 Start1/Stop1, 첫 Frame3.101초·collector8을 확인했다. 같은 generation/role/관측 token에서 시작한 Pipeline과 SDK Stop 대상이 일치했고 호출은0.285ms에 반환했다. 앱은5.007초에 기존 worker_join 오류를 반환했지만 **SDK wait는 Stop 기준39.354초에 반환**, worker 마지막 정리39.355초·직접 is_alive=false/대상 TCP 연결0을40.72초 표본부터 확인했다. 60초 미종료가 아니라 이번 window의 늦은 종료다. 과거5초 관측을 영구 hang/누수로 확대하지 않는다. Stop 전/첫 후속 표본 TCP bytes는2575119→3297619, 이후 연결 제거 전까지 고정이다. buffer는 mux/preprocess/infer/consume 모두47까지 진행 후 정지했다. RTP packet 계측이나 지속 신규 수신 증거는 아니다. sticky cleanup 오류와 group 후속 정리는 그대로 남아 Analytics 안전 중지·restart on-failure:3 복원. 비대상 container·model/config/overlay 불변, 새 진단 mount는 중지 container에 RETAIN. 다음 최소 범위는 **HTTP 대기 예산과 비동기 cleanup 완료를 분리해 늦은 worker 종료 뒤 남은 정리를 이어가는 앱 보정안**이다. 정확한 최대 대기/실패 상태 해제는 후속 승인 범위다. 단순 join60초 교체·오류 무시·추가 Runtime은 수행하지 않았다. 39초 지연 원인·SDK 내부 EOS 시점·반복 안정성·다중 카메라 무영향은 아직 미확정이다. ## 60초 교차 관측 사전 Gate [관측 준비 확인](runs/20260911T104329+0900-run-stop60-observation-preflight.md): actual image/app62개 source 일치, Analytics exited·restart on-failure:3. 현재 Status는 실제 handle.is_alive를 제공하지 않고 SDK Stop 진입/반환/생략·bind 일치 표식도 없어 helper만으로 필수 판별을 충족하지 못한다. 사용자 조건에 따라 source 수정/build/기동/Start/Stop0, 60초 Runtime 미실행이다. 늦은 종료 여부는 미확정 유지. 다음은 기존 lifecycle·diagnostics·Status에 bounded opt-in 관측을 최소 추가하고 관련 검증·새 image를 별도 승인으로 준비하는 범위다. 이후 실제 서비스1회에서 Stop 기준총60초를 확인한다. 개별 카메라 Stop/재Start와 타 채널 무영향은 필수. 전체 Analytics 중지는 실패 안전조치만 소유한다. 기존5초 판정·sticky cleanup 오류 유지, URI 출처 재조사0, raw packet/식별값 저장0. ## 실제 Analytics 종료 계약 검증 [실제 서비스 window](runs/20260911T100936+0900-run-actual-service-stop.md): 기존 container/app62개 source 일치, image/model 변경 없이 Start1/Stop1. 첫 Frame2.351초/collector7·API 응답을 확인했지만 Stop5.011초 후 Contextra 자체가 STOP_CLEANUP_FAILED(worker_join)를 반환했다. media thread0→4, cleanup_pending=false/error 보존. 저장/Scenario/AL Off이며 writer flush 이전 실패이므로 Event/Artifact 작업 완료를 기다리는 정상 drain으로 해석하지 않는다. 개별 join5초는 앱 예산이지 SDK 보장 아니다. Analytics 안전 중지·restart on-failure:3 복원·GPU3828MiB 복귀. 다른 container/env/config/overlay 불변. 격리 환경만의 현상은 아님을 확인했지만 native 정지 원인·영구 누수는 미확정이다. 다음은 SDK 종료 지원 경계와 앱 종료 정책의 최소 교정안 판단이며 동일 Runtime 반복/단순 timeout 연장0. 기존 진단 mount 유지·새 stack은 O_EXCL로 생성 불가, historical stack 미사용/불변. source/배포/recreate0. ## stdin·EOS 보완 후 단일 live 결과 [보완 검증](validation/20260911T095217+0900-validation-stdin-eos-live-stop.md): task process에서 stdin pipe의 writer를 유지했고 CPU 실제 EOS·Stop/wait 종료와 같은 관측기의 전송 표식4개를 확인했다. live1회는 첫 Frame1.834초/collector5·Stop 반환 뒤에도 전달 지속, wait 미종료였다. EOF 방지만으로 해결되지 않았다. infer 제출11/완료 함수 진입11은 전체 cleanup PASS가 아니다. 선택 pad의 실제 EOS 전송0, 초기 eos_other17은 전달로 해석하지 않는다. 추가 live/설정 대조0. task 자원·GPU 복귀, Analytics exited/restart0 확인. production 수정/배포0. 다음은 보정된 최소 reproducer를 기준으로 SDK live Stop 지원 경계/문의용 자료를 정리한다. 실제 문의 게시·외부 업로드·process 분리·운영 변경은 별도 승인이다. 같은 실험은 반복하지 않는다. ## 공식 근거에 따른 종료 접근 재평가 [접근 재평가](analysis/20260911T092002+0900-analysis-stop-approach-reassessment.md): 구조 교체보다 검증 helper의 stdin/EOF 통제와 실제 EOS 관측 coverage 보완을 먼저 추천한다. NVIDIA 공식 저장소의 비대화형 실행 주의사항을 기존 helper가 반영하지 않았지만, 이것이 실제 원인인지는 미확정이다. Stop 반환/worker 종료 구분은 유지한다. EOS 경유·5초 join을 SDK 보편 보장이나 별도 제품 Gate로 삼지 않는다. 기존 EOS0은 미관측이며 upstream 결함 확정 근거가 아니다. 단순 sink 대조도 첫 Frame0으로 인과 판정 불가다. 동일9.1 증상의 확정 patch는 찾지 못했다. 다음은 helper만 최소 보완 후 별도 승인된 live1회이며 같은 조건의 재실행·production 설정 탐색·SDK 교체는 하지 않는다. 이번 Runtime/구현0, Analytics stopped는 직전 기록이며 재조회0. historical 실행 사실·미완료 cleanup은 보존한다. ## Live infer EOS·종료 관측 [EOS·output 대조](validation/20260910T215353+0900-validation-live-eos-drain-observation.md) 기본에서 collector5·Stop 반환 뒤에도 infer 제출12/완료 함수 진입11·retrieve sink 반환10이 관측됐다. infer 전후 EOS와 bus EOS는 미관측이며 wait는 종료하지 않았다. pending1을 영구 추론 정지로 해석하지 않는다. retrieve 대신 단순 sink를 둔 조건부 대조는 첫 Frame60초 미도착으로 소비자 영향 판정이 불충분하다. 기본1+대조1 종료, task 자원·GPU 복귀 확인, 운영 Analytics exited/restart0 유지·production 수정0. 다음은 SDK Stop 요청이 실제 live source/bin에 전달되는 공개 종료 경계의 표적 확인이다. 같은 추론 재실행·timeout 연장·pool 증설은 선행하지 않는다. 모델 없는 CPU Stop PASS도 유지한다. EOS가 infer 내부 sync에서 막혔다고 확정할 근거는 없으며 수신 전/관측 밖 정지 가능성을 구분한다. ## SDK Stop 계약 표적 확인 [CPU live 종료 검증](validation/20260910T213504+0900-validation-sdk-stop-contract.md)에서 기존 helper와 같은 생성/start-wait/Stop thread 배치로 Stop 반환→EOS 수신→wait 반환·thread 종료를 확인했다. 기본1회 PASS·대조0·모델/RTSP/GPU0. 일반 thread 사용이나5초 join 자체의 결함은 확인되지 않았다. SDK nvinferserver는 EOS 전 output queue sync, 그 queue는 inference future 완료를 기다린다. 이는 정적 대기 경로이며 직전 live 실패의 실제 정지 위치는 미확정이다. timeout 연장·process 분리·SDK 교체 근거0. 다음은 별도 승인된 live/infer 최소 window에서 EOS 도달과 in-flight/output 완료를 연결하는 관측이다. 모델 없는 실험 반복이나 전체 Runtime 재배포는 이번에 하지 않았다. production 수정0. ## 실제 RTSP live 분리 결과 [live/Stop 대조](validation/20260910T212002+0900-validation-live-stop-isolation.md) 기본에서 첫 Frame1.652초, collector5 Frame을 확인했다. Stop 호출은 반환했지만 SDK wait thread는5초 join 후에도 살아 있었다. 조건부 appsink async=false 대조는 첫 Frame60초 미도착·동일 wait 미종료로 개선되지 않았다. 서비스 manager/Tracker/Snapshot 없이도 종료 문제가 남으므로 service 문맥만의 문제라고 볼 수 없다. 전용 Triton/task container 종료·GPU 복귀 확인, 운영 mutation0. 기본1+대조1로 종료했다. 다음은 SDK live Stop의 EOS 요청/실제 loop 종료와 buffer 보유 경계를 표적 확인한다. async=false/pool 증설/transport 변경을 production에 적용할 근거는 없으며 추가 반복 실행0이다. ## Infer·retrieve 최소 대조 [전용 Triton 합성 대조](validation/20260910T205454+0900-validation-infer-retrieve-isolation.md)에서 기본 infer→sink와 조건부 production retrieve→collector가 모두12 Frame 전달/Native 완료·정상 종료를 확인했다. exact v2 FP16/기존 설정·library, network-none 전용 Triton만 사용했다. 운영 기동/배포/production 수정0. 단독 전처리뿐 아니라 합성 입력에서의 infer/Native/retrieve 소비도 작동한다. 남은 차이는 실제 RTSP live 상태·서비스 lifecycle/추가 소비자 문맥이다. 원인을 특정 plugin이나 GIL로 확정하지 않는다. 다음은 승인된 RTSP를 이 통과 harness에 연결해 live/infinite와 service 문맥을 구분하는 최소 검증 범위다. 이번 추가 실험0, 모델/정규화/pool 교정안0. whole service first-frame/cleanup은 계속 미완료다. ## GPU 전처리 분리 검증 [전처리/tensor-meta](validation/20260910T202451+0900-validation-preprocess-isolation.md)에서 실제 generated 설정·기존 GPU library·pool2를 그대로 사용한 합성12buffer의 전/후12·유효meta12·EOS/Stop을 확인했다. 공개 SDK user-meta release가 tensor/scaling pool을 반환하며, infer 없는 sink에서도 지속 전달됐다. 기본1회 PASS로 대조0, 모델 inference/운영 배포/production 수정0. 초기 loader 경로 누락1건은 fixture 이력이다. 다음은 infer의 input_tensor_from_meta 소비와 retrieve 통합이다. 전처리 단독 PASS를 실제 RTSP 전체 Pipeline/정확도/장시간 자원 PASS로 확대하지 않는다. 현 근거만으로 pool 증설·정규화 변경은 하지 않는다. ## 첫 Frame 최소 분리 검증 [합성·승인 RTSP 대조](validation/20260910T175851+0900-validation-frame-path-isolation.md)에서 합성GPU→mux와 실제 RTSP→production adapter→Decode/mux 모두 mux probe3/tail3·정상 Stop을 확인했다. 전처리/추론/retrieve를 제외하면 입력·mux·production probe 경로가 작동한다. 실제 모델 실행0, 운영 Analytics/Stream 실행0, 소스 수정0. task container/임시 입력 정리와 GPU 복귀 확인. 후단을 붙였을 때의 backpressure/연결·caps/tensor 계약이 다음 우선 범위다. 어느 plugin이 원인인지 아직 확정하지 않으며 전체 Pipeline의 first-frame/cleanup PASS로 확대하지 않는다. 추가 실행은 하지 않았다. 다음 최소 단계는 검증된 입력/mux 뒤 전처리를 붙인 경계 확인이며 RTSP transport·decoder·mux 재작성·모델 재변환은 현재 근거상 선행하지 않는다. ## Callback 교정·제한 Runtime 결과 [교정·SDK·실제 실행](runs/20260910T174034+0900-run-callback-fix-window.md)에서 production callback을 message1인자로 교정했다. 실제 SDK fakesrc/fakesink state message9개·EOS/종료 PASS, source25 tests·image34 tests/Native fixture PASS. 새 image 반영 후 callback fatal/API 중단은 재발하지 않았다. 상태 조회와 /live200은 유지됐지만 first-frame60초 동안 collector0, 이후 FIRST_FRAME_TIMEOUT과 STOP_CLEANUP_FAILED(worker_join)가 확인돼 Analytics를 중지했다. 실제 bbox/cleanup 완료는 미확인이다. 진단 중 restart=no, 자동 restart0. 종료 후 docker update로 on-failure:3을 복원했고 recreate/추가 Start0. 작은 새 원인 결함이 확인되지 않아 두 번째 회차는 사용하지 않았다. 이번 Runtime1/2, Start1/Stop1. 다음은 decoded/mux 출력 표식 이전의 입력·buffer 전달·downstream 대기를 구분할 최소 진단이다. callback 수정 반복·모델/precision/threshold·surface Audit은 선행하지 않는다. ## 시작 진단 Runtime 결과 [진단 window](runs/20260910T172235+0900-run-start-diagnostic-window.md)에서 새 image/Infra PASS 뒤 Start1/Stop1을 수행했다. source/profile/config·Pipeline/Flow·SDK start 반환과 sdk_wait 진입13개 표식을 확보했다. fatal 로그는 `on_message() missing 1 required positional argument: 'message'`와 `pybind11::error_already_set`를 보여준다. 현재 callback2인자와 실제1인자 호출의 불일치가 확인됐다. SDK wrapper docstring은2인자이지만 같은 SDK utils/test5 예제는1인자다. 이번 수정/두 번째 배포0. first-frame/collector/bbox·cleanup은 미완료다. stack0bytes, container exit1 뒤 기존 정책의 자동 restart1회가 있었고 Analytics를 중지했다. 사용자 API Start는1회뿐이며 자동 재기동 뒤 추가 Stream Start0이다. 진단 env/mount는 중지 container와 task override에 남아 있다. 다음은 callback1인자 경계 최소 교정과 실제 SDK message 호출 검증 후 별도 승인 Runtime 재검증이며, GIL/모델/복사 Gate 재조사는 하지 않는다. ## 현재 incremental build 디스크 기준 [디스크 하한 보정](decision/20260910T171052+0900-decision-incremental-build-disk-floor.md)에 따라 test Contextra의 pinned Base/cache 재사용 incremental build는 시작 가용 공간을 **15GiB 이상**으로 변경한다. build 중15GiB 미만 중단은 유지한다. 이후 작업에도 적용하며 다른 profile/서버의 공용 정책으로 확장하지 않는다. 과거25GiB Gate 실패 기록은 당시 사실로 보존한다. 다음 build 직전 actual 공간·Docker 저장 위치·작업 충돌을 재확인한다. 이번 build/Runtime 실행0. ## 최소 관측 구현·배포 보류 [시작 관측 검증](validation/20260910T170501+0900-validation-start-observation.md)에 bootstrap/SDK 호출 표식, opt-in 단일 stack timer와 외부 생존 helper를 기록했다. 격리27 tests PASS·실제 Python stack timer1회 PASS. 이는 native GIL 원인/Runtime PASS가 아니다. root 가용26543595520bytes로 기존25GiB 하한보다299950080bytes 부족해 build·배포·Start0/1이다. Analytics는 기존 det-window image의 exited/restart0/OOM false를 read-only 확인했다. 삭제/prune0. 사용자 승인: 실제 결과·제어 응답·Stop 정리만 필수 Gate 유지. 진단1회에서 새 근거가 없으면 반복하지 않고 접근 변경을 판단한다. 장시간 무누수·성능·비사용 surface·FP16 재검증은 보류한다. 이후 위 정책 변경으로 시작 하한은15GiB다. 다음은 actual Gate 확인 뒤 source를 고정해 진단 opt-in을 준비하고 회차1회를 실행한다. 공간 정리·하한 완화는 이번에 수행하지 않았다. 기존 API 중단 원인은 여전히 미확정이다. ## 제어 API 중단 표적 진단 [Start/SDK/제어 경계 분석](analysis/20260910T164814+0900-analysis-control-api-stall.md)에서 Manager registry lock과 SDK 실행 thread를 분리해 확인했다. SDK start/stop의 GIL 해제는 공개 wrapper만으로 확정할 수 없다. bootstrap 이후에 생성되는 first-frame watchdog의 감시 공백은 확인했지만, 이를 API TimeoutError의 원인으로 단정하지 않는다. 초기 roles={}는 마지막 성공 관측일 뿐 정지 위치가 아니다. 직전 helper에 독립 liveness/process/thread 관측이 없어 crash/GIL/lock/native 대기를 구별할 근거가 부족하다. 추측 source 수정·격리 재시험·Runtime 조회/실행0. 다음은 호출 전후 최소 표식과 외부 process/stack 관측을 준비한 뒤 별도 승인된 진단 window1회다. 기존 Analytics stopped는 마지막 확인 상태로 유지한다. ## 최신 version2 제한 Runtime 결과 [Det-only window](runs/20260910T163451+0900-run-version2-det-window.md)에서 exact99698a0 source를 `contextra-analytics:det-window-99698a0`로 build했다. image source61개/pin·Native SDK fixture·관련32 tests PASS. version2/batch1과 Infra readiness·초기 stopped 확인 뒤 Start1/Stop1을 사용했다. 초기 starting/roles 빈 상태·collector 관측0 뒤 상태 API TimeoutError, Stop은 RemoteDisconnected로 cleanup 확인 실패했다. 승인대로 Analytics를 중지했고 새 image/env 유지, model/config/overlay 불변이다. 비대상 container ID/restart/OOM/state 불변, version1 rollback0. 이번은 FIRST_FRAME_TIMEOUT 확정 재현이 아니다. 후속 표적 확인은 위 분석에 기록했다. 추가 Runtime 자동 재실행0. ## Production 수명 Gate 재판정 [실제 소유 흐름·공식 계약 대조](analysis/20260910T161157+0900-analysis-production-data-lifetime-gate.md) 결과, 현재 callback 밖 전달값은 Metadata 숫자/tuple과 CPU NumPy 배열이다. Pipeline 종료 뒤 generic deep-copy GPU surface 독립 생존은 현 경로에 비적용이며 전체 Medium 배포 blocker에서 제외한다. 기존 surface FAIL을 PASS로 바꾸지 않는다. Metadata copy와 callback/CPU 저장소/Stop 수명 조건은 유지한다. FIRST_FRAME_TIMEOUT은 별도 미해결이며 다음은 추가 surface 실험이 아닌, 별도 승인된 version2 Det-only 실제 first-frame/collector/cleanup 검증이다. 이번 source·Runtime 변경/조회0. ## 실제 mux 복사 Gate 결과 [실제 mux 합성 검증](validation/20260910T160019+0900-validation-real-mux-buffer-copy.md)에서 표식 없음/있음 각 Frame1의 deep-copy 반환·원본 해제·복사본 Frame/완료 JSON 읽기는 PASS했다. 원본 Pipeline 해제 뒤 복사본 surface 크기 검사가 두 조건 모두 실패해, copied surface 픽셀 읽기/최종 release 검증은 미완료다. Native JSON이 원인이라는 근거는 없으며 일반 buffer copy의 NVMM 독립 소유 가정은 아직 미확정이다. 추가 GPU 실험·배포0. task 자원 회수 확인, 운영 Analytics 상태는 재조회하지 않았다. 이후 위 production 수명 분석에서 현 경로의 surface 독립 보관 요구가 없음을 확인해 Gate 범위를 교정했다. 실험 실패와 최종 release 미검증은 그대로 보존하며 FIRST_FRAME_TIMEOUT 원인으로 확대하지 않는다. Metadata publisher/Facade 독립 source PASS와 version2 우선 원칙은 유지한다. ## 독립 Metadata·Facade 구현 결과 [source·격리 검증과 AI 읽기 계약](validation/20260910T153921+0900-validation-metadata-publisher-facade.md)에 snapshot·nullable time·표시 command, 독립 latest-per-camera publisher, bounded 제어 worker와 Facade 부분/all-skip·제한 응답을 기록했다. 전체 unit162와 후속 HTTP26/Host13 PASS, 실제 Redis/Native callback 연결은 WAIT다. production Camera router mount0, 운영 Runtime 변경0. Queue/TTL/종료와 XREAD 의미는 해당 evidence가 소유한다. Web 소비/화면 작업은 AI 완료 조건이 아니다. 실제 AI Frame 발급/연결·Redis transport 준비는 아직 남았다. ## 9월 Metadata 우선 현재 계약 [AI 책임·최소 구현 범위](decision/20260910T152041+0900-decision-ai-metadata-minimum-scope.md)가 최신 보정이며 [side 승인 통합](decision/20260910T145810+0900-decision-september-metadata-web-integration.md)의 나머지 계약은 유지한다. 고객 요구 변경으로 9월부터 AI 소유 Metadata Redis→Web Backend→Browser 원본 영상 합성을 우선하고 WebRTC/AI Media Gateway는 보류한다. 아래 과거 단계의 재개 문구는 당시 이력이며 현재 순서는 이 절과 마지막 재개점이 소유한다. - Camera별 짧은 Redis Stream·채널 상태, XREAD와 bounded/fair 송신이 승인 방향이다. 기존 Redis 재사용은 표적 확인 후 선택할 기본 후보이며 설정/외부 공개/실제 읽기 검증은 미실행이다. - 미정 시간/score는 null로 진행한다. 실제 Frame identity·출처를 제공하되 RTP/Anchor sample 없는 source 절대시각·정확한 합성 PASS를 주장하지 않는다. - Start는 Web의 3초 timeout 전에 성공/실패/진행 중을 구분하는 방향이다. 미지원 Scenario는 사유와 함께 부분 skip한다. 전부 skip이면 Detection-only를 허용하고 effectiveScenarios=[]와 제외 사유를 제공한다. - Event clip/thumbnail/URI도 9월 필수다. 실시간 표시와 같은 eventId를 사용하고 독립 작업이 빠르면 Metadata와 병행한다. 출력별 지연·오류 상태는 분리하며 전체 무영향을 보장하지 않는다. - 독립 source에서 전체 Scenario 거부를 partial/all-skip으로 보정하고 worker와 HTTP 대기를 분리했다. 실제 연결·배포는 WAIT다. 영상 CLI 마감과 version2 우선 원칙 유지. - 직전 복사 Gate와 종료 구현 evidence를 보존했다. Analytics stopped는 마지막 확인값이며 이번 Runtime 조회0이다. Metadata 우선 결정으로 Medium 복사 위험이 해소된 것은 아니다. - AI 완료 조건은 데이터/읽기 계약·API·상태·Artifact 제공과 AI 자체 검증이다. Web의 소비·Backend· Browser 표시·원본 합성은 Web Owner이며 AI 구현 목록/완료 조건에 넣지 않는다. 공동 연동에서 확인된 AI 문제만 보정하고 Web 진행 대기를 AI 미완료로 표현하지 않는다. - 표적 source 확인: 기존 publisher는 저장 결합·전역 Stream·동기 I/O여서 새 실시간 경계로 재사용하지 않는다. Redis instance 재사용은 기본 후보이나 tracked 무인증 설정을 그대로 공개하지 않는다. 실제 Redis 설정은 미조회다. Envelope 계약은 재사용하고 실제 ingress/Native 연결은 별도 WAIT다. ## GstBuffer 복사 Gate 재개점 [표적 복사 대조](validation/20260910T144034+0900-validation-gstbuffer-copy-gate-blocked.md)에서 현재 SDK의 빈 batch copy/release는 PASS, Frame1은 Native 완료 JSON 유무와 무관하게 signal11을 재현했다. Python wrapper 없이 C++에서 재현했다. 인공 Frame/SDK 문맥 관련 후보이며 fixture-only 또는 실제 Pipeline 결함 확정은 아니다. 실제 mux Frame 안전성 근거가 부족해 사용자 Gate에 따라 배포를 보류했다. build/env/config/Analytics/Stream mutation0, Runtime0/2. actual Analytics exited/restart0/OOM false 유지. 당시 제안한 GPU 합성 mux 대조는 위 최신 validation에서 실행했다. 이전 인공 Frame 실험은 반복하지 않았으며 표식 Metadata 성공과 별도 surface 수명 실패를 구분한다. 기존 모델·image 보존 유지. ## Medium 완료·종료 구현 재개점 [완료 표식·종료 결과 검증](validation/20260910T142450+0900-validation-medium-completion-cleanup.md)이 최신 구현 결과다. teardown 단일 owner, Stop 실패 보존, join 생존 확인, 미종료 참조 보존/재Start 차단과 cleanup 상태를 추가했다. Native JSON UserMeta로 성공0/component/frame/PTS/count/bbox 기준 크기를 전달한다. 설치 SDK FrameMeta 복사에서 pipeline 크기 유실을 재현해, 실제 C++ bbox 기준 크기를 JSON으로 보존했다. 144 unit PASS, Native compile/link·SDK FrameMeta copy/release/독립 복사 PASS. 전체 GstBuffer copy_deep fixture 실패는 해결 완료로 기록하지 않으며 실제 Pipeline은 WAIT다. stage 최초 도달/count와 EOS/상태 message를 추가했다. 일반 Gst ERROR domain/code는 설치 SDK 공개 accessor 부재로 상세 매핑 WAIT이며 private pointer 접근을 도입하지 않았다. 이번 배포/Analytics/Stream 실행0. Analytics 중지는 직전 확인 상태이며 기동하지 않았다. 새 image/version2 Runtime은 최신 production 수명 Gate 범위와 별도 배포 승인을 따른다. version1 자동 rollback0. 재개: `Medium 완료·종료 source/격리 검증 완료 · 새 image와 version2 제한 Runtime 승인 준비`. ## Medium 표적 Audit 재개점 [실행 경로·종료 계약 Audit](analysis/20260910T135741+0900-analysis-medium-execution-teardown-audit.md)을 설치 DeepStream9.1 source·PyServiceMaker·공식 문서와 대조했다. 이번 Runtime 실행0. join timeout 뒤 생존 미확인/참조 해제, stop 실패 결과 유실·teardown 경합 경로, 성공 검출0과 추론 미실행을 구분하지 못하는 완료 신호를 확인했다. FIRST_FRAME_TIMEOUT의 단일 원인은 여전히 미확정이다. GIL·pool·FP16을 원인으로 단정하지 않는다. 해당 source 교정과 지원되는 SDK 관측은 위 최신 validation에서 구현했다. 일반 bus 상세 오류는 WAIT다. 전체 MODARCH 감사·모델 재변환·precision 탐색은 반복하지 않는다. version2 우선·기존 산출물 보존 유지. actual Analytics exited/restart0/OOM false를 read-only 확인했으며 기동/설정 변경0. 재개: `Medium 실행·종료 계약 Audit 완료 · teardown 결과 보존·Native 완료 확인·단계 관측 최소 구현 시작`. ## Version2 우선 재개점 [Surface 크기 전달·SDK ID 교정](runs/20260910T133646+0900-run-surface-dimensions-component-boundary.md)이 최신 Runtime 결과다. C++가 bbox 계산에 쓴 크기를 공개 pipeline_width/height로 게시하고 기존 값 충돌을 차단했다. 또한 SDK Flow.preprocess의 기본 target-unique-ids=1이 동적 infer ID를 덮어쓰는 것을 확인해 명시 component ID 전달로 교정했다. decoder/전처리 수식·Artifact source pin은 변경하지 않았다. 최종 image-owned132 unit과 C++/실제 SDK fixture PASS. Runtime2회 사용 후 추가 실행0. 회차1은 DIMENSIONS_UNAVAILABLE, 회차2는 collector0·FIRST_FRAME_TIMEOUT이며 decoded stage도 미관측이다. 크기0 오류가 재관측되지 않은 것만으로 실제 bridge/좌표 정합 PASS를 선언하지 않는다. Stop 응답은 두 회차 모두 PASS였으나 media thread 정리를 확인하지 못해 Analytics를 안전 중지했다. 현재 version2/batch1과 최종 surface image를 보존한 exited 상태이며 API는 사용할 수 없다. 다음은 입력→preprocess→infer의 첫 Frame 대기 지점과 종료 정리를 표적 확인하는 것이다. SURFACEDIM-01=A, BRIDGEITER-01=A(최대2회), BRIDGEDONE-01=A를 적용했으며 마지막 기준은 아직 미완료다. [Medium 배포·rollback 실패](runs/20260910T123016+0900-run-medium-pipeline-rollback-failed.md): `b272597` image build·image-owned 128 unit PASS, version2/batch1 모델·Infra READY까지 성공했다. 테스트 Start1/Stop1, 약6.8초에서 native_metadata 오류·collector0으로 종료했고 Stream Stop은 PASS했다. 이전 image/env/config로 rollback했으나 기존 config의 default latest가 보존된 version2를 선택하여 max-batch8/engine batch1 충돌이 났다. 이는 rollback 선택자 누락이며 FP16 정확도 문제로 해석하지 않는다. 당시 자동 restart1 관측 후 Analytics를 명시 Stop했다. 해당 snapshot은 보존한다. 기존 image/env/config bytes·version1과 새 image/version2는 보존됐고 다른 container15개는 불변이다. 최신 사용자 승인으로 초기 개발 단계에서는 version1 복구 기동을 보류하고 version2 해결을 우선한다. version1과 기존 image/config는 보존하되 자동 rollback하지 않는다. 실패 시 Stream Stop, 기동/정리 실패·자동 restart 때 Analytics Stop으로 종료한다. 이 원칙은 위 복구 우선 제안을 대체한다. [Version2 진단 1회](runs/20260910T125201+0900-run-medium-native-dimensions-diagnostic.md)에서 직접 실패 조건을 확인했다: source1920x1080, pipeline0x0 → DIMENSIONS_UNAVAILABLE. source/mux 크기를 임의 fallback하지 않고 검증을 유지했다. 격리 fixture에는 pipeline 크기를 직접 설정했으므로 실제 Runtime의 0 필드 상황이 이전 정상 fixture에 포함되지 않았음을 구분한다. 진단 source는 기준5730618+build-input snapshot f4894f1e의 고유 image이며 임의 commit0. image-owned 131 unit PASS, model version2/batch1·Infra READY, Start1/Stop1·약16.53초 진단 완료. 당시 Analytics running/healthy/restart0, Stream stopped였다. 현재 상태는 위 최신 run이 소유한다. 그 뒤 승인된 크기 전달 교정은 위 최신 run에 반영됐다. source 크기를 근거 없이 mux 크기로 대체하지 않는다. 모델 재변환·precision/threshold 변경0. 재개: `Version2 크기·component 교정 반영 완료 · 첫 Frame 대기 지점과 종료 정리 표적 확인`. 사용자가 Swagger /ready와 Stream 목록 응답이 예상과 일치한다고 확인했다. 재조회 없이 `USER SWAGGER READ-ONLY PASS`로 수용하며 실제 추론 semantic PASS로 해석하지 않는다. 사용자는 [동일 영상 FP32·FP16 비교](runs/20260909T194320+0900-run-medium-video-comparison.md)에서 체감 차이가 거의 없다고 확인했고, 9월까지 FP16을 제한적으로 수용했다. 전체 정확도 PASS는 아니며 기존 FP16 raw parity FAIL은 진단 기록으로 유지한다. 수치 FAIL만으로 반복 최적화를 강제하지 않는다. [Medium 영상 CLI 구현·검증](validation/20260910T100219+0900-validation-medium-video-cli.md)에 따라 사용자는 영상·구간·단일/비교 모드를 지정할 수 있다. 명령은 [tooling 사용설명](../../../../../model_tooling/README.md)이 소유한다. [CLI 사용성 개선](validation/20260910T105001+0900-validation-medium-video-ux.md)에서 기존 저장 기준 폴더·실행별 timestamp 하위 폴더·자동 파일명·한 줄 진행률·클래스별 후보 집계를 반영했다. 사용자는 CLI 개선 뒤 실행·저장·진행률·표시까지 PASS로 확인했으며 보조 CLI는 현재 범위에서 마감한다. 종료 실패 반환값·종료 후 readback 보강은 알려진 한계로 보류한다. 모든 강제 종료의 무누수를 보장하지 않는다. Pose/Fire 재사용 모듈과 모델별 별도 계약 경계는 tooling README에 짧게 남겼다. Native bridge·Det parser cutover·exact FP16 제한 수용 source 구현과 격리 검증을 완료했다. [Native bridge/acceptance 검증](validation/20260910T115939+0900-validation-medium-native-bridge-acceptance.md)이 SDK 복사 수명, 128개 unit PASS, 초기 GPU 격리 설정 오류와 최종 장치0 재검증을 소유한다. 해당 다음 배포를 수행한 최신 결과는 위 즉시 복구 재개점이 소유한다. 현재 source 검증 PASS와 운영 Runtime 실패/Analytics stopped를 구분하며 기존 image build와 Start를 중복하지 않는다. CLI의 COMPLETED는 영상 생성 완료일 뿐 deployment Gate 해제나 운영 자동 적용이 아니다. 이전 [FP32·TF32-off 대조 결과](runs/20260909T180019+0900-run-medium-fp32-control.md)는 그대로 보존한다. 같은 ONNX/fixture/C++ 경로의 대조 실험 1회가 PASS했다. 기존 FP16-enabled build의 정밀도/최적화 경로로 후보를 좁혔지만 FP16과 TF32를 함께 바꿨으므로 단일 연산·정확한 원인은 미확정이다. 고정 exporter 환경·공식 weight load·ONNX·engine build는 완료했으므로 재설치/재export를 반복하지 않는다. v4 FP16은 명시 policy에서만 제한 수용 source Gate를 통과하며 numerical FAIL·target 배포 차단은 유지한다. 새 FP32 후보의 deploy dry-run/Runtime 적용은 미실행이며 offline PASS를 배포 승인이나 실제 영상 정확도·10 FPS 달성으로 해석하지 않는다. 기존 출처 불명 Artifact는 복구용으로만 보존한다. CPU parser/ONNX 실행 환경과 SDK 검증 image는 준비됐으므로 부재 조사·재설치를 반복하지 않는다. GPU 전처리 source는 현재 진단 image에 반영됐지만 전체 Pipeline PASS는 아니다. 기존 image `smoke-b3868cf`로 자동 복구하지 않는다. Web wire와 Facade 활성화는 계속 별도 확인 대상이다. 13개 사용자 방향은 승인됐지만 전체 구현·검증 완료를 의미하지 않는다. ## 목적 SSIMS에서 관찰된 runtime lifecycle 문제를 Contextra의 리팩토링 요구와 acceptance 기준으로 연결한다. 이 문서는 현재 핵심 요약과 상세 evidence의 읽기 순서를 소유하며 canonical public architecture 계약을 만들지 않는다. ## Medium 연결 최소 재개 범위 `2026-09-10 11:59:39 KST`, test/ltb1021, 구현 기준 `c8b46185512ac2bcc44736c25223b481ce27cc50`. branch/local upstream 일치·clean에서 시작했다. 아래 source/격리 검증만 완료했고 운영 배포0. | Block | 완료된 근거 | 미연결·후속 | | --- | --- | --- | | 새 공식 Medium FP16 Artifact | weight→ONNX reference PASS, plan build/실제 영상·사용자 제한적 수용 | exact target 적용·서비스 Runtime WAIT | | GPU 전처리 | medium_preprocess.cu/.py, render_cfg sidecar, Flow.preprocess, Docker packaging source; standalone GPU normalization PASS | 새 image와 NV12/RGB resize→tensor-meta 실제 Pipeline WAIT | | C++ Adapter | processor.cpp→decodeDetections→NvDsObjectMeta attach, 공식 후보 선택/mapping·offline PASS | 새 image에서 실제 metadata attach 확인 WAIT | | Python 소비부 | native_metadata가 SDK iterator 안에서 숫자를 복사; Det tensor 의존/Det raw parser 호출 제거, Pose/Seg 공통 함수 보존 | 실제 SDK→Pipeline callback Runtime WAIT | | 좌표/후처리 | Native surface pixel LTWH→normalized XYXY→기존 tracker/storage CXCYWH, source/mux 크기 차이·frame0·검출0·component·세대 fencing test PASS | 실제 mux 크기/resize 연결 확인 WAIT; 크기 미관측은 오류로 처리 | | Frame/one-decode | FrameEnvelope/Observation type은 구현됨 | role별 Source·Decode와 frame_number 기반 collector가 남아 있음. canonical ingress identity·fan-out/join 미완료 | | Deploy Gate | deploy.py에 exact Medium policy·파일/보고서/source hash·shape/finite/C++ 검증 추가. numerical FAIL 보존 | ready=false, target 환경/명시 배포 승인 WAIT | Native Detection Metadata bridge와 해당 Det 소비부 cutover, 전처리 설정/packaging 정합 및 제한적 Artifact acceptance plan의 source·격리 검증을 완료했다. image/model 배치와 RTSP smoke는 다음 명시 승인으로 분리한다. Det template는 output tensor meta를 끄고 동일 component ID로 preprocess/Native/bridge를 연결한다. 기존 static CLI fallback cfg는 배포 경로로 사용하지 않는다. 이는 MODARCH 순서4의 일부 진행이며 PIPECORE-01 전체 완료가 아니다. Det 단독 연결 확인 뒤 one-decode ingress·Det/Pose fan-out·동일 Frame identity join을 이어가며 Pose9월 목표와 순서는 유지한다. role별 frame_number를 cross-role identity로 새로 정당화하거나 임시 fan-out을 추가하지 않는다. 필수 검증: actual SDK public Object Metadata accessor 확인, tensor meta 없는 Det/검출0 frame, class/score/box·source dimensions·component 구분·NaN·stale generation·frame0 보존, tracker/storage 호환 좌표, raw Det parser 경로 제거와 회귀. Metadata 참조는 callback 밖에 보관하지 않는다. 공식 C++ semantic/bridge 대체 검증 조건을 만족한 같은 Batch에서 RTSP Det parser 호출을 제거한다. Pose/Seg/진단 caller가 쓰는 공통 함수는 caller 대조 없이 삭제하지 않고 oracle/fallback으로 사용하지 않는다. Native 임의 floor0.5를 복원하지 않는다. 기존 Python profile score는 소비자 필터로 소유를 명시하며 CLI 표시 threshold를 Runtime 기본값으로 승격하지 않는다. ByteTrack/Scenario/Outbox/Media는 끌어오지 않는다. 제한적 수용 구현은 `LIMITED_USER_VISUAL_ACCEPTANCE` 같은 별도 상태로 exact plan SHA `5fdf1e9c55ab947a3b7d5f7f6bdceaf1e36a9e52efdf86f5a15d3b99b8631d1e`와 ONNX SHA `6ab93d8f1c64c369b2273b91738d554ce76466fb31f41f5fabb1f61d24a91999`, 기존 numerical FAIL evidence 및 사용자 시각 확인을 연결하는 범위다. 범용 skip/force-pass0. export/build/reference·hash·dtype/shape/finite·C++ 계약 오류는 면제하지 않는다. 이번 exact test 환경/9월 Det 제한 검증 외 artifact·GPU·서버로 승인을 자동 확장하지 않는다. source policy 자체는 실제 적용 승인이 아니다. 이후 사용자가 승인한 version2 진단 적용과 deploy.py의 ready=false/source acceptance/target readiness를 구분한다. 실제 배포 요청에는 그 시점의 clean source commit·새 image tag, target model version/config hash CAS, 현재 운영 image ID/config/model version 보존, Analytics/Triton의 명시 반영 방법과 대상 Stream/window, readiness·bounded 첫 frame 검증·실패 복구를 고정해야 한다. PostgreSQL/Redis/다른 서비스 변경0. 이 값은 이번에 Runtime 조회하지 않았으므로 과거 snapshot을 actual rollback으로 기록하지 않았다. FP32는 진단·대안 모델 후보이지 현재 운영 Runtime rollback image/model과 동일하지 않다. 추가 사용자 설계 선택은 현재 발견되지 않았다. SDK bridge 지원 한계·새 품질/출력 손실 정책· 외부 호환 변경이 발견될 때만 해당 범위를 재판단한다. 재개 문구: `Medium Native bridge·제한적 Artifact acceptance source/격리 검증 완료 · exact image/model 배포 CAS·rollback 승인 준비`. ## 범위 - desired state와 observed state의 구분 - stream start, stop과 restart lifecycle - worker와 pipeline liveness - frame heartbeat와 stale 상태 - 장애 복구와 중복 실행 방지 ## 개발 우선순위 원칙 - 최신 사용자 승인: 9월 Det는 RFDETRMedium만 사용하고 Large는 9월 이후로 보류한다. Det 검증 선행은 검증된 범위에서 마감했고 Pose·Fire는 최신 일정의 이번 주 준비 목표다. 공식 pretrained 변환이라는 구두 근거와 실제 weight/version 및 ONNX-plan 연결 검증은 구분한다. - 사용자가 9월 목표 달성을 명시하기 전까지 최소 연동·시연·설치 테스트 달성을 확장용 선행 설계보다 우선한다. 의미가 잠긴 기존 경계는 유지하되 무관한 전체 감사·빈 확장 구조를 만들지 않는다. - Scenario 우선순위는 INTRUSION → LOITERING → FALL → FIRE이며 다음 주 종료까지 네 종류가 목표다. 이번 주 최소1개, Tracking 선행과 Pose 목표를 유지한다. 전체 화면 분석을 기본으로 하고 입력 crop ROI는 보류한다. ROI/Snapshot과 Artifact 실패 Event 전달은 최신 최소 구현 결정이 소유한다. - [September-first, December-compatible 결정](decision/20260902T101155+0900-decision-september-first-december-compatible.md)에 따라 9월 Runtime PASS를 우선하되, 12월에 변경 비용이 커질 이름·경로·Owner·Metadata·API·상태 계약은 지금 잠근다. - 향후 판단은 `SEPTEMBER_IMPLEMENT`, `DECEMBER_LOCK_NOW`, `RUNTIME_DECIDE`, `OUT_OF_SCOPE`로 분류한다. Runtime 수치 미확정을 이유로 9월 필수 구현을 중단하지 않는다. - 임시 구조에는 적용 범위·검증 기준·종료 조건과 후속 전환점을 둔다. RF-DETR C++·Python 중복 후처리는 첫 Frame baseline 후보이며 영구 Metadata Architecture로 자동 승격하지 않는다. - [최신 Metadata 우선 결정](decision/20260910T145810+0900-decision-september-metadata-web-integration.md)이 기존 임시 WebRTC 선행 일정을 대체한다. 9월 실시간 Metadata와 Event/Artifact가 필수이며 `media-output`은 보류한다. 정확한 원본 Frame 동기화는 sample/연동 evidence로 별도 검증한다. - [MODARCH 전 선행 Architecture 최종 잠금](decision/20260904T171113+0900-decision-pre-modarch-architecture-final-lock.md)은 승인된 Module·Process·Service·Data Path·API·Config·Model·Artifact 경계를 통합한 다음 Audit의 recovery anchor다. 실제 Module 배치와 구현 완료를 의미하지 않는다. - [MODARCH Target Architecture 최종 잠금](decision/20260905T180241+0900-decision-modarch-target-architecture-lock.md)은 actual source Audit 결과에 따라 Runtime Shell 유지·Core 단계적 교체, one-decode, Scenario 선택 재작성과 scoped persistence를 잠근 current Architecture Owner다. - [Web-AI PoC·FPS·Frame 시간·Artifact 최종 잠금](decision/20260908T210436+0900-decision-web-ai-poc-fps-frame-time-artifact-lock.md)은 Web 외부 DTO와 AI canonical Runtime Contract를 분리하고 9월 Integration Facade·10 FPS·Event/Artifact 전달, 장기 Frame identity·시간 경계와 Sample/Runtime 대기를 잠근 current Web Integration Owner다. - 이 원칙은 우선순위 Owner이며 기존 `CTXRF`, `CTXREUSE`, `CTXINTAKE`, DSARCH와 `APICONTRACT-WAIT`의 기술 계약을 대체하지 않는다. ## 설명·변경 이유 기록 경계 - CV·Video AI의 중요한 판단 리스트는 profile Engineering Explanation Owner의 `CVGUIDE-01~03`에 따라 현재 방식, 문제, 추천 동작, 9월·12월 영향, 검증과 동료 설명 문장을 필요한 범위에서 제공한다. - Contextra 변경 이유는 profile `AGENTS.md`의 `CTXWHY-01~06`을 따른다. Architecture 판단 이유는 timestamp decision, 현재 route는 이 README, 구현은 commit, 실제 결과는 validation/run evidence가 각각 소유한다. - A등급의 중요한 source Owner·Invariant는 decision ID가 포함된 짧은 한국어 Anchor Comment로 연결한다. 현재 Native Adapter에는 `CTXRF-01`·`RFBUILD-07`, lifecycle에는 `STREAMERR-01` Anchor가 반영됐다. - 기존 historical decision은 보존하며 새 계약은 `extends` 또는 `supersedes` 관계로 연결한다. ## 현재 핵심 Capsule - Test worktree는 `/workspace/contextra-analytics-runtime-lifecycle-refactor`, branch/upstream은 `task/runtime-lifecycle-refactor`다. 현재 image는 위 surface 교정 snapshot이며 Analytics stopped다. COMPOSITION-01 구현 commit은 `be367b7a7285bce5dbfaaec87a67c110a84509bd`이며 새 image와 Analytics 반영까지 완료했다. - Service `main`은 service 서버가 배포·최종 Runtime acceptance를 소유하고, 현재 test task branch는 work-session이 분석·설계·구현·자동 검증을 소유한다. - SSIMS는 MySQL 설정, Redis `tasklist` ownership과 Celery worker의 실제 실행 상태가 분리돼 있다. - 사용자 운영 경험상 `ai-worker` container restart 뒤 DB와 Redis는 ON처럼 보이지만 실제 worker가 중단되고 브라우저에 stale frame이 남는 문제가 있었다. - Contextra는 FastAPI, Triton과 `StreamManager`가 같은 analytics container에서 동작한다. - Application startup은 `streams.yaml`과 writable runtime overlay를 결합하되 process restart에서 `autostart`를 적용하지 않으며 명시적인 Start만 허용한다. - 별도 worker container와 Redis ownership 불일치는 줄지만, 개별 role thread와 frame 처리 중단을 지속적으로 조정하는 기능은 부족하다. - 현재 stream별 `det/pose/seg`는 source를 독립 capture·decode하고 `frame_number` 동일성을 가정해 Python에서 병합한다. 실제 tracker는 `IoUTracker`이며 ByteTrack·BoT-SORT 문서와 불일치한다. - 기존 baseline은 Snapshot과 기본 활성 Active Learning 때문에 det callback에서 매 Frame GPU→CPU copy가 발생하고 Scenario·PostgreSQL·Redis는 5초 persistence loop에 결합돼 있었다. Canonical 기본값은 Active Learning Off로 보정했으며 실제 GPU path는 새 image Runtime에서 확인한다. - Canonical Compose는 project `contextra`, stable service 이름과 project-scoped resource를 사용하며 `container_name`, source hot-mount, Host PostgreSQL·Redis·Triton port와 implicit build를 제거했다. - 실제 Runtime env/config는 `/workspace/contextra-runtime-config`, API 생성 Stream projection은 `/data/contextra/runtime-state`가 소유한다. 실제 파일은 mode `600`, directory는 `700`이며 Git에 포함하지 않는다. - Test canonical Compose의 `postgresql`, `redis`, `analytics`는 모두 running·healthy다. Analytics는 `contextra-analytics:smoke-b3868cf`을 사용하며 canonical `app.*` import, `create_app()`, SourceAdapter, Native Adapter, `RFDETRMedium`, PostgreSQL과 Redis readiness가 PASS다. 이번 recreate 뒤 Stream은 `stopped/stopped`, process-local `run_generation=0`, `run_id=null`이고 자동 Start·RTSP 실행은 0이다. ## COMPOSITION-01 image·Runtime 검증 - commit `be367b7`의 image-owned package root와 canonical import, 독립 `create_app()` instance, Singleton owner와 OpenAPI 26개 operation fingerprint가 source 정적 기준과 일치한다. - 전체 Unit Test `47 PASS`, Composition Architecture Test `9 PASS` 뒤 Analytics만 새 image로 recreate했다. `/live`, `/ready`, `/health`는 모두 HTTP `200`이고 FastAPI process·startup은 각각 1회다. - PostgreSQL·Redis와 SSIMS container의 ID·restart·OOM은 불변이며 rollback은 필요하지 않았다. 상세 결과는 [COMPOSITION-01 image·Runtime run](runs/20260907T113617+0900-run-composition-image-runtime-ready.md)이 소유한다. ## 확인된 현재 Gap - 최신 [Det Gate](analysis/20260909T135231+0900-analysis-det-artifact-semantic-gate.md)에서 plan·ONNX·config hash를 확보했다. Engine 내부 schema와 exact weight/exporter provenance는 아직 미확인이다. - 고정 공식 reference와 비교한 sparse COCO mapping의 반례를 production C++ header로 확인했다. 80개 category slot 중 mismatch 69·제외 9이며 실제 영상 정확도 수치는 아니다. Query별 argmax와 reference의 global selection도 source상 다르다. 현재 artifact에 대한 semantic PASS는 선언하지 않는다. - preprocessing은 reference의 mean/std와 config가 다르지만 graph 내 변환 포함 여부가 미확인이므로 오류를 확정하거나 중복 normalize를 추가하지 않는다. Builder 자동 구현·재변환은 보류한다. - role별 init·Frame·오류를 수집하는 `RoleRunHandle`과 Stream supervisor는 source·image에 반영됐고 실제 RTSP 첫 Frame과 `starting -> running` 전이는 PASS했다. 실제 실패 경로의 `starting -> error`와 장기 heartbeat는 별도 Runtime 검증이 남아 있다. - Native와 Python det count는 `440 Frame / 236 detections`로 일치했지만 class·score·bbox와 공식 RF-DETR PostProcess 의미 정합은 검증하지 않았다. Python 결과를 correctness oracle로 사용하지 않는다. - Stream·Scenario acceptance, 지속 heartbeat와 완전 reconciliation은 `/live`·`/ready`와 별도다. - annotated inference 결과를 연속 영상으로 제공하는 streaming 기능은 구현되지 않았다. - `persisted` identity set lifecycle, 지속 heartbeat와 Stop 뒤 stale cache 정리의 실제 Runtime 검증이 부족하다. - Pipeline thread가 초기화 중 실패해도 Stream API가 `running`을 반환하고 이후 상태를 `error`로 승격하지 않던 Gap은 source·unit test와 새 image 반영까지 보정했다. 실제 RTSP에서 failure propagation을 검증해야 한다. ## RF-DETR Native Build·Stream Lifecycle 구현 - [RFBUILD·STREAMERR 결정](decision/20260902T163049+0900-decision-rfbuild-streamerr-contract.md)에 따라 Native source는 `native/nvinferserver_rfdetr/`, artifact는 `/opt/contextra/lib/libcontextra_nvinferserver_rfdetr.so`, factory는 `CreateContextraRfDetrProcessor`가 canonical이다. - Docker build stage는 pinned DeepStream image에서 Makefile로 C++14 artifact를 만들고 final image에는 `.so`만 복사한다. 과거 `gst-nvinfer` parser build와 active source는 제거했다. - Adapter는 `dets/labels` FP32 full-dims를 indexing 전에 검증하고 bbox·score·zero-based `class_id`만 `NvDsObjectMeta`에 붙인다. Tracking·Scenario·Event·OSD 표현은 Python이 계속 소유한다. - Stream은 `desired_state`와 `observed_state`를 분리하며 Start는 HTTP `202`와 `starting`을 반환한다. required role 전체의 첫 Frame 뒤에만 `running`이고 worker 실패·timeout은 structured error가 된다. - Source·unit 검증 28개와 isolated Native compile, ELF·symbol·`ldd`·`dlopen/dlsym`은 PASS다. 상세 결과는 [정적 validation](validation/20260902T163049+0900-validation-rfbuild-streamerr-static-ready.md)이 소유한다. - 새 image build와 Native static/load 검증, Analytics 단독 recreate와 Infra readiness는 PASS다. 실제 RTSP first Frame도 PASS했으며, semantic contract와 Python det cutover는 최신 decision이 소유한다. ## 첫 RTSP Smoke와 RF-DETR Adapter 경계 - Infra readiness, Swagger·GET, `start=false` 등록과 private runtime overlay 반영은 PASS다. 실제 Start 뒤 source TCP 연결과 Triton `RFDETRMedium` READY도 확인됐다. - det Pipeline은 template이 요구하는 `/opt/contextra/app/lib/libcontextracustom.so`가 image에 없어 `nvinferserver` Custom Processor 초기화에서 중단됐다. Frame은 0이고 watchdog가 no-frame을 감지했다. - 현재 Dockerfile의 parser stage는 다른 API용 `libdeepstream-rfdetr.so`를 빌드할 뿐, required `libcontextracustom.so`를 final image에 포함하지 않는다. 이는 Tracker·NumPy dependency와 별개다. - RF-DETR raw tensor 해석은 model-specific C++ Adapter가 맡아 `NvDsObjectMeta`를 생성한다. Tracking, Scenario, Event와 Visualization 정책은 Python CPU plane의 typed contract로 유지한다. - `.so` 자체는 Git에 넣지 않는다. C++ source·Docker build rule·검증을 Git이 소유하고 image build가 compile·COPY해 서버별 수동 compile과 source bind hidden dependency를 제거한다. - 상세 실행 결과는 [첫 RTSP Smoke 실패 run](runs/20260901T161936+0900-run-first-rtsp-custom-processor-failure.md), canonical 계약은 [RF-DETR Adapter·SSIMS 재사용 decision](decision/20260901T161936+0900-decision-rfdetr-adapter-ssims-reuse-boundary.md)이 소유한다. ## RTSP SourceAdapter 구현 - [RTSP SourceAdapter 결정](decision/20260903T123249+0900-decision-rtsp-source-adapter.md)에 따라 외부 `uri`는 완성된 값으로 유지하고 `RtspSourceOptions`가 transport·latency·audio·reconnect·first Frame timeout을 vendor-neutral 계약으로 소유한다. - `app/source_adapters/rtsp.py`의 `RtspSourceAdapter`는 역할·실행 세대마다 공식 ServiceMaker `source-list + source-config` YAML을 mode `600`으로 생성한다. `nvurisrcbin`, RTSP TCP, latency, audio Off, GPU와 retry Off를 명시 적용하고 Stop/error/finally에서 파일을 idempotent 삭제한다. - PyServiceMaker 9.1의 static SourceConfig 경로가 일부 `source-config.properties`를 source node에 전달하지 않는 동작은 Adapter가 Pipeline 시작 전에 보정하며 `StreamManager`는 NVIDIA property를 모른다. - 공개 Flow API에서 실제 Probe로 확인 가능한 source 단계는 `decoded_frame_received`와 `inference_frame_completed`다. `rtsp_session_ready`와 `rtp_packet_received` 직접 hook은 제공되지 않아 성공으로 추정하지 않으며 explicit Pipeline 전환 여부는 별도 판단한다. - 전체 unit test `38 PASS`, compileall, Compose render와 pinned image의 actual SourceConfig parser는 PASS다. 상세 결과는 [정적 validation](validation/20260903T123249+0900-validation-rtsp-source-adapter-static.md)이 소유한다. - commit `7c64098` 기반 image build, SourceAdapter hash·SourceConfig·Native library 정적 검증과 Analytics 단독 recreate까지 PASS했다. 이어진 수동 Smoke에서 first Frame과 Stop cleanup도 PASS했다. 상세 결과는 [SourceAdapter image/Infra 준비 run](runs/20260903T130633+0900-run-rtsp-source-adapter-image-runtime-ready.md)이 선행 image 상태를, [첫 Frame run](runs/20260903T174842+0900-run-first-frame-native-python-count-parity.md)이 actual Runtime 결과를 소유한다. ## First Frame 이후 Adapter·Model·Module Audit 방향 - [최신 decision](decision/20260903T174842+0900-decision-first-frame-adapter-model-modarch.md)에 따라 RTSP det raw tensor 해석 Owner는 C++ Native Adapter로 단일화한다. Python det 결과는 정답 기준·fallback으로 사용하지 않으며 독립 Golden Tensor 검증과 같은 구현 Batch에서 RTSP det Python parsing을 제거한다. - `RFDETRMedium`부터 actual artifact hash·`config.pbtxt`·고정 RF-DETR reference·Golden Tensor에 근거한 `model_contract.yaml` Bootstrap Contract를 둔다. 기존 변환 Artifact는 `MODELARTIFACT-GATE-01`을 먼저 통과해야 하며, 실패할 때만 RFDETRMedium·RFDETRKeypointPreview 대상 9월 최소 Ephemeral Builder를 구현한다. - Det Adapter를 먼저 교정하고 Pose는 별도 후속 Batch, Seg는 9월 구현 보류다. compile-time threshold는 Native·Tracking·Publish·Scenario·Visualization Owner로 분리하고 exact 값은 Runtime 뒤 정한다. - 9월 Model 운영은 `STATIC_PRELOAD_BUNDLE`이다. 필수 Det·Pose Model을 startup READY로 유지하고 Channel별 동적 Load/Unload는 도입하지 않는다. 현재 Test Compose는 `RFDETRMedium` 하나만 노출한다. - `MODARCH-01` read-only Audit은 완료됐다. Role별 Source·Decode 중복, C++ Metadata와 Python raw parser의 이중 경로, Scenario/Storage 결합, process-global DB·Redis와 혼합 import를 핵심 구조 Gap으로 확인했다. 상세 근거는 [Audit analysis](analysis/20260905T180241+0900-analysis-modarch-01-module-responsibility-audit.md)가 소유하며 다음 구현은 `COMPOSITION-01`이다. ## 승인된 Architecture 방향 - 9월은 단일 Stream Runtime Process 안에서 Stream별 Supervisor·Pipeline·Ordered Worker를 두는 A1이다. A3 Worker Shard와 Triton physical split은 Runtime evidence 뒤 결정한다. - Contextra는 Hybrid Modular Monolith이며 NVIDIA 공식 Plugin·Config·Protocol·Public Interface를 우선한다. Orchestrator는 실행 순서·상태 전이만 소유하고 API→Application→Domain 의존 방향을 지킨다. - GPU Media, Real-time Decision, Async Side-effect Path를 분리한다. GStreamer Callback에서 DB·HTTP·파일 I/O를 직접 수행하지 않는다. - `model_key/class_key/object_category/inference_bundle/scenario_key/display_name`과 `server_id/site_id/source_id/stream_id/run_generation/config_version`을 분리한다. - Frame Envelope와 Detection·Pose·Segmentation·Depth Typed Observation을 사용하며 같은 실행 세대·Frame만 bounded join한다. Pixel은 GPU/NVMM에 유지한다. - ByteTrack이 Main Tracker이고 IoUTracker는 Smoke fallback이다. ScenarioEvent, VisualizationCommand와 GPU OSD Drawing Owner를 분리한다. - Audit 전 상세 계약과 보류는 [선행 잠금 decision](decision/20260904T171113+0900-decision-pre-modarch-architecture-final-lock.md)이 historical baseline으로 소유한다. - Audit 뒤에는 검증된 Runtime Shell을 유지하면서 Core를 단계적으로 교체한다. 기존 Contextra Scenario 코드는 correctness oracle로 사용하지 않고 업무 용어·ROI 목적만 참고해 9월 필수 Scenario를 Contract-first 방식으로 선택 재작성한다. 현재 Target과 구현 순서는 [MODARCH Target decision](decision/20260905T180241+0900-decision-modarch-target-architecture-lock.md)이 소유한다. ## Canonical Import·Composition Root 구현 - `COMPOSITION-01`에 따라 application package root와 내부 import를 canonical `app.*`로 통일하고 bare import fallback과 `sys.path` 기반 package 탐색을 제거했다. - `app/main.py`의 `create_app()`은 기존 Route·startup handler가 모두 포함된 독립 FastAPI instance를 반환한다. module-level `app`과 `python -m app.main` compatibility는 유지하며 문자열 ASGI 재import는 제거했다. - 수정 전후 OpenAPI는 `26 operation`과 동일 fingerprint를 유지했고 신규 Architecture Test 9개를 포함한 전체 Unit Test는 `47 PASS`다. 상세 근거는 [Composition 정적 validation](validation/20260905T200621+0900-validation-composition-canonical-import-static.md)이 소유한다. - 새 source의 image build·Analytics Runtime validation도 PASS했다. 상세 Runtime 근거는 [Composition image·Runtime run](runs/20260907T113617+0900-run-composition-image-runtime-ready.md)이 소유하며 다음 단계는 Identity·Frame·Observation additive contract와 Resource Router 구현 판단이다. ## Web-AI PoC·FPS·Frame 시간·Artifact 계약 - Web 담당자 초안은 1차 PoC Wire Contract와 중앙 Web DB 의미 참고자료다. 외부 DTO, AI canonical Runtime Contract와 Storage·Outbound Adapter를 분리하며 중앙 MariaDB가 업무 Config·Event SOT다. - 9월에는 기존 Stream API를 유지하면서 Web Camera Facade를 additive로 연결한다. Start는 Web timeout 3초 전에 여유를 남겨 SUCCESS/RUNNING·FAIL/ERROR·ACCEPTED/STARTING을 구분하는 방향이다. exact HTTP/name은 Facade에서 보정하며 같은 Config 재요청 no-op과 저장 실패 보호는 유지한다. - Web `cameraId`는 AI `source_id`로 mapping하고 AI가 `stream_id`, `run_id`, `run_generation`, `frame_seq`를 생성한다. 외부 이름 변경은 Mapping Adapter에서 흡수한다. - `analysisFpsTarget=10`을 기본으로 단일 Decode 뒤 Det·Pose fan-out 전 PTS 기반 sampling을 수행한다. WebRTC output 의무는 보류한다. Metadata는 실제 처리 Frame을 참조하며 exact Scenario FPS와 Hot apply는 Runtime evidence 뒤 정한다. - 외부 bbox는 Source Frame 기준 normalized XYXY다. 9월 Frame Metadata 전송은 구현 대상이며 RTP/Anchor 미확보 시 관련 값은 null, PTS·수집 시각은 별도다. 정확한 원본 동기화는 sample WAIT다. - 9월 Event는 Artifact READY 뒤 실제 URI와 함께 local Outbox·Bounded Worker로 비동기 전달한다. AI PostgreSQL은 local projection·Outbox·Artifact index이며 중앙 업무 SOT가 아니다. - 최신 세부 계약과 외부 초안 hash는 [Metadata 우선 승인 통합](decision/20260910T145810+0900-decision-september-metadata-web-integration.md)이 소유한다. 이전 Web-AI PoC는 변경되지 않은 계약과 당시 evidence를 계속 소유한다. ## 9월 Metadata·보류 Media 경계 - 물리 배치는 AI 서버의 Contextra Compose, 별도 Web 서버 PC의 Backend·Frontend, Client PC의 Browser로 구분한다. Web Backend·Frontend와 Browser를 AI 서버에서 실행하는 구조가 아니다. - 9월에는 AI 소유 Metadata Redis를 Web이 읽고 Browser가 원본 영상에 합성한다. AI는 VisualizationPolicy/Command로 표시 의미를 결정한다. Frame snapshot은 빈 검출도 빈 배열로 전달하며, Event HTTP/Artifact 경로와 실시간 송신은 분리한다. - `media-output`, GPU OSD 영상 송출과 WebRTC는 보류한다. 기존 영상 CLI를 먼저 검토하되 재사용을 위해 더 큰 보완을 강요하거나 디버깅 편의만으로 Gateway를 선행 구현하지 않는다. - Metadata 의미·nullable 시간·실제 AI identity·eventId 연결과 미확정 wire는 최신 Decision이 소유한다. Frame별 전체 snapshot과 영구 업무 Event의 생성/삭제 의미를 혼동하지 않는다. - Det collector 연결과 종료는 최신 run의 검증 범위에서 마감했다. 정확도/성능 전체 PASS는 아니다. 9월에는 `RFDETRKeypointPreview`의 startup READY, Pose first-result와 Det·Pose Frame join까지 검증하고 Seg는 기존대로 9월 구현에서 제외한다. Exact Plugin graph, Queue·timeout과 장기 Platform config projection은 별도 판단 단계에서 잠근다. ## Canonical Compose·Config Boundary - 기존 `docker-compose.yml` 하나를 canonical Owner로 유지하고 별도 Smoke Compose·장기 Override를 만들지 않는다. 현재 구현 service는 `analytics`, `postgresql`, `redis`, `prometheus`, `grafana`이며 후자의 두 service는 `observability` profile 전까지 기본 기동하지 않는다. `media-output` 추가는 보류하며 Metadata Redis의 기존 재사용/전용 instance 선택은 별도 표적 확인 뒤 기록한다. 이번 Compose 변경0. - 첫 Runtime은 FastAPI만 loopback `35000`에 공개하고 PostgreSQL·Redis·내부 Triton은 Host port가 없다. GPU는 server-local `GPU_DEVICE_ID=0`, Model bind는 `RFDETRMedium` 하나로 제한한다. - Test Analytics restart는 `on-failure:3`, PostgreSQL·Redis는 `unless-stopped`다. Service Analytics의 `unless-stopped` 전환은 service Runtime acceptance 뒤 server-local env가 소유한다. - 기본 Stream, autostart와 Active Learning은 Off다. API 등록은 상태만 기록하고 명시 `/start` 요청 전 추론을 기동하지 않는다. Runtime overlay는 private atomic YAML로 기록하지만 중앙 config SOT가 아니다. - `/live`는 FastAPI process 생존, `/ready`와 `/health`는 `RFDETRMedium` Triton READY, PostgreSQL `SELECT 1`, Redis `PING`을 판정한다. 필수 dependency 실패는 HTTP `503`이며 Compose healthcheck는 `/ready`를 사용한다. Stream·Scenario 실제 처리는 별도 Runtime acceptance다. - `tools/validate_deployment.py`가 실제 env, bind source, YAML, file mode와 Model config를 Docker object 생성 전에 검사한다. Entrypoint도 같은 YAML boundary를 Triton·FastAPI 시작 전에 fail-fast 검증한다. - Tracked Stream·Camera 설정과 과거 backup Compose의 평문 Runtime credential은 current tree에서 제거했다. Git history rewrite와 실제 기존 credential rotation은 service deploy 전 별도 Gate다. - Pure unit test, compileall, Compose render와 missing env/path·invalid YAML negative test는 PASS다. Container·Network·Volume·GPU Runtime mutation은 수행하지 않았다. - Canonical source를 포함한 `contextra-analytics:smoke-790bbfb`의 static/import 검증과 첫 Infra Runtime은 PASS했다. SourceAdapter까지 포함한 `contextra-analytics:smoke-7c64098`이 현재 Analytics를 소유하며 Native Adapter baseline `smoke-b7c12ee`는 rollback으로 보존한다. ## Image Build Security Gate - deny-all allowlist `.dockerignore`로 Dockerfile이 실제 사용하는 약 500KB 입력만 build context에 포함한다. Compose, 실제 Camera·Stream config, env, backup, docs, model weight와 Runtime artifact는 제외한다. - Image 기본 Camera config는 `cameras: {}`인 credential-free example이며 실제 Camera/PTZ config는 Runtime Host bind가 제공한다. - `metadata_storage.py`의 PostgreSQL hardcoded fallback을 제거하고 `DATABASE_URL` 누락 시 명확히 fail-closed하도록 했다. Compose가 제공하는 실제 연결값은 이번 작업에서 변경하지 않았다. - 해당 image build 보안 Gate 당시 `camera_ptz_config.yaml`, `streams.yaml`, `docker-compose.yml`과 compose backup의 pre/post SHA-256은 일치했다. 이후 canonical config migration은 위 절이 소유한다. - 허용 context의 URL userinfo literal, YAML credential literal과 private key 검출은 0이며 BuildKit `check`는 warning 0이다. - 해당 단계의 tracked Runtime credential 외부화는 `WAIT`였고 현재 tree 외부화 결과는 위 canonical 절이 소유한다. History rewrite와 기존 credential rotation은 계속 `WAIT`다. ## Image Runtime Dependency Gate - 첫 local image `contextra-analytics:smoke-7262bce`는 생성됐지만 Roboflow `trackers 2.6.0`이 `numpy>=2.0.2`를 요구해 Base image의 Triton Server `numpy<2` 계약과 충돌했다. 해당 image는 실행·push·export하지 않는 Test 전용 실패 evidence로 격리한다. - Actual source import 기준으로 `trackers`, `rfdetr`, `torchvision`, `supervision`, `filterpy`, `scipy`, SQLAlchemy·Alembic·Gunicorn·pydantic-settings는 현재 Runtime 필수 package가 아니다. 현재 `IoUTracker`를 Infra Smoke fallback으로 유지하고 NumPy 1.x 호환 ByteTrack 선정은 후속으로 분리한다. - Runtime 수치·이미지 기준은 `numpy==1.26.4`와 `opencv-python-headless==4.11.0.86`이며 GUI OpenCV는 설치하지 않는다. Torch는 `2.13.0+cu132`를 공식 CUDA 13.2 index에서 별도 설치한다. - 일반 Runtime package는 `docker/requirements-runtime.txt`, critical version은 `docker/constraints-runtime.txt`가 소유한다. 공식 package metadata resolver dry-run은 충돌 없이 통과했으며 host package 설치는 0이다. - DeepStream Base는 승인된 linux/amd64 digest `sha256:f6fa0247da9290979cbb05749e7da9435d089c93db7c4dcfe85ba2488b5f4994`로 고정한다. 상속된 NVIDIA build history의 인증값 형태 기록은 Test 전용 한시 예외이며 외부 배포 전 재판정한다. - Dependency 파일 보정 단계에서는 image build·container·Compose·GPU Runtime mutation이 0이었고, 이후 해당 commit SHA를 기준으로 incremental rebuild와 격리 Import Smoke를 수행했다. - Canonical image `contextra-analytics:smoke-790bbfb`은 commit `790bbfbad4f76571fd18a0724ba19f12ebcc84b5`에서 BuildKit cache로 생성됐다. `pip check`, exact version, 새 Runtime module, `app.main`, Health route, Stream·Active Learning 기본 Off와 application compileall을 통과했다. - Test Docker의 default runtime은 `nvidia`이므로 GPU 미전달 Import Smoke는 `--runtime runc`와 `NVIDIA_VISIBLE_DEVICES=void`를 명시해야 한다. 이 격리 조건에서 `torch.cuda.is_available=false`를 확인했고 단발성 container는 제거됐다. - Server-local `CONTEXTRA_IMAGE`는 `contextra-analytics:smoke-be367b7`로 전환됐고 deployment preflight는 PASS다. Analytics만 recreate했으며 PostgreSQL·Redis와 SSIMS container의 ID·restart·OOM은 불변이다. - 현재 Analytics는 GPU 0 하나만 보고 `RFDETRMedium`을 READY로 로드했으며 PostgreSQL·Redis와 FastAPI readiness가 정합하다. 이번 COMPOSITION image 검증에서는 RTSP·Frame inference를 실행하지 않았다. - TensorRT의 다른 GPU model engine plan 사용 경고는 기존 `MODELARTIFACT-GATE-01`에서 provenance·GPU 호환성과 Golden Output을 검증하기 전까지 추론 acceptance로 승격하지 않는다. - Redis image의 `/data` 선언으로 project named volume과 별개인 anonymous volume 1개가 생성됐다. 첫 Smoke readiness에는 영향이 없지만 완전 비영속 계약과의 차이는 장기 실행 전 Compose 보정 대상으로 둔다. - Startup log의 optional Rivermax UDP plugin warning은 남아 있지만 scanner executable과 `nvstreammux`, `nvinfer`, `nvdsosd` 등록은 PASS다. 실제 RTSP Pipeline acceptance는 계속 `WAIT`다. ## Model·Driver Gate - Host model root `/data/contextra/models`에는 Triton model directory와 `model.plan`이 각각 15개 있고, source/copy `config.pbtxt` parity는 `15/15 PASS`다. - Plan set SHA-256은 `b5a147fd082d037759b61ca10a94d7934f9538c89c1854e88ed50947ef17a9a2`다. - Canonical Compose는 `/data/contextra/models/triton/RFDETRMedium` 하나를 read-only bind한다. Model은 static candidate에서 Test Infra Runtime READY로 승격됐다. 다른 14개 model과 실제 inference는 WAIT다. - Driver는 Ubuntu package와 Open DKMS 방식으로 `580.142`에서 `595.84`로 반영됐다. Reboot는 kernel `6.8.0-117-generic`으로 정확히 1회 수행했고 SSIMS ch20 Runtime compatibility는 PASS다. - DKMS는 kernel 117과 138 모두 build PASS지만 kernel 138 actual boot·Runtime은 WAIT다. GRUB를 117로 영구 고정하지 않으며 다음 일반 reboot에서는 kernel 확인부터 압축 Runtime Gate를 적용한다. - Exact R580.142 rollback 22개와 R595 install 22개 cache는 `/data/system-maintenance/nvidia-driver/20260831-r595-prep/`에 보존한다. Kernel 138·Contextra Runtime acceptance와 별도 사용자 승인 전에는 자동 cleanup, `apt clean`, `apt autoremove`를 수행하지 않는다. - Reboot 뒤 `itone-redis`보다 `api-endpoint`가 먼저 시작돼 초기 실패한 이력은 Driver regression이 아니라 SSIMS dependency ordering Gap이다. Contextra restart policy와 healthy dependency ordering은 canonical Compose에 반영했지만 actual Runtime acceptance는 아직 WAIT다. ## 보류 사항 ### 진행 중 판단 후보 Registry 아래 항목은 각 행의 상태로 확정·방향 합의·미승인을 구분하며 구현 완료로 해석하지 않는다. 과거 Smoke 전 발견 항목과 최신 구현 판단 후보를 구분하고, 현재 재개점에서 세부 잠금과 순서를 조정한다. 현재 Stream Config는 server-local read-only Base `/workspace/contextra-runtime-config/configs/streams.yaml`과 writable Runtime overlay `/data/contextra/runtime-state/streams_runtime.yaml`을 결합한다. Base의 `streams: []`는 정적 등록 Stream 0개와 schema Gate를 명시하며, API 등록·삭제는 overlay의 `added/removed`에 반영된다. 유효 Stream은 `Base - removed + added`이고 overlay는 Host `/data`에서 Process·Container recreate 뒤에도 복구되지만 중앙 업무 DB나 장기 CCTV Config SOT는 아니다. 별도 Save Endpoint는 없다. | 판단 후보 ID | 상태 | 문제·방향과 처리 시점 | | --- | --- | --- | | `EOSOBS-01` | `DEFERRED · AFTER_SEPTEMBER` | 2026-09-20 현장 cameraId1 generation3에서 det `bus_eos` 뒤 상위 `ROLE_RUNTIME_FAILED/child_exit`가 관측됐다. 실시간 입력이 먼저 끝나고 이후 Web Stop이 왔을 가능성은 있으나 송출/네트워크/AI 내부 EOS 및 Stop 선후관계는 미확정이다. 최종 stopped, child_reaped/writer_released=true, forced=false, cleanup_pending=false, cleanup_error=null이며 completed=false는 정상 완료가 아니었다는 기록이지 미회수라는 뜻이 아니다. 입력 문제나 Web 책임으로 확정하지 않는다. 현재 증거상 자원 누수는 없어 사용자는 9월 목표 이후 재검토를 선택했다. 후속에는 EOS 최초 시각·source/bus 사유·Stop 접수/stop_requested 시각·child 종료 순서를 함께 확인해 복구 정책과 오류 표시를 판단한다. 반복 종료·자동 복구 실패·회수 누락으로 운영에 영향이 생기면 보류를 재검토한다. 관련 코드는 app/multi_pipeline.py의 EOSMessage 처리와 app/channel_process.py의 _finish다. | | `STREAMCFG-01` | `DIRECTION_ACCEPTED · DETAIL_LOCK_WAIT` | Smoke까지 빈 필수 Base Config를 유지하고 CCTV 장기 SOT로 확장하지 않는다. Smoke 뒤 또는 Platform 연동 설계에서 Bootstrap Seed 유지·비상 복구용 유지·제거를 재판정한다. | | `STREAMCFG-02` | `IMPLEMENTED · RUNTIME_WAIT` | Store transaction·저장 실패 fail-closed와 격리 HTTP/unit 회귀는 PASS. 배포된 실제 Runtime 검증은 WAIT다. | | `STREAMCFG-03` | `PARTIAL · WIRE_WAIT` | 내부 apply_and_start는 동일 설정 no-op·변경 설정 controlled restart를 제공한다. 일반 StreamSpec PUT/PATCH와 공개 Web Facade는 아직 미연결이다. | | `STREAMCFG-04` | `CLEANUP_WAIT` | 일부 source comment·docstring의 `Git Base`·`autostart 기동` 표현을 actual server-local Base·explicit Start 계약에 맞춘다. 동작 변경 없이 API·Config 보강 Batch에서 정리한다. | | `APIDOC-01` | `DIRECTION_ACCEPTED · HIGH_PRIORITY_AFTER_SMOKE` | Swagger HTML을 직접 수정하지 않고 FastAPI·Pydantic의 summary·description·Query·Field·credential-free example·`response_model`·HTTP error·side effect를 보강해 `/openapi.json`과 Swagger UI에 반영한다. `detail` 세 Backend 요청은 모두 HTTP `200`이었고 일시적인 Swagger `Failed to fetch`는 복구됐다. | | `APIID-01` | `LOCKED · IMPLEMENTATION_WAIT` | Web `cameraId`를 canonical `source_id`로 mapping하고 AI가 `stream_id/run_id/run_generation/frame_seq`를 생성한다. 기존 `stream_id`는 additive migration으로 호환하며 구현은 Identity·Router Batch가 소유한다. | | `RTSPOBS-01` | `DIRECTION_LOCKED · EVIDENCE_WAIT` | 현재 `nvurisrcbin`에서 raw RTP 또는 Reference Timestamp가 decoded Frame까지 보존되는지 실제 sample로 Probe한다. `buffer_pts`를 raw RTP로 추정하거나 evidence 없이 Custom Pipeline으로 전환하지 않는다. | | `IMAGEHYGIENE-01` | `PROBLEM_DISCOVERED · FIX_WAIT` | Final image에 rollback과 동일한 `__pycache__` 42개가 남는다. 이번 COMPOSITION 회귀는 아니며 Docker context·COPY 경계를 정리하는 후속 packaging Batch에서 제거와 재현성 검증을 판단한다. | 현재 구현·검증 재개점은 아래 13개 승인값 상태를 따른다. 이후 실제 blocker, `STREAMCFG-02~03`, `APIDOC-01`, `STREAMCFG-01·04`를 9월 일정과 관련성에 따라 묶되 미확정 계약이나 Runtime blocker를 억지로 합치지 않는다. ### Identity/Frame/Router 13개 승인값과 구현 상태 - 최신 사용자 승인과 9월 우선순위: [최소 구현 결정](decision/20260909T122527+0900-decision-identity-facade-september-minimum.md). - IDIMPL/RUNID/CONFIGREV/FRAMEIMPL/OBSIMPL/FRAMEWIRE/ROUTERSPLIT/WEBROUTE/WEBDTO/ SCENARIOAPPLY/STREAMAPPLY/APICOMPAT/IMPLBATCH의 각 `-01` 방향은 사용자 승인 완료다. 과거 integer-only·저장 실패 후 실행 허용 제안은 최신 승인값으로 교정됐다. - 이후 [side 승인 통합](decision/20260910T145810+0900-decision-september-metadata-web-integration.md)에서 SCENARIOAPPLY의 전체 거부와 WEBDTO/WEBSTART의 항상 ACCEPTED 응답 방향을 부분 대체했다. 아래 구현 이력은 보존하되 부분 skip·제한 대기 응답의 source 반영 완료로 해석하지 않는다. - 실제 구현: Frame/Observation 계약, legacy Stream Router·공통 Service, run UUID, Overlay fail-closed·transaction, draft Camera Start/Stop Facade. - Web route는 production app에 mount하지 않았다. Exact wire·status 응답·local default API· 설치 identity 연결은 보류. 기존 Scenario prototype을 검증된 지원으로 광고하지 않는다. - 실제 Frame ingress·one-decode·join·추론 FPS·Det/Pose semantic은 이번에 연결하지 않았다. - [부분 검증](validation/20260909T122527+0900-validation-identity-facade-partial.md) 이후 [격리 HTTP·회귀](validation/20260909T125609+0900-validation-identity-http-regression.md) 70개 PASS. 실제 FastAPI·OpenAPI 검증이며 Native 실행은 금지한 unit boundary다. 이후 image-owned 70개도 PASS, Analytics·Infra 반영은 완료했고 실제 Stream Runtime은 별도 검증 대기다. - 사용자 Swagger 확인은 PASS로 수용했다. 다음 재개는 위 Det Artifact 근거 보완 단계다. 전체 Audit을 반복하지 않으며 Runtime 배포 승인은 별도다. ### 기존 장기 보류 - tracking, scenario와 visualization을 같은 container에 둘지 분리할지 - Metadata Redis instance 선택·보존/Queue 수치와 별도 runtime registry 필요성은 구분해 판단 - 장기 자동 복구 timeout과 운영자 개입 기준 - 실제 runtime acceptance, deploy와 rollback 계약 - 역할별 inference, 임시 stream lifecycle, sanitized metadata와 장애 복구는 Test 서버에서 검증 - exact DeepStream Plugin graph, role scheduling, Frame aggregator cap·timeout - Platform 연동 뒤 `streams_runtime.yaml` 제거·cache·Local PostgreSQL projection 선택 - Git history credential 정리와 실제 기존 credential rotation - Redis anonymous `/data` volume의 nonpersistent Compose 보정 - Optional Rivermax warning과 실제 RTSP·DeepStream Pipeline acceptance - Contextra 나머지 14개 Triton model과 actual inference acceptance - kernel 138 actual boot·Runtime acceptance - ch21의 Driver 이전 input 문제와 container dependency ordering 보완 Test exact task branch는 `task/runtime-lifecycle-refactor`다. Service baseline 결과는 확인한 범위만 `partial PASS`이며 전체 runtime 또는 전체 scenario PASS로 확대하지 않는다. ## 읽기 순서 최신 미해결 Runtime 경계는 상단 복사 Gate와 완료/cleanup validation부터 읽는다. COMPOSITION 당시 구현 정적 근거는 [COMPOSITION-01 정적 validation](validation/20260905T200621+0900-validation-composition-canonical-import-static.md)에서 확인한다. Web Integration·FPS·Frame 시간·Artifact의 current 계약은 [AI 책임·최소 구현 범위](decision/20260910T152041+0900-decision-ai-metadata-minimum-scope.md)부터 읽고, 변경되지 않은 세부는 이 Decision의 extends 문서를 참조한다. 1. [MODARCH Target Architecture 최종 잠금](decision/20260905T180241+0900-decision-modarch-target-architecture-lock.md) 2. [MODARCH-01 Module Responsibility Audit](analysis/20260905T180241+0900-analysis-modarch-01-module-responsibility-audit.md) 3. [MODARCH 전 선행 Architecture 최종 잠금](decision/20260904T171113+0900-decision-pre-modarch-architecture-final-lock.md) 4. [9월 임시 WebRTC와 장기 Metadata-only 전환](decision/20260904T163624+0900-decision-temporary-webrtc-metadata-only-cutover.md) 5. [First Frame 이후 Adapter·Model·Module Audit 방향](decision/20260903T174842+0900-decision-first-frame-adapter-model-modarch.md) 6. [첫 RTSP Frame·Native/Python Count Parity 검증](runs/20260903T174842+0900-run-first-frame-native-python-count-parity.md) 7. [RTSP SourceAdapter image와 Infra 준비 검증](runs/20260903T130633+0900-run-rtsp-source-adapter-image-runtime-ready.md) 8. [RTSP SourceAdapter 구현 결정](decision/20260903T123249+0900-decision-rtsp-source-adapter.md) 9. [RTSP SourceAdapter 정적 검증](validation/20260903T123249+0900-validation-rtsp-source-adapter-static.md) 10. [RFBUILD image와 Native/Infra 준비 검증](runs/20260902T172609+0900-run-rfbuild-image-native-infra-ready.md) 11. [RFBUILD·STREAMERR 구현 계약](decision/20260902T163049+0900-decision-rfbuild-streamerr-contract.md) 12. [RFBUILD·STREAMERR 정적 검증](validation/20260902T163049+0900-validation-rfbuild-streamerr-static-ready.md) 13. [September-first, December-compatible 개발 원칙](decision/20260902T101155+0900-decision-september-first-december-compatible.md) 14. [RF-DETR Adapter·SSIMS 재사용 경계](decision/20260901T161936+0900-decision-rfdetr-adapter-ssims-reuse-boundary.md) 15. [첫 RTSP Smoke 실패 검증](runs/20260901T161936+0900-run-first-rtsp-custom-processor-failure.md) 16. [첫 Infra Runtime live/ready 검증](runs/20260901T130250+0900-run-first-infra-live-ready-pass.md) 17. [Canonical image static/import 검증](runs/20260901T114903+0900-run-canonical-image-static-import-ready.md) 18. [Canonical Compose·Config 경계 검증](validation/20260901T111710+0900-validation-canonical-compose-config-boundary.md) 19. [이전 Image static/import 준비 검증](runs/20260831T210953+0900-run-image-static-import-ready.md) 20. [Image build 보안 경계 검증](validation/20260831T172559+0900-validation-image-build-security-boundary.md) 21. [R595 Driver와 SSIMS ch20 Runtime 결과](runs/20260831T130110+0900-run-r595-driver-ch20-runtime-pass.md) 22. [Test task Owner와 Architecture 방향 잠금](decision/20260831T111534+0900-decision-test-task-owner-architecture-lock.md) 23. [Service baseline runtime 결과](runs/20260828T170618+0900-run-service-baseline-runtime.md) (`partial PASS / service baseline closed`) 24. [Runtime 구조 질답 재개 handoff](handoff/20260827T120122+0900-handoff-runtime-architecture-qa.md) (`discussion-paused`) 25. [Service baseline runtime validation 계획](validation/20260826T171128+0900-validation-service-baseline-runtime-plan.md) (`planned / not executed`) 26. [SSIMS·Contextra runtime reliability 분석](analysis/20260824T160059+0900-analysis-ssims-contextra-runtime-reliability.md) 27. 분석 문서에 기록된 source path 중 현재 질문과 직접 관련된 범위 28. 이후 생성되는 `decision`, `validation` 또는 `run` evidence ## 다음 재개점 ```text 실제 Frame snapshot 생성·cleanup PASS · 유효 탐지/ID WAIT · Redis transport/동일 Metadata 시각 확인 재개 ``` 최신 범위·필수 검증·병행 지점은 [일정/구현 Decision](decision/20260911T131415+0900-decision-september-deadline-delivery-priority.md)이 소유한다. Det ingress→Observation→ByteTrack→snapshot source와 실제 SDK identity copy/release 검증은 완료했다. image packaging·실제 identity 주입·짧은 입력 검증도 최신 run까지 수행했다. 전체 구현/SDK 조사는 반복하지 않는다. 다음 Redis/시각 확인 Batch에서 승인된 명확한 입력으로 실제 유효 탐지/Tracking ID의 미관측 부분을 함께 확인한다. 그 뒤 실제 채널별 Redis/시각 확인→INTRUSION, Pose·Fire/Artifact는 독립 진행한다. one-decode/Det-Pose fan-out·join은 후속 Pose 연결까지 유지하며 Det-only PASS로 전체 완료를 선언하지 않는다. 기존 Envelope 입력의 snapshot·publisher·읽기 예시와 Facade 응답의 독립 source/격리 검증은 완료했다. Web 구현은 제외하고 실제 AI ingress/Native 연결·Redis transport·Facade 공개 검증은 별도 범위로 정한다. Artifact는 공통 eventId 뒤 독립 진행 가능하다. surface 수명 fixture FAIL은 현 경로 비적용으로 분리했으며 이전 window와 이번 실제 Restart/cleanup 검증은 종료했다. 같은 종료 실험·추가 최적화를 선행하지 않고 실제 Frame/Metadata 연결의 다음 구현 범위를 이어간다. 새 build/Start는 별도 승인 범위이며 version1 자동 rollback은 하지 않는다. 공용 FINAL의 WebRTC/Start/시간 설명은 stale 후보이며 이번 수정0이다. ## Authority 경계 - SSIMS의 canonical runtime 계약은 `/workspace/ssims.ai`의 owner와 현재 source가 소유한다. - Contextra 공용 code, API, deploy와 test 계약은 repository root `AGENTS.md`가 소유한다. - 이 task branch의 분석·설계·구현·자동 검증은 `(test, ltb1021, work-session)`이 소유하며, service `main`의 배포·최종 Runtime acceptance는 service 서버가 소유한다. - 이 README는 profile용 current capsule이며 실제 runtime 상태나 구현 완료를 주장하지 않는다.