TESTIMONIA - PUBLICATIEANALYSE 12 oktober 2026 Bewijsgericht rapport - geen systeemreparatie uitgevoerd 4 3. Wat in mijn werkwijze fout gaat De vertraging is ook het gevolg van mijn keuzes. Ik heb de beschikbare infrastructuur onvoldoende afgestemd op snelle, grote toevoegingen. Alleen wachten op de bestaande opdrachten levert geen schaalbare publicatieroute op. Te veel herhaald werk De gewone build start steeds met validate_published: alle eerdere bronbatches worden opnieuw inhoudelijk doorgelopen, nog vóór de keuze om bestaande Bijbelbestanden te hergebruiken. Daarnaast lezen controles en uploadvoorbereiding herhaaldelijk dezelfde release. Op G: worden die vele bestandsacties duur. De incrementele bouw voor slechts 18 noten duurde al ongeveer 2 minuten en 16 seconden. Onvoldoende controle op lopende opdrachten Ik keek eerder naar actieve bouw- en uploadprocessen, maar niet naar alle oude zoekopdrachten. Daardoor konden onderbroken zoekacties doorlopen. Het laatste directe uploadcommando had ook geen vaste eindtijd en gaf tijdens het lezen van bestanden geen voortgang. Mijn meldingen dat het nog draaide maakten de blokkade niet concreet. Tellingen en controles zijn niet consequent hergebruikt De unieke inhoudstelling 25.398 is live bevestigd. Het nieuwe releasebestand meldt echter 970 statische bestanden, terwijl Wrangler 978 assets telt. Mijn incrementele teller voegde per nieuw hoofdstuk één bestand toe, hoewel er een HTML- en een JSON-bestand bijkomen. Die metadata is dus onjuist; dat verandert het aantal unieke bronteksten niet. Mijn eerste nieuwe HTTP-controle kreeg 403 zonder de expliciete clientnaam die de bestaande controle al gebruikte. Met die clientnaam slaagden alle 35 controles. Dat was een fout in mijn nieuwe controle, geen bewijs dat de nieuwe site defect was. Inhoudelijke toelating en technische publicatie zijn verschillende stappen Veel verzamelde privéteksten moeten nog aan werk, editie, vertalerrechten en echte Bijbelverwijzingen worden gekoppeld. Dubbelen leveren geen nieuwe content op. Dat verklaart waarom sommige brede zoek- en onderzoeksrondes weinig toevoegen. Voor de laatste 18 noten waren deze controles al geslaagd; de resterende wachttijd lag in bouwen en publiceren. Aanbevolen volgorde voor herstel 1. Eén eigenaar van de publicatie en een zichtbaar overzicht van alle lopende opdrachten, met beëindiging van verouderde zoekacties. 2. Een gecontroleerde werk- en publicatiekopie op de lokale SSD, met Google Drive als behouden opslag. Geen verhuizing of verwijdering van originelen. 3. Nieuwe batches incrementeel toelaten en bouwen; ongewijzigde tekst- en Bijbelbestanden op basis van bestaande controlebewijzen hergebruiken. 4. Per fase tijd, voortgang en een begrensde wachttijd vastleggen. Eerst technische doorlooptijd meten met één batch, daarna grotere unieke batches. 5. Eén voltooiingsbewijs per batch: publicatie-ID, alle nieuwe teksten live gecontroleerd, correcte tellingen en een overeenkomende GitHub-stand.