Payload fingerprint renders every custom-codec type as the same opaque tag, so a retype between two of them is invisible

[Yaraslaut]

What is true

morph::model::payloadShapeString<A>() (include/morph/core/payload_schema.hpp,
added for #174) renders every type that carries its own glz::meta as the
single opaque tag x, because it deliberately refuses to use glz::name_v —
that name is derived from __PRETTY_FUNCTION__/__FUNCSIG__ and differs
between compilers, and a journal fingerprint that changes when the compiler
changes would make a journal unreadable by a peer build.

Measured on the #174 branch (clang++ -std=c++23, standalone probe):

struct WithSpecial {
    morph::math::Rational amount;
    morph::time::Timestamp at;
    morph::util::Tagged<std::string, "acct"> id;
};
payloadShapeString<WithSpecial>()  ->  (amount:x,at:x,id:x)

So swapping Rational for Timestamp in a recorded action's field does not
change the fingerprint, and replay()'s mismatch gate does not fire. (Swapping
a custom-codec type for a plain one is caught — x versus s — and every
member rename, addition, and removal is caught regardless of the member types.)

This is documented as a known boundary in docs/spec/journal/journal.md, "What
the fingerprint does not catch". Filing it so the boundary is tracked rather
than only described.

What a fix would need

A per-type discriminator that is stable across compilers, standard libraries,
and platforms — not a compiler-spelled type name. Candidates:

• An opt-in trait a custom-codec type specialises to declare its own stable
  shape tag (morph::model::PayloadShapeTag<T>), defaulted to x. Cheap;
  requires each such type to opt in, and a new type silently gets x again.
• Hashing glz::write_json_schema<T>(). Type-aware and derived, but its
  $defs keys come from glz::name_v, which reintroduces exactly the
  portability problem — would need the $defs normalised away first.

Verification status

Reproduced. The probe above was compiled and run on the #174 branch. Not
measured: whether any shipped action in examples/** actually has two
custom-codec fields whose types could plausibly be swapped for one another —
this is a gap in the mechanism, not an observed defect in a rung.

What would change the verdict

Close when the fingerprint distinguishes at least Rational, Quantity,
DateTime, and Tagged from one another without introducing a
compiler-dependent term, or when a decision is recorded that x is the
permanent answer and the spec's boundary paragraph is the whole story.

[Yaraslaut]

Triage: triage: valid

Premise verified empirically. Standalone probe against include/morph/core/payload_schema.hpp as merged in #247 (clang++ 20, -std=c++23, -fsyntax-only then a full build+run — no application build, no GUI):

struct WithSpecial {
    morph::math::Rational amount;
    morph::time::Timestamp at;
    morph::util::Tagged<std::string, "acct"> id;
};
struct WithSpecialRetyped {           // amount: Rational -> Timestamp
    morph::time::Timestamp amount;
    morph::time::Timestamp at;
    morph::util::Tagged<std::string, "acct"> id;
};

Output:

WithSpecial         shape: (amount:x,at:x,id:x)
WithSpecialRetyped  shape: (amount:x,at:x,id:x)
WithSpecial         fp:    1:bdcdde098eed14c6
WithSpecialRetyped  fp:    1:bdcdde098eed14c6
COLLISION (retype invisible to fingerprint): YES

Individually: Rational, Timestamp, DateTime, and Tagged<std::string,"acct"> all render as the bare opaque tag x — confirming the issue's claim is not specific to one pair of types but holds across every custom-codec type in the tree that has its own glz::meta/hand-written glz::from/glz::to.

Also re-verified the issue's two counter-claims, to make sure the gap is exactly as scoped and not wider:

A         -> (amount:x,count:i4)
ARenamed  -> (count:i4,total:x)      // rename: caught (different string)
APlain    -> (amount:f8,count:i4)    // custom-codec -> plain: caught (x vs f8)

Rename and custom-to-plain swaps are correctly caught. The gap is precisely
"custom-codec type A swapped for custom-codec type B," as stated.

Invariant check. Invariant 7 ("would this still pass if the feature did
nothing?") applies to exactly this slice of the fingerprint's domain: for a
retype between two glz::meta-bearing types, the mechanism emits the
identical x whether or not the check runs — no discriminating signal exists
for that category. It does not invalidate the mechanism as a whole (renames,
additions, removals, and custom→plain swaps all genuinely discriminate, as
re-verified above); it identifies one specific hole in an otherwise-working
control.

Why this isn't bug. docs/spec/journal/journal.md ("What the
fingerprint does not catch") and the doc comment on kOpaqueShapeTag in
payload_schema.hpp both already state this exact boundary as a deliberate
choice: a glz::name_v-derived tag was rejected because it is
compiler-spelled (__PRETTY_FUNCTION__/__FUNCSIG__) and would make a
journal fingerprint change when the compiler changes, which was judged the
worse failure mode. The mechanism is doing exactly what its own spec says it
does — this is a documented, accepted gap in newly-shipped code, not a defect
in shipped behavior. enhancement (already applied) is the correct category;
not adding bug.

Verdict: triage: valid. The problem is real, well-scoped (confirmed to
be exactly "custom-codec-to-custom-codec retype," nothing wider), reproduced
against the actual merged code, and the issue's own two candidate directions
(an opt-in PayloadShapeTag<T> trait defaulting to x; or a
glz::name_v-free hash of glz::write_json_schema<T>()'s $defs) are both
consistent with the architecture — neither reintroduces the
compiler-dependence #174/#247 deliberately avoided. Recommend the opt-in
trait: it composes as a specialization (no base class, invariant 2) and fails
safe (new/unmigrated custom-codec types silently keep today's x, i.e. no
regression versus current behavior).

Labels applied: area: journal (present), enhancement (present),
triage: valid (added). No bug — see above.