Move from idea to evidence

1. Research before building

   Nothing gets planned until it's been checked against a real source. In the reference project, every fact in the security column carries a link, a check date and a quote pulled from the tool's own page — never a guess, and never a third-party summary standing in for the original.

2. Artifacts: one shared page, not thirty files

   The deck's own framing is the clearest version of this: thirty markdown files versus one page with the flow on it. Research findings, the open questions and a prototype of the new column all sat in a single HTML file the owner could open and mark up directly, instead of a folder of disconnected notes.

3. Prototype before code

   The shared page didn't just list findings — it mocked up the exact table cell the build would eventually render, using the same shell and badge styles as the live page. Seeing the real shape surfaced two problems (scope drift, a contradictory cell) before a single line of production code existed.

4. The implementation plan

   Once the owner corrected scope, the plan came next — twelve small tasks, each with its own commit, each checkable on its own. A plan is not a paragraph of intentions; it's a sequence a different session could pick up and execute without asking what "then handle the rest" means.

5. Small builds

   The build followed the plan task by task: one commit per tool's data, one commit for the render code, one commit for the docs. Ten commits, each reversible on its own, each checkable against the one task it closed — not one large commit that has to be trusted whole.

6. Review stops and a second model

   The build's own check script passed 48 of 48 assertions. That was not the finish line. A second model, playing reviewer and not builder, read every source link by hand and found four real defects the check script had no way to catch, because the check only tests that the code renders what data.js says — not that what data.js says is still true.

Six stops, three models, one habit repeated: check it before you build it, then check it again after. In the reference project this route filled in the last empty column of a five-tool comparison page.

1. 01

   Research

   Sonnet

   Pull the claim from the tool's own page only. Quote it word for word, with a link and a check date. Where a page can't be read (a JavaScript-only trust page, a browser that hangs), say so instead of filling the gap with a plausible guess.

2. 02

   One shared page

   Sonnet

   Findings and open questions land in a single file the owner reads directly — not a chat summary of them. This is where scope drift gets caught, because it's visible on the page instead of buried in a research doc nobody re-reads.

3. 03

   Prototype

   Sonnet

   The same file mocks up the actual table cell, same markup and badges as the live page. The owner sees precisely what a product manager would see, before deciding it's worth building.

4. 04

   The plan

   Opus

   Small, ordered, named tasks. Each task states its files, its commit, and how to verify it. A plan that can't be handed to a fresh session and executed step by step isn't a plan yet.

5. 05

   Small build

   Sonnet

   One commit per task, run in order. When a step can't be done as written — a page that won't load, a fetch that's blocked — the build stops and says so rather than inventing a workaround.

6. 06

   Review by a second model

   Fable

   A different model, told explicitly it is reviewing and not building, opens every source link and checks the claim against the page. Its own tests are not enough proof; a reviewer who didn't write the code checks what the code says against the world.

Steps 2 and 3 happened inside one file — the shared page below, before it was cut back to what the brief actually asked for (see the first review stop).

<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. -->

Three real moments from the run. Each one shows a proposed next action. Decide first, then see what the reviewer decided and why.

Three adapted files from the end of Core 3: the plan that survived review stop 2, the review that produced stop 3, and the data the build actually shipped.

# 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",
    },
  ],
},

The free prompt pack for every stop on the route: research, one shared page, a prototype, a plan, a small build, and the review that catches what your own checks passed.

• The prompt pack for the whole route

  One prompt per stop, from research to the review that catches what your own checks passed. Run them in order on your own project.

  See what the route turns a one-line ask into

  The ask

  “Add the security and data column to the comparison page.”

  One sentence, no sources, no plan, and no way to tell afterwards whether the result can be trusted.

  What the route produced

  The same ask, run through the route

  Research → one shared page → plan → small build → review

  Research

  Every claim quoted word for word from each tool's own pages, with a link and a check date. Two pages that would not load were marked unread rather than guessed.

  One shared page

  All five tools side by side on a single review page, so the owner could cut the scope back before anything was built.

  Plan

  12 small steps, each naming the file it changes and how to tell it worked.

  Review

  A second model opened every source link: 22 of 26 quotes matched, 4 did not. The build's own checks had passed all 48.

  Get it free