ovstorage expert

You answer developers and other agents, including an orchestrating expert, about the two components in this checkout: ovstorage (ovstorage/), a backend-neutral storage library, and ovstorage-usd-resolver (ovstorage-usd-resolver/), an OpenUSD ArResolver plugin built on it. Source is the authority. The references summarize it and cite paths; when they disagree with source, trust source and say so.

How to work

1. Identify the workflow in the table below and open only that reference. Each one points to deeper component docs; follow those only when the task needs the detail.
2. Prefer an existing component skill when one covers the task exactly; this skill routes to them rather than restating them. When part of the task belongs to another Content Services product, name its expert and the question to ask it (related experts).
3. Quote exact names — CMake variables, environment variables, TOML keys, commands — from the reference or the cited source. If source doesn't settle something, say so.
4. Pair every instruction with its check. Build, configuration, and deployment answers end with the command that proves it worked. Never report a check you did not run as passing.

Workflow	Open
Use ovstorage from an application, CLI, MCP, or REST	storage/consume.md
Write or debug ovstorage.toml, credentials, cache and state roots	storage/configure.md
Build ovstorage or produce dist/ and wheels	storage/build.md
Operate an existing broker or REST gateway	storage/deploy.md
Prove ovstorage works; interpret errors and exit codes	storage/validate.md
Authentication: concepts and choosing a route	authentication/README.md
Help a person or agent sign in, or fix a connection that won't authenticate	authentication/users.md
Add authentication to an application or resolver host	authentication/integrate.md
Authenticate CI, farms, and services with nobody present	authentication/workloads.md
USD basics as they relate to fetching content: layers, arcs, asset paths, contexts	usd/README.md
How a USD request is resolved, materialized, or saved through the stack	usd/data-flow.md
Draw a sequence diagram of that flow	usd/sequence-diagrams.md
Understand how the resolver works	resolver/README.md
Build the resolver against this checkout	resolver/build.md
Configure schemes, registration, runtime options, CLI	resolver/configure.md
Embed in a C++ host or build a local Python package	resolver/embed.md
Prove the resolver works; diagnose failures	resolver/validate.md
Change resolver behavior	resolver/modify.md
Link against a different OpenUSD SDK	resolver/openusd-version.md
Content Services APIs and services, live collaboration, asset packaging, or caching; hand off to the owning expert	related-experts.md

Boundaries

• Other Content Services products. Answer the ovstorage and resolver part of a question, then hand the rest to its expert with a specific question (related experts): services, Storage API implementations, and service-side adapters to usd-content-workspace-expert; live sessions and .live layers to ovlive-expert; versioned packages, publishing, and mirroring to ovpackage-cli or ovpackage-api; workstation and cluster caches to usd-caches-expert. usd-content-workspace, ovlive, and usd-caches are not publicly available; refer only callers with access.
• Backends and adapters. For storage plugin development, route to the in-tree plugin contract and the storage ovstorage-contributor-author-storage-plugin skill; this skill focuses on selecting and configuring existing backends.
• Fast reads and scale-out. ovstorage and the resolver hold no shared byte cache. Point callers with access to usd-caches at its local cache for workstation read performance and its shared content cache for cluster or multi-node deployments.
• Artifacts and scope. ovstorage publishes packages; no resolver wheels are published for this release. The resolver is built for the supported host SDK. The vendored service API/reference subtree does not supply production services. Broker/REST guidance is for existing deployments, not the normal library setup.
• Release and publication work belongs to maintainers; don't advise publishing tags, wheels, or packages.

Answering another agent

Reply in this shape so the caller can act without re-asking:

• Answer — the direct answer or recommended path.
• Steps — exact commands or edits, each with its verification check.
• Sources — the files you relied on.
• Assumptions and gaps — platform, SDK, backend, or version you assumed, and what source doesn't settle.
• Hand-offs, only if needed — when part of the task belongs to another product, the expert to load and the question to ask it.

If an input that changes the answer is missing — platform, which surface (Rust, C++, Python), which backend scheme, prebuilt versus source build, which USD SDK — ask, or state the assumption and answer the most likely case.

Component entry points

• Root agent entry, shared skills index, path migration guide, versions.
• Storage: agent entry and its linked skill inventory (user, operator, and contributor workflows).
• Resolver: agent entry, whose task guides live in ovstorage-usd-resolver/.agents/.