Adding lifecycle contract validation and diagnostics mode

[Palakgokhru]

Motivation

Lifecycle bugs are hard to debug because the system currently does not validate or explain lifecycle state violations.

What this PR adds

• A lifecycle contract defining valid state transitions
• A validator that detects contract violations at runtime
• An optional diagnostics mode that explains why lifecycle failures occur
• Integration tests using the dummy client to validate detection

Why this matter:

This does not just fix a single bug it prevents an entire class of lifecycle issues and makes failures observable and actionable for maintainers and users.

Backward compatibility

Diagnostics are opt in and have no runtime impact unless explicitly enabled.

[Palakgokhru]

I can start with a minimal v1 focused on:

• defining a small set of lifecycle contracts
• observing transitions without altering behavior
• validating detection via the dummy client

Happy to adjust scope based on feedback.

[javizqh]

First of all, this is an issue not a Pull Request.

Second, we do not have any "lifecycles" in Robotics Application Manager. What are you trying to refer to with "lifecycle"?

[Palakgokhru]

Thanks for clarifying that’s on me, I should have been clearer with the wording.
I’m not referring to ROS lifecycle nodes or a formal lifecycle concept.
What I meant by “lifecycle” is the execution flow that RAM already handles today, starting and stopping applications, client connections and disconnections, reset, restart paths, and the related process, resource cleanup.
While going through the code, I noticed that these flows are handled across different parts of the manager, and when something unexpected happens (for example, a client exiting abruptly or a reset not completing cleanly), it is hard to tell what went wrong because there’s no visibility into which step or state caused the issue.
The idea I wanted to discuss is a small, opt-in validation, diagnostics layer that observes these existing transitions and reports unexpected sequences or stuck situations mainly to help with debugging and testing (starting with the dummy client).
I’m happy to rename or re-scope this to better align with RAM’s current design — just wanted to explain the intent more clearly.

[jmplaza]

Hi, I think no further improvement on RAM is a priority right now @Palakgokhru . I suggest you may focus on contributing to RoboticsAcademy, just in the open issues. Before improving anything it is good to extensively use it and get familiar with its codebase. Brand new developments are not a good point for newcomers.

[javizqh]

Thanks for clarifying that’s on me, I should have been clearer with the wording. I’m not referring to ROS lifecycle nodes or a formal lifecycle concept. What I meant by “lifecycle” is the execution flow that RAM already handles today, starting and stopping applications, client connections and disconnections, reset, restart paths, and the related process, resource cleanup. While going through the code, I noticed that these flows are handled across different parts of the manager, and when something unexpected happens (for example, a client exiting abruptly or a reset not completing cleanly), it is hard to tell what went wrong because there’s no visibility into which step or state caused the issue. The idea I wanted to discuss is a small, opt-in validation, diagnostics layer that observes these existing transitions and reports unexpected sequences or stuck situations mainly to help with debugging and testing (starting with the dummy client). I’m happy to rename or re-scope this to better align with RAM’s current design — just wanted to explain the intent more clearly.

That is already done by the Machine class from the transitions package