Struct Component 

pub struct Component {
    pub id: String,
    pub name: String,
    pub description: String,
    pub component_type: ComponentType,
    pub version: String,
    pub category: String,
    pub tags: Vec<String>,
    pub cargo_dependencies: Vec<CargoDependency>,
    pub files: Vec<FileTemplate>,
    pub mecha10_config: Mecha10Config,
}

A component that can be added to a project

Fields

id: String

name: String

description: String

component_type: ComponentType

version: String

category: String

tags: Vec<String>

cargo_dependencies: Vec<CargoDependency>

Cargo dependencies to add

files: Vec<FileTemplate>

Files to generate

mecha10_config: Mecha10Config

Configuration to add to mecha10.json

Implementations

impl Component

pub fn relevant_lifecycle_modes(&self) -> Vec<&'static str>

Infer which lifecycle.modes entries this component is relevant to, so newly added/selected nodes (via mecha10 init or mecha10 add) can be appended to the matching mode’s nodes list and actually get spawned by CliLifecycleManager::nodes_for_current_mode.

• AI/perception components (tagged with any of [AI_PERCEPTION_TAGS]) are relevant to both simulation (they consume the simulator’s synthetic camera feed) and hardware (they consume the real camera feed).
• Other components backed by real hardware - drivers, or package nodes whose run_target is "robot" - are hardware-only (e.g. motor/imu nodes have nothing to do in simulation).
• Anything else (examples, dev-only tooling, infra/plumbing nodes) has no inferred lifecycle-mode membership; those stay under manual/template control, matching prior behavior.

pub fn relevant_target(&self) -> Option<&'static str>

Infer which targets entry (see mecha10_cli_core::types::project::targets::TargetsConfig) this component should be dispatched to, so mecha10 add/mecha10 init can keep targets.robot/targets.remote in sync with the node’s own run_target, the same way Self::relevant_lifecycle_modes keeps lifecycle.modes.*.nodes in sync.

Falls back to None for anything without a driver/custom_node run_target of exactly "robot" or "remote" (e.g. run_target: "dev", or components with neither config block) - those aren’t meaningfully “targeted” and stay under manual control.

Trait Implementations

impl Clone for Component

fn clone(&self) -> Component

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Component

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Component

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Serialize for Component

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.