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 targets entries this component is relevant to, so newly added/selected nodes (via mecha10 init or mecha10 add) can be appended to the matching target’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 simulation (they consume the simulator’s synthetic camera feed).
• Everything else - including hardware-backed components (drivers, or package nodes whose run_target is "robot") - has no inferred simulation membership. Real-hardware placement is fully described by targets.robot/targets.remote (Self::relevant_target) - there’s no separate "hardware" target to add these to any more (removed: it was a redundant subset of targets.robot, and a real robot/remote deployment always runs its full configured target list unfiltered).

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 targets.simulation.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.

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

The full, deduplicated set of targets keys this component should be registered under - Self::relevant_lifecycle_modes and Self::relevant_target combined into the single list callers actually need to loop over when keeping nodes/lifecycle/targets in sync (LAB-2155: the one piece of “which sections does this node belong in” completeness logic shared by both the mecha10 add and mecha10 init code paths for writing a node into mecha10.json).

Trait Implementations

impl Clone for Component

fn clone(&self) -> Self

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.