@ihabdevteam/core 0.265.0 → 0.267.0

package/CHANGELOG.md

@@ -7,6 +7,86 @@ All notable changes to this project will be documented in this file.
 > 적은 글이라, 지금 이름으로 고쳐 놓으면 그 시절에 그 이름으로 받은 사람이
 > 제 이야기를 못 찾는다.
 
+## 0.267.0
+
+### 뜸이 **앱까지 닿지 않았다** — `TrainingStepListen` 이 가운데에서 끊었다 (말귀 실측)
+
+(74) 로 `leadInMs` · `tailMs` 를 재생기에 더해 0.266.0 으로 냈는데, 앱은 임시 자를 못 걷었다.
+**앱은 재생기를 직접 세우지 않는다** — 훈련 러너 여섯이 전부 `TrainingPagePopup.ListenStep`
+으로 짓고, 그 길은 `ListenStep`(`...rest` 로 다 흘린다) → `TrainingStepListen` →
+`TrainingStepAudioPlayer` 다. 끊긴 곳은 **가운데 하나**였다.
+
+`TrainingStepListenProps` 에 둘을 더하고 그대로 넘긴다. 기본 0 이라 안 주면 전과 같다.
+
+**글로 적지 않고 센다** — `test/trainingStepListenForwards.test.ts` 가 재생기 프롭 가운데
+`TrainingStepListen` 이 **스스로 정하는 것**(`ttsText`·`btnLabel`·`disabled`·`className` 등,
+까닭을 한 줄씩 적었다)을 뺀 나머지가 전부 지나가는지 센다. 재생기에 프롭을 새로 더하면
+그 이름을 대며 빨개진다. 안 넘기면 실제로 빨개지는지 확인했다.
+
+### 잇따라 나는 소리 사이는 **뒤 뜸 + 앞 뜸**이다
+
+`ended` → 뒤 뜸 → 다음 소리 실어 `play()` 앞에 앞 뜸, 차례가 그렇다. 앞뒤 1000ms 면
+소리 사이가 **2000ms** 다(같은지 다른지 맞히기의 1 → 2, 듣고 순서대로 기억하기의 세 소리).
+
+### 기본값은 **0 으로 둔다**
+
+말귀 실측: 사용자가 화면에서 들어 보며 300 → 500 → 1000 으로 세 번 올려 **앞 1000 · 뒤 1000**
+에서 멈췄고, 까닭도 섞여 있다 — 문장 음원은 이미 앞 1500ms · 뒤 870ms 를 갖고 있어서
+(`se_training_resources/LIN_D/C19015.mp3` 8177ms 중) 단어에 앞뒤 1000ms 를 주면 문장과 비슷한
+결이 된다. 쓸 만한 값이다.
+
+그래도 **코어 기본값은 0 이다.** 0 이 아닌 기본은 이 프롭을 모르는 모든 쓰는 쪽의 소리를
+말없이 늦춘다. 값은 앱이 준다 — `<TrainingPagePopup.ListenStep … leadInMs={1000} tailMs={1000} />`.
+
+## 0.266.0
+
+### 단어 소리에 **앞뒤 뜸**을 둔다 — `TrainingStepAudioPlayer` (말귀 요청 (74))
+
+`leadInMs` · `tailMs` 둘을 더한다(기본 0 — 안 주면 전과 똑같이 돈다).
+
+말귀 실측: 단어 녹음은 앞뒤 무음이 **50~70ms** 뿐이라, 누르는 순간 소리가 터진다.
+그 뜸은 시간선의 일부다 — 파형이 그 구간까지 그리고, 재생바는 **소리가 날 때가
+아니라 뜸부터** 움직인다. 잇따라 틀면 앞 것의 뒤 뜸과 뒤 것의 앞 뜸이 놓여 사이가
+돋을 만큼 된다.
+
+**세 자리를 함께 고쳤다. 하나만 고치면 어긋난 그림이 된다.**
+
+1. **재생 흐름** — `play()` 앞에 앞 뜸, `ended` 뒤에 뒤 뜸을 두고 그다음에 이어 간다.
+   멈추면 기다리던 뜸도 함께 걷는다(`멈춤의도`). 뜸을 기다리는 동안 누름이 바뀌면
+   그 기다림은 버린다 — 재생 의도를 다시 확인하고 돌아온다.
+2. **재생바** — `progressWithPad` 로 **뜸을 포함한 시간선** 위에서 잰다. 전에는
+   `currentTime` 만 따라 뜸 내내 0% 에 붙어 있었다(말귀 실측: 누른 뒤 2029ms 에 `play`,
+   그때까지 채움 0%).
+3. **파형** — `padBarSpans` 로 앞·소리·뒤에 막대를 나눠 준다. 2초 단어에 앞뒤 1초면
+   **4초가 한 폭**이고 소리는 가운데 절반이다.
+
+실측으로 확인했다(2026-10-05, 브라우저 칸 800×600 · 13.09초 문장 · 앞뒤 뜸 1000ms):
+누른 뒤 **1039ms 에 `play`**, 그전 152ms·452ms·756ms 에 재생바는 **0.70% · 2.69% · 4.78%**
+— 소리가 없는 동안에도 움직였다. 뜸이 끝나는 자리(1000/15090 = 6.63%)와 1051ms 의
+실측 6.69% 가 맞는다.
+
+### 파형의 **빈 자리**를 메운다 — 깔개가 없으면 막대를 안 숨긴다
+
+작은 막대를 숨기는(`--hidden`) 결정은 **뒤에 소음 층이 깔려 있다**는 전제 위에 있었다.
+뜻 없는 1px 막대를 지워도 바탕 결이 그 자리를 지키니까. 그런데 소음을 안 주면 그 전제가
+깨지는데 숨기는 쪽만 남아 있었다 — 실측: 소음 없는 13.09초 문장에서 94칸 중
+**앞 0~15 · 뒤 81~93 이 `--hidden`**, 눈에는 파형 양끝이 잘려 보인다. 사용자가 짚은
+"빈 공간"이 이것이다.
+
+깔개가 없을 때만 문장 막대가 바닥값을 진다. 소음을 주면 전과 같이 숨긴다 — 숨기는
+까닭이 사라진 것이 아니라 **그 까닭이 서는 자리가 어디인지**를 적은 것이다.
+소음 막대 자체는 (74) 에서 이미 바닥값을 받았다.
+
+> **고친 시험 하나.** `아주 작은 바는 숨긴다` 가 소음 없이 재고 있었다 — 숨기면 안 되는
+> 자리를 숨기라고 요구하는 꼴이라, 깔개를 주고 재게 고쳤다. 반대쪽은
+> `test/audioWaveNoEmptyBars.test.tsx` 가 센다. 뜻이 아니라 소스 글자를 짚던 시험 둘은
+> 지웠다(이름만 바꿔도 빨개졌다).
+
+### 소리를 만드는 동안 그렇게 말한다 — (75) 이어서
+
+TTS 를 받아 오는 자리의 상태를 `resolving` 에서 `synthesizing` 으로 옮겼다. (75) 에서
+세운 말(`소리를 만들고 있습니다…`)이 실제로 그 자리에 선다.
+
 ## 0.265.0
 
 ### 눌린 소리 고르개가 **손이 없으면 안 보였다** — `TrainingStepAudioPlayer` (말귀 요청 (76))