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 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 without authorization, or switch a primary checkout. If the destination is unavailable, continue source-side analysis and report only the port as blocked with the exact missing location or authority.

3. Establish the validated source basis

Port after the source change forms a coherent batch and passes its required validation. Read the current in-scope source bytes, record their basis for this port pass, and express every change independently of filenames:

• user-visible or operational outcome;
• defect mechanism or invariant;
• canonical source owner and affected callers/readers/writers;
• tests and compatibility behavior that prove it;
• exclusions and intentionally unchanged behavior.

Include the whole current source change: committed, staged, and unstaged bytes in scope. Do not snapshot, lock, stash, hash, clean, or require a stationary source worktree. If source bytes later change, inspect the changed intent and update its destination disposition; repeat the full destination analysis only when the source scope, owner, or architecture changed materially.

4. Re-discover the 0.3 owner

Search 0.3 by domain identifiers, symbols, state shapes, routes, provider or feature ids, persistence keys, and the defect mechanism. Identify its current canonical owner, expanded sibling paths, compatibility seams, tests, and active split-brains.

Classify each source intent as:

• already satisfied in 0.3, with evidence;
• applicable through an adapted 0.3-owned implementation;
• applicable to a broader 0.3 corridor because the architecture expanded;
• not applicable because the path is unreachable or deliberately replaced, with evidence.

Never use matching filenames as completeness proof. Do not cherry-pick blindly, copy whole files, overwrite evolved logic, restore a 0.2 owner, or add a predecessor exclusion that contradicts an intentional 0.3 generalization.