Struct InitService 

pub struct InitService;

Implementations

impl InitService

pub fn new() -> InitService

Create a new InitService

pub async fn create_project_directories(&self, path: &Path) -> Result<(), Error>

Create all the necessary directories for a new Mecha10 project.

pub async fn add_example_node( &self, project_root: &Path, component_name: &str, capabilities: Vec<Capability>, ) -> Result<(), Error>

Add an example node from the catalog to the project, updating Cargo.toml and mecha10.json as needed.

capabilities is this node’s declared Capability set as resolved by the caller from the live node catalog (catalog_client::fetch_node_catalog’s NodeCatalogEntry::capabilities) - threaded straight through to Self::add_node_to_config rather than read back off a local config.json, so mecha10 init/mecha10 init --update no longer depend on mecha10_robot_config::pull_node_catalog_configs having already written that file (it silently no-ops if one already exists there, which could otherwise strand capabilities at [] forever).

pub async fn sync_node_capabilities( &self, project_root: &Path, component_name: &str, is_monorepo_node: bool, capabilities: Vec<Capability>, ) -> Result<(), Error>

Backfill capabilities onto a node that’s already fully scaffolded on disk (component files already written, Cargo.toml/workspace member already present), without re-running any of Self::add_example_node’s file-writing steps.

mecha10 init --update needs this: re-running the full add_example_node scaffold for a node that already has a local config.json would needlessly rewrite its component files (clobbering anything the project author customized) just to upsert one field in mecha10.json. This only touches the nodes map entry, via Self::add_node_to_config’s upsert rules.

Trait Implementations

impl Default for InitService

fn default() -> InitService

Returns the “default value” for a type.