Testing with POSIX tools

Provider tests need two levels: code checks and filesystem behavior.

Compile the provider

The repo-level provider gate is:

just providers-check

That gate sets up the WASI environment, runs provider clippy, and checks provider test compilation. The underlying checks look like:

cargo check -p omnifs-provider-db --target wasm32-wasip2
cargo clippy -p 'omnifs-provider-*' -p 'omnifs-tool-*' -p test-provider --target wasm32-wasip2 -- -D warnings
cargo test -p omnifs-provider-db --target wasm32-wasip2 --no-run

WASM provider tests can compile on the host test harness, but they do not execute unless a WASM runtime is involved. Use --no-run for target-specific provider compilation checks.

Run the dev runtime

From the omnifs source checkout:

omnifs dev -y
omnifs status
omnifs shell

omnifs dev builds the dev image, wires provider manifests from the source checkout, materializes contributor fixtures and credentials, and starts the runtime with workspace providers mounted under /omnifs.

Exercise the tree

Test the whole traversal path, not only the final file:

ls /omnifs
find /omnifs/dns -maxdepth 2 -type f | head
cat /omnifs/dns/example.com/MX
cat /omnifs/docker/system/version.json | jq .
cat /omnifs/db/tables/Album/schema.sql

For provider path changes, check each intermediate directory. Literal route prefixes should be navigable. Dynamic captures should not accidentally shadow static control directories.

Use ordinary tools

A provider should behave like files for common tools:

ls -l /omnifs/github/0xff-ai/omnifs/issues/open
cat /omnifs/arxiv/papers/1706.03762/paper.json | jq .
grep -R "bug" /omnifs/linear/teams/ENG/issues/open
find /omnifs/docker/containers -maxdepth 3 -type f

The goal is not to prove every API endpoint. The goal is to prove the filesystem surface is coherent.

Debug failures

Use:

omnifs logs -f
omnifs inspect --plain
omnifs status --detail

Look for failed callouts, denied capabilities, stale cache writes, missing credentials, and route capture parse failures.