Gå til indholdet

Website Factory — udviklingsplan

Status: DISKUSSIONSOPLÆG — ingen beslutning truffet

Konsolideret 2026-09-07. Foreslået rækkefølge fra udviklingsplan v1.0, korrigeret med reviewet af v2.1. Ingen milepæle er dokumenteret gennemført ved denne import. Se arkitekturgrundlaget.

Første leverance

Allan og Danny kan fra én administration oprette kunden, vælge en skabelon, redigere indhold og branding, uploade billeder, vise preview, godkende en bestemt version og publicere på et verificeret domæne. Besøgende kan læse websitet og sende en henvendelse, som kun vises under den rette kunde.

Start med én branche og én skabelon. Frisører er en arbejdshypotese, ikke et endeligt nichevalg. Foreslåede sider: forside, ydelser/priser, om, kontakt og privatliv. Booking, webshop, fri layoutbygger og kundeselvbetjening udskydes. Domæner og fakturering håndteres manuelt i piloten.

MobilePay-kravet fra repoet består. Pilotens konkrete betalingsgang skal derfor beskrives og afstemmes med kravet før salg; manuel fakturering er ikke en beslutning om at fjerne MobilePay.

Milepæle og beviser

Trin Leverance Bevis før næste trin
M0 · Afgrænsning Branche, pakke, support, roller, domæneejerskab, betalingsgang og driftsmål Et konkret tilbud og tydelige kriterier for første salg; relevante valg føres i ADR
M1 · Fundament Bygbar applikation, CI og separat staging med D1 Frisk checkout bygger; staging-side læser D1 og håndterer fejl uden datalæk
M2 · Kundegrænse To testkunder, verificerede hostnames, login og tilladte bindings A og B viser forskelligt indhold; ukendte hosts og A's adgang til B afvises
M3 · Provisionering Oprettelse, fælles migrationer og genererede bindings Tredje testkunde kan oprettes og jobbet gentages sikkert; gamle kunder forbliver tilgængelige
M4 · Administration Kundeoversigt, virksomhedsbrief og synlig jobstatus Operatøren opretter en kunde og når frem til redigering uden database-id'er i brugerfladen
M5 · Indhold og medier Én skabelon, strukturerede sektioner, kladder og validerede uploads To forskellige virksomheder bruger samme skabelon med adskilte kladder og private medier
M6 · Publicering Beskyttet preview, versionsgodkendelse, outbox, cache og domæneverifikation A publiceres uden kodeudgivelse eller ændring hos B; fejl og rollback demonstreres
M7 · Henvendelser Modulrettighed, aktivering, valideret formular og privat indbakke Henvendelsen lander kun hos rette kunde; direkte kald til deaktiveret modul afvises
M8 · Driftsklarhed Retention, eksport, offboarding, restore, aftaler og overvågning Dokumenterede øvelser og gennemgåede faktiske dataforhold før rigtige besøgsdata
M9 · Pilot 2–3 kunder med manuel domæneopsætning og fakturering Gentagelig drift, målte omkostninger og kendt supportbehov
M10 · Agentkladder Afgrænsede jobs via de eksisterende indholdsoperationer Målbar tidsbesparelse; ingen omgåelse af kundeadgang eller godkendelse
M11 · Udvidelse Flere efterspurgte skabeloner/moduler; eventuel integration til registrar og regnskab Pilotens efterspørgsel og manuelle arbejde begrunder hver udvidelse

Hvert trin afhænger af det foregående. Aftale- og driftsarbejde begynder allerede i M0. Der fastsættes ikke kalenderløfter ud fra de vedhæftede planer alene.

Kritiske acceptkrav

Område Scenarier der skal kontrolleres
Routing og adgang Ukendt/forfalsket hostname, ombyttet binding, suspenderet kunde, A-administrator mod B samt alternative Worker- og preview-adresser
Provisionering Afbrudt oprettelse, gentaget job, fejlet migration, overlappende onboardinger og rollback med nye aktive kunder
Redigering Samtidige ændringer, ugyldige links/sektioner, for store uploads og brug af en anden kundes private medie
Publicering Ændring efter godkendelse, tilbagekaldt godkendelse, nul-række-kontrol, fejl midt i batch, dubleret outbox og fejlet cache-opdatering
Formular Forfalsket kunde-id, deaktiveret modul, SQL-lignende input, spam, gentaget indsendelse og utilgængelig notifikationstjeneste
Data og drift Automatisk udløb, afgrænset eksport, stop før sletning, slettebevis, isoleret restore og genanvendte sletteafgørelser
Brugeroplevelse Mobilvisning, tastaturbetjening, tydelig valgt kunde og forståelige fejl/publiceringsstatusser
Agenter Forsøg på adgang til anden kunde, ændring af rettigheder, ugyldigt output, afbrudte jobs og udokumenterede virksomhedspåstande

Kontrollerne skal ramme reelle applikationsoperationer. Mockede D1-kald dokumenterer ikke databasetransaktioner eller isolation. Kritiske forløb gentages med adskilte stagingressourcer.

Hvad må vente?

Registrarautomatik, CentralNic, Dinero-integration, automatiske fornyelser og agentgenerering er ikke forudsætninger for at vise to websites med adskilte kundedata. Den faktiske domæne- og certifikatopsætning skal dog afprøves tidligt. Særlige registrar- og navneserverkrav undersøges, hvis det kommercielle domænespor vælges.

Adgang til et modul holdes adskilt fra aktivering og konfiguration, også hvis den første pakke inkluderer alle moduler. Selvbetjening og nye systemlag indføres først, når et konkret behov er påvist.

Første udviklingsopgave

Bevis én delt applikation i staging med platform-D1 og to kundebindings. Vis forskellige publicerede markører på to testhostnames. Afvis ukendte hosts og dokumentér med en autentificeret test, at en bruger med adgang til A ikke kan hente B's private data gennem applikationen.

Opgaven hører til et applikationsrepo. Dette repo indeholder planen og testkriterierne. De vedhæftede dokumenters agentprompter, foreslåede mappetræer og instruktioner om at begynde implementering er ikke en del af denne dokumentationsleverance.

Kilder