# Appearance, wearables, and the Current Outfit Folder `AppearanceManager` owns the client-visible wearable and attachment snapshots. Wearables retain their inventory item, asset, asset type, and wearable slot. A clothing slot accepts at most 60 ordered layers; body parts are single-value slots and replace an existing value of the same type. Sending the outfit emits the native `AgentIsNowWearing` packet from a snapshot, then publishes the appearance event after the send. Wearable reply and appearance subscribers are also snapshotted before invocation, so no state or subscriber lock is held during a callback. Attachment calls preserve the inventory owner, name, description, permission masks, flags, and requested attachment point in `RezSingleAttachmentFromInv`. Add versus replace is encoded in the attachment point field, and replace removes only objects at the selected non-default point. `DetachAttachmentIntoInv` is keyed by inventory item ID. Queries expose the same state by item, item ID, and attachment point. ## Current Outfit Folder ownership `CurrentOutfitFolder` discovers the `CurrentOutfit` system folder from the inventory store unless an explicit folder has been supplied. Its contents are links: link UUIDs identify COF entries and link asset UUIDs identify the worn inventory objects. Resolution first consults committed local link targets and then the inventory store. This keeps successful mutations immediately queryable while an asynchronous inventory reply is still being reconciled. Clothing link descriptions encode the wearable type followed by a two-digit layer number. Add chooses the first free layer, preserves existing layers, and rejects a 61st layer. Replace removes the selected wearable type before allocating its new layers. Body-part and attachment descriptions remain empty, matching the reference link format. Folder ancestry and recursive outfit discovery are cycle-safe and bounded to 256 nodes. Mutations pass through a one-permit asynchronous operation gate. Waiting for the gate is cancellation-aware, but the gate is not an inventory/state lock; network awaits never retain a synchronous lock. Cancellation is checked while planning and before committing. Once a commit begins, it completes or runs its compensation before reporting the result, preventing a cancellation race from leaving a half-written outfit. Outfit changes create replacement links before removing old links. If removal fails, new links are removed and old link descriptions are recreated. Attach creates its COF link before executing the rez request; replacement removes the displaced links only after the new attachment succeeds. A later failure detaches the new item and restores displaced attachments. Detach similarly restores the attachment if its COF link cannot be removed. The local shadow is changed only after those network steps succeed. `ICurrentOutfitPolicy` remains a pure decision/reporting boundary. Composite policies use a stable subscriber snapshot, consult every policy for attach and detach decisions, and invoke reports in registration order. Policy locks are released before callbacks and committed changes are reported exactly once. Focused compatibility coverage lives in `current_outfit_folder_semantics`, `current_outfit_policy_semantics`, the COF link-description cases, and the issue-relevant appearance cases. Native recording fakes additionally prove create/remove compensation, create-before-attach ordering, replacement state, layer preservation, and cancellation before backend interaction. Texture baking, visual-parameter synthesis, and texture upload are the next appearance pipeline described below. ## Baking and texture transport The baking pipeline retains all 45 avatar texture slots, all 11 classic and extended baked outputs, the reference cache salts and sentinel UUIDs, and the generated visual-parameter ordering from the pinned character definition. Wearable assets are parsed as bounded LLWearable text, including parameter values and texture indices. Texture retrieval is provided through `IBakingTextureProvider`; the grid implementation downloads the asset and decodes it through the existing JPEG2000 abstraction. At most five texture downloads and six baked-texture uploads are in flight at once. `Baker` composites owned image copies into 1024-by-1024 bakes (128-by-128 for eyes). It applies the canonical head, skin-grain, hair, wearable alpha, tint, and morph-bump layers, preserves color/alpha/bump channels, and caps a bake at 60 input layers. Character resources are resolved cross-platform from `LIBREMETAVERSE_RESOURCE_DIR`, the configured resource directory, or the project resource bundle. Cached images are cloned on both insertion and read, so a caller cannot corrupt a later bake. Minimal installations have neutral built-in base masks; JPEG2000 encoding remains behind the project codec feature rather than a platform API. Appearance setting first uses server-side baking when the simulator advertises the appearance service and actually exposes `UpdateAvatarAppearance`; a region with only the protocol flag falls back to local baking. The capability call validates the COF version, success response, visual parameters, and required baked texture IDs, with five cancellation-aware attempts and bounded exponential delay. A classic region requests cached bake hashes, incorporates the reply, downloads only necessary inputs, bakes missing layers locally, uploads them, and sends the complete `AgentSetAppearance` packet. Its texture entry uses the protocol's big-endian seven-bit face masks and complete default-face attributes, while visual parameters retain the reference's 218 normal or 251 physics-wearable fields and drive the reported avatar height. Rebake packets cancel superseded work, clear stale bake IDs, and force a fresh local bake. A region change before the final send aborts and rolls back the old-region result. No synchronous state lock crosses a network await or event callback. On cancellation or failure the texture, wearable-asset, visual-parameter, and COF-version snapshots are restored before the failure event is published. Wearable discovery rebuilds both wearables and attachments from resolved COF links with a 512-entry bound. On classic/OpenSim regions, an empty or unusable COF result falls back to `AgentWearablesRequest` and waits up to 30 seconds for `AgentWearablesUpdate`. The packet handler ignores server-baking dummy payloads, preserves every valid item/asset/type tuple, wakes the pending request, and can start a bake for a spontaneous legacy update. Missing wearable assets or required texture downloads fail the pipeline instead of publishing a false success with incomplete bakes. ## Initial outfit setup First-login outfit setup searches the library iteratively with a 256-node bound, creates missing Clothing and Trash system folders, counts the selected tree, and copies its folder and item hierarchy into Clothing. Progress follows `Counting`, `Copying`, `Applying`, then `Complete`; completion is reported only after transactional COF replacement succeeds. Cancellation is checked during planning, creation, copying, and application. A failed or cancelled copy removes its partially created root, and a failed application removes the fully copied root while the Current Outfit Folder restores its prior links. The login handler starts this work once, owns its cancellation source and event subscription, and disposes idempotently. Focused verification covers the translated Baker cases, exact bake mappings and cache hashes, generated visual metadata, wearable parsing, output pixels and channels, packet/event payloads, cancellation before mutation, progress state, and handler disposal. Live appearance tests remain opt-in because they require grid credentials.