happier-port-0-2-to-0-3

# Happier Port 0.2 to 0.3 Own the forward-port lifecycle from the 0.2 release line to the 0.3 development line. Treat checkout paths as runtime inputs, never as product or release identities. ## 1. Load the owning workflows Use: - `.agents/skills/happier-compatibility` for released and prospective wire, persistence, semantic, and operational contracts; - `.agents/skills/happier-implement` and `.agents/skills/happier-testing` for destination changes and RED -> GREEN proof; - `.agents/skills/verify-claims` before relying on source reports or delegated conclusions; - `.agents/skills/attack-conclusion` and `.agents/skills/handoff-report` for closeout. Read [port-workflow.md](references/port-workflow.md) before acting. ## 2. Resolve source and destination explicitly Obtain or discover two independent Git checkouts: - the 0.2 source line containing the complete validated change; - the 0.3 destination line that must preserve its intent. Prefer an explicit destination supplied by the user or calling workflow. Otherwise, try the optional sibling alias `../v0.3.x`, then verify that it is a Git checkout for the intended Happier repository before using it. If the alias is absent or resolves incorrectly, ask for the destination location; do not create or repair filesystem aliases implicitly. Verify repository identity, branch/commit basis, dirty state, and current bytes. Do not infer a release line from a directory name, assume a sibling path exists, create or clone a checkout w...