Test a limit order staying pending below market

Failure modes in this flow

The correct outcome here is that nothing happens, which is harder to assert than a fill and easier to get wrong.

• The order type changes the form - choosing a limit order reveals a limit price field.
• The interface explains the rule - a hint that a price below the last traded price stays pending.
• The order does not fill - a pending banner rather than a filled one, at the limit price and not the market price.
• The order book agrees - a row with a pending badge naming the price it waits for.

Asserting the pending banner shows $200.00, the limit, rather than $241.05, the market price, is the detail that distinguishes a correctly parked order from one that recorded the wrong figure.

Writing the objective

The last traded price is asserted in the first step so the limit chosen in step three is demonstrably below market rather than assumed to be.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/robinhood-clone-app/trade?reset=true
max_steps: 45
tags: [robinhood, fintech, trading]
---

# Robinhud 16.2: Limit order

Catalog objective: place a limit buy below market and verify the pending state.
Key assertion: the open order is listed with its limit price.

## Open an order ticket
Type "TSLA" into "Search ticker or name", click "Trade" on the TSLA row, and verify "Last price" reads "$241.05".

## Switch to a limit order
Choose "Limit order" and verify a "Limit price" field appears with a hint that a price below "$241.05" stays pending.

## Place a limit below market
Set "Shares" to "1", type "200" into "Limit price", and click "Review and buy".

## Verify the order stays pending
Verify an amber banner titled "Order pending" shows a status of "Pending" at "$200.00", and the Orders list has an "ORD-501" row with a "Pending" badge noting it is waiting for TSLA to reach "$200.00".

The final assertion reads the order book, which is the record a trader checks the next morning and a different surface from the banner that appeared at submission.

The assertions in detail

Two steps establishing conditions, one action, one verification on the record.

Both the banner and the order book are asserted. An order that shows pending on screen and is absent from the book is an order the trader cannot cancel.

Running it locally

kane-cli testmd run tests/robinhood/limit-order_test.md

Pair this with the market order file. Together they cover the two order types most retail flows offer and the two outcomes that must not be confused.

Order type variants differ by a few values, which makes them worth generating rather than writing. Generating the variants covers that, and running Kane CLI in CI covers executing the set on every build.