Always Write MongoDB and Not Mongo
Written later and filed to this date, as part of filling in every day of the year.
The rules file says it three times. “When writing code, always write the tests first.” Then, under a different heading, “Always write the tests first.” Then, under a third, “Always write the tests first.” The repository it sits in has ten commits, and the last three are titled “progress”, “/jobs page” and “WIP”.
This is the job-search platform I started in March 2025, the one whose first commit carried two Python environments. That piece was about the log. This one is about the only file in the repository addressed to a model, because in a project with no second human, that file is the nearest thing to a conversation about how the work should go.
Two files, one reader
The first commit has two copies of the instructions. One is .cursorrules at the repository root, the older convention. The other is .cursor/rules/mainrule.mdc, the newer one, with a header that says alwaysApply: true. Their bodies are byte-identical: fifty-four lines opening “You are an AI assistant specializing in frontend web development,” then sections on component structure, hooks at the top of components, aria-label on every interactive element, CSS modules with BEM names, WCAG 2.1 AA, and a block headed PROJECT-SPECIFIC PATTERNS about the pagination components and the resume builder’s styling. It reads like a file written by someone who had looked at the code, and that one block is the part no template can supply.
Eleven days later a commit titled “styles cleanup” rewrote the root copy and left the other alone. Ninety-one lines in, eighteen out. The word “frontend” left the first sentence. The hooks rule, the aria-label rule, the CSS-module rules, the accessibility standard and the whole project-specific block were deleted. What replaced them was a second template, written for neither this project nor this language.
What the second template wanted
Init all dependencies in dependencies.py. Write the configuration in config.py. Don’t wrap code in try/except unless catching a specific exception. Always run the tests in the venv. Use a logger. Start private class variables with an underscore. Constants in UPPERER_SNAKE_CASE, typo included. Always use async. When you need to remember something, update .cursormemory.md, and put in that memory “instructions for development like how to add new GraphQL mutations and queries.” And under Naming Conventions: “Always write MongoDB and not Mongo.”
The project is Next.js over FastAPI, with Prisma and SQLAlchemy on Postgres and SQLite in development. There is no dependencies.py, no config.py, no GraphQL schema. .cursormemory.md was never created; the last commit of 2025 has no such file. The only places MongoDB appears outside the rules are the seed data, in the skills lists of two fictional job postings, where it is spelled correctly.
Under “Rewrite, Improve, and Refactor” the file asks for DRY code and then says “Keep the code clean and easy to understand” on two consecutive lines. “Always run the tests to make sure the code works” appears three times in all.
So from the nineteenth of March the model read both files on every request: one saying frontend and naming the pagination component, one saying Python and naming a database the project did not use. Nothing in the log suggests it minded. The commit on the same day as the rewrite is titled “fixed test case”; it removed 147 lines and added 22.
What the file was
I know why it happened, because I remember the feeling. Writing a rules file is the part of starting a project that feels like engineering management: you set the standard before the work, and the standard is long and firm. Pasting a second template on top felt like raising it. Tests first, three times, is a standard raised three times.
But a rules file is read by something that cannot ask whether you meant it, and the repository is the only record of whether you did. Read that way, the file is a wish list, and the log beside it is the audit. Tests first, three times; “fixed test case”, minus 147. Keep a memory file; no memory file. MongoDB, not Mongo; Postgres. The one block that could only have been written by looking at this code was the one deleted to make room.
What the repository taught, said plainly: an instruction to a model is only as real as the project’s ability to show it was followed, and a rule the code cannot show is a sentence in a file. The file written by looking is still in the repository, still marked alwaysApply: true, still asking for aria-label on every interactive element. Fifteen of the 143 component files have one. The registration form, in the commit called “WIP”, has none.