Keeping Secrets Out and Rules Shared
order-api has a rule file now, and by lesson 6 you were reviewing its diffs the way you'd review a teammate's pull request. Both of those are habits that live entirely on your machine, in your session. This lesson is about the two places that stop being true: what Cursor is allowed to read in the first place, and what your rules mean once someone besides you opens the repo.
.gitignore decides what ships. .cursorignore decides what a model reads.
order-api almost certainly has a .env file sitting next to package.json with a database URL or an API key in it, and almost certainly a .gitignore that already excludes it. That's the wrong file to check. .gitignore governs what gets committed. It says nothing about what Cursor's Agent, Tab, or Cmd-K can read off disk right now, in this session, on your laptop. A gitignored .env file is still sitting in the working directory, and unless something else excludes it, it's fair game for indexing, for @codebase, for anything Agent decides is relevant context on its way to answering a prompt.
That something else is .cursorignore. Same glob syntax as .gitignore, same location at the project root, completely different job: it tells Cursor's indexing which files never get read, never get suggested from, never get sent anywhere as context. Two files, similar look, two different questions: one is "what ships," the other is "what a model gets to see."
# .cursorignore
.env
.env.*
*.pem
*.key
credentials/
dist/
build/
node_modules/
*.log
Secrets and credentials belong there for the obvious reason. Build output and node_modules belong there for a quieter one: a generated dist/ folder or a fat lockfile doesn't help Cursor reason about order-api, it just burns indexing time and context budget on bytes nobody wrote by hand. .cursorignore isn't only a secrets fence. It's also how you keep the index made of source, not noise.
If your team has been relying on .gitignore alone, check what's actually reachable right now: open Agent and ask it to read your .env file directly by path. If it can, .gitignore was never doing the job you assumed. The fix is a .cursorignore entry, not a stronger .gitignore rule.
Run that check against whatever real repo you've had open since lesson 2, before adding the .cursorignore file below, not after. A gitignored .env that Cursor can still read on request isn't a hypothetical risk this lesson is describing in the abstract. It's a thirty-second check against your own working directory, and the answer is either yes or no, not "probably fine."
A rule file that lives in the repo is a team default. One that lives on your machine is a habit.
Lesson 4 walked through writing .cursor/rules/order-api.mdc: named exports only, every new method gets a test, OrderClient stays a thin synchronous wrapper. Framed as a solo habit, that file saved you from re-typing the same corrections every session. Framed for a team, it does something bigger, because .cursor/rules/ is a folder inside the project, and a folder inside the project is a folder that gets committed.
Commit .cursor/rules/order-api.mdc alongside the code it governs, and the next teammate who clones order-api and opens it in Cursor gets those three conventions applied to their session on turn one. Nobody walked them through it. Nobody pinned a doc in Slack they'll skim once and forget. The rule travels with the repo the same way the code does, because it's in the same commit history, subject to the same review, changeable by the same pull request process as everything else.
Contrast that with Cursor's personal and global settings: your own model preference, your own keybindings, whatever custom instructions you've added under your account. Those stay on your machine. They shape your sessions and nobody else's, and that's correct. A font size preference has no business in a team's shared conventions. The distinction that matters is which folder a given setting lives in, not how useful it feels to you personally.
This is the upshot of everything module 2 built: a well-written .cursor/rules/ directory isn't a personal productivity trick you happened to also share. Committed, it's how "the convention this team already agreed on" stops depending on whoever remembers to say it out loud in each PR review, and starts being the thing every teammate's Agent already knows before they ask.
A pull request that edits .cursor/rules/order-api.mdc is changing what every future agent turn on this project assumes. Review it with the same attention you'd give a change to a shared lint config, because that's functionally what it is.
Model choice is a team decision too
Cursor lets you pick which model handles a given Tab, Cmd-K, or Agent request, and the options trade off cost, speed, and capability against each other rather than one model simply winning on all three. Left unstated, everyone on a team picks ad hoc: one person always reaches for the most capable option regardless of task size, another defaults to whatever's fastest and eats the quality cost on a job that deserved better. Neither failure mode is really about the model. It's about a team never having agreed on a default in the first place.
The fix isn't picking one model forever. It's a short, written default, something like "use X for day-to-day Agent work, escalate to Y for anything touching more than a few files," so the choice is a team decision made once and revisited deliberately, not forty individual ones made silently every day. Specific model names and pricing change often enough that this course won't pin either here; check Cursor's current model picker and pricing page before writing your team's default.
One thing this lesson deliberately doesn't cover
Once an agent is reading and writing real code, it can also touch real data. A hardcoded test fixture with a customer's actual email address is a more common leak than people expect. If your team needs the GDPR and EU AI Act side of that question, claude-code-for-business lesson 10 covers it in full; this course doesn't repeat it here.
Checkpoint
Everything from the reframe to the ignore file, compressed into what to actually do Monday morning.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
