Skip to content

platform_notification_outcomes.md

Latest commit

 

History

History
66 lines (49 loc) · 2.84 KB

platform_notification_outcomes.md

File metadata and controls

66 lines (49 loc) · 2.84 KB
Raw

Platform Notification Outcomes

简体中文

Platform runtimes should use the shared execution outcome and notification envelope helpers in quant_platform_kit instead of defining private stage or notification sink semantics in each repository.

Execution Stages

quant_platform_kit.common.execution_outcomes defines the shared strategy-run stages used by platform persistence, API responses, logs, and notifications:

Stage Terminal Meaning
ORDERS_PLANNED No A plan was built before execution.
DRY_RUN_COMPLETED No Dry-run execution finished without live orders.
NO_ACTION No Live cycle completed with no order needed.
SUBMITTED Yes One or more live orders were submitted.
EXECUTION_BLOCKED No No order was submitted because of a retryable execution blocker.
PARTIAL_SUBMITTED No Some orders were submitted, but at least one execution blocker remains.
FUNDING_BLOCKED No Funding was insufficient and no order was submitted; retry only while the execution window is open.
RECONCILED Yes A submitted run was reconciled by a platform-specific process.
COMPLETED Yes A run was marked complete by a platform-specific process.

Terminal stages block duplicate live order submission for the same account/profile/period. Non-terminal execution blockers can be retried by the platform runtime while the strategy execution window remains open.

Skip Reasons

The shared helper treats these skip reasons as execution blockers by default:

  • buy_quantity_zero
  • insufficient_cash
  • insufficient_cash_for_whole_share
  • quote_unavailable
  • sell_quantity_zero

insufficient_cash and insufficient_cash_for_whole_share are retryable funding blocks when they are the only blocking reason and no live order was submitted. The platform may retry only while the strategy execution window is open, and must acquire its durable create-only submission claim immediately before the first broker request. A broker-accepted, pending, or unknown submission is never automatically retried.

Notification Envelope

quant_platform_kit.notifications.events provides:

  • RenderedNotification(detailed_text, compact_text)
  • NotificationPublisher(log_message, send_message)
  • publish_rendered_notification(...)

Platform renderers may keep broker-specific layout and order details, but they should publish through the shared envelope so logs and user notifications have a consistent delivery contract.

Platform Responsibilities

Platform repositories should:

  • use shared stage constants and stage resolution helpers
  • include the resolved stage in persisted run state and API responses
  • render execution blockers consistently in logs and notifications
  • keep broker-specific order payloads, account labels, and transport wiring local