Files

alexpolo1 11ad6b7f0b feat: enforce verified smart package catalog

2026-08-10 12:38:52 +02:00

26 KiB

Raw Permalink Blame History

Løbende og månedlig tømrergennemgang af hele Tilbudsgiver

Formål

Denne procedure bruges løbende ved produktændringer og køres som en samlet kontrol mindst én gang om måneden. Formålet er at gøre hele Tilbudsgiver så nem, smart og funktionel som muligt for en tømrer.

Platformens vigtigste opgave er:

En tømrer skal, mens han eller hun står hos kunden, hurtigt kunne registrere kunden og opgaven, få et fagligt brugbart tilbudsudkast, kontrollere pris og omfang og gøre tilbuddet klar til kunden uden at skulle lave det hele igen på kontoret.

Kontrollen skal derfor ikke kun undersøge, om knapper og API'er virker. Den, der udfører kontrollen, skal arbejde som en erfaren tømrer på kundebesøg, bruge hele siden på mobil og desktop og vurdere både hastighed, forståelighed og faglig kvalitet.

Metoden er:

Vælg en realistisk tømrersag.
Gennemfør hele tilbudsflowet som tømrer.
Notér fejl, mangler og usikre antagelser undervejs.
Prioritér observationerne som P0, P1 eller P2.
Lav en konkret plan for P0 og løs punkterne ét ad gangen.
Test efter hver rettelse og kør samlet regression bagefter.
Gentag samme metode for P1.
Slet/flyt den gamle PDF, generér en ny og kontrollér det faktiske dokument.
Opdatér månedsrapporten med beviser, åbne risici og næste handling.

Produktets nordstjerne

Alle produktbeslutninger vurderes mod én hovedopgave: hurtigt fra kundebesøg til korrekt tilbud.

En funktion er kun smart, hvis den reducerer tømrerens arbejde uden at skjule væsentlige valg eller opfinde fakta. En ny skærm, AI-funktion eller ekstra valgmulighed er en forringelse, hvis den gør tilbudsflowet langsommere eller mere usikkert.

En smartpakke er et vedligeholdt fagligt produkt. Hvis den mangler normale materialer eller opgaver inden for sit erklærede anvendelsesområde, skal grundpakken udvides og testes. Hvis konstruktionen, tagtypen eller arbejdsmetoden er reelt anderledes, oprettes en ny smartpakke. Projektspecifikke undtagelser må ikke ukritisk blive globale standardvalg.

Alle materialelinjer i en smartpakke skal pege på et rigtigt materiale i materialedatabasen via stabilt materiale-id eller varenummer. Fritekst, placeholders og kopier uden databasekobling må ikke godkendes som permanente pakkematerialer. Mangler et nødvendigt materiale, oprettes og kvalitetssikres det i materialedatabasen før brug. AI må kun formulere tilbudet fra de godkendte projekt- og pakkedata og må aldrig opfinde materialer, opgaver, timer eller priser.

Ved hvert review skal følgende måles:

tid fra start til et brugbart tilbudsudkast;
tid fra færdigt udkast til kontrolleret PDF/klart tilbud;
antal nødvendige klik eller trin;
antal felter tømreren skal skrive manuelt;
antal oplysninger der indtastes mere end én gang;
antal gange brugeren må gå tilbage for at rette data;
antal uklare valg, fagudtryk eller fejlbeskeder;
antal forslag systemet udfylder korrekt;
antal forslag tømreren må slette eller rette;
om arbejdet overlever afbrydelse, skærmskift og genindlæsning.

Som foreløbigt produktmål bør en kendt kunde og almindelig opgavetype kunne blive til et kontrollerbart tilbudsudkast på højst 10 minutter. Tiden skal måles hver måned og bruges til at finde flaskehalse. Hastighedsmålet må aldrig opnås ved at skjule manglende opmåling, prisusikkerhed eller sikkerhedskritiske forhold.

Hvornår tømrer-mode bruges

Brug tømrer-mode:

ved den faste månedlige helhedsgennemgang;
efter større ændringer i kunde-, projekt-, pakke-, beregnings- eller tilbudsflow;
når en rigtig tømrer melder, at noget er langsomt, uklart eller besværligt;
når data fra Ordrestyring, prisbøger eller AI ændres;
før en større release;
når målinger viser flere afbrudte eller ufærdige tilbud.

Den månedlige kontrol giver en samlet baseline. De løbende reviews bruger samme metode på det berørte flow og føjer observationer til næste måneds rapport.

Tømrerrollen

Under gennemgangen skal kontrolløren tænke og handle som en tømrer, der står med telefonen hos kunden. Kunden venter, der kan være støj og afbrydelser, og tømreren skal både lytte, opmåle, tage stilling og forklare løsningen. Flowet skal derfor fungere uden teknisk specialviden og uden unødvendig navigation.

Stil løbende disse spørgsmål:

Kan arbejdet faktisk udføres i den beskrevne rækkefølge?
Mangler der adgang, stillads, kran, afdækning, affald eller oprydning?
Er tagtype, konstruktion og materialevalg kompatible?
Er mængderne beregnet på det rigtige areal og med relevante enheder?
Er timerne realistiske for antal tømrere og opgavens kompleksitet?
Er alle nødvendige opgaver med, uden at systemet opfinder ikke-valgte arbejder?
Er der tydeligt skel mellem kendte fakta, foreløbige skøn og forhold, der kræver besigtigelse?
Kan kunden forstå tilbuddet, og kan alle priser summeres fra de viste linjer?
Vil data, timer og valg stadig være der efter genindlæsning?
Er historiske sager reelt sammenlignelige, eller bliver vi vildledt af testdata og andre opgavetyper?
Kan jeg se, hvad næste naturlige trin er, uden at lede?
Kan de vigtigste handlinger udføres på mobil med én hånd?
Er knapper, felter og fejltekster forståelige for en tømrer og ikke kun en udvikler?
Hjælper systemet mig med relevante standardvalg uden at låse mig fast?
Kan jeg rette et smart forslag hurtigt, når virkeligheden hos kunden er anderledes?
Kan jeg vise kunden et roligt, troværdigt overblik uden interne systemdetaljer?

Kontrolløren må ikke skjule faglig usikkerhed ved at udfylde manglende fakta. Manglende opmåling, fotos, materialemodel eller leverandørpris skal noteres som en afklaring eller et forbehold.

Hele siden skal reviewes

Tømrer-mode omfatter hele platformen, ikke kun PDF og beregning. Gennemgå mindst disse områder:

Login og startside.
Søgning og valg af eksisterende kunde.
Oprettelse af ny kunde og håndtering af dubletter.
Oprettelse, fortsættelse og redigering af projekt.
Mobil besigtigelse, noter, mål og eventuelle fotos.
Geometri og opgavetype.
Smart pakke og historiske forslag.
Materialer, udlejning og prisstatus.
Arbejdsopgaver, timer og bemanding.
Final Review og forbehold.
Kundetekst, PDF og klargøring til afsendelse.
Genåbning, rettelse og ny version af tilbuddet.
Status og kobling til Ordrestyring.
De øvrige sider, menuer og dashboards: kan tømreren finde tilbage til tilbudsflowet, og er sekundære funktioner tydeligt adskilt fra hovedopgaven?

For hvert område vurderes:

Dimension	Spørgsmål
Nem	Forstår en tømrer siden uden instruktion?
Hurtig	Er der unødvendige trin, klik, scroll eller gentagelser?
Smart	Foreslår systemet relevante værdier på baggrund af kendte data?
Faglig	Er forslag, beregninger og ordvalg tømrermæssigt korrekte?
Sikker	Er antagelser, risici og manglende fakta synlige?
Mobil	Kan flowet gennemføres på en almindelig telefon hos kunden?
Robust	Overlever data afbrydelse, tilbage-navigation og reload?
Kundeklar	Er slutresultatet roligt, forståeligt og professionelt?

Notér også funktioner, menupunkter og information, som ikke hjælper hovedopgaven. Målet er ikke flest mulige funktioner, men kortest mulig sikker vej til et godt tilbud.

Primært feltforsøg: tømrer hos kunden

Kør dette scenarie med stopur som den vigtigste månedlige accepttest:

Åbn siden på mobilvisning.
Log ind og start et nyt tilbud uden at bruge udviklerværktøjer.
Find en eksisterende kunde eller opret en ny.
Registrér adresse og en kort mundtlig kundebeskrivelse.
Vælg opgavetype og indtast de mål, der realistisk kan tages på stedet.
Vælg en komplet smartpakke, og lad systemet beregne materialer og opgaver fra målene.
Ret de forslag, der ikke passer til besigtigelsen. Notér samtidig, om grundpakken skal udvides, om en ny pakke er nødvendig, eller om forholdet kun gælder projektet.
Tilføj adgang, stillads, affald, forbehold og andre byggepladsforhold.
Kontrollér timer, materialepris, avance, moms og total.
Generér kundetekst og PDF.
Læs tilbuddet som kunden og kontrollér, at det kan forklares på stedet.
Afbryd flowet én gang, genindlæs siden og kontrollér, at arbejdet er bevaret.
Ret én væsentlig oplysning og generér tilbuddet igen.

Registrér tid efter trin 3, 6, 9 og 10. Notér præcis, hvor tømreren må vente, tænke unødigt, lede efter en funktion eller indtaste samme oplysning igen.

Der må ikke sendes noget til en rigtig kunde under kontrolkørslen. Testen slutter ved “klar til afsendelse”, medmindre der findes en eksplicit godkendt intern testmodtager.

Månedligt testprojekt

Vælg mindst ét projekt, som tilsammen udfordrer geometri, materialer, arbejde, økonomi og PDF. Projektet skal blive i review_pending og må ikke sendes til Ordrestyring under testen.

Brug gerne en fast referencesag, så resultater kan sammenlignes måned for måned. Projekt 392, Røsevangen 44, kan bruges som betontagsreference, så længe projektdata fortsat er egnede. Supplér med en anden tagtype i de måneder, hvor en ændring berører B7, tegl, tagpap, Velux eller andre løsninger.

Registrér før start:

Felt	Værdi
Dato
Kontrollør
Git commit/branch
Projekt-id
Kunde og adresse
Tag-/opgavetype
Projektstatus
Forventet areal
Forventede timer
Forventet total
Kendte forbehold

Fase 1: Faglig gennemgang som tømrer

1. Kunde og projekt

Søg kunden på navn, kundenummer og adresse.
Kontrollér vej/husnummer, postnummer og by.
Hvis samme navn og vejadresse findes flere gange, skal systemet advare og kræve et aktivt valg.
Kontrollér, at projektet er koblet til det korrekte kundenummer.
Kontrollér, at projektbeskrivelsen svarer til det arbejde, kunden ønsker.

Notér eksempelvis:

OBS-01 — Kunde-dublet
Fakta: Kundenr. 3352 og 3364 har samme navn og vej/husnummer.
Risiko: Tilbud kan blive koblet til forkert postadresse.
Forventning: Tydelig advarsel og aktivt valg før fortsættelse.
Resultat: Bestået / Fejl.

2. Besigtigelses- og geometrigrundlag

Kontrollér tagform, bredde, længde, hældning, antal tagflader og eventuelle gennembrydninger.
Sammenlign grundareal med reelt tagbeklædningsareal.
Kontrollér rygning, tagfod, skotrender, valme, kviste, skorstene, ovenlys og skel mod nabo, når de er relevante.
Kontrollér, at pris pr. m² beregnes på roof_covering_area for tagarbejde.
Markér oplysninger som fysisk opmålt, hentet fra ekstern kilde eller foreløbigt skøn.

En realistisk tagkontrol skal også afklare adgang, loftsadgang, stilladszone, kranmulighed, affaldshåndtering og risiko for skjulte træskader.

3. Smart pakke og materialer

Kontrollér, at den foreslåede pakke passer til tagtypen.
Kontrollér, at tømreren kan vælge én komplet tilbudspakke frem for manuelt at samle mange delpakker.
Udvid den eksisterende pakke, når den mangler noget, der normalt hører til dens anvendelsesområde. Opret en ny pakke, når løsningen fagligt er en anden.
Hold projektspecifikke tilvalg og forbehold på projektet, medmindre gentagne sager viser, at de er en fast del af pakken.
Betontag må ikke automatisk blive til vingetegl.
Kontrollér undertag, kontra-/afstandslister, lægter, tagsten/plader, fastgørelse, rygning, tagfod og relevante afslutninger.
Kontrollér, at hver materialelinje har et gyldigt materiale-id/varenummer, som kan slås op i materialedatabasen.
Fritekstmaterialer og placeholders er en fejl. Opret eller godkend først materialet i materialedatabasen.
Kontrollér mængde, enhed og spild for hver linje.
Kontrollér, at m², lbm, stk, pakke og sum bevares gennem hele flowet.
Kontrollér, at serviceydelser som stillads ikke skjules som almindelige materialer.
Markér manglende eller forældede priser. Opfind ikke en aktuel leverandørpris.

4. Arbejdsopgaver og timer

Gennemgå arbejdsrækkefølgen, som hvis holdet skulle udføre sagen:

Etablering, sikkerhed og afdækning.
Nedtagning og sortering.
Kontrol af underlag og konstruktion.
Eventuel mindre opretning.
Undertag og ventilationsopbygning.
Lægter og afstandslister.
Tagbelægning og fastgørelse.
Rygning, tagfod og inddækninger.
Slutkontrol, oprydning og dokumentation.

Kontrollér:

total timer;
timer pr. opgave;
timepris og samlet arbejdsløn;
antal tømrere og realistisk varighed;
at opgavenavn og beskrivelse er forskellige felter;
at timer og opgaver overlever en fuld browser-genindlæsning.

5. Historik og Ordrestyring

Gennemgå alle accepterede historikmatches manuelt.
Afvis testkunder, simulationer, forkert adresse, ikke-tagarbejde og inkompatible tagtyper.
Et match må ikke få høj confidence alene, fordi kunden er den samme.
Hvis ingen sag er sammenlignelig, er 0 matches bedre end et misvisende forslag.
Kontrollér, at fravalgte matches har en konkret årsag i excludedMatches.
Kontrollér, at Ordrestyring-beløb konverteres fra øre til kroner ved integrationsgrænsen.
Pengekontrakten skal indeholde normaliseret amount, currency, minorUnit og råt minorAmount.

6. Final Review og økonomi

Regn tilbuddet efter manuelt. Følgende skal kunne summeres direkte:

Materialer
+ Udlejning og øvrige ydelser
+ Arbejdsløn
= Direkte subtotal
+ Overhead
= Subtotal med overhead
+ Dækningsbidrag
= Pris ekskl. moms
+ Moms
= Pris inkl. moms

Kontrollér, at beregnings-API, Final Review, tilbudstekst, PDF og Ordrestyring-payload bruger samme versionerede økonomimodel. En afrundingsforskel på en øre skal forklares; en skjult prispost er en fejl.

7. Kundetekst og PDF

Kontrollér først tilbuddet på skærmen. Generér derefter PDF'en fra de gemte projektdata.

PDF'en skal mindst indeholde:

korrekt kundenavn, adresse og kundenummer;
korrekt projektnavn;
tag-/opgavetype og prisgrundlag;
valgte arbejdsopgaver og timer;
materialer med korrekte enheder;
udlejning og øvrige ydelser;
alle økonomiens delsummer;
moms og total;
eksplicitte forbehold.

PDF'en må ikke indeholde arbejde, materialer eller forbehold, som ikke kan spores til projektets data. Eksempelvis må asbestsanering eller udskiftning af stern/vindskeder ikke indsættes automatisk.

Fase 2: Notér fejl og mangler

Skriv observationer, mens flowet gennemføres. Vent ikke til sidst. Brug ét nummer pr. problem og vedlæg konkret evidens.

OBS-XX — Kort titel
Trin: Hvor i flowet fejlen opstår
Fakta: Hvad der faktisk blev vist eller returneret
Forventet: Hvad en tømrer eller kunde med rimelighed forventer
Faglig risiko: Pris, udførelse, sikkerhed, kunde eller datakvalitet
Teknisk spor: Side, endpoint, felt, log eller fil
Prioritet: P0 / P1 / P2
Status: Åben / I gang / Løst / Verificeret
Bevis efter rettelse: Test, API-svar, skærmbillede eller PDF-side

Skriv forskellen mellem fakta og vurdering tydeligt:

Fakta: roof_covering_area er 69,28 m².
Vurdering: 76 timer virker realistisk for det foreløbige omfang.
Mangler: Fysisk opmåling og fotos findes endnu ikke.

Prioritering

P0 — tilbuddet må ikke bruges

Brug P0 ved eksempelvis:

tømreren kan ikke færdiggøre eller klargøre et tilbud hos kunden;
kritiske felter eller handlinger kan ikke bruges på mobil;
forkert total eller uigennemsigtig økonomi;
arbejdsløn eller valgte data forsvinder;
ugyldig PDF-download;
forkert kunde;
PDF eller tilbud opfinder arbejde;
en fejl kan give væsentligt forkert pris, omfang eller sikkerhed.

P1 — høj prioritet

Brug P1 ved eksempelvis:

unødvendige trin eller gentagen indtastning, som gør feltflowet mærkbart langsommere;
uklare knapper, tekster eller navigation i hovedflowet;
smarte forslag, der ofte kræver manuel oprydning;
forkerte kunde-/projektfelter i PDF;
tab af opgavenavne eller materialenheder;
forkert smart pakke;
forurenet historikmatch;
fejl i øre/kroner;
forkert areal som prisgrundlag;
manglende dubletadvarsel.

P2 — forbedring

Brug P2 til arbejdsgang, kvalitet og effektivitet, når tilbuddet stadig er korrekt og sikkert. Eksempler er kortere PDF, bedre feltcheckliste, tydeligere kildeangivelse og bedre mobil oprettelse.

Fase 3: Løs metodisk

Arbejd altid i denne rækkefølge:

Opret en plan for alle P0-punkter.
Tag ét P0-punkt ad gangen.
Reproducer fejlen med test eller konkrete data.
Find den fælles årsag og kontrakt, ikke kun det synlige symptom.
Implementér den mindst mulige komplette rettelse.
Tilføj happy-path og failure-path test.
Kør den berørte test.
Verificér rettelsen i det aktive flow.
Markér først punktet løst, når beviset er gemt.
Fortsæt med næste P0.
Kør fuld regression og live-kontrol.
Opret derefter en P1-plan og gentag samme metode.

Hvis en ny kontrol afslører, at et tidligere punkt ikke er færdigt, genåbnes punktet straks. Fortsæt ikke til næste prioritet for at få listen til at se færdig ud.

Faste automatiske kontroller

Kør fra repository-roden. Installer først afhængigheder, hvis miljøet er nyt.

Backend

cd backend
npm test -- --coverage --passWithNoTests --runInBand

Krav: Alle suites og tests består. Nye service-/API-rettelser skal have relevante Jest-tests.

Frontend

cd frontend
CI=true npm test -- --runInBand
npm run build

Krav: Alle tests består, og production build kompilerer uden fejl.

Målrettet browserkontrol

cd tests
PLAYWRIGHT_BASE_URL=http://localhost:4032 npx playwright test labor-reload.spec.js

Tilføj eller vælg flere målrettede specs for den funktion, der blev ændret. Den brede Playwright-mappe indeholder ældre tests med hardcodede porte, eksterne AI-/loginforudsætninger og gamle API-kontrakter. Kør den brede suite separat, og registrér dens fejl særskilt; den må ikke erstatte en målrettet test af månedens flow.

Live-kontrol

Sæt månedens projekt og server uden at genbruge systemvariabler:

AUDIT_BASE_URL=http://localhost:4032
AUDIT_PROJECT_ID=392

Drift og labor

pm2 status
curl -fsS "$AUDIT_BASE_URL/api/health" | jq
curl -fsS "$AUDIT_BASE_URL/api/customer-projects/$AUDIT_PROJECT_ID/labor" | jq

Kontrollér, at PM2-processen er online, og at labor returnerer én stabil kontrakt med de gemte timer og opgaver.

Historik

curl -fsS "$AUDIT_BASE_URL/api/customer-projects/projects/$AUDIT_PROJECT_ID/order-suggestions?limit=10" \
  | jq '{recommendedPackage:.recommendation.recommendedPackage,matches,excludedMatches}'

Læs de accepterede matches. Det er ikke nok kun at kontrollere antallet.

Kundedubletter

AUDIT_CUSTOMER_QUERY='Alexander Warme'
curl -fsS --get "$AUDIT_BASE_URL/api/customers/search" \
  --data-urlencode "q=$AUDIT_CUSTOMER_QUERY" \
  | jq '{count,customers:[.customers[]|{customerNumber,name,address,postalCode,city}]}'

Kontrollér også brugerfladen: vælg en markeret dublet, og bekræft at kunden ikke kan anvendes, før ét kundenummer er valgt aktivt.

Beregning

En ny beregning opretter en ny beregningspost. Brug kun kontrollerede input fra Final Review, og behold projektet i review.

AUDIT_MATERIAL_TOTAL=44981.80
AUDIT_RENTAL_TOTAL=14000.00
AUDIT_LABOR_TOTAL=44080.00

curl -fsS -X POST "$AUDIT_BASE_URL/api/customer-projects/$AUDIT_PROJECT_ID/calculate" \
  -H 'Content-Type: application/json' \
  --data "{\"materialTotal\":$AUDIT_MATERIAL_TOTAL,\"rentalTotal\":$AUDIT_RENTAL_TOTAL,\"laborTotal\":$AUDIT_LABOR_TOTAL}" \
  | jq '{success,calculationId,data:{model:.data.model,totalInclVat:.data.totalInclVat,pricingArea:.data.pricingArea,areaBasis:.data.areaBasis,areaLabel:.data.areaLabel}}'

Kontrollér manuelt delsummerne, ikke kun totalen.

Slet/flyt og regenerér PDF

Overskriv ikke den gamle kontrolfil uden at bevare den midlertidigt. Brug en eksplicit filsti; brug aldrig brede slettekommandoer eller repository-roden som mål.

AUDIT_PDF="$(pwd)/Tilbud_maanedlig_kontrol_${AUDIT_PROJECT_ID}.pdf"
AUDIT_PDF_BACKUP_DIR=$(mktemp -d /tmp/tilbudgivern-pdf-backup.XXXXXX)

if test -f "$AUDIT_PDF"; then
  mv "$AUDIT_PDF" "$AUDIT_PDF_BACKUP_DIR/"
fi

curl -fsS -X POST "$AUDIT_BASE_URL/api/pdf/generate" \
  -H 'Content-Type: application/json' \
  --data "{\"projectId\":$AUDIT_PROJECT_ID}" \
  -o "$AUDIT_PDF"

Teknisk kontrol:

file "$AUDIT_PDF"
head -c 5 "$AUDIT_PDF"
pdfinfo "$AUDIT_PDF"
pdftotext -layout "$AUDIT_PDF" -
sha256sum "$AUDIT_PDF"

Krav:

de første bytes er %PDF-;
dokumentet kan åbnes og har forventet sidetal;
tekstudtræk indeholder kunde, adresse, kundenummer, areal, timer og alle prisdele;
summerne stemmer;
ingen ikke-valgte arbejder er tilføjet.

Lav også en visuel kontrol af mindst første side, en typisk opgaveside og økonomisiden. Tekstudtræk kan ikke afsløre overlap, afskåret tekst eller dårlig sideskift.

Den midlertidige backupsti skal skrives i månedsrapporten. Slet først backupfilen senere, når den nye PDF er godkendt, og kun hvis det er ønsket.

Samlet beståelseskriterium

Månedskontrollen er kun bestået, når:

det tidsmålte feltforsøg er gennemført og dokumenteret;
hovedflowet kan udføres på mobil uden en blokerende UX-fejl;
hele platformens centrale sider er vurderet som nemme, hurtige, smarte og fagligt anvendelige;
alle P0-punkter er løst og verificeret;
alle planlagte P1-punkter er løst eller eksplicit godkendt som åbne;
backend- og frontendtests består;
frontend build består;
målrettede browserflows består;
live API-data matcher projektets gemte fakta;
accepterede historikmatches er fagligt relevante;
beregningsmodellen er ens på tværs af systemet;
en helt ny PDF er teknisk, tekstligt og visuelt kontrolleret;
projektet ikke utilsigtet er sendt til Ordrestyring;
rapporten indeholder resterende besigtigelses- og leverandørforbehold.

En P0-fejl betyder ikke bestået og blokerer brug af tilbuddet. En åben P1-fejl skal være synlig i rapporten og have ejer/næste handling.

Månedsrapport

Opret én rapport pr. kørsel:

docs/status-reports/MAANEDLIG_TOEMRER_KONTROL_ÅÅÅÅ-MM.md

Brug denne struktur:

# Månedlig tømrerkontrol — ÅÅÅÅ-MM

## Testprojekt
- Projekt-id:
- Kunde/adresse:
- Opgavetype:
- Git commit:
- PM2-proces/PID:

## Tømrerens faglige vurdering
- Omfang:
- Materialer:
- Arbejdsrækkefølge:
- Timer/bemanding:
- Manglende besigtigelsesdata:

## Feltforsøg og hastighed
- Enhed/skærmstørrelse:
- Tid til kunde valgt/oprettet:
- Tid til smart udkast:
- Tid til kontrolleret pris:
- Tid til kundeklar PDF:
- Antal gentagne indtastninger:
- Største flaskehals:

## Review af hele siden
| Område | Nem | Hurtig | Smart | Mobil | Fejl/forbedring |
|---|---:|---:|---:|---:|---|
| Login/start | | | | | |
| Kunde/projekt | | | | | |
| Besigtigelse/geometri | | | | | |
| Smart pakke/materialer | | | | | |
| Opgaver/timer | | | | | |
| Final Review/PDF | | | | | |
| Rettelse/genåbning | | | | | |
| Navigation/øvrige sider | | | | | |

## Observationer
| ID | Prioritet | Fejl/mangel | Risiko | Status | Bevis |
|---|---|---|---|---|---|

## Rettelser
1. ...

## Testresultater
- Backend:
- Frontend:
- Build:
- Playwright målrettet:
- Bred legacy-suite, hvis kørt:

## Live-verifikation
- Labor:
- Historik:
- Kundedublet:
- Beregnings-id og total:
- Arealgrundlag:

## PDF
- Ny fil:
- Backup:
- `%PDF-`:
- Sidetal:
- SHA-256:
- Visuel kontrol:

## Åbne risici og næste handling
- ...

## Resultat
BESTÅET / IKKE BESTÅET

Instruktion, der kan gives til Codex hver måned

Kopiér og tilpas denne tekst:

Udfør den løbende/månedlige tømrerkvalitetsgennemgang af hele platformen efter
docs/guides/MAANEDLIG_TOEMRER_KVALITETSGENNEMGANG.md.

Arbejd som en erfaren tømrer, der står med mobilen hos kunden og skal gøre et
tilbud klar så hurtigt og sikkert som muligt. Gennemfør hele siden og det
valgte projekt fra login, kunde og besigtigelse til materialer, timer, Final
Review og PDF. Tag tid på hovedflowet. Notér alt der er langsomt, uklart,
unødvendigt, ikke mobilt, fagligt forkert eller teknisk ustabilt. Opfind ikke
manglende fakta.

Vurdér hver central side på om den er nem, hurtig, smart, faglig, sikker,
mobil, robust og kundeklar. Forslag til forbedringer skal prioritere færre
trin, mindre dobbeltindtastning, bedre standardvalg og hurtigere vej til et
korrekt tilbud. Smarte funktioner må ikke skjule antagelser eller opfinde
arbejde og priser.

Lav først en plan for P0, løs ét punkt ad gangen og test efter hver rettelse.
Kør derefter samlet regression. Lav så en plan for P1 og gentag samme metode.
Hvis et tidligere punkt ikke er færdigt, genåbn det.

Flyt den eksisterende kontrol-PDF til en sikker midlertidig backup, generér en
helt ny PDF fra de aktive gemte data, og kontrollér rå PDF-signatur, tekst,
summer og visuel rendering. Send ikke projektet til Ordrestyring.

Opret månedsrapporten i docs/status-reports/ og afslut med BESTÅET eller IKKE
BESTÅET samt åbne risici og næste handling.

Baseline fra august 2026

Den første dokumenterede gennemgang brugte projekt 392, Røsevangen 44:

korrekt kunde: Ordrestyring kundenr. 3352, 3520 Farum;
tagbeklædningsareal: 69,28 m²;
arbejde: 76 timer á 580 kr.;
materialer: 44.981,80 kr.;
stillads/faldsikring: 14.000,00 kr.;
total: 177.781,60 kr. inkl. moms;
økonomimodel: standard_overhead_profit_v1;
anbefalet pakke: betontag_renovering;
historik: 0 accepterede matches efter faglig filtrering;
beregning efter P1-verifikation: id 102;
backend: 34 suites / 167 tests;
frontend: 6 suites / 12 tests;
målrettet Playwright labor-reload: 1/1;
PDF: rå og læsbar A4-PDF på 9 sider, teknisk og visuelt kontrolleret.

Baseline er et sammenligningsgrundlag, ikke en tilladelse til at antage, at næste måneds leverandørpriser, geometri eller byggepladsforhold er uændrede.

26 KiB Raw Permalink Blame History