document what is needed for this to be a statically verified sandbox

Would adding a section to the Readme about this be welcome?

Together with static analysis, I think cap-std can be used to reduce the necessary code review to know that something does not escape the capabilities handed to it. So one would only need to review the API that one uses from a crate.

For this one would need some tool(s) one could run on a crate (and recursively its dependencies) to verify that it does not use any of the following:

* [cap-directories](https://github.com/bytecodealliance/cap-std/blob/main/cap-directories/README.md)
* [Dir::open_ambient_dir](https://docs.rs/cap-std/latest/cap_std/fs/struct.Dir.html#method.open_ambient_dir)
* the replaced functions/modules/crates (typical clippy job, but probably no ready made lint yet, can clippy guarantee this or is something else needed?)
* unsafe (there is `#![deny(unsafe_code)]` https://doc.rust-lang.org/reference/attributes/diagnostics.html , I think there are ready made tools, need to find a good recommendation)
* build script https://doc.rust-lang.org/cargo/reference/build-scripts.html (no idea if there is a ready to use tool to check, but easy to code)
* check known unsoundness like https://github.com/rust-lang/rust/issues/25860 are not used, I think miri https://github.com/rust-lang/miri is supposed to catch it, but need to double check

Any suggestions for relevant tools?

While there is research in that direction, for now none of this is to the level of formally proven, but the constructed to be correct level known from Rust.

先从仓库的 README 和链接的 cap-directories/README.md 开始，然后调查列出的 Rust 工具和检查项，了解其依赖项、不安全代码、环境目录访问、构建脚本以及已知的不健全性。完成的标准是：README 中有一个章节记录适用的工具、它们的限制，以及对于静态验证的沙箱可以验证和无法验证的内容。

由索引模型根据 Issue 内容生成。