The designator adornments returns all the adornments that are contained inside the current note, i.e. this container's child map. The data is returns as a List of the adornments' $Path values, in $OutlineOrder.
Siblings vs. children
For any given map, in terms of $OutlineDepth/$OutlineOrder, notes on the map are siblings of the maps' adornment(s). However, for adornments any adornments are for the addressed item's child map. If the logic seems odd, bear in mind that a map (timeline, etc.) is normally addressed in terms of its enclosing—and thus parent–container.
Thus, for an item on a map to get its sibling adornments use either of these relative references, use either:
$MyList = $Name(adornments(parent))
$MyList = $Name(adornments(..))
noting that .. is the unix term for the parent folder. For most Tinderbox users, who aren't familiar with Unix structures, the parent designator as the offset address argument is the most sensible to use.
Title vs. ID and action code
When using a large number of adornments, e.g. to set out a time or date grid, many of the individual adornments may not have a unique $Name. For instance if there is an adornment '10' mapping the first 10 minutes of an hour, there may be multiple adornments on the same map with the same $Name and $Path. Recall that when accessing a note via a not unique title/path, Tinderbox always matches the first match by $OutlineOrder, even when processing a list. In other words, processing a list of $Name values with multiple '10' values, the action will act on the same, first match target, every time.
$ID offers a sensible workaround, not least because within the action code context the use of item titles ($Name) is a convenience. If you want to process a list of adornments for whatever ever reason it may therefore make sense to use their $ID instead as this will always be unique. For example:
$MyList = $ID(adornments) → a list of child adornment IDs
$MyList = $Name(adornments(parent)) → a list of sibling adornment IDs