Ladder models that hand-roll journaling record unstamped entries, so #174's payload-shape check does not cover them

[Yaraslaut]

What is true

Four ladder models hand-roll their own journaling instead of going through the
framework's two execution sites, and construct morph::journal::LogEntry
directly:

• examples/ledger/src/models/ledger_model.cpp (LedgerModel::logAction)
• examples/ledger/src/models/budget_model.cpp (BudgetModel::logAction)
• examples/ledger/src/models/rule_model.cpp (RuleModel::logAction)
• examples/kanban/src/models/board_model.cpp (BoardModel::logAction)

The reason is documented and legitimate: morph appends a LogEntry
automatically only on the registry/dispatcher path
(IModelHolder::recordIfAttached), and a directly-constructed model — which is
how every ladder unit test builds one, per examples/IMPLEMENTATION.md rule 5 —
never goes through a holder. examples/lims/include/lims/core/self_journal.hpp
already says this in its file comment and exists to stop the copy count from
growing further.

Why it matters now

PR for #174 adds LogEntry::schema, a payload-shape fingerprint stamped at the
two framework execution sites (ActionDispatcher::registerAction's runner and
Bridge::executeVia's localOp) and checked by journal::replay(). An entry
with no fingerprint is unverifiable, and replay()'s default
UnstampedPayloadPolicy::Replay replays it exactly as before — i.e. a renamed
field still decodes to its default, silently.

So the rungs whose definition of done is "reconstructible from the journal
alone" are exactly the ones the new check does not cover, unless each
hand-rolled copy stamps the field. The one-line fix at each site is:

entry.schema = ::morph::model::detail::actionPayloadSchema<Action>();

Scope correction (was five sites, now four)

This issue originally also listed a fifth site,
examples/lims/src/models/analysis_catalog_model.cpp (AnalysisCatalogModel).
That listing is stale and has been dropped: AnalysisCatalogModel does not
hand-roll LogEntry at all — it calls
_journal.recordSuccess<AnalysisCatalogModel>(...) on a lims::SelfJournal
member (examples/lims/include/lims/models/analysis_catalog_model.hpp:64).

The fix landed for that call path in the exact same PR that filed this issue
(#247): entry.schema = ::morph::model::detail::actionPayloadSchema<Action>();
was added at examples/lims/include/lims/core/self_journal.hpp:169, confirmed
absent in the pre-merge parent commit and present after. SampleModel shares
the same SelfJournal member and picks up the same fix, so it was never a
distinct open site either.

The other four sites (ledger x3, kanban x1) hand-roll LogEntry directly
without going through an equivalent shared helper, so #247's fix — scoped to
SelfJournal — did not touch them. They remain unstamped.

Verification status

Reproduced for the mechanism, re-verified per site against current master.
Each of the five originally-cited sites has been read directly against the
tree that includes #247 (merged a615a6f8):

Site	entry.schema stamped?
examples/ledger/src/models/ledger_model.cpp (LedgerModel::logAction)	No
examples/ledger/src/models/budget_model.cpp (BudgetModel::logAction)	No
examples/ledger/src/models/rule_model.cpp (RuleModel::logAction)	No
examples/kanban/src/models/board_model.cpp (BoardModel::logAction)	No
examples/lims/src/models/analysis_catalog_model.cpp (via SelfJournal)	Yes (already fixed by #247)

Three of the four still-open sites (ledger/budget/rule) are textually
near-identical, down to copy-pasted comments ("See LedgerModel::logAction's
identical comment ..."). This is invariant-6 territory — a guarantee
reimplemented per call site belongs in one place — and it's already been named
once, in examples/lims/include/lims/core/self_journal.hpp's own file
comment, which lists these same sites as the copies it exists to stop
multiplying.

What would change the verdict

Close when every hand-rolled LogEntry construction in examples/** either
stamps schema or documents why it deliberately does not. Currently that
means the four sites above. Re-open if a new unstamped copy appears anywhere
in examples/**.

[Yaraslaut]

Triage: valid

Re-verified fresh against current HEAD (e45fa8323c3efdf167b82c8de1a766ad36da267a, which includes #247 merged as a615a6f8).

Premise check

Mechanism. actionPayloadSchema<Action>() is defined once, in
include/morph/core/registry.hpp:224 (morph::model::detail), and is stamped
at exactly the two framework execution sites the issue names:
registry.hpp:364/:383 (the registry/dispatcher runner) and
bridge.hpp:1473/:1492 (Bridge::executeVia's localOp). journal.hpp's
UnstampedPayloadPolicy doc comment (line 55-71) independently confirms the
failure mode: Replay is the default specifically because refusing unstamped
entries by default would make every pre-existing journal unreplayable, and an
entry is unstamped "when it was written before the field existed, or when
application code appended it directly rather than through an action
execution" — exactly what the four sites below do.

Site count, re-swept over all of examples/. Searched every
attachActionLog/logAction/LogEntry occurrence, not just the four named
sites, to check for a fifth:

• grep -rn "attachActionLog" examples/*/include/*/models/*.hpp examples/*/src/models/*.cpp → hits only in ledger (x3: Ledger/Budget/Rule), kanban (BoardModel), and lims (AnalysisCatalogModel, SampleModel — both via the shared SelfJournal member).
• bank/include/bank/models/transaction_model.hpp mentions IModelHolder::attachActionLog only in a doc comment; it has no member of that name and no logAction — it relies purely on the framework auto-append path, not a hand-rolled copy.
• examples/bookmarks/src/app/app.cpp:276 and examples/concepts/journal_and_outbox.cpp:95 also default-construct LogEntry, but neither is a model's logAction: app.cpp's is App-layer code rebuilding LogEntry from already-persisted outbox rows for OutboxRelay (no Action type in scope to stamp from), and journal_and_outbox.cpp is a standalone concept/demo, not a ladder model. Neither matches the pattern this issue is about.
• lims::SelfJournal::recordRejectedPayload (self_journal.hpp:127-145) also default-constructs an unstamped LogEntry, but structurally cannot stamp one: it exists precisely for the decode-failure case where no Action type is known at all (its own doc comment: "The decode-failure case has no Action to encode"). Not a fixable omission of the same pattern — a different, inherently type-erased case.

Confirmed exactly 4 open sites, matching the issue's corrected count exactly:

Site	entry.schema stamped?
examples/ledger/src/models/ledger_model.cpp:436 (LedgerModel::logAction)	No
examples/ledger/src/models/budget_model.cpp:78 (BudgetModel::logAction)	No
examples/ledger/src/models/rule_model.cpp:24 (RuleModel::logAction)	No
examples/kanban/src/models/board_model.cpp:235 (BoardModel::logAction)	No

lims fix confirmed landed. examples/lims/include/lims/core/self_journal.hpp:169 stamps entry.schema = ::morph::model::detail::actionPayloadSchema<Action>(); inside makeEntry(), which both recordSuccess (line 76) and recordFailure (line 97) call through. git log --oneline -- examples/lims/include/lims/core/self_journal.hpp shows this landed in a615a6f8 (#247), confirming the issue's scope correction (5 → 4 sites) is accurate and current.

One correction to the proposed fix

The issue's one-line fix (entry.schema = ::morph::model::detail::actionPayloadSchema<Action>();) is correct, but it isn't literally a one-line change at every site. actionPayloadSchema lives in morph/core/registry.hpp, and:

• ledger_model.cpp and board_model.cpp already transitively get it (they include <morph/journal/journal.hpp>, which includes ../core/registry.hpp).
• budget_model.cpp and rule_model.cpp include only <morph/journal/action_log.hpp> (confirmed by reading action_log.hpp's own include list — no registry.hpp/journal.hpp pulled in), so those two need #include <morph/core/registry.hpp> added alongside the stamp line.

This doesn't change the verdict — it's a two-line change at two of the four sites instead of one — but is worth noting for whoever implements it so the build doesn't surprise them.

Invariant check

Invariant 6 (a guarantee reimplemented per call site belongs in one place) is correctly named in the issue but correctly not used to expand scope here: the dedup of the ledger/kanban copies into a shared helper (the way lims::SelfJournal centralized its own two models) is already flagged by self_journal.hpp's own file comment as unfinished business, and this issue's closing condition only requires each site to stamp schema — it doesn't fold the dedup in as a precondition. That's the right scope boundary: conflating "should be deduplicated" with "must be stamped" would block the smaller, urgent fix behind a larger refactor.

Verdict

triage: valid. The problem is real (verified against current HEAD, not just read), the count is accurate (4, re-swept from scratch), the fix is a concrete single buildable change at each of the 4 named sites (with the minor include-gap note above), and it does not conflate with the separate, already-flagged dedup concern. Labeling area: journal as the primary area since the gap is in coverage of the journal's payload-shape check (#174/#247), even though the affected code lives under ladder examples.