Problem
Workflow contract specifies `concurrency: 2`. Two valid readings exist:
- (a) max 2 active workers per stage at any moment
- (b) max 2 entities at `status={stage}` at any moment
These behave very differently in practice. Reading (b) blocks entity advancement when entities have completed plan but are waiting for an impl slot — the plan-done entity occupies a "plan slot" until its impl worker completes. Reading (a) allows flow, treating the slot as "currently busy worker", not "entity-at-status".
I drifted between both readings during a long sprint and only settled on (a) by experiment.
Proposal
The shared first-officer core should be explicit about which interpretation is canonical, with a one-paragraph example showing what happens when an entity completes its plan-stage stage report and is held queued.
Scale context
- Spacedock version: 0.11.2
- Sprint with 14 entities across a 4-stage workflow
Problem
Workflow contract specifies `concurrency: 2`. Two valid readings exist:
These behave very differently in practice. Reading (b) blocks entity advancement when entities have completed plan but are waiting for an impl slot — the plan-done entity occupies a "plan slot" until its impl worker completes. Reading (a) allows flow, treating the slot as "currently busy worker", not "entity-at-status".
I drifted between both readings during a long sprint and only settled on (a) by experiment.
Proposal
The shared first-officer core should be explicit about which interpretation is canonical, with a one-paragraph example showing what happens when an entity completes its plan-stage stage report and is held queued.
Scale context