feat(smitebot): add working doctor command (checks + --json + docs)

[Ashish-Kumar-Dash]

Summary

This PR introduces the first working smitebot command: doctor.

It adds smitebot crate and implements prerequisite checks needed before running Smite campaigns, with both human and machine readable(JSON) output.

What’s included

• Add smitebot as a workspace member.
• Add smitebot crate dependencies (clap, serde, serde_json, thiserror).
• Implement smitebot doctor command (no stub-only command surface).
• Implement --json output for CI/machine parsing.
• Return non-zero exit code when any check fails.
• Add focused unit tests for report logic/path helpers/JSON shape.
• Add concise README docs, including install + direct smitebot doctor usage.

Checks implemented

• x86_64 architecture
• /dev/kvm accessible
• Docker daemon reachable (docker info)
• AFL++ tools on PATH:
  • afl-fuzz
  • afl-cmin
  • afl-tmin
  • afl-whatsup
• Nyx packer hget presence
• libnyx.so discoverable via LD_LIBRARY_PATH
• VMware backdoor enabled
• Required Smite scripts exist and are executable

Validation

cargo fmt --all --check
cargo clippy -p smitebot --all-targets -- -D warnings
cargo test -p smitebot
cargo run -p smitebot -- doctor
cargo run -p smitebot -- doctor --json

ping @morehouse @NishantBansal2003

[Ashish-Kumar-Dash]

made the required changes after the review & squashed the commits to a single one

[NishantBansal2003]

Just skimming through the changes (haven’t reviewed them deeply yet) but one main comment I wanted to add is that the code lacks Rust docs for each function, as well as some inline comments.

Also, I think the implementation could be simplified quite a bit and made more readable by following more idiomatic Rust patterns. Right now, I see quite a bit of redundancy in the code, such as repeated if/else patterns, duplicated check names like "Docker daemon reachable" etc etc.
I also think using proper error types would be better than returning strings explicitly.

You can also check https://github.com/dergoegge/fuzzamoto/tree/master/fuzzamoto-cli for some project/code structure ideas.

[Ashish-Kumar-Dash]

Refactored doctor so failed checks use typed CheckFailure variants instead of strings, which makes the code easier to extend and unrepetitive while keeping the same output, also cleaned up the command flow, added docs for each func, fixed ~ handling for --aflpp-path, made libnyx use the resolved AFL++ root, and switched to the faster docker version check.
Also, I feel main.rs does not need to be perfect at this stage, I’m keeping it clean enough for the first working command, and we can keep reshaping the structure as more commands land and better abstractions are spotted. Just my thoughts, since it might get messy as more commands keep adding

[NishantBansal2003]

I haven't reviewed the tests yet, but I think we can add more unit tests. I know there are some cases we can't test, but wherever possible, it would be great to add them, for example, tests for helper functions, error cases, and error display as well (since that is the most user visible part)

[Ashish-Kumar-Dash]

Refactored doctor so each check now returns Result<(), CheckFailure>, and DoctorCheck::new(...) turns that into report output. This keeps the check logic cleaner, & avoids repeated pass/fail boilerplate.

Also moved repeated tool/script/dockerfile lists into constants and added more helper/error-display tests(now 11)

[NishantBansal2003]

Some more comments (feel free to ignore some nits if you disagree)

I still think the test module can be improved. Also, could you add inline comments in the tests wherever some workaround is used to achieve a particular check case? I think that would make it easier to understand what is being done and why.

[Ashish-Kumar-Dash]

ping @NishantBansal2003 , I split smitebot into a more modular CLI layout like the fuzzamoto CLI: main.rs is now just clap wiring, the doctor logic lives in commands/doctor.rs, and shared helpers moved into utils/. It will keep PRs smaller and the command implementations isolated.

[NishantBansal2003]

I think once these comments are addressed (in a fixup), this PR will be ready for Matt’s review

[NishantBansal2003]

I think this is ready for @morehouse review:

Some points I would like to discuss are:

• Currently, aflpp_path is optional and defaults to $PATH. Since we explicitly pass the AFL++ path during fuzzing, I think we should make it explicit here as well instead of implicitly taking it from $PATH
• I couldn’t find anywhere that libnyx.so is used via LD_LIBRARY_PATH. From a high-level view of the AFL++ code, I only see libnyx.so being resolved via $AFL_PATH/libnyx.so, so I don’t think checking via LD_LIBRARY_PATH adds much value. I may be wrong though, so could you point me to the place that checks for libnyx.so via LD_LIBRARY_PATH?
• If we default to using $PATH for aflpp_path, then I think check_libnyx will be incorrect. For a system-installed AFL++, afl-fuzz would typically be in /usr/local/bin/, while libnyx.so would be in /usr/local/lib (or similar), so this check would always fail (I think the same issue will happen with check_nyx_hget as well)

[Ashish-Kumar-Dash]

• Currently, aflpp_path is optional and defaults to $PATH. Since we explicitly pass the AFL++ path during fuzzing, I think we should make it explicit here as well instead of implicitly taking it from $PATH
• If we default to using $PATH for aflpp_path, then I think check_libnyx will be incorrect. For a system-installed AFL++, afl-fuzz would typically be in /usr/local/bin/, while libnyx.so would be in /usr/local/lib (or similar), so this check would always fail (I think the same issue will happen with check_nyx_hget as well)

agreed, AFL++ tools, Nyx hget, and libnyx.so are now validated only under the explicit --aflpp-path. PATH is still used only for host tools like docker,python,bash

• I couldn’t find anywhere that libnyx.so is used via LD_LIBRARY_PATH. From a high-level view of the AFL++ code, I only see libnyx.so being resolved via $AFL_PATH/libnyx.so, so I don’t think checking via LD_LIBRARY_PATH adds much value. I may be wrong though, so could you point me to the place that checks for libnyx.so via LD_LIBRARY_PATH?

That LD_LIBRARY_PATH check came from my prev assumption that libnyx.so might be loaded through the dynamic linker search path. After going through the repo again, I couldn’t find a Smite dependency on LD_LIBRARY_PATH for libnyx.so, and your point about AFL++ resolving it via AFL_PATH makes sense. I’ve removed that check and now validate libnyx.so only under the explicit --aflpp-path.

[Ashish-Kumar-Dash]

Once you approve these changes, I'll go ahead with asking for Matt's review

[Ashish-Kumar-Dash]

@morehouse you may take a look, I think the PR is ready to be reviewed