Manipulation traits

container (a container, a kind noun, so it takes the article). Holds things inside; composes on one line with openable, lockable, and scenery (a container, openable, scenery). The putting example shows one in play. A holds N line bounds how many things fit directly inside; putting or inserting into a full one refuses with "There's no room". The transparent adjective keeps the contents visible while the container is closed, so examining it lists them and search or look in shows them instead of refusing. It is read by putting, inserting, removing, searching, opening/closing, dropping, throwing, and looking. Data fields beyond Chord's reach today (TypeScript territory): allowedTypes/excludedTypes, the weight and volume limits, and the liquid fields (containsLiquid, liquidType, liquidAmount; see drinking).

supporter (a supporter). Holds things on top; see the putting example. A holds N line bounds the number of items it holds. Unlike containers, a supporter's weight math includes nested contents recursively. It is read by putting, removing, climbing, dropping, and looking.

pushable (pushable). Makes an entity eligible for pushing: the signal-box button is this trait, bare. Its pushType, one of button (default), heavy, or moveable, selects the pushing behavior; from Chord, bare pushable composes the default button configuration (heavy/moveable are TypeScript territory today). Beyond pushType, revealsPassage, and pushSound, the trait's fields (activates, maxPushes, pushDirection, effects) are data for your event handlers, not behavior that stdlib enforces.

pullable (pullable). Makes an entity eligible for pulling: the signal lever. Stdlib mutates two fields: state (→ 'pulled', which is what gates already_pulled) and pullCount. It carries the rest (pullType, activates, linkedTo, detachesOnPull, maxPulls, effects) as data for story handlers reacting to pulled.

cuttable (cuttable, optionally with the <tool entity>, an adjective). Makes an entity eligible for cutting (the bramble) and carries the tool contract mirroring lockable's keys: toolId (one tool, what Chord's with sets), toolIds (several, TypeScript), with CuttableBehavior's requiresTool/canCutWith predicates. Composing it obliges the entity to register exactly one cut implementation; the load check enforces it.

diggable (diggable, optionally with the <tool entity>) takes the same shape for digging (the seedbed): toolId/toolIds, DiggableBehavior.requiresTool/canDigWith, and the same one-implementation rule.

moveable-scenery is dormant today (no action reads it, no behavior class, not composable from Chord): a sketched heavy-thing vocabulary (weight class, blocked exits, reveals-when-moved), not the way to build a boulder puzzle right now. Use pushable/pullable plus story logic.

attached is dormant on the same terms: a sketched attachment vocabulary (glued/nailed/tied, detachable, detach force); watch the ADRs for when these two wake up.