What β share the repeated section-styling logic across the home page's section components.
Why β eight components define an identical variant / containerStyle / sectionStyle trio plus the same theme data(). That is roughly 200 duplicated lines, and a change to the background rule currently means eight edits.
Scope β add src/modules/home/composables/home.sectionMixin.js and adopt it in the eight components whose trio is identical: about, articles, capabilities, cta, faq, features, services, steps.
These are Options-API components, so a Composition-API composable will not drop in β use a mixin. It lives under composables/ to match the module convention (billing, docs and legal each have one).
Do NOT convert these five β each differs, and converting breaks it (verified per file on master):
| Component |
Why excluded |
contact |
has no setup prop at all; its trio reads module config instead. The mixin would throw on render. Its data() also holds an unrelated key. |
statistics |
no variant, no containerStyle; its sectionStyle deliberately omits the background (supplied by the blur component). data() holds four animation keys. |
social |
sectionStyle adds an overflow rule and a gradient custom property the logo marquee depends on. |
presentation |
containerStyle adds padding and a glass style. |
gallery |
sectionStyle carries a theme-undefined guard for prerender safety. |
hero and team.member have no trio at all.
Three of the eight (articles, capabilities, features) have extra data() keys beyond the theme one. Delete only the theme key β never the whole data() block. Drop data() entirely only where theme was its sole key.
Test-harness note: the mixin calls Vuetify's useTheme() in data(), which throws without a Vuetify install. There is no global Vuetify in the vitest setup, so a mount-based test must install Vuetify (and provide the config global) explicitly or it fails on harness rather than on logic.
Definition of done: home module tests pass, and the page is visually verified β this is in-scope visual work, so a runtime check is required, not optional. Confirm section backgrounds still alternate and that the five excluded components render unchanged.
Scope: validated 2026-07-28
Created via /dev:issue
Baseline: line numbers and counts here were verified against master @ d246bc14 (2026-07-28). Master moves β re-verify against current master before starting; the invariants above are what must hold regardless of where the code has drifted to.
What β share the repeated section-styling logic across the home page's section components.
Why β eight components define an identical
variant/containerStyle/sectionStyletrio plus the same themedata(). That is roughly 200 duplicated lines, and a change to the background rule currently means eight edits.Scope β add
src/modules/home/composables/home.sectionMixin.jsand adopt it in the eight components whose trio is identical:about,articles,capabilities,cta,faq,features,services,steps.These are Options-API components, so a Composition-API composable will not drop in β use a mixin. It lives under
composables/to match the module convention (billing, docs and legal each have one).Do NOT convert these five β each differs, and converting breaks it (verified per file on master):
contactsetupprop at all; its trio reads module config instead. The mixin would throw on render. Itsdata()also holds an unrelated key.statisticsvariant, nocontainerStyle; itssectionStyledeliberately omits the background (supplied by the blur component).data()holds four animation keys.socialsectionStyleadds an overflow rule and a gradient custom property the logo marquee depends on.presentationcontainerStyleadds padding and a glass style.gallerysectionStylecarries a theme-undefined guard for prerender safety.heroandteam.memberhave no trio at all.Three of the eight (
articles,capabilities,features) have extradata()keys beyond the theme one. Delete only the theme key β never the wholedata()block. Dropdata()entirely only where theme was its sole key.Test-harness note: the mixin calls Vuetify's
useTheme()indata(), which throws without a Vuetify install. There is no global Vuetify in the vitest setup, so a mount-based test must install Vuetify (and provide the config global) explicitly or it fails on harness rather than on logic.Definition of done: home module tests pass, and the page is visually verified β this is in-scope visual work, so a runtime check is required, not optional. Confirm section backgrounds still alternate and that the five excluded components render unchanged.
Scope: validated 2026-07-28
Created via /dev:issue
Baseline: line numbers and counts here were verified against
master @ d246bc14(2026-07-28). Master moves β re-verify against current master before starting; the invariants above are what must hold regardless of where the code has drifted to.