Entrypoint pass detects zero entrypoints in Odoo; PyEntrypointReport is not projected to Neo4j

[rahlk]

Found while validating the CLDK python-sdk 2.0 Python leg against a live Neo4j projection of odoo-slim-19.0.0 (2,364 files) emitted by codeanalyzer-python 1.4.0.

Observation

The entrypoint pass detects nothing on Odoo:

MATCH (c:PyCallable) RETURN c.is_entrypoint, count(*)
FALSE  15549

MATCH (c:PyClass) RETURN c.is_entrypoint, count(*)
FALSE  1656

Zero entrypoints across 15,549 callables and 1,656 classes, in a framework whose entire public surface is HTTP routes. Odoo controllers are @http.route-decorated methods on classes deriving from http.Controller — for example addons/account_payment/controllers/payment.py::PaymentPortal.invoice_transaction.

Possibly related: only 81 :PyDecorator nodes exist for those 15,549 callables, which also looks low for a codebase using @api.model, @api.depends and @http.route pervasively.

Why this matters more than a missing convenience

Entrypoints are the source set for reachability. A consumer walking forward from sources to sinks treats an undetected entrypoint as a source that does not exist — so every sink reachable only from it is reported unreachable, and a real finding is dismissed as a false positive. The failure is silent and directional: an omission produces no error, just a smaller cone.

PyEntrypointReport's own docstring anticipates exactly this: "The pass under-approximates by design, so silence is its failure mode… What makes a gap visible instead of indistinguishable from 'this project has no entrypoints'." On this application, silence is the whole output.

Two asks, in priority order

1. Project PyEntrypointReport into the Neo4j graph. It is emitted in the JSON path but no :PyApplication property or node carries it, so a Neo4j consumer cannot distinguish "no entrypoints" from "the pass found nothing". The SDK now returns an entrypoint_report_unavailable diagnostic over Neo4j for precisely this reason — it can only say "I cannot tell you".
2. Detect Odoo-style controllers, or record in the report why they were skipped. Related: Framework-independent entrypoint detection (JackEE-style finders) #27 (framework-independent entrypoint finders).

Even without (2), (1) turns a silent wrong answer into a visible gap — which is the distinction the report was designed to draw.

Reproduction

canpy -i odoo-slim-19.0.0 --emit neo4j --neo4j-uri bolt://… --app-name odoo-slim-19 --skip-tests --no-venv

[rahlk]

Triage, reproduced on a small fixture (@http.route method on http.Controller, @app.route flask function, run with --no-venv):

Confirmed, both asks. neo4j/project.py never reads entrypoint_report; nothing on :PyApplication carries it. And rules.yml ships flask, fastapi, celery, click, drf and django only, so odoo is not a known framework at all.

A third defect the report hides. PyEntrypointReport.unresolved has no writer anywhere in the codebase. On the fixture the report comes back unresolved: {} while http.route sits on the method with qualified_name=None. The counter that exists to make silence visible is itself silent.

Why odoo rules alone will not fix detection. Decorator matching keys on PyDecorator.qualified_name, which comes from jedi resolution and is None whenever the framework package is not importable in the analysis environment (--no-venv with odoo not installed). Base-class matching is different: pipeline.py:82 resolves bases from the module's own import table, no jedi. So Ctl(http.Controller) can match a base rule under --no-venv, but @http.route cannot match a decorator rule. Detection for odoo needs an import-table fallback for decorators, the same way bases already work.

Not a defect. 81 :PyDecorator nodes is the count of distinct decorator names. The node is shared and merged by name; the per-use facts ride on the relationship (project.py:645).

Plan, in order: project the report onto :PyApplication (additive graph-contract MINOR); populate unresolved from every decorator and base that fails to resolve; add an odoo framework to rules.yml with the import-table fallback for decorators. Related: #27.