Run the BVH path from an installed product, and fix what that found

[snkmcb]

Closes the v0.8.0 carried item "The profiles reach the product; the smoke that would prove it does not exist" — and the smoke found a defect on its first run.

What was open

WORKSPACE.md §5 ships the motion profiles as product data for one stated reason: a converter with no profile available refuses every file it is given, which would make an artifact-only smoke test of the BVH path impossible to pass. That has been a requirement without a test since v0.7.0. ost 0.22.3 supplied the missing mechanism ([[workspace.install_data]], data_files: 3), and report 36 §4 said in as many words that the staging was what had been proven and not the run.

The defect

The profiles installed byte-identically to share/usd-vrm-plugins/profiles/motion/ and the converter refused the capture anyway:

motion_bvh_convert: no profile 'mocopi-mobile-bvh-default-v1' was found.
Looked for 'mocopi-mobile-bvh-default-v1.yaml' in:
  <prefix>/tools/motion_bvh/share/usd-vrm-plugins/profiles/motion
  <prefix>/profiles/motion

ost plugin product install lands a tool member at <prefix>/tools/<member>/bin/ while the product's own data goes to <prefix>/share/. The locator's installed-prefix rule was <exe>/../share/… — correct for a cmake --install prefix and for a member archive unpacked on its own, one directory too shallow for the product. §5's line "the layout was agreed and only the staging was missing" was true of a member archive, which is the layout that measurement was taken on.

Two installed layouts put the data in the same place relative to the prefix and the tool at different depths inside it, so one executable-relative rule can only ever serve one of them. The locator now carries both.

The destination never moved. It is stated in openstrata.toml, the root CMakeLists.txt, WORKSPACE.md §5 and ProfileLocator.h; all four agree, and one of them was describing a different prefix. That is the argument for the smoke rather than for more review.

What the smoke does

scripts/artifact_only_bvh_smoke.py:

ost plugin package --workspace --product   -> the product dist
ost plugin product verify  <dist>          -> archive + every member checksum
ost plugin product install <dist> --prefix -> a fresh prefix outside the repo
<prefix>/tools/motion_bvh/bin/motion_bvh_convert <bvh> --profile <id>

What makes it artifact-only rather than another way of running the tool:

• the prefix is created outside the repository and the script refuses one inside it;
• --profile-dir is never passed and USDVRM_MOTION_PROFILE_PATH is removed from the environment;
• the only environment the run gets is what ost env prints plus the activation the product declares in its own openstrata.activation.json — which is what the install contract tells a consumer to use.

Two checks are worth naming:

• every shipped profile is compared byte for byte against profiles/motion/, because the failure that shape replaces was a copy that had stopped being the file scripts/check_motion_profiles.py validates (report 35 §4);
• after the conversion succeeds the installed profile is moved aside and the same command is re-run, which must now refuse — so "the tool found a profile" cannot pass for "the tool found the one this product ships".

Evidence

before the fix	exit 1 against the committed 0.7.0 product artifact, on the refusal above — a negative verification against a real artifact rather than a stash
after the fix	PASS: 853 frames at 50 Hz, 22 of 27 joints bound, from the prefix alone
ctest	108/108
checks	check_docs.py, check_motion_profiles.py, verify_corpus.py green

What is not claimed

Measured on a Windows workstation only. The smoke is a release.yml step, beside the clean-install smoke and against the archive that lane just proved digest-reproducible — so it inherits that lane's standing caveat: no pull request event runs it, and the first Linux and macOS runs happen at a tag. current.md's Before the tag list now carries a line for exactly that.

Also in here

• The v0.7.0 condition both paths running from release artifacts alone, profiles included moves to in-progress rather than done: the recorded path runs, the live path still needs the product composed with mocopi_record's own artifact.
• RELEASE_NOTES_TEMPLATE.md said "No member carries data" and told a reader to pass --profile a path. Stale since ost 0.22.3 and now wrong for the product; the template separates the product route from the member-archive route, which still needs the flag.

Commits

1. Run the BVH path from an installed product, which refuses every file — the smoke and its lane step, red at this commit by construction.
2. Find the profile a product installs beside the tool that needs it — the locator.
3. Record what the artifact-only run measured, and where it has not run — the documents.

🤖 Generated with Claude Code