Suggestions surfaced during PR #166 review that were deferred to backlog.
1. draw_status_bar — eliminate redundant .to_string() allocations
Span::raw and Span::styled accept T: Into<Cow<'_, str>>, which &str satisfies directly. The calls to .to_string() allocate needlessly. (The separator-bug fix landed in PR #166 already removed the slug_text allocation; verify project_name is also clean.)
2. draw_status_bar — Style::default().dim() repeated at call sites
The dim style appears multiple times. Extract to a local binding at the top of the function (let dim = Style::default().dim();). This was partially addressed in the PR #166 separator fix (the sep span now uses dim), but verify all remaining call sites are consolidated.
3. draw_help_overlay — document that it must receive frame.area(), not content_area
The function doc comment says it renders on top of all content but doesn't capture the fragile constraint flagged in S05-SUMMARY.md: passing content_area instead of frame.area() would shift the centering up by one row and clip on small terminals. A note was added in PR #166 but may need strengthening if the call site is ever refactored.
Suggested inline note (already added in PR #166 — confirm it survived):
/// NOTE: must be called with `frame.area()` (full terminal rect), *not* with
/// `content_area`. The popup uses full-screen geometry to center correctly …
4. handle_event help-overlay guard — clarify that q is also consumed
The guard comment says "all other keys are no-ops" but doesn't call out the most surprising consequence: q does not quit while the overlay is open. A parenthetical would make this explicit for future maintainers debugging unexpected quit behaviour.
// When help overlay is visible, only ? and Esc dismiss it; all other keys —
// including q (quit) — are consumed as no-ops so nothing fires through the
// overlay by accident.
5. draw_status_bar doc comment — document dim-styling contract
The current doc describes the layout but not which spans are styled. project_name renders at default brightness; everything else is dim. Add one line:
/// `project_name` renders at default brightness; the separators, `cycle_slug`,
/// and key hints are all rendered dim.
All of these are cosmetic / doc improvements. No behaviour change required. Safe to batch into the next assay-tui polish pass.
Suggestions surfaced during PR #166 review that were deferred to backlog.
1.
draw_status_bar— eliminate redundant.to_string()allocationsSpan::rawandSpan::styledacceptT: Into<Cow<'_, str>>, which&strsatisfies directly. The calls to.to_string()allocate needlessly. (The separator-bug fix landed in PR #166 already removed theslug_textallocation; verifyproject_nameis also clean.)2.
draw_status_bar—Style::default().dim()repeated at call sitesThe
dimstyle appears multiple times. Extract to a local binding at the top of the function (let dim = Style::default().dim();). This was partially addressed in the PR #166 separator fix (thesepspan now usesdim), but verify all remaining call sites are consolidated.3.
draw_help_overlay— document that it must receiveframe.area(), notcontent_areaThe function doc comment says it renders on top of all content but doesn't capture the fragile constraint flagged in
S05-SUMMARY.md: passingcontent_areainstead offrame.area()would shift the centering up by one row and clip on small terminals. A note was added in PR #166 but may need strengthening if the call site is ever refactored.Suggested inline note (already added in PR #166 — confirm it survived):
4.
handle_eventhelp-overlay guard — clarify thatqis also consumedThe guard comment says "all other keys are no-ops" but doesn't call out the most surprising consequence:
qdoes not quit while the overlay is open. A parenthetical would make this explicit for future maintainers debugging unexpected quit behaviour.5.
draw_status_bardoc comment — document dim-styling contractThe current doc describes the layout but not which spans are styled.
project_namerenders at default brightness; everything else is dim. Add one line:All of these are cosmetic / doc improvements. No behaviour change required. Safe to batch into the next assay-tui polish pass.