Convention enforcement

Most teams have an opinion about where files belong and what they should be called. Few teams have a way to enforce those opinions consistently — especially against an AI assistant that has no memory of last week's PR review.

cix gives you that enforcement. You declare your conventions once. The system applies them every time a file is created, with no human review needed for the easy cases.

The two layers

Description. Your project gets a small machine-readable file that says, in effect: "Components live in this folder. Hooks live in that one. Components are PascalCase. Hooks are camelCase." Anyone — human or AI — can read it.

Enforcement. Before any file is written, the proposed path and name are checked against those rules. On clients that support write hooks, a violation blocks the write outright. On clients that don't, the violation surfaces as a warning the assistant must address before continuing.

Together, these mean the rule is not just visible — it is operative.

What you get out of the box

Ten convention profiles ship with cix, covering the most common stacks:

React (component placement, hook conventions, file naming)
Vue (single-file component organization, composition vs. options)
Next.js (App Router conventions for layouts, pages, server components)
Django (apps, models, views, templates)
Flask (blueprints, models, route registration)
FastAPI (routers, dependencies, schemas)
Laravel (controllers, models, requests, resources)
Rails (Active Record, controllers, partials)
Express (routes, middleware, models)
A general profile for projects that don't match any of the above

When you initialize cix on a project, the relevant profiles are detected and copied into your repo. You commit them alongside your code. They get tuned over time the way any convention document does — but unlike a document, they are enforced.

Why this matters more than it sounds like it should

A team's conventions are usually written down somewhere — a README, a CONTRIBUTING.md, a Notion page. Rarely are they enforced. They live as suggestions that humans usually follow and AI assistants usually ignore.

This is fine when humans are the only contributors. Reviewers catch convention violations in PRs. Bad placement gets corrected over time. The system holds together because there's a human in the loop noticing.

AI assistants change the math. They produce code at a rate where every human-in-the-loop step becomes a bottleneck. If you wait until PR review to catch convention violations, you are reviewing dozens of small, easily-prevented mistakes per week. Each one is a tiny correction, but the cumulative cost is real.

cix moves enforcement to the moment the file would be created. No PR review needed for the obvious cases. The reviewer's attention goes to the things that actually require judgment.

What gets enforced

The current rule surface covers:

Folder placement. A controller belongs under app/controllers, a hook belongs under src/hooks, etc.
File naming. Components are PascalCase. Utilities are camelCase. Tests follow your test naming pattern.
File kind classification. A .tsx file in src/components/ is treated as a component, not a hook, even if its name starts with use.

The rules are intentionally mechanical. They cover the high-volume, easy-to-verify decisions that don't need human judgment. Things that do need judgment — whether an abstraction should exist, whether two helpers should be merged — are explicitly not in scope. See Limitations for that boundary.

What about projects with messy existing conventions?

A common worry: "Our project's conventions are inconsistent. Half our components are in one folder, half in another."

cix handles this in two ways:

Inferred starting point. When you initialize on an existing project, cix reads what is actually in the repo and proposes a conventions file based on the dominant patterns. You review and adjust before committing.
Audit before enforcement. A separate audit pass scans the existing codebase against your declared rules and reports violations with suggested fixes. You can clean up incrementally — fixing the rules, fixing the code, or both — before turning enforcement on.

You do not have to be in a perfect state to start using cix. You start where you are, and the system meets you there.

What it does not enforce

Code style (use Prettier, Black, or whatever your team uses).
API design choices (those are judgment calls).
Test coverage (those need a different tool).
Whether the code is correct (that's what tests and review are for).

Convention enforcement is a structural backstop. It catches the class of small, repetitive, mechanical mistakes that compound over time. It is not a substitute for code review, testing, or thinking.

Find before you build — pairs naturally; together they prevent the two most common AI failure modes.
Workflow: feature add — see how this fits into adding new functionality.
Limitations — what convention enforcement deliberately does not try to do.