add thoughts on getting to v2 e2e running

databuild/databuild.proto

@@ -217,7 +217,7 @@ message PartitionStatus {
   string name = 2;
 }
 enum PartitionStatusCode {
-  // TODO how do we avoid copying job states here?
+  // TODO how do we avoid copying job states here? This is essentially a union of job states and taints?
   PartitionUnknown = 0;
   PartitionWanted = 1;
   PartitionBuilding = 2;

docs/impl_notes/2025-11-19_running-jobs.md

@@ -0,0 +1,17 @@
+
+We've gotten to a place where the orchestrator reacts to wants, runs jobs, and turns dep misses into other wants, which in theory is all we need from it to get to v2. So, what do we need around that?
+
+- Job configuration
+- Want submission - more generally, the API
+
+How do those break down into work items?
+
+### Job Configuration
+The databuild binary should accept a runtime config that points to a job config file, or just provides it directly, which populates the [`JobConfigurations`](databuild/orchestrator.rs:99). This should be fairly straightforward, and can probably just be deserialization of the read string via [the protobuf struct](databuild/databuild.proto:8).
+
+### API
+We have the (beginnings of) API endpoints described in protobuf structs ([starting here](databuild/databuild.proto:174)). We just need to build an API server around it, and a CLI that can talk to the API. This would break down into the following layers:
+
+- Build state accessor functions - transact via the protobuf structs
+- API - exposes build state accessor functions via HTTP
+- CLI - Talks to API, formats requests/responses, is able to start API server for databuild workspace