Omh Mobile Release

Catalog Metadata

Category: planning Phase: mobile-release Hermes role: planner Quality tier: store-gate-halt-planned Reasoning demand: standard

Quality bar:

• Name the halt and the replacement build before any rollout step.
• Load references/mobile-release-method.md for the per-platform signing, privacy, beta, rollout and hotfix table instead of recalling store rules.
• Check the privacy declarations against the SDK list the build actually ships, not the one in the plan.
• Keep iOS and Android steps separate wherever the stores differ.
• Keep prepared, submitted, approved, and released as separate states for every build.

Handoff policy:

Keep the signing plan, privacy declaration check, beta plan, staged rollout, and hotfix plan in Hermes. Build numbers, review outcomes, crash-free rates and rollout percentages are recorded only from store console, crash reporting, executor, or operator observed output; OMH never builds, signs, uploads, or submits a build.

Required inputs:

• the platforms, the app's bundle or package id, and the version and build number going out
• how signing is set up today: certificates, provisioning profiles, the keystore or upload key, and who holds them
• the SDKs the build ships, for the privacy manifest and the data safety form
• the beta channel and testers, and what they must verify before the rollout
• the crash-free and ANR figures the rollout will be judged on, observed from the consoles or crash reporting

Expected outputs:

• signing_plan/v1
• privacy_declaration_check/v1
• beta_channel_plan/v1
• staged_rollout_plan/v1
• hotfix_plan/v1

Artifact expectations:

• signing_plan/v1 names each certificate, provisioning profile, keystore, and upload key with its expiry and where it is held, and never contains the secret itself
• privacy_declaration_check/v1 compares the iOS privacy manifest's required-reason APIs and the Play data safety form against every SDK the build ships, and names each mismatch
• beta_channel_plan/v1 names the TestFlight group or Play testing track, whether it needs beta review, the testers, and the checks that must pass before the rollout
• staged_rollout_plan/v1 lists the rollout steps (App Store phased release or Play staged percentages) with the crash-free and ANR thresholds that halt each step
• hotfix_plan/v1 halts the bad rollout, names the higher build number that replaces it, whether to request an expedited review, and any server-side flag that contains the damage first

Safety rules:

• A store release cannot be rolled back; plan the halt and the next build number before the rollout starts.
• Never commit or paste a signing key, keystore, certificate, or provisioning secret; name where it lives and who holds it.
• Do not submit a build whose privacy manifest or data safety form disagrees with the SDKs it ships.
• Advance a staged rollout only on observed crash-free and ANR figures; a prepared threshold is not a passed one.
• OMH never builds, signs, uploads, or submits; every build number, review outcome, and rollout figure comes from observed output or is marked unverified.

Runtime Evidence

Preferred harness for this skill: app-delivery-loop.

omh runtime record --skill mobile-release --harness app-delivery-loop --status started

Record observed delegation results; otherwise return not_available or not_observed. Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.

• Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes. Preserve workflow intent and stop conditions; verify before claiming completion. Reply in the user's own words and the host's own voice: its SOUL.md persona owns reply language, tone, speech level, and sentence endings, progress updates included (where it sets no language, use the one the user wrote in), and OMH shapes structure and content only; OMH's record terms (surface, lane, wrapper, handoff, evidence boundary, not_observed) stay in records and tool calls, never in the sentence the user reads unless they ask about one; and when a stop condition or a decision the user owns ends the turn, offer the next action as a question rather than declaring what will not be done.

Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.

Shared product, compatibility, topology, memory, harness, and execution rules: omh-routing/references/skill-common-rail.md. Load it when applicable; otherwise name an unavailable capability.