Lesson 35.1 gave you a fast loop for learning: idea, prompt, change, run, react. A prototype card and a local preview were enough, because nothing was at stake beyond your own time.

This lesson teaches the moment that stops being true — when "keep prompting until it works" becomes too expensive and too risky.

A boundary crossing is a responsibility change

A project does not become a system gradually, like paint drying. It crosses boundaries — discrete changes in what it is *responsible for*. Watch for these:

• it starts storing real user information,
• it starts sending messages (email, SMS, notifications),
• it starts accepting payments or spending money on paid APIs,
• it starts publishing publicly where strangers and search engines arrive,
• it starts changing infrastructure others depend on,
• it needs to work while the owner is asleep — scheduled jobs, background updates, unattended retries.

A bigger codebase is not the signal. A research dashboard with forty polished mock-data pages is still a prototype. The same dashboard with ten real user accounts and saved watchlists is a system, even if it is smaller. Responsibility, not size, is the tripwire.

Why this is a security lesson, not just a process lesson

Say it plainly: if an uninspected vibe-coded site is about to handle sensitive information, customer accounts, payments, private documents, authenticated third-party services, or production administration, it needs a professional security assessment before it earns that responsibility.

One tool in that assessment is a penetration test — a controlled attempt by a qualified person to find weaknesses an attacker could exploit. A penetration test complements code review; it does not replace it. Review asks "is this code correct and properly permissioned?" A penetration test asks "can someone outside actually break in, escalate, or extract something?" You need both questions once the system holds something worth stealing or breaking. An LLM audit, which you will run below, is a strong inexpensive first pass — it is not a substitute for a qualified professional, real testing, or your own ownership of the result.

The research dashboard grows up, step by step

Follow the course's running example — a small research dashboard where a user picks a public company, the app gathers approved sources, and produces a source-linked brief — through five stages:

Mock company cards
  → approved public-source research prototype
  → saved user watchlists
  → accounts and private data
  → scheduled updates and paid data/API use

Each arrow adds a responsibility, and each responsibility adds questions no prompt can wave away:

Production discipline is not bureaucracy invented by fussy engineers. The system genuinely acquired more responsibility at each step, and each responsibility needs an owner and evidence — not just another prompt.

The prototype-to-product checklist

When you feel the project getting "serious," run it down this table. Any row that now reads true names your next job:

Note what the response is *not*: "rewrite everything." The first response is to write down the current behavior, protect the critical path, and make the next change small enough to inspect. Panic rewrites destroy the one thing the prototype gave you — a working thing you understand.

Graduate feature by feature

Here is the phrase to carry forward: graduate the project feature by feature.

The research dashboard can keep its vibe-coded landing page — low stakes, easy to review — while sign-in, data ingestion, and alerting each receive deliberate treatment: a written expectation, a bounded change, a review, a test. Not every part of the system needs the same rigor on the same day. The parts holding money, identity, or unattended power do.

That is also why Part X matters: version history, specifications, and small tasks are the machinery that lets one feature graduate without dragging the whole project into ceremony. Class 36 introduces the working model; Part X teaches the mechanics.

The audit ladder: five steps before real stakes

Before a site carries real users, money, or sensitive data, climb this ladder in order:

1. Builder reviews the intended behavior and changed files.
2. A second LLM reviews the full repository for bugs, dangerous patterns,
   exposed secrets, missing authorization, weak input handling, and dependency issues.
3. The builder verifies findings against the actual code and fixes/retests real issues.
4. A qualified independent professional performs a penetration test when the system
   handles sensitive data, money, powerful accounts, or a meaningful public attack surface.
5. The team repeats review after material changes; security is not a one-time sticker.

Step 2 deserves a concrete prompt. Give a *different* model from the one that built the project this job:

Then do step 3 honestly: open every cited file. Many LLM findings are wrong, out of date, or harmless in context — and some are real exposed keys, missing permission checks, or unvalidated inputs. Your job is to sort them, fix what is real, and re-run the evidence. An unverified audit report is another form of vibe coding.

And be explicit with yourself about limits: the LLM pass helps you ask better questions, catch obvious problems sooner, and clean the repository before a professional spends time on deeper attack paths. It does not replace testing, a qualified tester, or your responsibility for what the system does. For the weakness categories professionals look for, the shared reference is the OWASP Top 10.

Practical exercise: stage your project

Classify one current project — the events finder, the dashboard, or anything you are building — on this scale: exploration → prototype → internal tool → customer-facing product → operational system.

Then write PROJECT-STAGE.md:

# Project stage: research dashboard

- Current stage: prototype (approved public sources, no accounts).
- Boundaries crossed: real external data; public preview link.
- Not yet crossed: user accounts, stored private data, payments, scheduled jobs.
- One critical workflow: pick company → gather sources → render brief with dates.
- Next control to add: source-freshness check + error state before sharing link further.
- Three responsibilities today: show correct sources; respect source terms; handle source outage visibly.
- Next responsibility likely: private watchlists (data storage + access rules).

Finish line: a PROJECT-STAGE.md with current stage, boundaries crossed, one critical workflow, and the next control to add.

Verify: can a stranger read the file and name what the project must *not* yet be trusted with? If not, the stage is aspirational, not actual.

Common failure mode: listing the stage you want ("customer-facing product") instead of the stage you can prove. Recovery: drop back one stage and name the evidence — tests, reviews, logs — that would earn the next one.

Check your understanding

1. What is a boundary crossing — and why is ten real accounts more of a system than forty mock-data pages? 2. Name three boundary crossings and the new question each one forces. 3. What is a penetration test, and how does it complement (not replace) code review? 4. What does "graduate feature by feature" mean for the dashboard's landing page versus its sign-in flow? 5. Why must every LLM audit finding be verified against the actual code?