선택: VM(crownyc.c FB_MAX 정적배열) 직접 확장은 crownyc 쓰는 수백 서비스의 메모리·회귀 영향(고위험) → 보류. 대신 브라우저 canvasSize()가 FB_MAX 초과 캔버스를 요청하지 않도록 클램프(crowny-browser.m:1443 부근).
정확성 증명: fb 쓰기 opcode가 fb_width/fb_height로 클램프하므로 CW×CH ≤ FB_MAX면 모든 index=yfb_width+x < fb_widthfb_height ≤ FB_MAX = 배열 안. 완전 방어(부분 아님).
구현: permille 이분탐색 종횡비 유지 축소(math.h 불요, 순수 정수). 검증: 7개 창크기(1280x712~2560x1440@2x) 전부 CW×CH ≤ 1,024,000 + 종횡비 오차 0%. 클램프 크기 렌더=하단 검은잘림 0/4, 정상 배경색.
효과: 메모·터미널(반응형)=모든 창크기 정상 표시. 전 앱=크래시·검은잘림 0. 잔존(P2): 계산기·시계는 800x600 절대좌표라 크래시는 없지만 버튼이 구석 클러스터(반응형 재작성 필요).
P0-2 (VM 근본 — 별도 승인 대기): crownyc.c 프레임버퍼를 정적배열→동적 malloc(화면초기화 시 CW×CH 할당)로 전환하면 상한 자체 제거+레티나 풀해상도 크리스프. 단 VM 핵심부라 전체 회귀 게이트 필수(중~고 리스크). 클램프로 급한 불 껐으므로 신중히 별도 진행.
P2 계산기·시계 반응형 완료 (2026-07-12) — 실제 "그림만·비율이상"의 소재지
핵심 정정: 사용자 "메모/터미널 전혀 개선 안됨"이 맞았음. 렌더 이미지를 직접 눈으로 확인한 결과: 메모·터미널은 이미 정상 렌더(반응형), FB_MAX 수정은 큰 창 검은잘림만 막아 보통 창에선 무변화. 실제 깨져 보인 건 계산기·시계(800×600 절대좌표 → 좌상단 구석 뭉침).
수정: 계산기앱.한선/시계앱.한선을 균일 스케일(permille=min(CVW/800,CVH/600))+센터 오프셋으로 리팩터. 설계 800×600 좌표 유지, 렌더 시 _sx/_sy/_s로 스케일. 종횡비 왜곡 0, 구석 뭉침 제거.
검증(육안): 1356×754·1168×876 렌더를 PNG로 변환해 직접 확인 — 계산기 버튼그리드·디스플레이가 캔버스 중앙 꽉 채움, 시계 제목·시각·버튼 중앙정렬. 컴파일 exit0. .한선 소스 수정이라 렌더스크립트 자가치유로 자동 반영(브라우저 재빌드 불요).
교훈(★): 픽셀 샘플링만으로 "정상"이라 판정한 게 반복 오진의 원인. 렌더 PPM을 PNG로 변환해 Read로 직접 봐야 실제 레이아웃 결함이 보인다. 이후 GUI 검증은 이미지 육안 필수.
미세 잔여: 시계 시각 글로우박스가 시폭 계산(글자폭추정 근사)로 살짝 우측 치우침. 계산기 디스플레이 그림자 우측 약간 넘침. 둘 다 경미(글자폭추정→실 advance 교체 시 해소, P1).