pal-e-docs

Review: Mobile app — API key connection and strategy dashboard

review-1691-2026-07-02 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type — Feature
  • [x] Lineage — present ("Depends on all backend tickets (#1-#5)")
  • [x] Repo — present (ldraney/kalshi-assistant)
  • [x] User Story — full As a / I want / So that format
  • [x] Context — good description with user flow reference
  • [ ] File Targets — present but "TBD" — not actionable for an agent
  • [x] Feature Flag — "none"
  • [x] Acceptance Criteria — 6 criteria present
  • [ ] Test Expectations — present but "TBD based on framework choice" — not actionable
  • [x] Constraints — 3 constraints present
  • [x] Checklist — present
  • [x] Related — present

Traceability

  • [x] story:app-experience — App Experience — verified in project-kalshi-assistant user-stories section
  • [x] story:credential-onboarding — Credential Onboarding — verified in project-kalshi-assistant user-stories section
  • [ ] arch:frontend — arch note MISSING — [SCOPE] Create architecture note arch-frontend for component frontend
  • [ ] arch:auth — arch note MISSING — [SCOPE] Create architecture note arch-auth for component auth
  • [x] Forgejo issue — https://forgejo.tail5b443a.ts.net/ldraney/kalshi-assistant/issues/6, open

File Targets

  • [ ] File Targets are "TBD — depends on frontend framework decision (React Native / Flutter / Rails Turbo Native)" — no concrete paths to verify. The codebase currently contains only docs (no application code). An agent cannot act on this ticket until file targets are specified.

Repo Placement

Issue is filed on ldraney/kalshi-assistant and the Repo section matches. However, a mobile app (React Native or Flutter) may warrant a separate repo. This decision is blocked on the framework choice. If the frontend lives in a separate repo, the Forgejo issue should be refiled there.

Dependencies

  • Documented: #1-#5 (all backend tickets). All are in backlog. Sprint:4 sequencing is correct — this ticket runs after sprint:1-3 backend work.
  • Undocumented: #10 (Keycloak realm, client, users, and login theme — board item #1693, sprint:1, arch:keycloak,arch:auth) is a clear dependency for the auth flow. The mobile app needs Keycloak for user login and session management, but #10 is not listed in the Lineage section.
  • All dependencies are in backlog — none are blocking this ticket from scoping, but all must be completed before implementation.

Acceptance Criteria

6 criteria spanning multiple feature areas:
  • Auth: API key + private key input screen with validation; User can revoke API access
  • Strategy: Strategy selection (Watchdog, Option D); Budget configuration per strategy
  • Dashboard: Live dashboard: active positions, unrealized P&L
  • History: Trade history log
Each criterion is testable in principle, but "Live dashboard: active positions, unrealized P&L" is vague — it should specify what data source, refresh interval, and failure states. The criteria span at least 4 distinct screens/features, making this too broad for a single agent pass.

Blast Radius

Limited. No existing frontend code to break. The codebase contains only documentation. This ticket introduces a new surface area. Downstream effects: the auth flow touches Keycloak (ticket #10) and all API endpoints from backend tickets #1-#5.

Decomposition Assessment

NEEDS DECOMPOSITION — route to skill-decompose-ticket
  • 8 points (largest ticket on the board)
  • 6 acceptance criteria spanning 4+ feature areas (auth, strategy config, live dashboard, trade history)
  • File targets TBD — likely many files for a full mobile app
  • Framework decision is an unresolved prerequisite — should be a separate Spike ticket
  • Estimated agent work: well over 5 minutes (full mobile app with auth, multiple screens, real-time data)

Recommendation

  • [SCOPE] Create architecture note arch-frontend for component frontend
  • [SCOPE] Create architecture note arch-auth for component auth
  • [SCOPE] Framework decision (React Native / Flutter / Rails Turbo Native) should be resolved first — consider creating a Spike ticket to evaluate options and make this decision before decomposing
  • [BODY] File Targets are "TBD" — need concrete paths after framework decision is made
  • [BODY] Test Expectations are "TBD" — need concrete test commands after framework decision
  • [BODY] Add Keycloak ticket (#10) to Lineage as a dependency: "Depends on #10 (Keycloak) and all backend tickets (#1-#5)"
  • [DECOMPOSE] 8 points, 6 AC across 4 feature areas (auth, strategy, dashboard, history) — route to skill-decompose-ticket. Suggested split: (1) Spike: framework decision, (2) API credential input + validation, (3) Strategy selection + budget config, (4) Live dashboard, (5) Trade history, (6) Access revocation