sg_edge
The second-largest directory in the spec tree and the one the registry cannot see: it has no manifest.py, so Spec__Loader never finds it. Either register it or move it out of sg_compute_specs/ — leaving the largest unregistered thing inside the spec tree is confusing for anyone reading the catalogue.
sg_edge is not a registered spec. It has no manifest.py, so Spec__Loader never finds it and it is invisible to the registry, the API and the generated CLI. At 9,108 lines it is the second-largest directory in sg_compute_specs/.
It appears on this page because leaving it out would be the same omission the tree makes. The decision to take is register it or move it out.
The CLI, which nobody wrote
Per-spec CLIs are generated, not written. Spec__CLI__Builder registers the same verb set for every registered spec, so sg_edge gets its command surface from the same code that gives every other spec theirs:
# the uniform verb set, for every registered spec list · info · create · wait · health · connect · exec · delete · ami list|bake · cert # so, for this one sg sg_edge create --max-hours 1 sg sg_edge wait sg sg_edge health sg sg_edge delete
This is the strongest single argument that the thing is a platform rather than a service: adding a spec costs a manifest, a route class and a service — the CLI comes free. The three mechanisms →
What a node of this spec does
Every spec rides the same node lifecycle: a per-node API key minted and written to SSM before launch, composed user-data sections, EC2 tags as the registry, a two-phase health poll, then teardown. Teardown means terminate, not stop — systemd-run --on-active paired with InstanceInitiatedShutdownBehavior=terminate, on a default one-hour timer.