Applikasjonen opplevde teknisk ustabilitet under bygging, manifestert som en 500-feil. Dette skjedde som en konsekvens av at dynamiske rute-parametre ble forsøkt aksessert inne i definePageMeta-makroen, som evalueres før ruten er fullstendig instansiert. Samtidig manglet prosjektet en oppdatert oversikt over sidestrukturen, noe som gjorde det utfordrende å navigere i den voksende mengden sider og ruter.

Målet var todelt. For det første å dokumentere alle sider for å øke vedlikeholdbarheten. For det andre å løse byggfeilen ved å skille statisk metadata fra dynamisk SEO-logikk, uten å miste evnen til å vise beskrivende sidetitler basert på innholdet.

• For å løse 500-feilen, identifiserte jeg at definePageMeta er en compiler macro som krever statiske verdier. Jeg refaktorerte sluggen ved å erstatte dynamiske labels med statiske strenger.
• Jeg utvidet funkasjonaliteten for å lage en dynamisk-navigering med en watch som ser etter forandringer i side stien. Inne i denne funksjonaliteten la jeg til logikk som sjekker for slugs. Hvis en slug finnes, formateres denne til en menneskevennlig tittel (fjerner bindestreker, stor forbokstav) som sendes til useSeoMeta.
• Jeg oppdaterte prosjektets globale instrukser for å sikre at fremtidige commits følger Conventional Commits-standarden med fokus på arkitektonisk verdi.

Resultatet er en feilfri byggprosess uten prerendering-avvik. Applikasjonen har nå en tydelig skillelinje definePageMeta håndterer statisk organisering og rute-rekkefølge, mens useNavigation håndterer den dynamiske presentasjonen mot bruker og søkemotorer. Dette har redusert teknisk gjeld og gjort systemet mer forutsigbart.

Denne runden har erfart meg å forstå forskjellen mellom build-time macros og runtime logic i moderne rammeverk som Nuxt. Selv om det er fristende å gjøre alt på ett sted, fører det ofte til hydreringsfeil eller build-krasj. Ved å flytte kompleksitet til dedikerte composables oppnår man ikke bare stabilitet, men også en mer gjenbrukbar og testbar kodebase.