i feel like we need to clarify what Shells are in the context of SPT's systems.

## conceptually, here's what a shell is:
- a surface for one agent to control
  - enables the agent to be embodied within new systems and environments
- a two-way channel that can be configured to transfer text and file payloads both ways
  - a channel for **one-way from-agent commands** for Shell manipulation and Shell-->environment interaction
  - a channel for **one-way to-agent sensory payloads** for images, sounds (maybe), and arbitrary descriptive "sensory" payloads, i.e. "movement instruction completed", "movement obstructed", "bumped", temperature change, energy level, etc.
- a binary that runs on any of the user's own nodes
- can be spun up by an agent endpoint-->both linked. only that endpoint id can control that shell
- optionally ephemeral. when link is broken: can tear down, or can transition to an offline state

## is a shell just a special type of adapter?
adapters:
- have manifests
- can spawn different endpoint types, i.e. ReadyAgent and LiveAgent
- help define harness behaviors and agent-related data surfaces
- do NOT have an agent control surface

shell adapters:
- should also have manifests?
- maybe "Shell" is the endpoint type, and i.e. "GameRobot" is the shell adapter name?
- broadcast their existence. options:
  - to all agents on the subnet
  - only to agents on the same node
  - not at all (agents only learn about it through the user's instruction)
- can only run on nodes where it advertises from/is installed
- choose how they receive commands from SPT. options:
  - HTTP REST
  - stdin-via-broker
  - child relay (basically `spt api poll`(?))

shells are only ever invoked through SPT, and *usually*/typically by an agent. they may have harness-hosted-style topology if they choose to communicate via child relay, but their binary doesn't get booted by anything but SPT.

all this said, what are shell-relevant SPT commands, and how do they integrate with the spt-core file layout?