modwright 0.1.0

package/scaffolds/cyberpunk2077/new-entity-patch.yaml

@@ -0,0 +1,255 @@
+# new-entity-patch (Cyberpunk 2077) — observed in game (2026-09).
+#
+# Adds a component to vanilla entity templates through ArchiveXL's
+# `resource.patch`: the same mechanism `new-garment-refit` uses on the two
+# player entities, generalised to a list of targets and a chosen component.
+# The first component kind is the camera an in-game test proved: a
+# `gameCameraComponent` bound to a slot on the target (`Item_Attachment_Slot` / `Head`, read off the one archetype the test
+# read in full — the citizen default male; the other 739 under
+# `base\characters\entities\` were not checked, which is why the two
+# binding names are inputs with those defaults rather than constants) plus
+# the `gameDeviceCameraControlComponent` devices carry. Activated with high
+# priority from a script, that camera takes the game view (observed in game,
+# 2026-09: the spawned citizen's head became the view; the loader logged
+# both components added to the archetype at load). The component ships at
+# identity transform: the test set the orientation (roll 90 about the
+# bone's X) and the offset (0.15 forward, 0.06 up) live through
+# `SetLocalOrientation` and `SetLocalPosition`, so a mod tunes them at
+# take-over time rather than baking one head's numbers into every
+# archetype.
+#
+# What the test did NOT settle, and what this scaffold therefore does not
+# claim: input. `DeviceStartPlayerCameraControlEvent` queued on the
+# patched NPC did not give mouse look of that camera, and movement, aim
+# and fire were not exercised at all — the test drove the camera and
+# nothing else. `gameDeviceCameraControlComponent` is here because it is
+# the component a device carries beside its camera and the pair is what
+# was proven to load and activate, NOT because it was shown to route
+# player input to a puppet. Whatever takes over control is the mod's own
+# system, and it is unwritten. This scaffold places two components and
+# registers them; everything past `Activate` is still open.
+#
+# Why a `type: list` input (engine): one patch entity serves
+# many targets, and ArchiveXL takes the whole list on one manifest key; a
+# scaffold that appended one target per apply would need hundreds of
+# applies for the NPC set.
+id: cyberpunk2077.new-entity-patch
+game: cyberpunk2077
+title: New Cyberpunk 2077 entity patch (a component added to vanilla entities)
+summary: Write a patch entity carrying one chosen component (the camera kind ships a gameCameraComponent bound to a slot plus the device camera-control component), register it in the .archive.xl resource.patch for a list of vanilla entity templates, and add the deserialize build step.
+modTypes: [entity-patch, quickhack, npc]
+needs: {}
+inputs:
+  - type: string
+    name: modSlug
+    prompt: "Lowercase depot folder name for this mod, e.g. mymod (the patch compiles to mod\\\\<slug>\\\\<patchName>.ent)."
+    pattern: "^[a-z][a-z0-9_]*$"
+  - type: string
+    name: patchName
+    prompt: "File stem of the patch entity, e.g. npc_camera_patch (source <patchName>.ent.json, compiled <patchName>.ent)."
+    pattern: "^[a-z][a-z0-9_]*$"
+  - type: enum
+    name: component
+    prompt: "Which component the patch adds. camera: a gameCameraComponent bound to a slot, plus the device camera-control component."
+    values: [camera]
+  - type: string
+    name: componentName
+    prompt: "Name of the added camera component (what a script passes to FindComponentByName)."
+    pattern: "^[A-Za-z][A-Za-z0-9_]*$"
+    default: "patchCamera"
+  - type: string
+    name: bindSlotComponent
+    prompt: "The target entity's slot component the camera binds to (Item_Attachment_Slot on the one archetype the test read in full; confirm it on yours)."
+    pattern: "^[A-Za-z][A-Za-z0-9_]*$"
+    default: "Item_Attachment_Slot"
+  - type: string
+    name: bindSlot
+    prompt: "The slot in that component (Head on that archetype)."
+    pattern: "^[A-Za-z][A-Za-z0-9_]*$"
+    default: "Head"
+  - type: list
+    name: targets
+    prompt: "Vanilla entity templates to patch, one depot path per line (or semicolon-separated), e.g. base\\\\characters\\\\entities\\\\citizen\\\\citizen__default_ma.ent. Backslashes, no leading slash, lowercase, .ent."
+    itemPattern: "^[a-z0-9_]+(\\\\[a-z0-9_.]+)+\\.ent$"
+    minItems: 1
+  - type: path
+    name: xlFile
+    prompt: "Destination .archive.xl manifest (created with an empty resource.patch skeleton if missing). Put it beside the staged folder, e.g. archive-staging/<Project>.archive.xl, not inside it."
+    mustExist: false
+  - type: path
+    name: patchSourceDir
+    prompt: "Directory the patch entity's JSON source is written to, typically sources/<modSlug>."
+    mustExist: false
+  - type: path
+    name: patchCompiledDir
+    prompt: "Directory the compiled <patchName>.ent lands in, typically <archive-staging>/<Project>/mod/<modSlug> — the folder the manifest's resource.patch key names."
+    mustExist: false
+ids: []
+emits:
+  # The whole patch entity in one op, and deliberately so. The earlier
+  # draft wrote an empty `components: []` skeleton and appended each
+  # component with `insert-xl-entry` at `components.-` (the shape
+  # `new-garment-refit` uses, where an input-derived depot path with
+  # backslashes in it cannot be substituted into hand-typed JSON text).
+  # Nothing that lands inside this body carries a backslash — every input
+  # reaching it is `[A-Za-z][A-Za-z0-9_]*` — and `.-` *appends*, so a
+  # second apply of this scaffold (exactly the re-run this scaffold is
+  # written for: the target list widening from one archetype to the
+  # eligible set) grew the file to two cameras and two control
+  # components, sharing names and `id`s, with nothing to catch it —
+  # `cp2077.vehicles.cr2w-unique-ids` checks `HandleId`/`BufferId`, not
+  # `id`. One `write-text` with `ifExists: skip` is idempotent instead,
+  # and writes exactly the test's own file.
+  #
+  # The camera block is the turret's `gameCameraComponent`
+  # (`security_turret_1.ent`, extracted and read) — its numeric, name,
+  # plane and zoom fields, at identity transform; the eighteen
+  # `animParam*` CName defaults it also carries are not copied, matching
+  # the test's own file, which compiled and loaded without them. The
+  # `parentTransform` binding is the shape the base entity uses for its
+  # own `Targeting_Head` component. `HandleId: "0"` is this file's only
+  # handle.
+  #
+  # The two `id`s are fixed, chosen above every component id seen in a
+  # vanilla archetype (those observed run 1.7e18 to 3.5e18) so the merged
+  # entity cannot collide with one of the target's own. They are fixed,
+  # not derived, because these exact values are what the test ran with;
+  # a project applying this scaffold a *second* time, for a second patch
+  # entity over the same targets, must hand-edit the second file's two
+  # ids before both are merged into one entity.
+  - op: write-text
+    path: "${input.patchSourceDir}/${input.patchName}.ent.json"
+    ifExists: skip
+    body: |
+      {
+        "Header": {
+          "WolvenKitVersion": "8.20.0",
+          "WKitJsonVersion": "0.0.9",
+          "GameVersion": 2310,
+          "DataType": "CR2W",
+          "ArchiveFileName": "${input.patchName}.ent"
+        },
+        "Data": {
+          "Version": 195,
+          "BuildVersion": 0,
+          "RootChunk": {
+            "$type": "entEntityTemplate",
+            "components": [
+              {
+                "$type": "gameCameraComponent",
+                "farPlaneOverride": 0,
+                "fov": 60,
+                "fovOverrideValue": 0,
+                "fovOverrideWeight": 0,
+                "id": "9010000000000000001",
+                "isReplicable": 0,
+                "localTransform": {
+                  "$type": "WorldTransform",
+                  "Orientation": { "$type": "Quaternion", "i": 0, "j": 0, "k": 0, "r": 1 },
+                  "Position": {
+                    "$type": "WorldPosition",
+                    "x": { "$type": "FixedPoint", "Bits": 0 },
+                    "y": { "$type": "FixedPoint", "Bits": 0 },
+                    "z": { "$type": "FixedPoint", "Bits": 0 }
+                  }
+                },
+                "motionBlurScale": 1,
+                "name": { "$type": "CName", "$storage": "string", "$value": "${input.componentName}" },
+                "nearPlaneOverride": 0,
+                "parentTransform": {
+                  "HandleId": "0",
+                  "Data": {
+                    "$type": "entHardTransformBinding",
+                    "bindName": { "$type": "CName", "$storage": "string", "$value": "${input.bindSlotComponent}" },
+                    "enabled": 1,
+                    "enableMask": {
+                      "$type": "entTagMask",
+                      "excludedTags": { "$type": "redTagList", "tags": [ { "$type": "CName", "$storage": "string", "$value": "NoBinding" } ] },
+                      "hardTags": { "$type": "redTagList", "tags": [] },
+                      "softTags": { "$type": "redTagList", "tags": [] }
+                    },
+                    "slotName": { "$type": "CName", "$storage": "string", "$value": "${input.bindSlot}" }
+                  }
+                },
+                "weaponPlane": { "$type": "SWeaponPlaneParams", "blurIntensity": 0, "weaponNearPlaneCM": 0 },
+                "zoom": 1,
+                "zoomOverrideValue": 0,
+                "zoomOverrideWeight": 0,
+                "zoomWeaponOverrideValue": 0,
+                "zoomWeaponOverrideWeight": 0
+              },
+              {
+                "$type": "gameDeviceCameraControlComponent",
+                "id": "9010000000000000002",
+                "isReplicable": 0,
+                "name": { "$type": "CName", "$storage": "string", "$value": "${input.componentName}Control" },
+                "persistentState": null
+              }
+            ]
+          },
+          "EmbeddedFiles": []
+        }
+      }
+  - op: write-text
+    path: "${input.xlFile}"
+    ifExists: skip
+    body: |
+      {
+        "resource": { "patch": {} }
+      }
+  - op: insert-xl-entry
+    path: "${input.xlFile}"
+    pointer: "resource.patch.'mod\\${input.modSlug}\\${input.patchName}.ent'"
+    value: "${input.targets}"
+  - op: patch-project
+    add:
+      outDir: "archive-staging"
+      sources:
+        - id: "xl-${input.modSlug}"
+          path: "${input.xlFile}"
+          kind: xl
+      steps:
+        - step: exec
+          id: "deserialize-${input.modSlug}-${input.patchName}"
+          command: wolvenkit-cli
+          args: ["convert", "deserialize", "${input.patchSourceDir}/${input.patchName}.ent.json", "-o", "${input.patchCompiledDir}"]
+          expectOutputs: ["${input.patchCompiledDir}/${input.patchName}.ent"]
+          before: stage
+      deployTargets:
+        - rootId: archive
+          from: "${input.xlFile}"
+          locked: false
+          backup: true
+templates: []
+satisfies:
+  - cp2077.history.xl-manifest-lint
+  - cp2077.vehicles.cr2w-unique-ids
+  - cp2077.vehicles.cr2w-resource-path-shape
+  - cp2077.vehicles.cr2w-gameversion-header
+# `cp2077.garments.xl-entries-resolve` is deliberately absent. It resolves
+# every `resource.patch` KEY against the staged tree, and this scaffold's
+# key is `mod\<slug>\<patch>.ent` — the compiled output of the deserialize
+# step it adds, which does not exist until the build runs. Claiming that
+# rule would make the scaffold's own post-apply validate report it as
+# unresolved on a clean project. The rule is the right one to run after a
+# build, and the manual checklist says so.
+manual:
+  - title: Tune the camera and confirm the patch on every target
+    steps:
+      - "At take-over time set the camera's local orientation and offset from your script (the test's values on an NPC head slot: roll 90 degrees about the bone's X, 0.15 forward, 0.06 up); the patch ships the component at identity so one block serves every target."
+      - "Confirm the targets list covers the entities the mod addresses: mechanical NPCs (drones, mechs, androids) live under other template folders than base\\\\characters\\\\entities, and the index does not yet map a Character record to its template path, so find those paths with a resource prefix lookup and add them."
+      - "After a launch, read ArchiveXL.log: one \"Component \\\"${input.componentName}\\\" ... added to <target>\" line per target the game loaded; a missing line means a path in the list did not resolve."
+      - "Run validate again after a build, not only after this scaffold: cp2077.garments.xl-entries-resolve checks that the manifest's resource.patch key resolves to a staged file, and mod\\\\${input.modSlug}\\\\${input.patchName}.ent only exists once the deserialize step has run."
+      - "Write the control system yourself. The test proved the camera takes the view on Activate and nothing beyond that: DeviceStartPlayerCameraControlEvent queued on the patched NPC gave no mouse look, and movement, aim and fire were never exercised. Do not assume the device camera-control component routes player input to a puppet."
+      - "Re-applying this scaffold for a second patch entity over the same targets: hand-edit the second file's two component ids (9010000000000000001/2 are fixed here), or the two patches merge into one entity with colliding component ids."
+    expected: "Every listed target carries ${input.componentName} at load, and activating it from a script puts the game view at the bound slot."
+claim:
+  idSuffix: "${input.patchName}.applies"
+  claim: "ArchiveXL adds ${input.componentName} to each entity in ${input.patchName}'s target list at load, and the component is reachable through FindComponentByName on a spawned instance."
+testRows:
+  - gate: P-1
+    title: "Patched component present on a spawned target"
+    expected: "Through the bridge, spawn one target entity and read FindComponentByName(\"${input.componentName}\") on it: non-nil, and ArchiveXL.log carries the added-component line for that target."
+    manual: true
+    probeKinds: []
+evidence: ["ModWright research"]

package/scaffolds/cyberpunk2077/new-garment-refit.yaml

@@ -0,0 +1,279 @@
+# new-garment-refit (Cyberpunk 2077) — registers a body type in ArchiveXL's
+# `player.bodyTypes` with gendered patch `.ent`s supplying the `Body:<Type>`
+# component PuppetStateSystem looks up, and a TweakXL record for the
+# garment item itself.
+#
+# Scope: this scaffold stops at the body-type registration and the TweakXL
+# record — it does NOT author the item's own dynamic-appearance mesh-entity pair (a
+# blank-appearance root `.ent` plus a `{gender}`/`{body}`-substituted mesh
+# entity, the shape `jacket.ok.synthetic` demonstrates). That pair *is* the
+# Blender refit itself: the work splits as "Scaffolded: .xl registration,
+# .ent patch entries, TweakXL record | Human: the Blender refit" — the mesh-entity `.ent`'s own substituted component depotPaths
+# only exist once the refit's actual meshes do. Every garment rule this
+# scaffold's own emits could trigger (dynamicappearance-tag-present,
+# substitution-star-prefix, gendered-appearance-suffix, etc.) is
+# consequently vacuous here — a real pass over the human's own mesh-entity
+# `.ent` once written, not a promise this scaffold's output alone satisfies.
+#
+# Deviations observed in game (2026-09):
+#   - the `.archive.xl` `resource.patch` keys were hardcoded to
+#     `mod\<slug>\body_patch_male.ent` / `_female.ent` while the `.ent.json`
+#     sources were written to whatever free-form `malePatchEntFile` /
+#     `femalePatchEntFile` named — so the manifest could point at files
+#     nothing produces. Both free-form inputs are replaced with one
+#     `archiveStagingDir` input (a project source of kind "archive-staging"),
+#     so both ends share one `mod/<slug>/body_patch_<gender>` stem and agree
+#     by construction. The editable half was then moved out of the staging
+#     tree (2026-09-11): the sources are written to
+#     `sources/${modSlug}/body_patch_<gender>.ent.json` and the two
+#     `convert deserialize` build steps below compile them to
+#     `${archiveStagingDir}/mod/${modSlug}/body_patch_<gender>.ent` — the
+#     depot key unchanged, and no CR2W JSON left in the packed archive.
+#   - `cp2077.history.xl-manifest-lint` (src/surfaces/cyberpunk2077/
+#     validators/xl.ts) rejected the `player:` key this scaffold writes;
+#     fixed there — `player` is now a known top-level key with a
+#     `bodyTypes` shape check, citing
+#     cp2077.archivexl.bodytypes.player-bodytypes-key.
+#   - the same lint pass unconditionally required a `localization:`
+#     block with an `onscreens` mapping, but this scaffold writes no loca of
+#     its own. Fixed here (not in the validator, which stays untouched
+#     beyond the `player` key fix) by emitting the documented empty shape,
+#     `"localization": { "onscreens": {} }` — matching the skeleton
+#     `new-item-chain` already writes for the same reason (`new-project`
+#     writes no `.xl` at all).
+id: cyberpunk2077.new-garment-refit
+game: cyberpunk2077
+title: New Cyberpunk 2077 garment body-type refit
+summary: Register a body type in ArchiveXL's player.bodyTypes with gendered patch .ents carrying the Body:<Type> component, plus a TweakXL record for the garment item.
+modTypes: [garment, refit]
+needs: { index: true }
+inputs:
+  - type: string
+    name: bodyType
+    prompt: "Body type name registered in player.bodyTypes, e.g. Adonis."
+    pattern: "^[A-Za-z][A-Za-z0-9_]*$"
+  - type: index-ref
+    name: base
+    prompt: "$base TweakDB record this garment item inherits from, e.g. Items.GenericInnerChestClothing."
+    lookup: { kind: record, params: { name: "${input.base}" } }
+    requires: []
+  - type: string
+    name: itemName
+    prompt: "TweakDB record name / appearanceResourceName for this garment item."
+    pattern: "^[A-Za-z][A-Za-z0-9_]*$"
+  - type: string
+    name: outfitSlot
+    prompt: "OutfitSlots.* value this garment's placementSlots should !append."
+    default: "OutfitSlots.TorsoInner"
+  - type: string
+    name: modSlug
+    prompt: "Lowercase depot folder name for this garment, e.g. hexweave."
+    pattern: "^[a-z][a-z0-9_]*$"
+  - type: string
+    name: maleMeshPath
+    prompt: "Depot path (backslash, lowercase) to the male body-type mesh, e.g. mod\\\\hexweave\\\\meshes\\\\body_ma.mesh."
+    pattern: "^[a-z0-9_]+(\\\\[a-z0-9_]+)*\\.mesh$"
+  - type: string
+    name: femaleMeshPath
+    prompt: "Depot path (backslash, lowercase) to the female body-type mesh."
+    pattern: "^[a-z0-9_]+(\\\\[a-z0-9_]+)*\\.mesh$"
+  - type: path
+    name: tweaksFile
+    prompt: "Destination .yaml under a project source of kind \"tweaks\" (created if missing)."
+    mustExist: false
+  - type: path
+    name: xlFile
+    prompt: "Destination .archive.xl manifest (created with an empty skeleton if missing). Put it beside the staged folder, e.g. archive-staging/<Project>.archive.xl, not inside it; it is registered as a project source and deployed to archive/pc/mod by its file name."
+    mustExist: false
+  - type: path
+    name: archiveStagingDir
+    prompt: "Project-relative archive-staging root (a project source of kind \"archive-staging\") this garment's compiled files land under. The male/female patch .ent.json sources are written to sources/<modSlug>/ and deserialized into mod/<modSlug>/body_patch_<gender>.ent within it by the build steps this scaffold adds, so they agree by construction with the mod\\<modSlug>\\body_patch_<gender>.ent depot keys it writes into resource.patch (observed in game, 2026-09-11)."
+    mustExist: false
+ids:
+  - name: recordName
+    slot: "Items.${project.name}_${input.itemName}"
+    form: tweak-record
+    collision:
+      project: true
+      index: { kind: record, param: name }
+emits:
+  - op: insert-block
+    path: "${input.tweaksFile}"
+    createIfMissing: ""
+    anchor: append
+    body: |
+      ${ids.recordName}:
+        $base: ${input.base}
+        appearanceResourceName: ${input.itemName}
+        placementSlots:
+          - !append ${input.outfitSlot}
+  - op: write-text
+    path: "${input.xlFile}"
+    ifExists: skip
+    body: |
+      {
+        "localization": { "onscreens": {} },
+        "player": { "bodyTypes": [] },
+        "resource": { "patch": {} }
+      }
+  - op: insert-xl-entry
+    path: "${input.xlFile}"
+    pointer: player.bodyTypes.-
+    value: "${input.bodyType}"
+  # Observed in game (2026-09-11): with `value: []` ArchiveXL
+  # logged `[error] Line #N: Patch definition must have at least one
+  # target.` for each entry and `Archive extensions are loaded with issues`,
+  # so the patch .ents never attached to anything. The targets below are
+  # the vanilla player first-person entities, base plus the Phantom Liberty
+  # twin per gender: the pair a working project's own shipped manifest patches, which
+  # loaded in the same launch with ArchiveXL logging `[ResourcePatch]
+  # Component ... added to
+  # ep1\characters\entities\player\player_wa_fpp_ep1.ent`, and the pairing
+  # cp2077.history.xl-manifest-lint already requires. The base\ pair is in
+  # the vanilla index (`player_ma_fpp.ent`, `player_wa_fpp.ent`). Whether the
+  # third-person entities (player_XX_tpp.ent, present in the vanilla index)
+  # also need the component for a body mesh to show in third person is not
+  # yet observed; the ArchiveXL body-mod doc names "player_wa.ent /
+  # player_ma.ent" without a full path.
+  - op: insert-xl-entry
+    path: "${input.xlFile}"
+    pointer: "resource.patch.'mod\\${input.modSlug}\\body_patch_male.ent'"
+    value:
+      - "base\\characters\\entities\\player\\player_ma_fpp.ent"
+      - "ep1\\characters\\entities\\player\\player_ma_fpp_ep1.ent"
+  - op: insert-xl-entry
+    path: "${input.xlFile}"
+    pointer: "resource.patch.'mod\\${input.modSlug}\\body_patch_female.ent'"
+    value:
+      - "base\\characters\\entities\\player\\player_wa_fpp.ent"
+      - "ep1\\characters\\entities\\player\\player_wa_fpp_ep1.ent"
+  # A hand-typed JSON `write-text` body cannot safely carry a backslash-
+  # bearing depot path (`${input.maleMeshPath}`) as a raw string
+  # substitution — interpolation is plain text, not JSON-escaping, so an
+  # embedded single backslash breaks the JSON it lands in. `insert-xl-entry`
+  # sidesteps this: its `value` is a structured object, serialized through
+  # `JSON.stringify` (which escapes backslashes correctly), so the skeleton
+  # below is written free of any input-derived path text and the mesh
+  # component (the one field carrying a depot path) is appended separately.
+  - op: write-text
+    path: "sources/${input.modSlug}/body_patch_male.ent.json"
+    ifExists: skip
+    body: |
+      {
+        "Header": {
+          "WolvenKitVersion": "8.20.0",
+          "WKitJsonVersion": "0.0.9",
+          "GameVersion": 2310,
+          "DataType": "CR2W",
+          "ArchiveFileName": "body_patch_male.ent"
+        },
+        "Data": {
+          "Version": 195,
+          "BuildVersion": 0,
+          "RootChunk": { "$type": "entEntityTemplate", "components": [] },
+          "EmbeddedFiles": []
+        }
+      }
+  - op: insert-xl-entry
+    path: "sources/${input.modSlug}/body_patch_male.ent.json"
+    pointer: Data.RootChunk.components.-
+    value:
+      $type: entMeshComponent
+      name: { $type: CName, $storage: string, $value: "Body:${input.bodyType}" }
+      mesh:
+        DepotPath: { $type: ResourcePath, $storage: string, $value: "${input.maleMeshPath}" }
+        Flags: Soft
+  - op: write-text
+    path: "sources/${input.modSlug}/body_patch_female.ent.json"
+    ifExists: skip
+    body: |
+      {
+        "Header": {
+          "WolvenKitVersion": "8.20.0",
+          "WKitJsonVersion": "0.0.9",
+          "GameVersion": 2310,
+          "DataType": "CR2W",
+          "ArchiveFileName": "body_patch_female.ent"
+        },
+        "Data": {
+          "Version": 195,
+          "BuildVersion": 0,
+          "RootChunk": { "$type": "entEntityTemplate", "components": [] },
+          "EmbeddedFiles": []
+        }
+      }
+  - op: insert-xl-entry
+    path: "sources/${input.modSlug}/body_patch_female.ent.json"
+    pointer: Data.RootChunk.components.-
+    value:
+      $type: entMeshComponent
+      name: { $type: CName, $storage: string, $value: "Body:${input.bodyType}" }
+      mesh:
+        DepotPath: { $type: ResourcePath, $storage: string, $value: "${input.femaleMeshPath}" }
+        Flags: Soft
+  # Design change (2026-09-11): the two patch .ent.json sources used to be
+  # written straight into the archive-staging tree, where the pack step
+  # would ship them as JSON (a scratch project needed a hand
+  # `exclude` for them) and nothing compiled them. They now live under
+  # sources/<modSlug>/ and two deserialize steps, placed ahead of the stage
+  # step, compile them to the mod\<modSlug>\body_patch_<gender>.ent depot
+  # paths the resource.patch entries name. The manifest is registered as a
+  # project source and an archive deploy target.
+  - op: patch-project
+    add:
+      outDir: "archive-staging"
+      sources:
+        - id: "xl-${input.modSlug}"
+          path: "${input.xlFile}"
+          kind: xl
+      steps:
+        - step: exec
+          id: "deserialize-${input.modSlug}-patch-male"
+          command: wolvenkit-cli
+          args: ["convert", "deserialize", "sources/${input.modSlug}/body_patch_male.ent.json", "-o", "${input.archiveStagingDir}/mod/${input.modSlug}"]
+          expectOutputs: ["${input.archiveStagingDir}/mod/${input.modSlug}/body_patch_male.ent"]
+          before: stage
+        - step: exec
+          id: "deserialize-${input.modSlug}-patch-female"
+          command: wolvenkit-cli
+          args: ["convert", "deserialize", "sources/${input.modSlug}/body_patch_female.ent.json", "-o", "${input.archiveStagingDir}/mod/${input.modSlug}"]
+          expectOutputs: ["${input.archiveStagingDir}/mod/${input.modSlug}/body_patch_female.ent"]
+          before: stage
+      deployTargets:
+        - rootId: archive
+          from: "${input.xlFile}"
+          locked: false
+          backup: true
+templates: []
+satisfies:
+  - cp2077.garments.body-tag-registration
+  - cp2077.garments.substitution-star-prefix
+  - cp2077.garments.placeholder-known
+  - cp2077.garments.substitution-combination-resolves
+  - cp2077.garments.gendered-appearance-suffix
+  - cp2077.garments.dynamicappearance-tag-present
+  - cp2077.garments.visual-tags-resolve
+  - cp2077.garments.root-entity-blank-appearance
+  - cp2077.garments.xl-entries-resolve
+manual:
+  - title: The refit itself (Blender) and base_body regression
+    steps:
+      - "In Blender, refit the garment mesh onto the ${input.bodyType} body shape and export the mesh-entity chain: a blank-appearance root .ent (DynamicAppearance tag) plus a mesh entity .ent whose component depotPath substitutes {gender}/{body}, per the jacket pilot's own shape."
+      - "Stage the refitted meshes at the {gender}/{body} combinations the mesh entity's substituted path names, or cp2077.garments.substitution-combination-resolves will block on the real chain once it exists."
+      - "Confirm base_body (the unmodified vanilla mesh) still renders correctly for players who have not selected ${input.bodyType} — the acceptance criterion this pilot's own table calls out."
+    expected: "The garment renders correctly on both ${input.bodyType} and base_body, with the right mesh for each registered gender."
+claim:
+  idSuffix: body-type-registered
+  claim: "${input.bodyType} is registered in player.bodyTypes with gendered patch .ents supplying its Body:${input.bodyType} component, and ${ids.recordName} exists with $base ${input.base}."
+testRows:
+  - gate: R-1
+    title: "TweakXL record and body-type patch load without error"
+    expected: "TweakXL-<timestamp>.log and ArchiveXL's own log show no error for ${input.xlFile} or ${input.tweaksFile}."
+    manual: true
+    probeKinds: []
+  - gate: R-2
+    title: "Correct mesh for the registered body tag; base_body unaffected"
+    expected: "CET spawn-and-inspect confirms the right mesh for ${input.bodyType} and that base_body still renders the vanilla mesh."
+    manual: true
+    probeKinds: []
+evidence: ["ModWright research"]