Prova remixen med tre ofarliga markörer innan du delar ett riktigt projekt. Lägg en synlig kodmarkör i appen, en textfil i Files-fliken och en särskild mening i chatten. Låt sedan mottagaren skapa kopian och anteckna vilka av de tre som faktiskt finns.
Vad Lovable ändrade
I Lovables changelog för 7 september 2026 står att filer uppladdade till projektets Files-flik inte längre kopieras automatiskt vid remix. Den som går via en publik projektlänk får koden, men varken dessa projektfiler eller chatthistoriken.
En person som redan har redigeringsåtkomst till originalet möter fler val. Remixdokumentationen beskriver två separata reglage: Copy project files to new project för Files-fliken och Include project history för chatthistoriken, inklusive filer som bifogats i chattmeddelanden. Båda är avstängda från början och visas bara för den som har redigeringsåtkomst.
En fil i projektets kod är inte samma sak som en fil som någon har lagt i Files-fliken. Chattbilagor hör i sin tur till historikvalet. Skriv därför var en viktig fil ligger. Formuleringen ”allt finns i projektet” är för vag för att gå att kontrollera.
Bygg en ofarlig fixtur med tre markörer
Använd ett testprojekt utan personuppgifter, riktiga nycklar eller produktionsanslutningar. Skapa tre markörer som är lätta att känna igen men värdelösa utanför provet.
Ta en skärmbild av var varje markör ligger i originalet. Skriv också originalets projektnamn och tidpunkten för provet. Då går det att skilja ett missat val i remixdialogen från en markör som aldrig fanns när kopian skapades.
Prov A: mottagare med bara publik länk
Kontrollera först att Public remixing är en avsedd väg i arbetsytan. Lovable anger att inställningen är avstängd som standard och att publik remix inte finns i Enterprise-arbetsytor. Aktivera den bara för testprojektet och skicka länken till ett separat testkonto utan redigeringsåtkomst. Om ni i stället delar en förhandsvisning utan att lämna över koden, använd kontrollpunkterna i guiden om Lovables delningslänkar, lösenord och utgångstid.
Det här är inte ett misslyckat prov när bara koden finns. Det är det dokumenterade utfallet för en publik mottagare. Misslyckandet vore att överlämnaren lovat en komplett arbetskopia utan att först kontrollera vad ordet komplett betyder.
Prov B: mottagare med redigeringsåtkomst
Ge ett annat testkonto redigeringsåtkomst till originalet enligt er vanliga rutin. Starta en ny remix och läs dialogen innan kopian skapas. Markera både Copy project files to new project och Include project history. Ta en skärmbild som visar valen; den är beviset för vilken kopia du senare undersöker.
Gör om samma tre kontroller. Godkänt betyder att kodmarkören syns, att mottagarprov.txt innehåller REMIX-FIL-202 och att chatten innehåller REMIX-HISTORIK-303. Om ett reglage saknas ska ni inte gissa att innehållet ändå följer med. Kontrollera behörigheten till originalet och skapa inte fler kopior förrän dialogens faktiska val är förstådda.
Spara utfallet i en mottagarmatris
Den här kontrollen kompletterar provet i artikeln om att göra en Lovable-ändring i en kopia. Där är frågan om ändringen fungerar utan att originalet rörs. Här är frågan smalare: vilket underlag mottagaren faktiskt får när kopian skapas.
En fungerande preview bevisar inte en fungerande överlämning
Lovable listar flera delar som inte följer med en remix: databasens poster, versionshistorik, hemligheter, egna domäner, publiceringsstatus, medarbetare samt Git- och connectoranslutningar. Databasens struktur kan följa med utan data. En app kan därför se riktig ut i previewn men ändå sakna de poster och anslutningar som ett arbetsflöde behöver.
Lägg aldrig en riktig hemlighet i testet för att se om den försvinner. Dokumentationen säger att hemligheter inte kopieras; provet ska i stället kontrollera att mottagaren har en plan för att lägga in nya behörigheter i den nya kopian. För överlämningar med skarpa integrationer behövs en separat anslutningslista med ägare och nya testuppgifter.
Om ni egentligen vill flytta det enda originalet är remix fel begrepp. Lovable skiljer remix, som skapar en självständig kopia, från transfer, som flyttar ett befintligt projekt. Kopian hålls inte heller synkroniserad med originalet. Efter provet ska mottagaren alltså veta vilken av de två som är arbetsversionen.
En publik mottagare och en redigeringsbehörig mottagare har var sin dokumenterad kopia. För båda finns konto, behörighet, dialogval, projekt-id och utfall för kod, Files och historik. Inga riktiga hemligheter eller produktionsdata användes. Överlämnaren har därefter valt delningsväg uttryckligen och skrivit vilka delar mottagaren måste återskapa.