feat(cli): hint when no models.py is found

[Nitjsefnie]

What

django-orm-lens scan --path /some/dir (and describe/hover/list/er,
which all share _load_index) silently printed an empty apps list when zero
models were found. New users had no way to tell whether the tool actually
ran or the --path was wrong.

Change

_load_index in cli/django_orm_lens/cli.py now prints a hint to stderr
when idx.total_models() == 0 and no models.py/models/*.py file was
walked at all under --path:

hint: no models.py found under <path>. Django apps typically have
      <app>/models.py or <app>/models/*.py. Check the path or pass
      --exclude to whitelist non-standard layouts.

• stderr-only, exit code stays 0 — an empty result is valid, not an
  error, and stdout stays clean for piping.
• The "no models.py seen" check is real, not approximated. total_models() == 0
  alone can't distinguish "nothing under this path at all" from "a real
  models.py was found but defines zero Django model classes" — those are
  different situations from the user's point of view, and only the first
  should show the hint. WorkspaceIndex/scan_workspace don't currently
  expose a "files walked" count, and extending them felt like scope creep
  for a hint feature, so _load_index re-checks with the existing
  parser._iter_python_files(root, excludes) walker (same root + excludes
  used for the actual scan) to determine whether any models.py-shaped file
  was present. Verified both branches manually:
  • empty directory → hint fires
  • directory with a real models.py containing zero Django model classes
    → hint does not fire (a test covers this too)
• New --quiet/-q flag suppresses the hint. Registered in
  _add_scan_flags, so it's scoped identically to the existing
  --path/--exclude flags across every subcommand that goes through
  _load_index (scan, describe, hover, list, er).
• CHANGELOG.md gets an [Unreleased] entry, following the existing
  precedent of individual PRs adding to Unreleased ahead of a release
  commit bumping the version.

Tests

Added cli/tests/test_cli_hint.py (3 cases, invoking cli.main() directly
and capturing stdout/stderr via contextlib.redirect_stdout/stderr):

1. Hint appears on stderr for an empty workspace, stdout still has the
   {"apps": []} JSON, exit code is 0.
2. --quiet suppresses the hint entirely (stderr empty).
3. A models.py that was walked but defines zero Django model classes does
   not trigger the hint (models.py was "seen").

Gates (run from cli/)

• .venv/bin/pytest -q → 47 passed (44 pre-existing + 3 new), all green.
• .venv/bin/ruff check django_orm_lens/cli.py tests/test_cli_hint.py →
  the new test file is clean. cli.py reports 7 pre-existing findings
  (UP035/UP045/UP006/SIM105 on code this PR didn't touch or on
  unrelated pre-existing lines); confirmed identical (same messages, just
  shifted line numbers) by running ruff against the unmodified file via
  git stash — this PR introduces zero new lint findings.

Scope

Touches only cli/django_orm_lens/cli.py, cli/tests/test_cli_hint.py
(new), and CHANGELOG.md. No changes to the VS Code extension, .github/,
or any other file.

Closes #12

Prepared with AI assistance (Claude Sonnet 5), human-reviewed before submission.

[coderabbitai]

Warning

Review limit reached

@Nitjsefnie, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 49 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: dd8ef1b5-1d0e-439f-92f9-60de09908ee7

📥 Commits

Reviewing files that changed from the base of the PR and between a92d5b1 and e3a2bd2.

📒 Files selected for processing (3)

• CHANGELOG.md
• cli/django_orm_lens/cli.py
• cli/tests/test_cli_hint.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}