Security Governance for AI-Built Apps

Introduction

30 Second Summary

AI app builders generate working code in minutes. Without security guardrails and architectural constraints, that code ships secrets to public repos, runs sensitive logic in the browser, and produces components no senior engineer would approve.

In this project, you will build a secure multi-user task manager through architectural prompts in Lovable, enforce SSR/CSR boundaries that keep secrets server-side, audit the generated code for security gaps, and produce interview artifacts that prove you can govern AI output at a senior level.

What You'll Build

You'll walk into an interview, pull up your public GitHub repo, and demonstrate a live task manager with secure architecture alongside the security audit, prompt playbook, and governance methodology that built it. The repo starts private and goes public only after your audit confirms zero secrets in the codebase or Git history.

By the end of this project, you'll have:

• A secure full-stack app (React + Supabase + Edge Functions) where sensitive operations run server-side, secrets never reach the browser or the repo, and architecture is enforced through governance files.
• A security audit report documenting SSR/CSR boundary checks, secrets scanning, RLS review, and a comparison of guardrailed vs. default AI output.
• A prompt playbook with reusable architectural patterns that enforce security, separation of concerns, and production-quality standards from the first prompt.
• Secret Mission: Test your governance guardrails by deliberately prompting Lovable to violate security boundaries, then document the enforcement results.

Are there any prerequisites?

You need VS Code, Node.js, and a GitHub account before starting. If you already have these, the only new tool is a free Lovable account, which you will create in Step 1.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters for your interview.

This clarity keeps every prompt and audit decision focused on a single goal.

Set Up Lovable and Connect GitHub

To build your task manager app, you need a workspace where natural-language prompts become running code. Lovable is a full-stack AI development platform that generates React apps from descriptions you type in plain English.

In this step, you will create your free Lovable account, spin up a starter project, and connect it to GitHub for two-way sync so you can pull the code locally for review later.

In this step, get ready to:

• Create a free Lovable account using your GitHub login.
• Create your first Lovable project with an architectural prompt.
• Connect GitHub, delete the insecure default repository, and reconnect with a security governance file.

Create your Lovable account

Lovable offers a free plan with five credits per day. Since you already have a GitHub account, signing up with GitHub is the fastest path.

• Open lovable.dev/signup in your browser.
• Click GitHub as your sign-up method.
• Authorize the Lovable OAuth app when GitHub prompts you.

After sign-up, Lovable creates your first personal workspace on the free plan and drops you on the dashboard. You should see a prompt input box front and center.

What is a Lovable workspace?

A workspace is the container where your projects and credits live. The free plan gives you five credits per day (up to 30 per month). Each prompt you send in Build mode uses credits, so every prompt in this project needs to count.

📣 Credit budget for this project

This entire project uses 3-4 of your 5 daily free credits. Write each prompt in a text file before sending it to Lovable. No exploratory or throwaway prompts.

Create your project with an architectural prompt

The prompt you use to create a project shapes the entire codebase. You already created a LOVABLE.md governance file using Claude (covering security, architecture, and system design guardrails). Now you will use an architectural prompt that references that file and bakes in security, architecture, and behavior constraints from the very first line of generated code.

• Click the prompt input box (labelled "Ask Lovable to create...") and paste the following prompt:

Why attach LOVABLE.md before the first build?

Lovable reads instruction files from your repository on every request. By attaching your Claude-generated LOVABLE.md as a file in the chat (or pasting it into the initial prompt context), you ensure the AI agent reads your security and architecture rules while generating the very first line of code.

This is a critical interview insight: governance must be present before code generation, not layered on after. A senior engineer never generates code and then hopes to retrofit security. They set the boundaries first, then build inside them.

• Attach your Claude-generated LOVABLE.md file to the chat by clicking the paperclip icon (or drag and drop the file into the chat pane).
• Then paste the following prompt into the chat input below the attached file:

Build the authentication flow: sign-up and login pages using Supabase Auth with email/password.

Security constraints:
- Never place API keys, tokens, or secrets in frontend code or committed files.
- Authentication validation must happen server-side via Supabase Auth, not custom client-side logic.
- Do not store sensitive values in any environment variable that gets bundled into the frontend build.
- Only VITE_ prefixed public values (Supabase URL, anon key) belong in .env.

Architecture constraints:
- Separate auth logic into a custom hook (src/hooks/useAuth.ts).
- Keep UI components presentational in src/components/auth/ with no direct Supabase calls.
- Use TypeScript strict mode. Never use the any type.
- Add an error boundary wrapping the auth routes.
- Every async operation must include try/catch with a user-facing error state.

Behavior:
- Include loading states for all async operations.
- Form validation: email format check and password minimum 8 characters.
- User-facing error messages for failed auth attempts (wrong password, user not found, network error).

Refer to the LOVABLE.md file in the repository root for full security, architecture, and system design guardrails. Do not modify LOVABLE.md.

Do not build any other features yet. Do not create any other pages or routes beyond auth.

What makes this a senior-level prompt?

This prompt operates on three axes simultaneously. Security constraints prevent secrets from leaking into frontend code from the first line generated. Architecture constraints enforce hook/component separation and TypeScript strict mode so the codebase starts with the structure you need, not a structure you have to refactor later. Behavior specs name exact validation rules and error states so Lovable cannot skip them.

The reference to LOVABLE.md tells Lovable to read your governance file on this very first build. The negative constraint ("Do not build any other features yet") prevents scope creep. Together these produce a governed codebase from commit zero, not a codebase you have to retrofit later.

• Click the send button to submit the prompt.
• Wait for Lovable to finish building. The first project takes a few minutes to generate.

When the build completes, you land in the Lovable editor. You should see the chat pane on the left and the live preview on the right showing sign-up and login pages.

• In the live preview, click through to the sign-up page.
• Try submitting the form with an invalid email. You should see a validation error message appear inline.
• Try submitting with a password shorter than 8 characters. You should see a separate validation error for the password field.

What does this cost?

This initial prompt uses approximately 1 credit. Creating your account and adjusting settings costs 0 credits. You have used 1 of your 5 daily credits so far.

🙋‍♀️ Don't see auth pages in the preview?

If the build seems stuck, wait a full minute. Lovable takes longer on the very first project generation. If you see an error, try refreshing the page. Your project is saved automatically and you can return to it from the dashboard.

If Lovable built something but it looks different from expected, that is normal. AI output varies. The key checks are: does a sign-up form exist, does a login form exist, and do validation errors appear for bad input.

Still stuck? Help me troubleshoot my Lovable project build.

Connect GitHub and confirm the sync

Git sync gives you a full copy of your code in a GitHub repository. Changes you make in Lovable push to GitHub automatically, and commits you push to the synced branch flow back into Lovable.

• In the Lovable editor, click the project name in the top bar.
• Select Settings from the dropdown.
• In the Settings sidebar, click the Git tab.
• Click Add account.

What happens next?

A GitHub popup opens asking you to authorize the Lovable GitHub app. Since you are on the free plan, Lovable takes you straight to the github.com installation flow.

• In the GitHub popup, choose your personal account.
• Select All repositories.
• Click Install & Authorize.

Lovable detects the installation and creates a new repository linked to your project. Two-way sync starts automatically.

Before you check GitHub, what do you expect to see in the new repository?

• Open github.com in a new browser tab.
• Look at your repositories list. You should see a new repository created by Lovable with at least one commit containing the project files.
• Switch back to the Lovable editor and confirm you still see the chat pane on the left and the live preview with your authentication pages on the right.

Don't see the repository on GitHub?

Make sure you authorized the Lovable app on your personal GitHub account, not an organization you do not own. If the popup closed before you could finish, return to the Git tab in Lovable Settings and try Add account again.

Need more help? Help me connect Lovable to GitHub.

Delete the insecure repository and reconnect with guardrails

The repository Lovable just created has security problems. It was set up with "All repositories" access, giving Lovable permission to read every repo on your account. It contains no governance rules, so Lovable could hardcode secrets in frontend components, push sensitive credentials to the repo, or run server-side logic in client-side code where anyone with browser DevTools can inspect it.

You will delete this repository, then reconnect with tighter permissions and a security governance file that Lovable reads on every prompt.

• On GitHub, open the Lovable-created repository.
• Click Settings in the repository's top navigation bar.
• Scroll down to the Danger Zone section at the bottom of the page.
• Click Delete this repository.
• GitHub asks you to type the repository name to confirm. Type it and click I understand the consequences, delete this repository.

The repository is now deleted. Next, disconnect the stale Git link inside Lovable.

• Switch back to the Lovable editor.
• Click your project name in the top bar, then select Settings.
• Click the Git tab.
• Click Disconnect to remove the broken repository link.

Before reconnecting, you will add a security governance file directly in Lovable's code editor. Lovable reads instruction files like LOVABLE.md from the repository root on every prompt, enforcing whatever rules you define.

• In the Lovable editor, click the Code tab in the project toolbar.
• Click the + icon to create a new file.
• Name the file LOVABLE.md and paste the following content:

# Security, Architecture, and System Design Guardrails

## Repository Hygiene
- A .gitignore MUST exist before the first commit. It excludes: .env.local, .env*.local, node_modules/, dist/, .DS_Store.
- The .env file may ONLY contain VITE_ prefixed public build-time values (Supabase URL, anon/publishable key). These are intentionally public.
- Never commit .env.local or any file containing real secret values.
- Never commit node_modules/, build artifacts, or OS-generated files.

## Secrets Management
- Never hardcode API keys, tokens, service_role keys, JWT secrets, database passwords, or credentials in any source file.
- Never store secrets in environment variables that get bundled into the frontend build.
- Store all secrets in Supabase Edge Function secrets (runtime-only) or Lovable Secrets.
- If a value would cause damage if leaked publicly, it does not belong in the repository or in any VITE_ variable.

## SSR/CSR Boundary (Edge Functions vs React)
- All sensitive logic runs server-side in Supabase Edge Functions, never in the browser.
- Authentication, authorization, and session validation happen server-side.
- External API calls requiring credentials go through Edge Functions.
- Database queries using service_role or bypassing RLS run in Edge Functions only.
- Payment processing, email sending, webhook handling, and PII operations run server-side.
- Edge Functions read secrets from the Supabase secret store at runtime.

## Frontend Security (React Components)
- Client-side code handles ONLY: UI rendering, form validation, visual state, user interactions.
- Client-side code reads ONLY from VITE_ prefixed environment variables.
- Never perform authorization decisions in the browser.
- Never call external APIs from frontend code if the call requires a secret key.
- Never log, console.log, or expose sensitive values in client-side code.
- Never expose internal IDs, admin endpoints, or debug info in production builds.

• Still in the Code tab, paste the remaining sections of LOVABLE.md below what you just added:

## System Design and Architecture
- Separate data-fetching logic into custom hooks (src/hooks/).
- Keep UI components presentational with no direct Supabase calls.
- Use a layered architecture: UI components -> custom hooks -> Supabase client/Edge Functions.
- Group related components in feature directories (src/components/[feature]/).
- Share types across layers using a dedicated types directory (src/types/).
- Design for testability: hooks should be independently testable without UI rendering.

## Code Quality
- Use TypeScript strict mode. Never use the any type.
- Every async operation must include error handling with user-facing messages.
- Use error boundaries at route level.
- All user input must be validated client-side (format, length, required) AND server-side (Edge Functions).
- No console.log statements in production code. Use a structured logging utility if logging is needed.

## Change Control
- Name what you will NOT change in each response.
- Do not modify existing working features when adding new ones.
- Do not reorganize file structure unless explicitly asked.
- Never remove or weaken security rules in this file.

• Now create a second file. Click the + icon again to create a new file.
• Name the file .gitignore and paste the following content:

# Dependencies
node_modules/

# Environment files with secrets
.env.local
.env.development.local
.env.test.local
.env.production.local

# Build output
dist/
build/

# OS-generated files
.DS_Store
Thumbs.db

# IDE files
.vscode/
.idea/

# Debug logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*

Why create .gitignore before the first push?

Once a file is committed to Git history, deleting it later does not remove it from past commits. Anyone with access can still find it by browsing the history. Creating .gitignore before the first push ensures sensitive files like .env.local never enter the repository at all.

This is the number one security mistake AI app builders make: pushing secrets to a public repo, then deleting the file. The secret is still in the Git history forever.

• Save .gitignore by pressing Cmd+S (macOS) or Ctrl+S (Windows).

Why does LOVABLE.md work?

Lovable reads instruction files (like LOVABLE.md, AGENTS.md, or CLAUDE.md) from your repository alongside Project Knowledge on every request. By placing security rules in this file, every future prompt inherits those guardrails automatically.

This is the same governance pattern production teams use to prevent AI tools from introducing security regressions. The file lives in version control, so any changes to the rules are tracked in commit history.

• Save the file by pressing Cmd+S (macOS) or Ctrl+S (Windows).

Now reconnect GitHub with tighter permissions so Lovable can only access this specific project.

• Return to the Git tab in Lovable Settings.
• Click Add account.
• In the GitHub popup, choose your personal account.
• Select Only select repositories this time (not All repositories).
• Leave the repository selector empty. Lovable creates a fresh repository for you.
• Click Install & Authorize.

Lovable creates a new repository and pushes all your project files including LOVABLE.md. The security guardrails are now baked into the repo from the first commit.

• Open github.com and confirm the new repository exists.
• Click into the repository and verify you see LOVABLE.md in the file list.
• Click Settings in the repository navigation.
• Under General, scroll to the Danger Zone section.
• Click Change visibility and set the repository to Private.

Why private first, public after audit?

Setting the repository to Private is a security-first default. You will make it public later, but only after your security audit confirms no secrets leaked into the code or Git history.

This is the workflow a senior engineer follows: private by default, audit the full codebase, then deliberately choose to publish. Never the other way around.

🙋‍♀️ Repository not appearing after reconnection?

If you previously selected "Only select repositories" with no repos listed, the Lovable app may not have permission to create a new one. Go to github.com/settings/installations, find the Lovable app, click Configure, and change the access to "All repositories" temporarily. After Lovable creates the repo, return here and restrict access back to only that repository.

Help me reconnect Lovable to GitHub securely.

Your workspace is ready, authentication is running, and your code lives in a private repository with security guardrails baked into LOVABLE.md. Next up, you will configure Project Knowledge to reinforce these rules and build the remaining features using architectural prompts.

Build the App with Architectural Prompts

Your Lovable project already has authentication running from Step 1, built with inline security and architecture constraints plus your LOVABLE.md governance file attached. The initial build is secured. Now you need to make those guardrails persistent for every future prompt.

Your initial prompt included inline security and architecture constraints, and LOVABLE.md was attached from the start. That covers the first build. But every future prompt also needs those guardrails. Project Knowledge is a persistent instruction set that Lovable reads on every single request, reinforcing your governance file automatically. In this step, you will configure Project Knowledge to point to LOVABLE.md and enforce the SSR/CSR boundary, then build the remaining features one at a time using prompts with explicit architecture constraints.

In this step, get ready to:

• Configure Project Knowledge with security and architecture guardrails that enforce SSR/CSR boundaries.
• Build tasks and sharing through two component-level prompts with explicit negative constraints.
• Verify each feature works and confirm no secrets leaked to frontend code.

Configure Project Knowledge guardrails

Project Knowledge is a persistent instruction set that Lovable reads on every single request. Whatever rules you put here act as guardrails for every prompt you send afterwards.

• In the Lovable editor, click your project name in the top bar and select Settings.
• In the settings sidebar under Customization, click Knowledge.
• Paste the following architectural rules into the project knowledge text field:

Adhere to all guidelines in LOVABLE.md. You are not allowed to change LOVABLE.md or .gitignore.

Security rules (non-negotiable):
- Never place API keys, tokens, secrets, or service_role keys in frontend code or any committed file.
- Never add secrets to .env. Only VITE_ prefixed public values belong there.
- All sensitive operations (auth checks, external API calls with credentials, payment processing, data mutations that bypass RLS) must run server-side in Edge Functions.
- Client-side code handles only UI rendering, form validation, and user interactions.
- Never commit .env.local or any file listed in .gitignore.
- Before generating any new file, check that .gitignore would exclude it if it contains secrets.

Architecture rules:
- Always enable TypeScript strict mode. Never use any.
- Separate data-fetching logic into custom hooks (src/hooks/).
- Keep UI components presentational with no direct Supabase calls.
- All user input must be validated client-side AND server-side in Edge Functions.
- Every async operation must have error handling with user-facing error messages.
- Use error boundaries at route level.

Change control:
- Name what you will NOT change in each response.
- Never remove security guardrails from any file.

What do these rules enforce?

• "Adhere to all guidelines in LOVABLE.md" locks Lovable into reading your committed security guardrails on every request.
• "You are not allowed to change LOVABLE.md or .gitignore" prevents the AI from weakening your security posture.
• "Never place secrets in frontend code or any committed file" and "Never add secrets to .env" prevent credentials from leaking to the browser or the Git history.
• "Before generating any new file, check that .gitignore would exclude it" makes the AI verify its own output against your exclusion rules.
• "All user input must be validated client-side AND server-side" enforces defense-in-depth. Frontend validation improves UX. Server-side validation prevents bypass via direct API calls.
• "Name what you will NOT change" makes Lovable declare its boundaries in each response, preventing unintended edits to existing features.

Together with LOVABLE.md and .gitignore from Step 1, you now have three reinforcing layers: a version-controlled governance file, a gitignore preventing secret leaks, and a Project Knowledge instruction set that points to both.

Lovable saves automatically. You should see your text preserved in the Knowledge field.

This costs zero credits

Editing Project Knowledge is a settings change. It does not consume a credit. Only Build mode prompts and Plan mode messages cost credits.

💡 Write prompts in a text file first

You have 5 daily credits and this project uses 3-4 of them. Write each prompt in a text editor before pasting it into Lovable. No exploratory or throwaway prompts. Every prompt must count.

Build tasks and sharing features

With authentication working, you will now send two more prompts. Each one targets a single feature, names the exact hook and component structure, and protects everything already built with a negative constraint.

• Paste the following prompt into the chat pane and send it:

Add a tasks feature. Create a custom hook useTasks in src/hooks/useTasks.ts that handles all Supabase queries for tasks (create, read, update status, delete). Create presentational components: TaskList, TaskCard, and TaskForm in src/components/tasks/. TaskForm must validate title (1-200 characters) and description (under 1000 characters) before submission, showing inline validation errors. The dashboard page composes these components and passes data via props. Do not modify authentication.

Why name the exact file paths?

By specifying src/hooks/useTasks.ts and src/components/tasks/ explicitly, you force Lovable to create the separation of concerns your guardrails demand. Without these paths, Lovable often inlines data fetching directly inside page components.

• Wait for Lovable to finish generating (15-30 seconds).
• In the live preview, sign up with a test email and password, then log in.
• Create a task by filling in a title and description. You should see the new task appear in your task list.
• Try submitting a task with an empty title. You should see an inline validation error.

Tasks not appearing after creation?

If you can submit the form but tasks do not appear in the list, Lovable may not have wired up the read query in the hook. Send a follow-up prompt: "Tasks are not appearing after creation. Please fix the useTasks hook to refetch the task list after a successful create." This counts as fixing the same feature, not adding a new one.

Help me fix my tasks feature

Now send the final prompt to add task sharing.

• Paste the following prompt into the chat pane and send it:

Add task sharing. Create a useTaskSharing hook in src/hooks/useTaskSharing.ts. Add a ShareTaskDialog component that accepts an email address, validates email format before calling the backend, and shows a clear error if the user does not exist. Shared tasks appear in the recipient's task list with a 'shared with me' indicator. Do not modify the auth flow or task CRUD components.

What does the negative constraint protect?

"Do not modify the auth flow or task CRUD components" prevents Lovable from refactoring your existing working code while adding the new feature. Without this constraint, Lovable sometimes reorganizes files or renames variables in unrelated components, introducing bugs.

• Wait for Lovable to finish generating.
• In the preview, open a task you created and look for a share button or option.
• Click share and enter a test email address. You should see either a success confirmation or an error message if the user does not exist.

Before you move on, take a moment to predict what you will see in the Code tab. Do you think the files will follow the hook and component structure you specified?

• Click the Code tab in the project toolbar at the top of the editor.
• Expand the src/hooks/ folder. You should see useTasks.ts and useTaskSharing.ts.
• Expand src/components/tasks/. You should see TaskList, TaskCard, TaskForm, and ShareTaskDialog component files.

That file structure is your guardrails in action. Your prompts enforced the architecture that Lovable would not have created on its own.

Files not in the expected folders?

If Lovable placed hooks or components in different locations, it means the prompt constraints were partially ignored. You can fix this by sending a follow-up prompt: "Move useTasks.ts and useTaskSharing.ts to src/hooks/. Move TaskList, TaskCard, TaskForm, and ShareTaskDialog to src/components/tasks/." This reorganization does not count as building a new feature.

Help me fix my file structure

You have a working full-stack app built entirely through architectural prompts, within your free credit budget. Next, you will pull this code locally and audit it like a senior engineer reviewing AI output before production.

Audit the Generated Code and Document Findings

Your task manager app is live in Lovable with authentication, task CRUD, and team sharing. You spent 3 credits building it through architectural prompts with project knowledge guardrails.

Having working code is not enough for an interview. You need to prove you can critically evaluate AI-generated output before it ships to production. In this step, you will pull the code locally, run a structured audit, and produce a written report that demonstrates your methodology.

In this step, get ready to:

• Clone your GitHub repository and open it in VS Code.
• Run a 10-point security and architecture audit against the generated code.
• Create a code review report documenting security findings and architectural wins.

Clone the repository and open it locally

Everything from this point on happens locally in VS Code. No Lovable credits needed. Your GitHub repo already has the full app code synced from Lovable.

• Open a terminal and move to your Desktop by running this command:

cd ~/Desktop

• Clone your GitHub repository by running this command:

git clone [[YOUR_REPO_URL="https://github.com/your-username/your-lovable-repo.git"]]

• Move into the cloned folder by running:

cd [[REPO_FOLDER="your-lovable-repo"]]

• Confirm the project files are present by running:

ls src/hooks/ src/components/tasks/

You should see useTasks.ts and useTaskSharing.ts in the hooks folder, and TaskList, TaskCard, TaskForm, and ShareTaskDialog in the tasks folder.

Not seeing the hooks or components folders?

Make sure your Lovable project finished syncing to GitHub before you cloned. Return to your Lovable project editor, open the Git tab in settings, and confirm the last sync was successful. Then pull the latest changes with git pull.

Help me troubleshoot my missing Lovable files

• Open the project in VS Code by running:

code .

VS Code opens with your full project file tree visible in the Explorer sidebar.

Run the 10-point security and architecture audit

A senior engineer reviewing AI-generated code does not read every line top to bottom. Instead, they run targeted checks against the patterns that AI tools commonly get wrong. Your audit uses six checkpoints.

What is this audit checklist?

• TypeScript strictness: search for any usage and check tsconfig.json for strict settings.
• Separation of concerns: verify hooks exist in src/hooks/ and components are presentational.
• Error handling: check every async call has try/catch with user-facing messages.
• Input validation: verify form submissions validate before calling the backend.
• Secrets scanning: search for hardcoded API keys, tokens, service_role keys, or any credential in frontend files.
• SSR/CSR boundary: verify auth checks and sensitive data operations run in Edge Functions, not in React components.
• Environment variable hygiene: confirm only VITE_ prefixed public values exist in .env and no private keys are committed.
• .gitignore verification: confirm .gitignore exists at the repo root and excludes .env.local, .env*.local, and node_modules/.
• Git history scan: search past commits for accidentally committed secrets that were later deleted.
• RLS: note that Lovable sets up basic RLS automatically but it needs manual review for production access control.

• Start with TypeScript strictness. Press Cmd+Shift+F (macOS) or Ctrl+Shift+F (Windows) to open global search in VS Code.
• Type : any in the search field and press Enter.

If your project knowledge guardrails worked, you should see zero or very few results. Each match is an instance where Lovable ignored your "never use any" rule. Note the file and line number of each match.

• Open tsconfig.json from the Explorer sidebar. Look for "strict": true in the compiler options.

If strict mode is enabled, TypeScript catches type errors at compile time. This is your first guardrail win to document.

• Check separation of concerns next. In the Explorer sidebar, expand src/hooks/ and confirm useTasks.ts and useTaskSharing.ts exist.
• Open src/components/tasks/TaskList.tsx (or the .tsx equivalent). Search inside this file for supabase using Cmd+F (macOS) or Ctrl+F (Windows).

A presentational component should have zero direct Supabase imports. If you find any, that is a guardrail failure to document in your report.

• Check error handling. Open src/hooks/useTasks.ts and look for try and catch blocks around each Supabase query.
• Check input validation. Open TaskForm and verify it checks title length (1-200 characters) and description length (under 1000 characters) before calling the hook.
• Check secrets scanning. Run a global search for service_role, sk-, secret, and password. Any match in a .tsx or .ts file (outside .env) is a critical finding.
• Check SSR/CSR boundary. Search for supabase in component files. Any direct Supabase call with elevated permissions (service_role) in a React component means sensitive logic leaked to the browser.
• Check environment variables. Open .env and confirm it only contains VITE_ prefixed values (public Supabase URL and publishable key). No private keys should be present.

• Check .gitignore exists. Open .gitignore from the Explorer sidebar. Confirm it lists .env.local, .env*.local, and node_modules/.
• Scan Git history for leaked secrets. Run this command in your terminal:

git log --all --full-history -p | grep -i -E "(service_role|sk-|secret_key|password=|PRIVATE_KEY)" | head -20

If this returns any matches, a secret was committed at some point in the history. Even if the file was later deleted, it remains recoverable. Zero matches is the target.

What about RLS?

Lovable sets up basic Row Level Security policies automatically. For this audit, note that RLS exists but flag it as needing manual review. A full RLS audit is Day 2 scope (the security hardening project).

The key thing to document: basic RLS is a starting point, not a production-ready security layer.

You now have findings across all six checkpoints. Keep your notes handy for the next substep.

Create your code review report

Your audit findings need structure to serve as an interview artifact. You will create a markdown file with sections that demonstrate both your methodology and your specific findings.

• Create a new file called code-review-report.md in the root of your project by running:

touch code-review-report.md

• Confirm the file exists by running:

ls code-review-report.md

You should see code-review-report.md listed in the output.

• Open code-review-report.md in VS Code and paste Sections 1 and 2 of your report, filling in specifics from your audit:

# Code Review Report: AI-Generated Task Manager

## 1. Methodology

Audit checklist applied to Lovable-generated React/TypeScript code:

1. **TypeScript strictness** - Searched for `any`, checked tsconfig.json
2. **Separation of concerns** - Verified hooks in src/hooks/, presentational components
3. **Error handling** - Checked async calls for try/catch with user-facing messages
4. **Input validation** - Verified pre-submission validation in forms
5. **Secrets scanning** - Searched for hardcoded keys, tokens, credentials in frontend
6. **SSR/CSR boundary** - Verified sensitive operations in Edge Functions, not browser
7. **Environment variable hygiene** - Confirmed .env contains only VITE_ public values
8. **RLS** - Noted automatic setup, flagged for manual review

## 2. Security Architecture Findings

- **SSR boundary respected**: No service_role keys or elevated-permission Supabase calls found in React components.
- **Secrets clean**: Global search for `service_role`, `sk-`, `secret`, `password` returned zero matches in frontend .tsx/.ts files.
- **Environment variables safe**: .env contains only VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY (public, safe to commit).
- **LOVABLE.md enforced**: Governance file present at repo root preventing secrets in frontend code.

## 3. What Guardrails Enforced Correctly

- **Custom hooks**: useTasks.ts and useTaskSharing.ts contain all Supabase queries. No direct database calls in UI components.
- **TypeScript strict mode**: tsconfig.json has strict enabled. Zero (or minimal) uses of `any` found.
- **Input validation**: TaskForm validates title (1-200 chars) and description (under 1000 chars) before submission.
- **Error boundaries**: Auth routes wrapped in error boundaries.
- **Error handling**: Async operations in hooks use try/catch blocks.

What do these sections do?

Section 1 establishes your repeatable methodology. An interviewer reading this sees that you have a structured process, not ad-hoc browsing.

Section 2 proves that your guardrails produced real, measurable results. Replace any placeholder examples with the actual patterns you found during your audit. Reference specific file names and line numbers where possible.

• Save the file and preview it by pressing Cmd+Shift+V (macOS) or Ctrl+Shift+V (Windows) to open Markdown preview.

You should see your report rendered with a clear heading, numbered methodology list, and bullet points for guardrail wins.

• Switch back to the editor view and add Sections 3, 4, and 5 below your existing content:

## 4. What Still Needs Attention

Common AI-generated code issues found despite guardrails:

- **No server-side input sanitization**: Validation exists client-side only. A malicious user can bypass frontend checks via direct API calls.
- **Basic RLS policies**: Lovable sets up automatic RLS but policies need manual review to ensure row-level isolation matches business requirements.
- **No rate limiting**: No throttling on API calls. A bad actor could spam the task creation endpoint.
- **Auth token handling**: Verify tokens are validated server-side on every request, not just on initial login.
- **No CSP headers**: Missing Content-Security-Policy headers that would prevent XSS attacks in production.

## 5. Recommendations Before Production

1. **Server-side validation via Edge Functions** - Move input sanitization to Supabase Edge Functions so it cannot be bypassed.
2. **Manual RLS review** - Audit every policy against actual access requirements. Ensure users cannot access other users' data.
3. **Rate limiting** - Add request throttling at the Edge Function layer.
4. **Security headers** - Configure CSP, X-Frame-Options, and HSTS before deploying.
5. **Secrets rotation** - Rotate any keys that were ever exposed during development.

## 6. Architecture Comparison: Guardrailed vs. Default

| Pattern | Without Guardrails (Default) | With Security Guardrails |
|---------|------------------------------|-------------------------|
| Secrets | Hardcoded in frontend files | Stored in Edge Function secrets |
| Auth checks | Client-side only | Edge Functions (SSR) |
| Data fetching | Mixed into UI components | Isolated in custom hooks |
| TypeScript | Loose, uses `any` freely | Strict mode, no `any` |
| Error handling | Often missing on async ops | try/catch with user messages |
| Sensitive logic | Runs in browser (CSR) | Runs server-side (SSR) |
| Repo hygiene | .env with secrets committed | Only VITE_ public values |

Why document what is still wrong?

Section 3 shows the interviewer you understand that guardrails reduce problems but do not eliminate them. Listing specific gaps proves you know what a production-ready app actually requires beyond what AI generates.

Section 5 demonstrates your ability to compare and predict AI behavior. You did not waste credits building a version without guardrails. You know these default patterns from your React experience and from understanding how AI generators work without constraints.

💡 Why this report wins interviews

Most candidates say "I used AI to build an app." Your report proves three things interviewers value: you set governance before generation (LOVABLE.md attached to the first prompt), you have a repeatable methodology (10-point checklist), and you can articulate what the AI got wrong despite your guardrails (Section 4).

The comparison table (Section 6) is your strongest visual artifact. It shows the interviewer that you understand the default failure modes of AI-generated code and can quantify the improvement your governance approach produces. Point to it when asked "What value do you add on top of the AI?"

• Save code-review-report.md.
• Review your completed report in Markdown preview. You should see all five sections rendered with clear headings and a comparison table at the bottom.

Customize with your actual findings

The template above covers the most common patterns. Replace any generic examples with the specific files, line numbers, and patterns you found during your audit. The more specific your report, the stronger it reads in an interview.

✔️ Awesome, I've got everything!

Great. Make sure you have saved code-review-report.md and that all five sections are present.

ⓧ I'd like to double check the full code

Scroll through your file and confirm these sections appear in order:

• Section 1: Methodology (6-point numbered checklist).
• Section 2: What Guardrails Enforced Correctly (bullet list of specific wins).
• Section 3: What Still Needs Attention (5 bullet points of gaps).
• Section 4: Recommendations Before Production (4 numbered items).
• Section 5: Guardrailed vs. Default Lovable Output (comparison table with 5 rows).

Before you commit, what do you expect to see when you push this to GitHub? Think about what the repo will look like with this new file added.

• Commit and push your report to GitHub by running these commands:

git add code-review-report.md
git commit -m "Add structured code review report"
git push

• Open your GitHub repository in the browser. You should see code-review-report.md in the file list with your commit message visible.

Push rejected or permission denied?

If git asks for authentication, make sure you are using your GitHub credentials or a personal access token. If the push is rejected because the remote has newer commits (from Lovable syncing), run git pull --rebase first, then try git push again.

Help me fix my git push error

Your code review report is committed and visible on GitHub. In the next step, you will turn these findings into a prompt playbook and interview talking points that tie everything together.

Write the Prompt Playbook and Interview Talking Points

You have a working app and a code review that proves you can evaluate AI output critically. That is half the story.

The other half is showing a repeatable methodology for getting production-quality code from Lovable in the first place. This step creates two documents that turn your experience into teachable frameworks: a prompt playbook and interview talking points. These are your interview artifacts.

In this step, get ready to:

• Create a prompt playbook documenting your architectural patterns.
• Write interview talking points with evidence-backed answers to seven key questions covering security, architecture, code review, data migration, and ongoing maintenance.
• Commit all artifacts to GitHub, make the repository public, and practice your verbal delivery.

Create the prompt playbook

The playbook documents the patterns that produced your app. Anyone reading it should be able to replicate your approach on a different project.

• In VS Code, create a new file called prompt-playbook.md in the root of your project folder.
• Start with the Principles section by pasting the following:

# Prompt Playbook

## 1. Principles

- **Governance before generation.** Attach LOVABLE.md and include inline security/architecture constraints in the very first prompt. Never generate code and retrofit security after the fact.
- **Three-axis prompting.** Every build prompt operates on three axes: Security constraints (what must never happen), Architecture constraints (where code lives), and Behavior specs (what the user sees).
- **One change per prompt.** Lovable's single most important habit. Make one change, verify in the preview, then move on.
- **Sensitive operations stay server-side.** Auth checks, external API calls with credentials, and data mutations that bypass RLS run in Edge Functions only. React handles UI and form validation.
- **Name boundaries.** Every prompt states what will NOT be modified ("Do not modify authentication"). This prevents the AI from refactoring working code while adding new features.
- **Never commit secrets.** No API keys, tokens, or credentials in frontend code or the repository. Only VITE_ public values in .env.
- **Verify after each prompt.** Check the preview, Code tab, and search for leaked secrets before sending the next prompt.
- **Defense in depth.** LOVABLE.md + Project Knowledge + .gitignore + private-by-default repo + post-build audit. No single layer is sufficient alone.

What does this section do?

Each principle maps to a mistake that wastes credits. "One change per prompt" prevents tangled output. "Set guardrails first" prevents default-quality code. "Name boundaries" prevents Lovable from refactoring working features. "Verify after each prompt" catches issues before they compound.

• Below the Principles section, add the Prompt Patterns section with your three reusable templates:

## 2. Prompt Patterns

### Pattern A: Authentication Flow (Initial Build)

Build the authentication flow: sign-up and login pages using Supabase Auth with email/password.

Security constraints:
- Never place API keys, tokens, or secrets in frontend code or committed files.
- Authentication validation must happen server-side via Supabase Auth, not custom client-side logic.
- Do not store sensitive values in any environment variable that gets bundled into the frontend build.
- Only VITE_ prefixed public values (Supabase URL, anon key) belong in .env.

Architecture constraints:
- Separate auth logic into a custom hook (src/hooks/useAuth.ts).
- Keep UI components presentational in src/components/auth/ with no direct Supabase calls.
- Use TypeScript strict mode. Never use the any type.
- Add an error boundary wrapping the auth routes.
- Every async operation must include try/catch with a user-facing error state.

Behavior:
- Include loading states for all async operations.
- Form validation: email format check and password minimum 8 characters.
- User-facing error messages for failed auth attempts (wrong password, user not found, network error).

Refer to the LOVABLE.md file in the repository root for full security, architecture, and system design guardrails. Do not modify LOVABLE.md.

Do not build any other features yet. Do not create any other pages or routes beyond auth.

### Pattern B: Feature with Data Hook

Add a [feature] feature. Create a custom hook use[Feature] in src/hooks/use[Feature].ts that handles all Supabase queries for [feature] (create, read, update, delete). Create presentational components: [Component]List, [Component]Card, and [Component]Form in src/components/[feature]/. [Component]Form must validate [field] ([rule]) before submission, showing inline validation errors. The dashboard page composes these components and passes data via props. Do not modify [previous feature].

### Pattern C: Cross-User Feature

Add [cross-user feature]. Create a use[Feature] hook in src/hooks/use[Feature].ts. Add a [Dialog]Dialog component that accepts [input], validates [format] before calling the backend, and shows a clear error if [failure condition]. [Result description]. Do not modify the [previous features].

Why are these templates useful?

Each template encodes the same structure: explicit scope, named file paths, validation rules, and a negative constraint. The brackets show where to substitute for your next project. When an interviewer asks how you prompt, you point to these templates instead of giving a vague answer.

• Save prompt-playbook.md and confirm the file appears in your VS Code Explorer sidebar.
• Now add the remaining three sections (Knowledge Configuration, Anti-patterns, and Platform Features) below your Prompt Patterns:

## 3. Knowledge Configuration Template

Adhere to all guidelines in LOVABLE.md. You are not allowed to change LOVABLE.md.

Always enable TypeScript strict mode. Never use any. Separate data-fetching logic into custom hooks (src/hooks/). Keep UI components presentational with no direct Supabase calls. All user input must be validated before submission. Every async operation must have error handling with user-facing error messages. Use error boundaries at route level.

Never place API keys, tokens, or secrets in frontend code. All sensitive operations (auth checks, external API calls with credentials, payment processing, data mutations that bypass RLS) must run server-side in Edge Functions. Client-side code handles only UI rendering, form validation, and user interactions. Never commit secrets to the repository.

Name what you will NOT change in each response.

## 4. Security Anti-patterns to Prevent

- **Secrets in frontend**: API keys hardcoded in React components or committed to the repo.
- **Auth in the browser**: Authorization decisions made client-side where they can be bypassed.
- **Missing SSR boundary**: Sensitive logic running in CSR instead of Edge Functions.
- **No governance file**: No LOVABLE.md to prevent the AI from modifying security-critical code.
- **Multi-feature prompts**: Collapse into untangleable changes that break existing security patterns.
- **No boundary statements**: Causes Lovable to refactor existing secure features.

## 5. Platform Features

- **Plan mode**: Discuss and scope changes without touching code. Costs 1 credit per message.
- **Build mode**: Implements changes directly in your project. Usage-based cost.
- **Version history**: Every change saved automatically. Restore any version if a prompt introduces a security issue.
- **LOVABLE.md**: Governance file read on every request. Defines SSR/CSR boundaries, forbidden modifications, and coding standards.
- **Project Knowledge**: Persistent instruction set reinforcing LOVABLE.md. Prioritized over other instruction sources.

What does this section do?

Section 3 gives a copy-paste-ready knowledge config for any new Lovable project. Section 4 lists the mistakes you avoided. Section 5 shows you understand the platform beyond just typing prompts. Together they demonstrate breadth of platform knowledge.

• Save prompt-playbook.md.

✔️ Awesome, I've got everything!

Great. Confirm the file is saved and move on to the talking points.

ⓧ I'd like to double check the full code

Scroll up and confirm your prompt-playbook.md contains these sections in order:

• Heading: Prompt Playbook.
• Section 1: Principles (four bullet points).
• Section 2: Prompt Patterns (Patterns A, B, C).
• Section 3: Knowledge Configuration Template (your project knowledge text).
• Section 4: Anti-patterns (four bullet points).
• Section 5: Platform Features (Plan mode, Build mode, Version history, Skills).

File not showing in Explorer?

Make sure you created the file in the root of your project folder, not inside src/ or another subdirectory. The file should sit alongside your code-review-report.md from the previous step.

Help me find my prompt-playbook.md file

Create the interview talking points

The talking points translate your hands-on experience into concise, evidence-backed answers to the three questions most likely to come up in your interview.

• Create a new file called talking-points.md in the root of your project folder.
• Add the first two interview questions and their answers:

# Interview Talking Points

## Question 1: How do you ensure security when using AI app builders like Lovable?

**Before any code exists**, I establish governance. I generate a LOVABLE.md file using Claude that defines SSR/CSR boundaries, secrets management rules, repository hygiene standards, and architecture patterns. I attach this file to the very first Lovable prompt so the AI reads it while generating the initial codebase. I also create .gitignore before the first commit so no secrets can enter Git history.

**During the build**, I include inline security constraints in every prompt ("Never place secrets in frontend code", "Auth validation must happen server-side via Supabase Auth"). I verify after each prompt that no secrets leaked to frontend code, that sensitive logic stays server-side in Edge Functions, and that the hook/component separation is maintained.

**After the build**, I run a 10-point security audit: TypeScript strictness, separation of concerns, error handling, input validation, secrets scanning, SSR/CSR boundary verification, environment variable hygiene, .gitignore verification, Git history scan for leaked secrets, and RLS policy review. Only after the audit passes do I change the repository from private to public.

**Key insight for the interviewer**: The difference between a junior and senior approach is timing. A junior developer builds first and audits later. A senior engineer sets governance before generation, enforces it during generation, and verifies it after generation. The cost of retrofitting security is 10x the cost of building it in from the start.

## Question 2: Walk me through how you would build a new feature in Lovable.

First, I verify my governance layer is active: LOVABLE.md exists in the repo, Project Knowledge references it, and the .gitignore prevents secrets from entering history.

Then I write a single Build prompt that operates on three axes:
1. **Security constraints** — what must never happen (no secrets in frontend, no client-side auth decisions).
2. **Architecture constraints** — where code lives (custom hook path, component directory, TypeScript strict mode).
3. **Behavior specs** — what the user sees (validation rules, error messages, loading states).

I end every prompt with a negative constraint naming what must NOT be modified ("Do not modify authentication"). This prevents Lovable from refactoring working features while adding new ones.

After Lovable generates, I verify: preview works end-to-end, Code tab confirms hook/component structure matches my prompt, global search for secrets returns zero matches. Only then do I move to the next feature.

What makes these answers strong?

Each answer follows a before/during/after structure with evidence trails. They reference specific artifacts (LOVABLE.md governance file, the 10-point audit checklist, the three-axis prompting pattern) rather than speaking in generalities.

The key differentiator: you can point to your public GitHub repository as proof of every claim. The governance file, the code structure, the audit report, and the prompt playbook are all visible. An interviewer can follow up on any claim and find the evidence in your repo.

• Save talking-points.md and confirm it appears in the Explorer.
• Now add the third question below your existing content:

## Question 3: What are the security risks of AI-generated code and how do you mitigate them?

**Risk 1: Secrets in the repo.** Without governance, the AI hardcodes API keys in frontend files that get pushed to GitHub. Once committed, they exist in Git history forever even if the file is deleted.
- Mitigation: LOVABLE.md forbids secrets in frontend code. .env contains only VITE_ public values. .gitignore blocks .env.local before first commit. Post-build scan for leaked credentials.

**Risk 2: Sensitive logic in CSR.** AI tools default to running everything client-side where users can inspect source, replay requests, and bypass authorization.
- Mitigation: Project Knowledge enforces that auth checks, payment processing, and external API calls with credentials run in Edge Functions (SSR) only. Post-build audit searches for elevated-permission Supabase calls in React components.

**Risk 3: Default-permissive RLS.** Lovable sets up basic Row Level Security automatically, but policies may allow users to access other users' data.
- Mitigation: Dedicated RLS audit checking that every table restricts access to the owning user, with shared data explicitly whitelisted via policies.

**Risk 4: Missing server-side validation.** Frontend validation is bypassable via curl, Postman, or browser DevTools. If the backend trusts client input, injection attacks succeed.
- Mitigation: Edge Functions validate all inputs independently. LOVABLE.md requires "All user input must be validated client-side AND server-side."

**Risk 5: Over-permissive GitHub access.** Lovable's default setup requests All repositories access, giving the AI agent read/write to every repo on your account.
- Mitigation: Delete the default repo, restrict to Only select repositories, make new repo private, add governance file from first commit. Only make public after audit passes.

**Risk 6: Stale dependencies and known CVEs.** AI generators pin whatever version was current at training time, which may have known vulnerabilities by the time you deploy.
- Mitigation: Run npm audit after cloning. Flag any high/critical CVEs. Pin major versions and test upgrades before production.

## Question 4: How do you architect the SSR/CSR boundary in a Lovable project?

**CSR (React components)** handles: UI rendering, form inputs, client-side validation (format checks, required fields), visual state management, optimistic updates, and reading only from VITE_ environment variables.

**SSR (Edge Functions)** handles: authentication and session validation, authorization decisions, external API calls that require secret keys, payment processing, database queries that bypass RLS (service_role), webhook handlers, email sending, PII transformations, and rate limiting.

**The decision rule**: If the operation would cause damage if a user inspected or replayed it from the browser console, it belongs in an Edge Function. I enforce this through three layers:
1. LOVABLE.md defines the boundary in version-controlled prose.
2. Project Knowledge reinforces it on every prompt.
3. Post-build audit searches for Supabase imports with elevated permissions in React components.

**Interview-ready example**: "In my task manager app, the task CRUD hook calls Supabase with the anon key (safe for CSR because RLS restricts access to the authenticated user). But if I needed to send an email notification when a task is shared, that would require an email API secret — so it must run in an Edge Function, never in a React component."

• Save talking-points.md and add the final three questions covering code review, data migration, and ongoing maintenance:

## Question 5: How do you review AI-generated code before launch?

I run a 10-point audit checklist:

1. **TypeScript strictness** — Search for `any` usage, verify tsconfig.json has strict enabled.
2. **Separation of concerns** — Verify hooks in src/hooks/, components are presentational with no direct Supabase calls.
3. **Error handling** — Every async call has try/catch with user-facing messages.
4. **Input validation** — Forms validate before submission (client-side) AND Edge Functions validate independently (server-side).
5. **Secrets scanning** — Global search for hardcoded keys, tokens, service_role, sk-, password in frontend files.
6. **SSR/CSR boundary** — No elevated-permission Supabase calls in React components.
7. **Environment variable hygiene** — .env contains only VITE_ prefixed public values.
8. **.gitignore verification** — Exists at repo root, excludes .env.local, .env*.local, node_modules/.
9. **Git history scan** — `git log --all -p | grep -i` for secrets that were committed then deleted.
10. **RLS policy review** — Note automatic setup, flag for manual review of row-level isolation.

I document findings in a structured code-review-report.md with: methodology, security findings, architectural wins, gaps that need attention, production-readiness recommendations, and a guardrailed vs. default comparison table.

**Key differentiator**: I do not read every line top-to-bottom. I target the patterns AI tools commonly get wrong. This is faster and catches more real issues than a line-by-line review.

## Question 6: How do you handle data migration security?

Data migration has three security dimensions:

**Data in transit**: Encrypted connections (TLS/SSL) for all database transfers. Never plain-text exports over unencrypted channels. Migration scripts run in Edge Functions or secure server environments, never from a browser. Use pg_dump with --host over SSL, not unencrypted local sockets.

**Data at rest**: Validate data integrity with checksums before and after migration. PII fields are identified and access-controlled at the RLS level from the moment they enter the new system. Never store migration dumps in the repository or in publicly accessible storage (S3 buckets must be private with IAM-scoped access).

**Rollback safety**: Maintain a pre-migration snapshot and test the rollback procedure before running production migration. Every migration is idempotent so it can be safely re-run if interrupted. Use database transactions so partial migrations don't leave data in an inconsistent state.

**Supabase-specific**: Use Supabase's built-in backup/restore for Postgres. For schema migrations, use the migrations directory with timestamped SQL files. Never run ALTER TABLE directly in production without a tested rollback script.

## Question 7: How do you ensure ongoing security and reliability after launch?

Ongoing security is a system with four layers:

1. **Automated monitoring**: Alerts for authentication failures (brute force detection), unusual API call patterns (rate spike = potential DDoS or credential stuffing), error rate increases, and Edge Function timeout/failure rates.

2. **Dependency management**: Weekly npm audit review. Pin major versions. Test upgrades in a staging Lovable project before production. Subscribe to Supabase security advisories. Rotate API keys on a documented schedule (quarterly minimum).

3. **Access control review**: Quarterly audit of RLS policies against actual usage patterns. Review GitHub repository permissions and Lovable app installation scope. Verify no new VITE_ variables have appeared that should be secrets. Check that service_role key hasn't been accidentally exposed.

4. **Incident response playbook**: Document the escalation path. Know how to: rotate a compromised anon key (Supabase dashboard > Settings > API), revoke all user sessions (update JWT secret), disable an Edge Function (remove from deployment), and roll back to a previous version (Lovable version history or git revert).

**Interview-ready statement**: "Security isn't a gate you pass once. It's an ongoing discipline. My governance file, automated scans, and quarterly reviews create a system that catches drift before it becomes a breach."

Why are these the strongest questions to prepare for?

Questions 3-4 cover security risks and architecture. These prove you think in systems, not just features. Each risk maps directly to something in your code review report or LOVABLE.md governance file. The SSR/CSR boundary answer shows you understand where trust boundaries live in a modern web application.

Questions 5-7 cover the full lifecycle: code review before launch, data migration security, and ongoing maintenance. They show you can handle everything from pre-launch audit through production operations. The incident response section in Question 7 is especially strong because most junior candidates have never thought about key rotation or session revocation.

Together, these seven questions cover every phase a senior Lovable engineer encounters: initial governance setup, feature development, pre-launch audit, data handling, and production operations.

• Save talking-points.md.

✔️ Awesome, I've got everything!

Great. Your talking points file is ready. Move on to committing.

ⓧ I'd like to double check the full code

Scroll up and confirm your talking-points.md contains:

• Heading: Interview Talking Points.
• Question 1: How do you ensure code quality when using Lovable? (before/during/after structure).
• Question 2: Walk me through how you would build a new feature in Lovable? (Plan mode, Build prompt, verify structure).
• Question 3: What are the risks of AI-generated code and how do you mitigate them? (five risks with mitigations).

Not sure about your answers?

These talking points are templates. Replace or extend any section with specifics from your own code review. The more you reference actual file paths (src/hooks/useTasks.ts, src/components/tasks/TaskForm) in your spoken answers, the more credible they sound.

Help me refine my interview answers

Commit all artifacts and practice delivery

Your three interview documents are ready locally. Pushing them to GitHub makes them accessible and proves you did the work.

• In the VS Code terminal, stage and commit all three files by running:

git add prompt-playbook.md talking-points.md code-review-report.md
git commit -m "Add prompt playbook and interview talking points"

• Push to GitHub by running:

git push

Before you check GitHub, what do you expect to see in the repository? Think about which files should appear at the root level alongside the app source code.

• Open your GitHub repository in the browser.
• Confirm you see prompt-playbook.md, talking-points.md, and code-review-report.md listed at the repository root alongside your app source files.

Files not showing on GitHub?

If git push failed, check that your local branch matches the remote branch name. Run git status to see if there are uncommitted changes, and git remote -v to confirm the remote URL points to your repository.

Help me debug my git push

• Now practice your verbal delivery. Set a 2-minute timer and answer Question 1 out loud from memory.
• Reset the timer and answer Question 3 (security risks) out loud.
• Reset the timer and answer Question 5 (code review before launch) out loud.
• Reset the timer and answer Question 7 (ongoing security) out loud.

Keep your answers under 2 minutes

If you run over, cut the weakest risk from Question 3 or trim the "after" section of Question 1. Interviewers want crisp structure, not exhaustive lists. You can always offer to go deeper if they ask a follow-up.

Make your repository public

Your audit passed. Your code review report confirms no secrets in the codebase or Git history. Your governance files are in place. Now you deliberately choose to make the repository public so interviewers can see your work.

• Open your GitHub repository in the browser.
• Click Settings in the repository navigation.
• Scroll down to the Danger Zone section.
• Click Change visibility and set the repository to Public.
• Confirm the visibility change when GitHub prompts you.

Why is this safe to make public now?

Your audit confirmed three things: .gitignore was in place before the first commit (so no .env.local ever entered history), the Git history scan returned zero secret matches, and LOVABLE.md prevents future prompts from introducing secrets. The repo contains only public VITE_ values, governance rules, and application code.

This is the professional workflow: private by default, audit the full history, then deliberately publish. Interviewers see both the secure code and the methodology that produced it.

Refresh your repository page. You should see a Public badge next to your repository name.

You now have a public GitHub repository with three interview-ready artifacts: a code review report, a prompt playbook, and talking points covering security, architecture, code review, data migration, and ongoing maintenance. Total Lovable credits used: 3-4 of your 5 daily credits. Next up, the Secret Mission tests whether your governance guardrails actually hold when deliberately challenged.

Secret mission

Test Security Governance and Document Enforcement

Your LOVABLE.md guardrails file claims to prevent the AI from touching auth logic, committing secrets, or running sensitive operations client-side. But does it actually work? In this mission, you will deliberately attack your own guardrails, document what holds and what breaks, and recommend the CI-level enforcement a real team would add.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on free-tier services, so there are no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

• Lovable project (free tier, hosts your task manager app at its lovable.app URL).
• GitHub repository (free, contains all source code and documentation artifacts).
• Local clone of the repository on your machine.

Keep everything running

No action needed. Choose this if you plan to continue with the Day 2 Supabase security project or want to keep your app accessible.

• Your Lovable project persists for free with no charges.
• Your app remains accessible at its lovable.app URL.
• Your GitHub repository stays available with all committed artifacts.
• Your local project folder remains on your machine.

Pause - I'll come back to this later

Free up local disk space while keeping your cloud resources intact. Since both Lovable and GitHub are free tier, there are no charges to pause.

• Your Lovable project and GitHub repository stay active at no cost.
• Optionally delete your local clone to free disk space. You can re-clone from GitHub anytime.

Delete - I don't want to use this again

Remove all project resources permanently. Follow these steps in order.

• Delete the Lovable project: open your project in Lovable and click the project name in the top bar.
• Select Settings, scroll down to the Danger zone section, and click Delete project.
• Type the project name to confirm deletion.

• Delete the GitHub repository: open the repository on GitHub and click Settings.
• Scroll down to the Danger Zone section and click Delete this repository.
• Click I want to delete this repository, then I have read and understand these effects. Type the repository name and click Delete this repository to confirm.

• Delete your local project folder. On macOS or Linux, run:

rm -rf ~/Desktop/[[PROJECT_FOLDER="your-project-folder-name"]]

On Windows, run:

Remove-Item -Recurse -Force ~\Desktop\[[PROJECT_FOLDER="your-project-folder-name"]]

Your GitHub repo is independent of Lovable

Deleting the Lovable project does not delete your GitHub repository. The two are synced but managed independently.

If you only want to remove the Lovable workspace, your code and documentation remain safe on GitHub.

Nice Work!

Nice Work!

You just built a secure full-stack app through architectural prompts, enforced SSR/CSR boundaries that keep secrets server-side, audited the code like a senior security engineer, and documented everything into interview-ready artifacts.

Here's what you accomplished:

• Built a secure full-stack app with LOVABLE.md governance, SSR/CSR boundaries enforced through Edge Functions, secrets never touching the browser or repo, and architecture locked down from the first commit.
• Created an 8-point security audit covering secrets scanning, SSR/CSR boundary verification, environment variable hygiene, RLS review, and a guardrailed-vs-default architecture comparison.
• Produced a prompt playbook and interview talking points with evidence-backed answers to four key questions about security architecture and AI governance.
• (Secret Mission) Tested governance enforcement by deliberately attacking your own security guardrails and documenting what held, what broke, and what CI-level enforcement to add.

Your private GitHub repo now contains every artifact you need. You can walk into the interview and say: here is my security governance file, here is my 8-point audit methodology, here are the SSR/CSR boundaries I enforce, and here are the specific patterns I use to prevent AI tools from shipping insecure code.

Ready to quiz yourself?