Codependix reports a handful of distinct outcomes, and reading which one occurred is most of the work. Start by separating them: a boundary violation is a real edge in real code, a stale export is drift, a failure is a project that never got as far as producing one, and a run that wrote nothing at all is usually neither.

found an edge, or a cycle, that a declared rule condemns. Each violation names the graph level, the scope it was found in, the rule, both endpoints, and whatever the rule says about why it exists.

This is the one finding a re-run never fixes. Nothing is stale and nothing needs regenerating: the edge is in the code, and one of two things has to give.

Never narrow a selector, add an exclusion, or delete a rule purely to make a failing check pass. A gate loosened to pass is a gate that no longer protects anything, and the next reader has no way to tell it was ever meant to.

If the violation is at the level and mentions an edge with no import statement behind it, that is the point of the level: an entry is a real project-graph edge, and cannot see it. Remove the entry, or the rule has to change.

One or more configured exports disagree with a freshly built graph. The run names the projects.

Re-run

--write

. That is the entire fix. The graphs move with the workspace they describe, so a project graph that changed makes every export that drew it stale — which is drift to refresh, not a defect to investigate.

Never hand-edit inside the anchor markers. The next replaces the block wholesale, so an edited diagram is a diff that silently disappears on the following run. The same goes for a standalone Markdown file: codependix owns its whole contents.

Two more things a stale check does not mean:

A failure is collected per project and reported by name. One project failing does not stop the rest — every remaining project in that pass still runs, and all four graph-type passes are attempted regardless of whether an earlier one failed. So a run naming three failures is three things to fix, not one flaky run to retry.

The only anchor problem that fails outright. A missing anchor block is auto-created on ; a missing file is not, because a project with no readme at all is a more serious problem than an unplaced block, and inventing the file would mean authoring a document nobody asked for.

Create the file — a project readme with at least a heading — and re-run.

Not a failure. creates it, at one of exactly two safe places:

It never places a block anywhere else in a document someone else is authoring, and never duplicates the heading. If the block landed somewhere you did not want it, move the whole marker pair by hand once and every later replaces the content in place.

The NestJS pass explores a project's container in preview mode, which registers every module and provider without instantiating any of them. A project building a options factory never has a database contacted, so what breaks this pass is always something that throws while modules are being registered — a module whose static argument reads a variable that is absent, a top-level throw in a module file, or a project whose root module does not export what the pass expects. Look there.

An application is rooted in and its export; a library package with no such file is rooted in a synthetic module built from every it defines, so a module file that cannot be imported on its own fails a library that an application would not notice.

Two fixes that look plausible and are not: starting or seeding a database (the pass never contacts one), and building the project first (it imports the project's own TypeScript module sources directly).

If the CLI is being run from TypeScript sources through some other loader, check that decorator metadata survives it: NestJS constructor injection reads metadata that plain type-stripping erases, and the failure looks like a container that cannot resolve its own providers. The published binary registers a decorator-preserving loader itself; a hand-rolled invocation has to do the same.

takes a comma-separated set drawn from and , and the whole command line is read before anything else happens:

Every mistake on one command line is collected before any is reported, so two complaints are two things to fix rather than two runs.

The command is , not bare : a command line with no subcommand is rejected by the argument parser before any of this applies.

The quietest outcome, and almost never a bug: the run exits 0, reports that every configured export is current, and writes nothing, because nothing was configured. Every unset defaults to , and a project resolving to is left out of the results entirely rather than reported as up to date — so projects in the report means codependix was configured to produce nothing.

Work down this list before suspecting the tool:

The skill covers each of those fields.

Validation refuses two destination mismatches rather than silently exporting half of what was asked for: a or target with no destination, and a or target with no destination. A destination naming neither an nor a is refused for the same reason — nothing would say where the export goes.

A finished export is a description, not a verdict — an export gates nothing about a codebase's shape, and only a declared boundary rule does. A diagram that shows something alarming (a cycle, a project depending on far more than expected) is a real finding about the code even when no rule condemns it, and the fix belongs in the code rather than in the configuration that exported it. Reach for the skill to read what the graph is actually saying before changing anything.