Spec

Concept	Meaning	Repository path
`message`	typed payload schema	`spec/messages`
`API contract`	one endpoint-level API contract for one semantic namespace	`spec/apis`
`capability`	one app-facing robot capability contract backed by a capability API	`spec/capabilities`
`component`	compatibility bundle for component-role subsystems, composed from one or more API contracts	`spec/components`
`robot manifest`	platform declaration: slots, kinematics, and robot-level capabilities	`tutorials/robot/librux.robot.yaml`
`application`	app-role subsystem requirements for robot capabilities	`tutorials/subsystems/app.cleaner.teleop/subsystem.yaml`

message is the data layer
the primitive spec families are message, API contract, and capability
API contract means one namespace-aligned endpoint contract
one API contract may declare multiple event, control, procedure, and operation surfaces
component means a recognizable component-role subsystem contract composed from one or more API contracts
gateway subsystems provide api.* contracts directly because they own device boundaries for physical hardware or simulator-backed devices
compound subsystems provide capability.* contracts to applications
robot manifest composes gateway, component, and compound slots into one reusable platform target
application maps a top-level app subsystem onto a robot whose capabilities satisfy the app requirements
message and API contract should follow the same semantic namespace axis
defaults.yaml stores the default namespace-version map

Terminology note. subsystem is the Librux runtime unit. component.* is not a synonym for subsystem; it is the public compatibility namespace for component-role subsystems only. Message and API namespaces use direct semantic domains such as msg.motion.*, api.locomotion.*, and api.sensor.*. Capabilities use capability.* for the app-facing robot layer.