P07 — Runtime Resource Isolation

Problem

Separate files do not stop two Runs from binding the same port, reusing a database namespace, or terminating each other’s processes.

Context

Runs start local servers, test databases, browsers, or background services. The interactive driver remains at the workspace control-repository root while each bounded Run owns resources associated with its isolated managed-repo worktree.

Pattern

Model runtime dependencies as Resources. Allocate them before use, record ownership, observe health, and release or reconcile them after the Run.

Diagram

Run → request resource → allocator → owned port/process/service
                                  ↓
                              release / reconcile

Example

Run A → port 4311
Run B → port 4312
Run end → stop process → release port

The reference CLI records these resources under .workspace/runtime/, which is ignored by the control repository. ws status exposes active ownership and ws cleanup reconciles completed or orphaned Run resources. This narrow Run resource reconciliation is not Runtime Workspace reconciliation or deployed service management.

Trade-offs

Explicit allocation reduces collisions. Best-effort local allocation can still race or leak; stronger providers are more expensive.

Failure modes

Orphan processes survive a failed Run, a port is assumed free without checking, or a service is shared without a compatibility contract.

Extension points

Use containers, namespaces, ephemeral databases, a daemon, or a remote scheduler.

When not to use

Read-only Runs with no runtime dependencies do not need a resource allocator.