Assembly Quality

Assembly quality gate

This is the generic guardrail for assembly work. It complements edit-usd-assembly and build-vehicle; it does not create a second USD authoring path.

For a mission or operations-facing assembly, use the mission and engineering quality gates as the system-level companion: ConOps, interface control, model-fidelity limits, fault cases, progressive verification/validation, deterministic replay, and configuration baselines are part of assembly readiness, not post-hoc documentation.

Non-negotiable boundaries

• Never hand-edit .usd/.usda text, paste a generated USDA replacement, or mutate ECS entities to make a preview look right. USD is authored through the document owner and its journal; ECS is only the projection.
• Use Editor Perspective for component and assembly edits. Build/View are for composing or operating the mounted Twin. Activate the editor with the typed ActivatePerspective { id: "editor" } command and keep the focused preview visible while iterating.
• Use exact DocumentId, UsdPreviewId, UsdPreviewViewId, edit target, USD paths, and generation returned by discovery. Never infer an id or target from a display name, a screenshot, or a stale file.
• Keep identity/topology/facts in USD, mission policy and requirements in Twin-owned Rhai/SysML, equations in Modelica, and generic substrate in Rust. A missing generic capability is a small typed-tool feature request, not a vehicle-specific Rust implementation.

Plan a believable assembly before adding detail

1. Define the contract in SI metres (Y-up, right-handed, -Z-forward): root datum, envelope, mass/collision owner, attachment frames, interfaces, supported variants, and the evidence that will prove it.
2. Reuse the nearest existing component or assembly. One reusable or articulated component gets one explicit root and a separate Twin asset; the assembly owns references, instances, sockets, joints, placement and cross-component wiring.
3. Use named mount sockets/plugs and frame relationships. Place a part with assembly_builder::place_or_attach_plan, align_frames_plan, or the mount realignment planner. Do not copy guessed translations between parts.
4. Prefer standard USD schemas and primitive geometry for silhouette, mounting envelopes, collision and visible identity. Add detail only when it changes a contract, interface, physical envelope or recognizable shape.
5. Keep independent visual and physical roles explicit. A visual proxy may be visual-only, but never hide a missing body, joint, collider or reference.

The live edit loop

Use this sequence for every component and then for the composed assembly:

discover document + preview + generation
  -> inspect exact composed paths and target ownership
  -> pure Rhai *_plan (typed USD ops only)
  -> review/apply with assembly_edit::batch or proposal flow
  -> wait for projection_ready and matching projected_generation
  -> QueryUsdPrim / InspectUsdDocument / lint readback
  -> Editor screenshot and image inspection
  -> component test, then assembly integration test
  -> explicit save through the Editor document owner

Use RegisterToolLibrary to hot-reload a Rhai tool in the running process; verify a real namespaced call, not just ListToolLibraries. Restart only when the Rust binary changed. Every plan must be dry, generation-aware and idempotent or reject a completed contract; applying a plan must never silently flatten a referenced source.