runtime-inspector

The Wiretapper's Casebook

"Code lies, but processes don't. A .spawn() exposes more than a thousand lines of comments." — Old Wiretapper's Proverb

This skill's job is totrace the communication lines between processes。

Old Master's Core Law: If two processes talk, but nobody specifies what language, what version, or what format they speak, then it's aProtocol Mismatch disaster waiting to happen.

---

⚠️ Mandatory Deep Thinking

[!IMPORTANT] Before performing any analysis, youmustcall the sequential thinking tool, and as appropriate perform 3—5 stepsof reasoning. Example thought content:

1. "How many entry points does this project have (main functions)? Are they one process or multiple?"
2. "What do the processes use to communicate? Pipe? HTTP? Shared database?"
3. "If I only update process A's communication module, will process B crash? Is there version handshaking?"

---

⚡ Task Objective

IdentifyRuntime Boundaries and Communication Contracts。

---

🧭 The Investigation

Step One: Identify Entry Points

Each main function may represent an independent process.

• Search targets:
  • Rust: fn main(), #[tokio::main]
  • Python: if __name__ == "__main__":
  • Node: require.main === module, package.json's bin
  • Go: func main()
• Old Master's Intuition: Found multiple entry points? Immediately ask: "Do they run independently, or are they managed by a parent process?"

Step Two: Trace Spawning

If process A spawns process B, that's a "bloodline".

• Search targets:
  • Rust: Command::new(...), std::process::Stdio, tauri-plugin-shell
  • Python: subprocess.Popen, multiprocessing.Process
  • Node: child_process.spawn, child_process.fork
• Old Master's Alarm (Lifecycle Risks):
  • ⚠️ "The parent process died, does the child process know? Is there a heartbeat?" -> Zombie Child risk
  • ⚠️ "The child process crashed, will the parent process restart it? Or does it fail silently?" -> Silent failure risk

Step Three: Tap the Wire

What do the processes use to "talk"? Where is the protocol defined?

• Search Channels:

  • Pipe, NamedPipe, unix_stream, zmq
  • TcpListener, UdpSocket, websocket, http::server

• Search Protocols:

  • Handshake, Version, MagicBytes, schema
  • protobuf, serde_json, JSON.parse, enum Message

• Old Master's Core Judgment (Contract Status):

  Found	Status	Old Master's Advice
  Found Channel + found enum Message or Protobuf definition	🟢 Strong	Contract exists, relatively safe.
  Found Channel + found Version or Handshake check	🟢 Strong	Version negotiation present, very good.
  Found Channel + only raw JSON/strings	🟡 Weak	No explicit contract. Changing one end may blow up the other end.
  Found Channel + no protocol definition whatsoever	🔴 None	Communication black hole! This is a high-risk issue.

---

🛡️ IPC Risk Pattern Quick Reference (from security research)

Risk Pattern	Detection Characteristics	Veteran Advice
Protocol Mismatch	Channel exists, but no Handshake/Version	In new feature planningEnforce adding a version handshake task
Zombie Child	spawn exists, but no Kill on Drop or heartbeat	Flag process lifecycle management risks
Single Point of Failure (SPOF)	One process controls all IPC, with no fault tolerance	Recommend adding reconnect/restart logic
Named Pipe Permission Vulnerability (Windows)	Uses Named Pipe but does not explicitly set Security Descriptor	🔴 High risk: by default may allow Everyone access!
Race Condition	Multiple processes interact rapidly, with no explicit message ordering control	Recommend adding message sequence numbers or a locking mechanism

---

📤 Output Checklist

1. Process Roots: List of discovered entry points (file paths, roles).
2. Spawning Chains: Process spawn relationships (A spawns B).
3. IPC Surfaces: Discovered communication channels (type, keywords, location).
4. Contract Status: [Strong / Weak / None], and explain the basis.
5. Lifecycle Risks: Risks such as zombie processes, silent crashes, etc.
6. Security Flags (Windows): If it is a Named Pipe, is ACL configured?