Levyra CI Workflows

Levyra CI and workflow workflow

Required context

1. Read the root AGENTS.md and .github/AGENTS.md.
2. Read .agents/claude/rules/testing-release.md and .agents/claude/rules/security.md.
3. Inspect every workflow, reusable action, script, build file, secret/input contract, artifact path, and trigger affected by the change.
4. Inspect recent failing job logs when the task is a CI failure; do not infer a root cause from the check title alone.

Exact SHA and Actions evidence

When the task names a commit SHA, treat that SHA as the evidence key even when it has no pull request.

1. Work from the specialist agent's own ./repo checkout, not a parent agent's relative path or inherited working directory.
2. Fetch remote evidence as needed and verify that the requested SHA resolves in the local checkout before drawing conclusions.
3. Query GitHub Actions by the exact head_sha and include push-triggered, pull-request-triggered, and manually triggered runs that belong to that SHA.
4. Do not treat an empty commit-status surface, missing PR association, or empty PR-only run query as proof that CI does not exist. Cross-check the Actions runs surface for the SHA before reporting no CI or not verifiable.
5. Distinguish no run exists, run queued, run in progress, run completed, run cancelled, and run failed. Report workflow name, run id when available, event, exact SHA, and conclusion.
6. If a delegated handoff contains both a PR and SHA, verify the PR head still equals the supplied SHA before using PR-scoped evidence.

For GitHub CLI inspection, prefer a SHA-filtered run query such as gh run list --repo LUC4N3X/Levyra-deepsound --commit <sha> or the GitHub Actions runs API filtered by head_sha. Use PR-scoped queries only when the task is explicitly PR-scoped.

Guardrails

• Keep workflow permissions at least privilege and explicit where practical.
• Treat pull_request, pull_request_target, forks, checked-out code, issue comments, and workflow dispatch inputs as distinct trust boundaries.
• Never expose secrets to untrusted code or upload secret-bearing files as artifacts.
• Reuse existing release, validation, extractor-sync, F-Droid, and duplicate-guard workflows instead of creating parallel automation.
• Pin or constrain third-party actions according to the repository's existing policy and review supply-chain impact before adding one.
• Keep Android and Desktop release triggers, versions, tags, artifacts, and Latest-release behavior separate.
• Preserve artifact names and paths relied on by downstream jobs or release steps.
• Ensure caches use safe, deterministic keys and cannot substitute untrusted executable output across trust boundaries.
• Make no-change, skipped, cancelled, and failed outcomes visible and semantically distinct.

Kotlin and AGP 9 guardrails

Levyra currently uses AGP 9.x and built-in Kotlin support in the Android application module. Treat build-tooling edits as compatibility work, not routine cleanup.

Before changing AGP, Kotlin, KSP, Gradle, Compose tooling, source sets, compiler options, or module plugins:

1. inspect settings.gradle.kts, root and affected module build.gradle.kts files, gradle/libs.versions.toml, gradle/wrapper/gradle-wrapper.properties, and gradle.properties;
2. classify the affected module from its actual plugins instead of inferring KMP merely because the repository also contains a Desktop client;
3. compare the proposed change with the current official Kotlin/Android Gradle guidance when behavior is version-sensitive;
4. keep the change limited to the migration or compatibility issue that actually exists.

Levyra-specific rules:

• Do not reintroduce org.jetbrains.kotlin.android into the AGP 9 Android app; AGP provides built-in Kotlin support for the Android application plugin.
• Keep annotation processing on KSP where supported. Do not introduce org.jetbrains.kotlin.kapt as a convenience workaround; any legacy-kapt fallback requires an explicit task and compatibility justification.
• When compiler options must change, use the current Kotlin compiler DSL rather than reviving deprecated android.kotlinOptions configuration.
• Do not restructure Android and Desktop into a shared KMP application merely because a generic migration guide recommends that layout. Levyra's Android and Desktop products remain independently versioned and released unless the owner approves an architectural change.
• Do not upgrade AGP, Kotlin, KSP, Gradle, JDK, SDK tools, or Compose dependencies as collateral cleanup in an unrelated CI/build fix.
• If the official Kotlin/kotlin-agent-skills package is available, use kotlin-tooling-agp9-migration as an additional reference for AGP 9 migration work, then adapt it to Levyra's real module graph and repository rules rather than copying its target structure wholesale.

These guardrails intentionally take the useful AGP 9 compatibility checks from JetBrains' Kotlin agent skill while keeping Levyra's existing architecture authoritative.