refactor: move Go2 arm manipulation into its standalone repository

.gitignore

@@ -87,7 +87,6 @@ src/unilab/assets/robots/go2/assets/
 src/unilab/assets/robots/a2/assets/
 src/unilab/assets/robots/allegro_hand/assets/
 src/unilab/assets/robots/sharpa_wave/meshes/
-src/unilab/assets/robots/go2_arm/assets/
 
 # Grasp cache assets (downloaded from HF at runtime)
 src/unilab/assets/caches/*.npy

docs/sphinx/source/api_reference/algos/index.md

@@ -8,7 +8,6 @@ published on PyPI; issue #1480):
 - `uni_rl.algos.appo` — APPO runner, learner, staging, worker
 - `uni_rl.algos.fast_sac` / `uni_rl.algos.fast_td3` / `uni_rl.algos.flash_sac` — off-policy learners and runners
 - `uni_rl.offpolicy` — generic off-policy runner, worker, thread budget
-- `uni_rl.algos.him_ppo` — HIM-PPO
 - `uni_rl.algos.hora` — HORA models, trainers, and distillation
 - `uni_rl.algos.common` — shared actor factory, networks, normalization, compile helpers
 

docs/sphinx/source/api_reference/tasks/locomotion.md

@@ -11,6 +11,5 @@
    unilab.tasks.locomotion.g1
    unilab.tasks.locomotion.go1
    unilab.tasks.locomotion.go2
-   unilab.tasks.locomotion.go2_arm
    unilab.tasks.locomotion.go2w
 ```

docs/sphinx/source/changelog.md

@@ -13,6 +13,15 @@ UniLab 遵循[语义化版本](https://semver.org/)。本共享页面以中英
 
 ## Unreleased / 未发布
 
+- Go2 arm manipulation/locomotion, its legacy helpers, assets, tools and HIM-PPO
+  owners moved to [legged-manipulation_unilab](https://github.com/unilabsim/legged-manipulation_unilab)
+  under [#1528](https://github.com/unilabsim/UniLab/issues/1528). Dedicated source
+  content and compatibility imports are removed; shared backend contracts remain.
+  Go2 机械臂任务及专属辅助模块、资产、工具和 HIM-PPO 配置迁入独立仓库，原入口移除。
+  Per maintainer instruction, this migration does not change repository versions
+  or publish a release; consumers use the coordinated migration commits.
+  按维护者要求，本次不修改仓库版本号、不发布新版本，消费方固定配套迁移提交。
+
 ## 1.1.0 (2026-09-06)
 
 - Update the required `unisim-core` release to `>=1.1.3`, including the ROCm

docs/sphinx/source/en/0-index.md

@@ -108,7 +108,7 @@ capability requirements.
 :::{grid-item-card} Pick an algorithm
 :link: 2-user_guide/2-algorithms/0-index
 :link-type: doc
-Compare PPO, APPO, SAC, TD3, FlashSAC, HIM-PPO, and HORA entrypoints.
+Compare PPO, APPO, SAC, TD3, FlashSAC, and HORA entrypoints.
 :::
 
 :::{grid-item-card} Deploy or switch sims
@@ -155,7 +155,6 @@ committed benchmark manifest or separate recommendation metadata.
 | --- | --- | --- |
 | Go1 joystick | PPO, APPO, TD3 | PPO has tested MuJoCo and Motrix rows. APPO has tested MuJoCo rows and Motrix registered rows. TD3 has a Motrix owner YAML for `go1_joystick_flat`. |
 | Go2 joystick | PPO, FlashSAC, TD3 | PPO has tested MuJoCo and Motrix rows. FlashSAC has MuJoCo owner YAMLs for `go2_joystick_flat`; TD3 has a Motrix owner YAML for `go2_joystick_flat`. |
-| Go2 arm manip-loco | PPO, HIM-PPO | Committed MuJoCo owner YAMLs are present under `src/unilab/conf/ppo/task/go2_arm_manip_loco/` and `src/unilab/conf/ppo_him/task/go2_arm_manip_loco/`. |
 | Go2W joystick | PPO | PPO owner YAMLs exist for MuJoCo and Motrix flat/rough variants under `src/unilab/conf/ppo/task/go2w_joystick_*`. |
 | G1 locomotion / tracking | PPO, APPO, SAC, TD3 | PPO, APPO, and SAC include committed MuJoCo and Motrix owner YAMLs for G1 tasks; TD3 has a `g1_walk_flat` MuJoCo owner. |
 | Allegro in-hand | PPO, APPO | PPO and APPO have committed MuJoCo and Motrix owner YAMLs for Allegro in-hand tasks. |

docs/sphinx/source/en/1-getting_started/1-quick_demo.md

@@ -43,7 +43,7 @@ uv run demo dance
 ```
 
 Available demo names are `teaser`, `dance`, `wallflip`, `boxtracking`,
-`locomani`, and `inhandgrasp`. Use `uv run demo --help` for device and refresh
+and `inhandgrasp`. Use `uv run demo --help` for device and refresh
 options.
 
 ## Train A Task

docs/sphinx/source/en/1-getting_started/4-project_structure.md

@@ -10,7 +10,7 @@ changing behavior.
 | `src/unilab/conf/` | Hydra roots and task owner YAMLs. The top-level CLI exposes backend selection as `--task` plus `--sim`, then composes the matching owner YAML. |
 | `src/unilab/base/` | Registry, env state, scene, and backend contracts. |
 | `src/unilab/envs/` | Task env implementations and task-specific reset, reward, observation, and DR logic. |
-| `uni_rl` (unilab-rl repo) | PPO, APPO, off-policy, HIM-PPO, and HORA algorithm code. |
+| `uni_rl` (unilab-rl repo) | PPO, APPO, off-policy, and HORA algorithm code. |
 | `uni_rl.ipc` (unilab-rl repo) | Shared-memory and async runner primitives. |
 | `src/unilab/training/` | Shared training helpers for logging, playback, seed handling, and config guards. |
 | `src/unilab/visualization/` | Playback, rendering, NaN inspection, and scene/export utilities. |
@@ -27,8 +27,7 @@ The main config roots are:
 - `src/unilab/conf/sac/config.yaml`, `src/unilab/conf/td3/config.yaml`, and
   `src/unilab/conf/flashsac/config.yaml` for SAC, TD3, and FlashSAC, each with its
   algorithm hyperparameters inlined.
-- `src/unilab/conf/ppo_him/config.yaml` and `src/unilab/conf/hora_distill/config.yaml` for the
-  specialized HIM-PPO and HORA paths.
+- `src/unilab/conf/hora_distill/config.yaml` for HORA student distillation.
 
 Task owner YAMLs are the backend identity. Examples:
 

docs/sphinx/source/en/2-user_guide/0-index.md

@@ -15,7 +15,7 @@ CLI routes, Hydra owner YAMLs, logs, checkpoints, and Docker.
 :::{grid-item-card} Algorithms
 :link: 2-algorithms/0-index
 :link-type: doc
-Compare PPO, APPO, SAC, TD3, FlashSAC, HIM-PPO, and HORA.
+Compare PPO, APPO, SAC, TD3, FlashSAC, and HORA.
 :::
 
 :::{grid-item-card} Backends

docs/sphinx/source/en/2-user_guide/1-training/1-cli_reference.md

@@ -110,12 +110,11 @@ directly to `play_interactive.py` and always rolls out one environment.
 uv run demo dance
 uv run demo wallflip
 uv run demo boxtracking
-uv run demo locomani
 uv run demo inhandgrasp
 uv run demo dance --refresh --device cpu
 ```
 
-Available demos: `teaser`, `dance`, `wallflip`, `boxtracking`, `locomani`, `inhandgrasp`.
+Available demos: `teaser`, `dance`, `wallflip`, `boxtracking`, `inhandgrasp`.
 Each demo fetches a pre-trained checkpoint from the
 `unilabsim/unilab-checkpoints` Hugging Face dataset on first run and caches it
 under `src/unilab/assets/checkpoints/<demo>/model_0.pt`. Pass `--refresh` to

docs/sphinx/source/en/2-user_guide/1-training/2-hydra_config.md

@@ -10,7 +10,6 @@ identity of the task, backend, reward, scene, and task-specific runtime fields.
 | PPO | `src/unilab/conf/ppo/task/<task>/<backend>.yaml` |
 | APPO | `src/unilab/conf/appo/task/<task>/<backend>.yaml` |
 | SAC / TD3 / FlashSAC | `src/unilab/conf/<algo>/task/<task>/<backend>.yaml` |
-| HIM-PPO | `src/unilab/conf/ppo_him/task/<task>/<backend>.yaml` |
 | HORA distillation | `src/unilab/conf/hora_distill/task/<task>/<backend>.yaml` |
 
 Examples:

docs/sphinx/source/en/2-user_guide/2-algorithms/0-index.md

@@ -11,7 +11,6 @@ lives, and which command shape selects it. For general flags, see
 | SAC | off-policy | `src/unilab/scripts/train_sac.py` | `src/unilab/conf/sac/config.yaml` |
 | TD3 | off-policy | `src/unilab/scripts/train_td3.py` | `src/unilab/conf/td3/config.yaml` |
 | FlashSAC | off-policy | `src/unilab/scripts/train_flashsac.py` | `src/unilab/conf/flashsac/config.yaml` |
-| HIM-PPO | height-estimator PPO path | `scripts/train_him_ppo.py` | `src/unilab/conf/ppo_him/config.yaml` |
 | HORA | teacher/student distillation path | `scripts/train_hora_distill.py` | `src/unilab/conf/hora_distill/config.yaml` |
 
 ```{toctree}
@@ -22,6 +21,5 @@ lives, and which command shape selects it. For general flags, see
 3-sac
 4-td3
 5-flash_sac
-6-him_ppo
 7-hora
 ```

docs/sphinx/source/en/2-user_guide/4-tasks/0-index.md

@@ -24,12 +24,6 @@ G1 motion tracking, flips, climbs, wall flips, and box tracking.
 Allegro and Sharpa in-hand rotation and grasp generation.
 :::
 
-:::{grid-item-card} Mobile manipulation
-:link: 4-manip_loco
-:link-type: doc
-Go2 plus Airbot arm locomotion and manipulation.
-:::
-
 ::::
 
 ```{toctree}
@@ -38,5 +32,4 @@ Go2 plus Airbot arm locomotion and manipulation.
 1-locomotion
 2-motion_tracking
 3-manipulation
-4-manip_loco
 ```

docs/sphinx/source/en/2-user_guide/4-tasks/1-locomotion.md

@@ -12,7 +12,6 @@ define which algorithm and backend combinations are runnable.
 - G1 walking: `g1_walk_flat`, `g1_walk_rough`
 - G1 motion tracking: `g1_motion_tracking`, `g1_flip_tracking`,
   `g1_wall_flip_tracking`, `g1_climb_tracking`, `g1_box_tracking`
-- Go2 arm: `go2_arm_manip_loco`
 
 ## Examples
 

docs/sphinx/source/en/2-user_guide/4-tasks/3-manipulation.md

@@ -1,7 +1,6 @@
 # Manipulation
 
-Manipulation tasks live in `src/unilab/tasks/manipulation/` and the Go2 arm
-manip-loco env lives in `src/unilab/tasks/locomotion/go2_arm/`.
+Manipulation tasks live in `src/unilab/tasks/manipulation/`.
 
 ## In-Hand
 
@@ -36,13 +35,4 @@ training-stable under load.
 uv run train --algo ppo --task stewart_balance --sim motrix training.no_play=true
 ```
 
-## Mobile Manipulation
-
-`go2_arm_manip_loco` is the committed Go2 + Airbot owner path:
-
-```bash
-uv run train --algo ppo --task go2_arm_manip_loco --sim mujoco training.no_play=true
-```
-
-See {doc}`../8-manipulation/1-dexterous_inhand` and
-{doc}`../8-manipulation/2-manip_loco` for task-specific notes.
+See {doc}`../8-manipulation/1-dexterous_inhand` for in-hand task notes.

docs/sphinx/source/en/2-user_guide/5-domain_randomization/0-index.md

@@ -6,7 +6,7 @@ This page only describes the current domain randomization status of registered t
 Two DR declaration paths exist today:
 
 - **Manager-Based (Compatible) tasks**: reset / interval randomization is declared through Hydra `events:` manager terms in the owner YAML; reset-lifecycle events sample at reset, interval-lifecycle events perturb between steps. See the `events:` block of `src/unilab/conf/ppo/task/go1_joystick_flat/base.yaml` for an example.
-- **Legacy provider path**: only the 3 Adapted families (`sharpa_inhand` / `sharpa_inhand_grasp` / `go2_arm_manip_loco`, including their appo / hora / ppo_him owners) still declare `env.domain_rand.*` configuration through a `DomainRandomizationProvider` + `DomainRandomizationManager`.
+- **Legacy provider path**: only the 2 Adapted families (`sharpa_inhand` / `sharpa_inhand_grasp`, including their appo / hora owners) still declare `env.domain_rand.*` configuration through a `DomainRandomizationProvider` + `DomainRandomizationManager`.
 
 The unified entry point of the legacy provider path lives in `NpEnv._init_domain_randomization()` and `DomainRandomizationManager`:
 
@@ -24,7 +24,7 @@ These three paths correspond to three lifecycle classes:
 
 1. Manager-Based tasks do not register a DR provider; their reset/interval randomization consists of `events:` manager terms in the owner YAML, executed uniformly by the manager lifecycle. Only the frozen compatibility factories of the Adapted families still go through the `DomainRandomizationManager` unified entry point.
 2. Adapted-family owners define a `domain_rand` config dataclass, a `DomainRandomizationProvider`, and a `ResetPlan`; Manager-Based owners declare reset behavior through Hydra command/event terms. G1 motion reset perturbations belong to `MotionCommandCfg`, while WBT adds `EventTermCfg` reset and interval terms.
-3. What is "unified" today is mainly the entry point and execution flow, not every randomization item itself. The legacy path's shared helper `build_common_reset_randomization()` currently generates `base_mass_delta`, `base_com_offset`, `gravity`, `kp`, `kd`; the shared interval helper currently only generates push.
+3. What is "unified" today is mainly the entry point and execution flow, not every randomization item itself. The legacy path's shared helper `build_common_reset_randomization()` currently generates `base_mass_delta`, `base_com_offset`, `gravity`, `kp`, `kd`.
 4. `ResetRandomizationPayload` can already express `gravity`, `body_iquat`, `body_inertia`, `kp`, `kd`, and `MuJoCoBackend` has declared support. Whether these are actually used still depends on whether the task provider samples and dispatches them.
 5. `MotrixBackend` currently supports `base_mass_delta`, `base_com_offset`, `kp`, `kd`, and interval push; and it requires all model actuators to be position actuators during initialization.
 6. `geom_size` is not a reset-lifecycle field; Sharpa-hand object geom scale is handled by init-lifecycle model materialization.
@@ -43,7 +43,6 @@ These three paths correspond to three lifecycle classes:
 | `AllegroInhandRotationGrasp` | Hydra `events:` terms | Yes: reuses the rotation reset event + `RecorderTermCfg` | noisy hand reset + grasp collection | none | `allegro_inhand/grasp_gen.py` |
 | `SharpaInhandRotation` | legacy provider | Yes: `InitRandomizationPlan + ResetPlan + IntervalRandomizationPlan` | grasp cache sampling + common payload | object `body_force` | `sharpa_inhand/rotation.py` |
 | `SharpaInhandRotationGrasp` | legacy provider | Yes: reuses the Sharpa rotation provider and overrides reset sampling | grasp collection reset + common payload | none | `sharpa_inhand/grasp_gen.py` |
-| `Go2ArmManipLoco` | legacy provider | Yes: `DomainRandConfig + LocomotionDRProvider subclass + ResetPlan` | task state sampling + common payload | push | `go2_arm/manip_loco.py` |
 
 ## Per-task Domain Randomization List
 
@@ -77,14 +76,13 @@ in the owner YAML through the manager lifecycle.
 
 ### 2. The Shared Helpers Are Still Narrow
 
-The legacy path's `dr_utils.py` currently has only two classes of shared helpers:
+The legacy path's `dr_utils.py` builds and validates common reset payloads:
 
 - reset common payload: `base_mass_delta`, `base_com_offset`, `gravity`, `kp`, `kd`
-- interval common payload: push
 
 This means:
 
-- The go2_arm / sharpa families still on the legacy provider path sample their
+- The Sharpa families still on the legacy provider path sample their
   task-specific state directly inside each provider
 - `G1MotionTracking`'s pose / velocity / joint noise is owned by its manager command
 - Allegro's grasp / object initial state sampling is entirely task-specific logic
@@ -126,10 +124,9 @@ But on the task side, the current reality is: not every provider constructs thes
 - Lifecycle: only sampled and written at reset; the env retains that gravity until the next reset re-samples it.
 - Backend: currently in UniLab, only the MuJoCo backend declares support for this reset term; the Motrix backend does not. Some tasks filter it by capability and skip it; others raise an error in the validate stage.
 
-The config entry exists only under `env.domain_rand` of the Adapted-family
-owners still on the legacy provider path (`sharpa_inhand_grasp`,
-`go2_arm_manip_loco`, and their hora / appo / ppo_him variants); Manager-Based
-tasks have no `env.domain_rand`:
+The config entry lives under `env.domain_rand` in Sharpa owners on the legacy
+provider path, such as `sharpa_inhand_grasp`; Manager-Based tasks have no
+`env.domain_rand`:
 
 ```yaml
 env:
@@ -172,43 +169,15 @@ Notes:
 
 ## Interval push Usage
 
-The `env.domain_rand.push_robots` family of fields exists only in the go2_arm
-Adapted-family owners (`src/unilab/conf/ppo/task/go2_arm_manip_loco/mujoco.yaml` etc.);
-Manager-Based tasks declare push through a `push_by_setting_velocity` interval
-event term instead (for example `src/unilab/conf/ppo/task/go1_joystick_flat/base.yaml` and
-`src/unilab/conf/ppo/task/quadruped_joystick_rough/base.yaml`).
-
-The go2_arm owners configure push under `env.domain_rand`:
-
-```yaml
-env:
-  domain_rand:
-    push_robots: true
-    push_interval: 750
-    max_force: [1.0, 1.0, 0.5]
-    push_body_name: null
-```
-
-- `push_robots`: whether to enable push.
-- `push_interval`: trigger every N env steps.
-- `max_force`: a length-3 external-force upper limit; each dimension is sampled within `[-max_force, max_force]`.
-- `push_body_name`: the target body / link to apply the force to. Defaults to `null`, meaning the backend's `base_name` is used.
+Manager-Based tasks configure interval push through the `env.events.push_robot`
+term. For example, `src/unilab/conf/ppo/task/go1_joystick_flat/base.yaml` uses
+`push_by_setting_velocity` with a 15-second interval and per-axis velocity ranges.
 
 ```bash
-uv run train --algo ppo --task go2_arm_manip_loco --sim mujoco \
-  env.domain_rand.push_robots=true \
-  env.domain_rand.push_interval=500 \
-  'env.domain_rand.max_force=[20.0,20.0,5.0]' \
-  env.domain_rand.push_body_name=base
+uv run train --algo ppo --task go1_joystick_flat --sim mujoco \
+  'env.events.push_robot.interval_range_s=[10.0,10.0]'
 ```
 
-Notes:
-
-- MuJoCo resolves by body name, Motrix resolves by link name; a missing name raises an error during env/backend initialization.
-- `push_body_name` is an init config; changing it after env creation does not change the already-resolved target.
-- The hot path only samples and applies the external force; it does not parse XML / asset and does not probe backend-private capability.
-- MuJoCo push is implemented via `xfrc_applied` external force and does not directly overwrite base velocity.
-
 ## `geom_size` Lifecycle Boundary
 
 `geom_size` is explicitly not part of `ResetRandomizationPayload`, and must not be modified on the hot path via `BatchEnvPool.reset(..., randomization=...)`.

docs/sphinx/source/en/2-user_guide/5-domain_randomization/1-configuration.md

@@ -9,8 +9,8 @@ Two declaration paths exist today:
 - Manager-Based (Compatible) tasks declare reset / interval randomization
   through Hydra `events:` manager terms in the owner YAML, for example
   `src/unilab/conf/ppo/task/go1_joystick_flat/base.yaml`.
-- Only the Adapted families (sharpa / go2_arm and their hora / appo / ppo_him
-  owners) still configure legacy provider fields under `env.domain_rand`.
+- The Sharpa Adapted families and their hora / appo owners configure legacy
+  provider fields under `env.domain_rand`.
 
 ```bash
 uv run train --algo ppo --task sharpa_inhand_grasp --sim mujoco \
@@ -47,15 +47,13 @@ uv run train --algo ppo --task sharpa_inhand_grasp --sim mujoco \
 
 ## Interval Push
 
-Manager-Based tasks declare push through a `push_by_setting_velocity` interval
-event term; `env.domain_rand.push_robots` is only available on the go2_arm
-Adapted-family owners.
+Manager-Based tasks configure interval push through the `env.events.push_robot`
+term. For example, `src/unilab/conf/ppo/task/go1_joystick_flat/base.yaml` uses
+`push_by_setting_velocity` with a 15-second interval and per-axis velocity ranges.
 
 ```bash
-uv run train --algo ppo --task go2_arm_manip_loco --sim mujoco \
-  env.domain_rand.push_robots=true \
-  env.domain_rand.push_interval=500 \
-  'env.domain_rand.max_force=[20.0,20.0,5.0]'
+uv run train --algo ppo --task go1_joystick_flat --sim mujoco \
+  'env.events.push_robot.interval_range_s=[10.0,10.0]'
 ```
 
 ## Owner-Local Defaults