pal-e-docs

Review: Watchdog -- auto-buy when market crosses 85% threshold

review-1689-2026-07-02 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

Issue type: Feature (template-issue-feature)
  • [x] Type -- "Feature"
  • [x] Lineage -- documents deps on #2 (scanner) and #3 (schema)
  • [x] Repo -- ldraney/kalshi-assistant
  • [x] User Story -- present, well-formed
  • [x] Context -- references watchdog-strategy.md, API endpoint verified
  • [x] File Targets -- 3 CREATE targets listed
  • [x] Feature Flag -- watchdog_live_trading, global, disabled by default
  • [x] Acceptance Criteria -- 6 criteria listed
  • [x] Test Expectations -- unit tests + run command
  • [x] Constraints -- dry-run default, logging, error handling
  • [x] Checklist -- present
  • [x] Related -- present

Traceability

  • [x] story:watchdog-trading label -- verified in project-kalshi-assistant user-stories section
  • [x] story note verified -- "Watchdog Trading" entry exists with success metric "85%+ win rate, $0.10-$0.15 avg profit per contract"
  • [ ] arch:app note MISSING -- [SCOPE] No arch-app note exists in pal-e-docs. Project page references arch-domain-kalshi-assistant, arch-dataflow-kalshi-assistant, arch-deployment-kalshi-assistant instead. Label may need realignment.
  • [ ] arch:api note MISSING -- [SCOPE] No arch-api note exists in pal-e-docs. Same mismatch with project page architecture naming.
  • [x] Forgejo issue -- ldraney/kalshi-assistant#4, state: open

File Targets

  • [ ] app/services/watchdog_service.rb -- ISSUE: app/ directory does not exist yet. Requires Rails scaffold (issue #1) to be completed first. Correctly marked as CREATE target.
  • [ ] app/jobs/watchdog_job.rb -- ISSUE: Same dependency on #1 for app/ directory to exist.
  • [ ] app/services/order_service.rb -- ISSUE: Same dependency. Also note: this is a shared service that Option D sizing (#5) will likely also need.
The referenced docs/strategy/watchdog-strategy.md DOES exist and confirms the strategy description. API endpoint POST /portfolio/events/orders with side: bid confirmed in openapi.yaml (line 1143). The strategy doc uses the full path /trade-api/v2/portfolio/events/orders.

Repo Placement

OK -- issue filed on ldraney/kalshi-assistant, all file targets are in the same repo. Single-repo ticket.

Dependencies

  • Documented: #2 Market scanner (sprint:2, backlog), #3 Strategy engine schema (sprint:2, backlog)
  • Undocumented: #1 Rails app scaffold (sprint:1, backlog) -- the app/ directory structure comes from the scaffold. This ticket cannot be implemented without #1.
  • Sprint ordering: Correct -- this is sprint:3, dependencies are sprint:1 and sprint:2
  • Board state: All 12 items are in backlog. No items are in_progress or blocking.
  • Downstream: #5 Option D sizing (sprint:3) may share order_service.rb

Acceptance Criteria

6 criteria, all verifiable by an agent:
  • [x] Threshold detection (yes_bid >= confidence_threshold) -- unit testable
  • [x] API order placement (POST /portfolio/events/orders, side: bid) -- integration testable with HTTP mocks
  • [x] Trade record creation with order_id -- DB assertion testable
  • [x] Sell triggers at 95%+ (take profit) and below 80% (cut loss) -- unit testable
  • [x] Dry-run mode logs without executing -- unit testable with feature flag mock
  • [x] Pick and Trade record creation -- DB assertion testable
All criteria are concrete and testable. Count of 6 exceeds the >5 decomposition threshold.

Blast Radius

Greenfield project -- no existing application code to conflict with. order_service.rb is a candidate shared service (also needed by #5 Option D sizing). No sibling services or downstream consumers exist yet.

Decomposition Assessment

  • 3 file targets in 1 repo -- OK (under the >3 files across >2 repos threshold)
  • 6 acceptance criteria -- exceeds the >5 threshold by 1
  • Estimated agent work -- ~5 minutes, borderline
Borderline decomposition case. The natural split would extract order_service.rb (shared API client for order placement) into a separate foundational ticket, reducing this ticket to 4 AC focused on watchdog-specific logic. This also benefits #5 (Option D sizing) which will need the same order service.

Recommendations

  • [BODY] Add issue #1 (Rails app scaffold) to Lineage dependencies. The app/ directory does not exist without it.
  • [LABEL] Align arch labels with project page architecture notes. The project page defines arch-domain-kalshi-assistant, arch-dataflow-kalshi-assistant, arch-deployment-kalshi-assistant -- but the board item uses arch:app and arch:api which have no backing notes.
  • [SCOPE] Create architecture notes for this project. Either create arch-app and arch-api notes to match the current labels, or realign labels to the project page's architecture naming (arch-domain, arch-dataflow, arch-deployment) and create those notes.
  • [DECOMPOSE] 6 AC exceeds >5 threshold. Recommend extracting order_service.rb into a separate foundational ticket (shared Kalshi API order client), reducing this ticket to 4 AC. The order service is also needed by #5 (Option D sizing).