u/xerr00

I like Playwright MCP inside Cursor.

For unknown bugs it is genuinely useful.

Open the page, inspect the DOM, click around, read the console, figure out why the modal is stuck. That interactive loop is exactly what MCP is good at.

But I realised I was using the same setup for this:

Log in → open settings → change timezone → save → refresh → confirm timezone stayed changed.

The flow was already known.

Cursor still spent half the conversation opening the page, reading snapshots, deciding what to click, re-reading the page and then explaining what it saw.

It worked, but it felt like keeping an entire browser conversation alive for a 90-second smoke check.

So I split the workflow:

Unknown problem: Cursor + browser MCP
Known repeatable check: external CLI
Permanent critical flow: Playwright test in the repo

For the middle layer I’ve been trying Kane CLI from TestMu.

Cursor can read the Kane instructions through the same AGENTS.md-style path and call it after making a change.

Kane runs the objective and gives Cursor structured pass/fail output plus the browser evidence.

So instead of the coding conversation containing every click and page snapshot, Cursor basically gets:

• flow completed or failed

• assertion that failed

• final page state

• evidence from the run

That separation feels cleaner.

I’m not saying MCP always burns too much context. If the agent is debugging something unknown, that context is the whole point.

And I’m not replacing Playwright with Kane. Auth, billing, permissions and stable regression flows still belong in proper tests.

This is specifically for the awkward middle ground where the flow is too repeatable for exploration but not important enough to immediately build and maintain as a permanent test.

Do you keep browser control inside Cursor’s context, or move known checks out into CLI/CI?

open

have a pine alert sending json to a small fastapi endpoint. endpoint validates it and places the option order through nubra uat.

found one bad case while testing:

webhook reaches backend → nubra order request is sent → client times out before i save the returned order id → worker retries → same signal can become 2 orders.

currently blocking duplicates with an in-memory set, which is obviously useless after a restart or multiple workers.

thinking of persisting every intent before calling the broker:

signal_id | payload_hash | status | broker_order_id | created_at

flow would be:

receive alert, verify signature, insert signal_id with unique constraint, return 200, then process through a queue. on timeout, check nubra order state/positions before retrying instead of assuming failure.

nubra uat is nice for this because i can replay the same alerts and inspect actual order lifecycle without doing the experiment live.

how are people generating a durable idempotency key from tradingview though? alert id + bar time + strategy version? also what do you treat as source of truth after an uncertain broker response: order book, positions or both?

1. Stop trying to smash every shuttle.

2. Recover back to base after every shot.

3. Use your non-racket arm for balance.

4. Relax your grip until impact.

5. Focus on footwork before buying an expensive racket.

6.Consistency wins more points than power.

I’m always interested in hearing which courses people struggled with the most and how they got through them.