App Inspection

Five read-only commands cluster on this page. None of them mutate state — they read your project, print what they find, and exit. Reach for them when you’re diagnosing an unfamiliar setup or getting a quick inventory of an app you haven’t touched in a while.

You’ll use this for:

• Seeing every route your application declares without opening config/routes.cfm.
• Checking the installed framework version, datasource name, and server status at a glance.
• Counting models, controllers, views, and tests — and finding outliers with --verbose.
• Sweeping the codebase for TODO, FIXME, and OPTIMIZE markers before a release.
• Running a health check when something is misconfigured and you don’t know where to start.

wheels routes

Print the dispatch table for the running application — every route declared in config/routes.cfm plus any that framework defaults register at boot.

Synopsis

wheels routes

Description

wheels routes HTTP-dispatches to the development server at /wheels/ai?context=routing and prints the response verbatim. That means it requires a running server — start one with wheels start first. If no server is detected on any configured port, the command prints an error and exits without output.

Output is produced by the framework’s routing inspector, not by the CLI. The shape is a columnar listing: HTTP method, pattern, controller#action, and any name the route was mapped under.

Flags

None. The current implementation forwards no query arguments to the inspector endpoint.

Example

illustrative — server required

wheels routes

Sample output (trimmed):

Method  Pattern                    Controller#Action       Name
GET     /                          pages#home              root
GET     /posts                     posts#index             posts
GET     /posts/new                 posts#new               newPost
POST    /posts                     posts#create
GET     /posts/:key                posts#show              post

Server required

If the command prints No running Wheels server detected. Start one with: wheels start, boot the dev server in another terminal and re-run. The inspector only exists inside the framework runtime.

wheels info

Summarise the project’s environment in a short block — CLI version, installed framework version, engine, datasource, and whether a server is running.

Synopsis

wheels info

Description

wheels info reads the project locally (no server required) and emits a human-readable summary. It detects the Wheels version from vendor/wheels/events/onapplicationstart/settings.cfm, the datasource from config/settings.cfm, the presence of .env and lucee.json, and counts any .resources(…) calls in config/routes.cfm plus the CFC files under app/models/. It also calls detectServerPort() to report whether the dev server is currently up.

When the current directory is not a Wheels project (no vendor/wheels/ present), the command prints a single line saying so and exits.

Flags

None. wheels info takes no flags — ignore any reference to --json or --quiet; those were never wired up.

Output stream

Output is written to stdout. If you’re piping wheels info into another tool, it reads from stdout directly — no 2> redirection needed. The process exits successfully either way; no non-zero exit is raised when the summary is empty.

Example

wheels info

Sample output (trimmed):

Wheels CLI v4.0.0

Project:  /path/to/myblog
Wheels:   v4.0.0
Engine:   Lucee (LuCLI module)
Database: myblog
Env file: .env found
Config:   lucee.json found
Routes:   3 resource route(s)
Models:   5 model(s)
Server:   not running

The first line is preceded by a small Wheels banner in some terminals — reproduce it in full only if your docs workflow requires it.

wheels stats

Count files, lines of code, comments, and blanks by category (models, controllers, views, tests, and so on), then print a totals row and a code-to-test ratio.

Synopsis

wheels stats [--verbose | -v]

Flags

Flag	Description
--verbose, -v	Append a “Top 10 Largest Files” list after the totals row. Useful when hunting for views or controllers that have grown past the point of sanity.

Example

wheels stats

Sample output (trimmed):

Code Statistics
======================================================================
Category       Files    LOC   Comments   Blanks   Total
----------------------------------------------------------------------
Models             5    142         18       31     191
Controllers        6    287         42       68     397
Views             24    512         12       94     618
Tests             18    634         56      112     802
----------------------------------------------------------------------
Total             53   1575        128      305    2008

Code-to-test ratio: 1:0.67
Average lines/file: 29

wheels notes

Scan the project for inline annotations (TODO, FIXME, OPTIMIZE by default) and print each hit with its file path, line number, and the text after the marker.

Synopsis

wheels notes [--annotations=<list>] [--custom=<tag>]

Flags

Flag	Description
--annotations=<list>	Comma-separated list of markers to search for. Default: TODO,FIXME,OPTIMIZE. Case-insensitive.
--custom=<tag>	Additional single marker to include alongside the defaults (or the list set with --annotations=).

Example

wheels notes

Sample output (trimmed):

TODO (2):
  app/controllers/Posts.cfc:47 -- paginate once we break 100 posts
  app/models/User.cfc:112 -- extract password policy into a validator

FIXME (1):
  app/views/posts/show.cfm:23 -- escape HTML in the excerpt

Summary: 3 annotations (2 TODO, 1 FIXME)

When nothing matches, the command prints No annotations found. in green and exits.

wheels doctor

Run a battery of health checks against the project — file layout, configuration presence, datasource reachability, migrator table state, and anything else the doctor service has wired up — and print a list of passes, warnings, and issues with an overall status.

Synopsis

wheels doctor [--verbose | -v]

Flags

Flag	Description
--verbose, -v	Always print the list of passed checks. Without this flag, passes are shown only when the overall status is HEALTHY (i.e., zero issues and zero warnings).

Example

wheels doctor

Sample output (trimmed):

Wheels Health Check
========================================

Warnings (1):
  ! .env file missing — copy _env and customise

Passed (7):
  + vendor/wheels/ installed
  + config/settings.cfm present
  + config/routes.cfm present
  + app/models/ exists
  + app/controllers/ exists
  + tests/specs/ exists
  + lucee.json present

Status: WARNING

Recommendations:
  * Create a .env file from the _env template before running migrations.

Status is one of HEALTHY, WARNING, or CRITICAL. Issues (red) indicate the project cannot run as configured; warnings (yellow) flag things that work but look off; recommendations (cyan) are optional suggestions keyed off what the checks found.

Common workflows

Quick setup verification

wheels doctor

Run this first when a project acts strangely or when you’ve just cloned someone else’s app. If the status is HEALTHY or WARNING, you can usually start the server; CRITICAL means something is structurally wrong.

See what exists

illustrative — shell operators not supported

wheels info && wheels stats && wheels routes

Three commands, in order, give you: versions and environment, artifact counts, and the routing table. Run this after inheriting an app to orient yourself in under a minute. (Remember wheels routes needs a running server.)

Find stale work

wheels notes --annotations=TODO,FIXME,HACK,XXX

Sweep before a release. Widen the marker list with --annotations= or tack on a single extra tag with --custom=DEPRECATED.

Related commands

Configuration Where the settings that info and doctor read from actually live.

Creating a Project wheels new — produces the layout that doctor validates.

Code Quality wheels analyze, wheels validate — deeper diagnostic surfaces.

Upgrade wheels upgrade — run after info flags an outdated framework version.