Workflow: pre-release cleanup

Every team does this work eventually. A release is approaching. Someone says "let's clean up the obvious junk before we ship" — and now the next two days are a fuzzy mix of dead-code hunts, naming-overlap reviews, structural drift checks, and the slow realization that the codebase has accumulated more cruft than anyone wanted to admit.

This is the workflow cix was originally built to support. It is also the workflow that produces the most measurable wins.

What you're actually looking for

A pre-release cleanup pass typically tries to surface:

Dead code. Functions, components, modules with zero references.
Naming overlaps. Two helpers doing the same thing under different names.
Structural drift. Files in the wrong folders. Conventions that have decayed.
Schema-code mismatches. Models referencing columns that no longer exist. Migrations that conflict.
Hidden risks. Hardcoded credentials, forgotten test fixtures shipped to production, files that got mass-renamed but had old references left behind.
Duplicated logic. The same algorithm in three places, slightly different each time.

Each of these is a small fix. The hard part is finding them. Without an index, you find them by reading. With cix, you find them by querying.

The structured pass

A cleanup pass with cix in the loop follows roughly this shape:

1. Orient

A single orientation query gives you the project's stack, entry points, route surface, schema, top directories, and known parse errors. The parse-error report alone often surfaces issues — "this file failed to parse because someone left a syntax error" is the kind of thing teams discover at release time.

2. Audit conventions

A whole-project audit pass walks every file against your declared conventions and reports violations with suggested target paths. Some violations are obvious mechanical fixes ("this controller should be in app/Http/Controllers, not app/"). Others reveal that your conventions and your practice have drifted apart.

3. Find dead code

For each candidate symbol, an impact analysis query tells you if it has callers. Zero callers and zero tests is strong dead-code evidence. The list of candidates is informed by hot-symbol rankings (low-imported symbols are the natural place to look) and orientation data.

4. Look for naming overlaps

Search the index for pairs of functions or components whose names suggest similar functionality. The find-by-name search returns precise matches; you look at the source side-by-side and decide whether to consolidate.

5. Check schema-code alignment

The schema view, plus impact analysis on each table, tells you which models, queries, and tests reference each column. Columns referenced by no live code path are cleanup candidates. Models referencing columns the schema doesn't have are bugs.

6. Read the warnings

The system surfaces warnings throughout: tables defined in multiple migrations, dynamic database connections in unexpected files, parse errors in files the index couldn't fully understand. These warnings are often the most valuable output of the whole pass — they're the kind of thing a human review wouldn't think to look for.

A real measurement

A pre-release cleanup run on a Laravel + Vue project (300 indexed files, mid-rename, contact-unification refactor in flight) produced:

Eight findings that both cix and a less-capable indexer surfaced (broken model references, orphan models, frontend modules with zero importers, controller naming overlaps, suspicious data-access patterns).
Three additional findings that only cix surfaced — including a forgotten Python file in the Laravel public/ directory hardcoding root MySQL credentials.
About half the tool calls of the indexer-free pass (29 vs. ~55).
About a third of the tokens (30–40k vs. 80–100k).

The measured side-by-side write-up is in the pre-release cleanup case study.

What this enables

Cleanup that actually happens. Most teams skip the cleanup pass because it feels too expensive. When the cost drops by half or more, the work moves from "we should" to "we did."

Confidence at release time. "We did a cleanup pass" goes from a vague claim to a concrete artifact: an audit report, an impact-cleared dead-code list, a schema-alignment check.

Findings you wouldn't have looked for. The forgotten credential in the public directory wasn't on anyone's checklist. cix found it because the orientation step looks at every entry point, including the ones nobody remembers.

What it doesn't do

Decide what to fix. It surfaces candidates with evidence. You decide what to keep, merge, or delete.
Make the fixes. A cleanup workflow is a finding workflow. The actual edits happen afterward, often through the refactoring workflow.
Replace human review. This is especially true for "is this dead?" decisions. A symbol with zero static callers might be invoked dynamically through a config. The impact report flags lower-confidence cases — you make the call.

When to run it

Before any release that has been gathering changes for more than a sprint.
After any large refactor that touched many files.
When onboarding a new team member who will need to learn the cleaner shape of the project.
Periodically, just to see how much drift has accumulated.

The cost of running the workflow is low enough that "periodically, just because" becomes a reasonable answer.

Pre-release cleanup case study — the measured run.
Impact analysis — the engine for dead-code and reference checks.
Convention enforcement — the audit surface.