ledger: four QML bridges publish 15 members no gui/qml file binds

[Yaraslaut]

Summary

ledger's four QML bridges expose 15 QML-visible members that no file under
examples/ledger/gui/qml/ binds. Each is a Q_PROPERTY, a signal or a
Q_INVOKABLE that the metaobject publishes, that a shell hands to QML, and
that nothing in the shipped UI reads, handles or calls.

Found while generalising the metaobject-surface drift guard for #86 — the
audit was pointed at ledger and this is what it said on the first run.

Verification status

Reproduced, on d6690c5 plus the feat/86-qml-surface-drift-guard branch,
locally: macOS (arm64), Homebrew clang 22.1.8, Qt 6.11.1 (Homebrew) — note CI
pins Qt 6.8.1 — Debug,
QT_QPA_PLATFORM=offscreen.

Command:

cmake --build build --target ladder_ledger_tests
QT_QPA_PLATFORM=offscreen build/examples/ledger/ladder_ledger_tests "[qml-surface]"

Real output (the audit's own findings, verbatim):

ledger::gui::LedgerQmlBridge::busy is a Q_PROPERTY no scanned .qml reads (bound as 'ledgerBridge'/'bridge')
ledger::gui::LedgerQmlBridge::busyChanged is a signal no scanned .qml handles (bound as 'ledgerBridge'/'bridge')
ledger::gui::LedgerQmlBridge::refresh is invokable from QML but no scanned .qml calls it (bound as 'ledgerBridge'/'bridge')
ledger::gui::LedgerQmlBridge::undoTransaction is invokable from QML but no scanned .qml calls it (bound as 'ledgerBridge'/'bridge')
ledger::gui::BudgetQmlBridge::busy is a Q_PROPERTY no scanned .qml reads (bound as 'budgetBridge'/'bridge')
ledger::gui::BudgetQmlBridge::busyChanged is a signal no scanned .qml handles (bound as 'budgetBridge'/'bridge')
ledger::gui::BudgetQmlBridge::categoryCreated is a signal no scanned .qml handles (bound as 'budgetBridge'/'bridge')
ledger::gui::BudgetQmlBridge::budgetCreated is a signal no scanned .qml handles (bound as 'budgetBridge'/'bridge')
ledger::gui::BudgetQmlBridge::limitSet is a signal no scanned .qml handles (bound as 'budgetBridge'/'bridge')
ledger::gui::BudgetQmlBridge::lastBudgetId is invokable from QML but no scanned .qml calls it (bound as 'budgetBridge'/'bridge')
ledger::gui::BudgetQmlBridge::linkAccount is invokable from QML but no scanned .qml calls it (bound as 'budgetBridge'/'bridge')
ledger::gui::RuleQmlBridge::busy is a Q_PROPERTY no scanned .qml reads (bound as 'ruleBridge'/'bridge')
ledger::gui::RuleQmlBridge::busyChanged is a signal no scanned .qml handles (bound as 'ruleBridge'/'bridge')
ledger::gui::RuleQmlBridge::ruleCreated is a signal no scanned .qml handles (bound as 'ruleBridge'/'bridge')
ledger::gui::RuleQmlBridge::ruleUpdated is a signal no scanned .qml handles (bound as 'ruleBridge'/'bridge')

Cross-checked by hand, independently of the audit — none of these names occurs
anywhere in the rung's QML:

$ grep -rn "refresh\|busy\|undoTransaction\|linkAccount\|lastBudgetId\|ruleCreated\|ruleUpdated\|categoryCreated\|budgetCreated\|limitSet" examples/ledger/gui/qml/
$   # (no output)

ReportQmlBridge is clean: every member it publishes is bound by
ReportView.qml.

Not verified: whether each of the 15 is dead surface that should be deleted
or missing UI that should be added. That is a per-member judgement this issue
does not make. Two shapes are visible from reading, and are stated as
inferences, not measurements:

• busy / busyChanged appear on three of the four bridges with no QML
  consumer on any of them. That looks like a base-class-shaped convention
  applied uniformly and never wired up, not three independent oversights.
• undoTransaction, linkAccount and lastBudgetId are single features with
  a model and a presenter behind them and no control in the UI.

Why it matters

Each is either surface a reader will believe is live, or a UI gap. Neither is
visible today: QML resolves by string, so an unbound bridge member costs
nothing at run time and produces no warning anywhere.

Note the asymmetry — the other direction was clean. No ledger QML file
binds a name its bridge lacks, so nothing here is a broken screen today.

What would change the verdict

Close this when examples/ledger/tests/test_ledger_qml_surface.cpp passes with
its allowUnbound() list empty. That file exists on the #86 branch and
currently carries exactly these 15 members as exemptions, each citing this
issue. Removing an exemption without either deleting the member or binding it
from QML fails the test, so the list cannot be quietly abandoned.

Re-open if a later rung re-adds unbound surface to these four bridges — but
that should not be possible without deliberately adding an exemption, which is
the point of the guard.

[Yaraslaut]

Triage: triage: valid

Verified empirically, independent of the issue's own grep, on master at
d6690c56 (current HEAD): read all four bridge headers
(examples/ledger/gui_lib/{ledger,budget,rule,report}_qml_bridge.hpp) and all
five QML files under examples/ledger/gui/qml/, then grepped each of the 15
claimed names individually against examples/ledger/gui/qml/:

refresh, busy, busyChanged, undoTransaction, categoryCreated, budgetCreated,
limitSet, lastBudgetId, linkAccount, ruleCreated, ruleUpdated

— zero matches for every one, across all five .qml files. Confirmed by
hand-reading LedgerView.qml, BudgetView.qml, RulesView.qml,
ReportView.qml and Main.qml line by line: none references any of the 15.
ReportQmlBridge's claimed cleanliness also checks out — status, lines,
lastError, requestMonthlyStatement and openLedger are each bound in
ReportView.qml/Main.qml.

Also confirmed busy() on all three affected bridges forwards to real
presenter state (_presenter.busy()), not stub surface — so this is live,
meaningful surface with no UI consumer, not dead scaffolding.

Not a framework-architecture problem. None of the seven invariants is
implicated: busy/busyChanged are independently declared Q_PROPERTYs per
bridge (not inherited from a shared base), so this isn't invariant 2's
forced-base-class shape — it's copy-paste convention that never got wired to
a control, which is a rung-local application gap, correctly scoped as
area: qt + area: ladder rather than area: core.

Not vacuous test infra (invariant 7 check). Read
examples/common/testkit/qml_surface.hpp/.cpp on
feat/86-qml-surface-drift-guard (f34dd440): QmlSurfaceAudit parses the
rung's actual .qml text for calls/property-reads/Connections handlers and
resolves each against the live QMetaObject, sweeping both directions, and
explicitly detects its own vacuity conditions (no QML files found, a bound
alias nothing mentions, a bridge with no members, run() with nothing bound).
This is real, working infrastructure, not a check that would pass if the
feature did nothing — it already found these 15 findings on first run.

examples/ledger/tests/test_ledger_qml_surface.cpp on that branch pins
exactly these 15 names in allowUnbound(..., "tracked in morph#239"), and the
audit fails if an exemption is ever added for a member that's since been
deleted or since bound — so the backlog can only shrink deliberately, matching
the issue's stated closing condition.

Traced to origin: the ladder plan doc
(docs/superpowers/plans/2026-08-19-ledger-rung5.md, Task 22) sketches
main.cpp/QML as illustrative scaffolding for an implementing agent to flesh
out — it does not scope out undoTransaction/linkAccount/lastBudgetId or
the busy wiring. This reads as implementation drift during Task 22, not a
deliberate reduction in scope, so triage: parked does not fit.

Verdict: triage: valid. The issue does not prescribe a fix — it
correctly declines the per-member delete-or-bind judgment call and gives a
falsifiable, already-implemented closing condition (empty allowUnbound()
list on the drift-guard branch). Labels already applied (bug, area: qt,
area: ladder) are correct and are left as-is.

No duplicate exists; #240 (adopting the same guard in lims/kanban/bank)
is a distinct, already-filed issue and is not touched by this triage.