# Google Calendar — Arise live workflow benchmark

최종 확인: 2026-10-31 · 이슈 #103 / #126 · **R8: 짧은 L1로 T·M 모두 통과, 이번 비교에서 M 시간·호출 감소**

## R8 — 실제 막힌 경로를 줄인 짧은 메모리

기본 Calendar 힌트 세 개의 L1 본문을 합계 1,852자에서 1,103자(40.4% 감소)로 줄였다. 제목·현지 시각·시간대를 미리 채운 미저장 편집기 진입, Custom 반복 요일의 중복 선택 방지, 변경하지 않을 회차는 편집기 대신 저장된 팝업으로 확인하는 지침을 남겼다. 이 계정의 미저장 probe에서는 `recur=RRULE:...BYDAY=MO...`가 화요일로 표시되어, 기본 지침은 반복 규칙을 UI에서 설정하도록 한다.

새 seed를 적재한 격리 로컬 WAM API에서 실제 recall한 **L1만** M에 제공했다. L2는 버전·본문 대조용으로 따로 조회했고 작업자에게 전달하지 않았다. 전체 작업 프롬프트는 T 1,271자, M 2,465자였다. 입력창 copyback과 실행기 원문 일치, 자동 과거 기억 두 주입의 부재, 두 조건의 동일한 시작 페이지 wrapper를 확인했다.

| 조건 | 전체 작업·독립 확인 | 실행 시간 | 외부 도구 경계 | 실행 중 관찰 |
|---|---|---:|---:|---|
| T — 작업만 | 통과 | 431.108초 | 114 | stale 참조 거부 1회 |
| M — 수정한 L1 | 통과 | 237.169초 | 68 | 시작 시 tab_busy 거부 1회 |

이번 한 쌍에서 M은 **193.939초(44.99%)**, 외부 도구 경계 **46회(40.35%)**가 적었다. 같은 설치 Arise 0.1.60, `gpt-6-luna/max`, 새 대화, 실행당 900초다. 순서는 M→T이며 양쪽의 작업·도구 규칙은 같다. 양쪽 모두 browser_script는 금지했고 functions.exec의 여러 허용 도구 묶기는 허용했다. 표는 실제 외부 호출 경계를 센다. 별도 AST 소스 감사의 개별 브라우저 도구 호출은 T 176회, M 98회다. 이 두 로그에는 해당 호출을 감싼 조건·반복·동적 간접 호출이나 스크립트 실행 오류가 없어, 묶음 수 차이와 별개로 개별 호출도 줄었음을 확인했다. 실행 중 추가 memory 호출과 감사에서 탐지한 eval 변경 패턴은 모두 0이었다.

독립 검증자는 각 조건의 정확한 QA 제목을 별도 탭에서 검색해 결과가 세 건뿐임을 확인하고 **세 회차 팝업을 각각 다시 열었다**. LA 11월 2·16일 09:00–09:30, 9일만 10:00–10:30이며 월요일 3회·Los Angeles가 표시됐다. GMT+9 화면의 11월 3·17일 02:00, 10일 03:00과 일치했고 네 번째 회차가 없었다. 두 QA 시리즈만 모든 일정 범위로 삭제한 뒤 새 탭 검색 0건을 확인했다. 독립 확인 중 popup 전환의 이전 내용 읽기와 정리 클릭 재시도는 작업 수치 밖이며 #27에 남겼다.

이번 비교는 R7 경로를 보고 수정한 개발 관찰이다. 별도 미사용 과제나 반복 통계가 없고 조건당 한 번이며 순서는 무작위가 아니고 로그인·캐시 상태를 공유한다. 힌트 본문과 L2 전달 방식을 함께 바꿨으므로 각 변경의 효과를 분리하지 못했다. 준비의 메모리 조회·독립 확인·정리 시간은 제외했다. **일반적인 속도·비용 절감이나 자동 Arise–WAM 통합을 입증한 결과는 아니다.** R7과 R8은 전달량·도구 규칙이 달라 직접적인 인과 비교로 쓰지 않는다.

격리 서버의 실제 L1을 seed와 대조했다. 새 catalog에서는 version 번호가 다시 1부터 시작하므로 기존 서버와 opaque version_id가 같더라도 본문이 같다고 보지 않는다. Calendar 변경을 최종 기본 seed에 남겼으며, 최종 격리 catalog의 실제 L1과 고정 버전 L2도 source와 일치했다. 기존 공유 서버는 변경하지 않았다. 기존 ID를 건너뛰는 기본 seed의 명시적 갱신 경로는 #127로 추적한다. 시험 후 실제 앱의 자동 기억 두 스위치는 원래 true/true로 복원하고 파일에서도 확인했다.

로컬 증거: `target/e2e-logs/bench/productivity-live126-r8/`의 `calendar-{T,M}-result.json`, 입력 검증, `calendar-matched-wrapper-proof.json`, `calendar-{T,M}-independent-popups.json`, `calendar-{T,M}-cleanup.json`, `calendar-comparison.json`, `calendar-retrieval.json`, `seed-source-proof.json`, `final-seed-source-proof.json`, `settings-restored.json`, `prefill-probe.json`. 계정 원본 화면과 전체 실행 로그는 공개 저장소에 넣지 않는다.

이전 R7 판정: T·M 전체 성공, 당시 실행에서 시간·호출 절감 없음.

## R7 — 0.1.60 배포 후 실제 전체 작업 재시험

포커스 수정 `30bc7b3`을 포함한 소스 `3fe67c6` / `v0.1.60`을 macOS·Windows·Linux에 배포했다. 공개 파일 다섯 개의 전체 해시, 세 플랫폼 피드 서명과 다운로드 경로 16개를 확인했고 배포 기록 `efb9277`을 커밋·푸시했다. Mac GUI와 bundled MCP도 서명된 바이너리로 함께 교체했다. 프로필이나 인증 정보는 복사하지 않았다.

실제 설치본에서 채팅창을 클릭해 document.hasFocus=false를 만든 뒤 CEF browser_click만으로 반복 메뉴가 열리고 600ms 뒤에도 유지되는 것을 확인했다. 두 번째 클릭은 정상적으로 닫혔다. 서명 패키지의 확인창 12개·포커스 5개 검사도 통과했다.

같은 `gpt-6-luna/max`, 새 대화, 900초 한도로 실행했다. 두 자동 기억 스위치는 실제 상속 XDG 경로에서 꺼졌고 실행기 user 기록에 자동 Workspace history / Browser know-how가 없었다. 입력창 copyback과 실행기 입력을 원문과 대조했다(T 1,176자, M 7,998자). M은 실제 WAM recall 및 version-pinned L2 세 항목을 미리 제공했다.

| 조건 | 전체 결과와 독립 확인 | 외부 도구 경계 | 실행 시간 | 관찰한 재시도·오류 |
|---|---|---:|---:|---|
| T | 세 회차·시간대·11월 9일만 변경·네 번째 회차 없음 모두 통과 | 108 | 367.677초 | renderer/focus/stale 표식 0; 묶음 단계 수 25>20 거부 1회 |
| M | 같은 전체 기준 모두 통과 | 137 | 380.690초 | stale 참조 거부 1회 뒤 새 화면으로 재시도; renderer/focus 표식 0 |

명시적 memory 호출은 두 조건 모두 0이고, 감사에서 탐지한 eval 변경 패턴도 0이다. 실제 외부 도구 경계를 세었으며 준비·독립 확인·정리는 제외했다. 실행 완료 시각 이전의 마지막 backend token_count / total_token_usage도 별도로 추출했다.

| 조건 | 누적 input | 그중 cached input | output | total |
|---|---:|---:|---:|---:|
| T | 10,812,999 | 10,622,720 | 26,387 | 10,839,386 |
| M | 13,110,065 | 12,951,168 | 28,809 | 13,138,874 |

이 값은 반복 컨텍스트를 포함한 실행기 누적 보고값이며 고유 프롬프트 길이나 청구 비용이 아니다. 캐시 상태도 조건별로 달라 비용 절감으로 해석하지 않는다.

두 조건 각각 별도 탭에서 정확한 QA 제목을 검색해 **세 결과의 팝업을 모두 다시 열었다**. LA 11월 2·16일 09:00–09:30, 9일만 10:00–10:30이었다. 서울 화면에서는 각각 3·17일 02:00–02:30, 10일 03:00–03:30이며, 모든 팝업에 매주 월요일·3회·로스앤젤레스가 표시됐다. 전체 검색 결과도 이 세 건뿐이었다. 확인 후 각 QA 시리즈의 ‘모든 일정’ 범위를 선택해 삭제했고, 새 검색에서 두 제목 모두 0건을 확인했다.

이번 관찰에서 M은 호출 수도 시간도 줄지 않았다. 조건당 한 번, T→M 고정 순서와 공유 로그인 상태이므로 일반 성능이나 인과 효과를 주장하지 않는다. T는 허용된 키 입력을 browser_script로 묶었는데 이 묶음 도구 자체는 요청의 허용 목록에 빠져 있었다. M의 자동 현재 페이지 접두부도 T와 달랐다(과거 기억 주입은 둘 다 없었다). 따라서 엄격히 통제한 메모리 효과 벤치마크로 사용하지 않는다. 실제 저장 결과와 독립 검증은 유지한다. 자동 Arise–WAM 통합 검증도 아니다.

로컬 증거: `target/e2e-logs/bench/productivity-live103-r7/`의 `calendar-{T,M}-result.json`, 입력 검증 JSON, `calendar-{T,M}-independent-popups.json`, `calendar-{T,M}-cleanup.json`, `calendar-native-focus-green.json`, `calendar-retrieval.json`. 계정 원본 화면·전체 실행 로그는 공개 저장소에 넣지 않는다.

시험 종료 후 실제 XDG 경로와 기본 설정 경로의 자동 기억 두 스위치를 원래 true/true로 복원했고 앱 화면·파일 readback을 확인했다. 증거는 R7 `settings-restored.json`이다.

## R6 — 0.1.59 실제 앱에서 남은 포커스 문제 확인

Codex 도구 허용 목록 수정 `3ed8215`를 포함한 0.1.59를 세 운영체제에 배포하고 Mac의 GUI와 MCP를 함께 교체했다. 실제 앱 채팅에서 확인창 inspect/dismiss와 다운로드 조회를 호출해 검증했다(39.670초, 외부 도구 경계 10회, 52바이트 파일 원문 일치).

이번 대조군은 실제 앱 UI와 실제 XDG 설정 경로에서 자동 기억 두 스위치 꺼짐을 확인했다. 채팅 입력창 copyback 및 실행기 user 기록의 전체 요청 1,176자가 원문과 일치했고, 자동 Workspace history와 Browser know-how 주입이 없었다.

| 조건 | 결과 | 외부 도구 경계 | 실행 시간 | 실제 관찰 오류 |
|---|---|---:|---:|---|
| T | 반복 메뉴를 열지 못해 저장 없이 초안 폐기 | 83 | 399.356초 | editable focus 3, renderer timeout 0, stale 0 |
| M | 포커스 수정 뒤 같은 버전의 새 T/M으로 재시험 예정 | — | — | — |

T의 명시적 memory 호출 0, 탐지한 DOM 변경 패턴 0이다. 독립 탭에서 정확한 QA 제목을 새로 검색해 결과 0건을 확인했다. 유효한 입력을 받은 단일 대조군 기록이며, 짝이 되는 M 실행이나 메모리 개선 효과는 아직 없다. 도구 설명을 반환한 catalog-only 출력은 오류 집계에서 제외했다.

별도 새 빈 편집기에서 반복 컨트롤이 활성(aria-disabled=false)임을 확인했다. CEF 자동 클릭은 성공 응답 뒤에도 메뉴가 닫혀 있었지만, 같은 좌표를 네이티브 OS로 클릭하면 열렸다. 페이지의 빈 곳에 네이티브 포커스를 준 뒤에는 같은 CEF 클릭도 동작했다. 다시 채팅창을 누르면 document.hasFocus=false이고 CEF 클릭 뒤에도 false 및 메뉴 닫힘 상태가 유지됐다. 이 동작은 별도 자동 검사에서 실제로 실패했다.

계정 없는 격리 CEF에서도 trusted click 1회 후 앱의 폴링이 페이지 포커스를 회수해 메뉴가 닫히는 현상을 재현했다. CEF 마우스 경로가 앱의 페이지 포커스 의도를 갱신하지 않아 GPUI 회수 가드가 개입하는 코드 경로를 확인했고, #125에서 수정 `30bc7b3`에서 페이지 포커스 의도와 네이티브 responder를 함께 맞추되, 이미 포커스를 소유한 렌더러는 재지정하지 않도록 했다. CEF 208개·채팅 포커스 1개와 격리 실제 CEF 5개 검사가 통과했고 전후 이미지를 검사했다. 고정 소스 `3fe67c6`으로 0.1.60을 준비 중이며 실제 계정 전체 성공은 아직 확인하지 않았다. 좌표·스냅샷 참조 문제나 메모리 부족으로 단정하지 않는다.

R6 로컬 증거: `target/e2e-logs/bench/productivity-live103-r6/`의 `calendar-T-result.json`, 입력 검증 JSON, `calendar-native-focus-red.json`. 계정 없는 재현은 Arise 저장소의 `target/e2e-logs/native-focus125-before/`에 있다. 원본 계정 화면은 공개 저장소에 포함하지 않는다.

## R4 — Arise 0.1.58 배포 후 실제 재시험

> 사후 입력 대조에서 호스트 Unicode 입력의 20자 단위 누락을 확인했다. 후속 점검에서는 실제 앱 설정 경로가 달라 자동 기억 격리도 보장되지 않았음을 확인했다. 준비한 요청과 실제 전달된 요청이 달라 **아래 T/M 수치는 메모리 효과 비교에서 제외한다.** M의 세 일정 저장·시간대·단일 회차 변경과 정리 결과는 독립 확인된 사실로 유지한다. 정확한 입력을 검증하는 방식으로 재시험한다.

0.1.58의 GUI와 bundled MCP를 함께 설치하고 서명된 배포 바이너리와 해시가 일치함을 확인했다. 소스는 `e2497ef`, 태그는 `v0.1.58`, 배포 기록 커밋은 `4918312`이다. macOS·Windows·Linux 공개 게시와 다섯 전체 다운로드 해시, 피드 서명, 다운로드 경로 검증을 마쳤다. 확인창 수정 `f525a6d`가 이 버전에 포함된다.

같은 `gpt-6-luna/max`의 새 Arise 대화 두 개에서 아래 고정 작업을 수행했다. 자동 personal/WAM 기억을 끄도록 기본 설정 파일을 바꿨으나, 이후 실제 앱이 임시 XDG 설정 경로를 사용함을 확인했다. 따라서 자동 기억이 꺼졌다는 준비 기록은 신뢰하지 않는다. T의 명시적 메모리 호출은 금지했다. M에는 이번에 실제 WAM API에서 다시 조회한 세 메모리의 L1 및 version-pinned L2를 제공했다. `browser_dialog`도 두 조건에 동일하게 허용했다.

| 조건 | 전체 작업 | 실제 외부 도구 경계 | 실행 시간 | 관찰 오류 |
|---|---|---:|---:|---|
| T | 실패: 반복 메뉴를 열지 못해 저장 0건 | 86 | 307.816초 | editable focus 1; stale 0; renderer timeout 0 |
| M | 성공: 3회 반복·시간대·한 회차 변경·저장 후 재확인 | 152 | 826.272초 | editable focus 2; stale 0; renderer timeout 0 |

실제 도구 기록에서 두 조건 모두 추가 메모리 호출 0, 탐지한 DOM 변경 패턴 0이었다. 시간은 backend task 시작·완료 이벤트 기준이다. 운영자의 프롬프트 입력 문제와 준비 시간은 제외했다. 토큰 사용량은 측정하지 못했다.

T 종료 뒤 별도 탭의 정확한 제목 검색은 0건이었다. M 종료 뒤 별도 탭에서 정확한 제목으로 검색해 세 일정만 찾았고 **각 팝업을 실제로 다시 열었다.**

| LA 날짜 | LA 시간 | 서울 화면에서 재확인한 시간 |
|---|---|---|
| 2026-11-02 | 09:00–09:30 | 11월 3일 02:00–02:30 |
| 2026-11-09 | **10:00–10:30** | 11월 10일 **03:00–03:30** |
| 2026-11-16 | 09:00–09:30 | 11월 17일 02:00–02:30 |

세 팝업 모두 ‘매주 월요일, 3회 (미 태평양 시간 - 로스앤젤레스)’를 표시했다. 전체 제목 검색에서 이 세 날짜만 반환되어 11월 23일의 네 번째 회차가 없음을 확인했다. 검증 후 QA 시리즈의 ‘모든 일정’ 범위를 실제 선택·확인해 삭제했고, 새 검색에서 0건을 확인했다. 기존 일정은 수정하지 않았다.

이 실행의 저장 결과는 T 실패/M 성공이었지만, 입력 유실 때문에 유효한 조건 비교가 아니다. T→M 고정 순서와 공유 로그인 상태이며 M에도 반복 메뉴 재시도가 많았으므로, 메모리가 유일한 원인이라는 주장이나 일반적인 성공률·호출 절감률을 제시하지 않는다. M의 152회는 실패한 T의 86회보다 적지 않으며 성공에 필요한 호출 절감으로 비교할 수 없다. 자동 Arise–WAM 통합 검증도 아니다.

R4 로컬 증거: `target/e2e-logs/bench/productivity-live103-r4/`의 `calendar-T-result.json`, `calendar-M-result.json`, `calendar-retrieval.json`, 실제 제공 프롬프트. 계정 원본 화면이나 전체 에이전트 로그는 공개 저장소에 포함하지 않는다. 자동 기억 설정의 최종 복원은 서비스 전체 시험이 끝난 뒤 확인한다.

## 이전 R3 기록

## R3 환경과 비교 조건

- 설치본: Arise 0.1.57, macOS arm64. 앱과 bundled MCP에 `06d991a`의 클릭 안정화 코드가 포함됨을 확인했다.
- 실행 모델: Codex `gpt-6-luna`, effort `max`; Arise 앱의 새 대화에서 실행한다.
- T: 자동 personal/WAM recall을 끄고 명시적 memory 도구도 금지한다. 실제 도구 기록으로 위반 여부를 확인한다.
- M: 같은 조건의 새 대화에 실제 WAM recall 및 version-pinned L2 expand 결과를 명시적으로 제공한다. 자동 Arise–WAM 통합 검증은 아니다.
- 조건당 1회, T→M 고정 순서의 파일럿이다. 반복·무작위·격리 계정 벤치마크로 해석하지 않는다.
- 조건별 제한은 15분이다. 도구 호출 완료는 저장 성공이 아니며, 독립된 화면 재확인이 성공 기준이다.

## 고정 작업과 성공 기준

1. 정확한 QA 제목으로 2026-11-02 09:00–09:30, `America/Los_Angeles` 일정 생성.
2. 매주 월요일만 반복하고 총 3회, 11월 2·9·16일에 종료.
3. 11월 9일 한 건만 10:00–10:30으로 이동. 2일과 16일은 그대로 유지.
4. 세 일정을 저장 후 다시 열어 날짜·시간·시간대·변경 범위를 확인하고, 11월 23일에는 없음을 확인.
5. 검증 후 실행이 만든 QA 일정만 정리. 기존 일정·전역 시간대는 변경하지 않고 게스트를 추가하지 않는다.

## 배포 후 회귀 관찰

| 검사 | 관찰 |
|---|---|
| DOM 앞에 다른 버튼 삽입 후 기존 Repeat 참조 | 의도한 Repeat 클릭 통과 |
| 요소 교체·문서 이동 후 오래된 참조 | stale 오류로 거부 통과 |
| 펼쳐지는 빠른 입력창에서 Repeat 클릭 | 메뉴 열림, trusted native 클릭 확인, Meet 오클릭 0 |
| 첫 클릭 probe 시도 | 초기 hydration 중 stale 참조로 안전하게 거부됨; 재시도 기록 유지 |
| 전체 편집기에서 시간대 취소 후 Repeat 메뉴 | 메뉴 열림 확인 |
| 빈 초안 취소 후 페이지 복귀 | `Renderer response timed out` 재발, 기존 이슈 #27에 기록 |

마지막 오류가 있어 모든 브라우저 회귀 검사를 통과했다고 보고하지 않는다. 실제 메뉴 PNG는 직접 검사했으며, 계정 화면이므로 저장소에 포함하지 않는다.

## 메모리와 측정

조회된 메모리: `web:example-calendar-recurring`, `web:example-calendar-timezone`, `web:example-calendar-reschedule`. 세 항목의 L1 및 version-pinned L2 조회가 성공했다.

| 조건 | 전체 작업 성공 | 도구 호출 | 재시도·오류 | 메모리 조건 유효성 |
|---|---|---:|---|---|
| T | 실패: 반복 생성 성공, 11월 9일 이동 미완료 | 202 | renderer timeout 8, inactive tab 2, editable focus 오류 1 | 메모리 호출 0; 탐지한 DOM 변경 패턴 0 |
| M | 실패: 반복 생성 성공, 11월 9일 이동 미완료 | 133 | renderer timeout 6, inactive tab 1, editable focus 오류 2 | 실제 조회 힌트 3개 제공; 추가 메모리 호출 0 |

이전 R1(0.1.55)은 실패했고, R2(0.1.56)는 실패와 함께 명시적 메모리 조회·제목 변경이 있어 유효 대조군에서 제외했다. 성공한 단계만 골라 속도나 호출 절감률을 계산하지 않는다.

## T 실행의 독립 확인

T는 11:58:12 UTC에 시작했고, 15분 한도 뒤 운영자가 12:13:32 UTC에 중단했다. 실제 관찰 시간은 약 920초로, 중단 조작 지연 약 20초가 포함된다. 성공 완료 시간으로 사용하지 않는다. 위 호출 수는 실제 외부 도구 경계 수이며, 배치 안의 여러 브라우저 동작은 한 번으로 센다. 준비·독립 확인·정리 호출은 제외한다. 토큰 수는 호스트에서 유효하게 수집하지 못해 보고하지 않는다.

실행 후 별도 탭의 정확한 QA 제목 검색에서 세 일정만 찾았고 세 팝업을 각각 다시 열었다. 모두 서울 표시 시간 11월 3·10·17일 02:00–02:30, 요약은 매주 월요일 3회·로스앤젤레스였다. 이는 LA 11월 2·9·16일 09:00–09:30에 해당하며, 요청한 11월 9일 변경은 저장되지 않았다. 네 번째 일정은 검색되지 않았다.

QA 시리즈만 ‘모든 일정’ 범위로 삭제한 뒤 새 검색에서 0건을 확인했다. T가 연 12개 작업 탭도 닫고 실제 제거를 확인했으며, 기존 사용자 탭과 로그인 준비 탭은 유지했다. 실행 중 데스크톱에 leave/reload JavaScript Confirm이 보였고 renderer timeout·검은 화면이 발생했으나, 대화상자가 모든 오류의 단일 원인이라는 결론은 내리지 않았다.

## M 실행의 독립 확인과 해석

M은 12:19:20.886–12:28:02.130 UTC, 약 521초(8분 41초)에 실패를 명시하고 종료했다. T와 같은 모델·effort 및 자동 기억 꺼짐 상태의 새 대화였으며, 버전을 지정해 실제 조회한 힌트 세 개를 프롬프트로 제공했다. 다른 메모리 도구 호출이나 탐지한 DOM 변경 패턴은 없었다.

별도 탭의 정확한 제목 검색과 세 팝업 재열기에서 T와 동일한 날짜·시간·요일·시간대를 확인했다. **11월 9일은 09:00 그대로였으므로 단일 회차 변경은 실패**다. QA 시리즈 삭제 뒤 새 검색에서 0건을 확인했고, M이 만든 작업 탭 네 개도 실제 제거를 확인했다. 다른 세션의 탭은 보존했다. 자동 personal/WAM 기억 설정은 원래 값인 true/true로 복원하고 실제 설정 값을 확인했다.

133회와 202회의 차이는 **완료에 필요한 호출 절감률이 아니다**. T는 시간 한도에서 중단됐고 M은 실패 보고로 종료했으며, 두 조건 모두 전체 작업에 실패했다. M 중 같은 Arise 인스턴스에 다른 세션의 작업 탭도 열려 호스트가 격리되지 않았다. 조건당 한 번·고정 순서·공유 로그인 상태의 관찰이므로 인과적인 메모리 효과나 속도 향상을 주장하지 않는다.

추가 관찰로, T의 실제 페이지 캡처와 데스크톱 화면을 각각 검사했을 때 페이지 단독 캡처에는 네이티브 leave/reload 확인창이 포함되지 않았다. 대화상자 관측·응답과 renderer timeout의 관계는 #27에서 조사할 범위이며, 단일 원인으로 확정하지 않았다.

## 후속 원인 재현과 코드 수정

로그인 질문이 시간 초과된 뒤에도 독립적인 원인 조사를 이어갔다. 로그인 데이터를 쓰지 않는 동일 재현 페이지에서 설치된 0.1.57 GUI의 격리 복사본은 JavaScript 확인창을 연 뒤 페이지 읽기가 **6.004초 후 renderer timeout**으로 실패했다. 수정본은 대기 중인 확인창을 즉시 보고하고 명시적 응답 후 계속 진행했다. 따라서 네이티브 확인창 처리 누락이 이런 시간 초과를 만드는 한 원인임은 확인했으나, 기존 캘린더의 모든 실패를 같은 원인으로 단정하지 않는다.

Arise 소스 커밋: **`f525a6d`** (`fix/js-dialog-control-20261030`). 확인창을 조회하고 현재 ID를 명시해 수락·취소하는 `browser_dialog` 경로를 앱과 MCP에 추가했다. 오래된 ID·다른 리스의 응답, 사용자 인계·만료 후 대기 중이던 승인은 거부하며, 취소 시 초안을 보존한다. `wait_for`도 대기 중인 확인창을 일반 로딩으로 반복 폴링하지 않는다.

검증은 focused 테스트 **388개**, 격리된 실제 CEF의 **12개 시나리오**에서 통과했다. 확인/취소·한글 prompt·alert·지연 승인 뒤 후속 확인창·리스 종료·beforeunload 초안 보존·명시적 화면 이동을 검증하고 최종 PNG도 검사했다. 소스는 별도 worktree에 커밋했으며 원래 배포 브랜치는 정리했다.

**R3 종료 당시에는 설치된 앱과 MCP를 교체하지 않았다.** 이후 0.1.58로 함께 배포·설치했으며 재시험은 위 R4 및 후속 R5 기록을 따른다. 위 R3 실패 결과와 메모리 효과 미검증 상태는 그대로 유지한다. 합성 증거는 Arise 저장소의 `target/e2e-logs/js-dialog27-before/`, `js-dialog27/`에 있으며 실제 계정 자료를 포함하지 않는다.

## 증거와 남은 범위

- 로컬 증거: `target/e2e-logs/bench/productivity-live103-r3/`.
- 공개 저장소에는 재현 작업·집계 결과만 기록한다. 원본 계정 화면, 비공개 일정, 전체 에이전트 로그는 포함하지 않는다.
- 테스트 계획: `plan.json`; 실제 recall/expand: `calendar-retrieval.json`.
- 조건별 집계: `calendar-T-result.json`, `calendar-M-result.json`; 최종 결과: `result.json`.
- R3에서는 반복 생성·시간대·재열기·정리를 확인했고 단일 회차 변경은 실패했다. R4 전체 저장 상태는 위 절에서 확인했으나, 입력 유실로 메모리 효과 비교는 무효다.
- R3 당시 Canva·Notion은 로그인 화면까지 확인했다. 현재 상태는 각 서비스의 최신 기록을 따른다. 당시 메뉴·요소 참조 회귀와 웹 메모리 helper 테스트 8개, 문서 링크 검사를 통과했다.