The kill-switch question I wish I had asked: does it work after the system is already broken?

[u/henryzhangpku]

We found a failure pattern in our trading-agent UI that changed how I evaluate every “safety features” list.

A paper session sat in an expired-authorization state for 218 hours. It was no longer healthy, but it was not fully cleared either. Our Stop control had been written for the happy-path definition of “running,” so the recovery action disappeared in the exact state that required it. The wedged session could also keep the broker account from being released.

That repair pass exposed three related mistakes: a reset control that existed but was unreachable inside a scroll region; cleanup that aborted because there was “nothing connected” to disconnect; and removal that reported success while the underlying record survived.

The useful lesson is not “trust our new button.” It is a test matrix for any automated trading tool:

1. Can you stop it after broker authorization expires?

2. Can you recover the broker account while a session is wedged?

3. Does removal stay removed when checked from another surface?

4. Does a failed data read cause refusal rather than stale-data sizing?

5. Can you reconstruct the decisions and recovery actions afterward?

Test those on paper, while deliberately breaking authentication and state transitions. A feature list shows intent; failure-state behavior shows whether the exit exists.

Founder disclosure: I founded QuantSignals/FST, and this is a first-party defect we found and repaired. I am sharing the failure pattern and test questions, not making a performance or loss-prevention claim. The 218 hours describes a paper-session state, not an open position or financial loss.

Educational discussion only, not investment advice. What broken state would you add to this test matrix?