GTK regressions from #515: editor breadcrumbs broken + explorer treeview icons don't use Nerd Fonts (converge on quadraui; fix quadraui gaps first)

[JDonaghy]

Summary

Dogfooding #515 (editor-group tab drag-drop → quadraui) surfaced two GTK-backend regressions in the editor. Both are the same class of problem the Platform-Neutral milestone exists to eliminate: GTK render paths that diverge from the shared / quadraui-provided path the TUI uses.

As ever, the goal is elimination of backend-specific logic in vimcode. For each regression, the fix is to converge GTK onto the shared/quadraui path — and if quadraui has the gap (a missing or regressed primitive), fix quadraui FIRST (pull ~/src/quadraui, land the quadraui change), then adopt it in vimcode. Do not paper over either regression with GTK-only patch code.

Parent: Platform-Neutral milestone (same as #515). Surfaced by: #515.

---

Regression 1 — GTK editor breadcrumbs are broken

The breadcrumb bar (file path + symbol hierarchy, below the tab bar; settings.breadcrumbs, src/core/settings.rs:281-283) is broken in the GTK editor.

This is a shared-model feature that both backends already render from screen.breadcrumbs:

Backend	Path
Shared model	screen.breadcrumbs
GTK draw loop	src/gtk/draw.rs:330-341 → draw_breadcrumb_bar (src/gtk/draw.rs:1226-1234), which draws via quadraui::ScreenLayout::draw()
TUI draw loop	src/tui_main/render_impl.rs:338-400 → draw_breadcrumb_bar (src/tui_main/render_impl.rs:1392-1400), via the D6 StatusBar pipeline

Because GTK already routes breadcrumbs through quadraui (ScreenLayout::draw()), a GTK-only break most likely means a quadraui-side regression/gap in the breadcrumb (ScreenLayout / StatusBar) primitive on the GTK path — or a divergence between what the GTK adapter feeds ScreenLayout::draw() and what the TUI feeds the D6 StatusBar pipeline.

Fix approach:

1. Reproduce and localize: is the break in the quadraui ScreenLayout::draw() breadcrumb primitive (GTK path), or in the vimcode GTK adapter that builds the bar model?
2. If it's a quadraui primitive gap/regression → fix it in quadraui first, file/reference the quadraui issue, pull ~/src/quadraui, then let vimcode consume it.
3. Ensure GTK and TUI render breadcrumbs from the same shared model + quadraui primitive with no backend-specific breadcrumb layout/geometry logic left in src/gtk/.

---

Regression 2 — Explorer treeview icons don't use Nerd Fonts on GTK

In the Explorer sidebar treeview, file/folder icons render the plain-Unicode/ASCII fallback instead of the Nerd Font glyph on the GTK backend.

The icon system is already platform-neutral and Nerd-Font-aware:

• src/icons.rs — every Icon carries a Nerd Font glyph + a fallback (Icon::new("\u{e7a8}", "R") etc.; explorer icons at src/icons.rs:54-85: EXPLORER, FOLDER, FOLDER_OPEN, FILE_RUST, …).
• Icon::s() (src/icons.rs:38) picks glyph-vs-fallback off the global USE_NERD_FONTS flag; set at startup via set_nerd_fonts(bool) (src/icons.rs:16).
• Explorer state/logic is already shared — src/gtk/explorer.rs is a 4-line stub; the logic lives on the engine (explorer_ops.rs).

So the GTK treeview is falling to the fallback for one of these reasons — determine which:

1. GTK never calls set_nerd_fonts(true) (or sets it false) at startup, unlike the TUI path → the shared Icon::s() returns fallbacks. (Check the GTK app init vs the TUI init.)
2. The GTK font stack lacks a Nerd Font, so glyphs would render as tofu — if that's the intent behind the fallback, the detection/selection needs to run on GTK too (cf. detect_nerd_font_windows, src/icons.rs:169-204).
3. The Explorer tree is drawn through a quadraui tree/list primitive that doesn't carry or gate the Nerd-Font icon (drops the glyph, or renders the fallback) → quadraui gap → fix quadraui first, then adopt.

Fix approach: trace the GTK explorer icon path end-to-end; make GTK honor the shared Nerd-Font-aware icons.rs path exactly as the TUI does. If the icon is being dropped inside a quadraui treeview/list primitive, fill that gap in quadraui first (pull ~/src/quadraui) rather than adding a GTK-only icon shim.

---

Acceptance criteria

• GTK editor breadcrumbs render correctly again, from the shared screen.breadcrumbs model via the same quadraui primitive as the TUI — no new backend-specific breadcrumb layout logic in src/gtk/.
• Explorer treeview icons render Nerd Font glyphs on GTK (matching the TUI), via the shared src/icons.rs path — no GTK-only icon shim.
• Any quadraui gap uncovered (breadcrumb ScreenLayout::draw() regression; treeview/list primitive dropping the icon) is fixed in quadraui first, referenced here, with ~/src/quadraui pulled; the vimcode change then consumes it. Name the quadraui PR/branch in the briefing (vimcode builds against ../../quadraui/quadraui).
• Black-box coverage per vimcode CLAUDE.md: a test that drives the GTK render path and asserts breadcrumb presence + Nerd-Font glyph selection in the explorer tree (or the platform-neutral equivalent asserting the shared model/icon selection both backends consume).

Notes

• Build coupling: vimcode builds against ~/src/quadraui by relative path. If the fix needs an unmerged quadraui branch, the briefing must name it and the worker must git -C ~/src/quadraui checkout <branch> before cargo build and restore the original branch after (see vimcode/coord CLAUDE.md).
• Repro context: surfaced while working Consolidate editor-group tab drag-drop onto quadraui drop primitives (full TabGroupController adoption deferred — see quadraui#395) #515 on develop.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: —

Summary

Fixed both #547 regressions (GTK breadcrumbs + explorer Nerd Font icons), both root-caused to dead wiring from the #540 Relm4->ShellApp migration, not quadraui gaps. Added shared render::breadcrumb_draw_targets()/sync_nerd_fonts() helpers used by both GTK and TUI, deduping TUI's 3x-duplicated skip-check and its now-provably-redundant single-group tab-bar-hidden special case. 2 new render.rs unit tests. cargo build (default+gui and --no-default-features), cargo test --no-default-features (all pass, 2127+ tests), cargo clippy -D warnings, and cargo fmt all clean for my diff. Pre-existing, unrelated clippy failure (type_complexity on App::cached_tab_slots_abs, gtk/mod.rs:563) and pre-existing snake_case test-name warnings in tests.rs/git.rs/new_vim_features.rs predate this branch and are out of scope. Recorded durable findings + 3 follow-up dedup issues to file via coord context add.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: 43m 35s

[JDonaghy]

Coordinator: Assignment Complete

Machine: elitebook
Status: done
Exit code: 0
Duration: —

Summary

Smoke passed: GTK breadcrumbs render + explorer Nerd Font icons confirmed working, TUI sanity OK; found separate pre-existing GTK bug (missing draw_needed.set(true) in breadcrumb click Hit(idx) branch, src/gtk/mod.rs:3607-3611, dates to #366) to file as follow-up, not blocking #547

[JDonaghy]

Coordinator: Assignment Complete

Machine: elitebook
Status: done
Exit code: 0
Duration: 38s

[JDonaghy]

Coordinator: Assignment Complete

Machine: elitebook
Status: done
Exit code: 0
Duration: —

Summary

Fix logic verified correct (traced into quadraui's draw_tree/status_bar); requesting changes to document the quadraui#391 dependency and tighten test coverage on the two new functions

Verdict: request-changes

Review findings

Review: vimcode #547 — GTK breadcrumbs + Nerd Font icons

Branch: issue-547-gtk-regressions-from-515-editor-breadcru @ a2bb4b8

Summary of verification performed

I did not run cargo build/test/clippy (per review instructions — that's the
separate smoke gate's job). Instead I traced the actual data/control flow through
both the vimcode diff and the quadraui crate it depends on (~/src/quadraui) to
verify the two fixes are logically correct:

• Breadcrumbs (regression 1): Confirmed bc.bounds (computed in
  build_screen_layout, unchanged by this diff) is already in the caller's
  coordinate space — absolute pixels for GTK (window_rects built from
  layout.main_content_bounds), content-area-relative row units for TUI
  (content_bounds = WindowRect::new(0.0, 0.0, ...) in build_screen_for_tui).
  The new breadcrumb_draw_targets(screen, terminal_maximized, line_height, origin_offset) therefore correctly uses (0.0, 0.0) for GTK and
  (editor_area.x, editor_area.y) for TUI. Verified the hidden-tab-bar y-shift
  claim in the new test against Engine::adjust_group_rects_for_hidden_tabs
  (src/core/engine/accessors.rs:37) — the arithmetic checks out (tab row
  shown → breadcrumb at row 1; hidden → row 0, matching tab_row_h being
  subtracted from the window rect).
• Nerd fonts (regression 2): Traced into quadraui::gtk::tree::draw_tree
  (~/src/quadraui/quadraui/src/gtk/tree.rs:180) and confirmed it does
  if nerd_fonts_enabled { icon.glyph } else { icon.fallback } — i.e. the
  GTK TreeView primitive really does gate icon selection on
  GtkBackend.nerd_fonts_enabled, which was stuck at its false default
  because the only prior setter call (Msg::CacheFontMetrics) is dead code
  post-#448-C: Flip GTK main loop from Relm4 to ShellApp runner; delete Relm4 scaffolding (sub-task 3/3 of #448) #540, exactly as the issue/commit describe. render::sync_nerd_fonts()
  being called from ShellApp::setup() and every render_content() frame is
  the correct fix.

Both fixes are logically sound and match the "shared helper in render.rs, thin
per-backend wiring" pattern the Platform-Neutrality Rule requires — no new
backend-specific layout/geometry logic was added to src/gtk/. This is a good
example of the rule being followed correctly.

Findings

1. (Should-fix — process/documentation) Undocumented quadraui dependency

render::sync_nerd_fonts() calls b.set_nerd_fonts(...) on b: &mut dyn quadraui::Backend — a trait-object call. This only compiles if
Backend::set_nerd_fonts is a trait method. On the local ~/src/quadraui
checkout (branch develop @ b6421ae, the tip before fetching), it is
not — set_nerd_fonts is only an inherent method on the concrete
GtkBackend/TuiBackend structs. I confirmed the trait promotion landed
separately in quadraui as 9613f9c "feat(quadraui): promote set_nerd_fonts to Backend trait (#391)", dated 2026-06-29 — two days before this vimcode
commit (2026-07-01) — and that it's on origin/develop (needs git pull to
reach a stale local checkout, exactly the scenario vimcode's own CLAUDE.md
"stale quadraui checkout" section anticipates).

So process-wise this is fine (quadraui-first did happen), but the PR/commit
message never names this dependency, contrary to the issue's explicit
acceptance criterion: "Any quadraui gap uncovered ... is fixed in quadraui
first, referenced here ... Name the quadraui PR/branch in the briefing." As
written, a future reader hitting a build break here (no method named set_nerd_fonts found for &mut dyn Backend) has to reverse-engineer that it's
a stale-quadraui issue rather than a vimcode bug — please add a line to the
commit message / PR body naming quadraui commit 9613f9c / the
issue-391-add-backend-set-nerd-fonts-to-trait-so-s branch, and confirm
whatever machine runs the Test-stage smoke build has quadraui develop pulled
past that commit.

2. (Suggestion — test coverage gap vs. acceptance criteria)

Neither new test actually exercises the two new pub functions that are the
substance of this fix:

• test_single_group_breadcrumb_bounds_reflect_hidden_tab_bar asserts
  layout.breadcrumbs[0].bounds.y via build_screen_layout directly — it
  never calls breadcrumb_draw_targets. It's a good regression pin for the
  pre-existing bounds computation the refactor now trusts, but it doesn't
  cover breadcrumb_draw_targets's own logic: the terminal_maximized early
  return, the segments.is_empty() filter, or the origin_offset addition
  arithmetic.
• test_explorer_tree_rows_carry_glyph_and_fallback_icons asserts
  build_explorer_tree_rows (pre-existing, unchanged by this diff) produces
  distinct glyph/fallback pairs — it doesn't touch sync_nerd_fonts at all.

Given the issue's acceptance criteria explicitly asked for "a test that ...
asserts breadcrumb presence + Nerd-Font glyph selection ... or the
platform-neutral equivalent asserting the shared model/icon selection both
backends consume," consider adding a direct unit test for
breadcrumb_draw_targets (pure function, trivially testable: build a
ScreenLayout via build_screen_layout, then call
breadcrumb_draw_targets(&screen, false, lh, (10.0, 20.0)) and assert
rect.x/y reflect the offset, and that terminal_maximized: true yields an
empty Vec). sync_nerd_fonts itself is a one-line wrapper so may not need a
dedicated test, but the above would close the gap between what's asked for and
what's covered.

3. (Nit, non-blocking) GTK/TUI asymmetry re-introduced within the "shared" helper

src/gtk/mod.rs ~7601-7612 draws every target from breadcrumb_draw_targets
unconditionally, while both TUI call sites (src/tui_main/render_impl.rs:351
and :401) guard with if t.rect.width > 0.0. That guard exists in TUI
because the pre-existing code had it (preserved correctly by the refactor);
GTK's call site is brand new and never had it, so it was simply omitted.

I checked whether this can matter: bc.bounds.width can be 0.0 in the
min_x == f64::MAX fallback branch in build_screen_layout (a group with no
matching window rects — e.g. a transient state during group-tree mutation).
Traced into quadraui::gtk::status_bar::draw_status_bar — a zero-width rect
just clips a cr.rectangle(x, y, 0, line_height) region, so it's a visual
no-op rather than a crash. Not a functional bug, but it's exactly the kind of
per-backend divergence the shared-helper refactor exists to eliminate — worth
folding the width > 0.0 filter into breadcrumb_draw_targets itself so
neither backend has to remember it separately.

4. (Observation only — pre-existing, out of scope for #547)

While tracing the icon-selection path I noticed build_explorer_tree_rows
(src/render.rs:7221-7229, not touched by this diff) resolves the FILE
icon glyph via vimcode's own icons::file_icon(ext) (which already applies
vimcode's global icons::USE_NERD_FONTS flag internally via Icon::s()), then
wraps it as QIcon::new(glyph, ".".to_string()) — a hardcoded "." fallback.
Since quadraui::gtk::tree::draw_tree also gates on the backend's
nerd_fonts_enabled (picking icon.fallback when off), toggling nerd fonts
off at runtime will make every file row show a bare "." rather than its
per-type ASCII fallback letter (e.g. "R" for Rust). This is a latent,
pre-existing quirk unrelated to what #547 fixes (which is specifically the
nerd_fonts_enabled flag being stuck false, not this double-resolution
issue), but it does mean the new test's doc comment — "selection between them
is entirely the backend's job... not build_explorer_tree_rows's" — isn't
actually true for file rows (only for folder rows, which pass the raw
icons::FOLDER.nerd/.fallback pair through). Worth a follow-up issue, not a
blocker here.

Checklist

• Tests added/updated: yes, but see v0.3.0: TUI-only binary (vcd) #2 above — coverage is adjacent to, not
  directly on, the two new functions.
• Scope: stayed within the two regressions described in GTK regressions from #515: editor breadcrumbs broken + explorer treeview icons don't use Nerd Fonts (converge on quadraui; fix quadraui gaps first) #547; no scope creep.
• Security: none — pure rendering/layout code, no I/O or external input.
• Follows existing patterns: yes — matches the QSL::new() /
  Surface::StatusBar / frame.draw(backend) pattern used elsewhere in the
  same function for tab bars and the global status bar.
• Platform-neutral: yes, and a good example of it — both backends now go
  through the same render::breadcrumb_draw_targets /
  render::sync_nerd_fonts helpers; no new per-backend geometry/layout logic
  was added to src/gtk/.

Verdict

Requesting changes — primarily to close the acceptance-criteria gaps: name the
quadraui commit/branch this depends on (finding #1) and, ideally, add a direct
test of breadcrumb_draw_targets (finding #2). The core fix logic itself is
correct; #3 and #4 are optional/non-blocking nits worth a mention to the fix
worker but not required before merge.

[JDonaghy]

Coordinator: Assignment Failed

Machine: elitebook
Status: failed
Exit code: 0
Duration: 12m 20s

Error

Interactive review session exited without producing a verdict (session may have failed to start). Re-dispatch a fresh review via 'Start review'.

[JDonaghy]

Coordinator: Assignment Complete

Machine: elitebook
Status: done
Exit code: 0
Duration: —

Summary

Verdict: request-changes

Review findings

Branch: issue-547-gtk-regressions-from-515-editor-breadcru @ a2bb4b8

I did not run cargo build/test/clippy (per review instructions — that's the
separate smoke gate's job). Instead I traced the actual data/control flow through
both the vimcode diff and the quadraui crate it depends on (~/src/quadraui) to
verify the two fixes are logically correct:

• Breadcrumbs (regression 1): Confirmed bc.bounds (computed in
  build_screen_layout, unchanged by this diff) is already in the caller's
  coordinate space — absolute pixels for GTK (window_rects built from
  layout.main_content_bounds), content-area-relative row units for TUI
  (content_bounds = WindowRect::new(0.0, 0.0, ...) in build_screen_for_tui).
  The new breadcrumb_draw_targets(screen, terminal_maximized, line_height, origin_offset) therefore correctly uses (0.0, 0.0) for GTK and
  (editor_area.x, editor_area.y) for TUI. Verified the hidden-tab-bar y-shift
  claim in the new test against Engine::adjust_group_rects_for_hidden_tabs
  (src/core/engine/accessors.rs:37) — the arithmetic checks out (tab row
  shown → breadcrumb at row 1; hidden → row 0, matching tab_row_h being
  subtracted from the window rect).
• Nerd fonts (regression 2): Traced into quadraui::gtk::tree::draw_tree
  (~/src/quadraui/quadraui/src/gtk/tree.rs:180) and confirmed it does
  if nerd_fonts_enabled { icon.glyph } else { icon.fallback } — i.e. the
  GTK TreeView primitive really does gate icon selection on
  GtkBackend.nerd_fonts_enabled, which was stuck at its false default
  because the only prior setter call (Msg::CacheFontMetrics) is dead code
  post-#448-C: Flip GTK main loop from Relm4 to ShellApp runner; delete Relm4 scaffolding (sub-task 3/3 of #448) #540, exactly as the issue/commit describe. render::sync_nerd_fonts()
  being called from ShellApp::setup() and every render_content() frame is
  the correct fix.

Both fixes are logically sound and match the "shared helper in render.rs, thin
per-backend wiring" pattern the Platform-Neutrality Rule requires — no new
backend-specific layout/geometry logic was added to src/gtk/. This is a good
example of the rule being followed correctly.

render::sync_nerd_fonts() calls b.set_nerd_fonts(...) on b: &mut dyn quadraui::Backend — a trait-object call. This only compiles if
Backend::set_nerd_fonts is a trait method. On the local ~/src/quadraui
checkout (branch develop @ b6421ae, the tip before fetching), it is
not — set_nerd_fonts is only an inherent method on the concrete
GtkBackend/TuiBackend structs. I confirmed the trait promotion landed
separately in quadraui as 9613f9c "feat(quadraui): promote set_nerd_fonts to Backend trait (#391)", dated 2026-06-29 — two days before this vimcode
commit (2026-07-01) — and that it's on origin/develop (needs git pull to
reach a stale local checkout, exactly the scenario vimcode's own CLAUDE.md
"stale quadraui checkout" section anticipates).

So process-wise this is fine (quadraui-first did happen), but the PR/commit
message never names this dependency, contrary to the issue's explicit
acceptance criterion: "Any quadraui gap uncovered ... is fixed in quadraui
first, referenced here ... Name the quadraui PR/branch in the briefing." As
written, a future reader hitting a build break here (no method named set_nerd_fonts found for &mut dyn Backend) has to reverse-engineer that it's
a stale-quadraui issue rather than a vimcode bug — please add a line to the
commit message / PR body naming quadraui commit 9613f9c / the
issue-391-add-backend-set-nerd-fonts-to-trait-so-s branch, and confirm
whatever machine runs the Test-stage smoke build has quadraui develop pulled
past that commit.

Neither new test actually exercises the two new pub functions that are the
substance of this fix:

• test_single_group_breadcrumb_bounds_reflect_hidden_tab_bar asserts
  layout.breadcrumbs[0].bounds.y via build_screen_layout directly — it
  never calls breadcrumb_draw_targets. It's a good regression pin for the
  pre-existing bounds computation the refactor now trusts, but it doesn't
  cover breadcrumb_draw_targets's own logic: the terminal_maximized early
  return, the segments.is_empty() filter, or the origin_offset addition
  arithmetic.
• test_explorer_tree_rows_carry_glyph_and_fallback_icons asserts
  build_explorer_tree_rows (pre-existing, unchanged by this diff) produces
  distinct glyph/fallback pairs — it doesn't touch sync_nerd_fonts at all.

Given the issue's acceptance criteria explicitly asked for "a test that ...
asserts breadcrumb presence + Nerd-Font glyph selection ... or the
platform-neutral equivalent asserting the shared model/icon selection both
backends consume," consider adding a direct unit test for
breadcrumb_draw_targets (pure function, trivially testable: build a
ScreenLayout via build_screen_layout, then call
breadcrumb_draw_targets(&screen, false, lh, (10.0, 20.0)) and assert
rect.x/y reflect the offset, and that terminal_maximized: true yields an
empty Vec). sync_nerd_fonts itself is a one-line wrapper so may not need a
dedicated test, but the above would close the gap between what's asked for and
what's covered.

src/gtk/mod.rs ~7601-7612 draws every target from breadcrumb_draw_targets
unconditionally, while both TUI call sites (src/tui_main/render_impl.rs:351
and :401) guard with if t.rect.width > 0.0. That guard exists in TUI
because the pre-existing code had it (preserved correctly by the refactor);
GTK's call site is brand new and never had it, so it was simply omitted.

I checked whether this can matter: bc.bounds.width can be 0.0 in the
min_x == f64::MAX fallback branch in build_screen_layout (a group with no
matching window rects — e.g. a transient state during group-tree mutation).
Traced into quadraui::gtk::status_bar::draw_status_bar — a zero-width rect
just clips a cr.rectangle(x, y, 0, line_height) region, so it's a visual
no-op rather than a crash. Not a functional bug, but it's exactly the kind of
per-backend divergence the shared-helper refactor exists to eliminate — worth
folding the width > 0.0 filter into breadcrumb_draw_targets itself so
neither backend has to remember it separately.

While tracing the icon-selection path I noticed build_explorer_tree_rows
(src/render.rs:7221-7229, not touched by this diff) resolves the FILE
icon glyph via vimcode's own icons::file_icon(ext) (which already applies
vimcode's global icons::USE_NERD_FONTS flag internally via Icon::s()), then
wraps it as QIcon::new(glyph, ".".to_string()) — a hardcoded "." fallback.
Since quadraui::gtk::tree::draw_tree also gates on the backend's
nerd_fonts_enabled (picking icon.fallback when off), toggling nerd fonts
off at runtime will make every file row show a bare "." rather than its
per-type ASCII fallback letter (e.g. "R" for Rust). This is a latent,
pre-existing quirk unrelated to what #547 fixes (which is specifically the
nerd_fonts_enabled flag being stuck false, not this double-resolution
issue), but it does mean the new test's doc comment — "selection between them
is entirely the backend's job... not build_explorer_tree_rows's" — isn't
actually true for file rows (only for folder rows, which pass the raw
icons::FOLDER.nerd/.fallback pair through). Worth a follow-up issue, not a
blocker here.

• Tests added/updated: yes, but see v0.3.0: TUI-only binary (vcd) #2 above — coverage is adjacent to, not
  directly on, the two new functions.
• Scope: stayed within the two regressions described in GTK regressions from #515: editor breadcrumbs broken + explorer treeview icons don't use Nerd Fonts (converge on quadraui; fix quadraui gaps first) #547; no scope creep.
• Security: none — pure rendering/layout code, no I/O or external input.
• Follows existing patterns: yes — matches the QSL::new() /
  Surface::StatusBar / frame.draw(backend) pattern used elsewhere in the
  same function for tab bars and the global status bar.
• Platform-neutral: yes, and a good example of it — both backends now go
  through the same render::breadcrumb_draw_targets /
  render::sync_nerd_fonts helpers; no new per-backend geometry/layout logic
  was added to src/gtk/.

Requesting changes — primarily to close the acceptance-criteria gaps: name the
quadraui commit/branch this depends on (finding #1) and, ideally, add a direct
test of breadcrumb_draw_targets (finding #2). The core fix logic itself is
correct; #3 and #4 are optional/non-blocking nits worth a mention to the fix
worker but not required before merge.