There is a file I copy, nearly byte for byte, into every serious project I start. It is not a utility library or a config. It is a document: mandatory software engineering principles, the same SOLID, DRY, KISS, and YAGNI canon every senior engineer claims to know, written down as binding rules with a code-review checklist at the end. It has now shipped inside a healthcare platform, a manufacturing automation system, and a B2B agricultural platform.
Copying a principles doc between repos sounds like the least interesting engineering decision possible. That is exactly why it works. The document is boring, stable, and portable, which are the three qualities project-specific conventions never have. Every new codebase starts with the same constitutional layer, so the arguments that waste the first month of most projects, naming, error handling, when to abstract, are pre-settled by a document with authority.
The line from that document I quote most often: never generate tutorial-level code. It was written with AI assistants in mind, and it earns its keep daily. Tutorial code is code that works in the happy path and teaches nothing about failure: no error boundaries, no loading states, no thought about what happens when the network lies to you. Whether the author is a model or a rushed human, the rule gives review a word for the smell.
The constitution alone is not enough, because principles are stack-agnostic and bugs are not. So each project layers framework-specific rulebooks on top, and those are where the sharp edges live. Three examples that have each saved me real debugging hours.
Tailwind first. The JIT compiler scans your source for class names as literal strings. Build a class dynamically, by concatenating a color variable into a class name at runtime, and it silently vanishes from the output CSS. Nothing errors; the style just does not exist in production. The rule: never interpolate class names, keep a lookup map from state to complete class strings. One sentence in a rulebook versus an evening of staring at a button that is styled locally and naked in prod.
Next.js second. The rule is phrased to be unforgettable: Server Actions are public endpoints, authenticate every one. The framework makes calling a server function feel like a local call, and that ergonomic lie is exactly why people forget that anyone on the internet can invoke it with crafted input. Every action validates with a schema and checks authorization, no exceptions, even the "internal" ones. Especially the internal ones.
React lists third. The rulebook says virtualize any list beyond about a hundred items, and states the memoization policy as: only when profiling justifies it. Premature memo wrapping clutters code for wins that do not exist, while a two-thousand-row table without virtualization is a guaranteed jank generator. The number matters less than having a number; thresholds convert vibes into review comments.
The same rulebooks also encode the quieter preferences that keep bundles lean: prefer the platform Intl APIs over date-formatting libraries, prefer fetch over an HTTP client dependency, reach for a library only when the platform genuinely cannot do the job. None of these are dramatic. Compounded over a project, they are the difference between a lean app and a node_modules archaeology dig.
Does duplicating the constitution across repos violate DRY, the very principle it preaches? No, and the distinction matters: DRY is about not duplicating knowledge that must change together. The principles document is intentionally frozen; each copy is a snapshot, not a dependency. A shared living version would couple three unrelated projects to one file's churn, which is the exact coupling DRY exists to prevent.
If you work across multiple codebases, or with AI agents that need the same briefing every session, write your constitution once. Keep it under a page of rules that are actually enforceable, add a framework rulebook per stack with numbers and named gotchas, and copy them into every repo like you copy a license file. It is the highest-leverage boring file you will ever maintain.