The Pass

Every restaurant has a room guests never see. Not because it's shameful — because it's operational: where orders are read, where the chef decides what goes out. Your card box is now public, and last lesson's pre-flight told you the honest truth about public forms: anyone can write on your wall. What you own now is a lovely front of house with no back room.

Today you build the pass: a private page where you read everything, delete junk, and run the place — behind a door with a code. Along the way you meet one of the most important grown-up concepts in this whole course: the secret.

What you'll plate today

A /pass page only you can open: every card, newest first, with a quiet little "remove" next to each — and a door that politely refuses anyone without the code.

Ingredients

• Your live comment card box from Lesson 5
• About 35 minutes

Cook

1. Understand secrets before you own one

A door code has to live somewhere so your worker can check it. Here's the rule that separates professionals from headlines: secrets never live in files that travel. Not in the page, not in the code, not in save points — which, since Lesson 1, travel to GitHub. A secret goes in a separate, deliberate place that deployment machinery keeps out of sight.

You don't need to memorize the mechanics. You need to hold the rule, and make it law:

Add a rule to CLAUDE.md: secrets — codes, keys, passwords — never
go into any file that gets saved or pushed. If something needs a
secret, stop and tell me where it will live instead.

2. Build the pass

Build the private side of my card box:

1. A new page at /pass: every card, newest first, with the date
   and a small "remove" action next to each one.
2. Protect it with a door code. I want to type the code once and
   be let in; wrong code gets a polite refusal, nothing more —
   no hint about what went wrong.
3. Store the code as a proper secret — following the CLAUDE.md
   rule we just made. Set it up for BOTH kitchens: my local one
   and the live one. Tell me exactly when you need me to type
   the code, and wait.
4. Test locally first. Don't ship yet.

At some point it will ask you to type your code — maybe once for the local kitchen, once for the live one (two kitchens, two pantries, two copies of the secret: the Lesson 5 rule again). Pick something you'd never reuse from a real account, type it where it says, and notice what didn't happen: the code never appeared in any file you could accidentally push.

3. Taste the door

Three tastes, in order, locally:

1. Open /pass and type a wrong code. You should get the polite refusal — and no clue whether the code was close. (Vague refusals are a kindness to you and a wall to strangers.)
2. Type the right code. There's your wall, with the levers.
3. Submit a junk card from the public page — "BUY CHEAP WATCHES" — then remove it from the pass. Gone from the wall. That's moderation: the whole art, one button.

Then ship:

Ship the new version, verify the live /pass yourself — wrong code
refused, right code works — and make a save point: "the pass".

4. One honest paragraph about door codes

This course tells you what things are and aren't. A door code checked by your worker is real protection — strangers cannot browse your cards. It is also right-sized protection: perfect for comment cards, wrong for bank statements or anything you'd call sensitive data. Real login systems (accounts, passwords, "forgot my password" emails) are a genuinely deep dish, and the honest move at your stage is to know the difference — not to fake one. When a future project needs real accounts, that's a recipe we'd cook properly. Tonight, for a card box: this is exactly enough, and you understand why. That understanding is the lesson.

When it burns

• The pass works locally but not live — the live kitchen never got its copy of the secret. "Set the same door code as a secret on the live deployment, then verify." Two kitchens. Always two kitchens.
• You typed the code into the chat instead of where it asked — it happens; that chat line is now a place your code has been. Pick a new code, set it properly, move on. (This is why the agent says where to type — terminal prompts keep secrets out of transcripts.)
• The remove button deletes the wrong card — classic off-by-one. "Removing card #3 deleted a different card — find out why and fix it, then show me the raw rows to confirm."
• You forgot your own door code — no drama: secrets can be replaced, that's their nature. "Replace the door code with a new one" and type a fresh code — both kitchens.
• It wants to build a full login system — ambition again. "Door code only — re-read the plan. Real accounts are a different course."

Order up

□ /pass exists — wrong code politely refused, right code lets you in
□ The code lives as a proper secret in BOTH kitchens, in no files
□ You planted junk and removed it — moderation works
□ CLAUDE.md has the secrets rule
□ Save point "the pass", mirrored to GitHub — with no secrets in it

Next up — Lesson 07: House Style. Your app works. Now it gets finished — and the inspector is your own agent, using its browser eyes from First Kitchen to visit, poke, and test your live app like the world's most thorough first guest.

Stuck on a step? Question box below.