Enum StringSkeletonNode

pub enum StringSkeletonNode {
    Dispatch {
        name: String,
        ordering: Option<SubBranchOrdering>,
        children: HashMap<String, DispatchChildSpec>,
    },
    LeafHolder {
        name: String,
        ordering: Option<SubBranchOrdering>,
        n_leaves: u8,
        capstone: bool,
    },
    Aggregate {
        name: String,
        ordering: Option<SubBranchOrdering>,
        children: HashMap<String, AggregateChildSpec>,
    },
}

Set this object to configure a single node in the string skeleton, tagged by its role.

Note that we do not want the names of our nodes to be trivial or vague categories like “foundations”, or to use arbitrary separations like “beginner”, “intermediate”, “advanced”.

It is always better for us to slice the chosen topic into concrete subcomponents that bear physical meaning. In the case of lockpicking, for example, we could write categories for types of locks, types of equipment, and techniques for entry.

Categorizing into these three would be better than categorizing into “beginner skills”, “intermediate skills”, and “advanced skills”, for example. This same concept applies everywhere.

The essential idea is that the chosen names should refer to concrete subcomponents bearing physical meaning.

Variants

Dispatch

Select this variant at this position in the model to emit a Dispatch node in which each dispatch branch wraps a whole rooted subtree. Note that each Dispatch node should always have greater than one child.

Fields

name: String

Set this field to indicate the official-name of this tree node.

IMPORTANT: All names should be UpperCamelCase and contain no spaces and no punctuation.

MORE IMPORTANTLY: DO NOT NAME THIS FIELD ANY TEMPORARY OR ANY GENERIC NAME!

Do not use names like SomethingDispatch, Dispatch1, DispatchNode1, or anything like that!!! real names only!

Do not reveal the underlying structure of our tree growing algorithm by your choice of name!

WE DO NOT want to have to keep on asking you! name the tree nodes properly!!

Each name should have concrete physical value and stand on its own, independently of our tree and retain technical and structural significance OUTSIDE THE CONTEXT OF THE TREE GROWING PROCESS!!!!!!!!

ordering: Option<SubBranchOrdering>

Set the ordering field to indicate an (optional) sub-branch ordering hint for our dispatch branch sequencing

children: HashMap<String, DispatchChildSpec>

Set the members of the children map to specify official names for each dispatch-branch-rooted child node and their associated auxiliary specifications.

Keys in this map are the official names of the child nodes. Values are their associated DispatchChildSpec aux specifications.

LeafHolder

Select this variant to emit a LeafHolder node at this tree location.

A LeafHolder node is like the shell of an enum with unit variants only.

LeafHolder nodes are typically used as the “end-effectors” within the context of a domain model.

LeafHolder nodes each have an associated number of “leaves” representing the number of ways this end effector can manifest in practice.

Fields

name: String

Set this field to indicate the official-name of this tree node.

IMPORTANT: All names should be UpperCamelCase identifiers and contain no spaces and no punctuation.

MORE IMPORTANTLY: DO NOT NAME THIS FIELD ANY TEMPORARY OR ANY GENERIC NAME!

Do not use names like SomethingLeaf, Leaf1, Leaf1A, LeafBranch12, LeafHolder9B or anything like that!!! real names only!

Do not reveal the underlying structure of our tree growing algorithm by your choice of name!

THIS INSTRUCTION IS NOT OPTIONAL! We DO NOT WANT to ask again!

Correcting this problem after-the-fact is incredibly tedious! PLEASE PLEASE FOR THE LOVE OF GOD name the tree nodes properly!!

Each name should have concrete physical value and stand on its own, independently of our tree and retain technical and structural significance OUTSIDE THE CONTEXT OF THE TREE GROWING PROCESS!!!!!!!!

ordering: Option<SubBranchOrdering>

Set the ordering field to indicate an (optional) branch-ordering hint for the LeafHolder leaves

n_leaves: u8

Set this number to the number of leaves to generate under this node.

In practice, we typically want this number to be at least ten, but 5-7 is standard.

capstone: bool

Set this field to true to mark this LeafHolder node as a special capstone node within the tree.

capstone nodes bear special significance within the model and will typically be targeted by downstream tree-consumers.

Aggregate

Select the Aggregate variant to emit a structure aggregating several downstream branches.

An Aggregate node should have at least 3 children. 3-7 is typical. More than 7 is possible where useful.

We use Aggregate nodes to model components having children that always activate together (ie branches that are always taken simultaneously within the domain model path flow)

We model them as Aggregate nodes even if some of their branches may be temporarily deselected and are considered optional.

Aggregate nodes are analogous to struct data.

Note that each Aggregate node should always have greater than one child.

We use Aggregate for nodes whose children temporally or structurally overlap during simulation and Dispatch for nodes whose children are more akin to mutually exclusive variations or alternatives.

Fields

name: String

Set this field to indicate the official-name of this Aggregate node.

IMPORTANT: All names should be UpperCamelCase and contain no spaces and no punctuation.

MORE IMPORTANTLY: DO NOT NAME THIS FIELD ANY TEMPORARY OR ANY GENERIC NAME!

Do not use names like SomethingAggregator, Agg1, AggNode1A, MyAgg or anything like that!!! real names only!

Do not reveal the underlying structure of our tree growing algorithm by your choice of name!

THIS INSTRUCTION IS NOT OPTIONAL! We DO NOT WANT to ask again! correcting this problem after-the-fact is incredibly tedious! PLEASE name the tree nodes properly!!

Each name should have concrete physical value and stand on its own, independently of our tree and retain technical and structural significance OUTSIDE THE CONTEXT OF THE TREE GROWING PROCESS!!!!!!!!

ordering: Option<SubBranchOrdering>

Set the ordering field to indicate an (optional) branch-ordering hint for the Aggregate node fields

children: HashMap<String, AggregateChildSpec>

Set the members of the children map to specify official names for each aggregate-branch-rooted child node and their associated auxiliary specifications.

Keys in this map are the official names of the direct child nodes. Values in this map are their associated AggregateChildSpec aux specifications.

Trait Implementations

impl AiJsonTemplate for StringSkeletonNode

fn to_template() -> Value

Return a JSON template describing how the AI’s output should be structured. This might include doc comments or other instructions for each field.

impl AiJsonTemplateWithJustification for StringSkeletonNode

fn to_template_with_justification() -> Value

impl Clone for StringSkeletonNode

fn clone(&self) -> StringSkeletonNode

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for StringSkeletonNode

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

Formats the value using the given formatter.

impl Default for StringSkeletonNode

fn default() -> Self

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for StringSkeletonNode

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

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl From<JustifiedStringSkeletonNode> for StringSkeletonNode

fn from(value: JustifiedStringSkeletonNode) -> Self

Converts to this type from the input type.

impl LoadFromFile for StringSkeletonNode

where StringSkeletonNode: for<'de> Deserialize<'de>,

type Error = SaveLoadError

fn load_from_file<'async_trait>( filename: impl 'async_trait + AsRef<Path> + Send, ) -> Pin<Box<dyn Future<Output = Result<Self, Self::Error>> + Send + 'async_trait>>

where Self: 'async_trait,

impl PartialEq for StringSkeletonNode

fn eq(&self, other: &StringSkeletonNode) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl SaveToFile for StringSkeletonNode

where StringSkeletonNode: Serialize,

type Error = SaveLoadError

fn save_to_file<'life0, 'async_trait>( &'life0 self, filename: impl 'async_trait + AsRef<Path> + Send, ) -> Pin<Box<dyn Future<Output = Result<(), Self::Error>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

impl Serialize for StringSkeletonNode

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

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl Eq for StringSkeletonNode

impl StructuralPartialEq for StringSkeletonNode