Was du am Ende dieses Moduls hast
Am Ende dieses Moduls hast du eine echte Änderung im Referenzprojekt ausgeliefert: einen Plan auf der Platte, kleine, einzeln rückgängig zu machende Commits und das Review eines zweiten Modells, festgehalten mit dem, was es gefunden hat, und nicht nur grüne Tests des Builders.
Dieses Modul setzt dort an, wo Nie wieder bei null anfangen aufgehört hat: ein Projekt mit einer funktionierenden CLAUDE.md, einem Dev-Doc und einer Lessons-Datei. Die Lücke ist diesmal nicht das Gedächtnis. Es fehlt eine einzige Vergleichsdimension. Sie hinzuzufügen ist die Aufgabe.
Die Route ist dieselbe, die der MVP Blueprint aus der Sicht von Designern durchläuft: recherchieren, daraus etwas Reales formen, planen, klein bauen, eine zweite Meinung einholen.
Was dieses Modul vermittelt
- Recherchieren vor dem Bauen
Nichts wird geplant, bevor es an einer echten Quelle geprüft wurde. Im Referenzprojekt trägt jede Angabe in der Sicherheitsspalte einen Link, ein Prüfdatum und ein Zitat von der eigenen Seite des Tools: nie geraten und nie eine Zusammenfassung von Dritten anstelle des Originals. - Artefakte: eine gemeinsame Seite statt dreißig Dateien
Die Formulierung aus dem Deck bringt es am klarsten auf den Punkt: dreißig Markdown-Dateien gegen eine Seite mit dem Ablauf darauf. Recherchefunde, offene Fragen und ein Prototyp der neuen Spalte lagen in einer einzigen HTML-Datei, die der Owner direkt öffnen und kommentieren konnte, statt in einem Ordner voller unverbundener Notizen. - Prototyp vor Code
Die gemeinsame Seite listete nicht nur Funde. Sie bildete genau die Tabellenzelle nach, die der Build später rendern würde, mit derselben Shell und denselben Badge-Styles wie die Live-Seite. Die echte Form zu sehen, brachte zwei Probleme ans Licht (Scope Drift, eine widersprüchliche Zelle), bevor es eine einzige Zeile Produktionscode gab. - Der Umsetzungsplan
Nachdem der Owner den Scope korrigiert hatte, kam der Plan: zwölf kleine Tasks, jeder mit eigenem Commit, jeder einzeln prüfbar. Ein Plan ist kein Absatz voller Absichten, sondern eine Abfolge, die eine andere Session aufnehmen und ausführen kann, ohne nachzufragen, was „dann den Rest erledigen“ heißt. - Kleine Builds
Der Build folgte dem Plan Task für Task: ein Commit pro Tool-Daten, ein Commit für den Render-Code, ein Commit für die Doku. Zehn Commits, jeder einzeln rückgängig zu machen, jeder gegen den einen Task prüfbar, den er abgeschlossen hat. Kein großer Commit, dem man als Ganzes vertrauen muss. - Review-Stopps und ein zweites Modell
Das Check-Skript des Builds bestand 48 von 48 Assertions. Das war nicht die Ziellinie. Ein zweites Modell, in der Rolle des Reviewers und nicht des Builders, las jeden Quell-Link von Hand und fand vier echte Fehler, die das Check-Skript nicht erkennen konnte, weil der Check nur prüft, dass der Code rendert, was data.js sagt, nicht, dass das, was data.js sagt, noch stimmt.
Die Aufgabe
Ausgangspunkt
Das Core-2-Projekt, in dem eine Vergleichsdimension fehlt.
Erwartetes Ergebnis
Die ergänzte Dimension, plus der Plan, aus dem sie entstanden ist, und das Review, das sie geprüft hat.
Bestanden, wenn
Die Änderung umgesetzt ist, der Plan, der sie hervorgebracht hat, auf der Platte liegt und ein Review durch ein anderes Modell festgehalten ist, samt dem, was es gefunden hat.
Die Claude Code Route: von der Recherche zur geprüften Änderung
Sechs Stopps, drei Modelle, eine Gewohnheit, die sich wiederholt: erst prüfen, bevor du baust, dann nach dem Bauen noch einmal prüfen. Im Referenzprojekt füllte diese Route die letzte leere Spalte einer Vergleichsseite mit fünf Tools.
- Recherche (Sonnet)
Hole die Aussage ausschließlich von der eigenen Seite des Tools. Zitiere sie wortwörtlich, mit Link und Prüfdatum. Wo eine Seite nicht lesbar ist (eine reine JavaScript-Trust-Seite, ein Browser, der hängt), sag das, statt die Lücke mit einer plausiblen Vermutung zu füllen. - Eine gemeinsame Seite (Sonnet)
Funde und offene Fragen landen in einer einzigen Datei, die der Owner direkt liest, nicht in einer Chat-Zusammenfassung davon. Hier fällt Scope Drift auf, weil er auf der Seite sichtbar ist, statt in einem Recherche-Dokument zu verschwinden, das niemand erneut liest. - Prototyp (Sonnet)
Dieselbe Datei bildet die tatsächliche Tabellenzelle nach, mit demselben Markup und denselben Badges wie die Live-Seite. Der Owner sieht genau das, was ein Product Manager sehen würde, bevor er entscheidet, ob sich der Bau lohnt. - Der Plan (Opus)
Kleine, geordnete, benannte Tasks. Jeder Task nennt seine Dateien, seinen Commit und wie man ihn verifiziert. Ein Plan, den man nicht an eine frische Session übergeben und Schritt für Schritt ausführen lassen kann, ist noch kein Plan. - Kleiner Build (Sonnet)
Ein Commit pro Task, der Reihe nach. Wenn ein Schritt nicht wie geschrieben machbar ist (eine Seite, die nicht lädt, ein blockierter Abruf), stoppt der Build und sagt es, statt einen Workaround zu erfinden. - Review durch ein zweites Modell (Fable)
Ein anderes Modell, dem ausdrücklich gesagt wird, dass es prüft und nicht baut, öffnet jeden Quell-Link und gleicht die Aussage mit der Seite ab. Die eigenen Tests reichen als Beleg nicht aus; ein Reviewer, der den Code nicht geschrieben hat, prüft, was der Code sagt, an der Wirklichkeit.
Schritt 2 und 3 passierten in einer einzigen Datei, der gemeinsamen Seite unten, bevor sie auf das zurückgeschnitten wurde, was das Briefing tatsächlich verlangte (siehe den ersten Review-Stopp).
<div class="banner draft">
Draft for review: this page exists so you can check the findings and the
prototype column before anything is planned or built into index.html.
</div>
<h2>1. Full findings, side by side</h2>
<!-- Tool | Data location | Certifications | Encryption | Retention & subprocessors | Open items -->
<!-- Encryption and Retention & subprocessors: cut after review stop 1.
They stayed in docs/research/point-4-security.md, never shipped
on the live page. -->
<h2>2. Prototype: the "Security & data" column in index.html</h2>
<!-- Same table shell and badge styles as the live page, so the owner sees
how it will actually read on a call before it's built for real. -->Würdest du das freigeben?
Drei echte Momente aus dem Durchlauf. Jeder zeigt eine vorgeschlagene nächste Aktion. Entscheide zuerst selbst, dann sieh, was der Reviewer entschieden hat und warum.
Abgelehnt: Scope Drift. Punkt 4 des Briefings verlangt nur zwei Dinge: wo die Daten liegen und welche Sicherheitsaussagen das Tool veröffentlicht. Die Recherche hat mehr geholt (Verschlüsselung, Aufbewahrung, Subunternehmer, Zeilen zum KI-Training), weil ein guter Recherchierender dem folgt, was auf der Seite steht. Das zusätzliche Material ist nützlich, gehört aber nicht auf die Seite, die das Briefing abgesteckt hat. Es bleibt in der Recherche-Datei; der Owner schneidet die gemeinsame Seite auf die zwei verlangten Dinge zurück, bevor ein Plan geschrieben wird.
Abgelehnt: voreiliges Bauen. Ein Plan auf der Platte ist nicht dasselbe wie ein Plan, den der Owner tatsächlich gelesen hat. Im Beispiel-Build hält der erste Fortschrittseintrag des Dev-Docs den Blocker in einer Zeile fest: „User said 'don't build.'“ Der nächste Eintrag öffnet sich erst, nachdem der Owner den Plan geprüft und Go gesagt hat. Durch das Warten ging nichts verloren (der Plan hat sich nicht geändert), aber wer gegen einen ungelesenen Plan baut, riskiert, gegen einen zu bauen, den der Owner korrigiert hätte, genau wie die Recherche-Seite zuerst eine Korrektur brauchte.
Abgelehnt: Bestandene Tests sind nicht dasselbe wie wahre Aussagen. Ein zweites Modell prüfte dieselben Commits gegen die Live-Quellseiten und fand vier echte Fehler, die das Check-Skript nicht erkennen konnte, weil der Check nur prüft, dass die Seite rendert, was data.js sagt, nicht, dass data.js noch stimmt. Es fand ein Zitat, dem ein Wort fehlte (ein Verstoß gegen die Vertrauensregel), eine Notiz, die behauptete, eine Seite „couldn't be read“, obwohl die Antwort im eigenen Quelltext der Seite stand, eine Regel (Covers builder), die auf dieselbe Art von Satz auf zwei Arten angewendet wurde, und ein Zitat, das eine andere Frage beantwortete, als die Zelle behauptete. Alle vier bestanden die eigenen Tests des Builders. Keiner wäre ohne einen Reviewer aufgefallen, der den Code nicht geschrieben hat.
Das Projekt zu diesem Zeitpunkt
Drei adaptierte Dateien vom Ende von Core 3: der Plan, der Review-Stopp 2 überstanden hat, das Review, das Stopp 3 hervorgebracht hat, und die Daten, die der Build tatsächlich ausgeliefert hat.
# Point 4 (Security & Data) Implementation Plan
**Goal:** Fill the "Security & data" column in `index.html` from a new
`security` block per tool in `data.js`: data location + published security
claims, each quoted word for word with link, date and
`Covers builder: stated / not stated`.
**Scope source:** dev-docs/2026_09_17-SCOPE-pt2-CP_Security_And_Data.md.
Encryption, retention, subprocessors and AI-training lines are OUT: they
stay in docs/research/point-4-security.md only.
---
### Task 0: Manual recheck of Replit's security page (user, in a browser)
Owner: user (agents couldn't expand the accordions).
Copy any data-location or certification sentence word for word, with link,
check date and Covers builder value.
### Task 1: Fix the Lovable wording in the research file
Old: "The page does not say where data is stored (confirmed Not stated)."
New: "trust.lovable.dev itself doesn't say where data is stored. That's
silence on this one page, not 'Not stated' for Lovable: data location is
sourced from lovable.dev/security above."
### Task 2: Write the failing check script
tests/point4.check.js: runs index.html's real inline script against a
stubbed DOM and asserts on the rendered TEXT, not just "something rendered."
### Tasks 3–8: data.js (header, meta, then one security block per tool)
Lovable, Bolt.new, v0, Replit, Figma Make. Each commit is one tool.
### Task 9–10: index.html (styles, then the render functions)
Run: node tests/point4.check.js → expect ALL PASS, 48/48.
### Task 11: Real browser check (user)
Owner opens index.html, confirms every quote against its source link.
### Task 12: Docs update
CLAUDE.md and the pt2 dev-doc, renamed to READY4QA once Task 11 passes.
---
### Not in this plan (launch gate)
A second person checks every point 4 cell against its link before the team
uses it. Not this review: the brief's own launch gate, still open.# Review: point 4 (security & data), 2026-09-17
**Reviewer:** Fable (reviewer role, not builder). Nothing was changed in
index.html, data.js or the docs; findings only.
**Reviewed:** commits core-3-start..40baab9 (13 commits) against
docs/brief.md, the pt2 dev-doc and the plan.
## Verdict
**Not ready for the team yet. Ready for QA after 4 small data fixes.**
- 22 of 26 quotes verified word for word on the live source page.
- node tests/point4.check.js → ALL PASS, 48/48.
- Nothing on the page is a guess. But three cells would mislead a product manager
by omission, one cell carries a "couldn't read it" note over content that
is readable in the page source, and the Covers builder badge is applied
inconsistently.
## Findings (excerpt)
### F1: Replit SOC 2 quote is not word for word
Live page: "...demonstrating **our** ongoing commitment..."
data.js has "demonstrating ongoing commitment": the word "our" is missing.
Ask: add "our" back in data.js and the research file.
### F2: The Replit "FAQ unread" note is contradicted by the page source
The FAQ accordions don't render in a fetched browser session, but the
answers are embedded as structured data (FAQPage JSON-LD) in the HTML
source. Two published Replit claims are missing from the page as a result.
### F3: Covers builder is applied inconsistently
Same tool, same kind of sentence, different badge in three places. The
written rule doesn't say precisely enough what "names the builder" means.
...(F4–F8 fix a plan-gate note, a code-execution quote misfiled as data
location, a cut sentence, and a claim with no certification in it.)security: {
dataLocation: [
{
quote: "Lovable Cloud supports regional data hosting in the EU, US, and Asia Pacific.",
coversBuilder: "stated",
url: "https://lovable.dev/security",
checkDate: "2026-09-17",
checkCountry: "Germany",
},
{
quote: "Customer data remains in the region you select and does not move across regions by default.",
coversBuilder: "not stated",
url: "https://lovable.dev/security",
checkDate: "2026-09-17",
checkCountry: "Germany",
},
{
quote: "We and our service providers process Personal Data in a number of countries, including the United States.",
coversBuilder: "not stated",
url: "https://lovable.dev/privacy",
checkDate: "2026-09-17",
checkCountry: "Germany",
},
],
claims: [
{
quote: "AIUC-1, SOC 2 Type I, ISO 27001:2022, GDPR, SOC 2 Type II",
coversBuilder: "not stated",
url: "https://trust.lovable.dev",
checkDate: "2026-09-17",
checkCountry: "Germany",
note: "Listed under the Compliance section. Checked by hand in a browser. Badge list doesn't name Lovable in the text itself, so Covers builder: not stated per the brief's rule.",
},
{
quote: "Lovable supports SOC 2 and GDPR requirements and provides security documentation and data protection agreements for enterprise review.",
coversBuilder: "stated",
url: "https://lovable.dev/security",
checkDate: "2026-09-17",
checkCountry: "Germany",
},
],
},Geh dieselbe Route an deinem eigenen Projekt
Das kostenlose Prompt-Paket für jeden Stopp der Route: Recherche, eine gemeinsame Seite, ein Prototyp, ein Plan, ein kleiner Build und das Review, das auffängt, was deine eigenen Checks durchgewunken haben.
Die Anfrage
„Füge der Vergleichsseite die Spalte zu Sicherheit und Daten hinzu.“
Ein Satz, keine Quellen, kein Plan und keine Möglichkeit, hinterher festzustellen, ob man dem Ergebnis trauen kann.
Was die Route geliefert hat
| Ergebnis | |
|---|---|
| Recherche | Jede Aussage wortwörtlich von den eigenen Seiten jedes Tools zitiert, mit Link und Prüfdatum. Zwei Seiten, die nicht luden, wurden als ungelesen markiert, statt geraten. |
| Eine gemeinsame Seite | Alle fünf Tools nebeneinander auf einer einzigen Review-Seite, sodass der Owner den Scope zurückschneiden konnte, bevor irgendetwas gebaut wurde. |
| Plan | 12 kleine Schritte, jeder mit der Datei, die er ändert, und woran man erkennt, dass er funktioniert hat. |
| Review | Ein zweites Modell öffnete jeden Quell-Link: 22 von 26 Zitaten stimmten, 4 nicht. Die eigenen Checks des Builds hatten alle 48 bestanden. |
