pal-e-docs

Review: Credential input and management UI

review-1699-2026-07-02 Review

review ready
Project

Verdict: READY

Template Completeness

  • [x] Type -- Feature
  • [x] Lineage -- references parent #6, dependencies on spike, #10, #1
  • [x] Repo -- ldraney/kalshi-assistant
  • [x] User Story -- As a Kalshi trader / securely enter and manage API credentials
  • [x] Context -- explains Kalshi API key ID + RSA private key requirement, encryption at rest, credential verification flow
  • [x] File Targets -- 3 create targets, 2 do-not-touch targets
  • [x] Feature Flag -- mobile_credential_management, global, disabled by default
  • [x] Acceptance Criteria -- 5 criteria in when/then format
  • [x] Test Expectations -- 4 tests with run command
  • [x] Constraints -- encryption, pattern adherence, error handling, one-set-per-user
  • [x] Checklist -- PR, tests, no unrelated changes
  • [x] Related -- project, parent, dependencies

Traceability

  • [x] story:credential-onboarding label -- Credential Onboarding
  • [x] story note verified -- found in project-kalshi-assistant user-stories section (key: credential-onboarding, role: Consumer, metric: 90% of users complete setup without support)
  • [x] arch:frontend label -- Frontend component
  • [x] arch note verified -- arch-frontend note exists ("Frontend: kalshi-assistant", architecture, active)
  • [x] arch:auth label -- Authentication component
  • [x] arch note verified -- arch-auth note exists ("Authentication: kalshi-assistant", architecture, active)
  • [x] Forgejo issue -- ldraney/kalshi-assistant#14, open

File Targets

  • [x] app/controllers/credentials_controller.rb -- TO CREATE: standard Rails CRUD controller. Does not exist yet (expected: depends on Rails scaffold #1).
  • [x] app/views/credentials/ -- TO CREATE: form views for key input, status display, verification. Does not exist yet (expected).
  • [x] app/models/credential.rb -- TO CREATE: model with encrypted attributes. Does not exist yet (expected).
  • [x] Do-not-touch: app/controllers/dashboard_controller.rb -- correctly scoped out (separate ticket)
  • [x] Do-not-touch: app/controllers/strategies_controller.rb -- correctly scoped out (separate ticket)
Note: No application code exists yet. The repo is docs-only. All file targets are to-be-created, which is correct since this ticket depends on Rails scaffold (#1) being completed first. The Kalshi API docs confirm RSA-PSS key-pair signing, consistent with the ticket's description of API key ID + RSA private key storage.

Repo Placement

OK. Issue filed on ldraney/kalshi-assistant, matches ### Repo field. Single-repo scope.

Dependencies

  • #1 (Rails app scaffold with Kalshi API client) -- board item #1686, todo column -- DOCUMENTED in Lineage, BLOCKING
  • #10 (Keycloak realm, client, users, and login theme) -- board item #1693, todo column -- DOCUMENTED in Lineage, BLOCKING
  • #13 (Spike: Mobile framework decision) -- board item #1698, backlog column -- DOCUMENTED as "spike (child of #6)" in Lineage, BLOCKING
All three dependencies are correctly identified in the Lineage section and none are complete yet. This ticket is appropriately in backlog until its dependencies move through the pipeline.

Acceptance Criteria

5 criteria, all in clear when/then format and verifiable by an agent:
  • Form with API key ID and RSA private key fields (PEM paste or file upload) -- verifiable via view rendering
  • Submit valid credentials -> stored encrypted + success message -- verifiable via model test + integration test
  • Verify Credentials button -> test API call + status display -- verifiable via controller test with mocked API
  • Update existing credentials -- verifiable via CRUD integration test
  • Revoke credentials with confirmation dialog -- verifiable via destroy action test
Test expectations include 4 tests with a concrete run command. Testable and complete.

Blast Radius

Minimal. Greenfield application with no existing code. The Kalshi API docs (docs/api/overview.md, docs/api/openapi.yaml) confirm the RSA-PSS signing approach matches what the ticket specifies. No downstream consumers to affect. No sibling services to check for similar patterns.

Decomposition Assessment

  • 3 file targets in 1 repo -- OK (under threshold of >3 across >2 repos)
  • 5 acceptance criteria -- OK (not exceeding 5)
  • Estimated agent work: under 5 minutes (standard Rails CRUD + encrypted attributes) -- OK
No decomposition needed.

Recommendation

No action needed. Scope is solid, traceability is complete, template is filled, and the ticket fits comfortably in a single agent pass.