Spaces:
Sleeping
Sleeping
| # SimReady Foundations — process deviations | |
| Issues encountered while running the `/simready-report` skill against `yaskawa_local` | |
| that require changes in **`simready_foundations`** (or a clearly documented | |
| client-side workaround). These are not playbook bugs — the playbook is working | |
| around upstream gaps. | |
| Source data for each item: paths/codes observed during the validation run on | |
| `packages/yaskawa_local/` against `Robot-Body-Isaac` v1.0.0. | |
| --- | |
| ## 1. `Profile.capabilities` returns an empty list for every profile | |
| **Where:** `omni.asset_validator` profile schema (Python registry). | |
| **Observed:** | |
| ```python | |
| profile = oav.ProfileRegistry().find('Robot-Body-Isaac', '1.0.0') | |
| profile.capabilities # → [] | |
| profile.features # → 2 features, 8 requirements | |
| ``` | |
| Every profile in the registry returns `[]` for `.capabilities`. Profiles now | |
| declare scope through `.features` — each feature owns its requirements | |
| directly. The `capabilities` attribute is a leftover from an older schema. | |
| **Impact:** `validate_yaskawa.py` and earlier versions of this playbook's | |
| `validate.py` filtered the engine's enabled capabilities against | |
| `profile.capabilities`. Because the latter is always empty, the filter | |
| disabled **every** capability and reported `enabled capabilities: 0` while | |
| producing 6,551 issues from rules that ignored the disable calls (see #2). | |
| **Required:** remove `Profile.capabilities`, or populate it from the union of | |
| the features' capabilities, and update all reference scripts/docs that still | |
| use it. | |
| --- | |
| ## 2. `engine.enable_*` / `disable_*` do not constrain rule execution | |
| **Where:** `omni.asset_validator.ValidationEngine`. | |
| **Observed:** `engine.enable_feature(f)` and `engine.enable_requirement(r)` | |
| update `engine.enabled_features` / `engine.enabled_requirements` counters, | |
| but `engine.validate(stage)` still runs every rule registered via | |
| `@register_rule`. `engine.enabled_rules` stays at 0 even after enabling | |
| features and requirements; rules execute regardless. | |
| **Impact:** profile-scoping has to happen post-hoc, by filtering issues | |
| against the profile's requirement codes. The current playbook does this in | |
| `validate_one()` (filters failures by `code in profile_codes`). | |
| **Required:** either | |
| 1. make `enable_*` / `disable_*` actually scope rule execution, or | |
| 2. document explicitly that they are display-only and that callers must | |
| filter results themselves. Today the API name strongly implies (1). | |
| --- | |
| ## 3. `Robot-Body-Isaac` v1.0.0 silently drops 4 of 6 declared features | |
| (TOML ↔ Python registry mismatch) | |
| **Where:** `simready_foundations/_build/target-deps/pip_prebundle/simready/foundation/core/profiles/profiles.toml` | |
| vs the `Features` enum loaded from | |
| `simready.foundation.core.features`. | |
| **Observed:** `profiles.toml` declares Robot-Body-Isaac v1.0.0 with six | |
| features: | |
| | TOML entry | Loads? | Notes | | |
| |---|---|---| | |
| | `FET001_BASE_NEUTRAL` v0.1.0 | ✓ | 8 requirements | | |
| | `FET004_ROBOT_PHYSX` v0.2.0 | ✗ | No such name in `Features` enum (only `FET004_BASE_NEUTRAL`) | | |
| | `FET021_ROBOT_CORE_ISAAC` v0.2.0 | ✗ | Closest is `FET_021_ROBOT_CORE` v0.2.0 (note underscore + missing `_ISAAC`) | | |
| | `FET022_DRIVEN_JOINTS_ISAAC` v0.1.0 | ✗ | Closest is `FET_022_DRIVEN_JOINTS` v0.1.0 | | |
| | `FET024_BASE_ARTICULATION_PHYSX` v0.1.0 | ✗ | Closest is `FET_024_BASE_ARTICULATION` v0.1.0 | | |
| | `FET100_BASE_ISAACSIM` v0.1.0 | ✓ | 0 requirements | | |
| `pr.find('Robot-Body-Isaac', '1.0.0').features` therefore returns only the | |
| two features that successfully resolve. Four features (Robot Core, Driven | |
| Joints, Base Articulation, Robot Physx) are silently dropped — no warning, | |
| no error. | |
| The rules associated with the dropped features (RC.*, JT.*, RB.*, AT.*) still | |
| execute (per #2 the engine ignores feature gating), so they appear in the | |
| raw issue list, but they cannot be attributed to a profile feature for | |
| roll-up reporting. | |
| **Required:** reconcile the names. Either rename the TOML entries to match | |
| the `Features` enum (`FET_021_ROBOT_CORE` etc.), or add the `_ISAAC` / | |
| `_PHYSX` variants to the foundation as real feature implementations. Also | |
| make profile-feature lookup *fail loudly* when a declared feature can't be | |
| resolved — silent drop is the worst outcome. | |
| Validation also surfaced real failures with codes from features that | |
| **aren't even declared in the TOML profile**: | |
| | Code(s) | Source | Notes | | |
| |---|---|---| | |
| | `RC.002`, `RC.004` (`thumbnail-exist`), `RC.008`, `RC.009` | `capabilities/isaac_sim/robot_core` | Robot-core rules registered & raising issues, but no profile feature includes them | | |
| | `NP.001`, `NP.005`, `NP.006`, `NP.008` | `capabilities/visualization/nonvisual_materials` | | | |
| | `HI.001`, `HI.002` | `capabilities/hierarchy` | (`HI.004` is in profile, others aren't) | | |
| | `VG.007`, `VG.009`, `VG.016`, `VG.019`, `VG.MESH.001` | `capabilities/visualization/geometry` | (`VG.001` is in profile, the rest aren't) | | |
| | `EX.01`, `EX.03`, `GSP.001`, `ISA.001`, `VM.MDL.001` | various | | | |
| A "Robot-Body-Isaac" profile that does not require the asset to have a | |
| thumbnail, robot type, or pinned root joint, but the foundations repo ships | |
| those as registered rules, is a process gap. | |
| **Required:** extend the profile's features to include the robot-core, | |
| nonvisual-materials, hierarchy-completeness, and geometry-completeness | |
| features that are already authored in the foundation; align the JSON capability | |
| configs (`config/robot-core.json` etc.) with the Python `Profiles` enum. | |
| --- | |
| ## 4. JSON capability config and Python profile registry are not linked | |
| **Where:** `simready_foundations/nv_core/sr_specs/config/robot-core.json` vs | |
| `simready.foundation.core` Python plugin. | |
| **Observed:** `robot-core.json` declares `RobotCore` capability v1.0.0 with | |
| the `thumbnail-exist` requirement (and others). The Python registry exposes | |
| that requirement to the rule machinery (issues with `RC.004` are emitted), | |
| but no `Profile` exposes `RobotCore` as a feature, so client code that | |
| introspects `profile.features` to compute pass/fail per feature can't see it. | |
| **Impact:** validation reports list `RC.*` codes in raw issues but cannot map | |
| them to a feature, so they appear as "uncategorized" failures. | |
| **Required:** wire the JSON capability declarations into the `Features` / | |
| `Profiles` enums (or into a new `profile.capabilities` accessor that returns | |
| real entries — see #1). | |
| --- | |
| ## 5. ~87% of issues report `code: UNKNOWN` | |
| **Where:** rules registered in `omni.asset_validator` and SimReady plugins. | |
| **Observed:** of 6,551 issues across 7 robots, **5,695** have `iss.requirement | |
| is None`, so the issue cannot be attributed to any requirement code: | |
| ``` | |
| 5695 UNKNOWN | |
| 129 NP.001 | |
| 116 HI.002 | |
| 116 VG.009 | |
| 96 VG.007 | |
| ... | |
| ``` | |
| These come from rules that don't decorate with `@register_requirements`, so | |
| they run but have no requirement linkage. | |
| **Impact:** profile-scoped filtering (#2's workaround) drops 87% of the signal; | |
| those failures appear in the raw issue list but never roll up to a feature | |
| pass/fail. | |
| **Required:** every rule registered in foundations should declare the | |
| requirement(s) it enforces via `@register_requirements`, so issues are | |
| attributable. | |
| --- | |
| ## 6. `init_rules` defaults are inconsistent across consumers | |
| **Where:** `omni.asset_validator.ValidationEngine` constructor and the | |
| SimReady SDK's engine wrapper. | |
| **Observed:** `validate_yaskawa.py` (top-level reference) explicitly passes | |
| `init_rules=True` and notes that `simready_sdk.core.engine` passes | |
| `init_rules=False`, which leaves the engine empty: | |
| ``` | |
| The SDK passes init_rules=False which leaves the engine with no checks, | |
| producing 'No rules or requirements have been enabled.' for every asset. | |
| ``` | |
| With `init_rules=True` the engine has 124 rules / 118 requirements. With | |
| `False` it has 0 / 0. | |
| **Required:** make `init_rules=True` the default in the engine, or remove the | |
| parameter; update `simready_sdk.core.engine` to call it correctly. Today | |
| choosing the wrong path silently produces a "passes everything" report. | |
| --- | |
| ## 7. Foundation has the wrapper but ships no runnable thumbnail generator | |
| **Where:** `simready_foundations/nv_core/testing_tools/testing_framework/source/job_runner/core/engines/usdrecord/` | |
| plus lighting rigs at `simready_foundations/nv_core/common_tools/thumbnails/auto_thumbnail_indoor_lighting_rig_{small,medium,large}.usd`. | |
| **Observed:** the foundation defines `UsdRecordCommandBuilder` which builds | |
| the command `<usdrecord_exe> <asset.usd> <output.png>` and references three | |
| preset lighting USDs intended to be composed with the asset before rendering. | |
| But: | |
| - The `<usdrecord_exe>` is taken from `job.runner_config.executable`. The | |
| foundation does not bundle the binary, the venv does not have it, and | |
| `pxr.UsdAppUtils` (the Python library backing `usdrecord`) is absent. | |
| - The `auto_thumbnail_indoor_lighting_rig_*.usd` rigs have no documented | |
| composition recipe — there is no published "open the rig, payload the | |
| asset, render to 256×256" wrapper script. | |
| `usdrecord` is part of OpenUSD; on this machine it must be installed | |
| externally. Three working install paths (commands documented for the record; | |
| none are run automatically by the validator): | |
| 1. **Kit Kernel from NGC** (the user already has `ngc` on PATH): | |
| ```powershell | |
| $env:KIT_VERSION = "106.5.0" | |
| ngc registry resource download-version "nvidia/omniverse/kit:$env:KIT_VERSION" ` | |
| --dest "$env:USERPROFILE\.kit" | |
| # `usdrecord.bat` lives at <kit_root>\dev\tools\packman\repo\bld\target-deps\usd\release\bin\usdrecord.bat | |
| $env:USDRECORD_BIN = "$env:USERPROFILE\.kit\kit-$env:KIT_VERSION\...\usdrecord.bat" | |
| ``` | |
| 2. **OpenUSD prebuilt** (NVIDIA developer release): | |
| ```powershell | |
| # Download from https://developer.nvidia.com/usd (signed-in NGC link), | |
| # extract, and point to the binary: | |
| $env:USDRECORD_BIN = "C:\openusd\bin\usdrecord.cmd" | |
| ``` | |
| 3. **Build OpenUSD from source** (heaviest, only if the prebuilt isn't | |
| acceptable): | |
| ```powershell | |
| git clone https://github.com/PixarAnimationStudios/OpenUSD.git C:\src\OpenUSD | |
| python C:\src\OpenUSD\build_scripts\build_usd.py --tools C:\openusd | |
| $env:USDRECORD_BIN = "C:\openusd\bin\usdrecord.cmd" | |
| ``` | |
| Once `USDRECORD_BIN` is set (or the binary is on PATH), `validate.py`'s | |
| `_find_usdrecord()` will pick it up and the validator will invoke it for | |
| each asset missing a thumbnail at the spec path. Generated PNGs go to | |
| `report/<set>/_generated_thumbs/<filename>.png` — never into the | |
| packaged asset tree. Every command run is logged in `results.json` under | |
| `thumbnail_generation.attempts` and surfaced in the dashboard's "External | |
| tooling used" panel. | |
| For `yaskawa_local`, six of seven thumbnails were instead pulled from | |
| `Assets/Isaac/6.0/Isaac/Robots/Yaskawa/Motoman Next/.../.thumbs/256x256/` | |
| on the Omniverse content S3 bucket (free; no install required). One robot | |
| (`NHC10DE-A00`) has no S3 thumbnail; without `usdrecord` installed, its tile | |
| renders the inline SVG "no thumbnail" placeholder. | |
| **Required:** either ship `usdrecord` in the foundation's bundled toolchain, | |
| or distribute a foundation-side wrapper (e.g. a Kit ext that does | |
| `UsdAppUtils.framerec.FrameRecorder` programmatically) so `simready ingest | |
| usd` can produce the spec thumbnail without external installs. | |
| --- | |
| ## 8. Spec docs disagree on the thumbnail filename | |
| **Where:** | |
| - Spec doc: `nv_core/sr_specs/docs/capabilities/isaac_sim/robot_core/requirements/thumbnail-exist.md` | |
| - Validation rule: `nv_core/sr_specs/docs/capabilities/isaac_sim/robot_core/validation.py:213` | |
| - OEM publishing guide: `simready-oem-sdk-poc/docs/oem-publishing-guide-hf.md` | |
| **Observed:** | |
| - The spec doc's example uses `…/Robot_Name/.thumbs/256x256/Robot.png` | |
| (filename = USD stem only, no `.usd` suffix). | |
| - The rule code computes `…/<filename>.png` where `<filename>` is the full | |
| USD filename **including** the `.usd` extension, e.g. `nex4_c00.usd.png`. | |
| - The OEM publishing guide also uses `robot-a.usd.png` (with `.usd.`). | |
| - The Isaac S3 bucket uses `NEX4_C00.usd.png` (with `.usd.`). | |
| The rule and most published assets agree (`<filename>.png` with `.usd`); the | |
| spec doc's example is wrong. | |
| **Required:** fix the spec example in `thumbnail-exist.md` to match the rule. | |
| --- | |
| ## 9. `simready ingest usd` does not lift companion thumbnails | |
| **Where:** `simready-oem-sdk-poc/src/simready_sdk/packager/organizer.py`. | |
| **Observed:** `simready ingest usd ./robot/robot.usd` produces the spec | |
| layout (`<name>/<name>.usd`, `configuration/`, `materials/`, | |
| `.thumbs/256x256/` folder) but **does not** copy/rename a thumbnail from any | |
| companion location into `.thumbs/256x256/<file>.usd.png`. The packager docs | |
| (`SKILL.md`) call it "thumbnail placeholder" — the directory is created | |
| empty. | |
| For `yaskawa_local/images/<stem>.usd.usd.png`, no automated path exists for | |
| the packager to know that file should land at the spec's thumbnail path. | |
| **Required:** the packager should accept a companion-images directory hint | |
| (e.g. `--thumbs-from <dir>` or a sibling `images/` convention) and lift | |
| matching files into `.thumbs/256x256/<file>.usd.png` during organize. | |
| --- | |
| ## 10. A foundation rule crashes with `'NoneType' object has no attribute 'JointStateAPI'` | |
| **Where:** somewhere in the `simready.foundation.core` plugin's joint-state | |
| checker (rule not yet pinned down — issue is reported as `code: UNKNOWN`, | |
| `rule: None`). | |
| **Observed:** the rule fires on every prim it visits and produces an | |
| *Uncaught error* issue, accounting for between **566 and 698 issues per | |
| asset** in our run — i.e., most of what makes the report look noisy: | |
| ``` | |
| UNKNOWN ×668 Uncaught error: 'NoneType' object has no attribute 'JointStateAPI' | |
| UNKNOWN ×566 Uncaught error: 'NoneType' object has no attribute 'JointStateAPI' | |
| UNKNOWN ×698 Uncaught error: 'NoneType' object has no attribute 'JointStateAPI' | |
| ``` | |
| The remaining ~150 issues per asset (HI.*, NP.*, RC.*, etc.) are the *real* | |
| findings. | |
| The crash strongly suggests the rule reads | |
| `stage.GetPrimAtPath(...).GetAPISchemas()`-style and assumes the result is | |
| non-`None`. A defensive `if foo is None: continue` would silence the noise; | |
| the underlying joint-state coverage is presumably what the rule was meant to | |
| be checking, but currently it produces nothing useful. | |
| **Required:** pin down the rule (grep `JointStateAPI` across | |
| `simready.foundation.core`), add the missing None-guard, and either register | |
| the rule's requirement properly or remove it from the engine until it works. | |
| --- | |
| ## 11. `NP.005` — layout mismatch between the rule's spec and `simready ingest usd`, plus a path-printing bug | |
| **Where:** | |
| - Rule code: `simready_foundations/nv_core/sr_specs/docs/capabilities/core/naming_paths/validation.py:271-320` (`AssetFolderStructureChecker`). | |
| - Rule spec doc: `simready_foundations/nv_core/sr_specs/docs/capabilities/core/naming_paths/requirements/asset-folder-structure.md`. | |
| - Packager output: `simready-oem-sdk-poc/src/simready_sdk/packager/organizer.py` (invoked via `simready ingest usd`). | |
| ### 11a. Layout mismatch | |
| The NP.005 spec doc requires this structure: | |
| ``` | |
| <asset>/ ← asset folder | |
| ├── <intermediate>/ ← exactly ONE intermediate folder (any name) | |
| │ └── <main>.usd ← main USD; NO other .usd files here or below | |
| └── materials/ ← supporting folders are SIBLINGS of <intermediate>/ | |
| ``` | |
| The reference dashboard's FANUC content follows this exactly: | |
| ``` | |
| robots/CR/cr_50f_16b/isaac_ready_usd/cr_50f_16b.usd.usd | |
| robots/CR/cr_50f_16b/configuration/... | |
| ``` | |
| But `simready ingest usd` produces a *flat* layout — main USD at the asset | |
| root, sublayers nested inside the same dir: | |
| ``` | |
| <asset>/ | |
| ├── <asset>.usd | |
| └── configuration/ | |
| ├── <asset>_base.usd | |
| ├── <asset>_physics.usd | |
| └── <asset>_sensor.usd | |
| ``` | |
| The rule walks `os.path.dirname(stage_path)` (which is `<asset>/` in the | |
| flat layout) and flags every sublayer as "stray". The sublayers aren't | |
| stray — they're the spec-required configuration files — but the rule's | |
| walk-set includes them because the packager produced an | |
| NP.005-non-compliant layout. | |
| So: **two foundation artifacts disagree on the canonical asset layout.** | |
| The packaging spec (`simready-packaging`'s SKILL.md) and `simready ingest | |
| usd` produce one layout; NP.005's spec doc and the FANUC reference content | |
| use a different layout. | |
| ### 11b. Path-printing bug (independent) | |
| ```python | |
| # capabilities/core/naming_paths/validation.py:308-313 | |
| for root, dirs, files in os.walk(current_dir): | |
| for file in files: | |
| found_file = os.path.join(root, file).replace("\\", "/") | |
| if file.endswith((".usd", ".usda")) and found_file != stage_path: | |
| relative_path = os.path.relpath(file, current_dir) # ← bug | |
| other_usd_files.append(relative_path) | |
| ``` | |
| `file` here is just the basename returned by `os.walk` (e.g. | |
| `nex10_c00_base.usd`). `os.path.relpath` resolves it against | |
| `os.getcwd()`, not against `root`. With CWD = | |
| `<workspace>/.claude/skills/simready-report/`, the rule prints: | |
| ``` | |
| ..\..\..\.claude\skills\simready-report\nex10_c00_base.usd | |
| ``` | |
| — a path back to the validator's CWD, where the file emphatically does not | |
| exist. Should be `os.path.relpath(found_file, current_dir)` (`found_file` | |
| is the correct joined path, already computed on the line above and | |
| otherwise unused). With that one-character fix the cited path becomes | |
| `configuration/nex10_c00_base.usd` — pointing at the real file. | |
| ### Required | |
| **Pick one canonical layout and reconcile both sides.** Either: | |
| - **Update the packager** (`simready ingest usd`) to emit the | |
| NP.005-compliant `<asset>/<intermediate>/<main>.usd` structure with | |
| `configuration/` and `materials/` as siblings of `<intermediate>/`. This | |
| is what the FANUC reference content already uses. The packaging skill | |
| doc and any consumers (manifest tooling, dashboard, etc.) need updating | |
| in lockstep. | |
| - **Or update NP.005's spec doc and rule** to bless the flat layout that | |
| `simready ingest usd` actually produces — i.e., explicitly whitelist the | |
| spec-mandated subdirectories (`configuration/`, `materials/`, | |
| `.thumbs/`, `.simready/`) when scanning for stray USDs. | |
| Whichever is chosen, fix the path-printing bug at the same time | |
| (`relpath(file, …)` → `relpath(found_file, …)`) so the message names a | |
| real on-disk path. | |
| --- | |
| ## 12. The "example" capability is active in production validation | |
| **Where:** | |
| `simready_foundations/nv_core/sr_specs/docs/capabilities/example/example.py`, | |
| codes `EX.01`, `EX.02`, `EX.03`. | |
| **Observed:** every asset fails: | |
| - `EX.01` — *"Stage has no mesh prims."* | |
| - `EX.03` — *"Test prim 'TestBlob' not found under default prim."* | |
| The source comment on this capability is literally `"example"` and the | |
| rule docs (`example.md`) describe it as a tutorial — `EX.03` requires a | |
| prim named `TestBlob` to exist as a child of the default prim. That's | |
| clearly not an asset requirement; it's pedagogical scaffolding to teach | |
| plugin authors how to register a rule. | |
| **Required:** unregister the `Example` capability from production rule | |
| loading (move it to test fixtures, gate it behind an env var, or delete it | |
| from the shipped plugin). Today every real asset takes 2–3 spurious EX | |
| failures. | |
| --- | |
| ## 13. `EX.01` and `VG.MESH.001` are duplicate checks under different codes | |
| **Where:** | |
| - `capabilities/example/example.py:52` — `EX.01`: *"Stage has no mesh prims."* | |
| - `capabilities/visualization/geometry/validation.py:836` — `VG.MESH.001`: | |
| *"Stage does not contain any meshes."* | |
| **Observed:** both fire on every asset, with effectively identical | |
| semantics. `EX.01` is the example/tutorial version; `VG.MESH.001` is the | |
| real version. Reporting both is noise. | |
| **Required:** when #12 is fixed, this disappears for free. Otherwise, | |
| `EX.01` should be retired and any consumer that still references it should | |
| be redirected to `VG.MESH.001`. | |
| --- | |
| ## 14. `HI.002` rejects valid USD xform-op decompositions | |
| **Where:** `capabilities/hierarchy/validation.py:62-104` | |
| (`ExclusiveXFormParentChecker`). | |
| **Observed:** ~14 issues per asset, message *"Prim Parent has no | |
| xformOp:rotate."* The rule requires every Gprim parent to author both | |
| `xformOp:translate` and (a substring-matching) `xformOp:rotate*`: | |
| ```python | |
| if not any("xformOp:rotate" in op.GetAttr().GetName() for op in xform_ops): | |
| self._AddFailedCheck("Prim Parent has no xformOp:rotate.", …) | |
| ``` | |
| That's an over-strict reading of USD. Valid alternatives the rule rejects: | |
| - `xformOp:transform` (single 4×4 matrix — encodes translate + rotate + | |
| scale together). | |
| - No xform ops at all (identity transform — also a valid stateless prim). | |
| - Any combination authored on an inherited parent and overridden by the | |
| Gprim's own ops. | |
| Yaskawa's robots author matrix transforms in many places, which is what | |
| trips this. The check should accept *any* xformable spec that resolves to a | |
| defined transform — likely via `Xformable.GetLocalTransformation()` | |
| returning a non-error result — rather than pattern-matching specific op | |
| names. | |
| **Required:** rewrite the check to validate *that the prim resolves to a | |
| defined transform*, not that it authored a particular op vocabulary. | |
| --- | |
| ## 15. `NP.001` flags the conventional `/Looks` scope as a naming violation | |
| **Where:** `capabilities/core/naming_paths/validation.py:125-160` | |
| (`PrimNamingConventionChecker`). | |
| **Observed:** every asset fails NP.001 ×8 with *"Prim 'Looks' does not | |
| follow consistent naming convention (camelCase or snake_case)."* | |
| `Looks` is the long-established USD convention for the materials scope | |
| under an asset's default prim — it's used by Pixar's published USD | |
| samples, NVIDIA's Isaac/Omniverse content, and most authoring tools | |
| (Houdini, Maya USD, Kit). The rule's `CAMEL_CASE_PATTERN` and | |
| `SNAKE_CASE_PATTERN` regexes don't accept the `Looks` PascalCase | |
| single-word, so it reports a violation on a name the broader USD ecosystem | |
| treats as canonical. | |
| **Required:** either whitelist the well-known USD scope names (`Looks`, | |
| `Geometry`, `Cameras`, `Lights`, `Animation`, `Render`, etc.) or accept | |
| PascalCase as a valid convention alongside camelCase / snake_case. | |
| --- | |
| ## 16. `VM.MDL.001` and `NP.008` double-report the same MDL resolution failure | |
| **Where:** | |
| - `capabilities/visualization/materials/...` (VM.MDL.001 — *"The path | |
| OmniPBR.mdl does not exist."*) | |
| - `capabilities/core/naming_paths/...` (NP.008 — *"Asset path 'OmniPBR.mdl' | |
| on attribute 'info:mdl:sourceAsset' at prim '/.../Looks/.../...' does not | |
| resolve to an existing file."*) | |
| **Observed:** every asset emits the same number of VM.MDL.001 and NP.008 | |
| issues (9 each on `nex10_c00`, 6 each on `nex20_c00`, etc.) — both rules | |
| fire on the same `info:mdl:sourceAsset = @OmniPBR.mdl@` attribute. NP.008 | |
| gives a useful prim path; VM.MDL.001 just says "doesn't exist". | |
| Separately: `OmniPBR.mdl` is a **standard NVIDIA MDL** that ships with Kit | |
| and Isaac. The validator's asset resolver doesn't know where to find it | |
| (likely missing an MDL search path in the SimReady plugin's resolver | |
| config), so a perfectly portable, NVIDIA-blessed material reference is | |
| flagged as broken on every asset. | |
| **Required:** | |
| 1. Configure the SimReady validator plugin to register Kit's standard MDL | |
| search paths (`mdl/`, `omni/mdl/`, etc.) so `OmniPBR.mdl` and other | |
| shipped MDLs resolve without the customer having to vendor them. | |
| 2. Pick one of VM.MDL.001 / NP.008 as the canonical "MDL doesn't resolve" | |
| code. Have the other defer when the first has fired against the same | |
| attribute. | |
| --- | |
| ## 17. `RC.002` flags spec-mandated robot metadata as "overrides" | |
| **Where:** `capabilities/isaac_sim/robot_core/...`, `RC.002`. | |
| **Observed:** every asset fails RC.002 with messages like: | |
| ``` | |
| Prim is overridden: /nex10_c00, ['isaac:description', 'isaac:license', | |
| 'isaac:namespace', 'isaac:robotType'] | |
| ``` | |
| `isaac:description`, `isaac:license`, `isaac:namespace`, | |
| `isaac:robotType` look like exactly the kind of metadata the SimReady | |
| robot spec wants you to author on the robot's default prim — but RC.002 | |
| is treating any authored override of the default prim's properties as a | |
| violation. | |
| If those four `isaac:*` attributes are spec-mandated, the rule should | |
| *require* them, not flag their presence. If they're optional metadata, the | |
| rule should ignore them — overriding metadata fields on the default prim | |
| is a normal authoring pattern, not a layout error. | |
| **Required:** clarify the spec around the `isaac:*` namespace on the | |
| robot default prim and update RC.002 to either require those fields, or | |
| exclude them from the "this prim shouldn't be overridden" check, or split | |
| into two rules (one for "structural" overrides, one for the spec | |
| metadata). | |
| --- | |
| ## Summary | |
| | # | Severity | Area | One-line | | |
| |---|---|---|---| | |
| | 1 | high | profile schema | `Profile.capabilities` is dead; should be removed or populated | | |
| | 2 | high | engine API | `enable_*`/`disable_*` don't actually scope rule execution | | |
| | 3 | high | profile content | Robot-Body-Isaac v1.0.0 silently drops 4 of 6 declared features | | |
| | 4 | high | profile schema | JSON capability configs aren't linked to the Python profile registry | | |
| | 5 | high | rule registration | Most rules don't declare `@register_requirements` → 87% UNKNOWN | | |
| | 6 | medium | engine API | `init_rules` defaults inconsistent; SDK silently turns off all checks | | |
| | 7 | medium | tooling | No headless thumbnail generator ships with foundations | | |
| | 8 | low | spec docs | `thumbnail-exist.md` example contradicts the actual rule | | |
| | 9 | medium | packaging | `simready ingest usd` doesn't lift companion thumbnails into spec layout | | |
| | 10 | high | rule reliability | Rule crashes on `JointStateAPI` access → ~600 UNKNOWN issues per asset | | |
| | 11 | high | spec/packager mismatch | NP.005 expects `<asset>/<intermediate>/<main>.usd`; packager produces flat layout. Plus `relpath(file,…)` should be `relpath(found_file,…)` | | |
| | 12 | high | rule scoping | "Example" tutorial capability (`EX.*`) is active in production validation | | |
| | 13 | medium | rule duplication | `EX.01` and `VG.MESH.001` are the same check | | |
| | 14 | high | rule correctness | `HI.002` rejects matrix transforms (`xformOp:transform`) and identity transforms | | |
| | 15 | medium | rule correctness | `NP.001` rejects the conventional `/Looks` scope name | | |
| | 16 | high | rule correctness | `OmniPBR.mdl` (standard NVIDIA MDL) doesn't resolve; both VM.MDL.001 and NP.008 fire on the same attribute | | |
| | 17 | medium | spec ambiguity | `RC.002` flags spec-looking `isaac:*` metadata as illegal "overrides" | | |