셸 초기화 LF 계약 고정

docs/guides/testing.md

@@ -285,12 +285,13 @@ persisted episode를 UI에 hydrate하지 못하는 제품 결함을 각각 fail-
 SSE·review·G4/G5 `0→1→1`을 연속 통과했지만 fixture 공유와 mobile success-state locator를 각각 검출했다. 보정 후 7차
 clean `aa81af29…`는 same-learner SSE·review·G4/G5 `0→1→1`, 별도 zero-state returned desktop/mobile 4/4, route mock 0,
 exact cleanup 0으로 첫 전체 GREEN receipt를 만들었다. 최신 full GREEN은 clean `64e1b221…`의
-`periodic-learner-e2e-20260812-150209.json`·SHA-256 `a7b2f758…8071`이다. current `94666192…` run은
-disposable DB init health에서 브라우저 전에 FAILED했지만 보호 runtime 접촉 0·exact cleanup 0을 유지했다.
-당시 cleanup 전에 DB/API 로그를 보존하지 않아 exact 원인은 미확정이다. runner는 이제 실패 시 cleanup 전에
-`compose ps`와 db/api log tail을 수집하고 secret·email·UUID·민감 query를 제거한 뒤 raw SHA와 함께 receipt에 결속한다.
-contract 14/14를 통과했다. hourly heartbeat는 최신 GREEN이 6시간 이상 오래됐거나 material milestone이 바뀔 때만
-preflight 뒤 full runner를 최대 1회 실행하며, 실패 시 같은 heartbeat에서 재시도하지 않는다.
+`periodic-learner-e2e-20260812-150209.json`·SHA-256 `a7b2f758…8071`이다. `94666192…` run은 disposable DB
+init health에서 브라우저 전에 FAILED했고, 진단 보강 commit `f97e7fad…`의 single run도 같은 단계에서 멈췄다.
+두 번째 receipt `periodic-learner-e2e-20260812-163742.json`·SHA-256 `ad403712…d840f`의 cleanup 전 로그는
+detached checkout의 `infra/db/init/99_app_role.sh`가 CRLF라 `/usr/bin/env: ‘bash\r’: No such file or directory`로
+exit 127이 난 것을 확정했다. 두 실행 모두 보호 runtime 접촉 0·exact cleanup 0이다. Windows `core.autocrlf=true`
+환경에서도 shell entrypoint를 LF로 checkout하도록 `.gitattributes`에 `*.sh text eol=lf`를 둔다. hourly heartbeat는
+동일 장애가 두 번 반복되면 같은 heartbeat에서 재실행하지 않고, 새 clean commit/worktree에서 CR 0을 먼저 확인한다.
 
 - **병렬 시나리오**: 166 tests (desktop 83 + mobile 83)
 - **`@single-run` 직렬 시나리오**: 49 tests (DB 영속화·세션 MVP·음성 성공경로·인증 시각 테마·회기말 평가 저장·교수자 명시 재평가 저장·교수자 턴 재평가 저장·교수자 UI 평가 재시도·교수자 사용자별 분석·source pack sync·이론모드 저장·동의 철회 후 voice 차단·브라우저 stream PII 마스킹·음성 transcript 저장 실패 UI 표면화 등)