fix(mindrecord): 추억 공간 헤더가 화면 밖으로 뻗지 않게 한다 (closes 1153)

[Sadturtleman]

Closes #1153

이슈 전제를 정정합니다 — 겹치지 않습니다

이 이슈는 제가 #1131 의 compact baseline 을 눈으로 보고 등록한 것인데, 픽셀을 재 보니 겹침이 아닙니다. memorySpaceScreenErrorCompactScreenshot(360×800dp / 720×1600px)을 디코드해 행별 픽셀 런으로 측정했습니다.

요소	x (px)	dp
「돌아가기」 알약	48..243	24.0 .. 121.5
MEMORY SPACE	303..504	151.5 .. 252.0
부제	277..529	138.5 .. 264.5

알약 우측 끝 121.5dp, 부제 좌측 138.5dp — 17dp 여유. 원인 추정도 틀렸습니다. 헤더는 Box 오버레이가 아니라 이미 Row 라(MemorySpaceHeader.kt:38) 형제끼리 겹칠 수 없습니다.

실제 결함 — 우측 여백이 0 이다

크기 축만으로는 안 드러나고 글자 배율과 곱해져야 나옵니다. 360dp × fontScale 1.5 로 렌더해 측정했습니다.

	기본 배율	1.5배
알약 우측 끝	121.5dp	146.5dp
부제 우측 끝	264.5dp	356.5dp
남는 우측 여백	95.5dp	1.5dp

부제가 화면 오른쪽 끝(360dp)에 닿습니다. 한 글자만 길어지거나 배율이 한 단계 더 오르면 잘립니다.

원인 둘:

1. end 패딩이 없다 — padding(top = 24.dp, start = 24.dp). 좌측만 24dp, 우측 0.
2. 제목 Column 에 weight 가 없다 — 자기 내용 폭을 그대로 요구해, 폭이 모자라도 줄바꿈하지 않고 계속 뻗습니다.

변경

• end = 24.dp 추가
• 제목 Column 에 weight(1f) — 남은 폭이 상한이 되어 그 안에서 접히고, 이슈가 걱정한 겹침이 구조적으로 도달 불가능해집니다. fix(afternote): 카테고리 탭이 더보기 화살표와 겹치지 않게 (closes 1141) [base: develop] #1163(카테고리 탭)·fix(onboarding): 좁은 화면에서 약관 제목이 「전체보기」 자리를 먹지 않게 (closes 1132) [base: develop] #1162(약관 제목)가 같은 성질을 같은 방식으로 닫았습니다.
• textAlign = TextAlign.Center — Column 의 CenterHorizontally 는 Text 상자를 가운데 놓을 뿐이고, 접힌 줄끼리 맞추는 것은 textAlign 입니다. 없으면 둘째 줄이 왼쪽에 붙습니다(수정 중 실측으로 확인해 함께 고쳤습니다).

결과 (360dp × 1.5배)

	전	후
우측 여백	1.5dp	26.5dp
부제	한 줄로 화면 끝까지	두 줄로 접힘
접힌 두 줄 중심	—	498px · 499px (일치)

시안 대조

MEMORY SPACE 정본 4327:67706 을 렌더해 확인했습니다. 알약이 좌상단, 제목·부제가 한 행에 나란히 — 구조는 현재 앱과 같습니다. 이슈의 두 번째 제안(부제를 버튼 아래로)은 시안과 어긋나 택하지 않았습니다.

트레이드오프 하나: 시안은 393dp 기준이고 제목 블록이 화면 중앙에 놓입니다. weight 를 주면 블록이 「버튼 오른쪽 남은 폭의 중앙」이 되어 화면 중앙에서 조금 오른쪽으로 갑니다(411dp 기준 4dp). 완전 중앙을 지키려면 우측에도 버튼 폭만큼 비워야 하는데 360dp 에서 제목 슬롯이 과하게 좁아집니다 — 화면 밖으로 나가지 않는 쪽을 택했습니다. 판단이 다르시면 되돌리겠습니다.

감시 — 새 baseline 한 장

memorySpaceScreenCompactLargeFontScreenshot(360dp × 1.5배)을 더합니다. 크기 축(#1131)·배율 축(#1146) 어느 하나만으로는 이 자리가 안 잡힙니다 — 곱해져야 드러나는 결함이라 조합을 따로 고정합니다.

기존 6장은 end 패딩과 정렬 변경으로 모두 갱신됐습니다.

검증

항목	결과
:feature:mindrecord:presentation:ktlintCheck	BUILD SUCCESSFUL
:feature:mindrecord:presentation:testDebugUnitTest	BUILD SUCCESSFUL
:app:assembleDebug	BUILD SUCCESSFUL
docker(linux/amd64) updateScreenshotTest → validateScreenshotTest	BUILD SUCCESSFUL
git merge origin/develop	clean (#1154 머지 뒤 재확인)

실기동은 하지 않았습니다. 이 결함은 «360dp × 글자 1.5배» 조합에서만 나오고 그 조건을 위 baseline 이 그대로 재현하며, 판정 기준이 픽셀 단위 여백이라 실기가 더 얹어 줄 판단이 없습니다.

🧪 QA Metadata

{
  "scope": "covered-by-ci",
  "exclusionReason": "결함이 나오는 조건이 «360dp 폭 × fontScale 1.5» 한 조합뿐이고, 그 조합을 이 PR 이 추가한 screenshot baseline 이 그대로 렌더한다. 판정 기준도 픽셀 단위 우측 여백이라 실기 관찰이 baseline 보다 정밀하지 않다. 실기기 폭·배율을 이 조합으로 맞추는 것 자체가 baseline 이 하는 일과 같다.",
  "evidence": [
    {
      "kind": "ci",
      "ref": "docker(linux/amd64) :feature:mindrecord:presentation:validateScreenshotTest",
      "input": "MemorySpaceContent(statusText = mindrecord_error_memory_space_failed, onRetryClick 있음) 를 device=spec:width=360dp,height=800dp,dpi=320, fontScale=1.5 로 렌더",
      "boundary": "헤더 글자의 최우측 픽셀과 화면 우측 끝(720px) 사이 거리",
      "observation": "수정 전 713px(여백 1.5dp) → 수정 후 666px(여백 26.5dp). validateScreenshotTest BUILD SUCCESSFUL",
      "assertion": "좁은 화면과 글자 확대가 겹쳐도 헤더가 화면 밖으로 뻗지 않는다"
    },
    {
      "kind": "measurement",
      "ref": "memorySpaceScreenErrorCompactScreenshot PNG 픽셀 디코드 (720x1600)",
      "input": "360dp 기본 배율 baseline 의 헤더 밴드를 행별 dark-run 으로 분해",
      "boundary": "「돌아가기」 알약 우측 끝과 부제 좌측 시작의 x 간격",
      "observation": "알약 243px(121.5dp), 부제 277px(138.5dp) — 17dp 여유. 겹침 0",
      "assertion": "이슈가 적은 «겹친다» 는 재현되지 않으며, 실제 결함은 우측 여백 부재다"
    },
    {
      "kind": "screenshot",
      "ref": "Figma MEMORY SPACE 정본 4327:67706",
      "assertion": "알약 좌상단 · 제목/부제 한 행이라는 헤더 구조가 현재 앱과 같아, 부제를 버튼 아래로 내리는 대안은 시안과 어긋난다"
    },
    {
      "kind": "issue",
      "ref": "#1153",
      "assertion": "이슈 전제(겹침)를 실측으로 정정하고 실제 결함(우측 여백 0)을 이 PR 이 닫는다"
    }
  ]
}

CI Test Plan

{
  "androidTest": {
    "mode": "none",
    "reason": "추억 공간 헤더의 compact·large-font 렌더링은 변경된 Compose screenshot baseline으로 직접 검증합니다."
  }
}

[github-actions]

🚧 리뷰 적체 가드 — 이 PR 을 닫습니다

리뷰 응답을 기다리는 PR 이 8건 남아 있습니다.

PR	열린 날	경과	제목
#1262	2026-08-26	1일	ci: 접근성·manifest·PR 위생 자동화
#1261	2026-08-26	1일	test(network): Testcontainers 기반 API wire 계약 검증
#1259	2026-08-26	1일	fix(ci): Develop Validation 호출 권한을 복구한다
#1256	2026-08-26	1일	ci: 무거운 Android QA를 Actions로 이전
#1255	2026-08-26	1일	[ci] #1228 PR 연결 이슈를 필수화
#1219	2026-08-26	1일	[fix] #1127 동일한 에디터 검증 오류도 다시 안내
#1217	2026-08-26	1일	[fix] #1189 merge-order 이슈 참조 파싱 보강
#741	2026-08-05	22일	[chore] #735 Play 출시 런북과 AAB 검증 추가

이 저장소는 리뷰 응답을 기다리는 PR 이 1건이라도 남아 있으면 새 PR 을 열 수 없습니다 (#1136).

각 PR 에 필요한 리뷰는 한 건입니다 — 누구든 먼저 판정을 내면 그 PR 은 모두의 목록에서 빠집니다. 승인 뒤 변경을 다시 볼 의무는 없고, 변경요청도 작성자가 같은 리뷰어에게 재요청한 뒤 반영 커밋을 올린 경우에만 다시 리뷰어의 몫이 됩니다.

되살리는 법

위 리뷰를 끝낸 뒤 이 PR 을 다시 여세요. 브랜치는 지워지지 않았고 커밋도 그대로입니다.

gh pr reopen 1264

리뷰보다 이 PR 이 급하면 review-debt-exempt 라벨을 붙이고 다시 열면 통과합니다.

[github-actions]

🚧 리뷰 적체 가드 — 이 PR 을 닫습니다

리뷰 응답을 기다리는 PR 이 3건 남아 있습니다.

PR	열린 날	경과	제목
#1256	2026-08-26	1일	ci: 무거운 Android QA를 Actions로 이전
#1219	2026-08-26	1일	[fix] #1127 동일한 에디터 검증 오류도 다시 안내
#741	2026-08-05	22일	[chore] #735 Play 출시 런북과 AAB 검증 추가

이 저장소는 리뷰 응답을 기다리는 PR 이 1건이라도 남아 있으면 새 PR 을 열 수 없습니다 (#1136).

각 PR 에 필요한 리뷰는 한 건입니다 — 누구든 먼저 판정을 내면 그 PR 은 모두의 목록에서 빠집니다. 승인 뒤 변경을 다시 볼 의무는 없고, 변경요청도 작성자가 같은 리뷰어에게 재요청한 뒤 반영 커밋을 올린 경우에만 다시 리뷰어의 몫이 됩니다.

되살리는 법

위 리뷰를 끝낸 뒤 이 PR 을 다시 여세요. 브랜치는 지워지지 않았고 커밋도 그대로입니다.

gh pr reopen 1264

리뷰보다 이 PR 이 급하면 review-debt-exempt 라벨을 붙이고 다시 열면 통과합니다.

[github-actions]

❌ Screenshot test fail — baseline 과 CI rendered PNG 차이.

📦 Artifact: https://github.com/Afternote/Afternote-FE/actions/runs/33042229145 (페이지 하단 Artifacts → screenshot-test-results)

🔍 확인 위치 (artifact zip 내부):

• diff PNG: preview/debug/diffs/...
• rendered PNG: preview/debug/rendered/... (CI 환경에서 새로 그린 결과)
• baseline PNG: repo <module>/src/screenshotTestDebug/reference/... (:core:ui · :feature:home:presentation · :feature:receiver:presentation · :feature:onboarding:presentation · :feature:afternote:presentation · :feature:mindrecord:presentation)

📝 조치 가이드:

• 의도된 시각 변경 → docker build -t afternote-screenshot:latest -f Dockerfile.screenshot . 후 docker run --rm -v "$PWD":/workspace -w /workspace afternote-screenshot:latest ./gradlew :<module>:updateScreenshotTest 로 baseline 갱신 + commit/push
• diff 가 anti-aliasing/font 차이로 보이면 docker 환경 변경 여부 (Dockerfile.screenshot) 점검

CI ↔ 로컬 환경 차이는 본 워크플로의 container 단계가 root fix 한다 (README 의 "Compose Preview Screenshot Testing (docker baseline)" 섹션 참조).

[1hyok]

최신 HEAD 1914be2 기준 검토했습니다. 우측 여백과 대형 글자 baseline을 추가해 overflow를 재현·감시한 방향은 좋습니다. 다만 weight(1f)가 제목 축을 정본의 화면 중앙에서 크게 오른쪽으로 옮겨 기본 배율에도 시각 회귀가 생겨 변경 요청합니다. 세부 측정과 수정 요청은 인라인에 남겼습니다.

검증:

• exact-head Ktlint, Lint, Unit Test, Screenshot, CodeQL 등 성공
• Android Managed Device는 라벨이 없어 skipped
• develop/PR compact baseline 및 Figma 정본 4327:67706 대조

[Sadturtleman]

지적이 맞습니다. weight(1f) 는 겹침만 보고 고른 것이라, 잘리지 않던 조건의 시각까지 바꿔 놨습니다. 고쳤습니다.

바꾼 방식 — 먼저 중앙에 놓아 보고, 겹칠 때만 비킨다

SubcomposeLayout 으로 두 단계를 둡니다.

1. 제목 블록을 전체 폭 기준으로 재어 화면 중앙에 놓아 본다 (시안이 그렇게 둡니다)
2. 그 자리가 「돌아가기」와 겹칠 때만, 필요한 만큼만 오른쪽으로 민다

「남은 영역의 가운데」로 옮기는 방식은 택하지 않았습니다 — 겹침은 똑같이 풀리는데 화면 중심에서 더 멀어집니다. 360dp 기본에서 그 방식은 236dp 였고, 지금 방식은 202dp 입니다.

실측 (baseline PNG 픽셀 디코드)

조건	제목 중심	화면 중심 이탈	우측 여백
411dp 기본	270.0dp / 270dp	0.0dp	187dp
360dp 기본	202.0dp / 180dp	22dp	93dp
360dp × 1.5	249.0dp / 180dp	69dp	33.5dp

• 기본 화면(411dp)은 정확히 중앙입니다 — 정본 4327:67706이 393dp 화면 중심에 두는 것과 같은 배치입니다. 이전 버전에서는 여기서도 밀려 있었습니다.
• 360dp 기본은 202dp — 지적하신 develop 값(≈202.5dp)과 같습니다. 그 조건의 시각이 되돌아왔습니다.
• 360dp × 1.5 에서만 비킵니다. 여기서 중앙(≈103dp)에 두면 알약(우측 끝 146.5dp)과 겹칩니다 — 물리적으로 양립하지 않아, 「겹치지 않는 것」을 우선했습니다.

새 baseline 도 이동을 정상값으로 굳히지 않습니다

말씀대로 이전 baseline 들이 밀린 배치를 고정하고 있었습니다. 여섯 장 모두 재생성했고, 위 표가 그 결과입니다 — 411dp 세 장은 중앙 정렬로 돌아왔습니다.

docker(linux/amd64) validateScreenshotTest BUILD SUCCESSFUL, ktlintCheck · testDebugUnitTest · :app:assembleDebug 모두 green 입니다.

남는 한 가지

360dp 기본의 22dp 이탈은 이 PR 이 만든 것이 아니라 develop 그대로입니다. 그 화면에서 제목을 진짜 중앙에 두려면 알약과 겹치므로, 시안이 393dp 기준이라는 점과 함께 별도 판단이 필요해 보입니다. 이 PR 범위로 끌어오지 않았는데, 함께 정하는 편이 낫다고 보시면 이슈로 떼겠습니다.

[Sadturtleman]

지적이 맞습니다. weight(1f) 는 겹침만 보고 고른 것이라, 잘리지 않던 조건의 시각까지 바꿔 놨습니다. 고쳤습니다.

바꾼 방식 — 먼저 중앙에 놓아 보고, 겹칠 때만 비킨다

SubcomposeLayout 으로 두 단계를 둡니다.

1. 제목 블록을 전체 폭 기준으로 재어 화면 중앙에 놓아 본다 (시안이 그렇게 둡니다)
2. 그 자리가 「돌아가기」와 겹칠 때만, 필요한 만큼만 오른쪽으로 민다

「남은 영역의 가운데」로 옮기는 방식은 택하지 않았습니다 — 겹침은 똑같이 풀리는데 화면 중심에서 더 멀어집니다. 360dp 기본에서 그 방식은 236dp 였고, 지금 방식은 202dp 입니다.

실측 (baseline PNG 픽셀 디코드)

조건	제목 중심	화면 중심 이탈	우측 여백
411dp 기본	270.0dp / 270dp	0.0dp	187dp
360dp 기본	202.0dp / 180dp	22dp	93dp
360dp × 1.5	249.0dp / 180dp	69dp	33.5dp

• 기본 화면(411dp)은 정확히 중앙입니다 — 정본 4327:67706이 393dp 화면 중심에 두는 것과 같은 배치입니다. 이전 버전에서는 여기서도 밀려 있었습니다.
• 360dp 기본은 202dp — 지적하신 develop 값(≈202.5dp)과 같습니다. 그 조건의 시각이 되돌아왔습니다.
• 360dp × 1.5 에서만 비킵니다. 여기서 중앙(≈103dp)에 두면 알약(우측 끝 146.5dp)과 겹칩니다 — 물리적으로 양립하지 않아, 「겹치지 않는 것」을 우선했습니다.

새 baseline 도 이동을 정상값으로 굳히지 않습니다

말씀대로 이전 baseline 들이 밀린 배치를 고정하고 있었습니다. 여섯 장 모두 재생성했고, 위 표가 그 결과입니다 — 411dp 세 장은 중앙 정렬로 돌아왔습니다.

docker(linux/amd64) validateScreenshotTest BUILD SUCCESSFUL, ktlintCheck · testDebugUnitTest · :app:assembleDebug 모두 green 입니다.

남는 한 가지

360dp 기본의 22dp 이탈은 이 PR 이 만든 것이 아니라 develop 그대로입니다. 그 화면에서 제목을 진짜 중앙에 두려면 알약과 겹치므로, 시안이 393dp 기준이라는 점과 함께 별도 판단이 필요해 보입니다. 이 PR 범위로 끌어오지 않았는데, 함께 정하는 편이 낫다고 보시면 이슈로 떼겠습니다.

최신 HEAD 6b8793b에서 adaptive 중앙 배치 수정과 360dp·fontScale 1.5 스크린샷을 확인했고, exact-head GMD run 33068139619의 API 30 82/82 및 API 34 1/1이 모두 통과해 기존 변경요청이 더 이상 유효하지 않습니다.

[1hyok]

최신 HEAD 6b8793b 기준으로 재검토했습니다.

기존 중앙 정렬 지적은 중앙 배치를 먼저 시도하고 충돌할 때만 제목 폭을 제한하는 방식으로 해결됐습니다. 360dp × fontScale 1.5 감시 baseline을 포함해 기본 배율의 화면 중앙 정렬과 좁은 화면의 우측 여백을 모두 보존합니다.

미해결 스레드가 없고 Ktlint, Lint, Unit, Screenshot, CodeQL, API 30·34 GMD가 모두 통과했습니다. correctness, security, performance, test coverage에서 추가 차단 사항을 찾지 못했습니다.