The credential is the first boundary
Every worker authenticates with its own revocable credential bound to one workspace. The backend verifies that binding during the WebSocket upgrade, before registration or assignment. There is no pool-wide secret that turns any worker into global capacity.
Registration adds capability and lifecycle information, but it does not widen authority. A worker can only be considered for work in its credential's workspace.
Pending is a valid operational state
A BernOps-native run is stored before dispatch. If no eligible worker is ready, all matching workers are busy, or a concurrency scope is full, the run remains pending. That state makes capacity pressure visible instead of converting it into an immediate execution error.
Older pending work is considered first, while work blocked by one scope need not prevent eligible work in another scope from moving.
Limits are not replicas
Workspace, project, and job limits cap simultaneous execution. A limit of five does not create five workers, reserve five slots, or start a container. Operators still provision actual processes and decide their host, network, and isolation model.
What remains deliberately explicit
Live worker tracking and dispatch locks currently belong to one active backend scheduler. BernOps does not describe that as distributed scheduling, autoscaling, or exactly-once external execution. Accurate boundaries are part of the control plane: teams can engineer around a known constraint, but not around an implied guarantee.