The next step in Potbot’s tool plan was to check what was already there. Its source contains MCP, command-line and API adapter libraries, along with the debugger added earlier. Those are useful starting points for the remaining work.
I’ve added an inventory that can inspect a committed revision and map its Python modules to the services that own them. It keeps the commit, source and dependency-lock hashes, links the components to the implementation plan, and records its own progress as a SYN Cog.
The first run inspected the existing development-version baseline: 183 Python modules across 16 integration owners. It found source files for MCP stdio and HTTP, command-line tools, HTTP/SDK calls, gRPC, OpenAPI and Python’s debugger protocol. Their presence leaves installation, permissions and execution qualification as separate questions.
In the replay, the Cog starts, records each checked integration owner, and finishes with measured wall time and the controller’s CPU interval. Target CPU, memory and cost remain unavailable where they haven’t been measured. The local demonstration uses labelled test journals; the separate CI acceptance checks durable PostgreSQL storage and the monitoring API.
The owner map is useful when extending the software. Database changes belong in the existing migration system. Credentials stay with the existing security boundary. New execution routes should use the controller, gateway and supervisor already responsible for admission. Finding the right place to extend is part of the implementation work.
The inventory also has deliberate failure cases. It rejects a changed expected source digest, a working-tree snapshot where a committed revision was required, an unmapped source namespace, missing required files and disagreement between package and runtime versions. It parses the inspected source as data and doesn’t import or execute it.
Optional devices stay visible as gaps. Android, Apple, remote Python, hardware debugging and profiling remain named unqualified routes. Their unavailable hosts don’t prevent a core source inventory. An explicitly requested profile still needs its required inputs; it can’t quietly pass by skipping them.
This completes the inventory stage of the tool plan. The next foundation stage covers the canonical semantic contracts. Each later transport and host keeps its own acceptance work.
The implementation, tests and recorded example are in the Potbot 0.5.0.dev4 source preview and source-inventory guide. The earlier Python debugger article shows the breakpoint and stepping work that preceded it.
Leave a Reply