[gmemmy]

Problem

The current publication receipt reader changed the derived summary and published next-action text for legacy 1.0.0 receipts. Previously written receipts could therefore pass schema validation but fail semantic admission after upgrading ASL.

What changed

• Preserve the original twoPlatformClaim summary and published next-action wording for 1.0.0 receipts.
• Keep current 1.1.0 receipt wording unchanged.
• Validate legacy pack objects directly after schema admission instead of serializing them through JSON as an internal validation bridge.
• Export and document the legacy semantic validator, with packed-package coverage.
• Add historical round-trip and cross-version wording rejection tests.

Why this approach

Receipt schema versions define their own derived text contract. Version-gating the derivation preserves historical readability without weakening current platform-scope semantics or changing the current writer and CLI request contracts.

Proof

• pnpm typecheck - passed.
• Focused publication receipt tests - 28/28 passed.
• pnpm release:check - passed under an isolated resource lease.
• Full repository test suite - passed.
• Packed package smoke - passed, including the new public export.
• Installed-consumer rehearsal - passed.
• Independent context-rich final review - CLEAN, no P0-P3 findings.
• Device and live runtime proof - not run; this change is receipt compatibility and package-surface behavior.

Risks and limits

• Receipts created during an unreleased mixed-code window with 1.0.0 identity and 1.1.0 wording are not treated as canonical historical receipts.
• Object-only semantic validation does not prove pack-byte identity; the exact-byte APIs remain the authority for that claim.
• This PR does not alter evidence collection, platform coverage, publication transport, or product verdicts.

Stack/review order

• Base: fix(ci): enforce platform scope integrity #350.
• Review and merge after fix(ci): enforce platform scope integrity #350.
• This closes the remaining cumulative publication compatibility finding for the current evidence-contract stack.

Follow-ups

• Complete the cumulative release gate over the fully merged stack before creating the next immutable package candidate.