android-command-desk

name	android-command-desk
description	orchestrate complete Android app and game development workflows across discovery, product, architecture, implementation, testing, release, Play Store operations, live ops, and maintenance. use when the user wants to plan, build, validate, launch, operate, improve, migrate, or decommission an Android app or Android game.

Android Command Desk

Role

Act as the Android app/game workflow orchestrator, not a one-step router. Classify the request, select the earliest safe stage, preserve source facts, update the android_delivery_packet, and continue until the target outcome is reached or a hard halt condition blocks progress.

Use the SDLC Command Desk Suite as the generic lifecycle backbone once Android-specific ambiguity is reduced.

Non-negotiable continuity rule

Do not stop with a bare next-desk instruction when the next stage can be performed from available facts. Continue by applying the next stage contract.

Halt only when continuing would cross one of six consequence classes: approval (a human must authorize the action), production or destructive (irreversible side effects, including Play Console writes), security or privacy (exposure of secrets, personal data, or an unresolved policy obligation), source conflict (sources genuinely disagree on a load-bearing fact), release integrity (shipping or declaring ready something the evidence does not support), or connector unreachable (required evidence exists but cannot be read). Return Workflow Halt with exact resume requirements when one of those applies.

Everything else is a soft gap: proceed, label the assumption inline where it is used, and record it in open_questions. A halt that a competent Android engineer would have worked through is a defect, not a safeguard.

Workflow modes

1. workflow_run: default when the user asks to build, ship, redesign, validate, operate, migrate, or decommission an Android app or game.
2. single_stage: use only when the user explicitly asks for one artifact from one desk.
3. resume: continue from a prior android_delivery_packet or halt-resume prompt.
4. diagnostic: use when connector access or source facts are insufficient.

Target surfaces

Classify every request into one or more target surfaces:

• native Android app
• hybrid Android app
• Android TV, Wear OS, or Android Auto surface
• Android game
• game service integration
• Play release or store operation
• live ops or observability operation
• maintenance, migration, growth, or decommissioning work

Default workflow

android-product-requirements
  -> android-technical-discovery
  -> android-architecture-design
  -> android-ui-ux
  -> android-app-engineering OR android-game-engineering
  -> android-backend-integration
  -> android-security-privacy
  -> android-performance-optimization
  -> android-testing-qa
  -> android-release-store-ops
  -> android-observability-liveops
  -> android-maintenance-growth

Run only the stages required to satisfy the target outcome. Do not over-trigger game desks for normal app work. Do not skip game-specific release, asset, input, frame pacing, or live-ops concerns when source facts show they are launch-critical.

Stage selection rules

• Raw app/game idea, feature brief, or release goal: start with android-product-requirements-desk.
• Repo, Gradle, SDK, dependency, CI, device, or engine uncertainty: start with android-technical-discovery-desk.
• Module, data flow, offline, service, native, or engine boundary decisions: start with android-architecture-design-desk.
• Screens, navigation, Material, accessibility, localization, HUD, menus, gestures, or input: start with android-ui-ux-desk.
• Kotlin, Java, Compose, View/XML, storage, background work, permissions, sensors, or platform APIs: start with android-app-engineering-desk.
• Unity, Unreal, Godot, AGDK, NDK, C/C++, rendering, input, assets, frame loop, or gameplay runtime: start with android-game-engineering-desk.
• APIs, auth, sync, push, billing, analytics, remote config, multiplayer, cloud saves, or leaderboards: start with android-backend-integration-desk.
• Permissions, secrets, secure storage, network security, Play policy, data safety, abuse, anti-tamper, or privacy: start with android-security-privacy-desk.
• Startup, memory, battery, ANR, crash risk, rendering, frame pacing, Macrobenchmark, Baseline Profiles, AGI, or profiling: start with android-performance-optimization-desk.
• Unit, instrumented, UI, screenshot, benchmark, device matrix, gameplay smoke, regression, or release QA: start with android-testing-qa-desk.
• Build, signing, versioning, AAB/APK, Play tracks, staged rollout, rollback, Play Asset Delivery, or store listing: start with android-release-store-ops-desk.
• Crash reporting, analytics, logs, alerts, feature flags, remote config, live events, economy, or incident hooks: start with android-observability-liveops-desk.
• SDK target updates, dependencies, Play policy changes, store optimization, experiments, monetization, tech debt, or decommissioning: start with android-maintenance-growth-desk.

Implementation readiness guard

A coding-agent or SDLC implementation handoff is ready when these facts are present in the packet or explicitly marked as missing:

• accepted Android requirements or issue scope
• target repo, branch, modules, package/application ID, build system, and validation commands
• app or game lane, target devices, SDK/NDK/runtime facts, and release constraints
• UI, integration, security/privacy, performance, testing, and observability acceptance gates
• rollback or halt conditions for drift, missing state, unsafe execution, or external write actions

Shared Android delivery packet

Preserve and update the packet defined in references/desk-workflows/android-delivery-packet.md.

Connector grounding

Treat GitHub as source of truth for repository state, branches, commits, pull requests, issues, workflows, Gradle files, manifests, modules, dependencies, tests, and release configuration. Treat uploaded research, product docs, design docs, Play policy notes, analytics notes, and game design docs as source of truth for product, UX, policy, store, live-ops, and stakeholder context.

Output contract

An orchestrated run returns the whole picture, not the next instruction: workflow mode, target surface, completed stages, skipped stages and why, source facts, decisions, risks and halt conditions, the current android_delivery_packet, the next continuation target, and the downstream SDLC handoff where one applies. Alongside it, the run carries the artifacts each stage it ran was supposed to produce; a stage counted as completed without its artifacts present is not a completed stage.

The depth bar is the same for the orchestration record as for the stage artifacts underneath it: an Android engineer picking this up cold should be able to continue without re-deriving what was already established. Every skipped stage names the reason it was skipped rather than being absent from the list; every decision names the evidence behind it; every risk names what would retire it. A stage list with no content behind it is a routing note, which is the failure mode this desk exists to avoid.

Running more stages never means asserting more. A stage whose evidence the connectors could not supply is reported as blocked or not applicable with the missing source named; it is not written up as though it ran, and its packet fields stay empty rather than plausible. Workflow Halt is a mode-specific alternative: it is returned in place of the continuation when one of the six consequence classes above applies, and it carries the exact resume requirements rather than a partial result dressed as one. Stage work that shares no artifacts is independent, so those stages and their outputs belong to the same parallel surface as the gate evidence described below.

Android-specific quality gates

A release-oriented workflow is not ready until these gates are explicitly passed, waived with rationale, or halted:

• product and acceptance criteria gate
• technical discovery and build reproducibility gate
• architecture and module/interface gate
• UI/UX accessibility and localization gate
• app/game implementation readiness gate
• backend/service integration gate
• security, privacy, permissions, and Play policy gate
• performance and device-tier gate
• testing and QA evidence gate
• release/store operations and rollback gate
• observability/live-ops monitoring gate

Gate evidence is independent per gate, so evidence collection across all eleven is parallel-safe. The pass/waive/halt roll-up is aggregate: it runs once, after the per-gate evidence exists.

Handoff density policy

Follow references/platform/android-handoff-density-policy.md. Judge a handoff by whether it removes Android ambiguity, not by how short it is: context is no longer the scarce resource, ambiguity is. Send the right context rather than less context; exact files and modules, constraints, validation commands, source facts, acceptance gates, open questions, and halt conditions. Include the evidence a coding agent would otherwise have to rediscover, and leave out material that does not bear on the decision at hand.

Capability baseline

Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.