Assembly follow-up: dependent slots, defaults, and aggregate projection

[derekmerck]

Summary

The assembly/slotted-container foundation now exists, so this issue should stop acting like a free-floating note fragment.

What remains are the next concrete extensions that would make the assembly family more useful for authored loadouts and higher-level mechanic families.

Candidate extensions

1. Slot dependencies

Examples:

• powerplant requires chassis
• turret slot requires a large chassis
• saddlebag slot only meaningful if mount harness exists

Possible surfaces:

• slot-level dependency metadata
• validation that can explain unsatisfied prerequisites cleanly

2. Conditional slot enablement

Examples:

• turret slot enabled only for large frames
• ceremonial accessory slots only enabled for specific forms or roles

Possible surfaces:

• slot-level predicate / callable / selector-based enablement
• validation and projection that distinguish "disabled" from merely "empty"

3. Default components / default loadout materialization

Examples:

• base chassis auto-created on initialization
• common clothing slots populated from defaults

Possible surfaces:

• per-slot default template or equivalent initialization policy
• opt-in behavior rather than mandatory auto-population

4. Aggregate properties

Examples:

• total defense bonus
• total carried weight
• total speed modifier
• aggregate tags or capabilities exposed to higher-level systems

Possible surfaces:

• container-level aggregate helpers
• projection contracts for higher mechanic families

Preferred follow-ups

1. Assembly: aggregate property helpers #193 — low-risk aggregate helpers that higher-level families can consume immediately
2. Assembly: slot dependency validation #194 — explicit prerequisite validation for assembly slots
3. Assembly: conditional slot enablement #195 — conditional slot enablement on top of clearer structural rules
4. Assembly: opt-in default loadout materialization #196 — opt-in default loadout materialization after dependency/enablement semantics are clearer

Non-goals

• Reopening the whole asset-collection design space here.
• Unifying inventory, assembly, presence, and every other collection type in one pass.
• Premature optimization before a concrete consumer needs these rules.

Done when

At least one or two of the extensions above are implemented against a real consumer, with tests and a clearer contract for which assembly features are part of the supported family surface.