pal-e-docs

Review: Google Play Store submission

review-1885-2026-07-25 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type (Feature)
  • [x] Lineage
  • [x] Repo
  • [x] User Story
  • [x] Context
  • [x] File Targets
  • [x] Feature Flag (none -- acceptable, this is store submission config)
  • [x] Acceptance Criteria
  • [x] Test Expectations
  • [x] Constraints
  • [x] Checklist
  • [x] Related

Traceability

  • [x] story:android-app label -- present on board item
  • [ ] story note MISSING -- [SCOPE] No android-app entry in project-iss user-stories section. The table lists ios-app but has no Android counterpart. Create user story entry on project-iss user-stories section.
  • [x] arch:app label -- present on board item
  • [ ] arch note WRONG PROJECT -- [SCOPE] arch-app note exists but belongs to Prediction Assistant (Kalshi), not ISS. Either create an ISS-specific architecture note (e.g., arch-iss-app or arch-android) or re-label the board item with a more specific arch tag.
  • [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/iss-android/issues/1, open

File Targets

  • [x] app/build.gradle.kts -- verified: file exists in iss-android repo. Currently has release buildType with minify/proguard but no signing config. Ticket correctly identifies this needs signing config added.
  • [x] fastlane/Fastfile -- directory does not exist (expected). Ticket marks this as conditional ("if using Fastlane"). Acceptable.
  • [x] Store assets directory -- new directory, does not exist yet (expected for new creation).

Repo Placement

OK. Issue is filed on ldraney/iss-android, board item is on board-iss. The Android app is part of the ISS ecosystem. The issue body correctly states ### Repo: ldraney/iss-android. No cross-repo code changes needed -- only the iss-android repo is modified.
However, there is an implicit dependency on the ISS Rails app for the privacy policy page (see Dependencies).

Dependencies

  • Privacy policy page (UNDOCUMENTED BLOCKER) -- The Constraints section states "Need privacy policy page deployed before submission" and AC #5 references intelligentstaffingsystems.ai/privacy. However: no /privacy route exists in the ISS Rails app, no privacy view template exists, and no board item on board-iss tracks this work. This is an undocumented external dependency that blocks Play Store submission.
  • Store assets -- Screenshots and 1024x500 feature graphic are listed as constraints but no source or process is documented for producing them.
  • iOS app (#1798) -- Done. The Android ticket mirrors the iOS app pattern. No blocking dependency.
  • Landing page rewrite (#1883/#95) -- In backlog, sprint:E. Not a direct dependency, but if the landing page changes significantly, Play Store screenshots may need updating.

Acceptance Criteria

7 acceptance criteria. Most are manual external operations that an agent cannot perform or verify programmatically:
  • Agent-automatable: AC #2 (signed release AAB), partially AC #5 (setting URL in config)
  • Manual/external: AC #1 (Google Play Developer account -- requires payment), AC #3 (Play Store listing -- requires Google Play Console), AC #4 (content rating questionnaire), AC #6 (app live on Play Store), AC #7 (install link works)
The test expectations are both manual. This is reasonable for a store submission ticket, but means an agent can only handle the build/signing automation portion. The ticket should clarify which AC are agent work vs. human work.

Blast Radius

Self-contained to iss-android repo for code changes. The privacy policy dependency touches the ISS Rails app but is a separate concern. No downstream consumers affected. No similar patterns in sibling services need updating.

Decomposition Assessment

7 acceptance criteria (exceeds 5-AC threshold on count). However, the agent-automatable work is small: adding signing config to app/build.gradle.kts and optionally scaffolding a Fastlane lane. Estimated agent work: <5 minutes for the code changes. The remaining AC are manual operations. No decomposition needed for the code portion, but the ticket would benefit from clearly separating agent work from manual steps.

Recommendation

  • [SCOPE] Create android-app user story entry in the project-iss user-stories section. Mirror the existing ios-app story pattern.
  • [SCOPE] The arch-app note belongs to Prediction Assistant, not ISS. Either create an ISS-scoped arch note (e.g., arch-iss-android) or re-label the board item with a valid arch tag for the ISS project.
  • [BODY] Add a dependency note: "Blocked by: privacy policy page on ISS Rails app (no route/view exists yet). Needs a separate ticket or must be completed before this ticket can finish."
  • [BODY] Clarify which AC are agent-automatable vs. manual human steps. Consider splitting into: (a) agent ticket for build/signing config, (b) manual checklist for Play Store operations.
  • [BODY] Document the process for producing store assets (screenshots, feature graphic, icon). Are these generated from the running app? Designed manually?