(spec) Update devtools, integration catalog, and motor actuation migration spec

- Refresh devtools spec for current CLI surface
- Add new integration test IDs to catalog
- Update solution-motor-actuation-backend-parity migration notes

Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

Author: MRiabov

specs/devtools.md

@@ -63,7 +63,7 @@ The integration runner is a real-stack boundary contract, not a synthetic test h
 
 ### Severity classification
 
-- Devtool integration tests should be classified as `p1` or `p2` by default; `p0` is reserved for exceptional cases only.
+- Devtool integration tests should be classified as `p1` or `p2` priority by default; `p0` priority is reserved for exceptional cases only.
 
 ### Public entrypoint
 

specs/integration-test-list.md

@@ -146,6 +146,8 @@ This section is the smallest must-pass set. Keep it narrowly scoped, determinist
 | INT-218 | Skill catalog overlay precedence | `suggested_skills/` entries shadow canonical `skills/` entries when resolving skill reads and catalog entries, with overlay duplicates taking precedence over the approved tree. |
 | INT-219 | Skill overlay promotion publication contract | The promotion arbiter publishes the session overlay into canonical `skills/`, records the approved base commit and resulting promotion commit, and persists a traceable promotion record. |
 | INT-220 | Skill overlay promotion conflict gate | Dirty canonical repo state or unresolved overlay conflicts fail closed, do not publish a commit, and still emit a promotion record with the conflict reason. |
+| INT-222 | Skill overlay seeding replay contract | A retained skill-training session seeds `suggested_skills/` from the canonical `skills/` snapshot, records the approved base commit and repository root metadata, and resolves later reads against the seeded overlay first. |
+| INT-223 | Skill overlay deletion publication contract | A seeded overlay promotion applies deletions as part of the session diff, records the deleted paths in the promotion result, and removes deleted files from canonical `skills/` on publication. |
 | INT-066 | Fluid-on-electronics failure coupling | In electromechanical simulations with fluids enabled, fluid contact with powered electrical components triggers electrical failure state and benchmark failure/penalty path. |
 | INT-067 | Steerability exact-pointing + mention payload contract | Face/edge/vertex/part/subassembly selections and `@`-mentions are accepted over API/UI boundary, preserved in prompt payload, and observable in run traces/events used by the agent. |
 | INT-068 | Line-targeted steering contract | `@path/file.py:start-end` style references resolve and provide the exact requested code span to the agent context in the majority path; invalid ranges fail with explicit user-visible validation errors. |

specs/migrations/minor/solution-motor-actuation-backend-parity.md

@@ -225,41 +225,41 @@ The safe order is:
 
 ### Contract
 
-- [ ] Lock the solution motor contract in `AssemblyDefinition` and the moving
+- [x] Lock the solution motor contract in `AssemblyDefinition` and the moving
   part mapping.
 - [ ] Keep the MuJoCo reference behavior stable while the parity work lands.
-- [ ] Define the Genesis motor materialization strategy from the same shared
+- [x] Define the Genesis motor materialization strategy from the same shared
   contract.
-- [ ] Add the visible motor example to the new `electromechanics-syntax` skill
+- [x] Add the visible motor example to the new `electromechanics-syntax` skill
   if authors need a concrete reference.
 
 ### Runtime
 
-- [ ] Materialize solution motors as real controllable DOFs in Genesis.
-- [ ] Normalize `apply_control()`, `get_actuator_state()`, and
+- [x] Materialize solution motors as real controllable DOFs in Genesis.
+- [x] Normalize `apply_control()`, `get_actuator_state()`, and
   `get_all_actuator_names()` across backends.
 - [ ] Keep power gating and overload monitoring backend-agnostic.
-- [ ] Fail closed on unresolved or unsupported motor mappings.
-- [ ] Keep the validation and file-validation path fail-closed on missing or
+- [x] Fail closed on unresolved or unsupported motor mappings.
+- [x] Keep the validation and file-validation path fail-closed on missing or
   incompatible motor mappings before simulation starts.
 
 ### Validation
 
 - [ ] Preserve the shared validation path that turns moving parts into
   controller inputs.
-- [ ] Add a validation failure for missing or invalid motor mappings before
+- [x] Add a validation failure for missing or invalid motor mappings before
   simulation starts.
 - [ ] Make the validation failure surface the same motor identity and control
   mode context that the simulation path uses.
 
 ### Tests
 
-- [ ] Add or refresh integration tests for a motorized solution on MuJoCo.
-- [ ] Add or refresh integration tests for the same solution contract on
+- [x] Add or refresh integration tests for a motorized solution on MuJoCo.
+- [x] Add or refresh integration tests for the same solution contract on
   Genesis.
-- [ ] Add negative integration coverage for unresolved motor mappings.
-- [ ] Add regression coverage for unpowered and overloaded motors.
-- [ ] Refresh `specs/integration-test-list.md` so the solution-motor parity row
+- [x] Add negative integration coverage for unresolved motor mappings.
+- [x] Add regression coverage for unpowered and overloaded motors.
+- [x] Refresh `specs/integration-test-list.md` so the solution-motor parity row
   is explicit and tied to the actual integration coverage.
 
 ### Docs