App-analysis roadmap, re-scoped: of five proposed ports, one survives as proposed, one is dropped, three shrink or redirect

[MendixMau]

A roadmap for the app-analysis capability, posted as an idea rather than a set of issues because
its main finding is that less should be built than was proposed, and that is a conversation, not
a task list.

Background: an earlier claims harvest read a source project's analysis tooling and proposed a set
of ports into this toolkit, with estimates. Each proposal was then written up as a spec — and in
writing the spec, each one was checked against a real full catalog rather than against the
harvest's description. In every case the check changed the answer. Verdicts below are quoted from
those specs.

The re-graded proposals

Proposal	Verdict when checked against a real catalog
Lint report section	"Still worth doing, but not as a port." The source script never runs lint — it reads a JSON file something else produced. The instrument we actually lack (something that runs lint and writes a fact) "is the part it does not have."
Security section	"Worth doing, and the boundary the harvest drew is correct." Verified with negative controls: complements reconcile to totals, columns proven non-null, a positive control on the access-rule count. The two "not collectable" claims were confirmed by exhaustive schema grep and full-text search — strict mode, security level, password policy and demo users are not in the catalog.
Loop / transaction patterns	"Two of the four are worth adding cheaply, one is worth adding as an amplifier rather than a finding, and the fourth is already implementable today with the facts we have, at zero parser cost." But not in the estimated half-day: the loop skill had already borrowed two codes from the same source and given them different meanings — a collision the harvest missed.
Severity / priority model	"Mostly done already; the harvest's premise is stale." The claim that "the report reads fail everywhere and says nothing about what to do first" does not hold against the current renderer.
Graph rules	"Downgraded from one day to about two hours, and not a separate port." The three rules called "new" already exist in the catalog views and facts being collected.

Net: of five proposed ports, one survives as proposed, one is dropped, one shrinks to ~2 hours
and folds into existing work, one is redirected to a different instrument than the one proposed,
and one grows rather than shrinks because of a code collision.

Three smaller specs, ready and unblocked

These are self-contained and each already has a written spec against a named file:

Spec	Target	Ask
Index facts	project-bin/app-facts.sh, joined in the loop skill	emit indexes.json so index findings can be joined rather than re-derived
Inventory names	project-bin/app-facts.sh step 2	carry names alongside counts in the inventory facts — a count alone cannot be acted on
Medium-band ordering	bin/app-report.sh (severity model, add(), the sort)	an ordering rule for the unranked middle band, which currently comes out arbitrary

Why this is one idea and not eight issues

Two reasons.

First, the repo currently carries 9 open PRs and 11 open issues. Eight more tracker items would
not make this work more likely to happen; it would make the queue harder to read.

Second, and more important: the useful output here is a decision about scope, and issues are a
poor container for that. Four of the five re-grades reduce or redirect work. An issue implies
someone must close it, and the cheapest way to close "port the severity model" is to port the
severity model — which this spec says is mostly already done.

What would be useful back

1. Does the one clear survivor (security section) get picked up on its own, ahead of the rest?
2. Is the code collision in the loop/transaction item worth resolving first, since it blocks the
   cheap wins behind it?
3. Should the three smaller specs become one PR, given they touch two files between them?