12025-12-02T14:57:30  <stringintech> Thank you stickies-v. Yeah right now the runner operates sequentially (and I'm not expecting that to change for now), so I think we can avoid enforcing it in the response.
 22025-12-02T14:58:05  <stringintech> For now I'll try replacing the existing ones with the suite_name+test_case_number format to see how it looks. I think this should make it easier to add new test suites down the line since the naming convention will be consistent.
 32025-12-02T15:00:27  <stickies-v> yeah i don't see why it'd ever not need to be sequential, if we want multithreading each thread could just spawn its own handler
 42025-12-02T15:01:13  <stickies-v> (i was even thinking each test could spawn its own handler to simplify implementation and prevent state from previous tests leaking)
 52025-12-02T15:04:07  <stringintech> Yeah, it makes sense. In fact, for the chain tests (which I will open a PR for soon), I am spawning a new process for the same reason.
 62025-12-02T15:38:28  <stickies-v> nice, looking forward to it!
 72025-12-02T19:40:50  <stringintech> Release v0.0.2 is ready. Major changes are:
 82025-12-02T19:41:30  <stringintech> 1) Refactoring the tests and handler response validation to align with the C API exported symbols and semantics (PR 7)
 92025-12-02T19:42:08  <stringintech> 2) Refactoring handler process management for more reliable runner execution (PR 9)
102025-12-02T19:42:33  <stringintech> https://github.com/stringintech/kernel-bindings-tests/releases/tag/v0.0.2
112025-12-02T19:43:55  <stringintech> Thanks A LOT for the valuable feedback over the last two weeks!