The same answers on the final build and the same pure-runs on the Pi, WSL2 and a Mac (121); 019 points at 020's view workers

2 files changed, 8 insertions, 3 deletions

diff --git a/docs/design/019-pushing-views.md b/docs/design/019-pushing-views.md
index bf409ad..a2ce315 100644
--- a/docs/design/019-pushing-views.md
+++ b/docs/design/019-pushing-views.md
@@ -67,8 +67,9 @@ data: 135
 ## 단계
 
 1. 위의 전부. 한 앱의 호스트와 여러 앱의 호스트(`--apps`) 모두.
-2. (나중) 측정이 요구하면: 하트비트(프록시의 유휴 끊김), 보기가 읽는 상태가 바뀌지 않은 스냅숏을 계산하지 않고 건너뛰기, 긴 보기를
-   연결 스레드 밖에서(119).
+2. (나중) 측정이 요구하면: 하트비트(프록시의 유휴 끊김), 보기가 읽는 상태가 바뀌지 않은 스냅숏을 계산하지 않고 건너뛰기. 긴 보기를
+   연결 스레드 밖에서(119)는 [020](020-computing-faster.md)의 2단계로 했다: 본문이 있는 보기의 무리는 보기의 스레드에 계산을
+   넘기고, 그동안 온 새 스냅숏은 그 뒤에 계산한다([122](../research/122-views-off-the-connection-threads.md)).
 
 ## 착수 기준
 
diff --git a/docs/research/121-computing-faster.md b/docs/research/121-computing-faster.md
index db99568..2220aee 100644
--- a/docs/research/121-computing-faster.md
+++ b/docs/research/121-computing-faster.md
@@ -141,7 +141,11 @@ in_credit의 둘째 쌍(+2.21%)은 한 쌍으로는 기준을 넘는다. 그 질
   기록을, 통째로 저장한 항목 뒤에 다시 하면 그 리스트다(재시작 59번).
 - 두 검사가 잡는지 일부러 망가뜨려 봤다: 표에서 지울 때 뒤를 당기지 않으면 `key_sets`가, 손가락이 판을 보지 않으면 공유 검사가,
   키로 넣기가 기록의 길이를 더하지 않으면 `keyed_journal`이 멈춘다.
-- 두 빌드(전과 처음의 후)의 은행 질의 일곱의 답이 바이트까지 같다(`same_answers.py`).
+- 전과 후(`9484700`, `dde73e4` 둘 다)의 은행 질의 일곱의 답이 바이트까지 같다(`same_answers.py`, `2026-10-04-same-answers.txt`).
+- 기기 사이(033의 `record.py`, 029의 기록 방식): aup의 `transients`와 `computing` 검사가 돌리는 `pure-run` 46번이 Pi, WSL2(gcc 13),
+  M3 Mac(clang 21)에서 출력, 오류, 종료 코드까지 모두 같고, 그 모듈 넷의 바이트가 같다(`2026-10-04-{pi,wsl,mac}-record.jsonl`).
+  Mac의 기본 SDK(27.0)는 그 기계의 링커가 읽지 못해 26.5로 빌드했다(`SDKROOT`). WSL에서 처음 한 번 멈춘 것은 기록을 쓸 수 없는
+  경로를 준 내 명령 때문이었다(같은 경로로 다시 내면 같은 자리에서 멈추고, 맞는 경로로는 세 번 모두 통과했다).
 - Pure의 `make check`(ASan 포함), aup와 Vega의 모든 검사가 초록이다(`dde73e4`).
 
 ## 판정