fix(kebab-tui): p9-fb-24 — TUI status/key bar + Library 컬럼 헤더 + Ask/Inspect PgUp/PgDn #97
Reference in New Issue
Block a user
Delete Branch "fix/p9-fb-24-tui-affordances"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
요약
도그푸딩 피드백 3 건을 단일 PR 로 통합:
PAGE_STEP = 10, Inspect 의 기존 동작과 통일).주요 변경
bottom 영역 2-row 분할
render_status_bar신규:kebab v<version> │ <pane> │ <docs> docs │ [conv_<8hex>… │ ]<dynamic_status>.render_key_hints(기존render_footerrename, body 무수정).render_ingest_status의 dedicated row 가 status bar 의 dynamic slot 으로 흡수. priority cascade: streaming (Ask) → searching (Search) → indexing (Ingest) → idle.current_question.is_some() || !turns.is_empty()일 때만 conversation id 8자 prefix 표시.PAGE_STEP상수 일원화crates/kebab-tui/src/pager.rs::PAGE_STEP: u16 = 10(pub(crate)).KeyCode::PageUp/PageDown신규 (mode 무관).j/k와 동일하게follow_tail = false로 freeze.+/-10literal 을pager::PAGE_STEP으로 교체. 동작 동일.Library 헤더 행
format_doc_header(title_w)신규 —format_doc_row와 동일 width math (display-width 인지, Hangul/CJK 안전).render_doc_list가 block inner 영역을Layout::Length(1)(헤더) +Min(0)(List) 로 분할.cheatsheet popup
테스트
Spec contract impact
참조 문서
Known limitation (deferred)
회차 1 — 11-task TDD 분해 깔끔하고 단계별 verify (test/clippy/build) 가 일관되게 통과. cursor 모델 byte-position (p9-fb-22) 위에 status bar + page scroll + Library 헤더 추가가 회귀 표면을 잘 분리해서 잡혀 있고, ingest dedicated row 의 status bar dynamic slot 흡수도 cascade priority 명확하게 풀려 있음.
actionable 4건:
tests/inspect.rs— 신규page_down_scrolls_by_ten_in_inspect+page_up_rewinds_by_ten_saturating_in_inspect가 기존page_keys_scroll_by_ten와 중복 커버리지. plan 작성 시점에 기존 테스트를 못 본 듯. 33 줄 정리 필요.tasks/HOTFIXES.md테스트 카운트기존 720+→기존 695(실제 cargo --workspace 716 = 21 신규 + 695 기존).tasks/p9/p9-fb-24-tui-affordances.mdspec 파일에도 박혀 있음.render_status_bar의 magic string" │ "(sep) — 상수 추출 권장 (선택).@@ -331,0 +317,4 @@let sep = " │ ";let mut line_text = format!("kebab v{}{sep}{}{sep}{} docs{sep}",magic string
" │ "(sep) 가render_status_bar본문에 inline. 한 곳뿐이라 critical 은 아니지만 후속 PR 에서 layout 손볼 때 grep 안 됨.옵션:
const STATUS_SEPARATOR: &str = " │ ";모듈 상단 ���출.kebab v0.1.0 │ <pane>표기와 sync 보장 — 본문이 짧고 가독성 OK.선택 사항. 회차 2 에서 추출해도 좋고 acceptable as-is 로 닫아도 무방.
@@ -188,6 +188,39 @@ fn page_keys_scroll_by_ten() {assert_eq!(app.inspect.as_ref().unwrap().scroll, 0);}/// p9-fb-24 task 2: PageDown advances scroll by `PAGE_STEP` (= 10).중복 테스트. 기존
page_keys_scroll_by_ten(line 188 위) 이 이미 PgDn(+10) + PgUp(-10) + saturating-at-0 셋 다 검증. 신규page_down_scrolls_by_ten_in_inspect+page_up_rewinds_by_ten_saturating_in_inspect는 같은 동작을 한 번 더 어설션. 둘 중 하나만 남기는 게 깔끔 — plan 이 신규 작성을 명시했지만 pre-existing 테스트가 plan 작성 시점에 보이지 않았던 것으로 보임.권장: 신규 두 테스트 삭제 + 기존
page_keys_scroll_by_ten의 docstring 에p9-fb-24: PAGE_STEP 상수 회귀 핀한 줄 추가. 신규 테스트와 동일 의미가 됨. 또는 기존을 삭제하고 신규로 교체. 어느 쪽이든 33 줄 dead test 제거.@@ -17,0 +20,4 @@**Live binding 변경**:- bottom 영역을 2 row 로 분할. 윗줄 = status bar (`kebab v<version> │ <pane> │ <docs> docs │ <state>`), 아랫줄 = key hint bar (기존 `footer_hints` 그대로). p9-fb-13 follow-up 의 single-row footer 와 충돌 — frozen spec 텍스트 보존, 본 항목이 live source of truth.테스트 카운트 부정확. 본문에
기존 720+ 워크스페이스 테스트 무수정 통과인데 실제 cargo test --workspace -j 1 결과는 716 passed (= 신규 21 + 기존 695). plan 작성 시점의 추정치720+가 그대로 박힘.기존 695 워크스페이스 테스트또는기존 695개 워크스페이스 테스트 (cargo test --workspace -j 1 기준 716 passed)로 정정 권장. 영속 기록이라 정확한 카운트가 의미 있음.@@ -0,0 +35,4 @@## Tests- status_bar 통합 10 (version / pane / docs / idle / streaming / searching / ingest absorb / Ask conv_id present / Ask conv_id absent / outside Ask).- library 통합 1 (헤더 row visible).spec frozen 으로 박히기 전 카운트 정정.
기존 720+ 테스트 무수정 통과→기존 695개 테스트 무수정 통과. HOTFIXES 와 같은 출처 문제.회차 2 — 회차 1 의 4 건 모두 수렴.
기존 720+→기존 695개 (716 passed)정확.STATUS_SEPARATOR상수 추출 + docstring sync 코멘트.11-task TDD 분해의 결과로 회귀 표면 잘 분리됨. cursor model byte-position (p9-fb-22) + follow_tail (p9-fb-22) 위에 status bar dynamic cascade + page scroll + Library 헤더가 깔끔하게 얹힘. ingest dedicated row 의 status bar 흡수도 priority cascade 로 단일 source.
716 워크스페이스 테스트 통과 + clippy clean + backwards-compat 695개 그대로 통과 — 회귀 위험 없음.
머지 동의.
@@ -331,0 +291,4 @@/// p9-fb-24: separator between status bar fragments. Two spaces +/// box-drawings light vertical (U+2502) + two spaces. Single source/// — the docstring of `render_status_bar` references the rendered/// shape, so any change here MUST update that docstring too.STATUS_SEPARATOR추출 + docstring sync 코멘트 ("any change here MUST update that docstring too") 가 single-source 강제하는 좋은 패턴. magic string 이 grep 가능해지고 후속 PR 의 layout 손볼 때 single edit point 확보.@@ -183,1 +188,4 @@assert_eq!(app.inspect.as_ref().unwrap().scroll, 10);}/// p9-fb-24 task 2: PageUp rewinds scroll by `PAGE_STEP`, saturating회차 1 의 "중복 page_keys_scroll_by_ten 삭제 + 신규 두 개 유지" 깔끔하게 수렴. 신규
page_up_rewinds_by_ten_saturating_in_inspect가 25→15 이어서 3→0 두 saturating boundary 를 한 테스트에서 명시적으로 체크하는 게 기존보다 정밀도 ↑. PAGE_STEP regression 핀의 의도와 정확히 부합.