build-inspector

The Surveyor's Field Guide

"The map is not the territory. What you see as Cargo.toml may be only the tip of the iceberg." — Old Surveyor's Maxim

Static analysis looks atcode structure, while this skill looks atengineering scaffolding— the rules that determine "how software turns from source code into an executable."

---

⚠️ Mandatory Deep Thinking

[!IMPORTANT] Before performing any analysis, youmustcall the sequential thinking tool and, as appropriate, perform 2-3 stepsof reasoning. Examples of thinking content:

1. "What build system does this project use? (Cargo? npm? Make?)"
2. "Do I see multiple build configuration files? Are they independent or managed uniformly?"
3. "Are the final artifacts (exe, dll, bundle) released together? Or can they be updated independently?"

---

⚡ Task Objective

IdentifyBuild Boundaries。

Old Master's Core Law: If two things are built separately, any "interface" between them is a ticking time bomb—because what can happen isVersion Skew。

---

🧭 Exploration Process (The Expedition)

Step One: Locate Base Camps

• Command: find_by_name(pattern="Cargo.toml|package.json|go.mod|pom.xml|build.gradle|requirements.txt|CMakeLists.txt")
• Surveyor's Intuition: Each build configuration = a "camp." Multiple camps = potential splinter forces.

Step Two: Check for Unified Command

If you find multiple camps, youmustanswer:

Ecosystem	Check Item	Old Master's Verdict
Rust	Does the root Cargo.toml have [workspace] ? Are all members listed in it?	No -> 🔴 Independent Kingdom
Node	Does the root package.json have the workspaces field? Or does it use Lerna/Nx/Turborepo?	No -> 🔴 Independent Kingdom
Go	Does it use go.work for orchestration?	No -> 🟡 Further confirmation needed

• Old Master's Alerts (from industry cases):
  • ⚠️ Independent Kingdom (Polyrepo Hell): They can each upgrade versions independently, with no guarantee of compatibility! This very easily produces "Dependency Chaos."
  • ⚠️ Pseudo Monorepo (Distributed Monolith): Although in the same repository, the builds are independent, so in practice the risk is the same as Polyrepo!
  • ⚠️ Sidecar/External Binary: Is it packaged and deployed together with the main program? Is the CI pipeline the same one?If the Sidecar can be updated independently, there must be a version handshake!

Step Three: Identify Artifacts

• Read the build configuration and infer the final binary/library:
  • [[bin]] in Cargo.toml -> executable file.
  • "bin" in package.json -> CLI tool.
  • cmd/ directory in a Go project -> multiple command-line tools.
  • tauri.conf.json -> Tauri desktop application (check externalBin Is there a Sidecar).
• Veteran's must-ask questions:
  • "Do these artifacts ultimately run on the same machine?"
  • "Are they produced bythe same CI pipeline、the same version number?"
  • "Can users update only one of the artifacts?"

---

🛡️ Risk Label System (from industry research)

Pattern	Level	Veteran's advice
Single Workspace	🟢	Version consistency is guaranteed.
Multiple Roots + Shared Workspace	🟢	Check whether all members are within the workspace.
Multiple Roots + No Workspace (Polyrepo)	🔴	Split-Brain. Highly prone to version drift. Dependency versions across different repositories may conflict.
Sidecar + Atomic Release	🟢	Sidecar and the main program are updated together; risk is manageable.
Sidecar + Non-Atomic Release	🔴	High risk! Version handshaking must be implemented at the IPC layer.

---

📤 Output Checklist

1. Build Roots: List of discovered build configuration paths.
2. Topology: [Monolith / Workspace / Polyrepo / Distributed-Local]
3. Artifacts: List of identified final artifacts (name, type, source).
4. Sidecar Warning: If a Sidecar exists, specify its release strategy (atomic/non-atomic).
5. Risks Flagged: Flagged risks and their rationale.In particular, note "which two artifacts may have unsynchronized versions"。