Levyra release validation workflow

Required context

1. Read the root AGENTS.md, app/AGENTS.md, desktop/AGENTS.md, and .github/AGENTS.md as applicable.
2. Read .agents/claude/rules/testing-release.md.
3. Read docs/ai/RELEASE_NOTES_STYLE.md whenever preparing, rewriting, reviewing, or publishing release notes.
4. Load .agents/skills/levyra-humanizer/SKILL.md whenever authoring or rewriting release notes, Fastlane changelogs, release descriptions, or other product-facing release prose.
5. Inspect the complete diff, version files, build configuration, signing inputs, release workflows, artifact paths, and release notes.

Boundaries

Do not change versions, publish, tag, merge, upload, or release unless those actions are separately and explicitly authorized.

Android and Desktop versioning are independent:

• Android uses levyraVersionName and levyraVersionCode in the existing Android configuration.
• Desktop uses desktop/version.properties and desktop-v<version> tags.

Never update one platform's version merely because the other platform is releasing.

Release-note authoring contract

Treat release notes as a product-facing artifact, not a generated commit summary.

Follow docs/ai/RELEASE_NOTES_STYLE.md as the canonical Levyra editorial contract, then apply levyra-humanizer in embedded mode as the mandatory final prose pass.

Authoring order:

1. build the factual release story from the current repository, merged changes, version wiring, and direct validation evidence;
2. write the release notes in Levyra's product voice, preserving every workflow-required heading and exact version field;
3. run levyra-humanizer over the user-facing prose to remove AI-sounding patterns, filler, inflated claims, repetitive structure, stock wording, forced punchlines, unnecessary bold, and chatbot artifacts;
4. compare the humanized result against the factual draft and restore any claim, caveat, version value, validation detail, Markdown target, or required heading that was accidentally changed or removed;
5. read the complete final notes once as a user and once as a release reviewer before publication.

The Humanizer pass may rewrite prose and paragraph structure, but it must not:

• invent or strengthen facts, validation, compatibility, privacy, migration, performance, signing, or publication claims;
• remove a real limitation, failed check, blocked check, unperformed test, or compatibility caveat;
• alter # Levyra <version>, ## Highlights, ## Validation, ## Versioning, ## Upgrade notes, ## Final note, version name/code lines, code blocks, Markdown link targets, hashes, artifact names, commands, or machine-required text;
• turn technical evidence into marketing language;
• erase intentional Levyra house style merely because a generic Humanizer pattern would normally avoid it. In particular, the ✦ section marker is an allowed Levyra editorial convention when used sparingly and consistently.

Follow these editorial rules:

• write natural, professional English that sounds human rather than AI-generated;
• open with what the release changes for users, not commit counts, hashes, PR numbers, or file wiring;
• group meaningful changes into reader-facing sections and prefer ## ✦ ... headings for those sections when the release benefits from them;
• explain both what changed and why it matters in ordinary use;
• keep low-level architecture detail only when it explains reliability, compatibility, privacy, performance, or a deliberate design choice;
• keep exact commit ranges, SHAs, test inventory, workflow responsibilities, and unperformed checks in ## Validation;
• preserve the exact workflow-required headings ## Highlights, ## Validation, ## Versioning, ## Upgrade notes, and ## Final note;
• keep Fastlane changelogs compact and user-facing instead of duplicating the full GitHub release body;
• never invent validation, device evidence, compatibility, privacy, migration, or publication claims to make the release sound stronger.

Before publication, read the complete release notes once as a user. Rewrite any section that still reads like git log, an internal engineering ticket, a mechanical list of commits, or generic AI product copy.

Validation checklist

• inspect repository status/diff for unrelated edits, conflict markers, secrets, keystores, APKs, ZIPs, generated output, and private configuration;
• verify version changes are intentional, monotonic, and limited to the requested platform;
• verify release notes follow docs/ai/RELEASE_NOTES_STYLE.md and levyra-humanizer, remain truthful, and match the current repository;
• compare the pre-humanizer and post-humanizer factual claims when release prose was rewritten;
• run focused tests first;
• run the applicable Android or Desktop wrapper checks when the environment supports them;
• verify signing and API inputs are supplied only through approved local or CI mechanisms;
• compare workflow changes with existing Android release, Desktop release, F-Droid, extractor sync, duplicate guards, and artifact conventions;
• verify package names, filenames, checksums, update metadata, release tags, and expected output paths;
• distinguish CI evidence, local evidence, emulator/device evidence, and unperformed checks.

Android emulator and device evidence

When an Android change needs runtime verification, prefer semantic, reproducible interaction over screen-coordinate automation.

• Confirm adb, the intended SDK/JDK, the connected target, and the exact app/build variant before testing.
• If more than one device or emulator is connected, select the serial explicitly; never assume the first target is correct.
• Separate build, install, launch, interaction, log inspection, and final-state evidence so a successful earlier step is not mistaken for end-to-end success.
• Prefer UI hierarchy, resource IDs, visible text, and accessibility/content descriptions for navigation and assertions. Use raw coordinates only when no stable semantic target exists, and record that limitation.
• Capture focused logcat for the app/process around the reproduction window. Compact repetitive success noise when useful, but keep complete failure, crash, stacktrace, security, and exact-reproduction evidence available raw.
• For playback changes, verify the exact affected path (song/audio mode, native-video mode, queue transition, background/foreground, notification, or other relevant behavior) rather than treating a successful app launch as playback validation.
• Emulator success does not prove physical-device, Android Auto, notification, Bluetooth/media-key, battery, OEM, or hardware-decoder behavior. Report each category separately.

This adopts the strongest idea from SimpMusic's Android emulator workflow: semantic navigation and structured evidence instead of brittle pixel automation, without vendoring its helper scripts into Levyra.

Reporting

List every command/check with its result. A blocked or skipped check is not a pass. Report manual playback, Android Auto, notification, PiP, Windows installer, update, protocol, media-key, and native VLC checks as unverified unless actually performed.