What a project adds

A project is a folder that holds a CORA config, cora.config.ts or cora.config.json, or a package.json that lists @vispero/cora. cora and cora-mcp find it from the folder they run in, upwards.

Without one, cora still scans any page by its URL, keeps its results, its baseline and its report in the folder you run it in, and compares each scan with that baseline, as Scanning without a project shows. A project adds what needs your app’s code, or a decision the whole team shares.

The config file’s settings

The config file holds what everyone who scans the project shares, much of which no flag or variable can set, as Configuration describes:

• Targets: the pages a plain cora scan covers, and the baseUrl their paths resolve against (Targets).
• Rules: which rules run and which only report, in every run, for every page and for each route (Rules). --only and --skip narrow one run’s rules without a config (Narrowing a run).
• Pages and routes: how each page is waited for, and the elements it leaves out (Pages and routes).
• Signing in: a browser.setup script that signs the scan in to your app (Signing in).
• The app’s server: the command cora starts the app with before it scans, and stops after (The app’s server).
• The gate: policy.failOn, the severity at which a new issue fails the run, for every run of the project.

Source locations

In a Vite app, CORA’s Vite plugin stamps each element with its place in your source. A finding on a stamped element then names the file and line to fix, and an element of a shared component is one issue on every page it appears on (Issues and fingerprints). cora init registers the plugin in a Vite project.

The coding agents’ fixer and hooks

CORA’s plugin for Claude Code and Codex fixes issues in your code, which only a project has:

• The fixer scans the pages your request names, or the config’s targets, fixes each issue in your source, checks each fix in the browser, and pins it with a test in your project’s own test framework where it can (The fixer).
• The hooks run the project’s own cora. They ask you before an edit of what decides what CORA reports, keep CORA’s tools in the fixer, and start the fixer after the agent edits your UI (The plugin’s hooks).

cora init adds the plugin to the project’s Claude Code settings, and Codex’s fixer agent to the project’s .codex/ (Installing the plugin). Outside a project, cora-mcp’s tools still scan, explain and verify, and keep their state in the folder the agent opened.

One version for everyone

A project installs @vispero/cora as a devDependency, so everyone and CI run the version it pins. In a project with it installed, cora-mcp runs at that version too (Version alignment). Outside a project, npx @vispero/cora runs the version it resolves, and cora-mcp the release the agent started.

Turning a folder into a project

Getting started installs cora and sets the project up with cora init. A folder you scanned without a project keeps its .cora/ and its baseline: once it holds a config, it is the project root, and the next scan compares with the same baseline. If the config’s baseUrl names the site while the folder’s runs gave no base URL, its issues read as new once, since a page under the base URL is identified by its path alone.