docs: Add Rise/Fall business specification document

[ashkan-deriv]

Summary by Sourcery

Documentation:

• Adds a business specification document for the Rise/Fall trade type.

[sourcery-ai]

Reviewer's Guide by Sourcery

This pull request introduces a new business specification document for the Rise/Fall trade type. The document details the business logic, user journey, technical implementation, and UI/UX considerations for this feature.

No diagrams generated as the changes look simple and do not need a visual representation.

File-Level Changes

Change	Details	Files
Introduced a comprehensive business specification document for the Rise/Fall trade type within the Champion Trader application.	Defined the core concept of Rise/Fall trading, including Rise and Fall predictions. Specified key parameters such as duration, stake, and the optional 'Allow Equals' feature. Detailed the win conditions for both Rise and Fall scenarios, with and without 'Allow Equals'. Outlined the user journey from market selection to outcome determination. Described the technical implementation, including configuration structure, API integration, and state management. Listed the user interface components and their responsive design adaptations. Explained the educational content provided to users, including a 'How to Trade' guide and visual animations. Documented error handling mechanisms and performance optimization techniques.	BusinessSpecs/RiseFallBusinessSpecs.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!
• Generate a plan of action for an issue: Comment @sourcery-ai plan on
  an issue to generate a plan of action for it.

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey @ashkan-deriv - I've reviewed your changes - here's some feedback:

Overall Comments:

• This is a good start, but consider adding a section on security considerations, such as input validation and protection against replay attacks.

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[devloai]

I've reviewed the Rise/Fall Business Specification document and found it to be well-structured and comprehensive. I've provided several suggestions to improve clarity, consistency, and completeness. Feel free to reach out with any questions or instructions related to this or future reviews, and I'll be happy to assist.

Follow-up suggestion: @devloai help implement the suggested changes to the business specification document

[devloai]

There seems to be a duplication in the 'Allow Equals' description. Both Rise and Fall conditions state 'the exit price is equal to the entry price'. Please clarify if this is intended or if there should be different conditions for Rise vs Fall trades when using 'Allow Equals'.

[devloai]

The API endpoint path shown here (/v1/market/products/rise_fall/config) seems to be specific to Rise/Fall, but our API structure typically uses a pattern where the product ID is a parameter, not part of the path itself. Consider updating to reflect the actual endpoint format, such as /v1/market/products/{product_id}/config where product_id would be 'rise_fall'.

[devloai]

The Trade Execution API section lists trade_type with values 'CALL' and 'PUT', but in the Configuration Structure section (line 128-136), these are mapped to 'contractType'. Please ensure consistent terminology throughout the document to avoid confusion - either standardize on trade_type or contractType.

[devloai]

There's a reference to a 'Product Config Store', but this doesn't match our current store structure based on the repository insights. According to our repository structure, configurations are typically handled through the tradeStore which includes product configurations. Consider updating this to align with the actual implementation.

[devloai]

Consider adding a table of contents at the beginning of the document to improve navigation. This would be helpful given the length and detailed structure of the specification.

[devloai]

The Error Handling section is quite brief compared to other sections. Consider expanding this with more specific error codes, validation rules, and user-facing error messages that would be shown in different scenarios. This would help both developers and QA team understand the expected behavior in error conditions.